“The High-Level Operational Concept Graphic describes a mission and highlights main operational nodes (see OV-2 definition) and interesting or unique aspects of operations. It provides a description of the interactions between the subject architecture and its environment, and between the architecture and external systems.
OV-1 is usually a free-form graphic document that describes a mission. However a UML representation may also be added, so you can trace how your mission is implemented by lower abstraction level in OV or SV models. We recommend adding as much as possible information to the UML model as this data can be later reused by other artifacts.
OV-1 consists of a graphical executive summary for a given architecture with accompanying text. The content of OV-1 depends on the scope and intent of the architecture, but in general it describes the business processes or missions, high-level operations, organizations, and geographical distribution of assets.
OV-1 is the most general of the architecture products and the most flexible in format. The product usually consists of one or more graphics (or possibly a movie), as needed, as well as explanatory text.” [DoDAF, v.10, Vol. II]
OV-1 is a product highlighting a core concepts or the scope of the subject system. In general a sketch can be used for OV-2, however, in order to get consistent model, it is recommended to draw a diagram.
So in MagicDraw OV-1 is implemented as diagram, which is based on UML Use Case diagram.
If an external document or an image is done for OV-1, a hyperlink to a free-form document describing OV-1 can be added to simplify the navigation.
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
Mission |
<<Mission>> [UseCase] |
|
Objective |
<<Objective>> [UseCase] |
|
Line |
<<Line>> [Association] |
N/A |
Target Area |
<<TargetArea>> [Class] |
|
Asset |
<<Asset>> [Class] |
|
A Mission is UML Use Case showing the mission of the subject system. There might be multiple missions defined in the same model.
Extends UML Use Case.
Describes the objective of the subject system. There might be multiple objectives defined in the same model.
Extends UML Use Case.
Line is a generic relationship showing an abstract connection between the elements. It may represent actual relationship, defined in the other products.
Extends UML Association.
representationType: LineRepresentationKind |
Defines what relationship type does this Line represents. Possible values are taken from LineRepresentationKind enumeration: Needline Flow Interface Communications Link |
actualImplementation: DoDAFRelationship [0..1] |
Defines what concrete relationship does this line represents |
Defines target area.
Extends UML Class.
position: String |
Textual description describing the position of the target area |
Asset is an abstract entity, describing an asset of subject system. It may represent actual element, defined in the other products.
Extends UML Class.
position: String |
Textual description describing the position of the asset |
representationType: AssetRepresentationKind |
Defines what entity type does this Asset represents. Possible values are taken from AssetRepresentationKind enumeration: Operational Node Operational Activity Organizational Resource Systems Node System System Function |
actualImplementation: DoDAFEntity [0..1] |
Defines what concrete entity does this asset represents |
Figure 5 OV-1 profile diagram
OV-1 should be created as a high-level abstraction model, serving as a guideline for the rest of the DoDAF model. It should show only core objects and relationships. It is up to a modeler to choose the abstraction level. Modeler can choose from:
Show the missions, objectives, main assets (with types defined), and connecting lines (with types defined).
Show the missions, objectives, main assets (with actual entities defined), and connecting lines (with actual relationships defined). It is recommended to create Assets and Lines without showing their actual implementations (Nodes, Systems, Interfaces, etc). Later, when appropriate OV and SV products are done, user can link them the to the OV-1.
Show the missions, objectives, main entities, and main relationships. You can drag and drop existing elements to the OV-1.
Use the OV-1 specific diagram toolbar for fast creation of this product.
OV-1 can use various DoDAF elements as actualImplementation property for the Asset and various DoDAF paths as actualImplementation property for the Line.
If needed, concrete DoDAF element can be used in the OV-1, however, we recommend to use only core ones or none.
Figure 6 OV-1 sample 1
Figure 7 OV-1 sample 2
“The Operational Node Connectivity Description graphically depicts the operational nodes (or organizations) with needlines between those nodes that indicate a need to exchange information. The graphic includes internal operational nodes (internal to the architecture) as well as external nodes.
OV-2 is intended to track the need to exchange information from specific operational nodes (that play a key role in the architecture) to others. OV-2 does not depict the connectivity between the nodes. “[DoDAF, v.10, Vol. II]
OV-2 is a diagram, which is based on either UML Class Diagram or UML Composite Structure Diagram depending on the level of details.
User also may use:
Regular UML Class Diagram
Regular UML Composite Structure Diagram
SysML Block Definition Diagram
SysML Internal Block Diagram
Any other MagicDraw diagram
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
Needline |
<<Needline>> |
N/A |
Operational Node |
<<OperationalNode>> [Class] |
|
Operational Node Usage |
<<OperationalNodeUsage>> [Property] |
|
Organizational Resource Usage |
<<OrganizationalResourceUsage>> [Property] |
|
Service Specification |
<<ServiceSpecification>> [Class] |
|
Soa Service |
<<SoaService>> [Port] |
|
Information Exchange |
See OV-3 data element definitions |
|
Information Element |
See OV-3 data element definitions |
|
Operational Activity |
See OV-5 data element definitions |
|
Systems Node |
See SV-1 data element definitions |
|
Interface |
See SV-1 data element definitions |
A Needline is a relation between two Operational Nodes showing that these two nodes communicate to each other and exchange information.
Extends UML Association (in block definition diagrams), UML Connector (in internal block diagrams).
identifier: String |
Unique identifier of the Needline (may be a number) |
implementingInterface: Interface [*] |
Interface from SV-1 implementing this Needline |
An Operational Node is an element that produces, consumes, or manipulates information. It can also group Organizational Structure Elements from OV-4 and Operational Activities from OV-5.
Derives from SysML Block, Performer (extends UML Class).
levelIdentifier: String |
If using hierarchical decomposition of nodes: Identifier that corresponds to the node’s place in the node hierarchy – should be unique |
isExternal: Boolean = false |
Shows if this is an external Operational Node. By default Operational Node is not external. |
operationalRole: OperationalRole |
Defines an operational role that is applied to Operational Node. Possible values are taken from OperationalRole enumeration: Operational Service Provider Operational Service Consumer Operational Unanticipated User |
performers: Performer [*] |
Organizational Structure elements grouped by this Operational Node Note: Performer may be any specific element of Performer class: Organization, Organization Type, Role, Person |
activities: OperationalActivity [*] |
Operational Activities grouped by this Operational Node |
implementedBy: SystemsNode [*] |
Systems Nodes from SV-1/SV-2 that support this Operational Node by automation resident at Systems Node |
performs: OperationalActivity [*] |
OperationalActivities performed by this Performer |
Operational Node Usage is a helper element that is needed to show an Operational Node inside other Operational Node. We are using SysML based approach here: parent Operational Node will have a Operational Node Usage as a SysML BlockProperty. The type of the Operational Node Usage will be child Operational Node.
Derives from SysML BlockProperty (extends Property).
Note. Semantically this is the same as Part in UML composite structure diagrams.
operationalRole: OperationalRole |
Defines an operational role that is applied to Operational Node Usage. Possible values are taken from OperationalRole enumeration: Operational Service Provider Operational Service Consumer Operational Unanticipated User |
Organizational Resource Usage is a helper element that is needed to show an Organizational Resource inside Operational Node. We are using SysML based approach here: parent Operational Node will have an Organizational Resource Usage as a SysML BlockProperty.
Derives from SysML BlockProperty (extends Property).
Note. Semantically this is the same as Part in UML composite structure diagrams.
Service Specification is used to define Interfaces provided through the Soa Service and/or used by the Soa Service. Parts of Service Specification are typed by these Interfaces and represent potential users and providers of the Soa Service. Service Specification may have associated Behavior for denoting the order of invocation of operations on it.
Extends UML Class.
serviceDescription: string[1] |
The description of the Soa Service or a link to a formal Soa Service description |
The service model element provides the end-point for service interaction. Soa Service can be owned by a Service Provider or a Service Consumer. The type of Soa Service should be Interface or Service Specification. Interface should be chosen as a type of Soa Service if there is no protocol for using the Soa Service. Service Specification should be chosen as a type for Soa Service if there is protocol for using the Soa Service.
Extends UML Port.
Figure 8 OV-2 profile diagram
It is recommended at first to create the OV-2 Operational Node Connectivity Descriptions with main Operational Nodes. You will create main Operational Nodes, Needlines, Information Exchanges, etc.
If you have composite structure for the Operational Nodes, you need to create an OV-2 Operational Node Internal Connectivity Descriptions for the Operational Nodes that have sub nodes. Sub nodes will be created as Operational Node Usages in the parent Operational Nodes. Child Operational Node will be set as type for the Operational Node Usages.
Node’s internal diagram can be easily created from an Operational Node (context menu -> New Diagram -> OV-2 Operational Node Internal Connectivity Description).
There are several ways to create the Information Exchanges:
Drag the Information Element onto the Needline
Right click on the Needline->Information Exchanges->New
Create new Information Exchange from the Needline’s specification window, “Information Exchanges” node.
Information Elements (according to [DoDAF, v.10, Vol. II]) should be defined in the OV-3. However, because of implementation specifics, in MagicDraw Information Elements have to be defined in OV-2.
It is not necessary to define performed Operational Activities, however you can show them using the Note.
<<< PLEASE add instructions on adding "operational node usage" and "organizational node usage" >>>
<<< Please show examples of how usage looks. >>>
<<<Please add an example of Operational Activities in a Note >>>
Modeling service architectures
OV-2 product may be used for modeling service architectures. Operational Node and sub nodes (Operational Node Usages) have “Operational Role” property that allows you to specify the responsibility Operational Node plays: Operational Service Consumer, Operational Service Provider or Operational Unanticipated User.
Operational Service Consumer and Operational Service Provider can communicate only via Soa Service. Since Soa Service extends UML Port Operational Service Provider and Operational Service Consumer should be realizing classifiers of the same component. To model this on OV-2 Operational Node Connectivity Description diagram create Component and drag on it Operational Nodes. Operational Nodes will become realizing classifiers of the same Component and you will be able to connect their Soa Services using Needline [connector] relationship.
The type of Soa Service can be UML Interface or Service Specification. Use Service Specification when there is behavior for using Soa Service. After behavior addition you may detail it using any type of behavior diagram. After this double-click on Service Specification will open not Service Specification specification dialog but associated behavior diagram.
Organizational structure items from OV-4 may be set as performers for Operational Node, showing that they are performing at this node.
Operational Activities from OV-5 may be set as activities for Operational Node, showing that they are performed at this node.
Interface from SV-1 may be set as implementingInterface for Needline, showing that this Needline is implemented by this interface.
Systems Node from SV-1 may be set as realizedBy for Operational Node, showing that this Operational Node is realized by Systems Node.
Information Exchange may have relations to Operational Activities from OV-5 through consumedBy and producedBy properties, showing that it is consumed or produced by Operational Activities.
System Data Exchange from SV products is tied to Information Exchange using the implementedBy property.
Information Element caried by Information Exchange is assigned view informationElement property.
Figure 9 OV-2 sample
“The Operational Information Exchange Matrix details information exchanges and identifies “who exchanges what information, with whom, why the information is necessary, and how the information exchange must occur” [CJCSI 6212.01B, 2000]. There is not a one-to-one mapping of OV-3 information exchanges to OV-2 Needlines; rather, many individual information exchanges may be associated with one Needline. [DoDAF, v1.0, Vol. II]
OV-3 is a document, which is implemented as MagicDraw report, using model information mainly from OV-2. After OV-2 is done, user can generate a document for OV-3.
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
Information Exchange |
<<InformationExchanget>> [InformationFlow] |
|
Information Element |
<<InformationElement>> [Class] |
|
System Data Element |
See SV-6 data element definition |
Information Exchange shows information that is exchanged by two Operational Nodes via the Needline. An Information Element will show the kind of information that is exchanged. According to [DoDAF, v.10, Vol. II], Information Exchange should be modeled in the OV-3. However in MagicDraw it is modeled in OV-2, while OV-3 is just document generated from OV-2.
Extends UML InformationFlow.
protectionSuspenseCalendarDate: String |
The calendar date on which the designated level of safeguarding discontinues |
protectionTypeName: String |
Name for the type of protection |
classificationCaveat: String |
A set of restrictions on information of a specific classification; supplements a security classification with information on access, dissemination, and other types of restrictions |
protectionDuration: String |
How long the information must be safeguarded |
transactionType: String |
Descriptive field that identifies the type of exchange |
accountability: String |
Security principle that ensures that responsibility for actions/events can be given to an organization willingly or by obligation |
classification: String |
Classification code for the information |
periodicity: String |
How often the Information Exchange occurs; may be an average or a worst case estimate and may include conditions (e.g., wartime or peacetime) |
timeliness: String |
Required maximum allowable time of exchange from node to node (in seconds) |
criticality: String |
The criticality assessment of the information being exchanged in relationship to the mission being performed |
IADisseminationControl: String |
The kind of restrictions on receivers of the information based on sensitivity of information |
IAAccessControl: String |
The class of mechanisms used to ensure only those authorized who can access information |
IAConfidentiality: String |
The kind of protection required for information to prevent unintended disclosure |
IAAvailability: String |
The relative level of effort required to be expended to ensure that the information can be accessed |
IAIntegrity: String |
The kind of requirements for checks that the content of the information has not been altered |
identifier: String |
Identifier for the Information Exchange – usually based on the relevant Needline identifier |
mission: Mission |
Joint Mission Area, cross-mission area domain, Universal Joint Task List activity, related specific scenario, or other task-related basis of the architecture |
interoperabilityLevelRequired: String |
Level of Information Systems Interoperability (LISI), or other interoperability measure, required |
informationElement: InformationElement [1] |
Information being carried by this Information Exchange |
implementedBy: SystemDataExchange [*] |
A list of System Data Exchanges that implement this Information Exchange |
consumedBy: OperationalActivity [*] |
A list of Operational Activities that consume information |
producedBy: OperationalActivity [*] |
A list of Operational Activities that produce information |
Information Element describes information that is used in the DoDAF model.
Extends UML Class.
identifier: String |
Identifier for the Information Element – usually based on the relevant Information Exchange identifier; should be unique for the architecture |
accuracy: String |
Description of the degree to which the information conforms to actual fact as required by Operational Node |
language: String |
Identifier/name of codes of the natural language(s) involved in the information exchange; relevant for multinational operations |
content: String |
The content of the Information Element (i.e., actual information to be exchanged) |
scope: String |
Text description of the extent or range of the Information Element content |
implementedBy: SystemDataElement [*] |
A System Data Element that implements this Information Element |
informationExchange: InformationExchange [*] |
Information Exchanges via which this Information Element is exchanged |
Figure 10 OV-3 profile diagram
OV-2 has to be created upfront in order to generate the OV-3.
If OV-2 is created according to MagicDraw’s suggested way – Needlines, Information Exchanges and Information Elements are fully described, there is nothing more to model in order to get the OV-3. OV-3 just gathers information about Information Exchanges, Information Elements and attributes of Information Exchange and generates the document. Report may be generated for whole model or for selected scope.
In Operational Information Exchange Matrix report information about Information Exchange attributes are grouped according to Information Exchange attributes types:
Information Exchange Associations section associates Information Exchange with producing and consuming Operational Nodes and Operational Activities.
Information Element Description section provides information about specific attributes of Information Element: name, identifier, content, scope, accuracy, and language.
Nature of Transaction section includes the list of Information Exchange attributes that specifies nature of transaction: mission/scenario UJTL or METL, transaction type, interoperability level required, and criticality.
Performance Attributes section defines Information Exchange performance attributes: periodicity and timeliness.
Information Assurance section lists Information Exchange information assurance attributes: access control, availability, confidentiality, dissemination control, and integrity.
Security section presents Information Exchange security attributes: accountability, protection (type name, duration, date), classification, and classification caveat.
In each section items are sorted according to Information Exchange identifier.
User can customize report by selecting Information Exchange attributes sections that should be included to the report. Inside each section the list of Information Exchange attributes can also be customized.
OV-3 uses most of the OV-2 information – Needlines, Operational Nodes, and Information Elements.
Figure 11 OV-3 sample
“The Organizational Relationships Chart illustrates the command structure or relationships (as opposed to relationships with respect to a business process flow) among human roles, organizations, or organization types that are the key players in architecture. This product clarifies the various relationships that can exist between organizations and sub-organizations within the architecture and between internal and external organizations.” [DoDAF, v1.0, Vol. II]
OV-4 is a diagram that is based on the UML class diagram.
User also may use:
Regular UML Class Diagram
SysML Block Definition Diagram
Any other MagicDraw diagram
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
Performer |
<<Performer>> [Class] |
N/A |
Organization |
<<Organization>> [Class] |
|
Organization Type |
<<OrganizationType>> [Class] |
|
Role |
<<Role>> [Class] |
|
Person |
<<Person>> [Class] |
|
Responsibility |
<<Responsibility>> [Class] |
|
Organizational Relationship |
<<OrganizationalRelationship>> [Usage] |
N/A |
Direct Organizational Relationship |
<<Direct>> [Usage] |
N/A |
Indirect Organizational Relationship |
<<Indirect>> [Usage] |
N/A |
Coordination Organizational Relationship |
<<Coordination >> [Usage] |
N/A |
Situation Dependent Organizational Relationship |
<<SituationDependent>> [Usage] |
N/A |
Contributing Organizational Relationship |
<<Contributing>> [Usage] |
N/A |
Backup Organizational Relationship |
<<Backup>> [Usage] |
N/A |
Operational Node |
See OV-2 data element definitions |
|
Operational Activity |
See OV-5 data element definitions |
This is an abstract stereotype that is a parent for all Organizational Structure elements. Only elements derived from Performer are capable to perform Operational Activity.
Derives from SysML Block (extends UML Class).
performsAt: OperationalNode [*] |
Operational Nodes that this Performer is performing at |
performs: OperationalActivity [*] |
Operational Activities that are performed by this Performer |
An Organization represents a group of people or organizations that are related for a particular purpose. An Organization element defines a concrete organization, not a generic type.
Derives from Performer.
militaryServiceType: MilitaryServiceKind |
Military service type. Possible values are defined in the MilitaryServiceKind enumeration: Army Navy Air Force Marine Corps Joint |
code/symbol: String |
Service office code or symbol |
responsibility: Responsibility |
Responsibility of the described Organization |
type: OrganizationType [1] |
Type of this Organization |
A type of the Organization.
Derives from Performer.
A function within Organization or Organization Type.
Derives from Performer.
responsibilities: Responsibility [1..*] |
Responsibility of the described Role |
persons: Person [*] |
Persons who are assigned to perform this Role |
An abstract stereotype for defining entities that are capable to perform the Operational Activity.
Derives from SysML Block (extends UML Class).
performsAt: OperationalNode [*] |
OperationalNodes hosting this Performer |
performs: OperationalActivity [*] |
OperationalActivities performed by this Performer |
An actual person within Organization.
Derives from Performer.
responsibilities: Responsibility [*] |
Responsibilities of the Person |
roles: Role [*] |
Roles that Person is assigned to perform |
Responsibility assigned to an Organization, Role, or Person.
Extends UML Class.
persons: Person [*] |
Persons that are assigned to perform Responsibility |
roles: Role [*] |
Roles that are assigned to perform Responsibility |
Generic relationship used for connecting OV-4 elements. Possible types of organizational relationships:
Direct Organizational Relationship
Indirect Organizational Relationship
Coordination Organizational Relationship
Situation Dependent Organizational Relationship
Contributing Organizational Relationship
Backup Organizational Relationship
All organizational relationships extend UML Usage.
Figure 12 OV-4 profile diagram
There is nothing fancy with OV-4 creation. Use the OV-4 specific diagram toolbar when creating the Organizational Relationship Charts.
If you have created OV-4 elements in other products, for example as performers in OV-5, simply drag them into the OV-4 from model browser.
Every Performer in OV-4 may have relations to Operational Nodes from OV-2, showing what Operational Nodes it performs at (property performsAt).
Every Performer in OV-4 may have relations to Operational Activities from OV-5, showing what Operational Activities are performed by it (property performs).
Figure 13 OV-4 sample
“The Operational Activity Model describes the operations that are normally conducted in the course of achieving a mission or a business goal. It describes capabilities, operational activities (or tasks), input and output (I/O) flow between activities, and I/O flows to/from activities that are outside the scope of the architecture. High-level operational activities should trace to (are decompositions of) a Business Area, an Internal Line of Business, and/or a Business Sub-Function as published in OMB’s Business Reference Model [OMB, 2003]”. [DoDAF, v1.0, Vol. II]
As OV-5 should show hierarchies and flows of the Operational Activities, there is no single UML/SysML diagram that is able to do so. Therefore we suggest having two different products of the OV-5:
OV-5 diagram that is based on UML Class diagrams to define the hierarchy of Operational Activities.
OV-5 diagram that is based on UML Activity diagrams to define the flow of the Operational Activities.
User also may use:
Regular UML Class Diagram
Regular UML Activity Diagram
SysML Block Definition Diagram
SysML Activity Diagram
Any other MagicDraw diagram
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
Operational Activity |
<<OperationalActivity>> [Activity] |
|
Information Flow |
<<InformationFlow>> |
N/A |
Capability |
<<Capability>> [Use Case] |
|
Operational Activity Action |
<<OperationalActivityAction>> [CallBehaviorAction] |
N/A |
Operational Node |
See OV-2 data element definitions |
|
Information Exchange |
See OV-3 data element definitions |
|
Information Element |
See OV-3 data element definitions |
|
Performer |
See OV-4 data element definitions |
|
System Function |
See SV-4 data element definitions |
Operational Activity is an activity or process performed by Performer.
Extends UML Activity.
levelIndentifier: String |
If using hierarchical decomposition of activities: Identifier that corresponds to the activity’s place in the activity hierarchy – should be unique |
cost: float |
Cost for activity derived from or used in activity-based cost analysis |
parent: OperationalActivity [0..1] |
Parent Operational Activity |
subactivity: OperationalActivity [*] |
Child Operational Activities |
consumes: InformationExchange [*] |
Information Exchanges consumed by this Operational Activity |
produces: InformationExchange [*] |
Information Exchanges produced by this Operational Activity |
performedBy: Performer [*] |
Performers of this Operational Activity. |
performedAt: OperationalNode [*] |
Operational Nodes at which this Operational Activity is performed |
implementedBy: SystemFunction [*] |
System Functions that implement this Operational Activity |
capability: Capability [*] |
Capabilities to which this Operational Activity belongs |
Relationship in OV-5 Operational Activity Flow used to show the Information Flows between Operational Activities.
Extends UML ControlFlow, UML ObjectFlow.
type: InformationElement [1] |
Information Element carried by flow. |
The Capability of the subject system describes a function or action that the system can perform.
Extends UML UseCase.
mission: Mission |
Joint Mission Area, cross-mission area domain, Universal Joint Task List activity, related specific scenario, or other task-related basis of the architecture |
operationalThread: OperationalActivity [*] |
Operational Activities to which Capability is related |
Call action that invokes Operational Activity directly.
Extends UML CallBehaviorAction.
Figure 14 OV-5 profile diagram
We do recommend starting with the OV-5 Operational Activity Flow, because MagicDraw will be able to create OV-5 Operational Activity Hierarchy automatically from the data in the OV-5 flow definition.
OV-5 Operational Activity Hierarchy
Use OV-5 specific toolbar to create hierarchies of the Operational Activities. Use Composition (Associaton) as main path between Operational Activities. As UML Activity is a UML Classifier, it can be used in the structure diagrams.
Capabilities may also be modeled in the OV-5 Operational Activity Hierarchy.
OV-5 Operational Activity Flow
This is very similar to UML Activity diagram. Drawing Operational Activities will result in creation of Call Behavior Actions with Operational Activity assigned as behavior.
Operational Activities may have consumed or produced Information Exchanges from OV-2 (properties consumes and produces).
Operational Activities are performed at Operational Nodes from OV-2 (property performedAt)
System functions from SV-4 are implementing the Operational Activities (property implementedBy)
Operational Activity may be performed by Organizational structure elements in OV-4 (property performedBy)
Figure 15 OV-5 sample (hierarchy)
Figure 16 OV-5 sample (flow)
“The Operational Rules Model specifies operational or business rules on an enterprise, a mission, operation, business, or architecture. While other OV products (e.g., OV-1, OV-2, and OV-5) describe the structure of a business—what the business can do—for the most part, they do not describe what the business must do, or what it cannot do.” [DoDAF, v1.0, Vol. II]
Operational Rule is implemented as UML Constraint in MagicDraw, so every DoDAF element in MagicDraw project can have an Operational Rule assigned.
OV-6a is a document, which is implemented as MagicDraw report, using model information mainly from OV products.
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
Operational Rule |
<<OperationalRule>> [Constraint] |
|
Rules are statements that define or constrain some aspect of the mission, or the architecture. It is intended to assert operational structure or to control or influence the mission thread.
Extends UML Constraint.
type: RuleType [1] = Structural Assertion |
Operational Rule type. Possible values are defined in the RuleType enumeration: Structural Assertion Action Assertion Derivation |
Figure 17 OV-6 profile diagram
In general OV-6a is just a collection of Operational Rules (UML Constraints) from the model compiled in a document. Report may be generated for whole project or for selected scope.
An Operational Rule can be applied to any element in the DoDAF model.
In Operational Rules Model report Operational Rules are grouped according to type:
Structural assertions are added to “Structural Assertions” section of the report.
Action assertions are added to “Action Assertions” section of the report.
Derivations are added to “Derivations” section of the report.
Inside each group Operational Rules are listed in numbered manner and sorted according to Operational Rule name. Below each Operational Rule name constraint specification and information about constrained elements is provided.
User can customize report by selecting the type of Operational Rules, for which report should be generated. The list of constrained elements may also be included optionally.
The OV-6a is a collection of Operational Rules from the rest of the model.
Figure 18 OV-6a sample
“The Operational State Transition Description is a graphical method of describing how an operational node or activity responds to various events by changing its state. The diagram represents the sets of events to which the architecture will respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action.
An Operational State Transition Description can be used to describe the explicit sequencing of the operational activities. Alternatively, OV-6b can be used to reflect the explicit sequencing of actions internal to a single operational activity or the sequencing of operational activities with respect to a specific operational node”. [DoDAF, v1.0, Vol. II]
OV-6b is a diagram that is based on UML State Machine diagram.
No additional mapping to UML is needed for producing OV-6b.
This product is created as a UML State Machine diagram.
Operational Activities from OV-5 may be set as activities for the state’s Entry, Do Activity and Exit Actions.
Operational Nodes from OV-2 may have state machines as UML property Owned Behavior.
Information Elements from OV-3 may have state machines as UML property Owned Behavior.
Organizational structure elements from OV-4 may have state machines as UML property Owned Behavior.
Operational Activities from OV-5 may have state machines as UML property Owned Behavior.
Figure 19 OV-6b sample
“The Operational Event-Trace Description provides a time-ordered examination of the information exchanges between participating operational nodes as a result of a particular scenario. Each event-trace diagram should have an accompanying description that defines the particular scenario or situation.
OV-6c is valuable for moving to the next level of detail from the initial operational concepts. The product helps define node interactions and operational threads. The OV-6c can also help ensure that each participating operational node has the necessary information it needs at the right time in order to perform its assigned operational activity.
OV-6c can be used by itself or in conjunction with OV-6b to describe the dynamic behavior of business processes or a mission/operational thread.” [DoDAF, v1.0, Vol. II]
OV-6c is a diagram that is based on UML Sequence diagram.
No additional mapping to UML is needed for producing OV-6c.
This is a regular UML sequence diagram. In order to create lifelines you may drag objects from other DoDAF products from the data browser to this diagram.
Operational Nodes from OV-2 may be used as types for the interaction attributes that will be set as represents property for the lifelines in OV-6c.
Figure 20 OV-6c sample
“The Logical Data Model describes the structure of an architecture domain’s system data types and the structural business process rules (defined in the architecture’s Operational View) that govern the system data. It provides a definition of architecture domain data types, their attributes or characteristics, and their interrelationships. OV-7 is an architecture product and describes information about a specific architecture domain. The architecture data elements for OV-7 include descriptions of entity, attribute, and relationship types. Attributes can be associated with entities and with relationships, depending on the purposes of the architecture.” [DoDAF, v1.0, Vol. II]
OV-7 is a diagram that is based UML Class Diagram.
User also may use:
Regular UML Class Diagram
SysML Block Definition Diagram
Any other MagicDraw diagram
DoDAF Element Type |
UML Stereotype [metaclass] |
Notation |
Information Element |
See OV-3 data element definitions |
|
System Data Element |
See SV-6 data element definitions |
Figure 21 OV-7 profile diagram
OV-7 is a regular class diagram with Information Element used instead of a UML Class.
It is likely that a lot of Information Elements will be created by this diagram creation, so user can just drag those elements to the diagram from the browser tree.
Information Elements defined in OV-2/OV-3 are reused in OV-7.
In SV-6 System Data Element may implement Information Element (property implementedBy).
Figure 22 OV-7 sample