Software-Projekt. Prof. Dr. Rainer Koschke. Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen

Transkript

1 Software-Projekt Prof. Dr. Rainer Koschke Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen Wintersemester 2008/09

2 Überblick I 1 Antworten auf gesammelte Fragen im Wiki

3 Antworten auf gesammelte Fragen im Wiki 1 Antworten auf gesammelte Fragen im Wiki Objektorientierte Modellierung Softwarearchitektur Entwurfsmuster und Architekturstile Softwaretechnik im Allgemeinen Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 3 / 27

4 Objektorientierte Modellierung Übersicht über alle UML Diagramme: Welche gibt es alle und was ist ihr Verwendungsgebiet? (Keine Wiederholung über die Erstellung, Eigenschaften u.ä.) Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 4 / 27

5 Objektorientierte Modellierung Anwendungsfalldiagramm Übersicht von Anwendungsfällen, Zusammenhang mit Akteuren, Beziehungen zwischen Anwendungsfällen Klassendiagramm statische Beziehungen zwischen Dingen: Daten- bzw. Domänenmodell Klassenentwurf Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 5 / 27

6 Objektorientierte Modellierung Sequenzdiagramm Interaktionen zwischen Akteuren Interaktionen in Anwendungsfällen Interaktionen zwischen Komponenten der Architektur Programmablauf (Methoden und Klassen) Kollaborationsdiagramme äquivalent zu Sequenzdiagrammen heben Akteure und deren prinzipielle Interaktion hervor, Reihenfolge tritt in den Hintergrund Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 6 / 27

7 Objektorientierte Modellierung Zustandsdiagramme zustandsbasiertes Verhalten, Reaktion auf Stimuli Modellierung von Anwendungsfällen mit Zuständen Objektlebenszyklus Protokolle in Architektur zustandsbasiertes Testen Aktivitätsdiagramme Abläufe: Aktionen und ihre Reihenfolge Modellierung von Geschäftsprozessen Beschreibung von Anwendungsfällen Spezifikation/Entwurf von Algorithmen Pfadtest Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 7 / 27

8 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 Zusammenhänge zwischen System, Subsystem, Modul und Komponente nochmal erläutern Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 8 / 27

9 Konzeptioneller Blickwinkel (Hofmeister u. a. 2000) Conceptual Configuration 1 1 CComponent 0..1 CConnector cbinding CPort connection CRole cbinding obeys obeys Protocol 1 1 conjugate Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 9 / 27

10 Konzeptionelle Sicht Compiler «Component» Main «call» «call» call ist ein Control-Konnektor; ein einfacher Aufruf «call» «Data» Text-Pipe «Component» FrontEnd «Component» MiddleEnd «Component» BackEnd «Data» Assembler-Pipe «bind» «bind» «bind» «bind» Producer Producer «Data» AST-Pipe Consumer «Data» IL-Pipe Consumer Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 10 / 27

11 Modulblickwinkel (Hofmeister u. a. 2000) 0..1 Subsystem Module (layer) A uses module (layer) B when A requires an interface that B provides contain require provide Module 0..1 use Interface assigned to require provide 0..1 Layer 0..1 use contain Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 11 / 27

12 Modulsicht Main Run Optimizer <<Subsystem>> FrontEnd GetToken Parse Decorate <<Subsystem>> MiddleEnd Lexer SyntaxAnalysis SemanticAnalysis ILGenerator ControlFlowAnalyzer Run Create Open Lookup Generate GetText Annotate <<Layer>> Programrepresentation TextBuffer AST Traverse IL Traverse Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 12 / 27

13 Ausführungsblickwinkel (Hofmeister u. a. 2000) Software Platform Communication Mechanism 1 Communication Path consume use mechanism communicate over Platform Element 1 is a Runtime Entity 2.. consume contain Platform Resource assigned to assigned to 1 Hardware Resource Module Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 13 / 27

14 Ausführungssicht Processor1 Processor2 <<Thread>> Main SyntaxAnalysis AST Lexer Shared Memory 1 1 SemanticAnalysis Optimizer IL TextBuffer ILGenerator ControlFlowAnalyzer <<Thread>> 1 Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 14 / 27

15 Entwurfsmuster und Architekturstile die factory method an einem kleinen konkreten Implementierungsbeispiel darstellen Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 15 / 27

16 Fahrradladenbeispiel: Erweiterung für andere Domänen Anforderungen: Artikeldaten sollen von einer Datei gelesen werden können zukünftig sollen andere Domänen unterstützt werden (Fahrrad, Computer und Klettern) die Objekte dieser Domänen sind unterschiedlich notwendige Anpassungen sollen einfach realisiert werden können Lösungsstrategien: die Klassen der Benutzungsschnittstelle beziehen sich nur auf die Schnittstelle der abstrakten Klasse Artikel Datei hat gleiche Syntax für alle Domä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? Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 16 / 27

17 Lösungsstrategie GUI Artikel + Preis() Leser + lies(dateiname) ArtikelSchöpfer + Artikel FabrikMethode(id) id=datei.liesid() s.fabrikmethode(id) ComputerArtikel FahrradArtikel FahrradSchöpfer ComputerSchöpfer +FabrikMethode(id) +FabrikMethode(id) Rahmen Felge create create create if (id == rahmen ) return new Rahmen if (id == felge ) return new Felge Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 17 / 27

18 Artikelklassen p u b l i c a b s t r a c t c l a s s A r t i k e l { d o u b l e P r e i s ( ) {... } } 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 {... } Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 18 / 27

19 Leser p u b l i c c l a s s L e s e r { } A r t i k e l S c h o e p f e r s c h o e p f e r ; L e s e r ( A r t i k e l S c h o e p f e r s c h o e p f e r ) { t h i s. s c h o e p f e r = s c h o e p f e r ; } 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 ) {... } Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 19 / 27

20 Leser (Forts.) p u b l i c v o i d l i e s ( S t r i n g dateiname ) throws j a v a. i o. I O E x c e p t i o n { 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 ( dateiname ) ; S t r i n g i d ; A r t i k e l a r t i k e l ; w h i l e ( i n. a v a i l a b l e ( ) > 0) { i d = r e a d i d ( i n ) ; t r y { 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. out. p r i n t ( unknown i d + i d ) ; // keep g o i n g } } i n. c l o s e ( ) ; } Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 20 / 27

21 Schöpfer p u b l i c a b s t r a c t c l a s s A r t i k e l S c h o e p f e r { } 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 FabrikMethode ( S t r i n g i d ) throws Unknown Id ; p u b l i c c l a s s F a h r r a d S c h o e p f e r e x t e n d s A r t i k e l S c h o e p f e r { } F a h r r a d A r t i k e l FabrikMethode ( S t r i n g i d ) throws 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 ( ) ; throw new Unknown Id ( ) ; } Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 21 / 27

22 Softwaretechnik im Allgemeinen kleiner Exkurs über agile Softwareentwicklung im Vergleich zum Wasserfallmodell Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 22 / 27

23 Extreme Programming (Beck 2000) Wasserfallmodell Extreme Programming Code&Fix Extreme Programming (XP) ist eine agile Methode für kleinere bis größere Entwicklerteams (max Personen), Probleme mit vagen Anforderungen und Projekte, bei denen ein Kundenrepräsentant stets greifbar ist. Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 23 / 27

24 Extreme Programming (Beck 2000) Anerkannte Prinzipien und Praktiken werden extrem umgesetzt: Code-Reviews permanente Reviews durch Pair-Programming Testen ständiges Testen: Unit-Tests sowie Akzeptanztests durch den Kunden/Benutzer klare Struktur jeder verbessert sie kontinuierlich durch Refactoring Einfachheit stets die einfachste Struktur wählen, die die aktuellen Anforderungen erfüllt Integration permanente Integration auch mehrmals am Tag Validierung: Kunde/Benutzer ist stets involviert bei der Planung neuer Iterationen und verantwortlich für Akzeptanztest kurze Iterationen Dauer in Minuten und Stunden, nicht Wochen, Tage, Jahre aber auch Auslassung anerkannter Prinzipien: Dokumentation: mündliche Überlieferung, Tests und Quellcode Planung: sehr begrenzter Horizont Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 24 / 27

25 Weitere XP-Charakteristika Kunde vor Ort eine Metapher statt einer Architekturbeschreibung 40-Stundenwoche Code ist kollektives Eigentum Kodierungsstandards Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 25 / 27

26 Agile versus weit voraus planende Prozessmodelle (Boehm und Turner 2003) Risiken agiler Methode: Skalierbarkeit, Kritikalität, Einfachheit des Entwurfs, Personalfluktuation, Personalfähigkeiten Risiken weit voraus planender Prozessmodelle: Stabilität der Anforderungen, steter Wandel, Notwendigkeit schneller Resultate, Personalfähigkeiten Generelle Risiken: Unsicherheiten bei der Technologie, unterschiedliche Interessengruppen, komplexe Systeme Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 26 / 27

27 Beck 2000 Beck, Kent: Extreme Programming Explained. Addison-Wesley, 2000 (The XP Series). ISBN 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 Hofmeister u. a Hofmeister, Christine ; Nord, Robert ; Soni, Dilip: Applied Software Architecture. Addison Wesley, 2000 (Object Technology Series) Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 27 / 27