BRUEBehavioral Reverse Engineering in UML

as Eclipse Plugin

MSE Presentation 1Sri Raguraman

Outline

Project OverviewRequirementsProject PlanCost EstimationArchitecture Elaboration PlanSoftware Quality Assurance PlanPrototype DemoQuestions/Comments

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.

Project Overview (contd.)od Ov erv iew

User

Run Scenario

Collect behav ioral data

Jav a/C++ Project

UML2 Based model for scenario

View Scenario

Visualize model for scenarioPackage

relationships

Class Diagrams

Sequence diagrams

use

monitor

output

output

output

outcome

Requirements

Launch BRUE

Run Scenario

Visualize scenario

ViewStatic Structure

ViewDynamic behavior

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.

Launching BRUE (Screenshot)

BRUE Launch configuration

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.

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

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.

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.

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.

Project Plan

Cost Estimate

Basic COCOMO Model

Effort = 3.2*EAF (Size)^1.05

Time (in months) = 2.5(Effort)^0.38

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.

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

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.

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).

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

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

Standards, Practices, Conventions, and

Metrics

Documentation Standard IEEE standards will be used as a guideline to follow.

Coding StandardThe project will use traditional object oriented analysis and design methods. Recommended Java style guidelines will also be followed.

DocumentationJavaDoc will be used for documenting the complete API for the project.

MetricsBasic COCOMO will be used to estimate the effort and time for the project.

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.

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.

Tools, Techniques, and

Methodologies

Eclipse 3.xEclipse plugins: GMF 1.1, UML2 2.0Microsoft Word – for documentation Microsoft Software Project 2003 – Project PlanningUSE 2.0.1 – for formal requirements specification JUnit for unit testing

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.htmlRecords 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.

DeliverablesPhase 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

Deliverables (contd.)

Phase III

· Component Design

· Source Code

· Assessment Evaluation

· User Manual

· Formal Technical Inspection Letters

· Project Evaluation

Prototype Demonstration

Questions/Comments