1 what to remember from chap 13 (logical architecture)
TRANSCRIPT
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?