Interaction Diagrams

Previous | Home | Next Interaction diagrams model the behavior of use cases by describing the way groups of objects interact to complete the task. he two kinds of interaction diagrams are sequence and collaboration diagrams. his example is only meant as an introduction to the !"# and interaction diagrams. If you would like to learn more see the $esources page for a list of more detailed resources on !"#.

When to Use: Interaction Diagrams

Interaction diagrams are used when you want to model the behavior of several objects in a use case. hey demonstrate how the objects collaborate for the behavior. Interaction diagrams do not give a in depth representation of the behavior. If you want to see what a specific object is doing for several use cases use a state diagram. o see a particular behavior over many use cases or threads use an activity diagrams. %

How to Draw: Interaction Diagrams

&e'uence diagrams( collaboration diagrams( or both diagrams can be used to demonstrate the interaction of objects in a use case. &e'uence diagrams generally show the se'uence of events that occur. )ollaboration diagrams demonstrate how objects are statically connected. *oth diagrams are relatively simple to draw and contain similar elements. % Sequence diagrams: &e'uence diagrams demonstrate the behavior of objects in a use case by describing the objects and the messages they pass. the diagrams are read left to right and descending. he example below shows an object of class % start the behavior by sending a message to an object of class +. "essages pass between the different objects until the object of class % receives the final message.

*elow is a slightly more complex example. he light blue vertical rectangles the objects activation while the green vertical dashed lines represent the life of the object. he green vertical rectangles represent when a particular object has control. he represents when the object is destroyed. his diagrams also shows conditions for messages to be sent to other object. he condition is listed between brackets next to the message. ,or example( a -condition. has to be met before the object of class + can send a message/0 to the object of class 1.

he next diagram shows the beginning of a se'uence diagram for placing an order. he object an 2rder 3ntry 4indow is created and sends a message to an 2rder object to prepare the order. Notice the the names of the objects are followed by a colon. he names of the classes the objects belong to do not have to be listed. However the colon is re'uired to denote that it is the name of an object following the objectName5className naming system. Next the 2rder object checks to see if the item is in stock and if the -In&tock. condition is met it sends a message to create an new 6elivery Item object.

he next diagrams adds another conditional message to the 2rder object. If the item is -2ut2f&tock. it sends a message back to the 2rder 3ntry 4indow object stating that the object is out of stack.

his simple diagram shows the se'uence that messages are passed between objects to complete a use case for ordering an item. Collaboration diagrams: )ollaboration diagrams are also relatively easy to draw. hey show the relationship

between objects and the order of messages passed between them. he objects are listed as icons and arrows indicate the messages being passed between them. he numbers next to the messages are called se'uence numbers. 7s the name suggests( they show the se'uence of the messages as they are passed between the objects. here are many acceptable se'uence numbering schemes in !"#. 7 simple %( +( 1... format can be used( as the example below shows( or for more detailed and complex diagrams a %( %.% (%.+( %.+.%... scheme can be used.

he example below shows a simple collaboration diagram for the placing an order use case. his time the names of the objects appear after the colon( such as 52rder 3ntry 4indow following the objectName5className naming convention. his time the class name is shown to demonstrate that all of objects of that class will behave the same way.

Class Diagrams
Previous | Home | Next )lass diagrams are widely used to describe the types of objects in a system and their relationships. )lass diagrams model class structure and contents using design elements such as classes( packages and objects.+ )lass diagrams describe three different perspectives when designing a system( conceptual( specification( and implementation.% hese perspectives become evident as the diagram is created and help solidify the design. his example is only meant as an introduction to the !"# and class diagrams. If you would like to learn more see the $esources page for more detailed resources on !"#. )lasses are composed of three things5 a name( attributes( and operations. *elow is an example of a class.

)lass diagrams also display relationships such as containment( inheritance( associations and others. + *elow is an example of an associative relationship5

he association relationship is the most common relationship in a class diagram. he association shows the relationship between instances of classes. ,or example( the class 2rder is associated with the class )ustomer. he multiplicity of the association denotes the number of objects that can participate in then relationship.% ,or example( an 2rder object can be associated to only one

customer( but a customer can be associated to many orders. 7nother common relationship in class diagrams is a generali8ation. 7 generali8ation is used when two classes are similar( but have some differences. #ook at the generali8ation below5

In this example the classes )orporate )ustomer and Personal )ustomer have some similarities such as name and address( but each class has some of its own attributes and operations. he class )ustomer is a general form of both the )orporate )ustomer and Personal )ustomer classes. % his allows the designers to just use the )ustomer class for modules and do not re'uire in9depth representation of each type of customer.

When to Use: Class Diagrams

)lass diagrams are used in nearly all 2bject 2riented software designs. !se them to describe the )lasses of the system and their relationships to each other.

How to Draw: Class Diagrams

)lass diagrams are some of the most difficult !"# diagrams to draw. o draw detailed and useful diagrams a person would have to study !"# and 2bject 2riented principles for a long time. herefore( this page will give a very high level overview of the process. o find list of where to find more information see the $esources page. *efore drawing a class diagram consider the three different perspectives of the system the diagram will present: conceptual( specification( and implementation. ry not to focus on one perspective and

try see how they all work together. 4hen designing classes consider what attributes and operations it will have. hen try to determine how instances of the classes will interact with each other. hese are the very first steps of many in developing a class diagram. However( using just these basic techni'ues one can develop a complete view of the software system.

his example is only meant as an introduction to the !"# and use cases. If you would like to learn more see the $esources page for more detailed resources on !"#.

Activity Diagrams
Previous | Home | Next 7ctivity diagrams describe the workflow behavior of a system. 7ctivity diagrams are similar to state diagrams because activities are the state of doing something. he diagrams describe the state of activities by showing the se'uence of activities performed. 7ctivity diagrams can show activities that are conditional or parallel.

When to Use: Activity Diagrams

7ctivity diagrams should be used in conjunction with other modeling techni'ues such as interaction diagrams and state diagrams. he main reason to use activity diagrams is to model the workflow behind the system being designed. 7ctivity 6iagrams are also useful for5 analy8ing a use case by describing what actions need to take place and when they should occur: describing a complicated se'uential algorithm: and modeling applications with parallel processes. % However( activity diagrams should not take the place of interaction diagrams and state diagrams. 7ctivity diagrams do not give detail about how objects behave or how objects collaborate. %

How to Draw: Activity Diagrams

7ctivity diagrams show the flow of activities through the system. 6iagrams are read from top to bottom and have branches and forks to describe conditions and parallel activities. 7 fork is used when multiple activities are occurring at the same time. he diagram below shows a fork after activity%. his indicates that both activity+ and activity1 are occurring at the same time. 7fter activity+ there is a branch. he branch describes what activities will take place based on a set of conditions. 7ll branches at some point are followed by a merge to indicate the end of the conditional behavior started by that branch. 7fter the merge all of the parallel activities must be combined by a join before transitioning into the final activity state.

*elow is a possible activity diagram for processing an order. he diagram shows the flow of actions in the system;s workflow. 2nce the order is received the activities split into two parallel sets of activities. 2ne side fills and sends the order while the other handles the billing. 2n the ,ill 2rder side( the method of delivery is decided conditionally. 6epending on the condition either the 2vernight 6elivery activity or the $egular 6elivery activity is performed. ,inally the parallel activities combine to close the order.

Ty es o! U"# Diagrams
Previous | Home | Next 3ach !"# diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction. !"# diagrams commonly created in visual modeling tools include5% Use Case Diagram displays the relationship among actors and use cases. % Class Diagram models class structure and contents using design elements such as classes( packages and objects. It also displays relationships such as containment( inheritance( associations and others. % Interaction Diagrams Sequence Diagram displays the time se'uence of the objects participating in the interaction. his consists of the vertical dimension /time0 and hori8ontal dimension /different objects0. % Collaboration Diagram displays an interaction organi8ed around the objects and their links to one another. Numbers are used to show the se'uence of messages.%

State Diagram displays the se'uences of states that an object of an interaction goes through during its life in response to received stimuli( together with its responses and actions.% Activity Diagram displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. his diagram focuses on flows driven by internal processing. % $hysical Diagrams Com onent Diagram displays the high level packaged structure of the code itself. 6ependencies among components are shown( including source code components( binary code components( and executable components. &ome components exist at compile time( at link time( at run times well as at more than one time.% De loyment Diagram displays the configuration of run9time processing elements and the software components( processes( and objects that live on them. &oftware component instances represent run9time manifestations of code units.%

Overview:
Deployment diagrams are used to visualize the topology of the physical components of a system where the software components are deployed. So deployment diagrams are used to describe the static deployment view of a system. Deployment diagrams consist of nodes and their relationships.

Purpose:
The name Deployment itself describes the purpose of the diagram. Deployment diagrams are used for describing the hardware components where software components are deployed. Component diagrams and deployment diagrams are closely related. Component diagrams are used to describe the components and deployment diagrams shows how they are deployed in hardware. UML is mainly designed to focus on software artifacts of a system. ut these two diagrams are special diagrams used to focus on software components and hardware components. So most of the UML diagrams are used to handle logical components but deployment diagrams are made to focus on hardware topology of a system. Deployment diagrams are used by the system engineers. The purpose of deployment diagrams can be described as!

"isualize hardware topology of a system. Describe the hardware components used to deploy software components. Describe runtime processing nodes.

How to draw Component Diagram?

Deployment diagram represents the deployment view of a system. #t is related to the component diagram. ecause the components are deployed using the deployment diagrams. $ deployment diagram consists of nodes. %odes are nothing but physical hardwares used to deploy the application. Deployment diagrams are useful for system engineers. $n efficient deployment diagram is very important because it controls the following parameters

&erformance Scalability Maintainability &ortability

So before drawing a deployment diagram the following artifacts should be identified!

%odes 'elationships among nodes

The following deployment diagram is a sample to give an idea of the deployment view of order management system. (ere we have shown nodes as!

Monitor Modem Caching server Server

The application is assumed to be a web based application which is deployed in a clustered environment using server )* server + and server ,. The user is connecting to the application using internet. The control is flowing from the caching server to the clustered environment. So the following deployment diagram has been drawn considering all the points mentioned above!

Where to use Deployment Diagrams?

Deployment diagrams are mainly used by system engineers. These diagrams are used to describe the physical components -hardwares.* their distribution and association. To clarify it in details we can visualize deployment diagrams as the hardware components/nodes on which software components reside. Software applications are developed to model comple0 business processes. 1nly efficient software applications are not sufficient to meet business re2uirements. usiness re2uirements can be described as to support increasing number of users* 2uic3 response time etc. To meet these types of re2uirements hardware components should be designed efficiently and in a cost effective way.

%ow a day4s software applications are very comple0 in nature. Software applications can be stand alone* web based* distributed* mainframe based and many more. So it is very important to design the hardware components efficiently. So the usage of deployment diagrams can be described as follows!

To model the hardware topology of a system. To model embedded system. To model hardware details for a client/server system. To model hardware details of a distributed application. 5orward and reverse engineering.