Good Coding Practices Programmier

Good Coding Practices
Programmier-Richtlinien
Good Coding Practices
■ oder: wie restriktiv dürfen Konventionen sein?
■ Sie kennen die wichtigsten Regeln um "lesbare" Java
Programme zu schreiben
■ Sie wissen, wie man Variablen benennt
■ Sie wissen, wie man sinnvoll einrückt
■ Sie wissen, wieso Programme auch "Kunstwerke" sein können
School of Engineerig
Good Coding Practices
Programme sind
funktionale Produkte;
sie müssen funktionale
Qualitäten aufweisen.
2 von 70
Good Coding Practices
Programmieren ist eine
kreativ-künstlerische Tätigkeit.
Das Resultat muss gewissen
ästhetischen Kriterien genügen.
Correctness
Performance
Usability
Elegance
Readability
Maintainability
Visual Inspection
Verification
Understanding
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Mehr oder weniger strikte Führung
Grundregeln
Vorschriften
Zweck
Qualität
Integration
Team
Unterhalt
Fehlererkennung/elimination vor Debugger
Homogene Bauart
Schreiber/Leser-Lust
Anpassung anstatt Re-Engineering
Programm = Kunstwerk,
■ das seine Aufgabe korrekt und elegant löst
■ das zu lesen und zu verstehen Spass macht
3 von 70
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
4 von 70
Programmier Richtlinien
Vorschrift
dringende Empfehlung
allgemeine Empfehlung
must
should
can
... can dürfen missachtet werden, falls dadurch die Lesbarkeit
und Verständlichkeit verbessert werden.
Programmier Richtlinien
Konvention
Kultur
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
5 von 70
Namengebung
School of Engineerig
6 von 70
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
… Namengebung
Typen,Klassen
FileDescriptorTable
Gross-Klein-
Sinn
Konstanten
BLUE
SMTP_PORT
Bezeichnungen müssen möglichst klar zutreffend
den Sinn der Sache ausstrahlen
Underscore!
Kürze
a,b,c,
i,j,k,
...
x,y,z
Nur in sehr kleinem lokalem Kontext zu verwenden.
Sonst immer sinngebende Worte nehmen.
anker
filePrefix
abschickenKnopf
fliesstextElement
Klein-Gross-
Methoden
concatenateThisAndThat
verifyProperty
isOrdered
Verben, klein
infinitiv,imperativ
Properties
setValue
getValue
isValue //boolean
Variablen
...
Substantive
position, item, count, size, color ...
Sprache
Englisch (international verständlich, kurz, prägnant)
andernfalls: Konsequenz; keine Mischung.
Rechtschreibung Sorgfalt lohnt sich.
set-/getbei Boolean auch "is"
Verzicht auch auf kryptische Eigenkonstruktionen
Akronyme
Trotzdem nicht nur Grossbuchstaben verwenden:
HttpRequest, ValidRsaSignature
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
7 von 70
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
8 von 70
… Namengebung
Organisation der Quelldatei
Mit Typenbezeichnung spezifizieren
GUI-Elemente
Zeilenlänge
< 80 Zeichen (Seitenbreite bei sinnvoller Schriftgrösse)
Panel centralPanel; Button submitButton;
Abkürzungen
Tabulatoren etc.
Vermeiden. Machen nur Probleme bei Editoren, Druckern,
Debuggern
Zeilenumbruch
Darstellung muss logische Einheit klar bewahren
„Bekannte“ Bezeichnungen beibehalten
cpu, md5, gui, raid
Komplementäres
Konsequenter Einsatz
get/set, add/remove, create/destroy, start/stop, insert/delete,
increment/decrement, old/new, begin/end, first/last, up/down,
min/max, next/previous, old/new, open/close, show/hide
Negation
Umbruch nach Komma, nach Semikolon, nach Operator
Erscheinungsbild
Vermeiden
- Blocklänge (Anzahl Zeilen)
- Blockbreite (Anzahl Zeichen pro Zeile)
- Leerzeilen, Kommentarzeilen oder -blöcken
isNotConnected, notYetComplete
Spezialzeichen
School of Engineerig
Umlaute und sonstige Symbole: vermeiden
9 von 70
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Zu einzelnen Elementen
Variablen
Flattersatz mit Blockstruktur:
Geschickte Wahl von
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Schlaufen
Sollten immer bei der Deklaration gerade auch initialisiert werden
(Ausnahme Instanzvariablen)
Steuerzeile Keine weiteren "Kunststücke" in der Steuerzeile!
for (initial; condition; step) { ... }
Dürfen nicht mehrdeutig sein (bsp. einmal als Schlaufenzähler,
etwas später für einen anderen Verwendungszweck)
Deklaration und Initialisierung der Variablen direkt im Kopf
Sollten im kleinstmöglichen Kontext (Scope und Lebensdauer)
angesiedelt werden
wenn nicht möglich unmittelbar vor der Schlaufe
for (int i = 0; condition; step) { ... }
Boolean Done = false;
while (!done) { ...
Klassen-Variablen sollten nicht „public“ sein
Zurückhaltung mit neuen Variablen; wenn ein Wert leicht aus anderen
berechnet werden kann, dann nicht einführen.
do {.} while (.)
Anstelle
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
11 von 70
School of Engineerig
eher zurückhaltend verwenden
for(;;) {...}
while(true) {...} bevorzugen
break, continue
School of Engineerig
10 von 70
in Schleifen nach Möglichkeit
vermeiden
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
12 von 70
Bedingte Anweisungen
Weitere Elemente
Boole-sche Ausdrücke
Zahlen (magic numbers) Sollten in Ausdrücken nicht vorkommen.
Ausnahmen: 0 und 1.
Sonst Initialisierte Konstanten verwenden.
Vermeidung der linearen Komplexität durch Aufteilung in mehrere
Anweisungen unter Zuhilfenahme von (lokalen) Hilfsvariablen
Fliesskommazahlen als solche erkennbar.
if (Bedingung) {
Normalfall
}
else {
Seltenerer Fall
}
0.7 =
Logisch sinnvolle Anordnung
Leerzeichen
if ((fileHandle = open(...)) != null) ...
Immer nach Komma, Semikolon.
Meist vor und nach Operatoren
Tabellarische Gliederung Für Deklarationen.
Anweisungen oder Funktionen mit Seiteneffekt nur für erfahrene
Programmierer
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
3 = 3.0
0.7
13 von 70
Layout – Gestaltung
Code-Blöcke mit Anweisungen
ähnlicher Struktur
School of Engineerig
14 von 70
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Konkrete Formen
Blöcke haben einen Kopf und einen Inhalt.
Der Inhalt wird eingerückt; die schliessende Klammer aber auf die gleiche
Höhe wie der Kopf gesetzt.
,
Klasse
Methode(Parameterliste)
Schlaufensteuerung
Bedingung
andere Identifikation
Kopf
Sequenz
Einfach
Methode
if-ohne-else-Zweig
For- oder while-Schlaufe
switch/case-Konstruktion
if-mit-else-Zweig
if-else-if-Kaskade
Inhalt
Kopf
Kopf
Inhalt
Verschachtelung
}
Schwierig try-catch-Block
}
Einrückung = 2 oder 4 Blanks
Kopf
Inhalt
}
if () {
Inhalt
try {
Inhalt
else {
catch {
if
Inhalt
else if
Inhalt
else if
Inhalt
}
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
15 von 70
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
16 von 70
Leerzeilen
Kommentare
Block-Kommentar
Leerzeilen schaffen Struktur: nämlich Distanz.
Zeilen mit lediglich syntaktischer Funktion { } wirken wie Leerzeilen.
/*
*
*
Visuell stark.
Für Hintergrundinfo.
*/
Öffnende Klammer soll keine eigene Zeile
belegen. Ich setze sie hierhin.
Zeilen-Kommentar
Gliederung von Methoden und -Gruppen
// Method Group
previous block in sequence;
while (condition) {
do this;
and that;
} // while
next block;
School of Engineerig
Restzeilen-Kommentar
Schliessende Klammer
hat eigene Zeile,
allenfalls Identifikationskommentar.
hat gleiche Einrückung wie Kopf
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
17 von 70
… Kommentare
Javadoc-Kommentar
Statement1;
Staaaaaaaatement2;
Stmt3;
School of Engineerig
Keine Binsenwahrheiten!
Soll Code-Block nicht zu nahe kommen.
// explanation
// more explanation
// even more explanation
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Programmpakete
/**
*
Visuell stark.
Für Hintergrundinfo.
*/
■ Mittels dem javadoc Werkzeug kann aus Quelle eine
Programmdokumentation erstellt werden
■
sämtliche public Methoden, Typen und Parameter
■
spezielle Markierungen (@) für Parameter
■
sämtliche javadoc-Kommentare
■ Packages
■ Importieren von Klassen und Packages
■ Sichtbarkeitsregeln für Packages
■ Sprachelemente: package, import
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
19 von 70
18 von 70
Packages
Pakete = Subsysteme
■Normalerweise befindet sich jede Java-Klasse in einem eigenen File mit dem
gleichem Filenamen wie die Klasse
■Problem: Falls zwei Klassen denselben Namen haben, so sind sie nicht mehr
eindeutig identifizierbar
■Abhilfe: Der gesamte Namensraum (namespace) wird durch sogenannte
Packages aufgeteilt
■
■
■
die Bindung innerhalb der Subsysteme möglichst gross
(meist logisch zusammengehörende Teile)
die Kopplung zwischen den Subsystemen möglichst gering ist
Bildung von zusammengehörenden Einheiten die einzeln verstanden, gewartet und verteilt
werden können
• Beispiel
■Notation
■Beispiele:
■
■Grössere Systeme werden in Subsysteme (Pakete) unterteilt in denen:
■Zweck
Packages: Fasst eine Gruppe von Klassen (und eventuell Subpackages)
zusammen unter einem (möglichst eindeutigen) Namen
■
■Andere Sicht auf Packages:
Antriebssystem
java.applet : Alle Klassen im Zusammenhang mit Applets
java.awt : Die Klassen des Abstract-Windowing-Toolkit
Paketnamen
Bremssystem
■Vorteile:
Klassen werden eindeutig spezifizierbar durch Angabe des Package-Namens
Bremspedal
Bremskraftregler
Bremse
School of Engineerig
21 von 70
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Package Deklaration
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
22 von 70
Packages und File Struktur
■Die Package-Deklaration muss als erstes Anweisung in jedem File stehen:
package mypackage;
import java.applet.*;
School of Engineerig
Sensor
■ Die Punkte werden je nach Betriebssystem in / oder \ übersetzt
//package declaration
//import statements
■ Die Package Struktur wird 1:1 auf die File Struktur abgebildiet
■Klassen desselben Package werden
im gleichen Directory gespeichert
myProjekt
myProjekt
■Der Name des Verzeichnisses muss
gleich sein wie der des Package
src
src
myApplikation.java
myApplikation.java
mypackage
mypackage
Klasse1.java
Klasse1.java
School of Engineerig
■ Bsp: Klasse zhaw.zema.myPackage.Klasse1 muss ich im Verzeichniss
zhaw\zema\myPackage befinden.
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
classes
classes
myApplikation.class
myApplikation.class
mypackage
mypackage
Klasse1.class
Klasse1.class
23 von 70
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
24 von 70
Package-Namen
Klassenbibliotheken
■Beginnen mit Kleinbuchstaben (meist ganzer Packagename kleingeschrieben)
■Welche Klassen soll man zu Packages zusammenfassen?
■Sonst gelten die gleiche Regeln wie bei Klassennamen
■Es gibt keine Regeln über die Anzahl Klassen pro Package
■Package-Namen sollten internetweit eindeutig sein
■Klassen die einander häufig brauchen und logisch zusammengehören, sollten
im gleichen Package ablegt sein
Æ Vorschlag für internetweit eindeutige Package- Namen: URL verwenden
Eine Methode einer bestimmten Klasse wird folgendermassen eindeutig
spezifiziert:
■Klassenbibliothek Klassen, die häufig gebraucht werden, logisch
zusammengehören und einem gemeinsamen Zweck dienen werden häufig in
einem Package zusammengefasst.
firmenDomänenName.verzeichnis1.verzeichnis2...
...packageName.KlassenName.methodenName
■Beispiel:
■Beispiel: Java Platform Std. Ed. Packages (Auszug):
■
com.sybase.jdbc.SybDriver
■
ch.zhaw.meea.meinPackage.GenialeKlasse
java.applet java.awt java.awt.color java.awt.datatransfer
■Klassen ohne Package-Angabe gehören zu einem anonymen Package
(unnamed package)
Æ Dazu gehören alle "anonymen" Klassen im gleichen File und Directory
(so haben wir bis jetzt programmiert ->Praxis programmiert man NICHT so )
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
25 von 70
Beispiel: eigenes Package
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
26 von 70
■Generell muss jede Klasse, die verwendet wird, importiert werden
public class Klasse1 {
public void display(Graphics g){
g.drawString("Hallo von Klasse1", 40, 40);
}
}
--------------------------------------------import java.awt.*;
import java.applet.*;
import zhaw.zema.myPackage.*;
myProjekt
myProjekt
■Zur eindeutigen Spezifikation eines Packages muss der ganze Pfad des
Package angegeben werden:
■Beispiel: Wir möchten die Klassenmethode statMethode() der Klasse
mypackage.MyClass aufrufen
src
src
■
TestPackage.java
TestPackage.java
public class TestPackage extends Applet {
Klasse1 kvar = new Klasse1();
zema
zema
public void paint(Graphics g) {
kvar.display(g);
}
Der * gilt jeweils nur für eine Stufe
mypackage
mypackage
■Ausnahmen:
Klasse1.java
Klasse1.java
■
■
}
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
import mypackage.MyClass;
...
MyClass.statMethode();
■Falls alle Klassen eines Packages importiert werden sollen:
import mypackage.*;
■
zhaw.zema.myPackage.Klasse1();
mit import:
zhaw
zhaw
// alternative (ohne Import)
School of Engineerig
School of Engineerig
Importieren
package zhaw.zema.myPackage;
import java.awt.*;
// zhaw.zema.myPackage.Klasse1 kvar = new
java.awt.image java.beans java.io java.lang java.lang.ref java.lang.reflect
java.math java.net java.nio java.nio.channels java.nio.channels.spi
java.nio.charset java.nio.charset.spi java.rmi java.rmi.activation
java.rmi.dgc java.rmi.registry java.rmi.server java.security org.xml.sax
org.omg.CORBA
27 von 70
Klassen im anonymen Package
Klassen im selben Package
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
28 von 70
… Importieren
Sichtbarkeitsregeln
■Java definiert für Packages einen zusätzlichen Sichtbarkeitsbereich: package.
■ Package kann auch direkt (ohne Import) angegeben werden
■
nur in Ausnahmen (bei Namenskonflikten) verwenden
Dies ist die Standardsichtbarkeit in Java
■
void foo() {
java.awt.Button b = new java.awt.Button();
■
Klassen, Methoden, Variablen mit package-Sichtbarkeit sind in jeder Klasse innerhalb des
gleichen Packages sichtbar
Deklaration der package-Sichtbarkeit:
int x; //ohne Sichtbarkeitsmodifikator
■Die Packages im JDK beginnen mit
java (Standardklassen)
Basis-Package java.lang wird automatisch importiert (enthält die grundlegenden Klassen von Java)
■ javax (Standard-Erweiterungsklassen des JDK)
■
■
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
29 von 70
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
JAR Dateien
Manifest für Hauptklasse
■ Einfachstes Format zur Paketieren
■ Durch jar Werkzeug wird ein Standard-Default Manifest erzeugt
30 von 70
■ Die Klassen und ihre SHA1/MD5 Hashes können angegeben werden
META-INF
MANIFEST.INF
HelloWorld.class
Manifest-Version:
Manifest-Version:1.0
1.0
Name:
Name:java/math/BigDecimal.class
java/math/BigDecimal.class
SHA1-Digest:
TD1GZt8G11dXY2p4olSZPc5Rj64=
SHA1-Digest: TD1GZt8G11dXY2p4olSZPc5Rj64=
MD5-Digest:
MD5-Digest:z6z8xPj2AW/Q9AkRSPF0cg==
z6z8xPj2AW/Q9AkRSPF0cg==
...
...
Verzeichnis
VerzeichnisStruktur
Struktur
wird
wirdübernommen
übernommen
ein
META-INF/MANIFEST.MF
ein META-INF/MANIFEST.MF
wird
wirdgeneriert
generiert
images
■ die Haupt-Klasse oder das Java-Bean kann im Manifest angegeben werden
my.gif
Main-Class: classname
Main-Class: classname
■ Erstellt durch Kommandozeile
Name:
Name:classname
classname
Java-Bean:
Java-Bean:True
True
■ Erzeugung: Verändertes Manifest kann einbezogen werden
jar
jar cvf
cvf jar-file
jar-file input-file(s)
input-file(s)
jar
jar cmf
cmf manifest-addition
manifest-addition jar-file
jar-file input-file(s)
input-file(s)
■ Aufruf
■ Verwendung: z.B. zum Starten der Haupt-Klasse
java
java -jar
-jar jar-file
jar-file
java
java -cp
-cp my-jar.jar
my-jar.jar HelloWorld
HelloWorld
■ weiter Einträge unter
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
31 von 70
■ http://java.sun.com/developer/Books/javaprogramming/JAR/basics/manifest.html
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
32 von 70
JAR Dateien in JCreator
Zusammenfassung
■ In JCreator kann es mittels Configure->Options->Tools hinzu genommen werden
■ Pakete um Subsysteme zu bilden
■ Danach kann ein Verzeichnis eines Projekts in eine Jar Datei umgewandelt
werden: Tools-> Create Jar File
■ Importieren von anderen Subsystemen: import
■ Sichtbarkeit innerhalb Subsystemen: Package Scope
■ Jar Dateien um Klassen eines Pakets zu speichern
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
33 von 70
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
34 von 70
Einführung in den
Objektorientierten Entwurf (OOA/OOD)
Objektorientierte Modellierung und Design
■ Klasse und Objekte
■ UML
■ statische und dynamische Beziehungen
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
36 von 70
Die reale Welt und die Modellwelt
Design/Modellierung
■ Beispiel einer Top-Down Analyse
■ Definition: Ein Modell
■
■
■
ist eine Abstraktion irgendeines Gegenstandes oder Sachverhaltes
umfasst einen Teilaspekte des Beschreibungsgegenstandes
zielt auf ein besseres Verständnis des Beschreibungsgegenstandes
■ Modelle werden angewandt
■
■
zur Analyse und Darstellung existierender Strukturen
zur Beurteilung ingenieurtechnischer Produkte vor ihrer Erstellung
Systemgrenze
Motor
■ Beispiele von Modellen
Karosserie
■
Bremssystem
■
Fahrwerk
■
Physik: Atommodelle, Planetenbewegungen (Kepler vs. Einstein)
Theater und Film: Choreographien, Drehbücher
Softwaretechnik: Ablaufmodelle, Entwurfsmodelle
LeasingVertrag
School of Engineerig
37 von 70
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Vorgang der Modellbildung
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
38 von 70
Prinzipien des objektorientierten Designs
■ Ein System besteht aus einer Anzahl Objekten
Sensor
■ Ein Objekt hat ein definiertes Verhalten
Bremskraftregler
■
■
Bremspedal
■ Bestimmen der interessierenden Sichtweise
■
Bremse
■ Ein Objekt hat einen inneren Zustand
z.B. Fahrer der Fahrzeug bei hoher Geschwindigkeit sicher zum stehen bringen will
■
■ Bestimmen des zu modellierenden Funktion/Verhaltens
■
Verhalten setzt sich zusammen aus einer Menge genau definierter Operationen zur Erfüllung von
Einzelaufgaben
Eine solche Operation wird beim Empfang einer Meldung ausgeführt
■
Der Zustand des Objektes ist Privatsache
Das Resultat einer Operation hängt vom aktuellen Zustand des Objekts ab
z.B. Bremssystem mit Bremskraftregelung
■ Ein Objekt hat eine eindeutige Identität
■
■
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
39 von 70
Die Identität eines Objektes ist unabhängig von seinen anderen Eigenschaften
Es können verschieden Objekte mit gleichem Verhalten in einem System existieren
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
40 von 70
Vorteile der Objektorientierung
Risiken der Objektorientierung
■ Stabilität (des Entwurfs und des Laufzeitsystems)
■ Hoher Einführungsaufwand
■
■
durch Lokalitätsprinzip: Kombination von Daten und Operationen ermöglichen lokale Änderungen
durch Schnittstellendefinitionen: Entkopplung aufrufender Programmteile von der Realisierung der
aufgerufenen Programmteile
■
durch Bausteinprinzip: Systemkomponenten können aus Bibliothek entnommen und in anderem
Kontext wieder eingesetzt werden
■ Änderungsfreundlichkeit
■
■
41 von 70
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Elemente objektorientierter Modellierung
statischer Aspekt
dynamischer Aspekt
Klassendiagramme
Attribute
Operationen
■
■
Objektverwaltung und Schnittstellen erzeugen "Overhead"
Kompatibiltätsprobleme mit vorhandenen Systemen (z.B. DB)
schlechte Kombinierbarkeit von Klassenbibliotheken
Objekte
Interaktionsdiagramme
Assoziationen
Objekt_1
Objekt_2
Aufruf
Subsysteme
■
■
■
unübersichtliche Klassenhierarchien und Kontrollflüsse
übermässiger oder unangemessener Gebrauch von Vererbung
undokumentierte Klassenabhängigkeiten
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
42 von 70
Klassen und Objekte
UML = Unified Modeling Language
Klasse
Umschulung von traditionellen auf objektorientierten Sprachen
Umstellung von Prozessen und Werkzeugen
■ Risiken durch Klassenabhängigkeiten
durch Bausteinprinzip: Austausch und Ergänzung von Bausteinen
durch Abstraktionsebenen: Vererbung und Polymorphie ermöglichen das einfache Ableiten von
verschiedenen Varianten einer prinzipiellen Lösung
School of Engineerig
■
■ Mangelhafte Effizienz
■ Wiederverwendung
■
■
■ Definition Ein Objekt ist ein elementarer Bestandteil des betrachteten
Fachgebiets.
Ein Objekt wird erzeugt und behält eine unveränderlich Objektidentität bis zu
seiner Löschung.
■ Definition Eine Klasse ist eine Beschreibung gleichartiger Objekte. Jedes
Objekt gehört zu (ist Instanz von) genau einer Klasse.
■ Notation:
Generalisierung
Zustandsdiagramme
■ Beispiel
Start
Methode:
OOA & OOD
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
warte
Klasse
Bremskraftregler
43 von 70
School of Engineerig
Objekt : Klasse
br : Bremskraftregler
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
44 von 70
Beispiel einer Objektifizierung
Beispiel einer Klassifizierung
■ Objekte zeichnen sich aus durch
■ Da sich einige die Objekte, nur in ihren Werten (z.B. Farbe) unterscheidet,
entwickelt man einen Bauplan (=Klasse), aus dem die Klassen erzeugt
instanziert werden
■
■
■
Eigenschaften
Verhalten
Identität
Sportwagen
Farbe
Preis
Tankfüllung
Farbe
fahren
Modell
hupen
Rege's VW Golf
Bill Gate's Ferrari
Bill Gate's Ferrari
Rege's VW Golf
Hubraum
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
45 von 70
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
… Beispiel einer Klassifizierung
Attribute
■ Zusammenfassen von Gruppen gleichartigen Klassen zu Oberklassen
■ Definition Ein Attribut A einer Klasse K ist die Beschreibung eines
Datenelements, das in jeder Instanz der Klasse K vorhanden ist.
■
gemeinsame (abstrakte) Oberklasse
46 von 70
■ In der Beschreibung der Klasse wird der Name des Attributs angegeben.
Eine Objekt-Instanz von K trägt für jedes Attribut einen individuellen und
veränderbaren Attributwert.
■ Notation:
PKWs
Zweiräder
■ Beispiel
Erdbewegunsfahrzeuge
Klasse
Objekt : Klasse
Attribut_1
….
Attribut_n
Attribut_1 = Attributwert_1
….
Attribut_n = Attributwert_n
Bremskraftregler
Blockierungsdauer = 0
Transportfahrzeuge
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
47 von 70
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
48 von 70
Datentypen für Attribute
Detailinformationen zu Attributen
■ Definition Eine Klasse K kann für ein Attribut A einen bestimmten Datentyp T
vorschreiben. Dann muss in jedem Objekt O der Klasse K der Attributwert A aus
dem Wertebereich T sein.
■ Sichtbarkeit
■ Die Syntax für Datentypen ist in UML nicht festgelegt. Im allgemeinen können
Datentypen sein:
■ Multiplizität
■
■
■
Einfache Standard-Datentypen (z.B. Boolean, Char, Int)
Zusammengesetzt Datentypen (z.B. Int [10])
Klassenamen (Dann ist der Attributwert eine Objektreferenz)
■ Notation
■
■
■
■
■
+
#
-
global (public visibility)
geschützt (protected visibility, Klasse und Unterklasse)
privat (private visibility, nur Klasse)
[n..m]
[0..1]
mindestens n- höchstens m-mal, * für unbegrenzt
optionales Attribut
■ Initialwert
■
Attribut
oder
Attribut : Typ
oder
Attribut : Typ = Anfangswert
=x
Initialisierung bei Objekterzeugung
■ Beispiel
■ Beispiel
School of Engineerig
Bremskraftregler
Bremskraftregler
Blockierungsdauer : Int = 0
#Blockierungsdauer[1..4] : Int = 0
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
49 von 70
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
50 von 70
Klassenattribute
Operationen
■ Definition Ein Klassenattribut A einer Klasse K ist die Beschreibung eines
Datenelements, das genau einen Wert für die Gesamtheit aller Instanzen der
Klasse K annehmen kann. Gewöhnliche Attribute heissen auch Instanzattribute,
weil sei für jede Instanz individuelle Werte annehmen.
■ Definition Eine Operation OP einer Klasse K ist die Beschreibung einer Aufgabe,
die jede Instanz er Klasse K ausführen kann. In der Beschreibung der Klasse
wird der Name der Operation angegeben, die Parameterliste ist optional.
(Klassenoperationen analog Attribute)
■ Notation: Attribut : Typ
■ Notation
• Beispiel
■ Beispiel
Bremskraftregler
Klasse
Attribut_1
….
Attribut_n
Operation_1
….
Operation_n
# Blockierungsdauer[1..4] : Int = 0
- Räder : Int
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
51 von 70
School of Engineerig
Bremskraftregler
# Blockierungsdauer = 0
bremsen
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
52 von 70
Assoziationen und Aggregationen
Aggregationen
■ Definition Eine Assoziation beschreibt eine Beziehung zwischen Instanzen von
Klassen (Objekten). Mit der Assoziation kann gleichzeitig die Rolle ausgedrückt
werden die Objekte untereinander definieren. Zu dieser Rolle kann auch die
Multiplizität gehören.
■ Aggregation ist ein Spezialfall der Assoziation
• Beispiel
■ Notation
■ Mit der Aggregation wird eine Teil-von Beziehung ausgedrückt
■ UML kennt zwei Typen von Aggregationen
■
■
normale Aggregation
Komposition (stark gebundene Teile)
■ gleiche Lebenszeit von Teil und Aggregat
■ Notation
Klasse_1
• Beispiel
Bremspedal
1
Rolle
1
1
regelt Bremskraft
1
4
Bremse
School of Engineerig
Bremse
meldet blockiert
Bremskraftregler
*
Klasse_2
Klasse_1
löst Bremsvorgang aus
4
Hydraulik
Klasse_2
Sensor
53 von 70
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
School of Engineerig
1
Bremssscheibe
4
Bremsbelag
54 von 70
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Generalisierungsbeziehungen (Vererbung)
Subsysteme
■ Definition Klassen können auch als Spezialisierung von mehr allgemeineren
hervorgehen. Sie stehen dann in einer Generalisierungsbeziehung zueinander.
Typischerweise wird mit der Generalisierung auch die Substituierbarkeit
bestimmt, d.h. eine Unterklasse kann überall dort eingesetzt werden wo die
Oberklasse erwartet wird.
■ Grössere Systeme werden vorteilhaft in kleinere Subsysteme unterteilt in denen:
■
■
die Bindung innerhalb der Subsysteme möglichst gross
die Kopplung zwischen den Subsystemen möglichst gering ist
■ Notation
• Beispiel
• Beispiel
■ Notation
Antriebssystem
Paketnamen
Bremssystem
Bremspedal
Oberklasse
Bremskraftsteuerungssystem
Bremskraftregler
Bremse
Unterklasse
School of Engineerig
Bremskraftverstärker
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Sensor
ABS
55 von 70
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
56 von 70
Interaktionsdiagramme (Beschreibung
dynamischer Objektbeziehungen)
Zustandsdiagramme
■ Definition Mit den Interaktionsdiagrammen wird beschrieben, wie sich Gruppen
von Objekten verhalten. Eine Darstellungsform in UML sind die
Sequenzdiagramme (neben Kollaborationsdiagrammen).
■ Definition Mit dem Zustandsdiagramm werden die möglichen Zustände in dem
ein Objekt sich befinden kann beschrieben.
■ Beispiel
■ Beispiel
Bremspedal gedrückt
Bremspedal gelöst
Bremspedal
Bremskraftregler
Bremse
Sensor
Bremsen
bremsen
bremsen
Räder für > 50 ms
gelöst & Bremspedal
gedrückt
blockiert
Räder blockiert > 100 ms
Lösen
warte 100 ms
lösen
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Räder für < 50 ms gelöst
57 von 70
Beispiel: Eine Kreuzung
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
58 von 70
Beispiel: OO Modellierung der realen Welt
■ Mögliche Subsysteme
Kreuzung
Strassen
Induktionsschleife
Ampel
Regler
Drucksensor
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
59 von 70
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
60 von 70
Zusammenfassung
■ Wir haben folgende Begriffe kennengelernt:
■
■
Klassen, Objekte, Attribute und Operationen
Assoziationen, Aggregationen, Vererbungen, Subsysteme
■ Ferner kennen wir nun folgende Formen von Interaktionsdiagrammen:
■
■
Sequenzdiagramm
Zustandsdiagramm
School of Engineerig
Objektorientierte Analyse
61 von 70
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Methoden der objektorientierten Analyse
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
62 von 70
Klassen finden
■ Kandidaten für Klassen sind:
■
Klassen
Klassenfinden
finden
■
■
Assoziationen und
Assoziationen finden
und
Aggregationen
Aggregationen finden
Attribute finden
Attribute finden
Operationen
Operationenfinden
finden
■
Attribute
Attributefinden
finden
■
Operationen finden
Operationen finden
Assoziationen
Assoziationenund
und
Aggregationen
Aggregationenfinden
finden
Vererbungsstruktur finden
Vererbungsstruktur finden
Vererbungsstruktur finden
Vererbungsstruktur finden
■
■ Klassenname:
■
Datenorientierte
Vorgehensweise
School of Engineerig
Objekt-Lebenszyklus
Objekt-Lebenszyklusdefinieren
definieren
Operationen
Operationenspezifizieren
spezifizieren
Strukturen
Strukturenüberprüfen
überprüfen
Subsysteme
Subsystemefinden
finden
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Konkrete Objekte bzw. Dinge
Personen und deren Rollen
Informationen über Aktionen (z.B. Buchung)
Orte
Organisationen
Substantive in den Szenarienbeschreibung
Substantiv im Singular
■ Prüffragen:
Verhaltensorientierte
Vorgehensweise
63 von 70
■
■
Gibt es Attribute oder Operationen
Gibt es bereits eine identische Klasse
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
64 von 70
Operationen finden
Attribute finden
■ Kandidaten für Operationen:
■ Attribute sind Eigenschaften von Objekten (oder Klassen)
■
■
Aufgaben des Systems, Systeminterne Teilaufgaben
Ereignisse, auf die das System reagieren muss
■ Ein Attribut ist ein Datenelement, das in jedem Objekt enthalten ist
■ Nur problembezogene Attribute werden festgehalten
■ Keine expliziten Operation nötig für
■
■
■
Erzeugen und Löschen von Objekten
Lesen und Schreiben von Attributwerten
Auf- und Abbau von Assoziation / Aggregationen
■ Kein Attribute nötig für:
■
■
um Objekt zu identifizieren
um eine andere Klasse zu referenzieren
■ Operationennamen
■
■
soll ein Verb sein, in UML klein geschrieben
eindeutig und verständlich im Kontext der Klasse
■ Attributname (Substantiv)
■
eindeutig im Kontext der Klasse
■ Zuordnung von Attributen zu Klassen
■ Zuordnung von Operationen zu Klassen
■
■
■
evtl. neue Klassen bilden, Klassen auflösen
möglichst lokale Zugriffe auf Attribute
Objektoperationen bevorzugt gegen Klassenoperationen
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
65 von 70
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
Assoziationen und Aggregationen finden (1)
Assoziationen und Aggregationen finden (2)
■ Kandidaten für Assoziationen:
■ Aggregation ist ein Spezialfall der Assoziation
■
■
■
■
■
räumliche Nähe
Aktionen (A führt eine Aktion mit B aus)
Kommunikation (A sendet Meldung an B)
Besitz (A hat B)
allgemein Beziehung (z.B. A ist Fahrer von B)
■ Kandidaten für Aggregationen sind:
■
■
■
■
■ Assoziationsnamen
■
■
■
66 von 70
■
Verb in der 3. Person Präsens oder Perfekt
je allgemeiner der Klassenname, desto wichtiger der Rollenname
in UML ausgedrückt durch
oder
Das Ganze und seine Teile
Behälter und Inhalt
Kollektion und Mitglieder
Rangordnung
Schwer trennbare Assoziationen
■ Kontrollfragen:
■
■
besteht ein enger inhaltlicher Zusammenhang
ist die Aggregation symmetrisch oder asymmetrisch
■ Prüffragen:
■
■
ist die Assoziation unabhängig von allen unbeteiligten Klassen
welche Restriktionen muss die Assoziation erfüllen
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
67 von 70
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
68 von 70
Vererbungsstrukturen finden
Subsysteme finden
■ Kandidaten für Vererbungsstrukturen:
■ Ein Subsystem ist eine Gruppe von Klassen und Aggregationen/Assoziationen
■
■
■
identische Attribute und Operationen bei mehreren Klassen
sehr viele Attribute und Operationen in einer Klasse
natürliche Verallgemeinerung zur Erleichterung der Anpassbarkeit
■ Ein Subsystem:
■
■
ist für sich allein verständlich
hat eine wohldefinierte Schnittstelle zur Umgebung
■ "Gute" Vererbungsstrukturen
■
■
■
■
jede Unterklasse benötigt alle geerbten Attribute und Operationen
Generalisierungsbeziehung
■ Objekt der Oberklasse ist eine Verallgemeinerung der Unterklasse ("ist-ein")
maximal drei bis vier Hierarchieebenen
Klassen ohne Objektinstanz sind als abstrakt gekennzeichnet
■ Starke Bindung innerhalb des Subsystems
■ Schwache Kopplung zwischen Subsystemen
■ Vererbung sparsam einsetzen
■
■
■ Faustregel für ein sinnvolles Subsystem
nur wenn Vereinfachung und Anpassbarkeit erreicht wird
häufiger Fehler: "ist ein" Beziehung drückt auch Klassifikation aus
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
■
69 von 70
10-15 Klassen
School of Engineerig
© E. Mumprecht, J. Zeman, K. Rege, ZHAW
70 von 70