94
Software Engineering Studiengang Betriebsinformatik Sommersemester 2010 Vorlesung : 4 Veranst. á 2 DS = 16 Unterrichtsstunden Praktikum : 1 Veranst. á 2 DS = 4 Unterrichtsstunden

Software Engineering

  • Upload
    lamya

  • View
    22

  • Download
    0

Embed Size (px)

DESCRIPTION

Software Engineering. Studiengang Betriebsinformatik Sommersemester 2010. Vorlesung : 4 Veranst. á 2 DS= 16 Unterrichtsstunden Praktikum : 1 Veranst. á 2 DS = 4 Unterrichtsstunden. Inhalt. Einführung: Ziele und Arbeitsmethoden der Softwaretechnologie - PowerPoint PPT Presentation

Citation preview

Page 1: Software Engineering

Software Engineering

Studiengang Betriebsinformatik

Sommersemester 2010

Vorlesung : 4 Veranst. á 2 DS = 16 Unterrichtsstunden Praktikum : 1 Veranst. á 2 DS = 4 Unterrichtsstunden

Page 2: Software Engineering

Inhalt

1. Einführung: Ziele und Arbeitsmethoden der Softwaretechnologie

2. Objektorientierte Modellierung

Unified Modeling Language (UML 2)

3. Implementation von UML-Modellen

4. Systemarchitekturen

5. Der Software-Entwicklungsprozess

6. Wiederverwendung

Page 3: Software Engineering

Literatur

H. Balzert: Lehrbuch der Objektmodellierung. Analyse und Entwurf mit der UML 2.Spektrum Akademischer Verlag, 2004

M. Fowler, K. Scott: UML konzentriert. Eine Einführung in die Standard-Objektmodellierungssprache.

Addison-Wesley, 2. Aufl., 2000

C. Rupp, S. Queins, B. Zengler:UML 2 glasklar, Praxiswissen für die UML-ModellierungCarl Hanser Verlag, 3. Aufl., 2007

W. Pree: Komponentenbasierte Softwareentwicklung mit Frameworks.dpunkt.verlag, 1997

I. Sommerville: Software Engineering.Addison-Wesley, 8. Aufl. 2007

Rational Software Corporation Homepage: http://www-01.ibm.com/software/rational/

Page 4: Software Engineering

11 Einführung: Ziele und Arbeitsmethoden der Einführung: Ziele und Arbeitsmethoden der SoftwaretechnologieSoftwaretechnologie

• Softwareproduktion

• Lebenszyklusmodelle

• Methodologie → Objekttechnologie

• von Algorithmen zu Domänen

Page 5: Software Engineering

offen für Fragestellungen

• „Große Systeme“: Entwicklergruppen über längere Zeit

• Personen (Nutzer) agieren in Rollen

• Entwicklung endet nicht mit der 1. Systemversion: Erweiterung und Anpassung („Wartung“)

• Wiederverwendung beginnt nicht erst mit der eigenen Entwicklung

• Bestimmte Entwicklungsmethoden führen zu bestimmten Software-Architekturen

• Entwicklungsmethoden bedürfen einer rechentechnischen Unterstützung : CASE

• Zweckbindung -> Musterarchitekturen

Page 6: Software Engineering

Phasen im Softwareentwicklungsprozess:

Analyse Anforderungsanalyse (Pflichtenheft)AnwendungsfallanalyseProblembereichsanalyse (Geschäftsklassen)

Entwurf Softwareentwurf (Geschäftsklassen + Fachklassen)AlgorithmenentwurfKomponenten-/Systementwurf

Implementation Programmierung, weitestgehende Generierung

Test Unittest, Integrationstest, Systemtest→ möglichst entwicklungsbegleitend

Page 7: Software Engineering

Lebenszyklusmodelle:

Page 8: Software Engineering
Page 9: Software Engineering

Die Unified Modeling Language

( G. Booch, J. Rumbough, I. Jacobson )

► Diagramme visualisieren Ausschnitte aus bzw. Sichten auf Modelle

– Diagrammtypen

– Modelltypen

– Eine grafische Sprache

– Metamodellierung

Page 10: Software Engineering

Diagrammtypen:

• Use-Case-Diagramm (use case diagram)• Klassenstruktur-Diagramm (static structure diagram)• Sequenz-Diagramm (sequence diagram)• Kommunikations-Diagramm (communication diagram)• Zustands-Diagramm (statechart diagram)• Aktivitäten-Diagramm (activity diagram)• Komponenten-Diagramm (component diagram)• Verteilungs-Diagramm (deployment diagram)

Modelltypen:

• Use-Case-Modell• Klassenstrukturmodell• Interaktionsmodell (Sequenz- u. Kommunikations-Diagramm)• Zustandsmodell (Zustands- u. Aktivitäten-Diagramm)• Komponentenmodell• Verteilungsmodell

Page 11: Software Engineering
Page 12: Software Engineering

Metamodellierung

► Die UML ist eine grafische formale Sprache

=> Syntax + Semantik

► Die Definition einer formalen Sprache erfolgt mit den Mitteln einer (formalen) Sprache

=> Metasprache zur Definition einer Objektsprache

Bsp.: EBNF zur Definition der Syntax von Programmiersprachen

► UML zur Modellierung von UML-Konzepten

=> Metamodelle

Page 13: Software Engineering

22 ObjektorientierteObjektorientierte ModellierungModellierung

• Klassen-Instanzen-Abstraktion• Attribute und Operationen• Sichtbarkeit und Lebensdauer• Assoziationen und Verknüpfungen• Aggregation und Komposition• Generalisierung und Spezialisierung• Vererbung und Delegation• Polymorphie• Abstrakte und konkrete Klassen• Instanzen als Laufzeitobjekte• Statechart-Modelle• Aktivitäten-Diagramme

Page 14: Software Engineering

Klassen-Instanzen-Abstraktion

Objekt ist ein (abstrakter) Gegenstand oder ein Konzept mit klarer Abgrenzung und präziser Bedeutung.

Beispiele: Kommissar Rex, das Fenster links oben im Haus, Herr Lutze, Mediatec GmbH, ein bestimmter Button auf der GUI des Finanzprogrammes, ...

Klasse umfasst eine Menge von Objekten, die

• ähnliche Struktur und ähnliche Merkmale (Attribute) besitzen,• ähnliches Verhalten zeigen (Operationen bzw. „Methoden“),• in Relationen zu Objekten anderer Klassen oder der gleichen Klasse stehen.

Eine Klasse kann durch Aufzählung der Objekte oder durch die Definition der Eigenschaften der Objekte (Klassendefinition) beschrieben werden.

Zu einer Klasse gehörige Objekte werden als Instanzen, Instanzobjekte oder auch Exemplare der Klasse bezeichnet. Klassen werden benannt.

Beispiele: Hund, Fenster, Person, Firma, Button, ...

Page 15: Software Engineering

Objekte

• sind immer Instanzen einer bestimmten Klasse und • besitzen eine Identität und eine Lebensdauer.

Jedes Objekt kennt die Klasse, zu der es gehört.

Die Identifizierung und Benennung von Objekten hilft, die zu modellierende Welt zu verstehen. Objekte sind Ausgangspunkt für Implementierungen auf Computern.

Eine Klassendefinition umfasst (evtl. implizit) eine Vorschrift zur Erzeugung von Instanzen („Konstruktor“).

Klassenbildung ist Abstraktion

( bei einer Abstraktion werden unwesentliche Eigenschaften weggelassen; sprich: es wird von unwesentlichen Eigenschaften abstrahiert ).

Abstraktion ist ein mächtiges Mittel zur Bewältigung von Komplexität.

Art und Weise der Zerlegung eines Problems bzw. einer Domäne in Klassen/Objekte ist subjektiv

Page 16: Software Engineering

Beispiel:

Max:Person

Moritz:Person

Person

name:stringvorname:stringgeschlecht:chargeburtsjahr:int

+alter:int

Attribut : Merkmal mit einer Ausprägung (Datenwert) Jedes Attribut besitzt einen Wert aus dem Wertebereich für jedes Objekt. Jedes Objekt einer Klasse kann für dasselbe Attribut zum selben Zeitpunkt einen anderen Wert besitzen -> „Instanzvariable“

Operation : Funktion, die auf Objekte einer Klasse angewendet werden kann. Alle Objekte einer Klasse haben die gleichen Operationen. Implementierung der Operation in Programmiersprache -> „Methode“

Attribute und Operationen

Page 17: Software Engineering

• Die Gesamtheit der Werte (d.h. der Ausprägungen) aller Attribute eines Instanzobjektes bestimmt den Zustand des Objekts zu einem bestimmten Zeitpunkt.

• In Operationen kann auf Werte von Attributen zugegriffen werden. Das Verhalten eines Objekts wird durch seinen Zustand mit bestimmt (im Unterschied zu einer Prozedur).

• Die Verhaltensbeschreibung existiert unabhängig von der Anzahl vorhandener Instanzen je Klasse nur einmal und ist der Klasse zugeordnet.

Page 18: Software Engineering

Klassendiagramme (eigentlich: Klassenstrukturdiagramme)

Klassen

klassenname

[visibility] attributname : datentypname [ = default-wert ]

[visibility] operationsname ( argumentliste ) : ergebnistypname

formale grafische Notation für die Modellierung von Objekten, Klassen und Relationen,wird durch Entwicklungswerkzeuge unterstützt.

Page 19: Software Engineering

Instanzen

[ instanzname ] : klassenname

attributname = wert…

Instanziierungsrelation

klassenname

[instanzname] : klassenname

Klassen- u. Instanzensymbole können bei manchen Werkzeugen innerhalb eines Klassendiagramms verwendet werden.

Page 20: Software Engineering

Max:Person

Moritz:Person

Person

name:stringvorname:stringgeschlecht:chargeburtsjahr:int

+alter:int

Unterscheiden: → Wert einer Instanzvariablen name→ Name (Benennung) eines Objekts, z.B. Moritz

Page 21: Software Engineering

Sichtbarkeit und Lebensdauer

► Konstruktoren sind spezielle Operationen zur Erzeugung von Objekten. Objekte

existieren solange, solange sie referenzierbar sind bzw. bis sie explizit aus der Objektwelt entfernt werden (durch Destruktoren).

► Durch Benennungen werden Objekten Namen (in einer Umgebung) zugeordnet.

► Objekte besitzen einen zeitlich veränderlichen Zustand-> bestimmt durch die Werte aller Instanzvariablen (Ausprägungen aller Attribute)

► Sichtbarkeit (visibility) für Attribute und Operationen:

+ public von überall sichtbar

# protected nur eigene Klasse und abgeleitete (spezialisierte) Klassen

- private nur eigene Klasse

~ (oder keine Angabe) package wide nur Klassen innerhalb eines Packages

Page 22: Software Engineering

Unterscheidung:

instance scope -> „Instanzvariablen“, „Methoden“

class scope -> „Klassenvariablen“, „Klassenmethoden“(Syntax: Name und Typ werden unterstrichen)

Page 23: Software Engineering

Assoziationen und Verknüpfungen

Assoziation: abstrakte, nicht näher charakterisierte Beziehung zwischen zwei (binäre A.) oder

mehr (ternäre A. bzw. Assoziation höherer Ordnung) Klassen.

Notation: binäre Ass.: Linie, die zwei Klassensymbole verbindet.

A. höherer Ordn.: Rhombus, der durch Linien mit den

Klassensymbolen verbunden ist.

Beispiel:

Page 24: Software Engineering

Verknüpfung: Element einer Assoziation. Setzt eine Anzahl von Objekten ( „Link“ ) in Beziehung

Page 25: Software Engineering

Ein Pfad einer Assoziation kann an jedem Ende eine Beschriftung tragen.Arten der Beschriftung (Auswahl):

Multiplizität untere_grenze .. obere_grenze

0 .. *

Ordnung geordnete Elemente werden durch {ordered} spezifiziert

Rollenname spezifiziert die Rolle, die die Klasse am Ende des Pfades spielt

Aggregationsindikator hohler/ausgefüllter Rhombus

Page 26: Software Engineering
Page 27: Software Engineering

Aggregation und Komposition

Aggregation: bezeichnet die „Teil-Ganzes“-Relation

(„ist Teil von“ bzw. „besteht aus“)

Objekte, die die Komponenten einer Sache repräsentieren, sind mit einem Objekt verknüpft,

das die Komponentengruppe repräsentiert.

Notation:

Ein Objekt der Klasse1 repräsentiert die Komponentengruppe, Objekte der Klasse2 repräsentieren die Komponenten

Page 28: Software Engineering

Eigenschaften:

• Eine Aggregation ist eine Sonderform der Assoziation mit zusätzlicher Semantik

• Einschränkung auf Beziehung zwischen einer Komponentengruppenklasse und einer Komponentenklasse (eine Komponentengruppe mit Komponenten verschiedener Typen hat entsprechend viele Aggregationsrelationen)

• Eine Aggregation ist transitiv und antisymmetrisch

• einige Eigenschaften der Komponentengruppe pflanzen sich auf die Komponenten fort

Page 29: Software Engineering

Beispiel: Ein Dokument besteht aus mehreren Absätzen, die ihrerseits aus mehrerenSätzen bestehen.

Beispiel: In der Programmiersprache C sind ein Name, eine Argumentliste und eine Verbundanweisung Teile einer Funktionsdefinition.

Page 30: Software Engineering

Feststellungen:

Komponentenobjekte können unabhängig vom Komponentengruppenobjekt existieren.

Beispiel: Teile eines Computers

Die Existenz eines Komponentenobjektes kann von der Existenz des Komponentengruppenobjektes abhängen, zu dem es gehört.

Beispiel: Die Leimung ist Teil eines Buches zu dem sie gehört.

Komposition - bezeichnet eine „enge“ Aggregation.

- konstituiert eine Verbindung der Teile mit dem Ganzen auch hinsichtlich der „Lebenslinie“.

Page 31: Software Engineering

Beispiel:

Page 32: Software Engineering

Generalisierung/Spezialisierung und Vererbung

Spezialisierung: Beziehung zwischen einer Klasse und einer oder mehrerer

verfeinerter (speziellerer) Versionen davon.

Gegenrichtung: Generalisierung

Bezeichnungen

Oberklasse die Klasse, die verfeinert wird

(Superklasse)

Unterklasse jede Klasse, die eine verfeinerte Version ist

(Subklasse)

Inklusionsrelation Spezialisierungsbeziehung zwischen Klassen

(„is a“-Relation) Eigenschaften: transitiv, antisymmetrisch

Page 33: Software Engineering

Vererbung:

• „Merkmale“, die der Oberklasse zugeordnet sind, werden an die Unterklassen weitergegeben und von den Unterklassen genutzt, sie gelten auch für die Unterklassen und müssen dort nicht erneut angegeben werden.

entlang der Inklusionsrelation werden „Merkmale“ vererbt.

• Unterklassen können Merkmale spezialisieren, d.h.– zusätzliche Attribute

– zusätzliche Operationen

– für geerbte Operationen spezielle Realisierungen vorsehen

– Default-Werte für geerbte Attribute neu festlegen

• die Begriffe Vorfahre und Nachkomme beschreiben Generalisierung/Spezialisierung

(und Vererbung) über mehrere Ebenen hinweg

• eine Instanz einer Unterklasse ist gleichzeitig eine Instanz aller ihrer Vorfahrenklassen

Page 34: Software Engineering

Beispiel:

• jedes Buch, • jedes Fachbuch,• jedes Informatik-Fachbuch besitzt einen Autor und eine ISBN

• jedes Fachbuch, • jedes Informatik-Fachbuch, • jedes Medizin-Fachbuch besitzt ein Literaturverzeichnis

Page 35: Software Engineering

Constraints: neben dem Dreieck in geschweiften Klammern notiert.

overlapping, falls ein Nachkomme von mehr als einer Subklasse abgeleitet werden kann, andernfalls disjoint

complete, falls die Anordnung der Subklassen vollständig ist,andernfalls incomplete

Page 36: Software Engineering
Page 37: Software Engineering

Mehrfachvererbung:

Klassenhierarchie: eine Klasse kann mehrere Subklassen,aber nur eine Superklasse besitzen.

Klassenheterarchie: eine Klasse kann mehrere Subklassen undmehrere Superklassen besitzen.

Besitzt eine Klasse mehrere Superklassen, spricht man von Mehrfachvererbung.

Die Klasse erbt Merkmale von allen Superklassen.

Ein Merkmal aus der gleichen Vorfahrenklasse, das in mehr als einem Pfad gefunden wird, wird nur einmal geerbt.

Es können Mehrdeutigkeiten auftreten.

Ein Diskriminator kennzeichnet eine Partitionierung der Subklassen.(es wird nach verschiedenen Gesichtspunkten spezialisiert)

-> an die Linie neben dem Dreieck notiert

Page 38: Software Engineering
Page 39: Software Engineering

Vererbung und Delegation

Mittels Aggregation + Delegation kann (in der Programmiersprache) fehlende Mehrfachvererbung umgangen werden.

Delegation: eine Klasse A hat ein Attribut mit Wertebereich Klasse B.

(Instanzen von A besitzen für das Attribut als Wert einen Verweis

auf eine Instanz von B)

= Implementierungsmechanismus, mittels dessen ein Objekt eine

Operation auffängt und an ein Objekt entsprechend der Aggregation sendet.

Operationen werden aber nicht automatisch über die Aggregation hinweg vererbt!

Beispiel :

Page 40: Software Engineering

Beispiel: Realisierungsmöglichkeiten bei fehlender Mehrfachvererbung

Page 41: Software Engineering
Page 42: Software Engineering
Page 43: Software Engineering
Page 44: Software Engineering

Polymorphie

• wörtlich: „Vielgestaltigkeit“.

• hier: eine durch Namen und Signatur spezifizierte Operation kann in unterschiedlichen abgeleiteten Klassen durch unterschiedliche Methoden implementiert sein.

Signatur: Anzahl und Typen der Parameter einer Operation sowie ggf.

Typ des Rückgabewertes

statische Polymorphie vs. dynamische Polymorphie

gleichnamige Operationen mit unterschiedlichen Parametertypen

„späte Bindung“

Page 45: Software Engineering

Beispiel: Baumklassen

Page 46: Software Engineering
Page 47: Software Engineering
Page 48: Software Engineering

Rekursive Definition:

Ein Mobile ist- ein Gewicht oder- ein Gestänge mit Mobiles an beiden Enden

Page 49: Software Engineering

Abstrakte und konkrete Klassen

Abstrakte Klasse: Klasse, die selbst keine direkten Instanzen besitzt, deren Nachkommen aber direkte Instanzen besitzen.

Konkrete Klasse: Klasse, die direkte Instanzen besitzen kann(„Instanziierbare Klasse“)

Nur konkrete Klassen können Blattklassen im Vererbungsbaum sein!

Eine abstrakte Klasse kann sowohl abstrakte Operationen als auch nicht abstrakteOperationen definieren.

Abstrakte Operation: Eine Klasse kann nur das Protokoll einer Operation definieren, ohne eine entsprechende Methode zu implementieren.

Page 50: Software Engineering

Kennzeichnung abstrakter Operationen: { abstract } oder Signatur in italics

Ist eine Operation nicht als abstract gekannzeichnet, muß die Operation implementiert werden.

Page 51: Software Engineering

Instanzen als Laufzeitobjekte

• Instanzobjekt ist Laufzeitobjekt,

belegt Speicherplatz, besitzt Identität und Lebensdauer

• Klassen können auch Laufzeitobjekte sein ( -> Klassenobjekt)

Objekte können benannt werden

– global (Klassen)– Paket-lokal (Klassen)– Klassen-lokal– Methoden-lokal

Typkompatibilität: Mit einem Namen kann zeitlich wechselnd

- ein Objekt der definierten Klasse oder

- ein Objekt einer der Subklassen dieser Klasse assoziiert sein

Page 52: Software Engineering

Objekte befinden sich in Zuständen= Vereinigung der Werte aller Attribute zu einem bestimmten Zeitpunkt

Objekte können untereinander mittels Nachrichten kommunizieren

• Methodenaufrufe (mit Antwort)

• Ereignisse (ohne Antwort, Antworten sind selbst Ereignisse)

Bei der Abarbeitung von Methoden oder der Reaktion auf Ereignisse(in sog. Handlern) können Objekte ihren Zustand ändern.

Ereignisse und Zustände

Ereignis: • etwas, das in einem bestimmten Augenblick passiert. Ein Ereignis hat keine Dauer.• Übertragung von Informationen von einem Objekt zu einem anderen.

Ereignisse können in Ereignisklassen gruppiert werden.

Page 53: Software Engineering

Beispiele: Ereignisklassen mit Attributen

Telefonhörer abgehoben.Ziffer gewählt (Ziffer).Maustaste gedrückt (Taste, Ort).Flug fliegt ab (Datum, Fluglinie, Flugnummer).

Instanzen der Ereignisklassen

Telefonhörer abgehoben.Ziffer gewählt (4).Maustaste gedrückt (ShiftKey, (100,100))Flug fliegt ab (15 Jan, Dresden-Bonn, LH1319)

Zustand: • entspricht der Zeitspanne zwischen zwei von einem Objekt empfangenen

Ereignissen. Zustände repräsentieren Zeitspannen.

Der Zustand eines Objekts bestimmt die Reaktion des Objekts auf ankommende Ereignisse.Reaktionen können Aktionen und/oder Zustandsänderungen sein.

Page 54: Software Engineering

Szenario: Folge von Ereignissen, die bei einer ganz bestimmten Ausführung eines Systems auftritt.

• kann alle Ereignisse eines Systems betreffen

• kann Ereignisse betreffen, die bestimmte Objekte eines Systems beeinflussen oder von bestimmten Objekten erzeugt werden.

Ein Szenario erhält man durch Aufzeichnung bei der Ausführung eines Systems oder durch gedankliche Vorausplanung der Aufzeichnung.

Ereignispfad: zu einem Szenario werden Sender- und Empfängerobjekte zu jedem Ereignis bestimmt und mit den Ereignissen entsprechend derEreignisreihenfolge in einem Ereignispfad-Diagramm dargestellt.

Merke: Ein Szenario ist für ein dynamisches Modell das gleiche, wie ein Instanzendiagrammfür ein Objektmodell!

Page 55: Software Engineering
Page 56: Software Engineering
Page 57: Software Engineering

Ein Sequenzdiagramm zeigt das Verhalten von Objekten und berücksichtigt die Interaktion mit anderen Objekten durch Austausch von Nachrichten.

-> zeigt Objekte mit Lebenslinie und Nachrichtenaustausch

-> Interaktionen gehen stets von Objekten bzw. Prozessen aus

Page 58: Software Engineering
Page 59: Software Engineering

Statechart-Modelle/-Diagramme

Zustand: (state) ist die Verfassung (im Verlaufe des Lebens) eines Objekts, in der es

• einer Bedingung genügt• eine Aktivität ausführt (andauernd)• auf ein Ereignis wartet

Ein Zustand ist einer Klasse zugeordnet.

Nicht jede Änderung eines Attributwertes wird als Zustandsänderung registriert.

Transition: durch ein Ereignis verursachte Zustandsänderung eines Objekts (Zustands-Übergang). Wenn ein Ereignis empfangen wird, hängt der nächste Zustandsowohl vom aktuellen Zustand als auch vom empfangenen Ereignis ab.

Zustandsautomat: Graph, bestehend aus Zuständen (Knoten) und Transitionen (Kanten), der die Reaktion eines Objekts einer Klasse auf den Empfang von „äußeren Stimuli“ beschreibt. Zustandsautomat ist einer Klasse oder einer Operation zugeordnet.

Page 60: Software Engineering

Notation:

event(argument … ) [ bedingung ] / operation(argument … )

Startzustand Endzustand

Alle von einem Zustand ausgehenden Transitionen müssen unterschiedlichen Ereignissen entsprechen!

Interpretation:• Wenn sich ein Objekt in einem Zustand befindet, und ein Ereignis tritt auf, mit dem eine seiner Transitionen beschriftet ist, geht das Objekt in den Zustand am Ende der Transition über: Die Transition feuert.

• wenn ein Ereignis auftritt, für das es keine vom aktuellen Zustand ausgehende Transition gibt, wird das Ereignis ignoriert.

Page 61: Software Engineering

Beispiel: Dusche-Badewanne

Page 62: Software Engineering

Beispiel: Flug-Reservierung

Page 63: Software Engineering

Beispiel: Klimaanlage

Page 64: Software Engineering

Komposite Zustände:

Ein Zustand kann dekomponiert werden• mittels and in parallele Teilzustände• mittels or in sich gegenseitig ausschließende Teilzustände

Eine Verfeinerung ist nur auf einem dieser beiden Wege möglich.

Page 65: Software Engineering
Page 66: Software Engineering

Aktivitäten-Diagramm

Page 67: Software Engineering
Page 68: Software Engineering
Page 69: Software Engineering

Beispiel: Autovermietung Rücknahme

Page 70: Software Engineering

33 Implementation von UML-ModellenImplementation von UML-Modellen

Java-Applikationen

Programme in einer virtuellen Maschinensprache: JVM

Interpretative Verarbeitung java MyApplication

Compilation: MyApplication.java MyApplication.class

javac MyApplication.java

import java.io.*;

public class MyApplication{ public static void main(String args[]){

System.out.println("Hello World");for (int i = args.length -1; i>= 0; i--) System.out.println(args[i]); } }

Page 71: Software Engineering

Interfaces in Java

Syntaktisch analog Klassen (class → interface)

Reine Schnittstellen, enthalten keine Implementationen

Ausschließlich abstrakte Methoden und Konstanten

Eine Klasse kann ein oder mehrere Interfaces durch Implementierung erben(Ersatz für Mehrfachvererbung)

Wenn eine Klasse ein Interface implementiert, dann muss sie alle Methoden überschreiben

Die Eigenschaft, ein Interface zu implementieren, wird an Nachfahren der Klasse vererbt.

Page 72: Software Engineering

Implementation von Assoziationen und Aggregationen

1:1 – Beziehungen: Instanzvariable, Typ ist Klasse der zu verwaltenden Objekte

1:n – Beziehungen: Vektoren und Hashtabellen (java.util)

Vector v = new Vector(10);

Methoden:void addElement(Object o)void insertElement(Object o, int index)void removeElement(Object o)void removeElementAt(int index)int size()

Page 73: Software Engineering

Event-Handlingimport java.applet.*;import java.awt.event.*;import java.awt.*;

public class AcEvDemo2 extends Applet implements ActionListener{ public void init() { System.out.println("Hello world!"); Button bopen = new Button("open"); Button bclose = new Button("close"); bopen.addActionListener(this); bclose.addActionListener(this); add(bopen); add(bclose); System.out.println("I am waiting for events."); } public void actionPerformed(ActionEvent evt){ if (evt.getActionCommand().equals("open")){ System.out.println("action in open"); } if (evt.getActionCommand().equals("close")){ System.out.println("action in close"); } }}

Page 74: Software Engineering
Page 75: Software Engineering

44 SystemarchitekturenSystemarchitekturen

System

Logische Struktur(Klassen, objektbasiert)

Physische Struktur(Komponenten, nicht objektbasiert)

Komponentenmodelle UML: Komponentendiagramme

Subsystem :

package

Page 76: Software Engineering

Verteilungsmodelle

Modellierung verteilter Anwendungen: Auf Knoten laufen Prozesse ab

Page 77: Software Engineering

55 Der SoftwareentwicklungsprozessDer Softwareentwicklungsprozess

Anwendungsfallanalyse

Ein Anwendungsfall (use case) beschreibt Interaktionen zwischen Anwendern und demAnwendungssystem, die notwendig sind, um einen Arbeitsgang durchzuführen.

es sind Anwendungsfälle und Akteure zu identifizieren.

Page 78: Software Engineering
Page 79: Software Engineering
Page 80: Software Engineering

Methodische Aspekte der Modellierung

In der Analysephase sind folgende Aktivitäten erforderlich:

→ Zerlegung des Anwendungsbereiches in Unterbereiche→ Analyse und Spezifikation des geforderten Systemverhaltens

Während der Problembereichsanalyse werden zunächst „Geschäftsklassen“ modelliert. „Fachklassen“ beschreiben im Unterschied dazu implementierungs-technische Sachverhalte.

Zur Entwicklung eines Objektmodells wird von Rumbaugh folgendes Vorgehen empfohlen:

► Objektklassen identifizieren

► ein Data Dictionary vorbereiten

► Assoziationen zwischen Objektklassen identifizieren

► Attribute identifizieren und zu Objektklassen hinzufügen (Operationen erst spät beim Spezifizieren des Zustandsmodells hinzufügen)

► Klassen mittels Vererbung organisieren

► Zugriffspfade testen

► das Gesamtmodell in einem iterativen Prozess verfeinern

► Klassen zu Paketen (Teilsystemen) gruppieren

Page 81: Software Engineering

Qualitätssicherung

Die Qualitätssicherung umfasst

● die Planung/Durchführung von Qualitätssicherungsmaßnahmen (QSM) , ● die Kontrolle der Einhaltung von Standards (ISO 9000, ... ) und ● die Qualitätsbewertung anhand von Metriken.

Page 82: Software Engineering

Projektmanagement & Prozessmodellierung

• Maßnahmen zur Planung, Verfolgung und Qualitätssicherung einzelner Projekte und

von Projektfamilien

• Prozessmodellierung: Modellierung und Programmierung des Software-

Entwicklungfsprozesses

(Rollen, Aktivitäten, Dokumente, Ressourcen)

Page 83: Software Engineering
Page 84: Software Engineering
Page 85: Software Engineering

Konfigurationsmanagement

Das Konfigurationsmanagement umfasst Aufgaben wie

● die Kontrolle der entwickelten Quellprogramme● die Bereitstellung von „build“-Funktionalität● das Release-Engineering

Das Concurrent Versions System (CVS) ist ein System, das das Versions-Management auf der Ebene von Quellprogrammen unterstützt. Es ermöglicht die Aufzeichnung der Entwicklungsgeschichte von Programmdokumenten in Projekten und unterstützt dieGruppenarbeit (check out –check in).

Page 86: Software Engineering

66 WiederverwendungWiederverwendung

Die Verwendung objektorientierter PS allein garantieren keine Verbesserung der Wiederverwendbarkeit

Framework: Sammlung individueller Komponenten mit definiertem Kooperations-verhalten zur Lösung einer Aufgabe

Whitebox-Framework: Anpassung durch Subklassenbildung + Compilation

Blackbox-Framework: Anpassung zur Laufzeit durch unterschiedliche Instanziierung

Page 87: Software Engineering

Entwurfsmuster

• Gamma et al. haben einen Katalog von 23 Entwurfsmustern beschrieben.

• Entwurfsmuster sind typischerweise in Anwendungen vorkommende Kombinationen von Klassen zu größeren Einheiten, unabhängig von der Programmiersprache.

Page 88: Software Engineering
Page 89: Software Engineering
Page 90: Software Engineering
Page 91: Software Engineering
Page 92: Software Engineering

Entwurfsmuster „Beobachter“

Page 93: Software Engineering

Entwurfsmuster „Kompositum“

Page 94: Software Engineering

Die Model-View-Controller-Architektur (MVC)

View

Model Controller

• Modell-Objekt stellt das Anwendungsobjekt dar

• View-Objekt stellt die Bildschirmrepräsentation dar

• Controller-Objekt bestimmt die Reaktion auf Benutzereingaben→ Veränderung des Modells