Entwicklung von Anwendungssystemen

1. Einleitung:

- Herausforderungen für die EAS:
- langfristige Strategie; Anlehnung an die Unternehmens- bzw. IV-Strategie
- langjährige Entwicklungsdauer (zum Teil mehrere Jahre)
- AS sind - aufgrund von Anforderungsänderungen im Zeitablauf - sehr wartungsinten- siv
- Interdependenz- bzw. Integrationsbeziehungen zu angrenzenden Aufgaben sind zu berücksichtigen
- Anpassung der AS an neue - technologisch innovative - Hardware
- einheitliche Darstellungs- und Beschreibungsformen müssen die Kommunikation zwi- schen Fach- und DV-Abteilung erleichtern
- Qualität der erstellten AS ist sehr stark von den einzelnen Fähigkeiten und Kenntnis- sen (Skills) der AS-Entwickler abhängig
- Notwendigkeit der Standardisierung
- Notwendigkeit einer detaillierten Dokumentation

2. Ansätze:

- Methoden
- Modelle:
- Meta-Modelle
- Architektur-Modelle
- konventionelle Ansätze:
- Funktionsorientierung
- Datenorientierung
- neuerer Ansatz:
- Objektorientierung
- Geschäftsprozeßorientierung
- Funktionsorientierung:
- Ziel: Komplexitätsreduktion
- Zerlegung in Teilfunktionen durch Top-Down, dann Zuordnung der Daten Problem: separate Betrachtung von Daten und Funktionen führt zu Redundanzen
- Datenorientierung:
- Ziel: Sammlung und Betrachtung der im Betrieb anfallenden Daten Problem: Vernachlässigung der betrieblichen Funktionen LÖSUNG: Kombination von Funktions- und Datenorientierung
- Objektorientierung:
- Kapselung von Daten und Methoden
- Klassifizierung gleichartiger Objekte (Klassen)
- es wird versucht, drei Aspekten zu begegnen:
- gemeinsame Betrachtung von Daten und Funktionen
- einfacherer Übergang von der fach- zur DV-technischen Umsetzung
- einfachere Wiederverwendbarkeit der Objekte (Klassenbibliothek)
- Geschäftsprozeßorientierung:
- Betrachtung von Funktionsabläufen bzw. Prozessen
- Jeder Prozeß hat einen Auslöser (Anfangspunkt) sowie einen Endzustand (Endpunkt)
- Geschäftsprozeß (synonym: 'Vorgang')
- sequentielle oder parallele Anordnung von Funktionen
- Ergebnisse -> Ereignisse, Aktivitäten -> Funktionen
- unterschiedlicheUntersuchungsrichtungen
- Zweck von Funktionen
- Reihenfolge von Funktionen
- Schnittstellenbetrachtung (Medienbrüche) organisatorische Analyse
- Geschäftsprozeßorientierung als Ausgangsbasis der fachlichen und DV-Konzeption
- Wiederholbarkeit und (Teil-)Standardisierung als Voraussetzung
- Kritik:
- Überbewertung der IST-Analyse
- wie weit soll die Geschäftsprozeßorientierung gehen?

3. Vorgehensweisen:

- zwei Vorgehensweisen:
- Phasenkonzepte
- Prototyping
- Phasenkonzepte:
- teilen den Projektablauf bei der Gestaltung von AS in einzelne Schritte ein
- Ziele:
- besserer Überblick über das Gesamtprojekt
- Ergebniskontrolle nach jeder Phase
- Zuordnung von Ressourcen und fachlichem Know-How
- der grundsätzliche Aufbau der Phasenkonzepte ist ähnlich
- Phasen:
- Planung:
- Ziele und Ablauf definieren
- Frage: lohnt sich das Projekt?
- Definition:
- Aufwand für das Projekt nimmt zu
- fachliche Anforderungen werden definiert
- IST-Erhebungen
- Aufgabenanalyse
- Schwachstellenanalyse
- Ergebnis: Pflichtenheft (wird von der Fachabteilung abgenommen)
- Entwurf:
- Fachentwurf
- Festlegung der Module, Schnittstellen, Datenspeicherung
- Ergebnis: vollständig dokumentierter fachlicher und DV-technischer Entwurf
- häufig mangelt es am detaillierten fachlichen und technischen Entwurf
- der meiste Entwicklungsaufwand sollte hier bereits erledigt sein
- Implementierung/Codierung:
- kann von Programmierern übernommen werden
- Abnahme und Einführung:
- umfangreiche Tests (Module und Integration)
- werden die fachlichen Anforderungen erfüllt?
- fachliche und technische Abnahme
- Wartung:
- sehr wichtige Phase
- die meisten in der betrieblichen Praxis angewendeten Systeme sind 6-8 Jahre alt
- Kritik:
- Beteiligung der Fachabteilung ist bei einer idealtypischen Betrachtung nach der Defi- nitionsphase eigentlich bis zur Abnahmephase nicht vorgesehen. was passiert in einer dynamischen Umwelt?

Mitarbeiter der Fachabteilung sind evtl. nicht mehr im Unternehmen
Möglichkeit: stärkere Integration der Fachabteilung in alle Phasen

- Unvollständigkeit oder Fehlerhaftigkeit wird vielleicht erst am Ende bemerkt

Möglichkeit: bessere Ergebniskontrolle und Rückverzweigungen

- Information Engineering:
- Strategie:
- ausgehend von den allgemeinen Unternehmenszielen wird gefragt, welche strate- gischen Potentiale mit der IV erreicht werden können
- Analyse:
- Top Down- Analyse (Geschäftsprozesse)
- Design:
- Systementwurf
- Umsetzung der Prozesse in Module
- Konstruktion:
- Umsetzung in lauffähige Programme durch Programmgeneratoren
(die Wartungsphase wird nicht explizit berücksichtigt und ist zu ergänzen) - Methoden und Werkzeuge:
- Strategie:
- Hierarchiegraphen
- Eigenschafts- und Beziehungsmatrizen
- Analyse:
- Datenflußplan
- ER-Diagramme
- Funktions- und Aktionsdiagramme
- Design:
- Modulaktionsdiagramme
- Datei- und Datenbankschemata
- Datenstrukturdiagramme
- Struktogramme
- Benutzungsoberflächen- und Listengeneratoren
- Konstruktion:
- Generatorwerkzeuge (Vergleich Phasenkonzept <-> Information Engineering)
- Prototyping:
- verzichtet auf ein vollständiges fachliches und DV-technisches Konzept
- direkte Involvierung der Projektbeteiligten
- möglichst schnelle Erstellung eines ersten Prototypen
- Beschränkung auf die wesentlichen, relevanten Funktionen
- das vollständige AS wird sukzessive mit der Fachabteilung auf der Basis des Prototy- pen konzipiert
- Spiralmodell
- zwei Arten von Prototyping:
- evolutionäres Prototyping
- experimentelles Prototyping (rapid prototyping)
- Vorzüge:
- Anwender ist permanent in den gesamten Entwicklungsprozeß eingebunden
- Benutzerwünsche können besser berücksichtigt werden
- Änderungsaufwand am Ende eines Projektes sollte sich vermindern
- Grenzen:
- Spaghetticode
- wie soll die Dokumentation erfolgen?
- wie kann man vermeiden, wichtige Aspekte zu vergessen?
- viele Detaildiskussionen notwendig erfordert gute Koordination und strenge Füh- rung
- Vorgehen verleitet, gegen Unternehmensstandards zu verstoßen
- Möglichkeiten der Kombination von Phasenkonzepten und Prototyping:
- Entwicklung von Prototypen in den einzelnen Phasen

4. Werkzeuge:

- Zweck: Unterstützung und Beschleunigung von Entwicklungsprozessen
- Vorteile:
- Zurückgriff auf Bausteine
- Überprüfung formaler (nicht semantischer oder betriebswirtschaftlicher) Korrekt- heit
- Erstellung verschiedener Sichten auf das Modell
- projektbegleitende Dokumentation
- Grenzen:
- keine Vollautomatisierung
- keine Unterstützung inhaltlicher Korrektheit
- (mächtige) Werkzeuge setzen Fähigkeiten und Kenntnisse voraus
- Klassifikation:
- Data Dictionary (Implementierung, Abnahme/Einführung, Wartung)
- Verzeichnissystem
- Informationen über die Struktur, Verwendung und Eigenschaften der Daten
- Enzyklopädie (Repository)
- erweitert das Data Dictionary
- sämtliche Ergebnisse des Entwicklungsprozesses werden abgelegt (auch Funktionensicht etc.)
- Programmeditoren, Testhilfen, Debugger, AS-Generatoren
- Lower Case Tools (Implementierung, Abnahme, Betrieb) codenah
- Upper Case Tools (Planung, Definition, Entwurf)
- Integrated Case Tools (I-Case) für alle Phasen
- KEY
- I-Case Tool
- Information Engineering als Grundlage
- 4 Workstations:
- Planning
- Analysis
- Design
- Construction
- Rapid Application Development Workstation (für Prototyping)
- Enzyklopädie (implementierte Modelle werden abgelegt)
- Module abhängig von der Plattform (Mainframe, PC, AS400)
- Documentation Workstation
- Rational Rose
- für Objektorientierung (OMT)
- I-Case Tool
- Schwerpunkt auf der fachlichen und DV-technischen Konzeption
- Realisierung: Codegenerator und Data Description Language (DDL) Generatoren
- 3 Komponenten:
- Enzyklopädie
- Software Documentation Automation (SoDa)
- Rational Visual Test
- ARIS
- für Geschäftsprozeßorientierung
- Architektur Integrierter Informations Systeme
- 3 Schichten:
- Funktion
- Daten
- Steuerungsschicht
- übergeordnet: Organisationsschicht
- Ebenen: Fachkonzept-, DV-Konzept- und Implementierungsebene

5. Planung:

- Ausgangspunkt für den Gesamtentwicklungsprozeß
- 'Generalbebauungsplan'
- Was sind die Kernziele?
- Welche AS können unterstützend wirken?
- Auf welcher Architektur liegen die AS auf?
- langfristige Planung (3-5 Jahre)
- 2 Methoden:
- Business Systems Planning (IBM, 60er Jahre)
- Information Engineering
- Business Systems Planning (s. auch Biethahn)
- möglichst hohes Engagement für ein Planungsprojekt
- aktive Mitarbeit der Unternehmensführung
- Einbindung von 2-3 Mitarbeitern aus Fremdunternehmen als Moderatoren oder Projektleiter
- Planungsaufgaben erfordern gute Mitarbeiter
- zur Datenerhebung werden aus den Fachabteilungen Interviewpartner benötigt
- es werden nicht sämtliche Geschäftsprozesse analysiert (normal: 20-60 Prozesse)
- Kern- (Produkt und Service) und Unterstützungsprozesse (Porter'sche Wertschöpfungskette)
- 'Planungs- und Kontrollprozesse' oder 'Planungs- und Kontrollaufgaben'??
- Ausgangspunkt 'Prozeß-Organisationseinheit'-Matrix
- wer ist wie stark an welchem Prozeß beteiligt?
- 'System-Organisation'-Matrix zeigt die aktuelle und zukünftig geplante IV-Unterstützung
- Kern: 'Prozeß-Datenklasse'-Matrix
- Schrittweises Klassifizieren und Verfeinern
- Umorganisation, damit viele 'C's auf der Hauptdiagonalen liegen
- Pfeile, die nach unten rechts in Richtung der Hauptdiagonalen verlaufen, sind Daten, auf denen aufgebaut wird
- Rückbezügliche Pfeile nach links oben in Richtung der Hauptdiagonalen deuten auf vergangenheitsbezogene Daten der Vorperiode
- Ergebnis: welche IS werden in welchem Umfang benötigt?
- Vorzüge:
- gut formalisiert und standardisiert
- vielfach praktiziert
- in vielen Handbüchern dokumentiert
- einfache Verständlichkeit der Matrizen
- es gelingt eine gewisse Abgrenzung und Zuordnung der IS vorzunehmen
- Grenzen:
- möglicherweise hoher Durchführungsaufwand
- Mitgliederschulung erforderlich
- Fähigkeiten und Kompetenzen zur Strukturierung notwendig
- wird nur Existierendes abgebildet und nicht kritisch hinterfragt?
- Information Engineering
- es wird ebenfalls viel mit Matrizen gearbeitet
- Kern: Darstellung der Aufbauorganisation, Darstellung von Funktionen und Prozessen oder Aufzeigen von Datenobjekten
- Was sind die Unternehmensziele und die Prozesse, die dazu beitragen?
- Welche kritischen Erfolgsfaktoren bestimmen den Geschäftserfolg am meisten?
- Welches sind die Ziele der IV?
- Welche Infos braucht das Management?
- Wo fallen die Infos an?
- Wo laufen die Prozesse ab?
- Weitere Modelle:
- Analyse der kritischen Erfolgsfaktoren (s. Biethahn)
- Portfolioanalysen (s. Biethahn)
- Customer Resource Life Cycle (CRLC):
- Wie kann ich die DV einsetzen, um mir selber einen Wettbewerbsvorteil zu beschaffen?
- Verbesserung der Kundenbeziehungen zur engeren Kundenbindung
- Fragen von 'Wie erwecke ich Bedarf?' bis 'Wie unterstütze ich den Kunden beim Recycling?'
- Strategic Value Analysis:
- 10 Ablaufschritte, reichen in die fachliche Konzeption hinein
- von der Identifizierung bis hin zur Implementierung
- Kern: Geschäftsprozeßmodellierung
- umfassender als BSP, daher auch höherer Aufwand
- Werkzeuge (Beispiel KEY)
- Hierarchiediagramme (Decomposition Diagrammer)
- Organisationsstrukturen
- Aufgaben oder Funktionen
- Daten
- sowohl Top Down als auch Bottom up
- Property Matrix Diagrammer
- für BSP
- Beispiel: Eigenschaftsmatrix für Elementtyp Unternehmensziel
- Association Matrix Diagrammer
- Kontext von Verknüpfungen zwischen den Elementen zweier Elementtypen
- Entity Relationship Diagrammer
- für Datenmodellierung

6. Fachkonzept - Geschäftsprozesse:

- nicht nur individuelle, sondern auch Standardsoftware
- Welche relevanten Aufgaben oder Funktionen sollen mit der Software abgebildet werden?
- Wie sind die Daten und Funktionen miteinander verknüpft?
- Datensicht: Informationslebenszyklus (create, delete, use, update...)
- es wird nur ein Ausschnitt des Unternehmens analysiert
- Geschäftsprozeßmodellierung als Ausgangspunkt
- darauf aufbauend Daten- und Funktions- oder Objektmodellierung
- Prozeß: Folge einer oder mehrerer sequentiell oder parallel ablaufender Funktionen
- Synonym: Vorgang
- Ausgangspunkt und Endzustand sind Ereignisse
- Zweck, Reihenfolge, Schnittstellen, Organisationseinheiten
- wesentliche Merkmale: Wiederholbarkeit und (Teil-)Standardisierung
- Zielsetzung:
- Organisationsstruktur
- Funktionsunterstützung durch IV?
- Ereignisgesteuerte Prozeßketten (EPK)
- drei Methodenelemente
- Funktionen
- Ereignisse (Ausgangspunkt, Endzustand, Trigger, Ergebnis)
- Operatoren (xoder, oder, und)
- auch Organisationseinheiten, Input/Output-Daten, Ressourcen oder Informationsträger können dargestellt werden; diese werden schrittweise eingesetzt, mit entsprechenden Werkzeugen kann zwischen den Sichten gewechselt werden
- Modellierungsregeln für EPK

1. Ausgangspunkt und Endzustand sind ein oder mehrere Ereignisse
2. Funktionen und Ereignisse sollten den gleichen Abstraktionsgrad aufweisen
3. Verzweigungen können am Ende einer Funktion oder eines Ereignisses modelliert werden

- xoder/oder-Operatoren müssen an Funktionen anknüpfen
- und-Operator kann auch an Ereignisse anschließen
- Zusammenführung benötigt den gleichen Operator wie die vorhergehende Verzweigung

4. Eine Zusammenführung, auf die unmittelbar wieder eine Verzweigung folgt, wird
durch aufeinanderfolgende Verknüpfungsoperatoren abgebildet

5. Komplexere Zusammenführungen können ebenfalls durch aufeinanderfolgende Ver-
knüpfungsoperatoren abgebildet werden

Je komplexer die Strukturen, desto fehleranfälliger die Organisation des Ablaufs

- Weitere Methoden
- Petri-Netze
- Beschreibung, Analyse und Simulation von Prozessen
- Workflow-Modelle haben häufig auf den Petri-Netzen basierende Implementierungen
- Elemente: Ereignisse (Kreise), Transitionen (Rechtecke), Verbindungen (Pfeile)
- Nachteile:
- aufwendige Methode
- kann zu Unübersichtlichkeiten führen
- Semantische Objektmodellierung (SOM)
- systemtheoretische Sichtweise
- 3 Modellebenen:
- Unternehmensplan (Aussensicht, legt Ziele fest)
- GP (bilden die Innenansicht)
- AS-Ebene (Ressourcen der GP werden dargestellt und implementiert)
- 3 Sichten:
- Leistungssicht
- Lenkungssicht
- Ablaufsicht
- 2 Diagramme
- Interaktionsschema (Leistungs- und Lenkungssicht)
- Vorgangs-Ereignis-Schema (Ablaufsicht)
- Nachteile:
- setzt Systemdenken voraus
- es können Kommunikationsprobleme mit der Fachabteilung entstehen
- geht über die reine Sicht der GP hinaus
- relativ aufwendig
- Vorgehen bei der GP-Modellierung
- Ausgangspunkt:

1. Interviews
2. Aktenstudien
3. Dokumentationen
4. Selbstaufschreibungen

- Vorgehensweise
- Auslöse-Ereignisse identifizieren (extern und/oder intern und/oder periodisch)
- Funktionen und Ergebnisse identifizieren
- Endereignis identifizieren

schrittweise Detaillierung

Berücksichtigung besonderer Sachverhalte Betrachtung von Interdependenzen

Vermeidung von überflüssigen Funktionen

- GP aus AS-Sicht
- Geschäftsprozeß zeigt Soll-Modell
- welche Organisationseinheiten sollen unterstützt werden?
- welche Ergebnisse sind wichtig?
- welche Informationsträger werden zur Speicherung eingesetzt?
- welche Funktionen bestehen zu anderen Funktionen und/oder GP?
- ARIS zur GP-Modellierung
- Windows-Oberfläche
- kann in einer Enzyklopädie hinterlegt werden
- Top Down können EPK deklariert werden (zunehmender Detaillierungsgrad

7. Fachkonzept - Datenmodellierung:

- Welche Daten werden für betriebswirtschaftliche Fragestellungen benötigt?
- hohes Automatisierungspotential durch Werkzeugunterstützung
- Vorgehen

1. Erarbeiten und Ableiten des Datenmodells aus der Unternehmensrealität
2. Überführung des konzeptionellen Datenmodells in die Notation eines sog. logischen Datenmodells
3. Überführung des logischen Datenmodells in die Beschreibungssprache eines Daten-
banksystems

- es werden nur die relevanten Daten abgebildet, die übergreifend notwendig sind
- Daten <-!-> Funktionen
- Datenmodellierung basiert auf dem ERM
- Das Entity-Relationship-Modell
- Entitytyp: reales oder abstraktes Informationsobjekt mit eigenständiger Bedeutung (Kunden, Lieferanten, Aufträge, Produkte o.ä.)
- Entity: konkrete Ausprägung eines Entitytypen (Kunde (Entitytyp) --> Herr Meier (Entity))
- Attribute: Eigenschaften von Entitytypen, charakterisiert einen Entitytypen (Kunde: Name, Adresse etc.)
- konkrete Attributwerte kennzeichnen ein Entity
- Primärschlüsselattribut: z.B. eindeutige Kundennummer
- Relationshiptypen: Beziehungen zwischen Entitytypen
- Kardinalitäten von Relationshiptypen:
- 1:1 zu jedem Entity des Entitytypen eins gehört genau ein Entity des Entitytyps 2
- 1:N z.B. Kunde erteilt genau einen oder mehrere Aufträge
- M:N z.B. ein Auftrag enthält mehrere Artikel, einer oder mehrere Artikel können in einen Auftrag eingehen
- hängen von der Leserichtung ab
- viele Freiheitsgrade und Interpretationsmöglichkeiten
- Kardinalitäten sind diskussionswürdig (sollen Einschränkungen gemacht werden?)
- Beziehungen (Kanten):
- 0:1 -> einfacher Strich
- 0:* -> Strich mit Pfeil oder Strich mit Kästchen
- 1:* -> Doppelstrich mit Pfeil oder Doppelstrich mit Kästchen
- 1:1 -> Doppelstrich
- Regeln:
- Sartknoten liegt links vom Endknoten
- zwischen zwei Knoten können mehrere Kanten modelliert werden
- R-Typ darf kein Startknoten sein
- Zielknoten kann kein E-Typ sein
- ein R-Typ muß Zielknoten von mindestens zwei Kanten sein
- Erweiterungen des Modells
- (min,max)-Notation (minimax) soll zur Klarheit beitragen - Erhebungsmethoden
- der Entitytyp Zeit wird häufig vernachlässigt, ist jedoch von entscheidender Bedeu- - Dokumentenstudium bzw. Formularanalyse tung - Selbstaufschreibung
- Zeit als Attribut - Interviews und Befragungen
- Zeit wird der Relationship zugeordnet - Referenzmodelle
- Zeit als Entitytyp (z.B. Angebot wird Beziehungstyp zwischen Lieferant und Zeit)
- Generalisierungskonzept - Werkzeuge am Beispiel von KEY
- Generalisierung: Mitarbeiter -> Entitytyp Angestellter und Entitytyp Arbeiter - Entity Relationship Diagrammer
- Uminterpretation von Beziehungstypen - Definition von Entitytypen und Beziehungstypen
- Beispiel: Angebot als Beziehungstyp oder als Entitytyp - Entitytypen können neu erstellt oder auch - falls bereits vorhanden - gesucht werden
- Strukturiertes Entity Relationship Modell (SERM) nach SINZ - Entity Type Description: Attribute und Primärschlüssel
- Uminterpretationen bedeuten semantische Mehrfachbedeutung - Entitytypen:
- im SERM wird dafür ein eigenes Symbol eingeführt - Fundamental: eigenständiger Entitytyp
- Existenzabhängigkeiten sind im konventionellen Modell nur schwach zu erkennen - Attributive: beschreibt einen anderen Entitytyp (z.B. Preis beschreibt Produkt)
- Existenzabhängigkeiten sollen stärker Berücksichtigung finden - Associative: Verknüpfungen von Entitytypen (Auftragsposition -> Verknüp- Schwierigkeiten bei der Interpretation -> Leserichtung fung Auftrag und Artikel)
- eindeutige Leserichtung soll ermöglicht werden - Relationshiptypen:
- drei Objekttypen: - können erstellt oder auch - falls bereits vorhanden - gesucht werden
- E-typ - 'From To' und 'To From' beschreiben die Richtung
- ER-Typ (neu!) - Zoomen ist möglich
- R-Typ
- Multytyping
- Supertype
- Klassifikation (Covering, Non-Covering, Exklusive. Inclusive)
- Subtypes ergeben das Subtype Set

8. Fachkonzept - Funktionsmodellierung:

- Verarbeitungsabläufe werden analysiert
- Ziel: Top Down --> sukzessive Zerlegung der Gesamtaufgabe in einzelne überschaubare Teilaufgaben (Komplexitätsreduzierung)
- programmiersprachenähnliche Beschreibungstechniken (DFD)
- Elemente der Strukturierten Analyse
- Funktion:
- Transformation der Eingabedaten zu Ausgabedaten
- wird im DFD durch Ellipsen dargestellt
- Datenspeicher:
- temporärer Aufenthaltsort für Daten (Zwischenspeicherung)
- wird im DFD durch zwei parallele Striche dargestellt
- Elemente der Systemumwelt (externe Agenten):
- werden im DFD durch Rechtecke dargestellt
- Datenfluß:
- wird im DFD durch einen Pfeil dargestellt
- DFD Hierarchiemodell:
- Kontextdiagramm:
- oberste Abstraktionsebene
- Beziehungen zwischen Gesamtfunktion 0 und externen Agenten
- DFD der Funktion 0
- DFD bspw. der Funktion 3
- Pseudocode der Elementarfunktion 3.1 (unterste Abstraktionsebene) Dekompositionsdiagramm
- Formale Regeln der Strukturierten Analyse

1. selbstsprechende Bezeichnungen (Substantiv + Verb)

- Darstellung soll personenunabhängig selbsterklärend sein

2. Voranstellen von Ziffern

- Hierarchieebene wird deutlich
- Teilbereich wird deutlich
- Funktionen mit übergeordneten Funktionen lassen sich aufzeigen

3. Datenflüsse sollten ebenfalls selbstsprechende Bezeichnungen und den Status enthalten sowie evtl. Datenquelle und -Senke

4. eindeutige Bezeichnung der Datenspeicher

- Inhaltliche Regeln

1. Externe Agenten tauchen nur im Kontextdiagramm auf
2. Datenspeicher verwendungsnah eingezeichnet führt zu Redundanzen
Datenspeicher auf höherer Hierarchieebene machen zusätzliche Datenflüsse notwen-
dig
projektspezifisches Abwägen
3. max. 3 Datenflüsse zwischen zwei Elementen
4. jeder Datenfluß müssen mit mindestens einer Funktion in Verbindung stehen

5. Datenspeicher müssen einen zu- und einen abfließenden Datenfluß mit identischer Bezeichnung aufweisen

- Gestaltungstips

1. maximal 5 Teilfunktionen einer Funktion (+-2)

2. maximal 6 Hierarchieebenen

- SADT als Variante der Funktionsmodellierung
- Structured Analysis and Design Technique
- relativ lang eingesetztes Verfahren
- Höhepunkt in den 80ern, heute kaum noch Verwendung
- zwei Sichten
- Funktionen (Aktigramme)
- Daten (Datagramme)
- einfache Darstellung und gute Dokumentation
- Nachteil: keine Zeitabbildung
- Erhebungsmethoden
- Analyse der IST-Situation
- Schwachstellenanalyse und -beseitigungskonzepte
- starke Orientierung an bestehenden Abläufen
- kann zu noch komplexeren Gebilden führen
- Analyse von Ereignissen
- Ähnlichkeit zur GP-Analyse
- Tätigkeitsbeschreibung
- externe, interne oder periodische Ereignisse?
- Entitytypen können differenziert werden
- Typisierung der Funktionsstruktur
- Datenverwaltung, Steuerung oder Datenmaterialauswertung?
- Analyse von Unternehmensebenen
- Top Down ausgehend von der Unternehmensfunktion
- Gliederung in Fachgebiete oder Funktionen
- Abläufe, Ressourcen
- Identifikation von Elementarfunktionen
- sollen in sich ein vollständiges Ergebnis liefern
- Wertverändernde Operationen sollten innerhalb einer Elementarfunktion nur auf einem Datenobjekt ausgeführt werden
- eine Elementarfunktion muß unabhängig ausführbar sein
- halbe bis ganze DIN A4-Seite
- Einsatz von Rerferenzmodellen
- Vorlagen, vordefinierte Strukturen
- höherer Änderungsaufwand als bei der Datenmodellierung in der Praxis werden die Methoden häufig gemischt
- Werkzeuge am Beispiel von KEY
- Decomposition Diagrammer:
- Beschreibung von Funktionshierarchien
- Zoomen möglich
- Suchen von Funktionen möglich
- direkte Modifikation möglich
- Dataflow Diagrammer
- unterstützt DFD
- Minispec Action Diagrammer
- unterstützt das Erstellen von Pseudocode für Elementarfunktionen
- mit Compiler direkte Übersetzung in Programmiersprache möglich

9. Fachkonzept - Integration Daten/Funktionen:

- Zerlegung des Funktionsbereiches in Teilfunktionen
- DFDs und Datensichten für die Teilfuntionen werden spezifiziert und zusätzliche Entitybeschreibungen hinzugefügt einseitige Betrachtung soll vermieden werden
- Integriertes Modell: Vorgehensweise

1. Initialisieren eines Modells für die fachliche Konzeption eines AS (funktions-
orientiert)

- Beschreibung der Wurzelfunktion

2. Anlegen eines (groben) Bereichsdatenmodells (datenorientiert)

- keine Details

Schritte 3 und 4 werden bis zum gewünschten Detaillierungsgrad zyklisch durchlaufen

3. Hierarchieebenen definieren (funktionsorientiert)

4. Grobe Datenanalyse der Teilfunktionen

5. Aktionsdiagramme für die Elementarfunktionen festlegen

6. Detaillierte Datenanalyse der Elementarfunktionen durchführen

7. Detaillierte Datenanalyse aller Hierarchieebenen durchführen

- Bottom Up

8. Modellprüfung durchführen

- Gültigkeit von Datenflüssen
- Datenkonsistenzanalyse
- Objektlistenfunktion
Rücksprünge sind möglich

- Werkzeuge am Beispiel von KEY

1. Topfunktion mit Decomposition Diagrammer
2. Property Matrix Diagrammer, ER-Diagrammer, Entity Type Description
3. Decomposition Diagrammer
4. Data Flow Diagrammer, ER-Diagrammer
5. Minispec Action Diagrammer
6. ER-Diagrammer, Entity Type Description
7. (wie 6)
8. Connectivity Analysis, Data Conservation Analysis, Object Summary Report

- Regeln
- Minimierung der Schnittstellen zwischen zwei Teilfunktionen
- Ablauf- und objektbezogene Funktionsstruktur

10. Fachkonzept - Objektmodellierung:

- sowohl Daten als auch Funktionen müssen erfaßt werden
- Funktionen werden in der OM als Methoden bezeichnet
- Kapselung: Zusammenfassen von Daten und Methoden innerhalb eines Modells zur Abbilden der betrieblichen Realität es wird nur noch ein Modell benötigt
- Klassen fassen Objekte mit gleichen Eigenschaften zusammen (Pendant bei Datenmodellierung: Entitytyp)
- Die Objekte sind dann Instanzen von Klassen
- Vererbung (Inheritance): Definitionen für Oberklassen sind automatisch auch für die Unterklassen definiert
- Mehrfachvererbung (Multiple Inheritance): eine Unterklasse kann Eigenschaften mehrerer

Oberklassen erben es ergeben sich netzwerkartige Strukturen

- Mehrfachverwendung: es können aus bestehenden Klassen neue Klassen gebildet werden
- Mitteilungen (Messages)
- Senderobjekt --> Empfängerobjekt
- wenn es möglich ist, daß dieselbe Nachricht an unterschiedliche Objekte gesendet

werden kann und dort jeweils unterschiedliche Methoden (gleichen Namens) auslöst, spricht man von Polymorphismus.

- Modellierungsregeln
- Klassen sollen Abstraktionen der Inhalte des AS sein.
- Alle für das AS relevanten Attribute und Methoden müssen in mindestens einer Klasse enthalten sein.
- Klassenbildung dient der Kapselung zusammengehöriger Methoden und Attributen.
- Die Attribute und Methoden einer Klasse sollten so gewählt sein, daß sie für fast jedes der Objekte relevant sind.
- Die Zahl der Klassen und ihrer Vererbungsbeziehungen muß sich in Grenzen halten.
- Eine Klasse darf nicht vollständig in einer anderen enthalten sein.
- Klassifizierung existierender Analysemethoden

1. objektbasiert
2. klassenbasiert
3. objektorientiert (Objekte, Klassen, Vererbung)

- Object Modelling Technique (OMT)
- OMT baut im Kern auf bewährt konventionellen Modellen auf (ERM, DFD)
- Es wird neben der fachlichen auch die DV-technische Konzeption unterstützt, Übergang soll einfach gestaltet sein.
- Objektmodell
- graphische Notation --> Klassendiagramm
- Name, Attribute, Methoden
- Beziehungen: Assoziation, Aggregation, Generalisierung
- Dynamikmodell
- beschreibt das Verhalten des AS im Zeitablauf
- zwei Notationen:
- Zustandsdiagramm
- Ereignisdiagramm
- Funktionsmodell
- Bereichsanalyse
- was sind die Gegenstände bzw. Objekte?
- betrachtet das Untersuchungsgebiet allgemein
- CRC (Classes, Responsibilities, Collaborations)
- Anlegen von Karteikarten
- beschreibt auf konventionelle Weise die Funktionalität - Werkzeuge am Beispiel Rational Rose (s. Planung)
- Notation --> DFD - Class Diagrams stellen die Klassendiagramme dar
- State Diagrams bilden die Zustandsdiagramme
- Vorgehensweise der OMT - Message Trace Diagrams beinhalten die Ereignisdiagramme

1. Objektmodell erstellen - Object Message Diagrams entsprechen den DFD

- Identifizieren von Objekten und ihren Klassen
- Data Dictionary für Klassen erstellen
- Assoziationen identifizieren 11. DV-Konzept - Allgemeines zu DB
- Generalisierungen ermitteln 1. Wo und wie sollen die Daten abgespeichert werden?
- Aggregationen identifizieren 2. Wie bilde ich die Funktionalität ab (Verarbeitungsmodule)?
- Überprüfung des Objektmodells durch Simulation und Gruppierung von Klassen 3. Wie konstruiere ich die Benutzungsschnittstelle?

zu Modulen.

2. Dynamikmodell erstellen - Datenspeicherung in DB

- Abläufe und Dialoge zwischen Anwender und AS sind vorzubereiten - Anforderungen:
- Ereignisdiagramm erstellen - schneller Datenzugriff
- Zustandsdiagramm erstellen - hohe Datensicherheit

3. Funktionsmodell erstellen - Datenbestände sollen von vielen Funktionen (auch potentiellen) benutzt werden

- Ein- und Ausgabewerte des AS bestimmen können
- DFD erstellen - Aktualität
- Funktionen detailliert - z.B. mit Pseudocode - beschreiben - Konsistenz

4. Überprüfung und ggf. Überarbeitung bzw. Verfeinerung - sparsamer Umgang mit physischem Speicherplatz (verliert bei den heutigen Preisen immer mehr an Bedeutung)

- Erhebungsmethoden - Aufbau Dateiorganisation:

- Grammatikalische Untersuchung des Pflichtenheftes - Datei -> Datensatz -> Datensatzfelder

- Substantive bilden Klassen, Verben sind Methoden - Schema der Dateiorganisation (getrennte AS mit getrennten Dateien)

- keine besonders elegante Methode(!) verursacht Redundanzen und Inkonsistenzen
- Aufbau Datenbankorganisation:
- Datenbankverwaltungssystem
- Datenbank selbst kann in einzelne physische Komponenten zerlegt sein (interne Sicht)
- Den Anwendungssystemen werden logische Dateien vom DBVS zur Verfügung gestellt (Sichten)
- Aufbau eines Datenbanksystems
- unterste Ebene:
- Speichermedien
- Ebene des DBVS:
- interne Ebene (Sprache: DSDL - Data Storage Description Language)
- konzeptionelle Ebene (Sprache: DDL - Data Description Language --> Beispiel

ERM als Quasi-Standard-Entwurfssprache)

- Externe Ebene(Sprache: DML - Data Manipulating Language --> Beispiel: SQL)
- Auf der obersten Ebene sind die Benutzer, die entweder über ein AS oder direkt auf das DBVS zugreifen
- Zwischen den einzelnen Ebenen des DBVS übernehmen Transformationsregeln den

Übergang zwischen den einzelnen Sprachen

12. DV-Konzept - Hierarchische DB:

- Vorgänger-Nachfolger-Beziehungen
- über den Vorgänger kann auf den Nachfolger zugegriffen werden
- Recordtypen
- durch Attribute gekennzeichnet
- Wesentliche Merkmale
- Wurzel und Blätter
- jeder Record eines Recordtyps erhält einen eindeutigen Schlüssel
- jeder Record kann durch den Schlüssel und den Pfad eindeutig identifiziert werden
- Datensätze innerhalb einer Hierarchieebene werden sequentiell gespeichert
- Probleme
- bei M:N-Beziehungen werden Daten redundant gespeichert
- Konsistenzprobleme
- Zugriffspfade müssen bekannt sein aufwendiges Handling

13. DV-Konzept - Relationale DB:

- tabellenartige Struktur
- Spalten -> Attribute
- in den Zeilen werden die einzelnen Tupel organisiert
- Kennzeichen
- Zugriff erfolgt über die Abfrage einer oder mehrerer Bedingungen bzgl. der jeweiligen Attribute
- Attributkombinationen möglich
- Verbindung von Attributen möglich
- SQL Beispiel:
- SELECT Proj-Nr, Proj-Name from Project WHERE Kosten > 200000
- Integritätsbedingungen
- die auf ein Entity bezogene Integritätsbedingung
- Jedem Tupel muß ein Schlüsselattribut zugewiesen werden
- Bei keiner Zuordnung zu einem Attribut bekommt dieses den Wert NULL. Primärschlüsselattribute dürfen KEINE NULL-Werte enthalten!
- referentielle Integrität
- zwei Redundanzmöglichkeiten
- Redundanz von Schlüsseln
- gewollte Redundanz
- Fremdschlüsselbeziehungen
- Fremdschlüssel sind in abhängiger Tabelle (Kindtabelle) nur möglich, wenn in der zugehörigen unabhängigen
- Tabelle (Elterntabelle) ein Objekt existiert, das diesen Fremdschlüssel als Primärschlüssel hat
- Löschen (delete) eines Tupels
- Cascade-Prozedur: alle abhängigen Tupel werden gelöscht
- Set NULL: Fremdschlüssel bekommt den Wert NULL
- Restrict: verhindert das Löschen der Zeile in der Elterntabelle, solange noch korrespondierende Tupel in der abhängigen Kindtabelle existieren. Es müssen also zuerst alle abhängigen Tupel gelöscht werden
- Einfügen (insert) von Tupeln
- beim Einfügen eines Tupels in eine abhängige Tabelle ist gewährleistet,

daß ein Tupel mit demselben Primärschlüssel in der dazugehörigen unab-
hängigen Tabelle existieren muß. Ansonsten wird das Einfügen blockiert.

- Ändern (update) eines Tupels
- Beim Ändern eines Fremdschlüssels in einer abhängigen Tabelle wird

überprüft, ob ein korrespondierender Primärschlüssel in einer übergeord-
neten Tabelle vorhanden ist. Außerdem läßt dich ein Primärschlüssel einer Elterntabelle nicht ändern, solange noch entsprechende Tupel in abhängi-
gen Tabellen existieren.

- Ableiten der relationalen DB aus dem ERM
- Umsetzen von 1:1 Beziehungen

1. Möglichkeit: Ableiten EINER Tabelle
2. Möglichkeit: Ableiten von DREI Tabellen aus den Entitytypen und der Relation-
ship (2 Tabellen + Primärschlüsselbeziehungstabelle)

- Umsetzen von 1:N Beziehungen

1. Möglichkeit: Ableiten EINER Tabelle -!-> Redundanzen!
2. Möglichkeit: Ableiten von DREI Tabellen aus den Entitytypen und der Relation-
ship (2 Tabellen + Primärschlüsselbeziehungstabelle)

- Umsetzen von M:N Beziehungen

1. Möglichkeit: Ableiten EINER Tabelle -!-> Redundanzen und Notwendigkeit der
Primärschlüsselkombination
2. Möglichkeit: Ableiten von DREI Tabellen aus den Entitytypen und der Relation-
ship (2 Tabellen + Primärschlüsselbeziehungstabelle)

- Normalisierung von Relationen
- Unnormalisiert:

Einfügeanomalie

Pflege- bzw. Änderungsanomalie, da Redundanzen vorhanden Löschanomalie

- 1. Normalform:
- Definition:
- Zusammenfassung Struktur Eine Relation befindet sich in der ersten Normalform (1. NF), wenn jedes Attribut
- Relation nur atomare Werte enthält (Beispiel: Adresse wird zu Straße, Hausnr., PLZ, Ort)
- Relationenkopf - Handlungsanweisung:
- unterschiedliche Attribute Für jeden Wert der Wiederholungsgruppe wird ein eigenes Tupel eingeführt und
- eins dieser Attribute muß ein eindeutiger Primärschlüssel sein (auch Kombina- anschließend der Primärschlüssel erweitert tionen möglich) Einfügeanomalie

Löschanomalie

Änderungsanomalie

- 2. Normalform:

- Definition:

Eine Relation befindet sich in der 2. NF, wenn sie in der 1 NF ist und alle Nicht-
Schlüssel-Attribute voll funktional vom gesamten PS abhängig sind. Eine Relation mit einfachem PS befindet sich automatisch in der 2. NF

- Handlungsanweisung:

Die Attribute, die nur von einem Teil des zusammengesetzten PS abhängen, wer-
den mit dem betroffenen Schlüsselteil in eine neue Tabelle überführt.

Löschanomalien

Änderungsanomalien

2. NF ist der praktische Normalfall

- 3. Normalform:

- Definition:

Eine Relation befindet sich in der 3. NF, wenn sie in der 2. Normalform ist und kein Nicht-Schlüssel-Attribut transitiv vom PS abhängt, d.h. wenn kein Nicht-
Schlüssel-Attribut von einem anderen Nicht-Schlüssel-Attribut abhängt.

- Handlungsanweisung:

Die Nicht-Schlüssel-Attribute, die von anderen Nicht-Schlüssel-Attributen abhän-
gen, werden mit diesen in eine neue Tabelle überführt.

erhöhte Redundanz gegenüber 2. NF
hoher Zeitaufwand bei einem Full-Scan

14. DV-Konzept - Objektorientierte DB:

- Die betrachteten Objekte sollen vollständig in einer DB gespeichert werden
- In Relationalen DB sind weder Vererbungen noch Klassen noch Methoden abzulegen
- Klassenhierarchien, Aggregation und Vererbung sollen abgelegt werden können
- Auch Videosequenzen bzw. Animationen sollen abgelegt werden
- Es gibt verschiedene Modellierungsansätze
- ODMG (Object Database Management Group)
- Komponenten des ODMG-93
- Objektmodell (Objekte, Klassen, Attribute, Methoden, Beziehungen etc.)
- ODL - Object Definition Language
- Objekt-Abfragesprache
- Die Attribute werden um einen Datentyp und die Methoden um Ein- und Ausgabedatentypen sowie um Verarbeitungslogik ergänzt, die für den reinen Fachentwurf bislang noch nicht so wesentlich waren und dort noch keine Berücksichtigung fanden.

- Praxis: in 95% der Fälle werden relationale DB verwendet, es entstehen jedoch gewisse

Öffnungstendenzen in der Hinsicht auf Objektmodellierung.

15. DV-Konzept - DB Werkzeuge:

- bereits gute Unterstützung
- Data Translator erlauben es, aus ERM relationale DB-Schemata oder Datenkataloge zu erstellen
- Hierarchical Schema Diagrammer helfen bei der Konstruktion von hierarchischen DB
- Relational Schema Diagrammer dient zum Erstellen von relationalen Datenbankstrukturen
- File Schema Diagrammer hilft bei der Entwicklung von Dateisystemen
- Data Structure Diagrammer für Strukturen, Benutzungsoberflächen und Listen
- Data Type Diagrammer hilft beim Definieren von Datentypen
- Rational Rose (objektorientiert)
- Class Diagrams

16. DV-Konzept - Funktionen:

- aus dem fachlichen Konzeptionsentwurf wird das DV-technische Konzept abgeleitet
- Modulkonzepte: Module sind abgeschlossene 'Programme im Programm'
- welche Hürden bauen sich auf?
- Modularisierung
- Spezifikation der Verarbeitungslogik weist enge Parallelen zum Pseudocode der Elementarfunktionen auf
- Module stehen - ebenfalls wie Funktionen - in hierarchischer Beziehung zueinander
- es gibt deutliche Unterschiede zwischen Fach- und DV-Konzept:
- keine 1:1 Übernahme möglich
- Hierarchisierung der Module resultiert weniger aus der funktionalen Zerlegung als vielmehr aus dem Anwenden einer Unterprogrammtechnik
- Modulschnittstellen spezifizieren nicht nur den Daten- sondern ebenso den Kontrollfluß eines AS
- es müssen auch diejenigen Funktionalitäten abgedeckt werden, die im fachlichen Konzept noch vernachlässigbar waren:
- Zugriff auf Datenbanken
- Zugriff auf externe Ressourcen
- Fehlerbehandlung
- Modulbibliotheken (libraries) zur Reduzierung des Entwicklungsaufwandes
- Methoden und Modelle
- Strukturdiagramme zur Abbildung von Modulen
- enthalten sämtliche notwendigen Module
- Position der aufrufenden und aufgerufenen Module wird veranschaulicht
- Daten- und Kontrollfluß wird festgelegt
- Notation:
- Modul -> Rechteck
- Modul aus library --> Rechteck mit Doppelstrichen
- Anfrage -> Pfeil
- Datenparameter -> leerer Kreis mit Pfeil
- Kontrollparameter --> ausgefüllter Kreis mit Pfeil
- Strukturdiagramm als Black Box - zeigt nur die äußere Sicht der Modulstruktur, die interne Verarbeitungslogik wird nicht sichtbar
- Calls:
- intern-synchron: Aufruf zwischen Modulen des gleichen Programms; nach Ausführung des aufgerufenen Programms wird zum aufrufenden zurückgesprungen
- extern-synchron: Aufruf eines Moduls in einem anderen Programm; nach Ausführung des aufgerufenen Programms wird zum aufrufenden zurückgesprungen
- asynchroner Call: Ablaufsteuerung kehrt nicht wieder in das aufrufende Modul zurück
- mittels der Parameter definiert man die Informationen, die zwischen Modulen ausgetauscht werden
- die Richtung der Parameter zeigt auch die Richtung des Datenaustauschs an
- Daten- und Kontrollparameter
- Werkzeuge am Beispiel KEY

Anwender sollten über spezielle Kenntnisse der Zielplattformen verfügen

- Structure Chart Diagrammer
- Application Structure Charts
- Module Structure Charts
- Unterstützung durch graphische Benutzungsoberfläche
- Module Action Diagrammer
- die mit dem Minispec Action Diagrammer in der fachlichen Konzeption erarbeiteten Ergebnisse können mit diesem in die DV-Konzeption übernommen werden

17. DV-Konzept - Objekte:

- bei der objektorientierten AS-Entwicklung können die Ergebnisse der fachliche Konzeption übernommen werden
- es bedarf keiner Transformation, somit entfällt ein evtl. Strukturbruch

Prozeß der Entwicklung wird vereinfacht
komplette Werkzeugunterstützung möglich

- Inhalte
- die fachlichen Inhalte des AS - dokumentiert im Fachkonzept - werden bei der DVKonzeption in die von der gewünschten Programmiersprache bereitgestellten Imple-
mentierungskonstrukte überführt
- die Benutzerschnittstelle ist zu gestalten
- graphisches Layout der Grundelemente
- welche Benutzereingaben werden wie abgefragt und an welche Objekte oder Klassen weitergeleitet?
- Verwaltung und Aktualisierung von Fenstern und deren Inhalten
- die Datenverwaltung ist zu realisieren
- Voraussetzungen für das Abspeichern und Wiederauffinden der Objekte
- die Prozeßverwaltung ist zu realisieren
- Definition von Klassen, die das Starten und Terminieren der unterschiedlichen

Prozesse, die von diesen auszuführenden Aktivitäten und Aktionen sowie Interpro-
zesskommunikation und Prozessprioritäten festlegen

- Veranschaulichung am Beispiel OMT
- Systemdesign: Festlegung der Systemarchitektur

1. Strukturierung des AS in Subsysteme

- Unabhängigkeit
- Objektdesign: Modelle des Fachkonzepts werden verfeinert

1. Erweitern des Objektmodells um Operationen

- den Klassen im Objektmodell werden die aus dem Dynamik und Funktionsmodell abgeleiteten Operationen hinzugefügt, sofern sie noch nicht als Methoden in den Klassen enthalten sind

2. Entwurf von Algorithmen

- Formulierung der Verarbeitungslogik 3. Optimierung des Designs
- Erhöhung der Effizienz durch Hinzufügen von Assoziationen oder Speichern von Zwischenwerten

4. Implementierung der Steuerung 5. Anpassen der Vererbung

6. Festlegung der Implementierung von Assoziationen

- uni- oder bidirektional?

7. Physikalische Gruppierung

- Klassen, die eng miteinander gekoppelt sind, werden in Modulen zusammengefaßt

8. Dokumentieren des Designs

- sofortige Dokumentation
- Minimalität der Schnittstellen - Werkzeuge am Beispiel von Rational Rose

2. Identifizieren von Nebenläufigkeiten - es können die gleichen Werkzeuge wie bei der Fachkonzeption benutzt werden

- Zustandsdiagramme des Dynamikmodells - zusätzlich:

3. Zuweisen der Subsysteme an Prozessoren und Prozesse - Specifications -> Definition der Verarbeitungslogik für die Methoden

- Zuweisung zu Hardwaresystemen - Process Diagrams -> Zuordnung von Modulen zu Prozessoren und von Prozesso4. Speicherung von Daten ren zu Hardwarekomponenten

- Dateien, relationale DB oder objektorientierte DB? - Module Diagrams -> Darstellung der Struktur des AS

5. Steuerungsart festlegen

- prozedurale, ereignisgesteuerte oder nebenläufige Steuerung? - Qualitätskriterien zur Modularisierung
- Minimalität der Schnittstellen
- möglichst einfache Strukturierung des Datenaustauschs
- Testbarkeit
- jedes Modul muß - als Black Box - unabhängig testbar sein
- Modulbindung
- funktionale Bindung
- datenorientierte Bindung
- Konflikte:
- Minimalität der Schnittstellen (viele große Module) <-!-> Modulbindung (viele kleine Module)

in der Realität ist ein geeigneter Mittelweg einzuschlagen

18. Realisierung:

- die physischen Datenstrukturen müssen eingerichtet werden
- der Quellcode ist zu spezifizieren
- Benutzungsoberfläche ist anzulegen
- Realisierung nimmt heutzutage i.d.R. 30 % des Entwicklungsaufwandes ein
- Werkzeuge
- prozedurale Werkzeuge
- finden meist dort Anwendung, wo alte Systeme weiterentwickelt und gewartet werden
- Programmeditoren
- 2 Modi:
- Compiler
- Interpreter (Debugger)
- objektorientierte Werkzeuge
- auch hier gibt es Editoren, Debugger und Compiler
- Klassenbibliotheken
- AS-Generatoren
- Schreibaufwand für Quellcode soll reduziert werden
- automatische Generierung des Quellcodes
- Nacharbeitung und Korrekturen sind meist notwendig
- graphische Elemente (z.B. graphische Fallunterscheidung)
- schnelles Entwickeln von Benutzungsoberflächen
- Erstellung von Auswertungslisten
- Entscheidungstabellen
- deklarative Programmiersprachen
- informationsorientiert
- zur Verwaltung von Datenbeständen
- Beispiele: ORACLE FORMS oder VISUAL BASIC
- es zählt nur noch "Was will ich haben?" und nicht mehr "Wie will ich es haben?"

19. Steuerungskonzepte:

- einer AS besteht meist aus verschiedenen Komponenten
- solche Komponenten können auch eigenständig ablaufen (z.B. Kalkulationsmodul)
- 3 Anforderungen:
- Koordination
- Aufrufzeitpunkte
- Kommunikation
- Workflowsysteme
- teistandardisierte Arbeitsabläufe sollen rechnerbasiert unterstützt werden
- Einbeziehen von Transaktionssystemen möglich
- es müssen die entsprechenden Schnittstellen zur Verfügung stehen
- Workflow Management Coalition
- Sechs Komponenten:
- Workflow Engine
- Prozess-Definitions-Werkzeug
- Workflow Clients
- EingebundeneAnwendungen
- andere Workflow-Dienste
- Administrations- und Monitoring-Werkzeuge
- Leistungsumfang: 3 Typen von Workflowsystemen
- Verkehrspolizist

Vorgangssystem, das in der Form eines Routing-Systems den Dokumentenfluß entlang eines Prozesses verwaltet sowie steuert und dabei die Weiterleitung des Vorgangs an den als nächstes zuständigen Akteur veranlaßt

- Steuermann

Vorgangssystem, das nach festgelegten, vorgangstypindividuellen Regeln den Ar-
beits- und Dokumentenfluß steuert

- Assistenten

unterstützen darüber hinaus die Gestaltung des GP selbst, indem sie es ermögli-
chen, Prozeßänderungen zu simulieren. Außerdem können sie auch verschiedene Aktivitäten synchronisieren.

- Transaktionsorientierte Konzepte
- mit Transaktionssystemen werden formalisierte und meist kurze Verarbeitungsvorgänge im Dialog abgebildet (Ein-/Ausgaben)
- viele Nutzer kommunizieren mit diesem AS, welche ihre Transaktionen oft wiederholen
- Beispiele:
- Flugbuchungssysteme
- große Bestellsysteme
- Anwendungen im Einwohnermeldeamt
- Anforderungen:
- hoher Datendurchsatz
- Transaktionsmonitore
- Atomizität: jede Transaktion ist atomar -> "entweder ganz oder gar nicht"
- Konsistenz: physisch und logisch
- Isolation -> anderen Benutzern bleiben die Auswirkungen einer Transaktion bis

zur erfolgreichen Beendigung verborgen

- Problemfelder:
- Verhinderung von Transaktionsfehlern:
- Führung eines LOG-Files
- Daten werden in einem Mirror der Originaldatenbank geändert und hinterher

synchronisiert

- Verhinderung von Zugriffskonflikten (Deadlocks und Livelocks)
- sequentielle Ausführung der Transaktionen
- abwechselnde parallele Bearbeitung der Transaktionen
- Blackboard-Systeme:
- kommen bei schlecht strukturierten Problemen zum Ansatz
- schwarzes Brett
- kommen aus der KI -> Lösung von verteilten Problemen
- alle Problemlöser können auf die Blackboard (Daten- und Ergebnispool) zugreifen
- vier Elemente:
- das Blackboard selber
- Einträge auf dem Blackboard
- Systemmodule, Agenten oder Problemlöser
- intelligente Kontrollstruktur

20. Reengineering:

- "Sanierung von Altsystemen"
- Wie kann die Wartung effizienter gestaltet werden?
- viele Programme sind deutlich über 10 Jahre alt(!)
- Nachdokumentation
- 4 Aspekte:
- Verständlichkeit wiederherstellen/verbessern
- Effizienz: Wartungsaufwand reduzieren
- Know-How sichern (Teil des Wissensmanagements)
- Übergang von einem unsystematischen zu einem werkzeuggestützten AS
- Reverse Engineering
- Sichtbarmachen von Strukturen, ohne Programmcode zu ändern
- auf dem Quellcode aufsetzend wird versucht, die fachliche Beschreibung zu abstrahieren
- Problem: jeder Programmierer hat seine eigene Notation
- Vorschlag: 4 Schritte

1. Durchsuchen nach Datenstrukturen, die in Verbindung mit der Dateiverarbeitung
stehen
2. Untersuchen der gefundenen Strukturen auf ihre Verwendung im Programm
3. Überführen der Strukturen in ein konzeptionelles Datenmodell
4. Überarbeiten des Datenmodells, z.B. Eliminierung redundanter Elemente

- Restrukturierung
- Veränderung im Sinne einer Verbesserung des Quellcodes wird angestrebt
- "Glattziehen von Spaghetticode" ohne Veränderung der Funktionalität
- Eliminierung von GOTOs
- Wiederverwendbarkeit
- Module sollen mit geringem Aufwand auch in anderen Applikationen einsetzbar sein
- Reverse Engineering und Restrukturierung gehen i.d.R. voraus
- CARE-Tools (Computer Aided REengineering) am Beispiel DOMINO-CARE zur

Restrukturierung alter COBOL-Programme

1. Kontrollfluß wird in einen Flußgraphen überführt
2. Erzeugung linearer Strukturen (Eliminierung von GOTOs, "toter" Code)
3. Einführung höherer Sprachelemente

hoher personeller Aufwand rechtfertigen die Ergebnisse den Aufwand oder wäre eine komplette Neuimplementierung sinnvoller?