tagged by: uml
What does it mean to have a standard UML, and why the standard doesn't standardize as many things as people think it does..
At UML World in 2000 we had a panel discussion on whether we should have a kernel for the UML. SD Magazine turned it into a surprisingly coherent article (there's nothing like a good editor!) Take a look to see how frighteningly small I would make the kernel.
Few things in the UML cause more consternation than aggregation and composition, in particular how they vary from regular association.
One of the new notations that appeared in UML 2 was the socket notation to show interfaces required by a class. The origins of this was the 'lollipop' notation that was popularized by Microsoft to show a class implementing multiple interfaces. So I can show that the Array class implements multiple interfaces like this.
Lets say you have an album class which has an ArrayList of tracks. How do you show this in a UML class diagram?
What is the difference between dependency and association?
How do you represent derived information in the UML?
UML use case diagrams define a bunch of relationships between use cases. The two best known are include and extend. There seem to be more questions on these two relationships than on any other part of use cases, perhaps even anything in the UML.
How do you show local variables (parameters, temps etc) on UML class diagrams?
Some people think that Model Driven Architecture (MDA) will be biggest shift in software development since the move from assembler to the first high level languages. Others think that it's nothing more than Night of the Living Case Tools. I'm in the latter camp but feel the need for more than a slick saying.
Model Driven Software Development (MDSD) is a style of software development that considers itself as an alternative to the traditional style of programming. The approach centers itself on building models of a software system. These models are typically made manifest through diagrammatic design notations - the UML is one option. The idea is that you use these diagrams, to specify your system to a modeling tool and then you generate code in a conventional programming language.
When data modeling methods talk about relationships, they use the term cardinality to indicate how many entities may be linked together. So you might have a relationship between order and customer and say that the cardinality of the relationship is one-to-many. Or you might hear that the cardinality of customers for an order is 0-to-many.
One of the big claims about Model Driven Architecture (MDA) is that it allows you to develop a system in a Platform Independent Model (PIM) that can then be transformed into Platform Specific Models (PSM) for technologies such as .NET or Java. An alert reader should say to this: "hang on a moment, isn't the whole point of Java to be platform independent? So why would I want some platform independent technology that generates another platform independent technology?"
Last week the OMG adopted the superstructure document for UML 2. In practice this means that UML 2 is agreed on. There are numerous changes to the UML in UML 2 - it represents the biggest overhaul to the UML since the UML was originally agreed on. For general users the most obvious changes are probably:
In UML Distilled, I bemoaned the fact that there isn't a good book on teaching UML's activity diagrams. There still isn't, but I recently came across Conrad Bock's articles on UML 2.0 . Amongst these there is a series of articles on activity diagrams that go into more depth than I was able to cover in Distilled. (For those who don't know, Conrad Bock is one of the leaders of the activity diagram work in UML 2.)
For a long time engineering influenced software processes have looked for a way to express software designs in such a way that the designs can be handed off to a separate group to write the code, much as blueprints are used in building bridges. This would allow rare and expensive software designers to concentrate on the blueprints while many cheaper coders concentrate on construction.
Yesterday I was poking around a code base, looking at the domain model part of the code. When exploring a code base, I like to take notes to help me remember what I'm learning. For some code bases, in particular domain models, I find it handy to sketch UML class diagrams.
If you can detail the UML enough, and provide semantics for everything you need in software, you can make the UML be your programming language. Tools can take the UML diagrams you draw and compile them into executable code.
The promise of this is that UML is a higher level language and thus more productive than current programming languages.
In this UmlMode developers use the UML to help communicate some aspects of a system. As with blueprints you can use sketches a forward engineering or reverse engineering direction. Forward-engineering draws a UML diagram before you write code, while reverse-engineering builds UML from existing code in order to help understand it.
While I was looking at UML 2, it occurred to me that people differ about what should be in the UML because there are differing fundamental views about what the UML should be. As I thought about this, I came up with three primary classifications for thinking about the UML: UmlAsSketch, UmlAsBlueprint, and UmlAsProgrammingLanguage. (Interestingly Steve Mellor independently came up with the same classifications.)
Use cases are a technique for organizing and eliciting requirements. They were originally popularized by Ivar Jacobson in the late 80's and early 90's.