Software life Cycle (Wasserfallmodell)
Phase Produkt der Phase
Analyse (Probleme finden, Was soll das System tun?)
Spezifikation
Design (Wie soll das System das tun?)
Programmiervorlage
Programmierung, Realisierung
Programm
Test
Testberichte, Mängel Þ besseres Programm
Wartung
Parallel zu diesen Phasen:
Problem: Mehrere Datenbanken in einem Unternehmen können Mehrfachspeicherung von gleichen Daten und somit Redundanzen zur Folge haben, auch wenn jede Datenbank für sich normalisiert ist Þ
unternehmensweites Datenmodell (UDM) = Information Engineering nach James Martin
Unterschied zwischen Software und Information Engineering:
vor der Analysephase kommt die
Planningphase
unternehmensweites Betrachten des Problems
Vergleich:
Information Engineering Städteplaner
Software Engineering Architekt
Programmierer Maurer
Funktionsdekomposition (Aufgabenzerlegung)
Die Funktionsdekomposition dient zur besseren Verdeutlichung der Spezifikation (welche Funktionen sollen enthalten sein?). Es werden die Funktionen Schritt für Schritt verfeinert (Top down) bis das unterste Level der Detailierung erreicht wird. Ist ein Hilfsmittel für die Sezifikation
Zweck:
Nachteile:
Manche Funktionen lassen sich nicht eindeutig zuordnen (z.B. Stundenplan für Lehrer ausdrucken, sowohl zur Lehrerverwaltung als auch Reports drucken)
Kann sehr groß und unübersichtlich werden
Verknüpfung zwischen Daten und Funktionen fehlen (Þ DFD)
Wenn man die Funktionsdekomposition mit den Datenflüssen erweitert (Funktionsdekomposition + ERD) erhält man ein
Datenflußdiagramm
Das Datenflußdiagramm zeigt die Prozesse und den Fluß der Daten durch diese Prozesse.
4 Grundkomponenten:
Datenfluß: Pfeil mit Name darüber, zeigt den Datenfluß durch das System (z.B. Suchergebnis)
Prozeß: Abgerundetes Rechteck (Ellipse) mit Namen des Prozesses (sprechender Name!), Keine andere Information über den Prozeß in Datenflußdiagramm (z.B. Termin planen)
Data Store: Name zwischen zwei waagrechten Strichen, repräsentiert ein lokales File in das entweder Daten eingelesen werden, oder von dem Daten gelesen werden (z.B Schüler)
Terminator: Rechteck mit Namen, Gibt die Herkunft (Source) bzw. den Empfänger (Sink) der Daten an, doch sie werden meistens nicht in die Datenflußdiagramm eingezeichnet (z.B. Benutzer)
Jede Funktion wird auf eine Seite aufgeteilt, es werden alle Datenströme von und zur Funktion eingezeichnet.
DFD für den Prozeß Report: 14128jhb28jxb9f
Ein Datenflußdiagramm zeigt den Datenfluß in einem konkreten Prozeß, der wieder aus mehreren Unterprozessen besteht, die man wieder in eigene Datenflußdiagramm zerlegen kann.
So kann man ein System bis in die tiefsten Ebenen zerlegen. Ein Datenflußdiagramm gibt uns keine Details über die Datenflüsse innerhalb der Unterprozesse, um mehr über diese Datenflüsse zu erfahren, muß für den Prozeß ein eigens DFD erstellt werden.
Die Aufteilung der Diagramme muß konsistent sein, d.h. die Funktion im Unterdiagramm muß genau so viele Zu- und Abflüsse haben, wie das übergeordnete Diagramm.
Hyperdiagramm (in IEF: Repository)
großes Diagramm mit allen Informationen (Funktionen, Tabellen, Beziehungen)
Nachteil: Durch die vielen Informationen zu kompliziert und unübersichtlich (wird nicht gezeichnet) Þ Teilung in Teildiagramme (DFD), entweder Funktionen oder Informationen (Tabellen, Beziehungen) weglassen.
IEF (Information Engineering Facility)
CASE - Tool (Computer Aided Software Engineering): EDV unterstütztes Hilfsmittel für die Erstellung von DFD, ERD, FD.
CDUR - Matrix
PROZESSE / |
|
Schüler |
Lehrer |
FUNKTIONEN |
Schüler suchen |
R |
|
|
|
Klassenb. Blatt 1 |
X |
X |
|
| .
.
. |
|
C |
|
|
Reorganisation |
D |
|
|
|
Versatz |
R/U |
|
nach Stärke geordnet
C ... Create
D ... Delete
U ... Update
R ... Read
oder höchste Stärke
CDUR Þ DFD nicht ableitbar; z.B.: externe Pfeile
CDUR Þ genauer bezüglich Flüsse
Objektorientierte Programmierung
Unterprogramme und Stacks
Der Stack (=Stapel) dient zur Variablen- oder Wertübergabe von einem Programm zu seinem Unterprogramm. Der Stack ermöglicht die Kommunikation zwischen Hauptprogramm und Unterprogramm. Der Stack funktioniert nach dem Prinzip First In Last Out.
PUSH ... ein Wert wird in den Stack geschrieben
PUSH x Þ x wird auf den Stapel gelegt, Stapel wird erhöht
POP ... ein Wert wird aus dem Stack geholt
POP x Þ x wird vom Stapel genommen, der nächste Wert liegt nun oben
y=1;
for (i=1; i<=5; i++) y=y*a; Þ y=a5 Þ y=pot(a,5);
.
.
.
k=1;
for (u=1; u<=7; u++) k=k*z; Þ k=z7
.
.
.
p=1;
for (m=1; m<=4; m++) p=p*s; Þ p=s4
Sobald eine Aktion in einem Programm mehrmals vorkommt, ist es besser stattdessen ein Unterprogramm zu benützen.
long pot (int basis, int exp)
{
int x;
long y=1;
for (x=1; x<=exp; x++) y=y*basis;
return y;
}
Übergabe von Werten:
Call by Value
Call by Reference
( Call by Name )
IMMEDIATE ADDRESSING (unmittelbar) : PUSH 7 (=Call by Value)
DIRECT ADDRESSING (direkt) : PUSH M[1000] (=Call by Reference)
INDIRECT ADDRESSING (indirekt) : PUSH M[M[2000]]
M ... Memory (Speicherstelle)
Beispiel:
int a; a Û 1078 Compiler vergibt die Plätze
int k;
e=pot (a, k); pot Û 50000
|
|
|
|
|
|
|
<HP> |
|
|
|
PUSH M[1090] |
1004 |
k wird auf den Stack gelegt |
|
|
PUSH M[1078] |
1005 |
a wird auf den Stack gelegt |
e = pot(a,k) |
PUSH 1008 |
1006 |
Rücksprungadresse auf Stack |
|
|
JMP 50000 |
1007 |
Sprung zum UP (eigentlicher UP-Aufruf) |
|
|
POP M[1094] |
1008 |
Ergebnis (y) wird nach e geschrieben |
|
|
. |
|
|
|
|
. |
|
|
a |
12 |
1078 |
Direct Addressing |
|
|
... |
|
Immediate Addressing |
k |
2 |
1090 |
|
|
|
... |
|
|
e |
144 |
1094 |
|
|
|
. |
|
|
|
|
. |
|
|
Stack (P1) |
2 / - / 144 / - |
10000 |
Stackbeginn |
(P2) |
12 / - |
|
|
(P3) |
1008 / - |
|
|
|
|
. |
|
|
|
|
. |
|
|
return address |
1008 |
29999 |
|
x |
|
30000 |
|
y |
144 |
30002 |
|
basis |
12 |
30004 |
|
exp |
2 |
30006 |
|
|
|
. |
|
|
|
|
. |
|
|
|
|
POP M[29999] |
50000 |
Rücksprungaddresse von Stack |
|
|
POP M[30004] |
50001 |
a (12) vom Stack nach basis |
|
|
POP M[30006] |
50002 |
k (2) vom Stack nach exp |
UP pot |
... |
|
|
|
|
Schleife |
|
|
|
|
... |
|
|
|
|
|