Mapping feature optional (feaOpt)

Descr ipción: los features de tipo optional son aquellos que solo formarán parte de los sistemas generados dentro de la familia, si son seleccionados durante el proceso de configuración. La Figura 4.11 expresa las componentes que están involucradas en el mapping, y una especificación RSL formaliza esta descripción, con los siguientes los elementos involucrados en el mapping:

• un scheme cuyo nombre viene dado por el feature name,

• la cláusula extend parent_name expresando la que el feature optional mapeado es una extensión de un feature padre con un tipo de interés.

• la cláusula value dentro del scheme donde se expresan las siguientes propiedades:

o isSolitary con valor TRUE si no está formando parte de ningún

agrupamiento o con valor FALSE si pertenece a algún agrupamiento,

o isMandatory con valor FALSE ,

o isSelected con valor TRUE.

• la cláusula context parent_name expresando el feature que formará parte del

contexto.

• el scheme correspondiente al feature padre ya ha sido derivado, pudiendo ser

éste el feature concept o cualquier otro feature.

Figura 4.11 Transformación feature optional

Ejemplo: Desde el punto de vista del metamodelo y de acuerdo a la fracción de ejemplo presentado en la Figura 4.12 donde los subfeatures del feature Payment types son todos features de tipo optional, se presenta una configuración posible.

Figura 4.12 Features optional CreditCard, DebitCard, etc

Se puede observar en el modelo de objetos (Figura 4.13) que la transformación tendrá lugar con los siguientes elementos:

§ el objeto CreditCard es una instancia de la metaclase Feature

o atributos:

§ isSelected: TRUE

§ isSolitary: FALSE

§ isMandatory: FALSE

§ el objeto Payment Types es una instancia de la metaclase Feature

o atributos:

§ isSelected: TRUE

§ isSolitary: FALSE

§ isMandatory: TRUE

el enlace correspondiente desde el objeto feature CreditCard, el objeto feature PaymentTypes mediante la relación subfeature al objeto PaymentTypes y los distintos features que forman parte de esta asociación.

Figura 4.13 Modelo de objetos PaymentTypes - CreditCard

El feature Payment Types perteneciente a la categoría de los Capability features, se modela como un feature abstracto que relaciona distintos tipos de medios de pago para el eShop, entre ellos CreditCard, siendo éste derivado como un scheme RSL que extiende al tipo PAYMENTTYPES como se puede observar en la especificación que se muestra en la Figura 4.14.

context: PAYMENTTYPES scheme CREDITCARD = extend PAYMENTTYPES with class type value isSolitary: Boolean=FALSE isMandatory:Boolean=FALSE isSelected:Boolean=TRUE ... axioms ... end

scheme PAYMENTTYPES= class type value isSolitary:Boolean= FALSE isMandatory:Boolean=TRUE isSelected:Boolean=TRUE ... axioms ... end

Figura 4.14 Módulos RSL derivados de la transformación

Luego de un refinamiento en la especificación RSL, el módulo

PAYMENTTYPES será un módulo perteneciente al conjunto de servicios que se acceden a través de un conjunto de interfaces. Las interfaces están divididas en operaciones Front-end y Back-end. Una especificación RSL completa para este tipo de features contendrá:

• el scheme PaymentTypes

• un conjunto de funciones (values) abstractas que identifican operaciones del front-end del Payment types como por ejemplo la de validación de los medios de pago (validate_pt ()).

• un módulo scheme “TYPES” como cuya especificación será válida para

todos los tipos del modelo declarando un nombre de objeto de ese tipo para el uso en la especificación.

• la cláusula context TYPES permitiendo la visibilidad de este módulo a otros módulos.

Además, los features Credit card, Debit card, COD, Electronic cheque, y los restantes también serán mapeados como shemes RSL conservando el nombre. Estos features serán extensiones del scheme PaymentTypes. Los schemes contendrán records con campos representando atributos y una extensión (especialización) del PaymentTypes scheme. Los atributos en una especificación final de estos schemes representan la información relacionada con: nombre del titular, número, tipo, código de seguridad, fecha de expiración y demás elementos relacionados con este contexto. En las siguientes especificaciones se observa como se declaran las funciones de validación en cada una de las especificaciones: validate_cc(), validate_dc(), validate_cod(), validate_ech()) y funciones para acceder y modificar el tipo (getType(), SetState ()). La especificación final contendrá elementos como los que se muestran en la Figura 4.15.

Figura 4.15 Especificaciones RSL PaymentTypes y CreditCard

RSL PaymentTypes RSL CreditCard

scheme TYPES = class type

Date, PY_ID, end

context TYPES

scheme PAYMENTTYPES = class object T: TYPES

type

Payment types :: PTid: T. PT_ID ValidDate:T.Date

value

validate_pt : Payment types -> Bool …

end

scheme CREDITCARD= extend PAYMENTTYPES with class

object T: TYPES type

Payment Type=

PAYMENT TYPE.Payment Type

CreditCard= {|o:Payment Type: is_a_CreditCard (o)|}

Payment types :: PTid: T. PT_ID

StateCard==Valid| Invalid | Stolen | Lost | Cancelled TypeCard == International | Gold | Platinum ….

value

validate_cc: CreditCard Bool, getType: CreditCard TypeCard,

setState: CreditCard x StateCard CreditCard axiom

… end

Tr ansfor mación ATL

Como para el caso de la transformación del feature mandatory, esta transformación contiene la misma ´matched rule´ primaria que se usa para la transformación descripta anteriormente: rule fea2SchSpec. Esta regla permite hacer el matching de los features de tipo optional a un scheme RSL. Para cada feature, la regla identifica su nombre y realiza las correspondientes asociaciones con sus atributos y relaciones. Para definir los atributos y relaciones se proponen las ´lazy rules´ como así también los ´helpers´. El código ATL correspondiente se encuentra en el Anexo B.