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 Reduce coupling and
dependencies, improve cohesion,
increase reuse potential, and
increase clarity
z Related complexity is
encapsulated and decomposable
z Some layers can be replaced with
new implementation
z Lower layers contain reusable
functions
z Some layers can be distributed
z Development by teams is aided
because of the logical
segmentation
z Mapping Code organization to
layers and UML packages
// --- 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
// --- Foundation layer
// foundation packages that our team creates
com.mycompany.util
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