13_logicalArch

8/13/2019 13_logicalArch

1/16

Chapter 13

Logical Architecture and

UML Package Diagrams


2/16

Logical Architecture and Layers

Logical architecture: the large-scale

organization of software classes into

packages, subsystems, and layers.

Logical because no decisions about

deployment are implied. (See Chap. 37.)

Layer: a very coarse-grained grouping of

classes, packages, or subsystems that

has cohesive responsibility for a majoraspect of the system.


3/16

Layered Architectures

Typical layers in an OO system:

User Interface

Application Logic and Domain Objects

Technical Services

Application-independent, reusable across systems.

Relationships between layers:

Strict layered architecture: a layer only calls

upon services of the layer directly below it.

Relaxed layered architecture: a higher layer

calls upon several lower layers.


4/16

Fig. 13.2 Layers shown with UML package diagram.

Domain

UI

Swingnot the JavaSwing libraries, butour GUI classesbased on Swing

Web

Sales Payments Taxes

Technical Services

Persistence Logging RulesEngine


5/16

Fig. 13.3 Various UML notations for package nesting

Domain::Sales

UI::WebUI::Swing

Sales

WebSwing

UI

Domain

DomainUI

Swing SalesWeb


6/16

Design with Layers

Organize the large-scale logical structure

of a system into discrete layers of distinct,

related responsibilities.

Cohesive separation of concerns.

Lower layers are general services.

Higher layers are more application-specific.

Collaboration and coupling is from higher

to lower layers.

Lower-to-higher layer coupling is avoided.


7/16

Fig. 13.4 Common layers in an IS logical architecture

UI

(AKA Presentation, View)

Application(AKA Workflow, Process,

Mediation, App Controller)

Domain(AKA Business,

Application Logic, Model)

Technical Services(AKA Technical Infrastructure,

High-level Technical Services)

Foundation(AKA Core Services, Base Services,

Low-level Technical Services/Infrastructure)

width implies range of applicability

GUI windows reports speech interfaceHTML, XML, XSLT, JSP, Javascript, ...

handles presentation layer requests workflow session state window/page transitions consolidation/transformation of disparatedata for presentation

handles application layer requests implementation of domain rules domain services (POS, Inventory)- services may be used by just one

application, but there is also the possibility

of multi-application services

(relatively) high-level technical services

and frameworks

Persistence, Security

low-level technical services, utilities,and frameworks data structures, threads, math,file, DB, and network I/O

moreapp

specific

dependency

Business Infrastructure

(AKA Low-level Business Services)

very general low-level business servicesused in many business domains CurrencyConverter


8/16

Benefits of a Layered Architecture

Separation of concerns:

E.g., UI objects should not do application

logic (a window object should not calculate

taxes) nor should a domain layer object

create windows or capture mouse events.

Reduced coupling and dependencies.

Improved cohesion.

Increased potential for reuse.

Increased clarity.


9/16

Benefits of a Layered Architecture, continued

Related complexity is encapsulated and

decomposable.

Some layers can be replaced with new

implementations.

Lower layers contain reusable functions.

Some layers can be distributed.

Especially Domain and Technical Services. Development by teams is aided by logical

segmentation.


10/16

Designing the Domain Layer

How do we design the application logic withobjects?

Create software objects with names andinformation similar to the real-world

domain. Assign application logic responsibilities to

these domain objects.

E.g., a Sale object is able to calculate its total.The application logic layer is more accurately

called a domain layerwhen designed thisway.


11/16

Fig. 13.5 Domain Model Related to Domain Layer

Payment

amount

Sale

datetime

Pays-for

Payment

amount: Money

getBalance(): Money

Sale

date: DatestartTime: Time

getTotal(): Money. . .

Pays-for

UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.

Domain layer of the architecture in the UP Design ModelThe object-oriented developer has taken inspiration from the real world domainin creating software classes.

Therefore, the representational gap between how stakeholders conceive thedomain, and its representation in software, has been lowered.

1 1

1 1

A Payment in the Domain Modelis a concept, but a Payment inthe Design Model is a softwareclass. They are not the samething, but the former inspired thenaming and definition of thelatter.

This reduces the representationalgap.

This is one of the big ideas inobject technology.

inspiresobjects

and

names in


12/16


13/16

Fig. 13.7 Dont mix logical and deployment views.

Domain(s)

Technical

Services

Foundation

MySQL

Inventory

PersistenceNaming and

Directory ServicesWeb

AppFramework

Technical Services

POS Inventory

Domain(s)

Foundation

Worse

mixes logical and deployment viewsBetter

a logical viewa logical representationof the need for data or

services related to thesesubdomains, abstractingimplementation

decisions such as adatabase.

componentNovell

LDAP

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

UML notation: A physical database in the UML.


14/16

The Model-View Separation Principle

Model: the domain layer of objects.

View: user interface (UI) objects.

Model objects should not have direct

knowledge of view objects. Do not connect or couple non-UI objectsdirectly to UI objects.

E.g., dont let a Saleobject have a reference to a

Java Swing JFramewindow object.

Do not put application logic in a UI object.

UI objects should receive UI events and delegate

requests for application logic to non-UI objects.


15/16

Fig. 13.8 Messages from UI layer to domain layer

Domain

UI

Swing

ProcessSaleFrame

...

... Register

makeNewSale()enterItem()...

: Cashier

makeNewSale()enterItem()endSale()

makeNewSale()enterItem()endSale()

enterItem(id, quantity)

:System

: Cashier

endSale()

description, total

makeNewSale()

the system operations handled by the system in an SSD represent theoperation calls on the Application or Domain layer from the UI layer


16/16

The Observer Pattern

If model (domain) objects do not have direct

knowledge of view (UI) objects, how can a

Register or Saleobject get a window to

refresh its display when a total changes?

The Observerpattern (p. 463) allows domain

objects to send messages to UI objects

viewed only in terms of an interface.

E.g., known not as concrete window class, butas implementation of PropertyListenerinterface.

Allows replacement of one view by another.

Documents

13_logicalArch