Leccin Evaluativa 3

El proceso a seguir para realizar desarrollo orientado a objetos es complejo, debido a la complejidad que vamos a encontrar al intentar desarrollar cualquier sistema software de tamao medio-alto. El proceso est formado por una serie de actividades ! subactividades, cu!a realizacin se va repitiendo en el tiempo, aplicadas a distintos elementos La visin general para poder tener una idea del proceso de alto nivel, son las siguientes" Fase 1.Planificacin y Especificacin de Requisitos: #lanificacin, definicin de requisitos, construccin de prototipos, etc. Fase 2. Construccin del Modelo: La construccin del sistema, las fases dentro de esta etapa son las siguientes" <!--[if !supportLists]--><!--[endif]-->Diseo de Alto i!el: $e analiza el problema a resolver desde la perspectiva de los usuarios ! de las entidades e%ternas que van a solicitar servicios al sistema. <!--[if !supportLists]--><!--[endif]-->Diseo de "a#o i!el: El sistema se especifica en detalle, describiendo cmo va a funcionar internamente para satisfacer lo especificado en el &iseo de 'lto (ivel. <!--[if !supportLists]--><!--[endif]-->$%ple%entacin: $e lleva lo especificado en el &iseo de )ajo (ivel a un lenguaje de programacin. <!--[if !supportLists]--><!--[endif]-->Prue&as: $e llevan a cabo una serie de pruebas para corroborar que el software funciona correctamente ! que satisface lo especificado en la etapa de #lanificacin ! Especificacin de *equisitos. $nstalacin: La puesta en marc+a del sistema en el entorno previsto de uso ' veces, las cosas que tenemos que modelar no tienen equivalente software, como por ejemplo, gente que emite facturas o robots que empaquetan autom ticamente los pedidos, pueden formar parte del flujo de trabajo que se intenta modelar. #ara modelar cosas que no son software +a! que obtener abstracciones para poder representar esas cosas como clases ! si lo que se est modelando es alg,n tipo de +ardware que contiene software se tiene que considerar modelarlo como un tipo de (odo, de manera que m s tarde se pueda completar su estructura

Los diagramas de clases se utilizan para modelar la vista de diseo est tica de un sistema. Esta vista soporta principalmente los requisitos funcionales de un sistema, los servicios que el sistema debe proporcionar a los usuarios finales. -asos de .so (ing,n sistema se encuentra aislado. -ualquier sistema interesante interact,a con actores +umanos o mec nicos que lo utilizan con alg,n objetivo ! que esperan que el sistema funcione de forma predecible. .n caso de uso especifica el comportamiento de un sistema o una parte del mismo, ! es una descripcin de un conjunto de secuencias de acciones, inclu!endo variantes, que ejecutan un sistema para producir un resultado observable de valor para un actor. Los casos de uso se emplean para capturar el comportamiento deseado del sistema en desarrollo, sin tener que especificar como se implementa ese comportamiento. Los casos de uso proporcionan un medio para que los desarrolladores, los usuarios finales del sistema ! los e%pertos del dominio lleguen a una comprensin com,n del sistema. 'dem s, los casos de uso a!udan a validar la arquitectura ! a verifica el sistema mientras evoluciona a lo largo del desarrollo. -onforme se desarrolla el sistema, los casos de uso son realizados por colaboraciones, cu!os elementos cooperan para llevar a cabo cada caso de uso. Los diagramas de casos de uso se emplean para modelar la vista de casos de uso est tica de un sistema. Esta vista cubre principalmente el comportamiento del sistema /los servicios visibles e%ternamente que proporciona el sistema en el conte%to de su entorno0. -uando se modela la vista de casos de uso est tica de un sistema, Fase de Construccin del Modelo &iseo de 'lto (ivel En la fase de &iseo de 'lto (ivel se intenta llegar a una buena comprensin del problema por parte del equipo de desarrollo, sin entrar en detalles de implementacin. En el &iseo de 'lto (ivel +a! una serie de actividades de planificacin, estas actividades consisten en actualizar los modelos que se tengan seg,n lo que se +a!a implementado. Acti!idades del Diseo de Alto i!el Las actividades de la fase de &iseo de 'lto (ivel son las siguientes" 12--3if 2supportLists4--56. 12--3endif4--5&efinir -asos de .so Esenciales en formato e%pandido. /si no est n definidos 0

12--3if 2supportLists4--57. 12--3endif4--5*efinar los &iagramas de -asos de .so. 12--3if 2supportLists4--53. 12--3endif4--5*efinar el 8odelo -onceptual. 12--3if 2supportLists4--59. 12--3endif4--5*efinar el :losario. /continuado en posteriores fases0 12--3if 2supportLists4--5;. 12--3endif4--5&efinir los &iagramas de $ecuencia del $istema. <. &efinir -ontratos de =peracin. Dia'ra%as de Estados #ara modelar el comportamiento del sistema pueden usarse los &iagramas de Estados definidos en la unidad 7 del mdulo $e puede aplicar un &iagrama de Estados al comportamiento de los siguientes elementos" 12--3if 2supportLine)rea>(ewLine4--5 12--3endif4--5 <!--[if !supportLists]--> <!--[endif]-->.na clase software. <!--[if !supportLists]--> <!--[endif]-->.n concepto. <!--[if !supportLists]--> <!--[endif]-->.n caso de uso. La utilidad de un &iagrama de Estados en esta fase reside en mostrar la secuencia permitida de eventos e%ternos que pueden ser reconocidos ! tratados por el sistema Diseo de "a#o i!el

En la fase de &iseo de )ajo (ivel se crea una solucin a nivel lgico para satisfacer los requisitos, bas ndose en el conocimiento reunido en la fase de &iseo de 'lto (ivel. Los modelos m s importantes en esta fase son el &iagrama de -lases de &iseo ! los &iagramas de ?nteraccin, que se realizan en paralelo ! que definen los elementos que forman parte del sistema orientado a objetos que se va a construir /clases ! objetos0 ! cmo colaboran entre s@ para realizar las funciones que se piden al sistema.

Acti!idades

Las actividades que se realizan en la etapa de &iseo de )ajo (ivel son las siguientes" 12--3if 2supportLists4--56. 12--3endif4--5&efinir los -asos de .so *eales. 12--3if 2supportLists4--57. 12--3endif4--5&efinir ?nformes e ?nterfaz de .suario. 12--3if 2supportLists4--53. 12--3endif4--5*efinar la 'rquitectura del $istema. 12--3if 2supportLists4--59. 12--3endif4--5&efinir los &iagramas de ?nteraccin. 12--3if 2supportLists4--5;. 12--3endif4--5&efinir el &iagrama de -lases de &iseo. /en paralelo con los &iagramas de ?nteraccin0. <. &efinir el Esquema de )ase de &atos.

Dia'ra%as de $nteraccin
Los &iagramas de ?nteraccin muestran el intercambio de mensajes entre instancias del modelo de clases, +a! dos clases de &iagramas de ?nteraccin" 6. &iagramas de -olaboracin. 7. &iagramas de $ecuencia. 'mbos tipos de diagramas e%presan la misma informacin, por lo que se puede usar cualquiera de los dos para e%presar la interaccin entre los objetos del sistema. La creacin de los &iagramas de ?nteraccin de un sistema es una de las actividades m s importantes en el desarrollo orientado a objetos, pues al construirlos se toman unas decisiones clave acerca del funcionamiento del futuro sistema

Creacin de los Dia'ra%as de $nteraccin

#ara crear los &iagramas de -olaboracin o de $ecuencia se pueden seguir los siguientes consejos" 12--3if 2supportLists4--5 12--3endif4--5-rear un diagrama separado para cada operacin del sistema en desarrollo en el ciclo de desarrollo actual. #ara cada evento del sistema, +acer un diagrama con Al como mensaje inicial. 12--3if 2supportLists4--5 12--3endif4--5.sando los apartados de responsabilidades ! de post-condiciones del contrato de operacin, ! la descripcin del caso de uso como punto de partida, disear un sistema de objetos que interaccionan para llevar a cabo las tareas requeridas. 12--3if 2supportLists4--5 12--3endif4--5$i el diagrama se complica, dividirlo en dos diagramas m s pequeos. #ara ello se termina la secuencia de mensajes en un mensaje determinado, ! en el segundo diagrama se comienza con el mensaje que termin el primero. &ebe indicarse en el primer diagrama que el resto de la interaccin se detalla en el segundo.