1. 1 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Software Architecture Completeness Analysis Interim Presentation Christian Lange TU/e

2. 2 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Overview l Introduction l Software Architecture Analysis l Survey l Completeness l Rules & Metrics l Outlook l Questions TU/e

3. 3 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Introduction l “Technische Informatica” TUE since 1998 l Since December 2002 final year project at Océ Technologies (Venlo) l Supervisor Michel Chaudron l Advisor Eric Dortmans (Océ) l Lou Somers TU/e

4. 4 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Introduction l Extension of SAAT l Software Architecture Analysis Tool (Johan Muskens) l Completeness of Architecture l Introduced by Océ architecture specialists TU/e

5. 5 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Question / Goal l What is Software Architecture Completeness ? l Development of techniques l to assess a model’s completeness l to identify “incomplete spots” l (tool supported) l Validation of techniques in practice TU/e

6. 6 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 SW Architecture l 4+1 Views of Philippe Kruchten TU/e

7. 7 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 SW Architecture Analysis l Maintainability, Extensibility, Testability,… l SAAM, ATAM lSpecialist work, qualitative l Metrics, SAAT, other tools lCohesion, coupling lAutomated support lQuantitative l Completeness, Consistency l This project lAutomated support lQuantitative TU/e Existing New

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

9. 9 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Survey conclusions l To what degree do you follow the UML standard? TU/e

10. 10 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Survey conclusions l What criteria do you use to stop modelling? TU/e Project size

11. 11 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Other survey conclusions l Logical and Scenario view mostly used l Most practitioners encountered incompleteness problems l Consistency is important l Metrics usage in early stage expected to be useful l Use of dedicated case tools (XMI export) TU/e

12. 12 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Completeness l Intuition: l Has the maturity of the architecture model reached a level, such that we are ready to start implementing? l Definition: l An architecture model is complete if and only if it entirely describes and specifies the system that exactly fulfills all requirements and the model contains all necessary information that is needed to implement that desired model TU/e

13. 13 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Completeness l Decomposition TU/e Tracing SemanticsSyntax Completeness A model must be syntactically correct, i.e. it must be consistent with respect to different views and different levels of abstraction. A model must reach a good "score" for the non- functional quality attributes A model must necessarily reflect all functional requirements of the desired system

14. 14 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Consistency l Dimensions of consistency l Differs from “completeness” TU/e Time Views Abstraction level

15. 15 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Scope of Completeness TU/e

16. 16 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Meta Model l Logical View l Class diagram l Class interfaces l associations, dependencies, inheritance l State diagram l Scenario View l Message sequence charts l Objects, messages l Use Case diagrams l Use cases, Actors l associations, dependencies, inheritance, instantiations TU/e

17. 17 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Meta Model Subset of Logical and Scenario View TU/e

18. 18 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Rules & Metrics l Size of Use Case TU/e

19. 19 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Rules & Metrics l Dynamicity TU/e

20. 20 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Rules & Metrics l Examples (Rules, 18 so far) l Objects must have a name l Abstract classes should have abstract superclasses l Classes have at most one state diagram l Classes with a high dynamicity have a state diagram l Examples (Metrics, 20 so far) l (shown before) TU/e

21. 21 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 The tool TU/e Queries (rules & metrics) Database XMI representation of model UML representation of model HTML output

22. 22 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Outlook l Rules and metrics set l Dependencies l  Rule A   Rule B l #Scenarios = 0  NOT objects need name/type, dynamicity,… l Classification l abstraction level, phase TU/e RequirementsAnalysisDesignImplementation Rule AXX Rule BXXX Rule CX Rule DXXXX

23. 23 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Outlook l Case studies for validation l Tool vendor examples, literature examples lAssumed to be complete lFault injection lSmall l Case studies evaluated by Johan lVarious domains lCompare results l Real-world projects (Océ, …) lLarge projects lArchitects available for evaluation, discussion lSubsequent versions lProblem tracking data available lImplemented code available (e.g. compare design with reverse- engineered model) TU/e

24. 24 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Ongoing case study l Context l Controller, embedded system, l Printer / scanner l Size: l 103 Use cases l 135 classes l 109 scenarios TU/e

25. 25 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Ongoing case study l Identified: l oversized use case l14 scenarios vs. 1 - 5 l533 messages vs. 3 – 90 l High level scenarios vs. low level logical view lOnly actors in MSCs, messages without method relation l (wrong) interpretation of “Actor” l 1 god class vs. 97 empty classes l God class is abstract but subclass of non- abstract class TU/e

26. 26 Software Architecture Completeness Analysis Christian LangeEindhoven, 6-6-03 Questions ? TU/e