public repository for reusable Object Oriented models ?
Jean-Marc Vanel
For years I couldn't find one.
I think one of the reasons for non-existence is lack of reusable
exchange format.
XMI is pretty variable and poorly formalized.
UML is too complex, also unstable, and the strictly OO part (Class
diagrams) is mixed with the rest of the huge 250 metaclasses metamodel.
eCore could be a good exchange format, but it's rather limited to the
eclipse - Java world.
It seems that the best exchange format for business model is OWL - Web
Ontology Language ( http://www.w3.org/2004/OWL/ ).
OWL has classes and properties . It has no methods and interfaces, but
for that it is quite possible to reuse exactly the UML metamodel.
An advantage of OWL (and more generally Description Logics frameworks)
is that a class defined by its properties (e.g. an UnemployedPerson is a
Person that has no Job) provides a more natural way of modelizing a
domain than classic OO, where you have to use delegation for the
situation when a Person becomes UnemployedPerson.
And, contrary to classic OO models, there are sites for searching and
hosting OWL and RDFS ontologies on the Web :
http://swoogle.umbc.edu/
http://olp.dfki.de/ontoselect
http://www.schemaweb.info/
But maybe there are projects and sites I'm not aware for OO models ?
Phlip
> But maybe there are projects and sites I'm not aware for OO models ?
If you mean Patterns, they have a thriving community. The C2 Wiki, OOPSLA,
PLOPD, etc. See:
http://www.hillside.net/patterns/books/
If you mean Models, that's the part you must do yourself. If the models are the
same, then the apps are the same, and you are probably in competition with the
people with the same models!
--
Phlip
H. S. Lahman
> Is there a public repository for reusable Object Oriented odels ?
No; there is no need. If the solution described in the model is
reusable, then so is that solution in its implementation. Once you have
a reusable model, it only needs to be implemented once and then one
sells copies of the implementation in the OTS market.
> UML is too complex, also unstable, and the strictly OO part (Class
> diagrams) is mixed with the rest of the huge 250 metaclasses metamodel.
If you think that Class diagrams are the only part of UML that is OO,
then I strongly suggest reading a book on OOA/D.
> An advantage of OWL (and more generally Description Logics frameworks)
> is that a class defined by its properties (e.g. an UnemployedPerson is a
> Person that has no Job) provides a more natural way of modelizing a
> domain than classic OO, where you have to use delegation for the
> situation when a Person becomes UnemployedPerson.
Same recommendation vis a vis your view of OO abstraction. Are you and
Topmind related?
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
John "Z-Bo" Zabroski
>
> Same recommendation vis a vis your view of OO abstraction. Are you and
> Topmind related?
Easy.
Structural models, as well as variations, are discussed in Fowler's
Analysis Patterns book. Fowler creates a pattern language to discuss
a continuum of options. It is at a higher level than implementation.
H. S. Lahman
>> Same recommendation vis a vis your view of OO abstraction. Are you and
>> Topmind related?
>
>
>
> Easy.
>
> Structural models, as well as variations, are discussed in Fowler's
> Analysis Patterns book. Fowler creates a pattern language to discuss
> a continuum of options. It is at a higher level than implementation.
I was referring to the perception of OOA/D in the quoted OP paragraph.
The OP characterized OO development in terms of: (1) OO delegation was
generalization (an UnemployedPerson was a special sort of Person); (2)
that one had to use delegation to make such distinctions (between
whether Persons were employed or not); and (3) that a class is defined
by its properties is only true in OWL and not in OOA/D. Clearly the
first and third are completely untrue and the second is probably rare
for the example.
John "Z-Bo" Zabroski
> software blog:http://pathfinderpeople.blogs.com/hslahman/index.html
Sometimes when folks post a question, they are thinking out loud...
You have years of experience beyond Six Nines beyond somebody who
wonders out loud. I'm envious of your "OO Thinking Speed".
The takeaway here is to consider the value in helping people who think
out loud, by helping them to *re-crystallize*.
The OP needs to think about pattern languages and conversational OO
design discussion as the right format for this inherently coarse-
grained stuff, not as you say a fine-grained queryable OWL database.
Nietzsche, in Zarathrusta, has a short story about a dialogue between
a kitchen coal and a diamond. The story is called THE HAMMER SPEAKS.
For all creators are hard. And it must seem blessedness to you to
impress your hand on millennia as on bronze-harder than bronze, nobler
than bronze. Only the noblest is altogether hard.
This new table, O my bothers, I place over you: become hard!
~ Nietzsche
Jean-Marc Vanel
> Responding to Vanel...
>
>> Is there a public repository for reusable Object Oriented models ?
>
> No; there is no need. If the solution described in the model is
> reusable, then so is that solution in its implementation. Once you have
> a reusable model, it only needs to be implemented once and then one
> sells copies of the implementation in the OTS market.
This seems a rather out-dated conception an the era of Open Source
Software (OSS), given that there are many good OSS Object-Oriented
applications, and thousands of RDFS and OWL models available.
Also there is a misunderstanding regarding the kind of OO models (my
fault). In my mind, my original question was about reusable *business*
Object Oriented models, also called "domain analysis" (cf Eric Evans' book).
Obviously there is a long way from a raw business to a usable sellable
application.
However your answer is very interesting for me, and certainly reflects a
common conception in the OO design community.
>> UML is too complex, also unstable, and the strictly OO part (Class
>> diagrams) is mixed with the rest of the huge 250 metaclasses metamodel.
>
> If you think that Class diagrams are the only part of UML that is OO,
> then I strongly suggest reading a book on OOA/D.
Don't worry, I know UML from the OMT time ;-) .
What I was alluding to is the non modularity of UML, the fact that you
can't declare "this model only uses that part of the UML metamodel".
>> An advantage of OWL (and more generally Description Logics frameworks)
>> is that a class defined by its properties (e.g. an UnemployedPerson is
>> a Person that has no Job) provides a more natural way of modelizing a
>> domain than classic OO, where you have to use delegation for the
>> situation when a Person becomes UnemployedPerson.
>
> Same recommendation vis a vis your view of OO abstraction.
My experience with teaching UML trainings is that the invariability of
the type (inherited from OO programming languages) complicates the
teaching of domain design. I really think that OWL and description
logics (supported by many years of AI research) is better fit to domain
analysis.
But I reassure you, for application and framework design, OO is "sans
pareil" (incomparable).
> Are you and Topmind related?
No, BTW I found nothing about Topmind that on search engine...
Jean-Marc Vanel
> The OP needs to think about pattern languages and conversational OO
> design discussion as the right format for this inherently coarse-
> grained stuff, not as you say a fine-grained queryable OWL database.
Sorry guys, it's hard for me to follow the discussion ... the language
barrier ...
What does OP stand for ?
--
Jean-Marc Vanel
Consulting, services, training,
Rule-based programming, Semantic Web
http://jmvanel.free.fr/
Jean-Marc Vanel
> I was referring to the perception of OOA/D in the quoted OP paragraph.
> The OP characterized OO development in terms of: (1) OO delegation was
> generalization (an UnemployedPerson was a special sort of Person);
> (2) that one had to use delegation to make such distinctions (between
> whether Persons were employed or not); and (3) that a class is defined
> by its properties is only true in OWL and not in OOA/D. Clearly the
> first and third are completely untrue and the second is probably rare
> for the example.
Regarding point 3, I'd like in which formal variety of OO Analysis one
can define a class by its properties ( a full-blown class, not a Boolean
method computing the criterion for membership ).
Probably that variety of OOA would look much like OWL, where this kind
of definition is possible:
Class: VegetarianPizza
EquivalentTo:
Pizza
and (not (hasTopping some FishTopping))
and (not (hasTopping some MeatTopping))
And, alas, the point that this post confirmed is that for classic OO
techniques there is very few reusable business designs available on the
Web, Martin Fowler's and Eric Evan's stuff being an exception. And then
even Fowler's and Evans' designs are not really "available" in the sense
that one could readily download them in a machine - understandable format .
John "Z-Bo" Zabroski
> John "Z-Bo" Zabroski a écrit :
>
>
> barrier ...
>
> What does OP stand for ?
Depending on the context, it is either Original Post or Original
Poster. Original Post is the top-level message in a thread. The
Original Poster is the one who sent the message.
Let me know if anything else was unclear. =)
John "Z-Bo" Zabroski
>
> And, alas, the point that this post confirmed is that for classic OO
> techniques there is very few reusable business designs available on the
> Web, Martin Fowler's and Eric Evan's stuff being an exception. And then
> even Fowler's and Evans' designs are not really "available" in the sense
> that one could readily download them in a machine - understandable format .
>
Fowler's stuff is not copy-and-paste searchable stuff. You have to
read an entire chapter to digest its contents, and in some cases go
back and re-read it.
What you really want isn't some searchable database of classes and
properties. Instead, you want a database of real world discussion
about businesses and how they can be modeled. At this point it
becomes the classic OSS question of whether its faster to blaze your
own trail or spend the time searching for somebody else's footsteps to
follow.
If you just want "classes and properties" style models, look for ERD
diagrams. However, they don't capture behavior.
H. S. Lahman
>> I was referring to the perception of OOA/D in the quoted OP paragraph.
>> The OP characterized OO development in terms of: (1) OO delegation was
>> generalization (an UnemployedPerson was a special sort of Person); (2)
>> that one had to use delegation to make such distinctions (between
>> whether Persons were employed or not); and (3) that a class is defined
>> by its properties is only true in OWL and not in OOA/D. Clearly the
>> first and third are completely untrue and the second is probably rare
>> for the example.
>
> Regarding point 3, I'd like in which formal variety of OO Analysis one
> can define a class by its properties ( a full-blown class, not a Boolean
> method computing the criterion for membership ).
In OOA/D a Class Diagram basically defines sets of objects. (Even a
generalization is just a Venn Diagram in tree form that shows the
relationships among subsets.) So each class defines a set (or a subset
for generalization) of objects.
What distinguishes one set of objects from another set of objects are
the properties associated with their classes. Thus OO classes are
*always* defined by the properties shared by all the member objects.
You originally said that OWL allowed a class to be defined by its
properties and that was an advantage over the OO approach, implying that
OO classes are not defined by their properties.
>
> Probably that variety of OOA would look much like OWL, where this kind
> of definition is possible:
>
> Class: VegetarianPizza
> EquivalentTo:
> Pizza
> and (not (hasTopping some FishTopping))
> and (not (hasTopping some MeatTopping))
>
> And, alas, the point that this post confirmed is that for classic OO
> techniques there is very few reusable business designs available on the
> Web, Martin Fowler's and Eric Evan's stuff being an exception. And then
> even Fowler's and Evans' designs are not really "available" in the sense
> that one could readily download them in a machine - understandable format .
This is a major no-no in OOA/D because it defines classes based on a
negative. That can get into serious trouble during maintenance. For
example, that is most obvious in the corner that some OOPLs have painted
themselves into with regard to generalization.
[Avian]
A
|
+---------+--------+
| | |
[Sparrow] [Hawk] [Duck]
Some OOPLs allow you to instantiate an Avian without specifying a leaf
subclass. IOW, such an Avian is one that is NOT a Sparrow, Hawk, or
Duck. That may be fine for the original problem where the three
subclasses are the only flying birds of interest and, say, the only
other Avians are all flightless birds taken together.
But what happens later when one decides that one needs to add a
[Pheasant] subclass? How does the maintainer know that, looking at the
generalization? How does the maintainer know that pheasants weren't
already in the pool for Avians created w/o a subclass in the existing
application? There is no way except to look at every context where
Avians were created and used previously to see if something will be
broken by adding the subclass (and excluding pheasants from the original
Avians-only group).
As a result, in modern OOA/D one has two rules for generalization: (1)
the members of sibling subclasses must be disjoint sets and (2) the
union of all sibling subclass members must be a complete set of the
immediate superclass set. That eliminates the negative definition and
works fine for generalization, but what about other classes that are
defined based on negatives? There are no convenient, cookbook rules to
remove the ambiguity. So it is potentially a maintenance nightmare when
the negative rules are changed.
H. S. Lahman
>>> Is there a public repository for reusable Object Oriented models ?
>>
>> No; there is no need. If the solution described in the model is
>> reusable, then so is that solution in its implementation. Once you
>> have a reusable model, it only needs to be implemented once and then
>> one sells copies of the implementation in the OTS market.
>
> This seems a rather out-dated conception an the era of Open Source
> Software (OSS), given that there are many good OSS Object-Oriented
> applications, and thousands of RDFS and OWL models available.
I'm a translationist. My OOA model is already executable in itself and
is transformed into 3GL or Assembly program by a full code generator. So
the model *is* the executable and mucking around with 3GL code seems
outdated to me. B-)
OTOH, I don't see any problem with open source for models. Creating
models is just another form of programming. Open source is just one of
many development models for doing that, so I'm afraid I don't how it is
relevant to reusable models.
Also, OOA/D models only deal with the unique features of the solution of
the particular problem in hand. Any rules and policies that already
exist outside the scope of the specific problem in hand (e.g.,
mathematical algorithms) would be defined in external, "realized" code
or models. Such generic solutions are ideal candidates for large-scale
reuse, which comes full circle to my original point that you build them
once and reuse the executable.
>
> Also there is a misunderstanding regarding the kind of OO models (my
> fault). In my mind, my original question was about reusable *business*
> Object Oriented models, also called "domain analysis" (cf Eric Evans'
> book).
> Obviously there is a long way from a raw business to a usable sellable
> application.
Exactly. I regard Evans approach as closely related to design patterns
(or analysis patterns in Fowler's terminology). It is a design
methodology more than solution descriptions. Those patterns and
techniques are reusable and they get documented in books like his.
But the application models constructed using them are specific solutions
that utilize those patterns as one of many design tools. As such those
models are not reusable unless the subject matter is common across many
applications (e.g., GUIs or RDB access).
>>> UML is too complex, also unstable, and the strictly OO part (Class
>>> diagrams) is mixed with the rest of the huge 250 metaclasses metamodel.
>>
>> If you think that Class diagrams are the only part of UML that is OO,
>> then I strongly suggest reading a book on OOA/D.
> Don't worry, I know UML from the OMT time ;-) .
> What I was alluding to is the non modularity of UML, the fact that you
> can't declare "this model only uses that part of the UML metamodel".
Actually you can do that. That is essentially what the MDA initiative is
all about. MDA profiles define subsets and extensions of UML for
particular contexts. For example, the OOA/D methodology I use employs an
MDA profile largely defined in the book "Executable UML" by Mellor and
Balcer. That profile utilizes less than half of the UML graphic elements
and semantics.
>
>>> An advantage of OWL (and more generally Description Logics
>>> frameworks) is that a class defined by its properties (e.g. an
>>> UnemployedPerson is a Person that has no Job) provides a more natural
>>> way of modelizing a domain than classic OO, where you have to use
>>> delegation for the situation when a Person becomes UnemployedPerson.
>>
>> Same recommendation vis a vis your view of OO abstraction.
>
> My experience with teaching UML trainings is that the invariability of
> the type (inherited from OO programming languages) complicates the
> teaching of domain design. I really think that OWL and description
> logics (supported by many years of AI research) is better fit to domain
> analysis.
OK, but there are no types in UML, except for knowledge attribute ADTs.
OOA/D is based on class systems rather than type systems.
<aside>
The OOPLs are all still 3GLs (albeit 3.nGLs). At their heart they are
still procedural because they are married to things like procedural
block structuring, procedural scope, and procedural message passing.
IOW, however well they disguise it, they are still inherently married to
the hardware computational models of Turing and von Neumann.
As such they make a lot of compromises that one does not have to make in
OOA/D. My personal favorite is the failure of the OOPLs to separate
message and method because of their emphasis on type systems and
procedural message passing. If one does the OOA/D properly, then that is
benign. But a common trap, especially for those converting from
procedural development to OO development, is to adopt the Do This view
of communications because messages (procedure signatures!) are named by
what the receiver does in response to the message. That invites the
developer to construct calling methods to depend on what the response
is, creating unnecessary dependencies.
In contrast, in OOA/D messages are announcements (I'm Done) so there is
no expectation of what will happen. Then the developer connects the dots
of flow of control at a higher level of abstraction (a UML Interaction
Diagram by addressing the messages to particular objects) than method
definitions and implementations. While not perfect, it goes a long way
towards preventing hierarchical dependencies among behaviors.
</aside>
>> Are you and Topmind related?
>
> No, BTW I found nothing about Topmind that on search engine...
Topmind is the nom de plume of Bryce Jacobs. He is an anti-OO troll on
this forum who enjoys pulling the chains of OO people by creating straw
man views of OO development and then attacking them.
That's what you seemed to be doing in the paragraph of your post where
you equated delegation to generalization (its actually an alternative)
and implied OO classes were not defined by their properties.