Sean Chen wrote:
> Hi Robert,
>
> Thanks for your clarification. It seems like you'll be building a library
> around which modelling tools can be built, correct? In essence, the
> metamodel.
Hmm, I dont know if that is the case. there will be functionality for
manipulation of the model, its just that the manipulation takes a much more
programmatic approach and not such a drawing approach. Say for example that
you want to create a dependency association between class foo and class bar.
In a drawing tool with UML functionality, you would create this by physically
drawing a line. This approach has about a bullion problems, not least of
which is ambiguity about the nature of the association. With jump you will
create the association by clicking on a tool or UML menu item and choosing
association. Then a list would pop enumerating all the classifiers you have
for you to choose a source, destination, link class, and other values for the
association. The model diagram will then reflect your association by adding
the relavent classes to the diagram and drawing the assocation. Unlinking the
assocation throu simple drag and drop into midair would be impossible,
eliminating dangling associations. If oyu want to change its target, you can
double click on the association and reset the source or destination or even
remove the association. The classifiers themselves are stored in an entirely
separate part of the the model from the diagram. This enables you to create
multiple diagrams containing a classifier and change all of them by changing
the root classifier. On some diagrams the classifier my just display its
name, on others, it would be fully displayed. This allows a developer to
create segmented models where he reuses the classifiers. As for the XMI spec.
I frankly havent done alot with it. Im a pure UML guy and a devout believer
in the KISS philosophy. (Keep it Simple Stupid) One of the reasons many
developers dont use UML is because academic type people throw all sorts of
theories and specifications of specifications of specifications because they
want to have something to do. This confuses the developer that simply wants
to model his software so he gets scared and uses some drawing tool rather
then mess with the complexitites of rational rose type software.
Further there are two other principles guiding me. One is the concept of a
general public license. Universities have a history of putting out free
software til it becomes a viable product then selling that product. Or
releasing versions of software that are free to educational use but cost for
commercial development. I am releasing this under GPL and plan to solicit the
support of the GNU organization when I have a real working release.
The second principle is one of extensibility. I am actively terminating
complexity in the code. I am doing full javadoc commenting. I am actively
working to the point where a user will be able to say "dangit, I want to add
an Ada code generation module" and can do it without spending 6 months
studying my code. Through cursory examination of Argo, I think 9 months is a
tad more accurate. I plan to release a developers guide with the product. In
fact Im planning that the sample model included with the program will be the
full Jump model of Jump itself. I want all those thousands of programmers to
expand this just like emacs went crazy until it became the killer product it
is today. Sure, this means that things are highly compartmentalized. Thats a
good thing. The model itself is a self contained mechanism. Probably someonw
could use some of the classes in another program. What it doesnt mean is that
you need 300 class files just to represent the model. That is superfluous and
rediculous. Professional software engineering differes from theory in that we
dont have the luxury of government grants to give us all the time we need. We
need to be able to design and implement code vary rapidly, not explire the
theory of hashtable sort algorithms. users of this tool will be able to
generate an expansion to the tool very rapidly, reducing man-hour
expenditure.
--rob
>
>
> FYI, there are some other efforts in this area:
> http://141.76.120.111/UMLToolset/ is the Dresden UML Toolset, they
> generate Java classes out of the XMI specs.
> Another is recently introduced at http://novosoft.nsc.ru/~const/uml/
>
> What do you think of these in relation to your work?
>
> . . . Sean.
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
