Design Patterns for Adaptable Real-Time Systems



1

2 Design Patterns for Adaptable Real-Time Systems

Lawrence Chung

Department of Computer Science

The University of Texas at Dallas

2601 N. Floyd Rd. (P.O. Box 830688)

Richardson, Texas 75083-0688

email: chung@utdallas.edu

Tel: 972-883-2178

Fax: 972-883-2349



1 Abstract

The ability of a software system to adapt through its own mechanisms, or be adapted by developers, is a critical concern in Software Engineering. To assist designers in creating more adaptable software, the concept of design patterns is being explored in both industrial and research environments. Design patterns are high-level abstractions that reflect the experience of skilled practitioners and describe, according to a given format, the context, problems, solutions, and consequences of making specific design decisions. This paper presents ADAPT - an ongoing project whose goal is to develop methods for developing adaptable software using patterns. In order to achieve this goal, ADAPT adapts the NFR Framework, in which software adaptability, as a non-functional requirement (NFR), is treated as a softgoal to be satisficed (i.e., achieved not absolutely but within acceptable limits). In this paper, a primary emphasis will be in patterns that can support the development of adaptable real-time systems.

1. Introduction

The ability of a software system to adapt through its own mechanisms, or be adapted by developers, is a critical concern in Software Engineering. This is especially true in spirit of Brooks [Brooks87] who states that success brings change to most software systems, and often, the greater the success, the greater changes.

To assist designers in creating more adaptable software, the concept of design patterns is being explored in both industrial and research environments. Design patterns are high-level abstractions that reflect the experience of skilled practitioners and describe, according to a given format, the context, problems, solutions, and consequences of making specific design decisions [Gamma94].

Due to their utility, design patterns are drawing a growing interest, as manifested through their use in commercial frameworks, notably, the Java 2 Platform, Enterprise Edition (J2EE) -- an open standard for implementing and deploying component-based enterprise applications.

This paper presents ADAPT (ADAptable PaTterns) - an ongoing project whose goal is to develop methods for effectively developing adaptable software using patterns.. In order to achieve this goal, ADAPT adapts the NFR Framework [Chung00] [Mylopoulos01], in which software adaptability, as a non-functional requirement (NFR), is treated as a softgoal to be satisficed (i.e., achieved not absolutely but within acceptable limits). Through this adaptation, ADAPT then explores both definitional and design alternatives to satisfice the adaptability softgoal, analyzes tradeoffs among the alternatives, estimates the impact of the alternative design patterns upon software adaptability, and selects among the alternatives in relation to the domain characteristics (i.e., context and problem). Through the adapation, ADAPT will also offer a knowledge base of design patterns organized along a set of hierarchies, capturing both general and adaptability-specific ones (e.g., [Gamma94], [Pree95], [Irving96] and [Schmidt00]).

Section 2 describes those patterns that have been recognized as potential adaptability enhancers. Section 3 presents the ADAPT approach to analyze and use, or not use, such potential adaptability enhancers in developing a software system. Section 4 presents a knowledge-based aspect of the ADAPT approach for facilitating the analysis and use of potential adaptability enhancers.

2. Patterns Potentially Enhancing Adaptability

Several patterns have been identified as (potentially) enhancing the adaptability of real-time software systems [Schmidt00], and some of architectural design patterns are briefly presented below.

Wrapper Pattern

Intent: To encapsulate lower-level functions within type-safe, modular, and portable class interfaces

2 Helps to 1) avoid tedious, error-prone, and non-portable programming of low-level IPC mechanisms; 2) combine multiple related, but independent, functions into a single cohesive abstraction.

Figure 1. Structure of the Wrapper pattern

Reactor Pattern

Intent: To decouple event demultiplexing and event handler dispatching from the services performed in response to events.

3

4 Helps to 1)demultiplex multiple types of events from multiple sources of events efficiently within a single thread of control; 2)extend application behavior without requiring changes to the event demultiplexing/dispatching framework.

5

[pic]

Figure 2. Structure of the Reactor Pattern

Strategy Pattern

Intent: To define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

6 Helps to extend the policies for advertising, listening, creating, accepting, and executing a service handler without modifying the core algorithm.

[pic]

Figure 3. Structure of the Strategy Pattern

3

3. Developing Adaptable Software Using Patterns

ADAPT is an ongoing project whose goal is to develop methods for effectively developing adaptable software using patterns. In order to achieve these goals, ADAPT adapts the NFR Framework [Chung00] [Mylopoulos01], in which software adaptability, as a non-functional requirement (NFR), is treated as a softgoal to be satisficed (i.e., achieved not absolutely but within acceptable limits). Through this adaptation, ADAPT then explores both definitional and design alternatives to satisfice the adaptability softgoal, analyzes tradeoffs among the alternatives, estimates the impact of the alternative design patterns upon software adaptability, and selects among the alternatives in relation to the domain characteristics (i.e., context and problem). The whole process is carried out in terms of a visual representation, called softgoal interdependency graph, where each node represents a softgoal and each link between a parent goal and its descendants represents the degree to which the descendants (positively or negatively) contribute to the satisficing of the goal.

For example, Figure 4 shows a softgoal inderdependency graph for developing adaptable Remotely Controlled Embedded System (RCES) [Subramanian01]. The top

Figure 4. Softgoal Interdependency Graph for Adaptable RCES.

softgoal (a thin cloud), Adaptability [RCES], is AND-decomposed (a single arc) into two descendant goals: Detectability [Change in environment] and Transformability [RCES]. The latter in turn is further AND-decomposed into two subgoals: Recognizability [Change in RCES] and Enactability [Change in RCES]. The top goal is also OR-decomposed (a double arc) into Automatic Adaptability [RCES] and Manual Adaptability [RCES]. When a goal is multiply decomposed, there can be a cartesian product of subgoals.

Transformability [RCES] is connected to two dark clouds through green lines (+): Low Coupling [Architecture, RCES] and High Cohesion [Architecture, RCES], which represent architectural-level design techniques for positively satisficing Transformability [RCES]. Figure 4 also shows further refinements of Low Coupling [Architecture, RCES]. Architectural patterns then come into play here during the consideration of satisficing these architectural-level design techniques.

For real-time systems, speed often is a key NFR. As such, adaptability may need to be compromised in favor of speed. Figure 4 shows such considerations involving Detectability [Change in environment] and Reactor Pattern [Architecture, RCES].

Using softgoal interdependency graph, context-dependent nature of adaptability can be considered and represented in terms of the domain characteristics (represented as claims), different priorities can be associated with different softgoals, and the degree to which softgoals are satisficed or denied can also be evaluated.

4. Knowledge-Base of Design Patterns

Searching for patterns, which are potential adaptability enhancers, can be a time-consuming and difficult task. This is especially true when many pattern descriptions, or even a section, can run into several pages and the number of patterns grows to hundreds or even thousands. A knowledge-base of such patterns could significantly shorten the search time and facilitate effective use in developing adaptable real-time systems, if it represents a comprehensive survey of existing patterns and efficient organization. We observe that many patterns are indeed related to one another and can be arranged in some hierarchical form.

Through the adapation of the NFR Framework, ADAPT will offer a knowledge base of inference rules about patterns organized along a set of hierarchies, capturing both general and adaptability-specific ones (e.g., [Gamma94], [Pree95], [Irving96] and [Schmidt00]; loose coupling, localized tight coupling, of components [Sane95]). For example, Figure 5 shows a couple of inference rules, each depicted pictorially by a hierarchy consisting of a parent and its immediate descendants: 1) To satisfice Type1 [Topic1], satisfice Type2 [Topic2] and … and Typen [Topicn]; 2) Type2 [Topic2] helps Type1 [Topic1].

Figure 5. Inference Rules.

One such hierarchy can be constructed using the Wrapper, Façade, and Strategy patterns: Wrapper Facade Pattern, Strategy Facade Pattern , Strategy Wrapper Pattern, and Wrapper Strategy Facade Pattern. A couple of other patterns are shown below:

Loose-Coupling Pattern  Strategy Pattern

         -  (Variable) Strategy Pattern  - Policy Strategy Pattern

         - Platform-independent Pattern - Proactive Strategy Pattern

                - Thread-Specific Storage Pattern - Dynamic Proactive Strategy P

         - Implicit-invocation Pattern - Static Proactive Strategy P

                - Reactor Pattern - Reactive Strategy Pattern

                - Event Manager Pattern - Algorithmic Strategy Pattern

    - Reactive Strategy Pattern

- Proactive Strategy Pattern

     Tight-Coupling Pattern

         - Fixed Strategy Pattern

         ...            

     

Ranking of design patterns is possible through several contribution types too: break (--), hurt (-), help (+), make (++).

Each pattern in a hierachy can be either primitive or complex, and can be a sub-pattern of more than one super-patterns. Relationships between patterns can be about super-sub intents, problems, contexts, solutions, overlaps, etc. Once patterns are put into a hierarchical form, we can have a tool, which, given a keyword, would search up the associated pattern and display its subgroups. The user can thus browse and find the pattern most suitable to his/her needs. However, if the user is not satisfied with the search results, then the tool should accept information about the required pattern and upgrade its hierarchy database so as to improve the search results in the future. many patterns are very similar to each other, but differ subtly. Hence, for a given problem, more than one of the existing patterns may seem to fit. But the cost (in terms of implementation effort) of using each of them may be different. Moreover, this cost cannot always be estimated beforehand, and so the use of one of the candidate patterns is a subjective decision (or maybe a guess).

5. Conclusions

Design patterns are drawing increasing interests for improving software adaptability due to the fact software adaptation is almost an inevitable process. This paper has presented the ADAPT approach to the analysis and use of architectural design patterns which are potential adaptability enhancers in developing real-time software systems. Future work includes use of the ADAPT approach for J2EE applications, populating ADAPT knowledge bases, and mapping pattern language categories into Softgoal Interdependency Graph representations.

References

[Brooks87] F. P. Brooks, Jr., “No Silver Bullet: Essence and Accidents of Software Engineering,” Computer Magazine, April 1987.

[Buschmann96] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal,

Pattern-Oriented Software Architecture - A System of Patterns, Wiley and Sons Ltd., 1996.

[Chung00] L. Chung, B. A. Nixon, E. Yu and J. Mylopoulos, Non-Functional Requirements in Software Engineering, Kluwer Academic Publishing, 2000.

[Gamma94] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.

[Gullekson96] G. Gullekson and B. Selic, "Design Patterns for Real-Time Software,"

Embedded Systems Conference, West`96.

[Irving96] C. Irving and D. Eichmann. "Patterns and Design Adaptability," 3rd Annual Conference on the Pattern Languages of Programs, Allenon Park, Illinois, Sept. 46, 1996.

[Mylopoulos01] J. Mylopoulos, L. Chung, S. S. Y. Liao, H. Wang and Eric Yu, "Extending Object-Oriented Analysis to Explore Alternatives," IEEE Software, January/February, 2001. pp. 2-6.

[Pree95] W. Pree, Design Patterns for Object Oriented Development, Reading, MA. Addison Wesley and ACM press. 1995.

[Sane95] A. Sane and R. Campbell, "Composite Messages: A Structural Pattern for Communication Between Components," OOPSLA Workshop on Design Patterns for Concurrent, Parallel and Distributed Object-Oriented Systems, 1995.

[Schmidt00] D. C. Schmidt, M. Stal, H. Rohnert and F. Buschmann, Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects, Wiley & Sons, 2000.

[Subramanian01] N. Subramanian and L. Chung, "Software Architecture Adaptability: An NFR Approach," IWPSE`01 (To appear).

-----------------------

Wrapper

 request( )

request( )

Client

Wrappee

 specific_request( )

specific_request( )

Speed

[RCES]

Adaptability

[RCES]

Automatic-

Transformability

[RCES]

Manual-

Enactability

Recognizability

Detectability

[Change in RCES]

[Change in RCES]

[Change in environment]

High Cohesion

[Architecture, RCES]

Low Coupling

[Architecture,RCES]

Low # Connection

[Architecture, RCES]

Loose Coupling

[Architecture, RCES]

Indirect Connection

[Architecture, RCES]

Mediated Connection

[Architecture, RCES]

Wrapper Pattern

[Architecture, RCES]

Strategy Pattern

[Architecture, RCES]

Reactor Pattern

[Architecture, RCES]

Type1 [Topic1]

Type1 [Topic1]

Type2 [Topic2]

Type2 [Topic2]

Typen [Topicn]

(2) Operationalization

(1) AND decomposition

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download