CEN 4010 Ninth Lecture March 4, 2005 Introduction to Software Engineering (CEN- Introduction to Software Engineering (CEN- 4010) 4010) Spring 2005 Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/Classes/CEN- 4010/ Object Design: Object Design: Reuse and Patterns II Reuse and Patterns II
54
Embed
CEN 4010 Ninth Lecture March 4, 2005 Introduction to Software Engineering (CEN-4010) Spring 2005 Instructor: Masoud Sadjadi sadjadi/Classes/CEN-4010
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
CEN 4010 Ninth Lecture March 4, 2005
Introduction to Software Engineering (CEN-Introduction to Software Engineering (CEN-4010)4010)
Spring 2005
Instructor: Masoud Sadjadi
http://www.cs.fiu.edu/~sadjadi/Classes/CEN-4010/
Object Design: Object Design: Reuse and Patterns IIReuse and Patterns II
Ninth Lecture on March 4, 2005
2CEN 4010: Introduction to Software Engineering
AcknowledgementsAcknowledgements
Dr. Bernd Bruegge
Dr. Allen Dutoit
Dr. Betty Cheng
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
3CEN 4010: Introduction to Software Engineering
AgendaAgenda
Motivation
Overview
Some Design Patterns
Summary
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
4CEN 4010: Introduction to Software Engineering
Motivation Motivation (1)(1)
Developing software is hard
Designing reusable software is more challenging– finding good objects and abstractions– flexibility, modularity, elegance– takes time for them to emerge, trial and error
Successful designs do exist– exhibit recurring class and object structures
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
5CEN 4010: Introduction to Software Engineering
Motivation Motivation (2)(2)
During Object Modeling we do many transformations and changes to the object model.
It is important to make sure the object design model stays simple!
We show how to use design patterns to keep system models simple.
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
6CEN 4010: Introduction to Software Engineering
Motivation Motivation (3)(3)
Modeling must address our mental limitations: – Our short-term memory has only limited capacity (7+-2)
Good Models deal with this limitation, because they– Do not tax the mind
A good model requires only a minimal mental effort to understand
– Reduce complexity Turn complex tasks into easy ones (by good choice of
representation) Use of symmetries
– Use abstractions Ontology and taxonomy
– Have organizational structure: Memory limitations are overcome with an appropriate
representation (“natural model”)
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
7CEN 4010: Introduction to Software Engineering
Motivation Motivation (4)(4)
The hardest problems in object-oriented system development are: – Identifying objects– Decomposing the system into objects
Requirements Analysis – focuses on application domain– Object identification
System Design – addresses both, application and implementation
domain– Subsystem Identification
Object Design – focuses on implementation domain– Additional solution objects
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
8CEN 4010: Introduction to Software Engineering
Techniques for Finding ObjectsTechniques for Finding Objects
Requirements Analysis– Start with Use Cases. Identify participating objects– Textual analysis of flow of events (find nouns,
verbs, ...)– Extract application domain objects by interviewing
client (application domain knowledge)– Find objects by using general knowledge
System Design – Subsystem decomposition – Try to identify layers and partitions
Object Design– Find additional objects by applying implementation
domain knowledge
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
9CEN 4010: Introduction to Software Engineering
AgendaAgenda
Motivation
Overview
Some Design Patterns
Summary
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
10CEN 4010: Introduction to Software Engineering
Another Source of ObjectsAnother Source of Objects
Design Patterns
What are Design Patterns?– A design pattern describes a problem which occurs
over and over again in our environment– It describes the core of the solution to that problem,
in such a way that you can use the this solution a million times over, without ever doing it the same twice.
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
11CEN 4010: Introduction to Software Engineering
Design Patterns Design Patterns (1)(1)
A design pattern is…
…a template solution to a recurring design problem– Look before re-inventing the wheel just one more
time.
…reusable design knowledge– Higher level than classes or data structures (link
lists, binary trees...).– Lower level than application frameworks.
…an example of modifiable design– Learning to design starts by studying other designs.
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
12CEN 4010: Introduction to Software Engineering
Design Patterns Design Patterns (2)(2)
Describes recurring design structure– names, abstracts from concrete designs
– applicability, trade-offs, consequences Design patterns represent solutions to problems that
arise when developing software within a particular context– “Patterns == problem/solution pairs in a context”
Patterns capture the static and dynamic structure and collaboration among key participants in software designs– Especially good for describing how and why to resolve
non-functional issues
Patterns facilitate reuse of successful software architectures and designs.
“Encapsulate a request as an object, thereby letting you– parameterize clients with different requests,– queue or log requests, and – support undoable operations.”
“Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.”
Also called “Publish and Subscribe”
Uses:– Maintaining consistency across redundant state– Optimizing batch changes to maintain consistency
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
40CEN 4010: Introduction to Software Engineering
Observer patternObserver pattern
The Subject represents the actual state, the Observers represent different views of the state.
Observer can be implemented as a Java interface. Subject is a super class (needs to store the observers
vector) not an interface.
Observerupdate()
Subjectattach(observer)detach(observer)
notify()
ConcreteSubjectgetState()
setState(newState)subjectState
ConcreteObserverupdate()
observerState
observers
subject
*
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
41CEN 4010: Introduction to Software Engineering
Strategy PatternStrategy Pattern
Many different algorithms exists for the same task
Examples:– Breaking a stream of text into lines– Parsing a set of tokens into an abstract syntax tree– Sorting a list of customers
The different algorithms will be appropriate at different times– Rapid prototyping vs delivery of final product
We don’t want to support all the algorithms if we don’t need them
If we need a new algorithm, we want to add it easily without disturbing the application using the algorithm
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
42CEN 4010: Introduction to Software Engineering
Strategy PatternStrategy Pattern
Policy decides which Strategy is best given the current Context
StrategyAlgorithmInterface
Context
ContextInterface()
ConcreteStrategyC
AlgorithmInterface()
*
ConcreteStrategyB
AlgorithmInterface()
ConcreteStrategyA
AlgorithmInterface()
Policy
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
43CEN 4010: Introduction to Software Engineering
Example: A Database Example: A Database ApplicationApplication
StrategySort()
Database
Search()Sort()
Strategy *
BubbleSort
Sort()
QuickSort
Sort()
MergeSort
Sort()
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
44CEN 4010: Introduction to Software Engineering
Applicability of Strategy Applicability of Strategy PatternPattern
Many related classes differ only in their behavior. Strategy allows to configure a single class with one of many behaviors
Different variants of an algorithm are needed that trade-off space against time. All these variants can be implemented as a class hierarchy of algorithms
2 Examples Consider a user interface toolkit that supports
multiple looks and feel standards such as Motif, Windows 95 or the finder in MacOS.– How can you write a single user interface and make
it portable across the different look and feel standards for these window managers?
Consider a facility management system for an intelligent house that supports different control systems such as Siemens’ Instabus, Johnson & Control Metasys or Zumtobe’s proprietary standard.– How can you write a single control system that is
independent from the manufacturer?
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
46CEN 4010: Introduction to Software Engineering
Abstract FactoryAbstract Factory
AbstractFactory
CreateProductACreateProductB
CreateProductACreateProductB
AbstractProductA
ProductA1 ProductA2
AbstractProductB
ProductB1 ProductB2
ConcreteFactory1
CreateProductACreateProductB
ConcreteFactory2
Client
Initiation Assocation:Class ConcreteFactory2 initiates the
associated classes ProductB2 and ProductA2
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
47CEN 4010: Introduction to Software Engineering
ApplicabilityApplicability
Independence from Initialization or Represenation:– The system should be independent of how its products
are created, composed or represented Manufacturer Independence:
– A system should be configured with one family of products, where one has a choice from many different families.
– You want to provide a class library for a customer (“facility management library”), but you don’t want to reveal what particular product you are using.
Constraints on related products– A family of related products is designed to be used
together and you need to enforce this constraint Cope with upcoming change:
– You use one particular product family, but you expect that the underlying technology is changing very soon, and new products will appear on the market.
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
48CEN 4010: Introduction to Software Engineering
AgendaAgenda
Motivation
Overview
Some Design Patterns
Summary
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
49CEN 4010: Introduction to Software Engineering
Summary Summary (1)(1)
Design patterns are partial solutions to common problems such as– such as separating an interface from a number of
alternate implementations
– wrapping around a set of legacy classes
– protecting a caller from changes associated with specific platforms.
A design pattern is composed of a small number of classes – use delegation and inheritance
– provide a robust and modifiable solution.
These classes can be adapted and refined for the specific system under construction.– Customization of the system
– Reuse of existing solutions
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
50CEN 4010: Introduction to Software Engineering
Summary Summary (2)(2)
Structural Patterns– Focus: How objects are composed to form larger
structures– Problems solved:
Realize new functionality from old functionality, Provide flexibility and extensibility
Behavioral Patterns– Focus: Algorithms and the assignment of
responsibilities to objects– Problem solved:
Too tight coupling to a particular algorithm Creational Patterns
– Focus: Creation of complex objects– Problems solved:
Hide how complex objects are created and put together
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
51CEN 4010: Introduction to Software Engineering
Summary Summary (3) (3)
Composite: Model dynamic aggregates Facade: Interfacing to subsystems Adapter: Interfacing to existing systems Bridge: Interfacing to existing and future
systems Abstract Factory: Provide manufacturer
independence Proxy: Provide Location transparency Command: Encapsulate control flow Observer: Provide publisher/subscribe
mechanism Strategy: Support family of algorithms,
separate of policy and mechanism
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
Ninth Lecture on March 4, 2005
52CEN 4010: Introduction to Software Engineering
ConclusionsConclusions
Design patterns:
Provide solutions to common problems. Lead to extensible models and code. Can be used as is or as examples of interface
inheritance and delegation. Apply the same principles to structure and to
Read the problem statement again Use textual clues (similar to Abbot’s technique
in Analysis) to identify design patterns
Text: “manufacturer independent”, “device independent”, “must support a family of products”– Abstract Factory Pattern
Text: “must interface with an existing object”– Adapter Pattern
Text: “must deal with the interface to several systems, some of them to be developed in the future”, “ an early prototype must be demonstrated”– Bridge Pattern