[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kuml-devel
Subject:    Re: He made me an offer i could't refuse
From:       Gerard Flynn <gerard.flynn () free ! fr>
Date:       2000-09-25 21:52:11
[Download RAW message or body]

"Baak, E.J.M." wrote:

> Hi Guys,
>
> As Darius has pointed out so nicely, i have nothing better to do than
> writing large letters in english.
> So here's my first short one (well... short).
>
> I'll accept the offer.
>
> BUT
>
> as in a marriage (or whatever) remember that you have to give a lot and can
> take only a
> small bit if you want to succeed as a team.
> If one wants XML and the other wants CORBA, one of the two is about to
> become happy
> and the other is not (Yeez, i still don't know what i'm talking about).
>
> So, stop chatting about all kind of techniques and start thinking about what
> we really want.
> What are our goals.
> What do we want to reach.
> For whom are we writing this beauty app.
> What will be the OS.

    Linux/Unix but if it happens to work on other systems I won't consider it a
bug.


>
> Is it going to be KDE only or transparent/usable for GNome and what extra
> effort will that cost.

    The component library (see below) should be independent of both.

>
> Do we want to be extendible in future.
>

    Of course.

> Do we want our data to be exchangible with other modeling tools.
>

    Yes, as long as they use open, industry standard formats (XMI).


> What modeling tool are we going to use.
>

    I'd vote for Dia.  But we should try to switch to our own tool as soon as
possible.  Actually being able to do this might be a good goal for the first
iteration.


> Do we use sourceforge (Darius, i have peeked in it but i couldn't find KUml
> yet).
>

       OK by me.

    Here's my first stab at a requirements list.  Actually I have 2 separate
sets of requirements: one for a user app I'll call X and another for a
component library Y.  The question is can we codevelop these in such a way that
X uses Y to avoid duplication of effort ?  I know my requirements aren't very
detailed.  I'm not very qualified to write a detailed list because I have
limited experience with other UML tools.

UMLv1.3 refers to the UML version 1.3 specification document:
    ftp://ftp.omg.org/pub/docs/formal/00-03-01.pdf

END USER REQUIREMENTS:
        X is an end-user application which constitutes a general purpose UML
        modeling tool.

        -X shall furnish an easy to use and intuitive GUI for creating and
editing
        visual representations of UML models (diagrams).

        -X shall allow the saving and loading of models and their corresponding

        visualization elements.  Model state is saved in XMI files.

        -X will be usable for completely documenting a model while maintaining
        diagram readability.  This necessitates a highly flexible and user
        configurable mechanism for information hiding.

        -X shall support all diagram types defined by UMLv1.3.

        -X shall attempt to respect the notational guidelines defined in
UMLv1.3

        -X  shall permit the exportation of diagrams in various graphic formats

        (ps, eps, png, gif, etc.)

        -X shall provide a facility for optionally verifying the static and
dynamic
        semantics of models as defined in UMLv1.3.

        -X shall allow information sharing between diagrams. (For example when
a
        user adds a message to a colloboration diagram a corresponding method
may be
        created if it does not yet exist in the object's class.)

        -X shall permit code generation in C++.

        -X shall permit reverse engineering of C++ code.

        -X shall be integrated in a complete IDE (kdevelop).

        -X shall be integrated with KDE2.

        -X shall furnish remote access to shared persistent model repositories

DEVELOPER REQUIREMENTS:
        Y is a component library whose purpose is to support the use of UML
models
        in special purpose applications.

        -Y shall provide an API for creating and manipulating UML models.  This
API
        would preferably be standardized and would ideally be that presented in

        UMLv1.3.

        -Y shall provide an API for importing/exporting UML models from/to XMI
        streams.

        -Y shall provide a facility for optionally verifying the static and
dynamic
        semantics of models as defined in UMLv1.3.

        -Y shall not depend on graphic environments such as KDE or GNOME or
their
        libraries except for standalone XML libraries.

        Example of use of Y:

                Problem : Generate a working application domain specific
state-machine
                from a UML statechart diagram stored in an XMI file.

                Solution using Y:
                        The application calls functions to import data from the
XMI file.
                        The application traverses the model using the Y API and
generates
                        application specific objects which represent states and

                        transitions.

    Gerard

[prev in list] [next in list] [prev in thread] [next in thread]