Department of Computer Science &

Engineering
Affiliated to Dr. A.P.J. AKTU, Lucknow

Software Engineering Lab File

Subject Name : Software Engineering Lab File

Subject Code : KCS-651
Session : 2021 - 22 (Even Semester)
Under Supervision of: Dr. Suraj Malik

Submitted By:-
Name: Sushant Sharma
Roll No.: 1902900100167
Section: 3-CSC
 Index
Lab
Problem Statement Date Signature
No.
Formulate the problem statement for a software
1. solution required to manage the employee
records in an organization.
Write Software Requirements Specification
2. (SRS) document of the proposed Employee
Management System.
Practical exposure to the different elements of
3.
StarUML’s User Interface.
Draw a use case diagram of the proposed
4.
Employee Management System.
Draw an Entity Relationship (E-R) diagram of
5.
the proposed Employee Management System.
Draw a class diagram of College Automation
6.
System.
Draw a class diagram of the proposed
7.
Employee Management System.
Draw an activity diagram of the Ticket Vending
8.
Machine (TVM)
Draw an activity diagram of the proposed
9.
Employee Management System.
Draw a sequence diagram of the proposed
10.
Employee Management System.
Draw a component diagram of the Employee
11.
Management System
Objective: Code to model conversion. Take a
12. code in C++ and reverse engineer it into class
diagram (model).
Model to code conversion. Take a class diagram
13. (model) as base and forward engineer it into
code.
 Experiment No. 1

Objective: Formulate the problem statement for a software solution required to

manage the employee records in an organization.

Problem Statement
A software solution is required to manage the records of employees in an organization. Software
shall provide an option to add the details of the employee as soon as he/ she join the organization.
There must be an option to update the record of an employee if required. If the employee leaves
the organization then software must provide an option to remove the record of employee from the
active usage. If the details of an employee are required at any time for any purpose then software
should also give an option to view the record of an employee. Only the designated person in the
organization must have the right to add, update, remove and view the record of an employee. Along
with the designated person as mentioned above, every employee must be given an option to see
his/ her details at any time. Only the person designated and the employee must be allowed to use
the system as per the privileges described above.
 Software Requirements Specification (SRS) Document

2.1 Introduction
The software requirements specification (SRS) is a specification for a particular software
product, program, or set of programs that performs certain functions in a specific
environment. The SRS may be written by one or more representatives of the supplier,
one or more representatives of the acquirer, or by both.
It is important to consider the part that the SRS plays in the total project plan. The software
may contain essentially all the functionality of the project or it may be part of a larger
system. In the latter case typically there will be a requirement specification that will state
the interfaces between the system and its software portion, and will place external
performance and functionality requirements upon the software portion. Of course the SRS
should then agree with and expand upon these system requirements. The SRS indicates
the precedence and criticality of requirements. The SRS defines all of the required
capabilities of the specified software product to which it applies, as well as documenting
the conditions and constraints under which the software has to perform, and the intended
verification approaches for the requirements

2.2 SRS example outline

The specific requirements clause of the SRS should be organized such that a consensus
of the system stakeholders agrees that the organization method aids understanding of
the requirements. There is no one optimal organization for all systems. An example
outline for an SRS is in Figure 2.1
.
 Figure 2.2.1 — Example SRS Outline

2.3 Software requirements specification (SRS) document

This sub clause defines the normative content of the software requirements specification
(SRS). The project shall produce the following information item content in accordance
with the project's policies with respect to the software requirements specification
document. Organization of the information items in the document such as the order and
section structure may be selected in accordance with the project's documentation
policies.

2.3.1 Purpose
Delineate the purpose of the software to be specified.

2.3.2 Scope
Describe the scope of the software under consideration by
a) Identifying the software product(s) to be produced by name (e.g., Host DBMS, Report
Generator, etc.);
b) Explaining what the software product(s) will do;
c) Describing the application of the software being specified, including relevant benefits,
objectives, and goals;
d) Being consistent with similar statements in higher-level specifications (e.g., the system
requirements specification), if they exist.

2.3.3 Product perspective

Define the system's relationship to other related products.
If the product is an element of a larger system, then relate the requirements of that larger
system to the functionality of the product covered by the SRS.
If the product is an element of a larger system, then identify the interfaces between the
product covered by the SRS and the larger system of which the product is an element.
A block diagram showing the major elements of the larger system, interconnections, and
external interfaces can be helpful.

Describe how the software operates within the following constraints:

a) System interfaces;
b) User interfaces;
c) Hardware interfaces;
d) Software interfaces;
e) Communications interfaces;
f) Memory;
g) Operations;
h) Site adaptation requirements.

2.3.3.1 System interfaces

List each system interface and identify the functionality of the software to accomplish the
system requirement and the interface description to match the system.

2.3.3.2 User interfaces

Specify the following:
a) The logical characteristics of each interface between the software product and its
users. This includes those configuration characteristics (e.g., required screen formats,
page or window layouts, content of any reports or menus, or availability of programmable
function keys) necessary to accomplish the software requirements.
b) All the aspects of optimizing the interface with the person who uses, maintain, or
provides other support to the system. This may simply comprise a list of do's and don'ts
on how the system will appear to the user. One example may be a requirement for the
option of long or short error messages. This may also be specified in the Software System
Attributes under a section titled Ease of Use.
NOTE: A style guide for the user interface can provide consistent rules for organization,
coding, and interaction of the user with the system.

2.3.3.3 Hardware interfaces

Specify the logical characteristics of each interface between the software product and the
hardware elements of the system. This includes configuration characteristics (number of
ports, instruction sets, etc.). It also covers such matters as what devices are to be
supported, how they are to be supported, and protocols. For example, terminal support
may specify full-screen support as opposed to line-by-line support.

2.3.3.4 Software interfaces

Specify the use of other required software products (e.g., a data management system, an
operating system, or a mathematical package), and interfaces with other application
systems (e.g., the linkage between an accounts receivable system and a general ledger
system). For each required software product, specify:
a) Name;
b) Mnemonic;
c) Specification number;
d) Version number;
e) Source.

For each interface specify:

a) Discussion of the purpose of the interfacing software as related to this software product.
b) Definition of the interface in terms of message content and format. It is not necessary
to detail any well documented interface, but a reference to the document defining the
interface is required.

2.3.3.5 Communications interfaces

Specify the various interfaces to communications such as local network protocols.

2.3.3.6 Memory constraints

Specify any applicable characteristics and limits on primary and secondary memory.

2.3.3.7 Operations
Specify the normal and special operations required by the user such as
a) The various modes of operations in the user organization (e.g., user-initiated
operations);
b) Periods of interactive operations and periods of unattended operations;
c) Data processing support functions;
d) Backup and recovery operations.
NOTE This is sometimes specified as part of the User Interfaces section.

2.3.3.8 Site adaptation requirements

The site adaptation requirements include
a) Definition of the requirements for any data or initialization sequences that are specific
to a given site, mission, or operational mode (e.g., grid values, safety limits, etc.);
b) Specification of the site or mission-related features that should be modified to adapt
the software to a particular installation.

2.3.4 Product functions

Provide a summary of the major functions that the software will perform. For example, an
SRS for an accounting program may use this part to address customer account
maintenance, customer statement, and invoice preparation without mentioning the vast
amount of detail that each of those functions requires.
Sometimes the function summary that is necessary for this part can be taken directly from
the section of the higher-level specification (if one exists) that allocates particular
functions to the software product. Note that for the sake of clarity
a) The product functions should be organized in a way that makes the list of functions
understandable to the acquirer or to anyone else reading the document for the first time.
b) Textual or graphical methods can be used to show the different functions and their
relationships. Such a diagram is not intended to show a design of a product, but simply
shows the logical relationships among variables.

2.3.5 User characteristics

Describe those general characteristics of the intended groups of users of the product
including characteristics that may influence usability, such as educational level,
experience, disabilities, and technical expertise. This description should not state specific
requirements, but rather should state the reasons why certain specific requirements are
later specified in specific requirements in sub clause 2.3.9.

2.3.6 Limitations
Provide a general description of any other items that will limit the supplier's options,
including
a) Regulatory policies;
b) Hardware limitations (e.g., signal timing requirements);
c) Interfaces to other applications;
d) Parallel operation;
e) Audit functions;
f) Control functions;
g) Higher-order language requirements;
h) Signal handshake protocols (e.g., XON-XOFF, ACK-NACK);
i) Quality requirements (e.g., reliability)
j) Criticality of the application;
k) Safety and security considerations.
l) Physical/mental considerations

2.3.7 Assumptions and dependencies

List each of the factors that affect the requirements stated in the SRS. These factors are
not design constraints on the software but any changes to these factors can affect the
requirements in the SRS. For example, an assumption may be that a specific operating
system will be available on the hardware designated for the software product. If, in fact,
the operating system is not available, the SRS would then have to change accordingly.

2.3.8 Apportioning of requirements

Apportion the software requirements to software elements. For requirements that will
require implementation over multiple software elements, or when allocation to a software
element is initially undefined, this should be so stated. A cross reference table by function
and software element should be used to summarize the apportionments.
Identify requirements that may be delayed until future versions of the system (e.g., blocks
and/or increments).

2.3.9 Specific requirements

Specify all of the software requirements to a level of detail sufficient to enable designers
to design a software system to satisfy those requirements.
Specify all of the software requirements to a level of detail sufficient to enable testers to
test that the software system satisfies those requirements.
At a minimum, describe every input (stimulus) into the software system, every output
(response) from the software system, and all functions performed by the software system
in response to an input or in support of an output.
The specific requirements should:
a) Be stated in conformance with all the characteristics described in subclause 5.2 of this
International Standard.
b) Be cross-referenced to earlier documents that relate.
c) Be uniquely identifiable.

2.3.10 External interfaces

Define all inputs into and outputs from the software system. The description should
complement the interface descriptions in 2.3.3.3.1 through 2.3.3.3.5, and should not
repeat information there.
Each interface defined should include the following content:
a) Name of item;
b) Description of purpose;
c) Source of input or destination of output;
d) Valid range, accuracy, and/or tolerance;
e) Units of measure;
f) Timing;
g) Relationships to other inputs/outputs;
h) Screen formats/organization;
i) Window formats/organization;
j) Data formats;
k) Command formats;
l) End messages.
 Experiment No. 2

Objective: Write Software Requirements Specification (SRS) document of the

proposed Employee Management System.

Software Requirements Specification (SRS) document of Employee

Management System (EMS)

2.1 INTRODUCTION
2.1.1 Purpose
2.1.1.1 The purpose of this SRS is to describe the requirements involved in
developing a system to manage employee records.
2.1.1.2 The intended audience is any person who wants
2.1.1.2.1 To check employee details (both employee and administrator mode).
2.1.1.2.2 To add new employee, modify any employee’s details or delete
records for the employee (only administer mode).
2.1.2 Scope
2.1.2.1 The product is titled Employee Management System (EMS).
2.1.2.2 The product will perform the following tasks
2.1.2.2.1 Allow either an employee or an administrator to view employee details.
2.1.2.2.2 Allow the administrator to add a new employee with corresponding details.
2.1.2.2.3 Allow the administrator to modify the detail of an employee.
2.1.2.2.4 Allow the administrator to delete the records for an employee.
2.1.3 Definitions, Acronyms and Abbreviations
2.1.3.1 EMS: Employee Management System.
2.1.4 References
2.1.4.1 IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
2.1.5 Overview
2.1.5.1 The SRS contains an analysis of the requirements necessary to help easy design.
2.1.5.2 The overall description provides interface requirements for the Employee
Management System, product perspective, hardware interfaces, software
interfaces, communication interface, memory constraints, product functions, user
characteristics and other constraints.
2.1.5.3 Succeeding pages illustrate the characteristics of typical naïve users accessing the
system along with legal and functional constraints enforced that affect Employee
Management System in any fashion.

2.2 THE OVERALL DESCRIPTION

2.2.1 Product perspective
2.2.1.1 Hardware interfaces
2.2.1.1.1 Hard disk: The database connectivity requires a hardware configuration that
is on-line. This makes it necessary to have a fast database system (such as
any RDBMS) running on high rpm hard-disk permitting complete data
redundancy and back-up systems to support the primary goal of reliability.
2.2.1.1.2 The system must interface with the standard output device, keyboard and
mouse to interact with this software.
2.2.1.2 Software interfaces
 2.2.1.2.1 Back End: Oracle 11g
2.2.1.2.2 Front End: JSP
2.2.1.3 Memory Constraints
2.2.1.3.1 No specific constraints on memory.
2.2.1.4 Operations
2.2.1.4.1 The software allows two modes of operations
2.2.1.4.1.1 The administrator mode allows user to add a new employee, modify
the existing details of an employee, view the details of an employee
and also delete records for an existing employee.
2.2.1.4.1.2 The employee mode allows user to view the details of an employee.

2.2.2 Product Functions

2.2.2.1 Viewing the employee details
The user (both administrator and employee) must have the access to Up-to-date
information about the employee including
2.2.2.1.1 Employee Id
2.2.2.1.2 Employee Name
2.2.2.1.3 Employee Department
2.2.2.1.4 Date of Joining
2.2.2.1.5 Salary
2.2.2.2 Adding a new employee
The user (only in administrator mode) must be able to add a new employee by
supplying the following employee details.
2.2.2.2.1 Employee Name
2.2.2.2.2 Employee Department
2.2.2.2.3 Date of Joining
2.2.2.2.4 Salary
2.2.2.3 Modifying the details of an employee
The user (only in administrator mode) must be able to modify the following details
of an existing employee.
2.2.2.3.1 Employee Name
2.2.2.3.2 Employee Department
2.2.2.3.3 Date of Joining
2.2.2.3.4 Salary
2.2.3 User characteristics
2.2.3.1 The intended users of this software need not have specific knowledge as to what is
the internal operation of the system. Thus the end user is at a high level of
abstraction that allows easier, faster operation and reduces the knowledge
requirement of end user
2.2.3.2 The Product is absolutely user friendly, so the intended users can be the naïve users.
2.2.3.3 The product does not expect the user to possess any technical background. Any
person who knows to use the mouse and the keyboard can successfully use this
product.
2.2.4 Constraints
2.2.4.1 At the time of adding a new employee, each employee must be assigned a unique
ID number.

2.3 SPECIFIC REQUIREMENTS

2.3.1 Logical Database Requirements
 2.3.1.1 There is only one database which contains all the necessary information about an employee
across different tables which includes employee ID, employee name, department, date of
joining and salary and other information stored in child tables.

2.3.2 External Interface Requirements

2.3.2.1 Easy to navigate and use

Users should not have a hard time trying to navigate the site. Navigation links should be consistent
and clearly labeled. All navigation links should also be working properly and should point to the
intended page/site.

2.3.2.2 Browser compatible

When designing the site consider different browser environments. Extensive testing should be done
on each page in all the major browsers and the design changed appropriately to cater for all.

2.3.2.3 Visually appealing

The use of color, text, fonts and graphics should be carefullyconsidered and used to ensure that the
site is visually appealing to its visitors.

2.3.3 Performance Requirements

2.3.3.1 The performance of an application is mostly rated by its up -time and downtime.
2.3.3.2 These terms refers to the amount of time it takes the site to respond to requests. Both
must be within the acceptable limit of 10 seconds only.
2.3.3.3 Graphics should be kept to a minimum to allow the application to load faster.
2.3.3.3 The user interfaces on the application should load within an acceptable time e.g. under
10 seconds.

2.3.4 Product Functions Description

2.3.4.1 Saving a new employee’s records (Populating all of the tables with data) and Add
a record to an employee’s data records.
Saving new employee’s records: The whole process comprises a few actions, but not all of
them are compulsory to be accomplished at once! First of all, to unlock the fields in order
to get them prepared for accepting new data, the (“Add Employee”) button has to be
clicked. Afterwards, we can go to the desired form and fill the required data in. It’s not
necessary to fill in all of the forms with an exception of the two first, which ones hold the
data for the parent table into the database, and to be able to perform a successful save into
the database, we need to fill in all of the fields required there! Of course, if not all of the
rest forms are populated with data, a message appears on screen asking the user whether
he would like to proceed anyway saving only the data, filled till the moment, or go back
and fill them in. The next approach has been made up to resolve the saving problem: Firstly,
it is known that the primary key values in all tables are automatically generated by saving
a record as they have been set to an AutoNumber type. When data is saved into the parent
table, we have the primary key, which one is the Employee_ID_Number, but this value is
also needed for proceeding to another (child) table and populate it with data as the database
needs to know the responding record into the parent table! Apparently, we need to specify
to which employee (person) from the parent table, the current record we are trying to save,
belongs to. As it concerns all child tables into the database, it could be done in the following
way: When a record is populated into the parent table and we try to save another one into
a child table, the primary key’s value is taken and put into the child table where we want
to save the current record. Afterwards, we go to the child table and save the record there.
 To implement this in code, a few functions have been constructed (one for each child table
and one for establishing the connection between the parent and the child tables)

2.3.4.2 Updating records into the database

This operation, performed upon a database, is less or more essential as it is tightly related
to the “Edit”- and “Refresh”-modes of operating with data. One thing should always be
taken into an account when we deal with records-updating: We need to know the primary
key’s value of the current record that we would like to get updated by the system, as in
other way a rather different record would be updated. Two cases have been considered:_
Update All: It means, all of the records into the database, concerning a certain employee,
to be updated at once. For this purpose, it is desirable, but not compulsory, all of the fields
on the forms to be filled in with data (edited data, for instance) and after that we need to
press the “Update All” button. The program doesn’t allow the user to update not existing
records or records where insufficient information has been detected

2.3.4.3 Deleting data from the database

This kind of operation, performed upon the database, is subdivided into two parts: Single
Records Deletion and All Records Deletion. Both parts concern only single employee’s
data into the database. Deleting a single record from the database means moving to a certain
child table, selecting the record we want to be deleted and press the “Delete a Record”
button. The result is instantly reflected into the database and back into the program as well.
There is a bit difference between performing single record deletion into the child tables
and performing a delete operation upon the whole amount of records of an employee. In
the second case we need to delete the employee’s record into the parent table as well, but
before proceeding to this final action we have to ensure that all of his records into the child
tables are fully erased. Otherwise, the DBMS will not allow any data into the parent table
to be deleted! I made up as simple approach as it was possible: I have constructed a delete
function for every single child table, erasing all of the records of the selected employee.
These functions go through the child tables and when all data gets deleted, a function,
means
that only the current record we want to delete shall be removed from the database. For this

Records Deletion: To perform successfully this kind of operation upon the whole data of
an employee, existing into the database, we firstly need to delete consequently all of his
records into the child tables and then proceed to the parent table.

2.4 Conclusion

In this report, the requirements of the Employee Management Systems have been specified.
Apparently, the role of such systems is basic and essential within each company that wants
to keep a really good control and record concerning its personnel data, functionality and
performance on all levels in its structure.
That’s why the development of such systems is not just a programming business – a lot of
people are ordinarily involved in such projects and one of the basic requirements is the
reliability of the system, especially what concerns the storage of data and all of the
operations that will be performed upon it.
 Experiment No. 3

Objective: Practical exposure to the different elements of StarUML’s User

Interface.

User Interface
Main Window

Diagram Area

Diagram Area shows the currently selected diagram.

Sidebar

Sidebar is the area left containing Working Diagrams panel and Toolbox.
To show or hide Sidebar, press Ctrl+1 or check (or uncheck) View | Sidebar in Menu Bar.

Working Diagrams

Working Diagrams panel shows a list of the opened working diagram. The selected diagram is
shown in the Diagram Area.

Toolbox

Toolbox shows elements which can be created in the selected diagram.

To create an element: 1. Select an element in Toolbox 2. Mouse down on the Diagram Area and
then drag as the size of the element to be created. If the element is a kind of relationship, connect
two elements by drag and drop.

To show or hide Toolbox, press Ctrl+5 or check (or uncheck) View | Toolbox in Menu Bar.

Navigator

Navigator is the right area containing Model Explorer and Editors.

To show or hide Navigator, press Ctrl+2 or check (or uncheck) View | Navigator in Menu Bar.

Model Explorer

Model Explorer shows the tree structure of model elements.

You can find an element quickly by search box.

To change the order of elements: 1. Select the Model Explorer Settings menu in the right up
corner of Model Explorer. 2. Select one of the sorting types

● Sort by Added
● Sort by Name

To show or hide stereotypes in front of element name by check of uncheck Show Stereotype Text
in the Model Explorer Settings menu.

Editors (Holder)

Editors (Holder) contains editors to edit properties of model and view elements. It includes Style
Editor, Property Editor, and Documentation Editor.

To show or hide Editors, press Ctrl+6 or check (or uncheck) View | Editors in Menu Bar.
Style Editor

Style Editor allows editing styles of selected view elements.

Property Editor

Property Editor allows editing properties of selected model elements.

Documentation Editor

Documentation Editor allows editing documentation property of a selected model element.

Toolbar

Toolbar shows tool buttons typically provided from default or installed third-party extensions.

To show or hide Toolbar, press Ctrl+3 or check (or uncheck) View | Toolbar in Menu Bar.

Bottom Panel

Bottom Panel is a panel shown below Diagram Area typically provided from default or installed
third-party extensions including Find Results, Diagram Thumbnails, Validation Results,
Markdown Editor and etc.

Statusbar

To show or hide Statusbar, press Ctrl+4 or check (or uncheck) View | Statusbar in Menu Bar.
 Experiment No. 4

Objective: Draw a use case diagram of the proposed Employee Management

System.

Use Case Diagram Of Employee Management System (EMS)

Figure 1 - Use Case Diagram – EMS

Experiment No. 5
Objective: Draw an Entity Relationship (E-R) diagram of the proposed Employee
Management System.

Entity Relationship (E-R) Diagram Of Employee Management System (EMS)

Figure 2 — E-R Diagram – EMS

 Experiment No. 6

Objective: Draw a class diagram of College Automation System.

Class Diagram Of College Automation System (CAS)

Figure 3 — Class Diagram – CAS

 Experiment No. 7

Objective: Draw a class diagram of the proposed Employee Management System.

Class Diagram Of Employee Management System (EMS)

Figure 4 — Class Diagram – EMS

 Experiment No. 8

Objective: Draw an activity diagram of the Ticket Vending Machine (TVM).

Activity Diagram Of Ticket Vending Machine (TVM)

Figure 5 — Activity Diagram – TVM

 Experiment No. 9

Objective: Draw an activity diagram of the proposed Employee Management

System.

Activity Diagram Of Employee Management System (EMS)

Figure 6 — Activity Diagram – EMS

 Experiment No. 10

Objective: Draw a sequence diagram of the proposed Employee Management

System.

Sequence Diagram Of Employee Management System (EMS)

Figure 7 — Sequence Diagram – EMS

 Experiment No. 11

Objective: Draw a component diagram of the Employee Management System.

Component Diagram Of Employee Management System (EMS)

Figure 8 — Component Diagram – EMS

 Experiment No. 12

Objective: Code to model conversion. Take a code in C++ and reverse engineer it
into class diagram (model).

Code:
class Student
{
int rollNo;
char name[20];
public:
void putData(int,char*);
virtual void display();
};
void Student::putData(int rn,char *n)
{
rollNo=rn;
strcpy(name,n);
}
void Student::display()
{
cout<<"\n Roll No. : "<<rollNo;
cout<<"\n Name : "<<name;
}

class ClassRepresentative:public Student

{
char performanceGrade;
int noOfTimesElected;

public:
void putData(int,char*,char,int);
void display();
};
void ClassRepresentative::putData(int rn,char *n,char pg,int note)
{
Student::putData(rn,n);
performanceGrade=pg;
noOfTimesElected=note;
}
void ClassRepresentative::display()
{
Student::display();
cout<<"\n Performance Grade: "<<performanceGrade;
cout<<"\n No of times elected previously: "<<noOfTimesElected;
}
Model:
 Experiment No. 13

Objective: Model to code conversion. Take a class diagram (model) as base and
forward engineer it into code.

Model:

Code:
class Course
{
int courseId;
char courseName[20];
public:
void putData(int,char*);
void display();
};
void Course::putData(int id,char *cname)
{
courseId=id;
strcpy(courseName,cname);
}
void Course::display()
{
cout<<"\n Course :"<<courseName<<" ("<<courseId<<")";
}

class Student
{
int rollNo;
char name[20];
Course cou;

public:
 void putData(int,char*,Course);
void display();
};
void Student::putData(int rn,char *n,Course pCou)
{
rollNo=rn;
strcpy(name,n);
cou=pCou;
}
void Student::display()
{
cout<<"\n Roll No. : "<<rollNo;
cout<<"\n Name : "<<name;
cou.display();
}