metodología de desarrollo de software en base a mde con dsl

Descripción de las actividades de una propuesta de Metodología para

Ingeniería Dirigida por Modelos (MDE)

Santiago Jácome Universidad de las Fuerzas Armadas ESPE -Ecuador

Contenido:

1. Introducción

2. Impacto de MDE en la Empresa

3. Aspectos que incluye la Metodología

4. Metodología propuesta

5. Conclusiones

6. Referencias

Contenido:

1. Introducción 1.1 Evolución del desarrollo de software

1.2 Los modelos en el desarrollo del software

1.3 Características principales de MDE

1.4 Tendencias de MDE

1.5 Problema abordado

1.6 Objetivo




5. Conclusiones

6. Referencias

1.1 Evolución del desarrollo de software

40: Primeros ordenadores Ensamblador

50-60: Lenguajes de Programación: Fortran, LISP, Cobol.

70: Lenguajes Estructurados: Pascal, C. Metodologías de Desarrollo de Software

Estructuradas u Orientadas a Procesos (proceso)

80: Lenguajes OO: C++. Metodologías de Desarrollo de Software Orientadas

a Objetos (objeto)

2000: MDE-Ingeniería

Dirigida por Modelos (modelos)

1/33

Ensamblador.pptx

1.2 Los modelos en el desarrollo del software

El modelado se remonta a los primeros días del desarrollo de software.

Proporcionan abstracciones de un sistema.

Pueden ser desarrollados como un precursor del sistema, para:

“ Visualizar” el sistema antes de construirlo.

Realizar variaciones para determinar su comportamiento.

Comunicar las características clave del sistema a las distintas

partes interesadas.

Pueden ser mapeados a un Lenguajes de Programación de Propósito

General (GPL) para luego ser compilado en una determinada

plataforma.

Muchas veces los modelos solamente quedan como “documentación”.

2/33

1.3 Características principales de MDE

MDE conecta más estrechamente el modelo a la aplicación.

El modelo no sólo encapsula el diseño de la aplicación sino que se lo utiliza

para generar código de forma automática.

Eleva el nivel de abstracción al desarrollo de software, asignando a los

modelos y las transformaciones entre ellos el rol principal de todo el

proceso de desarrollo.

El desarrollo de software con enfoque MDE involucra dos etapas:

1. Creación de los artefactos MDE por expertos en informática.

2. Desarrollo de aplicaciones específicas con los artefactos MDE por el

usuario final.

Es aplicable a un dominio específico.

Permite la reutilización. Evita codificar las mismas soluciones una y otra vez.

3/33

1.4 Tendencias de MDE

MDA

Arquitectura Dirigida por Modelos (MDA).

Apoyada por el Grupo de Administración de Objetos (OMG).

Utiliza UML como Lenguaje de Modelado de Propósito General.

No muy adecuada para para modelar toda la complejidad del software

para dominios especializados.

Los mecanismos de adaptación de UML (perfiles) son a veces demasiado

"pesados" y van muy ligados a herramientas concretas.

DSL

Apoyada principalmente por la comunidad investigadora.

Utilización Lenguajes de Dominio Específico (DSLs).

Es más productivo utilizar un lenguaje que tenga abstracciones más

orientadas a un dominio.

4/33

1.5 Problema abordado

No existe una proceso formal de desarrollo plenamente

definido con enfoque MDE con DSL.

1.6 Objetivo

Realizar una descripción general de las actividades que

conforman una propuesta de metodología de desarrollo de

software basada en Ingeniería Dirigida por Modelos y

Lenguajes de Dominio Específico.

5/33

Contenido:

1. Introducción




5. Conclusiones

6. Referencias

2. Impacto de MDE en la empresa

Existen varios casos de utilización en la empresa.

Alguno consideran que la tecnología aún no es lo suficientemente madura

para utilizarla masivamente.

El balance costo/beneficio de emplear MDE sería positivo a largo plazo,

tras el desarrollo de un cierto número de proyectos

Se debe cambiar la forma de pensar de los desarrolladores. No están

acostumbrados a un "meta pensamiento" [Voel13 ].

La nueva tecnología debe venir acompañada por el desarrollo de una alta

calidad de la literatura, tutoriales y herramientas adecuadas.

Las empresas pueden ser reacias a cambiar su estructura o parte de ella.

Falta de apoyo decidido de las grandes empresas de desarrollo de

software.

6/33

Contenido:

1. Introducción


3. Aspectos que incluye la Metodología 3.1 Enfoque MDE con DSL

3.2 Metodologías de Desarrollo de Software

3.3 Análisis de Dominio

3.4 Desarrollo por el Usuario Final


5. Conclusiones

6. Referencias

Metodología de Desarrollo de Software Dirigida por

Modelos

Aspectos que incluye la propuesta de la Metodología

7/33

Esquema de la relación entre los elementos del enfoque

MDE con DSL [Garc13].

Meta-modelo (Sintaxis abstracta)

Notación (Sintaxis concreta)

DSL

Modelo Código M2T

M2M Aspecto de

un Sistema

Lenguaje de Meta-

modelado

expresado con conforme

a

definido con

representa a

La sintaxis abstracta del

Lenguaje de Meta-

modelado es un Meta-

meta-modelo

8/33

Semántica

3.2 Metodologías de Desarrollo de Software

Una Metodología de Desarrollo de Software es una marco de trabajo

que permite estructurar, planificar y controlar las actividades de un

proyecto de desarrollo con altas posibilidades de éxito.

La evolución de la gestión de proyectos de software al igual que otras

áreas del conocimiento, sigue un patrón dialéctico basado en los

conceptos formulados por Platón [Pala12].

Comienza con una etapa que se llama tesis, seguida de una etapa que

la niega llamada antítesis y por último se llega a la etapa final llamada

síntesis.

La tesis: Gestión Tradicional o Predictiva (metodologías tradicionales)

La antítesis: Agilidad

La síntesis: Métodos ágiles de desarrollo

9/33

La tesis: Gestión Tradicional o Predictiva

La tesis o alternativa tradicional fue la primera corriente que buscó dar

solución a los inconvenientes de la denominada “crisis del software”:

La Gestión de Proyectos Predictiva es una disciplina formal basada en la

planificación, ejecución y seguimiento de las actividades a través de procesos

sistemáticos y repetibles.

La antítesis: Agilidad

Las empresas deben adoptar nuevos enfoques de gestión de proyectos.

Se requieren estrategias orientadas a la entrega temprana de resultados

tangibles sin arriesgar la calidad.

No hay “productos finales” sino productos en evolución.

La gestión tradicional puede resultar inapropiada en el nuevo entorno social.

Surge el manifiesto ágil (2001, iniciativa de Kent Beck )

10/33

La síntesis: Métodos ágiles de desarrollo

Se aprende de los aciertos y los errores de los dos enfoques de gestión

anteriores.

Términos fundamentales de esta forma de construir software:

Agilidad: capacidad para producir partes completas del producto

en períodos breves de tiempo.

Flexibilidad: capacidad para adaptar el curso del desarrollo a las

características del proyecto y a la evolución de los requisitos.

Fases del desarrollo solapado: el concepto de “fase” que implica

el trabajo secuencial, se cambia ahora por el de “actividad”. Las

cuales pueden realizarse en cualquier momento “a demanda”.

Modelos inscritos en la Agile Allience: AUP (Agile Unified Process),

Crystal, FDD (Feature Driven Development), Scrum (utiliza ciclos iterativos

llamados sprints), XP (eXtreme Programming).

11/33

3.3 Análisis de Dominio

Diseño del DSL:

"El objetivo del Análisis de Dominio (AD) es la definición de un

modelo de dominio que represente las características comunes

de los sistemas y sus relaciones en un determinado dominio

[Díez09]".

Útil cuando en el diseño del DSL se pretende representar las

características comunes de un conjunto de sistemas de un

dominio.

Reutilización del software:

"La clave para la reutilización de software no se encuentra en la

forma de programar el código sino en la correcta especificación

del dominio de aplicación [Neig87]" .

12/33

3.4 Desarrollo por el Usuario Final

"El Desarrollo por el Usuario Final es el conjunto de actividades que

permiten al usuario final de sistemas de software actuar como

desarrolladores de software [Lieb06]".

El desarrollo de aplicaciones se ha convertido en una habilidad

técnica de millones de personas (no necesariamente del área

informática).

Por lo general desarrollan aplicaciones para apoyar sus actividades

laborales.

Para garantizar la calidad de las aplicaciones se recomienda utilizar

varias técnicas de ingeniería de software aunque sea con los mínimos

niveles de rigurosidad.

13/33

Contenido:

1. Introducción




4.1 Directrices para el diseño

4.2 Descripción

4.3 Proceso de desarrollo de aplicaciones con artefactos MDE

5. Conclusiones

6. Referencias

4.1 Directrices para el diseño

1. Basada en el enfoque MDE con DSL.

2. Para crear artefactos que permitan desarrollar aplicaciones

Ligeras y de una Familia de Aplicaciones de Dominio Específico.

3. Lo más simple posible.

4. Utilización de un proceso iterativo-incremental.

5. Comprometer la participación directa del usuario en la creación

de los artefactos MDE.

6. Incluir mecanismos de reutilización de artefactos.

7. Proponer un mecanismo de desarrollo de aplicaciones ligeras

por el Usuario Final con los artefactos MDE creados.

8. Considerar para el ámbito comercial la creación de herramientas

tipo CASE con tecnología MDE para diferentes áreas

profesionales.

14/33

4.2 Descripción/Metodología Orientada por Modelos (MOM1)

15/33

ETAPA 1: Preparación del Proyecto

1. Determinación de la Visión del Producto

Establecimiento del primer contacto entre el interesado en contar con un

conjunto de herramientas MDE y la empresa de desarrollo de software.

Permite conocer de forma general la visión y alcance del proyecto.

2. Conformación del Equipo de Desarrollo

Se encarga del staffing, es decir de la selección y entrenamiento de

personas para que conformen el equipo de desarrollo.

El equipo de desarrollo debe contar con ciertas capacidades y

conocimientos del entorno MDE.

3. Determinación de Aspectos de Logística

La finalidad de esta actividad es dar soporte al proyecto con las adecuadas

herramientas, métodos y procesos.

16/33


4. Análisis de Dominio

Identificar y representar las características de un dominio de sistemas

para establecer un modelo o patrón común que se expresará mediante

un DSL.

Se generan tres productos: a) Lista de Requisitos del Dominio, b) Modelo

de Características, c) Diagrama de Clases.

Se pueden utilizar una adaptación de técnicas de diseño de DSL

existentes. Enfoque "tradicional" y entornos colaborativos en base a

ejemplos [Cáno12], Example-Driven Modeling [Bąk13].

Estos productos justifican su realización como se verá posteriormente

debido a que:

Permiten obtener una versión preliminar del me-tamodelo.

Mejora la estimación de las tareas a realizar.

Si los productos satisfacen al Equipo de Desarrollo, las tareas de esta

actividad pueden ser omitidas y continuar con las demás.

17/33


4. Análisis de Dominio/Productos

PROYECTO:

Cliente: Aeropuerto de Barajas - Madrid

Experto de Dominio: Carlos Contreras

Supervisores de operaciones del terminal. Administrador del Proyecto: Marco Andrade

Personal de gestión del aeropuerto.

Gestores de terminales de la compañía aérea.

Id. Descripción de la funcionalidad Prioridad Riesgo Observaciones

Requisitos Funcionales

1Señalar si el operador de check-in está atendiendo o no (pueden habe varias colas de

atención)alta alto

2Representar dinámica y gráficamente la l legada de los pasajeros a la cola para

realizar el check-inalta alto

3 Representar dinámica y gráficamente la atención del operador de check-in alta alto

4Representar dinámica y gráficamente la l legada del pasajero al kiosco de atención de

check-inalta alto

5 Registrar equipaje del pasajero alta alto

6 Incluir procesos de seguridad de vuelos alta medio

7Representar dinámica y gráficamente la l legada de los pasajeros a la cola de

abordaje del aviónalta alto

8Especificar si el orden de abordaje es por prioridad o por número de asiento

asignadomedia bajo

9Especificar si el desplazamiento de los pasajeros al avión es por un corredor o

mediante el desplazamiento en bus media bajo

10 Se deberá señalar la capacidad de pasajeros del avión alta bajo

11 Se deberá señalar el número de pasajeros que han abordado alta bajoLa capacidad será proporcianada de acuerdo al tipo de

avión

12 Se indicará el tiempo total de atención a los pasajeros en la cola de check-in baja bajo

13 Se indicará el tiempo promedio de atención a los pasajeros en la cola de chek-in baja bajo

14 Se indicará el tiempo total de abordaje de todos los pasajeros en el avión baja bajo

15 Se indicará el tiempo promedio de atención a los pasajeros en el abordaje del avión baja bajo

1El sistema debe residir en el servidor del terminal aéreo, donde los operarios podrán

acceder a el a través de portátiles o dispositivos móviles.alta medio

2El sistema no deberá proporcionar a los operarios información confidencial de los

pasajeros.alta alto

* La prioridad y riesgo de los requisitos está ligada a la prioridad y riesgo en la implementación de la funcionalidad

Requisitos No Funcionales

LISTA DE REQUISITOS DEL DOMINIO

OBJETIVO: Optimizar el proceso de atención a los pasajeros en el check-in y abordaje.

USUARIOS:

Desarrollo de una cola de simulación para optimizar el proceso de abordaje de pasajeros a un avión.

18/33

1.Lista de Requisitos del Dominio

2.Modelo de Características (Feature Model)

3. Diagrama de Clases(versión

inicial del meta-modelo)

ETAPA 2: Sprint

1. Planificar

Con los productos del Análisis de Dominio (AD) se procura diseñar y

construir una versión definitiva del meta-modelo.

Se realiza la Reunión de Planificación del Sprint para planificar las

actividades y tareas del sprint. La reunión consta de dos partes.

Primera parte (1-4 horas):

Participantes: Experto del Domino, Equipo de Desarrollo y Administrador del

Proyecto.

Objetivo: Dar a conocer la versión actualizada de los productos del AD.

Segunda parte (1-4 horas):

Participantes: Equipo de Desarrollo y Administrador del Proyecto.

Objetivo: Descomponer, estimar y asignar trabajo .

MOM1 utiliza Plantillas de Planificación del Sprint predefinidas para

cada iteración (sprint), debido a que las actividades y tareas presentan

prácticamente un patrón similar de ejecución.

19/33

ETAPA 2: Sprint

1. Planificar/Plantilla de Planificación del Sprint

PROYECTO: Cliente: Aeropuerto de Barajas - Madrid


Administrador del Proyecto: Marco Andrade

Inicio: Lun 2, Sep. de 2013

Fin: Vie 15, Nov. de 2013

Tareas pendientes

Horas pendientes

Sprint No: 1 Inicio: Fin:

Actividad Tareas ResponsableEstimando

( horas)Estado

1. Revis ión de documentos del Anál is is de Dominio

2. Refinamiento de documentos de Anál is is de

Dominio (Lis ta de Requis i tos del Dominio, Modelo

de Caracterís ticas y Diagrama de Clases)

3. Selección de los requis i tos de mayor nivel de

prioridad

4. Construcción de la primera vers ión del

metamodelo (tendiente a obtener la vers ión

defini tiva)

5. Eva luación del metamodelo

Definición de la s intaxis

concreta del DSL

1. Definición de los elementos textuales/gráficos del

DSL

2. Construcción del editor

3. Eva luación del editor

Prueba de semántica del DSL 4. Uti l i zación del DSL para diseñar un modelo rea l

bás ico

1. Definición de reglas de transformación

2. Desarrol lo del programa de transformación

3. Ejecución del programa en un motor de

transformación

4. Evalución de la transformación

Generador 1. Determinación del GPL para el cual generar código

2. Selección del mecanismo de generación de código

3. Desarrol lo del generador de código

4. Pruebas de generación de código

Objetivo del Sprint

Reuniones Diarias:

Proveer de funcionalidad inicial básica a los artefactos MDECategoría

Desarrol lo del generador de

código

TOTAL HORAS PLANIFICADAS:

Reunión de Revisión de Incremento: Reunión de Retrospectiva: Reunión de Planificación de próximo Sprint:

Metamodelo

Editor

Transformación


abstracta del DSL

Creación de mecanismos de

transformación

Desarrol lo de una cola de s imulación para

optimizar el proceso de abordaje de pasajeros a un

avión.

PLANIFICACIÓN DEL SPRINTFecha:

20/33

ETAPA 2: Sprint

2. Hacer

Abarca la implementación de las actividades y tareas especificadas

en la Planificación del Sprint.

Para el efecto se debe utilizar la infraestructura hardware y software

que permita construir los diferentes artefactos MDE.

Cada elemento implementado deberá ser probado para verificar que

su funcionamiento esté acorde con lo detallado en el análisis y

diseño.

Pueda ser que en la implementación de algunos artefactos se entre

en un ciclo iterativo-incremental (mini-sprint) con la actividad de

verificación para determinar el cumplimiento de las tareas.

Se deben corregir los defectos encontrados lo más pronto posible.

21/33

ETAPA 2: Sprint

3. Verificar

Se considera la revisión de la ejecución de las tareas planificadas en el

sprint a través de Reuniones Diarias de todo el equipo de desarrollo.

En la Plantilla de la Planificación del Sprint se registra el avance del

desarrollo de los artefactos MDE.

La plantilla se convierte en una especie de Cuadro de Mando del Proyecto.

La Reunión diaria se desarrolla al inicio de cada jornada laboral. Realizada

en no más de 20 minutos.

Cada miembro expone al resto del equipo tres cuestiones:

Tareas en las que trabajó ayer.

Tarea o tareas en las que trabajará hoy.

Si ha tenido algún inconveniente o tiene una necesitar concreta.

22/33

ETAPA 2: Sprint

3. Verificar/Cuadro de Mando del Proyecto

23/33

PROYECTO: Cliente: Aeropuerto de Bara jas - Madrid


Administrador del Proyecto: Marco Andrade

Inicio: Lun 2, Sep. de 2013

Fin: Vie 15, Nov. de 2013

Tareas pendientes 17 14 14 14 13 12

Horas pendientes 124 116 108 100 94

Sprint No: 1 Inicio: Lunes 9, Sep. Fin: Martes, 1 Oct.

Actividad Tareas ResponsableEstimando

( horas)Estado

1. Revis ión de documentos del Anál is i s de Dominio José y María 2 Completa 2

2. Refinamiento de documentos de Anál is i s de

Domio (Lis ta de Requis i tos del Dominio, Modelo de

Caracterís ticas y Diagrama de Clases)

José y María 4 Completa 4

3. Selección de los requis i tos de mayor nivel de

prioridadJosé y María 2 Completa 2

4. Construcción de la primera vers ión del

metamodelo (tendiente a obtener la vers ión

defini tiva)

José y María 20 Completa 8 8 4

5. Eva luación del metamodelo José y María 6 Retrasada 4 4


concreta del DSL

1. Definición de los elementos textuales/gráficos del

DSLMaría 4 Completa 4

2. Construcción del edi tor María 20 Pendiente

3. Eva luación del edi tor María 4 Pendiente

Prueba de semántica del DSL 4. Uti l i zación del DSL para diseñar un modelo rea l

bás icoJosé 4 Pendiente

1. Definición de reglas de transformación Xabier 4 Pendiente

2. Desarrol lo del programa de transformación Xavier 18

3. Ejecución del programa en un motor de

transformaciónXabier 4 Pendiente

4. Eva lución de la transformación Xabier 4 Pendiente

Generador 1. Determinación del GPL para el cual generar código Xabier y María 2 Pendiente

2. Selección del mecanismo de generación de código Xabier y María 6 Pendiente

3. Desarrol lo del generador de código Xabier y María 16 Pendiente

4. Pruebas de generación de código Xabier y María 4 Pendiente

124

Mie

, 2

5 S

ep

.

Objetivo del Sprint

Mar

, 1

7 S

ep

Mie

, 1

8 S

ep

.

Mie

, 1

2 S

ep

.

Jue

, 1

2 S

ep

.

Vie

, 1

3 S

ep

.

Lun

, 1

6 S

ep

.

Reuniones Diarias: 9H00

Proveer de funcionalidad inicial básica a los artefactos MDECategoría

Desarrol lo del generador de

código

TOTAL HORAS PLANIFICADAS:

Reunión de Revisión de Incremento:

Martes 1, Oct. - 9Hh00

Reunión de Retrospectiva:

Martes 1, Oct. - 10Hh00

Reunión de Planificación de próximo Sprint:

Miércoles, 2 Oct. - 15H00

Metamodelo

Editor

Transformación


abstracta del DSL

Creación de mecanismos de

transformación

Desarrol lo de una cola de s imulación para

optimizar el proceso de abordaje de pasajeros a un

avión.

Jue

, 1

9 S

ep

Vie

, 2

0 S

ep

Lun

, 2

3 S

ep

.

Mar

, 2

4 S

ep

.

PLANIFICACIÓN DEL SPRINTFecha:

Lun

, 9

Se

p.

Mar

, 1

0 S

ep

.

ETAPA 2: Sprint

4. Revisar

Al finalizar cada sprint se realiza la Reunión de Revisión de Incremento,

con una duración máxima de 1 hora.

El equipo de desarrollo presenta al propietario del producto el incremento

construido en el sprint.

Permite al Experto de Domino obtener información objetiva del sistema.

Permite marcar a intervalos regulares el ritmo de construcción de las

herramientas MDE y la trayectoria que va tomando la visión del producto

(hitos de control).

24/33

ETAPA 2: Sprint

5. Retrospectiva

Se realiza una Reunión de Retrospectiva con una duración de 1 a 2

horas. Puede desarrollarse luego de Reunión de Revisión de

Incremento.

El objetivo de la Reunión Retrospectiva se centra en “cómo” se está

construyendo, “cómo” se está trabajando, con la finalidad de analizar

problemas y aspectos que se pueden mejorar.

Se discute lo bueno y lo malo que se ha producido en el sprint.

Se liman asperezas entre los miembros del equipo de trabajo.

Se provee retroalimentación a todas las personas.

25/33

Repositorio de Activos Reutilizables

La demanda social actual de software acentúan la necesidad de

aprovechar óptimamente el esfuerzo de desarrollo realizado con

anterioridad.

La finalidad de esta actividad es mantener la integridad de los

artefactos que se crean en el proceso para conformar un repositorio

de reutilización.

Para lograrlo se requiere de herramientas que apoyen esta labor.

El proyecto AMOR (Adaptable Model Versioning) desarrolla un

Sistema de Control de Versiones (VCS) para entornos MDE.

26/33

Procesos Transversales/Gestión del Proyecto

1. Planificación del Proyecto

Lo que se espera de la actividad: Elaboración de un plan del

proyecto.

Lo que se considera MOM1: Planificación de las actividades y

tareas de la creación de una versión completa del conjunto de

artefactos MDE a través en la Plantilla de Planificación del Sprint.

2. Seguimiento y Control del Proyecto

Lo que se espera de la actividad: Proporcionar un entendimiento

del progreso del proyecto para que puedan tomarse las acciones

correctivas.

Lo que se considera MOM1: Seguimiento y control de las

actividades en las cuatro reuniones planteadas en la metodología.

27/33

Procesos Transversales/Aseguramiento de la Calidad

La calidad de un producto está determinada en gran medida por la calidad del

proceso utilizado para su desarrollarlo (CMMI).

Calidad del Proceso

MOM1 incorpora tareas de planificación de tareas (Planificación del Sprint),

seguimiento y control del proyecto (Cuadro de Mando), acuerdos con los

proveedores (Reunión de Planificación del Sprint y Reunión de Revisión del

Incremento), mejora continua (Reuniones de Retrospectiva), gestión de la

configuración (Repositorio de Activos Reutilizables), desarrollo de Software

(metodología propuesta)

Que acercan al proceso de desarrollo a un nivel 2 de CMMI.

Calidad del Producto

Para garantizar la calidad de los artefactos MDE se tienen varios métodos y

técnicas que podrían emplearse.

Por ejemplo en [Ma04] se plantea un método cuantitativo para evaluar la

estabilidad y la calidad del diseño de metamodelos en base a una extensión

de los criterios utilizados en UML.

28/33


Con los artefactos MDE creados por expertos en informática. El usuario

final podrá utilizarlos para desarrollar aplicaciones de su área de

conocimiento a través de la un proceso de desarrollo propuesto en este

trabajo.

29/33

La funcionalidad del proceso de desarrollo por el usuario final debe ser concebida e implementada como actividades complementarias en los artefactos MDE.

Los artefactos MDE deben incorporar actividades que “obliguen” al usuario final a realizar tareas básicas de ingeniería de software.

Se propone utilizar un modelo en base a prototipos evolutivos de software.


30/33

Contenido:

1. Introducción




5. Conclusiones

6. Referencias

5. Conclusiones

Los mecanismos de desarrollo de software van cambiando

permanentemente.

MDE es una nueva disciplina dentro de la ingeniería de software que se

ocupa de la utilización sistemática de modelos para desarrollar software.

Se debe delimitar el ámbito de aplicación de MDE.

Todavía queda camino que recorrer para que los posibles usuarios de

esta tecnología tengan la suficiente confianza como para comenzar a

utilizarla masivamente.

La presente propuesta metodológica aporta con un grano de arena a esta

nueva iniciativa de desarrollo de software. La misma que fue estructurada

tomando en consideración aportes investigativos de varias personas.

MOM1 puede ser utilizada como una guía de soporte y ayuda para las

personas/empresas interesadas en adoptar este enfoque de desarrollo de

software.

31/33

Contenido:

1. Introducción




5. Conclusiones

6. Referencias

6. Referencias (principales)

[Cano12] Cánovas, J.,Cabot, J.,López-Fernández, J., Sánchez, J., Guerra, E., de Lara, J. (2012). Engaging End-Users in the Collaborative

Development of Domain-Specific Modelling Languages.

[Garc13] García, M. García, F., Pelechano, V., Vallecillo, A., Vara, J., Vicente-Chicote, C. (2013). Desarrollo de Software Dirigido por Modelos:

Conceptos, Métodos y Herramientas. Ra-Ma.

[Kang90] Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E., & Peterson, A. S. (1990). Feature-oriented domain analysis (FODA) feasibility study (No. CMU/SEI-90-TR-21). CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST.

[Ko11] Ko, A. J., Abraham, R., Beckwith, L., Blackwell, A., Burnett, M., Erwig, M., ... & Wiedenbeck, S. (2011). The state of the art in end-user

software engineering.ACM Computing Surveys (CSUR), 43(3), 21.

[Kulk05] Kulkarni, V., & Reddy, S. (2005). Model-driven development of enterprise applications. In UML Modeling Languages and Applications (pp.

118-128). Springer Berlin Heidelberg.

[Libe06] Lieberman, Henry, Paterno, Fabio, Klann, Markus and Wulf, Volker (2006): End-user development: An emerging paradigm. End User

Development. In: Lieberman, Henry, Paterno, Fabio and Wulf, Volker (eds.). "End User Development (Human-Computer Interaction

Series)". Springerpp. 1-8

[Ma04] Ma, H., Shao, W., Zhang, L., Ma, Z., & Jiang, Y. (2004). Applying OO metrics to assess UML meta-models. In UML 2004 - The Unified Modeling

Language. Modelling Languages and Applications (pp. 12-26). Springer Berlin Heidelberg.

[Moha08] Mohagheghi, P., Dehlen, V. (2008). Where is the Proof? - A Review of Experiences from Applying MDE in Industry. Springer Berlin

Heidelberg. Volume 5095, 2008, pp 432-443.

[Neig87] Neighbors, J. (1987). Report on the Domain Analysis Working Group Session. In Proceedings of the Workshop on Software Reuse. Rocky

Mountain.Institute of Software Engineering. Boulder. CO.

[Pala12] Palacio, J., Ruata C., (2012). Gestión de Proyectos con Scrum Manager, <URL: http:// www. Scrum manager.net>

[Prie87] Prieto-Diaz, R. (1987). Domain Analysis for Reusability. In Proceedings of COMPSAC 87:The Eleventh Annual International Computer

Software & Applications Conference, pages 23-29. IEEE Computer Society, Washington, DC.

[Sanc12] Sánchez, J., Cánovas, J., Garcia, J. (2012). Applying Model-Driven Engineering in Small Software Enterprises.

[Take04] Takeuchi, H., & Nonaka, I. (2004). Hitotsubashi on Knowledge Manegement, ISBN 0470820748, John Wiley & Sons.

[Voel13] Voelter, M. (2013). DSL Engineering - Designing, Implementing and Using Domain-Specific Languages. CreateSpace.

33/33

metodología de desarrollo de software en base a mde con dsl

Technology