UML Modellierung und deklarative Programmierung mit Attributen Achim Oellers newtelligence AG

1. UML Modellierung und deklarative Programmierung mit Attributen Achim Oellers newtelligence AG

2. Voraussetzungen • Grundkenntnisse in OOA/OOD • Objektorientierte Programmierung

3. Agenda • Skizze eines Analyseprozesses • UML Grundlagen • Statische und dynamische Modellierung • Entsprechungen zwischen Modellierung und Programmkonstrukten • Stereotypen und Tagged Values • Metamodellerweiterungen • Modellierung in Visual Studio .NET • Custom Attributes • Konzepte und Umsetzung in C# • Ansätze für ein Applikationsframework • Codegenerierung aus Visual Studio .NET

4. Begriffe und Konzepte • Objekte • Physische oder konzeptionelle Begriffe • Zustand • Zustand eines Objektes • Auf relevante Dinge beschränkt • Ist ein Internum • Actors • Objekte mit Eigenleben • Müssen nicht menschliche Benutzer sein

5. Begriffe und Konzepte • Klasse • Kategorisierung strukturell identischer Objekte • Hat einen Mechanismus zur Erzeugung von Objekten • Instanzen • Individuelle Objekte – durch den klasseneigenen Mechanismus erzeugt • Metaklasse • Eine Klasse, deren Instanzen Klassen sind • Parametrisierte Klasse • Eine Klasse, die zur Erzeugung vonKlassen Parameter benötigt

6. Begriffe und Konzepte • Abstrakte Klasse • Zusammenstellung unvollständiger Konzepte • Wird durch Spezialisierung verfügbar • Wird niemals instanziiert • Members • Methoden • Konstanten • Attribute (In .NET: Fields) • Exceptions • Events

7. Begriffe und Konzepte • Interface • Physisch: Zusammenstellung von öffentlichen Members • Konzeptionell: Semantischer Kontrakt • Aggregation • Ein oder mehrere Objekte werden Teil eines anderen • Monolithisch: • Struktur ist von außen nicht direkt erkennbar • Eventuell durch Interface zugreifbar

8. Begriffe und Konzepte • Vererbung • Beziehung, in der eine Klasse die Eigenschaften der anderen erhält • Einfach oder mehrfach • Spezialisierung • Genauere Bestimmung • Generalisierung • Allgemeinere Bestimmung

9. Software Engineering Prozess • Fachleute und Softwareentwickler sprechen unterschiedliche Sprache • Übersetzungen werden notwendig • Übersetzungen machen Probleme • Gemeinsame Sprache wird benötigt • Eine grafische Sprache mit wenigen Elementen • Umsetzungen statt Übersetzungen • Automation wo möglich • Aber: „Bunte Bildchen“ ohne definierten Prozess sind sinnlos!

10. Probleme der Anforderungsanalyse • Qualität ist Erfüllung von Anforderungen • Ein Fehler ist eine Nichterfüllung einer Anforderung • Was bedeutet "Nichterfüllung"? • Messbarkeit ist gefordert • Anforderungen müssen schriftlich vorliegen • Müssen mit Akzeptanzkriterien versehen sein • Exemplarische Kommentare und Beweisgrundlage • Kunde ist für Korrektheit der Anforderungen verantwortlich • Auftragnehmer ist für die Konsistenz der Anforderungen verantwortlich

11. Weitere Probleme • Typische Probleme bei Anforderungsaufnahme • Auslassungen • Widersprüche • Mehrdeutigkeiten • Mehrfachdefinitionen • Ungenauigkeiten • Zu viel Design • Prioritäten nicht definiert • Irrelevante Informationen

12. Pre-Analysis • Beschreibe die Aufgabe • Normalerweise: • Eine wohlbekannte Lösung für ein wohlbekanntes Problem zu automatisieren • Keine (software-)technischen Termini benutzen • Nur die fachlichen Begriffe • Benutze nur verlässliche Informationsquellen • Achte auf angemessenes Antwortverhalten • Das System muss alle Anforderungen abbilden • Das System soll keine Funktionalität ausserhalb der Anforderungen beinhalten • "Einfach – kurz – klar"

13. Problem-Dekomposition • Für jedes Problem gibt es ein angemessenes Abstraktionsniveau • Finde Subjekte, Prädikate, Objekte : Use Cases • Welche Aufgaben soll das System erfüllen? • Bezeichnet eine für den Benutzer sichtbare Funktion • Erfüllt ein konkretes Ziel des Benutzers • Beachte die 7±2-Regel • Wird ein Use Case zu groß – unterteile ihn • Dies alles hat nichts mit der Benutzeroberfläche zu tun

14. Analyse-Prozess Anforderungen Akzeptanz-kriterien Integrations- Modell Test Szenarien Simulations-Modell

15. Anforderungen • Beschreiben ein einzelnes Leistungsmerkmal • Prosa in der natürlichen Sprache des Kunden • Er verantwortet die Korrektheit • Grafiken und Formeln wenn nötig • Beispiel: • „Jeder Kunde hat ein bestimmtes Kreditlimit." • Beschreibt die Welt des Benutzers – nicht ein Softwaresystem!

16. Akzeptanzkriterien • Beschreiben einen Test, ob eine Anforderung erfüllt ist oder nicht • Ist ein Beispiel • Ist ein Testfall • Ist rechtlich bindend • Wenn alle Akzeptanzkriterien erfüllt sind, ist das System o.k. • Jedes AK bezieht sich auf eine einzelne Anforderung • Jede Anforderung hat mindestens ein Akzeptanzkriterium • AKen müssen so konkret wie möglich sein – keine Interpretationsmöglichkeiten • Bloße Anerkennung einer Anforderung ist nicht genug

17. Akzeptanzkriterium • Struktur: • Situation: • „Kunde Schmitz hat zwei Kredite, einer über 10K€, einer über 20K€; sein Kreditlimit ist 50K€. " • Aktion: • "Schmitz beantragt einen weiteren Kredit über 15K€." • Erwartetes Ergebnis: • Kunde Schmitz bekommt den Kredit, und hat anschließend drei Kredite mit einer Gesamtsumme von 45K€."

18. Offene Fragen • Probleme zeigen sich oft bei der Integration der Anforderungen • Analyst muß Lösung anfragen • Lösung kann angenommene Antwort enthalten • Rückfrage ist terminiert • Angenommene Antwort „wird wahr“ • Beispiel: • Frage: „Eine Anforderung nimmt ein gemeinsames Kreditlimit für alle Kunden an, eine andere verschiedene Limits je nach Kunde. Was ist richtig? " • Angenommene Antwort: „Kreditlimits sind je nach Kunde verschieden."

19. Integrationsmodell • Ein OOA-Modell mit allen Anforderungen • Integration der verschiedene Aspekte der Dinge • Sollte mit Hilfe eines Werkzeugs erstellt werden • Identifikation von Klassen und Assoziationen

20. Simulationsmodell • Lauffähiger Abkömmling des Integrationsmodells • Ist keine Zeitverschwendung! • Ist der einzige Weg, Übereinstimmung mit den Anforderungen sicherzustellen • Sollte von einem Werkzeug generiert werden • Lasse Testszenarien dagegen laufen • Abgeleitet von Akzeptanzkriterien • Wenn es funktioniert, ist kein Platz mehr für fachliche Fehler

21. Grafische Modellierung • Darstellung des Integrationsmodells • Grafik kann nur grobe Struktur zeigen • Hinter der Grafik ist mehr • Werkzeuge ermöglichen erst die Arbeit • Auch hier gilt: Einfach, kurz, klar!

22. UML • UML kann mit jedem Prozessmodell und jeder Methode eingesetzt werden • Mächtiges, erweiterbares Modell • Definiert diverse verschiedene Diagramme • Weit verbreitet, gut bekannt • Viele Publikationen und Kommentare • Gute Werkzeugunterstützung auf allen Plattformen

23. Architektur • UML ist definiert auf vier verschiedenen Ebenen • Jede Ebene ist eine Instanz der darüberliegenden Meta-Metamodel Layer Metamodel Layer Model Layer User Model Layer

24. Diagrammtypen • User Model • Use Case Diagramme • Structural Model • Klassen- und Objektdiagramme • Behavioral Model • Sequenz-, Kollaborations-, Zustandsdiagramme • Aktivitätendiagramme • Implementation Model • Komponentendiagramme • Environment Model • Verteilungsdiagramme

25. Use Cases • Actors • Menschliche Benutzer • Externe Systeme • Objekte, die Messages generieren • Use Cases • Können untereinander Beziehungen haben • Extends • Uses • Achtung: • Use Cases stellen einen funktionsorientierten Blick auf das System dar • Strukturiere das Problem - nicht das System!

26. Use Case Diagram

27. Klassendiagramme • Statische Sicht auf Struktur und Beziehungen der Dinge • Beschreibt Klassen • Members • Attribute, Methoden • Eigenschaften • Stereotyp • Abstrakt oder instanziierbar • Sichtbarkeit • Und mehr... • Beziehungen zwischen den Klassen • Assoziationen • Aggregationen • Generalisierungen/Spezialisierungen

28. Klassenbeschreibung Stereotyp Klassenname Attribute Sichtbarkeit Methoden

29. Assoziationen • Beziehung zwischen (zwei) Klassen • Beide Enden bezeichnen jeweils eine Rolle die die Klassen in der Beziehung einnehmen • Kann uni- oder bidirektional sein • Haben eine bestimmte Kardinalität auf beiden Seiten • Navigierbare Rollen und Kardinalitäten

30. Assoziationsklassen • Assoziationen mit eigenen Eigenschaften • Modelliert als Klassen

31. Aggregationen • Integrale Bestandteile werden aggregiert • Üblicherweise nur notwendige Teile • Aggregation kann „shared" oder "composite„ sein

32. Generalisierung/Spezialisierung • Stellt Vererbungsbeziehungen dar • Interfaces werden mit besonderem Symbol dargestellt

33. Assoziationsqualifizierer • Qualifizierer sind Eigenschaften der Assoziation • Dienen zur Bestimmung der Art des Verhältnisses

34. Klassediagramm

35. Utilities • Zusammenfassung von globalen Konstanten und Methoden in Form einer Klasse • Enthält nur statische Methoden

36. Erweiterungsmechanismen • Einfache Erweiterungen • Stereotypen • Tagged Values • Constraints • Metamodellerweiterungen

37. Stereotypen • Einfachste Form der UML-Erweiterung • Kategorisiert Klassen, Attribute, Methoden • Führt neue Modellelemente ein • Einige vordefinierte Stereotypen: <<interface>>, <<struct>> • Werkzeuge erlauben in der Regel völlig freie Definition

38. Tagged Values • Schlüssel-Werte-Paar • Kann jedem Modellelement hinzugefügt werden • Können frei definiert werden • Haben standardmäßig keinerlei Auswirkung auf Codegenerierung

39. Metamodellerweiterung • Beschreibung • Vorausgesetzte Erweiterungen • Stereotypen • Name • Metamodell-Klasse (die erweitert wird) • Semantiken • Syntax (Notation) Icon • Constraint Property • Tagged Value Property • Well-formedness Regeln • Generalisierung • Assoziation • Kommentare

40. Packages • Jede Klasse gehört genau einem Package an • Referenzierung einer Klasse innerhalb desselben Package ist unkompliziert • Benutzung einer Klasse aus einem anderen Package induziert Abhängigkeit • Ziel sind minimale Abhängigkeiten • Nur “public”-Klassen können von ausserhalb des Packages referenziert werden

41. Package Diagramm

42. Design Patterns • Beschreiben die technische Sicht auf ein fachliches Detail • Sind wohldokumentierte Teillösungen für wiederkehrende Probleme • Werden erst in der Designphase angewandt

43. Singleton • Stelle sicher, dass es nur eine Instanz von einem Objekt geben kann

44. Decorator • Füge Funktionalität dynamisch hinzu

45. Composite • Baumstruktur, die eine Teil-/Ganzes-Beziehung abbildet • Funktioniert mit einzelnen Objekten oder Composites

46. Proxy • Kontrolliere den Zugriff auf eine Objekt durch einen Stellvertreter • Nützlich als: • Remote, virtueller oder Schutz-Proxy • Smart References

47. Command • Kapsele einen Methodenaufruf als Objekt

48. Observer • Definiert eine eins-zu-viele Beziehung zwischen Objekten • Änderungen in dem einem Objekt werden an die vielen Objekte signalisiert

49. State • Dynamische Verhaltensänderung in Abhängigkeit vom Zustand

50. Aktivitätendiagramme • Dynamisches Modell • Flussdiagramm mit Parallelflüssen und Synchronisation • Nützlich für: • Paralleles Verhalten • Wie verschiedene Use Cases miteinander zusammenhängen