Wirtschaftsinformatik (Bachelor-Studiengang): Modellierung betrieblicher Anwendungssysteme (4. Semester)
Sie sind hier: Startseite › Wirtschaftsinformatik › Modellierung von Anwendungssystemen
MST / CM, Kurs vom 01.10.2003 - 31.03.2004
Einführung
Prozessmodelle für die Entwicklung objektorientierter Anwendungssysteme
Themenübersicht:
- Prozessmodelle zur Unterstützung des SE-Prozesses
- V-Modell 97 - ein Vorgehenskonzept für die objektorientierte Software-Entwicklung
- Der Rational Unified Process - als Basis für einen Prozessleitfaden
Ausgangssituation:
- Objektorientierung hat sich in großen Projekten trotz UML noch nicht umfassend durchgesetzt.
- Software-Entwicklung benötigt unter industriellen Bedingungen einen festgelegten organisatorischen Rahmen - ein Prozessmodell.
- Der Markt bietet generische Prozessmodelle - als Templates oder Baukästen zur Erstellung eigener - an das jeweilige Projekt angepasster Prozessleitfäden.
Warum braucht man ein Prozessmodell:
- Sprache, Konzepte, Notation, Darstellungsmittel
(Wie wird kommuniziert?, Was sieht man?)Hinweis: UML
- Management-Praktiken
(Wie wird geplant, kontrolliert und gesteuert?)Hinweis: projektorientierte Reviews...
- Prozesse, Regeln
(Wie geht man vor?, Wie wendet man eine Notation an?)Hinweis: inkrementell, iterativ, komponenten-, architektur- und anwendungsfallorientiert
Prozessmodelle regeln den gesamten Prozess der Software-Entwicklung:
Ein Prozessmodell ist eine abstrakte Beschreibung des Software-Entwicklungsprozesses.
Wozu dient ein Prozessmodell?
- als Leitfaden für alle Projektbeteiligten
- als Vertragsgrundlage für fremd vergebene Projekte
- als die Grundlage für Projektplanung und Projektsteuerung
- Prozessmodelle müssen mit angemessenem Aufwand an Projektsituationen anpassbar sein
Was beinhaltet ein Prozessmodell:
- Geschäftsprozessmodellierung
- Anforderungsanalyse
- Analysemodelle erstellen
- Designmodelle erstellen
- Implementierung
- Test
- Auslieferung
- In welche Abschnitte/Prozessschritte kann der Gesamtprozess zerlegt werden?
- In welcher Reihenfolge können die Prozessschritte ausgeführt werden?
- Welche Rollen sind vom Team zu besetzen?
- Welche Ergebnisse werden in welchen Prozessschritten erzeugt?
- Welche Modellierungstechnik ist für welche Prozessschritte einsetzbar?
- Welche Tools können eingesetzt werden?
Wie kann man qualitativ hochwertige Software auf wiederverwendbare Art und Weise entwickeln und pflegen:
- Visuelle Modellierung
- Iterative inkrementelle Entwicklung
- Architekturzentrierte Entwicklung
- Anforderungs-Management
- Prüfung der Software-Qualität
- kontrolliertes Änderungs-Management
Hinweis: Software Best Practices
Grundprinzipien der Objektorientierung
Anforderungen zur Auswahl eines Prozessmodells für die Entwicklung komplexer objektorientierter Anwendungssysteme:
- Gewährleistung der Konzepte der Wiederverwendbarkeit
- UML - als methodische Basis (Konzepte, Notationen, Darstellungsmittel)
- Projekt-, Änderungs- und Konfigurations-Management sowie Qualitäts-Management als integrale Bestandteile des Prozessmodells.
- Integration von Risiko-Management als wichtiges Steuerelement
- Prozessmodelle müssen mit angemessenem Aufwand an Projektsituationen anpassbar sein.
Prozessmodelle (Auswahl):
- Wasserfallmodell ("Veteran" der Prozessmodelle)
- Das iterative - inkrementelle Modell (stufenweise Entwicklung)
- Das V-Modell 97
- Rational Objectory Process, 1997
- Object Engineering Process, 1999
- Unified Process (Rational
Unified Process), 1999
Hinweis: Das Prozessmodell für den objektorientierten Entwicklungsprozess als Ergänzung zur UML.
Merkmale des Wasserfallmodells:
- Jede Aktivität ist vollständig und in der vorgegebenen Reihenfolge durchzuführen.
- Zu jeder Aktivität wird ein Dokument erstellt.
- Der Ablauf der Aktivitäten ist sequentiell.
- Das Vorgehen basiert auf dem Top-Down-Ansatz.
- Das Modell ist einfach, verständlich und erfordert geringen Management-Aufwand.
- Risiken werden in die Zukunft verschoben.
Merkmale des iterativen, inkrementellen Vorgehen:
- Der Entwicklungsprozess als eine Folge wiederholter (iterativer) Durchführungen der wesentlichen Aktivitäten.
- Das Anwendungssystem (Produkt) wird aus einer Reihe von Teilsystemen entwickelt, die aufeinander aufbauen.
- Die Entwicklung wird einfacher, da die Komplexität geringer ist.
- Der Auftraggeber erhält kurzfristig ein einsatzfähiges Produkt (Teilprodukt), danach wird eine weitere Aufbaustufe realisiert.
- Auf veränderte Anforderungen kann reagiert werden.
Grundlagen des Rational Unified Process
Phasen des RUP:
- Konzeptphase
Vorbereitung und Planung des zu entwickelnden Systems; Erarbeiten einer ersten Vision - Spezifikationsphase
Analyse des Anwendungsbereiches; Entwurf der Anwendungsarchitektur - Konstruktionsphase
Umsetzung der Anforderungen sowie Anwendungsarchitektur in eine Systemarchitektur (System-Design), Implementierung der Komponenten und Systemintegration - Einführungsphase
Übergabe des Produktes (Anwendungssystems) an den Kunden.
Worker - Rollenkonzept im RUP:
- Analytiker
- Use-Case-Spezifizierer
- Geschäftsprozessanalytiker
- Geschäftsprozessdesigner
- Systemanalytiker
- Geschäftsprozessmodellgutachter
- Anforderungsgutachter
- Manager>
- Projektmanager (Projektleiter)
- Projektgutachter
- Prozessmanager
- Verteilungsmanager
- Konfigurationsmanager
- Verteilungsmanager
- Entwickler
- Datenbank-Designer
- Designer
- Systemintegrator
- Architektur-Gutachter
- Design-Gutachter
- Code-Gutachter
- Implementierer (Software-Entwickler)
- Tester
- Testdesigner
- Systemtester
- Integrationstester
- Performance-Tester
V-Modell 97: ein Vorgehenskonzept für die objektorientierte Software-Entwicklung
V-Modell:
- Verbindlicher Standard für IT-Systeme im Bereich der Bundesbehörden (1996)
- Gewährleistung eines kontinuierlichen Änderungsprozesses und Anpassung an den Stand der Methoden- und Toolunterstützung
- Unterstützung der objektorientierten Grundprinzipien im V-Modell 97
- V-Modell 97 - ein Rahmen (Framework) zur Erstellung firmenspezifischer Prozessmodelle
V-Modell 97 regelt die Entwicklung von IT-Systemen über drei Ebenen:
Die Vorgehensebene - über das Vorgehensmodell
Die Methodenebene - über die Methodenzuordnung
Die Werkzeugebene - über die funktionalen
Werkzeuganforderungen
Struktur des V-Modells
Ein V-Modell besteht aus folgenden Elementen:
- Produkte
- Aktivitäten
- Beschreibungsmuster
- Rollenkonzept
Submodelle des V-Modells:
- Software-Entwicklung bzw.
Systemerstellung
Entwickelt das System/Dokumentation - Qualitätssicherung
Gibt Anforderungen und Methoden vor, prüft - Konfigurations-Management (KM)
Verwaltet Konfigurationen, Produkte, Rechte und Änderungen - Projekt-Management (PM)
plant, kontrolliert/steuert, informiert
Prozessmodelle zur Unterstützung der Software-Entwicklung:
- Mittelweg zwischen Standardisierung und Freiheit zur Kreativität finden
- So wenig Phasen, Produkte und Rollen wie notwendig.
- Produktstruktur für den Standardfall
- Optimale Toolunterstützung
- Jedes Produkt/Teilprodukt durch Qualitätssicherung überprüfen
Nutzen eines maschinell unterstützten Prozessmodell:
- einheitlicher Leitfaden (über Projektgrenzen hinweg)
- konkrete Arbeitsanleitung für alle Projektbeteiligten
- Kommunikationsbasis im Projekt
- aktuelle Informationen zum Projektstand
- Vertragsgrundlage für fremd vergebene Projekte
- Vergleichbarkeit von Projekten
- Chance zur kontinuierlichen Verbesserung des SE-Prozesses
Objektorientiertes Design (OOD) und Gestaltung der Architektur von Anwendungssystemen
Einführung und Überblick
Aufgabe des Entwerfens:
- Auf der Basis der Anforderungen an ein Software-Produkt (Anforderungsdefinition) wird eine Software-technische Lösung im Sinne einer Software-Architektur entwickelt
- Basis: Ergebnisse der Definitionsphase
Bildbeschreibung "Einführung und Überblick": Gestaltungsphasen der Architektur von Anwendungssystemen und die Ergebnisse der einzelnen Phasen. Planungsphase (Lastenheft), Definitionsphase (Produkt-Definition: Pflichtenheft, Produkt-Modell, Konzept Benutzeroberfläche), Entwurfsphase (Produktentwurf: Software-Architektur, Spezifikation der Systemkomponenten), Implementierungsphase (Programme), Annahme und Einführungsphase (Installiertes Produkt).
Ziele der Entwurfsphase:
Für das zu entwerfende Produkt ist eine Software-Architektur zu erstellen, die die funktionalen und nichtfunktionalen Produktanforderungen sowie allgemeine und produktspezifische Qualitätsanforderungen erfüllt und die Schnittstellen zur Umgebung versorgt.
Aufgaben der Entwurfsphase
- Ermitteln und Festlegen der Umgebungs- und Randbedingungen
- Treffen grundlegender Entwurfsentscheidungen
- Entwerfen einer Software-Architektur
- Zerlegung des definierten Systems in Systemkomponenten
- Strukturierung des Systems durch geeignete Anordnung der Systemkomponenten
- Beschreibung der Beziehungen zwischen den Systemkomponenten
- Spezifikation des Funktions- und Leistungsumfangs sowie des Verhaltens der Systemkomponenten in informaler, semiformaler oder formaler Weise
- Festlegung der Schnittstellen, über die die Systemkomponenten miteinander kommunizieren.
Verteilungsalternativen beim Client/Server-Konzept:
Bildbeschreibung "Verteilungsalternativen beim Client/Server-Konzept": Entfernte Datenhaltung = Benutzeroberfläche und eigentliche Anwendung beim Client, Datenhaltung auf Server-Seite. Entfernte Benutzeroberfläche = Benutzeroberfläche beim Client, eigentliche Anwendung und Datenhaltung auf Server-Seite. Kooperative Verwaltung = Benutzeroberfläche und Anwendung Teil 1 beim Client, Anwendung Teil 2 und Datenhaltung auf Server-Seite.
Was ist eine Software-Architektur?
- Sie ist ein Bauplan für die strukturelle Software-Organisation des Gesamtsystems.
- Eine Software-Architektur ist eine Beschreibung der Subsysteme und Komponenten eines Software-Systems und der Beziehungen zwischen ihnen (Basisniveau).
- Komponenten sind Bausteine der Struktur eines Software-Systems.
Darstellung der Struktur eines Software-Systems auf der Basis von Komponenten:
Bildbeschreibung "Struktur eines Software-Systems auf der Basis von Komponenten": Verschiedene Systemkomponenten sind durch Beziehungen miteinander verknüpft.
Drei-Schichten-Software-Architektur:
Schicht 2: Benutzeroberfläche
Schicht 1: eigentliche Anwendung
Schicht 0: Datenhaltung
Vier-Schichten-Software-Architektur:
Schicht 1: Benutzeroberfläche
Schicht 2: Anwendungskern
Schicht 3: Datenzugriffsschicht
Schicht 4: Datenhaltung
Anforderungen an eine Software-Architektur aus Sicht der Objektorientierung
- Eine objektorientierte Software-Architektur umfasst eine Hierarchie von Klassen.
- Sie wird in Schichten mit verschiedenem Abstraktionsgrad erzeugt.
- D.h., die Klassen werden innerhalb der Software-Architektur in gekapselten Schichten (Layer) organisiert.
- Zwischen den Schichten ist eine klare Aufgabentrennung.
- Die Interaktion der Klassen ist überwiegend auf die Schichten beschränkt, zu der sie gehören.
- Eine OOS-Architektur sollte einfach und somit verständlich sein.
Entwurf eines komponentenbasierten Anwendungssystems:
- Ergänzung der aus fachlicher Sicht modellierten Klassen um technische Eigenschaften (z.B.: Typdefinitionen, Oberflächen-Elementtypen).
- Definition von Komponenten als Bestandteile des Anwendungssystems.
- Entwurf der Architektur des Anwendungssystems auf Basis von Komponenten.
- Zielumgebung spezifizieren (u.a. Auswahl der Zielsprache, GUI-Tool, DBMS)
- Designvorgaben (u.a. Code-Skripte, Stereotypen, Packages zur Wiederverwendung, Entwurfsmuster)
- Systemarchitektur entwerfen
- Designmodell für Systemkomponenten entwickeln
Ergebnisse der Entwicklung einer Software-Architektur
- Beschreibung der Software-Komponenten (Subsysteme, Komponenten, Software-Schichten) einschließlich ihrer Funktionalität und Schnittstellen.
- Darstellung der Strukturierung der Software-Komponenten
- Spezifizierung der Schnittstellen, insbesondere des Datenaustausches zwischen den Software-Komponenten.
- Integration "fertiger" bzw. gekaufter Software-Komponenten als COTS-Produkte (Commercial-Off-The-Shelf-Produkt).
- Beschreibung der Datenhaltungskomponenten und Präsentationsschicht.
Vier-Schichten-Klassenarchitektur:
Bildbeschreibung "Vier-Schichten-Klassenarchitektur": Interface-Klassen, Anwendungskern, Datenzugriffsklassen, Systemklassen.
Designmodell für Systemkomponenten entwickeln
- Designklassen definieren (Ergänzen und Erweitern der aus fachlicher Sicht definierten Klassen aus technische Eigenschaften)
- Klassendiagramme mit Designklassen erstellen
- Zustandsdiagramme entwickeln
- Sequenzdiagramme für Designszenarien
Bestandteil des Designmodells:
- Designklassen sowie Attribute und Methoden mit sprachspezifischen und benutzerdefinierten Eigenschaften
- Zustandsdiagramm für Klassen und zustandsabhängiges Verhalten
- Sequenzdiagramm für Designszenarien
Anwendungsarchitektur
Ein Entwurf der Architektur des künftigen Anwendungssystems ist bereits vor den Designaktivitäten erforderlich.
Die Anwendungsarchitektur- vermittelt eine Übersicht über das künftige Anwendungssystem
- ist eine Basis für eine sinnvolle Arbeitsteilung
- gewährleistet die erforderliche Flexibilität während der Anwendungsentwicklung
- hilft hohe Wiederverwendung zu erzielen.
Sie beschreibt die innere Struktur des Anwendungssystems und seiner Komponenten aus fachlicher Sicht.
Bestandteile der Anwendungsarchitektur:
- Vorgangssteuerung (fachliche Ablaufsteuerung)
- initiiert, überwacht und steuert die Abarbeitung des Geschäftsvorfalls aus fachlicher Sicht
- die technischen und formalen Aspekte (Aufruf des Dialogs) übernimmt die Interaktionssteuerung
- Interaktionssteuerung (Controller, technische Ablaufsteuerung)
- Realisierung der Dialogsteuerung, d.h. sie regelt die Kommunikation zwischen den Dialogen und den Business-Objekten.
- Sie gewährleistet u.a. das Anzeigen und Aufblenden der Dialoge, Weiterleitung von Fehler- und Statusmeldungen
- Dialoge (Präsentation, Viewer)
- Dialoge bilden die Schnittstelle zum Anwender
- sie dienen zur Präsentation der Informationen und nehmen Eingaben entgegen
Komponentenorientierte Anwendungsentwicklung
Konzepte der Wiederverwendung- Komponenten
- Frameworks (Anwendungsrahmen)
- Design Pattern (Entwurfsmuster)
Was ist eine Komponente?
- Komponenten sind Software-Einheiten, die als relativ eigenständige Teile in verschiedenen Kontexten genutzt und kombiniert werden können.
- Die Interaktion der Komponenten zu deren Umwelt erfolgt ausschließlich über definierte Schnittstellen, den sogenannten Diensten.
- Eine Komponente bildet die Basis für die Wiederverwendung.
Anforderungen an Komponenten:
Komponenten müssen:- einen exakt definierten Aufgabenbereich möglichst vollständig beschreiben,
- definierte Schnittstellen (Dienste) bereitstellen, mittels derer die gesamte Kommunikation erfolgt,
- erweiterbar, änderungs- und anpassungsfähig sein,
- unabhängig von einem speziellen Kontext funktionieren.
Kategorien von Komponenten:
UML 2.0 klassifiziert Komponenten in folgende Kategorien:
- Prozess-Komponenten (repräsentieren Geschäftsprozess)
- Entity-Komponenten (werden von Prozess-Komponenten benutzt)
- Service-Komponenten (Business-unabhängige mehrfach verwendbare Komponenten)
Framework
Ein Framework ist eine Menge kooperierender Klassen, die für eine spezifische Art von Anwendungen wiederverwendet werden kann.
Die Klassen eines Frameworks sind abstrakte Klassen, die bei der Wiederverwendung des Frameworks spezialisiert werden.
Ein Framework stellt aus der Sicht der Architektur einen universellen, steuernden Rahmen dar, in den Komponenten eingebettet sind.
Das Ziel der Entwicklung von Frameworks ist es, Gemeinsamkeiten verschiedener Anwendungen eines Problembereiches zu erfassen und abzubilden.
Teilarchitekturen der Gesamt-Architektur eines Anwendungssystems:
- Business-Architektur
Modelle von der Art der Realisierung der Software:
(Definition fachlicher Anforderungen) - Referenz-Architektur
Plattform-unabhängige Modelle: PIM (Platform Independend Model)
(Spezifikation der Komponenten und Interaktionen) - Anwendungs-Architektur
Plattform-spezifische Modelle: PSM (Platform Specific Model)
Implementierung der Komponenten mittels spezieller Komponentenmodelle - System-Architektur
Systemspezifische Modelle: EDM (Enterprise Deployment Model)
Implementierung der Komponenten und Systeme in die spezielle Infrastruktur
Model Driven Architecture (MDA):
PIM -> PSM -> EDM
Vorteile von Frameworks:
- Software-Engineering wird schneller und kostengünstiger, da vorhandene Ideen und Komponenten wiederverwendet werden.
- Verbesserung der Qualität und Reduzierung der Wartungskosten, da mehrere Anwendungssysteme eine ähnliche Struktur besitzen.
- Software ist weniger personenabhängig.
Design Pattern
- Die Design Pattern sind Lösungsvorschriften dafür, wie typische, sich wiederholende, komplexe Entwurfsprobleme mit Mitteln der Objektorientierung zu lösen sind.
- Entwurfsmuster dokumentieren existierende und erprobte Design-Erfahrungen.
- Ein Entwurfsmuster identifiziert und beschreibt Abstraktionen, die über dem Niveau einzelner Klassen liegen.
- Entwurfsmuster helfen bei der Konstruktion und Dokumentation einer spezifischen Architektur mit definierten Eigenschaften.
Beschreibung der Design Pattern:
Beschreibung des Entwurfsproblems und des Kontextes, in dem die Lösung gültig ist.
Beschreibung der Eigenschaften des Entwurfsmusters mit:- Bezeichnung des Musters,
- Zweck, Motivation,
- Anwendbarkeit,
- Struktur,
- Konsequenzen (Vor- und Nachteile)
- Implementierungsbeispiele.