Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 Vorlesung Softwaretechnik Prof. Dr.-Ing.habil. Dipl.Math. Klaus-Peter Fähnrich (Wintersemester 2001/2002) Universität Leipzig Institut für Informatik.

Ähnliche Präsentationen


Präsentation zum Thema: "1 Vorlesung Softwaretechnik Prof. Dr.-Ing.habil. Dipl.Math. Klaus-Peter Fähnrich (Wintersemester 2001/2002) Universität Leipzig Institut für Informatik."—  Präsentation transkript:

1 1 Vorlesung Softwaretechnik Prof. Dr.-Ing.habil. Dipl.Math. Klaus-Peter Fähnrich (Wintersemester 2001/2002) Universität Leipzig Institut für Informatik

2 2 1.Einführung 2.OOA-Muster 3.Methodische Vorgehensweise 4.Einsatz von CASE-Werkzeugen 5.Zusammenfassung Inhalt 7. Die Definitionsphase: Objektorientierte Analyse

3 3 1.Wichtige Muster der Systemanalyse 2.Methodische Schritte zur Erstellung eines OOA-Modells 3.Die verschiedenen OOA-Muster und OOA-Modellen 4.Erstellung und Überprüfung eines OOA-Modells 5.Einsatz von CASE-Werkzeugen Lernziele 7. Die Definitionsphase: Objektorientierte Analyse

4 4 Ursprünge 7.1. Die Definitionsphase: Einführung

5 5 Dynamisches und statisches Modell 7.1. Die Definitionsphase: Einführung

6 6 Vereinfacht : Muster ( Pattern ) ist eine Idee, die sich in der Praxis bewährt hat OOA-Muster besteht aus einer Gruppe von Klassen mit feststehenden Verantwortlichkeiten und Interaktionen /Coad 95/ Muster ermöglichen effektive Kommunikation und erlauben standisierte Lösung bestimmter Probleme Einsatz vorhandener Muster hängt stark vom Verwendungsbereich ab. Daher Unterscheidung allgemeine Muster und anwendungsspezifische Muster. Im folgenden werden allgemeine Muster vorgestellt. Definition 7.2. Die Definitionsphase: OOA-Muster

7 7 Muster Liste : Beispiel Lagerverwaltung 7.2. Die Definitionsphase: OOA-Muster

8 8 Es liegt eine Komposition vor Ein Ganzes besteht aus gleichartigen Teilen, d.h. es gibt nur eine Teil- Klasse Teil-Objekte bleiben einem Aggregat-Objekt fest zugeordnet oSie k ö nnen jedoch gel ö scht werden, bevor das Ganze gel ö scht wird Die Attributwerte des Aggregat-Objekts gelten auch f ü r die zugeh ö rigen Teil-Objekte Das Aggregat-Objekt enth ä lt mindestens ein Teil-Objekt, d.h. die Kardinalit ä t ist meist 1..*. Muster Liste 7.2. Die Definitionsphase: OOA-Muster

9 9 Muster Exemplartyp 7.2. Die Definitionsphase: OOA-Muster Einfache Assoziation Einmal erstellte Objektverbindungen werden i. Allg. nicht ver ä ndert. Sie werden nur gel ö scht, wenn das betreffende Exemplar entfernt wird Der Name der neuen Klasse enth ä lt oft Begriffe wie Typ, Gruppe, Beschreibung, Spezifikation Eine Beschreibung kann – zeitweise – unabh ä ngig von konkreten Exemplaren existieren. Daher ist die Kardinalit ä t i. Allg. many (0..m) W ü rde auf die neue Klasse verzichtet, so w ü rde als Nachteil lediglich die redundante » Speicherung « von Attributwerten auftreten.

10 10 Muster Baugruppe 7.2. Die Definitionsphase: OOA-Muster Es handelt sich um physische Objekte Es liegt eine Komposition vor Objektverbindungen be-stehen ü ber eine l ä ngere Zeit Ein Teil-Objekt kann von seinem Aggregat-Objekt getrennt werden und einem anderen Ganzen zugeordnet werden Ein Ganzes kann aus unterschiedlichen Teilen bestehen.

11 11 Muster Stückliste: Beispiele 7.2. Die Definitionsphase: OOA-Muster

12 12 Es liegt eine Komposition vor Das Aggregat-Objekt und seine Teil-Objekte m ü ssen sowohl als Einheit als auch einzeln behandelt werden k ö nnen Teil-Objekte k ö nnen anderen Aggregat-Objekten zugeordnet werden Die Kardinalit ä t bei der Aggregat-Klasse ist 0..1 Ein Objekt der Art A kann sich aus mehreren Objekten der Arten A, B und C zusammensetzen Der Sonderfall der St ü ckliste ist, dass ein St ü ck nicht aus Objekten unterschiedlicher Art, sondern nur aus einer einzigen Art besteht. Muster Stückliste 7.2. Die Definitionsphase: OOA-Muster

13 13 Muster Koordinator 7.2. Die Definitionsphase: OOA-Muster Es liegen einfache Assoziationen vor Die Koordinator-Klasse ersetzt eine n- ä re (n >= 2) Assoziation durch bin ä re Assoziationen mit assoziativer Klasse Die Koordinator-Klasse besitzt kaum Attribute/Operationen, sondern mehrere Assoziationen zu anderen Klassen, i. Allg. zu genau einem Objekt jeder Klasse.

14 14 Muster Rollen 7.2. Die Definitionsphase: OOA-Muster Zwischen 2 Klassen existieren 2 oder mehrere einfache Assoziationen Ein Objekt kann – zu einem Zeitpunkt – in Bezug auf die Objekte der anderen Klasse verschiedene Rollen spielen Objekte, die verschiedene Rollen spielen k ö nnen, besitzen unabh ä ngig von der jeweiligen Rolle die gleichen Eigenschaften und ggf. gleiche Operationen.

15 15 Muster Wechselnde Rollen : Beispiele 7.2. Die Definitionsphase: OOA-Muster

16 16 Muster Wechselnde Rollen 7.2. Die Definitionsphase: OOA-Muster Ein Objekt der realen Welt kann zu verschiedenen Zeiten verschiedene Rollen spielen. In jeder Rolle kann es unterschiedliche Eigenschaften (Attribute, Assoziationen) und Operationen besitzen Die unterschiedlichen Rollen werden mittels Vererbung modelliert Objektverbindungen zwischen dem Objekt und seinen Rollen werden nur erweitert, d.h. weder gel ö scht noch zu anderen Objekten aufgebaut.

17 17 Muster Historie 7.2. Die Definitionsphase: OOA-Muster Es liegt eine einfache Assoziation vor F ü r ein Objekt sind mehrere Vorg ä nge bzw. Fakten zu dokumentieren F ü r jeden Vorgang bzw. jedes Faktum ist der Zeitraum festzuhalten Aufgebaute Objektverbindungen zu den Vorg ä ngen bzw. Fakten werden nur erweitert Die zeitliche Restriktion {t#k} (k = g ü ltige Kardinalit ä t) sagt aus, was zu einem Zeitpunkt gelten muss, wobei # f ü r die Vergleichsoperationen =,, = und steht.

18 18 Muster Gruppe 7.2. Die Definitionsphase: OOA-Muster Es liegt eine einfache Assoziation vor Mehrere Einzel-Objekte geh ö ren – zu einem Zeitpunkt – zum selben Gruppen-Objekt Es ist jeweils zu pr ü fen, ob die Gruppe – zeitweise – ohne Einzel-Objekte existieren kann oder ob sie immer eine Mindestanzahl von Einzel-Objekten enthalten muss Objektverbindungen k ö nnen auf- und abgebaut werden.

19 19 Muster Gruppenhistorie 7.2. Die Definitionsphase: OOA-Muster Ein Einzel-Objekt geh ö rt – im Laufe der Zeit – zu unterschiedlichen Gruppen-Objekten Die Historie wird mittels einer assoziativen Klasse modelliert o Dadurch ist die Zuordnung zwischen Einzel-Objekten und Gruppen deutlich sichtbar Die zeitliche Restriktion {t=k} (k = g ü ltige Kardinalit ä t) sagt aus, was zu einem Zeitpunkt gelten muss Da Informationen ü ber einen Zeitraum festzuhalten sind, bleiben erstellte Objektverbindungen bestehen und es werden nur Verbindungen hinzugef ü gt.

20 20 Zur Modellbildung 7.3. Die Definitionsphase: Methodische Vorgehensweise

21 21 3 Vorgehensweisen : 1.Orientierung an den Informationen des Systems (statisches Modell) 2.Orientierung an der Funktionalität des Systems (dynamisches Modell) 3.Synthese von 1. und 2. Im folgenden wird die Methode von /Heide Balzert 99/ dargestellt. Sie besteht aus : Dem Makroprozess: der die methodischen Schritte festlegt Methodischen Regeln, die in Form von Checklisten zur Verfügung stehen Der Makroprozess beschreibt auf einem hohen Abstraktionsniveau, in welcher Reihenfolge die einzelnen Aufgaben zu Erstellung eines OOA-Modells auszuführen sind: Ermitteln der relevanten Geschäftsprozesse Ableitung von Klassen aus den Geschäftsprozessen Erstellen des statischen Modells Parallel dazu Erstellung des dynamischen Modells Berücksichtigung der Wechselwirkungen beider Modelle Vorgehensweisen und Mákroprozesse 7.3. Die Definitionsphase: Methodische Vorgehensweise

22 22 1.Gesch ä ftsprozesse aufstellen Erstellen der wesentlichen Gesch ä ftsprozesse oBeschreibung Gesch ä ftsprozesse oGesch ä ftsprozessdiagramm 2.Pakete bilden Bilden von Teilsystemen, d.h. zusammenfassen von Modellelementen zu Paketen oBei gro ß en Systemen, die i. Allg. durch mehrere Teams bearbeitet werden, muss die Bildung von Paketen am Anfang stehen oPaketdiagramm. Analyse im Großen 7.3. Die Definitionsphase: Methodische Vorgehensweise

23 23 1.Klassen identifizieren F ü r jede Klasse nur so viele Attribute und Operationen identifizieren, wie f ü r das Problemverst ä ndnis und das einwandfreie Erkennen der Klasse notwendig sind Klassendiagramm Kurzbeschreibung Klassen 2.Assoziationen identifizieren Zun ä chst nur die reinen Verbindungen eintragen, d.h. noch keine genaueren Angaben, z.B. zur Kardinalit ä t oder zur Art der Assoziation, machen Klassendiagramm. 3.Attribute identifizieren Identifizieren aller Attribute des Fachkonzepts Klassendiagramm 4.Vererbungsstrukturen identifizieren... aufgrund der identifizierten Attribute Klassendiagramm 7 Schritte zum statischen Modell (1) 7.3. Die Definitionsphase: Methodische Vorgehensweise

24 24 5.Assoziationen vervollst ä ndigen Endg ü ltig festlegen, ob eine » normale « Assoziation, Aggregation oder Komposition vorliegt sowie Festlegung der Kardinalit ä ten, Rollen, Namen und Restriktionen Klassendiagramm Objektdiagramm. 6.Attribute spezifizieren F ü r alle identifizierten Attribute eine vollst ä ndige Spezifikation erstellen Attributspezifikation 7.Muster identifizieren Das Klassendiagramm daraufhin ü berpr ü fen, ob Muster enthalten sind und diese richtig modelliert wurden. 7 Schritte zum statischen Modell (2) 7.3. Die Definitionsphase: Methodische Vorgehensweise

25 25 1.Szenarios erstellen Jeden Gesch ä ftsprozess durch eine Menge von Szenarios pr ä zisieren oSequenzdiagramm, Kollaborationsdiagramm oAlternativ oder erg ä nzend k ö nnen auch Aktivit ä tsdiagramme verwendet werden 2.Zustandsautomat erstellen F ü r jede Klasse pr ü fen, ob ein nicht-trivialer Lebenszyklus erstellt werden kann und muss oZustandsdiagramm. 3.Operationen beschreiben Ü berlegen, ob eine Beschreibung notwendig ist oWenn ja, dann ist je nach Komplexit ä tsgrad die entsprechende Form zu w ä hlen Klassendiagramm fachliche Beschreibung der Operationen Zustandsautomaten Aktivit ä tsdiagramme 3 Schritte zum dynamischen Modell 7.3. Die Definitionsphase: Methodische Vorgehensweise

26 26 Grob beschriebene Vorgehensweise reichen bei praktischen Anwendungen nicht aus. Systemanalytiker wendet Hunderte von Regeln an. Diese stehen in Form von Checklisten zur Verf ü gung F ü rs Erstellen der entsprechenden Diagramme und Spezifikationen sollten alle Punkte der Checkliste durchgegangen werden. Aufbau von Checklisten F ü r die Qualit ä tssicherung k ö nnen die unter Analytische Schritte angegebenen Punkte benutzt werden. Prof. F ä hnrich, Qualitymanagement Checklisten 7.3. Die Definitionsphase: Methodische Vorgehensweise Konstruktive SchritteWie findet man ein Modellelement Analytische SchritteIst es ein gutes Modellelement? Konsistenzprüfung Fehlerquellen Für klassische EntwicklerWelche methodischen Regeln helfen beim Übergang von der Daten- modellierung zur objektorientierten Analyse

27 27 Die methodische Vorgehensweise und die Checkliste f ü r Gesch ä ftsprozesse wurde bereits behandelt, da sie nicht spezifisch f ü r eine objektorientierte Entwicklung sind. Zusammenfassung der passenden Folien Geschäftsprozess Die Definitionsphase: Checkliste Geschäftsprozess

28 28 Ergebnisse oPaketdiagramm Erstellen eines Paketdiagramms Jedem Paket werden Modellelemente zugeordnet Die Abh ä ngigkeiten zwischen den Paketen werden spezifiziert Konstruktive Schritte 1.Welche Pakete ergeben sich durch top-down-Vorgehen? Bei gro ß en Anwendungen: Noch vor der Formulierung von Gesch ä ftsprozessen: Unterteilen des Gesamtsystems in Teilsysteme (Pakete) Umfangreiche Pakete in weitere Pakete zerlegen. 2.Welche Pakete ergeben sich durch bottom-up-Vorgehen? Bei kleinen und mittleren Anwendungen: Klassen unter einem Oberbegriff zusammenfassen Paket (1) Die Definitionsphase: Checkliste Paket

29 29 Analytische Schritte 3.Bildet das Paket eine abgeschlossene Einheit? Enth ä lt eigenst ä ndigen Themenbereich Enth ä lt Klassen, die logisch zusammengeh ö ren Es erlaubt eine Betrachtung des Systems auf einer h ö heren Abstraktionsebene Vererbungsstrukturen liegen m ö glichst innerhalb eines Pakets Aggregationen sind nicht durchtrennt M ö glichst wenig Assoziationen sind durchtrennt. 4.Ist der Paketname geeignet? Der Inhalt eines Pakets muss mit 25 Worten oder weniger beschreibbar sein Aus der Beschreibung den Namen ableiten Paketnamen d ü rfen keine Verben enthalten 5.Fehlerquellen Zu kleine Pakete Fallstudie » Seminarorganisation « oKleines System Eine Aufteilung auf Pakete ist daher am Anfang des Entwicklungsprozesses nicht n ö tig Paket (2) Die Definitionsphase: Checkliste Paket

30 30 Ergebnisse Klassendiagramm Jede Klasse – entweder nur mit Namen oder mit wenigen wichtigen Attributen/Operationen – in das Klassendiagramm eintragen Kurzbeschreibung der Klassen Konstruktive Schritte 1.Welche Klassen lassen sich mittels Dokumentanalyse identifizieren (bottom-up)? Aus Formularen und Listen Attribute entnehmen und zu Klassen zusammenfassen. Reengineering von Software-Altsystemen: Arbeitsabl ä ufe anhand von Benutzerhandb ü chern, Bildschirmmasken, Dateibeschreibungen ermitteln Anhand des laufenden Systems die Funktionen der Gesch ä ftsprozesse ausf ü hren Klassen mithilfe der Bildschirmmasken ermitteln Bei technischen Systemen bieten sich die realen Objekte als Ausgangsbasis an, z.B. Lagermodul Klasse (1) Die Definitionsphase: Checkliste Klasse

31 31 Konstruktive Schritte 2.Welche Klassen lassen sich aus der Beschreibung der Gesch ä ftsprozesse identifizieren (top-down)? oBeschreibung nach Klassen durchsuchen Oft sind Substantive potenzielle Klassen oPotenzielle Klassen auf Attribute ü berpr ü fen oAkteure, ü ber die man sich etwas » merken « muss, sind potenzielle Klassen. 3.Zu welchen Kategorien geh ö ren die Klassen? oKonkrete Objekte bzw. Dinge, z.B. PKW oPersonen und deren Rollen, z.B. Kunde, Dozent oInformationen ü ber Aktionen, z.B. Bank ü berweisung durchf ü hren oOrte, z.B. Wartezimmer oOrganisationen, z.B. Filiale oBeh ä lter, z.B. Lagerplatz oDinge in einem Beh ä lter, z.B. Reifen in einem Lagerplatz oEreignisse, z.B. Eheschlie ß ung oKataloge, z.B. Produktkatalog oVertr ä ge, z.B. Autokaufvertrag. Klasse (2) Die Definitionsphase: Checkliste Klasse

32 32 Analytische Schritte 4.Liegt ein aussagef ä higer Klassenname vor? oDer Klassenname soll der Fachterminologie entsprechen ein Substantiv im Singular sein dasselbe ausdr ü cken wie die Gesamtheit der Attribute nicht die Rolle dieser Klasse in einer Beziehung zu einer anderen Klasse beschreiben eindeutig im Paket bzw. im System sein nicht dasselbe ausdr ü cken wie der Name einer anderen Klasse 5.Ist das gew ä hlte Abstraktionsniveau richtig? oDie Ziele sind nicht m ö glichst viele Klassen oder Klassen geringer Komplexit ä t zu identifizieren. 6.Wann liegt keine Klasse vor? oKeine Klassen bilden, um Mengen von Objekten zu verwalten Klasse (3) Die Definitionsphase: Checkliste Klasse

33 33 Analytische Schritte 7.Fehlerquellen oZu kleine Klassen oAus jedem Report eine Klasse modellieren oKlasse modelliert Benutzungsoberfl ä che oKlasse modelliert Entwurfs- oder Implementierungsdetails F ü r klassische Entwickler 8.Identifizieren von Klassen f ü r Datenmodellierer oEine potenzielle Klasse ist jeder Entit ä tstyp und jeder Beziehungstyp mit Attributen. Klasse (4) Die Definitionsphase: Checkliste Klasse

34 34 Ergebnis oKlassendiagramm Assoziationen im ersten Schritt nur als Linie eintragen Noch keine Kardinalit ä ten, Aggregationen, Kompositionen, Rollen, Namen, Restriktionen Konstruktive Schritte 1.Welche Assoziationen lassen sich mittels Dokumentanalyse ableiten? Aus Prim ä r- und Fremdschl ü sseln ermitteln. 2.Welche Assoziationen lassen sich aus Beschreibungen der Gesch ä ftsprozesse ermitteln? Nach Verben suchen, insbesondere: r ä umliche N ä he (in der N ä he von) Besitz (hat) Aktionen (f ä hrt) Kommunikation (redet mit), (verheiratet mit) allgemeine Beziehungen Assoziationen (1) Die Definitionsphase: Checkliste Assoziationen

35 35 Konstruktive Schritte 3.Liegt eine Assoziation folgender Kategorien vor? A ist physische Komponente von B A ist logische Komponente von B A ist eine Beschreibung f ü r B A ist eine Zeile einer Liste B A ist ein Mitglied von B. A ist eine organisatorische Einheit von B A benutzt B A kommuniziert mit B A besitzt B 4.Welche Restriktionen muss die Assoziation erf ü llen? Eine Assoziation: {ordered} Mehrere Assoziationen: {or}, {subset} 5.Welche Rollen spielen die beteiligten Klassen? Rollennamen angeben, wenn Assoziation zwischen derselben Klasse existiert eine Klasse in verschiedenen Assoziationen verschiedene Rollen spielt durch den Rollennamen die Bedeutung der Klasse in der Assoziation genauer spezifiziert werden kann. Assoziationen (2) Die Definitionsphase: Checkliste Assoziationen

36 36 Analytische Schritte 6.Ist eine Benennung notwendig oder sinnvoll? oNotwendig, wenn zwischen zwei Klassen mehrere Assoziationen bestehen oRollennamen (Substantive) bevorzugen oRollennamen sind bei reflexiven Assoziationen immer notwendig 7.Liegt eine 1:1-Assoziation vor? oZwei Klassen sind zu modellieren, wenn... die Verbindung in einer oder beiden Richtungen optional ist und sich die Verbindung zwischen beiden Objekten ä ndern kann es sich um zwei umfangreiche Klassen handelt die beiden Klassen eine unterschiedliche Semantik besitzen. 8.Gibt es zwischen 2 Klassen mehrere Assoziationen? oPr ü fen, ob die Assoziationen eine unterschiedliche Bedeutung besitzen oder/und unterschiedliche Kardinalit ä ten haben Assoziationen (3) Die Definitionsphase: Checkliste Assoziationen

37 37 Analytische Schritte 9.Sind abgeleitete Assoziationen korrekt verwendet? oF ü gen keine neue Information zum Modell hinzu oLassen sich mittels Objektdiagrammen erkennen 10.Assoziative Klasse oder eigenst ä ndige Klasse? oAssoziative Klasse betont die Assoziation zwischen den beteiligten Klassen oAssoziative Klassen lassen sich in eigenst ä ndige Klassen wandeln 11.Fehlerquellen oVerwechseln von Assoziation mit Vererbung. Assoziationen (4) Die Definitionsphase: Checkliste Assoziationen

38 38 Ergebnisse oKlassendiagramm F ü r jedes Attribut den Namen in das Klassendiagramm eintragen Klassenattribute und abgeleitete Attribute kennzeichnen oAttributspezifikation Jedes Attribut spezifizieren F ü r komplexe Attribute sind ggf. entsprechende Typen zu definieren. Konstruktive Schritte 1.Attribute durch Dokumentanalyse identifizieren Einfache Attribute sind ggf. zu Datenstrukturen zusammenzufassen Pr ü fen, ob alle Attribute wirklich notwendig sind F ü r jedes Attribut pr ü fen, ob es » im Laufe seines Lebens « einen Wert annehmen kann und ob diese Werte an der Benutzungsoberfl ä che sichtbar sind 2.2 Attribute durch Gesch ä ftsprozesse identifizieren Ben ö tigte Daten zur Ausf ü hrung der Aufgaben eines Gesch ä ftsprozesses Ben ö tigte Daten f ü r Listenfunktionalit ä t. Attribute (1) Die Definitionsphase: Checkliste Attribute

39 39 Konstruktive Schritte 3.Wurden geeignete Attributtypen gew ä hlt und u.U. als elementare Klasse beschrieben? oVorgegebene Typen nur verwenden, wenn problemad ä quat oAttribute beliebigen Typs definieren, um problemad ä quate Modellierung auf ausreichendem Abstraktionsniveau zu erreichen oF ü r komplexe Attribute zur Konstruktion der Typen das Klassenkonzept verwenden (elementare Klassen). Analytische Schritte 4.Ist der Attributname geeignet? oDer Attributname soll kurz, eindeutig und verst ä ndlich sein ein Substantiv oder Adjektiv-Substantiv sein den Namen der Klasse nicht wiederholen bei komplexen (strukturierten) Attributen der Gesamtheit der Komponenten entsprechen nur fachspezifische oder allgemein ü bliche Abk ü rzungen enthalten, z.B. PLZ Attribute (2) Die Definitionsphase: Checkliste Attribute

40 40 Analytische Schritte 5.Klasse oder komplexes Attribut? oKlasse: Objektidentit ä t, gleichgewichtige Bedeutung im System, Existenz unabh ä ngig von der Existenz anderer Objekte, Zugriff in beiden Richtungen grunds ä tzlich m ö glich. Attribut: keine Objektidentit ä t, Existenz abh ä ngig von Existenz anderer Objekte, Zugriff immer ü ber das Objekt, untergeordnete Bedeutung 6.Wurde das richtige Abstraktionsniveau gew ä hlt? oWurden komplexe Attribute gebildet? oBilden Attribute geeignete Datenstrukturen? oAnzahl der Attribute pro Klasse angemessen? 7.Geh ö rt Attribut zur Klasse oder einer Assoziation? oTest: Muss Attribut auch dann zur Klasse geh ö ren, wenn die Klasse isoliert von anderen Klassen betrachtet wird? Wenn ja, dann geh ö rt das Attribut zu dieser Klasse Wenn nein, dann ist zu pr ü fen, ob es sich einer Assoziation zuordnen l ä sst Sonst: Klasse oder Assoziation vergessen. Attribute (3) Die Definitionsphase: Checkliste Attribute

41 41 Analytische Schritte 8.Liegen Klassenattribute vor? Ein Klassenattribut liegt vor, wenn gilt: Alle Objekte der Klasse besitzen f ü r dieses Attribut denselben Attributwert Es sollen Informationen ü ber die Gesamtheit der Objekte modelliert werden 9.Sind Schl ü sselattribute fachlich notwendig? Schl ü sselattribute werden nur dann eingetragen, wenn sie Bestandteil des Fachkonzepts sind 10.Werden abgeleitete Attribute korrekt verwendet? Information ist f ü r den Benutzer sichtbar Lesbarkeit wird verbessert. Attribute (4) Die Definitionsphase: Checkliste Attribute

42 42 Analytische Schritte 11.Wann wird ein Attribut nicht eingetragen? Dient nur zum Identifizieren der Objekte Dient lediglich dazu, eine andere Klasse zu referenzieren, d.h. es realisiert eine Assoziation Beschreibt den internen Zustand eines Lebenszyklus und ist au ß erhalb des Objekts nicht sichtbar Beschreibt Entwurfs- / Implementierungsdetails Ist abgeleitetes Attribut, das nur eingef ü gt wurde, um Berechnungszeit zu sparen 12.Fehlerquellen Verwenden atomarer Attribute anstelle von komplexen Datenstrukturen Formulieren von Assoziationen als Attribute. Attribute (5) Die Definitionsphase: Checkliste Attribute

43 43 Ergebnis oKlassendiagramm Alle Vererbungsstrukturen eintragen und abstrakte Klassen bilden Konstruktive Schritte 1.Ergibt Generalisierung eine Einfachvererbung? Neue Oberklasse aus gleichartigen Klassen? Vorhandene Klasse als Oberklasse geeignet? 2.Ergibt Spezialisierung eine Einfachvererbung? Kann jedes Objekt der Klasse f ü r jedes Attribut einen Wert annehmen? Kann jede Operation auf jedes Objekt der Klasse angewendet werden? Analytische Schritte 3.Liegt eine » gute « Vererbungsstruktur vor? Verbessert die Vererbungsstruktur das Verst ä ndnis des Modells? Ben ö tigt jede Unterklasse alle geerbten Attribute, Operationen und Assoziationen? Liegt eine Ist-ein-Beziehung vor? Entspricht die Vererbungsstruktur den » nat ü rlichen « Strukturen des Problembereichs? Besitzt sie maximal 3 bis 5 Hierarchiestufen? 4.Wann liegt keine Vererbung vor? Vererbung Die Definitionsphase: Checkliste Vererbung

44 44 Ergebnis oKlassendiagramm Alle Kardinalit ä ten eintragen Konstruktive/analytische Schritte 1.Schnappschuss oder Historie modellieren? Aus den Anfragen an das System ergibt sich, ob ein Schnappschuss (1- bzw Kardinalit ä t) oder die Historie (many-Kardinalit ä t) zu modellieren ist Schnappschuss: eine alte Verbindung wird gel ö st wird, wenn eine neue aufgebaut wird Historie: eine neue Verbindung wird zwischen den jeweiligen Objekten hinzugef ü gt. 2.Liegt eine Muss- oder Kann-Assoziation vor? 3.Enth ä lt die Kardinalit ä t feste Werte? Ist eine Obergrenze vom Problembereich her (oft bei technischen Systemen) zwingend vorgegeben? Im Zweifelsfall mit variablen Obergrenzen arbeiten Ist die Untergrenze vom Problembereich her zwingend vorgegeben? Im Zweifelsfall mit » 0 « arbeiten Gelten besondere Restriktionen f ü r die Kardinalit ä ten? 4.Fehlerquelle Oft werden Muss-Assoziationen verwendet, wo sie nicht ben ö tigt werden. Kardinalitäten Die Definitionsphase: Checkliste Kardinalitäten

45 45 Ergebnis oKlassendiagramm Alle Aggregationen und Kompositionen eintragen Konstruktive/Analytische Schritte 1.F ü r eine Komposition gilt: Es liegt eine Ist-Teil-von-Beziehung vor Kardinalit ä t bei der Aggregatklasse: 0..1 oder 1 Lebensdauer der Teile ist an die des Ganzen gebunden Ein Teil darf jedoch zuvor explizit entfernt werden Funktionen des Ganzen werden automatisch auf seine Teile angewendet Muster bilden eine gute Orientierungshilfe Liste (Bestellung – Bestellposition), Baugruppe (Auto – Motor) und St ü ckliste mit physikalischem Enthaltensein. 2.F ü r eine Aggregation gilt: Es liegt eine Ist-Teil-von-Beziehung mit shared aggregation (ein Teilobjekt kann mehreren Aggregatobjekten zugeordnet werden) vor Sie ist selten 3.Im Zweifelsfall: immer einfache Assoziation Bei dem geringsten Zweifel an einer Komposition oder Aggregation immer die Assoziation w ä hlen 4.Fehlerquellen Prinzipiell ist es m ö glich, jedes Attribut als Klasse zu modellieren und mittels einer Komposition mit der urspr ü nglichen Klasse zu verbinden Dies f ü hrt jedoch zu schlechten Modellen. Aggregation und Komposition Die Definitionsphase: Checkliste Aggregation

46 46 Ergebnisse oSequenzdiagramm, Kollaborationsdiagramm F ü r jedes relevante Szenario: Sequenzdiagramm Alternativ: Kollaborationsdiagramme Konstruktive Schritte 1.Aus jedem Gesch ä ftsprozess (GP) mehrere Szenarios entwickeln Variationen von GPs ermitteln Standardausf ü hrung und Alternativen Positive und negative F ä lle unterscheiden Pr ü fen, welche Szenarios wichtig sind Diagramme benennen und beschreiben. 2.Ablauf relevanter Szenarios durch Sequenz- oder Kollaborationsdiagramme beschreiben Beteiligte Klassen Aufgaben in Operationen zerlegen Reihenfolge der Operationen pr ü fen UML erlaubt es, im Sequenzdiagramm Bedingungen anzugeben Damit k ö nnen mehrere Variationen durch ein einziges Sequenzdiagramm beschrieben werden 3.Operationen den Klassen zuordnen Werden nur Attribute einer Klasse ben ö tigt, dann ist die Operation dieser Klasse zuzuordnen Konstruktoren sind der jeweiligen Klasse selbst zuzuordnen. Szenario (1) Die Definitionsphase: Checkliste Szenario

47 47 Analytische Schritte 4.Sind die Empf ä nger-Objekte erreichbar? Assoziation existiert (permanente Verbindung) Identit ä t kann dynamisch ermittelt werden (tempor ä re Verbindung) 5.Sequenzdiagramm konsistent mit Klassendiagr.? Alle Klassen auch im Klassendiagramm enthalten Mit Ausnahme von impliziten Operationen werden nur Operationen aus dem Klassendiagramm eingetragen 6.Fehlerquellen Benutzungsoberfl ä che wird beschrieben Zu viele Details sind beschrieben. Szenario (2) Die Definitionsphase: Checkliste Szenario

48 48 Ergebnis oZustandsdiagramm Konstruktive Schritte 1.Existiert ein nicht-trivialer Lebenszyklus? 2.Welche Zust ä nde enth ä lt der Automat? Ausgangsbasis ist der Anfangszustand Durch welche Ereignisse wird ein Zustand verlassen? Ereignisse umgangssprachlich beschreiben, was » von au ß en auf das Objekt einwirkt « Welche Folgezust ä nde treten auf? Wodurch wird der Zustand definiert (Attributwerte, Objektverbindungen)? 3.Existieren Endzust ä nde? Nur bei linearen Lebenszyklen: Das Objekt h ö rt auf zu existieren Das Objekt existiert weiterhin, aber sein dynamisches Verhalten ist nicht l ä nger von Interesse (schlafendes Objekt) 4.Welche Operationen besitzt das Objekt? Jede zustandsabh ä ngige Operation aus dem Klassendiagramm eintragen Operationen, die in jedem Zustand ausgef ü hrt werden k ö nnen, nicht eintragen Pr ü fen, ob weitere Operationen notwendig sind Zustandsautomat (1) Die Definitionsphase: Checkliste Zustandsautomat

49 49 Konstruktive Schritte 5.Sind Operationen als Aktivit ä ten oder als Aktionen zu modellieren? 6.Welche Ereignisse sind zu modellieren? Externe Ereignisse: vom Benutzer von anderen Objekten Zeitliche Ereignisse: Zeitdauer Zeitpunkt Intern generierte Ereignisse des betrachteten Objekts Welche Fehlersituationen k ö nnen auftreten und wie soll das Objekt darauf reagieren (Ausnahmebehandlung) Zuerst immer das Normalverhalten und erst im zweiten Schritt das Fehlerverhalten betrachten. Zustandsautomat (2) Die Definitionsphase: Checkliste Zustandsautomat

50 50 Analytische Schritte 7.Geeigneter Zustandsname Beschreibt eine bestimmte Zeitspanne Kein Verb Kann entfallen, wenn er keine zus ä tzliche Information enth ä lt 8.Ist der Objekt-Lebenszyklus konsistent mit der Liste der Operationen? Gibt es f ü r jede Operation mindestens einen Zustand, in dem das Objekt auf die entsprechende Botschaft reagieren kann? Sind alle Aktivit ä ten und Aktionen auch Operationen des Klassendiagramms? 9.Sind alle Zustands ü berg ä nge korrekt eingetragen? Ist jeder Zustand erreichbar? Kann jeder Zustand – mit Ausnahme der Endzust ä nde – verlassen werden? Sind die Zustands ü berg ä nge eindeutig? 10.Fehlerquellen Modellierung der Benutzungsoberfl ä che im Lebenszyklus Gedankengut aus den Programmablaufpl ä nen ü bernommen » Schleifen « d ü rfen nicht vorkommen Bedingungen sind immer mit einem Ereignis verkn ü pft. Zustandsautomat (3) Die Definitionsphase: Checkliste Zustandsautomat

51 51 Ergebnisse oKlassendiagramm: Operationen eingetragen oBeschreibung der Operationen Konstruktive Schritte 1.Operationen ins Klassendiagramm eintragen Aus Szenarios & Zustandsautomat. übernehmen Listenoperationen hinzufügen Keine Verwaltungsoperationen eintragen 2.Vererbung von Operationen berücksichtigen Operationen so hoch wie möglich in der Hierarchie eintragen 3.Beschreibungen erstellen (nur wenn nötig). Analytische Schritte 4.Besitzt die Operation einen geeigneten Namen? Beginnt mit einem Verb Beschreibt, was die Operation »tut« 5.Erfüllt jede Operation die Qualitätskriterien? Angemessener Umfang Funktionale Bindung, d.h. jede Operation realisiert eine in sich abgeschlossene Funktion 6.Ist das balancing erfüllt? Alle Attribute werden von den Operationen benötigt 7.Fehlerquellen Keine Benutzungsoberfläche. Operationen Die Definitionsphase: Checkliste Operationen

52 52 Object Point-Methode /Sneed 96/ oGesch ä ftsprozess-Tabelle bzw. Prozess-Tabelle oKlassen-Tabelle oBotschaften-Tabelle bzw. Nachrichten-Tabelle oObjekt-Punkte = Prozess-Punkte + Klassen-Punkte + Botschaften-Punkte oDie Objekt-Punkte werden mit einem Qualit ä tsfaktor QF multipliziert Dazu werden 12 Qualit ä tsma ß e durch ihre prozentuale Erf ü llung definiert und nach festgelegten Regeln in eine Multiplikationsfaktor konvertiert. Object Point Methode 7.4. Die Definitionsphase: Aufwandschätzung

53 53 Die OOA verwendet die Basiskonzepte der Objektorientierung - Objekt, Klasse, Attribute, Operationen – erg ä nzt um die statischen Konzepte Assoziation, Vererbung, Paket und die dynamischen Konzepte Botschaft, Gesch ä ftsprozess, Zustandsautomat und Szenario um die fachliche Probleml ö sung zu modellieren. Dabei entstehen ein statisches und ein dynamisches Modell, die sich gegenseitig beeinflussen und ausbalanciert sein sollen. Muster (patterns) sind bew ä hrte generische L ö sungen f ü r immer wiederkehrende Probleme, die in bestimmten Situationen auftreten. OOA-Muster werden f ü r die Analyse und Konstruktion von OOA-Modellen benutzt. Wichtige OOA-Muster sind: Liste, Exemplartyp, Baugruppe, St ü ckliste, Koordinator, Rollen, wechselnde Rollen, Historie, Gruppe und Gruppenhistorie. Das Erstellen eines OOA-Modells auf der Grundlage schriftlicher Informationen, z.B. eines Pflichtenheftes, oder m ü ndlicher Informationen, z.B. durch Interviews, geh ö rt zu den schwierigsten Aufgaben der Software-Technik. Es handelt sich um einen iterativen Vorgang. Beschrieben wurde ein Makroprozess, der die Gleichgewichtigkeit von statischem und dynamischem Modell ber ü cksichtigt. F ü r jedes objektorientierte Konzept stehen einheitlich aufgebaute Checklisten zur Verf ü gung, die die Konstruktion und Analyse unterst ü tzen Die Definitionsphase: Zusammenfassung


Herunterladen ppt "1 Vorlesung Softwaretechnik Prof. Dr.-Ing.habil. Dipl.Math. Klaus-Peter Fähnrich (Wintersemester 2001/2002) Universität Leipzig Institut für Informatik."

Ähnliche Präsentationen


Google-Anzeigen