1.2. METODOLOGÍA PARA EL DESARROLLO DEL SISTEMA

1.2.1. Análisis y Diseño Orientado a Objetos

El análisis y diseño orientado a objetos constituye una nueva forma de pensar acerca de problemas empleando modelos que son útiles para comunicarse con expertos en esa aplicación, modelar empresas, preparar documentación, diseñar programas y bases de datos. La esencia del análisis y diseño orientado a objetos es la identificación y organización de conceptos del dominio de la aplicación, y no de su presentación final en un lenguaje de programación, es decir, es un proceso conceptual independiente de sí el lenguaje es orientado a objetos. El uso del análisis y diseño orientado a objetos puede facilitar mucho la creación de prototipos, y las técnicas de desarrollo evolutivo de software. Los objetos son inherentemente reutilizables, y se puede crear un catálogo de objetos que podemos usar en sucesivas aplicaciones. De esta forma, podemos obtener rápidamente un prototipo del sistema, que pueda ser evaluado por el cliente, a partir de objetos analizables, diseñados e implementados en aplicaciones anteriores. Y lo que es más importante, dada la facilidad de reutilización de estos objetos, el prototipo puede ir evolucionado hacia convertirse en el sistema final, según vamos refinado los objetos de acuerdo a un proceso de especificación incremental. En conclusión: "El análisis y diseño orientado a objetos es un proceso continuo donde no existe una división clara entre el análisis y el diseño, además, está centrada en un concepto de modelado y no en técnicas de implementación por lo que es independiente de todo lenguaje de programación hasta las etapas finales3".

METODOLOGÍA OMT4

La Técnica de Modelado de Objetos (OMT) fue desarrollada por James Rumbaugh, es una metodología orientada a objetos muy difundida que se hace cargo de todo el ciclo de vida del software. Utiliza los mismos conceptos y la misma notación a lo largo de todo el ciclo de vida. Divide el ciclo de vida del software en cuatro fases consecutivas: análisis de objetos, diseño del sistema, diseño de objetos e implementación (Fig. I.2)

Análisis de Objetos Esta fase tiene por finalidad la descripción del problema en un modelo de análisis. Diseño de Sistemas Comprende la arquitectura básica. En esta fase se tomarán las decisiones estratégicas de diseño. Diseño de objetos Es el último paso antes de implementar, y sirve para definir completamente todas las características de los objetos. Se detallan los tres modelos ya descritos en el análisis de objetos para poder implementarlo y optimizar el programa. Implementación Se codifica el diseño en un lenguaje específico.

METODOLOGÍA DE BOOCH5

Esta metodología es también muy popular, detalla un método ofreciendo también análisis y diseño 'iterativo', centrándose en el lado del diseño. Las etapas de esta metodología son: Análisis de Requerimientos, Análisis de Dominio y Diseño.

Análisis de Requerimientos En esta etapa se define qué quiere el usuario del sistema. Es una etapa de alto nivel que identifica las funciones principales del sistema, el alcance del modelamiento del mundo y documenta los procesos principales y las políticas que el sistema va a soportar. No se definen pasos formales, ya que éstos dependen de qué tan nuevo es el proyecto, la disponibilidad de expertos y usuarios y la disponibilidad de documentos adicionales.

Análisis de Dominio Es el proceso de definir de una manera concisa, precisa y orientado a objetos la parte del modelo del mundo del sistema. Las siguientes actividades son parte de esta etapa: * Diagrama de clases, clases del dominio claves y sus relaciones. * Especificación de las clases * Vistas de herencia. Diagramas de clases con este tipo de relaciones. * Diagramas de escenarios de objetos * Especificación de objetos, que relacionan objetos y sus clases. Diseño Es el proceso de determinar una implementación efectiva y eficiente que realice las funciones y tenga la información del análisis de dominio. Las siguientes actividades se plantean en esta etapa: * Descripción de arquitectura, describe las decisiones más importantes de diseño como son el conjunto de procesos, manejadores de bases de datos, sistemas operativos, lenguajes, etc. * Descripciones de prototipo, describen las metas y contenido de las implementaciones sucesivas de prototipos, su proceso de desarrollo y la forma de probar requerimientos. * Diagramas de Categorías * Diagramas de clases en diseño, detallan las abstracciones de análisis con características de implementación. * Diagramas de objetos en diseño, muestran las operaciones necesarias para desarrollar una operación. * Nuevas especificaciones * Especificaciones de clases corregidas, muestra la especificación completa de los métodos con algoritmos complicados, la implementación de relaciones y el tipo de atributos. METODOLOGÍA UML6 Esta metodología surge cuando J. Rumbaugh y G. Booch en el año 1994 se unen en una empresa común (de objetivos y de negocio) Rational Software Corporation donde unifican sus dos métodos y como fruto de dicha unión aparece en octubre de 1995 UML 0.8 (Unified Modeling Language). A finales de ese mismo año se une al grupo I. Jacobson, creador de OOSE (Object Oriented Software Engineer) para finalmente conseguir un modelo totalmente unificado. En el proceso de creación de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas y desarrolladores. UML no define un proceso concreto que determine las fases de desarrollo de un sistema, las empresas pueden utilizar UML como el lenguaje para definir sus propios procesos y lo único que tendrán en común con otras organizaciones que utilicen UML serán los tipos de diagramas. La metodología ofrece los siguientes diagramas a modelar sistemas. * Diagramas de Estructura Estática * Diagrama de Casos de Uso: Representa un conjunto de casos de uso, actores y sus relaciones. Vista de caso de uso estática, para organizar y modelar el comportamiento del sistema. * Diagrama de Clases: Para modelar la estructura estática de las clases del sistema. * Diagrama de Objetos: Para modelar la estructura estática de los objetos en el sistema.

* Diagramas Dinámicos * Diagramas de Secuencia: Para modelar el paso de mensajes entre objetos. * Diagramas de Colaboración: Para modelar interacciones entre objetos. * Diagramas de Estado: Representa la secuencia de estados por los que pasa un caso de uso o un objeto a lo largo de su vida, indicando qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera. Teniendo en cuenta que el estándar UML no define un proceso de desarrollo específico, tan solo se trata de una notación. En este trabajo de tesis se sigue el método propuesto por Craig Larman7 que se ajusta a un ciclo de vida iterativo e incremental dirigido por casos de uso. Un proceso de desarrollo es el que se ocupa de plantear cómo se realiza el análisis y el diseño, y cómo se relacionan los productos de ambos, entonces la construcción de sistemas de software va a poder ser planificable y repetible, y la probabilidad de obtener un sistema de mejor calidad al final del proceso aumenta considerablemente. Este proceso define una serie de actividades que pueden realizarse en cada fase, las cuales deben adaptarse según las condiciones del proyecto que se esté llevando a cabo. Se ha escogido seguir este proceso debido a que aplican los últimos avances en Ingeniería del Software, y a que adopta un enfoque eminentemente práctico. Las tres fases al nivel más alto son las siguientes: * Planificación: Planificación, y construcción de prototipos. * Construcción. La creación del sistema. Las fases dentro de esta etapa son las siguientes: - Análisis: Se analiza el problema a resolver desde la perspectiva del usuario y de las entidades externas que van a solicitar servicios al sistema. - Diseño: El sistema se especifica en detalle, describiendo como va a funcionar internamente para satisfacer lo especificado en el análisis. - Implementación: Se lleva lo especificado en el diseño en un lenguaje de programación. - Pruebas: Se lleva a cabo una serie de pruebas para corroborar que el software funciona correctamente y que satisface lo especificado en la etapa de Planificación. * Instalación: La puesta en marcha del sistema en el entorno previsto de uso. La mayor parte del esfuerzo y del tiempo en un proyecto de desarrollo se basa en la etapa de Construcción. Esta etapa se lleva a cabo tomando en cada iteración un subconjunto de los requisitos que llevados a través del análisis y diseño hasta la implementación y pruebas (ver Figura I.3) permite que el sistema vaya creciendo incrementalmente en cada ciclo.

Análisis En la fase de análisis de un ciclo de desarrollo se investiga el problema, sobre los conceptos relacionados con el subconjunto de casos de uso que se esté tratando. Se intenta llegar a una buena comprensión del problema por parte del equipo de desarrollo, sin entrar a como va a ser la solución en cuanto a detalles de implementación. Las actividades de esta fase son las siguientes: 1. Definir requisitos: Es la descripción de necesidades o aspiraciones respecto a un producto. 2. Definir casos esenciales de uso: Un caso de uso es un documento narrativo que describe la secuencia de eventos de un actor que usa un sistema para completar un proceso. Los casos esenciales de uso se describen a un nivel más detallado. 3. Crear el diagrama de casos de uso. 4. Crear el Modelo Conceptual: El Modelo Conceptual es el diagrama de estructura estática de UML que permite una representación de conceptos del mundo real, no de componentes de software. 5. Diagramas de Secuencia del sistema. 6. Definir contratos de operación: Un contrato de operación del sistema describe cambios en el estado del sistema cuando una operación del sistema es invocada. 7. Diagramas de Estados.

Diseño En la fase de diseño se crea una solución a nivel lógico para satisfacer los requisitos, basándose en el conocimiento reunido en la fase de análisis. Las actividades de esta fase son las siguientes: 1. Definir los casos reales de uso: Los casos reales de uso describen el diseño real del caso de uso según una tecnología concreta de entrada y salida y su implementación. 2. Definir Diagramas de Interacción: Los Diagramas de Interacción o Colaboración muestran el intercambio de mensajes entre instancias del modelo de clases para cumplir las post-condiciones establecidas en un contrato. 3. Definir el Diagrama de Clases: Un diagrama de clases muestra la especificación para las clases software de una aplicación. 4. Definir el esquema de base de datos.

1.2.2. Comparación entre el Análisis y Diseño Orientados a Objetos y el Análisis y Diseño Estructurado8

Tabla I.1. Análisis y Diseño EstructuradoAnálisis y Diseño Orientados a Objetos* El análisis y diseño estructurado se basa fundamentalmente en la descomposición funcional del sistema que queremos construir. Esta descomposición funcional requiere traducir el dominio del problema en una serie de funciones y subfunciones. Lo que puede parecer la forma más directa de implementar un objetivo deseado, pero el sistema resultante puede ser frágil. * Los cambios en los requisitos afectan notablemente a la funcionalidad del sistema, por lo que afectan mucho al software desarrollado, por lo que puede ser necesaria una importante reestructuración.* El análisis y diseño orientado a objetos buscan ante todo descomponer un espacio de problema por objetos y esto permite analizar mejor el dominio del problema. El concepto orientado a objetos es más simple y permite una mejor comunicación entre el analista y el experto en el dominio del problema (es decir, el cliente). * Las evoluciones de los requisitos afectan en mucha menor medida a los objetos que componen o manejan el sistema, que son mucho más estables.

1.2.3. Fundamento de la selección de la metodología

UML ha sido desarrollado con el propósito de ser útil para modelar diferentes sistemas de información, técnicos (telecomunicaciones, industria), y no sólo es útil para la programación sino también para modelar negocios, es decir, los procesos y procedimientos que establecen el funcionamiento de una empresa. Por lo tanto existe suficiente razón para que pueda ser utilizado en la mayoría de los proyectos de software. Este nuevo enfoque "orientado a objetos" trajo consigo muchas metodologías usadas en el desarrollo de software orientado a objetos, pero en 1996, el Object Management Group (OMG), un pilar estándar para la comunidad del diseño orientado a objetos, publicó una petición con propósito de un metamodelo orientado a objetos de semántica y notación estándares. UML, en su versión 1.0 fue propuesto y aprobado por el OMG en noviembre de 1997. El Lenguaje Unificado de Modelado (UML) es una metodología que tiene como objetivo conseguir un modelo unificado, abierto, que siga evolucionando en conjunto y no por separado tal como estaba ocurriendo hasta ese entonces, comprensible por el hombre, utilizable por la máquina y fundamentalmente con la capacidad de unificar las perspectivas de diferentes sistemas. Asimismo, esta dirigido por los casos de uso, centrado en la arquitectura y es iterativo e incremental, permite guiar a los desarrolladores en la implementación y distribución eficiente de sistemas que se ajusten a las necesidades de los clientes. Además, prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan.