COMS W4156: Advanced Software Engineering - PowerPoint PPT Presentation

Loading...

PPT – COMS W4156: Advanced Software Engineering PowerPoint presentation | free to download - id: 544aa2-OTA0M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

COMS W4156: Advanced Software Engineering

Description:

Title: Project management Last modified by: Gail Kaiser Created Date: 12/8/1995 5:21:36 PM Document presentation format: A4 Paper (210x297 mm) Other titles – PowerPoint PPT presentation

Number of Views:101
Avg rating:3.0/5.0
Slides: 86
Provided by: pslCsCol
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: COMS W4156: Advanced Software Engineering


1
COMS W4156 Advanced Software Engineering
  • Prof. Gail Kaiser
  • Kaiser4156_at_cs.columbia.edu
  • http//bank.cs.columbia.edu/classes/cs4156/

2
Topics covered in this lecture
  • General Design Goals
  • Design Patterns

3
Design Goals
4
Design Goals
  • Within a class (or component)
  • High Cohesion
  • Completeness
  • Convenience
  • Clarity
  • Consistency
  • Across classes (or components)
  • Low Coupling

5
Cohesion and Coupling
  • Cohesion is a property or characteristic of an
    individual unit
  • Coupling is a property of a collection of units
  • High cohesion GOOD, high coupling BAD
  • Design for change
  • Reduce interdependency (coupling) You don't want
    a change in one unit to ripple throughout your
    system
  • Group functionality (cohesion) Easier to find
    things, intuitive metaphor aids understanding

6
Cohesion
  • The measure of strength of the association of
    elements within a unit
  • Cohesion scale
  • Functional cohesion (strongest, most desirable)
  • Sequential cohesion
  • Communicational cohesion
  • Procedural cohesion
  • Temporal cohesion
  • Logical cohesion
  • Coincidental cohesion (weakest, undesirable)

7
Cohesion
  • Coincidental cohesion - elements have no
    meaningful relationship to one another
  • Logical cohesion - elements perform similar
    activities, but the activities to be executed are
    chosen from outside the unit
  • Temporal cohesion - elements are related in time
    (all should be done together)

8
Cohesion
  • Communicational cohesion - elements perform
    different functions, but each function references
    the same input or output information
  • Sequential (or informational) cohesion - elements
    are related such that output data from one serves
    as input data to the next
  • Functional cohesion - elements contribute to a
    single, well-defined task

9
Coupling
  • A measure of the interdependence of one software
    unit to another
  • Coupling scale
  • Content coupling (worst)
  • Common coupling
  • Control coupling
  • Stamp coupling
  • Data coupling (best / minimal needed
    coupling)
  • No direct coupling

10
Coupling
  • No Direct Coupling - Independent
  • Data Coupling - Communicate by passing parameters
  • Stamp Coupling - Communicate via a passed data
    structure that contains more information than
    necessary for the two units to perform their
    functions

11
Coupling
  • Control Coupling - Communicate using at least one
    "control flag"
  • Common Coupling - Share the same global data area
  • Content Coupling
  • One unit changes a statement in another (usually
    applicable only to interpreted languages)
  • One unit references or alters data contained
    inside another
  • One unit branches into another

12
Design Goals
  • Within a class (or component)
  • High Cohesion
  • Completeness
  • Convenience
  • Clarity
  • Consistency
  • Across classes (or components)
  • Low Coupling

13
Naming Conventions
  • Most modern programming languages supply their
    own naming conventions (learn it, use it! Java,
    C, C)
  • Otherwise, choose a scheme at design-time and
    stick to it at coding-time
  • For components, interfaces, classes, types,
    methods, exceptions, members, parameters,
    variables,

14
Separation of Concerns
  • The programmer is having to do several things at
    the same time
  • describe what is to be computed
  • organize the computation sequencing into small
    steps
  • organize memory management during the
    computation.
  • Ideally, the programmer should be able to
    concentrate on one of the three tasks (describing
    what is to be computed) without being distracted
    by the other two, more administrative, tasks.
    Chris Reade, Elements of Functional Programming,
    1989

15
Design Patterns
16
Design Pattern
  • A general repeatable solution to a commonly
    occurring problem
  • A description of the problem and the essence of
    its solution
  • Should be sufficiently abstract to be reused in
    different settings
  • Designed to avoid re-design
  • Allow developers to communicate using well known,
    well understood names for software interactions

17
Example Delegation
  • An object outwardly expresses certain behavior
    but in reality delegates responsibility for
    implementing that behavior to an associated
    object
  • Very general concept, refined in several more
    specific design patterns

18
Example Delegation
  • class A
  • void f() System.out.println("A doing
    f()")
  • void g() System.out.println("A doing
    g()")
  • class C
  • // delegation
  • A a new A()
  • void f() a.f()
  • void g() a.g()
  • // normal attributes
  • X x new X()
  • void y() / do stuff /
  • public class Main
  • public static void main(String args)
  • C c new C()
  • c.f()
  • c.g()

19
Example Proxy Pattern
  • An object functions as an interface to another
    object
  • Provide a surrogate or placeholder that uses an
    extra level of indirection to support
    distributed, controlled or intelligent access to
    an object
  • In its most general form, a proxy is ltsomethinggt
    functioning as an interface to ltsomething elsegt.
    The ltsomething elsegt could be anything a network
    connection, a large object in memory, a file, or
    some other resource

20
Non-Software Proxy Pattern
21
Software Proxy Pattern
22
Discussion Proxy
  • Maintains a reference that lets it access the
    real subject
  • Provides an interface identical to the subject's,
    so that a proxy can be substituted for the real
    subject
  • Controls access to the real subject and may be
    responsible for creating and deleting it
  • May also
  • Count the number of references to the real object
    so that it can be freed automatically when there
    are no more references
  • Load a persistent object into memory when it's
    first referenced
  • Check that the real object is locked before it is
    accessed to ensure that no other object can
    change it

23
Types of Proxies
  • Remote proxies are responsible for encoding a
    request and its arguments and for sending the
    encoded request to the real subject in a
    different address space
  • Virtual proxies are placeholders for expensive
    to create or resource hungry objects, may
    cache additional information about the real
    subject so that they can postpone accessing it
  • Protection proxies check that the caller has the
    access permissions required to perform a request
    and may provide different clients with different
    levels of access
  • Others copy-on-write, cache, synchronization,

24
Proxy Pattern Example
25
Example Façade Pattern
  • A single class that represents an entire
    subsystem or library
  • Provides a unified interface to a set of
    interfaces
  • May simplify by providing convenient methods for
    common tasks that internally involve multiple
    classes/methods
  • Often semantic wrapper of existing legacy
    objects

26
Non-Software Façade Pattern
27
Software Façade Pattern
28
Discussion Façade
  • Knows which subsystem classes are responsible for
    a request and delegates client requests to
    appropriate objects
  • Subsystem classes handle work assigned by façade
    but have no knowledge of the façade and keep no
    reference to it
  • Reduces dependencies of outside code on the inner
    workings of a subsystem
  • May reduce learning curve for novice users but be
    insufficient for power users

29
Façade Pattern Example
30
History of Design Patterns
  • (Building) 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.

31
History of Software Design Patterns
  • Arose from frameworks like Model-View-Controller
    (MVC) used in early OO programming, notably
    Smalltalk
  • Gang of Four (GoF) 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,

32
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. GoF

33
Design 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

34
Design Pattern Elements (Expanded)
  • name and classification
  • intent
  • also known as
  • motivation
  • applicability
  • structure
  • participants
  • collaborations
  • consequences
  • implementation
  • sample code
  • known uses
  • related patterns

35
Original Catalog of Patterns
Purpose Purpose Purpose
Creational Structural Behavioral
Scope Class Abstract Method Adapter (class) Interpreter Template Method
Scope Object Abstract Factory Builder Prototype Singleton Adapter (object) Bridge Composite Decorator Façade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor
36
Creational Patterns
  • Concerned with instantiation
  • Create objects for you, rather than having you
    instantiate objects directly

37
Creational Patterns
  • Factory Method creates an instance of several
    derived classes
  • Abstract Factory creates an instance of several
    families of classes
  • Singleton a class of which only a single
    instance can exist, ensures the class has only
    one instance and provides a global point of
    access to it

38
Factory Method Pattern
  • Define an interface for creating an object, but
    let subclasses decide which class to instantiate
  • Lets a class defer instantiation to subclasses
  • Common in toolkits and frameworks where library
    code needs to create objects of types that may be
    subclassed by applications using the framework
  • More generally, the term factory method is often
    used to refer to any method whose main purpose is
    creation of objects

39
Non-Software Factory Method Pattern
40
Software Factory Method Pattern
41
Discussion Factory Method
  • Defines a "virtual" constructor
  • Unlike a constructor, factory methods can have
    different and more descriptive names
  • Unlike a constructor, an existing object might be
    reused, instead of a new object created (object
    pooling)
  • The new operator considered harmful (make all
    constructors private or protected)

42
Factory Method Pattern Example
  • class Complex
  • public static Complex fromCartesian(double
    real, double imag)
  • return new Complex(real, imag)
  • public static Complex fromPolar(double rho,
    double theta)
  • return new Complex(rho cos(theta), rho
    sin(theta))
  • private Complex(double a, double b)
  • //...
  • Complex c Complex.fromPolar(1, pi)

43
Abstract Factory Pattern
  • 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()

44
Non-Software Abstract Factory Pattern
45
Software Abstract Factory Pattern
46
Discussion Abstract Factory
  • Coordinates the instantiation of sets of objects
    that have varying implementations in such a way
    that only legitimate combinations of instances
    are possible, and hides these concrete instances
    behind a set of abstractions
  • Hides from consuming (client) objects
  • The number of sets of instances supported by the
    system
  • Which set is currently in use
  • The concrete types that are instantiated at any
    point
  • The issue upon which the sets vary (might be
    determined from a config file, deployment
    descriptor, administrative GUI, etc.)

47
Abstract Factory Pattern Example
48
Singleton Pattern
  • Allow for only one instance of a given class to
    ever exist (encapsulates that the number of
    instances is constrained)
  • Provides a mechanism to obtain this instance that
    any client can access
  • Examples include objects needed for logging,
    communication, database access, etc.

49
Non-Software Singleton Pattern
50
Software Singleton Pattern
51
Discussion Singleton
  • Typically instantiated lazily - the instance is
    not created until it is needed, perhaps never
  • If stateful, analogous to a global variable (with
    many of the same problems as a global variable,
    e.g., unexpected side-effects)
  • May need to ensure thread safety (if it is
    possible for one thread to be engaged in the
    creation of the instance while another is
    checking for null, possibly resulting in two
    instances)
  • Can scale to two, three or more instances for
    load-balancing

52
Singleton Pattern Example
53
Other Creational Patterns
  • Builder separate the construction of a complex
    object from its representation so that the same
    construction process can create different
    representations
  • Prototype specify the kind of objects to create
    using a prototypical instance a fully
    initialized instance is copied or cloned (not the
    same as prototypes used during software
    engineering lifecycle requirements phase)

54
Structural Patterns
  • Concerned with composition
  • Help you compose groups of objects into larger
    structures
  • Eases design by identifying a simple way to
    realize relationships between entities

55
Structural Patterns
  • Proxy - a class functioning as an interface to
    another thing
  • Façade - creates a simplified interface of an
    existing interface to ease usage for common tasks
  • Adapter 'adapts' one interface for a class into
    an interface that a client expects

56
Adapter Pattern
  • Convert or wrap the interface of a class into
    another interface clients expect
  • Useful when an already existing class provides
    some or all of the services needed but does not
    provide the interface needed
  • Lets classes work together that could not do so
    otherwise because of incompatible interfaces
  • Example Convert the interface of a Document
    Object Model of an XML document into a tree
    structure that can be displayed

57
Non-Software Adapter Pattern
58
Software Adapter Pattern
59
Discussion Adapter
  • Creates an intermediary abstraction that
    translates, or maps, the old component to the new
    system
  • Makes heavy use of delegation where the delegator
    is the adapter (or wrapper) and the delegate is
    the class being adapted
  • Responsible for handling any logic necessary to
    transform data into a form that is useful for the
    consumer
  • Can wrap either an individual object instance or
    an aggregation of multiple object instances, and
    operate at either object or class level

60
Adapter Pattern Example
61
Individual Object Adapter
62
Aggregate Adapter
63
Object Adapter
64
Class Adapter
65
Other Structural Patterns
  • Bridge separates a varying entity from a
    varying behavior, decouples an abstraction from
    its implementation so that the two can vary
    independently (analogous to branching conditional
    logic)
  • 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 (e.g., root vs. internal vs. leaf node)
  • Decorator attach additional behavior(s) to an
    object dynamically, provides a flexible
    alternative to subclassing for extending
    functionality (e.g., pre and post processing)
  • Flyweight use sharing to support large numbers
    of fine-grained objects efficiently (e.g., each
    character object in a word processor shares
    reference to same object with font, formatting,
    etc.)

66
Behavioral Patterns
  • Concerned with communication
  • Identify common communication patterns between
    objects and realize these patterns
  • Help you define the communication between objects
    and how the flow is controlled

67
Behavioral Patterns
  • Observer (Publish/Subscribe or Event Listener) -
    objects register to observe an event that may be
    raised by another object
  • Mediator - simplifies communication between
    classes

68
Observer Pattern
  • Define a one to many dependency between objects
    so that when one object changes state, all its
    dependents are notified and updated automatically
  • Encapsulate the core (or common or engine)
    components in a Subject abstraction, and the
    variable (or optional or user interface)
    components in an Observer hierarchy

69
Non-Software Observer Pattern
70
Software Observer Pattern
71
Discussion Observer
  • Useful for dynamic relationships between objects,
    hook up a new observer while the program is
    running, unhook it later
  • Often associated with the model-view-controller
    (MVC) paradigm separates the display of object
    state from the object itself, e.g., when multiple
    distinct display views of state are needed
  • Possible optimizations such as event compression
    (only sending a single change broadcast after a
    series of consecutive changes has occurred)

72
Styles of Observer Notification
  • Push subject publishes a change and observers
    get notified of the change
  • Pull observers repeatedly poll the subject to
    note changes
  • The subject does not know anything about the
    observers
  • A single observer may monitor multiple subjects

73
Example Multiple Displays Enabled by Observer
74
Mediator Pattern
  • 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
  • Example Instant messaging

75
Non-Software Mediator Pattern
76
Software Mediator Pattern
77
Discussion Mediator
  • Design an intermediary to decouple and
    orchestrate many peers promotes the many-to-many
    relationships between interacting peers to "full
    object status
  • Like façade, provides a unified interface to a
    set of interfaces in a subsystem different from
    façade in that the underlying classes interact
    with each other through the mediator
  • Façade defines a simpler interface to a subsystem
    - it doesn't add new functionality, and it is not
    known by the subsystem classes (i.e., it defines
    a unidirectional protocol where it makes requests
    of the subsystem classes but not vice versa)

78
Mediator Pattern Example
79
More Behavioral Patterns
  • Chain of Responsibility a way of passing a
    request along a chain of objects or choosing
    among a set 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 implements a specialized computer
    language grammar to solve a specific set of
    problems (e.g., SQL)
  • Iterator sequentially access the elements of a
    collection iterate through the elements of an
    aggregate object sequentially without exposing
    its underlying representation

80
More Behavioral Patterns
  • Memento capture, externalize and restore an
    objects internal state (without violating
    encapsulation)
  • State alter an objects 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 lets 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 algorithms
    structure
  • Visitor - defines a new operation on the elements
    of an objects structure without changing its
    class

81
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
  • Sample Java and C code for all patterns
    http//www.vincehuston.org/dp/, also see Who ya
    gonna call?

82
Summary
  • Design Patterns write down and catalog common
    interactions between objects (or classes or
    components) that programmers have frequently
    found useful
  • Primarily applicable to OO programming, but also
    applies to some non-OO programming
  • A great source of intuition particularly wrt
    testing and cost-benefit issues, but only covers
    subset of patterns, at http//www.netobjectivesrep
    ository.com/

83
  • Upcoming Assignments

84
Upcoming Assignments
  • First Iteration Plan due Tuesday 19 October.
  • First Iteration Progress Report due Tuesday 26
    October.
  • First Iteration Demo Wednesday 3 November
    Thursday 11 November.
  • First Iteration Final Report due Friday 12
    November.

85
COMS W4156 Advanced Software Engineering
  • Prof. Gail Kaiser
  • Kaiser4156_at_cs.columbia.edu
  • http//bank.cs.columbia.edu/classes/cs4156/
About PowerShow.com