Subject: RE: Policy Framework Core Information Model -- Version 1

From: "John C. Strassner" <[email-masked]>
Date: Sun, 06 Feb 2000 16:37:17 -0800

Comments inline, look for <js>...</js>

regards,
John

At 06:57 AM 1/31/00 -0800, Jon Sjoberg wrote:
>John,
>
> > So I personally would be happy to help rework the draft to "track
> > tighter",
> > as you put it, but in order to do that I need specific examples,
> > especially
> > concerning its not being compliant with UML. SO please supply
> > examples, and
> > I'll give it a shot.
>
>Here is a list of differences between CIM and UML.  If you need any help
>re-working this, let me know.
>
>1.) We don't use the inheritance of associations, so it is just more words
>that add little value to our problem.   Lets lop it out of the document.

<js> Respectfully, that is incorrect if you look at (especially) the latest 
release of the UML spec. Associations can be AssociationClasses, which have 
the combined semantics of associations and classes. From the spec:

    "The AssociationClass construct can be expressed in a few
           different ways in the metamodel (e.g., as a subclass of
           Class, as a subclass of Association, or as a subclass
          of Classifier)."

Furthermore, implementing an association as a class, as is done in both CIM 
and DEN, is an elegant way to maximize the use of object-oriented design. 
If you look at CIM or DEN, you'll see the association inheritance is 
critical in defining specialized associations in the model. Furthermore, 
since associations have properties and methods (which are essential to 
being viewed as classes) why wouldn't they also have inheritance?
</jcs>

>2.) Associations with attributes is not used in UML and seems un-necessary.

<js>
I beg to differ. I've seen it used in many applications besides CIM and 
DEN. Please refer back to the UML spec, where it says that associations can 
be implemented as classes.
</js>

>Standard information modeling says:
>     For one to many associations the key attribute(s) of the association go
>to the one.
>     For the one to one association the key attribute(s) can go to either.
>     For the many to many associations then there is an associating object
>that can hold the key attributes plus any other attributes of the
>association (the only case that is somewhat like the current "associations
>with attributes").
>
>This eliminates a whole nest of sections on associations and provides just
>secondary key attributes.  Note that where the association keys go is just
>an analysis tool and has NO relevance on the implementation.

<js>
That is implementation-dependent. Look at the CIM and DEN models, which 
provide precedence for this feature.
</js>

>3.) CreationClassName:  Do we need this?  I understand why CIM uses it, but
>UML uses the concept of categories to provide name scoping.  We have the
>category of the base PCIM.  All names within in it are scoped to be unique
>(PCIM.PolicyGroup).  There is a whole paragraph plus a bunch of attribute
>descriptions for CreationClassName that are not part of the essential
>problem.  Perhaps the UML category idea would be lighter weight?  Besides,
>in all honesty, I don't quite get the whole "weak association" thing but
>what I do get leads me to believe it is not intrinsic in the policy problem.

<js>
It's always nice to know what type of class an instance is. So I think we 
need this regardless of implementation.

If we want backward compatibility to the CIM 2.2 model, we definately need 
this. And note that PCIM uses CreationClassName as part of its scoping, so 
your argument is somewhat circular.

Finally, weak associations simply mean that the non-weak entity provides 
scoping for the weak entity. Think of a service running on a system. The 
service (e.g., BGP) can't simply exist in the ether ;-), it has to be 
hosted by some entity. In this case, it would be hosted by a router 
interface, which is part of a system. So, the BGP service is weak to the 
router system, which means that the keys used to define the service must 
include keys propagated from the system. Stated another way, the system 
helps determine the name of the service, so you can identify and 
distinguish between different instances of the same service.
</js>

>The above three deviations from UML add, what I would consider,
>non-essential complexity to the document.

<js> I disagree. There are no deviations from UML (except for the 
additional concept of a weak relationship). CreationClassName is simply an 
attribute that has been uniformly used to help distinguish an instance, 
which is, imho, a Good Thing.
</js>

><soap box>
>If, as Ed implied, we are using CIM to play nicely with others, then there
>is merit in that.  To minimize the impact on us, perhaps we could move some
>of the CIM specific text to appendices, just refer to the CIM modeling
>language document (if it is publicly available), or a combination of the
>two.

<js> The CIM meta-model and spec are publically available. </js>

>If we are using CIM because it is the modeling tool best known by the
>authors, I would assert that it is not the best tool for the job.  UML would
>be better, Shlear-Mellor would be best.

<js> CIM is not a modeling tool, it is an information model. </js>

>NON-SEQUITOR:  UML is not a bunch of boxes and arrows and therefore the use
>of boxes and arrows does not make it UML.  UML is an approach to system
>architecture, design, and even, to extremes, implementation.  CIM is NOT
>UML, or even very much like UML.  This does not mean CIM is evil, but on
>several occasions I have heard the statement the CIM is UML (or so similar
>as for there to be no distinction) as a defense.  This statement is
>inaccurate and should probably not be used.
></soap box>

<js>
Of course CIM isn't UML, I completely agree. However, I do assert that CIM 
uses portions of UML to document its information model.

You happen to be in the minority of people that really grok what UML is. 
Many people do misuse the term UML. I'll try and encourage a more correct 
usage of the term.
</js>

>Jon
>
>P.S.  Yes "quark" was supposed to be "quirk".  The spell checker was
>checking what I typed, not what I meant.

---

From: "Jon Sjoberg" <[email-masked]>
Date: Mon, 7 Feb 2000 05:52:55 -0800

John (Sorry I can't put the comments inline, but I'm having an Outlook
problem!),

1.)  The important point here is that we don't use the inheritance of
associations.  How ever associations CAN be modeled, this mechanism is not
used by us and so it is just more text in the document.  More text makes
things more difficult to understand.

2.)  There is nothing "implementation dependent" (in the sense of dictating
a design) about where you put the attribute in a relationship during
analysis.  There ARE certainly many ways to model a relationship, I am just
trying to think of one that would do what is needed with minimum excess
baggage.  This is an attempt to get the document to focus tightly on policy
issues and not modeling issues.

3.)  I'm not saying (nor did I say) that CreationClassName was useless or
can't be explained.  What I'm saying is there maybe lighter weight solutions
to the same problem that adds less bulk to the document, making it easier to
understand.

If the intent is to say:  "the modeling we have chosen is valid", of course
I agree.  My intent was merely to trim the document down to make it easier
for us slow people to understand.

What also seems clear is I'm the only one who had a problem with this.  I
guess it doesn't make sense to make (or suggest) such large changes when the
vast majority seem to be content.

  -----Original Message-----
  From: John C. Strassner [mailto:[email-masked]]
  Sent: Sunday, February 06, 2000 4:37 PM
  To: Jon Sjoberg; John C. Strassner
  Cc: [email-masked]
  Subject: RE: Policy Framework Core Information Model -- Version 1

  regards,
  John

    John,

    1.) We don't use the inheritance of associations, so it is just more
words
    that add little value to our problem.   Lets lop it out of the document.

  <js> Respectfully, that is incorrect if you look at (especially) the
latest release of the UML spec. Associations can be AssociationClasses,
which have the combined semantics of associations and classes. From the
spec:

  Furthermore, implementing an association as a class, as is done in both
CIM and DEN, is an elegant way to maximize the use of object-oriented
design. If you look at CIM or DEN, you'll see the association inheritance is
critical in defining specialized associations in the model. Furthermore,
since associations have properties and methods (which are essential to being
viewed as classes) why wouldn't they also have inheritance?
  </jcs>

    2.) Associations with attributes is not used in UML and seems
un-necessary.

  <js>

    Standard information modeling says:
        For one to many associations the key attribute(s) of the association
go
    to the one.
        For the one to one association the key attribute(s) can go to
either.
        For the many to many associations then there is an associating
object
    that can hold the key attributes plus any other attributes of the
    association (the only case that is somewhat like the current
"associations
    with attributes").

    This eliminates a whole nest of sections on associations and provides
just
    secondary key attributes.  Note that where the association keys go is
just
    an analysis tool and has NO relevance on the implementation.

  <js>

    3.) CreationClassName:  Do we need this?  I understand why CIM uses it,
but
    UML uses the concept of categories to provide name scoping.  We have the
    category of the base PCIM.  All names within in it are scoped to be
unique
    (PCIM.PolicyGroup).  There is a whole paragraph plus a bunch of
attribute
    descriptions for CreationClassName that are not part of the essential
    problem.  Perhaps the UML category idea would be lighter weight?
Besides,
    in all honesty, I don't quite get the whole "weak association" thing but
    what I do get leads me to believe it is not intrinsic in the policy
problem.

  <js>

  Finally, weak associations simply mean that the non-weak entity provides
scoping for the weak entity. Think of a service running on a system. The
service (e.g., BGP) can't simply exist in the ether ;-), it has to be hosted
by some entity. In this case, it would be hosted by a router interface,
which is part of a system. So, the BGP service is weak to the router system,
which means that the keys used to define the service must include keys
propagated from the system. Stated another way, the system helps determine
the name of the service, so you can identify and distinguish between
different instances of the same service.
  </js>

    <soap box>
    If, as Ed implied, we are using CIM to play nicely with others, then
there
    is merit in that.  To minimize the impact on us, perhaps we could move
some
    of the CIM specific text to appendices, just refer to the CIM modeling
    language document (if it is publicly available), or a combination of the
    two.

    If we are using CIM because it is the modeling tool best known by the
    authors, I would assert that it is not the best tool for the job.  UML
would
    be better, Shlear-Mellor would be best.

    NON-SEQUITOR:  UML is not a bunch of boxes and arrows and therefore the
use
    of boxes and arrows does not make it UML.  UML is an approach to system
    architecture, design, and even, to extremes, implementation.  CIM is NOT
    UML, or even very much like UML.  This does not mean CIM is evil, but on
    several occasions I have heard the statement the CIM is UML (or so
similar
    as for there to be no distinction) as a defense.  This statement is
    inaccurate and should probably not be used.
    </soap box>

  <js>

    Jon

---

From: "John C. Strassner" <[email-masked]>
Date: Mon, 07 Feb 2000 08:48:25 -0800

Hi Jon, comments inline. You did get the text to change to blue, if that's 
any encouragement ;-)

regards,
John

>things more difficult to understand.

I completely disagree. AssociationClass models an association not just as a 
connection, but as a class. Not using inheritance in this situation is 
exactly like not using inheritance for other classes. More to the point, it 
is used by the DMTF and by anyone using the DEN model.

>2.)  There is nothing "implementation dependent" (in the sense of 
>dictating a design) about where you put the attribute in a relationship 
>during analysis.  There ARE certainly many ways to model a relationship, I 
>am just trying to think of one that would do what is needed with minimum 
>excess baggage.  This is an attempt to get the document to focus tightly 
>on policy issues and not modeling issues.

Sorry, I'm not following. The point of implementing an association as a 
class is to enable us to define properties on the association class that 
are a property of a relationship, not a property of either class at the 
ends of the association. This is critical in the design of the policy 
information model.

>can't be explained.  What I'm saying is there maybe lighter weight 
>solutions to the same problem that adds less bulk to the document, making 
>it easier to understand.

But the problem is that this is already defined in CIM and DEN. Not using 
this property encourages a war between object models, which would be a Bad 
Thing.

>If the intent is to say:  "the modeling we have chosen is valid", of 
>course I agree.  My intent was merely to trim the document down to make it 
>easier for us slow people to understand.
>
>guess it doesn't make sense to make (or suggest) such large changes when 
>the vast majority seem to be content.

I don't consider you slow at all. You appear, however, to be in the 
minority. This minority consists of people that want a pure model, and to 
use that foundation to build policy models.

DEN as well as PCIM have made some compromises to help unite the different 
communities in the modeling world with the networking world. It takes a bit 
getting used to, that's all. ;-)

>>which have the combined semantics of associations and classes. From the spec:
>>
>>design. If you look at CIM or DEN, you'll see the association inheritance 
>>is critical in defining specialized associations in the model. 
>>Furthermore, since associations have properties and methods (which are 
>>essential to being viewed as classes) why wouldn't they also have inheritance?
>></jcs>
>>
>>DEN. Please refer back to the UML spec, where it says that associations 
>>can be implemented as classes.
>></js>
>>
>>If we want backward compatibility to the CIM 2.2 model, we definately 
>>need this. And note that PCIM uses CreationClassName as part of its 
>>scoping, so your argument is somewhat circular.
>>
>>additional concept of a weak relationship). CreationClassName is simply 
>>an attribute that has been uniformly used to help distinguish an 
>>instance, which is, imho, a Good Thing.
>></js>
>>
>>><soap box>
>>Of course CIM isn't UML, I completely agree. However, I do assert that 
>>CIM uses portions of UML to document its information model.
>>