CS2 Software Engineering note 4 CS2Ah 01.11.

05

CS2 Software Engineering note 4

Analysis and Design in the Rational Unified

Process

In the last lecture we considered the Project Management Workflow of the

RUP. In this note we consider the Analysis and Design Workflow. This stage cov-
ers aspects of the architectural design in the early iterations and fairly detailed
design just prior to the implementation of the system in the later iterations.

The Analysis and Design Workflow

The overall purpose of the Analysis and design workflow is to translate the
requirements into a specification of how to implement the system. The activity
spans a range of abstraction, looking at fairly abstract architectural issues in
the early iterations but becoming increasingly detailed with later iterations. The
activities undertaken in this workflow cover:

• Selection of a robust architecture that supports the likely evolution of the

system. This should be easy to understand and implement.

• Refine the implementation environment.

• Undertake detailed design of (particularly non-functional) requirements like

performance, scalability, testability, availability, maintainability taking the
implementation environment into account.

Analysis is mainly involved with transforming the requirements into and archi-
tecture and collection of components that could credibly support an implemen-
tation of the proposed system. The focus is mainly on functional requirements
and the creation of a number of design components that create a suitable layer
of abstraction from the implementation. Analysis creates an idealised view of the
design of the system that will inevitably be modified during detailed design.

Design begins where analysis leaves off. Taking the idealised design as the
starting point the design process attempts to create the framework for an im-
plementation that is able to meet all the non-functional requirements that are
largely ignored in the analysis phase.

1
CS2 Software Engineering note 4 CS2Ah 01.11.05

Where does design stop? Design should be detailed enough that it determines
the structure of the implementation sufficiently that we can be sure any imple-
mentation meeting the design will satisfy the requirements. A consequence of
this is that the level at which design stops will vary depending on the experience
of the implementation team, the nature of the development environment, and
the precision to which the requirements are specified.

Workers and Artifacts

Here we will ignore any real-time aspects of systems. In the case of real-time
aspects we require to treat these specially. We do not consider real-time compo-
nents here. The main workers are:

Architect: who leads an coordinates technical activities and artifacts in the

project. Translates from requirements to architecture and is responsible
for decomposing the ask and distributing sub-tasks to designers. The ar-
chitect is responsible for the following artifacts:

• The analysis model – this is usually an abstraction of the design model.

It omits much of the detail of the design model. This kind of model is
particularly useful for long-lived products that need high-level coordi-
nation involving non-technical parts of the organisation (e.g. market-
ing).
• The design model is the primary artifact of the analysis and design
workflow. It comprises class definitions and how they collaborate to
provide requirements specified by use cases. These may be further
aggregated into packages and subsystems that group related classes to
allow us to hide unnecessary detail where necessary.
• Interfaces – specify the services offered by components (e.g. a class).
The main interfaces are the principal method to control the structure of
the system by hiding detail behind service specifications. The Architect
is responsible for maintaining these interfaces.
• The Architecture Document, that describes the software architecture of
the system. It includes all the architectural views of the system: the
logical view which presents the functionality of the system; the process
view that records how implementation elements will interact to realise
a service; the deployment view that says what will go where in the final
implementation.

Designer: Is responsible for seeing that individual classes, packages and sub-
systems meet the requirements, in particular the non-functional require-
ments that depend strongly on the underlying implementation technology.
The designer is responsible for:

• Detailed design of the design classes, packages and subsystems that

the designer is designing.

2
CS2 Software Engineering note 4 CS2Ah 01.11.05

• Evidence that the design elements play their appropriate part in realiz-
ing the use cases that involve them.

In addition it is possible to include some additional workers in some projects:

Database designer: who is responsible for the data model.

Architecture and Design reviewers: who review the analysis and design where
high levels of scrutiny are necessary.

The Workflow

In the early iterations we are primarily concerned with the architecture and there
are two main activities.

Define a candidate architecture. This combines work of the architect and the
designer. The architect proposes some candidate architectures and this is tested
against the relevant use case by the designer. The purpose of this activity is to:

Define the candidate architecture by defining:

• Identifying architectural elements that need analysis
• Identifying the initial layering and organisation of the system
• Identify those use case of architectural significance.
Identify key classes in the analysis these arise form the architecturally signif-
icant use cases.
Update use case realizations to take account of the refined class structure aris-
ing from the architecture definition.

Refining the Architecture follows on from selecting a candidate architecture.

It involves: identifying design mechanisms, identifying design elements, incorpo-
rate existing design elements, and describe run-time architecture and distribu-
tion. The main purpose of this workflow item is to:

• Effect the transition from architecting to design by identifying those design

elements that need design work.
• Maintain the consistency of the architecture with existing components.
• describe how the system will be organised at runtime and how it will be
deployed.

In later iterations the main activities involve design rather than analysis. At
this stage there are two interacting workflow items.

3
CS2 Software Engineering note 4 CS2Ah 01.11.05

Analyse Behaviour This workflow item involves analysing the use cases to
see how the activity described there maps onto demands on the behaviour and
non-functional characteristics of the design components (classes, packages, sub-
structures). This involves working with the use cases to identify how the compo-
nents will collaborate to meet the demands of a particular use case.

Design Components Having discovered the behaviour that should be displayed

by some design component this workflow item sets about seeing the behaviour
is realised in the appropriate component. This involves designing in the new
behaviours into the appropriate components, keeping track of how much of the
use cases have been designed into the system and reviewing the evolving design.
These two processes are repeated until all the behaviour in the use cases is
designed into the components and all the non-functional requirements are met
inside the chosen implementation environment.

Summary

This note provides a brief overview of the analysis and design workflow. In par-
ticular, we have:

• Seen how analysis devises the architecture and design components in re-
sponse to the use cases.

• How the designer deals with detailed (often non-functional) requirements

while the analyst mostly considers the overall structure of the system.

• The main outcome of the process is the design model and associated docu-
ment.