SOFTWARE ENGINEERING

OBSERVATION NOTES

Submitted in partial fulfillment of the

requirements for the award of the degree Of

-BACHELOR OF TECHNOLOGY-
In
Computer Science engineering
By
Shreya
(18001012022)

Guided by

IGDTUW- Faculty: Mr. Indra Tanaya

1
 INDEX

Lab Experiment Page Date

No. No.
1. Software Requirement Specification 3-9 09/08/23
2. E-R Modelling 10-15 16/08/23
3. Modeling Data Flow Diagrams 16-18 23/08/23
4. Modeling UML diagrams and Use Case 19-22 30/08/23
Scenarios

5. Identify Domain Classes 23-26 13/09/23

6. State Chart and Activity Modelling 27-31 27/09/23
7. Modeling UML Class Diagrams and 32-36 04/09/23
Sequence Diagrams

2
 LAB WORK-I

-------------------------------------------------------------------------------------------------------------
Title: Identifying the Requirements from Problem Statements
Objective To perform the Requirement analysis of the specified problem and draw a flow
chart
-------------------------------------------------------------------------------------------------------------
References: An Integrated Approach To Software Engineering
Pankaj Software Engineering K.K Aggarwal &
Yogesh Singh Software Engineering Roger Pressman
McGraw Hill
Visual Modeling with Rational Rose 2000 and UML Terry Quatrani.

Theory:
Identifying requirements from problem statements is a crucial step in the software development
process. Requirements serve as the foundation for designing and building a solution that
addresses the stated problem. Here are the steps to help you identify requirements from problem
statements effectively:
1. Read and Understand the Problem Statement:
Begin by thoroughly reading and comprehending the problem statement. Ensure that
you have a clear understanding of what the problem is and what needs to be solved.

2. Identify Stakeholders:
Determine who the stakeholders are - these are the individuals or groups who have an
interest in the problem and its potential solution. This could include end-users, clients,
managers, and other relevant parties.

3. Gather Information from Stakeholders:

Engage with the stakeholders to gather more insights into the problem. Conduct
interviews, surveys, or workshops to understand their needs, expectations, and any
constraints they might have.

4. Classify Requirements:
Categorize the identified information into different types of requirements:
a. Functional Requirements: These describe what the system should do. They are
typically expressed as features or functions that the system must provide to meet the
stakeholders' needs.
b. Non-Functional Requirements: These describe the quality attributes or
characteristics the system must possess. Common non-functional requirements include
performance, security, scalability, usability, and reliability.
c. Constraints: These are limitations or restrictions that must be adhered to during the
development process. Constraints can include budget limitations, technology choices,
or regulatory requirements.

3
 5. Prioritize Requirements:
Not all requirements are of equal importance. Work with stakeholders to prioritize
requirements based on their criticality and impact on the project's success. Use
techniques like MoSCoW (Must-have, Should-have, Could-have, Won't-have) to
prioritize.
6. Document Requirements:
Create detailed documentation for each requirement. Include a clear description,
acceptance criteria, dependencies, and any relevant diagrams or mock-ups to provide a
comprehensive understanding.

7. Validate Requirements:
Review the documented requirements with stakeholders to ensure they accurately
represent their needs and expectations. Make necessary revisions based on their
feedback.

8. Maintain Traceability:
Establish traceability between requirements and the problem statement. This helps
ensure that each requirement can be traced back to the specific problem it addresses.

9. Manage Changes:
Be prepared for changes in requirements as the project progresses. Implement a change
management process to evaluate and accommodate new requirements or modifications
to existing ones.

10. Review and Verification:

Regularly review and verify that the developed solution aligns with the documented
requirements. This helps ensure that the project stays on track and that the final product
meets stakeholders' expectations.

11. Communication:
Maintain open and consistent communication with stakeholders throughout the project
to address any questions, concerns, or changes related to the requirements.

12. Documentation and Tracking:

Use appropriate tools and methodologies to document and track requirements
throughout the project's lifecycle. Requirements management tools and version control
systems can be valuable in this regard.

By following these steps, you can effectively identify and manage requirements from problem
statements, which is essential for the successful delivery of a solution that meets stakeholders'
needs.

4
Requirements and Their Characteristics:
- A requirement is a specification of what should be implemented in a system.
- Requirements define how the system should behave, outlining what it should do but not how
to do it.
- Requirements engineering involves understanding customer expectations and documenting
them in a readable format.
- Clear requirements are crucial to avoid problems and customer dissatisfaction.

Characteristics of Requirements:
1. Unambiguity: Requirements should be clear and not open to interpretation.
2. Consistency: Requirements should not contradict each other.
3. Completeness: Requirements should cover what the system should and should not do.

Categorization of Requirements:
- User requirements: Written in natural language for customers to verify their expectations.
- System requirements: Technical and specification-oriented, intended for development and
testing teams.
- Requirements can be classified into functional and non-functional types.

Functional Requirements (FRs):

- Describe how the system reacts to inputs and the corresponding outputs.
- Focus on the system's functionality and behavior.

Non-Functional Requirements (NFRs):

- Define how the system behaves under certain conditions.
- Classified into product, performance, and organizational requirements.

Identifying Functional Requirements:

- High-level functional requirements can be deduced from the problem's conceptual
understanding.
- Identify cases where users achieve meaningful tasks using the system.
- Consider the system as a black box with inputs and outputs to define its functionalities.

5
- High-level requirements might have sub-requirements based on user classes or scenarios.

Preparing Software Requirements Specifications (SRS):

- Once complete, consistent, and unambiguous FRs and NFRs are identified, an SRS is
prepared.
- The SRS is a legal agreement between the client and the service provider.
- It outlines what the system will contain and the agreed-upon features.
- The SRS serves as a reference during development and deployment to avoid discrepancies.

Extracting Functional Requirements from a Problem Statement: A Case Study of an

Online Voting System

The advent of the internet has sparked discussions around e-democracy and online voting, with
some envisioning the internet as a potential replacement for representative democracy. This
could empower individuals to participate in voting on various issues through online platforms.
Online voting holds the promise of reducing costs and enhancing convenience for voters. This
approach finds application in e-democracy as well as in situations where multiple alternatives
require a final decision. Online voting relies on secure authentication methods due to the need
for ensuring the integrity of the process. Consequently, security measures become a critical
requirement, encompassing aspects such as obtaining, marking, delivering, and counting
ballots via computer systems.

Key Points:
1. Enhanced Convenience and Voter Turnout: Online voting offers the advantage of increased
voter turnout due to its convenience, potentially making participation more accessible to a
wider range of people.
2. Cost Reduction and Convenience: By allowing voters to participate from remote locations
and eliminating the need for physical infrastructure, online voting has the potential to reduce
costs associated with traditional voting methods.
3. Addressing Security Concerns: Given the reliance on the internet, security becomes
paramount. The system must ensure secure authentication to prevent unauthorized access and
tampering of votes.
4. Holistic Ballot Lifecycle: The system needs to support the entire lifecycle of a ballot,
including its issuance, marking, delivery, and secure counting, all carried out through computer
systems.

6
5. Fraud Prevention: Online voting should have mechanisms in place to detect and prevent
fraudulent voting attempts, safeguarding the integrity of the electoral process.
6. Support for Alternative Solutions: The system must allow for handling situations where
multiple alternatives are presented, requiring voters to choose from different options.
7. Ease of Use: User-friendly interfaces should be designed to ensure that individuals of varying
technical proficiencies can easily navigate the online voting platform.
8. Robust Data Privacy: The system must ensure the confidentiality of voters' choices and
personal information, adhering to data protection regulations.
9. Scalability and Reliability: The system needs to be scalable to accommodate a potentially
large number of voters and reliable to prevent downtimes during critical voting periods
10. Auditability and Transparency: The system should provide means for auditing the voting
process, allowing for transparency and accountability in case of disputes or doubts about the
results.

Functional Requirements:
- User Authentication: Implement secure authentication mechanisms to verify the identity of
voters and prevent unauthorized access.
- Ballot Issuance: Provide a process for distributing ballots to eligible voters electronically,
ensuring the correct recipients receive the appropriate ballots.
- Vote Marking: Allow voters to mark their choices electronically on the ballot in a clear and
intuitive manner.
- Ballot Delivery: Facilitate the secure delivery of marked ballots to a central location for
counting and verification.
- Vote Counting: Design a system capable of accurately and securely tallying the votes received
from various sources.
- Fraud Detection: Incorporate algorithms and techniques to detect and prevent fraudulent
voting activities.
- Alternative Handling: Develop functionality to present and manage different alternatives for
voting on specific issues.
- User-Friendly Interface: Design an intuitive user interface to accommodate a diverse range
of users, including those with limited technical skills.
- Data Privacy: Ensure the confidentiality of voter information and choices in compliance with
privacy regulations.
- Scalability and Reliability: Build a robust and scalable architecture to handle varying loads
and prevent system failures during critical periods.
- Audit Trail: Establish mechanisms for tracking and auditing the voting process to ensure
transparency and accountability.

7
- Result Declaration: Provide a secure and accurate method for announcing the final voting
results to the public.

In conclusion, an online voting system holds the potential to revolutionize the democratic
process by enhancing convenience, reducing costs, and increasing participation. However, to
realize these benefits, the system must fulfill a comprehensive set of functional requirements
to address security, ease of use, fraud prevention, and the successful execution of the entire
voting process through digital means.

Development of a Library Information System (LIS) for SE VLabs Institute: Functional

and Non-Functional Requirements Analysis
The SE VLabs Institute, established to provide cutting-edge research facilities in Software
Engineering, aims to enhance its capabilities through the creation of a Library Information
System (LIS). The proposed LIS seeks to streamline book transactions for students, professors,
and employees by enabling online borrowing and returning. The system will be developed as
a web application, exclusively accessible within the institute's LAN, to ensure security and
convenience. Let's delve into the functional and non-functional requirements of this system.

Functional Requirements:
1. New User Registration (R1 - High Priority): Institute members can register with the LIS to
avail library facilities. Upon successful registration, users receive a unique user ID and a
password for future transactions.
2. User Login (R2 - High Priority): Registered users log in using their employee ID and
password. After successful login, users access the "Home" page to perform various functions.
3. Search Book (R3 - High Priority): Members can search for books by title, author's name, or
publisher's name. Non-members can browse/search books online.
4. Issue Book (R4 - High Priority): Members can borrow books if they are available and if they
haven't reached the maximum allowed limit (four for students and research scholars, ten for
professors).
5. Return Book (R5 - High Priority): Borrowed books must be returned within 20 days. Upon
successful return, user accounts are updated.
6. Reissue Book (R6 - Low Priority): Users can reissue a book for an additional 20 days, but
only twice. User accounts reflect the updated information.

Non-Functional Requirements:
1. Performance Requirements:
- The system must remain accessible 24x7 to cater to users at any time.

8
 - Concurrent access should support a minimum of 50 users to ensure smooth performance.
2. Security Requirements:
- The system should operate exclusively within the institute's LAN to ensure restricted access.
- Passwords must not be stored in plain text; hashed values are to be stored for enhanced
security.

Software Quality Attributes:

1. Reliability: The system must accurately record book transactions and account updates,
ensuring consistent user experiences.
2. Usability: The user interface should be intuitive, accommodating users with varying
technical proficiency.
3. Scalability: The system should be designed to handle increasing user loads without
compromising performance.
4. Maintainability: The application code should be well-organized and documented, facilitating
future updates and improvements.
Database Requirements:
- The database should efficiently manage user profiles, book records, transactions, and security
information.

Design Constraints:
- The LIS must be developed as a web application compatible with Firefox 5, Internet Explorer
8, Google Chrome 12, and Opera 10.
- The system should be designed using HTML 5 to incorporate modern web development
standards.

With the identification of both functional and non-functional requirements, a Software

Requirements Specification (SRS) document is prepared. This document acts as a legal
agreement between the client and service provider, ensuring that all system aspects are clearly
outlined and understood.

9
 LAB WORK - II
------------------------------------------------------------------------------------------------------------------
Title: Draw E-R diagram for the specified system
Objective: To draw the ER-Diagram with generalization, specialization and aggregation.
-------------------------------------------------------------------------------------------------------------

References: An Integrated Approach To Software Engineering

Pankaj JaloteSoftware Engineering K.K Aggarwal &
Yogesh Singh Software Engineering Roger Pressman
McGraw Hill
Visual Modeling with Rational Rose 2000 and UML Terry Quatrani

Theory:
An entity-relationship model (ERM) is an abstract and conceptual representation of
data. Entity-relationship modeling is a database modeling method, used to produce a
type of conceptual schema or semantic data model of a system, often a relational
database, and its requirements in a top-down fashion. Diagrams created by this process
are called entity- relationship diagrams, ER diagrams, or ERDs. The building blocks:
entities, relationships, and attributes.

Database Development and ER Modeling: A Comprehensive Overview

Introduction
Database development plays a pivotal role in system design. Before diving into
creating database tables and relationships, conceptual modeling using Entity-
Relationship (ER) diagrams aids in laying the foundation for an efficient database
structure. This experiment explores the process of identifying entities, attributes, and
relationships, culminating in the creation of an ER diagram.

Objectives
The experiment aims to achieve the following objectives:
1. Identify entity sets, attributes, and relationships within a system.
2. Represent the data model through an ER diagram.

Entity-Relationship Model
The Entity-Relationship (ER) model serves as a blueprint for structuring databases
logically. It abstracts real-world objects into entities and represents their possible
connections as relationships. For example, in a school system, students and schools are
entities, connected by the "Studies in" relationship. Similarly, a job and a database are
entities linked by the "Updates" relationship.

Entity Sets and Relationship Sets

An entity set comprises similar entities. For instance, the "Student" entity set
encompasses individual students like Ram and John. Relationship sets represent similar
connections. Attributes describe entity characteristics, and each entity can be defined
by one or more attributes. For instance, a student's attributes include name, age, and
address.

10
 Keys
Keys help uniquely identify entities within a set. Super keys combine attributes to
distinguish entities, while candidate keys are minimal subsets of super keys. The
primary key is chosen from candidate keys for database implementation. Prime
attributes are part of super keys.

Weak Entity
A weak entity is reliant on another entity set for identification and lacks a super key.
For example, in a company's system, the "Family" entity depends on the "Employee"
entity for existence.

Mapping Cardinalities

ER modeling establishes relationships between entity sets. Mapping cardinalities

define how entities are associated:

- One-to-one: Entities relate uniquely in both sets.

- One-to-many: Entities in one set relate to multiple entities in another set.
- Many-to-one: Multiple entities in one set relate to one entity in another set.
- Many-to-many: Multiple entities in both sets relate to each other.
Cardinality

One-to-one 1 1

One-to-many
1 n

Many-to-Many
n m

Participation

Total

(Mandatory)

Partial

(Optional)

Entity Generalization and Specialization

Entities can have commonalities leading to generalization and specialization. In a
banking system, customers and employees are persons with specific roles, forming a
hierarchy.

11
ER Diagram

An ER diagram visually represents entities, attributes, and relationships. Entities are

depicted as rectangles, attributes as ellipses, and relationships as diamonds. Various
notations denote attributes' roles and primary keys.

Importance of ER Modeling

ER modeling is a crucial step in implementing relational databases. The process

involves identifying entities, attributes, and relationships based on a problem
statement. ER diagrams facilitate the creation of table structures, constraint
establishment, and normalization for data integrity and efficiency.

Example: Library Information System ER Model

The Library Information System manages book transactions. The "Member" entity
encompasses students, professors, and employees, with attributes like employee ID and
contact details. The "Book" entity has attributes such as title and author. A unique ID
serves as the primary key for "Book" entities. In an ER model, entities are the main
objects or concepts within a system, and attributes define the properties or
characteristics of those entities. Relationships depict how entities are connected to each
other. Let's break it down:

Entities:
1. Book:
- Attributes: Place , Title, Author(s), Status , Book Barcode number.

2. User:
- Attributes: User ID , Name, Branch, Phone Number, Address, No. of books issued.

3. Admin:
- Attributes: Admin ID, Name, Phone Number.

4. Book Record:
- Attributes: Update record, Add record, Delete record, Total books available.

5. Login:
- Attributes: Login ID, Password.

Attributes:
- Title: Title of the book.
- Author(s): Author(s) of the book.
- Name: Name of the author.
- User ID: Unique identifier for library users.
- Phone Number: Phone number of the user.
- Address: Address of the user.
- Admin ID: Unique identifier for library staff.

12
Relationships:

- User borrow Book (One-to-Many).

- Book issued by Admin (One -to-Many).
- Admin Maintains Book record (One -to-Many).
- User gets books issued from (Many-to-One).
- User have to login (Many-to-One).
- Admin have to Login (One -to - many).

This ER model represents the key entities, attributes, and relationships within a Library
Information System, providing a foundation for designing a database to manage
library-related operations efficiently.

Student Result Management System

13
Example: Cab Management System

Entities:

1. Cab:
- Attributes: Cab ID, Model, Seats.

2. Driver:
- Attributes: Name, Phone Number, License Number.

3. Passenger:
- Attributes: Name, Phone Number, Place, Start Time, Destination.

4. Agency:
- Attributes: Name, Address, Registration number.

Attributes:

- Cab ID: Unique identifier for cabs.

- Registration Number: License plate number of the cab.
- Model: Model of the cab.
- Phone Number: Contact number of the driver or user.
- License Number: Driver's license number.
- Address: Address of the user.
- Name: Name of the location (e.g., street name, landmark).
- Address: Address of the location.

Relationships:

- Driver drives cab (Many-to-Many).

- Agency owns cab (One-to-Many).
- Passenger books cab (Many-to-Many).
- Driver returns receipt to passenger (One-to-Many).
- Driver submits receipt to agency (Many-to-One).
- Agency hires driver (One-to-Many).

This ER model captures the main entities, attributes, and relationships in a Cab
Management System. It serves as a foundation for designing a database that efficiently
handles cab bookings, driver assignments, user information, and location data.

14
Conclusion

In conclusion, the Entity-Relationship (ER) diagram provides a comprehensive visual

representation of the essential components of a system, their attributes, and the
relationships that exist among them. Through the ER diagram, we have established a
structured framework for understanding the underlying data model of the system,
which is crucial for effective database design and management.

The ER diagram highlights the key entities within the system, such as cabs, drivers,
users, bookings, and locations, each characterized by their specific attributes that define
their properties. The relationships established between these entities illustrate how they
interact and depend on each other to fulfill the system's functionalities.

Furthermore, the ER diagram offers a valuable blueprint for the development of a

robust database that can efficiently store, retrieve, and manage data. It serves as a
foundational step in the software development life cycle, guiding the creation of
databases and aiding in the implementation of the system.

The ER diagram serves as a common language between developers, designers,

stakeholders, and users. It conveys complex data relationships in a visually intuitive
manner, making it easier to communicate ideas and concepts across the development team.

15
 LAB WORK-III

------------------------------------------------------------------------------------------------------------------
Title: Design of the System modeling.
Objective: Understanding of System modeling: Functional modeling: DFD level 0, l
i .e. Context Diagram and perform it.

References: An Integrated Approach To Software Engineering

Pankaj JaloteSoftware Engineering K.K Aggarwal &
Yogesh Singh Software Engineering Roger Pressman
McGraw Hill
Visual Modeling with Rational Rose 2000 and UML Terry Quatrani

Theory:
A Data Flow Diagram (DFD) is a traditional visual representation of the information flows
within a system. A neat and clear DFD can depict the right amount of the system
requirement graphically. It can be manual, automated, or a combination of both.
It shows how data enters and leaves the system, what changes the information, and where
data is stored.
The objective of a DFD is to show the scope and boundaries of a system as a whole. It may
be used as a communication tool between a system analyst and any person who plays a part
in the order that acts as a starting point for redesigning a system. The DFD is also called as
a data flow graph or bubble chart.

The following observations about DFDs are essential:

1. All names should be unique. This makes it easier to refer to elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows is a flow chart that represents the order
of events; arrows in DFD represents flowing data. A DFD does not involve any order
of events.
3. Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in a
DFD, suppress that urge! A diamond-shaped box is used in flow charts to represents
decision points with multiple exists paths of which the only one is taken. This implies
an ordering of events, which makes no sense in a DFD.
4. Do not become bogged down with details. Defer error conditions and error handling
until the end of the analysis.

Standard symbols for DFDs are derived from the electric circuit diagram analysis and are
shown in fig:
External entity

Process

Control flow
Data Flow

16
 Data store

Data Flow Diagrams

1. Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.

2. Data Flow: A curved line shows the flow of data into or out of a process or data store.

3. Data Store: A set of parallel lines shows a place for the collection of data items. A
data store indicates that the data is stored which can be used at a later stage or by the
other processes in a different order. The data store can have an element or group of
elements.

4. Source or Sink: Source or Sink is an external entity and acts as a source of system
inputs or sink of system outputs.

Levels in Data Flow Diagrams (DFD)

The DFD may be used to perform a system or software at any level of abstraction. Infact,
DFDs may be partitioned into levels that represent increasing information flow and
functional detail. Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see
primarily three levels in the data flow diagram, which are: 0-level DFD, 1-level DFD, and
2-level DFD.

0-level DFDM:

It is also known as fundamental system model, or context diagram represents the entire
software requirement as a single bubble with input and output data denoted by incoming
and outgoing arrows. Then the system is decomposed and described as a DFD with
multiple bubbles. Parts of the system represented by each of these bubbles are then
decomposed and documented as more and more detailed DFDs. This process may be
repeated at as many levels as necessary until the program at hand is well understood. It is
essential to preserve the number of inputs and outputs between levels, this concept is called
leveling by DeMacro. Thus, if bubble "A" has two inputs x1 and x2 and one output y, then
the expanded DFD, that represents "A" should have exactly two external inputs and one
external output as shown in fig:

Data Flow Diagrams

The Level-0 DFD, also called context diagram of the result management system is shown
in fig. As the bubbles are decomposed into less and less abstract bubbles, the
corresponding data flow may also be needed to be decomposed

17
1-level DFD

Data Flow Diagrams

In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In this

level, we highlight the main objectives of the system and breakdown the high-level process
of 0-level DFD into subprocesses.
Data Flow Diagrams

2-Level DFD

2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to project or
record the specific/necessary detail about the system's functioning.

18
 LAB WORK-IV

------------------------------------------------------------------------------------------------------------------
Title: Modeling UML Use Case Diagrams and Capturing Use Case Scenarios
Objective: “Creating Use Case Diagrams and Scenario Capture"
------------------------------------------------------------------------------------------------------------------

References: An Integrated Approach To Software Engineering

Pankaj JaloteSoftware Engineering K.K Aggarwal &
Yogesh Singh Software Engineering Roger Pressman
McGraw Hill
Visual Modeling with Rational Rose 2000 and UML Terry Quatrani

Modeling UML Use Case Diagrams and Capturing Use Case Scenarios

USE CASE DIAGRAM

A use case diagram is a graphical representation of how users interact with a system. It shows
the different types of users and use cases for a system. Use cases are sets of actions, services,
and functions that a system needs to perform. Actors are represented by stick figures and can
be people, organizations, or external systems. Use case diagrams are often used to analyze
systems and can be used to identify tests for a system during the testing phase.
Use case diagrams are a type of UML diagram. They are used to represent the dynamic
behavior of a system. Dynamic behavior is the behavior of a system when it is running or
operating.

Actor:
In a use-case diagram, users of the system are depicted as actors. Each actor performs a specific
role in the system, which is called a use-case. More than one actor can perform a single use-
case. An actor can be a person, such as a customer, or a computer, such as a database system
or server.

Actors can be classified as below:

Primary actor: They are principal users of the system, who fulfill their goal by availing some
service from the system. For example, a customer uses an ATM to withdraw cash when he
needs it. A customer is the primary actor here.
Supporting actor: They render some kind of service to the system. "Bank representatives",
who replenishes the stock of cash, is such an example. It may be noted that replenishing stock
of cash in an ATM is not the prime functionality of an ATM.

19
Use Case:
A use case is simply a functionality provided by a system. Continuing with the example of the
ATM, withdraw cash is a functionality that the ATM provides. Therefore, this is a use case.
Other possible use cases include, check balance, change PIN, and so on. Use cases include both
successful and unsuccessful scenarios of user interactions with the system. For example,
authentication of a customer by the ATM would fail if he enters wrong PIN. In such case, an
error message is displayed on the screen of the ATM.
Subject:
The subject of a use case diagram is the system or part of a system that the diagram represents.
The subject provides a context for the definition of the system. For example, an ATM is a
subject, having multiple use cases, and multiple actors interact with it.

GRAPHICAL REPRESENTATION
An actor is represented by a stick figure and name of the actor is written below it. A use case
is depicted by an ellipse and name of the use case is written inside it. The subject is shown by
drawing a rectangle. Label for the system could be put inside it. Use cases are drawn inside the
rectangle, and actors are drawn outside the rectangle.

ASSOCIATION BETWEEN ACTORS AND USE CASES

A use case is triggered by an actor. Actors and use cases are connected through binary
associations indicating that the two communicates through message passing.
An actor must be associated with at least one use-case. Similarly, a given use case must be
associated with at least one actor. Association among the actors are usually not shown.
However, one can depict the class hierarchy among actors.

20
RELATIONSHIPS BETWEEN ACTORS AND USE-CASES
Use-cases could be organized using following relationships −
· Generalization
· Extend
· Include

Generalization between Use-Cases

There may be instances where actors are associated with similar use-cases. In such case a Child
use-case inherits the properties and behavior of the parent use. Hence, we need to generalize
the actor to show the inheritance of functions. They are represented by a solid line with a large
hollow triangle arrowhead.

Extend
There are some functions that are triggered optionally. In such cases the extend relationship is
used and the extension rule is attached to it. Thing to remember is that the base use-case should
be able to perform a function on its own even if the extending use-case is not called Extend
relationship is shown as a dashed line with an open arrowhead directed from the extending use-
case to the extended (base) use-case. The arrow is labelled with the keyword «extend».

21
Include
It is used to extract use-case fragments that are duplicated in multiple use-cases. It is also used
to simplify large use-case by splitting it into several use-cases and to extract common parts of
the behaviors of two or more use-cases.
Include relationship between use-cases which is shown by a dashed arrow with an open
arrowhead from the base use-case to the included use-case. The arrow is labelled with the
keyword «include».
Use-cases deal only in the functional requirements for a system. Other requirements such as
business rules, quality of service requirements, and implementation constraints must be
represented separately.
The diagram shown below is an example of a simple use-case diagram with all the elements
marked.

GUIDELINES FOR DRAWING USE CASE DIAGRAMS

Following general guidelines could be kept in mind while trying to draw a use case diagram:
· Determine the system boundary
· Ensure that individual actors have well-defined purpose
· Use cases identified should let some meaningful work done by the actors
· Associate the actors and use cases -- there shouldn't be any actor or use case floating without
any connection
· Use include relationship to encapsulate common behavior among use cases, if any

22
 LAB WORK-V

------------------------------------------------------------------------------------------------------------------
Title: Identifying Domain Classes from the Problem Statements
Objective: "Deriving Domain Classes from Problem Statements"
------------------------------------------------------------------------------------------------------------------

References: An Integrated Approach To Software Engineering

Pankaj JaloteSoftware Engineering K.K Aggarwal &
Yogesh Singh Software Engineering Roger Pressman
McGraw Hill
Visual Modeling with Rational Rose 2000 and UML Terry Quatrani

Let's delve into the concept of identifying domain classes from problem statements in a more
detailed manner and provide a step-by-step example for a Library Management System.

Domain Classes:
• In Object-Oriented Programming (OOP), a domain class is a fundamental concept. It
represents a specific entity or concept within a system. These classes help organize and
model the real-world objects and their interactions in software. To create effective
software, it's crucial to identify the right domain classes.

Traditional Techniques for Identifying Domain Classes:

1. Grammatical Approach Using Nouns:

• This technique is widely used and involves analyzing the problem statement text to
identify potential classes.

• Steps:
1.1 Begin with the user requirements or problem statement, usually provided in plain
English.
1.2 Identify and extract nouns, pronouns, and noun phrases from the text.
1.3 Group these extracted elements into potential classes based on their nature.
For instance:
• Nouns referring to people, like "Librarian" or "Member," could become classes.
• Nouns indicating physical objects, like "Book" or "Library," may become classes.
Advantages:
It's straightforward and can be applied to problem statements in various languages.

23
 • Disadvantages:
It may not always lead to perfect class identification. There could be redundancy or
omissions.

Steps to Identify Domain Classes from a Problem Statement:

1. Start with the Problem Statement:
Begin by reading and understanding the problem statement. In this example, we'll
consider a Library Management System.

2. Identify Nouns and Noun Phrases:

Extract nouns and noun phrases that represent entities, objects, or concepts relevant to
the library system. Examples might include "Library," "Book," "Librarian," "Member,"
etc.

3. Apply Domain Knowledge:

Use your domain knowledge or expertise to identify additional classes that might not
be immediately evident from the grammatical analysis. For instance, you may recognize
the need for a "Transaction" class to handle borrowing and returning books.

4. Refine and Categorize:

Group the identified potential classes into categories. Common categories include:
People (e.g., "Librarian," "Member").
Things (e.g., "Book," "Library").
Concepts (e.g., "Transaction," "Due Date").
Assign names to these groups.

5. Iterate and Refine:

Review and refine your list of classes as needed. Sometimes, it's necessary to revisit the
problem statement or consult with domain experts to ensure completeness and
accuracy.

Example: Identifying Domain Classes for a Library Management System:

Problem Statement: Develop a Library Information System (LIS) for The SE VLabs Institute,
focusing on providing efficient book management services for research scholars, students,
professors, and employees.

Identified Nouns and Noun Phrases:

• The SE VLabs Institute

• Software Engineering
• Research scholars (students)
• Professors
• Employees

24
 • Projects
• Institution
• Library Information System (LIS)
• Members
• Book
• Desk/Chamber
• System
• Library staff
• Librarian
• Transactions
• Record
• Shelf
• Non-member
• Web application
• LAN
• Software
• Information
• Passwords

Categorization:

1. People:

• Research scholars (students)

• Professors
• Employees
• Members
• Library staff
• Librarian
• Non-member

2. Places:

• Desk/Chamber

3. Things:

• Projects
• Book
• System
• Shelf

4. Organizations:

• The SE VLabs Institute

• Institution

5. Concepts:

25
 • Software Engineering
• Library Information System (LIS)
• Record
• Web application
• Software
• Information
• Passwords

6. Events:

• Transactions (book transactions)

Refined Classes Relevant to the Library Information System:

• Member (People): Represents individuals who are eligible to borrow books from the
library, including research scholars, professors, and employees.
• Book (Things): Represents physical books available in the library's collection.
• Transaction (Events): Represents the process of borrowing and returning books.
• Librarian (People): Represents individuals responsible for managing the library and
overseeing LIS operations.
• Employee (People): Represents individuals employed at The SE VLabs Institute,
including librarians and other staff members.

Additional Potential Classes (based on domain knowledge):

• Desk/Chamber (Places): Represents physical locations where members can conduct

book transactions.
• Project (Things): Represents the research or software engineering projects undertaken
by the institution.
• Shelf (Things): Represents physical book storage areas within the library.
• Institution (Organizations): Represents The SE VLabs Institute as an organization.
• Web Application (Concepts): Represents the web-based application used to access the
LIS.
• LAN (Concepts): Represents the local area network within the institute.

Class Relationships:

• Librarian and Member can both be subclasses of Employee because they share
common attributes.
• Transaction involves interactions between Member, Book, and Desk/Chamber.
• Web Application runs within the institute's LAN.

This refined list of classes and relationships provides a solid foundation for modeling and
designing The SE VLabs Institute's Library Information System. It captures the key entities
and concepts relevant to the system and aligns with the institution's specific needs and
objective.

26
 LAB WORK-Vl
------------------------------------------------------------------------------------------------------------------
Title: State chart and Activity Modeling
Objective: "Visualizing System Behavior: State Chart Modeling"
------------------------------------------------------------------------------------------------------------------

References: An Integrated Approach To Software Engineering

Pankaj Jalote Software Engineering K.K Aggarwal &
Yogesh Singh Software Engineering Roger Pressman
McGraw Hill
Visual Modeling with Rational Rose 2000 and UML Terry Quatrani

Statechart Diagrams:

1. States:

• Initial State: This is the state in which an object or system begins its lifecycle. It
represents the starting point.
• Final State: This is the endpoint of a system's lifecycle, where no further state transitions
occur. It signifies completion.
• Intermediate State: These are states between initial and final states, representing distinct
stages in a system's behavior or lifecycle.

Example: For a computer, the initial state could be "Off," the final state "Shutdown," and
intermediate states might include "Running" and "Hibernate."

2. Transitions:
• Transitions describe how the system moves from one state to another in response to
external events or triggers.
• Transitions are labeled with events (e.g., button clicks), guard conditions (conditions
that must be true for the transition to occur), and action expressions (actions performed
during the transition).

Example: Transition from "Running" to "Shutdown" could occur when the user clicks the
"Shut down" button, with the event labeled as "Click" and a guard condition ensuring proper
system conditions.

27
3. Actions:
• Actions define the specific behavior of the system during different phases of state
transitions.
• These actions include entry actions (actions performed when entering a state), exit
actions (actions performed when leaving a state), and actions that occur during the state
(e.g., "Do" actions).

Example: When transitioning from "Running" to "Shutdown," an entry action could involve
saving the current state, an exit action might close running applications, and a "Do" action
could update a progress bar.

4. Guidelines for Drawing Statechart Diagrams:

• Begin by identifying the distinct states the system can be in.
• Define the events and conditions that trigger state transitions.
• Clearly specify the actions that occur during each state and transition.
• Use appropriate symbols to represent initial, final, and intermediate states.
• Label transitions with events, guards, and actions for clarity.

Activity Diagrams:

1. Activities:
• Activities represent specific actions or tasks within a system's logical flow. These
actions can range from simple function calls to complex processes involving multiple
steps.
• Activities are depicted using rounded rectangles to distinguish them from other
elements.

2. Flows:
• Flows represent the flow of control between activities, indicating the sequence of
actions.
• They can be associated with guard conditions, specifying when a particular path should
be followed based on certain criteria.

3. Decision and Merge Nodes:

• Decision nodes are diamond-shaped symbols that signify a choice or branching point
where one flow enters, and multiple flows exit.
• Merge nodes are also diamond-shaped and indicate synchronization, where multiple
flows enter and one exits.

28
4. Fork and Join:
• Fork nodes mark the start of parallel activities. They have one incoming flow and
multiple outgoing flows.
• Join nodes represent the synchronization of concurrent activities, having multiple
incoming flows and one outgoing flow.

5. Note and Partition:

• Notes can be used to add comments or constraints to different components of the
diagram.
• Partitions (swim lanes) are optional and can be employed to group activities by different
units or actors, helping to organize the diagram.

6. Guidelines for Drawing Activity Diagrams:

• Start by identifying and breaking down the tasks or activities within the system.
• Determine the logical flow of control between activities, considering decision points
and synchronization.
• Define conditions and constraints that influence the flow of control.
• Employ decision nodes for branching and merge nodes for synchronization.
• Optionally, use partitions to represent different units or actors within the system, aiding
in clear organization.

29
Activity diagrams provide a visual means of representing complex processes or workflows in
a system, making them invaluable for communicating the flow of control and decision logic.

• An Example of state chart diagram:

The process begins by checking out the code from Subversion repository. Necessary
modifications are then made to the checked out code (local copy). Once the developer is done
with his changes, the application has to be tested to verify whether the new functionality are
working fine. This test has to be performed with two of the more popular web browsers: Firefox
and Internet Explorer, to support cross-browser accessibility. If testing fails in at least one of
the two browser, developer goes back to his code, and fixes it. Only when all the browsers pass
the test, a patch is generated from the local copy, and applied to the production code. The local
copy is then committed resulting in update of the SVN repository. Note that, if the local copy
is committed before generating a patch file, then local changes would get registered, and one
won't be further able to generate the patch file.

Here's a State chart Diagram for the process of checking out, modifying, testing, and applying
changes to a code repository:

30
States:

1. Start: This is the initial state, representing the beginning of the process.

2. Checkout Code: The system is in this state when code is checked out from the Subversion
(SVN) repository.

3. Modify Code: After checking out the code, the developer enters this state to make necessary
modifications.

4. Testing - Firefox: This state represents testing the application in the Firefox browser.

5. Testing - Internet Explorer: This state represents testing the application in the Internet
Explorer browser.

6. Fix Code: If testing fails in one or both browsers, the system moves to this state, where the
developer goes back to the code to make fixes.

7. Generate Patch: When all browsers pass the test, a patch file is generated from the local
copy.

8. Apply Patch: The patch file is applied to the production code.

9. Commit to Repository: After applying the patch, the local copy is committed to the SVN
repository.

Transitions:

o Start -> Checkout Code: Transition to start the process by checking out the code.
o Checkout Code -> Modify Code: Transition to enter the code modification phase.
o Modify Code -> Testing - Firefox: Transition to testing the code in the Firefox browser.
o Modify Code -> Testing - Internet Explorer: Transition to testing the code in the Internet
Explorer browser.
o Testing - Firefox -> Fix Code: If testing in Firefox fails, transition to fixing the code.
o Testing - Internet Explorer -> Fix Code: If testing in Internet Explorer fails, transition to
fixing the code.
o Fix Code -> Modify Code: Transition back to the code modification phase after making
fixes.
o Testing - Firefox -> Generate Patch: Transition to generating a patch file if testing in
Firefox passes.
o Testing - Internet Explorer -> Generate Patch: Transition to generating a patch file if testing
in Internet Explorer passes.
o Generate Patch -> Apply Patch: Transition to applying the generated patch file.
o Apply Patch -> Commit to Repository: Transition to committing the modified code to the
SVN repository.

31
 LAB WORK - VII
------------------------------------------------------------------------------------------------------------------
Title: Modeling UML Class Diagrams and Sequence diagrams
Objective: Visualizing Software: UML Class & Sequence

References: An Integrated Approach To Software Engineering

Pankaj JaloteSoftware Engineering K.K Aggarwal
& Yogesh Singh Software Engineering Roger
Pressman McGraw Hill
Visual Modeling with Rational Rose 2000 and UML Terry Quatrani

Theory:
Class diagrams are widely used to describe the types of objects in a system and their
relationships. Class diagrams model class structure and contents using design elements such as
classes, packages and objects.2 Class diagrams describe three different perspectives when
designing a system, conceptual, specification, and implementation.1 These perspectives
become evident as the diagram is created and help solidify the design. This example is only
meant as an introduction to the UML and class diagrams. If you would like to learn more see
the Resources page for more detailed resources on UML. Classes are composed of three things:
a name, attributes, and operations. Below is an example of a class.

Procedure:
1) Identify various elements such as classes, member variables, member functions etc.of the
class diagram
2) Draw the class diagram as per the norms.
Objectives:
The document outlines the objectives of an experiment related to UML (Unified Modeling
Language) Class Diagrams and Sequence Diagrams, aimed at helping learners:

32
1. UML Class Diagrams:
- Class Diagrams serve as a foundational tool for visually representing the static structure of
a software system. They comprise several key elements, including classes, attributes,
operations, and relationships between classes.
Example: Let's consider the development of a social media platform. In this context, a class
might be "User," which contains attributes like "username" and "email" and operations like
"post Status ()" and "add Friend ()."

2. Generalization/Specialization:
- The document explains the concept of Generalization/Specialization, which describes
how one class can inherit properties from another, forming a hierarchy within the system.
Example: In the context of our social media platform, there might be a general class called
"Account" that represents any type of user account. Then, there could be specialized classes
like "Admin Account" and "User Account" that inherit from the "Account" class.

3. Relationships:
- The document introduces various types of relationships between classes:
- Association: signifies a connection between classes that allows for message exchange.
Example: In structure model for a system of an organization an employee (instance of
‘Employee’ class) is always assigned to a particular department (instance of
‘Department’ class) and the association can be shown by a line connecting the
respective classes.

- Aggregation: denotes a part-whole relationship between classes.

Example: For a supermarket in a city, each branch runs some of the departments they have.
So, the relation among the classes ‘Branch’ and ‘Department’ can be designed as an
aggregation. In UML, it can be shown as in the fig. below.

33
 - Composition: is a stronger form of aggregation where the whole entity owns its parts, and
the lifecycle of parts depends on the whole.
Example: Let consider a shopping mall has several branches in different locations in a
city. The existence of branches completely depends on the shopping mall as if it is not
exist any branch of it will no longer exists in the city. This relation can be described as
composition and can be shown as below.

4. Multiplicity:
- Multiplicity specifies how many instances of one class are related to instances of another
class in an association.
Example: In a project management system, the multiplicity between "Project" and "Team
Member" could be one-to-many, indicating that a project can have multiple team members, but
each team member belongs to one project.

Sequence Diagrams:
The document transitions to discussing Sequence Diagrams, which illustrate the dynamic
behavior of a system.

1. Sequence Diagram Elements:

- Sequence diagrams encompass objects, life-lines, and messages.
- Objects are depicted as rectangles with names and associated classes.
- Life-lines extend downward from objects, symbolizing their activity over time.
- Messages are represented as arrows, signifying interactions between objects.

34
Example:
In an online booking system for flights, you might have objects like "Passenger" and "Flight
Reservation," with messages between them such as "Passenger books a flight" and "Flight
Reservation confirms booking."

2. Types of Messages:
- The document delves into different types of messages:
- Synchronous Messages: entail the sender waiting for the receiver's response.
Example: In a chat application, when a user sends a message to another user, it's a synchronous
message because the sender expects a response.
- Asynchronous Messages: allow the sender to continue without waiting for the receiver's
response.
Example: In an email system, when a user sends an email, it's typically asynchronous because
the user can continue working while the email is being sent.
- Return Messages: are used to convey values back from a called function.
Example: In a banking system, when a customer checks their account balance, the system
returns the balance as a return message.
- Response Messages: depict self-interactions within an object's life-line.
Example: In an online game, when a player character levels up, it can send a response message
to itself to update its attributes.

35
Sample Output:

Conclusion:
In essence, this document equips learners with the skills and knowledge needed to model the
structural and dynamic aspects of software systems effectively. UML Class Diagrams enable
the representation of the system's static structure, while Sequence Diagrams help visualize its
dynamic behavior. By mastering these techniques, software designers and developers can
communicate ideas more clearly, analyze system requirements, and ultimately create well-
structured, functional software systems. In conclusion, the document offers a comprehensive
and detailed exploration of UML Class Diagrams and Sequence Diagrams, with practical
examples to illustrate each concept. This knowledge equips learners with the skills to
proficiently model both the structural and dynamic aspects of software systems, serving as a
solid foundation for effective software design and development.

36