12
Softwaretechnik SoSe 2016 (Fach) / Übungen 1-6 (Lektion)
Anzeige
- 1 Beschreibung von Anforderungen Am Anfang eines jeden Software-Projekts steht eine Beschreibung der aktuellen IST-Situation sowie der Kundenanforderungen an das zu entwickelnde System. Für die Beschreibung der IST-Situation werden häufig Szenarien verwendet. Sie beschreiben aus einer fachlichen Sichtweise die gegenwärtigen Arbeitssituationen und die Arbeitsweise der zukünftigen Anwender, wobei sie sich auf die wesentlichen Aufgaben und den sog. „Happy Path“ konzentrieren, der die vielseitigen Spezialfälle zunächst ignoriert.
- 1 Welche Arten von Szenarien gibt es? 1. Szenarien mit komplett verschiedenen Arbeitsabläufen2. Szenarien mit ähnlichen Abläufen aber leicht unterschiedlichen Zwischenschritten3. Szenarien mit gleichen Abläufen aber jeweils anderen Daten (Personen,Eingaben, Ausgaben)Szenarien, insbesondere solche vom Typ 2 oder 3, eignen sich aufgrund ihrer Vielfältigkeitnicht zur Spezifikation von Software-Systemen. Deshalb werden Szenarien zu Use Cases abstrahiert.
- 1 Use Cases und Akteure Use Cases und AkteureEin Use Case ist eine allgemeine, informale Beschreibung mehrerer Szenarien, die ähnliche oder gleiche Abläufe aufweisen. Die an einem Use Case beteiligten Personen (oder externen Systeme) nennt man Akteure, wobei auch hier eine Verallgemeinerung stattfindet. Akteur im obigen Szenario wäre also nicht die Studentin „Karin“ sondern lediglich „Student“ oder noch allgemeiner „Bibliotheksbenutzer“. Die Beschreibung von Use Cases folgt einem vorgegebenen Format.
- 1 Use-Case-Diagramme Große Software-Systeme bestehen auseiner Vielzahl von Use Cases. Um denÜberblick zu erleichtern, erstellt man einUse-Case-Diagramm, das alle an den UseCases beteiligten Akteure sowie die Namender Use Cases darstellt.
- 1 Der Glossar Während der Beschreibung der Anforderungen ist es sinnvoll, ein Glossar mit Definitionenund Erläuterungen zu den wichtigsten, in den Use-Case-Beschreibungen verwendetenBegriffen aufzustellen. Solch ein Glossar hilft allen Projektbeteiligten beim Verstehen derUse Cases und vermeidet von Anfang an Missverständnisse der Art: „Ich meinte damit abereigentlich...“
- 1 Wie finde ich Use Cases? Szenarien und Use Cases fallen nicht vom Himmel sondern sind Schritt-für-Schritt zuermitteln. Hierfür empfiehlt sich die folgende Vorgehensweise:1. Stellen Sie eine Reihe von Szenarien auf. Diese entstehen zumeist inZusammenarbeit mit Ihrem Auftraggeber und/oder den Benutzern des jetzigenSystems. Eine gute Quelle für Szenarien sind typische Arbeitsabläufe, auch mitexistierenden Systemen.2. Identifizieren Sie die an den Szenarien beteiligten Akteure.3. Gruppieren Sie gleiche und ähnliche Szenarien.4. Leiten Sie aus den Szenariogruppen die Use-Case-Beschreibungen ab.Verwenden Sie für die Formulierung das vorgestellte Schema.5. Ergänzen Sie fortlaufend das Use-Case-Diagramm des Systems.6. Pflegen Sie, während Sie die Use Cases beschreiben, das Glossar.Bedenken Sie: Use Cases gelingen selten im ersten Wurf, sondern müssen durchDiskussion mit dem Auftraggeber immer weiter verfeinert werden.
- 2 Wann sind Aktivitäten für Use Cases notwendig? Ihr Berater empfiehlt Ihnen den Einsatz von Aktivitäten, um Abläufe detailliert zu modellieren. Dies ist normalerweise nicht für jeden Use Case notwendig. Häufig genügt die Use-Case-Beschreibung bereits, um die Abläufe im System zu verstehen. Für komplexere Use Cases mit bspw. vielen Varianten und/oder Ausnahmen ist eine weitere Detaillierung jedoch sinn-voll.
- 2 Wie erstelle ich eine Aktivität? Eine Aktivität kann schnell sehr umfangreich werden. Um nicht den Überblick zu verlieren,bietet sich folgendes Vorgehen an:1. StandardverhaltenZerlegen Sie das in den Use Cases beschriebene Standardverhalten in einzelneSchritte (Aktionen). Stellen Sie deren Ablauf in einer Aktivität dar. Der Normalfallbildet häufig nur eine sequentielle Abfolge von Aktionen.2. Varianten, Ausnahmen, AbbrücheNehmen Sie als nächstes die Sonderfälle und Ausnahmen hinzu. Spätestens hierwerden Entscheidungspunkte notwendig sein.3. VerantwortlichkeitenStellen Sie sich die Frage: Wer wird die Aktionen später durchführen? ZeichnenSie Verantwortungsbereiche, sog. Partitionen, in die Aktivität ein.4. DatenflussWelche Daten benötigt der beschriebene Ablauf? Woher bekommt er sie? Welcheerzeugt oder verändert er vielleicht? Fügen Sie den Datenfluss in Form von Objektknotenoder Pins in das Diagramm ein.5. Weitere Detaillierung: Verschachtelte AktivitätenWelche Aktionen müssen weiter detailliert werden, um das Verhalten ausreichendzu beschreiben? Markieren Sie diese Aktionen mit dem Gabelsymbol und erstellenSie Unteraktivitäten.
- 3 Was ist ein Mock-up (grundsätzlich)? Ein Mock-up ist eine skizzenhafte Nachbildung einer grafischen Oberfläche, mit dessen Hilfe der interaktive Umgang mit einer (noch nicht vorhandenen) Software veranschaulicht werden kann. Mock-ups können aus verschiedenen Materialien erstellt werden wie z. B. Papier, PowerPoint-Folien oder mit speziellen Programmen.Mock-ups aus Papier werden auch als „Papier-Prototyp“ bezeichnet. Sie haben den Vorteil, dass sie sehr schnell und kostengünstig erstellt und Änderungen im Gespräch mit potentiellen Anwendern direkt übernommen werden können.Ein Mock-up dient vor allem als Diskussionsgrundlage mit den zukünftigen Anwendern und soll nicht perfekt sein. Gerade bei sehr gut ausgearbeiteten Mock-ups reagieren Anwender eher zurückhaltend mit Änderungsvorschlägen, da die Oberfläche schon sehr „fertig“ aussieht.Für den interaktiven Umgang mit einem Mock-up können diese Papier-Buttons, Drop-Down-Menüs aus Post-it’s und ähnliches enthalten.
- 3 Warum dürfen Anweisungen für Mock-Up-Benutzer nicht zu genau sein? Versuchen Sie die Beschreibung des Gesamtablaufs verständlich und eindeutig zuformulieren. Sie darf allerdings nicht zu genau sein, z. B. „Der Nutzer drückt zum Abbrechenauf den Knopf unten rechts.“ Denn dadurch kann nicht mehr überprüft werden, ob ein Nutzer in der Lage ist, die gestellte Aufgabe mit seinem Verständnis des Mock-ups zu erledigen.
- Anzeige
- 3 Allgemeine Kritik zum Beispiel der SE2-Mediathek Die Aufteilung der Anzeige ist in allen 4 Teilanwendungen gleich strukturiert. Da dieAnwendung einfach (gehalten) ist, ist sie übersichtlich. Die Mediathek verfügt über keineKundenverwaltung(s-GUI) zur Erweiterung / Änderung der Kundendaten Eine Hilfefunktionfehlt; sinnvoll ist vielleicht die Angabe der durchzuführenden Schritte (Hinweistext rechtsoben). Die feste Struktur ermöglicht keine Individualisierung. Da die Anwendung einfach ist,kann „By Doing“ gelernt werden.
- 4 Das Beobachtermuster kennt verschiedene Umsetzungsarten (3) • Push Notification: Jedes Mal wenn sich das beobachtete Objekt ändert, werden alleBeobachter benachrichtigt. Es werden jedoch keine Daten mitgeschickt, weshalb dieseForm besonders schnell ist.• Push-Update Notification: Jedes Mal wenn sich das beobachtete Objekt ändert, werdenalle Beobachter benachrichtigt. Zusätzlich kann das beobachtete Objekt die Update-Daten, die die Änderungen beschreiben, an die Beobachter weiterleiten.• Pull Notification: Der Beobachter fragt selbstständig nach dem Zustand des beobachtetenObjekts nach. 4:01