Object models, Domain models, Application models, and MVC?

Object models, Domain models, Application models, and MVC?

Post by Markus Beckman » Tue, 15 Oct 1996 04:00:00




> 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? What are
modeling actions that

  - are class-based specific,
  - are related to design and/or implementation and
  - "happen" during analysis/domain modeling?

Do you think of structuring the domain model with design/im-
plementation in mind instead of structuring it the way domain
expert see it?

Quote:> ...                                          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...")

Quote:>                                                        ... 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?

Quote:> [...]

MB

("Followup To" set to comp.object)

 
 
 

Object models, Domain models, Application models, and MVC?

Post by Bill Gooc » Wed, 16 Oct 1996 04:00:00





> > ....
> > And then what really set me off, in the Sep 96 Object Magazine issue
> > (several articles on ST; you should all read it), Brown and Whitenack
> > propose a 4-layer approach. From outside-in: (1) View layer, (2)
> > Application Model layer, (3) Domain Model layer, (4) Instrastructure
> > layer. Sounds great, but what is the difference between the application
> > model and the domain model?

> An "application model" in Smalltalk jargon is a model that
> supports interaction behavior, and sits essentially between the
> business model (the implementation of the conceptual domain
> model) and the user interface.  It is not uncommon for the
> business model and the application model to be merged, unless
> there is the intent for the business model to be reused, or in
> some fashion shared, either among multiple applications, via
> a database, or whatever.

Thanks to Alan Knight for correcting me on this point.  As
he pointed out, it is a very bad idea to merge application
model (user interface structure/behavior) with the business
model.  I'm not sure what I was getting at in the above, but
suffice to say that the way it came out was just plain wrong.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
William D. Gooch
Icon Computing

Texas liaison for the International Programmers Guild
For info on IPG, see http://www.ipgnet.com/ipghome.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 
 
 

Object models, Domain models, Application models, and MVC?

Post by Robert C. Mart » Thu, 17 Oct 1996 04:00:00


I think it was Alan Knight who wrote this.

Quote:> > An "application model" in Smalltalk jargon is a model that
> > supports interaction behavior, and sits essentially between the
> > business model (the implementation of the conceptual domain
> > model) and the user interface.  It is not uncommon for the
> > business model and the application model to be merged, unless
> > there is the intent for the business model to be reused, or in
> > some fashion shared, either among multiple applications, via
> > a database, or whatever.

This sounds very much like Jacobson's Entity/Controller/Interface model.

In any case I like the separation of concerns.  Business objects tend
to get bloated if they are filled with the concerns of every application that
uses them.  It is better to separate out the application specific methods
into "controller" objects so that the Business objects remain reusable.

This does not mean that the Business objects become * data structures
with nothing but accessors and mutators.  The methods that are intrinsic to
the business concept that is being encapsulated will still be present in the
business objects.

--
Robert C. Martin    | Design Consulting   | Training courses offered:

14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.veryComputer.com/  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

 
 
 

Object models, Domain models, Application models, and MVC?

Post by Bill Gooc » Thu, 17 Oct 1996 04:00:00




Quote:> I think it was Alan Knight who wrote this.

No, I wrote it and Alan posted a correction, which I
agreed with (see my post from yesterday on this subject).

Quote:> > > An "application model" in Smalltalk jargon is a model that
> > > supports interaction behavior, and sits essentially between the
> > > business model (the implementation of the conceptual domain
> > > model) and the user interface.  It is not uncommon for the
> > > business model and the application model to be merged, unless
> > > there is the intent for the business model to be reused, or in
> > > some fashion shared, either among multiple applications, via
> > > a database, or whatever.

> This sounds very much like Jacobson's Entity/Controller/Interface model.

> In any case I like the separation of concerns.  Business objects tend
> to get bloated if they are filled with the concerns of every application
that
> uses them.  It is better to separate out the application specific methods
> into "controller" objects so that the Business objects remain reusable.

> This does not mean that the Business objects become * data structures
> with nothing but accessors and mutators.  The methods that are intrinsic
to
> the business concept that is being encapsulated will still be present in
the
> business objects.

Agreed.  My statement quoted above was muddled.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
William D. Gooch
Icon Computing

Texas liaison for the International Programmers Guild
For info on IPG, see http://www.veryComputer.com/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 
 
 

Object models, Domain models, Application models, and MVC?

Post by Faisal Wari » Fri, 18 Oct 1996 04:00:00



[...]

Quote:>In any case I like the separation of concerns.  Business objects tend
>to get bloated if they are filled with the concerns of every application that
>uses them.  It is better to separate out the application specific methods
>into "controller" objects so that the Business objects remain reusable.

>This does not mean that the Business objects become * data structures
>with nothing but accessors and mutators.  The methods that are intrinsic to
>the business concept that is being encapsulated will still be present in the
>business objects.

I think this also leads to the idea of 'roles' being separate from 'type'.

I like Envy / IBM Smalltalk's ability to define extensions. I think
extensions are a useful construct for separating roles.

Faisal Waris

 
 
 

Object models, Domain models, Application models, and MVC?

Post by Andy Bow » Fri, 18 Oct 1996 04:00:00



Quote:>I think it was Alan Knight who wrote this.
>> > An "application model" in Smalltalk jargon is a model that
>> > supports interaction behavior, and sits essentially between the
>> > business model (the implementation of the conceptual domain
>> > model) and the user interface.  It is not uncommon for the
>> > business model and the application model to be merged, unless
>> > there is the intent for the business model to be reused, or in
>> > some fashion shared, either among multiple applications, via
>> > a database, or whatever.
>This sounds very much like Jacobson's Entity/Controller/Interface model.
>In any case I like the separation of concerns.  Business objects tend
>to get bloated if they are filled with the concerns of every application that
>uses them.  It is better to separate out the application specific methods
>into "controller" objects so that the Business objects remain reusable.
>This does not mean that the Business objects become * data structures
>with nothing but accessors and mutators.  The methods that are intrinsic to
>the business concept that is being encapsulated will still be present in the
>business objects.

I'd like to discuss what I think is a better framework than
traditional MVC.

With the Dolphin Smalltalk framework (as it is in Beta 1) we had gone
for a typical MVC split of responsibility i.e.

Domain Model ~~ Application Model ~~ View & Controller

The ~~ denote dependency links. We renamed the Application Models to
be Tools since this seemed more descriptive bearing in mind their
concern was to allow a user to interact with business objects down in
the domain model. A bit like using a spanner to interact with a car
engine. Anyway the requirement is there for something to sit between
the View&Controller pair (which are usually quite generic) and the
Domain Model which is  business specific. The Tool/Application Model
is therefore allowed to "know" something about the user interface
while it manipulates the domain.

However, increasingly we came across problems with this approach. Most
were caused by the Observer (pattern) connection between Application
Model (AM) and View. The difficulty here is that we have already said
that the AM is allowed to know about the View. For example, it may be
responsible for enabling and disabling View widgets or changing
colours to show validation errors and such like. However, because the
coupling between AM and View is loose it becomes difficult for this
sort of interaction to take place. VisualWorks users will be familiar
with the roundabout:

        builder componentAt: 'aViewName'

method of accessing Views from within the AM.

One of the problems here is that the dependency mechansim between AM
and View is being used for two, rather different reasons. First it is
being used to implement the Observer pattern. This allows several
Views to observe a single model and display changes to it while the
model knows nothing about these Views. However, we have already seen
that an AM needs to be able to communicate with its Views so the
potential use of Observer is weakened here. As soon as you have to use
"componentAt:" you've broken the Observer pattern.

Secondly, the dependency mechanism allows an adaptive coupling between
the model and view. We want to be able to plug different generic views
onto more specific models in many different ways, for maximum re-use.
Thus the interface between the two needs to be flexible or simple or
both. This is ability is implemented in VisualWorks using ValueModels.
This is the real reason for the loose coupling between AM and View.

What we really want, though, is tight coupling between AM and View but
loose coupling between DM and View. We started to think that there
must be a better way.

----------------------

We think we found it at Taligent. For several years now they have been
proposing an architecture for C++ applications  that was derived from
MVC. They call it Model-View-Presenter (MVP).

Domain Model ~~ Presenter & (View & Interactor)

(I really need two dimensions for a better diagram here)

Here the AM has become the Presenter but this is now closely coupled
to its associated View. Hence it has no difficulty interacting cleanly
with it. The Presenter's responsibility is to map the users actions
generated by the Interactor (which is effectively the old style
Controller) and use these as commands to manipluate the Model.

The View is still an Observer (i.e. loosely coupled) on the Model and
it is responsible for displaying the model's data.

The old Controller has been renamed Interactor and forms a less
important role. We had already found that, certainly in modern
windowing environents such as Win32, most of the Controller's job is
already handled by the windows widgets. For VisualWorks, where native
widgets are not yet used, Controllers made sense and added flexibility
but when native widgets are in use they just make their use more
cumbersome. Anyway MVP provides that sort of pluggability of input
handling using an Interactor. Typical Interactors might track the
mouse during menu pulldowns or button presses etc.

----------------------

This may not have been entirely clear; some diagrams would have
helped. However, you might want to check out a presentation of the
main features of MVP on Taligent's web site at:

        http://www.veryComputer.com/

We have built an implementation of MVP as the framework used by the
upcoming Beta 2 release of Dolphin Smalltalk. This is one reason why
the new release has been somewhat delayed, but it should be available
from our site during November:

        http://www.veryComputer.com/

There are a number of other advantages that should come with MVP.
Things like easier integration with component architectures (Active/X,
OpenDoc, Beans) and the ability to improve on the PARTs style wiring
interface. We hope to demonstrate these in the not too distant future.

------
Andy Bower


 
 
 

Object models, Domain models, Application models, and MVC?

Post by Greg Gibso » Fri, 18 Oct 1996 04:00:00



> I think it was Alan Knight who wrote this.

> > > An "application model" in Smalltalk jargon is a model that
> > > supports interaction behavior, and sits essentially between the
> > > business model (the implementation of the conceptual domain
> > > model) and the user interface.  It is not uncommon for the
> > > business model and the application model to be merged, unless
> > > there is the intent for the business model to be reused, or in
> > > some fashion shared, either among multiple applications, via
> > > a database, or whatever.

> This sounds very much like Jacobson's Entity/Controller/Interface model.

To some degree this is true; at least, I would expect that 'Interface'
corresponds to 'View', 'Controller' to 'Application Model', and
'Entity' to 'Domain Model'.  However, use cases also have levels of
detail and scope that cause some of this to blur.  I have seen
(just recently at OOSPLA!) the E/C/I model used strictly for UI design,
where all three types of objects are then in the View layer.  Yet again,
I would presume that use cases could be used to analyze/design the
Infrastructure layer objects as well.

Finally, there seems to be a basic 'philosophy of objects' question
here.
The 4 layers described are modeling application structure in a layered
manner (top to bottom).  The E/C/I model looks at an application
(i.e. system) from three orthog*perspectives (or stereotypes in
UML terms).  Whether the two are really similar at their core or
just use similar sounding terms I can't say.  (P.S. I hear Jacobson
calls Interface objects 'Boundary' objects now, since 'Interfaces'
have another meaning within Use Case Engineering).

--
=.=-=.=-=.=-=.=-=.=-=.=-=.=-=.=-=.=-=.=-=.=-=.=-=.=-=.=-=.=-=.=-=.=-=.=-=.=-=.=

\
AG Communication Systems      Talk: 602-582-7524           ||   no one  
||
Phoenix, AZ 85072-2179        Web:  http://www.veryComputer.com/     \ but myself
/

 
 
 

Object models, Domain models, Application models, and MVC?

Post by Bill Gooc » Sat, 19 Oct 1996 04:00:00





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

Quote:> 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.

Quote:> > ...                                          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.

Quote:> >   ... 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
Icon Computing

Texas liaison for the International Programmers Guild
For info on IPG, see http://www.ipgnet.com/ipghome.htm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 
 
 

Object models, Domain models, Application models, and MVC?

Post by Patrick Log » Sun, 20 Oct 1996 04:00:00


: I like Envy / IBM Smalltalk's ability to define extensions. I think
: extensions are a useful construct for separating roles.

What is meant by "roles" in this context?

Our group uses Team/V. This tool allows a package to add
methods to classes, where the class itself is defined in
another package. This is useful for adding methods that
could have been included by the author of the other package
but were not. For example, adding String>>substrings:
to an "extensions" package doesn't change the "role" of
a String. It simply adds functionality that logically
belongs to String.

--

 
 
 

Object models, Domain models, Application models, and MVC?

Post by im.. » Sun, 20 Oct 1996 04:00:00



Quote:>I think this also leads to the idea of 'roles' being separate from 'type'.

>I like Envy / IBM Smalltalk's ability to define extensions. I think
>extensions are a useful construct for separating roles.

>Faisal Waris

My intention was just to surf, but you touched the subject...

I agree. I haven't talked to the people who designed Envy, but if they designed it
as version control / group development tool, they ended up with a wrong but much
more useful product.
I think the greatest benefit of all the Envy gives you is the ability to bundle sets
of behaviors (not Behaviors) into components that have boundaries similar to your
application architecture. If you ever try to build a large system, you will find that
you need methods that are implemented in (e.g.) Object, but don't belong to a 'system'
behavior. One example is #inspect. Is that a behavior associated with the very basic
system? I don't think so - it is really a part of the development environment.
In 'vanilla' Smalltalk, development environment is so tightly integrated with
the rest that one tends to forget which is which. Enter Envy. By separating sets of
behaviors (corresponding with 'defined' and 'extended' classes) and combining
related sets of behaviors from different classes into (sub)applications, they
created an architecture.
I find it extremely useful because it lets me think in terms of building blocks for
the application. The building blocks are the layers (or, more exactly, parts of layers).
I could go on and on about how to define prerequisites and structure applications
and subapplications (and configuration maps) so that rebuilding the system from
a clean image is a breeze (well, almost).
It is almost invariably true that projects I come to have a messed-up architecture
(read Envy (sub)apps and prerequisites) so they are unable to rebuild images from
scratch, or they have lots of warnings and erors popping up in Transcript while loading,
which usually means nothing works until the WHOLE thing is loaded - which defeats
the purpose of splitting things into apps and subapps.
One thing that I hate but happens almost every time, is that people start implementing
code in an application which has 'VisualWorksDevelopment' or 'WindowBuilderDevelopment'
as a prerequisite. Good look trying to make your system work after you package...

This is getting long. If anyone out there has problems related to this and needs help,
give me a buzz.

BTW - this is not to say that the version control aspects of Envy are not great as
well. I wouldn't use Smalltalk without Envy even as a one man shop.

P.S. If there are the (orginal) OTI folks reading this, I would love to hear from them
what they had in mind when they started Envy. Whatever it was, they did excellent
job.
/------------------------------------------------------------------------------
/ Jerry Kott
/ Imageware Corporation - "Connecting Objects to a Perfect Image"
/ Toronto, Ontario, Canada
/ (416) 265-6934
/ http://www.inforamp.net/~image
/------------------------------------------------------------------------------