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