Chapter 3 , Class Diagram

Usi

ng U

ML,

Pat

tern

s, an

d Ja

vaO

bjec

t-O

rien

ted

Soft

war

e E

ngin

eeri

ngChapter 3,Class

Diagram

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2

Outline of this Class

• Activity diagrams• Describe the dynamic behavior of a system, in

particular the workflow.• Class diagrams

• Describe the static structure of the system: Objects, attributes, associations

• Use case diagrams• Describe the functional behavior of the system as seen

by the user• Sequence diagrams

• Describe the dynamic behavior between objects of the system

• Statechart diagrams• Describe the dynamic behavior of an individual object


Class Diagrams

• Class diagrams represent the structure of the system

• Used• during requirements analysis to model application

domain concepts• during system design to model subsystems• during object design to specify the detailed behavior

and attributes of classes.

Table zone2priceEnumeration getZones()Price getPrice(Zone)

TarifSchedule

* *

Tripzone:Zone

Price: Price


Classes

• A class represents a concept.• A class encapsulates state (attributes) and behavior (operations):

Table zone2priceEnumeration getZones()Price getPrice(Zone)

TarifSchedule

zone2pricegetZones()getPrice()

TarifSchedule

Name

Attributes

Operations

Signature

TarifSchedule

The class name is the only mandatory information

Each attribute has a typeEach operation has a signature

Type


Instances

• An instance represents a phenomenon.• The attributes are represented with their values.• The name of an instance is underlined. • The name can contain only the class name (TarifSchedule)

of the instance (anonymous instance).

zone2price = {{‘1’, 0.20},{‘2’, 0.40},{‘3’, 0.60}}

tarif2006:TarifSchedulezone2price = {{‘1’, 0.20},{‘2’, 0.40},{‘3’, 0.60}}

:TarifSchedule


Actor vs Class vs Object

• Actor • An entity outside the system to be modeled,

interacting with the system (“Passenger”)• Class

• An abstraction modeling an entity in the application or solution domain

• The class is part of the system model (“User”, “Ticket distributor”, “Server”)

• Object• A specific instance of a class (“Joe, the passenger who

is purchasing a ticket from the ticket distributor”).


Associations

Associations denote relationships between classes.

PriceZone

Enumeration getZones()Price getPrice(Zone)

TarifSchedule TripLeg

* *

The multiplicity of an association end denotes how many objects the instance of a class can legitimately reference.


1-to-1 and 1-to-many Associations

1-to-1 association

1-to-many association

Polygon

draw()

Point

x: Integer

y: Integer

*

Country

name:String

City

name:String

11


Many-to-Many Associations

StockExchange

Company

tickerSymbol**


Aggregation• An aggregation is a special case of association

denoting a “consists-of / part-of / has-a” hierarchy.• The aggregate is the parent class,

the components are the children classes.Exhaust system

Mufflerdiameter

Tailpipediameter

1 0..2

TicketMachine

ZoneButton3

A solid diamond denotes composition (“contains-a”): A strong form of aggregation where the life time of the component instances is controlled by the aggregate. That is, the parts don’t exist on their won (“the whole controls/destroys the parts”).


Difference of Aggregation and Composition

• Bir örnek Arabadır. Araba Parçalarından oluşur. Bu parçalara sahiptir. Eğer bir Parça yoksa araba bozuktur. Araba Parçalarıyla Composition oluşturur.

• Ayrıca Arabanın Yolcuları vardır. Yolcular Arabanın Parçası değildir. Eğer bir Yolcu yoksa Araba bozuk değildir. Araba Yolcularına sahip değildir. Arabada değillerse başka bir yerdedirler. İlişki geçicidir. Yolcular gelir ve gider. Araba ve Yolcular arasında Aggregation ilişkisi vardır.

• Her iki ilişki aslında Composition’dır. Arabanın hem Parçaları hem de Yolcuları vardır. Farklılık süresindedir. Parçalarla olan ilişki daimidir, Yolcularla olan ilişki geçicidir.


Qualifiers

• Qualification: A technique for reducing the multiplicity of associations by replacing many-to-many or one-to-many associations qith qualified associations.

• Qualified association: An association in which one end is indexed by an attribute.

• Qualifiers can be used to reduce the multiplicity of an association.

DirectoryFile

filename

Without qualification1 *

With qualification0..1Directory File

1filename


Qualification: Another Example

*StockExchange CompanyLists *tickerSymbol

1

StockExchange

Company

tickerSymbolLists **


Inheritance

• Inheritance is another special case of an association denoting a “kind-of” hierarchy.

• Inheritance simplifies the analysis model by introducing a taxonomy.

• The children classes inherit the attributes and operations of the parent class.

Button

ZoneButtonCancelButton


Packages• Packages help you to organize UML models to increase their

readability.• Pretty much all UML elements can be grouped into packages. Thus,

classes, objects, use cases, components, nodes, node instances etc. Can all be organized as packages.

• We can use the UML package mechanism to organize classes into subsystems

• Any complex system can be decomposed into subsystems, where each subsystem is modeled as a package.

Account

CustomerBank


Object Modeling in Practice

Class Identification: Name of Class, Attributes and MethodsIs Foo the right name?

Foo

AmountCustomerIdDeposit()Withdraw()GetBalance()


Object Modeling in Practice: Brainstorming

Foo

AmountCustomerId

Deposit()Withdraw()GetBalance()

Account

AmountCustomerId

Deposit()Withdraw()GetBalance()Is Foo the right name?

“Dada”

AmountCustomerId



Object Modeling in Practice: More classes

Account

Amount


Customer

NameCustomerId

CustomerIdAccountIdBank

Name

1) Find New Classes2) Review Names, Attributes and Methods


Object Modeling in Practice: Associations

Account

Amount


Customer

NameCustomerId

CustomerIdAccountId

AccountIdBank

Name

1) Find New Classes2) Review Names, Attributes and Methods

3) Find Associations between Classes

owns

4) Label the generic assocations

6) Review associations

*2

*?has

5) Determine the multiplicity of the assocations


Practice Object Modeling: Find Taxonomies

SavingsAccount

Withdraw()

CheckingAccount

Withdraw()

MortgageAccount

Withdraw()

Account

Amount


CustomerIdAccountId

AccountId

Customer

Name

CustomerId()

Has*Bank

Name*


Practice Object Modeling: Simplify, Organize

SavingsAccount

Withdraw()

CheckingAccount

Withdraw()

MortgageAccount

Withdraw()

Account

Amount


CustomerIdAccountId

AccountIdShow Taxonomies

separately


Practice Object Modeling: Simplify, Organize

Customer

Name

CustomerId()

Account

Amount


CustomerIdAccountId

Bank

NameHas**

Use the 7+-2 heuristicsor better 5+-2!


Practical Tips - 1

• Simplicity• To be easier to understand/takes less effort• Try to use minimal number of classes

• Diagram layout• Draw diagrams in symmetric manner• Try to avoid crossing lines

• Names• Descriptive, crisp, unambiguous• Singular nouns for the name of classes

• References• Do not bury object references inside objects• Model these as association


Practical Tips - 2• Generalization

• Do not nest subclasses too deeply• Two or three levels deep is good

• Association end names• To unify references to the same class• Be alert for multiple uses of the same class

• Qualified associations• To improve the precision of an association• Challenge with a multiplicity of “many”

• Review• Try to get others to review model• Clarify names, improve abstraction, add info

• Documentation• Diagram cannot describe the rationale• Always document models


Review of Class Diagrams

ClassAssociation End

Name (Role)

Multiplicity

Class diagrams represent the structure of the system

Aggregation

Inheritance


Class Diagram Examples - 1










Another view on UML Diagrams

Chapter 3 , Class Diagram

Documents