60-322 object-oriented analysis and design feb 9, 2009

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).


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.


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.


Feb 9, 2009 10


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.


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.


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).


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.


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.


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.


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.


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?


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.


Feb 9, 2009 28

Sequence diagrams illustrate interactions in a kind of fence format, in which each new object is added to the right:


: 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();

} // …

}


: 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).


: 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.


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);


Feb 9, 2009 34


Feb 9, 2009 35

Example Sequence Diagrams

: Register : Sale

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


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


: 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


Feb 9, 2009 49


calculate

: Bar

yy

xx

[ color = red ]opt

: Foo

[ color = red ] calculate

: Bar

yy

xx

: Foo

Feb 9, 2009 50


: B: A

calculate

doX

: C

calculate

[ x < 10 ]alt

[ else ]

Feb 9, 2009 51


st = getSubtotal

lineItems[i] :SalesLineItem

t = getTotal

loop

: Sale

60-322 object-oriented analysis and design feb 9, 2009

Documents

model domain objects

domain layer of objects

domain model slide

domain classes

nonui domain object

realworld domain

couple nonui objects

nonui elements