A) Technische Einflussfaktoren B) Organisatorische Einflussfaktoren
Werbung
C) Review, Heuristiken, Metriken, Prototypen A) Technische Einflussfaktoren System Requirements Specification Architektur erstellen D) Architektur Dokument Architektur prüfen B) Organisatorische Einflussfaktoren 1 Einflussfaktoren zu A) Technische Einflussfaktoren ­ Werkzeuge, Programmiersprache ­ Architekturstile ­ ... zu B) Organisatorische Einflussfaktoren ­ Zeit ­ Budget ­ Team: Qualifikation, Anzahl ­ "Make or Buy", Möglichkeit zur Unterbeauftragung ­ Risiko durch Produkt (z.B. Kernkraftwerk) für Projekt Wartbarkeit Mit zusätzlichen teuren externen Mitarbeitern, kann man ggf. Zeit sparen Zeit Risiko Stored Procedures sind schnell aber schädigen die Wartbarkeit Einfachheit Geld Performanz Eine einfache Architektur hat keine Möglichkeiten für Erweiterungen vorgesehen Flexibilität 2 ad C) Prüfung von Architekturen i) mit Reviews ­ Beteiligte: Architekt, SRS­Verantwortlicher, Entwickler, (Komponenten­/Integrations)­Tester ­ Testaspekte > Berücksichtigung aller Systemanforderungen > Berücksichtigung aller Einflussfaktoren > Umsetzbarkeit > Verständlichkeit ­ Güte der Architektur: Weak Coupling und Strong Cohesion Ein "weak coupling" würde man zerstören durch - Breite Schnittstellen > viele public Methoden > Methoden mit vielen Übergabeparametern - Vererbung über Komponentengrenzen hinweg - Fehlerwerfen über Komponentengrenzen hinweg - Zyklische Abhängigkeit der Komponenten Vollständigkeit mit Traceability­Matrix dokumentieren Anforderungen aus SRS SRS_LZ_001 (auf Windows und Mac laufen) Beschreibung, Stichwort zur Umsetzung in Architektur Programmiersprache: Java 3 ii) Heuristiken Sichtbarkeit von Klassen, Methoden, Variablen einschränken (private, ...) Zerlegt in Komponenten? durchgängige Entwurfsentscheidung 4 Durchgängige (integre) Architektur Verletzung der Integrität 5 YAGNI You ain't gonna need it 6 iii) Prüfung mit Metriken z.B. mit dem Distanzmaß instabil stabil Instabilität konkret abstrakt Distanzmaß Abstraktheit 7 8 iv) Validieren mit Prototypen Alle Stakeholder-Anforderungen erfüllt? Alle Systemanforderungen (insbesondere Performanz und Effizienz betreffen) erfüllt? 9 techn. + org. Einflussfaktoren siehe arc42.de ad D) Architekturdokument Ein Architekturdokument enthält üblicherweise vier Sichten 1) Kontextsicht: Grenzen und Einbettung des Systems und damit Schnittstellen erkennen (müsste aus SRS folgen) (Kontextdiagramm) 2) Statische Sicht/Baustein­Sicht: Internen hierarchischer Aufbau des Systems aus Komponenten und Subkomponenten erkennen (Klasendiagramme, Komponentendiagramme) 3) Dynamische Sicht: Welche Bausteine rufen welche anderen in welcher Reihenfolge auf (Sequenzdiagramme), mit welcher "Logik" laufen diese ab (Aktivitätsdiagramm) 4) Verteilungssicht: Beschreiben welche Artefakte es gibt, auf welcher physikalischen Infrastruktur dies Laufen (Deploymentdiagramme) "Cross cutting concerns" - Persistenz - Fehlerbehandlung - Logging - Authorisierung - ... 10 11 ad 1.) Kontextsicht Zur Erinnerung: Alle Schnittstellen beschreiben - Nutzer-System-Schnittstellen - System-System-Schnittstellen (4 IO-Ebenen) (nicht sichtbar: Laufzeitumgebung) 12 ad 2) Bausteinsicht typische Diagramme: Komponenten und Klassendiagramme UML 1.0 Elemente eines Komponentendiagramms: ­ Komponenten ­ Schnittstellen (Lollipop) ­ Port ­ Beziehung (uses) ­ Klassen (sind auch erlaubt) UML 2.x Oracle IDB := SQL, Connection 13 Beispiele für Schnittstellen ­ Methodenaufruf: API der Komponente > Methoden mit Name, Übergabe­ und Rückgabeparametern > Nach außen sichtbares Verhalten der Komponente (auch im Fehlerfall) (z.B. Rückgabeparameter, Fehler, die geworfen werden, ...) (Komponenten aus Blackbox­Sicht beschreiben) ­ Dateischnittstelle ­ Webservice ­ ... Falls keine API: Immer alle IO­Ebenen bedenken 14 ad 3.) Dynamische Sicht Sequenzdiagramme synchroner Aufruf asynchroner Aufruf Unbekannter Sender 15 Aktivitätsdiagramme Parallelisierungsknoten Synchronisationsknoten AND Signale: Senden bzw. empfangen an/von alle(n) 16 Sonderfall Objektknoten Modellierung von Funktionen, nicht von Daten Input = Output Input (hier Laborwert) muss zu Output (hier Hämoglobin) passen, d.h. muss allgemeiner sein 17 ad 4.) Verteilungssicht Notationselemente ­ Knoten / Node ­ Artefakte / Dateien ­ Verteilungsbeziehung ­ Kommunikationsbeziehungen Verschiedene Stereotypen - artifact (das allgemeinste) - file - document - source - library - executable 18 19
