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? .
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).