Assessment for quality product derivation from a software product

(2015). RACCIS 5(2), pp. 48-59
Revista Antioqueña de las
Ciencias Computacionales y la Ingeniería de Software
ISSN: 2248-7441
www.fundacioniai.org/raccis
[email protected]
Assessment for quality product derivation from a software product line reference
architecture
Asesoría para la derivación de productos de calidad a partir de una arquitectura de
referencia de línea de productos software
Francisca Losavio1, Oscar Ordaz2, Henry Márquez3
Universidad Central de Venezuela. Caracas. francislosavio(AT)gmail.com, oscarordaz55(AT)gmail.com.
Universidad de Oriente. Cumaná, Venezuela. Henrylmarquez(AT)gmail.com.
1,2
3
INFORMACIÓN DEL ARTÍCULO
Artículo de Investigación
Recibido: 19-10-2015
Correcciones:
Aceptado: 23-12-2015
Keywords
Software product line; reference
architecture; product derivation;
product configuration.
Palabras clave
Línea de productos de software;
arquitectura de referencia;
derivación de productos;
configuración de productos.
ABSTRACT
Reference Architecture (RA) in Software Product Lines (SPL) is the main artifact to derive
concrete products. SPL is a family of software intensive systems or products sharing a
common set of features satisfying a particular market sector, such as the Integrated
Healthcare Information Systems domain. The Assessment Process (ASSPRO), goal of this
work, concerns product configuration, the first stage of SPL product derivation, and starts
with RA, a connected graph or valid architectural configuration built by a bottom-up
process. Product configuration is selected among an optimal set of feasible solutions (FS),
representing valid architectural configurations. Functional and non-functional customer
requirements are considered, using weight-based heuristic assignment to select convenient
FS. A problem in the SPL product derivation is to manage the huge amount of non-functional
variants, which are identified in ASSPRO as solutions to satisfy precise quality
requirements; variants’ choices are handled by applying appropriated strategies. The “best”
FS is selected among an FS optimal set. ASSPRO does not pretend to compete with
established industrial and academic SPL derivation approaches, but offers an agile way of
specifying valid architectural configurations, meeting justified quality requirements; it is a
“front-end” for the automatic product development stage.
RESUMEN
La Arquitectura de Referencia (AR) es utilizada para derivar productos en Líneas de
Productos de software (LPS), quienes conforman una familia de sistemas de software
complejos, que comparten características comunes de un sector del mercado (dominio),
como Sistemas de Información de Salud Integrados. ASSPRO, proceso de asesoría objetivo
del trabajo, trata la configuración de productos concretos, en la primera etapa de derivación
de productos LPS; inicia con AR, grafo conexo o configuración arquitectónica válida,
construida en trabajos previos, por un proceso bottom-up. La “mejor” configuración del
producto es seleccionada entre soluciones factibles (FS) de un conjunto óptimo,
representadas por configuraciones arquitectónicas válidas; para esta evaluación, pesos son
asignados heurísticamente a las FS adecuadas, considerando requisitos funcionales y no
funcionales del cliente. Uno de los mayores problemas en la derivación de productos en una
LPS es el gran número de variantes no funcionales, las cuales son identificadas en ASSPRO
como soluciones que satisfacen requisitos de calidad precisos; la selección de variantes es
realizada aplicando estrategias apropiadas. ASSPRO no compite con métodos establecidos
industriales o académicos, sino ofrece una manera ágil de especificar configuraciones
arquitectónicas válidas, respondiendo a requisitos de calidad justificados; es una entrada
para la etapa de desarrollo automático de productos.
© 2015 IAI. All rights reserved
1. Introduction
A Software Product Line (SPL) is a family of software
intensive systems or products sharing a common and
organized set of features that satisfy specific
requirements of a market sector or domain. These
features are developed from a common set of assets that
are reused in different products of the SPL family [3]. In
consequence, the SPL approach favors reuse and claims to
reduce coding effort and time to market. The SPL
complete development or SPL Engineering (SPLE) is a
complex process that covers two main disciplines,
Domain and Application Engineering [16]. In Domain
Engineering, domain knowledge is captured to construct a
Reference Architecture (RA) and the assets repository; the
RA, also known in the literature as SPL Architecture
(SPLA) [15], is the main artefact shared by all members of
the SPL family and it covers common and variable parts of
the SPL. In the Application Engineering, new concrete
48
products are derived from RA, which is used as an
instantiable schema or framework, and the SPL family and
asset repository are enriched with new elements from the
derived products. SPL variants are differentiated in terms
of features, usually functional requirements (FR),
perceived by the user [9, 18]. However, there are features
that are not visible to the users, the non-functional
requirements (NFR), and in general they are not explicitly
considered at early stages of software development;
however, NFR drive most of the SPL variability. In this
context, the ISO/IEC 25010 Quality Model standard [8]
will be used to specify NFR, to respond to Software
Engineering
best
practices
and
to
facilitate
communication among groups of stakeholders. This
standard quality model translates product quality into
abstract properties or quality characteristics that in
general cannot be measured and are refined into subcharacteristics, until the measurable elements or quality
attributes. Quality characteristics are inherent software
properties, such as usability, efficiency and security, they
change if software changes, in opposition with assigned
properties like cost, price or delivery time, which can
change without changing the software [8]. Figure 1 shows
the ISO/IEC 25010 Quality Model.
Figure 1. ISO/IEC 25010 Quality Model [8]
A problem in SPL product derivation is that many
different requirements, often contradictory, can appear
during the identification of variant components while
instantiating RA constituted by a “core” or set of common
components (CC) and a set of variation points [16],
denoted by <<vp>>, which are composed by a set of
variant components performing similar tasks. RA satisfies
main domain requirements by construction. The set of
<<vp>> conforms the RA variability model [16]. As a result
of the high variability of quality properties, it is not clear
what is the FR selection that is responsible of certain NFR
[19]; Goal-ORiented Engineering (GORE) approaches have
been used to establish traceability between FR and NFR
[1, 7, 14, 15, 20]. Our RA has been constructed by a
bottom-up process [11, 12, 13], based on refactoring
architectures of existing products and captures NFR and
architectural styles from the refactored products, taking
into account these quality aspects and their traceability
w.r.t. FR.
In this work, the architecture of a product is represented
by a connected graph or valid architectural configuration
(P, R), where P are the nodes or components and R, subset
of P  P, is a symmetric relation representing the edges or
connectors of the architecture [13], and each edge is
denoted by aRb with a, b in P. Only the logic view of the
architecture expressing static aspects is considered and
will be specified in UML 2.0, as an ADL (Architecture
Description Language). The bottom-up process consists in
performing the union of the components of each product,
preserving the connections; CC is constituted by the
common components in the union and the non-common
components are considered variants.
The derivation of a concrete software product is the
instantiation of some RA variation point, keeping the CC
core. A feasible solution (FS) is a set of components
satisfying customer FR and NFR, that is consistent when
the constraints among RA components are verified, and
that is working when it holds a correct architectural
behavior w.r.t. a minimal set of FR and NFR. Moreover, the
graph induced by FS in RA is connected; i.e., RAFS = (FS, R)
is a valid architectural configuration. The induced graph
RAFS is defined as an architectural solution or Feasible
Architecture (FA). The RAFS evaluation is defined as its FS
evaluation, i.e., to optimize a set of FA implies to evaluate
and optimize the associated set of FS.
The main goal of this work is to offer an Assessment
Process (ASSPRO) to choose the “best” concrete product
architectural configuration RAFS, among an optimal set of
FS, where FS satisfies consistency, is a working solutions
and is connected,. Each FS is constituted by RA
components, satisfying a specific scenario of quality
requirements, with their architectural solutions [10], [11,
12]. A weight-based heuristic is proposed to evaluate
each FS and select an optimal RAFS, taking into account
trade-offs among domain and customer NFR.
In the Application Engineering discipline [16], three basic
stages conform the SPL derivation process, according to
[6]: Product Specification, Product Development and Onsite product configuration (see Figure 2); the development
stage is concerned with the product implementation
using the SPL asset repository; it implies to retrieve code
of components’ modules, etc. The on-site configuration
refers to the deployment of the demanded product on the
customer work platform. ASSPRO is concerned with the
Product Specification stage.
Our approach will be applied to the Integrated Healthcare
Information Systems (HIS) domain [10, 11, 12, 17]. HIS
are complex information systems, generally located in
different and distant institutions and with mandatory
NFR requirements, such as interoperability, availability
and security. They are supported by a hybrid SOA/Layers
architectural style [10], with SOA (Service-Oriented
Architecture) [21] integrating an Event-Driven Style [22].
HIS must facilitate transparent sharing of different kinds
of medical records, offering also telemedicine services
that can be performed online at remote locations, with
wide information and communication technology
support. Moreover, in actual medical practice, SPL for HIS
have not yet been completely defined, developed and
adopted; the lack of agreement on standards makes
difficult the interoperability of Electronic Health Records
(EHR), a basic HIS functionality, and HIS general adoption
is still difficult. Network providers are now offering HIS
49
cloud solutions, which will not be treated in this work.
According to the studies in [10, 17], the open source
systems OpenEMR, PatientOS with a 90% and 92% usage
respectively and Care2X, similar to OpenEMR, used
recently in health national projects, have been refactored
into the HIS-RA [11] considered in this work (see Figure
4). The HIS domain quality model (HIS-DQM) [8, 11] is
constituted by seven inherent quality characteristics and
sub-characteristics representing HIS domain global NFR;
Figure 3 shows the HIS-DQM.
assessment process for product derivation with the
weight-based heuristic; the fourth section applies ASSPRO
to the HIS domain, and finally the fifth section is dedicated
to main related works.
2. Reference architecture for the his domain
2.1 HIS-RA
The Components and Connectors Table (C&CT), shows the
refactored architectures’ components and their
connectors for the three products considered (see Table 1
for HIS-C&CT).
Table 1. HIS-C&CT: Components and Connectors Table
Figure 2. Assessment Process (ASSPRO) in the SPLE context –
gray blocks concern the present research [6]
Figure 3. HIS-DQM: Quality Model for the HIS Domain – Source:
authors, adapted from [8].
HIS must facilitate transparent sharing of different kinds
of medical records, offering also telemedicine services
that can be performed online at remote locations, with
wide information and communication technology
support. Moreover, in actual medical practice, SPL for HIS
have not yet been completely defined, developed and
adopted; the lack of agreement on standards makes
difficult the interoperability of Electronic Health Records
(EHR), a basic HIS functionality, and HIS general adoption
is still difficult. Network providers are now offering HIS
cloud solutions, which will not be treated in this work.
According to the studies in [10, 17], the open source
systems OpenEMR, PatientOS with a 90% and 92% usage
respectively and Care2X, similar to OpenEMR, used
recently in health national projects, have been refactored
into the HIS-RA [11] considered in this work (see Figure
4). The HIS domain quality model (HIS-DQM) [8, 11] is
constituted by seven inherent quality characteristics and
sub-characteristics representing HIS domain global NFR;
Figure 3 shows the HIS-DQM.
Besides this introduction and the conclusion, this paper is
structured with a second section dedicated to the HIS-RA
description; a third section presenting the ASSPRO
OpenEMR
a. Presentation Layer
Components:
a1. Web pages-Browser
a2. Patient Portal
a3. Reports
Connectors:
a1Ra2
a1Ra3
a1Rd1
a1Rd2
b. Process Layer
Components:
b1. Patient
b2. EHR Management
b3. Report System
Connectors:
b1Rc1
b1Rd1
b1Rd2
b2Rc1
b2Rd1
b2Rd2
b3Rc1
b3Rd1
b3Rd2
c. Data Layer
Components:
c1. Data Base
c2. HL7 CDA Engine
Connectors:
c1Rc2
d. Transmission
Components:
d1. Internet
d2. Satellite
PatientOS
a. Present Layer
Components:
a2
a3
a4. GUI
Connectors:
a4Ra2
a4Ra3
a4Rb5
b. Business logic
Components:
b1. Patient business
model
b2
b3
b4. Mirth (HL7
engine)
b5. GUI – Server Side
Connectors:
b1Rc1
X
b1Rb5
b2Rc1
X
b2Rb4
b2Rb5
b3Rc1
X
b3Rb5
b5Rd1
c. Data Layer
Components:
c1
Connectors:
d. Transmission
Components:
d1
-
Care2x
a. Present Layer
Components:
a1
a2
a3
Connectors:
a1Ra2
a1Ra3
a1Rd1
a1Rd2
b. Process Layer
Components:
b1
b2
b3
Connectors:
b1Rc1
b1Rd1
b1Rd2
b2Rc1
b2Rd1
b2Rd2
b3Rc1
b3Rd1
b3Rd2
c. Data Layer
Components:
c1
c3. HXP Engine
Connectors:
c1Rc3
d. Transmission
Components:
d1
d2
Let us denote by (Pi, Ri), i=1, 2, 3 the valid architectural
configurations of the three products considered, where
Pi is the set of components or nodes and Ri is the set of
edges or connectors.
Let CA = (P, R) be an initial architecture obtained
automatically, where P =  Pi and R =  Ri, i = 1, 2, 3. An
edge aRb  R is variant, and will be denoted by aRb if and
50
only if  i, j such that a, b  Pi  Pj and  a Ri b and  a Rj
b. The fact that a, b  Pi and  a Ri b for some i, was
signaled in Table 1 by “X”. Common and variant
components and connectors are also shown; the “-”
symbol indicates the absence of a specific connector, since
one of its component is absent.
In consequence, from Table 1 we have CA= (P, R), where:
P = {a1, a2, a3, a4, b1, b2, b3, b4, b5, c1, c2, c3, d1, d2},
R = {a1Ra2, a1Ra3, a1Rd1, a1Rd2, a4Ra2, a4Ra3, a4Rb5,
b1Rc1, b1Rd1, b1Rd2, b1Rb5, b2Rc1, b2Rd1, b2Rd2, b2Rb4,
b2Rb5, b3Rc1, b3Rd1, b3Rd2, b3Rb5, b5Rd1, c1Rc2, c1Rc3}.
b7*, c4, c5, c6, c7, c8 and c9*. The connectors of these new
variant components are: b6Rb1, b6Rb3, b7Rb1, b7Rb2,
b7*Rb3, c4Rc1, c5Rc1, c6Rc1, c7Rc1, c8Rc1, c9*Rc1. Note
that this issue is not treated in most of the FODA
approaches [11, 16, 19], where in general only
components functional variability is focused. The “*”
indicates multiple alternatives (see Table 3), Figure 4
shows HIS-RA with <<vp>> denoted by the stereotype
<<component name>>; common components are directly
denoted by their names.
2.2 HIS-RA documentation
RA is described in the Documentation Table (RADT), see
Table 2 for the HIS-RADT. Note that RA has imbedded the
global domain quality properties; the FODA model can be
deduced from the RADT. An ontology-based approach
could also be used to improve the consistency checking to
find the set of FS [5].
2.3 Architectural Solutions
The Architectural Solutions Table (AST), see Table 3 for
the HIS-AST, is constructed from RADT, including
architectural solutions for each variant, their quality
properties with priorities and trade-offs with respect to
the domain quality model.
3. Product derivation from quality-driven feasible
solutions
3.1 Preliminaries
The derivation of a software product is based on the
instantiation of some RA variation points, maintaining CC.
Recall that a feasible solution (FS) is a set of components
satisfying customer FR and NFR, is consistent, working,
and the graph induced by FS in RA is connected, i.e., RAFS =
(FS, R) is a valid architectural configuration. The relation
R will be defined as follows:
Let a, b  FS then aRb is defined by the alternatives:
Figure 4. HIS-RA with variability model [11]
In order to satisfy quality requirements, the initial CA is
completed using the GORE approach [1, 20]. With the
following new components to satisfy quality goals: b6,
 aRb  {xRy : x, y  CC}
 aRb  {x R <<Ai>> for some i and x  CC}
 aRb  {<<Ai>> R <<Aj>> for some i, j}.
Table 2. HIS-RADT: Reference Architecture Documentation Table (RADT)
HIS-RA <<vp>>, components,
connectors
a. Presentation Layer Components
<<a5>> User Interface
CC components, connectors
and <<vp>> variant
components
a1. Web pages – Browser
a4. GUI
a2, a3
Connectors
<<a5>>R<<d3>>
<<a5>>Ra2
<<a5>>Ra3
b. Process Layer Components
<<b8>> Computation modules;
a2. Patient Portal; a3. Reports
Comments/Constraints
- User access control and interaction with main HIS functionalities
and/or Web server
- MVC-based client-side GUI
Constraints: a1 and a4 cannot be executed together, only one of
them can be present in one architectural configuration;
a1 or a4 are mandatory
- Common components to access main HIS functionalities
Constraints: a2 is mandatory; a3 is optional
{a1R d1, a1Rd2, a4Rb5Rd1};
{a1Ra2, a4Ra2};
{a1Ra3, a4Ra3};
b6. Algorithms *
- Computations required for precise results, where * indicates
multiplicity.
Constraints: if b1 or b3 are present, b6 must be also present
51
<<b9>> Security modules
b7. Data Security *
- b7b (solo HTTPS)
- b7+b7a (b7+ HTTP)
- b7+b7b (b7+ HTTPS)
b1, b2, b3
b1. Patient
b2. EHR Manag.
b3. Report System
<<b10>>
<<b11>>
Connectors
b1R<<d3>>
b2R<<d3>>
b3R<<d3>>
b3R<<b8>>
b1R<<b8>>
b1R<<b9>>
b2R<<b9>>
b3R<<b9>>
b2R<<b10>>
b1Rc1; b2Rc1; b3Rc1;
b1Rb5; b2Rb5; b3Rb5;
<<b11>>R<<a3>>
<<b11>>R<<d3>>
c. Data Layer Components
<<c10>> Addition of new medical
standards
<<c11>> Data Integrity
<<c12>> Data Availability
<<c13>> Data Persistency
<<c14>> DB APIs
b4. Mirth Engine
b5. GUI Server-side
{b1Rd1, b1Rd2};
{b2Rd1, b2Rd2};
{b3Rd1, b3Rd2};
{b3Rb6};
{b1Rb6};
{b1Rb7b, b1Rb7+b7a,
b1Rb7+b7b};
{b2Rb7b, b2Rb7+b7a,
b2Rb7+b7b};
{b3Rb7b, b3Rb7+b7a,
b3Rb7+b7b};
{b2Rb4};
b1Rc1; b2Rc1; b3Rc1;
b1Rb5; b2Rb5; b3Rb5;
{b5Ra4};
{b5Rd1};
Connectors
c1R<<c10>>;
c1R<<c11>>;
c1R<<c12>>;
c1R<<c13>>
c1R<<c14>>
c1R<<c15>>
d. Transmission Layer Components
<<d3>> Network
- Common components, main HIS functionalities
Constraints: b1 and b2 must be present, b1 and b2 are mandatory
- HL7 Engine for interoperability in Process Layer
- GUI server side to access main HIS functionalities in Process Layer
and remote services via Internet
- b1Rd1, b2Rd1, b3Rd1 are variant connectors because they are
absent in one of the products
- a1 and a4 instances cannot be present at the same time
- d2 instance cannot be used with b5
c4. New medical standards *
c8. Integrity mechanisms *
c9. Availability mechanisms *
- c9a. Mirror DB
- c9b. Mirror DB with
replication
c7. Hibernate
- Addition of new medical standards (diagnosis catalogues, etc.) for
system scalability (evolution)
- APIs solutions for integrity for each data base
- Mechanisms for data availability: two optional solutions mirror
data base or mirror data base with replication
Constraints: c9a or c9b are optional
- Data persistency mechanism for Java platform
c5. JDBC
c6. ODBC
- APIs solutions for portability to other data bases under Java
platform
- APIs solutions for portability to other data bases
Constraints: c5 or c6 are mandatory
c2. HL7 CDA Engine
c3. HXP Engine
- Interoperability XML/ HL7
- Interoperability XML/HXP
Constraints: c2 or c3 are mandatory
c1. Data Base
- Commercial data base
Constraints: c1 is mandatory
<<c15>> HL7 Data Model Engine
c1. Data Base
- Services or algorithms required to handle card, password,
biometrics data, etc. devices for user authentication and for user
access rights for confidentiality of medical data
- HTTPS internet secure channels protocols for special message
transmission security
- HTTP internet protocols for ordinary message transmission
security
Constraints: Internet communication only via HTTPS or b7+ HTTP
or b7+HTTPS; Internet communication only via HTTP is not
possible due to HIS requirements; only one of the 3 alternatives
b7b, b7+b7a, b7+b7b must be present and it is mandatory
{c1Rc4};
{c1Rc8};
{c1Rc9a, c1Rc9b};
{c1Rc7};
{c1Rc5, c1Rc6};
{c1Rc2, c1Rc3}
d1. Internet
- b7a (HTTP)
- b7b (HTTPS)
d2. Satellite
- b7a (HTTP)
- b7b (HTTPS)
- Request/response for efficient, adequate, available, secure and
interoperable services using Internet protocols. Notice that d1 is a
common mandatory component, however it has been marked as
variant since d2 is an optional alternative variant and they share
the same variation point <<d3>> Network.
Constraints: d1 is mandatory, d2 is optional but it cannot be used
with b5; HTTP or HTTPS are optional; HTTP is impossible without
b7, due to HIS requirements
52
Table 3. HIS-AST: Architectural Solutions Table (AST) with priority assigned to quality properties
HIS-RA <<vp>>
Components
<<a5>> User Interface
<<variant>>
Components (RADT)
a1. Web pagBrowser
Architect.
solution
SOA (eventbased style)
SOAP messages
protocol
(digital
signature)
a4. GUI
<<b8>> Computation
modules
<<b9>> Security
modules
<<b10>> HL7
Interoperability
Engine
<<b11>> GUI Server
<<c10>> Addition of
new medical standards
<<c11>> Data Integrity
<<c12>> Data
availability
<<c13>> Data
persistency
<<c14>> DB APIs
<<c15>> HL7 Data
Model Engine
<<d3>> Network
MVC
architectural
pattern
b6. Algorithms*
Module
b7. Data security*
- b7+b7a (b7 +
HTTP)
- b7b (only HTTPS)
- b7+b7b (b7 con
HTTPS)
Module
b4. Mirth Engine
b5. GUI Server-side
- Module +
protocol
- Protocol
- Module +
protocol
Engine to
translate
XML/HL7
Module
Quality properties for each
<<variant>> with priority [1p3],
1 maximum w.r.t. HIS domain
(1) Availability
(w.r.t network)
Completeness (+), resource utiliz. (+),
time behav. (- )
(1) Interoperability
(w.r.t web services)
Completeness (+), modif. (+),
adaptability (+), time behav. (-),
(2) adaptability-scalability
(w.r.t web services)
Completeness (+), interop. (+), modif.
(+), time behav. (-)
(1) Authenticity,
(1) confidentiality,
(1) integrity
(w.r.t transmission)
(2) Time behavior
(3) Modifiability
Completeness (+), time behav. (-),
resource utiliz. (-)
(3) modularity,
Time behav. (-), resource utiliz. (--),
completeness (+), modif. (+)
Completeness (+), time behav. (--),
resource utiliz. (--)
(1) Authenticity,
(1) confidentiality,
(1) integrity
(2) Time behavior
(2) Correctness-precision
(1) Authenticity,
(1) confidentiality,
(1) integrity
Availability (++)
Time behave. (-), resource utilize. (-),
completeness (+), modif. (-)
Time behav. (-), resource utiliz. (-),
completeness (+), modif. (-)
(3) Modifiability
Time behav. (-), resource utiliz. (--),
completeness (+), adapt. (+)
(3) modularity
Time behav. (-), resource utiliz. (--),
completeness (+), modif. (+)
(2) Time behavior
(3) Modifiability,
(2) adaptability-scalability
(2) Correctness-precision
Availability (++)
Time behave. (-), resource utilize. (-),
completeness (+), modif. (-)
Time behave. (-), resource utilize. (-),
completeness (+), modif. (-)
Completeness (+), resource utiliz. (+),
time behav. (- )
Completeness (++), resource utiliz.
(++), time behav. (-- )
Completeness (+), resource utiliz. (+),
time behav. (-),
Resource utiliz. (-), modif. (+),
completeness (+), time behav. (-)
Modif. (+), completeness (+), resource
utiliz. (-), time behav. (-)
- Copy of DB
- Peer-to-peer,
merge, etc.
(1) Availability
c7. Hibernate
System images
(1) Availability
c5. JDBC
c6. ODBC
c2. HL7 CDA Engine
c3. HXP Engine
API
(2) Adaptability-scalability
Engines for
translation
XML/HL7
(1) Interoperability
Protocols
HTTP/ HTTPS/
Proxy server/
Gateway
Protocols
HTTP/ HTTPS/
Proxy server/
Gateway
(1) Availability
(1) Authenticity,
(1) confidentiality,
(1) integrity
d2. Satellite
Time behav. (-), resource utiliz. (--),
completeness (+), adapt. (+)
Modif. (-), completeness (+), resource
utiliz. (-), time behav. (--)
Module
d1. Internet
Availability (-), modif. (-)
(1) Interoperability
c4. New medical
standards *
c8. Integrity mechan.
*
c9. Availab. Mechan.
- c9a. Mirror DB
- c9b. Mirror DB with
replication
Module
Trade-offs w.r.t. HIS domain quality
model improve (+) (++), worsen (-) (--)
(1) Availability
(1) Interoperability
(1) Availability
(1) Authenticity,
(1) confidentiality,
(1) integrity
Modif. (+), completeness (+), resource
utiliz. (-), time behav. (--)
Completeness (+), authenticity (+),
confidentiality (+), integrity (+),
resource util. (-), time behav.(-),
interoperability (+), adaptabilityscalability (+)
Completeness (+), authenticity (+),
confidentiality (+), integrity (+),
resource util. (-), time behav.(-),
interoperability (+), adaptabilityscalability (+)
53
FS is obtained preserving CC and instantiating those
variation points <<Ai>> corresponding to customer
requirements. The induced graph RAFS = (FS, R) is defined
as a Feasible Architecture (FA). Evaluation and
optimization will be performed on a set of FS, i.e.,
optimize a set of FA implies to evaluate and optimize the
associated set of FS. To evaluate the FS we apply the
following heuristic:
1. A Weight Table (WT) (see Table 4 for the HIS-WT) is
constructed, where the rows are the RA variation
points involving more than one variant, with their
variants, demanded by the customer; the columns are
quality properties also involved in customer
requirements. A weight is assigned by the expert to
each <<vp>> variant, such that their sum is equal to 1.
These weights are assigned according to the
satisfaction to the main domain quality properties,
considering the trade-offs listed in Table AST (see
Table 3 for the HIS-AST), to consider the impact of the
quality properties derived from the customer
requirements, on the variant w.r.t. the global domain
quality properties specified by the DQM (see Figure 3
for the HIS-DQM).
The degree of satisfaction in WT is expressed by +/++
or –/-- on the customer NFR and translated to a
numerical value that is the weight of the variant; 0 is
placed when the variant is not involved with the
quality property. Common components and <<vp>>
with only one variant are assigned a weight of 1 and
are not shown in WT; it has to be noticed that the
weights assigned to the variants of a <<vp>> are
independent from the weights assigned to other
<<vp>> variants.
2. FS Evaluation: is defined as the average of the FS
components’ weights.
3. Find the set of Optimal Feasible Solution (OFS): many
real problems involve simultaneous optimization of
different competing objectives [18]. The expert
obtains OFS considering a subset of FS of greatest
average satisfying the customer demand and that may
compete with other objectives, emphasizing other
customer priority requirements, such as cost.
The above preliminary remarks, with artifacts RADT, AST,
DQM for the specific domain, HIS in our case, and the
customer requirements, are considered to start the
process.
3.2 ASSPRO: Heuristic-based assessment process
for SPL Product Derivation
3.2.1 Preparation for the FS computation
1. From RADT, an initial set B is constructed by the
expert containing common components. Other
components can be included to reflect the customer FR
and NFR necessary to make the product “work”;
however, the required product quality could be only
partially fulfilled. This set is not necessarily an FS.
2. Other variation points <<Ai >> i = 1, 2, ..., s with their
variants from RA, that the expert considers satisfying
NFR which are not fulfilled in the initial B, are chosen
to get the first set of FS; pairs <<Ai>>, <<Aj>> must be
checked to consider alternatives, <<Ai>>OR<<Aj>> or
<<Ai>>XOR<<Aj>>.
3. Once the first FS set is obtained, other variation points
can be instanciated by the expert to increase some of
the required qualities; these instances are added to
the first FS set to obtain a new FS set.
4. The Table WT, obtained from Table AST, customer
requirements and DQM, with the weights for each
variant integrating <<Ai >> i=1, 2, .., s.
Notice that in steps 2 and 3 connectivity checking must be
performed when adding new instances.
3.2.2 Process specification
1. FS computation:
B = B  <<A1>> <<A2>> ...  <<As>>, where B  <<A1>> =
{B  a: a  <<A1>>}. Notice that  is similar to a concat
operator.
If B = {FS(1), FS(2), …, FS(k)} then B  <<Ai>>={FS(j) 
<<Ai>>: j = 1, ..., k}, for some <<Ai>>.
It must be checked for each FS, that RAFS is connected.
This can be done by checking the adjacency matrix
representing RAFS .
2. Compute the average weight for each FS in B.
3. Compute the Optimal set of FS (OFS): Analyze those FS
with the greatest average among all FS, in a range
established by the expert; the optimization objective is
established w.r.t. customer NFR, as it has been already
explained; another optimization objective could be
considered over OFS, for example, the cost, towards a
more accurate choice of the leading FS.
4. Construct the documentation for each FS in OFS.
5. Construct the architectural configurations
RAFS = (FS, R) for the corresponding FS in OFS.
3.2.3 Output
 Display in UML the RAFS present in OFS .
 Discussion with customer about the solutions offered
in OFS with the documentation, showing also the RAFS
of the most adequate FS in OFS, considered by the
expert.
4. Applying ASSPRO to the his domain
4.1 Preparation for the FS computation
1. Customer requirements for a new HIS
Assume that customer requirements for a new
product of the HIS SPL family are the following:
A web-based system of low cost (priority
requirement) to handle basic functionalities of patient
data, HER management, besides medical reports and
statistics with some administrative services, Java
platform and Oracle database. For this study, if a
customer requirement cannot be accomplished with
the present RA, it will not be considered; else, the
option of extending RA with the new requirements
should be studied.
54
The expert extracts the following inherent quality
requirements from the HIS DQM: interoperability,
security (authenticity, confidentiality, integrity) for
HER, data adaptability-scalability, and HER availabilitypersistency [8].
Effect on global
cost of product
Weight
a1. Web pages
a4. GUI
c5. JDBC
c6. ODBC
c2. HL7 CDA
Engine
c3. HXP Engine
+
0
0
0
++
+
+
0
0
0
+
+
0
0
0
+
+
0
0
0
++
0
0
0
+
++
++
+
0
+
-
-++
0
0
-
0.8
0.2
0.8
0.2
0.7
+
0
0
0
0
0
+
0.3
b7+ b7a
(b7+HTTP)
b7b (only
HTTPS)
b7+b7b
(b7+HTTPS)
d1. Internet
d2. Satellite
0
+
+
+
+
+
-
-
0.4
0
+
-
+
-
-
+
--
0.5
0
+
+
+
+
+
-
++
0.1
+
+
+
+
+
+
+
+
-
+
+
-
++
0.8
0.2
HIS-RA
Variant
components
Time behaviour
{FS(46), FS(47), …, FS(90}} = {FS(1), FS(2), …, FS(15),
…, FS(45)} Δ c8 = {FS(1)  c8, FS(2)  c8, …, FS(45) 
c8}.
Adaptability—
scalability
We get 30 FS that added to the first 15 FS give 45 FS
considering additional availability. Now, additional
security <<c11>> = c8 is added to obtain:
Availabilitypersistency
To get more availability, <<c12>> = {c9a, c9b} is added:
{FS(16), FS(17), …, FS(45)} = {FS(1), FS(2), …, FS(15)}
 {c9a, c9b} = {FS(1) c9a, FS(2)  c9a, …, FS(15) 
c9a, FS(1)  c9b, FS(2)  c9b, …, FS(15)  c9b}.
Integrity
3. III. Additional variation points to increase quality
requirements can be used to construct another set of FS,
besides the first one.
Confidentiality
{FS(1), FS(2), …, FS(15)} = B Δ <<b9>>Δ (<<b10>> OR
<<c15>>) = {a1, a2, a3, d1, b1, b2, b3, b6, c1, c4, c5, c7} Δ
{b7b, b7+b7a, b7+b7b} Δ {b4, c2, c3, {b4, c2}, {b4, c3}}.
Customer
Quality
Req.
Authenticity
2. Other variation points required to construct the first set
of FS.
In the HIS case, <<Ai >> are security, interoperability
and availability. In general, the expert can recommend
a minimal set of <<vp>> that must be present to obtain
a first set of FS. In the HIS case, availability is already
present in initial B with c7. Hibernate for persistency;
security
<<b9>>=
{b7b,
b7+b7a,
b7+b7b},
interoperability <<b10>> = {b4} OR <<c15>> = {c2, c3} =
{b4, c2, c3, {b4, c2}, {b4,c3}} are considered to obtain
the 15 first FS;:
Table 4. HIS-WT: Weights Table (WT) - in gray components
favoring lower cost
Interoperability
 Construction of the initial set B
In our case, B = {a1, a2, a3, d1, b1, b2, b3, b6, c1, c4,
c5, c7} contains mandatory common components
that will be shared by all FS, and notice that B is not
necessarily an FS; component b6. Precision is
required by b1 and b3. On the other hand, c1. Data
Base is mandatory for HIS and customer requires
Oracle/Java, then we have c5. JDBC; c4. Addition of
new medical standards satisfies scalability
customer requirement; instead, c7. Hibernate for
persistency is placed by the expert because a low
cost system is required and other safeguard
mechanisms can increase the global cost.
property [8], and it was added to the set of the
customer “inherent” quality properties to consider the
effects of the variants selection on the global cost.
Since the customer requires a minimal cost, the global
weight of the variant will be greater if cost decreases.
The expert plays a very important role to identify the
adequate trade-offs involved.
4.2 ASSPRO for HIS SPL product derivation
1. Computation of the FS set
90 FS are obtained, as it was explained in section 4.1.
In case of considering the expression <<b10>>XOR
<<c15>> instead of <<b10>> OR <<c15>>, we get the
first 54 FS.
2. Computation of the weight’s average for each FS in B
Notice that the global cost of the product in Table WT
is an “assigned” software quality property, and it was
added to the set of the customer “inherent” quality
properties to consider the effects of the variants
selection on the global cost. Since the customer
requires a minimal cost, the global weight of the
variant will be greater if cost decreases. The expert
plays a very important role to identify the adequate
trade-offs involved (see Tables 3 and 4).
We get 45 new FS considering additional security. 90 FS is
obtained. Notice that the 90 FS are consistent by
construction and they are working solutions, since they
have CC and fulfill in some measure all priority quality
requirements. They are shown in the Appendix. Notice
that RAFS is connected since RAB is connected and the
<<vp>> considered to be operated with Δ are connected to
RAB. The <<vp>> instantiation must be checked against
the constraints present in RADT for consistency checking.
3. Computation of the set of Optimal FS (OFS)
Let FS(i) w be the ith FS and FS(i) w its weight. The
“best” solutions with greatest averages within the
interval [0.89, 0.91] of the 90 FS is selected, FS(2)w =
0.90, FS(47)w = 0.91, FS(7)w=0.89, FS(52)w = 0.90,
FS(62)w = 0.89 (see them in gray in the Appendix),
FS(47) is optimal w.r.t. customer and domain inherent
quality properties. Now, these FS can be checked
against the cost, as an additional optimization
objective, and FS(2) is optimal w.r.t. minimal cost,
since it provides a lower cost, in spite of having
FS(2)w<FS(47)w .
4. IV. Computation of Table HIS-WT.
Notice that the global cost of the product in HIS-WT
(see Table 4) is an “assigned” software quality
4. Construction of the Documentation for each FS in OFS
Two examples of FS documentation are provided in
what follows, for FS(47) which is optimal w.r.t
55
inherent customer and domain priority quality
properties, and FS(2) which is optimal w.r.t. the cost
assigned quality property. All FS in OFS must be
documented to be presented for final assessment to
the customer, to decide on product adoption.
 FS Documentation
some data availability; security level is minimal
since it only uses HTTPS in message
transmission; Oracle data base is also portable to
Java platform with c5.
5. Construction of the architectural configuration RAFS =
(FS, R).
 Description of FS(47) components and justification
of accomplished quality properties
FS(47) = {a1, a2, a3, d1, b1, b2, b3, b6, b7b, c1, c2,
c4, c5, c7, c8} with 15 components, where: a1.
Web pages – Firefox Browser, hybrid style
SOA/Layers; complete availability of Web Server
cannot be guaranteed by SOA [21], then
completeness is affected; to decrease response
time in web pages display, Apache and PHP with
AOdb library can be used; a2, a3 access HIS
functionalities, d1. Internet (SOAP for digital
security/HTTPS, besides Internet Access Control
Service; b1, b2, b3 are HIS functionalities, b6.
Algorithms guarantee precision on patient
information and medical reports; b7b. Data
security, only considers the HTTPS/Internet
Security service option; b1, b2 y b3 can access d1
also with HTTP or HTTPS; c1. Data Base, with c5.
JDBC API for Oracle and Java platform portability;
c2: HL7 CDA Engine to translate HL7 to XML, for
HER interoperability, increasing response time;
c4. New medical standards for scalability means to
consider increase in resources; c8. Integrity, to
guarantee that medical data is not corrupted is
included as an additional option by the expert to
increase minimal security level: c7. Hibernate, for
persistency to have availability in Data Layer
without special safeguard mechanisms, since a
low cost system is demanded.
 Evaluation of FS(47)
FS(47) decreases response time, increases
resource utilization, in consequence it increases
global cost; quality of service for security is low,
however c8, a component for integrity is added to
increase this quality of service; since availability
only depends on Internet protocols, a persistency
component, c7, is also present. Oracle database is
portable to Java platform with c5.
 Description of FS(2) components and justification
of accomplished quality properties
FS(2) = {a1, a2, a3, d1, b1, b2, b3, b6, b7b, c1, c2,
c4, c5, c7} with 14 components. The only
difference w.r.t. FS(47) is the integrity component
c8, which is missing in FS(2).
 Evaluation of FS(2)
It is a lower cost solution than FS(47), with fewer
components and less response time. And low
availability since it depends on the availability of
the Web Server /Internet connection in
Transmission Layer; however it has a data
persistency mechanism in Data Layer to have
Figure. 4. Architecture of the new product RAFS(2) = (FS(2), R) Source: authors
4.3 Output
 Display in UML of all RAFS in OFS. Figure 4 shows the
architectural configuration for RAFS(2) = (FS(2), R) in
UML.
 Assessment for optimal FS. RAFS(2) = (FS(2), R) is shown
in Figure 4 as the minimal cost solution, even if it is
not optimal w.r.t. customer and domain quality
properties,
since
FS(2)w<FS(47)w.
All
FS
documentation in OFS with the respective evaluation
is also presented, see FS(2) documentation. Notice that
FS(2) is preferred over FS(47) and FS(52), since these
solution have the c8. Integrity component, increasing
cost of both solutions. FS(2) is compliant with
demanded FR, and NFR and with the low cost
requirement. In conclusion FS(2) is the lowest cost
solution in resources and time behavior, however it is
less secure and reliable; however, the customer may
consult also the assessment for FS(47) optimal w.r.t.
“inherent” domain and customer NFR. It is clear that
these solutions are only a simple example to illustrate
our approach. The case study shows the need of
automatic tool support for the assessment process, as
in most of the derivation approaches in industrial
scenarios.
5. Related works
ASSPRO concerns the specification of the product as the
first stage of the SPL derivation process, and it involves
the stage for the derivation of the product architectural
configuration (see Figure 1). The stage of product
configuration is discussed, with two approaches, assembly
and configuration selection in [4]; three types of assembly
56
approaches are identified, construction, generation and
composition. We are concerned here with construction
and generation.
Assembly – Construction. This approach, similar to ours,
starts deriving the product architecture from the
components of RA. The last step is to provide the
parameters for each component with their respective
values to select [4]. Within this approach, we have:
Product derivation from RA: these works are related with
derivation from RA and not from the feature model. An
interesting work is that of Durán-Limón and others [5],
which use an ontology combined with the MDA (Model
Driven Architecture) approach to define transformation
rules for the derivation of the new product. They
consider, as we do, variability of components and
connectors, but not explicitly the variability of NFR
related to FR or domain, nor their specification with a
standard quality model.
Assembly – Generation: for the initial configuration, the
shared artifacts are modeled by a modeling language.
Many works on SPL product derivation using MDA
approaches are found [2, 7], essentially focusing product
derivation from FODA models [9, 16]. They are widely
used in industrial and academic scenarios; however the
feature model structure is not an architecture; only FR are
specified by FODA, and NFR are missing [7], [14], [18],
[19]; to get the RA, other models and transformations
must be created, the modules connections are not
explicitly specified either. Many of the approaches studied
are supported by automatic tools such as GenArch [2] and
SPL Conqueror [19], which inspired parts of this work. In
[2], [7], [14] important literature reviews can be found on
the SPL product derivation topic.
6. Conclusion
ASSPRO, for concrete product configuration, within the
SPL product derivation stage of the Application
Engineering discipline, has been presented. The
process starts with RA with imbedded domain
knowledge, and not from a feature model [9], as many
derivation approaches do [7], [16] since they do not
consider quality properties associated to FR or global
domain NFR, which drive most of the SPL variability as
much as the FR. A heuristic is used to compute weights
on the quality of the RA components and w.r.t.
customer requirements, to choose an optimal FS,
providing justified documentation. The heuristic may
appear naive for the simple weight average
computation; however, a much more complex formula
can be introduced, since the process is general. The
combinatorial explosion produced by the NFR
variability is trimmed by the  operation to construct
valid FS and by connectivity checking. We do not
pretend to compete with sound approaches used in
academic and industrial scenarios for SPL product
development from reusable code assets [2], [7], [14],
[18], [19]; nevertheless, ASSPRO can be used as a
“front-end” in any of these approaches. A limitation is
that expert knowledge plays a major role; however,
this aspect is shared by most of the known SPL
engineering approaches. In future works the
ontological approach [5] will be exploited to improve
the specification of the product configuration from the
domain knowledge gathered in RA. The ASSPRO
support tool is now under construction.
Acknowledgment
This work has received partial support from different
national projects and institutions: projects PEII DISoft
2011001343 of Fonacit, Venezuela and DARGRAF PG
03-8730-2013-1 of the CDCH (Consejo de Desarrollo
Científico
y
Humanístico),
Venezuela
Central
University, the Postgraduate Studies of Computer
Science, Faculty of Science, Venezuela Central
University, and the Banco Cemtral de Venezuela (BCV).
References
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
Chung, L. et al. (2000). Non-Functional Requirements in
Software Engineering. USA: Springer.
Cirilo, E., Kulesza, U. & Pereira, C. (2007). GenArch – A
model-based product derivation tool. Proceedings
Simpósio brasileiro de componentes, arquitetura e
reutilização de software (pp. 31-44). Campinas, Brasil.
Clements, P. & Northrop, L. (2001). Software product lines:
Practices and patterns. Readings: Addison Wesley.
Deelstra, S., Sinnema, M. & Bosch, J. (2005). Product
derivation in software product families: A case study.
Journal of Systems and Software 74(2), pp. 173-194.
Durán, H., Castillo, F. & López, R. (2011). Towards an
ontology-based
approach
for
deriving
product
architectures. Proceedings of the 15th International
Software Product Line Conference (Article 29). Munich,
Germany.
Elsner, C. (2012). Automating staged product derivation
for heterogeneous multi–product-lines. P.h.D Thesis.
Friedrich-Alexander-Universität, Germany.
González, J. (2014). Derivación, evaluación y mejora de la
calidad de arquitecturas software en el desarrollo de
líneas de producto software dirigido por modelos. P.h.D
Tesis. Universidad Politécnica de Valencia, España.
ISO/IEC (2011). Systems and software engineering Systems and software Quality Requirements and
Evaluation (SQuaRE). System and software quality models,
ISO/IEC JTC1/SC7/WG6. USA: ISO.
Lee, K., Kang, K. & Lee, J. (2002). Concepts and guidelines
of feature modeling for product line software engineering.
Proceedimngs 7th International Conference on Software
Reuse: Methods, Techniques, and Tool (pp. 62-77). Austin,
USA.
Losavio, F., Ordaz, O. & Santos, I. (2015). Proceso de
análisis del dominio ágil de sistemas integrados de salud
en un contexto venezolano. ENL@CE 12(1), pp. 101-134,
Losavio, F., Ordaz, O. & Esteller, V. (2015). Quality-based
bottom-up design of reference architecture applied to HIS.
Proceddings 9th International Conference on Research
Challenges in Information Science (pp. 76-81). Athens,
Greece.
Losavio, F., Ordaz, O. & Levy, N. (2014). Refactoring graph
for reference architecture design process. Proceedings
Journées Nationales GDR GPL - AFADL - CAL - CIEL 2014
(pp. 1-6). Paris, France.
Losavio, F. et al. (2013). Graph modelling of a refactoring
process for product line architecture design. Proceedings
XXXIX Latin American Computing Conference (pp. 1-12).
Naiguata, Venezuela.
Luimnigh, O. (2010). Towards a product derivation
process reference model for software product line
organisations. P.h.D Thesis. University of Limerick, Ireland.
57
[15] Matinlassi, M. (2004). Comparison of software product line
architecture design Methods: COPA, FAST, FORM, KobrA
and QADA. Proceedings 26th International Conference on
Software Engineering (pp. 127-136). Edinburgh, UK.
[16] Pohl, K., Böckle, G. & Linden, F. (2005). SPL Engineering Foundations, principles, and techniques. USA: Springer.
[17] Samilovich, S. (2010). OpenEMR – Historia Clínica
Electrónica de codigo abierto y distribuicón gratuita, apta
para su uso en el sistema de salud Argentina. Proceedings
CAIS 2010 Congreso Argentino de Informática y Salud.
Buenos Aires, Argentina.
[18] Sayyad, A. et al. (2013). Optimum feature selection in SPL:
Let your model and values guide your search. Proceedings
First International Workshop on Combining Modelling and
[19]
[20]
[21]
[22]
Search-Based Software Engineering (pp. 22-27). San
Francisco, USA.
Siegmund, N. et al. (2012). SPL-Conqueror: Toward
optimization of non-functional properties in SPL. Software
Quality Journal 20(3), 487-517.
Supakkul, S. & Chung, L. (2004). Integrating FRs and NFRs:
A use case and goal driven approach. Lecture Notes in
Computer Science 3647, pp. 29-41.
Booth, D. et al. (2004). Web services architecture
requirements. USA: World Wide Web Consortium.
Shaw, M. & Garlan, D. (1996). Software architecture:
Perspectives on an emerging discipline. New York:
Prentice Hall.
APPENDIX
Table of FS obtained by ASSPRO – the FS belonging to the OFS set are shown in gray
a1
a2
a3
d1
b1
b2
b3
b6
c1
Components & Weights
c4 c5 c7 b7b b7+b7a
FS(1)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(2)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(3)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(4)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
0.2
FS(5)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
0.2
FS(6)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(7)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(8)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(9)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
0.2
FS(10)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
0.2
FS(11)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(12)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(13)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(14)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
0.2
FS(15)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
0.2
FS(16)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(17)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(18)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(19)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
0.2
FS(20)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
0.2
FS(21)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(22)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(23)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(24)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(25)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(26)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(27)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(28)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(29)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
0.2
FS(30)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
0.2
FS(31)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(32)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(33)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(34)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
0.2
FS(35)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
0.2
FS(36)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(37)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(38)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(39)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
0.2
FS(40)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
0.2
FS(41)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
FS
b7+ b7b
b4
c2
c3
Average
Total
12.1/14
0.86
12.6/14
0.90
12.2/14
0.87
12.8/15
0.85
12.4/15
0.83
12.0/14
0.86
12.5/14
0.89
12.1/14
0.86
12.7/15
0.85
12.3/15
0.82
11.7/14
0.84
12.2/14
0.87
11.8/14
0.84
12.4/15
0.83
12.0/15
0.80
0.6
12.7/15
0.85
0.6
13.2/15
0.88
0.6
12.8/15
0.85
0.6
13.4/16
0.84
0.6
13.0/16
0.81
0.6
12.6/15
0.84
0.6
13.1/15
0.87
0.6
12.7/15
0.85
0.6
13.3/16
0.83
0.6
12.9/16
0.81
0.6
12.3/15
0.82
0.6
12.8/15
0.85
0.6
12.4/15
0.83
0.6
13.0/16
0.81
0.6
12.6/16
0.79
0.4
12.5/15
0.83
0.4
13.0/15
0.87
0.4
12.6/15
0.84
0.4
13.2/16
0.83
0.4
12.8/16
0.80
0.4
12.4/15
0.83
0.4
12.9/15
0.86
0.4
12.5/15
0.83
0.4
13.1/16
0.82
0.4
12.7/16
0.79
0.4
12.1/15
0.81
c9a
c9b
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.2
0.7
0.2
0.3
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.1
0.2
0.7
0.3
c8
58
FS(42)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(43)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
0.7
FS(44)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
0.2
FS(45)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
0.2
FS(46)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(47)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(48)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(49)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
0.2
FS(50)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
0.2
FS(51)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(52)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(53)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(54)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
0.2
FS(55)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
0.2
FS(56)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(57)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(58)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(59)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
0.2
FS(60)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
0.2
FS(61)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(62)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(63)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(64)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
0.2
FS(65)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
0.2
FS(66)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(67)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(68)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(69)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
0.2
FS(70)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
0.2
FS(71)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(72)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(73)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(74)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
0.2
FS(75)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
0.2
FS(76)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(77)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(78)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
FS(79)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
0.2
FS(80)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.5
0.2
FS(81)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(82)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(83)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
FS(84)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
0.2
FS(85)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.4
0.2
FS(86)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(87)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(88)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
FS(89)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
0.2
FS(90)
0.8
1.0
1.0
0.8
1.0
1.0
1.0
1.0
1.0
1.0
0.8
1.0
0.1
0.2
0.4
12.6/15
0.84
0.4
12.2/15
0.81
0.4
12.8/16
0.80
0.4
12.4/16
0.78
1.0
13.1/15
0.87
1.0
13.6/15
0.91
1.0
13.2/15
0.88
1.0
13.8/16
0.86
1.0
13.4/16
0.84
1.0
13.0/15
0.87
1.0
13.5/15
0.90
1.0
13.1/15
0.87
1.0
13.7/16
0.86
1.0
13.3/16
0.83
1.0
12.7/15
0.85
1.0
13.2/15
0.88
1.0
12.8/15
0.85
1.0
13.4/16
0.84
1.0
13.0/16
0.81
0.6
1.0
13.7/16
0.86
0.6
1.0
14.2/16
0.89
0.6
1.0
13.8/16
0.86
0.6
1.0
14.4/17
0.85
0.6
1.0
14.0/17
0.82
0.6
1.0
13.6/16
0.85
0.6
1.0
14.1/16
0.88
0.6
1.0
13.7/16
0.86
0.6
1.0
14.3/17
0.84
0.6
1.0
13.9/17
0.82
0.6
1.0
13.3/16
0.83
0.6
1.0
13.8/16
0.86
0.6
1.0
13.4/16
0.84
0.6
1.0
14.0/17
0.82
0.3
0.7
0.3
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.7
0.3
0.2
0.7
0.3
0.7
0.3
0.6
1.0
13.6/17
0.80
0.4
1.0
13.5/16
0.84
0.4
1.0
14.0/16
0.88
0.4
1.0
13.6/16
0.85
0.4
1.0
14.2/17
0.84
0.4
1.0
13.8/17
0.81
0.4
1.0
13.4/16
0.84
0.4
1.0
13.9/16
0.87
0.4
1.0
13.5/16
0.84
0.4
1.0
14.1/17
0.83
0.4
1.0
13.7/17
0.81
0.4
1.0
13.1/16
0.82
0.4
1.0
13.6/16
0.85
0.4
1.0
13.2/16
0.83
0.4
1.0
13.8/17
0.81
0.4
1.0
13.4/17
0.79
59