[
Lists Home |
Date Index |
Thread Index
]
[Uche Ogbuji]
[Tom P asked]
> > Uche, could you give one or two more concrete examples of this (I mean,
> > examples of replacing rules and inference by declarations and class
> > analyses)? Especially something that gives the flavor of what surprised
> > you. Not of course something that you shouldn't be talking about, but
some
> > kind of illustration. It would be very useful to me and, I'm sure, many
> > others.
>
> OK. One of the sensitive things about the project is the sorts of data in
the ontology, so I'll just have to completely make up an example that I hope
will do for illustration.
>
Many thanks, Uche. There are almost too many interesting things here,
especially including the posting you linked to from 1993.
>...
> Notice one thing. I introduced an object class Car. There isn't one in
the "raw" description of the business rule implementation. This is a common
artifact of OO development: you often introduce object classes just to take
advantage of polymorphism, even though these are not "first class" in the
business problem description. I've come to believe this is a common cause
of inflexibility of OO designs. What if we then have to consider a private
bus. We can introduce a PrivateBus class now and implement the
checkLegalForExpressLane() method. Probably this is very similar to that of
the Car class. We could break out the common functionality to a mix-in
class, or use one of the many design patterns available for this sort of
thing. However, regardless of our approach, we will almost certainly have
introduced some artifice to the design. Artifice is not bad per se, but
since the real world does not correspond to our artifice, it can cause
maintenance and integration probl!
> ems.
>
This reminds me of the way I usually approach high level modeling of the
problem domain. I try to model in a way that is neutral as to whether an OO
or non-OO would be used. It's true that I use a loose combination of ER and
Object modeling, mostly ISA and composition, but that doesn't automatically
commit you. I find that an informal approach modeling (which is actually
rigorous about the basic relationships and responsibilities in the model,
but loose about most everything else) is useful and productive, at least for
me.
My rationale for this is two-fold. First, the problem domain generally does
not know or care anything about OO engineering, and I want to understand the
problem domain. Of course, there has to be some kind of model, and that
will entail some kind of mental filter. Second, I think that it's good if
the model could be implemented in several different systems, because that
approach helps keep implementation out of the understanding of the problem
domain.
Anyway, I think this fits right in with the emphasis on ADTs and mixin
classes in your linked post.
> Most importantly, some of the object classes we introduce that are
specific to this business rule might not make sense in others. For
instance, if we were also writing a business rule for determining what
vehicles were allowed to pass through a tunnel, we might want to consider
private buses and public transport buses together, which cuts across the
object classes we set up for the express lane rule.
>
> I could go on for ever on little implementation details that dog this
approach. But I think you probably get the idea.
>
> Trying to re-cast this as a general classification problem, I might do the
following:
>
> Consider what properties are fundamental to vehicles: i.e. number of
wheels, their owner, propulsion system, etc.
>
> Now, you can construct needed classes dynamically: a motorcycle is simply
a vehicle with 2 wheels. A public transport vehicle is a vehicle whose
owner is the transport authority. Et cetera.
>
> We can then attach application behaviors to classifications in some way.
This is similar to the idea of methods in OO, but our big gain is that we've
decoupled the classification of objects from low-level implementation
details.
>
If I read you right, you have tried to replace dynamic application of rules
to known classes with dynamic discovery of (ontological, not just OO)
classes, whose discovery entails certain rules and behaviors. Is that close
to the mark? This puts the emphasis on classification, I can see that.
In a way, a certain rule could be considered a property of a class, right?
Classify an instance and you have the rule. Interesting.
Hmm, I wonder if you could create xslt stylesheets - if a structure is an
instance of a certain class, it gets a certain template. Of course, that
happens now if you think of an XPATH expression as classifying a set of
nodes, but I mean to actually construct a stylesheet, as opposed to applying
templates. Maybe that's too far-fetched.
> Some things are still probably best treated as instance state, e.g. the
number of occupants and the state of the emissions sticker.
>
Well, thanks, Uche. Very stimulating.
Tom P
|
