Software-Projekt - Informatik - FB3 - Uni Bremen

Transcription

Software-Projekt
Prof. Dr. Rainer Koschke
Fachbereich Mathematik und Informatik
Arbeitsgruppe Softwaretechnik
Universität Bremen
Wintersemester 2008/09
Überblick I
1
Antworten auf gesammelte Fragen im Wiki
1
Objektorientierte Modellierung
Softwarearchitektur
Entwurfsmuster und Architekturstile
Softwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen)
Software-Projekt
3 / 27
Übersicht über alle UML Diagramme: Welche gibt es alle und
was ist ihr Verwendungsgebiet? (Keine Wiederholung über die
Erstellung, Eigenschaften u.ä.)
Software-Projekt
4 / 27
Anwendungsfalldiagramm
→ Übersicht von Anwendungsfällen, Zusammenhang mit Akteuren,
Beziehungen zwischen Anwendungsfällen
Klassendiagramm
→ statische Beziehungen zwischen Dingen:
Daten- bzw. Domänenmodell
Klassenentwurf
Software-Projekt
5 / 27
Sequenzdiagramm
→ Interaktionen zwischen Akteuren
Interaktionen in Anwendungsfällen
Interaktionen zwischen Komponenten der Architektur
Programmablauf (Methoden und Klassen)
Kollaborationsdiagramme
→ äquivalent zu Sequenzdiagrammen
→ heben Akteure und deren prinzipielle Interaktion hervor, Reihenfolge
tritt in den Hintergrund
Software-Projekt
6 / 27
Zustandsdiagramme
→ zustandsbasiertes Verhalten, Reaktion auf Stimuli
Modellierung von Anwendungsfällen mit Zuständen
Objektlebenszyklus
Protokolle in Architektur
zustandsbasiertes Testen
Aktivitätsdiagramme
→ Abläufe: Aktionen und ihre Reihenfolge
Modellierung von Geschäftsprozessen
Beschreibung von Anwendungsfällen
Spezifikation/Entwurf von Algorithmen
Pfadtest
Software-Projekt
7 / 27
Softwarearchitektur
Außerdem aus gegebenem Anlass, zu den unterschiedlichen
Blickwinkel des Architekturentwurfs.
Konzeptionelle Sicht nach Hofmeister u. a. 2000: Data und
Control Konnektoren, Unterschiede? (Wir haben z.B. bei jeder
Verbindung beides benutzt...??)
Alternative Modellierung der Konzeptionellen Sicht mit UML?
Vielleicht ein kleines Beispiel?
Die Unterschiede und Zusammenhänge zwischen System,
Subsystem, Modul und Komponente nochmal erläutern
Software-Projekt
8 / 27
Konzeptioneller Blickwinkel (Hofmeister u. a. 2000)
Conceptual Configuration
1
*
*
1
0..1
*
CConnector
CComponent
0..1
0..1
*
0..1
0..1
0..1
cbinding
cbinding
*
*
*
*
*
CPort
*
connection
*
CRole
*
*
obeys
1
*
Protocol
Software-Projekt
obeys
1 conjugate
9 / 27
Konzeptionelle Sicht
Compiler
«Component»
Main
«call»
«call»
call ist ein Control-Konnektor;
ein einfacher Aufruf
«call»
«Data»
Text-Pipe
«Component»
FrontEnd
«Component»
MiddleEnd
«bind»
«bind»
Producer
«Component»
BackEnd
«bind»
«bind»
Producer
Consumer
«Data»
AST-Pipe
«Data»
Assembler-Pipe
Software-Projekt
Consumer
«Data»
IL-Pipe
10 / 27
Modulblickwinkel (Hofmeister u. a. 2000)
Module (layer) A uses
module (layer) B when
A requires an interface
that B provides
Subsystem
contain
0..1
*
require
*
require
*
provide
0..1 *
Interface
provide
*
*
*
Module
0..1
*
*
*
assigned−to
Layer
*
*
*
use
use
Software-Projekt
*
*
0..1
contain
11 / 27
Modulsicht
Main
Run
GetToken
Lexer
Optimizer
<<Subsystem>>
MiddleEnd
<<Subsystem>> FrontEnd
Parse
Decorate
SyntaxAnalysis
SemanticAnalysis
ControlFlowAnalyzer
ILGenerator
Run
Create
Open
Lookup
Annotate
GetText
<<Layer>>
Programrepresentation
TextBuffer
Generate
IL
AST
Traverse
Traverse
Software-Projekt
12 / 27
Ausführungsblickwinkel (Hofmeister u. a. 2000)
Software
Platform
*
Communication
Mechanism
1
contain
*
*
Platform
Element
*
*
1
consume
is a
*
* use mechanism
Runtime
Communication
Entity
Path
2..*
*
Platform
Resource
assigned to
Hardware
* 1
Resource
*
*
consume
*
assigned to
*
Module
communicate over
Software-Projekt
13 / 27
Ausführungssicht
Processor1
Processor2
Main
<<Thread>> *
SyntaxAnalysis
AST
Lexer
Shared Memory
SemanticAnalysis
1
Optimizer
IL
1
TextBuffer
ILGenerator
ControlFlowAnalyzer
<<Thread>>
Software-Projekt
1
14 / 27
Entwurfsmuster und Architekturstile
die factory method an einem kleinen konkreten
Implementierungsbeispiel darstellen
Software-Projekt
15 / 27
Fahrradladenbeispiel: Erweiterung für andere Domänen
Anforderungen:
Artikeldaten sollen von einer Datei gelesen werden können
zukünftig sollen andere Domänen unterstützt werden (Fahrrad,
Computer und Klettern)
die Objekte dieser Domänen sind unterschiedlich
notwendige Anpassungen sollen einfach realisiert werden können
Lösungsstrategien:
die Klassen der Benutzungsschnittstelle beziehen sich nur auf die
Schnittstelle der abstrakten Klasse Artikel
Datei hat gleiche Syntax für alle Domänen (nur die Inhalte variieren)
die Artikel werden beim Einlesen der Datei als Objekte erzeugt
→ aber der Leser muss doch die Konstruktoren der Objekte kennen, oder
was?
Software-Projekt
16 / 27
Lösungsstrategie
GUI
Artikel
Leser
ArtikelSchöpfer
+ Preis()
+ lies(dateiname)
+ Artikel FabrikMethode(id)
id=datei.liesId()
s.FabrikMethode(id)
ComputerArtikel
FahrradArtikel
FahrradSchöpfer
ComputerSchöpfer
+FabrikMethode(id) +FabrikMethode(id)
Rahmen
create
Felge
create
create
Software-Projekt
if (id == ”rahmen”)
return new Rahmen
if (id == ”felge”)
return new Felge
17 / 27
Artikelklassen
public abstract class Artikel {
double Preis () { . . . }
}
p u b l i c a b s t r a c t c l a s s F a h r r a d A r t i k e l e x t e n d s A r t i k e l {. . . }
p u b l i c c l a s s F e l g e e x t e n d s F a h r r a d A r t i k e l {. . . }
p u b l i c c l a s s Rahmen e x t e n d s F a h r r a d A r t i k e l {. . . }
Software-Projekt
18 / 27
Leser
public class Leser {
ArtikelSchoepfer schoepfer ;
Leser ( ArtikelSchoepfer schoepfer ) {
this . schoepfer = schoepfer ;
}
p r i v a t e S t r i n g r e a d i d ( F i l e I n p u t S t r e a m i n ) {. . . }
}
Software-Projekt
19 / 27
Leser (Forts.)
p u b l i c void l i e s ( S t r i n g dateiname ) throws java . i o . IOException {
F i l e I n p u t S t r e a m i n = new F i l e I n p u t S t r e a m ( d a t e i n a m e ) ;
String id ;
Artikel artikel ;
w h i l e ( i n . a v a i l a b l e ( ) > 0) {
id = read id ( in );
try {
a r t i k e l = s c h o e p f e r . FabrikMethode ( i d ) ;
}
c a t c h ( A r t i k e l S c h o e p f e r . Unknown Id e ) {
System . o u t . p r i n t ( ” unknown i d ” + i d ) ;
// k e e p g o i n g
}
}
in . close ();
}
Software-Projekt
20 / 27
Schöpfer
public abstract class ArtikelSchoepfer {
p u b l i c c l a s s Unknown Id e x t e n d s E x c e p t i o n { } ;
a b s t r a c t A r t i k e l F a b r i k M e t h o d e ( S t r i n g i d ) t h r o w s Unknown Id ;
}
public c l a s s FahrradSchoepfer extends ArtikelSchoepfer {
F a h r r a d A r t i k e l F a b r i k M e t h o d e ( S t r i n g i d ) t h r o w s Unknown Id {
i f ( i d == ” rahmen ” ) r e t u r n new Rahmen ( ) ;
e l s e i f ( i d == ” f e l g e ” ) r e t u r n new F e l g e ( ) ;
t h r o w new Unknown Id ( ) ;
}
}
Software-Projekt
21 / 27
Softwaretechnik im Allgemeinen
kleiner Exkurs über agile Softwareentwicklung im Vergleich zum
Wasserfallmodell
Software-Projekt
22 / 27
Extreme Programming (Beck 2000)
Wasserfallmodell — Extreme Programming — Code&Fix
Extreme Programming (XP) ist eine agile Methode für
kleinere bis größere Entwicklerteams (max. 10-15 Personen),
Probleme mit vagen Anforderungen
und Projekte, bei denen ein Kundenrepräsentant stets greifbar ist.
http://www.extremeprogramming.org/
Software-Projekt
23 / 27
Extreme Programming (Beck 2000)
Anerkannte Prinzipien und Praktiken werden extrem“ umgesetzt:
”
Code-Reviews → permanente Reviews durch Pair-Programming
Testen → ständiges Testen: Unit-Tests sowie Akzeptanztests durch
den Kunden/Benutzer
klare Struktur → jeder verbessert sie kontinuierlich durch Refactoring
Einfachheit → stets die einfachste Struktur wählen, die die aktuellen
Anforderungen erfüllt
Integration → permanente Integration auch mehrmals am Tag
Validierung:
Kunde/Benutzer ist stets involviert bei der Planung neuer Iterationen
und verantwortlich für Akzeptanztest
kurze Iterationen → Dauer in Minuten und Stunden, nicht Wochen,
Tage, Jahre
aber auch Auslassung anerkannter Prinzipien:
Dokumentation: mündliche Überlieferung, Tests und Quellcode
Planung: sehr begrenzter Horizont
Software-Projekt
24 / 27
Weitere XP-Charakteristika
Kunde vor Ort
eine Metapher statt einer Architekturbeschreibung
40-Stundenwoche
Code ist kollektives Eigentum
Kodierungsstandards
Software-Projekt
25 / 27
Agile versus weit voraus planende Prozessmodelle (Boehm
und Turner 2003)
Risiken agiler Methode:
Skalierbarkeit, Kritikalität, Einfachheit des Entwurfs,
Personalfluktuation, Personalfähigkeiten
Risiken weit voraus planender Prozessmodelle:
Stabilität der Anforderungen, steter Wandel, Notwendigkeit schneller
Resultate, Personalfähigkeiten
Generelle Risiken:
Unsicherheiten bei der Technologie, unterschiedliche
Interessengruppen, komplexe Systeme
Software-Projekt
26 / 27
1 Beck 2000 Beck, Kent: Extreme Programming Explained.
Addison-Wesley, 2000 (The XP Series). – ISBN 201-61641-6
2 Boehm und Turner 2003 Boehm, B. ; Turner, R.: Using risk to
balance agile and plan-driven methods. In: IEEE Computer 36 (2003),
Juni, Nr. 6, S. 57–66
3 Hofmeister u. a. 2000 Hofmeister, Christine ; Nord, Robert ;
Soni, Dilip: Applied Software Architecture. Addison Wesley, 2000
(Object Technology Series)
Software-Projekt
27 / 27

Software-Projekt - Informatik - FB3 - Uni Bremen

Transcription

Documents pareils

Familienkasse Bremen

Peer-to-Peer Web-Suche mit YaCy - SuMa

Architecture-Centric Integrated Development Environment (AIDE)

Theater Bremen GmbH Ausbildungsstelle Referendariat Das

Ausbildung zur Fachkraft fuer Lagerlogistik, Mercedes

Robert Walla, „Schlagzeug“ (Bremen, Deutschland) ist regelmäßiger

Ver.di Kündigung Bremen

Kurzvita Cornelia Hopp

Curriculum Vitae - Marketing Club Bremen eV

Bus 502, 508, 509 (Wilhelm-Raabe- Schule) 503, 507 (Elbestraße) H