ANÁLISIS ORIENTADO A OBJETOS (AOO)

Análisis orientado a objetos se refiere a un método  de análisis que examina los requisitos desde la perspectiva de las calces y objetos que se encuentran en el vocabulario del dominio del problema.

El análisis orientado a objetos nos habla acerca de que debemos de tener una vista arquitectónica,  para lo cual  se tiene que saber definir los atributos de una buena arquitectura los cuales son: las capas de abstracción bien definidas, clara separación  de intereses  entre interfaz e implementación, arquitectura simple, también es necesario saber distinguir entre decisiones estratégicas y tácticas, las decisiones  estratégicas son aquellas que tienen amplias implicaciones estratégicas e involucran así  a la  organización de las estructuras de la arquitectura del nivel mas alto y las decisiones tácticas son las que solo tienen implicaciones arquitectónicas locales, es decir solo involucran a los detalles de interfaz e implementación de una clase.

Lo que se tiene que analizar es lo siguiente: las características comunes de los documentos como son, identificación, titulo, descripción, versión , fecha , revisión, código del documento, etc. la especificación de los requisitos o los requerimientos, diagramas de casos de usos, escenarios y sub-escenarios y los prototipos.

La identificación se refiere a que es necesario identificar todos los elementos del proceso de desarrollo  de software de una forma univoca, también todos los elementos deben de estar identificados, en el titulo se debe  reflejar de la mejor forma posible sus fines y su funcionalidad.

La especificación de requisitos se refiere a que es el proceso de averiguar, normal mente en circunstancias difíciles lo que se va a construir. la captura de requisitos es un poco complicada  ya que los usuarios no saben expresar exactamente lo que quieren lo cual hace difícil tener una visión global de el problema a resolver, se pueden utilizar especificaciones jerárquicas en las cuales se busca que quede reflejado lo mas exactamente posible  el problema a resolver y que en las reuniones de análisis se determine que requisitos se añaden o se eliminan.

DISEÑO ORIENTADO A OBJETOS (DOO)

El diseño orientado a objetos es una metodología aplicada en el desarrollo de software.

Se divide en dos fases:

·                               Diseño Preeliminar

·                               Diseño Detallado.

DISEÑO PRELIMINAR

Aquí ya empezamos a pensar en cómo vamos a hacer las cosas.

En el diseño preliminar tratamos de establecer la arquitectura de nuestro programa. La arquitectura es un esquema de en qué módulos/paquetes vamos a dividir nuestro programa, qué librerías. Si el programa es suficientemente grande, quizás vaya en varios ejecutables, una arquitectura cliente/servidor, etc.

Viendo los casos de usos, deberíamos ver qué cosas podemos hacer comunes o como librerías aparte, que podamos reutilizar. Por ejemplo, en nuestro caso del juego de ajedrez, podríamos hacer los siguientes paquetes:

·                               Paquete de ajedrez. Un paquete que sea capaz de jugar al ajedrez, pero sin ningún tipo de relación con las pantallas. Si es una clase, tendría métodos del estilo “Poner Piezas posición Inicial ()”, “Mover Pieza ()”, “Dame_Siguiente_Movimiento ()”, etc.

Sólo con este paquete, seríamos capaces de jugar al ajedrez, o de instancias dos paquetes y hacer que jueguen entre ellos, o jugar en red, etc.

Interfase con el usuario. Un paquete con el dibujo del tablero, las piezas, recoger los movimientos del usuario etc.

Dentro de estos paquetes, podemos ir pensando más subpaquetes, etc.

En este punto y con los casos de uso en general, debemos tener cuidado. Según una crítica generalizada a los casos de uso, estos llevan a un diseño funcional y no a uno orientado a objetos. Debemos tratar de pensar en objetos y almacenarlos juntos en la misma librería cuando estén muy relacionados entre sí, no en funciones. Por ello es buena idea tratar de agrupar las clases del diagrama de clases del negocio en paquetes y tratar de desarrollar la arquitectura a partir de ellas.

Es importante en este paso definir las interfaces y relaciones entre paquetes. Para ello puede servir de ayuda hacer los diagramas de secuencia de los casos de uso mostrando los actores, los paquetes y los mensajes entre ellos. Según vayan creciendo los diagramas de secuencia por aquello de ir entrando en detalles, podremos ir extrayendo subcasos de uso, como "mover pieza", "elegir color", etc.

DISEÑO DETALLADO

En el diseño detallado ya se entra a nivel de clases y métodos. Por cada paquete que hayamos extraído en el paso anterior y siguiendo siempre los casos de uso, debemos ir detallando las clases que vamos a implementar y los métodos que van a tener. Detallamos aun más los casos de uso y las interfaces de las clases.

En este punto pueden ser de ayuda los patrones de diseño. La gente que ha ido diseñando a lo largo de la historia, se ha encontrado con problemas (¿cómo hago que la clase A se entere que la clase B ha cambiado sin necesidad de que B vea a A?, ¿En qué clase pongo el método que suma las clases A y B? ¿Como me aseguro que de esta clase sólo se haga una instancia?, etc.,). Algunos de dichos problemas salen con mucha frecuencia (como los indicados de ejemplo) y se han establecido soluciones "estándar", que funcionan bien. Dichas soluciones se llaman patrones. No está de más leer algo sobre patrones de diseño orientados a objetos para tener una lista de "soluciones" a aplicar.

Hay incluso patrones a nivel de arquitectura. Es bastante conocido, por ejemplo, el patrón modelo-vista. En nuestro caso "modelo" sería el conjunto de clases que juegan al ajedrez. "Vista" sería el conjunto de clases que "pintan" la partida en la pantalla. Hacer esa separación en dos módulos, hace que nuestro módulo de ajedrez sea reaprovechable, incluso si cambiamos de entorno de ventanas (de Windows a MS-dos o de MS-dos a unix). Eso sí, es imprescindible que sólo la "vista" vea al "modelo" y nunca al revés. Si lo hacemos al revés y queremos llevarnos nuestro "modelo" juego de ajedrez, tendremos que llevarnos también parte de la "vista".

MODELADO ORIENTADO A OBJETOS (MOO)

En la programación orientada a objetos encontramos tres términos importantes para desenvolvernos en este ámbito y que nos servirán como técnicas para una mejor programación. Una de ella es el Modelado Orientado a Objetos o mejor conocido como MOO.

El objetivo principal del modelado orientado a objetos es describir los Objetos.

Un modelo representa a un sistema software desde una perspectiva específica, ya que cada modelo puede representar un aspecto distinto del sistema. La  clase de objeto describe un grupo de objetos con atributos similares, con relaciones comunes con otros objetos y con una semántica común. Los diagramas de objetos  proporcionan  una notación gráfica formal para el modelado de objetos, de clases y sus relaciones entre si.

La técnica de Modelado de Objetos (OMT que es igual a Object Modeling Technique) se basa en un conjunto de conceptos que definen que es el término de Orientación a Objetos.

La llegada de la tecnología orientada a objetos viene a proponernos y enseñarnos una forma de pensar de modo abstracto acerca de los problemas que tenemos que resolver en cual podemos emplear conceptos del mundo real y no conceptos de computadoras.

A que nos estamos refiriendo con modelado, bueno, eh aquí algunos términos básicos

·                               Modelo: abstracción de algo, con el propósito de comprenderlo antes de construirlo.

Modelos y abstracción.

Un modelo nos puede servir para:

·                               Verificar una entidad física antes de su construcción.

Abstracción: es un examen selectivo de ciertos aspectos del problema, eliminando los aspectos que no son importantes, es decir, sacar las propiedades más adecuadas del objeto. Todas las abstracciones son incompletas e inadecuadas.

Un buen modelo captura los aspectos cruciales del problema y omite el resto, así, dejando solo los aspectos más importantes.

El modelo conceptual debe ser abstracto, esto sirve para facilitar la captación y modelado de aspectos del problema de una forma lo más cercana posible a los conceptos del dominio del problema. Por lo anterior, creemos que la orientación a objetos es un enfoque apropiado para el modelado de requisitos de sistemas de información.

Modelo Conceptual.

En la fase de Modelización Conceptual se construyen tres modelos del sistema:

·                               Modelo de Objetos.

·                               Modelo Dinámico.

·                               Modelo Funcional.

Estos tres modelos describen la sociedad de objetos desde tres puntos de vista complementarios.

Modelo de Objetos.

El Modelo de Objetos utiliza un Diagrama de Configuración de Clases (DCC) para definir y mostrar la estructura y comportamiento de todas las clases identificadas en el dominio del problema, así como sus relaciones. El DCC es un modelo semántico extendido.

Parte Estática: contiene la definición de los atributos que representan el estado de los objetos de la clase. Los atributos podrán ser constantes, variables y derivados. Aquellos atributos utilizados para identificar objetos se subrayan.

Parte Dinámica: contiene la declaración de los servicios de la clase. Se distinguirá (gráficamente) entre los eventos de creación, borrado y los eventos compartidos con otras clases.

Modelo Dinámico.

En el Modelo Dinámico se representan aspectos relacionados con las secuencias posibles de eventos (vidas posibles) y la interacción entre objetos. Para representar estos aspectos, tenemos dos tipos de diagramas:

·       Diagrama de Transición de Estados (DTE)

·       Diagrama de Interacción de Objetos (DIO)

Características:

Describe los aspectos del sistema que tienen que ver con el tiempo y la secuencia de las operaciones:

·       Sucesos (eventos).

·       Estados.

·       Acciones.

Captura el control del sistema.

Se representa gráficamente mediante diagrama de estados. Diagramas de Transición de Estados.

Una vida válida de un objeto, es una secuencia de eventos que caracteriza un comportamiento correcto para todos los objetos de la clase. Las transiciones representan cambios de estado permitidos que pueden restringirse introduciendo condiciones.

La especificación de una transición posee la sintaxis siguiente:

Evento | acción | transacción [if precondición] [when condición-de-control]

Una precondición es una condición definida sobre atributos del objeto que debe satisfacerse en el estado de partida para que el servicio pueda ocurrir.

Modelo Funcional.

El propósito del Modelo Funcional es capturar la semántica asociada a los cambios de estado de forma fácil e intuitiva.

En este modelo especificaremos mediante un diálogo interactivo el efecto de un evento sobre los atributos. El valor de cada atributo se modificará dependiendo de la acción ocurrida, de los argumentos del evento y del estado actual del objeto.

Restricciones.

Dependencias funcionales.

Las tres categorías de atributos son:

·       Cardinales.

·       Independientes del estado.

Relación entre Modelos.

·       Cada modelo describe un aspecto del sistema manteniendo referencias al resto de los modelos.

·       El Modelo de Objetos define las estructuras de datos sobre las que actuarán el Modelo Dinámico y el Modelo Funcional.

·       Los sucesos serán las operaciones de los objetos definidas en el Modelo de Objetos.

Modelo de Ejecución.

Una vez especificado el sistema, un Modelo de Ejecución establece:

1.     Una representación del modelo conceptual en un entorno de desarrollo, atendiendo aspectos estáticos y dinámicos (estrategia de generación de código).

2.     Una estrategia de ejecución.

Nivel de aplicación: en este nivel se sitúan los componentes que implementan de forma completa el comportamiento de las clases especificadas en la fase de modelado conceptual.

Nivel de persistencia: en este nivel se sitúan los componentes que proporcionan los servicios necesarios para dar persistencia a los objetos del nivel de aplicación. La persistencia de los objetos actualmente se realiza recurriendo a un sistema gestor de bases de datos relacional (SGBDR).

Estrategia de ejecución.

Para animar el sistema especificado, se define una estrategia de ejecución e interacción. Para iniciar una sesión de ejecución, los pasos a seguir son:

1.     Identificación del usuario (control de acceso): consiste en la conexión del usuario al sistema. Una vez conectado se le proporciona una visión clara de la sociedad de objetos (ofreciéndole qué clases de objetos puede ver, los servicios que puede activar y los atributos que puede consultar).

2.     Activación de servicios: el usuario podrá activar cualquier servicio (evento o transacción) disponible en su visión de la sociedad. Además, podrá realizar observaciones del sistema (object queries).

Las clases que implementan las tareas de control de acceso y construcción de la vista del sistema (clases y servicios visibles) se implementarán en el nivel de interfaz. La información necesaria para configurar la vista del sistema está incluida en la especificación del sistema (relaciones de agente) obtenida en la fase de modelado conceptual.

1.     Identificación del objeto servidor: si el objeto existe el nivel de persistencia se encargará de recuperar el objeto servidor de la base de datos y si es un evento de creación reservará espacio para su almacenamiento.

Una vez el mensaje se ha enviado, se identifica el objeto servidor (la existencia del objeto servidor es una condición implícita para ejecutar cualquier evento, excepto si se trata del evento creación) y se procede a seguir una secuencia de acciones sobre dicho objeto:

2.     Transición válida de estado: se verifica en el diagrama de transición de estados que exista una transición válida (desde el estado actual a un nuevo estado) para el servicio seleccionado.

3.     Evaluaciones: se modifican los valores de los atributos afectados por la ocurrencia del servicio (como fuera especificado en el modelo funcional).

4.     Comprobación de las restricciones de integridad: las evaluaciones del servicio deben dejar al objeto en un estado válido.

Análisis: Escribir y obtener una descripción inicial del problema (Definición del Problema).

Construir un Modelo de Objetos:

·       Identificar las clases.

·       Añadir las asociaciones entre las clases.

Modelo de Objetos = diagrama del Modelo de Objetos + Diccionario de Datos

Desarrollar un Modelo Dinámico:

·       Preparar guiones de las secuencias de interacción más frecuentes.

·       Identificar sucesos entre objetos y preparar una traza de sucesos por cada guión.

·       Preparar un Diagrama de Flujo de Sucesos para el sistema completo.

·       Desarrollar un Diagrama de Estados por cada clase que tenga un comportamiento dinámico significativo.

Modelo Dinámico = Diagramas de Estado + Diagrama de Flujo de Sucesos Global

Construir un Modelo Funcional:

·       Identificar valores de entrada y salida.

Modelo Funcional = diagramas de Flujo de Datos + Restricciones.

Verificar, iterar y refinar los tres modelos:

·       Añadir operaciones clave descubiertas en la preparación del Modelo Funcional.

·       Verificar las clases, atributos, operaciones y asociaciones son consistentes y completas al nivel de abstracción elegido.

Documento del Análisis = Definición del Problema + Modelo de Objetos + Modelo + Dinámico + Modelo Funcional.