Gliederung B.1. Methodik Dokumentenbasierte Entwicklung. Kontexteinbettung Geschäftsvorfälle Facharchitektur Nutzfälle Schnittstellen

Transkript

1 Block B (Software-Architektur): Methodischer Entwurf Block B (Software-Architektur): Methodischer Entwurf Gliederung B.1 Vorlesung Methoden des Software Engineering Block B Software Architektur Methodischer Entwurf Martin Wirsing Einheit B.1, Einleitung in den Block B Software-Architektur Definition, Gegenstand, Motivation Gliederung und Einbettung in die Vorlesung Teil 1: Methodischer Entwurf Notationen & Konzepte Fallbeispiel Hilfsmittel & Literatur Ausblick auf Teil 2: Systemarchitektur Block B (Software-Architektur): Methodischer Entwurf Software-Architektur - Gegenstand Die klassische Trias der Architektur seit Vitruv. Architekt Lösung, Konzept Venustas Block B (Software-Architektur): Methodischer Entwurf Software-Architektur - Definitionen Architecture is the set of design decisions [] that keeps its implementors and maintainers from exercising needless creativity. Architecture is a framework for change. (D`Souza & Wills, Catalysis) (Tom De Marco) Ingenieur, Entwickler Material, Umsetzung Firmitas Utilitas Klient Anlass, Problem Architecture is defined [] as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, ant the principles governing its design and evolution. (IEEE Architecture Working Group, P1471) Siehe z.b. für weitere Definitionen. Block B (Software-Architektur): Methodischer Entwurf Die Rolle des Software-Architekten Block B (Software-Architektur): Methodischer Entwurf Gliederung Block B kontrolliert-> Klient Nutzer moderiert & vermittelt beauftragt-> <- liefert Architekt <- befragt informiert-> Anbieter (Manager) Entwickler beauftragt-> <- berichtet Rahmen A B C D E F Anforderungen Architektur Formale Methoden Test, Validation, Verifikation Prozeß Web-Engineering Methodischer Entwurf Systemarchitektur Middleware Muster & Komponenten Formale Architektur- Beschreibungssprachen 1

2 Block B (Software-Architektur): Methodischer Entwurf Gliederung B.1 Vorstellung Einleitung in den Block B Software-Architektur Definition, Gegenstand, Motivation Gliederung und Einbettung in die Vorlesung Teil 1: Methodischer Entwurf Notationen & Konzepte Fallbeispiel Hilfsmittel & Literatur Ausblick auf Teil 2: Systemarchitektur Kontexteinbettung Geschäftsvorfälle Nutzfälle Schnittstellen Block B (Software-Architektur): Methodischer Entwurf Methodik Dokumentenbasierte Entwicklung Ein System entsteht und entwickelt sich als eine Menge von Dokumenten: Konzepte, Präsentationen, Testfälle, Code, Drei Dimensionen der Klassifizierung Historie ( Version, Phase ) Granularität ( Ebene ) Perspektive ( Sicht ) Verschiedene überlappende Perspektiven Überlappungen sind Quellen von Inkonsistenzen, aber auch Möglichkeit der Konsistenzprüfung ( Sollbruchstellen ). Überlappungen bieten außerdem Möglichkeiten, von einer Sicht eine andere methodisch abzuleiten ( opportunistisches Vorgehen ). Block B (Software-Architektur): Methodischer Entwurf Rückblick betrachtete Aspekte und Darstellungsmittel Block B (Software-Architektur): Methodischer Entwurf Ebene 0 Kontexteinbettung Kontext Einbettung Quantifizierung GeVo hierarchischer Text GeVo-Diagramm GeVo-Tabelle Aktivitätsdiagramm Struktur Fachliches Klassenmodell Zusammenhänge Objektlebenszyklus Subsysteme & Schnittstellen (fachliche) Interaktionen Stakeholder ( Betroffener ) 10 6 Kunden je 5* /d 5*10 3 /d von 10 3 Call-Center- Agent Leistungserbringer Reise- System 10 5 Amadeus Subsystem Ebene: 0 Phase: Architektur-Entwurf Autor: HS Version: 0.1 Sicht: Kontext Block B (Software-Architektur): Methodischer Entwurf Ebene 0 Kontexteinbettung Block B (Software-Architektur): Methodischer Entwurf Ebene Kunden je 5* /d 5*10 3 /d Leistungserbringer Reise- System 10 5 Amadeus CRM Gruppenreise Einkauf Individualreise Produktdefinition 10 2 von 10 3 Call-Center- Agent Ebene: 0 Phase: Architektur-Entwurf Autor: HS Version: 0.1 Sicht: Kontext Ebene: 1 Phase: Architektur-Entwurf Autor: HS Version: 0.1 Sicht: 2

3 Block B (Software-Architektur): Methodischer Entwurf Ebene 1 Block B (Software-Architektur): Methodischer Entwurf Spezifikation von Ports mit Protokollrollen Individualreise Gruppenreise Einkauf Produktdef. CRM Part Port Connector Im Allgemeinfall: je eine Liste für eingehende und ausgehende Signale plus ein gemeinsamer Zustandsautomat. Im Modell: je ein (UML-)Interface pro Richtung (können optional einen Zustandsautomaten haben). Für Benutzerschnittstellen: Window-Event-Diagramm, Storyboards, GUI-Prototypen. Ebene: 1 Phase: Architektur-Entwurf Autor: HS Version: 0.1 Sicht: Struktur/Schnittstellen Statt UML-Interfaces sind auch XML-DTDs, Corba-IDLs, oder DB- Schemata (z.b. als DDL-Ausdrücke oder ER-Modelle) nützlich. Block B (Software-Architektur): Methodischer Entwurf Block B (Software-Architektur): Methodischer Entwurf Rückblick betrachtete Aspekte und Darstellungsmittel Individualreise Gruppenreise Einkauf Funktionalitäten: Produkt Produktdef. auswählen Angebotsteile bearbeiten Buchung/Umbuchung CRM Stornierung Reiseabwicklung Ebene: 1 Phase: Architektur-Entwurf Autor: HS Version: 0.1 Sicht: Struktur Kontext Einbettung Quantifizierung GeVo hierarchischer Text GeVo-Diagramm GeVo-Tabelle Aktivitätsdiagramm Struktur Fachliches Klassenmodell Zusammenhänge Objektlebenszyklus Subsysteme & Schnittstellen (fachliche) Interaktionen Block B (Software-Architektur): Methodischer Entwurf Ebene 3 Block B (Software-Architektur): Methodischer Entwurf Ebene 3 Geschäftsvorfälle in der + +CRM +Gruppenreise +Individualreise + +In/Exkasso +Produktdefinition +Angebotserstellung +Stornierung +Reiseabwicklung -CRM +Direktmarketing +Kundenpflege +Reklamation +Gruppenreise +Individualreise + +In/Exkasso - Produktdefinition +Reiseerstellung +Katalogerstellung +Einkauf +Kapazitätsplanung Ebene: 1 Phase: Architektur-Entwurf Autor: HS Version: 0.1 Sicht: GeVo-Gruppen 3

4 Block B (Software-Architektur): Methodischer Entwurf Ebene 3 Geschäftsvorfälle in der Block B (Software-Architektur): Methodischer Entwurf Geschäftsvorfälle/Nutzfälle in der +Angebotserstellung +Stornierung +Reiseabwicklung -Angebotserstellung +Reise auswählen +Verfügbarkeit prüfen +Angebot reservieren +Stornierung +Reiseabwicklung Block B (Software-Architektur): Methodischer Entwurf Geschäftsvorfälle/Nutzfälle in der Block B (Software-Architektur): Methodischer Entwurf Geschäftsvorfälle/Nutzfälle in der -Angebotserstellung -Reise auswählen +Termine wählen +Hotelkategorie wählen +Flug wählen +Zusatzangebote wählen +Verfügbarkeit prüfen +Angebot reservieren -Angebot -Reise auswählen +Termine wählen +Hotelkategorie wählen +Saisonkalender anzeigen +Anfangstermin angeben +Endtermin angeben +Termingenauigkeit einstellen +Flug wählen +Zusatzangebote wählen Ebene: 3 Phase: Architektur-Entwurf Autor: HS Version: 0.1 Sicht: GeVo-Verfeinerung Block B (Software-Architektur): Methodischer Entwurf Unterschied Geschäftsvorfall/Nutzfall Geschäftsvorfall überschreitet Systemgrenzen benutzt/enthält Nutzfälle möglicherweise nur teilweise automatisch Nutzfall definiert Systemgrenze kann in GeVos vorkommen automatisch: umfasst keine manuellen Zwischenschritte Block B (Software-Architektur): Methodischer Entwurf Geschäftsvorfälle/Nutzfälle in der Angebotserstellung Reise auswählen Verfügbarkeit prüfen kann (leicht) unterbrochen werden wird erbracht von einer Organisation, umfasst mehrere Systeme & Personen von messbarem Wert oder Kosten, für einen Aktor, von außen sichtbar) läuft atomar in einem Zeitintervall ab wird erbracht von einem System Angebot reservieren white box view black box view Ebene: 3 Phase: Architektur-Entwurf Autor: HS Version: 0.1 Sicht: GeVo-Verfeinerung 4

5 Block B (Software-Architektur): Methodischer Entwurf Geschäftsvorfälle/Nutzfälle in der Angebotserstellung Reise auswählen Hotelkategorie wählen Verfügbarkeit prüfen Angebot reservieren Termin wählen Flug wählen Ebene: 3 Phase: Architektur-Entwurf Autor: HS Version: 0.1 Sicht: GeVo-Verfeinerung Block B (Software-Architektur): Methodischer Entwurf Alternative Szenarios für Geschäftsvorfälle Der Normalfall (Primärszenario): der häufigste oder wichtigste Fall. Ablauf Angebotserstellung Reisebuchung Reiseabwicklung Die Varianten (Sekundärszenarios): alle seltenen und komplizierten Fälle. a) keine Buchung Angebotserstellung b) Stornierung Angebotserstellung Reisebuchung Stornierung c) Reklamation Angebotserstellung Reisebuchung Reiseabwicklung Reklamation Block B (Software-Architektur): Methodischer Entwurf Zusammenfassung alternativer GeVo-Szenarios Block B (Software-Architektur): Methodischer Entwurf Zusammenhang von GeVos mit includes/extends.: GeVo-Abläufe GeVo PRA-001 Reisebuchung Angebotserstellung Angebotserstellung c Reisebuchung Reiseabwicklung a b Stornierung Reklamation Ebene: 3 Phase: Architektur-Entwurf Autor: HS Version: 0.1 Sicht: GeVo-Struktur Reise auswählen auswählen Individualreise auswählen Verfügbarkeit prüfen <<includes>> Flugverfügbarkeit prüfen Angebot reservieren <<extends>> Anzahlung leisten Block B (Software-Architektur): Methodischer Entwurf Extension Points Block B (Software-Architektur): Methodischer Entwurf GeVo-Details in Tabellenschema GeVo PRA-001 Reisebuchung GeVo PRA-001 Reisebuchung Angebot reservieren a) Reservierung länger als 1 Woche b) Kunde will definitiv buchen <<extends>> Anzahlung leisten Kurzbeschreibung Ein Sachbearbeiter im oder Callcenter macht dem Kunden ein Angebot. Der Kunde bucht die Reise und leistet eine Anzahlung. Auslöser Beteiligte Akteure Kunde akzeptiert Angebot 1. Kunde, 2. Sachbearbeiter Vorbedingung Häufigkeit Angebot ist verfügbar ca pro Tag und Vertriebskanal Primärszenario 1. Angebotserstellung 2. Reisebuchung 3. Reiseabwicklung Varianten a) 4. Reklamation b) 3. Storno c) 3. Umbuchung 4. Reiseabwicklung Nachbedingung Referenzen Kapazitätsplanung angepasst - Ergebnis Anmerkungen, offene Punkte Kunde hat Reservierung, - -Details 5

6 Block B (Software-Architektur): Methodischer Entwurf Zusammenfassung Geschäftsvorfälle Definition Jeder GeVo besteht aus vielen Einzelschritten, die maschinell/ manuell von verschiedenen Systemen/Aktoren erbracht werden. Darstellung Die Abläufe und ihre Verfeinerung werden zunächst durch hierarchischen Text, später dann durch Aktivitätsdiagramme festgehalten. Der Zusammenhang der GeVos wird durch GeVo-Diagramme dargestellt, die Details einzelner GeVos werden in einem vorgegebenen Schema tabellarisch angegeben. Herstellung Die Menge der GeVos und ihre Details sind entweder bekannt (Vorwissen, Vorgängersystem, Kunden-Dokumente), oder werden z.b. durch Rollenspiele und Interviews erhoben. Block B (Software-Architektur): Methodischer Entwurf Ableitung von Schnittstellen Ausgangspunkt +Angebotserstellung +Stornierung +Reiseabwicklung -CRM +Direktmarketing +Kundenpflege +Reklamation +Gruppenreise +Individualreise + +In/Exkasso - Produktdefinition +Reiseerstellung +Katalogerstellung +Einkauf +Kapazitätsplanung Block B (Software-Architektur): Methodischer Entwurf Ableitung von Schnittstellen Ausgangspunkt Block B (Software-Architektur): Methodischer Entwurf Ableitung von Schnittstellen Ausgangspunkt Individualreise Einkauf Individualreise Einkauf Gruppenreise Produktdef. CRM Gruppenreise Produktdef. CRM Ebene: 1 Phase: Architektur-Entwurf Autor: HS Version: 0.1 Sicht: Struktur/Schnittstellen Ebene: 1 Phase: Architektur-Entwurf Autor: HS Version: 0.1 Sicht: Struktur/Schnittstellen Block B (Software-Architektur): Methodischer Entwurf Ableitung von Schnittstellen von nach Nutzfallkarte Block B (Software-Architektur): Methodischer Entwurf Alternative: Aktivitätsdiagramme statt Nutzfallkarten.Reisebuchung Reise buchen Produktdef. Preis ermitteln daten einpflegen Lastschrifteinzug Kontodaten ermitteln Ebene: 1 Phase: Architektur-Entwurf Autor: HS Version: 0.1 Sicht: Struktur/Interaktion System-Schnittstellen Daten Anfang Verzweigung Schritt Methoden Ende des Software Engineering (c) 2004, Koch, Störrle, Wirsing, LMU München 6

7 Block B (Software-Architektur): Methodischer Entwurf Rückblick betrachtete Aspekte und Darstellungsmittel Block B (Software-Architektur): Methodischer Entwurf Klassenübersicht Angebot/Buchung/Reise Kontext Einbettung Quantifizierung GeVo hierarchischer Text GeVo-Diagramm GeVo-Tabelle Aktivitätsdiagramm Struktur Fachliches Klassenmodell Zusammenhänge Objektlebenszyklus Subsysteme & Schnittstellen (fachliche) Interaktionen KD PRA Reise Tarif Produkt 1 * Produktteil * * 1 Reise * Reiseteil Reisender + * Flug Unterbringung Verpflegung Transfer Zubringer Mietwagen Extras Ebene: 3 Phase: Fachliche Analyse Autor: HS Version: 0.1 Sicht: Klassen-Details Block B (Software-Architektur): Methodischer Entwurf Objektlebenslauf Angebot/Buchung/Reise OLL PRA Reise reservieren Angebot buchen umbuchen stornieren Buchung abrechnen antreten Reise beenden bearbeiten, löschen verlängern, hochstufen, Extras_buchen Ebene: 3 Phase: Fachliche Analyse Autor: HS Version: 0.1 Sicht: Objekt-Lebenslauf Block B (Software-Architektur): Methodischer Entwurf Angebot/Buchung/Reise KD PRA Reise Angebot + von: Datum + bis: Datum + ab: Ort + preis: Euro + anmerkungen: String + buchen(): Buchung + berechnen(): Euro + ist_verfügbar(): bool + reservieren(frist: Datum): void Buchung + buchungsdatum: Datum + sachbearbeiter: + agentur: + anzahlung: Euro + restforderung: Euro + tickets_verschickt: bool + stornieren(): Angebot + antreten(): Reise + umbuchen(): Buchung + tickets_ausstellen(): void Reise + ist_abgerechnet: bool + hochstufen(): Reise + verlängern() : Reise + beenden(): Reise + reklamieren(): Reise + abrechnen() : void Ebene: 3 Phase: Fachliche Analyse Autor: HS Version: 0.1 Sicht: Klassen-Details Block B (Software-Architektur): Methodischer Entwurf Rückblick betrachtete Aspekte und Darstellungsmittel Kontext Einbettung Quantifizierung GeVo hierarchischer Text GeVo-Diagramm GeVo-Tabelle Aktivitätsdiagramm Struktur Fachliches Klassenmodell Zusammenhänge Objektlebenszyklus Subsysteme & Schnittstellen (fachliche) Interaktionen Block B (Software-Architektur): Methodischer Entwurf Hilfsmittel 1: Repository Problem Ein Repository ist eine Datenbank für semantische komplexe Daten. CASE-Tools haben zwangsläufig ein Repository eingebaut. Dies kann als Datenbank realisiert sein (z.b. Rational Rose, Aonix StP), als XMI-Datei gespeichert werden (z.b. Magic Draw, ArguUML), oder im Code versteckt sein (Together). Oft kann kein Repository benutzt werden. Mögliche Gründe: Es ist keines (auf der richtigen Plattform) vorhanden. Es darf nicht für alle Zwecke/von allen Personen genutzt werden. Es ist aufwendig zu bedienen, und man soll nur mal eben schnell ( Overkill ). Es ist nicht (gut) integriert mit den anderen Werkzeugen. 7

8 Block B (Software-Architektur): Methodischer Entwurf Hilfsmittel 1: Repository Lösung: Primitiv-Repository Vorteile gibt s auf jeder Plattform keinerlei technischer Aufwand, minimale Kosten keine Genehmigung erforderlich Nachteile Vergabe von Identifiern & Zuständen wird nicht automatisch erledigt, dadurch Mehraufwand, und mögliche Inkonsistenzen nebenläufiges Arbeiten schwierig Anzuwenden bei kleinen Projekten / in der Frühphase in technisch rückständigen Umgebungen - d.h. in 70% aller SW- Buden Block B (Software-Architektur): Methodischer Entwurf Hilfsmittel 1: Repository Lösung: Primitiv-Repository Ablagestruktur Projekt Entwicklung Konzepte Werkzeuge Bibliotheken Team Müller, Meier, Schulze, Management Auslieferung Änderungs-Anforderungen Dokumente/Modelle Buchstabe: a, b, c Uhrzeit: hh-mm Datum: yyyy-mm-dd <Name> <Version>.doc Typ Gruppe System lfd. Nr. Beispiele Bib-AUS_GP_007 Block B (Software-Architektur): Methodischer Entwurf Hilfsmittel 2: Glossar Ist von Anfang an zu führen, zu pflegen und zu verwenden! In Excel, Word o.ä. -> Sortierung der Einträge Begriff Synonyme Erklärung(en) Verantw. Status Leser - Natürliche Person, die mit Namen, Geburtsdatum und Adresse im Leserverwaltungssystem erfasst ist. Störrle ok Sollte zentral gepflegt werden z.b. über einheitlich glossar@firma.com 4-Augen-Prinzip (QS) verfügbar im Intranet (-> Knowledge Management) Block B (Software-Architektur): Methodischer Entwurf Hilfsmittel 2: Glossar Zweck & Gütekriterien Standardisierte Sprache erhöht die Konsistenz, und hilft Missverständnisse vermeiden. Technische Prosa darf nicht nur langweilig sein, sie muß es! und bitte: kein Denglisch! Um die Usage-Policy zu updaten muß zuerst das File vom User downgeloadet werden. Weitere Tips bei: Peter Rechenberg: Technisches Schreiben. Hanser, 2002 Block B (Software-Architektur): Methodischer Entwurf Literatur für B.1 Block B (Software-Architektur): Methodischer Entwurf Gliederung B.1 Hofmeister, Nord, Soni: Applied Software Architecture. Addison- Wesley, 2000 Störrle: Models of Software Architecture. Book-on-demand, 2001 Sewell, Sewell: The Software Architect s Profession. Prentice Hall PTR, 2002 Rechenberg: Technisches Schreiben. Hanser, 2002 Mellor, Balcer: Executable UML. Addison-Wesley, 2002 Marshall: Enterprise Modeling with UML. Addison-Wesley, 2000?? Vorstellung Einleitung in den Block B Software-Architektur Definition, Gegenstand, Motivation Gliederung und Einbettung in die Vorlesung Teil 1: Methodischer Entwurf Notationen & Konzepte Fallbeispiel Hilfsmittel & Literatur Ausblick auf Teil 2: Systemarchitektur 8

9 Block B (Software-Architektur): Methodischer Entwurf Ausblick auf Block B Teil 2: Systemarchitektur Rahmen A B C D E F Anforderungen Architektur Formale Methoden Test, Validation, Verifikation Prozeß Web-Engineering Methodischer Entwurf Systemarchitektur Middleware Muster & Komponenten Formale Architektur- Beschreibungssprachen 9