BRUE Behavioral Reverse Engineering in UML as Eclipse Plugin

1. BRUEBehavioral Reverse Engineering in UML as Eclipse Plugin MSE Presentation 1 Sri Raguraman

2. Outline • Project Overview • Requirements • Project Plan • Cost Estimation • Architecture Elaboration Plan • Software Quality Assurance Plan • Prototype Demo • Questions/Comments

3. Project Overview Goal • To provide a Eclipse plugin to enable users to run scenarios on any Java based system and view both the static structure and dynamic behavior of the scenario. Motivation • To fully understand an object-oriented system, information regarding its structure and behaviorare required. • Lack of tools to visualize behavior of object-oriented systems.

4. Project Overview (contd.)

5. Requirements Launch BRUE Run Scenario View Static Structure Visualize scenario View Dynamic behavior

6. Use Case 1 – Launch BRUE • Description:This use-case describes the capability of launching BRUE and setting a scope for a Eclipse project intended to be analyzed through BRUE. • Includes: Displaying a Eclipse Launch configuration for BRUE. • Stimulus/response sequence:The user selects the “Run” option available for a Eclipse project. The “Run” wizard includes a BRUE launch configuration. User sets scope of types (packages, classes, and methods) that need to be analyzed by BRUE.

7. Launching BRUE (Screenshot) BRUE Launch configuration

8. Use Case 2 – Execute scenario • Description:This use case provides the capability of instructing a launched application that the user is about to execute a scenario. The launched application prepares itself to capture behavioral data. • Stimulus/response sequence: • User selects “BRUE > Start scenario” from the project’s context menu. • System instructs launched application to start collecting behavioral data. • User executes scenario and systems captures behavioral data (call trace along with details about caller and callee). • User selects “BRUE > Stop scenario” from the project’s context menu.

9. Context menu for project contains options to start/stop scenario.

10. Use Case 3 – Visualize scenario • Description:This use-case describes the capability of visualizing the structural and behavioral aspects of the scenario. • Stimulus/response sequence: • User navigates to the folder that contains the class diagram and sequence diagram model files. • User right clicks on a model file and selects “Initialize diagram”. • System renders the diagram appropriate for the model file.

11. Use Case 4 – Edit diagram • Description:This use-case describes the capability of editing a limited set of features in the diagrams. • Stimulus/response sequence:When a diagram (class diagram or sequence diagram) is rendered on a Eclipse editor, the user can perform the following tasks: • Move nodes • Align nodes • Attach notes to specific nodes or links • Change font, or color.

12. Use Case 5 – Printing Diagrams • Description:This use-case describes the capability of printing rendered diagrams. • Stimulus: User selects print option for a diagram • Response: Systems sends appropriate data to the selected printer.

13. Project Plan

14. Cost Estimate • Basic COCOMO Model Effort = 3.2*EAF (Size)^1.05 Time (in months) = 2.5(Effort)^0.38

15. Effort Adjustment Factor • RELY (Required Reliability) as normal and a value of 1.1 • DATA (Database Size) as very low and a value of 0.95 • CPLX (Product Complexity) as high and a value of 1.40 • TIME (Execution time constraint) as normal and a value of 1.35 • STOR (Main storage constraint ) as normal and a value of 1.30 • VIRT (Virtual machine volatility ) as very low and a value of 0.90 • TURN (Computer turnaround time) as low and a value of 0.90 • ACAP (Analyst capability) as normal and a value of 0.90 • AEXP (Applications experience) as normal and a value of 0.90 • PCAP (Programmer capability) as high and a value of 0.90 • VEXP (Virtual machine experience) as normal and a value of 1.0 • LEXP (Language experience) as high and a value of 1.0. • MODP (Use of modern practices) as high and a value of 0.95 • TOOL (Use of software tools) as high and a value of 0.90 • SCED (Required development schedule) as high and a value of 1.15.

16. Calculations KSLOC – 3.5 – based on the previous versions of the tool • EAF – 1.63 • Effort = 3.2*1.63*2.5^1.05 = 13.36 staff months The time can now be calculated as: • Time = 2.5*13.36^0.38 = 6.69 months

17. Architecture Elaboration Plan • Revision of Vision Document: After the first presentation, changes as required by the committee should be made in the Vision Document. • Revision of Project Plan: According to the changes suggested by the committee after the first presentation, the project plan should be modified to include those changes. A section about the implementation plan should be added before the second presentation. • Architecture Design: Based on the use case diagram in the vision document and using other UML diagrams, an architecture design should be developed for the second phase. • Development of Prototype: This prototype will include the demonstration of the critical requirements identified in the Vision Document.

18. Architecture Elaboration Plan (contd.) • Test Plan: A complete test plan will be developed indicating the testing techniques used and the way bugs will be reported and solved. Unit testing, integration testing and system testing will be performed. This will be done to test whether all the requirements specified in the vision document are met or not. • Formal Technical Inspection: Two other MSE Students will review the architecture design produced by the developer and submit a report on their findings. • Formal Requirements Specification: The part of the project describing Sequence Diagrams will be formally specified using OCL. The tool used will be USE (UML-based Specification Environment).

19. Software Quality Assurance Plan • Reference Documents • Vision Document • Project Plan • IEEE Guide for Software Quality Assurance Planning • IEEE Standard for Software Quality Assurance Planning • Supervisory Committee • Dr. Daniel Andresen (Major Professor) • Dr. Scott DeLoach • Dr. David Gustafson • Developer • Sri Raguraman • Formal Technical Inspectors • To-be-finalized-1 • To-be-finalized-2

20. Documentation • The documentation will consist of a vision document, project plan, software quality assurance plan, formal requirements specification, architecture design, test plan, formal technical inspection, prototype, user manual, component design, source code, assessment evaluation, project evaluation, references, formal technical inspection letters. • All documentation will be posted on the developer’s web site at http://www.cis.ksu.edu/~sri/BRUE.html

21. Standards, Practices, Conventions, and Metrics • Documentation Standard IEEE standards will be used as a guideline to follow. • Coding Standard The project will use traditional object oriented analysis and design methods. Recommended Java style guidelines will also be followed. • Documentation JavaDoc will be used for documenting the complete API for the project. • Metrics Basic COCOMO will be used to estimate the effort and time for the project.

22. Reviews and Audits • The committee members will be conducting reviews of the documentation as well as evaluating the developer’s work at each presentation. They will also comment on the software prototype demonstration to suggest changes and additions to the requirements specifications. • Two graduate students will evaluate the architecture design artifacts and report on their findings.

23. Test and Problem Reporting • All tests, along with their results, will be recorded on a time log of the project web page. • Unresolved problems will be reported directly to the committee members.

24. Tools, Techniques, and Methodologies Eclipse 3.x Eclipse plugins: GMF 1.1, UML2 2.0 Microsoft Word – for documentation Microsoft Software Project 2003 – Project Planning USE 2.0.1 – for formal requirements specification JUnit for unit testing

25. Others Media Control • The software will be available on a CD-ROM ready for installation. The executable file will be recorded on it. • A user manual soft copy will also be saved in the CD to aid with the installation process and use of the software. • Documentation will be available from the developer’s website http://www.cis.ksu.edu/~sri/BRUE.html Records collection, maintenance and retention • The design documentation will be stored in the University library, the Major Professor and the developer. • Entire source code, documentation and web pages for the project website will be submitted to the Major Professor in the form of a CD. This will also be stored with the developer.

26. Deliverables Phase I · Vision Document · Project Plan · Software Quality Assurance Plan · Prototype Demonstration Phase II · Vision Document · Project Plan · Formal Requirements Specification · Architecture Design · Test Plan · Formal Technical Inspection · Executable Architecture Prototype

27. Deliverables (contd.) • Phase III • · Component Design • · Source Code • · Assessment Evaluation • · User Manual • · Formal Technical Inspection Letters • · Project Evaluation

28. Prototype Demonstration

29. Questions/Comments