Ziele und Tätigkeiten von Architekten

Transkript

1 Ziele und Tätigkeiten von Architekten Definition Software Architektur o A software architecture provides a model of a whole software system that is composed of internal behavioral units (i.e. components) and their interaction, at a certain level of abstraction. All postulated requirements that are relevant to the later construction of the system have to be incorporated in this model. o Eine Softwarearchitektur besteht aus einer Menge von Komponenten und deren Beziehungen untereinander Ziele von Architekten Aufgabe in Komponenten und handhabbare Teilaufgaben zerlegen Den Entwicklern Arbeitsanweisungen / Vorgaben geben Lösung konzipieren, die der SRS und den Kriterien der ISO entspricht Eine Lösung in "Time & Budget" ermöglichen Mrz 23 07:56 1

2 Output: Ergebnis der Architekturphase Ergebnis sind ein oder mehrere Dokumente mit folgenden Inhalten Übersicht über Kontext z.b. mit Kontextdiagramm (Wiederholung SRS) Beschreibung einer Grobarchitektur > Komponentendiagramm > Beschreibung der Schnittstellen aller Komponenten z.b. als API Beschreibung oder als WSDL > Sequenzdiagramm, Aktivitätsdiagramme usw. Beschreibung der Feinarchitektur > Komponentendiagramm oder / und Klassendiagramme Verteilungsdiagramme Beschreibung von Technologien wie Programmiersprachen "Cross Cutting Concerns" (Querschnittsaspekte): Persistenz, Logging, Fehlerbehandlung, Nebenläufigkeit V Modell: Spezifikation der Integrationstests Projektplan Mrz 23 08:13 2

3 Weshalb so viele Diagramme? Auch in der Bauarchitektur nutzt man verschiedene Sichten (d.h. Pläne) z.b. für Installation, Elektrik, Inneneinrichtung usw. Mrz 23 08:21 3

4 Was zeichnet einen guten Architekten aus? Gute Architektur Wartbarkeit Erfüllt Q Eigenschaften gemäß ISO Erfüllt die Anforderungen (SRS) Gute Dokumentation der Architektur nachvollziehbar, verständlich vollständig widerspruchsfrei Mrz 23 08:27 4

5 Eine wartbare Architektur... ist komponentenorientiert und zeichnet sich aus eine schwache Kopplung zwischen den Komponenten ("weak coupling") und einem starken Zusammenhalt innerhalb der Komponenten ("strong cohesion") Tipps, wie man eine schwache Kopplung zerstören kann Keine Interfaces, sondern gegen konkrete Implementierung programmieren Vererbung über Komponentengrenzen hinweg Zyklische Abhängigkeiten der Komponenten Viele öffentliche Methoden Viele Übergabeparameter Fehler über Komponentengrenzen hinweg werfen... Bitte so nicht! Mrz 23 08:34 5

6 Der Architekturprozess A) Organisatorische Rahmenbedingungen C) Metriken Prototypen, Reviews, Heuristiken SRS Architektur modellieren D) SW Architekur C) Architektur prüfen iterativer Prozess B) Technische Rahmenbedingungen Mrz 23 08:39 6

7 ad A) organisatorische Rahmenbedingungen Budget Zeit Ressourcen (Personen mit Anzahl und Fähigkeiten) gesetzliche Anforderungen (=> sollten eigentlich in SRS stehen) Möglichkeit zur Unterbeauftragung Lizenzrecht ad B) technische Rahmenbedingungen Werkzeuge Programmiersprachen bestehende Systeme Mrz 23 08:46 7

8 Sich widersprechende Einflussfaktoren, Rahmenbedingungen Performanz Zeit Budget Risiko Ressourcen Verbrauch Wartbarkeit Stored Procedures erhöhen Performanz und schädigen Wartbarkeit Sehr gute Entwickler sind oft teurer Abhängigkeit von wenigen Top Entwicklern Ein guter Architekt ist nicht nur ein guter Techniker, sondern ein guter Moderator, Projektplaner und Kommunikator Mrz 23 08:47 8

9 zu C) Prüfen (validieren) von Architekturen i) Prüfen mit Metriken z.b. "Distanzmaß" instabil konkret stabil Interfaces, abstrakt Instabilität Distanzmaß Java: JDepend Abstraktheit Mrz 23 09:09 9

10 Bestimmen von Metriken mit Werkzeugen Mrz 23 09:18 10

11 ii) Prüfen mit Prototypen Vertikale Prototypen, um Performanz und Effizienz zu prüfen Mrz 23 09:16 11

12 iii) Validieren mit Review Prüfen durch Dritte z.b. auf Verständlich alle Anforderungen in SRS berücksichtigt (Traceability) Überstimmung mit Heuristiken (z.b. 7 +/ 2 Komponenten pro Baustein Ebene) Mrz 23 09:24 12