A bit late on this thread, but I wanted to throw in my 2 cents anyway. UML diagrams are a poor medium for communicating with the customer, in my limited experience (of communicating with customers via UML). Even if the customer is slightly technical, it is hard to grasp one-to-many and many-to-many relationships if you've never worked with a database before, and inheritance/generalization concepts may be hard to grasp also. The most useful UML device is the use case, and the benefit (problem?) here is that UML does not specify how use cases should be built. Each organization needs to standardize on a use case format, it shouldn't be technical (e.g., hierarchical use cases which become too low-level and hard to follow), and each element of the format (actors, preconditions, postconditions, included use cases, etc.) should provide real value down the road to design.
I agree with the previous poster who said that Object Role Modeling (ORM) is much more useful for the contract with the customer; in fact, I learned about ORM through this list! UML models are naturally derived from an ORM model, so I believe that the customer's exposure should be limited to use cases (and use case diagrams?) and the ORM model. As some experts such as Martin Fowler suggest, I find class diagrams to be very useful in conjunction with writing the use cases. The class diagrams should be conceptual at this point, i.e., not specifying multiplicities (n-ary relationships) or aggregation/composition, just classes and associations, until the domain is better understood and the class model can be refined further. However, class diagrams alone are not sufficient for describing the design of an OO system; when it comes down to the design iterations, I find sequence diagrams to be essential. As Martin Fowler (I think) also notes, it is not necessary to use both sequence and collaboration diagrams, for the two are equivalent, and Fowler is (was?) proposing sequence diagrams to be part of "core UML". These are invaluable in determining (discovering) the methods and collaborations of the classes. At this stage, I don't find it particularly useful to do sequence diagrams for every use case/scenario, but it is useful, however, to do some representative diagrams in order to come up with *patterns* of methods and collaborations that can then be applied throughout the implementation. If you have the time and money, then go ahead and complete the design! But it is imperative that you use a tool that will not hinder your ability to draw and modify these diagrams efficiently, such as I found with Visio 2000 Enterprise Edition. I like Objecteering Personal Edition (which I used a couple of years ago), and Rational Rose the most, the latter of which came out top in a Yphise evaluation of several enterprise tools, including Objecteering, GDPro, Cool:JEX, and Paradigm+. People are talking about UML in the context of CMS in two completely different ways here - one of them is to use UML to describe the design of the CMS itself (and is not needed for external customers) to the CMS developers, and another is to use UML to describe/design the CMS application with the customer. This distinction brings up one fundamental point about CMS, IMHO - that although a CMS may be an OO application, a CMS application may not be a pure, or at least conventional, OO application! Of course, it depends entirely on the design of the CMS, but let's look at our own CMS, Progenyx, for this discussion. It is OO, written in Java, and can have a nice UML diagram that describes all of the classes and methods. When it comes down to building an application, the model is also OO, only the classes are described, and not their methods. The model can have inheritance (generalization/specialization), but (conceptually) the methods are polymorphic across all the classes, and embody the functionality of the CMS itself. Thus, all classes need to be able to provide the services of the CMS such as versioning, workflow, security. In a way, content objects are "stupid" and only know about content, not real world behaviour. Well, behaviour, if you think about how content should behave. If you want a piece of "content" to be able to act as a controller in a MVC (model/view/controller) pattern, then our CMS doesn't support it and would have to be extended. In a typical J2EE application, one would have separate Java classes (EJBs, perhaps) to represent the classes in the UML design model, and each class could potentially have different behaviours. In a typical CMS application, the classes in the UML model would be represented by ONE Java class, i.e., the one used to access the content and provide the entry point into the rest of the API. In order to extend the functionality of (add methods to) a class, an interface would need to be designed that allows methods to be called via reflection and/or scripting which doesn't require recompilation of the CMS itself. This, in technical terms, is what I think defines a CMS. This has extended past the scope of the original discussion and into "OO and CMS", but I think it's still on topic. Regards, Daniel Ansari -- http://cms-list.org/ trim your replies for good karma.
