Applying UML & Patterns (3rd ed.

Chapter 13
LOGICAL ARCHITECTURE
&
UML PACKAGE DIAGRAMS

This document may not be used or altered without the express permission of the author.

Dr. Glenn L. Ray

School of Information Sciences
University of Pittsburgh
[email protected] 412-624-9470
Fig. 13.1

Sam ple UP Artifact Relationships

Dom ain
Business M odel
Modeling *
*

Use-Case Model Supplem entary

Require- Vision Specification Glossary
m ents

The logical architecture is influenced by the

constraints and non-functional requirements
captured in the Supp. Spec.

Design Model

package diagram s
UI
of the logical
architecture
(a static view) Dom ain

Tech
Services

: Register : ProductCatalog

Design interaction diagrams enterItem

(a dynamic view) (itemID, quantity)

spec = getProductSpec( itemID )

Register
ProductCatalog
class diagrams ... 1 1 ...
(a static view)
makeNewSale()
getProductSpec(...)
enterItem (...)
...
...

1/31/2008 Copyright © 2004 Glenn L. Ray 2

(From Larman 2004)
Fig. 13.2

• Logical architecture
– Shows large-scale organization of SW
classes, grouped by
• Layers (coarse-grained)
• Packages
• Subsystems (finer-grained)

– Independent of actual deployment

considerations

1/31/2008 Copyright © 2004 Glenn L. Ray 3

(From Larman 2004)
Fig. 13.2

• Software architecture definition

– Significant decisions about organization of
SW system
– Selection of structural elements & their
interfaces
– Specification of behavior by collaborating
elements
– Applied at higher and lower levels of system
composition
1/31/2008 Copyright © 2004 Glenn L. Ray 4
(From Larman 2004)
Fig. 13.2

• Layered architecture
– Probably most common generic architecture
– Typically 3 layers
• UI
• Domain
• Tech. Services (DB, logging, etc.)
– Strict version: Layer only calls on layer below
– Relaxed version: Layer may call on multiple
lower layers (common in SW)
1/31/2008 Copyright © 2004 Glenn L. Ray 5
(From Larman 2004)
Fig. 13.2
UI

not the Java

Swing Swing libraries, but Web
our GUI classes
based on Swing

Domain

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine

Layered architecture showing package diagram notation

1/31/2008 Copyright © 2004 Glenn L. Ray 6
(From Larman 2004)
Fig. 13.2

• UML package diagrams

– Illustrate logical architecture
– Can group elements within packages
• Classes
• Other packages
• Use cases, etc.
– Dependency line indicates coupling of packages
• Arrow points to the depended upon package
• Implies change to depended upon package likely impacts
dependent package
• Robust architectures minimize dependencies

1/31/2008 Copyright © 2004 Glenn L. Ray 7

(From Larman 2004)
Fig. 13.3

Embedded packages
UI Domain

Swing W eb Sales

Fully-qualified names Circle-cross notation

UI

UI::Swing UI::W eb

Swing W eb
Domain::Sales
Domain

Sales

Alternative package nesting notation

1/31/2008 Copyright © 2004 Glenn L. Ray 8
(From Larman 2004)
Fig. 13.2

• Layers Architectural Pattern

– Large-scale logical structure composed of layers with
distinct responsibilities
– Clear separation of concerns between layers
– Higher layers more application specific
– Lower layers more general
– Coupling is from higher -> lower (avoid the reverse!)

1/31/2008 Copyright © 2004 Glenn L. Ray 9

(From Larman 2004)
Fig. 13.2

• Benefits of Layered Architectural Pattern

– Prevents source code changes from rippling
throughout system
• Code changes should be confined within a specific layer

– Facilitates plug ‘n play between layers

• When domain layer independent of UI layer, domain layer
can be used with another UI layer
• Example: Application and web UIs for a given application

1/31/2008 Copyright © 2004 Glenn L. Ray 10

(From Larman 2004)
Fig. 13.2

• Benefits of Layered Architectural Pattern

– System is easier to comprehend since each layer has
specific purpose

– Better division of work so developers can work

independently on different layers simultaneously

– Minimizing coupling makes it easier to swap out a

technical service in a lower layer and replace it with
another technology
• Replacing RDBMS without major code re-write in application
logic
1/31/2008 Copyright © 2004 Glenn L. Ray 11
(From Larman 2004)
Fig. 13.2

• Benefits of Layered Architectural Pattern

– Lower layers contain more reusable functionality

– Some layers (Domain & technical) more amenable to

distributed deployment

– Facilitates ‘high-cohesion’ within layers and ‘low-

coupling’ between layers

1/31/2008 Copyright © 2004 Glenn L. Ray 12

(From Larman 2004)
Fig. 13.4
GUI windows
reports UI
speech interface (AKA Presentation, View)
HTML, XM L, XSLT, JSP, Javascript, ...
m ore
app
handles presentation layer requests specific
workflow Application
session state (AKA W orkflow, Process,

dependency
window/page transitions M ediation, App Controller)
consolidation/transform ation of disparate
data for presentation

handles application layer requests

implementation of domain rules
Dom ain
domain services (POS, Inventory) (AKA Business,
- services may be used by just one Application Logic, Model)
application, but there is also the possibility
of multi-application services

very general low-level business services

used in m any business dom ains Business Infrastructure
CurrencyConverter (AKA Low-level Business Services)

(relatively) high-level technical services Technical Services

and fram eworks (AKA Technical Infrastructure,
Persistence, Security High-level Technical Services)

low-level technical services, utilities,

Foundation
and fram eworks
(AKA Core Services, Base Services,
data structures, threads, m ath,
Low-level Technical Services/Infrastructure)
file, DB, and network I/O

width im plies range of applicability

1/31/2008 Copyright © 2004 Glenn L. Ray 13

(From Larman 2004)
Fig. 13.5
UP Domain Model
Stakeholder's view of the noteworthy concepts in the domain.

Sale
A Payment in the Domain Model Payment 1
1 Pays-for
is a concept, but a Payment in date
the Design Model is a software amount
time
class. They are not the same
thing, but the former inspired the
inspires
naming and definition of the
objects
latter.
and
names in
This reduces the representational
gap.
Sale
This is one of the big ideas in Payment
object technology. 1 1 date: Date
Pays-for
amount: Money startTime: Time

getBalance(): Money getTotal(): Money

...

Domain layer of the architecture in the UP Design Model

The object-oriented developer has taken inspiration from the real world domain
in creating software classes.

Therefore, the representational gap between how stakeholders conceive the

domain, and its representation in software, has been lowered.

1/31/2008 Copyright © 2004 Glenn L. Ray 14

(From Larman 2004)
Fig. 13.6

Domain

POS Inventory Tax

Vertical Layers
Technical Services

Persistence Security Logging

Horizontal Partitions

Tiers are often synonymous with layers, but may also indicate physical nodes
3-tier is GUI/Domain/Tech Svcs layers
n-tier is any number, usually more than 3 tiers
1/31/2008 Copyright © 2004 Glenn L. Ray 15
(From Larman 2004)
Fig. 13.7
W orse Better
mixes logical and deployment views a logical view
a logical representation
Dom ain(s)
of the need for data or
services related to these
Dom ain(s)
POS Inventory subdomains, abstracting
implementation
decisions such as a
Technical database.
Services
Technical Services

Foundation Naming and W eb

Persistence
Directory Services AppFramework

«component»
Novell
MySQL LDAP Foundation
Inventory

UML notation: A UML component, or replaceable, modular part of the physical system

UML notation: A physical database in the UML.

Mixed views of architecture

Logical view avoids premature implementation decisions

1/31/2008 Copyright © 2004 Glenn L. Ray 16

(From Larman 2004)
Fig. 13.8

• Model-View Separation Principle

– Model is the domain layer
– View is the UI layer
– Model objects shouldn’t have knowledge of
View objects
– Don’t assign domain responsibility to View
objects
– Better separation of concerns with lower
coupling
– Facilitates multiple views of a given Model
1/31/2008 Copyright © 2004 Glenn L. Ray 17
(From Larman 2004)
Fig. 13.8
UI

Swing makeNewSale()
:System enterItem()
: Cashier ProcessSale endSale()
...
Frame
makeNewSale()
: Cashier
enterItem(id, quantity)
makeNewSale()
description, total enterItem()
endSale()
Domain

endSale()
... Register

makeNewSale()
enterItem()
...

the system operations handled by the system in an SSD represent the

operation calls on the Application or Domain layer from the UI layer

Keep in mind that system operations are ‘passed through’ the UI layer to
the domain layer

1/31/2008 Copyright © 2004 Glenn L. Ray 18

(From Larman 2004)