Laboratory Manual

School of
Name of the School:
Computer
Sciences and
Engineering
Name of the Department: Computer Science and
Engineering
Name of the Programme: BTech CSE

Class: BAO/CSF/CTIS/IoT/CSE

Course/ Course Code:

17YCA712/17YCF712
/17YCT713/17YCI712/
17YCS712-: Object
Oriented Analysis and
Design Lab

Academic Year: 2021-22

COVER PAGE

1
 Guidelines
Laboratory rules

1. Attendance is required for all lab classes. Students who do not attend
lab will not receive credit.

2. Ensure that you are aware of the test and its procedure before each lab class.
You will NOT be allowed to attend the class if you a renortunprepared!

3. Personal safety is top priority. Do not use equipment that is not assigned to you.

4. All accidents must be reported to your instructor or laboratory supervisor.

5. The surroundings near the equipment must be cleaned before leaving each lab
class.

6. Ensure that readings are checked and marked by your TA for each lab period.

Laboratory report

1. Each student has to submit the report for each experiment.

2. Your report is to be written only in the space provided in the manual
3. Please write your number and, batch and group number.
4. Your report must be neat, well organized, and make a professional
impact. Label all axes and include proper units.
5. Your reports should be submitted within 7 days and before the
beginning of the lab class of the next batch.
6. Your reports will be as per rubrics provided at the end of each experiment
7. Anyone caught plagiarizing work in the laboratory report, from a current
or past student's notebook, will receive 0 on the grading scale.

2
Name of Student ……………………………………

Academic Year ……………………………………

Programm ……………………………………

Class/Div/ Roll No ……………………………………

PRN No. ……………………………………

3
 CERTIFICTAE

This is to certify that Mr./Miss

Roll
no…………………... PRN No…………………………………of
class………
…………..has satisfactorily/unsatisfactorily completed the Term Work of
Course
………………………………. in this School during academic
year
………………….

Course Teacher Head of Department DeanAcademics

4
 Table of Contents

Sr. Page
Title of Experiment Date Remark Sign
No. No
1. Study of Software Development Life Cycle
2. Study of Unified Modeling language and IBM Rational
Rose/ Star UML.
3. Design of Information Flow diagram for Hospital
Management System.
4. Design of Use Case diagram for Hospital Management
System

5. Design of Activity diagram for Hospital Management

System.
6. Design of Sequence diagram for Hospital Management
System.

7. Design of Class diagram for Hospital Management

System

8. Design of State Chart diagram for Hospital

Management System.
9. Design of a Mini Project using UML.

5
 Assignment No :01

Title: Study of Software Development Life Cycle

Prerequisite: Software Engineering Basic Concepts

Theory
Software Development Life Cycle Process

The Software Development Life Cycle (SDLC) refers to a methodology with clearly
defined processes for creating high-quality software. SDLC or the Software Development
Life Cycle is a process that produces software with the highest quality and lowest cost in
the shortest time possible. SDLC provides a well-structured flow of phases that help an
organization to quickly produce high-quality software which is well-tested and ready for
production use.

Adhering to the SDLC process leads to the development of the software in a systematic
and disciplined manner.

Purpose:
• Lowering the cost of software development while simultaneously improving quality and
shortening production time.
• Purpose of SDLC is to deliver a high-quality product which is as per the customer’s
requirement.
• SDLC has defined its phases as, Requirement gathering, Designing, Coding, Testing, and
Maintenance. It is important to adhere to the phases to provide the Product in a
systematic manner.
For Example, A software has to be developed and a team is divided to work on a feature
of the product and is allowed to work as they want. One of the developers decides to
design first whereas the other decides to code first and the other on the documentation
part.
This will lead to project failure because of which it is necessary to have a good knowledge
and understanding among the team members to deliver an expected product.

SDLC Cycle
SDLC Cycle represents the process of developing software.

6
Below is the diagrammatic representation of the SDLC cycle:

SDLC Phases
Given below are the various phases:
• Requirement gathering and analysis
• Design
• Implementation or coding
• Testing
• Deployment
• Maintenance

1) Requirement Gathering and Analysis

“What do we want?”. During this phase, all the relevant information is collected from the
customer to develop a product as per their expectation. Any ambiguities must be resolved
in this phase only. Business analyst and Project Manager set up a meeting with the
customer to gather all the information like what the customer wants to build, who will be
the end-user, what is the purpose of the product. Before building a product a core
understanding or knowledge of the product is very important.

For Example: - A customer wants to have an application which involves money

transactions. In this case, the requirement has to be clear like what kind of transactions

7
will be done, how it will be done, in which currency it will be done, etc. Once the
requirement gathering is done, an analysis is done to check the feasibility of the
development of a product. In case of any ambiguity, a call is set up for further discussion.
Once the requirement is clearly understood, the SRS (Software Requirement
Specification) document is created. This document should be thoroughly understood by
the developers and also should be reviewed by the customer for future reference.

2) Design
“How will we get what we want?” This phase of the SDLC starts by turning the software
specifications into a design plan called the Design Specification. All stakeholders then
review this plan and offer feedback and suggestions. It’s crucial to have a plan for
collecting and incorporating stakeholder input into this document. Failure at this stage
will almost certainly result in cost overruns at best and the total collapse of the project at
worst. In this phase, the requirement gathered in the SRS document is used as an input
and software architecture that is used for implementing system development is derived.

3) Implementation or Coding
“Let’s create what we want.”
At this stage, the actual development starts. It’s important that every developer stick to
the agreed blueprint. Also, make sure you have proper guidelines in place about the code
style and practices. Implementation/Coding starts once the developer gets the Design
document. The Software design is translated into source code. All the components of the
software are implemented in this phase.

4) Testing
“Did we get what we want?” In this stage, we test for defects and deficiencies. We fix those
issues until the product meets the original specifications. Testing starts once the coding
is complete and the modules are released for testing. In this phase, the developed
software is tested thoroughly and any defects found are assigned to developers to get
them fixed. Retesting, regression testing is done until the point at which the software is
as per the customer’s expectation. Testers refer SRS document to make sure that the
software is as per the customer’s standard.

5) Deployment
“Let’s start using what we got.”
At this stage, the goal is to deploy the software to the production environment so users

8
can start using the product. However, many organizations choose to move the product
through different deployment environments such as a testing or staging environment.
Once the product is tested, it is deployed in the production environment or first UAT
(User Acceptance testing) is done depending on the customer
expectation. In the case of UAT, a replica of the production environment is created and
the customer along with the developers does the testing. If the customer finds the
application as expected, then sign off is provided by the customer to go live.

6) Maintenance
After the deployment of a product on the production environment, maintenance of the
product i.e., if any issue comes up and needs to be fixed or any enhancement is to be done
is taken care by the developers. “Let’s get this closer to what we want.” The plan almost
never turns out perfect when it meets reality. Further, as conditions in the real-world
change, we need to update and advance
the software to match.

Conclusion: Thus, I have studied Software Development Life Cycle and its stages.

9
 Assignment No :02

Title: Study of Unified Modeling language and IBM Rational Rose/ Star UML.

Prerequisite: Software Engineering Basic Concepts

Theory

StarUML is an open source software modeling tool that supports the UML (Unified
Modeling Language) framework for system and software modeling. It is based on UML
version 1.4, provides eleven different types of diagram and it accepts UML 2.0 notation.
It actively supports the MDA (Model Driven Architecture) approach by supporting the
UML profile concept and allowing to generate code for multiple languages.

System Requirements: Windows 2000, Windows XP, or higher; Microsoft Internet

Explorer 5.0 or higher; 128 MB RAM (256MB recommended); 110 MB hard disc space
(150MB space recommended)

License & Pricing: Open Source

Installation

The installer follows the classic Windows install procedure without issues.

Documentation

The same help that could be browsed on the StarUML web site is available with the tool
on your desktop. Documentation describes the concepts of tool but on high level vision.
A more detailed documentation is available for the diagramming functions. Sample
projects are provided with the tool and one of them contains the model of the tool itself,
showing that the developers were able to eat their own dog food. Besides English,
documentation exists in Korean, Japanese and Russian.

Configuration

Some general and diagram configurations options are available from the Tools/Option
menu. You will find in this window also the configuration switches for the code
generation. The interface is also very configurable as you can select what part of the tool
you would like to view or not.

Features

When you start a new project, StarUML proposes which approach you want to use: 4+1
(Krutchen), Rational, UML components (from Cheesman and Daniels book), default or
empty. Depending on the approach, profiles and/or frameworks may be included and
loaded. If you don't follow a specific approach, the "empty" choice could be used. Although

10
a project can be managed as one file, it may be convenient to divide it into many units and
manage them separately if many developers are working on it together.

StarUML makes a clear conceptual distinction between models, views and diagrams. A
Model is an element that contains information for a software model. A View is a visual
expression of the information contained in a model, and a Diagram is a collection of view
elements that represent the user's specific design thoughts.

StarUML is build as a modular and open tool. It provides frameworks for extending the
functionality of the tool. It is designed to allow access to all functions of the model/meta-
model and tool through COM Automation, and it provides extension of menu and option
items. Also, users can create their own approaches and frameworks according to their
methodologies. The tool can also be integrated with any external tools.

StarUML supports the following diagram types

Use Case Diagram

Class Diagram

Sequence Diagram

Collaboration Diagram

Statechart Diagram

Activity Diagram

Component Diagram

Deployment Diagram

Composite Structure Diagram

11
The user interface is intuitive. On the upper right side, a window allows to rapidly
navigate between all the content of a project, adopting either a model or a diagram view.
Multiple diagrams can be open at the same time and tabs allow switching rapidly between
views. The lower right window allows to document the current diagram, either with plain
text or attaching an external document. During diagram editing, "wizards" are located
around the object that give you the quick shortcuts to main associated tasks with your
current operation, like adding an attribute when you create a class for instance. A right-
click on the mouse brings the full set of operations at your disposal.

StarUML has also a model verification feature. You can export diagram in different
formats (jpg, bmp, wmf). It also supports a patterns approach and import of Rational Rose
files.

StarUML Generator is platform module to generate various artifacts (like as Microsoft

Word, Excel, PowerPoint, and Text-based artifacts) by templates depending on UML
model elements in StarUML. The users can define their own templates and can apply
many different kinds of templates to the same UML model, so the users can get various
artifacts automatically, easily and fast. The tool supports code generation and reverse
engineering for Java, C# and C++.

Conclusion

StarUML has many powerful features and is certainly more than a "simple" diagramming
tool. With its support of MDA (Model Driven Architecture), it is more aimed at people
using UML in an intensive way and with some code generations objectives than for simply
drawing diagrams to document requirements. However, using StarUML just as a
diagramming tool work fine, especially on Windows as the tool is built with Delphi and
might execute faster than the Java-based tools.

12
 Assignment No :03

Title: Design of Information Flow diagram for Hospital Management System.

Prerequisite: Software Engineering Basic Concepts

Theory:

An information flow diagram (IFD) is an illustration of information flow throughout an

organization. An IFD shows the relationship between external and internal information
flows between organizations. It also shows the relationship between the internal
departments, sub-systems, sub-systems.

When to Use Information Flow Diagram?

The concept of Information Flow Diagram was initially used in radio transmission which
may consist of: feedback, a reply or response to the signal that was given out; the return
paths can be two-way or bi-directional: information can flow back and forth. Examples of
media include:
• Word Of Mouth
• Radio
• Email
• Feedback
• A Reply Or Response To The Signal
Etc
The main purpose of an information flow diagram visualizes the forwarding of
information and the analysis of different situations. It is a behavior diagram that shows
the exchange of data between systems.
They are also used to describe the circulation of information within systems and typically
used for the following cases:
• Develop A High-Level Overview Of The Flow Of Information In An Organization.
• Highlight Detailed Flows In An Individual Task.
• Describe The Flow Of Information Inside And Around Organizations And Between
Departments.
• Understand Business Process Bottlenecks In Sequential, Deferred, Real-Time,
Parallel, Wheel, One-To-Many, Many-To-Many And Many-To-One-To-Many
Information Flows.

Information Flow Diagram vs Data Flow Diagram vs Flowchart

• Information flow diagram s are often confused with data flow diagrams (DFDs).
• Information Flow Diagrams Show Information As Sources, Destination, And
Flows.
• DFDs Show Processes Where Inputs Are Transformed Into Outputs. Databases
Are Also Present In DFDs To Show Where Data Is Held Within The Systems. In
DFDs Information Destinations Are Called “Sinks”.
• Flowcharts Show The Flow Of Control. In A Flow Chart, A Reader Can Determine
What Operations Will Be Performed, In What Order, And Under What

13
 Circumstances.

Information Diagram at a Glance

A customer needs to make an order. The customer first posts the order to the sales
department. Customer’s order details are then entered into a centralized database which
can only be accessed by the warehouse (to make up the order); the goods are handed to
the dispatch department with a delivery note attached to them for delivery. On delivery,
the customer receives the goods and the delivery note (which are handled by a member
of the dispatch department). The sales department creates an invoice that is posted to the
customer; the accounts department then assesses a copy of the invoice from the
centralized database. The customer is then required to post the payment to the accounts
department.

Information Flow Diagram For Hospital Management System

14
15
 Assignment No :04

Title: Design of Use Case diagram for Hospital Management System.

Prerequisite: Software Engineering Basic Concepts

Theory:

A use case diagram is used to represent the dynamic behavior of a system. It encapsulates
the system's functionality by incorporating use cases, actors, and their relationships. It
models the tasks, services, and functions required by a system/subsystem of an
application. It depicts the high-level functionality of a system and also tells how the user
handles a system.

Purpose of Use Case Diagrams

The main purpose of a use case diagram is to portray the dynamic aspect of a system. It
accumulates the system's requirement, which includes both internal as well as external
influences. It invokes persons, use cases, and several things that invoke the actors and
elements accountable for the implementation of use case diagrams. It represents how an
entity from the external environment can interact with a part of the system.

Following are the purposes of a use case diagram given below:

1. It gathers the system's needs.

2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.

How to draw a Use Case diagram?

It is essential to analyze the whole system before starting with drawing a use case
diagram, and then the system's functionalities are found. And once every single
functionality is identified, they are then transformed into the use cases to be used in the
use case diagram.

After that, we will enlist the actors that will interact with the system. The actors are the
person or a thing that invokes the functionality of a system. It may be a system or a private
entity, such that it requires an entity to be pertinent to the functionalities of the system
to which it is going to interact.

Once both the actors and use cases are enlisted, the relation between the actor and use
case/ system is inspected. It identifies the no of times an actor communicates with the
16
system. Basically, an actor can interact multiple times with a use case or system at a
particular instance of time.

Following are some rules that must be followed while drawing a use case diagram:

1. A pertinent and meaningful name should be assigned to the actor or a use case of
a system.
2. The communication of an actor with a use case must be defined in an
understandable way.
3. Specified notations to be used as and when required.

The most significant interactions should be represented among the multiple no of

interactions between the use case and actors.

Example of a Use Case Diagram

A use case diagram depicting the Online Shopping website is given below.

Here the Web Customer actor makes use of any online shopping website to purchase
online. The top-level uses are as follows; View Items, Make Purchase, Checkout, Client
Register. The View Items use case is utilized by the customer who searches and view
products. The Client Register use case allows the customer to register itself with the
website for availing gift vouchers, coupons, or getting a private sale invitation. It is to be
noted that the Checkout is an included use case, which is part of Making Purchase, and
it is not available by itself.

17
The View Items is further extended by several use cases such as; Search Items, Browse
Items, View Recommended Items, Add to Shopping Cart, Add to Wish list. All of these
extended use cases provide some functions to customers, which allows them to search
for an item. The View Items is further extended by several use cases such as; Search Items,
Browse Items, View Recommended Items, Add to Shopping Cart, Add to Wish list. All of
these extended use cases provide some functions to customers, which allows them to
search for an item.

Both View Recommended Item and Add to Wish List include the Customer
Authentication use case, as they necessitate authenticated customers, and
simultaneously item can be added to the shopping cart without any user authentication.

18
19
 Assignment No :05

Title: Design of Activity diagram for Hospital Management System

Prerequisite: Software Engineering Basic Concepts

Theory:

In UML, the activity diagram is used to demonstrate the flow of control within the system
rather than the implementation. It models the concurrent and sequential activities.

The activity diagram helps in envisioning the workflow from one activity to another. It
put emphasis on the condition of flow and the order in which it occurs. The flow can be
sequential, branched, or concurrent, and to deal with such kinds of flows, the activity
diagram has come up with a fork, join, etc.

It is also termed as an object-oriented flowchart. It encompasses activities composed of a

set of actions or operations that are applied to model the behavioral diagram.

Components of an Activity Diagram

Following are the component of an activity diagram:

Activities

The categorization of behavior into one or more actions is termed as an activity. In other
words, it can be said that an activity is a network of nodes that are connected by edges.
The edges depict the flow of execution. It may contain action nodes, control nodes, or
object nodes.

The control flow of activity is represented by control nodes and object nodes that
illustrates the objects used within an activity. The activities are initiated at the initial node
and are terminated at the final node.

Activity partition /swimlane

The swimlane is used to cluster all the related activities in one column or one row. It can
be either vertical or horizontal. It used to add modularity to the activity diagram. It is not
necessary to incorporate swimlane in the activity diagram. But it is used to add more
transparency to the activity diagram.

20
Forks

Forks and join nodes generate the concurrent flow inside the activity. A fork node consists
of one inward edge and several outward edges. It is the same as that of various decision
parameters. Whenever a data is received at an inward edge, it gets copied and split
crossways various outward edges. It split a single inward flow into multiple parallel
flows.

Join Nodes

Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all of
the inward edges as it synchronizes the flow of input across one single output (outward)
edge.

Pins

It is a small rectangle, which is attached to the action rectangle. It clears out all the messy
and complicated thing to manage the execution flow of activities. It is an object node that
precisely represents one input to or output from the action.

Notation of an Activity diagram

Activity diagram constitutes following notations:

Initial State: It depicts the initial stage or beginning of the set of actions.

21
Final State: It is the stage where all the control flows and object flows end.

Decision Box: It makes sure that the control flow or object flow will follow only one path.

Action Box: It represents the set of actions that are to be performed.

Why use Activity Diagram?

An event is created as an activity diagram encompassing a group of nodes associated with

edges. To model the behavior of activities, they can be attached to any modeling element.
It can model use cases, classes, interfaces, components, and collaborations.

It mainly models processes and workflows. It envisions the dynamic behavior of the
system as well as constructs a runnable system that incorporates forward and reverse
engineering. It does not include the message part, which means message flow is not
represented in an activity diagram.

It is the same as that of a flowchart but not exactly a flowchart itself. It is used to depict
the flow between several activities.

How to draw an Activity Diagram?

22
An activity diagram is a flowchart of activities, as it represents the workflow among
various activities. They are identical to the flowcharts, but they themself are not exactly
the flowchart. In other words, it can be said that an activity diagram is an enhancement
of the flowchart, which encompasses several unique skills.

Since it incorporates swimlanes, branching, parallel flows, join nodes, control nodes, and
forks, it supports exception handling. A system must be explored as a whole before
drawing an activity diagram to provide a clearer view of the user. All of the activities are
explored after they are properly analyzed for finding out the constraints applied to the
activities. Each and every activity, condition, and association must be recognized.

After gathering all the essential information, an abstract or a prototype is built, which is
then transformed into the actual diagram.

Following are the rules that are to be followed for drawing an activity diagram:

1. A meaningful name should be given to each and every activity.

2. Identify all of the constraints.
3. Acknowledge the activity associations.

Example of an Activity Diagram

An example of an activity diagram showing the business flow activity of order processing
is given below.

Here the input parameter is the Requested order, and once the order is accepted, all of
the required information is then filled, payment is also accepted, and then the order is
shipped. It permits order shipment before an invoice is sent or payment is completed.

When to use an Activity Diagram?

23
An activity diagram can be used to portray business processes and workflows. Also, it
used for modeling business as well as the software. An activity diagram is utilized for the
followings:

• To graphically model the workflow in an easier and understandable way.

• To model the execution flow among several activities.
• To model comprehensive information of a function or an algorithm employed
within the system.
• To model the business process and its workflow.
• To envision the dynamic aspect of a system.
• To generate the top-level flowcharts for representing the workflow of an
application.
• To represent a high-level view of a distributed or an object-oriented system.

24
25
 Assignment No :06

Title: Design of Sequence diagram for Hospital Management System.

Prerequisite: Software Engineering Basic Concepts

Theory:
Sequence Diagram

The sequence diagram represents the flow of messages in the system and is also termed
as an event diagram. It helps in envisioning several dynamic scenarios. It portrays the
communication between any two lifelines as a time-ordered sequence of events, such that
these lifelines took part at the run time. In UML, the lifeline is represented by a vertical
bar, whereas the message flow is represented by a vertical dotted line that extends across
the bottom of the page. It incorporates the iterations as well as branching.

Purpose of a Sequence Diagram

1. To model high-level interaction among active objects within a system.

2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.

Notations of a Sequence Diagram

Lifeline

An individual participant in the sequence diagram is represented by a lifeline. It is

positioned at the top of the diagram.

Actor

A role played by an entity that interacts with the subject is called as an actor. It is out of
the scope of the system. It represents the role, which involves human users and external
hardware or subjects. An actor may or may not represent a physical entity, but it purely
depicts the role of an entity. Several distinct roles can be played by an actor or vice versa.

26
 Activation

It is represented by a thin rectangle on the lifeline. It describes that time period in which
an operation is performed by an element, such that the top and the bottom of the
rectangle is associated with the initiation and the completion time, each respectively.

C++ vs Java

Messages

The messages depict the interaction between the objects and are represented by arrows.
They are in the sequential order on the lifeline. The core of the sequence diagram is
formed by messages and lifelines.

Following are types of messages enlisted below:

o Call Message: It defines a particular communication between the lifelines of an

interaction, which represents that the target lifeline has invoked an operation.

o Return Message: It defines a particular communication between the lifelines of

interaction that represent the flow of information from the receiver of the

27
 corresponding caller message.

o Self Message: It describes a communication, particularly between the lifelines of an

interaction that represents a message of the same lifeline, has been invoked.

o Recursive Message: A self message sent for recursive purpose is called a recursive
message. In other words, it can be said that the recursive message is a special case of
the self message as it represents the recursive calls.

o Create Message: It describes a communication, particularly between the lifelines of an

interaction describing that the target (lifeline) has been instantiated.

28
 o Destroy Message: It describes a communication, particularly between the lifelines of
an interaction that depicts a request to destroy the lifecycle of the target.

o Duration Message: It describes a communication particularly between the lifelines of

an interaction, which portrays the time passage of the message while modeling a
system.

Note
A note is the capability of attaching several remarks to the element. It basically carries useful
information for the modelers.

Example of a Sequence Diagram

An example of a high-level sequence diagram for online bookshop is given below.

Any online customer can search for a book catalog, view a description of a particular book,
add a book to its shopping cart, and do checkout.

29
Benefits of a Sequence Diagram

1. It explores the real-time application.

2. It depicts the message flow between the different objects.
3. It has easy maintenance.
4. It is easy to generate.
5. Implement both forward and reverse engineering.
6. It can easily update as per the new change in the system.

The drawback of a Sequence Diagram

1. In the case of too many lifelines, the sequence diagram can get more complex.
2. The incorrect result may be produced, if the order of the flow of messages changes.
3. Since each sequence needs distinct notations for its representation, it may make
the diagram more complex.
4. The type of sequence is decided by the type of message.

30
31
 Assignment No :07

Title: Design of Class diagram for Hospital Management System.

Prerequisite: Software Engineering Basic Concepts

Theory:
UML Class Diagram

The class diagram depicts a static view of an application. It represents the types of objects
residing in the system and the relationships between them. A class consists of its objects, and
also it may inherit from other classes. A class diagram is used to visualize, describe, document
various different aspects of the system, and also construct executable software code.

It shows the attributes, classes, functions, and relationships to give an overview of the software
system. It constitutes class names, attributes, and functions in a separate compartment that
helps in software development. Since it is a collection of classes, interfaces, associations,
collaborations, and constraints, it is termed as a structural diagram.

Purpose of Class Diagrams

The main purpose of class diagrams is to build a static view of an application. It is the only
diagram that is widely used for construction, and it can be mapped with object-oriented
languages. It is one of the most popular UML diagrams. Following are the purpose of class
diagrams given below:

1. It analyses and designs a static view of an application.

2. It describes the major responsibilities of a system.
3. It is a base for component and deployment diagrams.
4. It incorporates forward and reverse engineering.

Benefits of Class Diagrams

5. It can represent the object model for complex systems.

6. It reduces the maintenance time by providing an overview of how an application is
structured before coding.
7. It provides a general schematic of an application for better understanding.
8. It represents a detailed chart by highlighting the desired code, which is to be
programmed.

It is helpful for the stakeholders and the developers.

Vital components of a Class Diagram

32
The class diagram is made up of three sections:

22.4M
475
HTML Tutorial
o Upper Section: The upper section encompasses the name of the class. A class is a
representation of similar objects that shares the same relationships, attributes,
operations, and semantics. Some of the following rules that should be taken into
account while representing a class are given below:
a. Capitalize the initial letter of the class name.
b. Place the class name in the center of the upper section.
c. A class name must be written in bold format.
d. The name of the abstract class should be written in italics format.
o Middle Section: The middle section constitutes the attributes, which describe the quality
of the class. The attributes have the following characteristics:
. The attributes are written along with its visibility factors, which are public (+), private (-
), protected (#), and package (~).
a. The accessibility of an attribute class is illustrated by the visibility factors.
b. A meaningful name should be assigned to the attribute, which will explain its
usage inside the class.
o Lower Section: The lower section contain methods or operations. The methods are
represented in the form of a list, where each method is written in a single line. It
demonstrates how a class interacts with data.

Relationships

In UML, relationships are of three types:

o Dependency: A dependency is a semantic relationship between two or more classes

where a change in one class cause changes in another class. It forms a weaker
relationship.
In the following example, Student_Name is dependent on the Student_Id.

33
 o Generalization: A generalization is a relationship between a parent class (superclass)
and a child class (subclass). In this, the child class is inherited from the parent class.
For example, The Current Account, Saving Account, and Credit Account are the
generalized form of Bank Account.

o Association: It describes a static or physical connection between two or more objects.

It depicts how many objects are there in the relationship.
For example, a department is associated with the college.

Multiplicity: It defines a specific range of allowable instances of attributes. In case if a

range is not specified, one is considered as a default multiplicity.

For example, multiple patients are admitted to one hospital.

34
Aggregation: An aggregation is a subset of association, which represents has a relationship. It
is more specific then association. It defines a part-whole or part-of relationship. In this kind of
relationship, the child class can exist independently of its parent class.

The company encompasses a number of employees, and even if one employee resigns, the
company still exists.

Composition: The composition is a subset of aggregation. It portrays the dependency between

the parent and its child, which means if one part is deleted, then the other part also gets
discarded. It represents a whole-part relationship.

A contact book consists of multiple contacts, and if you delete the contact book, all the
contacts will be lost.

Class Diagram Example

A class diagram describing the sales order system is given below.

Usage of Class diagrams

The class diagram is used to represent a static view of the system. It plays an essential role in
the establishment of the component and deployment diagrams. It helps to construct an

35
executable code to perform forward and backward engineering for any system, or we can say
it is mainly used for construction. It represents the mapping with object-oriented languages
that are C++, Java, etc. Class diagrams can be used for the following purposes:

1. To describe the static view of a system.

2. To show the collaboration among every instance in the static view.
3. To describe the functionalities performed by the system.
4. To construct the software application using object-oriented languages.

36
 Assignment No :08

Title: Design of State Chart diagram for Hospital Management System

Prerequisite: Software Engineering Basic Concepts

Theory:

UML State Machine Diagram

The state machine diagram is also called the Statechart or State Transition diagram, which
shows the order of states underwent by an object within the system. It captures the software
system's behavior. It models the behavior of a class, a subsystem, a package, and a complete
system.

It tends out to be an efficient way of modeling the interactions and collaborations in the
external entities and the system. It models event-based systems to handle the state of an
object. It also defines several distinct states of a component within the system. Each
object/component has a specific state.

Following are the types of a state machine diagram that are given below:

1. Behavioral state machine

The behavioral state machine diagram records the behavior of an object within the
system. It depicts an implementation of a particular entity. It models the behavior of
the system.
2. Protocol state machine
It captures the behavior of the protocol. The protocol state machine depicts the change
in the state of the protocol and parallel changes within the system. But it does not
portray the implementation of a particular component.

Why State Machine Diagram?

Since it records the dynamic view of a system, it portrays the behavior of a software application.
During a lifespan, an object underwent several states, such that the lifespan exist until the
program is executing. Each state depicts some useful information about the object.

It blueprints an interactive system that response back to either the internal events or the
external ones. The execution flow from one state to another is represented by a state machine
diagram. It visualizes an object state from its creation to its termination.

37
The main purpose is to depict each state of an individual object. It represents an interactive
system and the entities inside the system. It records the dynamic behavior of the system.

Notation of a State Machine Diagram

Following are the notations of a state machine diagram enlisted below:

Initial state: It defines the initial state (beginning) of a system, and it is represented by a black
filled circle.

Final state: It represents the final state (end) of a system. It is denoted by a filled circle present
within a circle.

Decision box: It is of diamond shape that represents the decisions to be made on the basis of
an evaluated guard.

Transition: A change of control from one state to another due to the occurrence of some
event is termed as a transition. It is represented by an arrow labeled with an event due to which
the change has ensued.

State box: It depicts the conditions or circumstances of a particular object of a class at a specific
point of time. A rectangle with round corners is used to represent the state box.

Types of State
The UML consist of three states:
1. Simple state: It does not constitute any substructure.
2. Composite state: It consists of nested states (substates), such that it does not contain
more than one initial state and one final state. It can be nested to any level.
3. Submachine state: The submachine state is semantically identical to the composite
state, but it can be reused.

How to Draw a State Machine Diagram?

38
The state machine diagram is used to portray various states underwent by an object. The
change in one state to another is due to the occurrence of some event. All of the possible
states of a particular component must be identified before drawing a state machine diagram.

The primary focus of the state machine diagram is to depict the states of a system. These states
are essential while drawing a state transition diagram. The objects, states, and events due to
which the state transition occurs must be acknowledged before the implementation of a state
machine diagram.

Following are the steps that are to be incorporated while drawing a state machine diagram:

1. A unique and understandable name should be assigned to the state transition that
describes the behavior of the system.
2. Out of multiple objects, only the essential objects are implemented.
3. A proper name should be given to the events and the transitions.

When to use a State Machine Diagram?

The state machine diagram implements the real-world models as well as the object-oriented
systems. It records the dynamic behavior of the system, which is used to differentiate between
the dynamic and static behavior of a system.

It portrays the changes underwent by an object from the start to the end. It basically envisions
how triggering an event can cause a change within the system.

State machine diagram is used for:

For modeling the object states of a system.

For modeling the reactive system as it consists of reactive objects.

For pinpointing the events responsible for state transitions.

For implementing forward and reverse engineering.

Example of a State Machine Diagram

4. An example of a top-level state machine diagram showing Bank Automated Teller

Machine (ATM) is given below.
5. Initially, the ATM is turned off. After the power supply is turned on, the ATM starts
performing the startup action and enters into the Self Test state. If the test fails, the
ATM will enter into the Out Of Service state, or it will undergo a triggerless transition to
the Idle state. This is the state where the customer waits for the interaction.
6. Whenever the customer inserts the bank or credit card in the ATM's card reader, the
ATM state changes from Idle to Serving Customer, the entry action readCard is
performed after entering into Serving Customer state. Since the customer can cancel
the transaction at any instant, so the transition from Serving Customer state back to
the Idle state could be triggered by cancel event.

39
Here the Serving Customer is a composite state with sequential substates that are Customer
Authentication, Selecting Transaction, and Transaction.

Customer Authentication and Transaction are the composite states itself is displayed by a
hidden decomposition indication icon. After the transaction is finished, the Serving
Customer encompasses a triggerless transition back to the Idle state. On leaving the state, it
undergoes the exit action ejectCard that discharges the customer card.

40
41
 Assignment No :09
Title: Design of a Mini Project using UML.

Prerequisite: Software Engineering Basic Concepts

Theory:

Draw the Following Diagrams for your Final Year Project

1) DFD Diagram
2) Class Diagram
3) Sequence Diagram
4) Activity Diagram
5) State Chart Diagram
6) Deployment Diagram
7) Component Diagram

42