Putting a Square Peg Model in a Round Hole Tool

Robert Bauman left the following comment on my Separated at Birth post?

The nice thing about using a general purpose modeler is that you can house all of your requirements, use cases, etc. in the same model. Rational provides the 4+1 view, Sparx Systems Enterprise Architect provides several views out of the box that you can easily navigate around… It means that everyone is working off of the same set of rules.

As soon as you start putting those rules into Visual Studio, they change and deviate from the model. It’s true that the AndroMDA does require you to remember to use certain stereotypes, but that’s all part of the game anyhow.

That’s like saying, “well, the GoF patterns are nice, but then you have to remember what it means to have an Observer pattern”. Furthermore, UML tools let you customize the list of stereotypes that show in the dropdown, and even the picture that should be associated with those stereotypes. Why mess with some other modeling standard when you can do it all with a proper UML tool

The point I was making is that when you start using the class model to design something other than classes, you’re using a domain specific language – even if you’re using a general purpose modeling tool.  Take a look at this example from the AndroMDA website. Their example reads:

You tag a CustomerService class with a <<Service>> stereotype. AndroMDA sees this stereotype, looks into its internal dictionary of available code generation components (called “cartridges”) and finds the EJB cartridge. In the EJB cartridge, two templates correspond to the <<Service>> stereotype: SessionBean.vsl and SessionBeanImpl.vsl. AndroMDA uses the internal representation of CustomerService loaded from the model, calls the processing engine twice, and two output files are generated: CustomerServiceBean.java and CustomerServiceBeanImpl.java.

In this example, classes with the <<Service>> stereotype actually generate two code classes – the Bean and the BeanImpl. But if we were using the class diagram as it was intended, wouldn’t there be a one-to-one mapping between a class in the model and a class in the code? As soon as you break that one-to-one mapping, you’re no longer modeling classes. A <<Service>> is something at a higher level of abstraction than a class – otherwise it wouldn’t take two classes to implement it.

BTW, I’m not saying that there is anything wrong with this approach at all! I’m just pointing out the similarities between an approach that many people are using to achieve practical results with UML today and what you can do with the modeling tools that Microsoft is building.

The key difference comes down to tools. Yes, you can use the class diagram and stereotypes to model stuff at a higher level of abstraction like Services and Entities. But putting a square peg in a round hole like that has problems. Since you’re not using the tools as they were designed, you have to manually enforce rules that the tool doesn’t know about. Sure, you can add some semantics via stereotypes, but you can’t take anything away. How easy is it to build a valid class model that isn’t a valid service model? Pretty easy. For example, do services support inheritance? Classes do. My EJB is a little rusty, but I don’t think beans do. It certainly doesn’t make sense for a service to inherit from an entity or vis-versa. Yet, the class modeler will happily let you do this, even though it makes no sense in the domain you’re actually trying to model.

The value of domain specific languages is that have a tool that is specifically designed to model the domain you’re working in. If you’re designing classes, of course you’d want to use a class model. We have a great one coming in VS2005. But if you’re designing services or entities or page flows or whatever else, why wouldn’t you want a tool that’s specific to the problem at hand?

This entry was posted by DevHawk on February 26, 2005. It was posted in Architecture. It was tagged Modelling.

Comments:

In general, I agree with the content of the post but... > But if we were using the class diagram as it was intended, wouldn't there be a one-to-one mapping between a class in the model and a class in the code? I suppose you are assuming that the Class Diagram is intended to be used for design purposes. Then, a class diagram could be considered simply as a code visualizer. In this case, what about nxn relationships? Why are they used in class diagramas if they don't have a one-to-one mapping? I think that the class diagram is usually (or sometimes) used for conceptual modelling purposes, where you are capturing the structure of your domain and not the structure of your software. Then, we need one-to-many mappings for converting the class diagram into software classes. Anyhow, I completely agree we should use DSLs. In fact we are all using DSLs when we are "intepreting" the semantics of UML (even when we use it without stereotypes) in the transformation from UML to code.
This comment was posted by Javier Muñoz on February 28, 2005 at 4:14 AM.
Javier already stated an obvious problem with your diatribe, so I will not go over that again. Although, if you look at elaborationist model driven development, you will see that there are "analysis" classes that are developed from use cases that then fan-out to "design" classes. And these _can_ also fan-out to "implementation" classes, depending on the implementation language... You also state: "Since you're not using the tools as they were designed, you have to manually enforce rules that the tool doesn't know about. Sure, you can add some semantics via stereotypes, but you can't take anything away." Actually, you can... To continue your example, I can define a profile that restricts the inheritance from "service" classes. This can be done today by attaching an OCL constraint to, for example, a class (and making it the default behaviour). Now if I were to create new icons for the service and have this type of constraint defined in the profile, I would have a DSL! Now there are cases where it is very difficult to extend UML to provide correct DSL support, but the example you provide in this post are not likely to convince people who understand how this works. And in cases where UML can not be used, then a DSL building tool would certainly help!
This comment was posted by Charles Rivet on February 28, 2005 at 8:31 AM.
Charles, I'm not sure I'd call this a diatribe, but your point is well taken. I did not realize you can use OCL to constrain the model - in the discussion that we had at the IASA user group meeting last week, that idea was rejected by those that use UML tools in this way as "not working very well". So maybe they're just using the wrong tool. Either way, as you point out, you end up with a DSL! My primary point is that how more similar these approachs are than they are different.
This comment was posted by DevHawk on February 28, 2005 at 6:52 PM.
I completely agree!!! Too many people are making up a lot of noise about how these approaches are very different when they are talking about basically the same thing: the need to present people with constructs that they understand at _their_ level of abstractions. If you can do that on a common base, then you gain the benefit of existing tools. But if the DSL is too complex for that common base, let's not shy away from creating a new tool. The important thing, in the end, is the user's productivity.
This comment was posted by Charles Rivet on March 01, 2005 at 7:13 AM.

Categories

Tags

Series

Disclaimer

The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion.