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