IMS ENGINEERING COLLEGE

LABORATORY FILE
SOFTWARE ENGINEERING
(BCS-651)

B.TECH – III YEAR

(EVEN SEM 2024-2025)

Name

Roll No.

Section-Batch

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

IMS ENGINEERING COLLEGE

(Affiliated to Dr A P J Abdul Kalam Technical University, Lucknow )
Approved by AICTE - Accredited by NAAC – ‘A’ Grade
NH#24, Adhyatmik Nagar, Ghaziabad, UP, India
www.imsec.ac.in
VISION OF THE INSTITUTE

To make IMSEC an Institution of Excellence for empowering students through technical education,
incorporating human values, and developing engineering acumen for innovations and leadership
skills to upgrade society

MISSION OF THE INSTITUTE

Mission 1: To promote academic excellence by continuous learning in core and emerging

Engineering domains using innovative teaching and learning methodologies.

Mission 2: To inculcate values and ethics among the learners.

Mission 3: To promote industry interactions and cultivate young minds for entrepreneurship.

Mission 4: To create a conducive learning ecosystem and research environment on a perpetual basis to
develop students as technology leaders and entrepreneurs who can address tomorrow's societal needs.

VISION OF THE DEPARTMENT

To provide globally competent professionals in Computer Science & Engineering embedded with sound
technical knowledge, aptitude for research and innovation, and nurture future leaders with ethical values to
cater to industrial & societal needs.

MISSION OF THE DEPARTMENT

Mission 1: To provide quality education in the theoretical and applied foundations of Computer Science
& Engineering.

Mission 2: To Conduct research in Computer Science & Engineering, resulting in innovations, thereby
nurturing entrepreneurial thinking.

Mission 3: To inculcate team building skills and promote life-long learning with high societal and ethical
values.
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

PROGRAMME EDUCATIONAL OBJECTIVES (PEOs)

Graduate Will:

PEO1: Possess core theoretical and practical knowledge in Computer Science and Engineering for
successful career development in industry, pursuing higher studies or entrepreneurship.

PEO2: Ability to imbibe lifelong learning for global challenges to impact society and the environment.

PEO3: To demonstrate work productivity, leadership and managerial skills, ethics, and human
values in a progressive career path.
PEO4: To exhibit communication skills and collaborative skill plans and participate in multidisciplinary
Computer Science & Engineering fields.

PROGRAMME SPECIFIC OUTCOME (PSOs)

PSO1: To analyze and demonstrate the recent engineering practices, ethical values, and strategies
for real-time world problems to meet the challenges for the future.

PSO2: To develop an adaptive computing system using computational intelligence strategies and
algorithmic design to address diverse data analysis and machine learning challenges.
PROGRAM OUTCOMES
Engineering Graduates will be able to:

1. Engineering knowledge: Apply the knowledge of mathematics, science, engineering

fundamentals, and an engineering specialization to the solution of complex engineering
problems.
2. Problem analysis: Identify, formulate, review research literature, and analyze complex
engineering problems reaching substantiated conclusions using first principles of
mathematics, natural sciences, and engineering sciences.
3. Design/development of solutions: Design solutions for complex engineering problems and
design system components or processes that meet the specified needs with appropriate
consideration for the public health and safety, and the cultural, societal, andenvironmental
considerations.
4. Conduct investigations of complex problems: Use research-based knowledge and research
methods including design of experiments, analysis and interpretation of data, and synthesis
of the information to provide valid conclusions.
5. Modern tool usage: Create, select, and apply appropriate techniques, resources, and modern
engineering and IT tools including prediction and modelling to complex engineering
activities with an understanding of the limitations.
6. The engineer and society: Apply reasoning informed by the contextual knowledge to assess
societal, health, safety, legal and cultural issues and the consequent responsibilities relevant
to the professional engineering practice.
7. Environment and sustainability: Understand the impact of the professional engineering
solutions in societal and environmental contexts, and demonstrate the knowledge of, and
need for sustainable development.
8. Ethics: Apply ethical principles and commit to professional ethics and responsibilities and
norms of the engineering practice.
9. Individual and team work: Function effectively as an individual, and as a member or leader
in diverse teams, and in multidisciplinary settings.
10. Communication: Communicate effectively on complex engineering activities with the
engineering community and with society at large, such as, being able to comprehend and
write effective reports and design documentation, make effective presentations, and give
and receive clear instructions.
11. Project management and finance: Demonstrate knowledge and understanding of the
engineering and management principles and apply these to one’s own work, as a member
and leader in a team, to manage projects and in multidisciplinary environments.
12. Life-long learning: Recognize the need for, and have the preparation and ability to engage
in independent and life-long learning in the broadest context of technological change.
GENERAL LABORATORY INSTRUCTIONS

1. Students are advised to come to the laboratory at least 5 minutes before (to the starting time),
those who come after 5 minutes will not be allowed into the lab.

2. Plan your task properly much before to the commencement, come prepared to the lab with
the synopsis / program / experiment details.

3. Student should enter into the laboratory with:

 Laboratory observation notes with all the details (Problem statement, Aim, Algorithm,
Procedure, Program, Expected Output, etc.,) filled in for the lab session.

 Laboratory Record updated up to the last session experiments and other utensils (if
any) needed in the lab.

 Proper Dress code and Identity card.

4. Sign in the laboratory login register, write the TIME-IN, and occupy the computer system
allotted to you by the faculty.

5. Execute your task in the laboratory, and record the results / output in the lab observation
note book, and get certified by the concerned faculty.

6. All the students should be polite and cooperative with the laboratory staff, must maintain
the discipline and decency in the laboratory.

7. Computer labs are established with sophisticated and high end branded systems, which
should be utilized properly.

8. Students / Faculty must keep their mobile phones in SWITCHED OFF mode during the lab
sessions. Misuse of the equipment, misbehaviors with the staff and systems etc., will attract
severe punishment.

9. Students must take the permission of the faculty in case of any urgency to go out; if anybody
found loitering outside the lab / class without permission during working hours will be treated
seriously and punished appropriately.

10. Students should LOG OFF/ SHUT DOWN the computer system before he/she leaves the
lab after completing the task (experiment) in all aspects. He/she must ensure the system / seat
is kept properly.
 DETAILS OF THE EXPERIMENTS CONDUCTED

INDEX

S.No TITLE OF THE EXPERIMENT DATE OF FACULTY

SUBMISSION SIGNATURE

10
 STUDY AND EVALUATION SCHEME

Course Course
Teaching Scheme Credits Assigned
Code Name
Theory Practical Tutorial Theory Practical Tutorial Total
BCS-601(T)
Software
B CS-651 (P)
Engineering 03 02 01 03 01 01 05
(70 (50
Marks) Marks)
 IMS Engineering College
NH-09, Adhyatmik Nagar, Near Dasna, Distt. Ghaziabad, U.P.
Tel: (0120) 4940000
Department of Computer Science and Engineering

Course Name: Software Engineering Lab Course Code: KCS-651

Semester / Year: 6th /3rd NBA Code: C 319

Bloom’s
COURSE OUTCOMES
Level
K2, K4
C319.1 Identify ambiguities, inconsistencies and incompleteness from a requirements
specification and state functional and non-functional requirement
K3, K5
C319.2 Identify different actors and use cases from a given problem statement and
draw use case diagram to associate use cases with different types of
relationship
K4, K5
C319.3 Draw a class diagram after identifying classes and association among them

Graphically represent various UML diagrams and associations among them K4, K5
C319.4
and identify the logical sequence of activities undergoing in a system, and
represent them pictorially.
Able to use modern engineering tools for specification, design, K3, K4
C319.5
implementation and testing

CO-PO Matrix

Course
PO 1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12 PSO1 PSO2
Outcome

C319.1 3 3 3 3 2 1 1 1 2 3 3 2 3 3

C319.2 3 3 3 3 2 1 2 2 2 3 3 2 3 3

C319.3 3 3 3 3 2 2 1 2 2 3 3 2 3 3

C319.4 3 3 3 3 2 1 1 1 2 3 3 2 3 3

C319.5 3 3 3 3 2 2 2 1 2 3 3 3 3 3

C319 3.0 3.0 3.0 3.0 2.0 1.4 1.4 1.4 2.0 3.0 3.0 2.2 3.0 3.0
 LIST OF PROGRAMS

Subject: Software Engineering Lab Code: BCS-651

S.NO. NAME OF EXPERIMENT MAPPING

WITH CO
1. Prepare a SRS document in line with the IEEE recommended C319.1
standards.
2. Draw the use case diagram and specify the role of each of the actors. C319.2
Also state the precondition, post condition and function of each use
case.
3. Draw the activity diagram. C319.4

4. Identify the classes. Classify them as weak and strong classes and C319.3
draw the class diagram.
5. Draw the sequence diagram for any two scenarios. C319.4

6. Draw the collaboration diagram. C319.4

7. Draw the state chart diagram. C319.4

8. Draw the component diagram. C319.4

9. Perform forward engineering in java. (Model to code conversion) C319.5

10. Perform reverse engineering in java. (Code to Model conversion) C319.5

11. Draw the deployment diagram. C319.5

Experiment Beyond Lab Syllabus

12. Project on Book Bank Management C319.5

13. Project on ATM Machine C319.5

 EXPERIMENT NO. – 1

AIM: Prepare an SRS document in line with the IEEE recommended

standards

Procedure:

Project Title: Food Label Reader. This page contains SRS documentation for the Food
Label Reader Web Application. The SRS is produced at the culmination of the analysis
phase. The function and performance allocated to software as part of the system
engineering are refined by establishing a complete information description, a detailed
functional description, a representation of system behavior, indication of performance
requirements, design constraints, validation criteria, and other related requirement
details. This SRS is a technical specification of requirements for the Food Label Reader
system. It describes what the proposed system should do without explaining how it will
do it. It also defines the complete external behavior of the system.

Purpose:
The main purpose of the Food Label Reader Web Application is to simplify the
understanding of food product labels for consumers. The goal is to develop a system that
can scan, read, and interpret ingredients and nutritional information from food packages
and translate them into simple, non-scientific terms. Additionally, it will describe the
effects of these components on human health and indicate safe consumption limits. This
document serves as a clear and concise guide for developers, stakeholders, and users
involved in the project.

Scope:
This document outlines the requirement specification for the Food Label Reader Web
Application. It focuses on defining the system’s behavior, modules, and functionalities.
References to external Optical Character Recognition (OCR) tools and nutritional
databases are included only as necessary to define system interfaces and dependencies.
 Feasibility Study:

The feasibility study ensures that the project is practical, implementable and beneficial. It
involves the following steps:
a) Understanding the challenges faced by consumers in interpreting food labels and
ingredients lists.
b) Identifying commonly used chemical additives, preservatives, and E-numbers in
packaged food.
c) Researching publicly available food safety and health guidelines (e.g., FDA, WHO) to
determine safe consumption limits.
d) Evaluating existing tools and the need for simple, easy-to-use web applications for
real-time food label analysis.

Overview:
Food Label Reader is a web-based application designed to extract and interpret
ingredient and nutritional information from food packaging. The system uses OCR and
NLP techniques to identify and translate scientific or complex ingredient names into
everyday language, explains their purpose and health effects, and provides guidance on
tolerable intake levels. It is especially useful for health-conscious individuals, parents,
people with allergies, or anyone aiming to make informed dietary decisions.

Product Perspective:
Food Label Reader provides an end-to-end pipeline for label scanning, data extraction,
ingredient interpretation, and health-based recommendations. It integrates with existing
food safety databases and APIs. The workflow includes uploading or capturing an
image of the food label, extracting the text using OCR, processing the content with
NLP, and displaying user-friendly interpretations and warnings.

Product Functions:
The application performs the following major functions:
 Label Upload – Allows users to upload or capture images of food labels.
 Text Extraction – Uses OCR to extract readable text from the uploaded label.
 Ingredient Interpretation – Decodes ingredients into simple language and explains
their purpose.

 Health Impact Analyzer – Highlights potentially harmful ingredients and suggests

daily/weekly tolerable limits.
 Allergy & Diet Match – Matches ingredients with user-defined allergies or dietary
preferences.
 Insights Reporting – Provides a summary of the label in visual and textual form.

User Characteristics:

The application is designed to be intuitive and accessible. End-users include health-

conscious consumers, nutritionists, parents, and individuals with dietary restrictions
or allergies. No specialized knowledge is needed; basic digital literacy and web
navigation skills are sufficient. Admins and developers will have role-based access
for managing backend features and monitoring system health.

General Constraints:

 Image processing and analysis require a stable server with moderate computational
power.
 Images should be clear and readable for accurate OCR performance.
 Integration with third-party APIs or databases like OpenFoodFacts or FDA datasets
may be required.
 Data security and privacy must be maintained for stored user profiles and
preferences.
 The system must support accessibility for differently-abled users.

Functional Requirements:

 Admin Module – Manage users, system logs, databases, and access control.
 Label Upload Module – Supports image upload or real-time camera capture for label
scanning.
 OCR Module – Uses OCR tools (e.g., Tesseract) to extract readable text from
 images.
 Interpretation Engine – Converts scientific terms to layman-friendly language using
NLP and predefined mappings.
 Health Analyzer Module – Evaluates ingredients against health guidelines and user
preferences.
 User Dashboard – Displays reports, tracks scan history, and allows customization of
alerts/preferences.
 Alert System – Warns users about allergens or ingredients exceeding safe levels.

Performance Requirements:

 OCR and interpretation process should be completed within 5 seconds per label
image.
 The system should support 50–100 concurrent users with minimal performance
degradation.
 Text recognition accuracy must be ≥ 85% on clear images.
 Ingredient interpretation accuracy should be ≥ 90% based on existing databases.

Design Constraints:

 The UI must be mobile-responsive and support assistive technologies (e.g., screen

reader)
 All user data must be securely stored and encrypted.
 System should follow a modular design for integration with newer food databases.
 The OCR engine should support multiple languages (initially English, with scalability
for others).
 The application should use open-source tools and libraries where possible to reduce
costs.
 EXPERIMENT NO. - 2
AIM: Draw the Use Case Diagram and specify the role of each of the
actor.

Procedure:
According to the UML specification a use case diagram is diagram that shows the
relationships among actors and use cases within a system.
Use case diagrams are often used to:
• Provide an overview of all or part of the usage requirements for a system or
organization in the form of an essential model or a business model
• Communicate the scope of a development project
• Model your analysis of your usage requirements in the form of a system use case model
Use case models should be developed from the point of view of your project
stakeholders and not from the (often technical) point of view of developers. There are
guidelines for:

1. Use Cases
A use case describes a sequence of actions that provide a measurable value to an actor. A use
case is drawn as a horizontal ellipse on a UML use case diagram.
1. Use Case Names Begin with a Strong Verb
2. Name Use Cases Using Domain Terminology
3. Place Your Primary Use Cases in The Top-Left Corner of The Diagram
4. Imply Timing Considerations by Stacking Use Cases.
Symbol

2. Actors
An actor is a person, organization, or external system that plays a role in one or more
interactions with your system (actors are typically drawn as stick figures on UML Use Case
diagrams).
1. Place Your Primary Actor(S) In the Top-Left Corner Of The Diagram
2. Draw Actors to The Outside of A Use Case Diagram
3. Name Actors with Singular, Business-Relevant Nouns
4. Associate Each Actor with One Or More Use Cases
5. Actors Model Roles, Not Positions
6. Use <> to Indicate System Actors
7. Actors don ‘t Interact With One Another
8. Introduce an Actor Called ―Time‖ to Initiate Scheduled Events
Symbol

3. Relationships
There are several types of relationships that may appear on a use case diagram:
• An association between an actor and a use case
• An association between two use cases
• A generalization between two actors
• A generalization between two use cases
Associations are depicted as lines connecting two modelling elements with an optional open
headed arrowhead on one end of the line indicating the direction of the initial invocation of the
relationship. Generalizations are depicted as a close-headed arrow with the arrow pointing
towards the more general modelling element.
1. Indicate an Association between an Actor and a Use Case If the Actor Appears Within the
Use Case Logic
2. Avoid Arrowheads on Actor-Use Case Relationships
3. Apply <> When You Know Exactly When to Invoke the Use Case
4. Apply <> When A Use Case May Be Invoked Across Several Use Case Steps
5. Introduce <> associations sparingly
6. Generalize Use Cases When a Single Condition Results in Significantly New Business
Logic
7. Do Not Apply <>, <>, or <>
8. Avoid More Than Two Levels of Use Case Associations
9. Place an Included Use Case to The Right of The Invoking Use Case
10. Place an Extending Use Case below the Parent Use Case
11. Apply the ―Is Like‖ Rule to Use Case Generalization
12. Place an Inheriting Use Case Below the Base Use Case
13. Apply the ―Is Like‖ Rule to Actor Inheritance
14. Place an Inheriting Actor Below the Parent Actor

Symbol

4. System Boundary Boxes

The rectangle around the use cases is called the system boundary box and as the name suggests
it indicates the scope of your system – the use cases inside the rectangle represent the
functionality that you intend to implement.
1. Indicate Release Scope with a System Boundary Box.
2. Avoid Meaningless System Boundary Boxes

Creating Use Case Diagrams

We start by identifying as many actors as possible. You should ask how the actors interact with
the system to identify an initial set of use cases. Then, on the diagram, you connect the actors
with the use cases with which they are involved. If actor supplies information, initiates the use
case, or receives any information as a result of the use case, then there should be an association
between them.
Output:

Use Case Diagram for Bank Management System

 EXPERIMENT NO. - 3
AIM: Draw the activity diagram of any software system using Star UML
tool.
Procedure:
Activity diagram is another important diagram in UML to describe the dynamic aspects of the
system.
Activity diagram is basically a flowchart to represent the flow from one activity to another
activity. The activity can be described as an operation of the system.
The control flow is drawn from one operation to another. This flow can be sequential, branched,
or concurrent. Activity diagrams deal with all type of flow control by using different elements
such as fork, join etc.
Purpose/Benefits of Activity Diagrams
It captures the dynamic behavior of the system. Other four diagrams are used to show the
message flow from one object to another but activity diagram is used to show message flow
from one activity to another. Activity diagram is sometimes considered as the flowchart.
Although the diagrams look like a flowchart, they are not. It shows different flows such as
parallel, branched, concurrent, and single. The purpose/benefits of an activity diagram are:
i. Draw the activity flow of a system.
ii. Describe the parallel, branched and concurrent flow of the system.
iii. Demonstrate the logic of an algorithm.
iv. Describe the steps performed in a UML use case.
v. Model software architecture elements, such as method, function, and operation.

Code/Method/Notations and Symbols used in making Activity Diagram:

Initial State or Start Point

A small filled circle followed by an arrow represents the initial action state or the start point
for any activity diagram. For activity diagram using swim lanes, make sure the start point is
placed in the top left corner of the first column.
Activity or Action State
An action state represents the non-interruptible action of objects. You can draw an action state
in Smart Draw using a rectangle with rounded corners.

Action Flow: Action flows, also called edges and paths, illustrate the transitions from one
action state to another. They are usually drawn with an arrowed line.

Object Flow
Object flow refers to the creation and modification of objects by activities. An object flow
arrow from an action to an object means that the action creates or influences the object. An
object flow arrow from an object to an action indicates that the action state uses the object.

Decisions and Branching

A diamond represents a decision with alternate paths. When an activity requires a decision
prior to moving on to the next activity, add a diamond between the two activities. The outgoing
alternates should be labelled with a condition or guard expression. You can also label one of
the paths "else."
Guards

In UML, guards are a statement written next to a decision diamond that must be
true before moving next to the next activity. These are not essential, but are useful
when a specific answer, such as "Yes, three labels are printed," is needed before
moving forward.

Time Event

This refers to an event that stops the flow for a time; an hourglass depicts it.

Merge Event

A merge event brings together multiple flows that are not concurrent.
Output:

Activity Diagram of Bank Management System

 EXPERIMENT NO. -4
AIM: Identify the classes. Classify them as weak and strong classes and draw the
class diagram.
Procedure:

Class diagram in the Unified Modeling Language (UML) is a type of static structure diagram
that describes the structure of a system by showing the system's classes, their attributes,
operations (or methods), and the relationships among objects.

The class diagram is the main building block of object-oriented modeling. It is used for general
modeling of the systematic of the application, and for detailed modeling translating the models
into programming code. Class diagrams can also be used for data modeling. The classes in a
class diagram represent both the main elements, interactions in the application, and the classes
to be programmed.

Code/Method/Notations and Symbols used in making Class Diagram:

In the diagram, classes are represented with boxes that contain three compartments:

i. The top compartment contains the name of the class. It is printed in bold and cantered, and

the first letter is capitalized. ii. The middle compartment contains the attributes of the class.
They are left-aligned and the first letter is lowercase.
iii. The bottom compartment contains the operations the class can execute. They are also left-aligned

and the first letter is lowercase.

20
Visibility

To specify the visibility of a class member (i.e. any attribute or method), these notations must be
placed before the member's name:

+ Public

- Private

# Protected

Derived (can be combined with one of the

/
others)

~ Package

* Random

Relationships:

UML relations notation

21
A relationship is a general term covering the specific types of logical connections found on class and
object diagrams. UML defines the following relationships:
Class Diagram for Bank Management System

22
 EXPERIMENT NO. -5
AIM: Draw the Sequence Diagram.
Procedure:
UML sequence diagrams model the flow of logic within the system in a visual manner, enabling
the user both to document and validate the logic, and are commonly used for both analysis and
design purposes. Sequence diagrams are the most popular UML artifact for dynamic modelling,
which focuses on identifying the behavior within your system. Sequence diagrams, along with
class diagrams and physical data models are the most important design- level models for
modern application development
Sequence diagrams are typically used to model:
1. Usage scenarios. A usage scenario is a description of a potential way the system is
used. The logic of a usage scenario may be part of a use case, perhaps an alternate course. It
may also be one entire pass through a use case, such as the logic described by the basic course
of action or a portion of the basic course of action, plus one or more alternate scenarios. The
logic of a usage scenario may also be a pass through the logic contained in several use cases.
For example, a student enrols in the university, and then immediately enrolls in three seminars.
2. The logic of methods. Sequence diagrams can be used to explore the logic of a
complex operation, function, or procedure. One way to think of sequence diagrams, particularly
highly detailed diagrams, is as visual object code.
3. The logic of services. A service is effectively a high-level method, often one that can
be invoked by a wide variety of clients. This includes web-services as well as business
transactions implemented by a variety of technologies such as CICS/COBOL or CORBA-
compliant object request brokers (ORBs).
Fig. shows the logic for how to enroll in a seminar. One should often develop a system-level
sequence diagram to help both visualize and validate the logic of a usage scenario. It also helps
to identify significant methods/services, such as checking to see if the applicant already exists
as a student, which the system must support.

23
The dashed lines hanging from the boxes are called object lifelines, representing the life span
of the object during the scenario being modeled. The long, thin boxes on the lifelines are
activation boxes, also called method-invocation boxes, which indicate processing is being
performed by the target object/class to fulfill a message.
Sequence Diagram Notation
Actor a type of role played by an entity that interacts with the subject (e.g., by exchanging
signals and data)
External to the subject (i.e., in the sense that an instance of an actor is not a part of the instance
of its corresponding subject).
Represent roles played by human users, external hardware, or other subjects.
Note that:
An actor does not necessarily represent a specific physical entity but merely a particular role
of some entity
A person may play the role of several different actors and, conversely, a given actor may be
played by multiple different person.

Lifeline
A lifeline represents an individual participant in the Interaction.

24
Activations
A thin rectangle on a lifeline) represents the period during which an element is performing an
operation.
The top and the bottom of the of the rectangle are aligned with the initiation and the completion
time respectively

Call Message
A message defines a particular communication between Lifelines of an Interaction.
Call message is a kind of message that represents an invocation of operation of target lifeline.

Return Message
A message defines a particular communication between Lifelines of an Interaction.

25
26
Duration Message
A message defines a particular communication between Lifelines of an Interaction.
Duration message shows the distance between two time instants for a message invocation.

How to Draw Sequence Diagrams

Sequence diagramming really is visual coding, even when you are modeling a usage scenario via
a system-level sequence diagram.
While creating a sequence diagram ,start by identifying the scope of what you are trying to
model. You should typically tackle small usage scenarios at the system level or a single
method/service at the detailed object level.
You should then work through the logic with at least one more person, laying out classifiers
across the top as you need them. . The heart of the diagram is in the messages, which you add
to the diagram one at a time as you work through the logic. You should rarely indicate return
values, instead you should give messages intelligent names which often make it clear what is
being returned.
It is interesting to note that as you sequence diagram you will identify new responsibilities for
classes and objects, and, sometimes, even new classes. The implication is that you may want
to update your class model appropriately, agile modelers will follow the practice Create Several
Models in Parallel, something that CASE tools will do automatically. Remember, each message
sent to a class invokes a static method/operation on that class each message sent to an object
invokes an operation on that object.
Regarding style issues for sequence diagramming, prefer drawing messages going from left-
to-right and return values from right-to-left, although that doesn‘t always work with complex
objects/classes. Justify the label on messages and return values, so they are closest to the
arrowhead. Also prefer to layer the sequence diagrams: from left-to-right. indicate the actors,
then the controller class(es), and then the user interface class(es), and, finally, the business
class(es). During design, you probably need to add system and persistence classes, which you
should usually put on the right-most side of sequence diagrams. Laying your sequence diagrams
in this manner often makes them easier to read and also makes it easier to find layering logic
problems, such as user interface classes directly accessing persistence.
Sequence Diagram for Bank Management System
 EXPERIMENT NO. - 6
AIM: Draw the Collaboration Diagram.
Procedure:
Collaboration diagrams are also relatively easy to draw. They show the relationship between
objects and the order of messages passed between them. The objects are listed as icons and
arrows indicate the messages being passed between them. The numbers next to the messages
are called sequence numbers. As the name suggests, they show the sequence of the messages
as they are passed between the objects. There are many acceptable sequence numbering
schemes in UML. A simple 1, 2, 3... format can be used, as the example below shows, or for
more detailed and complex diagrams a 1, 1.1 ,1.2, 1.2.1... scheme can be used.

The example below shows a simple collaboration diagram for the placing an order use case.
This time the names of the objects appear after the colon, such as: Order Entry Window
following the objectName:className naming convention. This time the class name is shown
to demonstrate that all of objects of that class will behave the same way.

Notations of Collaboration Diagram

Objects

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

Object_name : class_name

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

 Each object in the collaboration is named and has its class specified
Not all classes need to appear
There may be more than one object of a class
An object’s class can be unspecified. Normally you create a collaboration diagram with
objects first and specify their classes later.
The objects can be unnamed, but you should name them if you want to discriminate
different objects of the same class.
Actors
Normally an actor instance occurs in the collaboration diagram, as the invoker of the
interaction. If you have several actor instances in the same diagram, try keeping them in the
periphery of the diagram.
Each Actor is named and has a role
One actor will be the initiator of the use case

Links

Links connect objects and actors and are instances of associations and each link

Corresponds to an association in the class diagram Links

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

Messages
A message is a communication between objects that conveys information with the expectation that
activity will ensue. In collaboration diagrams, a message is shown as a labelled arrow
placed near a link. The message is directed from sender to receiver The receiver must
understand the message
The association must be navigable in that direction Steps
for Creating Collaboration Diagrams
Identify behaviour whose realization and implementation is specified
 Identify the structural elements (class roles, objects, subsystems) necessary to carry out
the functionality of the collaboration
Decide on the context of interaction: system, subsystem, use case and operation
Model structural relationships between those elements to produce a diagram showing the
context of the interaction
Consider the alternative scenarios that may be required
Draw instance level collaboration diagrams, if required.
Optionally draw a specification level collaboration diagram to summarize the alternative
scenarios in the instance level sequence diagrams

Collaboration Diagram for Bank Management System

 EXPERIMENT NO. - 7
AIM: -To draw a sample State Chart Diagram for real project or system

Procedure:
Hardware Requirements
Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, colored monitor.
THEORY
State Chart Diagram: State chart diagrams model the dynamic behavior of individual classes
or any other kind of object. They show the sequences of states that an object goes through, the
events that cause a transition from one state to another and the actions that result from a state
change. A State chart diagram describes a state machine. State machine can be defined as a
machine which defines different states of an object and these states are controlled by external
or internal events. State chart diagrams are also used for forward and reverse engineering of a
system. However, the main purpose is to model the reactive system.

Following are the main purposes of using State chart diagrams −

To model the dynamic aspect of a system.

To model the life time of a reactive system.

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

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

Basic components of a state chart diagram – States

States represent situations during the life of an object. You can easily illustrate a state in Smart
Draw by using a rectangle with rounded corners.

Transition
A solid arrow represents the path between different states of an object. Label the transition
with the event that triggered it and the action that results from it. A state can have a transition that
points back to itself.

Initial State
A filled circle followed by an arrow represents the object's initial state.

Final State an arrow pointing to a filled circle nested inside another circle represents the
object's final state.

Synchronization and Splitting of Control

A short heavy bar with two transitions entering it represents a synchronization of control. The
first bar is often called a fork where a single transition splits into concurrent multiple transitions.
The second bar is called a join, where the concurrent transitions reduce back to one.
Example of state chart of Bank management system
 EXPERIMENT NO. - 8
AIM :- To draw a sample Component Diagram for real project or system

HARDWARE REQUIREMENTS

Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse, colored monitor.

THEORY

Component diagrams are used to visualize the organization and relationships among components
in a system. These diagrams are also used to make executable systems. Component diagram is a
special kind of diagram in UML. The purpose is also different from all other diagrams discussed
so far. It does not describe the functionality of the system but it describes the components used
to make those functionalities.
Thus from that point of view, component diagrams are used to visualize the physical components
in a system. These components are libraries, packages, files, etc. Component diagrams can also
be described as a static implementation view of a system. Static implementation represents the
organization of the components at a particular moment. A single component diagram cannot
represent the entire system but a collection of diagrams is used to represent the whole.
The purpose of the component diagram can be summarized as –
Visualize the components of a system.
Construct executable by using forward and reverse engineering.

Describe the organization and relationships of the components.

Component diagrams are used to describe the physical artefacts of a system. This artefact
includes files, executable, libraries, etc.

The purpose of this diagram is different. Component diagrams are used during the
implementation phase of an application. However, it is prepared well in advance to visualize the
implementation details.
Initially, the system is designed using different UML diagrams and then when the artifacts are

ready, component diagrams are used to get an idea of the implementation.

This diagram is very important as without it the application cannot be implemented efficiently.
A well-prepared component diagram is also important for other aspects such as application
performance, maintenance, etc.
Before drawing a component diagram, the following artifacts are to be identified clearly −
 Files used in the system.
Libraries and other artifacts relevant to the application.
Relationships among the artifacts.

Component

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

Interface

An interface (small circle or semi-circle on a stick) describes a group of operations used

(required) or created (provided) by components. A full circle represents an interface created or
provided by the component. A semi-circle represents a required interface, like a person's input.

Dependencies
Draw dependencies among components using dashed arrows.

Port

Ports are represented using a square along the edge of the system or a component. A port is often
used to help expose required and provided interfaces of a component.
Example of Bank Management System
 EXPERIMENT NO. - 9
AIM: Perform forward engineering in java. (Model to code conversion).
Procedure:

About:

Forward engineering is the process of building from a high-level model or concept to build in
complexities and lower-level details. This type of engineering has different principles in various
software and database processes. Generally, forward engineering is important in IT because it
represents the 'normal’ development process. For example, building from a model into an
implementation language. This will often result in loss of semantics, if models are more
semantically detailed, or levels of abstraction Code/Method:
Click the “Tools->Java” menu on the main menu and select “Generate Code”

Select your module from the dialog (may be Model1 here) and click "Next". To generate stub
code for all classes of your module or icon, select “Select All” and press “Next”. Select a valid
output directory, "Next".
In the "Options Setup", be sure to check both "Generate the Documentation by JavaDoc" and
"Generate empty JavaDoc". All other checkboxes should be unchecked. Then press "Next".

In "Options Setup", be sure to check " Generate the Documentation by JavaDoc", "Generate
empty JavaDoc", all other checkboxes are unchecked, "Next"
Output:
Consumer.java
/**
* Represents a Consumer who can apply for Credit.
*/
public class Consumer extends Person {

public Consumer() {
super();
}
}
Mortgage.java
/**
* Represents a Mortgage which acts as a guarantee for Credit.
*/
public class Mortgage {

private Credit credit;

public Mortgage() {
}

public Credit getCredit() {

return credit;
}

public void setCredit(Credit credit) {

 this.credit = credit;
}
}
Goods.java
import java.util.ArrayList;
import java.util.List;

/**
* Represents Goods with value and an owner (Person).
*/
public class Goods {

private float value;

private List<Credit> guarantees = new ArrayList<>();
private Person owner;

public Goods() {
}

public float getValue() {

return value;
}

public void setValue(float value) {

this.value = value;
}

public List<Credit> getGuarantees() {

return guarantees;
}

public void addGuarantee(Credit credit) {

 this.guarantees.add(credit);
}

public Person getOwner() {

return owner;
}

public void setOwner(Person owner) {

this.owner = owner;
}
}
Credit.java
import java.util.ArrayList;
import java.util.List;

/**
* Represents a Credit taken by a Person, provided by a Bank.
*/
public class Credit {

private float sum;

private float monthlyPayment;
private String startDate;
private String endDate;

private Person debtor;

private Bank provider;
private List<Goods> guarantees = new ArrayList<>();

public Credit() {
}
public void approve() {
// Approval logic
}

// Getters and Setters

public float getSum() {
return sum;
}

public void setSum(float sum) {

this.sum = sum;
}

public float getMonthlyPayment() {

return monthlyPayment;
}

public void setMonthlyPayment(float monthlyPayment) {

this.monthlyPayment = monthlyPayment;
}

public String getStartDate() {

return startDate;
}

public void setStartDate(String startDate) {

this.startDate = startDate;
}

public String getEndDate() {

return endDate;
}
 public void setEndDate(String endDate) {
this.endDate = endDate;
}

public Person getDebtor() {

return debtor;
}

public void setDebtor(Person debtor) {

this.debtor = debtor;
}

public Bank getProvider() {

return provider;
}

public void setProvider(Bank provider) {

this.provider = provider;
}

public List<Goods> getGuarantees() {

return guarantees;
}

public void addGuarantee(Goods goods) {

this.guarantees.add(goods);
}
}
Person.java
import java.util.ArrayList;
import java.util.List;
/**
* Represents a Person who holds Accounts and can apply for Credits.
*/
public class Person {

private int id;

private String name;
private float netSalary;
private List<Account> accounts = new ArrayList<>();

public Person() {
}

public void applyForCredit() {

// Application logic
}

// Getters and Setters

public int getId() {
return id;
}

public void setId(int id) {

this.id = id;
}

public String getName() {

return name;
}

public void setName(String name) {

 this.name = name;
}

public float getNetSalary() {

return netSalary;
}

public void setNetSalary(float netSalary) {

this.netSalary = netSalary;
}

public List<Account> getAccounts() {

return accounts;
}

public void addAccount(Account account) {

this.accounts.add(account);
}
}
Account.java
/**
* Represents an Account with balance and minimum required amount.
*/
public class Account {

private String acNumber;

private float balance;
private int minAmount;

public Account() {
}
public void create() {
// Creation logic
}

public void deposit(float amount) {

if (amount > 0) {
this.balance += amount;
}
}

public void withdraw(float amount) {

if (amount > 0 && (balance - amount) >= minAmount) {
this.balance -= amount;
}
}

// Getters and Setters

public String getAcNumber() {
return acNumber;
}

public void setAcNumber(String acNumber) {

this.acNumber = acNumber;
}

public float getBalance() {

return balance;
}

public void setBalance(float balance) {

this.balance = balance;
}
 public int getMinAmount() {
return minAmount;
}

public void setMinAmount(int minAmount) {

this.minAmount = minAmount;
}
}
Bank.java
import java.util.ArrayList;
import java.util.List;

/**
* Represents a Bank providing Credits and Accounts.
*/
public class Bank {

private String name;

private List<Credit> credits = new ArrayList<>();
private List<Account> accounts = new ArrayList<>();

public Bank() {
}

// Getters and Setters

public String getName() {
return name;
}

public void setName(String name) {

this.name = name;
 }

public List<Credit> getCredits() {

return credits;
}

public void addCredit(Credit credit) {

this.credits.add(credit);
}

public List<Account> getAccounts() {

return accounts;
}

public void addAccount(Account account) {

this.accounts.add(account);
}
}
 EXPERIMENT NO. - 10
AIM: To Perform reverse engineering in java. (Code to Model conversion)
Procedure:

About:

StarUML can also create a class diagram from existing Java code. This is called "reverse
engineering". When you want to generate a chart from existing code, or you modify the code
generated by SU, and want to reflect it in the chart. The reverse engineering feature is very
useful. The process of repeating work through a text editor such as a chart or DrJava is called
"round-trip engineering". This is also a basic process in object-oriented Code/Method:
Go to the main menu bar and select “Tools/Java/Reverse Engineer...” to reverse the existing
code. Select the directory where the Java code is located and click the "Add" or "Add All"
button to include them in the reverse engineering process, then click "Next". Select the module
you want to add the class to, which may be "Model1" and then "Next". In the Option Setup:
Confirm that "public", "package", "protected" and "private" are selected (this is the default
setting). Similarly, by default, the radio button "Create the field to the Attribute" is also selected.
Don't check the "Create Overview Diagram" box unless you want SU to create something else,
such as a chart with a bad layout that contains all the classes. When you have checked the
options, click on “Run”. SU will now import the classes in the selected files into your model.
Click "Finish" to exit the dialog when it is complete. Su now import the class, in the selected
file to the product model you need, click "Finish" When you exit the dialog, it is complete.
Output:
 EXPERIMENT NO. - 11
AIM: Draw a Deployment Diagram.
Procedure:

Deployment Diagram is a type of diagram that specifies the physical hardware on which the
software system will execute. It also determines how the software is deployed on the underlying
hardware. It maps software pieces of a system to the device that are going to execute it.

The deployment diagram maps the software architecture created in design to the physical
system architecture that executes it. In distributed systems, it models the distribution of the
software across the physical nodes.

The software systems are manifested using various artifacts, and then they are mapped to the
execution environment that is going to execute the software such as nodes. Many nodes are
involved in the deployment diagram; hence, the relation between them is represented using
communication paths.

There are two forms of a deployment diagram.

Descriptor form

• It contains nodes, the relationship between nodes and artifacts.

Instance form
• It contains node instance, the relationship between node instances and
artifact instance. An underlined name represents node instances.

A deployment diagram consists of the following notations:

1. A node

2. A component

3. An artifact

4. An interface
The steps below outline the major steps to take in creating a UML Deployment Diagram.

1. Decide on the purpose of the diagram

2. Add nodes to the diagram

3. Add communication associations to the diagram

4. Add other elements to the diagram, such as components or active objects, if required

5. Add dependencies between components and objects, if required

Output: