ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] UML and Semantics

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Barkmeyer, Edward J" <edward.barkmeyer@xxxxxxxx>
Date: Wed, 5 Dec 2012 14:55:59 -0500
Message-id: <63955B982BF1854C96302E6A590823441737F5B061@xxxxxxxxxxxxxxxxxxxxxxxxxx>

Here and there a supporting comment.

 

William Frank wrote:

 

So now, I WRITE "at least one" more than one, etc.   Right on the UML diagram, when multiplicity is an issue. 

[EJB] I have found that I need to explain to business people how to “read” associations in simple UML class diagrams.  That is, telling them to read an association between Employee and Employee as “An employee has 0 or more supervisors, who are employees”.  You also read one with a 0..1 and they usually understand.  But that is in oral presentation.  If I tried to do it in a paper, I can see that William’s approach is better.  It is no longer UML, however, but FrankUML.  The point here is that the object is to communicate, and unless you need to use the formal UML model for other purposes, it is not necessarily a requirement that you stay strictly within the syntax of the language.  But when you depart, you will lose the UML-educated audience.

But I usually don't write anything, because the multiplicity of a relationship should be determined later. It is a common mistake to think that this is an essential part of a relationship

[EJB] I agree entirely with this principle.  It was one of Nijssen’s principles in his 1980s course in information analysis, and that was my introduction to information modeling.

[EJB] The problem with UML in this regard is that it defaults to a constraint.  The interpretation of an association end that has no stated multiplicity is ‘exactly one’.  This is a part of the object-oriented programming background.  The proper default for relationships is 0 or more, unless the modeler says it is constrained.  But 0 or more is harder to implement in an OOPL – you have to pick a paradigm for arrays or lists.

  consider marriage. Consider the issue of 'tenancy' in a SaS system.    How many customers may a customer representtive have?  In a family office, exactly one?   If you do your model with very few multiplicity assertions, and let those be made at a later time, following the Kanban and general good architecture principle of deffering commitments to details until just in time, you can make much faster progress.

[EJB] Yes.  When you are doing the analysis, you want to document the relationships as you discover them, and determine the rules  and constraints for them later.  The unfortunate choice of default in UML means that you can’t document the existence of a relationship without knowing its multiplicity, or you can, but you get a model that isn’t what you meant.

[EJB] I have a largely negative reaction to the idea that language syntax should enforce “good” modeling practice.  Language syntax should ENABLE _expression_ of intent and PERMIT good modeling practices.  The bitter lesson is that “good practice” in modeling Java programs and “good practice” in modeling databases and “good practice” in modeling the problem space may be different and conflicting.  This supports William’s very next assertion:

So, don't compare your good practice in one language with other people's poor practice in another.  And don't compare your work as an individual to the work of a standards body. Apples and apples, please.


I agree with Edward that NIEM/ORM is much better than either of them in expressing the semantics of the world, but he is right that they aren't well enough supported.

 

Yes, I have been UML's greatest critic over the years, for two reasons.  1) I would rather that cardinality be portrayed graphically, rather than by characters


I disagree, because while a picture is worth a thousand words, an equation is worth a thousand pictures. 

 

[EJB]  Here I have to differ.  The issue is what audience the picture/text/equation is intended to communicate with.  An equation is worth very little to persons who have little experience in mathematics and even less comfort with its languages.  I personally find the shift from text to equations in computer science papers to require a mental shift of gears.  It is a different language, with a different semantic foundation.

 

2) The hype that suggested that there exists such a thing as "object oriented analysis", and UML was an _expression_ of that.


Let me point to  Rebecca Wirfs-Brock and Eric Evans. They do relate thier modelling work to software.  But this makes their work more easily accessible.   You and I think the two should be separated, and we are right. But again, we can do that ourselves. We don't have to toss out the baby.

 

[EJB] In my experience the relationship between object-oriented analysis and object-oriented programming differed widely among the authors who wrote about o-o analysis.  I mentioned once to Steve Mellor that I found the Shlaer-Mellor book interesting, and Steve responded “interesting that the two authors clearly disagreed on the meaning of the title”.
 

(No.  there is analysis of a domain.  Once you've done  that, you can apply technology to create a solution using object-oriented technology or relational technology or whatever the current fad might require.  It is not the same thing.)


Of course. There is analysis of a domain, but you can use whatever conceptual model you choose to DO the analysis. It can be done very partially with E/R, more concisely with OWL, or more fully and richly with a tool like Enterprise architect, which lets you ship little parts to E/R and OWL.   I think everybody who thinks about this long ago realized that the "hype" you are talking about was just that. The OMG's model driven architecture recognized this, applying some but not enough of RM-ODP and IEEE a decade ago now, so the ":hype" windmill you are jousitng at is about 20 years old.

 

[EJB] I hope that we all agree that the idea that the problem space model is the solution model has never been correct, for either info analysis v database schemas or o-o analysis v. o-o programming.  [EJB]  The late Selden Stewart once observed that “any language used to produce a formal description of a problem space from which executable code is automatically generated is a programming language.”  I would say rather that, if the intent of the formal model is to produce an implementation by rote transformation, then the model is an implementation model.”  And I think David, William, John and I are all in agreement on that part.

 

[EJB] I see, however, that some of our educated journeyman knowledge engineers think that a good OWL model is one that allows the chosen reasoner to do the test classifications quickly.  It is just another version of making the problem space model the solution model, because the OWL model is the implementation schema.  A clear axiomatic representation of a problem space may need to be restructured, simplified, and assisted with helper axioms and other controls to produce an efficient “theory” for a particular kind of use by a particular reasoner.  Knowledge engineering is an engineering activity, and like the others it has both analytical and solution models.  We should not again make the mistake of assuming that a good analytical OWL model can be judged by the performance of a reasoner.

 

-Ed

 


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (01)

<Prev in Thread] Current Thread [Next in Thread>