Softwarearchitekturen I Softwareentwicklung mit Komponenten Detlef Streitferdt Technische Universität Ilmenau TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 1
Beispiel: Bibliothekssystem Wir sind ein Softwarehaus, spezialisiert auf objektorientierte Softwareentwicklung. Entwicklung eines modernen Bibliothekssystems für eine Hochschule: Java-basiert über das Internet nutzbar grafische Benutzeroberfläche Komponenten! TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 2
Entwicklung mit Komponenten Testfälle, Anwendung Test, Auslieferung Anforderungsbeschreibung, Analyse Use-Cases, komponentenbasierte Architektur Checklisten für Einkauf, angepasste Komponenten, eigener Quellcode Design, Implementierung TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 3
Phase 1.1: Anforderungsbeschreibung Ziel: Erstellung eines Pflichtenheftes Pflichtenheft Basis für Vertrag zwischen Auftraggeber und -nehmer Was will der Auftraggeber, was muss der Auftragnehmer liefern? Meilensteine: Welche Teilmenge der Funktionalität muss wann fertiggestellt sein? Wie erfolgt die Abnahme der gelieferten Anwendung? Mengengerüste TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 4
Struktur eines Pflichtenheftes Inhaltsverzeichnis 1. Einschränkungen ( Product Constraints ) 1.1. Sinn und Zweck des Systems 1.2.Alle Sta keholder mit Beziehungen 1.3.Nutzer des Produktes 1.4. Einschränkende Anforderungen 1.5. Kodiervorgaben und Definitionen 1.6. Relevante Fakten 1.7. Annahmen 2. Funktionale Anforderungen 2.1. Umfang des Produktes 2.2. Funktionale und Datenanforderungen 3. Nicht-funktionale Anforderungen 3.1. Look and Feel der Anwendung 3.2. Anforderungen an die Benutzbarkeit 3.3. Anforderungen an die Performanz 3.4. Anforderungen an den Betrieb des Systems 3.5. Anforderungen an die Wartbarkeit und die Portabilität 3.6. Anforderungen an die Sicherheit 3.7. Kulturelle und politische Anforderungen 3.8. Gesetzliche Anforderungen 4. Merkmalmodell 4.1.Merkmale 4.2. Varianten 5. Genutzte Komponenten mit Schnittstellen 6. Zusätzliche Punkte ( Project Issues ) 6.1. Offene Punkte 6.2. Neue Probleme 6.3. Arbeitsabläufe (Zeitplanung) 6.4. Migration alter Datenbestände 6.5. Risiken 6.6. Kosten 6.7. Benutzerdokumentation 6.8. Alles, was übrig war... 7. Glossar 8. Literaturverzeichnis TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 5
Personenmodell (Stakeholder mit Beziehungen) Videoprojekt TU-Ilmenau 1 Prozessinformatik 2 2 Doktorand 3 3 3 3 Doktorand Diplomand Diplomand Studienarbeiter Studienarbeiter 4 2 Wiss. Assistent 4 1 5 Uni Mannheim 1 Informatik IV Förderverein 2 1 ist Teil von 2 arbeitet bei 3 wird betreut von 4 hat Interesse an 5 unterstützt 5 Technotrend 2 2 Mitarbeiter Doktorand 4 3 Stakeholder Struktureinheit TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 6
Mittel zur Anforderungsbeschreibung Immer Use-Cases (Anwendungsfälle) Gelegentlich nützlich Aktivitätsdiagramme Klassendiagramme (grob) Sequenzdiagramme (grob) Zustandsdiagramme TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 7
Use-Cases (Anwendungsfälle) Definition A sequence of transactions performed by a system, which yields an observable result of values to a particular actor. Bibliothekssystem Buch suchen Vorbedingungen Durchführung Nachbedingungen Buch suchen Bibliotheksbenutzer TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 8
Varianten in Use-Cases Varianten erhöhen die Wiederverwendbarkeit von Komponenten Bibliothekssystem «extend» Buch suchen Rezension anzeigen Bibliotheksbenutzer Rezension schreiben Beispiel Bibliothekssystem: wissenschaftliche Rezensionen zu Büchern erfassen und anzeigen TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 9
Anforderungskarte Anforderung Nr.: Eindeutige Nummer Dokumentzuordnung: Einordnung in das Spezifikationsdokument (Kapitel) Ereignis/Use Case Nr.: Zuordnung Komponente: Welcher Komponente ist diese Anforderung zugeordnet Variante: Welcher Variante ist diese Anforderung zugeordnet? Beschreibung: Bedeutung: Ursprung: Überprüfung: Ein Satz, der die Anforderung beschreibt. Warum ist diese Anforderung wichtig? Warum soll sie aufgenommen werden? Woher stammt die Anforderung? Wer hat die Anforderung gestellt? Wie kann die Anforderung quantifiziert werden, um sie später zu prüfen? Kundenzufriedenheit: Wie stark ist der Kunde an dieser Anforderung interessiert? Folgen von Unzufriedenheit: Was wäre, wenn die Anforderung nicht realisiert wird? Abhängigkeiten: Andere beeinflusste Anforderungen. Konflikte: Widersprüchliche Anforderungen. Weitere Materialien: Historie: Hinweise auf weitere Informationen zu dieser Anforderung. Jeder, der etwas an der Anforderung verändert, muss sich hier eintragen. TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 10
Aktivitätsdiagramme... beschreiben Ablaufmöglichkeiten eines Systems mit Hilfe von Aktivitäten. Eine Aktivität ist ein einzelner Schritt in einem Ablauf. Sie kann ein oder mehrere ausgehende Transitionen haben, wenn diese durch Bedingungen unterschieden werden. Bibliothekar Signatur des Buches einlesen [keine] Rückgabedatum = heute + 4 Wochen Bibliothekssystem Vorbestellungen prüfen [vorhanden] Hinweis: Verlängerung nicht möglich TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 11
Entwicklung mit Komponenten Testfälle, Anwendung Test, Auslieferung Anforderungsbeschreibung, Analyse Use-Cases, komponentenbasierte Architektur Checklisten für Einkauf, angepasste Komponenten, eigener Quellcode Design, Implementierung TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 12
Phase 1.2: Analyse Ziel: Entwurf der Architektur Architektur Komponenten bzw. Subsysteme externe Schnittstelle der Komponenten Beziehungen der Komponenten untereinander verschiedene Sichten auf das System Die Karawane zieht weiter... TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 13
Sichten (Software-)Architekturen sind komplex Sichten bieten bessere Übersichtlichkeit Jede Sicht betont unterschiedliche Aspekte des Gesamtsystems Das 4+1 - Sichtenmodell: Logische Sicht Implementierungssicht Prozeßsicht Use-Cases Physikalische Sicht TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 14
Sichten der UML Struktur Klassen Objekte Implementierung Komponenten Use-Case Sequenz B e n u t z e r Kollaboration Zustände Aktivitäten Verteilung Verhalten Umfeld TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 15
Wozu? Architekturen liefern wichtige Informationen für alle Projektbeteiligten Architekturen legen Entwurfsentscheidungen fest Organisationsstruktur Qualitätsmerkmale Implementierung Architekturen wiederverwenden Referenzmodelle: Compiler, Datenbanken Systemfamilien/Produktlinien TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 16
Mittel zum Entwurf einer Architektur Techniken des Software-Engineering Zerlegung des Ganzen in immer kleinere Teile Kapselung der Teile Abstraktion/Verallgemeinerung Nutzung von Mustern (Architekturstile) standardisierten Referenzmodellen Beispiel: Bibliothekssystem TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 17
Daten zur Erfassung von Komponenten Art der Komponente Sinn und Zweck der Komponente Schnittstellenbeschreibung Nutzungsbeispiel Parametrierung Integration Testfälle / Testergebniss Leistungsanalyse Source Code Support TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 18
Zusammenfassung Was haben Sie gelernt? Beschreibung von Anforderungen mit Use-Cases und Aktivitätsdiagrammen ( Pflichtenheft) Bestandteile einer Softwarearchitektur erste Techniken zum Entwurf von Architekturen Wie geht s weiter? Architekturmuster (-stile) Bewertung von Architekturen Komponenten und Architekturen TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 19