Develop System Architecture Overview
The System Architecture Overview is created early in the lifecycle of a project, possibly as early as the inception
phase (in Activity: Synthesize System Architecture). It reflects early decisions and working
assumptions on implementing the Vision, as well as decisions concerning the physical, logical and process architecture
and non-functional requirements of the system. It is produced by the System Architect, usually in the form of an
informal sketch. Conceptually, it illustrates the essential nature of the proposed solution, conveying the governing
ideas and including the major building blocks. The level of formality of the System Architectural Overview is
project-dependent. For example, in a large, high-ceremony project, it might be necessary to capture the System
Architecture Overview in the appropriate sections of the System Architecture Document, so that it can be formally
reviewed. In this case the System Architect has to use a formal (UML) illustration of the tentative solution.
Many systems are constrained to be developed and deployed in an existing environment of hardware, software, and people;
for these, the Software Architect gathers information about the current environment and captures it in the System
Deployment Model.
|
Survey available assets
Understand the requirements of the environment for which assets are being considered. Understand the system scope and
the general functionality required. Search through organizational asset bases, and industry literature to identify
assets or similar projects. Consider several types of assets, such as, but not limited to, industry models, frameworks,
classes, and experience. Assess whether available assets could contribute to solving the key challenges of the current
project, and are compatible with its constraints.
Analyze the extent of fit between asset and customer requirements. Consider whether any of the requirements are
negotiable (to enable use of the asset).
Assess whether the asset could be modified or extended to satisfy requirements. Assess the trade-offs in cost, risk,
and functionality from adopting the asset.
Decide in principle whether to use one or more assets, and document the rationale for this decision.
|
Determine the initial logical decomposition into subsystems
In this step, the System Architect has the task of partitioning the system into subsystems (which themselves can be
further decomposed if sufficiently large or complex). The subsystems collaborate to deliver the behavior described in
the Use-Case Model, and, in particular, collaborate to realize the operations defined in Task: Define the System Context. The System Architect strives to
create a set of subsystems that are:
-
Functionally cohesive (have a well-defined and limited set of related capabilities and responsibilities).
-
Minimally coupled one to the other (the communication between subsystems that is required in the realization of
system operations is kept to a minimum).
Requirements work and Business Modeling work highlight abstractions that are candidates to become subsystems: the
expression of requirements in domain-appropriate language yield terms for entities that might become subsystems. The
domain itself, independent of the specific requirements for this system, might also guide the System Architect, because
there are concepts in the domain that are naturally (and historically) treated as subsystems. Rarely are a system and
its associated domain so completely unprecedented that there is not some guidance from previous implementations. Indeed
the domain might be so well explored that the System Architect can say with confidence that certain capabilities are to
be implemented in mechanical/electrical subsystems, others in software subsystems, and others as manual
(people/procedural) subsystems.
Depending on the domain, and the novelty of the system, analysis patterns, which capture many of the key abstractions required to model the
system, might already exist. The Object Management Group is also attempting to define interfaces and protocols for many
domains, through the work of its Domain Technology Committee and associated task forces. Inevitably, this work leads to
the identification of important abstractions in the domain.
Approached in this way, the System Architect can avoid a purely ad-hoc functional decomposition (and allocation of
requirements to subsystems), which often results in a sub-optimal architecture (see Concept: Derived Requirements).
|
Determine the system-level processes
By default, the System Architect might treat each subsystem as an entity capable of carrying out its responsibilities
autonomously and concurrently with other subsystems, communicating asynchronously with other subsystems as needed; that
is, the subsystems can be regarded as active, having their own loci of control. From this basic model, other forms of
computation and communication can be constructed if required. For example, in a software system, if the System
Architect see fit, a subsystem can be designed to be passive, that is, its operations are executed by processes
external to the subsystem (including invocations by other subsystems). This might bring some efficiencies in
execution (by reducing the process context switching overhead), at the expense of perhaps having to protect the passive
subsystem (or have it protect itself) from corruption caused by multiple simultaneous (and uncoordinated) invocations
of its operations.
Any processes external to the subsystems are represented as stereotyped active classes, and the drivers for their
identification are the same as for standard RUP-based software development (see Concept: Concurrency), for example, as proxies and interfaces for external systems or hardware (for example, acting in an
analogous way to a boundary class), or as control or sequencing agents (like a control class), in the end, together
with the active subsystems, representing internal system activities that need to run (at least logically, and perhaps
even physically) concurrently.
|
Develop Locality Model
Using the System Architecture Overview developed previously, the conceptual level of the Work Product: System Deployment Model is now developed. The System
Deployment Model is concerned with determination of elements which host the computational work defined by the
subsystems and their interactions. The System Deployment Model evolves through three levels: Locality (the most
abstract), Descriptor (where computational nodes are identified, along with their required characteristics), and
Implementation (at which actual hardware selections are made).
The primary business drivers of the System Deployment Model are:
-
users (at locations), defined in User Profiles (in the Vision) and use cases and the Use-Case Model
-
business data (in the Business Analysis Model), if a business modeling approach has been employed
-
operation level requirements (in the Supplementary Specifications)
-
constraints (in the Supplementary Specifications)
At this level of analysis, the concern is with the Locality Model (see Guidelines: System Deployment Model). The System
Architect partitions the computational resources into groups in support of kinds of processing, without, at this
stage, constraining the geographic location. The Locality Model represents the initial, abstract, physical partitioning
and distribution of the system, and is concerned with the physical resources of the system (nodes, devices, sensors and
their physical connections and interfaces, and the physical characteristics of these, for example weight, heat
generation, power consumption, vibration, and so forth.). The individual localities express notionally where processing
occurs (the semantics of locality implies a tighter grouping of resources) without defining exact geographic location
or how the processing capability is to be realized.
The System Architect prepares the locality diagram(s), consisting of the localities and their connections. Like the
localities, the connections are abstract at this level and simply represent pathways for information, mass, energy, or
discrete physical items to be exchanged between localities.
For each locality in the System Deployment Model, the System Architect prepares and attaches a description of derived
supplementary requirements (derived from system supplementary specifications) which specify quality (reliability,
maintainability, safety, and so on), physical and environmental requirements, and development constraints (cost,
technical risk, and so forth). From these requirements, the actual characteristics (of each locality) are determined
(tentatively in this task, more detail is added in Task: Refine System Deployment Model); obviously, these are chosen to
meet the explicit requirements at least, but can exceed the requirements if sound engineering practice dictates this,
for example, to cope with unexpected capacity demands.
Localities and connections are tagged (with UML tagged values) with their characteristics:
-
Localities, characterized with
-
Quality tags, such as reliability, availability, performance, capacity, and so forth
-
Management tags, such as cost and technical risk
-
Connections, characterized with
-
Link parameters, such as data rate, supported protocols, and flow rate
-
Management tags, such as cost and technical risk.
When there are no explicitly imposed requirements and constraints, the System Architect has to make judgments about the
implicit needs (confirming these with the stakeholders) and derive these characteristics accordingly.
Each locality hosts some set of subsystem operations, and the System Architect must ensure that the locality and
connection characteristics support the putative set of subsystem operations.
Detailed specification of localities and connections is deferred, except where this is important for estimation or
viability assessment.
Although this is the most abstract System Deployment Model produced in the project, and is produced quickly and at a
high level, it might identify actual hardware and software products if these are known (or required), or if it
is important to make these selection decisions at this time.
|
Outline significant collaborations
Based on the set of architecturally significant use cases (see Task: Prioritize System Use Cases), the System Architect outlines the
collaborations of subsystems that realize them, and captures these embryonic System Use-Case Realizations in the System Analysis Model. At this
stage, the System Architect need only identify the set of subsystems which realizes the use case; the links and
messages between them are added later.
|
Create/update Subsystem Vision(s)
Based on work in this task, the subsystems that need to be constructed have started to emerge. For each of these, the
System Architect produces an initial Subsystem Vision and includes a preliminary description of the desired
capabilities, responsibilities, qualities and interface requirements.
|
Review the results
The System Architect evaluates the results with the stakeholders, validating the choice of subsystems (with respect to
the domain and the architecturally significant use cases) and validating the assumptions and rationale behind the
choices made in the Locality Model.
|
|