[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (FC-Devel) Do not get Disheartened. We Can try to make a fresh Start.
could somebody remove me from this maillist please ?
Von: Andrzej Mazurkiewicz <email@example.com>
An: Chandresh Turakhia <firstname.lastname@example.org>; 'kiwi' <email@example.com>
Cc: firstname.lastname@example.org <email@example.com>;
Datum: Dienstag, 15. Dezember 1998 12:22
Betreff: RE: (FC-Devel) Do not get Disheartened. We Can try to make a fresh
>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
>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
>following list of such tools.
>standard object oriented 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
> - 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
> 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
>- 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
> 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
>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
>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).
>tel +48-22-6075492, +48-601-130888
>Na pohybel Microsoftowi !!!