Sunday, March 1, 2009

What Executes?

One problem executable design tools face when parsing and executing a design is "what do I execute"?

During the creative process, you tend to work with diagrams rather than class or object definitions. If you're fairly messy, as I am, you may end up with an underlying model containing lots of objects, classes, and relations which don't show up on any diagram, but which the tool created as you were adding things to the model.  You may also end up with different objects with the same name on different diagrams--class diagram 1 contains a class called "Person", and diagram 2 contains a class called "Person" with some of the same attributes and methods as the first, but internally, the UML design tool has created two separate Person classes, not one.  How does the execution engine know which one to execute--or did the designer want both?

I want to use the "diagram" as the control.  If something shows up in an underlying model, but not in a diagram, it's ignored by the execution engine. Oh, I want it listed somewhere when the model is parsed for execution, but I don't want it showing up in my executing code.  I used the diagram to communicate with developers, not the hidden underlying model--so that's what expresses my intent as a designer.

What're the drawbacks of this approach?

No comments:

Post a Comment