kopf
brlogo
fensterobenrechts
   
   
fensteruntenblau
   
 

 

Vom Objekt zur Polymorphie

1.  Modellieren: Vom Problem zum Programm

 

0.  Prolog


Sie habe sich entschlossen, objektorientiertes Denken und Programmieren am Beispiel der Programmiersprache Delphi kennen zu lernen. Hierzu benötigen Sie eine Version dieser Programmiersprache, z B. die für private und nicht-kommerzielle Benutzung freie Version Delphi 7 PE oder Free Pascal mit Lazarus.

Sie wollen nach Hause fahren, um schnellstens die neue Software zu installieren und kennen zu lernen. Sie sind mit dem Bus in die Stadt gekommen und benötigen für die Heimfahrt noch eine Fahrkarte. An der Haltestelle steht ein Fahrkartenautomat.

 

 

1.  Vom Problem zum Modell

 

Allgemein betrachtet können Computer mithilfe ihrer Computerprogramme durch Simulation der realen Welt zu Problemlösungen verwendet werden. Das Abbilden einer solchen Realwelt in ein Computerprogramm geschieht meistens in zwei Schritten:

 

  1. Modellieren: Abstraktion des Realweltproblem in einem Modell
  2. Programmieren: Realisierung des Modells mithilfe einer Programmiersprache

Objektorientiertes Modellieren
bedeutet in diesem Zusammenhang eine spezielle Sichtweise der Realwelt, die sich dann auch im Modell wieder findet. Zentrale Begriffe sind hierbei „Objekt“ und „Klasse“. Objektorientiertes Programmieren überträgt dieses Modell in die konkrete Programmiersprache. Eine objektorientierte Programmiersprache (z. B. Delphi, Java) ist für diese Übertragung besonders geeignet, da sie über Mechanismen verfügt, solche Klassen direkt zu definieren und im Programm Objekte dieser Klassen zu verwenden.

 

Beispiel Fahrkartenautomat

Auf Ihrem Weg zu Ihrem PC sind Ihnen in Ihrer Realwelt der Fahrkartenautomat, evt. auch mehrere dieser Geräte begegnet.


          modellieren1_10              modellieren1_25

         (Abb. Fahrkartenautomat der Deutschen Bahn und ein mögliches Modell in einem Computer-Programm))

 

Gemeinsame Merkmale von Fahrkartenautomaten

 

  • Es gibt verschiedene Geräte, die aber gleicher Bauart sein können (z. B. baugleiche Fahrscheinautomaten bei verschiedenen Verkehrsgesellschaften).
     
  • Gleiche Bauart bedeutet gleiche Funktionsweise: Man kann solche Geräte bedienen, indem man Ihnen Aufträge erteilt (z. B. Fahrstufe auswählen, Geld einwerfen, Aktion abbrechen...) oder Informationen erhält (z. B. Anzeige des Fahrpreises einer gewählten Fahrstufe).
      
  • Alle Geräte besitzen ein Innenleben, das man in der Regel nicht kennt. Z. B. muss das Gerät während eines Kartenverkaufs den bisher gezahlten Betrag mit dem Fahrkartenpreis vergleichen können, oder sich die gewählte Fahrstufe merken, damit am Ende der richtige Fahrschein ausgegeben wird.
     
  • Die Bedienung ist für den Benutzer explizit oder implizit dokumentiert. Die Bedienung ist bei Geräten entweder allgemein bekannt (Beispiel: Telefon) oder durch eine an dem Gerät angebrachte Bedienungsanleitung festgelegt. Das klappt dann auch häufig im Leben (außer beim Handy).
     
  • In jedem Fall gilt: Der Benutzer muss nicht wissen, „wie“ das Gerät seine Aufgabe erfüllt. Wenn der Benutzer aber nicht weiß, was das Gerät „kann“, welche Aufträge es in welcher Situation sinnvoll ausführen kann, und wie seine Informationen zu interpretieren sind, dann wird das wohl nichts mit der Fahrkarte.
     
  • Die Summe aller Aktionen, die ein solches Gerät kann, ist seine Benutzerschnittstelle. Jedes Gerät, dass nicht völlig autonom ist (Bezug zur Technischen Informatik: Autonomer endlicher Automat), definiert sich für seinen Benutzer über eben diese gut zu dokumentierende Benutzerschnittstelle. 

 

 

Objekte und Klassen

 

Ersetzen Sie nun den Begriff Gerät durch den Begriff Objekt und Sie haben eine erste, vorläufige und umgangssprachliche Definition eines Objekts. Man kann also sagen, dass ein solcher Fahrkartenautomat

 

  • ein Objekt ist,
  • gemäß seiner Bauvorschrift (Klasse) erzeugt (gebaut) wurde,
  • für seinen Benutzer (Auftraggeber) verschiedene Aufträge ausführen kann,
  • diese autonom ausführt und alle Informationen (Daten), die es für diesen Auftrag benötigt, vom Auftraggeber erhält oder in sich selbst verwaltet,
  • selber wiederum (Teil-)Objekte enthalten kann (Schalter, Anzeige, Fahrkartenausgabe...).


Das objektorientierte Denkschema geht davon aus, dass das gesamte System in der Realität wie im Software-Modell lediglich aus Objekten besteht. Die Software-Objekte sind dabei Abstraktionen der realen Welt. Die wesentlichen Bestandteile werden hierbei von den unwesentlichen getrennt, und nur die für die Problemstellung wesentlichen Bestandteile werden im Modell nachgebildet.

 

Damit sind wir beim Thema!

 
    
     Ziele
 
  • Objekte und Klassen als Grundbestandteile objektorientierten Modellierens
  • Bestandteile von Klassen: Attribute und Methoden
  • Zentrale GUI-Klassen von Delphi
  • Erste Grundsätze im Umgang mit Objekten
  • Klassendiagramme in UML (Unified Modelling Language)
  • Anwendungsfalldiagramme in UML
     

 

 

Unterrichtsmaterial

 

Skript: Modellieren.pdf

Info-Dateien:  UML_Unified Modelling Language.pdf, UML_Klassendiagramm.pdf, UML_Anwendungsfalldiagramm.pdf

Download:  (Delphi 7)  Modellieren.zip

 

 

Hinweise zum Unterricht

 

Vorhandene Klassen und neue Klassen

In größeren Zusammenhängen ist es sinnvoll und üblich, die Klassen, die zur Benutzerschnittstelle des Programms gehören (GUI-Klassen: Graphical User Interface), von denen zu trennen, die problemangepasst für das Projekt (Fachkonzept-Klassen) entstanden sind, und getrennt darzustellen.

Objektorientiertes Modellieren bedeutet dabei im Allgemeinen, die für die Problemlösung benötigten Klassen

 

  • zu identifizieren,
  • die Anforderungen (Operationen) an die zu erzeugenden Objekte festzulegen,
  • die hierfür notwendigen Information und Daten in den Objekten zur Verfügung zu stellen,
  • das Zusammenwirken dieser Klassen zu definieren.

 

Im Mittelpunkt eines Modells stehen dabei natürlich die Fachklassen, diejenigen Klassen, die die aufgaben- und problemspezifische Realwelt im Modell abbilden, im verwendeten Programmiersystem aber nicht „fertig“ zur Verfügung stehen. Dies setzt voraus, dass man diese „Systemklassen“ (hier z. B. GUI-Klassen) zumindest in dem Umfang kennt, in dem sie Verwendung finden sollen.

 

Wir beschränken uns daher in diesem Kapitel auf den Umgang mit solchen in Delphi vorhandenen GUI-Klassen, weil

 

  • der Leser/ der Lernende diese für seine Umsetzung des Modells in ein Delphi-Programm kennen muss, weil 
  • der Leser/ der Lernende an diese Stelle noch keine Informationen über die Konstruktion eigener Klasse besitzt und weil 
  • er die für das Erstellen der Methoden benötigten Kenntnisse erst nach und nach erlernen kann.
     

 

weiter: Vom Modell zum Delphi-Programm

 

 
 
Thursday, 23. November 2017 / 00:52:13