1. agentTool (III) Dynamic MSE Presentation 2 Binti Sepaha

2. Outline  GEF Overview  Architecture Design  Formal Specification  Inspection Checklist  Project Plan  Test Plan  Activity Diagram Editor Demo  Questions/Comments

3. Graphical Editing Framework  Enables user to make rich graphical editors  Uses Draw2D to handle visual graphics  Based on MVC Approach

4. Graphical Editing Framework (contd.)  Controller bridges the Model and the View  Model and View have no knowledge of each other  Each model has an associated edit part i.e. controller and a view

5. Functioning of Edit Part

6. Functioning of Edit Part (contd.)  An edit part can play certain roles like Node Role, Container Role, etc.  Node Role – to connect to other nodes  Container Role – to contain child objects  Roles are delegated to Edit Policies which handle Requests  ContainerEditPolicy is installed for container role which handles requests such as AddChild  NodeEditPolicy is installed for node role and handles requests such as target or source connect.

7. Functioning of Edit Part (contd.)  ContainerEditPolicy then creates a COMMAND called getCreateCommand which is executed and a new object is created and added to the Container  Similarly, NodeEditPolicy creates getConnectionCreateCommand and getConnectionCompleteCommand to start and end the connection  Another policy - XYLayout Policy is used by the container edit part to place children in XY Layout  The behavior of getCreateCommand is shown in a Sequence Diagram

8. Add an Element

9. Move an Element

10. Architecture Design  Package View Controller View Model Editor

11. Editor Package  ActivityDiagramEditor – creates and loads the graphical editor and the palette  ActivityDiagramPlugin – enables the editor to be installed as a plugin in Eclipse Environment  PaletteViewerCreator – creates palette entries and associates models with each entry  PaletteFlyoutPreferences – sets the palette flyout preferences  GraphicalViewerCreator – this is the actual graphical editor i.e. the drawing pane  OverviewOutlinePage – this class gives the outline view of the diagram

12. Model Package

13. EditPart Package

14. Command Package

15. View Package

16. Formal Specifications model agentTool -- -- CLASSES -- class ActivityDiagram attributes name : String end class IModel attributes name : String x : Integer y: Integer width: Integer height: Integer end class ActionState < IModel operations addActionState(ad : ActivityDiagram) : Set(ActionState) = ad.hasActionStates->union(Set{self}) deleteActionState(ad : ActivityDiagram) : Set(ActionState) = ad.hasActionStates - (Set{self}) end class InitialState < IModel end class FinalState < IModel end class FlowFinalNode < IModel End

17. class IncomingEvent < IModel end class OutgoingEvent < IModel end class SynchronizationPoint < IModel end class DecisionNode < IModel end class SwimLane < IModel end -- --ASSOCIATIONS -- association ActionStateBelongsTo between ActionState[*] role hasActionStates ActivityDiagram[*] role belongsTo end association FinalStateBelongsTo between FinalState[0..1] role hasFinalStates ActivityDiagram[*] role belongsTo end association InitialStateBelongsTo between InitialState[0..1] role hasInitialStates ActivityDiagram[*] role belongsTo end association FlowFinalNodeBelongsTo between FlowFinalNode[*] role hasFlowFinalNodes ActivityDiagram[*] role belongsTo end association IncomingEventBelongsTo between IncomingEvent[*] role hasIncomingEvents ActivityDiagram[*] role belongsTo End association OutgoingEventBelongsTo between OutgoingEvent[*] role hasOutgoingEvents ActivityDiagram[*] role belongsTo end

18. association SynchronizationPointBelongsTo between SynchronizationPoint[*] role hasSynchronizationPoints ActivityDiagram[*] role belongsTo end association DecisionNodeBelongsTo between DecisionNode[*] role hasDecisionNodes ActivityDiagram[*] role belongsTo end association SwimLaneBelongsTo between SwimLane[*] role hasSwimLanes ActivityDiagram[*] role belongsTo end -- --This assocaition shows that there is an action flow between 2 elements -- association ActionFlow between IModel[*] role startsFrom IModel[*] role endsAt end -- --CONSTRAINTS -- constraints context ad:ActivityDiagram inv UniqueActionStates: ad.hasActionStates->forAll(a1, a2 | a1 <> a2 implies a1.name <> a2.name) context ActionState::addActionState(ad : ActivityDiagram): Set(ActionState) pre cond1 : ad.hasActionStates->excludes(self) post cond2 : ad.hasActionStates = ad.hasActionStates@pre->union(Set{self}) post cond3 : result = ad.hasActionStates post cond4 : (ad.hasActionStates - ad.hasActionStates@pre)->size() = 1 context ActionState::deleteActionState(ad : ActivityDiagram): Set(ActionState) pre cond1 : ad.hasActionStates->includes(self) post cond2 : ad.hasActionStates = ad.hasActionStates@pre->excluding(self) post cond3 : result = ad.hasActionStates post cond4 : (ad.hasActionStates@pre - ad.hasActionStates)->size() = 1

19. Inspection Checklist  The symbols used in the class diagrams conform to UML standards  The classes in the class diagrams have a corresponding description provided in the Architecture Design document  The description of the classes in the Architecture Design document are clear and adequate  The symbols used in the sequence diagrams conform to UML standards  The sequence diagrams are clear and understandable  The attributes in the USE model are compatible with the attributes of the corresponding class diagrams  The multiplicities in the USE model are reflected in the Class diagram  Classes in the Architecture Design (Activity Diagram) correspond to classes in the USE model  All model elements and relationships as outlined in the Vision Document (Section 3.1.1.2) are present in the Architecture Design document as classes

20. Project Plan Already developed – 5.5 KSLOC which is 50% of the entire project  5500 SLOC / 150 hours = 36.67 SLOC/hour (productivity)  5500 SLOC /.50 = 11000 SLOC (total SLOC)  Remaining SLOC = 5500  (5500 SLOC)/ 36.67 SLOC/hour = 150 hours (Remaining Time)

21. Project Plan (contd.)  150 hrs/6 hrs per day = 25 days  Approximately 25 days for coding, testing, etc.  And 10 days documentation which includes component design, user manual, etc.  Total of 35 days  Approximate Completion Date – April 20 th 2005

22. Test Plan  Features to be tested – all features from Vision Document Version 1.0 Drawing Sequence Diagrams Drawing Activity Diagrams Importing Models Exporting Models Printing Diagrams  JUnit Plugin for Eclipse will be used for Unit testing  Only functional testing will be performed  All Test Results will be documented

23. Phase III Deliverables · Component Design · Source Code + JavaDocs · Assessment Evaluation · User Manual · Formal Technical Inspection Letters · References · Project Evaluation

24. Activity Diagram Editor Demo

25. Sample XML Model

26. Questions/Comments