22.08.2013 Aufrufe

Grundlagen der Informatik I “Programmierung”

Grundlagen der Informatik I “Programmierung”

Grundlagen der Informatik I “Programmierung”

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

4.1.1 Analyse und Gestaltung<br />

Softwaresysteme werden nur selten losgelöst von einem konkreten Bezug zur realen Welt erstellt. Deshalb<br />

besteht die wesentliche Aufgabe beim Entwurf von Softwaresystemen fast immer darin, den für die Problemstellung<br />

relevanten Ausschnitt <strong>der</strong> realen Welt zu modellieren. Softwareentwickler stehen also vor <strong>der</strong> Aufgabe,<br />

einen Bezug zwischen <strong>der</strong> realen Welt und <strong>der</strong> Denkwelt von Computeralgorithmen herstellen zu müssen. Das<br />

verlangt zum einen, den vorgesehenen Einsatzbereich des Softwareproduktes und das zugehörige Umfeld sowie<br />

eventuelle Nebenwirkungen des Softwareeinsatzes zu verstehen, und zum an<strong>der</strong>en, einen <strong>der</strong>artigen Teil <strong>der</strong><br />

realen Welt auf formale Modelle zu reduzieren, was zwangsläufig eine drastische Beschränkung <strong>der</strong> Sicht <strong>der</strong><br />

realen Welt mit sich bringen wird.<br />

<strong>Informatik</strong>er befinden sich daher immer in einer Doppelrolle. Einerseits sind sie Entdecker <strong>der</strong> Gesetzmäßigkeiten<br />

des Umfelds, das sie modellieren und durch ihr Softwareprodukt beeinflussen wollen. An<strong>der</strong>seits sind sie<br />

aber auch Gestalter (o<strong>der</strong> Erfin<strong>der</strong>) eines Modells, das den relevanten Ausschnitt <strong>der</strong> Welt wie<strong>der</strong>spiegelt und<br />

durch das entstehende Produkt wie<strong>der</strong> eine Rückwirkung auf die reale Welt – zum Beispiel auf Arbeitsabläufe<br />

innerhalb eines Betriebs – haben wird. Sie als zukünftige <strong>Informatik</strong>er müssen sich dieser Doppelrolle immer<br />

bewußt sein. Ihre Aufgaben und Ihre Verantwortung geht weit über die reine Technik (das Codieren eines<br />

Programms) hinaus: Sie müssen die bestehende Welt und natürlich auch die Problemstellung analysieren und<br />

sich dafür entscheiden, wie Sie sie durch Ihr Softwareprodukt gestalten wollen. Erst danach können Sie an<br />

eine konkrete Implementierung denken.<br />

Dementsprechend ist <strong>der</strong> Entwurf eines Softwaresystems in zwei prinzipiellen Schritten auszuführen:<br />

1. Am Anfang eines Entwurfs steht die Analyse <strong>der</strong> Leistungen, die das Programm an seine Klienten erbringen<br />

soll. Ergebnis <strong>der</strong> Analyse ist eine Reihe von Attributen, Methoden und Funktionen, die <strong>der</strong><br />

Anwen<strong>der</strong> abrufen kann. Jede einzelne Leistung entspricht einer Routine, <strong>der</strong>en Wirkung über ihren Kontrakt<br />

beschrieben ist. Das Gesamtangebot an Leistungen des Systems wird üblicherweise als Schnittstelle<br />

bezeichnet. 1 Für jede einzelne Leistung wird ihr Kontrakt bestimmt und für das Gesamtprogramm die<br />

Zusicherungen, die alle Prozeduren als Nachbedingung garantieren – also die Invariante.<br />

Damit ist die äußere Sicht des Programms (Grobspezifikation) abgeschlossen und <strong>der</strong> inhaltliche Teil des<br />

Pflichtenhefts definiert: Es ist vollständig festgelegt, was das Programm leisten soll.<br />

Diese Aufgabe muß meist in Kooperation mit Spezialisten aus den Anwendungsbereichen geschehen, da<br />

den <strong>Informatik</strong>ern meist die notwendige Kompetenz fehlt. Das befreit <strong>Informatik</strong>er allerdings nicht von<br />

<strong>der</strong> Pflicht, sich in die Denkweise <strong>der</strong> entsprechenden Dispziplinen einzuarbeiten.<br />

2. Der nächste Schritt ist <strong>der</strong> kreative Anteil am Entwurf. Man überlegt sich, wie die einzelnen Angebote<br />

realisiert werden können. Die Beschreibung davon nennt man Feinspezifikation.<br />

Das Grundprinzip ist dabei eine Zerlegung des Systems in unabhängige kooperierende Komponenten<br />

(Separation of Concerns), also die Frage, welche Objekte benötigt werden, um die gefor<strong>der</strong>ten Leistungen<br />

mit geringem Aufwand zu beschreiben. Hierzu muß man versuchen, Objekte zu spezifizieren, aus <strong>der</strong>en<br />

Merkmalen man die gefor<strong>der</strong>ten Leistungen zusammenbauen kann.<br />

Zur Durchführung dieser Schritte ist eine Menge Einfallsreichtum und Begabung und vor allem auch eine<br />

Menge von Erfahrung und Training erfor<strong>der</strong>lich. Dennoch lassen sich – zumindest für den zweiten Schritt<br />

– ein paar allgemeine Leitlinen angeben, die ein erfolgreiches Vorgehen för<strong>der</strong>n. Hierzu wollen wir zunächst<br />

noch einmal die Grundmerkmale <strong>der</strong> objektorientierten Vorgehensweise resümieren.<br />

1 Ist <strong>der</strong> Klient ein Anwen<strong>der</strong> (im Gegensatz zu Systemen, bei dem <strong>der</strong> Klient wie<strong>der</strong>um ein technisches Systems ist, wie z.B. bei<br />

ABS-Systemen, Waschmaschinen, autonomen Waffensystemen), dann wird er nicht direkt diese Routinen aufrufen son<strong>der</strong>n wird<br />

ein Menü sehen, das die einzelnen Routinen kennzeichnet. Die aktuellen Parameter werden dann innerhalb eines Dialogs abgefragt.<br />

In diesem Fall nennt man die Schnittstelle Benutzerschnittstelle (User Interface) und seine Darstellung Benutzeroberfläche.

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!