You are on page 1of 22


System sequence diagrams

Sequence Diagram focus on time ordering of messages Show only one flow of control Can model simple sequential flow, branching, iteration, recursion and concurrency May need multiple diagrams

Primary Variant Exceptions

Sequence Diagram (Basic)

Student aClass: Class




Sequence Diagrams (Advanced)

Seq# [Guard] *[Iteration] Return-List := Operation-Name (Argument-List) *[Iteration Condition] recursion Conditional Lifeline {transient}

Sequence Diagrams (Advanced)

Seq# [Guard] *[Iteration] Return-List := Operation-Name (Argument-List) *[Iteration Condition] recursion Conditional Lifeline {transient}

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 major aspect of the system.

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.

Fig. 13.2 Layers shown with UML package diagram.

UI not the Java Swing libraries, but our GUI classes based on Swing Swing Web





Technical Services




Fig. 13.3 Various UML notations for package nesting

UI D om ain S w ing W eb S ales

UI U I::S w ing U I::W eb

S w ing D om ain::S ales

W eb D om ain S ales

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.

Fig. 13.4 Common layers in an IS logical architecture

G U I w indow s reports speech interface H T M L, X M L, X S LT, JS P , Javascript, ... UI (A K A P resentation , V iew )
m ore app specific dependency

handles presentation layer requests w orkflow session state w indow /page transitions consolidation /transform ation of disparate data for presentation handles application layer requests im plem entation of dom ain rules dom ain services ( P O S , Inventory ) - services m ay be used by just one application, but there is also the possibility of m ulti-application services

A pplication (A K A W orkflow , P rocess , M ediation , A pp C ontroller)

D o m ain (A K A B usiness , A pplication Logic, M odel)

very general low -level business services used in m any business dom ains C urrencyC onverter

B usiness Infrastructu re (A K A Low -level B usiness S ervices )

(relatively) high-level technical services and fram ew orks P ersistence , S ecurity

Tech nical S ervices (A K A Technical Infrastructure , H igh-level Technical S ervices )

low -level technical services , utilities, and fram ew orks data structures, threads, m ath, file, D B , and netw ork I/O

Foun dation (A K A C ore S ervices, B ase S ervices , Low -level Technical S ervices /Infrastructure)
w idth im plies range of applicability

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.

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.

Class Diagrams

A class diagram shows:


Attributes Methods

Interfaces Collaborations Relationships: Dependency, Generalization, Association

A class diagram is a STATIC view of system

Basic Class Diagrams

Class Name

size: Size visibility: boolean display() hide()

Attributes Operations

Basic Class Diagrams

+ # / $ public protected private derived static


<<abstract>> <<constructor>> <<query>> <<update>>

Class Scope Variable

Visibility Attribute Name [Multiplicity]:Type = Initial Value Visibility Method Name (Parameter List) : Return-List

Attribute Example (Java implementation)

Note + author: String = unknown + text : String - total : long = 0

public class Note { public String author = unknown; public String text; private static long total = 0; ... }

Operation Example (Java implementation)

- size: Size - pos : Position + move(pos : Position) + getFigureCount() : long

public class Figure { private Size size; private Position pos; private static long figureCount = 0; public void move(Position pos) { ... } public static long getFigureCount() { return figureCount; } ... }

Basic Class Diagrams

Class A Superclass Class with parts Class with parts Interface name Class B Subclass Assembly Class Assembly Class Concrete Class

Association (relationship)

Inheritance (Generalization) (is-a, kind-of)

Aggregation (Part-Of)



UML interaction diagrams

Interaction diagrams model the behavior of use cases by describing the way groups of objects interact to complete the task. The two kinds of interaction diagrams are sequence and collaboration diagrams.

Collaboration diagrams:

Collaboration diagrams are also relatively easy to draw. They show the relationship between objects and the order of messages passed between them. The objects are listed as icons and arrows indicate the messages being passed between them. The numbers next to the messages are called sequence numbers. As the name suggests, they show the sequence of the messages as they are passed between the objects. There are many acceptable sequence numbering schemes in UML. A simple 1, 2, 3... format can be used, as the example below shows, or for more detailed and complex diagrams a 1, 1.1 ,1.2, 1.2.1... scheme can be used.