Chap 13.
Logical Architecture and
UML Package Diagrams
1
Objectives
z Introduce a logical architecture using
layers
z illustrate the logical architecture using
UML package diagrams
2
Introduction
z The design of a typical OO system is
based on several architectural layers,
such as a UI layer, an application logic
layer, and so forth.
z This chapter briefly explores a logical
layered architecture and related UML
notation
3
Sample UP Artifact Relationships
Domain
Business Model
Modeling *
*
Use-Case Model Supplementary
Require- Vision Specification Glossary
ments
The logical architecture is influenced by the
constraints and non-functional requirements
captured in the Supp. Spec.
Design Model
package diagrams
UI
of the logical
architecture
(a static view) Domain
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(...)
...
...
4
Figure 13.1 Sample UP artifact influence
Example
Figure 13.2 shows a partial layered, logical architecture drawn with
UML package diagram notation
UI
not the Java
Swing Swing libraries, but Web
our GUI classes
based on Swing
Domain
Sales Payments Taxes
Technical Services
Persistence Logging RulesEngine
5
Figure 13.2 Layers shown with UML package diagram notation
What is the logical architecture?
z The logical architecture is the large-scale
organization of the software classes into package,
subsystems, and layers
z Called because there’s no decision about how these
elements are deployed across different operating system
processes or across physical computers in a network
z A layer is a very coarse-grained grouping of classes,
packages, or subsystems that has cohesive responsibility
for a major aspect of the system
z User interface
z Application logic
z Software objects representing domain concepts that fulfill
application requirements
z Technical services
z General purpose objects and subsystems that provide supporting
technical services, such as database or error logging
6
What is the logical architecture?
z Software Architecture: Definition
z An architecture is the set of significant decisions
about the organization of a software system, the
selection of the structural elements and their
interfaces by which the system is composed,
together with their behavior as specified in the
collaborations among those elements, the
composition of these structural and behavioral
elements into pregressively larger subsystems,
and the architectural style that guides this
organization-these elements and their interfaces,
their collaborations, and their composition
7
Applying UML: Package Diagrams
z UML package diagrams are often used to
illustrate the logical architecture of a system-
the layers, subsystems, packages, etc.
z A layer can be modeled as a UML package
z Ex: the UI layer modeled as a package named UI
z It is common to want to show dependency
between packages so that developers can see
the larger-scale coupling in the system.
z The UML dependency line is used for this, a
dashed arrowed line with the arrow pointing
towards the depended-on package
z The UML package represents a namespace so
that a Date class may be defined in two
packages
8
UI Domain
Swing Web Sales
UI
UI::Swing UI::Web
Swing Web
Domain::Sales
Domain
Sales
Figure 13.3 Alternate UML approaches to show package nesting, using
Embedded packages, UML fully-qualified names, and the circle-cross symbol
9
Guideline
z Design with layers
z Organize the large-scale logical structure
of a system into discrete layers of distinct,
related responsibilities, with a clean,
cohesive separation of concerns such that
“lower” layers are low-level and general
services, and the higher layers are more
application specific
z Collaboration and coupling are from
higher to lower layers; lower-to-higher
layer coupling is avoided
10
ٛ GUI windows
ٛ reports UI
ٛ speech interface (AKA Presentation, View)
ٛ HTML, XML, XSLT, JSP, Javascript, ...
more
app
ٛ handles presentation layer requests specific
ٛ workflow Application
ٛ session state (AKA Workflow, Process,
ٛ
dependency
window/page transitions Mediation, App Controller)
ٛ consolidation/transformation of disparate
data for presentation
ٛ handles application layer requests
ٛ implementation of domain rules
Domain
ٛ 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 many business domains Business Infrastructure
ٛ CurrencyConverter (AKA Low-level Business Services)
ٛ (relatively) high-level technical services Technical Services
and frameworks (AKA Technical Infrastructure,
ٛ Persistence, Security High-level Technical Services)
ٛ low-level technical services, utilities,
Foundation
and frameworks
(AKA Core Services, Base Services,
ٛ data structures, threads, math,
Low-level Technical Services/Infrastructure)
file, DB, and network I/O
width implies range of applicability
11
Figure 13.4 Common layers in an information system logical architecture
Benefits of using Layers
z Separation of concerns z Mapping Code organization to
z Reduce coupling and layers and UML packages
dependencies, improve cohesion,
increase reuse potential, and
increase clarity // --- UI layer
[Link]
z Related complexity is
[Link]
encapsulated and decomposable // --- Domain layer
z Some layers can be replaced with // packages specific to the NextGen project
new implementation [Link]
z Lower layers contain reusable [Link]
functions // --- Technical services layer
[Link]
z Some layers can be distributed
// --- Foundation layer
z Development by teams is aided // foundation packages that our team creates
because of the logical [Link]
segmentation
z A great use for a UML CASE tool is
to reverse-engineer the source code
and generate a package diagram
automatically
12
Definition
Domain layer: the layer that contains domain objects to handle
application logic work
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.
13
Figure 13.5 Domain layer and domain model relationship
Definition
z The word tier has become widely used
to mean a physical processing
node(ex: client tier)
z The original of a tier in archirecture was a
logical layer, not a physical node
z The layers of an architecture are said to
represent the vertical slices, while
partitions represent a horizontal division
of relatively parallel subsystems of a
layer
14
Domain
POS Inventory Tax
Vertical Layers
Technical Services
Persistence Security Logging
Horizontal Partitions
Figure 13.6 Layers and partitions
15
Guideline: Don’t show external resources as the bottom layer
Worse Better
mixes logical and deployment views a logical view
a logical representation
Domain(s)
of the need for data or
services related to these
Domain(s)
POS Inventory subdomains, abstracting
implementation
decisions such as a
Technical database.
Services
Technical Services
Foundation Naming and Web
Persistence
Directory Services AppFramework
첽omponentٛ
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.
Figure 13.7 Mixing views of the architecture
16
Guideline
z Model-View separation principle
z Do not connect or couple non-UI objects directly
to UI objects
z Do not put application logic in the UI object
methods
z Model: a symnonym for the domain layer of
objects
z View: a symnonym for UI objects
z This principle states that model objects
should not have direct knowledge of view UI
objects
z Ex: a Register or Sale object should not directly
send a message to a GUI window object
ProcessSaleFrame
17
What’s connection between SSDs,
System operations, and Layers?
z SSDs illustrate these system operations, but
hide the specific UI objects
z It will be objects in the UI layer of the system that
capture these system operation requests
z In a well-designed layered architecture that
supports high cohesion and a separation of
concerns, the UI layer objects will then forward-
or delegate- the request from the UI layer onto
the domain layer for handling
z The message sent from the UI layer to the
domain layer will be the message illustrated on
the SSDs, such as enterItem
18
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
Figure 13.8 System operations in the SSDs and in terms of layers
19
UI
Swing Text
not the Java
Swing libraries, but used in quick
ProcessSale ProcessSale experiments
Frame our GUI classes Console
based on Swing
Domain
Sales Pricing
Register Sale PricingStrategy 쳃nterfaceٛ
Factory ISalePricingStrategy
ServiceAccess Payments
쳃nterfaceٛ
Services
CreditPayment ICreditAuthorization
Factory
ServiceAdapter
Inventory POSRuleEngine Taxes
쳃nterfaceٛ 쳃nterfaceٛ
POSRuleEngineFacade
IInventoryAdapter ITaxCalculatorAdapter
Technical Services
Persistence A general
purpose third-
Log4J Jess SOAP
DBFacade party rules
engine.
Figure NextGen Logical architecture 20
