[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: (FC-Devel) A troubling thought and some questions/suggestions


(I MAY BE writing all this because of lack of my knowledge about FREECASE as
I have joined late and have gone through only few of the archived mails and
discussions. If so, please forgive me.)

In so many months of development on FREECASE we might have done something
tangible. (I am writing this because I am not sure at what stage project
was/is when this discussion started) I remember that we had earlier also
decided to use whatever we could, from Argo.
All the questions of "which language to choose, what architecture, what
version control system etc..." must have been discussed earlier too. Are we
not starting the whole cycle of discussion again?

Please do not misunderstand my concern but I see here a disturbing FACT. The
whole project was going in one direction with one leader. When the leader
changed we are rethinking about everything: the architecture, the language,
the platform... Will we repeat the same cycle once again if the leader
changes once again(for some unavoidable reasons). Are we not being TOO

From the recent discussions I sense that we may need to PEN DOWN clearly
what we want to build. Something like: "We want to build a CASE TOOL which
supports UML as correctly as possible. This would allow user to have control
over various versions of design in the same way as a source control system.
etc..."  It would be good if we could come up with a FORMAL GOAL and AGREE

If we are going to be UML compliant, I think we need help from people
proficient in UML. We might also need to adopt a process for development.
And may be some methodology too.
The leader also needs to be able to distribute work AND FIX SOME DEADLINES
TOO. The work done for FREECASE may be done free of charge but the
responsibility and accountability has to be there. So there has to be a code
of conduct too. it may seem that my emphasis is on formalization of
everything but some degree of formalization is required if the project has
to reach somewhere and HAS TO BE PERSON INDEPENDENT WHICH IS very important
for a project of this nature where people are not being paid for the work
they are doing.

We have to have a system of reviews too. Where in everybody is free to give
comments, in addition to a committee which is primarily responsible for
carrying out the reviews and incorporating the review comments. The progress
monitoring and schedules is another thing that is required.

Support for NEW members is another area that needs focus. A person joining
this team should have access to some documents that can update him on the
history, design, current status, team structure and responsibilities,
Schedule etc.

Use of a particular language is one of the questions that need to be
answered. Coding will be done by people. When you assign the job to somebody
you have to make sure that the person has adequate knowledge of the language
else the task becomes formidable. Learning a language as well developing
something of importance in that language may prove to be costly in terms of
mistakes (BUGS). I believe a language in which the developer is comfortable
and which serves the purpose adequately should be chosen. We should list our
criterion (As: portability, Ability to prototype rapidly, availability,
support of OO features, quality of tools available (debuggers, profilers
,libraries etc.) and a list of languages that satisfy these criterion. We
should then choose a language which people are familiar with/are willing to

Such a table could be prepared to decide which language to choose:

	<Language ---> >
						C++ 	Java	Python	Smalltalk
Portability					++	+++	?		?
Free availability				+++	+++	?		?
Run time environment support

Written in standard C++ would make it portable enough (of course, though we
will have to compile it for every particular OS) but not as much as Java.
Besides, use of JAVA may not render it that slow. Together/J
 http://www.togetherj.com/) has been written in JAVA and the impression that

I have is that it is fast enough. (I have not tried this so I can not
guarantee that :-))
We may use Python or any other language too but the question is how many
people know those languages and systems.
There are other questions too. Interoperability of various CASE tools was
one of them. We should be able to import projects from other CASE tools too.
May be we need to provide an interface to import code from existing version
control systems and provide repository for the code too.

Vipul Kocher