[Modeling] Class Diagram Specification

Giovanni Rimassa rimassa@ce.unipr.it
Thu, 05 Jun 2003 19:45:19 +0200 

--------------090907070602060807090500
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Wagner, G.R. wrote:

>>Marc-Philippe wrote:
>>"the first level is the one, we always consider
>>knowledge, acquaintances, roles, groups, protocols, etc. and we have a
>>second level where we describe those elements in a 
>>"computable" manner,
>>see the example above, the first level is at design level, the second
>>one is at implementation level, and above all, we need to give recipes
>>to help designers moving from the first level to the second one."
>>
>>and in level 1, we deal with roles, groups, etc. And to this level I 
>>have pointed in my previous messages.
>>
>>AUML agent diagram is in level 2, because we have implementation 
>>consideration.
>>
>>I hope it is clear now :)
>>
> 
>Yes, it's clear, but you should better read my message before 
>you reply to it: at both of your levels (and in general, we
>distinguish between 3 levels, as in the MDA), we can/should
>use UML class diagrams! UML class diagrams are a powerful
>language for conceptual modeling of real world domains that
>include agents and objects.
>
>Do you really suppose that you can come up with a better 
>conceptual modeling language than UML class diagrams (or
>some extension of it)? 
>
Gerd,
I really appreciate you pointing out what UML really is (a conceptual 
modeling language), and I fully agree with
your position. I also think that you should consider that when you model 
something there is not just the modeling
language but also the modeled entities, that belong to some domain. 
Since we are trying to model software agents
here, there's got to be some domain concept somewhere: complaining about 
having AI concepts in the AUML class
diagrams metamodel is like complaining about having InterestRate in the 
metamodel of a financial application framework ;-)

That said, there's always the trick of the endless meta-level fugue, 
where extending a base level means adding some data to
its metalevel. So, it is OK for AUML Class Diagrams to extend UML Class 
Diagrams, as long as this does not imply
extending the UML metamodel, but just adding data (stereotypes, 
constraints, and the like) to it.

Moreover, I believe we should strive for a precise and clear 
specification (this is a TC belonging to a standard body, after all),
one that could be cut and pasted into the UML 2.0 Superstructure 
document and you wouldn't notice the difference.

So, I would invite you and all the other contributors to try and ground 
the discussion by making concrete proposals and by
referring to the UML metamodel in precise way (i.e. "let's add this 
stereotype", "let's modify this association", "let's give this
semantics to this new model element").

Bye,

    Giovanni

>
>-Gerd
> 
>
>_______________________________________________
>Modeling mailing list
>Modeling@www.fipa.org
>http://fipa.org/mailman/listinfo/modeling
>


-- 
	         Giovanni Rimassa
     Dipartimento di Ingegneria dell'Informazione
         Universita` di Parma - Parma (ITALY)
    Phone: +39 0521 905712 -  Fax: +39 0521 905723



--------------090907070602060807090500
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Wagner, G.R. wrote:<br>
<blockquote type="cite" cite="mid:AA2E843B3FC96349BF60350202650BE9257734@tmex1.tm.tue.nl">
  <blockquote type="cite">
    <pre wrap="">Marc-Philippe wrote:<br>"the first level is the one, we always consider<br>knowledge, acquaintances, roles, groups, protocols, etc. and we have a<br>second level where we describe those elements in a <br>"computable" manner,<br>see the example above, the first level is at design level, the second<br>one is at implementation level, and above all, we need to give recipes<br>to help designers moving from the first level to the second one."<br><br>and in level 1, we deal with roles, groups, etc. And to this level I <br>have pointed in my previous messages.<br><br>AUML agent diagram is in level 2, because we have implementation <br>consideration.<br><br>I hope it is clear now :)<br></pre>
    </blockquote>
    <pre wrap=""><!----> <br>Yes, it's clear, but you should better read my message before <br>you reply to it: at both of your levels (and in general, we<br>distinguish between 3 levels, as in the MDA), we can/should<br>use UML class diagrams! UML class diagrams are a powerful<br>language for conceptual modeling of real world domains that<br>include agents and objects.<br><br>Do you really suppose that you can come up with a better <br>conceptual modeling language than UML class diagrams (or<br>some extension of it)? <br></pre>
    </blockquote>
Gerd,<br>
I really appreciate you pointing out what UML really is (a conceptual modeling
language), and I fully agree with<br>
your position. I also think that you should consider that when you model
something there is not just the modeling<br>
language but also the modeled entities, that belong to some domain. Since
we are trying to model software agents<br>
here, there's got to be some domain concept somewhere: complaining about
having AI concepts in the AUML class<br>
diagrams metamodel is like complaining about having InterestRate in the metamodel
of a financial application framework ;-)<br>
    <br>
That said, there's always the trick of the endless meta-level fugue, where
extending a base level means adding some data to<br>
its metalevel. So, it is OK for AUML Class Diagrams to extend UML Class Diagrams,
as long as this does not imply<br>
extending the UML metamodel, but just adding data (stereotypes, constraints,
and the like) to it.<br>
    <br>
Moreover, I believe we should strive for a precise and clear specification
(this is a TC belonging to a standard body, after all),<br>
one that could be cut and pasted into the UML 2.0 Superstructure document
and you wouldn't notice the difference.<br>
    <br>
So, I would invite you and all the other contributors to try and ground the
discussion by making concrete proposals and by<br>
referring to the UML metamodel in precise way (i.e. "let's add this stereotype",
"let's modify this association", "let's give this<br>
semantics to this new model element").<br>
    <br>
Bye,<br>
    <br>
&nbsp;&nbsp;&nbsp; Giovanni<br>
    <br>
    <blockquote type="cite" cite="mid:AA2E843B3FC96349BF60350202650BE9257734@tmex1.tm.tue.nl">
      <pre wrap=""><br>-Gerd<br> <br><br>_______________________________________________<br>Modeling mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:Modeling@www.fipa.org">Modeling@www.fipa.org</a><br><a class="moz-txt-link-freetext" href="http://fipa.org/mailman/listinfo/modeling">http://fipa.org/mailman/listinfo/modeling</a><br><br></pre>
      </blockquote>
      <br>
      <br>
      <pre class="moz-signature" cols="$mailwrapcol">-- <br>	         Giovanni Rimassa<br>     Dipartimento di Ingegneria dell'Informazione<br>         Universita` di Parma - Parma (ITALY)<br>    Phone: +39 0521 905712 -  Fax: +39 0521 905723<br><br></pre>
      <br>
      </body>
      </html>

--------------090907070602060807090500--