MOSKitt: Herramienta de Modelado UML y Soporte a la Ingeniería del Software

M O SKitt: El M odeling
Software Kitt
H erramienta de M odelado UM L y
Soporte a la Ingeniería del Software
Jav ie r M u ñ o z, B e go ñ a B o n e t
jmunoz@prodevelop.es, bonet_beg@gva.es

Contenido
• Motivación del proyecto e historia

• Desarrollo de Software Dirigido por Modelos

• Herramientas de Análisis y Diseño

• Tecnologías para Construcción de Herramientas

• Soporte a la Ejecución de Métodos de Desarrollo

• Extensibilidad y Adaptaciones de MOSKitt

• La Comunidad del Proyecto MOSKitt

• Futuro del Proyecto

Antecedentes
• gvPontis: Migración a Software Libre (2003-2008)

• gvMétrica: Metodología de Desarrollo (2004-2006)
➢
Plantillas -> Documentos
➢
¿Herramientas?

✔
Proceso
✔
Roles
✔
Técnicas
✔
M étodos
✔
Recursos E/S
✔
H erramientas

Antecedentes
• ¿Qué Técnicas/Lenguajes?
- UML y BD
• ¿Qué Métodos para aplicar estas técnicas?
• ¿Qué Herramientas?
- CASE tradicional como PowerDesigner (insuficiente)
• ¿Cómo adaptar los métodos a las herramientas?
- Uso de perfiles, Guías metodológicas (pesado de
documentar y dificultades para transmitir todo el proceso)

Necesidad:
Herramienta (libre) de soporte a gvMétrica
para el personal de la CIT

Motivación
- Económica: Alto coste de las licencias de PowerDesigner (Sybase).

- Imposibilidad de reutilizar el conocimiento obtenido con MaPA en los
análisis posteriores con PowerDesigner.

- Carencias a la hora de dar soporte a gvMétrica para:

• Construir los modelos propuestos en la Metodología.

• Automatizar la generación de los productos de salida propuestos por
gvMétrica (modelos y documentos)

• Potenciar el trabajo colaborativo: Homogeneizar el modo de trabajo,
compartir modelos, documentos y recursos en general entre TODO el
equipo de desarrollo.

• Soportar diferentes roles en el equipo de desarrollo.

• Intercambiar información de unas herramientas de la CIT a otras,
para trabajar de un modo homogéo.

Solución: Proyecto gvCASE
• Proyecto gvPontis
 Proyecto de CIT para migrar a Software Libre

• Estudio del ecosistema de herramientas
CASE libres:
 Abril 2006
 No se encontrar una herramienta que soportara la mayoría de los
requisitos

• Decisión: Nueva herramienta CASE libre
 La Universidad Politécnica de Valencia propone Eclipse como
plataforma base
 Proyecto gvCASE: Abril 2007

Objetivo del Proyecto

Crear una herramienta libre de
Crear una herramienta libre de
soporte al método de desarrollo
soporte al método de desarrollo
de software gvMétrica
de software gvMétrica

• Método de desarrollo de software
 Es la aplicación de la Ingeniería al Desarrollo de Software
 Utiliza Técnicas de Modelado (planos del software)
 Establece unos Pasos para utilizar las técnicas

Beneficios Esperados
- Abaratamiento de costes

- Estandarización del trabajo

- Reutilización del conocimiento

- Reducción de documentación de análisis/diseño
poco útil

- Automatización del Proceso de Desarrollo de
Software
• Incremento de la Calidad del Software

• Mejora de la productividad del equipo.

Objetivo: Herramienta
• Solución adoptada: PROYECTO gvCASE (2007)
- Desarrollo Propio en Software Libre -> MOSKitt
- Asesoramiento de la U.P.V

• ¿Qué Enfóque Técnico? → Desarrollo Dirigido por Modelos
- Modelos
• Estándares: UML2, BPMN ....
• Propios: DSL's
- Transformaciones
• Modelo a Modelo (M2M)
• Modelo a Texto (M2T)

• ¿Qué Enfoque Tecnológico?: Eclipse
- Eclipe Modeling Project (EMP) : EMF, GEF, GMF...
- UML2 etc...

¿Qué NO es MOSKitt?
• No es un dibujador (como Visio o Dia)
 Aunque hace dibujos/diagramas

• No es un entorno de desarrollo
 Aunque está basado en Eclipse

• No es sólo un editor de UML2
 Aunque tiene un editor UML2

• No es mágico, ni tecnología alienígena
 Aunque puede usarse para generar automáticamente aplicaciones
software

Estrategia de Desarrollo
• Desarrollo por versiones: 1 versión x 4 meses:

- 3 meses de desarrollo + 1 mes de pruebas

• Situación Actual (Febrero 2010):

- Última Versión Publicada: 1.1.1 (Febrero 2010)

- Próxima versión a Publicar 1.3.0 (Mayo 2010)

- Iniciados nuevos contratos:

• Generación de Código a gvHidra (php) y gvNix (Java)
2.0.0
• Desarrollo de un Sketcher para facilitar la definición de IU's.

Publicación de versiones (0.3.0 a 1.1.1) en:
http://www.moskitt.org

4/2007 9/2007 5/2008 7/2009 5/201 0 3/201 1

0.1.0 0.5.0 1.0.0 1.3.0 2.0.0

Enfoque de Desarrollo
Enfoque de Invocación de otras
• desarrollo herram ientas
• Arquitectura de
plugins de Eclipse

Plataforma LIB RE
para la constucción
de herramientas
C A SE con soporte al
proceso de desarrollo

¿Qué es DSDM?
• Desarrollo de Software Dirigido por Modelos
 No es@s modelos

• Conceptos Similares
 Model Driven Engineering
 Model Driven Architecture
 Generative Programming

h t t p ://w w w .flic k r .c o m /p h o t o s/903 49 43 5 @ N 00/3 37 44 2 75 08 /
h t t p ://w w w .flic k r .c o m /p h o t o s/9 03 4 94 35 @ N 00/3 3 73 6 1 3 1 2 5/

¿Por qué DSDM?
• Hacer Software es Complejo
 El problema que se debe solucionar ES complejo

El cliente habla con El desarrollador utiliza
conceptos del problema conceptos de la tecnología

¿Por qué DSDM?
• Mismo problema → Misma Solución
 No inventarse cada vez una solución

¿Por qué DSDM?
• Ejemplo patrón
 Aplicaciones Gestión Información
 Problema: Propiedad de una Entidad
 Solución:

➢ Añadir columna en BBDD

➢ Añadir widget en interfaz de usuario

➢ Añadir comprobaciones de tipo

➢ Añadir columna en selects, inserts y updates

¿Por qué DSDM?

• La solución
 Describir problema utilizando conceptos del problema
 Aplicar automáticamente lo patrones de solución

• Evitar
 El usuario explica el problema
 El programador intenta entender el problema
 Mentalmente, resolver el problema con la tecnología
 Copiar, pegar y adaptar una solución que se aplicó anteriormente

¿Cómo aplicar DSDM?
1. Definir lenguaje para el dominio
 Nuevo lenguaje de dominio específico (DSL)
 Extender lenguaje de propósito general (UML con perfiles)

2. Identificar patrones
 ¿Cómo implementar cada problema?

3. Implementar generadores
 A partir de descripciones del problema, aplican los
patrones y producen soluciones (código fuente)

¡¡DSDM no es la panacea!!

Analizar costes :
(inversión vs beneficio)

VS
Crear lenguaje + Programación
Identificar patrones + Copy&Paste
Implementar generador


¿Aplicación singular o repetible?

¿Personal formado?

¿Modelar y generar 100%?

¿MOSKitt para DSDM?

MOSKitt + Eclipse Modeling Project

Infraestructura para desarrollar:

Editores Gráficos

Editores Formularios

Generadores de Código

Editor UML2
• Modelado UML2

 D. Clases
 D. Secuencia
 D. Estados
 D. Actividad
 D: Casos Uso
 D. Perfiles

• Aplicación
Perfiles

• Multidiagrama

Modelado de
Base de Datos
• Modelado DB

 Tablas
 Vistas
 Usarios
 Roles
 Grupos
• Generación DDL

 MySQL
 PostgreSQL
 Oracle
• Ingeniería
Inversa

Modelado de
Procesos (BPMN)
• Modelado BPMN

 Procedimientos
 Tareas y flujos
de documentos
 Multidiagrama

• Modelo
Documentos

 Familias de
documentos
 Plantillas

Modelado de
Interfaz de Usuario
• Modelado Interfaz
Usuario

 Vistas del Sistema
 Unidades de
Interacción
 Navegación
 Opciones Presentación
 Patrones

Gestor de
Transformaciones
• Registro Transformaciones

 Visualización
 Organización
 Priorización
 Ejecución Transformaciones
 Solicitud parámetros
 Resultados validación y ejecución

Exploradores de
Modelos
• Exploración de modelos

 Sincronización con los
editores gráficos
 Filtrados por diagramas
 Agrupación por tipo

• Edición de modelos

 Drag&Drop a los editores
gráficos
 Duplicación de elementos
 Manipulación diagramas
 Gestión de elementos
(creación, eliminación, etc.)

Extensiones Funcionalidad
Editores Gráficos
• Soporte completo al
Copy&Paste

• Integración de editores

• Soporte al multi-diagrama

• Filtrado de elementos por tipo

• Canvas mutantes

• Mejoras de eficiencia (cacheo)

• Mejor gestión de colores y
estilos

Editores de Formularios
para Modelos
• Soporte edición modelos Ecore

 Cargar/Salvar modelos
• Edición de Propiedaes EMFEObjectComposite

EMFPropertyStringComposite

 Tipos Básicos (string, boolean,
enumerados, etc.) EMFPropertyEReferenceComposite

 Colecciones EMFContainedCollectionEditionComposite

 Referencias
➢ univaluadas
➢ multivaluadas
• Gestión Maestro/Detalle

Soporte al método
M aPA Invocación de otras
herramientas

Intérprete de Procesos (Dashboard Interpreter)

Modelo Modelos Modelo
Procesos BBDD DB Editor de
Análisis/Diseño
(BPMN) Relacional PostgreSQL Procesos
UML2
(Dashboard
Editor)
➔
Editores G ráficos DB Métodos
T ransform aciones Código Oracle
+
➔

Prototipo DDL
➔
Ingeniería Inversa Ayuda
➔
Im portación de m odelos PostgreSQL
DB
DDL MySQL
Oracle
Modelo Modelo
WBS (GP) Interfaz Usuario DDL
MySQL

Soporte al método
Cheatsheets

Definición y Ejecución
Tareas de Desarrollo Transformaciones
de Modelos

UML BD

BPMN UML

Modelado de Métodos de
Desarrollo de Software
• Modelado Métodos

 Tareas
 Recursos
 Dependencias
 Acciones
 Visualización estado
desarrollo

Definición de un Proceso

Elementos del lenguaje:

• Tareas

• Dependencias entre tareas: ¡Dependencias de Recursos!

• Recursos E/S, Referencias a Recursos -> Recursos Físicos (Ficheros)

• Acciones:
- abrir Editor, lanzar Transformación, invocar aplicación externa.
- Acceso al resto de la documentación...

Ejecución de un Proceso

(2)
(3)
(1)
(1)
• Enlazar Recursos

• Editar Recursos

(3) Abrir Cheatsheet (Guías)
(2) Abrir Editores (graf. Y form.) Abrir Ayuda


• Cada Proyecto tiene su propio Proceso en ejecución (su
estado)
• Abrir, Editar recursos y referencias a recursos
• Enlazar/Desenlazar Recursos del Dashboard de Rec.Físicos
• Abrir las Guías de ayuda
• Invocar a los Editores (gráficos, formularios...)
• Lanzar Transformaciones etc...

Estados de los Recursos
Est ad o s:

- Pe n d ie n t e

- Em p e zad o
N otT oD o - T e r m in ad o

- M o d ific ad o
una vez
t e r m in ad o

- N o h ay q u e
h ac e r lo

Est ad o s:
Estados de las Tareas - Pe n d ie n t e
- Em p e zad a
- T e r m in ad a
- M o d ific ad o
algú n r e c u r so
un a vez
t e r m in ad a
- En Esp e r a d e
q u e algu n a
d e p e n d e n c ia
p r e v ia se
r e su e lv a
- N o h ay q u e
h ac e r la

Estados de las Dependencias

Est ad o s:
- L im p ia: T o d o s lo s R e c u r so s d e las t ar e as d e p e n d ie n t e s e st án
t e r m in ad o s
- Su c ia: H ay r e c u r so s d e las t ar e as d e p e n d ie n t e s q u e aú n n o se
h an c o m p le t ad o .
- D e sin c r o n izad a: H ay r e c u r so s m o d ific ad o s e n la t ar e a
d e p e n d ie n t e .
- A la Esp e r a d e q u e se fin alize n lo s r e c u r so s d e las t ar e as
d e p e n d ie n t e s.

Control del Estado de los Proyectos
• Análisis está Terminado y sus recursos completos
(“Terminado”).
• La Dependencia que tiene Diseño de Análisis está Resuelta
(el recurso está “Limpio”).
• Vamos a ejecutar la tarea de Diseño (“Por hacer”)

Iteraciones y Subdiagramas

Soporte a:
[*] Iteraciones
Subdiagramas

¿Por qué extender MOSKitt?

• Cada organización es diferente
 Cultura interna

 Experiencia e historia

 Objetivos y expectativas

• Todas las organizaciones cambian
 Nuevas responsabilidades y objetivos

 Mejora continua

h t t p ://w w w .sx c .h u /p h o t o /98441 8

¿C ómo adaptar M O SK itt a
cada contexto específico?

h t t p ://w w w .flick r .c o m /p h o t o s/8 3 4 7 68 7 3 @ N 00/1 1 099 3 8 7 7/

¿Cómo adaptar?
• Añadiendo herramientas
 Nuevos editores

 Nuevas transformaciones

• Modificando herramientas
 Cambiar código + recompilar → ramificar

➢ Difícil de mantener y evolucionar :(

 Mecanismos de extensiones dinámicas

➢ Implementar y declarar nueva funcionalidad

➢ El código existente debe estar preparado

➢ Las herramientas permanecen intactas
h t t p ://w w w .sx c .h u /p h o t o /1 1 52 1 2 7

Puntos de extensión
Plugin B

Plugin C

Plugin .
Anfitrión .
.

Plugin Z

¿Qué adaptar?
El Método

Contenidos del método 
Cheatsheets

Asistentes de creación 
Ayuda contextual

Los Editores

Plantillas de modelos 
Propiedades extendidas

Paleta de elementos

Decoradores gráficos

Las Transformaciones

Sobrescribir transformaciones

Sincronización

Contenidos del Método
• Cambiar los pasos del método

Asistentes de Creación
• Acciones específicas al crear el proyecto

Cheatsheets

• ¿Qué es un cheatsheet?
1. Define instrucciones paso a paso
para realizar una tarea
2. Los pasos pueden tener
instrucciones y ejecutar acciones
3. Algunos pasos pueden omitirse

Cheatsheets
• ¿Cómo utilizar cheatsheets?:

1. Crearlo con el editor
de Eclipse

Cheatsheets
2. Definirlo mediante un punto de extensión

Cheatsheet
3.a )Añadir la acción 'OpenCheatsheetAction'
a una tarea del dashboard:

3.b ) Seleccionar el cheatsheet en la pestaña
de propiedades:

Ayuda Contextual
• Los editores gráficos y de formularios de MOSKitt
muestran ayuda dependiendo del elemento
seleccionado

• Plugins externos pueden contribuir ayuda

C o n e x t u al h e lp sh o w in g h e lp c o n t e n t s fo r t h e
FEFEM e d it o r w it h e le m e n t se le c t e d se le c t e d e le m e n t

Ayuda Contextual
• Como contribuir ayuda contextual a
MOSKitt:
1. Crear el contenido de la ayuda:

Ayuda Contextual
2. Contribuir el archivo de ayuda mediante el
punto de extensión 'org.eclipse.help.contexts'.

Plantillas de Modelos
• Contenido inicial de los modelos

Personalización de la paleta
• grupos y botones ende
Cambiar el nombre
la
paleta.

• aMover botones de un grupo
otro.

• botones de la paleta. y
Crear y eliminar grupo

Pale t a
p e r so n alizad a

Pale t a o r igin al

1. Definir la personalización en el
punto de extensión
'es.cv.gvcase.mdt.common.editorPalet
te' extension point

• Elemento 'Group'
 añadir un nuevo grupo
 cambiar el nombre de un grupo
 eliminar un grupo

• Elemento 'Tool'
 cambiar nombre de un botón
 mover un botón entre grupos
 eliminar un botón

• Añadir nuevas propiedades a entidades existentes

• Editar las nuevas propiedades en la pestaña de
propiedades

• Mantener la compatibilidad con la versión sin extender

1. Definir la propiedad con el punto de extensión
'es.cv.gvcase.mdt.common.featureExtender'

2. Definir
 Tipo de la propiedad:
➢ Integer
➢ Double
➢ Boolean
➢ String
➢ Reference
 Multiplicidad mínima
 Multiplicidad máxima

3. Definir
 La entidad que necesita ser extendida (AdaptTo):
 Los valores válidos ('AvailableValue')

4. Implementar y definir la sección en la pestaña
de propiedades:

Double Properties

Collection Properties

String Properties

References Properties

Integer Properties

Decoradores gráficos
• Proporcionar decoraciones a las figuras en los editores
gráficos (GMF)

• Contribuir decoraciones desde plugins externos

• Usar iconos e imágenes para decorar figuras

A normal Class A decorated Class

Sobrescribir transformaciones
• Definir prioridades de mayor prioridad

Sincronización
• Acciones específicas al cambiar modelos trazados

Trazas entre
“X.uml” y
“Y.sqlschema”

1.- al cambiar 2.- actualizar
la entrada modelos trazados

Sincronización
• Acciones específicas al cambiar modelos trazados

Integrantes del Proyecto
Universidad Admon. Empresa
Pública

• Conocimiento • Liderazgo • Desarrollo
• Difusión • Requisitos • Proyección
• Aplicación • Financiación • Conocimiento

El Equipo del Proyecto
• 2 Jefes de Proyecto (CIT y adjudicatario)

• 2 Directores de Proyecto (CIT y adjudicatario)

• 9 – 11 Desarrolladores:
- CIT, adjudicatario y empresas colaboradoras.
- Perfiles: Analista, Analista/Programador, Programador
Junior/Senior, Diseñador, Arquitecto Software, Probadores.

• 15 Probadores:
- CIT (Analistas/Usuarios finales)

• 5 Asesores Técnicos y Científicos de la U.P.V.

Algunos datos:
• Accesos Web (durante Marzo 2010)
 2471 visitas (de 1864 visitantes)
 91.94 GB software descargados

• Métricas de Ohlo
(https://www.ohloh.net/p/moskitt)
 1,565,358 líneas de código
 443 personas/año

Trabajos futuros
• Consolidar el uso de la herramienta: Plan de Formación, testing....

• Potenciar la colaboración con otras organizaciones.

• Potenciar su facilidad de uso: especialmente para la definición de las Interfaces
de Usuario

• Generación Automática de Código para plataformas específicas en la CIT: Java y
PHP

• Mejora del Módulo de Soporte al Proceso (beca I+D+i).

• Incluir nuevas transformaciones, nuevos editores gráficos y formularios para cubrir
al máximo las necesidades que desde gvMétrica se vayan planteando

• Incluir un Modulo de Especificación de Requisitos

• Incluir un Repositorio de Modelos para soportar: trabajo en grupo, control de acceso
y manejo de versiones

• Soporte a la Gestión de los Proyectos y el Trabajo Colaborativo.

Creative Commons
Attribution-Noncommercial-Share Alike 3.0
Unported

• You are free:
 to share — to copy, distribute and transmit the work
 to Remix — to adapt the work

• Under the following conditions:
 Attribution — You must attribute the work in the manner specified by the
author or licensor (but not in any way that suggests that they endorse you or
your use of the work).
 Noncommercial — You may not use this work for commercial purposes.
 Share Alike — If you alter, transform, or build upon this work, you may
distribute the resulting work only under the same or similar license to this
one

h t t p ://c r e at iv e c o m m o n s.o r g/lic e n se s/b y -n c -sa/3.0/

MOSKitt: Herramienta de Modelado UML y Soporte a la Ingeniería del Software

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (17)

En vedette

En vedette (15)

Similaire à MOSKitt: Herramienta de Modelado UML y Soporte a la Ingeniería del Software

Similaire à MOSKitt: Herramienta de Modelado UML y Soporte a la Ingeniería del Software (20)

Dernier

Dernier (15)

MOSKitt: Herramienta de Modelado UML y Soporte a la Ingeniería del Software