OBJECT ORIENTED SOFTWARE ENGINEERING

UNIT-1

Object Orientation
Object-oriented programming (OOP) is a programming paradigm based on the concept of
"objects," which can contain data, in the form of fields (often known as attributes or properties),
and code, in the form of procedures (often known as methods). These objects are instances of
classes, which act as blueprints for creating objects. Object-oriented programming provides a
way to structure software in a more modular and organized manner, making it easier to manage
and maintain.

In the object-oriented design method, the system is viewed as a collection of objects (i.e.,
entities). The state is distributed among the objects, and each object handles its state data. For
example, in a Library Automation Software, each library representative may be a separate
object with its data and functions to operate on these data. The tasks defined for one purpose
cannot refer or change data of other objects. Objects have their internal data which represent
their state. Similar objects create a class. In other words, each object is a member of some
class. Classes may inherit features from the superclass.

Basic concepts of object orientation

● Class
● Objects
● Data Abstraction
● Encapsulation
● Inheritance
● Polymorphism
● Message Passing
● Aggregation

1. Class:
A class is a user-defined data type. It consists of data members and member functions, which
can be accessed and used by creating an instance of that class. It represents the set of
properties or methods that are common to all objects of one type. A class is like a blueprint for
an object.
For Example: Consider the Class of Cars. There may be many cars with different names and
brands but all of them will share some common properties like all of them will have 4 wheels,
Speed Limit, Mileage range, etc. So here, Car is the class, and wheels, speed limits, mileage
are their properties.
2. Object:
It is a basic unit of Object-Oriented Programming and represents the real-life entities. An Object
is an instance of a Class. When a class is defined, no memory is allocated but when it is
instantiated (i.e. an object is created) memory is allocated. An object has an identity, state, and
behavior. Each object contains data and code to manipulate the data. Objects can interact
without having to know details of each other’s data or code, it is sufficient to know the type of
message accepted and type of response returned by the objects.
For example “Dog” is a real-life Object, which has some characteristics like color, Breed, Bark,
Sleep, and Eats.

3. Data Abstraction:
Data abstraction is one of the most essential and important features of object-oriented
programming. Data abstraction refers to providing only essential information about the data to
the outside world, hiding the background details or implementation. Consider a real-life example
of a man driving a car. The man only knows that pressing the accelerators will increase the
speed of the car or applying brakes will stop the car, but he does not know about how on
pressing the accelerator the speed is increasing, he does not know about the inner mechanism
of the car or the implementation of the accelerator, brakes, etc in the car. This is what
abstraction is.

4. Encapsulation:
Encapsulation is defined as the wrapping up of data under a single unit. It is the mechanism that
binds together code and the data it manipulates. In Encapsulation, the variables or data of a
class are hidden from any other class and can be accessed only through any member function
of their class in which they are declared. As in encapsulation, the data in a class is hidden from
other classes, so it is also known as data-hiding.

Consider a real-life example of encapsulation, in a company, there are different sections like the
accounts section, finance section, sales section, etc. The finance section handles all the
financial transactions and keeps records of all the data related to finance. Similarly, the sales
section handles all the sales-related activities and keeps records of all the sales. Now there may
arise a situation when for some reason an official from the finance section needs all the data
about sales in a particular month. In this case, he is not allowed to directly access the data of
the sales section. He will first have to contact some other officer in the sales section and then
request him to give the particular data. This is what encapsulation is. Here the data of the sales
section and the employees that can manipulate them are wrapped under a single name “sales
section”.

5. Inheritance:
Inheritance is an important pillar of OOP(Object-Oriented Programming). The capability of a
class to derive properties and characteristics from another class is called Inheritance. When we
write a class, we inherit properties from other classes. So when we create a class, we do not
need to write all the properties and functions again and again, as these can be inherited from
another class that possesses it. Inheritance allows the user to reuse the code whenever
possible and reduce its redundancy.

6. Polymorphism:
The word polymorphism means having many forms. In simple words, we can define
polymorphism as the ability of a message to be displayed in more than one form. For example,
A person at the same time can have different characteristics. Like a man at the same time is a
father, a husband, an employee. So the same person posses different behavior in different
situations. This is called polymorphism.
7. Message Passing:
It is a form of communication used in object-oriented programming as well as parallel
programming. Objects communicate with one another by sending and receiving information to
each other. A message for an object is a request for execution of a procedure and therefore will
invoke a function in the receiving object that generates the desired results. Message passing
involves specifying the name of the object, the name of the function, and the information to be
sent.

Association:
Association is a relation between two separate classes which establishes through their Objects.
Association can be one-to-one, one-to-many, many-to-one, many-to-many. In Object-Oriented
programming, an Object communicates to another object to use functionality and services
provided by that object. Composition and Aggregation are the two forms of association.

Aggregation:
Association between two objects that defines the "has-a" relationship is referred to as
Aggregation. In Aggregation, linked objects are independent of each other. if we delete the
parent object, the child object will still exist in the system. For example, if we remove wheels
from a car, the car can function adequately with another wheel.
Aggregation implies a relationship where the child can exist independently of the parent. For
example, Bank and Employee, delete the Bank and the Employee still exist.
Composition:
A specific type of Aggregation that implies ownership is referred to as Composition. In
Composition, objects are tightly coupled or dependent on each other. if we delete a parent
object, the child object also gets deleted. For example, if we delete a folder, the files will also get
deleted which contain in the folder. Composition implies a relationship where the child cannot
exist independent of the parent. Example: Human and heart, heart don’t exist separate to a
Human

Why do we need object-oriented programming

● To make the development and maintenance of projects more effortless.
● To provide the feature of data hiding that is good for security concerns.
● We can solve real-world problems if we are using object-oriented programming.
● It ensures code reusability.
● It lets us write generic code: which will work with a range of data, so we don’t have to
write basic stuff over and over again.

Difference between Function Oriented Design and

Object Oriented Design
1. Function Oriented Design :
Function oriented design is the result of focusing attention to the function of the program. This is
based on the stepwise refinement. Stepwise refinement is based on the iterative procedural
decomposition. Stepwise refinement is a top-down strategy where a program is refined as a
hierarchy of increasing levels of details.

We start with a high level description of what the program does. Then, in each step, we take one
part of our high level description and refine it. Refinement is actually a process of elaboration.
The process should proceed from a highly conceptual model to lower level details. The
refinement of each module is done until we reach the statement level of our programming
language.

2. Object Oriented Design :

Object oriented design is the result of focusing attention not on the function performed by the
program, but instead on the data that are to be manipulated by the program. Thus, it is
orthogonal to function -oriented design. Object-oriented design begins with an examination of
the real world “things”. These things are characteristics individually in terms of their attributes
and behavior.

Objects are independent entities that may readily be changed because all state and
representation information is held within the object itself. Object may be distributed and may
execute sequentially or in parallel. Object oriented technology contains following three keywords
–

1. Objects –
Software package are designed and developed to correspond with real world entities
that contain all the data and services to function as their associated entities messages.

2. Communication –
Communication mechanisms are established that provide the means by which object
work together.

3. Methods –
Methods are services that objects perform to satisfy the functional requirements of the
problem domain. Objects request services of the other objects through messages.

Difference Between Function Oriented Design and Object Oriented Design :

COMPARISON FUNCTION ORIENTED OBJECT ORIENTED

FACTORS DESIGN DESIGN

The basic abstractions are

The basic abstractions, not the real world functions
Abstraction which are given to the user, but are the data abstraction
are real world functions. where the real world entities
are represented.

Function are grouped

Functions are grouped together on the basis of the
Function together by which a higher data they operate since the
level function is obtained. classes are associated with
their methods.

carried out using

structured analysis and
execute Carried out using UML
structured design i.e, data
flow diagram

In this approach the state

In this approach the state information is not represented
information is often in a centralized memory but is
State information
represented in a implemented or distributed
centralized shared memory. among the objects of the
system.
 Approach It is a top down approach. It is a bottom up approach.

Begins by considering the

Begins by identifying objects
Begins basis use case diagrams and the
and classes.
scenarios.

In function oriented design

Decompose we decompose in We decompose in class level.
function/procedure level.

This approach is mainly used

This approach is mainly
for evolving system which
Use used for computation
mimics a business or
sensitive application.
business case.

Generalization
Generalization is the process of extracting common properties from a set of entities and creating
a generalized entity from it. It is a bottom-up approach in which two or more entities can be
generalized to a higher-level entity if they have some attributes in common. For Example,
STUDENT and FACULTY can be generalized to a higher-level entity called PERSON as shown
in Figure 1. In this case, common attributes like P_NAME, and P_ADD become part of a higher
entity (PERSON), and specialized attributes like S_FEE become part of a specialized entity
(STUDENT).
Generalization is also called as ‘ Bottom-up approach”.
Specialization
In specialization, an entity is divided into sub-entities based on its characteristics. It is a
top-down approach where the higher-level entity is specialized into two or more lower-level
entities. For Example, an EMPLOYEE entity in an Employee management system can be
specialized into DEVELOPER, TESTER, etc. as shown in Figure 2. In this case, common
attributes like E_NAME, E_SAL, etc. become part of a higher entity (EMPLOYEE), and
specialized attributes like TES_TYPE become part of a specialized entity (TESTER).

Specialization is also called as ” Top-Down approch”.

Aggregation
An ER diagram is not capable of representing the relationship between an entity and a
relationship which may be required in some scenarios. In those cases, a relationship with its
corresponding entities is aggregated into a higher-level entity. Aggregation is an abstraction
through which we can represent relationships as higher-level entity sets.
For Example, an Employee working on a project may require some machinery. So, REQUIRE
relationship is needed between the relationship WORKS_FOR and entity MACHINERY. Using
aggregation, WORKS_FOR relationship with its entities EMPLOYEE and PROJECT is
aggregated into a single entity and relationship REQUIRE is created between the aggregated
entity and MACHINERY.
Principles of modeling

1. The choice of what models to create has a profound influence on how a problem
is attacked and how a solution is shaped.
Choose your models well. The right models will highlight the most nasty development
problems. Wrong models will mislead you, causing you to focus on irrelevant issues.

2. Every model may be expressed at different levels of precision.

Sometimes, a quick and simple executable model of the user interface is exactly what
you need. At other times, you have to get down to complex details such as cross-system
interfaces or networking issues etc.
 In any case, the best kinds of models are those that let you choose your degree of detail,
depending on who is viewing it. An analyst or an end user will want to focus on issues of
what and a developer will want to focus on issues of how.
3. The best models are connected to reality.
In software, the gap between the analysis model and the system’s design model must be
less. Failing to bridge this gap causes the system to diverge over time. In object-oriented
systems, it is possible to connect all the nearly independent views of a system into one
whole.

4. No single model is sufficient. Every non-trivial system is best approached through

a small set of nearly independent models.
In the case of a building, you can study electrical plans in isolation, but you can also see
their mapping to the floor plan and perhaps even their interaction with the routing of
pipes in the plumbing plan.

Importance of modeling

A model is a simplification of reality.

A good model includes those elements that have broad effect and omits those minor elements
that are not relevant to the given level of abstraction. A model may be structural, emphasizing
the organization of the system, or it may be behavioral, emphasizing the dynamics of the
system.

Why do we model? There is one fundamental reason:

We build models so that we can better understand the system we are developing.

Through modeling, we achieve four aims:

● Models help us to visualize a system as it is or as we want it to be.

● Models permit us to specify the structure or behavior of a system.
● Models gives us a template that guides us in constructing a system.
● Models document the decisions we have made.

The larger and more complex the system becomes, the more important modeling becomes, for
one very simple reason:

We build models of complex systems because we cannot comprehend such a system in its
entirety.
Every project can benefit from modeling. Modeling can help the development team better
visualize the plan of their system and allow them to develop more rapidly by helping them build
the right thing. The more complex your project, the more likely it is that you will fail or that you
will build the wrong thing if you do on modeling at all.

Object oriented modeling

Object-oriented modeling (OOM) is an approach to modeling an application that is used at the
beginning of the software life cycle when using an object-oriented approach to software
development. The software life cycle is typically divided up into stages going from abstract
descriptions of the problem to designs then to code and testing and finally to deployment.
Modeling is done at the beginning of the process.

In software field, there are several ways to approach for building a model. The two most
common ways are: from an algorithmic perspective and from an object oriented perspective.

The traditional view of software development takes an algorithmic perspective. In this approach,
the main building block of all software is the procedure or function. This view leads the
developers to focus on issues of control and the decomposition of larger algorithms into smaller
ones.

As requirements change, and the system grows, systems built with an algorithmic focus turn out
to be very hard to maintain.

The contemporary (another) view of software development takes an object oriented perspective.
In object oriented modeling, the main building block of all software systems is the object or
class.
The object oriented approach to software development is a part of the mainstream development
simply because it has proven to be of value in building systems in all sorts of problem domains
and cover all degrees of size and complexity.

The most common language used to do object-oriented modeling is the Object Management
Group's Unified Modeling Language (UML).

Different diagrams are used for different types of UML modeling. There are three important
types of UML modeling.

Structural Modeling
Structural modeling captures the static features of a system. They consist of the following −
​ Classes diagrams
​ Objects diagrams
​ Deployment diagrams
​ Package diagrams
​ Composite structure diagram
​ Component diagram
Structural model represents the framework for the system and this framework is the place where
all other components exist. Hence, the class diagram, component diagram and deployment
diagrams are part of structural modeling. They all represent the elements and the mechanism to
assemble them.
The structural model never describes the dynamic behavior of the system. Class diagram is the
most widely used structural diagram.

Behavioral Modeling
Behavioral model describes the interaction in the system. It represents the interaction among
the structural diagrams. Behavioral modeling shows the dynamic nature of the system. They
consist of the following −
​ Activity diagrams
​ Interaction diagrams
​ Use case diagrams
All the above show the dynamic sequence of flow in a system.

Architectural Modeling
Architectural model represents the overall framework of the system. It contains both structural
and behavioral elements of the system. Architectural model can be defined as the blueprint of
the entire system. Package diagram comes under architectural modeling.
Object oriented analysis
Object-Oriented Analysis (OOA) is the first technical activity performed as part of object-oriented
software engineering. OOA introduces new concepts to investigate a problem. It is based on a
set of basic principles, which are as follows:
● The information domain is modeled:
Lets say you’re building a game. OOA helps you figure out all the things you need to
know about the game world – the characters, their features, and how they interact. It’s
like making a map of everything important.
● Behavior is represented:
OOA also helps you understand what your game characters will do. If a character jumps
when you press a button, OOA helps describe that action. It’s like writing down a script
for each character.
● The function is described:
Every program has specific tasks or jobs it needs to do. OOA helps you list and describe
these jobs. In our game, it could be tasks like moving characters or keeping score. It’s
like making a to-do list for your software.
● Data, functional, and behavioral models are divided to uncover greater detail:
OOA is smart about breaking things into different parts. It splits the job into three
categories: things your game knows (like scores), things your game does (like jumping),
and how things in your game behave (like characters moving around). This makes it
easier to understand.
● Starting Simple, Getting Detailed:
OOA knows that at first, you just want to understand the big picture. So, it starts with a
simple version of your game or program. Later on, you add more details to make it work
perfectly. It’s like sketching a quick drawing before adding all the colors and details.

Difference between Structured and Object-Oriented Analysis

Analysis simple means to study or examine the structure of something, elements, and system
requirements in detail, and methodical way. Structured analysis and Object-oriented analysis
both are important for software development and are analysis techniques used in software
engineering. But both are different from each other.
Structured Analysis and Object-Oriented Analysis (OOA) are two software development
methodologies that are used to design and develop software systems. While they have some
similarities, they differ in a number of key ways.

Structured Analysis:
1. Focus on processes: Structured Analysis focuses on the processes involved in a
software system, modeling them as a series of connected steps.
2. Top-down approach: Structured Analysis follows a top-down approach, breaking down
complex systems into smaller, simpler parts that can be more easily understood.
 3. Data-centered: Structured Analysis focuses on the data that a software system
manipulates, modeling it as data flows between processes.
4. Emphasis on functional decomposition: Structured Analysis emphasizes the functional
decomposition of a software system into smaller, independent functions.

Object-Oriented Analysis (OOA):

1. Focus on objects: OOA focuses on the objects involved in a software system, modeling
them as instances of classes that encapsulate both data and behavior.
2. Bottom-up approach: OOA follows a bottom-up approach, building complex systems
from smaller, simpler objects that can be more easily understood.
3. Object-centered: OOA focuses on the objects that make up a software system, modeling
their relationships and interactions.
4. Emphasis on object-oriented design patterns: OOA emphasizes the reuse of objects and
object-oriented design patterns, reducing the amount of code that needs to be written
and improving the quality and consistency of the software.

1. Structured Analysis :
Structured analysis is a method of development that allows and gives permission to the
analyst to understand and know about the system and all of its activities in a logical way.
It is simply a graphic that is used to specify the presentation of the application.

Example –

2. Object-Oriented Analysis :
Object-Oriented Analysis (OOA) is a technical approach generally used for analyzing and
application designing, system designing, or even business designing just by applying
object-oriented programming even with the use of visual modeling throughout the process of
development to just simply guide the stakeholder communication and quality of the product. it is
actually a process of discovery where a team of developers understands and models all the
requirements of the system.

Example –

Difference Between Structured and Object-oriented analysis :

Structured Analysis Object-Oriented Analysis

The main focus is on the process and The main focus is on data structure and
procedures of the system. real-world objects that are important.

It uses System Development Life

Cycle (SDLC) methodology for It uses Incremental or Iterative
different purposes like planning, methodology to refine and extend our
analyzing, designing, implementing, design.
and supporting an information system.
 It is suitable for well-defined projects It is suitable for large projects with
with stable user requirements. changing user requirements.

Risk while using this analysis

Risk while using this analysis technique
technique is high and reusability is
is low and reusability is also high.
also low.

Requirement engineering includes the

Structuring requirements include DFDs
Use case model (find Use cases, Flow of
(Data Flow Diagram), Structured
events, Activity Diagram), the Object
Analysis, ER (Entity Relationship)
model (find Classes and class relations,
diagram, CFD (Control Flow Diagram),
Object interaction, Object to ER
Data Dictionary, Decision table/tree,
mapping), Statechart Diagram, and
and the State transition diagram.
deployment diagram.

This technique is old and is not This technique is new and is mostly
preferred usually. preferred.

Advantages of Structured Analysis:

1. Clear and straightforward: Structured Analysis is a clear and straightforward
methodology that is easy to understand and implement.
2. Top-down approach: The top-down approach of Structured Analysis makes it easy to
identify the high-level functions and processes involved in a software system, and to
break them down into smaller, more manageable components.
3. Emphasis on data: Structured Analysis places a strong emphasis on the data that a
software system manipulates, making it easier to understand the relationships between
data and processes.
4. Well-suited for small to medium-sized systems: Structured Analysis is well-suited for
small to medium-sized systems, where the focus is on breaking down complex systems
into simpler, more manageable components.

Disadvantages of Structured Analysis:

1. Limited scalability: Structured Analysis is limited in its scalability, and may become
cumbersome when dealing with complex, large-scale systems.
2. Lack of object orientation: Structured Analysis does not provide the object orientation
and encapsulation benefits of OOA, making it more difficult to manage and maintain
large systems over time.
 3. Limited ability to model complex relationships: Structured Analysis has a limited ability to
model complex relationships between objects, making it less suitable for modeling large,
complex systems.

Advantages of Object-Oriented Analysis (OOA):

1. Reusable code: OOA enables the creation of reusable objects and design patterns,
reducing the amount of code that needs to be written and improving the quality and
consistency of the software.
2. Scalability: OOA is more scalable than Structured Analysis, making it better suited for
large, complex systems.
3. Object orientation: OOA provides the benefits of object orientation, including
encapsulation, inheritance, and polymorphism, making it easier to manage and maintain
large systems over time.
4. Better modeling of complex relationships: OOA enables better modeling of complex
relationships between objects, making it better suited for modeling large, complex
systems.

Disadvantages of Object-Oriented Analysis (OOA):

1. Steep learning curve: OOA can be more difficult to understand and implement than
Structured Analysis, especially for those who are not familiar with object-oriented
programming.
2. Bottom-up approach: The bottom-up approach of OOA can make it difficult to
understand the high-level functions and processes involved in a software system, and to
break them down into smaller, more manageable components.
3. Emphasis on objects: OOA places a strong emphasis on objects, making it more difficult
to understand the relationships between data and processes.

Object Oriented Life cycle model

The Object-Oriented Approach to Building Systems takes the objects as the basis. For this, first,
the system to be developed is observed and analyzed, and the requirements are defined as in
any other method of system development. Once this is often done, the objects in the required
system are identified. For example, in the case of a Banking System, a customer is an object, a
checkbook is an object, and even an account is an object. The object-oriented model employs
an object-oriented strategy. The primary objectives are:
1. Object-oriented analysis: Object-oriented analysis develops an object-oriented model of
the application domain.
2. Object-oriented design: Object-oriented design develops an object-oriented model of the
software system.
 3. Object-oriented programming: Object-oriented programming realizes the software design
with an object-oriented programming language that supports the direct implementation of
objects, classes, and inheritance.
There are a variety of object-oriented methodologies such as:
1. Object Identification: System objects and their characteristics and events.
2. Object Organization: Shows how objects are related via “part-of” relationships.
3. Object Interfaces: Shows how objects interact with other objects.
These activities tend to overlap and in general parallel.

The requirements analysis stage strives to achieve an understanding of the client’s application
domain. The task that a software solution must address emerge in the course of requirement
analysis. The requirement analysis phase remains completely independent of any
implementation technique that might be applied later.

In the system specification stage, the wants’ definition describes what the software product must
do, but not how this goal is to be achieved.

One point of divergence from conventional phase model arises because implementation with
object-oriented programming is marked by the assembly of already existing components. The
class library serves as a tool that extends beyond the scope of an individual project because
class provided by one project can increase productivity in subsequent projects.
Advantages of Object-Oriented Life Cycle Model
1. Design is no longer carried out independently of the later implementation because during
the design phase we must consider which components are available for the solution of
the problem.
2. Design and implementation become more closely associated.
3. Duration of the implementation phase is reduced.
4. A new job title emerges, the class librarian, who is responsible for ensuring the efficient
usability of the class library.

Requirement Elicitation
Requirements elicitation is the process of gathering and defining the requirements for a software
system. The goal of requirements elicitation is to ensure that the software development process
is based on a clear and comprehensive understanding of the customer’s needs and
requirements. This article focuses on discussing Requirement Elicitation in detail.

Importance of Requirements Elicitation

1. Compliance with Business Objectives: The process of elicitation guarantees that the
software development endeavours are in harmony with the wider company aims and
objectives. Comprehending the business context facilitates the development of a
solution that adds value for the company.
2. User Satisfaction: It is easier to create software that fulfils end users needs and
expectations when they are involved in the requirements elicitation process. Higher user
pleasure and acceptance of the finished product are the results of this.
3. Time and Money Savings: Having precise and well-defined specifications aids in
preventing miscommunication and rework during the development phase. As a result,
there will be cost savings and the project will be completed on time.
4. Compliance and Regulation Requirements: Requirements elicitation is crucial for
projects in regulated industries to guarantee that the software conforms with applicable
laws and norms. In industries like healthcare, finance, and aerospace, this is crucial.
5. Traceability and Documentation: Throughout the software development process,
traceability is based on requirements that are well-documented. Traceability helps with
testing, validation, and maintenance by ensuring that every part of the software can be
linked to a particular requirement.

Requirements Elicitation Activities:

Requirements elicitation includes the subsequent activities. A few of them are listed below:
1. Knowledge of the overall area where the systems are applied.
2. The details of the precise customer problem where the system is going to be applied
must be understood.
 3. Interaction of system with external requirements.
4. Detailed investigation of user needs.
5. Define the constraints for system development.

Requirements Elicitation Methods:

There are a number of requirements elicitation methods. Few of them are listed below:

1. Interviews
Objective of conducting an interview is to understand the customer’s expectations from the
software.
It is impossible to interview every stakeholder hence representatives from groups are selected
based on their expertise and credibility. Interviews maybe be open-ended or structured.
1. In open-ended interviews there is no pre-set agenda. Context free questions may be
asked to understand the problem.
2. In a structured interview, an agenda of fairly open questions is prepared. Sometimes a
proper questionnaire is designed for the interview.

2. Brainstorming Sessions
● It is a group technique
● It is intended to generate lots of new ideas hence providing a platform to share views
● A highly trained facilitator is required to handle group bias and group conflicts.
● Every idea is documented so that everyone can see it.
● Finally, a document is prepared which consists of the list of requirements and their
priority if possible.

3. Facilitated Application Specification Technique

Its objective is to bridge the expectation gap – the difference between what the developers think
they are supposed to build and what customers think they are going to get. A team-oriented
approach is developed for requirements gathering. Each attendee is asked to make a list of
objects that are:
1. Part of the environment that surrounds the system.
2. Produced by the system.
3. Used by the system.
Each participant prepares his/her list, different lists are then combined, redundant entries are
eliminated, team is divided into smaller sub-teams to develop mini-specifications and finally a
draft of specifications is written down using all the inputs from the meeting.
4. Quality Function Deployment
In this technique customer satisfaction is of prime concern, hence it emphasizes on the
requirements which are valuable to the customer.
3 types of requirements are identified:
● Normal requirements: In this the objective and goals of the proposed software are
discussed with the customer. Example – normal requirements for a result management
system may be entry of marks, calculation of results, etc.
● Expected requirements: These requirements are so obvious that the customer need not
explicitly state them. Example – protection from unauthorized access.
● Exciting requirements: It includes features that are beyond customer’s expectations and
prove to be very satisfying when present. Example – when unauthorized access is
detected, it should backup and shutdown all processes.

5. Use Case Approach

This technique combines text and pictures to provide a better understanding of the
requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a functional
view of the system.
The components of the use case design include three major things – Actor, use cases, use case
diagram.
1. Actor: It is the external agent that lies outside the system but interacts with it in some
way. An actor maybe a person, machine etc. It is represented as a stick figure. Actors
can be primary actors or secondary actors.

● Primary actors: It requires assistance from the system to achieve a goal.

● Secondary actor: It is an actor from which the system needs assistance.
2. Use cases: They describe the sequence of interactions between actors and the system.
They capture who(actors) do what(interaction) with the system. A complete set of use
cases specifies all possible ways to use the system.
3. Use case diagram: A use case diagram graphically represents what happens when an
actor interacts with a system. It captures the functional aspect of the system.

● A stick figure is used to represent an actor.

● An oval is used to represent a use case.
● A line is used to represent a relationship between an actor and a use case.

Requirement Modeling
The technique of modeling requirements and solutions as they change through collaborative
work and cooperation is known as Requirements Modeling. You may ensure that your team
satisfies the stakeholders’ exact requirements by employing this approach of cross-functional,
self-organizing teams.
Requirements Modeling is the process of documenting, analyzing, and managing
Requirements. Requirements can be anything that a customer or user wants from a software
system. They can include functional requirements (what the system should do), non-functional
requirements (such as performance, security, etc.), as well as constraints (things that might limit
what the system can do).

The Requirements Modeling process involves three main activities:

1. Analysis: Once the Requirements have been collected, they need to be analyzed to see
if they are complete, consistent, and clear. Any inconsistencies or ambiguities should be
resolved at this stage.
2. Documentation: The Requirements should be documented in a clear and concise way.
This will ensure that everyone understands the Requirements and can refer back to
them if needed.
3. Management: Once the Requirements have been collected and documented, they need
to be managed throughout the project. This includes keeping track of changes to
Requirements, making sure everyone is aware of these changes, and ensuring that the
requirements are still being met.

Benefits of Requirements Modeling

Requirements modeling will improve the clarity of your requirements. This may have a profound
influence on the success of your software projects. The following are some of the most
significant advantages of adopting modern requirements modeling and management systems:
1. Creating simulations is a breeze
2. Automatic document generation
3. Automatics Test Conduction
4. Easy integration with development and testing tools
5. Easy requirements change management

Why is Requirements Modeling Important?

Requirements Modeling is important because it helps to ensure that the Requirements for a
project are well understood by everyone involved. It also helps to identify any potential risks or
problems early on in the project, which can save time and money later on.
If you want to achieve quick, consistent, and continuous software delivery, then requirements
modeling is key. Even though this process might not give you clear-cut solutions, it will provide
you with a reliable guide for the end product. This way, your development team will have a
stronger comprehension of the product and how to develop it. Consequently, both developers
and clients can voice any concerns they may have about the product early on. By using this
process from the beginning stages of planning, you can present both your project stakeholders
and customers with a comprehensive blueprint that is easy to follow.
Any modifications that are required to match their exact demands and specifications may be
addressed in this strategy. You will decrease the chance of obstacles later on by providing
enhanced and rapid feedback at the start of the project and throughout its duration. When fresh
team members are added, it’s even more crucial. These methods can quickly provide new
workers an overview of the project from beginning to end – from conception to completion. This
allows new employees to grasp how iterations in this system are prioritized.
If Requirements are not well understood, there is a risk that they will not be met. This can lead
to the project being delayed, over budget, or even canceled. In some cases, it can also lead to
legal issues if the final product does not meet the customer’s expectations.

Requirements Modeling Techniques

There are many different tools that can be used for Requirements Modeling, depending on the
needs of the project. Some of the most popular requirements modeling tools include
● Requirements Traceability Matrix: A requirements traceability matrix is a table that
shows the relationships between requirements. It can be used to ensure that all
requirements are being met.
● Use Cases: A use case is a description of how a user will interact with the system to
achieve a specific goal. Use cases can be used to capture functional requirements. Use
cases depict the high-level functionalities that the system should be able to perform.
● User Stories: A user story is a short, simple description of a feature from the perspective
of the user. User stories can be used to capture both functional and non-functional
requirements.
● Process Flow Diagrams: A process flow diagram shows how tasks are performed in a
process. Process flow diagrams can be used to capture both functional and
non-functional requirements.
● Activity Diagram – This approach is used to address the whole business process or
system process – which may be appropriate for all sorts of users depending on the
requirement being functional and the type being fundamental. This approach can only
define the scope of a system or procedure, but it can’t help with detailed impact analysis.
● State Diagram – A state diagram is a more detailed approach than a flow chart. Only the
various states of an object that passes through a process flow are depicted in a state
diagram when it comes to the system’s or procedure’s elements, or the process itself.
This element, according to this viewpoint, cannot be used directly in impact analysis
calculations.
● Sequence Diagram – This is more relevant for a technical user, especially when many
processes are underway. It visualizes how processes or objects interact during a
scenario and depicts this in a graphical way. This approach adds additional value to
technical users since it can help them get down to specific technological specifications.
During the development phase, this technique is the most popular method for
requirement reference, owing to its usefulness.

Requirements Modeling Elements

Below are the different strategies of requirements modeling:
1. Flow Oriented Modeling – The data objects are transformed by the function as it is
processed.
The Flow oriented elements are
● Data Flow Model – It is a graphical technique. It is used to represent information flow.
● Control Flow Model – Large class applications require control flow modeling.
● Control Specification – The state diagram in the control specification is a sequential
specification of the behavior.
● Process Specification – The process specification is used to describe all flow model
processes.
2. Class-based Modeling – Class-based modeling represents the object. The system
manipulates the operations.
The elements of the class-based model consist of the following:
● Classes – To figure out which classes to take, underline each noun or noun clause in the
text and enter it into the table.
● Attributes – Attributes are the data objects that define a class within the context of the
problem. For example, ’employee’ is a class consisting of the name, Id, department,
designation, and salary of the employee.
● Operations – The operations describe the actions of a thing.
Analysis Modeling

Analysis Model is a technical representation of the system. It acts as a link between the
system description and the design model. In Analysis Modelling, information, behavior,
and functions of the system are defined and translated into the architecture, component,
and interface level design in the design modeling.

Objectives of Analysis Modelling:

● It must establish a way of creating software design.

● It must describe the requirements of the customer.
● It must define a set of requirements that can be validated, once the software is
built.

Elements of Analysis Model:

Elements of Analysis Model

1. Data Dictionary:
It is a repository that consists of a description of all data objects used or
produced by the software. It stores the collection of data present in the software.
It is a very crucial element of the analysis model. It acts as a centralized
repository and also helps in modeling data objects defined during software
requirements.

2. Entity Relationship Diagram (ERD):

It depicts the relationship between data objects and is used in conducting data
modeling activities. The attributes of each object in the Entity-Relationship
Diagram can be described using Data object description. It provides the basis for
activity related to data design.

3. Data Flow Diagram (DFD):

It depicts the functions that transform data flow, and it also shows how data is
transformed when moving from input to output. It provides the additional
information which is used during the analysis of the information domain and
serves as a basis for the modeling of function. It also enables the engineer to
develop models of functional and information domains at the same time.

4. State Transition Diagram:

It shows various modes of behavior (states) of the system and also shows the
transitions from one state to another state in the system. It also provides the
details of how the system behaves due to the consequences of external events.
It represents the behavior of a system by presenting its states and the events
that cause the system to change state. It also describes what actions are taken
due to the occurrence of a particular event.

5. Process Specification:
It stores the description of each function present in the data flow diagram. It
describes the input to a function, the algorithm that is applied for the
transformation of input, and the output that is produced. It also shows regulations
and barriers imposed on the performance characteristics that are applicable to
the process and layout constraints that could influence the way in which the
process will be implemented.
 6. Control Specification:
It stores additional information about the control aspects of the software. It is
used to indicate how the software behaves when an event occurs and which
processes are invoked due to the occurrence of the event. It also provides the
details of the processes which are executed to manage events.

7. Data Object Description:

It stores and provides complete knowledge about a data object present and used
in the software. It also gives us the details of attributes of the data object present
in the Entity Relationship Diagram. Hence, it incorporates all the data objects and
their attributes.

Object Oriented Methodologies

● It is a new system development approach, encouraging and facilitating re-use of
software components.
● It employs the international standard Unified Modeling Language (UML) from the Object
Management Group (OMG).
● Using this methodology, a system can be developed on a component basis, which
enables the effective re-use of existing components, and facilitates the sharing of its
other system components.
● Object Oriented Methodology asks the analyst to determine what the objects of the
system are?, What responsibilities and relationships an object has to do with the other
objects? and How do they behave over time?

There are three types of Object Oriented Methodologies

1. Object Modeling Techniques (OMT)
2. Object Process Methodology (OPM)
3. Rational Unified Process (RUP)

1. Object Modeling Techniques (OMT)

• It was one of the first object oriented methodologies and was introduced by Rumbaugh in
1991.
• OMT uses three different models that are combined in a way that is analogous to the older
structured methodologies.
a. Analysis
• The main goal of the analysis is to build models of the world.
• The requirements of the users, developers and managers provide the information needed to
develop the initial problem statement.
b. OMT Models
I. Object Model
• It depicts the object classes and their relationships as a class diagram, which represents the
static structure of the system.
• It observes all the objects as static and does not pay any attention to their dynamic nature.
II. Dynamic Model
• It captures the behavior of the system over time and the flow control and events in the
Event-Trace Diagrams and State Transition Diagrams.
• It portrays the changes occurring in the states of various objects with the events that might
occur in the system.
III. Functional Model
• It describes the data transformations of the system.
• It describes the flow of data and the changes that occur to the data throughout the system. c.
Design
• It specifies all of the details needed to describe how the system will be implemented.
• In this phase, the details of the system analysis and system design are implemented.
• The objects identified in the system design phase are designed.

2. Object Process Methodology (OPM)

• It is also called as second generation methodology.
• It was first introduced in 1995.
• It has only one diagram that is the Object Process Diagram (OPD) which is used for modeling
the structure, function and behavior of the system.
• It has a strong emphasis on modeling but has a weaker emphasis on process.
• It consists of three main processes:

I. Initiating: It determines high level requirements, the scope of the system and the
resources that will be required.
 II. Developing: It involves the detailed analysis, design and implementation of the
system.
III. Deploying: It introduces the system to the user and subsequent maintenance of the
system.

3. Rational Unified Process (RUP)

• It was developed in Rational Corporation in 1998.
• It consists of four phases which can be broken down into iterations.
I. Inception II. Elaboration III. Construction IV. Transition

• Each iteration consists of nine work areas called disciplines.

• A discipline depends on the phase in which the iteration is taking place.
• For each discipline, RUP defines a set of artefacts (work products), activities (work undertaken
on the artefacts) and roles (the responsibilities of the members of the development team).

Objectives of Object Oriented Methodologies

• To encourage greater re-use.
• To produce a more detailed specification of system constraints.
• To have fewer problems with validation (Are we building the right product?).

Benefits of Object Oriented Methodologies

1. It represents the problem domain, because it is easier to produce and understand designs.
2. It allows changes more easily.
3. It provides nice structures for thinking, abstracting and leads to modular design.
4. Simplicity:
• The software object's model complexity is reduced and the program structure is very clear.
5. Reusability:
• It is a desired goal of all development process.
• It contains both data and functions which act on data.
• It makes easy to reuse the code in a new system.
• Messages provide a predefined interface to an object's data and functionality.
6. Increased Quality:
• This feature increases in quality is largely a by-product of this program reuse.
7. Maintainable:
• The OOP method makes code more maintainable.
• The objects can be maintained separately, making locating and fixing problems easier. 8.
Scalable:
• The object oriented applications are more scalable than structured approach.
• It makes easy to replace the old and aging code with faster algorithms and newer technology.
9. Modularity:
• The OOD systems are easier to modify.
• It can be altered in fundamental ways without ever breaking up since changes are neatly
encapsulated.
10. Modifiability:
• It is easy to make minor changes in the data representation or the procedures in an object
oriented program.
11. Client/Server Architecture:
• It involves the transmission of messages back and forth over a network.

Use case diagrams

A use case diagram is used to represent the dynamic behavior of a system. It encapsulates the
system's functionality by incorporating use cases, actors, and their relationships. It models the
tasks, services, and functions required by a system/subsystem of an application. It depicts the
high-level functionality of a system and also tells how the user handles a system.

Purpose of Use Case Diagrams

The main purpose of a use case diagram is to portray the dynamic aspect of a system. It
accumulates the system's requirement, which includes both internal as well as external
influences. It invokes persons, use cases, and several things that invoke the actors and
elements accountable for the implementation of use case diagrams. It represents how an entity
from the external environment can interact with a part of the system.
Following are the purposes of a use case diagram given below:
1. It gathers the system's needs.
2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.
Notation Description Visual Representation

Actor
● Someone interacts with use case (system function).
● Named by noun.
● Actor plays a role in the business
● Similar to the concept of user, but a user can play
different roles
● For example:
● A prof. can be instructor and also researcher
● plays 2 roles with two systems
● Actor triggers use case(s).
● Actor has a responsibility toward the system (inputs),
and Actor has expectations from the system (outputs).

Use Case
● System function (process - automated or manual)
● Named by verb + Noun (or Noun Phrase).
● i.e. Do something
● Each Actor must be linked to a use case, while some
use cases may not be linked to actors.

Communication Link
● The participation of an actor in a use case is shown by
connecting an actor to a use case by a solid link.
● Actors may be connected to use cases by
associations, indicating that the actor and the use case
communicate with one another using messages.
Boundary of system
● The system boundary is potentially the entire system
as defined in the requirements document.
● For large and complex systems, each module may be
the system boundary.
● For example, for an ERP system for an organization,
each of the modules such as personnel, payroll,
accounting, etc.
● can form a system boundary for use cases specific to
each of these business functions.
● The entire system can span all of these modules
depicting the overall system boundary
Structuring Use Case Diagram with Relationships
Use cases share different kinds of relationships. Defining the relationship between two use
cases is the decision of the software analysts of the use case diagram. A relationship between
two use cases is basically modeling the dependency between the two use cases. The reuse of
an existing use case by using different types of relationships reduces the overall effort required
in developing a system. Use case relationships are listed as the following:
Use Case Relationship Visual Representation

Extends
● Indicates that an "Invalid Password" use case may
include (subject to specified in the extension) the
behavior specified by base use case "Login Account".
● Depict with a directed arrow having a dotted line. The
tip of arrowhead points to the base use case and the
child use case is connected at the base of the arrow.
● The stereotype "<<extends>>" identifies as an extend
relationship
Include
● When a use case is depicted as using the functionality
of another use case, the relationship between the use
cases is named as include or uses relationship.
● A use case includes the functionality described in
another use case as a part of its business process
flow.
● A uses relationship from base use case to child use
case indicates that an instance of the base use case
will include the behavior as specified in the child use
case.
● An include relationship is depicted with a directed
arrow having a dotted line. The tip of arrowhead points
to the child use case and the parent use case
connected at the base of the arrow.
● The stereotype "<<include>>" identifies the
relationship as an include relationship.

Generalization
● A generalization relationship is a parent-child
relationship between use cases.
● The child use case is an enhancement of the parent
use case.
● Generalization is shown as a directed arrow with a
triangle arrowhead.
● The child use case is connected at the base of the
arrow. The tip of the arrow is connected to the parent
use case.
Use Case Examples

Use Case Example - Association Link

A Use Case diagram illustrates a set of use cases for a system, i.e. the actors and the
relationships between the actors and use cases.

Use Case Example - Include Relationship

The include relationship adds additional functionality not specified in the base use case. The
<<Include>> relationship is used to include common behavior from an included use case into a
base use case in order to support the reuse of common behavior.

Use Case Example - Extend Relationship

The extend relationships are important because they show optional functionality or system
behavior. The <<extend>> relationship is used to include optional behavior from an extending
use case in an extended use case. Take a look at the use case diagram example below. It
shows an extend connector and an extension point "Search".

Use Case Example - Generalization Relationship

A generalization relationship means that a child use case inherits the behavior and meaning of
the parent use case. The child may add or override the behavior of the parent. The figure below
provides a use case example by showing two generalization connectors that connect between
the three use cases.
AKASH
(1st term)
Function vs object oriented design
Requirement elicitation
Use case diagram + uses
Refactoring
System development models + needs
Basic concepts of object orientation
Extend vs include relationship
Reverse and forward engineering
Object oriented modelling
Aggregation
Generalization
Design model and implementation model
Interface vs entity vs control objects
Requirement model and analysis model
Object oriented methodologies
Encapsulation
Polymorphism
Object oriented analysis vs structured analysis

Use case diagram:

Library info system