Update locality supplementary requirements
The System Designer makes decisions about the determination and allocation of behavior in Task: System Operation Analysis and Task: System Operation Design and summarizes these decisions in the survey of subsystem operations hosted at a locality,
which is made a property of the Work Product: System Deployment Model. The sort of subsystem
operations by locality gives the System Architect an indication of the computing load at a locality (and so is useful
for reasoning about the capacity of the physical components that support the locality). The System Architect updates
the locality supplementary requirements based on this input.
|
Create/update locality interactions
In this step, the System Architect creates collaborations of localities and illustrates these with interaction diagrams
which show the data exchanged and the sequencing of exchanges between localities. This permits the System Architect to
reason about the coupling and cohesion of localities, and the required links (and their bandwidth) between localities.
The diagram shows the localities as stereotyped nodes.
Example Locality Interaction Diagram.
|
Refine Locality Model based on interactions
Based on discoveries made in the examination of locality interactions, the localities themselves can be refactored
(repartitioned), additional localities included, and so on. The locality supplementary requirements might be
consequently affected. The connections can also be specified with more certainty in this step.
|
Update locality subsystem survey
Any repartitioning of localities also has an effect on the subsystem operation survey, which is updated in the
System Deployment Model.
|
Develop/refine locality characteristics and derive locality element requirements
As the Locality Model stabilizes, the realization of locality supplementary requirements as locality characteristics
can progress, and the System Architect can begin to construct the Descriptor Level of the System Deployment Model to
support these characteristics (which become a statement of requirements for elements at the Descriptor Level).
|
Develop/refine Descriptor-Level Model
At this point, the System Architect starts to commit to hardware, software, and human elements to realize the
localities (and their hosted subsystem operations). The realization of a locality can be in terms of:
-
manual processing
-
general computational platforms and associated software, in which the computational platform is a delivery vehicle
for the capabilities of the software
-
other hardware elements
-
mechanical
-
hydraulic
-
electrical
-
electromechanical
-
...
which might contain no software, or in which software is embedded (and is therefore specialized in support
of the hardware function).
At the Descriptor Level, the System Architect specifies the types of elements, without making specific choices of
equipment (by manufacturer, model number, and so on). An allocation or budgeting process is used to define the
characteristics of the descriptor nodes.
|
Develop/refine Implementation-Level Model
At this, the physical level of realization of the System Deployment Model, the actual hardware selections are made and
the numbers and skills of staff needed are specified. Trade studies can be conducted to select a cost-effective (set
of) configurations which meet or exceed the specified characteristics.
|
Evaluate the results
Decisions made in this task are captured in the System Deployment Model; those aspects which the System Architect
considers to be significant are also recorded in the Work Product: System Architecture Document (in this case, as part of
the Physical viewpoint). The effectiveness of proposed solutions at all levels needs to be reviewed with the
stakeholders and the development team to ensure that all requirements (cost, capability, constraints) are satisfied.
Techniques such as simulation and prototyping can be used to provide more objective demonstrations of the adequacy of
the design(s).
|
|