Ringvorlesung: FIO Systems AG stellt Projektziel zum Thema Software Design Patterns vor

1. Software Design
und Design Patterns
FIO SYSTEMS AG®

2. Gliederung
•Gutes Design
•Typische Designprobleme
•Software-Wartung
•Schichtenarchitektur
•Architektur-Patterns
•Übergreifende Patterns
•Aufgabenstellung

3. Was ist gutes Design?
•Einfach
•Modular
•Gekapselt
•Erweiterbar
•Stabil
•Zweckmäßig

4. Typische Probleme
•Frontend == Anwendung
•Prozeduraler Code
•Code Duplication
•Architektur, die nicht zum Problem passt
•Pattern madness
•Design for the unpredictable

5. Typische Probleme
●
Untestbar / keine Unit-Tests
●
Spaghetti-Code
Folge:
●
hohe Wartungs- und Pflegekosten
●
ineffektive Erweiterungen
●
hohe Fehlerquote
●
Demotivation
●
Enge Kopplung

6. Praxisbeispiel Wartung
(stark vereinfacht)
•FIOPORT Vermarktung
•Grobkonzept 2003, 35 Seiten
•Entwicklungszeit: 1 Jahr, 5 Entwickler
•Wartungszeit: 9 Jahre, Wartung und Erweiterung durch
mittlerweile 10 Entwickler

7. Erstellung vs. Wartung / Pflege
Erstellung
Wartung / Pflege
2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013
0
1
2
3
4
5
6
7
8
9
10
Entwickler
Praxisbeispiel Wartung

8. Praxisbeispiel Wartung 2
(stark vereinfacht)
•FIOPORT Account
•Grobkonzept 2003
•Entwicklungszeit: 4 Monate, 1 Entwicklerin
•Wartungszeit: 9 Jahre, Wartung und Erweiterung durch
mittlerweile 8 Entwickler

9. Erstellung vs. Wartung / Pflege
Erstellung
Wartung / Pflege
Praxisbeispiel Wartung 2
2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013
0
1
2
3
4
5
6
7
8
Entwickler

10. Schichtenarchitektur

11. Schichtenarchitektur

12. Schichtenarchitektur

13. Dependency Inversion
•Abhängigkeit Frontend → … → Backend erscheint
natürlich
•Dadurch haben Änderungen in niederen Schichten
jedoch Auswirkungen auf alles darüber
•Außerdem erschwert eine solche Architektur die
Wiederverwendung

14. Dependency Inversion Principle
Formuliert von Robert C. Martin, 1996:
A. High-level modules should not depend on low-level
modules. Both should depend on abstractions.
B. Abstractions should not depend upon details. Details should
depend upon abstractions.

15. Architektur-Patterns
•Frontend Patterns
●
MVC
●
Front Controller
●
Page Controller
●
MVP
•BLL-Patterns
●
Service Layer
●
Domain Model
•DAL-Patterns
●
Repository
●
Data Mapper
●
Active Record

16. Frontend-Patterns - MVC

17. Frontend-Patterns - FC

18. Frontend-Patterns - FC
Code

19. Frontend-Patterns - PC

20. Frontend-Patterns - MVP

21. Frontend-Patterns - MVP
Code

22. BLL-Patterns – Service Layer

23. BLL-Patterns – Service Layer 2

24. BLL-Patterns – Domain Model

25. DAL-Patterns – Repository

26. DAL-Patterns – Data Mapper

27. DAL-Patterns – Active Record
@products = Product.all
@product = Product.find(params[:id])
@product = Product.new

28. Übergreifende Patterns
•Value Object
•Data Transfer Object
•Factory
•Singleton
•Observer
•Facade
•Proxy

29. Value Object

30. Data Transfer Object

31. Factory

32. Singleton

33. Observer

34. Facade

35. Proxy

36. Zusammenfassung
•einfaches Design, bereit für geplante Anforderungen
•Dependencies planen – Interfaces verwenden
•Unit-Tests als Absicherung für Umbauten
•Wartungskosten minimieren durch Investition in gute
Architektur-Planung am Projektanfang
•Bei bestehendem Code – schrittweise umstellen
Denn: Änderungen werden kommen!

37. Aufgabe
•Erstellen einer Web-Anwendung für das fiktive
Maklerbüro “Alt & Schimmel GmbH” unter Verwendung
von mind. 3 Patterns
•Seite für Kunden mit aktuellen Angeboten
•Seiten für Händler zur Pflege der Angebote
•Architekturdiagramm
•Beliebige Programmiersprache
•Vorstellung der Patterns mit Begründung

38. Quellen, Lesetipps
•Wikipedia (de, en)
•Martin Fowler “Patterns of Enterprise Application
Architecture”
•Eric Evans “Domain Driven Design”
•http://www.oodesign.com
•"Design Patterns. Elements of Reusable Object-Oriented
Software" Erich Gamma, Richard Helm, Ralph Johnson
und John Vlissides

39. Fragen?
(Spätere Fragen einfach per E-Mail an die Adresse auf der Veranstaltungswebsite schicken!)

40. Vielen Dank!

41. www.fio.de