Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
FrameworksFrameworks
B. Sc. Tim LüeckeSeminar Software-EntwurfFG Software Engineering
2Tim Lüecke: Frameworks
GliederungGliederung
1. Motivation u. Definition2. Charakteristiken von Frameworks3. Beispiele4. Frameworks aus
– Nutzersicht– Entwicklersicht
5. Literatur6. Fazit
Probleme und Erfahrungen
3Tim Lüecke: Frameworks
MotivationMotivation
• Ziel der Software-Entwicklung: Wiederverwendung– OO: Vererbung und Polymorphismus– Design Patterns: abstrakte Problemlösungen– Komponenten / Klassenbibliotheken: Lösungen für spezifische Ziele
Eingeschränkte Wiederverwendung
• Wunsch: Skelett einer Anwendung, das nur noch zurechtgeschneidert werden muss
Frameworksseit ca. 1980 (erstes Framework: MVC in Smalltalk-80)
4Tim Lüecke: Frameworks
Benutzung eines FrameworksBenutzung eines Frameworks
1. Anforderung der Anwendung werden spezifiziert2. Gemäß den Anforderungen wird Framework
ausgesucht3. Framework wird erlernt4. Framework wird an den gewünschten Stellen (hot
spots) angepasst5. Ergebnis: Wesentliche Verkürzung der
Entwicklungszeit- und Kosten
5Tim Lüecke: Frameworks
Definition u. StrukturDefinition u. Struktur
wieder verwendbarer Entwurf einer Anwendung beschrieben durch:– Abstrakte Klassen– Kollaboration der Instanzen
Anwendungsbereich (domain)
Framework-Domain
6Tim Lüecke: Frameworks
Benutzung eines FrameworksBenutzung eines Frameworks
1. Anforderung der Anwendung werden spezifiziert2. Gemäß den Anforderungen wird Framework ausgesucht3. Framework wird erlernt4. Framework wird an den gewünschten Stellen (hot spots)
angepasst– Subklassen von Framework-Klassen werden erstellt– Verhaltenssteuerende Methoden werden überschrieben (hooks)– zu nutzende Komponenten werden erstellt– etc.
5. Ergebnis: Wesentliche Verkürzung der Entwicklungszeit-und Kosten
7Tim Lüecke: Frameworks
Charakteristiken von FrameworksCharakteristiken von Frameworks
• Reuse of analysis– Erfolgreiche Betrachtung eines bestimmten Anwendungsbereiches
• Reuse of design– „fast“ kompletter Software-Entwurf
• Reuse of code– âtomarer Bestandteil: Abstrakte Klassen– hook methods
• Inversion of Control (IoC)
Framework
Application
8Tim Lüecke: Frameworks
Blackbox vs. Whitebox FrameworksBlackbox vs. Whitebox Frameworks
• Whitebox Frameworks setzen Kenntnis der inneren Struktur des Frameworks voraus– Vererbung– Überschreiben von hook-
Methoden– die meisten Frameworks sind am
Anfang Whitebox• Blackbox Frameworks sind
ausgereifter und werden über Komponenten konfiguriert– Definition der Komponenten-
Schnittstellen– Integration über Patterns wie
Strategy
White-Box Framework
Black-Box Framework
9Tim Lüecke: Frameworks
Einordnung aus NutzersichtEinordnung aus Nutzersicht
Frameworks
Anti-Patterns
Design Patterns
UML
Metriken
OOP
Software-EntwurfOOAD
Architektur
n-Schichten
J2EE .NET DCOM
benutzt
Pet Shop Pet Store
10Tim Lüecke: Frameworks
EinordnungEinordnung aus Entwicklersichtaus Entwicklersicht
Applikationsebene
Frameworks
HilfsmittelAnti-Patterns
Design Patterns
UML
Metriken
OOP
Software-EntwurfOOAD
Architektur
n-Schichten
J2EE .NET DCOM
Pet Shop Pet Store
11Tim Lüecke: Frameworks
Beispiel: Struts (MVC Framework)Beispiel: Struts (MVC Framework)
• Framework für MVC Web Applikation• Controller
– zentrales Servlet– steuert sog. Action-Klassen Geschäftslogik
• View– z.B. JSPs aber auch andere Präsentationstechniken– liefert Funktionalität für Web-Designer– Datenaustausch zwischen View/Controller über sog. ActionForms
• Model– keine Vorgaben (z.B. JavaBeans, EJBs, etc.)
• Controller wird zentral über XML-Datei konfiguriert
12Tim Lüecke: Frameworks
Beispiel: Struts (MVC Framework)Beispiel: Struts (MVC Framework)
13Tim Lüecke: Frameworks
Domain Framework zur VerkaufsfDomain Framework zur Verkaufsföörderungrderung
• oft wiederkehrender Anwendungsfall: Verkaufsförderung• tritt in vielen Geschäftsbereichen auf• daher: Framework für unterstützende Applikationen
– zeitliche Planung von Promotion Events– Auswertung der Ergebnisse– etc.
• wurde durchgeführt– mit komplexer Anforderungs-Erhebung– iteratives Verfahren um die Kern-Elemente zu abstrahieren
14Tim Lüecke: Frameworks
Domain Framework zur VerkaufsfDomain Framework zur Verkaufsföörderungrderung
entnommen aus [2]
15Tim Lüecke: Frameworks
GliederungGliederung
1. Motivation u. Definition2. Charakteristiken von Frameworks3. Beispiele4. Frameworks aus
– Nutzersicht– Entwicklersicht
5. Literatur6. Fazit
Probleme und Erfahrungen
16Tim Lüecke: Frameworks
Frameworks auswFrameworks auswäählenhlen
• Frameworks müssen in vier Anforderungs-Dimensionen einer Anwendung entsprechen:
• Die Kosten einer Fehleinschätzung sind hoch!
Interoperabilität
nicht-funktional funktional
Hardware
17Tim Lüecke: Frameworks
AuswahlAuswahl--KriterienKriterien
• Lizenz• Komplexität
– Modularisierung betrachten
• Dokumentation– Katalog / Feature-Liste– „Koch-Rezept“– Design Dokumentation– road maps– Source code
• Support– Wer stellt Support bereit?– Wie ist das Prozedere?– Was sind die Kosten?– Experten oder Aushilfen?– Self-support?
• Verwendung von Standards– Wiederverwendung!– quasi wie Interfaces im
Design
18Tim Lüecke: Frameworks
Probleme bei der BenutzungProbleme bei der Benutzung
• Erlernen des Frameworks!– Einarbeitungsdauer von ca. 6-12
Monaten– Mentoring
• erfahrener Mitarbeiter wird jedoch meist woanders benötigt
– Training• basierend auf Beispielen• von einfachen zu schweren,
speziellen Beispielen
• Management des Entwicklungsprozesses– anders als die ausgereiften Prozessmodelle– zumeist wird ad hoc entwickelt (Stand: 1999)
Zeit
Lernfortschritt
19Tim Lüecke: Frameworks
Probleme bei der BenutzungProbleme bei der Benutzung
• Abschätzung der Anwendungs-Entwicklung– meist schwer durchführbar– 90 Prozent / 10 Prozent-Regel
• Verifikation der Anwendungs-Komponenten– zwei Aspekte:
• Testen der Funktionalität• Testen der Konformität zu dem Framework
– Debugging ist zumeist äußerst schwierig (IoC)
t
Fortschritt
20Tim Lüecke: Frameworks
Framework EntwicklungFramework Entwicklung
Domain analysis
Framework-Enwicklung
DomainModel
Anwendungs-Entwicklung
Anwendung
Framework
AnwendungAnwendung
Anwendung1
21Tim Lüecke: Frameworks
Probleme bei der EntwicklungProbleme bei der Entwicklung
• Domain scope– es kann zuviel oder zuwenig mit einbezogen werden– besser sind zunächst kleinere Frameworks– Menschen neigen jedoch die andere Richtung zu wählen!
• Framework Dokumentation– wichtig: Darstellung der Framework-Struktur und der daraus folgenden
Regeln – kein Standard vorhanden, am besten verschiedene Methoden
verwenden– Dokumentation kostet! Vor allem bei Frameworks!
22Tim Lüecke: Frameworks
Probleme bei der EntwicklungProbleme bei der Entwicklung
• Verifizierung von abstrakten Verhalten– normal: Erstellung einer Test-Applikation, die getestet wird– Vielseitigkeit kann schwer getestet werden
• Framework Release Problem– Framework muss wieder verwendbar sein– stabil sein gegenüber Änderungen im Anwendungsbereich– sehr gut dokumentiert sein– keine Standard-Kriterien vorhanden!– aber unreife Veröffentlichung hat verheerende Auswirkungen
23Tim Lüecke: Frameworks
LiteraturLiteratur
[1] M.E. Fayad, D.C. Schmidt, R.E. Johnson, "Building ApplicationFrameworks", Wiley 1999
[2] M.E. Fayad, D.C. Schmidt, R.E. Johnson, "Implementing ApplicationFrameworks", Wiley 1999
[3] M. Nash, “Java Frameworks and Components”, Cambridge University Press 2003
[4] R.E. Johnson, B. Foote, "Designing reusable classes", Object-Oriented Programming 1, 5 (June/July 1988), 22–35.
[5] R.E. Johnson, „Frameworks=(Components+Patterns)“, CACM October1997/Vol. 40, No. 10
24Tim Lüecke: Frameworks
FazitFazit
• Frameworks im Idealfall eines der besten Wiederverwendungsmöglichkeiten im großen Maßstab
• aber:– Eigenentwicklung sollte genau bedacht werden!
• immense Kosten und Zeitbedarf!• sehr schwierig!• Dokumentation nicht unterschätzen!
– Bei Verwendung an Lernkurve denken!Respekt haben!
Vielen Dank für die Aufmerksamkeit!