Domain Models

[Paul Newton]

Just a quick question to you all...
A domain model is a 'visual vocabulary' of the domain. It models the existing business domain, not the software.
Okay. Larman suggests deriving a domain model based on the Use Cases for a particular iteration. This is then used as 'inspiration' for the design model.
The RUP book says that a domain model is largely written before the Use Cases, as a way of understanding the business domain. This is then used as input into both Use Case and Analysis models.
Maybe it is a hazy science. Design is rarely linear. But can anyone clarify this?
regards,
paul.

[Kyle Brown]

Well, it's historical.
Larman is coming from the Smalltalk modeling community from a tradition that comes from Tektronics and Xerox Parc. Probably the best description of this is the book "Designing object-oriented software" by Rebecca Wirfs-Brock.
In this tradition, the "domain model" is anything that's not either (a) a Presentation layer object or (b) an Infrastructure (database) layer object. Creating a domain model is something that makes up the bulk of OO design.
On the other hand, the RUP process has been heavily influenced by Jim Rumbaugh's point of view. Jim comes from a relational database tradition. In the relational world, you would often come up with a relational model that describes the world in "generic" terms before you ever begin considering the physical constraints of your particular implementation.
Later on, Ivar Jacobson put a more function-oriented spin on things. Ivar's point of view is that you have to do deep requirements analysis (use cases) before you can begin modeling the objects in your system. What his modeling would consist of, however, was actually something more like what Rebecca would call object-modeling or domain modeling.
So, when UML was being born, both Ivar and Jim had to try to merge their viewpoints into a single set of terms. So, what used to be called "conceptual modeling" or "logical modeling" became known as "domain modeling". This is very different than what Rebecca would have defined "domain modeling" as.
So, which do you choose? Personally, I've got zero, zip, zilch use for the UML/RUP definition of "domain modeling" happening before you do use cases. Instead, I'll do what Craig does, which is start with the use cases, and then do modeling based on the organized requirements that you get with use cases. I'll call that "domain modeling", as Rebecca would because it's just that -- it's building a model of your problem domain -- however, it's a model that's constrained by the REAL requirements of your system.
I've seen too many modelers get paralyzed by trying to model the "real world" appart from the constraints of the system they're supposed to be building. So, I say go ahead -- it's not going to be perfect, but then again, what ever is? I'd rather have something than nothing...
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.
[This message has been edited by Kyle Brown (edited October 11, 2001).]

[Paul Newton]

Many thanks for the reply Kyle. Much appreciated.
I did not realise that RUP had such 'internal tensions'. The approach to domain modelling was one area which troubled me - I think you've explained it very well.
This does lead on nicely to my next question. Another area in RUP which seemed unclear to me, was the notion of an analysis model. Again, the name seems to be widely used in different senses - often meaning some type of domain model.
The RUP Analysis model is one which focuses on the functional requirements of the system. In this way, it can be seen as a 'first-cut' at a design model.
Larman refers to this RUP analysis model in his book, and doesn't seem to have much time for it. He says that his discussions with the RUP community show this to be an optional step. In the RUP book, this doesn't seem to be the case - RUP outlines some situations where an analysis model might be less useful, but they certainly don't (at least in my reading) view it as 'optional'.
I am not exactly clear what the real goal of a (RUP) analysis model is - other than the vague goal of 'understanding the problem better'. It focuses exclusively on functional requirements and ignores non-functional requirements, so cannot be viewed as an architectural diagram. So, I would view this model (as RUP states) as a first attempt at application design. In which case, why include it as an explicit first modelling step - when it might be better seen as just part of the natural, iterative design process?
As a final point, they focus on classifying analysis classes as boundary, control or entity classes. This, I think, came from Jacobsons Objectory? Another question would be how useful, in people's experience, this classification really is. Would it not be better to classify classes on a more general 'pattern' level (controller/factory or more applied such as moment-interval/roles).
I would be very interested to hear peoples opinions on this (or any other aspect of RUP).
regards,
paul.

[Jes Sie]

Originally posted by Paul Newton:
Many thanks for the reply Kyle. Much appreciated.
I did not realise that RUP had such 'internal tensions'. The approach to domain modelling was one area which troubled me - I think you've explained it very well.
This does lead on nicely to my next question. Another area in RUP which seemed unclear to me, was the notion of an analysis model. Again, the name seems to be widely used in different senses - often meaning some type of domain model.
The RUP Analysis model is one which focuses on the functional requirements of the system. In this way, it can be seen as a 'first-cut' at a design model.
Larman refers to this RUP analysis model in his book, and doesn't seem to have much time for it. He says that his discussions with the RUP community show this to be an optional step. In the RUP book, this doesn't seem to be the case - RUP outlines some situations where an analysis model might be less useful, but they certainly don't (at least in my reading) view it as 'optional'.
I am not exactly clear what the real goal of a (RUP) analysis model is - other than the vague goal of 'understanding the problem better'. It focuses exclusively on functional requirements and ignores non-functional requirements, so cannot be viewed as an architectural diagram. So, I would view this model (as RUP states) as a first attempt at application design. In which case, why include it as an explicit first modelling step - when it might be better seen as just part of the natural, iterative design process?
As a final point, they focus on classifying analysis classes as boundary, control or entity classes. This, I think, came from Jacobsons Objectory? .

Just so that we're in sync, Craig Larman's book emphasis is on UP and he doesn't do much on RUP. I think it's purely Craig's personal opinion to say it's "Optional" as this was considered an crucial step in RUP.
The classification of Boundary, Control and Entity does help in analysing Use Cases. It represents an early conceptual model of the system before you go into full blown non-stereotype Design diagrams. Personally, the classification did help me to allocate responsibilities to classes.

Another question would be how useful, in people's experience, this classification really is. Would it not be better to classify classes on a more general 'pattern' level (controller/factory or more applied such as moment-interval/roles).
I would be very interested to hear peoples opinions on this (or any other aspect of RUP).
regards,
paul.

Most of the experts that I was mentored by....well, have not heard of Analysis model and obviously they don't practice it. I've attempted to work with it...but it just bogged me down...perhaps the project is way too small for such details. Sometimes it's easy to come up with the Design diagram straight away instead of having an intermediate like Analysis classes. Also, what Rational claimed is that Analysis classes rarely survive in the Design unchanged.

------------------
Thank you.
- Simon See
[e-mail]
-after office hours-
necro-mani-cide

[Kyle Brown]

Yes, I concur. I find no use for a separate Analysis and Design model either. That's a holdover (IMHO) from the old structured methodologies where there WAS a difference between two models. However, they didn't have use cases
Now, I do see uses for Ivar's Boundary, Controller and Entity categories -- I've found it maps half-way decently to MVC is many ways. Take a look at Conollan's "Building Web Applications with UML" for an interesting take on mapping these stereotypes to web technologies.
Kyle
------------------
Kyle Brown,
Author of Enterprise Java (tm) Programming with IBM Websphere
See my homepage at http://members.aol.com/kgb1001001 for other WebSphere information.

[Paul Newton]

Simon, Kyle - thanks for the feedback.
I did skim through Conallen's web book while trying to find examples of J2EE web app notations in UML (don't suppose either of you can help?!). I felt it was a little ASP/Microsoft heavy, as well as an obvious Rational focus, so I didn't really dig deeper. It looks like another visit is in order.
thanks again -
regards,
paul.