- UPDM: UML Profile for DoDAF and MoDAF
- DoDAF: Department of Defense Architectural Framework
- MoDAF: Ministry of Defence Architectural Framework
- BIRT: Business Intelligence and Reporting Tools
The UML Profile for DoDAF and MoDAF (UPDM) is an international standard accepted by the Object Management Group (OMG) in 2007. UPDM provides an annotative mechanism by which UML or SysML models can describe enterprise architectures consistent with the DoDAF or MoDAF.
The UPDM profile provides many stereotypes. In this document, we are using only those stereotypes necessary to the production of the DoDAF views OV-6c and OV-3. By no means do we suggest that our sample model is complete.
The OV-6c is the DoDAF view that corresponds to the UPDM OperationalEventTrace. In UML terms, an OperationalEventTrace is an interaction between UPDM Operational Nodes (expressed using a UML Interaction).
An OV-3, on the other hand, is the collection of UPDM InformationExchanges and their associated properties, and it is represented in tabular format. UPDM extends the UML InformationFlow to represent an InformationExchange.
Specifically, the UPDM InformationExchange allows the modeler to specify the data being exchanged (a UML Classifier, generally a UPDM InformationElement), the user, and the producer of that data, as well as attributes that describe that exchange.
Three of these attributes enable the modeler to describe the information assurance, security, and transaction properties of that exchange. These attributes are represented in the UPDM model by instances (UML InstanceSpecifications, that is) of the UPDM model library members InformationAssurance, Security and Transaction. Each of these classes has attributes that are realized in the InstanceSpecifications by UML slots and their values. (The fact that these properties are modeled by using InstanceSpecifications allows their reuse by multiple InformationExchanges.)
Although InformationExchanges may be realized in UML Activity diagrams (with activity edges), SysML block diagrams (connectors), or UML Interactions (messages), for the purposes of this example model, you will realize these InformationExchanges by Messages in an Interaction (the OperationalEventTrace).
The scenario that we're using here is a hypothetical weather tracking system. It provides satellite imagery and Doppler imagery to give the user a complete weather picture for a specified location.
- The first step in modeling this system is to create a UML project in IBM® Rational® Systems Developer in the Modeling perspective (Figure 1).
Figure 1. Creating a UML project
- Then, in the resulting wizard (Figure 2), name the project
Figure 2. Naming the project
- Next, select the UPDM Enterprise Model template.
Figure 3. Selecting the template
- Click Finish. In the Project Explorer, you should see a new project called Wx Tracking created and a new UML model (also named Wx Tracking), as Figure 4 shows.
Figure 4. New Wx Tracking project and UML model
By using the UPDM Enterprise template, you have a prepopulated model structure. At the root of the model is a new UPDM Enterprise, 00-Wx tracking. For this article, you’ll be working primarily in the Operational View (specifically, Wx Tracking-Enterprise Model::00-Wx Tracking Enterprise Architecture::03-Wx Tracking Operational Concepts).
- Expand the Operational view so that you can navigate to the 03-OperationalNodes package (Figure 5).
Figure 5. Finding the 03-OperationalNodes package
- Double-click the Operational Nodes diagram to open it (Figure 6).
Figure 6. Opening the Operational Nodes diagram
Then, from the UPDM Operational toolbox, create three OperationalNodes, and name them as the diagram in Figure 7 shows:
Figure 7. Three new operational nodes
These OperationalNodes will be collaborating to realize the operational capability of providing comprehensive weather imagery (more on this later).
At this point in the analysis, however, you can begin to describe what information is exchanged by these OperationalNodes to accomplish this mission. One information exchange will be between the WeatherControlCenter and the GroundStation. Our notion of this exchange is that the WeatherControlCenter will provide a location that needs weather data. This will be true, as well, for WeatherControlCenter and the DopplerControlCenter. With this in mind, create a new InformationElement called Location by using the InformationElement tool from the UPDM Operational toolbox (Figure 8).
Figure 8. New information element named Location
- Now, using the Operational Relationships tool (also from the UPDM Operational toolbox), create new InformationExchange relationships from the WeatherControlCenter to the DopplerControlCenter, and from the WeatherControlCenter to the GroundStation, each time referencing the existing Location information element.
Upon completion, your diagram now looks like Figure 9.
Figure 9. New operational relationships
We expect that the DopplerControlCenter will be providing DopplerData back to the WeatherControlCenter. Likewise, the GroundStation will be providing SatelliteData back to the WeatherControlCenter.
- Therefore, create the InformationElements SatelliteData and DopplerData, and then create the appropriate InformationExchanges from the GroundStation and the DopplerControlCenter back to the WeatherControlCenter.
After completing this action, your diagram should now be complete (Figure 10).
Figure 10. Completed diagram
- We can tidy up this model by creating a new OV-7 operational view and by relocating the InformationElements to that package by dragging them in the Project Explorer (Figure 11).
Figure 11. Relocating the information elements to the new view
- After relocating these InformationElements to the new OV-7, you can clean up your operational node diagram to show only the information exchanges by selecting Remove from diagram to remove the InformationElements.
Figure 12. Removing the information elements from the diagram
- Given these InformationExchanges, you can provide additional information regarding the nature of those exchanges. Specifically, you can select the Location InformationExchange and see its advanced properties in the Properties view (Figure 13):
Figure 13. Advanced properties of the Location information exchange
- Select the Value field for the information exchange ID property, and provide a value of
- Similarly, provide a value for the Periodicity property of on-demand, and a Timeliness value of real-time. These are string values. The remaining properties (data security, information assurance, and transaction) display as null. These properties must be set by providing the appropriate InstanceSpecifications.
- Create a new UML class diagram, and name it
- Then, from the UPDM Common toolbox, use the InformationAssurance tool to create a new InformationAssurance instance by using the default classifier from the UPDM model library.
- Name this instance
SatelliteInformationAssurance(see Figure 14).
Figure 14. Creating a new InformationAssurance instance
- Select this new instance, and in the Properties view, navigate to the Slots and Values tab.
Figure 15. Slots and Values tab in the Properties view
- For this model, you’re interested only in the Availability and accessControl properties, so check those boxes. Note that, as a result, the values are prepopulated:
Figure 16. Values for the Availability and accessControl properties
Also note that the Information Assurance diagram has changed, so that these slots now show on the diagram (Figure 17).
Figure 17. Slots added to the Information Assurance diagram
- Provide the value authorizedUser for the accessControl property and the value of on-demand for the Availability property. You should see the diagram and property view in agreement (Figure 18).
Figure 18. Diagram and property views agree
- Now, create a new instance of InformationAssurance on this diagram, and name it
- For this instance specification, as you did before, check the accessControl and Availability slots, and provide values of
- Create the third and final instance of InformationAssurance, and name it
- Select the new instance, and in the Slots and Values tab in the Properties view, check the accessControl and Availability
slots, and provide the values of
Your completed diagram should now show all three instances (Figure 19).
Figure 19. Three instances of InformationAssurance
- Now, create a new diagram, and name it
- Again, from the UPDM Common toolbox, you can create a new Security element (instance specification). Retain the default name of SecurityInstance.
- Select this new element, and, in the Properties view, select the Slots and Values tab, and check the protectionType and protectionName attributes (Figure 20). Provide values of
CRCfor these slots. (It may be necessary to explicitly show the Slots compartment on the Security item on the diagram.)
Figure 20. Values for protectionType and protectionName attributes
- Finally, create a new diagram, name it Transaction, and add a Transaction instance from the UPDM Common toolbox, retaining the default name of TransactionInstance.
- As before, select the new Transaction instance and in the Slots and Values tab of the Properties view, check the transactionType and Criticality attributes, and provide values of
highfor these slots. This will result in the view that Figure 21 shows.
Figure 21. Values for the transactionType and Criticality attributes
With these instance specifications in place, you can now round out the properties of your InformationExchanges.
- Return to the Operational Nodes diagram, and select the InformationExchange named Location once more. Then select the navigation button in the Information Assurance value field
Figure 22. Navigation button in the Information Assurance value field
- Next, navigate to the LocationAssurance instance specification (Figure 23).
Figure 23. The LocationAssurance instance specification
- Select LocationAssurance, and click OK to populate the information assurance property (Figure 24).
Figure 24. Populating the Information Assurance property
- In a similar way, provide the values for the Data security and Transaction properties.
The end result is that the InformationExchange is now fully specified (Figure 25).
Figure 25. Full specifications for the InformationExchange
- Repeat this same sequence (except for the information exchange ID) for the Location1 InformationExchange. (Note how these properties can be reused with multiple model elements, thus leading to a high degree of model consistency.)
Figure 26. Specifications for the Location1 InformationExchange
- Follow a similar path for the SatelliteData InformationExchange (Figure 27),
Figure 27. Specifications for the SatelliteData InformationExchange
- Also follow a similar path for the DopplerData InformationExchange (Figure 28).
Figure 28. Specifications for the DopplerData InformationExchange
At this point, all InformationExchanges have been fully specified.
In UPDM, an OperationalCapability describes, at a high level, a capability of an enterprise. (OperationalCapability extends the UML Use-Case metaclass.) In this Weather Tracking system, one OperationalCapability is that the enterprise can provide comprehensive weather imagery.
- Begin by creating a new OperationalCapability,
Provide Comprehensive Weather Imagery, in the 02-OperationalCapabilities (OV-1) package (see Figure 29).
Figure 29. Creating a new OperationalCapability
This OperationalCapability is realized by a OperationalCapabilityRealization.
- Select the 02-OperationalCapabilities package, and create a new OperationalCapabilityRealization, also named
Provide Comprehensive Weather Imagery.
It's perfectly acceptable to drag both the OperationalCapability and its realization onto the CapabilityUseCases diagram, and then connect them. Likewise, you can add the Local Forecaster, Internet User, and Alert System OperationalCapabilityRoles to this diagram and associate them with the OperationalCapability.
Figure 30. Creating a new OperationalCapabilityRealization
Now, specify how the OperationalNodes collaborate to achieve this realization.
- Select the OperationCapabilityRealization Provide Comprehensive Weather Imagery and right-click it to expose the Option menu. From the Add UPDM menu, select the Operational Event Trace menu item.
Figure 31. Selecting the Operational Event Trace
The result of this action is that an OperationalEventTrace has been created within the OperationalCapabilityRealization. Recall that an OperationalEventTrace extends the UML Interaction. Therefore, you can now model how the OperationalNodes collaborate to realize the OperationalCapability.
- Double-click to open the diagram within the OperationalEventTrace, and drag all three OperationalNodes onto the diagram.
- Select each lifeline created, one by one, and from the Filters submenu on the Option menu, choose the Lifeline Name Label Style > Type Name Only (you'll need to do this for each lifeline individually).
- Then, click all three lifelines, and from the Filters submenu on the Option menu, follow the Stereotype and Visibility Style to select Stereotype: Shape Image.
The result is a clean, uncrowded sequence diagram, as Figure 32 shows.
Figure 32. Updated sequence diagram
Next, describe how these OperationalNodes collaborate to achieve this OperationalCapability.
- Start by simply selecting the :WeatherControlCenter lifeline, and then creating a message to the DopplerControlCenter lifeline. Name the operation
- Create a Location parameter type named
location, and set the return type to DopplerData.
- Create a message from the WeatherControlCenter to the GroundStation, and name the operation
- Provide a Location parameter type named
location, and set its return type to SatelliteData.
- Create a message from the WeatherControlCenter to the GroundStation, and name the operation
- Finally, select the newly created operations on the OperationalNodes, and stereotype them as UPDM OperationalTasks (Figure 33).
Figure 33. Specifying how the OperationalNodes collaborate
At this point, you have described in detail the information exchanges between the operational nodes and created a simple OperationalEventTrace to describe the collaboration of the OperationalNodes in realizing the OperationalCapability.
Notice that all of the information entered is now part of the model and represented as model elements, model element properties, and relationships between the model elements. One distinction between DoDAF and UPDM is that UPDM approaches the problem from the perspective that models are created, properties provided, and relationships set, but the various views that end users need are available by extracting the information specific to that view from the model and displaying it in a format deemed suitable to the end user.
Now you can shift your focus to the extraction of this information and it's aggregation into user-specific views.
The BIRT (Business Intelligence and Reporting Tools) project has produced an open-source Eclipse-based reporting system that you will employ to produce two specific user views based upon information in your model. BIRT is included with IBM Rational Systems developer, as well as IBM-Rational extensions that facilitate reporting using UML models as data sources.
- The first step in producing reports is to create a new reporting project (see Figure 34).
Figure 34. Creating a new reporting project
- Name the project
UPDM Reporting, and click Finish (Figure 35).
Figure 35. Naming the new reporting project
- Clicking Finish completes the wizard and prompts you to switch to the Report Design perspective. After doing that, create a new report (Figure 36).
Figure 36. Creating a new BIRT report
- Name the new report
Figure 37. Naming the new report
- Next, choose a blank report (see Figure 38).
Figure 38. Choosing a blank report
- Click Finish. You should see the new report in the Editor view (Figure 39).
Figure 39. New report in the Editor view
The first step is to create a new data source.
- In the Data Explorer, select the Data Sources category, and invoke the Option menu to create the new data source (Figure 40).
Figure 40. Selecting the option to create a new data source
- Select UML Data Source, and name the source
UPDM model.(We're being rather general here on purpose. After you've developed your report, you 'll be able to direct the report to other UPDM models simply by altering the data source to point to the new model.)
Figure 41. Naming the new data source
- Next, you'll need to choose the model that you're going to be working with (Figure 42).
Figure 42. Choosing the model
- Click Add in the UML data instances region, and browse the workspace to select the Wx Tracking.emx model (Figure 43).
Figure 43. Selecting the Wx Tracking.emx model
- After specifying that model, add the UPDM profile to the List of UML Ecore models in the lower part of the dialog (Figure 44).
Figure 44. Adding the UPDM profile to the Ecore models
- Click Add in the List of UML Ecore metamodels section, and then click Browse Registered Profiles (Figure 45).
Figure 45. Adding the UPDM profile to the Ecore metamodels
- Select UPDM in the resulting dialog (Figure 36).
Figure 46. Selecting UPDM in the dialog
- Complete the dialog by clicking OK.
Now that you have specified this profile, you will see the display shown in Figure 47.
Figure 47. Display after specifying the profile
- Click OK in this dialog to return to the Data Set specification dialog (Figure 48).
Figure 48. Data Set specification dialog
- Click Finish, and your new data source is ready to use:
Figure 49. New data source
The data source the you just created specifies the source of the information that you intend to use for your report.
- Your next step is to create a data set that enables you to define the precise subset of that data source that we need for our report, such as one that you will query (Figure 50).
Figure 50. Defining the data subset that you need for your report
- Name the new data set
Figure 51. Naming the new data set
Next, Figure 52.
Figure 52. Specifying the data instances
Next, Figure 53.
Figure 53. Choosing the UML structure
- Now you'll need to change the table mapping to use the Instance Model, as opposed to the metamodel. Notice the red arrow in Figure 53.
- Construct your query with this command (specified using XPath):
- Then specify that the result is a notation.Diagram (see Figure 54).
Figure 54. The New UML Data Set with the Table Mapping specified
The query that you are creating is a nested query that first asks the data source for all of the elements with the UPDM OperationalEventTrace stereotype, and then for all of the diagrams contained by those elements.
- Validating the XPath query allows you to move to the Next screen in the wizard, where you create the column mapping (Figure 55).
Figure 55. Screen for creating column mapping
- Choose the Name attribute of the diagram (Figures 56 and 57).
Figure 56. Adding the diagram name to the column mapping
Figure 57. The Column mapping with the name added
- Add a new mapping to extract the diagram Binary Large Object, or BLOB (Figure 58).
Figure 58. The Column mapping with the diagram added
Notice the XPath query in the column mapping that retrieves the diagram image is as follows, where the . (period or dot) represents the current node:
Your table mapping query has asked the model for all of the elements with the UPDM stereotype
<<OperationalEventTrace>>. From that, you're
asking for all of the diagrams contained by those elements. In the Column Mapping
page, you're asking for the name of the diagram (a string), as well as
for the diagram image (a BLOB). You will use both of these columns to build
your OV6c report.
- Click Finish to return to the Data Set Definition dialog (Figure 59).
Figure 59. Data Set Definition dialog
Complete the new data set wizard tasks by clicking OK. This action results in the creation of the new data set, as evidenced by the data explorer contents (Figure 60).
Figure 60. Data Explorer contents showing new data set
Now that the data set is defined, the next step is to insert this into the blank report.
- Switch to the Report Design Palette tab, and drag a table onto the blank report.
- Change the Insert Table settings to reflect the following information (also see Figure 61):
Figure 61. Changing the Insert Table settings
- Click OK to get the report design that Figure 62 shows.
Figure 62. Report design
- Now, from the palette, drag an image onto the first detail row. In the resulting dialog, set the image as a Dynamic Image (Figure 63).
Figure 63. Specifying the Image Item properties
- Now, click Select Image Data, and select the Diagram column (ensure that the box is checked on the left, as Figure 64 shows)
Figure 64. Specifying the data binding for the image
- Click OK to close this dialog.
The result shows that the item that you specified is to be used for the image (Figure 65).
Figure 65. Result shows which image to use where
- Click Insert to complete the image specification.
- Return to the Data Explorer.
- Drag the name entry from the OV6c dataset, and then drop it onto the second detail row. This leads to the result that Figure 66 shows.
Figure 66. The table, as shown in the report design
- Finally, double-click the table header column, and insert the OV6c Diagram, which will lead to the final form of your report (Figure 67).
Figure 67. Final form of report
Save the report design, and click the Preview tab to see a preview of our report (Figure 68).
Figure 68. Preview of the report
After a bit of processing, you should see the result (Figure 69).
Figure 69. Final report
Precisely what you need!
- Begin by creating a new report. Name this report
OV3.rptdesign(see Figure 70).
Figure 70. New report named OV3.rptdesign
- Click Finish to create a blank report.
- In the Data Explorer view, select the Data Source
category, and create a new UML data source named
UPDM model(Figure 71).
Figure 71. Creating a new UML data source
- Next, just as you did for the OV6c report, choose the Wx Tracking model and the UPDM profile (Figure 72).
Figure 72. Choosing the model and the profile
- Click Finish, and you will find a new data source called UPDM model created in the Data Explorer (Figure 73).
Figure 73. UPDM model data source shown in the Data Explorer
- In the Data Explorer, select the Data Sets
node, and then create a new data set named
Figure 74. Creating a new data set
- Next, accept the defaults on the next page of the wizard (Figure 75).
Figure 75. Default settings
- Next, to define the table mapping, choose to use the Schema representation in this case, and select all of the UPDM InformationExchanges.
- Validate the XPath expression (Figure 76).
Figure 76. Validating the XPath expression
Next, you need to define the column mapping.
- The first column that you need in your OV3 report is the InformationExchangeId. Select this property from the UML Structure, and click the right arrow to add to the column mapping (Figure 77).
Figure 77. Adding an Information Exchanged column
- Now, expand both the base_InformationFlow and the informationSource nodes, and then select and insert the Name property (Figure 78).
Figure 78. Inserting the Name property
Sourceas the new column name, and then click OK.
Figure 79. Naming the new column
- Do the same for the informationTarget name, renaming
the Column Name to
Figure 80. Renaming the column name for the information target
- Now, expand the base_InformationFlow.conveyed node, select the Name property from the Conveyed (Classifier), and name this column
Figure 81. Renaming the column for the data conveyed
- Finally, add the Periodicity and Timeliness properties as Figure 82 shows.
Figure 82. Adding the Periodicity and Timeliness properties
- Before you complete the column mapping, double-click the informationExchangeId name in the column mapping, and change it to read ID.
Your column mapping should now look like Figure 83.
Figure 83. Updated column mapping
Recall that the other information that you would like to represent in the OV3 report exists as values in the slots for the associated InstanceSpecifications dataSecurity, informationAssurance, and transaction properties.
- Add new mappings to retrieve the values of the informationAssurance slot values accessControl and availability (Figure 84).
Figure 84. Mappings to retrieve the values of the accessControl and availability slots
- Repeat for the protectionType and protectionName slots values from the dataSecurity instance specification (Figure 85).
Figure 85. Mappings to retrieve the values of the protectionType and protectionName slots
- Finally, add mappings for the transactionType and criticality slot values from the Transaction instance specification (Figure 86).
Figure 86. Mappings for the transactionType and criticality slot values
- Ensure that the Type for all of these slot values is set to String in the column mapping dialog. (Scroll the display to the right.)
The OV3 column mappings are now complete.
- Close the Edit Data Set dialog by clicking OK.
- Drag the OV3 data set onto the blank report (Figure 87).
Figure 87. Dragging the data set onto the blank report
- Note that the table default sizes exceed the default width of the report. Change the report width by selecting the Master Page tab, and modifying the properties (also see Figure 88):
- Type: Custom
Figure 88, Modifying the table width to fit within the report
- Switch back to the Layout tab to validate that the table will now fit the page.
- Finally, select the Preview tab to see the newly expanded OV3 report (Figure 89).
Figure 89. Preview of the expanded OV3 report
UPDM provides a high level of specificity for the definition of an enterprise model. UPDM's annotative approach can be exploited for the creation of DoDAF (and MoDAF) products based upon model queries.
This article demonstrated how to create a sample UPDM model and the creation of two DoDAF products, the OV6c and OV3, using the BIRT reporting tools.
- Visit the
Rational software area on developerWorks
for technical resources and best practices for Rational Software Delivery Platform
- The draft UPDM specification is available from the OMG Web site.
- Subscribe to the
developerWorks Rational zone newsletter.
Keep up with developerWorks Rational content. Every other week, you'll
receive updates on the latest technical resources and best practices for the
Rational Software Delivery Platform.
- Browse the
for books on these and other technical topics.
Get products and technologies
trial versions of IBM Rational software.
IBM SOA Sandbox The IBM SOA Sandbox provides a mix of full-version software trials and "try online" hosted environments where you can explore tutorials and get architectural guidance.
- Download the trial
Systems Developer V7.
- Download the trial
Software Architect V7.
IBM product evaluation versions
and get your hands on application development tools and middleware products from
DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
- Check out
get involved in the
Rational Software Architect, Data Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Systems Developer.
Steve is an IBM Rational Lab Services (ISSR) technical representative in the NorthEast. He is a 14 year Rational veteran, and has supported Raytheon, Lockheed-Martin, General Dynamics, BAE Systems, Naval Undersea Warfare Center, among other mil-aero customers over the past 10 years on a variety of products including Rational Apex (Ada), Rational Rose, and most recently Rational Software Architect (RSA). Steve holds a Masters Degree in Physics from the University of Alabama. He has been a developer at Rational, sales technical representative, and is the principal designer and author of the IBM Rational DoDAF plugin. Steve has specialized in the extension of Rational tools to meet customer requirements and drive sales, whether it's writing embedded Ada network drivers, extending Rational Rose, or writing custom Eclipse plugins. He currently resides in Portsmouth, New Hampshire.