IMS ENGINEERING COLLEGE

SOFTWARE ENGINEERING LAB

(KCS-651)

B.TECH – III YEAR

(EVEN SEM 2022-2023)

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 coupled with incorporating values and developing engineering acumen for
innovations and leadership skills for the betterment of society.

MISSION OF THE INSTITUTE

 To promote academic excellence by continuous learning in core and emerging

Engineering areas using innovative teaching and learning methodologies.

 To inculcate values and ethics among the learners.

 To promote industry interactions and produce young entrepreneurs.

 To create a conducive learning and research environment for life-long learning to

develop the students as technology leaders and entrepreneurs for addressing societal
needs.

VISION OF THE DEPARTMENT

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

MISSION OF THE DEPARTMENT

M1: To provide quality undergraduate education in both the theoretical & applied
foundations of Computer Science Engineering.

M2: Conduct research to advance the state of the art in Computer Science & Engineering
and integrate the research results as innovations.

M3: To inculcate team building skills and promote life-long learning with a high societal
and ethical values.

2
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

PROGRAMME EDUCATIONAL OBJECTIVES (PEOs)

Graduate Will:

PEO1: Possess knowledge to enable continued professional development.

PEO2: Engage in life-long learning to foster personal & organization

growth.

PEO3: Work productively as successful professionals in diverse career

paths.

PEO4: Effectively communicate ideas to promote collaboration in accordance with societal

standards & ethical practices.

PROGRAMME SPECIFIC OUTCOME (PSOs)

PSO1: To apply standard software engineering practices & strategies in real-time software
project development.

PSO2: To apply latest programming languages in creating innovative career opportunitie

3
 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,K3
C319.1 Identify ambiguities, inconsistencies and incompleteness from a requirements
specification and state functional and non-functional requirement
K2,K3
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

4
 DETAILS OF THE EXPERIMENTS CONDUCTED

S.No TITLE OF THE EXPERIMENT DATE OF FACULTY

SUBMISSION SIGNATURE

1 Prepare a SRS document in line with the IEEE recommended

standards.

2 Draw the use case diagram and specify the role of each of the
actors. Also state the precondition, post condition and function of
each use
case.

3 Draw the activity diagram.

4 Identify the classes. Classify them as weak and strong classes and
draw the class diagram.

5 Draw the sequence diagram for any two scenarios.

6 Draw the collaboration diagram.

7 Draw the state chart diagram.

8 Draw the component diagram.

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

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

11 Draw the deployment diagram.

12 Project on Book Bank Management.

13 Project on ATM Machine

5
 EXPERIMENT NO. - 1

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

standards

Procedure:
Project Title: HOSPITAL MANAGEMENT SYSTEM
This page contains SRS documentation for Hospital Management System. The SRS is
produced at the culmination of the analysis task. The function and performance allocated to
software as part of the system engineering and refined by establishing a complete information
description, a detailed functional description, a representation of system behaviour, indication
of performance requirements and design constrains, appropriate validation criteria and the
other information related to requirements.
The SRS is technical specification of requirement of Hospital Management system. This
specification describes what the proposed system should do without describing how it will do
it. It also describes complete external behaviour of proposed system.

Purpose: -
The main purpose of our system is to make hospital task easy and is to develop software that
replaces the manual hospital system into automated hospital management system. This
document serves as the unambiguous guide for the developers of this software system.

Scope: -
The document only covers the requirement specification for the hospital management system.
This document does not provide any references to the other component of the hospital
management system. All the external interfaces and the dependencies are also identified in
this document.

Feasibility Study: -
The overall scope of the feasibility study was to provide sufficient information to allow a
decision to be made as to whether the hospital management system project should proceed
and so, its relative priority in the context of the other existing hospital management system.
The feasibility study of this project had undergone through various steps which as describe as
Under.

6
a) Identify the origin of the information at different level.
b) Identify the expectation of user from computerized system.
c) Analyse the drawback of existing system.
Overview: -
Hospital Management System is a process of implementing all the activities of the hospital in
a computerized automated way to fasten the performance. This project is to maintain the
patient details, lab reports and to calculate the bill of the patient. You can also manually edit
any patient details and issue bill receipt to patient within few seconds.

Product perspective: -
This project gives the procedural approach how a patient gets treatment, details about date of
treatment and finally depending on different criteria like room allocated, lab reports,
treatment and medicine taken, how billing is calculated etc. During billing health card facility
is also considered.

Product Function: -
The data represented in hospital management application will perform the following major
Function:
• Patient Details: – It includes inpatient and outpatient details.

• Lab reports

• Billing Details

This software will help to calculate the bill much quicker and simpler way. This enables the
organization to keep the information in efficient and systematic way.
User characteristics: -
This software is developed such that total appearance of the product to make it more user
friendly. The operator will be provided with login id and password. General users with basic
computer skills can use this software.
General Constraints: -
Any update regarding the patient information from the hospital is to be recorded to have
updated and correct values.
Functional Requirements: -
• Administration module

7
• Patient module

• Inpatient module

• Outpatient module

• Lab module

• Billing module

Performance Requirements: -
The capability of the computer depends on the performance of the software. The software can
take any number of inputs provided the database size is large enough. This would depend on
the available memory space.
Design constraints: -
This will help the doctors or users to view the records of the patients immediately whenever
necessary. They can also calculate the bill of the particular patients. This software also has
the ability to add, update and delete the record whenever needed. This project will help to
smoother the process of the hospital activities.

8
 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

9
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

10
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.
Some Sample Use Case Diagrams are given below for illustration purpose

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

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

14
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 Library Management System

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

16
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

17
A relationship is a general term covering the specific types of logical connections found on
class and object diagrams. UML defines the following relationships:

Output

Class Diagram of Library Management System:-

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

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

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

21
 Return message is a kind of message that represents the pass of information back to
the caller of a corresponded former message.

Self-Message
A message defines a particular communication between Lifelines of an Interaction.
Self-message is a kind of message that represents the invocation of message of the
same lifeline.

Create Message
A message defines a particular communication between Lifelines of an Interaction.
Create message is a kind of message that represents the instantiation of (target)
lifeline.

Destroy Message
A message defines a particular communication between Lifelines of an Interaction.
Destroy message is a kind of message that represents the request of destroying the
lifecycle of target lifeline.

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

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

HOSPITAL MANAGEMENT SYSYTEM: (Sequence Diagram)

24
 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:

25
 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

26
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

27
 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

28
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 library management system

29
30
 EXPERIMENT NO. - 8
AIM :- To draw a sample Component 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
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.

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

32
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 ATM Machine

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

34
In "Options Setup", be sure to check " Generate the Documentation by JavaDoc", "Generate
empty JavaDoc", all other checkboxes are unchecked, "Next"
Output:
Now StarUML will generate the code from your diagram and click "Finish" to exit the dialog.
Now you can edit the generated code to add an app.

35
 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:
SU will add imported classes to your module, but not your chart. To add it to your diagram,
simply drag them from the Model Explorer.

36
 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

37
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

38
 EXPERIMENT NO. - 12
AIM : Project on Book Bank Management.

Use_Case Diagram:
The book bank use cases are:
1. book_issue

2. book_return

3. book_order

4. book_entry

5. search book_details

Actors Involved:
1. Student
2. Librarian
3. Vendor
Usecase Name : Search Book_Details
The librarian initiates this use case when any member returns or request the book and checking if the
book is available.
Precondition: The librarian should enter all Book details.
Normal Flow: Build message for librarian who search the book.
Post Condition: Send message to respective member who reserved the book.

Usecase Name : Book_ Issue

Initiated by librarian when any member wants to borrow the desired book. If the book is available,
the book is issued.
Precondition: Member should be valid member of library.
Normal Flow: Selected book will be issued to the member.
Alternative Flow: If book is not available then reserved book use case should be initiate. Post
Condition: Update the catalogue.

39
Usecase Name : Book_Order

Initiated by librarian when the requested book is not available in the library at that moment. The book
is reserved for the future and issued to the person when it is available.
Precondition: Initiated only when book is not available.
Normal Flow: It reserved the book if requested.
Post Condition : Mention the entry in catalogue for reservation.

Usecase Name : Book_Return

Invoked by the librarian when a member returns the book.
Precondition: Member should be valid member of library.
Normal Flow: Librarian enters bookid and system checks for return date of the book. Alternative
Flow: System checks for return date and if it returned late fine message will be displayed.

Post Condition: Check the status of reservation.

Usecase Name : Book_Entry

The purchase book use-case when new books invoke it or magazines are added to the library.
Precondition: Not available or more copies are required.
Normal Flow: Enter bookid, author information, publication information, purchased date, prize
and number of copies.
Post Condition: Update the information in catalogue.

40
Figure 1. Usecase diagram for Book Bank System

Activity Diagram:

Activity diagrams are graphical representations of workflows of stepwise activities and actions with
support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams
can be used to describe the business and operational step-by-step workflows of components in a
system. An activity diagram shows the overall flow of control. An activity is shown as an rounded
box containing the name of the operation.
This activity diagram describes the behavior of the system.

41
Figure 2. Activity Diagram for Book Bank System [borrow book]

42
Figure 3. Activity Diagram for Book Bank System [order book]

Figure 4. Activity Diagram for Book Bank System [Return book]

43
Sequence Diagram:
A sequence diagram represents the sequence and interactions of a given USE-CASE or scenario.
Sequence diagrams can capture most of the information about the system. Most object to object
interactions and operations are considered events and events include signals, inputs, decisions, interrupts,
transitions and actions to or from users or external devices.

Figure 5. Sequence Diagram For Book Issue & Return

44
 Figure 6. Collaboration Diagram For Book Issue & Return

Class Diagram:

The class diagram, also referred to as object modeling is the main static analysis diagram. The main
task of object modeling is to graphically show what each object will do in the problem domain. The
problem domain describes the structure and the relationships among objects.

45
 The ATM system class diagram consists of four classes:

1. Student

2. Book

3. Issue

4. Return

5. Vendor

6. Details

1) Student:

It consists of twelve attributes and three operations. The attributes are enrollno, name, DOB,
fathername, address, dept name, batch and book limits. The operations of this class are addStInfo(),
deleteStInfo(), modifyStInfo().

2) Book:

It consists of ten attributes and four operations. This class is used to keep book information such as
author, title, vendor, price, etc

2) Issue:

It consists of eight attributes and two operations to maintain issue details such as, issue date, accno of
issued book, name of the student who borrowed book.

3) Return:

It consists of eight attributes and two operations to maintain issue details such as, issue date, accno of
issued book, name of the student who borrowed book.

4) Students:

The attributes of this class are name, dept ,year ,bcode no The operation is display students().

5) Detail:
The attributes of this class are book name, author, bcode no The operations are delete details().
46
 Figure 7. Class Diagram For Book Bank System

State Chart Diagram

It consists of state, events and activities. State diagrams are a familiar technique to describe the
behavior of a system. They describe all of the possible states that a particular object can get into and
how the object's state changes as a result of events that reach the object.

47
 Figure 8. State Chart Diagram for Book Bank System

Deployment Diagram
Deployment diagrams are used to visualize the topology of the physical components of a system
wherethe software components are deployed.

Figure 9: Deployment Diagram for Book Bank System

48
 EXPERIMENT NO. - 13

AIM : Project on ATM Machine

In automated teller machine (ATM) or the automatic banking machine (ABM) is a banking subsystem
(subject) that provides bank customers with access to financial transactions in a public space without the
need for a cashier, clerk, or bank teller.
Customer (actor) uses bank ATM to Check Balances of his/her bank accounts, Deposit Funds, Withdraw
Cash and/or Transfer Funds (use cases). ATM Technician provides Maintenance and Repairs. All these
use cases also involve Bank actor whether it is related to customer transactions or to the ATM servicing.

Figure 1: Use Case Diagram for ATM

State Chart Diagram

ATM is initially turned off. After the power is turned on, ATM performs startup action and enters Self Test state. If
the test fails, ATM goes into Out of Service state, otherwise49
there is triggerless transition to the Idle state. In this
state ATM waits for customer interaction.
The ATM state changes from Idle to Serving Customer when the customer inserts banking or credit card in the
ATM's card reader. On entering the Serving Customer state, the entry action readCard is performed. Note, that
transition from Serving Customer state back to the Idle state could be triggered by cancel event as the customer
could cancel transaction at any time.

Figure 2 state machine UML diagram - Bank ATM

Serving Customer state is a composite state with sequential substates Customer Authentication, Selecting,
Transaction and Transaction. Customer authentication and Transaction are composite states by themselves
which is shown with hidden decomposition indicator icon. Serving Customer state has triggerless
transition back to the Idle state after transaction is finished. The state also has exit action eject Card which
releases customer's card on leaving the state, no matter what caused the transition out of the state.

Class diagram

The purpose of savings account is to allow us to save money. Account holder can make some limited
number of deposits and withdrawals per month, while account provides no checks. Bank usually pays
interest rate that is higher than that of a checking account,
50 but lower than a money market account or CDs.
 Figure 3 Class Diagram - Bank ATM

A checking account is a bank account that uses checks as a way to withdraw or transfer money from the
account - pay bills, buy items, transfer or loan money. Usually banks allow account holders to make
withdrawals and deposits through automatic teller machines (ATM). Basic checking accounts, sometimes
called No frills accounts, offer a limited set of services. They usually do not pay interest, have lower
required minimum balance, may restrict writing and/or depositing more than a certain number of checks
per month. Checking accounts with interest have higher required minimum balance but pay interest
(based on the average balance maintained), and usually offer a better services, like allowing to write
unlimited number of checks. These accounts are sometimes referred to as negotiable order of withdrawal
(NOW) accounts.
Money market account or money market deposit account (MMDA) pays interest at a higher rate than the
rate paid on savings or checking accounts with interest. Market accounts usually require a higher
minimum balance for the account to start earning interest, as compared to checking or savings account.
Fund withdrawals allowed per month are very limited.
Certificates of deposit (CDs) also known as time deposits are bank accounts that require the account
holder to make a relatively large deposit and leave funds in the account for some agreed amount of time,
usually several months or years. There is a penalty for 51 early withdrawal of funds. Because of these
restrictions, the interest paid on a CD is usually higher than the interest paid with other types of bank
accounts.
Two special cases shown on this UML diagram are Children's Savings Account and Health Savings
Account (HSA). These two accounts are both Personal Accounts as well as Savings Accounts. It is
shown as multiple inheritance.
Children's Savings Account is a personal savings account that allows children to learn about money
savings, interest rates and see what this means in relation to their savings. Some banks require some
monthly fee or minimum balance and could charge fees, if an account is inactive or there are too many
small deposits.
Health Savings Account (HSA) is a personal savings account that allows individuals covered by high-
deductible health plans to receive tax-preferred treatment of money saved for future medical expenses.

Activity Diagram

52

Figure 4 Activity Diagram - Bank ATM