> > A domain model is an object model, but there is more to the
> > model for a complete system than a domain model. ...
> > [...]
> > As an aside, our method (Catalysis) uses type-based (rather
> > than class-based) models for domain modeling, which helps in
> > at least two ways: it reduces the tendency to fall into concerns
> > about design and/or implementation too soon, ...
> Can you explain, what you mean by this statement?
In a nutshell: class-based models are in some ways too
similar to OO programming constructs. In modeling the
problem domain, the goal is to understand and clearly
represent the problem itself, and not solutions. When
using type-based models, it becomes easier to maintain
this focus, by staying away from issues about classes
and instances, implementation inheritance, etc. Type
models don't carry as much of this baggage; they more
directly correspond to problem-domain entities, while
effectively supporting OO decomposition, and interface
specification and inheritance.
> What are modeling actions that
> - are class-based specific,
> - are related to design and/or implementation and
> - "happen" during analysis/domain modeling?
I wouldn't say that the issue relates very much to any
"modeling actions;" it's more a question of what one
thinks about and represents than how one actually does
the modeling. The "modeling actions" as well as nota-
tional conventions are pretty much the same with class
models and type models, but the interpretation of the
models is different.
What too easily happens that relates to design and/or
implementation when using class-based models is starting
to focus on solution-related issues and details, such as
how to carry out processing, rather than what the agents
and effects of the activities are in the domain.
Quote:> Do you think of structuring the domain model with design/im-
> plementation in mind instead of structuring it the way domain
> expert see it?
I'm not sure I understand your question. If you are making
reference to your previous questions, and suggesting that
this might be my answer, then: yes, exactly.
> > ... and it supports a
> > clear and explicit statement of the relationships between the
> > domain model and design models, once you reach that stage. ...
> Does this mean that one should change the method(ology)
> during projects to have a clear "border" between analy-
> sis and design? (I'm not kidding but some people do
> think this way: "Don't do OOA because when you do, you
> start with design...")
Yes, I think (and we teach) that there is value to a
clear division between domain analysis/modeling and the
design of solutions. Part of that division comes from
breaking the requirements into two sets: those which are
inherent in the problem, and those (such as hardware or
performance specifications) which constrain the possible
solutions without affecting the problem itself. Another
part, in Catalysis, is showing the progression of models
via explicit refinement relationships, which supports full
traceability back to specific requirements.
> > ... We
> > use the same notation for type modeling, but the interpretation
> > of the symbols is a bit different. In particular, subtyping
> > does not involve overriding, but only extends the supertype.
> Do you see "overriding" as design/implementation driven in
> this context?
I see it as only being *useful* when considering design,
and especially implementation. (I was really just trying
to clarify the distinction between types and classes, as
the languages tend to muddle these pretty thoroughly.)
William D. Gooch
Texas liaison for the International Programmers Guild
For info on IPG, see http://www.ipgnet.com/ipghome.htm