1 / 26

Software Architecture Completeness Analysis

TU / e Software Architecture Completeness Analysis Interim Presentation Christian Lange Overview TU / e Introduction Software Architecture Analysis Survey Completeness Rules & Metrics Outlook Questions Introduction TU / e “Technische Informatica” TUE since 1998

Mercy
Download Presentation

Software Architecture Completeness Analysis

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. TU/e Software Architecture Completeness Analysis Interim Presentation Christian Lange

  2. Overview TU/e • Introduction • Software Architecture Analysis • Survey • Completeness • Rules & Metrics • Outlook • Questions

  3. Introduction TU/e • “Technische Informatica” TUE since 1998 • Since December 2002 final year project at Océ Technologies (Venlo) • Supervisor Michel Chaudron • Advisor Eric Dortmans (Océ) • Lou Somers

  4. Introduction TU/e • Extension of SAAT • Software Architecture Analysis Tool (Johan Muskens) • Completeness of Architecture • Introduced by Océ architecture specialists

  5. Question / Goal TU/e • What is Software Architecture Completeness ? • Development of techniques • to assess a model’s completeness • to identify “incomplete spots” • (tool supported) • Validation of techniques in practice

  6. SW Architecture TU/e • 4+1 Views of Philippe Kruchten

  7. SW Architecture Analysis TU/e • Maintainability, Extensibility, Testability,… • SAAM, ATAM • Specialist work, qualitative • Metrics, SAAT, other tools • Cohesion, coupling • Automated support • Quantitative • Completeness, Consistency • This project • Automated support • Quantitative Existing New

  8. Survey TU/e • Web-based survey • To get insight in the way practitioners are using the UML for architecture • To investigate practitioners needs • To get feedback on the ideas so far • Published • In newsgroups • Within Océ • Sent to known experts • 20 questions (multiple choice, comments possible) • 2 month, 80 responses (20 Océ, 30 CGEY, 30 other) • Aimed audience

  9. Survey conclusions TU/e • To what degree do you follow the UML standard?

  10. Survey conclusions TU/e • What criteria do you use to stop modelling? Project size

  11. Other survey conclusions TU/e • Logical and Scenario view mostly used • Most practitioners encountered incompleteness problems • Consistency is important • Metrics usage in early stage expected to be useful • Use of dedicated case tools (XMI export)

  12. Completeness TU/e • Intuition: • Has the maturity of the architecture model reached a level, such that we are ready to start implementing? • Definition: • An architecture model is complete if and only if it entirelydescribes and specifies the system that exactly fulfills all requirements and the model contains all necessary information that is needed to implement that desired model

  13. Completeness TU/e • Decomposition A model must necessarily reflect all functional requirements of the desired system Tracing Completeness Syntax Semantics A model must reach a good "score" for the non-functional quality attributes A model must be syntactically correct, i.e. it must be consistent with respect to different views and different levels of abstraction.

  14. Consistency TU/e • Dimensions of consistency • Differs from “completeness” Views Time Abstraction level

  15. Scope of Completeness TU/e

  16. Meta Model TU/e • Logical View • Class diagram • Class interfaces • associations, dependencies, inheritance • State diagram • Scenario View • Message sequence charts • Objects, messages • Use Case diagrams • Use cases, Actors • associations, dependencies, inheritance, instantiations

  17. Meta Model TU/e Subset of Logical and Scenario View

  18. Rules & Metrics TU/e • Size of Use Case

  19. Rules & Metrics TU/e • Dynamicity

  20. Rules & Metrics TU/e • Examples (Rules, 18 so far) • Objects must have a name • Abstract classes should have abstract superclasses • Classes have at most one state diagram • Classes with a high dynamicity have a state diagram • Examples (Metrics, 20 so far) • (shown before)

  21. The tool TU/e XMI representationof model UML representationof model Queries (rules & metrics) HTML output Database

  22. Outlook TU/e • Rules and metrics set • Dependencies •  Rule A   Rule B • #Scenarios = 0  NOT objects need name/type, dynamicity,… • Classification • abstraction level, phase

  23. Outlook TU/e • Case studies for validation • Tool vendor examples, literature examples • Assumed to be complete • Fault injection • Small • Case studies evaluated by Johan • Various domains • Compare results • Real-world projects (Océ, …) • Large projects • Architects available for evaluation, discussion • Subsequent versions • Problem tracking data available • Implemented code available (e.g. compare design with reverse-engineered model)

  24. Ongoing case study TU/e • Context • Controller, embedded system, • Printer / scanner • Size: • 103 Use cases • 135 classes • 109 scenarios

  25. Ongoing case study TU/e • Identified: • oversized use case • 14 scenarios vs. 1 - 5 • 533 messages vs. 3 – 90 • High level scenarios vs. low level logical view • Only actors in MSCs, messages without method relation • (wrong) interpretation of “Actor” • 1 god class vs. 97 empty classes • God class is abstract but subclass of non-abstract class

  26. Questions TU/e ?

More Related