The graphical depiction of an architectural view is called an architectural blueprint. For the various views described above, the blueprints are composed of the following diagrams from the Unified Modeling Language [UML]:

• Logical view. Class diagrams, state machines, and object diagrams.

• Process view Class diagrams and object diagrams (encompassing task - processes and threads).

• Implement View: Component diagrams.

• Deployment View: Deployment diagrams.

• Use Case View: Use case diagrams depicting use cases, actors, and ordinary design classes; sequence diagrams depicting design objects and their collaboration.

The architecture is primarily an outcome of the analysis & design workflow. As the project reenacts this workflow, iteration after iteration, the architecture evolves, refined, and polished. As each iteration includes integration and test, the architecture is quite robust by the time the product is delivered. This architecture is a main focus of the iterations of the elaboration phase, at the end of which the architecture is normally baselined.

Concepts: Logical View

To provide a basis for understanding the structure and organization of the design of the system, an architectural view called the logical view is used in the Analysis & Design workflow. There is only one logical view of the system, which illustrates the key use-case realizations, subsystems, packages and classes that encompass architecturally significant behavior. The logical view is refined during each iteration.

The logical view shows an architecturally significant subset of the design model, i.e. a subset of the classes, subsystems and packages, and use-case realizations.

There are four additional views, the Use Case View (handled in the Requirements workflow), and the Process View, Deployment View, and Implementation View; these views are handled in the Analysis & Design, and Implementation workflows.

The architectural views are documented in a Software Architecture Document. You may add different views, such as a security view, to convey other specific aspects of the software architecture.

So in essence, architectural views can be seen as abstractions or simplifications of the models built, in which you make important characteristics more visible by leaving the details aside. The architecture is an important means for increasing the quality of any model built during system development.

Process View

To provide a basis for understanding the process organization of the system, an architectural view called the process view is used in the Analysis & Design workflow. There is only one process view of the system, which illustrates the process decomposition of the system, including the mapping of classes and subsystems onto processes and threads. The process view is refined during each iteration.

The process view shows the process organization of the system.

There are four additional views, the Use Case View (handled in the Requirements workflow), and the Logical View, Deployment View, and Implementation View; these views are handled in the Analysis & Design, and Implementation workflows.

The architectural views are documented in a Software Architecture Document. You may add different views, such as a security view, to convey other specific aspects of the software architecture.

So in essence, architectural views can be seen as abstractions or simplifications of the models built, in which you make important characteristics more visible by leaving the details aside. The architecture is an important means for increasing the quality of any model built during system development.

Deployment View

To provide a basis for understanding the physical distribution of the system across a set of processing nodes, an architectural view called the deployment view is used in the Analysis & Design workflow. There is only one deployment view of the system, which illustrates the distribution of processing across a set of nodes in the system, including the physical distribution of processes and threads. The deployment view is refined during each iteration.

The deployment view shows the physical distribution of processing within the system.

There are four additional views, the Use Case View (handled in the Requirements workflow), and the Logical View, Process View, and Implementation View; these views are handled in the Analysis & Design, and Implementation workflows.

The architectural views are documented in a Software Architecture Document. You may add different views, such as a security view, to convey other specific aspects of the software architecture.

So in essence, architectural views can be seen as abstractions or simplifications of the models built, in which you make important characteristics more visible by leaving the details aside. The architecture is an important means for increasing the quality of any model built during system development

Concepts: Layering

Typical Layering Approaches

Layering represents an ordered grouping of functionality, with the application-specific located in the upper layers, functionality that spans application domains in the middle layers, and functionality specific to the deployment environment at the lower layers.

The number and composition of layers is dependent upon the complexity of both the problem domain and the solution space:

• There is generally only a single application-specific layer.

• Domains in which previous systems have been built, or in which large systems are composed in turn of inter-operating smaller systems, there is a strong need to share information between design teams. As a result, the Business-specific layer is likely to partially exist and may be structured into several layers for clarity.

• Solution spaces which are well-supported by middleware products and in which complex system software plays a greater role will have well-developed lower layers, with perhaps several layers of middleware and system software.

Subsystems should be organized into layers with application-specific subsystems located in the upper layers of the architecture, hardware and operating-specific subsystems located in the lower layers of the architecture, and general-purpose services occupying the middleware layers.

The following is a sample architecture with four layers:

• The top layer, application layer, contains the application specific services.

• The next layer, business-specific layer, contains business specific components, used in several applications.

• The middleware layer contains components such as GUI-builders, interfaces to database management systems, platform-independent operating system services, and OLE-components such as spreadsheets and diagram editors.

• The bottom layer, system software layer, contains components such as operating systems, databases, interfaces to specific hardware and so on.

A layered structure starting at the most general level of functionality and growing towards more specific levels of functionality.

Layering provides a logical partitioning of subsystems into a number of sets, with certain rules as to how relationships can be formed between layers. The layering provides a way to restrict inter-subsystem dependencies, with the result that the system is more loosely coupled and therefore more easily maintained.

The criteria for grouping subsystems follow a few patterns:

• Visibility. Subsystems may only depend on subsystems in the same layer and the next lower layer.

• Volatility.

• In the highest layers, put elements which vary when user requirements change.

• In the lowest layers, put elements that vary when the implementation platform (hardware, language, operating system, database, etc.) changes.

• Sandwiched in the middle, put elements which are generally applicable across wide ranges of systems and implementation environments.

• Add layers when additional partitions within these broad categories helps to organize the model.

• Generality. Abstract model elements tend to be placed lower in the model. If not implementation-specific, they tend to gravitate toward to middle layers.

• Number of Layers. For a small system, three layers are sufficient. For a complex system, 5-7 layers are usually sufficient. For any degree of complexity, more than 10 layers should be viewed with suspicion that increases with the number of layers. Some rules of thumb are presented below:

Subsystems and packages within a particular layer should only depend upon subsystems within the same layer, and at the next lower layer. Failure to restrict dependencies in this way causes architectural degradation and makes the system brittle and difficult to maintain.

Exceptions include cases where subsystems need direct access to lower layer services: a conscious decision should be made on how to handle primitive services needed throughout the system, such as printing, sending messages, etc. There is little value in restricting messages to lower layers if the solution is to effectively implement call pass-throughs in the intermediate layers.

Within the top-layers of the system, additional partitioning may help organize the model. The following guidelines for partitioning present different issues to consider:

• User organization. Subsystems may be organized along lines that mirror the organization of functionality in the business organization (e.g. partitioning occurs along departmental lines). This partitioning often occurs early in the design because an existing enterprise model has a strongly organizationally partitioned structure. This organization pattern usually affects only the top few layers of application-specific services, and often disappears as the design evolves.

• Partitioning along user organization lines can be a good starting point for the model.

• The structure of the user organization is not stable over a long period of time (due to business reorganization), and is not a good long-term basis for system partitioning. The internal organization of the system should enable the system to evolve and be maintained independently of the organization of the business it supports.
• Areas of competence and/or skills. Subsystems may be organized to partition responsibilities for parts of the model among different groups within the development organization. Typically, this occurs in the middle and lower layers of the system, and reflects the need for specialization in skills during he development and support of complex infrastructural technology. Examples of such technologies include network and distribution management, database management, communication management, and process control, among others. Partitioning along competence lines may also occur in upper layers, where special competency in the problem domain is required to understand and support key business functionality; examples include telecommunication call management, securities trading, insurance claims processing, and air traffic control, to name a few.

• System distribution. Within any of the layers of the system, the layers may be further partitioned "horizontally" to reflect the physical distribution of functionality.

• Partitioning to reflect distribution can help to visualize the network communication which will occur as the system executes.

• Partitioning to reflect distribution can, however, make the system more difficult to change if the Deployment Model changes significantly.

• Secrecy areas. Some applications, especially those requiring special security clearance to develop and/or support, require additional partitioning along security access privilege lines. Software that control access to secrecy areas must be developed and maintained by personnel with appropriate clearance. If the number of persons with this background on the project is limited, the functionality requiring special clearance must be partitioning into subsystems that will be developed independently of other subsystems, with the interfaces to the secrecy areas the only visible aspect of these subsystems.

• Variability areas. Functionality that is likely to be optional, and thereby delivered only in some variants of the system, should be organized into independent subsystems which are developed and delivered independently of the mandatory functionality of the system.