Benutzer:Chi-Vinh/Testgelände/UMO1 Drechsler
www.skripte4u.de Modellierung betr. Informationssysteme I www.andreas-drechsler.de/uni/
Table of Contents
1 Motivation und Grundbegriffe.......................................................................................................................................... 4
1.1 Betriebliche Informationssysteme......................................................................................................................... 41.2 Modellierung.......................................................................................................................................................... 41.3 Sichtweisen auf Informationssysteme................................................................................................................... 41.4 Grundprobleme der Konzeptualisierung und Lösungen........................................................................................ 51.5 Konzeptuelle Modellierung.................................................................................................................................... 5
2 Grundlegende Abstraktionen.......................................................................................................................................... 6
2.1 Datenmodellierung................................................................................................................................................ 6 2.2 Funktionsmodellierung.......................................................................................................................................... 7
3 Grundlagen der objektorientierten Modellierung ............................................................................................................ 7
3.1 Grundlagen............................................................................................................................................................ 73.2 Abstraktion............................................................................................................................................................ 7
3.2.1 durch Klassen.............................................................................................................................................. 73.2.2 durch Verkapselung / Information Hiding..................................................................................................... 83.2.3 durch Generalisierung/Spezialisierung......................................................................................................... 83.2.4 durch Polymorphismus................................................................................................................................. 8
3.3 Wiederverwendung................................................................................................................................................ 8
4 Phasenmodelle............................................................................................................................................................... 8
4.1 Grundlagen............................................................................................................................................................ 84.2 Wasserfallmodell................................................................................................................................................... 84.3 Spiralmodell........................................................................................................................................................... 94.4 V-Modell................................................................................................................................................................ 94.5 Kritische Würdigung.............................................................................................................................................. 9
5 Modellierungsmethoden................................................................................................................................................. 9
5.1 Phasen.................................................................................................................................................................. 9 5.2 Traditionelle Ansätze für Systemanalyse und -entwurf.......................................................................................... 9
5.2.1 Funktionale Analyse..................................................................................................................................... 9 5.2.2 Structured Analysis...................................................................................................................................... 9 5.2.3 Structured Analysis and Design Technique................................................................................................. 9 5.2.4 Soft Systems Methodology........................................................................................................................ 10
5.2.4.1 Konzeptioneller Bezugsrahmen........................................................................................................ 10 5.2.4.2 Betrachtungsebenen......................................................................................................................... 10 5.2.4.3 Unterstützung von Erfassung und Analyse....................................................................................... 10 5.2.4.4 Rich Pictures..................................................................................................................................... 10 5.2.4.5 Würdigung........................................................................................................................................ 10
6 Prozessbasierte Modellierung.......................................................................................................................................
6.1 Geschäftsprozesse.............................................................................................................................................. 6.2 MEMO-OrgML..................................................................................................................................................... 6.3 Heuristiken zur Geschäftsprozessanalyse........................................................................................................... 6.4 MEMO-OrgML - Vorgehensmodell zur Geschäftsprozessoptimierung............................................................... 6.5 Prozessbasierte Methode zur Software-Entwicklung........................................................................................... 6.6 Bewertung...........................................................................................................................................................
7 Weiterführende Terminologie (nicht mehr WiSe 05/06)................................................................................................
7.1 Methoden, Modellierungsmethoden und Methodologie....................................................................................... 7.2 Semantisches Netz wichtiger Begriffe................................................................................................................. 7.3 Sprachdefinitionen...............................................................................................................................................
7.3.1 Natürlichsprachlich..................................................................................................................................... 7.3.2 Grammatik................................................................................................................................................. 7.3.3 Durch Metamodelle und Metasprachen......................................................................................................
8 Qualität von Modellen (nicht mehr WiSe 05/06)...........................................................................................................
8.1 Grundlagen.......................................................................................................................................................... 8.2 Bezugsrahmen von Lindland............................................................................................................................... 8.3 Bezugsrahmen von Shanks................................................................................................................................. 8.4 Grundsätze ordnungsgemäßer Modellierung von Becker/Schütte...................................................................... 8.5 Bezugsrahmen von Frank...................................................................................................................................
10
10 11 11 11 11 12
12
12 12 12
12 12 12
12
12 12 12 13 13 by Andreas Drechsler Alle Angaben ohne Gewähr
a@andreas-drechsler.de Benutzung auf eigene Gefahr ;-) 1/12 (2006-04-24) [[Image:]]www.skripte4u.de Modellierung betr. Informationssysteme I www.andreas-drechsler.de/uni/
Alphabetical Index
by Andreas Drechsler Alle Angaben ohne Gewähr
a@andreas-drechsler.de Benutzung auf eigene Gefahr ;-) 2/12 (2006-04-24)
[[Image:]]www.skripte4u.de Modellierung betr. Informationssysteme I www.andreas-drechsler.de/uni/
1 Motivation und Grundbegriffe
1.1 Betriebliche Informationssysteme
System, das der Erfassung, Aufbewahrung, Verarbeitung und Bereitstellung von Informationen
sowie der Informationsübermittlung (Kommunikation) dient, die für zweckgerichtetes Handeln in einem Unternehmen von Bedeutung sind.
weit gefasster Begriff:
- sämtliche zweckgerichtete Informationen und deren Träger (Medien, Maschinen,
Menschen)
- sämtliche zweckgerichtete Kommunikationsformen (zwischen Menschen, Maschinen,
direkt, indirekt, ...)
- Regeln zur Strukturierung, Ablage und Verarbeitung von Information sowie zur
Gestaltung der Kommunikation für Menschen und Maschinen
eng gefasster Begriff:
- Informationen, die computergestützt verwaltet werden (Software und Daten)
- Kommunikation, die sich auf den Austausch insbesondere dieser aber auch anderer
Informationen bezieht (zwischen Menschen und Maschinen)
1.2 Modellierung
Die Semantik eines Sprachkonstrukts (Wort, Satz) bzw. eines Teil-Modells ist seine Bedeutung, die durch Interpretation des Betrachters erschlossen / festgelegt wird - nach mehr oder weniger
rigiden Interpretationsvorschriften.
Ein Modell ist das Abbild von bestimmten Sichten eines tatsächlichen oder geplanten Realitätsausschnitts, welches von bestimmten Aspekten der Wirklichkeit (Diskurswelt) bewusst abstrahiert. Die Art der Abstraktion hängt dabei vom jeweiligen Verwendungszweck ab.
Die Diskurswelt wird durch Begriffe näher beschrieben, die ihrerseits wiederum eine Abstraktion darstellen, die uns helfen, die Realität zu strukturieren und zu ordnen. Genau
betrachtet wird somit nicht die Realität, sondern nur deren sprachliche Repräsentation abgebildet. Es wird auf den Begriffsgehalt abstrahiert, der für den intendierten Systemzweck benötigt wird.
Modellierungszwecke: Beschreibung, Erklärung, Entscheidung, Konstruktion
Ein Modell erfordert eine Modellierungssprache. Eine explizite Sprachdefinition behinhaltet Syntax, Semantik und Notation. Sie kann natürlichsprachig, über eine Grammatik oder über ein
Metamodell passieren.
1.3 Sichtweisen auf Informationssysteme
Informationssysteme aus Sicht des Managements:
- Unzureichendes Verstädnis informationstechnischer Zusammenhänge
- Potenziale von Informationssystemen für die Erhöhung der Wettbewerbsfähigkeit
schwer abzuschätzen
- Verunsicherung püber Strategien von Anbietern und zukünftige Standards
- Frustration über Abhängigkeit von IT-Experten * Informationssysteme verursachen hohe Kosten
- Entwicklungs- und Wartungsprojekte mit erheblichen, schwer durchschaubaren Risiken
verbunden
- Informationssysteme sind notwendig, ihre Wirtschaftlichkeit aber kaum zu messen
- IT durchdringt letztlich alle Bereiche des Unternehmens, gehört in der Regel aber nicht
zur Kernkompetenz
- Informationssysteme werden trotz hoher wirtschaftlicher Bedeutung häufig nur
nachrangig behandelt.
by Andreas Drechsler Alle Angaben ohne Gewähr
a@andreas-drechsler.de Benutzung auf eigene Gefahr ;-) 3/12 (2006-04-24)
Informationssysteme aus Sicht der IT-Fachleute:
- hohe technische Komplexität:
○ Vielzahl von Technologien
○ rascher technischer Wandel
○ vielfältige Interdependenzen innerhalb eines Systems und im Verhältnis zu seiner
Umwelt
○ Anforderungen an Software werden immer anspruchsvoller
- Ungewissheit / unzureichendes Wissen über
○ Funktionalität / Qualität am Markt erhältlicher Anwendungen
○ Anforderungen an Anwendungen im eigenen Unternehmen
○ Änderung der Anforderungen im Zeitverlauf
- Risiken
○ Hoher, schwer zu schätzender Aufwand für Entwicklung und Wartung
○ Bedrohliche Kompetenzlücken durch Fluktuation von Mitarbeitern in
Schlüsselpositionen
- Hoher Zeitdruck
○ Entwurf von Software erfolgt häufig nicht mit wünschenswerter Sorgfalt
○ Dokumentation bleibt unzureichend
- Hoher Grad an redundanter Arbeit
- Unzureichende Integration von Anwendungen
1.4 Grundprobleme der Konzeptualisierung und Lösungen
Barrieren der Kommunikation:
- Hoher Grad an schwer durchschaubarer Interdependenz zwischen Unternehmens-
strategie, Organisation und Informationssystem
- Empfehlung: Gemeinsame, verzahnte Planung und Realisierung durch Fachexperten
und IT-Experten
- Aber: häufig unterschiedliche Wahrnehmungen, Konzeptualisierungen und Bewertung-
en, Zielvorstellungen, Fachsprachen und Kultur
Ansätze zur Verbesserung der Situation:
- Reduktion der Komplexität und Risiken
=> Schaffung von Transparenz, Abstraktion von unwesentlichen Aspekten
- Förderung der Kommunikation zwischen Management / Anwendern und IT-Experten /
Entwicklern
=> Fokussierung auf Aspekte, die für die verschiedenen Interessengruppen verständlich
sind, Abstraktion von perspektivenspezifischen Details
- Betonung von Wirtschaftlichkeitsaspekten wie Wiederverwendung / Investitionsschutz
=> Abstraktion von speziellen Merkmalen einzelner Einsatzbereiche und zeitlich
varianten Eigenschaften (insb. von Technologien)
Der fundamentale Konflikt der Systementwicklung:
- Einerseits Abstraktion von der Implementierung, Beschreibung der bezogenen Domäne
auf eine Weise, die direkt und natürlich mit den in dieser Domäne verwendeten
Konzepten korrespondiert
- Andererseits Unterstützung des Entwurfs und der Implementierung von zuverlässigen
Systemen (formale Beschreibungen, Spezifika von Programmiersprachen)
1.5 Konzeptuelle Modellierung
Konzeptuelle Modellierung dient der allen Beteiligten an einem SW-Entwicklungsprozess
verständlichen Darstellung einer Anwendungsdomäne. Die Darstellung abstrahiert dabei von
technischen Besonderheiten, ohne dabei Randbedingungen der späteren Implementierung außer Acht zu lassen.
by Andreas Drechsler Alle Angaben ohne Gewähr
a@andreas-drechsler.de Benutzung auf eigene Gefahr ;-) 4/12 (2006-04-24)
[[Image:]]www.skripte4u.de Modellierung betr. Informationssysteme I www.andreas-drechsler.de/uni/
Kernideen:
- Förderung der Kommunikation zwischen Beteiligten mit unterschiedlichen Präferenzen,
Hintergründen und Sprachen
- Bereitstellung von Konzepten zur zielgerichteten Analyse und dem Entwurf von
Systemen
- Unterstützung des Entwurfs von IS entsprechend den Vorgaben der ermittelten
Anforderungen
- Modelle als wiederverwendbare Wissensspeicher
Konzeptuelle Modellierung als sprachliche Rekonstruktion:
- Natürliche Sprachen / Fachsprachen sind ungeeignet wegen mangelnder Präzision und
keiner Berücksichtigung von Restriktionen
- Modellierungssprachen sind besser geeignet (formal / semi-formal)
- Begriffe der Diskurswelt können für die Strukturierung eines IS ungeeignet sein
- Konzeptuelle Modellierung zielt deshalb auf eine zweckorientierte Rekonstruktion von
Begriffen mittels spezieller Sprachen
Das schlägt die Brücke zur Ontologie. Die Ontologie als Teilbereich der Philosophie hat die logisch-begriffliche Untersuchung des Seienden als solches zum Gegenstand. Sie zielt auf
grundlegende Kategorien zur Beschreibung der Welt
=> Mit welchen grundlegenden Begriffen (Kategorien) lässt sich die Welt vollständig
beschreiben?
Nach der Prädikatenlogik besteht die Welt aus Entitäten, die Attribute (einstellige Prädikate)
und Beziehungen untereinander (mehrstellige Prädikate) haben. Prädikatoren sind Begriffe für
Eigenschaften von Gegenständen und Relationen. Auch die Softwaretechnik hat Kategorien für die Strukturierung von Daten, Programmen, Relationen und Operationen.
Aus psychologischer Sicht kann es empfehlenswert sein, Modelle komplexer Systeme grafisch
zu repräsentieren anstatt eine rein schriftliche Darstellung zu wählen.
Abstraktionen in konzeptuellen Modellen:
- Datenabstraktion
- Funktionsabstraktion * Zustandsabstraktion
- Objektabstraktion (integrierte Betrachtung von Daten und Funktionen)
- Prozessabstraktion
Diese Abstraktionen werden erreicht über die Begriffe / Konzepte der Modellierungssprache, die geeignet sein sollen, die Domäne zu strukturieren und die wesentlichen Eigenschaften von Informationssystemen sowohl aus Benutzer- als auch aus Implementierungssicht zu beschreiben.
In der Regel werden bei der konzeptuellen Modellierung keine einzelnen Instanzen
(Gegenstände) modelliert, sondern gleichartige in Typen zusammengefasst, die den Begriffen / Konzepten der natürlichen Sprache entstammen.
Je mehr codiert wird, desto formaler (und starrer) wird ein Modell - daher wird mit tendenziell
informaleren Modellen begonnen, um möglichst lange möglichst viel Flexibilität zu wahren.
2 Grundlegende Abstraktionen
2.1 Datenmodellierung
Datenstrukturen sind im Zeitverlauf tendenziell stabiler und Datenbanken sind von zentraler
Bedeutung für die Architektur betrieblicher Informationssysteme.
Aus philosophischer Sicht besteht die Welt aus Entitäten, die Attribute (einstellige Prädikate)
und Beziehungen untereinander (mehrstellige Prädikate) haben. Gleichartige Entitäten lassen sich zu Entitätsklassen zusammenfassen. Dynamische Aspekte lassen sich mit diesen Kategorien nicht beschreiben. Mathematische Fundierung durch Relationenalgebra oder Prädikatenlogik bietet sich zusätzlich an.
by Andreas Drechsler Alle Angaben ohne Gewähr
a@andreas-drechsler.de Benutzung auf eigene Gefahr ;-) 5/12 (2006-04-24)
[[Image:]]www.skripte4u.de Modellierung betr. Informationssysteme I www.andreas-drechsler.de/uni/
Das ER-Modell ist kein konzeptuelles Modell, sondern eine Modellierungssprache zur Erstellung
von Datenbanken.
Abstraktionsprinzipien:
- Zweckmäßigkeit: Beschränkung auf das Relevante, Berücksichtigung von Änderungen
im Zeitverlauf
- Integrität: Redundanzvermeidung, starke Typisierung
- Anschaulichkeit: Orientierung an Fachterminologie, Verwendung von üblichen
Bezeichnern
Kritische Würdigung:
- Keine / nicht einheitliche Generalisierung / Spezialisierung im EERM
- Beziehungstypen redundant / verwirrend
- Keine Angabe der Leserichtiung für Beziehungen
- Abgeleitete Attribute u. U. wichtig, aber Bedeutung nicht darstellbar
- Beschränkter Vorrat an Datentypen für die Spezifikation von Attributen
2.2 Funktionsmodellierung
Der Fokus liegt dabei auf Funktionen, die Daten verarbeiten, die in der Regel in Unteraufgaben
dekomponiert werden und deren Funktionsweise nur durch die zu erfolgende Datentransformation spezifiziert wird.
Bedeutung: Menschen tendieren dazu, ihre Arbeitsumgebung eher in Form von Aufgaben und Funktionen wahrzunehmen als in Form von Objekten.
Ein Diagramm der Funktionenhierarchie dient zur Visualisierung eines Überblicks über relevante Funktionen in der Domäne und ihrer Zusammensetzung - ohne Kontrollfluss.
Datenflussdiagramme unterstützen die Durchführung und Dokumentation einer funktionsorientierten Analyse zur Vorbereitung und Ergänzung einer Datenmodellierung.
Konzepte: Prozess/Funktion, Datenfluss, Ablage/Datenspeicher, Akteur/Schnittstelle
Eine Integration von ER-Diagramm, Funktionshierarchiediagrammen und
Datenflussdiagramme kann durch geteilte Konzepte erfolgen (Prozess/Funktion bzw.
Ablage/Datenspeicher)
3 Grundlagen der objektorientierten Modellierung
3.1 Grundlagen
Hintergrund: Abstrakte Datentypen (ADT), die es dem Programmierer ermöglichen, eigene
Datentypen auf angemessenem Abstraktionsniveau zu verkapseln.
3.2 Abstraktion
3.2.1 durch Klassen
Klassen basierten auf ADT, erlauben aber zusätzliche Generalisierung / Spezialisierung.
Klassen sind ein wichtiges Konzept der Sprache und des Denkens allgemein, ermöglichen sie es doch ohne Aufzählungen über gleichartige Objekte / Gegenstände zu reden. Klassen sind Voraussetzung für Generalisierung / Spezialisierung.
Möglichkeiten der Definition von Klassen:
- extensionale Definition: Klasse als Menge von Objekten mit gemeinsamen
Eigenschaften
- intensionale Definition: Klasse als Template, von dem Objekte mit gemeinsamen
Eigenschaften instanziert werden
Abstraktion passiert von
- den einzelnen Instanzen / Exemplaren
- den Besonderheiten der Implementierungstechnologie
- den Phasen des Lebenszyklus / Software-Entwicklungsprozesses
by Andreas Drechsler Alle Angaben ohne Gewähr
a@andreas-drechsler.de Benutzung auf eigene Gefahr ;-) 6/12 (2006-04-24)
[[Image:]]www.skripte4u.de Modellierung betr. Informationssysteme I www.andreas-drechsler.de/uni/
Vorteile von Klassen:
- Korrespondenz mit natürlichsprachlichem Klassenbegriff fördert Anschaulichkeit
- Vermeidung von Friktionen zwischen den Phasen
- Modularisierung => „Separation of Concerns": Änderungen gezielt für Klassen
durchführbar, damit Abstraktion von Änderungen einer Klasse
3.2.2 durch Verkapselung / Information Hiding
Der Zustand eines Objektes ist nicht bekannt, sondern nur das, was es über Dienste nach
außen trägt. Die Signatur / Schnittstelle listet die zur Verfügung gestellten Dienste.
Abstraktion passiert von:
- interner Datenstruktur
- konkreter Implementierung der Operationen
Vorteile von Verkapselung:
- Auch umfassende interne Änderungen einer Klasse sind möglich, wenn sich die
Schnittstelle nicht ändert => keine Seiteneffekte
3.2.3 durch Generalisierung/Spezialisierung
Abstraktion passiert von:
- Besonderheiten der spezialisierten Klassen
Vorteile von Generalisierung:
- Änderungen, die sich auf gemeinsame Eigenschaften beziehen, können in der
Oberklasse zentral vorgenommen werden
- => reduzierter Aufwand und erhöhte Integrität von Änderungen
Problem der Mehrfachvererbung: Mehrdeutigkeiten, Interpretationsschwierigkeiten
3.2.4 durch Polymorphismus
Verwendung selber Signatur für verschiedene Semantik.
Abstraktion vom:
- Empfänger einer Nachricht
Vorteil:
- Natürliche Benennung von Bezeichern möglich
- Bei Erweiterung eines Systems durch spezialisierte Klassen können aufrufende Klassen
unberücksichtigt bleiben
3.3 Wiederverwendung
Die oben angesprochenen Abstraktionshilfen helfen auch bei der Wiederverwendung, aber nicht
in jedem Fall:
- Bessere Chance, von Randbedingungen zu abstrahieren
- Förderung einer komfortablen und sicheren Anpassung an spezielle Gegebenheiten
- Je spezieller eine Klasse für einen Kontext erstellt wurde, desto geringer sind die
Chancen einer Wiederverwendung in anderem Kontext
- Isolierte Klassen sind in der Regel aufgrund von Abhängigkeiten nicht
wiederzuverwenden.
4 Phasenmodelle
4.1 Grundlagen
Phasenmodellen dienen der Identifikation wesentlicher Aufgaben in der Software-Entwicklung,
haben präskriptiven Charakter, enthalten implizite oder explizite Annahmen über die Vorgehensweise, existieren in zahlreichen Ausprägungen und benötigen eine sorgfältige
Interpretation in ihrer Anwendung
4.2 Wasserfallmodell
Phasen Anforderungsanalyse, Entwurf, Implementierung, Test, Einführung, Wartung
by Andreas Drechsler Alle Angaben ohne Gewähr
a@andreas-drechsler.de Benutzung auf eigene Gefahr ;-) 7/12 (2006-04-24)
[[Image:]]www.skripte4u.de Modellierung betr. Informationssysteme I www.andreas-drechsler.de/uni/
erweitert: Machbarkeitsstudie, Anforderungsdefinition, Grobentwurf, Detailentwurf, Codierung,
Integration, Implementierung, Wartung - alles mit Validierung und Rücksprüngen
Trotzdem bleibt es relativ abstrakt, sieht SE als einen rationalen Prozess (keine Kreativität) und
berücksichtigt auch keine Wiederverwendung
4.3 Spiralmodell
beachtet besonders das Risiko in Projekten in jedem Zyklus. Zyklen: Machbarkeitsstudie,
Anforderungsspezifikation, Architekturentwurf, Detailentwurf + weitere Verfeinerungen in jedem Zyklus.
insgesamt detaillierter als das Wasserfallmodell, enthält Betrachtungen über Risiken, Kosten
und weitere Randbedingungen, berücksichtigt Prototyping, fördert Wiederverwendung - aber
grafisch unübersichtlich
4.4 V-Modell
Ziele: „Minimierung" der Risiken, Qualitätsverbesserung, Kostensenkung und Verbesserung der
Kommunikation der Beteiligten
Phasen: Anforderungsanalyse (dabei Systemtest planen), Grobentwurf (dabei Integrationstest
planen), Detailentwurf (dabei Modultest planen), Codierung, Modultest, Integrationstest, Systemtest - aber auch andere Phasen möglich.
Es ist ein generisches Vorgehensmodell, durch Vorgehensbausteine (bestehen aus Rollen,
Produkten und Aktivitäten) und Referenzelemente anpassbar.
Das V-Modell ist in Deutschland weit verbreitet, gut - allerdings unter hohem Aufwand -
anpassbar, flexibel, sehr umfangreich und detailliert - allerdings nicht leicht zu erlernen -, es gibt unterstützende Werkezuge, ist aber nicht mit Modellierungssprachen verknüpft und manchmal in Amtsdeutsch verfasst.
4.5 Kritische Würdigung
Phasenmodelle identifizieren wichtige Aufgaben, zeigen kausale / temporale Zusammenhänge,
unterstützen das Projektmanagement, sind in der Regel eher pragmatisch als akademisch ausgerichtet, haben einen Zielkonflikt zwischen Allgemeingültigkeit und Detaillierung und ihre Angemessenheit / Qualität hängt immer vom Einsatzzweck ab.
5 Modellierungsmethoden
5.1 Phasen
jeweils in Ziele, Aufgaben, Herausforderungen und Maßnahmen unterteilt
- Systemanalyse
- Systementwurf
- Implementierung
- Test
5.2 Traditionelle Ansätze für Systemanalyse und -entwurf
5.2.1 Funktionale Analyse
einfach DFDs malen...
5.2.2 Structured Analysis
Orientierung an betrieblichen Funktionen hilfreiche Metapher, Dekomposition, weite Verbreitung,
Werkzeugunterstützung, aber kaum Verbindung zur Datenmodellierung, keine Kontrollflüsse, perfekte Technologie anstatt Randbedingungen, keine Hilfe bei der Reorganisation von
Geschäftsprozessen
5.2.3 Structured Analysis and Design Technique
zusätzlich noch Steuerdaten und Ressourcen, so dass Geschäftsprozess besser beschrieben
werden kann, allerdings immer noch kein Kontrollfluss und Mehrdeutigkeiten möglich.
by Andreas Drechsler Alle Angaben ohne Gewähr
a@andreas-drechsler.de Benutzung auf eigene Gefahr ;-) 8/12 (2006-04-24)
[[Image:]]www.skripte4u.de Modellierung betr. Informationssysteme I www.andreas-drechsler.de/uni/
5.2.4 Soft Systems Methodology
5.2.4.1 Konzeptioneller Bezugsrahmen
Erweiterung der rein rationalen und formalen Beschreibungssprache um subjektive Sichtweisen
der einzelnen, beteiligten Personen und gemeinsame Lernprozesse (organisationales Lernen). Modellierung wird als interaktiver Prozess angesehen, bei dem die Beteiligung der Anwender
wichtig ist
=> Modell als Kommunikationsgrundlage für die Diskussion gewünschter und machbarer
Veränderungen, Brückenschlag zwischen Realwelt (Cultural Analysis) und Systemdenken
(Logical Analysis)
5.2.4.2 Betrachtungsebenen
der Realwelt:
- Political System Analysis: Macht, Interessen, Konfliktpotenzial, ...
- Social System Analysis: Rollen, Erwartungen, Normen, Werte, Kultur, ...
- Role Analysis: was beschäftigt die einzelnen Akteure / Rollen, Problemwahrnehmung
und -bewertung
Beschreibung von Handlungssystemen über CATWOE:
- Customers (Begünstigte)
- Actors (Ausführende)
- Transformationsprozesse (Transformation Process)
- Weltanschauung
- Ownership (Eigentümer)
- Environmental Constraints (Umwelt)
5.2.4.3 Unterstützung von Erfassung und Analyse
durch Beobachtungstechniken, Interview-Techniken, Interaktion,
5.2.4.4 Rich Pictures
selbstsprechende Bilder zur Erfassung der individuellen Sichten („Weltanschauung") und
Erarbeitung einer gemeinsamen Sicht
5.2.4.5 Würdigung
Plausible Ausgangshypothesen, anschauliche Rich Pictures, politische und soziale
Einflussfaktoren häufig sehr relevant, allerdings domänenunspezifisch, ohne Anleitung und mit beliebiger Syntax und Semantik von Rich Pictures.
6 Prozessbasierte Modellierung
6.1 Geschäftsprozesse
Ein Geschäftsprozess ist eine wiederkehrende Abfolge von Aktivitäten, die mehr oder weniger
rigiden Regelungsmustern genügt. Er ist zielgerichtet und steht in einem direkten Zusammenhang mit der marktgerichteten Leistungserstellung eines Unternehmens. Solche Prozesse, die unmittelbar und in bedeutsamem Umfang zur Erzeugung von Erträgen führen und gleichzeitig wettbewerbsrelevante Kompetenzen eines Unternehmens fordern, bezeichnet man als Kernprozesse. Die Ausführung von Geschäftsprozessen erfordert den Einsatz knapper Ressourcen.
Ziele von Geschäftsprozessen werden aus der Unternehmensstrategie abgeleitet und die
Organisationsstruktur wiederum aus den Anforderungen der Geschäftsprozesse. Eine
Fokussierung auf Geschäftsprozesse unterstützt eine wettbewerbsorientierte
Unternehmensführung durch Zielorientierung, Kundenorientierung und Überwindung von Abteilungsbarrieren.
Ein Geschäftsprozesstyp beschreibt eine Klasse gleichartiger Geschäftsprozesse.
by Andreas Drechsler Alle Angaben ohne Gewähr
a@andreas-drechsler.de Benutzung auf eigene Gefahr ;-) 9/12 (2006-04-24)
[[Image:]]www.skripte4u.de Modellierung betr. Informationssysteme I www.andreas-drechsler.de/uni/
Ein Geschäftsprozessmodell ist eine zweckgerichtete Abstraktion eines Geschäftsprozessetyps,
die häufig - aber nicht notwendig - mit einer grafischen Darstellung einhergeht. Es bietet eine gute Grundlage für die Kommunikation zwischen Führungskräften, Anwendern und IT-Experten, da es anschaulich ist und die Konzeptualisierung der Wahrnehmung der drei Personengruppen entgegen kommt.
Geschäftsprozessmodelle sind eine wichtige Abstraktion der Wirtschaftsinformatik, da sie
sowohl betriebswirtschaftliche Analysen erlauben als auch für die Gestaltung von Informationssystemen nützlich sind. Sie leisten eine gute Integration betriebswirtschaftlicher und informationstechnischer Aspekte.
Geschäftsprozessmodellierung bedarf wie jeder anderen Modellierung auch
- einer Sprache: problemadäquate Strukturierung des Untersuchungsgegenstandes
(Fachbegriffe, Analysekonzepte, ...)
- Evaluationskriterien / Heuristiken
- eines Vorgehensmodells: Problemlösungsphasen, Rollen, Dokumente,
Koordinationsinstrumente
6.2 MEMO-OrgML
Entwurfsziele: Anschaulichkeit, Anpassbarkeit (an zu lösende Aufgabe), Integration mit anderen
Modellarten
Elemente: Prozesse, Ereignisse, Kontrollstrukturen, Ausnahmen
6.3 Heuristiken zur Geschäftsprozessanalyse
- systematische Komplexitätsreduktion: durch Dekomposition („Teile und herrsche")
- Zielorientierung: der Prozesse / Teilprozesse, inkl. Indikatoren zur Zielerreichung
- Mitarbeiter: Eignung, Qualifikation, Motivation
- Vereinfachungspotenziale
- Auslagerung: andere Unternehmensbereiche, extern
- Automatisierungspotenziale: Medienbrüche, Spezialsoftware, Formalisierungsmöglich-
keiten
Durch „Method Engineering" (situationsspezifische Anpassung der Modellierungssprache) kann
eine bessere Analyse und Entwurf erreicht werden
6.4 MEMO-OrgML - Vorgehensmodell zur Geschäftsprozessoptimierung
- Erfassung betriebswirtschaftlicher Eckdaten
- Definition der Analyse- bzw. Gestaltungsziele
- Grob-Modellierung des Ist-Zustands
- Schrittweise Bewertung & Verfeinerung
- Prozess-Reorganisation
- Evaluation
dazu Analyse- und Bewertungstechniken pro Phase: Ziele / Gegenstand, verwendbare
Dokumente, Beteiligte, Methoden / Heuristiken, Erstellte Dokumente
6.5 Prozessbasierte Methode zur Software-Entwicklung
von Software, die Geschäftsprozesse unterstützen soll.
Vorgehensmodell:
- Modellierung des Soll-Prozesses
- Beschreibung der verwendeten Informationen
- Erstellung eines korrespondierenden Objektmodells
- ggfs. Erstellung eines Interaktionsmodells
- Verfeinerung des Modells
- Abbildung auf Implementierungsebene
- Evaluation
In diesem Prozess werden MEMO-OrgML und MEMO-OML integriert.
by Andreas Drechsler Alle Angaben ohne Gewähr
a@andreas-drechsler.de Benutzung auf eigene Gefahr ;-) 10/12 (2006-04-24)
[[Image:]]www.skripte4u.de Modellierung betr. Informationssysteme I www.andreas-drechsler.de/uni/
6.6 Bewertung
Vorteile der prozessbasierten Modellierung:
- Modelle von Geschäftsprozessen stellen eine für alle Beteiligten in Software-
Entwicklungsprojekten verständliche Abstraktion dar
- Sie dienen deshalb als eine gemeinsame Referenz und damit als ein zentrales Medium
zur Förderung zielgerichteter Kommunikation
- Anreicherung/Detaillierung kann in Abhängigkeit von konkreten Projektzielen erfolgen
- Sie sind in allen Phasen der Software-Entwicklung (jeweils in unterschiedlicher
Detaillierung/Formalisierung) verwendbar und eine gute Grundlage für die Generierung
von Code
- Wiederverwendung von (Basis-) Modellen in anderen Kontexten ist möglich (z. B.
Organisationsanalyse- und Entwurf, Analyse existierender DV-Systeme, ...), die dann
spezifisch angereichert werden
- z. B. gute Grundlage für betriebliches Wissensmanagement
Herausforderungen:
- Nutzen der Modellierung von Geschäftsprozessmodellen schwer zu quantifizieren
- Qualität der Modelle muss in geeigneter Form überprüft werden
- Pflege der Modelle ist aufwändig
- kein überzeugendes Konzept für Generalisierung/Spezialisierung von Prozessmodellen
- einschlägige Modellierungswerkzeuge zum größten Teil noch unbefriedigend
7 Weiterführende Terminologie (nicht mehr WiSe 05/06)
7.1 Methoden, Modellierungsmethoden und Methodologie
Eine Methode strukturiert eine Klasse von Problemen problembezogen, hat einen positiven
Einfluss auf die Problemlösung und findet unter bestimmten Rahmenbedingungen Anwendung.
Eine Modellierungsmethode unterstützt die Problemlösung durch Konstruktion von Modellen in
einer bestimmten Modellsprache und schlägt zudem Vorgehensmodelle für temporale/kausale Durchführung von Problemlösungsaktivitäten vor.
Die Methodologie ist die Lehre von den Methoden einer wissenschaftlichen Disziplin.
7.2 Semantisches Netz wichtiger Begriffe
7.3 Sprachdefinitionen
Ein Modell erfordert eine Modellierungssprache mit Syntax, Semantik und Notation. Sie kann auf
mehrere Arten definiert werden
7.3.1 Natürlichsprachlich
7.3.2 Grammatik
7.3.3 Durch Metamodelle und Metasprachen
Ein Metamodell beschreibt die Syntax und Semantik für eine Klasse von Modellen. Metamodelle
erleichtern die Implementierung in CASE-Tools und stellen keinen Paradigmenbruch bei der Modellierungssprachenbeschreibung dar.
Eine Metasprache erlaubt das Sprechen über eine Sprache, z. B. eine Grammatik einer
Programmiersprache - formal ist das wichtig.
8 Qualität von Modellen (nicht mehr WiSe 05/06)
8.1 Grundlagen
Bewertung von Modellqualität ist subjektiv, aber wirtschaftlich von hoher Bedeutung
8.2 Bezugsrahmen von Lindland
syntaktisch korrekt, semantisch valide und vollständig, pragmatisch verständlich - kann mit
bestimmten Maßnahmen festgestellt werden
8.3 Bezugsrahmen von Shanks
ergänzt soziale Aspekte (geteiltes Verständnis)
by Andreas Drechsler Alle Angaben ohne Gewähr
a@andreas-drechsler.de Benutzung auf eigene Gefahr ;-) 11/12 (2006-04-24)
[[Image:]]www.skripte4u.de Modellierung betr. Informationssysteme I www.andreas-drechsler.de/uni/
8.4 Grundsätze ordnungsgemäßer Modellierung von Becker/Schütte
Richtigkeit (syntaktisch und „semantisch"), Relevanz (zielabhängig - Domänenrelvanz und
Abbildungsrelevanz), Klarheit (Strukturiertheit, Übersichtlichkeit, Lesbarkeit), Wirtschaftlichkeit, Vergleichbarkeit (syntaktisch zwischen Modellsprachen; semantisch zwischen Modellen),
systematischer Aufbau (Sichten und Integration in Gesamtsicht)
8.5 Bezugsrahmen von Frank
syntaktische Korrektheit, Anschaulichkeit (sehr subjektiv), Angemessenheit
(Abstraktionsniveau!), Operationalisierbarkeit (in Simulationen, in Code...)
aber: Ziele nicht genau definierbar, Menschen sind lernfähig, Modelle sind kein Selbstzweck,
Vollständigkeiten können nicht bewiesen werden etc.
Qualitätskriterien sind bis auf syntaktische Korrektheit alle nicht objektiv beweisbar. Daher
Qualitätszirkel / Qualitätsbeauftragte [oder build quality in...]
by Andreas Drechsler Alle Angaben ohne Gewähr
a@andreas-drechsler.de Benutzung auf eigene Gefahr ;-) 12/12 (2006-04-24)
[[Image:]]Zusammenfassung Unternehmensmodellierung Ergänzungen zur Zusammenfassung von Skripte4u
Kapitel 1: Motivation & Grundbegriffe
1.1 Betriebliche Informationssysteme
Fokus der Vorlesung: betriebliches Informationssystem in engerer Fassung
(Wirtschaftsinformatik Blickwinkel)
1.2 Modellierung
Daten = Folge von Symbolen aus festgelegten Symbolmengen. Formale Semantik ergibt sich durch Typzugehörigkeit.
Informationen = Daten, deren Semantik sich durch die Abbildung realer Sachverhalte ergibt. Es liegt also eine realweltliche Interpretation vor.
Wissen = Informationen, die durch ein höheres Maß an Abstraktion und Begründung
gekennzeichnet sind. (Anmerkung: Informationen die in Kontext gesetzt werden!)
1.5 Konzeptuelle Modellierung
Diagramme auf Folien 540 / 550
Kapitel 2: Grundlegende Abstraktionen
2.1 Datenmodellierung
Entity - Relationship - Modell = Klasse semantischer Datenmodelle, die auf einen Vorschlag von Chen zurückgehen.
Ziele des ERM:
- Abstraktion von Datenbankmodellen (Investitionsschutz)
- Berücksichtigung einer formalen Fundierung (Modellierungssprache)
- Förderung einer anschaulichen (meist grafischen) Darstellung
Normalisierung:
- Verfahren zur Entdeckung und Vermeidung von Redundanzen
- Redundanz nur entdeckt wenn einheitliche Bezeichner verwendet werden
- Nicht erforderlich wenn in qualifizierter Weise modelliert wurde Begutachtung
durch weitere Fachkräfte
2.2 Funktionsmodellierung
Funktionenhierarchie Bewertung:
- Überblick
- Dekomposition
- Bewertung und Analyse durch fehlenden Kontrollfluss problematisch
- Ergänzungsfähig (z.B. durch Geschäftsprozessmodelle)
DFD Bewertung:
- Gute Grundlage für Entwurf der Funktionen eines Programms
- Keine Darstellungsmöglichkeit der zeitlichen Abfolge (Kontrollfluss)
- Grundlage für funktionale Integration
- Unterstützt sukzessive Entwicklung korrespondierender Datenmodelle
Kapitel 3: Objektorientierte Modellierung
3.1 Grundlagen
Kernkonzepte der Objektorientierung:
- Klassenbildung
- Verkapselung
- Spezialisierung (Vererbung)
- Polymorphismus
Kapitel 5: Modellierungsmethoden
[[Image:]]5.1.1 Systemanalyse
Ziele:
- Zweck des zu entwickelnden Systems konkretisieren
- Angemessenes Verständnis der betrachteten Domäne entwickeln und dokumentieren
- Systemanforderungen vollständig (möglichst) erfassen
- Unterstützung des Entwurfs
Aufgaben:
- Systemanforderungen in unterschiedlichen Abstraktionen erfassen
- Erfassung von Anforderungsalternativen
- Kommunikation mit Auftraggebern und Anwendern
Herausforderungen:
- Entscheidung über Vollständigkeit der Anforderungen treffen
- Bewertung der Kosten weiterer Detailanalysen und deren Nutzen
- Abgrenzung der betrachteten Domäne
- Differenzierung zwischen invarianten und variierenden Anforderungen
- Angemessene Abstraktion von Handlungsmustern finden
Maßnahmen:
- Bereitstellung möglicher Analysekriterien - Checklisten für Überprüfung von Risiken
- Methoden zur Unterstützung der Anforderungserhebung
- Verzeichnis wichtiger Rollen und Aufgaben - Skizze einer idealtypischen Vorgehensweise
5.1.2 Systementwurf
Ziele:
- Festlegung einer anforderungsgerechten Systemarchitektur - Detaillierte Spezifikation wesentlicher Systemeigenschaften
- Wirksame Unterstützung der anschließenden Implementierung
Aufgaben:
- Erstellung von Entwurfsdokumenten
- Erfassung und Bewertung von Entwurfsalternativen
- Auswahl der Entwurfs- und Implementierungswerkzeuge
Herausforderungen:
- Kompromiss zwischen Eigenerstellung und Wiederverwendung
- Festlegung Abstraktions- / Wiederverwendungsgrad - Einbettung System in existierende Systemlandschaft
- Angemessene Balance zwischen Implementierungstechnologien und Abstraktion von
diesen
Maßnahmen:
- Kriterien zur Bewertung alternativer Entwürfe
- Referenzentwürfe als Anleitung
- Qualitätskriterien zur Bewertung von Entwürfen - Bereitstellung geeigneter Modellierungssprachen
- Konzepte zur Beschreibung / Bewertung vorhandener Systeme / Komponenten
5.1.3 Implementierung
Ziele:
- Realisierung einer Software Architektur
- Lauffähiges System nach Vorgaben des Entwurfs
Aufgaben:
- Erfassung / Auswahl von Implementierungssprachen
- Generierung von Implementierungsdokumenten
- Festlegung von Schnittstellen
[[Image:]]- Integration der Systemkomponenten, ggf. mit existierenden Systemen
Herausforderungen:
- Auswahl von Sprachen und Werkzeugen erfordert multidimensionale Bewertung
- Einarbeitung in Sprachen und Werkzeuge
- Erstellung qualitativ hochwertiger Codes erfordert angemessene Kriterien zur
Bewertung von Qualität
- Entscheidung zwischen Wiederverwendung und neuer Implementierung
Maßnahmen:
- Regeln für Umsetzung des Entwurfs in Code für verschiedene Laufzeitumgebungen
- Einsatz von Software Generatoren
- Bezugsrahmen zur Unterstützung des Qualitätscontrolling
- Anleitung zur Integration mit vorhandenen bzw. parallel entwickelten Systemen
- Festlegung zur Unterstützung des Code Managements (Mehrbenutzerzugriff,
Versionsverwaltung, usw.)
5.1.4 Test
Ziele:
- Ermittlung nicht akzeptablen Systemverhaltens
- Ermittlung korrespondierender Ursachen
- Überprüfung eines angestrebten Qualitätsniveaus
Aufgaben:
- Ermittlung geeigneter Testfälle
Herausforderungen:
- Festlegung des angemessenen Testaufwands
- Entscheidung über Zustand ausreichender Qualität
Maßnahmen:
- Anleitung zum systematischen Test
- Automatisierte Testverfahren - Verzeichnisse mit Testfällen
- Hinweise auf typische Probleme
- Qualitätskriterien, Metriken