Re: (FC-Devel) repository

[Andrey V Khavryutchenko <akhavr@compchem.kiev.ua>]

Hi, Chen! 

>>>>> "CO" == Chen Ofek writes:

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

My references are to UML Semantics v1.0.  I yet have to catch up with 
UML 1.1.

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

See UML Semantics v1.0, chapter 2,  ModelElement for the same class.

 CO> ID is simple. (something like name+namespace)

ibid, Element.Name

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

ibid, chapter 3, Relationship, Dependency 
ibid, chapter 6, Generalization, Association

 CO> We also need a Diagram repository (Diagram is not the graphical
 CO> definition of the design it is the model) Diagrams will use Concepts
 CO> as their components.  The basic Diagram will be Conceptual Graph,
 CO> which is a directed graph with Concepts as its nodes.  

ibid, chapter 2, ViewElement and the whole chapter 12.

 CO> The basic interface to the Diagram repository is connect(Concept c1,
 CO> Concept c2, Concept port) : connect Concept c1 to Concept c2 through
 CO> port port.  On this basis we can define any diagram we want.  Every
 CO> Diagram as a whole is also definning a Concept.  For example: in out
 CO> tool we should have the Concept of CodeGenerationComponent,we
 CO> obviously need a Diagram to state what is the inner structure of this
 CO> Concept, but if we define it as Concept we can use it as a node in
 CO> another Diagram and we also can check (with argo's critics) if the
 CO> Ports of the Concept are consistent with its inner structure.

Sorry, didn't understand this.  Aren't you mixing Metamodel (our domain)
with our tool CodeGenerationComponent.

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

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

What is the benefit with regards to UML way?

 CO> Now we can comlicate things and go to do detailed design with our
 CO> Diagrams. lets say that Association is a general term for using a
 CO> specific interface. (lets say calling the method doIt() ) So we will
 CO> define the CallingMethodDoIt Concept as : CallingMethodDoIt
 CO> --> concept1 (again use definePort)
 CO> define also : CallingMethodDoIt --> (via port subClass) Inheritance
 CO> (via port superClass) <-- Association 

This is not the inheritance.  This is the instantiation of the
association. 

 CO> And then describe our detailed design as : concept2 --> (via port
 CO> CallingMethodDoIt) concept1 From this we can automatically generate
 CO> the Diagram : concept2 --> (via port associate1) Association (via port
 CO> associate2) <-- concept1 Which is the generalization from Detailed
 CO> design and thus enabling the programmer to view its Diagrams in all
 CO> sort of ways.  (In my detailed design exmaple I have tryied to show
 CO> the advantages of my approach to go beyond UML)

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

Why so complex?  Just create one repository of Documents and let
ConceptGraph be just one of it.

-- 
SY, Andrey V Khavryutchenko	http://www.kbi.kiev.ua/~akhavr

Shick's Law:
	There is no problem a good miracle can't solve.