Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Why Tigerstripe ?"

(Focused Modeling)
m
Line 1: Line 1:
 +
{{Backlink|Tigerstripe}}
 
__TOC__
 
__TOC__
  

Revision as of 13:34, 4 January 2008

< 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.

Two 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 majors themes that we found 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 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 is 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), other 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 wrt the model:

  1. All users need to be total experts about UML and understand the implications of a propery 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, like profiles to define stereotypes (annotations) that import/export with UML2 is available.

Large Model Support

Distributed Teams

MDE Roles

Back to the top