Title: BRUE Behavioral Reverse Engineering in UML as Eclipse Plugin
1BRUE Behavioral Reverse Engineering in UML as
Eclipse Plugin
- MSE Presentation 1
- Sri Raguraman
2Outline
- 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.
4Project Overview (contd.)
5Requirements
Launch BRUE
Run Scenario
View Static Structure
Visualize scenario
View Dynamic behavior
6Use 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.
7Launching BRUE (Screenshot)
BRUE Launch configuration
8Use 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.
9Context menu for project contains options to
start/stop scenario.
10Use 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.
11Use 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.
12Use 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.
13Project Plan
14Cost Estimate
- Basic COCOMO Model
- Effort 3.2EAF (Size)1.05
- Time (in months) 2.5(Effort)0.38
15Effort 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.
16Calculations
- 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
17Architecture 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.
18Architecture 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).
19Software 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
20Documentation
-
- 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
21Standards, 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.
22Reviews 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.
23Test 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.
24Tools, 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
25Others
- 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.
26Deliverables
- 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
27Deliverables (contd.)
Phase III Component Design Source Code
Assessment Evaluation User Manual Formal
Technical Inspection Letters Project Evaluation
28Prototype Demonstration
29Questions/Comments