Logical Architecture

The Bigger Picture

• we’ve looked at how to apply design patterns in close-up detail:

• at code or class level

• now we’ll look at the bigger picture:

• the organisation of a system

• its structure

• representational elements

• behavioural elements

• how elements communicate

 Packages

• systems are typically made up of packages:

user interface domain

ViewPanel InfoPanel Molecule Rule

application file handling

SimControl Driver queryDB insertDB

• we’ll look at the coupling and communication between these packages

• we’ll represent our analysis and design in a Logical Architecture Diagram

 Layers Pattern

• problem:

• many parts of the system are highly coupled

• maybe across different areas of concern

• changes to one area have impact across many other

areas

• application logic lives in UI, or

• service logic mixed in with domain classes

• hard to re-use or replace

 Layers Pattern

• solution:

• organise the large-scale structure of the system into

discrete layers of distinct related responsibilities

• achieve clean and cohesive separation of concerns:

• lower layers are low-level, general services (e.g.

database)

• higher layers are more application specific

• each layer may contain several packages or subsystems

Example: a 6-tier architecture

from Ch 30 Applying UML & Patterns (Larman)

Example: 4-tier achem program

: layers implemented

from Ch 30 Applying UML & Patterns (Larman)

 Example: 4-tier achem program
Presentation
swing text

ViewPanel InfoPanel InfoConsole

Application
commands
• we only show a few sample types for each
Simulation folder/layer
startCommand
• because this is meant as a large-scale overview
Domain
matter rules stats environment

Atom Molecule Rule1 StatSummary Lattice

Foundation
file handling .jxl

FileHandler (external library)

 Inter-Layer & Inter-Package Coupling
Presentation
swing text
• we can show dependency lines between types
ViewPanel InfoPanel InfoConsole and/or packages
• whichever is most illustrative
• notice the relaxed layered coupling, where
Application elements of one layer collaborate with several
commands other layers
Simulation
startCommand

Domain
matter rules stats environment

Atom Molecule Rule1 StatSummary Lattice

Foundation
file handling .jxl

FileHandler (external library)

Designing the Connection between
Layers and Packages
• some packages are simple groups of types

• for example: Domain:rules

• but some are subsystems

• for example Foundation:file_handling

<<subsystem>>
file handling

• they have cohesive responsibilities and do work by themselves

• so it’s worth thinking about how these subsystems as a whole

interact with other parts of the system
 Using Facade

• most common pattern of access for a subsystem

• a public object provides the interface for the subsystem

• clients interact with this interface, not the internal subcomponents

• interface methods expose high-level operations, not low-level ones

• for example, saveStats() rather than jxl.sheet.writeLine()

• this indirection protects the rest of the system from variations

• often also used for downward collaboration from a higher layer to a

lower layer

• for upward collaboration - such as domain to presentation layer - the

Observer pattern is often used
 Using Observer

• UI elements implement the Observer interface

• or a variant of it

• they listen to state changes in the domain layer objects

• for example: image editing application:

• user moves colour saturation slider to far left

• UI passes this input to a control object

• control object enacts image.setSaturation(0)

• image object notifies its observers that it has changed

• UI (an observer) reacts to the change and displays the image with its
new saturation level
Do we need an Application Layer?

• the application layer can contain objects which:

• know the state of the clients

• mediate between the presentation and domain layers

• control the flow of work

• consider using this layer when:

• the system uses multiple interfaces

• the system is distributed

• it is inappropriate for the domain layer to maintain session

state
Benefits of modelling the Logical
Architecture
• provides separation of concerns:

• reduces coupling and improves cohesion

• related complexity is kept in one place

• and can be decomposed if need be

• layers can be replaced

• for example, replace the presentation layer when porting from pc to

handheld

• lower layers contain reusable items

• can distribute the program across a network

• development can be partitioned, allowing parallel design and build

• so good for team projects

The Model-View Separation Principle

• what kind of visibility should other packages have to

the presentation layer?

• avoiding direct coupling between UI and other

components is desirable:

• allows re-use of the other components or UI

• allows a new interface to be implemented

The Model-View Separation Principle

...states that:

• domain objects should not have direct knowledge of

presentation objects

• for example, Weapon should not send a message (directly,

explicitly✻) to the display asking it to show its new
location

• ✻ hence use of Observer is a legitimate exception to this

• domain classes should encapsulate the application logic and data

• UI classes should be responsible for input and output only

The Model-View Separation Principle

• if we have implemented an application layer, then this

principle extends to (poorly named) Model-View-Controller:

• control classes act as intermediaries between the UI and

domain classes. Typically:

• UI passes an input to control

• control manipulates the relevant domain classes

• control passes information about the new state of the

domain classes to UI (or observer is used)

• UI outputs result
 Benefits of MV Separation

• supports models which focus on the domain processes rather

than the UI

• allows separate development of the model and UI layers

• minimises impact of change to UI upon the domain

• allows multiple views

• allows model layer to execute separately from the UI layer

• for example, in a distributed system

• allows porting of model layer to another system using another

UI
 Issue: Upward Communication

• we can aim to separate model from view, but the UI still needs
information to display

• polling - ‘pull from above’ - can work:

• UI sends messages to domain objects, querying state

• if state has changed then UI updates

• but this can be inefficient

• potentially thousands of polling messages sent for each

change

• so ‘push from below’ may be better...

 Issue: Upward Communication

• ...so ‘push from below’ may be better:

• but we want to avoid direct coupling of domain objects to

the UI

• we’ve already noted that Observer is one possible solution:

• making domain objects responsible for notifying

observers when state changes

• potentially fewer messages than with polling

• another solution is to create a presentation layer facade

 Presentation Layer Facade

• not a gui class

• a ‘plain’ object which adds
indirection to the UI objects

• used occasionally
• often control classes in an
application layer will handle
this responsibility
from Ch 30 Applying UML & Patterns (Larman)

• the indirection also provides protected variation if the UI

changes

• we can still use the observer pattern:

• let the facade observe the domain objects

 To conclude
• analysing and designing the architecture helps us see the bigger picture

• to split a project into cohesive layers, packages and subsystems

• we can create facades to handle the interface between layers and

subsystems

• this indirection protects the rest of the model from variations

• we should try to keep the model and view separated

• keep the application logic encapsulated in the domain where appropriate

• let the UI just worry about input and output

• it’s a big subject, there’s other things we haven’t looked at:

• such as networking impact of 2-tier versus n-tier client-server systems

References & Further Reading
• base structure and figures taken from:

• Applying UML & Patterns (Larman), Chapter 30

 AChem Application Logical Architecture

Presentation • this is a first-cut attempt at modelling the logical architecture

• not complete, but already it can help to guide design
swing text •we have identified 4 tiers in the architecture
•we show sample classes for each layer/package
ViewPanel InfoPanel InfoConsole •we show the key dependencies between packages and/or
objects, whichever is most relevant, for example:
• the swing.ViewPanel object is dependent upon the state of
the environment.Lattice object
Application •the Simulation object in the application layer is dependent
upon pretty much everything in the matter package
commands
Simulation
startCommand

Domain
matter rules stats environment

Atom Molecule Rule1 StatSummary Lattice

Foundation
file handling .jxl

FileHandler (external library)

M Hatcher