1

What to remember from Chap 13 (Logical architecture)

2

3

Example of logical architecture using a UML package diagram.

Logical Architecture Logical architecture: the large-scale

organization of software classes into packages, subsystems, and layers.

• “Logical” because no decisions about how these elements are deployed across different operating system processes or across physical computers in a network

.

5

A layer is a very coarse-grained grouping of classes, packages, or subsystems that has cohesive responsibility for a major aspect of the system. • Layers are organized such that "higher" layers (such

as the UI layer) call upon services of "lower" layers, but not normally vice versa. Typically layers in an OO system include:

Layers

• User Interface.

• Application Logic and Domain Objects software objects representing domain concepts (for example, a software class Sale) that fulfill application requirements, such as calculating a sale total.

• Technical Services general purpose objects and subsystems that provide supporting technical services, such as interfacing with a database or error logging. These services are usually application-independent and reusable across several systems.

6

7

Connection between SSDs, System Operations and Layers

In a well-designed layered architecture that supports high cohesion and a separation of concerns, the UI layer objects will then forward the request from the UI layer onto the domain layer for handling.

8

On To Object Design

Chapter 14

Applying UML and Patterns

-Craig Larman

WSEP 06

Designing Objects:Static and dynamic modeling.

Two kinds of object models:

• Static models :• Class diagrams / Package diagram / Deployment diagram

Helps design definition of packages, class name, attributtes and method signature

• Dynamic models:• Interaction Diagrams/ (Sequence / comunication). State machine

diagrams/activity diagram

Illustrate how objects collaborate via messages and methdos . They help design the logic and method bodies

10

Agile modeling practice Create Models in parallel!Modeling with others

11

On To Object Design

Chapter 15

Applying UML and Patterns

-Craig Larman

Sequence Diagrams 12

A First Look at interaction Diagrams

Illustrate how objects interacts with each other.

Emphasizes time ordering of messages. Can model simple sequential flow,

branching, iteration, …etc

Fig. 15.5

sales: ArrayList<Sale>

:Sale s1 : Sale

lifeline box representing an instance of an ArrayList class, parameterized (templatized) to hold Sale objects

lifeline box representing an unnamed instance of class Sale

lifeline box representing a named instance

sales[ i ] : Sale

lifeline box representing one instance of class Sale, selected from the salesArrayList <Sale> collection

x : List

«metaclass»Font

lifeline box representing the class Font, or more precisely, that Font is an instance of class Class – an instance of a metaclass

related example

List is an interface

in UML 1.x we could not use an interface here, but in UML 2, this (or an abstract class) is legal

Fig. 15.1:sequence diagram

: A myB : B

doTwo

doOne

doThree

Fig. 15.2:communication diagram

: A

myB : B

1: doTwo

2: doThree

doOne

Sequence diagram notation

: Register : Sale

doA

doB

doX

doC

doD

typical sychronous message shown with a filled-arrow line

a found message whose sender will not be specified

execution specification bar indicates focus of control

Figure 15.7

Creation of Instances

: Register : Sale

makePayment(cashTendered)

: Paymentcreate(cashTendered)

authorize

note that newly created objects are placed at their creation "height"

Figure 15.10

Fig. 15.8 : How to show a return result ?

: Register : Sale

d1 = getDate

getDate

doX

aDate

Fig. 15.9: Messages to “self”

: Register

doX

clear

Fig. 15.11: Object destruction

: Sale

: Paymentcreate(cashTendered)

...the «destroy» stereotyped message, with the large X and short lifeline indicates explicit object destruction

«destroy» X

Conditional message : OPT frame is placed around one or more messages.

calculate

: Bar

yy

xx

[ color = red ]opt

: Foo

Figure 15.13

opt: Optional fragment that execute if guard is true

Conditional message : UML1.x notation

[ color = red ] calculate

: Bar

yy

xx

: Foo

Figure 15.14

Which one do you prefer?

Loops (iteration over a collection) in sequence diagrams:

Figure 15.16

st = getSubtotal

lineItems[i] :SalesLineItem

t = getTotal

[ i < lineItems.size ]loop

: Sale This lifeline box represents one instance from a collection of many SalesLineItem objects.

lineItems[i] is the expression to select one element from the collection of many SalesLineItems; the ‘i” value refers to the same “i” in the guard in the LOOP frame

an action box may contain arbitrary language statements (in this case, incrementing ‘i’)

it is placed over the lifeline to which it applies

i++

Loops (iteration over a collection) in sequence diagrams:

Figure 15.17

st = getSubtotal

lineItems[i] :SalesLineItem

t = getTotal

loop

: Sale

Which notation do you prefer?

Nesting of frames

25

How relate Interaction diagram?

26

Polymorphism:How is it shown in interaction diagrams?

27

Questions?

28

• Finish operation contracts for “ register vikingShip”

• Architecture Analysis

• use case design of “register VikingShip”That is : Open the black box “System” in the SSD from analysis and show how objects collaborate.

• Add method names to the classes.

Project work for today

Fig. 17.1 UP artifacts influencing OO design

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

d = getProductDescription(itemID)

addLineItem( d, quantity )

: Sale

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

SupplementarySpecification

Glossary

starting events to design for, and detailed post-condition to satisfy

Process Sale

1. Customer arrives ...2. ...3. Cashier enters item identifier.

inspiration for names of some software domain objects

functional requirements that must be realized by the objects

ideas for the post-conditions

Register

...

makeNewSale()enterItem(...)...

ProductCatalog

...

getProductDescription(...)...

1*

non-functional requirements

domain rules

item details, formats, validation

Introduction to Creator Pattern Problem: Who should be responsible for

creating a new instance of some class? Solution: Assign class B the responsibility to

create an instance of class A if one or more of these is true:• B contains (compositely aggregates) A.

• B records A.

• B closely uses A.

• B has the initializing data for A that will be passed to A when it is created.

Introduction to Controller Pattern Problem: What first object beyond the UI

layer receives and coordinates (“controls”) a system operation?

Solution: Assign the responsibility to a class that represents

1. the overall system, a “root” object, a device that the software is running within, or a major subsystem (a façade controller), or

2. a use case scenario within which the system event occurs (use case or session controller).

Fig. 17.8 System Sequence Diagram for Monopoly

Fig. 17.9 Who is Controller for playGame?