Semana 1

Desarrollo

Para el desarrollo de software orientado a objetos no basta usar un lenguaje orientado a objetos.

También se necesitará realizar un análisis y diseño orientado a objetos.

El modelamiento visual es la clave para realizar el análisis OO (orientado a objeto). Desde los inicios del desarrollo de software OO han existido diferentes metodologías para hacer esto del modelamiento, pero sin lugar a duda, el Lenguaje de Modelamiento Unificado (UML) puso fin a la guerra de metodologías.

El marco de desarrollo de una aplicación software estaría formado por las tres fases tradicionales: análisis, diseño e implementación. El análisis es la fase cuyo objetivo es estudiar y comprender el dominio del problema, es decir, el análisis se centra en responder al interrogante ¿QUÉ HACER? El diseño, por su parte, dirige sus esfuerzos en desarrollar la solución a los requisitos planteados en el análisis, esto es, el diseño se haya centrado en el espacio de la solución, intentando dar respuesta a la cuestión ¿CÓMO HACERLO? Por último, la fase de implementación sería la encarga de la traducción del diseño de la aplicación al lenguaje de programación elegido, adaptando por tanto la solución a un entorno concreto.

Los métodos orientados a objeto acortan la distancia existente entre el espacio de conceptos (lo que los expertos o usuarios conocen) y el espacio de diseño (lo que conocen los desarrolladores) e implementación, ya que los objetos del mundo real tienen una correspondencia bastante clara con los objetos del sistema informático, evitando así los grandes abismos existentes entre el análisis y el diseño en el enfoque estructurado, esto es la falta de continuidad en la representación de los c onceptos en una y otra fase, por ejemplo los DFDs y los diagramas de estructura.

Por su parte, en los desarrollos orientados al objeto se tiene una mayor continuidad entre las diferentes fases, con unas fronteras entre fases muy poco marcadas que dan lugar a desarrollos más iterativos e incrementales. Todo esto es posible gracias a una característica de vital importancia, el modelo subyacente a todas las fases es el mismo, el modelo objeto, que tiene como elemento central al objeto, que es la entidad que encapsula elementos estructurales y de comportamiento. De esta forma, los objetos semánticos identificados en la fase de análisis se refinarán durante la fase de diseño e implementación, a la vez que se añaden objetos de interfaz y de utilidad para constituir la aplicación final.

Análisis y diseño orientados a objetos (ADOO)

Como se ha comentado en el apartado anterior, la transición entre las fases de análisis y diseño en la orientación al objeto es mucho más suave que en las metodologías estructuradas, no habiendo tanta diferencia entre las etapas. Esto implica que es difícil determinar donde acaba el Análisis Orientado a Objeto (AOO) y donde comienza el Diseño Orientado a Objeto (DOO), siendo la frontera entre ambas fases totalmente inconsistente, de forma que lo que algunos autores incluyen en el AOO otros lo hacen en el DOO. Esto conduce a que sea frecuente el uso de las siglas ADOO para hacer referencia a ambas fases de forma conjunta.

Los objetos del dominio del problema representan cosas o conceptos utilizados para describir el problema, recibiendo el nombre de objetos semánticos porque ellos representan las abstracciones que encierran el significado del dominio del problema.

· El análisis se centra en la representación del problema, es decir, en la identificación de las abstracciones que representen el significado de las especificaciones y de los requisitos del sistema.

· El énfasis del diseño se centra en la definición de la solución. Los objetos semánticos serán refinados durante la fase de análisis y de diseño, siendo completados con los objetos propios del dominio de la solución.

Los objetos del dominio de la solución incluyen: objetos de interfaz, objetos de aplicación y objetos base o de utilidad. Éstos no forman parte directamente de los objetos del dominio problema, pero representan la vista del usuario de los objetos semánticos.

Una vez realizada esta introducción al AOO y al DOO se puede proceder a dar una definición más concreta de ambos procesos.

· Se puede definir AOO como el proceso que modela el dominio del problema identificando y especificando un conjunto de objetos semánticos que interaccionan y se comportan de acuerdo a los requisitos del sistema.

· Se puede definir DOO como el proceso que modela el dominio de la solución, lo que incluye a las clases semánticas con posibles añadidos, y las clases de interfaz, aplicación y utilidad identificadas durante el diseño.

No debiera darse por terminado este apartado sin enunciar cuales son las actividades propias del AOO y del DOO. Este es un asunto comprometido por la diversidad existente en el mundo de las metodologías orientadas a objeto, como se puso de manifiesto, pero de forma general podría afirmarse que:

En el AOO deben llevarse a cabo las siguientes actividades:

• La identificación de clases semánticas, atributos y servicios

• Identificación de las relaciones entre clases (generalizaciones, agregaciones y asociaciones).

• El emplazamiento de las clases, atributos y servicios.

• La especificación del comportamiento dinámico mediante paso de mensajes.

En el DOO deben llevarse a cabo las siguientes actividades:

• Añadir las clases interfaz, base y utilidad.

• Refinar las clases semánticas. Como resumen final, se podría afirmar que el AOO y el DOO no deben verse como fases muy separadas, siendo recomendable llevarlas a cabo concurrentemente, así el modelo de análisis no puede completarse en ausencia de un modelo de diseño, ni viceversa. Uno de los aspectos más importantes del ADOO es la sinergia entre los dos conceptos.

Identificación de objetos

La identificación de objetos es la clave o el cuello de botella a la hora de aplicar tanto el diseño como los análisis orientados al objeto. Existen varios enfoques en cuanto a las técnicas a aplicar para identificar cuáles son las abstracciones que mejor representan o recogen la semántica del problema que se desea resolver. Aquí se van a comentar brevemente las tres técnicas más difundidas para llevar a cabo esta actividad. Estas son:

• El análisis textual: Análisis textual Es el más simple e intuitivo de las técnicas que aquí se van explicar. Parte de una descripción del problema en lenguaje natural (en nuestro caso sería una descripción realizada en español) y consistiría en extraer los objetos, los atributos, los servicios y las relaciones entre los objetos mediante un análisis lingüístico del enunciado del problema de acuerdo a la tabla representada

• Las tarjetas CRC: Las tarjetas CRC (Class, Responsability and Collaboration- Clases, Responsabilidades, y Colaboraciones), también denominadas tarjetas de clase, constituyen una forma simple y efectiva de analizar escenarios. Esta técnica consiste en elaborar una ficha o tarjeta por cada clase en la que se anotan los siguientes datos: el nombre de la clase, la lista de sus superclases, la lista de sus subclases, sus responsabilidades y sus colaboraciones.

• Las formas de utilización: Una forma de utilización representa Clase: nombre de la clase (Abstracta o concreta) Lista de superclases Lista de subclases Responsabilidad Colaboración. Elementos de una forma de utilización una secuencia de transacciones en un diálogo con el sistema que se encuentran relacionadas por su comportamiento, las formas de utilización se representan por elipses.

Modelado de objetos

Los objetos identificados en la etapa de análisis se plasman en diferentes modelos, combatiendo de esta forma la complejidad inherente del problema al que nos estamos enfrentando. Para la construcción de modelos de objetos, y modelos software en general, se debe contar con un lenguaje de modelado, es decir, un lenguaje para especificar, visualizar, construir y documentar los componentes de los sistemas software.

A la hora de realizar un modelo de un sistema software, éste debe hacerse desde diferentes puntos de vista, de forma que recojan tanto la dimensión estática y estructural de los objetos como su componente dinámica. Un lenguaje de modelado debe aportar una serie de mecanismos gráficos que permitan captar la esencia de un sistema desde diversas perspectivas. Estos mecanismos gráficos suelen recibir el nombre de diagramas en la mayoría de los lenguajes de modelado. UML cuenta con una amplia gama de diagramas para que el analista pueda reflejar las diferentes dimensiones de un sistema. Estos diagramas se dividen en las siguientes categorías:

• Diagramas estáticos de estructura

• Diagramas de formas de utilización (casos de uso)

• Diagramas de interacción

• Diagramas de transición de estados

• Diagramas de actividad

• Diagramas de implementación

Diagramas estáticos de estructura

Estos diagramas proporcionan una notación gráfica para el modelado conceptual del sistema, es decir, permiten representar las abstracciones identificadas en forma de clases, objetos y sus interrelaciones. Existen dos tipos de diagramas estáticos de estructura: los diagramas de clases y los diagramas de objetos. Los diagramas de clases representan un esquema conceptual que describe muchas instancias de datos posibles, por tanto, los diagramas de clases van a describir clases de objetos. Durante el análisis se usan los diagramas de clase para indicar los roles comunes y las responsabilidades de las entidades que sustentan el comportamiento del sistema, mientras que durante el diseño, se utilizan para capturar la estructura de las clases que forman la arquitectura del sistema.

Por su parte un diagrama de objetos estático es una instancia del diagrama de clases, mostrándose como una instantánea del estado del sistema en un momento dado. Los diagramas de objetos describen, por tanto, la forma en que un cierto conjunto de objetos se relaciona entre sí. De lo expresado aquí se puede afirmar que un diagrama de clases dado se corresponde con un conjunto infinito de diagramas de objetos que serían instancias de dicho diagrama de clases.

Diagramas de formas de utilización

Como resumen de lo qué es un diagrama de formas de utilización, podíamos decir que se trata de un diagrama donde una serie de entidades externas al sistema (los actores) interacciona con el sistema, comunicándose con una cierta forma de utilización.

Diagramas de interacción

Un diagrama de secuencia muestra las interacciones expresadas en función de secuencias de tiempo. En concreto muestra los objetos participantes y los mensajes que intercambian entre ellos a lo largo del tiempo. Un diagrama de secuencias tiene dos dimensiones, la vertical que representa el tiempo, y la horizontal que representa los distintos objetos. El tiempo avanza desde el comienzo hasta el final de la página, aunque se puede tomar el sentido contrario.

Diagramas de transición de estados

Un diagrama de transición de estados representa los estados que puede tomar un objeto mostrando, además, los eventos o circunstancias que implican el cambio de un estado a otro. En UML, un estado es una condición que se verifica durante la vida de un objeto o de una interacción. Durante este período de tiempo se satisface alguna otra condición, se ejecuta alguna acción o se espera a la ejecución de algún evento. Un objeto permanece en un estado por un espacio finito y no instantáneo de tiempo. Cuando un objeto cambia de estado por la ocurrencia de un evento, se dice que se ha producido una transición.

Diagramas de actividad

Un diagrama de actividad es un tipo especial de diagrama de estados en el que todos o la mayoría de los estados son estados de acción, y todas o la mayoría de las transiciones son disparadas porque se ha completado la acción de los estados fuente. El diagrama de actividad se adjunta a través del modelo a una clase, a un método o a una forma de utilización. El propósito de estos diagramas es centrarse en el flujo de los procesos internos, con independencia de los eventos externos. Por ello los utilizaremos fundamentalmente para flujos de operaciones, mientras que los diagramas de estado ordinarios serán más propios de sistemas donde puedan ocurrir eventos asíncronos.

Diagramas de implementación

Estos diagramas muestran los aspectos físicos del sistema, diferenciándose dos tipos: los diagramas de componentes y los diagramas de despliegue. Los diagramas de componentes representan las relaciones de dependencia entre el código fuente, componentes binarios y ejecutables. comprobar() [comprobar=TRUE] eliminar() Ventana de entrada de orden Orden Línea de Orden Elemento de stock prepar() * prepar() necesita_reordenar() [necesita_reordenar=TRUE] nuevo Elemento ordenado [comprobar=TRUE] nuevo Elemento ordenado objeto mensaje iteración condición retorno Los diagramas de despliegue se utilizan para representar los procesos y objetos en tiempo de ejecución, así como los componentes hardware en el que estos se ejecutan