Project: UML class diagram in ATOM3

Introduction

The first part of the project will consist of emulating an UML class diagram GUI in
ATOM3 using the entity relationship formalism.  The GUI will contains all the
constraints of the class diagrams so that the user can create designs following
OMG specifications.  However, we will not be able to create new formalisms with
the class diagram GUI until we map it to an equivalent entity relationship formalism.
This mapping will be the second part of the project and will be realized with ATON3's
graph grammar.  We need that mapping to create a isomorphic ER diagram from a
Class Diagram so that we can use ER built-in code generation for
creating new formalisms.  The final part of the project will be to
automatically generate python source files from an UML class diagram created
in the GUI of part 1.

Goals of the project:

- Provide a friendly GUI for designing UML class diagrams:

	1) OMG class diagram specifications must be realised in the
           GUI	 	 	
	2) Every single OMG constraint must be respected and carefully verified
	   at run-time

- Provide a way to create new formalism using UML class diagrams

	1) The resulting ER diagram must be isomorphic to the UML Class Diagram

- Provide python code generation from UML class diagrams:
	
	1) The generator will create code corresponding to the static part of a design
	2) The generator will be based on what has already been built such as DIA2CODE
	3) A build in text editor for classes will allow user code to be added to the generated code



Specific Information : UML class diagram GUI

Version 1.0

Author : Marc Provost

In the first version of the specifications, we tried to select the most
important features of the OMG specification.  The goal is to create a
prototyte in a short period of time containing the most used feature of OMG's
UML so that we can start with the second part of project as soon as possible.
Indeed, if we can create a formalism that will replace ER in ATOM3, we will be
able to add features to it by reprogramming it in itself so it is not vital to
include every single OMG specifications at first.  However, it is vital to get
a working class diagram formalism so that users can start creating formalism
using inheritance without emulating it with ER formalism.

******** Important notice ***********

Since the first part of the project is syntax oriented, the following
specification is mostly (not to say completely) about syntax.  We will deal
with the semantic of UML class diagram in the second part of the project, when
we will have to give an interpretation of the diagrams created with this tool


Specifications:

General statement:

Elements of a UML class diagram : {Class, Association, Generalization}

Detailled information :

1) Class:

	A conceptual abstraction represented graphically by a rectangle
	containing:

	- Stereotype of the class {concrete, interface, abstract, <user
	  defined>} 	
	- Name of the class
	- List of attributes {visibility, type, name, value}
	- List of methods name {visibility, signature: (return type, name,
          parameters)}

2) Association:

	A semantic relationship between two classes represented graphically
	by a line containing:

	- Name of the relation
	- AssociationEnds (2+)

		Represent the type of connection on each end of the
		relation.  Graphical representation on the endpoints of the
		line depends on the type.  Contains:

 		- Rolename of each class in the relation
		- Multiplicity
		- Type {isNavigable, composition, aggregation}

3) Generalization:

	Simple:

	A relationship between *one* more general to one or many specific
	classes. The graphical representation is a line with an arrow
	connected to the general class.  Contains:

	- Type {complete, disjoint, incomplete, overlapping}

	
	Multiple:

	A relationship between several more general class to one or many
	specific classes.  The graphical representation is a line with an
	arrow connected to the general class.  Contains:

	- Type {complete, disjoint, incomplete, overlapping}


Constraints:

The following constraints are valid within one Namespace.  In other words,
when we are referring to other Elements in the constraints specification, it is
implicit that those elements are contained in the same Namespace.

Non-specific constraints:

	- Class, Association and Generalisation must have unique names with
	  respect to each other.
	- The name of an attribute must be unique with respect to
	  the name of the associationEnds contained in the same Class
	- Circular inheritance is not allowed
	

Specific constraints:

1) Class
	 
        A) Attributes :
		- Each attribute must have an unique name with respect to
	          other attributes and methods
		- The value is optionnal


	B) Methods :
		- The parameters inside a given method must have unique names
		- The name of the method must be unique with respect to
		  other parameters
		- The signature of the method must be unique with respect to
		  other methods


2) Association

	- Each associationEnds in an association must have an unique name  
	- At most one associationEnds may be an aggregation or composition
	  within the association
	- If an association has three or more associationsEnds, then no
	  then no associationEnds may be an aggregation or composition
	- The class connected to an AssociationEnd cannot be an Interface if
	  the associationEnd is navigable
	- An associationEnd may not belong by composition to more than one
	  composite instance.  In other words:
	  if self.AssociationEnds.type == aggregation  ==>
	  self.AssociationEnds.multiplicity = 1

3) Generalization

	- The parent must be included in the namespace of the child
	- The stereotype of the parent class must be the same as the
	  stereotype of the child class
	- Only public/protected elements must be inherited by a child
	  class