EXPERIMENT-5

AIM: Draw the sequence diagram for any two scenarios.

THEORY:
Sequence Diagram Document
The Sequence Diagram Document should contain the following information:
 A sequence diagram for each Use case of your system.

 A brief description on the symbols used in the sequence diagram explaining the reason for the usage of
that particular symbol.

 A brief description on the flow of each event in each sequence diagram.

Basic Sequence Diagram Notations

Class Roles or Participants
Class roles describe the way an object will behave in context. Use the UML object symbol to illustrate class
roles, but don't list object attributes.

Activation or Execution Occurrence

Activation boxes represent the time an object needs to complete a task. When an object is busy executing
a process or waiting for a reply message, use a thin gray rectangle placed vertically on its lifeline.

Messages
Messages are arrows that represent communication between objects. Use half-arrowed lines to represent
asynchronous messages. Asynchronous messages are sent from an object that will not wait for a response
from the receiver before continuing its tasks. For message types, see below.

Lifelines
Lifelines are vertical dashed lines that indicate the object's presence over time.
Destroying Objects
Objects can be terminated early using an arrow labeled "<< destroy >>" that points to an X. This object is
removed from memory. When that object's lifeline ends, you can place an X at the end of its lifeline to
denote a destruction occurrence.

Loops
A repetition or loop within a sequence diagram is depicted as a rectangle. Place the condition for exiting
the loop at the bottom left corner in square brackets [ ].
Types of Messages in Sequence Diagrams

Synchronous Message
A synchronous message requires a response before the interaction can continue. It's usually drawn using a
line with a solid arrowhead pointing from one object to another.

Asynchronous Message
Asynchronous messages don't need a reply for interaction to continue. Like synchronous messages, they
are drawn with an arrow connecting two lifelines; however, the arrowhead is usually open and there's no
return message depicted.

Reply or Return Message

A reply message is drawn with a dotted line and an open arrowhead pointing back to the original lifeline.

Self Message
A message an object sends to itself, usually shown as a U shaped arrow pointing back to itself.

Create Message
This is a message that creates a new object. Similar to a return message, it's depicted with a dashed line
and an open arrowhead that points to the rectangle representing the object created.
Delete Message
This is a message that destroys an object. It can be shown by an arrow with an x at the end.

Found Message
A message sent from an unknown recipient, shown by an arrow from an endpoint to a lifeline.

Lost Message
A message sent to an unknown recipient. It's shown by an arrow going from a lifeline to an endpoint, a
filled circle or an x.

Sequence Diagram Examples

The best way to understand sequence diagrams is to look at some examples of sequence diagrams.
Click on any of these sequence diagrams included in SmartDraw and edit them:

Sequence Diagram - Log On Scenario

Sequence Diagram - Shopping Cart
 EXPERIMENT-6
AIM: Draw the collaboration diagram.
THEORY:

Collaboration diagrams are used to show how objects interact to perform the behavior of a particular use
case, or a part of a use case. Along with sequence diagrams, collaborations are used by designers to define
and clarify the roles of the objects that perform a particular flow of events of a use case. They are the
primary source of information used to determining class responsibilities and interfaces.

Unlike a sequence diagram, a collaboration diagram shows the relationships among the objects. Sequence
diagrams and collaboration diagrams express similar information, but show it in different ways.
Collaboration diagrams show the relationships among objects and are better for understanding all the
effects on a given object and for procedural design.

Contents of Collaboration Diagrams

You can have objects and actor instances in collaboration diagrams, together with links and messages
describing how they are related and how they interact. The diagram describes what takes place in the
participating objects, in terms of how the objects communicate by sending messages to one another. You
can make a collaboration diagram for each variant of a use case's flow of events.

A collaboration diagram that describes part of the flow of events of the use
case Receive Deposit Item in the Recycling-Machine System.

Objects

An object is represented by an object symbol showing the name of the object and its class underlined,
separated by a colon:

objectname :classname

You can use objects in collaboration diagrams in the following ways:

● An object's class can be unspecified. Normally you create a collaboration diagram with objects first and
specify their classes later.
● The objects can be unnamed, but you should name them if you want to discriminate different objects
of the same class.
● An object's class can itself be represented in a collaboration diagram, if it actively participates in the
collaboration.

Actors

Normally an actor instance occurs in the collaboration diagram, as the invoker of the interaction. If you
have several actor instances in the same diagram, try keeping them in the periphery of the diagram.

Links

Links are defined as follows:

● A link is a relationship among objects across which messages can be sent. In collaboration diagrams, a
link is shown as a solid line between two objects.
● An object interacts with, or navigates to, other objects through its links to these objects.
● A link can be an instance of an association, or it can be anonymous, meaning that its association is
unspecified.
● Message flows are attached to links, see Messages.

Messages

A message is a communication between objects that conveys information with the expectation that activity
will ensue. In collaboration diagrams, a message is shown as a labeled arrow placed near a link. This means
that the link is used to transport, or otherwise implement the delivery of the message to the target object.
The arrow points along the link in the direction of the target object (the one that receives the message).
The arrow is labeled with the name of the message, and its parameters. The arrow may also be labeled
with a sequence number to show the sequence of the message in the overall interaction. Sequence
numbers are often used in collaboration diagrams, because they are the only way of describing the relative
sequencing of messages.
 EXPERIMENT-7
AIM: Draw the state chart diagram.
THEORY:
The name of the diagram itself clarifies the purpose of the diagram and other details. It describes different
states of a component in a system. The states are specific to a component/object of a system.

A Statechart diagram describes a state machine. State machine can be defined as a machine which defines
different states of an object and these states are controlled by external or internal events.

Activity diagram explained in the next chapter, is a special kind of a Statechart diagram. As Statechart
diagram defines the states, it is used to model the lifetime of an object.

Purpose of Statechart Diagrams

Statechart diagram is one of the five UML diagrams used to model the dynamic nature of a system. They
define different states of an object during its lifetime and these states are changed by events. Statechart
diagrams are useful to model the reactive systems. Reactive systems can be defined as a system that
responds to external or internal events.

Statechart diagram describes the flow of control from one state to another state. States are defined as a
condition in which an object exists and it changes when some event is triggered. The most important
purpose of Statechart diagram is to model lifetime of an object from creation to termination.

Statechart diagrams are also used for forward and reverse engineering of a system. However, the main
purpose is to model the reactive system.

Following are the main purposes of using Statechart diagrams

● To model the dynamic aspect of a system.

● To model the life time of a reactive system.

● To describe different states of an object during its life time.

● Define a state machine to model the states of an object.

● Following is an example of a Statechart diagram where the state of Order object is analyzed
● The first state is an idle state from where the process starts. The next states are arrived for events
like send request, confirm request, and dispatch order. These events are responsible for the state
changes of order object.
The main usage can be described as

● To model the object states of a system.

● To model the reactive system. Reactive system consists of reactive objects.

● To identify the events responsible for state changes.

● Forward and reverse engineering.

 EXPERIMENT-8

AIM: Draw the component diagram.

THEORY:
Component diagrams are different in terms of nature and behavior. Component diagrams are used to
model the physical aspects of a system. Now the question is, what are these physical aspects? Physical
aspects are the elements such as executables, libraries, files, documents, etc. which reside in a node.

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 of Component Diagrams

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.

A single component diagram cannot represent the entire system but a collection of diagrams is used to
represent the whole.

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.

● 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 as it is drawn for
completely different purpose.
● The following component diagram has been drawn considering all the points mentioned above.

Component diagrams are very important from implementation perspective. Thus, the implementation
team of an application should have a proper knowledge of the component details

Component diagrams can be used to

● Model the components of a system.

● Model the database schema.

● Model the executables of an application.

● Model the system's source code.

 EXPERIMENT-9

AIM: Perform forward engineering in java.

THEORY:
Forward engineering is the process of transforming a model into code through a mapping to an
implementation language. Forward engineering results in a loss of information, because models written in
the UML are semantically richer than any current object-oriented programming language. In fact, this is a
major reason why you need models in addition to code. Structural features, such as collaborations, and
behavioural features, such as interactions, can be visualized clearly in the UML, but not so clearly from raw
code.
To forward engineer a class diagram,
● Identify the rules for mapping to your implementation language or languages of choice. This is
something you'll want to do for your project or your organization as a whole.
● Depending on the semantics of the languages you choose, you may want to constrain your use of
certain UML features. For example, the UML permits you to model multiple inheritance, but
Smalltalk permits only single inheritance. You can choose to prohibit developers from modeling
with multiple inheritance (which makes your models language-dependent), or you can develop
idioms that transform these richer features into the implementation language (which makes the
mapping more complex).
● Use tagged values to guide implementation choices in your target language. You can do this at the
level of individual classes if you need precise control. You can also do so at a higher level, such as
with collaborations or packages.
● Use tools to generate code.

●
● All of these classes specify a mapping to Java, as noted in their stereotype. Forward engineering the
classes in this diagram to Java is straightforward, using a tool. Forward engineering the
class EventHandler yields the following code.
● public abstract class EventHandler {
●
● EventHandler successor;
● private Integer currentEventID;
● private String source;
●
● EventHandler() {}
● public void handleRequest() {}}
 EXPERIMENT-10

AIM: Perform reverse engineering in java

THEORY:
Reverse engineering is the process of transforming code into a model through a mapping from a specific
implementation language. Reverse engineering results in a flood of information, some of which is at a
lower level of detail than you'll need to build useful models. At the same time, reverse engineering is
incomplete. There is a loss of information when forward engineering models into code, and so you can't
completely recreate a model from code unless your tools encode information in the source comments that
goes beyond the semantics of the implementation language.
To reverse engineer a class diagram,
● Identify the rules for mapping from your implementation language or languages of choice. This is
something you'll want to do for your project or your organization as a whole.
● Using a tool, point to the code you'd like to reverse engineer. Use your tool to generate a new
model or modify an existing one that was previously forward engineered. It is unreasonable to
expect to reverse engineer a single concise model from a large body of code. You need to select
portion of the code and build the model from the bottom.
● Using your tool, create a class diagram by querying the model. For example, you might start with
one or more classes, then expand the diagram by following specific relationships or other
neighboring classes. Expose or hide details of the contents of this class diagram as necessary to
communicate your intent.
● Manually add design information to the model to express the intent of the design that is missing or
hidden in the code.
 EXPERIMENT-11

AIM: Draw the deployment diagram.

THEORY:
Deployment diagrams are used to visualize the topology of the physical components of a system, where
the software components are deployed.

Deployment diagrams are used to describe the static deployment view of a system. Deployment diagrams
consist of nodes and their relationships.

Purpose of Deployment Diagrams

The term 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 the software artifacts of a system. However, these two diagrams are
special diagrams used to focus on software and hardware components.

Most of the UML diagrams are used to handle logical components but deployment diagrams are made to
focus on the hardware topology of a system. Deployment diagrams are used by the system engineers.

The purpose of deployment diagrams can be described as

● Visualize the hardware topology of a system.

● Describe the hardware components used to deploy software components.

● Describe the runtime processing nodes.

Deployment diagrams are useful for system engineers. An efficient deployment diagram is very important as it cont

● Performance

● Scalability

● Maintainability

● Portability

Before drawing a deployment diagram, the following artifacts should be identified

● Nodes

● Relationships among nodes

Following is a sample deployment diagram to provide an idea of the deployment view of order management system

● 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 connects to the application using the Internet. The control
flows from the caching server to the clustered environment.

The following deployment diagram has been drawn considering all the points mentioned above.

Deployment diagrams can be used

● To model the hardware topology of a system.

● To model the embedded system.

● To model the hardware details for a client/server system.

● To model the hardware details of a distributed application.

● For Forward and Reverse engineering.