1
2
M.Math(Computer Science), University of Waterloo M.A. (English), York University B.A. (English/Music), University of Waterloo SeniorSoftware Engineer am Software Engineering Institute der Carnegie Mellon University Büchersind z.b. Software Architecture in Practice (2nd Edition 2003) und Evaluating Software Architectures: Methods and Case Studies Über 100 weitere Artikel, thematisch verwandt sind z.b.: The Architecture Tradeoff Analysis Method (1998) Attribute-based Architecture Styles (1999) A basis for Analyzing Software Architecture Analysis Methods (2005) 3
Gregory Abowd wissenschaftlicher Mitarbeiter am Georgia Institute of Technology mittlerweile Professor an der Georgia Tech über 10 Bücher und über 25 weitere Artikel (ebenfallsco-autor bei Software Architectures in Practice, hauptsächlich im Bereich Human Computer Interaction) Len Bass Mitglied des Software Engineering Institutes an der Carnegie Mellon Autor 2er Bücher im Bereich Software Architekturen (ebenfalls Software Architectures in Practice und Documenting Software Architectures) 4
Paul Clements Promovierte an der University Texas at Austin Ehemaliger Mitarbeiter im U.S. Naval Research Laboratory Mitglied des Software Engineering Institutes an der Carnegie Mellon Co-Autor mehrerer Bücher und wissenschaftlicher Arbeiten (Ebenfalls Software Architecture in Practice, EvaluatingSoftware Architectures, Documenting Software Architectures) 5
Der Artikelbeschäftigt sich mit der Problematik Qualitätskriterien (wie zum Beispiel Sicherheit und Portabilität) in einer Architektur zu analysieren Veröffentlicht wurde der Artikel 1996 von der IEEE Computer Society Inhalt: In der Einleitung wird der Lösungansatz kurz vorgestellt: Durch die Einführung verschiedener Szenarien aus Sicht der Anwender und Entwickler soll festgestellt werden wie sich das System in bestimmten Situationen verhält um somit die o.g. Qualitätsmerkmale zu messen. Das ganze nennt sich dann Scenario-Based Architecture Analysis Method Obwohl die komplette Methode darauf ausgelegt ist in frühen Phasen der Anwendungsentwicklung eingesetzt zu werden, wurde sie in der Praxis an laufenden Systemen validiert 6
Warum überhauptszenarien? Um frühzeitig Aussagen über Qualitätsmerkmale wie Modifizierbarkeit, Sicherheit, und Portabilität. Dies steht im Gegensatz zur herkömmlichen Architekturanalyse wo beispielsweise die spätere Performanz oder Wartbarkeit getroffen werden können. Die verschiedenen SAAM Activities werden im weiteren Verlauf der Arbeit genauer vorgestellt. Im ersten Schritt muss eine Architekturbeschreibung des Zielssystems entstehen (z.b. durch UML Komponentendiagramme, Klassendiagramme) Im zweiten Schritt werden die verschiedenen Szenarien entwickelt, die Aufgaben beschreiben, welche das System später unterstützen soll. Dabei sollte aufgenommen werden welche Komponenten verwendet werden, und wer (Rolle des Benutzers) diese Aufgaben durchführt. Im nächsten Schritt wird evaluiert ob ein bestimmtes Szenario durchgeführt werden kann, falls dies nicht der Fall ist sollten die nötigen Veränderungen die an der Architektur notwendig sind aufgelistet werden mit den ungefähren Kosten für die Durchführung der Änderung. Im vierten Schritt wird untersucht, welche Komponenten durch die vorher aufgelisteten Änderungen durch mehr als ein Szenario verändert werden müssen (Szenario Interaktion). Dadurch kann erkannt werden, dass eine bestimmte Komponente in zu vielen Aufgaben mitwirkt, wodurch sich beispielsweise die Modifizierbarkeit der gesamten Architektur verschlechtert. Im letzten Schritt werden die verschiedenen Szenarien nach Wichtigkeit sortiert (anhand des Businessnutzen) und verschiedene 7
Warum überhauptszenarien? Um frühzeitig Aussagen über Qualitätsmerkmale wie Modifizierbarkeit, Sicherheit, und Portabilität. Dies steht im Gegensatz zur herkömmlichen Architekturanalyse wo beispielsweise die spätere Performanz oder Wartbarkeit getroffen werden können. Die verschiedenen SAAM Activities werden im weiteren Verlauf der Arbeit genauer vorgestellt. Im ersten Schritt muss eine Architekturbeschreibung des Zielssystems entstehen (z.b. durch UML Komponentendiagramme, Klassendiagramme) Im zweiten Schritt werden die verschiedenen Szenarien entwickelt, die Aufgaben beschreiben, welche das System später unterstützen soll. Dabei sollte aufgenommen werden welche Komponenten verwendet werden, und wer (Rolle des Benutzers) diese Aufgaben durchführt. Im nächsten Schritt wird evaluiert ob ein bestimmtes Szenario durchgeführt werden kann, falls dies nicht der Fall ist sollten die nötigen Veränderungen die an der Architektur notwendig sind aufgelistet werden mit den ungefähren Kosten für die Durchführung der Änderung. Im vierten Schritt wird untersucht, welche Komponenten durch die vorher aufgelisteten Änderungen durch mehr als ein Szenario verändert werden müssen (Szenario Interaktion). Dadurch kann erkannt werden, dass eine bestimmte Komponente in zu vielen Aufgaben mitwirkt, wodurch sich beispielsweise die Modifizierbarkeit der gesamten Architektur verschlechtert. Im letzten Schritt werden die verschiedenen Szenarien nach Wichtigkeit sortiert (anhand des Businessnutzen) und verschiedene 8
9
SAAMCS Flexibility, ESAAMI Ähnlichwie SAAM, SAAMER Evolution und reusability, ATAM Mehrere Qualitätsmerkmale, ALPSM - Maintainability 10
11
12
13