OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xtm-wg] TM Conceptual Model: Semantics of the UML "modern dinosaur"?


dear hard-working XTMers,

in this mail i want to share what i recently learnt
about conceptual modelling, TM processing, and UML in particular,
which may or may not be of value for you modelers and implementers.

what makes me worry is the lack of semantics in UML which might
hold us from fully understanding and clearly expressing the semantics
of the TM conceptual model.

------------------------------------------------------------------
1. conceptual model:
   discussion about TM processing with XSLT/XPathScript vs. OODBMS
------------------------------------------------------------------
i agree with lars that ideally one should regard topic map processing
on the conceptual, OO layer of the underlying TM model, not on the XML
node layer. which presupposes a clear understanding of this conceptual
model. and i agree with nikita that XML tools are appropriate to
work on a TM marked up in the interchange syntax format (in order
to construct a higher-level internal representation). it appears
to me that several basic TM processing functions can be built e.g.
with XPathScript (part of AxKit). (but code will become complex).
with the right conceptual API on top of it in place, it makes no
difference to me if the persistent store underneath is a fully-fledged
OODMS or raw XTM (in perl terms: OO data structures may be transparently
tied. in OO vs. RDMBS speak: with the right schema you can roll your own
object wrapper from relational stuff). however, performance may differ.
for me, the essence of this discussion is:
- what is the appropriate level of conceptual model?
- how can we best express what we intend with this model?
- what kind of functionalities do we want in a high-level API?
suggestions for working or even efficient physical data models are
interesting, but at this point not crucial.

---------------------------------------------------------------------------
2. conceptual model:
   discussion about DTD and UML in the spec, readability, interrelationship
---------------------------------------------------------------------------
i am both interested in the interchange format, and the conceptual
model, but the conceptual model appears more important to me.

after my recent isi 2000 topic map presentation, i was asked by prof.
bernhard thalheim of BTUniv. Cottbus, Germany, dept. of database
and information systems, which methodology is used to model the
conceptual model of TMs. it turned out that he did not really like
my response: UML. so i asked him to explain, and thus today he sent
me his recent paper "Codesign of Database Systems and Interaction
= Time and Consistent UML" [1], and a pointer to an even more critical
recent paper by his colleague and co-author klaus-dieter schewe:
"UML: A Modern Dinosaur? A Critical Analysis of the Unified Modelling
Language" [2].

both show serious drawbacks of UML.
the main point is that UML lacks clear semantics, is not better
than earlier ISOTEC, and completely ignores certain advances in
the scientific discussion of conceptual modelling.

so the main problem is not:
* will people understand if we put both DTD and UML diagrams
  in the annex spec, as they somehow differ, and we further explain
  in prose.

BUT:
* is our TM conceptual model already clear enough?
* how might UML impede our (and others) clear understanding of what
  is intended?

all the best
alex

===================================

References:
-----------
1.
Thalheim, Bernhard (2000):
Codesign of Database Systems and Interaction = Thin and Consistent UML. 
Paper presented on 5th OTS, 2000-06-20:
  http://lisa.uni-mb.si/cot/ots2000/povzetki.html
(I got the full .ps via personal communication)

Computer Science Institute, Brandenburg University of Technology at
Cottbus,
thalheim@informatik.tu-cottbus.de
http://www.informatik.tu-cottbus.de/~thalheim/

Abstract:
---------
Codesign of Database Systems and Interaction = Thin and Consistent UML

The Unified Modeling Language UML is becoming the quasi-standard for
development of object-oriented systems although it lacks in formal
semantics, integration of parts and pieces, validation and thus leads
to inconsistent systems. For this reason, design of systems on the
UML basis becomes as cumbersome as previous object-oriented approaches.
Another obstacle of oo development languages is the understimation of
user interaction support. Opposite to this situation the entity-
relationship model has got such rich extensions which enable the
developer to cope with all aspects of systems development in an
integrated and consistent fashion. This rich theory is the basis for
a design methodology for design of database structures, database
functions, static and dynamic integrity constraints together with the
design of the interaction space of users. In the paper we give a survey
on the codesign approach to development of database systems and
interaction. The codesign approach is based on the higher-order
entity-relationship model [Tha00], allows to model applications on
all levels of development and has a rich translation theory in order
to transfer the specification to implementation structures and
functions. Thus, the codesign approach might be understood together
with the model as the next generation UML or Super-UML. The approach
has been succesfully applied to large and complex applications
including internet information services.

2.
Schewe, Klaus-Dieter (2000):
UML -- A Modern Dinosaur?: A Critical Analysis of the Unified
Modelling Language

in H. Kangassalo et al. (Eds.) Information Modelling and Knowledge Bases
XII, IOS Press (to appear).
Proc. 1oth European-Japanese Conference on
Information Modelling and Knowledge Bases, Saariselkae (Finland)

K.D.Schewe@massey.ac.nz
http://fims-www.massey.ac.nz/%7Ekdschewe/publ.html

paper:
  http://fims-www.massey.ac.nz/~kdschewe/pub/articles/EJC00.ps
slides:
  http://fims-www.massey.ac.nz/~kdschewe/pub/slides/EJC00.ps

Abstract:
---------
UML is claimed to become a standard tool for the conceptual
modelling and development of modern Information Systems. In this
paper we analyse the concepts of UML, and compare them with a
rather old industrial development method ISOTEC and the Co-Design
approach propagated by the author and others.
We show that in many respects, UML is not new
- syntax: just re-invents many of the old ISOTEC concepts and
    introduces new names for them
- semantics: it does not present precise semantic definitions
    if these were added, the limitations of the expressiveness
    of the UML became apparent
- pragmatics: falls behind ISOTEC
On the other hand the UML ignores almost all theoretically-based
work on object-oriented modelling with respect to structures,
dynamics, contraints and interfaces and the co-design method
based on this theory.

>From the conclusion:
--------------------
... Therefore, we dare to classify UML as a modern dinosaur: It
is a semantically retarded, mighty ruler oppressing the development
of sophisticated methods for conceptual modelling and information
system design.

----------------------------------------------
Alexander Sigel, M.A. sigel@bonn.iz-soz.de
Informationszentrum Sozialwissenschaften, R&D
Lennéstr. 30, D-53113 Bonn, Germany
+49 228 2281 170 tel, +49 228 2281 120 fax
Homepage: http://index.bonn.iz-soz.de/~sigel/

-------------------------- eGroups Sponsor -------------------------~-~>
eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9699/1/_/337252/_/974714268/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC