SEPM File

UJJAIN ENGINEERING COLLEGE, UJJAIN
PROGRAM NO. - 1
OBJECTIVE: To study UML and describing its installation process.
Unified Modelling Language (UML) is a general-purpose modelling language. The main aim of UML is to
define a standard way to visualize the way a system has been designed. It is quite similar to blueprints used in
other fields of engineering.
UML is not a programming language; it is rather a visual language. We use UML diagrams to portray the
behavior and structure of a system. UML helps software engineers, businessmen and system architects with
modelling, design and analysis. The Object Management Group (OMG) adopted Unified Modelling Language as
a standard in 1997. It’s been managed by OMG ever since. International Organization for Standardization (ISO)
published UML as an approved standard in 2005. UML has been revised over the years and is reviewed
periodically.
Do we really need UML?
 Complex applications need collaboration and planning from multiple teams and hence require a clear
and concise way to communicate amongst them.
 Businessmen do not understand code. So UML becomes essential to communicate with non-
programmers essential requirements, functionalities and processes of the system.
 A lot of time is saved down the line when teams are able to visualize processes, user interactions and
static structure of the system.
UML is linked with object-oriented design and analysis. UML makes the use of elements and forms
associations between them to form diagrams. Diagrams in UML can be broadly classified as:
1. Structural Diagrams – Capture static aspects or structure of a system. Structural Diagrams include:
Component Diagrams, Object Diagrams, Class Diagrams and Deployment Diagrams.
2. Behavior Diagrams – Capture dynamic aspects or behavior of the system. Behaviour diagrams
include: Use Case Diagrams, State Diagrams, Activity Diagrams and Interaction Diagrams.
The image below shows the hierarchy of diagrams according to UML 2.2
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

Object Oriented Concepts Used in UML –

1. Class – A class defines the blue print i.e. structure and functions of an object.
2. Objects – Objects help us to decompose large systems and help us to modularize our system.
Modularity helps to divide our system into understandable components so that we can build our
system piece by piece. An object is the fundamental unit (building block) of a system which is
used to depict an entity.
3. Inheritance – Inheritance is a mechanism by which child classes inherit the properties of their
parent classes.
4. Abstraction – Mechanism by which implementation details are hidden from user.
5. Encapsulation – Binding data together and protecting it from the outer world is referred to as
encapsulation.
6. Polymorphism – Mechanism by which functions or entities are able to exist in different forms.
Additions in UML 2.0 –
 Software development methodologies like agile have been incorporated and scope of original
UML specification has been broadened.
 Originally UML specified 9 diagrams. UML 2.x has increased the number of diagrams from 9 to
13. The four diagrams that were added are: timing diagram, communication diagram, interaction
overview diagram and composite structure diagram. UML 2.x renamed state chart diagrams to
state machine diagrams.
 UML 2.x added the ability to decompose software system into components and sub-components.
Structural UML Diagrams –
1. Class Diagram – The most widely use UML diagram is the class diagram. It is the building
block of all object-oriented software systems. We use class diagrams to depict the static structure
of a system by showing system’s classes, their methods and attributes. Class diagrams also help
us identify relationship between different classes or objects.
2. Composite Structure Diagram – We use composite structure diagrams to represent the internal
structure of a class and its interaction points with other parts of the system. A composite
structure diagram represents relationship between parts and their configuration which determine
how the classifier (class, a component, or a deployment node) behaves. They represent internal
structure of a structured classifier making the use of parts, ports, and connectors. We can also
model collaborations using composite structure diagrams. They are similar to class diagrams
except they represent individual parts in detail as compared to the entire class.
3. Object Diagram – An Object Diagram can be referred to as a screenshot of the instances in a
system and the relationship that exists between them. Since object diagrams depict behavior
when objects have been instantiated, we are able to study the behavior of the system at a
particular instant. An object diagram is similar to a class diagram except it shows the instances
of classes in the system. We depict actual classifiers and their relationships making the use of
class diagrams. On the other hand, an Object Diagram represents specific instances of classes and
relationships between them at a point of time.
4. Component Diagram – Component diagrams are used to represent the how the physical
components in a system have been organized. We use them for modelling implementation
details. Component Diagrams depict the structural relationship between software system elements
and help us in understanding if functional requirements have been covered by planned
development. Component Diagrams become essential to use when we design and build complex
systems. Interfaces are used by components of the system to communicate with each other.
5. Deployment Diagram – Deployment Diagrams are used to represent system hardware and its
software. It tells us what hardware components exist and what software components run on
them. We illustrate system architecture as distribution of software artifacts over distributed
targets. An artifact is the information that is generated by system software. They are primarily
used when a software is being used, distributed or deployed over multiple machines with
different configurations.
6. Package Diagram – We use Package Diagrams to depict how packages and their elements have
been organized. A package diagram simply shows us the dependencies between different
packages and internal composition of packages. Packages help us to organize UML diagrams
into meaningful groups and make the diagram easy to understand. They are primarily used to
organize class and use case diagrams.
Behavior Diagrams –
1. State Machine Diagrams – A state diagram is used to represent the condition of the system or
part of the system at finite instances of time. It’s a behavioral diagram and it represents the
behavior using finite state transitions. State diagrams are also referred to as State machines and
State-chart Diagrams. These terms are often used interchangeably. So simply, a state diagram
is used to model the dynamic behavior of a class in response to time and changing external
stimuli.
2. Activity Diagrams – We use Activity Diagrams to illustrate the flow of control in a system. We
can also use an activity diagram to 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.
3. Use Case Diagrams – Use Case Diagrams are used to depict the functionality of a system or a
part of a system. They are widely used to illustrate the functional requirements of the system and
its interaction with external agents(actors). A use case is basically a diagram representing
different scenarios where the system can be used. A use case diagram gives us a high-level view
of what the system or a part of the system does without going into implementation details.
4. Sequence Diagram – 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.
5. Communication Diagram – A Communication Diagram (known as Collaboration Diagram in
UML 1.x) is used to show sequenced messages exchanged between objects. A communication
diagram focuses primarily on objects and their relationships. We can represent similar
information using Sequence diagrams; however, communication diagrams represent objects and
links in a free form.
6. Timing Diagram – Timing Diagram are a special form of Sequence diagrams which are used to
depict the behavior of objects over a time frame. We use them to show time and duration
constraints which govern changes in states and behavior of objects.
7. Interaction Overview Diagram – An Interaction Overview Diagram models a sequence of
actions and helps us simplify complex interactions into simpler occurrences. It is a mixture of
activity and sequence diagrams.
Open the link: http://staruml.io/download
1. According to your PC specifications. Download any version of the application. Here we are going to
choose the windows option.

2. Run the .exe file.
3. After installation, you can see the StarUML icon on the desktop screen.
4. The software will open directly and it will ask for buy now option or evaluate the option. Click on
evaluate.
5. The screen appears like this for the evaluated version.
6. If you check the C Drive, you can see the StarUML folder in the program files location.
7. If you want to try and create a class in StarUML, a demo is explained below.

8. Drag and drop class on the screen and a new class is formed. Double click on the class1 and we can
rename the class name in the model.
9. From the file option, select template and then template version of StarUML can be used in the
system. We can create one to one, one to many or many to many in the application and store the
diagram in the system.
10. Click on the help button and you will see the documentation option. With the help of
documentation, you can learn and become an expert in StarUML.
11. The tools in StarUML helps to know the requirements in the system and to apply the design patterns
so that proper analysis can be done to understand and modify the diagrams. These tools are open
source and for more highly requirements, tools can be purchased from the software vendors of
different applications.
Signature of Faculty

PROGRAM NO. - 2
OBJECTIVE: Write a SRS documentation of the project.
Tittle – Employee Management System
Purpose - The purpose of an Employee Management System (EMS) is to streamline and optimize HR and
administrative processes within an organization. It facilitates efficient employee data management, including
attendance tracking, leave requests, payroll processing, and performance evaluations. By centralizing
employee information and automating routine tasks, an EMS improves productivity, enhances data accuracy,
and ensures compliance with labor laws. It also empowers employees with self-service options and provides
valuable insights for informed decision-making, ultimately contributing to a more organized and productive
workforce.
Scope - The scope for an Employee Management System (EMS) is to provide a comprehensive and efficient
solution for organizations to effectively manage their workforce. This system encompasses various HR
functions, including personnel data management, attendance tracking, leave management, performance
evaluation, and payroll processing. It facilitates better decision-making, ensures compliance with labor laws,
and enhances employee productivity. An EMS can adapt to an organization's evolving needs, offering
scalability, customizable features, and data security. As businesses strive to optimize their human resource
management processes, the scope for EMS remains essential in streamlining HR operations, improving
employee engagement, and enhancing organizational efficiency.
Existing Software –
 User Authentication and Control.
 Attendance and Leave Management.
 Time and Attendance tracking.
 Employee Information Management.
Proposed Software –
 Payroll and Compensation.
 Training and Development.
 Compliance and Document Management.
 Communication and Notification.
 Data Security and Backup.
Functional Requirement –
1. Authentication -
 Users must authenticate with a username and password.
 Passwords should be securely hashed and stored in the database.

2. Employee Management:
 Add, edit, and delete employee records.
 View and search employee records.
 Store employee details (e.g., name, contact, position, department).
 Track employee attendance and leave.
3. Leave Management:
 Employees can submit leave requests.
 Managers can approve or reject leave requests.
 Leave balances should be updated automatically.
4. Reporting:
 Generate reports (e.g., employee list, attendance summary).
 Export reports in PDF or CSV format.
Non Functional Requirement –

1. Usability:
 The system should be user-friendly and require minimal training.
 Response times for user interactions should be fast.
2. Security:
 Data should be stored securely in the database.
 User authentication should prevent unauthorized access.
3. Scalability:
 The system should handle a growing number of employees and data.
4. Performance:
 The system should respond to user actions within 2 seconds.
 Database queries should be optimized for efficiency.
Software Tools –
 Programming Languages:
PHP: For server-side scripting and backend development.
JavaScript: For client-side scripting and interactivity.

HTML/CSS: For building the user interface.
 Database Management System (DBMS):

MySQL: A popular open-source relational database for storing employee data and system
information.
 Web Development Frameworks:
Laravel (PHP): A PHP framework that provides a foundation for building web applications.
Express (Node.js): A minimalist Node.js web application framework.
 Front-End Libraries and Frameworks:
React: A JavaScript library for building user interfaces.
Bootstrap: A CSS framework for creating responsive and visually appealing web pages.
 Version Control:
Git: For tracking changes in your codebase and facilitating collaboration among developers.
 Web Servers:
Apache: A widely used web server for hosting web applications.
 Development Environments:
Visual Studio Code (VS Code): A popular code editor with extensions for various languages
and frameworks.
 Testing and Debugging Tools:
PHPUnit (for PHP): A unit testing framework.
Jest (for JavaScript/React): A testing framework.
 Data Backup and Storage:
Regular database backups: Scheduled backups of your MySQL database.
Cloud Storage Services: Such as Amazon S3 or Google Cloud Storage for document storage.
Hardware Tools -
 Server
 Database Server
 Client Devices
 Internet Connection
 Backup System

Advantages –
 Efficiency and Time Savings
 Accuracy and Data Integrity
 Attendance and Leave Management
 Payroll and Compensation Management
 Performance Management and Feedback
 Compliance and Legal Requirements
 Workforce Planning and Reporting
 Employee Self-Service
 Communication and Notifications
 Data Security and Privacy
 Customization and Scalability
 Employee Satisfaction and Engagement
 Cost Savings
 Audit Trail and Accountability
Summary - An Employee Management System (EMS) is a software solution that simplifies human
resource and administrative tasks related to workforce management. It enables organizations to efficiently
handle employee data, attendance, leave requests, payroll, performance evaluations, and more. EMS
systems facilitate compliance with labor regulations, improve communication within an organization, and
offer valuable insights through reporting and analytics. These systems enhance HR efficiency, streamline
processes, and ensure the workforce is well-managed and productive, ultimately contributing to the overall
success of the organization.

PRACTICAL NO. - 3
OBJECTIVE: Explain Class diagram with the help of UML tool
Class Diagram
Class Diagrams show the different classes that make up a system and how they relate to each other. Class
Diagrams are said to be “static” diagrams because they show the classes, along with their methods and
attributes as well as the static relationships between them: which classes “know” about which classes or which
classes “are part” of another class, but do not show the method calls between them.
Class
A Class defines the attributes and the methods of a set of objects. All objects of this class (instances of this
class) share the same behaviour, and have the same set of attributes (each object has its own set). The term
“Type” is sometimes used instead of Class, but it is important to mention that these two are not the same, and
Type is a more general term.
In UML, Classes are represented by rectangles, with the name of the class, and can also show the attributes and
operations of the class in two other “compartments” inside the rectangle.
Attributes
In UML, Attributes are shown with at least their name, and can also show their type, initial value and other
properties. Attributes can also be displayed with their visibility:
 + Stands for public attributes
 # Stands for protected attributes
 - Stands for private attributes
Operations
Operations (methods) are also displayed with at least their name, and can also show their parameters and return
types. Operations can, just as Attributes, display their visibility:
 + Stands for public operations
 # Stands for protected operations
 - Stands for private operations

Templates
Classes can have templates, a value which is used for an unspecified class or type. The template type is specified
when a class is initiated (i.e. an object is created). Templates exist in modern C++ and will be introduced in Java
1.5 where they will be called Generics.
Class Associations
Classes can relate (be associated with) to each other in different ways:
Generalisation
Inheritance is one of the fundamental concepts of Object Orientated programming, in which a class “gains” all of
the attributes and operations of the class it inherits from, and can override/modify some of them, as well as add
more attributes and operations of its own.
In UML, a Generalisation association between two classes puts them in a hierarchy representing the concept of
inheritance of a derived class from a base class. In UML, Generalisations are represented by a line connecting the
two classes, with an arrow on the side of the base class.
Associations
An association represents a relationship between classes, and gives the common semantics and structure for
many types of “connections” between objects.
Associations are the mechanism that allows objects to communicate to each other. It describes the connection
between different classes (the connection between the actual objects is called object connection, or link.
Associations can have a role that specifies the purpose of the association and can be uni- or bidirectional
(indicates if the two objects participating in the relationship can send messages to the other, of if only one of
them knows about the other). Each end of the association also has a multiplicity value, which dictates how many
objects on this side of the association can relate to one object on the other side.
In UML, associations are represented as lines connecting the classes participating in the relationship, and can
also show the role and the multiplicity of each of the participants. Multiplicity is displayed as a range [minmax]
of non-negative values, with a star (*) on the maximum side representing infinite.

Aggregation
Aggregations are a special type of associations in which the two participating classes don't have an equal status,
but make a “whole-part” relationship. An Aggregation describes how the class that takes the role of the whole, is
composed (has) of other classes, which take the role of the parts. For Aggregations, the class acting as the whole
always has a multiplicity of one.
In UML, Aggregations are represented by an association that shows a rhomb on the side of the whole.
Composition
Compositions are associations that represent very strong aggregations. This means, Compositions form whole-
part relationships as well, but the relationship is so strong that the parts cannot exist on its own. They exist only
inside the whole, and if the whole is destroyed the parts die too.
In UML, Compositions are represented by a solid rhomb on the side of the whole.
Other Class Diagram Items

Class diagrams can contain several other items besides classes.
Interfaces
Interfaces are abstract classes which means instances can not be directly created of them. They can contain
operations but no attributes. Classes can inherit from interfaces (through a realisation association) and instances
can then be made of these classes.
Datatypes
Datatypes are primitives which are typically built into a programming language. Common examples include
integers and booleans. They cannot have relationships to classes but classes can have relationships to them.
Enums
Enums are a simple list of values. A typical example is an enum for days of the week. The options of an enum
are called Enum Literals. Like datatypes they can not have relationships to classes but classes can have
relationships to them.
Packages
Packages represent a namespace in a programming language. In a diagram they are used to represent parts of a
system which contain more than one class, maybe hundreds of classes.

CLASS DIAGRAM OF EMS: -

PRACTICAL NO. - 4
OBJECTIVE: Explain Data Flow diagram with the help of UML tool.
A data flow diagram (DFD) is a visual representation of the information flow through a process or system.
DFDs help you better understand process or system operation to discover potential problems, improve
efficiency, and develop better processes. They range from simple overviews to complex, granular displays of a
process or system.
DFDs became popular in the 1970s and have maintained their widespread use by being easy to understand.
Visually displaying how a process or system works can hold people’s attention and explain complex concepts
better than blocks of text can, so DFDs are able to help almost anyone grasp a system’s or process’ logic and
functions.
There are two types of DFDs — logical and physical. Logical diagrams display the theoretical process of moving
information through a system, like where the data comes from, where it goes, how it changes, and where it ends
up.
Physical diagrams show you the practical process of moving information through a system, like how your
system’s specific software, hardware, files, employees, and customers influences its flow of information.
You can either use logical or physical diagrams to describe the same flow of information or you can use them in
conjunction to understand a process or system on a more granular level. But, before you can use a DFD to
understand your system or process’ flow of information, you need to know the standard notations or symbols
used to describe it.


Levels of Data Flow Diagrams :-

DFDs can range from simple overviews to complex, granular representations of a system or process with
multiple levels, starting with level 0. The most common and intuitive DFDs are level 0 DFDs, also called context
diagrams. They’re digestible, high-level overviews of the flow of information through a system or process, so
almost anyone can understand it.
Level 0: Context Diagram

This DFD level focuses on high-level system processes or functions and the data sources that flow to or from
them. Level 0 diagrams are designed to be simple, straightforward overviews of a process or system.
This Level 0 DFD provides a contextual map of a securities trading platform. Data flows in one direction from
the customer service assistant and the broker to the platform, and in two directions from customers to the
platform and back again.

Level 1: Process Decomposition
While level 1 DFDs are still broad overviews of a system or process, they’re also more detailed — they break
down the system’s single process node into sub processes.
This Level 1 DFD breaks down the customer process in more detail, expanding it to include account creation,
cash withdrawals, and eventual securities transactions.
Level 2: Deeper Dives

The next level of DFDs dive even deeper into detail by breaking down each level 1 process into granular sub
processes.
This Level 2 DFD decomposes the “Place Order” process to contextualize the steps required to place an order —
either by a customer or by a broker. It even accounts for a third-party stock exchange center where transaction
details are forwarded after an order is placed.

Level 3: Increasing Complexity

Level 3 and higher-numbered DFDs are uncommon. This is largely due to the amount of detail required, which
defeats its original purpose of being easy to understand
DFD OF EMS SYSTEM: -
PRACTICAL NO. - 5
OBJECTIVE: Explain ER diagram with the help of UML tool.
An entity relationship diagram (ERD), also known as an entity relationship model, is a graphical representation
that depicts relationships among people, objects, places, concepts or events within an information technology (IT)
system. An ERD uses data modelling techniques that can help define business processes and serve as the
foundation for a relational database.
Importance of ERDs and their uses

Entity relationship diagrams provide a visual starting point for database design that can also be used to help
determine information system requirements throughout an organization. After a relational database is rolled out, an
ERD can still serve as a reference point, should any debugging or business process re-engineering be needed later.
However, while an ERD can be useful for organizing data that can be represented by a relational structure, it can't
sufficiently represent semi-structured or unstructured data. It's also unlikely to be helpful on its own in integrating
data into a pre-existing information system.
How to create an ERD

ERDs are generally depicted in one or more of the following models:
 A conceptual data model, which lacks specific detail but provides an overview of the scope of the
project and how data sets relate to one another.
 A logical data model, which is more detailed than a conceptual data model, illustrating specific
attributes and relationships among data points. While a conceptual data model does not need to be
designed before a logical data model, a physical data model is based on a logical data model.
 A physical data model, which provides the blueprint for a physical manifestation -- such as a relational
database -- of the logical data model. One or more physical data models can be developed based on a
logical data model.

There are five basic components of an entity relationship diagram. Similar components will be designated by the
same shape. For example, all entities types might be enclosed in a rectangle, while all attributes are enclosed in a
diamond. The components include:
1. Entities, which are objects or concepts that can have data stored about them. Entities refer to tables
used in databases.
2. Attributes, which are properties or characteristics of entities. An ERD attribute can be denoted as a
primary key, which identifies a unique attribute, or a foreign key, which can be assigned to multiple
attributes.
3. The relationships between and among those entities.
4. Actions, which describe how entities share information in the database.
5. Connecting lines
Figure: An entity relationship diagram showing relationships between sales reps, customers and product orders.
For example, an ERD representing the information system for a company's sales department might start with
graphical representations of entities such as the sales representative, the customer, the customer's address, the
customer's order, the product and the warehouse. (See diagram above.) Then lines or other symbols can be used
to represent the relationship between entities, and text can be used to label the relationships.

A cardinality notation can then define the attributes of the relationship between the entities. Cardinalities can
denote that an entity is optional (for example, a sales rep could have no customers or could have many) or
mandatory (for example, there must be at least one product listed in an order.)
The three main cardinalities are:

1. A one-to-one relationship (1:1). For example, if each customer in a database is associated with one
mailing address.
2. A one-to-many relationship (1:M). For example, a single customer might place an order for multiple
products. The customer is associated with multiple entities, but all those entities have a single
connection back to the same customer.
3. A many-to-many relationship (M:N). For example, at a company where all call center agents work with
multiple customers, each agent is associated with multiple customers, and multiple customers might
also be associated with multiple agents.
E-R DIAGRAM OF EMS: -

PRACTICAL NO. - 6
OBJECTIVE: Explain Sate Transition diagram with the help of UML tool.
A state diagram is used to represent the condition of the system or part of the system at finite instances
of time. It’s a behavioral diagram and it represents the behavior using finite state transitions. State diagrams
are also referred to as State machines and State-chart Diagrams. These terms are often used interchangeably.
So simply, a state diagram is used to model the dynamic behavior of a class in response to time and changing
external stimuli. We can say that each and every class has a state but we don’t model every class using State
diagrams. We prefer to model the states with three or more states.
Uses of state chart diagram –
 We use it to state the events responsible for change in state (we do not show what processes cause
those events).
 We use it to model the dynamic behavior of the system .
 To understand the reaction of objects/classes to internal or external stimuli.
Basic components of a state chart diagram –
Initial state – We use a black filled circle represent the initial state of a System or a class.
Transition – We use a solid arrow to represent the transition or change of control from one state to another.
The arrow is labelled with the event which causes the change in state.
State – We use a rounded rectangle to represent a state. A state represents the conditions or circumstances
of an object of a class at an instant of time.

Fork – We use a rounded solid rectangular bar to represent a Fork notation with incoming arrow from the
parent state and outgoing arrows towards the newly created states. We use the fork notation to represent a
state splitting into two or more concurrent states.
Join – We use a rounded solid rectangular bar to represent a Join notation with incoming arrows
from the joining states and outgoing arrow towards the common goal state. We use the join notation
when two or more states concurrently converge into one on the occurrence of an event or events.
Self transition – We use a solid arrow pointing back to the state itself to represent a self transition.
There might be scenarios when the state of the object does not change upon the occurrence of an
event. We use self transitions to represent such cases.
Composite state – We use a rounded rectangle to represent a composite state also. We represent a
state with internal activities using a composite state.

Final state – We use a filled circle within a circle notation to represent the final state in a state machine
diagram.
STATE TRANSITION DIAGRAM :-

PRACTICAL NO. - 7
OBJECTIVE: Explain Use Case diagram with the help of UML tool.
Use Case Diagrams

To model a system, the most important aspect is to capture the dynamic behavior. Dynamic behavior
means the behavior of the system when it is running/operating.
Only static behavior is not sufficient to model a system rather dynamic behavior is more important than
static behavior. In UML, there are five diagrams available to model the dynamic nature and use case diagram
is one of them. Now as we have to discuss that the use case diagram is dynamic in nature, there should
be some internal or external factors for making the interaction.
These internal and external agents are known as actors. Use case diagrams consists of actors, use cases and
their relationships. The diagram is used to model the system/subsystem of an application. A single use case
diagram captures a particular functionality of a system.
Hence to model the entire system, a number of use case diagrams are used.
Purpose of Use Case Diagrams
The purpose of use case diagram is to capture the dynamic aspect of a system. However, this definition is too
generic to describe the purpose, as other four diagrams (activity, sequence, collaboration, and State chart)
also have the same purpose. We will look into some specific purpose, which will distinguish it from other
four diagrams.
Use case diagrams are used to gather the requirements of a system including internal and external influences.
These requirements are mostly design requirements. Hence, when a system is analysed to gather its
functionalities, use cases are prepared and actors are identified.
When the initial task is complete, use case diagrams are modelled to present the outside view. In brief, the
purposes of use case diagrams can be said to be as follows −
 Used to gather the requirements of a system.
 Used to get an outside view of a system.
 Identify the external and internal factors influencing the system.
 Show the interaction among the requirements are actors.
How to Draw a Use Case Diagram?

Use case diagrams are considered for high level requirement analysis of a system. When the requirements of
a system are analyzed, the functionalities are captured in use cases.
We can say that use cases are nothing but the system functionalities written in an organized manner. The
second thing which is relevant to use cases are the actors. Actors can be defined as something that interacts
with the system.
Actors can be a human user, some internal applications, or may be some external applications. When we
are planning to draw a use case diagram, we should have the following items identified.
 Functionalities to be represented as use case
 Actors
 Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system. After identifying the above items,
we have to use the following guidelines to draw an efficient use case diagram
 The name of a use case is very important. The name should be chosen in such a way so that it can
identify the functionalities performed.
 Give a suitable name for actors.
 Show relationships and dependencies clearly in the diagram.
 Do not try to include all types of relationships, as the main purpose of the diagram is to
identify the requirements.
 Use notes whenever required to clarify some important points.
Following is a sample use case diagram representing the order management system. Hence, if we look into the
diagram then we will find three use cases (Order, Special Order, and Normal Order) and one actor which is the
customer.
The Special Order and Normal Order use cases are extended from Order use case. Hence, they have extended
relationship. Another important point is to identify the system boundary, which is shown in the picture. The actor
Customer lies outside the system as it is an external user of the system.
Where to Use a Use Case Diagram?

As we have already discussed there are five diagrams in UML to model the dynamic view of a system. Now each
and every model has some specific purpose to use. Actually, these specific purposes are different angles of a
running system.
To understand the dynamics of a system, we need to use different types of diagrams. Use case diagram is one of
them and its specific purpose is to gather system requirements and actors.
Use case diagrams specify the events of a system and their flows. But use case diagram never describes how they
are implemented. Use case diagram can be imagined as a black box where only the input, output, and the function
of the black box is known.
Although use case is not a good candidate for forward and reverse engineering, still they are used in a slightly
different way to make forward and reverse engineering. The same is true for reverse engineering. Use case
diagram is used differently to make it suitable for reverse engineering.
In forward engineering, use case diagrams are used to make test cases and in reverse engineering use cases are
used to prepare the requirement details from the existing application.

Use case diagrams can be used for −

 Requirement analysis and high-level design.
 Model the context of a system.
 Reverse engineering.
 Forward engineering.
USE CASE DIAGRAM –

PRACTICAL NO. - 8
OBJECTIVE: Explain Activity diagram with the help of UML tool.
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. A question arises: Do we need to use both the diagram and the textual documentation? Different
individuals have different preferences in which they understand something. For example: To understand a
concept, some people might prefer a written tutorial with images while others would prefer a video lecture. So
we generally use both the diagram and the textual documentation to make our system description as clear as
possible. We also need to be sensitive to the needs of the audience that we are catering to at times. Difference
between a Use case diagram and an Activity diagram An activity diagram is used to model the workflow
depicting conditions, constraints, sequential and concurrent activities. On the other hand, the purpose of a
Use Case is to just depict the functionality i.e., what the system does and not how it is done. So, in simple
terms, an activity diagram shows ‘How’ while a Use case shows ‘What’ for a particular system. The levels of
abstraction also vary for both of them. An activity diagram can be used to illustrate a business process (high
level implementation) to a stand-alone algorithm (ground level implementation). However, use cases have a
low level of abstraction. They are used to show a high level of implementation only.

Activity Diagram Notations –
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.
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

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.
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.
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 The statement must be true for the control
to shift along a particular direction. Guards help us know the constraints and conditions which
determine the flow of a process.
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.

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
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 For example – In the diagram below: we can’t have both sides executing
concurrently, but they finally merge into one. A number can’t be both odd and even at the same time.
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.

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.
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.

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 OF EMS: -

PRACTICAL NO. - 9
OBJECTIVE: Explain Sequence diagram with the help of UML tool.
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.
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 – 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.
 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.

 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 interacting with. Since the destination is not known
before hand, we use the Lost Message symbol.
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

SEQUENCE DIAGRAM OF EMS: -

PROGRAM NO. - 10
OBJECTIVE: Explain Object diagram with the help of UML tool.


SEPM File

Uploaded by

Copyright:

Available Formats

You might also like

SEPM File

Uploaded by

Document Information

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

SEPM File

Uploaded by

Copyright:

Available Formats

UJJAIN ENGINEERING COLLEGE, UJJAIN

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

Object Oriented Concepts Used in UML –

Additions in UML 2.0 –

Structural UML Diagrams –

Open the link: http://staruml.io/download

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

2. Run the .exe file.

5. The screen appears like this for the evaluated version.

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

Tittle – Employee Management System

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

Non Functional Requirement –

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

 Database Management System (DBMS):

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

Other Class Diagram Items

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

CLASS DIAGRAM OF EMS: -

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

Levels of Data Flow Diagrams :-

Level 0: Context Diagram

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

Level 1: Process Decomposition

Level 2: Deeper Dives

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

Level 3: Increasing Complexity

DFD OF EMS SYSTEM: -

Importance of ERDs and their uses

How to create an ERD

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

The three main cardinalities are:

E-R DIAGRAM OF EMS: -

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

STATE TRANSITION DIAGRAM :-

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

Use Case Diagrams

How to Draw a Use Case Diagram?

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

Where to Use a Use Case Diagram?

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

Use case diagrams can be used for −

USE CASE DIAGRAM –

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

Activity Diagram Notations –

Action or Activity State – An activity represents execution of an action on objects or by objects. We

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)

Fork – Fork nodes are used to support concurrent activities.

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING PRASHANT JAIN (0701CS223D06)