Why Tigerstripe ?

< To: Tigerstripe

Overview

Tigerstripe is a Model-Driven Engineering (MDE) framework for Eclipse that was initially put together as a prototype for Telecommunications Standards implementation in large Telecom Service Providers.

A few years later it has evolved into a production-ready framework used by Telecommunication Standard bodies themselves, and in production in large corporations (including Cisco Systems, Inc who is currently leading this project).

Tigerstripe has been focusing on trying to address specific themes with regards to MDE. It does not replace general purpose UML modeling environments, but offers a robust integrated MDE environment tested in demanding product environments.

Tigerstripe Themes

Tigerstripe is focusing on major themes that were typically not addressed properly in other existing environments:

• Users of MDE frameworks may not be UML experts: in fact, most of the time they only have a very limited knowledge of what UML is. Tigerstripe is trying to provide a simplified UML modeling environment by providing only a subset of the UML2 metamodel.
• Enterprise Models are BIG: typically large enterprises will want to develop a large model that will be used across departments, functional areas and products in order to provide coherency and unity. However, when generating artifacts out of such a model, only a sub-scope will be relevant for the task at hand, e.g. a model may contain details about a product, but when generating DB mapping or exposed public APIs, different model scopes are required since not all implementation details present in the database would be exposed through a public API.
• Smaller pieces of Enterprise Models are owned by various Teams: a large model is never maintained and owned by a single team. A large model needs to be split in sub-components or tiers that are consumed or extended by other teams. Being able to release model parts becomes necessary.
• MDE involves multiple roles: from modeling to code generation, all the way to product release multiple teams are involved: architects, engineering, integration, etc... They all need to interact with the model somehow, but would have different interactions. Some would define modeling conventions and guidelines (architects, e.g.), some would only extend parts of the model (functional domain experts), others would only need to refer to it for documentation (integration and support teams, e.g.).

Focused Modeling

Model-Driven Engineering requires a very tight process in order to be successful in a large scale. This means in particular that the starting point - i.e. the model itself - needs to be near perfect so that quality code can be generated.

Although a lot of development organizations use UML, very few are able to generate quality code and realize the expected cost-savings. This is the difference between Model-Inspired Engineering and Model-Driven Engineering. A nice UML model with a lot of nice diagrams provided to developers to "guide or inspire" the implementation can tolerate lack of conventions in the model, or even incoherencies. A model used for proper Model-Driven Engineering approach needs to follow agreed rules and principles, simply because no human being will be able to adjust the design for implementation.

There are 2 approaches to solve this garbage in - garbage out problem with the model:

1. All users need to be total experts about UML and understand the implications of a property change on a class in the model.
2. The modeling environment needs to guide (and sometimes constrain) users who are expected to have a basic knowledge of UML, but more so to be experts in their domain.

Tigerstripe is betting on option 2. UML is very complex. There are a lot of general purpose UML modeling environments out there for experts, Tigerstripe will allow to import models developed in these environments, but will limit the features available within Tigerstripe itself to ensure the quality of the model.

Practically, what does this mean? Tigerstripe uses a Domain Specific Language (DSL) inspired by UML2 where some of the complexity has been removed. Yet it was proven to provide a large-enough subset of UML2 to enable large projects to succeed.

The Domain Specific Language was initially developed based on the needs of Telecommunication Standards but it appears that it would be suitable for Enterprise Modeling at large.

Finally, Tigerstripe provides features similar enough to UML2 like Class Diagrams or Instance Diagrams. Profiles to define stereotypes (annotations) that import/export with UML2 is also available.

Large Model Support

Although MDE prototypes always start with small models, the reality is that models grow very quickly in size and complexity. In the case of Enterprise Models there is a good reason for it: the model provides a single place where commonalities across the enterprise or the products can be captured.

There are two main consequences:

1. The MDE framework needs to support ways to componentize a large model.
2. When generating code or documentation out of the model, the MDE framework needs to support mechanisms to identify scopes within the model allowing to consider the multiple facets of a model.

Tigerstripe address both of these requirements by

1. allowing to split models across projects and cross reference them
2. allowing to define Model Facets within a model, by identifying key artifacts in the model and by letting the framework resolve all the associated, extended or implemented artifacts that need to be in scope for the sub-model to be valid.

Distributed Teams

In real size MDE projects, multiple teams will be involved at various stage of the development process.

In particular, there is no single team that owns the complete model. More likely, the model is organized in components or tiers that are owned by specific teams and are cross referenced appropriately.

As with any development environment, these model components will evolve at different paces making versioning support of model components a key requirement.

Tigerstripe proposes a solution in 2 ways:

1. fine-grain granularity for model persistence: every component in the model is persisted in its own file. This significantly aids with merge issues when using Source Control Management systems, such as CVS or SVN, e.g.
2. Compiled version of a model: any Tigerstripe project can reference other projects either directly or through a compiled version of the target model. This compiled version is read-only, can be referenced and extended, and has a clearly identified version. A simple analogy to this concept can be drawn out of Java Projects able to reference other Java Projects (direct reference to source code, e.g.) or reference a corresponding .jar file that typically corresponds to a specific version.

MDE Roles

A Model-Driven Engineering Process will typically span over multiple teams with different involvement and roles.

For example:

• A Center of Excellence organization will be responsible for delivering a common baseline model and the associated conventions and guidelines.
• Multiple Engineering Teams will cover specific aspects of a product line and extend the common model appropriately, whether they are responsible for specific functions or technologies, e.g. They will need to adhere to the conventions defined by the Center of Excellence.
• Integration Teams will only need to consult the model but won't need to make changes.

Roles can be defined in Tigerstripe to enable/disable certain functions in the IDE accordingly to defined roles.

Note: roles were supported through the licensing mechanism in the commercial version of Tigerstripe. The open-source version will need to address this differently.