1. UNIVERSITY OF JYVÄSKYLÄ − ITRI Jouni Markkula − MODPA Design Patterns Supporting Mobile Application Development WIM Workshop Uppsala 17.9.2004 Jouni Markkula markkula@jyu.fi

2. 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).

3. UNIVERSITY OF JYVÄSKYLÄ − ITRI Jouni Markkula − MODPA Mobile Internet Technical Architecture (Nokia MITA)  Mobile application design is based on complex technical architecture Intranet (WLAN)/Bluetooth Web domain Internet xDSL PSTN Mobile networks GSM EDGE WCDMA Mobile domain WLAN /Bluetooth Bluetooth =Server

4. 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

5. 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.”

6. 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.

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

8. 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

9. 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 Object- Oriented 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

10. 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.

11. UNIVERSITY OF JYVÄSKYLÄ − ITRI Jouni Markkula − MODPA GoF Design Pattern Format  Pattern Name and Classification –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.  Intent –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 –Other well-known names for the pattern, if any.  Motivation –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 –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 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 –The classes and/or objects participating in the design pattern and their responsibilities.  Collaborations –How the participants collaborate to carry out their responsibilities.  Consequences –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 –What pitfalls, hints or techniques should you be aware of when implementing the pattern? Are there language-specific issues?  Sample Code –Code fragments that illustrate how you might implement the pattern in e.g. C++ or Smalltalk.  Known Uses –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?

12. UNIVERSITY OF JYVÄSKYLÄ − ITRI Jouni Markkula − MODPA GoF Catalog and Organization of Design Patterns Purpose CreationalStructuralBehavioral ScopeClass Factory MethodAdapter (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

13. UNIVERSITY OF JYVÄSKYLÄ − ITRI 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.

14. 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.

15. 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.)

16. UNIVERSITY OF JYVÄSKYLÄ − ITRI Jouni Markkula − MODPA Why Patterns?  Common vocabulary –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.  Documentation and learning aid –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 –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 –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.

17. 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)

18. 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. Addison- Wesley, 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. 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.  Fowler, Martin (2003). Patterns of Enterprise Application Architecture. Addison- Wesley, Boston.  Hillside.net Patterns Library. http://hillside.net/patterns/  Martin Fowler. http://www.martinfowler.com/