Steve Cook and I, in our 1994 book Designing Object Systems, were the first people to set out clearly the different purposes of object models, especially the distinction between a model of a situation (sometimes called a model of the world) and a model of a software system. It seems ridiculous now, but back in the early 1990s many people believed that models of situations in the world could just be treated as software designs if you squinted a bit.
I say it seems ridiculous, and I thought the whole issue was settled back in 1997 when Martin Fowler explicitly endorsed our approach in UML Distilled, but I was disturbed to hear from Keith Braithwaite recently that he still encounters many developers who have been taught UML without grasping this essential point.
There has been a backlash against modelling driven by the wastefulness of many large projects during the last fifteen years. These projects valued models over code and paid the price. But there is still a huge value in having a language at a higher level of abstraction than code that developers can use to organize and communicate their thoughts. The UML - for all its faults - can be this language, but not unless we teach people how to use it properly. Understanding the different purposes of models is absolutely key to this. How can we make sure this subject is properly covered whenever and wherever UML is taught?
Subscribe to:
Post Comments (Atom)
4 comments:
Indeed: woe betide the candidate who comes to interview with me having claimed on their CV to be an "expert" in UML.
I'm lucky to have had training in John and Steve's techniques back in the day. The distinctions to be drawn between modelling (someone's opinion about) a situation in the world, specifying a system to help with same and describing the design of an implementation of that have been invaluable to me over the years.
In fact, it's only a few weeks since I was able to revive a stalled project by using exactly that approach to free the users to talk about their world without worrying about how their desires were to be met. In all the decades that those folks have been having software built for them it seems that no-one ever let them know that they could do that.
Meanwhile, so-called Domain Driven Design seems to be going some way towards rehabilitating the activity of "modelling". I wonder how well these valuable distinctions are understood in that community?
Perhaps a good start would be to deal with the misnomer 'object oriented analysis'?
IMHO there's something seriously wrong with OOA. The way I see it being used is as
1) a domain model from a design perspective, in which case they're not really an analysis artifact
or
2) a domain model from an analysis perspective, in which case it's not really a good object-oriented model but rather a disguised data model.
Most books promote something similar to 2) and indeed still don't make a proper distinction between analysis models and design models.
Unfortunately that means that the 'pupil' gets a bad understanding of building OO models in general (ie data-centric).
I've always found it 'better' to focus on the behavioural aspect of objects first, and let the structure be defined by that (instead of starting out with a datamodel and adding a few operations here and there). I.e. work out interactions first (a bit superficial : sequence diagrams before class diagrams).
It's the main reason I created Trace Modeler, a specialized sequence diagram editor to make that approach feasible, see http://www.tracemodeler.com .
Love to hear your thoughts on this!
Yanic
I have to disagree with your suggestion, in analysis, to
"focus on the behavioural aspect of objects first" by doing "sequence diagrams before class diagrams".
I'm fairly clear that objects with operations invoked by messages from other objects should have no part in an analysis model. This is because this method of communication is point-to-point and synchronous, and doesn't correspond with what happens in the real world that's the subject of a analysis model. So, no sequence diagrams in the analysis model.
State diagrams are a better way to capture dynamic behaviour in the analysis model, because they make less assumptions about the communication between objects.
Steve Cook used to use an example to make this point. Imagine an analysis model of sunrise. Do you really want the sun object to get a rise message, and then to send a "startTweeting" message to each bird? In which order will you send messages to the birds? It seems better to say that the sunrise event happens, and that as a result, each bird transitions to the tweeting state. No assumptions about the communication, which is really about the design of some system you might later build.
- Dave
In reply to Yanic:
I'm not sure what "analysis" is. But if you want to create a model of a situation in the world (i.e. nothing to do with software) then, like Dave, I don't think sequence diagrams are appropriate. I much prefer the use of shared events to describe the moment when state changes. Dave's explanation of why is spot on.
However, I do think that starting with the events is a good alternative to starting with the domain objects. The effects of the events will have to be described in terms of changes in state of the domain objects, so really the whole model evolves together.
One reason for starting with the events is that it scopes the model: there is no point in including in the model classes that are not affected by any event. Conversely, for any class you must ask "what are the events that change the attributes or relationships of objects of this class?" In this way the behavioural and structural aspects of the model can be kept consistent.
Post a Comment