EMCIS 2011-Zafar Mehboob

8/6/2019 EMCIS 2011-Zafar Mehboob

1/14

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

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

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, [email protected]

Didar Zowghi, Faculty of Engineering and IT, University of Technology Sydney, NSW, [email protected]

David Lowe, Faculty of Engineering and IT, University of Technology Sydney, NSW, [email protected]

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 thosechanges. 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.

1 INTRODUCTIONCIA 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, orestimating what needs to be modified to accomplish a change. Much of the research about CIA is focusedon code level and for software maintenance, although CIA undoubtedly plays an important role in the entiresoftware development life cycle.

Different CIA methods have been developed specifically to address change impacts identification atarchitecture design (Tang et al., 2007b, Zhao et al., 2002 ). However, there is little research focus onapproaches that particularly support the identification of impacts on architecture design resulting frombusiness 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 thefundamental problems in rapidly evolvable systems such as Web systems that are based on businessprocesses (Xiaoyu and Mei-Hwa, 2007). Consequently, most of current research proposes the utilisation ofdesign knowledge both during architecture maintenance (Bengtsson et al., 2004) and modification (Tang etal., 2007a). Surprisingly, there is less research focus on the utilisation of design knowledge to support theidentification of impacts on architecture design. A less focus on the identification of impacts onarchitecture design resulting from business process changes may lead to problem- where detail designing orimplementation actually begins before change impacts are adequately identified. Consequently, inadequateimpact 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 detaildesign actually begins.

Gaining design knowledge is considered as an important outcome of the design process during the initialconstruction and the evolution of a system (Jansen and Bosch, 2005). Kruchten et al. considers design


2/14



knowledge (or more specifically architectural design knowledge) as a combination of design and designdecisions (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 andimplementation-downstream are also the key components during architecture modification (Jansen andBosch, 2005, Jansen et al., 2007, Tyree and Akerman, 2005).

To address the problem where detail designing or implementation actually begins before change impactsare adequately identified, we focus on identification of impacts on architecture design resulting frombusiness processes changes. We called the identification of impacts on architecture design resulting frombusiness processes changes as early identification of impacts in Web systems. Further, we propose toemploy design decisions (reported as the earliest available design knowledge (Jansen and Bosch, 2005, Venet al., 2006)) for the identification of change impacts on architecture design. For the practical application ofour research proposal, we have developed a process model of CIA that provides the necessary componentsfor systematically and rigorously incorporating the notion of DDs during CIA and supports for an earlyidentification of change impacts. Our CIA process model can be considered as an extension of the core CIAprocess model proposed in (Bohner and Arnold, 1996). The work presented in this paper is motivated byfollowing two research questions:

RQ1: Does process model of CIA provide support for the identification of change impacts on architecturedesign 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 anexample case study. The rest of the paper is structured as follows. Section 2 discusses Web systemsarchitecture - information architecture and the importance of design knowledge during CIA. Section 3presents CIA process model and its exemplification. Conclusions and future work can be found in 4.

2 WEB SYSTEMS ARCHITECTURE IN RELATION TO CIAThe nature of Web systems implies that potential changes in business process/models may fundamentallyaffect on different types of architecture such as functional, system and information architecture (Lowe andHenderson-Sellers, 2003). Information architecture (which covers aspects such as the content viewpoints,navigational structures, information flows and its behaviour (Rosenfeld and Morville, 2006)) issubstantially more sophisticated in Web systems than traditional software systems (Lowe and Henderson-Sellers, 2003). This is partly a consequence of the fact that Web systems typically have a major focus onthe 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 thecreativity of the interface, a Web system is likely to fail without an appropriate and substantial support ofup-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 functionalitiesthat a web-based business offers. This is partially true due to distinguishing characteristics of Web systemswhere 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 atinformation architecture design of Web systems, it is necessary to adequately identify the impacts oninformation architecture design resulted from business process changes.

During architectural design modifications, necessary design decisions (DDs) are taken to address thosemodifications. Typically these DDs are intertwined with a number of design entities, and thus may havepropagating effect on other parts of architecture (Jansen and Bosch, 2005). Existing architecture CIAapproaches 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

1We 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 amongthem.


3/14



analysis. We argue that the problem - where detail design or implementation actually begins before changeimpacts are adequately identified- is partially due to inadequate support provided by current CIAapproaches in Web systems context (Mehboob et al., 2009). The later the change impacts are recognizedand managed, the more expensive and difficult to address these change impacts (Rosso, 2006, Xiaoyu andMei-Hwa, 2007). Given the lack of support (i.e. the early identification of impacts during Web systemsdevelopment) 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, thatconsequently leads to high degree of satisfied user interaction and thus a successful Web systems. Wepropose 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 designknowledge in our CIA process model and describe it in next section.

2.1 Design decision and its use in CIAIt is widely accepted that reusability of either design structure or design knowledge is the most valuablekind of reuse (Gamma et al., 1995). To better understand different terminology being referred in this paperin 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 anddesign constraints (Jansen et al., 2007). Importantly, the significance of design rules and constraints is alsohighlighted in a number of current software architecture researches which are focused on the treatment ofdesign 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 ofa technical, infrastructure or other nature. Design constraints are prescriptions for further designdecisions. They describe what is not allowed in the future of the design, i.e. they prohibit certainbehaviors (Jansen and Bosch, 2005).

2. Design Rules - the behavior of one design entity may influence other design entity in other parts ofarchitecture by limiting the available design options. Rules are mandatory guidelines (Jansen andBosch, 2005), whereas constraints limit the design to remain sound.

Importantly, design rules and design constraints imply certain behavior on architecture design (Mattsson etal., 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 andconnector (IEEE, 2000)), both of these limiting and encouraging aspects may not be very useful bythemselves, however, they may be more useful when they are employed to investigate the relationshipsfrom one design entity (component) to another design entity. Therefore, we have only considered designrules and design constraints useful for the purpose of CIA as they explicitly guide us toward possiblerelationships among design entities of architecture. Design rules and constraints reveal collaborating designentities and their relationships (Mattsson et al., 2008). Relationships among design entities stem from thestructure and imposing behaviour on architecture design that are typically implicit in the underlying designrules or constraints (Harrison et al., 2007). We consider these relationships as a core information source tosupport 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 CIAIn this section we briefly describe process model of CIA. In next sections we present an example casestudy, illustrate the architecture design of the selected case study system, and explain in details the threesteps of process model. The process model of CIA, as shown in Figure 2, can be distinguished from the


4/14



Legends:BP: Business ProcessSIS: Starting Impact SetAR: Architecture Requ.EIS: Estimated Impact SetDE: Design entityDIS: 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 businessprocesses changes. Secondly at architecture design stage (i.e. the earliest stage where design knowledge isavailable), we propose to explore DDs and to employ such as design rules and design constraints to supportearly identification of change impacts. Thirdly, we tend to make the connection explicit from BusinessProcessesArchitecture RequirementsDDs(retrieved design rules, design constraints) DEs. Overall,we consider DDs as an important input for process model of CIA as reported elsewhere (Mehboob andZowghi, 2009). Additionally, we have used other information such as change request form/information andprevious experience, etc. that are also considered important in other CIA approaches such as (Bohner


5/14



and Arnold, 1996, Tang et al., 2007b, Zhao et al., 2002 ). We briefly describe each input of CIA processmodel as follows:

Change request form/ information - Change requests are the initial source of change information forprocess model of CIA. The change request can be either a business process modification or an enhancementrequest.

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 areused to identify design rules and design constraints.

Architecture design representation - Architecture design specificationcomes in many different forms, forexample as architecture sketches, view-based architecture models, and textual descriptions of systemcomponents and so on. However, our CIA process model is limited to address architecture specificationthat include architecture representation languages, visual references and interface of architectures (such asWebML (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 theprocess model is an impact set i.e. Actual Impact Set (AIS). We describe in detail both the three steps ofprocess model and its output in section 3.3.

3.1 Case study for CIA process modelWe have adapted an example case study from (Acerbis et al., 2008) of Web-based personal loan system todescribe process model of CIA. The Web system provides users to browse for features, terms andconditions, application fee, and application criteria for a personal loan; to fill application form, and to getnotification for the acceptance/rejection of a loan request. Additionally, online system allows the staff toevaluate the loan request, check the details of loan applications, register the final decision for anapplication, 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 describearchitecture design illustrating the information structure and navigational flow of online system.

3.2 Overview of WebML and design models for case studyWe present a simplified design model- describing the navigational design of an example case study Websystems using WebML modeling notations (Acerbis et al., 2008). Typically in WebML, a hypertext modelspecifies information structure, system navigational flow and user navigation path that determines theexecution 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 possibleto define different hypertexts (staff view and customer view) as we illustrated in figure 3a and 3b. Figure 3ashows a fragment of WebML hypertext model for staff siteview. From the home page two links allow thestaff to reach two pages. First - the lists of applications (for validation check) for which the security checkhas to start are shown by means of index units and then check activity start. Second- Loan Request isfinally approved and optionally connects to a set of loan proposals. Figure 3b shows a fragment of WebMLhypertext model for the customer site view. From the home page 3 links allow the customer to reach threepages including view news, loan request submission and loan request application (after preliminaryvalidation). From a particular news item, customer can further go to detail news and associated linkedpages such as detail loan page. Additionally, customer can apply for a loan request. However, only afterpreliminary validation customer can get to the loan request application page, and can browse for possibleloan options and other loan details such as loan features, fees, terms and conditions etc. Once a customerselects a specific loan, the loan request detail page is displayed as a confirmation of loan requestapplication. With the constant addition of loans features, Web system has introduced the discount rate interm of annual fee and interest rate associated with different types of loan. Additionally, there are fewchanges 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 supportinginformation structure and navigational flow are also required in order to reflect the proposed changes at


6/14



Table 1: List of Design entities with

their IDs

Table 1: Depedencies between

architeture requirements and design

entities

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

[CountryToNewsCategory]

NEST Category[NewsCategoryToSubCategory]

NewsHeadline

[NewsToDetailsPage]

NewsDetail

C

Home page

H

News

View News

Loan RequestSubmission page

Apply now

Loan Request

Request Detail Page

Preliminary Validation

[Entry=LoanRequest]

Loan Request

Request Application Page

User Loan Request

[user_request]

Loan Options

Loan Options[Request_loan options]

Loan request

Loan details Page C

Loan

Loan Loan Features

L

Fee, terms and

conditions

L

Application

L

Loan

Loan Details

Selected Loan detailPage

Loan RequestRequest Detail Page

Loan Request

Customer view

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

information architecture design. For example in case of loan request application, the introduction ofdiscount rate and related information (such as new term and condition, eligibility criteria etc) need to bestructure and organize as an important aspects of information architecture. Similarly, for keeping thecustomer informed about any major update, the introduction of discount rate also needs to becommunicated to customer prior to loan request. Indeed, in order to maintain up-to-date and information-rich Web applications, it is necessary that changes in business processes are reflected at the level ofinformation 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 proposedCIA 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)) thataddress different navigational aspects such as (1) availability of information and easy exploration-News

Design Entity IDs

Validation check

choice

DE1

Loan Proposal list DE2

Loan details unit DE3

News components DE4

ArchitectureRequirements

DesignEntities

AR1 DE1

AR2 DE2, DE3

AR3 DE4

Impacted Architecture area

Home page

H

Security Check Choices

Application[Activity=Validation check]

Choices Choices

Securitycheck

Security check

Choices

Staff View

Validation Check


7/14



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

architecture design.

3.3 Illustration of Process Model with case studyIn 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 designspecifications and previous experience are used. From these sources of information, we have furtherderived two types of information (i) traceability information (traceability between Business Processes andArchitecture Requirements) and (ii) dependency information (dependency between Architecture

requirements and design entities). For the presented case study, Web designers/architects can determine therequested changes in business processes by using change request form /information. The proposed changesin business processes can be listed as:

The introduction of discount rate during loan request (BP_loanrequest_01) is only applicable whereapplicants 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 thecommunication 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, architecturespecification, code module and test cases etc). The existing research work on traceability matrix has beenleveraged in process model and we have focused on Pohls work (Pohl et al., 2001) that suggest onmaintaining possible relationships between business processes and architectural requirements. In process

Traceability Matrix

Business Requirements

Business Processes Architecture Specification

Architecture Requirements

Tacit Knowledge and

Previous experience

Define

Change Request/

Information

Define

Scope of Architecture

Requirements Change

Architecture designrepresentation

Impacted

Architecture Area

Identify Impacted Architecture Area

Identify design entities

Dependency Information

SIS

DesignEntity

= Dn

DesignEntity

= DE13

DesignEntity

= DE9

DesignEntity

= DE1

Architecture Requirements

1

2

3

Have relationship to

Legends:

BP: Business Process DE: Design Entity

AR: Architecture Requirement : flow of activities in step#1

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


8/14



model of CIA, typically, relationships are specified by traceability matrix as shown in figure 4, whereeach 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 processesrequirements and the column of the architecture requirements intersect ( 1 in figure 4). The set ofarchitecture requirements (such as information architecture requirements) likely to be effected arehighlighted 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 eligibilitycriteria 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 inIA_Req_loan_05 and further modification of information flow and its navigation during loan requestand 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) inIA_Req_loan_05.

Analysing the traceability links further down to architecture design representation, is very beneficial todetermine the location where the impacted architecture requirements are need to be implemented ( 2 infigure 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 designspecifications and shown by dotted line in figure 3a-staff view. Similarly, other impacted architecture areasis determined as shown by dotted lines in figure 3b-customer view. Further taking into account impactedarchitecture area and using dependency analysis, we have identified design entities on which impactedarchitecture requirement depends on for implementation. We have represented these design entities in italicin the lists of impacted information architecture requirements as above.

Dependency information - Dependency analysis provides the depth of change propagation (Bohner andArnold, 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 architecturerequirements depends on. For example IA_Req_loan_05 depends on Loan Proposal list and Loan detailsunit for implementation at architecture design level, as shown in Table 2. All those design entities thatcorrespond to impacted architecture requirements are considered as a starting impact set. For the ease ofrepresentation, 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 andarchitecture requirements) and the dependency information as discussed above allow us to identify thestarting impact set i.e. the set of design entity that are thought to be initially affected by changing businessprocesses. 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), meaningthat some design decision may affect on design entities that are associated with other design decisions. Asdiscussed in section 2.1, the extracted information from DDs such as design constraints and design rulestends to exhibit dependency relationships among design entities. Tracing the potential impacts of changesmade to design entity is described through backward tracing in dependency graph. However, prior three

Arch. RequirementsBusiness Process ..

.IA_Req

06IA_Req

05IA_Req

07

BP_loanrequest-01

BP_loanapproval-02 BP_applic-criteris_03 BP_communicat._07

Table 3: Traceability Matrix


9/14



sub-section including finding design decisions, exploring design rules/constraints,forward tracing fordesign entity relationship describe the activities in step#2 and are pre-requisite for tracing potential impactsof change.

Finding Design Decisions - Design decisions that are taken to develop and modify architecture are stored indesign 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 DDsmanagement tools and in templates (Jansen and Bosch, 2005, Jansen et al., 2007). However, manydesign decisions are also captured by using design patterns (Harrison et al., 2007). A number of approachesand tools are reported to documents and manage design decisions in a form of repositories (Jansen andBosch, 2005, Jansen et al., 2007). Additionally, design decisions can easily be retrieved from theserepositories by using simple search query. Keeping in view existing research in relation to design decisionrepository, we assume that design decisions and their underlying information are being captured andmanaged successfully. From existing tools/approaches developed for design decision repository, we haveselected 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 documentand retrieve design rules and design constraints. For our case study, design decisions related to impacteddesign 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 decisionswhere that particular design entity has participated. At a minimum, design decisions mostly documented toreflect decision identifier, design entity, design rules, design constraints, rational/reason, alternativesolutions etc. (Jansen et al., 2007). So it is trivial to search out design decisions from repository againsteach design entity of SIS. For our case study, we have retrieved four related design decisions from designdecisions 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 section2.1) and to be used during step#2. Indeed, design rules and constraints act as a connector to link designentities and can be considered as a good source to understand the underpinning relationships amongdesign entities. Importantly, most of design decisions approaches and tools support for a common set ofinformation 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, designconstraints and their associated design entities are further examined ( 2 in figure 5). For this specificinstance of case study, we have found that only design rules (not design constraints) were documented indesign decisions repository. In general practice, it is likely the case that based on the nature of system andarchitecture 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

SIS

Design

Entity= Dn

Design

Entity= D3

Design

Entity= D2

Design

Entity= D1

Explore Design

Decisions Knowledge

Design Decisions (DDs)

DD 1

DD 2

Explore Design

Rules

Explore DesignConstraints

Dependency graph

DR2

DCn

DE9DE6

DE5

DE7

DE8DE1

DE4

DE3

DE2

Envisioning Design Rules, Design Constraints and

design elements

Forward TracingDesign entity relationships

Forward Tracing

Design entity relationshipsReverse Tracing for dependency analysis

DE8

DE9 DE7

e89e87

DE5

DE2

DE4

DE1DE6

DE3

e31

e32

e43

e54

e56

e68

2

4

Find Design Decisions1 3

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

EIS

2

Legends:

DD = Design Decision

DE = Design EntityDF = Design Fragment

= Follow of

activities in Step#2

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


10/14



Design Decision 1

DD# DD-09: Pat_News_latestupdate

DEs News component, set-based navigation, News-presentation, Navigation object

Design

Rules

1. DD-09_DR1: Each news component as presentation object is navigatedfrom one news item to other as anavigational context by using Set-Based Navigation.

2. DD-09_DR2: Each news component is exploredby landmark and specifiedin more than one context andlinked to other context. For example from latest update context to loan context by using InContext

Object (News).

Design Decision 2

DD# DD-18: Pat_Landmark_section

DEs Detail unit, landmark, menu list, set-based navigation, active reference

Design

Rules

1. DD-18_DR1: The addresses list of all section (landmark) are passed as a list of parameters (hypermediapointers) to the controller object (for example to implementloan detail unit)

2. DD-18_DR2: Controller object generate a menu list and make the landmarks accessible from every node ofthat menu using a single click.

3. DD-18_DR3: Display method of controller object instantiate each menu list specifiedby set-basednavigation and referencedby landmark Incontext and

4. DD-18_DR4: Each Loan detail unit are implemented as a landmark. Implementation of landmark isreferredby active reference.

Design Decision 3DD# DD-21b: Incontext_sharedcontext

DEs Incontext, navigational object, semantic link

Design

Rules

1. DD-21b_DR1: InContext object defined as subclasses of InContextSequential, inherit anchors forsequential navigation and for backtracking to the context index.

Design Decision 4

DD# DD-22: Active Reference

DEs Incontext, Controller Object, Active reference, Presentation Object

Design

Rules

1. DD-22_DR1: Each controller object keeps track of the users current position in navigating the hierarchy ofinformation andpass on this current position to active reference object.

2. DD-22_DR2: Each active reference object keep track of the users navigation path (parameters) startingfrom 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 Design entity

DD-09_DR1 News component News Set-based navigation Presentation Object

DD-09_DR3 News component InContext (News) Landmark

DD-18_DR1 Landmark Addresslist Landmark Controller

DD-18_DR2 Landmark Controller menuelist

DD-18_DR3 Landmark/ menu list Landmark InContext Landmark Set-basedNavigational

DD-18_DR4 Loan detail unit Landmark Landmark Active Reference

DD-

21b_DR1

InContext Object Incontext Sequential

ObjectDD-22_DR1 Active referenceController Object

Active reference object

DD-22_DR2 Active reference obj Presentational object

Table 5: Design rules extracted from table 4

both design rules or design constraints support to reveal relationships among design entities, and theseunderlying relationships is considered important for process model of CIA. Table 4 provides the details of 4selected design decisions and their related information. We have extracted design rules from each designdecisions (table 4) and by using content analysis determined participating design entities from each designrules. Table 5 shown each design rules (represented by design rules identifiers) and design entities belongto these rules (represented by design rules Identifiers).

Forward tracing of design entity relationships-Design rules as shown in table 4 support to reveals designentity relationships. By forward tracing ( 3 in figure 5), all design entity relationships are determined as


11/14



shown in figure 6 and represented by a directed link that relate design entities together. For case study Websystem, 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 areactually being modified because there is no rules associated with either DE1 or DE2. Therefore we havenot considered DE1 and DE2 during forward tracing of design entity relationships. However, other designentities 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 arelandmark controller, menu list and landmark set-based navigation and they are related to each other under adesign rule. By considering all design rules from selected design decisions it create a network ofrelationships among design entities and thus support to explore implicit design entity relationships. Forexample, as shown in figure 6, design decision DD-18 depicts a network of relationships among designentities by considering all design rules documented with DD-18. This network of design entity relationshipsis further expanded by considering other design rules including those that tend to relate design entitiesbetween two design decisions. For example by using DD-09-DR2, News component from DD-09 isdetermined to be related to Landmark from DD-18. Out of four design entities from SIS, only two designentities DE3 and DE4 have the design rules associated with them, therefore we have used DE3 and DE4further for identification of design entity relationships.

Backward tracing for dependency graph Graphical representation of dependencies such as dependencygraph is reported as the most mature strategy available for change impact analysis (Tang et al., 2007b). Adependency graph is a directed graph, represented by tuple (DE, DEdge) (Rosen, 2006), where DE is a setof 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) adependency graph is developed ( 4 in figure 5). Each node in the dependency graph represents a designentity, and each edge in the graph represents a dependency relationship as shown in figure 7. Webdesigners/ 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 intable 6. The design entities from table 6 are used in the development of dependency graph. In thedependency graph, the solid line edge (for example from DE7DE8DE4) indicates a dependencyrelationship between design entities as shown in figure 7. However, the dotted line edges (fromDE17DE16 and DE18DE12) indicate that these edges do not reveal any dependency relationshipwhile backward tracing of design entity relationships. For example, there is a relationship between DE17and 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 inheritany changes in attribute or behaviour from the base class, thus there is no dependency exist between DE17and DE16. Similarly, there is a relationship between DE18 and DE12, where DE18 shows the path taken inDE12 by using a list of parameters. However, if path get change due to different parameters passing thenthe display of path also automatically gets change in DE18. Therefore, there is no dependency as suchbetween 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 ofdependency 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 aftertaking 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 bothdirect 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 tothe selected change assessment method such as dependency graph, inferencing, slicing and heuristicsmethods (Bohner and Arnold, 1996). We have used dependency graph in process model of CIA. Throughdependency graph, we have identified all those design entity that depends directly and indirectly to thedesign entity of SIS. EIS subsumes the SIS and can therefore be seen as an expansion of the SIS. Theidentification 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}


12/14



Figure 6: Forward tracing of design entity relationships

Design entity IDs Design entity IDs

Loan detail unit DE3 Addresslist DE13

News component DE4 Munuelist DE14

News InContext DE6 Landmark Controller DE15

Presentation Objects DE7 InContext Object DE16

News Set-based navigation DE8 InContext SequentialObject DE17Landmark DE9 Active Reference Controller DE18

Landmark InContext DE10 Active Reference DE19

Landmark set-based navigation DE11 Presentation Object DE20

Landmark Active reference DE12

Table 6: List of Design entities with their IDs

Figure 7: Dependency graph-Backward tracing for dependency analysis

3.3.3 Step#3: Perform architectural changesThe design entities identified (as EIS) in step#2 are implemented by specifically making changes to thedesign entities at architecture design representation- in the case study the impacted design entities are thedesign entities of design specification as shown in figure 3a and 3b. Making changes to design entitiesvalidates 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 impactsets 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 bymaking changes for each design entities (from EIS) at architecture design and then examine other designentities in architecture design that possibility got affected by making those changes. Similarly, FPIS can bedetermined by examining those design entities (from EIS) that do not require any modification when thechanges made to architecture design. It means that FPIS are those design entities which are the over-estimation form the set of EIS.

The output of enactment of CIA process model is Actual Impact Set (AIS) that is the set of design entityactually 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, thesenull sets also indicate the accuracy of EIS as determined in step#2. Finally, AIS can be presented as below.

Legends:

DE = Design EntityDependency relationship with

dependency name

non-dependency relationship

DE4

DE7

DE8

DE13DE9

DE15

DE17

DE14

DE11

DE16

have pointer

generate by

explore

navigate

specify

get parameter

DE18

DE19

DE20

get currentpositionpresent

specify

present

specify

DE6

define

DE10

define

DE12

implement

DE3

reference to


13/14



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 architecturedesign resulting from business processes changes. Additionally, we have also employed design rules anddesign constraints, retrieved from design decision repository.

4 CONCLUSIONSIn this paper we have presented a process model of CIA that provides the necessary components forsystematically and rigorously incorporating the notion of DDs during CIA and thus supports for an earlyidentification of change impacts in Web systems. We have considered design decisions and theirunderlying information (design rules and design constraints) to be important during impact analysis. This ismainly true due to the reason that both design rules and design constraints facilitate the discovery ofpossible dependencies among the design entities of an architecture design and thus in turn addressRQ1. Wehave also demonstrate that process model of CIA supports to identify impacts on architecture designresulting from business processes changes- i.e. early identification of change impacts in Web systems. Thisaspect addressesRQ2.

We have illustrated our process model through an example case study, thus providing an initialdemonstration of its feasibility. The dependencies are derived from design rules and then used for impactsidentification, in particular, when the addition or modification of a design entity has consequences to otherrelated design entities at information architecture design. Results from the case study are encouraging as itprovides the ability to understand the dependencies among design entities and thus supports theidentification of impacts on architecture design. Given the paucity of research focus both on earlyidentification of impacts in Web systems and on utilising DDs information such as design rules and designconstraints, we will further improve process model of CIA and will validate it by other case studies in realsettings to demonstrate both its validity and broader usability.

ReferencesAcerbis, 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 InternationalConference 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, IEEEComputer Society Press.

Bosch, J. (2004) Software Architecture: The Next Step.In the Proceedings of First European Workshop onSoftware Architecture. St. Andrew, UK.

Capilla, R., Nava, F., P. Rez, S. & Due, J. C. (2006) A web-based tool for managing architectural designdecisions. SIGSOFT Softw. Eng. Notes, 31, 4.

Ceri, S., Franternali, P. & Bongio, A. (2000) Web Modeling Language (WebML): a modeling language fordesigning 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 ProfessionalGarrido, 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 ComputerSociety.


14/14

EMCIS 2011-Zafar Mehboob

Documents

Transcript of EMCIS 2011-Zafar Mehboob