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

Content

The following areas contain updates and enhancements:

• UPIA Profile and Model library
• New: Performer type hierarchy
• New: Information
• New: Plan and Plan Activity
• New: Personnel and Actual Personnel
• New: Education and Training
• New: Issue (Conflict and Obstacle modeling)
• New: Information Exchange and Data Exchange properties
• New: Relationships with Location
• New: Relationships with Performer specializations
• New: Viewpoint Method
• Rename: Capability Aggregation to Part Of
• Rename: Relationships with Competence
• Rename: Relationships with Effect
• Rename: Performance measuring types
• Rename: Service to Service Port
• Rename: Technical Standards Profile to Standards Profile
• Enhancement: Concern subject property
• Enhancement: Relationships with Stakeholder
• Enhancement: Relationships with Systems Node
• Enhancement: Service Specifications
• Deleted: Information Element and Data Element properties
• Modeling tools
• UPIA Explore tool custom queries
• New model wizard templates
• BIRT reports
• Extracting diagrams with saved custom queries
• Profile stereotype renaming and deletions

---

UPIA Profile and Model library changes


Version 7.5.4 of the UPIA feature includes updates to the UPIA profile, library, and modeling tools to add support for the new DoDAF 2.0 specification. These changes are based upon the DoDAF 2.0 specification documents (spiral 4) published on December 24, 2008.

New: Performer type hierarchy changes

The UPIA stereotype hierarchy was modified to include the DoDAF 2.0 power types Effect Object, Organizational Resource, Performer and Personnel. The following figure shows a portion of the revised stereotype hierarchy in the UPIA profile.

The stereotypes and relationships in red are new and the stereotypes in green are existing types that have been renamed.

Performer was previously called AbstractNode and it is still an abstract type. In DoDAF 2.0 a performer represents an entity that does something, whereas a Resource is some object that is acted upon.

EffectObject is an abstract type that represents some entity that can be affected by an activity or process of the enterprise. As such, both resources and performers can be affected.

Organizational Resource was previously a specialization of Resource but in DoDAF 2.0, it is a type of Performer, which is a specialization of Resource.

Information is a new DoDAF 2.0 type that represents high level conceptual or domain information. It can be decomposed into more concrete types of information used in the Operational viewpoint (Information Element) or data used in the System viewpoint (Data Element). DoDAF 2.0 has also introduced a new Data and Information Viewpoint (DIV) which has three views:

• DIV-1 is the conceptual data model (shows elements of type Information)
• DIV-2 is the logical data model (shows elements of type Information Element; in DoDAF 1.x this was OV-7)
• DIV-3 is the physical data model (shows elements of type Data Element; in DoDAF 1.x this was SV-11)

Personnel is a new type that can be used to show the decomposition of an organization with respect to its human components. Specific instances of Personnel can also be created by the Actual Personnel type.

CapabilityRole was previously called OperationalCapabilityRole but it was renamed since it can represent a role in either the Operational or System viewpoints.

New: Information

A new type of resource is available called Information. This type represents conceptual or high level domain information, which is different from the logical data represented by Information Elements or physical data represented by Data Elements. The tool for creating Information is available in the Enterprise and Strategic drawers.

Information can also be decomposed as Information Elements or Data Elements using the "Part Of" relationship.

New: Plan and Plan Activity

In the Project Planning drawer, a new Plan type has been added that can contain one or more activities (Plan Activity) that result in a Goal being achieved when the plans are executed. A Plan Activity is owned by the Plan itself. To create the activity, select the Plan and use the context menu. When adding a Plan Activity to a selected Plan on a diagram, the new Plan Activity is added as a child of the Plan but it is not shown on the diagram. You will find the Plan Activity in the Project Explorer.

The existing Project Structure relationship can be used between Projects and Plans to show the decomposition of a Project or it can be used between two Plans. This relationship was changed from a simple association to an aggregation to better show the whole/part structural concept. The Project Phase relationship can be used between Plans to show temporal sequencing.

A Goal can be associated with a Plan Activity (Goal directs Activity) using the Project Planning Relationships tool. A Milestone can also be associated with each Plan.

New: Personnel and Actual Personnel

An organization can now be decomposed into categories of people (Personnel) that perform tasks for the organization. Each category of people provides sets of skills needed to achieve the capabilities of the enterprise. Specific positions within a Personnel category can also be created as an Actual Personnel. The tools for creating Personnel and Actual Personnel are available in the Organizational drawer in the tool stack that contains Organizational Resource.

New: Education and Training

When modeling an enterprise, the realization of a capability may require the education and training of personnel. In the Organizational drawer, a new Education type has been added along with two new relationships: Teaches Skill and Training. These new types are used to model the training of Personnel with the skills that are required for the roles they must play. Education represents a structured process with data for teaching a particular knowledge or skill, indicated by the Teaches Skill association. Training is a directed information flow from the instructor to the student where the information conveyed is the corresponding education. Excluding artificial intelligence systems, training is performed by humans and therefore only Personnel are valid end points of the Training relationship.

New: Issue (Conflict and Obstacle modeling)

When modeling a complex enterprise, there can be situations where there are conflicting goals or some requirement of the architecture cannot be achieved because of some obstacle. When this occurs, it may be necessary to model the issue and how it will be resolved.

A new type called Issue has been added along with two associations: Issue Involves and Issue Resolution. When an issue is created in the model, it has several properties that should be defined:

• The documentation for the issue should provide the necessary details.
• The issue "type" is set to either Conflict or Obstacle (an enumeration).
• The issue "severity" is set to Major, Minor or Potential (an enumeration).
• The issue "category" is a string that the user can define for further classification.

For an Obstacle, the issue is typically connected with a single element using the Issue Involves relationship. For a Conflict, the issue should be connected with two or more other elements, also using the Issue Involves relationship. In either case, one or more elements may be needed to represent the solution to the issue and they are connected with the issue using the Issue Resolution relationship.

In the following diagram, the documentation on Literacy Obstacle might be:

The existing training material is an English manual with written instructions on how to perform certain operations. Each instruction has a screen shot of the menu or dialog that the user must use. In the past this training material has been sufficient but with the proposed expanded market, many of the newer customers do not have a good understanding of the English language and a portion may actually be illiterate. The training material should be updated with video examples and voice-over instructions that can be translated.

New: Information Exchange and Data Exchange properties

In previous releases, an Information Element had two string properties: content and scope. Since a given Information Element may be used in multiple Information Exchanges and the scope and content of that information might differ depending upon the exchange, these two properties were deprecated on the Information Element and added to the Information Exchange. During UPIA model migration, the old values for these properties on Information Element are retained and the user must manually copy those property values to the corresponding exchange properties. Once copied, the user should clear those property values on the Information Element.

Likewise, the string properties formatType and mediaType on Data Element were deprecated and similar properties were added to a Data Exchange. Again, the user will have to manually copy those values from the Data Element to the corresponding exchange properties.

New: Relationships with Location

In previous releases, a Location could only be associated with a Systems Node using the Systems Node Elements relationship. This was too restrictive. A Location can now be indicated for any Performer, or its specializations, a Resource or a Systems Node using the new "Located At" association. Use the relationship tool in the Operational, Organizational, Service or System drawer. As a result of this change, an existing Systems Node Elements association with a Location will generate a validation error. Simply delete the association and recreate the new Located At association.

New: Relationships with Performer specializations

The restructuring of the Performer hierarchy has resulted in several changes to associations that can involve any Performer. The Performer specialization types include Operational Node and its specializations, System and its specializations, and Organizational Resource and its specializations.

• The association Operational Capability Role Resource was used to indicate Resources that would play the corresponding Capability Role. The resources were restricted to a basic Resource or an Organizational Resource. The constraint on this association was modified to allow a Performer or its specializations, which still includes an Organizational Resource but not the basic Resource. Therefore this association was also renamed to "Plays Role".
• The aggregation relationship called "Part Of" can be created between Performers to illustrate the decomposition of a Performer.

New: Viewpoint Method


When a Viewpoint is defined, the user may wish to define the process required to produce the important Views that conform to the Viewpoint. When a Viewpoint is selected, the context menu can be used to add a new Viewpoint Method element as a child of the Viewpoint. Each Viewpoint Method, a UML opaque behavior, can be used to define one such process. When adding a Viewpoint Method to a selected Viewpoint on a diagram, the new Viewpoint Method is added as a child of the Viewpoint but it is not shown on the diagram. You will find the Viewpoint Method in the Project Explorer as a child of the selected Viewpoint.

In addition to owning a Viewpoint Method, a Viewpoint can now be decomposed using the "Part Of" aggregation relationship.

Rename: Capability Aggregation to Part Of

In previous releases two Capabilities could be related using an aggregation such that one Capability is a part of another Capability. This "Capability Aggregation" relationship has been renamed to "Part Of".

In addition, the "Part Of" relationship was enhanced to show decomposition of other UPIA types including Information, Viewpoints and Performers (and their specializations).

Rename: Relationships with Competence

Competence (also known as skill) has two existing relationships and a new relationship. The existing association (Operational Capability Role Competence) between Competence and a Capability Role indicates the skill required by that role in order to achieve the corresponding Capability. The association (Resource Competence) between Competence and a Resource indicates the skill that the Resource can provide.

The two existing associations were renamed to better indicate the type of relationship. Operational Capability Role Competence was renamed to Requires Skill and Resource Competence was renamed to Provides Skill. In addition, the constraint on the Provides Skill association now allows a Performer or a specialization meaning Operational Nodes, Systems, Organizational Resources, Personnel and Stakeholders can all be modeled as providing skills.

The new Teaches Skill association is used in conjunction with the new Training relationship between two Personnel elements. When Training is performed, Education flows from the instructor to the student, where that education teaches a particular skill that the student requires. The Teaches Skill association connects the Education element to the skill that it teaches.

Rename: Relationships with Effect

In UPIA an Effect is an action or a behavior that brings about a change in the state of something. In previous releases, an Effect object could be associated with a Resource to indicate the resource is influenced by the Effect. This relationship was maintained by two stereotype properties: an "effect" property on the Resource and a "resources" property on the Effect. An Effect object could also be associated with an Operational Node either by a stereotyped directed association to the Effect object (Node Causes Effect) or by a stereotyped directed association to the Operational Node (Effect Affects Node).

In this release, the cross referencing properties on Effect and Resource were deleted and the stereotyped directed associations were renamed respectively to Creates Effect (Node Causes Effect) and Effect Impacts (Effect Affects Node). In addition, the constraints on these associations now allow a Resource or its specializations. Therefore, these two associations can now be created between an Effect and any Performer, including Operational Nodes, Systems and Organizational Resources. These associations can be created by the relationship tools in the Operational, Organizational, Service and Systems drawers.

Rename: Performance measuring types

The names of UPIA types for doing performance measuring were too specific. Besides performance criteria, such as maintainability, operational costs and physical measures, there are other kinds of measurements that are important. Although the existing UPIA types did not prevent the defining of these types of measures, their names could be confusing to the user.

As a result, the names of the UPIA types for modeling measurements were made more generic and were renamed as follows:

• Performance Parameter Set becomes Measure Type
• Performance Parameter Type becomes Measure Attribute
• Performance Measurement Set becomes Actual Measure

A Measure Type (UML Class) can define one or more Measure Attributes (UML Property) with default values. An Actual Measure is a UML Instance Specification whose classifier must be a Measure Type and each Actual Measure can define specific slot values for the Measure Attributes that are owned by its corresponding Measure Type.

A new string property called "category" was added to the Measure Type stereotype, which enables users to indicate the classification of the measure, such as performance, maintainability or operational cost. Consistent names should be used in this category property so that related measures can be easily extracted into a BIRT report.

In addition, the Performance Elements context menu was renamed to Measurement Elements and the UPIA Performance diagram palette drawer was renamed to UPIA Measurement.

Rename: Service to Service Port

To be consistent, the UPIA type for defining a port that is used in Service modeling was renamed from Service to Service Port.

Rename: Technical Standards Profile to Standards Profile

The UPIA types for doing standards modeling are generic, except for the name of the Technical Standards Profile. The architecture may require other types of standards profiles such as a functional standards profile. To enable the modeling of functional standards and other types of standards, several changes were made.

The Technical Standards Profile type was renamed to a Standards Profile and it still refers to one or more of its related Standards. A new string property called "category" was added to the Standard stereotype to allow the user to define classifications of standards. Consistent names should be used in this category property so that related standards can be easily extracted into a BIRT report.

A Forecast can still be associated with a Standards Profile to define temporal information about the standards.

Enhancement: Concern subject property

A Concern is a UML Use Case element which can be related to a Stakeholder and a Viewpoint. Its purpose is to define an interest in some subject (the Viewpoint) that is held by one or more Stakeholders.

The UML "subject" property on the Concern element should identify what the Stakeholder is interested in, namely the corresponding Viewpoint. However, in previous releases, the subject property on the Concern was set to the Stakeholder. When a Concern is now associated with a Viewpoint, the subject property of the Concern will contain a reference to that Viewpoint. Conversely, when a Concern is associated with a Stakeholder, the subject property is no longer set.

When model validation is performed on a Concern, a warning will occur if the subject property still includes a Stakeholder. If the "viewpoint" property on Concern refers to at least one Viewpoint and the Concern's subject property does not contain a Viewpoint reference, a validation error will occur. In both cases, use the UML Properties dialog on the Concern to fix up the subject property references. When an element reference is either added or removed from a Concern's "subject" property, the corresponding "useCase" property on that referenced element will automatically be set to the Concern element.

Enhancement: Relationships with Stakeholder

Stakeholder has always been a specialization of an Organizational Resource yet the various relationships defined for an Organizational Resource were not applicable for a Stakeholder. With the addition of Personnel as another specialization of Organizational Resource, the relationships that can involve an Organizational Resource were extended to its specializations: Personnel and Stakeholder.

The following diagram shows the Organizational Resource relationships that can now be defined with a Stakeholder.

Enhancement: Relationships with Systems Node

In UPIA a Systems Node is used to model high level deployment schemes. In previous releases there were two associations that could link a Systems Node to other UPIA elements.

• Systems Node Elements is used to indicate Systems that are deployed or associated with a Systems Node.
• Systems Node Materiel is used to indicate a System associated with a Systems Node that represents some type of materiel.

In previous releases, the constraints on both of these associations were identical. With the new stereotype hierarchy, the constraints have been modified and made more exact.

The Systems Node Elements association now allows a Systems Node to be connected with a Resource, a Performer and its specializations or a System Group. Previously only a Systems Node could be associated with a Location via the Systems Node Elements relationship but in 7.5.4, this will result in a validation error. The new relationship "Located At" has been added and it allows any Performer, Resource or Systems Node to be associated with a Location. To fix an invalid Systems Node Elements association with a Location, simply delete the association and recreate a Located At association using the System Relationships tool.

The Systems Node Materiel association now restricts the materiel to be represented by a System Group or a System and its specializations.

Enhancement: Service Specifications

A Service Specification (interface) defines the contract for a service that is implemented by (provided) or used by (required) Service Participants. In UPIA, a Service Participant is both a specialization of Operational Node and System. As such, the methods defined on the Service Specification should either be Operational Tasks or System Tasks. In this release, the tooling and constraints were modified to allow Operational Tasks or System Tasks to be created on a Service Specification.

This change now allows Service Specifications to be used in Operational Activities, Operational Event Traces, System Functions and System Event Traces. The UPIA activity partition creation tool now allows a Service Specification to be created or an existing one to be referenced by the partition. Call Operation actions in such a partition should correspond to Operational or System Tasks defined on that specification. Likewise, a Service Specification can be used as a lifeline in an Event Trace (sequence) diagram, where call messages target the tasks defined on the specification.

As a result, if Service Specifications are used in activities or sequence diagrams and the operations being called are Operational Tasks, the corresponding activity Operational Information Flow or sequence Task Invocation message will be used in the generation of Information Exchanges by enumerating all Service Participants that implement the Service Specification. Similarly, System Information Flow (activity) edges and Task Invocation messages to System Tasks owned by a Service Specification will be used in the generation of Data Exchanges.

Deleted: Information Element and Data Element properties

An Information Element had a property (operationalInformationFlow) that could refer to an Operational Information Flow (activity Object Flow edge) that passed this element. This property had to be set manually and was redundant because the Information Element has references to the Information Exchanges that it is conveyed in and each Information Exchange has references to its realizing activity edges; the Operational Information Flow edges. The property was deleted from the Information Element.

Likewise, a Data Element had a "systemInformationFlow" property that was redundant, so it was also deleted.

---

Modeling tool changes

UPIA Explore tool custom queries

In previous releases, the Explore tab on a diagram palette contained five UPIA explore tools for updating or populating diagrams with specific types of UPIA elements. Although the names for some of these tools were specific to military standards (OV-2, OV-7, SV-1 and SV-11), the content added to the diagrams is applicable to most enterprise architecture designs.

These four explore tools were replaced by a single tool that is used for custom defined queries. There is only one UPIA Explore palette drawer and it contains two diagram query tools.



The Show Element Types tool is the same as in previous releases. The Custom Queries tool enables either a predefined or a user defined query to update a diagram. When the tool is clicked on a diagram, a dialog appears that allows the user to select which custom query is to be run.



The following predefined queries exist where four of them correspond to the old explore tools:

• Conceptual Data Model
• Conflict and Obstacle Issues
• Logical Data Model (was Update OV-7)
• Operational Resource Description (was Update OV-2)
• Physical Data Model (was Update SV-11)
• System Interface Description (was Update SV-1)

User specific custom queries can be defined using the Preferences dialog and selecting the Modeling > UPIA Modeling > Explore Tools page. This Explore tools preference page only has two tabs: one for custom queries and the other for query that shows selected element types. Although you can create a custom query for each element type combination, the "Show Element Types" tool remains a quick way to populate elements onto a diagram without using the Preferences page.

The custom queries tab of the UPIA Explore Tools preference page enables the user to select and change any custom query, including the predefined ones. New queries can be created or copied from an existing query but only user defined queries can be renamed or deleted.




If the parameters of a predefined query are changed by accident, the default parameters can be reset using the Restore Defaults button when the corresponding query is selected.

If the Custom Query explore tool is run and the corresponding custom query is saved on the diagram, the Outline view will show the name of the query. If the diagram is selected, the main toolbar button to refresh the saved diagram queries will result in the query being run again. When a custom query is saved on a diagram, its parameters are saved with the query, so changing the preferences will not affect the saved query.

All of the custom queries must have a unique identifier, which cannot be changed once the query is created. This query ID is used in conjunction with a new function for BIRT reports called getUPIADiagrams(). One of the parameters of this function indicates the custom query, either by giving the name of the custom query or the query ID. This function will search the given namespace for all diagrams that have a saved query which matches the given indicator. See the BIRT report section below for more information.

New model wizard templates

When creating a new UPIA model, there are now three templates to choose from. These templates provide a basic structure to the model that is simply a guideline. The user can change this structure to suit their modeling style. In addition, some of the templates contain examples of how that structure can be populated with UPIA elements. When the user no longer needs to refer to the example, it should be deleted from the model in order to avoid confusion with the real data.

• UPIA Blank Model

Create a new UML Integrated Architecture (UPIA) model that contains the minimal required structure.
• UPIA Enterprise Model

Create a new UML Integrated Architecture (UPIA) model that is structured for defining an Enterprise architecture. This model contains a parallel Architecture Description hierarchy as an example of the types of elements to create and how to connect them.
• UPIA Solution Model

Create a new UML Integrated Architecture (UPIA) model that is structured for defining architecture solutions. This model contains a package hierarchy that separates the data into logical groups such as the business model, the IT and systems model and the strategic model.

---

BIRT reports

Extracting diagrams with saved custom queries

In previous releases, there was a BIRT function to extract various DoDAF types of diagrams. The function was getDoDAFDiagrams (<namespace>, <diagramType>) where the <namespace> defined the model elements in which to search for diagrams and the <diagramType> was a string that indicated the type of DoDAF diagram to extract. The previously supported DoDAF diagram types were: OV-2, OV-5, OV-6b, OV-6c, OV-7, SV-1, SV-4, SV-10b, SV-10c and SV-11. This BIRT function still exists but it has been replaced with a different function called:

getUPIADiagrams(<namespace>, <diagramType>)

In addition to supporting the old DoDAF diagram type names (above), this new function also extracts three new DoDAF 2.0 types of diagrams. A new Data and Information Viewpoint (DIV) was added with three types of views:

• DIV-1 is the Conceptual Data Model (new in DoDAF 2.0)
• DIV-2 is the Logical Data Model (previously called OV-7)
• DIV-3 is the Physical Data Model (previously called SV-11)

This getUPIADiagrams() function can also extract diagrams with saved custom queries. In this case, the <diagramType> parameter should either be the custom query ID or the query name. When a report is being designed and if there is a chance that the query names may be translated when they are saved on a diagram, then the query ID should be used in this function to extract those diagrams.

All three of the new DIV views correspond to predefined custom queries so any of the old DoDAF types, the new DoDAF types or the custom query ID can be used to extract the corresponding diagrams.

For example, suppose an existing UPIA model already has a diagram with the saved Update OV-7 query (created using the old OV-7 explore tool). This diagram would contain Information Elements that represent the logical data model. The user creates a new diagram in a different part of the model and saves the custom query "Logical Data Model". In the report design, the getUPIADiagrams() function can be called with any of the following <diagramType> strings and both diagrams will be returned:

• OV-7
• DIV-2
• logicaldatamodel
• Logical Data Model

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
AbstractNode		Performer
CapabilityAggregation		PartOf
DataElement	formatType		(deprecated – use "formatType" on Data Exchange)
DataElement	mediaType		(deprecated – use "mediaType" on Data Exchange)
DataElement	systemInformationFlow		(deleted)
Effect	resources		(deleted)
EffectAffectsNode		EffectImpacts
InformationElement	content		(deprecated – use "content" on Information Exchange)
InformationElement	scope		(deprecated – use "scope" on Information Exchange)
InformationElement	operationalInformationFlow		(deleted)
MeasuredElement	performanceMeasurements	MeasuredElement	actualMeasures
MeasuredElement	performanceParameterSets	MeasuredElement	measureTypes
NodeCausesEffect		CreatesEffect
OperationalCapabilityRole		CapabilityRole
OperationalCapabilityRoleCompetence		RequiresSkill
OperationalCapabilityRoleResource		PlaysRole
PerformanceMeasurementSet		ActualMeasure
PerformanceParameterSet		MeasureType
PerformanceParameterType		MeasureAttribute
Resource	effect		(deleted)
ResourceCompetence		ProvidesSkill
Service		ServicePort
Standard	technicalStandardsProfile	Standard	standardsProfile
TechnicalStandardsProfile		StandardsProfile