Objektorientierte Analyse und Design

Objektorientierte Analyse und Design (Ooad) ist ein technischer Ansatz zur Analyse und Gestaltung einer Anwendung, eines Systems oder eines Unternehmens durch Bewerbung Objekt orientierte Programmierungund nutzte die visuelle Modellierung im gesamten Softwareentwicklungsprozess, um die Kommunikation und die Produktqualität der Stakeholder zu leiten.

Ooad in modernem Software -Engineering wird normalerweise iterativ und inkrementell durchgeführt. Die Ausgaben von OOAD -Aktivitäten sind Analysemodelle (für OOA) bzw. Entwurfsmodelle (für OOD). Es ist beabsichtigt, dass diese kontinuierlich verfeinert und weiterentwickelt werden, was auf Schlüsselfaktoren wie Risiken und Geschäftswert zurückzuführen ist.

Geschichte

In den frühen Tagen der objektorientierten Technologie vor Mitte der neunziger Jahre gab es viele verschiedene konkurrierende Methoden für die Softwareentwicklung und Objektorientierte Modellierung, oft mit spezifisch gebunden Computergesteuerte Software -Engineering (Fall) Werkzeuganbieter. Keine Standardnotationen, konsistente Begriffe und Prozessleitfäden waren zu dieser Zeit die Hauptanliegen, die die Kommunikationseffizienz und die verlängerten Lernkurven verschlechterten.

Einige der bekannten frühen objektorientierten Methoden stammten aus und inspiriert von Gurus wie z. Grady Booch, James Rumbaugh, Ivar Jacobson (das Drei Amigos), Robert Martin, Peter Coad, Sally Shlaer, Stephen Mellor, und Rebecca Wirfs-Brock.

1994 die Drei Amigos von rationaler Software begann zusammenzuarbeiten, um die zu entwickeln Einheitliche Modellierungssprache (Uml). Später zusammen mit Philippe Kruchtten und Walker Royce (ältester Sohn von Winston Royce), sie haben eine erfolgreiche Mission geführt, ihre eigenen Methoden zusammenzuführen. OMT, Oose und Booch -Methode, mit verschiedenen Erkenntnissen und Erfahrungen anderer Branchenführer in die Rational einheitlicher Prozess (RUP), ein umfassender iterativer und inkrementeller Prozessleitfaden und Rahmen für die Lernindustrie für Best Practices für Softwareentwicklung und Projektmanagement.[1] Seitdem die Einheitlicher Prozess Die Familie ist wahrscheinlich zum beliebtesten Methodik- und Referenzmodell für objektorientierte Analyse und Design geworden.

Überblick

Der Software -Lebenszyklus ist in der Regel in Phasen unterteilt, die von abstrakten Beschreibungen des Problems zu Designs zu Code und Testen und schließlich zur Bereitstellung übergehen. Die frühesten Phasen dieses Prozesses sind Analyse und Design. Die Analysephase wird auch häufig als "Anforderungen Akquisition" bezeichnet.

Das Wasserfall-Modell.
Ooad wird iterativ und inkrementell durchgeführt, wie durch die formuliert Einheitlicher Prozess.

In einigen Ansätzen zur Softwareentwicklung - gemeinsam als Wasserfallmodelle bekannt - sollen die Grenzen zwischen jeder Phase ziemlich starr und sequentiell sein. Der Begriff "Wasserfall" wurde für solche Methoden geprägt, um zu bedeuten, dass der Fortschritt nacheinander nur in eine Richtung verlief, d. H. Nach Abschluss der Analyse und erst dann begonnen wurde und er selten (und als Fehlerquelle angesehen wurde), als ein Entwurfsproblem angesehen wurde Erforderte eine Änderung des Analysemodells oder wenn ein Codierungsproblem eine Änderung des Designs erforderte.

Die Alternative zu Wasserfallmodellen sind iterative Modelle. Diese Unterscheidung wurde populär von Barry Boehm in einem sehr einflussreichen Artikel über sein Spiralmodell für die iterative Softwareentwicklung. Bei iterativen Modellen ist es möglich, in verschiedenen Phasen des Modells parallel zu arbeiten. So ist es zum Beispiel möglich - und nicht als Fehlerquelle angesehen - an der Analyse, dem Entwurf und sogar an der Codierung am selben Tag zu arbeiten und Probleme aus einer Stufe Auswirkungen von einem anderen zu haben. Der Schwerpunkt auf iterativen Modellen liegt darin Das Design sollte geändert werden usw.[2]

Obwohl es möglich ist, eine objektorientierte Entwicklung mit einem Wasserfallmodell durchzuführen, werden die meisten objektorientierten Systeme mit einem iterativen Ansatz entwickelt. Infolgedessen werden in objektorientierten Prozessen "Analyse und Design" häufig gleichzeitig berücksichtigt.

Das objektorientierte Paradigma betont die Modularität und Wiederverwendbarkeit. Das Ziel eines objektorientierten Ansatzes ist es, das zu befriedigen "offenes Prinzip". Ein Modul ist geöffnet, wenn es die Erweiterung unterstützt oder wenn das Modul standardisierte Möglichkeiten bietet, neue Verhaltensweisen hinzuzufügen oder neue Zustände zu beschreiben. In dem objektorientierten Paradigma wird dies häufig durch Erstellen einer neuen Unterklasse einer vorhandenen Klasse erreicht. Ein Modul ist geschlossen, wenn es eine gut definierte stabile Schnittstelle hat, die alle anderen Module verwenden müssen, und die die Interaktion und die potenziellen Fehler begrenzt, die durch Änderungen in einem anderen in ein Modul eingeführt werden können. Im objektorientierten Paradigma wird dies durch Definieren von Methoden erreicht, die Dienste auf Objekten aufrufen. Methoden können entweder öffentlich oder privat sein, d. H. Bestimmte Verhaltensweisen, die für das Objekt einzigartig sind, sind nicht anderen Objekten ausgesetzt. Dies reduziert eine Quelle vieler häufiger Fehler in der Computerprogrammierung.[3]

Der Software -Lebenszyklus ist in der Regel in Phasen unterteilt, die von abstrakten Beschreibungen des Problems zu Designs zu Code und Testen und schließlich zur Bereitstellung übergehen. Die frühesten Phasen dieses Prozesses sind Analyse und Design. Die Unterscheidung zwischen Analyse und Design wird oft als "was gegen wie" bezeichnet. In der Analyse arbeiten Entwickler mit Benutzern und Domänenexperten zusammen, um zu definieren, was das System tun soll. Implementierungsdetails sollen in dieser Phase hauptsächlich oder vollständig (abhängig von der jeweiligen Methode) ignoriert werden. Ziel der Analysephase ist es, ein Funktionsmodell des Systems unabhängig von Einschränkungen wie geeigneter Technologie zu erstellen. In der objektorientierten Analyse erfolgt dies typischerweise über Anwendungsfälle und abstrakte Definitionen der wichtigsten Objekte. Die nachfolgende Entwurfsphase verfeinert das Analysemodell und trifft die erforderliche Technologie und andere Implementierungsentscheidungen. In objektorientiertem Design liegt der Schwerpunkt auf der Beschreibung der verschiedenen Objekte, deren Daten, Verhalten und Interaktionen. Das Designmodell sollte alle Details benötigen, damit Programmierer das Design im Code implementieren können.[4]

Objektorientierte Analyse

Der Zweck einer Analyseaktivität in der Software-Lebenszyklus soll ein Modell der funktionalen Anforderungen des Systems erstellen, das unabhängig von Implementierungsbeschränkungen ist.

Der Hauptunterschied zwischen objektorientierter Analyse und anderen Analyseformen besteht darin, dass wir durch den objektorientierten Ansatz Anforderungen um Objekte organisieren, die sowohl Verhaltensweisen (Prozesse) und Zustände (Daten) integrieren, die nach realen Objekten modelliert sind, mit denen das System interagiert. Bei anderen oder traditionellen Analysemethoden werden die beiden Aspekte: Prozesse und Daten separat berücksichtigt. Zum Beispiel können Daten nach modelliert werden ER -Diagrammeund Verhaltensweisen von Flussdiagramme oder Strukturdiagramme.

Gemeinsame Modelle, die in OOA verwendet werden, sind Anwendungsfälle und Objektmodelle. Anwendungsfälle Beschreiben Sie Szenarien für Standarddomänenfunktionen, die das System ausführen muss. Objektmodelle beschreiben die Namen, Klassenbeziehungen (z. B. Kreis ist eine Unterklasse der Form), Operationen und Eigenschaften der Hauptziele. Mockups oder Prototypen für Benutzeroberflächen können auch zum Verständnis erstellt werden.[5]

Objektorientiertes Design

Hauptartikel: Objektorientiertes Design

Während des objektorientierten Designs (OOD) wendet ein Entwickler Implementierungsbeschränkungen auf das konzeptionelle Modell an, das in der objektorientierten Analyse erzeugt wird. Solche Einschränkungen könnten die Hardware und die Hardware umfassen und Software Plattformen, Leistungsanforderungen, anhaltende Speicherung und Transaktion, Benutzerfreundlichkeit des Systems und Einschränkungen, die durch Budgets und Zeit auferlegt werden. Konzepte im Analysemodell, das technologisch unabhängig ist, werden auf die Implementierung von Klassen und Schnittstellen zugeordnet, was zu einem Modell der Lösungsdomäne führt, d. H. Eine detaillierte Beschreibung von wie Das System soll auf konkreten Technologien aufgebaut werden.[6]

Wichtige Themen während OOD sind auch das Design von Softwarearchitekturen durch Auftragen Architekturmuster und Designmuster mit den objektorientierten Designprinzipien.

Objektorientierte Modellierung

Hauptartikel: Objektorientierte Modellierung

Objektorientierte Modellierung (OOM) ist ein gemeinsamer Ansatz für die Modellierung von Anwendungen, Systemen und Geschäftsbereichen, indem das objektorientierte Paradigma im gesamten gesamten Gebiet verwendet wird Entwicklungslebenszyklen. OOM ist eine Haupttechnik, die sowohl von OOD- als auch von OOA -Aktivitäten in modernen Software -Engineering verwendet wird.

Objektorientierte Modellierung unterteilt sich typischerweise in zwei Aspekte der Arbeit: die Modellierung dynamischer Verhaltensweisen wie Geschäftsprozesse und Anwendungsfälleund die Modellierung statischer Strukturen wie Klassen und Komponenten. OOA und OOD sind die beiden unterschiedlichen abstrakten Ebenen (d. H. Die Analyseebene und das Designstufe) während der OOM. Das Einheitliche Modellierungssprache (UML) und Sysml sind die beiden beliebten internationalen Standardsprachen, die für objektorientierte Modellierung verwendet werden.[7]

Die Vorteile von OOM sind:

Effiziente und effektive Kommunikation

Benutzer haben in der Regel Schwierigkeiten beim Verständnis umfassender Dokumente und Programmiersprachencodes. Visuelle Modelldiagramme können verständlicher sein und es Benutzern und Stakeholdern ermöglichen, Entwicklern Feedback zu den entsprechenden Anforderungen und Struktur des Systems zu geben. Ein zentrales Ziel des objektorientierten Ansatzes ist es, die "semantische Lücke" zwischen dem System und der realen Welt zu verringern und das System mit der Terminologie zu konstruieren, die nahezu gleich ist wie die Stakeholder im täglichen Geschäft. Objektorientierte Modellierung ist ein wesentliches Werkzeug, um dies zu erleichtern.

Nützliche und stabile Abstraktion

Modellierung hilft bei der Codierung. Ein Ziel der modernen Software -Methoden ist es, zuerst die "Fragen" zu beantworten und dann "wie" Fragen zu beantworten, d. H. Bestimmen Sie zuerst die Funktionalität, die das System ohne Berücksichtigung der Implementierungsbeschränkungen bereitstellen soll, und überlegen Anforderungen und verfeinern sie in detaillierten Designs und Codes durch Einschränkungen wie Technologie und Budget. Die objektorientierte Modellierung ermöglicht dies, indem sie abstrakte und zugängliche Beschreibungen sowohl der Systemanforderungen als auch der Designs erzeugt, d.h. Modelle die ihre wesentlichen Strukturen und Verhaltensweisen wie Prozesse und Objekte definieren, die wichtige und wertvolle Entwicklungsvermögen mit höheren Abstraktionsniveaus über dem konkreten und komplexen Quellcode sind.

Siehe auch

Verweise

  1. ^ "Rational Unified Process Best Practices für Softwareentwicklungsteams" (PDF). Rational Software White Paper (TP026B). 1998. Abgerufen 12. Dezember 2013.
  2. ^ Boehm B, "Ein Spiralmodell der Softwareentwicklung und -verbesserung", IEEE Computer, IEEE, 21 (5): 61-72, Mai 1988
  3. ^ Meyer, Bertrand (1988). Objektorientierte Softwarekonstruktion. Cambridge: Prentise Hall International Series in Informatik. p. 23. ISBN 0-13-629049-3.
  4. ^ Jacobsen, Ivar; Magnus Chrierson; Patrik Jonsson; Gunnar Overgaard (1992). Objektorientiertes Software -Engineering. Addison-Wesley ACM Press. pp.15, 199. ISBN 0-201-54435-0.
  5. ^ Jacobsen, Ivar; Magnus Chrierson; Patrik Jonsson; Gunnar Overgaard (1992). Objektorientiertes Software -Engineering. Addison-Wesley ACM Press. pp.77–79. ISBN 0-201-54435-0.
  6. ^ Conallen, Jim (2000). Bauen von Webanwendungen mit UML. Addison Wesley. p.147. ISBN 0201615770.
  7. ^ Jacobsen, Ivar; Magnus Chrierson; Patrik Jonsson; Gunnar Overgaard (1992). Objektorientiertes Software -Engineering. Addison-Wesley ACM Press. pp.15, 199. ISBN 0-201-54435-0.

Weitere Lektüre

  • Grady Booch. "Objektorientierte Analyse und Design mit Anwendungen, 3. Auflage":http://www.informit.com/store/product.aspx?isbn=020189551X Addison-Wesley 2007.
  • Rebecca Wirfs-BrockBrian Wilkerson, Lauren Wiener. Entwerfen von objektorientierter Software. Prentice Hall, 1990. [Eine bodenständige Einführung in die objektorientierte Programmierung und das Objekt.]
  • Eine Theorie des objektorientierten Designs: Die Gebäudeblocks von OOD und Notationen zur Darstellung (mit Fokus auf Designmuster).
  • Martin Fowler. Analysemuster: wiederverwendbare Objektmodelle. Addison-Wesley, 1997. [Eine Einführung in die objektorientierte Analyse mit konzeptionellen Modellen]
  • Bertrand Meyer. Objektorientierte Softwarekonstruktion. Prentice Hall, 1997
  • Craig Larman. Anwenden von UML und Mustern - Einführung in die OOA/D & Iterative Entwicklung. Prentice Hall PTR, 3. Aufl. 2005., Mnnm, N, Nnn
  • Setrag Khosfian. Objektorientierung.
  • Ulrich Norbisrath, Albert Zündorf, Ruben Jubeh. Modeling mit Geschichten angetrieben. Amazon Createspace. p. 333., 2013. ISBN9781483949253.

Externe Links