cd Blatt 5

Kontextmodelle

Zeigt die Grenzen und die Umgebung eines Systems, das zu entwickeln ist. Hilft, die Funktionalitäten und die Abhängigkeiten des Systems zu klären.

  • Bedeutung und Methodik

    • Definition der Grenzen: In der frühen Phase der Systemspezifikation müssen Grenzen des zu entwickelnden Systems festgelegt werden.
      Beispiel: Entscheidungen über die Automatisierung bestimmter Geschäftsprozesse.
    • Zusammenarbeit und Abstimmung: Die Festlegung erfolgt in Zusammenarbeit mit den Projektbeteiligten.
      Beispiel: Abstimmung mit den Stakeholdern über die Systemfunktionalitäten.
    • Konfigurierbare Systeme: Entwicklung anpassungsfähiger Systeme für heterogene Benutzeranforderungen.
      Beispiel: Ein System mit variablen Grenzen für unterschiedliche Benutzergruppen.
    • Nicht-technische Einflüsse: Systemgrenzen können auch durch gesellschaftliche und wirtschaftliche Faktoren beeinflusst werden.
      Beispiel: Standortwahl oder Managemententscheidungen, die die Systemgrenzen beeinflussen.

    Diagrammtypen in der Systemmodellierung

    • Aktivitätsdiagramme: Zeigen Datenverarbeitung und Kontrollflüsse. Ideal für Darstellung paralleler Aktivitäten und Entscheidungspunkte.
      Beispiel: Visualisierung der Prozessabläufe in einem System.
    • Anwendungsfalldiagramme: Stellen Interaktionen zwischen einem System und seinen Akteuren dar. Können Alternativen und Ausnahmen modellieren.
      Beispiel: Abbildung der Systemnutzung durch verschiedene Benutzertypen.
    • Sequenzdiagramme: Zeigen zeitliche Abfolge von Nachrichten zwischen Objekten im System. Können Aktivierungsdauer und Rückgabewerte anzeigen.
      Beispiel: Darstellung der Kommunikation zwischen Systemkomponenten über die Zeit.
  • Kurz gesagt: Die Festlegung von Systemgrenzen und der Einsatz verschiedener Diagrammtypen sind zentrale Aspekte der Systemmodellierung. Sie helfen, komplexe Systemanforderungen und -interaktionen verständlich darzustellen. Aktivitätsdiagramme illustrieren Prozesse und Kontrollflüsse, Anwendungsfalldiagramme zeigen Interaktionen mit Benutzern und Sequenzdiagramme veranschaulichen die zeitliche Abfolge von Systemoperationen. Diese Werkzeuge unterstützen effektiv die Kommunikation zwischen Stakeholdern und Entwicklern, um präzise und funktionale Systeme zu entwerfen.

Systemmodellierung und Interaktionsmodelle

  • 5.2.1 Anwendungsfallmodellierung

    Entwickelt von Ivar Jacobson in den 1990ern, dient die Anwendungsfallmodellierung der Darstellung von Interaktionen zwischen Benutzern und Systemen. Sie ist besonders hilfreich in den frühen Stadien des Systementwurfs, um Benutzeranforderungen zu verstehen und zu dokumentieren.

    • Anwendungsfall: Jeder Anwendungsfall repräsentiert eine Aufgabe, die externe Interaktion mit dem System umfasst, wie z.B. die Übertragung von Patientendaten.
    • Darstellung: Anwendungsfälle werden meist als Ellipsen abgebildet, beteiligte Akteure als Strichmännchen, und die Interaktionen werden in Tabellen oder Sequenzdiagrammen für detaillierte Beschreibungen genutzt.
      • Beispiel: "Arzthelfer"
        • Patient erfassen
        • Patient austragen
        • Patientendaten einsehen
        • Daten übertragen
        • Patient kontaktieren
  • 5.2.2 Sequenzdiagramme

    Sequenzdiagramme in UML zeigen zeitlich geordnete Interaktionen zwischen Akteuren und Systemobjekten, um das dynamische Verhalten während spezifischer Anwendungsfälle zu veranschaulichen.

    • Verwendung: Diese Diagramme eignen sich, um die Reihenfolge der Nachrichten und Interaktionen, Autorisierungschecks und Fehlerbehandlungen darzustellen.
    • Beispiel: Ein Sequenzdiagramm kann den Prozess der Anmeldung eines Arzthelfers und die anschließende Datenübertragung zu einem Patientenrekordsystem aufzeigen.

Strukturelle Modelle

Strukturelle Softwaremodelle visualisieren die Organisation eines Systems. Sie können sowohl die statische Struktur als auch die dynamische Organisation während der Ausführung abbilden. Klassendiagramme sind dabei ein zentrales Werkzeug zur Darstellung der statischen Struktur von Objektklassen.

  • Klassendiagramme

    • Visuelle Strukturierung: Klassendiagramme visualisieren die Struktur objektorientierter Systeme durch Darstellung von Klassen und Beziehungen.
      Beispiel: Abstrakte Definitionen von Benutzer, Produkt, oder Dienstleistungen als Klassen im System.
    • Assoziationen und Kenntnisse: Beziehungen zwischen Klassen werden durch Assoziationen verdeutlicht, wobei Klassen Wissen über Verbindungen teilen.
      Beispiel: Eine Klasse "Kunde" könnte mit der Klasse "Bestellung" über eine Assoziation verbunden sein.
    • Detaillierung und Multiplizität: Die Detailebene kann variieren; Multiplizität zeigt, wie viele Instanzen in einer Beziehung stehen.
      Beispiel: Eine 1:1-Beziehung zwischen "Konto" und "Kunde" oder eine 1:n-Beziehung zwischen "Hersteller" und "Produkte".
    • Attribute und Operationen: Klassen können Attribute und Operationen beinhalten, die im Diagramm innerhalb der Klassenrechtecke dargestellt werden.
      Beispiel: Die Klasse "Artikel" könnte Attribute wie "Preis" und Operationen wie "Preis aktualisieren" haben.
    • Kurz gesagt: Klassendiagramme klären die Systemstruktur und -dynamik, indem sie Klassen, deren Eigenschaften und Beziehungen visuell festhalten. Sie sind essentiell für das Design und die Vorab-Planung in der Softwareentwicklung.

    Generalisierung

    • Komplexitätsbewältigung: Generalisierung klassifiziert Objekte in allgemeinere Klassen zur effizienten Komplexitätsreduktion.
      Beispiel: Eichhörnchen und Ratten als Mitglieder der Klasse „Nagetiere“.
    • Designeffizienz: Gemeinsame Klasseninformationen werden zentral gespeichert, um Designänderungen zu erleichtern.
      Beispiel: Vererbung von Attributen wie „Name“ und „Telefonnummer“ in Arztklassen.
    • Vererbungskonzept: Generalisierung wird durch Klassenvererbung in Sprachen wie Java umgesetzt, die in UML durch Pfeilspitzen visualisiert wird.
      Beispiel: Krankenhausärzte als spezialisierte Unterklassen der generellen „Arzt“-Klasse.
    • Hierarchische Darstellung: UML-Assoziationen mit Pfeilspitzen illustrieren Generalisierungshierarchien und Vererbungsbeziehungen.
      Beispiel: Hierarchie von Arzttypen, von Allgemeinmedizinern bis Fachärzten.
    • Attribut- und Operationsvererbung: Unterklassen erben und erweitern Attribute und Operationen von Oberklassen.
      Beispiel: Eine Unterklasse „Zugelassener Arzt“ fügt spezifische Funktionen zur Oberklasse „Arzt“ hinzu.
    • Kurz gesagt: Generalisierung in der Informatik ist ein Schlüsselkonzept zur Vereinfachung komplexer Systeme, indem Objekte in allgemeinere Kategorien klassifiziert werden. Sie ermöglicht es, gemeinsame Eigenschaften und Verhaltensweisen in einer Oberklasse zu zentralisieren, was Wiederverwendung und Wartbarkeit verbessert. In objektorientierten Sprachen wie Java unterstützt sie die effiziente Verwaltung von Code durch Vererbung und fördert klar strukturierte und modulare Systemarchitekturen.

    Aggregation

    • Aggregationskonzept: Aggregation beschreibt eine "hat-ein"-Beziehung, bei der ein Objekt als ein Ganzes aus mehreren Teilen besteht. Es ist eine spezielle Form der Assoziation, die zeigt, wie Objekte zu einer größeren Einheit zusammengefasst werden.
      Beispiel: Ein "Auto" aggregiert Objekte wie "Räder", "Motor" und "Karosserie", die unabhängig voneinander existieren können.
    • Realweltanalogie: In der Realwelt finden wir Aggregation bei Objekten wie einem Studienpaket, das aus Büchern, Folien und weiteren Materialien besteht.
      Beispiel: Ein Seminar-Paket, das verschiedene Lehrmaterialien umfasst.
    • UML-Modellierung: UML nutzt das Aggregationskonzept, um die Zusammensetzung von Objekten in einem Systemmodell zu illustrieren.
      Beispiel: Ein Patientendatensatz, der aus Patienteninformationen und verschiedenen Konsultationen besteht.
    • Kurz gesagt: Aggregation hilft bei der Darstellung komplexer Beziehungen in Systemmodellen, indem sie zeigt, wie einzelne Teile zu einem kohärenten Ganzen zusammengeführt werden. Sie reflektiert die reale Weltstruktur in einem modellierten System und bietet Flexibilität durch die unabhängige Existenz der Komponenten.

Modellgetriebene Architektur (MDA)

Modellgetriebene Architektur revolutioniert die Softwareentwicklung durch die Verwendung von Modellen auf verschiedenen Abstraktionsebenen und die automatische Codegenerierung, die das Design und die Wartung von Softwaresystemen vereinfacht.

  • Kernkonzepte von MDA

    • Abstraktionsebenen: MDA unterscheidet zwischen rechen-, plattformunabhängigen und plattformspezifischen Modellen, um Flexibilität und Anpassungsfähigkeit zu maximieren.
      Beispiel: Vom Konzept bis zum konkreten Produkt durch unterschiedliche Modellierungsebenen.
    • Codegenerierung: Die Fähigkeit, ausführbaren Code direkt aus UML-Modellen zu generieren, beschleunigt die Entwicklung.
      Beispiel: Automatische Umwandlung eines plattformunabhängigen Modells in eine Java-Anwendung.
    • Praktische Herausforderungen: Trotz des Ideals der vollständigen Automatisierung erfordert MDA oft manuelle Eingriffe und Anpassungen.
      Beispiel: Anpassung des generierten Codes an spezifische Anwendungslogik und Performance-Anforderungen.
    • Anwendungsbereiche: MDA eignet sich besonders für langfristige Systemprodukte, wo Skalierbarkeit und Wartbarkeit im Vordergrund stehen.
      Beispiel: Einsatz in der Entwicklung von Unternehmensanwendungen und komplexen Steuerungssystemen.
    • Kurz gesagt: MDA bietet einen strukturierten Ansatz zur Softwareentwicklung, der auf der Automatisierung und Modelltransformation basiert. Es fördert die Wiederverwendung von Modellen und die Konsistenz über verschiedene Plattformen hinweg, stößt jedoch manchmal auf Herausforderungen bei der Integration in agile Prozesse.

1. Klassendiagramme I

  1. Stellen Sie die Klassen in a1 in einem UML-Klassendiagramm dar. Ihr Diagramm sollte möglichst alle Informationen, die Sie aus dem Code herleiten können abbild

  2. Klassendiagramm

2. UML Zustandsdiagramm

  1. Erstellen Sie ein Zustandsdiagramm für ein automatisches Hoftor. Das Tor ist initial geschlossen. Nun kann auf einem Bedienfeld ein Passwort eingegeben werden. Ist das eingegebene Passwort falsch, blinkt eine rote Warnleuchte. Diese Warnleuchte schaltet sich nach 30 Sekunden automatisch wieder ab. Erst nach diesen 30 Sekunden kann erneut ein Passwort eingegeben werden (das Tor geht also wieder in den Initialzustand). Ist das eingegebene Password korrekt, dann öffnet sich das Tor. Das Öffnen dauert 40 Sekunden. Sobald das Tor offen ist wird ein Bewegungssensor aktiv. Dieser Sensor prüft alle 10 Sekunden, ob sich jemand im Tor befindet. Falls sich jemand im Tor befindet wartet der Sensor wieder 10 Sekunden, bevor er erneut prüft. Anderenfalls schließt sich das Tor wieder. Unabhängig vom Bewegungssensor schließt sich das Tor spätestens 120 Sekunden nachdem es vollständig geöffnet ist wieder. Das Schließen dauert immer 40 Sekunden. Danach befindet sich das Tor in seinem Ausgangszustand. Wenn das Tor geschlossen ist, kann es deaktiviert werden. Daraufhin geht es in den einzigen Endzustand über.

K Klassendiagramme II

  1. Bilden folgende Diagramme die echte Welt ab? Begründen Sie Ihre Antwort falls nicht

  2. Klassendiagramm
    1. Das Diagramm stellt nicht die Realität dar, da Personen nicht mehrere Geburtstage haben können, aber mehrere Personen am selben Tag Geburtstag haben können.
    2. Im Diagramm muss sichergestellt werden, dass für ein Quadratdie Bedingung Höhe = Breite gilt, sonst wäre das Diagramm nicht korrekt.
    3. Das Diagramm bildet die Realität ab, da eine Bibliothekmehrere Bücher enthalten kann und Bücher unabhängig von einerBibliothek existieren können; ebenso kann eine Bibliothek ohneBücher existieren.

K Sequenzdiagramm

  1. Betrachten Sie folgende UML Sequenzdiagramme. Geben Sie jeweils an, ob die Diagramme die reale Welt korrekt modellieren. Begründen Sie Ihre Entscheidung kurz.

  2. Klassendiagramm
    1. Davon ausgehend dass der Kunde Vanille bestellt weil er sieht dass diese vorhanden ist, und der Eisladen keine Waffeln hat, sowie die Zahlung als einzelner Vorgang betrachtet wird, ja.
    2. Nein, damit der Automat die Pin prüfen kann muss diese zuvor vom Kunden eingegeben werden