Software-Engineering Objektorientierte Konzepte des Software-Engineering 5.2 UML Unified Modeling Language

Transkript

1 Software-Engineering Objektorientierte Konzepte des Software-Engineering 5.2 UML Unified Modeling Language Prof. Dr. Rolf Dornberger Software-Engineering: 5 Definitionsphase Objektorientierte Konzepte

2 5.3 UML Unified Modeling Language 1. Einleitung 2. Anwendungsfälle / Geschäftsprozesse Use Cases 3. Aktivitätsdiagramm Activity Diagram 4. Klassen und Objekte Classes and Objects 5. Pakete Packages 6. Kollaborationsdiagramm Collaboration Diagram 7. Interaktions- und Sequenzdiagramm Interaction and Sequence Diagram 8. Zustandsdiagramm State Diagram 9. Auslieferungsdiagramm und Komponentendiagramm Deployment Diagram and Component Diagram 10. Zusammenfassung

3 1 Einleitung Dieses Kapitel UML basiert auf dem Modul Introduction into UML, das im Rahmen des Sweed-Projektes (Software-Engineering-Education) erarbeitet wurde: Englischsprachige Folien IN-A1-uml.pdf ( Prof. Martin Kropp, FHSO, 2001) SWEED Introduction into UML A Practical Approach Martin Kropp University of Applied Sciences Solothurn / NWS

4 1 Einleitung Warum modellieren wir? Strukturierung der Problemlösung Standardisierung der Kommunikation Komplexität so lange abstrahieren, bis das Problem besser verständlich wird Testen verschiedener Lösungen Risiko von Fehlern beherrschbar machen Entwicklungskosten senken Warum modellieren wir grafisch? Ein Bild sagt mehr als tausend Worte

5 1 Einleitung UML (Unified Modeling Language) ist eine graphische Modellierungssprache vereinigt viele Basiskonzepte des Software-Engineering wird in der objektorientierten Sichtweise im Software-Engineering eingesetzt unterstützt vor allem Planung, Spezifikation, Design und Dokumentation einer Software- Entwicklung kann über alle Phasen der Software-Entwicklung kontinuierlich eingesetzt werden ist unabhängig von einer Programmiersprache

6 1 Einleitung UML bietet für die einzelnen Modellierungsschritte einer Software-Entwicklung speziell in der objektorientierten Analyse (OOA) jeweils bestimmte standardisierte grafische Elemente an. UML kennt speziell von Planungs- über Definitions- bis Entwurfsphase grafische Elemente für Geschäftsprozesse (use cases) Klassen und Objekte (classes and objects) sowie Pakete (packages) Aktivitätsdigramm (activity diagram) Interaktions- und Sequenzdiagramm (interaction and sequence diagram) Zustandsdiagramm (state diagram) sowie weitere Diagrammtypen

7 1 Einleitung Die einzelnen Diagrammtypen von UML werden im Allgemeinen zu folgenden Zeitpunkten einer Software-Entwicklung eingesetzt: I n c e p t i o n Planungsphase E l a b o r a t i o n Definitionsphase C o n s t r u c t i o n Entwurfsphase T r a n s i t i o n Use Cases Class Diagram Object Diagram Activity Diagram Collaboration diagram Interaction / Sequence Diagram Package Diagram State Diagram Component Diagram Deployment Diagram

8 2 Anwendungsfälle / Geschäftsprozesse Use Cases Anwendungsfälle (use cases), als Spezialfälle von Geschäftsprozessen, beschreiben die Interaktion von Akteuren (Benutzern) mit einem Computersystem zu einem bestimmten Zweck. Beispiele: Teilnehmer meldet sich online für einen Fortbildungskurs an Kunde benutzt Bancomat, um Geld abzuheben 2 Jugendliche chatten über Internet, um Neuigkeiten auszutauschen Buchhalter tippt Zahlen in sein Accounting-System für den Jahresabschluss ein Student spielt Computerspiel, weil es Spass macht... Anwendungsfälle / Geschäftsprozesse beschreiben die funktionalen Ansprüche an das System, ohne vertieft auf interne Details einzugehen. Anwendungsfälle / Geschäftsprozesse werden grafisch mit einem Geschäftprozessdiagramm (Anwendungsfalldiagramm) und verbal in einem Text beschrieben

9 2.1 Geschäftsprozessdiagramm Anwendungsfälle / Geschäftsprozesse werden grafisch in einem Geschäftprozessdiagramm (Anwendungsfalldiagramm) dargestellt. Folgende Elemente werden dafür verwendet: Akteure (actors), ein Benutzer oder auch ein anderes externes System, welche mit den Geschäftsprozessen interagieren Anwendungsfälle / Geschäftsprozesse (use cases), die in einem bestimmten Szenario (scenario) aktiviert werden Beziehungen (relationships) zwischen Akteuren und Geschäftsprozessen Online Kursregistrierung Geschäftsprozess / Anwendungsfall online Kurs registrieren Rechnungsstellung Akteur Anfragen senden Kunde Beziehung Kommentar senden

10 2.1 Geschäftsprozessdiagramm Erweiterungen in Geschäftsprozessdiagrammen sind Systemgrenzen (system boundaries) erweiterte Beziehungen (include und extend relationsships) Verallgemeinerungen (generalization) Customer <<include>> Browse Course Catalog Register for Course Request for Information Course Registration Enter Personal Data <<include>> Relationship Billing Base Use Case Extending Use Case Generalization <<extend>> Specialized Use Case Base Use Case extensionpoint1 extensionpoint2 System Boundary Send Comment Extension

11 2.2 Beschreibung von Geschäftsprozessen Für die verbale Beschreibung von Anwendungsfällen / Geschäftsprozessen gibt es verschiedene Vorlagen (Schablonen) in den unterschiedlichsten Sprachen, z.b.: Geschäftsprozess Ziel Kategorie Vorbedingung Nachbedingung Erfolg Nachbedingung Fehlschlag Akteure Auslösendes Ereignis Beschreibung Erweiterung Alternativen Use Case {give declarative unique name} ID {give unique identifier, list here also the modification history} Actors {list all actors involved with the use} Description {give short description of the goals to be achieved by the use case and sources for the requirements} Pre-Condition {describe the conditions in which the system must be so that the use case can be executed} Post- Condition {describe the conditions in which the system must be after the use case has been executed} Steps {describe step by step the interactions between the actors and the system that are necessary to achieve the goal. Describe the standard scenario, enumerating each step} Variations {describe possible variations for the steps from above. Reference each variation with the step number from above} Open Issues {list any open issues that remain to be solved}

12 2.3 Checkliste für Geschäftsprozesse Ergebnisse Geschäftsprozessdiagramm Alle Geschäftsprozesse und Akteure sind eingetragen Beschreibung der Anwendungsfälle / Geschäftsprozesse Alle Geschäftsprozesse sind umgangssprachlich oder mittels Schablone beschrieben Konstruktive Schritte 1 Akteure ermitteln Welche Personen führen diese Aufgaben zur Zeit durch und besitzen daher wichtige Kenntnisse über die durchzuführenden Arbeitsabläufe? Welche Rollen spielen diese Personen? Welche Personen werden zukünftig diese Aufgaben durchführen und auf welche Vorkenntnisse muss die Benutzungsoberfläche abgestimmt werden? Welche Rollen spielen diese Personen? Wo befindet sich die Schnittstelle des betrachteten Systems bzw. was gehört nicht mehr zu dem System?

13 2.3 Checkliste für Geschäftsprozesse 2 Geschäftsprozesse für die Standardverarbeitung ermitteln Primäre und ggf. sekundäre Geschäftsprozesse betrachten Welche Standardverarbeitung besitzen sie? 2a mittels Akteuren Sind die Akteure Personen? Welche Arbeitsabläufe lösen sie aus? An welchen Arbeitsabläufen wirken sie mit? 2b mittels Ereignissen (Akteure = externe Systeme) Erstellen einer Ereignisliste Für jedes Ereignis einen Geschäftsprozess identifizieren Externe und zeitliche Ereignisse unterscheiden 2c mittels Aufgabenbeschreibungen Was sind die Gesamtziele des Systems? Welches sind die zehn wichtigsten Aufgaben? Was ist das Ziel jeder Aufgabe?

14 2.3 Checkliste für Geschäftsprozesse 3 Geschäftsprozesse für Sonderfälle formulieren Erweiterungen und Alternativen mittels Schablone erstellen Aufbauend auf Standardfunktionalität mit extend die Sonderfälle formulieren, d.h. erweiterte Geschäftsprozesse beschreiben 4 Aufteilen komplexer Geschäftsfälle Komplexe Schritte als eigene Geschäftsprozesse spezifizieren (include) Komplexe Geschäftsprozesse (viele Sonderfälle) in mehrere Geschäftsprozesse zerlegen und Gemeinsamkeiten mit include modellieren Umfangreiche Erweiterungen als Geschäftsprozesse spezifizieren (extend) 5 Gemeinsamkeiten von Geschäftsprozessen ermitteln Auf redundanzfreie Beschreibung achten (include)

15 2.3 Checkliste für Geschäftsprozesse Analytische Schritte 6»Gute«Beschreibung Verständlich für den Auftraggeber Extern wahrnehmbares Verhalten Fachliche Beschreibung des Arbeitsablaufs Standardfall vollständig und Sonderfälle separat Maximal eine Seite 7 Fehlerquellen Zu kleine und damit zu viele Geschäftsprozesse Zu frühe Betrachtung von Sonderfällen Zu detaillierte Beschreibung Verwechseln von include und extend Geschäftsprozesse beschreiben Dialogabläufe

16 3 Aktivitätsdiagramm Activity Diagram Aktivitätsdiagramme visualisieren den Ablauf und die Reihenfolge der einzelnen Geschäftsprozesse respektive Aktivitäten (activity) von Anfang (start) bis Ende (end) folgen Verzweigungen (branch) je nach erfüllter Entscheidung (guard) unterstützen die Analyse der Geschäftsprozesse sind ähnlich den Flussdiagrammen bzw. Programmablaufplänen Start Activity Browse Course Catalog Select Course Info Enter Personal Data Guard Branch Confirm Registration [data correct] End [else] Update Course Send Print Bill

17 3 Aktivitätsdiagramm Activity Diagram Aktivitätsdiagramme können auch komplexere Formen annehmen. Mittels Aufteilung (fork), Zusammenführung (join) und Entscheidungen können auch parallel ablaufende Geschäftsprozesse sehr gut beschrieben werden. Zusam menführung (join) Aufteilung (fork) Verarbeitung2 Verarbeitung3 Verarbeitung1 [Bedingung1a] Verarbeitung4 Entscheidung [Bedingung1b] [Bedingung2b] [Bedingung2a] Verarbeitung6 Verarbeitung5 Customer Registration System Database System Billing System Browse Course Catalog [else] [data correct] Confirm Registration Select Course Info Enter Personal Data Fork Send Update Course Print Bill Join

18 4 Klassen und Objekte Classes and Objects Zusammenhänge zwischen mehreren Klassen respektive Objekten werden jeweils in Klassen- oder Objektdiagrammen angeordnet. Diese Klassen- und Objektdiagramme stellen statische Beziehungen der Klassen respektive der Objekte untereinander dar. Folgende Grundelemente werden dazu verwendet: Name Class Object:Class Object Attributs Operations Attribut1 = value1 Generalization 0..* 0..1 works at employs Multiplicity Roles Association Aggregation Composition

19 4 Klassen und Objekte Classes and Objects Klassen und Objekte werden am besten in separaten Diagrammen dargestellt. Class Person name address Represents common responsibilities for lecturer and customer Klassendiagramme sind immer eine abstrakte, allgemeine Modellierung des Problems. Z.B.: Es gibt nur allgemein Kunden. Lecturer tenure settenure() 1 Customer private creditcard# regforcourse() getcreditcard() participant Multiplicity Comment Objektdiagramme sind immer die spezielle Modellierung des Problems. Z.B.: Es gibt genau die 3 Kunden Schulz, Wenzel und Schröder. 0..* 0..* CourseOffering location date addparticipant() addlecturer() 1..* 1 Course name ID Zusätzlich können Kommentare (comment) an die Klassen bzw. Objekte gehängt werden. zw ölft ever anst alt ung: Ver anst alt ung Schröder: Kunde OOA: Sem inartyp Herbst: Dozent Sch ul z: Ku nd e Wenz el: Kun de

20 5 Pakete Packages Pakete (packages) ermöglichen das Zusammenfassen verschiedener Elemente. Pakete werden meistens dazu verwendet, zusammengehörige Klassen zusammenzufassen. Zwischen einzelnen Paketen kann es Abhängigkeiten (dependency) geben, z.b. Assoziationen zwischen einzelnen Klassen. In Paketen können auch andere Pakete gebündelt werden. Package Registration UI AWT Registration UI AWT Registration Application Dependency Registration Application Domain Courses Persons Courses Persons

21 6 Kollaborationsdiagramm Collaboration Diagram Kollaborationsdiagramme veranschaulichen, wie Objekte in einem speziellen Szenario miteinander verknüpft sind geben die statischen Beziehungen zwischen Objekten an zeigen die Abfolge (sequence number), in der Objekte (object) Botschaften (message) miteinander austauschen 1: Operation1() :Klasse1 {transient} 2: Operation2() :Klasse2 {new} 2.1: Operation3() :Klasse3 {new} 3: Operat ion4() :Klasse4 aregistrati onform Message 1.2: [not a Cust] new(joe) joe : Participant 1: register(joe, acourselist) aregistrati onmanager 1.4: delete() Object Sequence Number 1.3.1: save(joe) 1.3:*[for all courses] addparticipant(joe) acourse: Course 1.1: getcustomer(joe)

22 7 Interaktions- und Sequenzdiagramm Interaction and Sequence Diagram Interaktions- bzw. Sequenzdiagramme sind eine Erweiterung der Kollaborationsdiagramme geben die dynamischen Beziehungen zwischen Objekten an zeigen den zeitlichen Ablauf, wie Objekte für gewisse Zeitabstände Botschaften untereinander austauschen Bereits existierende Objekte Akteur erstesob jekt :Kl asse1 :Klasse2 Operation1() Bo tsch af t Klasse3() Neu erzeugtes Objekt neuesobjekt :Klasse3 Operation5() Objekt schickt Botschaft an sich selbst Operation3() Operation2() Objekt wird gelöscht Balkenlänge gibt die relative Dauer der Aktivität an

23 7 Interaktions- und Sequenzdiagramm Interaction and Sequence Diagram Interaktions- bzw. Sequenzdiagramme beschreiben, welche neuen Objekte angelegt (creation) und wieder gelöscht (deletion) werden welche Ergebnisse zurückgeliefert (return) werden welche Botschaften (message) eine Aktivierung (activation box) von Objekten (object) mit gewissen Bedingungen (condition), Iterationen (iteration) und Rekursionen (self delegation) bewirken aregistrationf orm aregistrationm anager Object acourse: Course register(joe, acourselist) acust = getcustomer(joe) Message Condition [not acust] a Cust = new(joe) Creation Joe: Customer Self Delegation Iteration *[for all courses] addparticipant(acust) numpart Return Activation Box delete() Deletion

24 8 Zustandsdiagramm State Diagram Zustandsdiagramme beschreiben, Buch defekt / entfer nen() welche verschiedenen Zustände (state) ein Objekt über verschiedene Geschäftsprozesse von Anfang (start) bis Ende (end) annehmen kann welche Zustandübergänge (transition) möglich sind und welche Aktivitäten (activity) diese bewirken welche Werte die Attribute eines Objektes in einem bestimmten Zustand annehmen können Class: Course Offering präsent ausgeliehen Buch v erloren / entfer nen() Ausleihwunsch / vorbestellen() neues Buch liegt vor / er fassen() after (Abholfrist vorbei) Ausleihwunsch / ausleihen() Leser gibt Buch zurück / zurückgeben() vorbestellt Leser holt Buch ab / ausleihen() zur Abholung bereit Leser gibt Buch z ur ück / zurückgeben() Start Activity Initialized do: Initialize course new Participant / Set Count = 0 new Participant [count < 10] Canceled State Canceled new Participant [count < 10] Canceled notify registered participants Canceled Open when (count = 10) Closed notify registered entry: register participant students Transition End

25 9 Auslieferungsdiagramm und Komponentendiagramm Deployment Diagram and Component Diagram UML kennt noch die weiteren Diagramme Auslieferungsdiagramm Deployment Diagram Komponentendiagramm Component Diagram Diese beschreiben Details über die Einheiten (node) von Komponenten (component), die Schnittstellen (interface) und Netzwerk-Verbindungen (connections). Das Auslieferungsdiagramm beschreibt die Konfiguration der einzelnen Software- und Hardware-Elemente, Prozesse und Objekte. Das Komponentendiagramm beschreibt die Abhängigkeiten der einzelnen Software- Komponenten (Quellcode, Binary, Executables). :Web Server :Domain.DLL :Regist. App TCP/IP :Windows PC :Regist Applet Connection TCP/IP Node anoracledb:db Server :Oracle.Dll Database Interface :Browser Component

26 10 Zusammenfassung Anwendungsfälle / Geschäftsprozesse fassen die Anforderungen an das zu entwickelnde System zusammen. Aktivitätsdiagramme verdeutlichen den (teilweise parallelen) Ablauf der Geschäftsprozesse. Klassen- und Objektdiagramme beschreiben die statische Struktur von Konzepten, Typen, Klassen und Objekten. Paketdiagramme zeigen die Gruppierung von Klassen und ihre Abhängigkeiten untereinander. Kollaborationsdiagramme zeigen die statischen Beziehungen zwischen Objekten und geben ihnen eine Abfolge. Interaktions- und Sequenzdiagramme zeigen die dynamischen Beziehungen zwischen Objekten, ihre Erzeugung und Löschung. Zustandsdiagramme zeigen die Zustände, die ein Objekt annehmen kann und die Aktivitäten bei den jeweiligen Zustandsübergängen. Auslieferungs- und Komponentendiagramme beschreiben das physikalische Layout des Systems