Thu Jan 15, 2004 3:26 pm
Hi
I am involved in a discussion on comp.object where the terms "model
of the problem domain" and "model of the solution" were used.
I was thinking that a domain model is a model of the solution but
just found
http://c2.com/cgi/wiki?DomainModel
Where "A DomainModel is an object model of a problem domain."
So would you say the Domain Model is a model of the solution or
problem?
ShaneMingins
Neither. It is a model of a domain. The domain with which the software is
concerned. I wrote those words on that wiki page, and I wasn't intentionally
trying to differentiate problem domain from solution domain. I just used them
because I think "problem domain" is understood by most people to mean "the
domain with which the software is concerned".
If you have Eric's book, he offers some profound characterizations of what a
domain model is on p.3.
Best Regards,
RandyStafford
>So would you say the Domain Model is a model of the solution or
>problem?
I don't understand what a model of a problem would look like, except
maybe a use case.
JohnBrewer
I have cut the OP from comp.object that started my question.
"Robert C. Martin" <unclebob@o...> wrote in message
news:cphb001es4luomkqi1k7ua7j2tp1h4l84s@4....
> On Wed, 14 Jan 2004 07:32:27 -0700, "Michael G" <mike-g@m...>
> wrote:
>
> >It seems to me that OO is less about managing dependencies and
more about
> >modeling problem domains.
>
> Why do you think that? Can you define what it means to "model the
> problem domain"? Can you then describe why OO helps?
>
> I am quite happy to stipulate that OO enhances expressiveness. I am
> also happy to use this increase of expressiveness to make my
programs
> more readable and understandable. However, I think the ability to
> manage coupling is far more important than the increase in
> expressiveness.
>
> Here is an example of my dilemma:
>
> The statement: "An integer is a real number." can be expressed in an
> object model as:
>
> |Real|
> A
> |
> |Integer|
>
> One might view this as an "OO model" of a problem domain.
>
> Any programmer who wrote code like that would have to be taken out
> back and shot. In a programming environment, real numbers are
> composed of several integers. Integers do not inherit from real
> numbers.
>
> What this tells me is that "OO Models" of the problem domain do not
> naturally translate well into an OO program. Indeed, it's not clear
> to me that the definition of the adjective "OO" when applied
to "model
> of problem domain" has any intersection at all with the definition
of
> "OO" when applied to a program. In the problem domain the arrow was
> being used to replace the term "is a". In an OO program inheritance
> is defined as the introduction of old declarations into a new scope.
>
> Since OO was first used as an adjective for programming, I think the
> programming definition trumps all others.
>
> Just my opinion.
>
And then later Robert differientiates between the problem/solution
model:
> The major flaw I see is confusion between modeling the problem and
> modeling the solution. A model of the problem is not executable. A
> model of the solution is executable, and is therefore a program.
So I was trying to relate this to Eric's book and a domain model.
Thanks
ShaneMingins
Reading this quote, I have to say I see things quite differently from
Robert.
I agree with him that Integer as a subclass of Real Number would not work
well as an implementation. THEREFORE, I would not choose that model as the
basis for work on such a project. There is always more than one way to model
the same thing. You should choose a model that is useful for the ends you
have. In this case, the end is a working Integer class. This case is so
trivial that we can only go so far with it.
The people who start talking about the problem domain and the solution
domain are basically saying "well, we'll model the domain without reference
to the need to write a program" (the "problem domain model", also known as
the "analysis model") and then we'll make a model that is really just an
explanation of the code we've decided to write (the "solution model", also
known as the "design model").
I explicitly reject this approach. I want ONE model that serves both ends. I
want a model of the domain that gives me an effective way of *thinking* and
communicating about the problem, AND can be the basis of a practical design.
This is what I mean when I say "model-driven design". It is not easy, but if
you keep experimenting, you can find such models, in my experience.
As I explain in the book in a couple of places, there is no such thing as
the "right" model. This is the problem with analysis models. They have no
purpose, and therefore no basis for choosing one over another. (Well,
expressive power is a criterion, I suppose.)
So, the mathematicions have settled on a model of integers being a type of
real number. That's nice for them. We shouldn't depart from that without a
good reason, but we have a good reason, and we don't have the requirements
they have (to do proofs and so forth). What we should do instead is find
another expressive way of relating the number types that also works in our
software environment.
"A model of the solution is executable, and is therefore a program." No,
models aren't executable. But a program can be constructed of elements that
express a model, if that model is properly chosen. I suspect what Robert and
I would actually do might be quite similar, but the way of describing it is
important.
EricEvans
Just a few thoughts to add...
Software applications exist in a context that defines how they provide value, and how they relate to other applications in a value chain supporting the business. This may result in the need to model more of the business domain than is actually implemented.
There are many perspectives from many stakeholders that have to be considered when building applications. For example, business architecture, software architecture, middle-ware best practices, implementation details, deployment, monitoring and maintenance, etc. This can result in the need for at least many views on the same domain model. It may also be helpful to separate these concerns so the model of the business does not include software or implementation architecture concerns. This reduces complexity, enables better participation by different stakeholders, and allows the business and IT platforms to change more independently. One can start with a model of the business domain itself, not considering software. Then this model is refined by choosing the subset that is necessary to support needed automated business applications, and the introduction of some chosen software architecture. This model is then refined to support the needs of a particular middle-ware platform or implementation domain. And so on. Essentially it boils down to successive refinement from abstract business concepts to concrete deployed implementations. Some of these refinements can actually be formalized in executable mapping rules created by experts in bridging between domains. This is the MDA promise.
However, I do agree with Eric that these various perspectives are not independent. Each refinement influences the whole end-to-end solution. As a result, creating a domain model without considering software architecture will either result in a less useful domain model or a potentially poor implementation. Creating different models and then bridging between them can be expensive, especially if the transformations have to be done by hand and require expert participation. There is likely a balance between separation of concerns and one domain model that will be different for different situations.
To be really useful, a model must be executable in at least some sense. Otherwise it cannot be validated and is really just speculation. Even executing the model manually to walk through critical scenarios or use cases may be sufficient. A business domain model that doesn't capture the business processes in sufficient detail to verify them introduces risks that the final implementation won't do what was intended. A customer often doesn't know what they want until you show them something that isn't it [Kent Beck]. Subject area and level of detail are independent dimensions. It is possible to be very detailed about the business without introducing the software subject area. Current modeling languages like UML are weak in this area, but improving.
JimAmsden
I should have added that OO is not a great way to model math. The example of
Real Number / Integer illustrates this, in a simplistic way. We get by with
a very limited model of numbers because most of our applications do little
math. Integers are used to count things, sometimes to add things up and
other simple arithmetic. Most of all, integers are used as identifiers,
which is just a technical thing, and has nothing to do with the abstraction
of numbers. These minimal needs we have allow us to give up on the
abstraction of Integers being Real Numbers without losing much.
As Ralph Johnson pointed out, when we get into serious math (and I've done
some, many years ago) OO gets in the way of the modeling process. It equally
gets in the way of implementation. It is better to have a modeling paradigm
that actually supports math, along with programming tools to match. You can
do math in Java, of course, but it doesn't support you.
EricEvans
Out of curiosity, what is an example of a "modelling paradigm that
supports math" and what would be an example of the associated programming
tools that support said modelling paradigm ?
thanks
CharlesMonteiro
Probably something like Fortran. For numerical applications, you
typically want to perform the same operation repeatedly over big
arrays of floating point data, preferably in a way that can be
optimized for vector processors.
JohnBrewer
Ok, so Fortran is the programming tool/environment what is the modelling
paradigm?
As far as simulations whether war theatres perhaps even stars exploding
isn't it possible to largely model such domains in OO but isolate the
number intensive computations as services of some entity which are
implemented externally i.e. in C etc.
thanks
CharlesMonteiro
Charles, et al
What a great topic!
To me, very little in software is absolutely right or wrong. The best
solution depends on the context--not only the domain, but the
surrounding issues like QoS, team capability, etc. Eric gave the
answer I would have, in response to the question about OO being
indispensable ("Not indispensable. Very useful in a lot of situations,
such as complicated business systems.").
Charles Monteiro said:
"As far as simulations whether war theatres perhaps even stars exploding
isn't it possible to largely model such domains in OO but isolate the
number intensive computations as services of some entity which are
implemented externally i.e. in C etc."
Following Eric's lead, I'll say that yes, you can largely model almost
any domain with any number of methods or hybrid approaches. The
question I always try to answer is: "what is the best model for this
problem and solution in this context?"
FSM's are, to me, a good example of something that can be modeled
successfully in different ways: STD, STT, OO, DSL (Domain Specific
Language).
Q: Which method is best?
A: It depends.
The model is important for many reasons, and the value we place on
different elements may lead us to one method or another. Eric puts a
lot of stock in reducing the "impedance mismatch" between the model
and the implementation--I tend to agree. I also value using the model
to communicate with the domain experts; what Eric calls the Ubiquitous
Language.
The model has to allow you to express the problem in the domain
completely; ideally it also makes it easy. The implementation must
allow you to express the solution to that problem. Domain experts have
to understand the model, developers have to understand both. The
Ubiquitous Language is the important bit, IMO, because it helps you
straddle the edge between them.
GreggIrwin
When I say OO isn't usually good for math, I am not refering to
computational efficiency. That can be an issue, but let's assume very good
optimizing compilers, etc. I find that OO is not a good modeling paradigm
for most of these problems. You could model parts of them and delegate
computation to something else, yes. (If it were computation speed that were
the limit, this could help.)
But the main value of modeling for software is to capture the core
complexity relevant to the problem. If the complexity comes in the math
itself, then that is the part that needs modeling. The other parts may or
may not be worth modeling in objects, but if you are trying to model fusion
reactions and gravity and convection in a collapsing star (and I don't know
that domain, I'm just throwing those out for my argument's sake) then that
is probably where the complexity lies. And it just isn't usually useful to
break these kinds of domains up into objects with relationships and
responsibilities.
EricEvans
I understood that but I guess that it breaks my heart that I cannot use OO
and probably therefore Smalltalk to model some of the very interesting
problems that I was hoping to get to and a star going supernova was
certainly high on my list :)
I am not a domain expert in such fields but when I have thought about, for
example modelling an atom my thoughts went as follows:
An atom is composed of:
nucleus
electrons or perhaps electron orbits which contain electrons
there is a physicial relationship between the atom and its electrons i.e.
beyond simple composition , one of atomic level attraction that I need to
model
that attraction may have some numerical expression (a number, a magnitude
level) which scientist use to understand the attraction,
said numerical expression is derived from a formula
said formula may require input from attributes of the "attraction entity"
or perhaps other involved entities and perhaps some constant "truths" etc
I just can't help but to want to model these physical entities as objects.
I guess as Ralph points out because it feels natural. But what is the
value of modelling these as objects? I guess to me for example if one was
developing simulations it would be easy given the tools that I know to
alter the attributes of entities , the relationship between entities, to
create visualizations based on these entities etc and therefore test
theories based on changing aspects of what one was simulating etc.
As I said I don't have a background in said type of domains so perhaps I
am being naive.
CharlesMonteiro
Actually, mathematics is it's own modeling paradigm.
If you're looking for computational support, the answer depends on what
you mean by "supports math".
Do you mean:
- allows you to describe algorithms in a way a mathematician might find
natural or convenient?
- allows you to describe mathematical expressions in a way suitable for
symbolic manipulation?
- enables you to describe calculations in a way that they can be
performed quickly?
- represents symbolic logic in a declarative form?
- caters to some particular branch of mathematics like Statistics,
Abstract Algebra, Lambda Calculus, or Vector Calculus?
Here are a few popular programming languages/environments that support
math: Mathematica, Mathlab, Maple, Common Lisp, Java, C++, Fortran, APL,
S-Plus, SPSS, and Prolog. There are myriad specialized packages.
Beware of recent scripting languages. It takes time and a great deal of
care to define mathematical primitives precisely and unambiguously. If
the primitives are buggy, you'll get bitten. ;-)
Not all mathematical applications deal with calculations over real or
complex numbers. For mathematics related to symbolic manipulations (e.g.
abstract algebra, symbolic integration, automated theorem proving),
Fortran is probably a poor choice. On the other hand, for Computational
Fluid Dynamics, it's still in use.
JohnDCorbett
Granted and understood but see my other post to understand my
confusion/question better. My approach to domains that are "math" heavy is
to use OO to model what I understand the entities and their contracts to
be and to isolate the heavy math computations into "primitives" for lack
of a better term i.e. services of an entity that are implemented
externally in something closer to the metal i.e. C.
BTW, one glaring omission from your list of languages that support Math
would be Smalltalk.
-thanks
CharlesMonteiro
"No, models aren't executable."
Why?
Being a model a simplified description of something for the sole purpose
to handle aspects of that something without the need to handle the thing
itself; seem to me that one important of those aspects is testing the
model, therefore must be executable.
The artificial world of software makes that we handle concepts in the
computer which sometimes exist as physical things and sometimes just as
conventions, so the mere executable programs in a computer are models of
something else.
MarcoDorantesMartinez
A model is a set of concepts. A programming language that supports a
modeling paradigm let's you express the model quite directly. But the
program isn't the model. A UML diagram can be used to communicate a model,
but it isn't the model. I guess this seems pedantic, but I think it is an
important distinction.
The value of OO is having a programming language that directly supports the
model concepts when they are structured according to that paradigm (objects,
associations, etc). The same is true of Prolog, which supports a different
model paradigm with predicates and rules.
C is a perfectly good programming language, but it doesn't relate to a
modeling paradigm. A model-based solution can be worked out by a C program,
but it is much less direct.
EricEvans
> When I say OO isn't usually good for math, I am not refering to
> computational efficiency. That can be an issue, but let's assume
> very good optimizing compilers, etc. I find that OO is not a good
> modeling paradigm for most of these problems. You could model parts
> of them and delegate computation to something else, yes. (If it were
> computation speed that were the limit, this could help.)
A good example of this dichotomy is electronics design simulation.
If you are building a digital logic simulator, then objects can be a big
help because they model discrete component interactions over incremental
time steps very well.
If you are building an analog electronics simulator, then discrete
objects will be of little value. Analog electronics are best described
by continuous mathematical formulas. Good functional composition is
valuable here, which *can* be done in objects, but those objects
essentially will be imitating functions. Functional notation tends to be
simpler for this.
PatrickLogan
WhatIsADomainModel is mentioned on: ThreadView
