Grundlagen des Software Engineering - Exam

Aufgabe 1)

Betrachte die beiden Softwareentwicklungsmethoden:

• Das Wasserfall-Modell ist ein sequentielles Modell, bei dem die Phasen Anforderungsanalyse, Design, Implementierung, Testen und Wartung in einer festen Reihenfolge durchlaufen werden.
• Agile Methoden, wie Scrum und Kanban, betonen iterative Entwicklung, flexible Reaktion auf Veränderungen und enge Zusammenarbeit innerhalb des Teams.

a)

a) Erläutere die wesentlichen Unterschiede zwischen dem Wasserfall-Modell und agilen Methoden (z.B. Scrum und Kanban) im Kontext der Softwareentwicklung. Nenne mindestens drei Unterschiede und gehe dabei insbesondere auf die folgenden Aspekte ein: Flexibilität, Kundenfeedback und Teamstruktur.

Lösung:

• Flexibilität:Das Wasserfall-Modell folgt einem starren, linearen Ansatz, bei dem jede Phase vollständig abgeschlossen sein muss, bevor die nächste beginnt. Änderungen während späterer Phasen sind schwer umzusetzen. Im Gegensatz dazu zeichnen sich agile Methoden durch ihre Flexibilität aus. Hier wird in kurzen, iterativen Zyklen gearbeitet, was es ermöglicht, Änderungen und Anpassungen schnell in die Entwicklung einzubringen.
• Kundenfeedback:Im Wasserfall-Modell wird Kundenfeedback hauptsächlich am Anfang (Anforderungsanalyse) und am Ende (Tests und Endabnahme) des Projekts eingeholt. Dies kann dazu führen, dass wesentliche Änderungen, die der Kunde wünscht, erst spät erkannt und schwer umsetzbar sind. Agile Methoden hingegen legen großen Wert auf kontinuierliches und regelmäßiges Kundenfeedback während des gesamten Entwicklungsprozesses, was sicherstellt, dass das Endprodukt den Kundenanforderungen besser entspricht und schneller angepasst werden kann.
• Teamstruktur:Das Wasserfall-Modell tendiert zu einer klaren, hierarchischen Teamstruktur, wo jedes Teammitglied eine feste Rolle hat und die Kommunikation überwiegend vertikal verläuft. Agile Methoden fördern eine flachere Hierarchie und selbstorganisierende Teams, wo die Zusammenarbeit und Kommunikation unter den Teammitgliedern gleichwertig und direkt ist. Dies fördert die Eigenverantwortlichkeit und Flexibilität innerhalb des Teams.

b)

b) Angenommen, Du bist der Projektleiter in einem Softwareentwicklungsprojekt. Beschreibe, wie Du eine Sprint-Planungssitzung im Rahmen von Scrum durchführen würdest. Erwähne dabei, welche Rollen beteiligt sind und welche Zielsetzung die Sitzung verfolgt.

Lösung:

Sprint-Planungssitzung im Rahmen von Scrum:

• Rollen: An einer Sprint-Planungssitzung nehmen die folgenden Rollen teil:
  • Product Owner: Er oder sie ist für die Priorisierung der Anforderungen (Product Backlog) verantwortlich und sorgt dafür, dass das Team versteht, welche Aufgaben den größten Kundenwert liefern.
  • Scrum Master: Diese Person moderiert die Sitzung, stellt sicher, dass die Scrum-Prinzipien eingehalten werden, und unterstützt das Team bei der Erreichung der Ziele.
  • Entwicklungsteam: Das sind die Personen, die die eigentliche Arbeit erledigen. Sie schätzen den Aufwand der Aufgaben und verpflichten sich, diese während des Sprints zu erledigen.
• Zielsetzung: Das Hauptziel der Sprint-Planungssitzung ist es, einen Plan für den nächsten Sprint zu erstellen. Dabei wird entschieden, welche Einträge aus dem Product Backlog in den Sprint Backlog übernommen werden. Die wichtigsten Schritte in dieser Sitzung sind:
  • Definition des Sprint-Ziels: Das Team und der Product Owner definieren gemeinsam ein konkretes Ziel für den kommenden Sprint, das den Fokus und die Richtung der Arbeit vorgibt.
  • Auswahl der Backlog-Einträge: Der Product Owner präsentiert die am höchsten priorisierten Einträge aus dem Product Backlog. Das Entwicklungsteam diskutiert dann diese Einträge und wählt diejenigen aus, die sie im Rahmen des Sprints liefern können.
  • Aufwandsschätzung: Das Entwicklungsteam schätzt den Aufwand für jede ausgewählte Aufgabe. Dies kann mithilfe von Schätzmethoden wie Planning Poker geschehen.
  • Erstellung des Sprint-Backlogs: Die aus dem Product Backlog ausgewählten Einträge werden in konkrete, umsetzbare Aufgaben zerlegt und in den Sprint Backlog aufgenommen.
• Verlauf der Sitzung:
  • Die Sitzung beginnt mit einer Einführung durch den Scrum Master, der den Zweck und die Agenda der Sitzung erklärt.
  • Der Product Owner stellt die priorisierten Einträge aus dem Product Backlog vor und erläutert das gewünschte Sprint-Ziel.
  • Das Entwicklungsteam diskutiert die vorgeschlagenen Einträge, stellt Fragen zur Klärung und nimmt Schätzungen vor.
  • Gemeinsam legen das Team und der Product Owner fest, welche Aufgaben in den Sprint Backlog aufgenommen werden.
  • Zum Abschluss der Sitzung fasst der Scrum Master den Plan für den Sprint zusammen und stellt sicher, dass alle Beteiligten ein gemeinsames Verständnis haben.

c)

c) Berechne, wie lange es dauern würde, ein Softwareprojekt mit dem Wasserfall-Modell abzuschließen, wenn jede Phase (Anforderungsanalyse, Design, Implementierung, Testen und Wartung) jeweils 4 Wochen in Anspruch nimmt. Setze voraus, dass jede Phase ohne Verzögerung beginnt, sobald die vorherige abgeschlossen ist. Kontrastiere diese Gesamtdauer mit einem agilen Entwicklungsansatz, bei dem Sprints von 2 Wochen angesetzt werden und iterative Entwicklung stattfindet.

Lösung:

• Berechnung der Gesamtdauer im Wasserfall-Modell:

Im Wasserfall-Modell werden die Phasen sequentiell durchlaufen, und jede Phase dauert 4 Wochen. Hier ist die Berechnung der Gesamtdauer:

• Anforderungsanalyse: 4 Wochen
• Design: 4 Wochen
• Implementierung: 4 Wochen
• Testen: 4 Wochen
• Wartung: 4 Wochen

Die Gesamtdauer beträgt also:

4 + 4 + 4 + 4 + 4 = 20 Wochen

• Agiler Entwicklungsansatz:

Bei einem agilen Ansatz, insbesondere bei Scrum, werden die Entwicklungsphasen in kurzen Sprints durchgeführt. Jeder Sprint dauert in diesem Fall 2 Wochen. Iterative Entwicklungsprozesse machen es schwierig, eine exakte Gesamtdauer zu berechnen, da sich der Fortschritt während der Sprints kontinuierlich ändert und Anpassungen vorgenommen werden. Dennoch kann man ein Beispiel heranziehen:

• Angenommen, das gesamte Projekt benötigt 10 Sprints à 2 Wochen:
• Gesamtdauer: 10 Sprints × 2 Wochen = 20 Wochen

Hier ist der Vergleich beider Methoden:

• Wasserfall-Modell: 20 Wochen
• Agile Methode: Schätzungsweise 20 Wochen (je nach Anzahl der Sprints und Projektumfang kann es variieren)

Obwohl beide Ansätze in diesem Beispiel auf eine ähnliche Gesamtdauer kommen, bietet der agile Ansatz den Vorteil der flexiblen Reaktion auf Änderungen und regelmäßigen Evaluierung und Anpassung durch iterative Sprints, während der Wasserfall-Ansatz eher starr und weniger flexibel ist.

d)

d) Angenommen, ein Team entscheidet sich für die Einführung von Kanban zur Verbesserung ihrer Entwicklungsprozesse. Erläutere, wie das Team dabei vorgehen könnte, insbesondere in Bezug auf die Einrichtung von Work-in-Progress-Limits (WIP) und kontinuierliche Verbesserung. Nenne konkrete Schritte und Praktiken, die das Team anwenden sollte.

Lösung:

Einführung von Kanban zur Verbesserung der Entwicklungsprozesse: 1. Einrichtung von Work-in-Progress-Limits (WIP):

• Verständnis der aktuellen Arbeitsprozesse: Das Team analysiert ihre bisherigen Prozesse und identifiziert die verschiedenen Arbeitsphasen, die durchlaufen werden, wie z.B. „Zu erledigen“, „In Bearbeitung“ und „Fertig“.
• Einrichtung des Kanban-Boards: Das Team erstellt ein visuelles Kanban-Board mit Spalten, die die verschiedenen Arbeitsphasen darstellen. Jedes Teammitglied kann nun sehen, welche Aufgaben sich in welcher Phase befinden.
• Festlegung der WIP-Limits: Das Team legt Work-in-Progress-Limits für jede Spalte des Kanban-Boards fest. Diese Limits definieren die maximale Anzahl von Aufgaben, die sich gleichzeitig in einer bestimmten Phase befinden dürfen. Zum Beispiel könnte das WIP-Limit für „In Bearbeitung“ auf 3 festgelegt werden.
  • Realistische Limits setzen:
  • Regelmäßige Überprüfung und Anpassung der Limits:

2. Kontinuierliche Verbesserung (Kaizen):

• Regelmäßige Team-Meetings: Das Team führt regelmäßige Meetings durch, um den Fortschritt zu besprechen und Hindernisse zu identifizieren. Diese Meetings können tägliche Stand-up-Meetings („Daily Stand-ups“) oder wöchentliche Retrospektiven umfassen.
• Analyse von Engpässen: Das Team analysiert, welche Phasen des Prozesses häufig überlastet sind oder Engpässe verursachen. Diese Engpässe können durch die WIP-Limits sichtbar gemacht werden.
• Umsetzung von Verbesserungsmaßnahmen: Basierend auf der Analyse der Engpässe und der durchgeführten Retrospektiven setzt das Team konkrete Verbesserungsmaßnahmen um. Dies könnte die Anpassung der WIP-Limits, die Einführung neuer Praktiken oder die Änderung der Arbeitsabläufe beinhalten.
• Kontinuierliche Überwachung: Das Team überwacht fortlaufend die Effektivität der implementierten Maßnahmen und passt sie bei Bedarf an. Ziel ist es, den Workflow stetig zu optimieren und die Produktivität zu erhöhen.

3. Konkrete Schritte und Praktiken:

• Visualisierung: Alle Aufgaben und ihre jeweiligen Phasen werden auf dem Kanban-Board dargestellt, um eine klare Sicht auf den aktuellen Stand der Arbeiten zu haben.
• Pull-Prinzip: Teammitglieder ziehen neue Aufgaben in ihren Arbeitsbereich, sobald sie Kapazitäten frei haben, anstatt Aufgaben zugewiesen zu bekommen. Dies fördert die Selbstorganisation und Eigenverantwortung.
• Fokus auf Fertigstellung: Der Fokus liegt darauf, Aufgaben vollständig abzuschließen, bevor neue Aufgaben begonnen werden. Dies minimiert Multitasking und erhöht die Effizienz.
• Kontinuierliches Feedback: Durch regelmäßige Meetings und Reviews stellt das Team sicher, dass kontinuierlich Feedback eingeholt und umgesetzt wird.
• Flexible Anpassung: Das Team bleibt flexibel und passt die Prozesse und Praktiken kontinuierlich an, um auf neue Herausforderungen und Veränderungen reagieren zu können.

Aufgabe 2)

Du sollst ein UML-Klassendiagramm für ein einfaches Bankensystem erstellen, das die Klassen Kunde, Konto und Transaktion zeigt. Ein Kunde kann mehrere Konten haben, und jedes Konto kann mehrere Transaktionen haben. Jede Klasse sollte mindestens zwei Attribute und zwei Methoden haben. Danach sollst du ein UML-Sequenzdiagramm erstellen, das zeigt, wie ein Kunde eine neue Transaktion durchführt.

a)

Erstelle ein UML-Klassendiagramm für die Klassen Kunde, Konto und Transaktion. Achte darauf, die Attribute, Methoden und die Beziehungen zwischen den Klassen korrekt darzustellen.

Lösung:

• Klasse: Kunde
  • Attribute:
    • Name: String
    • Kunden-ID: int
  • Methoden:
    • öffentliche void erstellenKonto()
    • öffentliche void anzeigenKontoinformationen()
• Klasse: Konto
  • Attribute:
    • Kontonummer: int
    • Saldo: double
  • Methoden:
    • öffentliche void einzahlen(double betrag)
    • öffentliche void abheben(double betrag)
• Klasse: Transaktion
  • Attribute:
    • Transaktions-ID: int
    • Datum: Date
  • Methoden:
    • öffentliche void ausführen()
    • öffentliche void anzeigenDetails()

Beziehungen zwischen den Klassen:

• Kunde und Konto:
  • Ein Kunde kann mehrere Konten haben. (1:n Beziehung)
• Konto und Transaktion:
  • Ein Konto kann mehrere Transaktionen haben. (1:n Beziehung)

b)

Füge zur Klasse Kunde die Attribute name(String) und id(Integer) sowie die Methoden getName(): String und getId(): Integer hinzu. Nimm entsprechende Anpassungen an den anderen Klassen vor.

Lösung:

• Klasse: Kunde
  • Attribute:
    • name: String
    • id: Integer
  • Methoden:
    • öffentliche String getName()
    • öffentliche Integer getId()
    • öffentliche void erstellenKonto()
    • öffentliche void anzeigenKontoinformationen()
• Klasse: Konto
  • Attribute:
    • kontonummer: Integer
    • saldo: Double
  • Methoden:
    • öffentliche void einzahlen(double betrag)
    • öffentliche void abheben(double betrag)
    • öffentliche Integer getKontonummer()
    • öffentliche Double getSaldo()
• Klasse: Transaktion
  • Attribute:
    • transaktionsId: Integer
    • datum: Date
  • Methoden:
    • öffentliche void ausführen()
    • öffentliche void anzeigenDetails()
    • öffentliche Integer getTransaktionsId()
    • öffentliche Date getDatum()

Beziehungen zwischen den Klassen:

• Kunde und Konto:
  • Ein Kunde kann mehrere Konten haben. (1:n Beziehung)
• Konto und Transaktion:
  • Ein Konto kann mehrere Transaktionen haben. (1:n Beziehung)

c)

Beschreibe die Beziehungen zwischen den Klassen Kunde, Konto und Transaktion. Welche Arten von Beziehungen bestehen zwischen diesen Klassen (z.B. Assoziation, Aggregation, Komposition, Vererbung)? Begründe deine Wahl.

Lösung:

• Beziehungen zwischen den Klassen:
  • Kunde und Konto:
    • Beziehungstyp: Aggregation
    • Beschreibung: Ein Kunde kann mehrere Konten haben, aber ein Konto existiert eigenständig und kann auch ohne den Kunden existieren. Die Lebenszyklen von Kunde und Konto sind unabhängig voneinander.
  • Konto und Transaktion:
    • Beziehungstyp: Komposition
    • Beschreibung: Ein Konto kann mehrere Transaktionen haben. Eine Transaktion kann nicht existieren, ohne dass sie zu einem bestimmten Konto gehört. Hierbei ist die Lebensdauer der Transaktion an die Lebensdauer des Kontos gebunden. Wenn ein Konto gelöscht wird, werden auch alle zugehörigen Transaktionen gelöscht.

Begründung:

• Die Aggregation zwischen Kunde und Konto wurde gewählt, weil ein Konto unabhängig vom Kunden existieren kann. Der Kunde besitzt zwar das Konto, aber das Konto kann auch ohne den Kunden existieren, beispielsweise wenn das Konto einem anderen Kunden zugeordnet wird.
• Die Komposition zwischen Konto und Transaktion ist angemessen, weil Transaktionen eng mit einem bestimmten Konto verknüpft sind. Ohne ein Konto gäbe es keine Transaktionen, da diese direkt auf Kontobewegungen bezogen sind.

d)

Zeichne ein UML-Sequenzdiagramm, das den Ablauf darstellt, wenn ein Kunde eine neue Transaktion erstellt. Zeige, welche Nachrichten zwischen den Objekten der Klassen Kunde, Konto und Transaktion ausgetauscht werden.

Lösung:

• UML-Sequenzdiagramm: Erstellen einer neuen Transaktion
  • Aktionen:
    • 1. Der Kunde initiiert die Transaktion: Nachricht: Kunde -> Konto: neueTransaktion(betrag: Double)
    • 2. Konto erstellt eine neue Transaktion: Nachricht: Konto -> Transaktion: new Transaktion(betrag: Double, datum: Date)
    • 3. Transaktion wird durchgeführt: Nachricht: Transaktion -> Konto: ausführen()
    • 4. Konto aktualisiert den Saldo: Nachricht: Konto: saldo += betrag
    • 5. Konto informiert den Kunden über die erfolgreiche Transaktion: Nachricht: Konto -> Kunde: transaktionErfolgreich()
• Diagramm:
  • 

Aufgabe 3)

Anforderungserhebung und -dokumentation (Interviews, Workshops)

Der Prozess der Identifikation und Dokumentation von Anforderungen erfolgt oft mithilfe von Interviews und Workshops. Die Anforderungserhebung beinhaltet das Sammeln von Anforderungen von Stakeholdern durch Einzelgespräche (Interviews) und Gruppenarbeit (Workshops). Die Anforderungen werden schriftlich dokumentiert, um sie für spätere Phasen des Projekts verfügbar und nachvollziehbar zu machen. UML-Diagramme, Use Cases und User Stories werden genutzt, um die Anforderungen zu visualisieren. Das Ziel ist es, Klarheit, Vollständigkeit und Nachvollziehbarkeit der Anforderungen sicherzustellen.

a)

a) Erkläre den Unterschied zwischen der Anforderungserhebung mittels Interviews und Workshops. Welche Vor- und Nachteile haben beide Methoden?

Lösung:

a) Erklärung des Unterschieds zwischen der Anforderungserhebung mittels Interviews und Workshops und deren Vor- und Nachteile:

• Interviews:
• Definition: Einzelgespräche zwischen dem Anforderungsanalytiker und einem Stakeholder.
• Vorteile: • Tiefere Einblicke: Durch Einzelgespräche lassen sich detaillierte Informationen und persönliche Einblicke gewinnen. • Weniger Ablenkungen: Der Fokus kann gezielt auf den jeweiligen Stakeholder und dessen Anforderungen gelenkt werden, ohne Ablenkung durch andere Teilnehmende. • Flexibilität: Interviews können zeitlich und inhaltlich flexibel gestaltet werden, um sie an den Zeitplan und die Verfügbarkeit der Stakeholder anzupassen.
• Nachteile: • Zeitaufwändig: Einzelinterviews erfordern oft mehr Zeitaufwand als Gruppenveranstaltungen, da jeder Stakeholder separat interviewt werden muss. • Begrenzte Sichtweise: Die Informationen basieren nur auf der Perspektive des jeweiligen Stakeholders und können subjektiv sein.
• Workshops:
• Definition: Gruppenarbeitssitzungen, bei denen mehrere Stakeholder gemeinsam Anforderungen erheben und diskutieren.
• Vorteile: • Synergieeffekte: Durch die Zusammenarbeit mehrerer Stakeholder können unterschiedliche Perspektiven eingebracht und Innovationen gefördert werden. • Effizienz: Workshops ermöglichen die gleichzeitige Erhebung von Anforderungen von mehreren Stakeholdern, was zu einem effizienteren Prozess führen kann. • Konsensbildung: Gemeinsame Diskussionen und Abstimmungen können helfen, Konflikte zu lösen und einen Konsens zu erzielen.
• Nachteile: • Gruppendynamik: Starke Persönlichkeiten können die Diskussion dominieren und andere Teilnehmende unterdrücken. • Koordinationsaufwand: Die Organisation und Planung von Workshops, einschließlich Terminfindung und Moderation, können aufwendig sein. • Ablenkungspotenzial: In Gruppensituationen kann es leicht zu Ablenkungen und Abschweifungen vom eigentlichen Thema kommen.

b)

b) Beschreibe, wie du mithilfe eines Workshops die Anforderungen eines neuen Softwareprojekts erheben würdest. Erläutere die Schritte, die du unternehmen würdest, und welche Rollen du in dem Workshop sehen möchtest.

Lösung:

b) Beschreibung der Durchführung eines Workshops zur Anforderungserhebung für ein neues Softwareprojekt:

Um die Anforderungen eines neuen Softwareprojekts mithilfe eines Workshops zu erheben, gehe ich wie folgt vor:

• Schritt 1: Vorbereitung des Workshops
• Identifikation der Stakeholder: Bestimmen, welche Personen und Gruppen vom Projekt betroffen sind und wessen Anforderungen relevant sind.
• Einladung der Teilnehmenden: Die identifizierten Stakeholder zur Teilnahme am Workshop einladen. Dazu zählen z.B. Kunden, Endnutzer, Projektmanager, Entwickler, Tester, Business-Analysten, und ggf. Vertreter des Managements.
• Festlegung der Ziele und Agenda: Klare Ziele für den Workshop festlegen und eine detaillierte Agenda erstellen, die den zeitlichen Ablauf und die Themen für den Workshop umfasst.
• Logistik und Ressourcen: Sicherstellen, dass alle notwendigen logistischen Aspekte (z.B. Ort, Technik, Verpflegung) organisiert sind und alle benötigten Materialien (Whiteboards, Notizblöcke, Präsentationsmittel) bereitstehen.
• Schritt 2: Durchführung des Workshops
• Begrüßung und Einführung: Den Workshop eröffnen, alle Teilnehmenden begrüßen und die Ziele und die Agenda vorstellen. Die Rollenverteilung und die Regeln für die Zusammenarbeit im Workshop klären.
• Anforderungsfindung und -erhebung: Mithilfe von Brainstorming, Diskussionen und moderierten Sitzungen die Anforderungen der Stakeholder erheben. Methoden wie SWOT-Analysen, Use Cases, User Stories oder Personas können hierbei hilfreich sein.
• Dokumentation: Alle besprochenen Anforderungen detailliert protokollieren und visualisieren. Tools wie UML-Diagramme oder Mindmaps können genutzt werden, um die Anforderungen zu strukturieren und verständlich darzustellen.
• Priorisierung der Anforderungen: Die gesammelten Anforderungen gemeinsam priorisieren. Hier können Techniken wie das MoSCoW-Verfahren (Must have, Should have, Could have, Won't have) Anwendung finden.
• Ergebnispräsentation: Die erarbeiteten und priorisierten Anforderungen zusammenfassen und den Teilnehmenden präsentieren. Rückmeldung und Anpassungswünsche aufnehmen.
• Schritt 3: Nachbereitung des Workshops
• Dokumentation aufbereiten: Die gesammelten Anforderungen in einem detaillierten Dokument zusammenfassen und für alle Stakeholder zugänglich machen.
• Review und Feedback: Den Workshop und die Ergebnisse mit den Teilnehmenden besprechen, Feedback einholen und eventuelle Verbesserungen oder Ergänzungen berücksichtigen.
• Planung der nächsten Schritte: Basierend auf den Ergebnissen des Workshops die nächsten Schritte im Anforderungsmanagement und im Projekt planen und entsprechende Maßnahmen einleiten.

Rollen im Workshop:

• Moderator: Leitet den Workshop, sorgt für einen strukturierten Ablauf und fördert die Diskussion.
• Protokollführer: Dokumentiert alle besprochenen Anforderungen und Ergebnisse.
• Stakeholder/Teilnehmende: Kunden, Endnutzer, Entwickler, Tester, Projektmanager, Business-Analysten und Managementvertreter, die ihre Anforderungen und Meinungen einbringen.
• Technischer Experte: Unterstützt bei technischen Fragen und hilft bei der Machbarkeitsbewertung der Anforderungen.

c)

c) Angenommen, du hast mehrere Anforderungen der Stakeholder gesammelt. Erläutere, wie du diese Anforderungen dokumentieren würdest. Nutze dabei UML-Diagramme, Use Cases und User Stories als Beispiele.

Lösung:

c) Erläuterung der Dokumentation von Anforderungen mithilfe von UML-Diagrammen, Use Cases und User Stories:

Nachdem die Anforderungen der Stakeholder gesammelt wurden, müssen diese klar, vollständig und nachvollziehbar dokumentiert werden. Hier sind drei gängige Methoden, um dies zu erreichen:

• 1. UML-Diagramme:
• Verwendung: UML-Diagramme (Unified Modeling Language) helfen dabei, die Anforderungen visuell darzustellen und die Struktur und das Verhalten des Systems zu modellieren.
• Beispiele:
  • Anwendungsfalldiagramm (Use Case Diagram): Zeigt die Interaktionen zwischen verschiedenen Akteuren (z.B. Benutzerrollen) und dem System. Dies hilft, alle Funktionen des Systems aufzuzeigen.
  • Aktivitätsdiagramm (Activity Diagram): Visualisiert den Workflow und die Prozessabläufe im System. Es zeigt, in welcher Reihenfolge die Aktivitäten durchgeführt werden und wie sie miteinander verbunden sind.
  • Klassendiagramm (Class Diagram): Stellt die Klassen im System sowie deren Attribute und Methoden dar. Es zeigt auch die Beziehungen zwischen den Klassen.
• 2. Use Cases (Anwendungsfälle):
• Verwendung: Ein Use Case beschreibt eine konkrete Interaktion zwischen einem Benutzer (Akteur) und dem System, um ein bestimmtes Ziel zu erreichen.
• Beispiele:
  • Kurzer Überblick: Jeder Use Case wird mit einem kurzen prägnanten Titel versehen (z.B. „Benutzerregistrierung“).
  • Beschreibung: Der Use Case beschreibt, wie der Benutzer mit dem System interagiert. Dies kann in Form eines Szenarios oder eines Flussdiagramms erfolgen. Z.B.:
    • Aktion 1: Der Benutzer öffnet das Registrierungsformular.
    • Aktion 2: Der Benutzer gibt seine Daten ein.
    • Aktion 3: Das System überprüft die Daten auf Validität.
    • Aktion 4: Bei erfolgreicher Überprüfung wird der Benutzer im System registriert.
  • Akteure: Identifikation der Akteure (z.B. „Neuer Benutzer“, „Administrator“).
  • Vorbedingungen: Bedingungen, die erfüllt sein müssen, bevor der Use Case ausgeführt werden kann (z.B. „Der Benutzer muss Zugang zur Registrierung haben“).
  • Nachbedingungen: Das erwartete Ergebnis nach der Ausführung des Use Cases (z.B. „Der Benutzer ist erfolgreich registriert und erhält eine Bestätigungs-E-Mail“).
• 3. User Stories:
• Verwendung: User Stories sind kurze, einfache Beschreibungen einer Funktion oder einer Eigenschaft aus der Sicht des Endbenutzers. Sie helfen, die Bedürfnisse des Benutzers in den Mittelpunkt zu stellen.
• Struktur:
  • Form: Eine typische User Story folgt oft dem Format: “Als [Rolle] möchte ich [Funktion], um [Nutzen] zu erreichen.”
  • Beispiel: “Als neuer Benutzer möchte ich mich registrieren, um Zugang zu den erweiterten Funktionen der Website zu erhalten.”
  • Akzeptanzkriterien: Definition der Bedingungen, die erfüllt werden müssen, damit die User Story als abgeschlossen gilt (z.B. „Ein neuer Benutzer kann sich erfolgreich registrieren und erhält eine Bestätigungs-E-Mail“).

Durch die Nutzung dieser Methoden kann eine vollständige und nachvollziehbare Dokumentation der Anforderungen sichergestellt werden. UML-Diagramme bieten eine visuelle Darstellung, Use Cases detaillieren die Interaktionen und User Stories stellen die Benutzerperspektive und den Nutzen in den Vordergrund.

d)

d) In einem Gespräch mit einem Stakeholder wurde klar, dass eine spezielle Anforderung unklar formuliert ist. Wie würdest du vorgehen, um diese Anforderung zu präzisieren und Missverständnisse zu vermeiden?

Lösung:

d) Vorgehen zur Präzisierung einer unklar formulierten Anforderung und zur Vermeidung von Missverständnissen:

Es ist wichtig, dass Anforderungen klar und präzise formuliert sind, um Missverständnisse zu vermeiden und die erfolgreiche Umsetzung des Projekts zu gewährleisten. Hier ist ein Schritt-für-Schritt-Vorgehen, um eine unklare Anforderung zu präzisieren:

• Schritt 1: Klärendes Gespräch führen
• Stakeholder erneut kontaktieren: Ein weiteres Gespräch mit dem betreffenden Stakeholder vereinbaren, um die unklare Anforderung zu besprechen.
• Konkretisierende Fragen stellen: Offene Fragen stellen, um mehr Details und Klarheit zu bekommen. Zum Beispiel:
  • „Können Sie bitte genauer erklären, was Sie mit dieser Anforderung meinen?“
  • „Welche spezifischen Ziele sollen durch diese Anforderung erreicht werden?“
  • „Gibt es Beispiele oder Szenarien, die Ihre Anforderung veranschaulichen könnten?“
• Schritt 2: Anforderungen neu formulieren
• Ergebnissammlung: Notizen aus dem Gespräch sammeln und die gesammelten Informationen analysieren.
• Erneute Formulierung: Die Anforderung präzisieren und klar formulieren, basierend auf den zusätzlichen Informationen vom Stakeholder.
• Rückkopplung: Die neu formulierte Anforderung dem Stakeholder zur Überprüfung und Bestätigung vorlegen, um sicherzustellen, dass sie korrekt verstanden und vollständig ist.
• Schritt 3: Dokumentation aktualisieren
• Anforderungsdokument updaten: Die präzisierte Anforderung in den offiziellen Anforderungsdokumenten aktualisieren, z.B. in den UML-Diagrammen, Use Cases oder User Stories.
• Kommunikation: Alle relevanten Projektbeteiligten über die aktualisierte Anforderung informieren, um sicherzustellen, dass alle auf dem gleichen Stand sind.
• Schritt 4: Klare Akzeptanzkriterien festlegen
• Definition: Akzeptanzkriterien für die präzisierte Anforderung definieren, um klarzustellen, unter welchen Bedingungen die Anforderung als erfüllt gilt.
• Beispiel: Wenn die ursprüngliche Anforderung lautete „Das System soll benutzerfreundlich sein“, könnte eine präzisierte Formulierung und Akzeptanzkriterien lauten: „Das System soll eine intuitive Nutzeroberfläche haben, die es neuen Benutzern ermöglicht, eine Registrierung innerhalb von maximal 5 Minuten ohne externe Hilfestellung abzuschließen.“

Durch diese Schritte wird sichergestellt, dass die Anforderung klar und vollständig ist, wodurch Missverständnisse vermieden und die Grundlage für eine erfolgreiche Umsetzung geschaffen wird.

Aufgabe 4)

Design Patterns (Singleton, Factory, Observer)Design Patterns sind wiederverwendbare Lösungen für häufig auftretende Probleme beim Softwareentwurf. Sie helfen dabei, bewährte, flexible und erweiterbare Softwarearchitekturen zu erstellen.

• Singleton: Stellt sicher, dass eine Klasse nur eine Instanz hat und bietet einen globalen Zugangspunkt zu dieser Instanz.
• Factory Method: Definiert eine Schnittstelle zur Erzeugung eines Objekts, lässt aber Unterklassen entscheiden, welche Klasse instanziiert wird.
• Observer: Ermöglicht es einem Subjekt, eine Liste von abhängigen Objekten zu pflegen und sie automatisch zu benachrichtigen, wenn sich sein Zustand ändert.

a)

Teilaufgabe 1:Erkläre den Singleton-Design-Pattern und beschreibe ein Szenario, in dem der Einsatz dieses Musters sinnvoll wäre. Implementiere danach ein einfaches Singleton-Muster in Java.

Lösung:

Teilaufgabe 1:\rErkläre den Singleton-Design-Pattern und beschreibe ein Szenario, in dem der Einsatz dieses Musters sinnvoll wäre. Implementiere danach ein einfaches Singleton-Muster in Java.\r\rSingleton-Design-Pattern:\r

\r
• Der Singleton-Design-Pattern stellt sicher, dass eine Klasse nur eine Instanz hat und bietet einen globalen Zugriffspunkt auf diese Instanz.
\r
• Dieses Pattern wird oft verwendet, wenn genau eine Instanz einer Klasse benötigt wird, um eine zentrale Steuerung über eine Ressource bereitzustellen oder um bestimmte Zustände in einer Anwendung zu verwalten.
\r

\r\rSzenario:\rEin typisches Beispiel für den Einsatz des Singleton-Patterns ist ein Logger, der in einer Anwendung verwendet wird. Es macht Sinn, nur eine Instanz des Loggers zu haben, um die Protokollierung einheitlich und kontrolliert zu gestalten. Ein weiteres Beispiel wäre eine Konfigurationsklasse, die Einstellungen für eine Anwendung hält und sicherstellt, dass alle Teile der Anwendung auf dieselben Konfigurationen zugreifen.\r\rImplementierung eines einfachen Singleton-Musters in Java:\r

\rpublic class Singleton {\r    // Eine statische Variable, die die einzige Instanz der Klasse hält\r    private static Singleton instance;\r\r    // Privater Konstruktor, um zu verhindern, dass andere Klassen Instanzen erstellen\r    private Singleton() {}\r\r    // Öffentliche statische Methode, die die einzige Instanz zurückgibt\r    public static Singleton getInstance() {\r        if (instance == null) {\r            synchronized (Singleton.class) {\r                if (instance == null) {\r                    instance = new Singleton();\r                }\r            }\r        }\r        return instance;\r    }\r}\r

\r

\r
• Erklärung: Der Singleton ist über einen privaten Konstruktor geschützt, sodass keine Instanzen direkt erstellt werden können.
\r
• Die einzige Instanz der Klasse wird über eine statische Methode getInstance() bereitgestellt, die den globalen Zugangspunkt darstellt.
\r
• Die Variable instance wird bei Bedarf initialisiert (Lazy Initialization) und durch synchronized wird sichergestellt, dass die Instanz in einem Multithreading-Umgebung einmalig erstellt wird.
\r

\r

b)

Teilaufgabe 2:Erkläre den Factory Method-Design-Pattern und seine Vorteile. Implementiere eine Factory Method in Python, die Objekte der Klassen Circle und Square erstellt. Beschreibe auch, welche Rolle Polymorphismus in diesem Design-Pattern spielt.

Lösung:

Teilaufgabe 2:\rErkläre den Factory Method-Design-Pattern und seine Vorteile. Implementiere eine Factory Method in Python, die Objekte der Klassen Circle und Square erstellt. Beschreibe auch, welche Rolle Polymorphismus in diesem Design-Pattern spielt.\r\rFactory Method-Design-Pattern:\r

\r
• Der Factory Method-Design-Pattern definiert eine Schnittstelle zur Erstellung von Objekten, lässt jedoch die Unterklassen entscheiden, welche Klasse instanziiert wird. Dies ermöglicht es, den Code flexibel und erweiterbar zu gestalten, ohne die Codebasis ändern zu müssen.
\r
• Statt direkt Objekte zu instanziieren, werden diese durch eine Fabrikmethode erstellt. Dadurch kann die genaue Klasse der zu erstellenden Objekte zur Laufzeit bestimmt werden.
\r

\rVorteile:\r

\r
• Flexibilität: Der Factory Method-Pattern ermöglicht es, die Instanziierung von Objekten zu kapseln und zu zentralisieren. Dadurch kann der gleiche Code verwendet werden, um unterschiedliche Arten von Objekten zu erstellen.
\r
• Erweiterbarkeit: Neue Klassen können einfach hinzugefügt werden, ohne den bestehenden Code zu ändern. Es müssen lediglich neue Unterklassen erstellt werden, die die Factory Method implementieren.
\r
• Wartbarkeit: Der Code ist leichter zu warten und zu verstehen, da die Objektinstanziierung klar getrennt vom restlichen Code ist.
\r
• Polymorphismus: Durch die Verwendung von Polymorphismus können unterschiedliche Objektarten durch die gleiche Schnittstelle implementiert werden. Dies ermöglicht es, dass der Code, der die Objekte verwendet, sich nicht ändern muss, wenn neue Objektarten hinzugefügt werden.
\r

\r\rImplementierung einer Factory Method in Python:

\rfrom abc import ABC, abstractmethod\r\rclass Shape(ABC):\r    @abstractmethod\r    def draw(self):\r        pass\r\rclass Circle(Shape):\r    def draw(self):\r        return 'Drawing a Circle'\r\rclass Square(Shape):\r    def draw(self):\r        return 'Drawing a Square'\r\rclass ShapeFactory(ABC):\r    @abstractmethod\r    def create_shape(self):\r        pass\r\rclass CircleFactory(ShapeFactory):\r    def create_shape(self):\r        return Circle()\r\rclass SquareFactory(ShapeFactory):\r    def create_shape(self):\r        return Square()\r\r# Verwendung der Factory Method\rcircle_factory = CircleFactory()\rcircle = circle_factory.create_shape()\rprint(circle.draw())\r\rsquare_factory = SquareFactory()\rsquare = square_factory.create_shape()\rprint(square.draw())\r

\r\rRolle des Polymorphismus:\r

\r
• Polymorphismus spielt eine zentrale Rolle im Factory Method-Pattern, da er es ermöglicht, Objekte unterschiedlicher Klassen durch die gleiche Schnittstelle zu verwalten.
\r
• Durch die Verwendung der abstrakten Klasse Shape und der Methode draw können Circle und Square auf dieselbe Weise behandelt werden, obwohl sie unterschiedliche Implementierungen der draw-Methode haben.
\r
• Der Code, der die Objekte verwendet, muss sich nicht ändern, wenn neue Formen (z. B. Triangle) hinzugefügt werden. Es reicht aus, eine neue Fabrikmethode zu erstellen, die die neue Form erzeugt.
\r

\r

d)

Teilaufgabe 4:Angenommen, Du hast ein komplexes System, in dem die design patterns Singleton, Factory Method und Observer kombiniert werden müssen. Beschreibe eine Situation, wie diese drei Patterns zusammen verwendet werden können. Zeichne danach ein UML-Diagramm, um die Beziehungen zwischen diesen Patterns in Deinem entworfenen System zu verdeutlichen.

Lösung:

Teilaufgabe 4:\rAngenommen, Du hast ein komplexes System, in dem die Design Patterns Singleton, Factory Method und Observer kombiniert werden müssen. Beschreibe eine Situation, wie diese drei Patterns zusammen verwendet werden können. Zeichne danach ein UML-Diagramm, um die Beziehungen zwischen diesen Patterns in Deinem entworfenen System zu verdeutlichen.\r\rSzenario:\rStell Dir ein komplexes System zur Überwachung und Steuerung einer Smart-Home-Anlage vor. Dieses System besteht aus verschiedenen Komponenten wie Sensoren, Aktoren und einem zentralen Controller.\r\r

\r
• Singleton: Der Controller in diesem System sollte als Singleton implementiert werden, um sicherzustellen, dass es nur eine zentrale Instanz gibt, die die Smart-Home-Anlage steuert und die Kommunikation zwischen den Komponenten koordiniert.
\r\r
• Factory Method: Die verschiedenen Sensoren und Aktoren in der Smart-Home-Anlage können mithilfe der Factory Method erstellt werden. Dies ermöglicht eine einfache Erweiterung des Systems, indem neue Gerätetypen hinzugefügt werden, ohne den bestehenden Code zu verändern.
\r\r
• Observer: Die Sensoren können den Observer-Pattern verwenden, um den Controller über Zustandsänderungen (z.B. Temperaturänderung, Bewegungserkennung) zu benachrichtigen. Der Controller kann dann entsprechende Aktionen koordinieren, wie z.B. das Einschalten der Heizung oder das Aktivieren der Alarmanlage.
\r

\r\rBeschreibung des Zusammenspiels der Patterns:\r

\r
• Der Controller ist eine Singleton-Klasse, die als zentraler Punkt zur Steuerung des Systems fungiert.
\r
• Ein SensorFactory und ein AktuatorFactory sind Factory Method-Klassen, die verschiedene Sensoren und Aktoren erstellen.
\r
• Die einzelnen Sensoren implementieren den Observer-Pattern, um den Controller zu benachrichtigen, wenn sich ihr Zustand ändert.
\r
• Der Controller registriert sich selbst als Observer bei den Sensoren, um Benachrichtigungen zu erhalten.
\r

\r\rUML-Diagramm:\rIm UML-Diagramm werden die Beziehungen zwischen den Klassen und Interfaces dargestellt. Die Hauptakteure sind Controller, SensorFactory, AktuatorFactory, Sensor (abstract), konkrete Sensor-Klassen, Aktor (abstract) und konkrete Aktor-Klassen.\r\rHinweis: Aufgrund der textbasierten Natur dieser Antwort kann ich kein UML-Diagramm zeichnen, aber ich werde die Struktur beschreiben, sodass Du es leicht visualisieren kannst.\r\r

\r
• Controller (Singleton)\r - Methoden: getInstance(), update()\r
\r
• SensorFactory (Factory Method)\r - Methode: createSensor()\r
\r
• AktuatorFactory (Factory Method)\r - Methode: createAktuator()\r
\r
• Sensor (abstract, Observer)\r - Methode: attach(), detach(), notify(), getState()\r
\r
• ConcreteSensorA (konkrete Implementierung von Sensor)\r - Methode: getState()\r
\r
• ConcreteSensorB (konkrete Implementierung von Sensor)\r - Methode: getState()\r
\r
• Aktor (abstract)\r - Methoden: performAction()\r
\r
• ConcreteAktuatorA (konkrete Implementierung von Aktor)\r - Methoden: performAction()\r
\r
• ConcreteAktuatorB (konkrete Implementierung von Aktor)\r - Methoden: performAction()\r
\r

\r\rInnerhalb des UML-Diagramms:\r

\r
• Die Klasse Controller wird als Singleton dargestellt und kommuniziert direkt mit den Factories und Sensoren.
\r
• SensorFactory und AktuatorFactory sind Factory Method-Klassen, die die abstrakte Methode zur Erstellung von Sensoren bzw. Aktoren erweitern.
\r
• Sensor und Aktor sind abstrakte Basisklassen, die von konkreten Implementierungen erweitert werden.
\r
• Der Controller implementiert Observer und registriert sich bei Sensoren, um Benachrichtigungen zu erhalten und die Aktoren zu steuern.
\r

\r