Changes to the IBM Rational UML Profile-based Integrated Architecture (UPIA) feature in V8.0.0

Content

The following areas contain updates and enhancements:

• UPIA Profile and Model library
• New: Classified Element
• Deleted: Data security property on Standard and exchanges
• Modeling tools
• UPIA types with UML Component versions
• Hiding Service modeling palette in UPIA models
• SoaML Service ports renamed
• DoDAF 2 Physical Exchange Specification (PES) support
• BIRT reports
• Profile stereotype renaming and deletions
• Example of report modifications for profile changes

---

UPIA Profile and Model library changes


Version 8.0.0 of the UPIA feature includes updates to the UPIA profile, library, and tooling to enhance the support for architectural modeling, such as the DoDAF 2.0 specification.

New: Classified Element


Architectural modeling sometimes requires security classifications to be specified for certain elements. In UPIA, a default Security classifier, with several default attributes, is defined in the UPIA model library. An instance of this Security classifier is created so that specific values can be assigned to the attributes. This Security instance can then be related to other elements. In some cases, the default Security attributes may not be rich enough for some architecture models so a specialization of the Security classifier should be created and custom attributes added. Then, an instance of that specialized Security classifier can be defined with appropriate values for those attributes.

Previously, exchanges (Information Exchange, Data Exchange and Resource Exchange) and Standards, could have references to Security instances. Any UPIA model element can now refer to a single Security instance via the Classified Element stereotype.

Use any of the UPIA relationship tools to connect an element to a Security instance. This gesture automatically applies the Classified Element stereotype to that source element and adds a reference to the Security instance in the "data security" stereotype property. In addition, a dependency from the source element to the Security instance is drawn to represent that reference stored in the stereotype property.

Any given UPIA element can only be associated with a single Security instance or else there could be conflicting classification attribute values.






Deleted: Data security property on Standard and exchanges

With the addition of the new Classified Element stereotype which specifies security attributes, the "dataSecurity" properties were deleted from the types Standard, Resource Exchange and its specializations Information Exchange and Data Exchange.

Modeling Tool changes

UPIA types with UML Component versions

In order to better integrate UPIA models with the deployment modeling feature in the Rational Modeling products, several of the existing UPIA types can now be created as a UML Component.

The following UPIA types can be created either as a UML Class or a UML Component:
Communication System
Network
Organizational Resource
Personnel
Stakeholder
System
System Hardware
System Software

Other UML class-based types, such as Capability Role, can also be components but you must create the UML component element and manually apply the stereotype.



Hiding Service modeling palette in UPIA models


In version 7.5.5.1 of the Rational modeling products, the UPIA feature was integrated with the service modeling feature and the SoaML profile. In a new UPIA model or an existing UPIA model, when a diagram was opened the service modeling palette drawer was available and automatically expanded. This was very annoying.

The Service modeling drawer and its related UI contributions can easily be hidden when a UPIA model is being modified. Select the root element of an existing UPIA model and in the Properties view display the "Capabilities" page. Expand the "Modeling" category and uncheck the "Services Modeling" capability. This change will only affect that UPIA model.

When a new UPIA model is created, this UI capability for Services Modeling is not checked. If you subsequently wish to perform enhanced service modeling in a UPIA model, simply check this "Services Modeling" capability on the root element of the model using the Properties view.



SoaML Service ports renamed


The integration of UPIA and SoaML uses multiple stereotypes to enable elements to behave both as UPIA elements and as SoaML elements. In UPIA, a port on a Participant is stereotyped as a UPIA Service Port and can be used for either providing or requiring interfaces. In SoaML, there is a distinction between providing ports and consuming ports so one of two SoaML port stereotypes are also applied along with UPIA Service Port.

In previous releases, the SoaML Service Point port represented a provider port and a Request Point port represented a consumer port. These SoaML port types have been renamed to just Service and Request.



DoDAF 2 Physical Exchange Specification (PES) support


With each release of UPIA, profile and tooling changes have been made to better support the DoDAF 2.0 specification, which is continually being revised. The version of the specification supported by UPIA is DoDAF 2.01. As part of the DoDAF specification, there is a separate Physical Exchange Specification (PES) which defines the format of an XML based interchange file that must conform to an XML Schema Definition (XSD).

UPIA has two commands available: (1) to export UPIA model elements to a PES XML file and (2) to import data from a PES XML file into a UPIA model. Because UPIA does not completely support the DoDAF 2 meta-model (DM2), on export various PES types will not be generated in the XML file because there is no equivalent mapping in UPIA. Similarly on import, various PES types defined in the XML file will not be imported into the UPIA model.

A separate document describes the mapping between DoDAF 2 meta-model (PES) element types and UPIA element types. This document can be found at the link:

http://www-01.ibm.com/support/docview.wss?rs=0&q1=UPIA&uid=swg27019041

To export UPIA data to a PES XML file, open a UPIA model and either right-click a package in the Project Explorer or on an open diagram. The popup menu is displayed.



Choose the command UPIA Modeling > PES Export and a wizard is displayed with two pages, the first page to select the PES view, which determines the UPIA elements to be exported, and the second page to identify the XML file to be generated.



If a diagram is selected, the view entry "Elements on diagram" exports all of the UPIA elements contained on the diagram that have a mapping to a PES element type. If a diagram is not selected, that view entry is not available.

The view entry "All supported PES elements" exports all UPIA elements, determined by the selected UPIA element and the search scope, that have a mapping to PES element types. For all other view types, the UPIA elements determined by selected element and search scope are exported if they map to a PES element type that is allowed for the corresponding DoDAF view.



On the wizard page used to select the target XML file, the workspace hierarchy is displayed. Either an existing XML file can be selected, or a folder can be selected and the name of a new XML file can be specified. If the target XML file already exists, the PES export operation overwrites that file.

After the XML file is generated, you can select the file in the Project Explorer and in the popup menu, choose the "Validate" command. This command ensures that the generated XML file conforms to corresponding PES XSD. If this validate menu command does not exist, to enable the capability for XML Development, click Window > Preferences > General > Capabilities, and then select XML Development.

To perform a PES import, you must first copy the source XML file into one of the workspace projects. Either in a new or an existing UPIA model, you must select a UML package in the Project Explorer, preferably an empty package. The PES XML file format does not support the UML concept of package hierarchies and namespace ownership of elements. Therefore, all of the imported elements are created in the selected UML package.

With the package selected in the Project Explorer, right-click the UML package and click UPIA Modeling > PES Import. The PES import wizard has a single page, which you use to specify the source XML file to be imported.




All of the PES elements in the XML file that have a mapping to UPIA element types are created in the corresponding package. Each PES element has a unique identifier as does the UML elements. If a UML element of the same type already exists with the same ID in the target UPIA model, that existing UML element will be used instead of creating a new one. Therefore, to ensure all of the data is imported from the XML file, the target UPIA model should be empty. The PES specification only requires these identifiers to be unique within the XML file itself, so if multiple imports are being performed separate empty target UPIA models should be used.

BIRT Reports

Profile stereotype renaming and deletions

The UPIA profile changes have resulted in various stereotypes and properties being renamed or deleted. Although the model migration handles renaming automatically, there is no automated mechanism to find and fix the UPIA type and property references in a BIRT report design. These references must be fixed manually.

For each report design, you must find and update all the affected UPIA types and properties. You can use the Report Design editor to update these references, or you can open the report design file with a text editor and manually fix the names.

The following is a summary of the UPIA types and properties that were renamed or deleted in this release of the product:

Old Type Name	Old Property Name	New Type Name	New Property Name
DataExchange	dataSecurity	ClassifiedElement	dataSecurity
InformationExchange	dataSecurity	ClassifiedElement	dataSecurity
ResourceExchange	dataSecurity	ClassifiedElement	dataSecurity
Standard	dataSecurity	ClassifiedElement	dataSecurity

In addition, the SoaML ServicePoint type was renamed to Service and the RequestPoint type was renamed to Request. Since the SoaML profile may not be applied to a UPIA model (service modeling is an optional feature in the Rational modeling products), expressions in a UPIA BIRT report template should refer to the UPIA service related stereotypes instead of the SoaML stereotypes. Consult the UPIA Reference manual.



Example of report modifications for profile changes


If you do not modify an existing BIRT report template, there are several basic types of problems that you might encounter when generating a report for a UPIA model.

a) If an old stereotype name is referenced in the row mapping expression of a data set, the evaluation will not match any elements and the table in the generated report will be empty.

b) If a column mapping expression refers to a valid stereotype property using the old stereotype name, the evaluation will not find that property on the corresponding element and the resulting column will be empty.

c) If a column mapping expression refers to a stereotype property that has been renamed or deleted, the generation of the report will fail with an IllegalArgumentException indicating the invalid stereotype property name.

Based on the changes made to the UPIA profile in this release, only problem (c) can occur.

Suppose a report template from a previous release has a data set, Standard_DS, with the following row expression and column expressions (column types are all String):

Standard_DS:

Row: getElementsWithStereotype(//*, "UPIA::Standard")
name: @name
security: getStereotypePropertyValue(., "UPIA::Standard::dataSecurity")/@name

Suppose the model being reported has at least one Standard element with a related Security instance.

Without any report template changes, the first report generation attempt will fail with an IllegalArgumentException for the property “dataSecurity” because that property is no longer defined on the Standard stereotype.

The stereotype property referenced in the “security” column expression in the Standard_DS data set is changed to the “UPIA::ClassifiedElement::dataSecurity”. After the change, the report generation does not fail.

The resulting data set for the Standard would be:

Standard_DS:

Row: getElementsWithStereotype(//*, "UPIA::Standard")
name: @name
security: getStereotypePropertyValue(., "UPIA::ClassifiedElement::dataSecurity")/@name

When the report is generated, the expected results are now displayed.