Softwaretechnik 3. Anforderungsanalyse RWTH Aachen PDF

Vorlesung Softwaretechnik 3. Anforderungsanalyse Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Farbe! Warum, was, wie und wozu? Anforderungsanalyse Warum? Was?...

Vorlesung Softwaretechnik 3. Anforderungsanalyse Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Farbe! Warum, was, wie und wozu? Anforderungsanalyse Warum? Was? Wie? Wozu? Analysephase Konzepte der Modellierungssprachen Zufriedene Für die Praxis AnwenderInnen Use Case Diagramme notwendig zu wissen, wie man für Anwendungsfälle Anwendung der Anforderungen Aktivitätsdiagramme für Modellierungstechnik systematisch erfasst Prozesse und dokumentiert Weniger Risiko in der Prototypen für die Konkrete Beispiele Produktentwicklung Analyse 2 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, 3. Anforderungsanalyse Analyse Entwurf tierung Integration Wartung 3.1. Verwendete Beispiele Anforderungs- System- ermittlung modellierung Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Beispiele: Seminarorganisation und Auktionssystem Verwaltung von Seminaren und Auktionsverwaltung und Teilnahme SeminarteilnehmerInnen - Auktion mit Dauern - Seminare und Termine - Angebote mit Beschreibungen und Gebote - Teilnehmende und Interessierte - Anbieter:innen, Bieter:innen, Auktionator:in - Rechnungen Zugriff über lokal installierte Software und eine Zugriff über eine Weboberfläche Weboberfläche - Auktion anlegen und verwalten - Teilnahmen buchen und verwalten - Nach Auktionen suchen und bei Auktionen - Abfragen stellen mitbieten - Angebotskatalog erstellen - Verwaltung der Auktionen - Statistiken erstellen - Abfragen und Statistiken Sicherheit? Was wird notwendig sein, um solche Systeme zu entwickeln? 4 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, 3. Anforderungsanalyse Analyse Entwurf tierung Integration Wartung 3.2. Anforderungsermittlung Anforderungs- System- ermittlung modellierung Prof. Bernhard Rumpe Literatur: Software Engineering Sommerville 5+6 RWTH Aachen Balzert Band 1, LE 2-4 http://www.se-rwth.de/ Requirements Engineering Analyse Anforderungs- (system analysis) spezifikation (Pflichtenheft, Anforderungs- requirements Ermittlung specification) "Lastenheft" (requirements Produktdefinition elicitation) (Funktionale Spezifikation, system specification) System- modellierung (system modelling) - Welches System sollen wir bauen? (bzw. welche Aspekte eines Systems verändern?) - Was sind die Anforderungen des Kunden? Entwurf - Ist es möglich, das geforderte System zu realisieren? 6 Software Engineering | RWTH Aachen Definitionen Anforderungsermittlung (requirements elicitation): - Tätigkeit: Feststellung der Anforderungen an das geplante System in Zusammenarbeit mit Kunden und potentiellen Benutzern - Ergebnis: Anforderungsspezifikation (Pflichtenheft) Systemmodellierung (system modelling) - Tätigkeit: Detaillierte und strukturierte Beschreibung der Anforderungen in einer Form, die als Grundlage für den Systementwurf dienen kann. - Ergebnis: Funktionale Spezifikation (Produktdefinition) Oberbegriff für beide Tätigkeiten: Analyse (engl. requirements analysis, system analysis) Requirements Engineering ist ein Name für das Teilgebiet des Software-Engineering, das sich mit den frühen Phasen der Entwicklung befasst. (Es gibt keinen wirklich adäquaten deutschen Begriff für requirements engineering.) 7 Software Engineering | RWTH Aachen Bedeutung der Anforderungsermittlung Kosten der Änderung von Fehlern aus der 60..100 x Aufforderungs -ermittlung 1x 1,5..6 x Anforderungs- Entwicklung Wartung definition Je später in der Entwicklung ein Fehler gefunden wird, um so aufwändiger ist seine Behebung. Jedoch: Moderne Prozesse wie XP versuchen diesen Anstieg zu drücken. nach [Pressman, S.17, Fig. 1.7] 8 Software Engineering | RWTH Aachen Funktionale/nicht-funktionale Anforderungen Funktionale Anforderung: - Beschreibung dessen, was das System tun soll - Bsp.: "Das System soll einen Mechanismus zur Identifizierung von Benutzern vorsehen." Nicht-funktionale Anforderung: - Einschränkende Bedingung, wie die funktionalen Anforderungen zu realisieren sind - Bsp.: "Der Identifizierungsvorgang muss in höchstens 5 Sekunden abgeschlossen sein." Mischfälle: - Bsp.: "Zur Identifizierung ist das Softwarepaket XY zu verwenden, von dem bekannt ist, dass es den Vorgang in höchstens 5 Sekunden bewältigt. à Zerlegbar in funktionale und nicht-funktionale Anforderungen 9 Software Engineering | RWTH Aachen Typen von nicht-funktionalen Anforderungen Anforderungen an das Produkt: Anforderungen an den Entwicklungsprozess: - Effizienzanforderungen: Zeit-, - Verwendung von Standards (V-Modell, UML,...) Speicheranforderungen - Anforderungen an die Implementierungstechnik - Zuverlässigkeitsanforderungen, „Quality of Service“ - Anforderungen an die Auslieferungsform - Betriebsrisiken, Bedrohungen - Ergonomische Anforderungen Externe Anforderungen: - Portabilitätsanforderungen - Interoperabilitätsanforderungen - Juristische Anforderungen: Sicherheit, Datenschutz, Zuverlässigkeit - Ethische Anforderungen 10 Software Engineering | RWTH Aachen Inhalte einer Anforderungsspezifikation Zielsetzung Allgemeine Beschreibung - Umgebung, generelle Funktion, Restriktionen, Benutzer Spezifische funktionale Anforderungen - möglichst quantitativ (z.B. Tabellenform) - eindeutig identifizierbar (Nummern) Spezifische nicht-funktionale Anforderungen - z.B. Antwortzeit, Speicherbedarf, HW/SW-Plattform - Entwicklungs- und Produkt-Standards Qualitäts-Zielbestimmung Zu erwartende Evolution des Systems - Grobe Identifikation von Versionen Formalia: Abkürzungsverzeichnis, Glossar, Index, Referenzen (sehr wirkungsvoll zur Konsistenzsicherung!) 11 Software Engineering | RWTH Aachen Beispiele funktionaler Anforderungen Produktfunktionen "Seminarorganisation" (Balzert I, S. 982), Auszug: Beispiel als textuelle Sammlung (zum Beispiel in einem Word-Dokument): Man beachte die Form der Nummerierung Kundenverwaltung /F10/ Ersterfassung, Änderung und Löschung von Kunden /F15/ Ersterfassung, Änderung und Löschung von Firmen, die Mitarbeiter zu Seminaren schicken /F20/ Anmeldung eines Kunden mit Überprüfung /F30/ - ob er bereits angemeldet ist /F40/ - ob der angegebene Seminarwunsch möglich ist /F50/ - ob das Seminar noch frei ist /F55/ - wie die Zahlungsmoral ist 12 Software Engineering | RWTH Aachen Gliederung nach Versionen (Beispiel) Beispiel als tabellarische Sammlung (zum Beispiel in einem Excel/Word-Dokument): Nr. Anforderung V1 (6/24) V2 (1/25) V3+ Funktionsgruppe 2 2.1 Mehrbenutzerfähigkeit nein erwünscht ja 2.2 Max. Anzahl Benutzer n/a 10 tbd … … Jargon: n/a = not applicable tbd = to be discussed... 13 Software Engineering | RWTH Aachen Grobes Vorgehen bei der Anforderungsermittlung System- Modellierung Anforderungsermittlung Anforderungs- Validation Anforderungs- Management: - Anforderungs- Fachliche Datenbanken Priorisierung Analyse - Verfolgung von Querbezügen - Iteratives Vorgehen Sammeln von Konflikt- Anforderungen Auflösung Integrieren Einordnen 14 Software Engineering | RWTH Aachen Analysephase als Kommunikationsleistung Die Wirklichkeit der Anforderungsermittlung: - Kreative, analytische und kommunikative Leistung - Hohe Bedeutung sozialer Kompetenz (offene, freundschaftliche, vertrauensfördernde Zusammenarbeit) - Weitere Kompetenzen: Urteilsfähigkeit, Kreativität, Erfahrung Hilfsmittel des Systemanalytikers: - Organisationsprinzipien und -werkzeuge für Informationen - Sammlung von bewährten Techniken (best practices) - Systemmodellierung Ein praxisrelevantes Hilfsmittel: - Unternehmens- und Geschäftsprozess-Modellierung "Attempt to understand before attempting to be understood." (Alan Davis in IEEE Software, Juli/August 1998) 15 Software Engineering | RWTH Aachen Probleme bei der Anforderungsermittlung 1. Viele Beteiligte in verschiedenen Rollen: 5. Verschiedene Beteiligte haben widersprüchliche Ziele. 1. Kunden, Benutzer 2. Informatik-Spezialisten 6. Organisatorische Rahmenbedingungen unklar oder 3. Betriebswirtschaft-Spezialisten veränderlich 4. Management, Marketing,... 7. Ständig veränderte Anforderungen, auch während 2. Kunden/Benutzer wissen meist nicht, was sie Analyse und Entwurf des Systems. wirklich wollen. 8. Neue Beteiligte während oder nach der Analyse 3. Fachsprachen, nicht allgemein verständliche Begriffe 9. Psychologische und soziale Randbedingungen: - z.B.: Mitarbeiter fürchten Rationalisierungseffekt und kooperieren deshalb schlecht. 4. Verschiedene Beteiligte verwenden inkonsistente - Mitarbeiter und Organisationen sind oft änderungsresistent Begriffe. 16 Software Engineering | RWTH Aachen Modelle in der Analysephase animated Analyse Anforderungs- (system analysis) Spezifikation (Pflichtenheft, Anforderungs- requirements Ermittlung specification) "Lastenheft" (requirements Produktdefinition elicitation) (Funktionale Spezifikation, system specification) System- modellierung (system modelling) Geschäftsprozessmodell Klassenmodell Anwendungsfallmodell Entwurf (business process model) (domain model) (use case model) 17 Software Engineering | RWTH Aachen Modelle werden in allen Disziplinen verwendet A model is an abstraction of an original made and used for a purpose. 18 Software Engineering | RWTH Aachen Modellierungssprachen & Standards General Purpose Languages - Versuchen viele unterschiedliche Zwecke zu vereinen - Standardisierungsorganisationen (z.B. Object Management Group, OMG) - Unified Modeling Language, UML § Unified Modeling Language § Vielzahl unterschiedlicher Diagrammtypen § Aktuelle Version: 2.5.1 § Varianten: z.B. UML/P für die Programmierung - Systems Modeling Language, SysML § Einsatz: Systems Engineering § Modellierung verschiedener komplexer Systeme § Diagrammtypen teilweise aus UML 2.0, modifiziert oder ganz neu § Aktuell: Version 1.5 Domänenspezifische Sprachen - Mehr dazu in Vertiefungen im Master! 19 Software Engineering | RWTH Aachen Diagrammtypen in der UML UML Diagramme Struktur Verhalten Zustands- Aktivitäts- diagramm Klassen- Kompositions- diagramm diagramm struktur- diagramm Use Case Diagramm Interaktion Objekt- Verteilungs- diagramm diagramm Kommunikations- Interaktions- Paket- Komponenten- diagramm diagramm diagramm diagramm Sequenz- Zeit- diagramm diagramm 20 Software Engineering | RWTH Aachen Geschäftsprozess (Business Process) "Unter einem Geschäftsprozess soll die zeitlich-logische Abfolge von Tätigkeiten zur Erfüllung einer betriebswirtschaftlichen Aufgabe verstanden werden, wobei eine Transformation von Material oder Information stattfindet.“ (Allweyer/Scheer 1995) GP-Modellierung ist eine typische Domäne der Wirtschaftsinformatik Beschreibung von Geschäftsprozessen Analyse und Optimierung von Geschäftsprozessen Ableitung einer flexiblen Infrastruktur für die effiziente Durchführung von Geschäftsprozessen 21 Software Engineering | RWTH Aachen Geschäftsprozess (Business Process) Geschäftsprozessmodellierung in der Systemanalyse: Zeitlich - vor der Erstellung der Anforderungsspezifikation Analyse des "IST-Zustands" - hilft bei Beurteilung der Ziele und des "SOLL" Grobe Geschäftsprozessmodelle - Hilfreich beim Finden von Beteiligten und globalen Belangen Detaillierte Geschäftsprozessmodelle - Hilfreich beim Finden von funktionalen Anforderungen und Anwendungsfällen 22 Software Engineering | RWTH Aachen Grobes Geschäftsprozessmodell Strategisch orientiert Ziel: Gesamtverständnis des Unternehmens und der Aufgabe Beispiel Notation an ARIS von Prof. Scheer angelehnt Markt- Seminar- Programm- Durch- forschung entwicklung planung führung Interne Vertrieb Schulung 23 Software Engineering | RWTH Aachen Detailliertes Geschäftsprozessmodell Beispiel: Ablauf einer Seminarbuchung AD Gewählte Darstellungsform: Teilnehmer Hauspost Sachbearbeiter Dozent Buchhaltung UML-Aktivitätsdiagramm "Swimlanes" zur Betonung Anmeldung verteilen prüfen von Akteuren Zusage Teilnehmer abwarten vorbereiten Teilnahme Es gibt auch andere Darstellungsformen: durchführen Datenflussdiagramme prüfen Workflow Modeling tats.Teilnehmer Languages abrechnen BPMN – Business Process Rechnung Modelling Notation 24 Software Engineering | RWTH Aachen Detailliertes Geschäftsprozessmodell Beispiel: Ablauf einer Seminarbuchung AD Externe Kommunikations- Teilnehmer Hauspost Sachbearbeiter Dozent Buchhaltung beziehungen: sogenannter System-Kontext verteilen prüfen Akteure für das zu abwarten vorbereiten entwickelnde System: - Akteure innerhalb der Systemgrenze und - „benachbarter“ Bediener durchführen des Systems prüfen abrechnen 25 Software Engineering | RWTH Aachen Digitale Transformation Wenn sie einen Scheißprozess digitalisieren, dann haben sie einen scheiß digitalen Prozess. Quelle: Thorsten Dirks, CEO von Telefónica Deutschland, am Wirtschaftsgipfel der 'Süddeutschen Zeitung‚ 2015 26 Software Engineering | RWTH Aachen Was haben wir gelernt? Anforderungsanalyse Zwei Arten von Modelle in der (System Analysis) Anforderungen Analyse Phase Besteht aus zwei Teilen, der Funktionale Anforderungen Unterschiedliche Arten für Anforderungsermittlung und beschreiben was das unterschiedliche Zwecke der Systemmodellierung System tun soll Aktivitätsdiagramme für die Anforderungsermittlung Nicht funktionale Geschäftsprozesse (Requirements Engineering) Anforderungen beschreiben Use-Cases für zur Feststellung der wie funktionale Anwendungsfälle Anforderungen an das Anforderungen zu Klassenmodell für die geplante System mit dem realisieren sind Beschreibung relevanter Ergebnis Konzepte Anforderungsspezifikation Glossar ist ein einfaches (Pflichtenheft) und wesentliches Hilfsmittel zur Konsistenzsicherung Fehler in der Anforderungsermittlung sind später teuer zu beheben 27 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, 3. Anforderungsanalyse Analyse Entwurf tierung Integration Wartung 3.4. Modellierung von Aktivitäten Anforderungs- System- ermittlung modellierung Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Warum, was, wie und wozu? Modellierung von Aktivitäten Warum? Was? Wie? Wozu? Software ist dazu da Erstellung von Verhalten (Funktionen) Gemeinsames zu bieten Aktivitätsdiagrammen Verständnis für Modellierung von Prozesse und Verhalten konkreter Arbeitsabläufe von Aktivitäten KundInnen mit Hilfe Verfeinerung von Use von Verständnis der DomänenexpertInnen Cases oder aus Geschäftsprozesse Anforderungen 29 Software Engineering | RWTH Aachen UML Aktivitätsdiagramme AD Beschreibung von Verhalten [Ja] [Nein] Modellierung von Geschäftsprozessen bzw. Kontrollflüssen zwischen A B - BenutzerInnen und Systemkomponenten Beschreibung von - parallelen, - sequentiell abhängigen, und C - alternativen Prozessen/Aktivitäten Werden oft als Verfeinerung von Use-Cases genutzt D E F 30 Software Engineering | RWTH Aachen Aktivitätsdiagramme (Verzweigung) Verzweigung und Zusammenfluss im Kontrollfluss Bedingungen (in eckigen Klammern), die wahr sein müssen, um eine Transition zu nehmen Bedingung [Ja] [Nein] Verzweigung A B Zusammenfluss C Nach Verzweigung kann nur A oder B ausgeführt werden; danach weiter bei C - Analog: if-then-else 31 Software Engineering | RWTH Aachen Aktivitätsdiagramme (Parallelität) Gabelung: - Verteilung einer eingehenden Transition auf mehrere parallel auszuführende Aktionen - An ausgehenden Transitionen dürfen keine Bedingungen stehen Vereinigung: - Bündelung mehrerer eingehender Transitionen zu einer Transition - Wird ausgeführt, sobald alle parallelen Aktivitäten beendet sind Gabelung D E Vereinigung F 32 Software Engineering | RWTH Aachen Aktivitätsdiagramme | Konzepte Oben stehen (optional) die Akteure (das sind Komponenten oder Klassen) Akteur1 Akteur2 Akteur3 Die Aktivitäten jedes Akteurs stehen dann in einer Swimlane. Aktivitäten (Rechtecke mit abgerundeten Ecken) = Aktionen A - Aktionsparameter repräsentieren Ein- und Ausgabe - Spezielle Send- und Accept-Message-Aktionen Transitionen zwischen Aktionen == Kontrollfluss A B Transitionen zwischen Ein- und Ausgaben von Aktionen == Objektfluss A B Objekt Gefüllter Kreis = Startknoten Bull‘s eye = Endknoten 33 Software Engineering | RWTH Aachen Stundenzettel archivieren Akteur AD MitarbeiterIn Sekretariat Zeichnungsbefugte [nicht ok] Stunden Stundenzettel Stundenzettel eintragen einreichen prüfen [ok] Stundenzettel Stundenzettel unterzeichnen Alle MitarbeiterInnen in Drittmittelprojekten müssen Stundenzettel führen. Dafür trägt ein/e MitarbeiterIn die Stunden in den virtuellen Stundenzettel ein und reicht diesen ein, wenn alle Stunden eines Monats erfasst sind. Das Sekretariat prüft den Stundenzettel z.B. ob an keinem Tag mehr als 10 Stunden gearbeitet wurde. Wenn dieser in Ordnung ist wird er an die Zeichnungsbefugten zur Unterzeichnung weiter geleitet. Wenn die Prüfung fehlschlägt muss die/der MitarbeiterIn die Stunden anpassen und den Stundenzettel wieder einreichen. AD im Vorlesungsstandard 34 Software Engineering | RWTH Aachen UML Aktivitätsdiagramme | Konzepte & Grundregeln Start AD Abläufe bestehen aus - Aktionen [Ja] [Nein] - Transitionen Verzweigung § Kontrollflüsse § Objektflüsse A B Port/Pin - Verzweigungen - Parallele Aufteilungen Aktion Optional: Akteure („Swimlanes“) Kontrollfluss C Start- und Endpunkt! - Wiederholung möglich Objektfluss Parallele Grundregeln Aufteilung - Parallele Aufteilungen immer wieder zusammenführen D E - Verzweigungen immer zusammen- oder rückführen - 1 Fluss in Aktion rein sowie 1 Fluss raus - Alles zu einem Endpunkt führen - Lesefluss: Links nach rechts, oben nach unten Ende F 35 Software Engineering | RWTH Aachen Beispiel: Welche Abläufe werden möglich? 3 Abläufe: register; welcome pack; assign to project; website; interview; report; pay register; welcome pack; website; assign to project; interview; report; pay register; assign to project; pay https://www.se-rwth.de/publications/ADDiff-Semantic-Differencing-for-Activity-Diagrams.pdf; AD im Vorlesungsstandard 36 Software Engineering | RWTH Aachen Evolution von ADs über die Projektlaufzeit. Wie verändert das die Abläufe? Abläufe geändert, jetzt: register; welcome pack; + assign to project; keys website; interview; report; pay (mit insgesamt 6 permutationen) (+1 alter) Assign keys kommt hinzu https://www.se-rwth.de/publications/ADDiff-Semantic-Differencing-for-Activity-Diagrams.pdf; AD im Vorlesungsstandard 37 Software Engineering | RWTH Aachen Weitere Evolution im Projekt: 3 Abläufe 7; Assign keys kommt hinzu 4; Assign keys vor project 4; Report auch https://www.se-rwth.de/publications/ADDiff-Semantic-Differencing-for-Activity-Diagrams.pdf; AD im Vorlesungsstandard wenn intern 38 Software Engineering | RWTH Aachen Was haben wir gelernt? Aktivitätsdiagramme Grundregeln Erstellung Beschreiben Verhalten Lesefluss: Links nach Analyse des Geschäftsprozessen bzw. rechts, oben nach unten Anwendungsfalls Kontrollflüssen zwischen Parallele Aufteilungen Gespräche mit BenutzerInnen und immer wieder DomänenexpertInnen Systemkomponenten zusammenführen und/oder aus einem Parallele, sequentiell Lastenheft Verzweigungen immer abhängige, und alternative zusammenführen Identifikation von Prozessen/Aktivitäten, die AkteurInnen und Aktivitäten über Transitionen 1 Fluss in Aktion rein sowie 1 Fluss raus verbunden sind Können sich über die Zeit Alles zu einem Endpunkt führen hinweg ändern und weiter entwickeln 39 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, 3. Anforderungsanalyse Analyse Entwurf tierung Integration Wartung 3.4. Use Case Modellierung Anforderungs- System- ermittlung modellierung Prof. Bernhard Rumpe Literatur: Software Engineering M. Hitz/G. Kappel, UML@Work, dpunkt 1999 RWTH Aachen http://www.se-rwth.de/ Warum, was, wie und wozu? Modellierung von Anforderungen Warum? Was? Wie? Wozu? Gut erhobene Anforderungen UML Use Case Diagramme bzw. Erhöht die minimieren Fehler im zu Übersichtlichkeit Anwendungsfallmodelle erstellenden System Modellierung von Anforderungen Text oft nicht Use Cases aus ausreichend um darüber Geschäftsprozessen und Bessere mit Kunden zu funktionalen Diskussionsbasis mit Kunden kommunizieren Anforderungen ableiten 41 Software Engineering | RWTH Aachen Modelle in der Analysephase Wiederholung Analyse Anforderungs- (system analysis) Spezifikation (Pflichtenheft, Anforderungs- requirements Ermittlung specification) "Lastenheft" (requirements Produktdefinition elicitation) (Funktionale Spezifikation, system specification) System- modellierung (system modelling) Geschäftsprozessmodell Klassenmodell Anwendungsfallmodell Entwurf (business process model) (domain model) (use case model) 42 Software Engineering | RWTH Aachen Anwendungsfälle (Use-Cases) | Grundbegriffe Ein Anwendungsfall (synonym Use-Case) ist die Beschreibung einer Klasse von Aktionsfolgen, die ein System ausführen kann, wenn es mit Akteuren interagiert. ("Systemgestützter Geschäftsprozess") Ein Akteur ist die Beschreibung einer Rolle, die ein(e) Benutzer(in) oder ein anderes System spielt, wenn er/sie/es mit dem System interagiert. - Mensch/Maschine, primär(=Nutznießer)/sekundär(=Mithelfer), aktiv/passiv Ein Akteur nimmt an einem Anwendungsfall teil, wenn er an einer der im Anwendungsfall beschriebenen Aktionen beteiligt ist. Beschreibung eines Anwendungsfalls: - Liste der Akteure (z.B. "Kundenbetreuer") - Name des Anwendungsfalls ("Anmeldungsstornierung") - Kurzer Beschreibungstext (oft nicht notwendig) 43 Software Engineering | RWTH Aachen Use-Case-Diagramm organisiert Anwendungsfälle | Beispiel und Konzepte Seminarverwaltung UC Systemgrenze Anmeldung prüfen Anwendungsfall Teilnehmer Anmeldung stornieren Veranstaltung anbieten Akteur Veranstaltung stornieren Verwaltungs- Dozenten system Sachbearbeiter zuordnen Katalog nimmt teil erzeugen 44 Software Engineering | RWTH Aachen Spezialisierung von Akteuren Spezialisierung eines Akteurs: - Die Rolle von Akteur B enthält die Rolle von Akteur A. - Notation: Vererbungsbeziehung A B - Semantik: Akteur B interagiert implizit auch mit allen Anwendungsfällen, die für Akteur A aufgeführt sind. Beispiel: Sachbearbeiter Programmverwalter 45 Software Engineering | RWTH Aachen Spezialisierung von Anwendungsfällen Spezialisierung eines Anwendungsfalles: - Anwendungsfall B ist eine spezielle Variante von Anwendungsfall A. A B - Notation und Semantik: Vererbungsbeziehung. Beispiel: Veranstaltung anbieten Veranstaltung Veranstaltung neu anbieten wieder anbieten 46 Software Engineering | RWTH Aachen Abstrakte Anwendungsfälle Abstrakter Anwendungsfall: - Ein Anwendungsfall, der nicht eigenständig durch Aktionsfolgen realisiert wird, sondern nur Gemeinsamkeiten anderer Anwendungsfälle festhält. - Oft beziehen sich abstrakte Anwendungsfälle auf abstrakte Klassen. Spezialisierung von Anwendungsfällen ist meist von dieser Art. Beispiel: {abstract} Veranstaltung anbieten Veranstaltung Veranstaltung neu anbieten wieder anbieten 47 Software Engineering | RWTH Aachen Einbindung von Anwendungsfällen Einbindung (include) eines Anwendungsfalles: - Anwendungsfall B wird „aufgerufen“ in Anwendungsfall A. A B - B ist ein unbedingt notwendiger „Unter-Anwendungsfall“ von A. - Zweck: Erhöhung der Wiederverwendung; Strukturierung Beispiel: Anmeldung prüfen Dopplung Seminarwunsch Freie Plätze Kd.-Bonität Mitteilung prüfen prüfen prüfen prüfen versenden 48 Software Engineering | RWTH Aachen Erweiterung von Anwendungsfällen Erweiterung (extend) eines Anwendungsfalles: - Anwendungsfall A kann durch Anwendungsfall B „ergänzt“ werden. A... B - Anwendungsfall A muss explizite „Anknüpfungspunkte“ (extension points) für B vorsehen - Tatsächliche Ausführung von B hängt von speziellen Bedingungen ab. Beispiel: Ersatzbuchung Seminar- Anmeldungs- buchung stornierung extension points Zusatzwunsch Katalog- Katalogwunsch anforderung 49 Software Engineering | RWTH Aachen Genaue Spezifikation der Erweiterung Wenn mehrere extension points angegeben sind, ist es notwendig, den betroffenen extension point einer Erweiterung anzugeben (in runden Klammern). Es kann darüber hinaus sinnvoll sein, Bedingungen für die Erweiterung anzugeben (in eckigen Klammern). (Beilage) [1 Jahr keine Buchung] Katalogbestellung erneuern Katalog zusenden (Beilage) extension points [Umsatz > 1000 €] Beilage Sonderkonditionen Rückfrage anbieten (Rückfrage) [2 Jahre keine Buchung Tel. Rückfrage und Umsatz > 1000 €] 50 Software Engineering | RWTH Aachen Anwendungsfall-Beziehungen: Vergleich Akteur interagiert mit… B Spezialfall von A B A B (und realisiert Funktionalität von A) B notwendiger Teil von A A A B (und weiß nichts von B) A B optionaler Zusatz zu A A und B... B (im Allgemeinen) 51 Software Engineering | RWTH Aachen Strukturierung in Pakete Programmverwaltung Veranstaltung anbieten Veranstaltung Programm- stornieren Sachbearbeiter verwalter Dozenten zuordnen Katalog erzeugen Programm- „Ikonifizierte" Ansicht: verwaltung 52 Software Engineering | RWTH Aachen Wie? | Use-Cases aus Geschäftsprozess-Modellen AD animated Teilnehmer Sachbearbeiter Dozent Anmeldung prüfen Zusage Teilnehmer abwarten vorbereiten Teilnahme System- durchführen grenze prüfen tats.Teilnehmer Dozent Anmeldung Durchführungs- Teilnehmer prüfen meldung prüfen Sachbearbeiter 53 Software Engineering | RWTH Aachen Wie? | Use-Cases aus funktionalen Anforderungen 4.1 Kundenverwaltung /F10/ Ersterfassung, Änderung und Löschung von Kunden /F15/ Ersterfassung, Änderung und Löschung von Firmen, die Mitarbeiter zu Seminaren schicken /F20/ Anmeldung eines Kunden mit Überprüfung /F30/ - ob er bereits angemeldet ist /F40/ - ob der angegebene Seminarwunsch möglich ist /F50/ - ob das Seminar noch frei ist /F55/ - wie die Zahlungsmoral ist Anmeldung Erfassung prüfen eines Kunden ? Änderung eines Kunden ? 54 Software Engineering | RWTH Aachen Anwendungsfälle: Detaillierungsgrad Was ist ein Anwendungsfall? Erstrebenswerte Ziele: - Menüpunkt für den Anwender (sehr detailliert?) - Gute Strukturierung - Abstrakte Systemfunktion - Abstrakte, allgemeine Anwendungsfälle § Niemals Anwendungslogik in Anwendungsfällen - Benutzerziel (sehr abstrakt?) codieren § Ggf. Aktivitätsdiagramm(e) für komplexe Anwendungsfälle Gefahren: - Anwendungsfälle & Szenarien hinreichend detailliert § geeignet als Testfälle - Vielzahl von Anwendungsfällen: Unübersichtlichkeit - Detaillierte Szenarien: Niedriger Abstraktionsgrad - Anwendungsfälle & Szenarien als Vertrag: Unvollständigkeit 55 Software Engineering | RWTH Aachen Was haben wir gelernt? Anwendungsfälle (Use-Cases) Use Case Diagramme Erstellung beschreiben die strukturieren Identifikation in Systemfunktionalität, Anwendungsfälle bestehenden die zu bewältigenden bestehen aus: Geschäftsprozessen bzw. Aufgaben und als Erweiterung von diesen Akteuren, deren Anwender (Akteure) Anwendungsfällen Identifikation in funktionalen Anforderungen Wer nimmt an welchem Anwendungsfall teil?... Spezialfall von... , - Beziehungen 56 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, 3. Anforderungsanalyse Analyse Entwurf tierung Integration Wartung 3.5. Prototyping Anforderungs- System- ermittlung modellierung Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Warum, was, wie und wozu? Prototypen in der Analyse Warum? Was? Wie? Wozu? Realisierbarkeit von Erstellung des Anwendungen und Konzepten Prototyps aus den Erstellung von Anforderungen überprüfen Bessere explorativen bzw. experimentellen Planbarkeit der zu entwickelnden Risiken minimieren Prototypen für die Analyse Anwendung (nicht in falsche Feedback von Richtung AnwenderInnen entwickeln) 58 Software Engineering | RWTH Aachen Prototyping und Prototypen Prototyp in klassischen Ingenieurdisziplinen: Prototyp in der Software-Entwicklung: - Problemlos in Serie fertigbar - Erstes Exemplar, Modell für ein neues Produkt - Erstes Exemplar, Modell für ein neues Produkt - Voll funktionsfähig - Nicht voll funktionsfähig - Noch nicht in Serie fertigbar - kurze Entwicklungszeit, preisgünstig - “Rapid Prototyping” - Lange Entwicklungszeit, teuer - Zwecke: § Frühe Einbindung von AnwenderInnen in die Entwicklung § Rechtzeitige Abklärung der Realisierbarkeit und von Risiken Deshalb: Einsatz bereits in der Analysephase sinnvoll 59 Software Engineering | RWTH Aachen Klassifikation von Prototyping Weiterverwendung Phase im Phasenmodell Zielgruppe des Prototyps (vorwiegend) explorativ wegwerfen Analyse Anwender, Systemanalytiker experimentell wegwerfen (Analyse,) Entwickler Entwurf, Implementierung evolutionär ausbauen Entwickler, Anwender (inkrementelle (sinnvoll nur bei Entwicklung) evolutionärer Entwicklung) 60 Software Engineering | RWTH Aachen Vorgehensweise beim Explorativen Prototyping Anforderungs- Ermittlung Bau eines Basis-Prototyps Experimente Änderung, mit Prototyp Erweiterung Stabilisierung des Prototyps Überarbeitung der Anforderungen zusätzliche Anwenderbeteiligung... 61 Software Engineering | RWTH Aachen Beispiel Evolutionäres Prototyping Web-Plattform im MaCoCo (Management Cockpit for - Agile, modell-basierte und generative Controlling) Projekt Entwicklungsmethoden: Inkrementelle Artefakte - Prototyp: Stand Ende 2017 62 Software Engineering | RWTH Aachen Beispiel Evolutionäres Prototyping Web-Plattform im MaCoCo (Management Cockpit for Controlling) Projekt - Version 1.13.2 (Oktober 2019) - Version 2.14.0 (Oktober 2024) 63 Software Engineering | RWTH Aachen Was haben wir gelernt? Prototypen Arten Zweck Erstes Exemplar bzw. Explorativ Frühe Einbindung von Modell für ein neues Für Analyse Phase AnwenderInnen in die Produkt Entwicklung Danach wegwerfen Nicht voll funktionsfähig Zielgruppe: Anwender Rechtzeitige Abklärung und Systemanalytiker der Realisierbarkeit und Kurze Entwicklungszeit, von Risiken preisgünstig Experimentell (Analyse,) Entwurf, Implementierung wegwerfen Evolutionär weiterentwickeln 64 Software Engineering | RWTH Aachen