WebApp Design Patterns

WebApp Design Patterns

• There are two dimensions in WebApp Design Patterns:
• The design focus of the pattern and its level of granularity.
• Design focus identifies which aspect of the design model is relevant (e.g., information architecture, navigation, interaction).
• Granularity identifies the level of abstraction that is being considered (e.g., does the pattern apply to the entire WebApp, to a single Web page, to a subsystem, or an individual WebApp component?).

• Design Focus 
• WebApp patterns can be categorized using the following levels of design focus
• Information architecture patterns relate to the overall structure of the information space, and the ways in which users will interact with the information. 
• Navigation patterns define navigation link structures, such as hierarchies, rings, tours, and so on. 
• Interaction patterns contribute to the design of the user interface.
• Presentation patterns assist in the presentation of content as it is presented to the user via the interface.
• Functional patterns define the workflows, behaviors, processing, communication, and other algorithmic elements within a WebApp.

• Design Granularity: When a problem involves “big picture” issues, you should attempt to develop solutions (and use relevant patterns) that focus on the big picture. 
• In terms of the level of granularity, patterns can be described at the following levels. 
• Architectural patterns. This level of abstraction will typically relate to patterns that define the overall structure of the WebApp, indicate the relationships among different components. 
• Design patterns. These address a specific element of the design such as an aggregation of components to solve some design problem, relationships among elements on a page, or the mechanisms for effecting component-to-component communication. 
• Component patterns. This level of abstraction relates to individual small-scale elements of a WebApp.

User interface Design Patterns

User interface Design Patterns

• Hundreds of user interface (UI) patterns have been proposed in recent years. 
• Most fall within one of the following 10 categories of patterns : 
• (1) Pattern: TopLevelNavigation 
• Brief Description: Used when a site or application implements a number of major functions. Provides a top-level menu, often coupled with a logo or identifying graphic, that enables direct navigation to any of the system’s major functions. 
• (2) Pattern: CardStack 
• Brief Description: Used when a number of specific subfunctions or content categories related to a feature or function must be selected in random order. [e.g. DropDownList]
• (3) Pattern: Fill-in-the-Blanks 
• Brief description: Allow alphanumeric data to be entered in a “text box.” 
• (4) Pattern: SortableTable
• Brief description: Display a long list of records that can be sorted by electing a toggle mechanism for any column label. 
• (5) Pattern: BreadCrumbs 
• Brief description: Provides a full navigation path when the user is working with a complex hierarchy of pages or display screens. 
• (6) Pattern: EditInPlace
• Brief description: Provide simple text editing capability for certain types of content in the location that it is displayed.
• (7)  Pattern: SimpleSearch 
• Brief description: Provides the ability to search a website or persistent data source for a simple data item described by an alphanumeric string.
• (8) Pattern: Wizard
• Brief description: Takes the user through a complex task one step at a time, providing guidance for the completion of the task through a series of simple window displays.
• (9) Pattern: ShoppingCart 
• Brief description: Provides a list of items selected for purchase. 
• (10) Pattern: ProgressIndicator 
• Brief description: Provides an indication of progress when an operation takes longer than n seconds.

Component Level Design Patterns

Component Level Design Patterns

• Component-level design patterns provide you with proven solutions that address one or more subproblems extracted from the requirements model. 

• In many cases, design patterns of this type focus on some functional element of a system. 

• For example: Searching is a very common problem, it should come as no surprise that there are many search-related patterns like… 

• AdvancedSearch
• HelpWizard
• SearchArea
• SearchTips
• SearchResults
• SearchBox

Architectural Pattern

Architectural Pattern 

• Architectural patterns for software define a specific approach for handling some characteristic of the system.
• Bosch and Booch define a number of architectural pattern domains.
• Access control :
• There are many situations in which access to data, features, and functionality delivered by an application is limited to specifically defined end users.
• Concurrency :
• There are a number of different ways in which an application can handle concurrency, and each can be presented by a different architectural pattern.
• Distribution:  
• The distribution problem addresses the manner in which systems or components within systems communicate with one another in a distributed environment.Twosubproblems are considered:
• (1) the way in which entities connect to one another,
•  For example The most common architectural pattern established to address the distribution problem is the Broker pattern. Abroker acts as a “middleman” between the client component and a server component. 
•  Persistence : 
•  Persistent data are stored in a database or file and may be read or modified by other processes at a later time. 
• two architectural patterns areused to achieve persistence 
• —A DatabaseManagementSystem 
• --- Application LevelPersistence pattern that builds persistence features into the application architecture

Pattern-Based Design | Thinking in Patterns | Design Tasks

Pattern-Based Design

• A software designer begins with a requirements model (either explicit or implied) that presents an abstract representation of the system. 
• The requirements model describes the problem set, establishes the context.

Thinking in Patterns

Shalloway and Trott suggest the following approach that enables a designer to think in patterns: 

• 1. Be sure you understand the big picture—the context in which the software to be built resides. The requirements model should communicate this to you. 
• 2. Examining the big picture, extract the patterns that are present at that level of abstraction.
• 3. Begin your design with ‘big picture’ patterns that establish a context for further design work. 
• 4. “Work inward from the context” looking for patterns at lower levels of abstraction that contribute to the design solution. 
• 5. Repeat steps 1 to 4 until the complete design is fleshed out. 
• 6. Refine the design by adapting each pattern to the specifics of the software you’re trying to build.

Design Tasks

• Examine the requirements model and develop a problem hierarchy. 
• Determine if a reliable pattern language has been developed for the problem domain.
• Beginning with a broad problem, determine whether one or more architectural patterns are available for it.
• Using the collaborations provided for the architectural pattern, examine subsystem or component level problems and search for appropriate patterns to address them.
• Repeat steps 2 through 5 until all broad problems have been addressed. 

Design Patterns | Effective Patterns | Kinds (Types) of Patterns | Frameworks | Difference between design patterns and Frameworks | Describing a Pattern | Pattern Languages

 Design Patterns

• Each of us has encountered a design problem and silently thought: I wonder if anyone has developed a solution to for this?
• What if there was a standard way of describing a problem (so you could look it up), and an organized method for representing the solution to the problem?
• Design patterns are a codified method for describing problems and their solution allows the software engineering community to capture design knowledge in a way that enables it to be reused.
•  Each pattern describes a problem that 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 the solution a million times over without ever doing it the same way twice.
• Christopher Alexander, 1977
• “a three-part rule which expresses a relation between a certain context, a problem, and a solution.”

Effective Patterns

• Coplien characterizes an effective design pattern in the following way:
• It solves a problem: Patterns capture solutions, not just abstract principles or strategies. 
• It is a proven concept: Patterns capture solutions with a track record, not theories. 
• The solution isn't obvious (Clear): Many problem-solving techniques (such as software design paradigms or methods) try to derive solutions from first principles. 
• It describes a relationship: Patterns don't just describe modules but describe deeper system structures and mechanisms. 
• The pattern has a significant human component (minimize human intervention). All software serves human comfort or quality of life.

 Kinds (Types) of Patterns

• Architectural patterns describe broad-based design problems that are solved using a structural approach. 
• Data patterns describe recurring data-oriented problems and the data modeling solutions that can be used to solve them. 
• Component patterns (also referred to as design patterns) address problems associated with the development of subsystems and components, the manner in which they communicate with one another, and their placement within a larger architecture.
• Interface design patterns describe common user interface problems and their solution with a system of forces that includes the specific characteristics of end-users. 
• WebApp patterns address a problem set that is encountered when building WebApps and often incorporates many of the other patterns categories just mentioned.
• As per Gamma and his colleagues, focus on three types that are relevant to object oriented design :
• Creational patterns focus on the “creation, composition, and representation of objects.
• Structural patterns focus on problems and solutions associated with how classes and objects are organized and integrated to build a larger structure.
• Behavioral patterns address problems associated with the assignment of responsibility between objects and the manner in which communication is effected between objects.

Frameworks

• Patterns themselves may not be sufficient to develop a complete design.
• In some cases, it may be necessary to provide an implementation- specific skeletal (Outline sketch) infrastructure, called a framework, for design work.
• A framework is not an architectural pattern, but rather a skeleton with a collection of “plug points” (also called hooks and slots) that enable it to be adapted to a specific problem domain.
• The plug points enable you to integrate problem specific classes or functionality within the skeleton. 
• In object-oriented context, a framework is a collection of cooperating classes.

Difference between design patterns and Frameworks

Gamma and his colleagues describe the differences between design. patterns and frameworks in the following manner: 

• 1. Design patterns are more abstract than frameworks. 
• Frameworks can be in material form in code, but only examples of patterns can be embodied in code. 
• A strength of frameworks is that they can be written down in programming languages and not only studied but executed and reused directly... 
• 2. Design patterns are smaller architectural elements than frameworks.
• A typical framework contains several design patterns but the reverse is never true. 
• 3. Design patterns are less specialized than frameworks. 
• Frameworks always have a particular application domain. In contrast, design patterns can be used in nearly any kind of application.

Describing a Pattern

• Pattern name—describes the essence of the pattern in a short but expressive name
• Problem—describes the problem that the pattern addresses 
• Motivation—provides an example of the problem 
• Context—describes the environment in which the problem resides including application domain 
• Forces—lists the system of forces that affect the manner in which the problem must be solved; includes a discussion of limitation and constraints that must be considered 
• Solution—provides a detailed description of the solution proposed for the problem 
• Intent—describes the pattern and what it does 
• Collaborations—describes how other patterns contribute to the solution 
• Related patterns—cross-references related design patterns

Pattern Languages

• A pattern language encompasses a collection of patterns 
• each described using a standardized template. 
• interrelated to show how these patterns collaborate to solve problems across an application domain. 
• A pattern language is analogous to a hypertext instruction manual for problem-solving in a specific application domain. 
• The problem domain under consideration is first described hierarchically, beginning with broad design problems associated with the domain and then refining each of the broad problems into lower levels of abstraction.