This practice focuses on integrating various viewpoints to reason concurrently about different systems concerns.
Localities are defined to show distribution of responsibilities to processing locations. Mapping of the
responsibilities through white box activity diagrams for flows of a use-case to parallel architectural representations
from different viewpoints, for example security, distribution.
Value proposition: concurrently optimizes the entire system through parallel perspectives which unifies stakeholders
and shortens time to agree the target system architecture.
In developing the system model, use cases are written, system components are defined, and the interactions between the
components are described. This is standard practice for modeling a system. For large-scale developments, we must design
across multiple viewpoints concurrently, distributing functionality to the various pieces of the system. We also
decompose the system, divide and suballocate the requirements, and develop links for traceability purposes. The concept
for doing this is called Joint Realization. One mechanism for connecting all of these items is a joint realization
table (JRT). The joint realization method is how the JRT is completed, and is therefore the process by which
decomposition is accomplished.
A viewpoint is defined as a subset of the architecture model that addresses a certain set of engineering concerns. The
same artifact can appear in more than one viewpoint. Viewpoints allow framework users to separately address different
engineering concerns while maintaining an integrated, consistent representation of the underlying design.
A particular viewpoint might not be useful at all model levels. For example, hardware developers are a category of
(internal) program stakeholders concerned with the allocation of functionality and distribution of hardware within the
system. However, at the analysis model level, decisions about where functionality will be implemented (in hardware,
software, or workers) have not yet been made. As a result, there is typically no need for a hardware viewpoint at the
analysis model level. However, if the system involves actual hardware development, then one certainly does need a
hardware viewpoint at the more specific (lower) model levels. Although different architectures require different sets
of viewpoints, almost all require the logical and distribution viewpoints.
|
