ANALISIS Y DISEO ORIENTADO A OBJETOS

El proceso del anlisis y el diseo orientados a objetos es ms complejo e importante que el lenguaje de modelado; y desde luego, es de lo que menos se oye hablar. Esta leccin est basada en el mtodo Objectory desarrollado en base a los aportes de James Rumabaugh (OMT, tecnologa de modelado de objetos), Ivar Jacobson (desarroll la ingeniera de software orientado a objetos) y Grady Broch (Quien propuso un mtodo cuyo nombre es su apellido.) denominados Three Amigos

Anlisis y diseo orientado a objetos

El proceso de diseo de software (al igual que muchos otros procesos de diseo es iterativo).
Diseo Implementacin

El desarrollo iterativo se puede distinguir del desarrollo en cascada (donde la salida de una etapa se convierte en la entrada de otro y no hay regreso). EL DESARROLLO EN CASCADA ES UN DESASTRE EN LA PRACTICA!

Anlisis y diseo orientado a objetos

Pasos del proceso de diseo iterativo

1 Conceptualizacin: Cuando se desarrollan la visin y el propsito general del proyecto. 2 Anlisis: Determinar las necesidades de la organizacin (entender lo que debe hacer el software); aqu es donde se modelan las clases. 3 Diseo: Crear el plano para solucionar el problema establecido 4 Implementacin: Crear el sistema a partir del plano de diseo; aqu es donde se desarrolla el cdigo. 5 Prueba: Asegurarse de que el sistema haga lo que se supone que debe hacer. 6 Distribucin: proporcionar el sistema a los usuarios

Diseamos e implementamos slo piezas del producto completo, iterando repetidamente en las fases de diseo e implementacin.

Anlisis y diseo orientado a objetos

Conceptualizacin Todo buen software comienza con una visin. Un individuo idea sobre un producto y piensa que sera bueno crearlo, Una buena prctica es capturar esta visin en una sola oracin o un parrfo corto y designarle un visionario.

Anlisis y diseo orientado a objetos

Anlisis de los requerimientos Es en esta fase donde suele entrar en accin el experto en diseo orientado a objetos (despus de que la visin se haya articulado). Debe entender la forma en que se va a utilizar el producto y como debe funcionar. El objetivo de la fase de anlisis es articular y capturar estos requerimientos y su resultado ser un documento de requerimientos.

Anlisis y diseo orientado a objetos

Casos de uso La primera seccin del documento de requerimientos es el anlisis de los casos de uso. Un caso de uso es: Una descripcin de alto nivel de la forma en que se va a utilizar el programa * Los casos de uso le dan muy poca importancia a la interfaz de usuario, y no le dan ninguna importancia al funcionamiento interno del sistema que se est creando.

Anlisis y diseo orientado a objetos

Casos de uso Un caso de uso es una descripcin de la interaccin entre el actor y el sistema mismo. Actor: Cualquier persona o sistema que interacta con el sistema que se est desarrollando.

Un actor enva un mensaje al sistema, y sucede algo: se regresa informacin, se cambia el estado del sistema, etc.

Anlisis y diseo orientado a objetos

Como identificar a los actores Las caractersticas esenciales de los actores son las siguientes: Son externos al sistema Interactan con el sistema Al principio, no necesitar ir mas all de la lista obvia. Generar 3 o 4 actores puede ser suficiente para que pueda empezar a generar casos de uso.

Anlisis y diseo orientado a objetos

Como determinar los primeros casos de uso Para cada actor debe determinarse como es la interaccin con el sistema, las siguientes preguntas pueden ayudarlo a encontrar casos de uso. Por que el actor est usando el sistema? Que resultados quiere de cada peticin el actor? Que ocasion que el actor utilizara el sistema? Que debe hacer el actor para utilizar el sistema? Que informacin debe proporcionar el sistema al actor? Que informacin espera el actor obtener del sistema?

Anlisis y diseo orientado a objetos

Como crear el modelo del dominio El modelo del dominio es un documento donde captura todo lo que sabe acerca del dominio . Dominio: El campo comercial en el que se est trabajando Como parte del modelo de dominio, debe crear objetos que describan a todos los objetos mencionados en los casos de uso. NO CONFUNDIR LOS OBJETOS DE DOMINIO CON OBJETOS DE DISEO.

Anlisis y diseo orientado a objetos

Cuenta banco

Objetos de dominio

Generalizacin

Ahorros

Corriente

Anlisis y diseo orientado a objetos

En el diagrama anterior, las cajas representan los diversos objetos de dominio y las lneas con punta de flecha la generalizacin. UML especifica que estas lneas se deben dirigir de la clase especializada a la clase base mas general. UML ES UN LENGUAJE DE MODELADO MUY COMPLETO, Y PUEDE CAPTURAR CUALQUIER CANTIDAD DE RELACIONES, PERO LAS PRINCIPALES RELACIONES SON. LA GENERALIZACION ---- LA CONTENCION ---- LA ASOCIACION

Anlisis y diseo orientado a objetos

Generalizacin Implica que el objeto derivado ES UN subtipo del objeto base. (La herencia es la implementacin de la generalizacin) Contencin Implica que el objeto TIENE UN

El diagrama en UML para la contencin es una lnea con un rombo que va desde el objeto que contiene hasta el objeto contenido Anlisis y diseo orientado a objetos

Asociacin Una asociacin indica que dos objetos se conocen entre s y que interactan de alguna forma.

Esto se har mas claro en tiempo de diseo

Anlisis y diseo orientado a objetos

Cmo establecer escenarios Cada caso de uso se puede dividir en una serie de escenarios. Un escenario es una descripcin de un conjunto especfico de circunstancias que se distinguen de entre los diversos elementos del contingente de casos de uso. Por ejemplo: Caso de uso: El cliente retira dinero de su cuenta: Escenario: El cliente solicita un retiro de $300 de su cuenta corriente, pero hoy ya ha retirado $100 y el lmite es de $300 por da. Se informa el problema al cliente, y este opta por retirar slo $200

Anlisis y diseo orientado a objetos

Lineamientos para los escenarios Por lo general debe asegurarse de que cada escenario incluya Condiciones previas que debe ser cierto para que el escenario comience Activadores Que hace que el escenario comience Que acciones realizan los actores Que resultados o cambios ocasiona el sistema Que retroalimentacin reciben los actores Si ocurren o no las actividades repetitivas, y que ocasiona que concluyan Que hace que el escenario termine Condiciones posteriores que debe ser cierto cuando el escenario termine.

Anlisis y diseo orientado a objetos

Diagramas de casos de uso

Anlisis y diseo orientado a objetos

Diagramas de interaccin El diagrama de interaccin captura detalles del escenario que tal vez no sean evidentes. Los objetos que interactan son objetos del dominio. Existen dos tipos de diagramas de interaccin, el diagrama de secuencia y el diagrama de colaboracin

Anlisis y diseo orientado a objetos

Diagramas de secuencia

Anlisis y diseo orientado a objetos

Anlisis de la aplicacin Adems de crear casos de uso, el documento de requerimientos capturar las suposiciones, restricciones y requerimientos del hardware y sistemas operativos. Estos requerimientos suelen estar ligados a la necesidad de tener interfaces con los sistemas existentes. Comprender lo que hacen los sistemas y cmo funcionan es un componente esencial de su anlisis. Lo ideal es analizar el problema, disear la solucin y luego tomar la decisin sobre que plataforma y sistema operativo encajan mejor en el diseo.

Anlisis y diseo orientado a objetos

Documentos de planeacin Es importante generar documentos para establecer el tiempo y presupuesto para el proyecto. Ley de Hofstadter: Siempre toma ms tiempo de lo que usted espera, incluso si toma en cuenta la ley de Hofstadter. Es importante generar un cronograma por prioridades, ya que en realidad, no terminar a tiempo. Es importante que cuando se agote el tiempo lo que tenga funcione y sea adecuado para una primera liberacin. LOS DOCUMENTOS DE PLANEACIN SIEMPRE ESTAN MAL, EN ESTA ETAPA TAN TEMPRANA ES CASI IMPOSIBLE OFRECER UNA ESTIMACIN DEL TIEMPO DE EJECUCIN DEL PROYECTO
Anlisis y diseo orientado a objetos

Visualizacin Es usual incluir en el documento de requerimientos ayudas visuales para la etapa de diseo, esto es los diagramas, imgenes, capturas de pantalla, prototipos y cualquier otra representacin visual creada para ayudarlo a idear y disear la interfaz grfica de usuario.

Anlisis y diseo orientado a objetos

DISEO El diseo es el proceso de transformar la comprensin de los requerimientos en un modelo que se pueda implementar en software. El resultado es la produccin de un documento de diseo. El documento se divide en dos secciones Diseo de clases : a su vez se divide en el diseo esttico y dinmico Mecanismos de la arquitectura: Proporciona detalles acerca de cmo se va a implementar la concurrencia, la persistencia de los objetos, etc.

Anlisis y diseo orientado a objetos

Que son las clases Las clases que usted esta acostumbrado a escribir en C++ son la implementacin de las clases de diseo. El principal obstculo puede ser encontrar el conjunto inicial de clases y comprender lo que conforma a una clase bien diseada. Una tcnica simple consiste en utilizar la descripcin de los casos de uso y luego crear una clase para cada sustantivo. Tambin podra comenzar evaluando los objetos del modelo, pero tenga cuidado, no siempre los objetos del modelo podrn modelarse como clases. Otras transformaciones Puede encontrar clases adicionales a medida que desarrolla su diseo, para encontrarlo puede comenzar a pensar en las interfaces con los sistemas existentes.
Anlisis y diseo orientado a objetos

Manipulacin de datos Si tiene que transformar datos de un formato a otro (unidades de medida, protocolos de comunicacin, etc.), es posible que una clase transformadora sea un candidato para su diseo. Vistas Cada vista o reporte que genere su sistema es un candidato para una clase, las reglas del reporte se pueden encapsular en forma productiva dentro de una clase de vistas. Dispositivos Si su sistema interacta con dispositivos o los manipula, los detalles especficos del protocolo del dispositivo deben estar encapsulados en una clase.

Anlisis y diseo orientado a objetos

Modelo esttico El modelo esttico se enfoca en tres reas de inters: responsabilidades, atributos y relaciones. La mas importante es el conjunto de responsabilidades CADA CLASE DEBE SER RESPONSABLE DE UNA COSA.

Anlisis y diseo orientado a objetos

Tarjetas CRC CRC significa Clase Responsabilidad y Colaboracin. Las tarjetas CRC slo son fichas que contiene en la parte superior el nombre de una clase individual, una lnea vertical divide la tarjeta en responsabilidades y colaboraciones. El objetivo principal es identificar las responsabilidades de cada clase. No es una sesin para definir atributos. Si al cumplir con una responsabilidad debe delegar trabajo a otra clase, debe capturar esta informacin bajo la seccin colaboraciones.

Anlisis y diseo orientado a objetos

Cmo transformar las tarjetas CRC en UML Las tarjetas CRC se pueden transformar fcilmente en clases modeladas con UML, las responsabilidades se convierten en mtodos y los atributos que se hayan identificado tambin se agregan.

Nombre de la clase Atributos Nombre de atributo: tipo Mtodos Nombre del metodo (argumentos) : tipo

Anlisis y diseo orientado a objetos

Relaciones entre clases Las principales relaciones que debe modelar son las siguientes: Generalizacin - Herencia publica Asociacin Es un concepto (Clases, funciones y mtodos amigos) Agregacin - Contencin Composicin Control del tiempo de vida del objeto

Anlisis y diseo orientado a objetos

Generalizacin

Anlisis y diseo orientado a objetos

Asociacin

Anlisis y diseo orientado a objetos

Agregacin

Anlisis y diseo orientado a objetos

Composicin

Anlisis y diseo orientado a objetos

Modelo dinmico
El modelo dinmico pretende modelar la forma en que interactan las clases. Esto es usando diagramas de interaccin que pueden ser diagramas de secuencia o diagramas de colaboracin.

Anlisis y diseo orientado a objetos

Diagramas de colaboracion

1: Revisar Cliente Cajero Auto 2: Obtener balance Cuenta Cte 6: Imprimir

Recibo

Anlisis y diseo orientado a objetos

Diagramas de transicin de estado Un Diagrama de Estados muestra la secuencia de estados por los que pasa bien un caso de uso, bien un objeto a lo largo de su vida, o bien todo el sistema. En l se indican qu eventos hacen que se pase de un estado a otro y cules son las respuestas y acciones que genera, el inicio es un circulo simple y el fin un circulo doble

Anlisis y diseo orientado a objetos

No se apresure a llegar al cdigo

Anlisis y diseo orientado a objetos

Bibliografa
- Aprendiendo Programacin Orientada a Objetos en 21 das, Anthony Sintes - Aprendiendo C++ Para Linux en 21 das, Jesse Liberty - http://www.clickear.com/manuales/uml Tutorial de UML

Anlisis y diseo orientado a objetos