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

Its that time of the month to confuse myself again. I ran into a
big-picture wall and everything collapsed. So I need to start slowly and
build it back up. Please bare with me...

In Rumbaugh et al., they have the object model, which is the OOP
equivalent of the Entity-Relationship (ER) model in the relational model.
Using the Rumbaugh et al. OMT schematics, you draw little rectangles for
the objects with names and attributes in the block (methods to if you
want). Then you draw connecting lines showing the 1-1, 1-N, and M-N
relationships between them. These relationships can have their own little
rectangles, etc, etc. The object model shows only the objects and
attributes. It shows no dynamic/state or functionality.

Is a domain model the same as the object model? Is it the model of the MVC
(Model-View-Controller).

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?

I see two schools of thought in the great debate: (1) The Rumbaugh et al.
group, which proposes developing the object model as the primary model,
then placing the dynamic model and functional model on top of it. The
feeling here is that the object model is least likely to change. I agree
with this, and in my area of work (engineering), it makes a lot of sense.
The second school pushes "use-cases" as the primary tool, and organizing
objects around those (oversimplified, I know). The use-case is also
useful, but in my field (normally I would call it my domain, but I don't
want to confuse anyone), use-cases are mainly useful for big picture user
operations, i.e., workflow. At the micro change level, they seem to be
less useful. The number of use-cases explodes for me, so I am better off
with a constraint-based approach, where a matrix keeps track of all
dependencies, then automatically triggers change events. In other words, I
can abstract the use-cases into a single pattern.

And its this pattern that is bothering me. Who generates the events? This
may be an incorrect impression, but the way I understand the Model in the
MVC is that it is supposed to be passive. It does not control
functionality or decide what to do. It just sits there and responds to
gets and sets.

But this is not satisfactory. My model has very detailed know-how, e.g.,
the dependencies, and it makes no sense to duplicate that in the
controller. I must be misunderstanding something. At the very least, the
Model must handle gets and sets, as well as propogating changes within the
Model. It must also initiate events that signal these changes. It is then
up to the Controller or View to register for these events.

I also get confused by the separation of the Controller and View. For
example, a text field is both.

Aside: Over time, I have eliminated the Controller from my code. I have
View objects which register with the Model for change events, and send the
Model messages when the user wants to initiate an event. For me, any
impedance mismatch between the Views and the Model is a sign of bad
design, not the need for a Controller to moderate the two. Yes, a
Controller is useful for these mismatch situations, but a mismatch will
just cause trouble down the road, as I try to ratchet-up and simplify my
code. Also, I have View objects made up of other View objects, so probably
that's where my Controller went.

The dynamic model is the toughest one, and I am trying to abstract it out
of there as much as possible. My field allows this to some degree. In
fact, rule and constraint based programming (i.e., auto-dynamic models) is
a much more powerful concept than even OOP.

Right now, I have PropertyDictionary 0bjects at the lowest level. These
are just get/set placeholders for properties. PropertyDictionaries are
owned by ConstraintPropertyDictionaries, which include rules and
constraints, handling dependent and independent properties.
ConstraintPropertyDictionaries are owned by ProjectObjects (just my word
for a subclass of Object with lots of stuff added. Its my root domain
object.) ProjectObjects receive set and get messages, and pass it along to
the ConstraintPropertyDictionary, also receiving a list of changed
properties, which are used to trigger events. ProjectObjects also manage
links to other ProjectObjects. So they "own" certain properties, and they
"link" to other ProjectObjects. Events can be sent to self, a linkObject,
or any View object that registers. Currently, there is some knowledge of
Views in my ProjectObjects, but I am working on ways to break this
connection.

So what's wrong? For one thing, rules and constraints cannot handle every
issue, so I have to write patch code in my ProjectObject. Fair enough; a
little is okay, and its a manageable location.

Secondly, I am uncomfortable with constraints being buried in an object.
Most constraints are between ProjectObjects, not just internal to a
ProjectObject. For that, I will have to go to a master ConstraintManager.
I have an idea how to do that. Lots of work, but basically a cosmetic
change  - and slower, due to a massive dictionary lookup.

Third, I want to explore finite-state-machines (FSM). There has to be a
better way to separate object, dynamic, and functional models.

Enough for now. I think there was a question in here somewhere. I just
need to hack out of my funk. Respond at will.



Tue, 30 Mar 1999 03:00:00 GMT  
 Object models, Domain models, Application models, and MVC?

Quote:

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



Fri, 02 Apr 1999 03:00:00 GMT  
 Object models, Domain models, Application models, and MVC?



Quote:

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



Sat, 03 Apr 1999 03:00:00 GMT  
 Object models, Domain models, Application models, and MVC?

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 {*filter*} 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.*-*-*.com/  

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



Sun, 04 Apr 1999 03:00:00 GMT  
 Object models, Domain models, Application models, and MVC?



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 {*filter*} 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.*-*-*.com/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Sun, 04 Apr 1999 03:00:00 GMT  
 Object models, Domain models, Application models, and MVC?


[...]

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 {*filter*} 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



Mon, 05 Apr 1999 03:00:00 GMT  
 Object models, Domain models, Application models, and MVC?


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 {*filter*} 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.*-*-*.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.*-*-*.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




Mon, 05 Apr 1999 03:00:00 GMT  
 Object models, Domain models, Application models, and MVC?

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.

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{*filter*}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.*-*-*.com/     \ but myself
/



Mon, 05 Apr 1999 03:00:00 GMT  
 Object models, Domain models, Application models, and MVC?


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

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

Yes, the idea is effectively identical. Confusion arises because back in
about 1976, Smalltalk started using Controller to refer to the user-input
handling part of a widget.

Quote:
>This does not mean that the Business objects become {*filter*} 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.

Absolutely.

--
Alan Knight                     | The Object People

613.225.8812(v) 613.225.5943(f) | http://www.*-*-*.com/

"Oh yeah, those Object People. They're kind of strange,
aren't they" - Jim Coplien, OOPSLA '96



Mon, 05 Apr 1999 03:00:00 GMT  
 Object models, Domain models, Application models, and MVC?

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

--



Wed, 07 Apr 1999 03:00:00 GMT  
 Object models, Domain models, Application models, and MVC?


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



Wed, 07 Apr 1999 03:00:00 GMT  
 Object models, Domain models, Application models, and MVC?

Quote:


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

>--


A class or type may have many clients. The class's interface for a
category of clients is its 'role'. By separating the roles of a class into
separate applications or extensions, we can keep our core model simpler.

I am suggesting that extensions is a useful construct for organizing
roles. This does not preclude the use of extensions for adding
functionality that intrinsically belongs to the model.

I really like Envy / IBM Smalltalk's concept of applications. I think that
it can be better exploited if it is given more attention and thought.
Perhaps somebody can develop some guidelines or even relate it to a
methodology.

Regards,

Faisal Waris



Fri, 09 Apr 1999 03:00:00 GMT  
 
 [ 31 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

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

2. Data Modeling/Object Modeling (was Re: [OT] RE: help -- persuade my boss to adopt ruby)

3. setting the model of a TreePresenter in Dialog>>model:

4. Should ReferenceView<<model return referee model?

5. c model convert to verilog/VHDl model

6. Models Models?

7. I2C Model Synthesizable Model

8. How to model the transmission gate in Verilog without using tran (Behaviour model)

9. PLI model vs. Verilog model

10. C model in model tech.

11. MODEL: Need 68030 model.

12. a 3D model search engine, currently about 20,000 models indexed

 

 
Powered by phpBB® Forum Software