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

["Zsolt Koppany" <zk@intland.de>]

Hi,

could somebody remove me from this maillist please ?


Regards,

Zsolt Koppany

-----Ursprüngliche Nachricht-----
Von: Andrzej Mazurkiewicz <andrzej.mazurkiewicz@polkomtel.com.pl>
An: Chandresh Turakhia <chandji@yahoo.com>; 'kiwi' <kiwi@timaru.com>
Cc: freecase@freecase.seul.org <freecase@freecase.seul.org>;
freecase-devel@freecase.seul.org <freecase-devel@freecase.seul.org>
Datum: Dienstag, 15. Dezember 1998 12:22
Betreff: RE: (FC-Devel) Do not get Disheartened. We Can try to make a fresh
Start.


>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 !!!
>
>
>