European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens,

Greece

A PROCESS MODEL OF CHANGE IMPACT ANALYSIS FOR WEB SYSTEMS USING DESIGN KNOWLEDGE
Zafar Mehboob, Faculty of Engineering and IT, University of Technology Sydney, NSW, Australia. zafar@it.uts.edu.au Didar Zowghi, Faculty of Engineering and IT, University of Technology Sydney, NSW, Australia. Didar.Zowghi@uts.edu.au David Lowe, Faculty of Engineering and IT, University of Technology Sydney, NSW, Australia. David.Lowe@uts.edu.au

Abstract
Change impact analysis (CIA) approaches have been developed to identify the consequences of making changes to system artifacts and to support decision making with regards to those changes. There is a growing body of research on CIA approaches that specifically addresses changes and their impacts on architecture design. However, there is little research focus on approaches that particularly support the identification of impacts on architecture design resulting from business process changes i.e. early identification of change impacts in Web systems. In this paper we propose a process model of CIA that employs design knowledge to support early identification of change impacts. This process model is described in three steps including analysing changes, tracing potential change impacts and implementing changes on architecture. We also illustrate the process model through a case study. Keywords: Change Impact Analysis, Business processes, Architecture design, Web systems.

INTRODUCTION

CIA is a crucial part of change management process in developing software systems. Bohner and Arnold (Bohner and Arnold, 1996) define CIA as identifying the potential consequences of a change, or estimating what needs to be modified to accomplish a change. Much of the research about CIA is focused on code level and for software maintenance, although CIA undoubtedly plays an important role in the entire software development life cycle. Different CIA methods have been developed specifically to address change impacts identification at architecture design (Tang et al., 2007b, Zhao et al., 2002 ). However, there is little research focus on approaches that particularly support the identification of impacts on architecture design resulting from business process changes i.e. early identification of change impacts in Web systems. Furthermore, during architecture modification, architecture design complexities and high cost of change are reported as the fundamental problems in rapidly evolvable systems such as Web systems that are based on business processes (Xiaoyu and Mei-Hwa, 2007). Consequently, most of current research proposes the utilisation of design knowledge both during architecture maintenance (Bengtsson et al., 2004) and modification (Tang et al., 2007a). Surprisingly, there is less research focus on the utilisation of design knowledge to support the identification of impacts on architecture design. A less focus on the identification of impacts on architecture design resulting from business process changes may lead to problem- where detail designing or implementation actually begins before change impacts are adequately identified. Consequently, inadequate impact identification further leads to unnecessary re-work during subsequent stages of system development. Therefore, in this paper, we have limited the scope of CIA only to the architecture design, before the detail design actually begins. Gaining design knowledge is considered as an important outcome of the design process during the initial construction and the evolution of a system (Jansen and Bosch, 2005). Kruchten et al. considers design

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens, Greece

knowledge (or more specifically architectural design knowledge) as a combination of design and design decisions (Kruchten et al., 2006). Similarly Bosch and others have pointed out that Design Decisions (DDs), and their mapping to both the system requirements-upstream, or the architecture1 design and implementation-downstream are also the key components during architecture modification (Jansen and Bosch, 2005, Jansen et al., 2007, Tyree and Akerman, 2005). To address the problem where detail designing or implementation actually begins before change impacts are adequately identified, we focus on identification of impacts on architecture design resulting from business processes changes. We called the identification of impacts on architecture design resulting from business processes changes as early identification of impacts in Web systems. Further, we propose to employ design decisions (reported as the earliest available design knowledge (Jansen and Bosch, 2005, Ven et al., 2006)) for the identification of change impacts on architecture design. For the practical application of our research proposal, we have developed a process model of CIA that provides the necessary components for systematically and rigorously incorporating the notion of DDs during CIA and supports for an early identification of change impacts. Our CIA process model can be considered as an extension of the core CIA process model proposed in (Bohner and Arnold, 1996). The work presented in this paper is motivated by following two research questions: RQ1: Does process model of CIA provide support for the identification of change impacts on architecture design in Web systems? RQ2: Can the process model of CIA be adopted for early identification of change impacts in Web systems? To address these research questions we provide the details of process model and its instantiation by an example case study. The rest of the paper is structured as follows. Section 2 discusses Web systems architecture - information architecture and the importance of design knowledge during CIA. Section 3 presents CIA process model and its exemplification. Conclusions and future work can be found in 4.

2 WEB SYSTEMS ARCHITECTURE IN RELATION TO CIA

The nature of Web systems implies that potential changes in business process/models may fundamentally affect on different types of architecture such as functional, system and information architecture (Lowe and Henderson-Sellers, 2003). Information architecture (which covers aspects such as the content viewpoints, navigational structures, information flows and its behaviour (Rosenfeld and Morville, 2006)) is substantially more sophisticated in Web systems than traditional software systems (Lowe and HendersonSellers, 2003). This is partly a consequence of the fact that Web systems typically have a major focus on the information (content) itself, whereas traditional software systems mostly focus on defining data types (Lowe and Henderson-Sellers, 2003). Irrespective of the sophistication of the functionality and the creativity of the interface, a Web system is likely to fail without an appropriate and substantial support of up-to-date information; structure, flow and behaviour of information (Lowe and Henderson-Sellers, 2003). Intuitively, there is an increased emphasis on information architecture and its relation to the functionalities that a web-based business offers. This is partially true due to distinguishing characteristics of Web systems where business processes and architecture are tightly connected (Lowe and Henderson-Sellers, 2003) and solution co-evolves (Lowe and Eklund, 2002). In order to clearly reflect business processes changes at information architecture design of Web systems, it is necessary to adequately identify the impacts on information architecture design resulted from business process changes. During architectural design modifications, necessary design decisions (DDs) are taken to address those modifications. Typically these DDs are intertwined with a number of design entities, and thus may have propagating effect on other parts of architecture (Jansen and Bosch, 2005). Existing architecture CIA approaches mainly focus on the changes to the architecture component and the connectors (Tang et al., 2007b, Zhao et al., 2002 ), and have less focus to employ design knowledge such as DDs during impact

We use a common definition of architecture proposed by IEEE (2000) as The software architecture of a program or computer is the structure or structures of the system, which comprises software components, the externally visible properties of those components, and the relationships among them.

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens, Greece

analysis. We argue that the problem - where detail design or implementation actually begins before change impacts are adequately identified- is partially due to inadequate support provided by current CIA approaches in Web systems context (Mehboob et al., 2009). The later the change impacts are recognized and managed, the more expensive and difficult to address these change impacts (Rosso, 2006, Xiaoyu and Mei-Hwa, 2007). Given the lack of support (i.e. the early identification of impacts during Web systems development) provided by current CIA approaches, we advocate that early identification of impacts is an obvious need to maintain sophisticated and up-to-date architecture such as information architecture, that consequently leads to high degree of satisfied user interaction and thus a successful Web systems. We propose that at architecture design level, DDs as earliest available design knowledge (Jansen and Bosch, 2005, Ven et al., 2006) can be used during CIA. We have treated DDs as a main source of design knowledge in our CIA process model and describe it in next section.

2.1

Design decision and its use in CIA

It is widely accepted that reusability of either design structure or design knowledge is the most valuable kind of reuse (Gamma et al., 1995). To better understand different terminology being referred in this paper in relation to architecture design, we have developed a structure representation as shown in figure 1. According to Kruchten et al. (Kruchten et al., 2006) design decisions are an important type of design knowledge and can be based on the kind of design entity, design rationale, along with design rules and design constraints (Jansen et al., 2007). Importantly, the significance of design rules and constraints is also highlighted in a number of current software architecture researches which are focused on the treatment of design decisions as first class entity (Jansen and Bosch, 2005, Jansen et al., 2007, Tyree and Akerman, 2005). In the rest of this paper we use the following description of design constraints and design rules: 1. Constraints - are the limitations to what can be achieved (Jansen and Bosch, 2005). They may be of a technical, infrastructure or other nature. Design constraints are prescriptions for further design decisions. They describe what is not allowed in the future of the design, i.e. they prohibit certain behaviors (Jansen and Bosch, 2005). 2. Design Rules - the behavior of one design entity may influence other design entity in other parts of architecture by limiting the available design options. Rules are mandatory guidelines (Jansen and Bosch, 2005), whereas constraints limit the design to remain sound. Importantly, design rules and design constraints imply certain behavior on architecture design (Mattsson et al., 2008) and consequently shape the architecture design both by limiting and encouraging these behaviors (Jansen et al., 2007). Keeping in view the definition of system architecture (composed of component and connector (IEEE, 2000)), both of these limiting and encouraging aspects may not be very useful by themselves, however, they may be more useful when they are employed to investigate the relationships from one design entity (component) to another design entity. Therefore, we have only considered design rules and design constraints useful for the purpose of CIA as they explicitly guide us toward possible relationships among design entities of architecture. Design rules and constraints reveal collaborating design entities and their relationships (Mattsson et al., 2008). Relationships among design entities stem from the structure and imposing behaviour on architecture design that are typically implicit in the underlying design rules or constraints (Harrison et al., 2007). We consider these relationships as a core information source to support the identification of impacts on architecture design as described in section 3.3.2.

Figure 1: structure representation of architecture design terminologies

3 PROCESS MODEL OF CIA

In this section we briefly describe process model of CIA. In next sections we present an example case study, illustrate the architecture design of the selected case study system, and explain in details the three steps of process model. The process model of CIA, as shown in Figure 2, can be distinguished from the

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens, Greece

Legends: BP: Business Process SIS: Starting Impact Set AR: Architecture Requ. EIS: Estimated Impact Set DE: Design entity DIS: Discovered Impact Set FPIS: False Positive Impact : flow in process model Figure 2: A Process Model of Change Impact Analysis, illustrating the three steps and the activities within each step

previously published process models of CIA [e.g. (Bengtsson et al., 2004, Tang et al., 2007b, Zhao et al., 2002 )] in three ways. Firstly we propose to identify the impacts on architecture resulting from business processes changes. Secondly at architecture design stage (i.e. the earliest stage where design knowledge is available), we propose to explore DDs and to employ such as design rules and design constraints to support early identification of change impacts. Thirdly, we tend to make the connection explicit from Business ProcessesArchitecture RequirementsDDs(retrieved design rules, design constraints) DEs. Overall, we consider DDs as an important input for process model of CIA as reported elsewhere (Mehboob and Zowghi, 2009). Additionally, we have used other information such as change request form/information and previous experience, etc. that are also considered important in other CIA approaches such as (Bohner

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens, Greece

and Arnold, 1996, Tang et al., 2007b, Zhao et al., 2002 ). We briefly describe each input of CIA process model as follows: Change request form/ information - Change requests are the initial source of change information for process model of CIA. The change request can be either a business process modification or an enhancement request. Previous experience - previous experience is used by process model of CIA to better predict change extent, and for a deeper understanding of impacts on architecture design. Design decisions - As discussed before, DDs are one of the important kinds of design knowledge and are used to identify design rules and design constraints. Architecture design representation - Architecture design specification comes in many different forms, for example as architecture sketches, view-based architecture models, and textual descriptions of system components and so on. However, our CIA process model is limited to address architecture specification that include architecture representation languages, visual references and interface of architectures (such as WebML (Ceri et al., 2000) etc). As shown in Figure 2, the process model of CIA is mainly based on three steps. Whereas the output of the process model is an impact set i.e. Actual Impact Set (AIS). We describe in detail both the three steps of process model and its output in section 3.3.

3.1

Case study for CIA process model

We have adapted an example case study from (Acerbis et al., 2008) of Web-based personal loan system to describe process model of CIA. The Web system provides users to browse for features, terms and conditions, application fee, and application criteria for a personal loan; to fill application form, and to get notification for the acceptance/rejection of a loan request. Additionally, online system allows the staff to evaluate the loan request, check the details of loan applications, register the final decision for an application, and finalise a given application. Overall, Web system describes a simplified business process related to loan request executed by two actors: customer and staff. In the next section we describe architecture design illustrating the information structure and navigational flow of online system.

3.2

Overview of WebML and design models for case study

We present a simplified design model- describing the navigational design of an example case study Web systems using WebML modeling notations (Acerbis et al., 2008). Typically in WebML, a hypertext model specifies information structure, system navigational flow and user navigation path that determines the execution and the composition of web pages representing the activities to be executed (Ceri et al., 2000). WebML defines a data schema/ model, describing application data, and hypertexts. Therefore, it is possible to define different hypertexts (staff view and customer view) as we illustrated in figure 3a and 3b. Figure 3a shows a fragment of WebML hypertext model for staff siteview. From the home page two links allow the staff to reach two pages. First - the lists of applications (for validation check) for which the security check has to start are shown by means of index units and then check activity start. Second- Loan Request is finally approved and optionally connects to a set of loan proposals. Figure 3b shows a fragment of WebML hypertext model for the customer site view. From the home page 3 links allow the customer to reach three pages including view news, loan request submission and loan request application (after preliminary validation). From a particular news item, customer can further go to detail news and associated linked pages such as detail loan page. Additionally, customer can apply for a loan request. However, only after preliminary validation customer can get to the loan request application page, and can browse for possible loan options and other loan details such as loan features, fees, terms and conditions etc. Once a customer selects a specific loan, the loan request detail page is displayed as a confirmation of loan request application. With the constant addition of loans features, Web system has introduced the discount rate in term of annual fee and interest rate associated with different types of loan. Additionally, there are few changes being introduced in the eligibility criteria, and additional terms & conditions along with normal loan request. To address these changed business process, indeed, necessary changes to supporting information structure and navigational flow are also required in order to reflect the proposed changes at

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens, Greece
Staff View

Security Validation Check Choices Choices H Application [Activity=Validation check]

Security check

Choi ces

Choices

Table 1: List of Design entities with their IDs Design Entity Validation check choice Loan Proposal list Loan details unit News components IDs DE1 DE2 DE3 DE4

Home page

Security check

Table 1: Depedencies between architeture requirements and design entities Architecture Requirements AR1 AR2 AR3 Design Entities DE1 DE2, DE3 DE4

Figure 3a: Navigational flow of loan issuance for staff view

Customer view
News Request Detail Page

Impacted Architecture area Areas

[CountryToNewsCategory] NEST Category [NewsCategoryToSubCategory] NewsHeadline NewsDetail

Loan Request Preliminary Validation [Entry=LoanRequest] Loan Request Loan Request Request Detail Page Loan Request Submission page Selected Loan detail Page Loan Details

[NewsToDetailsPage]

Loan Request Apply now Loan

View News

Loan details Page Request Application Page Loan Options Loan Loan Features Fee, terms and conditions Application

Home page
Loan Options [Request_loan options] Loan

User Loan request

Loan Request [user_request]

Figure 3b: Navigational flow of loan issuance for customer view

information architecture design. For example in case of loan request application, the introduction of discount rate and related information (such as new term and condition, eligibility criteria etc) need to be structure and organize as an important aspects of information architecture. Similarly, for keeping the customer informed about any major update, the introduction of discount rate also needs to be communicated to customer prior to loan request. Indeed, in order to maintain up-to-date and informationrich Web applications, it is necessary that changes in business processes are reflected at the level of information organisation, its access and its flow. To assess the effect of change at hypertext model (describing information structure and navigational flow) as illustrated in figure 3a and 3b, we run proposed CIA process model on the given case study as describe in next section. In the case study, we have used a number of design rules (as presented in (Garrido et al., 1997)) that address different navigational aspects such as (1) availability of information and easy exploration-News

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens, Greece

component, (2) multiple navigation paths for different context- Set-based navigation, and (3) assisting users in knowing the current position while navigating- Active reference. One important aspect that we have noticed in all design rules is the underlying structure and the relationships among the design entities of design rule (Akanda and German, 2005). In this case study, design rules facilitate us to discover the possible dependency (among design entities) as described in section 3.3.2. Having the understanding of dependency among design entities further supports the identification of change impacts on information architecture design.

3.3

Illustration of Process Model with case study

In the following sections we describe 3 steps of process model of CIA with the help of case study (explained in section 3.2).
3.3.1 Step#1: Examine architectural change specifications and related information.

In step#1, three mian sources of information i.e. change request form/information, architecture design specifications and previous experience are used. From these sources of information, we have further derived two types of information (i) traceability information (traceability between Business Processes and Architecture Requirements) and (ii) dependency information (dependency between Architecture requirements and design entities). For the presented case study, Web designers/architects can determine the requested changes in business processes by using change request form /information. The proposed changes in business processes can be listed as: The introduction of discount rate during loan request (BP_loanrequest_01) is only applicable where applicants fulfil eligibility criteria as specified in BP_applic-criteria_03. The eligibility criteria include job check along with other normal check during loan request as a part of BP_loancheck_03. Changes to loan request features need to be communicated to the applicants by extending the communication mechanism specified in BP_communiaction_07. Traceability analysis - Traceability analysis gives the breath of change propagation by providing the links among system artifacts (Bohner and Arnold, 1996) (e.g. requirement specification, architecture specification, code module and test cases etc). The existing research work on traceability matrix has been leveraged in process model and we have focused on Pohls work (Pohl et al., 2001) that suggest on maintaining possible relationships between business processes and architectural requirements. In process
Business Processes Tacit Knowledge and Previous experience Architecture Specification

1
Have relationship to

Define

Scope of Architecture Requirements Change Business Requirements Architecture Requirements

Define

Traceability Matrix
Architecture Requirements Identify Impacted Architecture Area

2
Identify design entities

Change Request/ Information

Impacted Architecture Area

Dependency Information

Architecture design representation

Design Design Design Design Entity Entity Entity Entity = DE1 = DE9 = DE13 = Dn

SIS

Legends: BP: Business Process AR: Architecture Requirement

DE: Design Entity : flow of activities in step#1

Figure 4: Detail of Step#1 in Process Model as shown in figure 2

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens, Greece

model of CIA, typically, relationships are specified by traceability matrix as shown in figure 4, where each row corresponds to business processes, and each column corresponds to architecture requirements (ARs). These relationships are expressed by putting a mark where the row of the business processes requirements and the column of the architecture requirements intersect ( 1 in figure 4). The set of architecture requirements (such as information architecture requirements) likely to be effected are highlighted in traceability matrix as shown in table 3. These information architecture requirements include the mechanism of an added feature discount rate and its validation as a part of validation check choices. The impacted information architecture requirements can be listed as: The introduction of discount rate requires the presentation of discount rate information and eligibility criteria in IA_Req_Loaninfo._06 and its linkage to loan details unit (for customer view). The introduction of discount rate introduce additional validation check choices, loan proposal entities in IA_Req_loan_05 and further modification of information flow and its navigation during loan request and approval activity (IA_Req_communication_07). Communicating the additional set of information related to discount rate to applicants (IA_Req_communication_07) is required by mean of News component (for customer view) in IA_Req_loan_05. Analysing the traceability links further down to architecture design representation, is very beneficial to determine the location where the impacted architecture requirements are need to be implemented ( 2 in figure 4). Given the changes to information architecture requirements as listed above, for example, IA_Req_Loaninfo._06 and partial IA_Req_loan_05 are need to be addressed in the staff view of design specifications and shown by dotted line in figure 3a-staff view. Similarly, other impacted architecture areas is determined as shown by dotted lines in figure 3b-customer view. Further taking into account impacted architecture area and using dependency analysis, we have identified design entities on which impacted architecture requirement depends on for implementation. We have represented these design entities in italic in the lists of impacted information architecture requirements as above. Dependency information - Dependency analysis provides the depth of change propagation (Bohner and Arnold, 1996). After the identification of impacted architecture area, dependency relationships between requirements and their underpinning information architecture design entities ( 3 in figure 3) are explored. The dependency analysis is performed by investigating all design entities on which impacted architecture requirements depends on. For example IA_Req_loan_05 depends on Loan Proposal list and Loan details unit for implementation at architecture design level, as shown in Table 2. All those design entities that correspond to impacted architecture requirements are considered as a starting impact set. For the ease of representation, we have assigned identity (as shown in table 1) to each design entities. Starting Impact Set (SIS) - The identification of traceability information (between business processes and architecture requirements) and the dependency information as discussed above allow us to identify the starting impact set i.e. the set of design entity that are thought to be initially affected by changing business processes. Therefore, we have SIS = {DE1, DE2, DE3, DE4}.
3.3.2

Step#2: Trace potential impacts.

Bosch and others stated that design decisions are cross-cutting and intertwined (Bosch, 2004), meaning that some design decision may affect on design entities that are associated with other design decisions. As discussed in section 2.1, the extracted information from DDs such as design constraints and design rules tends to exhibit dependency relationships among design entities. Tracing the potential impacts of changes made to design entity is described through backward tracing in dependency graph. However, prior three
Arch. Requirements Business Process

IA_Req 06

IA_Req 05

IA_Req 07

BP_loanrequest-01 BP_loanapproval-02 BP_applic-criteris_03 BP_communicat._07

Table 3: Traceability Matrix

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

...

European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens, Greece

sub-section including finding design decisions, exploring design rules/constraints,forward tracing for design entity relationship describe the activities in step#2 and are pre-requisite for tracing potential impacts of change. Finding Design Decisions - Design decisions that are taken to develop and modify architecture are stored in design decisions repository along with design rules and design constraints. The current approaches to capture design decisions are to document them in textual form (Jansen et al., 2007) by means of DDs management tools and in templates (Jansen and Bosch, 2005, Jansen et al., 2007). However, many design decisions are also captured by using design patterns (Harrison et al., 2007). A number of approaches and tools are reported to documents and manage design decisions in a form of repositories (Jansen and Bosch, 2005, Jansen et al., 2007). Additionally, design decisions can easily be retrieved from these repositories by using simple search query. Keeping in view existing research in relation to design decision repository, we assume that design decisions and their underlying information are being captured and managed successfully. From existing tools/approaches developed for design decision repository, we have selected architecture design decision support system (ADDSS) tool by Capilla et al.(Capilla et al., 2006) and Archium tool by (Jansen et al., 2007) as these both approaches provide adequate support to document and retrieve design rules and design constraints. For our case study, design decisions related to impacted design entities (i.e. SIS from setp#1) are retrieved by using search query from design decision repository ( 1 in figure 5). In doing so, for each impacted design entity (from SIS) we search for design decisions where that particular design entity has participated. At a minimum, design decisions mostly documented to reflect decision identifier, design entity, design rules, design constraints, rational/reason, alternative solutions etc. (Jansen et al., 2007). So it is trivial to search out design decisions from repository against each design entity of SIS. For our case study, we have retrieved four related design decisions from design decisions repository (as shown in Table 4). Explore Design rules/constraints - As shown in figure 3, we have considered (i) decision identifier (ii) design entities (iii) design rules and design constrains- more relevant for process model of CIA (see section 2.1) and to be used during step#2. Indeed, design rules and constraints act as a connector to link design entities and can be considered as a good source to understand the underpinning relationships among design entities. Importantly, most of design decisions approaches and tools support for a common set of information including design constraints and design rules (Jansen and Bosch, 2005, Jansen et al., 2007). These are mainly recorded in a form of natural language text as shown in Table 4. Design rules, design constraints and their associated design entities are further examined ( 2 in figure 5). For this specific instance of case study, we have found that only design rules (not design constraints) were documented in design decisions repository. In general practice, it is likely the case that based on the nature of system and architecture being developed, the practice may vary to document design rules or design constraints or both. However, the activities in this step remain same either we use design rules or or design constraints because
Design Decisions Knowledge
Explore Design Decisions Knowledge Forward Tracing Design entity relationships
DR2 DCn Design Design Design Design Entity Entity Entity Entity = D1 = D2 = D3 = Dn

SIS

Legends: DD = Design Decision DE = Design Entity DF = Design Fragment = Follow of activities in Step#2

Find Design Decisions

Design Decisions (DDs)

DE8 DE9 DE7 DE6 DE5 DE1 DE4

DE2

DD 1 2
Explore Design Rules Forward Tracing Design entity relationships

DE3

Envisioning Design Rules, Design Constraints and design elements

4 Reverse Tracing for dependency analysis

e68 DE6 DE8 e89 e87 e56 DE5 DE9 DE7 e54 DE4 DE3 e43 DE1 e31 DE2 e32

DD 2
Explore Design Constraints

2
Design entities [DE3,DE5,DE6,.DEm]

Dependency graph

EIS

Figure 5: Detail of Step#2 in Process Model as shown in figure 2

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens, Greece Design Decision 1 DD# DD-09: Pat_News_latestupdate DEs News component, set-based navigation, News-presentation, Navigation object Design 1. DD-09_DR1: Each news component as presentation object is navigated from one news item to other as a navigational context by using Set-Based Navigation. Rules 2. DD-09_DR2: Each news component is explored by landmark and specified in more than one context and linked to other context. For example from latest update context to loan context by using InContext Object (News). Design Decision 2 DD-18: Pat_Landmark_section Detail unit, landmark, menu list, set-based navigation, active reference 1. DD-18_DR1: The addresses list of all section (landmark) are passed as a list of parameters (hypermedia pointers) to the controller object (for example to implement loan detail unit) 2. DD-18_DR2: Controller object generate a menu list and make the landmarks accessible from every node of that menu using a single click. 3. DD-18_DR3: Display method of controller object instantiate each menu list specified by set-based navigation and referenced by landmark Incontext and 4. DD-18_DR4: Each Loan detail unit are implemented as a landmark. Implementation of landmark is referred by active reference.

DD# DEs Design Rules

Design Decision 3 DD# DD-21b: Incontext_sharedcontext DEs Incontext, navigational object, semantic link Design 1. DD-21b_DR1: InContext object defined as subclasses of InContextSequential, inherit anchors for sequential navigation and for backtracking to the context index. Rules Design Decision 4 DD# DD-22: Active Reference DEs Incontext, Controller Object, Active reference, Presentation Object Design 1. DD-22_DR1: Each controller object keeps track of the users current position in navigating the hierarchy of information and pass on this current position to active reference object. Rules 2. DD-22_DR2: Each active reference object keep track of the users navigation path (parameters) starting from the root of the hierarchy to current position (receives the users current position from the Controller) and generates a presentational object showing the whole navigation path.

Table 4: Design decisions and other design information Design Rule DD-09_DR1 DD-09_DR3 DD-18_DR1 DD-18_DR2 DD-18_DR3 DD-18_DR4 DD21b_DR1 DD-22_DR1 DD-22_DR2 Design entity News Set-based navigation InContext (News) Addresslist menuelist Landmark InContext Landmark Incontext Sequential Object Active reference object Presentational object

News component News component Landmark Landmark Controller Landmark/ menu list Loan detail unit InContext Object Active reference Controller Object Active reference obj

Presentation Object Landmark Landmark Controller

Landmark Set-based Navigational Landmark Active Reference

Table 5: Design rules extracted from table 4

both design rules or design constraints support to reveal relationships among design entities, and these underlying relationships is considered important for process model of CIA. Table 4 provides the details of 4 selected design decisions and their related information. We have extracted design rules from each design decisions (table 4) and by using content analysis determined participating design entities from each design rules. Table 5 shown each design rules (represented by design rules identifiers) and design entities belong to these rules (represented by design rules Identifiers). Forward tracing of design entity relationships - Design rules as shown in table 4 support to reveals design entity relationships. By forward tracing ( 3 in figure 5), all design entity relationships are determined as

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

10

European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens, Greece

shown in figure 6 and represented by a directed link that relate design entities together. For case study Web system, there is no design rule associated with validation check choices-DE1 and loan proposal list-DE2 (design entities from SIS). It means that DE1 and DE2 do not reveal any ripple effect when they are actually being modified because there is no rules associated with either DE1 or DE2. Therefore we have not considered DE1 and DE2 during forward tracing of design entity relationships. However, other design entities from table 1 such as loan detail unit-DE3, and News component-DE4 have associated design rules as shown in table 5. For example in DD-18_DR2 from table 5, the participating design entities are landmark controller, menu list and landmark set-based navigation and they are related to each other under a design rule. By considering all design rules from selected design decisions it create a network of relationships among design entities and thus support to explore implicit design entity relationships. For example, as shown in figure 6, design decision DD-18 depicts a network of relationships among design entities by considering all design rules documented with DD-18. This network of design entity relationships is further expanded by considering other design rules including those that tend to relate design entities between two design decisions. For example by using DD-09-DR2, News component from DD-09 is determined to be related to Landmark from DD-18. Out of four design entities from SIS, only two design entities DE3 and DE4 have the design rules associated with them, therefore we have used DE3 and DE4 further for identification of design entity relationships. Backward tracing for dependency graph Graphical representation of dependencies such as dependency graph is reported as the most mature strategy available for change impact analysis (Tang et al., 2007b). A dependency graph is a directed graph, represented by tuple (DE, DEdge) (Rosen, 2006), where DE is a set of nodes representing design entities, and DEdge is a set of dependency relationships (between two nodes) represented by directed edges. By backward tracing of design entity relationships ( 3 of figure 5) a dependency graph is developed ( 4 in figure 5). Each node in the dependency graph represents a design entity, and each edge in the graph represents a dependency relationship as shown in figure 7. Web designers/ architects can determine the name of dependency relationships from table 4 as shown in italic. For the ease of representation, we have assigned identity to each design entities of figure 6 as shown in table 6. The design entities from table 6 are used in the development of dependency graph. In the dependency graph, the solid line edge (for example from DE7DE8DE4) indicates a dependency relationship between design entities as shown in figure 7. However, the dotted line edges (from DE17DE16 and DE18DE12) indicate that these edges do not reveal any dependency relationship while backward tracing of design entity relationships. For example, there is a relationship between DE17 and DE16, but backward tracing of this relationship do not revel any dependency between DE17 and DE16. Because DE16 is defined as a subclass of DE17, and whenever base class is changed, subclass can inherit any changes in attribute or behaviour from the base class, thus there is no dependency exist between DE17 and DE16. Similarly, there is a relationship between DE18 and DE12, where DE18 shows the path taken in DE12 by using a list of parameters. However, if path get change due to different parameters passing then the display of path also automatically gets change in DE18. Therefore, there is no dependency as such between DE18 and DE12. Impacted design entity such as DE13 can be determined with direct dependency (named as get parameter) between DE15 and DE13, where as DE4 can be determined by using chains of dependency between DE14 and DE4 such as DE14DE15DE13DE9DE4 as illustrated in figure 7. Once the dependency graph has been constructed, the potential impacts of a change are determined after taking into account every design entity that depends on other design entities directly and indirectly. Here potential impacts of change mean the set of estimated impacts on architecture design. Considering both direct and indirect dependencies among design entities support to determine estimated impact set. Estimated Impact Set (EIS) - This is the set of design entities that are estimated to be affected according to the selected change assessment method such as dependency graph, inferencing, slicing and heuristics methods (Bohner and Arnold, 1996). We have used dependency graph in process model of CIA. Through dependency graph, we have identified all those design entity that depends directly and indirectly to the design entity of SIS. EIS subsumes the SIS and can therefore be seen as an expansion of the SIS. The identification of estimated design entities is repeated until all impacted design entities are discovered. Considering SIS and dependency graph from figure 7, it is determined that, EIS = {DE1, DE2, DE3, DE4, DE6, DE7, DE8, DE9, DE10, DE11, DE12, DE13, DE14, DE15, DE16, DE18, DE19, DE20}

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

11

European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens, Greece

Figure 6: Forward tracing of design entity relationships Design entity Loan detail unit News component News InContext Presentation Objects News Set-based navigation Landmark Landmark InContext Landmark set-based navigation Landmark Active reference IDs DE3 DE4 DE6 DE7 DE8 DE9 DE10 DE11 DE12 Design entity Addresslist Munuelist Landmark Controller InContext Object InContext SequentialObject Active Reference Controller Active Reference Presentation Object IDs DE13 DE14 DE15 DE16 DE17 DE18 DE19 DE20

Table 6: List of Design entities with their IDs

implement DE3 explore DE9 DE13 specify have pointer define DE6 navigate DE16 define present specify DE8 DE17 DE10 DE11 DE19 DE14 specify present get current position generate by DE20 DE18 DE15 reference to get parameter DE12

Legends : DE = Design Entity Dependency relationship with dependency name non-dependency relationship

DE4

DE7

Figure 7: Dependency graph-Backward tracing for dependency analysis

3.3.3 Step#3: Perform architectural changes The design entities identified (as EIS) in step#2 are implemented by specifically making changes to the design entities at architecture design representation- in the case study the impacted design entities are the design entities of design specification as shown in figure 3a and 3b. Making changes to design entities validates the EIS and may further discover other impacted design entity (if any). These steps are iterative in nature and used for discovering new design entities and falsifying estimated design entities (EIS). Therefore, while a change is being performed at architecture design, there may likely to be other impact sets categorised as (i) Discovered Impact Set (DIS)- represents an under estimation of impacts, and (ii) False Positive Impact Set (FPIS)- represents an over-estimation of impacts. DIS can be determined by making changes for each design entities (from EIS) at architecture design and then examine other design entities in architecture design that possibility got affected by making those changes. Similarly, FPIS can be determined by examining those design entities (from EIS) that do not require any modification when the changes made to architecture design. It means that FPIS are those design entities which are the overestimation form the set of EIS. The output of enactment of CIA process model is Actual Impact Set (AIS) that is the set of design entity actually modified as a result of an implemented change. The EIS plus additions of the DIS and deletions of FBIS represents AIS (Bohner and Arnold, 1996). Therefore architecture impact set can be represented as, AIS = (EIS DIS) \ FPIS. In the case study system, we have both DIS = {}, FPIS = {}. Indeed, these null sets also indicate the accuracy of EIS as determined in step#2. Finally, AIS can be presented as below.

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

12

European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens, Greece

AIS = EIS = {DE1, DE2, DE3, DE4, DE6, DE7, DE8, DE9, DE10, DE11, DE12, DE13, DE14, DE15, DE16, DE18, DE19, DE20} The resulting AIS from process model of CIA represents an early identification of impacts on architecture design resulting from business processes changes. Additionally, we have also employed design rules and design constraints, retrieved from design decision repository.

CONCLUSIONS

In this paper we have presented a process model of CIA that provides the necessary components for systematically and rigorously incorporating the notion of DDs during CIA and thus supports for an early identification of change impacts in Web systems. We have considered design decisions and their underlying information (design rules and design constraints) to be important during impact analysis. This is mainly true due to the reason that both design rules and design constraints facilitate the discovery of possible dependencies among the design entities of an architecture design and thus in turn address RQ1. We have also demonstrate that process model of CIA supports to identify impacts on architecture design resulting from business processes changes- i.e. early identification of change impacts in Web systems. This aspect addresses RQ2. We have illustrated our process model through an example case study, thus providing an initial demonstration of its feasibility. The dependencies are derived from design rules and then used for impacts identification, in particular, when the addition or modification of a design entity has consequences to other related design entities at information architecture design. Results from the case study are encouraging as it provides the ability to understand the dependencies among design entities and thus supports the identification of impacts on architecture design. Given the paucity of research focus both on early identification of impacts in Web systems and on utilising DDs information such as design rules and design constraints, we will further improve process model of CIA and will validate it by other case studies in real settings to demonstrate both its validity and broader usability.

References
Acerbis, R., Bongio, A., Brambilla, M., Butti, S., Ceri, S. & Fraternali, P. (2008) Web Applications Design and Development with WebML and WebRatio 5.0 in Rossi, G., Pastor, O., Schwabe, D. & Olsina, L. (Eds.) Web Engineering: Modelling and Implementing Web Applications. London, Springer. Akanda, M. A. K. & German, D. M. (2005) A System of Patterns for Web Navigation International Conference on Web Ebgineering. Sydney, Australia, Springer. Benstsson, P., Lassing, N., Bosch, J. & Vliet, H. V. (2004) Architecture-level modifability analysis. Systems and Software, 69, 129-147. Bohner, S. A. & Arnold, R. S. (1996) Software Change Imapct Analysis Los Alamitos, CA, USA, IEEE Computer Society Press. Bosch, J. (2004) Software Architecture: The Next Step. In the Proceedings of First European Workshop on Software Architecture. St. Andrew, UK. Capilla, R., Nava, F., P. Rez, S. & Due, J. C. (2006) A web-based tool for managing architectural design decisions. SIGSOFT Softw. Eng. Notes, 31, 4. Ceri, S., Franternali, P. & Bongio, A. (2000) Web Modeling Language (WebML): a modeling language for designing Web sites. Comput. Netw., 33, 137-157. Gamma, E., Helm, R., Johnson, R. & Vlissides, J. M. (1995) Design Patterns: Elements of Reusable Object-Oriented Software, New Jersey, Addison-Wesley Professional Garrido, A., Rossi, G. & Schwabe, D. (1997) Pattern Systems for Hypermedia. in Pattern Language of Programming- PloP'97. Allerton Park Monticello , Illinois , USA IEEE Computer Society. Harrison, N. B., Avgeriou, P. & Zdun, U. (2007) Using Patterns to Capture Architectural Decisions. IEEE Softw., 24, 38-45. IEEE (2000) IEEE Recommended Practice for Architecture Description of Software-Intensive Systems. New York, IEEE Computer Society. Jansen, A. & Bosch, J. (2005) Software Architecture as a Set of Architectural Design Decisions. Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture. IEEE Computer Society.

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

13

European, Mediterranean & Middle Eastern Conference on Information Systems 2011 (EMCIS2011) EMCIS2011 May 30-31 2011, Athens, Greece

Jansen, A., Ven, J. V. D., Avgeriou, P. & Hammer, D. K. (2007) Tool Support for Architectural Decisions. Proceedings of the Sixth Working IEEE/IFIP Conference on Software Architecture. IEEE Computer Society. Kruchten, P., Lago, P. & Vliet, H. V. (2006) Building Up and Reasoning About Architectural Knowledge. in Hofmeister, C., Crnkovic, I. & Reussner, R. (Eds.) Quality of Software Architectures. Berlin, Springer Berlin / Heidelberg. Lowe, D. & Eklund, J. (2002) Client Needs and the Design Process in Web Projects. J. Web Eng., 1, 23-36. Lowe, D. & Henderson-Sellers, B. (2003) Characterising Web Systems: Merging Information and Functional Architectures. in Shi, N. & Murthy, V. K. (Eds.) Architecture Issues of Web-Enabled Electronic Business Hershey, PA, USA, IDEA Group Publishing. Mattsson, A., Lundell, B. & Lings, B. (2008) Modelling architectural design rules in UML. Mehboob, Z. & Zowghi, D. (2009) Industrial Perspectives on Architecture level Change Impact Analysis in Web Systems Evolution. 11th IEEE International Symposium on Web Systems Evolution, in conjunction with the 25th IEEE International Conference on Software Maintenance. Edmonton, Canada, IEEE computer Society. Mehboob, Z., Zowghi, D. & Lowe, D. (2009) An Approach for Comparison of Architecture Level Change Impact Analysis Methods and Their Relevance in Web Systems Evolution. Proceedings of the 2009 Australian Software Engineering Conference - Volume 00. IEEE Computer Society. Pohl, K., Brandenburg, M. & Gulich, A. (2001) Integrating Requirements and Architecture Information: A Scenario and Meta-Model based Approach Seventh International Workshop on Requirements: Foundation for Software Quality (REFSQ'01),. Interlaken, Switzerland. Rosen, K. H. (2006) Discrete Mathematics and Its Applications, LA,USA, McGraw-Hill. Rosenfeld, L. & Morville, P. (2006) Information Architecture for the World Wide Web, CA, O'Reilly Media, Inc. Rosso, C. D. (2006) Continuous evolution through software architecture evaluation: a case study. Journal of Software Maintenance and Evolution: Research and Practices, 18, 351-383. Tang, A., Jina, Y. & Hana, J. (2007a) A rationale-based architecture model for design traceability and reasoning. Systems and Software, 80, 918-934. Tang, A., Nicholson, A., Jin, Y. & Han, J. (2007b) Using Bayesian belief networks for change impact analysis in architecture design. Journal of Software Maintenance, 80, 127-148. Tyree, J. & Akerman, A. (2005) Architecture Decisions: Demystifying Architecture. IEEE Softw., 22, 1927. Ven, J. S. V. D., Jansen, A. G. J., Nijhuis, J. A. G. & BOSCH, A. J. (2006) Design Decisions: The Bridge between Rationale and Architecture in Dutoit, A. H., Mccall, R., Mistrik, I. & Paech, A. B. (Eds.) Rationale Management in Software Engineering. Berlin, Springer-Verlag. Xiaoyu, Z. & Mei-Hwa, C. (2007) Maintaining Multi-Tier Web Applications. IEEE International Conference on Software Maintenance- ICSM 2007. . Paris, France, IEEE. Zhao, J., Yang, H., Xiang, L. & Xu, B. (2002 ) Change impact analysis to support architectural evolution Journal of Software Maintenance 14, 317-333

Zafar Mehboob et al. A Process Model of Change Impact Analysis for Web systems using Design Knowledge

14