Introduction
The term architecture is now widely used outside its traditional connotation of building, and there are many
definitions of "architecture" (in the context of systems) and "system (or systems) architecture," for example:
"Systems architecture: the fundamental and unifying system structure defined in terms of system elements,
interfaces, processes, constraints, and behaviors."
[baseline definition approved by the INCOSE Systems Architecture Working Group at INCOSE '96 in Boston, MA on July
8, 1996]
"System architecture comprises the major physical properties, style, structure, interactions, and purpose of a
system."
[Process for System Architecture and Requirements Engineering, Derek Hatley, Peter Hruschka, Imtiaz
Pirbhai, Dorset House Publishing 2000]
"Architecture: the concepts and rules that define the structure, semantic behavior, and relationships among the
parts of a system; a plan of something to be constructed. It includes the elements that comprise the thing, the
relationships among those elements, the constraints that affect those relationships, a focus on the parts of the
thing, and a focus on the thing as a whole."
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001, which references ISO/IEC 10746-2:
Information Technology - Open Distributed Processing - Reference Model: Foundations, as the source]
"Architecture: the structure of components in a program/system, their interrelationships, and the principles and
guidelines governing their design and evolution over time."
[DoD 5000.59-P, "Modeling and Simulation Master Plan," October 1995]
An architecture is "the structure of components, their relationships, and the principles and guidelines governing
their design and evolution over time."
[IEEE STD 610.12, extended slightly by the Integrated Architectures Panel (IAP) of the C4ISR Integration Task
Force (ITF) in DoD Architecture Framework, Version 1.0]
Different words and constructions are used, and not all the definitions cover exactly the same aspects, but
there are significant overlaps. These definitions reveal that system architecture is about the following:
-
the structure of the system in terms of the elements, components, and parts
-
the relationships between these elements
-
the constraints affecting the elements and their relationships
-
the behavior exhibited by the system and the interactions that occur between the elements to yield
that behavior
-
the principles, rules and rationale that made the system the way it is (and govern its evolution)
-
the system's physical and logical characteristics and properties
-
the purpose of the system
So, to completely convey all these aspects requires a rich and potentially complex information set, but it is necessary
to be mindful that not all stakeholders need to see or understand all aspects simultaneously. The idea of
viewpoints enables separation of these various concerns and presentation to a class of stakeholders of only what
they need for effective participation. From the perspective of a particular viewpoint, you can also view the system at
different "resolutions," from low resolution, corresponding to a high level of abstraction, to high resolution,
corresponding to a concrete specification (of parts, and so on) for implementation.
Viewpoints
A viewpoint (on a system) is "a form of abstraction achieved using a selected set of architectural concepts and
structuring rules, in order to focus on particular concerns within a system" [ISO/IEC 10746-2: Information Technology -
Open Distributed Processing - Reference Model: Foundations]. The table lists some of the viewpoints chosen to capture
the various concerns. These viewpoints are aligned with those found in ISO/IEC 10746-1: Information technology - Open
Distributed Processing - Reference Model: Overview.
Viewpoint
|
Concern
|
Impact
|
Worker
|
Concerned with the roles and responsibilities of the organization and system workers (and the
policies affecting these).
|
Worker activities, human/system interaction. Human performance specification and human factors.
|
Information
|
The kinds of information handled by the system and constraints on the use and interpretation of
that information.
|
Information integrity, capacity limitations.
Information accessibility, timeliness.
|
Logical
|
The decomposition of the system into a set of subsystems that interact at interfaces, collaborating
to provide the system services.
|
System exhibits desired behavior.
System is extendible, adaptable, maintainable.
Assets are reusable.
|
Distribution/Physical
|
The infrastructure required to support system functionality and distribution.
|
Adequacy of physical characteristics of system to host functionality and meet non-functional
requirements.
|
Process
|
Concurrency, scalability, performance, throughput, reliability.
|
Adequacy of system responsiveness, throughput, fault-tolerance.
|
Common System Viewpoints.
These viewpoints are some of the most common for software-intensive systems. Many system architectures also require
additional, domain-specific viewpoints. Examples include safety, security, and mechanical viewpoints. Viewpoints
represent different areas of concern that must be addressed in the system architecture and design. If there are system
stakeholders or experts whose concerns are important to the overall architecture, there is likely to be a need for a
set of viewpoint work products to capture their design decisions.
It is important to build a system architecture team with staff who are competent to look after the various viewpoints.
The team might consist of business analysts and users who take primary responsibility for the worker viewpoint,
software architects who attend to the logical viewpoint, and engineers who concern themselves with the physical
viewpoint, as well as experts on domain-specific viewpoints.
Levels of abstraction
In addition to viewpoints, a system architecture requires levels of specification. As the architecture is developed, it
evolves from a general, abstract specification to a more specific, detailed specification. RUP identifies four
architectural levels, as shown in the table below.
Model Level
|
Expresses
|
Context
|
The system and its actors.
|
Analysis
|
Initial partitioning of the system to establish the conceptual approach.
|
Design
|
Realization of the Analysis Model to hardware, software, and people.
|
Implementation
|
Realization of the Design Model into specific configurations.
|
RUP Architectural Levels
Through these levels, the design goes from the abstract to the physical. The Context Model captures all of the external
entities (actors) that interact with the system. These actors might be external to the enterprise that deploys the
system or might be internal to the enterprise. In both cases, the actors might be human workers or other systems. At
the Analysis level, the partitions do not reflect choices of hardware, software, and people. Instead, they reflect
design approaches for dividing up what the system needs to do and how the effort must be distributed. At the Design
level, the decisions are made as to the sorts of hardware and software components and worker roles that are needed. At
the Implementation level, specific choices of hardware and software technology are made to implement the design. For
example, at the Design level, a data server might be specified. At the Implementation level, the decision is made to
use a specific platform running a specific database application.
Models and diagrams
A model is a representation of a system, typically addressing some particular area of concern. A system,
then, is usually represented by a set of models, because there are multiple concerns for the system's development or
use. Each model can be constructed with varying levels of abstraction, from the more general, hiding or encapsulating
detail, to the more specific, exposing more detail and explicit design decisions.
A viewpoint, as its name implies, is a notional "position" from which some aspects or concerns about the system
are made visible, implying the application of a set of concepts and rules to form a conceptual filter. Usually, it is
not sufficient (for understanding) simply to examine the real system—models will have been (or will have to be)
constructed to represent and describe the concerns.
Views are projections of models which show entities that are relevant from a particular viewpoint. These
projections are typically illustrated by diagrams of some kind.
The intersection of viewpoint and model level of abstraction or specificity contain (or at least identify) views of one
or more models relevant to that viewpoint or concern, at that level of abstraction.
The system architecture then is captured in a set of models (and diagrams that visualize them) that express the
architecture from various viewpoints and levels. As shown in the model framework table below, there is not a
model/diagram for every viewpoint-level combination. At the Implementation level, a single model captures the
realization of hardware and software components for each system configuration.
Model Level
|
Viewpoints
|
Worker
|
Logical
|
Information
|
Distribution/Physical
|
Process
|
Context
|
UML Organization View
|
System Context Diagram
|
Enterprise Data View
|
Enterprise Locality View
|
Business Process View
|
Analysis
|
Generalized System Worker View
|
Subsystem View
|
System Data View
|
System Locality View
|
System Process View
|
Design
|
System Worker View
|
Subsystem Class Views
Software Component Views
|
System Data Schema
|
Descriptor Node View
|
Detailed Process View
|
Implementation
|
Worker Role Specifications and Instructions
|
Configurations: Deployment diagrams with software and hardware system components.
|
Many of the views specified in the table are derived from standard UML models. For example, in the Analysis level of
the Logical viewpoint, the system is decomposed into subsystems that collaborate to meet user requirements. The
subsystems are used with the same semantics as in the UML standard. These subsystems, in turn, are decomposed into
either subsystems or (ultimately) classes. The Design level of the Logical viewpoint is the view of the detailed Class
Model. The Process Model is also a standard UML class model, with the focus on active classes in the system. The
domain-specific viewpoints need also have views of work products in place for one or more of the levels. The set of
project work products , within this framework, needs to be a part of the project's development case.
|