Mostrando entradas con la etiqueta Diseño Orientado a Objetos. Mostrar todas las entradas
Mostrando entradas con la etiqueta Diseño Orientado a Objetos. Mostrar todas las entradas

DSN_XP y el proyecto AMBAR

Sistema de ticketing AMBAR

Año: 2006
Localidad: Quito
Institución: Aerolíneas Galápagos
Autor: Edwin Vargas Lara



DSN_XP: 

Participó documentando técnicamente el sistema AMBAR para la generación de reservaciones, itinerarios, emisión de tickets y reporte de ventas, el sistema fue diseñado y desarrollado por Edwin Vargas Lara para la aerolínea privada más grande del Ecuador Aerogal.

La documentación técnica se generó mediante modelos UML bajo los principios del diseño orientado a objetos, lo que permitió abstraer los procesos involucrados en:
  • la generación de reservas (planificación de vuelos, asignación de flota, itinerarios, rutas, etc.)
  • manejo de puntos de venta (agencias IATA/no IATA, puntos propios incluido la Web, cuentas corporativas, distribuidores, etc.) 
  • manejo de reservaciones (reservaciones, cancelados, manejo de grupos, tiempos límite, etc.)
  • manejo de inventario de ticktes (distribución, descarga de inventarios, etc.)
  • manejo de itinerarios (cambios, cancelaciones y publicación de vuelos por rutas y frecuencias, etc.)
  • emisión de documentos de tráfico (tickets, PTAs, MPDs, revisiones, exchange, etc.)
  • manejo de formas de pago (contado, crédito, tarjeta, prepagos, aerobonos, reportes de ventas, estados de cuenta, etc.)
  • chequeo en aeropuertos (No show, Go show, cancelaciones por operaciones involuntarias, etc.
Todos estos procesos importantes al rededor de la generación de las reservas y la emisión de los boletos de venta para una aerolínea, fueron automatizados mediante el sistema AMBAR por lo que había que modelarlos bajo la perspectiva del negocio y transformarlos en modelos bajo la perspectiva del software y que definían la arquitectura del sistema AMBAR, comprobándose una vez más que DSN_XP y sus artefactos de diseño estaban en la capacidad de abstraer hasta este momento cualquier tipo de proceso, procedimiento, actividad, tarea, etc.


Para poder agrupar las diversas funcionalidades que participaban en un escenario funcional (usualmente asociado a un departamento o unidad administrativa de una aerolínea y conforme lo determinaba incluso las reglas IATA), recurrimos a la noción de paquete y su propiedad como contenedor para poder distribuir los casos de uso de la programación soportada por el sistema.


Muchas de las decisiones técnicas estaban destinadas a soportar la demanda de diseño de un sistema complejo como lo es el conjunto de procedimientos tanto en cielo como en tierra respecto a cómo debe administrarse la data para que luego de procedimientos de ajustes y registros contables, pueda determinarse un dominio de datos centralizados en cuanto fuese posible por Ambar y su estructura de datos.

Se utilizó un paradigma de diseño de Cliente / Servidor desplegado localmente (pero con cobertura nacional operativamente hablando gracias a la tecnología Web aplicada en su diseño).




Dada la complejidad operativa de una aerolínea, la navegabilidad del sistema contemplaba muchos estados compartidos por los objetos del negocio que debían ser registrados adecuadamente y luego adaptados a los ajustes operativos que sufren entidades como los boletos y su capacidad anual de vida operativa bajo principios IATA.

Para lograr controlar los cambios en la documentación técnica debido a los continuos cambios en los diversos escenarios de usabilidad, adoptamos los principios de OOHDM para lograr establecer una estrategia de control de los atributos de estado de los diversos objetos que coexisten en el proceso de comercialización de una aerolínea.

DSN_XP y el modelado con UML

Los criterios de modelado


Los primeros "modelos" desarrollados por DSN_XP como tal, surgen en base a nuestro conocimiento de una escuela de modelado de software que se presenta madura y ordenada e incluso introduce el concepto de arquitectura sobre la ingeniería que veníamos desarrollando.

UML


El Lenguaje Universal de Modelado (UML) es independiente del proceso de desarrollo, lo que significa que como lenguaje, no está ligado a ningún modelo del ciclo de vida del desarrollo de software (CVDS) en particular.

Para DSN_XP como metodología, todo método sobre desarrollo de software, requiere por defecto definir un modelo CVDS, es decir, la forma en la cual se va a gestionar el proceso de desarrollo del software.
UML puede representar este modelo CVDS mediante un diagrama estereotipado de actividades.

Las escuelas de diseño y el modelado del sistema

La forma en la cual se diseñe el software del sistema, depende de las guías de diseño definidas para ello, UML no es una guía de diseño para desarrollar software; pero proporciona un lenguaje de modelado que soporta tanto la orientación a objetos como otros paradigmas de desarrollo. 
UML no posee un modelo para representar modelos, solventa este problema por la noción de paquetes estereotipados.

 La ingeniería del software como tal, utiliza los modelos y los métodos para desarrollar software e impone una estructura a la ingeniería detrás del software con el objetivo de hacer que esta actividad sea sistemática, en lo posible, repetible y en como fin, que esté orientada a cumplir una necesidad de cálculo o control de forma adecuada al contexto en el cual se la aplica.

La necesidad de utilizar perspectivas en el modelado

Un modelo es una abstracción de un sistema; un subsistema representa una partición de los elementos de un sistema más grande en partes independientes, los subsistemas y el sistema global pueden modelarse desde muy diferentes puntos de vista. 

Una vista es una proyección de la organización y estructura de un sistema centrada en un aspecto particular del mismo. 
UML posee la noción de paquetes que contienen todas las abstracciones pertinentes para esa vista

El uso de modelos proporciona un enfoque al problema de resolución, una notación y procedimientos para el modelo de construcción y su análisis. Como método, proporciona un enfoque de la especificación sistemática, diseño, construcción, prueba y verificación del producto final del software y los productos de trabajo asociados.

Modelado de la arquitectura de un sistema

Cuando se modela la arquitectura de un sistema, se capturan las decisiones sobre los aspectos estructurales y de comportamiento de los sistemas y los patrones que configuran estas vistas.
UML posee diversos artefactos para soportar las vistas requeridas para modelar la arquitectura del sistema (4+1), los patrones de diseño se modelan como colaboraciones.

Modelo conceptual de UML

El modelo conceptual de UML está conformado por los bloques básicos de construcción UML, (elementos, relaciones y diagramas), las reglas que dictan cómo se pueden combinar los bloques básicos (reglas semánticas para nombres, alcance, visibilidad, integridad, etc.) y algunos mecanismos comunes que se aplican a través de UML (especificaciones, adornos, divisiones comunes, mecanismos de extensibilidad)

Apuntes DSN_XP sobre UML 

UML: Lenguaje de modelado para visualizar, especificar, construir, documentar software

UML como lenguaje de modelado provee 5 vistas para modelar toda la arquitectura software, posee la vista de diseño, la vista de procesos, la vista de implementación la vista de despliegue y la vista de casos de uso.

DSN_XP no reconoce a los casos de uso como un artefacto orientado a objetos y no recomienda utilizar la noción de relaciones en los diagramas de clases ya que las relaciones en base a asociaciones no son tampoco recomendadas por DSN_XP en el diseño orientado a objetos.

Inicios de UML como lenguaje de modelado

El método de Booch era particularmente expresivo durante las fases de diseño y construcción de los proyectos, OOSE proporcionaba un soporte excelente para los casos de uso como forma de dirigir la captura de requisitos, el análisis y el diseño de alto nivel y OMT era principalmente útil para el análisis y para los sistemas de información con gran cantidad de datos.
“Como creadores principales de los métodos de Booch, OOSE y OMT, nos sentimos motivados para crear un lenguaje unificado de modelado por 3 razones. En primer lugar, cada uno de nuestros métodos ya estaba evolucionado independientemente hacia los otros dos. Tenía sentido hacer continuar esa evolución de forma conjunta en vez de hacerlo por separado, eliminando la posibilidad de cualquier diferencia gratuita e innecesaria, en segundo lugar, al unificar nuestros métodos, podríamos proporcionar cierta estabilidad al mercado orientado a objetos, permitiendo que los proyectos se pusieran de acuerdo en un lenguaje de modelado maduro y permitiendo a los constructores de herramientas que centraran en proporcionar más características útiles. En tercer lugar, esperábamos que nuestra colaboración introduciría mejoras en los tres métodos anteriores, ayudándonos a capturar lecciones aprendidas y a cubrir problemas que ninguno de nuestros métodos había manejado bien anteriormente” [UML]

Metas propuestas por UML

  1. Modelar sistemas, desde el concepto hasta los artefactos ejecutables utilizando técnicas orientadas a objetos.
  2. Cubrir las cuestiones relacionadas con el tamaño inherentes a los sistemas complejos y críticos.
  3. Crear un lenguaje de modelado utilizable tanto por las personas como por las máquinas.
Curiosamente, un montón de empresas de desarrollo de software comienzan queriendo construir rascacielos pero enfocan el problema como si estuvieran enfrentándose a la caseta de un perro :o)
Las ventajas del modelado son:
  1. Los modelos nos ayudan a visualizar cómo es o queremos que sea un sistema.
  2. Los modelos nos permiten especificar la estructura o el comportamiento de un sistema.
  3. Los modelos nos proporcionan plantillas que nos guían en la construcción de un sistema.
  4. Los modelos documentan las decisiones que hemos adoptado.

Principios de modelado

  • La elección de qué modelos crear tiene una profunda influencia sobre cómo se enfrenta un problema y cómo se da forma a una solución.
  • Todo modelo puede ser expresado a diferentes niveles de precisión.
  • Los mejores modelos están ligados a la realidad.
  • Un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes.
DSN_XP soporta varios lenguajes de modelado pero usualmente recurre a UML por estándar y lenguaje de modelado más conocido.

Referencias

El lenguaje unificado de modelado, Booch et al, Addison Wesley, 1999, ISBN:84-7829-028-1