Während
bei der objektorientierten Programmierung bereits 'der Stein ins Rollen' gekommen
ist, sieht es in den vorgelagerten Phasen mit der Objektorientiertheit noch bescheidener aus.
Keramidis [Kera 91] hat in einer Diskussion zur CASE-Entwicklung folgende Einsch-tzung
gegeben:
damals 1998 2002
Objektorientierung
-- - +
Dies
liegt zum einem daran, daß die objektorientierte Idee für Analyse und Entwurf erst relativ
spät aufgegriffen wurde, und zum anderen daran, daß sich Objektorientierung in der großen
Mehrzahl der verfügbaren Publikationen fast ausschließlich als objektorientiertes
Programmieren präsentiert. Sowohl in der Literatur als vor allem auch in der Praxis der
Software-Entwicklung spielen noch immer die Methoden der strukturierten Analyse und des
strukturierten Entwurfs die entscheidende Rolle. Aber immerhin ist auch bei den
objektorientierten Methoden schon einige Arbeit geleistet worden, siehe z.B. [CoYo 90],
[CoYo 91], [ShMe 89]. Stoyan [Stoy 89] kennzeichnet objektorientierte Systementwicklung
wie folgt: Objektorientierte Systementwicklung bedeutet Modellierung der Anwendungs welt:
Die real-physikalischen Objekte - aber auch abstrakt konstruierten - dieser Welt werden durch
Software-Objekte modelliert. [Stoy 89] Die folgenden Schritte sind beim objektorientierten
Entwurf vorzunehmen: 1. Bestimmung der Objektklassen 2. Bestimmung der Grundoperationen
(Konstruktion, Selektion, Modifikation, Attribution, Vergleich, Konversion) für jede
Objektklasse 3. Bestimmung der Systemfunktionen durch Zuweisung von Operationen an eine
Objektklasse 4. Implementation der erarbeiteten Operationen durch erneuten
objektorientierten Entwurf eine Ebene tiefer 5. Abstieg bis zur Maschinen-
/Programmiersprachebene Objektorientiertes Arbeiten erfordert, wenn es erfolgreich sein soll,
einen gewissen Bruch mit bisherigen Vorgehensweisen. Dazu Taylor [Tayl 91b]:
... the question was "What is the worst thing you can do if you want to get the full benefits of
object technology ?" ... the correct answer was "Apply the standard development lifecycle"
Objektorientiertes
Arbeiten nimmt aber auch bisherige Arbeitsweisen in sich auf. Auch hierzu
Taylor [Tayl 91b]:
Note, however, that I did not advocate throwing out all the traditional stages. You can't build
quality software without doing solid requirements analysis and good system design, nor can you
blithely ignore the minor nuisances of testing and maintenance. The trick is to keep all the
traditional stages but to apply them individually to every class, model, and application you build.
This technique allows you to reuse not just code but all the analysis, design, testing, and
maintenance that went into the lower levels of your system.
1. 6. Die Phasen im Software-Lebe...
