CEN 5011 10 th Lecture Advance Software Engineering (CEN-5011) Instructor: Masoud Sadjadi sadjadi/...
-
Upload
mercy-hardy -
Category
Documents
-
view
216 -
download
0
Transcript of CEN 5011 10 th Lecture Advance Software Engineering (CEN-5011) Instructor: Masoud Sadjadi sadjadi/...
CEN 5011 10th Lecture
Advance Software Engineering (CEN-Advance Software Engineering (CEN-5011)5011)
Instructor: Masoud Sadjadi
http://www.cs.fiu.edu/~sadjadi/
Object Design: Object Design: Reuse and Patterns IIReuse and Patterns II
10th Lecture 2CEN 5011: Advanced Software Engineering
AcknowledgementsAcknowledgements
Dr. Bernd Bruegge
Dr. Allen Dutoit
Dr. Betty Cheng
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 3CEN 5011: Advanced Software Engineering
AgendaAgenda
Motivation
Overview
Some Design Patterns
Summary
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 4CEN 5011: Advanced Software Engineering
Motivation Motivation (1)(1)
Developing software is hard
Designing reusable software is more challenging– finding good objects and abstractions– flexibility, modularity, elegance reuse– 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
10th Lecture 5CEN 5011: Advanced 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
10th Lecture 6CEN 5011: Advanced 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 Ontologies and taxonomies
– Have organizational structure: Memory limitations are overcome with an appropriate
representation (“natural model”)
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 7CEN 5011: Advanced 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
10th Lecture 8CEN 5011: Advanced 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
10th Lecture 9CEN 5011: Advanced Software Engineering
AgendaAgenda
Motivation
Overview
Some Design Patterns
Summary
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 10CEN 5011: Advanced 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– Then 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
10th Lecture 11CEN 5011: Advanced 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 datastructures (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
10th Lecture 12CEN 5011: Advanced Software Engineering
Design Patterns Design Patterns (2)(2)
Describes recurring design structure– names, abstracts from concrete designs
– identifies classes, collaborations, responsibilities
– 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.
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 13CEN 5011: Advanced Software Engineering
Essential ElementsEssential Elements
Pattern name
Problem
Solution
Consequences
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 14CEN 5011: Advanced Software Engineering
ApplicationsApplications
Wide variety of application domains:– drawing editors, banking, CAD, CAE, cellular
network management, telecomm switches, program visualization
Wide variety of technical areas:– user interface, communications, persistent objects,
O/S kernels, distributed systems
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 15CEN 5011: Advanced Software Engineering
Why are modifiable designs?Why are modifiable designs?
A modifiable design enables…
…an iterative and incremental development cycle– concurrent development– risk management– flexibility to change
…to minimize the introduction of new problems when fixing old ones
…to deliver more functionality after initial delivery
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 16CEN 5011: Advanced Software Engineering
What makes a design What makes a design modifiable?modifiable?
Low coupling and high cohesion Clear dependencies Explicit assumptions
How do design patterns help?
They are generalized from existing systems They provide a shared vocabulary to
designers They provide examples of modifiable designs
– Abstract classes– Delegation
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 17CEN 5011: Advanced Software Engineering
Design Pattern SpaceDesign Pattern Space
Creational patterns:– Deal with initializing and configuring classes and
objects
Structural patterns:– Deal with decoupling interface and implementation
of classes and objects– Composition of classes or objects
Behavioral patterns:– Deal with dynamic interactions among societies of
classes and objects– How they distribute responsibility
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 18CEN 5011: Advanced Software Engineering
Categorize Design PatternsCategorize Design Patterns
Creational Structural Behavioral
Factory Method
Abstract Factory
PrototypeSingleton
Builder
Adapter (class)
Adapter (object)Bridge
FlyweightDecorator
Proxy
Composite
Facade
Template MethodChain of ResponsibilityCommandIteratorMediatorMementoObserverStateStrategy
Interpreter
Visitor
Purpose
Class
Object
Scope
Abstract Factory
Adapter (class)
Adapter (object)Bridge
Proxy
Composite
Facade
Command
Observer
Strategy
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 19CEN 5011: Advanced Software Engineering
AgendaAgenda
Motivation
Overview
Some Design Patterns
Summary
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 20CEN 5011: Advanced Software Engineering
Composite PatternComposite Pattern
Models tree structures that represent part-whole hierarchies with arbitrary depth and width.
The Composite Pattern lets client treat individual objects and compositions of these objects uniformly
Client Component
Leaf
Operation()
CompositeOperation()
AddComponentRemoveComponent()
GetChild()
Children
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 21CEN 5011: Advanced Software Engineering
ExampleExample
Client Component
Leaf
Operation()
Composite
Operation()AddComponent
RemoveComponent()GetChild()
Children
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 22CEN 5011: Advanced Software Engineering
Example: Java AWT PackageExample: Java AWT Package
Graphics
Component
Button
TextField
Label
*
TextArea
TextComponent
Container
add(Component c)paint(Graphics g)
getGraphics()
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 23CEN 5011: Advanced Software Engineering
Adapter patternAdapter pattern
Delegation is used to bind an Adapter and an Adaptee
Interface inheritance is used to specify the interface of the Adapter class.
Target and Adaptee (usually called legacy system) pre-exist the Adapter.
ClientClientInterface
Request()
LegacyClass
ExistingRequest()
Adapter
Request()
adaptee
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 24CEN 5011: Advanced Software Engineering
Adapter PatternAdapter Pattern
“Convert the interface of a class into another interface clients expect.”
The adapter pattern lets classes work together that couldn’t otherwise because of incompatible interfaces
Used to provide a new interface to existing legacy components (Interface engineering, reengineering).
Also known as a wrapper Two adapter patterns:
– Class adapter: Uses multiple inheritance to adapt one interface to another
– Object adapter: Uses single inheritance and delegation
Object adapters are much more frequent. We will only cover object adapters (and call them therefore simply adapters)
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 25CEN 5011: Advanced Software Engineering
Bridge PatternBridge Pattern
Use a bridge to “decouple an abstraction from its implementation so that the two can vary independently”. (From [Gamma et al 1995])
Also know as a Handle/Body pattern.
Allows different implementations of an interface to be decided upon dynamically.
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 26CEN 5011: Advanced Software Engineering
Bridge PatternBridge Pattern
Abstraction
Operation()
imp
Client
Imp->OperationImp();
Concrete Implementor B
OperationImpl()
Refined Abstraction 2
Operation()
Refined Abstraction 1
Operation()
Concrete Implementor A
OperationImpl()
Implementor
OperationImpl()
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 27CEN 5011: Advanced Software Engineering
Using a BridgeUsing a Bridge
The bridge pattern is used to provide multiple implementations under the same interface.
Examples: Interface to a component that is incomplete, not yet known or unavailable during testing
JAMES Project: if seat data is required to be read, but the seat is not yet implemented, known, or only available by a simulation, provide a bridge
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 28CEN 5011: Advanced Software Engineering
ExampleExample
Client
Seat (in Vehicle Subsystem)
SeatImplementation
Stub Code SARTSeatAIMSeat
impGetPosition()SetPosition()
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 29CEN 5011: Advanced Software Engineering
Adapter vs BridgeAdapter vs Bridge
Similarities:– Both are used to hide the details of the underlying
implementation.
Difference:– The adapter pattern is geared towards making
unrelated components work together Applied to systems after they’re designed
(reengineering, interface engineering).
– A bridge, on the other hand, is used up-front in a design to let abstractions and implementations vary independently.
Green field engineering of an “extensible system” New “beasts” can be added to the “object zoo”, even
if these are not known at analysis or system design time.
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 30CEN 5011: Advanced Software Engineering
Facade PatternFacade Pattern
Provides a unified interface to a set of objects in a subsystem.
A facade defines a higher-level interface that makes the subsystem easier to use (i.e. it abstracts out the gory details)
Facades allow us to provide a closed architecture
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 31CEN 5011: Advanced Software Engineering
Example: Subsystem DesignExample: Subsystem Design
The ideal structure of a subsystem consists of – an interface object
– a set of application domain objects (entity objects) modeling real entities or existing systems
Some of the application domain objects are interfaces to existing systems
– one or more control objects
We can use design patterns to realize this subsystem structure
Realization of the Interface Object: Facade– Provides the interface to the subsystem
Interface to existing systems: Adapter or Bridge– Provides the interface to existing system (legacy system)
– The existing system is not necessarily object-oriented!
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 32CEN 5011: Advanced Software Engineering
Encouraging Reusable DesignsEncouraging Reusable Designs
A facade pattern should be used by all subsystems in a software system. The façade defines all the services of the subsystem.
Adapters should be used to interface to existing components.
Bridges should be used to interface to a set of objects. Use it for testing.
Model/View/Controller should be used when the interface changes much more rapidly than the application domain. Is MVC a DP?
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 33CEN 5011: Advanced Software Engineering
Proxy PatternProxy Pattern
What is expensive? – Object Creation– Object Initialization
Defer object creation and object initialization to the time you need the object
Proxy pattern:– Reduces the cost of accessing objects– Uses another object (“the proxy”) that acts as a
stand-in for the real object– The proxy creates the real object only if the user
asks for it
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 34CEN 5011: Advanced Software Engineering
Proxy patternProxy pattern
Interface inheritance is used to specify the interface shared by Proxy and RealSubject.
Delegation is used to catch and forward any accesses to the RealSubject (if desired)
Proxy patterns can be used for lazy evaluation and for remote invocation.
Proxy patterns can be implemented with a Java interface. Subject
Request()
RealSubject
Request()
Proxy
Request()
realSubject
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 35CEN 5011: Advanced Software Engineering
Proxy ApplicabilityProxy Applicability
Remote Proxy– Local representative for an object in a different
address space– Caching of information: Good if information does
not change too often Virtual Proxy
– Object is too expensive to create or too expensive to download
– Proxy is a standin Protection Proxy
– Proxy provides access control to the real object– Useful when different objects should have different
access and viewing rights for the same document. – Example: Grade information for a student shared by
administrators, teachers and students.
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 36CEN 5011: Advanced Software Engineering
Command PatternCommand Pattern
You want to build a user interface You want to provide menus You want to make the user interface reusable
across many applications– You cannot hardcode the meanings of the menus
for the various applications– The applications only know what has to be done
when a menu is selected.
Such a menu can easily be implemented with the Command Pattern
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 37CEN 5011: Advanced Software Engineering
Command patternCommand pattern
Client creates a ConcreteCommand and binds it with a Receiver.
Client hands the ConcreteCommand over to the Invoker which stores it.
The Invoker has the responsibility to do the command (“execute” or “undo”).
Command
execute()
Receiver
action()
Client
Invoker
ConcreteCommand
execute()
binds
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 38CEN 5011: Advanced Software Engineering
Command pattern ApplicabilityCommand pattern Applicability
“Encapsulate a request as an object, thereby letting you– parameterize clients with different requests,– queue or log requests, and – support undoable operations.”
Uses:– Undo queues– Database transaction buffering
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 39CEN 5011: Advanced Software Engineering
Observer patternObserver pattern
“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
10th Lecture 40CEN 5011: Advanced 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
10th Lecture 41CEN 5011: Advanced 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
10th Lecture 42CEN 5011: Advanced 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
10th Lecture 43CEN 5011: Advanced 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
10th Lecture 44CEN 5011: Advanced 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
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 45CEN 5011: Advanced Software Engineering
Abstract Factory MotivationAbstract Factory Motivation
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
10th Lecture 46CEN 5011: Advanced 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
10th Lecture 47CEN 5011: Advanced 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
10th Lecture 48CEN 5011: Advanced Software Engineering
AgendaAgenda
Motivation
Overview
Some Design Patterns
Summary
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 49CEN 5011: Advanced 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
10th Lecture 50CEN 5011: Advanced 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
10th Lecture 51CEN 5011: Advanced 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
10th Lecture 52CEN 5011: Advanced 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
behavior.
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 53CEN 5011: Advanced Software Engineering
Nonfunc. Reqs. Nonfunc. Reqs. Design Design Patterns Patterns (1)(1)
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
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary
10th Lecture 54CEN 5011: Advanced Software Engineering
Nonfunc. Reqs. Nonfunc. Reqs. Design Design Patterns Patterns (2)(2)
Text: “complex structure”, “must have variable depth and width” – Composite Pattern
Text: “must interface to an set of existing objects”– Façade Pattern
Text: “must be location transparent”– Proxy Pattern
Text: “must be extensible”, “must be scalable” – Observer Pattern
Text: “must provide a policy independent from the mechanism”– Strategy Pattern
OvervieOverview:w:Motivation
Overview
Design Patterns
Summary