[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (FC-Devel) core design + project steps
Hi folks,
especially welcome to those who could not participate, because
they have not hat the time...
Andrey V Khavryutchenko wrote:
>
> Hi, Chen!
>
> >>>>> "CO" == Chen Ofek writes:
>
> CO> Andrey V Khavryutchenko wrote:
>
> >> Hi, Chen! Hi, everybody!
> >>
> >> I've read the last month discussion on the list and have to say, that
> >> we're going into premature design :( Why I think so?
>
> CO> I have regarded last month discussion more as brain storming before we
> CO> sit and do an ordered definitions and design.
>
Of course we started somehow in a brainstorming manner. On problem is to
find
a common naming of the things, as I noticed in the discussion with Chen,
we
have concepts very close togehter, however, we are used to name it
different.
> Well, it migh be viewed that way too. Perhaps my perception is due reading
> the month worth discussion within few hours.
>
> >> We didn't yet decided what problem we're going to solve. We have no
> >> requirements document. We have no use cases.
>
I tried to start with a very simple use case: derive complex numbers
from
real numbers. This case is an example everybody knows, and it is so
simple,
that it is hard to simplify it further.
> Helping programmers is an enormous problem. And CASE tool won't do help
> much (at least in commercial area) because major problems are related to
> the project management (see Software CMM from SEI).
>
Case tools are real big problem in any project I know.
> Besides, will we produce something, if we even didn't agreed on what we're
> going to do?
>
> >> Sorry, Chen. I very appreciate your ideas, but I've seen lots of
> >> projects died from too deep diving into details just from the start.
>
> CO> I don't see how a free project can die when the discussion is
> CO> interesting :)
>
I would try to start with this simple use case. We will see the
beginning
of everything, we can see code generation, we can see if Java is
sufficient
for our purpose and we can decide to redesign everything.
> Too easy, unfortunately :( If you talk too long and do too little, very
> few will follow. Remember what was the boost of activity at Jun, when Jeff
> anounced the project? And where is it now?
>
The decision to buy a certain casetool lasts usually more than 3 months,
the
decision for the basic architecture (if we all have another job to do)
we needed
is not too much.
> 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.
>
I agree with concepts =~ patterns and port =~ roles?
> See UML Semantics v1.0, chapter 2, ModelElement for the same class.
>
> CO> ID is simple. (something like name+namespace)
>
Good to start at.
> 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.
I agree
>
> 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.
>
I agree. This way we can derive more complex diagrams from the simpler
ones.
> ...
> 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.
>
I cannot follow this detail.
>...
> 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.
>
I am going to be lost in details... So answering in general
One suggestion to the tools: everybody has some things she/he is
familiar
with( SGML, cvs, Corba, Java ...). Every single tool can be used for
a important part of the project. However, at the beginning we should
start VERY SIMPLE, perhaps with a Java application on a single file
system.
It should be a working demo with a very limited scope, ready in a few
weeks.
I prefer Java not, because I believe that it is the best choice,
however,
we have a fast turnaround for a quick (and a little bit) dirty first
impression.
Later we will decide to redesign each part with optimal components.
1. Then we should focus on a general code generator, the repository and
documentation. (perhaps SGML, perhaps cvs)
2. Lateron we can decide to distribute the application, perhaps using
Corba.
The Conceptual Graphs and UML seem to be a good common starting point...
If
we have simple example writing code onto the filesystem, we can connect
it to a better repository.
So I now would like to keep it simple...
Bye everybody,
Thomas
--
Thomas Fricke
SIEMENS AG, OEN TR SW PT
Fon: +49/30 386-36 344, Fax: -21928
Siemensdamm 62, D 13629 Berlin