Re: [COAS-List] Some Ideas from the UML Spec

["Tom Culpepper" <tcculpepper@wpmail.code3.com>]

I have interlaced my comments below starting with TCC.

>>> Tim Brinson <tim@protocol.com> 10/08 4:17 PM >>>
I looked over the "UML Notation Guide" from the OMG server (version
1.1).  I only reviewed the Static Structure Diagrmas since they seem to
be most relevant to the work we are currently doing.  Thought I would
pass on some information that is relevant to topics on today's
conference call or may be of interest to other modeling for COAS.


"An attribute is semantically equivilent to a composition association
(black diamond).  However the intent and usage is normally different." 
It appears from the example that the diamond is on the aggregate end and
the role at the other end from the diamond is the name of the attribute
in the aggregate.

TCC - I believe Rational Rose has some problems. I agree the diamond goes on the end which will contain the attribute that defines 
the reference or value depending on whether it is filled in.

The keywords/sterotypes <<type>> and <<implementation class>> can be
used above a class name to differentiate UML Classes that are not or are
implemented in a programming lanuguage.  For example we could designate
"Blob" as <<implementation class>> and things like "Audio" and
"Dictation" as <<type>>. 

TCC - seems reasonable.

An interface uses the same symbol as class but has no attributes or
relations - only operations.  The keyword/sterotype <<interface>> may be
used above the interface name.  These may become important when we get
to modeling the access service.

TCC - agree.

UML has a Parameterized Class, also called Template.  When we talk about
templates for COAS maybe we should use the term "Observation Template".

TCC - agree.

We should probably think of a UML package name for the COAS information
model.  I will start out the consideration by proposing "Observation
Data" package.  Any other thoughts?  When we model the access service I
propose it resides in the "Observation Access" package.  There would
then be an <<imports>> dependency (arrow) between the Observation Access
package and the Observation Data package.

TCC - I propose what ever we call it "Information Model", "Data Model", "Object Model" that we
then name the package the same to minimize ambuguity.

BTW, is it "Information Model" or "Data Model" or "Object Model"? 
Should we call one the "Information Model" (for the current work) and
the other the "Service Model" (for the remote service component)?

TCC - see above comment.

The Multiplicity indication on Association ends may be supressed on a
particular association or for an entire diagram.  In general then, if
they are not shown a reader would not know what the multiplicity is.

TCC - I beleiev we should show them.

By default (if not specified) multiplicities greater than one are
unordered.

"Aggregation diamonds are attached to the class that is the aggregate. 
If the diamond is filled (black diamond) then it signifies the strong
form of aggregation known as composition."

TCC - I also believe this is true. The hollow diamond is by reference and the filled diamond is by value..

(UML recommendation) "Begin class names with an upper case letter.";
"Center class name in boldface."; "Begin attribute and operation names
with a lowercase letter"

TCC - ok.

The generalization/specialization relationship can have constraints
specified.  In the specialization of Observations we have discussed
(possibly) specifying both "disjoint" ("a descendent may not be
descended from more than one of the subclasses.") and "complete" ("All
subclasses have been specified.").  If we were to specify both of these
they would be shown on the diagram as "{disjoint, complete}" toward the
triangle end of the relationship.  To explicitly indicate that the issue
is open but we are leaning that way I propose we put then in now as
"{?disjoint, ?complete}".

TCC - ok.

If we determine that Observation can not be instantiated we could create
our own steriotype called "<<abstract>>" to put on the class.  Likewise
if we determine that CompositeObservation and AtomicObservation can not
be subclassed we could create our own sterotype "<<final>>" to label
them with.  For now we could put them in as <<?abstract>> and <<?final>>
to show we are leaning that way but the issue is still open.

TCC - If the class is abstract (which means no instanceing) then Rational Rose changes
the font to italic.

I could not find any kind of a description of what UML means by
"aggregation" but did for "composition".  I have heard many people
suggest that aggregation is containment by reference while composition
is containment by value.  The UML spec does not have any indication of
"by reference" in class diagrams.

TCC - any luck and way a "+" in front of the role indicates?
Regards,

Tim Brinson