Transcript Dia 1 - Information management

Jouni Markkula
[email protected]
Design Patterns
Supporting Mobile Application Development
WIM Workshop
Uppsala
17.9.2004
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
Architecture and Design Patterns

Design Patterns are developed in the context of architectures
– Building architecture
– Software architecture
– Enterprise application architecture

Architecture: Design, the way components fit together. It may also
be used of any complex system, e.g. "software architecture",
"network architecture". (computing dictionary)

Architecture is a term that lots of people try to define, with little agreement.
There are two common elements: One is the highest-level breakdown of a
system into it’s parts; the other, decisions that are hard to change. There
isn’t just one way to state a system’s architecture; rather, there are multiple
architectures in a system, and the view of what is architecturally significant
is one that can change over a system’s lifetime. Architecture is a subjective
subjective thing, a shared understanding of a system’s design by the expert
developers on a project. Commonly this shared understanding is in the form of
the major components of the system and how they interact. It is also about
decisions, in that it’s the decision that developers wish they could get right
early on because they’re perceived as hard to change. The subjectivity comes
in here as well because, if you find that something is easier to change than you
once thought, then it’s no longer architectural. In the end architectural boils
down to the important stuff – whatever that is. (Fowler).
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
Mobile Internet Technical Architecture
(Nokia MITA)
Web domain
Mobile domain
(WLAN)/Bluetooth
Mobile
networks
xDSL
PSTN
Internet
EDGE
Bluetooth
GSM
Intranet
=Server
WCDMA
WLAN /Bluetooth

Mobile application design is based on complex technical
architecture
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
Problems of Mobile Application
Development

Complex architecture
– Difficult to learn and understand
– Many affecting factors: components, their qualities and combinations

Heterogenous and fast developing technologies
– Wireless networks
– Terminals
– Etc.

Relatively young application field
– Not much experience

Fast development expected
– Time to market critical

Application development often project-based and not well planned
– Fast and ad hoc solutions
– Organisational memory and infomation exchange problems

Value chain (or network)
– Diferent compaines involved (e.g. service provider(s), content provider(s),
network operator(s), technology provider(s))
– Interoperability
– Subcontracting
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
Origins of Patterns –
Building Architecture

Christopher Alexander, Professor of Architecture at the University of California,
Berkeley, director of the Center for Environmental Structure

Alexander, with his colleagues, published a series of books:
– Volume 1. The Timeless Way of Building (1979)
– Volume 2. A Pattern Language (1977)
– Volume 3. The Oregon Experiment. (1978)

This series of books “describe an entirely new attitude to architecture and
planning. The books are intended to provide a complete working alternative to
our present ideas about architecture, building, and planning – an alternative
which will, we hope, gradually replace current ideas and practices.
–
–
–
“Volume 1, The timeless Way of Building, lays the foundation of the series. It presents a new theory
of architecture, building, and planning which forms the basis for a new traditional post-industrial
architecture, created by the people . .”
“Volume 2, A Pattern Language, is a working document for such an architecture. It is an archetypal
language which allows lay persons to design for themselves.”
“Volume 3, The Oregon Experiment, shows how this theory may be implemented, describing a new
planning process for the University of Oregon.”
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
Alexander’s Definition of 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.
Each pattern is a three-part rule, which expresses a relation
between a certain context, a problem, and a solution.
As an element in the world, each pattern is a relationship
between a certain context, a certain system of forces which
occurs repeatedly in that context, and a certain spatial
configuration which allows these forces to resolve themselves.
As an element of language, a pattern is an instruction, which
shows how this spatial configuration can be used, over and
over again, to resolve the given system of forces, wherever the
context makes it relevant.
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
Alexander’s Pattern Language

Pattern language is extremely practical... It is a language that we have
distilled from our own building and planning efforts over years.. The
elements of this language are entities called patterns…

Patters have a same format:
–
–
–
–
–
Title, a descriptive name
Picture, showing archetypal example of the pattern
Introductory paragraph, which sets the context for the pattern
Headline giving the essence of the problem in one or two sentences
Body of the pattern: empirical background, evidence for it’s validity,
different ways it can be manifested in a building, etc.
– Solution describing field of physical and social relationships required to
solve the stated problem, in the stated context; solution is given in a form
of an instruction
– Diagram showing the solution, with labels to indicate its main components
– Related patterns paragraph which ties the pattern to all smaller patterns in
the language needed to complement this pattern
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
Alexander’s Pattern Language

Two essential purposes behind the specific format:
– First, to present each pattern connected to other patterns, so that you
grasp the collection of all 253 patterns as a whole, as a language, within
which you can create an infinite variety of combinations
– Second, to present the problem and solution of each pattern in such a way
that you can judge it for yourself, and modify it, without loosing the
essence that is central to it


The patterns are ordered, beginning with the very largest, for regions
and towns, then working down through neighbours, clusters of
buildings, buildings, rooms and alcoves, ending finally with details
of construction
We hope that many people try to improve these patterns… Patterns
are very much alive and evolving… Each pattern may be looked
upon as a hypothesis like one of the hypotheses of science… All free
to evolve under the impact of new experience and observations
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
GoF – Object Oriented Software
Design Patterns

Gamma, Erich; Helm, Richard; Johnson, Ralph & Vlissides,
John (1995). Design Patterns, Elements of Reusable ObjectOriented Software. Addison-Wesley, Boston.

Referred commonly as Gang of Four or GoF
Used the concept Design Pattern
Object-Oriented view



Definition
– The design patterns are descriptions of communicating
objects and classes that are customized to solve a
general design problem in a particular context
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
GoF

In general, a pattern has four essential elements:
– The pattern name which in a word or two provides a
handle and vocabulary for discussing and using the pattern.
– The problem which explains the problem and the context in
which the pattern is applicable. Sometimes a list of
conditions that must be met before it makes sense to apply
the pattern is included.
– The solution which describes the elements of the pattern,
their relationships, responsibilities, and collaborations. The
solution is abstract, like a template. Though sometimes a
concrete example in a certain programming language may
be included.
– The consequences which are the results and trade-offs of
applying the pattern. These are critical for evaluating
alternatives and understanding the costs and benefits of
applying the pattern.
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
GoF Design Pattern Format

Pattern Name and Classification
–

Intent
–

Code fragments that illustrate how you might implement the pattern in e.g. C++ or Smalltalk.
Known Uses
–

What pitfalls, hints or techniques should you be aware of when implementing the pattern? Are there language-specific
issues?
Sample Code
–

How does the pattern support its objectives? What are the trade-offs and results of using the pattern? What aspect of
system structure does it let you vary independently?
Implementation
–

How the participants collaborate to carry out their responsibilities.
Consequences
–

The classes and/or objects participating in the design pattern and their responsibilities.
Collaborations
–

A graphical representation of the classes in the pattern using a notation based on the Object Modeling Technique.
Additionally interaction diagrams are used to illustrate sequences of requests and collaborations between objects.
Participants
–

What are the situations in which the design pattern can be applied? What are examples of poor designs that the pattern
can address? How can you recognize these situations?
Structure
–

A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem.
The scenario will help you understand the more abstract description of the pattern that follows.
Applicability
–

Other well-known names for the pattern, if any.
Motivation
–

A short statement that answers the following questions: What does the design pattern do? What is its rationale and
intent? What particular design issue or problem does it address?
Also Known As
–

The pattern’s name conveys the essence of the pattern succinctly. A good name is vital, because it will become part of
your design vocabulary.
Examples of the pattern found in real systems. Gamma et al. include at least two examples from real domains.
Related patterns
–
What design patterns are closely related to this one? What are the important differences? With which other patterns
should this one be used?
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
GoF Catalog and Organization of
Design Patterns
Purpose
Creational
Scope
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Structural
Behavioral
Class
Factory Method
Adapter (class)
Interpreter
Template Method
Object
Abstract Factory
Builder
Prototype
Singleton
Adapter (Object)
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
Jouni Markkula − MODPA
Pattern Oriented Software Architecture
Patterns for Software Architecture, Distributed Systems and Resource
Management



Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal.
Pattern-oriented Software Architecture: System of Patterns Vol 1. John Wiley and Sons
Ltd. 1996.
Frank Buschmann, Douglas Schmidt, Michael Stal, Hans Rohnert. Pattern-oriented
Software Architecture Vol 2: Patterns for Concurrent and Networked Objects. John Wiley
and Sons Ltd. 2000.
Michael Kircher, Prashant Jain. Pattern-Oriented Software Architecture: Patterns for
Distributed Services and Components. John Wiley and Sons Ltd. 2004.
Three types of patterns (Buschmann et al.):



Architectural Patterns
– An architectural pattern expresses a fundamental structural organization for software
systems or 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.
Design Patterns
– A design pattern provides a scheme for refining the subsystems or components of a
software system, or the relationships between them. It describes commonly recurring
structure of communicating components that solve a design problem within a
particular context.
Idioms
– An idiom is a low-level pattern specific to a programming language. An idiom
describes how to implement particular aspects of components or the relationships
between them using the features of the given language.
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
Patterns of Enterprise Application
Architecture

Fowler, Martin (2003). Patterns of Enterprise Application Architecture.
Addison-Wesley, Boston.
– Enterprise applications are about the display, manipulation, and storage of
large amounts of often complex data and the support or automation of
business processes with the data. Enterprise applications have their own
particular challenges and solutions, and they differ from embedded
systems, control systems, telecoms, or desktop productivity software.

In case you haven’t realized, building computer system is hard.
As the complexity of the system gets greater, the task of
building the software gets exponentially harder. As in any
profession, we can progress only by learning, both from our
mistakes and from our successes. Presented patterns
represent some of the learning written in form which learn
these lessons quicker.
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
Why Patterns?






Patterns can be used by programmers, designers, and architects who
are building applications and who want to improve either their
understanding of architectural issues or their communication about
them. (Fowler)
Patterns are common solutions to recurring problems. If you have
worked in applications for a while, you may well know most of them.
They are industry’s old ideas. If you are new, pattern book can help
you learn about those techniques. If you are familiar with the
techniques, pattern book can help you communicate and teach them
to others. An important part of patterns is trying to build a common
vocabulary for communication. (Fowler)
Patterns constitute an effort to build on the collective experience of
skilled designers and software engineers. (Buschmann et al.)
Experts already have solutions to many recurring design
problems. (Buschmann et al.)
Patterns capture proven solutions in an easily-available and,
hopefully, well-written form (Buschmann et al.)
Patterns support both novices and experts in software development.
(Buschmann et al.)
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
Why Patterns?

Common vocabulary
–

Documentation and learning aid
–

Design reuse is different from e.g. code reuse; the former is typically more efficient than the latter
as design is more abstract and is therefore more likely to apply in a number of situations. An
effective design is, however, harder to come by than an effective implementation: a particular
implementation may be fully functional but that alone does not guarantee it’s understandable to
others and reusable (c.f. program code)
An adjunct to existing methods
–

Knowing design patterns helps understand existing systems. As patterns provide solutions to
common problems, they thereby help novices act more expert-like and allow them to produce
effective designs. Furthermore, when designs are presented in terms of patterns, outsiders
(members of other teams or even organizations) that are previously not familiar with a particular
system should be able to get a rapid higher-level understanding and overview of it.
Promotion of design reuse
–

For designers to use to communicate, document and explore design alternatives. Design patterns
reduce system complexity and increase design efficiency by letting people talk about their designs
at a higher level of abstraction than that of a design notation or programming language. Without
this vocabulary they would always have to put effort on finding descriptions for the problem at
hand. The common language will also span team boundaries making it even more universal.
Object-oriented design methods are, in themselves, supposed to promote good design by teaching
newcomers proven design principles, and by standardizing the way designs are done. Design
patterns add to these qualities by providing a means of describing more of the “why” of a design as
opposed to just recording the results of one’s decisions.
A target for refactoring
–
One of the problems of developing reusable software is that it often has to be reorganized or
refactored. Design patterns help determine how to reorganize a design and can reduce the amount
of refactoring later on.
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
How Can Patterns Support Mobile
Application Development?

Means for handling complexity
Analysis and description tool
Can introduce systematics to design process
Means for learning and teaching
Means for communication and information exchange
Etc.

Questions:





– Dependence of design methods on technology and its
development
– Design patterns in the context of Mobile Internet
Architecture
– Design patterns in organisational context (intra- &
interorganisational questions)
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA
References










Alexander Christopher (1979). The Timeless Way of Building. (Volume 1).
Oxford University press, New York.
Alexander, Christopher; Ishikawa, Sara; Silverstein, Murray; with Jakobson,
Max; Fiksdahl-King, Ingrid & Angel, Shlomo (1977). A Pattern Language.
(Volume 2). Oxford University press, New York.
Alexander, Christopher; Silverstein, Murray; Angel, Shlomo; Ishikawa, Sara &
Abrams, Denny (1978). The Oregon Experiment. (Volume 3). Oxford University
press, New York.
Gamma, Erich; Helm, Richard; Johnson, Ralph & Vlissides, John (1995).
Design Patterns, Elements of Reusable Object-Oriented Software. AddisonWesley, Boston.
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael
Stal. Pattern-oriented Software Architecture: System of Patterns Vol 1. John
Wiley and Sons Ltd. 1996.
Frank Buschmann, Douglas Schmidt, Michael Stal, Hans Rohnert. Patternoriented Software Architecture Vol 2: Patterns for Concurrent and Networked
Objects. John Wiley and Sons Ltd. 2000.
Michael Kircher, Prashant Jain. Pattern-Oriented Software Architecture:
Patterns for Distributed Services and Components. John Wiley and Sons Ltd.
2004.
Fowler, Martin (2003). Patterns of Enterprise Application Architecture. AddisonWesley, Boston.
Hillside.net Patterns Library. http://hillside.net/patterns/
Martin Fowler. http://www.martinfowler.com/
UNIVERSITY OF JYVÄSKYLÄ − ITRI
Jouni Markkula − MODPA