A UML Model of the Unified Process

The Unified Process is a confusing concept—and sometimes doesn't feel very unified at all—because there are
actually multiple Unified Processes:
 The Unified Process is a proposal from Jacobson, Booch, Rumbaugh, and others at Rational Software
for a standard software development process. It bears some superficial resemblance to the Waterfall
Model; but as a more modern approach, it's more component and object oriented, and it's more iterative
and incremental. It's also extremely customizable: it explicitly acknowledges that different projects
require different degrees of process. [2]
 The Rational Unified Process is an integrated suite of tools from Rational for implementing,
supporting, and customizing the Unified Process. While I think these are excellent tools, I find it
unfortunate that many people confuse the tools with the process. Then, if they choose not to purchase
the tools, they believe that the Unified Process offers no benefit to them. In this, they're quite wrong: the
process is a useful approach no matter what tools you use.
 And then there's any given customization of the Unified Process. A team working on a very large
project and a team working on a very small project may seem to be following entirely different
processes, and yet both may claim to be following the Unified Process.

In this model, I'll describe just the basic outline of the Unified Process. For more details, I recommend The
Unified Software Development Process from the Three Amigos.

The Four Key Characteristics

As described in The Unified Software Development Process, [3] the Unified Process has four key characteristics
that drive its structure and how you apply the process:

1. Use-Case Driven. The Unified Process is driven by (and usually starts with) identifying, elaborating,
categorizing, and modeling use cases. Thus, user needs are integrated into and reflected within all
steps of the process.

2. Architecture-Centric. The Unified Process has a very broad definition of architecture, encompassing
not just key elements of the system's structure, but also key use cases, key classes, key interfaces, and
key methods. In the UP view, the architecture encompasses all "essential" views of the system
structure, at different levels of abstraction.

3. Iterative. The system is analyzed, architected, designed, and implemented in cycles or iterations, mini-
projects defined by identifying a set of use cases and use case scenarios that comprise a useful
extension to existing knowledge and work; analyzing and identifying and managing risks within those
use cases; and then architecting, designing, implementing, and testing to fulfill those use cases. (The
nature of an iteration is explored further in the next section, "The Core Workflow.")

4. Incremental. The iterations of work can be further grouped into increments, marked by milestone
points that indicate a particular large chunk of functionality is ready for release.

The Core Workflow

The Unified Process embraces the core philosophy of the Spiral process: that requirements gathering and
analysis and design are all continuous parts of software development, rather than distinct activities performed in
advance. Like Spiral, UP arranges these activities into a cycle, which forms the Core Workflow of UP, as shown
in Figure 12-8.
Figure 12-8: The Core Workflow of the Unified Process

Note that when I refer to an "iteration" in the Unified Process, I'm referring to one complete cycle through these
five activities that make up the Core Workflow. Here, the five activities of the Core Workflow are as follows:

1. Requirements. Discovering, gathering, and organizing new and existing requirements.

2. Analysis. Analyzing, refining, and structuring the requirements, leading to early stages of an
architecture. Recall from Chapter 9 that the Unified Process considers architecture to mean much
more than code structure. Rather, UP uses the term to mean identification and elaboration of
"architecturally significant" elements of the system. The concept of architectural significance thus
includes the preliminary design of critical subsystems and the preliminary design of critical
functionality. This is why analysis—typically thought of as a requirements activity—involves the
architecture under UP. (UP has four main characteristics. It is architecture-centric, use-case driven,
iterative, and incremental. You'll see these characteristics in the UP diagrams. For instance, Figure
12-8 represents the iterative nature of UP, and Figure 12-9, shown later, will represent the
incremental nature.)

1.
Figure 12-9: The phases of the Unified Process
 2. Design. Refining the requirements and architecture into a detailed architecture and detailed designs.

3. Implementation. Deriving code from the detailed designs, and refining and unit testing that code.

4. Testing. Designing, implementing, applying, and assessing tests to verify that the code meets the
requirements. These results feed back into the Requirements activity, so that you can revise the
requirements based on questions raised in the tests.

Unlike the Spiral process—where Objective Management, Risk Management , Construction Management,
and Iteration Management form the "outer" shape of the process, with details within—the UP Core Workflow
is actually an "inner" shape. These activities happen within larger activities of the process. In UP, all five of
these workflows take place throughout the life of the project, but the proportion of time spent on each during
one iteration changes as the project matures:
 Early in the project, Requirements consume most of the effort. Analysis proceeds to give structure to
the requirements, and to raise architectural concerns that may lead to tradeoffs in the requirements. Design
and Implementation are focused mostly on critical architecture, and perhaps on UI prototypes and other
prototypes to explore the feasibility of the requirements. Testing is a minor effort, focused on identifying
what to test and how to test to verify that the requirements are met, as well as on a testing infrastructure.
 In the middle of the project, Requirements are baselined, but continue to grow in response to new user
needs and to discoveries in other activities. Analysis works to incorporate new requirements into the
existing architecture, and to revise the architecture where it must. Design and Implementation are focused
on architecture in depth and resulting code. Testing is focused on testing new functionality and verifying
that old functionality is unbroken.
 Late in the project, Requirements effort drops to a minimum, handling essential change requests (and
perhaps gathering nonessential requests for a next-generation project). Analysis similarly drops to only that
needed for new requirements. Design is ongoing, but again focused primarily on the few new
requirements. Implementation and Testing dominate the effort, pushing toward the goal of "all
requirements met."

The Unified Process Phases

Early, middle, and late in the preceding discussion are not very specific terms. UP defines much more specific
phases of the development process: Inception, Elaboration, Construction, and Transition, as shown in Figure 12-
9.

I used the «Cycle» stereotype for these phases, because each represents one or more increments of effort, where
an increment is the result of one iteration through the Core Workflow. Thus, each phase is cyclic until enough
increments have accumulated to support transition to the next phase.

The UP phases work as follows:

 Inception. In this phase, you define the requirements and a candidate architecture to the point where
you can assess the feasibility of the project, define initial estimates and schedules, and decide whether to
take on the project or not.

 Elaboration. In this phase, you define the architecture in detail, setting the framework for the
remaining phases.

 Construction. In this phase, the system is built over a number of increments and releases.

 Transition. In this phase, the current set of increments of the system is released to the user community
for use and for feedback.

Again, each phase contains within it iterations of the Core Workflow. Next, we'll look at each activity in the
Core Workflow in more depth.

The Requirements Workflow

The Requirements Workflow is depicted in Figure 12-10.
Figure 12-10: The Unified Process Requirements Workflow

In this diagram, the swimlanes represent actors participating in the workflow:

 System Analyst. This actor is responsible for describing the domain and the requirements to the rest of
the team.

 Architect. This actor is responsible for the architecture of the system.

 Use Case Specifier. This actor is responsible for comprehending and describing one or more use cases
in depth.

 User Interface Designer. This actor is responsible for designing and implementing the use interfaces
of the system.

The «Internal Document» objects in the diagram represent artifacts or work products produced within the
workflow:

 Actor. This object represents the descriptions of one or more actors that will interact with the system.

 Glossary. This object represents the formal definitions of one or more domain objects within the
problem domain.

 Architecture Description. This object represents the description of the architecturally significant
elements of the system. At this time, that means primarily the significant use cases (as judged by the
architect), including Use Case Diagrams and Interaction Diagrams as appropriate. This object will
reappear in other workflows, with new kinds of information added to it in each workflow.

 Use Case Description. This object represents the descriptions of one or more use cases, including
scenarios (perhaps captured as Activity Diagrams).

 Use Case Model. This object represents the structure and relationships of actors, use cases, and domain
objects, captured in part as Use Case Diagrams, Activity Diagrams, and Class Diagrams.
  UI Prototype. This object represents prototype user interfaces for one or more use cases.

The Analysis Workflow

The Analysis Workflow is depicted in Figure 12-11.

Figure 12-11: The Unified Process Analysis Workflow

In this diagram, I've added two new swimlanes:

 Use Case Engineer. This actor is responsible for analyzing and detailing one or more use cases.

 Component Engineer. This actor is responsible for specifying the responsibilities of one or more
classes in one or more packages within one or more components, along with the interactions among
classes.

I've also added the following «Internal Document» objects:

 Architecture Description. This object reappears in this workflow, adding the architecturally
significant classes and packages and components, plus Class Diagrams and Component Diagrams.
Interaction Diagrams can also be helpful explaining the purpose and method of critical use cases.

 Analysis Model. This object represents the packages and components and interfaces of the system,
captured in Component Diagrams and Class Diagrams.

 Use Case Realization Analysis. This object represents the detailed analysis of one or more use cases,
including detailed analysis Class Diagrams and Interaction Diagrams.

 Analysis Class. This object represents one or more classes or interfaces of the system, expressed at the
analysis scope. This identifies the responsibilities and interfaces, but not necessarily the internals.
  Analysis Package. This object represents one or more packages of analysis classes, with each package
possibly corresponding to a component.

The Design Workflow

The Design Workflow is depicted in Figure 12-12.

Figure 12-12: The Unified Process Design Workflow

In this diagram, you see a number of «Internal Document» objects:

 Architecture Description. This object represents the detailed decomposition into components and
interfaces, captured in Component Diagrams, and Class and Interaction Diagrams for the architecturally
significant elements.

 Design Model. This object represents the packages and components and interfaces of the system—in
more depth and implementation detail than in the Analysis Model—captured in Component Diagrams
and Class Diagrams.

 Deployment Model. This object represents the deployment of the components and interfaces to nodes
and physical associations of the system, captured in Deployment Diagrams.

 Design Class. This object represents one or more classes or interfaces of the system, expressed at the
design scope. This specifies the internals of the class: its attributes and operations and behavior in depth.

 Use Case Realization Design. This object represents the detailed analysis of one or more use cases,
going beyond the Use Case Realization Analysis to include precise method parameters, return values,
detailed logic, etc. Writing code from these diagrams should be like falling off a log.

 Interface. This object represents one or more interfaces, specified at a level of detail suitable for
implementation in the target language.

 Design Subsystem. This object represents one or more components that concretely realize a set of
interfaces and contain a set of design classes.

The Implementation Workflow

The Implementation Workflow is depicted in Figure 12-13.
Figure 12-13: The Unified Process Implementation Workflow

In this diagram, I've added one new swimlane:

 System Integrator. This actor is responsible for creating integration plans to install or update the
system.

You also have the following «Internal Document» objects:

 Architecture Description. This object represents updated Component Diagrams, Class Diagrams, and
Interaction Diagrams.

 Component Outline. This object represents the detailed component and deployment structure,
captured in Component and Deployment Diagrams.

 Implementation Model. This object represents a model of the system, and is used in later increments
to help determine what has changed and what needs to be integrated with this iteration.

 Integration Model. This object represents a model of what is new in the system, along with details of
how the new elements shall be integrated with existing elements.

 Interface. This object represents one or more interfaces, refined as needed during implementation.

 Component. This object represents one or more components, fully implemented and ready for testing.

The Testing Workflow

The Testing Workflow is depicted in Figure 12-14.
Figure 12-14: The Unified Process Testing Workflow

In this diagram, I've added three new swimlanes:

 Test Engineer. This actor is responsible for analyzing requirements, designs, and code to determine
testing strategies and evaluate test results.

 Integration Tester. This actor is responsible for testing that new components work correctly with each
other and with existing components in the deployment environment.

 System Tester. This actor is responsible for testing that each individual component works as designed.

You also have the following «Internal Document» objects:

 Test Plan. This object represents the testing strategies, test cases, and expected results used to test all
or part of the system.

 Test Procedure. This object represents one specific set of steps to follow in carrying out a test of all or
part of the system. The same test procedure may be applied in multiple test cases, with different results
expected for each test case. This procedure may include Use Case Diagrams, Class Diagrams, Activity
Diagrams, and other Interaction Diagrams as appropriate. It is, in essence, a model of a test, and thus
may be modeled with UML.

 Test Case. This object represents a single test of all or part of the system, including required inputs and
expected results.

 Test Component. This object represents a component designed and implemented specifically to test
one or more components of the system, as designed in a Test Procedure.

 Defect. This object represents the results of one test case, indicating discrepancies between expected
and actual results.

 Test Evaluation. This object represents the Test Engineer's evaluation of a Test Plan, Test Cases,
and Defects. It should include an evaluation of the severity and consequences of each defect, as well as a
recommendation of whether the defects are sufficient to hold up release of the system. The Test
Evaluation should become an input to the next Requirements Workflow.

Customizing the Unified Process

Wow, there's a lot in the Unified Process! I've identified ten participating actors— larger than a small
development team—and those are only internal actors. There are external actors involved as well. I've identified
26 internal documents and artifacts, without even discussing the external documents. And trust me, I've barely
scratched the surface.
This is why the Unified Process has a reputation for being large and cumbersome. But that reputation is
unjustified. As I discussed earlier, you can customize UP to be larger or smaller as your project warrants. There
are different types of projects—large projects and small projects, agile projects (accepting risk— in this case, a
free-form development approach—for the sake of speed and responsiveness) and orchestrated projects
(minimizing risk, at a cost of speed, by more precisely specifying, controlling, and reviewing development
tasks)—and each type of project needs a different flavor of UP. Some ways you might customize UP include the
following suggestions:
 For large or orchestrated projects, you might have very formal document templates for each kind of
internal document. This helps guide workers in gathering all relevant information and answering all
questions, and the consistency helps readers to understand the documents more easily.
 For small or agile projects, you might allow each type of internal document to be small and free form,
making it easy and fast to prepare and maintain. You might eliminate certain documents entirely,
combine other diagrams, or even capture the relevant information in the models or in the code.
 For large or orchestrated projects, you might assign multiple people to each actor role, each assigned to
some subset of the whole system. Each of the UP actors might represent a whole team, with managers
and reviewers and others as needed.
 For small or agile projects, individual team members may fill many of the actor roles. For a very small
project, one person may fill all of the roles, though it's usually wise to get some outside assistance to
review your work.
 For large orchestrated projects, you'll need many Elaboration increments to ensure that the system is
feasible, along with many Inception increments to ensure that your architecture is correct.
 For large agile projects (not necessarily a contradiction in terms), you might need many Elaboration
increments to understand the baseline requirements, but then have a small number of Inception
increments, trusting that whatever architecture you devise in advance may be modified as needed during
Construction.
 For small projects and most agile projects, you'll probably keep to a small number of Elaboration and
Inception increments, trusting that the real requirements and architecture will be described and defined
during Construction.
 The number of Construction and Transition increments that you need will be determined by your
project's size. You'll also need to determine the basic size of each increment in terms of time. Short
increments allow for more feedback, but require more end-of-transition activities that impose more
frequent overhead. Long increments have less overhead, but are harder to track. You need to determine
the right increment size for your needs. Agile approaches usually advocate increments 2 weeks to 1
month in length. Other projects may have increments measured in months.
 For orchestrated projects, you plan the expected Construction increments and milestones in advance,
updating this plan as circumstances require.
 For agile projects, you plan no further than the current Construction increment. You define its goals
and milestones, define the criteria for determining when the goals and milestones are complete, and start
working. At the end of the increment, you assess which goals were and weren't met, and you make plans
for the next increment.
 For agile projects, you may combine the Core Workflows as needed. For example, you might combine
the Requirements and Analysis Workflows, treating them as a single workflow (analyzing requirements
as you gather them). It's also possible to combine Design and Implementation Workflows to show a
more code-based design process.

So really, the Unified Process is as large or as small and as orchestrated or as agile as you need it to be.
Dogmatically following "all" of UP can sink a small project; but rejecting UP as "too large, too formal" can
deprive you of a powerful tool for planning and organizing your development process.

Both of these models are the software process models that are use d for the development of any
software.The water fall model is a model in which you can't some back to the previous steps. Like
the waterfall it only flows or work in one direction, there is not any possibility that you move to the
previous step. So for that you have to complete your current step fully and don't leave any work in
that step. Otherwise if you reach at the end of next step and you find that there was some missing in
the previous step then you have to start from the scratch again. It is like one-way traffic in which you
can't move backward.

While on the other hand all the steps of the V-model is almost same like the waterfall model, but the
difference Is that, the waterfall model moving to the downward direction, it work in the form of V
shape means at the and move upward. Until the coding step the model move towards downward
but after the coding step it bent and move towards upward direction. The reason for this V shape is
that the each and every step done at one side it will be tested on the other side, so at the end all
steps will be verified and tested correctly.