Moskitt En Espigon

Moskitt aplicado al proyecto Espigón

¿Qué es ESPIGÓN?

• ESPIGÓN: Empleo de un Sistema Portuario Integral de Gestión On-Line

• Sistema de gestión portuaria dirigido a entes gestores de puertos, como Comunidades Autónomas, Autoridades Portuarias, puertos privados o clubes náuticos.

ListadosListados

Data EntryData Entry

FormulariosFormularios

GISGIS

Bussines IntelligenceBussines Intelligence

Evolución

Portos de Galicia• Inicio 2004• Puesta en Producción 2006

Port de les Illes Balears• Inicio 2006• Puesta en Producción 2008

Ports de la Generalitat Valenciana• Inicio 2008• Puesta en Producción 2010

Características

Técnicas

•Aplicación web J2EE•100% Software libre•Licencia GNU/GPL•BBDD

PostgreSQL/PostGis•Mozilla/Firefox•BI Cubos OLAP Mondrian•Informes OpenOffice•Mtmto. de cartografía

con gvSIG

Características Técnicas

•Framework de trabajo javaEE de Prodevelop

•Modelo MVC•Modular, escalable•Componentizado

para fomentar la reutilización

Arquitectura proJaf

Herramientas

comunes

Menús de acceso dinámicos en función de

cada rol de usuario

Barras de Herramientas

comunes a cualquier área del

sistema

Filtros de Información Personalizados por usuario

Configuración de la información Mostrada al

Usuario

Búsquedas rápidas y Complejas

Facilidades de gestión de la información del sistema

Menús Dinámicos

Barras de Herramientas Comunes

Configuración Personalizada de la Información

Mensajes entre usuarios

Alarmas de aviso sobre la información

Combinación de Documentos (OpenOffice)

Documentos Anexados

Utilidades de Apoyo a la gestión

SubsistemasServicios y Operaciones Portuarias

Dominio Público

Sanciones

Inspección y Vigilancia

Contabilidad Presupuestaria

Núcleo Central de Facturación / Liquidación

Estadísticas -Business Intelligence

Sistema de Información Geográfica (SIG)

Servicios Portuarios

• Escalas de Buques• Mercancías y Pasajeros• Pesca• Embarcaciones Deportivas• Grúas• Suministros de agua y luz• Ocupaciones: Locales y Edificios• Servicios Diversos

GESTION DE SERVICIOS Y OPERACIONES PORTUARIAS

G2 ESCALAS Y ATRAQUES

G3 MERCANCÍAS Y PASAJEROS

G4 PESCA E1 GRÚAS

E2 SUPERFICIES Y LOCALES

Dominio Público

• Concesiones• Autorizaciones• Revisión automática o manual de Cánones• Workflow de Tramitación Expedientes• Fianzas• Obras• Hipotecas• Contadores de suministro

Ejemplo: Expediente de Concesión / Autorización - Tramitaciones Expedientes

Puertos Deportivos

• Definición de Instalaciones: Instalación , Pantalán, Amarres

• Expedientes de Plazas Base• Expedientes de Transeúntes• Gestión de Clubes Náuticos y Marinas• Convocatorias de Plazas• Solicitudes de Plaza (Lista de Espera)• Autorizaciones de Embarcaciones

Pesqueras

Ejemplo: Autorización Embarcación Deportiva

Ejemplo: Configuración Instalación Deportiva

•Gestión de Expedientes de Sanción

•Partes de Inspección y Vigilancia

•Facturación de Servicios y Expedientes

•Espigón GIS•Espigón Móvil Droid•Contabilidad Presupuestaria

Otros módulos

Ejemplo: Boletín de Sanción

Ejemplos de Partes de Revisión Infraestructuras y Limpieza

Cubo

agr

egad

o de

M

erca

ncía

s /

Pasa

jero

s po

r Ej

erci

cio

Ejemplo: Estadística Business Intelligence

ESPIGÓN-GIS: Módulo SIG integrado• Visor espacial web• Puertos Deportivos y Dominio Público• Integrado con

ESPIGÓN-DROID• Introducción de partes de Inspección

desde un dispositivo móvil Android

Espigón antes de

Moskitt

Herramientas de modelado dispares

•Rational Rose Enterprise Edition

•Rational Software Architect•Poseidon UML•DBDesigner•Etc….

Rational Rose

• Ejemplo Modelo de Datos

Rational SW Architect

• Ejemplo Diagrama de Clases

Conclusiones• Diferentes herramientas para

diferentes artefactos de SW• Falta de uniformidad entre

analistas• Mayor curva de aprendizaje para

analistas y desarrolladores• Mayor distancia entre lo

especificado por analistas y lo asumido por programadores

Uso de Moskitt en el

proceso de desarrollo

Artefactos del proceso de desarrollo

Diagrama de Contexto del

Sistema

Descomposición de tareas (WBS)

Diagrama de Casos de Uso

Especificación de Casos de Uso

Moskitt UML UseCase

• Ejemplo: Diagrama de Contexto de Espigón Valencia

Moskitt WBS Diagram

• Ejemplo: WBS Espigón 1er Nivel

Moskitt UML UseCase

• Ejemplo: Fragmento Diagrama de Casos de Uso

Especificación de Casos de Uso

Definición del CU

Diagramas de Estados

Diagramas de secuencia

Diagramas de Flujo de Actividad

Diagrama de Clases

Modelo de datos

Modelo de Navegación

Modelo de Interfaces

Moskitt UML StateMachine

• Ejemplo: Diagrama de Estados Escala / Atraque

Moskitt UML Sequence

• Ejemplo: Secuencia Liquidaciones Domiciliadas

Moskitt UML Activity

• Ejemplo: Flujo Actividad Creación Liquidaciones

Moskitt UML ClassDiagram

• Ej: Diagrama de Clases de Negocio Expedientes Concesión

Diagrama de modelo de datosMoskitt UML ClassDiagram

• Ejemplo: Modelo Navegación Gestión Liquidaciones

Modelo de datos

•Definición del modelo•Sincronización con base de

datos física•Validaciones del modelo•Generación de DDL

Diagrama de modelo de datosMoskitt SqlModel Diagram

• Ejemplo: Modelo de datos Inspecciones Espigón-Droid

Conclusiones• Única herramienta para los diferentes

artefactos SW• Uniformidad entre analistas• Reducción curva de aprendizaje para

analistas y desarrolladores• Menos distancia entre lo especificado

por analistas y lo asumido por programadores

• Eliminación coste de licencias

Espigón & Moskitt

Acciones futuras

Arquitectura MVC•Vista: JSP +

Javascript + CSS•Controlador:

STRUTS•Modelo: POJOS +

JDBC

Espigón•Gestión y Explotación masiva de

información (BackOffice)•Diseño dirigido por BBDD•Patrones de formularios de

mantenimiento similares•Código fuente de mantenimiento

similar

Automatización de tareas

Automatización• A partir de un diagrama E/R de un CU,

automatizar con MOSKITT la generación de las diferentes capas de la arquitectura:

• JSP (listado y mantenimiento)• Action de Struts• Factoría de negocio• POJO (Clase de negocio)• Capa DAO (Acceso a datos)

Automatización de tareas• Fase 1: Mantenimiento Simple

Automatización de tareas

• Campos obligatorios• Tipo de datos de cada campo• Tamaño máximo de cada campo• Forma de generar la clave primaria (secuencial,

secuencial filtrado por campo…)• Interfaz asociada a maestros. Indicar si las

claves ajenas se muestran con una lupa o con un desplegable

• Máscara de formato de cada campo. Por ejemplo => Campos fecha que puedan ser dd/mm/aaaa o bien dd/mm/aaaa hh:mm

• Rangos de valores. Por ejemplo=> No poder dar de alta una escala con año inferior a 2006

Fase 1: Mantenimiento Simple

Automatización de tareas

• Fase 2: Mantenimiento Complejo

Automatización de tareas

• Validaciones cruzadas. Por ejemplo=> Que el campo 1 no pueda tomar determinados valores si el campo 2 toma un valor determinado

• Ocultar/desactivar campos. Por ejemplo=> Que el campo 1 se oculte o se desactive si el campo 2 toma un valor determinado

• Estructuras maestro/detalle

Fase 2: Mantenimiento Complejo

Automatización de tareas

• Fase 3: Workflows

Automatización de tareas

• Poder generar código, no sólo a partir de diagrama E/R

• Indicar reglas de negocio complejas

• Generar interfaz y capas arquitectura asociadas

Fase 3: Workflows

Automatización de tareas

• Incorporar nuevas tecnologías J2EE ( Hibernate, Spring…)

• Publicación de lógica como servicio web

• ………………..

Fase N

Espigón

Moskit

tRecorriendo juntos el camino

cmartinez@prodevelop.esprey@prodevelop.es

www.prodevelop.es

cmartinez@prodevelop.esprey@prodevelop.es

www.prodevelop.es

Gracias por su atención