Transcript presentation

Software Architecture Risk Assessment
(SARA) Tool
Technical Presentation
Final Project - CpE 585, Fall 2006
Ali Bahu
Matthew Madden
James Martin
Outline

Introduction



Implementation





SARA Tool Overview
Project Requirements
Backend
Overview and Documents
Register, Login, Logout, Chat
Help, Demo, Risk Assessment
Summary and Conclusions
Introduction – SARA Tool

Provides software developers the ability to
quantitatively analyze the architectural risk
factors of their designs





Maintainability Risk  Focus of Project
Reliability-Based Risk
Requirements-Based Risk
Currently implemented as a stand-alone java
GUI application
Need for web-based features
Introduction – Project Requirements

Requirements for web-based SARA Tool

Develop a user interface and web service to provide
the following functionality to multiple users









Overview
Demonstration
Risk Assessment
Chat
Documents
Help
Login
Registration
Logout
Implementation – Software Used

Development Tools




User Interface







Eclipse 3.2 - Open Source IDE with Web Tools Plug-in
Apache Tomcat 5.5 Server
MySQL 5.0 database - Data storage
JavaServer Pages (JSP) - scripting
XHTML - Webpage content and markup
Cascading Style Sheets (CSS) - Webpage layout and styling
JavaScript (JS) – menus and page dynamics
Coldbeans Software - Servlet for Chat function
Quadbase Espress Charts
Backend



Java - SARA Tool and several supporting classes
Java Webservices
J2EE Servlets
Backend Implementation



Problems with existing code were encountered!
ICPnewFc.java, ICPnewFa.java,
parserCPSC.java, parserCPSC1.java.
Fields in these classes had the static modifier.
When multiple copies of the program were loaded,
data was overwritten and results were unpredictable.
NullPointerException’s were encountered.
File streams were never closed. This lead to a
memory leak and caused errors after extended use.
This was corrected using try…catch…finally
blocks.
Backend Implementation

Further problems encountered in MyFrame1.java.

Risk assessment code was mixed with GUI code.


There was no way to programmatically access the
tool without modification.
Action listener method was analyzed and dissected
into separate methods for each ‘step’ of the risk
assessment process.
Backend Implementation



…MyFrame1.java. problems continued
File names were hard coded. This prevented
concurrent access. Data was being overwritten by
separate instances of the tool.
This was fixed by ensuring that each user had a
unique ID. The tool code was modified to utilize this
unique identifier when generating intermediate files.
Backend Implementation



…MyFrame1.java. problems continued
Having multiple GUIs loaded on the server
bogged it down and caused poor
performance. Also, numerous debug
statements cluttered the console.
This was fixed by removing nearly all of the
GUI code, and eliminating
System.out.println statements.
Backend Implementation

SARAToolHandler.java





Subclass of MyFrame1.java
All GUI code removed.
All debug statements removed for better performance
on server.
Provides methods for each step of the risk
assessment.
Provide ‘getter’ methods for charts and tables result
Backend Implementation

Results.java






Encapsulates a “result” for each step of the system.
Accepts a StarUML (XML) and ICP (TXT) file as input.
Runs through each step of the risk assessment.
Stores a table and chart for each step.
Each user can have his or her own Results
instance.
Provides for concurrent user access.
Backend Implementation

Chart.java






Subclass of HTTPServlet.
Accepts “step #” as a parameter.
Gets QBChart from Results instance.
Exports chart as a JPEG to the request output
stream.
Charts images are dynamically generated.
They are not stored anywhere on the server.
Backend Implementation

SARAToolUser.java

Represents instance of user once he or she is logged
into the system.

Stores email, and SARA Tool Results.

Provides getter methods for each.
Backend Implementation

AuthUtilities.java



Provides static methods for authenticating user.
For example, to check to see if the user session is
valid (i.e. the user has logged in).
As another example, to verfiy that the inputs for
registration are valid (i.e. email is proper length and
password + confirmation match).
Backend Implementation

Results Tables



Tables for the risk assessment results are simply
accessed via a call to
Result.getResultsTable(Step).
Two dimensional string array is returned.
Easily displayed via JSP.
User Interface Implementation


Designed using XHTML, CSS, and JS via JSP.
User can choose among functions specified on
the main menu
Overview and Documents

Overview


Documents


Provides introduction for users.
Will give links to our documents that we have
completed.
Both are implemented with simple JSP.
Registration


Accepts email, password and password
confirmation via a form.
Submitted to create.jsp which verifies validity
of input, checks for existing matches, and inserts
new user into database table.

Passwords hashed using MD5.

Redirects user to login section.
Login

Accepts email and password via a form.

Submits to auth.jsp.

Checks for match in database table.

On success, creates new user session

On failure, redirects to login page.
Logout

Simple JSP page.

Removes “user” attribute from session.

Invalidates http session.

Redirects to login page.
Chat




Provides user with a way to communicate with
other users Tool through a text message board
JSP page with chat servlet embedded inside an
iframe.
Utilized servlet from Coldbeans Software
(www.servletsuite.com)
Configured in order to blend the transparently
with that of the user interface
Chat

User selects nickname and color for chat
messages.
Chat

User can then chat in a dynamically refreshed
web page.

Not a Java applet.

Uses XHTML with minimal JavaScript.

Allows for private messaging.
Chat

Screenshot of chat session.
Help




Provides the user with information
regarding key topics of the SARA Tool
User can browse help topics via a dynamic
JavaScript menu system.
Also will have search capabilities.
JSP client will access search web service
and display results to user.
Help




Visual Integration into
main site is not
completed yet.
Content for help has been
nearly completed
dTree - Provides tree
outline containing all Help
topics
(www.Destroydrop.com)
Preview here
Demonstration / Risk Assessment

Step 1: User provides inputs*





StarUML models (.xml)
Initial Change Probability (ICP) File (.txt)
For the demo, the file are already provided.
For the actual risk assessment, the user will need to
upload both files.
Next: User chooses among six steps…
Demonstration / Risk Assessment

Step 2: Calculate Change Propagation Metrics

Step 3: Size of Change Metrics

Step 4: Calculate Corrective ICP

Step 5: Calculate Adaptive ICP

Step 6: Calculate Corrective Maintainability Risk

Step 7: Calculate Adaptive Maintainability Risk
Outputs

Charts and Tables





Change Propagation Metrics
Corrective ICP
Adaptive ICP
Corrective Maintainability Risk
Adaptive Maintainability Risk
Chart
SARA Tool Output – Table
Demonstration / Risk Assessment


Demo uses actual runs of the SARA Tool.
Displayed results actually come from running
instance of tool.

User file upload feature not yet complete.

Preview demo here
Summary and Conclusions


Through the described implementation, a webbased SARA Tool has been created that is
capable of handling requests to multiple users
Users have the ability to…







Access the SARA Tool
Request a Demonstration
Use a Searchable Help
Chat with other users
View an Overview Description of the Project
Register
Login/Logout
Questions?
Thank You!