Chapter 6: Logical Architecture and UML Package Diagrams

Source files used: Lecture 6 - Logical Architecture and Packages; textbook (applying-uml-and-patterns.pdf) Chapter 30 as support.

A focused guide to logical architecture, layers, and UML package diagrams for the COMP302 Midterm 1. It covers what layers are, the typical layers of an information system, how to draw package diagrams, the Model-View Separation principle, and how SSD messages cross the layers. Guides 3 to 5 were analysis; this guide is the first step of design, at the largest scale.

Roadmap: 1 OOA/D and UP → 2 Inception and Requirements → 3 Use Cases → 4 Domain Models → 5 SSDs and Contracts → 6 Logical Architecture → 7 Interaction Diagrams

Logical Architecture and Layers

From Analysis to Design

The course now moves from analysis-oriented work to software design, starting with the large scale. At this level, a typical OO system is designed as several architectural layers: a UI layer, an application logic (or “domain”) layer, and so on. The logical architecture is influenced by the constraints and non-functional requirements in the Supplementary Specification.

What Is the Logical Architecture?

The logical architecture is the large-scale organization of the software classes into packages (or namespaces), subsystems, and layers.

“Logical” means no decision is made about how these elements are deployed across operating system processes or across physical computers in a network.

What Is a Layer?

A layer is a coarse-grained grouping of classes, packages, or subsystems that has responsibility for a major aspect of the system. Layers are organized so that “higher” layers (such as the UI) call upon services of “lower” layers, not the other way around.

Typical layers in an OO system:

User Interface,
Application Logic and Domain Objects: software objects representing domain concepts,
Technical Services: general-purpose objects and subsystems such as database interfacing or error logging; usually application-independent and reusable across several systems.

What Is Software Architecture?

The set of significant decisions about:

the organization of a software system,
the selection of the structural elements and their interfaces, with their behavior,
the composition of these elements into larger subsystems,
the architectural style that guides this organization.

UML Package Diagrams

Notation

UML package diagrams illustrate the logical architecture: layers, subsystems, packages (in the Java sense), and so on.

A UML package can group anything: classes, other packages, use cases.
Nesting packages is very common.
A dependency between packages is a dashed arrow from the dependent package to the package it depends on.
A package is a namespace: a Date class may be defined in two packages. A fully qualified name uses ::, for example java::util::Date (outer package java, nested package util, class Date).
Nesting can also be shown as UI::Swing, or with a circle-plus connector from the outer package to its nested packages.

The lecture’s partial NextGen architecture:

+-- UI -----------------------------------------+
|   [Swing]                              [Web]  |
+-----------------------------------------------+
           :                               :
           v                               :
+-- Domain ---------------------------+    :
|   [Sales]   [Payments]   [Taxes]    |    :
+-------------------------------------+    :
           :                               :
           v                               v
+-- Technical Services -------------------------+
|   [Persistence]   [Logging]   [RulesEngine]   |
+-----------------------------------------------+

[Name] = package;  : and v = dependency (a dashed arrow in UML)

Here “Swing” is not the Java Swing library: it is the team’s own GUI classes based on Swing. Note the Web package depending directly on Logging, two layers down.

Exam Trap #1: Drawing the dependency arrow the wrong way.

WRONG:   Domain - - -> UI         (lower layer depends on a higher one)
CORRECT: UI - - -> Domain - - -> Technical Services

Designing With Layers

The Two Principles

Layering applies two key architectural principles: separation of concerns and high cohesion.

Organize the large-scale structure into discrete layers of distinct, related responsibilities, with a clean, cohesive separation of concerns.
“Lower” layers are low-level, general services; higher layers are more application-specific.
Collaboration and coupling go from higher to lower layers; lower-to-higher coupling is avoided.

Problems That Layers Solve

Source code changes ripple throughout the system because many parts are highly coupled.
Application logic is intertwined with the user interface, so it cannot be reused with a different interface or distributed to another processing node.
General technical services or business logic is intertwined with application-specific logic, so it cannot be reused, distributed, or easily replaced.
High coupling across areas of concern makes it hard to divide the work along clear boundaries for different developers.

Benefits of Using Layers

Separation of concerns (high-level from low-level services, application-specific from general services), which reduces coupling and dependencies, improves cohesion, increases reuse potential, and increases clarity,
complexity is encapsulated and decomposable,
layers can be replaced with new implementations,
lower layers contain reusable functions,
separate teams can develop separate layers.

Key Insight: This is what loose coupling means at the architecture level: parts depend on each other as little as possible, and only in one direction (downward), so a change in one layer does not ripple through the rest.

Common Layers in an Information System

From the most application-specific (top) to the most general (bottom). Dependencies point downward.

Layer	Also known as	Typical contents
UI	Presentation, View	GUI windows, reports, speech interface, HTML, XML, JSP, JavaScript
Application	Workflow, Process, Mediation, App Controller	handles presentation layer requests; workflow; session state; window/page transitions; consolidating data for presentation
Domain	Business, Application Logic, Model	handles application layer requests; implements domain rules; domain services (POS, Inventory)
Business Infrastructure	Low-level Business Services	very general business services used in many business domains, such as CurrencyConverter
Technical Services	Technical Infrastructure, High-level Technical Services	relatively high-level technical services and frameworks: Persistence, Security
Foundation	Core Services, Base Services, Low-level Technical Services/Infrastructure	data structures, threads, math, file, DB, and network I/O

The purpose and number of layers vary across applications and domains. In the lecture figure, the width of each layer implies its range of applicability: lower layers are wider (more general).

Strict vs Relaxed Layering

The textbook adds a distinction:

Strict layering: layer N only uses layer N-1, as in the OSI network model.
Relaxed layering: a layer may use several lower layers. This is the norm in information systems. For example, all higher layers depend on Technical Services and Foundation (in Java, every layer uses java.util).

Either way, dependencies still only go downward.

Mapping Layers to Code

Layers Become Package Names

OO languages support packages (C# and C++ call them namespaces). Layers and packages map to Java package names, with the layer name as part of the package name:

// --- UI layer
com.mycompany.nextgen.ui.swing
com.mycompany.nextgen.ui.web

// --- DOMAIN layer (packages specific to the NextGen project)
com.mycompany.nextgen.domain.sales
com.mycompany.nextgen.domain.payments

// --- TECHNICAL SERVICES layer
com.mycompany.service.persistence   // our home-grown persistence access layer
org.apache.log4j                    // third party
org.apache.soap.rpc                 // third party

// --- FOUNDATION layer
com.mycompany.util                  // foundation packages our team creates

Domain Layer vs Domain Model

The domain layer is part of the software; the domain model is part of the conceptual analysis (Guide 4).
We look to the domain model for inspiration for the class names in the domain layer.
Doing so gives a lower representational gap between the real-world domain and the software design.

Exam Trap #2: “The domain layer is the domain model.” They are different artifacts: one is code, the other is a picture of real-world concepts.

Tiers, Layers, and Partitions

Tier originally meant a logical layer, but it is now widely used for a physical processing node, such as the “client tier” (the client computer).
Layers are the vertical slices of an architecture.
Partitions are a horizontal division of relatively parallel subsystems within one layer (Domain: POS, Inventory, Tax; Technical Services: Persistence, Security, Logging).

Don’t Show External Resources as the Bottom Layer

Systems rely on external resources such as a MySQL database or Novell LDAP. These are physical implementation components, not a layer of the logical architecture.

WORSE (mixes logical and deployment views):
  Domain(s)
  Technical Services
  Foundation
  [MySQL Inventory database]  [«component» Novell LDAP]   <- not layers

BETTER (a logical view):
  Domain(s):          [POS] [Inventory]
  Technical Services: [Persistence] [Naming and Directory Services]
                      [Web AppFramework]
  Foundation

Exam Trap #3: Drawing “Database” or “MySQL” as the lowest layer. Show the logical need (Persistence) instead.

Model-View Separation

The Principle

What visibility should other packages have to the UI layer? In older terms, the model is the domain layer and the view is the UI objects (windows, web pages, reports).

Guideline: Model-View Separation Principle

Do not connect or couple non-UI (domain) objects directly to UI objects. For example, don’t let a Sale object hold a reference to a Window object. Windows belong to one particular application, while domain objects may be reused in new applications or attached to a new interface.
Do not put application logic in UI object methods. UI objects should only initialize UI elements, receive UI events (such as a mouse click on a button), and delegate requests for application logic to non-UI objects.

// WRONG: the domain object holds a window
public class Sale {
    private ProcessSaleFrame frame;     // domain -> UI coupling, not allowed
}

// WRONG: application logic inside a UI event handler
public void actionPerformed(ActionEvent e) {
    total = total + price * quantity;   // business math living in the window
}

// CORRECT: the window just delegates the system operation
public void actionPerformed(ActionEvent e) {
    register.enterItem(id, quantity);   // domain layer does the real work
}

When the Domain Must Notify the UI: Observer

A relaxation of the principle is the Observer pattern. Domain objects send messages to UI objects that they know only through an interface, such as PropertyListener.

The domain object knows that some object implements PropertyListener, but not which object (and not that it is a window).
Notification happens through the interface methods, for example onPropertyEvent(sale, "sale.total", total) in the textbook’s version.

The lecture’s quick illustration has a Subject interface (addObserver(), removeObserver(), notifyObservers()) implemented by WeatherStation, and an Observer interface (update(weather)) implemented by PhoneDisplay and TVDisplay.

Motivation for Model-View Separation

domain objects focus on domain processes, not on user interfaces,
domain objects and UI can be developed separately,
requirement changes in one have minimal effect on the other,
new views (UIs) can be connected to an existing domain layer,
multiple simultaneous views (a GUI and a text interface) can share the same model object,
the domain layer works without the UI layer being on,
modularity.

SSDs, System Operations, and Layers

Where the SSD Messages Go

SSDs show system operations but hide the UI objects.
In the real system, objects in the UI layer capture the system operation requests, usually through a GUI.
The UI layer then forwards or delegates each request to the domain layer (or the application layer).
The messages sent from the UI layer to the domain layer are the messages on the SSD, such as enterItem.

:Cashier --makeNewSale(), enterItem(), endSale()--> [UI: ProcessSaleFrame]
[UI: ProcessSaleFrame] --makeNewSale(), enterItem(), endSale()--> [Domain: Register]

Key Insight: The system operations of an SSD (Guide 5) become the operation calls on the Application or Domain layer from the UI layer. Guide 7 designs what happens after the domain object receives them.

Exam-Style Practice Problems

Problem 1: Order the Layers

Question: The Fall 2024 Midterm 1 study sheet: for the layers UI, Application, Domain, Foundation, (a) rewrite them in order from the higher (application-specific) layer to the lower (generic) layer; (b) which layers depend on which?

Answer:

(a) UI  >  Application  >  Domain  >  Foundation
(b) Each layer depends only on layers below it:
    UI -> Application -> Domain -> Foundation
    (relaxed layering: e.g. UI and Application may also use Foundation directly)
    No lower layer depends on a higher one.

Problem 2: Draw the Package Diagram

Question: (Study sheet) Draw a package diagram with three layers (create new packages for the layers) for the packages Web, Mobile, Products, Inventory, Offices, Persistence, Security, Logging.

Answer:

+-- UI ----------------------------------------------+
|   [Web]                    [Mobile]                |
+----------------------------------------------------+
                          :
                          v
+-- Domain ------------------------------------------+
|   [Products]        [Inventory]        [Offices]   |
+----------------------------------------------------+
                          :
                          v
+-- Technical Services ------------------------------+
|   [Persistence]      [Security]        [Logging]   |
+----------------------------------------------------+

Draw each layer as a package containing its packages, with dashed dependency arrows pointing down.

Problem 3: Define the Terms

Question: Explain “layer (in the context of a package diagram)” and “loose coupling” (both on the study sheet’s term list).

Answer:

Layer: a coarse-grained grouping of classes, packages, or subsystems with responsibility for a major aspect of the system, drawn as a package; higher layers use the services of lower layers.
Loose coupling: elements depend on each other as little as possible, so changes do not ripple; layers get it by allowing coupling only from higher to lower layers and by keeping the domain separate from the UI.

Common Exam Traps

1. Upward Dependencies

WRONG:   Domain depends on UI;  Foundation depends on Domain
CORRECT: dependencies only point downward

Why: Lower-to-higher coupling is what layering is meant to avoid.

2. Domain Objects Holding UI References

WRONG:   class Sale { Window w; }
CORRECT: Sale knows only an interface (PropertyListener) if it must notify

Why: Model-View Separation, relaxed only through Observer.

3. Business Logic in Event Handlers

WRONG:   the button handler computes totals and taxes
CORRECT: the handler delegates to register.enterItem(...)

Why: UI objects only initialize, receive events, and delegate.

4. External Resources as a Layer

WRONG:   bottom layer = "MySQL"
CORRECT: Technical Services contains a Persistence package

Why: A database product is a physical component, not part of the logical architecture.

5. Wrong Layer Order

WRONG:   UI > Domain > Application > Foundation
CORRECT: UI > Application > Domain > Business Infrastructure
            > Technical Services > Foundation

Why: The Application layer mediates between the UI and the Domain.

6. Logical Is Not Physical

WRONG:   "The logical architecture says the domain runs on the server."
CORRECT: "Logical architecture makes no deployment decisions; the physical
          (deployment) view does."

Why: “Logical” means no decision about processes or computers.

7. Layers vs Partitions

WRONG:   partitions = vertical slices
CORRECT: layers = vertical slices; partitions = horizontal subsystems within a layer

Why: The lecture’s figure shows POS, Inventory, Tax side by side inside Domain.

8. Domain Layer vs Domain Model

WRONG:   "We implement the domain model."
CORRECT: "The domain model inspires the class names of the domain layer."

Why: One is conceptual analysis, the other is software.

Final Tips for the Midterm

Know the six layers in order with one example each: UI, Application, Domain, Business Infrastructure, Technical Services, Foundation.
Draw package diagrams fast: a box per layer, nested packages inside, dashed arrows pointing down.
State Model-View Separation as two rules: no domain-to-UI coupling, no application logic in the UI.
Name Observer as the exception: the domain talks to the UI only through an interface.
Connect to Guide 5: SSD system operations are the UI-to-domain calls.
Define loose coupling in one sentence: few, downward dependencies so changes do not ripple.

Good luck on the midterm! You’ve got this.