Mostrando entradas con la etiqueta SPL. Mostrar todas las entradas
Mostrando entradas con la etiqueta SPL. Mostrar todas las entradas

lunes, 29 de octubre de 2012

SPL en pequeñas empresas


Effective development of automation systems through
domain-specific modeling in a small enterprise context



High development and maintenance costs and a high error rate are the major problems in the development of
automation systems, which are mainly caused by bad communication and inefficient reuse methods. To overcome these problems, we propose a more systematic reuse approach. 

Though systematic reuse approaches such as software product lines are appealing, they tend to involve rather burdensome development and management processes. This paper focuses on small enterprises. Since such companies are often unable to perform a “big bang” adoption of the software product line, we suggest an incremental, more lightweight process to transition from single-system development to software product line development. Besides the components of the transition process, this paper discusses tool selection, DSL
technology, stakeholder communication support,  and business considerations. Although based on problems from the automation system domain, we believe the approach may be general enough to be applicable in other domains as well. The approach has proven successful in two case studies. First, we applied it to a research project for the automation of a logistics lab model, and in the second case (a real-life industry
case), we investigated the approaches suitability for fish farm automation systems



http://download.springer.com/static/pdf/469/art%253A10.1007%252Fs10270-012-0289-1.pdf?auth66=1351512547_48997887e84e0044a96808afbdda8db4&ext=.pdf (vía @jlroda)

miércoles, 17 de agosto de 2011

miércoles, 15 de junio de 2011

Biglever and Pure-Systems - SPL

Empresa especializada en SPL su producto GEAR
http://www.biglever.com/
http://www.biglever.com/extras/BigLever_Solution_Brochure.pdf
http://www.biglever.com/extras/Gears_Data_Sheet.pdf


http://www.pure-systems.com/
http://www.pure-systems.com/Downloads.31.0.html
http://www.exmotion.co.jp/service/spl_demo_movie_en.asx

Congreso SPL 2001 en Munich

Congreso SPL 2001
http://www.splc2011.net/tutorials/index.html

lunes, 6 de junio de 2011

SPL

http://grandview.rymatech.com/2009/15-introduction-to-the-sei-framework-for-software-product-line-practice.html

http://grandview.rymatech.com/2009/16-software-product-lines-an-effective-business-and-development-strategy.html

http://grandview.rymatech.com/2010/30-exploring-product-line-opportunities.html

http://grandview.rymatech.com/2009/46-towards-compositional-software-product-lines.html

http://www.cs.helsinki.fi/u/vjkuusel/gradu/vanhat/Software%20Product%20Lines.pdf

martes, 3 de mayo de 2011

MDA vs. MDD vs. SPL vs. DSL

Ayer, escribiendo un artículo se planteo una duda formal en la frase

"En el diseño del DSL se ha evitado la inclusión de elementos de asociados a la tecnología intentando  aumentar al máximo el nivel de expresividad del mismo acerdándolo al dominio del problema."
Algunos opinan que era incorrecta otros (sólo yo) opinan que es correcta.
En la conversación aperecieron otras discrepancias con la frases, "MDA no está alineado con SPL".



Bueno, intentaré expresar mejor mi opinión  en este post.

Lo primero que quiero decir es que el mundo de Model-Driven y  generación de código los conceptos, ideas y paradigmas se enlazan entre sí de una manera confusa y a veces peligrosa. He buscado en la bibligrafía una comparación entre MDA y MDD que incluyo al final del post.

Brevemente:

  • MDA es una iniciativa de OMG interesada en la interoperabilidad entre herramientas,  portabilidad y estandarización. Y no en la productividad y la calidad
  • MDA juega con los conceptos UML, MOF, PIM, PSM, XMI, Metamodelos
  • MDA no excluye la idea de round-tripping (sincronización de código y modelo). MDD sí
  • MDA no usa el concepto de DSL . 
En cambio MDD busca otros objetivos diferentes que son las productividad y calidad en el código.

  • MDD usa el concepto de DSL
  • Con los DSL hablamos de DSL técnicos o funcionales con mayor o menor grado de expresividad. 
  • Si nos vemos forzados a meter detalles tecnológicos  lo que hay que pensar es "no estoy logrando en nivel de abstracción adecuado, ¿es necesario introducir esta semántica en el DSL?" y no "tengo 2 DSLs un PIM y otro PSM". Y mucho menos creer en los mundo de Jupi de MDA y decir "puedo crear otro DSL PSM para otra arquitectura.¡NO!". Si quieres otra arquitectura nos montamos otro generador. E intentaremos mantener el DSL lo más intacto posible de la nueva tecnolgía (si no tendremos otro DSL). El conocimiento de la arquitectura está en el generador y no en los DSL. ¡En algo sustancial se tiene que diferenciar MDD de MDA.!
  • Mezclar la idea de DSL PIM y DSL PSM creo que no es buena idea. Pensemos en SQL (un DSL) que intenta abstraerse lo más posible de la integración del sistema gestor de base de datos pero aún así existen diferentes versiones de SQL para diferentes SGDB. No hay un SQL independiente del dominio y otro dependiente.

Sobre la discusión de SPL y MDA, dos detalles:

  • La idea de SPL viene SEI y no de OMG
  • SPL piensa en productividad y calidad. OMG en interoperabilidad y portabilidad


    domingo, 24 de abril de 2011

    Análisis del dominio

    Técnicas de análisis del dominio.

    FODA Feature Oriented Design Analysis
    DARE Domain Analysis and Reuse Enviroment
    ODE Ontology Based Domain Engineering
    FAST Family Oriented Abstraction Specification and Translation


    y una presentación sobre SPL
    http://redwood.snu.ac.kr/files/Seminar%202008_06_11%20SPL.ppt

    domingo, 20 de marzo de 2011

    Próximo libro de Markus Volter

    Ya está en el fuego el próximo libro de Markus Volter,

    Aquí está disponible la introducción
    http://dsl-engineering.org/wiki/bookintro

    Toca muchos palos, y hace una buena clasificación de DSL. En particular algo que estaba buscando sobre DSL y requirimientos.

    "

    DSLs in Requirements Engineering.

    A related topic to application domain DSLs is the use of DSLs in the context of requirements engineering. Here, the focus of the languages is not so much on automatic code generation, but rather on precise and checkably complete description of requirements. Traceability into other artifacts is important. Often, the DSLs need to be embedded or otherwise connected to prose text, to integrate them with "classical" requirements approaches.
    Examples include a DSL for helping with the trade analysis for satellite construction or pseudo-structured natural language DSLs that imply some formal meaning into domain entities and terms such as should or must."



    sábado, 19 de marzo de 2011

    Software Factories

    Un serie de entradas sobre SF.

    http://0x7c00.wordpress.com/2007/08/24/software-factories-introduccion-parte-1/
    http://geeks.ms/blogs/lontivero/archive/2007/09/30/software-factories-introducci-243-n-parte-3.aspx
    http://geeks.ms/blogs/lontivero/archive/2007/10/02/software-factories-introducci-243-n-parte-4.aspx

    martes, 22 de febrero de 2011

    Martin Fowler.- Language Workbenches: The Killer-App for Domain Specific Languages?

    Most new ideas in software developments are really new variations on old ideas. This article describes one of these, the growing idea of a class of tools that I call Language Workbenches - examples of which include Intentional Software, JetBrains's Meta Programming System, and Microsoft's Software Factories.
    ...
    http://www.martinfowler.com/articles/languageWorkbench.html