Wirtschaftsinformatik mit Office 2010 - HERDT
Werbung
Wirtschaftsinformatik Holger Ludolph, Thorsten Schwandt, Peter K. Siebert 1. Auflage, 2013 ISBN 978-3-86249-262-6 mit Office 2010 Jahrgangsstufe 11 Band 1 Berufliches Gymnasium Nordrhein-Westfalen BS-BG-NRW-WINF1-W72010 Impressum ISBN 978-3-86249-262-6 Matchcode: BS-BG-NRW-WINF1-W72010 Autoren: Holger Ludolph Studienrat und Fachlehrer für BWL/VWL und Datenverarbeitung Thorsten Schwandt Studienrat und Fachlehrer für Wirtschaftsinformatik und Wirtschaftswissenschaft Peter K. Siebert Studiendirektor und Fachlehrer für Informatik und Physik Produziert im HERDT-Digitaldruck 1. Auflage, 2013 HERDT-Verlag für Bildungsmedien GmbH Am Kümmerling 21-25 55294 Bodenheim Internet: www.herdt.com E-Mail: [email protected] © HERDT-Verlag für Bildungsmedien GmbH, Bodenheim Alle Rechte vorbehalten. Kein Teil des Werkes darf in irgendeiner Form (Druck, Fotokopie, Mikrofilm oder einem anderen Verfahren) ohne schriftliche Genehmigung des Verlags reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. Dieses Buch wurde mit großer Sorgfalt erstellt und geprüft. Trotzdem können Fehler nicht vollkommen ausgeschlossen werden. Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Wenn nicht explizit an anderer Stelle des Werkes aufgeführt, liegen die Copyrights an allen Screenshots beim HERDT-Verlag. Sollte es trotz intensiver Recherche nicht gelungen sein, alle weiteren Rechteinhaber der verwendeten Quellen und Abbildungen zu finden, bitten wir um kurze Nachricht an die Redaktion. Die in diesem Buch und in den abgebildeten bzw. zum Download angebotenen Dateien genannten Personen und Organisationen, Adress- und Telekommunikationsangaben, Bankverbindungen etc. sind frei erfunden. Eventuelle Übereinstimmungen oder Ähnlichkeiten sind unbeabsichtigt und rein zufällig. Die Bildungsmedien des HERDT-Verlags enthalten Verweise auf Webseiten Dritter. Diese Webseiten unterliegen der Haftung der jeweiligen Betreiber, wir haben keinerlei Einfluss auf die Gestaltung und die Inhalte dieser Webseiten. Bei der Bucherstellung haben wir die fremden Inhalte daraufhin überprüft, ob etwaige Rechtsverstöße bestehen. Zu diesem Zeitpunkt waren keine Rechtsverstöße ersichtlich. Wir werden bei Kenntnis von Rechtsverstößen jedoch umgehend die entsprechenden Internetadressen aus dem Buch entfernen. Die in den Bildungsmedien des HERDT-Verlags vorhandenen Internetadressen waren zum Zeitpunkt der Erstellung der jeweiligen Produkte gültig. Sollten Sie die Inhalte nicht mehr unter den angegebenen Adressen finden, sind diese eventuell inzwischen komplett aus dem Internet genommen worden oder unter einer neuen Adresse zu finden. Bildquellenverzeichnis Seite 7 LAN-Party, © iStock/Matej Michelizza Seite 12 Set of solid state drives (SSD), © iStock/Oleksiy Mark Seite 25 young couple with a laptop, © iStock/Alex Raths Seite 32 the sheet of paper with the hole against the black background, © Fotolia/Pavel Losevsky Seite 37 Zwei Frauen, © iStock/Alex Raths Seite 109, 149-150, 201-202, 206-207 Logo, © Thorsten Schwandt 2 Seite 122 Bungalow, © Pixabay – Public Domain Seite 152, 188, 193, 196, 198 Filmklappe, © Pixabay – Public Domain Seite 176 Kamel, © Pixabay – Public Domain Seite 181 Monitor, Fernbedienung, © Pixabay – Public Domain Seite 208-211 Drei Häuser, © Pixabay – Public Domain Seite 210 Call center operator, © Fotolia/Kurhan © HERDT-Verlag 4 Grundlagen der objektorientierten ­ Modellierung und Programmierung Einstiegssituation Die remoTec GmbH aus Münster stellt moderne Fernbedienungen für Geräte aller Art her. Das Unternehmen hat in den vergangenen Jahren aufgrund sehr erfolgreicher Produktinnovationen schnell expandiert. Bislang lässt Clemens Funkel, der Geschäftsführer der remoTec GmbH, die Buchhaltung von einem Steuerberater vornehmen. Eingangsrechnungen von Lieferanten werden von einem Sachbearbeiter der remoTec GmbH geprüft und bezahlt. Ein anderer Sachbearbeiter schreibt die Ausgangsrechnungen und überwacht deren ­Bezahlung. Alle so anfallenden Belege werden quartalsweise zum Steuerberater gebracht. Dieser erstellt damit einen ordnungsgemäßen Jahresabschluss für das Unternehmen, der ­insbesondere aus der Bilanz und der Gewinn-und-Verlust-Rechnung besteht. Anfangs war Clemens Funkel mit dieser Situation auch zufrieden, doch seit einiger Zeit benötigt er für wichtige Entscheidungen immer kurzfristigere Auswertungen. Das Honorar, das sein Steuerberater für monatliche Auswertungen im gewünschten Umfang verlangt, empfindet Herr Funkel als zu hoch. Seit dem vergangenen Jahr arbeitet Nadine Stöppler nach ihrem erfolgreichen Studium der Betriebswirtschaftslehre mit den Schwerpunkten Rechnungswesen und Controlling für die remoTec GmbH. Sie soll nun eine unternehmensinterne Finanzbuchhaltung sowie ein darauf aufbauendes Controlling einführen. In einer Besprechung zwischen Herrn Funkel, Frau Stöppler und Herrn Rudnik, dem Leiter der Informatik­abteilung, wird die dazu notwendige Anschaffung neuer Software diskutiert. Herr ­Rudnik 4 Objektorientierte Modellierung und Programmierung erklärt, dass seine Abteilung nicht über die Kompetenzen zur Erstellung eines derart komplexen ­Programms verfügt. Daraufhin wird das Pro und Kontra von Individual- und Standardsoftware diskutiert. Am Ende des Meetings wird beschlossen, ein IT-Unternehmen damit zu beauftragen, ein an die Besonderheiten der remoTec GmbH angepasstes Buchhaltungssystem zu entwickeln. Herr Rudnik soll Angebote für ein solches System einholen. 4.1 Objektorientierte Analyse und Design 4.1.1 Software entwickeln Softwareentwicklung ist heute weit mehr als bloßes Programmieren. Zwar kann ein einzelner Programmierer in wenigen Tagen ein „kleines“ Programm wie z. B. ein Handy-Spiel oder eine Adressverwaltung programmieren. Heutige Softwaresysteme in Unternehmen sind aller­dings meist keine separaten Programme mehr, die auf einem einzelnen Computer ablaufen, sondern bestehen vielmehr aus Dutzenden einzelner Programmkomponenten, die auf verschiedenen, auch räumlich voneinander getrennten Computern ablaufen. Mit solch ­einem Softwaresystem arbeiten unter Umständen Hunderte von Mitarbeitern gleichzeitig, per ­Inter- oder Intranet verbunden, über Länder- und Kontinentgrenzen hinweg. Ferner müssen ­Softwaresysteme heute in der Lage sein, weitgehend autonom mit den Softwaresystemen anderer Unternehmen zu kommunizieren. Beispiel: In unserem Eingangsbeispiel wäre es beispielsweise wünschenswert, wenn die Sachbearbeiter der Verkaufsabteilung automatisch benachrichtigt werden würden, wenn das Zahlungsziel für die Ausgangsrechnung eines Kunden erreicht bzw. überschritten wurde. Ein weiterer Aspekt ist, dass komplexe Softwaresysteme heute von einem einzelnen Entwickler innerhalb eines Menschenlebens gar nicht mehr fertiggestellt werden können – einfach weil die Programmierarbeit zu umfangreich ist. Aber wo mehrere Menschen zusammen an einer Sache arbeiten, muss sichergestellt sein, dass jeder genau weiß, was er wie zu tun hat, damit die Ergebnisse am Ende zusammenpassen. Handlungsauftrag Recherchieren Sie im Internet eine Definition für den Begriff „Projekt“. Prüfen Sie anhand der in Ihrer Definition aufgeführten Projektmerkmale, ob es sich bei dem in der Einstiegssituation geschilderten Vorhaben um ein Projekt handelt. Damit dies möglichst reibungslos funktioniert, wird ein Softwareentwicklungsprozess in mehrere Phasen unterteilt: sehr grob in eine Planungs- und eine Entwicklungsphase. Die Planer recherchieren vor Ort, sprechen mit Angestellten des Kunden, analysieren Arbeitsabläufe und formulieren daraus Anforderungen an die Software, erstellen ein Pflichtenheft und letztendlich ein Modell des Programms. Auf Grundlage dieses Modells programmieren die Entwickler anschließend die einzelnen Komponenten. Hierbei brauchen Planer und Entwick- 110 © HERDT-Verlag Objektorientierte Analyse und Design ler sich nicht einmal zu kennen. Das funktioniert so gut, dass für die kontinenteübergreifende Softwareentwicklung ein eigener Begriff entstanden ist: Offshore Development. Europäische Softwareunternehmen analysieren und modellieren Projekte für europäische Kunden und lassen diese dann z. B. in Indien kostengünstig programmieren. Die in der Modellierungs­ phase eingesetzten Software-Architekten brauchen für die Planung detaillierte und fundierte Kenntnisse der Analyse- und Modellierungstechniken sowie ein zumindest rudimentäres Verständnis der eingesetzten Programmiertechniken. Bei den Programmierern ist es umgekehrt: Sie interessiert nicht, wie ein Modell zustande gekommen ist, sondern lediglich, wie es konkret umzusetzen ist. Merke Am Anfang eines komplexen Softwareentwicklungsprozesses steht die Analyse der zu bewerkstelligenden Aufgaben und die sich daran anschließende Entwicklung eines Modells. Handlungsauftrag Recherchieren Sie im Internet in der Praxis eingesetzte Phasenmodelle der Software­ entwicklung. Diskutieren Sie, welches Phasenmodell in der Einstiegssituation sinn­ vollerweise eingesetzt werden kann. 4.1.2 Maschinen- und Hochsprache unterscheiden Bevor die Analyse und das Design des Projektes eingehender betrachtet werden, stehen ­zunächst grundsätzliche Gedanken zum Thema Computer und Software an. Am Ende eines jeden Softwareentwicklungsprozesses steht ein fertiges Programm, das von einem Mikroprozessor (CPU) ausgeführt wird. Inzwischen gibt es Tausende verschiedener ­Prozessoren, die aber alle eines gemeinsam haben: Sie verstehen die in Programmen enthaltenen Befehle nur in der sogenannten Maschinensprache. Dabei spricht jeder ­Prozessortyp seinen eigenen „Dialekt“. Ein Programm in Maschinensprache, das auf Prozessor A läuft, ­verweigert auf jedem anderen Prozessortyp den Dienst. Der am weitesten verbreitete Dialekt ist die ­32-Bit-x86-Architektur des Unternehmens lntelTM. In so gut wie jedem PC steckt ein ­Prozessor, der x86-Maschinen­programme ausführen kann. Programmieren in Maschinensprache heißt, „die Bits einzeln durch den Computer zu schieben“. Das bedeutet, dass schon für kleinere Aufgaben der Programmcode sehr umfangreich und undurchsichtig wird. Daher entstanden bereits sehr früh sogenannte Hochsprachen. Hochsprachen sind Programmiersprachen, deren Code man fast wie einen richtigen Text lesen kann. Eine noch sehr stark an der ­Maschinensprache ­orientierte Sprache ist Assembler. Aber auch wenn es sich bei Assembler nicht um einen ­reinen Maschinencode handelt, ist der Code für Außenstehende kaum zu lesen: org 100h mov ax, cs mov ds, ax mov ah, 09h mov dx, out int 21h mov ax, 4C00h int 21h out: db ”Hallo Welt!” db ”$” © HERDT-Verlag 111 4 Objektorientierte Modellierung und Programmierung Dieses kleine Programm tut nichts anderes, als „Hallo Welt!“ am Bildschirm auszugeben. In der frühen Hochsprache BASIC besteht dieses Programm dagegen aus nur einer einzigen Zeile: 10 PRINT ”Hallo Welt!” Ein Computerprozessor kann ein in einer Hochsprache geschriebenes Programm nicht unmittelbar verstehen. Die Anweisungen müssen deshalb erst in Maschinensprache übersetzt ­werden, bevor der Prozessor sie ausführen kann. Dies kann grundsätzlich auf zwei Arten erfolgen: 1. Die Übersetzung erfolgt erst, während das Programm abläuft, und findet bei jedem ­Programmstart erneut statt. 2. Die Übersetzung findet vollständig vor dem ersten Ausführen des Programms statt. Code in Hochsprache Code in Hochsprache Code wird übersetzt und ausgeführt Programmstart Kompilierung Programmstart Maschinencode wird ausgeführt Bei einer Compilersprache wird vor dem ersten Ausführen eines Programms der komplette Code der Hochsprache in Maschinencode übersetzt. Diesen Vorgang nennt man Kompilierung und den„Übersetzer“ den Compiler. Bei der Übersetzung eines zeitgleich ablaufenden Programms spricht man davon, dass die Programmiersprache interpretiert wird. Die betroffenen Sprachen heißen Interpretersprachen. Bei einer interpretierten Hochsprache wird jedes Mal, wenn das Programm ausgeführt wird, vom Interpreter ein Maschinencode erzeugt, den der Prozessor dann direkt ausführt. Dabei wird nicht gleich der komplette Programmcode übersetzt, sondern immer nur der Befehl, der als nächster ausgeführt wird. Inzwischen haben sich andere Verfahren etabliert, die zwischen den beiden grundlegenden Varianten anzusiedeln sind. Interpreter Compiler BASIC C Perl C++ Python Pascal / Delphi PHP Fortran JavaScript Modula2 Wikipedia listet inzwischen über 300 Hoch­ sprachen auf. Die tatsächliche Anzahl dürfte weit höher liegen. Dabei haben sich vier grundsätzlich ­verschiedene Ansätze entwickelt, die man als Programmier­paradigmen bezeichnet: die imperativ prozedurale, die logische und die funktionale, die objektorientierte Programmierung. Jede Programmiersprache folgt zumindest einem dieser Paradigmen. Im Prinzip kann man in jeder Sprache, egal welchem Paradigma sie folgt, dieselben Probleme lösen, allerdings unterschiedlich effizient. Wofür man in der einen Sprache bloß wenige Zeilen Code braucht, sind in einer anderen seitenlange, kaum zu durchschauende Befehlsabfolgen nötig. 112 © HERDT-Verlag Objektorientierte Analyse und Design Die Programmiersprache Java Seit 1991 entwickelt das Unternehmen Firma Sun Microsystems eine plattformunabhängige und objekt­orientierte Hochsprache mit dem anfänglichen Namen Oak. ­Plattformunabhängig bedeutet, dass ein einmal geschriebenes Programm im Prinzip auf vielen unterschiedlichen Computer­systemen lauffähig ist. Für die rasante Verbreitung der 1994 in Java (inspiriert von einer Kaffeesorte und nicht zu verwechseln mit JavaScript) umbenannten Hochsprache hat letztlich die sehr rasche Ausbreitung des World Wide Web gesorgt. JVM für Linux Code in Hochsprache wird kompiliert Bytecode JVM für Windows JVM für Mac OS X Der 1994 entwickelte Browser WebRunner war der erste, der kleine Java-Programme, sogenannte Applets, aus dem WWW laden und ausführen konnte. Wenig später beherrschten auch die Konkurrenten Netscape und Internet Explorer diese Technik. Grund für die zügige Verbreitung ist die Art und Weise, in der Sun das Problem der Plattformunabhängigkeit gelöst hatte. Um zu verhindern, dass ein Java-Programm für jede Prozessor- bzw. Betriebs­ system-Architektur neu kompiliert werden muss, hat Sun Java als Mischung aus Compilerund Interpretersprache entworfen: Wird ein Java-Programm kompiliert, entsteht erst eine Vorstufe zum Maschinencode, der sogenannte Bytecode. Merke Egal auf welcher Plattform man ein Java-Programm kompiliert, der entstehende ­Bytecode ist immer identisch und kann dann ohne weitere Änderungen auf anderen Plattformen verwendet werden. Zum Ausführen des Bytecodes kommt dann ein plattformabhängiger Interpreter zum ­Einsatz, den man Java Virtual Machine (JVM) nennt. Echte JVMs gibt es unter anderem für die Plattformen Linux, Solaris, Windows und Mac OS X. Sun entwickelt seit Längerem zusätzlich abgespeckte JVMs mit einem verringerten Funktionsumfang und geringeren Hardware­ anforderungen, sodass Java auch auf Geräten wie Handys, PDAs, Fernsehgeräten oder sogar Waschmaschinen lauffähig ist. Java teilt sich seit geraumer Zeit mit C die ersten beiden Plätze des „TIOBE Programming Community Index“1. Suns Programmiersprache wird also so schnell nicht an Bedeutung ­verlieren. 1 http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html, 11.12.2012 © HERDT-Verlag 113 4 Objektorientierte Modellierung und Programmierung 4.1.3 Objektorientiert vorgehen In den 80er-Jahren begannen Wissenschaftler, Probleme bereits in der Planungsphase mit objektorientierten Methoden anzugehen. Das hieraus entwickelte Paradigma der objektorientierten Programmierung hat sich so weit durchgesetzt, dass heute im Unternehmensbereich fast ausschließlich objektorientiert entwickelt bzw. programmiert wird. Die Vorgehensweise lässt sich dabei grob in drei Schritte unterteilen: Kundenauftrag OOA OOD OOP objektorientierte Analyse objektorientiertes Design objektorientierte Programmierung Die objektorientierte Analyse Während der ersten Phase, der objektorientierten Analyse, muss so viel wie möglich über das zu realisierende Projekt in Erfahrung gebracht werden. Dies geschieht meist direkt vor Ort beim Kunden. Der Ablauf ist grundsätzlich folgender: 1. Der Kunde muss zunächst detailliert darlegen, was die in Auftrag gegebene Software leisten soll. 2. Danach wird untersucht, welche Geschäftsprozesse wie und in welchem Umfang betroffen sind. 3. Anschließend betrachtet man die Situation aus der objektorientierten Sicht – man reduziert die Realität objektorientiert, d. h., im Unternehmen werden die Objekte, Klassen und deren Eigenschaften identifiziert. Im nächsten Schritt untersucht man die Beziehungen zwischen den Objekten bzw. Klassen. Das kann noch auf dem Papier geschehen. Es gibt keine vorgeschriebene Norm, wie diese Modellbildung zu erfolgen hat, es ist nur wichtig, dass der Kunde diesen Vorgang versteht und ihn nachvollziehen kann. Das objektorientierte Design Im nächsten Schritt, dem objektorientierten Design, wird, resultierend aus den Überlegungen im Rahmen der OOA, das konkrete Modell erstellt. Die Modellbildung ist immer eine Vereinfachung der Realität, „damit man das System verstehen kann, bevor man es gebaut hat“2. Hierbei hat sich in den letzten Jahren die sogenannte Unified Modeling Language, kurz UML, etabliert. Die UML legt für die Modellierung wichtige Begriffe fest und schreibt dabei bestimmte grafische Notationen vor. Merke Die UML stellt eine Zeichensprache zur Modellierung konkreter Abläufe mit ­Klassen und Objekten und deren Beziehungen dar. Sie enthält keine Methode, in der eine Handlungsweise zur Erstellung von Modellen definiert ist. Das Grundprinzip besteht in der Erstellung von Diagrammen, die den zu modellierenden Prozess aus unterschiedlichen Sichtweisen beleuchten. Grundsätzlich könnte auch das OOD noch mit Stift und Papier erledigt werden, allerdings ist die UML so weit standardisiert, dass es zahllose Entwicklungstools gibt, die bereits beim Erstellen des Modells automatisch Pro2 Frei nach James Rumbaugh in “The Unified Modeling Language User Guide“ (Addison-Wesley Object Technology Series), 1998. 114 © HERDT-Verlag Instrumente für die Strukturierung betrieblicher Aufgabenstellungen grammcode für verschiedene Hochsprachen generieren. Das beim OOD entstehende Modell kann ebenfalls von allen Beteiligten verstanden werden: Der Kunde kann z. B. Schwachstellen oder Auslassungen entdecken, der Programmierer hat eine verbindliche Vorlage, auf die er sich später beziehen kann. Die objektorientierte Programmierung In einem letzten Schritt entsteht aus dem Modell das Programm. Dabei spricht man von der Implementierung des Modells. Welche Hochsprache dabei zum Einsatz kommt, ist von nachrangiger Bedeutung. Zwar gibt es einige UML-Elemente, die nicht in jeder Hochsprache zur Verfügung stehen. Da man die verwendete Hochsprache aber bereits im Vorfeld festlegt, ist dieses Problem zu vernachlässigen. Die meisten Modellierungstools sind bereits an eine bestimmte Hochsprache gebunden und lassen es während des OOD erst gar nicht zu, dass Sachverhalte modelliert werden, die später nicht programmiert werden können. Ein ­derart detailliertes Modell ermöglicht es, dass mehrere Programmierer weitgehend unabhängig voneinander an einem Projekt arbeiten – solange sie sich an die Vorgaben halten, sollte der Code anschließend zusammenpassen. Aufgaben 1 Recherchieren Sie verbreitete Interpreter- und Compilersprachen. Welche Sprachen ­kommen in welchen Bereichen zum Einsatz? 2 Finden Sie heraus, ob Ihr Handy Java-Programme, sogenannte MIDlets, ausführen kann. Wo kommt Java noch zum Einsatz? 4.2 Instrumente für die Strukturierung betrieblicher Aufgabenstellungen 4.2.1 Die Modellierungssprache UML kennenlernen Die Unified Modeling Language (UML) ist eine „grafische Sprache“ zur Modellierung, Visualisierung und Dokumentation komplexer Softwaresysteme. Sie wird seit Beginn der 90er-Jahre von der Object Management Group (OMG), einem Konsortium aus verschiedenen Unternehmen des IT-Bereichs, entwickelt. Die Sprache wird fortlaufend weiterentwickelt. Diesem Buch liegt die UML2 zugrunde. Die UML vereint mehrere unterschiedliche Modellierungskonzepte in Form unterschiedlicher Diagrammtypen und baut dabei konsequent auf den Prinzipien der Objektorientierung auf. UML-Modelle können in sämtlichen Phasen des Softwareentwicklungsprozesses eingesetzt werden. Ein UML-Modell besteht aus mehreren Diagrammen. Jedes Diagramm stellt eine ­spezielle Sicht auf das betrachtete Softwaresystem dar. Die einzelnen Diagramme stellen meist nur ­einen Teil der im gesamten Modell enthaltenen Informationen dar. Einzelne Elemente eines Modells können im Modell auch mehrfach, also in unterschiedlichen Diagrammen vorkommen. Die verschiedenen Diagrammtypen der UML lassen sich in die Kategorien Struktur- und Verhaltensdiagramme sowie Interaktionsdiagramme unterteilen. Die nachfolgende Übersicht in Anlehnung an ein Klassendiagramm zeigt sämtliche UML-Diagrammtypen. © HERDT-Verlag 115 4 ObjektorientierteModellierungundProgrammierung Die hellblau hinterlegten Diagrammtypen werden im Verlaufe dieses Buches in Grundzügen erläutert. Im Folgeband wird darüber hinaus auch auf das Sequenzdiagramm eingegangen. Tipp DiaPortable_ 0.97.2.paf.exe Im Internet finden Sie eine Vielzahl kostenloser Tools zur Erstellung von UML-Diagrammen. Die in diesem Kapitel dargestellten UML-Diagramme wurden z. B. mit dem Freeware-Tool Dia erstellt. 4.2.2 Ein Anwendungsfalldiagramm entwickeln Herr Rudnik, der Leiter der Informatikabteilung der remoTec GmbH, hat sich mit der SoftSolution GmbH aus Lüdinghausen in Verbindung gesetzt. Das Unternehmen hat sich auf die individuelle Entwicklung von Unternehmenssoftware für mittelständische Unternehmen spezialisiert und hat sehr gute Referenzen in diesem Bereich. Die Systemarchitektin der SoftSolution GmbH, Birte Nederkorn, möchte sich zunächst einmal in einem gemeinsamen Gespräch mit den Sachbearbeitern der remoTec GmbH einen Überblick über die benötigten Grundfunktionen der zu entwickelnden Buchhaltungssoftware verschaffen. Vorab wird vereinbart, dass das Programm zunächst nur die finanzbuchhalterische Buchung der Belege ermöglichen soll, weitere Funktionen sollen erst später integriert werden. Das Anwendungsfalldiagramm gehört zur Gruppe der UML-Diagramme. Es stellt die Benutzer und die groben Funktionen eines Softwaresystems sowie deren Beziehungen zueinander dar. Ziel eines Anwendungsfalldiagramms ist es, möglichst einfach zu zeigen, was mit dem zu entwickelnden Softwaresystem gemacht werden kann, welche Anwendungsfälle es also gibt. 116 System x Anwendungsfall 1 Akteur 1 Anwendungsfall 2 Anwendungsfall 3 Akteur 2 © HERDT-Verlag AllgemeineGrundlagender Java-Programmierung 4.5.3 Das Prinzip der Sichtbarkeit und Kapselung beachten Um Objekte vor unerlaubten Zugriffen von außen zu schützen, verwendet man in objektorientierten Programmen das Prinzip der Kapselung. Bei dieser Datenkapselung werden die Attributwerte von Objekten nach außen hin verborgen. Der Zugriff auf die Objekte bzw. deren Attributwerte erfolgt ausschließlich über die dazu freigegebenen Methoden der entsprechenden Klasse. Diese Kapselung lässt jedes Objekt wie eine Blackbox erscheinen. Das Innere dieser Box ist vor Blicken und direkten Eingriffen von außen geschützt; es gibt jedoch Steuerelemente, die dem Anwender die Möglichkeit geben, die Box zu verwenden. Dieses Blackbox-Prinzip kann man gut anhand eines Fernsehgeräts veranschaulichen: Man steuert das Gerät über eine Fernbedienung anhand vorgegebener Funktionen, ohne jedoch einen Einblick in die internen Abläufe und die Eigenschaften des Geräts zu haben. Beispiel: Kapselung der Attributwerte eines Aktivkontos Gegeben sei ein Objekt der Klasse Aktivkonto. Am Jahresanfang wird der Anfangsbestand mit dem Ergebnis der Inventur abgestimmt und gegebenenfalls korrigiert. Da gemäß dem Prinzip der Kapselung nicht direkt auf die Attributwerte zugegriffen werden kann, müssen dazu die Methoden der Klasse verwendet werden. Mithilfe der Methode getAnfangsbestand() kann der Anfangsbestand ausgelesen und mit der Methode setAnfangsbestand()verändert werden. Das Objekt kapselt seine Attributwerte durch seine Methoden. Die folgende Abbildung veranschaulicht diese „Datenkapsel“. getKontoNr() getKontoBezeichnung() setSummeHabenbuchungen() getSummeHabenbuchungen() setSummeSollbuchungen() kontoNr: 2010 kontoBezeichnung: Vorprodukte anfangsbestand: 5.000,00 summeSollbuchungen: 0,00 summeHabenbuchungen: 0,00 getSummeSollbuchungen() © HERDT-Verlag setKontoNr() setKontoBezeichnung() getAnfangsbestand() setAnfangsbestand() 181 4 Objektorientierte Modellierung und Programmierung Die konsequente Umsetzung dieses Prinzips im Java-Quellcode erkennen Sie im folgenden Ausschnitt der Klasse Aktivkonto.java. public class Aktivkonto { private private private private private Die Attribute ­wurden mit dem Zugriffs­ modifizierer private versehen. Dadurch können sie nur innerhalb dieser Klasse direkt verändert werden. int kontoNr; String kontoBezeichnung; double anfangsbestand; double summeSollbuchungen; double summeHabenbuchungen; (…) public double getAnfangsbestand() { return anfangsbestand; } Von außen kann auf die Attribute nur über die Getter und Setter zugegriffen werden, da diese public sind. public void setAnfangsbestand(double anfangsbestand) { this.anfangsbestand = anfangsbestand; } } (…) Merke Für Attribute einer Klasse sollte grundsätzlich der Zugriffsmodifizierer private, für die get- und set-Methoden public gewählt werden. Um die Funktionsweise dieses Prinzips innerhalb eines Java-Projekts noch besser verstehen zu können, muss noch eine zentrale Frage geklärt werden: Was heißt in diesem Zusammenhang eigentlich „Zugriff von außen“ bzw. „Zugriff von innen“? Hierbei handelt es sich um eine klassenbezogene Sichtweise. Methoden können stets auf die in ihrer eigenen Klasse ­deklarierten Attribute und Variablen zugreifen, um deren Werte z. B. für Berechnungen zu verwenden. Dies ist ein Zugriff von innen. Ein konkretes Beispiel dafür ist die Methode berechneSaldo() in der Klasse Aktivkonto. java des remoTec-Projekts, die u. a. auf das Attribut summeHabenbuchungen zugreift. Dieses ist zwar durch den Zugriffsmodifizierer private nach außen geschützt, der Zugriff aus einer Methode der eigenen Klasse ist jedoch möglich. Im Gegensatz dazu kann von der Klasse StartGUI.java aus nicht direkt auf die ­Attribute ­ ines Objekts zugegriffen werden. Dies wäre ein Zugriff von außen. Ein solcher direkter e ­Zugriffsversuch, z. B. auf den Wert des Attributs kontoNr, führt zu einer Fehlermeldung. Die Fehlermeldung besagt, dass der Zugriff (engl. access) auf das Attribut kontoNr in der Klasse Aktivkonto private und somit an dieser Stelle nicht möglich ist. Verwendet man hier jedoch die dafür vorgesehene set-Methode, erscheint keine Fehlermeldung. 182 © HERDT-Verlag Allgemeine Grundlagen der ­ Java-Programmierung Die folgende Tabelle veranschaulicht, aus welcher Klasse bei welchem Z ­ ugriffsmodifizierer auf ein Attribut oder auf eine Methode zugegriffen private werden kann. Da es in Java noch weitere public ­Zugriffsmodifizierer gibt, wird diese Tabelle an späterer Stelle noch erweitert. Eigene Klasse Fremde Klasse Zugriff kein Zugriff Zugriff Zugriff Handlungsauftrag Stellen Sie den obigen Fehler in Ihrem remoTec-Projekt nach. Versuchen Sie also einen direkten Zugriff aus der Klasse StartGUI.java auf einen Attributwert eines ­Aktiv­kontos. Was müssten Sie in der Klasse Aktivkonto.java ändern, damit diese Fehlermeldung verschwindet? Erklären Sie, warum diese kleine Änderung dem Prinzip der Kapselung widerspricht. Das Prinzip der Kapselung im Klassendiagramm darstellen Wie zuvor bei den Datentypen bietet die UML auch für die Zugriffsmodifizierer von ­Attributen und Methoden eine Möglichkeit für deren Darstellung in Klassendiagrammen. Dazu wird vor den Attributen bzw. Methoden jeweils ein Minuszeichen für private oder ein Pluszeichen für p ­ ublic gesetzt. Auch diese Ergänzung soll wiederum anhand des aktualisierten Klassendiagramms der Klasse Aktivkonto.java veranschaulicht werden. Aktivkonto - kontoNr: int - kontoBezeichnung: String - anfangsbestand: double - summeSollbuchungen: double - summeHabenbuchungen: double + Aktivkonto() + Aktivkonto(kontoNr:int,kontoBezeichnung:String,anfangsbestand:double) + Aktivkonto(kontoNr:int,kontoBezeichnung:String) + getKontoNr(): int + setKontoNr(kontoNr:int): void + getKontoBezeichnung(): String + setKontoBezeichnung(kontoBezeichnung:String): void + getAnfangsbestand(): double + setAnfangsbestand(anfangsbestand:double): void + getSummeSollbuchungen(): double + setSummeSollbuchungen(summeSollbuchungen:double): void + getSummeHabenbuchungen(): double + setSummeHabenbuchungen(summeHabenbuchungen:double): void + berechneKontosumme(): double + berechneSaldo(): double + toString(): String © HERDT-Verlag 183
