Softwaretechnik. Was haben wir bisher erreicht? Was machen wir heute? Methodische und Praktische Grundlagen der Informatik (MPGI 3) WS 2008/09

Transkript

1 Methodische und Praktische Grundlagen der Informatik (MPGI 3) WS 2008/09 Softwaretechnik Steffen Helke Andreas Mertgen (Organisation) Rojahn Ahmadi, Georgy Dobrev, Daniel Gómez Esperón, Simon Rauterberg, Jennifer Ulrich (Tutoren) Was machen wir heute? Werkzeug-Vorführung IBM Rational Software Modeler Statische Modellierung UML-Klassendiagramme (Wiederholung) Verhaltensmodelle in der UML Anwendungsfalldiagramme (Use-Case-Modelle) Sequenzdiagramme 2 Was haben wir bisher erreicht? Problembereich Textuelle Anforderungen nberater Klassenmodelle Verwaltet Werkstatt Nimmt_auf Analyse Analyse,. Schritt: Klassenmodell Klassenmodell Anforderungsdefinition Schnittstellenmodell Sequenzdiagramme Aktivitätsdiagramme Use-Case-Modell Analyse-Klassenmodell Vor- und Nachbedingungen von System-Operationen Data Dictionary 3

2 Notationen für Klassenmodelle Textuelle Anforderungen an Software Name Anmelden Erteilt Erteilt nberater Klassen: Namen, Attribute und Methoden Assoziationen: Namen, Leserichtung, Rollen Assoziationsklassen, mehrstellige Assoziationen Aggregationen: Ist-Teil-von-Beziehungen Kompositionen: exklusiv und existenzabhängig Multiplizitäten: Namen, Leserichtung und Rollen Generalisierung/Spezialisierung: Strukturierungsmittel auf Typebene, Schlüsselwörter: complete, incomplete, disjoint, overlapping 5 Ein erteilt einen Reparaturauftrag für sein Auto. Der wird im von einer oder einem mechaniker aufgenommen. Für jeden wird zunächst eine Reparaturanweisung erstellt. Ein freier Mechaniker druckt diese an einem Terminal in der Werkstatt aus und übernimmt damit die Reparatur. Nach erfolgter Reparatur ergänzt der Mechaniker die am Terminal um die Schadensbehebung (Arbeitsstunden und verbrauchtes Material). Zusätzlich festgestellte Schäden oder fehlendes Material werden in der vermerkt und die weitere Vorgehensweise wird ans verwiesen. 6 Softwaresystem für eine -Werkstatt Ein erteilt einen Reparaturauftrag für sein Auto. Softwaresystem für eine -Werkstatt Ein erteilt einen Reparaturauftrag für sein Auto. Der wird im von einer oder einem mechaniker aufgenommen. Nimmt_auf Erteilt Erteilt Ist_Halter_von Ist_Halter_von nberater

3 Softwaresystem für eine -Werkstatt Für jeden wird zunächst eine Reparaturanweisung erstellt. Softwaresystem für eine -Werkstatt Ein Mechaniker druckt in der Werkstatt en aus und übernimmt Reparatur. Nimmt_auf Nimmt_auf Bearbeitet Mechaniker Erteilt Erteilt Repariert Ist_Halter_von Ist_Halter_von nberater nberater Softwaresystem für eine -Werkstatt Fehlendes Material wird in einer vermerkt und zur Bearbeitung ans verwiesen. Softwaresystem für eine -Werkstatt Der mechaniker arbeitet auch in der Werkstatt. Bestellt Material Nimmt_auf Braucht Bearbeitet Mechaniker Bestellt Material Nimmt_auf Braucht Bearbeitet Mechaniker Erteilt Ist_Halter_von Repariert Frage: Erteilt Ist_Halter_von Repariert nberater Welche Objekte modellieren wir mit der Klasse Material genau? nberater

4 Welche Objekte modellieren wir mit einer Klasse? Variante : Objekt beschreibt echtes Material Material Braucht Variante 2: Objekt beschreibt die Material-Art Material-Art Variante 3: Objekt beschreibt einen Material-Lagerposten Material-Art 0.. Braucht Anzahl n: Nat Braucht Besitzt Lagerposten n: Nat Benötigt Kommuniziert_mit 2 Material Bestellt Nimmt_auf Erstellt 0.. Basiert_auf nberater Wird_bestellt_bei Braucht 0.. Rechnung Erteilt.. Ist_Halter_von Anbieter.. Führt_Material_für Bearbeitet.. Werkstatt Mechaniker.. Repariert Ist_vom_Typ Modell Konventionen zur besseren Lesbarkeit Klassen: Großer Anfangsbuchstabe, Substantiv Assoziationen: Großer Anfangsbuchstabe, Zusammengesetzte Bezeichner durch _ trennen, Verben im Singular verwenden Use-Case-Modelle und Sequenzdiagramme Textuelle Anforderungen? Klassenmodelle nberater Werkstatt Verwaltet Nimmt_auf Verhaltensmodelle z.b. Überprüfen der Regel Klasse & Assoziation & Klasse = Satz :Mechaniker 5

5 Analyse, 2. Schritt: Use-Case-Modelle Analyse Klassenmodell Anforderungsdefinition Schnittstellenmodell Sequenzdiagramme Use-Case-Modell Akteure Aktivitätsdiagramme (actors) Aktionsfolgen Analyse-Klassenmodell Beziehungen: Vor- include und Nachbedingungen extend von System-Operationen generalize Data Dictionary Use-Case-Modell Erster Schritt, um das mögliche Verhalten des Systems zu beschreiben (Anwendungsfälle) Akteure (actors) sind außerhalb des Systems repräsentieren verschiedene Benutzerrollen Anwendungsfälle (Use-Case) Menge von Aktionsfolgen jede Folge beschreibt mögliche Interaktion der Akteure mit dem System (Szenario) von Akteur angestoßen System liefert beobachtbares Ereignis von Wert 8 UML-Notation: Use-Case-Modell Beschreibung von Use-Cases Akteur Kommunikation E-Commerce Use Case System Use-Cases kapseln Verhalten Normalfälle Ausnahmefälle Konkretisierung von Use-Cases mit Szenarien, die als Sequenzdiagramme dargestellt werden. Sequenzdiagramme sind nächster Schritt in der Analyse! 9 20

6 Verbale Beschreibung von Use-Cases Beziehungen zwischen Use-Cases Use-Case Normalfall System fragt n nach PIN; tippt PIN ein; System prüft Richtigkeit der PIN Ausnahmefälle Benutzer bricht Transaktion ab; Benutzer hat sich vertippt, drückt Taste CLEAR; Benutzer gibt dreimal falsche PIN ein Place Order Einbindung Check Password «extend» Gen / Spec Place Rush Order Erweiterung Retinal Scan 2 22 Generalisierung / Spezialisierung von Use-Cases Einbindung eines Use-Case Verschiedene Use Cases realisieren das Verhalten der Funktionsgruppen eines allgemeineren auf unterschiedliche Art. Abhängigkeit Place Order Funktionen eines Use Case werden durch Bezug auf einen anderen beschrieben Importierender Use Case kann nicht allein vorkommen Ausfaktorisierung gemeinsamen Verhaltens Check Password Retinal Scan unabhängig 23 24

7 für gemeinsames Verhalten Erweiterung eines Use-Case Place Order «extend» Place Rush Order Place Order «extend» Place Rush Order List Orders Erweiternder Use Case beschreibt optionales Verhalten Einbindung in Aktionsfolgen des Basis-Use- Case über extension points Check Password Retinal Scan Basis-Use-Case kann allein vorkommen Akteur-Assoziationen und Use-Case-Beziehungen Place Order List Orders «extend» Place Rush Order Konventionen Namen für Use-Cases Bezeichner, die eine Tätigkeit beschreiben Beispiele: als Substantiv (z.b. Materialbeschaffung ) oder als Verb (z.b. Material beschaffen ) Check Password Retinal Scan E-Commerce 27 28

8 -Werkstatt : Anforderungen () Ein erteilt einen Reparaturauftrag für sein Auto. Der wird im von einer oder einem mechaniker aufgenommen. Für jeden wird zunächst eine Reparaturanweisung erstellt. Ein freier Mechaniker druckt diese an einem Terminal in der Werkstatt aus und übernimmt damit die Reparatur. Nach erfolgter Reparatur ergänzt der Mechaniker die am Terminal um die Schadensbehebung (Arbeitsstunden und verbrauchtes Material). Zusätzlich festgestellte Schäden oder fehlendes Material werden in der vermerkt und die weitere Vorgehensweise wird an das verwiesen. Use-Case-Modell: -Werkstatt Rechnungserstellung nberater Mechaniker sannahme sbearbeitung extension point: Material fehlt «extend» Materialbeschaffung Anbieter Analyse, 3. Schritt: Sequenzdiagramme Anforderungsdefinition Analyse Schnittstellenmodell Use-Case-Modell Sequenzdiagramme Klassenmodell Aktivitätsdiagramme Szenarien für Use Cases: Analyse-Klassenmodell sequentielle Abläufe Vor- und Nachbedingungen Systemoperationen von System-Operationen Ausgabeereignisse Data Dictionary Zeitlicher Verlauf Notationen für Sequenzdiagramme :Akteur Aufbau Systemoperation Ausgabeereignis Nachrichten Objekt Lebenslinie Kommunikation Synchron: Sender wartet auf Antwort Asynchron Sender arbeitet weiter 32

9 Notationen für Sequenzdiagramme sd Name Aktivitätszonen :A :B :C Zweck: Beschreibung von sequentiellen und geschachtelten Kontrollflüssen möglich Notationen für Sequenzdiagramme Schleifen Alternativen sd Name sd Name :Akteur :Akteur loop alt [0,] [Bedingung] Hinweis: Spielt in der Analyse zunächst keine Rolle wird im Entwurf aufgegriffen break [Abruchbedingung] [Bedingung2] [sonst] Wie kommen wir zu Sequenzdiagrammen für die Werkstatt? Beispiel: Szenario für Use-Case sbearbeitung sd holen Rechnungserstellung sannahme? sbearbeitung :Mechaniker :Werkstatt :Mechaniker nächste_anweisung_holen anweisung_gedruckt Materialbeschaffung 35 36

10 Alternativen in einem Szenario z.b. Ausnahmefälle sd annehmen Use-Case sannahme sd holen :nberater alt :Mechaniker alt [ vorhanden] auftrag_eingeben(kundenid,kfzid) auftrag_angelegt [ vorhanden] nächste_anweisung_holen anweisung_gedruckt [sonst] auftrag_eingeben(kundenid,kfzid) fehlende_oder_veraltete_daten [sonst] nächste_anweisung_holen keine_anweisung_vorhanden kundendaten_eingeben(kundenid,kdaten,kfzid,kennz,modellid) kundendaten_aufgenommen auftrag_eingeben(kundenid,kfzid) auftrag_angelegt 37 Use-Case sannahme Use-Case sbearbeitung sd bearbeiten :Mechaniker :nberater sd generieren :nberater anweisung_generieren(aid,schäden) alt [alles ok] anweisungsbearbeitung_ vermerken(anid, std, matids) bearbeitung_vermerkt anweisung_bearbeitet anweisung_erstellt [Zusatzschäden] zusätzliche_schäden_vermerken (anid, schäden,std, matids) zusätzliche_schäden_vermerkt zusätzliche_schäden_festgestellt [Material fehlt] fehlendes_material_ vermerken (anid, matids) fehlendes_material_vermerkt material_fehlt 39

11 Use-Case sbearbeitung Use-Case Materialbeschaffung sd Reparatur beenden sd Material bestellen :nberater reparaturende_vermerken(aid) reparaturende_vermerkt :nberater :Anbieter material_bestellen(aid) material_ordern (mat, aid) material_bestellt 4 42 Use-Case Rechnungserstellung Was haben wir bis jetzt erreicht? sd Rechnung stellen alt :nberater [ abgeschlossen] [sonst] abrechnen(aid) abrechnen(aid) rechnung_gedruckt auftrag_nicht_abgeschlossen Analyse Klassenmodell Anforderungsdefinition Schnittstellenmodell Sequenzdiagramme Aktivitätsdiagramme Use-Case-Modell Analyse-Klassenmodell Vor- und Nachbedingungen von System-Operationen Data Dictionary 43