Brue behavioral reverse engineering in uml as eclipse plugin
This presentation is the property of its rightful owner.
Sponsored Links
1 / 29

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


  • 79 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

BRUE Behavioral Reverse Engineering in UML as Eclipse Plugin

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


Outline

Outline

  • Project Overview

  • Requirements

  • Project Plan

  • Cost Estimation

  • Architecture Elaboration Plan

  • Software Quality Assurance Plan

  • Prototype Demo

  • Questions/Comments


Project overview

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.


Project overview contd

Project Overview (contd.)


Requirements

Requirements

Launch BRUE

Run Scenario

View

Static Structure

Visualize scenario

View

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.


Brue behavioral reverse engineering in uml as eclipse plugin

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


Use case 3 visualize 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

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

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

Project Plan


Cost estimate

Cost Estimate

  • Basic COCOMO Model

    Effort = 3.2*EAF (Size)^1.05

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


Effort adjustment factor

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

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

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

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

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

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

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.


Reviews and audits

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

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

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


Others

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.


Deliverables

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


Deliverables contd

Deliverables (contd.)

  • Phase III

    • · Component Design

    • · Source Code

    • · Assessment Evaluation

    • · User Manual

    • · Formal Technical Inspection Letters

    • · Project Evaluation


Prototype demonstration

Prototype Demonstration


Questions comments

Questions/Comments


  • Login