The Architect s Activities in the RUP

The Architect's Activities in the RUP

It is hard to reduce the activities of the architect to a small set of recipes. Too much will depend on the context, the nature of the system, its size, or whether it is "green-field" development, an extension of an existing system, or the re-engineering of a legacy application.

Besides the Software Architecture Document and the architectural views it describes, the RUP describes several activities for the architect (see Figure 16.3). We will group them into three "buckets":

• Working with the requirements and the project management

• Refining the architecture

• Maintaining the architectural integrity

Figure 16.3. Overview of the Architect's Activities. An architect is responsible for a wide set of activities, including activities related to requirements and project management, refining the architecture, and maintaining architectural integrity.

Working with the Requirements and Project Management

These activities are usually at the early stages of a project, where the architect's role is straddling across project management, requirements management, and analysis and design.

Prioritize Use Cases

This activity encompasses the role of the architect in the planning of iterations, working jointly with the project manager. Based on the risks that must be mitigated in a given iteration, and based on which part of the system must be completed (when we are in the later part of the development cycle), the architect will select which parts of which use cases should be implemented in the upcoming iteration. We have seen this described in Chapter 6 on Inception.

Architectural Analysis

Based on the vision and the key use cases, an architect will develop the architectural vision we described earlier by developing an overview of the architecture, identifying which existing assets can be used or reused to minimize work, and giving a structure to the logical view of the architecture.

This structure is populated with key abstractions, usually deriving from the domain. They often are classes such as Customer, Order, Inventory, and so on, and key parts or attributes of these key classes. The architect also identifies fundamental analysis mechanisms and patterns to connect and give behavior to these classes. These analysis mechanisms are implementation-independent . They cover issues like persistency, communication, synchronization, and security. They will later be bound to concrete implementations .

Then, using these candidate abstractions (classes and patterns), the selected use cases can be described in use-case realizations.

Finally, all these individual decisions must be put together in a single coherent architecture, eliminating redundancy, looking at similarities, and exploiting them.

Construct an Architectural Proof-of-Concept Prototype

We saw in Chapter 6 on Inception that in bold, new projects, where a lot of unchartered territory has to be covered before making wise development choices, it may be necessary to build prototypes just to help scope the system, assess feasibility, or view the reality of a risk or the efficiency of a solution.

Refining the Architecture

This is where technological choices are made, validated , and documented. These activities mostly contribute to the development of the executable architectural baseline of the system, and their outcome is documented mainly in the SAD. These activities are illustrated in Chapter 7 on Elaboration.

Identify Design Mechanisms

The architect must now choose appropriate designs to realize the analysis mechanisms identified earlier. For example, shall persistency be on disk or in memory, using a database or a simple file? Often the choice of an infrastructure (a middleware) will bring a choice of possible designs. Then these designs must be mapped onto concrete implementation mechanisms.

Identify Design Elements

Similarly, the architect must know how the various key elements will be defined in the software. This is a core activity, where all the design skills of the architect can be used, as well as all the wealth of guidance on design that is contained in the RUP product. The only danger is in the architect going overboard and getting lost in this activity: too far, too deep, and too detailed.

Incorporate Existing Design Elements

Very often all this work must not be done in a vacuum . There are large opportunities for reuse, from platforms, from other similar projects, from legacy systems. Sometimes this takes the form of reverse-engineering existing elements to integrate them in the new system.

Structure Implementation Model

Having made some of the major choices, the implementation structure must be defined: Where will the implementation artifacts be stored? What about source code, executable, documentation, models? What will be under configuration and version control? Where will the reusable parts be? This structure must also allow developers to work in an efficient manner without stepping on each other's feet. Issues such as individual or team workspaces, integration spaces, and Configuration Management must also be considered when building this aspect of the architecture.

Describe Distribution and Describe the Runtime Architecture

Similarly, if the system is distributed and concurrent, processes, tasks , and various other issues of parallelism must be resolved and organized in separate views: the process view and the deployment view.

The architect describes the runtime architecture by

• Analyzing concurrency requirements.

• Identifying processes and threads.

• Identifying inter-process communication mechanisms.

• Allocating inter-process coordination resources.

• Identifying process lifecycles.

• Mapping processes onto the implementation environment.

• Distributing model elements among processes.

For distributed systems, the architect describes the distribution by outlining the physical nodes. This includes defining the network configuration and allocating processes to nodes.

A few years ago, our colleague Grady Booch was involved in a project that illustrated the importance of concurrency and load balancing. For a new generation of armored rocket launchers , he was designing advanced software to help maneuver the vehicle and analyze incoming fire. The design review showed some major flaws: When under fire, an operator could barely maneuver the vehicle, let alone scoot quickly away and hide. The solution was another allocation of modeling elements to processes and of processes to physical nodes, as well as different priorities for the runtime processes, so that neither the same processes nor the same processors would simultaneously handle the maneuvering of the vehicle and the analysis of incoming fire.

Maintaining Architectural Integrity

There are a certain number of auxiliary but important activities that are also the architect's responsibility. They either pertain to the assessment of the architecture, or they contribute to maintaining architectural integrity throughout the development cycle.

Develop Design Guidelines

The architects not only need to design or select an architecture, but they must also communicate on how to use it and how to exploit the elements of the architecture in a consistent manner; they even set up the rules on how to extend and change it. There may be many hidden assumptions in the architecture that must be spelled out clearly to all of the other designers, testers, and integrators in order not to break the architecture.

Develop Programming Guidelines

This is similar to the design guidelines, but it exploits the feature of a chosen programming language to achieve certain architectural intent.

Review the Architecture

The purpose of architectural reviews is

• To uncover any unknown or perceived risks in the schedule or budget.

• To detect any architectural design flaws. Architectural flaws are known to be the hardest to fix and the most damaging in the long run.

• To detect a potential mismatch between the requirements and the architecture: overdesign, unrealistic requirements, or missing requirements. In particular the assessment may examine some aspects often neglected in the areas of operation, administration, and maintenance. How is the system installed or updated? How do we transition the current databases?

• To evaluate one or more specific architectural qualities: performance, reliability, modifiability, security, and safety.

• To identify reuse opportunities.

This review is conducted as apart of the LCA Milestone at the end of Elaboration. Without enumerating them here, it is highly likely that an architect will be involved in other reviews, defined in the Project Management discipline of the RUP, as well as be a key player in the Change Control Board to decide how and when critical issues must be resolved.