OOA Tool
is a Shlaer-Mellor OOA/RD CASE tool with Executable UML support implemented in 100% pure Java™
which includes a model editor and will include a simulator and translator.
It is currently being developed in parallel with OOA10.
Once development finishes, a Professional edition will be released at a competitive price,
while a Standard edition will be distributed at no cost indefinitely.
In the meantime, an early access Beta release is available for download.
This Read Me is for the OOA Tool Beta Build 014 release.
Requirements
The only requirement to run OOA Tool is that a Java Runtime Environment (JRE) exists on your machine.
OOA Tool requires Java SE 6 or later.
It no longer runs on J2SE 5.0
since that platform is no longer supported.
Licensing
This early access Beta release is distributed with a free software LICENSE.
The source code for OOA Tool is not included in the distribution, i.e. this is not an open source project.
Future Standard editions of OOA Tool will also be distributed with this free software license.
Future Professional editions of OOA Tool will be distributed with a different commercial software license.
How To Install
To install OOA Tool, unzip the release into your chosen ${PROGRAM_FILES} directory.
To uninstall OOA Tool,
simply delete the ${PROGRAM_FILES}/KavanaghConsultancy/OOATool directory.
On Windows, OOA Tool uses the registry to store various user preferences under:
My Computer\HKEY_CURRENT_USER\Software\JavaSoft\Prefs\com\ooatool
These settings can be deleted at any time using the Windows regedit tool.
They can also (since Build 009) be deleted by selecting Delete Saved Preferences
from the Preferences menu on the menu bar.
How To Run
To run OOA Tool, simply run:
OOATool.bat or OOAToolW.bat (no console window) on Windows,
OOATool.sh on Unix,
or OOATool.jar on any Java platform.
All of the above should be run from the
${PROGRAM_FILES}/KavanaghConsultancy/OOATool/bin directory.
If your standard Java platform is older than Java SE 6 then you will need to change the batch files or shell script
to reference a Java SE 6 or later java program.
You can determine what your standard Java platform is by executing the command
java -version on the command line.
On Windows you run the cmd tool to access the command line.
If you are working with very large models and need more memory
then you may need to change the batch files or shell script to specify a larger maximum memory, e.g. by adding
-Xmx256M (for 256 M) to the java command line.
You can determine what memory is being used within OOA Tool
by selecting About OOA Tool... from the Help menu on the menu bar.
Documentation
There is no user manual at present but OOA Tool is fairly intuitive to use.
We recommend new Shlaer-Mellor users buy [OOA88],
[OOA91]
and [Starr96].
OOA91 is by far the most important book to buy.
All three books can be purchased at Amazon.
The facsimile edition of OOA91 can also be purchased in the UK at Tesco
using the following link: OOA91.
However, if you are only going to use Executable UML notation in OOA Tool then we recommend users buy
[xtUML02]
and [Starr02] instead.
OOA Tool is distributed with a number of OOA and UML models which have been used to test the tool.
You can use these models to explore the capabilities of the tool.
This OOA model captures the complete information model for "Management of Magnetic Tapes"
given in [00A88] Appendix A.
The only significant difference between the captured model and the book
is the formalization of R11 which originally used informal conditional logic.
This has been replaced with formal unconditional logic
using an [OOA91] composed relationship,
i.e. R11 has been split into R11
and R17 = R5 + R1 + R6 within the captured model.
The associated OOA work products generated from OOA Tool are listed below:
This Executable UML (xtUML) model captures the platform-independent model and state machines for "Elevator"
given in [Starr01].
However, the class and attribute descriptions have not been copied from the book.
This model is not currently executable since OOA Tool doesn't include a simulator yet.
We are hoping it will be executable before OOA Tool Standard is released.
The associated UML work products generated from OOA Tool are listed below:
This OOA model captures the metamodel or "OOA of OOA" for
Mentor Graphics BridgePoint® 4.2 CASE tool
based on [BPAL97]
and [BPAuto99].
It also defines the syntax and lexical rules for BridgePoint's action language and archetype language.
This model has been used as the basis for the BridgePoint loading mechanism used in OOA Tool.
The associated OOA work products generated from OOA Tool are listed below:
This OOA model captures the OOA of OOA for OOA Tool
along with the additional information models necessary to formalize the
OOA Interchange Format
specified in OOA10.
It also defines the syntax and lexical rules for OOA Tool's
Pattern Language.
This model is currently very much under development.
Some subsystems are nearly complete, e.g. the Information Model and State Model subsystems,
while others are just scratch pads at present, e.g. the Process Model and Action Language subsystems.
The associated OOA work products generated from OOA Tool are listed below:
The Information Model Report archetype template listed above is only for test purposes at present.
It is not used to generate the information model reports within OOA Tool.
There are a number of issues which need to be resolved before it can be used for that purpose,
e.g. the archetype needs to be able to generate the graphical model included within an information model report.
This OOA model is version 0.01 of the official OOA of OOA
for OOA10.
Online Bookstore
This Executable UML (xtUML) model is the case study given in
[xtUML02] Appendix B.
It is contained in a BridgePoint 6.1D export file which was downloaded from
Executable UML.
Since the model can be loaded into OOA Tool without any significant loss of information,
it is clear that Excutable UML has not moved far from its Shlaer-Mellor origins.
Elevator 2
This Executable UML (xtUML) model is Leon Starr's revised Elevator model
(the original was given in [Starr01]).
It is contained in a BridgePoint 6.1D export file which was downloaded from
Model Integration :: Download.
For updates, you should check Leon's website.
Note that, OOA Tool now loads BridgePoint 6.x ".bak" and ".sql" export files
and BridgePoint 7.0 ".xtuml" export files (all of which can be found on Leon's website!).
This Executable UML2 model captures the Abstract Syntax for the Executable UML Foundation (fUML)
given in fUML08 Clause 7
(sections are called clauses in this specification).
It will be used later as the basis for providing fUML simulation support.
The captured model differs from the UML2 model given in the reference since Executable UML2 is a subset of UML2.
A summary of the differences which affect the captured model are listed below:
A subject matter domain package can only be decomposed into a single layer of subsystem packages
and each package is represented by a single class diagram.
They can't be decomposed into arbitrary nested packages with arbitrary class diagrams.
Thus, the captured model only has a single class diagram for Kernel etc.
Classes are abstract if (and only if) they are superclasses.
Attributes can't have multiplicities greater than one.
This only happens twice in fUML,
i.e. in OpaqueBahavior attributes body and opaqueBehavior.
Visibility is not specified on attributes or association ends.
All relationships are uniquely labelled.
No relationship is shown on more than one class diagram.
Compositions and aggregations are not supported.
Directed associations are not supported.
Association ends can't have arbitrary multiplicities,
e.g. 2..* is replaced by 1..*.
Derived associations are always derived at both ends and are shown with a slash
preceding their relationship label rather than a slash preceding their role names.
Generalizations are always disjoint and complete.
The captured model actually breaks this rule for StructuralFeature, Parameter
and Pin.
However, this rule break would need to be fixed before the captured model could be used for real.
The full scope of a generalization is always shown on a single class diagram
and not split across multiple class diagrams.
This follows on from the rule that no relationship is shown on more than one class diagram.
Enumerations are not show as classes on class diagrams.
The associated UML work products generated from OOA Tool are listed below:
The graphical model within an information model report is now scaled down to fit within a page
and a link has been added to view the unscaled graphical model.
Dropped all Java SE 6 dependencies so that OOA Tool can be run on a Mac platform
which only supports J2SE 5.0 at present.
Adopted UpperCamelCase naming convention within OOA XML.
However, the OOA parser has been made case insensitive for the moment.
Composed relationships are now fully implemented, e.g. R17 in OOA88AppendixA model.
Finished first pass of OOA of OOA domain within OOATool project.
As a result, numerous small changes have been made to bring OOATool in sync with OOA of OOA.
Created BridgePoint OOA of OOA and captured Elevator model.
Optimized diagram repainting.
Revamped diagram package, adding support for configurable fonts, multi-line labels,
better layout, etc.
Added pattern matching mechanism based on new Pattern Language.
SymbolicType can now be associated with a pattern taken from a pattern file
attached to the domain.
All diagrams now automatically update when underlying OOA objects change.
This fixed a major bug in previous builds that could result in corrupt diagram data
being saved in an OOA file requiring manual fixing of the XML!
All diagram buttons now work correctly.
Users can now add temporary imported objects to object information models
so that relationships can be more easily created.
However, temporary imported objects are not recorded when a model is saved.
Added "Work Products" node to tree browser giving quick access to all diagrams.
State models are now fully implemented, including polymorphic events as defined in OOA96.
The Subsystem Communication Model (SCM), Object Communication Model (OCM)
and State Transition Diagram (STD) have now been implemented.
While the State Transition Table (STT) has been partially implemented.
Terminators have been implemented even though they were removed in OOA96.
OOA Tool project includes a significantly revised OOA of OOA.
Fixed problem where diagram element labels get out of sync with model elements
after they are renumbered.
The problem resulted in link waypoints being lost when model reloaded.
Added "Renumber All Objects And Relationships" action to information model menu.
Saving pattern or archetype files also saves a HTML formatted version
with a ".html" suffix added.
Simple attributes may have an associated initial value.
If this value is final then the simple attribute is a literal value attribute.
Such attributes may be used to complete the mapping of a polymorphic attribute.
Mathematically dependent attributes may have an associated initial value.
However, the semantics of such a value have not been finalized yet.
Referential attributes must now resolve to a single base attribute.
This was not an explicit requirement in OOA91 or OOA96.
It is a requirement in OOA10.
Analysts might think that using the same data type for equivalent base attributes was sufficient.
However, this results in incomplete identification of relationships.
Referential loops are ignored during resolution of base attributes
as long as at least one path to a base attribute can be determined.
Referential attributes can be associated with an explicit manual data type
ensuring an error will be flagged if the resolved base attribute's data type is incompatible.
Referential attributes can also have a final value
indicating that the referential attribute is actually a referential constraint,
e.g. Associative Participant.Associative Role is a referential constaint.
Polymorphic attributes are now fully implemented.
Polymorphic attributes are essentially mathematically dependent attributes
which return a value dependent on which subtype object is associated
with the supertype object containing the polymorphic attribute.
Polymorphic attributes are required in some situations to ensure all referential attributes
can resolve to a single base attribute,
e.g. Entity.Information Model needs to be polymorphic
otherwise any references to Object.Information Model
or Terminator.Information Model would fail to resolve to a single base attribute.
However, since subtype-supertype relationships are always complete when defined
unlike inheritance associations, analysts do not need to use polymorphic attributes in all cases,
e.g. Attribute.Attribute Category is not currently defined as polymorphic
but it could be.
Attributes have an associated conditionality
indicating whether they always have an associated value.
All attributes can be made conditional by setting manual conditional status.
Referential attributes will also be conditional if their associated base attribute is conditional
or if all navigation paths to the base attribute are conditional.
Polymorphic attributes will also be conditional if any associated true attribute is conditional.
Conditional attributes are shown with a "(1c)" suffix in the tree browser.
Formalized attribute conditionality is new to OOA10.
However, Executable UML defines attribute conditionality using a multiplicity of "0..1".
Associative participants now have conditionality allowing an analyst to specify
that an associative object can exist independently of the associative relationship.
It is required to determine navigation conditionality across associative relationships.
This capability is new to OOA10.
All uniqueness tests involving names and key letters are now case insensitive,
e.g. you can't define the objects "Cat" and "CAT" in the same information model.
Automated entity (object and terminator) key lettering using first letter of each word in name
while allowing user to specify custom letters if required.
All entities are now required to have unique key letters.
Subsystem prefix letters if defined always prefix assigned object key letters.
Only custom letters are stored in OOA files now.
Automated object and relationship numbering using ordering within information model
or ordering within subsystem offset by subsystem lowest number
while allowing user to specify manual number if required.
All objects and relationships are now numbered.
Manual numbers may be specified outside of subsystem number ranges
but these will be shown in orange as a warning.
Only manual numbers are stored in OOA files now.
Tree browser labels are now colour coded.
Derived information is shown in grey.
References are shown in blue.
Warnings are indicated by showing part of a label in orange.
Errors are indicated by showing part of a label in red.
Overridden values are shown in red with a line thru them, followed by overriding values in grey.
Prominent objects are shown in bold.
Literal labels or literal value attributes are shown in italics.
Comments are shown in green.
Fixed tree browser so that when model elements are added
the browser doesn't close previously opened tree nodes.
Added drag and drop mechanism to tree browser allowing ordered elements to be reordered.
Added tab selection history so that the previously selected tab is reselected
when a tab is closed.
Added look and feel menu to preferences menu on the menu bar.
This allows users to switch between Metal, CDE/Motif, native and Liquid/Mac look and feels.
The Liquid/Mac look and feel which works on Windows is courtesy of Miroslav Lazarevic and
Erik Vickroy (see liquidlnf: Project Home Page).
Domain, Subsystem and Object shapes now reduce visible content if there is not enough room.
Domain shapes only show subsystems and/or prominent objects if enough room.
Subsystem shapes only show prominent objects if enough room.
Object shapes only show attributes if enough room.
Preferences for Beta releases are now build specific.
Fixed bug causing internal and external events to be deleted when a model is loaded.
The Elevator model has also be fixed up after being damaged by this bug.
OOA files now always contain a project rather than a project or information model.
OOA Interchange Format DTD updated and fixed.
DTD renamed from ooafile0.1.dtd to OOAInterchangeFormat0.01.dtd.
All models distributed with OOA Tool now include embedded DTD and have been fully validated.
Fixed numerous issues with XML being generated.
XML element and attribute names are now closely aligned with OOA of OOA object and attribute names.
All changes to OOA Interchange Format will be tracked from now on.
First and second participants are now associated with the verb phrase
in which they are the source participant rather than the target participant.
Reimplemented polymorphic event logic to match polymorphic attribute logic.
Polymorphic and true events are now shown on OCM and SCM.
Various actions have been added to Preferences menu:
Save Preferences (saves preferences to registry on Windows),
Delete Saved Preferences (deletes registry entries on Windows),
Save Preferences on Exit (toggles save on exit setting).
Participant nodes in tree browser now have a new look.
Saving pattern or archetype files no longer generates a colour-coded HTML file.
However, the Pretty Print Java program which is now distributed with OOA Tool
performs the same task.
Undefined pattern rule names are now shown in orange within Pattern Language editor.
OOATool project now saves information model reports for OOA of OOA domain
within an OOAofOOA subdirectory.
"PatternLanguage.pattern" has been moving into Pattern Language service domain.
An "ExtensibleMarkupLanguage.pattern" has been created
and added to Extensible Markup Language service domain in OOATool project.
However, this domain has not been modelled yet.
Fixed arrow display problem in tree browser when using Liquid/Mac look and feel.
Fixed multi-line HTML display problem in tree browser
when using CDE/Motif, Windows and Liquid/Mac look and feels.
J2SE 5.0 menus containing icons are now better aligned
(problem completely fixed in Java SE 6).
Character patterns within ".pattern" files can now correctly include Java integer literals.
Token rules can now reference other token rules without returning duplicate tokens.
Only the enclosing token will be returned from the lexical parser.
BridgePoint 6.x ".bak" and ".sql" exports and BridgePoint 7.0 ".xtuml" exports
can now be loaded into OOA Tool with minimal loss of information.
Some diagram layout information is currently lost
and OOA Tool needs to provide zoom support to better handle BridgePoint diagrams
which are typically laid out within an 8000 by 6000 pixel space.
Obviously, synchronous services and processes (bridges and transformers in BridgePoint)
are also lost at present since OOA Tool doesn't support them yet.
Once a BridgePoint export is loaded it can only be saved as an ".ooa" file.
Added browser icons to indicate active objects, competitive relationships
and polymorphic subtype-supertype relationships.
Competitive relationships can't be composed or mathematically dependent relationships
and this constraint is now enforced within OOA Tool.
Diagram editors now centre their view on a preferred model element when opened.
For domain charts this is the first application domain or first domain if no application domain.
For subsystem models this is simply the first subsystem.
For object information models this is the lowest numbered prominent object
or lowest numbered object if no prominent objects.
For object communication models this is the highest state model on the OCM
which should be the most knowledgeable and powerful.
For state transition diagrams this is the lowest numbered creation state
or lowest numbered state if no creation states.
State actions are now only shown on state transition diagrams if 10 lines or less.
This is a temporary fix.
Saves OOA files using OOA Interchange Format
Version 0.02.
However, Version 0.01 OOA files from previous builds can still be loaded.
Supplemental data items now include a description attribute.
Domain chart diagrams now represent bridges using double curved lines with 1 or 2 way points
(cubic or quad curves in Java 2D).
All diagrams now include the following zoom actions:
Zoom To Fit Window which increases or decreases diagram scale
to fit within the current window,
Zoom To Actual Size which restores diagram scale
to use the default font size,
Zoom In which increases diagram scale by 1 font size,
and Zoom Out which decreases diagram scale by 1 font size.
These actions have been added to all diagram toolbars and popup menus.
All diagram shapes now include a Preferred Size Usage attribute
which takes one of the following values:
None enabling the user to resize a shape freely,
Use As Size disabling the user's ability to manually resize a shape
(default value),
Use As Minimum Size enabling the user to increase a shape's size
but not decrease it below the preferred size,
and Use As Maximum Size enabling the user to decrease a shape's size
but not increase it beyond the preferred size
(useful for shrinking imported objects to exclude attributes).
The preferred size of a shape changes whenever the shape's content changes.
Depending on what the preferred size usage is for a given shape,
the shape's size may be automatically increased or decreased in line with the preferred size
whenever the parent diagram is viewed or edited.
However, any automatic size changes must still be applied manually by the user.
The preferred size usage for a shape may be changed using the shape's popup menu.
Rectilinear link management has been significantly improved:
way point creation and deletion is better,
spur point determination is better,
and moving a way point (or target point) will automatically move the previous
or next way point so that a vertex move operation becomes an edge move operation.
Diagrams are automatically resized to make all shapes and links visible
when a diagram editor is opened.
However, this automatic resize can be undone by pressing the Reset button.
Added Select All action and Resize menu
containing various resize actions to all diagram popup menus.
Users can still type CTRL-A to select all model elements
and use the diagram details form (accessed from diagram popup menu) to resize diagrams.
Added CTRL-UP, CTRL-DOWN, CTRL-LEFT
and CTRL-RIGHT keys to all diagrams for moving selected elements by 2 pixels.
Fixed a corrupt participant mapping bug causing save project to fail.
This bug would occur whenever a supertype object was changed
on an existing subtype-supertype relationship containing any participant mappings.
Fixed a problem with the referential attribute resolution algorithm
which was not always resolving referential attributes involved in circular references.
The final pass of the algorithm needs to be iterative rather than a single step
(see
Technical Note - Referential Attributes).
Fixed a scaleability issue caused by Java Swing timers which don't scale in J2SE 5.0 or Java SE 6,
e.g. using 100 or more timers causes popup submenus to take several seconds to appear.
This was becoming a major problem since OOA Tool makes heavy use of timers
to update derived values.
Fixed a tab selection bug which occurs in J2SE 5.0 when any first tab is removed.
Fixed a focus problem on diagram editor which meant that ESCAPE
could not always be used to cancel a move or resize operation.
Selection and deselection of multiple elements is now performed as a single visible action,
i.e. CTRL-A now selects all elements instantly.
Saves OOA files using OOA Interchange Format
Version 0.03.
However, Version 0.01 to 0.02 OOA files from previous builds can still be loaded.
Added Executable UML support:
Added the concept of notation to a project and separately to all diagrams.
Notation can be either:
Shlaer-Mellor,
Executable UML (xtUML)
or Executable UML2.
The notation of all diagrams can be changed automatically when project notation is changed.
However, if diagram notation is changed on an individual basis the user is given
an option of horizontally and/or vertically scaling a diagram during the conversion.
This is especially useful when converting tightly packed OIMs into Class Diagrams.
It is also possible to selectively choose between UML1 and UML2 diagrams
while sticking with UML1 as the project notation.
The notation used in the different diagrams supported by OOA Tool
is specified in the following technical notes:
The technical notes for OCMs and STDs will be published before the next build is released
since some minor bits associated with these diagrams isn't finished yet.
Diagram notation controls the actual diagram notation used
along with the following displayed diagram type names:
Shlaer-Mellor
Executable UML
Domain Chart
Domain Chart
Subsystem Relationship Model
Subsystem Relationship Diagram
Subsystem Communication Model
Subsystem Collaboration DiagramUML1 Subsystem Communication DiagramUML2
Subsystem Access Model
Subsystem Access Diagram
Object Information Model
Class Diagram
Object Communication Model
Collaboration DiagramUML1
Communication DiagramUML2
Object Access Model
Access Diagram
State Transition Diagram
Statechart DiagramUML1
State Machine DiagramUML2
Action Data Flow Diagram
Activity Diagram
Thread of Control Chart
Sequence Diagram
N/A
Use Case Diagram
Executable UML names in italics were not explicited named in xtUML.
Executable UML names with a UML2 suffix are used
when Executable UML2 notation is selected.
Obviously, Action Data Flow Diagrams and Thread of Control Charts
are not currently supported since process models are not fully implemented yet
and neither is the OOA simulator.
Project notation controls the initial notation of new diagrams
along with the following displayed names and phrases:
Shlaer-Mellor
Executable UML
Information Model
Platform-Independent Model
Object
Class
Unassigned Object
Unassigned Class
Assigned Object
Assigned Class
Mathematically Dependent Attribute
Derived Attribute
Binary Relationship
Binary Association
Simple Relationship
Simple Association
Associative Relationship
Association Class Association
Composed Relationship
Equal Set Constrained Association
Mathematically Dependent Relationship
Derived Association
Loop Dependent Relationship
Loop Dependent Association
Loop Independent Relationship
Loop Independent Association
Subtype-Supertype Relationship
Generalization
Participant
Relationship End
First Participant
First Class End
Second Participant
Second Class End
Associative Participant
Association Class End
Supertype Participant
Superclass End
Subtype Participant
Subclass End
Participant Mapping
Relationship End Mapping
Associative To First Mapping
Association To First Mapping
Associative To Second Mapping
Association To Second Mapping
Subtype To Supertype Mapping
Subclass To Superclass Mapping
State Model
State Machine
Lifecycle Model
Lifecycle Machine
Assigner Model
Assigner Machine
Single Assigner Model
Single Assigner Machine
Multiple Assigner Model
Multiple Assigner Machine
Terminator
Actor
Subtype Event
Subclass Event
Internal Event
Internal Signal
External Event
External Signal
Supplemental Data Item
Event Parameter
Carried Data Item
Carried Parameter
Received Data Item
Received Parameter
Action
Procedure
Simple Action
Simple Procedure
Process Model
Action Model
Process
Action
Added Default Notation preference
which controls the initial notation of all new projects.
Added Notation attribute to Project element
and all diagram elements within OOA Interchange Format.
Added new Executable UML icons.
Added new Executable UML tree browser node label formatting.
Added the concept of a loop dependent relationship
which defines a dependent loop using a set of loop traversal mappings
(see
Technical Note - Loop Dependent Relationships).
A composed relationship is now a loop dependent relationship with loop traversal mappings
rather than component participants so ComponentParticipant elements
are now replaced by LoopTraversalMapping elements.
A constrained relationship (first mentioned in OOA96) is a simple, associative or
mathematically dependent relationship with loop traversal mappings.
The Constraints attribute on all attribute elements has now been removed
since loop constraints should now be documented in loop dependent relationship descriptions.
Changed the naming of assigner models from "Rn Assigner" to
"associtiveObject Assigner" when the associative object only has a single assigner model.
However, the competitive relationship name format is still used when there is no associative object
or when the associative object participates in many competitive relationships.
The label prefix used for assigner models has also been changed in the same way,
e.g. R21 Assigner (R21-A) in Starr01Elevator model is now
Transfer Assigner (XFER-A).
Clicking on an action node within OOA Tool now opens an Action Language colour-coded editor.
Furthermore, STDs now show action language code using the same colour coding.
State elements now include a SimpleAction element containing a
StatementBlock rather than an Action element containing
a Description.
SimpleAction elements also define a MaximumVisibleLOC attribute
for controlling the maximum number of code lines displayed below a state on an STD.
Fixed a participant mapping validation bug.
Participant mappings were sometimes not being removed when a participant object was changed.
Fixed a diagram editor update bug.
Attribute information was not always being updated immediately after a change occurred.
Circular link way points are now correctly updated when diagram border is changed.
Selected way points now stay selected when zooming in.
A dialog with a sensible initial number is now presented to the analyst
when adding a manually numbered relationship.
Simple unary links (e.g. creation event links) now have their target point reset
if target point overlaps source shape.
Creation event link way points are now associated with creation state rather than creation event.
This stops the analyst accidentally deleting a creation event
when they think they are deleting a creation event transition.
Non-creation states are now highlighted in orange in the model element browser
when new state transitions into the state have incompatible signatures.
This mirrors the behaviour of creation states
when their creation events have incompatible signatures.
As part of this change, a new TransitionEventsCompatible attribute
has been added to the Non-Creation State object in the OOA of OOA.
Diagram labels (which are drawn above shapes and links) now have half transparent backgrounds
so that links drawn beneath labels are greyed out making the label more readable.
Link edges (i.e. connector points) are now immediately recalculated
after way points are automatically removed.
Link labels on simple vertical links are now always centered making allowance for shape labels,
e.g. event signatures on simple vertical transition links
are now always centered making allowance for state actions.
Link elements now have a LinkID attribute
instead of a Label attribute in OOA Interchange Format.
BinaryLink element now has a LabelAnchorFlipped flag
which can be set in diagram editors to flip the location of various link labels,
e.g. event signature on STDs can be flipped left/right or up/down.
Saves OOA files using OOA Interchange Format
Version 0.04.
However, Version 0.01 to 0.03 OOA files from previous builds can still be loaded.
Added support for arbitrary ID attributes and data types.
This topic will be discussed in an upcoming technical note.
Finished all data type forms including: Boolean Type forms, Enumerated Type forms,
Symbolic Type forms, Numeric Type forms and Arbitrary ID Type forms.
Added object and relationship instance data support.
Model Populations of instance data can now be added to projects.
Model populations covering an entire project are partitioned into domain populations
which are further partitioned into object and relationship instance tables
with one table per object and relationship.
Their primary role is to define the initial population of instance data
used to intialize a simulation or translation.
Added version controlled OOA of OOA
instance data support.
Metamodel Populations of OOA of OOA instance data can now be added to projects.
This instance data is automatically generated from the current model
whenever the user selects Populate Metamodel... from the metamodel population's menu.
However, it is never saved in OOA files since it is massively redundant!
This instance data will be used in the new translator to generate reports and code.
It will also be accessable in action language code during simulations.
Added basic Project Matrix
[ProjMatx84]
support including concepts of task and activity.
Tasks can now be defined on projects.
Activities can now be defined on domains (if no subsystems) and subsystems.
There are no predefined tasks covering the Shlaer-Mellor Method at present.
Although the Project Matrix table editor only views tasks and activities,
it does allow you to create/edit tasks and activities via model element popup menus.
Tasks and activities have also been added to the OOA Tool
and official metamodel Recursive Design subsystems.
A new Executable UML2 model for the Executable UML Foundation (fUML)
has been added to the distribution.
It will be used later as the basis for providing fUML simulation support.
Identifier form no longer allows identifiers to be created
with identifying attributes matching an existing identifier.
Version format attribute on projects replaced with location format attribute,
e.g. version format of "0.04" replaced with location format of "OOA Interchange Format 0.04".
Can now capture server requirements on bridge form.
Domain form now shows all server requirements from bridges (only editable on bridge form)
and all client assumptions to bridges (editable on domain and bridge form).
Made a small improvement to the referential attribute resolution algorithm.
When navigating from a subtype object to a supertype object (via a referential attribute mapping)
and back again across the same subtype-supertype relationship (via a polymorphic attribute mapping)
then the only true attributes that are checked as part of the resolution
are those associated with the source object
since any true attributes associated with the other subtype objects are not reachable.
Added Swap First And Second Roles action to binary relationship menu.
This makes the first participant become the second participant and vice-versa.
It also swaps the actual roles associated with the first and second participants.
This can be useful when defining connector phrases or participant roles.
This build was a major rewrite with many new features but not all features were completed.
After considerable thought, the architecture used here has since been abandoned.
Work is already well underway on a completely new architecture
which will be released in a future build.
However, the new architecture is being modelled using this build of OOA Tool.
Saves OOA files using OOA Interchange Format
Version 0.05
but this format is not complete.
Version 0.01 to 0.04 OOA files from previous builds generally still load.
However, backwards compatibility has not been fully tested.
Anyone with a model that doesn't load should email support for assistance.
OOA Tool now supports the following new data types:
user defined External Types which are associated with an external entity
and which may also have an associated literal type allowing default values,
a single predefined Enumerated Subtype Type for every subtype-supertype relationship,
a single predefined Enumerated State Type for every state model,
a single predefined Object Instance Type for every object,
a single predefined Event Instance Type for every event,
a single predefined Return Coordinate Type for every synchronous service,
a single predefined generic Transfer Vector Type,
and a single predefined Transfer Vector Type for every asynchronous return process.
More details can be found in the
Data Type subsystem
of the OOA of OOA.
A distinction is now made between population independent types (boolean type, enumerated type,
symbolic type, numeric type and arbitrary ID type) which all allow default values
and population dependent types (object instance type, event instance type, return coordinate type,
transfer vector type) which all require a population as a context for any associated data values.
External types are not classified as either.
In the previous build, users had to explicitly add core types to a project and all data types
appeared directly below their parent information model node in the tree browser.
In this build, all predefined types (including core types) are automatically added to every project
but are not visible in the tree browser until they are referenced from within the project.
Obviously, they are visible within data type selection widgets.
Furthermore, not all data types appear directly below their parent information model node now,
instead:
user defined types (excluding object specific arbitrary ID types), core types
and the generic transfer vector type are below parent information model node,
object specific arbitrary ID types and object instance types
are below associated object node,
enumerated subtype types are below associated subtype-supertype relationship node,
enumerated state types are below associated state model node,
external types are below associated external entity node,
event instance types are below associated event node,
return coordinate types are below associated synchronous service node,
and transfer vector types (excluding generic transfer vector type)
are below associated asynchronous return process node.
Core types can be overridden by defining a user defined type with the same basic name
while still allowing the original core type to be used.
However, the core type should be referenced using a "<>" suffix in that case.
For example, core type Integer could be overridden with user defined type
Integer while core type Integer could still be accessed
using the qualified name Integer<>.
Core type names are now shown in italics rather than bold navy.
All data types now have derived Data Type ID and Reference Count
attributes.
Data type IDs are used within operator labels since using name would be too verbose.
Arbitrary ID types may now have an associated default value.
They are also labelled as sequential if
Unallocated Percentage Before Reallocation is zero and
Minimum Unallocated Before Reallocation is one.
Most ordinal ID types will be sequential while most non-ordinal ID types will not.
Only user defined types are saved when a project is saved unless the Include Derived Data
preference is selected in which case all data types are saved.
However, all predefined types are ignored after being parsed when a project is loaded.
Added workaround for a serious bug in J2SE 1.5 which occurs when a very large panel is opened,
e.g. opening a Subsystem editor panel when there are more than 512 Objects and Relationships
causes continuous exceptions making OOA Tool almost impossible to interact with.
The workaround logs a single warning and recommends Java SE 6 be used instead,
then displays a blank panel.
Added a workaround for a Java SE 6 infinite loop bug (see Java Bug ID 6606443)
which sometimes occurs after replacing text in any of the colour-coded text editors.
There is no undo support when model elements are changed or deleted, so be careful and backup regularly.
State Transition Table is not finished.
Use Case Diagrams defined in Executable UML are not supported.
Information Model Reports will not properly support Executable UML
until new template-based reports are created.
The current XML parser used to load OOA files doesn't support all aspects of the XML 1.0 standard,
e.g. element start and end tags must appear on separate lines (unless they delimit character data).
Support
To contact us
with regard to bugs or other support issues please e-mail:
