Building an Architectural Prototype

Figure 16-2 illustrates our second example: an iteration early in the elaboration phase. The context of this example is that the inception phase has been completed and the lifecycle objective milestone has been passed; we have an outline of the actors and use cases as well as an initial cut at a project plan. (See the iteration workflow discussed in the preceding section.)

Figure 16-2. An iteration early in the elaboration phase

graphics/16fig02.gif

Start-up: Outline the Iteration Plan, risks, and architectural objectives.

Based on the project plan outlined earlier, the Project Manager starts sketching an iteration plan for the current iteration (Artifact: Iteration Plan). Evaluation criteria for the architecture are outlined in discussions with the Architect and by considering the architectural risks to be mitigated (Artifact: Risk List). Remember that one of the goals of elaboration is to establish a robust, executable architecture; the plan for doing this must be developed in this initial elaboration iteration.

Requirements: Decide which use cases and scenarios will drive the development of the architecture.

The Software Architect continues by discussing an initial use-case view with the Project Manager to determine which use cases and scenarios should be focused on in this iteration; these use cases and scenarios will drive the development of the architecture. Note that the identification of these use cases and scenarios affects the iteration plan described in the preceding step, and the iteration plan should be updated.

Requirements: Understand this driver in detail and inspect the results.

A number of requirement specifiers describe some of the selected use cases and scenarios in detail: the higher priority, most critical, and most complex ones to be addressed in this first elaboration iteration. The System Analyst might then need to restructure the use-case model as a whole. The changes to the use-case model are then reviewed and approved (Artifacts: Use-Case Model and Supplementary Specification).

Reconsider use cases and risks.

The Software Architect revisits the use-case view, taking into consideration new use-case descriptions and possibly a new structure of the use-case model. The task now is to select the set of use cases and scenarios to be analyzed , designed, and implemented in the current iteration. Note again that the development of these use cases and scenarios sets the software architecture. The Project Manager again updates the current iteration plan accordingly (Artifact: Iteration Plan) and might reconsider risk management because new risks might have been made visible according to new information (Artifact: Risk List).

Requirements: Prototype the user interface.

Using the use cases that have already been fleshed out, a user-interface designer starts expanding them in storyboards and builds a user-interface prototype to get feedback from prospective users (Artifacts: Storyboards and User-Interface Prototype).

Analysis and Design: Find obvious classes, do initial subsystem partitioning, and look at use cases in detail.

To get a general sense of the obvious classes needed, the Software Architect considers the system requirements, the glossary, the use-case view (but no use cases), and the team's general domain knowledge to sketch the outline of the subsystems, possibly in a layered fashion. The architect also identifies the analysis mechanisms that constitute common solutions to common problems during analysis. The software architecture document is initiated (Artifact: Software Architecture Document). In parallel with this effort, a team of designers, possibly with the architect, starts finding classes or objects for this iteration's use cases or scenarios. This team also begins to allocate responsibilities to the identified classes and analysis mechanisms.

Analysis and Design: Refine and homogenize classes and identify architecturally significant ones; inspect results.

A number of designers refine the classes identified in the preceding step by allocating responsibilities to the classes and updating their relationships and attributes. It is determined in detail how the available analysis mechanisms are used by each class. Then the architect identifies a number of classes that should be considered architecturally significant and includes them in the logical view (Artifact: Software Architecture Document).

Analysis and Design: Consider the low-level package partitioning.

To analyze the service aspect of the architecture, the Software Architect organizes some of the classes into design packages and relates these packages to the subsystems. The subsystem partitioning might need to be reconsidered.

Analysis and Design: Adjust to the implementation environment, decide the design of the key scenarios, and define formal class interfaces; inspect results.

The Software Architect then refines the architecture by deriving the design mechanism needed by the analysis mechanisms identified earlier. The design mechanisms are constrained by the implementation environment, that is, the implementation mechanisms available: operating system, middleware, database, and so on. Designers instantiate these classes into objects when they describe how the selected use cases or scenarios are realized in terms of collaborating objects in interaction diagrams. This puts requirements on the employed classes and design mechanisms; the interaction diagrams previously created are refined. Given the detailed requirements that are then put on each object, the designers merge these into consistent and formal interfaces on their classes. The requirements put on each design mechanism are handled by the Software Architect, who updates the logical view accordingly. The resulting design artifacts are then reviewed.

Analysis and Design: Consider concurrency and distribution of the architecture.

The next step for the Architect is to consider the concurrency and distribution required by the system. The Software Architect studies the tasks and processes required and the physical network of processors and other devices. An important input to the architect here is the designed use cases in terms of collaborating objects in interaction diagrams: the use-case realizations (Artifact: Software Architecture Document).

Analysis and Design: Inspect the architectural design.

The architecture is reviewed.

Implementation: Consider the physical packaging of the architecture.

The Software Architect now considers the impact of the architectural design on the implementation model and defines the implementation view.

Implementation: Plan the integration.

A System Integrator studies the use cases that are to be implemented in this iteration and defines the order in which subsystems should be implemented and later integrated into an architectural prototype. The results of this planning should be reflected in the project plan (Artifact: Project Plan).

Test: Plan integration tests and system tests.

A Test Designer plans the system tests and the integration tests, selecting measurable testing goals to be used when assessing the architecture. These goals could be expressed in terms of the ability to execute a use-case scenario with a certain response time or under specified load. The Test Designer also identifies and implements test cases and test procedures (Artifact: Test Plan).

Implementation: Implement the classes and integrate.

A number of Implementers code and unit-test the classes identified in the architectural design. The implementations of the classes are physically packaged into components and subsystems in the implementation model. The Integration Testers test the implementation subsystem, and then the Implementers release the subsystems to integration.

Integrate the implemented parts .

The System Integrators incrementally integrate the subsystems into an executable architectural prototype. Each build is tested .

Test: Assess the executable architecture.

Once the whole system (as defined by the goal of this iteration) has been integrated, the System Tester tests the system. The Test Designer then analyzes the results to make sure that the testing goals have been reached. The Software Architect then assesses this result and compares it with the risk identified initially.

Assess the iteration itself.

The Project Manager compares the iteration's actual cost, schedule, and content with those of the iteration plan; determines whether rework is necessary and, if so, assigns it to future iterations; updates the Risk List (Artifact: Risk List); updates the Project Plan (Artifact: Project Plan); and prepares an outline of an iteration plan for the next iteration (Artifact: Iteration Plan). Other lessons learned in terms of productivity, process improvement, tool support, and training are also interesting to consider at this stage, and actions are defined for the next iteration.

Result

The result of this initial iteration is a first cut at the architecture. It consists of fairly well-described architectural views (the use-case view, the logical view, and the implementation view) and an executable architectural prototype.

Subsequent Iterations in Elaboration

Subsequent iterations enhance the understanding of the requirements and of the architecture. This might imply a further enhancement of the design or implementation model (that is, the realization of more use cases in priority order).



The Rational Unified Process. An Introduction
Blogosphere: Best of Blogs
ISBN: B0072U14D8
EAN: 2147483647
Year: 2002
Pages: 193

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