Class Diagram in Uml

8/16/2019 Class Diagram in Uml

1/79

CSIS3600 Systems Analysis and

Design

Class Identification and Class

Diagrams


2/79


3/79

Objects

• In object oriented analysis, the world is modeled

in objects.

• Objects are entities that have a well-defined role

within the system.

• An object can be tangible or visible (i.e. person,

place or thing) or a concept of event (department,

registration, etc.) or an artifact of the design process (ser interface, schedler, etc.).

• Objects are nons.


4/79

Object Properties

• Objects are described both by their properties

(attribtes and relationships) and by their behavior

(how the object acts and reacts).

• Objects represent categories while an objectinstance is a specific occrrence of the object.

• !o remove any confsion, some te"ts se the

terminology object class to refer to the set ofobjects.


5/79

Object Defined

An object is an entity which has a state and a defined set of

operations which operate on that state. !he state is represented

as a set of object attribtes. !he operations associated with the

object provide services to other objects (clients) which re#estthese services when some comptation is re#ired. Objects are

created according to some object class definition. An object

class definition serves as a template for objects. It incldes

declarations of all the attribtes and services which shold beassociated with an object of that class.

Ian Summerville, Software Engineering, 2000


6/79

Object Encapsulation

• Object encapslation is the term sed to describe the

representation of objects by their attribtes and behavior.

• It is important to remember that an object is $solelyresponsible for carrying ot any fnctions or behaviors that

act on its own data.$

• !he internal wor%ings of an object are private - other

objects can see only the interface.• &o shold also note that the attribtes of an object can be

other objects and the behavior of an object can se other

objects.


7/79

Object Classification

Objects are represented by classification andclass hierarchies. 'everal principles relate tothis process. !hese inclde

• lass - an abstraction describing objects of thesame %ind.

• Object - instance of a class. Objects contain

attribtes - data property of an object (variable,etc.) and methods - behavioral property of anobject (operation, fnction, etc.) *ethods areinvo%ed by a call (message).


8/79

Object Classification continued

• Inheritance - relationship between a more speciali+ed class

and its more generali+ed parent class.

• enerali+ationspeciali+ation - Abstracting common

featres (attribtes and operations) among mltiple classesinto a more general class.

• 'pertype - class that stores attribtes common to one or

more class sbtypes of the object.

• 'btype - a class who inherits some common attribtes

from a class spertype and adds attribtes that are ni#e

to the sbtype.


9/79

nderstanding Classes

A class is a collection of objects with a common

strctre, common behavior, common relationships

and common semantics.

class name non representing the class domain.

attribtes characteristics of the class - identified by

e"amining class definitions, problem re#irements and

domain %nowledge - crrent attribte vales define an

object/s state.

behaviors represents operations and fnctions and are

fond by e"amining object interactions


10/79

Object Identification

• Identifying objects is the most difficlt part of

object oriented design.

• !here is no /magic formla/ for objectidentification. It relies on the s%ill, e"perience .

and domain %nowledge of system designers.

• Object identification is an iterative process. &o

are nli%ely to get it right first time.


11/79

E!ample of Single Class Diagram"s#

Class $ame

Attributes

%

%

&et'ods%

%

Course

$ame

$umber of

Credits

OpenAddStudent

Student

$ame

StudentID

(ear

)))

Calc*age "#Calc*gpa

+egister for "course#

)))

Classes are dra,n as a rectangle ,it' t'ree compartments-


12/79

Object Instance Diagram

• An object diagram is also %nown as an instance

diagram or a graph of instances that are

compatible with a given class diagram.


13/79

&. Class and Object Diagrams

(a) lass 0iagram

'howing !wo lasses

(b) Object 0iagram with

!wo Instances


14/79

An office information system

• !he Office Information 1etrieval 'ystem (OI1') isan atomatic file cler% which can file documents nder some name in one or more inde!es/ retrievedocuments/ display and maintain documentinde!es, archive docments and destroy

documents) !he system is activated by a re#estfrom the user and always returns a message to theuser indicating the sccess or failre of the re#est.

2ile1etrieveArchive0estroy

Document

3ame

0isplay0elete entryAdd entry

Inde!

Name

Get commandPut message

ser +etrieal

System

4ser commandUserID


15/79

Preliminary Object Identification

2ile

1etrieveArchive0estroy

Document

3ame

0isplay

0elete entryAdd entry

Inde!

Name


ser +etrieal

System

4ser commandUserID

• 3ons in the description give pointers to objects in the system.

• 5erbs give pointers to operations associated with objects.

• Approach assmes that the designer has a common sense

%nowledge of the application domain as not all objects and

services are li%ely to be mentioned in the description.


16/79

Operations

Operations are fnctions or services provided by allinstances of a class (calc-gpa, delete, display, etc.).

!here are three types of operations

onstrctor creates a new instance of a class.

6ery Accesses a state of an object bt does not alter

the state.

4pdate it alters the state of an object.


Document

3ame


Inde!

Name


ser +etrieal

4ser commandUserID


17/79

A 7ord on Attribtes

• 5isibility of attribtes may be shown

5isibility relates to information hiding

• 8 pblic not hidden from any other object

• 9 protected hidden from all classes e"cept itsimmediate sbclass

• - private hidden from all other classes


Document 3ame


Inde!Name


ser +etrieal

4ser commandUserID1 1


18/79

2'e Class Diagram

!he class diagram is a central modeling techni#ethat rns throgh nearly all object-oriented methods.

!his diagram describes the types of objects in thesystem and varios %inds of static relationshipswhich e"ist between them.

!here are three principal %inds of relationships

associations (a cstomer may rent a nmber of

videos) sbtypes (a nrse is a %ind of person)

aggregation (an engine is part of an aircraft).

(noteone class can be part of many class diagrams.)


19/79

:"ample lass 0iagram


20/79


21/79

Perspecties of Class Diagrams

!here are three perspectives yo can se in drawing class diagrams

• Conceptual: In this case yo are drawing a diagram that represents the

concepts in the domain nder stdy. !hese concepts will natrally relate to

the classes that implement them, bt it is often not a direct mapping.

Indeed the model is drawn with little or no regard for the software thatmight implement it.

• Specification: In this case, yo are loo%ing at software, bt yo are

loo%ing at the interfaces of the software, not the implementation. 7e are

ths loo%ing at types rather than classes.

• Implementation: In this view we really do have classes and we are laying

the implementation base. !his is probably the most often sed perspective

in the design phase of systems development, bt in many ways the

specification perspective is often a better one to ta%e.


22/79

Perspectie continued

• 4nderstanding the perspective is crcial to drawing and reading the

class diagram.

• !he perspective determines its se.1emember OOA0 is iterative.!he

conceptal diagram is refined for specification and implementation.


23/79

asic Elements of Class Diagrams

On a class diagram, it is recommended thatonly the most often needed elements be listed!hese inclde

• lass

• 1elationship

enerali+ation

Associations

*ltiplicity


24/79

Symbols of t'e Class Diagram

• ;o" 1epresents the class.;ro%en down into < parts 3ame, attribtes and operations

• =ine represents association with nmber representingmltiplicity.=ine with an arrow represents navigation

• onnecting lines with arrows represent generali+ation ofsperclass sbclass

• >? - constraints or rles provided for major constraints only

• open diamond shows aggregation (closed diamond shows

composition)

• ;o" with flipped edge depicts notes


25/79


26/79

+epresenting $otes "business rules#


27/79

Class +elations'ips

• 1elationships between classes are

discovered by e"amining interactions

between objects.

• If two objects mst /tal%,/ there mst be a

pathway for commnication.


28/79

2ypes of +elations'ips

!here are three primary types of relationships• enerali+ation enables inheritance of attribtes and operations)

S'o,n as connecting lines ,it' arro,s

• Association - a bi-directional connection between classes. S'o,nas a line connecting related classes.

• Aggregation - stronger from of relationship between a whole andits parts. S'o,n as a line connecting t'e related classes ,it' a'ollo, diamond ne!t to t'e class representing t'e ,'ole)

• 0ependency - wea%er form of relationship showing a relationship

between a client and a spplier where the client does not have asemantic %nowledge of the spplier. S'o,n as a das'ed linepointing from t'e client to t'e supplier)


29/79


30/79

Association $aming on Class

Diagrams

• Associations are named - se verbs that have

meaning ie is-contained

• 'ometimes they imply messages to be sent• 1oles (each end of the association) are named if

needed or if the association is between objects of

the same class


31/79

Diagram role naming


32/79


33/79


34/79

Deried Attribute/ Association/ and +ole

• Age is derived attribte of stdent calclated from date of birth and

crrent date shown in braces.• !a%es is derived becase it can be inferred from the other relationships

1egisters-for and 'chedle-for • @articipants is derived becase it can be derived from other roles.


35/79

+elations'ip Attributes4Operations

• 'ome relationshipshave attribtes andoperations.

• !hey are added as anassociation class anddepicted with a dashedline.

• !he association classdoes not e"ist withotthe original association.

@erformer @erformance

@erformance

)ontract


36/79

+elations'ip Association E!ample

stomer

name

addresss

credit card

area code

phone no.

@rchase

- total

service charge

delivery charge

facility charge

sales ta"

calclate total()sm prchase price()

receive payment ()

claclate change()

add item()

harge

e"iration date

accont nmber

isser

athori+e credit ()


37/79

Aggregation

• Aggregation - stronger from of relationship

between a whole and its parts. 'hown as a line

connecting the related classes with a 'ollo,diamond ne!t to t'e class representing t'e

,'ole)

A stronger form of aggregation is composition (depicted

,it' a solid diamond). omposition is sed when a partobject belongs to only one whole object and lives and dies

with the whole object room in a bilding.


38/79

Aggregation and Composition

(a) lass 0iagram

(b) Object 0iagram


39/79

Adding In'eritance

• Inheritance is a relationship between asperclass and its sbclasses.

• !here are two ways to find inheritance -

generali5ation and speciali5ation.• Inheritance identifies common attribtes,

operations andor relationships and places

them at the highest level in the hierarchy.• Inheritance redces redndancy andimproves efficiency.


40/79


41/79

Abstract

• An abstract class is a class that has no direct

instances(oncrete class is a class that has

direct instances).

:"amples inclde niversity stdents who mst

be identified by their standing.!he abstract

class is stdent bt stdent does not have any

direct instances. 'tdent descendants

radate and 4ndergradate have instances.

• Abstract classes are shown in italics or

>abstract? with the word abstract in braces.


42/79


43/79

Adding &ultiplicity

• *ltiplicity is also shown between class relationships (asis done with cardinality in :1 diagrams).

• *ltiplicity defines how many objects participate in a

relationship. *ltiplicity is bi-directional - one for eachend of the relationship. 7hen thin%ing of mltiplicity, yodefine it as the nmber of instances of one class related tothe O3: instance of the other class.

• 7hile associations and aggregation are bi-directional bydefalt, is often desirable to restrict navigation to onedirection. If this is done, an arrowhead is added to indicatethe direction of the navigation.


44/79

E l f A i ti + l ti 'i f


45/79

E!amples of Association +elations'ips of

Different Degrees


46/79


47/79

Object Diagrams

• A method sed to #ic%ly identify

relationships is the Object 0iagram.

• In its simplest form, an Object 0iagramdepicts classes and their relationships to

other classes withot adding detail.

• !he object diagram is sed as a tool ponwhich the lass 0iagram can be bilt.


48/79

E!ample Object Diagram


49/79

Once Again +ules on &odeling

lass diagrams are the bac%bone of OO methods so sed #ite

fre#ently. !he troble is that they are so rich that they can be

overwhelming. ere are a few tips to remember

• 0on/t try to se all the varios notations. 'tart with thesimple classes, associations, attribtes, and

generali+ation. Introdce other notations only when yo

need them.

• 0on/t draw models for everything, concentrate on the %eyareas. It is better to have a few diagrams that yo se and

%eep p-to-date than many forgotten, ot-of-date models.


50/79

+ules continued

• *odeling is iterative.

• 'ort ot which perspective yo are drawing

the models from.

If yo are in analysis draw conceptal models.

7hen wor%ing with software concentrate on

specification models.

0raw implementation models only when yoare illstrating a particlar implementation

techni#e.


51/79


52/79


53/79


54/79


55/79


56/79


57/79


58/79


59/79


60/79


61/79


62/79


63/79


64/79


65/79

Identifying Classes

• Identifying objectsclasses is the most difficlt part of

OOA0.

• !here is no magic formla.

• It relies on s%ill, e"periences and %nowledge of the system

domain.

• It is an iterative process.

• Objectsclasses can be identified throghot the OOA0 process.

Suggested Approac'es to Object


66/79

Suggested Approac'es to Object

Identification

• 4se a grammatical approach based on a natral

langage description of the system.

• ;ase the identification on tangible things in theapplication domain.

• 4se a behavioral approach and identify objects

based on what participates in what behavior

• 4se a scenario-based analysis (se case

descriptions).


67/79

Object Identification

• !e"tal analysis of se-case information

3ons sggest classes

5erbs sggest operations

• reates a rogh first ct

• ommon object list

• Incidents

• 1oles

PowerPoint Presentation for Dennis, Wixom & Tegardem Systems Analysis andDesign

Copyright 2001 © John Wiley & ons, !n"# $ll rights reser%ed#


68/79



@atterns

• 4sefl gropings of classes that recr in varios

sitations

• !ransactions

!ransaction class

!ransaction line item class

Item class

=ocation class @articipant class


69/79

Other ideas for lasses

• !emplates for creating instances or objects

oncrete

Abstract

• !ypical e"amples

Application domain

ser interface

data strctre

file strctre

operating environment

0ocment

and mltimedia classes




70/79

• A good place to start the identification of systemclasses and objects is by analy+ing se cases. &ocan begin by simply finding all the nons and then

assessing whether they really are an object orsimply an attribte.

• Another commonly sed techni#e relies on /role- play/ to act ot se cases. A class of objects is

identified and then what the class does and whomit does it with are identified. !he reslts arereported on a lass 1esponsibility ollaboration(1) card.

Approac'es to identification

't f Obj t Id tifi ti d 't t l


71/79

'teps for Object Identification and 'trctral

*odeling

1# Create CC "ards 'y performing text(al analysis on the (se)"ases#

2# *rainstorm additional "andidate "lasses, attri'(tes, operations, andrelationships 'y (sing the "ommon o'+e"t list approa"h#

# ole)play ea"h (se)"ase (sing the CC "ards#

-# Create the "lass diagram 'ased on the CC "ards#

.# e%iew the str("t(ral model for missing and/or (nne"essary "lasses, attri'(tes, operations, and relationships#

# !n"orporate (sef(l patterns#

# e%iew the str("t(ral model#




72/79

E!ample C+C Card

C.ASS 7class name8

+esponsibilities Collaborators

=ist of things class mst

%now and do

=ist of other classes

which help this

class flfill itsresponsibilities


73/79

Course +egistration System

C.ASS 7Student8


1emember name and

major

1emember the selectedorse Offerings

orse Offerings


74/79

Course +egistration System E!ample

C.ASS 7+egistration 9orm8


0isplay 'tdent Info

0isplay available corses

0isplay chosen corses

1egistrar

1egistration*anager


75/79

A 1 ard

Front:

Class name: ID: Type:

Description:

Responsibilities: Collaborators:

Back:

Attributes:

Relationships:

Generalization (a-kin-o!":

A##re#ation (has-parts":

$ther Associations:




76/79

• 2or a description of how to play the 1 game

visit

httpmembers.aol.comhmansandttechni#escrc.htm

• 1 !torial

httpwww.csc.calpoly.edBdbtlerttorialswin

terCDcrcEbhttpftp.ics.ci.edpbarchmltorsbdlas

s0iagram.html

C+C +esources

http://members.aol.com/humansandt/techniques/crc.htmhttp://members.aol.com/humansandt/techniques/crc.htmhttp://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/http://ftp.ics.uci.edu/pub/arch/uml/tours/bdClassDiagram.htmlhttp://ftp.ics.uci.edu/pub/arch/uml/tours/bdClassDiagram.htmlhttp://ftp.ics.uci.edu/pub/arch/uml/tours/bdClassDiagram.htmlhttp://ftp.ics.uci.edu/pub/arch/uml/tours/bdClassDiagram.htmlhttp://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/http://members.aol.com/humansandt/techniques/crc.htmhttp://members.aol.com/humansandt/techniques/crc.htm


77/79


78/79


79/79

6ote of the 7ee%

It is difficult to introduce both novice and experienced

procedural programmers to the anthropomorphic

perspective necessary for object-oriented.We introduce CRC

cards, which characterie objects by class name,responsibilities and collaborators, as a way of giving

learners a direct experience of objects.

:ent ec; and

Class Diagram in Uml

Documents

Transcript of Class Diagram in Uml