Tigerstripe Metamodel

< To: Tigerstripe

Overview

As part of the migration of Tigerstripe's core to EMF, we are formally specifying the Tigerstripe Metamodel through an EMF ECore.

The actual .ecore file can be accessed from the "org.eclipse.tigerstripe.metamodel" plugin.

This .ecore is organized as follows:

• Main "Metamodel" package: contains the basic Metamodel for Tigerstripe including all the Artifact types as exposed through the palette.
• A "extensions" package: intended to host all extensions to the main Tigerstripe metamodel. In particular, it is expected that specific standard bodies, industry verticals may want to agree on some content in this package for standardization.
  • extensions.ossj: contains the first set of extensions specially targeting the OSS/J Community.

Highlights

The Tigerstripe metamodel is derived from UML, yet it constitutes a Domain Specific Language initially inspired by concepts of Entity, Service and Resource modeling in an Service Oriented Architecture based OSS/BSS (Operational Support System/Business Support System).

In particular, whereas UML provides basic components such as UML Class, UML Interface or UML Enumeration, Tigerstripe provides slightly different basic components. These components should be seen as UML Classes tagged with built-in Stereotypes. For example, a Tigerstripe Managed Entity Artifact is in effect a UML Class with a Managed Entity stereotype if you will, allowing to build Associations, Association Classes, and any other typically UML Relationship with other artifacts.

Typical UML Relationships (extends, implements) as well as Associations, Association Classes and Dependencies are supported similarly to UML (in fact 1-to-1 mapping).

Single inheritance is enforced in a "java-fashion", where each artifact can only extend a class of their own type (with the exception of AssociationClasses that should be considered as Managed Entities). Multiple inheritance is realized through an implements relationship.

The semantics of the Tigerstripe Metamodel is as follows:

• Managed Entity Artifact: modeling a "thing" of physical or logical existence in the world, typically something that will be stored in a database and can be associated with a unique key. Managed Entities support methods, Literal and fields. Managed Entities may only extend another Managed Entity or an Association Class.
• Datatype Artifact: modeling a "complex type" which is in fact an aggregation of multiple primitive types into a single class. This is similar to the old C struc construct. Datatypes support methods, literals and Fields. Datatypes can only anther Datatype.
• Enumeration Artifact: Similar to UML Enumeration, supporting Literals only. An Enumeration can extend another Enumeration.
• Query Artifact: modeling an opaque Query Object. In typical SOA environments, interfaces or service contracts support query mechanisms that don't expose the details of implementation of the query, but presents the available features and expected return type. Queries support Fields as a way to model input parameters to a query and have a special returns relationship that allows to identify the expected content of the resultset produced when running the query. A Query can only extends another Query.
• Update Procedure Artifact: modeling an opaque batch update mechanism. In Typical SOA environments, interfaces or service contracts support ways to provide the details of a batch task to be performed. This is the intend of this meta object. Update Procedures support fields as a way to parameterize batch operations. An Update Procedure can only extend another Update Procedure.
• Exception Artifact: a dedicated meta-object to model exceptions thrown by methods. Exceptions support fields as a way to model the content of an exception. An Exception can only extend another Exception.
• Event Artifact: typical SOA environments are expected to be very much event-driven. This meta object is dedicated to modeling Events as they may be emitted through a logical interface of service contract. Events support fields as a way to model the payload of these events. An event can only extend another event.
• Primitive Type Artifact: this is a special meta-object to model specific custom primitive types for fields in the model. Tigerstripe supports the usual (UML-like) primitive types such as int, long, char, String, etc... If you need to define additional types, you can do so through a Tigerstripe profile. Once a profile is deployed the corresponding Primitive Type Artifacts will be made available for modeling.
• Session Artifact: this corresponds to a UML Interface and is intended to model interfaces or integration points in a SOA environment. Session Artifacts may have any number of incoming implements relationships (if enabled in a profile) and/or specific relationships to specific types of artifacts:
  • managed entities relationship: modeling which entities are to be managed through a given interface/session. For example, an ordering interface would "manage" Orders modeled as Managed Entities.
  • supports relationship: modeling which Query Artifacts are supported by a given interface/session.
  • exposes relationship: modeling which Update Procedures Artifacts can be triggered through a given interface/session.
  • emits relationship: modeling which Event Artifacts may be logically emitted through a given interface/session.

Complete ECore Diagram

A complete ECore diagram based on a snapshot of the actual .ecore file is presented below.