Vorlesung Softwaretechnologie Wintersemester este 2008 R O O T S Kapitel 4 Requirements Engineering
Kontext Bisher: Grundlegende Werkzeuge Praktische Grundlagen (SVN, Eclipse) UML Übersicht Nun: Arbeitsabläufe (Aktivitäten / Workflows) Anforderungserhebung Entwurf... Testen Später: Prozessmodelle Organisation des Projektes Wann, wie viel von welchem Workflow? 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-2 R O O T S
Aktivitäten bei der Softwareentwicklung ( Workflows Workflows ) Requirements Engineering Anforderungs- Anforderungs- erhebung analyse System Object Implemen- Testen Design Design tation Use Case Model ausgedrückt als strukturiert durch realisiert durch implementiert von verifiziert durch class... class... class...? class...? Domain Object Model Analysis Model Subsysteme Implementa- tion Domain Objects Quell Code Test Fälle * Die erzeugten dynamischen Modelle (und Andere) sind hier aus Platzgründen nicht explizit dargestellt.
Vorlesung Softwaretechnologie Kapitel 4: Anforderungserhebung odeu ebu gund -analyse a R O O T S Requirements Engineering Was und warum? Motivation und Definition
Können Sie so etwas bauen? Widersprüchliche Anforderungen 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-5 R O O T S
Was ist das? Mehrdeutige Anforderungen 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-6 R O O T S
Mögliches Objektmodell: Inuit Iglo beleuchtung eingang betrete() verlasse() lebt_in Inuit groesse anziehen() laecheln() schlafen() 2 Schuh groesse farbe typ anziehen() Mantel groesse farbe typ anziehen() 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-7 R O O T S
Genauso mögliches Objektmodell: Kopf haare Kopf anziehen() laecheln() schlafen() Gesicht nase laecheln() augenzu() 2 Ohr groesse hoehr() Mund zahn groesse oeffnen() sprechen() 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-8 R O O T S
Objektmodell aus der Sicht des Künstlers Bild Sicht 1 Sicht 2 Bild einer Skulptur Bild eines Inuit Auge Nase Mund Hand Bein Jacke 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-9 R O O T S
Bestimmen der Grenzen des Systems: Was siehst Du? Unscharfe Anforderungen 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-10 R O O T S
Was ist Requirements Engineering (RE)? Requirements Engineering Ziele Kennen lernen der Anwendungsdomäne d Identifikation von Konzepten, Beziehungen, grundlegendem Verhalten Bestimmung der Anforderungen an das System Identifikation der Geschäftsprozesse, die das System unterstützen soll Identifikation der Funktionen die das System dafür bieten soll Das Ganze geschieht auf zwei Ebenen, aus denen sich zwei verschiedene "Workflows" des RE-Prozesses ergeben: Anforderungserhebung ( Requirements Elicitation ): Definition des Systems in einer Form, die Kunden und Entwickler verstehen Anforderungsanalyse ( Requirements Analysis ) Technische Spezifikation des Systems in einer für die Entwickler verständlichen und handhabbaren Form. 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-11 R O O T S
Der Requirements Engineering Prozess Problem stellung Grundlage für Requirements Elicitation Workflow Voraussetzung für führt zu Verfeinerung von Requirement Analysis Workflow erzeugt erzeugt Requirement Specification : Model Analysis Model : Model Anforderungen Dynamisches Modell, Objekt Modell benutzt natürliche Sprache (abgeleitet von der Problemstellung) Beide fokussieren auf die Anforderungen aus der Sicht der Anwender des Systems benutzt formale oder semi-formale Notation (z.b. UML) Eindeutigkeit, Korrektheit, Vollständigkeit Konsistenz, Machbarkeit
Anforderungen: Verschiedene Sichten BenutzerIn Produktqualitäten Zuverlässigkeit Effizienz Benutzerfreundlichkeit Externe Sicht Prozessqualitäten EntwicklerIn Verifizierbarkeit i it Wartbarkeit Portabilität Erweiterbarkeit Sicht Interne Produktivität Pünktlichkeit Kontrollierbarkeit ManagerIn
Der Anforderungserhebungsprozess: Erhebungsstufen Ziele festlegen Hintergrundanalyse Wissen organisieren Anforderungen sammeln Geschäftsziele Organizations Struktur Akteure identifizieren Anforderungen der Anwender Probleme Anwendungsdomäne Ziele gewichten Fachliche Anforderungen existierende Systeme Fachwissen filtern Systemgrenzen Organisatorische Anforderungen Zielsetzung: Unternehmensziele identifizieren: Warum wird das System gebraucht Hintergrundanalyse: Sammeln und verstehen von Hintergrundinformationen über das System 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-15 R O O T S
Der Anforderungserhebungsprozess: Erhebungsstufen Ziele festlegen Hintergrundanalyse Wissen organisieren Anforderungen sammeln Geschäftsziele Organizations Struktur Akteure identifizieren Anforderungen der Anwender Probleme Anwendungsdomäne Ziele gewichten Fachliche Anforderungen existierende Systeme Fachwissen filtern Systemgrenzen Organisatorische Anforderungen Wissensorganisation: Organisation, Gewichtung und Zuordnung der Daten die in den vorherigen Phasen gesammelt wurden Anforderungen der Anwender sammeln: Die Nutzer des Systems mit einbinden um deren Anforderungen zu erfahren 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-16 R O O T S
Anforderungsanalyse und -verhandlung: Analyse überprüfen Notwendigkeits- prüfung Anforderungsanalyse Konsistenz- und Vollständigkeitsprüfung Machbarkeitsprüfung unnötige Anforderungen widersprüchliche und unvollständige Anforderungen Nicht-machbare Anforderungen Notwendigkeitsprüfung Einige Anforderungen tragen möglicherweise nicht zu den Geschäftszielen der Firma bei oder betreffen das geplante System nicht Konsistenz- und dvollständigkeitsprüfung it Überkreuzprüfung der Konsistenz und der Vollständigkeit (keine Widersprüche, keine fehlenden Dienst und Einschränkungen übersehen) Machbarkeitsprüfung Budget und Zeitplan einhaltbar
Anforderungsanalyse und -verhandlung: Analyse überprüfen Notwendigkeits- prüfung Anforderungsanalyse Konsistenz- und Vollständigkeitsprüfung Machbarkeitsprüfung unnötige Anforderungen widersprüchliche und unvollständige Anforderungen Nicht-machbare Anforderungen Prioritätensetzung ität t Anforderungsverhandlung Anforderungs- diskussion Anforderungs- vereinbarung Anforderungsdiskussion Problematische Anforderungen werden diskutiert Die Anwender legen ihre Meinung zu den Anforderungen dar Prioritätensetzung Identifizierung der kritischen Anforderungen Anforderungsvereinbarung Verständigung auf die zu erfüllenden Anforderungen notwendige Änderungen bei einigen Anforderungen
Aktivitäten bei der Anforderungserhebung und -analyse Anforderungserhebung Identifiziere Akteure Identifiziere Szenarien Identifiziere Use Cases Verfeinere Use Cases Identif. Beziehungen zwischen Use Cases Identif. nichtfunktionale Anforderungen Identifiziere Neben- bedingungen Identifiziere beteiligte Objekte Erstelle Glossar Anforderungsanalyse Identifiziere Objekte/Klassen boundary, controller, entity Identifiziere Operationen und Methoden Identifiziere Assoziationen Identifiziere Attribute Modelliere Objektinteraktionen Kollaborationsdiagramme Sequenzdiagramme Modelliere nichttriviales internes Verhalten Zustandsdiagramme Von beobachteter Mehrdeutigkeit, Unkorrektheit, Unvollständigkeit, Inkonsistenz, Undurchführbarkeit zur Verfeinerung der Anforderungen
Vorlesung Softwaretechnologie Kapitel 4: Anforderungserhebung odeu ebu gund -analyse a R O O T S 4.1 Anforderungserhebung ( Requirements Elicitation ) 4.1.1 Dynamische Modellierung 4.1.2 Vorgehensmodell
Anforderungstypen Funktionale Anforderungen Beschreiben die Interaktionen zwischen dem System und seiner Umgebung unabhängig von der Implementierung Die Uhr muss die Zeit ortsabhängig anzeigen Nichtfunktionale Anforderungen Für den Nutzer sichtbare Aspekte des Systems, welche nicht direkt mit dem funktionalen Verhalten in Beziehung stehen. Die Reaktionszeit muss unter einer Sekunde liegen Die Genauigkeit muss innerhalb einer Sekunde sein Die Uhr muss 24 Std am Tag verfügbar sein, außer zwischen 02:00-02:0102:01 und 03:00-03:01 Nebenbedingungen ( Pseudo requirements ) Bedingt durch den Kunden oder der Operationsumgebung des Systems Die Implementierung muss in COBOL erfolgen unter Verwendung von DB2. Muss mit dem Abfertigungssystem von 1956 zusammenarbeiten. 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-21 R O O T S
Was gehört normalerweise nicht zu den Anforderungen? Systemstruktur, Implementierungstechnik Entwicklungsmethodologie th l i Entwicklungsumgebung Wiederverwendbarkeit... Dies sind Dinge, die normalerweise die Entwickler selbst festlegen sollten, nicht die Kunden. 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-22 R O O T S
Arten der Anforderungserhebung Greenfield Engineering ( Planung auf der grünen Wiese ) Es existiert t kein vorheriges System Die Anforderungen werden vom Kunden und den Endbenutzern bestimmt Ausgelöst durch Nutzerbedarf Reengineering Re-Design und/oder Re-Implementierung eines existierenden Systems mit neuerer Technologie Ausgelöst durch neue verfügbare Technologie Interface Engineering Bietet die Dienste eines existierenden Systems in neuer Umgebung Ausgelöst durch neue verfügbare Technologie oder neuen Marktbedarf 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-23 R O O T S
Produkte des Requirement Elicitation Workflows <<UML>> 1..* Use Case Diagramm 1 Nichtfunktionale Anforderungen 1 Use Case Model 1..* * <<Text>> Use Case Beschreibung <<UML>> Dynamisches-DiagrammDiagramm * * 1 Requirements Model 1 Interface Model * <<Mockup or Text>> UI Spezifikation * Spezifikation der System- Schnittstellen Nebenbedingungen 1 Glossar Funktionale Anforderungen Anwendungsdomäne Domain Object Model 1..* <<UML>> Klassen-Diagramm Erfassung der Anforderungen aus Anwender-Sicht in einer für den Anwender noch nachvollziehbaren Form
Artefakte des Anforderungs-Models Use Case Modell Beschreibung aller Anwendungsfälle durch ein oder mehrere Diagramme Beschreibung jedes Anwendungsfalls durch strukturierten Text Evtl. Beschreibung der Abläufe komplexer Anwendungsfälle durch dynamische Diagramme Evtl. zum zusätzlichen Verständnis komplexer Geschäftsprozesse in die die Anwendungsfälle eingebettet sind, Beschreibung der Geschäftsprozesse durch dynamische Diagramme. Glossar Stichwortverzeichnis der Anwendungsdomäne Begriffe sind durch freien Text definiert Domain Object Model Erfassung der wichtigsten Konzepte des Glossars und ihrer Beziehungen durch ein Klassendiagramm / Klassendiagramme Interface Model Mockups (= mit Papier, Farben, etc. simulierte Benutzeroberflächen) System-Schnittstellen-Beschreibung Schnittstellen (textuell oder Klassendiagramm) 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-25 R O O T S
Anforderungserhebung Herausforderung: erfordert Zusammenarbeit von Leuten mit unterschiedlichem Background Nutzer mit Wissen über die Anwendungsdomäne Entwickler mit Wissen über die Implementierungsdomäne Überbrücken der Lücke zwischen Nutzer und Entwickler Szenarien: Beispiel der Nutzung des Systems in Form einer Reihe von Interaktionen zwischen Nutzer und System Use Cases: Abstraktion, welche eine Klasse von Szenarien beschreibt 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-26 R O O T S
Beziehungen Akteur-Szenario-Use Case als Klassendiagramm Ein Akteur hat Ziele Use Cases sind nach den Zielen benannt Jeder Use Case fasst eine Menge von Szenarien zusammen Ein Szenario kann sich auf Teil-Use Cases beziehen. 1 hat n Verantwortlichkeiten hat benennt enthält Akteur Ziel Use Case Szenarien 1 n 1 n n Teil-UseCase Bedingung Erfolgreich/ nicht erfolgreich hat 1 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-27 R O O T S
Ziele in Anforderungen umsetzen Die Ziele für die das System von dem Akteur eingesetzt wird sind gute Kandidaten für funktionale Anforderungen. Z.B.: Eine Bestellung aufgeben. Hebe Geld von meinem Konto ab. Ich brauche ein Angebot. Finde die beste Alternative. Ziele fassen die Systemfunktionen in einer verständlichen, überprüfbaren Weise zusammen 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-28 R O O T S
Ziele in Anforderungen umsetzen Ein Use Case besteht aus der Zielsetzung und den zugehörigen Szenarien. Der Name des Use Case ist seine Zielsetzung: Bestell das Produkt aus dem Katalog Beachte die Grammatik: das aktive Verb steht am Anfang Ein Szenario spezifiziert wie sich eine Voraussetzung auswirkt Szenario (1): Alles funktioniert wie vorhergesehen... Szenario (2): Zu wenig Guthaben... Szenario (3): Produkt nicht mehr Vorrätig... 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-29 R O O T S
Szenarien und Use Case Ziel: Bestelle (Use Case) Nebenziel (Szenario): sz1 sz2 sz3 sz4 sz5 sz6 sz7... Erfolgreiche endende Szenarien Nicht erfolgreich endende Szenarien 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-30 R O O T S
Aktivitäten der Anforderungsanalyse: Ein Szenario- und Use-Case-getriebener Ansatz Identifiziere Akteure Identifiziere i Szenarien Identifiziere Use Cases Verfeinere Use Cases Identifiziere Beziehungen zwischen Use Cases Identifiziere nichtfunktionale Anforderungen Identifiziere beteiligte Objekte Erstelle Glossar 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-31 R O O T S
Wozu Szenarien und Use Cases? Nachvollziehbar für Nutzer Use Cases modellieren ein System aus Sicht des Nutzers (funktionale Anforderungen) Bestimmung jedes möglichen Ereignisflusses durch das System Beschreibung von Interaktionen zwischen Objekten Großartiges Werkzeug um ein Projekt zu managen. Use Cases können eine Basis für den gesamten Entwicklungsprozess sein Gebrauchsanleitung Systemdesign und Objektdesign Implementierung Testspezifikation Akzeptanztest beim Kunden Eine exzellente Grundlage für inkrementelle & iterative Entwicklung Use Cases wurden auch zur Restrukturierung von Geschäftsprozessen vorgeschlagen (Ivar Jacobson) 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-32 R O O T S
Use-Case-getriebener Softwareentwicklungsprozeß Requirements Engineering Anforderungs- Anforderungs- erhebung analyse System Object Implemen- Testen Design Design tation Use Case Model ausgedrückt als strukturiert durch realisiert durch implementiert von verifiziert durch class... class... class...? class...? Domain Analysis Object Model Model Subsysteme Implementa- tion Domain Objects Quell Test Code Fälle * Die erzeugten dynamischen Modelle (und Andere) sind hier aus Platzgründen nicht explizit dargestellt.
Szenarien Eine erzählende Beschreibung dessen, was Menschen tun und erfahren wenn sie versuchen, Computersysteme und Anwendungen zu benutzen [M. Carrol, Scenario-based Design, Wiley, 1995] Eine konkrete, fokussierte und informelle Beschreibung einer einzelnen Funktionalität eines Systems, aus Sicht eines einzelnen Akteurs. Szenarien können während eines Software-Lebenszyklus an vielen Stellen Anwendung finden. 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-34 R O O T S
Beispiel Szenario: Brand im Lagerhaus Bob, der die Hauptstraße mit seinem Streifenwagen entlangfährt, bemerkt Rauch der aus einem Lagerhaus dringt. Seine Kollegin Alice meldet den Notfall von ihrem Wagen aus. Alice gibt die Adresse des Gebäudes ein, eine kurze Beschreibung des Ortes (z.b., nordwestliche Ecke) und eine Notfallstufe. Zusätzlich zu einem Feuerwehrwagen fordert sie mehrere Sanitäter an, da die Gegend sehr belebt scheint. Sie bestätigt ihre Eingabe und wartet auf Bestätigung. John, der Disponent, wird durch einen Piepton seiner Workstation alarmiert. Er überprüft die Informationen von Alice und bestätigt ihre Meldung. Er schickt einen Feuerwehrwagen und zwei Sanitäter zum Unglücksort und sendet Alice ihre voraussichtliche Ankunftszeit. Alice empfängt die Bestätigung und die voraussichtliche Ankunftszeit. 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-35 R O O T S
Beobachtungen beim Brand-im- Lagerhaus-Szenario Konkretes Szenario Beschreibt eine einzelne Instanz der Meldung eines Feuers. Beschreibt nicht alle möglichen Situationen, bei welchen ein Feuer gemeldet werden kann. Beteiligte Akteure Bob, Alice und John 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-36 R O O T S
Arten von Szenarien As-is Szenario Zur Beschreibung einer momentanen Situation. ti Normalerweise während des Reengineering genutzt. Der Benutzer beschreibt das System. Visionäres Szenario Zur Beschreibung eines zukünftigen Systems. Normalerweise genutzt beim Greenfield Engineering g oder Reengineering. g Kann oft weder von Benutzer noch Entwickler alleine erstellt werden Evaluationsszenario i Benutzeraufgaben, anhand derer das System bewertet wird Trainingsszenario Schritt für Schritt Anweisungen, um einen Neuling durch das System zu führen 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-37 R O O T S
Wie finden wir Szenarien? Erwarte keine Aussagen vom Kunden, solange das System (noch) nicht existiert. (greenfield engineering) Warte auch bei existierendem System nicht auf Informationen Versuche einen dialektischen Ansatz (evolutionär, inkrementell) Du hilfst dem Kunden, die Anforderungen zu formulieren Der Kunde hilft dir, sie zu verstehen Die Anforderungen entfalten sich während der Entwicklung der Szenarien 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-38 R O O T S
Heuristiken zum Finden von Szenarien Stelle dir selbst oder dem Kunden die folgenden Fragen: Was sind die primären Aufgaben des Systems? Welche Daten möchte der Akteur im System anlegen, speichern, ändern, löschen oder einfügen? Über welche externen Änderungen muss das System informiert sein? Bei welchen Änderungen oder Ereignissen soll der Akteur des Systems informiert werden? Wenn bereits ein System existiert, bestehe darauf zu beobachten, wie die Aufgaben damit bearbeitet werden. (z.b. bei Interface-Engineering oder Reengineering): Bitte um ein Gespräch mit dem Endbenutzer, nicht nur mit dem Softwareanbieter. Erwarte Widerstand und versuche ihn zu überwinden. 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-39 R O O T S
Beispiel: Ein Unfall-Management-System Was ist zu tun, um eine Katze im Baum zu melden? Was benötigst Du, wenn jemand einen Brand in einem Lagerhaus meldet? Wer ist an der Meldung eines Unfalls beteiligt? Was tut das System, wenn keine Polizeiwagen verfügbar sind? Was, wenn der Polizeiwagen auf dem Weg zur Katze einen Unfall hat? Was tust Du, wenn die Katze im Baum zu einer von der Leiter gefallenen Oma wird? Kann das System mit gleichzeitigen Feuer-im-Lagerhaus-Meldungen umgehen? 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-40 R O O T S
Nächstes Ziel, nach Formulierung der Szenarien: Finde einen Use Case im Szenario, welcher alle möglichen Instanzen der Meldung eines Feuers spezifiziert Beispiel: Notfall melden im zweiten Paragraph des Szenarien ist ein möglicher Use Case Nach Vergabe eines Namens beschreibe den Use Case detaillierter Benenne die Akteure Beschreibe die Anfangsbedingung Beschreibe den Ereignisfluss Beschreibe die Endbedingung Beschreibe Ausnahmen Beschreibe besondere Anforderungen (Nebenbedingungen, nichtfunktionale Anforderungen) 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-41 R O O T S
Beispiel: Schrittweise Formulierung eines Use Case Benenne zuerst den Use Case Name des Use Case: ReportEmergency Dann finde die Akteure Verallgemeinere die konkreten Namen ( Bob ) zu beteiligten Akteuren ( Field officer ) Beteiligte Akteure: Field Officer (Bob und Alice in diesem Szenario) Disponent (John in diesem Szenario)? Dann richte das Augenmerk auf den Ereignisfluss Benutze informelle natürliche Sprache 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-42 R O O T S
Beispiel: Schrittweise Formulierung eines Use Case Formuliere den Ereignisfluss: Der FieldOfficer betätigt die Melde Notfall -Funktion seines Terminals. Das System reagiert durch Anzeige eines Formulars. Der FieldOfficer füllt das Formular durch Angabe von Stufe, Art und Ort des Notfalls sowie einer kurzen Situationsbeschreibung ti ib aus. Zudem schlägt er mögliche Reaktionen vor. Wenn es ausgefüllt ist, sendet der FieldOfficer das Formular, und der Disponent wird sofort benachrichtigt. Der Disponent überprüft die erhaltenen Informationen und erstellt einen Notfall in der Datenbank durch Aufruf des OpenIncident Use Case. Er wählt eine passende Reaktion auf den Notfall aus und bestätigt die Notfallmeldung. ld Der FieldOfficer empfängt die Bestätigung und die gewählte Reaktion. Daraus lassen sich wichtige Konzepte und Beziehungen der Objektdomäne ableiten Verwende Abbottt s Technik zur Objektidentifikation schon parallel zur Use Case Modellierung zwecks Erstellung des Domain Object Model (und später verstärkt bei der Anforderungs-Analyse) 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-43 R O O T S
Beispiel: Schrittweise Formulierung eines Use Case Schreibe die Ausnahmen auf: Der FieldOfficer wird sofort benachrichtigt, hti t wenn die Verbindungen zwischen seinem Terminal und Zentrale abbricht. Der Disponent wird sofort benachrichtigt, wenn die Verbindung zu irgend einem der eingeloggten FieldOfficer abbricht. Identifiziere und notiere jegliche besondere Anforderungen: Die Meldung des FieldOfficer wird innerhalb von 30 Sekunden bestätigt. Die gewählte Reaktion trifft nicht später als 30 Sekunden nach der Wahl durch den Disponent ein. 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-44 R O O T S
Wie man einen Use Case spezifiziert (Zusammenfassung) Name des Use Case Akteure Beschreibung der am Use Case beteiligten Akteure Anfangsbedingung Nutze einen syntaktischen Ausdruck wie Dieser Use Case beginnt, wenn Ereignisfluss i Formlos, informelle natürliche Sprache Endbedingung Beginnt mit Dieser Use Case endet, wenn Ausnahmen Beschreibe was passiert, wenn etwas schief geht inkl. der entsprechenden Nachbedingungen. Spezielle Anforderungen Nichtfunktionale Anforderungen und Nebenbedingungen 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-45 R O O T S
Standard dablauf Use Case Beschreibung als strukturierter Text: Termin erfassen Kurzbeschreibung Ein Termin kann für einen oder mehrere Teilnehmer... Akteure Benutzer Vorbedingung E-Mail-System... Benutzer ist dem System bekannt. Ereignisfluss 1. Benutzer meldet sich an. 2. Neuer Termin wird erfasst (Zeit, Ort,...) 3. Teilnehmer werden zugeordnet. 4. Benutzer ist berechtigt für alle Teilnehmer Termine zu erfassen. 5.... Nachbedingung g Neuer Termin ist erfasst. Alle Teilnehmer sind verständigt und... Alle Sichten sind aktualisiert. Alternativabläufe 4'. Benutzer hat für mind. einen Teilnehmer keine Berechtigung....... Fehlersituation Benutzer hat für keinen der Teilnehmer die Berechtigung, einen... Nachbedingung im Ein Termin kann für einen oder mehrere Teilnehmer... Fehlerfall Trigger --- 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-46 R O O T S
Use Case Model für Notfallzentrale FieldOfficer Disponent Flow of Events:... Entry Conditions:... Melde Notfall Weise Resourcen zu Notfallzentrale Lege Akte an Exit Conditions:... Flow Entry Flow Entry Special Requirements: Exit... Exit...... Special Special 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-47 R O O T S
Use-Case Diagramm Stellt einen Ausschnitt aus der Funktionalität eines Systems aus Sicht des Benutzers dar. Beschreibt Interaktionen von Akteuren und System sowie Beziehungen zwischen den Use Cases. System Uhr Anwendungsfall (Use Case) LeseZeit Akteur SetzeZeit Uhrenträger Uhrmacher TauscheBatterie Rolle eines Akteurs 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-48 R O O T S
Use-Case Diagramm: Elemente Einsatz Analysephase Kommunikation mit Auftraggeber / Benutzer Erfassung von Anwendungsszenarien (Use Cases) Elemente Akteure Beispiel Rolle eines Akteurs System Use Cases Annotationen Beziehungen name... <<include>> A B <<extend>> A B customer System place order salesperson When placing an order,... A <<inherit>> B 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-49 R O O T S
Verfeinerung und Strukturierung von Use Cases Ausgangspunkt: Mehrere Use Cases erfasst Verfeinere und strukturiere die Use Cases durch Assoziationen Use Case Assoziation = Beziehung zwischen Use Cases Wichtige Use-Case-Assoziationstypen Extend Ein Use Case erweitert einen anderen Include Ein Use Case benutzt einen anderen ( funktionale Dekomposition ) Generalisierung Ein abstrakter Use Case mit verschiedenen Spezialisierungen 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-50 R O O T S
Übersicht Include-Beziehung Wenn immer A ausgeführt wird, muss auch B ausgeführt werden B ist unbedingt nötig, um A auszuführen Für Verhalten, das von mehreren genutzt wird A <<include>> B <<extend>> Extend-Beziehung B A Wenn A ausgeführt wird, kann auch B ausgeführt werden B ist nicht zwingend nötig, um A auszuführen Für Sonderfälle, optionales oder seltenes Verhalten Generalisierungsbeziehung B erbt das ganze Verhalten von A Zur Modellierung von Vererbung B A 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-51 R O O T S
<<include>>-beziehung: Verwendung Funktionale Dekomposition Problem Ein Use Case ist zu komplex und muss zerlegt werden. Gesamt-Anwendungsfall Gemeinsame Verwendung Problem Gemeinsames Verhalten verschiedener Use Cases muss ausgedrückt werden Gesamt-Anwendungsfälle ErzeugeDokument Notfall erfassen Ressourcen zuweisen <<include>> <<include>> Scanne OCR Prüfe Karte Anzeigen Enthaltene Anwendungsfälle Enthaltener Anwendungsfall 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-52 R O O T S
<<include>>-beziehung: Semantik Jeder Ablauf des Gesamt-Anwendungsfalls beinhaltet einen Ablauf des enthaltenen Anwendungsfalls Die include-beziehung von A nach B bedeutet, dass A all das Verhalten von B ausführt ( A delegiert an B ). A ist abhängig von B (daher auch die Richtung und Art des Pfeiles: der übliche Abhängigkeitspfeil, lediglich mit einem passenden Stereotyp) ErzeugeDokument Gesamt-Anwendungsfall <<include>> <<include>> <<include>> Enthaltener Anwendungsfall Scan OCR Prüfe 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-53 R O O T S
extend-beziehung Problem Unter bestimmten t Bedingungen (Sonderfälle, Fehlerfälle, ) muss der Ablauf eines Use-Cases erweitert werden Lösung / Semantik Eine extend-beziehung von Use Case A nach B bedeutet, dass A eine Erweiterung von B ist, die nur unter der angegebenen Bedingung aktiv ist. Der erweiterte UC ist unabhängig vom erweiternden UC. Beispiel Notfall erfassen ist komplett, kann aber in einem Szenario, in dem der Benutzer Hilfe braucht, durch Help erweitert werden. Notfall Erfassen Ressourcen zuweisen <<extend>> [F1 gedrückt] <<extend>> [F1 gedrückt] Help 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-54 R O O T S
Use-Case Diagramm: Extension Points Deklaration im zu erweiternden Use Case Benannte Stellen im Ereignisfluss i des erweiterten t Use Case, wo der Ablauf des erweiternder Use Cases einzufügen ist Bezugnahme in <<extends>>-beziehung Erweiternder Use Case wird an am Extension Point aktiviert falls die spezifizierte extends-bedingung gilt Notizen können Bedingungen und Namen von extension points enthalten Notfall erfassen extension points Kommunikationsausfall Extension Point Deklarationen «extend» «extend» condition: { F1 gedrückt } extension point: ---- condition: { Verbindung abgebrochen } extension point: Kommunikationsausfall Hilfe anzeigen Ersatzstreife schicken 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-55 R O O T S
Extend-Beziehung-Notation in UML 1 und UML 2.0 UML 1 und 2.0: Angabe von Bedingungen und Erweiterungspunkten an der Beziehung (wie auf dieser Folie) ab UML 2.1: in getrennter Notiz (wie auf vorheriger Folie) «extends» [F1 gedrückt] Notfall erfassen extension points Kommunikationsausfall Deklaration eines Erweiterungspunktes Bezug auf Erweiterungspunkt «extends» (Kommunikationsaufall) [Verbindung abgebrochen] Ersatzstreife schicken Hilfe anzeigen Bedingung unter der die Erweiterung aktiv wird 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-56 R O O T S
Use-Case Diagramm: Extension Points Extension points werden im zu erweiternden Use Case deklariert Sie sind Namen für die Stellen im Ereignisfluss i des erweiterten t UC, wo der Ablauf des erweiternden UC einzufügen ist Die Angabe von Extension points an einer <<extends>>-beziehung spezifiziert, dass die Verhaltensfragmente des erweiternden Use Case an den jeweiligen Extension Points aktiviert werden sollen Meist gibt es aber pro Use Case nur ein Verhaltensfragment und somit nur einen Erweiterungspunkt auf den Beug genommen wird. Sonst werden die verschiedenen Fragmente der Reihe nach an den jeweiligen Erweiterungspunkten aktiviert Erstes Fragment am ersten Erweiterungspunkt, zweites Fragment am zweiten Erweiterungspunkt, Vorschau: Extends-Beziehung und Aspektorientierte Programmierung! 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-57 R O O T S
Generalisierung von Use Cases Problem Man möchte in Use Cases wiederkehrendes d Verhalten auslagern. Lösung Die Generalisierungsbeziehung lagert gleiches Verhalten von Use Cases aus. Die Kinder erben die Kommunikationsbeziehungen, die Bedeutung und das Verhalten, der Eltern, ersetzen Teile davon und fügen neues hinzu. Beispiel ValidateUser ist verantwortlich für die Überprüfung der Benutzeridentität. Der Kunde könnte zwei Umsetzungen fordern: CheckPassword und CheckFingerprint CheckPassword Eltern Case ValidateUser CheckFingerprint Kind Use Case 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-58 R O O T S
Beispiel Kalender-Manager Benutzer Termin erfassen Kalender-Manager Termine exportieren Termin abfragen Termin ändern Termin löschen 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-59 R O O T S
Beispiel Kalender-Manager : Verfeinerung Kalender-Manager Benutzer E-Mail System Termin erfassen «include» [ geklickt] kt] Programm verwalten «extend» Zugriffsrechte verwalten [ geklickt] Teilnehmer verständigen Kalender aktualisieren Einstellungen verwalten Fax-System Verfeinerung und Strukturierung der Use-Cases Gemeinsamkeiten / Überlappungen: «include»-beziehung Kernablauf / Sonderfälle: «extend»-beziehung 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-60 R O O T S
Beispiel Kalender-Manager : Spezialisierung Kalender-Manager Benutzer Termin erfassen «include» Eintrag erfassen E-Mail System Teilnehmer verständigen Kalender aktualisieren to-do-eintrag t erfassen Fax-System Verfeinerung und Strukturierung der Use-Cases Gemeinsamkeiten / Überlappungen: «include»-beziehung Kernablauf / Sonderfälle: «extend»-beziehung Generalisierung / Spezialisierung: Vererbungs-Beziehung 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-61 R O O T S
Use-Case Diagramm: Beziehungen Verfeinerung und Strukturierung der Use-Cases A «include» B: das Verhalten von B wird idin A eingefügt B «extend» A: das Verhalten von B kann in A eingefügt werden B ist Spezialisierung von A: B erbt das gesamte Verhalten von A. Kalender-Manager Eintrag erfassen Benutzer Programm verwalten «extend» «include» Termin erfassen to-do-eintrag erfassen E-Mail System Zugriffsrechte verwalten «extend» Kalender aktualisieren «include» Einstellungen verwalten Teilnehmer verständigen Fax-System
Kalender-Manager: Strukturiertes Use Case Diagramm Kalender-Manager Termin abfragen Kalender aktualisieren Benutzer Termin erfassen «include» Termin ändern «include» Termin löschen «include» «include» «include» «include» Termine exportieren Teilnehmer verständigen E-Mail System Programm verwalten «extend» Einstellungen verwalten Fax-System Administrator Benutzer verwalten Termintypen verwalten Zugriffsrechte verwalten
Kalender-Manager: Überarbeitung des UC Packages Termine Termin abfragen Kalender aktualisieren Benutzer Termin erfassen «include» Termin ändern «include» Termin löschen «include» E-Mail System Termine exportieren «include» «include» «include» Teilnehmer verständigen Fax-System Verwaltung Programm verwalten «extend» Einstellungen verwalten Benutzer Administrator Benutzer verwalten Termintypen verwalten Zugriffsrechte verwalten
Gesamt-System als geschachtelte Paket- Sicht <<system>> Kalender-Manager Termine Verwaltung Pakete können um weitere Artefakte erweitert werden Aktivitätsdiagramme Sequenzdiagramme Klassendiagramme des Domain Object Model Textuelle Beschreibungen der Use Cases Tip zu Together Sie können Use-Case-Diagramme per drag-n-drop in ein Paket einfügen 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-66 R O O T S
Vorlesung Softwaretechnologie Kapitel 4: Anforderungserhebung odeu ebu gund -analyse a R O O T S 4.1.1 Dynamische Modellierung
Beschreibung von Use-Cases und Geschäftsprozessen Motivation Textuelle Beschreibung des Use-Case Ablaufs nicht eindeutig Geschäftsprozesses in den der Use Case eingebettet ist, ist noch unklar Vorgehen: bei einfachen Abläufen / wenigen Varianten Aktivitätsdiagramm Varianten durch Entscheidungsknoten im Diagramm darstellen Vorgehen: bei komplexen Abläufen / vielen Varianten mehrere Aktivitätsdiagramme je ein Diagramm für eine Gruppe von Ablaufvarianten Alternative: Szenarien Konzentration auf einen wesentlichen Ablauf (ein Szenario) dann auch Modellierung mit Sequenz- oder Kollaborationsdiagrammen möglich eventuell mehrere Diagramme für die wichtigsten Abläufe 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-68 R O O T S
Aktivitätsdiagramm mit Produkten Benutzer Kalender-Manager Benutzer Anmelden Benutzerdaten prüfen :Benutzer [ok] :Termin [erzeugt] Termin anlegen <<create>> Teilnehmer zuordnen Eckdaten erfassen <<become>> :Termin [zugeordnet] Berechtigung prüfen [else] [Berechtigung für mindestens einen Teilnehmer] Kollision prüfen
Vom Use-Case zur Verhaltensbeschreibung mit Diagrammen 1. Analysiere die Problembeschreibung Identifiziere i funktionale Anforderungen Identifiziere nichtfunktionale Anforderungen Identifiziere Nebenbedingungen g (Pseudo-Anforderungen) 2. Entwickele das funktionale Modell Entwickle Use Cases zur Illustration der funktionalen Anforderungen Input für 3. Entwickele das Objektmodell Entwickle Klassendiagramme, die die Struktur des Systems beschreiben 4. Entwickele das dynamische Modell Entwickle Sequenzdiagramme zur Illustration von Interaktionen zwischen Objekten Entwickle Zustandsdiagramme für Objekte mit interessantem Verhalten 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-70 R O O T S
Vorlesung Softwaretechnologie Kapitel 4: Anforderungserhebung odeu ebu gund -analyse a R O O T S Beispiel (aus Brügge und Dutoit) Nutzung von Sequenz- und Zustandsdiagrammen zur Modellierung der Dynamik eines Use Nutzung von Sequenz und Zustandsdiagrammen zur Modellierung der Dynamik eines Use Cases
Problembeschreibung: Richtungssteuerung für ein Spielzeugauto Strom wird angeschaltet Auto fährt fähtvorwärts ät und Scheinwerfer leuchtet Strom wird ausgeschaltet Auto hält an und Scheinwerfer geht aus. Strom wird angeschaltet Scheinwerfer leuchtet Strom wird ausgeschaltet Scheinwerfer geht aus. Strom wird angeschaltet Auto fährt rückwärts und Scheinwerfer leuchtet Strom wird ausgeschaltet Auto hält an und Scheinwerfer geht aus. Strom wird angeschaltet Scheinwerfer leuchtet Strom wird ausgeschaltet Scheinwerfer geht aus. Strom wird angeschaltet Auto fährt vorwärts und Scheinwerfer leuchtet. 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-72 R O O T S
Modelliere Use Cases Use Case 1: Systeminitialisierung Anfangsbedingung: Strom ist aus, Auto steht Ereignisfluss: Fahrer schaltet Strom ein Endbedingung: g Auto fährt vorwärts, Scheinwerfer ist an Use Case 2: Schalte Scheinwerfer aus-an-aus Anfangsbedingung: Auto fährt vorwärts und Scheinwerfer leuchtet Ereignisfluss: Fahrer schaltet Strom aus, Auto hält an und Scheinwerfer geht aus. Fahrer schaltet Strom ein, Scheinwerfer leuchtet und Auto steht. Fahrer schaltet Strom aus, Scheinwerfer geht aus Endbedingung: Auto steht, Scheinwerfer aus 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-73 R O O T S
Use Cases Fortsetzung Use Case 3: Bewege Auto rückwärts Anfangsbedingung: Auto steht, Scheinwerfer aus (History!) Ereignisfluss: Fahrer schaltet Strom ein Endbedingung: Auto fährt rückwärts, Scheinwerfer an Use Case 4: Stoppe rückwärtsfahrendes Auto Anfangsbedingung: Auto fährt rückwärts, Scheinwerfer an Ereignisfluss: Fahrer schaltet Strom aus, Auto stoppt, Scheinwerfer geht aus. Strom an, Scheinwerfer leuchtet und Auto steht. Strom aus, Scheinwerfer geht aus. Endbedingung : Auto steht, Scheinwerfer aus. Use Case 5: Bewege Auto vorwärts Anfangsbedingung: Auto steht, Scheinwerfer aus Ereignisfluss: Fahrer schaltet Strom ein Endbedingung: Auto fährt mit leuchtendem Scheinwerfer vorwärts. 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-74 R O O T S
Use Case Ausdünnung Brauchen wir Use Case 5? Use Case 1: Systeminitialisierung Anfangsbedingung g g : Strom ist aus, Auto steht Ereignisfluss: Fahrer schaltet Strom ein Endbedingung : Auto fährt vorwärts und Scheinwerfer leuchtet Use Case 5: Bewege Auto vorwärts Anfangsbedingung : Auto steht, Scheinwerfer aus Ereignisfluss Fahrer schaltet Strom ein Endbedingung : Auto fährt mit leuchtendem Scheinwerfer vorwärts. 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-75 R O O T S
Dynamisches Modell: Sequenzdiagramm für Benutzungs-Szenario Name: Fahre Auto Abfolge von Ereignissen: i Kind schaltet den Strom ein Scheinwerfer geht an Räder beginnen sich vorwärts zu bewegen Räder bewegen sich weiterhin vorwärts Billy schaltet den Strom aus Scheinwerfer geht aus Räder halten an... 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-76 R O O T S
Sequenzdiagramm für das Fahre-Auto- Szenario :Licht Billy:Fahrer :Rad Strom(an) Strom(an) Strom(aus) Strom(aus) Strom(an) Strom(an) 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-77 R O O T S
Zustandsdiagramm des Spielzeugautos Licht Rad Stop 1 Strom an Vor do Vorfahren Aus Strom aus Strom an Strom aus Strom aus An Zurück do Zurückfahren Strom an Stop 2 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-78 R O O T S
Objektmodell des Spielzeugautos Auto Strom Status: (an, aus) einschalten() ausschalten() Licht Status: (an, aus) einschalten() ausschalten() Rad Richtung: (Vor, Rück, Stop) starten() stoppen() 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-79 R O O T S
Vorlesung Softwaretechnologie Kapitel 4: Anforderungserhebung odeu ebu gund -analyse a R O O T S 4.1.2 Domain Object Model Klassendiagramme Abbott's Technik Beispiele
Domain Object Model 1 Use Case Model 1 * Use Case Diagramm Use Case Beschreibung Requirements Model 1 Domain Obj. Model 1 Klassen-Diagramm 1 Interface Model * * UI Spezifikation System- Schnittstellen Klassendiagramm für Konzepte der Anwendungsdomäne Klassen Attribute Beziehungen (wenige Operationen) Vorgehensweise Dialog mit Benutzer Hauptwörter-Erfassung und Filterung Verfahren von Abbott 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-81 R O O T S
Domain Object Model: Beispiel ToDoListe Einzeltermin 1 1..* * 0,1 ToDoEintrag fälligam : Datum relevantab : Datum Serientermin * Termin kollidiertmit begin: DatumUndZeit dauer: Zeit istverschiebbar:bool art:terminart wiederhdauer Werktagstermin wiederhfrequenz 1..* * Teilnehmer * Ansicht Jahresansicht Monatsansicht Wochenansicht Tagesansicht Exportformat Fax HTML Zeitintervall Drucker EMail 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-82 R O O T S
R O O T S 5.2.2 2 Objektmodellierung (Grundlagen) Allgemeine Einführung von Objektmodellierung mit Fokus auf dem Detaillierungsgrad der Anforderungserhebung und den in der Anforderungserhebung eingesetzten Techniken Weitere Notationen, Techniken, Vorgehensweisen der Objektmodellierung werden später schrittweise ergänzt
Objektmodellierung Hauptziel Allgemein: Finden der strukturellen Abstraktionen des Systems In Anforderungserhebung: Finden der wichtigen Abstraktionen des Systems soweit sie für den Anwender beobachtbar sind. Schritte der Objektmodellierung 1. Identifikation von Typen 2. Identifikation von Attributen t 3. Identifikation von Methoden 4. Identifikation von Assoziationen zwischen Typen Reihenfolge der Schritte ist nicht wichtig Ziel: Erreichen der gewünschten Abstraktionen Obige Reihenfolge der Schritte ist sekundär, nur eine Heuristik Wenn wir zu falschen Abstraktionen kommen iterieren das Ganze um das Modell zu korrigieren 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-84 R O O T S
An Use Cases beteiligte Objekte finden Für jeden Use Case führe folgende Schritte durch : Finde Begriffe die Nutzer oder Entwickler klären müssen um den Ereignisfluss zu verstehen Beginne immer mit den Begriffen des Nutzers, dann diskutiere: FieldOfficerStationBoundary oder FieldOfficerStation? IncidentBoundary oder IncidentForm? EOPControl oder EOP? Identifiziere Entitäten der realen Welt, die das System im Auge behalten muss. Beispiele: FieldOfficer, Disponent, Resource Identifiziere Vorgänge der realen Welt, die das System im Auge behalten muss. Beispiel: EmergencyOperationsPlan Identifiziere Datenquellen oder -senken. Beispiel: Drucker Identifiziere Schnittstellen. Beispiel: PoliceStation Führe eine Textanalyse zum Finden zusätzlicher Objekte durch (Nutze Abott s Technik) Modelliere den Ereignisfluss mit einem dynamischem Diagramm 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-85 R O O T S
Wie findet man Klassen? Analyse der Anwendungsdomäne: Gespräche mit dem Kunden zur Identifikation von Abstraktionen Verwende allgemeines Verständnis der Welt und Intuition Textuelle Analyse der Problembeschreibung ( Technik von Abbott) Entwurfsmuster Fokus hier Eigenes Kapitel 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-86 R O O T S
Beispiel: Ein Szenario aus der Problembeschreibung Jim Smith betritt ein Geschäft um ein Spielzeug für sein 3 Jahre altes Kind zu kaufen. Der Geschäftsinhaber berät den Kunden. Der Rat beruht auf dem Alter des Kindes und den Eigenschaften des Spielzeugs. Jim wählt ein gefährliches Spielzeug, das für das Kind ungeeignet ist. Der Geschäftsinhaber empfiehlt eine ungefährlichere Puppe. Hilfe muss innerhalb einer Minute verfügbar sein. Gibt uns diese Beschreibung Hinweise, wie unser Objektmodell aussehen sollte? 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-87 R O O T S
Textanalyse von Abbott [Abbott 1983] Zuordnung von Teilen der Sprache zu Komponenten des Objektmodells Wird vor allem genutzt bei Erstellung des Domain Object Models und Analysemodells Sprachelement Modellelement Beispiel Eigenname Objekt Jim Smith Nomen Klasse Spielzeug, Puppe ist Generalisierung Eine Puppe ist ein Spielzeug hat,, enthält, Aggregation g Eine Puppe hat zwei Arme Modalverb ( müssen, können, dürfen, sollen ) Einschränkung (Constraint) Spielzeug darf nicht verschluckt werden können. Adjektiv Attribut grün, beweglich Transitives Verb Methode bringen Intransitives Verb Methode (Event) erscheinen 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-88 R O O T S
Textanalyse von Abbott [Abbott 1983] Abbott s Technik ist eine Hilfestellung für denkende Menschen, nicht ein starres Regelwerk für Automaten! Die Entsprechungen sind Hinweise, keine Gesetze! Selbst entscheiden, was im konkreten Fall zutrifft ist immer noch erforderlich. Z. B.: Tisch hat Beine Aggregation Aber: Kunde hat Konto einfache Assoziation. Z. B.: Kind ist Mensch Aber: Thomas ist Kind Generalisierung Instanz! Die Entsprechungen aus der Abbott-Tabelle ist nicht exklusiv! Sie sollten sie sinngemäß ergänzen. Z.B: hat beinhaltet, enthält, ist Teil von, 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-89 R O O T S
Beispiel: Szenario aus der Problembeschreibung Jim Smith betritt ein Geschäft um ein Spielzeug für sein 3 Jahre altes Kind zu kaufen. Der Geschäftsinhaber berät den Kunden. Der Rat beruht auf dem Alter des Kindes und den Eigenschaften des Spielzeugs. Jim wählt ein gefährliches Spielzeug, das für das Kind ungeeignet ist. Der Geschäftsinhaber empfiehlt eine ungefährlichere Puppe. Hilfe muss innerhalb einer Minute verfügbar sein. OK, wir haben nun erste Hinweise was Objekte, Methoden,... sein könnten. Wie geht's nun weiter? Diagramme erstellen! 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-90 R O O T S
Objektmodellierung: Klassenidentifikation Klassenidentifikation Name der Klasse Attribute Methoden Konto kontostand kundennr einzahlen() abheben() kontostand() 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-91 R O O T S
Objektmodellierung: Iteration Finde neue Objekte Kunde, Bank Iteriere über Namen, Attribute und Methoden Kunde name kundennr Konto kontostand kundennr einzahlen() abheben() kontostand() Konto kontostand kundennr einzahlen() abheben() kontostand() name Bank 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-92 R O O T S
Objektmodellierung: Iteration Finde Assoziationen zwischen Objekten Benenne die Assoziationen Ermittle ihre Art und Multiplizität hat 1..* 1..* Kunde name kundennr Konto kontostand kundennr einzahlen() abheben() kontostand() 1..* name Bank 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-93 R O O T S
Objektmodellierung: Kategorien finden (Vererbung) Kunde name kundennr Konto kontostand t 1..* hat 1..* 1..* einzahlen() abheben() kontostand() name Bank Sparkonto Festzinskonto Tagesgeldkonto abheben() abheben() abheben() 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-94 R O O T S
Qualifikation Ein Qualifier präzisiert die Multiplizitätsangaben einer Assoziation zwischen Klassen. Er wird benutzt, um 1-n Multiplizitäten auf 1-1 Multiplizitäten zu reduzieren Ohne Qualifikation: Ein Verzeichnis enthält viele Dateien. Eine Datei gehört zu genau einem Verzeichnis. Ordner 1 * Datei dateiname Ordner Ordner dateiname 1 0..1 Datei Mit Qualifikation: Ein Verzeichnis enthält viele Dateien, jede mit einem einmaligen Namen 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-95 R O O T S
Qualifikation Ein Qualifier präzisiert die Multiplizitätsangaben einer Assoziation zwischen Klassen. Er wird benutzt, um 1-n Multiplizitäten auf 1-1 Multiplizitäten zu reduzieren Ohne Qualifikation: Ein Verzeichnis enthält viele Dateien. Eine Datei gehört zu genau einem Verzeichnis. Ordner 1 * Datei dateiname Mit Qualifikation: i 1 0..1 Ein Verzeichnis enthält viele Ordner Ordner dateiname Datei Dateien, jede mit einem einmaligen Namen 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-96 R O O T S
Objektmodellierung allgemein: Zusammenfassung Ableitung eines Objektmodells aus einem Use Case Modell Identifikation von Objekten / Klassen Identifikation von Attributen and Operationen Generalisierung Identifikation von Assoziationen, Aggregation und Komposition Reduzierung der Multiplizität mit Hilfe von qualifizierten Assoziationen Die besprochenen Techniken sind allgemeiner Natur und können jederzeit eingesetzt werden Anforderungs-Erhebung für Domain Object Model Analyse für Analyse-Modell Design für Design-Modell Sie wurden hier vorgestellt, da sie grundlegend g sind und hier zum ersten Mal Verwendung finden 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-97 R O O T S
Vorlesung Softwaretechnologie Kapitel 4: Anforderungserhebung odeu ebu gund -analyse a R O O T S Erstellung des Domain Object Model Ausführliches Beispiel Anwendung der Technik von Abbott Verfeinerung des schematisch erstellten Modells
Beispiel: Ereignisfluss aus Use Case als Ausgangspunkt Stellen Sie Sich vor, dass Ihre Kundin, eine Großhändlerin, die Softgetränke an Supermärkte liefert, ein System wie folgt beschreibt: Die Pfandrückgabemaschine (PRM) wird in Supermärkten aufgestellt um wiederverwendbare db Getränkebehälter zurückzunehmen (leere Dosen, Flaschen und Kästen, welche Endbenutzern geliefert werden). Für jeden Behältertyp kann unsere Betreiberin einen individuellen Pfandbetrag einstellen. Anstelle der Rückgabe von Münzgeld druckt die PRM eine Quittung über die Summe der entstandenen Pfandbeträge. Diese Quittung kann durch einen Bar Code Scanner eingelöst werden. Die PRM generiert für unsere Betreiberin täglich einen Bericht. Ein Bericht beinhaltet eine Liste aller an diesem Tag zurückgegangenen Behälter, sowie die Tagessumme an ausgezahltem Pfand-Geld. 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-99 R O O T S
Beispiel: Textanalyse nach Abbott Objektidentifikation mit Hilfe von Abbott's Technik: Substantive / Nomen / Hauptwörter Die Pfandrückgabemaschine (PRM) wird in Supermärkten aufgestellt um wiederverwendbare db Getränkebehälter zurückzunehmen (leere Dosen, Flaschen und Kästen, welche Endbenutzern geliefert werden). Für jeden Behältertyp kann unsere Betreiberin einen individuellen Pfandbetrag einstellen. Anstelle der Rückgabe von Münzgeld druckt die PRM eine Quittung über die Summe der entstandenen Pfandbeträge. Diese Quittung kann durch einen Bar Code Scanner eingelöst werden. Die PRM generiert für unsere Betreiberin täglich einen Bericht. Ein Bericht beinhaltet eine Liste aller an diesem Tag zurückgegangenen Behälter, sowie die Tagessumme an ausgezahltem Pfand-Geld. 2000-2008 Dr. G. Kniesel Vorlesung Softwaretechnologie (SWT) Seite 4-100 R O O T S
Beispiel: Schematische Erstellung des Domain Object Model (1) Substantive / Nomen / Hauptwörter Klassen Die Pfandrückgabemaschine (PRM) wird in Supermärkten aufgestellt um wiederverwendbare Getränkebehälter zurückzunehmen (leere Dosen, Flaschen und Kästen, welche Endbenutzern geliefert werden). Für jeden Behältertyp kann unsere Betreiberin einen individuellen Pfandbetrag einstellen. Betreiberin Supermarkt Pfandrückgabemaschine Getränkebehälter Behältertyp Pfandbetrag Dose Flasche Kasten