Week 39 of 2009

This week I have been trying to finish off the OOA Dictionary. This should have been easy except for the fact that it made me think about a number of mapping issues. Obviously, that is the purpose of having a centralized multi-notation dictionary so it shouldn't have surprised me that this work would slip a bit. I completed most of the entries and a few of the issues raised are discussed below. The outstanding entries that I still need to finish off are the Operation and Simulation entries. Process Model, Action Language and Translation entries are light on the ground since the associated model elements don't exist yet.

The Information Model subsystem defines a multiple hierarchy for binary relationships. The first hierarchy defines simple, associative, composed and mathematically dependent relationships. The second defines loop independent and loop dependent relationships. A third implicit hierarchy defines competitive and non-competitive relationships, i.e. whether a relationship has an associated assigner model. Not all combinations make sense, e.g. composed relationships are always loop dependent. Some combinations make sense but aren't recommended, e.g. competitive simple relationships. The problem I had was to determine the best names to use for all legal combinations of these relationship types. I also redesigned some of the icons used here.

There are a number of changes that I need to make to the State Model subsystem: whether internal events are manually created or automatically determined (from Action Language code) needs to be configurable, I want to be able to control transition label formatting over multiple lines, a creation transition is needed so that there is something to select or delete in the STD editor, and it should be possible to associate multiple transition notes with a transition. However, I want to put this work off until the next build since there are a number of other related things that I need to finish off, e.g. the STT editor and the technical note defining state models. The main change I did make was to rename external entities in Executable UML notation from Actor to External Entity. The use of the term Actor here is similar to the use of the term Terminator in Shlaer-Mellor notation. More importantly, the term Actor is better used in the context of Use Cases which I discuss below.

I started on OOA work products then and one area of Executable UML that OOA Tool doesn't currently support is Use Cases since there is no equivalent in Shlaer-Mellor. I have used Use Cases on UML projects in the past as an alternative to writing traditional requirement specifications. If used correctly, they can help to identify the scope of a project and kick start the application domain. However, in my experience, they shouldn't be overused. The main Executable UML book [xtUML02] defines Use Cases very simply leaving out a lot of the more advanced features defined in UML Use Cases. Unfortunately, there are a few issues with how the basic features described in the book relate to the rest of Executable UML, e.g. how actors relate to external entities and interactions relate to external signals. I produced a simple information model for basic Use Cases and I plan to add it to the OOA of OOA as a new subsystem in the future. Two new diagrams will need to be supported: Use Case Diagrams and Use Case Activity Diagrams. I did have a think about whether to use Process Model notation for the Shlaer-Mellor equivalent of Use Case activity diagrams. However, I'm not sure anything would be gained since anyone defining use cases will expect to use UML notation to do so. Anyway, I'm not planning on implementing Use Cases until after the simulator is finished.

One of the tasks associated with the OOA Dictionary work was a facility to view the dictionary from within OOA Tool. I implemented a report view to do just that. However, images are always loaded from URLs in JEditorPane which gave me a headache since I don't want to extract the large number of icon image files out of the main OOA Tool Jar file. I eventually managed to work out how to create a custom ImageView that would load the icon images from the class path. This discovery should also allow me to clean up how Information Model Reports currently show graphical model images, i.e. the current design involves saving the image to a file and then referencing the file as a URL within the HTML report. This is a horrible design since no one expects a view operation to save a file in the background. This should only happen when the user wants to save the report as a HTML file. This change should also enable OOA Tool to be run as an applet within a web browser which I want to be able to do in the near future.

After testing what CSS styles are now supported in the Java SE 6 version of JEditorPane (so that I could format the OOA Dictionary within a report view), I decided to download the latest version of JDK 7 to see what future support there will be. The last build I downloaded was build 47 which I had no problems with. The latest early access build is 72. After I installed it I discovered OOA Tool wouldn't even build due to numerous inferred type errors. It pretty much ruined the rest of my day since I had to change numerous bits of code where Generic types were mixed with raw types. These errors aren't even warnings in previous JDK versions! JDK 7 now applies stricter mandatory rules which I'm sure will effect other people as well. I also had to download the latest version of Ant (version 1.7.1) to get my build scripts to work. After finally getting OOA Tool to build and run, I discovered that JDK 7 does have better support for CSS styles which was a bit of good news after a day of pain.

So next week, I have a few more dictionary entries to complete and then I can get back to doing something else - exactly what has not been decided yet!

Week 38 of 2009

I started this week by finishing off the view factory logic I mentioned last week. I discovered that Java reflection and generics don't mix well! The old factory logic used reflection to create a view using a standard constructor. However, I had to change all the view constructors to reference their model elements generically. Unfortunately, you don't seem to be able to create the generic parameters that are required to invoke the constructors using reflection. I've probably just missed something really simple! Anyway, I decided to implement the factory longhand using a big switch statement. A big advantage of this approach is that the compiler can check the constructors exist at compile time. The only disadvantage is the big and ugly switch statement.

The next thing I did was a total sidetrack but a useful improvement. I've extracted all notation specific object/role names from model elements into an OOA Dictionary. The dictionary provides the Shlaer-Mellor, Executable UML (xtUML) and Executable UML2 (xtUML + UML2) names and icons for all object/role names. The OOA Dictionary webpage just referenced is automatically generated from OOA Tool rather than manually maintained. This means that each future build will allow the user to browse the dictionary that is specific to that build since these names (and icons) are still evolving. I've also added the dictionary as a resource to the main website. However, this will always contain the latest version of the dictionary which may differ from that used in any given OOA Tool build.

A very interesting possibility now that I have a notation switchable dictionary within OOA Tool is that I could use it to convert any OOA of OOA within OOA Tool to use Executable UML terminology. I will need to extend the dictionary to include attribute names, verb phrases and role names. However, the vast majority of these either overlap the object/role names or won't need to be changed. Diagrams do need to be scaled after these conversions. However, I could determine appropriate defaults so that completely changing notation on a loaded metamodel is a one click action.

An even more interesting possibility is that I will be able to generate Executable UML metamodel populations so that archetype templates can reference Executable UML classes and attributes rather than Shlaer-Mellor objects and attributes. For example, the following simple archetype template which generates a list of qualified object names:

.select many objects from instances of Object
.for each object in objects
.select one domain related by \
    object->Information_Model->Domain
Object: ${domain.Name}.${object.Name}
.end for
.emit to file "ObjectList.txt"

could alternatively be coded as:

.select many classes from instances of Class
.for each class in classes
.select one domain related by \
    class->PlatformIndependentModel->Domain
Class: ${domain.name}.${class.name}
.end for
.emit to file "ClassList.txt"

OK, so what's next. I need to finish the OOA Dictionary webpage generator and ensure that all views reference the dictionary rather than hardcode notation specific labels. I also need to add a menu item (on the Help menu) for viewing a build specific dictionary within OOA Tool. After that I'm not sure since my To Do List is way too big and I seem to be picking items at random at the moment! I would like to hear from people with regards to what UML/UML2 names I should be using within the OOA Dictionary since I wouldn't claim to be an expert on UML terminology since it keeps changing!

Week 37 of 2009

Java SE 6 executable Jar files don't seem to be limited to 64M on Vista x64 which means that running OOA Tool by clicking the Jar is probably better in the next release than running the Batch or Shell scripts that I also include in releases since event logging is now captured and viewable within OOA Tool. After some checking via Google, I discovered that executable Jar files can be executed with any JVM options by altering the following registry entry on Windows:

HKEY_CLASSES_ROOT\jarfile\shell\open\command

The current value on my machine is:

"C:\Program Files\Java\jre6\bin\javaw.exe" -jar "%1" %*

Changing this to the following increases maximum memory to 256M:

"C:\Program Files\Java\jre6\bin\javaw.exe" -Xmx256M -jar "%1" %*

However, this step doesn't seem to be necessary on Vista x64 since OOA Tool starts up with 903M by default on my machine! I'm not sure what you need to change to do the same thing on a Mac or under Unix.

My JBuilder 2005 IDE finally seems to be having problems building OOA Tool by itself. I have already had to work around some nasty JBuilder bugs, e.g. you can't break or continue directly out of a nested loop since JBuilder generates some shit bytecode that doesn't work. Note that all releases are built using an Ant build file and the latest JDK so these problems only effect me since I want to be able to instrument and step thru code using the JBuilder debugger. The latest problem seems to be related to too much complexity involving Java Generics. The JDK builds all of my stuff without a single warning (although I do have to use a few @SuppressWarnings("unchecked") directives). I can even build my stuff using JBuilder itself if I build all packages bar one first and then build the last package afterwards!

I have considered upgrading JBuilder to the latest version except they have moved JBuilder onto the Eclipse platform which means I will have to learn the Eclipse IDE to use it. If I'm going to learn Eclipse I don't see what additional benefits I would get from buying JBuilder since I'm not currently a Java Enterprise user. I also don't use JBuilder's GUI builder. If Embarcadero Technologies wants users like me to move to the latest version then they need to make the Professional version of the tool cheaper or they need to provide a Foundation version for free like they did in the past.

I mentioned Vista for the first time at the beginning of this blog because I have recently bought a new laptop (my old laptop kept overheating and shutting down). It's the first machine I have had with Vista, previous machines have all been running XP instead. It's also the first 64 bit machine I have had so I can now see how well Java x64 runs. There doesn't seem to be any problems running OOA Tool. A screenshot from my laptop is shown below:

From the screenshot, you can see that load times are longer in the latest build. This is a consequence of a safer model element design and the fact that I haven't spent any time optimizing load times yet. Most users will not need to load more than one project on startup so load times should not be more than a few seconds anyway.

One big drawback with Vista is that I can't get JBuilder 2005 to even install never mind run. I've tried copying the installed directory over from my desktop machine (as recommended by other developers in my position) but it still doesn't run. It looks like I will have to move to Eclipse once my desktop machine packs in.

OK, so what have I been doing other than messing with Vista and JBuilder this week? I have spent most of the week refactoring an application wide factory into OOA Tool. The existing design included two types of factory: model element factory methods which are defined on parent model elements (e.g. OOAObject class defines a createAttribute() method), and editor view factory methods which create an appropriate form/diagram/table/report view for a given model element. To debug OOA Tool I often have to tweek methods in various model elements to determine what's happening. I also have to add workarounds for backwards compatility. However, I really want to be able to subclass model elements when debugging and move any backwards compatibility code out of the main model element classes into subclasses. To do this with the current design requires subclassing at several levels, e.g. to create a new Attribute subclass we need to create new OOAObject, InformationModel, Domain and Project classes since creation is delegated at each level.

The solution on the model element side was to add a factory reference to all model elements. Root elements are passed a factory but have no parent. Non-root elements are passed a parent and optionally passed a factory. If no factory is given then a non-root element uses the factory of the parent. I also wanted to statically scope factories using Generics so the new signature of the ModelElement class is given below along with a brief outline of OOAObject:

public interface ModelElementFactory { }

public abstract class ModelElement<F extends ModelElementFactory,
                                   P extends ModelElement<F, ?> {
    private F m_factory;

    protected ModelElement(P parent, F factory, boolean deleted) {
        if (factory == null) {
            throw new NullPointerException("Factory required");
        }
        // ...
    }

    protected ModelElement(F factory) { // Root element constructor
        this(null, factory, false);
    }

    protected ModelElement(P parent) { // Non-root constructor
        this(parent, (parent != null) ? parent.getFactory() : null,
             true);
    }

    public final F getFactory() {
        return m_factory;
    }
}

public interface OOAFactory extends ModelElementFactory {
    public Attribute createAttribute(OOAObject parent);
}

public class OOAObject<F extends OOAFactory>
        extends ModelElement<F, InformationModel<F>> {
    public OOAObject(InformationModel<F> parent) {
        super(parent);
    }

    public Attribute createAttribute() {
        return getFactory().createAttribute(this);
    }
}

I'll leave this weeks report there since we seem to be getting a little bit technical with all this Java coding! Hopefully, I'll have more modelling specific stuff to report next week.

Week 36 of 2009

A few distractions derailed this week's activities since they gave me some thinking time and I came up with a few new ideas! The main one being to merge in some Swing components that I developed just prior to starting this project. These components included: a console and I/O library for interactive console-like editor panes, an enhanced event logger (mostly internal benefits), and a status bar panel. I have now added a consoles tabbed pane at the bottom of OOA Tool and a status bar panel right on the bottom edge.

The consoles tabbed pane will always contain a System Log of colour-coded events which were previously sent to standard output. The System Log is highly configurable with many filtering and formatting options. It also allows logs to be saved as XML files. You will also be able to create command consoles for interacting with operating system specific shell environments. Simulation and translation logs will also appear here in the future.

The status bar includes a message area, a locale indicator (language only) and a clock. The main user of the status bar at present is the model element browser which displays the currently selected element in the status bar. Since the browser is normally given very little width, many elements will not be entirely visible in the browser. The status bar provides an easy way to see longer elements, i.e. just select the element. Both screenshots below demonstrate this.

The following screenshot shows OOA Tool (using the Java SE 6 Nimbus look and feel) after the Object.Prominent attribute has been changed (notice the pencil on the attribute's icon):

The following screenshot shows log messages at different levels in different colours (demonstrating some current BP loading problems!):

This new distraction has left a few loose ends to resolve. I need to do a sweep thru the code base ensuring that only the new event logger is used. I need to add a new View menu to the menu bar allowing some control over which panes are visible beyond the split pane controls. I also need to check the new components don't have any problems using the Nimbus look and feel. An ability to select locale will also be added.

I also need to think about resource bundle usage (for multiple language support) within OOA Tool since the new components already ultilize them. The main problem here if we want to fully support other languages is that Shlaer-Mellor and Executable UML names are very carefully thought out and controlled, more so than normal user interface titles and messages. Does anyone out there have any views with regard to additional language support? What do French, German, Russian, Japanese, Chinese etc. modellers want to see - English or their own language? Are there any UML tools out there that convert the UML metamodel into non-English for non-English users?