OM Verteilte objektorientierte Anwendungen

(1)

1

Objektmodellierung

9 Verteilte objektorientierte Anwendungen

Prof. Dr. Heide Balzert Fachbereich Informatik Fachhochschule Dortmund

OM – Verteilte objektorientierte Anwendungen

LE 16

2

Lernziele

▲

Erklären können, wie die Kommunikation zwischen entfernten Objekten stattfindet

▲

Erklären können, was der ORB ist und aus welchen Komponenten er besteht

▲

Erklären können, aus welchen Komponenten OMA besteht

▲

Klassen mittels IDL spezifizieren können

(2)

LE 16

3

Inhalt

9.1 Kommunikation von verteilten Objekten 9.2 ORB-Architektur

9.3 OMA 9.4 IDL

9.5 Entwicklung von verteilten Systemen

LE 16

4

9.1 Kommunikation von verteilten Objekten

▲

Verteilung vieler Anwendungen auf Client- Server-Architekturen

Aufgabe des Entwurfs

Entwicklung geeigneter Architekturen für verteilte objektorientierte Anwendungen auf heterogenen und vernetzten Systemen Kommunikation zwischen Objekten

Unabhängig von der Programmiersprache

Unabhängig von der Systemplattform

(3)

LE 16

5

9.1 Kommunikation von verteilten Objekten

▲

Kommunikation

Server-Objekte bieten Dienstleistungen an, die vom Klient benötigt werden

Klient und Server-Objekt müssen nicht wissen, wo sich jeweils der andere Partner befindet ORB (Object Request Broker) führt die

Kommunikation zwischen beiden durch

Klient Server-Objekt

ORB

LE 16

6

9.1 Kommunikation von verteilten Objekten

▲

ORB (Object Request Broker)

Vergleichbar mit Telefonvermittlung Realisiert

Anrufen anderer Teilnehmer (Server-Objekte) und

Entgegennehmen von Anrufen (Operationsaufrufen)

Hauptaufgaben

Übermittlung von Operationsaufrufen vom Klient an das entfernte Server-Objekt

Rückgabe der Ergebnisse

(4)

LE 16

7

9.1 Kommunikation von verteilten Objekten

▲

Operationsaufruf eines entfernten Objekts

Klient

Softwareeinheit, die eine Operation eines Objekts auf einem entfernten Server benutzen möchte

Einfaches Programm oder Objekt

Fordert ein entferntes Objekt zur Ausführung einer Operation auf (request)

Zugriff auf entfernte Operationen so, als ob es sich um ein lokales Objekt handelte

ORB

Ermittlung des Server-Objekts

Übermittlung des requests

LE 16

8

9.1 Kommunikation von verteilten Objekten

Server

Beschreibung des Verhaltens des Objekts

Objektorientierte Sichtweise

Jedes Server-Objekt gehört zu einer Server-Klasse Sicht des Betriebssystems

Zusammenfassung mehrerer Server-Objekte zu einem Programm – dem Server

Identifizierung des Server-Objekts

Systemweit eindeutige Objektreferenz (object reference)

Keine physische Adresse

Server-Objekt kann sich außerhalb des Prozeßraums befinden

Probleme insbesondere bei heterogenen Netzen

(5)

LE 16

9

9.1 Kommunikation von verteilten Objekten

▲

request

Ereignis, mit folgenden Informationen

Name der angeforderten Operation

Zielobjekt

Aktuellen Parametern

Optionaler Kontext

LE 16

10

9.1 Kommunikation von verteilten Objekten

▲

Server-Klasse = IDL-Schnittstelle + Objekt- Implementierung

Trennung zwischen Schnittstelle und Implementierung der Server-Klassen IDL-Schnittstelle

Auf dem Klienten

Programmiersprachen-unabhängige IDL (Interface Definition Language)

Beschreibt, welche Operationen die Objekt- Implementierung zur Verfügung stellt Objekt-Implementierung

Auf dem Server

In Programmiersprache realisiert, z.B. C++

(6)

LE 16

11

9.2 ORB-Architektur

▲

Ergebnisse des IDL-Compilers

Objekt-Implementierung IDL Skeleton Interface

Repository

IDL Stub

Klient

IDL Definition

LE 16

12

9.2 ORB-Architektur

▲

IDL Stub

Lokaler Vertreter eines entfernten Objekts

▲

IDL Skeleton

Rahmen in der jeweiligen Programmiersprache Verbindet den request mit der

Implementierung

▲

Interface Repository

Systemweit zugängliche Datenbank Enthält alle IDL-Definitionen

(7)

LE 16

13

9.2 ORB-Architektur

▲

Implementation Repository

Verwaltet Informationen, die der ORB benötigt, um Objekt-Implementierungen zu lokalisieren

Abbildung der Objektreferenz auf die physische Adresse mit Hilfe des Implementation Repository

Einfaches Umleiten aller Operationsaufrufe durch Änderung im Implementation Repository

Objekt-Implementierungen für ein Objekt evtl.

auf mehreren Rechner

ORB gibt den Operationsaufruf an den am wenigsten belasteten Rechner weiter

Aus Sicht des Klienten gibt es nur ein Objekt und eine Objektreferenz

LE 16

14

9.2 ORB-Architektur

▲

Schnittstellen des ORB

Klient Objekt-Implementierung

ORB Inter-

face

IDL

Skeletons OA ORB-Kern

DII IDL DSI Stubs

(8)

LE 16

15

9.2 ORB-Architektur

▲

Übermittlung des request statisch oder dynamisch

Benutzung von IDL Stubs für den Programmierer wesentlich einfacher

Dynamische Form nur, wenn die Schnittstelle zur Übersetzungszeit des Klienten nicht bekannt ist

ORB-Kern

DII IDL

Stubs

request Klient

LE 16

16

9.2 ORB-Architektur

▲

IDL Stub

Definition des Server-Objekts muß vor der Übersetzung des Klienten bekannt sein

Übergabe des Operationsaufrufs eines entfernten Objekts an die entsprechende Operation des Stubs Verpacken des Operationsaufrufs und Weiterleiten

über den ORB an das entfernte Objekt

▲

Dynamic Invocation Interface (DII)

Generierung eines Operationsaufrufs zur Laufzeit Klient liest die Beschreibung der gewünschten

Operation aus dem Interface Repository Aufbau der Parameterliste der Operation

Erzeugen und Verpacken des Operationsaufrufs und über den ORB an das entfernte Objekt senden

(9)

LE 16

17

9.2 ORB-Architektur

▲

Object Adapter (OA)

Auf der Empfängerseite ist nicht bekannt, ob ein Operationsaufruf statisch oder dynamisch erstellt wurde

Object Adapter empfängt den Operationsaufruf und sorgt für das Aufrufen der entsprechenden Operation der Objekt-Implementierung

Objekt-Implementierung

OA

ORB-Kern

IDL Skeletons DSI

request

LE 16

18

9.2 ORB-Architektur

▲

IDL Skeleton

Zuständig für eine IDL-Schnittstelle

▲

Dynamic Skeleton Interface (DSI)

Verwendung, wenn für ein Objekt kein IDL Skeleton vorhanden ist

Kann beliebige requests entgegennehmen

Aktivierung durch IDL Stubs oder Dynamic Invocation Interfaces

Wird verwendet für Operationsaufrufe zwischen ORBs verschiedener Hersteller

▲

Aufgabe 1

▲

Aufgabe 2

(10)

LE 16

19

9.3 OMA

▲

OMG (Object Management Group)

Internationales Konsortium von

Hardwareherstellern

Softwareentwicklern

Netzwerkbetreibern und

kommerziellen Nutzern

1989: Gründung durch 8 Firmen Anfang 1999: Mehr als 800 Mitglieder

Ziel

Schaffung von Standards und

Spezifikationen für verteilte objektorientierte Anwendungen

LE 16

20

9.3 OMA

▲

CORBA (Common Object Request Broker Architecture)

OMG-Standard, der spezifiziert, wie Objekte in einer verteilten, heterogenen Umgebung kommunizieren

Beschreibt ...

den Aufbau des ORB

seine Bestandteile

deren Verhalten und Schnittstellen

(11)

LE 16

21

9.3 OMA

▲

OMG-Objektmodell

Liegt allen OMG-Spezifikationen zugrunde Beschreibt zugrundeliegende objektorientierte

Konzepte, die für Klienten wichtig sind

Objekte (objects)

Operationsaufrufe (requests)

Typen (types)

Schnittstellen von Klassen (interfaces)

Operationen (operations)

Attribute (attributes)

Beschreibt Konzepte für die Ausführung von Operationen auf der Serverseite

LE 16

22

9.3 OMA

▲

OMA (Object Management Architecture)

Basis aller Standardisierungsaktivitäten der OMG

Unterteilt eine verteilte Anwendung mehrere Komponenten

Common Facilities Druckersteuerung E-Mail

usw.

Object Services Auffinden von Objekten Erzeugen von Objekten usw.

Object Request Broker (ORB)

Domain Interfaces CORBA finance CORBA health usw.

Application Interfaces individuelle

Anwendung

(12)

LE 16

23

9.3 OMA

▲

Object Services

Elementare, betriebssystemähnliche Funktionen

Entsprechen – bei einer Telefonvermittlung – den elementaren Diensten wie Auskunft, Notrufe

z.B. Finden von Objekten im Netz

z.B. Erzeugen und Löschen von Objekten

▲

Common Facilities

Höhere Dienste, die einen wesentlichen Teil einer Anwendung ausmachen

Bauen auf den object services auf

z.B. Druckersteuerung, E-Mail

LE 16

24

9.3 OMA

▲

Domain Interfaces

Bieten Lösungen für bestimmte Anwendungsbereiche

z.B. Softwarepakete für Finanzen

z.B. Softwarepakete für das Gesundheitswesen

▲

Application Interfaces

Anwendung

Daher nicht standardisiert

▲

Aufgabe 3

(13)

LE 16

25

9.4 IDL

▲

IDL (Interface Definition Language)

Sprache zur Spezifikation der Schnittstellen aller Objekte, die von den Klienten verwendet werden Rein beschreibende Sprache

Objekte können in IDL nicht implementiert oder aus einem IDL-Quelltext heraus aufgerufen werden

IDL-Definition muß in äquivalente Konstrukte der jeweiligen Programmiersprache übersetzt werden (language mapping)

Entwicklung der ODL des ODMG-Standards auf der Grundlage von IDL entwickelt

ODL ohne extent, keyund relationship ist weitgehend mit IDL identisch

LE 16

26

9.4 IDL

▲

IDL-Syntax

Ähnlich der Syntax von C++

IDL-Definition

const <Typ> <Name> = ...;

typedef ...;

enum <Name> { ... };

struct <Name> { ... };

exception <Name> { ... };

interface <Name> { ... };

module <Name> { ... };

(14)

LE 16

27

9.4 IDL

▲

IDL-Schnittstelle (interface)

Spezifiziert Signaturen von Operationen, die ein Klient aufrufen kann

Wichtigste Komponente einer IDL-Definition interface Name

{ attribute Typ Attribut-Name;

...

void Operation()...;

...

};

LE 16

28

9.4 IDL

▲

Attribut

Jedes Attribut einer Schnittstelle ist logisch äquivalent zu einem Paar von Zugriffsoperationen

Eine zum Schreiben

Eine zum Lesen des Attributwertes

Ein Attribut kann als readonlydeklariert werden

Nur eine Operation zum Lesen des Werts

Wert muß nicht konstant sein readonly attribute Typ1 Name1;

attribute Typ2 Name2;

(15)

LE 16

29

9.4 IDL

▲

Signatur einer Operation

[oneway] <Ergebnistyp> <Operationsname>

( in Typ1 Parameter1, out Typ2 Parameter2,

inout Typ3 Parameter3, ...) [raises (Ausnahme1, ..., AusnahmeM)]

[context (Kontextname1,..., KontextnameK)]

Wenn die Operation keinen Ergebnistyp besitzt, dann Angabe von void(wie in C++)

Klassenoperationen können in IDL nicht spezifiziert werden

LE 16

30

9.4 IDL

raises-Klausel

Ist optional

Spezifiziert die Ausnahmen innerhalb eines Operationsaufrufs

Ausnahme bedeutet

Aufgerufene Operation wird nicht ordnungsgemäß zu Ende geführt

★ Aufruf einer Operation zu einem ungeeigneten Zeitpunkt oder mit sinnlosen Eingabeparametern Werte der out- und inout-Parameter sind undefiniert context

Ist optional

Bereitstellung zusätzlicher Informationen

Aufenthaltsort des Klienten für die Rückmeldung der Ergebnisse

(16)

LE 16

31

9.4 IDL

▲

Kommunikationsarten

Synchrone Kommunikation

Ist Standardfall

Klient wartet nach dem Operationsaufruf auf Rückgabe der Ergebnisse oder auf eine Ausnahmemeldung

Asynchrone Kommunikation

Schlüsselwort oneway

Klient wartet dann nicht auf das Ende der Operation, sondern arbeitet sofort weiter

Voraussetzung

Keine Rückgabe von Ergebnissen

LE 16

32

9.4 IDL

▲

Vererbung

IDL-Schnittstellen können von beliebig vielen anderen Schnittstellen erben

interface D: B1, B2 { ... };

Hinzufügen neuer Deklarationen in der Unterklasse möglich

Geerbte Bezeichner können in der spezialisierten Schnittstelle redefiniert werden

Weiterhin verfügbar unter

<Basis-Schnittstelle>::<Bezeichner>

Unzulässig ist, wenn ein Bezeichner von mehreren Basis-Schnittstellen geerbt wird

(17)

LE 16

33

9.4 IDL

▲

Beispiel

Kunde Nummer Name Umsatz erfassen()

erhoehenUmsatzUm()

Lieferant Firma

Ansprechpartner

erfassen() Handelsbeteiligter Adresse

Telefon

LE 16

34

9.4 IDL

struct AdresseT { string Strasse;

unsigned short PLZ;

string Ort;

};

interface Handelsbeteiligter { attribute AdresseT Adresse;

attribute string Telefon;

};

(18)

LE 16

35

9.4 IDL

interface Kunde: Handelsbeteiligter { readonly attribut long Nummer;

attribute string Name;

readonly attribute float Umsatz;

void erfassen() raises (schonVorhanden);

void erhoehenUmsatzUm ( in float Erhoehung);

};

interface Lieferant: Handelsbeteiligter { attribute string Firma;

attribute string Ansprechpartner;

void erfassen() raises (schonVorhanden);

};

LE 16

36

9.4 IDL

▲

Modul

Gruppierung mehrerer IDL-Schnittstellen und anderer IDL-Definitionen zu einer logischen Einheit

module Personen

{ interface Kunde {...};

interface Lieferant {...};

};

Zugriff auf Schnittstelle Kundemittels Personen::Kunde

(19)

LE 16

37

9.4 IDL

▲

C++ mapping

Jede Schnittstelle (interface) wird zu einer Klasse Jede IDL-Operation wird eine Member-Funktion Aus der IDL-Signatur

T op (in T p1, inout T p2, out T p3) wird in C++

T op (T p1, T& p2, T& p3)

Jedes IDL-Attribut auf zwei Member-Funktionen zum Lesen und Schreiben abbilden

für Readonly-Attribut nur Lese-Operation Modul wird namespace-Konstrukt

IDL-Basistyp wird äquivalenter Typ in C++

z.B. shortwird zu CORBA::Short Aufgabe 4

LE 16

38

9.5 Entwicklung eines verteilten Systems

▲

Entwicklungsprozeß in 5 Schritten

1. Server-Klassen in IDL spezifizieren 2. IDL-Schnittstellen mit dem Precompiler

übersetzen

3. Server-Objekte implementieren 4. Klient-Anwendung implementieren 5. Server-Hauptprogramm erstellen

(20)

LE 16

39

9.5 Entwicklung eines verteilten Systems 1 Server-Klassen in IDL spezifizieren

Server-Klassen im OOA-Modell identifizieren

Ermitteln, welche Attribute und Operationen,

netzweit und welche lokal

zur Verfügung gestellt werden müssen Erstellen von IDL-Spezikationen für alle

Server-Klassen

LE 16

40

9.5 Entwicklung eines verteilten Systems

Beispiel

interface SimpleObject

{ attribute short value1;

attribute short value2;

short calcSum();

};

SimpleObject Value1: Short Value2: Short calcSum(): Short

(21)

LE 16

41

9.5 Entwicklung eines verteilten Systems 2 IDL-Schnittstellen übersetzen

Precompiler generiert vier Dateien

Client-Header-Datei

Ins Client-Hauptprogramm einbinden Client-Implementierungsdatei

Enthält Funktionen für den Zugriff auf die Klassen- Schnittstelle des entfernten Objekts

Server-Header-Datei

In Objekt-Implementierung einbinden Server-Implementierungsdatei

Enthält den Programmcode, der im Server die Verbindung zwischen dem ORB und der Objekt- Implementierung herstellt

LE 16

42

9.5 Entwicklung eines verteilten Systems 3 Objekt-Implementierung erstellen

Programmierer muß das allgemeine

Transformationsschema des IDL-Precompilers kennen

Implementierung des Server-Objekts erfolgt mit der Klasse SimleObject_i

Abgeleitet von der Klasse SimpleObjectBOAImpl

Generiert durch den IDL-Compiler

(22)

LE 16

43

9.5 Entwicklung eines verteilten Systems

//SimpleObject_i.h

class SimpleObject_i: public

SimpleObjectBOAImpl { CORBA_Short m_value1;

CORBA_Short m_value2;

public:

virtual CORBA_Short value1

(CORBA_Environment &env);

virtual void value1 ( CORBA_Short value, CORBA_Environment &env);

// analoge Signaturen für value2 ...

virtual CORBA_Short calcSum

(CORBA_Environment &env);

};

LE 16

44

9.5 Entwicklung eines verteilten Systems

//SimpleObject_i.cpp

CORBA_Short SimpleObject_i::value1

(CORBA_Environment &env) { return m_value1;}

void SimpleObject_i::value1

(CORBA_Short value,CORBA_Environment &env) { m_value1 = value;}

//analoge Operationen für value2 ...

CORBA_Short SimpleObject_i::calcSum

(CORBA_Environment &env) { return m_value1 + m_value2; }

(23)

LE 16

45

9.5 Entwicklung eines verteilten Systems 4 Client-Anwendung implementieren

Objekts wird über Zeiger eindeutig identifiziert Mit Hilfe dieses Zeigers können Operationen

des Objekts aufgerufen werden

Operationsaufruf erfolgt durch Aufruf der entsprechenden Operation im lokalen Stub

Erstellung des Stubs in der verwendeten Programmiersprache

Kein Unterschied beim Zugriff auf entfernte und lokale Operationen

LE 16

46

9.5 Entwicklung eines verteilten Systems

//Client.cpp: Client-Anwendung

#include "SimpleObject.hh"

int main (int argc, char **argv) { ...

//Zeiger auf das Server-Objekt;

SimpleObject_var SimpleObjectVar;

//Einlesen des Servernamens (Rechner) ...

//Binden des Servernamens(Rechner) an das Server-Objekt ...

//Eingabe der gewünschten Operation

(24)

LE 16

47

9.5 Entwicklung eines verteilten Systems

try

{ switch (auswahl)

{ case 1 : cout << "Wert 1: " ; cin >> txt;

val = atoi (txt);

SimpleObjectVar->value1(val);

// analog für value 2 ...

break;

case 2 : CORBA_Short sum;

sum =SimpleObjectVar->calcSum();

cout <<sum <<endl; break ; }

} //end try ...

}

LE 16

48

9.5 Entwicklung eines verteilten Systems 5 Server-Hauptprogramm erstellen

Zwei Aufgaben

Für jede Server-Klasse wird mindestens ein Objekt erzeugt, damit der Klient darauf zugreifen kann

CORBA wird mitgeteilt, daß der Server bereit ist Operationsaufrufe vom Client entgegenzunehmen

impl_is_ready()

(25)

LE 16

49

9.5 Entwicklung eines verteilten Systems

Jeder Server besitzt einen Namen, der auf der jeweiligen Plattform eindeutig ist

Implementation Repository

Abbildung des Server-Namens auf die Prozeß-Identifikation und den

Computernamen des ausführbaren Codes, der den Server implementiert

Daher

Jeder Server muß durch den Programmierer im Implementation Repository registriert werden

Automatisches Starten des Codes, wenn ein request für ein Objekt eintrifft, dessen

Objektreferenz zu einem speziellen Server gehört

LE 16

50

9.5 Entwicklung eines verteilten Systems

//Srv_Main.C:

//Hauptprogramm Server-Implementierung int main()

{ //Erzeugen eines Objekts

SimpleObject_i aSimpleObject;

try

{ //Initialisierung des Server- Objekts

//ist abgeschlossen

CORBA_Orbix.impl_is_ready(

"SimpleObject");

} ...

return 0;

}

(26)

LE 16 51

▲

Danke!

▲

Diese Präsentation bzw. Teile dieser Präsentation enthalten Inhalte und Grafiken des Lehrbuchs der

Objektmodellierung von Heide Balzert, Spektrum Akademischer Verlag 1999

LE 16

52

Aufgabe 1 (10 min)

▲

Kommunikation zwischen verteilten Objekten erläutern können

▲

Erklären Sie,

a. wie ein Objekt auf einem entfernten Server identifiziert wird

b. wann ein Operationsaufruf eine

Ausnahmebehandlung auf der Server-Seite auslöst

c. den Unterschied zwischen dem »normalen«

Operationsaufruf innerhalb eines Programms und dem Operationsaufruf eines entfernten Objekts

▲Lösung

(27)

LE 16

53

Aufgabe 2 (10 – 15 min)

▲

ORB erklären können

▲

Erläutern Sie,

wofür der ORB verantwortlich ist,

aus welchen Komponenten er besteht und wofür diese Komponenten verantwortlich sind, den Unterschied zwischen statischen und

dynamischen Operationsaufrufen.

▲

Lösung

LE 16

54

Aufgabe 3 (5 – 10 min)

▲

OMA erläutern können

Beschreiben Sie,

aus welchen Komponenten die OMA- Architektur besteht und

für welche Aufgaben diese Komponenten verantwortlich sind.

▲

Lösung

(28)

LE 16

55

Aufgabe 4 (15 min)

▲

IDL-Definitionen für Klassen erstellen können

Sparkonto Art

abheben() gutschreibenZinsen() Girokonto

Sollzins Dispokredit

Konto Kontonummer Habenzins Kontostand einzahlen

abheben() gutschreibenZinsen() abbuchenZinsen()

LE 16

56

Aufgabe 4

Bei einem Girokonto werden Zinsen quartalsweise gutgeschrieben bzw.

abgebucht. Bei einem Sparkonto erfolgt die Gutschrift der Zinsen jährlich. Gehen Sie bei der Berechnung der Zinsen davon aus, daß der Betrag aus gespeicherten Daten – die hier nicht modelliert sind – errechnet werden kann.

▲

Lösung

(29)

LE 16

57

Lösung der Aufgabe 1

a. Identifizieren des entfernten Objekt über seine systemweit eindeutige Objektreferenz, die auf physischen Aufenthaltsort der zugehörigen Objekt- Implementierung abgebildet wird

(Implememantation Repository)

b. Eine Ausnahme (exception) tritt immer dann auf, wenn die gerufene Operation nicht ordnungsgemäß ausgeführt werden kann.

c. Bei »normaler« objektorientierter Programmierung kann ein Objekt nur mit Objekten innerhalb

desselben Programms kommunizieren. Der ORB ermöglicht die Kommunikation mit Objekten sowohl innerhalb desselben Programms als auch mit Objekten in anderen Programmen, auch auf einem anderen Rechner und unter einem anderen Betriebssystem.

LE 16

58

Lösung der Aufgabe 2

a. Finden der Objekt-Implementierung; request an die Objekt-Implementierung weitergeben und eine Anwort zurückgeben

b. Komponenten

IDL Stubs: lokale Vertreter entfernter Objekte Dynamic Invocation Interface: Klient kann

Operationsaufruf zur Laufzeit generieren Object Odapter: nimmt die Operationsaufrufe

entgegen, sorgt für Aufruf der Operation

IDL Skeleton und Dynamic Skeleton Interface:

Verbinden Operationsaufrufe mit den Implementierungen dieser Operationen c. Statische Operationsaufrufe: Schnittstelle des

entfernten Objekts bei der Übersetzung des Klienten bekannt ist. Sonst dynamsche Aufrufe

(30)

LE 16

59

Lösung der Aufgabe 3

▲

Komponenten der OMA (Object Management Architecture)

ORB: bildet den Kern der Architektur Object services: elementare Funktionen Common facilities : stellen eine höhere

Funktionalität bereit, die in vielen Anwendungsbereichen benötigt wird

Domain interfaces: Klassen-Schnittstellen, die gezielt die Funktionalität einiger

Anwendungsbereiche realisieren

Application objects: eigentliche Anwendung

LE 16

60

Lösung der Aufgabe 4

interface Konto

{ readonly attribute long Kontonummer;

attribute float Habenzins;

readonly float Kontostand;

void einzahlen (in float Betrag);

}

interface Sparkonto: Konto

{ readonly attribute string Art;

void abheben(in float Betrag) raises (zuWenigGeld);

void gutschreibenZinsen (in short Jahr) raises (JahrSchonGutgeschrieben);

}

(31)

LE 16

61

Lösung der Aufgabe 4

interface Girokonto: Konto { attribute float Sollzins;

attribute float Dispokredit;

void abheben(in float Betrag)

raises (DispokreditUeberschritten);

void gutschreibenZinsen (in string Quartal) raises (QuartalSchonGutgeschrieben);

void abbuchenZinsen (in string Quartal) raises (QuartalSchonAbgebucht);

}