Brue behavioral reverse engineering in uml as eclipse plugin
1 / 29

BRUE Behavioral Reverse Engineering in UML as Eclipse Plugin - PowerPoint PPT Presentation

  • Uploaded on

BRUE Behavioral Reverse Engineering in UML as Eclipse Plugin. MSE Presentation 1 Sri Raguraman. Outline. Project Overview Requirements Project Plan Cost Estimation Architecture Elaboration Plan Software Quality Assurance Plan Prototype Demo Questions/Comments. Project Overview.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'BRUE Behavioral Reverse Engineering in UML as Eclipse Plugin' - yvon

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Brue behavioral reverse engineering in uml as eclipse plugin

BRUEBehavioral Reverse Engineering in UML as Eclipse Plugin

MSE Presentation 1

Sri Raguraman


  • Project Overview

  • Requirements

  • Project Plan

  • Cost Estimation

  • Architecture Elaboration Plan

  • Software Quality Assurance Plan

  • Prototype Demo

  • Questions/Comments

Project overview
Project Overview


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


  • To fully understand an object-oriented system, information regarding its structure and behaviorare required.

  • Lack of tools to visualize behavior of object-oriented systems.


Launch BRUE

Run Scenario


Static Structure

Visualize scenario


Dynamic behavior

Use case 1 launch brue
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
Launching BRUE (Screenshot)

BRUE Launch configuration

Use case 2 execute scenario
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.

Use case 3 visualize scenario
Use Case 3 – Visualize scenario 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
Use Case 4 – scenario.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
Use Case 5 – Printing Diagrams scenario.

  • 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
Project Plan scenario.

Cost estimate
Cost Estimate scenario.

  • Basic COCOMO Model

    Effort = 3.2*EAF (Size)^1.05

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

Effort adjustment factor
Effort Adjustment Factor scenario.

  • 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 scenario.

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
Architecture Elaboration Plan scenario.

  • 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
Architecture Elaboration Plan (contd.) scenario.

  • 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
Software Quality Assurance Plan scenario.

  • 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 scenario.

  • 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

Standards practices conventions and metrics
Standards, Practices, Conventions, and Metrics scenario.

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

Reviews and audits
Reviews and Audits scenario.

  • 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
Test and Problem Reporting scenario.

  • 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
Tools, Techniques, and Methodologies scenario.

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

Others scenario.

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

    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.

Deliverables scenario.

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

Deliverables contd
Deliverables (contd.) scenario.

  • Phase III

    • · Component Design

    • · Source Code

    • · Assessment Evaluation

    • · User Manual

    • · Formal Technical Inspection Letters

    • · Project Evaluation