Using a Single Business Pattern with the RUP -part2

The architecture of the RUP

Figure 2 shows the overall architecture of the Rational Unified Process. The
process has two dimensions:
-The horizontal dimension represents time and shows the phase and iteration
milestones that occur over the life of the project.

-The vertical dimension represents content, in logical groupings called
disciplines.

Figure 2 Architecture of RUP

The “humps” in the chart show the relative emphasis of the disciplines over time.
Iterative development is shown; we see all disciplines represented in every
iteration. What changes is the emphasis, for example, more requirements in the
early stages of the project and more testing in the later stages.
RUP follows a standard meta-model1 for describing software processes, that
includes the following concepts:
- Artifacts: What is produced
- Activities: How to perform the work
- Roles: Who performs the work

Artifacts
Artifacts can take various shapes or forms, such as:
- A model, such as the use-case model or the design model. These contain
model elements (sub-artifacts) such as design classes, use cases, and
design subsystems.
-Databases or other types of tabular information repositories such as
spreadsheets.
- Source code and executables.
- Various types of documents, for example, a specification document, such as
the requirements specification, or a plan document, such as the software
development plan.
Roles
A role defines the behavior and responsibilities of an individual, or a set of
individuals working together as a team, within the context of a software
engineering organization.
Note that roles are not individuals; instead, roles describe responsibilities. An
individual will typically take on several roles at one time and frequently will
change roles over the duration of the project.
Activities
An activity is work performed by a role. It is usually defined as a series of steps
that involve creating or updating one or more artifacts.
Some examples of activities are:
-Find actors and use cases: An activity performed by the system analyst role
to identify high-level functional requirements in terms of actors and use
cases.
- Describe distribution: An activity performed by the software architect role to
describe software distribution across multiple processors.
Workflow and workflow details
A process should describe which activities are performed together and the order
in which activities are performed. A workflow is a sequence that shows how work
is ordered.
RUP describes a workflow for each discipline. The elements in the workflow are
groupings of activities referred to as workflow details. The groupings are
activities that are performed together to achieve a specific result. Figure 3 shows
the workflow for the analysis and design discipline.

Figure 3 Analysis and design discipline workflow

The diagram shown in Figure 4 describes the workflow detail “define a candidate
architecture.”

Figure 4 Define a candidate architecture workflow

Phases
Another key concept in RUP is phases. Phases provide project milestones that
ensure that iterations make progress and converge on a solution, rather than
iterate indefinitely.
The phases of RUP are:
- Elaboration: The software architecture is established and validated with an
executing architectural version of the system.
- Construction: The focus is on completing the development of the system.
- Transition: The software is deployed and made acceptable to its end users.

The objectives of each phase are achieved by executing one or more iterations
within the phase. Each phase concludes with a milestone at which the phases
are assessed to determine if the project has achieved the specified objectives of
the phase. The project cannot move to the next phase until these objectives are
achieved. See Figure 5.
The objectives of each phase are described in more detail in the next section.

Figure 5 The phases and milestones of a project