final patterns in ooad 312 5 may 16 updated 7 may

What is a Pattern?"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“ (Christopher Alexander)

What is a Pattern?• “Pattern is a named and well-known problem/solution pair that can be applied in new contexts, with advice on how to apply it in novel situations and discussion of its trade-offs, implementations, variations, and so forth.” (Craig Larman)

What is a Design Pattern?

• A technique to repeat designer success.

• Borrowed from Civil and Electrical Engineering domains.

A (Problem, Solution) pair.

How Patterns are used?• Design Problem.• Solution.• Implementation details.

Reduce gap

Design Implementation

Designer

Programmer

Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design patterns: elements of reusable object-oriented software. 1995.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M.: Pattern-oriented software architecture: a system of patterns. 2002.

Design Pattern： An Introduction

Outline• Background• What is a Design Pattern?• Why Design Pattern?• Description of Design Patterns.• Goals of Design Patterns• Classifications of Design Patterns.• Organization of Design Patterns• How Design Patterns Solve Design Problems.• Benefits of Design Patterns.• Liability of Design Patterns.

Patterns

• “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.”

---Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, Shlomo Angel, “A Pattern Language: Towns/Buildings/ Construction”, Oxford University Press, New York, 1977

• …

Background• In 1987, Kent Beck and Ward Cunningham began

experimenting with the idea of applying patterns to programming and presented their results at the OOPSLA conference that year.

----Beck, Kent; Ward Cunningham (September 1987). "Using Pattern Languages for Object-Oriented Program". OOPSLA '87 workshop on Specification and Design for Object-Oriented Programming. OOPSLA '87. http://c2.com/doc/oopsla87.html

http://en.wikipedia.org/wiki/OOPSLA

5. Design Patterns

• Are the answer to a question that commonlyarises “How can I … ?”

• Patterns record successful solutions in software development for sharing between projects.

• Gang of Four (GoF) Gamma, Helm, Johnson, Vlissides, - founders of movement.

• Gamma et al, Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995.

Definitions

• A pattern is a recurring solution to a standard problem, in a context.

• Christopher Alexander, a professor of architecture…• Why would what a prof of architecture says be relevant to

software?• “A 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.”

Patterns in engineering• How do other engineers find and use patterns?

• Mature engineering disciplines have handbooks describing successful solutions to known problems

• Automobile designers don't design cars from scratch using the laws of physics

• Instead, they reuse standard designs with successful track records, learning from experience

• Should software engineers make use of patterns? Why?• “Be sure that you make everything according to the pattern

I have shown you here on the mountain.” Exodus 25:40.

• Developing software from scratch is also expensive • Patterns support reuse of software architecture and design

The “gang of four” (GoF)• Erich Gamma, Richard Helm, Ralph Johnson

& John Vlissides (Addison-Wesley, 1995)• Design Patterns book catalogs 23 different patterns as

solutions to different classes of problems, in C++ & Smalltalk• The problems and solutions are broadly applicable, used by

many people over many years• What design pattern did we discover with the Undo problem?

• Why is it useful to learn about this pattern?• Patterns suggest opportunities for reuse in analysis, design

and programming• GOF presents each pattern in a structured format

• What do you think of this format? Pros and cons?

http://www.tml.hut.fi/~pnr/GoF-models/html/

http://en.wikipedia.org/wiki/Design_pattern_(computer_science)#Documentation

Design Patterns are NOT

• Not Data structures that can be encoded in classes and reused as is (i.e., linked lists, hash tables)

• Complex domain-specific designs (for an entire application or subsystem)

• If they are not familiar data structures or complex domain-specific subsystems, what are they?

• They are:• “Descriptions of communicating objects and classes

that are customized to solve a general design problem in a particular context.”

Elements of Design Patterns

• Design patterns have 4 essential elements:• Pattern name: increases vocabulary of designers• Problem: intent, context, when to apply • Solution: UML-like structure, abstract code• Consequences: results and tradeoffs

Three Types of Patterns

• 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

5.1. Types of Pattern

There are 3 types of pattern …• Creational: address problems of creating an object

in a flexible way. Separate creation, from operation/use.

• Structural: address problems of using O-O constructs like inheritance to organize classes and objects

• Behavioral: address problems of assigning responsibilities to classes. Suggest both static relationships and patterns of communication(use cases)

5.2. Patterns, Architectures & Frameworks

• There can be confusion between patterns, architectures and frameworks.

• Let’s try to distinguish them:

• Architectures model software structure at the highest possible level, and give the overall system view. An architecture can use many different patterns in different components

• Patterns are more like small-scale or local architectures for architectural components or sub-components

• Frameworks are partially completed software systems that may be targeted at a particular type of application. These are tailored by completing the unfinished components.

Summary of Differences• Patterns are more general and abstract than

frameworks. A pattern is a description of a solution, not a solution itself.

• A pattern cannot be directly implemented. An implementation is an example of a pattern.

• Patterns are more primitive than frameworks. A framework can employ several patterns.

Background

• In software engineering• Search for recurring successful designs – emergent

designs from practice (via trial and error)• Supporting higher levels of reuse (i.e., reuse of designs)

is quite challenging

What is a Design Pattern?

• In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design.

• A design pattern is not a finished design that can be transformed directly into code.

• It is a description or template for how to solve a problem that can be used in many different situations.

• Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

---http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

Why Design Patterns?

• Expert designers know not to solve every problem from first principles.

• They reuse solutions.• These patterns make OO designs more flexible,

elegant, and ultimately reusable.

22

Why Design Patterns?• Designing OO software is hard• Designing reusable OO software – harder• Experienced OO designers make good design• New designers tend to fall back on non-OO

techniques used before• Experienced designers know something – what is

it?

Design Patterns 23

More on Design Patterns

• Summerville (in “Software Engineering”, V7) suggests that a Design Patterns

• Are abstract designs• Include algorithms and data types• Have four important elements

• Meaningful Name• Problem Description• Solution Description (algorithms, data types)• Consequences (results and trade-offs)


• Famous book: “Design Patterns: Elements of Reusable Object-Oriented Software”

• Serves as a Catalog of Design Patterns• Similar to the idea of a Pattern Handbook

• Divides patterns into three categories• Creational: Patterns that govern the creation of

objects• Structural: Patterns that govern composition of

large structures• Behavioral: Patterns that assign responsibilities

(algorithms) to objects


• Examples• Creational

• Factory• Singleton

• Structural• Adapter• Bridge

• Behavioral• Memento• Mediator

What Is a Design Pattern?

• A design pattern• Is a common solution to a recurring problem in design• Abstracts a recurring design structure• Comprises class and/or object

• Dependencies• Structures• Interactions• Conventions

• Names & specifies the design structure explicitly• Distils design experience

Goals of Design Patterns• Design patterns can speed up the development

process by providing tested, proven development paradigms.

• Effective software design requires considering issues that may not become visible until later in the implementation.

• Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

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”

Design Patterns VS. Architecture Patterns

• Design patterns reside in the domain of modules and interconnections.

• At a higher level there are Architectural patterns that are larger in scope, usually describing an overall pattern followed by an entire system.

software architecture patterns (2)

• The fundamental problem to be solved with a large system is how to break it into chunks manageable for human programmers to understand, implement, and maintain.

• Large-scale patterns for this purpose are called architectural patterns.

• Design patterns are similar, but lower level and smaller scale than architectural patterns.


• Design Patterns represent a lower level of system structure than “software architecture” (cf: seven levels of A)

• Patterns can be applied to architecture:• Architectural patterns tend to be focussed on

middleware. They are good at capturing:• Concurrency• Distribution• Synchronization

Why design patterns?• If you’re a software engineer, you should know

about them anyway.• There are many architectural patterns

published, and the 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

What Makes it a Pattern?

• A Pattern must:• Solve a problem and be useful• Have a context and can describe where the solution can

be used• Recur in relevant situations• Provide sufficient understanding to tailor the solution• Have a name and be referenced consistently

Goals of Design Patterns• Design patterns can speed up the development

process by providing tested, proven development paradigms.

• Effective software design requires considering issues that may not become visible until later in the implementation.

• Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

OO Design is hard

• The design should be specific to the problem at hand, but also general enough to address future problems and requirements.

• Therein lies valuable design knowledge, the problem is• Capturing,• Communicating,• applying this knowledge

Expert designers use patterns• When they find a good solution, they use it

again and again.• The design patterns solve specific design

problems and make OO designs more flexible, elegant, and ultimately reusable.

• A designer who is familiar with patterns can apply them immediately to design problems.

A design pattern can …

• Make it easier to reuse successful designs and architectures.

• Help you choose good design: make system reusable.• Improve the documentation and maintenance.

Why Study Design Patterns?• Can reuse solutions.

• Gives us a head start• Avoids the unanticipated things later• No need to reinvent the wheel

• Establish common terminology• Design patterns provide a common point of reference• Easier to say, “We need some Strategies here.”

• Provide a higher level prospective.• Frees us from dealing with the details too early.

“Gang of Four” (GoF) Book

Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Publishing Company, 1995

This book solidified thinking about patterns and became the seminal Design Patterns text

“Gang of Four” (GoF)

• Dr. Erich Gamma, then Software Engineer, Taligent, Inc.; now at Object Technology International as the technical director of the Zurich lab in Switzerland.

• Dr. Richard Helm, then Senior Technology Consultant, DMR Group; now at the Boston Consulting Group.

• Dr. Ralph Johnson, then and now at University of Illinois, Computer Science Department; now a Research Associate Professor.

• Dr. John Vlissides, then a researcher at IBM Thomas J. Watson Research Center.

Patterns• This book defined 23 patterns, classified into three

categories.• Creational patterns, which deal with the process of object

creation.• Structural patterns, which deal primarily with the static

composition and structure of classes and objects.• Behavioral patterns, which deal primarily with dynamic

interaction among classes and objects.• Many other patterns have been introduced by

others.• For example, the book Data Access Patterns by Clifton

Nock introduces 4 decoupling patterns, 5 resource patterns, 5 I/O patterns, 7 cache patterns, and 4 concurrency patterns.

• Hundreds of patterns have been documented since; other examples include telecommunications patterns, pedagogical patterns, analysis patterns, and indexing patterns.

What’s in this book

• Designs that have been applied more than once in different systems.

• Although the patterns are not new, they are arranged in a new and accessible way.

• Three categories:• Creational Patterns• Structural Patterns• Behavioral Patterns

Types of Patterns

• 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

Classification of GoF Design Pattern

Creational Structural BehavioralFactory MethodAbstract FactoryBuilderPrototypeSingleton

AdapterBridgeCompositeDecoratorFlyweightFacadeProxy

InterpreterTemplate MethodChain of ResponsibilityCommandIteratorMediatorMementoObserverStateStrategyVisitor

Patterns vs Frameworks

• Design patterns are more abstract than frameworks.• Design patterns are smaller architectural elements.• Design patterns are less specialized than framework.

How to select a design pattern

• Approaches to finding the design patterns:• Consider how design patterns solve design problems.• Scan intent sections.• Study how patterns interrelate.• Study patterns of like purpose.• Examine a cause of redesign.• Consider what should be variable in your design

Where They are Used

• Object-Oriented programming languages [and paradigm] are more amenable to implementing design patterns

• Procedural languages: need to define• Inheritance• Polymorphism• Encapsulation

When to Use Patterns

• Solutions to problems that recur with variations• No need for reuse if problem only arises in one context

• Solutions that require several steps:• Not all problems need all steps• Patterns can be overkill if solution is a simple linear set

of instructions

• Solutions where the solver is more interested in the existence of the solution than its complete derivation

• Patterns leave out too much to be useful to someone who really wants to understand

• They can be a temporary bridge

How to use a design pattern

• A step-by-step approach:• Read the pattern once through for an overview.• Go back and study the Structure, Participants, and

Collaborations sections.• Look at the sample Code section to see a concrete example of

the pattern in Code.• Choose names for pattern participants that are meaningful in

the application context.

How to use a design pattern(2)

• Define the classes.• Define application-specific names for operations in the

pattern.• Implement the operations to carry out the

responsibilities and collaborations in the pattern.

Benefits of Design Patterns• Design patterns enable large-scale reuse of

software architectures and also help document systems

• Patterns explicitly capture expert knowledge and design tradeoffs and make it more widely available

• Patterns help improve developer communication• Pattern names form a common vocabulary• Patterns help ease the transition to OO

technology

Benefits of Design Patterns

• Enhance understanding, restructuring, & team communication

• Basis for automation• Transcends language-centric biases/myopia• Abstracts away from many unimportant details

53

Drawbacks to Design Patterns

• Patterns do not lead to direct code reuse• Patterns are deceptively simple• Teams may suffer from pattern overload• Patterns are validated by experience and

discussion rather than • by automated testing

Design Patterns are NOT

• Designs that can be encoded in classes and reused as is (i.e., linked lists, hash tables)

• Complex domain-specific designs (for an entire application or subsystem)

• They are:• “Descriptions of communicating objects and classes

that are customized to solve a general design problem in a particular context.”

Conclusions

• Design Patterns 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!

What is An Architectural Pattern?• An architectural pattern expresses a fundamental

structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them – Buschman et al, “Pattern-Oriented Software Architecture— A System of Patterns””

• Architectural patterns - Common Architectural Styles• Layers• Model-view-controller (M-V-C)• Pipes and filters• Blackboard

ESE — Software Architecture© Oscar Nierstrasz ESE 10.58

Roadmap• What is Software Architecture?• Coupling and Cohesion• Architectural styles:

• Layered• Client-Server• Blackboard, Dataflow, ...




• UML diagrams for architectures


How Architecture Drives Implementation• Use a 3-tier client-server architecture: all business logic must be in

the middle tier, presentation and dialogue on the client, and data services on the server; that way you can scale the application server processing independently of persistent store.


Sub-systems, Modules and Components• A sub-system is a system in its own right whose operation is independent of the services

provided by other sub-systems.

• A module is a system component that provides services to other components but would not normally be considered as a separate system.

• A component is an independently deliverable unit of software that encapsulates its design and implementation and offers interfaces to the out-side, by which it may be composed with other components to form a larger whole.


CohesionCohesion is a measure of how well the parts of a component “belong together”.• Cohesion is weak if elements are bundled simply because they perform similar or related

functions (e.g., java.lang.Math).• Cohesion is strong if all parts are needed for the functioning of other parts (e.g.

java.lang.String).• Strong cohesion promotes maintainability and adaptability by limiting the scope of changes to small

numbers of components.

There are many definitions and interpretations of cohesion.

Most attempts to formally define it are inadequate!


CouplingCoupling is a measure of the strength of the interconnections between system components.• Coupling is tight between components if they depend heavily on one another, (e.g., there is a lot

of communication between them).• Coupling is loose if there are few dependencies between components.

• Loose coupling promotes maintainability and adaptability since changes in one component are less likely to affect others.


Layered ArchitecturesA layered architecture organises a system into a set of layers each of

which provide a set of services to the layer “above”.• Normally layers are constrained so elements only see

• other elements in the same layer, or• elements of the layer below

• Callbacks may be used to communicate to higher layers• Supports the incremental development of sub-systems in different

layers. • When a layer interface changes, only the adjacent layer is affected


OSI reference modelApplication

Presentation

Session

Transport

Network

Data link

Physical

7

6

5

4

3

2

1

Communica tions medium

Network

Data link

Physical

Application

Presentation

Session

Transport

Network

Data link

Physical

© Ian Sommerville 2000


Client-Server ArchitecturesA client-server architecture distributes application logic and services respectively to a number of client and

server sub-systems, each potentially running on a different machine and communicating through the network

Advantages• Distribution of data is straightforward

• Makes effective use of networked systems. May require cheaper hardware

• Easy to add new servers or upgrade existing servers

Disadvantages• No shared data model so sub-systems use different data organisation. Data interchange may be inefficient

• Redundant management in each server

• May require a central registry of names and services — it may be hard to find out what servers and services are available


Four-Tier Architectures

© D'Souza, Wills, 1999


Blackboard ArchitecturesA blackboard architecture distributes application logic to a number of independent sub-systems, but manages

all data in a single, shared repository (or “blackboard”).

Advantages• Efficient way to share large amounts of data

• Sub-systems need not be concerned with how data is produced, backed up etc.

• Sharing model is published as the repository schema

Disadvantages• Sub-systems must agree on a repository data model

• Data evolution is difficult and expensive

• No scope for specific management policies• Difficult to distribute efficiently

ESE — Software Architecture

© Oscar Nierstrasz ESE 10.74

Pipes and Filters

Domain Data source Filter Data sinkUnix tar cf - . gzip -9 rsh picasso ddCGI HTML Form CGI Script generated HTML page


Invoice Processing System

Read issuedinvoices

Identifypayments

Issuereceipts

Findpayments

due

Receipts

Issuepaymentreminder

Reminders

Invoices Payments



Compilers as Dataflow Architectures

Lexicalanalysis

Syntacticanalysis

Semanticanalysis

Codegeneration

Symboltable


© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software 2/26

Architectural Patterns

• ‘Notion’ of an architectural pattern is essential to good architectural design.

•We call these architectural patterns or architectural styles.• • Patterns provide for flexible systems using components

—Components are as independent as possible. (Hunks of executable components…)

• Some architectural patterns are better far better for some applications than for others.

• Let’s look at a few important ones.


1. The Multi-Layer Architectural Pattern • Layered architecture:

—layers communicate down!—Normally immediately below with few ‘skips’—Is the classical approach.

—The higher layer sees the lower layers as a set of services.—This notion is fundamental to good design.

—Often, a layer communicates ONLY with the layer below it not always - but normally.

• .


Multi-Layered Architectural Pattern…

• Built with layers at increasing levels of abstraction.— 1. User Interface layer - normally first for presentation — 2. Application Layer is usually immediately below UI

layer and typically provides the application functions determined by application use-cases. (application layer)

— 3. Domain Layer is usually next and provides general domain-level services (business use-cases)

— 4. Services / Support (Bottom) layers provide general (but essential) services.

» e.g. network communication, database access» operating system services


Extremely Nice Feature of Layered Design

— Layers / layer services are replaceable- NO impacting to other layers and dependencies

• if the interfaces remains unchanged. - Examples:

» User Interface layer when porting to a different platform or for different environments.

» Upgrading / enhancing / optimizing services…- We have clear separation of concerns- We have very good ‘cohesion’ of services…


Example Of Multi-layer Systems (Seen Before…)

Screen display facilities

User account management

File system

Kernel (handling processes and swapping)

Application programs

User interface

Application logic

Database access

Network communication

Transmitting and receiving

Dealing with packets

Dealing with connections

Dealing with application protocols

a) Typical layers in an application program

b) Typical layers in an operating system

c) Simplified view of layers in a communication system

Operating system access

Communications between layers: usually use procedure calls. Upper layers become clients; lower layers become servers.

6

Multi-Tier Layered Architecture - Example Layering Approach

General functionality

Specific functionality

This is a very broad generalization. in practice, things will be considerably different and application dependent in many cases.

Note: this is also a very general view; may/may not include a GUI layer.

© Lethbridge/Laganière 2001


Multi-layered Architecture And Design Principle Satisfy Eleven Architectural Design Principles)

• 1. Divide and conquer: layers can be independently designed.

• 2. Increase cohesion: Well-designed layers have layer cohesion.

• 3. Reduce coupling: Well-designed lower layers do not know about the higher layers and the only connection between layers is through the API.

• 4. Increase abstraction: you do not need to know the details of how the lower layers are implemented.

• 5. Increase reusability: The lower layers can often be designed generically. (e.g. those that handle database access, persistency, etc.) (different databases….)


2. Client-server and other Distributed Architectural Patterns

•At least one component has the role of server: —waiting for and then handling connections.

•At least one component that has the role of client, initiating connections to obtain some service.

•Three-tier model for web-based client-sever applications:—Server ‘in the middle’

- server to client (web-based or not; likely communicating via the Internet)

- client to a database server (usually / often via an intranet)


Other Distributed Client-server Architectural Patterns

• Peer-to-Peer pattern. A system where:—various software components distributed over several hosts.—Hosts: both clients and servers (to each other)—Any two components can set up a communications channel through which communications is accomplished.

• Variation: —Sometimes peers need to be able to find each other; — May need a server containing location information •


5. The Pipe-and-Filter Architectural Pattern • Streams of data, in a relatively simple format, passed through

series of processes• Data constantly fed into a pipeline; Each component transforms the data in some

way.

• The processes work concurrently. Constant data in and coming out.

• Very flexible architecture.—Almost all the components could be removed.—Components may added, changed, deleted, reordered…

• Very flexible particularly (for example) as in converting data or filtering out (removing) characters or ‘features’, etc.

• Sometimes (oftentimes) data might undergo a series of transformations…• Can also split pipelines or join pipelines together.


Example Of A Pipe-and-filter System

encoders formicrophone input

encoder forambientnoise

cancelnoise

equalizedynamicrange

removenon-voicefrequencies

compress transmit

receivedecompressencodespeakeroutput

microphonesnearsoundsource

distantmicrophone

cancelecho

TCP/IP Transmission

One pipe starts here…

Another pipeline starts here…

Pipelines join here

Think in terms of manufacturing processes, process control applicationsor a GPS system.Used more frequently in scientific/engineering systems than in information systems applications.Note: questionable architecture for an information system….

Note the concurrency…


Pipe-and-Filter Architecture: Design Principles

• 1. Divide and conquer: The separate processes can be independently designed. Excellent for manufacturing / process control / etc. systems.

• 2. Increase cohesion: The processes have functional cohesion. (single input; single output; no side effects…)

• 3. Reduce coupling: The processes have only one input and one output.

• 4. Increase abstraction: The pipeline components are often good abstractions, hiding their internal details. And components are usually replacable!

• 5. Increase reusability: The processes can often be used in many different contexts.

• 6. Increase reuse: It is often possible to find reusable components to insert into a pipeline.


6. The Model-View-Controller (MVC) Architectural Pattern

• Architectural pattern to help separate user interface layer from other parts of the system

• Great way to have layered cohesion, as interfaces or controlled. • Coupling reduced between UI layer and rest of system.• Very popular architectural pattern….

THE MVC pattern separates the Model: the functional layer (business entities, ‘key abstractions,’ the objects, relations, ...) from the View: the user interface and the Controller; the director / sequencer of the activities in response to the

user. Why are the business entities called the Model??


MVC Architectural Pattern•The model contains the underlying classes whose instances (objects) are to be viewed and manipulated

—Model will likely contain classes from the business domain that may be general and form the application itself (may be inherited) , which may be unique or specialized to the application.

—These may be very complicated software objects.

•The view contains objects used to render the appearance of the data from the model in the user interface and the controls with which an actor can interact.

•The controller contains the objects that control and handle the user’s interaction with the view and the model.

—Controller contains business logic…and response to events.

• (The Observable design pattern is normally used to separate the model from the view (later) )

Layer - N-Tier (n-tier)HTML, Script Languages, ...

JSP, Servlets, CGI, ...

EJB, CORBA, COM+

Native languages

Client/Browser

Web Server

Application Server

LegendSystem

DatabaseServer

Architectural Pattern - MVC• Name: MVC (Model-View-Controller)• Context and forces: we have a data model and several representations of the data – We want to modularize the system – Data representation must be kept up to date• Problem: how to modularize the system• Solution: the model holds the data (and does data modification), the view represents the data, the controller handles user input

Sapana Mehta (CS-6V81)

Details of MVC Design Pattern

• Name (essence of the pattern)• Model View Controller MVC

• Context (where does this problem occur)• MVC is an architectural pattern that is used when developing

interactive application such as a shopping cart on the Internet.

• Problem (definition of the reoccurring difficulty)• User interfaces change often, especially on the internet

where look-and-feel is a competitive issue. Also, the same information is presented in different ways. The core business logic and data is stable.


MVC continued• Solution (how do you solve the problem)

• Use the software engineering principle of “separation of concerns” to divide the application into three areas:

• Model encapsulates the core data and functionality• View encapsulates the presentation of the data there can be many

views of the common data• Controller accepts input from the user and makes request from the

model for the data to produce a new view.


MVC Structure for J2EE


MVC Architecture• The Model represents the structure of the data in the application, as well as application-specific

operations on those data.

• A View (of which there may be many) presents data in some form to a user, in the context of some application function.

• A Controller translates user actions (mouse motions, keystrokes, words spoken, etc.) and user input into application function calls on the model, and selects the appropriate View based on user preferences and Model state.

Examples of Architectural Patterns - Blackboard1) Pattern Name Blackboard2) ContextA domain in which no closed (algorithmic) approach to solving a problem is known or feasible. Examples are AI systems, voice recognition, and surveillance systems.3) Problem(ROBOT)Multiple problem-solving agents (knowledge agents) must cooperate to solve a problem that cannot be solved by any of the individual agents. The results of the work of the individual agents must be accessible to all the other agents so they can evaluate whether they can contribute to finding a solution and post results of their work.

Examples of Architectural Patterns - Blackboard

4) ForcesSequence in which knowledge agents can contribute to solving the problem is not deterministic and may depend on problem solving strategies. Input from different agents (results or partial solutions) may have different representations. Agents do not know of each other's existence directly but can evaluate each other's posted contributions

5) SolutionA number of Knowledge Agents have access to a shared data store called the Blackboard. The blackboard provides an interface to inspect and update its content. The Control module/object activates the agents following some strategy. Upon activation an agent inspects that blackboard to see if it can contribute to solving the problem. If the agent determines that it can contribute, the control object can allow the agents to put its partial (or final) solution on the board.

Pattern Categories• Creational Patterns concern the process of object creation.

• Structural Patterns concern with integration and composition of classes and objects.

• Behavioral Patterns concern with class or object communication.

Why use Patterns?• A pattern addresses a recurring design problem that

arises in specific design situations, and presents a solution to it.

• Patterns document existing, well-proven design experience.

• Patterns identify and specify abstractions that are above the level of single classes and instances, or of components.

• Patterns provide a common vocabulary and understanding for design principles

• Patterns are a means of documenting software architectures.

Why use Patterns?• Patterns support the construction of software

with defined properties.• Patterns help you build complex and

heterogeneous software architectures.• Patterns help you to manage software

complexity.

Background-Origins of Design Patterns

• “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.”

---Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, Shlomo Angel, “A Pattern Language: Towns/Buildings/ Construction”, Oxford University Press, New York, 1977

• …

Background• In 1987, Kent Beck and Ward Cunningham began

experimenting with the idea of applying patterns to programming and presented their results at the OOPSLA conference that year.

----Beck, Kent; Ward Cunningham (September 1987). "Using Pattern Languages for Object-Oriented Program". OOPSLA '87 workshop on Specification and Design for Object-Oriented Programming. OOPSLA '87. http://c2.com/doc/oopsla87.html

http://en.wikipedia.org/wiki/OOPSLA

Background• In software engineering

• Search for recurring successful designs – emergent designs from practice (via trial and error)

• Supporting higher levels of reuse (i.e., reuse of designs) is quite challenging

What is a Design Pattern?• In software engineering, a design pattern is a general reusable solution to a

commonly occurring problem in software design.• A design pattern is not a finished design that can be transformed directly into

code. • It is a description or template for how to solve a problem that can be used in

many different situations. • Object-oriented design patterns typically show relationships and interactions

between classes or objects, without specifying the final application classes or objects that are involved.

---http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

What Is a Design Pattern?• A design pattern

• Is a common solution to a recurring problem in design• Abstracts a recurring design structure• Comprises class and/or object

• Dependencies• Structures• Interactions• Conventions

• Names & specifies the design structure explicitly• Distils design experience

Re-use Code VS. Design• Code re-use

• Don’t reinvent the wheel• Requires clean, elegant, understandable, general, stable code• leverage previous work

• Design re-use• Don’t reinvent the wheel• Requires a precise understanding of common, recurring designs• leverage previous work

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”


• Design patterns reside in the domain of modules and interconnections.

• At a higher level there are Architectural patterns that are larger in scope, usually describing an overall pattern followed by an entire system.


• Design Patterns represent a lower level of system structure than “software architecture” (cf: seven levels of A)

• Patterns can be applied to architecture:• Architectural patterns tend to be focussed on middleware.

They are good at capturing:• Concurrency• Distribution• Synchronization

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 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*

Global architectureEnterprise architectureSystem architecture

Application architecture

Macro-architecture

Micro-architecture

Objects

ORBOO architecture

Frameworks

Subsystem

Design patterns

OO programming

What Makes it a Pattern?• A Pattern must:

• Solve a problem and be useful• Have a context and can describe where the solution can be

used• Recur in relevant situations• Provide sufficient understanding to tailor the solution• Have a name and be referenced consistently

Description of a Design Pattern

• Description of communicating objects and classes that are customized to solve a general design problem in a particular context.

• Language- & implementation-independent• A “micro-architecture”• Adjunct to existing methodologies (RUP, Fusion, SCRUM, etc.)

Description of a Design Pattern• Describe a recurring design structure

• Defines a common vocabulary • Abstracts from concrete designs• Identifies classes, collaborations, and responsibilities• Describes applicability, trade-offs, and consequences

• Formats of pattern writers vary, but a pattern description usually has at least these four things.

• pattern name• problem• solution• Consequences

Pattern Name• A handle used to describe:

• a design problem• its solutions• its consequences

• Increases design vocabulary• Makes it possible to design at a higher level of

abstraction• Enhances communication• “The Hardest part of programming is coming up with

good variable [function, and type] names.”

Problem• Describes when to apply the pattern• Explains the problem and its context• May describe specific design problems and/or object

structures• May contain a list of preconditions that must be met

before it makes sense to apply the pattern

Solution• Describes the elements that make up the

• design• relationships• responsibilities• collaborations

• Does not describe specific concrete implementation• Abstract description of design problems and how the

pattern solves it

Goals of Design Patterns• Design patterns can speed up the development process

by providing tested, proven development paradigms. • Effective software design requires considering issues that

may not become visible until later in the implementation. • Reusing design patterns helps to prevent subtle issues

that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

Design Patterns 122

Why Design Patterns?• Designing OO software is hard• Designing reusable OO software – harder• Experienced OO designers make good design• New designers tend to fall back on non-OO techniques

used before• Experienced designers know something – what is it?

123

Why Design Patterns?• Expert designers know not to solve every problem from first

principles.• They reuse solutions.• These patterns make OO designs more flexible, elegant, and

ultimately reusable.

OO Design is hard• The design should be specific to the problem at hand, but also general

enough to address future problems and requirements.• Therein lies valuable design knowledge, the problem is

• Capturing,• Communicating,• applying this knowledge

Expert designers use patterns• When they find a good solution, they use it again

and again.• The design patterns solve specific design problems

and make OO designs more flexible, elegant, and ultimately reusable.

• A designer who is familiar with patterns can apply them immediately to design problems.

A design pattern can …• Make it easier to reuse successful designs and architectures.• Help you choose good design: make system reusable.• Improve the documentation and maintenance.

Why Study Design Patterns?• Can reuse solutions.

• Gives us a head start• Avoids the unanticipated things later• No need to reinvent the wheel

• Establish common terminology• Design patterns provide a common point of reference• Easier to say, “We need some Strategies here.”

• Provide a higher level prospective.• Frees us from dealing with the details too early.

“Gang of Four” (GoF) BookDesign Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Publishing Company, 1995

This book solidified thinking about patterns and became the seminal Design Patterns text

“Gang of Four” (GoF) • Dr. Erich Gamma, then Software Engineer, Taligent, Inc.; now at Object

Technology International as the technical director of the Zurich lab in Switzerland. • Dr. Richard Helm, then Senior Technology Consultant, DMR Group; now at the

Boston Consulting Group.• Dr. Ralph Johnson, then and now at University of Illinois, Computer Science

Department; now a Research Associate Professor.• Dr. John Vlissides, then a researcher at IBM Thomas J. Watson Research Center.

Patterns• This book defined 23 patterns, classified into three categories.

• Creational patterns, which deal with the process of object creation.• Structural patterns, which deal primarily with the static composition and

structure of classes and objects.• Behavioral patterns, which deal primarily with dynamic interaction

among classes and objects.

• Many other patterns have been introduced by others.• For example, the book Data Access Patterns by Clifton Nock introduces 4

decoupling patterns, 5 resource patterns, 5 I/O patterns, 7 cache patterns, and 4 concurrency patterns.

• Hundreds of patterns have been documented since; other examples include telecommunications patterns, pedagogical patterns, analysis patterns, and indexing patterns.

What’s in this book• Designs that have been applied more than once in different systems.• Although the patterns are not new, they are arranged in a new and

accessible way.• Three categories:

• Creational Patterns• Structural Patterns• Behavioral Patterns

Types of Patterns• 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

How Design Patterns Solve Design Problems.

• The problems• Finding Appropriate Objects• Determining Object Granularity• Specifying Object Interfaces• Specifying Object Implementations• Putting Reuse Mechanisms to Work• Relating Run-Time and Compile-Time Structures.• Designing for Change

System Architecture

• The architecture of a computer system is the high-level (most general) design on which the system is based

• Architectural features include:• Components• Collaborations (how components interact)• Connectors (how components communicate)

System Architecture

• Common architectural patterns include• Client-Server• Layered• Peer-to-peer• Pipes and Filters• etc.

Client-Server Architecture

• Each component of a client-server system has the role of either client or server

• Client: a component that makes requestsclients are active initiators of transactions

• Server: a component that satisfies requestsservers are passive and react to client requests

Tiered Web Architectures

• Web applications are usually implemented with 2-tier, 3-tier, or multitier (N-tier) architectures

• Each tier is a platform (client or server) with a unique responsibility

2-Tier C-S Architecture• Tier 1: Client platform, hosting a web browser• Tier 2: server platform, hosting all server software components

2-Tier Characteristics• Advantage:

• Inexpensive (single platform)

• Disadvantages• Interdependency (coupling) of components• No redundancy• Limited scalability

• Typical application• 10-100 users• Small company or organization, e.g., law office, medical practice, local non-profit

3-Tier C-S Architecture• Tier 3 takes over part of the server function from tier 2, typically data

management

3-Tier Characteristics• Advantages

• Improved performance, from specialized hardware • Decreased coupling of software components• Improved scalability

• Disadvantages• No redundancy

• Typical Application• 100-1000 users• Small business or regional organization, e.g., specialty retailer, small college

Multitier C-S Architecture• A multitier (N-tier) architecture is an expansion of the 3-tier

architecture, in one of several different possible ways• Replication of the function of a tier• Specialization of function within a tier• Portal services, focusing on handling incoming web traffic

Replication• Application and data servers are replicated• Servers share the total workload

Specialization• Servers are specialized• Each server handles a designated part of the workload, by function

Multi-Tier Characteristics• Advantages

• Decoupling of software components• Flexibility to add/remove platforms in response to load• Scalability• Redundancy

• Disadvantages• Higher costs (maintenance, design, electrical load, cooling)

• Typical Application• 1000+ users• Large business or organization

Characteristics Summary

2-Tier

3-Tier

N-Tier

10

100

1000users

•large e-commerce, business, or organization

•small e-commerce, regional business or organization

•local business or organization

capacityscalabilityredundancycost

CSE 156 148

3-Tier Architectures(or 3-Tier Applications)

CSE 156 149

Simple Programs• The programs you have written so far have

probably had the following properties:• Input/output was text-based, GUI, and/or with files• Ran locally—that is, they had to be downloaded to the

machine on which you (or your T.A.) ran them• The data had to be on the same machine as your

program• Were not able to be run simultaneously by more than

one person.• Had no interaction with other programs

• In the real world, most software is much more complicated than this

CSE 156 150

Databases and the Web• Many real applications are different than what you have

programmed in two important ways• They make extensive use of databases to store data • They are accessible from anywhere by multiple people

simultaneously via the World Wide Web

• Sites like amazon.com and ebay.com are entirely database driven—that is, each time you go to the site, what you see is determined by data in their database

• As we will see, applications that use databases and are web accessible can be implemented using a 3-tier architectural model

CSE 156 151

3-Tier Architectures• Definition: A 3-tier architecture is one which has a

client tier, a middle tier, and a database tier.• The database tier manages the database• The middle tier contains most of the logic and

communicates between the other tiers • The client tier is the interface between the user and the

system

• Definition: An n-tier architecture is one which has n tiers, usually including a database tier, a client tier, and n-2 tiers in between.

CSE 156 152

Thin-Client 3-Tier Models• The thin-client 3-tier model has these tiers:

• The database management system (DBMS)• The main application software• A web browser

• Examples• http://cse.unl.edu/~sscott/teach• http://contests.unl.edu• http://ebay.com*

• http://amazon.com*

• Lotus Notes Web Client*

(*These may actually be n-tier)

http://cse.unl.edu/~sscott/teach

http://cscontests.unl.edu/

http://ebay.com/

http://amazon.com/

CSE 156 153

Thick-Client 3-Tier Models• The thick-client 3-tier model has these tiers:

• The database management system (DBMS)• The main application software• Some sort of interface software which must be installed

on each client machine

• Examples:• Lotus Notes• Desktop applets that display weather, etc.• RealPlayer and other applications that download CD

information from the Web

CSE 156 154

Another 3-Tier Model• Another common model has these tiers:

• The database management system (DBMS) and a persistence manager which controls all data flow into and out of the database

• The main application software• A GUI (thin or thick)

• The main difference here is that the main application software is not allowed to interact directly with the database

• You could also think of this as a 4-tier architecture:• The database management system (DBMS) • A persistence manager • The main application software• A GUI (thin or thick)

CSE 156 155

2- and n-Tier Models• The 2-tier model is more simple, but more limited, than a

3-tier model, and often includes• The database management system (DBMS) • The main application software, including GUI

• Here, the entire application is generally run on the client machine (certainly a thick-client)

• In some contexts, the 2-tier model is also know as the client-server model, where the server can be something other than a database

• In general an n-tier model will have • The database management system (DBMS) • (n-2) application layers• A GUI (thin or thick)

CSE 156 156

n-Tier Questions• The following are important questions one must

ask when thinking about n-tier architectures• How many tiers should be used?• What tasks should be done by each tier? In other

words, how exactly should the layers be divided?• Should I use thin or thick clients?• Should the application be web-accessible?• How should connections to the database be managed?• What database management system (DBMS) should be

used?• What languages(s), platform(s), and software should

the system use?

CSE 156 157

n-Tier Answers• The purpose of these notes is not to

• Present clear answers to all of the questions on the previous slide

• Be the authoritative source for information about n-tier architectures

• Make you an expert in n-tier architectures

• Rather, the purpose is to• Introduce you to the concept of n-tier architectures• Get you to start thinking about the issues involved• Give you partial answers to some of the question

CSE 156 158

Database Choices• There are many popular database management

systems (DBMSs), including• IBM DB2• Oracle• Microsoft SQL Server• Microsoft Access• MySQL

• Which one you should use depends on many factors, including number of expected users, size of the application and/or the database, budget, etc.

• Fortunately, the interfaces to these DBMSs have a lot in common, so if you learn to use one, most of what you learn is transferable to the others

CSE 156 159

Middle Tier Choices• Almost anything is possible, with some common choices

being – Java – JSP– PHP– C++– Perl

– Visual Basic – C#– .NET– ASP

• However, whether or not the client will be thin or thick will influence this choice

• For a thin client, the obvious middle tier choices are – Java applets, JSP, PHP, ASP, and Perl– Of course with all of these, HTML is involved as well

CSE 156 160

Client Choices• Thin clients are generally web browsers, so the important

choice was made in the middle tier• For thick clients, we might use

• Java applications • C++ applications with GUI provided by

• MFC (Microsoft Foundation Classes) • Tcl/Tk (Tool command language) • GTK (Gimp ToolKit) • Qt

CSE 156 161

Examples• You could build a 3-tier application which has

• Oracle DBMS, C++ middle, and C++/MFC client

• MySQL DBMS, PHP middle, and web browser client (http://cse.unl.edu/~sscott/teach uses these choices)

• IBM DB2 DBMS, JSP middle, and Java applet client

• MySQL DBMS, Java Applet middle, and web browser client

• MySQL DBMS, JSP middle, and web browser client (http://contests.unl.edu uses these choices)

• Microsoft SQL Server DBMS with ASP access control, ASP middle, and web browser client

http://cse.unl.edu/~sscott/teach

final patterns in ooad 312 5 may 16 updated 7 may

Documents