Pattern Detection and Design Rationale Traceability

ReView by River Valley This Technologies article has been accepted for publication in a future issue of this journal, but has not been fully edited.

IET Software

Content may change prior to final publication in an issue of the journal. To cite the paper please use the doi provided on the Digital Library page.

Pattern Detection and Design Rationale Traceability: An Integrated Approach to Software Design Quality Loay Aladib1, Sai Peck Lee2, * 1,2 Department of Software Engineering Faculty of Computer Science and Information Technology University of Malaya, Kuala Lumpur, Malaysia Email: [email protected], * [email protected] Abstract: Design rationale is the synthesis of the structure that is consistent with the model of an artefact, decisions, alternative approaches and the reasoning behind it. Hence, bypassing it will result in poor quality systems engineering. Ambiguous representation of design rationale goals is just one of the many limitations that contributes to the intricacy of design patterns, thereby this research aims to introduce an approach to support the structuring, evaluation, and analysis of design patterns. We have proposed a method and implemented an associated tool with a mechanism that validates the class relationships and properties of design patterns comprehensively, resulting in a reliable pattern detection result. The preliminary results of the proposed research show that although detection and evaluation of a design pattern require some overhead using the approach, it does contribute to the confidence of the developers and gives affirmation that the design pattern implemented in the source code achieves its defined rationale goals based on the Gang of Four definition of design patterns through the reliable pattern detection output and straightforward evaluation result. The conclusion could be drawn that through the proposed approach, the preliminary result resolves the intricacy of design rationale traceability while achieving software quality is permissible. 1. Introduction The influence of design patterns in software design quality is becoming relevant in the area of software engineering [1-3]. Developers have opted to apply design patterns to solve recurring software design issues. However, prior to application of a certain design pattern, it is common among developers to consider only the design pattern that solves their current design problem, without considering and fully understanding why that design pattern is built, to solve a software issue. This compromises software design quality. Software architecture design is a crucial development activity. It begins with a single word ‘quality’ which reflects the importance of the software design. Object-oriented design patterns have been founded in the mid-1990s as templates of repeatable solutions to commonly occurring software design problems [4-6]. Design patterns have been categorized by authors into 23 patterns, labelled according to two criteria: 1) purpose depicts the motivation of the pattern which can be either creational, structural, or behavioural; 2) scope - determines whether the pattern is applied primarily to object or class level [5].

Numerous design pattern detection methods have been proposed [7-11]. However, they pay no attention to the design rationale. Detection of the presence of design pattern in a source code is not enough to prove that software design quality has been achieved though it represents the traceability of the design rationale nonetheless. The assurance whether it serves its purpose well is not guaranteed. Diverse pattern detection processes came into the picture in order to bridge the existing gap of misinterpretation of design pattern usage and to avoid the risk of wrong design pattern implementation. The intent of design pattern detection is not only limited to providing aid in the clear understanding of the software design, but also in detecting whether various non-functional software requirements such as understandability, maintainability, reusability, and traceability of the object-oriented programs are achieved [7, 12]. The work of Antony Tang et al. [13] emphasized design rationale goals to be the reason that motivates in structuring the design pattern and providing a context of the design. We consider it as the major influence in developing a design solution represented in the design pattern.

1

2018/08/28 14:55:02

IET Review Copy Only

2


IET Software


Design rationale is a comprehensive documentation of the reason behind decisions were made upon designing a system or artefacts. It is an explicit listing of decisions which were made throughout a design process that gives more useful information and details about the architecture design. It provides an extra insight to the designers to have a better decision-making process [14, 15]. Several research studies with reference to design rationale focus on two main concepts: 1) rationale traceability - the reason behind design decisions. It shows how the software design program satisfies the given requirements. Also, it proves why the specific design has been chosen over alternative options. Design decisions are created and justified through the software design process but they are often unrecorded [16]. Designers find it difficult to explain and justify the design or reconstruct the rationale when it's necessary [17]; 2) rationale representation - it is crucial to choose the rationale representation in order to ensure that the rationales we capture are actually what we desire, how should rationale be saved for later access, and how we can use it efficiently. This paper proposes an approach that does not only focus on detecting the presence of a design pattern but also in tracing its rationale, and provides an evaluation as well as determines whether the implementation of the detected pattern satisfies the design rationale goals or not. The outcome of the proposed approach highlights the importance of defining the pattern structure as accurate as possible to produce a well-founded pattern detection and evaluation result. Simultaneously, extraction of basic elements and all other important classes and properties of design pattern plays a crucial part both in pattern detection and design rationale tracing phase. We found design rationale goals as the most ambiguous component of the design pattern. Thus, we predefine and formulate a new design rationale decision tree model using a utility function to determine the optimal decision. However, in order to substantiate this step further, it is part of the future work to improve this process by making available the design rationale decision tree with minimal human intervention to avoid subjective results. The remainder of this paper is structured as follows. Section 2 discusses the research background in the area of design pattern detection and design rationale. Section 3 describes

the proposed approach methodology. Section 4 evaluates the methodology adopted in our study. Section 5 reveals the study limitations of the proposed approach. Section 6 draws the conclusion and plans our future work. 2. Related work Pattern detection alone will not be sufficient to achieve software design quality. Thus, we have come up with the idea of merging two different approaches (pattern detection and design rationale traceability) and we found this to be the most efficient and effective way of attaining our objective. 2.1 Pattern Detection Design patterns being intricate by nature, and the inconsistency of the developers’ commitment to providing proper design documentation, make design pattern detection a key issue for many research areas. According to Chihada et al. [18], design pattern detection by classification approach has been introduced to help solve the pattern detection problem, by not only identifying possible variant implementations but also by mapping the design pattern detection problem into a learning problem. The suggested pattern detector has been designed by learning from the extracted information of the design pattern instances. This approach was evaluated on open-source software to detect six different design patterns and the result has shown a better performance and reduced the overall execution time of the proposed approach. The study on ‘design pattern detection using similarity scoring’ [8] which aims in finding a solution to the issues of the existing methodologies in capturing versions of modified patterns, search space explosion is used for huge systems and compliance to novel patterns. Through the use of a similarity algorithm, it presents the capability of detecting patterns that can be deviated from the standard representation. This methodology exploits the use of unified modelling language diagrams and proposes an automated process to detect the actual instances of a pattern in a system, which contributes to the approach flexibility. This approach tackles the following difficulties in capturing the design pattern: a) magnitude of the study space for large software systems; b) continuously expanding the design pattern detection list limitations inspires the author of this 2

2018/08/28 14:55:02


3


IET Software


study to develop an algorithm flexible enough to cover even patterns that might not have been discovered to date. This study serves as our inspiration in coming up with a more flexible approach and leads us in developing the starting point of our approach which is the pattern structure definition part, to be first accomplished before pattern detection process. Most of the existing design pattern detection techniques focus on identifying as many false hits as possible. This is due to the vague nature of design patterns. A new method for the detection of design pattern has been presented by [19] based on the semantic graphs and the pattern signature to describe design patterns. The initial problem was to convert the problem of finding matches in the system graph to reduce the exploration space, based on a predesigned set of criteria. However, the behavioural signature of the patterns was evaluated in the final phase by three open-source systems that aimed to discard the identified false positives in the structural phase concerning improving the recall and precision metrics of the detection process. 2.2 Design Rationale Design rationale has been spreading amongst the development and research community in software engineering [20-22]. Researchers do not totally agree that there is a demand to enhance the design pattern detection process, representation, and reuse of the design rationale. Perry and Wolf [23] have stated that, when an architecture design develops, the system is progressively brittle due to the following issues: a) architectural erosion, and; b) architectural drift. The mentioned problems would possibly result in modelling design problems if the involved rationale is not identified over the time. Bosch [16] suggested that the decision of an architecture design is cross-cutting and

intertwining, thus it can be susceptible to improper interpretations without a superior representation of design rationale. However, whenever changes happen, there is the possibility that the software design could be infringed and the cost of the modification could be expensive. Design rationale is important in various ways. It helps in preserving design knowledge like design premise, restrictions and design decisions that are often not captured. It encapsulates design options in order to reveal why several designs have been refused. It assists software architects to grasp the intent of the design since design decisions are often twisted and traverse several issues. Without the presence of design rationale, it would be difficult to discover inconsistencies, expectations, and failures in a software design. Amendments done to a decision may result in a series of the cumulative effect on the interdependent portions of the system [24, 25]. We have used the work of Antony Tang et al. [13] in coming up with our own rationale traceability framework with the goal of linking back the design elements to their design rationale goals. Their approach of familiarizing a rationalebased architecture model that involves design rationale, objects, and their relations result in better understanding and reasoning by software architects on why a certain architecture design has been developed. This result is the answer to the objective of our proposed approach. Thus, this article gives a great impact on our design rationale traceability technique. 3. Proposed approach The overall process of our proposed approach is composed of seven steps as shown in Fig. 1.

3

2018/08/28 14:55:02


4


IET Software


Fig. 1. Process flow of proposed appraoch

3.1 Define Pattern Structure (S1) A design pattern is composed of several sections describing the design structure, participants, collaborations, and so forth. Several design patterns are expected to be present, especially in a huge program. Therefore, in order to refine the usefulness and adequacy of our approach, we choose one pattern for each category: singleton from the creational patterns, adapter from the structural patterns, and observer and template method from the behavioural patterns [5]. To define the design pattern structure, our technique offers two different options: 1) it can be either drawn manually and saved as eXtensible Markup Language (XML) file. It gives the user an option to add a class and define its properties as follows: modifier, access, base type, return type, and class attribute; 2) a predefined XML file of the pattern structure can be uploaded and generated accordingly. 3.2 Validate and Set Properties (S2) Subsequent to the definition of pattern structure is the validation process. Our technique allows the developers to have some degree of freedom in terms of modifying the pattern structure. However, it verifies if the following criteria are observed: 1) if the chosen pattern type matches the defined pattern structure, where the pattern types were defined and selected in S1; 2) if the pattern classes are correctly defined; 3) if the correct relationships between the pattern classes are specified; 4) if the

correct class properties such as access type, modifier type, base type, and return type have been set. Consequently, if all the above criteria are met, then the final result of the pattern rules will be ‘Satisfactory’ as shown in Fig. 2 otherwise, revisiting the pattern structure will be suggested. We have set unique validation pattern rules based on the class and relationship properties for each design pattern (see Table 1). The unique validation criteria are implemented and stored in the system in order to validate each pattern’s rules and further set its properties based on the graphical representation of the design pattern [5]. Each pattern rule has its own class and relationship properties method to be validated into the system to ensure its correctness. A sample of validating observer pattern pseudo-code is given as follows: 1. 2. 3. 4. 5. 6. 7. 8.

9.

begin procedure validate observer pattern foreach class subject in unique list do if validate (class modifier subject = abstract) then if validate (class subject ∉ base type n and class subject ∈ return type observer) then // {n = class} if validate (pattern type = observer) then foreach class observer in unique list do if validate (class modifier observer = abstract) then if validate (class observer ∉ base type n and class observer ∉ return type n) then // {n = class} foreach class concrete subject in unique list do

4

2018/08/28 14:55:02


5


IET Software


10. if validate (class concrete subject ∈ base type subject and class concrete subject ∉ return type n) then 11. foreach class concrete observer in unique list do 12. if validate (class concrete observer ∈ base type observer and class concrete observer ∈ return type concrete subject) then 13. print ‘result is satisfactory’ 14. else 15. print ‘result is unsatisfactory’ 16. end procedure

Set properties process will start once the developer adds each of the four validated patterns to the target program. This can be done through answering ‘Yes’ to the question ‘do you want to add this pattern to the target program’ as shown in Fig. 2 to ensure that the validated pattern properties are set correctly into a list called ‘Validate’ in the system. It must contain all the validated pattern properties in order to enable the target program button and proceed to the next step. In addition, it will be used as part of the mapping step with S5.

Fig. 2. Validate and set properties Table 1 Design pattern class definition Pattern Name Singleton Adapter

Observer

Template Method

Class Name Singleton Client Target Adapter Adaptee Subject Observer Concrete Subject Concrete Observer Abstract Class Concrete Class

Access Public Default Public Public Public Public Public Default Default Public Default

Class and Relationship Properties Modifier Base Type Return Type Sealed None Singleton None None Target Abstract None None None Target Adaptee None None None Abstract None Observer Abstract None None None Subject None None Observer Concrete Subject Abstract None None Abstract Abstract Class None

Label Optional Optional Optional Adaptee Optional Observer Optional Optional Subject Optional Optional

5

2018/08/28 14:55:02


6


IET Software


3.3 Upload Target Program (S3) After all four detectable patterns are validated and their properties set, uploading of target program will be enabled. A preview of the source code is to be made available upon uploading. 3.4 Extract Basic Elements (S4) Basic elements are extracted using NRefactory tool [26] and categorized in the form of text representation as follows: parent, role, type, and data. These categories are listed and made available to the developer to ensure that the information of the basic elements is extracted correctly. 3.5 Pattern Detection Process (S5) After the target program has been uploaded and elements have been extracted, pattern detection process will then begin. Elements extracted and parsed are stored in the main array. Elements in the main array are validated against the predefined pattern properties using the Gang of Four (GoF) pattern representation as a reference [5]. Design pattern structure is a graphical representation where both class diagrams and interaction diagrams are used for this purpose. However, each of the four design patterns has its unique class diagram rules which are derived from the structure section of the design pattern. The class rules are used as a basic guideline to detect the pattern from the source code. Therefore, our system detects the pattern instances by matching the direction of the relationships between the extracted elements and the rules of each pattern’s properties. The system searches all combinations of the elements in the main array that agree with the predefined pattern properties. Table 2 shows pattern detection class rules. Pattern detection codes and conditions are uniquely programmed for each of the four design patterns to detect its presence in a source code. A sample of observer pattern detection rules pseudocode is given as follows: 1. 2. 3. 4. 5. 6. 7. 8.

begin procedure check observer pattern declare new observer pattern list declare new observer list declare new defined observer list declare new patterns list foreach class subject in unique list do if check (class modifier subject = abstract) then foreach class observer in unique list do

9. if check ((class name observer != name subject and class modifier observer = abstract) or entity type = interface)) then 10. foreach body class in fields subject do 11. if check (body class type argument identifier = name observer or return type body = name observer then 12. foreach class concrete observer in unique list do 13. if check (base type concrete observer = name observer) then 14. foreach class concrete observer in unique list do 15. if check (base type concrete observer = name subject) then 16. foreach body2 class in methods concrete observer do 17. foreach body3 class in methods observer do 18. if check (body2 name = body3 name) then 19. foreach class client in unique list do 20. foreach body5 class in methods client do 21. foreach block statement class in block statement body5 do 22. if check (type identifier block statement = name concrete subject) then 23. foreach block statement1 class in block statement body5 do 24. foreach body6 class in methods subject do 25. if check (name body6 = block statement1 variable name then 26. if check (observer list = empty) then 27. initialize new observer list 28. add subject class to observer list 29. add observer class to observer list 30. add concrete observer class to observer list 31. add concrete subject class to observer ist 32. add client class to observer list 33. add observer list to observer pattern list 34. else 35. j to 0 36. foreach class item in observer list do 37. if check (j = observer list count -1 and (item name = name subject and item name != name observer and item name != name concrete observer and item name != name concrete subject and item name != name client)) then 38. initialize new observer list 39. add subject class to observer list 40. add observer class to observer list 41. add concrete observer class to observer list 42. add concrete subject class to observer list 43. add client class to observer list 44. add observer list to observer pattern list 6

2018/08/28 14:55:02


7


IET Software


45. j = j + 1 46. foreach body7 class in fields client do 47. if check (identifier body7 = name concrete subject) then 48. foreach block atatement1 class in block statement body5 do 49. foreach body6 class in methods subject do 50. if check (name body6 = block statement1 variable name) then 51. if check (observer list = empty) then 52. initialize new observer list 53. add subject class to observer list 54. add observer class to observer list 55. add concrete observer class to observer list 56. add concrete subject class to observer list 57. add client class to observer list 58. add observer list to observer pattern list 59. else 60. j to 0 61. foreach class item in observer list do 62. if check (j = observer list count -1 and (item name != name subject and item name != name observer and item name != name concrete observer and item name != name concrete subject and item name != name client)) then 63. initialize new observer list 64. add subject class to observer list 65. add observer class to observer list 66. add concrete observer class to observer list

67. add concrete subject class to observer list 68. add client class to observer list 69. add observer list to observer pattern list 70. j = j + 1 71. add observer pattern list to defined observer list 72. add defined observer list to patterns list 73. end procedure After all the design pattern instances are detected from source code and set into their corresponding private lists, the content of each private list is stored into the ‘patterns list’. The ‘Validate’ list that has been set in S2 is mapped to this ‘patterns list’. Each pattern instance in the ‘patterns list’ must be mapped and matched with its corresponding structure in the ‘Validate’ list. The mapping step is important to ensure that the detected pattern instances from the source code are implemented correctly and matched with its corresponding validated structure in the ‘Validate’ list. The system will consider only the correct mapping of each design pattern instance. Once the mapping process is done, the pattern detection results window will be displayed. Pattern detection’s results window containing the list of pattern instance(s). detected along with the identified number of classes, constructors, fields, and methods are made available as shown in Fig. 3.

Table 2 Pattern detection class rules Pattern Name

✓

Adapter

✓

✓

✓

✓

✓

Singleton Template Method

Adaptee

Optional

Adapter

✓

Target

✓

Child Class 2

Client

Observer

Child Class 1

Interface

Child Class

Singleton

Mandatory Classes Abstract Class

✓

Optional

Optional

7

2018/08/28 14:55:02


8


IET Software


Fig. 3. Pattern detectable results screen

3.6 Rationale Traceability Framework and DRDT Model (S6) To trace the rationale of the detected design pattern, we employ the Design Rationale Decision Tree (DRDT) model. We conceptualize DRDT to define the rationale of structuring the design pattern that supports traceability to help in achieving software design quality. The DRDT concept focuses on: 1) identifying the Design Rationale Goals (DRGs) as it is known to lead to the creation of the design pattern’s basic elements; 2) linking of Design Elements (DEs) back to their main DRGs and to identify the positive properties or Non-Functional Requirements (NFRs) that certain DEs possess. The DRDT is the main output of Rationale Traceability Framework (RTF), a concept that we have developed to link the DEs back to their DRGs and evaluate design elements’ positive properties or NFRs as shown in Fig. 4 as follows: 1) DEs:

refer to any concepts, operations, entities, methods, and models of the design patterns; 2) DRGs: refer to the reason that motivates in structuring a design pattern and providing a context of the design. The researcher considers it as the major influence in developing a design solution represented in the design pattern text; 3) NFRs: refer to the positive properties or quality attributes that the DEs possess. Furthermore, RTF can analyze, organize, and refine NFRs in which it provides a reasoning support and guideline during the design of the system when applying the pattern. In addition, NFRs such as maintainability, stability, traceability, flexibility, and reusability are prevalent in descriptions of the design patterns. They play a very important role in understanding the problem, the trade-offs, and the proposed design solutions of the design patterns [27].

8

2018/08/28 14:55:02


9


IET Software


Fig. 4. Rationale Traceability Framework (RTF)

DRGs representation using the DRDT model is as shown in Fig. 5. In this representation, we use the basic elements extracted in S4. Elements are identified from the design pattern text located in sections namely implementation, applicability, collaboration, intent, participant, consequences, etc.. [5]. After defining the significant DEs, our approach then maps the DEs that are related to each other and name them as Main_DEs. Then, the design pattern detection is incorporated in the DRDT and finalized as the main concept. The process moves to the next rationale level which is the Design Rationale Decision (DRD) part. DRD is a DRG question to evaluate whether the Design Pattern’s Main Concept (DP_Main_Concept) satisfies a DRG or not. In this level, DRD will be represented using a decision object ‘Diamond’, where the recommended DP_Main_Concept will be evaluated to determine whether it satisfies a DRG or not. If the answer is ‘Yes’, the justification will be given on ‘how/why it satisfies the DRG’, unless there are such instances where a certain DP_Main_Concept is able to satisfy the DRG only when a suggested alternative justification is applied. However, if the answer is ‘No’, the justification will be given why it does not satisfy the DRG. This representation of the evaluation decision step varies based on the type of design pattern to be represented. The more complicated the design pattern, the more complex will be our DRDT. In addition, to further guide the developer

in identifying the positive properties/characteristics of the design pattern detected such as singleton, adapter, observer, or template method, the DP_Main_Concept will be linked to its corresponding NFRs or quality attributes. Basically, DRDT levels of Rationale ‘R’ have six levels as follows: • • • •

•

•

R0: the root of the process - the main array includes the basic DEs extracted from the source code as input. R1: in this level, each of the necessary sections laid down from where all the important DEs were extracted. R2: DEs dissection, extraction of the DEs from the main array list. R3: mapping the DEs that are related to each other in terms of meaning, function, intent, and goal at this level. The researcher used parts of speech tagger tool called ‘LTCHUNK’ to identify the noun and verb phrases from the set of basic DEs extracted in S4 [28]. R4: DRD, this level identifies whether DRG is satisfied or not, it is represented using a decision object ‘Diamond’ inside which is a DRG question developed using a commandline tool, designed to evaluate whether the concept satisfies a DRG or not. R5: DRGs identification, which is often extracted from the motivation section of the design pattern [5].

9

2018/08/28 14:55:02


10


IET Software


Fig. 5. The general structure of DRDT levels of rationale

10

2018/08/28 14:55:02


11


IET Software


DRDT in its current form, does explicitly represent NFRs and the roles they play in DRDT. It ensures a clear understanding of the DRGs and how they explicitly satisfy certain NFRs. For every DRG, a suitable ‘One to Many’ NFRs defined to identify whether DP_Main_Concept (MC) achieves the Quality Attributes (QA) or not, through the following equations.

•

•

𝐼𝑓 𝑀𝐶 𝒔 𝐷𝑅𝐺 ≠ 𝐴𝑙𝑡 𝑡ℎ𝑒𝑛 𝑄𝐴 = 𝑎 𝐼𝑓 𝑀𝐶 𝒔 𝐷𝑅𝐺 = 𝐴𝑙𝑡 𝑡ℎ𝑒𝑛 𝑄𝐴 = 𝑚

Where, MC: DP_Main_Concept DRG: Design Rationale Goal Alt: alternative QA: Quality Attribute (≠): not through (=): through (s): satisfy (m): miss (a): achieve

•

▪

As an example, the usage of the NFRs can be seen in Fig. 5 as follows: •

•

RTF_NFR1: maintainability: it means an object-oriented feature which applies more to the stability model because the objects will need the least amount of maintenance [29]. RTF_NFR3: traceability: it means the ability to capture, define, and follow the traces left by requirements on other elements of the software development environment and the trace left by those elements on requirements [29].

A sample of the DRDT model of observer design pattern is explained in Fig. 6. DRDT levels of Rationale ‘R’ of observer design pattern has six levels as follows: • •

R0: starting from the observer design pattern text as input, observer design pattern text is described in the book of GoF [5]. R1: each of the necessary sections of the observer pattern is laid down such as implementation, applicability, collaboration, and consequences. However, the pattern reader must understand each section to extract all the significant DEs in the next level.

R2: DEs are extracted and listed down such as push model, pull model, observer, subject, update, notify, object, change, set state, get state, concrete subject, concrete observer, dependents, and notify. R3: the extracted DEs that are related to each other, are then mapped in terms of meaning, function, intent, and goal into two main DEs as follows: Main_DE1: subject, and Main_DE2: observer. These two main DEs are leading to the DP_Main_Concepts as follows: DP_Main_Concept1: pull model, and DP_Main_Concept2: push model. R4: the pull model and push model as the main concepts of observer design pattern have two decision object diamonds for each concept that are represented as DRD questions as follows: Pull model

1) Is loose coupling achieved? If the answer is ‘Yes’ because an observable interface offers a specific accessor method that gives the observer more flexibility to decide for itself what right information to query, without relying on the subject to send the correct information. If the answer is ‘No’ because the observer is dependent on the subject in pulling data. 2) Is consistency between related objects maintained? If the answer is ‘Yes’ because template method is applied in the abstract subject classes. If the answer is ‘No’ because self-consistency rule is easy to violate unintentionally. ▪

Push model

1) Is loose coupling achieved? If the answer is ‘Yes’ because the subject does not need to know about its observer. If the answer is ‘No’ because the class-specific get method is invoked on the subject. 2) Is consistency between related objects maintained? If the answer is ‘Yes’ because the template method is applied in the abstract subject classes. If the answer is ‘No’ because self-consistency rule is easy to violate unintentionally.

11

2018/08/28 14:55:02


12


IET Software


These DRD questions are required to have both Yes/No answer to evaluate whether the pull model or push model satisfies the DRGs in the next level or not. These DRD questions lead to the DRGs which need to be extracted in the next level. R5: in this level, the desired DRGs are often identified and extracted from the motivation section [5] of the observer pattern as follows: 1) DRG1: maintain consistency between two related objects. 2) DRG2: achieve loose coupling. Consequently, as shown in Fig. 6 not all the DP_Main_Concepts (push model and pull model) satisfy their DRGs, wherein a link between the DP_Main_Concept and its DRGs are represented as Roles and Relations (R&Rel) as follows: 1) R&Rel1/DRG1: pull model / maintain consistency between two related objects.

2) R&Rel1/DRG2: pull model / achieve loose coupling. 3) R&Rel2/DRG1: push model / maintain consistency between two related objects. 4) R&Rel2/DRG2: push model / achieve loose coupling. The R&Rel analysis result will be used in the result evaluation (S7) which is the main output of the graphical representation of the observer design pattern. After that, the DP_Main_Concepts of observer design pattern will be linked to their corresponding NFRs [29] as follows: 1) R&Rel1/DRG1: misses RTF_NFR1: stability. 2) R&Rel2/DRG1: misses RTF_NFR1: stability. 3) R&Rel1/DRG2: misses RTF_NFR2: reusability. 4) R&Rel2/DRG2: achieves RTF_NFR2: reusability.

12

2018/08/28 14:55:02


13


IET Software


Fig. 6. Observer pattern structure of DRDT levels of rationale

13

2018/08/28 14:55:02


14


IET Software


3.7 Result Evaluation (S7) For each design pattern detected, there is an equivalent DRG tracing process whose output is the Graphical Representation (GR). GR is based mainly on the R&Rel analysis result. The graph expected to show the percentage of DRGs achieved through the implementation of the design pattern. We derive the value of the graph using the R&Rel from the pattern detection process.

Where, 𝑒𝑎 = 𝑒𝑞𝑢𝑖𝑣𝑎𝑙𝑒𝑛𝑡 𝑎𝑛𝑠𝑤𝑒𝑟 𝑛 𝐷𝑅𝐺 = 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝐷𝑅𝐺 𝑛𝑞 = 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑞𝑢𝑒𝑠𝑡𝑖𝑜𝑛𝑠

A sample calculation of the observer pattern DRDT is used to derive the percentage of the DRGs

Based on our experimental results of the proposed approach, we provide complete data and information gained by exploiting every module of our process for each of the four design patterns represented in our system (See Table 3). Table 3 Experimental results

Number of Data / Information Hits,

Classes Constructors Fields Methods DEs Main_DEs DP_Main_Concepts DRD Justification Alternative Justification DRGs DRD Questions NFRs

Template Method

(1)

0.5 + 1 1.5 = = 0.75% 1+1 2

Observer

𝑒𝑎 + 𝑛 𝐷𝑅𝐺 𝑛𝑞 + 𝑛 𝐷𝑅𝐺

=

𝑒𝑎 + 𝑛 𝐷𝑅𝐺 𝑛𝑞 + 𝑛 𝐷𝑅𝐺

Adapter

𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑎𝑔𝑒 =

𝑃𝑒𝑟𝑐𝑒𝑛𝑡𝑎𝑔𝑒 𝑜𝑓 𝑅&𝑅𝑒𝑙1/𝐷𝑅𝐺1 =

Singleton

We have considered the result as the x-axis value and the following information to find out the percentage of DRG achieved: a) number of questions + number of DRGs from the DRDT model; b) number of ‘Yes’ answers to the question; c) number of ‘No’ answers to the question with the alternative provided; d) number of ‘No’ answers to the question without the available alternative. We have coined a simple and straightforward computation logic as follows: 1) if the answer to the DRD question of a particular DP_Main_Concept is ‘Yes’, the value of the equivalent answer (ea) will be 1.0; 2) if the answer to the DRD question of a particular DP_Main_Concept is ‘No’, ‘given that the corresponding alternative justification is provided’, the value of the equivalent answer (ea) will be 0.5; 3) if the answer to any of the DRD questions of a particular DP_Main_Concept is ‘No’ without any alternative found, the value of the equivalent answer (ea) will be 0.0; in this case, the developer is suggested to re-evaluate the design pattern implementation. Moreover, a percentage lower than 70% as the passing value means that the developer needs to re-evaluate the design pattern implementation. GR is used to represent the percentage of the DRGs achieved. Formula (1) used to calculate the percentage value.

achieved. The percentage values of the R&Rel1/DRG1 (pull model / maintain consistency between two related objects) of the observer pattern DRDT model is explained as follows: the value of the equivalent answer (ea) of the R&Rel1/DRG1 of the observer design pattern DRDT model is equal to 0.5 because there is a corresponding alternative justification provided. The number of DRGs for this R&Rel is equal to 1, because there is only one DRG provided. The number of questions (nq) for this R&Rel is equal to 1, because there is only one question provided. Therefore, we calculated the percentage of R&Rel1/DRG1 achieved for the observer design pattern as follows:

2 2 2 2 10 2 1 3 6

4 2 6 6 18 3 2 2 3

5 3 5 6 14 2 2 4 3

4 0 2 10 12 2 1 2 4

0

1

2

0

3 3 3

2 2 2

2 2 2

2 2 2

14

2018/08/28 14:55:02


15


IET Software


4. Evaluation To evaluate the accuracy of the proposed approach, we interpret the results by counting how many correct numbers of the detected pattern instances (positive instances). Besides, negative instances are the actual pattern instances that are not detected by the methodology in [30]. In fact, the sum of the number of positive and negative instances is equal to the total number of actual detected pattern instances in the system.

Table 4 Pattern detection results JHotDraw 5.1

Design Pattern Detection Tools

DPD Tool 4.5

2 2 2 3 1 1 1

P-Mart

1 3

Web of Patterns 1.4.3 DPD-DRDT 1.0

Template Method

Singleton

Observer

On further analysis, we identified in the case of DPD-DRDT 1.0, there was no actual pattern instances that were not detected (negative instances) by the used system. However, for DPD tool 4.5, there were both positive and negative numbers of instances. This is one of the downsides of DPD tool 4.5 because there were actual pattern instances not detected (negative instances), while on the contrary, DPD-DRDT 1.0 displays only the positive instances. The rationale behind DPDDRDT 1.0 increases the accuracy in detecting the positive number of instances is mainly because, 1) unique data structure and more variations of the pattern rules were built into DPD-DRDT 1.0 system; 2) the attempt for detecting the patterns from the source code is completely focused on GoF

Based on the DRG tracing result of the detectable patterns, DPD-DRDT 1.0 shows an accurate evaluation with the rate greater than 70% of the DRGs achieved. The rationale behind the traceability result is mainly because 1) the usage of a simple and straightforward formula that calculates the percentage value of each DRG achieved of a particular design pattern detected from the source code; 2) the usage of the DRDT method that gives a better understanding of the design pattern structure and links the design elements back to their DRGs; 3) the usage of the accuracy rate of DRG tracing result that gives the developers a supportive guideline to understand and analyze the design justification, leading to the design pattern and suggests to them to re-evaluate the implementation of the design pattern in which the percentage value is lower than 70% of the DRG achieved. Table 4 shows the results of the JHotDraw 5.1 open-source pattern detection tool.

Adapter

In order to show that our developed tool named Design Pattern Detection-Design Rationale Decision Tree (DPD-DRDT 1.0) is able to detect the pattern instances, we focused on few GoF design patterns namely singleton, adapter, observer, and template method. DPD-DRDT 1.0 was applied in one of the widely adopted opensource software named JHotDraw 5.1, which is one of the tools that belongs to the design pattern detection tools benchmark platform. Various pattern detection tools such as DPD Tool 4.5, PMart, and Web of Patterns 1.4.3 have been applied for evaluation of the existence of the four design patterns [31]. We compared the result of the DPDDRDT 1.0 tool with the other pattern detection tools. The result showed that only DPD-DRDT 1.0 and DPD tool 4.5 support all four of the nominated design patterns, wherein comparison, the other tools such as P-Mart, and Web of Patterns 1.4.3 could not. This is evident from the result summarized in Table 4 that DPD-DRDT 1.0 produced a lot more design pattern instances (positive instances) compared to DPD Tool 4.5, PMart, and Web of Patterns 1.4.3.

design patterns [5]. Furthermore, the flexibility of DPD-DRDT 1.0 is giving the developer full control in defining and validating the pattern structure in terms of the rules as additional benefits for our pattern detection technique. This feature leads to a more efficient way to deal with large and scalable projects concerning the goals that we discussed in Section 2.

2

1 1 4

5

2

3

Agenda: N M N positive instances / M negative instances No instance found for design pattern Our pattern detection tool

15

2018/08/28 14:55:02


16


IET Software


5. Limitations Our technique is not fully applicable to other patterns beyond the four ones presented in this paper. Unfortunately, this was not possible during the period of this research. Nonetheless, applying a new pattern, in fact, is a critical challenge because it is not easy to fully understand the structure of patterns without dealing with them in detail at the coding level. Having an opportunity or experience to develop such patterns support into quite a largescale software is a best practice for us. Besides, it requires time, cost, and effort to come up with the unique constraints/rules of patterns especially for those which already have common characteristics such as state/strategy. The more complex the pattern is, the more difficult it is to apply. Such difficulties we faced in applying our proposed approach to the four patterns are: 1) role types are often restricted to the classes in the pattern such as abstract classes, concrete classes, or interfaces. Such restriction allows a pattern to define its interfaces and implementations easily for changes to be made. For instance, the class target is an abstract or an interface, whereas concrete classes are adapter and adaptee. This provides an interface from the class target to the client, whose implementation is presented by its child adapter. In the adapter pattern, the class adapter does not provide the implementation of the request method, instead, it delegates to the specific request method in adaptee class. Thus, concrete classes should be adapter and adaptee. However, this case can be more complex in the system source code; 2) different pattern variations are implemented in various ways when the pattern is applied in a system. For instance, the singleton pattern has different ways of implementation such as a fully lazily-loaded, simple, and highly performance version in which it shares common characteristics such as a singleton constructor is private and does not have a parameter, a static variable which holds a reference to the single created instance (if any), a public static means getting the reference to the single created instance (creating one if necessary). This is the reason why some pattern variations are detected by some approaches but missed by others. Besides, one of the drawbacks of our DRG tracing is that the system does not automatically answer all the questions of the DRDT model. We documented all answers to the questions manually

in our system with high accuracy through references to design pattern books [5]. Thus, it traces back all the design justifications of the detected pattern. It gives more information and details about the design and provides an extra insight to the developers to have a better decisionmaking process while developing systems. 6. Conclusions and future work We have outlined a set of concepts intended to support pattern detection and design rationale traceability. Our approach goes beyond the common pattern detection technique. It elaborates more on tracing the DRGs, identifying if the presence of design pattern achieves the design rationale, making a way to further evaluate design pattern implementation, hence simultaneously, gives an assurance that does not compromise the software design quality. Some of the major contributions of this research are as follows: 1) a mechanism that validates the class relationships and properties comprehensively resulting in a reliable pattern detection result; 2) a working tool that paves the way to a relatively easy traceability of the design rationale, resolving the open issues of design rationale misconception; 3) a simple and straightforward representation of the evaluation and decision result to determine whether a DRG is achieved or the design pattern implementation needs to be re-evaluated. At this juncture, we have produced a prototype system named DPD-DRDT 1.0 to support our research objectives. Along with these achievements, we have also developed a DRDT model of the design patterns named singleton, adapter, observer, and template method, and conceptualized our own unique rationale traceability framework to support our DRG tracing concept. Items that we plan to focus on in the immediate future are: 1) to cater to other design patterns; 2) to automate the design pattern definition phase; 3) to integrate our software tool with other developers’ systems and provide them with enough information about the classes that are about to change, by evidently identifying the basic elements within the classes being implemented to maintain the integrity of the related NFRs. Therefore, the developer is equipped to make effective decisions regarding the proposed change and its overall impact on the

16

2018/08/28 14:55:02


17


IET Software


system; 4) to have an automated modelling of the DRDT model. In conclusion, we believe that we have demonstrated a high-level method of tracing the design rationale. Likewise, the concept that we implemented in our design pattern detection technique is unique and helpful in achieving software design quality. 7. Acknowledgement This work has been developed within the framework of the research project with reference ER026-2013A, supported by the Ministry of Higher Education, Malaysia. We would like to thank our colleague Mahmoud Abdulber Alfakhoury who provided expertise that greatly assisted our research tool. 8. References [1] Hsueh, N.-L., Chu, P.-H., and Chu, W.: ‘A quantitative approach for evaluating the quality of design patterns’, Journal of Systems and Software, 2008, 81, (8), pp. 1430-1439 [2] Langsari, K., Rochimah, S., and Akbar, R.J.: ‘Measuring Performance Efficiency of Application applying Design Patterns and Refactoring Method’, IPTEK Journal of Proceedings Series, 2018, (1), pp. 149-155 [3] Ampatzoglou, A., Frantzeskou, G., and Stamelos, I.: ‘A methodology to assess the impact of design patterns on software quality’, Information and Software Technology, 2012, 54, (4), pp. 331-346 [4] Albin, S.T.: ‘The art of software architecture: design methods and techniques’ (John Wiley & Sons, 2003. 2003) [5] Gamma, E., Helm, R., Johnson, R., et al.: ‘Design patterns: Elements of reusable objectoriented software’, Reading: Addison-Wesley, 1995, 49, (120), pp. 11 [6] van Vliet, H., and Tang, A.: ‘Decision making in software architecture’, Journal of Systems and Software, 2016, 117, pp. 638-644 [7] Uchiyama, S., Kubo, A., Washizaki, H., et al.: ‘Detecting design patterns in object-oriented program source code by using metrics and machine learning’, Journal of Software Engineering and Applications, 2014, 7, (12), pp. 983 [8] Tsantalis, N., Chatzigeorgiou, A., Stephanides, G., et al.: ‘Design pattern detection using similarity

scoring’, Software Engineering, IEEE Transactions on, 2006, 32, (11), pp. 896-909 [9] Shi, N., and Olsson, R.A.: ‘Reverse engineering of design patterns from java source code’. Proc. 21st IEEE/ACM Int. Conf. Automated Software Engineering (ASE'06), Davis, California, USA, September 2006, pp. 123-134 [10] Hayashi, S., Katada, J., Sakamoto, R., et al.: ‘Design pattern detection by using meta patterns’, IEICE TRANSACTIONS on Information and Systems, 2008, 91, (4), pp. 933-944 [11] Zanoni, M., Fontana, F.A., and Stella, F.: ‘On applying machine learning techniques for design pattern detection’, Journal of Systems and Software, 2015, 103, pp. 102-117 [12] Ferenc, R., Beszedes, A., Fulop, L., et al.: ‘Design pattern mining enhanced by machine learning’. Proc. 21st IEEE Int. Conf. Software Maintenance (ICSM'05), September 2005, Los Alamitos, California, USA, pp. 295-304 [13] Tang, A., Jin, Y., and Han, J.: ‘A rationalebased architecture model for design traceability and reasoning’, Journal of Systems and Software, 2007, 80, (6), pp. 918-934 [14] Jarczyk, A.P., Löffler, P., and Shipman III, F.M.: ‘Design rationale for software engineering: a survey’. Proc. Int. Conf. System Sciences, January 1992, Kauai, HI, USA, pp. 577-586 [15] Burge, J., and Brown, D.C.: ‘Reasoning with design rationale’: ‘Artificial Intelligence in Design’00’ (Springer, 2000), pp. 611-629 [16] Bosch, J.: ‘Software architecture: The next step’. Proc. European Workshop on Software Architecture, May 2004, Berlin, pp. 194-199 [17] Moran, T.P., and Carroll, J.M.: ‘Design rationale: Concepts, techniques, and use’ (L. Erlbaum Associates Inc., 1996. 1996) [18] Chihada, A., Jalili, S., Hasheminejad, S.M.H., et al.: ‘Source code and design conformance, design pattern detection from source code by classification approach’, Applied Soft Computing, 2015, 26, pp. 357-367 [19] Mayvan, B.B., and Rasoolzadegan, A.: ‘Design pattern detection based on the graph theory’, Knowledge-Based Systems, 2017, 120, pp. 211-225 [20] Kurtanović, Z., and Maalej, W.: ‘On user rationale in software engineering’, Requirements Engineering, 2018, pp. 1-23 [21] Dutoit, A.H., McCall, R., Mistrík, I., et al.: ‘Rationale management in software engineering’ (Springer Science & Business Media, 2007. 2007) 17

2018/08/28 14:55:02


18


IET Software


[22] Burge, J.E., Carroll, J.M., McCall, R., et al.: ‘Rationale-based software engineering’ (Springer, 2008. 2008) [23] Perry, D.E., and Wolf, A.L.: ‘Foundations for the study of software architecture’, ACM SIGSOFT Software Engineering Notes, 1992, 17, (4), pp. 40-52 [24] Tang, A., Aleti, A., Burge, J., et al.: ‘What makes software design effective?’, Design Studies, 2010, 31, (6), pp. 614-640 [25] Wang, W., and Burge, J.E.: ‘Using rationale to support pattern-based architectural design’. Proc. Workshop on Sharing and Reusing Architectural Knowledge (ICSE 2010), May 2010, Cape Town, South Africa, pp. 1-8 [26] 'NRefactory', http://wiki.sharpdevelop.net/NRefactory.ashx, accessed 17 April 2015 [27] Veleda, R., and Cysneiros, L.M.: ‘Towards a Tool to Help Exploring Existing Non-Functional

Requirements Solution Patterns’. Proc. 25th Int. Conf. Requirements Engineering Workshops (REW), September 2017, Lisbon, Portugal, pp. 232-239 [28] 'The Edinburgh Language Technology Group (LTG)', http://www.ltg.ed.ac.uk/index.html, accessed 12 September 2016 [29] Chung, L., Nixon, B.A., Yu, E., et al.: ‘Nonfunctional requirements in software engineering’ (Springer Science & Business Media, 2012. 2012) [30] Vokac, M.: ‘Defect frequency and design patterns: An empirical study of industrial code’, IEEE Transactions on Software Engineering, 2004, 30, (12), pp. 904-917 [31] Fontana, F.A., and Zanoni, M.: ‘A tool for design pattern detection and software architecture reconstruction’, Information sciences, 2011, 181, (7), pp. 1306-1324

18

2018/08/28 14:55:02


19

Pattern Detection and Design Rationale Traceability

Pattern Detection and Design Rationale Traceability

Suggest Documents

Supporting Requirements Traceability with Rationale

Automatic Design Pattern Detection

Feature Point Detection and Curve Approximation ... - Design Rationale

Feature Point Detection and Curve Approximation ... - Design Rationale

Download PDF - Rationale Design

On Agent Design Rationale

On Agent Design Rationale

Download PDF - Rationale Design

Design Rationale: The Rationale and the Barriers - Research

Rationale and design of XAMOS ... - CiteSeerXwww.researchgate.net › publication › fulltext › Rationale-

Meta-modeling Design Patterns: application to pattern detection and ...

SPQR: Formalized Design Pattern Detection and ... - Semantic Scholar

Updated Design Rationale, Learning Goals, and Hypothesized ...

Rationale, design and population baseline ... - Springer Link

Rationale and design of the PRognostic

Creativity and Rationale in Software Design

The EPIC Project: Rationale and Study Design

Rationale and design for programming implantable cardioverter ...

Rationale and design of the Chinese Atrial

Hypotheses, rationale, design, and methods for

23_TERA2020 Rationale, Objectives and Design Algorithm - NEWAC

rationale and design of the cAreFul study

Hypotheses, rationale, design, and methods for

Rationale, Design, and Demographic Characteristics ...