(FC-Devel) repository

[Chen Ofek <cheno@glx.chief.co.il>]

Hi all

As I promised Andrey V Khavryutchenko I will try to state my view about
our tool repository.
Please comment about it.

We need a Concept repository.
A Concept is basically defined by its connections.
Every Concept has an ID and a list of Ports.

ID is simple. (something like name+namespace)

Port is some other Concept which is defined as a proto-type for
connecting to the concept.
for example : the Inheritance Concept has two ports subClass and
superClass (which are also concepts)
another example : the Model-View-Controller Concept has three ports:
Model, View and Controller.

We also need a Diagram repository (Diagram is not the graphical
definition of the design it is the model)
Diagrams will use Concepts as their components.
The basic Diagram will be Conceptual Graph, which is a directed graph
with Concepts as its nodes.
The basic interface to the Diagram repository is connect(Concept c1,
Concept c2, Concept port) : connect Concept c1 to Concept c2 through
port port.
On this basis we can define any diagram we want.
Every Diagram as a whole is also definning a Concept.
For example: in out tool we should have the Concept of
CodeGenerationComponent,we obviously need a Diagram to state what is the
inner structure of this Concept, but if we define it as Concept we can
use it as a node in another Diagram and we also can check (with argo's
critics) if the Ports of the Concept are consistent with its inner
structure.

As a use case I want to show how we can generate a UML like diagrams:
We will have a Conceptual Graph Diagram for every concept in the UML.
Note that I am using Conceptual Graphs to define the ports of the
concept and also to connect other Concept to the ports.
If I don't state (via port XX) it means I am definning the Port

The Diagram definning the Inheritance Concept is :   subClass -->
Inheritance <-- superClass (we will use definePort interface)
The Diagram definning the Association Concept is :   associate1 -->
Association <-- associate2
Now we can use this Concepts in another Diagrams : Integer --> (via port
subClass) Inheritance (via port superClass) Number

Now we can comlicate things and go to do detailed design with our
Diagrams. lets say that Association is a general term for using a
specific interface. (lets say calling the method doIt() )
So we will define the CallingMethodDoIt Concept as : CallingMethodDoIt
--> concept1 (again use definePort)
define also : CallingMethodDoIt --> (via port subClass) Inheritance (via
port superClass) <-- Association
And then describe our detailed design as : concept2 --> (via port
CallingMethodDoIt) concept1
From this we can automatically generate the Diagram : concept2 --> (via
port associate1) Association (via port associate2) <-- concept1
Which is the generalization from Detailed design and thus enabling the
programmer to view its Diagrams in all sort of ways.
(In my detailed design exmaple I have tryied to show the advantages of
my approach to go beyond UML)

I think this should be enough to start with. I can also think about more
repositories (e.g. Domain repository which will use Diagrams as its
components and Project repository which will use Domains as its
components, etc.)

chen