Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Sprachbeschreibung
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Mathematisches
6 Eigene Klassen schreiben
7 Angewandte Objektorientierung
8 Exceptions
9 Die Funktionsbibliothek
10 Threads und nebenläufige Programmierung
11 Raum und Zeit
12 Datenstrukturen und Algorithmen
13 Dateien und Datenströme
14 Die eXtensible Markup Language (XML)
15 Grafische Oberflächen mit Swing
16 Grafikprogrammierung
17 Netzwerkprogrammierung
18 Verteilte Programmierung mit RMI und Web-Services
19 JavaServer Pages und Servlets
20 Applets
21 Midlets und die Java ME
22 Datenbankmanagement mit JDBC
23 Reflection und Annotationen
24 Logging und Monitoring
25 Sicherheitskonzepte
26 Java Native Interface (JNI)
27 Dienstprogramme für die Java-Umgebung
A Die Begleit-DVD
Stichwort
Download: - ZIP, ca. 12,5 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Computing / <openbook> /Java-Insel | vor >>
Java ist auch eine Insel von Christian Ullenboom Programmieren mit der Java Standard Edition Version 6
Java ist auch eine Insel 7., aktualisierte Auflage geb., mit DVD (November 2007) 1.492 S., 49,90 Euro Galileo Computing ISBN 978-3-8362-1146-8 |
| 3 Klassen und Objekte
|  | 3.1 Objektorientierte Programmierung
|  |  | 3.1.1 Warum überhaupt OOP?
|  |  | 3.1.2 Wiederverwertbarkeit
|  | 3.2 Eigenschaften einer Klasse
|  |  | 3.2.1 Die Klasse Point
|  | 3.3 Die UML (Unified Modeling Language)
|  |  | 3.3.1 Hintergrund und Geschichte zur UML
|  |  | 3.3.2 Wichtige Diagrammtypen der UML
|  | 3.4 Neue Objekte erzeugen
|  |  | 3.4.1 Anlegen eines Exemplars einer Klasse mit dem new-Operator
|  |  | 3.4.2 Deklarieren von Referenzvariablen
|  |  | 3.4.3 Zugriff auf Variablen und Methoden mit dem ».«
|  |  | 3.4.4 Konstruktoren nutzen
|  |  | 3.4.5 Die API-Dokumentation
|  | 3.5 Import und Pakete
|  | 3.6 Mit Referenzen arbeiten
|  |  | 3.6.1 Die null-Referenz
|  |  | 3.6.2 Zuweisungen bei Referenzen
|  |  | 3.6.3 Funktionen mit nicht-primitiven Parametern
|  | 3.7 Identität und Gleichheit
|  |  | 3.7.1 Identität von Objekten
|  |  | 3.7.2 Gleichheit und die Methode equals()
|  | 3.8 Wrapper-Klassen und Autoboxing
|  |  | 3.8.1 Die Basisklasse Number für numerische Wrapper-Objekte
|  |  | 3.8.2 Die Klasse Integer
|  |  | 3.8.3 Unterschiedliche Ausgabeformate
|  |  | 3.8.4 Autoboxing: Boxing und Unboxing
|  |  | 3.8.5 Die Boolean-Klasse
|  |  | 3.8.6 Die Klassen Double und Float für Fließkommazahlen
|  | 3.9 Arrays
|  |  | 3.9.1 Deklaration von Arrays
|  |  | 3.9.2 Arrays mit Inhalt
|  |  | 3.9.3 Die Länge eines Arrays über das Attribut length
|  |  | 3.9.4 Zugriff auf die Elemente über den Index
|  |  | 3.9.5 Array-Objekte erzeugen
|  |  | 3.9.6 Fehler bei Arrays
|  |  | 3.9.7 Vorinitialisierte Arrays
|  |  | 3.9.8 Die erweiterte for-Schleife
|  |  | 3.9.9 Arrays mit nicht-primitiven Elementen
|  |  | 3.9.10 Mehrdimensionale Arrays
|  |  | 3.9.11 Die Wahrheit über die Array-Initialisierung
|  |  | 3.9.12 Mehrere Rückgabewerte
|  |  | 3.9.13 Methode mit variabler Argumentanzahl (Vararg)
|  |  | 3.9.14 Klonen kann sich lohnen – Arrays vermehren
|  |  | 3.9.15 Feldinhalte kopieren
|  |  | 3.9.16 Die Klasse Arrays zum Vergleichen, Füllen und Suchen
|  | 3.10 Der Einstiegspunkt für das Laufzeitsystem main()
|  |  | 3.10.1 Kommandozeilen-Argumente verarbeiten
|  |  | 3.10.2 Der Rückgabewert von main() und System.exit()
|  | 3.11 Eigene Pakete schnüren
|  |  | 3.11.1 Die package-Anweisung
|  |  | 3.11.2 Importieren von Klassen mit import
|  |  | 3.11.3 Hierarchische Strukturen und das Default-Package
|  |  | 3.11.4 Paketnamen
|  |  | 3.11.5 Klassen mit gleichen Namen in unterschiedlichen Paketen
|  |  | 3.11.6 Statisches Import
|  |  | 3.11.7 Eine Verzeichnisstruktur für eigene Projekte
|  | 3.12 Zum Weiterlesen
## 3.3 Die UML (Unified Modeling Language) Für die Darstellung einer Klasse lässt sich Programmcode verwenden, also eine Textform, oder aber eine grafische Notation. Eine dieser grafischen Beschreibungsformen ist die UML. Grafische Abbildungen sind für Menschen deutlich besser zu verstehen und erhöhen die Übersicht. Im ersten Abschnitt des UML-Diagramms lassen sich die Attribute ablesen, im zweiten die Methoden. Das + vor den Eigenschaften zeigt an, dass sie öffentlich sind und jeder sie nutzen kann. Die Typenangabe ist gegenüber Java umgekehrt: Zuerst kommt der Name der Variable, dann der Typ beziehungsweise bei Methoden der Typ des Rückgabewerts. Hier klicken, um das Bild zu vergrößern Abbildung 3.1 Die Klasse java.awt.Point in der UML-Darstellung ### 3.3.1 Hintergrund und Geschichte zur UML Die UML ist mehr als eine Notation zur Darstellung von Klassen. Mit ihrer Hilfe lassen sich Analyse und Design im Softwareentwicklungsprozess beschreiben. Mittlerweile hat sich die UML jedoch zu einer allgemeinen Notation für andere Beschreibungen entwickelt, zum Beispiel für Datenbanken oder Workflow-Anwendungen. Vor der UML waren andere Darstellungsvarianten wie OMT oder Booch verbreitet. Diese waren eng mit einer Methode verbunden, die einen Entwicklungsprozess und ein Vorgehensmodell beschrieb. Methoden versuchen, eine Vorgehensweise beim Entwurf von Systemen zu beschreiben, etwa »erst Vererbung einsetzen und dann die Attribute finden« oder »erst die Attribute finden und dann mit Vererbung verfeinern«. Bekannte OO-Methoden sind etwa Shlaer/Mellor, Coad/Yourdon, Booch, OMT und OOSE/Objectory. Aus dem Wunsch heraus, OO-Methoden zusammenzufassen, entstand die UML – anfangs stand die Abkürzung noch für Unified Method. Die Urversion 0.8 war die erste Veröffentlichung im Jahre 1995. Die Initiatoren waren Jim Rumbaugh und Grady Booch. Später trat Ivar Jacobson dazu, und die drei »Amigos« erweiterten die UML, die in der Version 1.0 bei der Object Management Group (OMG) als Standardisierungsvorschlag eingereicht wurde. Die Amigos nannten die UML nun »Unified Modeling Language«, was deutlich macht, dass die UML keine Methode ist, sondern lediglich eine Modellierungssprache. Die Spezifikation erweitert sich ständig mit dem Aufkommen neuer Software-Techniken und so bildet die UML 2.0 Konzepte wie Model Driven Architecture (MDA) und Geschäftsprozessmodellierung (BPM) ab und unterstützt Echtzeitmodellierung (RT) durch spezielle Diagrammtypen. Eine aktuelle Version des Standards lässt sich unter http://tutego.com/go/uml beziehen. ### 3.3.2 Wichtige Diagrammtypen der UML UML definierte diverse Diagrammtypen, die unterschiedliche Sichten auf die Software beschreiben können. Für die einzelnen Phasen im Softwareentwurf sind jeweils andere Diagramme wichtig. Wir wollen kurz drei Diagramme und ihr Einsatzgebiet besprechen: #### Use Cases Die Use-Cases-Diagramme entstehen meist während der Anforderungsphase und beschreiben die Geschäftsprozesse, indem die Interaktion von Personen oder von bereits existierenden Programmen mit dem System dargestellt werden. Die handelnden Personen oder aktiven Systeme werden Aktoren genannt. Ein Use Case beschreibt dann eine Interaktion mit dem System. Dazu werden die Aktoren als Männchen dargestellt (wobei die Geschlechter nicht zu erkennen sind) und die einzelnen Anwendungsfälle (Use Cases) als Ellipsen. #### Klassendiagramme Für die statische Sicht auf einen Programmentwurf sind Klassendiagramme einer der wichtigsten Diagrammtypen. Sie sind besonders interessant, da Hilfsprogramme aus diesen Diagrammen automatisch Teile des Quellcodes erzeugen können. Die Diagramme stellen zum einen die Elemente der Klasse dar, zum anderen die Beziehungen der Klassen untereinander. Die Diagramme werden in diesem Buch häufiger eingesetzt. Klassen werden als Rechteck dargestellt, und die Beziehungen zwischen den Klassen werden durch Linien angedeutet. #### Sequenzdiagramm Das Sequenzdiagramm stellt das dynamische Verhalten von Objekten dar. So zeigt es an, in welcher Reihenfolge Methoden aufgerufen werden und wann neue Objekte erzeugt werden. Die einzelnen Objekte bekommen eine vertikale Lebenslinie und horizontale Linien zwischen den Lebenslinien der Objekte beschreiben die Operationen oder Objekterzeugungen. Das Diagramm liest sich somit von oben nach unten. ### Ihr Kommentar Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
Name |
E-Mail |
Ihr Kommentar |
<< zurück | <top> | vor >>

Copyright © Galileo Press 2008
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

[Galileo Computing]
Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de