Post on 13-Dec-2015
24 October 2006 Kaiser: COMS W4156 Fall 2006 1
COMS W4156: Advanced Software Engineering
Prof. Gail Kaiser
Kaiser+4156@cs.columbia.edu
http://york.cs.columbia.edu/classes/cs4156/
24 October 2006 Kaiser: COMS W4156 Fall 2006 2
Design Patterns
• A design pattern is a way of reusing abstract knowledge about a problem and its solution
• A pattern is a description of the problem and the essence of its solution
• A pattern should be sufficiently abstract to be reused in different settings
• Patterns often rely on object characteristics such as inheritance and polymorphism
24 October 2006 Kaiser: COMS W4156 Fall 2006 3
History of Design Patterns
• Architect Christopher Alexander– A Pattern Language (1977)– Several other books…– www.patternlanguage.com
“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. “
24 October 2006 Kaiser: COMS W4156 Fall 2006 4
Software Developers’ Lament
• “If only software engineering could be more like X ...”, where X is any design-intensive profession with a longer and apparently more successful history than software
• It is therefore both comforting and troubling to discover that the same fundamental philosophical, methodological and pragmatic concerns arise in all of these Xs
24 October 2006 Kaiser: COMS W4156 Fall 2006 5
History of Software Design Patterns
• “Gang of four”• Erich Gamma • Richard Helm• Ralph Johnson• John Vlissides
– Design Patterns: Elements of Reusable Object-Oriented Software (1995) – described 23 patterns (observed, not invented)
• Many conferences, symposia, books by many
24 October 2006 Kaiser: COMS W4156 Fall 2006 6
Design Patterns“A design pattern systematically names, motivates, and explains a
general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context.”
Pattern elements: • Name• Problem description• Solution description
– Not a concrete design but a template for a design solution that can be instantiated in different ways
• Consequences– The results and trade-offs of applying the pattern
24 October 2006 Kaiser: COMS W4156 Fall 2006 7
Types of Patterns• Creational
– Concerned with instantiation– Create objects for you, rather than having you instantiate objects
directly, giving your program more flexibility in deciding which objects need to be created for a given case
– Class-creation patterns use inheritance in the instantiation process while Object-creation patterns use delegation
• Structural– Concerned with composition– Help you compose groups of objects into larger structures– Use inheritance to compose interfaces or define other ways to compose
objects to obtain new functionality• Behavioral
– Concerned with communication– Help you define the communication between objects and how the flow is
controlled
24 October 2006 Kaiser: COMS W4156 Fall 2006 8
The Abstract Factory Pattern
• Creational• Creates an instance of any of a family of classes• Provide an interface for creating families of related or
dependent objects without specifying their concrete classes
• Useful for families of products and to enforce families of products that must be used together
• Promotes consistency among products • Example: DocumentCreator class that provides
interfaces to create instances of several kinds of documents, e.g., createLetter() and createResume()
24 October 2006 Kaiser: COMS W4156 Fall 2006 9
The Abstract Factory Pattern
• If you want to construct instances of a class, where the class is selected at run-time, then1. Create one abstract factory class for each existing
class (or group of related classes) you wish to create
2. Have a polymorphic “create instance” method on each abstract factory class, conforming to a common method signature, used to create instances of the corresponding class
3. Store and pass around instances of the abstract factory class to control selection of the class to create
24 October 2006 Kaiser: COMS W4156 Fall 2006 11
Other Creational Patterns
• Builder – separates complex object construction from its representation, so that same construction process can create different representations
• Factory Method – creates an instance of any of several derived classes, lets a class defer instantiation to subclasses
• Prototype – specify the kind of objects to create using a prototypical instance, a fully initialized instance is copied or cloned
• Singleton – a class of which only a single instance can exist, ensure the class has only one instance and provide a global point of access to it
24 October 2006 Kaiser: COMS W4156 Fall 2006 12
The Façade Pattern
• Structural• A single class that represents an entire subsystem• Provide a unified interface to a set of interfaces in a
subsystem• Defines a higher-level interface that makes the
subsystem easier to use• Applicable when need to provide a simple interface to a
complex system, to shield clients from subsystem components, or to provide a single entry point to a library or layer
• Often semantic wrapper of existing [legacy] objects• Example: Java Font and Graphics classes front for
dozens of classes for parsing font files and rendering text into geometric outlines and ultimately into pixels
24 October 2006 Kaiser: COMS W4156 Fall 2006 14
The Proxy Pattern
• Structural• Provide a surrogate or placeholder for another object to
control access to it• Several types:
– Virtual (or Lazy) – lazy instantiation, useful for holding off on creating resource-hungry objects until functionality actually needed by a client, also Copy-on-write
– Remote – hide the fact that the real object is in another address space and provide communication mechanisms between remote objects
– Synchronization – multiple accesses to target object, also Caching– Access (or Protection) – checks client’s access permissions, also
Firewall– Smart (or Decorator) – provide additional functionality to top of proxied
object
• Example: Reference counting pointer object
24 October 2006 Kaiser: COMS W4156 Fall 2006 16
The Adapter Pattern• Structural• Convert or wrap the interface of a class into
another interface clients expect• Lets classes work together that could not
otherwise because of incompatible interfaces• Makes heavy use of delegation• Example: Convert the interface of a
Document Object Model of an XML document into a tree structure that can be displayed.
24 October 2006 Kaiser: COMS W4156 Fall 2006 18
Other Structural Patterns
• Bridge – separates an object’s interface from its implementation, decouples an abstraction from its implementation so that the two can vary independently
• Composite – compose objects into a tree structure of simple and composite objects to represent part-whole hierarchies, lets clients treat individual objects and compositions of objects uniformly
• Decorator – attach additional responsibilities to an object dynamically, provides a flexible alternative to subclassing for extending functionality
• Flyweight – use sharing to support large numbers of fine-grained objects efficiently
24 October 2006 Kaiser: COMS W4156 Fall 2006 19
The Observer Pattern
• Behavioral• Separates the display of object state from the object
itself, e.g., when multiple distinct display views of state are needed (model-view-controller paradigm)
• Define a one to many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically
• Useful for dynamic relationships between objects, hook up a new observer while the program is running, unhook it later
• However, optimizations to enhance display performance may be impractical
24 October 2006 Kaiser: COMS W4156 Fall 2006 20
Example:Multiple displays enabled by Observer
Subject
A: 40B: 25C: 15D: 20
Observer 1 Observer 2
0
50
25
A B C D
A
B
C
D
24 October 2006 Kaiser: COMS W4156 Fall 2006 21
The Observer Pattern
Subject Observer
Attach (Observer)Detach (Observer)Notify ()
Update ()
ConcreteSubject
GetState ()
subjectState
ConcreteObserver
Update ()
observerState
return subjectState
for all o in observers o -> Update ()
observerState = subject -> GetState ()
24 October 2006 Kaiser: COMS W4156 Fall 2006 22
Styles of Observer Notification
• Push – observed “publishes” a change and observers get notified of the change
• Pull – observers repeatedly poll the observed to note changes
• The observed does not know anything about the observers
• Basis for publish-subscribe messaging architectures
24 October 2006 Kaiser: COMS W4156 Fall 2006 23
The Mediator Pattern
• Behavioral• Define an object that encapsulates how a set of
objects interact• Promotes loose coupling by keeping objects from
referring to each other explicitly, and allows to vary their interaction independently
• Defines simplified communication between classes where otherwise the interactions may be complex, with code buried inside those classes
• May limit subclassing, centralizes control • Example: Instant messaging
24 October 2006 Kaiser: COMS W4156 Fall 2006 25
More Behavioral Patterns• Chain of Responsibility – a way of passing a request
along a chain of objects, avoid coupling the sender of the request to its receiver by giving more than one object a chance to handle the request
• Command – encapsulate a command request as an object, used to parameterize clients with different requests, queue or log requests, and support undoable operations
• Interpreter – given a language, define a representation for its grammar along with an interpreter for sentences in this language
• Iterator – sequentially access the elements of a collection, access the elements of an aggregate object sequentially without exposing its underlying representation
24 October 2006 Kaiser: COMS W4156 Fall 2006 26
More Behavioral Patterns
• Memento – capture, externalize and restore an object’s internal state (without violating encapsulation)
• State – alter an object’s behavior when its internal state changes, the object will appear to change its class
• Strategy – define a family of algorithms, encapsulate each one inside a class, and make them interchangeable, let’s the algorithm vary independently from clients that use it
• Template Method – define the skeleton of an algorithm and defer (some) exact steps to subclasses, lets subclasses refine certain steps of an algorithm without changing the algorithm’s structure
• Visitor – defines a new operation on the elements of an object’s structure without changing its class
24 October 2006 Kaiser: COMS W4156 Fall 2006 27
Where to Get Code Examples
• GoF book defines 23, with sample C++ and Smalltalk• Sample C# code for all patterns at http://
www.dofactory.com/Patterns/Patterns.aspx • Sample Java code for all patterns at
http://www.patterndepot.com/put/8/JavaPatterns.htm • Some sample code in various languages (some each C+
+, Java, C#, Perl, Python) at http://en.wikipedia.org/wiki/Design_Patterns
• GOF member John Vlissides has another book, Pattern Hatching: Design Patterns Applied (1998), about using patterns – but requires C++ intimacy
• Other authors have proposed various additional patterns, often with code
24 October 2006 Kaiser: COMS W4156 Fall 2006 28
Guiding Themes
• Program to an interface and not to an implementation– Define the top of any class hierarchy with an abstract class,
which implements no methods, but simply defines the methods the class will support
– Then in all your derived classes, you have more freedom to implement these methods as most suits your purposes
• Favor object composition over inheritance– Construction of objects that contain or encapsulate several other
objects– Your new object can have the interface that is best for what you
want to accomplish without having all the methods of the parent classes
24 October 2006 Kaiser: COMS W4156 Fall 2006 29
Project Deliverables
• Project concept (P/F)• Revised concept (P/F)• First iteration (25%)
– 1st iteration plan (5%)– 1st iteration progress
report (5%)– 1st iteration demo (5%)– 1st iteration final report
(10%)
• Second iteration (25%)– 2nd iteration plan – Code inspection– 2nd iteration progress
report – 2nd iteration demo– 2nd iteration final report
24 October 2006 Kaiser: COMS W4156 Fall 2006 30
Demo due November 8-14
• 15-20 minutes total including any "setup" time• Schedule
– With Prof. Kaiser for in/after class time (Thursday November 9th or Tuesday November 14th, 11-12:15 or 12:30-1:30)
– With your TA otherwise• Be prepared to show the code corresponding to
any portion of the demo system• Be prepared to describe your system's utilization
of the component model framework.• One representative of each pair must be present
at the demo
24 October 2006 Kaiser: COMS W4156 Fall 2006 31
First Iteration Progress Report due November 14th
• The purpose of this assignment is to revise your requirements, architecture and component-level design to reflect realityreality, and to evaluate your use of the chosen component model framework.
• Revise your requirements:– Include your complete set of requirements (use cases
or user stories).– For any requirements that changed, show the new
version of the requirement and explain the difference.– Indicate any requirements that have been dropped. – If any features are only partially completed, describe
what does and does not work.
24 October 2006 Kaiser: COMS W4156 Fall 2006 32
First Iteration Progress Report due November 14th
• Revise your high-level architecture and lower-level design.
• Diagram and explain the process-level architecture of your system, including all communication paths.
• Describe the major expected "workflows" that a user would achieve with the system and explain the corresponding interactions among the architectural units during those scenarios.
• Consider both end-users and administrators, if applicable.
24 October 2006 Kaiser: COMS W4156 Fall 2006 33
First Iteration Progress Report due November 14th
• For each internal architectural subsystem, break down into components.
• Diagram and explain the use of interfaces and control and data flows among the components.
• Indicate any previously planned subsystems, communication paths, components, interfaces, etc. that are "missing" for whatever reason from your system.
• Explain the roles of any external "systems" - e.g., databases, web browsers, facilities provided by the component model framework.
24 October 2006 Kaiser: COMS W4156 Fall 2006 34
First Iteration Progress Report due November 14th
• Describe how you leveraged the main aspects of the component model framework
• Or "worked around" them if that is indeed what you did. • Consider the main services provided by the framework,
and discuss any you considered using - both those you did end up using and those you did not (and why not).
• Discuss any "challenges" that arose in deploying or utilizing the framework, and how you resolved them.
• State which specific implementation of the component model framework you used, including version number and where you got it from (e.g., url).
24 October 2006 Kaiser: COMS W4156 Fall 2006 35
DeliverablesAn archive (e.g., a .zip file) with a main document that includes:1. Cover page (1 page): Indicate the name of your team and list all
team members with their full names and email addresses. Indicate that this document presents your First Iteration Final Report.
2. Revised Requirements (no maximum page limit). 3. Revised high-level architecture and component-level design (no
maximum page limit).4. Component-model framework (no maximum page limit).5. Controversies (maximum 1 page).Additional files in the archive should include:6. The complete code for your system. Include a README file with
installation instructions and a brief description of how to run the system.
24 October 2006 Kaiser: COMS W4156 Fall 2006 36
Upcoming
• First iteration progress report due October 31st
• First demo week November 8-14
• First iteration final report due November 14
24 October 2006 Kaiser: COMS W4156 Fall 2006 37
COMS W4156: Advanced Software Engineering
Prof. Gail Kaiser
Kaiser+4156@cs.columbia.edu
http://york.cs.columbia.edu/classes/cs4156/