Software - Engineering 1 <--- ---> Softwareengeneering

Zusammenfassung

Inhaltsverzeichnis

1       Software-Engineering....................................................................................................................................................... 3
1.1        Phasen der SW-Entwicklung.................................................................................................................................. 3
1.2        OO SW-Entwicklung................................................................................................................................................ 3

2       Anforderungsanalyse (AA)............................................................................................................................................ 4
2.1        Ziel und Zweck......................................................................................................................................................... 4
2.2        Qualitätsmerkmale.................................................................................................................................................... 4
2.3        Inhalt.......................................................................................................................................................................... 5
2.4        Qualitätsmerkmale von Software............................................................................................................................ 5
2.5        Schlüsselmechanismen (use cases)....................................................................................................................... 5
2.5.1          Use Case Modell............................................................................................................................................. 6
2.5.2          Beschreibung eines Use Cases..................................................................................................................... 6

3       Domain Analyse (DA)...................................................................................................................................................... 7
3.1        Konzepte finden....................................................................................................................................................... 7
3.2        Attribute definieren.................................................................................................................................................. 7
3.3        Beziehungen finden................................................................................................................................................. 7
3.3.1          Assoziation...................................................................................................................................................... 7
3.3.2          Vererbung definieren...................................................................................................................................... 8
Transaction Pattern............................................................................................................................................................... 8

4       Systemverhalten................................................................................................................................................................ 9
4.1        Systemereignisse und Systemoperationen.......................................................................................................... 9
4.2        Sequenzdiagramme................................................................................................................................................... 9
4.3        Verträge...................................................................................................................................................................... 9

5       UML.................................................................................................................................................................................. 10
5.1        Collaboration Diagrams......................................................................................................................................... 10
5.1.1          Return Value und Iteration (mit Grenzen).................................................................................................. 10
5.1.2          Conditional Messages.................................................................................................................................. 10
5.1.3          Messages to Multiobjects........................................................................................................................... 10

1          Software-Engineering

Software-Engineering ist die Anwendung eines systematischen, disziplinierten und messbaren Verahrens in der Entwicklung, dem Betrieb und der Wartung von Software, d.h. Software-Engineering ist die Anwendung von Engineering auf Software.

Gründe für ein Modell:
- Modelle sind Kommunikationsmittel!
- Ein Modell hilft, Fehler und Lücken in den Anforderungen zu finden! Je später im Entwicklungsprozess ein Fehler gefunden wird, desto teurer.

Eigenschaften von Modellen:
- Ein Bild sagt mehr als tausend Worte. Grafiken vermitteln schnell eine Übersicht.
- Modelle erlauben, ein System in Teile zu gliedern (Überblick)
- Modelle verwenden Regeln. (Syntaxregeln, Semantische Regeln)

1.1        Phasen der SW-Entwicklung

·         Analyse: Anforderungsspezifikation, Projektplan
·         Systementwurf: Systementwurfsbeschreibung
·         Detailentwurf: Detailentwurfsbeschreibung
·         Implementation: Ausgetestete und dokumentierte Komponenten bzw. Subsysteme
·         Integration, Systemtest: Verifiziertes und validiertes Softwareprodukt
·         Wartung: Betriebsfähiges Softwareprodukt

1.2        OO SW-Entwicklung

OO SW-Entwicklung: es gibt nur ein Modell. Entwicklungsvorgehen nicht sequentiell, sondern iterativ. Das iterative Vorgehen ermöglicht, folgende Aspekte früh zu beurteilen:

- Eignung des Entwurfs.                                                          - Identifikation von Risikobereichen.
- Akzeptanz beim Kunden                                                       - Gültigkeit von Aufwandabschätzungen und Terminen

2          Anforderungsanalyse (AA)

2.1        Ziel und Zweck

Ziel:                                                      Die AS legt die Anforderungen an das System so fest, dass sie als Vereinbarung zwischen Auftraggeber und SW-Ersteller dienen können.

Ergebnisse:                                                         - Anforderungsspezifikation (AS) mit Schlüsselmechanismen
- (vorläufiger) Projektplan

Eigenschaften der AS:                      Anforderungen sollen nur festlegen, was für Eigenschaften das Produkt haben soll und nicht, wie diese Eigenschaften realisiert werden. Um das Was auszudrücken sind Black-Box-Beschreibungen geeignet. Bei komplexen Zusammenhängen ist eine White-Box sinnvoll.

2.2        Qualitätsmerkmale

Korrektheit

·         Jede Anforderung ist eine Anforderung die mit der Software erfüllt wird.

Eindeutigkeit

·         Jede Anforderung hat nur eine Interpretation (Problem mit natürlicher Sprache)
·         Begriffsdefinitionen, Glossar wichtig

Vollständigkeit

·         Nicht nur funktionale Anforderungen
·         Verhalten in allen möglichen Situationen (z.B. unzulässige Eingabedaten)
·         Struktur nach Norm mit durchgehender Numerierung (auch Figuren, etc.)

Konsistenz

·         Nicht verschiedene Begriffe für gleiche Objekte, Sachverhalte
·         Keine widersprechende Anforderungen
·         Mit Gewichtung versehen, bez. Wichtigkeit/Stabilität
·         Wichtigkeit: Muss- / Soll- / Wunschanforderungen
·         Stabilität: Erwartete Änderungen

Überprüfbarkeit

·         Jede Anforderung überprüfbar (z.B. nicht einfach “benutzerfreundlich“)
·         Keine schwammigen Formulierungen (wie z.B. “normalerweise“)
·         Keine Anforderungen wie “fehlerfrei“ (lässt sich nicht nachprüfen)

Änderbarkeit

·         Struktur, Inhaltsverzeichnis, Glossar, Querverweise
·         Vorsicht mit Redundanz (Querverweis).
·         Leistungsfähiges Dokumentationswerkzeug und Verfahren.

Verfolgbarkeit

·         Jede Anforderung muss eindeutig referenzierbar sein
·         Rückverfolgbarkeit auf Quelle jeder Anf.
·         Vorwärts-Verfolgbarkeit zur Realisierung jeder Anforderung

2.3        Inhalt

2.4        Qualitätsmerkmale von Software

·         Funktionalität:                 Angemessenheit, Richtigkeit, Interoperabilität, Ordnungsmässigkeit, Sicherheit

·         Zuverlässigkeit:              Reife, Fehlertoleranz, Wiederherstellbarkeit

·         Benutzbarkeit:                 Verständlichkeit, Erlernbarkeit, Bedinbarkeit

·         Effizienz:                           Zeitverhalten, Verbrauchsverhalten

·         Änderbarkeit:                  Analysierbarkeit, Modifizierbarkeit, Stabilität, Prüfbarkeit

·         Übertragbarkeit:              Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit

2.5        Schlüsselmechanismen (use cases)

Eine verhaltensmässig zusammenhängende Folge von Transaktionen (transaction), die von einem System angeboten werden und einem Aktor (actor) einen messbaren Nutzen bringen.

Aktor:                 Eine Rolle (oder eine Menge von Rollen), die jemand oder etwas in der Umgebung des Systems in Zusammenhang mit dem System spielt. Ein Aktor liegt ausserhalb des zu beschreibenden Systems.

Transaktion:     Eine Folge von Aktionen, die entweder als Ganzes oder gar nicht durchgeführt werden. Eine Transaktion wird durch ein Ereignis gestartet. Ein Ereignis wird durch einen Aktor oder durch das Erreichen eines Zeitpunktes ausgelöst.

2.5.1          Use Case Modell

Das Use Case Modell besteht aus: Aktor, Use Case, Zusammenhang zwischen Aktor und Use Case, Beschreibung des Use Case. Das Use Case Modell ist ein externes Modell, es beschreibt nur das was von aussen aus dem Blickwinkel der Aktoren sichtbar ist.

2.5.2          Beschreibung eines Use Cases

·         Auslösender Aktor und auslösendes Ereignis
·         Grundlegender Ablauf
Ø       Aktion 1
Ø       Aktion 2
Ø       ...
Ø       Aktion n
·         Alternative Abläufe für Spezialfälle, Fehlerbedingungen

·        
Vorbedingungen und Nachbedingungen

3          Domain Analyse (DA)

Ziel:                                                      Die DA modelliert den Problembereich entsprechend den in der Anforderungsspezifikation enthaltenen funktionalen Anforderungen in einem formalen, grafischen OO-Modell. Das Konzeptmodell enthält die essentielle, logische Struktur des Systems.

Ergebnisse:                                         Konzeptdiagramm (statische Sicht des Problembereichs), Klassenspezifikationen
(evtl. mit Zustandsdiagramm), Objekt-Szenario-Diagramme bzw. Interaktionsdia-gramme (dynamische Sicht der Systemfunktionalität).

Schritte der DA:
·         Objekte und Klassen finden, welche die Schlüsselabstraktionen des Problembereichs bilden.
·         Beziehungen zwischen den Klassen finden, d.h. Assoziationen
·         Attribute festlegen.
·         Methoden definieren
·         Generalisierungen und Spezialisierungen finden: Vererbung festlegen.

3.1        Konzepte finden

·         Suchen nach Strukturen
·         Andere Systeme mit denen das System zusammenarbeitet
·         Geräte: Mit welchen externen Geräten tauscht das System Informationen aus?
·         Ereignisse: Welche Dinge oder Ereignisse müssen erinnert werden?
·         Rollen: über welche Personen bzw. Rollen von Personen verwaltet das System Informationen? (in der Regel keine Aktoren, ausser das System muss etwas über sie erinnern.)
·         Orte: Muss das System Orte kennen, z.B. Standorte von Geräten, seinen eigenen Standort?
·         Organisatorische Einheiten: Zu welchen Organisationen gehören die Personen?

3.2        Attribute definieren

Um Attribute zu identifizieren, kann man folgende Fragen stellen:
·       Was muss ein Objekt einer Klasse wissen?
·       Aus der Sicht eines Objektes fragt man:
Ø     Wie werde ich im Kontext der Verantworung des Systems beschrieben?
Ø     Was muss ich wissen?
Ø     Welche Zustandsinformation muss ich erinnern?
Ø     In welchen Zuständen kann ich sein?
·       Man wähle natürliche Attribute: einzelne Daten (z.B. AHV-Nummer) oder eng zusammengehörige Daten (z.B. Adresse).

3.3        Beziehungen finden

3.3.1          Assoziation

·         Welche anderen Objekte muss ein Objekt einer Klasse kennen?
·         Von welchen andern Objekten benötigt das Objekt Dienstleistungen, bzw. von welchen anderen Objekten benutzt es Methoden?

3.3.2          Vererbung definieren

·       Jede Klasse betrachte man als Verallgemeinerung und suche potentielle Spezialisierungen.
·       Jede Klasse betrachte man als Spezialisierung und suche potentielle Verallgemeinerungen.
·       Klassen mit mehreren gleichen Attributen können Spezialisierungen der gleichen Verallgemeinerung sein.
·       Klassen mit mehreren gleichen Operationen können Spezialisierungen der gleichen Verallgemeinerung sein.
·       Treten alle Attribute und Operationen einer Klasse auch in einer anderen auf, kann diese eine Spez. der ersten sein.

3.4       

WAS ?

Transaction Pattern

4          Systemverhalten

4.1        Systemereignisse und Systemoperationen

Operationen die das System erfüllen muss. Können aus den Use Case erstellt werden.

4.2        Sequenzdiagramme

Zeigt die Abläufe zwischen Aktoren und dem System. Die verwendeten Systemoperationen und Systemereignisse.

4.3        Verträge

5          UML

5.1        Collaboration Diagrams

5.1.1          Return Value und Iteration (mit Grenzen)

5.1.2          Conditional Messages

5.1.3          Messages to Multiobjects

powered by

Software - Engineering 1 <--- ---> Softwareengeneering