Transcript Lysbilde 1

Open source software
architecture recovery
Part of the INCO project
Ida Hogganvik and Eivind Molstad
Supervisors: Marco Torchiano and Letizia Jaccheri
NTNU 12.12.02
Project description (parts)


What techniques can be used to build an
architectural description from existing
software?
What views are relevant in this context?
3.
This work try to answer this questions by analyzing open
source products in order to recover their architecture. The
main steps of this analysis are:
identification of stakeholders
definition of stakeholder concerns
definition of architectural views
4.
description of the system according to the views
1.
2.
Background

IEEE 1471: Recommended Practice for
Architectural Description of SoftwareIntensive Systems
 Stakeholders
 Concerns
 Viewpoints

Papers/Books
 Software
architecture
 Architecture recovery

tools, manual methods
Accomplishment

Project description
 initial

hypothesis
Xerces case study
 Generic
stakeholders, concerns and
viewpoints
Refined hypothesis
 2 case studies; Jetty and JBoss

 Specific
stakeholders, concerns and views.
Xerces2 Java Parser 2.1.0




XML parser
OSS – Apache project
DOM/SAX
We used Xerces to find generic stakeholders:
 Acquirer (software manager)
 System administrator
 User
 Developer/Maintainer/Tester
 Interest groups
Example
Stakeholder
Acquirer
Concern
ga-01
What are the main features
provided by the system?
Use case
ga-02
How are the features of the
system achieved?
Dataflow
Conceptual
ga-03
What hardware does the product
require?
Deployment
ga-04
What software does the product
require?
Deployment
ga-05
How is the support service for
the product?Concern
Documentation
UseViewpoint
case
gs-01
What hardware does the product
require?
Deployment
gs-02
What software does the product
require?
Deployment
gs-03
How to build and install the
product?
Deployment
Build-time
gs-04
How do the processes of the
system interact?
Process
Stakeholder
System
administrator
Viewpoint
Logical view
Textual explanation
The generic viewpoints









Logical (RUP)
Deployment (RUP)
Process (RUP)
Use case (RUP)
Build time (SWAG)
Dataflow
Documentation
Test
Conceptual (Siemens)
Case study 1 - Jetty Web Server
Open Source HTTP Server and Servlet
container developed using Java
 Light weight, high performance,
embeddable, extensible and flexible
 Available on all Java supported platforms
 Can be used at two levels; as the core
HTTP server and as the complete Jetty
server.

Example
Stakeholder
Concern
sa-01
How are the different security issues for
web servers handled by Jetty?
Security
sa-02
How to integrate Jetty with a firewall?
Deployment
System administrator
Stakeholder
Web administrator
Viewpoint
Concern
Viewpoint
wa-01
How is the performance of Jetty?
Performance
wa-02
How does Jetty handle simultaneously
connections?
Process
wa-03
How are different web technologies
supported by Jetty?
Logical
Documentation
wa-04
How to publish web components (e.g.
Servlets, JSP, web applications and
html) on Jetty?
Web component
deployment
wa-05
How does Jetty communicate with a
database?
Documentation
wa-06
How to administrate Jetty (start, stop)?
Use case
Documentation
Use case view
Textual explanation
Case study 2 - JBoss
EJB Application Server
 Open Source
 Based on the J2EE specification
 Distributed for free
 150,000+ downloads per month

Stakeholder
GENERIC
Developer
Maintainer
Tester
SPECIFIC
Web Developer
Concerns
Views
How is the source code structured?
Logical view
What functionality does the product
offer?
Use case view
Which technologies are used?
Conceptual view
How is the support service for the
product?
Documentation
view
How does a webpage communicate
with the database?
Dataflow
How is the logical view of the modules
in JBoss?
Logical
“How does a webpage communicate with the
database?” (dataflow view)
Request webpage
Web
Browser
Web server
Response from
server
or
Web container
for servlets and
JSPs
EJB container
Application server
Services
Database
“How is the logical view of the modules in JBoss?”
(logical view)
EJB Container
Security
JTS / JTA
JMS
Data Sources
Java Server
Pages
Web container
(optional)
Remote
Management
Databases
JMX implementation
JBOSS modules
Discussion

A weakness with our method:
 Lack
of verifying both the finding of
stakeholders, and especially the finding of the
stakeholders’ concerns.

A strength about our method:
 The
focus on stakeholders and the fact that
different stakeholders may regard different
elements of the system as important.
Evaluation

The results
 Not
evaluated by any external persons
 The method proposed in our hypothesis is a
possible way of finding the architecture of
open source software.
Conclusion

Our main findings:
 A hypothesis
describing a lightweight
methodology to express the architecture of an
open source system based on views.
 A list of generic stakeholders, concerns and
architectural viewpoints, selected from a set
of viewpoint definitions which we found useful.
 The architecture of two open source products