The following table lists the views (within their viewpoints) included in the IBM® Rational® Rhapsody® for MODAF Add On.
For more information about these views, go to the official online documentation website for MODAF at http://www.modaf.org.uk.
| Architecture Viewpoint/View | View | View Name | Description |
|---|---|---|---|
| All Views Viewpoint | Package | The All Views viewpoint contains views that provide overview and nomenclature. | |
| AV-1 | All | Overview and Summary Information |
This view is typically a text document (for example, Word, FrameMaker, HTML) that provides overview and summary information for the operations and capabilities being considered for the enterprise. It scopes the architecture and gives it context. You can add AV‑1 documents and launch them by clicking on them. |
| AV-2 | All | Integrated Dictionary |
This view presents all the elements used in an architecture as a standalone structure, generally using a specialization hierarchy. It should provide a text definition for each one and references the source of the element (for example, MODAF Ontology, IDEAS Model, local, and so on). |
| Strategic Viewpoint | Package | The Strategic Viewpoint contains views that detail military capabilities and how they evolve to be used by various organizations. | |
| StV-1 | Strategic | Enterprise Vision | This view defines the strategic context for a group of enterprise‑level capabilities. It takes the overall enterprise vision and goals of the architects and enables them to relate these to realizable capabilities. StV-1 used to be a textual document but is now better represented in a more structured format as UML structure or class diagrams. |
| StV-2 | Strategic | Capability Taxonomy | This view models capability hierarchies. It enables users to
organize capabilities in the context of an enterprise phase, showing
required capabilities for current and future enterprises. It specifies
all the capabilities that are referenced throughout the current architecture
and possibly other reference architectures. StV‑2 is realized using UML structure or class diagrams. |
| StV-3 | Strategic | Capability Phasing | This view shows when capabilities are expected to be used.
It maps capabilities to time periods. It is also used to perform gap/overlap
and redundancy analysis. StV‑3 shows a customized table view, with the user defining the time periods. |
| StV-4 | Strategic | Capability Dependencies | Similar to StV‑2, this view shows the capability dependencies
and logical groupings of capabilities (capability clusters) of the
capabilities described in the StV-2. StV‑4 is realized using UML structure or class diagrams. |
| StV-5 | Strategic | Capability to Organization Deployment Mapping | This view details what capabilities are mapped to what systems
at any particular time and the fulfilment of capability requirements,
in particular by network‑enabled capabilities. Use this view to perform
gap/overlap analysis and interoperability analysis, validate that
capabilities have been realized in Systems, and help provide system
requirements documents (SRDs) for Systems views. StV‑5 is realized using UML class or structure diagrams. |
| StV-6 | Strategic | Operational Activity to Capability Mapping | This view describes the mapping between the capabilities required
by an enterprise and the operational activities that those capabilities
support. Use this view to map capabilities to Operations and ensure
that all capabilities are fulfilled and can be traced to Operational
Activities. StV‑6 is derived from UML class diagrams with dependencies. It can be completed once you have done some of the Operational views. StV‑6 is a major reason to use tables/matrix layouts and views in Rational Rhapsody. |
| Operational Viewpoint | Package | The Operational viewpoint contains views that provide a logical view of how an operation is carried out. | |
| OV-1 | Operational | OV‑1 consists of three parts: OV‑1a, OV‑1b, and OV‑1c. The OV‑1 views are realized using UML use case diagrams. | |
| OV-1a | Operational | High-Level Operational Concept Graphic |
This high-level graphical presentation of the operational concept allows you to import pictures and other operational elements, such as Operational Nodes, Human Operational Nodes, Operational Activities, and the relations among them. It is intended to be an informal representation of the Concept of Operations (CONOPS). |
| OV-1b | Operational | Operational Concept Description |
This view presents a textual description for OV‑1a and it is produced with the associated OV‑1a. |
| OV-1c | Operational | Operational Performance Attributes |
This view presents in tabular form the details for the operational
performance attributes associated with the scenarios represented in
OV‑1a and their evolution over time. OV1‑1a contains performance parameters that define quality of service requirements. |
| OV-2 | Operational | Operational Node Relationships Description | This view shows the detailed relationships and flows among
operational nodes and operational activities. It also might be used
to express a capability boundary, that is, the problem domain. OV‑2 is realized using UML class or structure diagrams. |
| OV-3 | Operational | Operational Information Exchange Matrix |
This view, presented as a matrix, shows information exchanged
between nodes, and the relevant attributes of that exchange. OV‑3 can be derived from OV‑2 and is generated using the table and matrix functionality. |
| OV-4 | Operational | Organizational Relationships Chart |
This view shows an organizational chart for the enterprise.
It is divided into two types, a typical chart and an actual chart. OV‑4 is realized for using UML class or structure diagrams. |
| OV-5 | Operational | Operational Activity Model |
This view shows the flow and ordering of activities required
to achieve the operational capability. OV‑5 is a lower-down version of OV‑2 and is realized using UML activity diagrams. |
| OV-6a | Operational | Operational Rules Model | The OV‑6 views are used to describe the textual rules that
control and constrain the mission (for example, doctrine, rules of
engagement, and so on). They are represented as operational constraints
placed upon operational view model elements. The actual rules and to which elements they are applied are shown in a UML structure or class diagram and then shown in a table. |
| OV-6b | Operational | Operational State Transition Description |
The OV‑6 views are used to describe the mission objective. OV‑6b view depicts the behavior of an operational element (node or activity). OV‑6b is realized using UML statecharts. |
| OV-6c | Operational | Operational Event- Trace Description | The OV‑6 views are used to describe the mission objective. OV‑6c shows the messages and ordering of messages passing between operational nodes. OV‑6c is realized using UML sequence diagrams. |
| OV-7 | Operational | Information Model | This view shows the structures of the data that are being passed
between elements. OV‑7 is realized using UML class diagrams that define the data, its composition and types. |
| System Viewpoint | Package | The System viewpoint contains views that look at how Operations are physically implemented. They are used as input to SRDs, detail how platforms interact, and are the physical realization of capabilities in StVs. | |
| SV-1 | Systems | Resource Interaction Specification |
This view shows what your resources are and how they interact
with each other. This includes the human elements of your enterprise,
such as roles, posts, and organizations; as well as physical elements,
such as systems and platforms. This view is generally used for the
definition of systems concepts/options, interface definitions, interoperability
analysis, and operational planning. SV‑1 is realized from using UML structure or class diagrams. |
| SV-2a | Systems | Systems Port Specification |
The SV2 views are all related to communication and can be realized
using UML structure and class diagrams. SV‑2a specifies the ports (specified points of interaction) that a system has and defines the protocols that a port might use. |
| SV-2b | Systems | Systems Port Connectivity Description |
The SV2 views are all related to communication and can be realized
using UML structure and class diagrams. SV‑2b shows the interaction of ports between systems. SV‑2b is very similar to SV‑1 but with protocols and networks included. |
| SV-2c | Systems | Systems Connectivity Clusters |
The SV2 views are all related to communication and can be realized
using UML structure and class diagrams. SV-2c defines how individual connections between systems are grouped into logical connections between parent resources. |
| SV-3 | Systems | Resource Interaction Matrix | This view tells you what communicates with what. It is generated from the information from SV‑1. SV‑3 shows the lines of communication between systems as an N2 diagram (system‑system matrix). It indicates source (provider of information) and sink (consumer of information) of data flows. |
| SV-4 | Systems | Functionality Description |
This view defines the functional decomposition of a system
or function. It can be used to show how functions interact to perform
a higher‑level function. SV‑4 provides the functional requirements
from the SRDs. SV‑4 can be realized by using UML activity diagrams. |
| SV-5 | Systems | Function to Operational Activity Traceability Matrix |
This view is a spreadsheet-like generated view that summarizes
the mapping of System and Systems functions to Operations, helps identify
missing System functions, and provides traceability links between
URDs and SRDs. This matrix is derived from UML class diagrams that have dependencies that link systems resources or functions to operations. |
| SV-6 | Systems | Systems Data Exchange Matrix | Similar to SV‑3 but for system data, this view details source‑sink,
protocols, content, and so on, of all data items. It helps specify
interoperability requirements. SV‑6 is derived from information captured as attributes in the model. It is customizable depending upon the information required by the user of the architecture. |
| SV-7 | Systems | Resource Performance Parameters Matrix |
This is a generated spreadsheet-like view that defines the
quality of service requirements expected of each part of the system. SV‑7 can be derived from a UML requirements diagram or attributes associated with model elements. This view is customizable by the user. |
| SV-8 | Systems | Capability Configuration Management |
This view is the system evolution description. It describes
how the system or architecture is expected to evolve over long periods
of time. SV‑8 is similar to StV‑3. SV‑8 can be realized as an UML class or structure diagram. |
| SV-9 | Systems | Technology and Skills Forecast |
This view is a customizable table (it depends on user‑defined time periods) that details what technology will be available in the near future. It touches upon system evolution, capability phasing, and acquisitions. |
| SV-10a | Systems | Resource Constraints Specification |
This view specifies functional and non‑functional constraints
on the implementation aspects of the architecture (that is, the structural
and behavioral elements of the SV viewpoint). These elements are mapped to each other on a class or structure diagram and shown in a set of table views. |
| SV-10b | Systems | Resource State Transition Description |
This view shows state-based behavior, of the system resources
to various events. For consistency, the state‑based behavior should
map to the aggregate behavior of all the flows shown in SV‑10c. SV‑10b is realized using UML statecharts. |
| SV-10C | Systems | Resource Event- Trace Description | This view provides a time‑ordered representation of all the
message and event interaction that occur between the various systems
resources. These diagrams are focussed around specific scenarios. SV‑10c is realized using UML sequence diagram. |
| SV-11 | Systems | Physical Schema | This view is similar to OV‑7 and it defines data used at the
physical level (data relationships, structure, attributes), optimizes
data structures, and specifies interfaces and data types. SV‑11 is realized in UML class diagrams. |
| Acquisition Viewpoint | Package | It contains elements associated with the Acquisition viewpoint
that are used by other views in the Rational Rhapsody MODAF
profile. The AcV-1 and AcV-2 views are not supported in the Rational Rhapsody MODAF profile. |
|
| Technical Viewpoint | Package | The Technical viewpoint contains views that detail technical standards that constrain the system development. | |
| TV-1 | Technical | Standards Profile | TV‑1 presents the current technical and non‑technical standards,
guidance, and policy applicable to the architecture. Note that TV‑1 can be a very large external document that is brought into the model or it can created as a customizable table that maps elements representing standards to model elements. |
| TV-2 | Technical | Standards Forecast | This view identifies the standards under development with expectations going forward. TV‑2 can be seen in a customizable table that relates standards to time periods. |