In-Depth

Toward Pattern-Oriented Frameworks

  • By Sherif M. Yacoub , H. H. Ammar
  • July 16, 2001

Abstract

Much effort has been expended by experienced designers and researchers to document quality practices in software design in the form of design patterns. Less emphasis, however, has been placed on systematically reusing these proven solutions, which is a basic benefit of claiming reusability of the documented design pattern catalogs. We present an approach for constructing object-oriented (OO) design frameworks using design patterns as building blocks. The resulting frameworks are named pattern-oriented frameworks. The construction of pattern-oriented frameworks is illustrated using an example of a common engineering application, namely closed-loop control systems. These systems are commonly described in terms of block diagrams. The feedback control framework is presented as a generic architecture based on design patterns. A pattern diagram is defined to express the framework's architecture in terms of subsystems, design patterns, and associations. A development process is proposed to express the framework in two design levels: a pattern diagram and a class diagram. Two approaches for framework instantiations are illustrated. The instantiation of the framework in an example is presented to show the benefits of the pattern-oriented frameworks approach.

Many application designers are motivated to utilize reusable components in their applications to reduce the effort and time of software development. Reusable components range from simple classes and libraries to reusable patterns and frameworks. The level of component reuse in the development life cycle depends on the nature and granularity of the component and the decisions made by the component designer on behalf of the component user. A simple design decision, like the reuse of a library class or an API, is commonest and easiest to use. The next level is reuse of design patterns, and the most difficult and sophisticated level is reuse of frameworks in which a wide range of design decisions has already been made by the framework designer.

Recently, design patterns were introduced to document good OO designs.1-5 In general, a pattern describes a problem that frequently occurs in software applications, then describes its solution in such a way that it can be reused.6 Patterns can be classified, according to the level in which they are used, into analysis patterns,7 design patterns,1 and architecture patterns.5 In building design frameworks, we focus on reusing design patterns such as the Strategy and Observer Patterns.1

It is clear that less emphasis has been placed on systematically deploying these reusable designs than on mining and documenting them. Reusing software in practical applications is a difficult task, yet it is required to reduce development effort and assure high software quality. Code reusability is the most popular and common form of reuse. Reusable designs and frameworks are less frequently used due to the complexity and difficulty of constructing generic designs for common engineering problems.

Many authors have defined frameworks in different contexts. Generally, a framework is a frame on which (or around which) something will be made (built). Fayad et al.8 present a comprehensive discussion on OO frameworks in which they classify application frameworks and discuss their general strengths and weaknesses. Johnson et al.9 describe a framework as a reusable "semi-complete" application that can be specialized to produce custom applications. They discuss classifications of white- and black-box frameworks. In black-box frameworks, the source code of the original framework cannot be modified, only extended,10 while white-box frameworks require understanding of the frameworks structure and the hot spots to which application-specific functions are hooked. D'Souza11 refers to frameworks as "a pattern of model or code that can be applied to different problems," and further refers to OO frameworks as "collaborations with a default, skeletal implementation." Schmid12 classifies frameworks as application- or domain-specific. Application-specific frameworks provide the basic functionalities of a working application, but the specific contents that model the application domain have to be added for each particular application. Domain-specific frameworks are less commonly used; they model the domain-specific functionality using common objects and generic application logic that can be found in a particular domain. An application is built by configuring these objects and binding the generic application logic to the configuration. Rogers13 describes a framework as:

A class library that captures patterns of interaction between objects, ... consists of a suite of concrete and abstract classes, explicitly designed to be used together. Applications are developed from a framework by completion and implementation of abstract classes.
Buschmann et al.5 define frameworks in an architectural context as:

A partially complete software system that is intended to be instantiated. It defines the architecture for a family of systems and provides the basic building blocks to create them. It also specifies the places where adaptations for specific functionality should be made. In an object oriented environment a framework consists of abstract and concrete classes.
We are concerned with what we called pattern-oriented frameworks, which are design frameworks constructed from design patterns. We address the problem of constructing these frameworks by using design patterns as their building components, using a feedback control framework as a case study. Feedback control systems are used in many applications that include monitoring and control functions. Thus, a generic design for such a common problem serves many software designers. Moreover, it is a small-scale framework that illustrates the feasibility of the approach.

Pattern-oriented frameworks are white-box frameworks. The framework user has to understand the design as interfacing patterns (referred to later as pattern diagrams) to instantiate the framework in his application. Pattern-oriented frameworks are also application-specific frameworks, as they provide the basic functionality and architecture of applications in a given problem domain.

The life cycle of frameworks has two phases: construction and reuse. Pattern-oriented frameworks are constructed at the high-level design of a software development process, therefore the intended users of these frameworks are system designers. Such frameworks can be considered as white-box frameworks whose frozen spots describe the framework architecture that need not be modified by the framework user. Their hot spots are those parts that are application specific and will be implemented by the framework user in a particular application. The construction process of a framework is illustrated using the feedback control framework as an example. Two instantiation approaches of frameworks are discussed. A simple example of the quality control in a production line14 shows how the structure of the framework is not modified in the instantiation (reuse) phase, while the application-specific methods and attributes are added to the framework concrete classes to implement application-specific behavior.

RELATED WORK
This is work related to the concept of frameworks, framework construction process, and framework instantiation in applications. The discussion of framework construction based on patterns shows that building frameworks based only on patterns has not received enough research attention, though its benefits are well-known and understood. Several tools are built to support usage of design patterns, a fact that motivates pursuing a pattern-oriented framework approach and adding a pattern view of frameworks to these tools.

We have presented several definitions of a framework to distinguish the concept of pattern-oriented frameworks and show that many authors have different interpretations of what constitutes a framework. These definitions are not conflicting, rather they describe several aspects of frameworks such as the structure (how it is constructed), instantiation (how it is used), and classification of frameworks (black box/white box or application/domain-specific). Most of the work refers to frameworks as collaborating classes and presents them as class participants whenever patterns are used. Beck and Johnson15 show how patterns can be used to derive the HotDraw architecture, easing understanding of the final system, but do not explicitly discuss how the patterns interact and collaborate together as we will. In this article, we refer to pattern-oriented frameworks as design frameworks defined by an architecture of communicating design patterns (in a pattern-level view), which are further extended to classes and objects (in a class-level view). Framework construction in terms of design patterns adds to the reusability and descriptive capability of the design framework because patterns can coexist and may depend on one another. Moreover, using well-established design patterns as components can contribute to the design quality of the constructed framework.

Johnson16 describes how patterns can be thought of as microarchitecture elements, hence a single framework contains many patterns. Pattern-oriented frameworks are closely related to his definition. We introduce a pattern-level architecture description of frameworks in terms of a pattern diagram that we perceive as an approach to solve the complexity problems and the difficulty of understanding white-box frameworks as discussed in the literature.8,9,16 This approach addresses reuse at the design level, which differs from code reuse.16

Castellani and Liao17 propose an application development process that focuses on the reuse of OO application design. Their work presents a process that allows the system designer to create generic applications and reuse them in other application designs in the same problem domain. Their approach starts with an existing application then abstracts design macrocomponents through application specifics. However, the authors use a general definition of macrocomponents (frameworks or patterns) that allows any group of related classes to be considered a pattern. An application, in the context of their development process, is split into macrocomponents, which are filled later on with classes. The authors do not consider partitioning the application into subsystems. In our approach, we construct frameworks using generic design patterns whose designs are predefined in the patterns literature. We also tackle the genericity of designs, but from the perspective of constructing design frameworks with generic patterns. We adopt a top-down design approach that starts from architectural design based on a pattern diagram, proceeds with expansion of patterns into their predefined class diagrams, and further refines the class diagram through reduction and grouping phases to reach a final class diagram of the framework.

Odenthal and Quibeldey-Cirkel18 describe the benefits of using design patterns as an intermediate level of systems description between the analysis and design levels. They address two important issues: deploying patterns in designs, including how to identify candidate patterns, and adding a documentation level based on patterns. The pattern level reduces the descriptive complexity by covering the design with pattern instances. Identifying candidate patterns is closely related to pattern-oriented framework construction; however, the authors do not show how the selected patterns are put together to construct the overall system.

Schmid19 discusses an architecture for manufacturing systems. He starts from an existing OO analysis and targets a more general and flexible architecture for automated manufacturing systems like assembly lines. Although successive transformation steps are guided by design patterns to create an overall architecture, patterns are not used as design building blocks. A design framework for manufacturing applications is proposed by Bosch20 for measurement systems. In this framework, design patterns are used to some extent in the design phase. The framework provides more details related to other subsystem components such as sensors and actuators.

As for instantiating patterns, several tools have been developed to aid the process. For code generation and pattern instantiation purposes, a tool called FACE21 was developed to guide the process of instantiating patterns by starting with a primal-schema, containing the abstract classes of a pattern and their association, then proceeding to a meta-schema for concrete classes, operations, and associations. A more global view of deploying patterns in design22 uses a meta-pattern called "HOOK&TEMPLATE" to distinguish between pattern components that will be implemented by the user "HOOKS," and those components that are already defined for the pattern class collaboration "TEMPLATES." The discussion in that work about a pattern "metamodel" explains how patterns from a pattern repository can be instantiated. The "fragmentation" technique23 shows another approach for binding patterns together with each other and with other nonpattern classes. Patterns are instantiated and decomposed into fragments, then associated with other components. This approach does bind patterns together with other program elements, but at a lower level of fragments, so we believe it would be difficult for large designs. The PSiGene CASE tool24 is another tool for binding patterns from a predefined catalog. This method is application specific (building simulators) and also generates the classes and methods for specific patterns from a catalog, but doesn't link them together in a higher design level. The tool developed by IBM25 shows how code can be automatically generated for a pattern by supplying application-specific information of a selected pattern.

Yet none of the proposed methods or developed tools discusses how to construct the framework by putting together design patterns, which would provide a good level of abstraction in the design and ease framework reuse. The main concern of most of the tools was the instantiation, implementation, and code generation for design patterns.

DESIGN PATTERNS
Constructing frameworks using design patterns provides a high level of genericity that in essence increases frameworks reusability. This section briefly describes three design patterns that we will use to construct the example framework. These patterns are in the category of patterns that can be frequently used as building blocks of application-specific frameworks. The Strategy, Observer, and Blackboard Patterns are summarized here (a detailed description of each pattern is found in the literature1,5,13).

Strategy Pattern
The intent of a Strategy Pattern is to define a flexible design that solves the problem of choosing between alternative strategies and algorithms. The Strategy Pattern lets the algorithm vary independently from other system objects that use it.1 This pattern was chosen because in a generic framework, the high-level design should be implementation independent and should allow many application-specific algorithms to be instantiated easily without modifying the architecture or the protocol of communication between the framework classes. Figure 1 illustrates the UML26 representation of the Strategy Pattern.

Observer Pattern
The intent of the Observer Pattern (see Figure 2) is to provide a way to define dependencies between objects. When an object's state (a subject) is changed, it is sometime required to automatically notify and update other objects (observers).1

Feedback applications are deployed in reactive systems, which receive changes in the plant and act accordingly. The plant is our subject of interest, thus a generic approach is required to isolate the application-specific plant measurements from other framework components (observers); an Observer Pattern will serve the purpose of update notifications.

Blackboard Pattern
The intent of the Blackboard Pattern (see Figure 3) is to reduce the amount of information that needs to be studied and processed simultaneously, by partitioning the data into similar data objects and describing the properties of these data groups.13 Buschmann et al.5 discussed the Blackboard Pattern as an architecture pattern composed of controller, blackboard, and analyzers. We use a simpler version of the blackboard in which it is a system repository. We also added a slight modification by referring to stored data in terms of an abstract data class; we found this useful in adding abstraction to the signature of methods in the framework's components which increases its genericity.

PATTERN-ORIENTED FRAMEWORKS
Figure 4 illustrates a high-level view of a framework lifecycle. Initially, a framework development is triggered by a frequently recurring concept, which constitutes the motivation behind constructing a framework, what purpose it serves, and in which domain it is applicable, such as distributed processing, user interfaces, and business applications.8

The framework development process starts with analysis and planning for development, then various activities (design, detailed design, coding, testing, and documentation) are exercised.11 The framework development team iterates on their product (framework) to ensure that it meets the targeted concepts. Framework instantiation is referred to as applying the framework in particular applications.

A feedback is normally provided from the framework user to the framework designer specifying various problems encountered, which assists the designer in enhancing the framework design. This article focuses on the development process of pattern-oriented frameworks.

Terminology
The terms used in the following discussion are defined as:

  • Pattern-oriented framework: a construct of subsystems and design patterns that collaborate to describe the generic architecture of a design framework.
  • Design pattern: a design component composed of collaborating classes that are customized to solve a design problem in a particular context.
  • Internal subsystem: an independent group of patterns that collaborate to fulfill a set of responsibilities1 in the framework. The architecture and behavior of a design framework is realized by means of subsystems interacting with each other and with external subsystems. Modularity plays an important role in decomposing a system into subsystems.
  • External subsystem: a subsystem that is not part of the framework under development, it can be a part of the real-world environment or other frameworks or applications.
  • Actors: external entities interacting with the framework.
  • Class associations: relationships between classes, such as aggregation, composition, generalization, and dependency as specified in UML.24
  • Dependency: in general, implies that the complete functioning of an element requires the presence of another, which exists in the same level of abstraction or realization (i.e., pattern, class, or subsystem level of abstraction).
  • Pattern associations: relationships between patterns in a pattern diagram. Currently, dependencies are defined as one type of pattern relationship. A pattern dependency indicates a semantic relationship between two patterns; a situation in which a change to the source pattern may require a change to the target pattern, or a pattern delegates the processing of a certain function to the other. This relationship is further refined in later design phases to indicate the exact nature of the dependency by translating it into class associations between classes of two communicating patterns.
  • Subsystem associations: a general dependency relationship between subsystems in which the change in one subsystem affects the other. A dependency between two internal subsystems implies that one or more dependencies among their patterns exists. The relation is stereotyped further to indicate the exact nature of the dependency, such as calling operation of one pattern to the other, usage of one pattern of the other, etc.
These terms are more formally defined as follows:


 := < subsystem="">* *
 :=  | 
 := * *
 := * *
 := * *
 := * *
 :=  |  | 
 :=  |  |  | 
 := 
 := *
 := 
 := *
Pattern diagram
A pattern-oriented framework is specified by using patterns as building components and defining their collaboration. The current support for patterns in UML26 shows how classes in a class diagram are related to a pattern using a collaboration, which is a dotted ellipse pointing to participant classes. This is a bottom-up approach, because it marks the classes representing a pattern in the design, which doesn't show a pattern as a design component. We used a top-down approach in the development process where the framework is partitioned into subsystems and patterns, and then the patterns are exploded into classes. A pattern diagram* is used to describe the framework in terms of subsystems, design patterns, and associations. The elements used in the pattern diagram are shown in Figure 5.
  • Design Pattern: represented as a rectangular box labeled with the pattern name and type as "Pattern Name : Type". We refer to the type here as the name of a known documented pattern. For example a Strategy Pattern used in a feedback subsystem is named "FeedbackStrategy : Strategy".
  • Internal subsystem: represented in the form of a dotted ellipse with the subsystem name on top.
  • External subsystems: not part of the framework, represented in the form of a solid ellipse labeled with the subsystem name.
  • Association: The relationship between patterns is represented in terms of a solid line joining the patterns labeled with the association name. The relationship between subsystems is represented as a dotted line labeled with the association name. Arrowheads are used to show the association direction when applicable.
  • Actors: represented by a stick figure and associated with subsystems using the dotted association line.
Framework development process
Figure 6 illustrates the development process steps of pattern-oriented frameworks. The rectangular boxes show the activities, while the ellipses show the inputs and outputs of each activity.

The closed-loop control system is subdivided into subsystems based on independent responsibilities-functional and behavioral wise. Referring to control literature,25,28,29 the generic block diagram of feedback systems represents an initial architecture documentation. Subsystems are identified, the requirements of each subsystem are studied, and a set of design patterns is chosen accordingly to satisfy the required functionalities. Each subsystem is then represented in the form of design patterns and associations. The following development process steps show how to construct the pattern diagram, then reduce it to a final class diagram.

Step 1: system analysis. Many practical reactive systems encompass software control applications in their implementation. The portion of a system to be controlled is called the plant or process.29 A closed-loop system (see Figure 7) is one in which the control action is somehow dependent on the output. Feedback is the property of a closed-loop system that permits a measured output to be compared to the system's input so that the appropriate control action may be performed as some function of the output and the input.29

An output variable is adjusted as required by the error signal. Generally, a controller is required to process the error signal such that a certain control strategy will be applied and a system specification is satisfied. Some or all of the system outputs are measured and used by the controller. To implement a feedback control system, the specification and description of the system configuration and its components must be put into a form amenable to analysis and design. Three basic representations (models) of components and systems are used extensively in the study of control systems: mathematical models, block diagrams, and signal-flow graphs. We are not concerned with theoretical analysis and design techniques for a feedback control system.30 Instead, we are more concerned with OO design and implementation of the feedback system in a reusable structure that is easy to implement and instantiate.

Step 2: subsystems identification. Using the generic block diagram of a closed-loop control system (shown in Figure 7), the framework is decomposed into the following subsystems:

  • Feedforward subsystem-processes the error data and applies a control algorithm to the plant.
  • Feedback subsystem-measures and processes data from the plant and provides the feedback data.
  • Error calculation subsystem-compares the input and feedback data and produces the error.
  • Plant-external subsystem on which control is applied and from which measurements are taken.
Step 3: subsystem analysis. In this step, each subsystem is analyzed and candidate design patterns are chosen. The output of this step is the pattern diagram.

  1. The feedforward subsystem implements some sort of a control strategy; the change in the strategy should be flexible and hidden from any calls and invocations from any other components. Thus, a Strategy Pattern is a good candidate for the task.
  2. The feedback subsystem receives measurements and applies a feedback control strategy, then feeds the result to the error calculation subsystem.

    The measurement unit observes and measures data from the plant and feeds it to the feedback branch. Thus, measurement observations are communicated to the feedback controller using the Observer Pattern. The measured data is fed to the feedback control strategy that is implemented using another Strategy Pattern.

  3. The error calculation subsystem: The feedback controller notifies the error calculation unit with the feedback data. The feedback controller can be viewed as the subject that notifies the error calculator of the changes in the feedback data. This is implemented using the Observer Pattern.
  4. Data of different types need to be exchanged between the framework components. We used the Blackboard Pattern for managing the system repository.
Thus, the framework can be built by gluing design patterns as shown in Figure 8. The pattern diagram is a high-level design diagram; it describes the architecture of a feedback system using patterns, which explains why the name "pattern-oriented framework" is chosen.

Step 4: pattern instantiation and expansion. In this step, the patterns in each subsystem are expressed in terms of their collaborating classes. The classes are renamed to have meaningful presence in the feedback framework context.

Feedforward subsystem
Figure 9 illustrates the forward control subsystem, a simple subsystem composed of one design pattern-the FeedforwardStrategy Pattern.

The FeedforwardStrategy Pattern is composed of:

  • Controller: the context of the control strategy that is configured with a concrete control strategy object through a reference to an Abstract_Controller interface.
  • Abstract_Controller: the interface for all concrete control strategies. The Controller uses this interface to invoke the concrete control strategy algorithm.
  • Concrete control strategies (ControlStrategy1, ControlStrategy2): Various implementations of control strategies to choose from.
Error calculation subsystem
The error calculation subsystem (see Figure 10) consists of the ErrorObserver and ErrorBlackboard Patterns. The ErrorObserver is composed of:

 

  • AbstractObserver: an updating interface for objects that are notified of changes in the subject.
  • AbstractSubject: an interface for attaching and detaching observers. It knows about its observers that ought to be notified of a subject's change.
  • Concrete observer Error_Observer: maintains a reference to the Feedback_Subject, reads the feedback data after being processed by the feedback strategy, analyzes the feedback data with respect to the reference input data, and stores the error in the blackboard. It implements the AbstractObserver updating interface.
  • Concrete subject Feedback_Subject: sends notification to the concrete observers of new data received from the feedback subsystem.
ErrorBlackboard is composed of:

  • Blackboard: the interface for retrieving and storing data. For the error subsystem, it stores error data for successive readings, and provides interfaces for retrieving and storing data records.
  • AbstractData: an interface to all types of data, this class is added to facilitate manipulating and referring to data in various class method signatures.
  • ErrorData: the concrete error data record to be stored in the application repository.
Feedback subsystem
The feedback subsystem (see Figure 11) consists of the FeedbackObserver, the FeedbackStrategy, and the FeedbackBlackboard Patterns.

FeedbackObserver is composed of:

  • AbstractObserver2 and AbstractSubject2: play an interface role similar to those of the ErrorObserver in the error subsystem.
  • Measurement_Subject: receives measurement notifications from the plant and notifies its observer (Feedback_Observer) that a measurement is ready.
  • Feedback_Observer: is notified by changes in the plant through the Measurement_Subject. It pulls the data identifier from the subject (using the pull mode of the Observer Pattern) and invokes the feedback controller to process the measured data.
FeedbackBlackboard is composed of:

  • AbstractData and Blackboard: same functionality as those of the ErrorBlackboard in the error subsystem.
  • MeasuredData: concrete data record measured from the plant.
  • FeedbackData: data after being processed by the feedback control strategy.
The FeedbackStrategy pattern is composed of:

  • Feedback: context of the feedback control strategy. It is configured with a feedback control strategy object through a reference to an FB_Abstract_Controller.
  • FB_Abstract_Controller: interface for all feedback control strategies. Feedback uses this interface to call the feedback concrete algorithm.
  • FB_ControlStrategy1 and FB_ControlStrategy2: concrete implementations for feedback control strategies.
The Feedback_Observer invokes the control routine of the Feedback that applies the feedback control strategy required from the subsystem. The Feedback class interacts with the Feedback_Subject of the Observer Pattern in the error calculation subsystem and invokes its notify procedure. This establishes the link between the feedback subsystem and the error calculation subsystem. The class diagram of the overall system is shown in Figure 12.

Step 5: reduction. In this step, eliminating replicated abstract classes reduces the complexity of the framework. A pattern has one or more abstract classes. Because the same pattern type is used in more than one subsystem, we may expect to find abstract classes with similar interfaces. In this sense, an abstract class should appear once and be subclassed according to concrete implementations. In Figures 10 and 11, the Observer Pattern is used in the feedback subsystem and in the error subsystem, thus the classes AbstractObserver and AbstractSubject are replicated. Similarly, the abstract class Abstract_Controller of the Strategy Pattern is used in the feedforward and feedback subsystems. Therefore, the replicated classes are eliminated, and only one common version of the abstract classes is used.

Step 6: grouping. In this step, more optimization in class usage is projected by merging concrete classes together depending on their interaction and responsibilities. This step brings the framework's class diagram to a more dense and profound form, and mainly depends on the skills of the framework designer. From Figure 12, we note that the classes Feedback_Observer, Feedback_Subject, and Feedback perform highly related functions, which are summarized as receiving measurement notification, applying control strategy, and notifying the error subsystem that the feedback data is ready. Instead of implementing a primitive function in each class, the three classes are merged into one class Feedback_Subject_Observer. Similarly, one Blackboard class and one AbstractData class are used since an application would normally have one repository. Figure 13 illustrates the final class diagram of the framework.

We can still identify patterns in the class diagram as follows:

  • FeedforwardStrategy:Strategy is composed of the classes Controller, Abstract_Controller, ControlStrategy1, and ControlStrategy2.
  • FeedbackObserver:Observer is composed of the classes AbstractSubject, AbstractObserver, Measurement_Subject (a concrete subject) , and Feedback_Subject_Observer (a concrete observer).
  • ErrorObserver:Observer is composed of the classes AbstractSubject, AbstractObserver, Feedback_Subject_Observer (a concrete subject), and Error_Observer (a concrete observer).
  • FeedbackStrategy:Strategy is composed of the classes Feedback_Subject_Observer (the controller), Abstract_Controller, ControlStrategy1, and ControlStrategy2.
  • FeedbackBlackboard and ErrorBlackboard:Blackboard: the Blackboard, AbstractData, and the inherited data subclasses MeasuredData, FeedbackData, and ErrorData, which are information data classes used by Measurement_Subject, Feedback_Subject_Observer, and Error_Observer.
We note that class Feedback_Subject_Observer is a common player in multiple patterns:

  • It is the observer for Measurement_Subject in FeedbackObserver, and is notified by changes in MeasuredData.
  • It acts as a controller in FeedbackStrategy that invokes a concrete control strategy to be applied on the FeedbackData.
  • It acts as a subject for ErrorObserver, and notifies the observer to changes in the FeedbackData.
It is noted that reduction and grouping of the instantiated patterns decrease the traceability of the patterns in the final class diagram (a problem addressed by Bosch31) as a result of lack of patterns support in OO designs. But this may not be perceived as a major problem in constructing pattern-oriented frameworks because:

  • The framework user is still left with a pattern diagram that can be recalled as a substitute for the final class diagram.
  • When referring to the final class diagram, the architecture of the framework as collaborating classes is the main interest of the framework user, and knowing how it came out of patterns is of less interest at that level.
We are currently developing a tool32 to support pattern level views27 and their traceability to the optimized class diagram of the framework.

Framework instantiation
Recalling Figure 6, a pattern-oriented framework can be expressed in a pattern diagram view or a class diagram view and thus can be reused starting from either level: pattern level or class level (see Figure 14).

Pattern-level instantiation. Pattern-oriented frameworks are represented in the form of pattern diagrams such as that shown in Figure 8. The framework user can initially use one as an architectural diagram of the system. The framework user instantiates the patterns by expanding them into classes and then carries out the reduction and grouping steps. The design is then refined and details are added; then code can be generated using a code generation tool, which starts from class diagrams. It is more comprehensive for the framework user to instantiate the framework starting at the pattern level since the details are hidden and it provides the architecture in a higher level of abstraction. The disadvantage of such an approach is that users need to map the high-level associations between patterns into class associations and rework their own reduction process as illustrated in the previous section.

Class-level instantiation. Alternatively, the framework users can instantiate the reduced class diagram. We showed in a previous work14 how the feedback design framework is instantiated in a feedback application in the quality control line of a "Beverage Bottle System." This system is commonly used in the quality control section of the production line, where it is usually required to separate the acceptable and unacceptable items based on a particular criteria supplied by the system user and compared to the feedback data taken from real-world measurements of the item under inspection. Some of the results experienced in the instantiation were:

  • Instantiation from the class diagram is difficult due to its high complexity; the user has to understand the framework hot spots, i.e., where to add the implementation-specific code.
  • Decreasing the dependencies between several parts of the framework adds simplicity to the design and increases the flexibility of using and instantiating the framework. The architecture and collaboration between classes is not changed, only implementation details such as the data types, the repository data format, and the arm motion control are specified.
CONCLUSION
We have presented a new approach to design frameworks based on design patterns using a closed-loop framework. The resulting frameworks are called pattern-oriented frameworks. A framework construction process was examined and a pattern level described as a higher design layer than class diagrams. The feedback framework showed how a framework design can be expressed using design patterns then expanding the design in terms of classes. Ordinary techniques represent the framework in terms of classes and their interaction.

The approach of using design patterns in constructing a framework makes it more reusable and easier to understand. We described two approaches for instantiating the frameworks and briefly discussed the benefits and liabilities of each. We consider this work as an initial step to:

  1. Design applications from generic frameworks constructed based on patterns as design components.
  2. Lever reuse to the design level, because the architecture design based on patterns provides a higher level of abstraction.
  3. Reduce development time and effort. As illustrated, the designer of a feedback application can always start with the framework in the pattern level instead of wasting effort and time to start up with his own architecture and class diagram.
The feedback application is used to illustrate these concepts. We do not claim that this methodology is applicable to all application-specific frameworks in general. The applicability to other frameworks for generalization purposes is a current subject of investigation that necessitates further effort to:

  • Formalize the visual presentation for patterns and their interfaces, a step that guides more rigorous approach of discussing collaboration between patterns.27
  • Investigate the applicability of the approach to larger application frameworks.
  • Automate the development process using a tool support27,32 for pattern diagrams in which patterns, subsystems, and their collaborations are defined. The pattern diagram tool support will be integrated with a class diagram view to instantiate patterns and to facilitate the reduction and grouping process to reach the optimized dense class diagram of the framework.
Acknowledgment
This work was funded by the DoD research grant No. DAAH04-96-1-0419, monitored by the Army Research Office, to West Virginia University.

References

  1. Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1995.
  2. Coplien, J. and D. C. Schmidt, eds. Pattern Language of Program Design, Addison-Wesley, Reading, MA, 1995.
  3. Vlissides, J., J. Coplien, and N. L. Kerth, eds. Pattern Language of Program Design 2, Addison-Wesley, Reading, MA, 1996.
  4. Martin, R., D. Riehle, and F. Buschmann, eds. Pattern Language of Program Design 3, Addison-Wesley, Reading, MA, 1998
  5. Buschmann, F. et al. Pattern-Oriented Software Architecture, A System of Patterns, John Wiley & Sons, New York, NY, 1996.
  6. Alexander, C. et al. A Pattern Language, Oxford University Press, New York, NY, 1977.
  7. Fowler, M. Analysis Patterns, Addison-Wesley, Reading, MA, 1997.
  8. Fayad, M. E. and D. C. Schmidt. "Object-Oriented Application Frameworks," Communications of the ACM, 40(10): 32-38, October 1997.
  9. Johnson, R. E. and B. Foote. "Designing Reusable Classes," JOOP, 1(2): 22-35, June/July 1988.
  10. Schmid, H. A. and F. Mueller. "Patterns for Extending Black-Box Frameworks," JOOP, 11(3): 38-47, June 1998.
  11. D'Souza, D. "Interface Specification, Refinement, and Design with UML/Catalysis," JOOP, 11(3): 12-18, June 1998.
  12. Schmid, H. A. "Creating Applications from Components: A Manufacturing Framework Design," IEEE Software, 13(6): 67-75, Nov. 1996.
  13. Rogers, G. F. Framework-Based Software Development in C++, Prentice Hall, Englewood Cliffs, NJ, 1997.
  14. Yacoub, S. M. and H. H. Ammar. "An Object-Oriented Framework for Feedback Control Applications" in Proceedings of Application Specific Software Engineering Technology ASSET '98, IEEE Computer Society, Dallas, Texas, March 1998.
  15. Beck, K. and R. Johnson. "Patterns Generate Architectures" ECOOP '94, LNCS 821:139-149.
  16. Johnson, R. E. "Frameworks = Components + Patterns," Communications of the ACM, 40(10): 39-42, October 1997.
  17. Castellani, X. and S. Y. Liao. "Development Process for the Creation and Reuse of Object-Oriented Generic Applications and Components," JOOP, 11(3): 24-31, June 1998.
  18. Odenthal, G. and K. Quibeldey-Cirkel. "Using Patterns for Design and Documentation," Proceedings of the 11th European Conference of Object Oriented Programming, ECOOP '97, LNCS #1241, pp. 511-529, 1997.
  19. Schmid, H. A. "Creating the Architecture of a manufacturing Framework by Design Patterns", in Proceedings of Object-Oriented Programming Systems, Languages and Applications, OOPSLA '95, 1995.
  20. Bosch, J. "An Object-Oriented Framework for Measurement Systems," in Object-Oriented Application Frameworks: Applications and Experiences, M. Fayad, D.C. Schmidt, and R. Johnson, eds., Wiley, New York, NY, pending. Early version at http://www.ide.hk-r.se/~bosch/papers/, University of Karlskrona/Ronneby.
  21. Meijler, T. D., S. Demeyer, and R. Engel. "Making Design Patterns Explicit in FACE, A Framework Adaptive Composition Environment," in Software Engineering Notes, ESEC/FSE, 22(6): 94-110, Nov. 1997.
  22. Pagel, B., and M. Winter. "Towards Pattern-Based Tools," EuroPLoP Preliminary Conference Proceedings, July 1996.
  23. Florijin, G., M. Meijers, and P. van Winsen. "Tool Support for Object-Oriented Patterns," Proceedings of the European Conference of Object-Oriented Programming, ECOOP, p. 472.
  24. Schuetze, M., J. P. Riegel, and G. Zimmermann. "A Pattern-Based Application Generator for Building Simulation," in Software Engineering Notes, ESEC/FSE, 22(6):468-482.
  25. "Automatic Code Generation from Design Patterns," IBM System Journal, 35(2), 1996.
  26. UML Resource Center. http://www.rational.com/uml/documentation.html.
  27. Yacoub, S. "Pattern-Oriented Analysis and Design (POAD)," Ph.D. Dissertation, Department of Computer Science and Electrical Engineering, West Virginia University, Dec. 1999.
  28. Hosteller, G. H., C. J. Savant, and R. T. Stefani. Design of Feedback Control Systems, CBS college publishing, 1982.
  29. Distefano, J., A. R. Stubberud, and I. J. Williams. Feedback and Control Systems, McGraw-Hill, New York, 1990.
  30. Phillips, C. L. and R. D. Harbor. Feedback Control Systems, Prentice Hall, Englewood Cliffs, NJ, 1988.
  31. Bosch, J. "Design Patterns as Language Constructs," JOOP, 11(2): 18-22, May 1998.
  32. Yacoub, S. and H. Ammar. "Tool Support for Developing Pattern-Oriented Architectures," in Proceedings of the 1st Symposium on Reusable Architectures and Components for Developing Distributed Information Systems (RACDIS '99), Orlando, FL, I(665-670), Aug. 2-3, 1999.

FOOTNOTE
* We further refine a pattern diagram into three logical pattern models: Pattern-Level view, Pattern-Level with Interfaces, and Detailed Pattern view.27

Most   Popular