JOSIF Main Page | JOSIF Guidebook | Modeling | General Patterns | Model Transformation Rules

Only in JOSIF V1.1.

Introduction

...

The base for the implementation model is a subset of the SID model which imported into the Tigerstripe tool from RSM (to be RSA in the future). The SID is exported in UML2 and imported into Tigerstripe. The TIP _ SID _ Import tool  tool is used to pilot this import. It is an Eclipse plugin, accessible through the Import menu of Eclipse by selecting Tigerstripe/ UML2 Import.

In addition to the functionalities of selection, the the TIP _ SID _ Import tool includes a set of unique transformation rules to move from the SID model to an implementation model in a repeatable and simple way.

The SID_Import tool uses an xml configuration file (SID_Import.xml) to keep the import and transformation rules specific to the project. Please refer to the TIP _ SID _ Import page  page for more details on how to use this tool.

...

An example of package rule for importing an ABE in a Model project is provided below:

<artifact>
       <type>package</type>
       <name>SID Phase 9dot5 Models::Resource Domain::Resource Trouble ABE::Alarm Severity Assignment Profile ABE</name>
       <rule>import_package_only</rule>
</artifact> 

...

The import_datatype rule imports a datatype and all attributes and all datatypes required for its attributes. It is used to populate a dependency project with a datatype used either in the data model, but outside of interface ABE or used by a parameter.

<artifact>
	   <type>datatype</type>
	   <name>SID Phase 9dot5 Models::Resource Domain::Resource ABE::TIP Resource ABE::Network Resource Basic ABE::LayerRate</name>
	   <rule>import_datatype_and_attributes</rule>
</artifact>

...

The exclude statement for this relationship is provided below:

<artifact>
	<type>class</type>
	<name>SID Phase 9dot5 Models::Resource Domain::Resource ABE::LogicalResource ABE::LogicalResource</name>
	<rule>import_class_and_attributes_and_associations</rule>
	<exclude>
		<attribute>_resourceSecurityEntity</attribute>
	</exclude>
</artifact> 

...

An example of collapsing statements is provided below:

<collapse>
      <from>SID Phase 9dot5 Models::Common Business Entities Domain::Root Business Entities ABE::RootEntity</from>
      <to>SID Phase 9dot5 Models::Common Business Entities Domain::Root Business Entities ABE::Entity</to>
</collapse>
<collapse>
      <from>SID Phase 9dot5 Models::Common Business Entities Domain::Root Business Entities ABE::Entity</from>
      <to>SID Phase 9dot5 Models::Common Business Entities Domain::Root Business Entities ABE::ManagedEntity</to>
</collapse>

...

JOSIF has a standard entity identifier pattern (See Entity Identifier pattern) and the generators will handle this case by injecting the standard EntityIdentifier structure.

...

An example is provided below:

	
           <artifact>
		<type>class</type>
		<name>SID Phase 9x Models::Resource Domain::Resource ABE::Resource</name>
		<rule>import_empty_class</rule>
	</artifact>

...

In this example, it is not useful to have EntityIdentifier for securityServiceUser and securityServiceProvider'. These 2 relationship roles are transformed as attributes of type String in the ResourceAlarm entity.
This rule is not implemented yet in JOSIF Rel 1.1. Today, the relationship object should be deleted and the string attributes created by hand.
When the target object of the association needs to be passed by value, then the question the developer should ask is whether the target object should be an entity or a datatype.
An entity supports a lifecycle with associated events (ObjectCreation, Attribute Value change…). If the remote object is more of a utility object, simply used to carry data where having a separate lifecycle does not make sense, then the class should be refactored as a datatype.
The example below illustrates this rule:

The CrossedThreshold object does not have a real lifecycle as it just carries data associated with the threshold crossed. So this class should be refactored as a datatype.'This rule is partly implemented in JOSIF V1.1.1. '
To transfrom a class in a datatype, the class should be tagged with the keyword_baseType_or_dataType_in the SID as shown below:

As soon as a class is marked with one of these 2 keywords, the SID Import tool will transform it in a datatype.
Notes:
* If the object has to be imported in the Dependency model, then it should be added in the SID_Import.xml file of the Dependencies project with the rule: import_class_and_attributes_and_associations
* In JOSIF V.1.1.1, handling of associations targeting the transformed class is not supported. Attributes will have to be created by hand in the source classes. This will be fixed in a next release.
If the target object of the association needs to be passed by value and should not be refactored as a datatype, then be sure to uncheck the attribute_Passed by Id_of the tipAttribute stereotype of the relation role. If the target object is not in the Model, then add it to the Dependencies model using the rule import_class_and_attributes_and_associations.
h1. Extensibility Rules
The SID is using an extensibility pattern called CharacteristicValue/CharacteristicSpec. The figure below is showing a use of this pattern.

The use of this pattern allows one to indicate that the object can be extended by additional attributes which are not described in the model.
_In the implementation model, a specific datatype_AttributeValuePair'' exists to allow adding new attributes identified by their names.

...