View this PageEdit this Page (locked)Attachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Michael Langford's UML Tool to Replace BOOST

I started to design and build a UML tool to replace the often buggy/unpretty BOOST. It is only for class diagramming at this time, however that is the main usage of UML in this class. Realistically, the way people use BOOST is that they have already thought out their design, and then they just want a nice presentation for it. My design is currently only set up to operate by typing in smalltalk code.
Here is my design:

Uploaded Image: ec3_langford.gif



Many of the following classes do have run of the mill accessors and modifiers in addition to the shown methods. Any confilcts with the diagram should accept the descriptions below as the authority.

Descriptions of the classes



CDSystem


Idea: This is the class that models a subsystem in the diagram. This is useful for not showing some parts of the design at times, as it can be collapsed. Example use: You have written a equation formatting set of classes then you add to that a squeak GUI, the capability to parse laTeX, and then, a webUI. You may not want to show all of the squeak UI classes when you are printing the WebUI, so you might add all of the squeak UI to a subsytem then collape it for ease of display


Attributes:
classes-
collection of all the classes that are in the subsystem
isCollapsed-
This is a boolean that tells whether the subsytem is supposed to be collapsed at this time.

Messages:
addClass:-
Adds a class to the subsystem
removeClass:-
Removes a class from the subsystem
collapsed-
tells whether a subsystem is collapsed
collapsed:-
sets a subsystem to be collapsed or not
form-
returns an icon on a form for the collapsed subsystem.
classes-
returns all of the classes in the subsystem



CDClass


Idea: This a representation of a class for UML class diagramming.

Attributes:
attributes-
list of all attributes that the clas is to have. Later attributes become objects. But text at first for simplicity
messages-
list of all messages that the class will have. Same situation as attributes.
relationships-
all of the relationships that a class has with other classes

Messages:
addAttribute:-
adds an attribute
addMessage:-
adds a message
removeMessage:-
removes a message
removeAttribute:-
removes an attribute
addRelationship:-
adds a relationship
removeRelationship:-
removes a relationship
relationships-
returns all of the relationships
messages-
returns all of the messages
attributes-
returns all of the attributes
form-
returns a form representation of the class

CDRelationship


Idea: Models class relationships(inheritance and composition)

Attributes:
NONE

Messages:
unlink-
removes a linkage between two classes
form-
returns a form that has the conection between the two classes


CDInheritance


Idea: models an isA relationship

Attributes:
parent-
parent class
child-
child class

Messages:
parent:child:-
returns a new inheritance relationship



CDComposition


Idea: models a composition relationship where both classes ahve a reference to one another.

Attributes:
class1-
class2-
these are the two classes in the relationship.

Messages:
link:and:-
makes a new composition relationship
classes-
returns a collection of the classes in the relationship
replace:with:-
removes the class matching replace: and sets it equal to with:


CDHasA


Idea:models a composition relationship that is a one way reference.

Attributes:
whole-
the class that has the reference
part-
the referred to part
isWholePart-
is this a case of aggregation?? is so, this will display differently

Messages:
class:hasA:-
returns a new CDHasA relationship where the first argument would have a reference to the second.


How do you use it?


You start to make a your classes, then you make the relationships between them. Add all of the classes to a system, call form on that subsystem, and Voila, you will get a form of the entire system, layed out with a minimum of line overlap, proximity of classes in a subsystem and no occlution of lines or imporant symbols. Any subsystem that is collapsed will instead be represented as a small icon about the size of a class.


GUIfication


To contruct a GUI to go with this, I will make use of morphs called pins and wires to connect the classes, which will be decendents of RecatngleMorph or another morph that already has text support. These can be seen on play with me 6 in the graphically programmable browser. I will probbably extend them to make them so they do not occlude each other.


Other cases of expansion


I am also planing to make the subsytem have some mechanism to show what is the interface(s) between it and the outside world. This is rather unimportant at the time however, and is being pushed to apfter the fist implementation stage is done.





Michael Langford

Links to this Page