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

Content

The following areas contain updates and enhancements:

• UPIA Profile and Model library
• New: Icons for selected types
• New: Task and Project Task
• New: Resource Exchange
• New: Resource Flow
• New: Implements Exchange
• New: Implements Flow
• New: Strategy and Tactics of Project relationships
• New: Consumable
• New: Domain enumeration and Domain Element
• New: Temporal Element
• Rename: Task properties on Policy
• Rename: Capability related types and relationships
• Rename: Systems Node to System Assembly
• Enhancement: Issue relationships
• Enhancement: Depends On relationship
• Enhancement: Location
• Enhancement: Milestone Point relationship
• Enhancement: Plan extension
• Enhancement: Plan Activity extension
• Enhancement: Project Phase relationship
• Enhancement: Rule
• Deleted: Activity Realization relationship
• Deleted: Exchange properties on Data Element and Information Element
• Deleted: Operational Capability Effect relationship
• Deleted: Specialized service producer and consumer types
• Modeling tools
• UPIA models integrated with SoaML profile
• UPIA pop-up menu item for creating relationships
• New UPIA Resource palette
• UPIA Strategic Planning palette renamed
• UPIA Generation of exchanges and resource flows
• UPIA Manual creation of exchanges
• UPIA Logical domain modeling
• Creating new Location type elements
• Indentifying consumable resources
• BIRT reports
• New xpath function for logical domain filtering
• Profile stereotype renaming and deletions
• Example of report modifications for profile changes

---

UPIA Profile and Model library changes


Version 7.5.5.1 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: Icons for selected types


In previous releases, some of the UPIA element types used the same icon representation and other types were using the default UML icon. New icons are used for the following types: Issue, Organizational Resource, Resource, Stakeholder, Network, System Hardware, System Software, Plan Activity and Project Task.




New: Task and Project Task


A new abstract element type, Task, is the supertype for Operational Task, System Task, and the new Project Task. A Project Task is an activity or action that must be accomplished in order for a Project to produce the necessary Resources. The realization of that Project Task is described by the Plan Activity behaviors that are owned by one of the Project's Plans. A Project Task can be owned by Capability Role, Organizational Resource, Personnel and Stakeholder. There are multiple ways to model Organizations and Personnel performing project related tasks. These elements can define the project task, or a Capability Role can define the project task and the personnel or organization can play that role.


In addition, the Task Invocation message in sequence diagrams also supports the calling of Project Tasks. These messages are used by the generation command to create Resource Exchanges.



New: Resource Exchange


A new relationship type, Resource Exchange, was added to model the flow of resources from one performer to another. The existing relationship types Information Exchange and Data Exchange are now specializations of a Resource Exchange. This inheritance allowed many of the duplicate properties defined on Information Exchange and Data Exchange to be moved to the supertype Resource Exchange. These properties include content, dataSecurity, informationAssurance and transaction. The exchange identifier properties, “dataExchangeIdentifier” and “operationalExchangeId”, were also moved to the Resource Exchange as the “exchangeId” property. The UML profile implementation of stereotype specializations results in all of these properties appearing to be defined on the subtypes. Thus DataExchange::exchangeId will contain the unique identifier for this exchange.

The Resource Exchange type also contains two new properties, which will automatically be available on Data Exchange and Information Exchange. These properties, “producingTask” and “consumingTask”, enable the user to perform high level task sketching with exchanges, without having to define the detailed exchange realizations in activity diagrams and event traces (sequence diagrams). However, if there are detailed realizations defined, then the UPIA modeling command to generate exchanges will automatically compute and set the producing and consuming tasks for the exchange based on Task Invocation messages and activity edges between Call Operation actions.

The following diagram shows a flow of Personnel from Organization2 to Organization1.




New: Resource Flow


A new relationship type, Resource Flow, was added as an association between two performers to represent one or more resource exchanges between those performers. The existing Needline and System Interface types are now specializations of a Resource Flow. The Needline property “information exchanges” and the System Interface property “data exchange” were moved to an “exchanges” property on the Resource Flow type, which is inherited by Needline and System Interface. This property contains references to the exchanges that are represented by the given Resource Flow, Needline, or System Interface.

Between the same two performers, multiple Information Exchanges are represented by a single Needline, multiple Data Exchanges are represented by a single System Interface and multiple Resource Exchanges are represented by a single Resource Flow. The UPIA modeling command to generate resource flows will automatically create separate Needline, System Interface and Resource Flow associations between two performers, based on the existing exchanges and the types of those exchanges. If a corresponding association (flow) already exists, the generation command will update the “exchanges” property on that flow.




New: Implements Exchange


A new relationship type, Implements Exchange, was added to represent the mapping of exchanges in one logical domain to exchanges in another logical domain. For example, in the project domain, two Capability Roles exchange some resource. This Resource Exchange is realized in the operational domain by an Information Exchange between two Operational Nodes, which is subsequently realized in the system domain by a Data Exchange between two Systems. To show these realizations, the Implements Exchange dependency would connect the Information Exchange to the Resource Exchange, and the Data Exchange to the Information Exchange. The realization of a single exchange in one logical domain might actually correspond to multiple exchanges in another logical domain.




New: Implements Flow


A new relationship type, Implements Flow, was added to represent the mapping of resource flows in one logical domain to flows in another logical domain. The existing Implements Needline relationship is a specialization of the new Implements Flow. In the example above for Implements Exchange, the realization mapping could be done between the corresponding flow associations instead of between the exchanges.




New: Strategy and Tactics of Project relationships


Some architecture designs require two different types of modeling with respect to projects: acquisition modeling and project implementation modeling. If an architecture design contains both types of project modeling, the new logical domain support enables users to differentiate the elements.

Acquisition modeling treats a project as a black box where the most import aspects of the project are the (strategic) Capabilities the project will deliver, who manages the project and what resources are created as a result of the project. UPIA already had existing types for doing acquisition modeling, such as (strategic) Capability, Strategic Mission, Capability Configuration, Project and relationships connecting these types as follows:




Project implementation modeling delves into how the project is executed in order to deliver the strategic capabilities. The details of the project execution would illustrate how organizations and personnel perform tasks (project tasks) needed to complete the project. This execution detail can show resources flowing from one organization to another.

The execution of a project may be governed by both long term strategies and short term tactics. Two new relationship types, Strategy of Project and Tactics of Project, allow a Project to be connected to its long term strategy (a Strategic Mission) or to its short term tactics (a Capability Usage). The tactics of a project can be realized by a project Plan which contains various Plan Activities that illustrate some aspect of the tactics. Plan Activities can be defined as UML activities, interactions or state machines to model the details of the project execution.





New: Consumable


In some architecture designs, there is a need to identify selected resources or systems as being consumable, meaning they may need to be replaced. To enable flexibility, a new Consumable stereotype was added that can be applied to any Resource specialization or Performer specialization. By using dual stereotypes, existing resources and systems are easily identified as being consumable. If the lifespan of such a resource is known, the consumable resource can be associated with a Time Interval by the new Temporal Element stereotype.



New: Domain enumeration and Domain Element


Some architecture designs are modeled with respect to multiple logical domains, such as acquisition, operational, and system. Previously, models used UML packages or multiple models to separate the elements corresponding to different domains. A new Domain enumeration and a Domain Element stereotype enable users to mark individual model elements as belonging to one or more logical domains. The Domain enumeration has literals Acquisition, Business, Custom, Operational, Project, Service, Strategic and System. The Domain Element stereotype has two properties:

domain: Domain[*]
customDomain: String[1]

The "domain" property can contain zero or more Domain enumeration literals. If one of the literals is "Custom", then the customDomain property can be set to a custom domain name or to multiple comma-separated names. See the Logical Domain Modeling section below.



New: Temporal Element


Architectural modeling sometimes requires time intervals to be specified for certain elements. In UPIA, a Time Interval instance, with start and end dates, is used to define a period of time that can be related to other elements. Previously, only some element types, such as Actual Measure, Capability, Forecast, Milestone, Standard and Strategic Mission, could have references to Time Intervals.

To properly model temporal behaviors, separate elements may be needed to represent the same entity at different times in its lifecycle where each element would have an associated Time Interval. The new stereotype Temporal Element allows any element to be associated with a Time Interval instance. This stereotype has a "time period" property which contains one or more Time Interval references. If Temporal Element is applied to an element, then it must contain at least one Time Interval reference.

Use any of the UPIA relationship tools to connect an element to a Time Interval. This gesture automatically applies the Temporal Element stereotype to that source element and adds a reference to the Time Interval in the "time period" stereotype property. In addition, a dependency from the source element to the Time Interval is drawn to represent that reference stored in the stereotype property.


The types Actual Measure, Milestone and Strategic Mission all had special Time Interval reference properties such as planned dates or actual dates. Temporal Element will not be applied to these types of elements because their existing properties are still supported by the UPIA relationship tools. However, the "time period" properties on Capability, Forecast and Standard were deleted and instead the "time period" property on Temporal Element is used.



Rename: Task properties on Policy


The stereotype Policy had two separate properties which contained references to the Operational and Systems tasks that adhered to that policy. These properties, “operationalTask” and “systemTask” are now combined into a single “tasks” property so that new Project Tasks can also be associated with policies.



Rename: Capability related types and relationships


Three capability related types and various relationships were renamed to clarify their meanings. An Operational Capability is a UML use case that illustrates the usage of a corresponding Capability, so it was renamed to Capability Usage. As a result, the properties on Strategic Mission and Goal that refer to a Capability Usage were also renamed from "operationalCapabilities" to "capabilityUsage".

The corresponding realizations, Operational Capability Realization and Operational Activity Realization, were combined into a single Capability Realization. The following table shows the capability related types that were renamed.

Old Type Name	New Type Name
Operational Capability	Capability Usage
Operational Activity Realization	Capability Realization
Operational Capability Realization	Capability Realization

In addition, several relationships were renamed. The old relationship names referred to the end types of the relationship but these names did not indicate what the relationship meant. The new names reflect the purpose of the relationship.

Old Relationship Name	New Relationship Name	Connects
Capability Operational Capability	Exercises Capability	Capability to Capability Usage
Capability Configuration Capability	Configures Capability	Capability Configuration to Capability
Capability Requirement Capability	Describes Usage	Capability Requirement to Capability Usage
Organizational Resource Capability	Provisions Capability	Organizational Resource to Capability
Organizational Resource Capability Configuration	Manages Configuration	Organizational Resource to Capability Configuration
Organizational Resource Mission	Contributes to Mission	Organizational Resource to Strategic Mission
Organizational Resource Vision	Contributes to Vision	Organizational Resource to Vision
Realized Operational Capability	Realizes Usage	Capability Realization to Capability Usage, or Plan to Capability Usage
Resource Capability Configuration	Used by Configuration	Resources or Performers to Capability Configuration

Rename: Systems Node to System Assembly


A Systems Node element and the Systems Node Elements relationship are used to represent a collection of systems and resources that need to be deployed together. The name Systems Node had different meanings in various architecture frameworks so to avoid confusion the stereotype has been renamed to System Assembly.

A System Assembly differs from a System Group. A System Assembly defines a collection of systems for deployment and a System Group defines a collection of systems for the purpose of doing forecasts and tracking the assessment of systems against standards.

As part of this rename, the two Systems Node relationships were also renamed. Systems Node Elements was renamed to "In Assembly" and is used to indicate the systems that belong to the deployment collection. Systems Node Materiel indicated Systems in the collection that corresponded to consumable items, or materiel. This materiel relationship was deprecated because of the new Consumable marker. However, during migration an existing Systems Node Materiel association will be converted to an In Assembly association, and the element being included in the collection will have the new Consumable stereotype applied to it. The end result is a consumable system or resource that is included in the deployment collection.




Enhancement: Issue relationships


When conflict and obstacle modeling was added in a previous release, the relationships Issue Involves and Issue Resolution were stereotyped associations. In UML, an association can only be created between UML Type elements, but this is too restrictive. If a conflict or obstacle involved a task, a UML operation, the Issue element could not be connected to that task. In this release, the Issue Involves and Issue Resolution relationships now use a UML dependency instead of an association. Existing stereotyped issue associations are still valid but any new relationships are stereotyped dependencies.

With dependencies, relationships can be created from the Issue element to any other UPIA element, including tasks. One limitation is that the diagram tooling does not allow relationships to be created from the Issue (a UML class) to an operation which is contained in a compartment of another class or interface. There are two ways to create these issue dependencies.

(1) Select the Issue element either in the Project Explorer or on a diagram. In the Properties view on the relationships page, add a relationship from the Issue. In the resulting dialog, choose the target task (or another UPIA element) and in the list of relationships, choose either Issue Involves or Issue Resolution.

(2) Select the Issue element in the Project Explorer and in the popup menu, the “Add UPIA” submenu has a new entry for creating a UPIA relationship to an existing element. In the subsequent cascading menu, choose either Issue Involves or Issue Resolution and in the dialog, choose the target UPIA element.







Enhancement: Depends On relationship


The Depends On association between Capabilities was changed from an aggregation to a directed association. In the figure below, Capability2 depends on Capability1.




Enhancement: Location


In UPIA, the Location type is generic such that it can be defined and customized to represent any point or extent in space. The Location stereotype is used to represent a type of location, such as "building". A specific location is represented by an Actual Location element, which is an instance of some Location type element.

The Location stereotype has two string properties to distinguish one type of Location from another; the location description and the location type. However, these two properties are not enough to define the necessary details of a specific location (Actual Location instance). Other attributes such as street address, city, and so on, are needed so that an Actual Location instance can specify exact values. One Location type may require a different set of attributes than another Location type.

To help differentiate location types, the UPIA model library now contains a hierarchy of classes that can be specialized when a user creates a new Location (type) element. For example, the UPIA library contains the following class hierarchy of location types:



When a new Location type element is created, that element can specialize one of the location type classes in the UPIA model library. This inheritance effectively identifies a category of Location types.



Enhancement: Milestone Point relationship


The Milestone Point association was changed to allow a Capability Configuration to be related with a Milestone.




Enhancement: Plan extension


The stereotype extension of Plan was changed to include both Class and Collaboration. The palette tools and menu items now prompt for which type of Plan, class or collaboration, to create.



Enhancement: Plan Activity extension


The stereotype extension of Plan Activity was changed from Opaque Behavior to Behavior. This now allows four different types of Plan Activity to be created: activity, interaction, state machine and opaque behavior. The palette tools and menu items now prompt for which type of behavior to create for a Plan Activity.



Enhancement: Project Phase relationship


The Project Phase relationship between Projects was changed from a bidirectional association to a directed association.




Enhancement: Rule


The Rule type in UPIA corresponds to a stereotyped UML constraint that can be attached to any UPIA element. In previous releases, the Rule stereotype had a single stereotype property (type) whose value was one of the literals defined in the Rule Type enumeration. The existing Rule Type enumeration did not have a literal to represent a condition. A rule that represents a condition would define the state of the environment or situation in which some activity or process is performed.

In this release, a "Condition" literal was added to the Rule Type enumeration. In addition, a "category" string property was added to the Rule stereotype. The "type" and "category" properties of a Rule can be used together if necessary.



Deleted: Activity Realization relationship


The Activity Realization relationship was deleted. Previously this relationship indirectly associated an Operational Activity with a System function by connecting an Operational Activity to an Operational Activity Realization and by connecting a System Function to an Operational Capability Realization. The relationship was effectively replaced in a previous release by the Operational to System relationship, which directly associates an Operational Activity with a System Function.



Deleted: Exchange properties on Data Element and Information Element


In previous releases, Data Element had a property with references to the Data Exchanges in which the Data Element was passed. Likewise Information Element had a property for the references to the Information Exchanges. The new Resource Exchange allows any resource or resource specialization to be exchanged between performers. However because of the Resource stereotype hierarchy, adding an exchange reference property to Resource would add unnecessary data to the model. Every exchange already keeps references to the resources it passes in the corresponding “conveyed” property. To create a BIRT report that lists the exchanges in which a given Resource is used, perform a data join between that Resource and the “conveyed” list for the known exchanges.



Deleted: Operational Capability Effect relationship


The Operational Capability Effect relationship between an Effect and either an Operational Activity Realization or an Operational Capability Realization (now a Capability Realization) was deleted. This relationship is replaced by the Creates Effect and Effect Impacts relationships.



Deleted: Specialized service producer and consumer types


The specialized service types in UPIA (Operational Service Producer, Operational Service Consumer, System Service Producer and System Service Consumer) do not have equivalent types in the Service oriented architecture Modeling Language (SoaML). These four UPIA element types were deprecated and during migration of an existing UPIA model, they are converted into Participant elements.

Modeling Tool changes

UPIA models integrated with SoaML profile

The Rational modeling products now have a profile and tools that support version 1.0 of the OMG specification for the Service oriented architecture Modeling Language (SoaML). The UPIA profile and tools were integrated with the SoaML profile and its tools to enable more extensive service modeling in UPIA models.

In previous releases, UPIA contained several service related types such as Service Participant, Service Specification, and Service Port. These types enabled basic modeling of service oriented architectures, but the types are also integrated with other UPIA types. For example, the Service Participant inherits attributes and relationships from Operational Node and System, so a Service Participant can have event traces, either in the operational domain or the system domain. Likewise a Service Specification can own either Operational Tasks or System Tasks.

The integration of UPIA and SoaML enables intersecting element types to have the behavior of both the UPIA type and the SoaML type by applying both UPIA and SoaML stereotypes to the same element. Special migration occurs for the UPIA Service Port because SoaML has two port types: Service Point and Request Point. A UPIA Service Port that only has required interfaces becomes a SoaML Request Point and all other UPIA Service Ports become SoaML Service Points.

The following table shows the UPIA and SoaML types that intersect. The columns in the table show the UPIA stereotype that was applied in a previous release, the current UPIA stereotype that will be applied and the corresponding SoaML stereotype that will also be applied.

Previous UPIA Stereotype	Current UPIA Stereotype	SoaML applied Stereotype
Operational Service Consumer	Service Participant	Participant
Operational Service Provider	Service Participant	Participant
Service Participant	Service Participant	Participant
Service Port (with only required interfaces)	Service Port	Request Point
Service Port (with at least one provided interface)	Service Port	Service Point
Service Specification	Service Specification	Service Interface
System Service Consumer	Service Participant	Participant
System Service Provider	Service Participant	Participant

Although UPIA and SoaML both have a Capability element type, the semantic meaning of these two types is different. The UPIA Capability is a key type in modeling enterprise architectures, so the modeler must choose which Capability to use.

To avoid confusion when two stereotypes are applied to the same element, only the SoaML stereotype name and icon are visible on diagrams and in the Project Explorer, but both stereotypes will be shown in the Properties view. This enables any necessary UPIA attributes to be set.

When creating service elements in a UPIA model, either the UPIA Service palette or the (service modeling) Service palette can be used. In either case, the corresponding SoaML and UPIA stereotypes will be applied. The tools in the UPIA Service palette and UPIA context menu reflect the SoaML tool name and icon. The following figure shows the Service modeling palette and the updated UPIA Service palette.



In previous releases, the Service Participant tool in the UPIA palette only created a UML class. Since the Participant tool in the (SoaML) Service palette only creates a UML component, selecting the Participant tool in the UPIA Service palette gives you the option of creating a UML class or component version of the Participant. Similarly, selecting the Service Interface tool from the UPIA Service palette gives you the option to create a UML interface (simple) or a class (collaborating).

The SoaML integration support in UPIA will still work if the Service Modeling installation feature is not included. In this case, there will be no SoaML profile and no service modeling palette. However, the UPIA Service palette and menus can still be used to create the service related elements. Only the UPIA stereotype will be applied to intersecting elements but a keyword is defined with the corresponding SoaML stereotype name. This results in the same visual representation in Project Explorer and diagrams, whether SoaML is available or not. If the Service Modeling feature is subsequently installed and an existing UPIA model is opened, the SoaML keyword (stereotype name) is removed and the corresponding SoaML stereotype is applied.

Since the SoaML stereotypes might not be available, when designing a BIRT report the expressions should refer to the UPIA stereotypes instead of the SoaML stereotypes.



UPIA pop-up menu item for creating relationships


UPIA relationships can now be created by a pop-up menu command in the Project Explorer. Right-click the source element for the relationship; then click Add UPIA > Relationship to existing element to display a submenu that contains only the UPIA relationships that are valid for the selected source element. When a relationship is selected, an element selection dialog box is displayed that allows you to select the existing target element of the relationship.

This mechanism enables relationships to be created that cannot be created on a diagram using a palette Relationship tool. For many types of diagrams, the diagram editor only allows relationships to be created between top level shapes (such as a class shape) and not internal compartments (such as a class attribute or operation).







New UPIA Resource palette


A new diagram palette and popup submenu was added for creating Resource related types and relationships. This palette was created to provide a separation between types that correspond to data resources and types that correspond to performers (which are a specialization of Resource). The Resource palette and submenu have entries for creating a Resource, Information, Data Element and Information Element. The Resource Relationships tool allows the creation of resource compatible relationships, including the new Resource Exchange and the Resource Flow, and their specializations. The palettes that correspond to the various performer specializations are Operational, Organizational, Service, and System.





UPIA Strategic Planning palette renamed


The Strategic Planning palette was renamed to Capability. The palette contains the same tools and relationships as before.






UPIA Generation of exchanges and resource flows


With the introduction of new relationship types Resource Exchange and Resource Flow, the UPIA modeling commands for generating Information Exchanges and Data Exchanges were replaced with a single command to generate Resource Exchanges. This new command uses the same model scoping but generates all three types of exchanges: Information Exchanges, Data Exchanges, and Resource Exchanges. An Information Exchange is only generated if the source and target elements are Operational Nodes, or specializations, the defined producing and consuming tasks are all Operational Tasks, and the conveyed resources are all Information Elements. Likewise, a Data Exchange is only generated if the source and target elements are Systems, or specializations, the defined producing and consuming tasks are all System Tasks, and the conveyed resources are all Data Elements. For any other combination of source and target performers, producing and consuming tasks, or conveyed resources, the generation command creates a Resource Exchange.

Similarly, the UPIA modeling commands for generating Needlines and System Interfaces were replaced with a single command to generate Resource Flows. This new command uses the same model scoping but generates all three types of flow associations: Needlines, System Interfaces and Resource Flows. When generation is performed, all of the Information Exchanges between two Operational Nodes are represented by a single Needline association and all of the Data Exchanges between two Systems are represented by a single System Interface association. Similarly, Resource Exchanges between two performers are represented by a single Resource Flow.







UPIA Manual creation of exchanges


There are times when the user wants to create exchanges between performers without having to define the realization details using sequence and activity diagrams. Using a relationships tool and connecting two performers, a popup menu will list the various types of relationships that can be created between those performers, which may include Information Exchanges, Data Exchanges and Resource Exchanges. If any of these exchange relationship types is selected, a subsequent popup menu will prompt for the resource conveyed by that exchange. Based on the type of exchange being created, this latter menu will have entries to create various resource types that can be exchanged, plus an entry to select an existing resource type. However, if the target performer has one or more tasks (Project, Operational or System Tasks) defined with “in” parameters, the second popup will also contain an entry to select the consuming task on the target performer. When a task is selected, the type of the first “in” parameter becomes the conveyed resource of the exchange and the selected task is set in the exchange’s “consumingTask” property. The user has to manually set the “producingTask” property.






UPIA Logical domain modeling


Some architecture designs are modeled with respect to multiple logical domains since many of the UPIA element types are applicable in different logical domains. Previously architects used UML packages, or separate models, to structure the elements that correspond to different logical domains. In general, an associated logical domain is orthogonal to the types of elements being created.

Logical domain modeling allows the user to associate any UPIA element with a logical domain or with multiple logical domains. The Domain Element stereotype has a "domain" property, which is a list of zero or more literals defined in the Domain enumeration as follows:

• Acquisition
• Business
• Custom
• Operational
• Project
• Service
• Strategic
• System

If the "Custom" domain literal is set, then the "customDomain" string property on Domain Element defines one or more custom domain names, where multiple names must be separated by commas.

In the context menu, the UPIA Modeling submenu has a command to set the logical domain. If one or more UPIA elements are selected, all of them are modified accordingly.




When this menu command is selected, a dialog box opens to enable the selection of logical domains. The dialog box lists the available domains with a check box to either set or clear the domain for the selected elements. If multiple elements are selected, and for a given domain some elements have it set and others do not, the check box has a third grayed state to indicate the mixed settings. When you click OK, domains in the grayed state do not change the settings on the selected elements. For the Custom domain, if all of the selected elements have Custom set but they have different custom domain names ("customDomain" property), then the check box is also in the grayed state. In this scenario, if the check box is put into the checked state and a custom domain name is specified, the "customDomain" property on all of the selected elements is changed to that new name.



In addition, logical domain filtering is available in the Custom Queries. The preference page has two additional parameters for filtering: (1) the logical domain filter and (2) a custom domain name. The logical domain filter is a combo box with the names of the Domain literals, plus an entry <No Filtering>. The custom domain name is a text control that is only enabled if the Custom domain is selected for filtering. When Custom domain filtering is selected, one or more domain names can be specified in the custom domain name control, including the standard domain names. For example, if the custom domain name control was set to "business, system", then any element belonging to either the Business domain or the System domain will be displayed.

When a query is executed, it searches for elements in the model based on the search scope, element types and the derived flag. If no filtering is selected, these queried elements would be added to the diagram, as before. When filtering, only the elements in this list that belong to the specified domain(s) are added to the diagram.







Creating new Location type elements


In UPIA, a Location type is defined using a class stereotyped as Location. Each Location type will have one or more attributes to define the type of data needed to identify a specific location. Multiple instances of that Location type can be created as Actual Locations, where specific values for the Location attributes can be given.

When a palette tool or menu command is used to create a new Location, a new popup menu allows the user to choose to create a generic location or to create a specialization of one of the UPIA library classes.



In any case, a new UML class is created and is stereotyped as Location. For specializations, this new class has a generalization to the library class and the stereotype property "location type" is set to the name of the library class.

In UPIA, there are multiple ways to define the attributes needed to specific exact locations for a given Location type. A common approach is to define the attributes on the new Location type element. By creating multiple Location type elements and using generalizations, location specific attributes can be defined using inheritance. The following figure shows this technique for defining specific location attributes.



A more flexible technique to define specific location attributes can be accomplished using Measure Types and Actual Measures. This technique enables different Location types to share specific location attributes and specific location instances. For example, a single street address Measure Type can be defined so that different Location type elements can be associated with the same Measure Type. Then a single Actual Measure instance can be created with specific address attribute values. The instance of a Location type, an Actual Location, can refer to that Actual Measure instance that defines a specific address. In fact, different Actual Location instances can refer to the same Actual Measure instance, thus ensuring the Actual Locations are all at the same address.






Indentifying consumable resources


In UPIA, any Resource or Performer specialization can be dual stereotyped with Consumable to indicate it may be depleted or worn out by use. If one or more Resource or Performer specializations are selected and the context menu is displayed, the UPIA Modeling submenu will contain a command to toggle the consumable state of the selected elements.

In the following figure, the Resource element is already marked as Consumable but the other two elements are not. If the Toggle Consumable State command is executed both Personnel and System will be marked as Consumable but the Resource will not.


If you want to highlight the consumable resources, you can use the UPIA Modeling command to reorder the stereotypes. Note the different icon being displayed for the consumable System.

BIRT reports

New xpath function for logical domain filtering

In addition to logical domain filtering in custom queries, the "filterUPIADomain" function can be called from expressions in a BIRT report. The function signature is:

filterUPIADomain(<elements>, <domainName>)

where <elements> is one or more UPIA elements and <domainName> is a string to indicate the logical domain name. If the domain name does not correspond to a Domain literal, then elements with the "Custom" domain set are returned if the "customDomain" string property contains the given domain name.

In the function call, the domain name string can actually be a comma separated list of domain names, which is interpreted as a logical OR. All elements in the collection that belong to any of the specified domains are returned. To achieve a logical AND, simply imbed the filtering function call as the first parameter of another filtering function call as follows:

filterUPIADomain(filterUPIADomain(<elements>, "domain1"), "domain2")

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
ActivityRealization		(deleted)
Capability	timePeriod	TemporalElement	timePeriod
CapabilityConfigurationCapability		ConfiguresCapability
CapabilityOperationalCapability		ExercisesCapability
CapabilityRequirementCapability		DescribesUsage
DataElement	dataExchange		(deleted)
DataExchange	dataExchangeIdentifier	DataExchange	exchangeId
Forecast	timePeriod	TemporalElement	timePeriod
Goal	operationalCapabilities	Goal	capabilityUsage
InformationElement	informationExchange		(deleted)
InformationExchange	informationExchangeId	InformationExchange	exchangeId
Needline	informationExchanges	Needline	exchanges
OperationalActivityRealization		CapabilityRealization
OperationalCapability		CapabilityUsage
OperationalCapabilityEffect		(deleted)
OperationalCapabilityRealization		CapabilityRealization
OperationalServiceConsumer		ServiceParticipant
OperationalServiceProvider		ServiceParticipant
OrganizationalResourceCapability		ProvisionsCapability
OrganizationalResourceCapabilityConfiguration		ManagesConfiguration
OrganizationalResourceMission		ContributesToMission
OrganizationalResourceVision		ContributesToVision
Policy	operationalTask	Policy	tasks
Policy	systemTask	Policy	tasks
RealizedOperationalCapability		RealizesUsage
ResourceCapabilityConfiguration		UsedByConfiguration
Standard	timePeriod	TemporalElement	timePeriod
StrategicMission	operationalCapabilities	StrategicMission	capabilityUsage
System Interface	dataExchange	System Interface	exchanges
SystemServiceConsumer		ServiceParticipant
SystemServiceProvider		ServiceParticipant
Systems Node		System Assembly
Systems Node Elements		In Assembly
Systems Node Materiel		In Assembly

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 will encounter when generating a report for a model that uses the latest version of UPIA.

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.

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

Capability_DS:

Row: getElementsWithStereotype(//*, "UPIA::Capability")
name: @name
timeout: getStereotypePropertyValue(., "UPIA::Capability::timePeriod")/@name

OpCapability_DS:

Row: getElementsWithStereotype(//*, "UPIA::OperationalCapability")
name: @name
goal: getStereotypePropertyValue(., "UPIA::OperationalCapability::goals")/@name

The model being reported has multiple Capability elements with one related TimeInterval instance, and multiple Operational Capability (Capability Usage) elements with related Goal elements. The Operational Node element has dual stereotypes, so it is also a Capability.



Without any report template changes, the first report generation attempt will fail with an IllegalArgumentException for the property “timePeriod” because that property is no longer defined on the Capability stereotype. (problem c)

The stereotype property referenced in the “timeout” column expression in the Capability_DS data set is changed to the “UPIA::TemporalElement::timePeriod”. After the change, the report generation does not fail. Although the Capability table is populated, the Operational Capability table is empty. (problem a)

The OpCapability_DS data set row expression in the template is modified to search for elements with the stereotype “UPIA::CapabilityUsage”. However, the “goal” column expression is not changed, and still refers to “OperationalCapability”. When the report is generated, the Operational Capability table will now be populated but will not have any entries in the “goal” column. (problem b)

The column expression for “goal” is changed in the OpCapability_DS data set and the final report template data sets would be as follows:

Capability_DS:

Row: getElementsWithStereotype(//*, "UPIA::Capability")
name: @name
timeout: getStereotypePropertyValue(., " UPIA::TemporalElement::timePeriod ")/@name

OpCapability_DS:

Row: getElementsWithStereotype(//*, "UPIA:: CapabilityUsage ")
name: @name
goal: getStereotypePropertyValue(., "UPIA:: CapabilityUsage::goals")/@name

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