Tigerstripe Case Study

< To: Tigerstripe Community Resources

Cisco has a large Information Model called Chameleon (over 700 classes) which is used to provide a consistent basis for the development of a family of network management applications. The information model is based on existing industry standard models (such as the TMF’s SID and DMTF’ CIM) but extends on them significantly to add various networking technologies. A particular focus of the model is its use for automatic artifact generation – rather than remaining a picture on the wall, we generate all of the key internal and external interfaces from the applications directly from the model as part of an automated build process.

Prior to using Tigerstripe, Ciso made use of a custom tool chain:

• A commercial Eclipse-based UML editor.
• Some home-brew Eclipse plugins (which were run headless) for UML/EMF model consolidation and segmentation.
• Model source code control using Subversion.
• Andromda (www.andromda.org) which was used to generate artifacts from the resulting models as part of a Maven build process.

Although this loosely integrated tool chain worked well enough, there were a bunch of issues surrounding its use:

• Chameleon is owned and managed by a central team, but is used and extended by an extended group of people spread across development teams. It was difficult to ensure that consistency was maintained across the various contributors since it was not possible to constrain the editor to only accept valid model extensions. We ended up with a 30+ page document describing all of the rules that needed to be followed, with no ability to implement ‘up front’ validation on entry.
• The editor used a coarse grain persistence model which means that multiple model packages were stored in the same package. This form of persistence proved fairly fragile and we wended up having to carefully synchronize edits to ensure things didn’t break.
• With information models, it is very useful to be able to draw ‘Instance Diagrams’, this is both to explain modeling patterns and also to explain the function and usage of a portion of the model. This was not possible with our chosen editor.
• Since the whole model was not used in any particular application we used home brew tooling to segment and subset the model. It was difficult and error prone to maintain the metadata necessary for this.
• The number of different elements in the chain made it difficult and error prone to manage and reduced it’s scalability – things became worse and worse as more and more people used the model.

Eventually we decided to invest in a new set of tooling to address all of these issues and settled on the use of Tigerstripe for this. Some features of the Tigerstripe tooling that are especially useful to us are:

• The editor in Tigerstripe can customized to contain people’s editing palette.
• We can draw instance diagrams and have them available at build time.
• Tigerstripe artifact generation plug-ins can be run at build time (headless) or during an editing session.
• We have written a validation plug-in that can be used at design and build time to check model validity against a set of rules.
• Integrating plug-in/template development into the tool has improved usability significantly over the use of AndroMDA.
• Fine grain, class based persistence model has made it much easier for multiple editors to work on the model simultaneously.
• We can distribute read only model libraries to other development teams.