Practical No.

1 Date:
Aim: To draw one or more Use Case diagrams for capturing and representing requirements
of the system .Use case diagram must include template showing description and steps of the
Use Case for various scenarios. Eg. Library Management System
Theory:

Use Case Diagram captures the system's functionality and requirements by using
actors and use cases. Use Cases model the services, tasks, function that a system needs to
perform. Use cases represent high-level functionalities and how a user will handle the system.
Use-cases are the core concepts of Unified Modelling language modelling.
A Use Case consists of use cases, persons, or various things that are invoking the
features called as actors and the elements that are responsible for implementing the use cases.
Use case diagrams capture the dynamic behaviour of a live system. It models how an external
entity interacts with the system to make it work. Use case diagrams are responsible for
visualizing the external things that interact with the part of the system.

 Use-case diagram notations

Following are the common notations used in a use case diagram:
Use-case:
Use cases are used to represent high-level functionalities and how the user will handle
the system. A use case represents a distinct functionality of a system, a component, a package,
or a class. It is denoted by an oval shape with the name of a use case written inside the oval
shape. The notation of a use case in UML is given below:

UML UseCase Notation

Actor:
It is used inside use case diagrams. The actor is an entity that interacts with the system.
A user is the best example of an actor. An actor is an entity that initiates the use case from
outside the scope of a use case. It can be any element that can trigger an interaction with the
use case. One actor can be associated with multiple use cases in the system. The actor notation
in UML is given below.

UML Actor Notation

 How to draw a use-case diagram?
To draw a use case diagram in UML first one need to analyze the entire system carefully.
You have to find out every single function that is provided by the system. After all the
functionalities of a system are found out, then these functionalities are converted into various
use cases which will be used in the use case diagram.
A use case is nothing but a core functionality of any working system. After organizing the
use cases, we have to enlist the various actors or things that are going to interact with the
system. These actors are responsible for invoking the functionality of a system. Actors can be
a person or a thing. It can also be a private entity of a system. These actors must be relevant to
the functionality or a system they are interacting with.
After the actors and use cases are enlisted, then you have to explore the relationship of a
particular actor with the use case or a system. One must identify the total number of ways an
actor could interact with the system. A single actor can interact with multiple use cases at the
same time, or it can interact with numerous use cases simultaneously.

 When to use a use-case diagram?

A use case is a unique functionality of a system which is accomplished by a user. A purpose

of use case diagram is to capture core functionalities of a system and visualize the interactions
of various things called as actors with the use case. This is the general use of a use case diagram.
The use case diagrams represent the core parts of a system and the workflow between them. In
use case, implementation details are hidden from the external use only the event flow is
represented.
With the help of use case diagrams, we can find out pre and post conditions after the
interaction with the actor. These conditions can be determined using various test cases.

In general use case diagrams are used for:

1. Analyzing the requirements of a system

2. High-level visual software designing
3. Capturing the functionalities of a system
4. Modeling the basic idea behind the system
5. Forward and reverse engineering of a system using various test cases.

Use cases are intended to convey desired functionality so the exact scope of a use case may
vary according to the system and the purpose of creating UML model.
  Use Case diagram for LIBRARY MANAGEMENT SYSTEM:

Conclusion: Thus we have successfully studied how to Use Case diagrams for capturing and
representing requirements of the system.
 Practical No. 2 Date:
Aim: To draw one or more Package diagram to organise and manage your large and
complex systems as well as their complex models. Eg. ATM Machine
Theory:

 What is Package Diagram?

Package diagram, a kind of structural diagram, shows the arrangement and

organization of model elements in middle to large scale project. Package diagram can show
both structure and dependencies between sub-systems or modules, showing different views
of a system, for example, as multi-layered (multi-tiered) application - multi-layered
application model.

 Purpose of Package Diagrams:-

Package diagrams are used to structure high level system elements. Packages are used
for organizing large system which contains diagrams, documents and other key deliverables.
 Package Diagram can be used to simplify complex class diagrams, it can group classes
into packages.
 A package is a collection of logically related UML elements.
 Packages are depicted as file folders and can be used on any of the UML diagrams.
 Package Diagram at a Glance:-

Package diagram is used to simplify complex class diagrams, you can group classes
into packages. A package is a collection of logically related UML elements.
The diagram below is a business model in which the classes are grouped into packages:
 Packages appear as rectangles with small tabs at the top.
 The package name is on the tab or inside the rectangle.
 The dotted arrows are dependencies.
 One package depends on another if changes in the other could possibly force changes
in the first.

 Basic Concepts of Package Diagram:-

Package diagram follows hierarchal structure of nested packages. Atomic module for
nested package are usually class diagrams. There are few constraints while using package
diagrams, they are as follows.
 Package name should not be the same for a system, however classes inside different
packages could have the same name.
 Packages can include whole diagrams, name of components alone or no components at
all.
 Fully qualified name of a package has the following syntax.
Packages can be represented by the notations with some examples shown below:

 Package Diagram Example - Import

<<import>> - one package imports the functionality of other package

 Package Diagram Example - Access

<<access>> - one package requires help from functions of other package.

  Package Diagram for ATM Machine:

Conclusion: Thus we have successfully studied how to Package diagram to organise and
manage large and complex systems as well as their complex models.
 Practical No. 3 Date:
Aim: Draw activity diagrams to display either business flows or like flow charts. Eg. Online
Payment Gateways or Campus Recruitment System.

Theory:

 What is Activity Diagram?

We use Activity Diagrams to illustrate the flow of control in a system and refer to the
steps involved in the execution of a use case. We model sequential and concurrent activities
using activity diagrams. So, we basically depict workflows visually using an activity
diagram. An activity diagram focuses on condition of flow and the sequence in which it
happens. We describe or depict what causes a particular event using an activity diagram.

UML models basically three types of diagrams, namely, structure diagrams, interaction
diagrams, and behavior diagrams. An activity diagram is a behavioral diagram i.e. it depicts
the behavior of a system.

An activity diagram portrays the control flow from a start point to a finish point showing
the various decision paths that exist while the activity is being executed. We can depict both
sequential processing and concurrent processing of activities using an activity diagram. They
are used in business and process modelling where their primary use is to depict the dynamic
aspects of a system.

An activity diagram is very similar to a flowchart. So let us understand if an activity

diagrams or a flowcharts are any different :
Difference between an Activity diagram and a Flowchart –

Flowcharts were typically invented earlier than activity diagrams. Non programmers use
Flow charts to model workflows. For example: A manufacturer uses a flow chart to explain
and illustrate how a particular product is manufactured. We can call a flowchart a primitive
version of an activity diagram. Business processes where decision making is involved is
expressed using a flow chart.

So, programmers use activity diagrams (advanced version of a flowchart) to depict

workflows. An activity diagram is used by developers to understand the flow of programs on
a high level. It also enables them to figure out constraints and conditions that cause particular
events. A flow chart converges into being an activity diagram if complex decisions are being
made.

Brevity is the soul of wit. We need to convey a lot of information with clarity and make
sure it is short. So an activity diagram helps people on both sides i.e. Businessmen and
Developers to interact and understand systems.

Activity Diagram Notations –

1. Initial State – The starting state before an activity takes place is depicted using the initial
state.

Figure – notation for initial state or start state

A process can have only one initial state unless we are depicting nested activities. We use
a black filled circle to depict the initial state of a system. For objects, this is the state when
they are instantiated. The Initial State from the UML Activity Diagram marks the entry
point and the initial Activity State.
2. Action or Activity State – An activity represents execution of an action on objects or by
objects. We represent an activity using a rectangle with rounded corners. Basically any
action or event that takes place is represented using an activity.

Figure – notation for an activity state

3. Action Flow or Control flows – Action flows or Control flows are also referred to as
paths and edges. They are used to show the transition from one activity state to another.

Figure – notation for control Flow

 An activity state can have multiple incoming and outgoing action flows. We use a line
with an arrow head to depict a Control Flow. If there is a constraint to be adhered to while
making the transition it is mentioned on the arrow.
4. Decision node and Branching – When we need to make a decision before deciding the
flow of control, we use the decision node.

Figure – notation for decision node

The outgoing arrows from the decision node can be labelled with conditions or guard
expressions.It always includes two or more output arrows.
5. Guards – A Guard refers to a statement written next to a decision node on an arrow
sometimes within square brackets.

Figure – guards being used next to a decision node

6. Fork – Fork nodes are used to support concurrent activities.

Figure – fork notation

When we use a fork node when both the activities get executed concurrently i.e. no
decision is made before splitting the activity into two parts. Both parts need to be executed
in case of a fork statement.
We use a rounded solid rectangular bar to represent a Fork notation with incoming arrow
from the parent activity state and outgoing arrows towards the newly created activities.
For example: In the example below, the activity of making coffee can be split into two
concurrent activities and hence we use the fork notation.
7. Join – Join nodes are used to support concurrent activities converging into one. For join
notations we have two or more incoming edges and one outgoing edge.

Figure – join notation

8. Merge or Merge Event – Scenarios arise when activities which are not being executed
concurrently have to be merged. We use the merge notation for such scenarios. We can
merge two or more activities into one if the control proceeds onto the next activity
irrespective of the path chosen.

Figure – merge notation

9. Swimlanes – We use swimlanes for grouping related activities in one column. Swimlanes
group related activities into one column or one row. Swimlanes can be vertical and
horizontal. Swimlanes are used to add modularity to the activity diagram. It is not
mandatory to use swimlanes. They usually give more clarity to the activity diagram. It’s
similar to creating a function in a program. It’s not mandatory to do so, but, it is a
recommended practice.

Figure – swimlanes notation

We use a rectangular column to represent a swimlane as shown in the figure above.
 10. Time Event –

Figure – time event notation

We can have a scenario where an event takes some time to complete. We use an hourglass
to represent a time event.
11. Final State or End State – The state which the system reaches when a particular process
or activity ends is known as a Final State or End State. We use a filled circle within a
circle notation to represent the final state in a state machine diagram. A system or a
process can have multiple final states.

Figure – notation for final state

How to Draw an activity diagram –

1. Identify the initial state and the final states.

2. Identify the intermediate activities needed to reach the final state from he initial state.
3. Identify the conditions or constraints which cause the system to change control flow.
4. Draw the diagram with appropriate notations.

Figure – an activity diagram

The above diagram prints the number if it is odd otherwise it subtracts one from the number
and displays it.
Uses of an Activity Diagram –

 Dynamic modelling of the system or a process.

 Illustrate the various steps involved in a UML use case.
 Model software elements like methods,operations and functions.
 We can use Activity diagrams to depict concurrent activities easily.
 Show the constraints, conditions and logic behind algorithms.

 Activity Diagram for Online Payment Gateway:

Conclusion: Thus we have successfully studied how to draw Activity diagrams to display
either business flow or like flow charts.
 Practical No. 4 Date:
Aim: To draw basic Class diagram to identify and describe key concepts like Classes, types
in your system and their relationship. Eg. Online banking System.
Theory:
 What is Class Diagram?
In software engineering, a class diagram in the Unified Modeling Language (UML) is a
type of static structure diagram that describes the structure of a system by showing the
system's classes, their attributes, operations (or methods), and the relationships among
objects.

 Purpose of Class Diagrams:-

[1]. Shows static structure of classifiers in a system.
[2]. Diagram provides a basic notation for other structure diagrams prescribed by UML.
[3]. Helpful for developers and other team members too.
[4]. Business Analysts can use class diagrams to model systems from a business perspective.

 A UML class diagram is made up of:

 A set of classes and
 A set of relationships between classes
 What is a Class?

A description of a group of objects all with similar roles in the system, which consists of:
 Structural features (attributes) define what objects of the class "know"
 Represent the state of an object of the class
 Are descriptions of the structural or static features of a class
 Behavioral features (operations) define what objects of the class "can do"
 Define the way in which objects may interact
 Operations are descriptions of behavioral or dynamic features of a class

 Class Notation

A class notation consists of three parts:

1. Class Name
 The name of the class appears in the first partition.
2. Class Attributes
 Attributes are shown in the second partition.
 The attribute type is shown after the colon.
 Attributes map onto member variables (data members) in code.
3. Class Operations (Methods)
 Operations are shown in the third partition. They are services the class
provides.
 The return type of a method is shown after the colon at the end of the method
signature.
 The return type of method parameters is shown after the colon following the
parameter name.
 Operations map onto class methods in code

The graphical representation of the class - MyClass as shown above:

 MyClass has 3 attributes and 3 operations
 Parameter p3 of op2 is of type int
 op2 returns a float
 op3 returns a pointer (denoted by a *) to Class6

 Class Relationships
A class may be involved in one or more relationships with other classes. A relationship can
be one of the following types:
 Relationship Type Graphical Representation
Inheritance (or Generalization):
 Represents an "is-a" relationship.
 An abstract class name is shown in italics.
 SubClass1 and SubClass2 are
specializations of Super Class.
 A solid line with a hollow arrowhead that
point from the child to the parent class

Simple Association:
 A structural link between two peer classes.
 There is an association between Class1 and
Class2
 A solid line connecting two classes

Aggregation:
A special type of association. It represents a "part
of" relationship.
 Class2 is part of Class1.
 Many instances (denoted by the *) of Class2
can be associated with Class1.
 Objects of Class1 and Class2 have separate
lifetimes.
 A solid line with an unfilled diamond at the
association end connected to the class of
composite

Composition:
A special type of aggregation where parts are
destroyed when the whole is destroyed.
 Objects of Class2 live and die with Class1.
 Class2 cannot stand by itself.
 A solid line with a filled diamond at the
association connected to the class of
composite

Dependency:
 Exists between two classes if the changes to
the definition of one may cause changes to
the other (but not the other way around).
 Class1 depends on Class2
 A dashed line with an open arrow
 Relationship - Roles
 A role is a directional purpose of an association.
 Roles are written at the ends of an association line and describe the purpose played by
that class in the relationship.
 E.g., A cell is related to an expression. The nature of the relationship is that the
expression is the formula of the cell.

 Navigability
The arrows indicate whether, given one instance participating in a relationship, it is possible to
determine the instances of the other class that are related to it.
The diagram above suggests that,
 Given a spreadsheet, we can locate all of the cells that it contains, but that
 We cannot determine from a cell in what spreadsheet it is contained.
 Given a cell, we can obtain the related expression and value, but
 Given a value (or expression) we cannot find the cell of which those are
attributes.

 Visibility of Class attributes and Operations

In object-oriented design, there is a notation of visibility for attributes and operations. UML
identifies four types of visibility: public, protected, private, and package.
The +, -, # and ~ symbols before an attribute and operation name in a class denote the visibility
of the attribute and operation.
 + denotes public attributes or operations
 - denotes private attributes or operations
 # denotes protected attributes or operations
 ~ denotes package attributes or operations

 Class Visibility Example

In the example above:

 attribute1 and op1 of MyClassName are public
 attribute3 and op3 are protected.
 attribute2 and op2 are private.

Access for each of these visibility types is shown below for members of different classes.
protected
Access Right public (+) private (-) Package (~)
(#)

Members of the same class Yes yes yes yes

Members of derived classes Yes no yes yes
Members of any other class Yes no no in same package
  Class Diagram for Online Banking System:

Conclusion: Thus we have successfully studied how to draw basic Class diagram to identify
and describe key concepts.
 Practical No. 5 Date:
Aim: To draw advanced class diagrams to depict advanced relationships, other classifiers
like interfaces. Eg. Executing a complex computer program

Theory:

 What is Class Diagram?

Class diagrams are the main building blocks of every object oriented methods. The class
diagram can be used to show the classes, relationships, interface, association, and collaboration.
UML is standardized in class diagrams. Since classes are the building block of an application
that is based on OOPs, so as the class diagram has appropriate structure to represent the classes,
inheritance, relationships, and everything that OOPs have in its context. It describes various
kinds of objects and the static relationship in between them.

The main purpose to use class diagrams are:

 This is the only UML which can appropriately depict various aspects of OOPs concept.
 Proper design and analysis of application can be faster and efficient.
 It is base for deployment and component diagram.

There are several software available which can be used online and offline to draw these
diagrams Like Edraw max, lucid chart etc. There are several points to be kept in focus while
drawing the class diagram. These can be said as its syntax:
 Each class is represented by a rectangle having a subdivision of three compartments
name, attributes and operation.
 There are three types of modifiers which are used to decide the visibility of attributes and
operations.
 + is used for public visibility(for everyone)
 # is used for protected visibility (for friend and derived)
 – is used for private visibility (for only me)
Below is the example of Animal class (parent) having two child class as dog and cat both have
object d1, c1 inheriting properties of the parent class.
import java.io.*;
class GFG {
public static void main(String[] args)
{
dog d1 = new dog();
d1.bark();
d1.run();
cat c1 = new cat();
c1.meww();
}
}
class Animal {
public void run()
{
String name;
String colour;
System.out.println("animal is running");
}
}
class dog extends Animal {
public void bark()
{
System.out.println("wooh!wooh! dog is barking");
}
public void run()
{
System.out.println("dog is running");
}
}
class cat extends Animal {
public void meww()
{
System.out.println("meww! meww!");
}
}
Process to design class diagram:
In Edraw max (or any other platform where class diagrams can be drawn) follow the steps:
 Open a blank document in the class diagram section.
 From the library select the class diagram and click on create option.
 Prepare the model of the class in the opened template page.
 After editing according to requirement save it.
There are several diagram components which can be efficiently used while making/editing the
model. These are as follows:
 Class { name, attribute, method}
 Objects
 Interface
 Relationships {inheritance, association, generalization}
 Associations {bidirectional, unidirectional}
Class diagrams are one of the most widely used diagrams in the fields of software engineering
as well as businesses modelling.
 Class Diagram for Executing a complex computer program:

Conclusion: Thus we have successfully studied how to draw Class diagrams.

 Practical No. 6 Date:
Aim: Draw sequence diagrams OR communication diagrams with advanced notation for your
system to show objects and their message exchanges. Eg. Advance Network Management
System

Theory:

 A sequence diagram is the most commonly used interaction diagram.

 Interaction diagram –
An interaction diagram is used to show the interactive behavior of a system.
Since visualizing the interactions in a system can be a cumbersome task, we use
different types of interaction diagrams to capture various features and aspects of
interaction in a system.
 Sequence Diagrams –
A sequence diagram simply depicts interaction between objects in a sequential
order i.e. the order in which these interactions take place. We can also use the terms
event diagrams or event scenarios to refer to a sequence diagram. Sequence diagrams
describe how and in what order the objects in a system function. These diagrams are
widely used by businessmen and software developers to document and understand
requirements for new and existing systems.

Sequence Diagram Notations –

1. Actors – An actor in a UML diagram represents a type of role where it interacts with the
system and its objects. It is important to note here that an actor is always outside the scope
of the system we aim to model using the UML diagram.

Figure – notation symbol for actor

We use actors to depict various roles including human users and other external subjects.
We represent an actor in a UML diagram using a stick person notation. We can have
multiple actors in a sequence diagram.
For example – Here the user in seat reservation system is shown as an actor where it
exists outside the system and is not a part of the system.
 Figure – an actor interacting with a seat reservation system

2. Lifelines – A lifeline is a named element which depicts an individual participant in a

sequence diagram. So basically each instance in a sequence diagram is represented by a
lifeline. Lifeline elements are located at the top in a sequence diagram. The standard in
UML for naming a lifeline follows the following format – Instance Name : Class Name

Figure – lifeline
We display a lifeline in a rectangle called head with its name and type. The head is located
on top of a vertical dashed line (referred to as the stem) as shown above. If we want to
 model an unnamed instance, we follow the same pattern except now the portion of
lifeline’s name is left blank.
Difference between a lifeline and an actor – A lifeline always portrays an object
internal to the system whereas actors are used to depict objects external to the system.
The following is an example of a sequence diagram:

Figure – a sequence diagram

3. Messages – Communication between objects is depicted using messages. The messages
appear in a sequential order on the lifeline. We represent messages using arrows. Lifelines
and messages form the core of a sequence diagram.
Messages can be broadly classified into the following categories:

Figure – a sequence diagram with different types of messages

 Synchronous messages – A synchronous message waits for a reply before the
interaction can move forward. The sender waits until the receiver has completed the
processing of the message. The caller continues only when it knows that the receiver
has processed the previous message i.e. it receives a reply message. A large number
of calls in object oriented programming are synchronous. We use a solid arrow head
to represent a synchronous message.

Figure – a sequence diagram using a synchronous message

 Asynchronous Messages – An asynchronous message does not wait for a reply

from the receiver. The interaction moves forward irrespective of the receiver
processing the previous message or not. We use a lined arrow head to represent an
asynchronous message.

 Create message – We use a Create message to instantiate a new object in the

sequence diagram. There are situations when a particular message call requires the
creation of an object. It is represented with a dotted arrow and create word labelled
on it to specify that it is the create Message symbol.
For example – The creation of a new order on a e-commerce website would require
a new object of Order class to be created.
 Figure – a situation where create message is used

 Delete Message – We use a Delete Message to delete an object. When an object is

deallocated memory or is destroyed within the system we use the Delete Message
symbol. It destroys the occurrence of the object in the system. It is represented by
an arrow terminating with a x.
 For example – In the scenario below when the order is received by the user, the
object of order class can be destroyed.

Figure – a scenario where delete message is used

 Self Message – Certain scenarios might arise where the object needs to send a
message to itself. Such messages are called Self Messages and are represented with
a U-shaped arrow.

Figure – self message

For example – Consider a scenario where the device wants to access its webcam. Such a
scenario is represented using a self message.

Figure – a scenario where a self message is used

 Reply Message – Reply messages are used to show the message being sent from
the receiver to the sender. We represent a return/reply message using an open
arrowhead with a dotted line. The interaction moves forward only when a reply
message is sent by the receiver.

Figure – reply message

For example – Consider the scenario where the device requests a photo from the
user. Here the message which shows the photo being sent is a reply message.

Figure – a scenario where a reply message is used

 Found Message – A Found message is used to represent a scenario where an
unknown source sends the message. It is represented using an arrow directed
 towards a lifeline from an end point. For example: Consider the scenario of a
hardware failure.

Figure – found message

It can be due to multiple reasons and we are not certain as to what caused the
hardware failure.

Figure – a scenario where found message is used

 Lost Message – A Lost message is used to represent a scenario where the recipient
is not known to the system. It is represented using an arrow directed towards an end
point from a lifeline. For example: Consider a scenario where a warning is
generated.

Figure – lost message

The warning might be generated for the user or other software/object that the lifeline
is interracting with. Since the destination is not known before hand, we use the Lost
Message symbol.
 Figure – a scenario where lost message is used
4. Guards – To model conditions we use guards in UML. They are used when we need to
restrict the flow of messages on the pretext of a condition being met. Guards play an
important role in letting software developers know the constraints attached to a system
or a particular process.
For example: In order to be able to withdraw cash, having a balance greater than zero is
a condition that must be met as shown below.

Figure – sequence diagram using a guard

Uses of sequence diagrams –

 Used to model and visualise the logic behind a sophisticated function, operation or
procedure.
 They are also used to show details of UML use case diagrams.
 Used to understand the detailed functionality of current or future systems.
 Visualise how messages and tasks move between objects or components in a system.

Conclusion: Thus, we have successfully studied how to create sequence diagrams.

 Practical No. 7 Date:
Aim: Draw state machine to model the behaviour of a single object, specifying the sequence
of events that an object goes through during its lifetime in response to events.

Theory:
A state machine diagram models the behaviour of a single object, specifying the sequence of
events that an object goes through during its lifetime in response to events.

As an example, the following state machine diagram shows the states that a door goes through
during its lifetime.

The door can be in one of three states: "Opened", "Closed" or "Locked". It can respond to
the events Open, Close, Lock and Unlock. Notice that not all events are valid in all states; for
example, if a door is opened, you cannot lock it until you close it. Also notice that a state
transition can have a guard condition attached: if the door is Opened, it can only respond to the
Close event if the condition doorWay->isEmpty is fulfilled. The syntax and conventions used
in state machine diagrams will be discussed in full in the following sections.

States

A state is denoted by a round-cornered rectangle with the name of the state written inside it.

Initial and Final States

The initial state is denoted by a filled black circle and may be labeled with a name. The
final state is denoted by a circle with a dot inside and may also be labeled with a name.
Transitions

Transitions from one state to the next are denoted by lines with arrowheads. A transition
may have a trigger, a guard and an effect, as below.

"Trigger" is the cause of the transition, which could be a signal, an event, a change in some
condition, or the passage of time. "Guard" is a condition which must be true in order for the
trigger to cause the transition. "Effect" is an action which will be invoked directly on the object
that owns the state machine as a result of the transition.

State Actions

In the transition example above, an effect was associated with the transition. If the target
state had many transitions arriving at it, and each transition had the same effect associated with
it, it would be better to associate the effect with the target state rather than the transitions. This
can be done by defining an entry action for the state. The diagram below shows a state with an
entry action and an exit action.

It is also possible to define actions that occur on events, or actions that always occur. It is
possible to define any number of actions of each type.

Self-Transitions

A state can have a transition that returns to itself, as in the following diagram. This is most
useful when an effect is associated with the transition.
Compound States

A state machine diagram may include sub-machine diagrams, as in the example below.

The alternative way to show the same information is as follows.

The notation in the above version indicates that the details of the Check PIN sub-machine are
shown in a separate diagram.

Entry Point

Sometimes you won’t want to enter a sub-machine at the normal initial state. For example,
in the following sub-machine it would be normal to begin in the "Initializing" state, but if for
some reason it wasn’t necessary to perform the initialization, it would be possible to begin in
the "Ready" state by transitioning to the named entry point.

The following diagram shows the state machine one level up.
Exit Point

In a similar manner to entry points, it is possible to have named alternative exit points. The
following diagram gives an example where the state executed after the main processing state
depends on which route is used to transition out of the state.

Choice Pseudo-State

A choice pseudo-state is shown as a diamond with one transition arriving and two or more
transitions leaving. The following diagram shows that whichever state is arrived at, after the
choice pseudo-state, is dependent on the message format selected during execution of the
previous state.
Junction Pseudo-State

Junction pseudo-states are used to chain together multiple transitions. A single junction can
have one or more incoming, and one or more outgoing, transitions; a guard can be applied to
each transition. Junctions are semantic-free. A junction which splits an incoming transition into
multiple outgoing transitions realizes a static conditional branch, as opposed to a choice
pseudo-state which realizes a dynamic conditional branch.

Terminate Pseudo-State

Entering a terminate pseudo-state indicates that the lifeline of the state machine has
ended. A terminate pseudo-state is notated as a cross.

History States

A history state is used to remember the previous state of a state machine when it was
interrupted. The following diagram illustrates the use of history states. The example is a state
machine belonging to a washing machine.
 In this state machine, when a washing machine is running, it will progress from "Washing"
through "Rinsing" to "Spinning". If there is a power cut, the washing machine will stop running
and will go to the "Power Off" state. Then when the power is restored, the Running state is
entered at the "History State" symbol meaning that it should resume where it last left-off.

Concurrent Regions

A state may be divided into regions containing sub-states that exist and execute
concurrently. The example below shows that within the state "Applying Brakes", the front and
rear brakes will be operating simultaneously and independently. Notice the use of fork and join
pseudo-states, rather than choice and merge pseudo-states. These symbols are used to
synchronize the concurrent threads.

Conclusion: Thus, we have successfully studied state machine to model the behaviour of a
single object, specifying the sequence of events that an object goes through during its lifetime
in response to events.
 Practical No. 8 Date:
Aim: Draw component diagrams assuming that you will build your system reusing existing
components along with a few new ones. Eg. Development of bio-inspired algorithms to
solve complex computational or real-life problems.

Theory:

What is a Component Diagram?

A component diagram, also known as a UML component diagram, describes the

organization and wiring of the physical components in a system.

Component diagrams are often drawn to help model implementation details and double-
check that every aspect of the system's required function is covered by planned development.

In the first version of UML, components included in these diagrams were physical:
documents, database table, files, and executables, all physical elements with a location.

In the world of UML 2, these components are less physical and more conceptual stand-
alone design elements such as a business process that provides or requires interfaces to interact
with other constructs in the system.

The physical elements described in UML 1, like files and documents, are now referred
to as artifacts.

A UML 2 component may contain multiple physical artifacts if they naturally belong
together.

Basic Component Diagram Symbols and Notations

Component
A component is a logical unit block of the system, a slightly higher abstraction than classes. It
is represented as a rectangle with a smaller rectangle in the upper right corner with tabs or the
word written above the name of the component to help distinguish it from a class.

Interface
An interface (small circle or semi-circle on a stick) describes a group of operations used
(required) or created (provided) by components. A full circle represents an interface created or
provided by the component. A semi-circle represents a required interface, like a person's input.
Dependencies
Draw dependencies among components using dashed arrows.

Port
Ports are represented using a square along the edge of the system or a component. A port is
often used to help expose required and provided interfaces of a component.

How to Draw a Component Diagram

 Take stock of everything needed to implement the planned system. For example, for a
simple e-commerce system, you'll need components that describe products, orders,
and customer accounts.
 Create a visual for each of the components.
 Describe the organization and relationships between components using interfaces,
ports, and dependencies.

What's the Difference Between a Package Diagram and a Component Diagram?

Package diagram elements are always public, while component diagram elements are
private.
Component Diagram for Online Shopping:

Conclusion: Thus, we have successfully studied how to create component diagrams.