TIP SID Import
JOSIF Main Page | JOSIF Framework | TIP SID Import
Introduction
In TIP, when a specification team works in Tigerstripe workbench, 2 different projects are defined per interface:
- The Interface project, which contains the main entities.
- The Dependencies project, where the dependencies of the entities locate.
For example, for Service Problem Management specification, we have
- TIP_SPM_Model, which contains the entity ServiceProblem.
- TIP_SPM_Dependency, where the dependencies such as TroubleTicket, GeographicPlace, Party etc defined.
From the point of view of a TIP model author (for example, the author of ServiceProblem Management model), a recommended process to import UML models to Tigerstripe models is summarized as follows:
step 1: In modeling tool such as Rational Software Modeler, work on a SID branch to define main domain-specific ABE(such as Service Problem ABE). Note that the dependencies of the ABEs are resolved in the branch.
step 2: In Tigerstripe workbench, for each of the Tigerstripe projects (Interface project and Dependencies project), configure (in an XML file to be defined later in this doc) what to be imported to the projects.
step 3: In Tigerstripe workbench (which is enhanced and expanded) imports ABEs and its dependencies into interface project and dependency project repectively, according to the configuration.
Subversion Location
Source Code
https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_SID_Import/trunk/
Under the URL you find following 2 projects:
1) UML2Import - enhanced Tigerstripe UML2Import plug-in
2) SID Mapping - enhanced Tigesrstripe SID Mapping plug-in
Binary
Under the URL you find releases for:
1) Eclipse Galileo and Tigerstripe Workbench 0.5
2) Eclipse Helios and Tigestripe Workbench 0.6
Note
For more information about Tigerstripe workbench, please refer to Tigerstripe.
Rules
Rules for UML packages, classes, data types, enumerations, associations, association classes.
Class Rules
We define 2 rules for UML classes.
Class Rule 1 - import_class_with_attributes_and_associations
This is the default rule for UML classes.
Rule Definition:
- Source UML model: e.g. SID model
- a UML type in the source = an UML class
- magic word = import_class_with_attributes_and_associations
The dependencies of the UML class under this rule:
# Types of the attributes of the UML class. And further treatment of the types: ## If the type is primitive, ignore (it is automatically handled). ## If the type is an UML class, ### If the attribute is passed by value, apply Class Rule 1 to its type. ### If the attribute has no stereotype defined or is passed by id, apply Class Rule 2 (defined below) to its type. ## If the type is an UML data type (including enumeration), apply the Datatype Rule 1 (defined below). ## If the type is an UML association class, apply the Association Class Rule 1 (defined below). ## If the type is not one of the above mentioned, no further treatment (correct?). # All UML associations which contains an end navigable from the UML class. # UML classes of the ends navigable from the UML class. And further treatment of the end classes: ## If the end is passed by value, apply Class Rule 1 to its type. ## If the end has no stereotype defined or is passed by id, apply Class Rule 2 (defined below) to the type of the end. # All super types of the class, if any; and further treatment of the super types: ## If the type is an UML data type (including enumeration), apply the Datatype Rule 1. ## If the type is an UML association class, apply the Association Class Rule 1 (defined below). ## If the type is an UML class, apply Class Rule 1 to its type. ## If the type is not one of the above mentioned, no further trea tment (correct?). # All UML packages directly or indirectly contain the UML class.
Typical Use Cases:
- Type of an attribute which is passed by value
- A class used as a parameter (but note that currently there are no operations in SID)
- The class is an association end passed by value
Class Rule 2 – Import Empty Class
Rule Definition:
- Source UML model: e.g. SID model
- a UML type in the source = an UML class
- magic word = import_empty_class
Note that with this rule, the UML class will be changed to an empty class:
The empty class comes from the original class by:
- discard all attributes of the original class
- discard all associations of the original class
- discard all supertypes of the original class
The dependencies of the empty class under this rule:
# All UML packages directly or indirectly contain the original UML class.
Typical Use Cases:
• Type of an attribute passed by id
• The class is an association end passed by id
Data Type Rules
We define only one rule for UML data types.
Data Type Rule 1 – import_datatype_with_attributes
Note: Enumeration is a kind of data type (at least as seen from Eclipse UML API which the SID Import plug-ins are based on)
Rule Definition:
• Source UML model: e.g. SID model
• a UML type in the source = a UML datatype
• magic word = import_datatype_with_attributes
The dependencies of the UML DataType under this rule:
# All UML packages directly or indirectly contain the UML datatype. # (same with the treatment in the Class Rule 1) Types of the attributes of the UML class. Further treatment: ## If the type is primitive, ignore (it is automatically handled). ## If the type is an UML data type (including enumeration), apply the Datatype Rule 1. ## If the type is an UML association class, apply the Association Class Rule 1 (defined below). ## If the type is an UML class, ### If the attribute is passed by value, apply Class Rule 1 to its type. ### If the attribute has no stereotype defined or is passed by id, apply Class Rule 2 to its type. ## If the type is not one of the above mentioned, no further treatment (correct?). # All super types of the datatype, if any ## If the type is an UML data type (including enumeration), apply the Datatype Rule 1. ## If the type is an UML association class, apply the Association Class Rule 1 (defined below). ## If the type is an UML class, apply Class Rule 1 to its type. ## If the type is not one of the above mentioned, no further treatment (correct?).
Typical Use Cases:
- Type of an attribute of an UML class
- A data type used as a parameter (passed by value)
Rules for Association
This section defines Association rule.
Association Rule 1 – Association_With_Ends
Typically, it is an internal rule, that is, a rule used by the plug-in.
Rule Definition:
• Source UML model: e.g. SID model
• a UML type in the source = a UML association
• magic word = import_ association_with_ends
The dependencies of the UML association under this rule:
# All UML packages directly or indirectly contain the UML association. # Types of the ends of the UML association. Further treatment: ## If the type is an UML class, ### If the attribute is passed by value, apply Class Rule 1 to its type. ### If the attribute has no stereotype defined or is passed by id, apply Class Rule 2 to its type. ## If the type is not one of the above mentioned, no further treatment (correct?). # All super types of the association, if any (?exist in SID?) ## If the type is an UML association class, apply the Association Class Rule 1 (defined below). ## If the type is an UML class, apply Class Rule 1 to its type. ## If the type is not one of the above mentioned, no further treatment (correct?).
Rules for Association Class
This section defines a rule for association class.
Association Class Rule 1 – AssociationClass_With_Attributes_and_Ends
Typically, it is an internal rule, that is, a rule used by the plug-in.
Rule Definition:
• Source UML model: e.g. SID model
• a UML type in the source = a UML association class
• magic word = import_ AssociationClass_with_Attributes_and_Ends
The dependencies of the UML association class under this rule:
# All dependencies defined in Association Rule 1 # (same with the treatment of Class Rule 1) Types of the attributes of the UML association class. And further treatment of the types: ## If the type is primitive, ignore (it is automatically handled). ## If the type is an UML class, ### If the attribute is passed by value, apply Class Rule 1 (full class) to its type. ### If the attribute has no stereotype defined or is passed by id, apply Class Rule 2 (empty class) to its type. ## If the type is an UML data type (including enumeration), apply the Datatype Rule 1 (full content). ## If the type is an UML association class, apply the Association Class Rule (full content). ## If the type is not one of the above mentioned, no further treatment (correct?).
Package Rules
This section defines rule for UML packages.
Package Rule 1 –Import_package_only
This is the default rule for packages.
Rule Definition:
• Source UML model: e.g. SID model
• a UML type in the source = a UML package
• magic word = import_ package_only
The dependencies of the UML package under this rule:
# All UML packages directly or indirectly contain the UML package. # Types of the DIRECT members of the UML package. ## If the member is a package, then apply Package Rule 1 (import packge only) to it.
Note: A consequence of the rule. Suppose that
1) a class is contained in the package, and
2) the class has a super type, and
3) the super type is not in the package
Then, the super type is NOT in the result of the rule. The type should be provided by dependencies with or without attributes included.
Package Rule 2 – import_package_and_external_references
Rule Definition:
• Source UML model: e.g. SID model
• a UML type in the source = a UML package
• magic word = import_package_and_external_references
The dependencies of the UML package under this rule:
# All UML packages directly or indirectly contain the UML package. # Types of the members of the UML package. And further treatment of the member types: ## If the type is primitive, ignore (it is automatically handled). ## If the type is an Association class, apply Association Class Rule 1 ## If the type is an Association, apply Association Rule 1 ## If the type is a datatype, apply DataType Rule 1. ## If the type is a class, apply Class Rule 1 ## If the type is a package, apply package rule 2.
Typical Use case:
• The package used in a dependency. Example, resource model for inventory interface.
Installation
You find the binary release of the SID Import Plug-ins at the OpenOSS SVN:
Install on Eclipse Galileo and Tigerstripe Workbench 0.5
The 2 jar files under the folder 'galileo' are the SID import plugins for Eclipse Galileo+Tigerstripe Workbench v0.5.0.201005200239.
To install it,
1. Stop the eclipse if not yet
2. Backup the file Eclipse_Home/plugins/org.eclipse.tigerstripe.workbench.ui.UML2Import_0.5.0.201005200239.jar.
3. copy these 2 jar files to the folder Eclipse_Home/plugins. In my environment, it is the folder C:\IDE\eclipse-jee-galileo-SR2-win32-ts05-testbed\plugins. You will be asked whether to overwrite the file org.eclipse.tigerstripe.workbench.ui.UML2Import_0.5.0.201005200239.jar, please accept it.
4. Start the Eclipse. To ensure the new plug-in is detected, you can use '-clean' tag in start up command, for example,
C:\IDE\eclipse-jee-galileo-SR2-win32\eclipse.exe –clean
Install on Eclipse Helios and Tigerstripe Workbench 0.6
The 2 packages under the folder 'helios' are the SID import plugins for Eclipse Helios+Tigerstripe Workbench v0.6.935.201102010903.
To install it,
1. Stop the eclipse if not yet
2. Backup the file Eclipse_Home/plugins/org.eclipse.tigerstripe.workbench.ui.UML2Import_0.6.935.201102010903.jar.
3. Copy these 2 jar files to the folder Eclipse_Home/plugins. In my environment, it is the folder C:\IDE\eclipse-jee-helios-SR1-win32-x86_64-ts06-testbed\plugins. You will be asked whether to overwrite the file org.eclipse.tigerstripe.workbench.ui.UML2Import_0.6.935.201102010903.jar, please accept it.
4. Start the Eclipse. To ensure the new plug-in is detected, you can use '-clean' tag in start up command, for example,
C:\IDE\eclipse-jee-helios-SR1-win32-x86_64-ts06-testbed\eclipse.exe –clean
Configuration
File Name
The name of the configuration file is SID_import.xml. The rule engine will search this file under the root of a Tigerstripe model project.
Note: if the file is absent, the plug-ins will import whole SID model. This is compatible with original model import plug-ins.
Grammar of Configuration File
The configuration file is XML file containing instances of the rules. Its XML Schema Definition file is to be added.
Before go any further, let us give an important note:
An important note
The rules about UML package, UML class, and UML data type are the 1st class rules and the rules about UML Association, UML Association Class, and UML Primitive Type are the 2nd class rules.
In rule configuration file (SID_import.xml), the model authors only need to use the 1st class rules. The 2nd class rules are executed to support the 1st class rules. The configuration file only supports the 1st class rules.
A sample of the configuration file
Here we give a sample configuration file which shows basic structure.
<?xml version="1.0" encoding="UTF-8" ?> <sidimport> <artifact> <type>package</type> <name>SID Phase 9x Models::Service domain::Service Problem ABE</name> <rule>import_package_only</rule> </artifact> </sidimport>
The root elment is 'sidimport'. A rule instance is an XML element named "artifact". You can put any number of rule instances in the file. From now, we will also call rule instance as rule.
The "artifact" element has 3 sub-elements: type, name, and rule.
Note: If under the root “sidimport” there is no any “artifact” element, the plug-ins will import nothing.
defining rules for UML classes
1. in the "type" element, give the constant word "class"
2. in the "name" element, give the full name of the UML class
3. in the "rule" element, specify a rule name. There are 2 class rules supported.
class rule - sample 1
<artifact> <type>class</type> <name>TIP_RAM_InfoModel::Resource Domain::Resource Trouble ABE::Alarm ABE::ResourceAlarm</name> <rule>import_class_and_attributes_and_associations</rule> </artifact>
class rule - sample 2
<artifact> <type>class</type> <name>SID Phase 9x Models::Common Business Entities Domain::Trouble or Problem ABE::TrackingRecord</name> <rule>import_empty_class</rule> </artifact>
defining rules for UML data types
Note that UML enumerations are UML data types.
1. in the "type" element, give the constant word "datatype"
2. in the "name" element, give the full name of the UML data type
3. in the "rule" element, specify a rule name. There is one data type rule supported.
data type rule - sample 1
<artifact> <type>datatype</type> <name>SID Phase 9x Models::Common Business Entities Domain::Trouble or Problem ABE::AckStatus</name> <rule>import_datatype_and_attributes</rule> </artifact>
defining rules for UML packages
1. in the "type" element, give the constant word "package"
2. in the "name" element, give the full name of the UML package
3. in the "rule" element, specify a rule name. There are 2 package rules supported.
package rule - sample 1
<artifact> <type>package</type> <name>SID Phase 9x Models::Common Business Entities Domain::Trouble Ticket ABE</name> <rule>import_package_only</rule> </artifact>
Editing the configuration files
This section gives guideline on configuration (essentially, it is about dependency analysis) and a sample.
Guideline
In TIP, when a specification team works in Tigerstripe workbench, 2 different Tigerstripe model projects are defined per interface:
- The Interface project, which contains the main ABE.
- The Dependencies project, where the dependencies of the entities locate.
For example, for Service Problem Management specification, we have following Tigerstripe model projects:
- TIP_SPM_Model which contains the Service Problem ABEs.
- TIP_SPM_Dependency where the dependencies such as TroubleTicket, GeographicPlace, Party e.t.c defined.
Generally, For interface projects, in configuration, we only need to use the package rule "import_package_only" to import main ABE package and its members.
For dependency projects, in configuration, we use
- the datatype rule "import_datatype_and_attributes" to import dataypes
the class rule "import_class_and_attributes_and_associations" to import full classes. Typical use cases are: the class from which the main entity inherites from, the type of attributes passed by value, or an aggregation composition
- the class rule "import_empty_class" to import empty classes. The typical use cases are: the type of attributes passed by id, the type of an association end passed by id.
Sample
Let take Service Problem Management as an example.
Usage
Importing to dependency model project
Step 1: Prepare configuration file "SID_import.xml" and put it at the root of the dependency model project.
Note that if the Tigestripe project is created with JOSIF Project Creator, an empty "SID_import.xml" is already in the place.
Step 2: Right click on the Tigesstripe project and select "import ..." in the pop-up menu.
Step 3: Select "UML2 Import" and click "Next>"
Step 4: Set Tigerstripe project and UML2 file. Click "Next>"
Step 5: A preview of the mapping between UML types and Tigestripe artifacts. Click "Next>"
Step 6: An overview of changes to be made on the target Tigerstripe project. Click "Finish"
Step 7: The Tigerstripe project updated.
Step 8: Validator the Tigerstripe project
You can examine the model by compiling the model project or by invoking TIP Model Validator
In case of any error, you may need to review the source UML model and/or the configuration SID_import.xml.
Exporting dependency model
Step 1: Following Tigesrtripe export wizard to export the dependency model
Right click the project and select "Export" in the pop-up menu
Select "Tigerstripe Model" and click "Next"
Accept default values with one exception: change the suffix of model package from "jar" to "zip". Click "Finish"
We see a package is generated (highlighted) under the root of the project
Step 2: Adding the dependency model package as a dependency of the interface model
Copy the dependency model zip to the root of the interface model
Open the tigerstripe.xml and navigate to "dependencies" tag
Click "Add" button, select the dependency model zip, then click "OK" to add it.
Save the updated tigerstripe.xml file.
Now we see the dependency model zip is successfully added as a dependncy
Importing to interface model project
Follow the steps described in the previous section Importing to dependency model project.
Note on resolving references
The tool (in fact, part of the tool set - the enhanced Tigerstripe UML2Import plugin) resolves references from the interface model to the dependency model. Typical cases:
1. super types in dependency model
We know that in ServiceProblemManagement SID branch, the entity SID Phase 9x Models::Service domain::Service Problem ABE::ServiceProblem
has a supertype SID Phase 9x Models::Common Business Entities Domain::Trouble or Problem ABE::Problem. Suppose that we have already imported Problem into dependency model and added dependency model package to the interface model project as a dependency, then the resulted ServiceProblem entity will correctly extend the entity Problem if we import ServiceProblem into interface model with the rule
<artifact> <type>class</type> <name>SID Phase 9x Models::Service domain::Service Problem ABE::ServiceProblem</name> <rule>import_class_and_attributes_and_associations</rule> </artifact>
2. associations to dependency model
ServiceProblem has a navigable association to Resource. If the entity Resource is in dependency of the interface model project, when we import ServiceProblem with the rule import_class_and_attributes_and_associations, the resulted association will correctly navigable to the entity Resource.
3. attributes refer to dependency model
Note on Logging
The log files are in the same folder of the imported UML file.
After importing, please take a look into the log files for ERROR or WARN message, especially in SIDImportTrimmerX.log, even if the resulted Tigestripe model has no any obvious error. For example, the tool will report ERROR or WARN when it saw an Entity inherits from an Association Class although it accormadates the practice.
Note on handling doNotImplement
In SID model, some types and attributes are marked with doNotImplement. This is how the import tool handle doNotImplement:
1. remove any UML classifier (package, class, associationClass, association, dataype, etc) marked with doNotImplement.
2. Any UML classifiers in SID, including package, class, associationClass, association, dataype, etc, if it is contained in a package (directly or indirectly) marked as doNotImplement, it will be excluded from the final model.
3. For an UML class, or an AssociationClass, or a dataype, all their attributes marked with doNotImplement will be excluded from the final model.
4. Given an association, if it has at least one end points to a classifier that is marked with doNotImplement or contained in a package (directly or indirectly) marked as doNotImplement, it will be excluded from the final model.