UNIT-2
REQUIREMENTS ANALYSIS
AND SPECIFICATION
2.10
OBJECT MODELING USING UML
Object oriented analysis is the process of identifying and
describing the objects for a given problem instance. For example:
For designing the banking systems customer, Account, Branch are
the objects that must be described.
Object oriented design is the process of defining the objects and
their collaboration with other objects in order to fulfill the
requirements. For example in banking system getCustomerInfo,
Withdraw_Amount, Deposit_Amount and so on are the methods
that help in collaborating one object with another object. These
methods actually help in fulfilling requirements. The methods of
objects represent the behavior of the objects.
Representation of object orientation
The diagram shows a three-step transition:
Domain concept: A stick figure labeled "Customer".
Visualization of domain concept: A UML class box titled Customer with attributes
(Account_No, Name, Address, Phone) and a method (getCustomerInfo()).
Representation of domain concept in object oriented language: A code snippet in
Java:
public class Customer {
private int Account_No;
private string Name;
private string Address;
private int Phone;
public getCustomerInfo() {
........
}
}
What is UML?
The Unified Modeling Language (UML) is a standard diagramming notation for
specifying, visualizing, constructing and documenting the artifacts of software
systems, as well as for business modeling and other non-software systems.
The goals of UML are -
[Link] is intended to provide ready-to-use and expressive visual modeling language
in order to develop the effective system model.
[Link] modeling must be independent of the programming language or platform but
at the same time the automatic code that can be generated by this tool must
support the modern programming languages.
[Link] tool supports the high level concepts such as collaborations, framework,
patterns and components.
[Link] helps to integrate the organizational standards in the software systems.
According to Martin Fowler there are three ways of using UML -
UML as sketch: For exploring the difficult part of the system or for
representing the solution to a particular problem, software designers
create informal diagrams.
UML as blueprint: The UML can be used as a blueprint for two main
reasons - either for reverse engineering or for forward engineering.
In Reverse Engineering the UML tool reads the source code and generates
the class diagram, sequence diagram and so on.
In Forward Engineering, using the UML tool the software developers draw
some diagrams such as class diagram, use case diagram, sequence
diagram and so on. From these diagrams the code can be generated
manually or automatically. Later on, the software developer adds up more
code to implement the complete software system.
UML as programming language: UML can also be used as a
programming language.
That means, the code can be generated automatically from the UML
diagrams that are designed by the software engineers.
But for using the UML tool in this manner it is essential to draw the
diagrams with highly logical and practical approach.
Although one can use UML as a tool for programming language it is
still immature to use it in this manner.
UML can be applied as three perspectives -
Conceptual perspective: Using this perspective, the things in a real
world situation are described by the UML diagram.
Specification perspective: Using this perspective, the UML diagrams
describe the software abstractions or components with specification
or interface.
Implementation perspective: Using this perspective, the UML
diagrams describe the particulars of implementation.
UML Diagrams
● Meaning of class in different perspective
Conceptual class: Represents real world entities.
Software class: Represents specification or implementation perspective of a
software component.
Implementation class: Implemented using suitable OOP languages like C++, Java
UML Diagrams
Diagrams are the graphical representation of the set
of elements.
Various types of diagrams that can be drawn in UML
are:
[Link] diagram [Link] diagram [Link] diagram
[Link] diagram [Link] diagram
[Link] diagram [Link] diagram
[Link] case diagram [Link] diagram
Class diagram: Represents the static design view; contains classes, interfaces, and
relationships.
Object diagram: Shows relationships among different objects (instances of
classes).
Component diagram: Shows the organization and dependencies among software
components.
Use case diagram: Represents the behavior of the system; consists of use cases,
actors, and relationships.
Sequence diagram: Interaction diagrams focusing on time-ordering of messages.
State diagram: Represents states, transitions, activities, and events of an object.
Activity diagram: Represents the flow of control or data step-by-step.
Deployment diagram: Addresses the static deployment view of the architecture
(hardware/nodes).
Package diagram: Shows organizational units and their dependencies.
2.11 USE CASE MODEL
During requirement gathering the primary requirements of the system are understood.
These basic requirements of the system are called the functional requirements.
In order to understand the working of these functional requirements, developers and
users create a set of scenarios. These scenarios are nothing but text stories. These text
stories are called as use cases
The use cases are the textual representation of particular scenario, whereas the case
model is the graphical representation of the scenario.
For example :
" Customer wants to operate the ATM machine for performing some transactions.
For instance customer wants to withdraw the money. He enters the ATM card and
then types in the PIN. The system validates the customer. If the customer is the
valid customer then the customer is allowed to do further transactions. Otherwise
the card will be rejected. The valid customer enters the amount to be withdrawn. It
is then checked if withdrawal amount < balance amount. If it is so, then the
machine dispenses the desired amount. If there is no further transactions then the
card is ejected. Customer collects the cash, statement and card."
Actors, Scenarios and Use Cases
Use cases are the fundamental units of modeling language in which
functionalities are distinctly represented.
The first step in writing use case is to identify the actors. The actors are the
entities that use the system or product within the context of behavior of the
system. Actors represent the role of the people as system gets operated.
Actors can be a person, computer system or organization.
Actor is anything that communicates with the system or product. It is
external to the system. Every actor has one or more goals when using the
system.
Example : Customer, Inventory database, Accountant
Scenario is a specific sequence of actions or interactions between actor and
the system. It is also called as use case instance. The scenarios describe the
text stories.
Use case is a success or failure scenarios in which the actor communicates
with the system in order to achieve certain functionality.
Abstract Use Case vs Concrete Use Case Abstract Use Case
Concrete Use Case An Abstract Use Case is NOT a full task.
A Concrete Use Case is something the user actually does. Cannot be used alone
It represents a complete user action. Is incomplete by itself
(ATM System) Only supports other use cases
User wants money. Is reused many times
Withdraw Cash It exists only to help other use cases.
Deposit Money Example (ATM System)
Before withdrawing money, the system must:
Check Balance
Verify PIN
These are full tasks.
Authenticate User
If you remove everything else, the user can still perform
It only supports:
them.
Withdraw Cash
So they are Concrete Use Cases.
Deposit Money
Check Balance
Concrete = Real action that gives result So “Authenticate User” is Abstract.
Abstract = Helper behavior
Relationship in use cases
Include and exclude
«include» Relationship
Meaning: One use case always includes another use case as part of its process.
It is compulsory.
Simple Meaning:
If A happens → B must also happen.
Example:
In an Online Shopping System:
Use case: Place Order
Use case: Make Payment
You cannot place an order without making payment.
So:
Place Order «include» Make Payment
«extend» Relationship
Meaning: One use case adds extra behavior to another use case.
It is optional.
A happens → B may or may not happen.
In Online Shopping:
Use case: Login
Use case: Two-Factor Authentication
Not all systems force 2FA every time.
So:
Two-Factor Authentication «extend» Login
That means:
Login works normally.
But sometimes, extra security (2FA) is added.
Generalization
Generalization means inheritance.
One use case (or actor) is a special type of another use case (or actor).
In simple words:
Child use case inherits behavior from Parent use case.
It shows an "is-a" relationship.
Both inherit common features of User but may have extra privileges.
It represents inheritance.
It shows parent–child relationship.
The child element inherits behavior from the parent.
Parent Use Case:
Make Payment
Child Use Cases:
Credit Card Payment
UPI Payment
Net Banking Payment
when to use Use Cases:
To understand how users (actors) interact with a system.
To capture functional requirements of a system clearly.
To describe system behavior from the user’s perspective.
To identify system scope and boundaries.
To communicate requirements between developers and clients.
To model real-world scenarios before system design.
To document system functionality in UML diagrams.