SWT WS1213 Folien v21

Grundlagen der

Softwaretechnik(SWT)

Vorlesung im Wintersemester 2012/2013Leibniz Universitt Hannover

Prof. Dr. Kurt SchneiderFachgebiet Software Engineering

[email protected]

Kurt Schneider Leibniz Universitt Hannover SWT-WS0910 - 3SWT 2012-13

1.

Grundlagen der Softwaretechnik

1. Wieso Software Engineering?

2. Programmieren: Vom Einzelkmpfer zum Groprojekt

3. Entwurf: Strukturen und nicht-funktionale Eigenschaften

4. Entwrfe notieren mit UML: Modelle im Software Engineering

5. Design Patterns: Entwurfserfahrungen

6. Anforderungen: Die Basis des Projekts

7. Projektmanagement: Wie alles zusammenspielen muss

8. Prozesse, Reife, Agilitt: ber den Tellerrand des Projekts


Anspruch der Veranstaltung

Lernziele von SWT (Vorlesung und bungen) Sie kennen die Schlagworte des Software Engineering Sie wissen, wie wichtige Verfahren im Prinzip funktionieren Sie haben einige selbst ausprobiert Sie wissen, wo sie genauer nachlesen knnen Sie knnen vernnftig in SW-Projekten mitarbeiten Sie achten beim Programmieren auf Verstndlichkeit Sie machen einige hufige Fehler nicht, weil Sie sie kennen Sie wgen ab und Sie entscheiden auf Basis eines begrndeten Urteils

Sie lernen dagegen nicht Grundlagen des Programmierens Irgendein kommerzielles Werkzeug zu bedienen


Organisatorisches

Aktuelle Informationen, Folien etc.: Wir verwenden StudIP Melden Sie sich auch hier an: www.se.uni-hannover.de Hier werden Bonuspunkte verwaltet.

Klausur Klausur SWT (und danach SWQ):

18.3.2013, Conti-Gebude Raum VII 201, 13:30 SWT, 14:45 SWQDiese Angaben ohne Gewhr! Lesen Sie kurz vorher www.se.uni-hannover.de

bungen: Anna Averbakh ([email protected]) Montags, 14:45 - 15:30 Uhr, MMH (Anna Averbakh)

--> berlauftermin, nur fr die Anfangsphase, dann beendet Dienstag, 11:15 12:15 Uhr, G323 (Polina Yakovleva) Dienstag, 15:00 16:00 Uhr, G323 (Oliver Karras) Mittwoch, 11:15 12:15 Uhr, G323 (Wadim Friedrich) Freitag, 10:00 11:00 Uhr, G323 (Matthias Herrmann)

Irrtum und nderungen vorbehalten!


Vorlesung bung Praktikum

Vorlesung Konzepte vorstellen Erklren kurz zeigen

bung Wichtiges noch mal zeigen Selbst anwenden/erklren Erfahrungen und Fragen diskutieren brigens: Korrelation bung-Note

Programmier Praktikum (ProPra) Programmieren ben Scheu verlieren In grerem Zusammenhang anwenden

Klausur

Berufspraxis


Wo Sie die angegebene Literatur finden

Bibliothek gegenber dem Hauptgebude

Systemstelle Software Engineering (L inf 430)

Im Lesesaal oder zu bestellen

in Anlehnung an Cockburn, A.: Writing Effective Use Cases. Addison-Wesley, 2001

Manche Bcher sind sehr gut zu

lesen. Blttern Sie doch mal durch!


Ein paar Tipps, aus Erfahrung

Das Wesen einer Vorlesung Frei gewhlt und doch kein Kino

Laptop, Block, oder Gedchtnis? Ein wenig Arbeitstechnik

Auch hier achten wir auf freundlichen, professionellen Stil Kommen Sie pnktlich Seien Sie leise, stren Sie Ihre Kollegen nicht Gehen Sie respektvoll miteinander um Spielen Sie mit Handy und Laptop: aber bitte nur drauen!

Wie man hineinruft

Wir wollen, dass Sie Erfolg habenund Ihnen die Sache Spa macht!

Anliegen und Ziele Herausforderungen an Software-Profis Grundbegriffe Geschichte und Vorbild Ingenieur Gedankenexperiment: Informationsfluss

Kapitel 1

Wieso Software Engineering?

weiche Botschaften - harte Wahrheiten

Prof. Dr. Kurt Schneider


Einstimmungsbild

http://www.plexispos.com/screens/touchkey1.jpg(20.9.2006)


Software ist berall

Bankomat Animierter Film Auto Zndschlssel Spielzeug Gehaltsabrechnung PC-Spiel Luftraumkontrolle Medizin ...


Mit SW ist jeder stndig konfrontiert

jemand muss eine Idee fr SW haben jemand muss sie entwickeln jemand muss sie kaufen jemand muss sie installieren jemand muss sie verwenden (wollen) jemand braucht die Resultate


Fazit: Einfluss von Software

SW beeinflusst Technik SW beeinflusst Wirtschaft SW beeinflusst Menschen

Software


Software ...

Ist der faszinierende Werkstoff unserer Zeit!

Aber es kommt darauf an, was man daraus macht

... und wie man es macht!


Wenn es dagegen nicht funktioniert

Katastrophenbeispiele Flugzeug bremst nicht Marssonde geht verloren Fahrkartenautomat macht einen verrckt Spiel ist nicht zu kapieren, Geburtstagskind heult

Was htten Sie besser gemacht?

Sie werden Gelegenheit bekommen, das zu beweisen: Auto Banken, Brsen Kernkraftwerke Spielzeughersteller Admin. Software

Hier oder in vielen anderen Bereichen schon in bungen und Softwareprojekt!


Softwareentwicklung richtig machenein kleiner Unterschied

Annahme: Sie wollen nicht Hobbyprogrammierer werden, sondern Softwareprofi dazu gehrt die richtige Einstellung

Nach dieser Vorlesung sollen Sie Fhigkeiten Fertigkeiten und berzeugungen gewonnen haben,

die die Wahrscheinlichkeit fr erfolgreiche Projekte erhhen.

Programmieren ist nicht schwer, professionell Entwickeln sehr Technische Seite: Programmstruktur und Methoden konomische Seite: Kosten und Nutzen Menschliche/psychologische Seite: Kunden und Mitarbeiter

Nehmen Sie die Softwaretechnik ernst, dann macht sie Spa


Kritik ist einfach

Bluescreen

Microsofts Datenerhebung

Zu komplizierte Oberflchen

Langsame Verarbeitung

Unlogische/doppelte Abfragen

Strende Releasewechsel

Sicherheitsbedenken

Anforderungen klren

Benutzer verstehen

Neueste Technik einsetzen

Seris planen und verfolgen

Qualitt und Risiken prfen

Unsere Frage muss sein: was knnen wir (als Informatiker) dagegen tun?


Herausforderung an Profis 1Software soll tun, was Kunden erwarten

Aber woher wissen wir, was Kunden erwarten? Anforderungen erfassen und umsetzen Irrglauben ablegen, wir wssten selbst am besten, was richtig ist

Und wer genau sind diese Kunden? Initiator des Auftrags, Kufer, Anwender, Marketing Nicht nur den Erstbesten befragen

Aber wenn die es nicht sagen? dann knnen sie es vielleicht einfach nicht! Wir mssen helfen dafr gibt es Techniken (Requirements Eng.)


Aber fr wen? Verschiedene Leute haben unterschiedliche Bedrfnisse Usability Engineering: Benutzerprofil erstellen

Und in welchem Zusammenhang? Eigentlich will kaum einer ein Programm bedienen sondern

eine Aufgabe erledigen Usability Engineering: Aufgabenanalyse durchfhren

Aber sind Oberflchen nicht Geschmackssache? Irrtum: darum geht es gar nicht! Man kann objektiv sagen:

manche Farbkombinationen sind physiologisch ungnstig Man merkt sich nur 5+/-2 oder 3*3 Einheiten und so weiter: das zu bedenken hilft schon sehr

Geschmacksfragen von obj. Bedienbarkeit trennen

Herausforderung an Profis 2Software soll leicht zu bedienen sein


Herausforderung an Profis 3Software soll im Zeit- und Kostenplan bleiben

Software

Zeit

Kosten Qualitt

ACHTUNG!Qualitt umfasst hier

Funktionalitt undnicht-funktionale

Eigenschaften

Realistisch planen trotz vieler Unsicherheiten Alle relevanten Aspekte methodisch planen (Projektmgmt.) Systematisch aus Erfahrung lernen

Neueste Technik einsetzen, dennoch gut schtzen Typische Informatikerfehler vermeiden, Schtztechniken

Auswirkungen von Zeit- und Kostenberziehung bedenken Risiken fr den Kunden abschtzen Damit eigene Risiken


Software Engineering

Hilft, diese Herausforderungen anzugehen

Bietet systematische Methoden und Techniken Projektmanagement Risikomanagement Requirements Engineering Usability Engineering und viele Techniken mehr

Bezieht sich auf SW-Entwicklung, -Akquisition und -Wartung

Bietet Konzepte, praktische Tipps fr den tglichen Bedarf... aber auch ungelste Forschungsfragen


SE wird beeinflusst

Fazit: Das ist kein softes Bild: harte Einflsse! SE muss sich in der Praxis dieses Spannungsfelds bewhren Software-Profis knnen sich nicht nur auf einen Aspekt strzen

Menschen

TechnikWirtschaft

SoftwareEngineering


Grundbegriffe

Software (SW) Computer programs, procedures and possibly associated

documentation and data pertaining to the operation of a computer system (IEEE Std 610.12 - 1990)

Bemerkungen: Computer system im weiteren Sinn: embedded

Software Engineering (SE)(1)the application of a systematic, disciplined, quantifiable approach

to the development, operation, and maintenance of software; that is, the application of engineering to software

(2) the study of approaches as in (1) (IEEE Std 610.12 - 1990)

offenbar ist also Engineering: a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of X

Parnas: SE erst ab 2 Personen und 2 Versionen

Softwaretechnik (SWT): hier als Synonym fr Software Engineering


Ingenieursprinzipien

A systematic, disciplined, quantifiable approach to the development, operation, and maintenance of X

Konsequenzen Kostendenken

Kein Perfektionismus

Qualittsbewutsein es luft reicht nicht

Anwendung von Normen und Regeln keine Knstler

Probleme durch Zerlegung lsen divide et impera

Baugruppen und Wiederverwendung statt not invented here


Wieso Software Engineering?

Hardware wird relativ immer billiger und besser Speicher ist grer, schneller, billiger Rechner auch Netzwerke auch

Software kann nicht mithalten Produktivittsgap Denn Software entsteht im wesentlichen im Hirn Das wchst nicht so schneller wie Chips und Speicher

Verzahnung mit Wirtschaft und Gesellschaft Immer mehr Software in allen Bereichen steigende Komplexitt wachsende Lebensdauer grere Technologiesprnge

SW=Risiko+Chance

Muss man systematischangehen, nicht zufllig


Kurze Geschichte des Software Engineering

Sehnsucht: ingenieursmig auch bei Software vorgehen! Verklrung des Ingenieurs

Bei Hardware klappt es so gut, und bei Brcken und Husern

Aber Software ist anders SW ist immateriell nur Entwicklung, keine Fertigung SW hat unstetiges Verhalten Testen viel schwieriger universelles Material fr alle mglichen Anwendungen amorphes Material keine implizite Struktur Entwickler berschtzen sich regelmig

Trotzdem mchte man SW genauso gut in den Griff kriegen

F.L. Bauer, NATO Science Conference, Garmisch-Partenkirchen 1968Anwendung von Ingenieursprinzipien fr zuverlssige SW, die auf realen Rechnern luft und mit wirtschaftlichen Mitteln erstellt wird.


NATO Science ConferenceGarmisch-Partenkirchen 1968

http://homepages.cs.ncl.ac.uk/brian.randell/NATO/N1968/

Der Begriff Software Engineeringwird geprgt

Prof. F.L. Bauer


Professionelle Softwareentwicklung?http://www.csss.cs.ubc.ca/files/images/DSCN2559.preview.jpg(29.9.06)


SW-Entwicklung

Elemente der Software-Entwicklung

Computer/Ressource

Person

7300Day One

7200Info-Material

12

a: BedienkonzeptEntwickeln (3)

3

b: KassiererschulungErarbeiten (3)

4d: InfomaterialEntwickeln (3)

e: Infomaterialverteilen

(1)

5

c: Kassierer-Schulung

halten(2)

6f: erster Tagoperativ

(1)

03

6

6

9/9

/8/7

/6

/3

/4

/0

7 8

Plan

Phase

Projekt-definition

Abfolge

Rolle

Anforderungs-erhebung

Codierung

Aktivitten

Dokument

Handbuch


SW-Entwicklung

Modelle sind Voraussetzung fr Planung

Rolle

Computer/Ressource

Dokument

Person

7300Day One

7200Info-Material

12


3




(1)

5


halten(2)


(1)

03

6

6

9/9

/8/7

/6

/3

/4

/0

7 8

Plan

Phase

Projekt-definition

Abfolge

Anforderungs-erhebung

Codierung

Aktivitten

Handbuch

Modell

Original


Grundbegriff Modell

Original Modell

Relevante Eigenschaften

PrterierteEigenschaften

AbundanteEigensch.

Modell-Abbildung

Fragen zu Charakterisierung und Verstndnis Was ist das Original? Modell fr wen? Modell zu welchem Zweck (welche Operationen)? Welche Eigenschaften sind dafr relevant?


Wozu modelliert man was?

Modell-element

Original Relevante Eigenschaften

Fr wen, wozu?

Aktivitt Bestimmte Ttigkeit

Ziel, Ergebnis, Dauer, Teilnehmer

Projektleiter, Mitarbeiter: Plan, Aufgaben

Rolle Bndel von Aufgaben, Rechten u. Pflichten

Aufgaben, ZustndigkeitenVerantwortg.

Alle Projekt-beteiligte: wissen, wer was tun muss

Dokument Papier- oder elektron. Dokument

Zugnglich, lesbar, meist mit definierter Struktur

Autor und Leser: was ist zu leisten/zu erwarten

Person Individueller Mensch

Individuum; Fhigkeiten, Krankheiten

Projektleiter: Rollen zuweisen, Eigen-heiten beachten

Beziehungen Abhngigkeit, Kenntnisse

(verschieden) (vielfltig: meist um bersicht zu wahren


Wie modelliert man Software-Entwicklung?SPEM / Syntax

SPEM heit Software & Systems Process Engineering Meta-Model Dt.: Metamodell fr Entwicklungsprozesse der Software- und Systemtechnik Version 2.0 vom April 2008

Historie Es gibt verwirrend viele Ablaufnotationen Nach dem Vorbild von UML angegangen; aber anderes Original Als UML subset definiert (merkt man aber kaum) D.h: ordentlich definiertes Austauschformat fr Prozessbeschreibungen

SPEM ist kein Prozess sondern eine Modellierungsnotation dafr

z.B. CodeConventions

z.B.: Entwickler z.B. programmieren

z.B. SourceCode


SPEM-Notation (Auszug)

Work Product Definition Dokument oder anderes Produkt

Role Definition Bndel von (erwarteten) Fhigkeiten u. Kompetenzen AKV: Aufgaben, Kompetenzen, Verantwortlichkeiten

Task Definition Arbeitsvorgang; kann unterteilt werden

Category Zum Strukturieren von Elemente (in eine Hierarchie)

Guidance Anleitende Info.: Templates, Checklisten, Vorgaben


Person und RolleImmer genau unterscheiden

Beide Konzepte sind wichtig Aber sie bedeuten nicht das Gleiche!

Rolle Auf Zweck hin definiert:

Aufgabe erfllen Profil vorausgesetzt:

Kenntnisse, Fhigkeiten Definierte Aufgaben, Zu-

stndigkeiten, Verantwortg. Mit Erwartungen verbunden Von einer oder mehreren

Personen auszufllen

Person Individuum mit persnlicher

Geschichte: ist, wie sie ist Hat ein Profil, passt mehr oder

weniger zu Rolle Wird Rolle zugewiesen, ber-

nimmt deren Aufgaben usw. Erfllt Erwartung mehr/weniger Kann eine, mehrere oder keine

(definierte) Rolle wahrnehmen

Patrizia

Paul

Entwickler

Analytiker


Ordnung im Softwareprojektdurch Prozesse und Prozessmodelle

Aktivitten und Ablufe

Normaler Ablauf

es gibt aber Alternativen!

Analyse(Anford.) Entwurf Codierung Integration Betrieb

Code&fix: lieber nicht!

Codierung Codierung CodierungFix Fix


Beispiel fr eine Variante

Prototyping auch davon gibt es noch Unter-Varianten

Analyse(Anford.) Codierung

Integration Betrieb

EntwurfAnalyse(Anford.) Codierung


Ordnung im Softwareprojekt

7300Day One

7200Info-Material

12


3




(1)

5


halten(2)


(1)

03

6

6

9/9

/8/7

/6

/3

/4

/0

7 8

Projektplan

Benutzer-Handbuch

Dieter-Paul

Einige Beziehungen

Patrizia

isterstellt

BetriebIntegra-tionCodierungEntwurfAnalyse(Anford.)

(Betriebs-Ing.)

Projektleiter

ProgrammiererDesignerAnalytiker

Tech.Writer


Grundbegriffe fr diese Vorlesung

Diese Dokumentarten muss man kennen

Wie die Aktivittentreten sie in verschiedenen Formen/Namen auf

Grundbezeichnungen (rechts) sind ein guter Anhaltspunkt

... wir kommen darauf zurck!

Lasten-heft

Pflichten-heft

Grob-entwurf

Fein-entwurf

Code

TechnischeDoku-

mentation

Roll-Out-Plan

Test-plne

Benutzer-Handbuch

Software = ... and documentation

BetriebIntegra-tionCodie-rungEntwurf

Analyse(Anford.)


Gedankenexperimentzum Informationsfluss in Projekten

Ein Experiment, um die Dynamik zu sehen! Softwareprojekt ist etwas hoch Dynamisches

Gesucht: Entscheidungshilfe in vielen SE-Situationen wie wirkt sich eine Handlung auf Projektfortschritt aus?

Gefunden: Softwarequanten-Metapher Metapher half schon bei der Simulation von SW-Projekten


Software-Quanten


Software-Quantenwandern

Spezifikation


Software-Quantenwandern

Spezifikation Entwurf Code


... und am Schluss

Spezifikation Entwurf Code


Zusammenfassung von Kapitel 1

Software beeinflusst Technik, Wirtschaft, Menschen

Software Engineering wird davon beeinflusst Professioneller Softwareingenieur beachtet alle Aspekte

Geschichte des Begriffs Software Engineering NATO Science Conference 68, F.L. Bauer, Engineering als Vorbild Aber Software ist ein spezielles Material!

Software Engineering: Viel Neues in Forschung und Praxis

Modelle fr bersicht und Planung Aspekte eines Softwareprojekts

Gedankenmodell Software-Quanten Probieren Sie es aus: www.se.uni-hannover.de/en/qgame


Programmhygiene und egoless programming Dokumentation und Zusammenarbeit Konfigurationsmanagement Information Hiding Interfaces

Kapitel 2

ProgrammierenVom Einzelkmpfer zum Groprojekt



Situation Einzelkmpfer

AlleinKeiner bezahlt

Keiner beteiligt sichSelbst die Idee gehabt

Wird nicht weiterentwickelt

Muss keinem Kunden gefallenMuss nicht zusammenpassenMuss nicht verstndlich sein

Muss man keinem zeigenMuss nicht gelingen


Stellen Sie sich vor

Sie haben eine neue Stelle Sie sollen Code entwickeln und pflegen

Zu Anfang bekommen Sie das Programm eines Kollegen Er hat sehr auf Speichereffizienz geachtet, heit es Er ist leider versetzt worden Nicht mehr verfgbar

Viel Spa


Was tut dieses Programmstck?

Erst verstehen, dann verbessern

Wieso verstehen Sie das nicht?Das Programm funktioniert doch!


Quellcode dient der Kommunikation

Syntax korrekt der Compiler versteht Semantik korrekt das Programm tut, was es soll

Dennoch kann es unverstndlich und unwartbar sein! Dann ist es in der Praxis nutzlos

FazitQuellcode dient der Kommunikationmit dem Compilervor allem aber mit anderen Menschen

Quellcode

Entwickler


Erster Versuch: Bessere Formatierung

Schon besser. Bezeichner sind nicht hilfreich, im Gegenteil

berlang, kryptisch, mit Sonderzeichen bezeichnen nichts, sondern verwirren

Kein Hinweis!

FALSCH!

Bedeutung der intVar?

x, y: Koordinaten?

Irrefhrend


Zweiter Versuch: Bessere BezeichnerFazit: Auch das Format ist wichtig

Leerzeilen, Leerzeichen, TabsUmbrche, Einrckungen

Sieht wie Fehler aus

Leere strt

Leere fehlt

Gegen die Semantik


Format und Bezeichner besser

Keine Kommentare Alles public, keine Exceptions Verstehen Sie, was hier passiert und warum?


Kommentare sind kein Luxus

Schreiben Sie Programme zum Lesen fr Menschen!

Dazu gehren Bezeichner Kommentare Optische Verteilung

Hintergrundinformation Huffmann Code


Fazit: Wie sehen Programme aus?

Sie whlen im Quellcode: Klassennamen Methodennamen Leerzeichen Kommentare Einrckungen

Variablentypen Schleifen Rckgabewerte

Ziele Verstndlichkeit Lesbarkeit


Software Engineering: Zoom out

Vom Einzelkmpfer zum Team und Projekt

Programmierstil: subjektive Vorlieben und professionelles Verhalten

Sie programmieren nicht vor allem fr sich Man soll nicht merken, wer es gemacht hat (egoless!) Jemand anders macht damit weiter evtl. nach langer Zeit Software-Entwicklung ist viel mehr als Programmieren Sie mssen zusammen erfolgreich sein


Sie sind nicht allein.

Groe Systeme kann man nicht allein entwickeln

Entwicklung findet immer mit vielen Beteiligten statt Viele Kunden Viele Entwickler

Koordination erforderlich Entwicklungsprozesse fr die Ablufe Versions- und Konfigurationsmanagement fr die Technik

Untersttzung durch Werkzeuge z.B. CVS, Subversion oder Git


Richtlinien

Bezeichner: machen knapp ihre Bedeutung klar

Format: gewohnte Struktur erleichtert die Orientierung

Kommentare: erklren den Quellcode (warum ist das so?)

Externe Dokumentation: Beschreibt ausfhrlicher Hintergrnde

Aufteilung und Struktur: entspricht den Entwurfsentscheidungen Pakete: Nicht vergessen! Anzahl von Klassen, Methoden, LOC, Kommentaren: ausgewogen Vererbung: einsetzen, aber nicht zu tief vererben Komplizierte Stellen im Programm mssen erklrt werden

Wieso muss das gemacht werden? Wieso wird es so gemacht? Was bedeutet die Konstante, woher kommt die Formel? Welche Funktion hat das im Algorithmus?

Mglichst macht man aber gleich gar nichts kompliziert


Beispiele aus dem ProPra zur Diskussion

package de.unihannover.se.pp.Engine;

public class Account implements IAccount {private String name;private int balance;

public Account(String name, int balance){

setName(name);setBalance(balance);

}

public String getName() {return name;

}

public void setName(String name) {if(name == null)

throw new IllegalArgumentException();if(name.equals(""))

throw new IllegalArgumentException ("Der Kontoname sollte mindestens ein Zeichen lang sein!");this.name = name;

}

// Folgen noch getter und setter

public int getBalance() {return balance;

}

AufgabeImplementierung fr Interface IAccount- Kontostand abrufen- Inhabernamen abrufen und setzen

Sinnvoller Paketname

Gute Bezeichner

Position inkonsistent: {

Sogar sehr gut: Sonderflle behandelt


Bezeichner sorgfltig whlen

Konstanten benennen Symbolische Namen: PI statt 3.141592 Gro geschrieben: MEHRWERTSTEUER statt 16.0

Kurzbezeichner (nur) dort, wo sie blich sind Schleifenzhler: i, j, k Koordinaten: x, y Aber nicht aus Faulheit: asrstz (Abschreibungsrabattsatz) Konvention: Teilweise zur Vereinheitlichung erzwungen U2-MEA-PREM

Lngere Bezeichner Drcken inhaltliche Bedeutung aus: steuersatz, kontonr Hinweise auf Typ sind akzeptabel: kontoNrInt (nicht so gut) Aber NICHT der Typ allein: float1 Nicht zu lang whlen: steuerlichAbsetzbarerPauschbetrag Jedes Objekt soll EINE einzige Bedeutung haben: eindeutig benennen Deutsch oder Englisch: kein Gemisch


Methodennamen

Bezeichnen, was der Empfnger tun soll: () setName fillRectangle Update

Methoden mit Rckgabe: Name bezeichnet Rckgabewert isEmpty implizierte Rckgabewerte: ja oder nein getName nicht so schn, aber blich (Rckgabe: name) conflictingRules ermittelt Sammlung widersprchlicher Regeln

Rckgabe: Rules (und zwar die mit Konflikt)

Am besten lesen sich Aufrufe wie normale Stze steuerformular.steuersatz(kunde.getEinkommen()) Hallo Steuerformular, was ist der Steuersatz vom Einkommen des kunden?


Vertiefung: Variablendefinition

Nur eine pro Zeile definieren, dahinter // Kommentardouble steuersatz; // Durchschnittssatz, in Prozent

Initalisieren, wenn nicht stets erst eine Berechnung ntigdouble mehrwertsteuer = 19.0; //normaler Satz, in %

Mglichst lokal definieren Schleifenvariablen in der Schleife

for (int i = 1; i


Java-Konventionen von Sun

Google: Java code conventions (von Sun). Auszug:


Code-Konventionen

Wozu? Einheitlicher Code (egoless)

Welches sind die besten Konventionen? Eclipse, Sun, Firma XY, Ihre eigenen?

Welche sollte eine Firma verwenden, wie oft wechseln? Bekannte Einfache Prfbare

Antwort: vor allem immer dieselben!


Eclipse hilft bei Java-Konventionen

Rechtes-Maus-Men


ProPra-Beispiel zur Diskussion keine Angst: stets anonym

protected JLabel account1, account2;private IAccount acc1, acc2;

JLabel lblAcc1 = (JLabel)main.getContentPane().getComponents()[6];JLabel lblAcc2 = (JLabel)main.getContentPane().getComponents()[7];

// Fr die Fhigkeit, ein Fenster darzustellen: die GANZE Klassepublic class Fenster extends JFrame {

public Fenster(){}}

public class Konto extends JFrame implements IAccount public Konto(ArrayList liste)

Konto kann alles

Nur der Name neu?

Keine sprechenden Namenschlecht zu merken

fehleranfllig

Components nicht gemerkt,Mssen kryptisch angesprochen werden



public MoneyTransfer(Account source, Account destination, int sum){

source.setBalance(source.getBalance() - sum);destination.setBalance(destination.getBalance() + sum);

this.sum = sum;this.source = source;this.destination = destination;

}public void execute(){

source.setBalance(source.getBalance() - sum);destination.setBalance(destination.getBalance()+sum);

}

Wieso (erst jetzt)?

Achtung: Schon im Constructor geschehen!

Besser:1. Parameter in Attribute bernehmen2. Erst bei explizitem execute() ausfhren



package uebung01;public class MoneyTransfer implements IMoneyTransfer {

Account source;Account destination;int amount;public MoneyTransfer(Account source, Account destination, int amount) {

this.source = source;this.destination = destination;if (amount >= 0)

this.amount = amount;else

this.amount = -1;}public void execute() {

if (amount == -1)System.out.println("Buchung nicht erfolgreich - negativer Betrag!");

else {source.setBalance(source.getBalance() - amount);destination.setBalance(destination.getBalance() + amount);System.out.println("Buchung erfolgreich!");

}}

}

Wenig Luft: Leerzeilen, Kommentare

Paketname entspricht nicht der Norm

Abfrage bereits im Konstruktor. Wieso?

Fehler implizit durch Code gekennzeichnet, keine Reaktion

Scheinbar unsinnig enge Abfrage: was ist mit -200?



Kapitel 2




Dokumentation im Code

Kopfkommentare (header) Bis zu einer Druckseite/Methode blich

Struktur und Gestalt des Codes Code ist Dokument, muss lesbar gemacht werden Einrckungen, Kommentare, Bezeichner

Namen von Variablen, Klassen, Methoden usw. Hufig Namenskonventionen Dennoch sprechende Benennung

Kommentare Wo, wie viel, welche Angaben (v.a. Kopfkommentare)?

Im Projekt standardisieren! Nicht beschreiben, was man sieht (5 addieren, Exception werfen)

Eher warum es geschieht und warum auf diese Weise

Wichtig wieder:Rationale

(Begrndung)


Arten von Dokumentation

Fr den Benutzer Manual, Bedienungsanleitung Roll-Out-Plan Wartungsunterlagen, technische Dokumentation

Fr den Entwickler Codekommentare Technische Dokumentation Hintergrundinformation

Fr das Projekt und das Management Produktdokumentation Projektdokumentation (Ablauf, Zeitplne, Organisatorisches) Prozessdokumentation (Zwischendokumente, Prozessangaben)


Javadoc

Verlinkte Dokumentation, aus Kommentaren generiertdoc comments:

/** */

Schnitt-Stellen(APIs)


Javadoc / Graphics


Externe JavaDoc-Dokumentation erzeugen1. JavaDoc-Kommentare einfgen

normale Kommentare werden ignoriert

JavaDoc an die richtige Stelle schreiben

Es gibt Schlsselwrter (mit @)


Externe JavaDoc-Dokumentation erzeugen2. JavaDoc generieren

Einige weitere Angaben, [command liegt unter Java/bin/javadoc.exe],dann


Externe JavaDoc-Dokumentation erzeugen3. Erzeugte Dokumentation verwenden

Ein ganzer Dokumentenbaum wird erzeugt; z.B. index.html:


Viel ist mglich in JavaDoc


Externe DokumentationBeispiel: Entwurfsidee Huffmann-Code

Teilweise als JavaDoc aus dem Programm generiert Teils separat geschrieben (nicht im Programm: Beispiel, Theorie)

3

6

7

22

23

30

46

55

200

7

22

23

30

46

55

200

93

6

1622

23

30

46

55

200

7

93

6

16

Eintrge nach Hufigkeit sortieren.

3

6

7

22

23

30

46

55

200

97

22

23

30

46

55

200

93

6

Die zwei kleinsten streichen,ihre Summe in einen neuen Eintragstecken und einsortieren.

Diesen Schritt wiederholen,bis aus der Liste ein Baum

geworden ist.

ABCDEFGHI


Externe DokumentationBeispiel: Entwurfsidee Huffmann-Code

Auch interessant: Beweis, dass dies zu optimalem Code fhrt Wichtige Entwicklerdokumentation: Empfohlene Datenstruktur


geworden ist.

22

23

30

46

55200

7

93

6

1638

53

84

108

192392

3

6

7

22

23

30

46

55

200

ABCDEFGHI

Jeweils 0 und 1 an Verzweigung schreiben.Egal, was wohin.

Der 01-Pfad ist der Code fr den Buch-staben

0

1 1

11

11

110

0

00

00

0 0 0 0 0 1 00 0 0 0 1 10 0 0 0 00 0 0 10 1 0 00 1 0 10 0 10 1 11

Huffmann-Code



Kapitel 2




Code organisieren: Versionen und Konfigurationen

Ziele Dateien, die bei der Entwicklung anfallen, fr Team koordinieren Fr alle zugreifbar Kein versehentliches Lschen Kein gegenseitiges berschreiben Klarheit ber jeweils gltige Fassung

xyyz

xyneu

v1

V2/3

v2


Code organisieren: Versionen und Konfigurationen

Grundgebriffe Version =Def Definierter Stand eines Dokuments

Konfiguration =DefMenge der Versionen aller Bestandteile eines Systems,die zu einem definierten Stand gehren

v3v2v1

v18v17

V2.0V1.1V0.8

Teil A

Teil B

Teil C

System = A+B+C

Zeit

Konfiguration (tk)

tk


Grundlagen

Aufbau einer Versionsverwaltung

DB Filesystem

Repository

Working CopyWorking Copy

Client Client

Server

Client Interface


Wichtige Begriffe 1/2

Repository Zentraler Datenspeicher

Working Copy Lokale Arbeitskopie

Checkout Arbeitskopie aus dem

Repository erstellen Update

Arbeitskopie mit nderungen im Repository aktualisieren

Add Neue Datei/Verzeichnis dem

Repository hinzufgen Checkin/Commit

nderungen der Arbeitskopie ins Repository schreiben

v1

V2/3

v2

OptimistischMehrere haben Zugriff auf ein DokumentFalls beide ndern, gibt es Kollission

PessimistischSicherheitshalber darf nur einer ndernKeine KollissionBehindert aber Parallelarbeit


Wichtige Begriffe 2/2

Conflict Gleichzeitige nderung der selben Stelle einer Datei

Diff Differenzen zweier Dateien anzeigen

Merge Zusammenfhren von zwei in Konflikt stehenden Dateien

Tag Spezieller Name einer Version (z.B.: Release 1.4)

Branch Separater Zweig eines Projekts, an dem unabhngig vom

Hauptzweig weitergearbeitet wird Z.B.: Hauptzweig: Firefox 1.5.x, Branch: Firefox 2.0.x


VersionsmanagementPrinzip (optimistisch)

Grundoperationen1. Aufsetzen: Pfade, Rechte etc.2. Datei beim System anmelden: add3. Datei eintragen: commit4. Datei herausholen: checkout5. Datei zurckgeben: commit6. Datei nochmal holen: update

d

3 commit d2 add d

1

5b commit d6 update d

Weiterfhrendes Branches (Verzweigungen)

Abspalten: branch Verbinden: merge

Konflikte Nie beim Auslesen: optimistisch Falls beim Zurckgeben:

Merge versuchen Sonst Warnung, manuell

4b checkout d

d

4a checkout d(d ndern)

dworkingdirectories

5 commit d

7 Konflikt auflsen8 commit



Kapitel 2




Sie arbeiten im TeamStellen Sie sich vor

Sie haben den Huffmann-Code programmiert. Nun soll ihn das ganze Team benutzen.

Was geben Sie den Kollegen, damit sie das tun knnen?


Was mssen die anderen wissen?Beispiel Huffmann-Code-Programm

3

6

7

22

23

30

46

55

200

3

6

7

22

23

30

46

55

200

97

22

23

30

46

55

200

93

6

7

22

23

30

46

55

200

93

6

1622

23

30

46

55

200

7

93

6

16Eintrge nach Hufigkeit sortieren.


Diesen Schritt wiederholen,bis aus der Liste ein Baum geworden ist.

ABCDEFGHI


22

23

30

46

55

200

7

93

6

1638

53

84

108

192

392

3

6

7

22

23

30

46

55

200

ABCDEFGHI

Jeweils 0 und 1 an Verzweigung schreiben.

0

1

1

11

11

110

0

00

0

00 0 0 0 0 1 0

0 0 0 0 1 10 0 0 0 00 0 0 10 1 0 00 1 0 10 0 10 1 11

Huffmann-Code


PerspektivenwechselWas mchten Sie in dieser Situaton wissen (mssen)?

Oh, es gibt jetzt einen effizienteren Algorithmus! Verwenden Sie doch den! Wir haben ein Modul gekauft.Es ist aber sehr kompliziert; 12 Seiten Mathe wenn Sie das nicht verstanden haben, knnen Sie das Programm kaum richtig einsetzen.Aber wir haben auch die ganze Entwicklerdoku hier drei Ordner!Super, oder?

Wollen Sie das

BetterCode

+addChar(char, int)+printCodeBook()

Oder eher das:


Also: Was mssen die anderen wissen?Beispiel Huffmann-Code-Programm

3

6

7

22

23

30

46

55

200

3

6

7

22

23

30

46

55

200

97

22

23

30

46

55

200

93

6

7

22

23

30

46

55

200

93

6

1622

23

30

46

55

200

7

93

6

16Eintrge nach Hufigkeit sortieren.


Diesen Schritt wiederholen,bis aus der Liste ein Baum geworden ist.

ABCDEFGHI


22

2330

46

55200

7

936

1638

53

84

108

192392

367

2223304655

200

ABCDEFGHI

Jeweils 0 und 1 an Verzweigung schreiben.

0

11

11

11

110

0

00

00

0 0 0 0 0 1 00 0 0 0 1 10 0 0 0 00 0 0 10 1 0 00 1 0 10 0 10 1 11

Huffmann-Code

HuffmannCode

+addChar(char, int)+printCodeBook()

Das meiste verstecken wir!Zum Glck.


Entwurfsprinzip Information Hiding

Von David Parnas, 1972

Absolute Grundlage des SE! Taucht immer wieder auf Von Implementierung bis Doku.

Idee: Jede Einheit gibt nur das Ntigste preis, um sie zu nutzen Das ist die Schnittstelle mit Dokumentation

Wie sie funktioniert, ist dagegen versteckt (hidden) ndert sich etwas Internes, merkt man es auen nicht Da vor ihm/ihr versteckt, braucht Nutzer keine Selbstdisziplin Jede Einheit versteckt (min.) eine Entwurfsentscheidung Parnas


Beispiel/SzenarioVereinfachtes Telefonbuch

A schreibt Customer Management System (CMS) Will darin ein vereinfachtes Telefonbuch nutzen Beauftragt B

B macht sich Anforderungen klar (Name, Telefonnummer)-Eintrge verwalten Suche nach richtigem Eintrag untersttzen Lschen, Initialisieren

Alles Kompliziertere lassen wir in diesem Beispiel weg! Namen seien eindeutig, null werde abgefangen usw.

Ziel: Sinn von Information Hiding mit Interfaces zeigen

A

B

BeispielInterfaces


PhoneTable

Erster Versuch: B verwendet Array

PhoneTable(int size) setEntry(int id, String name, String number)getNumber(String name): StringgetID(String name): intdelete(id)

1234567

MllerHuber

SchneiderSchmidt

Khler

0511/978650241/12-4711

762-19666001-(303) 492

030/762-123

Als simples Array implementiertpublic void organize() {

PhoneTable ph = new PhoneTable(7);ph.setEntry(3, "May", "089/4567");nr = ph.getNumber("Khler");ph.delete(ph.getID("Huber"));

}

CMS verwendet PhoneTable

BeispielInterfaces


PhoneList

Zweiter Versuch: B versucht verkettete Liste

first(): Nodesearch(String): Nodeinsert(Node)append(Node)delete(Node)

Als verkettete Liste implementiertimport theNodePackage.Node;public void organize() {PhoneList ph = new PhoneList();// insert or appendph.insert(new Node("May", "089/4567"));nr=ph.search("Khler").get_Number();ph.delete(ph.search("Huber"));

}

CMS verwendet PhoneList

Node1 * get_Name(): String

set_Name(String)get_Number(): Stringset_Number(String)get_nextNode(): Nodeset_nextNode(Node)get_prevNode(): Nodeset_prevNode(Node)

Mller 0511/97865

Huber 0241/12-4711

Schneider 762-19666

Schmidt 001-(303) 492

Khler 030/762-123

BeispielInterfaces

nextNode

prevNode


TreeNode1 *

C berredet A zu sortiertem Baum

first(): TreeNodesearch(String): TreeNodeadd(TreeNode)delete(TreeNode)

PhoneTree

Als speziell sortierter Baum implementiertimport theTreePackage.TreeNode;public void organize(){PhoneTree ph = new PhoneTree();ph.add(new TreeNode("May", "089/4567"));nr=ph.search("Khler").get_Number();ph.delete(ph.search("Huber"));

}

CMS verwendet PhoneList

get_Name(): Stringset_Name(String n)get_Number(): Stringset_Number(String nr)get_leftNode():TreeNodeset_leftNode(TreeNode)get_rightNode():TreeNodeset_rightNode(TreeNode)

Mller 0511/97865

Huber 0241/12-4711

Schneider 762-19666

Schmidt 001-(303) 492

Khler 030/762-123

< left() > right()

BeispielInterfaces


Information Hiding: Interfaces!

add(String name, String number)get_Number(String name): Stringdelete(String name)

IPhoneBook

public void organize(){IPhoneBook ph; ph = new PhoneTree();

ph.add("May", "089/4567");nr=ph.get_Number("Khler");ph.delete("Huber");

}

JavaInterface

BeispielInterfaces

oder: PhoneList()oder: PhoneTable(7)Das ist der einzige Unterschied!


Aber wie ist es denn nun implementiert?

Programming to an Interface von zwei Seiten: Aufrufer und Anbieter verlassen sich darauf

BeispielInterfaces

add(String name, String number)get_Number(String name): Stringdelete(String name)

interfaceIPhoneBook

PhoneTable(int size)add(String name, String number)get_Number(String name): Stringdelete(String name)

PhoneTableadd(String name, String number)get_Number(String name): Stringdelete(String name)sortInverse()

PhoneTree

Wir wissen es nicht! Und wollen es nicht wissen!

implements Implementierer 3Implementierer 1

CMS ph

Aufrufer


Was zeigt das Beispiel

Abhngigkeiten zwischen Programmteilen entstehen leicht ndert sich eines, muss man das andere ndern

Aufwndig! Fehleranfllig!

Was fehlte, war ein klarer Bezugspunkt: Schnittstelle/Interface Zwischen Beteiligten ausgehandelt: Contract

Interfaces Sind syntaktische Einheit in Java

Abstrakte Klasse mit Methodenschnittstellen, ohne Rmpfe Im Aufrufer dennoch als Typ verwenden IPhoneBook Letztlich braucht man natrlich auch eine ImplementierungPhoneTree, PhoneList oder PhoneTable

Vorteile Nur Implementor-Name ist spezifisch im Aufrufer-Code Aufrufer braucht bei nderungen im Implementor nichts zu tun


Interface in Java definieren

Schlsselwort interface statt class

Methodenohne Rumpf


Interface in Java anbieten/implementieren

usw.

Als Liste implementieren

Spezialmethoden lieber private machen


Angebotene Methoden aufrufen

public void organize(){IPhoneBook ph; ph = new PhoneList();

ph.add("May", "089/4567");nr=ph.getNumber("Khler");ph.delete("Huber");

}

Methoden wie IPhoneBookImplementiert als PhoneList

Nutzerprogramm, wie CMS


Information Hiding Zusammenfassung

Trennung von Schnittstelle und Implementierung Schnittstelle muss ich kennen Implementierung lieber nicht (information hiding)

In Java: Spezielle Klassenkonstruktion

Ein Interface kann keine Instanzen haben Kann ja nichts tun, spezifiziert nur Etwas allgemeineres Konzept: Abstrakte Klasse

Implementor erbt alle Methoden der Schnittstelle berschreibt sie, d.h.: implementiert, was da passiert Kann zustzliche Methoden haben; die nutzt Aufrufer lieber nicht Nutzer bezieht sich nur auf das Interface

Vorteil von Programming to an Interface Beide Seiten knnen sich unabhngig ndern Probleme werden zerlegt


Beispiel aus dem Alltag: Info. Hiding

Volkswagen-Website, 14.11.04

Smart-Website, 14.11.04

Kommunikation nicht nur mit Rechnern Schnittstellen und APIs Prinzipien Kohsion und Kopplung Architektur und Entwurfsebenen Erfahrungen und Design Patterns Anforderungen Entwurf Codierung

Kapitel 3

EntwurfStrukturen und

nicht-funktionale Eigenschaften



Kommunikation ber groe Systeme

Worber kommunizieren? Auch ber zuknftigen Code Nicht zu viele Details Nur die Strukturen

Wozu kommunizieren? Zur Orientierung Zum Erklren Zur Arbeitsaufteilung Zur Diskussion Zur Dokumentation

Quellcode

Entwickler


Entwurf

Einem neuen Softwaresystem Struktur geben also: strukturieren, was es noch nicht gibt fr die vielen Entwickler, die es bauen sollen: Vorgabe nur Strukturen, Details meiden (info. Hiding)

Entwurf aufschreiben Oft mit graphischen Modellen (UML, folgt spter) berlegungen und Entscheidungen textuell erklren Zielgruppe: Entwickler Aufgabe: ohne Missverstndnisse in Code umsetzen

Ziele Code verschiedener Entwickler muss zusammenpassen Qualittsanforderungen strukturell untersttzen Entwicklung und Wartung eine Richtung geben Struktur auf Dauer verstndlich machen und dadurch erhalten


Zwischenziele des Entwurfs

Entwurfsideen kommunizieren Alternativen vergleichen und

diskutieren

Kreativitt nutzen, aber Ergebnisse sichern

Erfahrungen einflieen lassen

Weichen stellen, wohin der Entwicklungszug fhrt!


Entwurfsstufen

Top-Down Entwurf

Architektur/Grobentwurf: Bleibende Strukturen Feinentwurf: Strukturen und Schnittstellen Code: Ausfllen der Strukturen, Erfllen der Schnittstellen

Reifestufen der Entwurfsdokumentation Skizze an der Tafel Abgezeichnet in grafischer Notation (meist UML): Draft berarbeitet Freigegeben, verbindlich

berlegenswert Wird Entwurf aktualisiert oder weggeworfen? Wozu dient ein UML-Modell genau? Was tut man, wenn man bei Codierung Entwurfsmngel sieht?


Strukturen sind wichtiger als Details

Struktur legt Mglichkeiten fest Manches ist damit sehr einfach Anderes sehr schwer

Das muss zu den Anforderungen passen Leider kennt man die nicht immer Oder sie ndern sich

Es gibt kaum Patentrezepte Teile und Herrsche Kohsion und Kopplung Daher auch unterschiedliche Lsungsideen Um damit weiterzuarbeiten: Dokumentieren!

Struktur prgt Verhaltensmglichkeiten


Grundprinzip: Teile und herrsche

Man kann bei einem (groen) Programm nicht an alles gleichzeitig denken

Lsung: Probleme zerkleinern Ein groes Problem wird in mehrere kleinere zerlegt

Dann werden die kleinen rekursiv zerlegt Die noch kleineren werden gelst das ist einfacher! Die Lsungen werden zusammengesetzt

Von unten nach oben werden die Teile zusammengesetzt Bis man wieder auf der obersten Ebene ankommt

Damit sollte das groe Problem gelst sein

Folgt rmischem Prinzip: divide et impera! Was man erst einmal klein zerlegt hat, hat man im Griff Wie das rmische Reich oder ein groes Programm


Programmcode im Entwurf strukturieren

Evelynentwirft


Strukturierung durch Zerlegen

Schnittstelle:DurchtrennteVerbindung

Datenflu

Kontrollflu

Vorstellung desProgramms


Schnittstellen beschreiben

Was gehrt zu einer Schnittstellenbeschreibung?

Name der Funktion oder Methode Sichtbarkeit: von wem aufrufbar? Welcher Parametertyp Welcher Rckgabetyp

Zusatzinformationen Sinn der Schnittstelle:

wer nutzt sie fr welchen Zweck? Pre-/Postconditions ber Schnitt-Stellen kann man

verhandeln und sie ndern.

Schnittstelle:DurchtrennteVerbindung

Datenflu

Kontrollflu

Teilsysteme


Java-Signatur einer MethodeSchnittstellen-Beschreibung fr den Compiler

DEFINITION Die Signatur einer Java-Methode umfasst :=DefMethodennamen und Parametertypen

KOMPLIZIERT bei Generics (z.B. List)Two method or constructor declarations M and N have the same argument types if all of the following conditions hold:

Have same numbers of formal and of type parameters Let be the formal type parameters of M and let be the formal type parameters of N. After renaming each occurrence of a Bi in N's type to Ai the

bounds of corresponding type variables and the argument types of M and N are the same.

GENAUER Two methods have the same signature [ =Def ]if they have the same name and argument types:

Java Language Specification, 3rd Edition, 2005. Download: http://java.sun.com/docs/books/jls/

Alles, was Java wissen muss, um die Methode eindeutig zu identifizieren

ACHTUNG: nichtden Rckgabewert (trotz Wikipedia)


Aufruf-SchnittstelleSchnittstellen-Beschreibung fr den Verwender

public static double factorial (int x){double fact;...return fact;}

Allgemein: die Aufruf-Schnittstelle einer Java-Methode umfasst alles, was ein Aufrufer/Verwender wissen muss - und nichts mehr:

Modifiers type name (parameter-list) [throws exceptions]

Modifier:Sichtbarkeit

Modifier:Klasse/Instanz?

Typ desRckgabewerts

Name Parameter(-liste):je Typ, Name

Rckgabe eines Werts vom Rckgabewert-Typ

Dazu: ausgelste(geworfene)

Exceptions


API: Bedienungshandbuch mit ZusatzinfoKomfortable Schnittstellen-Beschreibung

Allgemein: Application Programming Interface (API) =Defeine dokumentierte Software-Schnittstelle, mit deren Hilfe ein Programm bestimmte Funktionen eines anderen Programms nutzen kann

Dokumentation

Was tut die Funktion?

Contract:Voraussetzungen?Zusicherungen?Worauf kann sich Nutzerverlassen?


Organisatorische Schnittstellen

Zwischen Auftraggeber und Auftragnehmer

Zwischen einer Business Unit und der anderen

Zwischen einem Team und dem anderen

Zwischen einzelnen Bearbeitern

Auftraggeber

SW-Auftragnehmer

Auch fr diese Schnittstellen gelten sinngemdie selben Regeln und Erfahrungen!


Zusammenfassung: Schnittstellen

Technische Schnittstellen sind exakt festzulegen Programmiersprachen-spezifisch (Signatur, Aufruf, API) Paketzugehrigkeit, Aufrufart usw. Schnittstellen-Beschreibungen beachten!

Organisatorische Schnittstellen so genau wie mglich Organisationseinheiten und Personen Aufgaben, Kompetenzen, Verantwortlichkeiten (AKV) Genaue Regeln bei der bergabe von einem zum anderen

Das reicht noch nicht: Zusatzinformationen nicht vergessen Sinn der Schnittstelle: wieso und wieso hier getrennt? Pre-/Postconditions Ergebnis der Schnittstellen-Verhandlungen


Gute Struktur anstreben1. Was ist die Struktur von Code?

import theTreePackage.TreeNode;public void organize(){PhoneTree ph;ph.add(new TreeNode(Lahm, 089/4567));nr=ph.search(Beckenbauer).get_Number();ph.delete(ph.search(Huber));

}

CMS verwendet PhoneTree

thisCMS

newTreeNode

phPhoneTree

Objekteu. Nachrichten Fazit:Es gibt nicht nur

eine Struktur

Methodenu. Aufrufe

CMS

TreeNode

PhoneTree

addsearchdelete

newget_Number


Gute Struktur anstreben2. Was ist gute Struktur?

Wollen wir groe oder kleine Einheiten?Viele oder wenige?Wir brauchen Kriterien fr gute Struktur!

Klassenu. Vererbung

Entry

HelperEntryCodeEntry

UsingHuffmannCode

HuffmanCode


Grade von Kohsion und Kopplung3. Die wichtigsten Strukturkriterien

Kohsion soll hoch sein Zufllig Logisch hnliche Operationen Zeitlich zusammengehrig (Init) Sequenziell nacheinander

auszufhrende Funktionen Um wichtige Funktion herum Informational

(um Daten gruppiert)

Kopplung soll niedrig sein

Beeinflusst lokale Daten anderer

Globale Daten

Beeinflusst fremden Kontrollfluss (flags sind bel!)

Explizite Daten-Parameter

Objekt-basiert/-orientiert Daten verborgen Methoden zugeordnet Instanzen von Klassen

besser-werdend


Kohsion und KopplungGleiches Prinzip auf verschiedenen Ebenen

A B C D

Programm-Einheit P1

P3P2

Datenelemente

Zugriff von berallauf alle (globalen) Daten

Programmeinheiten (Module, Klassen usw.)

Klasse X Klasse Y

A

B

C

D

Klassen mit Daten

Zugriff auf fremde Daten nur ber Methoden dort

Selbstaufrufemglich

Schlecht: Daten und Programme getrennt, hngen aber voneinander ab

Besser: Objekt-Orientierung


Kohsion und KopplungGleiches Prinzip auf verschiedenen Ebenen

Klasse X Klasse Y

A

B

C

D

Klassen mit Daten

Zugriff auf fremde Daten nur ber Methoden dort

Selbstaufrufemglich

Aber hier noch nicht gut: Stark gekoppelte Klassen, wenig innere Kohsion

Besser: innen starker Zusammenhalt, wenig zwischen den Klassen

Klasse X Klasse Y

A

C

B

D

Klassen mit Daten

Weniger Abstimmungsbedarf

Innen starkerZusammenhalt


Auch auf grberem Granulat Hohe Kohsion, niedrige Kopplung anstreben

GUI

Bank

DB

Konto Kredit

BrgschaftIntro

KontoVerwaltung

Werbung

Oracle

Access

Pakete (Packages)darin: Klassen

Dazwischen: irgendeine Verwendung


Weitere Entwurfsregelngenauer hingesehen

Fr schwache Kopplung Wenige Schnittstellen: nicht viele Verbindungen Kleine Schnittstellen: wenig Informationen austauschen (Wenig Interaktion ber Schnittstellen) das ist nicht so wichtig!

Klare Verhltnisse schaffen Nur explizite Schnittstellen, keine impliziten Nebenwirkungen Dokumentieren, ob sich Einheit noch ndert (Stabilitt der Schnittstellen)


Weitere Entwurfsregelngenauer hingesehen

Once and only once: Keine Doppelungen Algorithmen doppelt Daten doppelt gehalten Struktur dupliziertFhren zu Inkonsistenzen und nderungsanomalien

Kognitive Grenzen beachten Nutzer der Schnittstellen soll mglichst wenig wissen-mssen Interna geheimhalten und verstecken Struktur des Systems begrnden und dokumentieren:

Hinweis auf hnliche Strukturen im Anwendungsfeld Hinweis auf hnliche Teamstruktur (schlechter, da vergnglich) Oder andere, explizit genannte Grnde


Architekturdie Lehre von der Struktur(-ierung)

SW-Architektur beschftigt sich mit Abstraktion, mit Zerlegung und Zusammenbau, mit Stil und sthetik. (Kruchten 95)

Architektur Legt grobe Struktur fest Liefert den Bauplan

bergang von Analyse zur Realisierung Verwendet verschiedene Sichten Abstrahiert Erklrt Systemaufbau

Schliet und begrndet Komromisse

Siehe: Starke, G. (2002): Effektive Software-Architekturen. Carl Hanser Verlag


Grundlegende Architekturen

Datenfluss-Systeme Batch Pipes and filters

Call-and-return Systeme Haupt- und Unterprogramme OO Systeme Hierarchische Schichten

Unabhngige Komponenten Kommunizierende Prozesse Event-getriebene Systeme

Virtuelle Maschinen Interpreter Regel-basierte Systeme

Repository-Systeme DB, Hypertext, Blackboards


Schichten-Architekturen

Monolithisches System

Anwendung

DBInfrastruktur

2-Schichten/2-Tier

Anwendung (mit GUI)

DBInfrastruktur

Geschftslogik

3-Schichten/3-Tier

Externes Schema

KonzeptuellesSchema

Internes Schema

System-Infrastruktur

Gemeinsame Datenbank

Netzwerk

Vgl.: Zuser et al. (2004): Software Engineering mit UML und dem Unified Process. Pearson Studium


Praxis-ZusammenfassungSchichten-Architektur und Pakete

Erstellen Sie je ein Paket (in Java: Package) fr jeden Aspekt. Stecken Sie Module, Klassen usw. in diese Pakete, sortiert nach den

Aspekten. Die Pakete sollen sich nur sparsam gegenseitig aufrufen und

dabei die mittlere Schicht nicht berspringen. Jedes Paket kann rekursiv weitere enthalten:

entweder feinere Schichten oder Groe Ansammlungen von Code, die man noch aufteilt.

Vorteile Sie knnen gezielt auf einen Aspekt zugreifen, ohne andere anzufassen. Sie brauchen (fast) nichts ber die anderen zu wissen (Information Hiding)

Min. 2Aspekte?

3Schichten

Paketezu gro?

Rekursivverfeinern

Paketstruktur

Architektur finden

N

J

J

N

WENN mindestens zwei der folgenden Aspekte vorkommen: GUI Nicht-triviale Logik Datenverwaltung/Verteilung

DANN verwenden Sie eine Drei-Schichten-Architektur!


Architekturen fr verteilte Systeme

Master-Slave

Client-Server

Peer-to-Peer

Historie der UML Objektorientierung: Konzepte und Denkweise Klassendiagramme Sequenz- und Kollaborationsdiagramme Weitere Diagrammarten

Kapitel 4

Entwrfe notieren: UMLModelle im Software Engineering



Wozu grafische Notation (2D)?

Grafische Notation := 2-dimensionale Syntax +Semantik +Pragmatik

Modelltheorie Irrelevante Details ausblenden Relevante Eigenschaften hervorheben

Abundante Eigenschaften gnstig gestalten Leicht zu verstehen Leicht zu ndern Menschlicher Kognition entgegenkommen: Patterns, 2D >> 1D (Text)

Spektrum von Formalittsgraden Mehr oder weniger viele relevante Eigenschaften Anfangs wenige, Grobstruktur schnell erstellen Schritt fr Schritt mehr, Detail ausfeilen, nher zum Code


Was ist UML?Unified Modeling Language

Sammlung vorwiegend grafischer Sprachen [ mehrere! ] zur Erstellung von Anforderungs- und Entwurfsmodellen aus verschiedenen Perspektiven

UML-Spezifikation oder UML-Modell =DefSammlung von UML-Diagrammen, die sich inhaltlich ergnzen und berlappen

Klassenmodell spezifiziert strukturellen Aufbau des Systems Bei Anforderungen zeigt es folgende relevante Originalaspekte:

Gegenstnde der Realitt, mit denen das System umgehen muss

Bei Entwurf und Implementierung zeigt es: Klassen der Lsung


Klassen und Objekte: Eine DenkweiseGenauer hingesehen

Eine Klasse ist die gemeinsame Beschreibung des Verhaltens und der Attribute

aller Objekte dieser Klasse

Objekte sind verschiedene Individuen haben je eigenen Zustand zeigen Verhalten:

sie versenden Nachrichten und reagieren auf Nachrichten anderer Objekte

Klasse beschreibt: Verhaltensmuster Attribute pro Objekt Bezeichner

Jedes Objekt hat Dieselben Bezeichner Evtl. verschiedene Zustnde Evtl. verschiedene Attributwerte

Folglich evtl. verschiedene Situationenim selben Verhaltensmuster


Interaktionssicht

UML Diagramme

Zustands-diagramm

Verhaltenssicht:Innere Zustndeund Verhalten

der Objekteeiner Klasse

Aktivitts-diagramm

Aktivittssicht:Gemeinsame

Bearbeitung einerAufgabe

Sequenz-diagrammZusammenspiel

weniger Objekte

Use Case DiagrammBenutzersicht: Interaktion von Benutzern mit dem System

Kollaborations-diagrammZusammenspielvieler Objekte

Verteilungsdiagramm Physische Sicht: Physische Systemstruktur und Verteilung

Paketdiagramm Gliederungssicht: Aufteilung in Pakete und Substrukturen

KlassendiagrammStatische Sicht:

Beteiligte Klassen und Strukturen


Ein UML ModellBeispiel fr ein Klassendiagramm

Martin Glinz (2002): Vorlesung Requirements Engineering Grundlagen und berblick, Universitt Zrich


Historie: Merger von Methoden

Diagramm von Prof. H. Lichter, RWTH Aachen: Vorlesung Softwareentwicklung, SS 2003, aktualisiert

die drei Amigos

heute UML V2.3 (V2.x) Strkere Formalisierung; Profile zur Erweiterung


UML-Diagramme bearbeiten

Mein Tipp: Malen Sie erst von Hand Danach holen Sie sich ein Werkzeug Fr diese Vorlesung: StarUML (open source, kostenlos)

Download: http://sourceforge.net/projects/staruml (letzter Zugriff: 30.10.2011) StarUML ist nicht hypermodern, aber leicht zu handhaben Viele andere Werkzeuge sind fr unsere Zwecke weniger geeignet

Wozu Sie StarUML verwenden sollten Nach einer Handskizze: Diagramme sauber abzeichnen Speichern, Datei im Team verteilen und verwenden ndern und aktualisieren

Generieren, C# usw.? Es geht noch viel mehr mit StarUML und hnlichen Werkzeugen Das brauchen Sie in SWT noch nicht


KlassenBasisvarianten

BedeutungKlassennameKeine Attribute def.Operationen auch nicht

Verwendungshinweise

Kann Stck fr Stckvervollstndigt werden

Mssen nicht Java-konform sein

() ist Konvention fr Operation,

nicht nur in Java

Dies sind die Minimalangaben

Oft zuerst die Operationenfestlegen: Attribute zweitrangig

Konto

Konto

kontoNrkontostandkreditRahmenverschluesseltePIN

erzeugeKontoNr()verschluesslePIN()getKontoStand()einzahlen()abheben()ueberweisen()istPINkorrekt()setInhaber()getInhaber()setKreditRahmen()getKreditRahmen()

Konto

kontoNrkontostandkreditRahmenverschluesseltePINAttributnamen

Operationsnamen


Konto

+kontoNr: int-kontostand: EURO-kreditRahmen: EURO~verschluesseltePIN: SecretPINtype

+erzeugeKontoNr()+verschluesslePIN(pin)+getKontoStand()+einzahlen(betrag: EURO)+abheben(betrag: EURO)+ueberweisen(betrag: EURO, zielkonto: Konto)-istPINkorrekt(pin)+setInhaber(name: String)+getInhaber()+setKreditRahmen(kreditObergrenze: EURO)+getKreditRahmen()

Klassenfortgeschrittene Angaben

Bedeutung

KlassennameAttribute mit Typen

Sichtbarkeit+ public- private~ package# protected

OperationenSichtbarkeitParameter

mit und ohne Typ

Verwendungshinweise

Kann Stck fr Stckvervollstndigt werden

Man kann Sichtbarkeit auch zunchst offen lassen

Ebenso: ParametertypenViele Tools dulden das nicht:

alle oder keine Sichtbarkeiten

Mglichst wenige Getter und Setter

Nicht fr alle AttributeEvtl. im Modell ausblenden

Hintergrundfarbe wei

Farbe, Schatten, 3D vermeiden!


Klassenund entsprechender Code

UML-Modell

Konto

kontoNrkontostandkreditRahmenverschluesseltePIN

erzeugeKontoNr()verschluesslePIN()getKontoStand()einzahlen()abheben()ueberweisen()istPINkorrekt()setInhaber()getInhaber()setKreditRahmen()getKreditRahmen()

public class Konto {public int kontoNr;private EURO kontostand;private EURO kreditRahmen;public SecretPINtype verschluesseltePIN;public int erzeugeKontoNr() { }public SecretPINtype verschluesslePIN

(int pin) { }public EURO getKontoStand() { }public void einzahlen(EURO betrag) { }public EURO abheben(EURO betrag) { }public void ueberweisen

(EURO betrag, Konto zielkonto) { }private boolean istPINkorrekt

(Object pin){}public void setInhaber(String name) { }public String getInhaber() { }public void setKreditRahmen

(EURO kreditObergrenze) { }public EURO getKreditRahmen() { }

}

Java#if !defined(_KONTO_H)#define _KONTO_H

#include "Kunde.h"

class Konto {public:

int kontoNr;int erzeugeKontoNr();SecretPINtype verschluesslePIN(int pin);EURO getKontoStand();void einzahlen(EURO betrag);EURO abheben(EURO betrag);void ueberweisen

(EURO betrag, Konto zielkonto);void setInhaber(String name);String getInhaber();void setKreditRahmen

(EURO kreditObergrenze);EURO getKreditRahmen();

private:EURO kontostand;EURO kreditRahmen;boolean istPINkorrekt(int pin);

};

C++(Konto.h)


Interfaces

PhoneTree

+add(name, number: String)+get_Number(name: String)+delete(name: String)-sortInverse()

PhoneTable

+PhoneTable(size: int)+add(name, number: String)+get_Number(name: String)+delete(name: String)

IPhoneBook

CMS

+organize()

benutzt einInterface

Interface-Symbol(nur dessen Name ist sichtbar)

realisieren das Interface

IPhoneBook

+add(name, number)

Kompromiss in StarUML:Abstrakte Klasse

ACHTUNGgehen berdas Interfacehinaus!

IPhoneBook

+add(name, number)

Oder besser(geht leidernicht in StarUML)


Konto


+erzeugeKontoNr()+verschluesslePIN()+getKontoStand()+einzahlen()+abheben()+ueberweisen()-istPINkorrekt()+setInhaber()+getInhaber()+setKreditRahmen()+getKreditRahmen()

Schlerkonto

+zinssatz

kreditRahmen= 0

Bankomat

-istPINkorrekt()+kontostandAnzeigen()+abheben()

+arbeitsKonto+bedienstation 0..1

0..1

ecKarte

+kontoNr: int-verschlsseltePIN: SecretPINtype

+setPIN()+getPIN()+verbucheAbhebung()

+eingeleseneKarte0..1

1

Kunde

+Name

+inhaber

1..*

1..3

1

1..*

+besitzt

11..*

Kundenerfassung

+erffneKonto()+erfrageNamen()+erfrageAusweisNummer()

+neueKonten

*

1

Prfbehrde

+vermerkeNeuesKonto()+getKreditwrdigkeit()

+schufa

1

GUI

+getPIN()~gebeGeldFrei()

Beziehungen zwischen KlassenAssoziationen

Kommentar

Vererbung

Multiplizitten

Benannte Assoziationsenden

bedient

Leserichtung

ist-geffnet-in


Interaktion in SequenzdiagrammenSequenzdiagramm 1: Konto anlegen

erffneKonto()

:Kundenerfassung

new():Konto

kontoNr

erzeugeKontoNr()

kontoNr

erfrageAusweisNummer()

setKreditrahmen()

erfrageWunschPIN()

verschlsslePIN()

erfrageNamen()

setInhaber()

Schufa

getKreditwrdigkeit()

meldeNeuesKonto()


Interaktion in SequenzdiagrammenBedeutung der Symbole

erffneKonto()

:Kundenerfassung

new():Konto

kontoNr

erzeugeKontoNr()

kontoNr

erfrageAusweisNummer()

setKreditrahmen()

erfrageWunschPIN()

verschlsslePIN()

erfrageNamen()

setInhaber()

Schufa

getKreditwrdigkeit()

meldeNeuesKonto()

Das Ganze ist eineInteraktion, nicht jede Nachricht fr sich!

new() erzeugt ein Objekt Objekte

Nachrichten

Antwort

Selbstaufruf

Lebenslinie

Aktivierung

Objektname(auch Objektname:Klasse)Anonym, nur

:Klassenangabe


Interaktion als SequenzdiagrammSequenzdiagramm 2: Geld abheben am Bankomaten

:GUI :Bankomat :ec-Karte :Konto

istPINkorrekt(PIN)

getKreditRahmen()

getKontoStand()

abheben (wunschBetrag)

getPIN()

verschlsseltePINgetPIN()

PIN

gebeGeldFrei (verfgbarerBetrag)

verbucheAbhebung()


verfgbarerBetrag

Kommentar(in allen Diagrammen erlaubt)

verfgbarerBetrag = min( wunschBetrag,

kontoStand+kreditRahmen)


Interaktion als KollaborationsdiagrammGeld abheben am Bankomaten, andere Modellart

:GUI:Bankomat

myCard:ecKarte

:Konto

2.1: getPIN()2.2: getPIN()

1: abheben() 2: abheben() 2.3: istPINkorrekt()

2.4: abheben()

2.4.1: getKontoStand() 2.4.2: getKreditRahmen()

2.5: verbuche-Abhebung()

2.6: gebeGeldFrei()


Interaktion als KollaborationsdiagrammGeld abheben am Bankomaten, andere Modellart

:GUI:Bankomat

myCard:ecKarte

:Konto



2.4: abheben()



2.6: gebeGeldFrei()

Objekte

Objekte Objekte (Namenskonventionen wie blich)

Auslser Nachrichten mitReihenfolgeUnter-Reihenfolgen inPunkt-Notation (2.3)

Unter-Reihenfolgen,tiefer verschachtelt (2.4.1)

quivalent zu Sequenzdiagramm

Unterschiede nur in den semantischnicht-relevanten Modelleigenschaften.Fr Handhabung jedoch wichtig.


Konto



Schlerkonto

+zinssatz

kreditRahmen= 0

Bankomat



0..1

ecKarte




1

Kunde

+Name

+inhaber

1..*

1..3

1

1..*

+besitzt

11..*

Kundenerfassung

+erffneKonto()+erfrageNamen()+erfrageAusweisNummer()+erfrageWunschPIN()

+neueKonten

*

1Prfbehrde


+schufa

1

GUI


Klassendiagramm aktualisierenErkenntnisse aus Interaktionssicht einarbeiten


Klassendiagramm aktualisierenErkenntnisse aus Interaktionssicht einarbeiten

Konto



Schlerkonto

+zinssatz

kreditRahmen= 0

Bankomat



0..1

ecKarte




1

Kunde

+Name

+inhaber

1..*

1..3

1

1..*

+besitzt

11..*

Kundenerfassung

+erffneKonto()+erfrageNamen()+erfrageAusweisNummer()+erfrageWunschPIN()

+neueKonten

*

1Prfbehrde


+schufa

1

GUI


5


Methode im ZusammenhangModelle fr Statik und fr Dynamik

Konto



Schlerkonto

+zinssatz

kreditRahmen= 0

Bankomat



0..1

ecKarte




1

Kunde

+Name

+inhaber

1..*

1..3

1

1..*

+besitzt

11..*

Kundenerfassung

+erffneKonto()+erfrageNamen()+erfrageAusweisNummer()

+neueKonten

*

1

Prfbehrde


+schufa

1

GUI


Ein Klassendiagramm: Basis und Statische Aspekte


istPINkorrekt(PIN)

getKreditRahmen()

getKontoStand()


getPIN()

verschlsseltePIN

getPIN()

PIN


verbucheAbhebung()


verfgbarerBetrag

Viele Diagramme fr Dynamik

+

= das UML-Modell

:GUI

:Bankomat

myCard:ecKarte

:Konto



2.4: abheben()



2.6: gebeGeldFrei()

Kollaborationsdiag. Sequenzdiag.und andere


Kleine Variationen durch Tooleinsatz Beispiel: Sequenzdiagramm in StarUML

:GUI :Bankomat :ec-Karte gehaltskonto : Konto

1 : abheben()2 : getPIN()

3 : verschlsseltePIN4 : getPIN()

5 : PIN

6 : istPINkorrekt()

7 : abheben()

8 : getKontoStand()

9 : getKreditRahmen()

10 : verfgbarerBetrag

11 : verbucheAbhebung()

12 : gebeGeldFrei()

Nummerierung automatisch

Gelber Hintergrund(abschaltbar)

Stapel von Aktivittsboxen

Objektname mit : nur durch Tricksen


Code entspricht Sequenzdiagramm:GUI :Bankomat :ec-Karte :Konto

istPINkorrekt (eingegebenePIN, verschlsseltePIN)

getKreditRahmen()

getKontoStand()


getPIN()


PIN


verbucheAbhebung()


verfgbarerBetrag

Pseudocode einer Methode des Bankomaten// Variablen seien vorbelegtpublic void abheben (EURO wunschbetrag) {

verschlsseltePIN = meineKarte.getPIN();eingegebenePIN = dieGUI.getPIN();if (istPINkorrekt(eingegebenePIN, verschlsseltePIN) {

verfgbarerBetrag = arbeitsKonto.abheben(wunschBetrag);meineKarte.verbucheAbhebung(verfgbarerBetrag);dieGUI.gebeGeldFrei(verfgbarerBetrag);

}}


Aufbau und Verhalten von Klassenaus mehreren Diagrammen ableiten

Ein Klassendiagramm: Basis und Statische Aspekte


istPINkorrekt(PIN)

getKreditRahmen()

getKontoStand()


getPIN()


PIN


verbucheAbhebung()


verfgbarerBetrag

Viele Diagramme fr Dynamik

:GUI

:Bankomat

myCard:ecKarte

:Konto



2.4: abheben()

2.4.1: getKontoStand()2.4.1: getKreditRahmen()


2.6: gebeGeldFrei()

Kollaborationsdiag. Sequenzdiag. und andere

Bankomat


Code

Klassen, Attribute, Methoden-Schnittstellen (Parameter, Typen)

Teile von Methodenrmpfenmehrerer Klassen

Methodenrmpfe


Konsistenz von Diagrammen

Ein UML-Modell ist auf mehrere UML-Diagramme verteilt

In der Regel verschiedene relevante Aspekte betont

berlappungen mssen konsistent sein Objekte passen zu Klassen aus dem Klassendiagramm Sichtbarkeiten, Parameter und Typen sind konsistent dargestellt Methodennamen in Sequenzen passen zu Klassendiagramm Use Case Modelle (kommen noch) passen zu Interaktionspersp. Verschiedene Interaktionsdiagramme widersprechen sich nicht

Zweck aller Diagramme in einem Modell Konsistente Darstellung aller relevanten, interessanten Aspekte Genau genug fr Programmierung Mglicherweise sogar fr (teilweise oder vollstnd.) Generierung


Wnde

Weitere BeispieleComputer - Ballspiel

Blast thru Special Edition. rockSolid Software ca. 2002

WandSchlgerBoden

Ball

Steine


Klassen-Diagramm des Spiele-Beispiels

Steinpunktewert

istGetroffen ()

Wand

istGetroffen ()

Spielhindernisse, ballscore, level

start (), stop ()nextLevel ()

Schlgerbreiteelastizitt

istGetroffen ()

Ballposition, winkelgeschwindigkeit

fliegt-los ()fliegt ()trifft (Hindernis)verschwindet ()

Hindernispositiongroesse

istGetroffen ()

Msste Ball nicht auch ein Hindernis sein? Sonst prallen

Blle nicht aneinander ab.

Entwurf: zwischen Anforderungenund Entscheidungen


KollaborationsdiagrammeInteraktion mehrerer Objekte in UML

Allgemein

1:

[Bedingung] : antw := nachricht()

NachrichtenPfeile mgl. waag-/senkrechtBedingung mglichAntwort mglich (Rckgabe): 1, 1.1, 1.2, 1.1.1

::

.*:

Mehrfach (an alle)An doppeltes Klassenrechteck: 1, 1.1, 1.2, 1.1.1 ,Jedoch mit * als letzte Stelle

Beispiel

meinSpiel:Ballspiel

:Ball

::Hindernis

1: start()

1.2: fliegt ()

1.2.1*: treffer :=istGetroffen()

punktestand:Score

1.2.2: aktualisien ()

initLevel:Level1.1: aufbauen ()

Objekte (Alternativen)ObjektsymbolKlassenrechteck:

:

Benutzer (Mnnchen)


SequenzdiagrammeInteraktion von (wenigen) Objekten in UML

Allgemein

ObjekteUnterstrichenerObjektname oder:Klassenname

Objekt1

Lebenslinie des Objekts

: KonstruktionObjekt der Klassewird erzeugt

new()

AblaufWaagrecht oderschrg (Zeit vergeht)

()

DestruktionObjektwird zerstrt

delete()

Selbstaufruf()

Beispiel: Ausschnitt

myGame

:Ballnew()

shoot()

score

delete()

flies()

:Hindernis

hits()

score-or-0

delete()

updateScore()


Fugngerberweg als SequenzdiagrammeInteraktion weniger Objekte

Beispiel: Kreuzung

KnopfAnforderung

fussgaengerAnforderung

:Fugngerampel :berweg :Autoampel

stop

gelb

rotstehen

3 s

rotgelb

grnfahren

go

5 s

go

4 s

30 s

10 s

stop

Zeitangabenund Klammern sind UML-Kommentare,nur fr Menschen bedeutungsvoll.

Dieser Text ebenso.


Zustandsdiagramme/StatechartsVerhalten einzelner Objekte in UML

Allgemein

/[]

[]

Transitionen Von Zustand zu ZustandAber nur,

SWT WS1213 Folien v21

Documents

Transcript of SWT WS1213 Folien v21