Upload
toby-nelson
View
216
Download
2
Tags:
Embed Size (px)
Citation preview
60-322 Object-Oriented Analysis and Design
Feb 9, 2009
Feb 9, 2009 2
Logical Architecture and UML Package Diagram The logical architecture is the large-scale
organization of the software classes into packages (or namespaces), subsystems, and layers.
UML package diagrams are often used to illustrate the logical architecture of a system - the layers, subsystems, packages (in the Java sense), etc.
The responsibilities of the objects in a layer should be strongly related to each other and should not be mixed with responsibilities of other layers.
Domain Layer vs. Application Logic Layer; Domain Objects.
Last lecture covered….
Feb 9, 2009 3
The Relationship Between the Domain Layer and
Domain Model??
. We look to the domain model (which is a visualization of
noteworthy domain concepts) for inspiration for the names of classes in the domain layer
The domain layer is part of the software and the domain model is part of the conceptual-perspective analysis - they aren't the same thing.
– By creating a domain layer with inspiration from the domain model, we achieve a lower representational gap, between the real-world
domain, and our software design.
Relationship Between the Domain Layer and Domain Model
Feb 9, 2009 4
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 domain in creating software classes.
Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.
1 1
1 1
A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter.
This reduces the representational gap.
This is one of the big ideas in object technology.
inspires objects
and names in
Relationship Between the Domain Layer and Domain Model
Feb 9, 2009 5
Model is a synonym for the domain layer of objects (it's an old OO term from the late 1970s).
View is a synonym for UI objects, such as windows, Web pages, applets, and reports.
The Model-View Separation principle states that model (domain) objects should not have direct knowledge of view (UI) objects.
– For example, a Register or Sale object should not directly send a message to a GUI window object ProcessSaleFrame, asking it to display something, change color, close, and so forth.
The Model-View Separation Principle
Feb 9, 2009 6
This principle has at least two parts:– Do not connect or couple non-UI objects directly to UI
objects. – For example, don't let a Sale software object (a non-UI "domain"
object) have a reference to a Java Swing JFrame window object.– Why? – Because the windows are related to a particular application, while
(ideally) the non-windowing objects may be reused in new applications or attached to a new interface.
– Do not put application logic (such as a tax calculation) in the UI object methods.
– UI objects should only initialize UI elements, receive UI events (such as a mouse click on a button), and delegate requests for application logic on to non-UI objects (such as domain objects).
The Model-View Separation Principle
Feb 9, 2009 7
The domain classes encapsulate the information and behavior related to application logic.
The window classes are relatively thin; they are responsible for input and output, and catching GUI events, but do not maintain application data or directly provide application logic.
For example, a Java JFrame window should not have a method that does a tax calculation. A Web JSP page should not contain logic to calculate the tax. These UI elements should delegate to non-UI elements for such responsibilities.
The Model-View Separation Principle
Feb 9, 2009 8
During analysis work, we sketched some SSDs for use case scenarios.
We identified input events from external actors into the system, calling upon system operations such as makeNewSale and enterItem.
The SSDs illustrate these system operations, but hide the specific UI objects. Nevertheless, normally it will be objects in the UI layer of the system that capture these system operation requests, usually with a rich client GUI or Web page.
The Connection Between SSDs, System Operations, and Layers
Feb 9, 2009 9
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.
The messages sent from the UI The messages sent from the UI layer to the domain layer will be the layer to the domain layer will be the messages illustrated on the SSDs, messages illustrated on the SSDs, such as enterItem.such as enterItem.
The Connection Between SSDs, System Operations, and Layers
Feb 9, 2009 10
The Connection Between SSDs, System Operations, and Layers
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 the operation calls on the Application or Domain layer from the UI layer
Feb 9, 2009 11
We are on our way to designing collaborating objects to fulfill project requirement.
How do you design objects?– Code
Design-while-coding (Java, C#, …). From mental model to code.
– Draw, then code Drawing some UML on a whiteboard or UML CASE tool, then switching to
#1 with a text-strong IDE (e.g., Eclipse or Visual Studio).
– Only draw Somehow, the tool generates everything from diagrams. Many a dead tool
vendor has washed onto the shores of this steep island. "Only draw" is a misnomer, as this still involves a text programming language attached to UML graphic elements.
Ch 14 On to Object Design
Feb 9, 2009 12
If we use Draw, then code (the most popular approach with UML), the drawing overhead should be worth the effort.
This chapter introduces object design and lightweight drawing before coding, suggesting ways to make it pay off.
Ch 14 On to Object Design
Feb 9, 2009 13
How Much Time Spent Drawing UML Before Coding?
Guideline For a three-week timeboxed iteration, spend a few hours
or at most one day (with partners) near the start of the iteration "at the walls" (or with a UML CASE tool) drawing UML for the hard, creative parts of the detailed object design.
Then stop - and if sketching-perhaps take digital photos, print the pictures, and transition to coding for the remainder of the iteration, using the UML drawings for inspiration as a starting point, but recognizing that the final design in code will diverge and improve.
Shorter drawing/sketching sessions may occur throughout the iteration.
Ch 14 On to Object Design
Feb 9, 2009 14
There are two kinds of object models: dynamic and static.
Dynamic models,– Such as UML interaction diagrams (sequence
diagrams or communication diagrams), help design the logic, the behavior of the code or the method bodies. They tend to be the more interesting, difficult,
important diagrams to create.
Designing Objects: Static and Dynamic Modeling
Feb 9, 2009 15
Static models, such as UML class diagrams, help design the definition of packages, class names, attributes, and method signatures (but not method bodies).
Designing Objects: Static and Dynamic Modeling
Feb 9, 2009 16
There's a relationship between static and dynamic modeling and the agile modeling practice of create models in parallel:
– Spend a short period of time on interaction diagrams (dynamics), then switch to a wall of related class diagrams (statics).
People new to UML tend to think that the important diagram is the static-view class diagram, but in fact, most of the challenging, interesting, useful design work happens while drawing the UML dynamic-view interaction diagrams.
Designing Objects: Static and Dynamic Modeling
Feb 9, 2009 17
It's during dynamic object modeling (such as drawing sequence diagrams) that "the rubber hits the road" in terms of really thinking through the exact details of what objects need to exist and how they collaborate via messages and methods.
Therefore, we start by introducing dynamic object modeling with interaction diagrams.
Guideline:– Spend significant time doing interaction diagrams
(sequence or communication diagrams), not just class diagrams.
Ignoring this guideline is a very common worst-practice with UML.
Designing Objects: Static and Dynamic Modeling
Feb 9, 2009 18
Note that it's especially during dynamic modeling that we apply responsibility-driven design and the GRASP principles (Ch 17 and 18). The subsequent chapters focus on these key topics of the book and key skills in OO design.
Designing Objects: Static and Dynamic Modeling
Feb 9, 2009 19
The most common static object modeling is with UML class diagrams.
After first covering dynamic modeling with interaction diagrams, we introduce the details.
Note, though, that if the developers are applying the agile modeling practice of Create several models in parallel, they will be drawing both interaction and class diagrams concurrently.
Designing Objects: Static and Dynamic Modeling
Feb 9, 2009 20
The following chapters explore detailed object design while applying UML diagrams.
It's been said before, but is important to stress:
– What's important is knowing how to think and design in objects, and apply object design best-practice patterns,
– which is a very different and much more valuable skill than knowing UML notation.
Ch 14
Feb 9, 2009 21
While drawing a UML object diagram, we need to answer key questions:
– What are the responsibilities of the object? – Who does it collaborate with? – What design patterns should be applied?
Far more important than knowing the difference between UML 1.4 and 2.0 notation!
Therefore, the emphasis of the following chapters is on these principles and patterns in object design.
Ch 14
Feb 9, 2009 22
Object Design Skill vs. UML Notation Skill Drawing UML is a reflection of making
decisions about the design.
The object design skills are what matter, not knowing how to draw UML. Fundamental object design requires knowledge of:
– principles of responsibility assignment– design patterns
Ch 14
Feb 9, 2009 23
A popular text-oriented modeling technique is Class Responsibility Collaboration (CRC) cards.
CRC cards are paper index cards on which one writes the responsibilities and collaborators of classes.
Each card represents one class.
A CRC modeling session involves a group sitting around a table, discussing and writing on the cards as they play "what if" scenarios with the objects, considering what they must do and what other objects they must collaborate with.
Ch 14 Other Object Design Techniques: CRC Cards
Feb 9, 2009 24
Ch 14 Other Object Design Techniques: CRC Cards
Feb 9, 2009 25
Objectives Provide a reference for frequently used UML
interaction diagram notation - sequence and communication diagrams.
Note this chapter does not discuss object design, wait until Chapter 17
Ch 15 UML Interaction Diagrams
Feb 9, 2009 26
The UML includes interaction diagrams to illustrate how objects interact via messages.
They are used for dynamic object modeling.
There are two common types: sequence diagrams. communication diagrams.
This chapter introduces the notations only.
Subsequent chapters focus on a more important question: What are key principles in OO design?
Ch 15 UML Interaction Diagrams
Feb 9, 2009 27
Both can express similar interactions.
Sequence diagrams are the more notationally rich of the two types, but communication diagrams have their use as well, especially for wall sketching.
Ch 15 UML Interaction Diagrams
Feb 9, 2009 28
Sequence diagrams illustrate interactions in a kind of fence format, in which each new object is added to the right:
Ch 15 UML Interaction Diagrams
: A myB : B
doTwo
doOne
doThree
What might this represent in code?
Probably, that class A has a method named doOne and an attribute of type B.
Also, that class B has methods named doTwo and doThree.
Perhaps the partial definition of class A is:
Feb 9, 2009 29
public class A
{
private B myB = new B();
public void doOne()
{
myB.doTwo();
myB.doThree();
} // …
}
Ch 15 UML Interaction Diagrams
: A myB : B
doTwo
doOne
doThree
Feb 9, 2009 30
Communication diagrams illustrate object interactions in a graph or network format, in which objects can be placed anywhere on the diagram (the essence of their wall sketching advantage).
Ch 15 UML Interaction Diagrams
: A
myB : B
1: doTwo
2: doThree
doOne
Feb 9, 2009 31
Each diagram type has advantages, and modelers have idiosyncratic preference - there isn't an absolutely "correct" choice.
However, UML tools usually emphasize sequence diagrams, because of their greater notational power.
Sequence diagrams have some advantages over communication diagrams.
– Perhaps first and foremost, the UML specification is more sequence diagram centric- more thought and effort has been put into the notation and semantics.
Sequence v. Communication Diagrams
Feb 9, 2009 32
– It is easier to see the call-flow sequence with sequence diagrams - simply read top to bottom.
– With communication diagrams we must read the sequence numbers, such as "1:" and "2:".
– Hence, sequence diagrams are excellent for documentation or to easily read a reverse-engineered call-flow sequence, generated from source code with a UML tool.
Sequence v. Communication Diagrams
Feb 9, 2009 33
On the other hand, communication diagrams have advantages when applying "UML as sketch" to draw on walls (an Agile Modeling practice) because they are much more space-efficient.
– modifying wall sketches is easier with communication diagrams - it is simple.
– In contrast, new objects in a sequence diagrams must always be added to the right edge, which is limiting as it quickly consumes and exhausts right-edge space on a page (or wall);
Sequence v. Communication Diagrams
Feb 9, 2009 34
Sequence v. Communication Diagrams
Feb 9, 2009 35
Example Sequence Diagrams
: Register : Sale
makePayment(cashTendered)
makePayment(cashTendered)
: Paymentcreate(cashTendered)
The sequence diagram shown above is read as follows:
1. The message makePayment is sent to an instance of a Register. The sender is not identified.
2. The Register instance sends the makePayment message to a Sale instance.
3. The Sale instance creates an instance of a Payment
public class Sale { private Payment payment;
public void makePayment( Money cashTendered ) { payment = new Payment( cashTendered );
//… } // …
} `
Feb 9, 2009 36
Example Sequence Diagrams
Register
id
ItemStore
nameaddress
Sale
dateTime/ total
CashPayment
amountTendered
SalesLineItem
quantity
Cashier
id
Customer
ProductCatalog
ProductDescription
itemIDdescriptionprice
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Records-sale-of
0..1
Paid-by Is-for
Logs-completed
*
Works-on
1
1
1
1 1..*
1
1
1
1
1
1
1
0..1 1
1
Ledger
Records-accounts-
for
1
1
Feb 9, 2009 37
Example Communication Diagrams
1: makePayment(cashTendered)
1.1: create(cashTendered)
:Register :Sale
:Payment
makePayment(cashTendered)
direction of message
•Most UML novices are aware of class diagrams and usually think they are the only important diagram in OO design. Not true!
•Although the static-view class diagrams are indeed useful, the dynamic-view interaction diagrams, or more precisely, acts of dynamic interaction modeling, are incredibly valuable.
•Spend time doing dynamic object modeling with interaction diagrams, not just static object modeling with class diagrams
Feb 9, 2009 38
Illustrating Participants with Lifeline Boxes
Common UML Interaction Diagram Notation
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
Feb 9, 2009 39
Interaction diagrams show messages between objects; the UML has a standard syntax for these message expressions:
return = message(parameter : parameterType) : returnType
Parentheses are usually excluded if there are no parameters, though still legal.
Type information may be excluded if obvious or unimportant.
Basic Message Expression Syntax
Feb 9, 2009 40
For example:– initialize(code) – initialize – d = getProductDescription(id) – d = getProductDescription(id:ItemID) – d = getProductDescription(id:ItemID) :
ProductDescription
Basic Message Expression Syntax
Feb 9, 2009 41
Sometimes, there is only one instance of a class instantiated, never two.
In other words, it is a "singleton" instance. In a UML interaction diagram (sequence or
communication), such an object is marked with a '1' in the upper right corner of the lifeline box
Singleton Object
: Register1
: Store
doAdoX
the ‘1’ implies this is a Singleton, and accessed via the Singleton pattern
All these notations apply to both kinds of interaction diagrams.
Feb 9, 2009 42
Lifeline Boxes and Lifelines In contrast to communication diagrams, in sequence
diagrams the lifeline boxes include a vertical line extending below them- these are the actual lifelines.
Although virtually all UML examples show the lifeline as dashed (because of UML 1 influence), in fact the UML 2 specification says it may be solid or dashed.
Basic Sequence Diagram Notation
Feb 9, 2009 43
Messages, Focus Control and Execution Spec. Bar Basic 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
Feb 9, 2009 44
Illustrating Reply or Returns Basic Sequence Diagram Notation
There are two ways to show the return result from a message:
Using the message syntax returnVar = message(parameter). Using a reply (or return) message line at the end of an
execution spec. bar.
: Register : Sale
d1 = getDate
getDate
doX
aDate
Feb 9, 2009 45
Message to “self” or “this” Basic Sequence Diagram Notation
You can show a message being sent from an object to itself by using a nested Exec. Spec. bar
: Register
doX
clear
Feb 9, 2009 46
Creation of Instance Basic Sequence Diagram Notation
The typical interpretation (in languages such as Java or C#) of a create message on a dashed line with a filled arrow is "invoke the new operator and call the constructor".
: Register : Sale
makePayment(cashTendered)
: Paymentcreate(cashTendered)
authorize
note that newly created objects are placed at their creation "height"
Feb 9, 2009 47
Diagram Frames in UML Sequence Diagram Basic Sequence Diagram Notation
To support conditional and looping constructs (among many other things), the UML uses frames.
Frames are regions or fragments of the diagrams; they have an operator or label (such as loop) and a guard(conditional clause).
enterItem(itemID, quantity)
: B
endSale
a UML loop frame, with a boolean guard expression description, total
makeNewSale
[ more items ]loop
: A
Feb 9, 2009 48
Diagram Frames in UML Sequence Diagram Basic Sequence Diagram Notation
Feb 9, 2009 49
Diagram Frames in UML Sequence Diagram Basic Sequence Diagram Notation
calculate
: Bar
yy
xx
[ color = red ]opt
: Foo
[ color = red ] calculate
: Bar
yy
xx
: Foo
Feb 9, 2009 50
Diagram Frames in UML Sequence Diagram Basic Sequence Diagram Notation
: B: A
calculate
doX
: C
calculate
[ x < 10 ]alt
[ else ]
Feb 9, 2009 51
Diagram Frames in UML Sequence Diagram Basic Sequence Diagram Notation
st = getSubtotal
lineItems[i] :SalesLineItem
t = getTotal
loop
: Sale