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!
2 comments:
I personally would suggest that if you want to handle requirements within the model then do it with a proper requirements model a la SysML style. Then you would be able to support requirements traceability to the SM model.
However, so long as you can this later then I would see it as a lower priority objective for now.
Regards
Dave B.
I'm not currently trying to capture requirements or demonstrate traceability to the analysis model. Use cases can be useful when analysing interaction driven applications as opposed to data, behaviour or function driven applications. I don't believe every domain would benefit from a use case model but some certainly would.
Furthermore, I want to make it possible for third-parties to sell their reusable domains openly. Use cases can be used to help specify the public interface to a domain. In this situation they may be produced after the domain has been completed or during the process of testing.
Post a Comment