Meerut Institute of Technology, Meerut

Department of Computer Science & Engineering

(Affiliated to DR. A.P.J KALAM TECHNICAL UNIVERSITY LUCKNOW)

LAB MANUAL

B.TECH.
COMPUTER SCIENCE AND ENGINEERING
(2021-2022)

Software Engineering Lab

(KCS-651)

Submitted To : Submitted By :
Ms. Srishti Agarwal
 Department of Computer Science & Engineering
MEERUT INSTITUTE OF TECHNOLOGY, MEERUT

Software Engineering Lab

(KCS-651)

INDEX

Lab Problem Statement

No.
Formulate the problem statement for a software solution required to
1.
manage the employee records in an organization.
Write Software Requirements Specification (SRS) document of the
2.
proposed Employee Management System.
3. Practical exposure to the different elements of StarUML’s User Interface.
4. Draw a use case diagram of the proposed Employee Management System.
Draw an Entity Relationship (E-R) diagram of the proposed Employee
5.
Management System.
6. Draw a class diagram of College Automation System.

7. Draw a class diagram of the proposed Employee Management System.

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

9. Draw an activity diagram of the proposed Employee Management System.

10. Draw a sequence diagram of the proposed Employee Management System.

11. Draw a component diagram of the Employee Management System

Objective: Code to model conversion. Take a code in C++ and reverse

12.
engineer it into class diagram (model).
Model to code conversion. Take a class diagram (model) as base and
13.
forward engineer it into code.
14. Formulation of Problem Statement acting as the base for SRS document.
 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.
 ISO/IEC/IEEE 29148:2011(E) Format
For
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.

2.3.11 Functions
Define the fundamental actions that have to take place in the software in accepting and
processing the inputs and in processing and generating the outputs, including
a) Validity checks on the inputs
b) Exact sequence of operations

c) Responses to abnormal situations, including

1) Overflow
2) Communication facilities
 3) Error handling and recovery
d) Effect of parameters
e) Relationship of outputs to inputs, including
1) Input/output sequences
2) Formulas for input to output conversion
It may be appropriate to partition the functional requirements into sub functions or sub
processes. This does not imply that the software design will also be partitioned that
way.

2.3.12 Usability requirements

Define usability (quality in use) requirements. Usability requirements and objectives for
the software system include measurable effectiveness, efficiency, and satisfaction
criteria in specific contexts of use.

2.3.13 Performance requirements

Specify both the static and the dynamic numerical requirements placed on the software
or on human interaction with the software as a whole.
Static numerical requirements may include the following:
a) The number of terminals to be supported;
b) The number of simultaneous users to be supported;
c) Amount and type of information to be handled.
Static numerical requirements are sometimes identified under a separate section
entitled Capacity.
Dynamic numerical requirements may include, for example, the numbers of transactions
and tasks and the amount of data to be processed within certain time periods for both
normal and peak workload conditions.
The performance requirements should be stated in measurable terms.
For example,
95 % of the transactions shall be processed in less than 1 second.
Rather than, An operator shall not have to wait for the transaction to complete.
NOTE Numerical limits applied to one specific function are normally specified as part of
the processing subparagraph description of that function.
2.3.14 Logical database requirements
Specify the logical requirements for any information that is to be placed into a database,
including:
a) Types of information used by various functions;
b) Frequency of use;

c) Accessing capabilities;
d) Data entities and their relationships;
e) Integrity constraints;
f) Data retention requirements.

2.3.15 Design constraints

Specify constraints on the system design imposed by external standards, regulatory
requirements, or project limitations.

2.3.16 Standards compliance

Specify the requirements derived from existing standards or regulations, including:
a) Report format;
b) Data naming;
c) Accounting procedures;
d) Audit tracing.
For example, this could specify the requirement for software to trace processing activity.
Such traces are needed for some applications to meet minimum regulatory or financial
standards. An audit trace requirement may, for example, state that all changes to a
payroll database shall be recorded in a trace file with before and after values.

2.3.17 Software system attributes

Specify the required attributes of the software product. The following is a partial list of
examples:
a) Reliability - Specify the factors required to establish the required reliability of the
software system at time of delivery.
b) Availability - Specify the factors required to guarantee a defined availability level for
the entire system such as checkpoint, recovery, and restart.
 c) Security - Specify the requirements to protect the software from accidental or
malicious access, use modification, destruction, or disclosure. Specific requirements in
this area could include the need to:
1) Utilize certain cryptographic techniques;
2) Keep specific log or history data sets;
3) Assign certain functions to different modules;
4) Restrict communications between some areas of the program;
5) Check data integrity for critical variables;
6) Assure data privacy.
d) Maintainability - Specify attributes of software that relate to the ease of maintenance
of the software itself.
These may include requirements for certain modularity, interfaces, or complexity
limitation. Requirements should not be placed here just because they are thought to be
good design practices.
e) Portability - Specify attributes of software that relate to the ease of porting the
software to other host
Machines and/or operating systems, including:
1) Percentage of elements with host-dependent code;
2) Percentage of code that is host dependent;
3) Use of a proven portable language;
4) Use of a particular compiler or language subset;
5) Use of a particular operating system.

2.3.18 Verification
Provide the verification approaches and methods planned to qualify the software. The
information items for verification are recommended to be given in a parallel manner with
the information items in sub clause 2.3.10 to 2.3.17.

2.3.19 Supporting information

The SRS should contain additional supporting information including
a) Sample input/output formats, descriptions of cost analysis studies, or results of user
surveys;
b) Supporting or background information that can help the readers of the SRS;
c) A description of the problems to be solved by the software;
d) Special packaging instructions for the code and the media to meet security, export,
initial loading, or other requirements.
The SRS should explicitly state whether or not these information items are to be
considered part of the requirements.
 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 deleterecords 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.1Allow 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
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.
Bothmust 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.4 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, erasing the record into the parent table, is called as last. Single
Record Deletion: means that only the current record we want to delete shall be removed
from the database. For this purpose, we can use the functional buttons, related to a record
in each data table. All 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. Every organization, in
now-a-days, has the necessity of managing its staff on a really good level as the staff has
definitely the greatest merit of building up a company as such as it is.
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();
}