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.
[引用]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.
[
引用][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
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.
[引用]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.
[引用]
- 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?
[
引用]
[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.
[
引用]
_________________________________________________________________
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)