Bsp CRM: Der Nutzer muss am System alle Kunden erkennen können, die besonderes wahrscheinlich ein Produkt kaufen werden.

Transkript

1 Stakeholder Anforderungen Nutzungsanforderungen Bsp CRM: Der Nutzer muss am System alle Kunden erkennen können, die besonderes wahrscheinlich ein Produkt kaufen werden. Das System muss alle Kunden, die..., in Liste in 12pt Software Requirements SpecificationSchriftart (Arial, schwarz) 2px vom linken Rand anzeigen (=> Mockup + Style Guides) Grobarchitektur Feinarchitektur 1

2 Fortsetzung letzte Stunde... OUTPUT: Das Ergebnis der Architekturphase sind ein oder mehrere Dokumente Beschreibung der Grobarchitektur > Komponentendiagramm > Sequenzdiagramm, Aktivitätsdiagramme > Verteilungsdiagramme Beschreibung der Feinarchitektur > Komponenten, Package, Klassendiagramm (statisch) > Sequenz und Aktivitätsdiagramme Beschreibung von > Technologien: Programmiersprache, Bibliotheken > Werkzeugen: IDE, Build Management, Versionsmanagement, Projektmanagement, Testwerkzeuge "Querschnittsaspekte", "Cross Cutting Concerns" > Persistenz > Logging > Fehlerbehandlung Zeitplan verschiedene Sichten Ein großer Teil der Wertschöpfung bei der Software Entwicklung findet bei der Architektur d.h. beim/in Dokumenten statt und nicht (nur) beim Kodieren! 2

3 Auch in der Bauarchitektur nutzt man verschiedene Sichten d.h. Pläne um alles dazustellen (Grundriss, Installation, Innenrichtung) 3

4 SW Bau Input SRS eher Stakeholder Anforderungen Tätigkeiten Randbedingungen Typen von Architekten SRS prüfen Erstellt Bauplan Technologien auswählen Entwickler kontrollieren Software Architektur, System Architektur neue Disziplin, wenig Spezialisierung Anforderungen erheben (sowohl Stakeholder als auch System Anforderungen), Baupläne erstellen Technologien auswählen Arbeiter kontrollieren Städteplaner, Hoch /Tiefbauarchitet en, Innenarchitekten altes, bekanntes Berufsbild 4

5 Eine gute Architektur: ist umsetzbar und beschreibt die endgültige/wirkliche Architektur setzt alle Anforderungen um (SRS) ist verständlich ist wartbar > weak coupling der Komponenten > strong cohesion innerhalb der Komponenten Wie man eine gute Architektur kaputt macht und Komponenten stark koppelt - Viele Klassen aus anderem Package verwenden (alle Klassen/Methoden public) - Über Komponentengrenzen vererben - Methoden mit vielen Übergabeparametern - Fehler über Komponentengrenzen werfen

6 6

7 A) Technische Einflussfaktoren C) Review, Heuristiken, Metriken, Prototypen System Requirements Specification Architektur erstellen D) Architektur Dokument Architektur prüfen B) Organisatorische Einflussfaktoren 7

8 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 Einfachheit Zeit Wartbarkeit Risiko Geld Mit zusätzlichen teuren externen Mitarbeitern, kann man ggf. Zeit sparen Stored Procedures sind schnell aber schädigen die Wartbarkeit Eine einfache Architektur hat keine Möglichkeiten für Erweiterungen vorgesehen Performanz Flexibilität 8

9 ad C) Prüfung von Architekturen i) mit Reviews Beteiligte: Architekt, SRS Verantwortlicher, Entwickler, (Komponenten /Integrations) Tester Testaspekte > Berücksichtigung aller Systemanforderunge > Berücksichtigung aller Einflussfaktoren > Umsetzbarkeit > Verständlichkeit ii) Heuristiken Sichtbarkeit von Klassen, Methoden, Variablen einschränken (private,...) Zerlegt in Komponenten? durchgängige Entwurfsentscheidung 9

10 Durchgängige (integre) Architektur Verletzung der Integrität 10

11 YAGNI You ain't gonna need it 11

12 iii) Prüfung mit Metriken z.b. mit dem Distanzmaß stabil abstrakt Instabilität instabil konkret Distanzmaß Abstraktheit 12