276
Engineering Systems Integration
together. Then, the architect may develop one area in particular to sufficient detail to surface as many details as possible. Others may develop all
areas concomitantly in parallel, developing similar levels of detail,
expanding and detailing iteratively at each level of abstraction. Then,
when the underlying structures are worked through, the definitions and
contexts are defined and clarified further. Regardless of the proclivities of
the work, a structure of abstractions from the top level leading to lowerlevel detail is exacted. Much like the process of decomposition, the nature
of architecting is often to move from top to bottom, from bottom to top,
and from abstraction to detail and back. It is the iterative process of decomposing the design space and recomposing the elements that forms a preliminary architecture. To use the iterative process successfully, the
architect must conceptualize a schema in the domain at each of the levels
of abstraction that captures the exact behaviors needed by the product or
service. This schema is an internal representation of each level of abstraction that includes what (and does not) belong, the degree of misalignment
of the layer of each abstraction that is acceptable, the organization of the
concepts (partitioning of the objects, functions, and behaviors), and the
actions that can potentially revise the schema (and under what conditions
those revisions may take place). To be successful, the architect must have
content knowledge, structural knowledge, domain-specific strategy, general searching strategy, general representational strategy, and general
abstraction strategy.
Architecture describes what the system does and generally how it does
it. It reflects the optimizations and trade-offs that support the key operations. It identifies the processes to be performed by the subsystems and
components, defines the flows of information and interfaces between the
elements, and signifies the priorities. Architecture is explicitly concerned
with the views of what and how things are done in the context of the
domains. The domain of a relation is the set that contains all parameters
that identify the members of a relation. The domain is defined as the
sphere of activity that includes the physical entities, functions, processes
through their relations, and context. Domain analysis is defined as determining the (1) operations, (2) unit modularity of data and associated processing (data), (3) properties and abstractions, and (4) appropriate
partitioning. Domain analysis provides a representation of the requirements of the domain. The domain model identifies and describes the
structure of data, flow of information, functions, constraints, and controls
within the domain.
For a domain, the system architecture view shows how multiple systems link and interoperate. Additionally, the system architecture
describes the internal construction and operations. These descriptions
should include the physical connections, location and identification of the
key nodes (or points of interaction), and the component performance
parameters.