BRUE Behavioral Reverse Engineering in UML as Eclipse Plugin

1
BRUE Behavioral 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 behavior
  are 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 gt Start scenario from the
  projects 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 gt Stop scenario from the
  projects 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.2EAF (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.21.632.51.05 13.36 staff months
• The time can now be calculated as
• Time 2.513.360.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
  developers web site at http//www.cis.ksu.edu/sr
  i/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
  developers 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
  developers website http//www.cis.ksu.edu/sri/BR
  UE.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