Das Ziel des Information Engineering ist es, das mehrfache Vorhandensein von Daten, oder Funktionen zu verhindern. Bsp.: Innerhalb eines Betriebes sind die gleichen Daten in verschiedenen Datenbanken gespeichert, und Funktionen wie das Suchen oder Sortieren von Mitarbeitern sind in jedem Programm extra implementiert.
Die Lösung dafür ist eine einheitliche Datenbank für das ganze Unternehmen. Dies beinhaltet:
. UDM ... unternehmensweites Datenmodell
. UFM ... unternehmensweites Funktionsmodell
Das UDM spielt dabei eine bedeutendere Rolle, weil sich Daten langsamer ändern als Funktionen. Z.B.:
Der Unterschied zwischen dem Information Engineering und dem Software Engineering ist, daß das Pflichtenheft des SE durch das Planning ersetzt wird. Nach James Martin unterteilt sich das Information Engineering in folgende Teilgebiete:
1. Planning
2. Analysis
3. Design
4. Constructing
5.1 Planning
Das Planning sollte von vier Mitarbeitern in einem halben Jahr durchgeführt werden können. Ist das nicht möglich, ist es zu fein durchgeführt worden. Das Ziel sollte sein, sich einen Grobüberblick über das Unternehmen zu schaffen.
5.1.1 Unternehmensweites Datenmodell
Das UDM wird vorerst mit entity clusters (subject area) erstellt. Diese werden nach dem Planning in feinere ERDs zerlegt. Bsp.: Der Konzern SHELL hat die entity clusters Fahrzeug, Mitarbeiter, Kunde, Organisation usw.
5.1.2 Unternehmensweites Funktionsmodell
Für das UFM wird eine grobe Funktionsdekomposition erstellt. Im Allgemeinen wird sie soweit durchgeführt, bis keine Funktionen, sondern Prozesse vorhanden sind. Prozesse haben im Gegensatz zu Funktionen einen Anfang und ein Ende.
5.1.3 Organigramm (organisation chart)
5.1.4 Zielfestlegung
Es wird ein Baum aufgebaut, indem Ziele in ihre einzelnen untergeordneten Ziele zerlegt werden:
Andere Ziele sind:
. monetär
. humanitär
. marktorientiert
. produktorientiert
. ökologisch
Kritische Erfolgsfaktoren (critical success factors) sind vom Betrieb unbeeinflußbare, äußere Faktoren, die auf den Betriebserfolg Wirkung ausüben (z.B.: Dollarkurs, Marktsituation, ...):
. Positive kritische Erfolgsfaktoren (facilitators) erleichtern das Erreichen des Betriebszieles
. Negative kritische Erfolgsfaktoren (inhibitors) wirken den Betriebszielen entgegen.
5.1.5 Assoziationsmatrix
Diese werden gebildet, um Verbindungen (Assoziationen) zwischen den vier bekannten Dokumenten (UDM, UFM, Organigramm, Zielfestlegung) herzustellen (CDUR Matrix). In unserem Beispiel ist die Verbindung zwischen Organigramm und Zielfestlegung dargestellt:
Stellen Ziel 1 Ziel 2 Ziel 3 Ziel 4 Ziel 5
Direktor X X
Abteilungsvorstand techn. X
Abteilungsvorstand kaufm.
Werkstättenleiter X X
In diesem Fall würde eine Information Engineering - Software die Fehlermeldungen
. Stellen ohne Ziele
. Ziel 5 wird nicht verfolgt
anzeigen.
5.1.5.1 RAEW Matrix
Sie stellt die Verbindung zwischen den Stellen und den Funktionen dar. In den Zellen werden die Beziehungsarten eingetragen:
. Responsibility (Verantwortung)
. Authority (Autorität, Vollmacht)
. Expertise (Fachwissen)
. Work (Arbeit [in])
Bsp. zur RAEW Matrix für unsere Schule:
Stelle Schülerverwaltung Unterricht Finanzentscheidung
Direktor R RE
Abteilungsvorstand techn. REA EA W
Abteilungsvorstand kaufm. W
Werkstättenleiter EW EW
5.1.5.2 Zerlegungsinkonsistenz
5.2 Affinitätsanalyse
Nach dem Planning stellt sich das Problem, wie das UDM und das UFM zerlegt werden soll. Mit der Affinitätsanalyse wird nun das Gesamtprojekt in verschiedene Einzelprojekte zerlegt.
a(E1) = Anzahl der Prozesse, die die Tabelle E1 benützen
a(E1, E2) = Anzahl der Prozesse, die sowohl E1 und E2 benützen
Affinität von E1 nach E2:
affin(E1, E2) = 0 ... Prozesse gehören in verschiedene Unterprojekte
affin(E1, E2) = 1 ... Prozesse gehören in das selbe Unterprojekt
Bsp.:
E13 E9 0,89
E12 E4 0,87
E9 E4 0,87
E13 E4 0,72
Error! Reference source not found. E13 und E9 werden zu einem E1000 zusammengefaßt, und eine neue Affinitätsanalyse wird durchgeführt. Affinitäten für E1000 werden mittels gewichtetem Durchschnitt berechnet:
In der Software erfolgt die Einstellung der minimalen Affinität zur Zusammenfassung zweier Gruppen folgendermaßen:
Minimum Affinity to merge two groups: ... (z.B.: 0,7)
Nach der Affinitätsanalyse erhält man Projekte. Will man eine bestimmte Anzahl von Projekten, muß man den Faktor danach anpassen. Dann kann man entscheiden, mit welchem Projekt man beginnen soll. Diese Entscheidung kann aufgrund der Projektgröße oder der Wichtigkeit getroffen werden.
5.3 Analysis
In der Analyse erstellt man das Fein - ERD und eine feinere funktionale Dekomposition. Weiters werden Interaktionsanalysen durchgeführt. Die Analysis läßt sich also folgendermaßen unterteilen:
Da die Planning gröbere Daten- und Funktionsstrukturen behandelt, ergibt sich folgende Gliederung für die feine Analysis:
Behandelte Objekte Planning Analysis
Daten subject areas entity types
Funktionen Funktionen Prozesse
5.3.1 Kanonische Synthese (Data Analysis)
Aus Befragungen und der Durchsicht von bereits existierenden Formularen erhält man Datenelemente, die später zu Attributen werden. Im Bubblechart werden alle Datenelemente aufgeschrieben und miteinander verbunden. Dies geschieht indem man die Abhängigkeiten einträgt:
Aus diesem Diagramm entfernt man transitive Abhängigkeiten. Z.B.:
Hinzugefügt wird Intersection Data. z.B.:
Aus dem Bubblechart ergibt sich eine voll normalisierte Datenbank:
Bubblechart Tabelle
E (x, y, z)
E (x, y)
E1 (x, z) und E2 (x, y)
Danach kann man die Datenbank noch denormalisieren, und zwar dann, wenn oft auftretende Joins viel Zeit verbrauchen würden:
normalisiert denormalisiert
A (Mitarbeiter#, Abteilungs#)
B (Abteilungs#, Abteilungsleiter) A (Mitarbeiter#, Abteilungs#, Abteilungsleiter)
Hier kann denormalisiert werden, wenn zu einem Mitarbeiter oft der Abteilungsleiter gesucht werden muß, weil jedesmal ein Join erforderlich wäre.
5.3.2 Prozeßabhängigkeitsdiagramm (Process Analysis)
Der Funktionsbaum gibt keine Auskunft über die Reihenfolge, in der die Prozesse ausgeführt werden. Elementare Prozesse sind funktional kohesiv. Im Prozeßabhängigkeitsdiagramm werden nun die Beziehungen zwischen den Prozessen dargestellt.
Beziehung Darstellung in IEF Beschreibung
A enables B A Error! Reference source not found. B
B kann erst laufen, wenn A beendet ist
X disables Y Ist X abgelaufen kann Y nicht mehr laufen
B1 und B2 können erst laufen, wenn A beendet ist
B1 und B2 schließen einander aus
Daraus kann auch ermittelt werden, welche Prozesse gleichzeitig ablaufen. Das hat besondere Bedeutung bei der Programmierung auf parallelen Rechnersystemen.
5.3.2.1 Ereignisse
Prozesse werden meistens nicht durch andere Prozesse, sondern durch Ereignisse hervorgerufen. Man unterscheidet dabei in externe und zeitliche Ereignisse. Die externen sind vom Programm nicht beeinflußbar, wie z.B. Benutzereingaben. Zeitliche Ereignisse ergeben sich bei bestimmten Zeitpunkten, ein Beispiel hierfür ist das Versetzen von Schülern in den nächsten Jahrgang.
5.3.3 Interaktionsanalyse
Bei der Interaktionsanalyse werden die Zusammenhänge zwischen der Daten- und der Prozeßseite dargestellt. Dazu gibt es folgende Hilfsmittel:
5.3.3.1 ELCA (Entity Lifecycle Analysis)
Bei der ELCA betrachtet man die Objekte, und welche Zustände sie während des Programmablaufes einnehmen können. Weiters ermittelt man die Prozesse, die sie von einem in den anderen Zustand versetzen. Z.B.: Schüler
Aus den Betriebssystemen sind bereits die vier Prozeßzustände bekannt:
z.B.: Mietwagen
Ein weiteres Beispiel wäre eine OSI Schicht 2 Protokollinstanz, die die Zustände
. Sent & Waiting
. Ack receded
. Ack received
einnehmen kann.
5.3.3.2 EVA (Entity View Analysis)
Bei der EVA betrachtet man die Prozesse, mit den Daten, die er erhält, abfragt aber auch liefert:
Bsp. Bestellannahme:
Der Kunde ruft an, und gibt seine Kunden#, die bestellten Produkte und deren Menge an. Ist die Kunden# vorhanden, wird die Bestellung erstellt. Sie beinhaltet die Bestell#, den Gesamtbetrag, und das Datum. Als erstes wird das dafür notwendige ERD erstellt:
Daraus folgen die verschieden Datenflüsse :
Import View: K#
(P#, Stk)*
Mit einem Stern werden diejenigen Attribute versehen, die mehrmals eingegeben werden müssen. In unserem Beispiel kann man ja pro Bestellung mehrere Bestellposten angeben.
Darstellung in IEF:
Gruppe Viewname Entity Attribute
Import
Kunde
K#
Bestellte Posten
Bestellposten
Stk
Produkt
P#
End Bestellte Posten
Export View: B#
GesError! Reference source not found.
Datum
Entity Action View: C: Bestellung
C: Bestellposten *
R: Kunde
R: Produkt
Daraus kann man das Prozeß - Logikdiagramm erstellen, daß aber auch noch keine Auskunft über die Reihenfolge der Ausführung angibt:
A ... Associate (C)
D ... Dissociate (D)
T ... Transfer (U)
5.3.4 Datennavigationsdiagramm (Yourdan, McClure)
Wenn dieses Diagramm erstellt ist, kann die Information Engineering - Software endlich den Programmcode erstellen. In Bezug auf Dr. Dipl. Ing. Mag. Hasitschka endet bereits hier die Analysis, und beginnt das Design. James Martin zieht diese Grenze erst nach dem Action Diagram.
Action Diagram Beschreibung
Anweisungen
Schleife
Verzweigung (If - Klausel)
Verzweigung (CASE Anweisung)
Schleife verlassen, nächster Schleifendurchlauf
gleichzeitige Anweisungen (für Parallelrechner)
Bsp. Bestellannahme:
5.4 Design
Information Engineering - Programme können noch keine Masken erstellen. Die Masken müssen daher vom Entwickler erstellt werden. Formulare die Eventhandler enthält nennt man "Procedure Step" oder Dialog. Man kann mehrere Prozesse in einem Dialog zusammenfassen (Anlegen, Löschen, Ändern). Es können aber auch Prozesse auf mehrere Masken aufgeteilt werden, z.B. aus Platzgründen am Bildschirm.
5.4.1 Dialogflußdiagramm
Hier werden die möglichen Pfade durch die Dialoge festgelegt. Dazu verwendet IEF zwei Arten von Verbindungen:
link flow (Wechsel in beide Richtungen möglich)
transfer flow (Wechsel nur in eine Richtung möglich)
Im Beispiel besteht der Listengenerator Schüler aus zwei Masken, wobei man in die zweite nur über die erste gelangen kann, die Verwaltung der medizinischen Daten ist aber von beiden Dialogen unabhängig:
Bsp. Bestellannahme: Wechsel zur Fehlermeldung, wenn Kunden# nicht gefunden (link flow)
EXITSTATE IS Kunde_Not_Found ... (Maskenwechsel)
.
.
FLOWS ON Kunde_Not_Found
RETURNS ON ...
PROCEDURE STEP
COMMAND ... (was ist mit Daten zu tun)
if COMMAND = . . .
Nach dem Design sind alle Informationen vorhanden, um das Programm erstellen zu können.
5.5 Construction
Im Constructing erfolgt die Umsetzung in den Programmcode. Dazu kann eine Plattform eingegeben werden (z.B.: Oracle). Eine Nachbearbeitung kann aber nur schwer erfolgen, da die Casetools nicht dafür ausgelegt sind (keine sprechenden Variablen usw.). Ein weiterer Nachteil der meisten Casetools ist, daß der Programmcode meisten nicht sehr effizient programmiert ist.
|
