1. Sequence Diagram Generator Presentation II MSE Project / Fall, 2005 Samer AliSaleh Major Advisor: Bill Hankley

2. Presentation I Action Items Quality Assurance Plan. Quality Assurance Plan. Area covered by formal specification. Area covered by formal specification. Technical Inspectors. Technical Inspectors. Better GUI Prototype. Better GUI Prototype. Used Technology Used Technology

3. Action Item: Quality Assurance Plan Quality assurance plan is created and can be found on the following link: Quality assurance plan is created and can be found on the following link: http://www.cis.ksu.edu/~ssaleh/mseproject.htm

4. Action Item: Formal Specification Topic The Analyzer Rules were selected for formalization using OCL. The Analyzer Rules were selected for formalization using OCL. More details about the specification in the following slides. More details about the specification in the following slides.

5. Action Item: Technical Inspectors Judy Dizon (MSE) Judy Dizon (MSE) Patrcik Gallagher (MSE) Patrcik Gallagher (MSE) Inspection will be done during phase 3 of the project. Inspection will be done during phase 3 of the project. Inspection List can be found on the following link: Inspection List can be found on the following link: http://www.cis.ksu.edu/~ssaleh/mseproject.htm

6. Action Item: GUI Prototype Problem: Only Visio GUI diagrams were provided as a prototype. No Executable GUI. Problem: Only Visio GUI diagrams were provided as a prototype. No Executable GUI. Solution: an executable prototype is built with some functionality of each given requirement. Solution: an executable prototype is built with some functionality of each given requirement. Prototype demonstration will be given at the end, with an example. Prototype demonstration will be given at the end, with an example.

7. Action Item: Used Technology Writing Plug-in for Smart Development Environment (SDE) developed by Visual Paradigm Writing Plug-in for Smart Development Environment (SDE) developed by Visual Paradigm

8. Smart Development Environment Very powerful tool that has the needed functionality to fit any application Very powerful tool that has the needed functionality to fit any application Can be extended and integrated through different IDEs. Can be extended and integrated through different IDEs. Easier to write plug-in: Readable tutorial, and well organized API. Easier to write plug-in: Readable tutorial, and well organized API. Functionality Vs. Development Time Functionality Vs. Development Time Online Support Online Support

9. VP-SDE and IDE’s

10. VP-SDE Plug-in Architecture

11. Writing Plug-in Challenges…. Learning Curve: Learning Curve: - Very brief tutorial. - Uncommented API. Click here - Uncommented API. Click hereClick hereClick here Limited Interaction: Limited Interaction: - No listeners nor Events handling or processing. - No listeners nor Events handling or processing. Bugs in the API Bugs in the API - Bugs even in getters & setters No way to debug or trace exceptions No way to debug or trace exceptions

12. Design Architecture -Package Model Actions Handler Dialogs Controller Diagram Elements Models UML Diagrams SDE Diagram Manager

13. Design Arch. – Class Model Click Here to view the class diagram. Click Here to view the class diagram. Click Here Click Here

14. Design Arch.- Controller Domain model

15. Design Arch. – Analyzer Domain Model

16. Design Arch.- Sequence Diagram (Create New Sequence Diagram)

17. Design Arch. – Sequence Diagram (Create New Caller )

18. Design Arch. – Sequence Diagram (Create New Callee )

19. Design Arch.- Sequence Diagram (Create New Life Line Element)

20. Design Arch. – State Model (Sequence Diagram Generator)

21. Formal Specification Analyzer Part + Related Classes & Attributes. Analyzer Part + Related Classes & Attributes. 9 Classes and 13 associations 9 Classes and 13 associations 3 major invariants. 3 major invariants. Formal Specification is done using OCL and USE 2.3.0. Formal Specification is done using OCL and USE 2.3.0.

22. Formal Specification Sample 1 class IClass < IModelElement Attributes classID:String className:String Operations getAllFromEndAggregationsAndCompositionsToClasses():Set(IClass)=self.cl assFromAssociationEnd-> select (a|a.type=#AGGREGRATIONKIND_AGGREGATION or a.type=#AGGREGATIONKIND_COMPOSITED).toClass->asSet // This operation is used to generate the transitive aggregation set for a // given class For example if A aggregate to B and B Aggregate to C // then the operation for class A will generate the set {B,C} transitiveAggregation(s:Set(IClass)):Set(IClass)= if s-> includesAll (s.getAllFromEndAggregationsAndCompositionsToClasses())then s else transitiveAggregation(s-> union (s.getAllFromEndAggregationsAndCompositionsToClasses())->asSet) Endif end Return all the classes that the selected class has aggregation with If Selected class aggragation classes is Subset of Transitive_Set, return Transitive_Set Else Recursion(Transitive_Set U Aggregation_Classes)

23. Formal Specification Sample 2 //3--If Message corresponds to indirect Association and intermediate classes exist, then the sender // object / must have a reference to receiver object either by a pre outgoing message with a return // type of receiver or by an ingoing message with a parameter passes as receiver. context message:IMessageinv senderHasReferenceOfReceiverForIndirectASsociation: //Check if the message corresponds to indirect Association message.fromEnd.baseClass.classFromAssociationEnd->select (a|a.toClass->includes(message.toEnd.baseClass))->isEmpty And message.fromEnd.baseClass.allFromClassRelationship->select (r|r.relationToClass->includes(message.toEnd.baseClass))->isEmpty And message.fromEnd.baseClass.transitiveAggregation (message.fromEnd.baseClass.getAllFromEndAggregationsAndCompositionsToClasses())->includes (message.toEnd.baseClass) Implies // If Message corresponds to indirect association then check // if there is a pre message in which: message.sequenceDiagram.associatedMessages->exists (m| message.index<m.index and ( // 1.a pre message sender is the same as current message sender and // the return type of the message is the same as the class name (m.fromEnd = message.fromEnd and m.toEnd.baseClass.classOperations->select (op|op.name = message.name).returnType->asSet->includes(message.toEnd.name)) or //1.b pre messate receiver is the same as the current message sender and //the message has at least one parameter of type of current messate receiver. (m.toEnd = message.fromEnd andm.toEnd.baseClass.classOperations->exists (op|op.operationParameters.type->asSet->includes(message.toEnd.name)) )) ) Message Ends don’t have aggregation Message Ends don’t have association Message Ends have indirect relation Exists a message with a return type of receiver going from sender Exists a message going into sender with a parameter passed as type of receiver

24. Testing Plan Functional Testing. Functional Testing. Test case for each functional requirement. Test case for each functional requirement. ~ 80 test cases. ~ 80 test cases. Testing will be done as part of the assessment evaluation in phase 3 of the project. Testing will be done as part of the assessment evaluation in phase 3 of the project.

25. Testing Plan Each Test case consist of action to be taken, Pre condition & post condition that need to be satisfied. Each Test case consist of action to be taken, Pre condition & post condition that need to be satisfied. Sample Test Case: Sample Test Case: IDTest CasePre ConditionsPost Conditions CS_SDG_13 Create New Callee. No New Activation. No Return Message Callee Dialog is showing. No Existing life line object of type of the selected operation class. New object name is not given. Show Error Message. Select Existing Callee object must be Disabled

26. Project Plan & Cost Estimate COCOMO Model was used to estimate LOC, and Time. COCOMO Model was used to estimate LOC, and Time. Unadjusted FP = 68 Unadjusted FP = 68 Adjusted FP = 65.96 Adjusted FP = 65.96 Estimated SLOC = 2506 Estimated SLOC = 2506 Estimated Development Time = 5 months Estimated Development Time = 5 months

27. So Far…… Total time = 19,110 min. Total time = 19,110 min. Total Days = 90 days. Total Days = 90 days. Hours/Day = 19,110 / 90 / 60 ≈ 4 hours/day Hours/Day = 19,110 / 90 / 60 ≈ 4 hours/day Remaining Days = 150 – 90 = 60 days with 4 hours / day productivity. Remaining Days = 150 – 90 = 60 days with 4 hours / day productivity. Deadline: December 7 th, 2005. Only 30 days left. Deadline: December 7 th, 2005. Only 30 days left. Productivity should increase to 8 hours/day Productivity should increase to 8 hours/day

28. Expected Vs Estimated Time (months)

29. Current Vs Estimated LOC

30. Productivity