How to Reap the Business Benefit from SPI
European Software Process Improvement
SPI and Object Orientation
Category Index
Rated Newspaper Supported by EU Project  

The Rational Objectory Process - A UML-based Software Engineering Process

Presenter: Sten Jacobson
Rational Software Scandinavia AB


This paper presents an overview of the Rational Objectory Process. The Rational Objectory Process is a full lifecycle software engineering process bringing Unified Modeling Language (UML) best practices to the fingertips of each software developer. Objectory is a controlled iterative process, with strong focus on architecture. It is a use-case driven, object-oriented process, using the UML as a notation for its models. Objectory can be configured to fit a wide range of projects.

Introduction—What is Objectory?

The Rational Objectory Process is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software, meeting the needs of its end-users, within a predictable schedule and budget. The Objectory process captures many of the best practices in modern software development in a form that is tailorable for a wide range of projects and organizations.

Objectory is an iterative process. Given today’s sophisticated software systems, it is not possible to sequentially first define the entire problem, design the entire solution, build the software and then test the product at the end. An iterative approach is required that allows an increasing understanding of the problem through successive refinements, and to incrementally grow an effective solution over multiple iterations. An iterative approach gives better flexibility in accommodating new requirements or tactical changes in business objectives, and allows the project to identify and resolve risks earlier. [1, 2]

Objectory is a controlled process. This iterative approach is only possible however through very careful requirements management and change control, to ensure at every point in time a common understanding of the expected set of functionality and the expected level of quality, and to allow a better control of the associated costs and schedules.

Objectory activities create and maintain models. Rather than focusing on the production of large amount of paper documents, Objectory emphasizes the development and maintenance of models—semantically rich representations of the software system under development. [3, 7, 8]

Objectory focuses on early development and baselining of a robust software architecture, which facilitates parallel development, minimizes rework, increases reusability and maintainability. This architecture is used to plan and manage the development around the use of software components.

Objectory development activities are driven by use cases. The notions of use case and scenarios drive the process flow from requirements capture through testing, and provides coherent and traceable threads through both the development and the delivered system. [7]

Objectory supports object-oriented techniques. Several of the models are object-oriented models, based on the concepts of objects, classes and associations between them. These models, like many other technical artifacts, use the Unified Modeling Language (UML) as the common notation. [4]

Objectory supports component-based software development. Components are non trivial modules, subsystems that fulfill a clear function, and that can be assembled in a well-defined architecture, either ad hoc, or some component infrastructure such as the Internet, CORBA, COM, for which an industry of reusable components is emerging. [5]

Objectory is a configurable process. No single process is suitable for all software development. Objectory fits small development teams as well as large development organization. Objectory is founded on a simple and clear process architecture that provides commonality across a family of processes and yet can be varied to accommodate different situations. It contains guidance on how to configure the process to suit the needs of a given organization.

Objectory encourages objective on-going quality control. Quality assessment is built into the process, in all activities, involving all participants, using objective measurements and criteria, and not treated as an afterthought or a separate activity performed by a separate group.

Objectory is supported by tools, which automate large parts of the process. They are used to create and maintain the various artifacts—models in particular—of the software engineering process: visual modeling, programming, testing, etc. They are invaluable in supporting all the bookkeeping associated with the change management as well as the configuration management that accompanies each iteration.

Process Overview

Two Dimensions

The Rational Objectory Process can be described in two dimensions: The first dimension represents the dynamic aspect of the process, as it is enacted, and is expressed in terms of cycles, phases, iterations and milestones.

The second dimension is represents the static aspect of the process: how it is described in terms of process components, activities, workflows, artifacts, and workers.

Phases and Iterations

This is the dynamic organization of the process along time.

The software lifecycle is broken into cycles, each cycle working on a new generation of the product. The Objectory process divides one development cycle in four consecutive phases [10]

Each phase is concluded with a well-defined milestone—a point in time at which certain critical decisions must be made, and therefore key goals must have been achieved [2].

Each phase has a specific purpose.

Inception Phase

During the inception phase, you establish the business case for the system and delimit the project scope. To accomplish this you must identify all external entities with which the system will interact (actors) and define the nature of this interaction at a high-level. This involves identifying all use cases and describing a few significant ones. The business case includes success criteria, risk assessment, and estimate of the resources needed, and a phase plan showing dates of major milestones.

At the end of the inception phase, you examine the lifecycle objectives of the project and decide whether or not to proceed with the development.

Elaboration Phase

The goals of the elaboration phase are to analyze the problem domain, establish a sound architectural foundation, develop the project plan and eliminate the highest risk elements of the project. Architectural decisions must be made with an understanding of the whole system. This implies that you describe most of the use cases and take into account some of the constraints: non functional requirements. To verify the architecture, you implement a system that demonstrate the architectural choices and executes significant use cases.

At the end of the elaboration phase, you examine the detailed system objectives and scope, the choice of an architecture, and the resolution of major risks.

Construction phase

During the construction phase, you iteratively and incrementally develop a complete product that is ready to transition to its user community. This implies describing the remaining use case, fleshing out the design, and completing the implementation and test of the software.

At the end of the construction phase, you decide if the software, the sites, the users are all ready to go operational.

Transition phase

During the transition phase you transition the software to the user community. Once the product has been put in the hand of the end users, issues often arise that require additional development to adjust the system, correct some undetected problems, or finish some of the features that may have been postponed. This phase typically starts with a "beta release" of the systems.

At the end of the transition phase you decide whether the lifecycle objectives have been met, and possibly if you should start another development cycle. This is also a point where you wrap up some of the lessons learned on this project to improve the process.


Each phase in the Objectory process can be further broken down into iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system [10].

Each iteration goes through all aspects of software development, i.e., all process components, although with a different emphasis on each process component depending on the phase. This is depicted in the diagram in the beginning of section 'Process Overview'. The main consequence of this iterative approach is that the artifacts we described earlier grow and mature as time flows.

Process Components

The Objectory process is composed of 7 process components, which are described in terms of activities, workflows, workers and artifacts. There are four engineering process components:

Requirement capture, Analysis and Design, Implementation and Test

and three supporting components:

Management, Deployment, and Environment

Process Components and Models

Each engineering process component describes how to create and maintain a model. Objectory has the following model: use-case model, design model, implementation model, and test model. The next figure shows the relationship of the process components and models.

Each process component is associated with a particular model.

Requirements Capture

The goal of the Requirements Capture process component is to describe what the system should do and allows the developers and the customer to agree on that description. To achieve this, we delimit the system, define its surroundings and the behavior it is supposed to perform. Customers and potential users are important sources of information as well as any system requirements that may exist.

Requirements capture results in a use-case model and some supplementary requirements. The use-case model is essential for both the customer, who needs the model to validate that the system will become what he expected, and for the developers, who need the model to get a better understanding of the requirements on the system.

The use-case model is relevant to all people involved in the project.

The use-case model consists of actors and use cases. Actors represent the users, and any other system that may interact with the system being developed. Actors help delimit the system and give you a clearer picture of what it is supposed to do.

Use cases represent the behavior of the system. Because use cases are developed according to the actor's needs, the system is more likely to be relevant to the users. The following figure shows an example of a use-case model for a recycling-machine system.

An example of a use-case model with actors and use cases.

Each use case is described in detail. The use-case description shows how the system interacts step by step with the actors and what the system does.

The use cases function as a unifying thread throughout the system's development cycle. The same use-case model is used during requirements capture, analysis & design, and test.

The workflow in requirements capture, shown in terms of workers and their activities. The arrows indicate a logical order between the activities.

Analysis & Design

The goal of the Analysis & Design process component is to show how the system will be realized in the implementation phase. You want to build a system that:

The use-case model is the basis for design, along with the supplementary specifications.

Analysis & Design results in a design model that serves as an abstraction of the source code; that is, the design model acts as a 'blueprint' of how the source code is structured and written. Design also results in 'inside-view' descriptions of the use cases, or use-case realizations, which describe how the use cases are realized in terms of the participating objects/classes.

The design model consists of design classes structured into design packages; it also contains descriptions of how objects of these design classes collaborate to perform use cases. The next figure shows part of a sample design model for the recycling-machine system in the use-case model shown in the previous figure.

Part of a design model with communicating design classes, and package group design classes.

The design activities are centered around the notion of architecture. The production and validation of this architecture is the main focus of early design iterations. Architecture is represented by a number of architectural views [9]. These views capture the major structural design decisions. In essence architectural views are abstractions or simplifications of the entire design, in which important characteristics are made more visible by leaving details aside. The architecture is an important vehicle not only for developing a good design model, but also for increasing the quality of any model built during system development.

The workflow in analysis & design, described in terms of workers and their activities. The arrows indicate a logical flow between the activities.


The system is realized through implementation producing the sources (source-code files, header files, makefiles, and so on) that will result in an executable system. The sources are described in an implementation model that consists of modules structured into implementation packages. The design model is the basis for implementation.

Implementation includes testing the separate classes and/or packages, but not testing that the packages/classes work together. That is described in the next process component, "Test".

The workflow in implementation, shown in terms of workers and their activities. The arrows indicate a logical order between the activities.


Test verifies the entire system. You first test each use case separately to verify that its participating classes work together correctly. Then you test (certain aspects of) the system as a whole with use-case descriptions as input to this test. At the end of test, the system can be delivered.

The workflow in test, shown in terms of workers and their activities. The arrows indicate a logical order between the activities.

Features of Objectory

This section explains the core ideas behind the Objectory process, its most salient features.

Object Technology

Many projects today employ object-oriented programming languages to obtain reusable, change-tolerant, and stable systems. To obtain these benefits, it is even more important to use object technology in design. Objectory produces an object-oriented design model that is the basis for implementation [3, 7, 8].

An object-oriented model aims at reflecting the world we experience in reality. Thus, the objects themselves often correspond to phenomena in the real world that the system is to handle. An object can be an invoice in a business system or an employee in a payroll system, for example.

A model correctly designed using object technology is

Use-Case-Driven Development

It is often difficult to tell from a traditional object-oriented system model how a system does what it is supposed to do. We believe this difficulty stems from the lack of a "red thread" through the system when it performs certain tasks. In Objectory, use cases are that thread because they define the behavior performed by a system. Use cases are not part of "traditional" object orientation, but their importance has become more and more apparent. Other object-oriented methods provide use cases but use different names for them, scenarios, threads.

Objectory is a ìuse-case driven approach.î What we mean by that is the use cases defined for a system are the basis for the entire development process. Use cases play a role in each of the four engineering process components: requirements analysis, design, implementation, and test.

Notice that a use case has several descriptions. For each use case there is a use case description, which describes what the system should do from the userís point of view, and there is a use case design, which describes how the use case is performed in terms of interacting objects.

Use cases have other roles as well:

Controlled Iterative Development

The Objectory iterative approach is generally superior to a linear or waterfall approach for many reasons:

It lets you take into account changing requirements. The sad truth is that requirements will normally change. Requirements change and requirements "creep" have always been a primary source of project trouble, leading to late delivery, missed schedules, unsatisfied customers, and frustrated developers.

Integration is not one "big bang" at the end—elements are integrated progressively. Actually the Objectory iterative approach is almost continuous integration. What used to be a big, uncertain and painful time taking up to 40% of the total effort at the end of a project, is now broken down into 6 to 9 smaller integrations that begin with far fewer elements to integrate.

It lets you mitigate risks earlier because integration is generally the only time risks are discovered or addressed. As you unroll the early iteration you go through all process components, exercising many aspects of the project: tools, off-the-shelf software, people skills, and so on. Perceived risks will prove to not be risks, and new, unsuspected risks will show up.

It provides management with a way to do tactical changes to the product; for example, to compete with existing products. You can decide to release a product with reduced functionality earlier to counter a move by a competitor, or you can adopt another vendor for a given technology.

It facilitates reuse, since it is easier to identify common parts as they are partially designed or implemented, instead of identifying all commonality up front. Identifying and developing reusable parts is hard. Design reviews in early iterations allow architects to identify unsuspected potential reuse and develop and mature common code in subsequent iterations.

It results in a more robust architecture because you are correcting errors over several iterations. Flaws are detected even in the early iterations as the product moves beyond inception. Performance bottlenecks are discovered at a time when they can still be addressed, not on being discovered on the eve of delivery.

Developers can learn along the way, and the various competencies and specialties are more fully employed during the whole life cycle. Testers start testing early, technical writers write early, and so on. In non-iterative development the same people would be waiting around to begin their work, making plans and honing their skills. Training needs or the need for additional (perhaps external) help is spotted early on, during assessment reviews.

The process itself can be improved, refined along the way. The assessment at the end of an iteration not only look at the status of the project from a product/schedule perspective but also analyze what should be changed in the organization and in the process itself to perform better in the next iteration.

Project managers often resist the iterative approach, seeing it as a kind of endless ìhacking.î In Objectory, the interactive approach is very controlled; iterations are planned, in number, duration, and objective. The tasks and responsibilities of the participants are defined. Objective measures of progress are captured. Some rework does take place from one iteration to the next, but this, too, is carefully controlled.

Requirements Management

The two key elements behind a controlled iterative process are requirements management and change control. Requirements management is a systematic approach to eliciting, organizing, communicating and managing the changing requirements of a software intensive system or application.

The benefits of effective requirements management include:

Focused more closely towards the needs of the development organization, change control is a systematic approach to managing changes in requirements, design, implementation, but also covers the important activities of keeping track of defects, misunderstandings, project commitments, and being able to associate these with specific artifacts and releases.

A Strong Emphasis on Architecture

Use cases drive the Objectory process end-to-end over the whole lifecycle, but the design activities are centered around the notion of architecture—system architecture, or for software-intensive systems, software architecture. The main focus of the early iterations of the process—mostly in the elaboration phase—is to produce and validate a software architecture, which in the initial development cycle takes the form of an executable architectural prototype that gradually evolves to become the final system in later iterations [9].

The Objectory process provides a methodical, systematic way to design, develop and validate an architecture. It offers templates for architectural description around the concepts of multiple architectural views, and the capture of architectural style, design rules, and constraints. The design process component contains specific activities aimed at identifying architectural constraints and, architecturally-significant elements, as well as guidelines on how to make architectural choices. The management process shows how the planning of the early iterations takes into account the design of an architecture and the resolution of the major technical risks.

Architecture is important for several reasons:

It lets you gain and retain intellectual control over the project, to manage its complexity, and to maintain system integrity.

A complex system is more than the sum of its parts, more that a succession of small independent tactical decisions. It must have some unifying coherent structure to organize those parts systematically, and provide precise rules on how to grow the system without having its complexity explode beyond human understanding.

The architecture establishes the means for improved communication and understanding throughout the project by establishing a common set of references, a common vocabulary with which to discuss design issues.

It is an effective basis for large-scale reuse.

By clearly articulating the major components and the critical interfaces between them, an architecture lets you reason about reuse, both internal reuse—the identification of common parts—and external reuse—the incorporation of ready made, off-the-shelf components. But it also allows reuse on a larger scale: the reuse of the architecture itself in the context of a line of products that addresses different functionality in a common domain.

It provides a basis for project management.

Planning and staffing are organized along the lines of major components. Fundamental structural decisions are taken by a small, cohesive architecture team; they are not distributed. Development is partitioned across a set of small teams each responsible for one or several parts of the system.

Component-Based Development

A software component can be defined as a non trivial piece of software, a module, a package or a subsystem, that fulfills a clear function, has a clear boundary and can be integrated in a well-defined architecture. It is the physical realization of an abstraction in your design.

Components come from different avenues:

The first point exploits the old concepts of modularity, encapsulation, bringing the concepts underlying object-oriented technology a set further. The last two points shift software development from programming software (a line at time) to composing software (by assembling components).

Objectory supports component-based development in several ways.

Process Configurability

The Rational Objectory Process is general and complete enough to be used "as is" by some software development organizations. However in many circumstances, this software engineering process will need to be modified, adjusted, tailored to accommodate the specific characteristics, constraints and history of the adopting organization. In particular a process should not be followed blindly, generating useless work, producing artifacts that are of little added value; it must be made as lean as possible and still be able to fulfill its mission to produce rapidly and predictably high quality software.

The process elements that are likely to be modified, customized, added or suppressed include: artifacts, activities, workflows, workers and process components.

The Origin of Objectory

Objectory has many different sources. The more essential of these are: The Objectory Process is supported by Rational's leading methodologists, including Grady Booch, Ivar Jacobson, Philippe Kruchten, Dean Leffingwell, Walker Royce and Jim Rumbaugh.

Objectory is sold as a product by Rational Software Corp. It is available in on-line, browsable form and in printed book from. It is supported by training courses and other services.


  1. Barry W. Boehm, "A Spiral Model of Software Development and Enhancement," Computer, May 1988, IEEE, pp.61-72
  2. Barry W. Boehm, "Anchoring the Software Process," IEEE Software, 13, 4, July 1996, pp. 73-82.
  3. Grady Booch, Object Solutions, Addison-Wesley, 1995.
  4. Grady Booch, Ivar Jacobson, and James Rumbaugh, Unified Modeling Language, White paper, Rational Software Corp., 1996.
  5. Alan W. Brown (ed.), Component-Based Software Engineering, IEEE Computer Society, Los Alamitos,CA, 1996, pp.140.
  6. Michael T. Devlin, and Walker E. Royce, Improving Software Economics in the Aerospace and Defense Industry, Technical paper TP-46, Santa Clara, CA, Rational Software Corp., 1995
  7. Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Object-Oriented Software Engineering—A Use Case Driven Approach, Wokingham, England, Addison-Wesley, 1992, 582p.
  8. Ivar Jacobson, M. Griss, and P. Jonsson, Software Reuse—Architecture, Process and Organization for Business Success, ACM Press, New York, NY, 1997.
  9. Philippe Kruchten, "The 4+1 View Model of Architecture," IEEE Software, 12 (6), November 1995, IEEE, pp.42-50.
  10. Philippe Kruchten & Walker Royce, "A Rational Development Process," CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.
Cf. also

Partners in EuroSPI

ISCN LTD, ISCN GesmbH, Schieszstattgasse 4/24, 8010 Graz, and Coordination Office, Florence House, 1 Florence Villas, Bray, Ireland,,,, Editing Done: 19.7.2002