RE: RIM 0.51 distribution

["Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>]

Comments:

Figure 1:  
-association from organization to contact is aggregation (hollow diagram)
not composition (solid diamond); contact can live on its own and may switch
organizations
-association from organization to address is aggregation not composition;
address can live on its own and may have different organization reside at
the address
-add VersionInformation object to view or have complete model in appendix.

It needs to be clearer that the interfaces in this document are not
publically access via registry services, but accessible through ad hoc
query.  

(side note: Difference between boundary (interfaces), control, and entity
classes needs to clean up slightly.  These are from the Unified Process:
-Boundary/ interface classes are publically accessible and behavior based.
These are typically those in Registry Services.
-entity classes are data related and have getters/setters. This is the term
I was referring to Tuesday.
-control classes can manage the creation, destruction, threads, and state of
other classes generally managing the flow of a use case, resolving business
logic, therfore also having some behaviour. 

I am not certain if TogetherJ needs to define classes as <<interfaces>> to
enable proper Java code generation.)

Line 336 and 337; metamodel.  Delete sentence as purists may have problems
with this.  This model does span across meta-levels. Organization, address,
classification-node etc. are at the M1 level.  M1 implies a model or
metadata whose instance are data.  Classification, ManagedObject etc are at
M2. M2 implies a metamodel whose instances are models.  refer to OMG MOF
specification for clarification.  A classification scheme instance can be a
model at any meta-level, which IMHO is more general than MOF.

Line 320:  change from Detail View to "Inheritance View".

Figure 2:
Delete address and contact.  They are not part of the hierachy and do not
add value to this view.

I am OK with the format of the method summaries, but generally I prefer to
see three column table approach: Method Name, Description, Return.  If this
is autogenerated from Together, I am OK with this.

Line 401:
-change to "enumeration list" 
-Delete PartyAgreement as an objectType.  Registries should not persist this
type of information due to legal concerns, risky of confidentiality.
Formation of this object is done outside a registry.
-Add UML model as an objectType.  
-ditto on three column format


Line 435: change "act" to "event"
Line 444 - 470
- Create separate chapter that list supporting entity classes.
- add VersionInformation class here; as referenced in Line 365

Line 583:  I assume "extent" should be "intent"
Line 695:
=font changed to Times New Roman

Line 673:
- typo: one permission 0bject: word object actually has a zero by mistake

Line 681:  Figure 8:
- Uni-directional associations with multiplicity on both ends are
semantically incorrect.  Get rid of the arrow if the path is bi-directional.
The Priviledge object should be a uni-directional composition to
PriviledgeAttribute with cardinality 0:n.
- Relationship to Identity is wrong:  a Principal should be only to one
identity and should represent the user. This is a 1:1 bidirectional
association
Line 711: 
- typo: different

Line 715-719:
- Security Clearance definition is vague.  What is the difference between
this and the rules specified in Lines 684-689?

Line 735:
- Add sentence:  A groups is an aggregation of users (identity) that may
have different roles.

Line 745-746:
- This is not the same verbiage as in the .002 document.  I prefer the
previous defintion.  I interpret the Principal to be the instantiated object
that represents the valid roles, groups, and accessible methods for a
specific user.  It is derived from the Priviledges object.  

Scott