Stuart Kent - Software Modeling and Visualization
When I'm creating domain models, the ability to place properties on a relationship is proving very useful.
For example, at the moment I'm remodelling our designer definition format (we generate it from a domain model) and have a relationship between Connector and Decorator and Shape and Decorator. Decorators have a position, which is modelled as an enumeration (inner-top-right, etc.), but the values of the enumeration are different depending on whether the decorator is on a Shape or on a Connector (inner-top-right is not a meaningful position for a connector). Without properties on relationships, we'd have to subclass Decorator to ShapeDecorator and ConnectorDecorator, and all we'd be adding was a differently typed Position property in each case. With properties on relationships, we can just attach a differently typed Position property to the relationships from Shape to Decoarator and from Connector to Decorator, respectively - no subclassing required.
UML has associations which are like our relationships. You can attach properties (attributes) to associations via their association classes. UML also has qualified associations, where you can index links of the associations by a property - e.g. an integer or a position. But it seems to me that one could achieve the effect of qualified associations by adding attributes to association classes, as we add properties to relationships. So, in my mind, if you've got association classes, qualified associations are redundant.
Am I missing something?
Last night the conference banquet was held for the MoDELS conference in Jamaica. The MoDELS conference changed it's name this year - it used to be known as the UML conference, and UML is still used in the byline. I'm the general chair for the conference this year, and Microsoft sponsored the banquet. As you know, Microsoft is arguing for domain specific languages, with UML playing a useful role in some circumstances within that approach.
So I was mildly amused to see the title printed on the menu that interpreted the acronym 'UML' as 'Universal Modeling Language'. I also noticed that alongside the UML logo on the conference program, the acronym is expanded as 'United Modeling Language'. Having experienced OMG politics at first hand during the standardization process for UML 2.0, I find the latter interpretation particularly ironic.
This reminds me of a game I once played with colleagues in a quiet moment at an OMG meeting. It's surprising how many subsititutions for the letter 'U' one can come up with. Kept us going for a good 30 minutes.
I'm in Jamaica at the MoDELS 05 conference.
Yesterday I attended a workshop on model transformation, where a number of different techniques were presented. The organizers had asked all submitters to apply their technique to a standard example (the object-relational mapping) so it was quite easy to compare the different approaches. There were also some excellent discussions. Here's my distillation of key take-aways:
1) Most of the approaches modeled the tracing data (i.e. the mapping itself) in some way. Transformations created both the tracing data as well as the target model. Some of the approaches (e.g. triple graph grammars) used the tracing data generated by one application of the transformation as input into the next application.
2) Rules which use pattern matching was a common theme running through most (though not all) techniques. Placing priorities on rules was one way of controlling the order in which rules are processed. Some combined rules with imperative code, to put control structure around rules or to 'finish' off work done by a rule. Some techniques used constraint solvers to avoid writing any imperative code at all.
3) There was an interesting discussion about specifying and testing transformations. One could argue that a dedicated model transformation language, if it is any good, is high level enough not to require a separate specification. Even so, it's still necessary to validate that the transformation meets the business need: does it produce the expected results for designated example input models? So we need testing frameworks for delivering input models to a set of rules and checking the output is correct. How do we check the output is correct? It depends on what it is. If the model is executable, you can test its execution to see that it has the desired behavior. If not you can at least inspect it and check that it is well formed. One can also write well formedness constraints on the tracing model (see 1) and check that generated traces are well formed. This then led into a discussion about debugging transformation rules... here again the tracing data may be useful information, especially if the order in which rules have been fired, hence tracing information created, is also kept.
(An aside: In building DSL Tools we have been faced with the issue of specifying code generators, which are expressed as text templates. An effective way of specifying them, we have found, is to describe the behavior of the generated code for various combinations of inputs.)
4) Another interesting discussion emerged around the topic of bidirectional mappings and model management. Suppose we have two models where one is not fully generated from the other - they are both edited directly in some way. The goal is then to keep them consistent and help the user bring them back to consistency, and there would probably need to be UI specific to the particular transformation in question to do this. Again, tracing information seems important in this scenario. But now consider a team scenario with multiple models and multiple mappings between them. Different team members make changes to models, checking them into source control. How do you go about keeping all models consistent with one another across the mappings? What are the steps a developer must take when they check in? When dealing with a large code base through source control, you soon learn to use diff and merge tools and also soon learn that there are different levels of consistency: will the code build? does it run all tests? does it meet all scenarios? I think it's a similar situation with models. We need diff and merge tools with models, and, they have to be domain specific, just like the languages. We need to start considering what the different levels of consistency are: are there any unresolved cross references between model elements? are the models well-formed? are the mappings between models consistent?
5) Finally there was a brief discussion about diagrams and diagram layout. The point being that if you run a transformation to create a new model, then what about creating and laying out the diagram to go with that model (assuming a graphical modeling language here)? And what about getting that layout to be a transformation of the layout of the source model?
Interesting, uh? Well I thought so, at least.