05-ObjectDesign

7/28/2019 05-ObjectDesign

1/76

Object Oriented Analysis and DesignObject Design

Paul Janecek

Computer Science and Information ManagementAsian Institute of Technology

Paul Janecek (CSIM-AIT) Object Design 1 / 76
http://find/


2/76

Readings

Readings for these lecture notes:

- Larman (2005), Applying UML and Patterns: An Introduction to

Object-Oriented Analysis and Design and Iterative Development, 3rdedition, Chapters 1416.

Some material c Larman (2005).

http://find/


3/76

Outline

1 Object design

2 UML interaction diagrams

3 Design class diagrams

http://find/


4/76

Object designIntroduction

We have three basic approaches to designing objects:

Just code, with refactoring as needed.

Draw then code, using UML on the whiteboard or in a CASE tool

followed by coding in an IDE like Eclipse or Visual Studio.Only draw then let the CASE tool write the code.

Draw then code is the most popular method in practice. We should use alightweight drawing approach to avoid analysis paralysis.

For a 3-week iteration, we will spend a few hours to at most a day onobject design.

http://find/


5/76

Object designStatic and dynamic analysis

Object design uses two kinds of models:

Dynamic models use interaction diagrams to characterize application

logic, behavior, and method bodies.Static models use class diagrams to characterize the static (logical)structure.

Dynamic models are the most difficult, most interesting, and most

important models.

http://find/


6/76

Object designStatic and dynamic analysis

Example of both kinds:

Larman (2005), Fig. 14.1

http://find/http://goback/


7/76

Object designObject design guidelines

Guidelines for object design:

Spend more time on interaction diagrams (sequence, communication)than on class diagrams.

Where appropriate, use state machines and activity diagrams fordynamic behavior.

Design the static model (mainly class diagrams, secondarily packageand deployment diagrams) together with the dynamic model.

Focus on the objects, responsibility assignment, and design patterns,not UML syntax!

http://find/


8/76

Object designAlternative approaches

One alternative to visual modeling is CRC (Class ResponsibilityCollaboration) card analysis.

The method uses index cards or sticky notes on a table or whiteboard.Example of a CRC card:

Larman (2005), Fig. 14.2

http://find/


9/76

Object designAlternative approaches

Examples showing the level of detail expected:

Larman (2005), Fig. 14.3

http://find/


10/76

Outline

1 Object design



http://find/


11/76

UML interaction diagramsIntroduction

For dynamic modeling in design, the main tools are sequence diagrams andcommunication diagrams.

Remember that dynamic object modeling is more important than staticmodeling.

Much of the static model can be easily derived from a few interactiondiagrams.



12/76

UML interaction diagramsExample sequence diagram

A basic sequence diagram:

: A myB : B

doTwo

doOne

doThree

Larman (2005), Fig. 15.1

http://find/


13/76

UML interaction diagramsExample communication diagram

A basic (equivalent) communication diagram:

: A

myB : B

1: doTwo

2: doThree

doOne

Larman (2005), Fig. 15.2

Sequence diagrams are more explicit about ordering of events, butcommunication diagrams make better use of space.



14/76

UML interaction diagramsExample sequence and communication diagrams

Another example of a sequence diagram and equivalent communicationdiagram:

: Register : Sale

makePayment(cashTendered)


: Paymentcreate(cashTendered)

Larman (2005), Fig. 15.3

http://find/


15/76

UML interaction diagramsExample sequence and communication diagrams

Equivalent communication diagram:

1: makePayment(cashTendered)

1.1: create(cashTendered)

:Register :Sale

:Payment


direction of message

Larman (2005), Fig. 15.4

http://find/


16/76

UML interaction diagramsNotation for sequence diagrams

Sequence diagrams are structured by lifeline boxes and messages.

Lifelines usually but not always represent object instance lifetimes.

sales:ArrayLi st

:Sale s1 : Sale

lifeline box representing aninstance of anArrayList class,parameterized (templatized) tohold Sale objects

lifeline box representing anunnamed instance of class Sale

lifeline box representing anamed instance

sales[ i ] : Sale

lifeline box representingone instance of class Sale,selected from the sales

ArrayList collection

x : List

metaclass

Font

lifeline box representing the classFont, or more precisely, that Font isan instance of class Class aninstance of a metaclass

relatedexample

List is an interface

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

Larman (2005), Fig. 15.5


I i di
http://find/


17/76

Interaction diagramsNotation for sequence diagrams

Messages have the form

return = message( parameter: parameterType ) : returnType

Language-specific syntax is also acceptable.


I i di
http://find/


18/76

Interaction diagramsExamples of sequence diagrams

Singleton objects

Sometimes only a single instance of an class is required for an entireapplication.

The Singleton pattern (GoF) makes the single instance accessible globally

through a class method for the objects class.

In UML, singleton objects are denoted with the number 1:

: Register1

: Store

doAdoX

the 1 implies this is a

Singleton, and accessedvia the Singleton pattern

Larman (2005), Fig. 15.6


I i di
http://find/


19/76


Synchronous messages are denoted by a filled arrowhead:

: Register : Sale

doA

doB

doX

doC

doD

typical sychronous messageshown with a filled-arrow line

a found messagewhose sender will notbe specified

execution specification

bar indicates focus ofcontrol

Larman (2005), Fig. 15.7


I t ti di
http://find/


20/76


There are two ways to show a return from a message:

: Register : Sale

d1 = getDate

getDate

doX

aDate

Larman (2005), Fig. 15.8


I t ti di
http://goforward/http://find/http://goback/


21/76


Messages to self or this are shown like this:

: Register

doX

clear

Larman (2005), Fig. 15.9


Interaction diagrams
http://find/


22/76


Instance creation is shown with a dashed line:

: Register : Sale



authorize

note that newly createdobjects are placed at theircreation "height"

Larman (2005), Fig. 15.10




23/76


Instance destruction:

: Sale


...the destroy stereotypedmessage, with the largeX and short lifelineindicates explicit objectdestruction

destroyX

Larman (2005), Fig. 15.11


http://find/


24/76


For looping, conditionals, and so on, we use diagram frames.

alt is used for case-like behavior

loop is used for indexed loops or loops over collectionsopt is only executed if the guard condition is true

par indicates execution in parallel

region indicates a critical region with mutual exclusion between

threads


http://find/


25/76


Example loop:

enterItem(itemID, quantity)

: B

endSale

a UML loopframe, with aboolean guardexpression description, total

makeNewSale

[ more items ]loop

: A

Larman (2005), Fig. 15.12


http://find/


26/76


Example opt:

calculate

: Bar

yy

xx

[ color =red ]opt

: Foo

Larman (2005), Fig. 15.13


http://find/


27/76


Example conditional message (UML 1 style):

[ color =red ] calculate

: Bar

yy

xx

: Foo

Larman (2005), Fig. 15.14

Most CASE tools still support conditional messages. They are compactand lightweight. Recommended when modeling by hand.


http://find/


28/76


Example alt:

: B: A

calculate

doX

: C

calculate

[ x < 10 ]alt

[ else ]

Larman (2005), Fig. 15.15


http://find/


29/76


Example loop over a collection:

st =getSubtotal

lineItems[i] :SalesLineItem

t =getTotal

[ i < lineItems.size ]loop

: Sale This lifeline box represents oneinstance from a collection of many

SalesLineItem objects.

lineItems[i] is the expression toselect one element from thecollection of manySalesLineItems; the i valuerefers to the same i in the guardin the LOOP frame

anaction box may contain arbitrary languagestatements (in this case, incrementing i)

it is placed over the lifeline to which it applies

i++

Larman (2005), Fig. 15.16


http://find/


30/76


Example implicit loop over a collection:

st =getSubtotal

lineItems[i] :SalesLineItem

t =getTotal

loop

: Sale

Larman (2005), Fig. 15.17


http://find/


31/76


Diagram frame nesting is legal:

calculate

: Bar

xx

[ color =red ]opt

: Foo

loop(n)

Larman (2005), Fig. 15.18


http://find/


32/76

gExamples of sequence diagrams

Use ref to refer to separate diagrams:

interaction occurrence

note it covers a set of lifelines

note that the sd frame it relates to

has the same lifelines: B and C

doA

: A : B : C

doB

sd AuthenticateUser

refAuthenticateUser

authenticate(id)

doX

doM1

: B : C

authenticate(id)

doM2

refDoFoo

sd DoFoo

doX

: B : C

doY

doZ

Larman (2005), Fig. 15.19Paul Janecek (CSIM-AIT) Object Design 32 / 76

http://find/


33/76


Invoking static (class) methods:

1: locs =getAvailableLocales: Foo

metaclass

Calendar

doX

message to class, or astatic method call

Larman (2005), Fig. 15.20

The metaclass keyword indicates that the Calendar lifeline represents

an instance of class Class.


http://find/


34/76


Sequence diagrams with polymorphic methods:

:Register

authorize

doX

:Payment {abstract}

polymorphic messageobject in role of abstractsuperclass

:DebitPayment

doA

authorize

:Foo

stop at this point dont show anyfurther details for this message

doB

:CreditPayment

doX

authorize

:Bar

Payment {abstract}

authorize() {abstract}...

CreditPayment

authorize()...

DebitPayment

authorize()...

Payment is an abstractsuperclass, with concretesubclasses that implement thepolymorphic authorize operation

separate diagrams for each polymorphic concrete case

Larman (2005), Fig. 15.21


http://find/


35/76


Asynchronous messages use a line-style arrow, and active classes (withtheir own thread) are indicated by a special lifeline box:

:ClockStarter

:Clock

run

startClock

create

a stick arrow in UML implies an asynchronous call

a filled arrow is the more common synchronous call

In J ava, for example, an asynchronous call may occur as

follows:

// Clock implements the Runnable interfaceThread t =new Thread( new Clock() );t.start();

the asynchronous start call always invokes the run methodon the Runnable (Clock) object

to simplify the UML diagram, theThread

object and thestart message may be avoided (they are standardoverhead); instead, the essential detail of the Clockcreation and the run message imply the asynchronous call

runFinalization

System :Class

activeobject

Larman (2005), Fig. 15.22


http://find/


36/76

Example communication diagram

Example of a basic communication diagram:

1: makePayment(cashTendered)2: foo

2.1: bar

: Register :Sale

link line

Larman (2005), Fig. 15.23




37/76

Communication diagram notation

Messages are passed along links.

There is only one link between any two lifeline boxes:

1: msg22: msg33: msg4

3.1: msg5

: Register :Sale

all messages flow on the same link

msg1

Larman (2005), Fig. 15.24




38/76

Examples of communication diagrams

Messages to this:

: Register

msg1

1: clear

Larman (2005), Fig. 15.25


http://find/


39/76


Instance creation:

1: create(cashier)

: Register :Sale

create message, with optional initializing parameters. This willnormally be interpreted as a constructor call.

create1: make(cashier)

: Register :Sale

if an unobvious creation message name is used, themessage may be stereotyped for clarity

1: create(cashier)

: Register :Sale {new}

Three ways to show creation in acommunication diagram

Larman (2005), Fig. 15.26


http://find/


40/76


Sequence numbers are used to indicate message order:

: Amsg1

: B1: msg2

: C

1.1: msg3not numbered

legal numbering

Larman (2005), Fig. 15.27


http://find/


41/76


Complex sequence numbering:

: Amsg1

: B1: msg2

: C

1.1: msg3

2.1: msg5

2: msg4

: D

2.2: msg6

first second

fourth

sixth

fifth

third

Larman (2005), Fig. 15.28


http://find/


42/76


Conditional messages:

1 [ color = red ] : calculate: Foo : Bar

message1

conditional message, with test

Larman (2005), Fig. 15.29


Interaction diagramsE l f i i di
http://find/


43/76


Mutually exclusive paths:

1a[test1] : msg2

: A : B

: C

1a.1: msg3

msg1

: D

1b[not test1] : msg4

1b.1: msg5

: E

2: msg6

unconditional aftereither msg2 or msg4 1a and 1b are mutually

exclusive conditional paths

Larman (2005), Fig. 15.30


Interaction diagramsE l f i i di
http://find/


44/76


Iteration:

1 * [ i = 1..n ]: num =nextInt: Simulator

runSimulation: Random

iteration is indicated with a * and an optionaliteration clause following the sequence number

Larman (2005), Fig. 15.31


Interaction diagramsE l f i ti di


45/76


Iteration over a collection:

1 * [i =1..n]: st =getSubtotal: Sale

t =getTotal

This lifeline box represents one instance from acollection of manySalesLineItemobjects.

lineItems[i] is the expression to select oneelement from the collection of manySalesLineItems; the i value comes from themessage clause.

lineItems[i]:SalesLineItem

this iteration and recurrence clause indicateswe are looping across each element of thelineItems collection.

1 *: st =getSubtotal: Sale

t =getTotal lineItems[i]:SalesLineItem

Less precise, but usually good enough to implyiteration across the collection members

Larman (2005), Fig. 15.32


Interaction diagramsExamples of communication diagrams
http://find/


46/76


Messages to class objects:

1: locs =getAvailableLocales: Foo

metaclass

Calendar

doX

message to class, or astatic method call

Larman (2005), Fig. 15.33


http://find/


47/76


Polymorphism:

:RegisterauthorizedoX

:Payment {abstract}

polymorphic message

object in role of abstractsuperclass

:DebitPayment

authorize

:Foo

stop at this point dont show anyfurther details for this message

separate diagrams for each polymorphic concrete case

doAdoB

:CreditPayment

authorize

:BardoX

Larman (2005), Fig. 15.34




48/76


Asynchronous messages and active objects:

3: runFinalization:ClockStarter System : Class

startClock

:Clock

1: create

2: run

asynchronous message

active object

Larman (2005), Fig. 15.35


Outline
http://find/


49/76

1 Object design




Design class diagramsIntroduction
http://find/


50/76

Introduction

Design class diagrams (DCDs) indicate static structure of the software.

java.awt::Fontor

java.awt.Font

plain : Int =0 {readOnly }bold : Int =1 {readOnly }name : Stringstyle : Int =0

...

getFont(name : String) : F ontgetName() : String...

interfaceRunnable

run()

- ellipsis means there may be elements, but not shown- a blank compartment officially means unknown but as aconvention will be used to mean no members

SubclassFoo

...

run()...

SuperclassFoo

orSuperClassFoo {abstract }

- classOrStaticAttribute : Int+publicAttribute : String- privateAttributeassumedPrivateAttributeisInitializedAttribute : Bool = trueaCollection : VeggieBurger [ * ]attributeMayLegallyBeNull : String [0..1]finalConstantAttribute : Int =5 {readOnly }/derivedAttribute

+classOrStaticMethod()+publicMethod()

assumedPublicMethod()- privateMethod()#protectedMethod()~packageVisibleMethod()constructor SuperclassFoo( Long )methodWithParms(parm1 : String, parm2 : Float)methodReturnsSomething() : VeggieBurgermethodThrowsException() {exception IOException}abstractMethod()abstractMethod2() {abstract } // alternatefinalMethod() {leaf } // no override in subclasssynchronizedMethod() {guarded }

3 commoncompartments

1. classifier name

2. attributes

3. operations

interfaceimplementation

andsubclassing

Fruit

...

...

PurchaseOrder

...

...

1

association withmultiplicities

dependency

officially in UML, the top format isused to distinguish the packagename from the class name

unofficially, the second alternativeis common

order

an interfaceshown with akeyword

Larman (2005), Fig. 16.1


Design class diagramsDesign classes vs. domain classes
http://find/


51/76

Design classes vs. domain classes

Design classes will often derive from domain/analysis classes:

Register

...

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

Sale

timeisComplete : Boolean/total

makeLineItem(...)

Register

...

Sale

timeisComplete : Boolean/total

Captures

1

11

Domain Model

conceptualperspective

Design Model

DCD; softwareperspective

currentSale

Larman (2005), Fig. 16.2

Generally, the Design Model contains interaction diagrams, DCDs, andpackage diagrams.


Design class diagramsAttributes
http://find/


52/76

Attributes are shown in text notation, via an association line, or even bothtogether:

Register

...

...

Sale

...

...

1

Register

currentSale : Sale

...

Sale

...

...

using the attributetext notation toindicate Register hasa reference to oneSale instance

using the association notation to indicateRegister has a reference to one Sale instance

OBSERVE: this stylevisually emphasizesthe connectionbetween these classes

currentSale

Register

currentSale : Sale

...

Sale

...

...

1thorough andunambiguous, but somepeople dislike thepossible redundancy

currentSale

Larman (2005), Fig. 16.3


Design class diagramsAttributes
http://find/


53/76

The full attribute notation is

visibility name : type multiplicity = default [property-string]

As for messages, programming language-specific syntax is also OK.

Visibility is + (public), - (private), # (protected), or ~ (package). If novisibility is given we assume the attribute is private.


Design class diagramsAssociations and attributes
http://localhost/var/www/apps/conversion/tmp/scratch_12/~http://localhost/var/www/apps/conversion/tmp/scratch_12/~http://find/


54/76

DCDs use directed associations, with role names and multiplicities on oneside. Example:

the association name, common when drawing adomain model, is often excluded (though still legal)when using class diagrams for a softwareperspective in a DCD

Register

id: Int

...

Sale

time: DateTime

...

1

currentSale

Register

id : Int

Sale

time : DateTime

Captures-current-sale1 1UP Domain Modelconceptual perspective

UP Design ModelDCD

software perspective

Larman (2005), Fig. 16.4


http://find/


55/76

Typically, we use the text representation for attributes that are data types(value types for which object identity is unimportant).

Example:

Register

id: Int

...

Sale

time: DateTime

...

1applying the guidelineto show attributes asattribute text versus asassociation lines

Store

address: Addressphone: PhoneNumber

...

1

Register has THREE attributes:1. id2. currentSale3. location

currentSale

location

Larman (2005), Fig. 16.5


http://find/


56/76

Attributes that are collections are denoted using associations withappropriate multiplicity and properties on the role name.

notice that an association end can optionally alsohave a property string such as {ordered, List}

Sale

time: DateTime

...

SalesLineItem

...

...

1..*

lineItems{ordered, List}

Sale

time: DateTimelineItems : SalesLineItem [1..*]

orlineItems : SalesLineItem [1..*] {ordered}

...

SalesLineItem

...

...

Two ways to show acollection attribute

Larman (2005), Fig. 16.6


Design class diagramsOperations
http://find/


57/76

Operations go in their own compartment and are denoted with the syntax

visibility name ( parameter-list ) { property-string }

UML 2 does not provide for declaration of the return type of an operation,but tools still support the preferred UML 1 syntax

visibility name ( parameter-list ) : return-type { property-string }

As with attributes, language-specific syntax is also OK:

+ getPlayer ( name : String ) : Player { exception IOException }

public Player getPlayer( String name ) throws IOException

Visibility is assumed to be public if not given.


http://find/


58/76

Note that operations are not methods:

An operation in a DCD is a declaration.

A method is the implementation of an operation, which can beprovided as code or pseudocode in a note with themethod keyword.

Register

...

endSale()enterItem(id, qty)makeNewSale()makePayment(cashTendered)

method// pseudo-code or a specific language is OKpublic void enterItem( id, qty ){

ProductDescription desc =catalog.getProductDescription(id);sale.makeLineItem(desc, qty);

}

Larman (2005), Fig. 16.7


http://find/


59/76

Creation operations (constructors) should be tagged with the

constructor

stereotype.Accessor operations (getters and setters) should not be shown in a DCD.


Design class diagramsKeywords and stereotypes
http://find/


60/76

Keywords appear in guillemot notation (actor, interface) or in

property lists ({abstract}, {ordered}).

Stereotypes (e.g. destroy) are refinements of modeling concepts thatare part of a UML Profile and may be used by UML tools as aids fortransformations.

stereotypeAuthorship

author: Stringstatus : String

UML extensionrelationship to a basicUML metamodel term Element

authorship

author =craigstatus =tested

metaclassElement

...

authorshipSquare

...

using the stereotype

a tool will probably allow a popup to fill in the tag values,once an element has been stereotyped with authorship

declaring the stereotype

Larman (2005), Fig. 16.8


Design class diagramsGeneralization associations
http://find/


61/76

Generalization uses an open triangular arrow head:

In an analysis model, generalization indicates a subset/supersetrelationship.

In a design model, generalization indicates object-oriented inheritance.

Abstract classes use the {abstract} property, and final classes use the{leaf} property.


Design class diagramsDependency associations
http://find/


62/76

Some dependency relationships (generalization, attribute-as-association)have their own arrow style.

Other types of dependencies are represented as generic dependencies usinga dashed arrow with open head from the client to the supplier.

We most often use generic dependency lines for

Global variables

Parameter variables

Local variablesStatic method calls


http://find/


63/76

As an example of dependency, consider the codepublic class Sale {

public void updatePriceFor( ProductDescription description ) {Money basePrice = description.getPrice();

...

}

}

The parameter and the method call introduce a dependency of Sale as aclient of ProductDescription:

SalesLineItem

...

...

ProductDescription

...

...

1..*lineItems

Sale

...

updatePriceFor( ProductDescription )...

theSale has parameter visibility to aProductDescription, and thus some kind ofdependency

Larman (2005), Fig. 16.9Paul Janecek (CSIM-AIT) Object Design 63 / 76

http://find/


64/76

As another example, the code

public class Foo {

public void doX() {

System.runFinalization();

...

}

}

introduces a dependency from Foo to System through the static methodcall:

System

...

runFinalization()...

Foo

...

doX()...

the doX method invokes the runFinalizationstatic method, and thus has a dependency onthe System class

Larman (2005), Fig. 16.10


http://find/


65/76

Dependency associations can be labeled with keywords or stereotypes toclarify their significance:

callWindow

a dependency on calling on operations ofthe operations of a Clock

Clock

getTime()...

createA

a dependency that A objects create B objects

B

...

Larman (2005), Fig. 16.11


Design class diagramsInterface-related associations
http://find/


66/76

Interface declaration, implementation, and use can be shown in a few

different ways:

interface

Timer

getTime()

Clock1

...

getTime()... lollipop notation indicates Clock3 implements

and provides the Timerinterface to clients

Timeris a provided interface

Timer

Clock3

...

getTime()...

Window2

Window3

dependency line notation

Window2 has a dependency on theTimerinterface when it collaborateswith aClock2 object

socket line notation

Window3 has a dependency on theTimerinterface when it collaborateswith aClock3 object

Window1Timer

socket line notation

Window1 uses the Timerinterface

it has a required interface

Clock2

...

getTime()...

Clock1

implements andprovides theTimerinterface

Timer

Larman (2005), Fig. 16.12


Design class diagramsComposition associations
http://find/


67/76

UML actually allows both loose whole-part relationships calledaggregations and strong whole-part relationships called compositions.

Aggregations are deprecated; just use ordinary associations for looserelationships.

Compositions are indicated with a solid diamond on the whole side:Finger

0..7Hand

composition

1

Square40

Board1

SalesLineItem1..*

Sale1

composition means-a part instance (Square) can only be part of onecomposite (Board) at a time

-the composite has sole responsibility for management ofits parts, especially creation and deletion

Larman (2005), Fig. 16.13


Design class diagramsComposition associations
http://find/


68/76

By a strong whole-part relationship, we mean that

The part can only be associated with one whole.

The part cannot exist in isolation.

The whole is responsible for creation and deletion of its parts.


Design class diagramsConstraints
http://find/


69/76

Constraints can be attached to various UML elements to provideadditional information to the reader:

Stack

size : Integer {size >=0 }

push( element )pop() : Object

three ways to show UML constraints

{post condition: new size =old size +1 }

{post condition: new size =old size 1}

Larman (2005), Fig. 16.14


Design class diagramsQualified associations
http://find/


70/76

Qualified associations select an object from a collection based on a key:

ProductCatalog

ProductDescription

itemIDContains

ProductCatalog

ProductDescription

Contains

1..*

multiplicity reduced to 1

(a)

(b)

qualifier

1

11

Larman (2005), Fig. 16.15


Design class diagramsAssociation classes
http://find/


71/76

Association classes allow adding attributes to an association. They areuseful for many-to-many relationships like Company-Person.

salarystartDate

Employment

EmploysCompany Person**

a person may haveemployment with severalcompanies

Larman (2005), Fig. 16.16


Design class diagramsSingleton classes
http://find/


72/76

As in interaction diagrams, singleton classes are indicated by a 1:

1ServicesFactory

instance : ServicesFactory

accountingAdapter : IAccountingAdapter

inventoryAdapter : IInventoryAdaptertaxCalculatorAdapter : ITaxCalculatorAdapter

getInstance() : ServicesFactory

getAccountingAdapter() : IAccountingAdaptergetInventoryAdapter() : IInventoryAdaptergetTaxCalculatorAdapter() : ITaxCalculatorAdapter...

UML notation: in aclass box, anunderlined attribute or

method indicates astatic (class level)member, rather thanan instance member

UML notation: this '1'can optionally be usedto indicate that only oneinstance will be created(a singleton)

Larman (2005), Fig. 16.17


Design class diagramsTemplates/generics
http://find/


73/76

Templates or generic classes have template parameters, e.g.:

public class Board {

private List squares = new ArrayList();

...

}

interface

List

clear()...

Kparameterized or template

interfaces and classes

K is a template parameter

anonymous class withtemplate binding complete

Board

squares : Listor

squares : List...

ArrayList

clear()...

the attribute type may be expressed inofficial UML, with the template bindingsyntax requiring an arrow

orin another language, such as J ava

ArrayList

elements : T[*]

...

clear()...

T

for example, the elements attribute is anarray of type T, parameterized and boundbefore actual use.

there is a chance the UML 2 arrow symbol willeventually be replaced with something else e.g., =

Larman (2005), Fig. 16.18


Design class diagramsUser-defined compartments
http://find/


74/76

You can add arbitrary compartments to your class boxes:

DataAccessObject

id : Int...

doX()

...

exceptions thrown

DatabaseExceptionIOException

responsibilities

serialize and write objectsread and deserialize objects...

Larman (2005), Fig. 16.19


Design class diagramsActive classes
http://find/


75/76

Active classes (classes running their own thread of execution) are shownthe same way as in interaction diagrams:

interface

Runnable

run()

Clock

...

run()

...

active class

Larman (2005), Fig. 16.20


Design class diagramsInteraction vs. class diagrams
http://find/


76/76

Let the class diagrams emerge naturally as you do dynamic modeling

with interaction diagrams. You might draw them side-by-side on awhiteboard.

: Register : Sale



Register

...

makePayment()...

Sale

...

makePayment()...

1

currentSale

messages in interactiondiagrams indicate operationsin the class diagrams classes

identified in theinteractiondiagrams aredeclared in theclass diagrams

Larman (2005), Fig. 16.21

http://find/

Documents

05-ObjectDesign