1 / 18

Open source software architecture recovery Part of the INCO project

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?

dieter-spence
Download Presentation

Open source software architecture recovery Part of the INCO project

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Open source software architecture recoveryPart of the INCO project Ida Hogganvik and Eivind Molstad Supervisors: Marco Torchiano and Letizia Jaccheri NTNU 12.12.02

  2. Project description (parts) • What techniques can be used to build an architectural description from existing software? • What views are relevant in this context? 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 • description of the system according to the views

  3. Background • IEEE 1471: Recommended Practice for Architectural Description of Software-Intensive Systems • Stakeholders • Concerns • Viewpoints • Papers/Books • Software architecture • Architecture recovery • tools, manual methods

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

  5. Xerces2Java 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

  6. Example

  7. Logical view Textual explanation

  8. The generic viewpoints • Logical (RUP) • Deployment (RUP) • Process (RUP) • Use case (RUP) • Build time (SWAG) • Dataflow • Documentation • Test • Conceptual (Siemens)

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

  10. Example

  11. Use case view Textual explanation

  12. Case study 2 - JBoss • EJB Application Server • Open Source • Based on the J2EE specification • Distributed for free • 150,000+ downloads per month

  13. Request webpage Web Browser Web server Response from server or Web container for servlets and JSPs EJB container Application server Services Database “How does a webpage communicate with the database?” (dataflow view)

  14. EJB Container Security JTS / JTA JMS Data Sources Java Server Pages Web container (optional) Remote Management Databases JMX implementation JBOSS modules “How is the logical view of the modules in JBoss?” (logical view)

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

  16. Evaluation • The results • Not evaluated by any external persons • The method proposed in our hypothesis is a possibleway of finding the architecture of open source software.

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

More Related