Software Product Lines - Science topic

Hola Hauwa,

Tomando como base que una característica en este modelo es un elemento distintivo el cual es percibido por el usuario final del producto a generar, considero que sí es factible crear al menos los casos de prueba de sistema, haciendo uso de escenarios que integren la asociación de características de cada componente de software con las características del resto de los componentes (incluyendo su despliegue en la infraestructura). De alguna forma, esto también le permite a la empresa explotar todas combinaciones de características que pudiera brindarle a un cliente a través de diferentes versiones del producto. En cuanto a pruebas de integración, si este modelo en un alto nivel de abstracción le está permitiendo realizar la asociación de características de diferentes componentes de software, entonces implícitamente también se pueden trazar en el siguiente nivel de abstracción todas las pruebas de interfaces de conexión para el cumplimiento de las funcionales de cada componente de software. En cuanto a las pruebas unitarias, estas dependerán de la forma en que tenga documentado el diseño detallado y la forma en que lo implemente del equipo de desarrollo.

Mehwish Sundas You can use FaMa and SPLOT for SPL practice.

You can also use S.P.L.O.T tool. It is online tool and very useful .

@Jaime Chaverriaga Thank you for your valuable answer

You may try  FAMA tool suite

Hi !

I can recommend you those two references :

 - Metzger, A. & Pohl, K. - Software Product Line Engineering and Variability Management: Achievements and Challenges, 2014

 - Krueger, C., Clements, P. - Systems and software product line engineering, 2013

Regards

Mr. Shallangwa,

Please pay attention to the following discussions:

The program package is Gaussian (www.gaussian.com)

Thank you sir

Concerning other techniques for SPLE transitioning -- colleagues and I have developed a refactoring-based technique to transition towards an SPL (see links below).

This technique lets the engineer stay in control on variability design (automates clicking for refactorings). The variability model / SPL design, which is often strategic, stays as human task.

The approach was developed on modeling level, but could be realized on code level as well (e.g, by using OO-polymorphism as refactoring targets).

http://www.zora.uzh.ch/73131/1/20130201230110_merlin-id_7409.pdf (chapter 10)

There it goes:

Sample Spaces and Feature Models: There and Back Again

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4626837&tag=1

I guess it's kinda related to what your thinking into.

Regards!

The selfish answer: URML, see my profile.

But, of course I should refer to FODA by Kang et al., a revision of FODA is FORM . You should also look into the book by Krysztof Czarnecki, Ulrich Eisenecker: "Generative Programming: Methods, Tools, and Applications: Methods, Techniques and Applications".

A review paper I recently found is

V. Vranić, “Reconciling Feature Modeling: A Feature Modeling Metamodel,” in Object-Oriented and Internet-Based Technologies, vol. 3263, M. Weske and P. Liggesmeyer, Eds. Springer Berlin / Heidelberg, 2004, pp. 245–255.

A relationship of requirements to features, that relates Jacksons work to features:

A. Classen, P. Heymans, and P.-Y. Schobbens, “What’s in a Feature: A Requirements Engineering Perspective,” in Fundamental Approaches to Software Engineering, vol. 4961, J. Fiadeiro and P. Inverardi, Eds. Springer Berlin / Heidelberg, 2008, pp. 16–30.

It is also my impression that context-oriented programming encompasses feature-oriented programming in the sense that you could consider (certain) contexts as features, and on the condition that you have a context-oriented language which provides support for declaring (and verifying at run-time) feature-like dependency relations between contexts (as is for example the case in the Subjective-C language). But what about my other questions :

Can feature-oriented programming learn from context-oriented programming to enable for more dynamicity?

Can context-oriented programming take inspiration from feature-oriented programming and software product lines to offer more control and guarantees about the program's dynamic behavior?

Should/will they eventually merge into a single paradigm that takes the best of both worlds?

You may have a look here:

In this book "Software Product Line- A Ruled-Based Approach: Automated validation of software product lines using first order logic rules"

there are some operations could be used as metrics for both domain-engineering and application-engineering processes.