SDLC

Waterfall Model :
Phases of Waterfall Model
Waterfall Model is a classical software development methodology that was
first introduced by Winston W. Royce in 1970. It is a linear and sequential
approach to software development that consists of several phases that must
be completed in a specific order.
The Waterfall Model has six phases:
1. Requirements Gathering and Analysis: The first phase involves
gathering requirements from stakeholders and analyzing them to understand
the scope and objectives of the project.
2. Design Phase: Once the requirements are understood, the design phase
begins. This involves creating a detailed design document that outlines the
software architecture, user interface, and system components.
3. Implementation and Unit Testing: The implementation phase involves
coding the software based on the design specifications. This phase also
includes unit testing to ensure that each component of the software is
working as expected.
4. Integration and System Testing: In the testing phase, the software is
tested as a whole to ensure that it meets the requirements and is free from
defects.
5. Deployment: Once the software has been tested and approved, it is
deployed to the production environment.
6. Maintenance: The final phase of the Waterfall Model is maintenance,
which involves fixing any issues that arise after the software has been
deployed and ensuring that it continues to meet the requirements over time.
The classical waterfall model divides the life cycle into a set of phases. This
model considers that one phase can be started after the completion of the
previous phase. That is the output of one phase will be the input to the next
phase. Thus the development process can be considered as a sequential
flow in the waterfall. Here the phases do not overlap with each other. The
different sequential phases of the classical waterfall model are shown in the
below figure.

Phases :
1. Feasibility Study
The main goal of this phase is to determine whether it would be financially
and technically feasible to develop the software.
The feasibility study involves understanding the problem and then
determining the various possible strategies to solve the problem. These
different identified solutions are analyzed based on their benefits and
drawbacks, The best solution is chosen and all the other phases are carried
out as per this solution
strategy.

2. Requirements Analysis and Specification

The aim of the requirement analysis and specification phase is to understand
the exact requirements of the customer and document them properly. This
phase consists of two different activities.
 Requirement gathering and analysis: Firstly all the requirements
regarding the software are gathered from the customer and then the
gathered requirements are analyzed. The goal of the analysis part is to
remove incompleteness (an incomplete requirement is one in which some
parts of the actual requirements have been omitted) and inconsistencies
(an inconsistent requirement is one in which some part of the requirement
contradicts some other part).
 Requirement specification: These analyzed requirements are
documented in a software requirement specification (SRS) document.
SRS document serves as a contract between the development team and
customers. Any future dispute between the customers and the developers
can be settled by examining the SRS document.
3. Design
The goal of this phase is to convert the requirements acquired in the SRS
into a format that can be coded in a programming language. It includes high-
level and detailed design as well as the overall software architecture.
A Software Design Document is used to document all of this effort (SDD).
4. Coding and Unit Testing
In the coding phase software design is translated into source code using any
suitable programming language. Thus each designed module is coded. The
aim of the unit testing phase is to check whether each module is working
properly or not.
5. Integration and System testing
Integration of different modules is undertaken soon after they have been
coded and unit tested. Integration of various modules is carried out
incrementally over a number of steps. During each integration step,
previously planned modules are added to the partially integrated system and
the resultant system is tested. Finally, after all the modules have been
successfully integrated and tested, the full working system is obtained and
system testing is carried out on this.
System testing consists of three different kinds of testing activities as
described below.
 Alpha testing: Alpha testing is the system testing performed by the
development team.
 Beta testing: Beta testing is the system testing performed by a friendly
set of customers.
 Acceptance testing: After the software has been delivered, the customer
performed acceptance testing to determine whether to accept the
delivered software or reject it.
6. Maintenance
Maintenance is the most important phase of a software life cycle. The effort
spent on maintenance is 60% of the total effort spent to develop a full
software. There are basically three types of maintenance.
 Corrective Maintenance: This type of maintenance is carried out to
correct errors that were not discovered during the product development
phase.
 Perfective Maintenance: This type of maintenance is carried out to
enhance the functionalities of the system based on the customer’s
request.
 Adaptive Maintenance: Adaptive maintenance is usually required for
porting the software to work in a new environment such as working on a
new computer platform or with a new operating system.
Advantages of Classical Waterfall Model
The classical waterfall model is an idealistic model for software development.
It is very simple, so it can be considered the basis for other software
development life cycle models. Below are some of the major advantages of
this SDLC model.
 Easy to Understand: Classical Waterfall Model is very simple and easy
to understand.
 Individual Processing: Phases in the Classical Waterfall model are
processed one at a time.
 Properly Defined: In the classical waterfall model, each stage in the
model is clearly defined.
 Clear Milestones: Classical Waterfall model has very clear and well-
understood milestones.
 Properly Documented: Processes, actions, and results are very well
documented.
 Reinforces Good Habits: Classical Waterfall Model reinforces good
habits like define-before-design and design-before-code.
 Working: Classical Waterfall Model works well for smaller projects and
projects where requirements are well understood.

Disadvantages of Classical Waterfall Model

The Classical Waterfall Model suffers from various shortcomings, basically,
we can’t use it in real projects, but we use other software development
lifecycle models which are based on the classical waterfall model. Below are
some major drawbacks of this model.
 No Feedback Path: In the classical waterfall model evolution of software
from one phase to another phase is like a waterfall. It assumes that no
error is ever committed by developers during any phase. Therefore, it
does not incorporate any mechanism for error correction.
 Difficult to accommodate Change Requests: This model assumes that
all the customer requirements can be completely and correctly defined at
the beginning of the project, but actually customer’s requirements keep on
changing with time. It is difficult to accommodate any change requests
after the requirements specification phase is complete.
 No Overlapping of Phases: This model recommends that a new phase
can start only after the completion of the previous phase. But in real
projects, this can’t be maintained. To increase efficiency and reduce cost,
phases may overlap.
 Limited Flexibility: The Waterfall Model is a rigid and linear approach to
software development, which means that it is not well-suited for projects
with changing or uncertain requirements. Once a phase has been
completed, it is difficult to make changes or go back to a previous phase.
 Limited Stakeholder Involvement: The Waterfall Model is a structured
and sequential approach, which means that stakeholders are typically
involved in the early phases of the project (requirements gathering and
analysis) but may not be involved in the later phases (implementation,
testing, and deployment).
 Late Defect Detection: In the Waterfall Model, testing is typically done
toward the end of the development process. This means that defects may
not be discovered until late in the development process, which can be
expensive and time-consuming to fix.
 Lengthy Development Cycle: The Waterfall Model can result in a
lengthy development cycle, as each phase must be completed before
moving on to the next. This can result in delays and increased costs if
requirements change or new issues arise.
 Not Suitable for Complex Projects: The Waterfall Model is not well-
suited for complex projects, as the linear and sequential nature of the
model can make it difficult to manage multiple dependencies and
interrelated components.
When to Use Waterfall Model?
Here are some cases where use of Waterfall Model is best suited:
 Only well-defined, unambiguous, and fixed requirements are employed
with this paradigm.
 The definition of a product is constant.
 People understand technology.
 There are no unclear prerequisites.
 There are many resources with the necessary knowledge readily
available.
 When it’s a brief project.
The Waterfall approach involves little client engagement in the product
development process. The product can only be shown to end consumers
when it is ready.
Applications of Classical Waterfall Model
 Large-scale Software Development Projects: The Waterfall Model is
often used for large-scale software development projects, where a
structured and sequential approach is necessary to ensure that the
project is completed on time and within budget.
 Safety-Critical Systems: The Waterfall Model is often used in the
development of safety-critical systems, such as aerospace or medical
systems, where the consequences of errors or defects can be severe.
 Government and Defense Projects: The Waterfall Model is also
commonly used in government and defense projects, where a rigorous
and structured approach is necessary to ensure that the project meets all
requirements and is delivered on time.
 Projects with well-defined Requirements: The Waterfall Model is best
suited for projects with well-defined requirements, as the sequential
nature of the model requires a clear understanding of the project
objectives and scope.
 Projects with Stable Requirements: The Waterfall Model is also well-
suited for projects with stable requirements, as the linear nature of the
model does not allow for changes to be made once a phase has been
completed.
V Model

1. Requirements Gathering and Analysis : The first phase of the V-Model

is the requirements gathering and analysis phase, where the customer’s
requirements for the software are gathered and analyzed to determine the
scope of the project.
2. Design: In the design phase, the software architecture and design are
developed, including the high-level design and detailed design.
3. Implementation: In the implementation phase, the software is actually
built based on the design.
4. Testing: In the testing phase, the software is tested to ensure that it
meets the customer’s requirements and is of high quality.
5. Deployment: In the deployment phase, the software is deployed and put
into use.
6. Maintenance: In the maintenance phase, the software is maintained to
ensure that it continues to meet the customer’s needs and expectations.
7. The V-Model is often used in safety: critical systems, such as
aerospace and defence systems, because of its emphasis on thorough
testing and its ability to clearly define the steps involved in the software
development process.
The following illustration depicts the different phases in a V-Model of
the SDLC.

A.Verification Phases:
It involves static analysis technique (review) done without executing code. It
is the process of evaluation of the product development phase to find
whether specified requirements meet.
There are several Varification phases in the V-Model:

I.Business Requirement Analysis:

These is the first step of the designation of development cycle where product
requirement needs to be cure with the customer perspectives. in these
phases include the proper communication with the customer to understand
the requirement of the customers. these is the very important activity which
need to handle with proper way, as most of the time customer did not know
exact what they want, and they did not sure about it that time then we use
an acceptance test design planning which done at the time of business
requirement it will be used as an input for acceptance testing.

II.System Design:

Design of system will start when the overall we clear with the product
requirements, then need to design the system completely. these
understanding will do at the beginning of complete under the product
development process. these will be beneficial for the future execution of test
cases.

III.Architectural Design:

In this stage, architectural specifications are comprehended and designed.

Usually, a number of technical approaches are put out, and the ultimate
choice is made after considering both the technical and financial viability.
The system architecture is further divided into modules that each handle a
distinct function. Another name for this is High Level Design (HLD)
At this point, the exchange of data and communication between the internal
modules and external systems are well understood and defined. During this
phase, integration tests can be created and documented using the
information provided.

IV.Module Design:
This phase, known as Low Level Design (LLD), specifies the comprehensive
internal design for each and every system module. Compatibility between the
design and other external systems as well as other modules in the system
architecture is crucial. Unit tests are a crucial component of any development
process since they assist identify and eradicate the majority of mistakes and
flaws at an early stage. Based on the internal module designs, these unit
tests may now be created.

V.Coding Phase:

The Coding step involves actually writing the code for the system modules
that were created during the Design phase. The system and architectural
requirements are used to determine which programming language is most
appropriate.
The coding standards and principles are followed when performing the
coding. Before the final build is checked into the repository, the code
undergoes many code reviews and is optimised for optimal performance.

Validation Phases:

It involves dynamic analysis technique (functional, non-functional), testing

done by executing code. Validation is the process to evaluate the software
after the completion of the development phase to determine whether
software meets the customer expectations and requirements.

So, V-Model contains Verification phases on one side of the Validation

phases on the other side. Verification and Validation phases are joined by
coding phase in V-shape. Thus, it is called V-Model.

There are several Validation phases in the V-Model:

Unit Testing:
Unit Test Plans are developed during module design phase. These Unit Test
Plans are executed to eliminate bugs at code or unit level.

Integration testing:
After completion of unit testing Integration testing is performed. In integration
testing, the modules are integrated and the system is tested. Integration
testing is performed on the Architecture design phase. This test verifies the
communication of modules among themselves.

System Testing:
System testing test the complete application with its functionality, inter
dependency, and communication. It tests the functional and non-functional
requirements of the developed application.

User Acceptance Testing (UAT):

UAT is performed in a user environment that resembles the production
environment. UAT verifies that the delivered system meets user’s
requirement and system is ready for use in real world.
Design Phase:

 Requirement Analysis: This phase contains detailed communication

with the customer to understand their requirements and expectations.
This stage is known as Requirement Gathering.
 System Design: This phase contains the system design and the
complete hardware and communication setup for developing product.
 Architectural Design: System design is broken down further into
modules taking up different functionalities. The data transfer and
communication between the internal modules and with the outside world
(other systems) is clearly understood.
 Module Design: In this phase the system breaks down into small
modules. The detailed design of modules is specified, also known as
Low-Level Design (LLD).

Testing Phases:

 Unit Testing: Unit Test Plans are developed during module design
phase. These Unit Test Plans are executed to eliminate bugs at code or
unit level.

 Integration testing: After completion of unit testing Integration testing is

performed. In integration testing, the modules are integrated, and the
system is tested. Integration testing is performed on the Architecture
design phase. This test verifies the communication of modules among
themselves.

 System Testing: System testing test the complete application with its
functionality, inter dependency, and communication. It tests the functional
and non-functional requirements of the developed application.

 User Acceptance Testing (UAT): UAT is performed in a user

environment that resembles the production environment. UAT verifies that
the delivered system meets user’s requirement and system is ready for
use in real world.

Industrial Challenge:

As the industry has evolved, the technologies have become more complex,
increasingly faster, and forever changing, however, there remains a set of
basic principles and concepts that are as applicable today as when IT was in
its infancy.
 Accurately define and refine user requirements.
 Design and build an application according to the authorized user
requirements.
 Validate that the application they had built adhered to the authorized
business requirements.

Principles of V-Model:
 Large to Small: In V-Model, testing is done in a hierarchical perspective,
for example, requirements identified by the project team, create High-
Level Design, and Detailed Design phases of the project. As each of
these phases is completed the requirements, they are defining become
more and more refined and detailed.
 Data/Process Integrity: This principle states that the successful design
of any project requires the incorporation and cohesion of both data and
processes. Process elements must be identified at each and every
requirement.
 Scalability: This principle states that the V-Model concept has the
flexibility to accommodate any IT project irrespective of its size,
complexity or duration.
 Cross Referencing: Direct correlation between requirements and
corresponding testing activity is known as cross-referencing.

Tangible Documentation:
This principle states that every project needs to create a document. This
documentation is required and applied by both the project development team
and the support team. Documentation is used to maintaining the application
once it is available in a production environment.

Why preferred?

 It is easy to manage due to the rigidity of the model. Each phase of V-

Model has specific deliverables and a review process.
 Proactive defect tracking – that is defects are found at early stage.

When to use?

 Where requirements are clearly defined and fixed.

 The V-Model is used when ample technical resources are available with
technical expertise.
 Small to medium-sized projects with set and clearly specified needs are
recommended to use the V-shaped model.
 Since it is challenging to keep stable needs in large projects, the project
should be small.

Advantages:

 This is a highly disciplined model and Phases are completed one at a

time.
 V-Model is used for small projects where project requirements are clear.
 Simple and easy to understand and use.
 This model focuses on verification and validation activities early in the life
cycle thereby enhancing the probability of building an error-free and good
quality product.
 It enables project management to track progress accurately.
 Clear and Structured Process: The V-Model provides a clear and
structured process for software development, making it easier to
understand and follow.
 Emphasis on Testing: The V-Model places a strong emphasis on testing,
which helps to ensure the quality and reliability of the software.
 Improved Traceability: The V-Model provides a clear link between the
requirements and the final product, making it easier to trace and manage
changes to the software.
 Better Communication: The clear structure of the V-Model helps to
improve communication between the customer and the development
team.

Disadvantages:
 High risk and uncertainty.
 It is not a good for complex and object-oriented projects.
 It is not suitable for projects where requirements are not clear and
contains high risk of changing.
 This model does not support iteration of phases.
 It does not easily handle concurrent events.
 Inflexibility: The V-Model is a linear and sequential model, which can
make it difficult to adapt to changing requirements or unexpected events.
 Time-Consuming: The V-Model can be time-consuming, as it requires a
lot of documentation and testing.
 Overreliance on Documentation: The V-Model places a strong emphasis
on documentation, which can lead to an overreliance on documentation at
the expense of actual development work.

Prototyping Model
Prototyping is defined as the process of developing a working replication of a product
or system that has to be engineered. It offers a small-scale facsimile of the end product
and is used for obtaining customer feedback. The Prototyping concept is described
below:
The Prototyping Model is one of the most popularly used Software Development Life
Cycle Models (SDLC models). This model is used when the customers do not know
the exact project requirements beforehand. In this model, a prototype of the end
product is first developed, tested, and refined as per customer feedback repeatedly till
a final acceptable prototype is achieved which forms the basis for developing the final
product.

In this process model, the system is partially implemented before or during

the analysis phase thereby giving the customers an opportunity to see the
product early in the life cycle. The process starts by interviewing the
customers and developing the incomplete high-level paper model. This
document is used to build the initial prototype supporting only the basic
functionality as desired by the customer. Once the customer figures out the
problems, the prototype is further refined to eliminate them. The process
continues until the user approves the prototype and finds the working model
to be satisfactory.

Software Prototyping Model is a software development methodology that

involves creating an initial prototype of the software product before
developing the final product. The prototype is a working model of the
software product that can be used to gather feedback and refine the design
before the final product is developed. The prototyping model is particularly
useful for projects where the requirements are not well-defined or are likely
to change over time. The prototyping model can help to reduce the risk of
developing a software product that does not meet the needs of end-users or
stakeholders, while also reducing development time and cost. The prototype
can be developed using different methods, such as throwaway prototyping,
evolutionary prototyping, and incremental prototyping. The prototyping model
can be used in conjunction with other software development methodologies,
such as agile development, to create software products that meet the needs
of end-users and stakeholders.
Prototyping is a software development methodology that focuses on the use
of working models that are constantly refined based on feedback from the
end user. Prototyping is most commonly used to develop systems with
significant end-user interaction and complex user interfaces.
Because it allows for the capture of customer requirements at an early stage
of development, software prototyping is becoming increasingly popular as a
software development model. It allows for valuable customer feedback and
assists software designers and developers in understanding what is
expected directly from sales.
The term “software prototyping” refers to the process of creating software
application prototypes that demonstrate the functionality of the product under
development but may not contain the exact logic of the original software.
What is Software Prototyping?
 A prototype can be a limited-functionality software performance model.
 The prototype does not always contain the exact logic used in the specific
software application and is an additional effort to be considered when
estimating effort.
 Prototyping is used to allow users to evaluate and test developer
proposals before they are implemented.
 It also aids in understanding the user-specific requirements that will not
be considered by the developer during product design.
Prototyping Model Phases:
Prototyping Model has six SDLC phases as follows
Step-1: Requirements gathering and analysis :
Requirement analysis is the first step in developing a prototyping model.
During this phase, the system’s desires are precisely defined. During the
method, system users are interviewed to determine what they expect from
the system.
Step-2: Quick design :
The second phase could consist of a preliminary design or a quick design.
During this stage, the system’s basic design is formed. However, it is not a
complete design. It provides the user with a quick overview of the system.
The rapid design aids in the development of the prototype.
Step-3: Build a Prototype :
During this stage, an actual prototype is intended to support the knowledge
gained from quick design. It is a small low-level working model of the desired
system.
Step-4: Initial user evaluation :
The proposed system is presented to the client for preliminary testing at this
stage. It is beneficial to investigate the performance model’s strengths and
weaknesses. Customer feedback and suggestions are gathered and
forwarded to the developer.
Step-5: Refining prototype :
If the user is dissatisfied with the current model, you may want to improve
the type that responds to user feedback and suggestions. When the user is
satisfied with the upgraded model, a final system based on the approved
final type is created.
Step-6: Implement Product and Maintain :
The final system was fully tested and distributed to production after it was
developed to support the original version. To reduce downtime and prevent
major failures, the programmer is run on a regular basis.

Types of Prototyping Model:

Four types of Prototyping models are :
1. Rapid Throwaway prototypes
2. Evolutionary prototype
3. Incremental prototype
4. Extreme prototype
1. Rapid Throwaway Prototype :
The preliminary requirement is used for quick throwaway. It is quickly
developed to show how the need will appear visually. Customer feedback
aids in the movement of demand change, and the prototype is re-created
until the need is basic. As a result, the upgraded version is rejected and
cannot be the last accepted type. This programme aids in the testing of ideas
and the rapid response to customer needs.
2. Evolutionary Prototyping :
It assists you in avoiding both time and effort waste. This is due to the fact
that performing a specific type from the start of each method of
communication can be time-consuming. This model is useful for a project
that involves the use of an unknown replacement technology. It is also used
in high-end projects where each feature must be tested only once. It’s useful
when the need isn’t stable or isn’t clearly understood at the start.
3. Incremental Prototyping :
The final product is decimated into small prototypes and developed
individually in incremental prototyping. The various prototypes are eventually
combined into a single product. This method is useful for reducing feedback
time between the user and, consequently, the application development team.
4. Extreme Prototyping :
The extreme prototyping method is commonly used in web development. It is
divided into three stages that must be completed in order.
1. The HTML format contains a basic prototype of the current page.
2. A prototype services layer will allow you to simulate data processes.
3. The services are built and integrated into the final prototype.
Software Prototyping Application :
Software prototyping is extremely beneficial in the development of systems
that require a high level of user interaction, such as online applications.
Systems that require users to fill out forms or view various screens before
data is processed can benefit greatly from prototyping in order to convey the
exact look and feel even before the software is developed. Prototyping is
usually not an option for software that involves a large amount of information
processing and the majority of the functionality is internal with little
programme. Prototype development can be an additional overhead in such
projects and should necessitate a significant amount of additional effort.
Advantages of Software Prototyping :
 Users help to shape the future. As a result, errors can be discovered
during the first stage of the software development process.
 Prototyping is also considered a risk reduction function because it allows
non-existent performance to be seen, lowering the risk of failure.
 Assists team members in effectively communicating.
 Customer satisfaction exists, and he can feel the product from the start.
 There will be no risk of software loss.
 Quick user feedback aids in the development of better software solutions.
Disadvantages of Software Prototyping :
 Prototyping is a time-consuming and labor-intensive process.
 The cost of creating a specific type of waste is completely wasted
because the prototype is eventually discarded.
 Prototyping may result in an overabundance of change requests.
 Customers may be unwilling to commit to the iteration cycle for an
extended period of time.
 During each customer test, there may be too many variations in software
requirements.
 Poor documentation as a result of changing customer needs.
Spiral Model :

Spiral Model is one of the most important Software Development Life Cycle
models, which provides support for Risk Handling. This article focuses on
discussing the Spiral Model in detail.

What is the Spiral Model?

The Spiral Model is a Software Development Life Cycle (SDLC) model that
provides a systematic and iterative approach to software development. In its
diagrammatic representation, looks like a spiral with many loops. The exact
number of loops of the spiral is unknown and can vary from project to
project. Each loop of the spiral is called a Phase of the software
development process.
1. The exact number of phases needed to develop the product can be varied
by the project manager depending upon the project risks.
2. As the project manager dynamically determines the number of phases,
the project manager has an important role in developing a product using
the spiral model.
3. It is based on the idea of a spiral, with each iteration of the spiral
representing a complete software development cycle, from requirements
gathering and analysis to design, implementation, testing, and
maintenance.
What Are the Phases of Spiral Model?
The Spiral Model is a risk-driven model, meaning that the focus is on
managing risk through multiple iterations of the software development
process. It consists of the following phases:
1. Planning
The first phase of the Spiral Model is the planning phase, where the scope of
the project is determined and a plan is created for the next iteration of the
spiral.

2. Risk Analysis
In the risk analysis phase, the risks associated with the project are identified
and evaluated.
3. Engineering
In the engineering phase, the software is developed based on the
requirements gathered in the previous iteration.
4. Evaluation
In the evaluation phase, the software is evaluated to determine if it meets the
customer’s requirements and if it is of high quality.
5. Planning
The next iteration of the spiral begins with a new planning phase, based on
the results of the evaluation.
The Spiral Model is often used for complex and large software development
projects, as it allows for a more flexible and adaptable approach to software
development. It is also well-suited to projects with significant uncertainty or
high levels of risk.
The Radius of the spiral at any point represents the expenses(cost) of the
project so far, and the angular dimension represents the progress made so
far in the current phase.

Each phase of the Spiral Model is divided into four quadrants as shown in the above figure. The
functions of these four quadrants are discussed below:
1. Objectives determination and identify alternative solutions: Requirements are gathered
from the customers and the objectives are identified, elaborated, and analyzed at the start
of every phase. Then alternative solutions possible for the phase are proposed in this
quadrant.
2. Identify and resolve Risks: During the second quadrant, all the possible solutions are
evaluated to select the best possible solution. Then the risks associated with that solution
are identified and the risks are resolved using the best possible strategy. At the end of this
quadrant, the Prototype is built for the best possible solution.
3. Develop the next version of the Product: During the third quadrant, the identified features
are developed and verified through testing. At the end of the third quadrant, the next
version of the software is available.
 4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so-
far developed version of the software. In the end, planning for the next phase is started.

Advantages of the Spiral Model

Below are some advantages of the Spiral Model.
1. Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development
model to follow due to the risk analysis and risk handling at every phase.
2. Good for large projects: It is recommended to use the Spiral Model in
large and complex projects.
3. Flexibility in Requirements: Change requests in the Requirements at a
later phase can be incorporated accurately by using this model.
4. Customer Satisfaction: Customers can see the development of the
product at the early phase of the software development and thus, they
habituated with the system by using it before completion of the total
product.
5. Iterative and Incremental Approach: The Spiral Model provides an
iterative and incremental approach to software development, allowing for
flexibility and adaptability in response to changing requirements or
unexpected events.
6. Emphasis on Risk Management: The Spiral Model places a strong
emphasis on risk management, which helps to minimize the impact of
uncertainty and risk on the software development process.
7. Improved Communication: The Spiral Model provides for regular
evaluations and reviews, which can improve communication between the
customer and the development team.
8. Improved Quality: The Spiral Model allows for multiple iterations of the
software development process, which can result in improved software
quality and reliability.
Disadvantages of the Spiral Model
Below are some main disadvantages of the spiral model.
1. Complex: The Spiral Model is much more complex than other SDLC
models.
2. Expensive: Spiral Model is not suitable for small projects as it is
expensive.
3. Too much dependability on Risk Analysis: The successful completion
of the project is very much dependent on Risk Analysis. Without very
highly experienced experts, it is going to be a failure to develop a project
using this model.
4. Difficulty in time management: As the number of phases is unknown at
the start of the project, time estimation is very difficult.
5. Complexity: The Spiral Model can be complex, as it involves multiple
iterations of the software development process.
6. Time-Consuming: The Spiral Model can be time-consuming, as it
requires multiple evaluations and reviews.
7. Resource Intensive: The Spiral Model can be resource-intensive, as it
requires a significant investment in planning, risk analysis, and
evaluations.
The most serious issue we face in the cascade model is that taking a long
length to finish the item, and the product became obsolete. To tackle this
issue, we have another methodology, which is known as the Winding model
or spiral model. The winding model is otherwise called the cyclic model.
When To Use the Spiral Model?
1. When a project is vast in software engineering, a spiral model is utilized.
2. A spiral approach is utilized when frequent releases are necessary.
3. When it is appropriate to create a prototype
4. When evaluating risks and costs is crucial
5. The spiral approach is beneficial for projects with moderate to high risk.
6. The SDLC’s spiral model is helpful when requirements are complicated
and ambiguous.
7. If modifications are possible at any moment
8. When committing to a long-term project is impractical owing to shifting
economic priorities.

RAD Model

The Rapid Application Development Model was first proposed by IBM in the
1980s. The RAD model is a type of incremental process model in which
there is an extremely short development cycle. When the requirements are
fully understood and the component-based construction approach is adopted
then the RAD model is used. Various phases in RAD are Requirements
Gathering, Analysis and Planning, Design, Build or Construction, and finally
Deployment.
The critical feature of this model is the use of powerful development tools
and techniques. A software project can be implemented using this model if
the project can be broken down into small modules wherein each module
can be assigned independently to separate teams. These modules can
finally be combined to form the final product. Development of each module
involves the various basic steps as in the waterfall model i.e. analyzing,
designing, coding, and then testing, etc. as shown in the figure. Another
striking feature of this model is a short period i.e. the time frame for
delivery(time-box) is generally 60-90 days.
Multiple teams work on developing the software system using the RAD
model parallely.
1. Requirements Planning – It involves the use of various techniques used
in requirements elicitation like brainstorming, task analysis, form analysis,
user scenarios, FAST (Facilitated Application Development Technique),
etc. It also consists of the entire structured plan describing the critical
data, methods to obtain it, and then processing it to form a final refined
model.
2. User Description – This phase consists of taking user feedback and
building the prototype using developer tools. In other words, it includes re-
examination and validation of the data collected in the first phase. The
dataset attributes are also identified and elucidated in this phase.
3. Construction – In this phase, refinement of the prototype and delivery
takes place. It includes the actual use of powerful automated tools to
transform processes and data models into the final working product. All
the required modifications and enhancements are too done in this phase.
4. Cutover – All the interfaces between the independent modules developed
by separate teams have to be tested properly. The use of powerfully
automated tools and subparts makes testing easier. This is followed by
acceptance testing by the user.
The process involves building a rapid prototype, delivering it to the customer,
and taking feedback. After validation by the customer, the SRS document is
developed and the design is finalized.
When to use RAD Model?
When the customer has well-known requirements, the user is involved
throughout the life cycle, the project can be time-boxed, the functionality
delivered in increments, high performance is not required, low technical risks
are involved and the system can be modularized. In these cases, we can use
the RAD Model. when it is necessary to design a system that can be divided
into smaller units within two to three months. when there is enough money in
the budget to pay for both the expense of automated tools for code creation
and designers for modeling.
Advantages:
 The use of reusable components helps to reduce the cycle time of the
project.
 Feedback from the customer is available at the initial stages.
 Reduced costs as fewer developers are required.
 The use of powerful development tools results in better quality products in
comparatively shorter time spans.
 The progress and development of the project can be measured through
the various stages.
 It is easier to accommodate changing requirements due to the short
iteration time spans.
 Productivity may be quickly boosted with a lower number of employees.
Disadvantages:
 The use of powerful and efficient tools requires highly skilled
professionals.
 The absence of reusable components can lead to the failure of the
project.
 The team leader must work closely with the developers and customers to
close the project on time.
 The systems which cannot be modularized suitably cannot use this
model.
 Customer involvement is required throughout the life cycle.
 It is not meant for small-scale projects as in such cases, the cost of using
automated tools and techniques may exceed the entire budget of the
project.
 Not every application can be used with RAD.
Applications:
1. This model should be used for a system with known requirements and
requiring a short development time.
2. It is also suitable for projects where requirements can be modularized and
reusable components are also available for development.
3. The model can also be used when already existing system components
can be used in developing a new system with minimum changes.
4. This model can only be used if the teams consist of domain experts. This
is because relevant knowledge and the ability to use powerful techniques
are a necessity.
5. The model should be chosen when the budget permits the use of
automated tools and techniques required.
Drawbacks of rapid application development:
 It requires multiple teams or a large number of people to work on the
scalable projects.
 This model requires heavily committed developer and customers. If
commitment is lacking then RAD projects will fail.
 The projects using RAD model requires heavy resources.
 If there is no appropriate modularization then RAD projects fail.
Performance can be problem to such projects.
 The projects using RAD model find it difficult to adopt new technologies.

Ppk@1981
 CHAPTER 2

Object-oriented refers to a programming language, system or software methodology that is built on

the concepts of logical objects. It works through the creation, utilization and manipulation of reusable
objects to perform a specific task, process or objective.

Object oriented is a computer science concept that has been widely implemented, specifically
in programming languages and applications/software. The object-oriented technique is
different from conventional programming, which focuses on functions/behaviors, while
object-oriented works on the interactions of one or more objects.

An object-oriented based system is modeled and created through the use of objects, where
each object's class instance has specific attributes and behaviors, and the relative methods or
behaviors are called to manipulate or utilize such a system. The essence of object-oriented is
that each of the created objects can be reused in the same and other programs and
applications.

Object-oriented programming (OOP) is a computer programming model that

organizes software design around data, or objects, rather than functions and logic.
An object can be defined as a data field that has unique attributes and behavior.

OOP focuses on the objects that developers want to manipulate rather than the
logic required to manipulate them. This approach to programming is well-suited
for programs that are large, complex and actively updated or maintained. This
includes programs for manufacturing and design, as well as mobile applications;
for example, OOP can be used for manufacturing system simulation software.

The organization of an object-oriented program also makes the method beneficial

to collaborative development, where projects are divided into groups. Additional
benefits of OOP include code reusability, scalability and efficiency.

The first step in OOP is to collect all of the objects a programmer wants to
manipulate and identify how they relate to each other -- an exercise known as data
modeling.
Examples of an object can range from physical entities, such as a human being
who is described by properties like name and address, to small computer programs,
such as widgets.

Once an object is known, it is labeled with a class of objects that defines the kind
of data it contains and any logic sequences that can manipulate it. Each distinct
logic sequence is known as a method. Objects can communicate with well-defined
interfaces called messages.

What is the structure of object-oriented

programming?
The structure, or building blocks, of object-oriented programming include the
following:

 Classes are user-defined data types that act as the blueprint for individual
objects, attributes and methods.

 Objects are instances of a class created with specifically defined data. Objects
can correspond to real-world objects or an abstract entity. When class is defined
initially, the description is the only object that is defined.

 Methods are functions that are defined inside a class that describe the
behaviors of an object. Each method contained in class definitions starts with a
reference to an instance object. Additionally, the subroutines contained in an
object are called instance methods. Programmers use methods for reusability or
keeping functionality encapsulated inside one object at a time.

 Attributes are defined in the class template and represent the state of an object.
Objects will have data stored in the attributes field. Class attributes belong to
the class itself.

Inheritance:

In OOP, inheritance follows the "is-a" relationship, meaning that the derived class is a more specific
version of the base class. For example, in a class hierarchy for vehicles, a "Car" class can inherit
from a more general "Vehicle" class, as a car is a type of vehicle.
Inheritance: Inheritance is an OOP mechanism allowing a new class (the derived or child class) to
acquire the properties and methods of an existing class (the base or parent class).

Polymorphism: Polymorphism is the ability of one function or method to perform different actions
depending on the input or the type of object it is called upon. Inheritance enables polymorphism by
allowing child classes to override or extend the functionality of parent class methods.

There are various benefits of using the parent-child relationship in inheritance, including:

 Code Reusability: Inheritance allows the derived class to reuse the code from the
base class, reducing duplication and promoting maintainability.
 Code Organization: Organizing your code into a hierarchy of classes with
inheritance can make it easier to understand the relationships and dependencies
between different parts of your program.
 Modularity: With inheritance, you can modify or extend the functionality of a base
class without changing the base class itself. This modularity can enhance the
flexibility and scalability of your code.

Object-Oriented Modeling Mean?

 Object-oriented modeling (OOM) is the construction of objects using a collection of
objects that contain stored values of the instance variables found within an object.
Unlike models that are record-oriented, object-oriented values are solely objects.

The object-oriented modeling approach creates the union of the application and database
development and transforms it into a unified data model and language environment. Object-
oriented modeling allows for object identification and communication while supporting data
abstraction, inheritance and encapsulation.

Object-oriented modeling is the process of preparing and designing what the model’s code
will actually look like. During the construction or programming phase, the modeling
techniques are implemented by using a language that supports the object-oriented
programming model.

OOM consists of progressively developing object representation through three phases:

analysis, design, and implementation. During the initial stages of development, the model
developed is abstract because the external details of the system are the central focus. The
model becomes more and more detailed as it evolves, while the central focus shifts toward
understanding how the system will be constructed and how it should function.

An object model is a visual representation of a system's objects, actions, and associated attributes.
An object model can be used, in conjunction with a design system, to create a consistent experience
across a system's higher-level constructs.
An object model is a visual representation of a system’s objects, actions, and associated attributes.
An object model can be used, in conjunction with a design system, to create a consistent experience
across a system’s higher-level constructs.

Roots of Object Modeling

The whole idea of interface objects stems from the development of the graphical user
interface (GUI). With a GUI, users could directly interact with objects represented on-screen;
it was a radical departure from the command-line interfaces in use at the time. The Xerox
Star system, released in 1981, was the first commercially-available system with a GUI — and
served as inspiration for the Apple Lisa (in 1983) and later the Apple Macintosh (in 1984).

In the 1990s as software began to proliferate, development processes became more

formalized, and there was interest in representing software requirements in a consistent
manner. UML (Unified Modeling Language) was developed to meet this need. The UML
diagrams that are most likely to be familiar to UX-ers even today are the Use Case Model and
the Class Diagram.

The Use Case Model is a behavioral model and depicts the system from a task perspective
(similar to user stories in Agile).

A simple use case diagram for a banking system.

The Class Diagram is a structural model, which shows a system’s objects and the
relationship between them. Each object rectangle includes the object’s associated actions (in
the lower pane) and attributes (in the middle pane).

An example UML Class Diagram for an ATM.

Within development processes reliant on UML, there was an emphasis on object-oriented

user interface design, using the Class Diagram as the basis. And, indeed, in the 1990s whole
books were written on this methodology.

Admittedly, a complete Class Diagram can be time-consuming to complete and requires a set
of analysis skills more typical of an engineer or analyst. It’s not something a UX professional
today would typically prepare.

I would argue, however, that object-orientation is a lost and necessary part of UX design,
particularly for more complex applications.
The Narrative Object Model
What I am proposing is a simplified object model I call a Narrative Object Model —
narrative because it substantially replaces the UML notation with plain-English narrative.
Also, while the Class Diagram is highly structured, following the rules of UML, the Narrative
Object Model is lighter-weight and more flexible.

Creating a Narrative Object Model

In this next section, we’ll walk through the process of creating a model, breaking the process
into three steps:

1) Identifying the Objects

2) Characterizing the Relationship Between Objects

3) Identifying each Object’s Actions and Attributes

Source Materials for the Model

Creating the model starts with identifying the source materials you have available. What sorts
of artifacts do you have that describe or otherwise depict intended functionality?

In my consulting work, I usually am starting with an existing system that we will redesign or
re-envision in some way. Starting the model by inspecting that system’s existing interface
accomplishes two things: 1) it gets me intimately familiar with that system in its current state
2) it provides a baseline object model that can then be extended to depict the desired future-
state.

The other primary source for an object model is user stories or other requirements-oriented
artifacts. For greenfield design work, these may be the only sources available.

We’ll begin an example model by looking at an existing interface, using the relatively simple
example of Twitter.com.

First, however, it’s important to define two central concepts: an object and an action. Simply
stated, objects are the nouns in a system and actions are the verbs. In an existing interface,
menus and button bars often contain clues to a system’s objects and actions.

When working with objects, it’s also important to remember the difference between the
object, which represents the concept, and an instance of an object. For example, most systems
have the concept of an Account, which would be an object. However, there are many
instances of an Account: the account of Louise Hughes, the account of Ramon Woods, etc.

Identifying Objects
Below is a screen capture of a Tweet from Twitter.com. We have a button bar below the
Tweet and a menu (shown expanded) to the right. We’ll use these to identify some nouns
(aka objects).

In our model, the objects become titled rectangles that we will connect together to show
relationships. Here are our object rectangles so far:

A set of initial object rectangles.

We definitely can (and will) do more with our objects. However, sometimes if I’m trying to
make sense of a poorly organized system, it’s enough, at least initially, to get the objects
identified and laid out on a page.

I find the most logical next step, once I’ve identified the objects, is to identify the
relationships between objects.

Relationship Between Objects

Revisiting the UML Class Diagram, you’ll note there is a somewhat cryptic notation scheme
for depicting relationships between objects. This scheme involves notating multiplicity of the
relationship and showing relationship types using different line-end treatments.
A UML Class Diagram uses various line notations to describe the relationships between
objects.

Rather than rely on notation to characterize the relationship between objects, the Narrative
Object Model uses descriptive text. The diagram below shows the objects we’ve identified
thus far with their relationships described.

Narrative Object Model describing the relationships between objects.

The descriptions help illuminate the purpose of each object in context of the larger whole:
  An Account can send a Direct Message
 An Account can publish Tweets
 Tweets can be curated into groups call Moments

Again you could stop your model at this point, after the relationships have been defined, if
you feel the model serves your purpose. However, it can be helpful to fill in more information
about each object…specifically its associated actions and attributes.

Identifying Actions
Next, let’s identify some Actions associated with a Tweet. We can again use the button bar
and menu as a starting point:

The object Tweet with attributes (middle pane) and actions (lower pane).

Here again, I’ve retained some notation from a Class Diagram. The colon after the attribute
Text indicates the type of data — in this case, the fact that Text is limited in length (280
characters or less). I’ve only included data type for the Text attribute because I’ve deemed it
to be especially meaningful to the user experience.

Building Out the Model

Next, let’s look at our model more fully built-out, with some additional elements added to it.
Narrative Object Model for Twitter

In addition to including more objects, I’ve added some visual elements to help me interpret
the model more easily. These include:

 Indicating which objects are the core system objects (in bold outline)
 Using traditional UML line-end treatments to characterize relationships further
 Using color to associate objects with a similar purpose

Indicating Core System Objects

Not every object is of equal importance in a system. Some objects represent a system’s
unique value proposition or are otherwise central to the experience. It usually makes sense to
design conventions for the core objects first and then extend the conventions out to other
objects in the system.

For Twitter, I’ve indicated the Tweet and the Timeline objects as core, capitalizing the object
name and using a bold outline treatment.

Indicating Specific Types of Object Relationships

In the model, it can be helpful to represent specific types of relationships. Relationship types
illuminate more about the objects and how they might be treated from a design perspective.

The four main types of relationships are:

 Association
 Aggregation
 Component
 Inheritance
Association Relationship
The simplest type of relationship is an association. Here we are showing the relationship
between an Account and a Tweet with a plain line. In our Narrative Object Model, the line
contains a verbal description of the relationship; the description includes reference to both
objects (in bold).

An association relationship, indicated by a plain line.

Aggregation Relationship
An aggregation relationship indicates an object that is merely a collection or list of other
objects. For example, in Twitter users can add Tweets to a collection called a Moment. A
Moment is a kind of collection of Tweets.

An unfilled diamond notates an aggregation relationship.

An aggregation relationship, indicated by an unfilled diamond.

Component Relationship
A component relationship is a type of dependency relationship where one object is a
component of another. For Twitter, a Hashtag is an important component of a Tweet. The
concept of a Hashtag is entirely dependent upon the idea of a Tweet — if you remove the
concept of a Tweet from the system, the concept of Hashtag necessarily ceases to exist.

A component relationship is notated by a filled-in diamond.

A component relationship, indicated by a filled-in diamond.

Inheritance Relationship
Last but not least is the inheritance relationship. This is a parent-child relationship where the
children objects inherit all or some of the parent object’s characteristics.

Our example model for Twitter isn’t showing any inheritance relationships. However, if I
was building a full object model for Twitter, I might use inheritance to depict different types
of accounts, for example, a User Account and an Administrator Account. These objects,
which share a subset of characteristics, are best treated as children of an Account.

An inheritance relationship is shown using an unfilled arrow pointed at the parent object. The
parent object contains the shared characteristics; only the unique characteristics are shown for
the children.
An inheritance relationship, shown by an unfilled arrow.

Note, however, in this example Account isn’t an actual object in the system — it’s an
abstraction we used to create a parent. Here again, we can use traditional Class Diagram
notation to indicate the abstract object <<Account>>.

Though inheritance may seem a bit fussy to include in the model, it’s also one of the most
useful relationships to understand. When designing, you want to make sure parent functions
are presented consistently across all the children.

Indicating Objects with a Similar Purpose

Large models can become visually complex. To make them easier to read, it’s helpful to
color-code objects that share a similar purpose. For example, for Twitter I’ve used three
categories of objects:

 Core Experience (blue)

 Categorization & Discovery (green)
  Account Management (orange)

A More Real World Model

I’ve used Twitter to create an example model since it’s a relatively simple, well-known
system. For simple systems, the objects and their relationships might be self-evident.
However, that’s not usually the case with more complex systems, where the object model can
provide a concise representation of an otherwise incoherent underlying structure.

Below is a more real-world model for an enterprise system. This model is based on an actual
workflow management system, though some details have been changed for presentation here.
You can see the more extensive use of inheritance, component, and aggregation relationships
— and expanded use of the verbal descriptions to help “tell the structural story” of the
system.

Narrative Object Model for an enterprise workflow management system.

Mastering Object Modeling

Object modeling takes some practice: the best way to learn is by doing. If you are working on
a current project, go back and create an object model, even if you’re well along in the design
process. If you don’t have a current real-world project, it’s easy to model existing systems on
the web, as we did here for Twitter.

Tips for Creating a Model:

 Start with the easy stuff — for example, just identifying some objects.
  For larger systems, it may make sense to create two or more smaller models and then
bring them together.
 Build out the model over time, in a series of shorter work sessions.
 Do just enough to serve your purpose; avoid analysis paralysis.
 Two people may model the same system slightly differently, and that’s OK.

Using the Model

Of course, we aren’t creating models solely as an analytical exercise. We want to use the
model to improve design outcomes.

To begin, I want to emphasize that the Narrative Object Model provides a single, specific
view of a system — a structural view. It’s not designed to replace other artifacts such as
storyboards, journey maps, user stories, and use cases that represent the user experience from
a task perspective. The object model is always a compliment to other design artifacts.

Let’s look at how the object model fits into the design process. The model can be used to
identify:

 A system’s signature elements

 Objects that are similar either in purpose or function
 What might be functionally incomplete
 Controlled vocabulary terms

I also use the object model when doing screen-level design to make sure there is a clear
relationship between an object and all its associated actions.

Identifying the System’s Signature Elements

The rise of ready-made design systems such as Google Material Design has meant it’s easier
than ever for an organization to get started on their design system. The risk with using
publicly available components (or deriving directly from them) is that your application looks
and feels like all the other ones out there. One way to avoid this is by first developing
conventions for your core objects — those that are central to the experience — making the
design of those objects distinctive. These collectively become the system’s signature
elements, extended and built upon for the remaining design conventions. This approach has
been proposed both by Dan Mall in “Distinct Design Systems” and by Emmet Connolly in
“The Full Stack Design System.”

Identifying Objects Similar in Function or Purpose

Another way to view the model — and drive design conventions — is to identify those
objects with a similar function or purpose and design those objects as a unit. For example,
aggregate objects are often lists or collections that are inherently similar in function. By
designing conventions for these objects concurrently, you can avoid the case where you’ve
created a design based on one object but then discover it doesn’t appropriately extend to a
substantially similar object.
It’s also helpful to identify objects that have a similar purpose. In the previous section, we
used color-coding to group objects into categories.

In the Twitter model, there are three object categories:

 Core experience
 Categorization & Discovery
 Account Management

In the enterprise workflow system model, there are four categories:

 System Users
 Roles in a Transaction
 Components of a Transaction
 Work Management

Here again, it can make sense to design the objects within a category concurrently so that the
experience feels consistent.

It’s also useful to look at cases of inheritance (parent-child relationships). You want to make
sure parent functions are presented consistently across all the children.

Identifying What Might be Functionally Incomplete

When designing new functionality, the object model can provide a helpful cross-check that
all objects are functionally complete — and that actions, in particular, haven’t been
overlooked.

A starting point is looking for CRUD actions (create, read, update, and delete). For example,
Twitter famously doesn’t allow users to update a Tweet once it’s been posted. As I am
modeling Twitter and checking that objects are complete, I would notice this omission. In this
case, the lack of an update function is intentional, but it could also have been overlooked. In
my experience overlooked basic functions are not uncommon.

It can also be helpful to look at objects that serve a similar function and compare them. For
example, in Twitter, a Tweet and a Direct Message serve a similar function — to
communicate with others. You can favorite a Tweet, but you can’t favorite a Direct Message.
Should users be able to favorite a Direct Message as well?

Identifying Controlled Vocabulary Terms

A common problem with systems that have grown over time (or have functions built by
different teams) is inconsistent vocabulary. Sometimes inconsistencies are relatively minor
(Edit vs. Update) but they can also be foundational (Task vs. Assignment).

One reason to more completely fill out the actions and attributes for each object rectangle is
to do a thorough vocabulary cross-check. The model can ultimately serve as a source for a
controlled system vocabulary.
In addition to checking vocabulary across objects, it’s also handy to review terms within an
object. In Twitter, the word “Tweet” is used both as a noun and a verb. It’s evident that for
Twitter this makes sense, but it could be a legitimate question to raise.

Keeping a Clear Relationship Between an Object and Its

Associated Actions
During screen-level design work, the object model can serve as a reference to make sure there
is a clear association between an object and its associated actions. Though this may sound
like remedial advice, I’ve encountered many a system with illogically dispersed actions.
Typically, this happens over time where new functions are placed where there’s available
screen real estate rather than where they would more logically fit into the experience.

Wrapping Up
In this article, I’ve attempted to lay out the case for object modeling. I consider object
modeling a skill in my UX tool belt, along with conducting research, facilitating workshops,
journey mapping, persona development, and the like. These are all inputs which, depending
upon the needs of the project, contribute to successful design outcomes.
 UML Diagrams

Structure diagrams show the things in the modeled system. In a more technical term, they show
different objects in a system. Behavioral diagrams show what should happen in a system. They
describe how the objects interact with each other to create a functioning system.

Iterative Devlopment With RUP:

Rational Unified Process (RUP) is a software development process for object-oriented

models. It is also known as the Unified Process Model. It is created by Rational corporation
and is designed and documented using UML (Unified Modeling Language). This process is
included in IBM Rational Method Composer (RMC) product. IBM (International Business
Machine Corporation) allows us

to customize,

design, and

personalize the unified process.

RUP is proposed by Ivar Jacobson, Grady Bootch, and James Rambaugh.

Some characteristics of RUP include

-use-case driven,

- Iterative (repetition of the process), and

- Incremental (increase in value) by nature,

- delivered online using web technology,

-can be customized or tailored in modular and electronic form, etc.

-RUP reduces unexpected development costs and prevents wastage of resources.

Iterative Development wit RUP :

 1. Inception –
o Communication and planning are the main ones.
o Identifies the scope of the project using a use-case model allowing managers
to estimate costs and time required.
o Customers’ requirements are identified and then it becomes easy to make a
plan for the project.
o The project plan, Project goal, risks, use-case model, and Project description,
are made.
o The project is checked against the milestone criteria and if it couldn’t pass
these criteria then the project can be either canceled or redesigned.
2. Elaboration –
o Planning and modeling are the main ones.
o A detailed evaluation and development plan is carried out and diminishes the
risks.
o Revise or redefine the use-case model (approx. 80%), business case, and risks.
o Again, checked against milestone criteria and if it couldn’t pass these criteria
then again project can be canceled or redesigned.
o Executable architecture baseline.
3. Construction –
o The project is developed and completed.
o System or source code is created and then testing is done.
o Coding takes place.
4. Transition –
o The final project is released to the public.
o Transit the project from development into production.
o Update project documentation.
o Beta testing is conducted.
o Defects are removed from the project based on feedback from the public.
5. Production –
o The final phase of the model.
o The project is maintained and updated accordingly.

Advantages:

1. It provides good documentation, it completes the process in itself.

2. It provides risk-management support.
3. It reuses the components, and hence total time duration is less.
4. Good online support is available in the form of tutorials and training.

Disadvantages :

1. Team of expert professional is required, as the process is complex.

2. Complex and not properly organized process.
3. More dependency on risk management.
4. Hard to integrate again and again.
 CHAPTER 3

Requirements engineering is the process of identifying, eliciting, analyzing, specifying,

validating, and managing the needs and expectations of stakeholders for a software system. In
this article, we’ll learn about it’s process, advantages and disadvantages.

What is Requirements Engineering?

A systematic and strict approach to the definition, creation and verification of requirements
for a software system is known as requirements engineering. In order to guarantee the
effective creation of a software product, the requirements engineering process entails a
number of tasks that help in understanding, recording and managing the demands of
stakeholders.

The Requirements Engineering process is a critical step in the software development life
cycle as it helps to ensure that the software system being developed meets the needs and
expectations of stakeholders, and that it is developed on time, within budget, and to the
required quality.

Requirement Engineering is the process of defining, documenting and maintaining the

requirements. It is a process of gathering and defining service provided by the system. it is
the disciplined application of proven principle , methods ,tools and notations to describe a
proposed system’s intended behaviour and its associated constraints.

Steps in Requirements Engineering Process

The requirements engineering process is an iterative process that involves several steps,
including

1. Requirements Elicitation

It is related to the various ways used to gain knowledge about the project domain and
requirements. The various sources of domain knowledge include customers, business
manuals, the existing software of same type, standards and other stakeholders of the project.
The techniques used for requirements elicitation include interviews, brainstorming, task
analysis, Delphi technique, prototyping, etc. Some of these are discussed here. Elicitation
does not produce formal models of the requirements understood. Instead, it widens the
domain knowledge of the analyst and thus helps in providing input to the next stage.

Requirements elicitation is the process of gathering information about the needs and
expectations of stakeholders for a software system. This is the first step in the requirements
engineering process and it is critical to the success of the software development project. The
goal of this step is to understand the problem that the software system is intended to solve,
and the needs and expectations of the stakeholders who will use the system.
There are several techniques that can be used to elicit requirements, including:

 Interviews: These are one-on-one conversations with stakeholders to gather

information about their needs and expectations.

 Surveys: These are questionnaires that are distributed to stakeholders to gather

information about their needs and expectations.

 Focus Groups: These are small groups of stakeholders who are brought together to
discuss their needs and expectations for the software system.

 Observation: This technique involves observing the stakeholders in their work

environment to gather information about their needs and expectations.

 Prototyping: This technique involves creating a working model of the software

system, which can be used to gather feedback from stakeholders and to validate
requirements.

It’s important to document, organize and prioritize the requirements obtained from all these
techniques to ensure that they are complete, consistent and accurate.

2. Requirements Specification

This activity is used to produce formal software requirement models. All the requirements
including the functional as well as the non-functional requirements and the constraints are
specified by these models in totality. During specification, more knowledge about the
problem may be required which can again trigger the elicitation process. The models used at
this stage include ER diagrams, data flow diagrams(DFDs), function decomposition
diagrams(FDDs), data dictionaries, etc.

Requirements specification is the process of documenting the requirements identified in the

analysis step in a clear, consistent, and unambiguous manner. This step also involves
prioritizing and grouping the requirements into manageable chunks.

The goal of this step is to create a clear and comprehensive document that describes the
requirements for the software system. This document should be understandable by both the
development team and the stakeholders.

There are several types of requirements that are commonly specified in this step,
including

1. Functional Requirements: These describe what the software system should do. They
specify the functionality that the system must provide, such as input validation, data
storage, and user interface.

2. Non-Functional Requirements: These describe how well the software system should
do it. They specify the quality attributes of the system, such as performance,
reliability, usability, and security.
 3. Constraints: These describe any limitations or restrictions that must be considered
when developing the software system.

4. Acceptance Criteria: These describe the conditions that must be met for the software
system to be considered complete and ready for release.

In order to make the requirements specification clear, the requirements should be written in a
natural language and use simple terms, avoiding technical jargon, and using a consistent
format throughout the document. It is also important to use diagrams, models, and other
visual aids to help communicate the requirements effectively.

Once the requirements are specified, they must be reviewed and validated by the stakeholders
and development team to ensure that they are complete, consistent, and accurate.

3. Requirements Verification and Validation

Verification: It refers to the set of tasks that ensures that the software correctly implements a
specific function.

Validation: It refers to a different set of tasks that ensures that the software that has been
built is traceable to customer requirements. If requirements are not validated, errors in the
requirement definitions would propagate to the successive stages resulting in a lot of
modification and rework. The main steps for this process include:

1. The requirements should be consistent with all the other requirements i.e no two
requirements should conflict with each other.

2. The requirements should be complete in every sense.

3. The requirements should be practically achievable.

Reviews, buddy checks, making test cases, etc. are some of the methods used for this.

Requirements verification and validation (V&V) is the process of checking that the
requirements for a software system are complete, consistent, and accurate, and that they meet
the needs and expectations of the stakeholders. The goal of V&V is to ensure that the
software system being developed meets the requirements and that it is developed on time,
within budget, and to the required quality.

1. Verification is the process of checking that the requirements are complete, consistent,
and accurate. It involves reviewing the requirements to ensure that they are clear,
testable, and free of errors and inconsistencies. This can include reviewing the
requirements document, models, and diagrams, and holding meetings and
walkthroughs with stakeholders.

2. Validation is the process of checking that the requirements meet the needs and
expectations of the stakeholders. It involves testing the requirements to ensure that
they are valid and that the software system being developed will meet the needs of the
stakeholders. This can include testing the software system through simulation, testing
with prototypes, and testing with the final version of the software.
 3. V&V is an iterative process that occurs throughout the software development life
cycle. It is important to involve stakeholders and the development team in the V&V
process to ensure that the requirements are thoroughly reviewed and tested.

It’s important to note that V&V is not a one-time process, but it should be integrated and
continue throughout the software development process and even in the maintenance stage.

4. Requirements Management

Requirement management is the process of analyzing, documenting, tracking, prioritizing and

agreeing on the requirement and controlling the communication to relevant stakeholders. This
stage takes care of the changing nature of requirements. It should be ensured that the SRS is
as modifiable as possible so as to incorporate changes in requirements specified by the end
users at later stages too. Being able to modify the software as per requirements in a
systematic and controlled manner is an extremely important part of the requirements
engineering process.

Requirements management is the process of managing the requirements throughout the

software development life cycle, including tracking and controlling changes, and ensuring
that the requirements are still valid and relevant. The goal of requirements management is to
ensure that the software system being developed meets the needs and expectations of the
stakeholders and that it is developed on time, within budget, and to the required quality.

There are several key activities that are involved in requirements management, including:

1. Tracking and controlling changes: This involves monitoring and controlling

changes to the requirements throughout the development process, including
identifying the source of the change, assessing the impact of the change, and
approving or rejecting the change.

2. Version control: This involves keeping track of different versions of the

requirements document and other related artifacts.

3. Traceability: This involves linking the requirements to other elements of the

development process, such as design, testing, and validation.

4. Communication: This involves ensuring that the requirements are communicated

effectively to all stakeholders and that any changes or issues are addressed in a timely
manner.

5. Monitoring and reporting: This involves monitoring the progress of the

development process and reporting on the status of the requirements.

Requirements management is a critical step in the software development life cycle as it helps
to ensure that the software system being developed meets the needs and expectations of
stakeholders, and that it is developed on time, within budget, and to the required quality. It
also helps to prevent scope creep and to ensure that the requirements are aligned with the
project goals.
Advantages and Disadvantages
The advantages and disadvantages of the requirements engineering process in software
engineering include:

Advantages

 Helps ensure that the software being developed meets the needs and expectations of
the stakeholders

 Can help identify potential issues or problems early in the development process,
allowing for adjustments to be made before significant

 Helps ensure that the software is developed in a cost-effective and efficient manner

 Can improve communication and collaboration between the development team and
stakeholders

 Helps to ensure that the software system meets the needs of all stakeholders.

 Provides a clear and unambiguous description of the requirements, which helps to

reduce misunderstandings and errors.

 Helps to identify potential conflicts and contradictions in the requirements, which can
be resolved before the software development process begins.

 Helps to ensure that the software system is delivered on time, within budget, and to
the required quality standards.

 Provides a solid foundation for the development process, which helps to reduce the
risk of failure.

Disadvantages

 Can be time-consuming and costly, particularly if the requirements gathering process

is not well-managed

 Can be difficult to ensure that all stakeholders’ needs and expectations are taken into
account

 Can be challenging to ensure that the requirements are clear, consistent, and complete

 Changes in requirements can lead to delays and increased costs in the development
process.

 As a best practice, Requirements engineering should be flexible, adaptable, and

should be aligned with the overall project goals.

 It can be time-consuming and expensive, especially if the requirements are complex.

 It can be difficult to elicit requirements from stakeholders who have different needs
and priorities.

 Requirements may change over time, which can result in delays and additional costs.

 There may be conflicts between stakeholders, which can be difficult to resolve.

 It may be challenging to ensure that all stakeholders understand and agree on the
requirements.
Activity Diagram
Activity Diagrams are used to illustrate the flow of control in a system and refer to the steps
involved in the execution of a use case. We can depict both sequential processing and
concurrent processing of activities using an activity diagram ie an activity diagram focuses on
the condition of flow and the sequence in which it happens.

 We describe what causes a particular event using an activity diagram.

 An activity diagram portrays the control flow from a start point to a finish point
showing the various decision paths that exist while the activity is being executed.

 They are used in business and process modeling where their primary use is to depict
the dynamic aspects of a system.

Swimlanes

We use Swimlanes for grouping related activities in one column. Swimlanes group related
activities into one column or one row. Swimlanes can be vertical and horizontal. Swimlanes
are used to add modularity to the activity diagram. It is not mandatory to use swimlanes.
They usually give more clarity to the activity diagram. It’s similar to creating a function in a
program. It’s not mandatory to do so, but, it is a recommended practice.

How to Draw an Activity Diagram in UML?

Below are the steps of how to draw the Activity Diagram in UML:

Step 1. Identify the Initial State and Final States:

 This is like setting the starting point and ending point of a journey.

 Identify where your process begins (initial state) and where it concludes (final states).

 For example, if you are modelling a process for making a cup of tea, the initial state
could be “No tea prepared,” and the final state could be “Tea ready.”

Step 2. Identify the Intermediate Activities Needed:

 Think of the steps or actions required to go from the starting point to the ending point.

 These are the activities or tasks that need to be performed.

 Continuing with the tea-making , intermediate activities could include “Boil water,”
“Pour tea into a cup”.

Step 3. Identify the Conditions or Constraints:

  Consider the conditions or circumstances that might influence the flow of your
process.

 These are the factors that determine when you move from one activity to another.

 Using the tea-making scenario, a condition could be “Water is boiled,” which triggers
the transition to the next activity.

Step 4. Draw the Diagram with Appropriate Notations:

 Now, represent the identified states, activities, and conditions visually using the
appropriate symbols and notations in an activity diagram. This diagram serves as a
visual map of your process, showing the flow from one state to another.

Example of an Activity Diagram

An example of an activity diagram showing the business flow activity of order processing is
given below.
Chapter 4

Identifying Elements of Object Model

The elements of an object model—classes and objects, attributes, operations, and messages—were
each defined and discussed in the preceding section. But how do we go about identifying these
elements for an actual problem? The sections that follow present a series of informal guidelines that
will assist in the identification of the elements of the object model.

Identifying Classes and Objects

If you look around a room, there is a set of physical objects that can be easily identified, classified,
and defined (in terms of attributes and operations). But when you "look around" the problem space
of a software application, the objects may be more difficult to comprehend.

We can begin to identify objects by examining the problem statement or performing a "grammatical
parse" on the processing narrative for the system to be built. Objects are determined by underlining
each noun or noun clause and entering it in a simple table. Synonyms should be noted. If the object
is required to implement a solution, then it is part of the solution space; otherwise, if an object is
necessary only to describe a solution, it is part of the problem space. What should we look for once
al

of the nouns have been isolated? Objects manifest themselves in one of the ways represented
in figure. Objects can be

• External entities (e.g., other systems, devices, people) that produce or consume information
to be used by a computer-based system.
• Things (e.g, reports, displays, letters, signals) that are part of the information domain for the
problem.
• Occurrences or events (e.g., a property transfer or the completion of a series of robot
movements) that occur within the context of system operation.
• Roles (e.g., manager, engineer, salesperson) played by people who interact with the system.
• Organizational units (e.g., division, group, team) that are relevant to an application.
• Places (e.g., manufacturing floor or loading dock) that establish the context of the problem
and the overall function of the system.
• Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects
or in the extreme, related classes of objects.

This categorization is but one of many that have been proposed in the literature. For example,
Budd suggests a taxonomy of classes that includes producers (sources) and consumers
(sinks) of data, data managers, view or observer classes, and helper classes.
It is also important to note what objects are not. In general, an object should never have an
"imperative procedural name" . For example, if the developers of software for a medical imaging
system defined an object with the name image inversion, they would be making a subtle mistake.
The image obtained from the software could, of course, be an object (it is a thing that is part of the
information domain). Inversion of the image is an operation that is applied to the object. It is likely
that inversion would be defined as an operation for the object image, but it would not be defined as
a separate object to connote "image inversion." As Cashman states: "the intent of object-orientation
is to encapsulate, but still keep separate, data and operations on the data."

To illustrate how objects might be defined during the early stages of analysis, we return to the
SafeHome security system example. We already performed a "grammatical parse" on a
processing narrative for the SafeHome system . The processing narrative is reproduced:

SafeHome software enables the homeowner to configure the security system when it is
installed, monitors all sensors connected to the security system, and interacts with the
homeowner through a keypad and function keys contained in the SafeHome control panel
During installation, the SafeHome control panel is used to "program" and configure the
system. Each sensor is assigned a number and type, a master password is programmed for
arming and disarming the system, and telephone number(s) are input for dialing when a
sensor event occurs.

When a sensor event is sensed by the software, it rings an audible alarm attached to the
system. After a delay time that is specified by the homeowner during system configuration
activities, the software dials a telephone number of a monitoring service, provides
information about the location, reporting and the nature of the event that has been detected.

The number will be redialed every 20 seconds until telephone connection is obtained. All
interaction with SafeHome is managed by a user-interaction subsystem that reads input
provided through the keypad and function keys, displays prompting messages on the LCD
display, displays system status information on the LCD display. Keyboard interaction takes
the following form . . .

PotentialObject/Class General Classification

master password thing
telephone number thing
sensor event occurrence
audible alarm external entity
monitoring service organizational unit or external entity

Extracting the nouns, we can propose a number of potential objects:

The list would be continued until all nouns in the processing narrative have been considered.
Note that we call each entry in the list a potential object. We must consider each further
before a final decision is made. Coad and Yourdon suggest six selection characteristics that
should be used as an analyst considers each potential object for inclusion in the analysis
model:

1. Retained information. The potential object will be useful during analysis only if
information about it must be remembered so that the system can function.

2. Needed services. The potential object must have a set of identifiable operations that can
change the value of its attributes in some way.

3. Multiple attributes. During requirement analysis, the focus should be on "major"

information; an object with a single attribute may, in fact, be useful during design, but is
probably better represented as an attribute of another object during the analysis activity.

Specifying Attributes
Attributes describe an object that has been selected for inclusion in the analysis model. In
essence, it is the attributes that define the object—that clarify what is meant by the object in
the context of the problem space. For example, if we were to build a system that tracks
baseball statistics for professional baseball players, the attributes of the object player would
be quite different than the attributes of the same object when it is used in the context of the
professional baseball pension system. In the former, attributes such as name, position, batting
average, fielding percentage, years played, and games played might be relevant. For the
latter, some of these attributes would be meaningful, but others would be replaced (or
augmented) by attributes like average salary, credit toward full vesting, pension plan options
chosen, mailing address, and the like.

To develop a meaningful set of attributes for an object, the analyst can again study the
processing narrative (or statement of scope) for the problem and select those things that
reasonably "belong" to the object. In addition, the following question should be answered for
each object: "What data items (composite and/or elementary) fully define this object in the
context of the problem at hand?"
To illustrate, we consider the system object defined for SafeHome. Homeowner can
configure the security system to reflect sensor information, alarm response information,
activation/deactivation information, identification information, and so forth. Using the
content description notation defined for the data dictionary , we can represent these
composite data items in the following manner:

sensor information = sensor type + sensor number + alarm threshold

alarm response information = delay time + telephone number + alarm type
activation/deactivation information = master password + number of allowable tries +
temporary password
identification information = system ID + verification phone number + system status

Each of the data items to the right of the equal sign could be further defined to an elementary
level, but for our purposes, they constitute a reasonable list of attributes for the system
object .
Defining Operations
Operations define the behavior of an object and change the object’s attributes in some way.
More specifically, an operation changes one or more attribute values that are contained within
the object. Therefore, an operation must have "knowledge" of the nature of the object's
attributes and must be implemented in a manner that enables it to manipulate the data
structures that have been derived from the attributes.

Although many different types of operations exist, they can generally be divided into three
broad categories: (1) operations that manipulate data in some way (e.g., adding, deleting,
reformatting, selecting), (2) operations that perform a computation, and (3) operations that
monitor an object for the occurrence of a controlling event.

As a first iteration at deriving a set of operations for the objects of the analysis model, the
analyst can again study the processing narrative (or statement of scope) for the problem and
select those operations that reasonably belong to the object. To accomplish this, the
grammatical parse is again studied and verbs are isolated. Some of these verbs will be
legitimate operations and can be easily connected to a specific object. For example, from the
SafeHome processing narrative , we see that "sensor is assigned a number and type" or that "a
master password is programmed for arming and disarming the system." These two phrases
indicate a number of things:

That an assign operation is relevant for the sensor object.

• That a program operation will be applied to the system object.
• That arm and disarm are operations that apply to system (also that system status may ultimately
be defined (using data dictionary notation) as

Upon further investigation, it is likely that the operation program will be divided into a
number of more specific suboperations required to configure the system. For example,
program implies specifying phone numbers, configuring system characteristics (e.g., creating
the sensor table, entering alarm characteristics), and entering password(s). But for now, we
specify program as a single operation.

In addition to the grammatical parse, we can gain additional insight into other operations by
considering the communication that occurs between objects. Objects communicate by passing
messages to one another.
Finalizing the Object Definition
The definition of operations is the last step in completing the specification of an object.
Operations were culled from a grammatical parse of the processing narrative for the system.
Additional operations may be determined by considering the "life history" of an object and
the messages that are passed among objects defined for the system.

The generic life history of an object can be defined by recognizing that the object must be
created, modified, manipulated or read in other ways, and possibly deleted. For the system
object, this can be expanded to reflect known activities that occur during its life (in this case,
during the time that SafeHome is operational). Some of the operations can be ascertained
from likely communication between objects. For example, sensor event will send a message
to system to display the event location and number; control panel will send system a reset
message to update system status; the audible alarm will send a query message; the control
panel will send a modify message to change one or more attributes without reconfiguring the
entire system object; sensor event will also send a message to call the phone number(s)
contained in the object. Other messages can be considered and operations derived. The
resulting object definition is shown in figure.

A similar approach would be used for each of the objects defined for SafeHome. After attributes and
operations are defined for each of the objects identified to this point, the beginnings of an OOA
model would be created.

Statechart Diagram
Object Diagram:

Object diagrams are a visual representation in UML (Unified Modeling Language) that illustrates the
instances of classes and their relationships within a system at a specific point in time. They display
objects, their attributes, and the links between them, providing a snapshot of the system’s structure
during execution. Since object diagrams depict behavior when objects have been instantiated, we
can study the behavior of the system at a particular instant.

1. What are Object Diagrams?

An Object Diagram can be referred to as a screenshot of the instances in a system and the
relationship that exists between them.

 An object diagram in UML is useful because it provides a clear and visual

representation of specific instances of classes and their relationships at a particular
point in time, aiding in understanding and communicating the structure and
interactions within a system.

 In other words, “An object diagram in the Unified Modeling Language (UML), is a
diagram that shows a complete or partial view of the structure of a modeled system at
a specific time.

Object diagrams in UML are depicted using a simple and intuitive notations to show a
snapshot of a system at a specific point in time, displaying instances of classes and their
relationships.

What is an Object?

An object refers to a specific instance of a class within a system. A class is a blueprint or

template that defines the common attributes and behaviors shared by a group of objects. An
object, on the other hand, is a concrete and individual occurrence of that class, possessing
unique values for its attributes.

What is a Classifier?

In UML a classifier refers to a group of elements that have some common features like
methods, attributes and operations. A classifier can be thought of as an abstract metaclass
which draws a boundary for a group of instances having common static and dynamic
features.

For example:

we refer a class, an object, a component, or a deployment node as classifiers in UML since

they define a common set of properties. We are able to design object diagrams by
instantiating classifiers.
. Object Diagram Notations
The object diagram in UML uses specific notations to represent instances of classes and their
relationships at a particular moment in time.

1. Objects or Instance specifications

When we instantiate a classifier in a system, the object we create represents an entity which
exists in the system. We can represent the changes in object over time by creating multiple
instance specifications. We use a rectangle to represent an object in an object diagram.

2. Attributes and Values

Inside the object box, attributes of the object are listed along with their specific values.
3. Link

We use a link to represent a relationship between two objects. We represent the number of
participants on the link for each, at the end of the link. The term link is used to specify a
relationship between two instance specifications or objects. We use a solid line to represent a
link between two objects.

For Example – In the figure below, an object of class Student is linked to an object of class
College.

4. Dependency Relationships

We use a dependency relationship to show when one element depends on another element. A
dependency is used to depict the relationship between dependent and independent entities in
the system.
  Any change in the definition or structure of one element may cause changes to the
other.

 This is a unidirectional kind of relationship between two objects.

 Dependency relationships are of various types specified with keywords like

Abstraction, Binding, Realization, Substitution and Usage are the types of
dependency relationships used in UML.

For example – In the figure below, an object of Player class is dependent (or uses) an object
of Bat class.

5. Association

Association is a reference relationship between two objects (or classes). An association line
connects two object boxes, representing a relationship between instances of two classes. We
use association when one object references members of the other object. Association can be
uni-directional or bi-directional. We use an arrow to represent association.

For example – The object of Order class is associated with an object of Customer class.
6. Aggregation

Aggregation represents a “has a” relationship. We use a hollow diamond on the containing

object with a line which joins it to the contained object.

 Aggregation is a specific form of association.

 It is a kind of parent-child relationship however it isn’t inheritance.

 Aggregation occurs when the lifecycle of the contained objects does not strongly
depend on the lifecycle of container objects.

For example – A library has an aggregation relationship with books. Library has books or
books are a part of library. The existence of books is independent of the existence of the
library.

7. Composition

Composition is a type of association where the child cannot exist independent of the other.
We use a filled diamond on the containing object with a line which joins it to the contained
object. Composition is also a special type of association. It is also a kind of parent child
relationship but it is not inheritance. So whenever independent existence of the child is not
possible we use a composition relationship.

Consider the example of a boy Gurkaran: Gurkaran is composed of legs and arms. Here
Gurkaran has a composition relationship with his legs and arms. Here legs and arms can’t
exist without the existence of their parent object.
5. Purpose of Object Diagrams
The main purpose of using object diagrams is:

 They offer a detailed view of how objects interact with each other in specific
scenarios.

 Proper design and analysis of applications can be faster and efficient.

 Object diagrams are beneficial during the implementation phase of software

development.

 Promoting a shared understanding of specific instances and their relationships,

facilitating collaboration among team members.

6. Benefits of Object Diagrams

 Detailed Insight into Relationships:

o They offer a detailed view of relationships and collaborations between

instances of classes. This helps in understanding the specific interactions and
dependencies among objects.

 Implementation Guidance:

o During the system implementation phase, object diagrams assist developers in

building and testing the actual instances of classes. They provide guidance on
how to represent objects in code.

 Integration Testing Assistance:

o They are valuable for integration testing, allowing testers to evaluate how
different objects collaborate and exchange information. This ensures that
integrated components of the system work seamlessly.

 Validation of Code Implementation:

o Developers can use object diagrams to validate that the actual code aligns with
the intended relationships and interactions specified in the design. This helps
maintain consistency between the design and the implementation.

 Scenario Illustration:

o Object diagrams are useful for illustrating and documenting specific scenarios
or use cases, providing a clear visual representation of how objects behave in
different situations.

7. How to draw an Object Diagram?

 1. Identify Classes: Determine the classes relevant to the scenario you want to depict.
Classes are the blueprints that define the attributes and behaviors shared by their
instances.

2. Identify Objects: Identify specific instances or objects of each class that you want to
include in the diagram. These represent the actual things in your system.

3. Create Object Boxes: Draw rectangles to represent the specific instances or objects
of each class. Write the name of each object inside the box.

4. Add Attributes and Values: Inside each object box, list the attributes of that object
along with their specific values.

5. Draw Relationships: Connect the object boxes with lines to represent relationships
or associations between instances. Use arrows to indicate the direction of the
association if necessary.

6. Label Relationships: Label the relationships with multiplicity and role names if
needed. Label the association lines with a verb or phrase to describe the nature of the
relationship.

7. Review and Refine: Review your Object diagram to ensure it accurately represents
the system’s structure and relationships. Refine the diagram as needed based on
feedback and requirements.

8. Use Tools for Digital Drawing: While you can draw class diagrams on paper, using
digital tools can provide more flexibility and ease of modification. UML modeling
tools, drawing software, or even specialized diagramming tools can be helpful.

8. Use Cases of Object Diagrams

Object diagrams in UML also play a crucial role in various phases of software development.
Here are some use cases for object diagrams:

 System Implementation:

o Object diagrams provide a practical representation of specific instances of

classes, aiding in the implementation phase. Object diagrams help developers
when they are building the actual software. These diagrams show real
examples of things (objects) in the system and how they work together.

 Communication and Collaboration:

o Similar to class diagrams, object diagrams serve as a communication tool

among stakeholders. They facilitate discussions about the relationships and
interactions between specific objects at a particular moment, promoting a
shared understanding among team members.

 Test Case Design:

 o Testers use object diagrams to design test cases based on the relationships and
behaviors of specific instances. This helps ensure thorough testing of object
interactions in the system.

 Debugging and Troubleshooting:

o During the debugging process, object diagrams can be valuable for

understanding the state of specific objects at a particular point in time. This
aids developers in identifying and resolving issues related to object
interactions.

 Training and Documentation:

o Object diagrams can be used for training purposes, helping new team members
understand the structure and behavior of specific instances in the system. They
also contribute to documentation by providing visual representations of object
relationships.
 Chapter 5

Interaction Modeling

From the term Interaction, it is clear that the diagram is used to describe some type of
interactions among the different elements in the model. This interaction is a part of dynamic
behavior of the system.

This interactive behavior is represented in UML by two diagrams known as Sequence

diagram and Collaboration diagram. The basic purpose of both the diagrams are similar.

Sequence diagram emphasizes on time sequence of messages and collaboration diagram

emphasizes on the structural organization of the objects that send and receive messages.

Purpose of Interaction Diagrams

The purpose of interaction diagrams is to visualize the interactive behavior of the system.
Visualizing the interaction is a difficult task. Hence, the solution is to use different types of
models to capture the different aspects of the interaction.

Sequence and collaboration diagrams are used to capture the dynamic nature but from a
different angle.

The purpose of interaction diagram is −

 To capture the dynamic behaviour of a system.

 To describe the message flow in the system.
 To describe the structural organization of the objects.

How to Draw an Interaction Diagram?

As we have already discussed, the purpose of interaction diagrams is to capture the dynamic
aspect of a system. So to capture the dynamic aspect, we need to understand what a dynamic
aspect is and how it is visualized. Dynamic aspect can be defined as the snapshot of the
running system at a particular moment

We have two types of interaction diagrams in UML. One is the sequence diagram and the
other is the collaboration diagram. The sequence diagram captures the time sequence of the
message flow from one object to another and the collaboration diagram describes the
organization of objects in a system taking part in the message flow.

Following things are to be identified clearly before drawing the interaction diagram

 Objects taking part in the interaction.

 Message flows among the objects.
 The sequence in which the messages are flowing.
 Object organization.
Following are two interaction diagrams modeling the order management system. The first
diagram is a sequence diagram and the second is a collaboration diagram

The Sequence Diagram

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

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

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

The Collaboration Diagram

The second interaction diagram is the collaboration diagram. It shows the object organization
as seen in the following diagram. In the collaboration diagram, the method call sequence is
indicated by some numbering technique. The number indicates how the methods are called
one after another. We have taken the same order management system to describe the
collaboration diagram.

Method calls are similar to that of a sequence diagram. However, difference being the
sequence diagram does not describe the object organization, whereas the collaboration
diagram shows the object organization.
To choose between these two diagrams, emphasis is placed on the type of requirement. If the
time sequence is important, then the sequence diagram is used. If organization is required,
then collaboration diagram is used.

Where to Use Interaction Diagrams?

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

The main purpose of both the diagrams are similar as they are used to capture the dynamic
behavior of a system. However, the specific purpose is more important to clarify and
understand.

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

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

Interaction diagrams can be used −

 To model the flow of control by time sequence.

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

 To describe the interaction among objects.

Unified Modelling Language (UML) is a modeling language in the field of software
engineering that aims to set standard ways to visualize the design of a system. UML guides
the creation of multiple types of diagrams such as interaction, structure, and behavior
diagrams. A sequence diagram is the most commonly used interaction diagram.

Interaction diagram

An interaction diagram is used to show the interactive behavior of a system. Since

visualizing the interactions in a system can be difficult, we use different types of interaction
diagrams to capture various features and aspects of interaction in a system.

 A sequence diagram simply depicts the interaction between the objects in a sequential
order i.e. the order in which these interactions occur.

 We can also use the terms event diagrams or event scenarios to refer to a sequence
diagram.

 Sequence diagrams describe how and in what order the objects in a system function.

 These diagrams are widely used by businessmen and software developers to

document and understand requirements for new and existing systems.

1. Sequence Diagram Notation

1.1. Actors
An actor in a UML diagram represents a type of role where it interacts with the system and its
objects. It is important to note here that an actor is always outside the scope of the system we
aim to model using the UML diagram.
We use actors to depict various roles including human users and other external subjects. We
represent an actor in a UML diagram using a stick person notation. We can have multiple
actors in a sequence diagram.

For example:

Here the user in seat reservation system is shown as an actor where it exists outside the
system and is not a part of the system.

1.2. Lifelines
A lifeline is a named element which depicts an individual participant in a sequence diagram.
So basically each instance in a sequence diagram is represented by a lifeline. Lifeline
elements are located at the top in a sequence diagram. The standard in UML for naming a
lifeline follows the following format:

Instance Name : Class Name

We display a lifeline in a rectangle called head with its name and type. The head is located
on top of a vertical dashed line (referred to as the stem) as shown above.

 If we want to model an unnamed instance, we follow the same pattern except now the
portion of lifeline’s name is left blank.

 Difference between a lifeline and an actor

o A lifeline always portrays an object internal to the system whereas actors are
used to depict objects external to the system.

The following is an example of a sequence diagram:

1.3. Messages
Communication between objects is depicted using messages. The messages appear in a
sequential order on the lifeline.

 We represent messages using arrows.

 Lifelines and messages form the core of a sequence diagram.

Messages can be broadly classified into the following categories:

Synchronous messages

A synchronous message waits for a reply before the interaction can move forward. The
sender waits until the receiver has completed the processing of the message. The caller
continues only when it knows that the receiver has processed the previous message i.e. it
receives a reply message.

 A large number of calls in object oriented programming are synchronous.

 We use a solid arrow head to represent a synchronous message.

Asynchronous Messages

An asynchronous message does not wait for a reply from the receiver. The interaction moves
forward irrespective of the receiver processing the previous message or not. We use a lined
arrow head to represent an asynchronous message.

1.4. Create message

We use a Create message to instantiate a new object in the sequence diagram. There are
situations when a particular message call requires the creation of an object. It is represented
with a dotted arrow and create word labelled on it to specify that it is the create Message
symbol.

For example:

The creation of a new order on a e-commerce website would require a new object of Order
class to be created.

1.5. Delete Message

We use a Delete Message to delete an object. When an object is deallocated memory or is
destroyed within the system we use the Delete Message symbol. It destroys the occurrence of
the object in the system.It is represented by an arrow terminating with a x.

For example:
In the scenario below when the order is received by the user, the object of order class can be
destroyed.

1.6. Self Message

Certain scenarios might arise where the object needs to send a message to itself. Such
messages are called Self Messages and are represented with a U shaped arrow.

Another example:

Consider a scenario where the device wants to access its webcam. Such a scenario is
represented using a self message.
1.7. Reply Message
Reply messages are used to show the message being sent from the receiver to the sender. We
represent a return/reply message using an open arrow head with a dotted line. The
interaction moves forward only when a reply message is sent by the receiver.

For example:

Consider the scenario where the device requests a photo from the user. Here the message
which shows the photo being sent is a reply message.
1.8. Found Message
A Found message is used to represent a scenario where an unknown source sends the
message. It is represented using an arrow directed towards a lifeline from an end point.

For example:

Consider the scenario of a hardware failure.

It can be due to multiple reasons and we are not certain as to what caused the hardware
failure.

1.9. Lost Message

A Lost message is used to represent a scenario where the recipient is not known to the
system. It is represented using an arrow directed towards an end point from a lifeline.

For example:

Consider a scenario where a warning is generated.

The warning might be generated for the user or other software/object that the lifeline is
interacting with. Since the destination is not known before hand, we use the Lost Message
symbol.

1.10. Guards
To model conditions we use guards in UML. They are used when we need to restrict the flow
of messages on the pretext of a condition being met. Guards play an important role in letting
software developers know the constraints attached to a system or a particular process.

For example:

In order to be able to withdraw cash, having a balance greater than zero is a condition that
must be met as shown below.
The above sequence diagram depicts the sequence diagram for an emotion based music
player:

1. Firstly the application is opened by the user.

2. The device then gets access to the web cam.

3. The webcam captures the image of the user.

4. The device uses algorithms to detect the face and predict the mood.

5. It then requests database for dictionary of possible moods.

6. The mood is retrieved from the database.

7. The mood is displayed to the user.

8. The music is requested from the database.

9. The playlist is generated and finally shown to the user.

2. How to create Sequence Diagrams?
Creating a sequence diagram involves several steps, and it’s typically done during the design
phase of software development to illustrate how different components or objects interact over
time. Here’s a step-by-step guide on how to create sequence diagrams:

1. Identify the Scenario:

o Understand the specific scenario or use case that you want to represent in the
sequence diagram. This could be a specific interaction between objects or the
flow of messages in a particular process.

2. List the Participants:

o Identify the participants (objects or actors) involved in the scenario.

Participants can be users, systems, or external entities.

3. Define Lifelines:

o Draw a vertical dashed line for each participant, representing the lifeline of
each object over time. The lifeline represents the existence of an object during
the interaction.

4. Arrange Lifelines:

o Position the lifelines horizontally in the order of their involvement in the

interaction. This helps in visualizing the flow of messages between
participants.

5. Add Activation Bars:

o For each message, draw an activation bar on the lifeline of the sending
participant. The activation bar represents the duration of time during which the
participant is actively processing the message.

6. Draw Messages:

o Use arrows to represent messages between participants. Messages flow

horizontally between lifelines, indicating the communication between objects.
Different types of messages include synchronous (solid arrow), asynchronous
(dashed arrow), and self-messages.

7. Include Return Messages:

o If a participant sends a response message, draw a dashed arrow returning to

the original sender to represent the return message.

8. Indicate Timing and Order:

 o Use numbers to indicate the order of messages in the sequence. You can also
use vertical dashed lines to represent occurrences of events or the passage of
time.

9. Include Conditions and Loops:

o Use combined fragments to represent conditions (like if statements) and loops

in the interaction. This adds complexity to the sequence diagram and helps in
detailing the control flow.

10. Consider Parallel Execution:

o If there are parallel activities happening, represent them by drawing parallel

vertical dashed lines and placing the messages accordingly.

11. Review and Refine:

o Review the sequence diagram for clarity and correctness. Ensure that it
accurately represents the intended interaction. Refine as needed.

12. Add Annotations and Comments:

o Include any additional information, annotations, or comments that provide

context or clarification for elements in the diagram.

13. Document Assumptions and Constraints:

o If there are any assumptions or constraints related to the interaction, document

them alongside the diagram.

14. Tools:

o Use a UML modeling tool or diagramming software to create a neat and

professional-looking sequence diagram. These tools often provide features for
easy editing, collaboration, and documentation.

3. Use cases of Sequence Diagrams

 System Behavior Visualization:

o Sequence diagrams are used to illustrate the dynamic behavior of a system by

showing the interactions among various components, objects, or actors over
time.

o They provide a clear and visual representation of the flow of messages and
events in a specific scenario.

 Software Design and Architecture:

 o During the design phase of software development, sequence diagrams help
developers and architects plan and understand how different components and
objects will interact to accomplish specific functionalities.

o They provide a blueprint for the system’s behavior.

 Communication and Collaboration:

o Sequence diagrams serve as a communication tool among stakeholders,

including developers, designers, project managers, and clients.

o They help in conveying complex interactions in an easy-to-understand visual

format, fostering collaboration and shared understanding.

 Requirements Clarification:

o When refining system requirements, sequence diagrams can be used to clarify

and specify the expected interactions between system components or between
the system and external entities.

o They help ensure a common understanding of system behavior among all

stakeholders.

 Debugging and Troubleshooting:

o Developers use sequence diagrams as a debugging tool to identify and analyze

issues related to the order and timing of messages during system interactions.

o It provides a visual representation of the flow of control and helps in locating

and resolving problems.

4. Challenges of using Sequence Diagrams

 Complexity and Size:

o As systems grow in complexity, sequence diagrams can become large and

intricate. Managing the size of the diagram while still accurately representing
the interactions can be challenging, and overly complex diagrams may become
difficult to understand.

 Abstraction Level:

o Striking the right balance in terms of abstraction can be challenging. Sequence

diagrams need to be detailed enough to convey the necessary information, but
too much detail can overwhelm readers. It’s important to focus on the most
critical interactions without getting bogged down in minutiae.

 Dynamic Nature:
 o Sequence diagrams represent dynamic aspects of a system, and as a result,
they may change frequently during the development process. Keeping
sequence diagrams up-to-date with the evolving system can be a challenge,
especially in rapidly changing or agile development environments.

 Ambiguity in Messages:

o Sometimes, it can be challenging to define the exact nature of messages

between objects. Ambiguity in message content or meaning may lead to
misunderstandings among stakeholders and impact the accuracy of the
sequence diagram.

 Concurrency and Parallelism:

o Representing concurrent and parallel processes can be complex. While

sequence diagrams have mechanisms to indicate parallel execution,
visualizing multiple interactions happening simultaneously can be challenging
and may require additional diagrammatic elements.

 Real-Time Constraints:

o Representing real-time constraints and precise timing requirements can be

challenging. While sequence diagrams provide a sequential representation,
accurately capturing and communicating real-time aspects might require
additional documentation or complementary diagrams.

Feeling lost in the vast world of System Design? It's time for a transformation! Enroll in our
Mastering System Design From Low-Level to High-Level Solutions - Live Course and
embark on an exhilarating journey to efficiently master system design concepts and
techniques.
UML Collaboration Diagram
The collaboration diagram is used to show the relationship between the objects in a system.
Both the sequence and the collaboration diagrams represent the same information but
differently. Instead of showing the flow of messages, it depicts the architecture of the object
residing in the system as it is based on object-oriented programming. An object consists of
several features. Multiple objects present in the system are connected to each other. The
collaboration diagram, which is also known as a communication diagram, is used to portray
the object's architecture in the system.

Notations of a Collaboration Diagram

Following are the components of a component diagram that are enlisted below:

1. Objects: The representation of an object is done by an object symbol with its name
and class underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
o The object is represented by specifying their name and class.
o It is not mandatory for every class to appear.
o A class may constitute more than one object.
o In the collaboration diagram, firstly, the object is created, and then its class is
specified.
o To differentiate one object from another object, it is necessary to name them.
2. Actors: In the collaboration diagram, the actor plays the main role as it invokes the
interaction. Each actor has its respective role and name. In this, one actor initiates the
use case.
3. Links: The link is an instance of association, which associates the objects and actors.
It portrays a relationship between the objects through which the messages are sent. It
is represented by a solid line. The link helps an object to connect with or navigate to
another object, such that the message flows are attached to links.
4. Messages: It is a communication between objects which carries information and
includes a sequence number, so that the activity may take place. It is represented by a
labeled arrow, which is placed near a link. The messages are sent from the sender to
the receiver, and the direction must be navigable in that particular direction. The
receiver must understand the message.
When to use a Collaboration Diagram?
The collaborations are used when it is essential to depict the relationship between the object.
Both the sequence and collaboration diagrams represent the same information, but the way of
portraying it quite different. The collaboration diagrams are best suited for analyzing use
cases.

Following are some of the use cases enlisted below for which the collaboration diagram is
implemented:

1. o model collaboration among the objects or roles that carry the functionalities of use
cases and operations.
2. To model the mechanism inside the architectural design of the system.
3. To capture the interactions that represent the flow of messages between the objects
and the roles inside the collaboration.
4. To model different scenarios within the use case or operation, involving a
collaboration of several objects and interactions.
5. To support the identification of objects participating in the use case.
6. In the collaboration diagram, each message constitutes a sequence number, such that
the top-level message is marked as one and so on. The messages sent during the same
call are denoted with the same decimal prefix, but with different suffixes of 1, 2, etc.
as per their occurrence.

Steps for creating a Collaboration Diagram

 1. Determine the behavior for which the realization and implementation are specified.
2. Discover the structural elements that are class roles, objects, and subsystems for
performing the functionality of collaboration.
o Choose the context of an interaction: system, subsystem, use case, and
operation.
3. Think through alternative situations that may be involved.
o Implementation of a collaboration diagram at an instance level, if needed.
o A specification level diagram may be made in the instance level sequence
diagram for summarizing alternative situations.

Example of a Collaboration Diagram

Benefits of a Collaboration Diagram

1. The collaboration diagram is also known as Communication Diagram.
2. It mainly puts emphasis on the structural aspect of an interaction diagram, i.e., how
lifelines are connected.
3. The syntax of a collaboration diagram is similar to the sequence diagram; just the
difference is that the lifeline does not consist of tails.
4. The messages transmitted over sequencing is represented by numbering each
individual message.
5. The collaboration diagram is semantically weak in comparison to the sequence
diagram.
6. The special case of a collaboration diagram is the object diagram.
7. It focuses on the elements and not the message flow, like sequence diagrams.
8. Since the collaboration diagrams are not that expensive, the sequence diagram can be
directly converted to the collaboration diagram.
 9. There may be a chance of losing some amount of information while implementing a
collaboration diagram with respect to the sequence diagram.

The drawback of a Collaboration Diagram

1. Multiple objects residing in the system can make a complex collaboration diagram, as
it becomes quite hard to explore the objects.
2. It is a time-consuming diagram.
3. After the program terminates, the object is destroyed.
4. As the object state changes momentarily, it becomes difficult to keep an eye on every
single that has occurred inside the object of a system.