1 / 76

UML Modellierung und deklarative Programmierung mit Attributen Achim Oellers newtelligence AG

UML Modellierung und deklarative Programmierung mit Attributen Achim Oellers newtelligence AG. Voraussetzungen. Grundkenntnisse in OOA/OOD Objektorientierte Programmierung. Agenda. Skizze eines Analyseprozesses UML Grundlagen Statische und dynamische Modellierung

geneva
Download Presentation

UML Modellierung und deklarative Programmierung mit Attributen Achim Oellers newtelligence AG

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related