[Modeling] Class Diagram Specification
Hossam Allam
hallam@cedare.org.eg
Thu, 05 Jun 2003 14:14:25 +0200
--=====================_275619234==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Dear Mr. Huget
Concerning Class Diagram specification, I have identified that there are
two new entities; Agents and Intelligent Agents entities. Intelligent agent
is an agent with learning capabilities as I clam. Learning is considered
the highest level of the intelligence dimension. For the Class diagram I
propose to have two new shapes one for agent and one for intelligent agent
such as in UML class diagram you have one shape for Passive class and
another one for Active class. The advantage in having two shapes is to
visualizes the capabilities of the agent or intelligent agent from the
class diagram.
If you think that adding such learning (intelligent) agent idea is
applicable I can start to add more input.
Thank you for your time
Regards
Hossam Allam
At 12:54 PM 5/26/2003, Marc-Philippe Huget wrote:
>Hello all,
>
>Since now my duty on interaction diagram specification is almost
>finished (for the first version waited for June, 1st, I think the
>current version will be issued soon after proof-reading and the like), I
>have plenty of time to work on class diagram specification that was
>really bad considered by me... Sorry for that.
>
>Well, here are my feelings around class diagrams. I would like to share
>them with you to know if you agree with me:
>
>Class diagrams for object systems are "easy" to do, you write the
>attributes, the methods, the associations and it is finished, for sure,
>we cannot apply the same recipe for agents since usually you don't
>handle String k1 = "believe self (a = 10)" but (believe self (a = 10)).
>My idea is the following, we need to distinguish two levels in class
>diagram specification: 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.
>Moreover, that would be an utopia to say: we know all the different
>kinds of agents that could be implemented as a consequence, we need to
>offer in this class diagram specification: some "agent template" and
>elements to fulfill these "templates".
>
>So, here is the plan I would like to follow:
>
>Class diagram specification:
>1. Scope
>2. What is an agent? I know this question is a lot of pain for everybody
>but at least we need to explain what this specification covers
>3. "Generic agent description", there are many different agent types but
>at least, they all share some elements in common: agent id, role and
>group, this generic agent will have these elements and all the different
>kinds of agents will be a derivation of this one
>4. Elements for agent description: beliefs, knowledge, ontologies,
>protocols, etc. This section will present how to describe all these
>elements to be included in the agent class diagram.
>5. Derived agent types: reactive agents, BDI agents, mobile agents, etc.
>This section will present how elements from Section 4 will be used and
>included in agent class diagram to give a specific kind of agents.
>It means that the end user that would like to create a BDI agent will
>read Section 5 on BDI agents, then s/he will take description of
>elements in Section 4, then includes them in the class diagram, then
>adds other features.
>
>Until now, we were in the design level, we now move to the
>implementation level When I speak about implementation level , I refer
>to the fact that I would like to have a design level oriented to agent
>description and an implementation level where it is possible to
>represent agent features as usual UML class diagrams if possible
>6. Implementation level. For instance, a belief is an object instance of
>a class X where there are Y attributes, the believer from the design
>level is the attribute String Z, etc.
>
>That's my idea so, since we are late to provide the class diagram
>specification (my fault), I would like to have a prompt answer from you
>about several points:
>
>1. Design level/Implementation level: pros and cons, why?
>2. Document structure
>3. Elements that would be provided within agents
>
>As soon as we have a clearer view, I can begin to write even if some
>parts are already done. Thanks in advance for your help.
>
>Cheers,
>Marc-Philippe
>
>
>--
>Marc-Philippe Huget
>
>Agent Applications, Research and Technology Group
>Department of Computer Science
>University of Liverpool
>Chadwick Building, Peach Street
>L69 7ZF Liverpool
>United Kingdom
>
>email: mph@csc.liv.ac.uk
>http://www.csc.liv.ac.uk/~mph
>
>
>
>_______________________________________________
>Modeling mailing list
>Modeling@www.fipa.org
>http://fipa.org/mailman/listinfo/modeling
-------------------------------------------------------------------------------------------
Hossam Allam,M.Sc
Information Systems Specialist
CEDARE - Centre for Environment and Development for the Arab Region & Europe
2 Elhegaz St, Roxy, Heliopolis, CEDARE Building
P.O. Box: 1057 Heliopolis Bahary, Cairo, Egypt
Tel #:(202)-4513921/2/3/4 ext:666
Fax #: (202)-4513918
Email: hallam@cedare.org.eg
email@cedare.org.eg
Web address: http://www.cedare.org.eg
--------------------------------------------------------------------------------------------
--=====================_275619234==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<font size=3>Dear Mr. Huget<br><br>
Concerning Class Diagram specification, I have identified that there are
two new entities; Agents and Intelligent Agents entities. Intelligent
agent is an agent with learning capabilities as I clam. Learning is
considered the highest level of the intelligence dimension. For the Class
diagram I propose to have two new shapes one for agent and one for
intelligent agent such as in UML class diagram you have one shape for
Passive class and another one for Active class. The advantage in having
two shapes is to visualizes the capabilities of the agent or intelligent
agent from the class diagram. <br><br>
If you think that adding such learning (intelligent) agent idea is
applicable I can start to add more input.<br><br>
Thank you for your time<br><br>
Regards<br><br>
Hossam Allam<br><br>
<br><br>
At 12:54 PM 5/26/2003, Marc-Philippe Huget wrote:<br>
<blockquote type=cite class=cite cite>Hello all,<br><br>
Since now my duty on interaction diagram specification is almost<br>
finished (for the first version waited for June, 1st, I think the<br>
current version will be issued soon after proof-reading and the like),
I<br>
have plenty of time to work on class diagram specification that was<br>
really bad considered by me... Sorry for that.<br><br>
Well, here are my feelings around class diagrams. I would like to
share<br>
them with you to know if you agree with me:<br><br>
Class diagrams for object systems are "easy" to do, you write
the<br>
attributes, the methods, the associations and it is finished, for
sure,<br>
we cannot apply the same recipe for agents since usually you don't<br>
handle String k1 = "believe self (a = 10)" but (believe self (a
= 10)).<br>
My idea is the following, we need to distinguish two levels in
class<br>
diagram specification: 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 "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>
Moreover, that would be an utopia to say: we know all the different<br>
kinds of agents that could be implemented as a consequence, we need
to<br>
offer in this class diagram specification: some "agent
template" and<br>
elements to fulfill these "templates".<br><br>
So, here is the plan I would like to follow:<br><br>
Class diagram specification:<br>
1. Scope<br>
2. What is an agent? I know this question is a lot of pain for
everybody<br>
but at least we need to explain what this specification covers<br>
3. "Generic agent description", there are many different agent
types but<br>
at least, they all share some elements in common: agent id, role
and<br>
group, this generic agent will have these elements and all the
different<br>
kinds of agents will be a derivation of this one<br>
4. Elements for agent description: beliefs, knowledge, ontologies,<br>
protocols, etc. This section will present how to describe all these<br>
elements to be included in the agent class diagram.<br>
5. Derived agent types: reactive agents, BDI agents, mobile agents,
etc.<br>
This section will present how elements from Section 4 will be used
and<br>
included in agent class diagram to give a specific kind of agents.<br>
It means that the end user that would like to create a BDI agent
will<br>
read Section 5 on BDI agents, then s/he will take description of<br>
elements in Section 4, then includes them in the class diagram,
then<br>
adds other features.<br><br>
Until now, we were in the design level, we now move to the<br>
implementation level When I speak about implementation level , I
refer<br>
to the fact that I would like to have a design level oriented to
agent<br>
description and an implementation level where it is possible to<br>
represent agent features as usual UML class diagrams if possible<br>
6. Implementation level. For instance, a belief is an object instance
of<br>
a class X where there are Y attributes, the believer from the
design<br>
level is the attribute String Z, etc.<br>
<br>
That's my idea so, since we are late to provide the class diagram<br>
specification (my fault), I would like to have a prompt answer from
you<br>
about several points:<br><br>
1. Design level/Implementation level: pros and cons, why?<br>
2. Document structure<br>
3. Elements that would be provided within agents<br><br>
As soon as we have a clearer view, I can begin to write even if
some<br>
parts are already done. Thanks in advance for your help.<br><br>
Cheers,<br>
Marc-Philippe<br><br>
<br>
--<br>
Marc-Philippe Huget<br><br>
Agent Applications, Research and Technology Group<br>
Department of Computer Science<br>
University of Liverpool<br>
Chadwick Building, Peach Street<br>
L69 7ZF Liverpool<br>
United Kingdom<br><br>
email: mph@csc.liv.ac.uk<br>
<a href="http://www.csc.liv.ac.uk/~mph" eudora="autourl">http://www.csc.liv.ac.uk/~mph</a><br><br>
<br><br>
_______________________________________________<br>
Modeling mailing list<br>
Modeling@www.fipa.org<br>
<a href="http://fipa.org/mailman/listinfo/modeling" eudora="autourl">http://fipa.org/mailman/listinfo/modeling</a>
</blockquote>
<x-sigsep><p></x-sigsep>
-------------------------------------------------------------------------------------------<br>
Hossam Allam,M.Sc <br>
Information Systems Specialist<br>
CEDARE - Centre for Environment and Development for the Arab Region & Europe <br>
2 Elhegaz St, Roxy, Heliopolis, CEDARE Building<br>
P.O. Box: 1057 Heliopolis Bahary, Cairo, Egypt<br>
Tel #:(202)-4513921/2/3/4 ext:666<br>
Fax #:<x-tab> </x-tab>(202)-4513918<br>
Email: hallam@cedare.org.eg<br>
<x-tab> </x-tab>email@cedare.org.eg<br>
Web address: <a href="http://www.cedare.org.eg/" eudora="autourl">http://www.cedare.org.eg<br>
</a>--------------------------------------------------------------------------------------------</font></html>
--=====================_275619234==_.ALT--