STUDY OF UMLDiagrams

DESCRIPTION The heart of object-oriented problem solving is the construction of a model. The model abstracts the essential details of the underlying problem from its usually complicated real world. Several modeling tools are wrapped under the heading of the UML, which stands for Unified Modeling Language. The purpose of this course is to present important highlights of the UML.

Se !e"ce diagrams C#llab#rati#" diagrams State c$art diagrams Acti%it& diagrams C#m'#"e"t diagrams De'l#&me"t diagrams The UML is applicable to object-oriented problem solving. solving -- it all begins with the construction of a model. nyone interested in

learning UML must be familiar with the underlying tenet of object-oriented problem model is an abstraction of the underlying problem. The domain is the actual world from which the problem comes. Models consist of objects that interact by sending each other messages. Thin! of an

http://csetube.co.nr/

ht

Object diagrams

tp

Class diagrams

://

cs

Use case diagrams

et

ub

here.

e.c

t the center of the UML are its nine !inds of modeling diagrams" which we describe

o.

nr

object as #alive.# $bjects have things they !now %attrib!tes& and things they can do %be$a%i#rs or #'erati#"s&. The values of an object's attributes determine its state. Classes are the #blueprints# for objects. classes. AN INTRODUCTION TO UML DIA(RAM The Unified Modeling Language is a language for specifying" constructing" visuali(ing" and documenting the artifacts of a software-intensive system. nalogous to the use of architectural blueprints in the construction industry" UML provides a common language for describing software models" and it can be used in conjunction with a wide range of software lifecycles and development processes. )* USE CASE DIA(RAM class wraps attributes %data& and

behaviors %methods or functions& into a single distinct entity. $bjects are i"sta"ces of

the users who interact with the system %actors&" and the association between the users and

diagrams include+ ,roviding a high-level view of what the system does -dentifying the users %#actors#& of the system .etermining areas needing human-computer interfaces. (RAP+ICAL NOTATION The basic components of Use )ase diagrams are the ssociation. ctor" the Use )ase" and the

)T$/

ctor" as mentioned" is a user of the system" and is depicted using a stic! ctors are not limited to humans.

figure. The role of the user is written beneath the icon.

http://csetube.co.nr/

ht

articulate the high-level re*uirements of the system. The primary goals of Use )ase

tp

the functionality. Use )ases are used in the

://

cs

et

Use )ase diagrams identify the functionality provided by the system %use cases&" nalysis phase of software development to

ub

e.c

o.

nr

-f a system communicates with another application" and e0pects input or delivers output" then that application can also be considered an actor.

US1 )

S1

Use )ase is functionality provided by the system" typically described as verb 2 object %e.g. /egister )ar" .elete User&. Use )ases are depicted with an ellipse. The name of the use case is written within the ellipse.

SS$)- T-$3

the ctor and the Use )ase.

The following image shows how these three basic elements wor! together to form a use case diagram.

Use case diagrams describe what a system does from the standpoint of an e0ternal observer. The emphasis is on what a system does rather than how.

http://csetube.co.nr/

ht

participates in the Use )ase in some form. ssociations are depicted by a line connecting

tp

ssociations are used to lin!

://

cs

ctors with Use )ases" and indicate that an

et

ub

e.c

o.

nr

ctor

Use case diagrams are helpful in three areas.

Determi"i"g ,eat!res -re !ireme"ts.. 3ew use cases often generate new re*uirements as the system is analy(ed and the design ta!es shape. C#mm!"icati"g /it$ clie"ts. Their notational simplicity ma!es use case diagrams a good way for developers to communicate with clients. (e"erati"g test cases. The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.

0* SE1UENCE DIA(RAM Se*uence diagrams document the interactions between classes to achieve a result" communications between classes are !nown as messages. The Se*uence diagram lists

NOTATION

O23ECT $bjects are instances of classes" and are arranged hori(ontally. The pictorial representation for an $bject is a class %a rectangle& with the name prefi0ed by the object name %optional& and a semi-colon.

http://csetube.co.nr/

ht

lifelines indicating the lifetime of the object over time.

tp

-n a Se*uence diagram" classes and actors are listed as columns" with vertical

://

cs

et

ub

objects hori(ontally" and time vertically" and models these messages over time.

e.c

o.

nr

such as a use case. 4ecause UML is designed for object-oriented programming" these

ACTOR ctors can also communicate with objects" so they too can be listed as a column. n ctor is modeled using the ubi*uitous symbol" the stic! figure.

LIFELINE The Lifeline identifies the e0istence of the object over time. The notation for a Lifeline is a vertical dotted line e0tending from an object.

MESSA(E Messages" modeled as hori(ontal arrows between communications between objects. ctivations" indicate the

4elow is a se*uence diagram for ma!ing a hotel reservation. The object initiating the se*uence of messages is a Reser%ati#" /i"d#/.

http://csetube.co.nr/

ht

tp

://

cs

et

ub

object is performing an action.

e.c

ctivations" modeled as rectangular bo0es on the lifeline" indicate when the

o.

ACTI4ATION

nr

1ach vertical dotted line is a li,eli"e" representing the time that an object e0ists. 1ach arrow is a message call. e0ecution of the message. 5* ACTI4ITY DIA(RAM ctivity diagrams are used to document wor!flows in a system" from the business level down to the operational level. 5hen loo!ing at an elements from State diagrams. -n fact" the ctivity diagram" you'll notice ctivity diagram is a variation of the state ctivity n arrow goes from the sender to the top of the acti%ati#" bar of the message on the receiver's lifeline. The activation bar represents the duration of

diagram where the #states# represent operations" and the transitions represent the activities that happen when the operation is complete. The general purpose of diagrams is to focus on flows driven by internal processing vs. e0ternal events.

http://csetube.co.nr/

ht

tp

-f the +#tel has available rooms" then it ma!es a Reser%ati#" and a C#",irmati#".

://

+#telC$ai". The +#telC$ai" then sends a makeReservation() message to a +#tel.

cs

et

The Reser%ati#" /i"d#/ sends a makeReservation() message to a

ub

e.c

o.

nr

ACTI4ITY STATES ctivity states mar! an action by an object. The notations for these states are rounded rectangles" the same notation as found in State chart diagrams.

TRANSITION 5hen an ctivity State is completed" processing moves to another ctivity State. Transitions are used to mar! this movement. Transitions are modeled using arrows.

S6IM LANE

INITIAL STATE The -nitial State mar!s the entry point and the initial be one -nitial State on a diagram. ctivity State. The notation for the -nitial State is the same as in State chart diagrams" a solid circle. There can only

FINAL STATE 6inal States mar! the end of the modeled wor!flow. There can be multiple 6inal States on a diagram" and these states are modeled using a solid circle surrounded by another circle.

http://csetube.co.nr/

ht

tp

://

cs

et

ub

top of the column" and vertical bars separate the columns to form the swim lanes.

e.c

o.

format and placing activities by that object within that column. $bjects are listed at the

nr

Swim lanes divide activities according to objects by arranging objects in column

SYNC+RONI7ATION 2AR ctivities often can be done in parallel. To split processing %#for!#&" or to resume processing when multiple activities have been completed %#join#&" Synchroni(ation 4ars are used. These are modeled as solid rectangles" with multiple transitions going in and7or out.

COMPONENT

component represents a software entity in a system. 10amples include source code files" programs" documents" and resource files. the right. component is represented using a rectangular bo0" with two rectangles protruding from the left side" as seen in the image to

DEPENDENCY .ependency is used to model the relationship between two components. The notation for a dependency relationship is a dotted arrow" pointing from a component to the component it depends on.

http://csetube.co.nr/

ht

tp

://

dependencies and can be used to properly compile an application.

cs

et

This information is similar to that within ma!e files" which describe source code

ub

software components such as the dependency between e0ecutable files and source files.

e.c

)omponent .iagram" in particular" is used to describe the dependencies between various

o.

!ind of diagram that models the implementation and deployment of the system.

nr

8* COMPONENT DIA(RAM )omponent diagrams fall under the category of an implementation diagram" a

http://csetube.co.nr/

ht

tp

://

cs

et

ub

e.c

o.

nr

9* CLASS DIA(RAM A Class diagram gives an overview of a system by showing its classes and the relationships among them. )lass diagrams are static -- they display what interacts but not what happens when they do interact. The class diagram below models a customer order from a retail catalog. The central class is the Order. the Pa&me"t. ssociated with it are the C!st#mer ma!ing the purchase and Pa&me"t is one of three !inds+ Cas$" C$ec:" or Credit. The order

contains OrderDetails %line items&" each with its associated Item.

UML class notation is a rectangle divided into three parts+ class name" attributes" and operations. 3ames of abstract classes" such as Payment, are in italics. /elationships between classes are the connecting lin!s. $ur class diagram has three !inds of relationships.

ass#ciati#" -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must !now about the other in order to perform its wor!. -n a diagram" an association is a lin! connecting two classes.

http://csetube.co.nr/

ht

tp

://

cs

et

ub

e.c

o.

nr

aggregati#" -- an association in which one class belongs to a collection. diagram" Order has a collection of OrderDetails.

aggregation has a diamond end pointing to the part containing the whole. -n our

ge"erali;ati#" -- an inheritance lin! indicating one class is a superclass of the other. generali(ation has a triangle pointing to the superclass. Payment is a superclass of Cas$" C$ec:" and Credit. n association has two ends. n end may have a r#le "ame to clarify the nature of

the association. 6or e0ample" an OrderDetail is a line item of each Order. "a%igabilit& arrow on an association shows which direction the association can be traversed or *ueried. n OrderDetail can be *ueried about its Item" but not the other ssociations with no navigability arrows are biway around. The arrow also lets you !now who #owns# the association's implementation8 directional.

associated with a single instance of the other end. Multiplicities are single numbers or a C!st#mer can have any number of Orders. This table gives the most common multiplicities. M!lti'licities <**) <**= or = ) )**= 1very class diagram Mea"i"g (ero or one instance. The notation n . . m indicates n to m instances. no limit on the number of instances %including none&. e0actly one instance at least one instance has classes" associations" and multiplicities. 3avigability and roles

are optional items placed in a diagram to provide clarity.

http://csetube.co.nr/

ht

ranges of numbers. -n our e0ample" there can be only one C!st#mer for each Order" but

tp

://

cs

The m!lti'licit& of an association end is the number of possible instances of the class

et

ub

e.c

in this case" OrderDetail has an Item.

o.

nr

>* PAC?A(ES AND O23ECT DIA(RAMS To simplify comple0 class diagrams" you can group classes into 'ac:ages. pac!age is a collection of logically related UML elements. The diagram below is a business model in which the classes are grouped into pac!ages.

,ac!ages appear as rectangles with small tabs at the top. The pac!age name is on depends on another if changes in the other could possibly force changes in the first. Object diagrams show instances instead of classes. They are useful for e0plaining small pieces with complicated relationships" especially recursive relationships. This small class diagram shows that a university De'artme"t can contain lots of other De'artme"ts.

http://csetube.co.nr/

ht

the tab or inside the rectangle. The dotted arrows are de'e"de"cies. $ne pac!age

tp

://

cs

et

ub

e.c

o.

nr

The object diagram below instantiates the class diagram" replacing it by a concrete e0ample.

Instance names are underlined in &)* diagrams. 'lass or instance names ma% be omitted $rom object diagrams as long as t!e diagram meaning is still clear.

@* COLLA2ORATION DIA(RAMS C#llab#rati#" diagrams are also interaction diagrams. They convey the same information as se*uence diagrams" but they focus on object roles instead of the times that messages are sent. -n a se*uence diagram" object roles are the vertices and messages are the connecting lin!s.

http://csetube.co.nr/

ht

tp

Eac! rectangle in t!e object diagram corresponds to a single instance.

://

cs

et

ub

e.c

o.

nr

A* STATE C+ART DIA(RAMS $bjects have behaviors and state. The state of an object depends on its current activity or condition. statec$art diagram shows the possible states of the object and the transitions that cause a change in state. $ur e0ample diagram models the login part of an online ban!ing system. Logging in consists of entering a valid social security number and personal id number" then submitting the information for validation. Logging in can be factored into four non-overlapping states+ (etti"g SSN" (etti"g PIN" 4alidati"g" and Rejecti"g. 6rom each state comes a complete set of tra"siti#"s that determine the subse*uent state.

http://csetube.co.nr/

ht

same decimal prefi0 but suffi0es of 9" :" etc. according to when they occur.

tp

message is numbered 9. Messages at the same level %sent during the same call& have the

://

cs

1ach message in a collaboration diagram has a se !e"ce "!mber. The top-level

et

ub

)lass names are preceded by colons % + &.

e.c

The object-role rectangles are labeled with either class or object names %or both&.

o.

nr

States are rounded rectangles. Transitions are arrows from one state to another. 1vents or conditions that trigger transitions are written beside the arrows. $ur diagram has two self-transition" one on (etti"g SSN and another on (etti"g PIN.

dummy states that terminate the action.

B* COMPONENT AND DEPLOYMENT DIA(RAMS c#m'#"e"t is a code module. )omponent diagrams are physical analogs of class diagram. De'l#&me"t diagrams show the physical configurations of software and hardware. The following deployment diagram shows the relationships among software and hardware components involved in real estate transactions.

http://csetube.co.nr/

ht

tp

The initial state %blac! circle& is a dummy to start the action. 6inal states are also

://

cs

et

ub

e.c

o.

nr

; ;

http://csetube.co.nr/

ht

tp

The software architecture is a fairly large topic+ we will only introduce one possible solution %the most common& here. s we have finished the re*uirement analysis part of the first iteration and are ready to move on to design we can loo! at a larger scale. The design of a typical $$ system is based on several architectural layers" such as a U- layer" an application logic %or #domain#& layer" and so forth.

://

L#gical Arc$itect!re a"d UML Pac:age Diagrams

cs

et

ub

)omponents are shown as rectangles with two tabs at the upper left.

e.c

The physical hardware is made up of "#des. 1ach component belongs on a node.

o.

nr

L#gical arc$itect!re !si"g a UML 'ac:age diagram*

http://csetube.co.nr/

ht

tp

://

cs

et

ub

e.c

o.

nr

; ; ;

UML pac!age diagram provides a way to group elements. UML pac!age can group anything+ classes" other pac!ages" use cases" and so on. 3esting pac!ages is very common. -t is common to want to show dependency %a coupling& between pac!ages so that developers can see the large-scale coupling in the system. UML pac!age represents a namespace so that" for e0ample" a .ate class may be defined in two pac!ages. -f you need to provide fully-*ualified names" the UML notation is" for e0ample" java++util++.ate in the case that there was an outer pac!age named #java# with a nested pac!age named #util# with a .ate class.

http://csetube.co.nr/

ht

tp

Desig"i"g /it$ La&ers

://

cs

et

ub

e.c

o.

nr

http://csetube.co.nr/

ht

tp

://

cs

et

ub

Guidelines < The responsibilities of the objects in a layer should be strongly related to each other and should not be mi0ed with responsibilities of other layers. 6or e0ample" objects in the U- layer should focus on U- wor!" such as creating windows and widgets" capturing mouse and !eyboard events" and so forth. $bjects in the application logic or #domain# layer should focus on application logic" such as calculating a sales total or ta0es" or moving a piece on a game board. < U- objects should not do application logic. 6or e0ample" a =ava Swing =6rame %window& object should not contain logic to calculate ta0es or move a game piece. nd on the other hand" application logic classes should not trap U- mouse or !eyboard events. That would violate a clear separation of concerns and maintaining high cohesion + basic architectural principles. T$e M#delC4ie/ Se'arati#" Pri"ci'le ; The Model->iew Separation principle states that model %domain& objects should not have direct !nowledge of view %U-& objects. So" for e0ample" a /egister or Sale object should not directly send a message to a GU- window object ,rocessSale6rame" as!ing it to display something" change color" close" and so forth.

e.c

o.

nr