[Modeling] Document structure

[Marc-Philippe Huget]

Hi all,

I am quite a bit late to enter in the discussion, here are some of my
comments:

Radovan Cervenka wrote:

>   a.. <Title>! {name of the area}

Agree but maybe we can use a path and a name, as a consequence, we can
have a first idea of the use of the document and we can have several
documents with the same name but different paths

>   b.. Overview! {description of the area to-be-modeled. What are the
> problems, how they are usually modeled, what modeling elements are
> used by the currently used techniques, what is the applicability
> during the development cycle of MAS, etc. - informally}

I would like to add, what are the redundant solutions?

>   c.. Abstract Syntax! {UML diagram(s) of proposed metamodel; UML 2.0
> metamodel can be taken as the basis}

Except the name of the field, I agree with you

>   d.. Class Descriptions! {class-by-class description of the
> metaclasses. For each class to specify:}
>     a.. <Name>! {name of the metaclass}
>     b.. Description! {textual description of the semantics}
>     c.. Attributes {a list of contained attribute descriptions}
>     d.. Associations {a list of related relationship descriptions}
>     e.. Constraints {a list of applicable constraints (called also
> well-formedness rules), described firstly in English then in OCL}
>     f.. Notation {description of the notation (concrete syntax)}
>     g.. Presentation options {description of alternate notation}
>     h.. Examples {examples of using an element}

b. Description: do we speak about the description of the class or the
semantics of the class, the former is usually a natural language
document, the latter a formal definition

Once again, we do not feel obliged to follow strictly UML and maybe we
can have several other fields in the class description

>   f.. Diagrams {a chapter describing proposed diagrams; for each
> diagram type to specify:}
>     a.. <Diagram name> {a name of the diagram}
>     b.. Description {Description of the diagram content (what elements
> are comprised) and applicability (why and when to use this diagram)}
>     c.. Examples {some sample diagram(s) and description of their
> semantics}
>   g.. References! {a list of used and/or relevant references; papers
> and Web pages as well; reference list should be structured according
> to different sources, sub-areas, etc.}

and above all, what elements from the superstructure the diagram uses or
maybe you put this information in class description

> Furthermore we should share our UML models - they should be placed at
> the Web page into some protected area available for FIPA modeling
> members only. What UML CASE tool do you use? Will we try particular
> UML tool or XMI as an interchange format?

XMI might be a good idea as long as we share some strong links with UML,
else it would be more efficient to define our specific language (based
on XML?)

Tool? Well, I strongly agree that Rational Rose is a good solution, my
concern is money, what to do if your team does not consider this
expensive tool as essential for the team? Does it mean I am out for
several things?

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