Each process component
is associated with a particular model.
The Rational Objectory Process - A UML-based Software Engineering Process
Presenter: Sten Jacobson
Rational Software Scandinavia
AB
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.
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.
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 has a specific purpose.
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.
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.
At the end of the construction phase, you decide if the
software, the sites, the users are all ready to go operational.
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 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.
Requirement capture, Analysis and Design, Implementation and Test
and three supporting components:
Management, Deployment, and Environment
Each process component
is associated with a particular model.
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.
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:
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.
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".
This section explains the core ideas behind the Objectory
process, its most salient features.
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
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.
Use cases have other roles as well:
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.
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:
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.
Components come from different avenues:
Objectory supports component-based development in several ways.
The process elements that are likely to be modified, customized,
added or suppressed include: artifacts, activities, workflows, workers
and process components.
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.
       
|
| ISCN LTD, ISCN GesmbH, Schieszstattgasse 4/24, 8010 Graz, and Coordination Office, Florence House, 1 Florence Villas, Bray, Ireland, office@iscn.at, office@iscn.com, office@iscn.ie, Editing Done: 19.7.2002 |