Re: Dijkstra on the Usefulness of Hierarchy
From: Lee Riemenschneider (newsuser_at_frogooa.com)
Date: 09/18/04
- Next message: Lee Riemenschneider: "Re: Why Software Is Bad and What We Can Do to Fix It"
- Previous message: Lee Riemenschneider: "Re: 3-ary relationship and association class"
- In reply to: Universe: "Re: Dijkstra on the Usefulness of Hierarchy"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 18 Sep 2004 10:41:44 -0500
On Sun, 12 Sep 2004 17:07:16 UTC, Universe <> wrote:
> > <Universe> wrote in message
> > >
> > > "layered hierarchical architecture" of OO systems:
> > >
> > > OO Interface
> > > ---------
> > > OO Use Case Model
> > > --------
> > > OO Domain Model // or Use Case & this combined
> > > --------
> > > Data Domain Model
>
> > > OO Interface
>
> GUI, and or console. Dialog boxes, forms, lists, and from other it
> might involve pipes. User/Actor enters text, clicks buttons etc all
> in pursuit of carrying out one or more use cases - register student,
> fly out of planet, start an insurance policy, make a bowling strike,
> etcetera - an application was designed to achieve.
>
> Most major forms, dialog boxes and so on are represented here in
> *Interface* classes.
>
> This is the *top* of the system. It is where the one or more current
> aims of the application at any instant were prompted to begin,
> directly or indirectly.
>
> This underscores at a minimum that a system has **hierarchy** of
> purpose and control.
>
You are mixing implementation of the interface with the problem
itself. "register student" is wholly independent of GUI, console,
dialog boxes, etc. Driving the solution to the problem space from the
choice of interface implementation seems very prone to error and extra
effort. These are two wholly independent domains. e.g., User
Information Entry and Student Registration.
> > > ---------
> > > OO Use Case Model
>
> This layer is where at least *Controller* classes reside that
> coordinate attempting to complete the use cases requirements the
> system was designed to satisfy.
>
> Non-domain Entity classes that inter-operate are coordinated by
> Controller classes frequently reside in this layer as well.
>
> Often smaller less complex systems place these classes in the Domain
> Model with other directly evident business/game/scientific Entity
> classes.
>
This sounds like a mix of (partial) architectural decision with
problem space solution. I can't see how this doesn't couple tightly to
the next layer.
> > > --------
> > > OO Domain Model // or Use Case & this combined
>
> *Entity* classes that model/abstract entities and process that play a
> an apparent, or easily distinguishable role in the application domain
> exist here and collaborate and inter-operate peer2peer as well as
> under the direction of Controller classes.
>
> > > --------
> > > Data Domain Model
>
> In an OODBMS classes and objects that hold data reside here.
>
I'm not sure I see a huge distinction between this and the previous
layer.
-- Lee W. Riemenschneider GO BOILERS! Running eComStation (eCS)(the latest incarnation of OS/2) Buy eCS everyone! Buy it now! http://www.ecomstation.com
- Next message: Lee Riemenschneider: "Re: Why Software Is Bad and What We Can Do to Fix It"
- Previous message: Lee Riemenschneider: "Re: 3-ary relationship and association class"
- In reply to: Universe: "Re: Dijkstra on the Usefulness of Hierarchy"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
