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