SWT - Blatt 6

1 Klassendiagramme I

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, abbilden.

classDiagram
Gast --> Person : extends
Mitarbeiter --> Person : extends

class Person {
    <<abstract>>
    - vorname : String
    - nachname : String
    - geburtsdatum : String
    + getVorname() : String
    + getNachname() : String
    + getGeburtsdatum() : String
}

class Gast {
    - einladenderMitarbeiter : Mitarbeiter
    + Gast(einladender : Mitarbeiter)
    + getEinladenderMitarbeiter() : Mitarbeiter
}

class Mitarbeiter {
    - mitarbeiterNummer : String
    ~ Mitarbeiter(vorname : String, nachname : String, geburtsdatum : String)
    + raumBuchen(raum : Raum) : RaumBuchung
    + getMitarbeiterNummer() : String
    ~ static anzahlMitarbeiter : int
}

class Gebäude {
    - räume : Set<Raum>
    ~ addRaum(raum : Raum) : void
}

class Gerät {
    - name : String
    ~ Gerät(name : String)
    + getName() : String
}

class Raum {
    - ausstattung : Set<Gerät>
    - gebäude : Gebäude
    ~ Raum(gebäude : Gebäude)
    + getGebäude() : Gebäude
    + addGerät(gerät: Gerät) : void
}

class Raumbuchung {
    - mitarbeiter : Mitarbeiter
    - raum : Raum
    - buchungsZeitraum : String
    + Raumbuchung(mitarbeiter : Mitarbeiter, raum: Raum, buchungsZeitraum: String)
}

2 UML Zustandsdiagramm

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 Passwort 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.

stateDiagram-v2
    [*] --> Geschlossen
    Geschlossen --> Warnleuchte: Passwort falsch
    Geschlossen --> Öffnen: Passwort richtig
    Geschlossen --> Deaktiviert: Deaktivieren

    Warnleuchte --> Geschlossen: 30 Sekunden abgelaufen

    Öffnen --> Offen: 40 Sekunden

    Offen --> BewegungssensorAktiv: Bewegungssensor aktiviert
    BewegungssensorAktiv --> Offen: Bewegungssensor erkennt Person
    BewegungssensorAktiv --> Schließen: Bewegungssensor erkennt keine Person

    Offen --> Schließen: 120 Sekunden abgelaufen

    Schließen --> Geschlossen: 40 Sekunden

    Deaktiviert --> [*]

Frage: Wäre das hier so auch in Ordnung?

3 Risikomanagement

An einem Lehrstuhl einer Universität gibt es in der Regel drei Typen von Personen: die verantwortliche Professor:in, einige Mitarbeitende und mehrere Studierende, quasi eine typische Lehrstuhlhierarchie. Der Lehrstuhl führt über mehrere Jahre ein größeres Forschungs- bzw. Softwareprojekt durch, an dem alle Personen beteiligt sind.

Zeigen sie anhand von zwei konkreten Beispielen auf, welche Risiken bestehen, die eine Fortführung des Projektes gefährden können. Sie können hierbei auch allgemeine Risiken als Basis verwenden und diese auf den Lehrstuhl konkretisieren. Welche vorbeugenden Maßnahmen könnte man dagegen anwenden? Welche Maßnahme ist bei welcher Person sinnvoll?

• Ein Problem ist, dass an dem Projekt alle drei Typen von Personen enthalten sind und die Forschung-/ Softwareprojekt über mehrere Jahre hinweg geht. Da beispielsweise Studierende eine Regelstudienzeit von knapp drei Jahren, muss sich also ungefähr alle 3 Jahre eine neue Studentengruppe in das Projekt einarbeiten und auf den Forschungsergebnissen-/ Code der früheren Studierenden arbeiten, was zu sehr viel Overhead und Problemen führen kann, da es schwer sein kann die neuen Studierenden in dieses Projekt einzuarbeiten, wenn es vergleichsweise groß ist. Auch Mitarbeiter und Professoren können sich vom Institut abwenden und können eventuell so dass Projekt frühzeitig verlassen und somit gefährden. Eine Maßnahme bei den Mitarbeitern und Professoren wären beispielsweise Verträge mit Kündigungsbedingungen. Wobei Studierende zum Beispiel auf eine gute Dokumentation des Codes und Projektes achten. Workshops um neuen Studenten eine Einarbeitung durch erfahreneren Studierenden zu geben.
• Bei solch einem Projekt könnte die Kommunikation zwischen den verschiedenen Ebenen und auch innerhalb der Ebenen sich als sehr Schwierig erweisen. Die Studenten beispielsweise sind in Überzahl und es wär schwer Ihnen Aufgaben zum Projekt gleichmäßig und nach Individuellen Stärken und Schwächen zu geben. Die Mitarbeiter könnten überlastet werden als Kommunikationsbrücke zwischen Mitarbeiter und Proffesoren, wobei die Professoren ihren Zielen der Forschung und Lehre eventuell nicht mehr nachkommen könnten, aufgrund des entstehenden Overheds des Projekts. Eine Maßnahme wäre eine limitierte Teilnehmeranzahl von Projektarbeitern und ein gut strukturiertes Mittel für die Arbeitsverteilung zum Beispiel durch agile Methoden und Scrum

K Risikomanagement

Kreuzen Sie für die folgenden Szenarien an, zu welcher Art von Risiko sie gehören.

Szenario	Projekt	Produkt	Geschäft
Eine Mitarbeiterin fällt aus.	$X$
Eine Library die Sie für das Projekt nutzen wird nicht mehr weiterentwickelt und funktioniert nun auf dem neuesten Betriebssystem nicht mehr.		$X$
Mehr als 80 % der Geldmittel sind verbraucht und die Software hat erst einen Bruchteil der Features die vereinbart wurden.	$X$	$X$
Für Ihre Machine Learning Applikation warten Sie seit Wochen auf die Bereitstellung von GPUs.	$X$
Während Sie die SWT-TV Mediathek entwickeln, kommen andauernd neue Features hinzu und die User Stories für die Mitarbeitenden werden regelmäßig komplett geändert.	$X$	$X$
Nur wenige Wochen bevor Ihre Mediathek SWT-TV online gehen soll veröffentlicht OMG-Now ein Videoportal mit ähnlichen Features.			$X$

K Klassendiagramme II

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

Diagramm 1

classDiagram
    Person --> "1" Datum : geboren_am
    class Person {
        +name : String
    }
    class Datum {
        +tag : integer
        +monat : integer
        +jahr : integer
    }

Das erste Diagramm stellt die Realität nicht korrekt dar, da Personen nicht mehrere Geburtstage haben können. Gleichzeitig können jedoch mehrere Personen am selben Tag Geburtstag haben. Um die Realität korrekt abzubilden, müsste das Diagramm eine 1:N-Beziehung zwischen Datum und Person modellieren, bei der ein Datum mit mehreren Personen verknüpft werden kann.

Diagramm 2

classDiagram
    Rechteck <|-- Quadrat

    class Rechteck {
        +höhe : integer
        +breite : integer
        +setDimensions(h:integer, b:integer)
    }
    class Quadrat {
        +höhe : integer
        +breite : integer
        +setDimensions(h:integer, b:integer)
    }

    note for Rechteck "Sets höhe = h and breite = b"

Das zweite Diagramm kann je nach Kontext korrekt oder fehlerhaft sein. Wenn die Methode setDimensions sicherstellt, dass höhe = breite gilt, bildet das Diagramm die Realität korrekt ab. Andernfalls wäre es fehlerhaft, da die Definition eines Quadrats verletzt wird. Es hängt also davon ab, ob die Bedingung in der Implementierung durchgesetzt wird.

Diagramm 3

classDiagram
    class Bibliothek {
    }
    class Buch {
    }
    Bibliothek "1" --> "N" Buch : "enthält"

Das dritte Diagramm bildet die Realität korrekt ab, da eine Bibliothek mehrere Bücher enthalten kann und Bücher unabhängig von einer Bibliothek existieren können. Ebenso kann eine Bibliothek ohne Bücher existieren, was die Aggregation sinnvoll beschreibt.

---

K Sequenzdiagramm

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

Diagramm 1: Eiscreme-Kauf

sequenceDiagram
    Kunde->>Verkäufer: 1 Kugel Vanille
    Verkäufer-->>Kunde: Eisbecher

Das Diagramm könnte die Realität korrekt abbilden, wenn folgende Annahmen getroffen werden:

• Der Kunde bestellt Vanille, da er sieht, dass diese Sorte verfügbar ist.
• Der Eisladen bietet keine Waffeln an, weshalb der Kunde einen Eisbecher erhält.
• Die Zahlung wird als eigenständiger Vorgang betrachtet und ist daher nicht im Diagramm enthalten.

Mit diesen Voraussetzungen kann das Diagramm die Realität korrekt modellieren. Ohne diese Annahmen bleibt es unvollständig, da z.B die Bezahlung fehlt.

Diagramm 2: Geldautomat

• Das Diagramm stellt die Realität nicht korrekt dar. Das Geld wird hier ausgegeben, bevor der PIN geprüft wird. In der Realität würde der Geldautomat zuerst die PIN des Kunden prüfen, bevor eine Auszahlung erfolgen kann. Die Reihenfolge der Interaktionen müsste angepasst werden, um die Realität korrekt zu modellieren.

---