ANLISIS Y DISEO ORIENTADO A OBJETO.

CLASE 3

Anlisis y diseo Orientado a Objeto Clase 3

Esta semana aprenders respecto a UML como funciona y para qu sirve, adicionalmente, conocers las caractersticas del ciclo de vida llamado RUP (Rational Unified Process) y conocers como organizar los objetos y los datos detectados en la definicin de un problema.

Datos, comportamiento y relaciones de los objetos.

Durante el transcurso de este curso, aprenderemos un hermoso camino, que comienza con la necesidad de un cliente y que termina con una solucin para l, producto de un esfuerzo en conjunto, una buena planificacin y un conjunto de reuniones en el que nos sentaremos a entender el problema de nuestro cliente, ayudarlo y asesorarlo en lo que encontremos que no est bien. Todo este proceso lo iremos documentando aplicando un conjunto de tcnicas que veremos ms adelante, sin embargo antes de entrar en aspectos tcnicos deberemos conocer algunos conceptos bsicos y realizar ciertos anlisis simples, los cuales nos darn un punto de inicio, con falencias y omisin de buenas prcticas, pero que ms adelante aprenderemos a corregir. Durante el desarrollo de la asignatura realizaremos mucho anlisis, sin embargo la forma en que lo haremos no ser al azar, aplicaremos una tcnica que ve todo como un objeto, muy similar a la forma en la que se comporta el mundo real, el cual esta lleno de stos, monitores, papeles, botellas, cuentas, tarjetas de crdito, personas etc. Todo durante esta asignatura ser considerado un objeto, sin embargo si queremos realizar un buen anlisis sobre las situaciones que nos rodean debemos comprender qu objetos participan en ello, hagmoslo ms simple y vemoslo a travs de un ejemplo haciendo un pequeo anlisis de un partido de futbol. Como podrs darte

cuenta un partido de futbol no esta compuesto por un solo objeto, es ms, si observamos con detencin podremos concluir que existen muchos, enumeremos algunos: 1) 22 jugadores 2) Pelota 3) Marcador 4) arbitro Si sumamos obtendremos que: 22 jugadores + una pelota + un marcador + un arbitro dan un total de 25 objetos, si bien la suma esta correcta, el anlisis que debemos realizar durante esta asignatura es ms simple, ya que 22 jugadores es slo la cantidad de veces que existe el objeto jugador en la cancha, pero en realidad el objeto es el jugador, slo podramos determinar que ellos son objetos distintos si existiese algo que los diferencie, por ello nos bastar con determinar que existe un objeto jugador, quedando nuestra lista simplificada de la siguiente forma: Jugador Pelota Marcador arbitro Volviendo al tema de los 22 jugadores, podemos a decir que si bien todos son un jugador y por ende el objeto es uno slo, esto no significa que los 22 jugadores sean iguales, muy por el contrario, incluso el reglamento ordena que cada uno tenga un nmero de camiseta

distinto dentro de su mismo equipo,

tambin sabemos

que cada uno tiene un nombre, un Rut, una posicin etc. Con este pequeo anlisis podemos asegurar que todos los objetos tienen ciertos datos asociados a ellos que permiten identificarlos. Hagamos una lista con los datos que consideremos son importantes para estos objetos: Jugador Dorsal (nmero de la camiseta) Nombre Posicin Goles anotados Pases dados Recuperaciones Pie con que juega

Pelota Marca

Marcador Goles del local Goles del visita

Arbitro Nacionalidad

Ahora

imaginemos

los

jugadores,

la

pelota,

el

marcador y al rbitro sobre la cancha sin moverse eso sera realmente un partido de futbol? sabemos que con slo poner a todos los objetos sobre la cancha no basta para llamar a eso un partido de futbol, entendemos dada nuestra experiencia que los jugadores realizan acciones y esto permitir dar un dinamismo propio de un partido, analicemos comportamientos de cada uno de estos objetos:

Jugador Pelota Arbitro Marcador Incrementar en uno el gol de la visita Incrementar en uno el gol del local Dar tarjeta amarilla Dar tarjeta roja Iniciar partido Finalizar partido Rodar Rebotar Dar pase Hacer gol Recuperar el baln

Como puedes ver todos los objetos tienen datos y algn comportamiento (una accin) que pueden realizar, sin embargo ser posible que un jugador d pases o haga goles si no existe una pelota y un compaero a quien darlo, pues no, esto significa que los objetos por si solos no representan un sistema y para que pueda llevarse a cabo el objetivo es necesario que se asocien entre ellos, algunas interacciones relevantes en un partido de futbol son: Partido se asocia con Marcador Partido se asocia con arbitro Partido se asocia con equipo Equipo se asocia con jugador Jugador se asocia con pelota Al igual como lo hemos realizado ahora, siempre

reconocer los objetos, conocer las acciones que pueden realizar y con quin se asocian nos servir como un buen comienzo para realizar un buen anlisis posterior.

Definicin de UML
UML, cuya sigla significa lenguaje unificado de modelado, es un lenguaje visual (basado en diagramas), que nos sirve para visualizar y documentar el software que deseamos construir y colaborar con la documentacin de todo el conocimiento de los sistemas que deseamos construir, existen en UML distintos tipos de diagramas, el objetivo de cada uno de ellos es presentar de distintos puntos de vista una parte de un sistema, esto quiere decir que por ejemplo una misma situacin puede ser diagramada (dibujada) varias veces y con ms de un tipo de diagrama, donde cada uno de ellos nos entrega un enfoque de la misma situacin pero resaltando factores como el tiempo o el orden en el que ocurren, sin embargo uno de los mayores beneficios es proporcionar a todas las partes integrantes del equipo un lenguaje comn, UML consta de una semntica y un conjunto de notaciones que hacen que todos leamos y entendamos lo mismo de un diagrama UML. UML nos permite representar un sistema desde el punto de vista esttico y dinmico, el punto de vista esttico nos muestra los elementos y como ellos se relacionan para en su conjunto dar como resultado con xito la implementacin del sistema que se desea construir. La vista dinmica en cambio modela el comportamiento de alguna parte del software en algn momento del futuro, con ello podremos aclarar ms las ideas y lo que

deseamos lograr, detectar y corregir errores antes de que sea demasiado tarde.

Etapas del ciclo de vida utilizando RUP (Rational Unified Process)

Un ciclo de vida en el desarrollo de software se entiende como un conjunto de etapas que se definen para poder realizar una tarea, en el caso de la orientacin a objetos, es muy comn utilizar una metodologa llamada RUP (Rational Unified Process), que fue desarrollada por la empresa Rational, hoy parte de IBM. El ciclo de vida es una implementacin del modelo en espiral. Se desarroll pensando en el ensamble de elementos de un contexto determinado pasando por una secuencia de pasos semi ordenados. La ventaja de RUP es que la estructura puede ser personalizada segn las necesidades especficas del proyecto (de ah lo de semi ordenadas). El ciclo de vida RUP organiza las tareas en fases e iteraciones. Fase de inicio Fase de elaboracin Fase de construccin Fase de transicin

Cada parte se termina con un hito bien definido, es decir un momento en el tiempo en que se deben tomar decisiones importantes, y en al cual ciertas metas ya deberan haber sido alcanzadas.

La fase de inicio: en esta fase se deben definir algunas caractersticas del tecnologas de proyecto a emprender (proyecto de como el contexto del informacin)

negocio1, los factores de xito (expectativas que se quieren lograr) y tratar de definir los tiempos y los costos (aproximados). Lo que necesitas definir en esta etapa es si tu y tu contraparte entienden a cabalidad el sistema. Por ejemplo debes tener presente que el proyecto est alineado con los planes de la organizacin, que se haya considerado en el presupuesto y que sea posible al final del proyecto comparar los requisitos establecidos de forma inicial con el proyecto entregado. La fase de elaboracin: el propsito de la fase de elaboracin es analizar el dominio del problema, establecer las bases de la tecnologa a utilizar en el proyecto (hardware y software), desarrollar el plan del proyecto y eliminar los riesgos ms altos del proyecto. Las decisiones respecto de la arquitectura debern ser tomadas completa considerando del una vista amplia y lo ms y mbito, funciones principales

requerimientos de rendimiento. La fase de elaboracin es

Se entiende por contexto del negocio al contexto del problema a analizar, se trata de una actividad cualquiera que no necesariamente tiene lucro de por medio.

dnde el proyecto comienza a tomar forma. En esta fase se hace el anlisis del dominio del problema y los proyectos de arquitectura comienzan a tomar forma. Las salidas para esta fase son: Un modelo de casos de uso (que veremos ms adelante) Captura adicional de requerimientos funcionales y no funcionales y de cualquier requerimiento que no est asociado con un caso de uso especfico La descripcin de la arquitectura del proyecto (hardware y software) Una lista revisada de los riesgos Una planificacin de la construccin completa del proyecto, incluyendo la planificacin de las subtareas o subproyectos que vayas encontrando en cada iteracin. Una especificacin de los casos especificando los procesos a realizar La fase de construccin: todos los durante y la fase de

construccin,

componentes

aplicaciones

restantes son desarrolladas e integradas al producto, y todas las caractersticas de funcionamiento son testeadas de forma exhaustiva. La fase de construccin es un proceso de manufactura dnde el nfasis est puesto en el manejo de los recursos y el control de las operaciones para optimizar los costos, el calendario planificado y la calidad. En esta fase se realiza la construccin de cdigo y la configuracin de la plataforma de hardware y software. En proyectos muy grandes, se deben realizar

muchas iteraciones de construccin en un esfuerzo por dividir los casos de uso en partes que se puedan transformar en prototipos demostrables y construibles. Las salidas de la fase de construccin son una serie de productos que estn listos para ser utilizados por el usuario final, como mnimo, estn compuestos por: Una aplicacin de software integrada en una

plataforma de servicios y hardware adecuado. Los manuales de usuario Una descripcin de la versin actual. La fase de transicin: el propsito de la fase de transicin es el transmitir el producto a los usuarios de la comunidad. Una vez que el producto ha sido entregado al usuario final, siempre van a existir algunos problemas que van a obligar al desarrollo de nuevos proyectos o a la correccin de parte de ellos. La fase de transicin comienza cuando se ha alcanzado una cierta madurez de los productos a entregar como para que estos sean probados por los usuarios finales (aunque no estn completamente terminados). Tambin es necesario que la documentacin para los usuarios est disponible para que estos puedan probar la funcionalidad y retroalimentar el proceso. Algunas tareas que es necesario realizar: Usuarios de prueba, para validar el sistema con las experiencias del usuario. Operaciones en paralelo entre el sistema antiguo y el nuevo. Conversin a las bases de datos operacionales.

Entrenamiento de los usuarios y la gente de soporte.

Si todos los objetivos se cumplen, el punto de entrega final del proyecto se alcanza y el ciclo de desarrollo del proyecto termina.