softwaretechnologie für fortgeschrittene teil thaller stunde iv: software engineering i köln 21....
TRANSCRIPT
Softwaretechnologie für FortgeschritteneTeil Thaller
Stunde IV: Software Engineering I
Köln 21. Januar 2010
Systemdesign / Systemplanung
2
(1) Entsteht Software, entstehen Informationssysteme als Ergebnis eines künstlerischen Prozesses?
(2) Oder sind sie planbar?
Ein ernstes Problem …
3
Erfolg von IT Projekten laut Umfragen:
• 45,2 % aller Softwareprojekte erfolgreich.• 19,4 % Zeit- und Kostenüberschreitungen.• 35,4 % Fehlschläge.
Ein ernstes Problem …
4
In Abhängigkeit von der Teamgröße.Erfolgreiche Projekte bei einer Teamgröße von:
• Bis 4 Personen 60 %• 4 – 8 Personen 38 %• 8 – 20 Personen 32 %• Mehr als 20 Personen 18 %
Ein ernstes Problem …
5
Design Patterns
6
(1) Eine „Kunstlehre“, die auf der Objektorientierung aufsetzt ...
(2) … so verbreitet, dass ich mir erlaubt habe, zwei sehr geringfügig modifizierte Vorlesungsfolien auswärtiger Kollegen zu benutzen.
Background
Gamma, Helm, Johnson, and Vlissides (the “Gang of Four”) – Design Patterns, Elements of Reusable Object-Oriented SoftwareThis book solidified thinking about patterns and became the seminal Design Patterns textSoftware design patterns are based (somewhat) on work by the architect Christopher Alexander
Purpose
A design pattern captures design expertise –patterns are not created from thin air, but abstracted from existing design examplesUsing design patterns is reuse of design expertiseStudying design patterns is a way of studying how the “experts” do designDesign patterns provide a vocabulary for talking about design
Why design patterns in SA?
If you’re a software engineer, you should know about them anywayThere are many architectural patterns published, and the GoF Design Patterns is a prerequisite to understanding these: Mowbray and Malveau – CORBA Design
Patterns Schmidt et al – Pattern-Oriented Software
Architecture
Design Patterns help you break out of first-generation OO thought patterns
The seven layers of architecture*
Global architectureEnterprise architecture
System architecture
Application architecture
Macro-architecture
Micro-architecture
Objects
* Mowbray and Malveau
ORB
OO architecture
Frameworks
Subsystem
Design patterns
OO programming
How patterns arise
ProblemProblem
Context
SolutionSolution
Benefits
Related Patterns
Consequences
Forces
Structure of a pattern
NameIntentMotivationApplicabilityStructureConsequencesImplementationKnown UsesRelated Patterns
Key patterns
The following patterns are what I consider to be a good “basic” set of design patternsCompetence in recognizing and applying these patterns will improve your low-level design skills(The slides are necessarily brief and do not follow the structure just given above!)
Composite
ComponentOperation()Add(Component)Remove(Component)
CompositeOperation()Add(Component)Remove(Component)
LeafOperation()
Client
children
0..*
For all c in children c.Operation();
Construct part-whole hierarchySimplify client interface to leaves/compositesEasier to add new kinds of components
Composite (2)
Figurepaint()translate()getBounds()
CompositeFigurepaint()addFigure(Figure))removeFigure(Figure))
BasicFigurepaint()
Viewchildren
0..*
For all c in children c.paint();
Example: figures in a structured graphics toolkit
LabelFigurepaint()
0..*
Controller
parent
FacadeProvide unified interface to interfaces within a subsystemShield clients from subsystem componentsPromote weak coupling between client and subsystem components
FacadeClient
Façade (2)
Entity
CompositeEntityAtomicEntity
PortRelation
BufferedRelation
GraphSchematicEditor
Example: graph interface to a simulation engine
Actor
Director0..*
2
Token
Strategy
StrategyOperation()
ConcreteStrategy2Operation()
Context
Make algorithms interchangeable---”changing the guts”Alternative to subclassingChoice of implementation at run-timeIncreases run-time complexity
ContextInterface()
ConcreteStrategy1Operation()
Strategy (2)
ConnectorRouterShape recalculate(Pt, Pt)
ArcRouterShape recalculate(Pt, Pt)
Connectorroute()
StraightRouterShape recalculate(Pt, Pt)
ManhattanRouterShape recalculate(Pt, Pt)
shape=router.recalculate(start,end);redraw(shape);
Example: drawing different connector styles
ObserverMany-to-one dependency between objectsUse when there are two or more views on the same “data”aka “Publish and subscribe” mechanismChoice of “push” or “pull” notification styles
Observerupdate()
Subjectattach(Observer)detach(Observer)notify()
ConcreteObserverupdate()
ConcreteSubjectgetState()
state=subject.getState();
forall o in observers o.update()
Factory Method
CreatorProduct createProduct()
Product
Defer object instantiation to subclassesEliminates binding of application-specific subclassesConnects parallel class hierarchiesA related pattern is AbstractFactory
operation()
ConcreteCreatorProduct createProduct()
ConcreteProductoperation()
return new ConcreteProduct();
Factory Method (2)Example: creating manipulators on connectors
FigurecreateManipulator()
0..1Manipulator
attach(Figure)
ArcManipulatorattach(Figure)
BoundsManipulatorattach(Figure)
ConnectorcreateManipulator()
RectFigurecreateManipulator()
manip = new BoundsManipulator();
manip = new ArcManipulator();
Interactor
Chain of Responsibility
HandlerhandleRequest()
ConcreteHandler2handleRequest()
ClientContextInterface()
ConcreteHandler1handleRequest()
Decouple sender of a request from receiverGive more than one object a chance to handleFlexibility in assigning responsibilityOften applied with Composite
successor
Chain of Responsibility (2)
FigurehandleEvent(Event)
CompositeFigure
Interactorchildren
0..*
If interactor != null interactor.handle(event,this)else parent.handleEvent(event)
0..1
parent
Example: handling events in a graphical hierarchy
handle(Event,Figure)
0..*
Patterns vs “Design”
Patterns are design But: patterns transcend the “identify
classes and associations” approach to design
Instead: learn to recognize patterns in the problem space and translate to the solution
Patterns can capture OO design principles within a specific domainPatterns provide structure to “design”
Patterns vs Frameworks
Patterns are lower-level than frameworksFrameworks typically employ many patterns: Factory Strategy Composite Observer
Done well, patterns are the “plumbing” of a framework
Patterns vs Architecture
Design Patterns (GoF) represent a lower level of system structure than “architecture” (cf: seven levels of A)Patterns can be applied to architecture:
Mowbray and Malveau Buschmann et al Schmidt et al
Architectural patterns tend to be focussed on middleware. They are good at capturing:
Concurrency Distribution Synchronization
Online resources
Pattern FAQ http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html
Patterns home page http://hillside.net/patterns/
Beispiel einer (GUI) “Pattern Library”
http://www.welie.com/patterns/showPattern.php
Concluding remarks
Design Patterns (GoF) provide a foundation for further understanding of: Object-Oriented design Software Architecture
Understanding patterns can take some time Re-reading them over time helps As does applying them in your own designs!
31
Herzlichen Dank!