Updates
Latest Tweet
What's New?
Check out for latest innovation, a computer based training video collection
Like this Page
The UML Profile for Framework Architectures Review by wiredweird
Good in lots of ways
First, it's a very clear example of how to extend UML within its own rules for extension. Other authors need more than raw UML gives, so start adding cruft any way they want - wrong! UML was meant to be extended and has explicit points at which extension is allowed. This shows extension as it's meant to be done.
Second, it is a worthwhile application area. Frameworks have been around for years, important all out of proportion to the relativley small number of them and relatively small number of framework developers. Framework development deserves attention as a specific discipline, and it's good to see this kind of attention being paid. The authors have chosen parts of well known design patterns for examples, keeping the ideas readable and understandable.
Best, it doesn't try to pull the entire UML standard into the discussion. To tell the truth, if I printed out the whole set of UML standards documents, I'm not sure I'd be able to lift the pile. This uses a well-chosen subset of the standard, but still lets the afficionado use as much more of the standard as desired.
Still, it's just notation. It's a set of tags for making statements about frameworks. The book doesn't really go into the design of frameworks. Framework design appears to be a premise, something the reader already understands well - perhaps not a good assumption.
The real problem with this notation, though, is that it is barely useable without tool support. It's based on sets of tags, which refine other tags (using something like inheritance), which refine yet other tags. Looking at tag A, though, there is no way to know that it refines tag B. Nothing about the tag indicates its family tree of inheritance, or even where to look for the information. Also, the UML extension mechanism for tags appears not to have dealt with global uniqueness at all. Nothing prevents me and you from coming up with the same tag names independently, then causing collisions for our common customer. XML deals with global uniqueness fairly well. If XML conventions are compatible with UML, they should be used - if not, UML needs to create conventions.
On the whole, this is interesting and informative. It's nearly impossible to put to practical use without significant automation, however, and that automation is not available to me.