Introducing RUP


The RUP is a commercial method and is sold as an online resource on CD-ROM, although numerous books and articles are available on the subject.

It was developed as a complementary methodology to the Unified Modeling Language (UML) and is a use-case-driven, architecture-centric, iterative development process for producing object-oriented software. The process is the result of the combination of many software engineering best practices as well as the acquisition by Rational of several software engineering methods. Its lineage goes back to the Objectory process, created in 1987 by methodology guru Ivar Jacobson.

Chapter 5, Modeling Software, examines the Unified Modeling Language.


RUP is actually a process framework rather than a methodology. It defines an extensive selection of disciplines, artifacts, activities, and roles each of which represents industry best practice for the development of object-oriented software. The best practices that underpin the RUP framework are as follows:

  • Develop software iteratively.

  • Manage requirements.

  • Use component-based architectures.

  • Visually model software.

  • Continuously verify software quality.

  • Control changes to software.

Due to the comprehensive nature of the framework, the process is often assumed to be high-ceremony and heavyweight. While RUP does emphasize the importance of certain key artifacts and activities that are central to the process, this assumption is largely incorrect. Instead, RUP encourages the developer to tailor the process to the needs of his or her specific project by selecting from the long list of elements RUP provides for just about every conceivable project type. By tailoring the process, RUP can take on the agility of a lightweight methodology if the needs of the project dictate. However, the reliance of the process on artifacts such as use cases and design models means it is unable to slim down to the feather-light weights of methods such as XP, which we cover later.

A second common misconception with the process is that it is based upon predictive methods rather than adaptive methods. Again, this assumption is incorrect: RUP promotes the best practice of developing software iteratively. Many adopters of the RUP have been guilty of overlaying the waterfall lifecycle model on top of the process framework, thereby turning it into a predictive method. This is counter to the best practices of the process and certainly goes against the intent of its creators.

To understand how RUP is applied on projects, over the next sections we look at two of the key drivers for the process: use cases and timeboxed iterative development. We also examine the core elements of the framework.

A Use-Case-Driven Process

We know that a successful system meets the needs of its end users. To achieve this goal, IT staff must work closely with the business domain experts to elicit the requirements that will ultimately drive the development effort. The interaction between business representatives and members from the project team is a critical success factor for ensuring all relevant requirements are both understood and captured correctly. Achieving this objective is a challenge, since both parties approach the engagement with very different mindsets and viewpoints. The end users focus on business concerns, while the IT staff likely thinks in terms of system design and architecture.

The question becomes, "How do we capture requirements in a form that is understandable to both the business domain experts and the IT-focused software engineers?" One of the most successful methods to date of achieving this is to develop a set of use cases.

Use cases describe what the system should do from the end user's perspective. They are text-based documents, as opposed to diagrams, that step through the flow of a set of closely related business scenarios. Each use case represents a functional slice of the system and describes how actors interact with the system in order to execute the use case.

An actor is defined as something external to the system, usually a person, who interacts with the system. The use case itself is a series of actions a system performs for the actor.

Here is an example of the structure of a typical use case:

  • Use-case name: A short but descriptive title based on the goal of the use case

  • Goal: A longer description of the goal

  • Category: Several categories are possible but are likely to be one of primary, secondary, or summary

  • Preconditions: Conditions that must exist before starting

  • Postconditions: Conditions present upon the successful conclusion of the use case

  • Actors: A list of all the participating actors

  • Trigger: The event that starts the execution of the use case

  • Flow of events: A series of numbered steps that walks through each of the flows. You can optionally include activity diagrams for each flow:

    - Main flow

    - Alternative flows

    - Exception flows

  • Extensions: Points at which branching to other use cases occurs within the flow of events

  • Special requirements: Any additional processing requirements not covered by the different flows

  • Performance goals: Measurable performance criteria the system must meet when executing the main flow

  • Outstanding issues: Any unresolved issues that are preventing the completion of the use case

Templates for use cases vary, with publications on the subject each presenting slight variations on a common theme. The structure of the use case shown represents the elements commonly found in use-case templates. You may wish to tailor this template to suit the needs of your own project.

The most important part of a use-case document is the flow of events section:. This describes the interplay between actors and system for a given scenario in a concise, natural language form.

Note

A scenario is a flow of events within the use case. Very often, a use case comprises additional alternative flows to the main flow. These secondary flows typically cover exception conditions or slight deviations from the main scenario.


Let's look at an example of a use case that details the flow of events for a customer who enters the office of a travel company to reserve seats on a suitable flight. Table 3-1 shows an example of the complete use case.

Table 3-1. Use Case Example

Name

Customer flight reservation.

Goal

To allow a customer to reserve seats on an airline flight.

Category

Primary.

Preconditions

The Customer is in the Travel Agency office meeting with the Travel Agent. The Flight Reservation system is online, and flights are available that meet the Customer's travel needs.

Postconditions

The Customer has reserved a seat(s) that meets her travel requirements and is ready either to pay for the flight or to place a deposit for the reservation.

Actors

Customer

 

Travel Agent

Trigger

The Customer requests to make a flight booking.

Main flow

1. The use case starts when the Customer requests to make a flight reservation.

 

2. The Travel Agent asks the customer for the date of travel, the destinations, and the number of people traveling.

 

3. The Travel Agent enters the Customer's details into the Flight Reservation system.

 

4. The Flight Reservation system lists the available flights that match the Customer's travel requirements and displays the airfare for each option.

 

5. The Customer selects a flight from the list and requests to make a booking.

 

6. The Travel Agent asks the customer for name, address, and contact telephone number.

 

7. The Travel Agent enters the Customer's details into the Flight Reservation system and reserves seats on the flight.

 

8. The Flight Reservation system prints out the details of the booking.

 

9. The Travel Agent asks the Customer how she wishes to pay, at which point the use case ends.

Extensions

5a. No flights match the Customer's criteria.

 

8a The system cannot print the flight details.

 

9a. Handle Customer payment (Use Case: Customer Pays Invoice).

Special requirements

No special requirements.

Performance goals

The Flight Reservation system must display the list of available flights within 10 seconds.

Outstanding issues

Need to identify the exact details and format of the booking information printed out by the Flight Reservation system.


The plain language of use cases, which is both business- and technology-neutral, makes them ideal for communicating system behavior to both end users and developers. Use cases are important in RUP because they provide a common thread through many activities, particularly in the area of linking requirements to design. They also serve to focus the design, implementation, and testing efforts around a central set of requirements, which form the core of the system.

Use cases are organized by producing a use-case model. A use-case model is a UML diagram that graphically illustrates how the different use cases and actors interact. Models are useful for gaining an understanding of the relationships that exist between each use case and actor. However, the true value of use cases is in the text of the use case itself, not the diagram in the model.

Ivar Jacobson initially proposed the concept of use cases. As Jacobson's Objectory is one of the foundation methodologies on which the RUP framework is built, it is not surprising that use cases are one of the driving forces of the process.

Although they are an important part of the process, use cases are not confined to object-oriented development and have enjoyed widespread acceptance in all manner of projects. They are an excellent technique for capturing and understanding customer requirements and are worth considering for inclusion in any methodology.

We next examine how the RUP framework centers on the use of iterations throughout the project lifecycle.

Iterative Development with RUP

The process prescribes an iterative approach to development with timeboxed iterations. Here, all iterations occur over a fixed duration but have a variable scope.

A RUP iteration focuses on a subset of the system's use cases. Within a typical iteration, the selected use cases are elaborated and a design is evolved followed by implementation and testing. The objective of each iteration is a functioning system. Should it appear that this objective will not be achieved, then the scope is reduced in preference to extending the timeboxed duration of the iteration or bringing more people on to the project.

The exact content of an iteration is dependent upon the particular phase of RUP within which the planned iteration is being conducted. Let's examine the different phases of a RUP project cycle.

Phases of the Process

RUP Phases

  • Inception

  • Elaboration

  • Construction

  • Transition


Conventional waterfall-based processes are broken down into phases according to specific software engineering activities, with phase names denoting the associated activity. We therefore commonly have requirements, analysis and design, implementation, and testing. Only a single type of activity is undertaken in each of these phases. For example, during the requirements phase, only work relating to the gathering, analysis, and documenting of requirements is performed. Absolutely no design, coding, or testing work is undertaken as part of this early phase.

RUP projects are also divided into the four discrete phases. These are inception, elaboration, construction, and transition. Unlike in the waterfall model, these phases are not aligned by activity but instead demark the achievement of a major project milestone. Phases within the process include a number of iterations, with each iteration serving to advance the project toward the phase milestone. As an iteration is a complete mini-waterfall project, we can expect to see the general activities of requirements, analysis and design, implementation, and testing being undertaken in each phase.

A common failing in implementing the RUP is to mistakenly associate these four phases with the four phases of the classic waterfall lifecycle. This is a fact Philippe Kruchten, one of the creators of RUP, went to great pains to point out with his fellow authors in the article, How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering [Larman, 2002].

Please note:

  • Inception does not equal requirements

  • Elaboration does not equal design

  • Construction does not equal coding

  • Transition does not equal testing

Here are the four phases of a RUP project and a brief description of the work undertaken in each phase:

Inception.

During inception, a preliminary iteration focuses on establishing a business case for the system. A small but critical set of primary use cases are identified, and based on these, the scope of the project is estimated, architectural options explored, and key risks assessed. Findings from this phase assist in determining if the project is viable and if it should continue on to the elaboration phase.

Elaboration.

Having made the decision to continue with the project, the elaboration phase shifts the focus of the project to iteratively constructing the architecture for the system. This exercise is conducted in parallel with a detailed investigation of the core requirements.

Iterations within the elaboration phase focus on refining these core requirements and constructing the architecture to the point where it can be demonstrated. Both requirements and the system architecture may undergo significant change during this phase because of feedback between the two tasks.

The output from this phase is a stable architecture on which the bulk of the functionality of the system can be built during the construction phase.

Construction.

With a stable architecture in place and most of the primary requirements defined, the construction phase looks to build the remaining functionality of the system on this stable platform. The objective of the iterations for this phase is a system that is ready for deployment into a beta testing environment.

Transition.

Iterations in the fourth and final phase focus on producing a fully tested system, with all outstanding issues resolved, that is ready for final deployment.

Running throughout each of these phases are the different disciplines of a RUP project.

Disciplines

A discipline represents an area of work. Disciplines are undertaken in each iteration, although the degree to which each discipline is practiced depends on the current project phase. There are nine different disciplines:

Business modeling.

Seeks to describe an organization's core business processes in order to assist in identifying the important requirements for the system targeted for development.

Requirements management.

Involves the gathering, structuring, and documenting of all requirements.

Analysis and design.

Involves the conception and demonstration of an architecture for the system that is capable of supporting the requirements of the system.

Implementation.

Writing, testing, building, and debugging the source code for the system.

Test.

Performing quality-assurance tests, such as functional, performance, and system testing.

Deployment.

Undertaking all the necessary tasks to ensure the system is deliverable into the environment of the end users.

Project management.

Planning and monitoring of the project.

Configuration and change management.

Associated with all tasks that relate to change control, versioning, and release management.

Environment.

Tailoring the process to a specific project and selecting and supporting the project infrastructure and associated development tools.

The amount of effort required in each discipline varies as the project traverses through the four different phases over time. Iterations in inception and elaboration phases will be heavy on the business modeling and requirements management disciplines. Later in the project, during the transition phase, effort in these disciplines will have trailed off but may still play a minor part in later iterations.

The Elements of RUP

RUP Elements

  • Roles: Who?

  • Activities: How?

  • Artifacts: What?

  • Workflows: When?


The RUP framework provides all the elements necessary for building a comprehensive project around the different disciplines. For each discipline, RUP defines a set of roles, activities, artifacts, and workflows that represent the core elements of the lifecycle model. Each of these elements is an answer to the questions of who, how, what, and when.

Artifacts: The What

An artifact is a work product used to capture and convey project-related information. Artifacts can be documents, models, model elements, source code, or executables. Complete artifact sets are defined that align to each discipline; for example, artifacts from the analysis and design discipline include a software architecture document (SAD) and a design model.

Activities: The How

Producing an artifact requires undertaking an activity. The RUP views an activity as a unit of work carried out by a member of the team with a specific role. Examples of activities for the analysis and design discipline include those of architectural analysis and database design. Artifacts resulting from these two activities include a software architecture document and a data model respectively.

Roles: The Who

RUP allocates responsibilities to members of the team by handing out roles. Roles are associated with a set of performed activities and owned artifacts. From the activities and artifacts mentioned so far, the software architect is responsible for undertaking the architectural analysis activity and producing the software architecture document artifact, while the database designer produces a database model as an artifact resulting from the database design activity.

Team members are not assigned a single role but instead take on a range of roles as and when the project dictates. On smaller projects, a member of the team may hold several roles if he is undertaking a range of activities, whereas large projects may require a single person to be dedicated to a particular role.

Workflow: The When

To work with the different artifacts, activities, and roles, we need more information than merely a list of each element. It is necessary to understand how each different element interacts as part of the process. This is the purpose of workflows.

A workflow is represented in RUP as a modified activity diagram illustrating how a particular set of activities is organized. Workflows equate to the disciplines we have already covered. In fact, a discipline is a type of high-level workflow, as disciplines represent a logical grouping of a set of artifacts, activities, and roles. A discipline is therefore one type of workflow. A second type of workflow is the workflow detail, which breaks disciplines down into finer levels of granularity.

Within RUP, we therefore have phases, iterations, disciplines, roles, activities, and artifacts. The question is how you go about combining all of these elements into a coherent project plan.

Planning

Planning is a key part of RUP, which encourages the production of two types of plan: a coarse-grained phase plan and a series of detailed iteration plans.

The phase plan is a single plan that spans the duration of the entire project from inception to transition. This high-level plan defines the anticipated dates for the major project milestones, the required project resources, and scheduled dates for each of the planned iterations.

The phase plan is created early in the project during the inception phase. Detailed planning is reserved for the iteration plan, which, like traditional management plans, allocates tasks to individuals and specifies minor milestone dates and project review points. Milestone dates within the iteration plan are made with an expectation of accuracy, as the estimates are made for near-term deadlines as opposed to the long-term forecasts of the phase plan. Toward the end of the iteration, the plan is concluded and work on the plan for the next iteration commences. Thus, in RUP it is common to have two iteration plans: one plan for tracking progress to schedule in the current iteration and a second plan that is under construction for the upcoming iteration.

Two of the most frequently asked questions regarding planning for iterative processes relate to how iterations should be structured throughout the project and what should be the length of an individual iteration.

For structuring the iterations within the project, Philippe Kruchten gives some guidance in an article on planning iterative projects [Kruchten, 2002]. For very simple projects, Kruchten suggests a single iteration for each of the four phases:

  • Inception: A single iteration to produce a user-interface prototype or mock up

  • Elaboration: One iteration to build a stable architectural prototype

  • Construction: One iteration to advance the software to the beta release stage

  • Transition: A last iteration to complete the final system

Where a large project with many unknowns in terms of both problem domain and technology is under development, Kruchten advises the following structure between the phases:

  • Inception: Two iterations to enable suitable prototyping activities

  • Elaboration: Three iterations to explore different solutions and technical options

  • Construction: Three iterations, or as many are required, to build in all the called-for functionality

  • Transition: Two iterations to incorporate operational feedback

The length of a timebox for a single iteration is governed by the size of the project team. Extremely large projects with hundreds of people involved require careful coordination in order to maintain momentum for the project. This coordination effort soaks up time and tends to lead to longer iterations. Smaller teams can work to iterations with shorter durations.

Ideally, iterations should be short and focused, running to weeks rather than months. Iterations of two to five weeks work well if the team size allows it. Where longer iterations are unavoidable, then consider setting minor milestones within the timeframe of the iteration. This helps keep the team focused on delivery and prevents risks from creeping back into the project. These minor milestones also help in tracking longer iteration plans.

Supporting Enterprise Projects

Enterprise J2EE developments and RUP fit well together. The way in which enterprise projects are conducted can vary greatly based on both the customer and the development team involved. Thanks to the extensive range of elements RUP provides, the process can tailor to suit most situations.

The size and scope of enterprise developments varies immensely, ranging from teams with only a handful of developers to projects comprised of hundreds of people spread across geographically distant locations. The RUP framework supports both extremes and can meet the needs of small, adaptive style projects while also providing the high-ceremony artifacts necessary for developments conducted on a much grander scale.

Although RUP supports a lightweight adaptive approach, this is not the nature of the majority of enterprise-level developments. Traditionally, such projects are highly contractual, requiring upfront fixed-price quotes for agreed-upon levels of functionality. This type of engagement is the forte of RUP. Placing great importance on early prototype and investigation work helps to drive out the risks involved in this type of project.

Another factor in adopting RUP is the current trend for offshore development. Regardless of whether you favor this contentious practice, it has become a part of the IT industry. The extensive range of artifacts RUP defines makes it possible to conduct large projects with distributed development teams spread across the world. Here, elements of the process provide a common technical vocabulary between teams of different cultures and backgrounds, allowing them to work effectively and collaboratively on a system.

Furthermore, practitioners of best practice processes such as RUP are also able to convey a high degree of professionalism. When organizations are selecting software vendors, an important criterion is often their adopted development methodology. Companies with development teams who demonstrate a knowledge and investment in an established lifecycle model are more likely to win business than those companies who see little value in such methods.

Disadvantages of RUP

RUP is not without its downsides. A major issue is the amount of time and effort that must be invested in knowledge and education of the process framework. The extensive nature of the framework means this investment is often considerable, as becoming expert in the use of the process requires both training and practical experience. Ensuring all team members receive sufficient upfront training before embarking on any project is an important part of developing an adaptive foundation within a company in order to facilitate rapid development methods.

If taking RUP on board is viewed as being too expensive, an alternative is to adopt the practices of a lightweight agile methodology. We look at the benefits of these methods next.

Key Points of RUP

  • Can be scaled according to project size

  • Employs best practice software engineering methods

  • Is use-case-driven and architecture-centric

  • Complements the use of UML diagrams for modeling

  • Provides a comprehensive range of artifacts, activities, and roles

  • Is suited to large-scale enterprise-level developments

  • Requires a substantial investment in training and education




    Rapid J2EE Development. An Adaptive Foundation for Enterprise Applications
    Rapid J2EEв„ў Development: An Adaptive Foundation for Enterprise Applications
    ISBN: 0131472208
    EAN: 2147483647
    Year: 2005
    Pages: 159
    Authors: Alan Monnox

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net