Home
Articles
OOP, UML and RUP

Object-Oriented Analysis and Design with UML and RUP

Part 2: Processes and Unified Process

Table of Contents
Part 1: OOP, vocabulary, and UML Part 2: Processes and Unified Process Part 3: Summary, going further, and remarks

Development Processes

Why use a software development process

Even if you know what is an object, a class and how you should make use of it, to do can remain difficult. It is even harder if you are accustomed to programme in a traditional way, worse even with waterfall processes. We've pointed out that one can program very well in C++ with classes without never making programming object (it is what makes of C++ an object oriented language and not an object language).

A development process (programming methodology) is a series of steps to follow in order to create classes with their attributes, their methods and the relations between them to create a specific system. They make it possible to increase the productivity largely, to estimate the development time, to create more robust applications - a field called quality assurance which often is part of these processes.

If you program without any methodology or process you're going to encounter the same problems as with the waterfall processes (with even more problems). We will see two development processes: The first an old one, the second definitely more recent.

Waterfall processes: A model quickly problematic

First you make the analyse, then the design of the complete software. You describe step by step the whole software from the requirement up to the details of each class. This method can also be applied for the traditional programming. In short: You document everything perfectly, then start coding afterward.

This method supposes that you won't forget anything at the beginning and that what you could have forgotten will require just small changes. It also supposes that all every will occur as planed. A bit like when a house is built and that with built house looks like what was planned with only some small improvements to do. All the documents which define the preceding stage are regarded as frozen (and are modified only in the event of a major problem).

It is mainly because programming remains still well too near to an art without means mathematically prove (except if one takes a so enormous time that only the army can afford to do so). At the difference of our friends engineers, in physics for example, we do not have yet have tools to prove our system is going to work before building it. The result is obvious: We spend 90% of time for the first 90% of the project, and 90% for the 10% remaining. Most of the problems arrive late and some may require changing the complete software architecture. Every change induces new bugs that will have to be found, fixed, and so on.

Iterative processes: Principles and advantages

All current development processes are based on an iterative approach. It means that you take a part of the sub-set of the features that you're going to analysis, design, and implement, and compile. Then you take another sub-set and make the same way until you have nothing left. Even if I summarize here very much, it is that principle that you have to remember.

The results are clear. You face the risks much earlier and solve them in the early phases of development. So you can plan the rest of project in a more precise way and the whole software gains in quality also.

Unified Process: A development process

Now that we have an idea of the advantages of iterative processes, lets see one more closely.

What is this the UP/RUP?

The Unified Process (UP) (also called Rational Unified Process or RUP because they are nearly identical) is currently one of the most famous development processes among with the Agile methodology (which are more methodologies then a development process). It uses an iterative approach and it is based on programming Best practices.

All the Agile processes are more adapted for small or average teams projects, but they can be grouped with RUP (which gives AUP). RUP remains by far more used and more adapted for the very large projects, however it is possible to use it even in a one-person team. I nevertheless invite you to rather use AUP (Agile Unified Process) if you're alone.

Overview of the UP

We have spoken about iterations, it's the moment to see what UP ask us to do at each iteration:

During the initial iteration you will make in the order every discipline: The modeling of the business, requirements, analysis then design, the implementation, tests, deployment... Once you've finished, you continue with the following iteration (the following column). It is not obligatory to make every discipline. On the graph above, you can see an estimation of the quantity of work required in each field during various iterations.

RUP is split in 4 phases which are carried out in order: Inception, Elaboration, Construction, Transition. When an iteration is finished and when some conditions are fullfilled you may pass to the next phase. Note that for each phase you perform iterations, and for each iteration you perform the all the disciplines (each line of the graph).

We are going to see in a very brief way the disciplines of analyse and design.

Analyse

You make a use case UML diagram or simply write a text document. A use case is a scenario which will meet the need of one or more actors (for example the customer).

For each case of use case you're going to write a scenario of events in business terms. For example:

The user gives his card and type his secret code.
The system validates the code. (alternate: the code is invalid, the card is rejected)
The user enters the amount.
The system checks the balance, provides the money and returns the chart.

Then you look at the nouns in the description of our use case to analyse. Each noun is a possible object. You filter them to keep only true objects and you describe the attributes in a class diagram. You can also make a sequence diagram for the use case, and possibly others.

In the order and in short:

Identify the actors and the use cases
Build the use case model
Describe the main flow of events for a successfull scenario
Identify the relations
Describe the alternative scenarios
Find the potential objects (look at the nouns)
Filter the objects proposed (remove: synonyms, roles, not unique, vague, actions or attributes)

Design

You transform the use case from analyse use case to design use case. It means that you describe in detail what the user make and the system's reponse. For example: "The user between his code and valid" becomes "the user press in the order on the keys pad his code and validates by pressing on the key VALIDATE".

Possibly add new objects, then look the verb phrases this time. Each verb is a possible responsibility for an object. Filter the verbs to remove those carried out manually by the user and then classify the others (Entity/Boundary/Control). Find the object which is responsible for that reponsibility and the collaborators necessary. Thus our methods are obtained.