software engineering 1 object-oriented analysis and design applying uml and patterns an introduction...

Software Engineering1

Object-oriented Analysis and Design

Applying UML and Patterns

An Introduction to Object-oriented Analysis

and Design and Iterative Development

Part III Elaboration Iteration I – Basic3



Chap 18Object Design Examples with GRASP



Introduction

This chapter applies OO design principles and the UML to the case studies, to show larger examples of reasonably designed objects with responsibilities and collaborations.

ObjectiveDesign use case realizations.Apply GRASP to assign responsibilities to classes.Apply UML to illustrate and think through the design of

objects No "magic" is needed in object design



Use-case realization

A use-case realization describes how a particular use case is realized within the Design Model, in terms of collaborating objects" [RUP].

A designer can describe the design of one or more scenarios of a use case; each of these is called a use case realization

Use case realization is a UP term used to remind us of the connection between the requirements the object design

Some relevant artifact-influence points include the following: The use case suggests the system operations that are shown in

SSDs. The system operations become the starting messages entering

the Controllers for domain layer interaction diagrams. Domain layer interaction diagrams illustrate how objects

interact to fulfill the required tasks - the use case realization.



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



Communication diagrams and system operation handling

:RegisterenterItem

:RegisterendSale

:RegistermakePayment

1: ???

1: ???

1: ???

:RegistermakeNewSale 1: ???

makeNewSale, etc., are the system operations from the SSD

each major interaction diagram starts with a system operation going into a domain layer controller object, such as Register

DOMAIN LAYERUI LAYER

Window objects or

GUI widget objectsor

Web control objects

. . .



Sequence diagrams and system operation handling

: Register

: Sale

makeNewSalecreate

: Register

enterItem(...)

: ProductCatalog

desc = getProductDesc( itemID )

. . .

UI LAYER

Window objects or

GUI widget objectsor

Web control objects

. . .

DOMAIN LAYER



Operation Contract 1

Use case realizations could be designed directly from the use case text or from one's domain knowledge.

For some complex system operations, contracts may have been written that add more analysis detail. For example:



Operation Contract 2

1: makeLineItem(...)enterItem(id, qty)

1.1: create(...)

:Register :Sale

:SalesLineItem

In conjunction with contemplating the use case text, for each contract, we work through the postcondition state changes and design message interactions to satisfy the requirements



Use case realization with GRASP patterns.

'Start Up' Use Case Step

Design makeNewSale Design enterItem Design endSale Design makePayment Connect the UI Layer to the Domain Layer Create the Initialization Design Applications Start Up



'Start Up' Use Case

The Start Up use case realization is the design context in which to consider creating most of the 'root' or long-lived objects.

GuidelineWhen coding, program at least some Start Up initialization

first. But during OO design modeling, consider the Start Up

initialization design last, after you have discovered what really needs to be created and initialized.

Then, design the initialization to support the needs of other use case realizations



Design makeNewSale 1




Choosing the Controller Class Our first design choice involves choosing the controller for the

system operation message enterItem. By the Controller pattern, here are some choices:

Represents the overall "system," "root object," a specialized device, or a major subsystem.

Store a kind of root object because we think of most of the other domain objects as "within" the Store.Register a specialized device that the software runs on; also called a POSTerminal.POSSystem a name suggesting the overall system

Represents a receiver or handler of all system events of a use case scenario.

ProcessSaleHandler constructed from the pattern <use-case-name> "Handler" or "Session"ProcessSaleSession




:Register

makeNewSale

:Salecreate




Creating a New SaleWe must create a software Sale object, GRASP Creator pattern suggests assigning the

responsibility for creation to a class that aggregates, contains, or records the object to be created.

Register may be thought of as recording a Sale, Thus, Register is a reasonable candidate for creating a Sale.

By having the Register create the Sale, we can easily associate the Register with it over time so that during future operations within the session, the Register will have a reference to the current Sale instance.

When the Sale is created, it must create an empty collection (such as a Java List) to record all the future SalesLineItem instances that will be added.




:Register

makeNewSale

:Salecreate

Register creates a Sale by Creator

create lineItems :List<SalesLineItem>

by Creator, Sale creates an empty collection (such as a List) which will eventually hold SalesLineItem instances

by Creator and Controller

this execution specification is implied to be within the constructor of the Sale instance



Design enterItem 1



Design enterItem 2

Choosing the Controller Class Who can handle the responsibility for the system operation

message enterItem. Based on the Controller pattern, as for makeNewSale, we will

continue to use Register as a controller. Display Item Description and Price?

Because of a principle of Model-View Separation, it is not the responsibility of non-GUI objects (such as a Register or Sale) to get involved in output tasks.

Therefore, although the use case states that the description and price are displayed after this operation, we ignore the design at this time.

All that is required with respect to responsibilities for the display of information is that the information is known, which it is in this case.



Design enterItem 3

Creating a New SalesLineItem The enterItem contract postconditions indicate the creation,

initialization, and association of a SalesLineItem. Who create? Based on

Analysis of the Domain Model reveals that a Sale contains SalesLineItem objects.

Taking inspiration from the domain, we determine that a software Sale may similarly contain software SalesLineItem.

The postconditions indicate that the new SalesLineItem needs a quantity when created;

therefore, the Register must pass it along to the Sale, which must pass it along as a parameter in the create message.

In Java, that would be implemented as a constructor call with a parameter. Therefore, by Creator, a makeLineItem message is sent to a Sale for it

to create a SalesLineItem. The Sale creates a SalesLineItem, and then stores the new instance in its permanent collection.

The parameters to the makeLineItem message include the quantity, so that the SalesLineItem can record it, and the ProductDescription that matches the itemID.



Design enterItem 4

2: makeLineItem(desc, qty)enterItem(id, qty)

1: desc = getProductDesc(id) 2.1: create(desc, qty)

1.1: desc = get(id)

:Register :Sale

:ProductCatalog

sl: SalesLineItem

lineItems : List<SalesLineItem>

: Map<ProductDescription>

2.2: add(sl)

by Expert

by Controllerby Creator

add the newly created SalesLineItem instance to the List



Design enterItem 5

Other design issuesWho should be responsible for knowing a

ProductDescription, based on an itemID match?Start assigning responsibilities by clearly stating the

responsibility Who should send the getProductDescription message to

the ProductCatalog to ask for a ProductDescription For an object to send a message to another object, it must

have visibility to it.



Design enterItem 6

SalesLineItem

quantity : Integer

...

ProductCatalog

...

getProductDesc(...)

ProductDescription

description : Textprice : MoneyitemID: ItemID

...

1..*

1..*

Register

...

enterItem(...)...

Sale

isComplete : Booleantime : DateTime

makeLineItem(...)...1

1

1

catalog

currentSale

descriptions{Map}

lineItems{ordered}

description

Partial DCD related to the enterItem design. Static view



Design enterItem 7

The enterItem interaction diagram. Dynamic view



Design endSale 1

StepChoose the controller classSetting the Sale.isComplete Attribute Calculating the Sale Total Designing Sale.getTotal



Design endSale 2

Figure 18.9. Completion of item entry



Design endSale 3

Figure 18.10. Sale.getTotal interaction diagram



Design endSale 4

Figure 18.12. Showing a method in a note symbol



Design makePayment 1




Creating the Payment Guideline

When there are alternative design choices, take a closer look at the cohesion and coupling implications of the alternatives, and possibly at the future evolution pressures on the alternatives. Choose an alternative with good cohesion, coupling, and stability in the presence of likely future changes

Logging a Sale Calculating the Balance




1: makePayment(cashTendered)

1.1: create(cashTendered)

:Register :Sale

:Payment

makePayment(cashTendered)

by Controller by Creator and Low Coupling

Figure 18.13. Register.makePayment interaction diagram




Store

...

addSale(s : Sale)...

SalesLedger

...

addSale(s : Sale)...

Store is responsible for knowing and adding completed Sales.

Acceptable in early development cycles if the Store has few responsibilities.

SalesLedger is responsible for knowing and adding completed Sales.

Suitable when the design grows and the Store becomes uncohesive.

Sale

...

...

Sale

...

...

Logs-completed Logs-completed

* *

1 1

Figure 18.14. Who should be responsible for knowing the completed sales?




1: makePayment(cashTendered)

1.1: create(cashTendered)

:Register s :Sale

:Payment

makePayment(cashTendered)

:Store

2: addSale(s)

completedSales: List<Sale>

2.1: add(s)

by Expert

note that the Sale instance is named's' so that it can be referenced as a parameter in messages 2 and 2.1

Figure 18.15. Logging a completed sale




s :Sale pmt: Payment1: amt = getAmountbal = getBalance

2: t = getTotal

{ bal = pmt.amount - s.total }

Figure 18.16. Sale.getBalance interaction diagram




SalesLineItem

quantity : Integer

getSubtotal()

ProductCatalog

...

getProductDesc(...)

ProductDescription

description : Textprice : MoneyitemID: ItemID

...

Store

address : Addressname : Text

addCompleteSale(...)

Payment

amount : Money

...

1..*

1..*

Register

...

endSale()enterItem(...)makeNewSale()makePayment(...)

Sale

isComplete : Booleantime : DateTime

becomeComplete()makeLineItem(...)makePayment(...)getTotal()

1

1

1

1

1

1

*

catalog

catalog

register

currentSale

descriptions{Map}

lineItems{ordered}

payment

completedSales{ordered}

description

Figure 18.17. A more complete DCD reflecting most design decisions



Connect the UI Layer to the Domain Layer 1

Common designs by which objects in the UI layer obtain visibility to objects in the domain layer include the following:

An initializer object (for example, a Factory object) called from the application starting method (e.g., the Java main method) creates both a UI and a domain object and passes the domain object to the UI.

A UI object retrieves the domain object from a well-known source, such as a factory object that is responsible for creating domain objects.

Once the UI object has a connection to the Register instance (the facade controller in this design), it can forward system event messages, such as the enterItem and endSale message, to it



Connect the UI Layer to the Domain Layer 2

:Register

Cashier

:ProcessSaleJFrame

actionPerformed( actionEvent )

1: enterItem(id, qty) system event

UILayer

DomainLayer

presses button

Figure 18.18. Connecting the UI and domain layers.



Initialization and the 'Start Up' Use Case

When to Create the Initialization Design?Guideline: Do the initialization design last.

How do Applications Start Up?

public class Main { public static void main( String[] args ) { // Store is the initial domain object. // The Store creates some other domain objects. Store store = new Store(); Register register = store.getRegister(); ProcessSaleJFrame frame = new ProcessSaleJFrame( register ); ... } }



:Store :Register

pc:ProductCatalog

create 2: create(pc)

1: create

1.2: loadProdSpecs()

descriptions:Map<ProductDescription>

1.1: create

1.2.2*: put(id, pd)

1.2.1*: create(id, price, description)

pd:ProductDescriptionthe * in sequence number indicates the

message occurs in a repeating section

pass a reference to the ProductCatalog to the Register, so that it has permanent visibility to it

by Creatorcreate an empty collection object



Use Case Realizations for the Monopoly Iteration 1

Choosing the Controller Class Choosing a root-object facade controller like

MonopolyGame is satisfactory if there are only a few system operations (there are only two in this use case) and if the facade controller is not taking on too many responsibilities (in other words, if it is not becoming incohesive).

Who is Responsible for Controlling the Game Loop By Expert, MonopolyGame is a justifiable choice to

control the game loop and coordinate the playing of each round.



Figure 18.21. Iteration-1 Domain Model for Monopoly



Figure 18.22. Applying Controller to the playGame system operation.



Figure 18.23. Game loop




Who Takes a Turn Again, Expert applies Naive reaction might be to say "a Player object should

take the turn" because in the real world a human player takes a turn.

This is an interesting problem! There are three partial information experts for the "take a turn" responsibility: Player, MonopolyGame, and Board.




Who Takes a Turn (conti.) Guideline: When there are multiple partial information experts

to choose from, place the responsibility in the dominant information expert - the object with the majority of the information. This tends to best support Low Coupling.

Guideline: When there are alternative design choices, consider the coupling and cohesion impact of each, and choose the best.

Guideline: When there is no clear winner from the alternatives other guidelines, consider probable future evolution of the software objects and the impact in terms of Information Expert, cohesion, and coupling.

In the end, by these guidelines Player turns out to be a good candidate, justified by Expert when we consider the full game rules.




Figure 18.24. Player takes a turn by Expert




Figure 18.25. Dynamic design for playGame



The Command-Query Separation Principle

This principle states that every method should either be:a command method that performs an action (updating,

coordinating, …), often has side effects such as changing the state of objects, and is void (no return value); or

a query that returns data to the caller and has no side effects - it should not permanently change the state of any objects



Initialization and the 'Start Up' Use Case

Figure 18.27. Creation dependencies



Sample process and setting context

January February

WhenNear the beginning of each iteration, for a "short" period before programming.

WhereIn a project room with lots of support for drawing and viewing drawings.

WhoPerhaps developers will do some design work in pairs. The software architect will collaborate, mentor, and visit with different design groups.

How: ToolsSoftware: A UML CASE tool that can also reverse engineer diagrams from code.

Hardware: - Use two projectors attached to dual video cards.- For whiteboard drawings, perhaps a digital camera.- To print noteworthy diagrams for the entire team, a plotter for large-scale drawings to hang on walls.

DeveloperDeveloper

SoftwareArchitect

Two adjacent projections.

: R e g is te r

e n te r Ite m( ite mID , qu a n tity )

: Pro d u c tC ata log

s pe c := g e tSp ec ific a tio n ( itemID )

a dd L in e Ite m( s p e c , q u an tity )

: Sa le

. . .

mak e N e w Sa le ( )c r ea te ( )

. . .

: R e g is te r

en te r Item( ite mID , q u a n tity )

: Pr od uc tC a ta lo g

s pe c := g e tSpe c ific a tion ( ite mID )

ad dL ine Item( s p e c , q u a n tity )

: Sa le

. . .

ma k e N ew Sa le ( )c re a te ( )

. . .

SalesLineItem

quantity : Integer

getSubtotal()

Produc tCatalog

getSpec ific ation( )

ProductSpecification

des cr iption : Tex tpr ic e : MoneyitemID : ItemID

Store

addres s : Addres sname : Tex t

addSale( )

Payment

amount : Money

1..*

1..*

Regis ter

endSale( )enter Item()makeNewSale( )makePay ment( )

Sale

date : D ateisComplete : Booleantime : Time

bec omeComplete( )mak eLineItem( )mak ePayment()getTotal( )

1 1

1

1 1

1

11

1

1

1

1

1

*

*

1

whiteboards

software engineering 1 object-oriented analysis and design applying uml and patterns an introduction...

Documents

design introduction

design of objects

design chap

object design slide

object design examples

objectoriented analysis

oo design principles

design use case realizations