(RATIONAL) UNIFIED PROCESS

AN END-TO-END SOFTWARE PROCESS

TOMAS LENNVALL LEIF ENBLOM

M Ä L A R D A L E N U N I V E R S I T Y I N S T I T U T I O N O F C O M P U T E R S C I E N C E

2

TABLE OF CONTENTS

TABLE OF CONTENTS .......................................................................................................................2

TABLE OF FIGURES ...........................................................................................................................3

INTRODUCTION ..................................................................................................................................4

MOTIVATION.........................................................................................................................................4 HISTORY ...............................................................................................................................................4

INSTRUCTIONS ON READING .........................................................................................................5

THE UNIFIED PROCESS.....................................................................................................................6

THE FOUR (FIVE) P’S IN SOFTWARE DEVELOPMENT...........................................................................6 People ..............................................................................................................................................6 Project..............................................................................................................................................6 Product ............................................................................................................................................7 Process.............................................................................................................................................7 Tools, A Part Of The Process ..........................................................................................................8

THE LIFE CYCLE ....................................................................................................................................8 The Inception Phase.........................................................................................................................9 The Elaboration Phase ..................................................................................................................10 The Construction Phase.................................................................................................................10 The Transition Phase .....................................................................................................................11

A USE CASE-DRIVEN PROCESS ...........................................................................................................11 A brief overview .............................................................................................................................12 Benefits of use cases.......................................................................................................................12 Capturing use cases .......................................................................................................................13 Analyzing, designing and Implementing The use cases .................................................................14 testing.............................................................................................................................................15 Summary ........................................................................................................................................16

ARCHITECTURE-CENTRIC ...................................................................................................................16 The need for an architecture..........................................................................................................16 Influences on architecture..............................................................................................................17

ITERATIVE AND INCREMENTAL...........................................................................................................17 Iterative and incremental development..........................................................................................18 iterationS........................................................................................................................................19

THE CORE WORKFLOWS .....................................................................................................................20 Requirements .................................................................................................................................20

Requirements in the life-cycle................................................................................................................... 20 Using a Domain Model ............................................................................................................................. 20 Business Model ......................................................................................................................................... 21

Analysis..........................................................................................................................................21 Analysis in the life-cycle ........................................................................................................................... 21 Artifacts..................................................................................................................................................... 21 Workers ..................................................................................................................................................... 22 Workflow .................................................................................................................................................. 22

Design ............................................................................................................................................22 Design in the life-cycle.............................................................................................................................. 22 Artifacts..................................................................................................................................................... 23 Workers ..................................................................................................................................................... 23 Workflow .................................................................................................................................................. 23

Implementation ..............................................................................................................................23 Implementation in the life-cycle................................................................................................................ 24 Artifacts..................................................................................................................................................... 24 Workers ..................................................................................................................................................... 24 Workflow .................................................................................................................................................. 24

Test.................................................................................................................................................25 Test in the life-cycle.................................................................................................................................. 25

3

Artifacts..................................................................................................................................................... 25 Workers ..................................................................................................................................................... 25 Workflow .................................................................................................................................................. 25

RATIONAL UNIFIED PROCESS......................................................................................................26

AN INTERVIEW ....................................................................................................................................27

SUMMARY...........................................................................................................................................29

REFERENCES .....................................................................................................................................29

QUESTIONS TO ANSWER................................................................................................................30

TABLE OF FIGURES

FIGURE 1, THE SOFTWARE DEVELOPMENT PROCESS ................................................................................4 FIGURE 2, THE HISTORICAL DEVELOPMENT OF THE UNIFIED PROCESS......................................................5 FIGURE 3, THE CYCLES OF A PROCESS .......................................................................................................8 FIGURE 4, A CYCLE COMPLETE WITH ITS PHASES AND ITERATIONS ...........................................................9 FIGURE 5, THE FIVE WORKFLOWS THAT TAKE PLACE OVER THE FOUR PHASES ..........................................9 FIGURE 6, THE RELATIVE RESOURCE REQUIREMENTS DURING THE INCEPTION PHASE .............................10 FIGURE 7, THE RELATIVE RESOURCE REQUIREMENTS DURING THE ELABORATION PHASE .......................10 FIGURE 8, THE RELATIVE RESOURCE REQUIREMENTS DURING THE CONSTRUCTION PHASE .....................11 FIGURE 9, THE RELATIVE RESOURCE REQUIREMENTS DURING THE TRANSISTION PHASE .........................11 FIGURE 10 , THE WORKFLOWS IN THE UP, RANGING FROM REQUIREMENTS TO TEST. ..............................12 FIGURE 11,USE CASE MODEL OF THE ATM SYSTEM, THE BANK CUSTOMER IS THE ACTOR AND HE/SHE

INTERACTS WITH THE TREE DIFFERENT USE CASES REPRESENTED BY WITHDRAW MONEY, DEPOSIT MONEY AND TRANSFER BETWEEN ACCOUNTS. ................................................................................14

FIGURE 12, THE ANALYSIS CLASSES THAT PARTICIPATE IN THE WITHDRAW MONEY USE CASE REALIZATION ..................................................................................................................................14

FIGURE 13, A COLLABORATION DIAGRAM FOR THE WITHDRAW MONEY USE CASE..................................15 FIGURE 14, INFLUENCES ON ARCHITECTURE...........................................................................................17 FIGURE 15, EVERY ITERATION PASSES THROUGH ALL THE FIVE CORE WORKFLOWS. ...............................19 FIGURE 16, THE MAJOR MILESTONES AT THE END OF EACH PHASE WHERE THE IMPORTANT BUSINESS

DECISIONS ARE MADE. ....................................................................................................................19 FIGURE 17, AN EXAMPLE OF AN BUSINESS USE-CASE AT A CHECK-IN POINT AT AN AIRPORT ...................21 FIGURE 18, THE WORKFLOW IN ANALYSIS ..............................................................................................22 FIGURE 19, THE WORKFLOW OF DESIGN ..................................................................................................23 FIGURE 20, THE WORKFLOW OF IMPLEMENTATION .................................................................................25 FIGURE 21, THE WORKFLOW DURING TESTING ........................................................................................26 FIGURE 22, THE STARTING PAGE OF RUP KNOWLEDGE BASE..................................................................27 FIGURE 23, INFORMATION ON THE USE-CASE MODEL ............................................................................28 FIGURE 24, THE ITERATION CYCLE AND THE KEY CONCEPTS OF RUP .....................................................29

4

INTRODUCTION

As the title suggests, the unified process deals not solely with a specific part of a development process but with the whole process, from the very idea to the end product. Moreover what the title wants to emphasize is the fact that there is a difference between the Rational Unified Process (RUP) and the Unified Process (UP). The UP is actually a subset of the RUP, where the RUP contains a number of features increasing the ability of the process.

MOTIVATION

Who should be interested in the UP? The main audience of this report would be anyone involved with the development of software. Software of today is marred by shortcomings of various types. The speed in society is increasing and makes it necessary to produce quality software at short times. “Time to market” is an established concept and is very essential for companies today. The product should not be inadequate or out of date by the time it reaches the market and the customers. There is also an emphasis on the quality aspect, software should not only complete its tasks, and it should also be flexible, meaning it should be easy to add features to the products later on. Customers want more ability in the products making the projects bigger and more inflexible. This leads to the need of managing the whole process in a homogenous way, including such parts as providing guidance to a team’s activities, direct the tasks of the individual developers and monitoring the project’s products and activities.

The Unified Process provides a generic process framework that can be specialized for software systems, application areas, different organizations and competence as well as different project sizes. But what do we actually mean by a process? As illustrated in Figure 1, where the process spans over the whole set of activities from the user’s requirements to the finished software system, we need to point out that the box illustrating the software development contains of not one single process but many.

SoftwareDevelopment

ProcessUser'sRequirements

SoftwareSystem

Figure 1, The Software Development Process

A process defines who is doing what when and how to reach a certain goal. The process should be a guide for all who participates in the development – customers, users, developers and managers. A software development process is the set of activities needed to transform a user’s requirements into a software system.

The Unified Modeling Language (UML) is actually an integral part in the thinking of the UP being developed and specified in part by the same people. UML gives the developers a standard way of visualizing, specify, construct, document, and communicate the different parts of the software system. But a note has to be made; UML is a means (merely a tool), not the product. The product should be a robust, flexible and scalable software application.

HISTORY

To understand the UP and why it has been developed, a brief historical flashback of the field would help a lot. There are a lot of contributions made to the final concept, but what today is called the Ericsson Approach was the foundation. Ericsson back in the 1960:s modeled whole systems as sets of interconnected blocks, assembling lower-level blocks into higher-level sub-systems to make the system more manageable. Today we would call these features use cases. For each use case, Ericsson identified the blocks that cooperate to realize it. The next step was to prepare specifications and the result was a static block of diagrams and interfaces, which today would correspond to a simplified version of UML class diagram. Furthermore sequence diagrams and collaboration diagrams were developed and the blocks could be used to compile sources to form executables, which in turn could be downloaded into the target system. The need that

5

forced Ericsson to first work in this direction was that the company created telephone systems. These systems are required to be running 100% during the year, and a developer cannot just turn off the system running because of for example an update in software. This approach is what we today call component-based development. During this time in the seventies the need for a standardization of the functional behavior was needed which led to the Specification and Description Language (SDL). In this specification, blocks communicate with each other solely with messages and encourage the use of class diagrams, collaboration diagrams and sequence diagrams. SDL is still used today by many developers but UML, which was standardized in 1997, will probably take its place in the future.

ObjectoryProcess

1987-1995

The Ericsson Approach

Rational ObjectoryProcess

1996-1997

Rational UnifiedProcess

The RationalApproach

UML

Several othersources

Figure 2, The historical development of the Unified Process

The main character driving this development at Ericsson was Ivar Jacobson who left the company to start his own firm in 1987, named Objectory. At this time the specification was extended to support other industries than the telecommunication market and countries beyond Sweden. Objectory which was also the name of the product developed, and during this time a lot of the terms used today in UP was established at conferences and meetings. In 1995 Rational Software Corporation acquired the Objectory Company and some well-known individuals were connected to the company. Philippe Kruchten, Michael Devlin, James Rumbaugh (the originator of the Object Modeling Technique, OMT) and Grady Booch (creator of the Booch method (surprise!)) were among the recruited people, and their work was also included in part by the Unified Process being developed. Figure 2 tries to depict the historical development of the concept all the way till the product we have today. Recently Rational has acquired or merged with quite a lot of other companies giving rise to a quite complex and big product.

INSTRUCTIONS ON READING

The Unified Process is complex and we have tried to systematically go through the concept, which some may say wasn’t successful L. We will here give some advice though ☺.

Figure 5 is an important figure, which actually depicts all the most important parts of the process, the core workflows together with the main phases. The phases flow over time while the workflows are activities more or less active during each phase. This is a two-dimensional diagram, which results in the paradox of circular reasoning. We have to describe the phases before we describe the workflows and in the same breath we have to describe the core workflows before we describe the phases. Therefore the reader has to read both sections at once, which obviously isn’t a trivial task. Our advice is to flip pages frequently and try to capture the basic meanings of the process. We haven’t included a glossary in this report but rather marked important terms bold.

6

The Unified Process is quite larded with terms, and we have tried to describe the most important ones. Since the Unified Process is tightly interconnected with UML, basic understanding of this subject is not bad.

THE UNIFIED PROCESS

As we shall se in coming sections of this report the Unified Process is use-case driven, architecture centric and iterative. These three properties can be seen as the main currents of thought in the UP driving it ahead. The business part of a project cannot be neglected and there is a human aspect to it all, there are people working in the project. A process needs tools to be automated in greatest possible extent, rendering risks few. All these aspects and many more has to be dealt with in a Unified Process.

THE FOUR (FIVE) P’S IN SOFTWARE DEVELOPMENT

The creators of Unified Process have identified four parts in software development that are a sort of backbone. These four parts (actually five, but Tools doesn’t start with a P. ☺) are described in the main reference[2] for this paper in this way:

“The end result of a software project is a product that is shaped by many different types of people as it is developed. Guiding the efforts of the people involved in the project is a development process; a template that explains the steps needed to complete the project. Typically, the process is automated by a tool or a set of tools.”

The following sections will try to dissect the problems involved with these concepts.

PEOPLE

This is the most essential part of a product coming to life, since no development can be fully automated. The people involved can be everything from architects, developers, testers, managers, users, customers and stakeholders (ung. intressenter). They all contribute in some way, developers develop, managers manage etc. Many parts affect people in their life at work:

• The feasibility (genomförbarhet) of the project. A project that is not feasible will discourage people working in it, and the iterative approach can help out here by terminating these parts not feasible at an early stage.

• Risk management, risks make people uneasy, especially if the risks have not been investigated.

• Team structure has to be considered too, people will work most efficiently if they are working in groups of six to eight people.

• Project schedule. If people discover that a schedule for a project is unrealistic morale drops.

• Understanding of the project, everybody likes to have an overview of what they are involved in.

• Accomplishment. This is important in an iterative process where people provide feedback. Frequent feedback will make leaving old parts behind easier and thus the sense of accomplishment.

A term synonymous to people in UP is worker. A worker is a person that has been assigned to a position and has accepted it. The term is not restricted to mean just a single person but can also be designated to a whole team. The worker has been assigned a task that requires responsibilities as well as abilities. A worker type is the role a worker plays in the software development such as for example an architect or a use-case specifier. An important task for an organization is to transform people from “resources” to workers.

PROJECT

The first project is the one that first releases the product and the cycles of the coming projects extend the life of the system over many releases. Over time the project team has to deal with change, iterations in development and also with the organizational patterns. This is a big subject in it self but we can take notes on some important cornerstones:

7

• A project undergoes a lot of changes during its lifetime. Each cycle leads a release and beyond cycles the product continues for generations.

• The project also goes through a series of iterations, and one can think of iteration as a sort of mini-project.

• A project contains people that are assigned to accomplish something according to some business constraints, which one can identify as an organizational pattern. A business constraint specifies how much the project can cost as well as requirements on quality and when it has to be finished.

PRODUCT

The Unified Process deals not only with the code but suggests that the product produced is a software system. In the definition of what a software system is lie all such things as subsystems, classes, interaction diagrams, and artifacts along with the binary code. Additionally one has to remember that the sales, production, installation and operation of the system are also the product.

This is the reason why the term artifact came into life in the minds of the Unified Process creators. It is a general term for any kind of information created, produced, changed, or used by the worker developing the system. Two types of artifacts can be noted: engineering artifacts and management artifacts, where the first one is the one dealt with in the Unified Process.

An important artifact in the system development is the model. A model is an abstraction of the system mainly created by workers such as architects and developers. One can think of a model as a box with users outside and use-cases inside. The important thing is not how the use-cases look like as long as the created system provides the specified work to the users outside. In contrast to the real system that is being developed, the model can contain elements that describe the environment around it, namely the actors. For example a use-case model consist of use-cases and actors and this is enough for the viewer to understand the systems interactions. The use-case is in that context an outside view of the system, and as will be dealt with in the design section a design model represents the building of the system. The Unified Process consists of the main model sets Use-Case model, Analysis model, Design Model, Deployment Model, Implementation Model and the Test model.

A model identifies the system that is being modeled, and not just the models themselves but also the relationships between them. For example has the use-case model a relationship with the collaboration in the analysis model and such relationships are called trace dependencies or a trace in UML.

PROCESS

Now we have come to the last of the P’s but not the least important, namely the process. What do we mean by a process? One nice way to put it is to refer to it as a template that can be reused. You don’t use a process unless there is some thoughts that can be followed in it or some model to follow. Talking in object oriented terms the Unified Process defines the term Process as a concept that works as a template that can be reused by creating instances of it. A Process Instance in turn is synonym for a project. A requirement in turn is used in a general sense, actually meaning ‘needs'. To understand the requirements one has to understand the needs of the customers as well as the environmental issues in which this users work.

We will in coming sections describe a process in terms of workflow. A workflow is a set of activities. An activity is work done by a worker that defines a responsibility for the worker and produces results (artifacts) based on the input (artifacts).

The Unified Process deals a lot with finding a feasible set of workers and artifacts and this will require a lot of experience. When the set of workers has been found we can describe how the process works through the different workers. This can be depicted in an activity diagram. Figure 18 until Figure 21 can be seen as such activity diagrams.

Since a process can be seen as a template there is of course a need to specialize the process to the environments where it is going to be used. The system developed can be radically different

8

from each other as well as business constraints such as schedule, cost, quality and so on. The creators of the Unified Process claims that it is developed for change and specialization, and making such adaptations feasible for a specific organization. There are differences that will influence the process as organizational factors such as organizational culture, project organization and management as well as skills. Furthermore the domain influences the process through the user community and competition from competitors. Technical factors will also influence such as the use of programming language, development tools and frameworks. The Unified Process as a template has to adapt to this situation.

Why use a process in development? Because it has lots of benefits: • All the developers in the project can understand what he has to do. • Developers can easier understand each other. • Managers who not necessarily know how to code can, thanks to architectural drawings,

understand what developers are doing. • In the company developers and managers can transfer between projects and divisions

and still know how the process is done. • A Company can standardize the training.

TOOLS, A PART OF THE PROCESS

Tools are most important in a modern team of developers. The Unifies Process counts on the use of them and RUP especially relies on its own tools. Why are tools important one can ask? The major reason is that it automates repetitive task, keeps things structured and managing large amounts of information is made easier. On the other hand if you don’t use tools for special tasks you will certainly rely on a lot of manual work and it will be harder to update designs already created. A reflection done by us studying the Unified Process is that tools should not restrict creativeness. We think that in for example a University environment there is a little bit of fear concerning being controlled and the feeling is probably legitimate. Control may lead to control over creativeness. Our hope is that tools will not restrain creativeness but give the creative persons more time to be creative when automating repetitive tasks such as documentation and templates for designing class diagrams.

The process drives the tools meaning that tools are there for the process. The purpose is to make the process easier and more automated. Therefore tools will be evolving due to the progress the process makes.

There is a need for tools making visual modeling of UML an easy task, since UML is a visual language. Tools supporting visual modeling of UML should have features like formatting and drawing and even colors in common.

Tools have to support the whole life cycle; there have to be tools supporting management of requirements, as we have already said; visual modeling, programming tools like debuggers and compilers, and also tools for quality assurance.

THE LIFE CYCLE

Looking at a system or a product a series of cycles make up the life of a product. Each of these cycles is concluded with a product release (For example Word for Windows v6.0). The whole life span of a product can be illustrated as in Figure 3. By a product release we mean a product ready for delivery. A release includes everything the users and all the people that work with the product need to run the system. This includes such things as the binaries, but also manuals and documentation. The in-house release also includes the sources.

Cycle 1 Cycle 2 ... ... Cycle n Time

Release Figure 3, The cycles of a process

9

Each of these cycles consists of phases that all can be subdivided into iterations as seen in Figure 4.

Inception Elaboration Construction Transition

Time

Iteration#1

Iteration#2

Iteration#n

Phase

... ... ... ... ...

Figure 4, A cycle complete with its phases and iterations

As can be noted in the figure above, the cycles take place over time. Taking Figure 5 into account when looking at one can see that there are five main workflows that stream through the project.

InceptionIteration

#1Iteration

#n

TransitionIteration

#2

Elaboration Construction

Time

... ... ... ... ...Core Workflows

Requirements

Analysis

Design

Implementation

Test

Figure 5, the five workflows that take place over the four phases

Each one of these workflows is more important in different phases of the projects life cycle,

but the shapes in the figure aren’t universal but acts as an example. We will deal with these core workflows in coming sections and how they should be dealt with, but for now we look at the whole picture. In each of the phases managers of different sub-projects can divide the work into the interactions as we said earlier but each phase is terminated with a milestone. A milestone consists of a set of artifacts, i.e. models, documents that have matured into something that was foreseen. It is important for developers as well as for management to know and keeping track of how much is spent on each part of the project. This will be important for the future in terms of how much efforts will be spent on each phase and especially how many people will be needed.

THE INCEPTION PHASE

The inception (början, upptagande) phase is the visionary part of the process where ideas come to life and where these have to be transformed into visions of an end product, but also a business case for the product (is it a financially feasible project?). Three main questions that have to be answered are:

1. What is the system primarily going to do for each of its major users? 2. What could and architecture for the system look like? 3. What will the costs be? The goal of the inception phase is to bring the idea to a feasible business situation, which

probably will require delimit the scope of the system proposed. Key terms to think about here are early estimates of cost, schedule and return of investment. Estimating costs is necessary for the delimiting factor just discussed while schedule targets the temporal aspects. A project should not exceed the time factors set up otherwise costs will increase.

10

At the start of the inception phase the starting criteria can vary a lot from project to project. Sometimes there are lots of documentation and material available while other times the client may have only a vague idea of how to design a system and solve a problem.

In the inception phase the core workflows are more or less active as seen in Figure 6.

Analysis TestImplementationDesignRequirements

Resources

Figure 6, The relative resource requirements during the inception phase

THE ELABORATION PHASE

The elaboration phase has these objectives to fulfill: 1. To capture most of the remaining requirements and formulating functional requirements

as use-cases. 2. To establish a sound architectural foundation (the architectural baseline). This baseline

guides the work in the construction and transition phases. 3. Monitor the remaining critical risks and identify risks that can impact the business case

and the bid. 4. Fill in more details in the project plan. The primary focus of the elaboration phase is to formulate the architectural baseline. This means that 80% of the use-cases must be fleshed out and the interfering risks must be addressed to get a good understanding of the system. But only about 10% must be completed (analyzed, designed, implemented and tested). To do this a basic understanding of the whole system must exists, such as the functional and nonfunctional requirements, for example performance. At the end of the phase there is enough information to plan the construction phase and to make a more reliable business case than the one from the inception phase. The figure shows how active the core workflows are.

Analysis TestImplementationDesignRequirements

Resources

Figure 7, The relative resource requirements during the elaboration phase

THE CONSTRUCTION PHASE

The main purpose of the construction phase is to produce software ready for an initial operational release (beta release). The software should of course be appropriate to the requirements. This work is based on the architectural baseline from the elaboration phase; it is expanded through a series of iterations and increments. This means that the rest of the use-cases and scenarios are detailed, subsystems are integrated and tested and so on. The construction phase is also a change of emphasis, from research in the inception and elaboration phases to development. This is a shift from collecting the knowledge to build the system to the actual construction if it (within cost, effort and schedule parameters). There is also a goal to mitigate all risks that exist in the risk list, produce a preliminary user manual and all other artifacts of the system.

11

Analysis TestImplementationDesignRequirements

Resources

Figure 8, The relative resource requirements during the construction phase

THE TRANSITION PHASE

At the transition phase the system has reached an initial operational capability. The system is not perfect since some risks may show up in the user environment and these must be corrected without severely impacting the project plan. The basic intentions of the transition phase is:

1. To meet the requirements established in the earlier phases (to the satisfaction of the stakeholders).

2. Handle all issues for the operation in the user environment and correction of flaws discovered during the beta test.

The main focus of the phase is to establish the product in the operational environment. This is accomplished by beta testing and acceptance testing usually performed by the customers, but special acceptance test organizations exist. Feedback is collected from the operating sites so that the system can be modified if necessary. The transition phase ends with a product release.

Analysis TestImplementationDesignRequirements

Resources

Figure 9, The relative resource requirements during the transistion phase

A USE CASE-DRIVEN PROCESS

The goal of the UP is to help the developers to efficiently implement and deploy systems that meet the customer’s needs. Efficiency is measured in terms of cost and quality. The process of making an implementation out of the customer’s needs is not trivial, because those needs are not easy to discern. This lead to the need of a way to capture the users needs so they can be clearly communicated to all the people involved in the project. Then there is also a need to be able to design an implementation that meets the customer needs. And lastly also to be able to verify the system by testing that the customer needs have been met.

Figure 10 shows the different workflows in the UP, from requirements to test represented by different models.

12

Requirements - - - - - - - - -

Analysis - - - - - - - - - - - - - - - - -

Design - - - - - - - - - - - - - - - - - - - - - - - -

Implementation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Test - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Use-Case model

Analysis model

Design model Deployment model

Implementation model

Test model Figure 10 , the workflows in the UP, ranging from requirements to test.

A BRIEF OVERVIEW

There are two objectives for requirement capturing: first to find the requirements that add the expected value to the users, and secondly to represent them in an understandable way. A system usually has many different types of users; these users are represented as actors. An actor uses the system through interaction with use cases; a use case is a sequence of actions that the system performs to give a result of value to an actor. The use case-models of a system are made up of all the actors and the use cases in the system.

Analysis and design then transforms the use case model into a design model via an analysis model. The analysis and design models consist of classifiers (class like things) and also use case realizations, that is, how the use cases are realized. The analysis model is a detailed specification of the requirements. It’s used by the developers to understand the use cases more precisely by refining them as collaborations between conceptual classes. This is also the difference between the analysis model and the design model; it’s a conceptual model rather than a blueprint of the implementation as the design model is. There is a mapping between the subsystems in the design model and components in the implementation model. The developers identify the classes that participate in the realizing of the use cases; they also assign responsibilities to the classes corresponding to the responsibilities of the use case they realize. Use case realizations are stereotypes of collaborations, where collaboration represents how classifiers act to realize a use case.

The developers then design the classes to take better advantage of products and technologies (GUI kits, COM, CORBA, and similar products) that are used to implement the system. Making subsystems of classes and defining interfaces between these subsystems further refines the design model. The deployment is the definition of the physical organization of the system as computational nodes. This is then used to verify that the use cases can be implemented as components that execute on those nodes. The designed classes are then implemented as source code in the implementation model, from where executables can be produced; this can be in different forms (dlls, Java Beans,).

Lastly in the test workflow the system is verified so that it really implements the functionality described in the use cases. And that it also satisfies the system requirements. The test model consists of test cases that define of input, execution conditions and output (result). Some test cases can be constructed directly from the use cases which means that the testers can verify that the system really does what the user require it to do.

BENEFITS OF USE CASES

Below are two major reasons why use cases have become so popular and widespread: • They offer a systematic and intuitive means of capturing functional requirements with a

focus on value added to the user. • They drive the whole development process, since many activities such as analysis; design

and testing are preformed starting from the use cases. By taking the perspective of each user the proper use cases for the system can be identified,

the use cases that add value to its users. In this way only the proper use cases will be detected, by

13

using other methods unimportant and bad use cases can be accidentally included. Bad use cases are such that they allow the user to perform actions on the system that they are not allowed to do which can lead to dire consequences. It has been found that by simply asking yourself what you want the system to do is not enough; you don’t get the right answers. In this way you get a list of system functions that can at a first glance seem valuable, but may not at a closer look be related to the user needs. The use case strategy extends the common question: “What do you want the system to do?” by adding the three important words: “for each user” to the end of the phrase. This shapes the search for system functions by looking at the system from every user view and discerning what that user wants the system to do. Further this process also involves the users, the customers and the developers in the process of identifying the use cases. And also since use cases are intuitive and often written in plain English (or whatever language) it’s easy to understand for everybody, no complex notational knowledge is required.

Use cases also drives the process as mentioned earlier. This means that the use cases initiate many of the workflows in the project. They also help the project managers plan, assign and monitor many of the different tasks that the developers are carrying out. The project manager can also easily identify the tasks from the use cases and assign the task to different individual developers; each-use case to specify is a task, each use case to design is also a task and so on. It can also help the manager estimate the project size, required resources and also the time and effort to complete a task.

Use cases also support traceability through all the models, which is an important mechanism. This means that the use case requirements are traceable to its realization in analysis and design, to the classes that participate in realizing it, to components and finally to the testing. This is important for the project management, if a use case is changed every affected part in the analysis and design, implementation and testing must also be changed. This means that it’s easier to maintain the integrity of the system and to keep it up to date when requirements change.

The use cases can also help with selecting the architecture of the system, by selecting the right ones, architecturally significant ones, a stable architecture can be implemented that can then be used for further subsequent development cycles. Its also possible to estimate how often different paths through the use cases is performed so that the dimension of the underlying hardware (processor, or something similar) can be set.

Use cases are also the starting point for documentation since they describe the user interactions with the system.

CAPTURING USE CASES

The use case model is an agreement of how to use the system, agreed upon by the users, the customers and the developers. The users are represented as actors that interact with the use cases, all the actors and the use cases make up the model. Actors don’t need to be humans they can be other systems, external hardware, anything that communicates with the system. A user may take the roles of several different actors when interacting with the system and also several different users may take the role as the same actor. Actors are a part of the environment of the system.

The definition of a use case is as follows: A use case specifies a sequence of actions, including variants that the system can perform and that yield an observable result of value to a particular actor. The use cases specify the system; they are fashioned to meet the users needs as they use the

system. The use cases are found by looking at how the users need to use the system to do their work, each such case that adds value to the user is a candidate use case. These candidates can be changed into smaller use cases or become parts of larger and more complex use cases. One use case can consist of several variants of that use case, these variants are different paths taken by the sequence of actions performed during operation by a specific use case. Use cases that have similar variant-paths are grouped together for ease of understanding.

The use case model is almost finished when it captures all the functional requirements of the system in a correct and understandable way. The following figure (Figure 11) shows a simple use case model of an ATM (Automated Teller Machine) system.

14

Bank customer

Withdraw money

Deposit money

Transfer betweenaccounts

Figure 11,Use case model of the ATM system, the bank customer is the actor and he/she interacts with the tree different use cases represented by withdraw money, deposit money and transfer between accounts.

The next step is to write specifications of how the use cases work, its sequence of actions to give value to the user. The withdraw money use case from the model above is used as an example:

1. The bank customer identifies himself/herself. 2. The bank customer chooses from which account to withdraw money and specifies how

much to withdraw. 3. The system deducts the amount from the account and dispenses the money.

ANALYZING, DESIGNING AND IMPLEMENTING THE USE CASES

In each iteration use cases are selected and then realized, the analysis model grows incrementally with the iterations. The goal of the analysis is to transform the use case model into a design model via an analysis model. The analysis model is a structure of classifiers and a realization of the use cases as mentioned above. Another goal is to also make the realization of the use cases cost efficient, for performance and future evolution. The first step is to read through the use case description and identify classifiers and associations that are needed. Later in the process the classifiers may already exist in the architecture so that we can reuse them or they become new ones that maybe can be reused later. Each classifier plays one or more roles in a use case; each of these roles specifies the responsibilities, attributes and so on for the realization of the use case. A way to look at a classifier is to imagine it like a class with several attributes and responsibilities, and then a filter is put over it to conceal every other role than the one being realized. The figure shows the realization of a use case from the ATM example above.

Withdraw Money Withdraw Money

Use-case model Analysis model

<<trace>>

Dispenser CashierInterface

Withdrawal Account

participant

Figure 12, The analysis classes that participate in the withdraw money use case realization

The next step after all the classifiers responsibilities have been set and the relationships between them have been found, is to detail the interaction that takes place in realizing the use cases. To understand the interaction patterns, how each use case realization is preformed must be described. To model interactions among the objects in the analysis, collaboration diagrams are used. A collaboration diagram resembles a class diagram but shows instances and links (an instance is a synonym for objects and a link is an instance of an association) instead of classes and associations. The interactions are also numbered so that it is possible to see if the objects interact sequentially or in parallel. It’s also possible to use text to explain the interaction between

15

the objects to complement the collaboration model. The figure shows a collaboration diagram for the withdraw money use case.

:BankCustomer

:Dispenser

:CashierInterface

:Withdrawal :Account

1: identify 2: request withdrawal

3: validate andwithdraw

Figure 13, A collaboration diagram for the withdraw money use case.

After all the use cases have been analyzed and all the participating class roles have been identified, all the classes must be analyzed.

All classes must fulfill all its collaboration roles; the responsibilities of a class are all its roles in all use case realizations put together that it participates in. The use case designer is responsible for ensuring that the classes realize the use cases correctly. If something is changed in a class the designer of the class is also responsible for making sure that it can still fulfill its roles in the realization of the use case. The same also applies for a use case designer, if something is changed in a use case it must also be changed in the realization. Thus the roles of a class help maintain integrity of the analysis.

The design model adapts the analysis model to a selected implementation environment; it can be a certain framework, a database management system or something similar. It can also be an older system that has to be incorporated wholly or partially into the new system being developed. Thus the design model is a blueprint for the implementation of the system. As the analysis model, the design model also defines classifiers, relationships between them and also collaborations that realize the use cases. The difference is that in the analysis model the elements are more conceptual than in the design model where the elements are adapted to a certain environment. In the design model the class diagram introduces a lot more detail than in the analysis model, this is because the analysis classes are refined to design classes adapted for the implementation environment.

The interaction between the classes also needs to be identified in detail, as in the analysis model. This is done in a sequence diagram that shows exactly how the objects interact to realize a use case.

The design model is likely to contain many classes and if it approaches thousands or larger numbers it becomes impossible to work at the class level when realizing use cases. Therefore the classes are grouped into subsystems that is a semantically useful grouping of classes or even other subsystems. Each subsystem has a set of interfaces that define the context of the subsystem. It is possible to devise the subsystems either bottom-up or top-down. Bottom-up means that the already found classes are used as a basis for the subsystems, the suggested subsystems package the classes into clearly defined functions. In the top-down model the subsystems and interfaces are identified before the classes are identified.

Next the implementation model is made up of components that include all the executables. Components can be things like files (source code, shell scripts and so on) database elements and so on. Components are also replaceable physical parts of the system that provides and conforms to the realization of the interfaces. This also makes it easier to replace the components with newer and better versions long as they conform to the same interface as the older ones, which is a valuable property.

TESTING

Testing is the workflow where the system is verified so that it correctly implements its specification. A test model, consisting of test cases and test procedures is developed, and executed to make sure the system works, as it should. A test case consists of input, execution

16

conditions and expected output results for a particular path through a use case. A test procedure is a specification of how to setup, execute and evaluate a particular test case. As stated before, test cases can be derived from use cases. Use case tests can be performed by treating the system as black box, which means that the test cases can be specified as soon as the requirements are reasonable stable. It can also be viewed as a white box where the test cases are constructed to verify that the internal parts do what they should when a use case is realized. An example of a test case for the withdraw money use case follows:

Input: • The bank customer’s account 12-121-1211 has a balance of $350. • The bank customer identifies himself/herself correctly. • The bank customer requests to withdraw $200 from account 12-121-1211. • There is enough money in the ATM.

Result: • The balance of the bank customer’s account 12-121-1211 decreases to $150. • The bank customer receives $200 from the ATM.

Conditions: No other use cases are allowed to access the account 12-121-1211 during this test case.

SUMMARY

Use cases drive the process. Requirements are represented as use cases; project managers can plan the project in terms of use cases that the developers work with. During analysis and design, the use case realizations are created, in terms of classes or subsystems, and later implemented as components. Each component is part of an increment that realizes a set of the use cases and finally testers verify that the system implements the right use cases, the ones that give value to the users. This is what is meant by use cases driving the development process, they bind all the activities together, which is the most important benefit of the use case driven approach.

ARCHITECTURE-CENTRIC

Use-cases provide a good way of understanding the problems and situations that may occur in a system, but this will not be enough for a whole process where we need to perform analysis, design, implementation and tests.

THE NEED FOR AN ARCHITECTURE

What is then the architecture of a system and what is the motivation of creating it? If you for example want to build a simple construct as a shelter against rain for your car it may be enough to build a roof, i.e. a carport. But in the same way you may want a workshop (sw. Verkstad) too and the need to integrate it to the same building increases. This in turn may require you to plan for electrical outlets and build walls etc. The whole work is pretty simple since everybody knows what will be needed in a workshop and the constructor can design the workshop without gigantic blueprints etc. Everything that should be done can be done in the head of the designer. But when the design gets bigger, for example if you want to build a skyscraper, there will be a need for a big team of architects, and they in turn need to present a common vision to laymen such as the owner and the users but also to the builders and the suppliers of material. This analogy can also be applied to construction of software. Basically we need architecture in order to understand the system, organize development, encourage reuse and evolve the system. Understanding the system is a challenge in terms of behavior, environment and technology among others. Organizing development is needed to coordinate developers and that is made especially difficult when the project is geographically dispersed. Encouraging reuse is important and standardization and use of standard components makes development more effective. The developers know the problem domain and thus can make use of the standard components available but in the domain of software it is more difficult to create standard components. UML will hopefully accelerate the componentization process thus encouraging reuse. A good architecture will make evolving the system easier, making changes easy to implement and thus enabling future evolution an easier task. New features should be easy to incorporate and developers should be able to change functionality without having to worry about making the whole system unstable.

17

As an example of the importance of architecture one can look at the Ericsson AXE project which was started in the early 1970s, being a template to the UP look at architecture today. Function modularity was an important concept bringing parts of the system together into blocks, thus encouraging strong cohesion (sammanhang) in the system. Furthermore the company tried to separate the interfaces of the blocks with the services in the subsystems thus making blocks more pluggable. Loose coupling among service systems was another main idea and targets the fact that signals in the system are mostly asynchronous and are therefore encapsulated and supports distribution (i.e. no send-and wait semantics).

INFLUENCES ON ARCHITECTURE

We say that the UP is use-case driven and architecture centric. Use-cases show the main interactions that both customers and developers have agreed upon. The architecture gets input from mainly these use-cases but also from other factors. Figure 14 below shows some influences on the architecture.

Use-cases

Architecture

Experience

Constraints and enablers

System software

Middleware(ex. frameworks)

Legacy Systems

Standards and Policies

Nonfunctional Requirements

Distribution needs

Previous architectures

Architectural Patterns

Figure 14, Influences on Architecture

System software products influence the products we want to create, such as operating system or if we for example want to use a specific application as a particular relational database management system. Furthermore do middleware provide and substantial impact on the architecture, such as the selection of a special Object Request Broker (ORB) or for example a platform-neutral framework. Legacy systems (befintliga, “gamla” system and products), for example an existing banking system, can enable us to reuse existing functionality but we are also stuck with its specific features. This will probably lead us to adjust the architecture accordingly. Standards and policies will influence architecture as well; we might choose to adapt our interfaces to some standard as for example OMG’s Interface Definition Language (IDL) or POSIX. Nonfunctional requirements such as requirements on availability, recovery time or memory usage will also be an influence. Finally the constraints on how the system is distributed, perhaps via client/server architecture, will affect architecture. As we will deal with in next section iterations are an essential part of the Unified Process and the architecture is mainly developed during the elaboration phase.

ITERATIVE AND INCREMENTAL

Each phase in the process contains a number of iterations and increments. These iterations and increments lead to the fulfillment of certain criteria so that movement to the next phase can occur. Each phase have different criterions that must be fulfilled before a move to the next phase can be done as shown below:

The inception phase: • Identifying and reducing risks critical to the systems viability.

18

• Moving from a key subset of the requirements into a candidate architecture. • Initial estimate of the cost, effort, schedule and product quality. The elaboration phase: • Identifying and reducing risks that affect the system construction. • Specifying most use cases that represent the functionality to be developed. • Make a project plan (a “road map” for the project) sufficient to guide the construction

phase. The construction phase: • A series of iterations that leads to increments (periodic builds), viability of the system is

evident in executables. The transition phase: • Modify the product to account for problems not discovered earlier. • Correcting defects (a system fault discovered during testing or reviewing). One of the goals of the UP is to make developers, architects and stakeholders to grasp the

importance of the early phases. The iterative-and-incremental development approach is the third key aspect of the UP. It provides a strategy for developing software in small and manageable steps.

In the early phases the iterations are mainly aimed at reducing the risk, scooping the project and baseline the architecture. The development project changes the requirements into a software product in small steps, each step is called a miniproject and each one is iteration. All iteration consists of everything in the whole project: requirements, analysis and design, implementation and testing. Each iteration produces an internal release (for the project member, not the customers) of the product, its not a full version but only covers the part the iteration took care of (reduction of risks). The early iterations provide a knowledge base for the later iterations, this means knowledge about requirements, risks and the problems. Later iterations are additive increments that eventually result in an external release (release to the customer).

ITERATIVE AND INCREMENTAL DEVELOPMENT

The main reason for using an iterative and incremental development approach is: better software, which is a result from the better control of development that this approach gives. UP is a risk driven software process because it addresses the risks in the two first phases: inception and elaboration, it does this by iteration. Compared to the waterfall approach (common design method) the iterative approach reduces the risks in the early phases but the waterfalls method don’t take risks into consideration until the testing stage. Another result from iterations in the early phases is a robust architecture, in the inception phase the goal is an architecture that satisfies the requirements, overcomes critical risks and resolves central development problems. And in the elaboration phase the goal is to establish an architecture base for guiding further development. It’s also easier to understand a system that operates, even if only parts of it work, than a system that only exists as documentation. And this working “system” is then expanded by more iteration's and new versions are produced with more functionality incorporated. This early working version of the system makes it easier for the customers to propose suggestions or changes to the system.

Since the iterative approach is risk driven, it deals with reducing risks in the different phases. A risk is a project variable that endangers or eliminates the success of a project. The iterations are organized to achieve risk reduction on the basis of the risks order of importance. Some examples of serious risks are: matters of performance (speed, capacity, accuracy), reliability, availability, adaptability and portability. We try to order the iterations so that each one builds on the previous one; this is so that the risk of having to rework previous iterations due to the wrong order of iterations is avoided. To deal with a risk the designers basically have four choices: avoid it, confine it, mitigate it or monitor it. Depending on the risk one of the approaches is taken, it

19

might not be possible to completely remove all risks and that is why such options as confining it exist.

ITERATIONS

Iteration’s can be viewed as workflows, which means that it’s collaboration between workers. The UP distinguishes between two workflows: core workflow and iteration workflow. CORE workflow is the five ones discussed above: requirements, analysis, design, implementation and testing. Iteration workflows pass through all five of the core workflows and start with a planning activity and ends with an assessment, as can be seen in the figure below.

Analysis TestImplementationDesign

An iteration

Requirements

Includes additionally:� Iteration and planning� iteration assessment� specific activities

Figure 15, each iteration passes through all the five core workflows.

A thing worth noting is that when testing is done in the iteration workflow, regression testing must be used. Regression testing means that we have to retest the parts of a previous version that has already been tested to guarantee that the behavior has not been changed by the latest iteration. The iterative approach requires more planning and more thought than the waterfall approach. The iterative approach do not plan the whole project in detail during the inception phase as opposed to the waterfall approach were almost all the planning is done at the beginning. Not until the elaboration phase when a good base has been established is the construction and transition phases planned. It’s also important to try to sequence the iterations so that the important decisions can be made early.

Increments are the difference between the internal release of a specific iteration and the internal release of the following iteration.

Each of the four phases concludes with a major milestone as shown in the figure below.

Inception

Iter. 1

Elaboration Construction Transition

Iter. 2 Iter.#n-1 Iter. #n... ... ...

Life cycle objectivesmilestone

Life cycle architecturemilestone

Initial operationalcapability milestone

Product releasemilestone

Milestones

Figure 16, the major milestones at the end of each phase where the important business decisions are made.

The goal of each major milestone is to make sure that each of the workflows most important decisions has been taken early in the life cycle. Within each phase there are also lesser milestones,

20

at the time of an internal release, i.e. the end of an iteration. At these minor milestones the managers and developers decide how to best to the subsequent iterations. Minor milestones are a planned step towards major milestones at the end of the phase. At the major milestones crucial go/no go decisions are made, determinations of the budget and schedule are made and so on.

THE CORE WORKFLOWS

What is a workflow (arbetsflöde)? The definition in the main reference is ”A realization of (a part of) a business use case”. It can be described in terms of activity diagrams that include participating workers, the activities they perform, and the artifacts they produce”. We will here try to learn about the different core workflows that are included in a process.

REQUIREMENTS

A project has to capture the requirements, answering the trivial question, what is going to be built? The question is actually not that easy to answer and it is not uncommon that teams start coding before they know what the code actually is supposed to do. A first error may be to ask the users of the system what they want since they probably cannot oversee the whole environment and the factors involved and since they may be divided in many user groups. Then it is common to think that a team of analysts can provide lots of documentation that will be readable and understandable for others involved. This proves also an error-prone way to go.

The requirement workflow has to solve these problems and the purpose is to aim the development towards the right system. An agreement has to be made between the customers and the developers of what the system should look like and what it is supposed to do and then the requirements have to be captured so that the customer can understand it.

To be able to capture the requirements of the system four things have to be done: 1. List the candidate requirements. Having a list of features gives the ability to add and delete

the features when they become requirements. Each feature can have different values represented such as priority, risk and estimated cost to implement.

2. Understand system context. It is important that everybody involved can communicate and understand the context of the system and therefore a common glossary has to be established. Here the domain model and the business model helps out.

3. Capture functional requirements. It is important to capture these in use-cases early on. 4. Capture nonfunctional requirements. These are also important to capture. Nonfunctional

features may include performance, extensibility, availability, mean time between failures and reliability.

Requirements in the life-cycle

Looking back at Figure 5 one can see that the requirement workflow is mostly active during the inception and elaboration phase. During the inception phase most of the analysis is performed and the purpose is to delimit the scope of the project. Then during the elaboration phase over 80% of the requirements should have been documented for sake of the developers knowing the extent of their work. Finally only a small part is completed in the construction phase.

Using a Domain Model

A domain is an area of knowledge or activity characterized by a family of related systems. A domain model captures the most important types of objects in the domain. For example are orders, accounts and contracts domain classes that fall in a category of business objects. Missiles and enemy aircraft are real-worlds objects and aircraft arrival is an example of an event object. All these objects can be modeled together in what is called a domain model. UML is a nice tool to use for describing the domain model and class diagrams are most suited for that.

21

Business Model

The business model is a technique for understanding the business processes of an organization. Business modeling uses two kinds of UML models, use-case models and object models. There are definitions in the business-specific extensions to UML. A business use-case describes the business from the inside, illustrating how actors i.e. workers, are acting on business entities. These entities can be for example orders, invoices or items. The workers can for example be testers, salesmen or customers. A simple example of a business model, illustrated with a use-case, of a check-in at an airport is shown in Figure 17.

Figure 17, An example of an business use-case at a check-in point at an airport

ANALYSIS

The purpose of analysis is to capture the requirements as described in requirements by refining and capturing them. Looking at Figure 5 and Figure 24 one can see that after finishing the requirements specification one should deal with the analysis. The use-cases of the requirements should be as independent of each other as possible not interfering with each other. This can lead to unresolved cases where the states of two or more use-cases lead to states of the system not thought of. Therefore it is important to talk the language of the developers while in the analysis workflow. The developers should be able to understand the specifications, be able to prepare them, change them and maintain them.

To be able to succeed with these criteria we have to come from an external view of the system to an internal view in the end leading to the specification of packages and stereotypes. A stereotype in UML is a building block derived from existing ones and extended by the user. It is important to capture the functionality of the system and the analysis should not contain redundancies or inconsistencies. Analysis is a first step towards design, which is the next step in the workflow.

Analysis in the life-cycle

Looking back at Figure 5 one can see that analysis is mostly active during the elaboration phase. Here the specification of the architecture gets a firm grip and the understanding of the requirements is well established.

Artifacts

There are certain artifacts that may be produced by an analysis. The top-level artifact is the analysis model. It contains analysis packages that in turn contain analysis classes. An analysis package organizes the analysis model into smaller pieces while analysis of classes involves analyzing a set of objects that share the same attributes, operations, relationships and semantics. Without going

22

too deep into the different artifacts one can conclude that these consist of use-cases that are refined and modified to describe functionality.

Workers

Who or which systems are going to work with the analysis and what artifacts should be produced? First there is the architect who is responsible for the integrity of the analysis model. This includes the fact that it should be readable. The architect is at the top-level of the model, responsible for delegating work to workers and put the right competence where it is needed. The architect should not be responsible for the artifacts actually created.

The use-case engineer deals with specified use-cases that have become his responsibility. These use-cases should be updated and to reflect the functionality and that they suit their purpose.

There is yet another responsibility and that is the Component Engineer who maintains the attributes, relationships and special requirements of the analysis classes.

Workflow

With the different workers in mind from the section above one can look at Figure 18 and see how the workflow involves the workers over time.

Architect

Use-case Engineer

Component Engineer

ArchitecturalAnalysis

Analyzea use-case

Analysea class

Analyzea Package

Figure 18, The Workflow in analysis

DESIGN

As before the major input to this workflow is the results from the analysis. The purpose of design is to take the refinements done in analysis and take the specifications further. This will include understanding the non-functional issues concerning requirements and constraints. Now we are beginning to look at aspects such as programming languages, component reuse, operating systems, concurrency technologies, user-interface technologies etc. Furthermore the designer looks at the individual sub-systems and their interfaces and classes. If these parts are divided into manageable parts there is much hope of distributing work concurrently between different software teams. In this context it is important to define the interfaces between sub-systems well and keep them clean during the progressing work.

Design in the life-cycle

Looking back at Figure 5 once again we see that design is focused during the end of the elaboration phase and the beginning of the construction phase. Remember that design is close to implementation and it is natural to maintain the design model the complete software life cycle.

23

Artifacts

What does the design workflow produce is a natural question to ask. The top-level artifact is obviously the design model, which describes the physical realization of use-cases. The design model in turn includes design classes, which are an abstraction of the coming implementations. In the design classes there is room to specify parameters, attributes, types etc. and now the chosen programming language’s syntax can be used. The visibility of for example methods can be adjusted, if using C++ with public, private and protected. Methods are with success elaborated with pseudo-code when the designer and the implementers are different workers. The recommendation is that the implementer and the designer are the same person. The realization of the analysis diagrams can be converted into UML class diagrams including participating subsystems and design classes. The designing of subsystems is essentially the work of dividing the system into smaller pieces maybe using reusable software. An important artifact in this context is the interface, which is important to design well together when creating the subsystem. Now the number of artifacts increases with the deployments, which in short means defining the nodes where the different subsystems shall operate. This may mean defining the network the system should work in and the functionality of the nodes.

Workers

Lets consider our three workers from the analysis workflow. The architect is only responsible for the integrity of the design and the deployment models (where the different parts of the system end up) and will therefore not be involved in the construction of the artifacts. The use-case engineer in turn is responsible for the individual use-case implementations concerning the behavior. The component engineer is the one defining the operations, methods, and attributes of the design class that has been allotted him.

Workflow

With the different workers in mind from the section above one can look at Figure 19 and see how the workflow involves the workers over time.

Architect

Use-case Engineer

Component Engineer

ArchitecturalDesign

Designa use-case

Designa class

Design asubsystem

Figure 19, the workflow of design

Further thoughts concerning design may include layering. The need of splitting the system into smaller parts can lead to the need of designing a middleware or a database middleware. In that case it is more important than ever to keep the interfaces clean and that the architect keeps consistency in the architecture.

IMPLEMENTATION

Now the fun part starts most programmers’ think, the real work. But in fact this part should be a minor part of designing the product, most of the work should already be done. One should

24

be a “code-slave” at this stage. Implementation includes work creating the source code, compiling the binaries, designing the scripts and more. During in this workflow the implementer also has to think into the future, planning for the next step of iteration while in the implementation workflow. Now the work of distributing the executables to the different nodes (mostly computers) is performed as well as the first test of functionality.

Implementation in the life-cycle

When we once again look back at Figure 5 we see that implementation is mainly an activity during the construction phase. During transition the activity is lessened with exception of a small little top when late errors from beta testing are discovered.

Artifacts

What are the products created while in this workflow? On top of everything is as always a model, in this case an implementation model. The use-cases are as always involved and compared to the subsystems. Components are created which is the “physical” packaging of model elements such as design classes. This may include executables, files, libraries and documents. The implementation subsystems may also be a part of the implementation. They are artifacts organizing the implementation into manageable pieces, such as packages in Java or projects in Visual Basic. The interfaces designed in the design workflow now have to become realized and of course the operation of them has to be correct. An integration build plan also has to be developed in this workflow. Software is built in steps and a plan concerning the different builds has to be specified. The ability of filing a build must exist and this requires good version control of sources etc.

Workers

Lets once again go back to our workers and see what they are up to in this workflow. As always is the architect responsible for the integrity of the models. How much work this will create for the architect is hard for us to estimate but he/she should not be involved in the artifacts. The component engineer on the other hand maintains the source code of the components. The use-case engineer has in this workflow been traded out to the benefit of the system integrator who is responsible for the builds.

Workflow

With the different workers in mind from the section above one can look at Figure 20 and see how the workflow involves the workers over time.

Architect

Use-case Engineer

Component Engineer

ArchitecturalImplementation

IntegrateSystem

Implementa

subsystem

PerformUnit Test

Implement aclass

25

Figure 20, The workflow of implementation

TEST

Testing is an important task and each build has to be tested. Test have to be planned well, integration tests are performed in every iteration while system testing is performed at the end of the iteration. One has to systematically handle results and defect code has to be sent back to the implementation workflow or the design workflow.

Test in the life-cycle

One last time we go back to Figure 5 and look at the activity of testing in the different phases. Testing must be planned from the beginning on, so it is already being planned during the elaboration phase.

Artifacts

The test model is produced in this workflow; it describes how to test executable components by integration and system tests. The test model can also describe how to test specific aspects of the system (like user interface and so on). Test cases are also artifacts of this workflow, and they specify ways of testing the system (one case specifies one way). Test procedures specify how to perform several test cases or parts of them. Test components automate one or several test procedures, like a script that performs the tests. Test plan describes the test strategies, resources and schedule. It defines what kind of tests that should be performed every iteration. Defects is another artifact that can be produced, it's a system anomaly (a symptom of a software fault).

Workers

The different workers in this workflow are the Test designers who are responsible for the integrity of the test model, ensuring that it fulfills its purpose. There are also Component engineers responsible for the test components and integration testers who perform the required integration tests in the implementation workflow. System testers are responsible for the system test at the end of a complete iteration.

Workflow

With the different workers in mind from the section above one can look at Figure 21 and see how the workflow involves the workers over time.

26

TestEngineer

Integration Tester

System Tester

Plan Test

PerformIntegration

Test

Implementtest

EvaluateTest

PerformSystem

Test

Design Test

Component Engineer

Figure 21, The workflow during testing

RATIONAL UNIFIED PROCESS

Rational Unified Process (RUP) is an offspring from the same people that created the first Unified Process as we described in the history section. The main base if of course the Unified Process but Rational has in their product added features and abilities to provide a (hopefully) more flexible solution. What is then actually RUP? What is the product? We are used to get a product in our hands when we deal with software. Our compilers are bought as a separate package including documentation and executable code for a platform, and in some cases we get support around the product, for such things as installations and problems related to that.

RUP as a product includes a book that serves as an introduction to the subject and access to a web-based searchable knowledge base. As a customer you also get access to a team that is helping you out on problems that arise when you try to adapt RUP for your company. The knowledge base provides all the people involved in the company working as a team with guidelines and templates for their activities. We have tried the evaluation version of RUP that is available on Rational's homepage [1]. It is actually an evaluation version of the knowledge base where the user can click his way through menus in his search for information. Figure 22 shows how the starting page of the evaluation version looks in a browser. From the left link-structure called the treebrowser one can navigate through the entire information that is available. For example you can find information on how you best deal with the core workflows such as for example analysis. Please note that the overview seen in Figure 22 gives a nice picture of Figure 4.

27

Figure 22, The starting page of RUP knowledge base

The RUP is not an integrated tool for keeping developers and managers up to date about how the project proceeds but acts rather as a wrapper and guideline about how the process is to be best executed. When the need arises to keep all team members of the project updated another tool is needed, and conveniently there is one from Rational ;-) named Rational ClearQuest.

If we return to RUP and for example want to get information on an artifact it may look like as in Figure 23. There you can get information on how the UML-representation looks like as well as who (worker) actually should work with the task. In this case we see that a system analyst is best suited. Lots of other information is available through the links.

Rational has a lot of products targeting the market of system development and visual modeling. Probably the most well known is Rational Rose. RUP has got so called tool mentors that give information and help using for example Rational Rose.

The buyer of RUP will be able to customize the product into his own organization[3]. For example is it possible to add menus and information to the tree-browser tailoring the product for the company’s own needs. Furthermore one can add own web pages to the view especially for the whole project or for a sub-project. And the ability to add development cases that describe the development process that has been chosen for the project.

AN INTERVIEW

For the purpose of knowing a little more about the product and how it is being used “out there” we conducted an interview with a project leader at a company here in Västerås, Kenneth Nilsson. We asked questions that would be relevant for a person who just made a first contact with the concept and the product (like ourselves).

• - Hello Kenneth, we have one first question. We look at a concept that is pretty big; it is not just one tool for a special purpose but rather a set of tools that wants to influence whole projects. Is it difficult to adopt the thinking and the actions of RUP into an organization, provided the employees are willing to give it a try, and which problems arise concerning the size of the organization? - Well, hard work and intense efforts. RUP is designed for any size of groups, but my opinion is that is easiest to adapt in a middle-sizes organization. If the organization is big, more than a couple of hundred employees, you probably get problems with logistics and the flow of information as well as for education. In a small company with just a couple of employees you get the problem of spending to much money and efforts on carrying out the task of using the product. You may have to set aside one person on the task of integrating the product and that will be a big sacrifice for a company of just a few persons.

28

Figure 23, Information on the Use-Case Model

• - When did you start using RUP? - A couple of years ago.

• How did you work with the task of starting to use it in your projects? – First I tried a sort of sneak-tactics, I took parts of the RUP and made the team use it without stressing the fact that it was RUP that was used. After a while the team had adopted the ideas.

• - How about UML? The book “The Unified Software Process” by among others Ivar Jacobson points out that the Unified Process is an integral part of it. Do you agree? – Not completely. I mean, UP has certainly been developed along with UML, but both are not introducing completely new stuff, but gathers rather existing experiences of what is good design and practices. It is not completely necessary to use UML as standard; other standards may well be fine especially if the organization already has the knowledge of using it. RUP as a product is tightly integrated with UML though.

• - Is UP and RUP a necessary part of the software organization? – Issues that have been neglected during the years are mainly control of projects, assurance of quality, handling of requirements and the issue of making changes the right way. RUP is not going to solve all problems but will certainly help. It is for example important to go back all the way to analysis when a problem occurs, you cannot just change the implementation at once. If you do the overview will soon be rendered impossible. If you use RUP you most certainly will also use Rational Rose for documentation of use-cases and class diagrams. If you change the code but not the design you get inconsistencies. Furthermore the metrics have been neglected during the years, estimations of how much time activities will take have been bad and provide an uncertainty into the project. A major issue a lot of books on the subject claims for true are the historical aspect of how work is done. A long time ago people implemented software, coding, coding, coding, but that was not a good idea when problems arose. Later on the need for design penetrated the thinking of software teams, but today modern organizations stress the analysis part.

• - Any common issues that is important to think about when working with projects and especially the processes? Well, one should keep the work to the domain where one has the experience. Don’t do systems for a banking system when you are an expert on rolling mills for example. And if you design system for a domain try to reuse as much if implementation and experiences as possible. I have been around where we designed the automation systems for three different rolling mills and actually designed three different systems. Not good.

29

• - Thank you Kenneth. The Rational Unified Process if commonly illustrated through the circle diagram shown to the left in Figure 24. This figure quite nicely summons up the whole thinking and the summary we have tried to bring forward in this report. The circle is closed; iterations and phases succeed each other all the way from evaluation to testing. We feel that this picture is quite important and if one can look at it and feel conformable about what they stand for one has cone quite a long way of understanding the process.

Figure 24, The iteration cycle and the key concepts of RUP

A nice summary figure over the key concepts of RUP is to the right in Figure 24. Here you can see a lot of the concepts introduced in the text interconnected for easier understanding.

SUMMARY

The Unified Process is a pretty complicated concept since it covers the whole aspect form idea to product, management, and so on. This complexity makes it hard to integrate the process the first time its used, and it also includes a lot of tools that has to be used, which takes time to learn. But if learned the UP is a powerful process to use in development, and its roots also come from a long time back so the concept has been tested over and over again. This complexity is also the reason we think it's a very diffuse area to write a paper about; we had some problems understanding the structure of the UP (we are still not sure we understand it correctly☺). But hopefully the readers can get an idea of what the UP is about by reading this paper.

REFERENCES

[1] www.rational.com [2] Jacobson, Booch, Rumbaugh. 1999. The Unified Software Development Process, Reading,

Massachusetts: Addison Wesley Longman Inc. [3] Rational Unified Process White Paper available at [1]. [4] Interview with Kenneth Nilsson, Benima Data, Västerås, 16/5 2000.

30

QUESTIONS TO ANSWER

1. There are many terms introduced in the Unified Process. Please describe what an artifact is.

2. Shortly name and describe the main phases in the process.

3. What is the difference between core workflow and iteration workflow?

4. What does use-case driven process mean? (Extra question if we’re supposed to answer four questions)