Systementwicklung Vorlesung SS 2005 Paul Manthey Systementwicklung.

Präsentation zum Thema: "Systementwicklung Vorlesung SS 2005 Paul Manthey Systementwicklung."—  Präsentation transkript:

1 Systementwicklung Vorlesung SS 2005 Paul Manthey Systementwicklung

2 Gliederung der Veranstaltung
Einführung Die Gestaltung der Organisation durch IS Das Systemmodell und seine Entwicklung Grundlagen der Systemmodellierung Funktionssicht (Funktions- oder Prozessmodell) Funktionsmodellierung Ablaufmodellierung Alternativen der Funktions- und Ablaufmodellierung Objektmodell I Objektmodell II Objektmodellierung Systementwicklung

3 Die Gestaltung der Organisation durch IS
Einfluss verschiedener Informationstechniken auf die Organisation Systementwicklung

4 Arten der Veränderung der Organisation durch IS (1)
Automation Menschliche Arbeit wird teilweise (einzelne Schritte von Geschäfts-prozessen) durch Computer ersetzt Beschleunigung, Kostensenkung und Qualitätsverbesserung Beispiele: Geldausgabeautomat, Baubarkeitsprüfung von LKW, Gehaltsabrechnungen, Flugbuchungen etc. Häufigste und älteste Form der Veränderung der Organisation durch IT Rationalization Nicht nur Automatisierung menschlicher Aktivitäten, sondern Beseitigung typischer Engpass-Situationen und Medienbrüche, Vereinheitlichung von Daten, Aktivitäten, Geschäftsregeln etc. Beispiel: Von der automatischen Berechnung eines Kredits bis zur durchgängigen, aber sequentiellen Abwicklung mit Computerunterstützung Systementwicklung

5 Arten der Veränderung der Organisation durch IS (2)
Business Process Reengineering Geschäftsprozesse werden analysiert, vereinfacht und neu gestaltet Gestaltung zielt auf optimale Nutzung der IT Workflows werden reorganisiert, Arbeitsschritte zusammengefasst, um Wartezeiten, Rüstkosten oder unnötige Dokumentation zu vermeiden, Weitreichendere Veränderung als Rationalization, erfordert eine neue Vision des Prozesses Beispiel: Ford Motor Company‘s invoiceless processing Traditioneller Prozess: Auftrag an Lieferant, Lieferung, Lieferschein und Rechnung, Mitarbeiter verwenden die meiste Zeit auf die Beseitigung von Diskrepanzen zwischen Dokumenten Neuer Prozess: Auftrag an Lieferant, Lieferung wird verglichen mit Auftrag, automatische Buchung und Bezahlung, keine Rechnung Konsequenz: Reduzierung der Mitarbeiterzahl um 75% Systementwicklung

6 Arten der Veränderung der Organisation durch IS (3)
Paradigm Shift IS können Organisation und Geschäftsmodell grundsätzlich ändern Beispiel: Transportunternehmen, entwickelt IS, mit denen es das Management der Logistik seiner Kunden übernimmt. Systementwicklung

7 Business Process Reengineering (1)
Beispiel: Traditionelle Vergabe von Hypotheken. Systementwicklung

8 Business Process Reengineering (2)
Beispiel: Traditionelle Vergabe von Hypotheken. Systementwicklung

9 Business Process Reengineering (3)
Beispiel: Traditionelle Vergabe von Hypotheken. Systementwicklung

10 Business Process Reengineering (4)
Beispiel: Team approach bei der Vergabe von Hypotheken. Systementwicklung

11 Business Process Reengineering (5)
Bearbeitung einer Hypothek nach dem traditionellen Prozess (Weiterreichen von Schreibtisch zu Schreibtisch): Kosten: $ in Wochen nach dem Team approach (gemeinsame Bearbeitung einer Hypothek durch eine Gruppe von Spezialisten): Kosten: $ in 1 Woche Was verursacht die Kosteneinsparung? Keine wiederholte Erfassung von Daten auf Papier, sondern einmalige Eingabe in Datenbank Kein sequentieller Prozess mit Wartezeiten, sondern gleichzeitiger Datenzugriff durch verschiedene Spezialisten, mit kurzen Kommunikationswegen Vorläufige Zusage einer Kreditlinie Parallelisierung von Loan Origination („Produktentwicklung“) und Loan Servicing („Einrichtung des Produktionsprozesses“) Systementwicklung

12 Work flow management Viele Prozesse beschreibbar als
Fluss von Vorgängen (meist definiert durch eine Menge von Dokumenten) durch eine Organisation (Work flow) mit hoher Wiederholrate Work flow management systems Erlauben die Definition eines Geschäftsprozesses als Menge von Arbeitsschritten Mit Übergängen zwischen den Arbeitsschritten Regeln für die Übergänge Zuordnung von Dokumenten zu Arbeitsschritten Zuordnung von Arbeitsschritten und Dokumenten zu Organisationseinheiten und IS Können automatisch Vorgänge entlang des Geschäftsprozesses abwickeln, überwachen und dokumentieren Systementwicklung

13 Effective Reengineering
Klare Vision, wie Geschäftsprozesse verändert werden sollen Konzentration auf wenige Geschäftsprozesse mit dem höchsten strategischen Bedeutung und dem höchsten potentiellen Nutzen Quantitative Planung und Kontrolle Nicht nur „Elektrifizierung“ bestehender Prozesse, sondern Nutzung des Potentials von IS für die Neugestaltung der Prozesse Berücksichtigung der Prozesse von Kunden, Lieferanten und anderen Partnern (X-engineering) Change Management Systementwicklung

14 Process improvement TQM (Total Quality Management)
Auf der Mitwirkung aller ihrer Mitglieder beruhende Führungsmethode einer Organisation, die Qualität in den Mittelpunkt stellt und durch Zufriedenstellung der Kunden auf den langfristigen Geschäftserfolg sowie Nutzen für die Mitglieder der Organisation und für die Gesell-schaft zielt.„ Quelle: DIN ISO 8402 Zentraler Wirkungsmechanismus: Fehlervermeidung Instrumente des TQM und die Rolle der IS Vereinfachung von Produkten und Produktionsprozessen (Blumenversand, korrekte und schnelle Auftragsbearbeitung) Benchmarking (Versandhandel, 99,9% korrekte Aufträge) Kundenorientierung (Customer care system am Airline gate) Beseitigung von Zwischenlagern (Just-in-time Produktion) Reduzierung von Durchlaufzeiten (Vergabe von Hypotheken) Verbesserung der Präzision und Qualität im Design (CAD-Systeme) und in der Produktion (Varianten-Produktion) Systementwicklung

15 Veränderung der Organisation und Rolle der IS
Systementwicklung

16 Grundlagen: Modell (1) Definition
Modelle von Objekten sind Ersatzobjekte mit analoger Struktur, Funktion oder analogem Verhalten. Systementwicklung

17 Grundlagen: Modell (2) Definition
Modelle von Objekten (Originalen) sind vereinfachte Abbildungen der Objekte (Abstraktionen). Das Original ist meist ein Realitätsausschnitt, es kann aber auch selbst etwas Fiktives sein (z. B. ein dreidimensionales Modell eines zwar konstruierten, aber noch nicht realisierten Gebäudes.) Es gibt unterschiedliche Modelle desselben Originals, unterschiedliche Abstraktionen. Ein Modell kann andere Modelle integrieren oder konkretisieren, ist aber dennoch ein Modell des Originals (z. B. ein dreidimensionales Modell eines Gebäudes integriert die Modelle Grundriss und Seitenansichten und konkretisiert diese z. B. durch Textur und Farbe der Außenwände). Ein Modell besitzt nicht alle Merkmale des Originals. Systementwicklung

18 Grundlagen: Partialmodelle, unterschiedliche Sichten
Definition Ein Modell stellt eine Sicht auf ein Objekt dar. Werden verschiedene Sichten betrachtet, spricht man auch von Partialmodellen. “Umfassen-dere” Modelle können durch Integration der Partialmodelle gebildet werden). Verschiedene Sichten/Aspekte: Architektur: Grundriß Elektro-Plan (elektrisches System) Plan der Wasserversorgung (hydraulisches System) Integration in den Grundriß. Systementwicklung

19 Modell eines Geschäftsprozesses (Objektfluss)
Systementwicklung

20 Modell eines Geschäftsprozesses (Vorgangskette)
Systementwicklung

21 Grundlagen: System Definition
Ein System ist eine Menge von Objekten, die untereinander in Beziehung stehen. Beispiel: Unternehmen - es besteht aus Menschen Technik (Gebäude, Maschinen, ...) Arbeitsergebnisse Organisatorische Regelungen Beziehungen zwischen diesen Bestandteilen Person stellt Ergebnis her Person benutzt Maschine Person arbeitet in Gebäude Person ist Vorgesetzter von Person ... Systementwicklung

22 (System-)Modell Systementwicklung

23 Grundlagen: Modell (3) Forderung an die Abbildung:
Jedem Element und Attribut sowie jeder Attributausprägung und Relation des Ausschnitts ist durch die Abbildung genau ein Element, ein Attribut, eine Attributausprägung oder Relation des Modellweltausschnittes zugeordnet. Abstraktion: Nicht alle Elemente der Originalwelt müssen im Ausschnitt der Originalwelt und nicht alle Elemente der Modellwelt müssen im Ausschnitt der Modellwelt vorkommen Nicht alle Attribute, Ausprägungen von Attributen und Relationen der Originalwelt (Modellwelt) müssen im Ausschnitt der Originalwelt (Modellwelt) vorkommen (Relationen des Ausschnitts können Teilrelationen von Relationen der Originalwelt sein) Verschiedene Elemente (Attribute, Attributausprägungen, Relationen) der Originalwelt können aber auf gleiche Elemente (Attribute, Attributausprägungen, Relationen) der Modellwelt abgebildet werden. Systementwicklung

24 Übungsaufgabe (1) Beschreiben sie den Schaltplan (Modell) explizit als Abbildung von Ausschnitten im Sinne der Definition eines (System-)Modells, d.h. Elemente, Attribute, Ausprägungen, Relationen für den Ausschnitt der Modell- und der Originalwelt sowie die Abbildung explizit beschreiben. Ist ein Kabel ein Element oder eine Relation? Systementwicklung

25 Übungsaufgabe (2) Was ist falsch an dem folgenden Modell und warum?
Systementwicklung

26 Vorgehen bei der Entwicklung eines Modells
Mehrere Schritte, die mit Wiederholungen und Rücksprüngen, tendenziell in der folgenden Reihenfolge ausgeführt werden: Den zu modellierenden Gegenstand festlegen. Den Modellierungszweck bestimmen. Die Modellwelt/Beschreibungsmittel bestimmen. Regeln für die Abstraktion festlegen. Die Abbildung der Realität auf die Modellwelt bestimmen. Modell überprüfen. Systementwicklung

27 Der Zweck eines Modells
Verstehen der Realität (Ist-Modelle) zur Beschreibung: Z.B. Nutzung der Anschauung zur Exploration: Z.B. Vorhersage über das Verhalten zur Bewertung/Analyse: Z.B. Bestimmung von Mängeln Konstruktion/Gestaltung der Realität (Soll-Modelle) Beschreibung einer Vorgabe für die Konstruktion Analyse/Simulation zur Prüfung der Konstruktion vor der Realisierung Analyse möglicher/alternativer Gestaltungen der Realität Z.B. Identifikation von Fehlern vor der Realisierung Bestimmung von Charakteristika (Verhalten, Kosten etc.) Abstimmung zwischen Beteiligten (Auftraggeber, Auftragnehmer, Koordination zwischen oder verschiedenen Mitarbeitern/Organi-sationen, die die Realisierung kooperativ durchführen, z. B. Auftragnehmer, Unterauftragnehmer) Systementwicklung

28 Darstellungsmittel für Modelle (Modellsprache) (1)
meist graphische Elemente Kombinationsregeln meist allgemein anwendbar Funktion einer Sprache Beispiele in der Architektur: perspektivische Darstellung Schaltpläne/Vernetzungspläne Beispiele aus der Unternehmensbeschreibung: Organigramm Systementwicklung

29 Syntax und Semantik Syntax einer Sprache: Alphabet
Regeln nach denen aus dem Alphabet Terme (zur Bezeichnung von Dingen) gebildet werden Regeln nach denen aus Termen und dem Alphabet Aussagen/Modelle gebildet werden Semantik einer Sprache: Sprache wird interpretiert, d. h. es wird ein Anwendungsbereich zugeordnet Regeln mit denen die Bedeutung sprachlicher Ausdrücke (Terme und Aussagen) festgelegt wird Bedeutung von Termen sind Elemente des Anwendungsbereichs Bedeutung von Aussagen sind die Wahrheitswerte wahr und falsch Systementwicklung

30 Beispiel Arithmetik Syntax
Alphabet: d.h. Zahlzeichen wie 0,1,2,3 etc. bzw. +, *, -, /, =, <, > oder Hilfszeichen (,) Terme: Zahlzeichen sind Terme. Sind t und s Terme, so auch (t + s), (t * s), (t – s) und (t / s) Beispiele: (2 + 3), (2 – 2), (((2 + 3) * 2) – (3 – 1)) Aussagen: Sind t und s Terme, so sind t = s, t < s und t > s Aussagen Beispiele: (((2 + 3) * 2) / (3 – 1)) = 3 oder 4 < 3 oder (2+3)=(3+2) Semantik Terme bezeichnen Anzahlen von Objekten, bezeichnen t und s Anzahlen, so bezeichnet (t + s) die Anzahl der zusammengelegten Objekte etc. Sind t und s Terme, so ist t = s wahr, wenn die durch t und s bezeichneten Anzahlen identisch sind. Systementwicklung

31 Beispiel Schaltpläne (1)
Systementwicklung

32 Beispiel Schaltpläne (2)
Systementwicklung

33 Beispiel Schaltpläne (3)
Systementwicklung

34 Beispiel Schaltpläne (4)
Simulationsmodell gestattet die Ableitung von Aussagen: Für einen bestimmten Schaltplan (siehe Beispiel) gilt: Wenn Schalter zu, dann Lampe an. Wenn Schalter auf, dann Lampe aus. Simulationsmodelle gestatten also Vorhersagen (Aussagen) über das Verhalten zusammengesetzter Objekte (Systeme) Die Aussagen werden aus der Struktur des Systems (des zusammengesetzten Objekts) abgeleitet. Semantik des Modells: Bezeichnet ein zusammengesetztes Objekt (System) Zum Simulationsmodell gehört ferner eine Sprache zu Bildung von Aussagen, mit der Bedeutung: wahr oder falsch Häufig werden Modelle nicht explizit als Simulationsmodelle beschrie-ben, aber als solche genutzt (z.b. der übliche „intuitive“ Gebrauch der Schaltpläne) Systementwicklung

35 Darstellungsmittel für Modelle (Modellsprache) (2)
Vorteil durch Verwendung derselben Darstellungsmittel für verschiedene Modelle (wie z. B. bei den Schaltplänen): Routine im Umgang mit den Darstellungsmittel Perfektionierung der Darstellungsmittel (z. B. wohldefinierte Semantik) Einfachere Sicherung der Vollständigkeit und Relevanz der Modellelemente Routine in der Entwicklung von Modellen Möglichkeit der Entwicklung von Werkzeugen zur Unterstützung Vergleichbarkeit der Modelle/Originale Systementwicklung

36 Was ist eine Modellierungsmethode?
Systementwicklung

37 Modellierungsmethode
laut Duden ist Methode ein planmäßiges Vorgehen, Verfahren Modellierungsmethode: planmäßiges Vorgehen zur Entwicklung eines Modells Anforderung: strukturiert die Entwicklung eines Modells in Teilaufgaben und Schritte bedient sich bestimmter Darstellungsmittel gibt Anleitung für die Durchführung der Modellierung, Unterstützt die Sicherung der Qualität der Modelle oder enthält Kriterien für “gute” Modelle, ist in der Regel kein Algorithmus (im Sinne der Mathematik) unterstützt die relevanten Partialmodelle und deren Integration ist effizient Systementwicklung

38 Arten von Systemen Systementwicklung

39 Arten von Systemen: interaktive Systeme
Systementwicklung

40 Weitere Arten von Systemen (1)
Systementwicklung

41 Verschiedene Modellierungen eines Systems
Systementwicklung

42 Weitere Arten von Systemen (2)
Systeme mit geplanten Reaktionen (McMenamim/Plamer) Definition Ein System mit geplanten Reaktionen ist eine Einheit (oder eine Sammlung von Einheiten), die vordefinierte Aktionen ausführen, wenn ein bestimmtes Ereignis außerhalb ihres Einflußbereiches eintritt. Ein System mit geplanten Reaktionen ist transportabel, wenn seine geplanten Reaktionen in einer symbolischen Sprache ausgedrückt werden können, so daß auch andere aktive Einheiten diese ausführen könnten. Ähnliche Abgrenzung: formal Systems (formale, formelle Systeme) auf expliziten, akzeptierten Regeln basierend versus informal Systems (nicht formale, informale, informelle Systeme) z. B. die Büro-Tratsch-Netzwerke Systementwicklung

43 Beispiele von Systemen mit geplanten Reaktionen (1)
Tante-Emma-Laden Geplante Reaktionen Ungeplante Reaktionen Geschäftsprozesse Außerhalb der Betrachtung Süßigkeiten als Geschenke Architektur des Ladens Vertretung von Tante Emma durch ihre Freundin ... Arzt bei Operation System mit geplanten Reaktionen, aber nicht transportabel Systementwicklung

44 Beispiele von Systemen mit geplanten Reaktionen (2)
Unternehmen oder andere Organisationen und Organisationseinheiten bestehen aus Menschen, Organisation, Technik und Management Betrachtungsgegenstand: Verarbeitung und Transport von Material und Information (Fokus ist die Arbeitsweise des Unternehmens) Geschäftsprozesse regelmäßig wiederkehrende geplante Aktivitäten, die durch einen Kundenkontakt (Auftrag/Anfrage) ausgelöst werden und mit einem Kundenkontakt (Auslieferung/Bezahlung) enden (End-to-End-Prozesse). Ist ein Prozess ein System? System = alle Elemente eines Unternehmens, die an der Ausführung des Geschäftsprozesses beteiligt sind. Geschäftsprozess stellt die geplanten Reaktionen dar. Informationssysteme Menge von Einheiten zur Verarbeitung, Speicherung und zum Transport von Informationen, ihre Beziehungen untereinander sowie alle technischen, organisatorischen und Managementregelungen zur Verarbeitung und Speicherung von Informationen Verarbeitungseinheiten können Menschen oder Maschinen sein, Speicher können elektronische Systeme, Papier etc. sein, Transport kann materiell oder immateriell erfolgen Systementwicklung

45 Abstraktionskriterium: geplante Reaktion
Systementwicklung

46 Aufgaben der spontanen Hülle
typische Aufgaben der spontanen Hülle: Filtern relevanter Ereignisse, Ereignisse aktiv herbeiführen, auf die der geplante Kern reagieren kann, Übersetzung von Umgebungsanforderungen/Informationen Ausführung von Aktivitäten, die der geplante Kern nicht oder nur unzureichend leisten kann, Spezialfälle behandeln, deren Planung nicht wirtschaftlich ist (z.B. zu selten), Informelle Kommunikation mit der Umgebung (z.B. Beratung) Systementwicklung

47 Abstraktionskriterium: perfekte Technologie
Abstraktionskriterium: perfekte Technologie*) Komplexität durch Mängel der Technologie Zerstückelung: Verteilung auf verschiedene Prozessoren Redundanz: Mehrfachspeicherung von Daten Durchführung der gleichen Aktivität an verschiedenen Daten Zusatzkomponenten dienen dem Ausgleich von Unzulänglichkeiten der Implementation Verwicklung umständliche Ausführung einer Aktivität wegen Unzulänglichkeiten der Implementation Konglomerate Zusammenfassung unterschiedlicher Aktivitäten (auf einem Prozessor) *) Gemeint sind die Mittel der Realisierung (Implementierung). Bei manuellen Systemen ist auch der Mensch ein Mittel der Realisierung. Systementwicklung

48 Essenz des geplanten Kerns
Definition Die Essenz eines Systems beschreibt alle Aspekte des Systems, die existieren müssen, unabhängig davon, welche Technologie zur Implementierung des Systems (interne Technologie) verwendet wird. Soll vom technologischen Wandel unberührt bleiben Technologische Neutralität Zur Abgrenzung der Essenz gehen wir von einer perfekten internen Technologie aus d. h. alle Komponenten haben unendliche Verarbeitungsgeschwindigkeit, haben unbegrenztes Fassungsvermögen, arbeiten absolut fehlerfrei. Systementwicklung

49 Inkarnation Definition
Die Inkarnation eines Systems ist die sichtbare Form des Systems im Betrieb d. h. die Gesamtheit aller Prozessoren, Speicher und sonstigen Hilfsmittel, die benutzt werden, um die Essenz des Systems zu implementieren. Bindung an reale, imperfekte Technologie: Prozessoren brauchen Zeit, können Fehler machen, verursachen Kosten Speicher haben nur eine endliche Kapazität, Speicherung unsicher Systementwicklung

50 Verschiedene Sichten Z.B. in der Geometrie:
Unabhängigkeit Jede Sicht abstrahiert jeweils von einer Dimension und ist daher von ihr unabhängig. Aber: Veränderungen einer Sicht i.A. mit Folgen für andere Sichten Vollständigkeit Die drei Sichten zusammen beschreiben den Körper vollständig Systementwicklung

51 Verschiedene Sichten bei der Modellierung von Unternehmensprozessen und Informationssystemen
Funktionssicht (Prozesssicht oder -modell): Beschreibt die Funktionen (man spricht auch von Prozessen, Vorgängen, Tätigkeiten, Aktivitäten oder Auf-gaben) und Teilfunktionen. Abstrahiert von der Zeit und damit vom Ablauf. Ablaufsicht (Dynamisches oder Ablaufmodell): Beschreibt welche Aktivi-täten, Vorgänge gleichzeitig oder nacheinander ablaufen. Abstrahiert von der Semantik der Daten. Datensicht (Datenmodell): Beschreibung der Daten, die in einem Prozess oder IS verarbeitet oder gespeichert werden. Abstrahiert von der Zeit, unabhängig von Ablaufsicht. Objektsicht (Objektmodell): Beschreibt einen Prozess oder ein IS als eine Menge von interagierenden Objekten. Abstrahiert vom Ablauf, Integration der Daten- und der Funktionssicht Organisationssicht: Beschreibt den Aufbau der Organisationseinheiten, die an einem Prozess oder IS beteiligt sind. Zur Aufbauorganisation gehören die Kommunikations- uns Weisungsbeziehungen zwischen den Einheiten Leistungssicht. Beschreibung der Ergebnisse der Prozessausführung durch Produktmodelle Systementwicklung

52 Fachkonzept und DV-Konzept
Im Rahmen der Entwicklung von IS wird wie beim Bau eines Hauses zunächst ein Modell entwickelt. Dabei wird unterschieden zwischen Fachkonzept und DVKonzept Beides sind Modelle von Geschäftsprozessen oder IS allerdings mit unterschiedlichem Konkretisierungsgrad Fachkonzept Beschreibt, was ein System tut abstrahiert vom Verfahren und von der Technik der Realisierung ist ein essentielles Modell DV-Konzept beschreibt die Struktur der DV-technischen Realisierung und Algorithmen beschreibt, was ein System tut und wie es dies tut ist abstrakter als die Inkarnation genauere Beschreibung später Keine scharfe Abgrenzung Systementwicklung

53 Systemanalysetechniken (1): Ereignisse, Auslöser, Antworten
Systementwicklung

54 Systemanalysetechniken (2): Ereignistabelle
Beispiel: Tante-Emma-Laden (Gemeint sind Unternehmensprozesse. Sie werden aber oft einfach mit dem Namen der Organisation bezeichnet, die sie ausführt.) Systementwicklung

55 Systemanalysetechniken (3): SA
Strukturierte Analyse (SA) Man beschreibt ein System durch im wesentlichen vier unterschiedliche Beschreibungsmittel: Kontextdiagramme geben einen Gesamtdarstellung des Systems Datenflussdiagramme beschreiben, welche Daten durch das System fließen und auf welchen Wegen sie dies tun. Das Datenlexikon legt fest, wie diese Daten strukturiert sind, sofern es sich nicht um primitive Daten handelt. Mini-Spezifikationen („minispecs“) beschreiben die Leistungen einzelner Systemteile. Systementwicklung

56 Systemanalysetechniken (4): DFD
Ein Datenflussdiagramm besteht aus vier Sorten von Objekten: Terminatoren, d.h. Endpunkte des Systems. Sie stellen die Grenz-linie des Systems zum Rest der Welt dar und grenzen somit den betrachteten (analytischen) Teil der Welt gegen die nicht betrach-tete Umwelt ab. Hier gelangen Daten ins System bzw. kommen aus dem System heraus. Prozesse, stellen die aktiven Komponenten eines Systems dar. Im Rahmen der SA interessiert man sich nur für das Ein/Ausgabever-halten der Prozesse, d.h. dafür, welche Eingabedaten sie verwenden und welche Ausgabedaten sie hieraus erzeugen. Datenspeicher, in welchen Daten abgelegt werden können. Sie repräsentieren Datenspeicher oder Datenträger.. Datenflüsse zwischen Terminatoren, Prozessen und Datenspeichern. Hierbei interessiert nicht nur die reine Tatsache, dass Daten fließen können, sondern auch, welche Daten hier fließen können. Systementwicklung

57 Systemanalysetechniken (5): DFD-Symbole
Beispiel: Übersichts-DFD Systementwicklung

58 Systemanalysetechniken (6): Datenlexikon
Definition Ein Datenlexikon ist eine endliche Menge von Datendefinitionen. Beispiel Personendaten = Name + Vorname + Geb-Datum + Adresse + (Tel.Nr.) + Familienstand + {Kind} Familienstand = [ledig|verheiratet|verwitwet|geschieden] Kind = Name + Vorname + Geb-Datum Adresse = Strasse + Hausnr. + PLZ + Stadt + (Staat) Systementwicklung

59 Systemanalysetechniken (7): DFD-Arten
Definition Ein DFD heißt Übersichts-DFD, wenn darin keine Speicher vorkommen. Ein Verfeinerungs-DFD ist ein DFD, in dem keine Terminatoren vorkommen. Beispiel Systementwicklung

60 Systemanalysetechniken (8): Beispiel
Systementwicklung

61 Systemanalysetechniken (9): Syntaktische Regeln für SA
jeder Datenfluß in jedem Diagramm muß mit mindestens einer Funktion/Prozess verbunden sein d.h. keine Datenflüsse zwischen Terminatoren und keine Datenflüsse zwischen Speichern keine Datenspeicher im Kontextdiagramm keine Terminatoren in Verfeinerungen jeder Speicher und jede Funktion/Prozess muß mindestens einen Zufluss und einen Abfluss besitzen jedes Objekt im DFD muß einen Namen besitzen (Ausnahme: Datenflüsse in oder aus Speichern, dabei sind Doppelpfeile eine Abkürzung für zwei einfache Pfeile) Systementwicklung

62 Beispiel: Flugkarten-Verkauf (1)
Aufgaben des Systems: Auskunft geben über Daten verfügbarer Flüge Buchen eines Flugs mit Ausgabe der Flugkarte (=Rechnung) und Anstoßen der Abwicklung des Zahlungsverkehrs durch die Buchhaltung. Systementwicklung

63 Beispiel: Flugkarten-Verkauf (2)
Kontextdiagramm Systementwicklung

64 Beispiel: Flugkarten-Verkauf (3)
Datenflussdiagramm Systementwicklung

65 Beispiel: Flugkarten-Verkauf (4)
Datenflussdiagramm von Funktion/Prozess(3): Flug aktualisieren Systementwicklung

66 Unified Modelling Language
Definition Die UML ist eine Sprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von System-Modellen. Wichtige Modellelemente der UML gegliedert nach Diagrammtypen Anwendungsfalldiagramm Klassendiagramm Aktivitätsdiagramm Kollaborationsdiagramm Sequenzdiagramm Zustandsdiagramm Komponentendiagramm Einsatzdiagramm Systementwicklung

67 Anwendungsfalldiagramm
Definition Ein Anwendungsfalldiagramm besteht aus einer Menge von Anwendungs-fällen und stellt die Beziehungen zwischen Akteuren und Anwendungs-fällen dar. Es zeigt das äußerlich erkennbare Systemverhalten aus der Sicht eines Anwenders. Notation Anwendungsfälle werden durch Ellipsen die den Namen des Anwendungs-falles tragen und einer Menge von beteiligten Objekten (Akteuren) darge-stellt. Zu jedem Anwendungsfall gibt es eine Beschreibung in Textform. Die Beschreibung kann ausführlich oder stichpunktartig erfolgen. Es em-pfiehlt sich aber eine inhaltliche Gliederung. Die entsprechenden Anwen-dungsfälle und Akteure sind durch Linien miteinander verbunden. Akteure können durch Strichmännchen o.ä. Symbole dargestellt werden. Die Sy-stemgrenze wird durch einen Rahmen um die Anwendungsfälle symbo-lisiert. Systementwicklung

68 Anwendungsfalldiagramm - Beispiel
Systementwicklung

69 Präzisierung des Begriffs Anwendungsfall
Problem der Begriffsbildung Ist die Erste Hilfe der Tante Emma an einem ohnmächtigen Kunden ein Anwendungsfall? Erste Hilfe ist eine mögliche Sequenz von Interaktionen, die von einem Akteur (Tante Emma) durchgeführt werden, um ein Ziel zu erreichen bzw. ein gewünschtes Ergebnis zu erstellen (z. B. stabile Seitenlage). Präzisierung der Definition: Anwendungsfall ist eine aus mehreren zusammenhängenden Aktionen (bzw. der Erfüllung mehrerer zusammenhängenden Aufgaben) bestehende, technologieunabhängig beschriebene, geplante Reaktion, die auf ein von einem Akteur (z. B.: Kunde) ausgelöstes externes Ereignis (z. B. Kunde wünscht Ware) oder ein Zeitereignis hin ausgeführt wird. Dabei können weitere Akteure involviert sein. Anwendungsfall (Use case) = essentieller Anwendungsfall (essentieller Use case) Systementwicklung

70 Textschablone zur Darstellung von Anwendungsfällen
Name: sollte aus einem aussagekräftigen Substantiv im Singular und einem starken Verb gebildet werden. Ziel: globale Zielsetzung bei erfolgreicher Ausführung Kategorie: primär (notwendig, häufig), sekundär (notwendig, selten), optional (nützlich, nicht notwendig) Vorbedingung: erwarteter Zustand vor Beginn der Ausführung Nachbedingung Erfolg: erwarteter Zustand nach erfolgreicher Ausführung Nachbedingung Fehlschlag: erwarteter Zustand nach fehlgeschlagener A. Akteure: Rollen von Personen oder anderen Systemen, die den Use case auslösen oder daran beteiligt sind Auslösendes Ereignis: Beschreibung: Normale Sequenz von Aktionen, Alternativen der Ausführung, Sonderfälle Systementwicklung

71 Beispiel: Use Case Tante-Emma-Laden
Systementwicklung

72 Beziehungen zwischen den Anwendungsfällen
Systementwicklung

73 Identifizierung von Anwendungsfällen (1)
Von den Akteuren ausgehen. Die folgenden Fragen an die Akteure stellen: Welches Ereignis löst den Auftrag aus? Welche Eingabedaten werden benötigt? Welche Schritte sind auszuführen? Ist eine Reihenfolge der Schritte festgelegt? Welche Zwischenergebnisse werden erstellt? Welche Vorbedingungen müssen erfüllt sein? Welche Nachbedingungen (Vorbedingungen anderer Anwendungsfälle) müssen sichergestellt werden? Wie wichtig ist diese Arbeit? Warum wird diese Arbeit durchgeführt? Kann die Durchführung verbessert werden? Systementwicklung

74 Identifizierung von Anwendungsfällen (2)
Sind die Akteure organisatorische Einheiten oder technische Schnittstellen: Ereignisse suchen: Welche Ereignisse der Umgebung sind für das System relevant? Worauf reagiert es geplant? Weitere Möglichkeit des Vorgehens: Aufgabenanalyse: Zweck, Ziele des Systems beschreiben Die zu ihrer Erreichung notwendigen Aufgaben auflisten. Die Ziele der wichtigsten Aufgaben bestimmen. Die zur Erreichung dieser Ziele notwendigen Aufgaben ableiten etc. Systementwicklung

75 Beispiel: Tante-Emma-Laden
Systementwicklung

76 Klassendiagramm Definition
Eine Klasse ist eine Menge von Objekten, in der die Eigenschaften (Attribute), Operationen und die Semantik der Objekte definiert werden. Alle Objekte einer Klasse entsprechen dieser Festlegung. Notation Klassen werden durch Rechtecke dargestellt, die den Namen der Klasse und/oder die Attribute und Operationen der Klasse enthalten. Klassen-name, Attribute und Operationen werden durch eine horizontale Linie getrennt. Der Klassenname steht im Singular und beginnt mit einem Groß-buchstaben. Attribute können näher beschrieben werden, z.B. durch ihren Typ, einen Initialwert und Zusicherungen. Sie werden aber mindestens mit ihrem Namen aufgeführt. Operationen können ebenfalls durch Parameter, Initialwerte, Zusicherungen usw. beschrieben werden. Auch Sie werden mindestens mit ihrem Namen aufgeführt. Systementwicklung

77 Woraus besteht ein Objektmodell?
Klassen mit Attributen und ihren Attributspezifikationen Operationen Beziehungen mit Angabe der Kardinalitäten insbesondere Generalisierungen (Zusammenfassung der Klassen in Pakete) Evtl. auch Objekte Systementwicklung

78 Vergleich des Objektmodells mit dem essentiellem Prozessmodell
Prozessmodell beschreibt ein System als Menge von Prozessen, die Daten austauschen Objektmodell beschreibt ein System als Menge strukturierter Klassen/Objekten (Daten), die Operationen auf ihren Daten ausführen können und miteinander kooperieren. Ergänzt man das Prozessmodell um eine geeignete Methodik zur Gestaltung der Speicher, dann erhält man einen Zusammenhang zwischen Prozessmodell und Objektmodell. Das Prozessmodell beschreibt welche Operationen der Klassen welche Daten untereinander austauschen und welche Operationen aus welchen anderen Operationen zusammengesetzt sind. Das Objektmodell beschreibt zusätzlich zum Prozessmodell, Beziehungen zwischen Daten (Klassen/Objekten). Systementwicklung

79 Beispiel: Flugbuchung (1)
Systementwicklung

80 Beispiel: Flugbuchung (2)
Systementwicklung

81 Attributspezifikation
Name Typ Anfangswert Muß-Attribut (mandatory): muß bei Anlegen des Objektes definiert werden Schlüssel (key): kennzeichnet das Objekt eindeutig, auch mehrere Attribute möglich Attributwert nicht änderbar (frozen): z.B. Matrikelnummer Einheit: (km, DM etc.) Beschreibung: Erläuterung bzw. Definition bei abgeleiteten Attributen Systementwicklung

82 Beziehungen Systementwicklung

83 Modellierung von Beziehungen als Klassen
Systementwicklung

84 Kardinalitäten Systementwicklung

85 3er Beziehungen Systementwicklung

86 Aggregation Spezielle Beziehung: Teil-Ganzes (part-whole)
Daher zusätzliche Eigenschaften (z.B. transitiv und antisymmetrisch) Systementwicklung

87 Komposition Komposition ist ein Spezialfall der Aggregation:
Jedes Objekt der Komponentenklasse kann nur Komponente eines Objektes der Aggregatklasse sein. D.h. Kardinalität der Aggregat-klasse in der Aggregation darf nicht größer als eins sein. Im all-gemeinen darf eine Komponente aber Komponente anderer Aggregate sein. Die dynamische Semantik des Ganzen gilt auch für seine Teile. Wird z.B.das Ganze kopiert, werden auch die Teile kopiert. Wird das Ganze gelöscht, so werden auch seine Teile gelöscht Systementwicklung

88 Aggregation und Komposition
Systementwicklung

89 Generalisierung und Vererbung
Modellierungsphase: Klarheit durch Modellierung von Gemeinsamkeiten Vereinfachung durch Reduzierung unabhängiger Features Implementationsphase: Wiederverwendung Systementwicklung

90 Beispiel: Generalisierung und Vererbung (1)
Systementwicklung

91 Beispiel: Generalisierung und Vererbung (2)
Systementwicklung

92 Beispiel: Generalisierung und Vererbung (3)
Systementwicklung

93 Probleme der Vererbung
Vererbung verletzt das Geheimnisprinzip Die Unterklasse kennt die Struktur der Implementation der Attribute und Operationen der Oberklasse. Vererbung verletzt das Lokalitätsprinzip Um die Unterklasse zu verstehen, muss man die Oberklasse kennen. Grenzen der Wiederverwendung Wird die Oberklasse neu implementiert, muss evtl. auch die Unterklasse neu implementiert werden. Systementwicklung

94 Schritte zur Konstruktion des Objektmodells
1. Identifizierung von Objekten/Klassen 2. Identifizierung von Beziehungen 3. Identifizierung von Attributen 4. Organisation des Modells mittels Vererbung 5. Iterationen und Verfeinerungen des Modells Systementwicklung

95 Problembeschreibung: Geldautomat
Erstellen Sie ein Modell eines Banknetzwerkes, das Geldschalter und Geldautomaten beinhaltet. Jede Bank hat ihren eigenen Computer, um Konten zu verwalten und um Transaktionen auf den Konten zu verarbeiten. Die zu den einzelnen Banken gehörenden Geldschalter kommunizieren direkt mit den Bankcomputern. Kassierer geben an den Geldschaltern die Kontonummer und die eigentliche Transaktion ein. Die Geldautomaten kommunizieren mit einem Zentralcomputer, welcher die vom Kunden gewählten Transaktionen an die jeweilige zuständige Bank weitergibt. Der bereitgestellte Zentralcomputer gehört einem Konsortium von Banken. Die Geldautomaten akzeptieren Scheckkarten, interagieren mit den Benutzern, kommunizieren mit dem Zentralcomputer, um Transaktionsdaten weiterzugeben und geben Geld aus. Das System besitzt besondere Sicherheitsvorkehrungen. Dazu gehört die korrekte Verarbeitung eines gemeinsamen Zugriffs auf ein Konto. Die Banken stellen für ihre Computer ihre eigene Software bereit. Sie sind also nur zuständig für die Entwicklung der Software für die Geldautomaten und das Netzwerk. Systementwicklung

96 Identifizierung von Objekten und Klassen (1)
Vorgehensweise Objekte und Klassen können oft durch Nominalphrasen in der Problembeschreibung (unstrukturiert oder strukturiert durch z.B. Use cases) identifiziert werden (Nominalphrasenanalyse). Kandidaten aus der Problembeschreibung müssen überprüft werden. Systementwicklung

97 Identifizierung von Objekten und Klassen (2)
Klassenkandidaten Systementwicklung

98 Identifizierung von Objekten und Klassen (3)
Kriterien zur Wahl der richtigen Klassen Eine Klasse für ein Konzept (keine redundanten Klassen) Eliminierung von irrelevanten Klassen (Klassen, die nicht zum Problembereich gehören). Eine Klasse sollte spezifisch sein (keine unklaren Klassen, die mehrere Bedeutungen haben können). Wörter, die ein Objekt näher beschreiben, sollten als Attribut modelliert werden. Besteht die unabhängige Existenz eines Wortes, sollte dieses als Klasse modelliert werden. Operationen mit Merkmalen sollten als Klassen modelliert werden. Rollen sind Beziehungen, keine Klassen. Implementierungskonstrukte werden erst im Design modelliert. Systementwicklung

99 Identifizierung von Objekten und Klassen (4)
Eliminierung unnötiger Klassen Systementwicklung

100 Identifizierung von Beziehungen
Vorgehensweise Beziehungen können oft durch Verbalphrasen in der Problembeschreibung (unstrukturiert oder strukturiert durch z.B. Use cases) identifiziert werden (Verbalphrasenanalyse). Kandidaten aus der Problembeschreibung müssen analysiert werden. Systementwicklung

101 Beziehungskandidaten aus der Problembeschreibung
Banknetzwerk beinhaltet Geldschalter und Geldautomaten Bank hat Computer Bankcomputer verwaltet Konten Bankcomputer verarbeitet Transaktionen auf Konten Bank gehören Geldschalter Kassierer geben Transaktionen für Konten ein Geldautomaten kommunizieren mit Zentralcomputer über Transaktionen Zentralcomputer gibt Transaktionen weiter an Banken Zentralcomputer gehört Konsortium Konsortium besteht aus Banken Geldautomat akzeptiert Scheckkarten Geldautomat interagiert mit Benutzer ... Systementwicklung

102 Identifizierung von Attributen
Vorgehensweise Die Problembeschreibung bietet selten die Möglichkeit, einen Großteil der Attribute zu identifizieren, statt dessen muß auch das Anwendungswissen herangezogen werden. Zuerst sollten nur die wichtigsten Attribute gesucht werden, andere können später identifiziert werden. Insbesondere sollten keine Attribute modelliert werden, die nur für die Implementierung von Bedeutung sind. Systementwicklung

103 Aktivitätsdiagramm Definition
In einem Aktivitätsdiagramm werden die Objekte eines Programms mittels der Aktivitäten, die sie während des Programmablaufs vollführen, be-schrieben. Eine Aktivität ist ein einzelner Schritt innerhalb eines Pro-grammablaufs, d.h. ein spezieller Zustand eines Modellelementes, eine interne Aktion sowie eine oder mehrere von ihm ausgehende Transitionen enthält. Gehen mehrere Transitionen von der Aktivität aus, so müssen diese mittels Bedingungen von einander zu entscheiden sein. Somit gilt ein Aktivitätsdiagramm als Sonderform eines Zustandsdiagramms, dessen Zustände der Modellelemente in der Mehrzahl als Aktivitäten definiert sind. Notation Eine Aktivität wird durch ein „Rechteck“ mit konvex abgerundeten Seiten visualisiert. Sie enthält eine Beschreibung der internen Aktion. Von der Aktivität aus gehen die Transitionen, die den Abschluss der internen Aktion und den Übergang zur nächsten Aktivität darstellen. Systementwicklung

104 Aktivitätsdiagramm - Beispiel
Systementwicklung

105 Kollaborationsdiagramm
Definition Die verschiedenen Modellelemente eines Programmes agieren innerhalb des Programmablaufes miteinander. Um diese Interaktionen für einen bestimmten begrenzten Kontext, unter besonderer Beachtung der Be-ziehungen unter den einzelnen Objekten und ihrer Topographie, darzu-stellen, verwenden wir das Kollaborationsdiagramm. Notation Die einzelnen Objekte werden als Rechtecke dargestellt. Diese werden durch Assoziationslinien mit einander verbunden, auf denen dann die Nachrichten, bestehend aus einer durchgehenden zeitlichen Nummerie-rung, dem Namen der Nachrichten und Antworten und ihren möglichen Argumenten. Ein Pfeil zeigt die Richtung der Nachricht vom Sender zum Empfänger. Antworten werden in der Form antwort:=nachricht() symbolisiert. Die zeitliche Nummerierung erfolgt mittels Durchnummerierung der einzelnen Nachrichten angefangen bei 1, die interaktionsauslösende Startnachricht erhält noch keine Nummerierung. Systementwicklung

106 Kollaborationsdiagramm - Beispiel
Systementwicklung

107 Sequenzdiagramm Definition
Das Sequenzdiagramm beschreibt die zeitliche Abfolge von Interaktionen zwischen einer Menge von Objekten innerhalb eines zeitlich begrenzten Kontextes. Notation Die Objekte werden durch Rechtecke visualisiert. Von Ihnen aus gehen die senkrechten Lebenslinien, dargestellt durch gestrichelte Linien, ab. Die Nachrichten werden durch waagerechte Pfeile zwischen den Objektlebens-linien beschrieben. Auf diesen Pfeilen werden die Nachrichtennamen in der Form: nachricht(argumente) notiert. Nachrichten, die als Antworten deklariert sind erhalten die Form: antwort:=nachricht(). Nachrichten können Bedingungen der Form: [bedingung] nachricht() zugewiesen be-kommen. Iterationen von Nachrichten werden durch ein Sternchen „*“ vor dem Nachrichtennamen beschrieben. Objekte, die gerade aktiv an Inter-aktionen beteiligt sind, werden durch einen Balken auf ihrer Lebenslinie zu kennzeichnen. Systementwicklung

108 Sequenzdiagramm - Beispiel
Systementwicklung

109 Zustandsdiagramm Definition
Ein Objekt kann in seinem Leben verschiedenartige Zustände annehmen. Mit Hilfe des Zustandsdiagramms visualisiert man diese, sowie Funktionen, die zu Zustandsänderungen des Objektes führen. Notation Im Zustandsdiagramm werden die Zustände als abgerundete Rechtecke verbunden durch Pfeile, auf denen die Transitionen stehen, visualisiert. Startzustand ist ein gefüllter Kreis, die Endzustände sind leere Kreise mit einem kleineren gefüllten in der Mitte. Systementwicklung

110 Zustände Definition Zustand = Abstraktion der Gesamtheit der Merkmalsausprägungen eines Systems. Merkmale und Ausprägungen müssen zunächst nicht definiert sein. In einem Zustand qualitativ homogene Reaktion auf Events. In verschiedenen Zuständen mindestens für ein Event eine unterschiedliche Reaktion. Übergänge zwischen zwei Zuständen durch Events. Ein System reagiert in einem Zustand nicht auf ein bestimmtes Event gdw. für dieses Event ist kein Zustandsübergang eingetragen. Systementwicklung

111 Zustandsdiagramm - Beispiel (1)
Systementwicklung

112 Zustandsdiagramm - Beispiel (2)
Systementwicklung

113 Zustandsdiagramm mit bedingten Übergängen - Beispiel (3)
Systementwicklung

114 Komponentendiagramm Definition
Damit bei späterer Implementierung der Softwarelösung Compiler- und Laufzeitabhängigkeiten klar sind, werden die Zusammenhänge der einzel-nen Komponenten der späteren Softwarelösung in einem Komponenten-diagramm dargestellt. Notation Die einzelnen Komponenten werden als Rechtecke dargestellt, die den Namen und den Typ der jeweiligen Komponente enthalten. An deren linken Rand tragen sie eine Ellipse sowie 2 Rechtecke. Eine Komponente kann wiederum weitere Elemente, wie Objekte, Komponenten oder Knoten enthalten und Schnittstellen besitzen. Die Abhängigkeiten zwischen den einzelnen Komponenten werden durch gestrichelte Pfeile symbolisiert. Die in dieser Art dargestellten Abhängigkeiten zeigen die spätere Compilierreihenfolge auf. Systementwicklung

115 Komponentendiagramm - Beispiel
Systementwicklung

116 Einsatzdiagramm Definition
Ein Einsatzdiagramm beschreibt, welche Komponenten (Objekte) auf welchen Knoten ablaufen, d.h. wie diese konfiguriert sind und welche Abhängigkeiten bestehen. Notation Knoten werden im Einsatzdiagramm als Quader visualisiert. In den Knoten können die dort ablaufenden Komponenten(Objekte) dargestellt werden, wobei auch Schnittstellen und Abhängigkeitsbeziehungen zwischen den Elementen erlaubt sind. Knoten die miteinander kommunizieren werden durch Linien miteinander verbunden. Systementwicklung

117 Einsatzdiagramm - Beispiel
Systementwicklung