Editing Informatiker FA M175 Zusammenfassung

= Probleme der SW-Entwicklung =

*Es werden immer grössere und schwierigere Aufgabe durch SW unterstützt.
*Dadurch wird SW immer komplexer
*SW ist nach wie vor Handwerkskunst (trotz CASE Tools)
*Benutzeranforderungen lassen sich nicht immer 1:1 umsetzen
*Anforderungen ändern sich  immer wieder.
*SW kann man nicht anfassen, daher ist der Zustand schwer einzuschätzen.
*Auch die SW-Qualität ist schwer zu fassen. Der Zusammenhang zwischen messbarem und das was SW-Qualität wirklich ausmacht ist nicht immer klar.
*Die Qualitätsanforderungen nehmen zu. SW-Fehler können Menschenleben gefährden.

Softwareentwicklung bewegt sich im Dreieck Zeit - Qualität - Kosten. 

== Bedeutung methodisches Vorgehen ==

*Wichtigste Erkenntnis der letzten 50 Jahre: konsequente Anwendung von '''Methodik'''.

Um für den Einsatz von Methodik das richtige Mass zu finden, ist es nützlich, sich die Zielsetzung zu vergegenwärtigen. Ziel des methodischen Vorgehens sind:

*Durch eine sachlogische begründbare, auf bewährten Prinzipien basierende Vorgehensweise klar definierte Ziele zu erreichen.
*Die Entwicklungsrisiken mindern
*Mehr Sicherheit bei der Schätzung des Aufwandes (dadurch Zeitplan und Kosten einhalten)
*Die Anforderungen in der vordefinierten Qualität umsetzen.
*Den Entwicklungsprozess wiederholbar und unabhängig von bestimmten Personen zu machen.

Der konsequente Einsatz von Methoden verursacht keine zusätzlichen Kosten, sondern vermindert diese. Vor allem Test- und Fehlerkosten. 

Die Erfahrung zeigt: Je ausgeprägter der Methoden-Einsatz desto geringer die Entwicklungskosten und desto höher die Produktqualität.

= Entwicklungsprozesse =

Eine zentrale Komponente jeder Methode besteht in der Beschreibung der Vorgehensweise.  So wie ein gutes Rezept zu einem guten Kuchen beiträgt,  führt eine bewährte Vorgehensweise bei der Entwicklung mit hoher Wahrscheinlichkeit zu einem qualitativ hoch stehenden SW-Produkt.

== Vorgehensmodelle ==

Die professionelle Erstellung von SW erfordert folgende Haupttätigkeiten:
*Fachliche und technische Entwicklung sowie Wartung und Pflege
*Management = fachliche Führung und wirtschaftliche Kontrolle
*QS

Ein bedeutender Schritt von der SW-Bastelei zur professionellen Softwareproduktion ist die Verwendung von '''Vorgehensmodellen'''. Durch Vorgehensmodelle wird der SW-Entwicklungsprozess in aufeinander abstimmte '''Phasen''' zerlegt. Für jede Phase werden '''Tätigkeiten und Ergebnisse''' festgelegt. Bekannte Vorgehensmodelle sind:

*das Wasserfallmodell
*das Spiralmodell
*das prototyping-orientierte Live-Cycle-.Modell
*das V-Modell
*der Rational Unified Process (RUP)


== Entwicklungsphasen ==

Als Kern der meisten Modell haben sich folgende Phase herauskristallisiert

[[Image:Entwicklungsphase.gif]]

=== Planungsphase (Vorstudie) ===

*Vor dem eigentlich Entwicklungsstarts des Produktes
*Es wird durch eine Vorstudio die fachliche, ökonomische und personelle Durchführbarkeit gezeigt.
*Am Ende wird entschieden: weitermachen oder beenden, wenn weitermachen, mit welcher Lösungsvariante etc.



Die Planungsphase beinhaltet u.a. folgende Aktivitäten
*'''Situationsanalyse und Zielformulierung'''. Was ist das zu lösende Problem, welche Anforderungen, was soll erreicht werden, was gehört dazu, was gehört nicht dazu, soll entwickelt oder gekauft werden.
*'''Voruntersuchung des Produktes'''. Ist-Aufnahme wenn eine Vorgänger vorhanden ist, Hauptanforderungen festlegen, Leistungsmerkmale festlegen, Hauptaspekte der Benutzeroberfläche festlegen, wichtiges Qualitätsmerkmale
*'''Untersuchung der Durchführbarkeit'''. fachlich, personell, alternative Lösungsvorschläger, Risiken.
*'''Prüfung der ökonomischen Durchführbarkeit'''

Die Ergebnisse dieses Tätigkeit münden in einer Studie die folgende Teildokumente enthalten kann:

*Grobe Anforderungsspezifikation
*Projektkalkulation
*Projektplan

Eine grobe Anforderungsspezifikation kann z.B. folgenden Aufbau haben:
*Zielbestimmung
*Produkteeinsatz
*Hauptfunktion und Hauptdaten
*Leistungsmerkmale
*Anforderung an die Benutzeroberfläche
*Qualitätsanforderungen


Die Tätigkeiten der Vorstudie haben das ziel zu prüfen ob eine Produkt entwickelt werden soll. Wenn die Entscheidung zum Kauf einer fertige Anwendung getroffen wird, diese dir grobe Anforderungsspezifikation als Vorgabe für die Evaluation. Wenn entwickelt werden soll, wird die grobe Anforderungsspezifikation im Rahmen der Definitionsphase erweitert und verfeinert.



=== Definitionsphase (Analyse) ===

Eine wichtige Tätigkeit stellt das Definieren der Anforderungen dar. Anforderungen legen die qualitativen und quantitativen Eigenschaften eines Produktes aus der Sicht des Auftraggebers fest. Die systematische Vorgehensweise um die Anforderungen in einem iterativen Prozess zu ermitteln bezeichnet man als Systemanalyse (requirements engineering)

Anforderungen sind zuerst oft vage, verschwommen, unzusammenhängend und widersprüchlich. Aufgabe des Definitionsprozesses ist es, aus diesen Anforderungen ein vollständiges, konsistentes und eindeutiges Anforderungsdokument zu erstellen.

Die fertig gesellte Produkt-Definition besteht aus folgenden Teildokumenten:
*Anforderungsspezifikation (detailliert)
*Produktemodell
*Konzept der Benutzerinteraktion


=== Entwurfsphase (Design) ===

Aufgabe des Entwerfens ist es, aus den gegebenen Anforderungen an ein Softwareprodukt eine software--technische Lösung im Sinne einer konkreten Afo6tware-Architektur zu entwickeln. Entwerfen wird auch als "Programmieren im grossen" bezeichnet. Die Ergebnisse der Analysephase bilden den Ausgangsprunk für das Entwerfen. Das Entwurfsergebnis wiederum ist die Voraussetzung für die Realisierung.


Ziel des Software-Entwurfs ist es, für das zu entwerfende Produkt eine Software-Architektur zu erstellen, welche die funktionalen Produkteanforderungen sowie allgemeine und produktespezifische Qualitätsanforderungen erfüllt und die Schnittstellen zur Umgebung versorgt.


Eine Software-Architektur beschreibt die Struktur des zu erstellen Systems durch Komponenten und ihrer Beziehungen untereinander. Zu den wichtigsten Ergebnissen des Entwurfs zählen somit die Module. Je nach eingesetzter Methode können das sein:

*Funktionale Module
*Datenobjekt-Module
*Datentyp-Module


=== Realisierungsphase (Implementation) ===

Die Programmiertätigkeiten werden in der Realisierungsphase (auch: Implementationsphase) durchgeführt. Sie ist zwischen Entwurfsphase und Einführungsphase eingebettet.

Die Realisierungsphase beinhaltet u.A. folgende Tätigkeiten:

*Datenstrukturen und Algorithmen konzipieren
*Programme strukturieren
*Implementationsentscheidungen dokumentieren
*Konstrukte der verwendeten Programmiersprache umsetzen
*Entwickelte Programm testen und verifizieren.

Ergebnisse:
*Quellprogramme inkl. Doku
*Lauffähige Objektprogramme
*Detaillierte Testplanung und Testprotokolle


=== Einführungsphase ===

In dieser Phase wird das fertig gestellte Produkt inkl. Doku abgenommen und bei Anwender eingeführt (in Betrieb genommen). Ab diesem Zeitpunkt  unterliegt das System der Wartung.Die Einführungsphase beginnt mit der Übergabe an den Auftraggeber. Dieser ist verantwortlich für die Abnahmetests und protokolliert diese.

Folgende Tätigkeiten werden weiter ausgeführt:
*Installation des Produktes (für den betrieb)
*Schulung der Benutzer und Betriebspersonal
*Inbetriebnahme des Produktes mit produktiven Daten.

Die Installation in der Zielumgebung kann mit umfangreichen Aktivitäten verbunden sein.
*Integration in bestehende Umgebung 
*Pilotierung
*Rahmenorganisation

= Systemanalyse =
Die Anforderungsdefinition (=Spezifikation) ist die Kommunikationsbasis um eine Vereinbarung über die geplante SW zu erreichen. Dabei ist es wichtig, dass Entwurfs- und Realisierungsentscheidungen während der Definitionsphase so weit als möglich vermieden werden.

== Anforderungsdefinition ==

=== Anforderungsanalyse ===
Anforderungen legen die qualitativen und quantitativen Eigenschaften des Produktes aus Sicht des Arbeitgebers fest. Die systematische Vorgehensweise um die Anforderungen in einem iterativen Prozess zu ermitteln, bezeichnet man als '''Systemanalyse'''. Diese beinhaltet folgende Aktivitäten:

*Anforderungen ermitteln
*Anforderungen festlegen und beschreiben
*Anforderungen analysieren 
*Anforderungen simulieren und ausführen (exploratives Prototyping)
*Anforderungen verabschieden.

Anforderungen sind am Anfang noch vage, verschwommen, unzusammenhängend, unvollständig und widersprüchlich. Aufgabe des Definitionsprozesses ist es aus diesen Anforderungen ein vollständiges, konsistentes und eineindeutiges Anforderungsdokument (Produkt-Definition) zu erstellen.
Die Produkt-Definition ist unter andrem deshalb so wichtig weil sie die Basis für die Abnahme des fertigen Produktes ist.

=== Was sind Anforderungen ===

Anforderungen können in funktionale und nicht-funktionale Anforderungen unterschieden werden.

*Funktionale Anforderungen definieren die Funktionen die eins System ausführen können muss (Transformation beschreiben welches aus einem Input einen Output macht)
*Nicht-funktionale Anforderungen sind Restriktionen und Qualitätsanforderungen wie z.B. Performance, Zuverlässigkeit, Wartbarkeit, Gestaltung der Benutzungsschnittstelle, Sicherheitsanforderungen, Portabilität, Erfüllung von Standard etc.

Hinweis: Aus nicht-funktionalen Anforderungen können funktionale werden; z.B. die Erfüllung von Sicherheitsstandars kann nur von entsprechenden Zusatzfunktionen erreicht werden.

=== Zur Bedeutung der Systemanalyse ===
*bildet in vielerlei Hinsicht das '''Fundament''' für ein Softwaresystem
*zwingt den Benutzer seine Anforderungen sorgfältig zu bedenken und in Zusammenhang mit seinen Problemen und Zielen zu betrachten.
*Im Verlaufe der Erarbeitung der Anforderungsdefinition findet eine intensive Auseinandersetzung zwischen Benutzer und Entwickler statt.
*Die Systemanalyse fördert zugleich die Entwicklung von '''Plänen für den Abnahmetest'''.
*gegen die Anforderungsspezifikation wird das implementierte Produkt auf Korrektheit und Vollständigkeit getestet.
*unterstützt das Projektmanagement indem daraus Schätzungen bezüglich Zeit, Kosten und anderer Ressourcen abgeleitet werden können.
*es können auch schon Rahmenbedingungen für zukünftige Änderungen und Wartungsarbeiten festgelegt werden.

Wesentlich für eine Anforderungsdefinition ist es den Auftraggeber angemessen einzubinden. Die Systemanalyse bildet von Anfang an die Basis für eine vertrauensvolle Zusammenarbeit zwischen Benutzer und Entwickler welche erfahrungsgemäss nach der erfolgten Realisierung des Produktes nicht abgeschlossen ist.


=== Exploratives Prototyping ===

Ein verbreitetes Problem bei der Erarbeitung der Anforderungsdefinition ist, dass Benutzervertreter bzw. Analytiker sich nicht vorstellen können, wie die geplante Applikation funktionieren soll. Die verbale bzw. grafische Beschreibung reicht oft nicht aus, um eine ausreichend klare Vorstellung  vom zu entwickelnden Produkt zu erhalten.

Der explorative Prototyp dient der Veranschaulichung und Klärung der Anforderungen. Das Ziel beim exploratoiven Prototyping  ist also eine möglichst vollständige Systemspezifikation. Es geht den Entwicklern nur darum, verschiedene Lösungsansätze mit dem Anwender zu klären.


== Ausgestaltung der Anforderungsdefinition ==

=== Anforderungsdefinition nach IEEE ===

Als Muster für verbale Anforderungsbeschreibungen mit festgelegtem Gliederungsschema kann ANSI/IEEE Std-830-1984 angesehen werden

[[Image:IEEEStd-830-198.gif]]

=== Qualitätsziele der Anforderungsdefinition ===

Beschriebene Anforderungen sind auf folgende Qualitätsziele zu analysieren:

*Sind die Anforderungen inhaltlich vollständig?
*Sind die Anforderungen konsistent? (untereinander widerspruchsfrei)
*Sind die Anforderungen eindeutig? (eindeutige, nicht unterschiedliche interpretierbaren Anforderungen)
*Sind die Anforderungen durchführbar? (z.B. technisch mit der geplanten Plattform möglich)
*Sind die Anforderungen als Vorgabe für den Abnahmetest geeignet?

= Strukturierte Analyse =

Dir Strukturierte Analyse (SA) dient dazu, die Definition von Anforderungen an komplexe System zu vereinfachen. Dazu legt die SA fest, welche Ergebnisse zu erbringend sind um die nachfolgende Phase Strukturiertes Design (SD) in Angriff zu nehmen. Dazu werden Techniken zur Verfügung gestellt die aufeinander abgestimmt sind.

Die Modellierung nach SA hat zum Ziel das so genannte essenzielle Modell des System zu erstellen. Darin wird beschrieben was ein System tun muss und welche Informationen vorhanden sein müssen. Die beschreibung in dieser Form ist auch für den Benutzer verständlich.

== Methode der strukturierte Analyse ==

*In der SA enthält das Modell  keine Implementationsdetails
*es werden die wahren Anforderungen des Anwenders wiedergegeben. d.H. diejenigen Funktionen die unabhängig von der Implementation verfügbar sein müssen.


=== Umgebungs- und Verhaltensmodell ===

Das essenzielle Modell besteht aus zwei Komponenten:

*Dem Umgebungsmodell bestehend aus Ereignistabelle, Kontextdiagramm und einer Kurzbeschreibung der Aufgabe des Systems
*Dem Verhaltensmodell bestehend aus Datenflussdiagramm, Prozessbeschreibung, Datenkatalogeinträgen, ERD.

Das Umgebungsmodell beschreibt das System als '''Blackbox''', das Verhaltensmodell als '''White-Box'''



[[Image:UmgebungsVerhaltensmodell.gif]]

=== Das Hierarchiekonzept der strukturierten Analyse ===

*Problem: Bei umfangreichen Aufgabenstellungen kann ein Datenflussdiagramm (DFD) mehrere Seiten umfassen.
*Die Lösungsidee der SA besteht darin, das DFD hierarchisch zu verfeinern.
*Nachdem auf Basis der Ereignistabelle das Kontextdiagramm erstellt worden ist, wird dieses in Form des '''Datenflussdiagramm Level 1''' verfeinert.
*Zu diesem Zweck werden Prozesse identifiziert welche die Datenflüsse verarbeiten/generieren.
*Für jeden Prozess der in '''Teilprozesse''' aufgeteilt werden kann, wird ein weiteres DFD auf der nächsten Detaillierungsstufe gezeichnet.
*Auf diesen Weise werden DFD stufenweise verfeinert (Level 1, Level 2 ...)
*Dies wird so lange fortgesetzt bis die Teilprozesse nicht mehr sinnvoll zerlegt werden können (bis '''Elementarprozesse''' entstanden sind)
*Jeder Elementarprozess wird schliesslich durch eine Mini-Spezifikation beschrieben.


[[Image:HirarchiekonzeptSA.gif]]


== Techniken der strukturierten Analyse ==

=== Ereignistabelle ===

Die Ereignistabelle zeigt durch welche Ereignisse das System aktiviert wird. Zu jedem Ereignis gehört ein konkreter Auslöser in Form eines externen Datenflusses und eine Reaktion im System. 

Beispiel Seminar-Hotel:

{| border="1"
! Nr !! Ereignis !! Auslöser !! Antwort/Reaktion
|-
| 1 || Gast wünscht Zimmerreservation || Reservation ||  Reservationsbestätigung
|-
| 2 ||  Auftraggeber fragt Dienstleistung an || Anfrage  || Offerte
|}

*Eine Ereignistabelle  beschreibt diejenigen Ereignisse die im System ein Aktion auslösen und eine oder mehrere Antworten bzw. Reaktionen.
*Man unterscheidet zwischen externen und zeitlichen Ereignissen
*Es werden nur Ereignisse in die Liste aufgenommen welche ein nach aussen sichtbare Reaktion des Systems auslösen.
*Bei der vereinfachten Form der Ereignistabelle wird die Spalte "Auslöser" weggelassen. Der Auslöser wird dann in der Ereignisbeschreibung erwähnt.

Im nächsten Schritt werden die Auslöser und Reaktionen im Kontextdiagramm grafisch dargestellt

=== Kontextdiagramm ===

Das Kontextdiagramm ist ein Datenflussdiagramm das die Schnittstellen des zu modellierenden Systems mit seiner Umwelt beschreibt.

Im Compendio-Buch werden folgende drei Symbole folgende Notation verwendet:

*Applikation, dargestellt durch ein Rechteck; damit wird das System als ganzes symbolisiert.
*Schnittstelle zur Umwelt, dargestellt durch ein Rechteck mit Schatten, das den Schnittstellennamen enthält.
*Datenfluss, dargestellt durch einen beschrifteten Pfeil. Manchmal werden zum einfacheren Verständnis auch Informationsflüsse (gestrichelt) zwischen den externen Partnern gezeichnet.

'''Syntaktische Regeln'''
*Das Kontextdiagramm enthält nur einen Prozess, nämlich die Applikation als Ganzes.
*enthält mindestens eine Schnittstelle.
*zwischen den Schnittstellen gibt es keine Datenflüsse
*enthält keine Speicher und keine Funktionen


Semantische Regeln:
*beschriebt den Anwendungsbereich des zu modellierenden Systems (problem domain, Untersuchungsbereich)
*es zeigt die Datenflüsse welche die Systemgrenzen passieren.
*Eine Schnittstelle ist so zu wählen, dass sie die ursprüngliche Quelle oder Senke (Ziel)einer Information angibt.


Mögliches Kontextdiagramm für Seminar-Hotel:

[[Image:KontextdiragrammHotel.gif]]]

Die Beschreibung darf nicht zu abstrakt aber auch nicht zu detailliert sein. Wichtig ist, dass jemand der sich in ein System neu einarbeiten muss, anhand des Kontextdiagramm die wesentlichen Informationen über die Umwelt des Systems (inkl. Datenströme) erhält.


Das Kontextdiagramm wird  durch eine Kurzbeschreibung in Textform ergänzt.

Beispiel: ''Die Applikation "Seminar-Hotel" erlaubt es ......."''


Der Prozess im Kontextdiagramm beschreibt das gesamte zu modellierende System. Dieser Prozess wird anschliessend in Teilprozesse gegliedert und ein einem DFD dargestellt.


=== Datenflussdiagramm (DFD) ===
Ein Datenflussdiagramm (data flow diagramm) beschreibt die Wegen von Daten bzw. Informationen zwischen Funktionen, Speichern und Schnittstellen sowie die Transformation der Daten bzw. Informationen durch Funktionen

In der deutschsprachigen Schweiz ist die folgende Notation mit vier Symbolen weit verbreitet:

*Funktion bzw. Prozesse, dargestellt durch ein Rechteck mit dem Namen der Funktion
*Datenfluss, dargestellt durch einen beschrifteten Pfeil
*Schnittstelle zur Umwelt, dargestellt durch ein Rechteck mit Schatten, das den Schnittstellennamen enthält.
*Datenspeicher, dargestellt durch ein abgerundetes Rechteck, in dem der Speichername steht.


Das DFD stellt dar welche Informationen von wo nach wo durch das System fliessen. Es wird nicht dargestellt, wie es initiiert wird, oder in welcher Reihenfolge dies ausgeführt wird.

*jedes zu entwickelnde System hat Schnittstellen zur Umwelt.
*Die Umwelt liefert Informationen die vom System verarbeitet werden.
*Die Umwelt nimmt Informationen auf welche vom System erzeugt wurden.
*Nur das System wird modelliert. Die Umwelt nicht.
*Informationen kommen aus Informationsquellen und fliessen zu Funktionen.
*Eine Funktion transformiert ankommende Datenflüsse in ausgehende Datenflüsse.
*Speicher sind Hilfsmittel zur Ablage von Informationen.
*Informationen können in einen Speicher geschrieben und daraus wieder gelesen werden.



Beispiel DFD "Seminar-Hotel"

[[Image:DFD SeminarHotel.gif]]


'''Syntaktische Regeln'''
*Ein DFD enthält mindestens eine Schnittstelle
*Zwischen Schnittstellen gibt es keine Datenflüsse. Zur Erläuterung können Informationsflüsse gestrichelt eingetragen werden. Sie sind aber für die Spezifikation des Systems nicht wichtig.
*Jeder Datenfluss hat einen Namen. Ausnahme: Datenflüsse die zu einem Speicher führen oder dort beginnen und keinen Namen haben, transportieren die gesamten gespeicherten Daten.
*Zwischen Speichern gibt es keine direkten Datenflüsse
*Zwischen Schnittstellen und Speichern dürfen keine direkten Datenflüsse gezeichnet werden.


'''Semantische Regeln'''
*Das DFD beschriebt den Datenfluss, nicht den Kontrollfluss.
*Es enthält weder Entscheidungen noch Schleifen
*Es wird keine Aussage über die Initiierung, Terminierung oder Abfolge von Funktionen gemacht.
*Ein Schnittstelle ist so zu wählen, dass sie die ursprüngliche Quelle oder Senke(Ziel) angibt (jedoch wenn möglich nicht "Tastatur" oder "Drucker").
*Ein Datenflussname besteht aus einem Substantiv (Nomen) oder einem Adjektiv (Eigenschaftswort) und einem Substantiv.
*Als Datenflussnamen sollten keine seichten Namen wie "Daten" oder "Informationen" verwendet werden. Stattdessen soll der Namen auch etwas über die fliessenden Daten aussagen (z.B. Gästedaten, Buchungsdaten etc.)
*Funktionsnamen repräsentieren Aktionen; ein Funktionsname besteht au seinem einzigen starken Aktions-Verb gefolgt von einem einzigen konkreten Objekt (z.B. erstelle Adresskleber) oder einem konkreten Substantiv gefolgt von einem starken Aktions-Verb (z.B. Adressaufkleber erstellen". Seichte Namen wie "verarbeite", "bediene" sind zu vermeiden.


'''Inhaltliche Regeln'''
*Wird in einen Datenspeicher geschrieben, so muss auch wieder gelesen werden (und umgekehrt)
*Alle Daten die aus einer Funktion herauskommen, müssen auch in diese eingeflossen sein.
*Jede Funktion hat mindestens einen Eingangs- und Ausgangsdatenfluss.
*DFD sollten nur die wesentliche Verarbeitung beschreiben. Einzelheiten wie Prüfroutinen, Fehlerbehandlung, Datenadministration, Initialisierung, Drucken gehören nichts ins DFD

Die inhaltliche Qualität kann mit einer '''Handsimulation''' geprüft werden.



'''Bewertungen:'''

*DFD sind leicht zu erstellen und sind gut lesbar
*werden auch von Auftraggebern verstanden (gut vermittelbar)
*ein DFD enthält mehr Informationen als eine Funktionsbaum
*Wenn ein ganzes System dargestellt werden soll, wird das Diagramm schnell zu gross und unübersichtlich.
*es ist schwierig bei den Daten und Funktionen ein einigermassen einheitliches Abstraktionsniveau einzuhalten.
*Die Bezeichnung der Datenflüsse reicht nicht aus. Man muss den Datenaufbau kennen um eine Handsimulation durchführen zu können.

[[Image:DFD SeminarHotel Level2.gif]]


Wichtige Regeln bei der Erstellung eines SA-Modells:
*Schnittstellen können nicht verfeinert werden. Jedoch können die im Kontext-Diagramm aufgeführten Schnittstellen unverändert in verfeinerten Diagrammen dargestellt werden, wenn dies die Verständlichkeit fördert.
*Speicher können nicht verfeinert werden. Jedoch können Speicher, nachdem sie  in einem Diagramm eingeführt wurden, auf allen Verfeinerungen dieses Diagramms unverändert wiederholt werden.
*Die Anzahl der Prozesse auf einem Diagramm sollte nicht wesentlich grösser als sieben sein (7 +/- 2-Regel). Sonst zusätzliches Diagramm.


'''Hinweise:'''
*wenn die Anzahl und Struktur der Speicher schwierig zu ermitteln ist, empfiehlt es sich die SA-Modellierung zu unterbrechen und zunächst ein ER-Modell (Entity-Relationship-Modell) zu erstellen. Aus dem ER-Modell ergibt sich dann die Anzahl der benötigten Speicher.
*Die Erstellung eines SA-Modells ist ein iterativer Prozess. Es werden mehrere Durchgänge benötigt bis sich ein stabiles SA-Modell ergibt.



=== Data Dictionary (DD) ===

*Ein DD ist ein Verzeichnis, das Informationen über die Struktur von Daten, ihre Eigenschaften sowieso ihrer Verwendung enthält.
*Die Informationen des DD werden z.B. zur Konsistenzüberwachung eines Datenbestandes benötigt.
*entsteht in der Definitionsphase und wird in der Entwurfs- und Realisierungsphase weiter verwendet und ergänzt.
*Das Hauptziel des DD ist es, die in den DFD verwendeten Bezeichnungen der Datenflüsse und Datenspeicher zu definieren.
*In der einfachsten Form des DD wird für die Bezeichnungen definiert aus welchen Elementen sie bestehen.


Hier ein mögliches DD für das "Seminar-Hotel"

{| border="1"
! Bezeichnung !! Elemente
|-
| Kunde ||  = Personal-Nr. + Name + Adresse + Geburtsdatum + Funktion + Umsatz
|-
| Name || = Anrede + Titel + Vorname + Nachname
|-
| Adresse|| = Strasse + Haus-Nr. + Postfachnummer + Länderkennzeichen + PLZ + Ort + Telefon + Fax
|}

Ausgehen von abstrakten Daten, z.B. Kundendaten, werden dieser schrittweise verfeinert (Kundendaten, Adresse, Ort). Die Verfeinerung wird beendet wenn die Daten nicht weiter zerlegt werden können.


Unter Umständen ist es sinnvoll die Datenbeschreibung zusätzlich zu strukturieren. z.,B. Backup-Naur-Form (BNF):

[[Image:BNF1.gif]]


Beispiel:

[[Image:BNF Beispiel.gif]]


=== DD-Einträge und Datenintegrität ===
DFD werden Schritt für Schritt verfeinert. Auch die Datenflüsse werden verfeinert. Woher weiss man nun aber, welche Datenflüsse zwischen zwei Diagrammen wie zusammengehören. Diese Problem löst man in der SA mit folgenden Forderungen:

*Jeder Datenfluss trägt einen Datenflussnamen (Ausnahme: Datenfluss zu einem Speicher wenn auf den gesamten Inhalt zugegriffen wird)
*Jeder Datenflussname ist im DD definiert
*jeder Speicher trägt einen Namen
*jeder Speichername ist im DD definiert.

Die Zusammenhänge zwischen zwei Diagrammen werden also über die DD-Einträge hergestellt. Alle Datenflüsse eines untergeordneten DFD müssen im übergeordneten entweder unter gleichem Namen erscheinen oder Teilkomponente eines Datenflusses sein. Ist diese Eigenschaft in allen Diagrammen erfüllt, dann spricht man von einem '''ausbalancierten Datenflussmodell''' (Überprüfung durch CASE-Tool).

=== Mini-Spezifikation (MiniSpec) ===
*ist eine inhaltliche Beschreibung eines Prozesses.
*jeder Prozess eines DFD, der nicht durch ein weiteres DFD verfeinert wird, muss durch eine MiniSpec beschrieben werden.
*jede MiniSpec beschreibt wie Eingaben (Datenflüsse) in den Prozess fliessen und in Ausgaben transformiert werden.
*durch die Verknüpfung der Eingaben mit den Ausgaben kann festgestellt werden, ob die Erzeugung aller Ausgaben mit Hilfe der vorhandenen Eingaben möglich ist.
*MiniSpec darf keine Implementationsvorschriften enthalten
*MiniSpec ergänzt DFD, aber ersetzt sie nicht.
*werden durch normalen Text, Pseudocode oder Entscheidungstabellen beschrieben.


=== Funktionsbaum ===

*Eine funktionale Hierarchie entsteht, wenn eine allgemeine Funktion in Teilfunktionen gegliedert wird.
*wirf oft in Form eines Funktionsbaumes dargestellt.
*Funktionen werden als beschriftete Rechtecke ("Kästchen") gezeichnet und mit unbeschrifteten Linien verbunden.

Beispiele:
[[Image:Funktionsbaum1.gif]]

[[Image:Funktionsbaum2.gif]]

*Eine Funktion solle entweder durch ein Verb und ein Objekt (verwalte Kunden) oder ein Substantiv und ein Verb (Kunden verwalten) bezeichnet werden.
*Bezeichnung muss durchgängig sein.


Folgende Regeln sind bei der Erstellung zu beachten:
*Unter einer gemeinsamen Vaterfunktion sollen nur Funktionen angeordnet werden, welche zusammengehörende Tätigkeiten beschreiben (kann nur mit Fachwissen entschieden werden).
*Auf einer Hierarchieebene sollen Funktionen angeordnet sein, dir sich auf dem selben Abstraktionsniveau befinden.


Fazit:
*bewährtes Konzept zur systematischen Gliederung von Funktionen
*Gibt erste Hinweise für mögliche Dialoggestaltung
*sehr einfach einsetzbar, berücksichtigt aber nur die funktionale Sicht.


Im Allgemeinen enthält ein DFD nur solche Funktionen die in einem Funktionsbaum vorkommen, dort derselben Hierarchieebene angehören und dieselbe Vaterfunktion besitzen.


=== Bewertung der SA ===

Vorteile der SA:
*Geschickte Kombination bewährter Basistechniken
*Verbesserung der Übersichtlichkeit durch hierarchisch gegliederte DFD
*viele analytische Qualitätssicherungsmöglichkeiten durch Quervergleiche.
*Leicht erlernbar
*Auch für den Auftraggeber nachvollziehbar
*Erlaubt eine top-down Einarbeitung in ein System
*Durch CASE-Tools gut unterstützt.
*Zusammenhang zu ER-Modell über Speicher gut herstellbar.
*Durch die DFD-Hierarchie entsteht implizit auch ein Funktionsbaum.

Nachteile:
*Schnittstellen können nicht verfeinert werden. Dadurch: Darstellungsprobleme bei umfangreichen Schnittstellen.
*Speicher können nicht verfeinert werden.

== Qualitätssicherung ==

*grosse Stärke des SA:Modell: vielfältige QS-Analysen möglich
*jede Basistechnik kann überprüft werden.
*Quervergleiche zwischen DFD und DD sowie DFD und Minispec sowie Minispec und DD möglich.

Die syntaktische Überprüfungen können CASE_Tool übernehmen, die semantischen müssen per Review erfolgen.


=== Allgemeine Anforderungen an das Modell ===

*Das Modell soll nur so komplex sein, dass ein durchschnittlicher Leser nicht überfordert wird.
*Ein DFD sollte nicht mehr als 7 (plus/minus zwei) Prozesse enthalten
*Eine Zerlegung muss alle für das Verständnis notwendige Informationen enthalten.
*hat man mehrere Möglichkeiten, eine Aktivität auszudrücken, wählt man die mit den wenigsten Aktivitäten und Datenspeichern
*alle Eigenschaften weglassen welche sowieso selbstverständlich sind.
*Die Definition des Systems soll keine Hinweise auf die Technolgie beinhalten.

=== DFD-Semantik ===

Die Semantik der DFD einschliesslich der DFD-Hierarchie kann durch folgend Fragen überprüft werden:

*benötigt ein Prozesse zusätzliche Eingabedaten welche nicht verfügbar sind?
*prüfe ob alle Ausgabendatenflüsse mit den vorhanden Eingabedatenflüsse erzeugt werden können?
*besitzt ein Prozess überflüssige Eingabedaten?
*Prozessname irreführend?
*Prozessname allgemein.

=== DFD-Syntax ===

*Gibt es Speicher welche nur beschrieben oder nur gelesen werden?
*überdurchschnittlich viele Eingabe- und/oder Ausgabedatenflüsse?
*namenloser Datenfluss? (nur bei Speichern zulässig)


=== Konsistenz ===

Zwischen DFD und DD sowieso zwischen MiniSpec, DFD und DD gibt es viele Möglichkeiten die Konsistenz zu prüfen:

*Ein- und Ausgaben
*überflüssige Definitionen im DFD
*bereits Implementationsdetails in der MiniSpec?
*sind alle Datenflüsse des DFD im DD


== Ergebnisse der SA ==

[[Image:Ergebnisse SA.gif]]


= Konzeptionelle Datenmodellierung =

== Grundlagen ==

=== Drei-Ebenen-Architektur ===

*Die Arbeit mit Modellen erfolgt in der Informatik auf drei Ebenen.
*Für Daten ist das 3-Ebenen ANSI-SPARC-Modell (1975) relevant


[[Image:DreiEbenen SPARC.gif]]


*'''Interne Ebene''': beschreibt wie die Daten auf den externen Speichermedien z speichern sind. Festlegen der physischen Speicherstruktur.
*'''Konzeptionelle Ebene''': hardware-- und softwareneutrale Beschreibung der Daten. Dient als Basis für die Umsetzung des Datenmodells auf die externe und interne Ebene.  Es entsteht das semantische Datenmodell.
*'''Externe Ebene'''. Beschreibt die Daten aus der Sicht der Benutzer. Daten welche in der konzeptionellen eeben zerlegt wurden, werden hier wieder zusammengesetzt (View, Abfrage, etc.)

=== Vorgehensweise ===

Für die Datenmodellierung hat sich folgenden Vorgehensweise durchgesetzt:

*Realitätsanalyse (Grobmodell in der Vorstudie)
*Erstellung des ERM (Detailliertes Modell in der Systemanalyse)
*Umsetzung des ERM in ein RDM (Entwurfsphase)
*Physisches Datenmodell (Realisierungsphase)


== Elemente des Entity-Relationship-Modells (ERM) ==

=== Entitäten und Eigenschaften ===
siehe Modul 170


=== Beziehungen ===
siehe Modul 170

=== Generalisierung / Spezialisierung ===
Für sich überlappende Entitätsmengen kann immer eine Menge definiert werden, welche die überlappenden Mengen umfasst. Eine solche Menge wird als Superentität bezeichnet. Das Definieren einer Superentität wird Generalisierung bezeichnet und die in einer Generalisierung auftretenden Entitätsmengen und Subentitäten lasse sich als Spezialisierung auffassen.


'''Die vier Arten der Überdeckung'''

(die folgenden Beispiele gehen vom Beispiel einer Subentität "Fotoclub" und "Sportclub aus)

'''1. Die Subentitätsmengen überlappen sich gegenseitig'''

Beispiel: Ein Mitarbeiter kann in keiner, nur einer oder in beiden Subentitäten vorhanden sein.


'''2. Die Subentitätsmengen überlappen sich gegenseitig und überdecken vollständig die Entitätsmenge der Generalisierung'''

Beispiel: Ein Mitarbeiter muss in einer oder in beiden Subentitäten vorhanden sein.


'''3. Die Subentitätsmengen sind sich gegenseitig disjunkt'''

Beispiel: Ein Mitarbeiter kann in keiner oder einer Subentitäten vorhanden sein.


'''4. Die Subentitätsmengen sind sich gegenseitig disjunkt und überdecken vollständig die Entitätsmenge der Generalisierung'''

Beispiel: Ein Mitarbeiter muss in einer, aber nicht in beiden Subentitäten vorhanden sein.


=== Assoziationen ===

Siehe Modul 170

=== Eigenschaften und Attribute ===

Siehe Modul 170

=== Aggregation ===

In bestimmten Situationen kann es erwünscht sein, dass ein Beziehungstyp selbst an einer Beziehung teilnehmen soll. Der Beziehungstyp wird dadurch zu einem komplexen Entitätstyp uminterpretiert. Der Vorgang wird häufig auch als '''Aggregation''' und der entstehende Entitätstyp als '''Assoziationstyp''' bezeichnet.

[[Image:Aggregation ERM.gif]]

Im obigen Beispiel soll der Kurs mit einer Prüfung abgeschlossen werden. Die Prüfung bezieht sich einerseits auf den Kurs und andererseits auf den teilnehmen, als auf deren Beziehung untereinander, "Teilnahme" genannt. Daher ist es notwendig die Prüfung mit der Teilnahme in Beziehung zu setzen. dies wird erreicht, indem die Beziehung als Entität aufgefasst wird.

Auch wenn in einer Beziehung zusätzliche Daten untergebracht werden sollen muss eine komplexe Beziehung als Entität aufgepasst werden. (Im Beispiel das Anmeldedatum).

= Weitere Techniken der Systemanalyse =

== Zustandsdiagramm ==

=== Beschreibung ===

Beschreibt verschiedene Zustände einer Entität/Objekt (d.h. einen möglichen Lebenszyklus) sowie die Ereignisse, Bedingungen und Aktionen welche die Übergänge (Transitionen) zwischen diesen Zuständen verursachen.


=== Notation ===

[[Image:Zustandsdiagramm-Notation.gif]]

Hinweis:
Anfangs- und Endzustand sind als besondere Zustandstypen anzusehen, da zu einem Startzustand kein Übergang stattfindet und dem Endzustand keine Zustandsänderung folgt.



Beispiel Zustandsdiagramm für die Offerterstellung des Seminar-Hotels:

[[Image:Zustandsdiagramm-Beispiel.gif]]

== Aktivitätsdiagramm ==

=== Beschreibung ===

*besteht aus Folgen von Aktivitäten. Ein Aktivität ist dabei ein einzelner Schritt in einem Verarbeitungsablauf.
*ist vergleichbar mit den bekannten Flussdiagrammen bzw. Programmablaufplänen. 
*kann u.a. zur Beschreibung von prozeduralen Abläufen, Algorithmen, Geschäftsprozessen, Anwendungsfällen oder Operationen verwendet werden.
*Im Unterschied zu Flussdiagrammen ist die Darstellung paralleler Prozesse möglich.


=== Notation ===

[[Image:Aktivitaetsdiagramm Notation.gif]]

Beispiel für Seminar-Hotel

[[Image:Aktivitaetsdiagramm Beispiel.gif]]

== Entscheidungstabelle ==

*bei komplexen Entscheidungssituationen ist eine verbale oder eine grafische Darstellung oft ungenügend.
*Die Entscheidungstabelle ist ein Klassiker unter den Darstellungstechnikern und ein bewährtes Hilfsmittel um Entscheidungssituationen übersichtlich und verständlich darzustellen
*können durch Generatoren automatisch in Code verwandelt werden.

=== Grundaufbau ===

[[Image:Entscheidungstabelle Grundlagen.gif]]

=== Arten von Entscheidungstabellen ===


'''Begrenzte Entscheidungstabellen'''

Haben im Bedingungsanzeigerteil nur folgende Symbole:

*J: Bedingung muss erfüllt sein)
*N: Bedingung darf nicht erfüllt sein)
*-: Bedingung egal (Irrelevanzanzeiger)

[[Image:Begrenzte Entscheidungstabelle.gif]]


Von der vollständigen Entscheidungstabelle ET1 mit allen '''2 hoch 3 = 8 Regeln''' kommt man wie folgt zur begrenzten Entscheidungstabelle ET2:
*prüfen ob es Regeln mit identischen Aktionen gibt. Wenn ja, werde zwei dieser Regeln betrachtet und geprüft auf welche Bedingung es ankommt. Irrelevante Bedingungen werden eliminiert.
*Im Beispiel haben die regeln R3 und R4 in ET1 dieselbe Aktion. Es kommt also auf das J oder N in Bedingung B3 nicht an. Darum werden R3 und R4 in ET1 zu R3 in ET2 zusammengefasst. Anstelle des J oder N wird das "-" eingesetzt.
*Ebenso kann man leicht erkennen, dass es bei Regeln R5 bis R8 in ET1 auf Bedingung B2 und B3 nicht ankommt.  --> zusammenfassen


'''Erweiterte Entscheidungstabelle'''

Unterscheiden sich von den begrenzten dadurch, dass die einzelnen Bedingungen und Aktionen nicht mehr vollständig beschrieben, sondern nur zusammen mit den Eintragungen im Bedingungs-- und Aktionsanzeigerteil eindeutig bestimmt werden.

Beispiel:
[[Image:Entscheidungstabelle erweitert.gif]]


== CRUD-Matrix ==

*ist eine Möglichkeit den Zusammenhang zwischen den Daten- und Funktionssicht herzustellen.
*kann auch eine QS-sichernde Massnahme sein.
*zeigt welche Entitäten von welchen Funktionen erstellt (create), gelesen (read), verändert (update) oder gelöscht (delete) werden.
*die Anforderungsspezifikation ist erst vollständig wenn jede Entität mindestens von einer Funktion erstelle und gelöscht werden kann.
*wenn die Funktion zum lesen fehlt, muss die Spezifikation ebenfalls näher geprüft werden.

[[Image:CRUD-Matrix.gif]]

= Grundlagen zum Entwurf =

Nachdem die Anforderungen analysiert, dokumentiert und modelliert wurde (das "Was"), soll in der nächsten Entwicklungsphase eine Entwurf des Systems erstellt werden (das "Wie")

== Einordnung des Entwurfs ==

Aufgabe des Entwerfen (Design) ist es, aus den Anforderungen eine Software-technische Lösung im Sinne eine Software-Architektur zu entwickeln. Entwerfen wird auch als "Programmieren im Grossen" bezeichnet.

Ziele des Softwareentwurfs:
*Erhöhung der Produktivität bei der Entwicklung und Wartung komplexer Systeme
*Sicherung wesentlichen Qualitätsmerkmale aus Entwicklersicht wie Wartbarkeit
*Sicherung wesentlichen Qualitätsmerkmale aus Benutzersicht wie Zuverlässigkeit.


Ergebnis des Entwurfs ist eine '''Entwurfsspezifikation''', die Beschreibung der Software-Architektur des geplanten Systems. Bevor mit den eigentlichen Entwurfsaktivitäten begonnen werden kann, müssen die Rahmenbedingungen geklärt und festgelegt werden. Ausserdem müssen eine Reihe von Entscheidungen gefällt werden welche die weitere Vorgehensweise wesentlich beeinflussen.

== Einflussfaktoren ==

*Produkteinsatz: Mandantenfähigkeit, zentraler/verteilter Betrieb, etc.
*Nichtfunktionale Anforderungen: Skalierbarkeit, Internationalisierung, etc.
*Qualitätsanforderungen: Zuverlässigkeit, Effizienz, etc..
*Zielplattform: Netzdienste, GUI-System, Datenbanken, Systemsoftware, etc.

Diese Faktoren beeinflussen sowohl die zu entwerfende Software-Architektur als auch die zu treffenden Entscheidungen bezüglich unterstützenden Systeme:

*Datenhaltung
*Benutzeroberfläche
*Hilfesystem

=== Produkteinsatz ===

bei den Einsatzbedingungen sind verschieden Aspekte zu unterscheiden welche einen wesentlichen Einfluss haben. Z.B.

*Zentrale / verteilte Systeme
*Mandantenfähigkeit


'''Zentraler / Verteilter Betrieb'''
*Client / Server Konzept


'''Mandantenfähigkeit'''
*alle Daten eines Mandanten müssen unabhängig von den anderen Mandaten gespeichert werden.


=== Nicht-funktionale Anforderungen /Qualitätsanforderungen ===


z.B.
*international --> mehrere Sprachen, verschieden Währungsformate, Mehrwertsteuerberechnungen
*verschiedene Plattformen
*Skalierbarkeit
*Zuverlässigkeit
*Effizienz


=== Zielplattform ===

*Es muss geklärt werden welche "unterstützenden Systeme" benötigt werden und ob diese auf der Zielplattform bereits existieren.
*Die Schnittstellen zu diesen System müssen klar definiert sein.
*klären ob unterstützende Systeme selber entwickelt werden müssen.

fast alle Anwendungen benötigen eine Datenhaltung. Dafür gibt es im Wesentlichen vier Konzepte:
*"flache" Dateien (flat files). Filesystem des jeweiligen Betriebssystem
*hierarchische DB (nicht mehr aktuelle, aber aus Performancegründen interessant wo sehr grosse Datenmengen zu verwalten sind)
*relationale DB (RDBMS) 
*objektorientierte DB (ODBMS) (aktuell nur für kleine Datenmengen einsetzbar)

Weitere Faktoren:
*Datenhaltung auf einem Server oder verteilt auf mehrere Plattformen
*Art und Weise wie die Benutzeroberfläche realisiert werden soll (u.a. abhängig von der Programmiersprache)
*soll ein eigenständiges Hilfesystem eingesetzt werden oder stellt das OS schon etwas zur Verfügung.


Generelles Ziel aller Entscheidungen:
*möglichst viele Dienstleistungen auf hohem Abstraktionsniveau von anderen Systemen in Anspruch nehmen.


== Aufgaben des Entwurfs ==

*Erstellen einer konkreten Software-Architektur für das zu entwerfende Produkt, welche funktionalen und nicht-funktionalen Anforderungen sowie allgemeine und produktespezifische Qualitätsanforderungen erfüllt und die Schnittstellen zur Umgebung versorgt.


=== Software-Architektur ===

*Beschreibt die Struktur des Systems durch Komponenten und ihre Beziehung untereinander
*Eine Komponente ist ein abgegrenzter Teil eines Systems. Sie dient als Baustein für die physikalische Struktur einer Anwendung.
*Beispiel für Komponenten: Module, Funktionen, Prozeduren, abstrakte Datentypen.
*Eine Beziehung kann jede mögliche Art von Verbindung zwischen den Komponenten sein

Beispiel für Beziehungen:
*Aufruf von Funktionen durch andere Funktionen
*Austausch von Daten zwischen Komponenten


=== Modularisierung ===

*ist die Aufgliederung eines Systems in mehrere Teile (Module, Komponenten)

Ein Modul ist ein SW-Baustein der folgende Eigenschaften hat:
*Darstellung einer funktionalen Einheit oder zusammengehörende Funktionsgruppen
*Weitgehend Kontextunabhängig, d.h., ein Modul ist in sich abgeschlossen und unabhängig von der Umgebung entwickelbar, prüfbar und einsetzbar.
*Definierte Schnittstelle für die Verwendung des Moduls
*handlich, überschaubar, verständlich.


Vorteile:
*Einfache Änderbarkeit/Austauschbarkeit
*Verbesserung der Wartbarkeit
*Erhöhung der Wiederverwendbarkeit
*Erleichterung der Standardisierung
*Verbesserung der Überprüfbarkeit
*Erleichterung der Arbeitsorganisation

'''Hinweis''': Zur Modularisierung gehört auch das Prinzip der Kapselung.


=== Schichtenarchitektur ===

Wenn eine Software viele Komponenten hat, ist eine stärkere Strukturierung sinnvoll. Diese '''Schichtenarchitektur''' kann wie folgt dargestellt werden:

[[Image:Schichtenarchitektur.gif]]

Gliedert man eine Anwendung in Benutzeroberfläche, eigentliche Anwendung und Datenhaltung, dann erhält man eine '''Drei-Schichten-Anwendungsarchitektur''' (3-tier-architecture)



= Strukturierter Entwurf =

Ein in der Definitionsphase (=Analysephase) erstelltest SA_Modell kann mit Hilfe von Transformationsregeln in eine strukturierte Software-Architektur umgewandelt werden.

Ein '''strukturierter Entwurf''' ist der planvolle, systematische Ansatz, um um zum Entwurf eines geplanten System-Systems zu kommen.

Ziel des strukturierten Entwurfs:
*eine konkrete Software-Architektur zu erstellen die aus hierarchisch angeordneten funktionalen Modulen besteht. Zur Beschreibung des Entwurfs werden Strukturdiagramme und Modulspezifikationen verwendet.

Mit Hilfe des strukturierten Entwurfs entstehen Kriterien zur Beurteilung der SW-Qualität.


== Grundsätze des strukturierten Entwurfs ==

Vorgehensweise:
*Aufteilung in Module
*hierarchische Organisation der Module

=== Aufteilung in Module ===

Ein System wird zunächst in Black Boxes aufgeteilt. Eigenschaften der Blackbox:

*Eingabewerte sind bekannt
*Ausgabewerte sind bekannt
*Die Funktion ist bekannt
*Es ist nicht bekannt wie die Funktion ausgeführt wird.

Vorteile von Systemen, dies aus Black Boxes zusammengesetzt sind:

*einfach aufgebaut
*einfach zu testen
*können einfach repariert werden
*leicht zu verstehen
*leicht veränderbar

Die Einteilung in Black Boxes beim strukturierten Design geschieht nach folgenden Gesichtspunkten:

*jede Black Box löst einen genau definierten teil des Problems
*Die Aufteilung geschieht so, dass dabei jede entstehende Funktion leicht zu verstehen ist.
*Die Verbindung zwischen Blaxk Boxes ist dann sinnvoll, wenn sie einer Verbindung zwischen Teilern der Problemstellung entspricht.
*Die Verbindung zwischen Black Boxes sollte so einfach sein, dass sie unabhängig wie möglich voneinander sind.

Zusammengefasst: Dir Struktur der Aufgabenstellung definiert die Struktur der Lösung und nicht umgekehrt.


=== Organisation in Hierarchien ===

Wie bei hierarchischer Struktur einer Firma: In den oberen Stellen werden Aufgaben wie Planung, Koordination whregenommen während die unteren Stellen die Teilaufgaben erledigen. (Aufgaben werden von oben nach unten delegiert)

== Funktionale Abstraktion ==

Ein funktionales Modul besitzt folgende Eigenschaften:

*Es ist aktiv bzw. aktionsorientiert, d.h. es "tut" etwas.
*Es besitzt ein Transformationsverhalten, d.h. Eingabedaten werden in Ausgabedaten transformiert.
*Identische Eingabedaten führen immer zu identischen Ausgabedaten, d.h. ein funktionales Modul besetzt '''kein''' internes Gedächtnis.

Aufgaben:
*Steuerungs- Koordinationsaufgaben (z.B. Hauptprogramm)
*Transformationsaufgaben (z.B. Compiler)
*Auswertungsaufgaben
*Hilfsaufgaben

=== Modulspezifikation ===

Damit eine funktionales Modul im Rahmen eines Entwurfs eingesetzt werden kann, muss seine Schnittstelle spezifiziert werden:

*Aufgabenbeschreibung
*Eingabeparamater (inkl. Datentyp)
*Ausgabeparameter (inkl. Datentyp)
*evtl. Vorausssetzungen und Vorbedingungen
*evtl. Bedingung die nach der Anwednung geldent
*verhalten bei inkorrekten Eingabewerten oder Fehlfunktion des zugrunde liegenden Basissystems



=== Strukturdiagramm ===

Bestehen aus:
*Rechtecke die funktionale Module darstellen
*Aufruflinien zwischen Rechtecken welche die Aufrufhierarchie festlegen
*Datenpfeile beschreiben die Kommunikation zwischen Modulen


[[Image:Notation-Strukturdiagramm.gif]]

*Der Modulname soll die Funktion des Moduls beschreiben, die si für das rufende Modul erledigt.

Die Datenpfeile werden mit den Namen der aktuellen Parameter beschriftet:
*Ein Pfeil mit weissem Kreis beschreibt eine Datenkommunikation (Daten werden übergeben)
*Ein Pfeil mit schwarzem Pfeil beschreibt eine Status-Information (flag). (z.B. Dateiende). Eine eigentliche Verarbeitung der Information findet nicht wirklich statt.


Bereits vorhanden, zur Wiederverwendung vorgesehen Module werden wie folgt durch Doppellinien an den Rändern gekennzeichnet.



[[Image:Strukturdiagramm-Beispiel.gif]]


=== Entwurf der Modul-Inneren ====

Anschliessen wird das Modul-Innere mittels Pseudocde oder anderen Mitteln den Programmentwurfs im Detail entworfen. Mögliche Mittel:

*Jackson-Diagramm
*Nassi-Shneidermann-Diagramm
*Programmablaufplan

'''Hinweis''': Das Modul-Innere mit einer der genannten Techniker zu entwerfen ist nur bei relativ komplexen Modulen sinnvoll. Ansonsten ist es üblich aus den Vorgaben der MiniSpec direkt eine Funktion oder Teilfunktion zu realisieren.


== Qualitätskriterien ==

Wichtigste Ziele:

*Kopplung zwischen Modulen zu minimieren
*Bindung in Modulen zu maximieren


=== Kopplung ===

Module müssen so unabhängig wie möglich voneinander sein. Gründe:

*geringere Gefahr von Fernwirkungen
*keine Änderungen an anderen Modulen wenn an einem Modul etwas geändert wird.
*interne Details sollen anderen Modulen nicht bekannt sein
*System soll einfach und verständliche bleiben


=== Bindung ===

Bindung ist der Grad der funktionalen Zusammengehörigkeit der Elemente. Für ein gutes Moduldesign muss die Bindung maximiert werden. Jedes Modul soll ein bestimmte Aufgabe erledigen, diese aber komplett.

Ein Modul besitzt '''normale Bindung''' wenn es eine oder mehrere Funktionen umfasst, die inhaltlich eng zusammengehören und die mindestens auf einer gemeinsamen Datenstruktur operieren, die lokale definiert oder explizit als Parameter übergeben wird.

= Modularer Entwurf =

Der modulare Entwurf verwendet neben der "funktionalen Abstraktion" die "Datenabstraktion". Zur Beschreibung des Entwurfs werden Grafiken und Modulspezifikationen verwendet.

=== Datenabstraktion ==

Ein funktionales Modul funktionieren bei jedem Aufruf genau gleich (weil es kein Gedächtnis hat) Dies führt zu einer Reihen von Probleme. z.B. wenn der Seed eines Zufallsgenerator  "geheim" gespeichert werden soll. Lösung: Seed wird im Modul als "private Daten" gehalten.

Wenn in einem Modul Daten gehalten werden, haben wir es mit einer Datenabstraktion zu tun. Wenn das Modul ein Gedächtnis hat, haben wird es mit einem Datenobjekt zu tun. Es lassen sich zwei Grade der Datenabstraktion unterscheiden.

*abstrakte Datenobjekte
*abstrakte Datentypen (ADT)


== Abstrakte Datenobjekte ==

entspricht weitgehend einem Datenobjekt in der objektorientierten Softwareentwicklung

== Abstrakte Datentypen ==

entspricht weitgehend eine Objekt-Klasse


= Entwurf von verteilten Modulen =

bei einer verteilten Architektur läuft eine Funktion in mehreren schichten ab. Es ist daher notwendig diese so in Module aufzuteilen, dass in den Schichten zugeordnet werden können. Die Verteilung muss dabei derart vorgenommen werden, dass für jedes Modul die geeignete Plattform gewählt wird.

'''Hinweis''': Ein Modul sollte nur zu genau einer Schicht gehören. Würde man die Funktionalität mehrerer Schichten in ein einziges Modul packen, würde dies dem Prinzip der losen Kopplung widersprechen.


== Die drei Schichten ==

*Präsentationslogik
*Geschäftslogik
*Datenlogik


=== Präsentationslogik (PL) ===

*Benutzerschnittstelle: GUI, spezielle Ein- Ausgabegerät z.B. Handy
*Systemschnittstellen: automatische Datenübertragungen über Schnittstellen zu anderen Systeme ohne Beteiligung von Benutzern.


=== Geschäftslogik (GL) ===

=== Datenlogik (DL) ===

sorgt für den Zugriff auf persistente Daten. Ebenso kann die Einhaltung der Datenschutz- und Sicherheitskonzepte in Datenlogik-Modulen gekapselt werden.


=== Transaktionslogik (TL) ===
Manchmal wird von einer vierten Schicht gesprochen, der TL. 


== Vorgehensweise ==
Wie können die Module in einer 3-Schicht-Architektur bestimmt werden?

=== Module bestimmen ===

*Im Datenflussdiagramm suchen wir alle Schnittstellenpfeile und zu jedem Schnittstellenpfeil definieren wir ein PL-Modul.
*Im DFD suchen wir alle Pfeile von und zu Datenspeicher; zu jedem Datenspeicher-Pfeil definieren wir ein DL-Modul.
*Den Rest der Logik packen wir in einen GL-Modul


Hinweis: Beim Aufteilen in Module ist darauf zu achten, dass es sich um Module handelt welche bereits an anderer Stelle identifiziert worden sind. Damit wird die Wiederverwendbarkeit angestrebt.



=== Vorgefertigte Module verwenden ===

Die Abwicklung der Transaktionen wird gewöhnlich^von einem Transaktionsmonitor gesteuert. Dieser übernimmt einmal die Kommunikation mit dem Client und anderseits überwacht er die Durchführung der physischen Transaktion auf der DB. Daher kann sich der Anwendungsprogrammierer darauf konzentrieren die Geschäftslogik zu programmieren.


Die '''Geschäftslogik ''' wird gewöhnlich im '''Applikations-Server''' untergebracht. Auf dem Markt angebotene Applikations-Server bieten Dienste an, die Transaktionen koordinieren, die Last verteilen, für Sicherheit sorgen und Web-/GUI-Schnittstellen bedienen. Transaktionssteuerung ist einer der wichtigsten Funktionalitäten, den damit lässt sich die Konsistenz der Daten und Abläufe sicherstellen.



= Entwurf der Benutzerinteraktion =