An Architectural Discussion of Cayenne ObjectTeam and StP

Mark Bell, Sr. Apps. Engr   9 July, 1998

Summary:  Our Cayenne Tiger Team¹ has installed and operated ObjectTeam, initially to characterize our competitive advantages and to counter theirs.  We have spent at least ten man-days and developed a worthwhile list of comparisons beneficial to Aonix.  However, we also find that ObjectTeam's architecture supports versioning from the ground up, and that for certain customers this makes Cayenne the tool of choice.

Since versioning is inherent in the ObjectTeam architecture and is difficult to support with ours, I began to think about ways to combine the two tools and have the best of both worlds.  I believe we could do that and emerge with an impregnable position in the high-end UML tools market.

We could combine the tools in several ways.  StP’s graphical front end could be placed on top of  Cayenne’s repository.  The effort to do this would occupy both engineering teams in a fruitful collaboration which would undoubtedly result in gaining the best features from each.  The design thinking needed to provide proper upgrade paths would also bear unexpected fruit in enhancements.  (Interestingly, our architects have in times past contemplated going to a non-flat-file repository.) ²

On the Structured side, we could develop a sound migration from Cayenne to Aonix and take over their Structured maintenance stream.  My understanding is that our Structured tool has benefited from continued development whereas theirs has been dormant.  (However, I have briefly run their Structured tool at a customer site and found it also supports versioning.  We would have to accommodate that.)

To conclude, we would also ensure that we took the proper stance on Windows Native and Unix.  This would mean that we could architect an absolute world-class toolset, benefit the great majority of our customers and draw our line in the sand against Rational.  And the stake through the heart of Rational’s high-end business would be a migration utility to our tools!

How Versioning is Used

To begin with, versioning is not significant to a substantial fraction of our customers.  However, to some such as Boeing, it is required.  And there are others who would strongly prefer that we had it and are obliged to work around its absence. 

Version control has three main aspects.  First, it allows the user to define a baseline or a minor version of their graphical model and return to it at will later.  Second, one can extend this notion and provide for "phases" or "levels."  (Cayenne supports three phases by default:  analysis, system design and object design.)  Third, one can split the development of a large project into several pieces and merge them later.  That in turn implies the existence of a diagram-differencing capability to facilitate merging.  Cayenne has that.  This versioning scheme, while proprietary to Cayenne, is very similar to classical versioning of source code as used by ClearCase and many others ³.  A thorough description with StP-based examples is in my version control paper of May 1996 ⁴.  (I also describe suggested enhancements to our process which Cayenne, I now learn, has already implemented.  But there are still some features in that paper we could add to make ours superior.)

Our tiger team was initially unable to understand why project phases would be of any interest to a customer.  Methodologically, phases seem like a throwback to the Structured world and a Waterfall process ⁵.  I have learned, however, that project phases are valuable for tool users who work with multiple deliverables.  That is, a major contractor like TRW is asked by their customers to provide evidence of work-in-progress.  Hence, when they have customer reviews they are asked, "How much more work have you done on the project since the last review?  How far into design have you progressed on Segment X or Y?"  The "phase" notion supports that admirably, especially when supported with diagram and model differencing tools.

StP does not do versioning or phases as a practical matter.  There have been workarounds and partial implementations on StP but in my view none have been production quality.  We are about to build some new menus and customizations to StP that will accommodate much of this, but they will still be ad hoc responses, falling short of architectural change.  (These enhancements will nevertheless help quite a bit in many sales situations.  So will our bringing in Fear, Uncertainty and Doubt about the prospect getting stuck in a Waterfall process…)

StP and ObjectTeam - an Architectural Comparison

There are surprising similarities between the two tools.  Both use an RDBMS repository, both have a persistent data model and both support the UML (although ours is more complete!).  But the differences are where we must turn.

ObjectTeam has no flat files.  Everything about diagrams or any part of the model is stored in their RDBMS  repository.  Each design element in the database has version information associated with it -- the project phase, the individual version and all previous versions.

StP uses flat files as our primary storage medium, with images of the same data in our repository.  In our long-ago version of 4.2d, this scheme lent itself to versioning with third-party CM products.  However, there are issues with our current architecture that make this cumbersome ⁴.

1.      Sarah Satterlee, Mark Steffensen and Mark Bell performed the technical analysis with ObjectTeam installed single-user on our laptops.  Tom King, Rob Hadley, David Bennett and Rick Learn added insights.

2.      Phone conversation with Peter Pircher, approx. June 20.

3.   ClearCase manuals describe classical versioning exceptionally well.  They can act as a competent introduction to the field.  I have a current set and one back-rev set.

4.   Configuration Management of StP Models,  May 17, 1996, Mark Bell.

5.      "Need Critique of Cayenne UML Workflow," June 25, 1998, Daryl Winters email, responding to Sarah’s and my methodology questions.