Re: [ontolog-forum] UML and Semantics

["David C. Hay" <dch@xxxxxxxxxxxxxxxxxxxxxxx>]

William, Ed, 

At  12/5/2012 01:55 PM, you wrote:

> 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.

[dch]  Actually, what I am promoting is the "Highly Abstract
Yellow" (HAY) version.  I always present models as a
succession, beginning with one or two entity types highlighted in yellow,
followed by a drawing adding one or two more, with relationships, where
only the additions are in yellow.  The maximum size for a subject
area is maybe 15 boxes.  

>  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. 

[dch]Point taken. 

> But when you
> depart, you will lose the UML-educated audience.

[dch]Yes!  This is not oriented towards the UML-educated audience! I
am forced to use the notation because there are IT people in the audience
who object if they don't recognize the symbols.  

[dch]Actually, I got in trouble in an OMG group because I was redefining
things.  So I always make it very clear at the beginning that this
is a HAY model.  So far, that seems to work. 

> 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.

By the end of the project, you must write up the model.  This is
much easier if you use the naming (and aesthetic) standards I advocate
(which I describe below).  The finished book is then something that
can be handed around to the business community.  Again, it is about
the text.  The drawings are supplemental. 

> [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.  

[dch]By the time I get to an architectural model, I only have one to many
relationships.  (See 
http://tiny.cc/6c9zow
 for my definitions of "architectural" and "semantic"
data models.)  A many-to-many relationship conceals important
information about each instance of the relationship.  

> 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.

The way I name relationships in any model (borrowed from my E/R days) is
"Each <subject class> must be | may be <predicate> one
and only one | one or more <object class>."  For
example,  "Each Order must be from one
and only one Party"; "Each Party may
be a customer in one or more Orders. 

[dch]Thus you have normal, easy to understand English sentences. None of
this "0, one or more" silliness.  Indeed, a feedback
session is to get agreement on these sentences.  The drawing is for
taking notes.  

[dch]Note that using a <predicate> instead of a
"roleName" in UML is a major departure from the logic behind
that notation.  That's why it has to be HAYUML instead of just UML.

[dch]Your example could be in what I call a "semantic model".
(See above hyper link.)   I would put it that "Each
Employee may be supervised by one or more
Supervisor, where each Supervisor must be over one
Employee and a role played by one and only one
Employee.  In the Architectural model, I would replace
Employee with Employment, where each Employment must
be of one and only one Person, and must be with one
Organization.  I would then replace Supervisor with
Supervisory Role, where each Supervisory Role must be
played for one and only one Employment and played by
one and only one (other) Employment.  

[dch]Note that Supervisory Role (and Employment, too , for
that matter) probably has as attributes "effective date"
and "until date".  Thus, over time, each
Employment might be supervised via one or more
Supervisory Roles, and each Employment might be player
of one or more Supervisory Roles. 

[dch]Here, by the way (I think) ORM allows the notation to show that the
same Supervisory Role cannot be both played for and
played by the same Employment.  This is in the
category of business rules (constraints) that have to be documented
outside the model--both in E/R and UML. 

[dch]Note that none of this conversation has anything to do with UML,
per se.  I happen to use the notation for class models, but
the boxes are <entity types> and the roleNames are
<predicates>.  

[dch](In my time spent with the OMG, it took me a very long time to sort
out how what I was doing was different from the mind set of the UML
folks.  As it became clear, it seemed that if I was to play this
game, I would have to invent the "stereotypes" for <Entity
Type> and <Predicate>.   But, since the whole point of
this model is to present it to non-technical business people, I decided
against doing that.  I took the approach of announcing up front that
this is a different kind of model, and these are what the symbols mean.

[dch]It  turns out, I can in fact do that within the syntax of the
modeling notation, but I don't have to display the stereotypes. Ah,
well.  Next time.

[dch]I also enforce aesthetic standards, which is something both UML and
E/R modelers have problems with.  

> [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.  

[dch]Fair enough.

[dch]The syntax should only enable best practices, but "best
practices" should be defined.  I have described those
extensively in my last two books, but they come down to what I described
above:

1. Distinguish between "semantic", "architectural"
and "design" models, as described in
http://tiny.cc/6c9zow
. 
2. In architectural and semantic models, only use classes that are
"entity types"--classes of things in the real world. 
3. In architectural and semantic models, name everything in English.
4. In architectural and semantic models, define relationships as
assertions about something in the domain being modeled. as described
above.
5. Apply appropriate aesthetic rules to the drawing. This applies to
any kind of models. (Another posting, perhaps.)

(By the way, some E/R syntaxes, and some tools implementations of them,
make these best practices nearly impossible to carry out.)

> And don't compare
> your work as an individual to the work of a standards body. Apples and
> apples, please. 

I'm working on the standards bodies.  That's tougher.

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.

[dch]  I'm with EJB, here.

 

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.

[dch] To whom?

   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.

[dch]I am pleased to agree with you on that.  But that windmill
affected a lot of what I've written in the past.

>  
> [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.  

[dch]You raise a point that has been troubling me.  As I go into the
OWL world, I start by trying to map my E/R models to it.  You can do
that, but this misses the point of OWL.  In my model, I am trying to
make assertions about the world, but I have the "closed world"
view.  It is true that, until now, I have assumed that my model is
of the corporate data asset, and it was important to be able to describe
the rules that constrain what data may be added.  The OWL folks, on
the other hand, are out there exploring and trying to draw conclusions
from large bodies of data, without preconceptions as to what they will
find.  

I am pursuing the objective of translating my Enterprise Model Patterns
into OWL, and publish them as a high-level ontology. My idea is that they
can be included as a starting point to be part of other people's more
detailed ontologies.  Is this practical?  I have no idea.

> 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
>  
>  

Thanks, all, for giving me this chance to speak. 

> _________________________________________________________________
> 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
>  

_________________________________________________________________
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)