Lecture UML

8/16/2019 Lecture UML

1/87

1

What is UML?

It is a Unified Modeling Language, which is mainly a collection ofgraphical notation that methods use to express the designs.

The UML is language for isuali!ing, specifying, constructing anddocumenting the artifacts of software system.

UML is isual modeling language for modeling systems and is non proprietary

UML is not a radical departure from "ooch, #MT, ##$% notations &ut rather legitimate successor to all three.

It is an eolutionary step, which is more expressie and more uniform

than indiidual notations. Whitehead says

' "y relieing the &rain of unnecessary wor(, a good notation, sets itfree to concentrate on more adance and creatie pro&lems ' UML isnot a method or process &ut is the means to express the same.


2/87

)

Where can you use the UML?

$ystem of seeral different (inds, a&solutely anywhere eerywhere.

*rimarily for software intensie systems li(e+

$ystems software

"usiness processes


3/87

The %olution of the UML+

UML1.1

UML1.-

UML-.

"eta ersion ##*$L/0

*u&lic 2eed&ac(

$u&mission of #M3 group

#M3 ote04

$u&mission to #M3, sept04

Unified Method -.5

#ther method "ooch #MT ##$%


4/87

6

/dantages of UML+

7aptures &usiness processes

%nhance communication and ensures the right communication

7apa&ility to capture the logical software architecture independent ofthe implementation language

Manages the complexity

%na&les reuse of design


5/87

8

UML refers to+

UML things+

7lass, component, node, relationship, pac(age etc..

UML diagrams+Use case diagram, interaction diagram, class diagram, $tate

diagram,deployment diagram


6/87

"est *ractices followed &y 9ational Unified *rocess

:eelop software iteratiely

Manage re;uirements

Use component &ased architectures


7/87

4

What is a tool?

It is automated support for eery stage of software deelopment

life cycle.

$ince we are concentrating on re;uirement, analysis and design phase,

following are the names of few tools which are greatly in use+

1. 9ational 9ose

). 7ayenne

. *latinum

6. $elect


8/87

5

Why Tool?

>elps designer for creating designs much more ;uic(ly.

$upports alidations li(e+

Consistency checking

Completeness checking Constrain checking.

Time re;uired for certain operation could &e predicted .

7ode generation

9eerse engineering.

9ound trip engineering

7onersion from $$/: to ##/:

uic( documentation@etc


9/87

Triangle for $uccess+

/ll three components play e;ually important role towards the success

of the proAect.

Botation

MethodTool


10/87

1-

## model+

$T/TI7 M#:%L

:CB/MI7 M#:%L

*>C$I7/L M#:%L

L#3I7/L M#:%L

The models of #&Aect #riented :eelopment


11/87

11

Models and


12/87

1)

UML diagrams+

1. Use case diagram

). 7lass :iagram

. "ehaioral diagrams

E $tate chart diagrams

E #&Aect diagram

E /ctiity diagrams

E Interaction diagrams

E $e;uence diagrams

E 7olla&oration diagrams

6. Implementation diagramsE 7omponent diagram

E :eployment diagram


13/87

1

$emantics of :iagrams+

Use case diagrams represent the functions of a system from the user0s point of iew.

$e;uence diagrams are a temporal representation of o&Aects and their

interactions. 7olla&oration diagrams are a spatial representation of o&Aects, lin(s,

and interactions.

#&Aect diagrams represent o&Aects and their relationships, andcorrespond to simplified colla&oration diagrams that do not represent

message &roadcasts. 7lass diagrams represent the static structure in terms of classes and

relationships.


14/87

16

$emantics of :iagrams+

7ontd...

$tate chart diagrams represent the &ehaior of a class in terms of states

/ctiity diagrams are to represent the parallel &ehaior of an operationas a set of actions.

7omponent diagrams represent the logical components of anapplication.

:eployment diagrams represent the deployment of components on particular pieces of hardware.


15/87

18

What is U$% 7/$% diagram?

/ use case diagram esta&lish the capa&ility of the system as a whole.

7omponents of use case diagram+

/ctor Use case

$ystem &oundary

9elationship

/ctor relationship


16/87

1

/7T#9+

What is an actor?

/n actor is some one or something that must interact with the system

under deelopment

UML notation for actor is stic(man, shown &elow.

7ustomer Manager 7ashier


17/87

14

ACTOR:

More about an actor:

It is role a user plays with respect to system.

Actors are not part of the system they represent anyone oranything that must interact with the system.

Actors carry out use cases and a single actor may perform more

than one use cases.

Actors are determined by observing the direct uses of the

system


18/87

15

/7T#9+

/n actor may

E input information to the system.

E receie information from the system.E input to and out from the system.


19/87

1

/7T#9+

>ow do we find the actor?

/s( following ;uestions to find the actors+

– Who uses the system?

– Who installs the system?

– Who $tarts up the system?

– What other systems use this system?

– Who gets the information from the system?

– Who proides information to the system?

/ctor is always external to the system. They are neer part of the

system to &e deeloped.


20/87

)-

/7T#9+

6E7ategories of an actor+

*rinciple + Who uses the main system functions. $econdary + Who ta(es care of administration F maintenance.

%xternal h=w + The h=w deices which are part of application

domain and must &e used.

#ther system+ The other system with which the system must

interact.


21/87

)1

/7T#9+

ote:

If newly identified actor is using a system in a same way li!e an

e"isting actor# then new actor can be dropped.

If two actors use system in the same way they are same actors.


22/87

))

U$% 7/$%+

What is U$% case?

/ use case is a pattern of &ehaior, the system exhi&its

%ach use case is a se;uence of related transactions performed &y an

actor and the system in dialogue.

U$% 7/$% is dialogue &etween an actor and the system.

%xamples+

#pen new account Withdrawal of cash

from /TM


23/87

)

U$% 7/$%+

More about $%& CA%&:

It is a snapshot of one aspect of system.

They model a dialog between actor and system.

A use case typically represents a ma'or piece of functionality

that is complete from beginning to end.

Most of the use cases are generated in initial phase# but you

find some more as you proceed.


24/87

)6

U$% 7/$%+

Contd(

A use case must deliver something of value to an actor.

The use cases may be decomposed into other use cases.

$se cases also present a good vehicle for pro'ect planning.


25/87

)8

U$% 7/$%+

>ow do we find the use cases?

What functions will the actor want from the system?

:oes the system store information? What actors will create, read,

update. #r delete that information?

:oes the system need to notify an actor a&out changes in its internal

state?


26/87

)

$%& CA%&:

Generic format for documenting the use case:

) *re condition: If any – $se case : ame of the case.

– Actors : +ist of actors,e"ternal agents-# indicating who

initiates the use case.

– *urpose : Intention of the use case.

– Overview : escription.

– Type : primary / secondary.

– *ost condition: If any

Typical Course of Events:

ACTOR ACTIO : umbered actions of the actor.

%0%T&M R&%*O%&: umbered description of system responses.


27/87

)4

U$% 7/$%+

$%& CA%& documentation example+

The following use case descri&es the process of opening a new

account in the &an(.

$se case :Open new account

Actors :Customer# Cashier# Manager

*urpose :+i!e to have new saving account.

escription : A customer arrives in the ban! to open the newaccount. Customer re1uests for the new account

form# fill the same and submits# along with the

minimal deposit. At the end of complete successful

process customer receives the passboo!.

Type :*rimary use case.


28/87

)5

##/: EEE U$% 7/$% drien

7apture,clarify

F alidate use cases

/nalysis :esign F

Implementation

Implement

use cases

Use cases ma(e up the glue

Test


29/87

)

$C$T%M "#UB:/9C+

2hat is %ystem 3oundary4

It is shown as a rectangle.

It helps to identify what is e"ternal verses internal# and what the

responsibilities of the system are.

The e"ternal environment is represented only by actors.


30/87

-

9%L/TI#B$>I*+

What is 9elationship?

9elationship &etween use case and actor.

7ommunicates

9elationship &etween two use cases

%xtends

Uses

Botation used to show the relationships+

GG HH


31/87

1

9%L/TI#B$>I*+

Relationship between use case and actor is often referred as

5communicates6 .

Relationship between two use cases is refereed as either uses

or e"tends.

USES:

) Multiple use cases share a piece of same functionality.

) This functionality is placed in a separate use case rather thandocumenting in every use case that needs it.


32/87

)

9%L/TI#B$>I*+

Contd...

A uses relationship shows behavior that is common to one or

more use cases.

EXTENDS:

It is used to show optional behavior# which is re1uired only

under certain condition.


33/87

U$% 7/$% diagram+

Use case diagram for the shown functionality.

Balance status

report

Withdraw cash

Validation

uses

CustomerClerk

Manager

extends

ATM


34/87

6

2low of %ents+

/ flow of eents document is created for each use case.

:etails a&out what the system must proide to the actor when the useis executed.

Typical contents

– >ow the use case starts and ends – Bormal flow of eents

– /lternate flow of eents

– %xceptional flow of eents


35/87

8

Bormal 2low of %ents+

2or withdrawal of cash+

1.The /TM as(s the user to insert a card.

). The user inserts a cash card.

. The /TM accepts the card and reads its serial num&er.

6. The /TM re;uests the password.

8. The user enters 1)6.

. The /TM erifies the serial num&er and password with the

&an( and gets the notification accordingly.

4.The /TM as(s the user to select the (ind of transaction. 5.User selects the withdrawal.


36/87


7ontd...

.The /TM as(s for the amount of cash user enters 9s. )8--=E

1-.The /TM erifies that the amount of cash is within predefined

policy limits and as(s the &an(, to process the transaction which

eentually confirms success and returns the new account &alance.

11. The /TM dispenses cash and as(s the user to ta(e it.

1). The user ta(es the cash.

1. The /TM as(s whether the user wants to continue.

16. The user indicates no.


37/87

4


7ontd...

18 The /TM prints a receipt, eAects the card and as(s the user to ta(e

them

1. The user ta(es the receipt and the card.

14. The /TM as(s a user to insert a card.


38/87

5

/lternatie 2low of %ents+

2or withdrawal of cash use case+

. The /TM as(s for the amount of cash the user has change of mind

and hits the 'cancelJ.


39/87

%xceptional 2low of %ents+

2or withdrawal of cash use case+

$uspicious pattern of usage on the card.

1- The machine is out of cash.

11 Money gets stuc( in the machine.


40/87

6-

Why flow of eents?

It helps in understanding the functionality of a system to &e deeloped.

2low of eents helps in finding o&Aects of the system to &e deeloped.

>appens to &e most important and ery first step towards analysis and

design.


41/87

61

2hat is %cenario4

The functionality of the use case is captured in flow of the

events.

A scenarios is one path through the flow of events for the use

case.

%cenarios are developed to help identify ob'ects# classes and

ob'ect interactions for that use case.


42/87

6)

U$% 7/$% 9eali!ations+

The use case diagram presents an outside iew of the system

Interaction diagrams descri&e how use cases are reali!ed as

interactions among societies of o&Aects.

Two types of interaction diagrams

– $e;uence diagrams

– 7olla&oration diagrams


43/87

6

What is Interaction diagram?

Interaction diagrams are models that descri&e how groups of o&Aects

colla&orate in some &ehaior

There are ) (inds of interaction diagrams

• $e;uence diagram

• 7olla&oration diagram

$e;uence diagrams are a temporal representation of o&Aects and their

interactions

7olla&oration diagrams are spatial representation of o&Aects, lin(s and

interrelations


44/87

66

2hat is se1uence diagram4

Typically these diagrams capture behaviors of the single

scenario.

%hows ob'ect interaction arranged in time se1uence.

They show se1uence of messages among the ob'ects.

It has two dimensions# vertical represents time 7 hori8ontal

represents ob'ects.

Components of sequence diagram:

)ob'ects

)ob'ect lifeline)Message

)pre/post conditions.


45/87

68

#"K%7T F #"K%7T LI2% LIB%+

#&Aect are represented &y rectangles and name of the o&Aects are

underlined.

#&Aect life line are denoted as dashed lines. They are used to

model the existence of o&Aects oer time.

Bame+7lass


46/87

6

M%$$/3%$+

They are used to model the content of communication &etween

o&Aects. They are used to coney information &etween o&Aects and

ena&le o&Aects to re;uest serices of other o&Aects.

The message instance has a sender, receier, and possi&ly other

information according to the characteristics of the re;uest.

Messages are denoted as la&eled hori!ontal arrows &etween life lines.

The sender will send the message and receier will receie the

message.


47/87

64

M%$$/3%$+

7ontd@

May hae s;uare &rac(ets containing a guard conditions. This is a

"oolean condition that must &e satisfied to ena&le the message to &e

sent.

May hae hae an asteris( followed &y s;uare &rac(ets containing aniteration specification. This specifies the num&er of times the message

is sent.

May hae return list consisting of a comma Eseparated list of names

that designate the alues of returned &y the operation.

Must hae a name or identifier string that represents the message.

May hae parentheses containing an argument list consisting of a

comma separated list of actual parameters passed to a method.


48/87

65

+7ustomer +/TM +"an( 9e;uest password


49/87

6

What is 7olla&oration diagram?

7olla&oration diagrams illustrate the interaction &etween the o&Aects,

using static spatial structure.

Unli(e se;uence diagram the time is not explicitly represented in these

diagrams

In colla&oration diagram the se;uence of messages is indicated &ynum&ering the messages. The UML uses the decimal num&ering

scheme.

In these diagrams, an actor can &e displayed in order to represent the

triggering of interaction &y an element external to the system.

This helps in representing the interaction, without going into the

details of user interface.


50/87

8-

7omponents of colla&oration diagram+

Bamed o&Aects

Lin(s+ Lin(s are represented &y a continuous line &etween o&Aects, and

indicates the exchange of messages.

Messages has following attri&utes+• $ynchroni!ation EEthread name, step within thread.

• $e;uence num&er

• Message la&els + The name of the message often corresponds to an operation

defined in the class of the o&Aect that is the destination of the message.

Message names may hae the arguments and return alues.

• Niteration.

• It uses decimal notation.

• Message direction.


51/87

81

$emantics of components+

#&Aect names identify which o&Aects are participating and the lin(s

show which o&Aects colla&orate

/ lin( &etween two o&Aects must exist for one o&Aect to send message

to another and ice a ersa.

Messages in the colla&oration diagram get transformed to more

detailed signature.

They use the decimal notation system for num&ering the messages.

The direction of the message defines the sender and receier of the

message


52/87

8)

The elements of message+

*redecessor

9ole names

Message ;ualifiers – Iteration expression

– *arameters – 9eturn alues

– 3uard

– Message stereotypes

7oncurrent thread se;uencing

Thread dependencies Message expression

*re /1+NOexpressionP+doItOp,rP+return alue


53/87

8

The examples of message+

6+:isplayOx,yP $imple

message

..1+:isplayOx,yP Bested

message

6.)+su&tractToday,"irthday+age Bested

message with

return alue/ge HQ15 .)+


54/87

86

7olla&oration diagram for withdrawal of cash, normal flow.

1. Insert card

%nter password, %nter (ind

%nter amount,

Ta(e cash, Ta(e card

cancel,Terminate, 7ontinue

:isplay main screenunreada&le card message,

re;uest password,

re;uest (ind, re;uest amount,

canceled message, eAect card, failure message,

dispense cash, re;uest ta(e cash

re;uest continuation,

print receipt, re;uest ta(e card

&ad account message,

&ad &an( account message


55/87

88

What is 7lass diagram?

/ class diagram shows the existence of classes and their relationshipsin the logical iew of a system

UML modeling elements in class diagrams are+ – 7lasses, their structure and &ehaior. – relationships components among the classes li(e association,

aggregation, composition, dependency and inheritance – Multiplicity and naigation indicators – 9ole names or la&els.


56/87

8

MaAor Types of classes+

Concrete classes

/ concrete class is a class that is instantia&le that is it can hae

different instances.

#nly concrete classes may &e leaf classes in the inheritance tree.

Abstract classes

/n a&stract class is a class that has no direct instance &ut whose

descendants classes hae direct instances.

/n a&stract class can define the protocol for an operation without

supplying a corresponding method we call this as an abstract

operation.

/n a&stract operation defines the form of operation, for which each

concrete su&class should proide its own implementation.


57/87

84

9%L/TI#B$>I*+

/ssociation

/ggregation

7omposition

Inheritance

:ependency

Instantiation


58/87

85

A%%OCIATIO:

These are the most general type of relationship:

It denotes a semantic connection between two classes

It shows 3I directional connection between two classes

It is a wea! coupling as associated classes remain somewhat

independent of each other

&"ample:

7U$T#M%9 /TM system


59/87

8

A99R&9ATIO:

This is a special type of association

The association with label 5contains6 or 5is part of6 is an

aggregation

It represents 5has a 5 relationship

It is used when one ob'ect logically or physically contains other

The container is called as aggregate

It has a diamond at its end

The components of aggregate can be shared with others It e"presses a whole ) part relationships


60/87

-

A99R&9ATIO:

%xample+

7ustomer /TM card


61/87

1

COM*O%ITIO:

This is a strong form of aggregation

It e"presses the stronger coupling between the classes

The owner is e"plicitly responsible for creation and deletion of

the part

Any deletion of whole is considered to cascade its part

The aggregate has a filled diamond at its end

Window 7lient /rea


62/87

)

IB>%9IT/B7%+

The inheritance relationship helps in managing the complexity &y

ordering o&Aects within trees of classes with increasing leels of

a&straction. Botation used is solid line with arrowhead,shown &elow.

3enerali!ation and speciali!ation are points of iew that are &ased on

inheritance hierarchies./ccount

%avingAccountCurrentAccount


63/87

:%*%B:%B7C+

ependency is semantic connection between dependent and

independent model elements.

This association is unidirectional and is shown with dotted

arrowhead line.

In the following e"ample it shows the dependency relationshipbetween client and server.

The client avails services provided by server so it should have

semantic !nowledge of server.

The server need not !now about client.

7lient $erer


64/87

6

I%TATIATIO

This relationship is defined between parameteri8ed class and

actual class.

*arameteri8ed class is also referred as generic class.

A parameteri8ed class cant have instances unless we first

instantiated it&"ample:

Queue

ueue

%lement


65/87

8

What is 7ardinality? +

Deinition! Bum&er of instances of each class inoled in the

dialogue is specified &y cardinality.

Common multiplicit" #alues!

$"mbol Meaning

1 #ne and only one

-..1 ero or one

M@B 2rom M to B Onatural integerP

-..N 2rom !ero to any positie integer

1..N 2rom one to any positie integer

/lso thought can &e gien a&out naiga&ility to eery applica&le

relationship.


66/87

9eaching the class diagram+

In colla&oration diagram we hae shown the o&Aects, their interaction

and detailed message signature.

This information is carried forward to the class diagram.

/t this point,we group the similar o&Aects and form classes.

Messages get mapped to responsi&ilities for respectie classes.

2ind the attri&utes for eery class.

Transform the lin(s to appropriate relationships.

9elationship is further refined with respect to multiplicity and

naiga&ility.

This complete procedure &rings the minimal class diagram for withdraw cashuse case, normal flow.


67/87

4

7lass diagram for withdrawal of cash, normal flow

Customer

Transaction

;


68/87

5

What more to the 7lass :iagram?

Till this slide we hae wor(ed out the essentials of class diagram for

withdrawal of cash use case, normal flow of eents.

$imilar exercise re;uired to &e carried out for eery scenario and

clu&&ed all in the class diagram.

/t this point, we refine this integrated class diagram to add further finedetails. /pproximate s(etch for this class diagram has &een shown at

the end of this module.

9efinement attri&utes should &e updated right from se;uence diagram

to class diagram.

Bext few slides will ta(e into the discussion of refinement attri&utes. This process of iteratie and incremental deelopment will continue

till there is no change in two consecutie iteration.


69/87

##/:EEEIteratie F Incremental /pproach

%denti" ob&ects

%denti" Messages

'roup (b&ects

into classes

%denti" ) classi"

Class relationships%denti" class

beha#ior

'roup classes

into domains

Validate Classes) (b&ects


70/87

4-

9efinement attri&utes+

$tereot"pes!

$tereotypes are part of the range of extensi&ility mechanism proided

&y UML

It permits user to add new model element classes on top of the (ernel

predefined &y UML


71/87

41


7ontd@

Constraints!

7onstraints are functional relationship &etween the entities and o&Aect

model. The entities include o&Aects, classes, attri&utes, association,

lin(s. / constraint restricts the alues that entities can assume.

UML doesnt specify a particular syntax for constraints, other than

they should appear &etween &races, so they may therefore &e

expressed using natural language, pseudo code, naigation expression

or mathematical expression

UML1.) does prefer the use of a constraint language #7L i.e. #&Aect

7onstraint Language, which is su&set of UML.


72/87

4)


Transaction

Window

length=width

VBo. of transaction GQ8 =day

V-.5GQlength=width GQ 1.8

7onstraint on the same class.

/ constraint &etween the

properties of the same o&Aect

Bo window will hae an aspect ratio i.e. Olength=widthP of less than -.5 or H 1.8

*umber o withdrawal transaction should be less than i#e per da"+

%xample+7onstraints


73/87

4


Qualiier!

UML proides a role of constraint notation to indicate different (ind of

collections that may &e inherent in the analysis model

7ommon role constraints for multi alued roles include

Vordered 7ollection is maintained in sorted manner

V&ag 7ollection may hae multiple copies of same item.

Vset 7ollection may hae at most one copy of gien item.

$ome constraints may &e com&ined such as+ Vordered set


74/87

46


Qualiier!

/nother common design scheme is to use a (ey alue to retriee an

item from the collection. This is called as ;ualified association and the

(ey alue as ;ualifier.

/ ;ualified association is the UML e;uialent of a programmingconcept ariously (nown as associatie arrays, maps,dictionaries

/ ;ualified association relates two o&Aect classes and a ;ualifier

The ;ualifier is a special attri&ute that reduced the effectie

multiplicity of an association.

#ne to many and many to many association may &e ;ualified.


75/87

48


7hec( for many to many relationship, if any, normali!e with ;ualifier

or association class.

7hec( for the scope forming a&stract classes and template classes.

7hec( for helper functions.

Thought can &e gien for using the design patterns.


76/87

4

9efined 7lass diagram for withdrawal of cash

%avingAccount

AccountAccessor

@@abstract

Teller%creen

ATM%creen3an!Associates

Cashier%tation

person@@abstract

Cash

3atchBob

oteelpDor3an!Card

ATM%ystem

3an!Computer

Area

3an!Card

3an!>3ranch?;;

;..=;..=

Customer

;


77/87

44

What is state transition diagram?

/ state transition diagram shows the states of a single o&Aect, the

eents or the messages that cause a transition from one state to another

and the action that result from a state change.

/ state transition diagram will not &e created for eery class in the

system. Components o $tate Diagram!

– $tart $tate

– $top state

– $tate Transition


78/87

45

$emantics of eery components+

$tate! / state is a condition during the life of an o&Aect when it

satisfies some condition, performs some action, or waits for an eent.

The UML notation for a state is a rectangle with rounded corners.

$pecial states!There are two special states.

$tart state+ %ach state diagram must hae one and only one start

state. Botation for start state is 'filled solid circleJ.

$top $tate+ /n o&Aect can hae multiple stop states. Botation for stop

state is &ull0s eye.


79/87

4

$emantics of eery components+

7ontd...

$tate transition! / state transition represents a change from an

originating to a successor state.

Transition label! eent nameguard condition = action


80/87

5-

$tate Transition :iagram for /ccount class.

Operational

ormant

Open

sei8ed

transaction re1uest> validate ? / update,-

close

no transaction / TransferEtoEormantE+edger

fillEtheEre1uestEform / update,-

Draud or authori8ed instruction>Falidate?

/ loc!Account,-

matterEresolved> validate ? / unloc!Account,-

re1uest and fill the form for new saving account> validate ? / process

fillEtheEre1uestEform/update,

-

transaction%trart / TransferEtoEmainEledger ,-

Note:Account can be closed from open state as well


81/87

51

More a&out $tate :iagram+

/ state diagram will not &e created for eery class.

state diagrams are used only for those classes that exhi&it interesting

&ehaior.

$tate diagrams are also useful to inestigate the &ehaior of user

interface and control classes. $tate diagram are used to show dynamics of a indiidual class


82/87

5)

What is actiity diagram?

It is a special (ind of state diagram and is wor(ed out at use case leel.

These are mainly targeted towards representing internal &ehaior of a

a use case.

These may &e thought as a (ind of flowchart.

2lowcharts are normally limited to se;uential process actiitydiagrams can handle parallel process.

/ctiity diagrams are recommended in the following situations+

i /naly!ing use case

i :ealing with multithreaded application

i Understanding wor(flow across many use cases.

7 i t 7h (i


83/87

5

7onsistency 7hec(ing

7onsistency chec(ing is the process of ensuring that,information in &oth static iew of the systemOclass diagramPand the dynamic iew of the systemOse;uence and

colla&oration diagramP is telling the same story.


84/87

56

What is component diagram?

C(M,(*-*T D%A'.AM!

7omponent diagrams illustrate the organi!ations and dependencies

among software components.

/ component may &e

• / source code component

• / run time components

• /n executa&le component

• :ependency relationship.

7 :i


85/87

58

7omponent :iagram for withdrawal of cash

policy.dll

3ranch3an!.dllcustomer.dll

ATM.e"e

3ranch3an!.e"e

3an!%erver.e"e


86/87

5

What is deployment diagram?

/ deployment diagram shows the relationship among software and

hardware components in the deliered system.

These diagram include nodes and connections &etween nodes.

%ach node in deployment diagram represents some (ind of

computational unit, in most cases a piece of hardware. 7onnection among nodes show the communication path oer which

the system will interact.

The connections may represent direct hardware coupling line 9$E))

ca&le, %thernet connection, they also may represent indirect coupling

such as satellite to ground communication.


87/87

:eployment diagram

ATME machine

3an!E server

3ranch3an!E

&thernet&thernet

3an!.e"e

3an!%erver.e"e ATM.e"e

Lecture UML

Documents