LAB MANUAL

Lab Name : Software Engineering Lab

Lab Code : 3CS4 - 23

Branch : Computer Science & Engineering

Year/Sem : 2rd Year/III

Jaipur Engineering College and Research Center, Jaipur

Department of Computer Science & Engineering
(Rajasthan Technical University, KOTA)

1
 INDEX
PAGE
S.NO CONTENTS CO
NO.

1 VISION/MISION 4

2. PEO 4

3. POS 5

4. MAPPING OF PO & PEO 6

5. COS 6

6. MAPPING OF CO & PO 6

7. SYLLABUS 7

8. BOOKS 8

9. INSTRUCTIONAL METHODS 8

10. LEARNING MATERIALS 8

11. ASSESSMENT OF OUTCOMES 8

LIST OF EXPERIMENTS (RTU SYLLABUS)

Objectives: - Development of requirements specification, function oriented

Exp:- 1 design using SA/SD, object-oriented design using UML, test case design, 12
implementation using Java and testing. Use of appropriate CASE tools and
other tools such as configuration management tools, program analysis tools in
the software life cycle.
Exp:- 2 Objectives :- Develop Software Requirements Specification (SRS) for a given 13
problem in IEEE template.
Exp:-3 Objectives :- Develop DFD model (level-0, level-1 DFD and Data 20
dictionary) of the project.

Exp:-4 23
Objectives: - Develop ERD model of the project.

2
Exp:-5 Objectives: - Developed all Structure UML diagram of the given project. 26

Exp:-6 Objectives: Develop Behavior UML diagram of the given project. 28

Objectives: Manage file, using ProjectLibre project management software

Exp:-7 tool.

3
 JAIPUR ENGINEERING COLLEGE AND RESEARCH CENTER

Department of Computer Science & Engineering

Branch: Computer Science & Engineering Semester: 3rd

Course Name: Software Engineering Lab Code: 3CS4 - 23

External Marks: 30 Practical hrs: 3 hrs/week

Internal Marks: 45 Total Marks: 45

1. VISION & MISSION

VISION: To become renowned Centre of excellence in computer science and engineering and
make competent engineers & professionals with high ethical values prepared for lifelong
learning.

.MISSION:

M1: To impart outcome based education for emerging technologies in the field of
computer science and engineering.
M2: To provide opportunities for interaction between academia and industry.
M3: To provide platform for lifelong learning by accepting the change in technologies
M4: To develop aptitude of fulfilling social responsibilities.

2. PEO

1. To provide students with the fundamentals of Engineering Sciences with more

emphasis in Computer Science &Engineering by way of analyzing and exploiting
engineering challenges.
2. To train students with good scientific and engineering knowledge so as to
comprehend, analyze, design, and create novel products and solutions for the real life
problems.

4
3. To inculcate professional and ethical attitude, effective communication skills,
teamwork skills, multidisciplinary approach, entrepreneurial thinking and an ability to
relate engineering issues with social issues.
4. To provide students with an academic environment aware of excellence, leadership,
written ethical codes and guidelines, and the self motivated life-long learning needed
for a successful professional career.
5. To prepare students to excel in Industry and Higher education by Educating Students
along with High moral values and Knowledge

3. PROGRAM OUTCOMES
1. Engineering knowledge: Apply the knowledge of mathematics, science,
engineering fundamentals, and Computer Science & Engineering specialization to
the solution of complex Computer Science & Engineering problems.
2. Problem analysis: Identify, formulate, research literature, and analyze complex
computer Science & Engineering problems reaching substantiated conclusions
using first principles of mathematics, natural sciences, and engineering sciences.
3. Design/development of solutions: Design solutions for complex Computer
Science& Engineering problems and design system components or processes that
meet the specified needs with appropriate consideration for the public health and
safety, and the cultural, societal, and environmental considerations.
4. Conduct investigations of complex problems: Use research-based knowledge
and research methods including design of Computer Science & Engineering
experiments, analysis and interpretation of data, and synthesis of the information
to provide valid conclusions.
5. Modern tool usage: Create, select, and apply appropriate techniques, resources,
and modern Computer Science& Engineering and IT tools including prediction
and modeling to complex computer science engineering activities with an
understanding of the limitations.
6. The engineer and society: Apply reasoning informed by the contextual
knowledge to assess societal, health, safety, legal and cultural issues and the

5
 consequent responsibilities relevant to the professional Computer Science &
Engineering practice.
7. Environment and sustainability: Understand the impact of the professional
Computer Science & Engineering solutions in societal and environmental
contexts, and demonstrate the knowledge of, and need for sustainable
development.
8. Ethics: Apply ethical principles and commit to professional ethics and
responsibilities and norms of the Computer Science & Engineering practice.
9. Individual and team work: Function effectively as an individual, and as a
member or leader in diverse teams, and in multidisciplinary settings in Computer
Science & Engineering.
10. Communication: Communicate effectively on complex Computer Science &
Engineering activities with the engineering community and with society at large,
such as, being able to comprehend and write effective reports and design
documentation, make effective presentations, and give and receive clear
instructions.
11. Project management and finance: Demonstrate knowledge and understanding
of the Computer Science & Engineering and management principles and apply
these to one’s own work, as a member and leader in a team, to manage projects
and in multidisciplinary environments.
12. Life-long learning: Recognize the need for, and have the preparation and ability
to engage in independent and life-long learning in the broadest context of
Computer Science& Engineering change.

6
4. MAPPING OF PEOs & POs

PROGRAM OUTCOMES
PROGRAM
OBJECTIVES 12
1 2 3 4 5 6 7 8 9 10 11

I H L H

II M H M H H L H

III L H M H L M

IV L M H M H M

V M M

7
5. COURSE OUTCOMES
Graduates would be able:
1. To understand Software Requirement Analysis, CASE Tools, Software Testing,
and other configuration tools.
2. To understand Functional Modeling (DFD), Data Modeling (DFD) - Use work
products – data dictionary.
3. An ability to understand the Structural and Behavioral UML Diagrams with the
use of Project Management Tool – ProjectLibre.

6. MAPPING OF CO & PO

COURSE PROGRAM OUTCOMES

OUTCOMES
1 2 3 4 5 6 7 8 9 10 11 12

I H H H M H L L M M

II H H H M M L L M M

II H H H M H L L M M

8
7. SYLLABUS
Objectives:
At the end of the semester, the students should have clearly understood and implemented the
following:
S. No. LIST OF EXPERIMENTS (RTU SYLLABUS)

Objectives: - Development of requirements specification, function oriented

Exp:- 1 design using SA/SD, object-oriented design using UML, test case design,
implementation using Java and testing. Use of appropriate CASE tools and
other tools such as configuration management tools, program analysis tools in
the software life cycle.
Exp:- 2 Objectives :- Develop Software Requirements Specification (SRS) for a given
problem in IEEE template.
Exp:-3 Objectives :- Develop DFD model (level-0, level-1 DFD and Data
dictionary) of the project.

Exp:-4
Objectives: - Develop ERD model of the project.

Exp:-5 Objectives: - Developed all Structure UML diagram of the given project.

Exp:-6 Objectives: Develop Behavior UML diagram of the given project.

Objectives: Manage file, using ProjectLibre project management software

Exp:-7
tool.

8. BOOKS:-

8.1 Text books:-

1. Software Engineering by Roger S. Pressman, TMH

2. Software Engineering fundamentals by Ali Behforooz, Frederick J. Hudson, Oxford
University Press

8.2 Reference Books:-

1. Software Engineering by Ian Sommerville

9
 2. Software Engineering by Richard E. Fairley, TMH

9. INSTRUCTIONAL METHODS:-
9.1. Direct Instructions:

I. Through Projectors & White Board with Marker

9.2. Interactive Instruction:

I. Programs

9.3 . Indirect Instructions:

I. Problem solving

10. LEARNING MATERIALS:-

9.1. Text/Lab Manual

11. ASSESSMENT OF OUTCOMES:-

1. End term Practical exam (Conducted by RTU, KOTA)

2. Daily Lab interaction.
OUTCOMES WILL BE ACHIEVED THROUGH FOLLOWING:-

1. Lab Teaching (through Projectors and White Board).

2. Discussion on Programs.

10
 INSTRUCTIONS OF LAB

DO’s
1. Please switch off the Mobile/Cell phone before entering Lab.
2. Enter the Lab with complete source code and data.
3. Check whether all peripheral are available at your desktop before proceeding for
program.
4. Intimate the lab In charge whenever you are incompatible in using the system or
in case software get corrupted/ infected by virus.
5. Arrange all the peripheral and seats before leaving the lab.
6. Properly shutdown the system before leaving the lab.
7. Keep the bag outside in the racks.
8. Enter the lab on time and leave at proper time.
9. Maintain the decorum of the lab.
10. Utilize lab hours in the corresponding experiment.
11. Get your CD / Pen drive checked by lab In charge before using it in the lab.

DON’TS
1. No one is allowed to bring storage devices like Pan Drive /Floppy etc. in the
lab.
2. Don’t mishandle the system.
3. Don’t leave the system on standing for long
4. Don’t bring any external material in the lab.
5. Don’t make noise in the lab.
6. Don’t bring the mobile in the lab. If extremely necessary then keep ringers off.
7. Don’t enter in the lab without permission of lab Incharge.
8. Don’t litter in the lab.
9. Don’t delete or make any modification in system files.
10. Don’t carry any lab equipments outside the lab.
We need your full support and cooperation for smooth functioning of the

11
 INSTRUCTIONS FOR STUDENT

BEFORE ENTERING IN THE LAB

 All the students are supposed to prepare the theory regarding the next program.
 Students are supposed to bring the practical file and the lab copy.
 Previous programs should be written in the practical file.
 Any student not following these instructions will be denied entry in the lab.

WHILE WORKING IN THE LAB

 Adhere to experimental schedule as instructed by the lab incharge.
 Get the previously executed program signed by the instructor.
 Get the output of the current program checked by the instructor in the lab copy.
 Each student should work on his/her assigned computer at each turn of the lab.
 Take responsibility of valuable accessories.
 Concentrate on the assigned practical and do not play games.
 If anyone caught red handed carrying any equipment of the lab, then he will have to face
serious consequences.

12
 Experiment No.1
Aim:- Development of requirements specification, function oriented design using SA/SD,
object-oriented design using UML, test case design, implementation using Java and testing. Use
of appropriate CASE tools and other tools such as configuration management tools, program
analysis tools in the software life cycle.

WHAT IS COMPUTER SOFTWARE?

Computer software or simply software is any set of machine-readable instructions that directs a
computer's processor to perform specific operations. Computer software contrasts with computer
hardware, which is the physical component of computers. Computer hardware and software
require each other and neither can be realistically used without the other.

Computer software includes computer programs, libraries and their associated documentation.
The word software is also sometimes used in a more narrow sense, meaning application software
only. Software is stored in computer memory and is intangible, i.e. it cannot be touched.

WHAT IS SOFTWARE ENGINEERING?

Software engineering is the study and an application of engineering to the design, development,
and maintenance of software.

Typical formal definitions of software engineering are:

 the application of a systematic, disciplined, quantifiable approach to the development,

operation, and maintenance of software.
 an engineering discipline that is concerned with all aspects of software production.
 the establishment and use of thorough engineering principles in order to economically
obtain software that is reliable and works efficiently on real machines.

WHY IS SOFTWARE IMPORTANT?

Software affects nearly every aspect of our lives and has become pervasive in our commerce, our
culture and our everyday activities.

THE EVOLVING ROLE OF SOFTWARE:

13
The role of computer software has undergone significant change over a span of little more than
50 years. Dramatic improvements in Hardware performance profound change in Computing
architectures, vast increases in Memory and Storage capacity and a wide variety of exotic input
and output options have all precipitated more sophisticated and complex computer based system.

SOFTWARE CHARACTERISTICS:

1) Software is Developed or Engineered. It is not manufactured in the classical sense.

Although some similarities exist between software development and hardware
manufacturing, yet the two activities are fundamentally different.
2) Software does not wear out but deteriorates due to changes.
 Software is not susceptible to the environment maladies that cause hardware to wear out.
Software undergoes changes during its life. As changes are made, it is likely that errors
will be introduced; causing the failure and thus increased failure rate indicates the
decoration of software as a result of change.
 Another aspect of Software and Hardware differences caused by wear-out is that:-

When a Hardware component wears out, it is replaced by a spare part. However, there are no
software spare parts. Every Software failure indicates an error in design, or in program
coding, therefore, Software maintenance involves considerably more complexity than
Hardware maintenance.

3) Most Software continues to be Custom built.

Although the industry is moving towards Component-based construction, most software
continues to be custom built.

In hardware industry the components parts are designed to be reusable and can be ordered off
the shelf. These are called Standard Design Components. Component use is a natural part of
the Hardware engineering process.

However in the Software world, it has only begun to be achieved on a broad scale. A
Software component should be designed and implemented so that it can be “Reused” in many
different programs. ”Reusable Objects” or „‟Reusable Software Components‟‟ enable
the Software Engineers to create new applications from reusable parts.

14
SOFTWARE CATAGORIES

1) System Software
2) Application Software
3) Engineering/Scientific Software
4) Embedded Software
5) Product-line Software
6) Web Application (WebApps)
7) Artificial Intelligence Software (AI Software)

SYSTEM SOFTWARE:

System Software is a collection of Programs written to service other Programs (e.g. Compilers,
Editors, File management utilities, etc.). These software are process complex but determinate
information structure.

Other system software, like Operating Systems, Drivers, Networking software,

Telecommunications processors, process largely intermediate data.

CHARACTERISTICS OF SYSTEM SOFTWARE

System Software area is characterized by heavy interaction with Computer hardware, heavy
usage by multiple users, concurrent operation that regain scheduling, resource sharing and
sophisticated process management, complex data structure and multiple external interface.

APPLICATION SOFTWARE

Application software consists of standalone programs that solve specific business need.
Application software processes business data in a way to facilitate business operation or
Management decision making. (Hotel Management System, Decision Support Systems etc)

ENGINEERING / SCIENTIFIC SOFTWARE

Formerly, characterized by “Number crunching” algorithms. Engineering and Scientific

Applications range from Astronomy to Volcanology, from automotive stress analysis to Space
shuttle orbital dynamics and from Molecular Biology to Automated manufacturing.

15
EMBEDDED SOFTWARE

Embedded software resides within a product or system and is used to implement and control
features and functions for the end-uses and for the system itself.(e.g.: Keypad control for a
microwave oven, digital function in an Automobile such as fuel control, Anti-braking system
(ABS) etc.

PRODUCT-LINE SOFTWARE (SOFTWARE PACKAGE PROGRAMS)

Designed to provide a specific capability for use by many different customers. It can focus on a
limited and esoteric marketplace (e.g.: Inventory control products, Database Management
System, Personal and Business Functional Applications, Word processing, Computer graphics
etc)

WEB APPLICATIONS (WEB APPS)

WebApps in their simplest form can be little more than a set of linked hypertext files that present
information using text and limited graphics. However as e-commerce and B2B (business to
business) applications grow in importance, webApps are evolving into sophisticated computing
environment. WebApps not only provide standalone features, computing functions and content
to end-users, but also are integrated with corporate databases and Business applications.

ARTIFICIAL INTELLIGENCE SOFTWARE (AI SOFTWARE)

(AI) software makes use of “NON NUMERICAL ALGORITHMS” to solve complex problems
that are not amenable to computation or straight forward analysis (e.g. Robotics, Expert systems,
Pattern recognition, Image or Voice recognition), Artificial Neural networks, Theorem proving
and Game playing.)

Millions of Software Engineers worldwide are hard at work on Project in one or more of the
above mentioned 7 software categories.

In some cases new Computer System are being built, but in others, existing software applications
are being corrected, adapted and enhanced.

16
THE NEW SOFTWARE CHALLENGES ON THE HORIZON

The following new Software challenges have appeared on the horizon:

 Ubiquitous computing
 Net sourcing
 Open source
 The New Economy (Dot.com)

UBIQUITOUS COMPUTING

The rapid growth of „‟Wireless Networking‟‟ may soon lead to true Distributed Computing. The
challenge to current Software Engineers is to develop System and Applications software that will
allow “Small Device”, Personal Computers and Enterprise System to communicate across vast
networks.

NET SOURCING

WWW is rapidly becoming a Computing Engine as well as a Content Provider. The challenge
for current Software Engineers is to architect simple and sophisticated application that provide
benefit to targeted end-user markets world wide (e.g. personal financial planning applications)

OPEN SOURCE

A growing trend that results in “Distribution of Source Code) for Software applications
(e.g. Operating systems, Database and Development environments) so that customers can make
Local modification. The challenges for current generation Software Engineers is to build Source
code that is “Self- descriptive”, but more importantly, to develop techniques that will enable both
customers and developers to know what changes have been made and how those changes
manifest themselves within the software.

THE NEW ECONOMY (DOT COM)

The DOT COM gripped financial markets during late 1990‟s and the bust that followed have
lead many Business people to believe that the New Economy is dead. The New Economy is alive

17
and well but it will evolve slowly. The New Economy will be characterized by mass
Communication and Distribution.

The challenge for current Software Engineers is to built Application and Mass Product
Distribution using concepts that are only forming now.

LEGACY SOFTWARE

Hundreds of thousands of Computer Programs fall into one of the seven broad Application
categories as mentioned above. Some of these Programs are State-of-the-art Software; but
other programs are older programs often referred to as Legacy Software.

Legacy Software have been developed decades ago and continually modified to meet changes in
business requirements and computing platforms. The proliferation of such system is causing
headaches for large organizations who find them costly to maintain and risky to evolve. Still
many Legacy Systems remain supportive to core business functions and are indispensable to the
business.

Hence, Legacy Software is characterized by ‟Longevity and Business critically”.

Unfortunately, there is one additional characteristic that can be present in Legacy software; that
is “Poor quality”. Legacy software system in many cases have inextensible design, code, poor
or nonexistent document, test cases and results that were never archived, a poorly managed
change history and so on,,,,. Yet these systems are expected to support “Core business functions
and are indispensable to the business.

Computer-Aided Software Engineering (CASE)

Computer-Aided Software Engineering (CASE) is the integration of software-based modeling

tools into the software development process. Analysis and design methodologies and modeling
notations were developed to formalize the software engineering process; CASE tools automate
that process by assisting in each step. Some types of CASE tools are analysis and design tools,
automated code generation tools, and software testing tools. Analysis and design tools aid in the
creation of diagrams and project documentation. Automated code generation assists in the
implementation phases. Testing tools lead to a more thorough evaluation of an application. Table

18
given below provides a chronological list of CASE tool development.

Time Period CASE Tools

Documentation
Early 1980‟s
Analysis and design diagramming
Mid-1980‟s Analysis and design validation
Late 1980‟s Automated code generation
Early 1990‟s User interface reusability

Selecting a CASE Tool

A wide variety of CASE tools exist to support different development environments. Choosing
the best tool for a project can be a challenging exercise. The criteria used to select CASE tools
include methodology, flexibility, collaboration, and diagram validation.

Methodology

Although a wide variety of software development methodologies exist, common themes exist
between all object-oriented methodologies. Most variations occur in their processes, procedures,
and notations. It is vital that the CASE tools selected support the methodology followed by the
project.

Flexibility

It is impossible to foresee every project need before development has begun. For this reason,
choose tools that allow customization. The tool should allow custom documentation and should
provide support for multiple programming languages. The best tools allow construction of
custom schemas that can be used to generate code in several programming languages. Even with
a detailed methodology, unforeseen problems and needs may arise throughout software
development. Thus, the CASE tool cannot force users to use a fixed design. Common CASE tool
flexibilities include the ability to modify the target operating system, language used, modeling
language, size of the software, and the entire process.

Collaboration

19
One of the principal purposes of any software development methodology is to facilitate
collaboration. It is vital that CASE tools allow collaboration among developers; multiple
developers should be able to work on the project simultaneously. The tool should also support
distribution across multiple computers and multiple work areas.There are two parts to
collaboration, both of which can heavily influence the selection of the CASE tool. The first is the
prerequisites of the design. The second is the knowledge of the organization producing the code.

Diagram validation

Although diagrams are used to simplify the design of a complex system, diagrams themselves
can become fairly complex. Tools are available to validate analysis and design diagrams. These
tools help diagrams conform to the modeling syntax, and ensure consistency across sets of
diagrams.

20
 Experiment No. 2

Aim:- Develop Software Requirements Specification (SRS) for a given problem in IEEE
template.

PROJECT SRS IEEE TEMPLATE

1. INTRODUCTION

<TO DO: Please provide a brief introduction to your project and a brief overview of what the
reader will find in this section.>

1.1 Document Purpose

<Identify the product whose software requirements are specified in this document, including the
revision or release number. Describe the scope of the product that is covered by this SRS,
particularly if this SRS describes only part of the system or a single subsystem.

TO DO: Write 1-2 paragraphs describing the purpose of this document as explained above.>

1.2 Product Scope

<Provide a short description of the software being specified and its purpose, including relevant
benefits, objectives, and goals.

TO DO: 1-2 paragraphs describing the scope of the product. Make sure to describe the benefits
associated with the product.>

1.3 Intended Audience and Document Overview

<Describe the different types of reader that the document is intended for, such as developers,
project managers, marketing staff, users, testers, and documentation writers. Describe what the
rest of this SRS contains and how it is organized. Suggest a sequence for reading the document,
beginning with the overview sections and proceeding through the sections that are most pertinent
to each reader type.>

1.4 Definitions, Acronyms and Abbreviations

21
<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the
entire organization, and just include terms specific to a single project in each SRS.

TO DO: Please provide a list of all abbreviations and acronyms used in this document sorted in
alphabetical order.>

1.5 References and Acknowledgments

<List any other documents or Web addresses to which this SRS refers. These may include user
interface style guides, contracts, standards, system requirements specifications, use case
documents or a vision and scope document.

TO DO: Use the standard IEEE citation guide for this section. Give complete links of 2-3 main
websites referred. >

2. OVERALL DESCRIPTION

2.1 Product Perspective

<Describe the context and origin of the product being specified in this SRS. For example, state
whether this product is a follow-on member of a product family, a replacement for certain
existing systems, or a new, self-contained product. If the SRS defines a component of a larger
system, relate the requirements of the larger system to the functionality of this software and
identify interfaces between the two. In this part, make sure to include a simple diagram that
shows the major components of the overall system, subsystem interconnections, and external
interface. In this section it is crucial that you will be creative and provide as much information as
possible.

TO DO: Provide at least one paragraph describing product perspective. Provide a general
diagram that will illustrate how your product interacts with the environment and in what context
it is being used. >

2.2 Product Functionality

<Summarize the major functions the product must perform or must let the user perform. Details

22
will be provided in Section 3, so only a high level summary is needed here. Organize the
functions to make them understandable to any reader of the SRS. A picture of the major groups
of related requirements and how they relate, such as a top level data flow diagram or object class
diagram, will be effective.

TO DO: Provide a bulleted list of all the major functions of the system.>

2.3 Users and Characteristics

<Identify the various users that you anticipate will use this product. Users may be differentiated
based on frequency of use, subset of product functions used, technical expertise, security or
privilege levels, educational level, or experience.

TO DO:

1. Describe the relevant characteristics of each user. Certain requirements may relate only to
certain users.
2. Distinguish the most important users for this product from those who are less important to
satisfy.>
2.4 Operating Environment

<Describe the environment in which the software will operate, including the hardware platform,
operating system and versions, and any other software components or applications with which it
must peacefully coexist. In this part, make sure to include a simple diagram that shows the major
components of the overall system, subsystem interconnections, and external interface

TO DO: As stated above, in at least one paragraph, describe the environment your system will
have to operate in. Make sure to include the minimum platform requirements for your system. >

2.5 Design and Implementation Constraints

<Describe any items or issues that will limit the options available to the developers. These might
include: hardware limitations (timing requirements, memory requirements); interfaces to other
applications; specific technologies, tools, and databases to be used; parallel operations; language
requirements; communications protocols; security considerations; design conventions or
programming standards (for example, if the customer’s organization will be responsible for

23
maintaining the delivered software).

TO DO: In this section you need to consider all of the information you gathered so far, analyze it
and correctly identify at least 5 constraints.>

2.6 User Documentation

<List the user documentation components (such as user manuals, on-line help, and tutorials) that
will be delivered along with the software. Identify any known user documentation delivery
formats or standards.

TO DO: You will not actually develop any user -manuals, but you need to describe what kind of
manuals and what kind of help is needed for the software you will be developing. One paragraph
should be sufficient for this section.>

2.7 Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements stated
in the SRS. These could include third-party or commercial components that you plan to use,
issues around the development or operating environment, or constraints. The project could be
affected if these assumptions are incorrect, are not shared, or change. Also identify any
dependencies the project has on external factors, such as software components that you intend to
reuse from another project.

TO DO: Provide a short list of some major assumptions that might significantly affect your
design. For example, you can assume that your client will have 1, 2 or at most 10 finger-print
scanners. Every number has a significant effect on the design of your system. >

3. SPECIFIC REQUIREMENTS

3.1 External Interface Requirements

3.1.1 User Interfaces

<Describe the logical characteristics of each interface between the software product and the
users. This may include sample screen images, any GUI standards or product family style guides
that are to be followed, screen layout constraints, standard buttons and functions (e.g., Cancel)

24
that will appear on every screen, error message display standards, and so on. Define the software
components for which a user interface is needed.

TO DO: The least you can do for this section is to describe in words the different User Interfaces
and the different screens that will be available to the user. Those who will be able to provide
optional Graphical User Interface screenshots, will be rewarded by extra marks.>

3.1.2 Hardware Interfaces

<Describe the logical and physical characteristics of each interface between the software product
and the hardware components of the system. This may include the supported device types, the
nature of the data and control interactions between the software and the hardware. You are not
required to specify what protocols you will be using to communicate with the hardware, but it
will be usually included in this part as well.

TO DO: Please provide a short description of the different hardware interfaces. If you will be
using some special libraries to communicate with your software mention them here. In case you
have more than one hardware interface, divide this section into subsections.>

3.2 Software Interfaces

<Describe the connections between this product and other specific software components (name
and version), including databases, operating systems (Windows? Linux? Etc…), tools, libraries,
and integrated commercial components. Identify the data items or messages coming into the
system and going out and describe the purpose of each. Describe the services needed and the
nature of communications. Identify data that will be shared across software components. If the
data sharing mechanism must be implemented in a specific way (for example, use of a global
data area in a multitasking operating system), specify this as an implementation constraint.

TO DO: The previous part illustrates some of the information you would usually include in this
part of the SRS document. To make things simpler, you are only required to describe the specific
interface with the operating system.>

3.3 Communications Interfaces

<Describe the requirements associated with any communications functions required by this

25
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication
standards that will be used, such as FTP or HTTP. Specify any communication security or
encryption issues, data transfer rates, and synchronization mechanisms.

TO DO: Do not go into too much detail, but provide 1-2 paragraphs were you will outline the
major communication standards. For example, if you decide to use encryption there is no need to
specify the exact encryption standards, but rather, specify the fact that the data will be encrypted
and name what standards you consider using. >

3.4 Functional Requirements

< Functional requirements capture the intended behavior of the system. This behavior may be
expressed as services, tasks or functions the system is required to perform. This section is the
direct continuation of section 2.2 where you have specified the general functional requirements.
Here, you should list in detail the different product functions with specific explanations
regarding every function.

TO DO: Brake the functional requirements to several functional areas and divide this section
into subsections accordingly. Provide a detailed list of all product operations related to these
functional areas.

3.5 Behaviour Requirements

Use Case View

<A use case defines a goal-oriented set of interactions between external actors and the system
under consideration.

TO DO: Provide a use case diagram which will encapsulate the entire system and all possible
actors. Do not include detailed use case descriptions (these will be needed when you will be
working on the Test Plan), but make sure to include a short description of what every use-case is,
who are the actors in your diagram.>

26
4. OTHER NON-FUNCTIONAL REQUIREMENTS

4.1 Performance Requirements

<If there are performance requirements for the product under various circumstances, state them
here and explain their rationale, to help the developers understand the intent and make suitable
design choices. Specify the timing relationships for real time systems. Make such requirements
as specific as possible. You may need to state performance requirements for individual
functional requirements or features.

TO DO: Provide at least 5 different performance requirements based on the information you
collected from the client. For example you can say “1. Any transaction will not take more than
10 seconds, etc…>

4.2 Safety and Security Requirements

<Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as well as
actions that must be prevented. Refer to any external policies or regulations that state safety
issues that affect the product’s design or use. Define any safety certifications that must be
satisfied. Specify any requirements regarding security or privacy issues surrounding use of the
product or protection of the data used or created by the product. Define any user identity
authentication requirements.

TO DO:

1. Provide at least 3 different safety requirements based on your interview with the client or,
on your project research, and again you need to be creative here.
2. Describe briefly what level of security is expected from this product by the client and
provide a bulleted (or numbered) list of the major security requirements.>

4.2 Software Quality Attributes

<Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness,

27
testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At
the least, clarify the relative preferences for various attributes, such as ease of use over ease of
learning.

TODO: Use subsections (e.g., 4.3.1 Reliability, 4.3.2 Portability, etc…) provide requirements
related to the different software quality attributes. Base the information you include in these
subsections on the material you have learned in the class. Make sure, that you do not just write
“This software shall be maintainable…” Indicate how you plan to achieve it, & etc…Do not
forget to include such attributes as the design for change. Please note that you need to include at
least 5 quality attributes.>

28
 Experiment No. 3

Aim: Develop DFD model (level-0, level-1 DFD and Data dictionary) of the project

FUNCTION MODELING
Functional Modeling gives the process perspective of the object-oriented analysis model
and an overview of what the system is supposed to do. It defines the function of the
internal processes in the system with the aid of Data Flow Diagrams (DFDs). It depicts the
functional derivation of the data values without indicating how they are derived when they
are computed, or why they need to be computed.

Data Flow Diagram:-

Data flow diagram is graphical representation of flow of data in an information system. It is
capable of depicting incoming data flow, outgoing data flow and stored data. The DFD does not
mention anything about how data flows through the system.

There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of
control in program modules. DFDs depict flow of data in the system at various levels. DFD
does not contain any control or branch elements.

Types of DFD:-
Data Flow Diagrams are either Logical or Physical.

 Logical DFD - This type of DFD concentrates on the system process, and flow of data in
the system.For example in a Banking software system, how data is moved between
different entities.

 Physical DFD - This type of DFD shows how the data flow is actually implemented in
the system. It is more specific and close to the implementation.

DFD Components:-
DFD can represent Source, destination, storage and flow of data using the following set of
components -

29
  Entities - Entities are source and destination of information data. Entities are represented
by a rectangles with their respective names.

 Process - Activities and action taken on the data are represented by Circle or Round-
edged rectangles.

 Data Storage - There are two variants of data storage - it can either be represented as a
rectangle with absence of both smaller sides or as an open-sided rectangle with only one
side missing.

 Data Flow - Movement of data is shown by pointed arrows. Data movement is shown
from the base of arrow as its source towards head of the arrow as destination.

Levels of DFD:-

 Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the
entire information system as one diagram concealing all the underlying details. Level 0
DFDs are also known as context level DFDs.

 Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1
DFD depicts basic modules in the system and flow of data among various modules. Level
1 DFD also mentions basic processes and sources of information.

30
  Level 2 - At this level, DFD shows how data flows inside the modules mentioned in
Level 1.

Higher level DFDs can be transformed into more specific lower level DFDs with deeper
level of understanding unless the desired level of specification is achieved.

ER Diagrams:-

An Entity Relationship Diagram (ERD) is a visual representation of different data using

conventions that describe how these data are related to each other.

ER Diagram Symbols and Notations:-

31
Entity:-
Entities are represented by means of rectangles. Rectangles are named with the entity set they
represent.

Attributes:-
Attributes are the properties of entities. Attributes are represented by means of ellipses. Every
ellipse represents one attribute and is directly connected to its entity (rectangle).

If the attributes are composite, they are further divided in a tree like structure. Every node is
then connected to its attribute. That is, composite attributes are represented by ellipses that are
connected with an ellipse.

32
Multivalued attributes are depicted by double ellipse.

Derived attributes are depicted by dashed ellipse.

33
Weak Entity:-

A weak entity is an entity that depends on the existence of another entity. In more technical
terms it can defined as an entity that cannot be identified by its own attributes. It uses a foreign
key combined with its attributed to form the primary key. An entity like order item is a good
example for this. The order item will be meaningless without an order so it depends on the
existence of order.

Weak Entity Example in ER diagrams

Relationships:-

Entity-Relationship model making possibility to describe a database in which in the tables data
can be the point to data in other tables - for instance, your entry in the database could point to
several entries.

34
Data Dictionary:-

A data dictionary contains metadata i.e data about the database. The data dictionary is very
important as it contains information such as what is in the database, who is allowed to access it,
where is the database physically stored etc. The users of the database normally don't interact with
the data dictionary, it is only handled by the database administrators.

The data dictionary in general contains information about the following −

 Names of all the database tables and their schemas.

 Details about all the tables in the database, such as their owners, their security
constraints, when they were created etc.

 Physical information about the tables such as where they are stored and how.

 Table constraints such as primary key attributes, foreign key information etc.

 Information about the database views that are visible.

This is a data dictionary describing a table that contains employee details.

35
Field Name Data Type Field Size for Description Example
display

Employee Integer 10 Unique ID of each employee 1645000001

Number

Name Text 20 Name of the employee David

Heston

Date of Birth Date/Time 10 DOB of Employee 08/03/1995

Phone Number Integer 10 Phone number of employee 6583648648

The different types of data dictionary are −

Active Data Dictionary

If the structure of the database or its specifications change at any point of time, it should be
reflected in the data dictionary. This is the responsibility of the database management system in
which the data dictionary resides.

So, the data dictionary is automatically updated by the database management system when any
changes are made in the database. This is known as an active data dictionary as it is self
updating.

Passive Data Dictionary

This is not as useful or easy to handle as an active data dictionary. A passive data dictionary is
maintained separately to the database whose contents are stored in the dictionary. That means
that if the database is modified the database dictionary is not automatically updated as in the case
of Active Data Dictionary.

So, the passive data dictionary has to be manually updated to match the database. This needs
careful handling or else the database and data dictionary are out of sync.

36
 Experiment No.4

Aim: Develop ERD model of the project.

DATA MODELING

Data modeling in software engineering is the process of creating a data model for an information
system by applying formal data modeling techniques.

Data modeling techniques and methodologies are used to model data in a standard, consistent,
predictable manner in order to manage it as a resource. The use of data modeling standards is
strongly recommended for all projects requiring a standard means of defining and analyzing data
within an organization, e.g., using data modeling:

 to assist business analysts, programmers, testers, manual writers, IT package selectors,

engineers, managers, related organizations and clients to understand and use an agreed
semi-formal model the concepts of the organization and how they relate to one another
 to manage data as a resource
 for the integration of information systems
 for designing databases/data warehouses (aka data repositories)

Entity Relationship Diagram

An entity relationship diagram (ERD) is one means of representing the objects and their
relationships in the data model for a software product.

An entity-relationship diagram (ERD) is a graphical representation of an information system that

shows the relationship between people, objects, places, concepts or events within that system. An
ERD is a data modeling technique that can help define business processes and can be used as the
foundation for a relational database.

Creating an Entity/Relationship Diagram:- The entity/relationship diagram enables a software

engineer to fully specify the data objects that are input and output from a system, the attributes

37
that define the properties of these objects, and their relationships. Like most elements of the
analysis model, the ERD is constructed in an iterative manner. The following approach is taken:

1. During requirements elicitation, customers are asked to list the “things” that the application or
business process addresses. These “things” evolve into a list of input and output data objects as
well as external entities that produce or consume information.

2. Taking the objects one at a time, the analyst and customer define whether or not a connection
(unnamed at this stage) exists between the data object and other objects.

3. Wherever a connection exists, the analyst and the customer create one or more
object/relationship pairs.

4. For each object/relationship pair, cardinality and modality are explored.

5. Steps 2 through 4 are continued iteratively until all object/relationships have been defined. It is
common to discover omissions as this process continues. New objects and relationships will
invariably be added as the number of iterations grows.

6. The attributes of each entity are defined.

7. An entity relationship diagram is formalized and reviewed.

Entity

Entities are represented by means of rectangles. Rectangles are named with the entity set they
represent.

Attributes

Attributes are the properties of entities. Attributes are represented by means of ellipses. Every
ellipse represents one attribute and is directly connected to its entity (rectangle).

38
If the attributes are composite, they are further divided in a tree like structure. Every node is then
connected to its attribute. That is, composite attributes are represented by ellipses that are
connected with an ellipse.

Multivalued attributes are depicted by double ellipse.

Relationship

Relationships are represented by diamond-shaped box. Name of the relationship is written inside
the diamond-box. All the entities (rectangles) participating in a relationship, are connected to it
by a line.

Binary Relationship and Cardinality

39
A relationship where two entities are participating is called a binary relationship. Cardinality is
the number of instance of an entity from a relation that can be associated with the relation.

 One-to-one − When only one instance of an entity is associated with the relationship, it
is marked as '1:1'. The following image reflects that only one instance of each entity
should be associated with the relationship. It depicts one-to-one relationship.

 One-to-many − When more than one instance of an entity is associated with a

relationship, it is marked as '1:N'. The following image reflects that only one instance of
entity on the left and more than one instance of an entity on the right can be associated
with the relationship. It depicts one-to-many relationship.

 Many-to-one − When more than one instance of entity is associated with the
relationship, it is marked as 'N:1'. The following image reflects that more than one
instance of an entity on the left and only one instance of an entity on the right can be
associated with the relationship. It depicts many-to-one relationship.

40
  Many-to-many − The following image reflects that more than one instance of an entity
on the left and more than one instance of an entity on the right can be associated with the
relationship. It depicts many-to-many relationship.

Participation Constraints

 Total Participation − Each entity is involved in the relationship. Total participation is

represented by double lines.
 Partial participation − Not all entities are involved in the relationship. Partial
participation is represented by single lines.

41
Derived attributes are depicted by dashed ellipse.

Cardinality Notations:-
Cardinality specifies how many instances of an entity relate to one instance of another entity.
Ordinality is also closely linked to cardinality. While cardinality specifies the occurances of a
relationship, ordinality describes the relationship as either mandatory or optional. In other words,
cardinality specifies the maximum number of relationships and ordinality specifies the absolute

42
minimum number of relationships. When the minimum number is zero, the relationship is
usually called optional and when the minimum number is one or more, the relationship is usually
called mandatory.
There are many notation styles that express cardinality, those are:

1. Information Engineering:-

2. Chen:-

43
3. Bachman

Martin:-

44
 Experiment No. 5

Aim: Developed all Structure UML diagram of the given project.

The Unified Modeling Language (UML) is a general-purpose, developmental, modeling

language in the field of software engineering, that is intended to provide a standard way to
visualize the design of a system.

UML was originally motivated by the desire to standardize the disparate notational systems and
approaches to software design developed by Grady Booch, Ivar Jacobson and James Rumbaugh
at Rational Software in 1994–95, with further development led by them through 1996.

In 1997 UML was adopted as a standard by the Object Management Group (OMG), and has
been managed by this organization ever since. In 2005 UML was also published by the
International Organization for Standardization (ISO) as an approved ISO standard. Since then it
has been periodically revised to cover the latest revision of UML.

As UML describes the real time systems it is very important to make a conceptual model and
then proceed gradually. Conceptual model of UML can be mastered by learning the following
three major elements:

 UML building blocks

 Rules to connect the building blocks
 Common mechanisms of UML

The building blocks of UML can be defined as:

 Things
 Relationships
 Diagrams

(1) Things:

Things are the most important building blocks of UML. Things can be:

45
  Structural
 Behavioral
 Grouping
 Annotational

Structural things:

The Structural things define the static part of the model. They represent physical and
conceptual elements. Following are the brief descriptions of the structural things.

Class:

Class represents set of objects having similar responsibilities.

Interface:

Interface defines a set of operations which specify the responsibility of a class.

Collaboration:

Collaboration defines interaction between elements.

Use case:

Use case represents a set of actions performed by a system for a specific goal.

Component:

Component describes physical part of a system.

Node:

A node can be defined as a physical element that exists at run time.

46
Behavioral things:

A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral
things:

Interaction:

Interaction is defined as a behavior that consists of a group of messages exchanged among

elements to accomplish a specific task.

State machine:

State machine is useful when the state of an object in its life cycle is important. It defines the
sequence of states an object goes through in response to events. Events are external factors
responsible for state change.

Grouping things:

Grouping things can be defined as a mechanism to group elements of a UML model together.
There is only one grouping thing available:

Package:

Package is the only one grouping thing available for gathering structural and behavioral things.

Annotational things:

Annotational things can be defined as a mechanism to capture remarks, descriptions, and

comments of UML model elements. Note is the only one Annotational thing available.

Note:

A note is used to render comments, constraints etc of an UML element.

47
2) Relationship :

Relationship is another most important building block of UML. It shows how elements are
associated with each other and this association describes the functionality of an application.

There are four kinds of relationships available.

Dependency:

Dependency is a relationship between two things in which change in one element also affects the
other one.

Association:

Association is basically a set of links that connects elements of an UML model. It also describes
how many objects are taking part in that relationship.

Generalization:

Generalization can be defined as a relationship which connects a specialized element with a

generalized element. It basically describes inheritance relationship in the world of objects.

Realization:

Realization can be defined as a relationship in which two elements are connected. One element
describes some responsibility which is not implemented and the other one implements them. This
relationship exists in case of interfaces.

(3) UML Diagrams:

UML diagrams are the ultimate output of the entire discussion. All the elements, relationships
are used to make a complete UML diagram and the diagram represents a system.

The visual effect of the UML diagram is the most important part of the entire process. All the
other elements are used to make it a complete one.

48
UML includes the following nine diagrams and the details are described in the following
chapters.

 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Activity diagram
 Statechart diagram
 Deployment diagram
 Component diagram

Structural diagrams
Structure diagrams depict the static structure of the elements in your system.It shows the things
in the system - classes, objects, packages or modules, physical nodes, components and interfaces.
They also show the relationships between these things - classes that inherit from other classes,
objects that own other objects, what classes belong to what packages, what nodes are connected
to each other.

The four structural diagrams are −

 Class diagram

 Object diagram

 Component diagram

 Deployment diagram

UML - Class Diagram

Overview:

The class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing and documenting different aspects of a
system but also for constructing executable code of the software application.

49
The class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modelling of object oriented
systems because they are the only UML diagrams which can be mapped directly with object
oriented languages.

The class diagram shows a collection of classes, interfaces, associations, collaborations and
constraints. It is also known as a structural diagram.

Purpose:

The purpose of the class diagram is to model the static view of an application. The class
diagrams are the only diagrams which can be directly mapped with object oriented languages and
thus widely used at the time of construction.

The UML diagrams like activity diagram, sequence diagram can only give the sequence flow of
the application but class diagram is a bit different. So it is the most popular UML diagram in the
coder community. So the purpose of the class diagram can be summarized as:

 Analysis and design of the static view of an application.

 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.

How to draw Class Diagram?

Class diagrams are the most popular UML diagrams used for construction of software
applications. So it is very important to learn the drawing procedure of class diagram.

Class diagrams have lot of properties to consider while drawing but here the diagram will be
considered from a top level view. Class diagram is basically a graphical representation of the
static view of the system and represents different aspects of the application. So a collection of
class diagrams represent the whole system.

The following points should be remembered while drawing a class diagram:

50
  The name of the class diagram should be meaningful to describe the aspect of the system.
 Each element and their relationships should be identified in advance.
 Responsibility (attributes and methods) of each class should be clearly identified.
 For each class minimum number of properties should be specified. Because unnecessary
properties will make the diagram complicated.
 Use notes when ever required to describe some aspect of the diagram. Because at the end
of the drawing it should be understandable to the developer/coder.
 Finally, before making the final version, the diagram should be drawn on plain paper and
rework as many times as possible to make it correct.

Now the following diagram is an example of an Order System of an application. So it describes a

particular aspect of the entire application.

 First of all Order and Customer are identified as the two elements of the system and they
have a one to many relationship because a customer can have multiple orders.
 We would keep Order class is an abstract class and it has two concrete classes
(inheritance relationship) SpecialOrder and NormalOrder.
 The two inherited classes have all the properties as the Order class. In addition they have
additional functions like dispatch () and receive ().

So the following class diagram has been drawn considering all the points mentioned above:

51
Where to use Class Diagrams?

Class diagram is a static diagram and it is used to model static view of a system. The static view
describes the vocabulary of the system.

Class diagram is also considered as the foundation for component and deployment diagrams.
Class diagrams are not only used to visualize the static view of the system but they are also used
to construct the executable code for forward and reverse engineering of any system.

Generally UML diagrams are not directly mapped with any object oriented programming
languages but the class diagram is an exception.

Class diagram clearly shows the mapping with object oriented languages like Java, C++ etc. So
from practical experience class diagram is generally used for construction purpose.

So in a brief, class diagrams are used for:

 Describing the static view of the system.

 Showing the collaboration among the elements of the static view.
 Describing the functionalities performed by the system.
 Construction of software applications using object oriented languages.

UML Object Diagram:-

Object diagrams are also closely linked to class diagrams. Just as an object is an instance of a
class, an object diagram could be viewed as an instance of a class diagram. Object diagrams
describe the static structure of a system at a particular time and they are used to test the accuracy
of class diagrams.

Basic Object Diagram Symbols and Notations:-

Object names:- Each object is represented as a rectangle, which contains the name of the object
and its class underlined and separated by a colon.

52
Object attributes:-

As with classes, you can list object attributes in a separate compartment. However, unlike
classes, object attributes must have values assigned to them.

Active object:-

Objects that control action flow are called active objects. Illustrate these objects with a thicker
border.

Multiplicity:-You can illustrate multiple objects as one symbol if the attributes of the individual
objects are not important.

Links:-

Links are instances of associations. You can draw a link using the lines used in class diagrams.

53
Self-linked:-

Objects that fulfill more than one role can be self-linked. For example, if Mark, an administrative
assistant, also fulfilled the role of a marketing assistant, and the two positions are linked, Mark's
instance of the two classes will be self-linked.

UML Component Diagram:-

A component diagram describes the organization of the physical components in a system.

Basic Component Diagram Symbols and Notations:-

Component:-

A component is a physical building block of the system. It is represented as a rectangle with tabs.

Interface:-

An interface describes a group of operations used or created by components.

54
Dependencies:- Draw dependencies among components using dashed arrows.

UML Deployment Diagram:-

Deployment diagrams depict the physical resources in a system including nodes, components,
and connections.

Basic Deployment Diagram Symbols and Notations:-

Component:-

A node is a physical resource that executes code components.

Association:-

Association refers to a physical connection between nodes, such as Ethernet.

55
Components and Nodes:-

Place components inside the node that deploys them.

56
 Experiment No. 6

Aim: Develop Behavior UML diagram of the given project.

Behavioral diagrams

Behavior diagrams depict the dynamic behavior of the elements in your system.
It shows how the system behaves and interacts with itself and other entities (users, other
systems). They show how data moves through the system, how objects communicate with each
other, how the passage of time affects the system, or what events cause the system to change
internal states.

UML has the following five types of behavioral diagrams −

 Use case diagram

 Sequence diagram

 Collaboration diagram

 State chart diagram

 Activity diagram

UML - Use Case Diagrams

Overview

To model a system the most important aspect is to capture the dynamic behaviour. To clarify a
bit in details, dynamic behaviour means the behaviour of the system when it is running
/operating.

So only static behaviour is not sufficient to model a system rather dynamic behaviour is more
important than static behaviour. In UML there are five diagrams available to model dynamic
nature and use case diagram is one of them. Now as we have to discuss that the use case diagram
is dynamic in nature there should be some internal or external factors for making the interaction.

57
These internal and external agents are known as actors. So use case diagrams are consists of
actors, use cases and their relationships. The diagram is used to model the system/subsystem of
an application. A single use case diagram captures a particular functionality of a system.

So to model the entire system numbers of use case diagrams are used.

Purpose

The purpose of use case diagram is to capture the dynamic aspect of a system. But this definition
is too generic to describe the purpose.

Because other four diagrams (activity, sequence, collaboration and Statechart) are also having
the same purpose. So we will look into some specific purpose which will distinguish it from
other four diagrams.

Use case diagrams are used to gather the requirements of a system including internal and
external influences. These requirements are mostly design requirements. So when a system is
analyzed to gather its functionalities use cases are prepared and actors are identified.

Now when the initial task is complete use case diagrams are modelled to present the outside
view.

So in brief, the purposes of use case diagrams can be as follows:

 Used to gather requirements of a system.

 Used to get an outside view of a system.
 Identify external and internal factors influencing the system.
 Show the interacting among the requirements are actors.

How to draw Use Case Diagram?

Use case diagrams are considered for high level requirement analysis of a system. So when the
requirements of a system are analyzed the functionalities are captured in use cases.

58
So we can say that use cases are nothing but the system functionalities written in an organized
manner. Now the second things which are relevant to the use cases are the actors. Actors can be
defined as something that interacts with the system.

The actors can be human user, some internal applications or may be some external applications.
So in a brief when we are planning to draw an use case diagram we should have the following
items identified.

 Functionalities to be represented as an use case

 Actors
 Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system. So after
identifying the above items we have to follow the following guidelines to draw an efficient use
case diagram.

 The name of a use case is very important. So the name should be chosen in such a way so
that it can identify the functionalities performed.
 Give a suitable name for actors.
 Show relationships and dependencies clearly in the diagram.
 Do not try to include all types of relationships. Because the main purpose of the diagram
is to identify requirements.
 Use note when ever required to clarify some important points.

The following is a sample use case diagram representing the order management system. So if we
look into the diagram then we will find three use cases (Order, SpecialOrder and NormalOrder)
and one actor which is customer.

The SpecialOrder and NormalOrder use cases are extended from Order use case. So they have
extends relationship. Another important point is to identify the system boundary which is shown
in the picture. The actor Customer lies outside the system as it is an external user of the system.

59
Where to Use Case Diagrams?

As we have already discussed there are five diagrams in UML to model dynamic view of a
system. Now each and every model has some specific purpose to use. Actually these specific
purposes are different angles of a running system.

So to understand the dynamics of a system we need to use different types of diagrams. Use case
diagram is one of them and its specific purpose is to gather system requirements and actors.

Use case diagrams specify the events of a system and their flows. But use case diagram never
describes how they are implemented. Use case diagram can be imagined as a black box where
only the input, output and the function of the black box is known.

These diagrams are used at a very high level of design. Then this high level design is refined
again and again to get a complete and practical picture of the system. A well structured use case
also describes the pre condition, post condition, exceptions. And these extra elements are used to
make test cases when performing the testing.

Although the use cases are not a good candidate for forward and reverse engineering but still
they are used in a slight different way to make forward and reverse engineering. And the same is

60
true for reverse engineering. Still use case diagram is used differently to make it a candidate for
reverse engineering.

In forward engineering use case diagrams are used to make test cases and in reverse engineering
use cases are used to prepare the requirement details from the existing application.

So the following are the places where use case diagrams are used:

 Requirement analysis and high level design.

 Model the context of a system.
 Reverse engineering.
 Forward engineering.

The Sequence Diagram:

The sequence diagram is having four objects (Customer, Order, SpecialOrder and NormalOrder).

The following diagram has shown the message sequence for SpecialOrder object and the same
can be used in case of NormalOrder object. Now it is important to understand the time sequence
of message flows. The message flow is nothing but a method call of an object.

The first call is sendOrder () which is a method of Order object. The next call is confirm ()
which is a method of SpecialOrder object and the last call is Dispatch () which is a method of
SpecialOrder object. So here the diagram is mainly describing the method calls from one object
to another and this is also the actual scenario when the system is running.

61
Where to use Interaction Diagrams?

We have already discussed that interaction diagrams are used to describe dynamic nature of a
system. Now we will look into the practical scenarios where these diagrams are used. To
understand the practical application we need to understand the basic nature of sequence and
collaboration diagram.

The main purposes of both the diagrams are similar as they are used to capture the dynamic
behaviour of a system. But the specific purposes are more important to clarify and understood.

Sequence diagrams are used to capture the order of messages flowing from one object to another.
And the collaboration diagrams are used to describe the structural organizations of the objects
taking part in the interaction. A single diagram is not sufficient to describe the dynamic aspect of
an entire system so a set of diagrams are used to capture is as a whole.

62
The interaction diagrams are used when we want to understand the message flow and the
structural organization. Now message flow means the sequence of control flow from one object
to another and structural organization means the visual organization of the elements in a system.

In a brief the following are the usages of interaction diagrams:

 To model flow of control by time sequence.

 To model flow of control by structural organizations.
 For forward engineering.
 For reverse engineering.

UML Collaboration Diagram:-

A collaboration diagram describes interactions among objects in terms of sequenced messages.

Collaboration diagrams represent a combination of information taken from class, sequence, and
use case diagrams describing both the static structure and dynamic behavior of a system.

Basic Collaboration Diagram Symbols and Notations:-

Class roles:-

Class roles describe how objects behave. Use the UML object symbol to illustrate class roles, but
don't list object attributes.

Association roles:-

Association roles describe how an association will behave given a particular situation. You can
draw association roles using simple lines labeled with stereotypes.

63
Messages:-

Unlike sequence diagrams, collaboration diagrams do not have an explicit way to denote time
and instead number messages in order of execution. Sequence numbering can become nested
using the Dewey decimal system. For example, nested messages under the first message are
labeled 1.1, 1.2, 1.3, and so on. The a condition for a message is usually placed in square
brackets immediately following the sequence number. Use a * after the sequence number to
indicate a loop.

State chart Diagram:-

A statechart diagram shows the behavior of classes in response to external stimuli. This diagram
models the dynamic flow of control from state to state within a system.

Basic Statechart Diagram Symbols and Notations:-

States:-

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

64
Transition:-

A solid arrow represents the path between different states of an object. Label the transition with
the event that triggered it and the action that results from it.

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. A short
heavy bar with two transitions leaving it represents a splitting of control that creates multiple
states.

65
UML - Activity Diagrams

Overview:

Activity diagram is another important diagram in UML to describe dynamic aspects of the
system.

Activity diagram is basically a flow chart to represent the flow form one activity to another
activity. The activity can be described as an operation of the system.

So the control flow is drawn from one operation to another. This flow can be sequential,
branched or concurrent. Activity diagrams deals with all type of flow control by using different
elements like fork, join etc.

Purpose:

The basic purposes of activity diagrams are similar to other four diagrams. It captures the
dynamic behaviour 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 is a particular operation of the system. Activity diagrams are not only used for
visualizing dynamic nature of a system but they are also used to construct the executable system
by using forward and reverse engineering techniques. The only missing thing in activity diagram
is the message part.

66
It does not show any message flow from one activity to another. Activity diagram is some time
considered as the flow chart. Although the diagrams looks like a flow chart but it is not. It shows
different flow like parallel, branched, concurrent and single.

So the purposes can be described as:

 Draw the activity flow of a system.

 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the system.

How to draw Activity Diagram?

Activity diagrams are mainly used as a flow chart consists of activities performed by the system.
But activity diagram are not exactly a flow chart as they have some additional capabilities. These
additional capabilities include branching, parallel flow, swimlane etc.

Before drawing an activity diagram we must have a clear understanding about the elements used
in activity diagram. The main element of an activity diagram is the activity itself. An activity is a
function performed by the system. After identifying the activities we need to understand how
they are associated with constraints and conditions.

So before drawing an activity diagram we should identify the following elements:

 Activities
 Association
 Conditions
 Constraints

Once the above mentioned parameters are identified we need to make a mental layout of the
entire flow. This mental layout is then transformed into an activity diagram.

The following is an example of an activity diagram for order management system. In the diagram
four activities are identified which are associated with conditions. One important point should be

67
clearly understood that an activity diagram cannot be exactly matched with the code. The activity
diagram is made to understand the flow of activities and mainly used by the business users.

The following diagram is drawn with the four main activities:

 Send order by the customer

 Receipt of the order
 Confirm order
 Dispatch order

After receiving the order request condition checks are performed to check if it is normal or
special order. After the type of order is identified dispatch activity is performed and that is
marked as the termination of the process.

68
Where to use Activity Diagrams?

The basic usage of activity diagram is similar to other four UML diagrams. The specific usage is
to model the control flow from one activity to another. This control flow does not include
messages.

The activity diagram is suitable for modeling the activity flow of the system. An application can
have multiple systems. Activity diagram also captures these systems and describes flow from one
system to another. This specific usage is not available in other diagrams. These systems can be
database, external queues or any other system.

Now we will look into the practical applications of the activity diagram. From the above
discussion it is clear that an activity diagram is drawn from a very high level. So it gives high
level view of a system. This high level view is mainly for business users or any other person who
is not a technical person.

This diagram is used to model the activities which are nothing but business requirements. So the
diagram has more impact on business understanding rather implementation details.

Following are the main usages of activity diagram:

 Modeling work flow by using activities.

 Modeling business requirements.
 High level understanding of the system's functionalities.
 Investigate business requirements at a later stage.

69
 Experiment No. 7

Aim: Manage file, using ProjectLibre project management software tool.

Overview Presentation

ProjectLibre is the leading open source alternative to MS Project. It is a free downloadable

project management software that is compatible with several versions of Project. Users can open
the software on Windows, Mac OS, and Linux platforms. As of August 2018, it has passed 3.5
million downloads, and has been adopted in over 200 countries. An enterprise cloud version
coming soon will be offered on a simple monthly subscription. The cloud version is best for
teams and for multiple project management.
Features, Benefits, Product Strengths

 MS Project Compatibility – ProjectLibre is compatible with Microsoft Project 2003, 2007,

and 2010, so it will open these files. It also has import/export capabilities. A similar ribbon
UI allows users familiar with MS Project to easily transition to ProjectLibre. In creating a
project plan, they can use a similar approach, such as listing and indenting a task list or
work breakdown structure. They can set durations, links, predecessors, and resources in a
similar manner. They can also create budgets and manage expenses with the software. The
latest version is 1.8.0 modified in May 2018.
 Core PM Functionality – This open source alternative software includes features such as
Gantt charts, network diagrams, work breakdown structure charts, resource breakdown
structure charts, earned value costing, and resource histograms. These are also comparable
to features in Microsoft Project. Users can set dependencies, create a project baseline, and
use multiple calendar to define working and non-working days for different resources. It
also has reporting functionality, such as for displaying project details, resource information,
task information, and others.
 Enterprise Cloud – ProjectLibre is busy finalizing a cloud version. It will extend the open
source desktop software to a cloud version that can be accessed anytime and anywhere.
Unlike the single-user desktop version, the cloud version will be capable of handling
multiple projects by multiple users. Thus, simple project portfolio management features will

70
 also be available. A team dashboard will allow project collaboration from members in
different locations. Pricing will be offered on a simple monthly subscription.

Pricing

ProjectLibre is released under the Common Public Attribution License and qualifies as free
software. The developers accept donations for development efforts.

Social Network Presence

 Facebook
 Twitter

Target Market

ProjectLibre is for small to mid-sized businesses that have single project requirements.

Supported Language

Aside from English, ProjectLibre has been translated to Arabic, Chinese (Simplified), Czech,
Dutch, French, Finnish, Galician, German, Hindi, Italian, Japanese, Korean, Persian, Portuguese,
Slovak, Spanish, Swedish, Russian, and Ukranian.

Some of their Clients

Clients include The Clinton Foundation, Giorgio Armani, McKesson, Abbot, IBM, Turner, ST
Microelectronics, Flextronics, Kiewit, Accenture, EADS, Cisco, AMD, Caterpillar, Medtronic,
Boeing, and Husqvarna.

Why ProjectLibre

Users who are looking for a free open source alternative to MS Project but do not want a to learn
how to use a new application can check ProjectLibre. An affordable cloud version that handles
multi-project for multi-users will be available soon. Requests to be included in the beta of the
cloud version can now be sent.

71