Übungsblatt 8 - Lehrstuhl Software-Systemtechnik - BTU Cottbus

3. Dezember 2013 

LS Software-Systemtechnik 

Entwicklung von Software-Systemen 

Übungsblatt 8 

Aufgabe 1 

(2 Punkte) 

Welche Unterschiede bestehen zwischen Lastenheft und Pflichtenheft? Warum werden beide benötigt? In 

welcher Reihenfolge werden sie durch welche Prozessschritte erstellt? 

Aufgabe 2 

(6 Punkte) 

Beantworten Sie folgende Fragen für Softwareentwicklungsphasen. 

1. Was ist die Produkt-Definition? 

2. Was sind die Ergebnisse der Produkt-Definition? 

3. Was ist der Produkt-Entwurf? 

4. Was sind die Ergebnisse des Produkt-Entwurfs? 

5. Was ist der Unterschied zwischen Produkt-Entwurf und Software-Entwurf? 

6. Sowohl in der Produkt-Definition als auch im Produkt-Entwurf werden Modelle (Beschreibungen) 

des Produkts erstellt. Was ist der grundlegende Unterschied zwischen diesen Modellen? 

Aufgabe 3 

(5 Punkte) 

Wesentliches Ergebnis des Software-Entwurfs ist eine Software-Architektur. Stellen Sie möglichst vollständig 

dar, welche Rolle eine SW-Architektur im SW-Entwicklungsprozess spielt. 

Aufgabe 4 

(3 Punkte) 

Was versteht man unter folgenden Konzepten der Objektorientierung? 

1. Vererbung? 

2. Polymorphie? 

3. Kapselung? 

Aufgabe 5 

(15 Punkte) 

Auf der nächsten Seite des Übungsblattes ist eine kleine Fallstudie gegeben. Lesen Sie sich diese genau 

durch und erstellen Sie dazu passend 

1. ein Kontextdiagram 

2. eine Verfeinerung des Kontextdiagramms aus 1. (DFD 0). 

Nehmen Sie hierbei an, dass das zu beschreibende System alle Anfragen, Bewerbungen, Rechnungen, Studienunterlagen 

sowie Testate verwaltet. 

Aufgabe 6 

(4 Punkte) 

Erklären Sie die charakteristischen Unterschiede bei einer synchronen und eine asynchronen Operation in 

einem Sequenzdiagram. Modellieren Sie beide Varianzten grafisch und erklären Sie kurz den Unterschied 

der Notation. 

Seite 1 von 2




Fallstudie - Fernstudium 

Die BTU Cottbus bietet Fernkurse für Studenten an. Dabei dauert jeder Kurs 20 Wochen und wird wöchentlich 

im Rahmen einer digitalen Übungssitzung und eines Testats organisiert. Am Ende des Kurses wird eine 

beaufsichtigte Prüfung durchgeführt. 

Ein Sachbearbeiter aus dem Studieredensekretariat befasst sich mit diesbezüglichen Anfragen und Anträgen 

sowie Bewerbungen von Studenten. Verfügen potentielle Bewerber über die nötigen Qualifikationen, 

werden diese gebeten, ein Antragsformular auszufüllen und an das Studierendensekretariat zu senden. 

Nachdem der Modulverantwortliche eine Bewerbung geprüft hat, geht diese zurück an das Studierendensekretariat. 

Dieses legt eine Liste der angenommenen Bewerber an. Dazu werden die Daten aus dem Antragsformular 

verwendet. Im Anschluss wird eine Rechnung erstellt, welche den angehenden Studenten 

zugesendet wird. Geleistete Zahlungen werden in einer Übersicht notiert, die ausstehende Forderungen dokumentiert. 

Die erste Charge von Studienmaterial sowie dazu passenden Testaten wird durch die Bibliothek 

an Studierende verschickt, sobald diese bezahlt haben (dazu haben die verantwortlichen Bibliothekare Zugriff 

auf die Übersicht der ausstehenden Forderungen). 

Die zurückgeschickten Testate werden durch das wissenschaftliche Personal kontrolliert. Die Ergebnisse 

werden anschließend zusammen mit Kommentaren bis zur nächsten Woche bzw. zum nächsten Block versendet. 

Weiterhin wird neues Material durch die Bibliothek nur dann versendet, sofern ein Student auch die 

Antworten für das aktuelle Testat zurückgeschickt hat. 

Das Übungsblatt ist bestanden, wenn bei jeder Aufgabe mindestens 50% der Punkte erreicht wurden. Jede 

Lerngruppe gibt eine gemeinsame Lösung in einer PDF-Datei mit einer maximalen Dateigröße von 2 MByte 

bis zum 05.12.2013 um 23:59 Uhr per eMail bei Ihrem Tutor sowie bei M.Schubanz@tu-cottbus.de ab. 

Ausnahmen kann der Tutor auf Nachfrage zulassen. Die mündliche Kontrolle der Lösung und Rückgabe 

des Übungsblattes findet in der Woche vom 09.12.2013 statt. 

Seite 2 von 2




Material 8 

Lastenheft 

Quelle: http://www.stefan-baur.de/ 

In [ . . . ] der Definitionsphase eines IT-Projektes stellt sich immer die Frage über die Vorgehensweise, die 

selbstverständlich immer vom jeweiligen Auftraggeber abhängig ist. Doch kann meines Erachtens unabhängig 

vom Auftraggeber folgender, grober Verlauf während der Anforderungsdefinition angestrebt werden: 

1. Lastenheft vom Auftraggeber erhalten 

2. Anforderungen erheben und Lastenheft korrigieren 

3. Korrigiertes Lastenheft vom Kunden absegnen lassen 

4. Pflichtenheft gegen Bezahlung erstellen 

5. Anhand des Pflichtenhefts den Aufwand schätzen 

6. Angebot und Vertrag 

Lastenheft vs. Pflichtenheft 

1. Während im Lastenheft die Anforderungen des zu entwickelnden Produkts aus Sicht des fachunkundigen 

Auftraggebers beschrieben werden, spiegelt das Pflichtenheft die Anforderungen des Lastenhefts 

im Hinblick auf eine risikoarme Umsetzung aus Sicht des fachkundigen Auftragnehmers wider. (Als 

Fach ist die technologische Gesamtheit zu verstehen, mit der das Produkt entwickelt wird.) 

2. Zur Erstellung eines Heftes scheint allerdings folgender Unterschied weitaus nützlicher zu sein: Das 

Lastenheft stellt die Problemstellung des Auftraggebers dar und das Pflichtenheft den Lösungsvorschlag 

des Auftragnehmers. 

Aufgabe 1 

Szenario: 

Ein Kunde möchte einen Internetdienst für Brettspiele in Auftrag geben. 

Die grobe Zielvorstellung des Kunden lautet: 

Dem einzelnen Benutzer soll das Spielen (von Brettspielen) mit anderen Benutzern über einen Internetdienst 

ermöglicht werden. Folgende Brettspiele sollen für den einzelnen Benutzer zunächst zur Verfügung 

stehen: 

• Mühle, 

• Dame 

• Schach 

Erstellen Sie ein Lastenheft! 

Seite 1 von 9




Architektur 

Quelle: R. Reussner, W. Hasselbing, „Handbuch der Software-Architektur“, dpunkt.verlag, 2008 

Definition: 

Die Software-Architektur ist die grundlegende Organisation eines Systems, dargestellt durch dessen Komponenten, 

deren Beziehungen zueinander und zur Umgebung sowie die Prinzipien, die den Entwurf und die 

Evolution des Systems bestimmen. 

Eine Software-Architektur beschreibt [...] nicht den detaillierten Entwurf, vielmehr geht es darum, die Zusammenhänge 

zwischen den Anforderungen und dem konstruierten System zu beschreiben, möglichst mit 

einer Begründung für die Entwurfsentscheidungen. Die Wahl einer bestimmten Architektur hat dann einen 

starken Einfluss auf die nicht funktionalen (qualitativen), technischen Eigenschaften der resultierenden Systeme. 

Beispiel: Drei-Schichten-Architektur 

Presentation tier 

The top-most level of the application 

is the user interface. The main function 

of the interface is to translate tasks 

and results to something the user can 

understand. 

>GET SALES 

TOTAL 

>GET SALES 

TOTAL 

4 TOTAL SALES 

Logic tier 

This layer coordinates the 

application, processes commands, 

makes logical decisions and 

evaluations, and performs 

calculations. It also moves and 

processes data between the two 

surrounding layers. 

GET LIST OF ALL 

SALES MADE 

LAST YEAR 

ADD ALL SALES 

TOGETHER 

Data tier 

Here information is stored and retrieved 

from a database or file system. The 

information is then passed back to the 

logic tier for processing, and then 

eventually back to the user. 

QUERY 

SALE 1 

SALE 2 

SALE 3 

SALE 4 

Database 

Storage 

Beispiel für eine Dreischichten-Architektur (Quelle: Wikipedia) 

Seite 2 von 9




Eine typische Drei-Schichten-Architektur besteht aus den folgenden Schichten: 

• Präsentationsschicht - Diese, auch Front-End bezeichnet, ist für die Repräsentation der Daten, Benutzereingaben 

und die Benutzerschnittstelle verantwortlich. 

• Logikschicht - Sie beinhaltet alle Verarbeitungsmechanismen. Hier ist die Anwendungslogik vereint. 

• Datenhaltungsschicht - Sie enthält die Datenbank und ist verantwortlich für das Speichern und Laden 

von Daten. 

Quelle: Wikipedia: 

Durch eine Schichtenarchitektur wird die Komplexität der Abhängigkeiten innerhalb des Systems 

reduziert und somit eine geringere Kopplung bei gleichzeitig höherer Kohäsion der einzelnen 

Schichten erreicht. Insbesondere werden durch sie Zyklen im Abhängigkeitsgraphen 

vermieden, insofern das Dependency Inversion Principle eingehalten wird. Dies hat Vorteile 

sowohl für das Verständnis wie auch für die Wartung des Systems. 

Vorteile einer Schichtenarchitektur: 

• Übersichtlichkeit 

• Schichten können einfach ausgetauscht werden, weil die einzelnen Schichten nicht miteinander verwoben 

sind (Beispiel: Datenbank austauschen) 

• Programmlogik ist von GUI getrennt 

• Getrennte Entwicklung wird vereinfacht 

Schematische Darstellung in einem Klassendiagramm 

Eine sehr vereinfachte Darstellung einer Architektur ist auf der nächsten Seite zu finden. Die 3-Schichten 

sind über das Entwurfsklassendiagramm für einen Artikel gezeichnet. Im Analyseklassendiagramm wäre 

nämlich nur die Klasse Artikel vorhanden, was aber zur Darstellung der 3-Schichten-Architektur ungeeignet 

wäre. 

Seite 3 von 9




javax.swing.JDialog 

Präsentations-Schicht 

ArtikelDialog 

Logik-Schicht 

Artikel 

java.io.FileReader 

Daten-Schicht 

ArtikelFileReader 

ArtikelFile 

Beispiele 

Schichtenarchitektur schematisch dargestellt anhand von Cluster-Hardware – Quelle: http://bobi.blog.com/ 

Seite 4 von 9

Echtes Beispiel: http://www.openkm.com/Architecture.html 




Echtes Beispiel angelehnt an nicht mehr existierende Quelle von http://www.openkm.com/ 

Seite 5 von 9




Einschub: Objektorientierung 

Entnommen aus: 

• Helmut Balzert, Lehrbuch der Software-Technik, 1996 

• Bernhard Lahres, Gregor Raýman, Praxisbuch Objektorientierung 

Beispiel 

• jedes Einfamilienhaus ist ein Objekt 

• Firma Nobel & Teuer hat Auftrag zum Verkauf eines 

Landhauses 

• zum ”Landhaus“-Objekt werden folgende Daten 

(auch Attributwerte) gespeichert: Haustyp, Name des 

Besitzers, Adresse des Landhauses, Wohnfläche, Anzahl 

der Bäder, Schwimmbad vorhanden, Baujahr, 

Verkaufspreis 

(Einfamilienhaus) 

Haustyp: Landhaus 

Besitzer: Dr. Kaiser 

Adresse: Konigstein 

Wohnfläche: 400 m 2 

Anzahl Bäder: 3 

Hat Schwimmbad: ja 

Garten: 5000 m 2 

Baujahr: 1976 

Verkaufspreis: 2 Mio e 

• Käufer möchte Verkaufspreis wissen ⇒ Funktion 

(auch Operation) auf Landhaus angewendet (Ein 

Objekt enthält Attributwerte, auf die nur über die 

Operationen zugegriffen werden kann. Die Attributwerte 

des Objekts sind verkapselt, d.h. von außen 

nicht sichtbar.) 









Baujahr: 1976 


Verkaufspreis erfragen 

• Außer dem Objekt ”Landhaus“ werden noch andere Einfamilienhäuser angeboten. 









Baujahr: 1976 



Haustyp: Bungalow 

Besitzer: Herzog 

Adresse: Stiepel 



Hat Schwimmbad: nein 


Baujahr: 1986 

Verkaufspreis: 1.5 Mio e 


Haustyp: Stadthaus 

Besitzer: Urban 

Adresse: Bochum 



Hat Schwimmbad: nein 


Baujahr: 1990 


Seite 6 von 9




Beispiel 

• Sie haben zwar alle unterschiedliche Attributwerte, 

die aber von der gleichen Art sind. Man spricht von 

Attributen ”Haustyp“, ”Besitzer“ usw. Außerdem 

besitzen alle Objekte die gleiche Operation ”Verkaufspreis 

erfragen.“ Diese Objekte werden zu der 

Klasse ”Einfamilienhaus“ zusammengefasst. (Eine 

Klasse definiert die Attribute und Operationen ihrer 

Objekte.) 

Einfamilienhaus 

Haustyp 

Besitzer 

Adresse 

Wohnfläche 

Anzahl Bäder 

Hat Schwimmbad 

Garten 

Baujahr 

Verkaufspreis 


Geschäftshaus 

• Nobel & Teuer vermittelt nun auch Geschäftshäuser 

analog zu Einfamilienhäuser wird eine Klasse ”Geschäftshaus“ 

gebildet 

Besitzer 

Adresse 

Anzahl Büroräume 

Geschosszahl 

Hat Aufzug 

Hat Tiefgarage 

Baujahr 

Verkaufspreis 


Anzahl Büroräume erfragen 

• vergleicht man beide Klassen fallen die gleichen Attribute ”Besitzer“ usw. auf diese werden in eine 

neue Klasse ”Immobilie“ eingetragen 

Immobilie 

Besitzer 

Adresse 

Baujahr 

Verkaufspreis 


Einfamilienhaus 

Adresse 

Wohnfläche 

Anzahl Bäder 

Hat Schwimmbad 

Garten 


Geschäftshaus 

Anzahl Büroräume 

Geschosszahl 

Hat Aufzug 

Hat Tiefgarage 


Anzahl Büroräume erfragen 

• die Klasse ”Immobilien“ vererbt alle ihre Attribute an die Klassen ”Einfamilienhaus“ und ”Geschäftshaus.“ 

Die Klasse ”Einfamilienhaus“ besitzt also zusätzlich zu ihren eigenen Attributen und 

Operationen alle Attribute und Operationen der Klasse ”Immobilie.“ 

• Polymorphismus bedeutet, dass dieselbe Botschaft an Objekte verschiedener Klassen einer Vererbungshierarchie 

gesendet werden kann und diese Objekte die Botschaft ganz unterschiedlich interpretieren 

können. So könnte ”Verkaufspreis erfragen“ angewendet bei ”Einfamilienhaus“ den Verkaufspreis 

erhöht um Mehrwertsteuer und Maklergebühr zurückgeben, wobei ”Verkaufspreis erfragen“ 

angewendet bei ”Geschäftshaus“ nur den Verkaufspreis erhöht um die Maklergebühr zurückgibt 

Seite 7 von 9




Konzepte 

Kapselung von Daten 

Daten gehören in der Objektorientierung explizit einem Objekt, ein direkter Zugriff wie auf die Datenstrukturen 

wie in der strukturierten Programmierung ist nicht mehr erlaubt. 

Objekte haben damit also das alleinige Recht, ihre Daten zu verändern oder auch lesend auf sie zuzugreifen. 

Möchte ein Aufrufer (zum Beispiel ein anderes Objekt) diese Daten lesen oder verändern, muss er sich über 

eine klar definierte Schnittstelle an das Objekt wenden und eine Änderung der Daten anfordern. 

Der große Vorteil besteht nun darin, dass das Objekt selbst dafür sorgen kann, dass die Konsistenz der Daten 

gewahrt bleibt. Falls zum Beispiel zwei Dateneinträge immer nur gemeinsam geändert werden dürfen, kann 

das Objekt dies sicherstellen, indem eine Änderung eines einzelnen Wertes gar nicht vorgesehen wird. 

Ein weiterer Vorteil besteht darin, dass von einer Änderung der zugrunde liegenden Datenstruktur nur die 

Objekte betroffen sind, die diese Daten verwalten. Wenn jeder beliebig auf die Daten zugreifen könnte, 

wäre die Anzahl der Betroffenen in einem System möglicherweise sehr hoch, eine Anpassung entsprechend 

aufwändig. 

Durch das in der Objektorientierung gegebene Prinzip der Datenkapselung haben Sie also auf jeden Fall 

Vorteile, weil Sie die Konsistenz von Daten wesentlich einfacher sicherstellen können. Damit ist es auch 

einfacher, die Korrektheit Ihres Programms zu gewährleisten. Außerdem reduzieren Sie den Aufwand bei 

Änderungen. Die internen Daten und Vorgehensweisen eines Objekts können geändert werden, ohne dass 

andere Objekte ebenfalls angepasst werden müssten. 

Polymorphie 

Wörtlich übersetzt bedeutet Polymorphie ”Vielgestaltigkeit“. Mit Bezug auf Glühbirnen können wir diesen 

Begriff definitiv anwenden: Glühbirnen gibt es in den verschiedensten Formen und Gestalten. Wir können 

diese verschiedenen Formen aber alle an einer ganz definierten Stelle anbringen: in einer dafür vorgesehenen 

Fassung. 

Energiesparlampen können in dasselbe Gewinde geschraubt werden wie eine Birne, die von Greenpeace den 

Preis ”Umweltschwein des Jahres“ erhalten hat. Dass sich die einzelnen Birnen dann ganz unterschiedlich 

verhalten, ist nicht mehr relevant. 

Genau diese Möglichkeiten, die es für den (auf den ersten Blick banalen) Bereich der Glühbirnen gibt, 

möchten wir auch in unseren objektorientierten Systemen nutzen. Wir möchten Stellen in unserem Code 

haben, die es uns erlauben, einzelne Elemente auszutauschen – wie eine Fassung für Glühbirnen: Ein Berechnungsverfahren 

für eine bestimmte Aufgabe ist nicht mehr schnell genug für Ihre Ansprüche? Tauschen 

Sie es doch einfach gegen ein effizienteres Verfahren aus, und klinken Sie es in die dafür vorgesehene Fassung 

ein. Ein neues Übertragungsprotokoll für Daten muss unterstützt werden? Schrauben Sie es in die 

Fassung, in die schon alle anderen Übertragungsprotokolle eingesetzt werden konnten. 

Die Polymorphie im Zusammenspiel mit einem cleveren Systementwurf ermöglicht uns ein solches Vorgehen. 

Gegenstand des Entwurfs ist es, die Stellen zu finden, an denen Fassungen vorgesehen werden müssen, 

und die Objekte zu bestimmen, die in diese Fassungen geschraubt werden. An den richtigen Punkten eingesetzt, 

kann die Nutzung der Polymorphie dadurch zu wesentlich flexibleren Programmen führen. Sie 

steigert damit die Wartbarkeit und Änderbarkeit unserer Software. 

Seite 8 von 9




Vererbung 

Die Glühbirnen in unserem Beispiel können ganz unterschiedliche Formen aufweisen, der Energieverbrauch 

und die Leuchtkraft können sich erheblich unterscheiden. Trotzdem können wir sie alle in die gleiche Fassung 

schrauben, und, sofern sie nicht defekt sind, werden sie das tun, was wir von Glühbirnen erwarten: Sie 

leuchten. 

Wir stellen also fest, dass diese verschiedenen Glühbirnen eine grundlegende Gemeinsamkeit haben: Sie 

entsprechen einer Spezifikation, die es erlaubt, sie in eine genormte Fassung zu drehen und mit der in 

Deutschland vorgesehenen Standardstromspannung von 220 Volt zu 

betreiben. 

In einer objektorientierten Anwendung könnten wir diese Gemeinsamkeiten der verschiedenen Glühbirnenarten 

modellieren, indem wir die so genannte Vererbung der Spezifikation verwenden. Eine abstrakte 

Spezifikation, wie sie für Glühbirnen von einer Normungsorganisation kommt, gibt dabei vor, welche Eigenschaften 

die Objekte haben müssen, um die Spezifikation zu erfüllen. In objektorientierten Anwendungen 

würden wir in diesem Fall davon sprechen, dass die verschiedenen Arten von Glühbirnen ihre Spezifikation 

von der abstrakten Spezifikation erben, die als Norm ausgegeben worden ist. 

Die Vererbung der Spezifikation hängt sehr eng mit der Polymorphie zusammen. Dass unsere Elektrogeräte 

nämlich alle die Normen für den Stromanschluss erfüllen, macht sie austauschbar. Jedes von ihnen kann 

an die gleiche Steckdose angeschlossen werden und wird dann seine Arbeit verrichten. 

Seite 9 von 9

Übungsblatt 8 - Lehrstuhl Software-Systemtechnik - BTU Cottbus

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

Template löschen?

Als Template speichern?