Rational Rhapsody for MODAF views

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.

Table 1. MoDAF views
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.

Feedback