Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

JOSIF Main Page | JOSIF Guidebook | Tooling

Table of Contents
outlinetrue
indent20px
stylenone
printablefalse

Principles

All the data objects of a TIP interface are part of the SID.
So the definition of an interface goes through 2 stages:

...

Tigersripe is used for the interface projects. The TIP The JOSIF Project Creator must  must be used to create the interface projects.

The project name used in TIP JOSIF Project Creator should  should be TIP_XXX, where XXX is the interface short acornym. The corresponding id for the Model project should be: org.tmforum.tip.xxx Note the lower case for xxx in the id. The id for the Dependency project should suffixed by dep, i.e. org.tmforum.tip.xxx.dep

...

A model project might contain no information model ABE if it is a pure task-centric interface like an Inventory interface. In this case, no import is needed for the Model project.

The The TIP _ SID _ Import tool  tool is used for importing the information model. The use of this tool requires to set up a SID_Import.xml file in each project. The syntax and the use of this tool are explained in the  TIP _ SID _ Import page page.

The main steps of the import process are:

...

It includes operations in Service Interfaces, notifications and exceptions. In some specific cases, some datatypes or enumerations not relevant for the Information Model might also be added at this level. However, in the more general case, if a specific data object is needed for an operation, then it should be checked first:
1) if it exists in the SID. In this case, simply edit the SID_Import.xml file of the Dependencies Model and follow the steps described in Importing Information Model to import the dependencies model again and rebuild the corresponding module.
2) if it needs to be added to the Information Model of the interface. In this case, augment the Information Model in the SID and follow the steps described in Importing Information Model to import the Model again.

Service Interfaces

Operations are grouped in in Service Interfaces that are named Session Facade in Tigerstripe. An interface specification must have at least one Service Interface, but having more than one is possible if needed by the design of the interface. Please use the stereotype stereotype tipServiceInterfaceto indicate if the implementation of the service interface is mandatory or not.

For entity-centric interfaces centered around one object, like Service Problem or TroubleTicket, the recommendation is to name the main Service
Interface <Object>Interface. For example, ServiceProblemInterface in case of SPM where the main object is the Service Problem. For these entity-centric interfaces, if some common operations, like create, delete, get or set are needed, then it might be worth considering using the Common Operations pattern. This pattern is used by defining the needed tipEntityXxx stereotype on the corresponding entity artefact. If for any reason, this pattern is not suitable for interface, then defining explicitly the needed operation is possible. It is however recommended to try to follow as much as possible the signature of the corresponding common operation for consistency.

Operations

All  TIP operations should Operations should return void.
Do not forget to add and document the the tipOperation stereotype  stereotype on each operation.
Add needed parameters with corresponding tipParameter stereotype stereotype.

Pre-defined exceptions are Exceptions are added to all operations. Any common exceptions can  Common Exceptions can be added and specific exceptions might be added as needed.

...

The TIP Framework generators will generate for each class the appropriate notifications based on the stereotypes defined for the objects. Please refer to the Notification general patternGeneral Pattern for more details on common notification.

It is also possible to define explicit notifications in the model using the the Notification artefact.

Validating the Model

The TIP _ Model _ Validator is a plugin allowing you to validate the model at any time during the development.

To validate the model, select it in the Explorer and in the righ-click menu, select Validate TIP Model.
The pop-up will indicate the results and any warning or error will be displayed in the standard Eclipse Problems panel.

It is recommended to run the the TIP _ Model _ Validator right  right after importing the Information Model, as it implements some TIP specific rules stricter than the standard UML checks of RSM.

Panel
 

The validator should also be run once the first operations have been developed and before publishing the specifications.

...

These projects must be created by the TIP_ JOSIF Project _ Creator for  for getting correct settings.

...