Available online at www.sciencedirect.com The Journal of Systems and Software 81 (2008) 37–55 www.elsevier.com/locate/jss DRAMA: A framework for domain requirements analysis and modeling architectures in software product lines q a,* Jintae Kim , Sooyong Park b, Vijayan Sugumaran c a Telecommunication R&D Center, Samsung Electronics, Metan-dong, Suwon, Gyeonggi Province, Republic of Korea b Department of Computer Science, Sogang University, Sinsu-Dong, Mapo-gu, Seoul 121-742, Republic of Korea c Department of Decision and Information Sciences, School of Business Administration, Oakland University, Rochester, MI 48309, USA Received 17 May 2006; received in revised form 5 April 2007; accepted 5 April 2007 Available online 19 April 2007 Abstract One of the beneﬁts of software product line approach is to improve time-to-market. The changes in market needs cause software requirements to be ﬂexible in product lines. Whenever software requirements are changed, software architecture should be evolved to correspond with them. Therefore, domain architecture should be designed based on domain requirements. It is essential that there is traceability between requirements and architecture, and that the structure of architecture is derived from quality requirements. The purpose of this paper is to provide a framework for modeling domain architecture based on domain requirements within product lines. In particular, we focus on the traceable relationship between requirements and architectural structures. Our framework consists of processes, methods, and a supporting tool. It uses four basic concepts, namely, goal based domain requirements analysis, Analytical Hierarchy Process, Matrix technique, and architecture styles. Our approach is illustrated using HIS (Home Integration System) product line. Finally, industrial examples are used to validate DRAMA. Ó 2007 Elsevier Inc. All rights reserved. Keywords: Domain requirements; Domain architecture; Traceability; Quality attribute 1. Introduction Several questions arise in this context: How can we analyze domain requirements for modeling domain archi- In software product lines, a critical success factor is tecture? How can we design domain architecture corre- often time-to-market (Pohl, 1998). In typical software sponding to domain requirements? How can we assure development, whenever market needs change, a new prod- that domain architecture can be reconﬁgured according uct is developed to correspond to them. The frequent to changing requirements? The core answer to all these changes in market needs necessitate software requirements questions relies on the traceability between domain require- to be ﬂexible and changeable in product lines. The domain ments and domain architecture. architecture should also be evolved to correspond to mar- Traceability relates to documenting the relationships ket changes because it emphasizes software reuse among between layers of information, for instance, between several closely related applications in a product line domain requirements and domain architecture (Dick, (O’Brien and Smith, 2002). Therefore, domain architecture 2005). Dick argues that traceability has the following two should be designed based on domain requirements. beneﬁts (Dick, 2005): q This research was supported by University IT Research Center (ITRC) (a) Increased understanding of design. Traceability project, South Korea. * Corresponding author. answers such questions as ‘‘How does the system meet E-mail addresses: firstname.lastname@example.org (J. Kim), sypark@sogang. customer requirements?’’ ‘‘What is this component’s ac.kr (S. Park), email@example.com (V. Sugumaran). role?’’ ‘‘What are the system requirements associated 0164-1212/$ - see front matter Ó 2007 Elsevier Inc. All rights reserved. doi:10.1016/j.jss.2007.04.011 38 J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 with this step?’’ Documenting these relationships vides how to analyze domain requirements, how engenders greater reﬂection by the subjects. to identify components and how to construct the (b) Semi-automated impact analysis. Appropriate tool strategy for architecture modeling. Thus, change in support for representing traceability relationships domain requirements that cause domain architec- can make automated analysis of those relationships ture to be reconﬁgured can be handled through possible. DRAMA. (2) Quantitative analysis. Since software architecture Prior research has addressed the relationship between reﬂects quality attributes of the system, DRAMA requirements and architecture. Kazman et al. (2005) for elicits quality attributes quantitatively. From the instance, proposed the WinCBAM framework, extending quantiﬁed quality attributes, we can decide which an architecture design method, called cost beneﬁt analysis architecture styles can be adopted for domain archi- (CBAM) framework to include an explicit requirements tecture through DRAMA. negotiation component based on the WinWin methodol- (3) Semi-automated tool support. The DRAMA tool sup- ogy. They proposed a conceptual framework, not a con- ports the whole process and helps analyze domain crete process to be implemented by the industry. requirements graphically. It can compute the impor- Svahnberg et al. (2003) proposed a decision-support tance of quality attributes quantitatively and recom- method to understand diﬀerent architecture candidates mend feasible architecture styles. The DRAMA tool for a software system. Their method is adaptable with enables us to maintain the traceability between respect to both the set of potential architecture candidates domain requirements and domain architecture. and quality attributes relevant for the system’s domain. Thus, domain architecture can be reconﬁgured to However, their method does not support domain architec- correspond to the changes in requirements. ture for a product family. It is focused on the product architecture of a single product. Kang et al. (1998) pro- The remainder of this paper is organized as follows: posed a well deﬁned framework for supporting feature Section 2 describes the basic concepts used in DRAMA. oriented reuse method (FORM). FORM is extended from Section 3 illustrates each process within DRAMA using FODA (Kang et al., 1990), popularly used in academia and HIS (Home Integration System) and the tool that fully sup- industry for domain analysis. FORM supports the devel- ports our methodology. Section 4 discusses the preliminary opment of reusable architectures and components and the validation of the methodology and tool. Section 5 com- development of applications using the domain artifacts pares prior approaches and evaluates them with respect produced from domain engineering. Since FORM does to DRAMA. The ﬁnal section provides the summary and not support relationships between requirements and archi- future work. tecture, it is not easy to recognize how architecture evolves when requirements are changed. 2. Basic concepts in DRAMA This research focuses on how to analyze domain requirements for domain architecture and how to model This section discusses basic concepts used in DRAMA. domain architecture based on domain requirements. Thus, As mentioned in the previous section, DRAMA supports we concentrate on domain requirements among many fac- domain requirements analysis and domain architecture tors that inﬂuence the domain architecture and limit the modeling. In domain requirements analysis, we use goal discussion to domain requirements as input to domain and scenario based analysis technique to elicit, analyze, architecture. We propose a framework, called DRAMA, and construct the domain requirements. Goal and scenario which implements our objectives. DRAMA consists of based analysis is widely used in the industry when require- processes, methods and a supporting tool. The three main ments are gathered initially from users. Thus, goal and sce- characteristics of DRAMA are as follows: nario represent requirements gathered from markets and customers (Kim et al., 2004, 2006). (1) Traceability between domain requirements and domain Domain requirements are processed to analyze quality architecture. Requirements are divided into func- attributes quantitatively through AHP (Analytic Hierarchy tional requirements and non-functional requirements Process) and Matrix technique. AHP compares alternatives (quality requirements). The functional requirements in a stepwise fashion and measures their contribution to the can be mapped to a subsystem or a component in overall objective (Saaty, 1980). AHP is used to quantify the architecture. On the other hand, quality require- functional requirements in terms of components. On the ments cannot be pinpointed to a particular compo- other hand, Matrix technique is used to quantify quality nent, but they impact the system structure and attributes related to each of the components. behavior as a whole (Liu and Mei, 2003). Therefore, In domain architecture modeling, we use architecture requirements should provide the rationale for design- styles. Based on domain requirements, one of the architec- ing the architecture. In other words, requirements ture styles is adopted as a feasible domain architecture, reﬂect how to design elements of the architecture which is then evolved according to the components and and what components are developed. DRAMA pro- quality attributes. J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 39 In order to use the above mentioned concepts in our A goal is achieved by scenarios. When scenarios are generated to approach, we assume that quality attributes similar to the satisfy a goal, they are authored Variant type ones presented in Bass et al. (1998) are used and that the with variant types such as ‘Common’, ‘Alternative’, and architectural styles proposed in POSA (Pattern-Oriented ‘Optional’. Variant points come Common from the relationship between Software Architecture) (Buschmann et al., 1996), SAP goals and scenarios. (Software Architecture in Practice) (Bass et al., 1998), Alternative and the architectures discussed by Shaw and Garlan : Variation point (1996) are also used. The following sections describe in Optional detail the basic concepts used in our methodology. author Goal Scenario 2.1. Goal and scenario based domain requirements analysis yield Fig. 1. The relationship between goals and scenarios. In DRAMA, the purpose of goal and scenario based domain requirements analysis is to identify basic units that make up the architecture, i.e. components. It is an eﬀective may or may not be integrated into the system. This means way to identify requirements in requirements engineering that from a set of optional scenarios, any number of sce- (Kim et al., 2004, 2006, 2004; Rolland et al., 1998). A goal narios can be chosen (from zero to all). Hence, the optional provides the rationale for requirements – a requirement scenarios can be modeled by means of an optional exists because of some underlying goal which provides a relationship. basis for it (Kim et al., 2006; Potts, 1997). Since scenarios Fig. 1 depicts the variation point from the relationship describe real situations, they capture real requirements. between goals and scenarios. In the HIS example, the goal, In the context of a product line, an organization’s high- ‘‘Provide entertainment service to customers’’ can be level business goals drive marketing plans and product achieved in many diﬀerent ways, which are represented as plans, and force products in a product family to have com- scenarios. Scenarios such as ‘‘the HIS provides a movie mon and variant requirements. On the basis of the business service on TV’’, ‘‘the HIS provides electronic games on goals, the characteristics of products are determined, and TV’’, or ‘‘the HIS provide home shopping on TV’’ are possi- the goal provides the rationale for the domain require- ble ways. In these cases, domain experts and analysts ments. Consequently, goal and scenario modeling makes should decide which scenario should be common, alterna- it possible to manage adequately the variations among tive, or optional. This is determined based on the goal pro- products in the product family. In addition, the following viding the rationale for the variations. For example, if the levels in domain requirements are proposed to help the sep- scenario, ‘‘the HIS provides a movie service on TV’’ has a aration of concerns in product line requirements elicitation: common type, it should be involved in all products in the business, service, interaction, and internal level. These product family. If the other scenarios are either alternative levels are abstraction hierarchies. Each of them has its or optional, they can be involved in any product or none. own perspective on separation of concerns in the product Therefore, variation point comes from the relationship line requirements. Goal and scenario modeling is thus used between goals and scenarios. to identify and analyze the domain requirements corre- Goal and scenario modeling is conducted at each sponding to each of the domain requirements level via requirement level, which is extended from Rolland’s initial the proposed template. identiﬁcation of levels (Rolland et al., 1998). Through this The scenarios capture real requirements since they modeling, the domain requirements including common and describe actual situations or concrete behaviors, and goals variant requirements are identiﬁed. Fig. 2 shows the struc- can be achieved through the execution of scenarios. Thus, ture of the goal and scenario modeling process. scenarios have their goals, and typically, the goals are As shown in Fig. 2, the aim of the business level is to achieved by the scenarios. In other words, just as goals identify the ultimate purpose of a product family. At this can help in scenario discovery, the scenarios can also help level, the goal is speciﬁed by the organization or its repre- in goal discovery. As each individual goal is discovered, a sentatives. The business goal is represented as a business scenario can be authored for it. Once a scenario has been strategy or as a business objective. In the HIS example, authored, it is explored to yield goals. In a product line, the business goal ‘‘Become the best provider in HIS market since a goal provides the rationale for variations in domain within 10 years’’ is an ultimate goal of the organization. In requirements, it is used as a discriminator that enables us to general, the business goal represents the directional value identify common and variant requirements. Variant of the organization. requirements (or variation point) are identiﬁed when sce- The service level addresses identifying the product plan narios achieve a goal in two ways; ﬁrst, alternative varia- or marketing plan, recognizing what kinds of products will tion: from a set of alternative scenarios, only one be developed in a product line, and deciding their charac- scenario can be chosen to achieve a goal – deﬁning an teristics. At this level, the domain requirements are repre- exclusive relationship, which means a ‘‘1 from n choice.’’ sented as a pair hG, Sci where G is a service goal and Sc Second is optional variation: optional scenarios for a goal is a service scenario. All the service goals correspond to a 40 J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 given Common Business goal Alternative Optional refined Service Service goal Common author Scenarios Alternative Optional yield Interaction Interaction goal Scenarios Common author Alternative yield Optional Internal Internal goal Scenarios author Fig. 2. The structure of goal and scenario modeling process. given business goal. For example, the service goal ‘‘Provide game’’ is an internal goal. The associated internal scenario high-end products to customers’’ is one possible way of sat- describes the interactions among the system objects to ful- isfying the business goal (the high-end product contains ﬁll this internal goal. For example, ‘‘the entertainment more functions). As another example, the service goal manager connects a main game server on Internet’’ is the ‘‘Provide low-end products to customers’’ is another possi- internal scenario. ble way to achieve the business goal (the low-end product During the goal and scenario modeling process, com- contains fewer functions than the high-end product). mon and variant requirements are identiﬁed. After this Service scenarios describe the ﬂow of services, which are process, a goal tree is generated, and then the components necessary to fulﬁll the service goal. For example, the service are identiﬁed based on the goal tree. Section 3 explains how scenario ‘‘customers get entertainment services through our process can be implemented in the context of the HIS High-end HIS’’ achieves the service goal ‘‘Provide high- example. end products to customers’’. At the service level, goals have corresponding scenarios showing the functions of products 2.2. Analytic Hierarchy Process (AHP) with the variant types such as common, alternative, and optional. The goals are generated from the scenarios at The Analytic Hierarchy Process (AHP) compares alter- the previous level and they author the corresponding natives in a stepwise fashion and measures their contribu- scenarios. tion to an overall objective (Saaty, 1980). In DRAMA, At the interaction level, the focus is on the interactions the purpose of AHP is to calculate the priority of each between the system and its external entities. The domain component and provide the rationale for determining requirements at this level are represented as a pair hG, Sci which component is more important in an objective man- where G is an interaction goal and Sc is an interaction ner. The reason for adopting AHP is that it is a powerful scenario. These interactions are required to achieve the and ﬂexible decision making process to help set priorities services assigned to the system at the service level. For and make the best decision when both qualitative and example, the interaction goal ‘‘Provide entertainment ser- quantitative aspects of a decision need to be considered. vices to our High-end product customers’’ expresses a By reducing complex decisions to a series of one-on-one way of providing a service. The interaction scenario comparisons and synthesizing the results, AHP not only describes the ﬂow of interactions between the system and helps decision makers arrive at the best decision, but also agents. For example, the interaction scenario ‘‘the High- provides a clear rationale that it is the best. After compo- end HIS helps customers to watch TV’’ and ‘‘customers nents are identiﬁed, the priority of each component is cal- can play a video game through High-end HIS’’ can achieve culated through AHP. the interaction goal. In AHP, the number of pairewise comparison is The internal level focuses on what the system should n * (n À 1)/2, which might pose scalability problems. This provide to satisfy the interactions selected at the interaction depends on the size of software and the number of compo- level. At this level, the domain requirements are repre- nents. Although software is complex, if it needs to be devel- sented as a pair hG, Sci where G is an internal goal and oped incrementally or iteratively, we should plan which Sc is an internal scenario. For example, ‘‘operate a video components (or modules) are ﬁrst developed, and compo- J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 41 x is a quality attribute 2.4. Architecture styles the priority of x: P( x) n is the total number of components Software architecture may be explored at diﬀerent levels 1≤ i ≤ n of abstraction. Shaw proposed various structural models called architecture styles, which are commonly used in soft- correlationValue( x, i) = 0,1, 2,or 3 ware and then examined quality attributes related to each style (Shaw and Garlan, 1996). n P( x) = Σ the weight of Component(i) × correlationValue( x, i) Using architecture styles, reference architectures for an 1 application domain or a product line can be built. These Fig. 3. The notion of Matrix technique. architectures embody application domain-speciﬁc seman- tics and quality attributes inherited from the architecture styles. Application architectures may be created using nents are managed. AHP can provide us with good clues. domain architectures (Frakes and Kang, 2005). DRAMA Therefore, AHP cannot be applied to the entire domain. uses the architecture styles from Bass et al. (1998), Busch- mann et al. (1996) and Shaw and Garlan (1996). DRAMA 2.3. Matrix classiﬁes architecture styles corresponding to quality attri- butes as shown in Table 1. Table 1 also shows the relation- The Matrix technique is an extended version of the tech- ship between architecture styles and quality attributes nique discussed by Kim et al. (2004). The Matrix technique (QA). QA is described on the basis of six categories accord- is typically used to calculate the priority of attributes and ing to Bass’, POSA, and Shaw’s books. For example, we adopted it in our approach to identify the priority of Availability is divided into ﬁve subcategories such as avail- quality attributes quantitatively. The basic concept of ability, error handing, fault tolerance, robustness, and Matrix technique is to identify the relationship between interoperability. This means, availability is represented by six quality attributes and components, and to calculate ﬁve subcategories. This is not perfect but helps to under- how each component corresponds to the six quality attri- stand the QA and architecture style of a system in the sense butes. The Matrix technique is formally represented in that we can identify QA from various points of view. Fig. 3. We use ﬁve popular architecture styles, namely, layers, P(x) is the priority of quality attribute x. P(x) is esti- pipes and ﬁlters, blackboard, broker, and MVC (Model mated by each weight of all components times each corre- View Controller) because they are widely used in the indus- lation degree between quality attribute x and corresponding try. Table 1 shows the relationship between architecture Component (i) where i is a natural number between 1 styles and quality attributes. Each cell shows whether there and the total number of components (more detail in is a positive or negative impact of a quality attribute on a Section 3). The correlation degree (or value) can be 0 (no particular architecture style using the up or down arrow. relation), 1 (weak relation), 2 (normal relation), or 3 (strong For example, modiﬁability in layers architecture style is relation). manifested in such quality attributes as ‘reusability’, The Matrix technique aims to provide numerical deci- ‘exchangeability’, and ‘portability’. ‘Reusability "’ means sion criteria in order to ﬁnd which quality attribute is layers architecture style reﬂects reusability well. On the important. Thus, the correlation value (0, 1, 2, or 3) is other hand, modiﬁability in MVC architecture style is char- enough to discriminate between attributes. acterized in ‘pluggable’, ‘exchangeability’, and ‘reusability’. Table 1 The relationship between architecture styles and quality attributes Layers Pipes and ﬁlters Blackboard Broker Model view controller A Availability" Availability" Fault tolerance" Interoperability" Error handling# Robustness" Fault tolerance# M Reusability" Replacement" Changeability" Portability" Exchangeability" Maintainability" Reusability" Pluggable" Reusability" Changeability" Exchangeability" Portability" Reusability" Extensibility" Reusability# P Performance# Performance# Performance# Performance# Performance# S Security " T Testability" Testability" Testability# Client" Broker# U Usability" Usability" Usability" Usability" Availability (A), Modiﬁability (M), Performance (P), Security (S), Testability (T), Usability (U). 42 J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 ‘Reusability #’ means MVC architecture style does not components. Goal modeling for component elicitation reﬂect reusability well. Thus, layers architecture style is use- is implemented according to four abstraction levels of ful to represent ‘Availability’ and ‘Modiﬁability’. Pipes and requirements: business level, service level, interaction ﬁlters architecture style is suitable for incorporating ‘Mod- level, and internal level. After goal modeling, compo- iﬁability’. Blackboard architecture style is appropriate for nents are constructed. ‘Availability’ and ‘Modiﬁability’, but not very useful for 2. Calculating the priority of components: the importance ‘Testability’. Table 1 is used to model domain architecture of components is calculated through AHP to understand corresponding to quality attributes. which components have a major role. This is done quantitatively. 3. DRAMA 3. Calculating the priority of quality attributes: the Matrix technique (discussed in Section 2.3) is used to calculate Based on the concepts introduced in the previous sec- the priority of each quality attribute. tion, we present the DRAMA process and a supporting 4. Modeling domain architectures: the structure of archi- tool. To demonstrate the feasibility of our approach tecture is determined based on quality attributes. (DRAMA), we have applied it to the example of home Domain architectures are constructed based on compo- integration system (HIS) (Kang et al., 2002). HIS enhances nents and quality attributes using architecture styles. comfort, safety, and security of a home and enables home- owners to access, control, and integrate equipment in their home such as the ones listed below: 3.1.1. Step 1: Identifying logical components Goal and scenario modeling as mentioned above is used • climate control systems – heating and cooling; to identify logical components. A logical component is a • security systems – intrusion, ﬁre, and ﬂood detection component representing requirements except technology, and response; and environments, and constraints. The inputs to ‘Identifying • entertainment systems – televisions, radios, and music- logical components’ are business strategy and marketing playing devices. plan. The outputs from ‘Identifying logical components’ are a goal tree and logical components. Implementing the 3.1. DRAMA process goal and scenario modeling approach is discussed using the HIS example below: The DRAMA process consists of four major steps, and • At the business and service level detailed description for each step is provided in the follow- In the HIS example, let us assume that a company ing sections (refer to Fig. 4): ‘‘ABC’’ has projected a multibillion-dollar market for HISs. The company intends to become a major vendor 1. Identifying logical components, which constitute the with two initial HIS products: a low-end product architecture, is achieved in the requirements analysis (LE-HIS) – a small system with few services, a high-end phase. We use goal modeling to elicit and to identify product (HE-HIS) with additional services, and a middle- end product (ME-HIS). The key marketing strategy of this company is to build scalable products that allow budget- conscious customers to start with a small system and then •Business strategy grow to a bigger one by adding additional services instead Identifying components •marketing plan of buying new products. The intention of the company as mentioned above drives the business goal ‘‘Become the best provider in HIS Calculating the priority •Goal tree market within 10 years (BG: Business Goal)’’. This business of components •components goal becomes concrete by means of the service goals. Ser- vice goals are inﬂuenced by the marketing strategy of the organization. The marketing strategy of ‘‘ABC’’ is to divide HIS market into a low-end product HIS, a high-end prod- Calculating the priority •Priority of components uct HIS, and a middle-end product HIS responding to of quality attributes budget-conscious customers. Due to this marketing strat- egy, service goals corresponding to their business goals are generated as follows: ‘‘Provide high-end products to cus- Modeling domain tomers (Sg1: Service goal 1)’’, ‘‘Provide low-end products to •Priority of quality attributes architectures customers (Sg2: Service goal 2)’’, and ‘‘Provide middle-end products to customers (Sg3: Service goal 3)’’. Thus, the goal Inputs •Domain architectures Sg1 is related to the high-end products, Sg2 is related to the outputs low-end products, and Sg3 is related to the middle-end Fig. 4. DRAMA process. products, which means that the organization can choose J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 43 At business and service level BG: Become the best provider in HIS market within 10 years alternative alternative alternative Sg3: Provide middle-end products to customers Scenarios Sg2: Provide low-end products to customers Scenarios Sg1: Provide high-end products to customers Scenarios Ss1. Customers control climate through HIS remotely <<Common>> Ss2. Customers secure their home through remotely <<Common>> Ss4. Customer telecommunicate HIS remotely <<Optional>> Ss1. Customers control climate through HIS remotely <<Common>> Ss2. Customers secure their home through remotely <<Common>> Ss3. Customer enjoy an entertainment service on TV <<Optional>> Ss1. Customers control climate through HIS remotely <<Common>> Ss2. Customers secure their home through remotely <<Common>> Fig. 5. Goals and scenarios at business and service level. one among Sg1, Sg2, and Sg3. During development time, Fig. 5 depicts goals and scenarios at the business and ser- if Sg1 is chosen for the marketing plan, then Sg2 and vice level so far in the HIS example. Sg3 are exclusive. If Sg2 is chosen, then Sg1 and Sg3 are exclusive. If Sg3 is chosen, then Sg1 and Sg2 are exclusive. • At the interaction level Only one of these three service goals will be developed The interaction level focuses on the interactions between and hence they have an alternative relationship with each the system and its external entities, which correspond to its other. higher goals and scenarios. Goals at the interaction level As shown in Fig. 5, service scenarios are generated in the are derived from scenarios at the service level as illustrated same way that a goal is implemented by scenarios. Because in Fig. 6. The scenarios yield possible interaction goals at Sg1 fulﬁlls the marketing strategy for a high-end product, the interaction level. For example, Ss1, Ss2, Ss3, and Ss4 Sg1 has the following scenarios (shown in Table 2) corre- yield the following goals at the interaction level: ‘‘Control sponding to high-end services. climate remotely (IAg1: Interaction goal 1)’’, ‘‘Secure home Since Sg2 fulﬁlls the marketing strategy for a low-end remotely (IAg2: Interaction goal 2)’’, ‘‘Provide an entertain- product, Sg2 has fewer scenarios than Sg1. A high-end ment service to customers (IAg3: Interaction goal 3)’’, and product fulﬁlled by Sg1 includes the following scenarios: ‘‘Communicate with HIS (IAg4: Interaction goal 4). These Ss1 ‘‘Customers control climate through HIS remotely’’, goals inherit all characteristics (e.g. variant type) of the sce- Ss2 ‘‘Customers secure their homes through remotely’’, Ss3 narios at the previous level. Then, the domain experts and ‘‘Customer enjoy an entertainment service on TV’’, and analysts choose speciﬁc interaction goals among the possi- Ss4 ‘‘Customers communicate with HIS remotely’’. A ble goals. low-end product fulﬁlled by Sg2 includes the scenarios Next, the interaction scenarios are generated to achieve Ss1 ‘‘Customers control climate through HIS remotely’’ these interaction goals, which should reﬂect the character- and Ss2 ‘‘Customers secure their homes through HIS remo- istics of that level. Fig. 6 shows the goals and the associated tely’’. Because both Ss1 and Ss2 are involved in Sg1 and scenarios at the interaction level. Scenarios at the interac- Sg2, all of Ss1 and Ss2 have a common relation type. How- tion level are also authored with common, optional, or ever, Ss3 is just involved in Sg1, not Sg2 and Sg3. Thus Ss3 alternative types. The variant type of the interaction has an optional relationship. Ss4 has also an optional rela- scenarios is determined based on the way each interaction tionship because Ss3 is involved in Sg1 and Sg3, not Sg2. scenario achieves its own interaction goal. In Fig. 6, there Table 2 Goals and scenarios at service level in HIS example (Ss: service scenario) Sg1 Provide high-end products to customers Ss1 Customers control climate through HIS remotely Ss2 Customers secure their homes through HIS remotely Ss3 Customers enjoy an entertainment service on TV Ss4 Customers communicate with HIS remotely Sg2 Provide low-end products to customers Ss1 Customers control climate through HIS remotely Ss2 Customers secure their homes through HIS remotely Sg3 Provide middle-end products to customers Ss1 Customers control climate through HIS remotely Ss2 Customers secure their homes through HIS remotely Ss4 Customers communicate with HIS remotely 44 J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 Interaction level common IAg1. Control climate remotely Scenarios in various ways author common IAg2. Secure home remotely Scenarios optional IAg3. Provide an entertainment Scenarios service to customers IAs1. Customers connect HIS remotely <<common>> IAs2. HIS checks the authentification of customers << common >> IAs3. Customers ask HIS to control a climate manually << alternative>> IAs3`. Customers ask HIS to control a climate automatically << alternative >> IAs4. HIS returns the result of control climate service << common >> Fig. 6. Partial example at the interaction level. are ﬁve scenarios corresponding to IAg1. Some of these interaction level. Of course, internal goals and internal sce- scenarios, namely, IAs1 (Interaction scenario 1), IAs2, narios are generated to correspond to the characteristics of and IAs4 are essential for IAg1. However, IAs3 and IAs3 0 the internal level. At this level, internal goals are generated have a diﬀerent variant type according to whether the cli- from the scenarios at the previous level, shown in Fig. 6. mate control is done manually or not. On the one hand, The internal goals and scenarios supplement the goals IAs3 supports the climate control service manually. On and scenarios at the interaction and service level in more the other hand, IAs3 0 supports climate control automati- detail from the interaction among the internal objects’ cally, which means that HIS operates the interior climate point of view. Fig. 7 depicts a partial example at the inter- control both automatically and manually. The way that nal level. For the goal INg2, it has ﬁve scenarios represent- HIS operates a climate service depends on customers’ pref- ing the interaction ﬂows of objects within the inner system. erence. If IAg1 is assigned to ‘‘Control climate remotely and The objects interacting with each other are HIS engine, economically’’, IAs3 0 could not be generated because an Communicator, and Discriminator. HIS engine performs automatic climate control is generally more expensive than the role that coordinates all the objects within the system. a manual climate control. Therefore, a goal decides which The Communicator is responsible for communicating with variant type a scenario must utilize. external objects. The Discriminator checks whether the • At the internal level connection information is valid or not. The goal and scenario modeling process is done at the One of the ﬁnal outputs of this step is a goal tree, which internal level in the same way that it is performed at the can be analyzed using the DRAMA tool. Fig. 8 shows the Common INg2. Validate the authentification of customers Scenarios Internal level Common INg1. Maintain connection with customers Scenarios Common INg3. Operate a climate in a manual way Scenarios Optional INg4. Operate an climate in a automatic way Scenarios author Common INg5. Provide a result of services Scenarios INs1. The HIS engine asks the Communicator to receive the id and password of customers <<common>> INs2. The Communicator asks the Discriminator to identify whether id and password are reserved << common >> INs3. The Discriminator returns the result of identification to the Communicator <<common>> INs4. The Communicator returns the result of identification and the state of customers to the HIS engine <<common>> INs5. The HIS engine returns the result and the state of customers’ contact to customers <<common>> Fig. 7. Partial example at the internal level. J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 45 Fig. 8. The ﬁnal goal tree in HIS product line. resulting goal tree for the HIS example. All the goals have that these logical components provide the starting point for their own variant type such as common (represented by a designing the software architecture. solid line), alternative (a solid line with black circle), and For the HIS product line, eleven logical components optional (a solid line with white circle), as shown in Fig. 8. are identiﬁed based on the internal goals and scenarios: Logical components are identiﬁed from the goal tree CheckTemperature(c1), ManageTemperature(c2), DetectIn- shown in Fig. 8. The core idea is that the goals at the inter- trusion(c3), CallPolice/Oﬃce(c4), OperateFireExtinguisher nal level are used to construct logical components. As the c5), DetectFire(c6), OperateCutoﬀ(c7), DetectFlood(c8), internal level focuses on what the system should provide CheckAuthentiﬁcation(c9), DisplayTV(c10), and PlayRa- internally to satisfy the interactions speciﬁed at the interac- dio(c11). tion level, a goal at the internal level is regarded as a logical All the logical components have their own variant type component which is a basic unit for composing the system, extended from ‘common’, ‘optional’, and ‘alternative’ type. and scenarios illustrate the role of the logical component. A more detailed variant type is needed to maintain the This is due to the fact that, in our approach, a goal is trans- traceability between requirements and logical components. formed into a logical component and scenarios to the role As shown in Fig. 8, CheckAuthentiﬁcation has a common of the logical component, which describes how the logical type in the goal tree. Its parent node, ‘Telecommunicate- component works. Therefore, we propose the following HIS’, has an optional type. Thus, strictly speaking, it is relationship diagram (shown in Fig. 9) that captures the possible to say that CheckAuthentiﬁcation has both association between an internal goal, a logical component, optional (from its parent) and common (from itself) type. and scenarios. As shown in Fig. 9, an internal goal is imple- In this paper, it is represented as OC (optional and com- mented by one or more internal scenarios. Internal scenar- mon) type. It is useful to decide which logical components ios describe the role of logical component. are important. For example, both CheckAuthentiﬁca- These logical components are not concrete but concep- tion(c9) and DisplayTV(c10) have common type with tual. Thus, these logical components cannot exactly consti- respect to its own type. However, at the point of extended tute the physical architecture. Nevertheless it is meaningful type, CheckAuthentiﬁcation(c9) has OC type. On the other hand, DisplayTV(c10) has CC type. When considering a logical component’s own type, each logical component internal 1 Is implemented by 1..* internal has the same priority. However, considering their parent goal scenario type may be more important. For example, Dis- 1 1..* playTV(c10) can be more important than CheckAuthentif- ication(c9). Thus, all logical components have additional name 1 Logical 1 role extended variant types such as ‘CC’, ‘CO’, ‘CA (alterna- Component tive)’, ‘OC’, ‘OO’, ‘OA’, ‘AO’, ‘AA’, and ‘AC’. This gives Fig. 9. The relationship between internal goal, logical component, and us more precise information for designing the architecture. scenario. In other words, software developers should pay attention 46 J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 to these components because they are involved in all the values ranging from 0 to 3 are entered (0: none, 1: weak, product lines and the requirements they fulﬁll have higher 2: average, 3: strong). The importance of quality attributes priority than other components. is determined by multiplying the correlation values by the importance of each logical component according to each 3.1.2. Step 2: Calculating the priority of logical components quality attributes. Table 3 shows the output using Some logical components have to be managed more DRAMA tool which implements the Matrix technique. carefully than others. This is decided based on the role of For example, the priority of ‘Availability’ is calculated the logical component, development cost, users’ preference, based on how much each logical component contributes etc. This raises the issue of weighting each logical compo- towards the ‘availability’ attribute. Depending upon the nent corresponding to its own importance. According to assessment of the contribution of each logical component, the priority of logical components, the logical component a value for the co-relationship from ‘0’, ‘1’, ‘2’, and ‘3’ is with higher priority is more important than one with lower ﬁlled in. Then the priority of ‘Availability’ is calculated priority because software quality is more dependent on the according to the equation shown in Fig. 3. For example, logical component with higher priority. This issue is tack- the priority of ‘Availability’ is computed as 0.97 (= 5% * led in step 2 using AHP as discussed in Section 2.2. 0 + 6% * 1 + 10 % *2 + 8% * 2 + 19% * 2 + 10% * 1 + 10% * The inputs to Step 2 are the goal tree and the logical 0 + 7% * 1 + 12% * 0 + 4% * 0 + 4% * 0). components. The output from Step 2 is the priority of each For the c1 example, c1 is the ‘CheckTemperature’ logi- logical component. For the HIS product line, the priorities cal component. It has 5% priority in all logical compo- of the 11 logical components are calculated as shown in nents. c1 and each quality attribute are compared and Fig. 10. then the correlation value between c1 and the six quality The last row in the table shows the priorities of each of attributes are assessed as follows: availability(0), modiﬁ- the logical components. Speciﬁcally, the logical component ability(1), performance(0), security(0), testability(1), and c1 contains 5%, c2 contains 6%, c3 contains 10%, c4 con- usability(0). Modiﬁability and testability could be weakly tains 8%, c5 contains 19%, c6 contains 10%, c7 contains related to c1. This decision depends on architects, design- 10%, c8 contains 7%, c9 contains 12%, c10 contains 4%, ers, analysts and developers. c2–c11 are assessed in a simi- and c11 contains 4%. Thus, since the OperateFireExtin- lar manner. guisher(c5) logical component contains 19%, c5 is the most Priorities of attributes help us focus on which quality important logical component in the HIS product line. attribute is the most important for the target system. We can decide on the quality attributes we should consider 3.1.3. Step 3: Calculating the priority of quality attributes more carefully and the related logical components, which The priority of each quality attribute is calculated based is lacking in prior works as they did not provide numeric on the priority of logical components. This is done using values for attributes in designing architectures. DRAMA the Matrix technique discussed in Section 2.3. The inputs provides the quantitative rationales for designing architec- to Step 3 are the priorities of logical components and the tures, which is one of the important contributions of this outputs are the priorities of quality attributes. paper. DRAMA uses the following quality attributes classiﬁed in Bass et al. (1998): availability (A), modiﬁability (M), per- 3.1.4. Step 4: Modeling domain architectures formance (P), security (S), testability (T), and usability (U). This step describes how to model domain architectures In order to calculate the importance of quality attributes, a using the outputs we have explained. As already mentioned table is created. Quality attributes are enumerated on the above, we do not deal with how to create architecture in top row and the identiﬁed logical components are enumer- detail, but propose an approach for deriving proper domain ated on the left column. The correlation between quality architectures from architecture styles. The inputs to this attributes and each logical component, namely, the correla- step are quantiﬁed priorities of logical components and tion values are assessed. For this correlation assessment, quality attributes, logical components list, and architecture Fig. 10. Priority of each logical component in the HIS product line. J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 47 Table 3 Calculation of the priority of quality attributes Priority Availability Modiﬁability Performance Security Testability Usability c1 5 0 1 0 0 1 0 c2 6 1 1 1 0 1 0 c3 10 2 0 1 0 1 0 c4 8 2 0 2 0 0 0 c5 19 2 0 3 0 1 0 c6 10 1 2 0 0 1 0 c7 10 0 0 0 2 0 0 c8 7 1 0 2 0 3 0 c9 12 0 3 0 3 3 0 c10 4 0 0 0 0 0 2 c11 4 0 0 0 0 0 2 Total Qualit. 0.97 0.67 1.03 0.56 1.07 0.16 styles. The output from this step is the conceptual domain eled based on the roles of logical components. For exam- architecture, which is the most appropriate among many ple, ManageTemperature is connected with CheckTem- feasible domain architectures. plate and CallPolice/Oﬃce according to its role. The roles To adopt architectural styles, we need to classify the rep- of logical components were already determined according resentative architectural styles and arrange the characteris- to the internal scenarios shown in Fig. 9. tics of each style. Speciﬁcally, we need to understand which architectural styles reﬂect which quality attribute because 3.2. CASE environment supporting our approach the overall architecture reﬂects many quality attributes (refer to Section 2.4). As software product lines aim to provide a product to For the HIS product line, ‘Testability’ and ‘Perfor- end-users and reduce time-to-market, domain requirements mance’ should be considered in modeling the domain archi- elicitation and analysis and domain architecture design tecture since ‘Testability’ (1.07) has the highest priority, require more traceability and eﬀort. As a result, many tools and ‘Performance’ (1.03) has the second highest priority. for automating domain requirements management and Therefore, pipes and ﬁlters architecture styles are recom- domain architecture have been developed. Moon’s mended for the HIS product line according to Table 1. DREAM (Moon et al., 2005) and Kang’s ASADAL/ DRAMA automatically recommends Pipes and Filters FORM (http://selab.postech.ac.kr/form) have been intro- architecture style as the most feasible architecture and then duced recently. However, DREAM is limited in its ability proposes a design tool kit corresponding to the pipe and to support traceability between requirements and architec- ﬁlter architecture styles. Fig. 11 depicts one feasible archi- ture because it concentrates on managing the requirements tecture for the HIS product line, in which eleven logical of product lines. ASADAL/FORM supports the FORM components become ﬁlters. Pipes as connectors are mod- method proposed by Kang et al., 1998. It provides a tool for domain requirements analysis and domain architecture design. However, domain architectures are not designed according to quality attributes in ASADAL/FORM. Our tool is a semi-automated CASE tool supporting the DRAMA process and methods. Our tool is useful for: (1) domain requirements analysis based on goal and scenario, (2) quantitative analysis for the priority of components and quality attributes, and (3) traceability between domain requirements and domain architectures. Fig. 12 shows the graphical user interface of our tool. The tool consists of domain requirements analyzer, component priority calcu- lator, quality attributes priority calculator, and domain architecture modeler. The following sections describe each tool in more detail. 3.2.1. Domain Requirements Analyzer The Domain Requirements Analyzer tool supports the ‘identifying components’ process fully. As mentioned above, this process is based on goal and scenario modeling. Fig. 11. Feasible domain architecture in HIS product line. The domain requirements analyzer aims to analyze domain 48 J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 Fig. 12. An overview of DRAMA tool. requirements for modeling architectures in a semi-auto- The domain requirements analyzer consists of three pan- matic way; the scenarios are used to discover goals at the els. The left panel shows the goal list. The right panel shows next lower level. Fig. 13 shows the snapshot of the domain the workspace where goals represented by rectangles and requirements analyzer. relation represented by lines are drawn. Each goal has its Fig. 13. Domain requirements analyzer. J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 49 own goal property where a goal’s level, description tem- 3.2.3. Quality attributes priority calculator plate, variant type, rationale, and scenarios are contained. Quality attributes priority calculator supports the ‘cal- The domain requirements analyzer helps generate and culating the priority of quality attributes’ process. Fig. 15 analyze domain requirements in terms of goal and sce- depicts a snapshot of the quality attributes priority calcu- nario. Using the Template tab in the Goal Property panel, lator. The interface for the Quality attributes priority the abstraction level and variant type of a goal are inserted calculator is similar to the one for component priority cal- or modiﬁed. A goal is authored according to the goal tem- culator. The quality attributes priority calculator generates plate hVerb, Target, Direction, Wayi. The source and ratio- priorities for all the quality attributes. nale of a goal are inserted using the Rationale tab within The degree of relationship between each of the compo- the Goal Property panel. Scenarios corresponding to a goal nents and each of the quality attributes is added to each are inserted using the Scenarios tab in the Goal Property cell. The degree is a numerical value, which can be 0, 1, panel. The scenarios can be candidate goals at the next 2, 3 or 4. When the ‘‘Total Weight Calculation’’ button is lower level automatically. pressed, the quality attributes priority calculator produces the ﬁnal priority for each quality attribute using the Matrix 3.2.2. Component priority calculator technique. The component priority calculator supports ‘calculating the priority of components’ process. As mentioned above, 3.2.4. Domain Architecture Modeler this process uses AHP. Thus, the component priority calcu- The domain architecture modeler helps to generate a lator supports automatic calculation of the priority of generic architecture for product lines based on the above components. Fig. 14 depicts the snapshot of Component outputs. It helps us to determine which architecture styles priority calculator. are feasible according to the priority of quality attributes The component priority calculator interface consists of and then shows candidate architectures with components four panels. The left upper panel shows the component list. and their connections. Finally, users of the tool can choose The lower left panel shows information about each compo- a feasible architecture based on their domain knowledge nent in detail. The right panel shows the workspace where and environment. the priority of components is calculated. Each cell in the As shown in Table 1, the tool supports ﬁve architecture workspace shows two components to be compared with styles. Our tool automatically generates a feasible architec- each other in the ‘Relative comparison of two components’ ture style according to the priority of quality attributes. panel. When a number between 1 and 9 or 1/2 and 1/9 is The tool users can select a feasible architecture style as inserted as the pairwise comparison value, this comparison the generic architecture and use it as a starting point for value is added to the workspace. the design phase. Fig. 14. Component priority calculator. 50 J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 Fig. 15. Quality attributes priority calculator. 4. Empirical validation The ﬁrst day of the training focused on the concept of domain analysis, domain architecture modeling, and how The objective of the empirical validation is to demon- DRAMA could be used. The second day focused on the strate whether software development eﬀorts using our usage of DRAMA tool and Q&A. For the validation, par- approach and the tool can help in generating better quality ticipants were randomly assigned to two groups. Group A: domain architecture compared to those not using it. In the group which developed the projects with their own order to carry out an empirical validation, we divided sys- choice of methods. Group B: the group which developed tem development experts drawn from the Korean industry the same projects using the DRAMA methodology and into two groups and asked them to perform a system devel- the tool. opment exercise. Both groups were tasked to develop three Prior to the start of the validation exercise, the partici- systems, namely an e-learning system, credit card system, pants ﬁlled out a questionnaire, which asked for their back- and CRM system. One group developed these systems ground and experience in software development. Then, using DRAMA and the other group developed them using they analyzed domain requirements and modeled domain their method of choice. At the end of the exercise, the par- architectures. Table 4 shows the speciﬁc assignment of ticipants that used our tool were asked to complete a ques- the groups and the cases. tionnaire. An exploratory survey of practice was also At the completion of the validation exercise, the partic- conducted through site visits. ipants that used the DRAMA tool ﬁlled out another ques- tionnaire regarding the exercise and the usefulness of the 4.1. Design of empirical validation DRAMA methodology and the tool. A discussion seminar was also conducted where the DRAMA group freely dis- Before the empirical validation was conducted, all the cussed a number of issues concerning the use of DRAMA. twenty participants were trained in our DRAMA method- The other group participated as a reference group to ensure ology and the tool for two days. Thirty eight percent of them are working at a SI (System Integration) company. Table 4 Twenty ﬁve percent of them are working in an IT Consul- Design of empirical validation tant Company. Nineteen percent of them are working for a DRAMA Project 1 Project 2 Project 3 Solution Provider. The others are working as freelancers in a bank and a hardware vendor. Most of them have more Group A Not used e-Learning Credit card CRM Group B Used system system system than 3 years of experience in developing software. J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 51 that they are in fact discussing the DRAMA tool and noth- Average Score ing extraneous. In the open discussion, they also provided 5 4.13 4.28 4.05 3.87 comments about the methods they used and how it com- 4 pared to the DRAMA approach. 3 2 4.2. Design of questionnaire 1 A B C D The purpose of the questionnaire concerning DRAMA A) Overall usefulness is to verify the usefulness of our DRAMA approach and B) Domain analysis based on goal and scenario the tool. The questionnaire consisted of several categories C) Calculating the priority of components using AHP of questions. These categories were about domain analysis D) Calculating the priority of quality attributes using Matrix using goal and scenario based on linguistics, calculation of the priority of components using AHP, calculation of the Fig. 16. Average scores for usefulness. priority of quality attributes using Matrix, and overall use- fulness for modeling architectures from domain analysis. Average Score 5 4.52 4.3 4.3. Data analysis and results from survey 4 3.6 3 This section describes the results from the survey admin- istered to the group that used the DRAMA tool and data 2 analysis. The results extracted from the questionnaires are 1 summarized below. A B C D Eighty ﬁve percent of participants that used our tool A) Methodological support answered that our methodology and the tool are useful B) Tool support and that DRAMA provides available information for C) Traceability between requirements and architecture modeling architectures in a product line. This means that D) Reliability on domain architecture DRAMA supports the creation of a concrete domain Fig. 17. Average scores for potential beneﬁts. architecture. Remaining participants indicated that DRAMA should supplement the other factors inﬂuencing domain architecture such as technology, constraints, man The following is an excerpt from some of the comments power, and hardware environments as well as domain made by the participants: requirements. Seventy seven percent of the participants using • A well deﬁned process and method are useful to model DRAMA answered that it can forecast the change of domain architectures. DRAMA provides good support domain architecture when domain requirements are chan- for creating the domain architecture. ged. This shows that DRAMA is useful for modeling • Because domain analysis is based on goal and scenario domain architectures based on domain requirements and with linguistic aspects, users can elicit and analyze provide the starting point for a concrete domain domain requirements easily. With domain analysis in architecture. DRAMA, the correctness of requirements and the Participants were asked to grade the usefulness of the familiarity of users have increased by 150% compared various components of DRAMA on a scale of 1–5 (1: to other projects without it. Totally useless, 2: Somewhat useless, 3: Neutral, 4: Some- • The calculation of the priority of components using what useful, 5: Very useful). Speciﬁcally, users were asked AHP is useful because DRAMA helps to decide which to score how well the tool supported domain analysis based component is important objectively. on goal and scenario, calculating the priority of compo- • The calculation of the priority of quality attributes is nents and quality attributes, and the overall usefulness. useful. However, the classiﬁcation of quality attributes The average scores for each of these dimensions are pre- in DRAMA should be supplemented. sented in Fig. 16. The remaining results from the survey • Tool support enhances the eﬃciency and usefulness of are provided in Appendix. DRAMA. However, it is unsatisfactory that the tool It is evident from Fig. 16 that users have expressed quite does not provide ‘Copy and paste’, ‘Undo’, and ‘Version a high level of satisfaction with the methodology and tool, management’ functions. which is very encouraging. Also, Fig. 17 shows the partic- ipants’ feedback regarding the four frequently mentioned DRAMA supports traceability between domain require- contributions of our approach to the improvement of cur- ments and domain architecture. This means that the change rent practice. The tool support was the most frequently in users’ needs is reﬂected in the architecture. Therefore, mentioned beneﬁt resulting from the use of the approach. DRAMA enables us to achieve better time-to-market. 52 J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 However, since domain requirements drive the domain 5.2. Svahnberg et al.’s approach architecture, it is not guaranteed completely but recom- mended before designing a concrete domain architecture. Svahnberg et al. (2003) present a method to increase the Participants also commented that the methods they understanding of the beneﬁts and liabilities of diﬀerent know such as WinCBAM and FORM are lacking in pro- software architectures with respect to quality attribute. viding a tight coupling between domain requirements and Their method can be used to indicate which of the architec- domain architecture. Positive statements were made ture candidates best suits the quality requirements of a regarding the contribution of the approach to the mapping given software system. Thus, their method enables software from requirements to architecture. The quantitative designers to take into account relevant quality attributes approach proposed in our methodology for analysis, dis- for a system and evaluate these against all software archi- ambiguation and completion were found applicable to tecture candidates for the system. However, their method most real situations where it is necessary to support a rea- does not support the entire process, but only partially from sonable decision making process for selecting appropriate requirements to architecture. Their approach focuses on architecture style. Some negative statements were made the relationship between quality attributes and the struc- regarding the scalability problem. In AHP, the count of ture of architecture. Since they also do not provide a sup- pairwise comparisons is n * (n À 1)/2, which could lead to porting tool, it is diﬃcult to check whether their scalability issues. However, it could be partly alleviated approach is practical or not. through proper planning and management. Instead of applying it to the entire domain, AHP can be used for 5.3. The PuLSE approach sub-domains. PuLSE stands for Product Line Software Engineering 5. Related work and shows that its scoping approach is only the scoping part of a full-ﬂedged product line development method In this section, prior works similar to DRAMA are (Bayer et al., 1999). PuLSE covers two forms of scoping: introduced and evaluated. Speciﬁcally, the WinCBAM domain scoping (this aims at evaluating the beneﬁts and framework, Svanhnberg et al.’s approach, and PuLSE risks connected with systematic reuse in the domains that approach are introduced and compared with DRAMA are relevant to the product line) and asset scoping (this from the perspective of the overall methodology. Require- aims at determining a reuse infrastructure that optimizes ments Abstraction Model, TQM, Non-functional Require- satisfaction of the economic objectives of the organiza- ments and the Softgoals methodology are also discussed tion). Within this setup the product line mapping has the with respect to the key ideas in DRAMA. role of deﬁning the communication basis for the later steps of the scoping process. The scoping steps of domain poten- 5.1. Kazman et al.’s approach tial assessment and reuse infrastructure scoping rely on this communication basis. In the domain potential assessment Kazman et al. (2005) proposed the WinCBAM frame- the various technical domains relevant to the product line work, extending an existing architecture design method, are analyzed with respect to their inherent beneﬁts and called the cost beneﬁt analysis method (CBAM), to include risks for product line development. These results are then an explicit requirements negotiation component based on used for selecting focus areas for product line reuse. the WinWin methodology. Their research speciﬁcally Finally, the reuse infrastructure scoping determines a examines why and how the architecture design process detailed scope by identifying within the selected focus areas can be tightly integrated with the requirement negotiation the features that should be packaged as reusable assets. process resulting in time and cost savings, risk reduction, This scope aims at the overall optimization of the economic and higher design quality. In particular, their research beneﬁts to the organization. extends the previous work on ATAM (Kazman et al., PuLSE is focused on the scoping of product lines. It is 1999) and the CBAM (In et al., 2001) to incorporate good for the scoping. However, this approach cannot requirement negotiation techniques from WinWin, forming provide how to generate a domain architecture in product an integrated method to assure architecture design quality. lines. On the other hand, DRAMA can provide scoping The WinCBAM framework provides various rationales and analysis using goal and scenario, the design of domain for design architecture, and makes it available for develop- architecture, a fully supporting tool. This is a main diﬀer- ers to decide which factors aﬀect their architecture. How- ence between PuLSE and DRAMA. ever, it is not very practical because the WinCBAM framework does not provide a process or any tool support. Since WinCBAM focuses on theoretical rather than practi- 5.4. Requirements Abstraction Model (RAM) cal aspects, it is very diﬃcult to apply to a real world case. Also, WinCBAM does not tackle how quality attributes Requirements Abstraction Model (RAM), with four are reﬂected in the architecture, even though architectures abstraction levels, was developed as a response to the typically fulﬁll quality attributes in software systems. industrial needs (Gorschek and Wohlin, 2005). RAM J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 53 allows companies to ensure comparability between require- als for e.g. the ﬂexibility softgoal. Once uncovering tree ments, and hence it generates important input to activities structures, one is bound to ﬁnd interfering softgoals in dif- such as prioritization and packaging of requirements ferent trees, e.g. security goals generally interferes with before launching a development project. RAM was usability. These softgoal trees now form a softgoal graph designed with Product Managers in mind, supporting them structure. The ﬁnal step in this analysis is to pick some par- in their requirements engineering eﬀort towards producing ticular leaf softgoals, so that all the root softgoals are sat- requirements good enough for planning activities, giving isﬁed. This approach is the origin of goal and scenario detailed abstraction as well as a big picture view. However, modeling in DRAMA. it was also developed with engineers (developers) in mind, controlling the abstraction level and reﬁnement of require- 6. Conclusion ments handed over to projects. Therefore, the contribution of RAM is to assure that requirements be speciﬁed on mul- The main contribution of our approach is to provide the tiple abstraction levels in a repeatable and homogenous traceable relationship between requirements and architec- way, enabling, e.g. Product Managers in early requirements ture. In order to design the architecture based on require- engineering eﬀorts. ments, we have developed the DRAMA methodology Requirements level in DRAMA is similar to RAM at and the supporting tool that supports how to analyze this aspect. The requirements level was used to guide goal requirements, how to quantify requirements, and how to and scenario modeling and provide the separation of measure quality attributes. If requirements are changed in concerns. RAM is more detail than requirements level in terms of goals, our proposed methodology makes it possi- DRAMA. ble to determine how to redesign the architecture. A full- scale architecture may not be easy to design because many 5.5. TQM (Total Quality Management) factors inﬂuence the architecture. Nevertheless, the concep- tual architecture generated as the output from our Total Quality Management (TQM) is a management approach is useful as a starting point for designing the approach for an organization, centered on quality, based overall system architecture. Our DRAMA support tool on the participation of all its members and aiming at automates the design of conceptual architecture using an long-term success through customer satisfaction, and intuitive graphical interface. Our future work includes fur- beneﬁts to all members of the organization and to society ther reﬁnement of goal modeling as well as the relationship (ISO). TQM has been widely used in manufacturing, edu- between quality attributes and architectural styles using cation, government, and service industries, as well as neural network theory, and conducting additional valida- NASA space and science programs. TQM views an organi- tion in diﬀerent domains. When selecting a candidate zation as a collection of processes. It maintains that among architecture styles, all the priorities of quality attri- organizations must strive to continuously improve these butes should be normalized and considered. This selection processes by incorporating the knowledge and experiences will be further explored as part of our future work. The of workers. The simple objective of TQM is ‘‘Do the right tool will also be improved to support ‘Copy and paste’, things, right the ﬁrst time, every time’’. TQM is inﬁnitely ‘Undo’, and ‘Version management’ functions. Our concep- variable and adaptable. Although originally applied to tual architecture will be represented using ADL (Architec- manufacturing operations, and for a number of years only ture Description Language) such as UML 2.0 because it used in that area, TQM is now becoming recognized as a provides such the new notations for architectures as ports, generic management tool, just as applicable in service signals, and interfaces (UML). Our future work will also and public sector organizations (Smith, 1993). However, include a more complete experimental validation of the DRAMA focuses on designing a domain architecture cor- approach with more number of subjects participating in responding to quality attributes derived from domain the experiment. The experimental design will focus on requirements. DRAMA is a framework, but TQM focused applying the methodology to more domains and compar- on organization processes. ing the quality of the artifacts created and the time taken to generate these artifacts by the treatment group vis-a- ` vis the control group. 5.6. NFR (Non-Functional Requirements) framework NFR (Non-Functional Requirements) is a framework Appendix on Goal Modeling (Mylopoulos et al., 1999). The analysis begins with softgoals that represent NFR which stakehold- The appendix presents the remaining results from the ers agree on. Softgoals are goals that are hard to express, empirical validation. Speciﬁcally, we present the mean but tend to be global qualities of a software system. These scores for the diﬀerent subcategories in the survey and could be usability, performance, security and ﬂexibility in a the corresponding questions. As discussed earlier, the given system. These softgoals are then usually decomposed survey was administered to the group that used DRAMA and reﬁned to uncover a tree structure of goals and subgo- (see Fig. 18–20). 54 J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 Response Value Very useful 5 4.25 4.38 4.31 4.12 Somewhat 4 useful Neutral 3 Somewhat 2 useless Totally useless 1 0 1 2 3 4 Question id Questions: If you compare DRAMA with your own methods, 1. How much is goal and scenario approach in DRAMA useful at the initial phase? 2. How much does DRAMA help to identify commonality and variability? 3. How much is domain analysis based on linguistics useful to find the variation points? 4. How much is the rationale of variation provided by DRAMA useful? Fig. 18. Average scores for domain requirements analysis. Response Response Value Value Very useful 5 Very useful 5 4.27 Somewhat 3.83 Somewhat 4.23 4 4 useful useful 3.51 Neutral 3 Neutral 3 Somewhat 2 Somewhat 2 useless useless Totally 1 Totally 1 useless useless 0 0 1 2 1 2 Question id Question id Questions: Questions: If you compare DRAMA with your own methods, If you compare DRAMA with your own methods, 1. How much does DRAMA help to calculate the priority of components? 1. How much does DRAMA help to calculate the priority of quality attributes? 2. How much is AHP practical to calculate the priority of components ? 2. How much is Matrix practical to calculate the priority of quality attributes? Fig. 19. Average scores for determining the priority of components using Fig. 20. Average scores for calculating the priority of quality attribute AHP. using Matrix. References In, H., Boehm, B., Rodgers, T., Deutsch, M., 2001. Applying WinWin to quality requirements: a case study. In: Proceedings of the 23rd Bass, Len, Clements, Paul, Kazman, Rick, 1998. Software Architecture in International Conference on Software Engineering, Toronto, Canada, Practice. Addison-Wesley. pp. 555–564. Bayer, Joachim, Flege, Oliver, Knauber, Peter, Laqua, Roland, Muthig, ISO <http://en.wikipedia.org/wiki/ISO>. Dirk, Schmid, Klaus, Widen, Tanya, DeBaud, Jean-Marc, 1999. Kang, K.C. et al., 2002. Feature-oriented product line engineering. IEEE PULSE: a methodology to develop software product lines. In: Software 9 (4), 58–65. Proceedings of the ACM SIGSOFT Symposium on Software Reus- Kang, K., Cohen, S., Hess, J., Nowak, W., Peterson, S., 1990. Feature- ability, pp. 122–131. Oriented Domain Analysis (FODA) Feasibility Study, Technical Buschmann, Frank, Meunier, Regine, Rohnert, Hans, Sommerlad, Peter, Report CMU/SEI-90-TR-21, Pittsburgh, PA, Software Engineering Stal, Michael, 1996. In: Pattern-Oriented Software Architecture: A Institute, Carnegie Mellon University, November 1990. System of Pattern, vol. 1. Wiley. Kang, K., Kim, S., Lee, J., Kim, K., Shin, E., Huh, M., 1998. FORM: a Dick, Jeremy, 2005. Design traceability. IEEE Software 22 (6), 14–16. feature-oriented reuse method with domain-speciﬁc reference archi- Frakes, William B., Kang, Kyo, 2005. Software Engineering Research: tectures. Annals of Software Engineering 5, 143–168. Status and Future. IEEE Transactions on Software Engineering 31 (7), Kazman, R., Barbacci, M., Klein, M., Carriere, S.J., Woods, S., 1999. 529–536. Experience with performing architecture trade oﬀ analysis. In: Gorschek, Tony, Wohlin, Claes, 2005. Requirements abstraction model. Proceedings of the 21st International Conference on Software Engi- Requirements Engineering Journal 11 (1), 79–101. neering Los Angeles, CA, pp. 54–63. J. Kim et al. / The Journal of Systems and Software 81 (2008) 37–55 55 Kazman, Rick, In, Hoh Peter, Chen, Hong-Mei, 2005. From requirements O’Brien, Liam, Smith, Dennis, 2002. MAP and OAR Methods: Tech- negotiation to software architecture decisions. Information and niques for Developing Core Assets for Software Product Lines from Software Technology 47 (8), 511–520. Existing Assets, Technical Note, CMU/SEI-2002-TN-007. Kim, Jeongwook, Kim, Jintae, Park, Sooyong, Sugumaran, Vijayan, 2004. Pohl, Klaus et al., 1998. Software Product Line Engineering. Springer. A multi-view approach for requirements analysis using goal and Potts, C., 1997. Fitness for use: the system quality that matters most. In: scenario. Industrial Management and Data Systems Journal 104 (9), Proceedings of the Third International Workshop Requirements Eng.: 702–711. Foundations of Software Quality REFSQ’97, Barcelona, pp. 15–28. Kim, Jintae, Park, Sooyong, Sugumaran, Vijayan, 2004. A linguistics- Rolland, C., Souveyet, C., Achour, C., 1998. Guiding goal modeling using based approach for use case driven analysis using goal and scenario scenarios. IEEE Transaction on Software Engineering 24 (12), 1055– authoring. NLDB 2004. In: LNCS, vol. 3136. Springer-Verlag, pp. 1071. 159–170. Saaty, T.L., 1980. The Analytic Hierarchy Process. McGraw-Hill, New Kim, Jintae, Park, Sooyong, Sugumaran, Vijayan, 2006. Improving York. usecase driven analysis using goal and scenario authoring: a linguis- Shaw, Mary, Garlan, David, 1996. Software Architecture: Perspectives on tics-based approach. Data and Knowledge Engineering 58 (1), 21–46. Emerging Discipline. Prentice-Hall. Liu, Dongyun, Mei, Hong, 2003. Mapping requirements to software Smith, A., 1993. Total quality management in the public sector. Quality architecture by feature-orientation. In: STRAW’03 Second Interna- Progress (June). tional SofTware Requirements to Architectures Workshop, Portland, Svahnberg, M., Wohlin, C., Lundberg, L., Mattsson, M., 2003. A quality- Oregen, May 3–11, pp. 69–76. driven decision-support method for identifying software architecture Moon, Mikyeong, Yeom, Keunhyuk, Chae, Heung Seok, 2005. An candidates. International Journal of Software Engineering and Approach to developing domain requirements as a core asset based on Knowledge Engineering 13 (5), 547–573. commonality ad variability analysis in a product line. IEEE Transac- UML 2.0, <http://www.uml.org>. tion on Software Engineering 31 (7), 551–569. Mylopoulos, John, Chung, Lawrence, Yu, Eric, 1999. From object- oriented to goal-oriented requirements analysis. Communications of the ACM 42 (1), 31–37.
Pages to are hidden for
"drama _13_"Please download to view full document