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
2. Impacto de MDE en la Empresa
3. Aspectos que incluye la Metodología
4. Metodología propuesta
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
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
2. Impacto de MDE en la Empresa
3. Aspectos que incluye la Metodología
4. Metodología propuesta
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
2. Impacto de MDE en la Empresa
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
4. Metodología propuesta
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
2. Impacto de MDE en la Empresa
3. Aspectos que incluye la Metodología
4. Metodología propuesta
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
ETAPA 1: Preparación del Proyecto
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
ETAPA 1: Preparación del Proyecto
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
Experto de Dominio: Carlos Contreras
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
Definición de la s intaxis
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
Experto de Dominio: Carlos Contreras
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
Definición de la s intaxis
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
Definición de la s intaxis
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
4.3 Proceso de desarrollo de aplicaciones con artefactos MDE
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.
4.3 Proceso de desarrollo de aplicaciones con artefactos MDE
30/33
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
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
2. Impacto de MDE en la Empresa
3. Aspectos que incluye la Metodología
4. Metodología propuesta
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