Welcome to GDPro Release 2.2.4! Release 2.2.4 is a patch to Release 2.2.3 that contains the initial release of the Design Rule Checking and Synchronization features and several bug fixes. The main feature of Release 2.2.4 is the new Design Rule Checking and Diagram Synchronization, which is explained in detail below. Bugs fixed in Release 2.2.4 include: - Reverse Engineering into UML sometimes failed to create relationships between objects. - Missing view backpointers in diagram symbols caused GDPro to crash when the symbols were moved or edited. - Code Generation fixes - forward engineering and Code Regeneration of virtual functions now works properly. - Code Generation of "const" attributes was corrected. - Code Generation of abstract (pure virtual) was corrected. - Postscript and EPS output has been extensively modified, and the resulting files are much more compact. The Diagram Synchronization in Release 2.2.4 will be extended further in Release 3.0, which will also include Pick Lists, allowing you to choose things like: - attribute types from static and dynamically created lists - messages in sequence diagrams from dynamically created lists of operations in classes - object class names fron a dynamic list of classes in the system. DOCUMENT CONTENTS ----------------- ----------------- 1.0 - New features and bug fixes on Release 2.2.4 2.0 - General Release 2.4 Information 3.0 - System Requirements ----------------------------------------------- 1.0 NEW FEATURES AND BUG FIXES IN RELEASE 2.2.4 ----------------------------------------------- DIAGRAM SYNCHRONIZATION ----------------------- When changes are made to objects or attributes on one model, associated models or referenced objects are automatically updated. 1. When you change the name of a class in the class diagram, that change propagates downwards to any named objects of the old class. 2. Changing an operation=92s name or parameters in the class diagram propagates the changes to sequence diagram messages with the old name and parameters. 3. Deleting an operation will delete sequence diagram messages with the same name and matching parameters. 4. When a message is named in the sequence diagram, the target class operations are checked to see if the message already exists. If it doesn't exist, the new message can be added to the list of operations. 5. When a message is updated in the sequence diagram, you are asked if the class operation should be changed as well. If so, other messages with the old name and parameters are also updated. 6. When one of the consistency checks listed above is violated, an informational message is displayed. The action is still allowed and the data is still saved. DESIGN RULE CHECKING -------------------- The Design Rule Checking functionality check for things like name duplication, duplicate relationships, duplicate attribute and operations within objects, and that things like association lower and upper bounds have the proper sense. The elements checked for each diagram are listed below: Class Diagram Class CLASS NAME - no duplicate name allowed within the name scope: reporting requirement. ATTRIBUTE NAME - no duplicate name allowed within the class Utility CLASS NAME - no duplicate name allowed within the name scope: reporting requirement. ATTRIBUTE AND OPERATION NAMES - no duplicate name allowed within the class Template CLASS NAME - no duplicate within the scope ATTRIBUTE NAME - no duplicate within the scope of the class Instance Class TEMPLATE NAME - match the name of a template class. Cannot add template class. Object NAME - not duplicated within the scope of a package or class CLASS NAME - must be an existing class. Cannot add. ATTRIBUTE NAME - must match an attribute of the class ATTRIBUTE TYPE - will be populated based on attribute name. This will overlay whatever the user may have entered in the field. Package PACKAGE NAME- no duplicate within the scope Pattern PATTERN NAME - no duplicate within the scope Object Association ASSOCIATION IDENTIFIER - if non-blank, must be the name of an association between the two classes of the associated objects. Class Association NAME - no (non-blank) duplicate between the same two classes or between all of the classes and the ternary symbol ROLE 1 LOWER BOUND- insure lower is <- upper ROLE 1 UPPER BOUND - insure upper is -> lower ROLE 2 LOWER BOUND - insure lower is <- upper ROLE 2 UPPER BOUND - insure upper is -> lower Binary Constraint NAME - no duplicate between the same two elements Pattern Link MEMBER ROLE NAME - no duplicate between the same pattern an= d target element Use Case Diagram ACTOR NAME - not duplicated within the scope. The actor should be pasted by reference between diagram types and this will keep the consistency. There are no other checks performed for creation or modification. Sequence and Collaboration Diagrams Object NAME - not duplicated within the scope of a package or class CLASS NAME - must be an existing class. Cannot add. ATTRIBUTE NAME - must match an attribute of the class ATTRIBUTE TYPE - will be populate based on attribute name. This will overlay whatever the user may have entered in the field. Life Line OBJECT NAME - populate based on the attached object. User can change if they wish. OBJECT ACTIVATION NAME - could be an operation name of the received message. No tight constraint because abstraction should be allowed. CONTROL FOCUS NAME - not duplicated within scope of the Life Line OBJECT BLOCK NAME - not duplicated within scope of the Life Line Message NAME - must be name of target object's class operation. This includes any inherited public operations of any super class. If no match then considered a new operation. If name match but parameter attributes do not match the specified class operation's parameter string, then it is a new operation. The return type must be entered via the Class operation attribute editor. The user may not want to create a new operation but simply have an abstract entry to be refined later. Therefore, before adding, you will be asked whether or not this operation should be added. If the matched name and the parameters are different, then you will be asked if it is to be added or the matched operation changed. PARAMETERS - populate based on the selected operation. Allow input and changes. If the selected operation has its parameters changed, then the selected class's operation parameter list must change also. State Diagram State Diagrams have no coupling to anything directly related to a class. States are just conditions of a class. Transitions are not operations of a class. The transition is triggered by an Event. The action of an Event can be a call to a class operation, but that is not necessarily true. Since there is so much conjecture and no tight coupling, there is no consistency checking here. When we properly handle Event diagramming (using Class Diagram Types), then we can tightly couple these events to the events used in state diagrams. STATE, INITIAL STATE, FINAL STATE, HISTORY STATE AND COMPOSITE STATE NAMES - not duplicated within the scope of the diagram or within composite state including all states OBJECT NAME - not duplicated within the scope of the class it represents. The problem here is that there are no attributes to define the class that this object is an instance of. Therefore, this validation should not be done. Activity Diagram INITIAL STATE AND FINAL STATE NAMES - not duplicated with any other state within the scope of the diagram. ACTION STATE LABEL - not duplicated with any other state within the scope of the diagram Known Bugs and Limitations -------------------------- 1. If an operation is deleted from a class, the message on the sequence diagram appears to still be there. However, if something on the sequence diagram is moved, the message disappears and the diagram is refreshed. Also, if the system is closed without the sequence diagram being refreshed, the message remains. These are both refresh problems in the tool and will be corrected in the next release. 2. There are some problems in the sequence diagram when there are several class operations with the same name and different signatures. These will be resolved when we move towards typecasting the signatures. 3. Deleting a parameter from a message will not update the class. 4. Entering a name of "Fred" and a name of "Fred