Umfrage zum CHE-Ranking

Transkript

1 Umfrage zum CHE-Ranking Wichtigstes Hochschulranking in Deutschland Fächerbezogene Bewertung Kombination aus Fakten und Meinungen Jeweils 1/3 der Fächer wird jährlich aktualisiert Dieses Jahr: Informatik Veröffentlichung im ZEIT-Studienführer (Nächste Ausgabe Mai 2009) Durchführung der Erhebung ab August 2008 Aktuell: Befragung der Studierenden Wir bitten alle Studierenden, die angeschrieben werden, dringend, an der Befragung teilzunehmen und den Fragebogen verantwortungsbewusst und fair auszufüllen und zurückzusenden.

2 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)

3 Was machen wir heute? Wiederholung Use-Case-Modelle Sequenzdiagramme Fortsetzung Analyse Aktivitätsdiagramme Analyse-Klassendiagramme MPGI 3 WS 2008/9 3

4 Wiederholung: Use-Case-Modelle und Sequenzdiagramme Textuelle Anforderungen? Verhaltensmodelle :System :Mechaniker MPGI 3 WS 2008/9

5 Analyse, 2. Schritt: Use-Case-Modelle Anforderungsdefinition Analyse Klassenmodell Schnittstellenmodell Sequenzdiagramme Aktivitätsdiagramme Use-Case-Modelle Analyse-Klassenmodell Vor- und Nachbedingungen von System-Operationen Data Dictionary MPGI 3 WS 2008/9

6 Notationen für Use-Case-Modelle Material beschaffen Use-Case: Funktionsgruppe mit komplexem Verhalten, Menge von Szenarien Mechaniker Akteur: Personen oder Softwaresysteme, die mit dem System interagieren Kommunikation: zwischen Akteur und Use-Case (Multiplizitäten möglich) Benutzer validieren Passwort eingeben Generalisierung/Spezialisierung: Realisierung von abstrakten Verhalten Benutzer validieren «include» Auftrag erteilen «include» - Beziehung: importierender Use Case kann nicht allein vorkommen, sinnvoll zur Ausfaktorisierung Anweisung bearbeiten extension point: Material fehlt «extend» Material bestellen «extend» - Beziehung: Basis-Use-Case kann allein vorkommen, optionales Verhalten, Einbindung über extension points

7 Konventionen (Achtung: Korrektur) Namen für Use-Cases Bezeichner, die eine Tätigkeit beschreiben Beispiele: als Substantiv (z.b. Materialbeschaffung ) oder als Verb (z.b. Material beschaffen ) MPGI 3 WS 2008/9 7

8 Analyse, 3. Schritt: Sequenzdiagramme Anforderungsdefinition Analyse Klassenmodell Schnittstellenmodell Sequenzdiagramme Aktivitätsdiagramme Use-Case-Modelle Analyse-Klassenmodell Vor- und Nachbedingungen von System-Operationen Data Dictionary MPGI 3 WS 2008/9

9 Notationen für Sequenzdiagramme :Akteur :System Grundaufbau: Objekte, Lebenslinien und Nachrichten, z.b. Systemoperationen und Ausgabeereignisse Kommunikation: synchroner und asynchroner Nachrichtenaustausch Aktivitätszonen: synchrone verschachtelte Kontrolflüsse (für Entwurf) sd:name loop [1..*] break [Ende] Schleifen: sich wiederholende Szenarien, mit oder ohne Abbruchkriterium möglich sd:name alt [Bedingung] [Sonst] Alternativen: über Bedingungen mit else-zweig spezifizierbar, weitere Konstrukte wie z.b. opt (optional), par (nebenläufig), seq (lose Reihenfolge) möglich

10 Analyse, 4. Schritt: Aktivitätsdiagramme Anforderungsdefinition Analyse Klassenmodell Schnittstellenmodell Sequenzdiagramme Aktivitätsdiagramme Use-Case-Modell Analyse-Klassenmodell Vor- und Nachbedingungen von System-Operationen Data Dictionary MPGI 3 WS 2008/9

11 Was sind Aktivitätsdiagramme? Grundaufbau Auftrag annehmen Aktion Auftrag eingeben Kontroll- oder Datenfluss Anweisung generieren Herkunft Flussdiagramme Programmablaufpläne Petrinetze Aktivitäten Folgen von Aktionen Verlassen eines Zustands erst nach Beendigung der Aktion Aktionen sind... Ausführungsschritte in einem Algorithmus, Geschäftsprozess oder Systemablauf MPGI 3 WS 2008/9 11

12 Entscheidungsknoten (Decision) Auftrag annehmen Auftrag eingeben [Daten fehlen] [Daten vorhanden] Anweisung generieren Kundendaten eingeben nur ein Zweig kann weiterverfolgt werden disjunkte Bedingungen verwenden else-konstrukte möglich (default unbeschriftet) Zusammenführung (Merge) Auftrag annehmen [Daten fehlen] Auftrag eingeben MPGI 3 WS 2008/9 Kundendaten eingeben Anweisung generieren Zusammenführung mehrerer alternativer Daten bzw. Kontrollflüsse MPGI 3 WS 2008/9 12

13 Nebenläufige Aktionen Kontodaten ändern Auftrag bearbeiten Auftrag abrechnen Reparatur durchführen Aufsplittung (Fork) B und C beginnen nach A B und C sind unabhängig Sychronisierung (Join) D beginnt erst nach B und C B B unabhängige D Kontollflüsse werden synchronisiert A C C MPGI 3 WS 2008/9 13

14 Terminierungsknoten Auftrag abwickeln Auftrag bearbeiten Aktivität beenden gesamte Aktivität wird beendet activity final Kontodaten ändern Reparatur durchführen Kontrollfluss beenden nebenläufiger Kontrollfluss wird beendet flow final MPGI 3 WS 2008/9 14

15 Objektflussgraphen Auftrag aufnehmen Anweisung Anweisung Datenobjekt Reparatur beginnen - Aktion A erzeugt Datenobjekt A - Aktion B konsumiert Datenobjekt B Geschachtelte Aktivitäten Reparatur annehmen Auftrag annehmen Auftrag annehmen Reparatur beginnen Auftrag eingeben Anweisung generieren MPGI 3 WS 2008/9 15

16 Definition der Semantik mit Hilfe von Token B A D C - Fragen nach Erreichbarkeit z.b. mit Model-Checkern zu beantworten - Verifikation Hierarchischer Zustandssysteme ist aktuelles Forschungsthema am Lehrstuhl Softwaretechnik [cond] [else] E MPGI 3 WS 2008/9 16

17 Modellierung mit Verantwortungsbereichen Zigaretten kaufen Automat Käufer Geld einwerfen Geld zählen [sonst] Fehler anzeigen [verfügbar] Marke wählen Verfügbarkeit prüfen Wechselgeld entnehmen Wechselgeld berechnen Zigaretten entnehmen Zigaretten ausgeben [sonst] [ausreichend] Abbildung nach M. Jeckle: MPGI 3 WS 2008/9 17

18 Wie kommt man zu Aktivitätsdiagrammen? Textuelle Anforderungen Aktivitätsdiagramme Use-Case- und Sequenzdiagramme? :System :Mechaniker 18

19 Verhaltensmodellierung mit Aktivitätsdiagrammen Intention Beschreibung, die mehrere Sequenzdiagramme in einen Zusammenhang bringt ausgehend vom Initialzustand des System alle Aktionen des Systems beschreiben Praktischer Nutzen Grundlage zur Implementierung von GUI-Skizzen, um beim Kunden die erhobenen Anforderungen zu validieren MPGI 3 WS 2008/9 19

20 Konsistenzverpflichtung Sequenzdiagramme Aktivitätsdiagramme Aktivitätsdiagramme enthalten alle Szenarien aus den Sequenzdiagrammen Aktivitätsdiagramme können noch zusätzliche Abläufe beinhalten Hinweis Sequenzdiagramme beschreiben in unserer Methode nur einige wichtige Abläufe des Gesamtverhaltens, aber nicht alle Abläufe. MPGI 3 WS 2008/9 20

21 Vorgehen: Erstellung Aktivitätsdiagramme 1. Schaffe Aktivitätsdiagramm für jeden Use-Case! Daumenregel: abhängig von der Komplexität des Use-Case 2. Füge explizite Aktion für GUI-Auswahl ein! Grundlage für zu implementierende GUI-Skizzen 3. Repräsentiere Systemoperationen als Aktionen! Achtung nur Systemsicht, keine Ausdifferenzierung in Verantwortungsbereiche für Akteur/System ähnliche Namen verwenden 4. Beachte Abhängigkeiten zwischen Systemoperationen! Vorbedingungen von Systemoperationen beachten! 5. Arbeite Schleifen, Alternativen und Schachtelungen ein! Guards, wie z.b. Abbruchkriterium bei Schleifen aus Sequenzdiagrammen übernehmen

22 Erinnerung: Use-Case-Modell Rechnungserstellung Kundenberater Auftragsannahme Anweisungsbearbeitung extension point: Material fehlt Anbieter «extend» Mechaniker Materialbeschaffung MPGI 3 WS 2008/9 22

23 Aktivitätsdiagramm für UC Anweisung bearbeiten Anweisung bearbeiten Aktion auswählen [Beenden] [Bearbeiten] [Unzureichend] Auftrag als unzureichend melden Anweisung durchführen [Zusatzschäden] Zusatzschäden aufnehmen MPGI 3 WS 2008/9 23

24 Verfeinerte Aktivität: Zusatzschäden Aufnehmen Zusatzschäden aufnehmen Zusatzschäden vermerken [sonst] [Kunde einverstanden] Neue Anweisung generieren Unbearbeitete Schäden vermerken MPGI 3 WS 2008/9 24

25 Analyse, 5. Schritt: Systemklassenmodell Anforderungsdefinition Analyse Festlegen der Systemgrenzen: Schnittstellenmodell Basis: Klassenmodell Akteure: außerhalb Ziele von Systemoperationen: innerhalb Klassenmodell Sequenzdiagramme Aktivitätsdiagramme Use-Case-Modell Analyse-Klassenmodell Vor- und Nachbedingungen von System-Operationen Data Dictionary MPGI 3 WS 2008/9 25

26 Klassen im Systemklassenmodell RUP unterscheidet drei Arten von Klassen 1. Übergangsklassen <<Boundary>> 2. Gegenstandsklassen 3. Steuerungsklassen <<Control>> Stereotypen zur Unterscheidung eine Art Etikett, auch als Bild darstellbar Qualifizierende Ergänzung eines Modellelements UML/RUP gibt eine Reihe von Stereotypen vor MPGI 3 WS 2008/9 26

27 Boundary-Klassen (Übergangsklassen) Kapselung des Systems zu seiner Umwelt Präsentationsschicht in Form von GUI-Komponenten Schnittstellen zu anderen Systemen Sensoren oder Schalter zur Steuerung externer Geräte eine Boundary-Klasse pro Akteur Akteure kommunizieren nur mit ihrer Boundary-Klasse MPGI 3 WS 2008/9 27

28 Entity-Klassen (Gegenstandsklassen) zur Speicherung von Daten, Informationen, Datenhaltungsschicht persistente Datenhaltung, z.b. durch Zugriffe auf Datenbank werden von Steuerungsklassen angesprochen z.b. Daten der Akteure durch Entity-Klassen beschrieben Für Akteure prüfen, ob ihre Daten in einer Entity-Klasse gespiegelt werden müssen. MPGI 3 WS 2008/9 28

29 Control-Klassen (Steuerungsklassen) Kapselung von Abläufen und Geschäftslogik in einer Logikschicht Bindeglied zwischen Boundaryund Entity-Klassen Modellieren komplexe Funktionalitäten (Algorithmen), die keiner anderen Klasse zugeordnet werden können. Für jeden Use-Case prüfen, ob eine Control-Klasse einzuführen ist. MPGI 3 WS 2008/9 29

30 Tips zur Erstellung des Systemklassenmodells Ableitung aus dem Klassenmodell für den Gegenstandsbereich Einige Klassen sind offensichtlich Daten im System. Für andere kann sich die Klasseninterpretation von reales Objekt zu Datensatz ändern. Klassen an der Systemgrenze werden eventuell in interne und externe zerlegt. Unterscheidung zwischen Klassen in und außerhalb des Systems wird aus Use Cases und Szenarien abgeleitet MPGI 3 WS 2008/9 30

31 Vorgehen: Erstellung Systemklassenmodelle 1. Identifiziere Akteure im Klassenmodell nur, wer direkt mit dem System interagiert 2. Schaffe Boundary-Klassen für Akteure repräsentiert Benutzerschnittstelle 3. Identifiziere Entity-Klassen für das System! Prüfen der Semantik von Klassen (z.b. Material-Art?) 4. Bilde Entity-Klassen für Akteure, falls nötig! Datenspiegelung von Personen im System 5. Streiche Assoziationen oder biege diese um! Assoziationen von Akteuren nur zur Boundary 6. Füge Control-Klassen für Use-Cases ein! Klassen zwischen Boundary- und Entity-Klassen 7. Vervollständige Attribute in den Klassen

32 Rückblick: Use-Case-Modell der Werkstatt Rechnungserstellung Kundenberater Auftragsannahme Anweisungsbearbeitung extension point: Material fehlt Anbieter «extend» Mechaniker Materialbeschaffung 32

33 Rückblick: Klassenmodell der Werkstatt Material Wird_bestellt_bei Anbieter Führt_material_für Werkstatt Bestellt Arbeitet_in Braucht Anweisung bearbeitet Mechaniker Nimmt_auf Büro Erstellt Gehört_zu Repariert Arbeitet_in Rechnung Basiert_auf Auftrag Ist_zugeordnet KFZ Erteilt Ist_Halter_von Besitzt Kundenberater Kommuniziert_mit Kunde Modell

34 1. Identifiziere Akteure im Klassenmodell! Bestellt Material Wird_bestellt_bei Anbieter Führt_material_für Werkstatt Arbeitet_in Braucht Nimmt_auf Anweisung bearbeitet Mechaniker Büro Erstellt Gehört_zu Repariert Arbeitet_in Rechnung Basiert_auf Auftrag Ist_zugeordnet KFZ Erteilt Ist_Halter_von Besitzt Kundenberater Kommuniziert_mit Kunde Modell

35 2. Schaffe Boundary-Klassen für Akteure! Bestellt Material Büro <<Boundary>> Bestellt_über Wird_bestellt_bei Erstellt Braucht Nimmt_auf -Client <<Boundary>> Informiert Anweisung Anbieter bearbeitet Führt_material_für Werkstatt <<Boundary>> Arbeitet_in Mechaniker Gehört_zu Repariert Arbeitet_in Rechnung Basiert_auf Auftrag Ist_zugeordnet KFZ Erteilt Ist_Halter_von Besitzt Kundenberater Kommuniziert_mit Kunde Modell

36 3. Identifiziere Entity-Klassen für das System! Material-Art Bestellt Büro <<Boundary>> Bestellt_über Bestellt_bei Besitzt Lagerposten Nimmt_auf Erstellt Braucht -Client <<Boundary>> Informiert Anweisung Anbieter bearbeitet Führt_material_für Werkstatt <<Boundary>> Arbeitet_in Mechaniker Arbeitet_in Rechnung Gehört_zu Repariert Basiert_auf Auftrag Ist_zugeordnet KFZ Erteilt Ist_Halter_von Besitzt Kundenberater Kommuniziert_mit Kunde Modell

37 4. Bilde Entity-Klassen für Akteure, falls nötig! Material-Art Bestellt Büro <<Boundary>> Bestellt_über Bestellt_bei Besitzt Lagerposten Nimmt_auf Erstellt Braucht -Client <<Boundary>> Anbieterdaten Informiert Anweisung Anbieter bearbeitet Führt_material_für Werkstatt <<Boundary>> Arbeitet_in Mechaniker Arbeitet_in Rechnung Gehört_zu Repariert Basiert_auf Auftrag Ist_zugeordnet KFZ Erteilt Ist_Halter_von Besitzt Kundenberater Kommuniziert_mit Kunde Modell

38 Arbeitet_in Auftrag Erteilt Kunde Anweisung Büro <<Boundary>> Gehört_zu Werkstatt <<Boundary>> Mechaniker KFZ bearbeitet Rechnung Erstellt Modell Repariert Arbeitet_in Kundenberater Besitzt Anbieter Führt_material_für Ist_zugeordnet Nimmt_auf Kommuniziert_mit Basiert_auf Ist_Halter_von Kommunizieren Akteure nur über Boundary? Informiert Material-Art Bestellt -Client <<Boundary>> Anbieterdaten Bestellt_über Braucht Bestellt_bei Lagerposten Besitzt

39 Arbeitet_in Auftrag Erteilt Kunde Büro <<Boundary>> Gehört_zu Werkstatt <<Boundary>> Mechaniker KFZ Rechnung Erstellt Modell Arbeitet_in Kundenberater Besitzt Anbieter Ist_zugeordnet Basiert_auf Ist_Halter_von 5. Entferne notfalls verbotene Assoziationen! Anweisung Nimmt_auf Material-Art Bestellt -Client <<Boundary>> Anbieterdaten Bestellt_über Braucht Bestellt_bei Lagerposten Besitzt

40 Arbeitet_in Auftrag Erteilt Kunde Büro <<Boundary>> Gehört_zu Werkstatt <<Boundary>> Mechaniker KFZ Rechnung Erstellt Modell Arbeitet_in Kundenberater Besitzt Anbieter Ist_zugeordnet Basiert_auf Ist_Halter_von 6. Füge Control-Klassen für Use-Cases ein! Informiert Werkstatt-Session <<Control>> Steuert Verwaltet Büro-Session <<Control>> Verbunden mit Legt_fest Anweisung Nimmt_auf Material-Art Bestellt -Client <<Boundary>> Anbieterdaten Bestellt_über Braucht Bestellt_bei Lagerposten Besitzt

41 Auftrag Erteilt Kunde Büro <<Boundary>> Gehört_zu Mechaniker KFZ Rechnung Modell Arbeitet_in Kundenberater Besitzt Ist_zugeordnet Basiert_auf Ist_Halter_von Ergebnis: Eine virtuelle Systemgrenze entsteht! Verbunden mit Legt_fest Arbeitet_in Werkstatt <<Boundary>> Erstellt Anbieter Informiert Werkstatt-Session <<Control>> Steuert Verwaltet Büro-Session <<Control>> Anweisung Nimmt_auf Material-Art Bestellt -Client <<Boundary>> Anbieterdaten Bestellt_über Braucht Bestellt_bei Lagerposten Besitzt

42 7. Vervollständige Attribute in den Klassen! Anbieterdaten Anweisung Auftrag Büro KFZ adresse : ADRESSE schäden : TEXT anid : ANID zusatzschäden : TEXT status : STATUS std : NAT aid : AID ist_beendet : BOOL ist_probefahrt _erfolgreich : BOOL hat_zusatzschäden : BOOL stdsatz : NAT kennzeichen : KENNZEICHEN kfzid : KFZID Kundendaten kdat : KDATEN kundenid : KUNDENID Material-Art matid : MATID preis : NAT Modell mid : MODID mdat : MDAT Rechnung betrag : NAT Werkstatt stdsatz : NAT Typdefinitionen: ADRESSE - Internetadresse ANID - Identifier deranweisung STATUS - bereit_zur_bearbeitung in_bearbeitung beendet AID - Identifier des Auftrags KENNZEICHEN - KFZ-Kennzeichen KDATEN - Kundendaten MATID - Identifier des Materials MID - Identifier des Modells MDAT - Modelldaten NAT - natürliche Zahl BOOL - boolscher Wert KFZID - Identifier des KFZ KUNDENID - Identifier des Kunden TEXT - Text 42

43 Was haben wir bis jetzt erreicht? Anforderungsdefinition Analyse Klassenmodell Schnittstellenmodell Sequenzdiagramme Aktivitätsdiagramme Use-Case-Modell Analyse(System)-Klassenmodell Vor- und Nachbedingungen von System-Operationen Data Dictionary MPGI 3 WS 2008/9