RE: (FC-Devel) Do not get Disheartened. We Can try to make a fresh Start.

[Andrzej Mazurkiewicz <andrzej.mazurkiewicz@polkomtel.com.pl>]

Hi everybody,
I have learnt about your project a couple of days ago. I do not have too
much information so perhaps you will not agree with me. 

1. I am personally interested in free CASE and I have planned to prepare
such kind of tool. I think I have a reasonable experience working with CASE
tools (Oracle, System Architect, LBMS).

2. Lately I have read some materials about UML. As far as I have noticed you
plan to be as UML correct as possible. Personally I am disappointed with
UML. Of cource it uses a buzzword "Object orientation". But it does not
provide certain elementary tools needed for development. I would prepare the
following list of such tools.
standard object oriented diagram 
state-transition diagram
requirements tracking (at later stage)
requirements association with CASE objects (at later stage).

Features of the tools.
- standard object oriented diagram:
	- data attributes, services/methods visible on object/class symbol,
	- messages, subjects visiblew on the diagram,
	- differentiation of key and non-key data (in a meaning of Entity
Relationship Diagram - I have found it in no CASE object diagram  !!!) on
Object/Class Symbol,
	- differentiation of one-to-one, one-to-many, many-to-many relations
using crows foot (easier visible than with numbers),
	- differentiation of inheritance (commonly used),
	- balancing of message data elements/attributes with
minispecification of service and Object/Class data elements/attributes (ref.
to System 
			ArchitectCASE process minispecification balancing
and dataflow with datastore balancing),
	- generation of Entity-Relationship Diagram (???)
	- generation of Data Flow Diagram (???)
	- generation of inherited keys for data (ref to Entity Relationship
Diagrams)
- state transition diagram
	- association of triggering events with messages,

- assigning of decomposition hierarchy: class/object --->
State-Transition-Diagram (useful for oject life cycle, switching systems,
message processing etc).
			 class/object ---> Class/Object diagram (I have not
used it yet but I see that I could do it for certain decomposition of a
system)
			state ---> state transition diagram
			state ---> Class/Object

3. My personal opinion is that all above objects should be stored in a
DATABASE. This solution is used by Oracle as well as System Architect (a
specialized db). I think that a reasonable choice of free database is
Postgres, which has reached a minimal necessary maturity level.
The other question is a user interface. One can be simply alphanumeric for
screen form data input. The other, graphical one, would be necessary for
diagrams.

4. And the question C++ or Java is valid only for graphical interface and
strictly speaking it is not clear whether it makes sense now. What has to be
done in the nearest future is some king of prototyping. An interpreter with
interpreting environment, debugging environment is the easiest solution.
That language should support graphics environment as well. In my opinion a
reasonable solution might also be tcl/tk since it has an interface to
postgress as well. As soon as something working has been got it can be
transfered to C++, Java or whatever.
Perhaps my last opinion is because of my experience (I do not have a lot of
experience with C++, and almost none with Java).
Andrzej Mazurkiewicz

tel +48-22-6075492, +48-601-130888

Na pohybel Microsoftowi !!!