Architecture A Technical Perspective

Although software architecture has been discussed at length over the past decade, convergence on definitions, terminology, and principles has been lacking. The following discussion draws generally on the foundations of architecture developed at Rational Software Corporation and particularly on Philippe Kruchten's concepts of software architecture [Kruchten, 1995].

Software architecture encompasses the structure of software systems (the selection of elements and the composition of elements into progressively larger subsystems), their behavior (collaborations among elements), and the patterns that guide these elements, their collaborations, and their composition. The context of software architecture structure, behavior, and patterns must include functionality, performance, resilience, comprehensibility, economic trade-offs, technology constraints, and aesthetic concerns.

An architecture framework is defined in terms of views that are abstractions of the UML models in the design set. The design model includes the full breadth and depth of information. An architecture view is an abstraction of the design model; it contains only the architecturally significant information. Most real-world systems require four views: design, process, component, and deployment. The purposes of these views are as follows:

• Design: describes architecturally significant structures and functions of the design model

• Process: describes concurrency and control thread relationships among the design, component, and deployment views

• Component: describes the structure of the implementation set

• Deployment: describes the structure of the deployment set

The design view is probably necessary in every system; the other three views can be added to deal with the complexity of the system at hand. For example, any distributed system would need a process view and a deployment view. Most large systems, as well as systems that comprise a mixture of custom and commercial components, would also require a separate component view.

Figure 7-1 summarizes the artifacts of the design set, including the architecture views and architecture description. The architecture description is usually captured electronically but is always maintained so that it is printable as a single cohesive document. The engineering models and architectural views are defined as collections of UML diagrams.

The requirements model addresses the behavior of the system as seen by its end users, analysts, and testers. This view is modeled statically using use case and class diagrams, and dynamically using sequence, collaboration, state chart, and activity diagrams.

• The use case view describes how the system's critical (architecturally significant) use cases are realized by elements of the design model. It is modeled statically using use case diagrams, and dynamically using any of the UML behavioral diagrams.

Requirements

Design

Implementation

Deployment

The requirements set may include UML models describing the problem space.

The design set includes all UML design models describing the solution space.

Depending on its complexity, a system may require several models or partitions of a single model.

The design, process, and use case models provide for visualization of the logical and behavioral aspects of the design.

The component model provides for visualization of the implementation set.

The deployment model provides for visualization of the deployment set.

An architecture is described through several views, which are extracts of design models that capture the significant structures, collaborations, and behaviors.

An architecture is described through several views, which are extracts of design models that capture the significant structures, collaborations, and behaviors.

Figure 7-1. Architecture, an organized and abstracted view into the design models

Architecture Description Document

Design view Process view Use case view Component view Deployment view Other views (optional) Other material:

• Constraints

Figure 7-1. Architecture, an organized and abstracted view into the design models

The design model addresses the architecture of the system and the design of the components within the architecture, including the functional structure, concurrency structure, implementation structure, and execution structure of the solution space, as seen by its developers. Static descriptions are provided with structural diagrams (class, object, component, deployment diagrams). Dynamic descriptions are provided with any of the UML behavioral diagrams (collaboration, sequence, state chart, activity diagrams).

• The design view describes the architecturally- significant elements of the design model. This view, an abstraction of the design model, addresses the basic structure and functionality of the solution. It is modeled statically using class and object diagrams, and dynamically using any of the UML behavioral diagrams.

• The process view addresses the run-time collaboration issues involved in executing the architecture on a distributed deployment model, including the logical software network topology (allocation to processes and threads of control), interprocess communication, and state management. This view is modeled statically using deployment diagrams, and dynamically using any of the UML behavioral diagrams.

• The component view describes the architecturally significant elements of the implementation set. This view, an abstraction of the design model, addresses the software source code realization of the system from the perspective of the project's integrators and developers, especially with regard to releases and configuration management. It is modeled statically using component diagrams, and dynamically using any of the UML behavioral diagrams.

• The deployment view addresses the executable realization of the system, including the allocation of logical processes in the distribution view (the. logical software topology) to physical resources of the deployment network (the physical system topology). It is modeled statically using deployment diagrams, and dynamically using any of the UML behavioral diagrams.

Architecture descriptions take on different forms and styles in different organizations and domains. At any given time, an architecture requires a subset of artifacts in each engineering set. The actual level of content in each set is situation-dependent, and there are few good heuristics for describing objectively what is architecturally significant and what is not.

Generally, an architecture baseline should include the following:

• Requirements: critical use cases, system-level quality objectives, and priority relationships among features and qualities

• Design: names, attributes, structures, behaviors, groupings, and relationships of significant classes and components

• Implementation: source component inventory and bill of materials (number, name, purpose, cost) of all primitive components

• Deployment: executable components sufficient to demonstrate the critical use cases and the risk associated with achieving the system qualities

Although the technical details of architecture description are not central to software management, the underlying spirit of architecture-first development is crucial to success. Drawing this line (what's in the architecture and what's not) is the challenge of project management, for it is the ultimate question of balance that significantly influences project success.

An architecture baseline is defined as a balanced subset of information across all sets, whereas an architecture description is completely encapsulated within the design set. This distinction is a subtle but important difference between conventional approaches and modern iterative development processes. Conventional approaches would equate an architecture baseline with an architecture description (realized as a document with no rigorous design notation), without any representation in the other engineering artifact sets to validate the integrity of the description. In iterative development, an architecture baseline is a partial realization of the architecture description that is sufficient to provide tangible evidence that the architecture is valid in the context of the requirements and plans.

The architecture description will take a wide range of forms, from a simple, direct subset of UML diagrams to a complex set of models with a variety of distinct views that capture and compartmentalize the concerns of a sophisticated system. The former may be applicable for a small, highly skilled team building a development tool, the latter for a highly distributed, large-scale, catastrophic-cost-of-failure command and control system.

The artifact sets evolve through a project life cycle from the engineering stage (when the focus is on the requirements and design artifacts) to the production stage (when the focus shifts to the implementation and deployment artifacts). The transition point from the engineering stage to the production stage constitutes a state in which the project has achieved a stable architecture baseline. From a management perspective, this state is achieved when relevant stakeholders agree that the vision (as supported by the requirements set and the architecture, represented in the design set, and partially realized in the implementation and deployment sets) can be achieved with a highly predictable cost and schedule (as supported in the management set). Substantiation of this state typically requires not only briefings and documents, but also executable prototypes that demonstrate evolving capabilities. These demonstrations provide far more tangible feedback on the maturity of the solution. The more standard components are used, the simpler this state is to achieve. The more custom components are used, the harder it is to achieve and the harder it is to estimate construction costs.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Responses

  • curzio
    What is architecture technical perspective?
    2 years ago

Post a comment