From Software Architecture to Design Patterns: A Case Study of an

From Software Architecture to Design Patterns: A Case Study of an NFR Approach Jing Wang Towson University [email protected]

Yeong-Tae Song Towson University [email protected]

Abstract There has been extensive research on establishing a non-functional requirement (NFR) framework [3] and applying it systematically in selecting software architectural design alternatives. However there is still a gap between software architecture and concrete detailed design. This paper presents a way to come up with more detailed designs by selecting a set of applicable design patterns. The method in selecting design patterns will be applied step by step systematically in a defined process. After a preliminary selection of a set of potentially applicable design patterns based on existing knowledge, analysis of their applicability is conducted on each of the design patterns. In each analysis process, the potentially applicable design pattern and the chosen architectural design are decomposed; the traceability from software architecture to design patterns is analyzed. This method is applied in the case study on keyword in context system (KWIC) [2] [3]. The notation of NFR approach [4] is further refined.

Keyword Non-functional requirements, architecture, design pattern

software

1. Introduction There has been much research on developing software architectural design from software requirements. One of them is goal-oriented nonfunctional requirement (NFR) approach. Meanwhile, practitioners and researchers defined and cataloged the knowledge of design patterns to benefit novices. This paper aims at introducing a methodology on the selection of design patterns during the process of developing detailed design. The methodology is applied in the case study on KWIC system. We also further refined the notation of NFR approach [4].

1.1. Background With the subjective nature of non-functional requirements (NFRs) and all other reasons which

Lawrence Chung University of Texas at Dallas [email protected]

make them difficult to deal with, t wo basic approaches, product-oriented and processoriented, have been researched and explored extensively in the literatures [12] [13] [14], and are roughly classified into quantitative and qualitative categories. One process-oriented qualitative approach addresses NFRs by applying NFR framework [3]. In the framework, NFRs are represented as softgoals. Softgoals and their interdependencies are represented graphically in the softgoal interdependency graphs (SIGs), which maintain a complete record of the development decisions and design rationales. In the SIGs, the nodes represent softgoals and links represent their interdependencies. Softgoals are decomposed into subgoals. Satisficing NFR softgoals is achieved by satis ficing their subgoals. The results of the NFR approach are software architectural design softgoals, which are represented as leaves in the completed SIGs. Software architectural designs are the designs at a higher level of abstractions dealing with the main components, their interactions, and the constraints on them [2] [7]. Figure 1 is a simplified illustration of the NFR approach for software architectural design. Design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context [1] [5] [9]. We try to utilize the knowledge and experience on design patterns to come up with detailed designs.

1.2. Purposes This paper deals with the process of selecting design patterns. The main purposes are summarized as following: • By NFR approach, we can produce software architectural designs from given requirements, but the coarse-grained software architectural designs need to be further developed into finegrained detailed designs. • It is necessary to systematically reuse the existing catalogue of the knowledge on design patterns.

1/8 Proceedings of the Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Networks (SNPD/SAWN’05) 0-7695-2294-7/05 $20.00 © 2005 IEEE

Legend

Modifiability [System]

Non-Functional Requirement softgoal

Modifiability [Function]

Modifiability [Process] Modifiability [Data Rep]

Deletability [Function]

Extensibility [Function] -

+ -

Software Architecture softgoal Make: ++

Updatability [Function]

Help: +

+

Hurt: Break: - -

Abstract Data Type [Target System] Figure 1: Simplified illustration of NFR approach in the generation of software architectural design • For each software architectural design softgoal, any suitable design pattern may be applied for creational, structural, and behavioral purposes [1]. • Visualization of the selection of design patterns could help to understand, communicate on, and review the system while retaining as much intuitiveness as possible.

1.3. Related Work In this paper, we touched several questions in the illustration of the methodology on design pattern selection. (1). What is software architectural design? There are many definitions about software architectural design, so confusion may incur [8]. We define software architectural design as a high-level abstraction of design characterized by the main components, their interactions and the constraints on them. This is more intuitive rather than formal expression. (2). Are design patterns beneficial? The enthusiasm of identifying, cataloging design patterns in industry and academia has always accompanied with demonstration of their benefits [1] [5] [9]. The aspects of the benefits on applying design patterns that we are concerned with are qualitative rather than quantitative [6]. (3). For the question of how to introduce design patterns, different efforts have been made in different context [4] [15] [11]. In the context of developing adaptable software architecture, a framework supporting development of adaptable software architecture using design patterns was

proposed [4] [15]. In the framework, the NFR framework [3] was extended to select design patterns to satisfice adaptability NFR softgoal in SIG. In this paper, we include traceability analysis from the software architectural design to design patterns.

1.4. Overview This paper is organized into five sections. Section 1 is the introduction of the paper. Section 2 illustrates the process of design with design patterns and the notation. Section 3 is the case study of KWIC system [2] [3]. Section 4 is the observation on the case study. Section 5 concludes the paper.

2. From Software Architecture to Design Patterns: A Methodology This section describes a methodology from software architecture to design patterns. The illustration of the process is followed by the notation.

2.1. Process We now present a design process that utilizes design patterns. The process starts with software requirement document. By applying the NFR approach, a software architectural design is selected. With the aid of knowledge on design patterns, a preliminary selection of design patterns is conducted, which results in a preliminary set of potentially applicable design patterns with priorities. We conduct traceability

2/8 Proceedings of the Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Networks (SNPD/SAWN’05) 0-7695-2294-7/05 $20.00 © 2005 IEEE

Legend

Start No

Requirements

More design patterns Terminator

Design with selected design patterns

Architectural design

Yes

Process

Analysis Document

Architectural design

End

Selected No

Design pattern knowledge base

Yes Set of selected design patterns

Preliminary selection of design patterns

Decision

Flow

Discarded design patterns

Figure 2: Process of design with design patterns. analysis for each of the design patterns in the set according to its priority and make selections. In this process, we decompose the software architectural design softgoal into subgoals and each of the selected design pattern into components with AND or OR relationships hierarchically. The traceability from the components of software architectural design to the components of design patterns is analyzed. With the consideration of NFRs, the applicability of the design pattern is determined. Finally, we justify the interdependencies of the selected set of design patterns. The above process is illustrated in Figure 2.

2.2. Notation In our notation, NFR softgoals are denoted as clouds, software architecture softgoals as clouds with heavily weighted borders, design patterns as clouds with heavily weighted borders and brick patterns. The structures of design patterns provide arrangement of elements such as classes and objects. In our decomposition process, the types of elements, their relationships, responsibilities, and collaborations are chosen as decomposition nodes. The types of elements (subgoals of software architectural design or components of design pattern softgoal) are followed by notation “[E]” to denote “element”,

their relationships, responsibilities, and collaborations are followed by “[I]” to denote “interaction”. Interaction with the nature of data communication is followed by “[I:D]”. Interaction with the nature of process control is followed by “[I:P]”. The AND and OR relationships that are either among the subgoals of software architecture, or among the components of design patterns. AND relationships are expressed as single arch lines, and OR relationship is expressed as double arch lines. The “make” relationship is represented as solid green line with label “++”; the “help” relationship as solid light green line with label “+”; the “hurt” relationship as solid light red line with label “+”; and the “break” relationship as solid red line with label “++”. The notations are illustrated in Figure 3.

3. Case Study: KWIC System The keyword in context system (KWIC) [10] was formulated as following: • The KWIC index system shall accept an ordered set of lines, where each line is an ordered set of words, and each word is an ordered set of characters. • Any line shall be “circularly shifted” by repeatedly removing the first word and

3/8 Proceedings of the Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Networks (SNPD/SAWN’05) 0-7695-2294-7/05 $20.00 © 2005 IEEE

Visual representation

Meaning Non-Functional Requirement Software Architectural Design Design Pattern Element (component/part)

[E]

Interaction (connection/connector/glue/ relationship)

[I]

Interaction: Data communication

[I:D]

Interaction: Process control

[I:P]

Constraint

[C]

AND relationship

OR relationship

Make relationship

++

Help relationship

+

Hurt relationship

+

Break relationship

++

Figure 3: Notation appending it at the end of the line. • The KWIC index system shall output a listing of all circular shifts of all lines in ascending alphabetical order. KWIC example has been explored for software architectural design alternatives including shared data, implicit invocation, abstract data type, pipe and filter [2]. In our approach, potentially applicable software architectural designs are selected by applying goal-oriented NFR approach. Then a set of design patterns is selected. The traceability from the software

architectural design to des ign patterns is evaluated. With consideration of NFRs, the applicability of the design pattern is analyzed. The KWIC example had been used in the course projects in the University of Texas at Dallas. The class size averaged fifty students, altogether several hundreds of students participated the project in the three years. Students in the class made great efforts to incorporate their knowledge of design patterns into the KWIC project, that’s the main basis of the paper. The analysis on the design patterns is incremental. The following explanations are grouped by the types. The types are classified as creational, structural, and behavioral [1]. The creational design patterns used in KWIC system includes Abstract Factory and Singleton, the analysis is illustrated as Figure 4. • Abstract Factory: can be used anywhere that needs to create families of objects. Since data representations and related operations are encapsulated in a number of objects in Abstract Data Type, so Abstract Factory can be applied to create objects for it. • Singleton: comes in when only one instance of Abstract Factory is needed to be globally accessible without resorting to global variables. So it can be used whenever Abstract Factory is applied. Since Abstract Factory can be used for Abstract Data Type, so does Singleton. The structural type includes Adapter, Bridge, Proxy, Façade, Composite, Session Façade, and Transfer Object. Since the last three are generally applicable to all software architectures, we illustrate the first four in Figure 5. • Adapter: can be used anywhere there are reusable existing interfaces that need to be converted to the interface expected by clients. In Implicit Invocation, the existing interface of internal data could be incompatible with the interface of the control module expected by other modules, so Adapter could be applied. • Bridge: can be applied when abstraction and implementation need to be decoupled. In Implicit Invocation, implementation of data could be decoupled from abstraction by applying the Bridge to enhance flexibility. Similarly, it can be applied elsewhere for the same reason. • Proxy: can be used when a local representation of a remote object is needed, or the access to an object need to be controlled, or expensive objects need to be created only on

4/8 Proceedings of the Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Networks (SNPD/SAWN’05) 0-7695-2294-7/05 $20.00 © 2005 IEEE

Comprehensibility [KWIC]

Modifiability [KWIC]

+ + 1. Shared Data [KWIC]

+

++

Performance [KWIC]

+ ++ ++ 3. Implicit Invocation [KWIC]

Modules without data [E] Control module with data [E]

Modules with Masterdata [E] slave [I:P] Shared storage [I:D]

Modules with data, Master-slave [I:P] procedures [E] Access by interface [I:D]

Share data through interface 4. Pipe & Filter [KWIC]

Filter process data [E] Singleton

Abstract Factory

Creation [I] A class [E]

Families of objects [E]

+

Triggered by event [I:P]

2. Abstract Data Type [KWIC]

An interface [E]

Reusability [KWIC]

Pipeline [I:P] Output of current filter is input of next filter [I:D]

A global point of access [I]

One instance [E]

Figure 4: KWIC system: creational design patterns demand. Therefore, generally it can be applied to any of these situations. Specifically in Implicit Invocation, data is shared through interface, so data access need to be controlled, and creation of data object with large amount of data is expensive, and both of these necessitate Proxy. • Façade: can be applied anywhere requiring a unified interface. In Implicit Invocation, the control module can provide a unified interface to manipulate data objects. In Abstract Data Type, each module need to provide a unified interface to a set of interfaces inside the module. • Composite: can be applied anywhere objects can be composed into tree structure to represent part-whole hierarchies. Since any data representation can be in this kind of structure, so Composite can be applied anywhere. • Session Façade: If J2EE client-server architecture is combined, introducing a uniform interface decouples the business objects from the clients, and abstracting the inter-business object interactions promotes manageability of workflow. So it can be applied to all but Pipe & Filter. • Transfer Object: is used to transfer more data with fewer remote calls in J2EE clientserver architecture. It can be used anywhere Session Façade is applied.

The behavioral type used in KWIC system includes Mediator, Strategy, Observer and Iterator. Since Iterator is generally applicable, we illustrate the first three in Figure 6. • Mediator: In Implicit Invocation, the implementation of event dispatching mechanism inside the control module can be applied with Mediator, so objects can be kept from referring to each other. • Observer: In Implicit Invocation, the objects triggering events don’t need to know who the dependent objects are and how many objects need to be notified and updated automatically, so it can be applied. • Strategy: For some common functionalities shared by all of the software architectural design softgoals, such as user data validation, data sorting, etc., there could be several algorithms to choose from, so it can be used in any of them. Particularly in Implicit Invocation, event handling can be implemented with Strategy to reflect different behavior for different event, so avoiding code from many conditional statements. • Iterator: can be applied anywhere elements of aggregate objects need to be accessed sequentially. So, it can be applied to Abstract Data Type and Implicit Invocation, and elswhere if objects are used to encapsulate data.

5/8 Proceedings of the Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Networks (SNPD/SAWN’05) 0-7695-2294-7/05 $20.00 © 2005 IEEE

Comprehensibility [KWIC]

+

Modifiability [KWIC]

++ + + + 1. Shared Data [KWIC]

Performance [KWIC] +

+

+

Reusability [KWIC]

++ ++ + + + 3. Implicit Invocation [KWIC]

++

MasterModules with Modules without slave [I:P] data [E] data [E] Shared Control module storage [I:D] with data [E] 2. Abstract Data Type [KWIC]

++ +

Triggered by event [I:P] Share data through interface [I:D] 4. Pipe & Filter [KWIC]

Filter process Pipeline [I:P] data [E] Master-slave Output of current [I:P] filter is input of Access by next filter [I:D] Bridge interface [I:D]

Modules with data, procedures [E]

Adapter Client

Abstraction [E]

Expected interface [E]

Adapter [E]

Decouple [I]

Implementation [E]

Facade

Proxy Existing interface [E] Class adapter Object adapter Multiple inheritance

A set of interfaces Unidirectional in a subsystem [E] [I] Control Object an object [E] A unified access [I] composition interface [E] A surrogate [E]

Figure 5: KWIC system: structural design patterns To justify the traceability from the Implicit Invocation architectural design to the Adapter design pattern, both of them are treated as goals and are decomposed into subgoals. With the characteris tics of Implicit Invocation, four subgoals are identified in AND relationship, which are Modules without data, Control module with data, Sharing data through interface, and Triggered by event. Among these subgoals, Control module with data is further decomposed into three subgoals in AND relationship, which are Control module interface, Immediate data interface, and Converter. On the other hand, Adapter is decomposed into four components in AND relationship, which are Client, Expected nterface, Existing interface, and Adapter. Among them, Adapter component is decomposed into Class adapter, and Object Adapter in OR relationship. Class adapter is realized by multiple inheritance, and object adapter is realized by

object composition. The above decomposition is illustrated in Figure 7. The subgoal C1: Module without data traces to the component A1: Client. Similarly, C2: Control module interface traces to A2: Expected interface; C3: Immediate data interface traces A3: Existing interface; and C4: Converter traces to A4: Adapter. With the tracing between the components of Implicit Invocation and Adapter design pattern, the traceability from Implicit Invocation to the Adapter can be established. Since Adapter makes Reusability NFR, helps Comprehensibility and Performance, and only hurts Modifiability as illustrated in Figure 5, the Adaptor Design Pattern is chosen for detailed design.

4. Observation The following observations are made: (1). In the definition of each design pattern, the

6/8 Proceedings of the Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Networks (SNPD/SAWN’05) 0-7695-2294-7/05 $20.00 © 2005 IEEE

Comprehensibility [KWIC]

Modifiability [KWIC]

+ + 1. Shared Data [KWIC] +

Performance [KWIC]

+

+ +

Reusability [KWIC]

++ + + 3. Implicit Invocation++ [KWIC] +

++ Modules with Masterdata [E] Shared slave [I:P] storage [I:D]

Modules without data [E] Control module with data [E]

2. Abstract Data Type [KWIC] Modules with data, procedures [E] Access by interface [I:D] Mediator

Dependent objects [E]

Triggered by event [I:P] Share data through interface [I:D] 4. Pipe & Filter [KWIC]

Filter process Pipeline [I:P] data [E] Output of current filter is input of next filter [I:D] One-to-many dependency [I] Support 1, 2, 3, 4

Master-slave [I:P] Observer

Subject object [E]

Strategy

A set of Multidirectional [I] Context object [E] objects [E] An object [E] A family of algorithms [E]

Interchangeable [I] Algorithm interface in abstract class [E]

Figure 6: KWIC system: behavioral design patterns consequences describe its benefits and liabilities [1]. This trade-offs information is shown in the SIG of KWIC system. (2). By the end of the process, we have a set of design pattern to be used in the design. (3). When people use the diagram, they can see clearly the relationships between software architectures and design patterns, as the relationships between NFRs and design patterns. (4). Just as UML is a visual aid for software engineering, so is SIG. We find the visualization promotes better understanding of the system. (5). We also note the NFR interaction complexity that could make the diagrams unreadable. So tool support will be very helpful.

5. Conclusion The paper provides a process to select design patterns. The process identifies a set of potentially applicable design patterns and makes applicability analysis for each of them.

In our approach, the software architectural design softgoal and any potentially applicable design pattern softgoals are decomposed into subgoals. By the mapping relationship between their subgoals, the traceability from the software architectural design to the design patterns can be established. With the consideration of the NFRs, its applicability is determined. By the observation on the case study, we note that tool support must be done to make the approach easy to handle. In summary, the paper introduces an approach to select a set of applicable design patterns to come up with detailed design. It provides a way to systematically reuse the existing catalogue of knowledge on design patterns. This approach is applied in the case study on KWIC system. We also further refined the notation of NFR approach [4].

7/8 Proceedings of the Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Networks (SNPD/SAWN’05) 0-7695-2294-7/05 $20.00 © 2005 IEEE

Implicit Invocation [KWIC] C1: Modules without data[E]

Triggered by event[I:P]

Control module Share data through with data[E] interface[I:D]

C2: Control C4: converter module interface C3: Immediate data interface

[6] L. Prechelt and W. F. Tichy. “A Controlled Experiment in Maintenance Comparing Design Patterns to Simpler Solutions”, IEEE Trans. Software Eng., vol. 27, no. 12, pp. 1134-1144, December 2001. [7] D. E. Perry and A. L. Wolf. “Foundation for the Study of Software Architecture”, ACM SIGSOFT Software Engineering Notes, Vol. 17, No. 4, pp. 40-52, Oct. 1992.

B: Adapter

A1:Client A4: Adapter[E] A2: Expected A3: Existing interface[E] interface[E] Class adapter

[5] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, Pattern-Oriented Software Architecture – A System of Patterns. Chichester, UK: John Wiley and Sons, 1996.

[8] A. H. Eden and R. Kazman. “Architecture, Design, Implementation”, Proc. 25th International Conf. Software Engineering (ICSE) , Portland, Oregon, USA, pp. 149-159, 2003.

Object adapter

Multiple inheritance

Object composition

Figure 7: From Implicit Invocation Software Architecture to Adapter Design Pattern

Acknowledgement Special thanks for the students worked for the KWIC project instructed by Dr. Lawrence Chung in the University of Texas at Dallas.

References [1] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns, Elements of Reusable Object-Orented Software, AddisonWesley, 1995. [2] Mary Shaw and David Garlan. Software Architecture, Perspectives On An Emerging Discipline, Prentice Hall, 1996. [3] Lawrence Chung, Brian A. Nixon, Eric Yu, and John Mylopoulos. Non-Functional Requirements In Software Engineering, Kluwer Academic Publisher, 2000. [4] L. Chung, K. Cooper and A. Yi, “Developing adaptable software architectures using design patterns: an NFR approach”, Computer Standards & Interfaces, Special issue: Adaptable software architecture, vol. 25, issue 3, pp. 253260, June 2003.

[9] Douglas Schmidt, Michael Stal, Hans Rohnert, and Frank Buschmann. PatternOriented Software Architecture, Patterns for Concurrent and Networked Objects, Wiley, 2000. [10] D. L. Parnas, “On the Criteria to be Used in Decomosing Systems into Modules”, Communications of the ACM, vol. 15, pp. 10531058, Dec. 1972. [11] L. Tahvildari and K. Kontogiannis, “A Methodology for Developing Transformations Using the Maintainability Soft-Goal Graph”, Proc. 9th Working Conf. on Reverse Engineering (WCRE’02), Richmond, Virginia, USA, pp. 1095-1350, 2002. [12] P. Loucopoulos and V. Karakostas, System Requirements Engineering, McGraw-Hill, 1995. [13] G. Kotonya and I. Sommerville, Requirements Engineering: Processes and Techniques, John Wiley & Sons, 1998. [14] A. M. Davis, Software Requirements: Objects, Functions and States, Prentice Hall PTR, 1993. [15] D. Gross and E. Yu, “From Non-Functional Requirements to Design through Patterns”, Requirement Engineering, Springer-Verlag. (2001) 6:18-36.

8/8 Proceedings of the Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Networks (SNPD/SAWN’05) 0-7695-2294-7/05 $20.00 © 2005 IEEE