• To transform the requirements into a design of the system to-be.

• To evolve a robust architecture for the system.

• To adapt the design to match the implementation environment, designing it for performance.

An analysis mechanism represents a pattern that constitutes a common solution to a common problem. They may be patterns of structure, patterns of behavior, or both. They are used during analysis to reduce the complexity of analysis, and to improve its consistency by providing designers with a short-hand representation for complex behavior. Mechanisms allow the analysis effort to focus on translating the functional requirements into software concepts without bogging-down in the specification of relatively complex behavior needed to support the functionality but not central to it.

Analysis mechanisms are primarily used to represent 'placeholders' for complex technology in the middle and lower layers of the architecture. By using the mechanisms as 'placeholders' in the architecture, the architecting effort is less likely to become distracted by the details of mechanism behavior. As an example, the need to have object lifetimes span use cases, process lifetimes, or system shutdown and start-up defines the need for object persistence. Persistence is a particularly complex mechanism, and during analysis we do not want to be distracted by the details of how we are going to achieve persistence. This gives rise to a 'persistence' analysis mechanism which allows us to speak of persistent objects and capture the requirements we will have on the persistence mechanism without worrying about what exactly the persistence mechanism will do or how it will work.

Analysis mechanisms are usually unrelated to the problem domain, but instead are "computer science" concepts; as a result they typically occupy the middle and lower layers of the architecture. They provide specific behaviors to a domain-related class or component, or correspond to the implementation of cooperation between classes and/or components. They may be implemented as a framework, Examples include mechanisms to handle persistence, inter-process communication, error or fault handling, notification, and messaging, to name a few.

• Granularity: Range of size of the objects to keep persistent.

• Volume: Number of objects to keep persistent.

• Duration: How long does the object typically need to be kept.

• Retrieval mechanism: How is a given object uniquely identified and retrieved?

• Update frequency: Are the objects more or less constant; are they permanently updated?

• Reliability: Shall the objects survive a crash of the process; the processor; or the whole system?

• Inter-process Communication

For all model elements which needs to communicate with objects, components or services executing in other processes or threads, we need to identify:

• Latency: How fast must processes communicate with another?

• Synchronicity: Asynchronous communication

• Size of message: A spectrum might be more appropriate than a single number.

• Protocol, flow control, buffering, and so on.

Other typical patterns include:

• Message routing

• Process control and synchronization

• Transaction management

• Information Exchange

• Security

• Redundancy

• Error reporting

• Format conversion

1. Collect all analysis mechanisms in a list
   
   The same analysis mechanism may appear under several different names across different use-case realizations, or different designers. For example, storage, persistency, database, and repository might all refer to a persistency mechanism. Or inter-process communication, message passing, or remote invocation might all refer to and inter-process communication mechanism.

• There might be a need for many (2,000) small objects (200 bytes each) to be stored for a few seconds, with no need for survival.

• There might be a need for several very large objects to be stored permanently on disk for several months, never updated, but with sophisticated means of retrieval.

These objects will require different support for persistency; the following design mechanisms for persistency support might be identified:

• In-memory storage; characteristics: for up to 1 Mb total (size x volume); very fast access for read write update.

• Flash card; characteristics: for up to 8 Mb; slow update and read access; moderate read access.

• Binary file; characteristics: for 100 Kb to 200 Mb; slow update; slow access.

• Database Management System (DBMS); characteristics: for 100 Kb to 2 Gb; even slower read and write access.

Initially, the mapping between design mechanisms and implementation mechanisms is likely to be less than optimal but it will get the project running, identify yet-unseen risks, and trigger further investigations and evaluations. As the project continues and gains more knowledge, the mapping needs to be refined.

Proceed iteratively to refine the mapping between design and implementation mechanisms, eliminating redundant paths, working both "top-down" and "bottom-up."

Working Top-Down. When working "top-down," new and refined use-case realizations will put new requirements on the needed design mechanisms via the analysis mechanisms needed. Such new requirements might uncover additional characteristics of a design mechanism, forcing a split between mechanisms. There is also a compromise between the system's complexity and its performance:

• Too many different design mechanisms make the system too complex.

• Too few design mechanisms can create performance issues for some implementation

mechanisms that stretch the limits of the reasonable ranges of their characteristics values.

Working Bottom-Up. When working "bottom-up," investigating the available implementation mechanisms, you might find products that satisfy several design mechanisms at once, but force some adaptation or repartitioning of your design mechanisms. You want to minimize the number of implementation mechanisms you use, but too few of them can also lead to performance issues.

Once you decide to use a DBMS to store objects of class A, you might be tempted to use it to store all objects in the system. This could prove very inefficient, or very cumbersome. Not all objects which require persistency need to be stored in the DBMS. Some objects may be persistent but may be frequently accessed by the application, and only infrequently accessed by other applications. A hybrid strategy in which the object is read from the DBMS into memory and periodically synchronized may be the best approach.

A flight can be stored in memory for fast access, and in a DBMS for long term persistency; this however triggers a need for a mechanism to synchronize both.

It is not uncommon to have more than one design mechanisms associated with a client class as a compromise between different characteristics.

Because implementation mechanisms often come in bundles in off-the-shelf components (O.S., and middleware products) some optimization based on cost, or impedance mismatch, or uniformity of style needs to occur. Also, mechanisms often are inter-dependent, making clear separation of services into design mechanisms difficult.

• The error reporting mechanism can be based on the persistency mechanism.

Refinement continues over the whole elaboration phase, and is always a compromise between:

• An exact 'fit' with the requirements of the clients of the design mechanism, in terms of the expected characteristics.

• The cost and complexity of having too many different implementation mechanisms to acquire and integrate.

The overall goal is always to have a simple clean set of mechanisms that give conceptual integrity, simplicity and elegance to a large system.

The Persistence design mechanisms can be mapped to implementation mechanisms as follows:

A possible mapping between analysis mechanisms and design mechanisms. Dotted arrows mean "is specialized by," implying that the characteristics of the design mechanisms are inherited from the analysis mechanisms but that they will be specialized and refined.

Once you have finished optimizing the mechanisms, the following mappings exist:

The design decisions for a client class in terms of mappings between mechanisms; the Flight class needs two forms of persistency: in-memory storage implemented by a ready-made library routine, and in a database implemented with an off-the-shelf ObjectStorage

• The Business Modeling workflow provides a organizational context for the system.

• The Requirements workflow provides the primary input for Analysis and Design.

• The Test workflow tests system designed during Analysis and Design.

• The Environment workflow, develops and maintains the supporting artifacts that are used during Analysis and Design.

Concepts: Software Architecture

Software architecture is a concept that is easy to understand, and that most engineers intuitively feel, especially with a little experience, but it is hard to define precisely. In particular, it is difficult to draw a sharp line between design and architecture - architecture is one aspect of design that concentrates on some specific features.

But there is more to architecture than just structure; the IEEE Working Group on Architecture defines it as "the highest-level concept of a system in its environment" [IEEE]. It also encompasses the "fit" with system integrity, with economical constraints, with aesthetic concerns, and with style. It is not limited to an inward focus, but takes into consideration the system as a whole in its user environment and its development environment - an outward focus.

Architecture Description

To speak and reason about software architecture, you must first define an architectural representation, a way of describing important aspects of an architecture. In the Rational Unified Process, this description is captured in the Software Architecture Document.

We have chosen to represent software architecture in multiple architectural views. Each architectural view addresses some specific set of concerns, specific to stakeholders in the development process: end users, designers, managers, system engineers, maintainers, and so on.

The views capture the major structural design decisions by showing how the software architecture is decomposed into components, and how components are connected by connectors to produce useful forms. These design choices must be tied to the requirements, functional, and supplementary, and other constraints. But these choices in turn put further constraints on the requirements and on future design decisions at a lower level.

Architecture is represented by a number of different architectural views, which in their essence are extracts illustrating the "architecturally significant" elements of the models. In the Rational Unified Process, you start from a typical set of views, called the "4+1 view model" [KR95]. It is composed of:

• The Use-Case View, which contains use-cases and scenarios that encompasses architecturally significant behavior, classes, or technical risks. It is a subset of the use-case model.

• The Logical View, which contains the most important design classes and their organization into packages and subsystems, and the organization of these packages and subsystems into layers. It contains also some use case realizations. It is a subset of the design model.

• The Implementation View, which contains an overview of the implementation model and its organization in terms of modules into packages and layers. The allocation of packages and classes (from the Logical View) to the packages and modules of the Implementation View is also described. It is a subset of the implementation model.

• The Process View, which contains the description of the tasks (process and threads) involved, their interactions and configurations, and the allocation of design objects and classes to tasks. This view need only be used if the system has a significant degree of concurrency. In Rational Unified Process 5.X, it is a subset of the design model.

• The Deployment View, which contains the description of the various physical nodes for the most typical platform configurations, and the allocation of tasks (from the Process View) to the physical nodes. This view need only be used if the system is distributed.

The architectural views are documented in a Software Architecture Document. You can envision additional views to express different special concerns: user-interface view, security view, data view, and so on. For simple systems, you may omit some of the views contained in the 4+1 view model.

Although the views above could represent the whole design of a system, the architecture concerns itself only with some specific aspects:

• The structure of the model - the organizational patterns, for example, layering.

• The essential elements - critical use cases, main classes, common mechanisms, and so on, as opposed to all the elements present in the model.

• A few key scenarios showing the main control flows throughout the system.

• The services, to capture modularity, optional features, product-line aspects.

In essence, architectural views are abstractions, or simplifications, of the entire design, in which important characteristics are made more visible by leaving details aside. These characteristics are important when reasoning about

• System evolution - going to the next development cycle.

• Reuse of the architecture, or parts of it, in the context of a product line.

• Assessment of supplementary qualities, such as performance, availability, portability, and safety.

• Assignment of development work to teams or subcontractors.

• Decisions about including off-the-shelf components.

• Insertion in a wider system.

Architectural patterns are ready-made forms that solve recurring architectural problems [BMR96]. An architectural framework or an architectural infrastructure (middleware) is a set of components on which you can build a certain kind of architecture. Many of the major architectural difficulties have been resolved in the framework or in the infrastructure, usually targeted to a specific domain: command and control, MIS, control system, and so on.

A software architecture, or only an architectural view, may have an attribute called architectural style, which reduces the set of possible forms to choose from, and imposes a certain degree of uniformity to the architecture. The style may be defined by a set of patterns, or by the choice of specific components or connectors as the basic building blocks. For a given system, some of the style can be captured as part of the architectural description in an architecture style guide - part of a design guidelines document in the Rational Unified Process. Style plays a major role in the understandability and integrity of the architecture.