drama _13_ by elgendy22


									                                               Available online at www.sciencedirect.com

                                            The Journal of Systems and Software 81 (2008) 37–55

              DRAMA: A framework for domain requirements analysis
               and modeling architectures in software product lines q
                                Jintae Kim               , Sooyong Park b, Vijayan Sugumaran                           c

                    Telecommunication R&D Center, Samsung Electronics, Metan-dong, Suwon, Gyeonggi Province, Republic of Korea
                      Department of Computer Science, Sogang University, Sinsu-Dong, Mapo-gu, Seoul 121-742, Republic of Korea
            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


   One of the benefits of software product line approach is to improve time-to-market. The changes in market needs cause software
requirements to be flexible 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 reconfigured 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 flexible 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.                             benefits (Dick, 2005):
   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: canon.kim@gmail.com (J. Kim), sypark@sogang.                   customer requirements?’’ ‘‘What is this component’s
ac.kr (S. Park), sugumara@oakland.edu (V. Sugumaran).                               role?’’ ‘‘What are the system requirements associated

0164-1212/$ - see front matter Ó 2007 Elsevier Inc. All rights reserved.
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 reflection 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 reconfigured can be handled through
     possible.                                                                DRAMA.
                                                                          (2) Quantitative analysis. Since software architecture
   Prior research has addressed the relationship between                       reflects 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                            quantified quality attributes, we can decide which
an architecture design method, called cost benefit 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 different 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 reconfigured 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 defined 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 final 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 influence 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,
         reflect 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.
                                                                                      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 effective           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 different 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.                                                 identification 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 identified. 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 specified 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 identified when sce-                 The service level addresses identifying the product plan
narios achieve a goal in two ways; first, 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 – defining 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

                  Business goal                           Alternative

                       Service goal                                                    Common
                                        author   Scenarios

                                                    Interaction               Interaction
                                                        goal                   Scenarios                             Common
                                                                     author                                          Alternative
                                                                                             yield                   Optional

                                                                                      Internal                 Internal
                                                                                        goal                  Scenarios

                                          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                      fill 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 identified. After this
Service scenarios describe the flow of services, which are                     process, a goal tree is generated, and then the components
necessary to fulfill the service goal. For example, the service                are identified 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 flexible 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 flow 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 identified, 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 first 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 different 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).
     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-specific 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                                                                        classifies 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 five 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                            five 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 five popular architecture styles, namely, layers,
    P(x) is the priority of quality attribute x. P(x) is esti-                     pipes and filters, 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, modifiability 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 find which quality attribute is                           layers architecture style reflects reusability well. On the
important. Thus, the correlation value (0, 1, 2, or 3) is                          other hand, modifiability 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 filters         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"
U              Usability"                    Usability"               Usability"                                         Usability"
Availability (A), Modifiability (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
reflect reusability well. Thus, layers architecture style is use-                is implemented according to four abstraction levels of
ful to represent ‘Availability’ and ‘Modifiability’. Pipes and                   requirements: business level, service level, interaction
filters architecture style is suitable for incorporating ‘Mod-                   level, and internal level. After goal modeling, compo-
ifiability’. Blackboard architecture style is appropriate for                    nents are constructed.
‘Availability’ and ‘Modifiability’, 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
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, fire, and flood 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 influenced 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
                                           •Domain architectures
                                                                             Sg1 is related to the high-end products, Sg2 is related to the
                                                                             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 fulfills 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 fulfills 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 fulfilled 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 specific interaction goals among the possi-
Ss4 ‘‘Customers communicate with HIS remotely’’. A                                     ble goals.
low-end product fulfilled 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 reflect 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
                                        in various ways

                                                                    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 five 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 different 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 five scenarios represent-
HIS operates a climate service depends on customers’ pref-                              ing the interaction flows 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 final 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

                      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

                                                                         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 final 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 identified based on the internal goals and scenarios:
   Logical components are identified 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/Office(c4), OperateFireExtinguisher
nal level are used to construct logical components. As the                          c5), DetectFire(c6), OperateCutoff(c7), DetectFlood(c8),
internal level focuses on what the system should provide                            CheckAuthentification(c9), DisplayTV(c10), and PlayRa-
internally to satisfy the interactions specified 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, CheckAuthentification 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 CheckAuthentification 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 CheckAuthentifica-
   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, CheckAuthentification(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-
                                                                                    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 fulfill 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             filled 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), modifi-
the logical components. Specifically, 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). Modifiability 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 classified
in Bass et al. (1998): availability (A), modifiability (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 identified 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 quantified 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          Modifiability        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/Office 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. Specifically, we need to understand which
architectural styles reflect which quality attribute because                      3.2. CASE environment supporting our approach
the overall architecture reflects 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 effort. As a result, many tools
and ‘Performance’ (1.03) has the second highest priority.                        for automating domain requirements management and
Therefore, pipes and filters 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-
filter 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 filters. 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 modified. 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 final 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 five 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 first 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 efforts 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 filled 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 specific 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 filled 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 five 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

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. Data analysis and results from survey                                   4                                                          3.6

   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 five 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 benefits.
architecture. Remaining participants indicated that
DRAMA should supplement the other factors influencing
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:
   Seventy seven percent of the participants using                    • A well defined 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). Specifically, 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 classification 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 efficiency 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 reflected in the architecture. Therefore,
mentioned benefit 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 benefits and liabilities of different
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 difficult 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
                                                                          PuLSE stands for Product Line Software Engineering
5. Related work
                                                                       and shows that its scoping approach is only the scoping
                                                                       part of a full-fledged 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. Specifically, the WinCBAM
                                                                       domain scoping (this aims at evaluating the benefits 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 defining 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 benefits and
called the cost benefit 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 specifically
                                                                       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
                                                                       benefits 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 differ-
ers to decide which factors affect 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 difficult to apply to a real world case.
Also, WinCBAM does not tackle how quality attributes                      Requirements Abstraction Model (RAM), with four
are reflected in the architecture, even though architectures            abstraction levels, was developed as a response to the
typically fulfill 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 flexibility softgoal. Once uncovering tree
ments, and hence it generates important input to activities           structures, one is bound to find 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 final step in this analysis is to pick some par-
in their requirements engineering effort towards producing             ticular leaf softgoals, so that all the root softgoals are sat-
requirements good enough for planning activities, giving              isfied. 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 refinement of require-
                                                                      6. Conclusion
ments handed over to projects. Therefore, the contribution
of RAM is to assure that requirements be specified 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 efforts.
                                                                      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-
                                                                      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 influence 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-
benefits to all members of the organization and to society             ther refinement 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 different 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 first time, every time’’. TQM is infinitely           ‘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. Specifically, we present the mean
but tend to be global qualities of a software system. These           scores for the different subcategories in the survey and
could be usability, performance, security and flexibility 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 refined 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

                                       Very useful 5
                                                                4.25            4.38                             4.31

                                          Neutral       3


                                          useless       1

                                                                   1               2               3                  4        Question id
                                                      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
     Somewhat                                    3.83                                            Somewhat                                          4.23
                  4                                                                                               4
       useful                                                                                      useful
       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-specific 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 off 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.

To top