Mining Patterns to Support Software Architecture Evaluation

Transcription

1 Mining Patterns to Support Software Arhiteture Evaluation Liming Zhu, Muhammad Ali Babar, oss Jeffery National ICT Australia Ltd. and University of New South Wales, Australia {limingz, malibaba, Abstrat In this paper, we present an approah to improve the software arhiteture evaluation proess by systematially extrating and appropriately doumenting arhiteturally signifiant information from software arhiteture and design patterns; we are interested in only two piees of information found in software patterns: general senarios and arhitetural tatis. General senarios distilled from patterns not only assist stakeholders in developing onrete senarios during a senario-based arhiteture evaluation, but an also help an arhitet selet and alibrate a quality attribute reasoning framework. Arhitetural tatis in patterns are used as a means of manipulating independent parameters in the reasoning framework to ahieve the desired quality. Moreover, we believe if we use general senarios and tatis extrated from patterns in an arhitetural evaluation, the results of that evaluation an be used as an evidene to validate the pattern s laim with respet to the quality attributes. We demonstrate our approah by using EJB arhiteture usage patterns. We ontend that this approah an be used to analyze and validate any arhiteture pattern. 1. Introdution Quality is one of the most important issues in software development. The idea of prediting the quality of a software intensive system from a high level design desription originated in Parnas s seminal work on software modularization [1], and has reently emerged as an important quality assurane tehnique known as software arhiteture (SA) evaluation. It has been shown that SA onstrains the ahievement of various quality attributes (suh as performane, seurity, maintainability and usability) in a software intensive system [2]. That is why a number of formal and systemati efforts are onentrated on ensuring that the quality issues are addressed at the SA level. The priniple objetive of evaluating a SA is to assess the potential of the hosen arhiteture to deliver a system apable of fulfilling required quality requirements and to identify potential risks [3]. A number of methods, suh as Arhiteture Tradeoff Analysis Method (ATAM) [4], Software Arhiteture Analysis Method (SAAM) [5] and Arhiteture-Level Maintainability Analysis (ALMA) [6], have been developed to evaluate the quality related issues at the SA level. Most of these methods are struturally same but there are a number of differenes among their ativities and tehniques [7]. The auray of the results of these methods is largely dependent on the quality of the senarios used for the SA evaluation as these are senario-based methods [8]. An appropriate easoning Framework for a desired quality attribute is also an important element of these methods. The main soures of quality attribute sensitive senarios and reasoning frameworks are the problem domain, quality requirements, existing quality models and stakeholders [8, 9]. It has been laimed that arhitetural patterns are another important soure of quality attribute sensitive senarios [10]. eently, many large and omplex software systems have been developed using arhitetural and design patterns. One of the major purposes of using patterns is to develop software systems that are expeted to provide the desired level of quality attributes [9]. Patterns are doumented in a variation of Alexander or Gang Of Four (GOF) styles [11, 12], whih require the inlusion of problem, solution, quality onsequenes parts. We observed that quality attribute sensitive senarios and other arhitetural related information are embedded in a pattern desription. For example, the problem part ontains the senarios addressed by the patterns, arhitetural tatis and design deisions an be found in the solution part, and quality attribute analysis is provided in the quality onsequenes setion. We believe that this invaluable information an be extrated and systematially doumented to support the SA evaluation proess. Another important issue this paper examines is the lak of rigorous validation of the published patterns. Though patterns have been very popular sine early 90s, they have been often ritiized for lak of systemati and rigorous validation of their benefits [13]. The patterns ommunity has proposed a few solutions to address this issue, e.g., validation through experiments [13], or in anedotal form from pratitioners [14]. However, suessful design with patterns largely relies on the experiene of the patterns user. Sine the benefits a pattern laims to offer are ahieved by the tatis used in that pattern, we believe that one an rigorously validate a pattern by identifying the independent parameter a pattern s tati is manipulating and using an appropriate reasoning

2 framework. In order to aumulate the evidene from arhiteture evaluation for pattern validation, we need to guarantee at least two things: 1) The onrete senarios we are using in the evaluation must be instanes of the general senarios extrated from the pattern, to ensure that we evaluate the pattern against the problem that pattern laims to solve. 2) The parameters that the pattern s tatis are manipulating must be part of the independent parameters of the quality-attribute reasoning framework, to ensure that the tati is ahieving the benefit the pattern laims to provide. This paper shows that the information we have extrated from patterns satisfies these two onditions. This paper makes two signifiant ontributions to arhiteture evaluation disipline. First, it presents our approah to distill quality attribute sensitive senarios, arhitetural tatis and other arhiteture related information from patterns to support the senario-based SA evaluation. Seond, the paper presents a way of rigorously validating a pattern s benefits. We begin by disussing the importane of SA evaluation for quality attributes and the role of general senarios and reasoning frameworks in performing arhitetural evaluation. We then present our assertion that arhitetural patterns are an important soure of quality attribute sensitive senarios and other arhitetural information. We demonstrate our approah by extrating a number of piees of arhiteturally vital information from well know software patterns. We illustrate the pratial appliability of our approah with an example. We lose by mentioning the limitations of this work and identifying areas of future work. 2. Bakground and Motivation 2.1 Quality attributes and software arhiteture evaluation A quality attribute is a non-funtional requirement of a software system, e.g., reliability, modifiability, performane, usability and so forth. Aording to [15], software quality is the degree to whih the software possesses a desired ombination of attributes. There are a number of lassifiations of quality attributes. In [16], MCall listed a number of lassifiations of quality attributes developed by a number of software engineering researhers inluding himself. A later lassifiation of software quality is provided in [17]. Quality attributes of large software intensive systems are usually determined by the system s SA. During reent years, it has been widely reognized that quality attributes (suh as maintainability, reliability, usability, performane, flexibility et.) of omplex software intensive systems depend more on the overall SA of suh systems than on other fators suh as platform and framework seletion, language hoie, detailed design deisions, algorithms, data strutures, and so forth [2]. Sine SA plays a vital role in ahieving system wide quality attributes, it is very important to evaluate a system s arhiteture with regard to desired quality requirements as early as possible. The priniple objetive of SA evaluation is to assess the potential of the hosen arhiteture to deliver a system apable of fulfilling required quality requirements and to identify any potential risks [3]. Additionally, it is quiker and less expensive to detet and fix design errors during the initial stages of the software development. A number of methods and tehniques have been applied to ensure that the quality onerns are addressed at the arhiteture level. Senario-based SA evaluation methods suh as ATAM, SAAM, and ALMA, are onsidered relatively mature and established as they have been widely applied and more rigorously validated in various domains [7]. Figure 1 shows a generi proess of senario-based SA evaluation. The desired quality attributes, their assoiated reasoning frameworks and relevant onrete senarios are important inputs, an evaluation report is the output. Quality Attribute easoning Framework Conrete Senarios for Quality Attribute Evaluation Method Evaluation results Figure 1: Important inputs and outputs of software arhiteture evaluation proess 2.2 Using senarios for software arhiteture evaluation Abowd et. al. [18] proposed two broad ategories of SA evaluation: questioning tehniques, whih fous on qualitative analysis; and measurement approahes, whih are quantitative in nature. The former ategory inludes tehniques like senarios, questionnaires, and heklists. The latter ategory onsists of metris and simulation. Most of the mature and established arhitetural evaluation methods are senario-based. Senarios have been used for a long time in several areas of different disiplines (military and business strategy, deision making,). The software engineering ommunity started using senarios in user-interfae engineering, requirements eliitation, performane modelling and more reently in SA evaluation [19]. Senarios are quite effetive for SA evaluation beause they are very flexible; senarios are used for evaluating most of the quality attributes. For example, we an use senarios that represent failure to examine availability and reliability, senarios that represent hange requests to analyze modifiability, senarios that represent threats to analyze seurity, or senarios that represent ease of use to analyze usability. Moreover,

3 senarios are normally very onrete, enabling the user to understand their detailed effet [20]. The SA ommunity has developed different frameworks for eliiting, struturing and lassifying senarios. For example, Nio Lassing et. al. [21] proposed a two dimensional framework to eliit hange senarios, ik Kazman et. al. [22] proposed a generi 3 dimensional matrix to eliit and doument senarios. Len Bass et. al. [2] provided a six elements framework to struture senarios. Senarios used in arhiteture evaluation are also lassified into various ategories, e.g., diret senarios, indiret senarios, omplex senarios, use ase senarios, growth senarios, exploratory senarios and so forth [2, 5, 21]. Elements Brief Desription Stimulus A ondition that needs to be onsidered when it arrives at a system esponse The ativity undertaken after the arrival of the stimulus Soure of An entity (human, system, or any Stimulus atuator) that generates the stimulus Environment A system s ondition when a stimulus ours, e.g, overloaded, running et. Stimulated Artifat Some artifat that is stimulated; may be the whole system or a part of it. esponse measure The response to the stimulus should be measurable in some fashion so that the requirement an be tested. Table 1: Six elements senario generation framework [9] We will use the senario generation framework shown in Table 1 to struture the senarios distilled from software patterns. This framework provides a relatively rigorous and systemati approah to apture and doument general senarios, whih an be used to develop onrete senarios and to selet an appropriate reasoning framework to evaluate SA. 2.3 ole of a reasoning framework in software arhiteture evaluation Most of the senario-based SA evaluation methods use informal reasoning (suh as impat analysis or walkthroughs) for analyzing the design deisions with respet to the desired quality attributes. Suh informal approahes may not be suffiient to reliably analyze ertain quality attribute, e.g. performane, availability et. A solution to this issue is to make and evaluate arhitetural design deisions by developing appropriate quality attribute models. In this respet, senario-based SA evaluation methods developers and users an borrow a number of tehniques from Predition Enabled Component Tehnology (PECT) [23]. PECT is a systemati approah that applies quantitative reasoning framework and appliation speifi information to predit the quality of omponent assembly. SA design deisions are usually based on a quality attribute model (suh as a sheduling model), whih is an instane of a quality attribute reasoning framework. A reasoning framework provides the voabulary and analytial mahinery for desribing and deduing partiular system properties. Quality attribute reasoning framework onsists of a set of independent and dependent parameters and their relationships [9]. The relationship between a reasoning framework, its independent and dependent variables and quality model, an instane of the reasoning framework, is shown in Figure 3. Dependant Parameters Quality Attribute easoning Framework Instane of Quality Attribute Model Independent Parameters Figure 2: elationship between quality attribute reasoning framework, its parameters and quality attribute model We believe that the results of senario-based arhiteture evaluation will be more reliable if an appropriate reasoning framework is used to analyze arhitetural design deisions with respet to the desired quality attributes. Quality attribute sensitive general senarios an help the arhitet or evaluator selet an appropriate reasoning framework. A general senario ontains quality attribute parameters that an identify one or more quality-attribute-reasoning frameworks [9]. If general senarios for a SA evaluation have been strutured aording to the framework desribed in the previous setion, suh senarios will have stimulus and response measures. The stimulus of a senario an be treated as an independent parameter, while the response measures an be onsidered as dependent parameters. The theory of why manipulating independent parameter hanges the value of the dependent parameter an explain the relationship in the quality model. 3. Skeleton of elationships between patterns, tatis, evaluation and pattern validation In this setion, we present our assertion that software patterns are an important soure of arhitetural related information that should be systematially aptured and appropriately doumented to improve the SA design and analysis proesses. Moreover, we laim that the results of arhiteture evaluation may help rigorously validate the patterns used in that arhiteture. Figure 3 presents the relationships between patterns, arhitetural tatis, arhiteture evaluation and patterns validation.

4 Patterns are a vital means of designing SAs of large omplex systems. One of the major objetives of using patterns is to develop a software system with preditable non-funtional properties [12]. Eah pattern helps ahieve one or more quality attribute in a system; however, eah of them may also hinder other quality attributes. In pattern-oriented design, an arhitet develops a desirable SA by omposing a number of arhitetural patterns and tatis. The format of a pattern s doumentation requires the inlusion of problem, solution and quality onsequenes. Thus, eah doumented pattern has information on the desription of the senarios that haraterize the quality attributes ahieved by the pattern and assoiated quality onsequenes. Figure 3: A skeleton of relationship between patterns, tatis, evaluation and pattern validation These are the vital piees of information required to perform SA evaluation. However, the existing format of pattern doumentation does not make suh information readily available to the arhitet and evaluators. This may be the reason that the SA evaluation does not usually use the information within the patterns. There is a need to provide omplementary or alternative tehniques to develop senarios for SA evaluation and there is huge amount of information impliitly hidden in pattern desriptions, we ontend that we an greatly improve the SA design and evaluation proess by extrating and appropriately doumenting the quality attribute speifi information from the patterns. The availability of general senarios extrated from the patterns that promise to deliver the desired quality attributes during arhiteture design an help an arhitet to preisely artiulate the quality requirements and ensure the quality requirements are omplete [9]. From our point of view, the more important thing is the potential benefits of the extrated information to the arhiteture evaluation proess. Most of the senario-based SA evaluation methods require the stakeholders to generate senarios to evaluate the arhiteture. We argue that if the general senarios that haraterize the quality attributes satisfied by the patterns used in the SA are available to the stakeholders, it will improve SA evaluation and redue the time and resoures required to generate senarios from srath for eah SA effort. Moreover, those general senarios an also help the arhitet to selet an appropriate reasoning framework to perform a more rigorous analysis of the arhitetural deisions with respet to the desired quality attributes. Additionally, the results of arhiteture evaluation an aumulate the evidene to either validate or rejet a pattern s laim of providing ertain quality attributes. Let us larify the onepts presented above with an example of a performane general senario for EJB framework. Following is a performane sensitive general senario extrated from a pattern named Data Transfer Objet [24] using the framework desribed in Table 1. A large number of requests on an individual data entity attribute (stimulus) from a user interfae (soure of the stimulus) arrive at the system under normal ondition (environment). The system (stimulated artifat) has to transfer the data (response) within a ertain amount of time (response measure). The stimulus in this senario suggests an event is arriving in some rate whih may have some aspets of harateristis in terms of arrival distribution, number of event streams et. All the aspets an be onsidered as independent parameters. The required measure of response is a hard-deadline response time, whih is a dependent parameter. This information should help an arhiteture evaluator selet an appropriate reasoning framework, whih is a sheduling theory in this ase. The hosen reasoning framework may provide some more independent parameters and an be alibrated into a quality model. During arhiteture evaluation, an arhitet an study how various arhitetural tatis an manipulate those independent parameters to ahieve the desired quality attributes. 4. Extrating senarios and tatis from patterns In this setion, we demonstrate the appliability of the theoretial onepts underpinning our researh into mining software patterns for arhiteture evaluation and pattern validation. We present the arhiteturally signifiant senarios and tatis extrated from well know software patterns. To improve readability and understandability, we doument the extrated senarios and tatis using struturing formats ommonly used in SA disipline.

5 Figure 4: A diagrammati view of a pattern The proess of distilling arhiteture sensitive information from pattern is impliit in the desription beause proess issues are not within the sope of this paper. Figure 4 presents a diagrammati view of the various parts that must be inluded in the pattern doumentation and different types of the information that we an extrat from a pattern. We use this diagram as a guide to the pattern mining proess. 4.1 Distilling general senarios from patterns In this setion, we show a few general senarios extrated from known arhitetural patterns of Enterprise Java Bean (EJB) used in enterprise appliations [24]. We have already stated and Figure 4 shows whih part of a pattern ontains what kind of information. Senarios are desribed mostly in the problem element. While the quality attributes supported by the pattern are shown in the quality onsequene part. Information on the relevant quality attributes is not usually presented in the early part of the pattern; espeially quality attributes being negatively affeted. We have extrated the quality attribute sensitive senarios using a senario development framework proposed in [9]. Stimulus, soure of stimulus and environment an be found in the problem part of the investigated pattern. esponse and stimulated artifat are ommonly enountered in the solution part of the pattern. Explanations of the purpose of different parts within a pattern will reveal the stimulated artifat and expeted response of the system. esponse measures are usually pervasive, espeially in the quality onsequene part of a pattern s doumentation. We illustrate the onept by extrating a senario from Data Mapper pattern [24]. The extrated senario is: A periodi data struture hange request from stakeholders arrives when data use ase hanges. The system has to be modifiable aording to the data struture hange request within ertain sope under ertain time and maintenane ost. Elements General Senarios Soure Stakeholders Stimulus A periodi data struture hange request Environment Normal ondition Artifat System esponse Modify esponse Measure Certain time and maintenane ost Table 2: Senario 1 Similar general senarios an also be extrated from Diret Aess to Entity Bean, Data Transfer Objet, Domain Data Transfer Objet, Custom Data Transfer Objet and Hash Fatory [24]. However, not every extrated senarios will fous on positive quality onsequenes. We an also extrat senarios by looking at negative quality onsequenes of a pattern and unexpeted stimulus. The other senario has been extrated from the Data Transfer Objet [24] pattern on data transfer performane: A large number of data requests from an independent soure arrive at the system under normal ondition. The system has to transfer the data within a ertain amount of time. Elements General Senarios Soure Independent soure Stimulus A large number of data requests Environment Normal ondition Artifat System esponse Transfer the data esponse Measure Within ertain amount of time Table 3: Senario 2 Similar senarios an be extrated from States Holder, Value Objet, Detailed Objet [24]. Both of the examples of senario extration from the arhitetural patterns are very high-level general senarios. Patterns also ontain rih ontext sensitive information, whih an be used to refine the oarsegrained general senarios into more fine-grained one. For example, by integrating the available ontextual information, the performane general senario an be refined into the following senario: A large number of requests on an individual data entity attribute from a user interfae arrive at the system under normal ondition. The system has to transfer the data within a ertain amount of time without generating too many network alls However, this senario is still quite general. In order to make the general senarios diretly usable in SA evaluation, we need to onvert them into onrete senarios by providing system speifi value for various elements like periodi, large, time and bandwidth et. Elements efined General Senarios Soure User interfae Stimulus A large number of requests on data entity attribute Environment Normal ondition Artifat System esponse Transfer the data esponse Measure Within ertain amount of time Table 4: efined general senario

6 By looking at the stimulus part, we find stimulus like data struture hange request or requests on data entity attribute an indiate some harateristis of the independent parameters. However, this information alone may not be suffiient to enable a relatively inexperiened arhitet to analyse arhitetural deisions. Thus, we need to go to the next step of identifying and studying the tatis. 4.2 Distilling arhitetural tatis from patterns We have stated that the general senario extrated from a pattern provides valuable information that an help in seleting a reasoning framework. However, this information may not be suffiient to provide detailed seletion riteria. Arhitetural tatis used in a pattern an also be very useful in the seletion proess. The solution and quality onsequene parts of a pattern s doumentation desribe the tatis used in that pattern. Arhitetural tatis are doumented in terms of manipulating some aspet of independent variables to ahieve the target quality attribute. Thus, tatis used in a pattern provide more tangible information on the detailed aspets of parameters that an be manipulated to ahieve the desired results. Moreover, the solution and quality onsequene parts also provide qualitative lues about the reasoning framework that is more suitable to the pattern. For example, a Fatory intermediary tati is introdued in the DTOFatory (Data Transfer Objet Fatory) pattern to isolate and loalize the hange. This tati may be seen as an explanation for a modifiability impat analysis reasoning framework. The SA ommunity has started doumenting various tatis used in different patterns. Bass et. al. [9] doumented various tatis in a hierarhial form. We have used that hierarhy to extrat the tatis reported here. Let us use an example from EJB usage pattern to illustrate the proess of extrating general senario and the tatis and seleting a reasoning framework. DTOFatory is frequently used in enterprise appliation to balane both performane and modifiability attributes. We have extrated two main general senarios by looking into the problem, solution and onsequene parts of the pattern. General Senario 1: A large amount of lients need to aess server side objet (stimulus). The server has to serve the data within ertain response time (response measure). General Senario 2: Frequent domain onept hanges require hanges to Data Transfer Objet (stimulus). The system has to be modified under ertain time and maintenane ost (response measure). The dependant variables we are interested in are modifiability in terms of effort and performane in terms of response time. Two stimuli here give valuable information to the independent parameters of the quality model but not in a very detailed fashion. However, we an get more information on the possible independent parameters by identifying tatis used in this pattern and the parameters being manipulated by those tatis. Following are the two tatis extrated from this pattern. Tati 1: Independent Tatis Parameters Number of equests Manage demand by: Managing event rate (edue request rate by bulk request) Table 4: Tati 1 This tati is used in this pattern based on the assumption that network alls on the remote interfae of an entity bean have severe performane burden on the server, whih will affet the response time; and the number of alls generated on remote interfae per unit of time an be redued by putting a olletion of data into a single Data Transfer Objet. This is learly one way of managing demand by managing event rate. However, pakaging data into large transfer objet will inrease the amount of data transferred if requests are not aligned with the pakaged data. A reasoning framework based on the number of requests and response time should be seleted to evaluate the result using the onrete senarios, whih are the instanes of the general senario extrated from DTOFatory pattern. The result of this evaluation may also help validate the benefit of the DTOFatory pattern. Tati 2: Independent Tatis Parameters Number of primary omponents affeted Loalize expeted modifiation by: Limiting hange options Isolating expeted hanges Maintaining semanti oherene Table 5: Tati 2 Table 5 shows the seond tati extrated from the pattern, whih is other appliation of a loalize expeted modifiation tati. When a hange request on the Data Transfer Objet happens, modifiation should be loal with minimum number of ripple effets. By introduing an intermediary, the hange is limited in the fatory method without affeting both the lient and the entity bean (limit hange options and isolate expeted hanges). In the meantime, semanti hange on the lient request should not hange the server side semanti. By using the intermediary fatory method, server side semantis oherene will be proteted (maintain semanti oherene). It also provides the benefits of avoiding redeployment. The olletion of tatis is used to manipulate the number of primary omponents affeted. The general senario has already indiated the dependent parameters, whih affet maintenane. By assoiating the number of primary omponents affeted and the effort required, we an

7 alibrate the impat analysis model as our reasoning framework. Having demonstrated how to extrat the general senarios and arhitetural tatis from software patterns, let us disuss how the extrated information an help in pattern validation. Deriving onrete senarios from general senarios extrated from the pattern assures us that we are evaluating the pattern with those senarios, whih are instanes of the general senarios the pattern is implementing. If ertain onrete senarios annot be derived from the pattern s general senarios that means the pattern may be not suitable for that problem. Moreover, the independent parameters that the pattern s tatis an manipulate must be part of the quality-attribute reasoning framework to ensure that the tati (not any other fator) is ahieving the benefit that pattern laims to provide. These two rules are utterly important in using the evaluation result as evidene for pattern validation. 5. Proof of onept - An illustrated example In this setion, we use an extended example to illustrate our approah to extrat arhiteturally important information, general senarios and tatis from software patterns to support arhiteture evaluation and to selet and alibrate a reasoning framework and how the results from this analysis an be used to aumulate the evidene to validate the pattern. The proess of seleting and alibrating reasoning framework may vary from one quality attribute to the other depending on the ontext. For example, the proess of hoosing and adjusting a reasoning framework for modifiability impat analysis an be different to the one used for performane quality attribute. In the following setion, we use the arhitetural information extrated from a pattern to selet and alibrate a performane model in Enterprise Java Beans (EJB) ontext using the proess and example presented in [25] by Liu et. al. 5.1 Overview of the proess Liu et. al. [25]has proposed a proess to selet and alibrate performane reasoning framework using arhitetural and appliation speifi information under the PECT framework. Their proess first selets a performane model based on an individual s experiene and then alibrates the hosen model aording to two soures of information: 1) Arhiteture speifi information. This omes from the environment and implementation onstraints. For example, in order to alibrate a performane model for EJB arhiteture, Contain Managed Persistene (CMP), and a find-bynon-primary-keys entity bean needs to be integrated into the model. Arhitetural tatis like ead-only, ahing and session façade also provide some information. 2) Appliation speifi information. This onsists of typially senarios from the appliation domain, e.g. typial online stok trading senarios have a large amount of read-only requests. Figure 5 Having studied the proess model of Liu et. al, we assert that our researh into mining software patterns to extrat senarios and tatis an omplement their proess. Figure 5 shows how the arhitetural information extrated from patterns using our approah an be used in the alibrating proess of Liu et. al. Our laim is based on the assumption that general senarios and arhitetural tatis an provide the information required to alibrate the general model for arhiteturespeifi model. General senarios an be instantiated to generate appliation speifi onrete senarios and alibrate the appliation-speifi model. The performane profile derived from the pattern an be bundled with the pattern as valuable information on pattern use and arhiteture evaluation of the patternbased appliation. By using this approah, we believe arhiteture evaluators an use the qualitative reasoning information found in patterns to help alibrate quantitative attribute models. Even in non-quantitative situation, the information an help adjust the general qualitative model. We an also use this approah to ompare different patterns, that satisfy the same or similar general senarios. 5.2 Pattern Desription The pattern investigated in this example is a M (ead-mostly) pattern of EJB appliation. When there are a large number of read-only requests, an entity bean on the server side an be semantially divided into a read-only bean and a write-only bean. By using ahing on the read-only bean, if a read request hits the ahe, a data soure aess is avoided. We an ahieve better performane by using the M pattern. We an use this pattern desription along with the extration tehniques and extrated information struturing tehniques desribed earlier to demonstrate our approah to mining software patterns to improve the SA evaluation proess and aumulate evidene to validate the M pattern.

8 Following is the desription of the four steps along with the examples of our approah. Step 1 Extrat senarios from M pattern By using the six element framework for struturing senarios, we have extrated the following general senario from The M pattern used in the example appliation. The onstituent parts of the senario are shown in table 4. Here is the desription of the senario: A large number of lient (stimulus soure) requests, mostly read-only requests (stimulus) arrive at the server at normal ondition (environment), the server (artifat) needs to proess the requests (response) within ertain response time (response measure). We an use the stimulus (lient request) and the response measure (hard deadline response) parts of the above-mentioned senario and some experiene of lient server environment to identify the need of some sort of queuing model. This an model the server s behavior in proessing a request from a lient as the reasoning framework. However, only this information may not be enough to selet and alibrate the most suitable model. To gather more information, we move onto the next step of extrating tatis from the pattern. Step 2 Extrat tatis from M pattern We an identify two tatis in the M pattern: managing demands by inludes introduing ahing and reduing event rate. The ahing is used for read-only requests. If a orresponding entity bean instane is in the ahe, the ahed item will be returned so the event rate on serialization and synhronization with entity bean an be redued. These events usually have signifiant impat on performane. In an EJB appliation, the time involved in a server replying lient request has two parts: EJB ontainer response time and data soure response time. Container response time inludes T 1 (servie time to synhronize with the database) and T 2 (servie time to aess the entity bean). Data soure response time inludes T find (servie time to find the data), T load (servie time to load the data) and T store (servie time to store the data). By using ahing and reduing the event rate, the number of requests that need resoure intensive ativities an be dereased. This will shorten the total response time for a large number of read-only requests. The identified tatis an manipulate the following parameters: Within the EJB ontainer, redued event rate results in redued need for synhronization with database and the aess entity bean. The parameters, whih an be manipulated, inlude number of requests (1) related to T1 (servie time to synhronize with database) and number of requests (2) related to T2 (servie time to aess the entity bean). Within the data soure, redued rate an redue the servie time to load and store the data. Sine, no matter whether the request is read-only or not, we need time to find the item, the time to find the data is not affeted by the event rate. The parameters whih an be manipulated in this ase, are number of requests (3) related to Tload (servie time to load the data) and number of requests (4) related to Tstore (servie time to store the data). Step 3 - Selet and alibrate reasoning framework Having gathered the information based on the abovementioned senarios and tatis, an arhitet will be more onfident in alibrating a QNM (queuing network model) as an appropriate quality-attribute reasoning framework. Taking the onstraints imposed by other design and tehnologial issues, e.g. EJB-speifi information, CMP (Container Managed Persistent) issue, into aount, Liu et. al. [26] has shown how they adjusted the QNM reasoning framework to the response time quality model for ontainer and data soure. Here is their logi to alibrate QNM to response time model: ontainer datasoure = T = T + load 2 + T 2 4 T store + T All the number of requests here an be expressed in terms of ratio of read-only requests (p) and ahe hit rate (h r ): find = ( p + np ) h r + (1 p p ) h = ( p + np )( 1 h r ) + (1 p = 1 p ph r + np (1 h r ) = 1 p p p )( 1 h ) 1, 2, 3, 4 are independent parameters as mentioned above. The introdution of h r and p in the equation and their lear manipulation on the independent parameters has refleted the tatis on managing demands in this pattern. During arhiteture evaluation, we an test ratio of read-only requests and hit ratio regarding their relationship with the response time to verify whether this arhiteture satisfies the requirements and the tatis ontribute to ahieve the desired response time whih is the benefit laimed by the pattern used in the arhiteture. Step 4 Aumulate proof to validate the pattern Having extrated senarios and tatis from M pattern and seleted and alibrated a suitable qualityattribute model, we an use this information to evaluate a SA that is using M pattern. The evaluation results an provide some evidene to validate the effetiveness of the pattern. A real world appliation may provide muh stronger evidene. Sine a pattern is an abstrat onept, any onrete implementation of the pattern if evaluated should qualify as evidene. Liu et. al.[26], designed and built a benhmark appliation based on Stok-Online [27], whih uses the M pattern. We will use the appliation as a form of validation of the M pattern. Following is a onrete senario that is an

9 instane of the general senario extrated from the M pattern (reall the two prerequisites of the validation proess mentioned in setion 1): A large number of stok transation related requests (get/set/reate aout/stokholders/stokitems/stoktx, 36/43 of them is read-only request arrives at the server at normal ondition), the server needs to proess the request within ertain response time. The response time is unspeified in the senario beause we are only investigating the onrete senario and we are interested in a wide range of the response times. Thus, it is obvious that the onrete senario is the instane of the general senario satisfied by the pattern. Let us make sure that the seond requirement is also met: tatis must manipulate only those parameters whih belong to the reasoning framework s independent parameters. This is shown in the M pattern response time quality model used in [26] as the tatis and orresponding parameters are learly modeled in the reasoning framework for the response time. We an take approahes to use the result of the arhitetural evaluation as an evidene to validate the pattern: Compare the pattern with a design without using the tatis on managing demands. Manipulate the ahe hit ratio to see the results of response time. Both approahes are valid. Liu et. al.[26] used the first approah in order to ompare two designs; the seond happens to be the one without using the tatis. They used the proess of evaluating arhiteture for performane quality attribute. The result of their evaluation shows that the ontribution of tatis in the pattern is very signifiant. Considering the fat that we are evaluating against onrete senarios derived from general senario extrated from the pattern, the result an be onsidered as the validation of the pattern. In this extended example, we have disseted a performane modeling work done within the PECT framework aording to demonstrate the pratial appliation of our approah to distill general senarios and arhitetural tatis from a pattern. The extrated information an help selet and alibrate a general performane reasoning framework the QNM model. Then, the extrated general senario an be used to develop onrete senario for the arhiteture to be evaluated. These two steps failitate the arhiteture evaluation proess whih requires onrete senarios and reasoning framework. Sine the parameters being manipulated by the tati are the independent parameters of the reasoning framework, we an laim that the arhiteture evaluation results validate the benefits of using M pattern as asserted by the pattern doumentation. 6. Future work and Conlusions 6.1 Future work This paper reports our initial work on improving SA evaluation ativities for pattern-oriented systems by extrating and doumenting the arhiteturally ritial information from well known software patterns. We are developing a rigorous and systemati approah to identify and apture any piee of information, i.e. senarios, tatis, et., that an be useful during the arhiteture design or evaluation. The work reported in this paper annot be desribed as omplete in its urrent form as there are a number of things that need to be done before the users, i.e. arhitets/designers/sa evaluators, of our approah an experiene signifiant benefits in terms of redued arhiteture evaluation time, improved onfidene in using patterns to ompose arhiteture for desired quality attributes, ease of omparing patterns and so on. In the short term, we plan following tasks to refine and validate our approah: To validate the usefulness and generality of our approah by applying it to various appliations and quality attributes models. To develop a quantifiable means of showing benefits of using it. To develop a reusable repository of the general senarios and tatis for well-known patterns. To expand our approah into evidene-based empirial software engineering by providing a systemati way of validating design patterns. 6.2 Conlusions In this paper we present an approah to mine software patterns for extrating arhiteturally signifiant information to support SA evaluation. We assert that software patterns are a vital soure of arhitetural information, whih an be systematially extrated and appropriately doumented to support and improve SA evaluation proess. We base our laim on our investigation into the relationship between arhitetural patterns, software quality attributes, and senario-based SA evaluation approahes. We argue that general senarios and arhitetural tatis extrated from software patterns an be used as a useful input to arhiteture evaluation and reasoning framework seletion and alibration proesses. Moreover, we believe that the arhiteture evaluation results may provide an evidene of pattern validation. Our main onlusion is that the existing usage of patterns in software engineering does not utilize the large amount of arhitetural information impliitly embedded in them. Patterns are mainly used to ompose arhitetures for omplex and large systems. One of the reasons for using patterns is the widely aepted belief that they help satisfy various quality attributes requirements. An arhitet or SA evaluator needs to ome up with the senarios that an preisely haraterize the required quality attributes and then try to identify those patterns whih promise to satisfy those senarios. We ontend that this is a quite time onsuming and expensive proess. We assert that if

10 patterns are doumented along with the senarios they satisfy and the tatis whih ontribute to the benefits provided by a pattern, the arhiteture design and evaluation proess an greatly be improved. Given our use of general senarios and arhitetural tatis along with the independent variables that an be manipulated by the tatis in arhiteture design and analysis proess, we also onlude that the information extrated from the patterns an help an arhitet selet and alibrate the most suitable quality-attribute reasoning framework. We use only those onrete senarios that are instanes of the general senarios extrated from the pattern. Moreover, the parameters manipulated by the pattern s tatis are the independent parameters of the reasoning framework of the quality attributes to be satisfied by the pattern. We further onlude that the results of the evaluation of that pattern may be used to rigorously validate the pattern. Our major researh objet is to improve the proess of SA design and evaluation by gathering and doumenting arhitetural information in a format that is readily useful in making design deisions with an informed knowledge of the onsequenes of those deisions. Espeially we want to redue the time, resoures and skill level required to effetively and effiiently evaluate a system s SA with respet to various quality attribute models. We believe that mining software patterns to distill and doument SA sensitive information is one of the most important steps towards that goal. 7. eferenes [1] D. L. Parnas, "On the Criteria To Be Used in Deomposing Systems into Modules," Communiation of the ACM, vol. 15, pp , [2] L. Bass, P. Clements, and. Kazman, Software Arhiteture in Pratie, 2 ed: Addison-Wesley, [3] N. Lassing, D. ijsenbrij, and H. v. Vliet, "The goal of software arhiteture analysis: Confidene building or risk assessment," First BeNeLux onferene on software arhiteture, [4]. Kazman, M. Barbai, M. Klein, and S. J. Carriere, "Experiene with Performing Arhiteture Tradoff Analysis," 21th International Conferene on Software Engineering, New York, USA, [5]. Kazman, L. Bass, G. Abowd, and M. Webb, "SAAM: A Method for Analyzing the Properties of Software Arhitetures," Proeedings of the 16th International Conferene on Software Engineering, [6] N. Lassing, P. Bengtsson, J. Bosh, and H. V. Vliet, "Experiene with ALMA: Arhiteture-Level Modifiability Analysis," Journal of Systems and Software, vol. 61, pp , [7] M. Ali-Babar, L. Zhu, and. Jeffery, "A Framework for Classifying and Comparing Software Arhiteture Evaluation Methods," Australian Software Engineering Conferene, Melbourne, [8] P. Bengtsson and J. Bosh, "An Experiment on Creating Senario Profiles for Software Change," University of Karlskrona/onneby, Sweden HK--ES-99/6-SE, [9] L. Bass, F. Bahmann, and M. Klein, "Deriving Arhitetural Tatis-A Step toward Methodial Arhitetural Design," Software Engineering Institute, Carnegie Mellon University CMU/SEI-2003-T-004, [10] L. Zhu, M. Ali Babar, and. Jeffery, "Distilling Senarios from Patterns for Software Arhiteture Evaluation," First European Workshop on Software Arhiteture, [11] E. Gamma,. Helm,. Johnson, and J. Vlissides, Design Patterns-Elements of eusable Objet-Oriented Software. eading, MA: Addison-Wesley, [12] F. Bushmann, Pattern-oriented software arhiteture : a system of patterns. Chihester ; New York: Wiley, [13] L. Prehelt, B. Unger, W. F. Tihy, P. Brossler, and L. G. Votta, "A ontrolled experiment in maintenane: omparing design patterns to simpler solutions," Software Engineering, IEEE Transations on, vol. 27, pp , [14] K. Bek, J. O. Coplien,. Croker, L. Dominik, G. Meszaros, F. Paulishh, and J. Vlissides, "Industrial Experiene with Design Patterns," 18th International Conferene on Software Engineering, Berlin, Germany, [15] IEEE Standar , Standard for Software Quality Metris Methodology. New York: Institute of Eletrial and Eletroni Engineers, [16] J. A. MCall, "Quality Fators," in Enylopedia of Software Engineering, vol. 2, J. J. Mariniak, Ed. New York, U.S.A.: John Wiley, 1994, pp [17] ISO/IEC, Information tehnology - Software produt quality: Quality model, ISO/IEC FDIS :2000(E). [18] G. Abowd, L. Bass, P. Clements,. Kazman, L. Northrop, and A. Zaremski, "eommanded Best Industrial Pratie for Software Arhiteture Evaluation," Software Engineering Institute, Carnegie Mellon University CMU/SEI- 96-T-025, [19]. Kazman, G. Abowd, L. Bass, and P. Clements, "Senario-Based Analysis of Software Arhiteture," IEEE Software, Nov [20] N. Lassing, D. ijsenbrij, and H. v. Vliet, "How Well an we Predit Changes at Arhiteture Design Time?," Journal of Systems and Software, vol. 65, pp , [21] N. Lassing, D. ijsenbrij, and H. v. Vliet, "On Software Arhiteture Analysis of Flexibility, Complexity of Changes: Size isn't Everything," 2nd Nordi Software Arhiteture Workshop, [22]. Kazman, S. J. Carriere, and S. G. Woods, "Toward a Disipline of Senario-based Arhitetural Engineering," Annals of Software Engineering, Kluwer Aademi Publishers, vol. 9, [23] K. Wallnau, "Volume III: A Tehnology for Preditable Assembly from Certifiable Components," Software Engineering Institute, Carnegie Mellon University CMU/SEI T-009, [24] F. Marinesu, EJB design patterns : advaned patterns, proesses, and idioms. New York: John Wiley, [25] Y. Liu, A. Fekete, and I. Gorton, "Prediting the performane of middleware-based appliations at the design level," Fourth International Workshop on Software and Performane (WOSP 2004), edwood City, California, USA, [26] Y. Liu, A. Fekete, and I. Gorton, "Design Level Performane Modeling of Component-based Appliations," Shool of Information Tehnologies, University of Sydney T543, [27] I. Gorton, Enterprise Transation Proessing Systems: Putting the COBA OTS, Enina++ and OrbixOTM to Work: Addison-Wesley, 2000.