Model based software architecture

ARCHITECTURE: A MANAGEMENT PERSPECTIVE

The most critical technical product of a software project is its architecture: the infrastructure, control, and data
interfaces that permit software components to cooperate as a system and software designers to cooperate
efficiently as a team. When the communications media include multiple languages and intergroup literacy
varies, the communications problem can become extremely complex and even unsolvable. If a software
development team is to be successful, the inter project communications, as captured in the software
architecture, must be both accurate and precise
From a management perspective, there are three different aspects of architecture.
1. An architecture (the intangible design concept) is the design of a software system this includes all
engineering necessary to specify a complete bill of materials.
2. An architecture baseline (the tangible artifacts) is a slice of information across the engineering
artifact sets sufficient to satisfy all stakeholders that the vision (function and quality) can be
achieved within the parameters of the business case (cost, profit, time, technology, and people).
3. An architecture description (a human-readable representation of an architecture, which is one of the
components of an architecture baseline) is an organized subset of information extracted from the
design set model(s). The architecture description communicates how the intangible concept is
realized in the tangible artifacts.
The number of views and the level of detail in each view can vary widely.
The importance of software architecture and its close linkage with modern software development processes can
be summarized as follows:
 Achieving a stable software architecture represents a significant project milestone at which the
critical make/buy decisions should have been resolved.
 Architecture representations provide a basis for balancing the trade-offs between the problem space
(requirements and constraints) and the solution space (the operational product).
 The architecture and process encapsulate many of the important (high-payoff or high-risk)
communications among individuals, teams, organizations, and stakeholders.
 Poor architectures and immature processes are often given as reasons for project failures.
 A mature process, an understanding of the primary requirements, and a demonstrable architecture are
important prerequisites for predictable planning.
 Architecture development and process definition are the intellectual steps that map the problem to a
solution without violating the constraints; they require human innovation and cannot be automated.

ARCHITECTURE: A TECHNICAL PERSPECTIVE

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
Figure 7-1 summarizes the artifacts of the design set, including the architecture views and architecture
description.
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.
 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 dia-
grams, and dynamically using any of the UML behavioral diagrams.
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