3. OEP

OEP (Object Engineering Process) ist ein von Bernd Oestereich entwickeltes auf OOAD (objektorientierte Analyse und Design), UML und UP (Unified Process) basierendes Vorgehensmodell zur objektorientierten Softwareentwicklung. OEP ist ein iterativ-inkrementeller, agiler, anwendungsfallgetriebener, architekturzentrierter Entwicklungsprozess. OEP ist zugeschnitten auf die Entwicklung betrieblicher Informationssysteme als mehrschichtige objektorientierte Client-Server-Architektur und weniger gut geeignet für die Entwicklung technischer Systeme.

Weiteres siehe http://www.oose.de/oep.

Es folgt eine vereinfachte Kurzübersicht zu den von Oestereich fürdie objektorientierte Analyse (OOA) vorgeschlagenen Schritten(anders als hier dargestellt teilweise iterativ; ausführlicheBeschreibung siehe Buch:Oestereich, Objektorientierte Softwareentwicklung, 3486255738):

1. Systemidee und Zielsetzung entwickeln:
   Was soll erreicht werden, Ideen, Visionen, Absichtsbekundungen und Wünsche. Freitext, ca. halbe Seite.
   
2. Anforderungsbeitragende (Stakeholder) identifizieren:
   Auftraggeber, Gesetzgeber, Projektbetroffene, Systembetroffene, Anwender, Kunden, Support, Vertrieb und Projektgegner. Tabellarische Unterscheidung in: Fachexperten, Anforderungsverantwortliche und Systembetroffene/Akteure.
   
3. Geschäftsprozesse identifizieren:
   Systemidee mit UML-Anwendungsfalldiagramm (Use Case Diagram, «workflow») visualisieren. Geschäftsprozesse mit jeweils einem UML-Aktivitätsdiagramm (Ablaufdiagramm mit zeitlich aufeinander folgenden Schritten) abstrakt beschreiben. Fachliche und am Geschäft beteiligte Akteure abstrakt beschreiben.
   Ein Anwendungsfall (Use Case) beschreibt eine zeitlich ununterbrochene Interaktion eines oder mehrerer Akteure mit einem System.
   Ein Geschäftsprozess kann aus mehreren Anwendungsfällen bestehen und stellt eine Zusammenfassung von fachlich zusammenhängenden Aktivitäten dar, die durchgeführt werden, um einen Geschäftsvorfall ergebnisorientiert zu bearbeiten.
   Ein Geschäftsvorfall (z.B. Antrag) entsteht durch ein Ereignis (z.B. Antragseingang) und hat fachliche Ergebnisse (z.B. Vertrag).
   
4. Interessen der Anforderungsbeitragenden (Stakeholder) identifizieren:
   Beschreibung der Ziele und Interessen, Aufzählung wichtiger geforderter Systemeigenschaften und Identifizierung von Problemen und Schwachstellen, alles aus Sicht der Anforderungsbeitragenden.
   
5. Geschäftsanwendungsfälle (Business Use Case) identifizieren:
   Identifizierung der Geschäftsanwendungsfälle («business») (eventuell in Form von Stories) und deren Auslöser und Ergebnisse sowie Identifizierung auszuschließender Geschäftsanwendungsfälle («business» {excluded}).
   Ein Geschäftsanwendungsfall (Geschäftsfall, Business Use Case) beschreibt einen Anwendungsfall in abstrakter fachlicher Form aus Sicht des Anwenders.
   
6. Anwendungsfälle essentiell beschreiben:
   Beschreibung der geschäftlichen Intentionen der Geschäftsanwendungsfälle («essential»). Definition der Auslöser, Vorbedingungen und eingehenden Informationen sowie der Ergebnisse, Nachbedingungen und ausgehenden Informationen. Entkopplung der Anwendungsfälle zu einzelnen kohärenten fachlichen Sachverhalten (eventuell mit «include» und «extend»).
   
7. Systemanwendungsfälle identifizieren:
   Konkretisierung der essentiellen Anwendungsfallbeschreibungen unter Berücksichtigung konkreter Umgebungsbedingungen, Anforderungen und technischer Gegebenheiten. Eventuell Aufteilung eines essentiellen Geschäftsfalls in mehrere Systemanwendungsfälle, wenn unterschiedliche technische Systeme verwendet werden (z.B. Telefon, Fax, E-Mail, Web).
   
8. Materialsammlung und -studie:
   Untersuchung von bestehenden Materialien, Gegenständen, Beispielen, Muster, Formulare, Vordrucke, Korrespondenzen und Beschreibungen.
   
9. Anforderungen (Requirements) beschreiben:
   Funktionale Anforderungen (Anwendungsfälle), Benutzbarkeit (Usability), Effizienz (Performance), Zuverlässigkeit (Reliability), Änderbarkeit / Erweiterbarkeit / Wartbarkeit / Administrierbarkeit (Supportability), Gesetze, Standards und Testanforderungen. Unterscheidung in Pflichtanforderungen, optionale Anforderungen, Absichten, Vorschläge und Kommentare.
   
10. Geschäftsklassen identifizieren:
    Identifizierung der fachlichen Gegenstände/Konzepte und Modellierung der strukturellen fachlichen Zusammenhänge in einem einfachen Analyse-Klassenmodell, ohne zu viele Details, aber mit Assoziationen, Assoziationsrollen und Multiplizitäten. Das Analyse-Klassenmodell soll für den Auftraggeber oder die Fachabteilung verständlich sein.
    
11. Fachliches Glossar anlegen:
    Definition und Begriffskonsolidierung aller fachlichen Begriffe, aller Klassen des Analyse-Klassenmodells und aller Assoziationsrollen.
    
12. Anwendungsfall-Ablaufmodell entwickeln:
    Modellierung aller Anwendungsfälle sowohl des Standardablaufs als auch des vollständigen Ablaufs inklusive aller fachlichen Ausnahmen und Varianten in UML-Aktivitätsdiagrammen. Für alle elementaren Aktivitäten Modellierung sowohl aller eingehenden als auch aller resultierenden Objekte und Daten in zu UML-Objektflussdiagrammen erweiterten Aktivitätsdiagrammen.
    
13. Systemschnittstelle beschreiben:
    Schnittstellenbeschreibungen zu allen ein- und ausgehenden Daten, Objekten und Ereignissen. Beschreibung der Dialoge, Ausgabeerzeugnisse, Daten-Schnittstellen und funktionalen Schnittstellen.
    
14. Exploratives Schnittstellen-Prototyping:
    Häufig lauffähige und benutzbare Sequenzen von Dialogentwurfprototypen. Eventuell auch Auswertungen, Formulare, Simulationen oder Berechnungen.
    

Das objektorientierte Design (OOD) könnte folgendermaßen ablaufen:

1. Anwendungsarchitektur definieren:
   Systemdesign bezieht sich auf bestimmte Anwendungsarchitektur, die zuerst definiert werden muss. Eine übliche Anwendungsarchitektur wäre eine komponentenbasierte Three-Tier-Architektur mit einer Präsentationsschicht auf den Clients (Dialog-Steuerung), einer Geschäftslogikschicht auf Servern (Dialog-Agent, Workflow-Steuerung, Anwendungsfallsteuerung, fachliche Komponente, externe Komponenten) und einer zentralen Datenhaltung (Datenbankserver).
   
2. Fachliche Komponenten identifizieren:
   Definition eines ersten fachlichen Komponentenmodells auf Basis des Analyse-Klassenmodells, von Workflow-Komponenten («workflow») zu jedem Geschäftsprozess und von Anwendungsfallsteuerungskomponenten («use-case-control») zu jedem Anwendungsfall.
   
3. Komponentenspezifische Klassenmodelle entwickeln:
   Entwicklung von lösungsorientierten komponentenspezifischen Design-Klassenmodellen für jede Komponente. Auflösung komponentenübergreifender Klassenbeziehungen und Ersetzung durch komponentengerechte Schnittstellen (Factory-, Observer-, Object-Interface).
   
4. Zustandsmodelle (weiter-)entwickeln:
   Identifizierung der fachlichen Zustände, der Zustandsänderungen verursachenden Operationen, der zustandsabhängigen Operationen und der Nachfolgezustände im UML-Zustandsdiagramm. Zustandsmodellierung z.B. mit Zustandsautomat, Zusicherungen, Zustandsattributen oder Zustands-Entwurfsmuster.
   
5. Komponentenabhängigkeiten identifizieren und ggf. restrukturieren:
   Überprüfung sowohl der strukturellen als auch der dynamischen Zusammenhänge und Abhängigkeiten zwischen den Komponenten mit dem Ziel der Minimierung der Kopplungen und Abhängigkeiten. Per zu UML-Objektflussdiagrammen erweiterten Aktivitätsdiagrammen (oder alternativ per UML-Sequenz- oder -Kollaborationsdiagramm) werden separierbare Verantwortlichkeitsbereiche (swim lanes) ermittelt.
   
6. Komponentenschnittstellen entwerfen:
   Aus Aktivitäten (z.B. der Anwendungsfallsteuerungskomponente und der fachlichen Komponenten) werden Schnittstellenbeschreibungen («interface») und Datentransferobjekte («structure») abgeleitet.
   
7. Zusammenarbeitsmodelle entwickeln:
   UML-Sequenz- oder -Kollaborationsdiagramme für alle Anwendungsfälle sowohl für den Standardablauf als auch die wichtigsten Ablaufvarianten entwerfen. In der Regel dienen diese Diagramme nur zur Ermittlung von Erkenntnissen über die benötigten Operationen und Datentransferobjekte und werden im weiteren Verlauf nicht mehr benötigt.
   
8. Ablauforientierte Komponententests entwickeln:
   Entwurf von Tests für alle Anwendungsfälle und Schnittstellen, möglichst automatisierbar (z.B. mit JUnit).
   
9. Klassentests entwickeln:
   Entwurf von Tests für alle Operationen unter Berücksichtigung aller möglichen Zustände/Umgebungsbedingungen, möglichst automatisierbar (z.B. mit JUnit).
   
10. Attribute definieren:
    Überprüfung aller Klassenattribute (z.B. Klassenzuordnung, eventuell eigene Klasse, Enumeration, Zusicherungen).
    
11. Dialoge spezifizieren:
    Zuordnung der Dialogkontexte und Dialogkomponenten zu Aktivitäten der UML-Aktivitätsdiagramme und zu Subsystemen. Spezifizierung der Dialogkomponenten und Definition von clientseitig auszuführenden Vorabüberprüfungen.
    
12. Überprüfung des Designs:
    Prinzipien der Objektorientierung, Design Patterns, Architektur, Namenskonventionen, Konsistenz, Effizienz, Erweiterbarkeit, Flexibilität, Testbarkeit, Benutzerfreundlichkeit, Zuverlässigkeit, Sicherheit, Korrektheit, Vollständigkeit, Widerspruchsfreiheit, Überprüfbarkeit, Nachvollziehbarkeit, Übersichtlichkeit, ...
    

Zurück

Inhaltsverzeichnis

Nächste

Diplomarbeiten zum Runterladen: