Ooad UNIT 5 Notes

OOAD UNIT 5 6 SEM CSE ANNA UNIVERSITY
UNIT 5 - UML state diagrams and modeling
State diagrams are used to describe the behavior of a system. State diagrams describe all of the possible
states of an object as events occur. Each diagram usually represents objects of a single class and track the
different states of its objects through the system.
When to Use: State Diagrams

Use state diagrams to demonstrate the behavior of an object through many use cases of the system. Only
use state diagrams for classes where it is necessary to understand the behavior of the object through the
entire system. Not all classes will require a state diagram and state diagrams are not useful for describing
the collaboration of all objects in a use case. State diagrams are other combined with other diagrams such
as interaction diagrams and activity diagrams.
How to Draw: State Diagrams

State diagrams have very few elements. The basic elements are rounded boxes representing the state of
the object and arrows indicting the transition to the next state. The activity section of the state symbol
depicts what activities the object will be doing while it is in that state.
All state diagrams being with an initial state of the object. This is the state of the object when it is
created. After the initial state the object begins changing states. Conditions based on the activities can
determine what the next state the object transitions to.
Below is an example of a state diagram might look like for an Order object. When the object enters the
Checking state it performs the activity "check items." After the activity is completed the object
transitions to the next state based on the conditions [all items available] or [an item is not available]. If an
item is not available the order is canceled. If all items are available then the order is dispatched. When
the object transitions to the Dispatching state the activity "initiate delivery" is performed. After this
activity is complete the object transitions again to the Delivered state.
Powered by www.technoscriptz.com Page 1

State diagrams can also show a super-state for the object. A super-state is used when many transitions
lead to the a certain state. Instead of showing all of the transitions from each state to the redundant state a
super-state can be used to show that all of the states inside of the super-state can transition to the
redundant state. This helps make the state diagram easier to read.
The diagram below shows a super-state. Both the Checking and Dispatching states can transition into the
Canceled state, so a transition is shown from a super-state named Active to the state Cancel. By contrast,
the state Dispatching can only transition to the Delivered state, so we show an arrow only from the
Dispatching state to the Delivered state.
Activity Diagrams
Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar to state
diagrams because activities are the state of doing something. The diagrams describe the state of activities
by showing the sequence of activities performed. Activity diagrams can show activities that are
conditional or parallel.

When to Use: Activity Diagrams

Activity diagrams should be used in conjunction with other modeling techniques such as interaction
diagrams and state diagrams. The main reason to use activity diagrams is to model the workflow behind
the system being designed. Activity Diagrams are also useful for: analyzing a use case by describing
what actions need to take place and when they should occur; describing a complicated sequential
algorithm; and modeling applications with parallel processes.
However, activity diagrams should not take the place of interaction diagrams and state diagrams.
Activity diagrams do not give detail about how objects behave or how objects collaborate.
How to Draw: Activity Diagrams

Activity diagrams show the flow of activities through the system. Diagrams are read from top to bottom
and have branches and forks to describe conditions and parallel activities. A fork is used when multiple
activities are occurring at the same time. The diagram below shows a fork after activity1. This indicates
that both activity2 and activity3 are occurring at the same time. After activity2 there is a branch. The
branch describes what activities will take place based on a set of conditions. All branches at some point
are followed by a merge to indicate the end of the conditional behavior started by that branch. After the
merge all of the parallel activities must be combined by a join before transitioning into the final activity
state.
Below is a possible activity diagram for processing an order. The diagram shows the flow of actions in
the system's workflow. Once the order is received the activities split into two parallel sets of activities.
One side fills and sends the order while the other handles the billing. On the Fill Order side, the method

of delivery is decided conditionally. Depending on the condition either the Overnight Delivery activity or
the Regular Delivery activity is performed. Finally the parallel activities combine to close the order.
Physical Diagrams:
There are two types of physical diagrams: deployment diagrams and component diagrams.
Deployment diagrams show the physical relationship between hardware and software in a system.
Component diagrams show the software components of a system and how they are related to each other.
These relationships are called dependencies.
When to Use: Physical Diagrams

Physical diagrams are used when development of the system is complete. Physical diagrams are used to
give descriptions of the physical information about a system.
How to Draw: Physical Diagrams

Many times the deployment and component diagrams are combined into one physical diagram. A
combined deployment and component diagram combines the features of both diagrams into one
diagram.
The deployment diagram contains nodes and connections. A node usually represents a piece of hardware
in the system. A connection depicts the communication path used by the hardware to communicate and
usually indicates a method such as TCP/IP.

The component diagram contains components and dependencies. Components represent the physical
packaging of a module of code. The dependencies between the components show how changes made to
one component may affect the other components in the system. Dependencies in a component diagram
are represented by a dashed line between two or more components. Component diagrams can also show
the interfaces used by the components to communicate to each other.
The combined deployment and component diagram below gives a high level physical description of the
completed system. The diagram shows two nodes which represent two machines communicating through
TCP/IP. Component2 is dependent on component1, so changes to component 2 could affect component1.
The diagram also depicts component3 interfacing with component1. This diagram gives the reader a
quick overall view of the entire system.

UML MODELING
It is very important to distinguish between the UML model. Different diagrams are used for different type
of UML modeling. There are three important type of UML modelings:
Structural modeling:
Structural modeling captures the static features of a system. They consist of the followings:
Classes diagrams
Objects diagrams
Deployment diagrams
Package diagrams
Composite structure diagram
Component diagram
Structural model represents the framework for the system and this framework is the place where all other
components exist. So the class diagram, component diagram and deployment diagrams are the part of
structural modeling. They all represent the elements and the mechanism to assemble them. But the
structural model never describes the dynamic behavior of the system. Class diagram is the most widely
used structural diagram.
Behavioral Modeling:
Behavioral model describes the interaction in the system. It represents the interaction among the structural
diagrams. Behavioral modeling shows the dynamic nature of the system. They consist of the following:
Activity diagrams
Interaction diagrams
Use case diagrams
All the above show the dynamic sequence of flow in a system.
Architectural Modeling:
Architectural model represents the overall framework of the system. It contains both structural and
behavioral elements of the system. Architectural model can be defined as the blue print of the entire
system. Package diagram comes under architectural modeling.
UML Operation Contract
A UML Operation contract identifies system state changes when an operation happens. Effectively, it will
define what each system operation does. An operation is taken from a system sequence diagram. It is a
single event from that diagram. A domain model can be used to help generate an operation contract. The
domain model can be marked as follows to help with the operation contract:
Green - Pre existing concepts and associations.
Blue - Created associations and concepts.
Red - Destroyed concepts and associations.
Operation Contract Syntax

Name: appropriateName
Responsibilities: Perform a function
Cross References: System functions and Use Cases
Exceptions: none
Preconditions: Something or some relationship exists
Postconditions: An association was formed
When making an operation contract, think of the state of the system before the action (snapshot) and the
state of the system after the action (a second snapshot). The conditions both before and after the action
should be described in the operation contract. Do not describe how the action or state changes were done.
The pre and post conditions describe state, not actions.
Typical postcondion changes:

Object attributes were changed.
An instance of an object was created.
An association was formed or broken.
Postconditions are described in the past tense. They declare state changes to the system. Fill in the name,
then responsibilities, then postconditions.
UML Deployment Diagram
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. But 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:

Visualize 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. It is related to the component diagram.
Because the components are deployed using the deployment diagrams. A deployment diagram consists of
nodes. Nodes are nothing but physical hardwares used to deploy the application.
Deployment diagrams are useful for system engineers. An efficient deployment diagram is very important
because it controls the following parameters
Performance
Scalability
Maintainability
Portability
So before drawing a deployment diagram the following artifacts should be identified:

Nodes
Relationships among node
The following deployment diagram is a sample to give an idea of the deployment view of order
management system. Here 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 1, server 2 and server 3. 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 complex business processes. Only efficient software
applications are not sufficient to meet business requirements. Business requirements can be described as
to support increasing number of users, quick response time etc.
To meet these types of requirements hardware components should be designed efficiently and in a cost
effective way.
Now a day's software applications are very complex 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.
Forward and reverse engineering.

Deployment Diagrams
Deployment diagram shows execution architecture of systems that represe nt the assignment
(deployment) of software artifacts to deployment targets (usually nodes).
Nodes represent either hardware devices or software execution environments. They could be
connected through communication paths to create network systems of arbitrary complexity.
Artifacts represent concrete elements in the physical world that are the result of a development
process and are deployed on nodes.
Note, that components were directly deployed to nodes in UML 1.x deployment diagrams. In
UML 2.x artifacts are deployed to nodes, and artifacts could manifest components. So
components are now deployed to nodes indirectly through artifacts.
The following nodes and edges are typically drawn in a UML deployment diagram: artifact,
association between artifacts, dependency between artifacts, component, manifestation, node,
device, execution environment, composition of nodes, communication path, deployment
specification, deployment specification dependency, deployment specification association,
deployment.
You can find some deployment diagrams examples here:
Web Application Deployment
Clustered Deployment of J2EE Web Application
Apple iTunes Deployment
Artifact
An artifact is a classifier that represents some physical entity, piece of information that is used
or is produced by a software development process, or by deployment and operation of a system.
Artifact is source of a deployment to a node. A particular instance (or "copy") of an artifact is
deployed to a node instance.
Artifacts may have prope rties that represent features of the artifact, and operations that can be
performed on its instances. Artifacts have fileName attribute - a concrete name that is used to
refer to the artifact in a physical context - e.g. file name or URI.
Some real life examples of artifacts are:
model file
source file
script
binary executable file
text document
mail message
table in a database
The UML Standard Profile defines several standard stereotypes that apply to artifacts:
«file» A physical file in the context of the system developed.
Standard stereotypes - subclasses of «file»:
«document» A generic file that is not a «source» file or «executable».
«source» A source file that can be compiled into an executable file.
«library» A static or dynamic library file.
«executable» A program file that can be executed on a computer system.
«script» A script file that can be interpreted by a computer system.
Standard UML 1.x stereotype that is now obsolete:

«table» Table in database.
Standard stereotypes can be further specialized into implementation and platform specific
stereotypes in profiles. For example, an EJB profile might define «jar» as a subclass of
«executable» for executable Java archives. Specific profiles are expected to stereotype artifact to
model sets of files (e.g., as characterized by a "file extension" on a file system).
Artifacts are deployed to a deployment target. Instance specification was extended in UML to
allow instances of artifacts to be deployed artifacts in a deployment relationship.
An artifact is presented using an ordinary class rectangle with the keyword «artifact». Examples
in UML specification also show document icon in upper right corner.
Artifact web-app.war
Source file artifact UserServices.cs
Library commons.dll
Alternatively, artifact may be depicted by an icon.
Artifact web-tools- lib.jar

Optionally, the underlining of the name of an artifact instance may be omitted, as the context is
assumed to be known to users.
Associations Between Artifacts
Artifacts can be involved in associations to other artifacts, e.g. composition associations. For
instance, a deployment descriptor artifact for a component may be contained within the artifact
that manifests that component. In that way, the component and its descriptor are deployed to a
node instance as one artifact instance.

Application book-club.ear artifact contains EJB user-service.jar artifact and deployment

descriptor.
Dependency Between Artifacts
Artifacts can be involved in dependency relationship with other artifacts.
Dependency between artifacts is notated in the same way as general dependency, i.e. as a general
dashed line with an open arrow head directed from client artifact to supplier artifact.
The book-club.war artifact depends on web-tools-lib.jar artifact.

Artifact Manifestation
Manifestation is an abstraction relationship which represents the concrete physical rendering of
one or more model elements by an artifact or utilization of the model elements in the
construction or generation of the artifact. An artifact manifests one or more model elements.
Note, that since UML 2.0 artifacts can manifest any packageable element, not just component as
it was in previous versions of UML.
The artifact owns the manifestations, each representing the utilization of a packageable element.
Specific profiles are expected to stereotype the manifestation relationship to indicate particular
forms of manifestation. For example, «tool generated» and «custom code » might be two
manifestations for different classes embodied in an artifact.
A manifestation is notated in the same way as abstraction dependency, i.e. as a dashed line with
an open arrow head directed from artifact to packageable element, (e.g. to component or
package) and is labeled with the keyword «manifest».
EJB component UserService and skeleton of web services are manifested by EJB module user-
service.jar artifact
In UML 1.x, the concept of manifestation was referred to as implementation and annotated as
«imple ment». Since this was one of the many uses of the word "implementation" this has been
replaced in UML 2.x by «manifest».
Deployment Target
Artifacts are deployed to deployment targets. Deployme nt target is the location for a deployed
artifact.
Deployment target owns the set of deployment that target it.
Deployment target is specialized by:
node
property
Instance specification was extended in UML 2.0 to allow instance of a node to be deployment
target in a deployment relationship.
Property was also extended in UML 2.0 with the capability of being a deployment target in a
deployment relationship. This enables modeling the deployment to hierarchical nodes that have
properties functioning as internal parts.
Deployment target has no specific notation by itself, see notations for subclasses.
Node
A Node is a deployment target which represents computational resource upon which artifacts
may be deployed for execution.
A Node is shown as a perspective, 3-dimensional view of a cube.
Application Server Node

Node is associated with a Deployment of an Artifact. It is also associated with a set of
Elements that are deployed on it. This is a derived association in that these Packageable
Ele ments are involved in a Manifestation of an Artifact that is deployed on the Node.
Nodes may have an internal structure defined in terms of parts and connectors associated with
them for advanced modeling applications. Parts of node could be solely of type Node.
Hierarchical nodes (i.e., nodes within nodes) can be modeled using composition associations,
or by defining an internal structure for advanced modeling applications.
Nodes can be interconnected through communication paths to define network structures.
Communication paths can be defined between nodes such as “application server” and “client
workstation” to define the possible communication paths between nodes. Specific network
topologies can then be defined through links between node instances.
Node is specialized by:
device
execution environment
Device
A device is a subclass of node which represents a physical computational resource with
processing capability upon which artifacts may be deployed for execution.

A device is rendered as a node (perspective, 3-dimensional view of a cube) annotated with

keyword «device».
Application Server device

Device may be depicted using custom icon.
UML provides no standard stereotypes for devices. Examples of non-normative stereotypes for
devices are:
«application server»
«client workstation»
«mobile device»
«embedded device»
Profiles, stereotypes, and tagged values could be used to provide custom icons and properties for
the devices.
Application Server device depicted using custom icon
Computer stereotype with tags applied to Device class.

Database Server device depicted using custom icon
Mobile smartphone device depicted using custom icon

Devices may be complex (i.e., they may consist of other devices) where a physical machine is
decomposed into its elements, either through namespace ownership or through attributes that are
typed by Devices.
Execution Environment
An execution environment is a node that offers an execution environment for specific types of
component that are deployed on it in the form of executable artifacts. Components of the
appropriate type are deployed to specific execution environment nodes.
Execution environment implements a standard set of services that components require at
execution time (at the modeling level these services are usually implicit). For each deployment
of component, aspects of these services may be determined by properties in a deployment
specification for a particular kind of execution environment.
Execution environment is notated as a node (perspective, 3-dimensional view of a cube)
annotated with the standard stereotype «executionEnvironme nt».
Execution environment - J2EE Container

This «executionEnvironment» is pesky sesquipedalian to use. UML provides no other standard
stereotypes for execution environments. Examples of reasonable non-normative stereotypes are:
«OS»
«workflow engine»
«database system»
«J2EE container»

«web server»
«web browser»
Linux Operating System Execution Environment
Oracle 10g DBMS Execution Environment

An execution environment can optionally have an explicit interface of system level services that
can be used by the deployed elements, in those cases where the modeler wants to make the
execution environment software execution environment services explicit.
Composition of Nodes
Nodes may have an internal structure defined in terms of parts and connectors associated with
them for advanced modeling applications. Parts of node could be only of type node.
Hierarchical nodes (i.e., nodes within nodes) can be modeled using composite associations, or
by defining an internal structure for advanced modeling applications.
Application server box runs several web servers and J2EE serve rs
Execution environment is usually part of a general node or «device» which represents the
physical hardware environment on which this execution environment resides. Execution
environments can be nested (e.g., a database execution environment may be nested in an
operating system execution environment).

Several execution environments nested into server device

Execution environment instances are assigned to node instances by using composite associations
between nodes and execution environments, where the execution environment plays the role of
the part.
Communication Path
A communication path is an association between two deployme nt targets, through which they
are able to exchange signals and messages.
Communication path is notated as association, and it has no additional notation compared to
association.
Communication path between several application servers and database server.

Deployment Specification
A deployment specification is an artifact that specifies a set of deployment properties that
determine execution parameters of a component artifact that is deployed on a node. A
deployment specification can be aimed at a specific type of container for a components.
A deployment specification is a general mechanism to parameterize a deployme nt relationship,
as is common in various hardware and software technologies. The deployment specification
element is expected to be extended in specific component profiles. Non-normative examples of
the standard stereotypes that a profile might add to deployment specification are, for example,
«concurrencyMode» with tagged values {thread, process, none}, or «transactionMode» with
tagged values {transaction, nestedTransaction, none}.
A deployment specification at specification level is graphically displayed as a classifier
rectangle with optional deployment properties in a compartment.

The ejb-jar.xml deployment specification

An artifact that reifies or implements deployment specification properties is a deployment
descriptor. A deployment specification at instance level is graphically displayed as a classifier
rectangle with the name underlined and with deployment properties having specific values in a
compartment.
The ejb-jar.xml deployment descriptor

An instance of a deployment specification with specific values for deployment properties may be
contained in a complex artifact.
Deployment Specification Dependency

A deployme nt specification could be displayed as a classifier rectangle attached to a
component artifact using a regular dependency arrow pointing to deployed artifact.
The ejb-jar.xml deployment specification for user-service.ejb artifact.
Deployment Specification Association

Deployment Specification could be associated with the deployment of a component artifact on
a node. In this case deployment specification could be displayed as a classifier rectangle
attached to the deployment. Note, UML 2.2 specification shows this association as a dashed
line (while association is normally displayed as solid line.)

The ejb-jar.xml deployment specification attached to deployment.
Deployment
A deployme nt is dependency relationship which describes allocation of an artifact or artifact
instance to a de ployment target.
Accordingly, deployed artifact is an artifact or artifact instance that has been deployed to a
deployment target.
A component deployme nt is the deployment of one or more artifacts or artifact instances to a
deployment target, optionally parameterized by a deployment specification. Examples are
executables and configuration files.
The deployment relationship between a deployed artifact and a deployment target can be defined
at the “type” level and at the “instance level.”
For example, a „type level‟ deployment relationship can be defined between an “application
server” Node and an “order entry request handler” executable Artifact. At the „instance level‟ 3
specific instances “appserver1” ... “app-server3” may be the deployment target for six “request
handler*” instances.
For modeling complex deployment target models consisting of nodes with a composite structure
defined through „parts,‟ a Property (that functions as a part) may also be the target of a
deployment.
Deployment diagram shows deployed artifacts contained within a deployme nt target symbol.
The portfolio.ear artifact deployed on application server.

Deployment could also be shown using textual list of deployed artifacts within a deployment
target symbol.

The portfolio.ear, stocks.ear, weather.ear artifacts deployed on application server.

An alternative notation is to use a dependency labeled «deploy» that is drawn from the artifact to
the deployment target.
Deployment Diagram Example
Captures the distinct number of computers involved

Shows the communication modes employed
Component diagrams can be embedded into deployment diagrams effectively

Design Codes
In this post we‟ll see how deployment diagrams are used to model the physical architecture of a
system; we‟ll start from the most simple use of the deployment diagram in which we only
present the nodes and their inter-relationships, and complete the picture by including the
components and the applications that run in the nodes.
Connecting the Nodes

Very early in the system life time - deployment diagrams are used to show the nodes (computers,
virtual machines) and the external devices (if there are any) which construct the system. A „node‟
usually refers to a computer which can be stereotyped as server, client, workstation etc. A
„device‟ is a subclass of „node‟ which refers to a resource with processing capability such as
camera, printer, measurement instrument etc. The nodes and the devices are usually wired
though the „Communication Path‟ connector which illustrates the exchange of signals and
messages between both ends.

Notice that the client node is stereotyped as „pc-client‟ (indicated by the icon) and the server
node is stereotyped as „pc-server‟.
The following diagram shows the deployment architecture of a scalable, fault tolerant „Camera
control and image processing‟ system . The system consist of N servers, load balancer with
redundancy, and several clients.
The client machines present live state of all the cameras available in the system, and allow the
user to control the cameras and initiate all kind of activities on the servers. The load balancer
process the inputs that it receives from the clients and send the appropriate instructions to the
appropriate server, it is designed to gracefully scale to increasing number of servers. Since the
load balancer is a single point of failure, a passive load balancer (that maintains copy of the
active load balancer state) run in the background, ready to replace the active load balancer in
case of a crush. All the servers run the same application, they support different kinds of cameras
and can be configured to manage up to 200 cameras of different kinds.

Including the Components

In the next stage we are ready to put in the components that run in the physical nodes. As
indicated in the previous post, when using components to model the physical architecture of a
system (as in this case) the term „component‟ refers to dll, or some executable.
The following figure shows snapshot of the above diagram with the addition of the components
that reside in the nodes.
As you can see the client node includes the „CamerasC2C.Client‟ component which uses
infrastructure level controls reside within „Company.Contorls‟ which includes classes which
derive from framework level controls (notice the use of stereotypes to divide the components to
levels/layers). The „CamerasC2C.Client‟ component communicate with the load balancer
„CamerasC2C.LoadBalance‟ component, which transfer instructions to the appropriate server
through the „IServer‟ interface. The server consist of 3rd party components that were shipped
with the cameras hardware, each component exposes interface tho ugh which the camera can be

controlled, the „CamerasC2C.Server.Cameras‟ component includes adapter classes which wrap

the 3rd party interfaces and expose matching interfaces that fit to the systems requirements and
speak the system language (uses system level classes etc), the „CamerasC2C.Server.Core‟
component uses the interfaces exposed by the „CamerasC2C.Server.Cameras‟ in order to
command the cameras as appropriate.
Presenting the Applications

In order to show the applications that run on the different nodes and the components that make
up the applications – we use artifact wired to nodes through the „deploy‟ connector, and wired to
components through the „manifest‟ connecter.
Presenting External Applications

In order to show the way in which the system interact with external applications - artifacts can be
used to represent the external application as illustrated in the following diagrams.

UML Component Diagram:
Overview:
Component diagrams are different in terms of nature and behaviour. Component diagrams are used to
model physical aspects of a system.
Now the question is what are these physical aspects? Physical aspects are the elements like executables,
libraries, files, documents etc which resides in a node.
So component diagrams are used to visualize the organization and relationships among components in a
system. These diagrams are also used to make executable systems.
Purpose:
Component diagram is a special kind of diagram in UML. The purpose is also different from all other
diagrams discussed so far. It does not describe the functionality of the system but it describes the
components used to make those functionalities. So from that point component diagrams are used to
visualize the physical components in a system. These components are libraries, packages, files etc.

Component diagrams can also be described as a static implementation view of a system. Static
implementation represents the organization of the components at a particular moment.
A single component diagram cannot represent the entire system but a collection of diagrams are used to
represent the whole.
So the purpose of the component diagram can be summarized as:

Visualize the components of a system.
Construct executables by using forward and reverse engineering.
Describe the organization and relationships of the components.
How to draw Component Diagram?

Component diagrams are used to describe the physical artifacts of a system. This artifact includes files,
executables, libraries etc. So the purpose of this diagram is different, Component diagrams are used
during the implementation phase of an application. But it is prepared well in advance to visualize the
implementation details.
Initially the system is designed using different UML diagrams and then when the artifacts are re ady
component diagrams are used to get an idea of the implementation. This diagram is very important
because without it the application cannot be implemented efficiently. A well prepared component diagram
is also important for other aspects like application performance, maintenance etc.
So before drawing a component diagram the following artifacts are to be identified clearly:
Files used in the system.
Libraries and other artifacts relevant to the application.
Relationships among the artifacts.
Now after identifying the artifacts the following points needs to be followed:
Use a meaningful name to identify the component for which the diagram is to be drawn.
Prepare a mental layout before producing using tools.
Use notes for clarifying important points.
The following is a component diagram for order management system. Here the artifacts are files. So the
diagram shows the files in the application and their relationships. In actual the component diagram also
contains dlls, libraries, folders etc. In the following diagram four files are identified and their relationships
are produced. Component diagram cannot be matched directly with other UML diagrams discussed so far.
Because it is drawn for completely different purpose.
So the following component diagram has been drawn considering all the points mentioned above:

Where to use Component Diagrams?

We have already described that component diagrams are used to visualize the static implementation view
of a system. Component diagrams are special type of UML diagrams used for different purposes.
These diagrams show the physical components of a system. To clarify it, we can say that component
diagrams describe the organization of the components in a system. Organization can be further described
as the location of the components in a system. These components are organized in a special way to meet
the system requirements.
As we have already discussed those components are libraries, files, executables etc. Now before
implementing the application these components are to be organized. This component organization is also
designed separately as a part of project execution.
Component diagrams are very important from implementation perspective. So the implementation team
of an application should have a proper knowledge of the component details.
Now the usage of component diagrams can be described as:
Model the components of a system.
Model database schema.
Model executables of an application.
Model system's source code.
Basic Component Diagram Symbols and Notations
Component
A component is a physical building block of the system. It is represented as a rectangle with tabs.
Learn how to resize grouped objects like components.
Interface
An interface describes a group of operations used or created by components.
Dependencies
Draw dependencies among components using dashed arrows.
Learn about line styles in SmartDraw.
Explain all elements of a Component diagram.
Ele ments of a component diagram:
Rectangle: A single component is described using a rectangle and having the component‟s name
inside it. <<Component>>Component Name
Additional compartments: Additional compartments are stacked below the component name.
Inte rfaces provided/required: Another compartment exists for displaying the interface
provided and required by the component.

Relationships: A lollipop and socket notation is used along with showing dependency arrows.
Dependency arrow points towards the needed socket and arrowhead connects with provider‟s
lollipop.
Subsystem: A subsystem is represented using a rectangle with stereotype <>subsystem name.

Ooad UNIT 5 Notes

Uploaded by

Copyright:

Available Formats

Ooad UNIT 5 Notes

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ooad UNIT 5 Notes

Uploaded by

Copyright:

Available Formats

OOAD UNIT 5 6 SEM CSE ANNA UNIVERSITY

UNIT 5 - UML state diagrams and modeling

When to Use: State Diagrams

How to Draw: State Diagrams

Powered by www.technoscriptz.com Page 1

Powered by www.technoscriptz.com Page 2

When to Use: Activity Diagrams

How to Draw: Activity Diagrams

Powered by www.technoscriptz.com Page 3

When to Use: Physical Diagrams

How to Draw: Physical Diagrams

Powered by www.technoscriptz.com Page 4

Powered by www.technoscriptz.com Page 5

UML Operation Contract

Operation Contract Syntax

Powered by www.technoscriptz.com Page 6

Responsibilities: Perform a function

Cross References: System functions and Use Cases

Preconditions: Something or some relationship exists

Postconditions: An association was formed

Typical postcondion changes:

UML Deployment Diagram

Powered by www.technoscriptz.com Page 7

The purpose of deployment diagrams can be described as:

How to draw Component Diagram?

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

Powered by www.technoscriptz.com Page 8

Where to use Deployment Diagrams?

So the usage of deployment diagrams can be described as follows:

Powered by www.technoscriptz.com Page 9

Standard UML 1.x stereotype that is now obsolete:

Source file artifact UserServices.cs

Artifact web-tools- lib.jar

Powered by www.technoscriptz.com Page 11

Application book-club.ear artifact contains EJB user-service.jar artifact and deployment

The book-club.war artifact depends on web-tools-lib.jar artifact.

Application Server Node

Powered by www.technoscriptz.com Page 13

A device is rendered as a node (perspective, 3-dimensional view of a cube) annotated with

Application Server device

Application Server device depicted using custom icon

Computer stereotype with tags applied to Device class.

Powered by www.technoscriptz.com Page 14

Database Server device depicted using custom icon

Mobile smartphone device depicted using custom icon

Execution environment - J2EE Container

Powered by www.technoscriptz.com Page 15

Linux Operating System Execution Environment

Oracle 10g DBMS Execution Environment

Powered by www.technoscriptz.com Page 16

Several execution environments nested into server device

Communication path between several application servers and database server.

Powered by www.technoscriptz.com Page 17

The ejb-jar.xml deployment specification

The ejb-jar.xml deployment descriptor

Deployment Specification Dependency

The ejb-jar.xml deployment specification for user-service.ejb artifact.

Deployment Specification Association

Powered by www.technoscriptz.com Page 18