3. Systemanalyse und Systemmodellierung

Transkript

1 3. Systemanalyse und Systemmodellierung Test, Integration Wartung Analyse Entwurf Implementierung Anforderungsermittlung Systemmodellierung Literatur: Sommerville 7 Balzert LE Modellierungssprachen Seite 1

2 Modellierung Definition Ein Modell ist eine Abstraktion irgendeines Gegenstands oder Sachverhalts umfaßt meist nur Teilaspekte des Beschreibungsgegenstands zielt auf besseres Verständnis des Beschreibungsgegenstands Modelle werden angewandt zur Analyse und Darstellung existierender komplizierter Strukturen zur Beurteilung ingenieurtechnischer Produkte vor ihrer Herstellung Beispiele für Modelle: Architektur: Architekturmodelle, Pläne,... Medizin: Anatomiemodelle, biochemische Modelle Theater und Film: Drehbücher, Ablaufpläne, Choreographien,... Softwaretechnologie: Phasenmodelle, Analysemodelle, Entwurfsmodelle,... Modellebenen im Software Engineering Informationsverarbeitendes System: Technisches Modell der realen Welt Arbeitet mit Repräsentationen realer Information Analysemodell eines fachlichen Aufgabenbereichs: Abstraktes Modell der realen Welt Entwurfsmodell des informationsverarbeitenden Systems: Abstrakte Darstellung der Systemstruktur Meta-Modelle: Darstellung der Struktur von Modellierungssprachen Phasenmodelle (Prozessmodelle): Darstellung der Struktur des Entwicklungsprozesses Phasen, Stufen, Zwischenergebnisse Unternehmensmodelle: Darstellung der Struktur und Arbeitsabläufe realer Wirtschaftsunternehmen Seite 2

3 Mehrdimensionalität Mehrere komplementäre Modelle ("Ansichten" des Beschreibungsegenstands). "Modell": Einzelansicht, oder auch Gesamtheit der Einzelansichten Beispiele: In UML:» Strukturmodell» Verhaltensmodell» Architekturmodell In Strukturierter Analyse (SA):» Datenflußmodell» Entity-Relationship-Modell» Data Dictionary 3.2 Strukturierte Analyse Literatur: Balzert LE 14 DeMarco: Structured Analysis and System Specification, 1978 McMenamin/Palmer: Essential Systems Analysis, 1984 Yourdon: Modern Structured Analysis, 1989 Seite 3

4 Notationen von SA Datenflußdiagramm (DFD) Strukturierung des Systems Funktionen und Daten und ihr Zusammenwirken Data Dictionary (DD) Strukturierung der Daten Detaillierte Datenbeschreibung Funktionsbaum Strukturierung der Funktionen Mini-Spezifikationen Detailierte Funktionsbeschreibung 8 Schritte zum SA-Modell 1. Schnittstellen und Ein/Ausgaben finden 2. Funktionen finden 3. Speicher finden 4. Datenflüsse finden 5. Data Dictionary erstellen 6. Konsolidieren des Modells 7. Iterative Verfeinerung 8. Mini-Spezifikationen erstellen (nach Balzert) Seite 4

5 Kontext der Seminarverwaltung Kunde Dozent verwalte Seminare und Kunden Kontextdiagramm der Seminarverwaltung Kunde Anfrage, Buchung Mitteilung, Rechnung Kundenanfragen Auskünfte verwalte Seminare und Kunden Buchhaltung Zahlungsverzug Rechnungs daten Seminarsachbearbeiter Dozentendetails Katalog, Auskünfte Veranstaltungsinfo. Seminaranfragen Dozent Kundensachbearbeiter Seminarsachbearbeiter Buchhaltung Kundensachbearbeiter Seite 5

6 Ebene 0 der Seminarverwaltung Anfrage, Buchung Mitteilung, Rechnung Kundenanfragen Auskünfte verwalte Seminare und Kunden 1 verwalte Kunden 2 verwalte Dozenten 3 verwalte Seminare Dozentendetails Veranstaltungsinfo. Seminaranfragen Zahlungsverzug Rechnungs daten Katalog, Auskünfte Datenflußdiagramm Ebene 0 Anfrage, Buchung Mitteilung, Rechnung Kundenanfragen Auskünfte Rechnung, Zahlungsvz. Rechnungen 1 betreue Kunden Rechnung, Zahlungsvz. Kunden & Seminare Seminardaten Seminar- Teilnahmen Zahlungsverzug Dozentendaten 4 behandle Rechnungen 2 verwalte Dozenten 3 verwalte Seminare Dozentendetails Veranstaltungsinfo. Seminaranfragen 4 behandle Rechnungen Zahlungsverzug Rechnungs daten Katalog, Auskünfte Seite 6

7 Datenfluß-Verfeinerung (Ebene 1) Anfrage, Buchung Bestätigung/Ausgebucht, Rechnung, Mahnung, Stornierung Mitteilung, Rechnung Rechnung, Zahlungsvz. Rechnungen 1 betreue Kunden Kunden & Seminare Rechnungen 1.1 buche Veranstaltg. Rechnung, Zahlungsvz. Kundendaten, Seminarstatus Kunden & Seminare Mitteilung Bestätigung/Ausgebucht Mahnung Stornierung Entity-Relationship-Modelle in SA Moderne Versionen von SA berücksichtigen Datenmodellierung z.b. Yourdon, McMenamic/Palmer, SSADM Datenmodellierung als separate Aktivität Entity-Relationship-Diagramm Konsolidierung mit Speichern des DFDs Z.B. (SSADM) Korrespondenztabelle Speicher/ER-Diagramm: Speicher Entities Relationships Kunden & Seminare Kunde nimmt_teil Seminar Rechnungen Rechnung Seite 7

8 SD: Von der SA-Analyse zum Entwurf "Structured Design" (SD) Stevens, Yourdon/Constantine, Myers, Page-Jones Definition von Transformationsstrukturen auf Basis von DFDs Darstellungsform: Structure Charts (SCs) Aufgabe C C korr. DFD: A Hole C B B C Hole B Transf. B->C Schreibe C B C A Lese A A B Transf. A->B Transaktions- und Transformationsanalyse Transaktionsanalyse Finden von Ketten» auslösendes Ereignis (event, stimulus)» Systemaktivität (activity)» Systemantwort (response)» Effekt (effect) Transformationsanalyse Für jede Transformationskette von Eingabe in Ausgabe:» "Zentrale Transformation" finden» Funktion der zentralen Transformation oder neue Funktion wird Koordinator (Wurzel eines SC)» Erstellen eines SC entsprechend der Daten-Transformation Seite 8

9 Zusammenfassung SA Ausgangspunkt: Kontextdiagramm (ähnlich Use-Cases) Ergebnis: Abgestimmte Modelle von Funktionalität und Datenhaltung Methodisches Vorgehen der schrittweisen Verfeinerung In verschiedenen Detaillierungsgraden anwendbar Unbefriedigende Integration mit Datenmodellierung Sprachebenenwechsel nötig für Entwurf ("Strukturbruch") Eingeschränkte Systemarchitektur (Baumstrukturen) Keine Sicherstellung des Lokalitätsprinzips 3.3 Objektorientierte Analyse Literatur: Balzert LE 14 J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen: Object-oriented modeling and design, 1991 G. Booch, J. Rumbaugh, I. Jacobson: The Unified Modeling Language User Guide, 1999 Seite 9

10 Prinzipien der Objektorientierung Ein System besteht aus vielen Objekten. Grundprinzipien: Ein Objekt hat ein definiertes Verhalten. Verhalten besteht aus einer Menge genau definierter Operationen Eine Operation wird beim Empfang einer Nachricht ausgeführt. Ein Objekt hat einen inneren (privaten) Zustand. Resultat einer Operation hängt vom aktuellen Objektzustand ab. Ein Objekt hat eine eindeutige Identität. Erweiterte Prinzipien: Ein Objekt gehört zu einer Klasse. Klasse definiert Verhaltensschema und innere Struktur. Vererbung gibt Verhaltensschema und innere Struktur an spezialisierte Klassen weiter. Die gleiche Nachricht kann bei Objekten verschiedener Spezialklassen verschiedene Operationen auslösen (Polymorphie). Vorteile von Objektorientierung Stabilität durch Lokalitätsprinzip: Kombination von Daten und Operationen ermöglicht lokale Änderungen durch Schnittstellendefinitionen: Entkopplung aufrufender Programmteile von der Realisierung der aufgerufenen Programmteile Wiederverwendung durch Bausteinprinzip: Systemkomponenten können aus Bibliotheken entnommen werden bzw. in anderem Kontext wieder sinnvoll eingesetzt werden Änderungsfreundlichkeit durch Bausteinprinzip: Austausch und Ergänzung von Bausteinen durch Abstraktionsebenen: Vererbung und Polymorphie ermöglichen das einfache Ableiten von verschiedenen Varianten einer prinzipiellen Lösung Seite 10

11 Risiken von Objektorientierung Hoher Einführungsaufwand Umschulung von traditionellen auf objektorientierte Sprachen Umstellung von Prozessen und Werkzeugen Mangelhafte Effizienz Objektverwaltung und Schnittstellen erzeugen "Overhead" Kompatibilitätsprobleme mit vorhandenen Systemen, z.b. relationalen Datenbanken Moderne Sprachen (Smalltalk, Java) sind teilweise interpretiert Instabilität durch Klassenabhängigkeiten Unübersichtliche Klassenhierarchien Übermäßiger oder unangemessener Gebrauch von Vererbung erzeugt Abhängigkeiten Undokumentierte Klassenabhängigkeiten Methodik der Objektorientierten Analyse Klassen finden Assoziationen und Aggregationen finden Attribute finden Operationen finden Szenarien finden und prüfen Vererbungsstrukturen finden Operationen finden Szenarien finden und prüfen Attribute finden Assoziationen und Aggregationen finden Vererbungsstrukturen finden Datenorientierte Vorgehensweise z.b. OMT Objekt-Lebenszyklen erstellen Operationen spezifizieren Strukturen überprüfen Subsysteme finden Verhaltensorientierte Vorgehensweise z.b. OOSE Seite 11

12 Klassendiagramm der Seminarverwaltung Firma Seminartyp QualDozenten 0..1 Typ 1 0..* 0..* Referent Teilnehmer 1..* Dozent Mitarbeiter 0..* 1 0..* 0..* 0..* 1..* 1 Leiter Kunde Buchung Veranstaltung 0..* 1 0..* 0..* Attribute und Operationen Kunde kunden_nr: 1..max_Kunden_Nr name: String_Name adresse: Record_Addresse geburtsdatum [0..1]: Date ersterfassung: Date notizen: String_Notizen umsatz: Integer_Umsatz = 0 anzahl_kunden: Integer drucke_adresse drucke_mitteilung erstelle_serienbrief Veranstaltung veranst_nr: 1..max_Veranst_Nr von, bis: Date ort: String_Ort teiln_min: Integer = default_teiln_min teiln_max: Integer = default_teiln_max teiln_akt: Integer = 0 öffentlich: Boolean = true storniert: Boolean = false storniere erstelle_teilnehmerliste erstelle_teilnehmerurkunden Seite 12

13 Vererbungsstruktur "Person" Person pers_nr: 1..max_Pers_Nr name: String_Name adresse: Record_Addresse geburtsdatum [0..1]: Date ersterfassung: Date notizen: String_Notizen anzahl: Integer drucke_adresse drucke_mitteilung erstelle_serienbrief Kunde Dozent Mitarbeiter umsatz: Integer = 0 honorar: Integer berechtigung Objekt-Lebenszyklus: Beispiel Klasse "Veranstaltung" Ändern Erfassen Freigeben in Planung Löschen storniert fällt aus do/ stornieren Absage / Abs. Eintragen fällt aus buchend ausgebucht [ist voll] Anmeldung / Anm. Eintragen Absage / Abs. Eintragen [abgelaufen] [abgelaufen] durchgeführt / Archivieren ist_voll: teiln_akt = teiln_max abgelaufen: today >= bis Seite 13

14 Operationen spezifizieren Zusatzinformation zu Operationen: Formale Parameter Verwendungsart der Parameter (in, out, inout) Datentypen der Parameter Resultat-Datentyp Beschreibung der Semantik der Operationen: Kommentar Pseudo-Code Vor- und Nachbedingungen Invarianten Für Entwurf der Benutzungsoberfläche: Abgeleitete Operationen beschreiben ("Kunde bearbeiten") Beispiel: Invariante "Jede Seminarveranstaltung muß von einem qualifizierten Referenten durchgeführt werden." Diese Eigenschaft ist im Klassenmodell nicht sichergestellt! Object Constraint Language (OCL): Teil von UML erlaubt präzise Spezifikation von Invarianten, Vor- und Nachbedingungen context Veranstaltung inv: this.typ.qualdozenten -> includes(this.referent) Seite 14

15 Subsysteme finden Ein Subsystem ist eine Gruppe von Klassen und Aggregationen/Assoziationen. Ein Subsystem: ist für sich allein verständlich hat eine wohldefinierte Schnittstelle zur Umgebung ermöglicht eine Betrachtung des Systems aus einer abstrakteren Sicht Starke Bindung innerhalb des Subsystems Schwache Kopplung zwischen Subsystemen Faustregeln für ein sinnvolles (Sub-)System: Klassen 1 DIN A4 Seite Darstellung von Subsystemen in UML: Pakete Subsysteme: Beispiel Personal- und Kundenverwaltung Seminarverwaltung Person Seminartyp Mitarbeiter Dozent Veranstaltung Kunde Buchung Firma Seite 15

16 Zusammenfassung OOA Objektorientierung bietet prinzipielle Vorteile bezüglich Stabilität, Änderungsfreundlichkeit und Wiederverwendbarkeit Alternative Vorgehensweisen: datenorientiert verhaltensorientiert Verschiedene Sichten und Detaillierungsebenen Kernstück: Klassendiagramm ergänzend: Zustandsdiagramme, Sequenzdiagramme, Use-Case- Diagramme Anbindung an Anforderungen durch Anwendungsfälle (use cases) und Szenarien Einheitliche Notation für Analyse (OOA) und Entwurf (OOD) Erste Ansätze zur systematischen Aufarbeitung von Analyseerfahrung: Analysemuster Von SA-Modellen zu UML-Modellen Kunden erfassen Kunden Adresse ändern Kunde erfassen Adresse Ändern SA-Modellierung im Vorlauf zu OOA Zerlegung von DFD-Speichern in "atomare Speicher" (Klassen) Klasse = ein Speicher + Teil der umgebenden Funktionen Seite 16

17 Kontext-Diagramm und Use-Case-Diagramm Seminarverwaltung Teilnehmer Veranstaltung anbieten Veranstaltung stornieren Sachbearbeiter Programmverwalter Seminarverwaltung Teilnehmer Sachbearbeiter Programmverwalter Datenflüsse in UML: Objektfluß Definition: Ein Objektfluß ist eine Beziehung zwischen zwei Zuständen eines Aktivitätsdiagramms, die die Weitergabe von Information (in Form eines Objektes) beschreibt. Ein Objektfluß bedeutet implizit auch einen Zustandsübergang. Notation: Zustand 1 Objekt Zustand 2 Beispiel: Teilnehmer Sachbearbeiter vorbereiten... Anmeldung Zusage Anmeldung prüfen... Seite 17

18 Vergleich OOA - SA SA ist informeller DFDs (SA) sind leichter verständlich für Informatik-Laien DFDs unterstützen gestufte Abstraktionsebenen SA ist weit verbreitet (gute Werkzeugunterstützung) OOA ist abstrakter OOA liefert leichteren Übergang zum Entwurf OOA berücksichtigt moderne Strukturprinzipien OOA verbessert Wiederverwendung OOA integriert (seit neuestem) SA-Konzepte in verbesserter Form Use-Case-Diagramm - Kontextdiagramm Datenflußdiagramm - Aktivitätsdiagramm mit Objektfluß Transaktionsanalyse - Szenarien OOA und UML sind inzwischen fest etabliert (schnelle Entwicklung bei den Werkzeugen) Seite 18