Softwaretechnologie f r fortgeschrittene teil thaller stunde iv software engineering i
Download
1 / 29

Softwaretechnologie für Fortgeschrittene Teil Thaller Stunde IV: Software Engineering I - PowerPoint PPT Presentation


  • 110 Views
  • Uploaded on

Softwaretechnologie für Fortgeschrittene Teil Thaller Stunde IV: Software Engineering I. Köln 20. Januar 2011. Ein ernstes Problem …. Erfolg von IT Projekten laut Umfragen: 45,2 % aller Softwareprojekte erfolgreich. 19,4 % Zeit- und Kostenüberschreitungen. 35,4 % Fehlschläge.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Softwaretechnologie für Fortgeschrittene Teil Thaller Stunde IV: Software Engineering I' - cuyler


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Softwaretechnologie f r fortgeschrittene teil thaller stunde iv software engineering i

Softwaretechnologie für FortgeschritteneTeil ThallerStunde IV: Software Engineering I

Köln 20. Januar 2011


Ein ernstes Problem …

  • Erfolg von IT Projekten laut Umfragen:

  • 45,2 % aller Softwareprojekte erfolgreich.

  • 19,4 % Zeit- und Kostenüberschreitungen.

  • 35,4 % Fehlschläge.



Design Patterns

Eine „Kunstlehre“, die auf der Objektorientierung aufsetzt ...

… so verbreitet, dass ich mir erlaubt habe, zwei sehr geringfügig modifizierte Vorlesungsfolien auswärtiger Kollegen zu benutzen.


Design patterns

Design Patterns

John Reekie

[email protected]

Software Architecture 48433

21st August 2003


Background
Background

  • Gamma, Helm, Johnson, and Vlissides (the “Gang of Four”) – Design Patterns, Elements of Reusable Object-Oriented Software

  • This book solidified thinking about patterns and became the seminal Design Patterns text

  • Software design patterns are based (somewhat) on work by the architect Christopher Alexander


Purpose
Purpose

  • A design pattern captures design expertise –patterns are not created from thin air, but abstracted from existing design examples

  • Using design patterns is reuse of design expertise

  • Studying design patterns is a way of studying how the “experts” do design

  • Design patterns provide a vocabulary for talking about design


Why design patterns in sa
Why design patterns in SA?

  • If you’re a software engineer, you should know about them anyway

  • There 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

ORB

The seven layers of architecture*

OO architecture

Global architecture

Enterprise architecture

Subsystem

System architecture

Application architecture

Frameworks

Macro-architecture

Design patterns

Micro-architecture

Objects

OO programming

* Mowbray and Malveau


How patterns arise
How patterns arise

Problem

Context

Forces

Solution

Benefits

Consequences

Related Patterns


Structure of a pattern
Structure of a pattern

  • Name

  • Intent

  • Motivation

  • Applicability

  • Structure

  • Consequences

  • Implementation

  • Known Uses

  • Related Patterns


Key patterns
Key patterns

  • The following patterns are what I consider to be a good “basic” set of design patterns

  • Competence 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
Composite

  • Construct part-whole hierarchy

  • Simplify client interface to leaves/composites

  • Easier to add new kinds of components

0..*

Client

Component

Operation()

Add(Component)

Remove(Component)

children

Leaf

Composite

Operation()

Operation()

Add(Component)

Remove(Component)

For all c in children

c.Operation();


Composite 2
Composite (2)

  • Example: figures in a structured graphics toolkit

Controller

0..*

0..*

View

Figure

children

paint()

translate()

getBounds()

BasicFigure

LabelFigure

CompositeFigure

parent

paint()

paint()

addFigure(Figure))

removeFigure(Figure))

paint()

For all c in children

c.paint();


Facade

  • Provide unified interface to interfaces within a subsystem

  • Shield clients from subsystem components

  • Promote weak coupling between client and subsystem components

Client

Facade


Façade (2)

  • Example: graph interface to a simulation engine

SchematicEditor

Graph

Director

2

0..*

Relation

Port

Entity

BufferedRelation

AtomicEntity

CompositeEntity

Token

Actor


Strategy
Strategy

  • Make algorithms interchangeable---”changing the guts”

  • Alternative to subclassing

  • Choice of implementation at run-time

  • Increases run-time complexity

Context

Strategy

ContextInterface()

Operation()

ConcreteStrategy2

ConcreteStrategy1

Operation()

Operation()


Strategy 2
Strategy (2)

  • Example: drawing different connector styles

shape=router.recalculate(start,end);

redraw(shape);

Connector

ConnectorRouter

route()

Shape recalculate(Pt, Pt)

ArcRouter

StraightRouter

ManhattanRouter

Shape recalculate(Pt, Pt)

Shape recalculate(Pt, Pt)

Shape recalculate(Pt, Pt)


Observer
Observer

  • Many-to-one dependency between objects

  • Use when there are two or more views on the same “data”

  • aka “Publish and subscribe” mechanism

  • Choice of “push” or “pull” notification styles

Subject

Observer

attach(Observer)

detach(Observer)

notify()

update()

forall o in observers

o.update()

ConcreteSubject

ConcreteObserver

getState()

update()

state=subject.getState();


Factory Method

  • Defer object instantiation to subclasses

  • Eliminates binding of application-specific subclasses

  • Connects parallel class hierarchies

  • A related pattern is AbstractFactory

Product

Creator

operation()

Product createProduct()

ConcreteProduct

ConcreteCreator

operation()

Product createProduct()

return new ConcreteProduct();


Factory method 2
Factory Method (2)

  • Example: creating manipulators on connectors

Interactor

0..1

Figure

Manipulator

createManipulator()

attach(Figure)

ArcManipulator

RectFigure

Connector

BoundsManipulator

attach(Figure)

attach(Figure)

createManipulator()

createManipulator()

manip = new ArcManipulator();

manip = new BoundsManipulator();


Chain of Responsibility

  • Decouple sender of a request from receiver

  • Give more than one object a chance to handle

  • Flexibility in assigning responsibility

  • Often applied with Composite

successor

Client

Handler

ContextInterface()

handleRequest()

ConcreteHandler2

ConcreteHandler1

handleRequest()

handleRequest()


Chain of responsibility 2
Chain of Responsibility (2)

  • Example: handling events in a graphical hierarchy

If interactor != null

interactor.handle(event,this)

else

parent.handleEvent(event)

0..*

0..1

0..*

Interactor

Figure

children

handle(Event,Figure)

handleEvent(Event)

CompositeFigure

parent


Patterns vs design
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 domain

  • Patterns provide structure to “design”


Patterns vs frameworks
Patterns vs Frameworks

  • Patterns are lower-level than frameworks

  • Frameworks typically employ many patterns:

    • Factory

    • Strategy

    • Composite

    • Observer

  • Done well, patterns are the “plumbing” of a framework


Patterns vs architecture
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
Online resources

  • Pattern FAQ

    • http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html

  • Patterns home page

    • http://hillside.net/patterns/

  • Beispieleiner (GUI) “Pattern Library”

    • http://www.welie.com/patterns/showPattern.php


  • Concluding remarks
    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!



    ad