Manual Análisis y Diseño Orientado A Objeto Versión 1.1

Manual para la asignatura de Anlisis y Diseo Orientado a Objetos Versin 1.0.
Santiago Marzo de 2012
Este material ha sido diseado para el uso de los alumnos y profesores de la asignatura de Anlisis y Diseo Orientado a Objetos de las carreras del rea informtica. Queda estrictamente prohibido el uso en otros cursos ya sean en lnea o presenciales sin el consentimiento explcito de INACAP.
Pgina 1 de 152
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES
Agradecimientos.
Agradecemos a todas las personas que de forma directa o indirecta han colaborado en la elaboracin de este manual. De forma significativa agradecemos a los docentes de las sedes que nos han apoyado y colaborado con ejercicios y propuestas durante la presentacin de este proyecto. Vayan nuestros sinceros agradecimientos a los siguientes docentes: Cristian Leiva Marn, Miguel Palma Esquivel, Marcelo Montecinos Cabrera, Rodrigo Toledo de los Santos, Paola Cifuentes Berrios, Servando Campillay Briones, Emerson Ilaja Villarroel, Hugo Herrera Valenzuela, Fernando Santolaya, Manuel Morales, Roberto Prez Fuentes, Fernando Neyra Castro, Victor Brquez, Francisco Andrs Daz Rojas, Ademar Araya Fuentes, Ricardo Vera Muoz, Mauricio Torres Pizarro, Ernesto Ramos Vega, Alberto Garrido Burgos, Helton Bustos Sez, Beatriz Contreras Guajardo, Jos Landeta Parra, Luis Pacheco Toro, Patricio Araya Castro, Ivn Torres, Hinojoza Vega Mauricio, Yasna Hernndez, Vctor Orellana, Rene Valderas Aros, Ricardo Toledo Barra, Cesar Eduardo Arce Jara, Luis Ponce Cuadra, Javier Miles Avello, Carolina Ehrmantraut Caballero, Pedro Alfonso Fuentealba Martnez, Jorge Hormazabal Valds, Pedro Ernesto Ulloa Morales, Mara del Pilar Gallego Martnez, Claudio Fuenzalida Medina, Mara Encarnacin Seplveda, Francisco San Martin, Christian Sarmiento Zampillo, Romn Gajardo Robles, Ricardo Hidalgo Hidalgo, Nelson Fredy Ganga Caldern, Manuel Reveco Cabellos, Jacqueline San Martin Grandon, Sergio Vergara Salvatierra, Pablo Lpez Chacn, Cinthya Acosta, Jocelyn Oriana
Pgina 2 de 152
Gonzlez Corts, Carlos Felipe Alten Lpez, Francisco Prieto Rossi, Giannina Costa Lizama, Christian Silva, Sebastin Pastn Daz.
El aporte realizado por ustedes durante las jornadas de capacitacin ha significado mejorar enormemente entregado. Saludos. la calidad del material
Pgina 3 de 152
ndice
Introduccin al anlisis y diseo Orientado a Objetos .............................................................................................8 Definicin del anlisis y diseo orientado a objetos ......................................................................................... 11 Importancia del anlisis y diseo orientado a objetos ...................................................................................... 11 Diferentes metodologas de anlisis de sistemas.............................................................................................. 12 Los datos, la informacin y su importancia para las organizaciones. ............................................................... 18 Definicin de los datos en el contexto de un problema.................................................................................... 20 Teora de sistemas bsica y la interaccin de los objetos en una organizacin................................................ 24 Patrn ECB (Entity Control Boundary) ......................................................................................................... 27 Datos, comportamiento y relaciones de los objetos. ........................................................................................ 31 Definicin de UML ............................................................................................................................................. 36 Etapas del ciclo de vida utilizando RUP (Rational Unified Process) .................................................................. 37 Diagramas de Estructura. .................................................................................................................................. 41 Diagrama de clases ........................................................................................................................................ 41 Diagrama de objeto ....................................................................................................................................... 49 Diagrama de estructuras compuestas. .......................................................................................................... 52 Diagramas de componentes. ......................................................................................................................... 54 Diagrama de despliegue. ............................................................................................................................... 57 Diagrama de paquete. ................................................................................................................................... 59 Diagramas de comportamiento......................................................................................................................... 61 Diagrama de casos de uso. ............................................................................................................................ 61 Diagrama de mquina de estados. ................................................................................................................ 64 Diagrama de actividad. .................................................................................................................................. 66 Diagramas de Interaccin. ................................................................................................................................. 68 Diagrama de secuencias. ............................................................................................................................... 68 Diagrama de tiempo. ..................................................................................................................................... 71 Tcnicas de recopilacin y anlisis de requerimientos. ........................................................................................ 75 Tcnicas de captura de requerimientos. ........................................................................................................... 75 Entrevista. ...................................................................................................................................................... 79 Pgina 4 de 152
Encuesta. ....................................................................................................................................................... 79 Observacin directa....................................................................................................................................... 80 Definicin de actividades................................................................................................................................... 80 Relacin entre las actividades y los actores. ..................................................................................................... 82 Anlisis bsico de los requerimientos para la realizacin de un listado de actividades. .................................. 83 Diagrama de flujo de datos (Agile Unified Process). ......................................................................................... 85 Diagrama de procesos (BPMN 2.0) .................................................................................................................... 91 Diagrama de casos de uso. .................................................................................................................................. 100 Componentes del diagrama de casos de uso. ................................................................................................. 103 Actores. ........................................................................................................................................................ 105 Casos de uso. ............................................................................................................................................... 106 Relaciones. ................................................................................................................................................... 110 Identificacin del contexto en el que participan los actores. ......................................................................... 113 Identificacin de los roles. ............................................................................................................................... 114 Definicin de los actores. ................................................................................................................................ 115 Definicin de los casos de uso. ........................................................................................................................ 116 Definicin de los casos de uso. ........................................................................................................................ 117 Definicin de los tipos de relaciones ............................................................................................................... 119 Comunicacin. ............................................................................................................................................. 119 Inclusin....................................................................................................................................................... 119 Extensin. .................................................................................................................................................... 120 Generalizacin. ............................................................................................................................................ 121 Documentacin de los casos de uso................................................................................................................ 121 Definicin del caso de uso. .............................................................................................................................. 122 Flujo Normal. ................................................................................................................................................... 122 Pre-condiciones. .............................................................................................................................................. 123 Post-condiciones. ............................................................................................................................................ 123 Diagrama esttico de clases. ............................................................................................................................... 126 Introduccin al diagrama esttico de clases. .................................................................................................. 126 Utilidad del diagrama esttico de clases. .................................................................................................... 127 Componentes del diagrama esttico de clases. .......................................................................................... 128 Pgina 5 de 152
Relacin entre las clases y las tablas de un modelo entidad relacin............................................................. 138 Componentes del diagrama esttico de clases. .............................................................................................. 139 Relaciones entre las clases. ............................................................................................................................. 142 Asociacin. ................................................................................................................................................... 145 Multiplicidad. ............................................................................................................................................... 146 Asociacin calificativa. ................................................................................................................................. 148 Asociacin reflexiva. .................................................................................................................................... 148 Herencia....................................................................................................................................................... 149 Asociacin. ................................................................................................................................................... 149 Realizacin. .................................................................................................................................................. 152
Pgina 6 de 152
Pgina 7 de 152
Introduccin al anlisis y diseo Orientado a Objetos

Bienvenido al mundo de los objetos! te felicito por emprender este camino, aprenders a ver tu entorno de una forma distinta. Para ello comenzaremos trabajando con la forma en que piensas y cambiaremos el modo en la que analizas las cosas, el objetivo es convertirte en una persona capaz de hacer un buen anlisis sobre las situaciones que te rodean, ya que esto tendr un directo beneficio en los programas computacionales que crears en el futuro prximo y la forma en la que entregars soluciones al medio que te rodea. Mientras mejor entendamos nuestro entorno podremos tomar mejores decisiones. Todos mejores que otros, probablemente hemos utilizado software alguna vez y de seguro que has encontrado algunos en este momento ests recordando dos o ms software que hayas usado y cul de ellos te agrad ms, no slo considerando la usabilidad o lo vistoso del software, sino a un mundo completo que esta detrs que an no conoces pero del cual sers partcipe muy pronto, que va en desde cmo utiliza el hardware en el que funciona, la velocidad en la que se comunica por la red con otros componentes de software e incluso con la optimizacin con la que realiza clculos y los entrega al usuario. Quin se encarga de todo eso? Existe algn responsable de que todas las partes trabajen en forma eficiente? Quin debe velar porque lo que se construye solucione de la mejor forma posible un problema? Como me imagino ya lo adivinars esa persona en un futuro cercano sers t.
Pgina 8 de 152
Por eso es tan importante tener una buena capacidad de anlisis, de esta forma comprenders mejor las cosas y podrs tomar mejores decisiones, mientras ms comprendemos menos deberemos memorizar. El primer paso consiste en hacer anlisis, entender el problema de tu cliente e identificar una buena solucin. El segundo paso ser disearla, el paso previo a construirla. Muchos software comienzan a ser codificados sin un buen anlisis, lo que da como resultado un producto deficiente que no soluciona el problema del cliente. Un mal diseo provocara un software con errores en el cual se habr trabajado probablemente el doble de lo necesario, los errores en diseo comienzan notarse tarde en el desarrollo haciendo que una gran cantidad de programas queden en el 90% de su construccin, haciendo que el 10% restante implique incluso ms trabajo que el 90% anterior. Para que te hagas una idea esto no es algo que no pase en el resto de las disciplinas, has pensado en cmo quedara un edificio si la constructora comienza su tarea sin un anlisis y diseo apropiado? y si lo logra, soportar el prximo temblor? Ahora pensemos en qu sucede si el diseo es apropiado, pero proviene de un mal anlisis de requerimiento y si bien el edificio queda bonito con 80 pisos, grandes ventanales y piscina en la azotea, pero despus de construido y luego de una larga y pausada conversacin con tu cliente en la cual te tomas ms tiempo para entenderlo, haces un mejor anlisis y te das cuenta que lo que en realidad necesitaba era un bunker subterrneo para sobrevivir al paso de un tornado. A estas alturas ya no hay nada que hacer, desarmar el edificio, para dejar el terreno libre para luego comenzar a disear y construir un bunker llevar sin duda a tu empresa a un fracaso, deja a tus clientes sin un bunker y a t en
Pgina 9 de 152
un serio problema, por esto una buena capacidad tanto de anlisis como de diseo es tan importante.
Pgina 10 de 152
Definicin del anlisis y diseo orientado a objetos

El anlisis y diseo orientado a objetos es un enfoque de la ingeniera de software que permite modelar un sistema como un conjunto de objetos relacionados que interactan entre si. Para lograr esta tarea, el anlisis y diseo orientado a objetos propone una serie de diagramas entre los que destacan los diagramas propuestos en UML (Unified Modeling Language o Lenguaje Unificado de Modelado) que surge como una estandarizacin de los diagramas propuestos por muchos tericos de esta disciplina alrededor del mundo. El proceso de anlisis y diseo orientado a objetos (desde ahora ADOO) se basa en analizar un problema (generalmente asociado al manejo de datos) y tratar de resolverlo utilizando para esto estructuras del mundo real. La unidad bsica es el objeto, que combina datos y comportamientos que se realizan con estos datos y que se unen en una estructura atmica.
Importancia del anlisis y diseo orientado a objetos

El ADOO es parte de un proceso que se conoce como Ingeniera de Requerimientos, que consiste en tratar de recopilar la mayor cantidad de datos disponible respecto a una serie de procesos para los cuales se requiere construir una solucin utilizando tecnologas de informacin. Las tecnologas de informacin son un grupo de tecnologas cuyo propsito es gestionar los datos que son importantes para una organizacin. Por lo tanto los sistemas que
Pgina 11 de 152
utilizan tecnologas de informacin, no slo hacen referencia al software, sino que tambin a los procesos, las personas y la infraestructura (hardware) necesario para poder administrar de la mejor forma posible los datos que son necesarios para que la organizacin realice su propsito. Un correcto proceso de anlisis permitir a los ingenieros de software tomar mejores decisiones para la creacin, gestin y administracin de proyectos de tecnologas de informacin. Un anlisis incorrecto puede generar un enorme costo para la organizacin, pues sta puede tomar malas decisiones respecto a su negocio por no contar con la informacin correcta en el momento adecuado. Adicionalmente, el desarrollo de un proyecto de tecnologas de informacin no es un proceso que se realiza de un da para otro, sino que requiere de un tiempo que es difcil de estimar en un principio y por lo tanto su costo puede elevarse en demasa si el anlisis inicial no est bien hecho, por lo que esta etapa resulta crucial en el desarrollo de los proyectos de tecnologas de informacin.
Diferentes metodologas de anlisis de sistemas.

Al realizar el anlisis de procesos en las organizaciones, existen diferentes metodologas que se pueden ocupar para lograr el resultado esperado. Como definicin formal podemos decir que una metodologa hace referencia al conjunto de procedimientos racionales,
Pgina 12 de 152
utilizados para alcanzar una gama de objetivos que rigen en una investigacin cientfica, una exposicin doctrinal o tareas que requieran habilidades, conocimientos o cuidados especficos. Alternativamente puede definirse la metodologa como el estudio o eleccin de un mtodo pertinente para un determinado objetivo. 1. De esta forma podemos decir que las metodologas como un conjunto de pasos para lograr un objetivo, se pueden clasificar utilizando el enfoque que se aplica para el proceso, existiendo dos metodologas bsicas, una metodologa estructurada y una metodologa orientada a objetos. La metodologa estructurada se origin en los lenguajes de programacin estructurados para dar soporte a las necesidades del lenguaje. Esta metodologa sent las primeras estructuras para la definicin de la llamada ingeniera de software es decir se definieron fases y etapas para dar solucin a proyectos de software que se van a desarrollar utilizando un lenguaje de programacin estructurado. Adicionalmente a sta, surge la metodologa orientada a objetos, la cual se ha desarrollado y ha permanecido en el tiempo siendo el paradigma de anlisis y diseo de proyectos de tecnologas de informacin ms utilizada en estos tiempos. Esta metodologa que comenz a desarrollarse a finales de los aos sesenta de la mano del desarrollo de lenguajes de programacin orientados a objetos, ha evolucionado durante todos estos aos, estableciendo una serie de pasos que han sido extraordinariamente probados en una serie de proyectos. Esta metodologa evoluciona constantemente y los estudiosos del tema desarrollan nuevas formas optimizadas y cada
1
http://es.wikipedia.org/wiki/Metodolog%C3%ADa
Pgina 13 de 152
vez ms especficas para el anlisis y diseo en situaciones particulares llamadas patrones de diseo. El se desarrollo aplican de proyectos las de tecnologas de anlisis, de informacin e
orientados a objetos, requieren tcnicas orientadas a objetos que durante etapas construccin implementacin del proyecto. Estas metodologas requieren que se detecten los objetos del sistema, cmo stos interactan, cmo se comportan en el tiempo y las responsabilidades que asumen al relacionarse con otros objetos. El anlisis orientado a objetos mira todos los objetos en el sistema, agrupa sus caractersticas y comportamientos comunes, estudia sus diferencias y cmo el sistema maneja estos objetos para lograr su objetivo. En trminos sencillos, el anlisis y diseo orientado a objetos est basado en identificar a los objetos en un sistema y sus interrelaciones. Una vez que esta parte est hecha, es necesario modelar el sistema, esta etapa es similar a la etapa de la metodologa estructurada, pues tambin se sigue un proceso secuencial pero con una aproximacin diferente. Las etapas bsicas del diseo de sistemas en un modelo orientado a objetos, se pueden listar de la siguiente forma: Anlisis de Sistemas. Diseo del sistema. Diseo de los objetos. Implementacin. La etapa de anlisis de sistemas es la primera parte del proceso de desarrollo de proyectos de tecnologas de informacin orientados a objetos, al igual que en las otras metodologas. En esta fase es
Pgina 14 de 152
necesario interactuar con los usuarios del sistema (los que realizan las acciones) para identificar sus necesidades y analizar el sistema para entender su funcionalidad. Basndose en el sistema estudiado, se prepara un modelo del sistema definido. Este modelo est basado puramente en lo que se requiere que el sistema haga. En esta etapa los detalles de implementacin (como se van a hacer las cosas) no son tomados en cuenta. Slo se prepara un modelo del sistema basndose en la idea de que el sistema es un conjunto de objetos que interactan. La etapa de diseo del sistema es la siguiente etapa de desarrollo dnde se decide la arquitectura del modelo completo (hardware y software). Este sistema complejo es organizado en un conjunto de sub procesos, cada uno con su proyecto individual, los cuales van a interactuar unos con otros. Mientras se disea el sistema, es necesario poner especial atencin a las especificaciones de los procesos definidos en la etapa anterior por parte de los usuarios. Como el anlisis orientado a objetos percibe los sistemas como un conjunto de objetos que interactan, as mismo los sistemas ms grandes y complejos se pueden ver como un conjunto de pequeos sistemas que interactan entre s. En la etapa de diseo de los objetos, se definen los detalles del anlisis del sistema y del diseo para definir cmo sern implementados. Ac se decide la forma en la que se van a construir los objetos de manera de implementar las estructuras de datos, los comportamientos y las relaciones entre cada uno de los objetos.
Pgina 15 de 152
La fase de implementacin implica transformar el diseo de los objetos a cdigo, utilizando algn lenguaje de programacin. Adicionalmente se construyen todas las estructuras que darn soporte al funcionamiento del software (hardware y procedimientos). Tambin se construyen los almacenes de datos o bases de datos, para dar una forma lo ms funcional posible al sistema. Las metodologas orientadas a objeto se basan en la identificacin de los objetos del sistema. Cuando se observan de forma detenida, los objetos muestran ciertas caractersticas y comportamientos que les son propios. Mientras se desarrolla el proyecto, se utilizan ciertos modelos para identificar a los objetos. Bsicamente se usan tres modelos: a) Modelo de objetos: Este modelo describe a los objetos en un sistema y sus interrelaciones. Analiza al sistema como un conjunto de elementos estticos y no se preocupa de la dinmica que estos puedan tener. b) Modelo dinmico: Este modelo describe a los objetos en su aspecto dinmico, es decir muestra los cambios ocurridos en el estado de varios objetos que estn interactuando en un momento determinado. c) Modelo de flujo de datos: Este modelo describe bsicamente los datos que han sido transformados por el sistema. De esta forma se describen los flujos de los datos y los cambios que ocurren a los datos a travs del sistema
Pgina 16 de 152
Comparada son:
con
las
tcnicas
de
desarrollo
de
sistemas
convencionales, el ADOO tiene muchas ventajas, algunos de ellos
Reusabilidad: Las estructuras que se construyen pueden ser utilizadas en otros proyectos, esto permite reducir los tiempos de desarrollo, pues las clases que se construyen se crean de tal forma que pueden ser mantenidas para usos posteriores.
Herencia: El concepto de herencia ayuda al programador a usar cdigo existente de otra forma, es decir se pueden agregar nuevas funcionalidades o extender la funcionalidad ya existente para crear nuevas clases.
Ignorancia selectiva: la encapsulacin es la tcnica que permite al programador esconder el funcionamiento interno de los mtodos al usuario. La encapsulacin separa la funcionalidad interna del objeto de las funciones externas provistas al usuario. Esto permite al programador proteger el cdigo de cambios realizados por el usuario.
Los
sistemas
diseados
utilizando
este
enfoque
estn
ms
cercanos al mundo real pues las funciones del mundo real se mapean directamente a los sistemas. La metodologa orientada a objetos representa el dominio del problema, pues es fcil reproducir e interpretar los diseos. Los objetos en el modelo son inmunes a los cambios en los requerimientos, un objeto alumnos ser un objeto alumno independiente de ms o menos atributos o comportamientos que
Pgina 17 de 152
se agreguen. Por lo tanto los cambios se pueden desarrollar de forma ms fcil. Los diseos realizados con esta metodologa enfatizan la
reutilizacin. Las nuevas aplicaciones pueden usar mdulos ya existentes, por lo tanto se reduce el tiempo de anlisis y desarrollo, redundando esto en un costo final menor al trmino del ciclo de vida. Las metodologas orientadas a objetos, tienen una aproximacin ms natural, esto entrega mejores estructuras para el pensamiento y la abstraccin y permite un diseo ms modular.
Los datos, la informacin y su importancia para las organizaciones.

Todas las organizaciones basan su quehacer en la toma de decisiones, estas decisiones se toman utilizando los datos que la organizacin posee. Los sistemas de informacin que poseen las organizaciones y los que nosotros tengamos que construir se basan en el proceso de capturar datos, almacenarlos, procesarlos y obtener un resultado que es mostrado al usuario. Los datos que son capturados corresponden a un par ordenado de atributo con valor (atributo, valor) que representa el registro de un hecho importante para la organizacin sucedido en algn momento especfico. El atributo define qu es lo que quieres guardar y el valor define el tipo de valor asociado, es decir los rangos mximos y mnimos, y el tipo
Pgina 18 de 152
de dato. Los datos siempre estn formados por un par ordenado, ya que cada una de las partes por separado no tienen sentido. Por ejemplo (edad, 21 aos).
Cuando una organizacin registra informacin relativa a procesos que son importantes, lo hace exclusivamente para poder procesar estos datos, transformarlos en informacin y luego analizar esta informacin y tomar decisiones ms acertadas. Este proceso de toma de decisiones se ha especializado en extremo, como por ejemplo con la minera de datos, que consiste en analizar los datos ya almacenados y extraer informacin que se desconoca que exista ah, esto que si bien parece ser un poco complicado, permite a las organizaciones descubrir nuevas interpretaciones de los datos que tienen almacenados, siempre con el propsito de tomar mejores decisiones.
Pgina 19 de 152
Definicin de los datos en el contexto de un problema.

Cuando se definen los datos a almacenar es necesario siempre pensar en el proceso que se desea registrar. Recuerda que en todas las organizaciones, el proceso de registro de datos no se hace al azar, es decir cuando se registra el proceso es necesario determinar el contexto en el cual se encuentra inmerso el proceso. Por ejemplo, si tu organizacin realiza un proceso de compra y venta de productos, te va a interesar fundamentalmente registrar esos procesos y todos los otros anexos a ese proceso, por eso es necesario determinar cul es el proceso que se quiere registrar, pues de este anlisis dependern los datos que se elijan. Un punto muy importante a recalcar en esta etapa es el hecho de que las organizaciones realizan distintas acciones durante su ciclo de proceso, pero hay algunos procesos que conforman el quehacer bsico de la organizacin. Ahora si bien es posible detectar el quehacer de una organizacin de forma relativamente simple, es necesario siempre hacer un anlisis en funcin de determinar los datos que se deben registrar, por ejemplo, si analizamos los procesos que realiza una panadera, nos podemos dar cuenta fcilmente que el proceso fundamental de una panadera, en la mayora de los casos es fabricar y vender pan. Ahora bien si te fijas tambin hay otros procesos en el ciclo de vida de la organizacin como por ejemplo pagar los sueldos, comprar las materias primas, distribuir el pan entre los clientes, llevar el registro contable, registrar las ventas, etctera. Ahora, una vez que has definido los procesos, debes seleccionar los procesos ms relevantes para los cuales vas a registrar los datos, siempre
Pgina 20 de 152
pensando en un contexto determinado. As si lo que te interesa es registrar los procesos productivos de la empresa, debers registrar los datos de las compras de insumos, transformacin de materias primas a pan y su posterior venta.
Pgina 21 de 152
Si te fijas en este contexto dejamos varios procesos fuera, pero eso es lo interesante de este trabajo, debes concntrate en lo importante, es decir slo en el mbito que te incumbe en ese momento, pues no existe una solucin para todas las reas al mismo tiempo. Esta lgica de divisin de los proyectos en pequeos proyectos que se preocupen de reas especficas de la organizacin garantiza dos cosas fundamentales, primero garantiza menos costos iniciales en el desarrollo de la solucin y segundo, disminuye el tiempo de anlisis y desarrollo pues se disminuye la complejidad de los procesos a analizar (son menos los procesos que se deben analizar al mismo tiempo), lo cual genera la sensacin al usuario de que todo avanza ms rpido. Volviendo a la definicin de los datos en el contexto, una vez que defines el contexto y defines los procesos bsicos asociados a ese contexto, puedes definir las estructuras de los datos. La estructura de un dato, est asociada al concepto de dominio del dato, es decir al tipo de dato que se seleccione (nmero entero, decimal, caracteres, verdadero o falso, un objeto, etc.) y adems los valores permitidos, mximos y mnimos. Por ejemplo si analizamos los datos que podemos registrar de un alumno al momento de matricularlo (este es el contexto), nos podran interesar datos como los siguientes:
Pgina 22 de 152
Si analizamos ahora el dato de la edad, y nos detenemos a pensar un momento, podemos determinar que este dato por ejemplo es un valor numrico entero (raramente tengo 15,76789 aos), ahora el rango de los posibles valores enteros es muy extenso y por lo tanto es necesario el determinar cuales de estos valores me sirven, as logro determinar que cuando recin vi la luz del mundo, tena 0 aos y segn Wikipedia, la persona ms longeva de la tierra tuvo 122 aos2, por lo tanto el valor mximo para este dato debera ser al menos 122, de esta forma tenemos que la edad est compuesta por valores numricos enteros entre 0 y al menos 122.
http://es.wikipedia.org/wiki/Jeanne_Calment
Pgina 23 de 152
Teora de sistemas bsica y la interaccin de los objetos en una organizacin.

Existe una teora bsica para el anlisis de las organizaciones llamada teora de sistemas. Esta teora de forma muy simplificada nos indica que un sistema es un conjunto de elementos que estn interrelacionados entre s con un propsito en comn, por lo tanto el conjunto de elementos y sus interrelaciones conforman a un sistema. Adicionalmente este sistema existe dentro de lo que se conoce como la frontera del sistema (su contexto) y est sumido en un medio ambiente.
Entrada
Salida
Sistema 1 Medio ambiente
Componente del Sistema
Frontera del Sistema
Sistema 2
Pgina 24 de 152
Todos los sistemas poseen un propsito especfico y para lograrlo reciben elementos (entradas) desde el medio ambiente, los procesan y generan un resultado que se incorpora al medio ambiente. Esta salida modifica el medio ambiente, el que al mismo tiempo est siendo modificado por otros sistemas que tambin consumen recursos del medio y generan salidas, esto provoca un desbalance en el medio ambiente el cual es equilibrado nuevamente por los mismos sistemas formando un delicado balance en el ecosistema. Con la informacin que tenemos ahora podemos implcitamente definir algunas cosas, como por ejemplo que el conjunto de sistemas que se encuentra en un medio ambiente determinado tambin conforman un sistema, el cual a su vez esta compuesto por otros sistemas. Un ejemplo de esto es un ser humano, est compuesto de un conjunto de rganos que forman sub sistemas, sistema digestivo, reproductor, nervioso central, etc. A su vez, cada sistema est compuesto de rganos que estn compuestos de clulas y estas a su vez estn compuestas de una serie de componentes (membrana, ncleo, citoplasma). Ahora, si analizamos al ser humano, ste pertenece a una familia, el conjunto de familias forman una comunidad que est inserta en un pueblo, que a su vez esta inserto en una ciudad que pertenece a una regin y esta a un pas etc., etc...
Pgina 25 de 152
En las organizaciones la teora de sistemas se aplica para poder realizar un anlisis ms especfico de las distintas reas que componen las organizaciones, sobre todo cuando se trata de organizaciones complejas. Muchas veces las organizaciones son separadas en departamentos (departamento contable, de personal, de finanzas, de produccin, etc.), esta separacin permite analizar cada sub seccin de forma ms especfica, adicionalmente esta separacin permite que cada una de las secciones se especialice en su trabajo. Cuando realizamos un anlisis de las organizaciones, nuestro trabajo consiste en aplicar esta teora de sistemas y
Pgina 26 de 152
complementarla con la orientacin a objetos. De esta forma debemos definir un contexto para la organizacin (frontera del sistema), despus debemos definir los objetos que estn insertos en el sistema (componentes del sistema) y las relaciones que se establecen (relaciones del sistema).
Patrn ECB (Entity Control Boundary)

Una forma relativamente simple de graficar la relacin entre los elementos que componen un sistema es ocupar los grficos que nos entrega el patrn ECB (Entity-Control-Boundary). Antes de mostrar los grficos, es necesario entender qu es un patrn en el mundo del diseo y anlisis de sistemas. Un patrn se puede definir como: una solucin a un problema de diseo que aparece con frecuencia.3 O tambin como est definido en Wikipedia Los patrones de diseo son la base para la bsqueda de soluciones a problemas comunes en el desarrollo de software y otros mbitos referentes al diseo de interaccin o interfaces. Un patrn de diseo es una solucin a un problema de diseo. Para que una solucin sea considerada un patrn debe poseer ciertas caractersticas. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseo en distintas circunstancias.4
3 4
UML y Patrones, Capitulo 18. Craig Larman. Prentice Hall. http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o
Pgina 27 de 152
El patrn Entity Control Boundary (Entidad Control Frontera)5 se basa en la deteccin de cada uno de los componentes del modelo al momento de realizar el anlisis, de esta forma podemos definir que las entidades (Entity) son objetos que entregan o reciben datos que son tiles para el sistema, la frontera (boundary) son objetos que representan interfaces del sistema (mtodos o acciones con las cuales interactan las entidades), los objetos de control (Control) son objetos que intermedian entre las entidades y las fronteras, estn encargadas de orquestar la ejecucin de comandos que vienen definidos desde la frontera. La representacin grfica de cada uno de los componentes es de la siguiente forma:
Se opt por mantener el nombre del patrn tal cual como fue definido para evitar la confusin al leer otros apuntes.
Pgina 28 de 152
Este grfico nos permite entender de mejor forma como funciona un sistema asocindolo a la forma en que cada uno de las entidades interacta con el sistema y como esta interaccin gatilla la ejecucin de una serie de funciones que no se ven desde afuera pero que deben ser analizadas para entender cmo funcionan las cosas. Analicemos el siguiente caso: supongamos que vas a sacar plata de un cajero automtico. Si analizamos el proceso, vemos que existe una interaccin de tu parte con la interfaz del cajero lo que gatilla alguna de las acciones que aparecen graficadas a continuacin.
Pgina 29 de 152
Fjate que slo analizamos las funciones bsicas del cajero (sacar plata, solicitar el saldo, transferir fondos), pero qu pasa si adems necesitamos realizar un depsito en efectivo?, en ese caso el modelo cambia un poco y entran otras entidades y procesos a jugar.
Pgina 30 de 152
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.
Pgina 31 de 152
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
Pgina 32 de 152
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
Pgina 33 de 152
Pelota Marca
Marcador Goles del local Goles del visita
Arbitro Nacionalidad
Ahora imaginemos a 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 Dar tarjeta amarilla

Pgina 34 de 152
Dar pase Hacer gol Recuperar el baln Rodar Rebotar
Marcador
Dar tarjeta roja Iniciar partido Finalizar partido Incrementar en uno el gol de la visita Incrementar en uno el gol del local
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
Pgina 35 de 152
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
Pgina 36 de 152
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
Pgina 37 de 152
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 proyecto a emprender (proyecto de tecnologas de informacin) como el contexto del negocio6, 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 considerando una vista amplia y lo ms completa del mbito, funciones principales y requerimientos de rendimiento. La fase de elaboracin es dnde el proyecto comienza a tomar forma.
6
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.
Pgina 38 de 152
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: durante la fase de construccin, todos los componentes y 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.
Pgina 39 de 152
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.
Pgina 40 de 152
Diagramas de Estructura.
Diagrama de clases
En el paradigma de programacin orientada a objeto (POO) todos los componentes de un software son llamados objetos, por ejemplo, en un software que registra las notas de un curso algunos objetos sern, el objeto nota, el curso, el alumno y la asignatura, no te sientas mal por que se haya tratado al alumno como un objeto, pero en orientacin a objeto todo lo construido en un software recibe esa denominacin, cada uno de estos objetos tiene un conjunto de caractersticas (atributos), estados y comportamientos que debemos conocer con anticipacin antes de construir el software, con el fin de no cometer errores, de esta forma lo ms adecuado es generar un plano, que indique qu atributos, estados y comportamientos tienen cada uno (acciones que realizan), a este plano es el que en informtica conocemos como clase, donde tendremos que crear una clase para cada objeto que deseamos construir, al conjunto de todas las clases se le denomina diagrama de clases. Una vez todas las clases han sido construidas debemos proseguir con el paso nmero dos, el cual identificamos las asociaciones que existen entre ellos, por ejemplo, en el ejemplo anterior una asignatura puede contener de cero a muchos cursos (o secciones) y cada curso puede tener entre 15 (el mnimo) y hasta 34 (el mximo) alumnos, a su vez un alumno puede tener desde 3 a 8 notas, de aqu se desprenden dos conceptos, el primero llamado asociacin que es la vinculacin de dos o ms clases y la multiplicidad, que dice con cuantos objetos se asociar.
Pgina 41 de 152
El diagrama de clases por tanto se construye antes de construir el software y es un plano de todo lo que deseamos construir. En l van las clases que va a contener tu software y sus asociaciones, adems podemos decir que es una forma normada de representar un software, de esta forma todos hablamos el mismo idioma y conocemos a priori lo que debemos construir, evitando as errores o interpretaciones por parte del equipo de programadores. El diagrama de clases sea probablemente uno de los diagramas en UML ms utilizados y sirve para representar las relaciones estticas que existen entre las clases que lo componen, aclaramos qu significa esto, cuando tenemos una clase llamada auto que tiene los atributos de color, velocidad, marca y modelo, un estado (encendido o apagado) y algunos comportamientos como acelerar, frenar, encender, etc., estamos diciendo que a partir de esta clase vamos a construir un vehculo, pero no lo hemos realizado an, slo definimos en un plano (clase) llamado auto, las caractersticas y acciones que debemos construir, cuando asociamos est clase a una clase llamada rueda podemos decir que se asocian y que su multiplicidad es de 0 a 4, debido a que un vehculo eventualmente podra no tener ruedas, Sin embargo, ninguno de los dos objetos existe an, vale decir que no hay ningn auto ni tampoco ruedas, es por esto que la relacin es considerada esttica, ms adelante veremos que una vez construido el objeto auto ste podr tener una rueda, dos o todas si se las instalan y es en este momento en que la relacin se vuelve realidad, pero fue posible slo debido a que nuestro diagrama de clases nos guo para que pudisemos construir un objeto con la capacidad de poder contener entre 0 y 4 ruedas.
Pgina 42 de 152
En UML una clase es representada por un rectngulo que se encuentra sub dividido en 3 rectngulos, el primero de arriba debe ir el nombre de la clase, el cual debe representar el objeto que se construye a partir de esta clase, en el segundo espacio va una lista con todos los atributos o caractersticas que deseas tenga tu objeto y en el ltimo una lista con todos los comportamientos que tu futuro objeto podr realizar. Vemoslo con un ejemplo, supongamos que deseas construir un automvil, el primer paso es definir cules son los atributos, los comportamientos y estados que tiene un auto, para que los agrupemos de forma tal que generemos una clase llamada vehculo, entonces procedemos a ubicar el nombre de la clase en el primer rectngulo utilizando la primera letra con maysculas.
Felicitaciones!, en el segundo espacio ubicaremos todos los atributos que deseamos tenga nuestro objeto, debes tener cuidado aqu y ser selectivo con los atributos que deseas incluir en tu clase, si miramos un vehculo es probable que encontremos una gran
Pgina 43 de 152
cantidad de ellos, pero segn para que queramos el auto slo sern tiles algunos, por ejemplo, si lo que deseas es utilizar el vehculo como parte de una carrera de autos, tal vez slo nos baste con el nombre del piloto, el modelo del auto, su categora, nmero (nico en cada carrera) y la cantidad de vueltas que lleva.
El tercer rectngulo debe contener todos los comportamientos (acciones) que realizar el objeto que construirs a partir de esta clase, al igual que en el caso anterior, las acciones que pueden realizarse con un auto son ms de las que necesitamos para este caso, es por eso que slo seleccionaremos algunas, las cuales pueden ser: dar vuelta, pasar a Pitt, acelerar y frenar.
Pgina 44 de 152
Listo! hemos diagramado como ser nuestra clase vehculo, la que construiremos ms adelante utilizando algn lenguaje de programacin, la cual podremos utilizar para construir todos los vehculos necesitemos.
Asociaciones.
Un diagrama se dice que presenta las relaciones estticas entre las clases con el fin de establecer qu clases se relacionarn y cual ser su multiplicidad, en el caso anterior por ejemplo, el vehculo no es lo nico que debemos considerar para que podamos decir que construimos un software que permita gestionar una carrera, as tambin tendremos que crear la clase pista con sus respectivos atributos y comportamientos siguiendo la misma tcnica anterior, pero si construyo ambos objetos a partir de estas clases serviran por separado?, pues no si lo queremos realizar es una carrera, es
Pgina 45 de 152
por eso que debemos especificar una asociacin entre ellas, de forma tal que cuando se construyan estos objetos tambin est definida las asociaciones entre ellas, evitando as errores en la construccin, por ejemplo, para este caso es natural que la pista este asociada a los vehculos, para ello en el diagrama es necesario unirlas a ambas con una lnea para representar esta asociacin.
De esta forma sabemos que el vehculo esta asociado a la pista, pero an nos queda determinar quien esta asociado con quien, ya que la lnea no lo explica por si sola, pudiendo alguien pensar que un vehculo esta asociado a 3 pistas, lo que, al menos en lo que nosotros deseamos representar ahora no es correcto.
Pgina 46 de 152
Multiplicidad.
Uno a uno: esta relacin se da cuando dos instancias de una clase tiene una asociacin de uno es a uno en ambos sentidos, un buen ejemplo es el matrimonio, en el que un hombre se asocia a una sola mujer y una mujer a un solo hombre, variables como el divorcio, no interfieren con este ejemplo, debes tener presente que un diagrama de clases es una foto de un momento, no de lo que puede hacer un hombre o mujer a lo largo de su vida.
Uno a muchos: Esta relacin se da cuando un objeto esta asociado a ms de un objeto de otro tipo, un buen ejemplo es que una madre puede tener ms uno o varios hijos.
Pgina 47 de 152
Uno a una cantidad limitada de elementos: esta relacin se da cuando un objeto puede estar asociada con una cantidad limite de otros elementos, cuyo limite puede encontrarse en el nmero mnimo o mximo, por ejemplo un curso para formarse necesita un mnimo de 15 alumnos, pero puede tener como mximo 34, tambin es posible que un objeto pueda asociarse con un mnimo de cero, en este caso se define que podra no existir una asociacin si lo requiere, por ejemplo, si tratas de lanzarte en una carrera presidencial necesitars un mnimo de firmas que avalen tu candidatura, este proceso de recoleccin es una asociacin de cero a muchos, ya que podras no conseguir votos como podras tener millones.
Mucho es a Muchos: Representa una asociacin donde un objeto se asocia de uno a es a mucho en cualquier direccin, por ejemplo, un alumno tiene muchas asignaturas y una asignatura tiene muchos alumnos.
Pgina 48 de 152
Diagrama de objeto
Los diagramas de objetos son similares en su anotacin al de diagrama de clases y son un complemento que se utiliza para enfatizar la relacin que existe entre dos instancias de clases en un momento especfico de tiempo, la diferencia de este diagrama es que no se presenta como una relacin esttica con su respectiva multiplicidad, a cambio, muestra cmo un objeto se relaciona con otros objetos luego de haberse construido, es decir un ejemplo de cmo se ver en el futuro en algn instante de su vida, recuerdas el ejemplo del vehculo y su relacin esttica con una posible cantidad de cero a cuatro ruedas?, podramos realizar un ejemplo de la relacin con sus ruedas, pero para eso debemos tener objetos de tipo vehculo y algunas ruedas, as que el primer paso ser construir un objeto de tipo vehculo segn lo que definimos en nuestra clase, por si no lo recuerdas en ella especificamos que un vehculo tendra un color, una marca y un modelo, no te preocupes si no sabes como armar un auto por que no lo vas a necesitar, en informtica un objeto es slo una agrupacin de informacin y acciones que se pueden realizar con ella, debido a esto se considera un objeto a una agrupacin de valores dados a cada una de los atributos definidos en el diagrama de clases, por ejemplo si construimos un objeto auto de tipo vehculo bastar con darle un nombre, el cual podra ser miObjetoAuto, un valor para el atributo color, que te parece rojo, una marca, le pondremos Ford, al modelo Mustang, y a la velocidad cero. Cuando nuestro objeto ya esta construido es cuando las acciones que pueden realizar toman sentido, por ejemplo si utilizas el comportamiento encender
Pgina 49 de 152
el estado del vehculo pasar de apagado a encendido y si aceleras un clculo matemtico har que la velocidad avance de cero a uno, como puedes darte cuenta la construccin de un objeto pasa por dar valores a sus atributos y al igual que las clases, los objetos tambin se pueden representar de la siguiente forma:
En lo ms alto del rectngulo est el nombre del objeto y separado por dos puntos el tipo de objeto que es, en la parte inferior van los atributos y los valores que tienen, as como este puedes crear todos los objetos que desees, incluso otro con iguales valores en sus atributos, la nica regla es no repetir el nombre del objeto, vale decir que el prximo objeto no podr llamarse miObjetoAuto. Esta representacin es un ejemplo que ayuda a los programadores a entender mejor cmo se debe comportarn los objetos cuando sean construidos. Tambin se dijo que un vehculo puede tener de cero a cuatro ruedas y as est especificado en el diagrama de clases, pero en el diagrama de objetos es cuando puedes mostrar un ejemplo de cmo esa relacin luce en algn momento de la vida de tu auto, habr ocasiones en la que el vehculo tendr todas las ruedas y otras ocasiones en las que tendr 3 o menos. As
Pgina 50 de 152
puedes dibujar un diagrama para cada situacin que consideres vale la pena aclarar, el siguiente ejemplo muestra un vehculo asociado a una sola rueda, la cual proviene de una clase llamada Rueda que define que para cada rueda se debe especificar su marca y el aro de llanta para la cual esta hecha.
Pgina 51 de 152
Diagrama de estructuras compuestas.

La relacin de asociacin entre clases se da muy a menudo en un diagrama de clases, sin embargo este diagrama no permite presentar el contexto en la que la relacin deber efectuarse. Para que sea ms clara, este caso es principalmente dado en la relacin de composicin. Para que podamos comprender bien cmo funciona, vamos primero a aclarar qu es la composicin en el diseo orientado a objetos: si miras a tu alrededor podrs ver que hay muchos objetos que se asocian con otros para realizar una actividad, como lo son el chofer y su auto o el ascensor y el edificio, sin embargo, es posible tener un auto sin chofer o un ascensor sin edificio, por ello en ambos casos la relacin es de 0 a N, vale decir que puede no tener como tambin podra tener varios, pero hay casos en la que dos objetos dependen uno del otro para formar un todo, si pensamos en el vehculo notaremos que est compuesto por carrocera, motor y ruedas entre otros, o dicho de otra forma podemos decir que se encuentran asociados (tienen relacin), pero esta relacin en particular no es una relacin de asociacin, dado que si bien el motor existe sin las motor ni ruedas o viceversa, el auto no puede existir sin
carrocera, esto es debido a que el vehculo esta compuesto de ellas, entonces, cuando hacemos un diagrama de clases podemos especificar que dicho vehculo se asocia con un motor y que el motor mover cuatro ruedas, pero para los que no conocen bien el funcionamiento del auto podra ser difcil determinar que de las cuatro ruedas dos son las de adelante y dos las de atrs, dada esta dificultad, el diagrama de estructuras compuestas nos permite representar esta situacin con un ejemplo, que representa algn
Pgina 52 de 152
momento de la vida del objeto cuando se est llevando a cabo la composicin. Abordemos con ms profundidad el ejemplo del vehculo para que veas como el diagrama ayuda a presentar informacin del funcionamiento interno que a simple vista no es posible apreciar, si en nuestro diagrama de clases, decimos que un auto tiene una relacin con un mnimo y mximo de un motor, esto quiere decir debe tener uno de forma obligatoria y una relacin de cero a cuatro rueda a menos que desees construir el troncomovil de Pedro Picapiedra. A pesar de que la informacin parece clara y completa, si analizamos ms a fondo la informacin que se nos ha entregado comenzarn a salir dudas, por ejemplo, qu hace el motor con las ruedas?, es el encargado de moverlas?, si fuese el motor, debe mover las cuatros al mismo tiempo, slo las de adelante o slo las de atrs?, o es un vehculo extrao que puede mover las dos ruedas de un mismo lado? Con el diagrama de estructuras estas dudas son aclaradas, presentan como un dibujo un ejemplo del auto ya construido, es decir, posterior a llevar la clase a un objeto, en l se dibujan las partes que le componen y qu tipo de vinculacin tiene las partes, cules se asocian con cul y con cuntas, as podramos dibujar de forma clara que un auto tiene una parte llamada motor y cuatro ruedas, pero dos de ellas son las traseras y dos las delanteras y que es el motor el encargado de mover las delanteras. (Esto cambiar dependiendo del tipo traccin que tenga el vehculo). Veamos un ejemplo de cmo ser este diagrama:
Pgina 53 de 152
Diagramas de componentes.
El diagrama de componentes es un diagrama de alto nivel de abstraccin, en l van modelados todos los (elementos) que componen un software. En componentes l vamos a
representar los componentes que van incluidos pero no funcionan, sin embargo si debemos especificar cules se comunicarn entre s, tal vez la palabra componente sea algo que an no te haga mucho sentido, pero para explicarlo de otra forma, un componente es una pieza de software, es muy similar como cuando armas un puzzle, imagnate con un nuevo puzzle en la mano recin comprado y llegas con l a casa para comenzar a armarlo, lo primero que notars es que no viene armado donde slo podrs
Pgina 54 de 152
ver piezas sueltas que parecen no tener una conexin entre s, sin embargo en la mayora de los puzzles en la tapa de la caja traen una vista del puzzle armado podras armarlo sin eso? Probablemente no y el puzzle al igual que el software muchas veces se construye de la misma forma, por piezas, y alguien debe encargarse de realizar un diagrama que muestre cmo deben ensamblarse, tambin notars que cada pieza del puzzle esta diseada para comunicarse con alguna otra pieza, a esto en informtica le llamamos interfaces, la cual expone una forma de comunicacin con otros componentes, entonces un software esta compuesto por varias piezas llamadas componentes y cada una de ellas tiene una o mas interfaces para comunicarse con otras, sin embargo el software tiene una ventaja por sobre la pieza del puzzle, ya que, en el caso del puzzle cada pieza sirve slo para ensamblarse con una pieza en particular, en el software en cambio las interfaces expuestas sirven para conectarse con ms de un componente, creando piezas que permitirn tener ms de un uso. Un componente de software es una pieza que representa un conjunto de funcionalidades que dependern del tipo de software va a realizar, por ejemplo, si pensamos en un software que va a permitir que los usuarios utilicen una pgina web, en la cual pueden chatear luego de registrarse y cumplir con ciertas condiciones, los componentes seran los siguientes: Componente de negocio: un componente encargado de aplicar clculos matemticos o de verificacin de formato de datos para saber si un usuario cumple con los requisitos que le pide el software para poder registrarse, por ejemplo, si es mayor de edad, si escribi su nmero de celular respetando el formato solicitado.
Pgina 55 de 152
Componente de pginas Web: el cual representar un conjunto de pginas web con las que el usuario va a interactuar. Componente de chat: el cual va a representar un software ms pequeo (conjunto de clases) que permitir a los usuarios comunicarse entre si en tiempo real. El siguiente dibujo muestra cmo debe representarse un
componente.
Para que un componente pueda comunicarse con otro componente debe tener lo que se conoce como interfaces, una interfaz es un punto de entrada para que otros componentes puedan obtener del l el servicio que presta, un buen ejemplo es un componente que valida el Rut, es posible que si deseas registrarte en una pgina Web y entre los datos que solicitas est el Rut, es muy probable que desees que el Rut sea vlido, para llevar a cabo esto el componente de negocio tendr entonces una interfaz que permita recibir el Rut para luego informar si esta correcto o no, este componente a travs de dicha interfaz, podra reutilizarse en todos los software que requieran validar el Rut, de esta forma tenemos un componente de software que a diferencia de la pieza del
Pgina 56 de 152
puzzle podemos volver a utilizar en cada software en el que se necesite. Una interfaz se representa de la siguiente forma:
Diagrama de despliegue.
El diagrama de despliegue es un diagrama que permite mostrar la relacin fsica que tendrn los componentes de software y hardware de un sistema, la mayora de los programas de hoy estn distribuidos en ms de un computador, un buen ejemplo es el Windows Live Messenger o Gtalk, estos software presentan ante el usuario una ventana para que stos puedan escribir un mensaje y enviarlo a otros usuarios, pero has pensado que sucede al presionar el botn enviar?, pues al hacerlo los datos son tomados y son enviados a otra aplicacin, la cual posiblemente est incluso en otro pas, este software es el encargado por medio de una interfaz de recibir tu mensaje, ubicar al destinatario y envirselo para que lo pueda leer. Como puedes ver la aplicacin que instalas en tu computador de poco servira sin la otra, la cual es la que hace posible que cientos de miles de personas se comuniquen, ese equipo que presta el servicio de comunicar se le denomina
Pgina 57 de 152
servidor, nombre que se le puede aplicar a todo equipo que preste algn servicio, as como este ejemplo existen muchos, que incluso tienen componentes en ms de dos equipos. Cuando se da este tipo de casos el diagrama de despliegue nos sirve para ubicar en que Hardware (en que equipo fsico) debe ir cada componente para que los encargados de instalar el software sepan como hacerlo, por supuesto esto no es una receta de cocina, tambin hay miles de otros software donde todos sus componentes van en el mismo lugar, en dicho caso el diagrama de despliegue ser mucho menos necesario. Un ejemplo del caso mencionado lucir as:
Cada uno de los cuadrados dibujados con profundidad son denominados nodos y representan un equipo donde se realizar la instalacin, por ejemplo el software de chat esta instalado en el cliente y el segundo componente, el cual se encarga de reunir a todos los componentes de chat para que puedan comunicarse esta en el equipo denominado servidor.
Pgina 58 de 152
Diagrama de paquete.
El diagrama de paquete sirve para formar una mejor visin de qu queremos construir, para ello lo divide en subsistemas ms pequeos, la agrupacin de los elementos se define en funcin de algo que ellos tengan en comn y que los identifique como grupo, para luego mediante flechas representar la dependencia que existe entre ellos, es decir los elementos de un grupo que dependen de otro que se encuentran en un grupo distinto, esto se hace para dar orden y claridad en el diagrama, de esta forma evitamos tener ciclos dentro de nuestra estructura, conoces el dilema de si es primero la gallina o el huevo?, pues casos similares a estos tambin se dan en el software, la dependencia es un tema que hay que tomar muy en serio a la hora de construir un programa, un error de dependencia de software sera el equivalente a tratar de hacer una vela en una caverna sin luz, donde para realizarla necesitas luz, pero para generar luz necesitas la vela, como puedes ver hay una dependencia mutua que hace imposible que podamos generar la luz necesaria, en el software esto tambin se da: imaginemos que estamos en un lugar donde arriendan internet y en cada equipo hay una aplicacin que bloquea el teclado cuando recibe la orden desde el computador del encargado del lugar, adicionalmente para que los usuarios no puedan engaar al sistema y piensen en apagar y encender el equipo el software para iniciar tiene un componente que busca en la red si el equipo del operario esta activo para regular el uso, de no ser as el sistema no permite usar el equipo y lo apaga, por otra parte el sistema del operario tiene un componente que se encarga de verificar cules computadores estn funcionado en la red para que puedan ser gestionados, pero si no encuentra ninguno la aplicacin se cierra.
Pgina 59 de 152
Cuando llegue la noche y apagues todos los Pcs, al da siguiente no podrs volver a usar el sistema, dado que el software del operario espera a los clientes y el software que est en los clientes espera al operario. El error de lgica anterior que refleja una dependencia de componentes puede ser an peor dentro de la construccin del software, dado que mientras desarrollas un programa puedes cometer tambin un error de dependencia, es decir, puede verse afectado por esto incluso mucho antes de que el programa concluya, Cmo es esto posible? Muy sencillo, imagina que dentro de tu software para crear un archivo utilizas el componente llamado creador de archivos y este a su vez mediante su interfaz espera un componente llamado leerDisco el cual verifica que el espacio sea suficiente en el disco, el problema es que la informacin del disco en el que se quiere guardar el archivo va en el componente creador de archivos, el cual para iniciarse requiere que mediante su interfaz el componente leer disco le entregue la informacin necesaria para escribir el archivo, en este caso el software nunca podr instalarse, dado que hay dos componentes que estn iterativamente esperando al otro para poder iniciarse. De esta forma el diagrama de paquetes permite ver de forma agrupada en paquetes los elementos que componen el software, uniendo los paquetes con lneas discontinuas entre aquellos que exista dependencia de algn tipo.
Pgina 60 de 152
Diagramas de comportamiento.
Diagrama de casos de uso.
Este tipo de diagramas es esencialmente til durante la etapa de anlisis, es decir cuando estas comenzado a entender lo que necesita construir tu cliente, ya que su finalidad es describir los actores que interactan con el software y los procesos que deben realizar. Un actor se considera a cualquier elemento que interacta con tu programa, que pueden ir desde otros software, un robot o humanos, el caso de uso se refiere a todas las acciones que tu software realizar, por ejemplo si estas considerando realizar un software que simule una agenda entonces tendrs un solo actor, (el encargado de agregar informacin a la agenda) y los procesos o casos de uso que realizar sern, agregar un contacto, agregar una actividad a realizar, ver las actividades pendientes, verificar los datos de un contacto previamente agregado, etc. De todas estas acciones no es necesario tener con toda claridad toda la
Pgina 61 de 152
lgica que hay tras el proceso, la idea principal es slo identificar los procesos y quin es el encargado de realizarlos. Este tipo de diagramas es muy til para apoyar el proceso de anlisis con tu cliente sobre lo que deseas que haga el software, debes considerar lo difcil que es para ellos explicar sus necesidades de programa y ms an todos los procesos que ellos mismos quieren realizar, donde olvidar alguno podra ser catastrfico, para el software, para tu cliente y para ti, ya que terminar agregndolo al final, trabajando ms de lo pactado y potencialmente atrasando la entrega. Es posible pensar que si se ha olvidado de algo la responsabilidad sea del cliente, en parte s, pero tambin debes recordar que t eres el experto y si notas que la ausencia de un proceso generar un problema en el software es parte de tu trabajo advertirlo. Todos los procesos que deseen incluirse posteriormente deben ser pactados como un nuevo requerimiento, lo cual tendr un nuevo costo para el cliente. Un actor en un sistema es representado con un dibujo de persona con cuerpo de palito, el siguiente ejemplo representa un actor y su respectivo rol en el software.
Actor1
Pgina 62 de 152
Un actor es el encargado de ingresar informacin al software, es l quien a travs de las interfases que tiene el sofware agrega la informacin que se desea almacenar y procesar, tambin es quien recibe la informacin procesada en el momento en que lo requiera. Un caso de uso, por otro lado, permite mostrar la forma en que el sistema presenta sus procesos para que sean usados por los distintos usuarios que interactan con el.
El siguiente ejemplo muestra cmo un actor interacta con la agenda, especificando que el actor realiza una accin llamada agregar contacto. Segn los requerimientos que desees modelar, puedes agregar ms procesos dentro del mismo diagrama o dibujarlos por separado segn lo necesites, agregando todos los procesos que requieras que se encuentren asociados a un mismo actor o bien agregando un segundo actor y todos sus procesos.
Agregar Contacto
Actor1
Buscar contacto
Pgina 63 de 152
Diagrama de mquina de estados.

Este diagrama muestra los estados por los que pasa un nico objeto en respuesta a los eventos que este efecta. Para que lo entendamos mejor primero veamos lo relativo a los estados, un estado es una condicin en la que se encuentra un objeto en un determinado momento de su vida, esto sucede en cualquier orden de cosa, a tu alrededor podrs encontrar muchos ejemplos, tu mismo tienes varios estados: alegre, triste, concentrado, etc. Sin embargo para que estos eventos vayan
cambiando debe suceder algo para que tu estado cambie. Por ejemplo, si hoy por la tarde llegas a casa y descubres que eres el nico ganador de un millonario premio, seguramente tu estado pasar a ultra feliz al borde del colapso nervioso, sin embargo para que esto ocurra ha tenido que suceder lo que denominamos un evento, en este caso particular al evento le podramos llamar ganar la lotera, al igual que en este ejemplo, en el software los objetos que lo componen tambin pasan por eventos, los cuales van cambiando su estado, un ejemplo sencillo puedes verlo en tu navegador, cuando haces clic en el cono por primera vez el estado inicial de este es a la espera en la que el navegador no esta haciendo otra cosa que esperando que hagas algo, cuando escribas una direccin de internet y presiones el botn de bsqueda, habrs generado un evento en l, el cual podramos llamar buscar este evento har que el navegador pase del estado en el que se encontraba a un nuevo estado que podramos llamar mostrando pgina en el que el navegador lee la informacin que le llega de internet para mostrrsela al usuario, as puedes identificar varios
Pgina 64 de 152
eventos que cambiarn el estado de tu navegador, por ejemplo si haces clic en el botn para minimizar o maximizar. Este diagrama presenta el estado inicial del objeto y va
representando con flechas acompaadas de un nombre el evento que se ejerci sobre el objeto, para luego finalizar en un nuevo estado, se puede ver un ejemplo en la siguiente figura:
En el diagrama de estados se debe definir un comienzo y un final, de esta forma podremos saber cul es el estado inicial y cul es el final. Para especificar el estado inicial se utiliza el siguiente smbolo:
Y para el estado final se debe utilizar:
Quedando el diagrama completo de la siguiente forma:
Pgina 65 de 152
Se podra pensar que en un diagrama de estados el estado inicial y final podrn omitirse debido a que las flechas determina la direccin en la que los estados van cambiando, sin embargo estos no pueden omitirse debido a que un diagrama de estados no es necesariamente lineal, por ejemplo, una persona podra pasar de estar divorciado a casado si vuelve a contraer matrimonio, sin embargo si vuelve a romper su relacin volver a estar divorciado, este ejemplo es representado en la siguiente imagen:
De esta manera queda definido que nuestro objeto sin importar la combinatoria que realice siempre finalizar casado.
Diagrama de actividad.
Este diagrama es muy similar al diagrama de mquinas de estado, la diferencia principal es que en el diagrama de actividad no muestra los estados de los objetos si no que modela cmputos y flujos de trabajo, especificando el orden en el que se llevan a cabo, adems se asume que no existen interrupciones externas para dichos flujos, de ser as ser mejor modelar utilizando el diagrama de maquina de estados visto previamente.
Pgina 66 de 152
En este diagrama se modelarn uno o ms estados de actividad, donde cada uno de ellos representa el funcionamiento de una actividad que ocurre en un flujo de trabajo, para cada flujo es necesario definir un inicio y de all se da paso a la ejecucin de la primera actividad, cada una va inicindose conforme va terminando su actividad predecesora, lo que implica que es el termino de una actividad dentro del flujo la que da inicio a otra, este diagrama permite adems modelar bifurcaciones dentro del diagrama, de esta forma segn el resultado de la actividad que se ha ejecutado es posible tomar ms de un camino, en otros casos y segn se requiera tambin es posible que dos actividades se ejecuten de forma simultanea. Veamos un ejemplo, supongamos que hoy vas al teatro, el proceso es relativamente simple, vas, pagas, si gustas dejas tus datos para futuras promociones y luego de cancelar se asigna un asiento para ti. Para modelar este flujo representaremos en un diagrama de actividades cada una de ellas como un cuadrado con los vrtices redondeados y en el centro el nombre de la actividad, tambin utilizaremos una flecha que una las actividades para poder modelar el orden en el que se ejecutan. Por lo tanto cada uno de las actividades descritas deber ir de la siguiente forma:
Pgina 67 de 152
El orden en el que se ejecutarn son modelados con una flecha que ndice que orden del flujo del proceso.
Si el trmino de una actividad puede dar inicio a ms de una actividad dependiendo de alguna condicin la bifurcacin que all se produce se representa con un rombo:
Diagramas de Interaccin.
Diagrama de secuencias.
El diagrama de secuencia es un diagrama que muestra la forma en la que interactan los objetos dentro de un software agregando el factor tiempo, de esta forma se puede visualizar el orden en el que se ejecutan las llamadas en forma ordenada a partir de una peticin, la mayora de las veces con un diagrama de caso de uso es suficiente para comprender como interactan las partes, sin embargo hay algunos casos en los que el proceso puede ser ms complejo o requiera una explicacin mayor, es por ello que el diagrama de secuencias viene casi siempre a partir de un caso de uso especifico.
Pgina 68 de 152
Para representar los objetos en este diagrama UML utiliza rectngulos con sus nombres subrayados.
La diferencia es que abajo del objeto agregaremos una lnea segmentada que simbolizar el tiempo de vida del objeto durante el proceso que deseamos representar de la siguiente forma:
El paso se siguiente es dibujar las llamadas entre los objetos si es que las hay, una llamada har que un objeto realice alguna accin que tarda algn tiempo, la cual al finalizar podr realizar otra llamada para ejecutar alguna tarea de otro objeto o de el mismo si es necesario. Veamos con un ejemplo que representa la interaccin entre las personas de un restaurante, veremos como interacta el cliente, el mesero, el cocinero y el encargado de la caja, a travs de este ejemplo veremos el orden en el que participa cada uno, tambin permite apreciar cuando una actividad comienza y cuando otras terminan.
Pgina 69 de 152
Como puedes ver en el diagrama, al seguir la lnea de tiempo del cliente vers que se une con el mesero con una lnea (una llamada) que simboliza el momento en el que se ordena la cena al mesero, a partir de ese momento ambas lneas tienen un rectngulo, lo cual significa que la llamada que hace la solicitud de comida activa a ambos (cliente y mesero) por lo cual los dos
Pgina 70 de 152
generan una accin, cuando ambos se han puesto de acuerdo el mesero solicita al cocinero que prepare el plato, a partir de ah, el cliente y el mesero quedan a la espera mientras el cocinero prepara el plato, como el proceso de preparar el plato tarda tiempo, el mesero aprovecha para servir la bebida al cliente, luego la interaccin entre el cliente y el mesero vuelve a quedar a la espera, tiempo despus el cocinero hace una llamada al mesero (entrega), en el cual le entrega el alimento al mesero, cuando eso sucede slo el mesero comienza a tener actividad, el cual corresponde al tiempo en el que el mesero prepara la bandeja y lleva la comida al cliente, cuando sta es entregada el mesero queda en actividad, sin embargo el cliente queda con la satisfactoria tarea de comer lo que ha solicitado y disfrutar un momento de su familia, los cuales posiblemente estn celebrando que su hijo ahora es estudiante de educacin superior y que ahora lee este manual, cuando finalizan de cenar pagan y as finaliza el proceso.
Diagrama de tiempo.
Este diagrama permite mostrar el cambio de estado o valor de los elementos a travs del tiempo, prcticamente todos los objetos durante su vida van cambiando sus valores o estados y muchas veces estos cambios son producidos por factor que tiene relacin con el tiempo, antes de continuar es bueno aclarar que el estado la mayora de las veces tambin produce un cambio en el valor del objeto, por ejemplo, si tienes un termmetro digital,
Pgina 71 de 152
que acompaa la temperatura con un mensaje que dice mucho calor es por que el valor de los grados Celsius es mayor a 25, cuando dicho valor baje a 18, el estado cambiar a templado . Con este diagrama puedes mostrar los cambios de estado por los que pasa un objeto a travs del tiempo, un ejemplo sencillo es el funcionamiento de una lavadora, ya que, las lavadoras actualmente se encargan de pasar por varios procesos, determina el peso de la ropa, llena el tambor con agua, lava, enjuaga y centrifuga, este proceso por ejemplo esta definido en funcin del tiempo, para diagramar esto, utilizaremos un grafico con coordenadas X e Y, donde el eje X representa el tiempo e Y los estados, as como muestra el siguiente figura:
Pgina 72 de 152
Pgina 73 de 152
Pgina 74 de 152
Tcnicas de recopilacin y anlisis de requerimientos.

Tcnicas de captura de requerimientos.
Por lo general las personas que hacemos software nos encanta, es un entretenido reto que se lleva en conjunto con un equipo de trabajo, en el cual ponemos todo nuestro esfuerzo en construir un software que utilice datos provenientes de nuestros clientes, los procese para luego entregar informacin relevante para ellos, la cual por lo general va agrupada y ordenada segn ciertos criterios, sin embargo muchos software tienen defectos y cuando digo esto no me refiero en particular a que cada cierto rato muestren un mensaje de error o produzcan una cada en el rendimiento de nuestro equipo, sino que, muchos software que nacen de una necesidad del cliente pero que no cumplen con lo que el cliente ha solicitado, veamos el siguiente ejemplo para ilustrar el concepto, supongamos que hoy te regalar el auto de tus sueos y lo mejor de todo es que el vehculo ser como tu lo especifiques, como muchos que lean este libro sus requerimientos sern mas o menos as: Llantas aro 17. Deportivo. Motor muy poderoso. De algn color que te guste.
Pgina 75 de 152
Ahora supongamos que ha pasado algn tiempo, y he venido a entregar el vehculo, aquel que esperas con muchas ansias y medida que ves que lo van bajando del camin estas cada vez ms contento cuando descubres que tiene unas llantas preciosas, que el color es tal y cual lo imaginaste, en la cola del vehculo pone un numero que dice 3.5 haciendo referencia la cilindradas del motor, al fin el auto esta en el suelo y el encargado de construirlo hace un gestos de amabilidad para que te acerques a recoger tus llaves y entres al vehculo, una vez adentro sin mirar ms pones la llave, haces contacto y escuchas como ruge el motor mientras te imaginas la expresin de tus amigos cuando te vean en el, ha llegado el momento, estiras las piernas para acelerar y descubres que no hay pedales, pensando que a lo mejor es acelerador esta en el manubrio comienzas a palpar la parte de atrs pero no encuentras nada, a tu derecha notas la ausencia de una caja de cambios, de aire acondicionado, de la traccin de las ruedas ni hablar, apenas el motor esta conectado al sistema de arranque, no hay tacmetro, no hay luces y as sigue, muy enojado bajas del vehculo y encaras al encargado, el cual mira el documento en el que especificaste lo que necesitabas, hace una revisin y te das cuenta que todo lo que pediste esta ah y que en realidad reclamas por lo que no hay que jams pediste, Quin es el culpable? El mecnico? T por no especificar bien lo que necesitas? Y la respuesta es ambos, el problema que aqu hubo es de comunicacin, a pesar de que da la sensacin es que es ms culpable el mecnico es por que tu sabes los comportamientos que un vehculo debiese tener, pero, que pasa cuando tratamos de construir algo que el cliente ni el constructor conocen? Aqu es cuando el asunto se pone difcil, en el anlisis de requerimientos
Pgina 76 de 152
esta situacin se da mucho ms habitual de lo que perece, la razn de ello se debe a que la persona que debe construir el software debe hacerlo de forma tal que se adecue a las necesidades de una empresa que la cual no conoce sus procesos, pero por otra parte el cliente conoce bien su empresa, pero jams ha hecho software. Mucho antes de siquiera pensar en como construir un software encontraremos la etapa de captura de requerimientos, esta etapa es de vital importancia para lo que viene luego, ya que, es durante esta etapa en la que obtenemos cliente, los en requerimientos la que (las necesidades) desde nuestro mediante
conversaciones, formularios, encuestas u otras formas obtenemos la informacin sobre los procesos del negocio que desean el apoyo de software, es muy comn que se confundan la palabra requisito y requerimiento, sin embargo en informtica no debieses ser utilizadas de forma indistinta, los requerimientos son la palabra ms comn usada por las personas y viene de la necesidad de algo, por lo tanto, la palabra correcta para definir las necesidades que tiene tu clientes debe ser requerimiento, otra forma de explicar lo mismo es la ubicar la captura de requerimiento en el tiempo, con esto nos referimos a que en algn lugar existe una persona con un problema o necesidad de mejora para la cual necesita una solucin que pasa principalmente por un conjunto de herramientas informticas que apoye uno o ms de sus procesos, cuando el profesional encargado de suplir esa necesidad se acerca a conocer los procesos que la empresa realiza para las cuales necesita un apoyo informtico y lo que realmente la empresa necesita de ellos para mejorar o solucionar una carencia estamos hablando entonces de requerimientos.
Pgina 77 de 152
Pressman dice
Ingeniera de Requerimientos ayuda a los
ingenieros de software a entender mejor el problema en cuya solucin trabajarn. Incluye el conjunto de tareas que conducen a comprender cul ser el impacto del software sobre el negocio, qu es lo que el cliente quiere y cmo interactuarn los usuarios finales con el software. El proceso de toma de requerimiento, puede ser una tarea difcil y que requiere trabajo y una habilidad para tratar y comprender a las personas con las que se entrevista, muchas personas siempre consideraron al informtico como un ermitao que vive frente a un computador, pero se equivocan, por que son ellos los encargados de extraer de sus clientes las necesidades que permiten el desarrollo de una solucin, por lo general durante la toma de requerimientos descubrirs que los propios usuarios no saben lo que quieren, adicional a lo anterior la tarea se vuelve algo mas compleja debido a que los usuarios no tienen una visin como conjunto, lo que provocar que escuchars versiones distintas de una misma necesidad dependiendo a quien se entreviste, a lo anterior, como si fuera poco, debes agregar que muchas veces los requerimientos no son detallados correctamente, lo que suele conducir a error y a incongruencias entre los clientes , es por esto, el encargado de la toma de requerimiento debe tener una habilidad que le permita mediar con ellos, ya que descubrir con el tiempo que una misma necesidad es vista de distintos puntos de vista segn a quien se entrevista y en muchos casos descubrirs que ni ellos tienen claridad de lo que realmente desean. Lo que debemos obtener de una buena toma de requerimientos es enumerarlos, comprender el contexto en el que se encuentran.
Pgina 78 de 152
Para lidiar con esto hoy aprenderemos algunas tcnicas de extraccin de requerimientos desde el cliente, las cuales son: entrevista, encuesta y observacin directa, ms adelante en asignaturas posteriores vers metodologas ms elaboradas sobre la captura de requerimientos, las cuales consisten en un conjunto de tcnicas, sin embargo en este semestre veremos tres de las formas mas naturales de comunicacin existentes para extraer informacin.
Entrevista.
La entrevista es posiblemente la forma ms natural y rpida de comunicacin con una persona, en informtica la entrevista debe ir enfocada a aquellas personas que ms conocen sobre los procesos de la organizacin y a las personas que utilizarn el sistema, estas entrevistas pueden ser individuales o grupales y se recomienda hacerlas cada cierto tiempo, ya que vers que los requerimientos van a ir cambiando producto de la falta de entendimiento que los clientes suelen tener sobre sus propios procesos.
Encuesta.
Las encuestas son documentos que tienen un conjunto de preguntas relevantes del sistema que se desea construir, de esta forma podemos obtener informacin ms precisa sobre los puntos sobre los cuales necesitamos una respuesta cerrada, las preguntas se hacen de forma verbal al encuestado, siendo el mismo encargado de marcar la respuesta segn lo que el encuestado haya dado como respuestas, las encuestas puede llevar preguntas abiertas o de seleccin mltiple, en la que los encuestados debern seleccionar una alternativa, esta tcnica es buena cuando lo que
Pgina 79 de 152
deseas es obtener informacin puntual desde un grupo grande de personas que no pueden reunirse ya sea por horario o por limitaciones de espacio.
Observacin directa.
Esta tcnica consiste en que el encargado de la toma de requerimientos observa las personas mientras realizan su trabajo, de esta forma se conoce cules son los procedimientos que se realizan, quines son los encargados de hacerlos y cul es el orden en el que se ejecuta.
Definicin de actividades.
Una vez los requerimientos han sido extrados del cliente pasaremos a una nueva etapa en la cual tomaremos cada uno de los procesos del cliente y lo dividiremos en actividades ms pequeas, las cuales juntas y en algn orden en particular dan como resultado alguna accin que deseamos convertir en software ms adelante, por ejemplo, si existe un proceso en el que los clientes compran utilizando el mtodo tradicional y esto lo quieres llevar a un servicio de pago por internet, debes determinar todas las actividades que hay que realizar para lograrlo, en este caso las actividades a realizar comienzan por construir una pgina web con un catalogo de productos donde el usuario pueda especificar el o los productos que quiera comprar, luego una interfaz de pago que permita ingresar el nmero de la tarjeta bancaria con la que se desea realizar dicho pago, la informacin ingresada deber enviarse al banco que corresponde, slo si esta habilitada y el monto disponible para compra supera el valor del producto, entonces se genera la venta, esta venta es registrada por el
Pgina 80 de 152
software y en ella incluye los datos del comprador y algunos datos de la venta, como la fecha, el total y el detalle, el cual consiste en una lista de los productos que compr. Adicionalmente a lo anterior, para que un cliente pueda comprar en una pgina web que permita navegar por los productos, seleccionarlos y comprarlos, ser necesario unos cuantos pasos previos, ya que dichos productos deben ser agregados a la pgina antes de que el cliente navegue por ellos, entonces, alguien debe ingresar la informacin de los productos, subir sus fotos, establecer el valor y agregarlos a la categora que corresponde, adicionalmente especificar algn tipo de descuento si lo hubiese. Si hacemos un mejor anlisis de la situacin notars que hace un momento acordamos que cuando un cliente realiza una compra la informacin que almacenaremos incluir los datos del comprador, es por ello que antes de la compra hay una actividad que corresponde al registro del usuario, en la cual se almacenan los datos del mismo. Es muy probable que la necesidad de transformar en software este flujo tenga principalmente dos objetivos, el primero, una mejora en la forma en la que las personas obtienen los productos, cambiando de la tradicional, en la que el cliente deba salir de su hogar para adquirir los productos a una cmoda, rpida y gil forma de comprar sin salir de su hogar, la segunda razn es que al tener la informacin de las ventas la organizacin podr llevar de mejor forma su contabilidad y podr tomar mejores decisiones basadas en los reportes que el sistema entregar, como por ejemplo, los productos ms vendidos, las fechas de mayor compra, lo que alertar aquellas temporadas en las que hay que tener una
Pgina 81 de 152
mayor
cantidad
de
stock
de
productos,
estos
informes
se
generarn de forma automtica por el sistema en respuesta a una solicitud de quien los desee ver, todo esto a cambio de lo que antes deben haber sido engorrosas planillas o largas sumas y restas realizadas en papel. A pesar de que pereciera que la lista de actividades para un portal de ventas esta completa, ms adelante con un mejor anlisis veremos que lo aqu descrito no es slo una pequea parte, que por ahora obviaremos.
Relacin entre las actividades y los actores.

Del anlisis anterior realizado se obtiene una lista de actividades que pueden realizarse para llevar a cabo los procesos de la empresa, el paso siguiente una vez identificados dichos procesos es determinar las responsabilidades, o dicho de otra forma quin o quines son los encargados de cada uno de ellos, a cada elemento (usualmente personas) que interacten con nuestro software lo llamaremos un actor, por ejemplo y siguiendo con el caso anterior la persona encargada de la compra a travs de internet es el actor llamado cliente, la carga de productos en el sistema ser realizada por el actor denominado encargado de ventas y los reportes que permitirn tomar decisiones a una persona con un rol ms gerencial, con esto no slo logamos identificar lo que los actores deben hacer, sino que tambin lo que no deben hacer.
Pgina 82 de 152
Anlisis bsico de los requerimientos para la realizacin de un listado de actividades.

En los procesos de anlisis de requerimientos siempre se determinan necesidades mltiples para las organizaciones que se estn estudiando. Es necesario por lo tanto que determines un mbito de accin para tu proyecto, y de esta forma dar una solucin acotada y precisa. Lo primero que debes tener en cuenta es que las organizaciones siempre tienen una razn de ser y esta razn de ser determina las actividades que la organizacin realiza. Por un tema de complejidad de las organizaciones, poseen diferentes procesos que dan soporte a la realizacin del quehacer de la organizacin y adicionalmente otra serie de actividades que si bien no son parte del quehacer de la organizacin, estas sirven de soporte a estos procesos principales. Por ejemplo, el propsito de la panadera es hacer y vender pan (proceso principal), pero adicionalmente necesita realizar proceso tales como hacer aseo, comprar materiales, contratar personal, etc. Como te puedes dar cuenta existe una gran cantidad de operaciones que pueden ser realizadas como soporte de las actividades principales, y mientras ms compleja sea la organizacin, ms complejas sern las actividades de soporte y ms especficas. Cuando ests analizando requerimientos, es importante que puedas agrupar las actividades que ests analizando. Este agrupamiento de actividades permitir que analices los procesos y las necesidades de la organizacin de forma mucho ms eficiente (aplicando la teora de sistemas). Una vez que hayas agrupado los
Pgina 83 de 152
requerimientos en relacin a su funcionalidad es necesario que determines los grados de importancia de los requisitos identificados. El grado de importancia esta asociado a los procesos que realiza la organizacin como parte de su quehacer. Debes considerar que para cualquier organizacin los requerimientos principales a considerar son aquellos que tienen que ver con el quehacer de la organizacin, es decir con los procesos que hacen que la organizacin funcione. Con todos estos antecedentes a la mano es posible ahora realizar un listado de los principales requerimientos y ordenarlos en funcin de las principales necesidades de la organizacin. Este listado servir entonces para realizar un listado de actividades que deben ser realizadas para poder alcanzar los requerimientos. Este listado de actividades te dar la pauta para poder definir las actividades importantes en el desarrollo de tu proyecto, y en que cosas debes fijar tu atencin al momento de planificar y desarrollar el proyecto.
Pgina 84 de 152
Diagrama de flujo de datos (Agile Unified Process).

Los diagramas de flujo de datos (DFD) fueron herramientas muy utilizadas por la metodologa estructurada como una forma de representar los flujos de datos entre las entidades externas y el sistema que se estaba analizando. Adicionalmente a este anlisis los DFD permiten mostrar el flujo de datos entre cada uno de los procesos que componen el sistema y su almacenamiento lgico. Para construir estos diagramas existen cuatro elementos
principales: Los rectngulos representan entidades externas, las cuales son orgenes o destinos de los datos, es decir son todas aquellas cosas, personas o sistemas que aportan o reciben datos como resultado del proceso.
Pgina 85 de 152
Los rectngulos redondeados representan los procesos, los cuales toman los datos de entrada para hacer algo (un proceso) y generan una salida.
Las flechas representan los flujos de datos, los cuales viajan entre las entidades y los procesos y entre los procesos y los almacenes de datos.
Finalmente un rectngulo con el lado izquierdo abierto representa un almacn de datos, el cual puede ser un archivo, un documento en papel, un archivador o cualquier cosa que pueda almacenar datos de un proceso que nos interese.
El proceso de generacin de estos diagramas consiste en definir un escenario para con esa informacin definir las entidades y los procesos que se realizan. Una vez que hayas definido el escenario comienzas a dibujar las entidades en el lado izquierdo del diagrama, a continuacin defines los procesos que se realizan en el
Pgina 86 de 152
sistema y unes a estas entidades con los procesos. Recuerda que esta unin entre procesos y entidades no se realiza al azar sino que es fruto de un proceso de anlisis en el cual se identifica si la entidad entrega o recibe datos de un proceso en particular, para muestra el siguiente ejemplo.
Fjate que en el contexto del sistema de compra en lnea, el proceso de validacin de usuario est relacionado con la entidad usuario que es la que enva los datos y estos se buscan en el almacn de datos del usuario, estos datos son analizados por el proceso de validacin de datos y con esto se generan los permisos de acceso del usuario de esta misma forma se van a analizando y uniendo las entidades con los procesos, los procesos con otros procesos, los almacenes con los procesos, la siguiente tabla muestra la relacin existente entre cada uno de los elementos del diagrama mediante los flujos de datos que son los conectores.
Entidad Proceso Almacn Entidad Proceso Almacn NO SI NO SI SI SI NO SI NO
Pgina 87 de 152
Utilizando esta tabla anterior, podemos definir algunos ejemplos de cosas que jams podras hacer:
En el caso anterior, si bien en la vida real el profesor y el alumno se relacionan, en el caso del uso de un sistema ellos nunca conversan pues ambos conversan por separado con el sistema y finalmente eso es lo que nos interesa reflejar en este anlisis.
En el ejemplo anterior, las entidades nunca pueden enviar un flujo de datos directamente al almacn, pues siempre los datos al menos pasan por un proceso de validacin antes de ser guardados en un almacn de datos.
Pgina 88 de 152
Como puedes ver los almacenes de datos tampoco se pueden relacionar, pues al ser slo repositorios, ellos no pueden ejecutar ninguna accin, slo almacenan datos. Adicionalmente a lo visto existen algunas otras reglas que debes observar respecto a los DFD: a) Todos los procesos deben tener al menos un flujo de entrada y uno de salida. Estos son ejemplos vlidos.
Pgina 89 de 152
Estos son ejemplos no vlidos.
b) Todos los procesos deben modificar los datos de entrada produciendo nuevas formas de datos de salida. Algunos procesos comunes son validaciones, ordenamientos, bsquedas, etc. c) Cada uno de los almacenes de datos debe tener al menos un flujo de datos, ya sea de entrada, salida o actualizacin de datos. d) Cada una de las entidades externas debe estar relacionada con al menos un flujo de datos. e) Cada flujo de datos debe estar asociado al menos a un proceso. Si bien estos diagramas son una buena alternativa para representar la relacin entre las entidades, los procesos y los almacenes de datos utilizando para esto los flujos de datos, tambin es necesario mantener el control respecto a la complejidad de los procesos representados. Utilizando conceptos de teora de sistemas, trata siempre de mantener los diagramas lo ms simple posibles, si el diagrama no es suficiente, lo puedes documentar, es decir puedes definir por escrito los procesos y el trabajo que cada uno de los componentes realiza en el contexto del problema.
Pgina 90 de 152
Diagrama de procesos (BPMN 2.0)

Cuando ests trabajando, muchas veces tendrs que realizar anlisis de sistemas que son muy complejos. Una herramienta que te permite representar grficamente los sistemas es utilizando un diagrama que se llama BPMN, Business Process Model and Notation (BPMN) es decir Modelo de Procesos de Negocio y Notacin. Esta es una notacin grfica que describe los pasos que se realizan en un proceso. Esta notacin ha sido especialmente diseada para actividades. BPD (Bussines Process Diagram) o diagrama de procesos de negocio es un diagrama diseado para representar grficamente la secuencia de todas las actividades que ocurren durante un proceso, basado en la tcnica de diagrama de flujo incluye adems toda la informacin que se considera necesaria para el anlisis. BPD es un diagrama diseado para ser usado por los coordinar la secuencia de los procesos y los mensajes que fluyen entre los participantes de las diferentes
analistas,
quienes
disean,
controlan
y gestionan procesos.
Dentro de un Diagrama de Procesos de Negocio BPD se utiliza un conjunto de elementos grficos, agrupados en categoras, que permite el fcil desarrollo de diagramas simples y de fcil comprensin. El modelado de proceso es la captura de una secuencia de actividades de negocio, y de la informacin de soporte. Los procesos de negocio describen la manera cmo una empresa alcanza sus objetivos. Es decir ac lo que analizamos y tratamos
Pgina 91 de 152
de graficar son los procesos de negocio. Recuerda que los procesos de negocio son todas las actividades que realiza una organizacin y que tienen que ver con la gestin de los datos para obtener un resultado. Existen diferentes niveles del proceso de modelado: Mapas de proceso. Son diagramas de flujo simple de las actividades. Descripciones de proceso. Conforman una extensin del anterior, y manejan informacin adicional pero no suficiente actual. Modelos de proceso. Son diagramas de flujo extendido con suficiente informacin para que el proceso pueda ser analizado, simulado, y/o ejecutado para definir completamente el funcionamiento
Para realizar los diagramas, BPMN clasifica los elementos de la siguiente forma: Objetos de flujo, que son elementos que permiten definir cosas que suceden durante el proceso de negocio. De esta forma tenemos los eventos de inicio, los eventos intermedios y los eventos de fin. Los eventos de inicio se grafican de la siguiente forma:
Representa un evento de inicio que no tiene condicin o requisito previo.

Pgina 92 de 152
Un proceso o una aplicacin que da inicio a un proceso mediante un mensaje. Representa una fecha o una hora en la cual se iniciar el proceso o tarea.
Los eventos intermedios forman parte del flujo del proceso en la secuencia normal del mismo. Pueden o no anteceder a una actividad o subproceso. Representa el envo o la recepcin de un mensaje desde otros procesos. Representa un mecanismo de retraso dentro del proceso. Puede estar definido como una fecha o unidad de tiempo. Permite conectar dos secciones de un proceso para graficar situaciones repetitivas o para evitar lneas de secuencia de flujo largas o cruzadas que puedan ser muy complejas.
Los eventos de fin se representan de la siguiente forma:
Representa un evento de fin que no tiene condicin o requisito previo. Representa un evento de fin que termina con un mensaje.
Pgina 93 de 152
Las actividades son la representacin de un trabajo que se realiza en el sistema analizado. Se representa con un rectngulo redondeado. Una actividad puede ser atmica o compuesta. Los tipos de actividades son: Una tarea es una actividad atmica que est incluida dentro de un proceso. Se habla de tarea cuando el trabajo que representa en el proceso no puede descomponerse en un nivel mayor de detalle.
Un
subproceso de
es
un
conjunto
de
actividades
incluidas
dentro
un proceso. Puede descomponerse en diferentes
niveles de detalle denominadas tareas. Se representa con un smbolo de suma en la parte central inferior de la figura. A continuacin se presentan los tipos de subprocesos: Una tarea contrada o colapsada muestra una tarea cuyos subprocesos no pueden ser visualizados. El signo + indica que la actividad en un subproceso y que tiene el nivel ms bajo de detalle.
Pgina 94 de 152
Un proceso expandido muestra los subprocesos, es decir est en el mismo nivel de detalle del proceso y tiene un evento de inicio y fin del proceso.
Las compuertas o gateway se representa con un diamante y representa una divergencia o convergencia de la secuencia de flujo. Estas siempre determinan bifurcaciones, combinaciones o fusiones del proceso.
La compuerta exclusiva puede ser de dos tipos convergente o divergente, la divergente son decisiones que toma el usuario del sistema para saber que camino seguir, las convergentes sincronizan los caminos salientes al cumplir una condicin del negocio. La compuerta compleja representa un punto donde aparecen varios caminos y slo uno de ellos es vlido.
Pgina 95 de 152
La compuesta paralela indica un punto en el proceso donde pueden ser llevadas a cabo varias actividades en paralelo.
Los objetos conectores conectan los objetos de flujo de un proceso, y definen el orden de ejecucin de las actividades. Los tipos de conectores son: Conector de secuencia, muestra el orden de los eventos, realizan dentro del proceso. Conector de mensaje, indica el flujo de mensaje entra las distintas entidades de los procesos. Conector de asociacin, permite asociar actividades y decisiones que se
diferentes artefactos con objetos de flujo.
Pgina 96 de 152
Los swimlanes o canales son un mecanismo empleado para organizar actividades en categoras separadas visualmente, el fin de ilustrar diferentes capacidades funcionales responsabilidades. con o
Representa a los actores externos o internos con los cuales interacta un proceso, contiene un conjunto de actividades asociadas a su rol.
Los artefactos son objetos grficos que proveen informacin adicional de los elementos dentro de un proceso, sin afectar el flujo del proceso. Los grupos se utilizan para agrupar un conjunto de actividades, la agrupacin se puede realizar con propsitos de documentacin o de anlisis.
Las anotaciones, son un mecanismo para entregar informacin adicional.
Pgina 97 de 152
Ac vemos un ejemplo de un proceso de compra y venta de productos con el posterior despacho de este producto por parte del vendedor. Fjate que la representacin de los procesos se hace cada una en su propio canal o swimline para separar las tareas que estn asociadas a cada uno de los roles en el proceso.
Pgina 98 de 152
Pgina 99 de 152
Diagrama de casos de uso.

El diagrama de casos de uso, es el primer diagrama que aprenders a crear en profundidad, este diagrama te permitir analizar los problemas que vayas estudiando de una manera grfica que es mucho ms cercana a la realidad que conoces. Este diagrama permite a los analistas tener una visin primitiva respecto de cmo funciona o debera funcionar el sistema que se est analizando y ver cmo cada uno de los entes que participan en el proceso van a interactuar con este sistema. Recuerda que cuando hablamos de sistema, estamos hablando de un conjunto de objetos que se interrelacionan con el fin de lograr un propsito comn, por lo tanto los sistemas que analicemos pueden ser de cualquier tipo, pero por el perfil de nuestra carrera tenemos que acercarnos a los sistemas de informacin. Recuerda que los sistemas de informacin son un conjunto de normas y procedimiento que definen el cundo, dnde y por qu se realizan las cosas, un conjunto de personas que realizan las acciones y las corrigen y un conjunto de hardware y software que permiten automatizar los procesos que sean montonos o que lleven mucho tiempo y que generalmente estn asociados a la gestin de los datos. Por lo tanto siempre recuerda que un sistema de informacin no es slo software o slo hardware es un todo mucho ms complejo. Tambin debes tener la seguridad que nunca se construye el uno sin el otro (o al menos no se recomienda) pues estn relacionados y el uno sin el otro, provoca que el sistema quede incompleto.
Pgina 100 de 152

Te preguntars Y cmo hago todo esto?, pues bien, la respuesta por un lado es simple, pues lo nico que debes hacer es pensar y por otro compleja dado que hay que pensar y mucho, bsicamente debes aprender a resolver problemas como si fueras un detective, es decir, recopilar informacin asociada a los hechos, luego proponer soluciones, reconstruir procesos o acciones que ocurrieron y luego establecer la forma de corregir los errores. Para esto tienes dos aliados que son indispensables, el hardware y el software. Como ya sabes que hay que pensar debes hacer que tu cerebro te obedezca e intente resolver problemas por ti. Para esto lo primero que debes hacer es recopilar toda la informacin respecto a como funcionan los sistemas que ests analizando y luego generar un diagrama que te ayude a ver si lo que pensaste se ajusta o no a la realidad. El diagrama de casos de uso cumple esta funcin, ahora dado que se puede malinterpretar pues es slo una representacin grfica de la realidad de un proceso, es necesario documentar este diagrama, para aclarar algunos conceptos que puedan quedar en el aire. Es importante comprender que este es un proceso iterativo e incremental que fue pensado para ser de esta forma ,es decir para que puedas analizar en como solucionar las cosas, debes tener en cuenta es que no es recomendable trabajar solo pues dos o ms cerebros piensan ms que uno, adicionalmente si no puedes verbalizar una idea o explicarla en palabras o texto, significa que tu cerebro an no lo puede resolver del todo y debes tratar volver a analizar. Este proceso es muy entretenido pues implica el investigar y tratar de dar soluciones a problemas cotidianos
Pgina 101 de 152
aplicando tecnologa y todo el conocimiento que vayas adquiriendo durante tu carrera. Bsicamente los sistemas de informacin se encargan de realizar cuatro procesos: Captura de datos. Almacenamiento. Procesamiento. Entregar de resultados. Todos los sistemas de informacin realizan bsicamente estos cuatro procesos desde el procesador de texto hasta los video juegos pasando por software empresarial y pginas web. Bsicamente lo que hacemos es dar soluciones basndonos en una combinacin de hardware, software y mucho anlisis respecto a los procesos que realiza la organizacin que estamos estudiando para realizar sus tareas, todo ngulo del almacenamiento, procesamiento y entrega de resultados del proceso. A lo mejor te estas haciendo algunas preguntas del tipo Para que almacenar datos?, Quin define los procesos de la organizacin?, Es lo mismo un dato que informacin?, El fin del mundo ser el 2012?, Cmo es posible que los vampiros que son seres de la noche puedan caminar de da en la pelcula Crepsculo?, estas y otras preguntas las responderemos durante el desarrollo de este y los siguientes captulos. La comunicacin que se establece entre las personas siempre es compleja, una persona que emite una frase o comentario puede ser mal interpretada por el receptor pues, su interpretacin de lo que est escuchando depende de muchos factores. Como nuestro
Pgina 102 de 152
objetivo al construir diagramas es poder transformarlos en software o en una solucin informtica, no nos podemos dar el lujo de que esto suceda. El diagrama de casos de uso, nos facilita mucho la tarea de mostrar a la contraparte mediante un dibujo lo que hemos entendido y de contener errores es fcil de corregir. Las organizaciones requieren gestionar la informacin de sus procesos para poder tomar decisiones respecto a como estn haciendo las cosas para continuar hacindolo bien o para mejorar lo que estn haciendo mal. Por ejemplo, si fabricamos 3000 litros de helados en marzo y vendemos pocos litros en invierno lo ms probable es que el prximo ao ajustemos la cuota de produccin en funcin de las ventas del ao anterior, para no tener que botar 2999 litros como la temporada anterior. Este tipo de decisiones estn asociadas a todos los procesos
Componentes del diagrama de casos de uso.

Para poder realizar de forma correcta un diagrama de casos de uso, debes saber que este est compuesto por tres elementos: los actores, los casos de uso y las relaciones. Cada uno de estos elementos permite que tengas una visin de los componentes de un sistema (personas, reglas y procedimientos) y cmo estos se relacionan. Recuerda que un diagrama de casos de uso se circunscribe a un momento en el tiempo, es decir que lo que nos muestra es la relacin entre los procesos y las personas en un momento especfico o como se suele decir, en un escenario particular.
Pgina 103 de 152
En los casos de uso, el escenario se define como un momento especfico en la vida de un proceso que esta siendo analizado, esta separacin se hace para poder simplificar el anlisis de los procesos. Por ejemplo, cuando compras un producto en una multitienda, se producen muchos procesos de traspaso de informacin, por ejemplo cuando vas a comprar un producto el proceso comienza cuando tu buscas ropa por modelo, marca, color, o precio, en funcin de estos parmetros (todos, una combinacin de ellos o slo uno), t seleccionas un artculo, te acercas al vendedor, vas a la caja y cancelas, ya sea con tarjeta de crdito, con efectivo o con cheque y luego de la impresin de los comprobantes de la venta, te puedes llevar el artculo. Si te fijas este es un escenario del proceso, pero Qu pasa si el artculo es muy pesado como un refrigerador y no te lo puedes llevar y este debe ser enviado a tu casa?, Qu sucede si debes devolver el artculo porque no te gust, o porque presenta fallas?, si te fijas cada una de estas situaciones, son parte del proceso de venta de un producto pero son escenarios diferentes, es decir situaciones que van ms all del proceso normal y conocido de una venta. Por eso cada vez que hacemos un diagrama de casos de uso es muy importante que definamos el escenario en el cual se va a desarrollar. Este escenario tiene como misin fundamental el circunscribir el problema y definir los factores que puedan afectar el comportamiento del sistema, piensa que el comportamiento del sistema para un vendedor que realiza una venta es distinto que para un vendedor que desea procesar una devolucin o un cambio, por lo tanto es necesario establecer el modelo en funcin del escenario especfico que se est analizando.
Pgina 104 de 152

Vamos a ver en detalle los componentes del diagrama de casos de uso.
Actores.
Los actores se definen en un diagrama de casos de uso como entes externos que interactan con funciones del sistema. De esta forma un actor no necesariamente es una persona, puede ser una entidad o una idea. Lo que sucede es que cuando las organizaciones son complejas, el software que da soporte a la organizacin tambin lo es, y ya no hablamos de personas usando el software sino que de departamentos (que finalmente son un conjunto de personas), pero que no tienen un rostro visible. En estos casos el actor no es una persona, sino que una representacin de varias personas o de ninguna en particular. Los actores se representan como una persona dibujada con palitos, como cuando ramos pequeos y an no aprendamos a dibujar.
Pgina 105 de 152

Fjate que el actor posee un nombre que define su rol, es decir el papel que le corresponde realizar en ese escenario especfico, este rol del usuario esta definido por el escenario, as en un sistema llamado casa, probablemente desempees alguno de los siguientes roles: hermano(a), pololo(a), hijo(a), esposo(a), papa o mam, etc., fjate que es posible que t cumplas ms de un rol, por ejemplo, hermana, polola, mam dentro del mismo sistema, pero las acciones que realizas y como las realizas son distintas en funcin del rol que te toca representar en ese escenario en particular. Por ejemplo supongamos que sabes cocinar y al mismo tiempo eres hijo de tus padres, cuando ests en la cocina, estableces un rol de usuario de la cocina, cocinero y por lo tanto vas a interactuar como usuario cocinero con el sistema cocina, el cual se encuentra dentro del sistema casa, cuando ya serviste la comida, entonces interactas con tus padres de forma distinta, pues tu rol de cocinero cambi por el rol de hijo.
Casos de uso.
Un caso de uso se define como una funcin que tiene o debe tener el sistema y que es utilizada por un usuario. De esta forma los casos de uso se transforman en las acciones que debe implementar el sistema, recuerda que en el anlisis de casos de uso, la vista desde la cual analizamos el problema es como usuarios del sistema que deben cumplir una serie de tareas que van asociadas a nuestro rol en un escenario especfico. De esta forma si analizamos las tareas que debe realizar un vendedor para poder vender algn artculo en una multitienda (fjate que el problema se circunscribe a ese escenario en particular), este debe poder consultar por los precios de los productos, vender uno o ms
Pgina 106 de 152
productos a un cliente, consultar el total de la venta, imprimir el comprobante de la venta, recibir el pago, y dar vuelto si corresponde, recuerda que este es una aproximacin inicial al problema por lo que las etapas pueden cambiar, as que si descubres ms, sintete libre de agregarlas . Una vez que determines las tareas que debe hacer el actor, estas deben ser analizadas pues a veces este anlisis inicial puede llevar a una confusin. Realicemos el siguiente anlisis, supongamos que tenemos la siguiente definicin de procesos: Necesitamos representar un sistema que permita a los mdicos de una clnica dental, definir sus horarios de atencin y a los clientes de la clnica el registrarse y el solicitar hora a travs de una pgina web Pese a que esta es una definicin de procesos extremadamente simple, ya podemos definir algunas caractersticas iniciales para el modelo y basndonos en estas caractersticas iniciales podemos con posterioridad hacernos algunas preguntas respecto a como funcionan las cosas y tendremos la posibilidad de mejorar el modelo. Lo primero es definir a los actores (personas o sistemas u organizaciones) que participan del proceso. De esta forma identificamos al menos dos, mdico y paciente.
Pgina 107 de 152

Una vez que identificamos a los actores, lo que debemos hacer es definir los casos de uso, es decir a las acciones que estos actores van a realizar para lograr el objetivo propuesto. Para el ejemplo anterior vemos que podemos detectar ciertas acciones o comportamientos que debe realizar cada uno de los actores como usuarios del sistema, as podemos dividir las acciones que realiza cada uno de la siguiente forma: Mdico: Define su horario de atencin Usuario: Registrarse, solicitar hora. Si te fijas la definicin de los casos de uso define el qu, pero no el cmo, pues an no interesa, recuerda que estamos primero definiendo qu es lo que hay que hacer, concntrate en este punto, pues si bien la tecnologa es importante antes de identificar y solucionar el problema, hay que saber qu es lo que necesitamos
Pgina 108 de 152
que el sistema haga. Un punto importantsimo que debes analizar son los datos que necesita el proceso para poder realizarse completamente o de otra forma tratar de definir los datos que la organizacin necesita registrar como parte del proceso para la toma de decisiones, por lo tanto el diagrama final quedara de la siguiente forma:
Pgina 109 de 152

Relaciones.
Las relaciones permiten establecer la forma en que los actores y los casos de uso se comunican y adicionalmente muestra la relacin existente entre los casos de uso. Existen cuatro tipos de relaciones en los diagramas de casos de uso, asociacin de comunicacin, extensin, inclusin y generalizacin. La relacin de asociacin de comunicacin se establece entre el actor y el caso de uso y nos permite definir en el contexto del diagrama que el actor est utilizando que el caso de uso. Recuerda que cada uno de los actores que aparezca en el diagrama debe estar relacionado al menos con un caso de uso, pues la relacin entre el actor y el caso de uso nos indica qu funcionalidad del sistema ser utilizada por cada uno de los actores que estn representados en ese escenario particular. En la relacin de inclusin, la que graficamos con una lnea segmentada que une dos casos de uso ms una flecha que indica la direccin de la relacin, estamos representando dos casos de uso que son complementarios. En la relacin de inclusin, un caso de uso necesita de otro caso de uso para poder realizar una operacin en particular. Recuerda que en la inclusin el resultado del caso de uso incluido afecta el caso de uso que incluye por lo tanto estn ntimamente relacionados los resultados de ambos. Este tipo de relaciones se grafica utilizando la palabra <<include>> sobre la lnea que muestra la relacin.
Pgina 110 de 152

En la imagen anterior fjate que el caso de uso denominado login, incluye su funcionalidad al caso de uso buscar usuario, que tambin es utilizado por el caso de uso registro para evitar que el usuario se registre dos veces. En este ejemplo ambos casos de uso incluyen su funcionalidad, y as la ejecucin o no del caso de uso se relaciona con el resultado obtenido por el caso de uso incluido, es decir, el caso de uso login y el caso de uso registro segundo caso de uso depende el resultado del primero. Cuando se trata de relaciones de extensin las cuales se grafican con la palabra <<extend>>, tambin se puede analizar la relacin como si los dos casos de uso fueran slo uno. Pero una de las diferencias bsicas es que hay situaciones en que el caso de uso de extensin no es indispensable que ocurra, y cuando lo hace ofrece un valor extra el cual extiende al objetivo original del caso de uso base, mientras que en el <<include>> es necesario que ocurra el caso incluido slo para satisfacer el objetivo del caso de uso base. Un ejemplo de lo anterior lo podemos analizar en el siguiente ejemplo:
Pgina 111 de 152
no
estn completos sin la utilizacin de buscar usuario, pues de este
En el ejemplo anterior el caso de uso servir caf extiende hacia el caso de uso agregar azcar, fjate que para servir caf no es siempre necesario el agregar azcar, pero cuando se hace, le agrega un valor al caso de uso anterior, sin que exista la dependencia del uno con el otro. Otro tipo de relacin que se establece en los casos de uso es la relacin de generalizacin, la cual se dibuja en el diagrama mediante una flecha con sentido, la punta de flecha a diferencia de los otros tipos de relacin a parte se rellena. La generalizacin est asociada al concepto de especializacin, en esta situacin un caso de uso puede dar origen a una forma especializada de realizar una accin para muestra un ejemplo:
En el diagrama anterior el proceso de pago en el sistema se puede realizar de dos formas, con la tarjeta de la multitienda o en efectivo. Si te fijas cada uno de estos procesos en s es un pago,
Pgina 112 de 152
por lo tanto, como ambos son una forma de pagar, podemos definir que la generalizacin del proceso es el pago el cual hereda su comportamiento a los otros casos de uso.
Identificacin del contexto en el que participan los actores.

Uno de los puntos principales para poder realizar un buen anlisis de la situacin actual, es poder determinar el contexto en el cual participan los actores. Es importante recalcar que muchas veces el contexto del problema es importante para determinar las acciones que se deben considerar a implementar como casos de uso. Para muestra el siguiente ejemplo: Un taller mecnico recibe vehculos para ser reparados, los clientes que desean atender su vehculo, primero deben registrar sus datos y los del vehculo, adicionalmente se registra el motivo de la visita en el taller y se procede a la evaluacin preliminar del vehculo. Junto con esto se hace una cotizacin basndose en la deteccin de los problemas que presenta el vehculo. Una vez se recibe esa cotizacin y el cliente da la autorizacin para ejecutar el trabajo, este es asignado a uno o ms tcnicos mecnicos los cuales proceden a la ejecucin del trabajo que est asociado a su especialidad (falla mecnica del motor, amortiguacin, sistema elctrico, mantencin peridica, etc.). El proceso se lleva cabo por cada uno de los tcnicos y es revisado por un jefe de taller el cual fiscaliza la correcta ejecucin del trabajo. Una vez que el trabajo completo es realizado, el vehculo es entregado al cliente..
Pgina 113 de 152
Identificacin de los roles.

El proceso de identificacin de los actores, pasa por determinar, personas o sistemas que entreguen informacin al sistema o reciban informacin de este (entes pasivos), ahora tanto el envo como la recepcin de la informacin est asociada al contexto del problema. Si te fijas en el enunciado del ejercicio anterior, nuestro contexto se remite a la recepcin del vehculo, el diagnstico del problema, la asignacin de tareas, el proceso de verificacin de la ejecucin de las tareas y la devolucin del vehculo reparado, jams se consider el cobro a los clientes ni el pago a los proveedores de insumos, ni el pago a los trabajadores, pues nuestro contexto es slo el de la definicin de procesos. Es posible que un anlisis posterior nos pudiera mostrar que existe relacin con otras reas pero siempre es necesario determinar las fronteras del sistema para realizar un anlisis acotado. Una vez que hayamos determinado el contexto del problema, es necesario determinar a los actores que pueden ser personas, entidades u otros sistemas que envan o reciben informacin desde y hacia el sistema. Recuerda que cuando hablamos de un sistema en el anlisis de casos de uso, estamos hablando de un conjunto de procesos que nos permiten lograr un resultado, en el caso anterior, reparar nuestro auto. Si analizamos la definicin de procesos del ejemplo podemos detectar algunos actores iniciales: Cliente: quien lleva el auto. Recepcionista: quien recibe y anota los datos del vehculo y el cliente.
Pgina 114 de 152
Tcnico mecnico: quien recibe la informacin de las tareas que debe realizar asociadas a un vehculo. Jefe de taller: Es el que revisa que el trabajo se haya realizado de forma correcta. Fjate que podemos hacer un anlisis un poco ms avanzado del proceso y podramos pensar en lo siguiente Qu pasa si el recepcionista, el tcnico y el jefe del taller son la misma persona?, la mejor respuesta a esto es que lo que estamos analizando son los roles que cumplen las personas al enfrentarse al uso del sistema, por lo tanto independiente de que sean 1 o 100 personas que estn interactuando con el sistema, lo que nos interesa es encontrar los roles que ellos estn ejerciendo. De esta forma podemos definir que cada uno de los roles tiene asociada una serie de tareas que debe realizar para poder aportar su parte en el proceso. Por ejemplo el tcnico mecnico le podran eventualmente corresponder realizar ms tareas que las definidas (recibe las tareas realizadas). Utilizando esta misma lnea de pensamiento, podemos identificar que existen varios actores asociados a un rol en particular, en este caso por ejemplo pueden existir varios clientes y varios mecnicos, adems si te fijas el cliente puede no slo traer el vehculo, sino que adems en otro contexto debe pagar por el servicio.
Definicin de los actores.

Una vez que defines los roles en la organizacin o en el sistema que estas analizando, es necesario que definamos los actores asociados a los roles que has encontrado, para esta identificacin, debes poner especial atencin en que pueden existir varios actores
Pgina 115 de 152
que estn asociados a un mismo rol, por ejemplo en el anlisis de nuestro caso, podramos encontrar a varios mecnicos, pero slo registramos uno. Ahora esto nos podra llevar a pensar que existen tanto usuarios como roles, pero no es as, pues es posible que un mismo actor pueda cumplir varios roles en funcin de su contexto. Esto puede parecer un poco complejo, pero no lo es, piensa que un rol est asociado a una tarea, mientas que un actor puede cumplir varios de estos roles en diferentes contextos, es decir que un mecnico puede realizar ms tareas que las detectadas en otro contexto. Ahora recuerda que si identificas a varios actores (alumnos de un curso, pasajeros de un bus, jugadores de un equipo), estos se consideran como uno solo, pues el rol que estn cumpliendo es el mismo para todos.
Definicin de los casos de uso.

Un caso de uso se entiende como una accin con la cual interacta un actor, esta accin es parte del sistema que estamos analizando. Esta accin se puede descomponer en un conjunto de acciones distintas, pero eso es parte de anlisis posteriores. Recuerda que los casos de uso pueden recibir informacin del actor o pueden entregar informacin al actor. En cada uno de esos casos el proceso siempre tiene un objetivo dentro del proceso general de la organizacin. Recuerda que cada uno de los casos de uso que logres identificar estn asociados al propsito del sistema que ests analizando. As, en nuestro ejemplo podemos identificar las acciones que debe realizar cada uno de los usuarios como muestran las siguientes imgenes.
Pgina 116 de 152

Definicin de los casos de uso.

Existen distintas formas para poder detectar los casos de uso para un sistema que estemos analizando, algunas de esas formas pueden ser una lluvia de ideas en la cual los participantes aporten ideas respecto a los casos de uso que cada uno identifica por separado al hacer el anlisis de la descripcin de los procesos. Otra forma de realizar este anlisis es utilizando a los actores que ya se han definido, analizando a cada uno de ellos podemos determinar los procesos en cuales ellos participan o inician. Adicionalmente
Pgina 117 de 152
nos podemos hacer una serie de preguntas relativas al sistema que estamos analizando. Cules son las tareas que debe realizar un actor? Qu informacin crea, guarda, modifica, destruye o lee el actor? Debe el actor notificar al sistema los cambios externos? Debe el sistema informar al actor de los cambios internos? Respondiendo las preguntas anteriores y realizando una
combinacin de los procesos descritos, ya que no hay ninguno mejor que el otro, podemos identificar sin mayor problema a los casos de uso del sistema.
Pgina 118 de 152

Definicin de los tipos de relaciones

Las relaciones en el diagrama de casos de uso se dan entre los actores y los casos de uso y adicionalmente entre los casos de uso. Estas relaciones nos permiten establecer de forma grfica como un caso de uso se asocia con otro caso de uso para complementar su funcionalidad o con un usuario para mostrar la forma en que estos son utilizados.
Comunicacin.
Es el tipo de relacin que se establece entre el usuario y el caso de uso, se define con una lnea continua que une al actor y el caso de uso.
Inclusin.
La relacin de inclusin nos permite mostrar la forma en que los casos de uso se complementan con otros casos de uso a los cuales incluyen para poder realizar una accin. Cuando el caso de uso incluye a otro, el caso incluido sirve para complementar la accin del primer caso de uso, vale decir, sin el caos de uso incluido, el caso de uso inicial no puede completar su tarea.
Pgina 119 de 152
Extensin.
En la relacin de extensin el caso de uso extendido, completa su accin con el caso de uso extendido, es decir, el caso de uso extendido, aumenta su funcionalidad con el caso de uso extendido, pero el caso de uso extendido no es necesario siempre.
Pgina 120 de 152

Generalizacin.
La relacin de generalizacin en los casos de uso permite definir un caso de uso especializado para una situacin en particular, es decir existe un caso de uso especfico que realiza una accin, pero tambin un caso de uso que se especializa en realizar un proceso en particular.
Documentacin de los casos de uso.

La documentacin de los casos de uso es un proceso que permite aumentar el grado de comprensin de los procesos asociados a los casos de uso. Esta documentacin est orientada a servir como complemento al diagrama pues el diagrama muchas veces no permite representar con claridad los procesos ni cmo estos se implementan. Adicionalmente la documentacin es una gua prctica para que los desarrolladores de las aplicaciones a futuro puedan implementar de mejor forma la funcionalidad de la aplicacin. Otro aporte fundamental de la documentacin es el hecho de que tambin puede ser revisada por la contraparte
Pgina 121 de 152

cliente y se podr trabajar con ellos en la definicin correcta de los procesos ac descritos. Existen muchos formatos para realizar la documentacin de los casos de uso, vamos a usar un formato bsico pero completo para poder establecer de la mejor forma la descripcin de los casos de uso. Nuestro documento constar de las siguientes partes:
Definicin del caso de uso.

En esta parte se define el nombre del caso de uso, su identificador y se da un breve descripcin del caso de uso, fundamentalmente la descripcin est orientada a definir el proceso general que se est describiendo.
Flujo Normal.
La seccin del flujo normal pretende que definamos el flujo normal de actividades que se pueden identificar en un caso de uso, este es el camino feliz es decir el proceso en su estado ideal en donde nada falla y todo est como queremos. Adicionalmente al flujo normal se suele definir una serie de caminos alternos que nos permitan saber cmo se comporta el sistema que estamos analizando cuando el proceso no llega a buen puerto. La realizacin de este tipo de anlisis es muy importante pues muchas veces el flujo alterno puede definir una regla importante respecto al flujo del proceso.
Pgina 122 de 152

Pre-condiciones.
Las precondiciones permiten formalizar todas aquellas condiciones de deben considerarse como requisitos para la ejecucin de nuestro caso de uso
Post-condiciones.
Las post-condiciones con estados finales con los cuales termina el caso de uso y que son obligatorios. Esto significa que el caso de uso debe terminar su proceso con alguna de las condiciones definidas en esta seccin. Para clarificar el concepto, fjate en la definicin del caso de uso que esta hecha en el siguiente texto:
Nombre del caso de uso: Registro de usuario Actores: Usuario/Administrador Objetivos: Registrar al usuario/administrador en el sistema Pre-condiciones: 1. El usuario no debe estar registrado con anterioridad. Flujo Normal: 1. El usuario solicita el registro. 2. El usuario llena el formulario de registro. 3. El sistema valida que los datos estn completos y que la informacin sea del tipo correcto. 4. El sistema chequea que el usuario no se encuentre registrado con anterioridad. 5. El sistema almacena los datos del usuario, asignndole los permisos necesarios. Pgina 123 de 152
6. El sistema muestra un mensaje de exito en el proceso de registro. Post-condiciones: 1. El usuario es registrado en el sistema y se le enva un correo el cual contiene un hipervnculo que debe ser seguido para validar el registro. Excepciones: 1. El usuario cancela el registro 2. El usuario no llena todos los datos. 3. El usuario ingresa datos que no corresponde. 4. El usuario intenta registrarse, pero sus datos ya existen en el sistema.
Pgina 124 de 152

Pgina 125 de 152

Diagrama esttico de clases.

Introduccin al diagrama esttico de clases.
Como se vio en los captulos anteriores, el mundo de los diagramas UML es bastante extenso y cada diagrama tiene un propsito especfico y entre ellos muchas veces se complementan para entregar informacin ms especfica respecto a un proceso en particular, o la forma en que se deben realizar las cosas. Uno de los diagramas que nos va a permitir mostrar la forma en que los diferentes componentes del software interactan entre si, es el diagrama esttico de clases. Piensa en lo siguiente, la mayora de las cosas que conocemos estn formadas por varias partes las cuales se complementan para realizar una tarea especfica, la cual no podra ser realizada por ninguna de las partes por separado. Por ejemplo cuando quieres prender tu televisor y te encuentras a una distancia apreciable, vas a tener la tendencia natural a utilizar el control remoto, si te fijas, para lograr prender el televisor, t como objeto, ests interactuando con el control remoto (otro objeto) el cual enva una seal al televisor (otro objeto) y finalmente el televisor se enciende.
Pgina 126 de 152

Si analizas el comportamiento que tienen los objetos, podemos definir que el objeto persona enva un mensaje al objeto control remoto que a su vez se comunica con el objeto televisor para realizar una accin. De esta forma t no enciendes el televisor, es el control remoto el que solicita al televisor que se encienda. Una de las funciones del diagrama esttico de clases es el poder mostrar la forma en que los objetos se comunican y relacionan.
Utilidad del diagrama esttico de clases.

El diagrama esttico de clases como lo vimos, permite obtener informacin referente a 2 vistas en particular. La primera dice relacin con la forma en que los objetos se componen, es decir sus caractersticas y la forma en que se comportan, y la segunda es analizar la forma en que las clases se relacionan. El diagrama permite tener una vista esttica del problema el cual no va a cambiar con el tiempo. Este diagrama adicionalmente nos va a permitir avanzar en una concepcin ms acabada de cmo todos los procesos que determinamos en el diagrama de casos de uso se van a convertir en una aplicacin de software o en un proyecto de algn otro tipo (recuerda que una de las ventajas de UML es que no slo sirve para disear software). Cabe sealar que el diagrama esttico de clases no hace slo referencia a como las distintas partes del software interactan sino que tambin puede incluir hardware, y todos los otros componentes que forman un proyecto informtico.
Pgina 127 de 152

En cursos ms avanzados en la lnea de programacin vers el cmo poder interpretar este diagrama esttico de clases y convertirlo en una aplicacin o al menos en una parte de ella. Una de las ventajas de la orientacin a objetos es que las aplicaciones de software se pueden construir por partes sin que esto afecte el total de la aplicacin y adicionalmente esta parte que construyes la puedes reutilizar en otros proyectos.
Componentes del diagrama esttico de clases.

Para comprender cmo podemos construir un diagrama esttico de clases primero vamos a conocer los distintos componentes de este diagrama y que representan, adems de cmo se relacionan unos con otros y los diferentes significados que estos van a tomar en funcin de como se relacionen. Lo primero que debes entender es que existe una diferencia entre la clase y el objeto, aunque muchas veces tendemos a confundirlos producto de malos entendidos. La clase es la muy parecido al plano de construccin de un edificio o al diseo que hace un ingeniero en electrnica de un circuito impreso, es decir ac se define la forma en que se van a construir los objetos. Por lo tanto podemos decir que un objeto es la construccin fsica basndonos en las especificaciones de una clase. A continuacin se define formalmente el concepto de clases y objetos.
Pgina 128 de 152

descripcin generalizada (por ejemplo, una plantilla, un patrn o un prototipo) que describe una coleccin de objetos similares7 descriptor de un conjunto de objetos que comparten los mismos atributos, operaciones, mtodos, relaciones y comportamiento8 Si te fijas en las definiciones anteriores, stas siempre hacen referencia a un descriptor o plantilla o prototipo, es decir en una clase es necesario hacer la definicin de las caractersticas y las acciones que realizarn los objetos. Para lograr este cometido primero debes tener en claro el modelo que quieres representar. Recuerda que una de las partes ms complejas del desarrollo de proyectos de tecnologas de informacin es tratar de definir de forma correcta los requerimientos que tenga la contraparte. Recuerda el ejemplo del bunker para el apocalipsis zombi. Si bien un bunker para un apocalipsis nuclear te podra servir, el bunker para el apocalipsis zombi tiene otras caractersticas que son necesarias, por ejemplo muchas motosierras, y por lo tanto suficiente combustible, y un sin nmero de armas corto punzantes (machetes, espadas, katanas, etc.) que sern de mucha utilidad cuando salgas a explorar los alrededores. Una vez que tengas muy claro las necesidades de la contraparte puedes comenzar a pensar en la funcionalidad que debe tener el sistema y como cada una de estas funciones est pensada para un tipo de usuario. Por ejemplo el sistema de transporte pblico tiene funciones pensadas para diferentes usuarios (pasajeros, pasajeros con capacidades de desplazamiento limitadas y choferes). Cada
7
Ingeniera del Software: Un enfoque prctico, Roger S. Pressman, McGraw-Hill/Interamericana de Espaa, S.A.U. 2002, ISBN 84-481-3214-9 8 El Lenguaje Unificado de Modelado. Manual de Referencia, Pearson Educacin, S.A. 2000, ISBN 84-7829-037-0
Pgina 129 de 152

uno de ellos utiliza funcionalidades distintas del sistema, por ejemplo slo el chofer puede manejar. Cuando logras definir las funciones y quien las utiliza en el sistema, entonces puedes construir un diagrama de casos de uso (visto en el captulo anterior). y que paso con las clases? Cuando logras establecer el comportamiento del sistema y los usuarios que interactan con el sistema analizado, entonces ests en condiciones de pasar a la siguiente etapa del proceso de anlisis, que corresponde a tratar de hacer una agrupacin de funcionalidades que implementa el sistema y agrupar estas funciones, si bien esto suena complejo, no te preocupes esto lo has hecho de forma natural durante toda tu vida, la diferencia es que no te habas dado cuenta. Para muestra un ejemplo. Supongamos que te encuentras leyendo este manual en la sala de clases, si te fijas, la sala esta llena de objetos que interactan entre si y que en conjunto logran un objetivo, que en este caso es el traspaso de conocimiento desde el docente al alumno. Ahora debes tener en cuenta que los objetos que viven en esta sala de clases, lo hacen con un propsito, este propsito est asociado a su entorno, es decir, las actividades que realiza el alumno en la sala de clases son diferentes a las acciones que realiza la misma persona cuando va a comprar al supermercado, aunque se trate de la misma persona. Lo anterior nos demuestra que existe un mbito para los objetos en el cual el objeto se comporta de una forma especfica y posee ciertas caractersticas que estn asociadas a los procesos que este realiza. Por ejemplo, para estudiar, el alumno necesita materia que le entrega el profesor, adicionalmente el profesor califica el
Pgina 130 de 152
desempeo del alumno con una nota, si te fijas en el ejemplo anterior, cada uno de los objetos realiza un proceso y ese proceso lo realiza con un conjunto de datos que les es propio o que algn otro objeto les entrega. Este proceso de abstraccin mental en el anlisis de los procesos que se ve tan complejo en realidad t lo llevas haciendo desde pequeo seguramente sin darte cuenta. Volvamos ahora hacia las clases y su representacin en el modelo. Como vimos anteriormente, en el mundo real los objetos interactan entre s y poseen datos que les permiten realizar sus procesos, esos datos a su vez definen el comportamiento posible de los objetos. Volvamos a ver un ejemplo, si tuviramos que definir un lpiz en orientacin a objetos, tendramos que definir sus caractersticas o atributos y su funcionalidad. Definicin del lpiz
En los objetos la funcin y las caractersticas siempre estn unidos y nunca se separan, de esta forma, la funcin afecta a la caracterstica y viceversa, por ejemplo cuando el lpiz raya, esta accin hace que la cantidad de tinta disminuya, cuando la cantidad de tinta llega a 0, Puede seguir rayando el lpiz? . Si analizas los comportamientos de muchos objetos que te rodean te dars cuenta de que esta unin entre las caractersticas y la funcin
Pgina 131 de 152
siempre se encuentra y es fcil de descubrir, por ejemplo, si enciendo la ampolleta con el interruptor, que otra cosa puede hacer el interruptor? , Puede volver a encender la luz?, o primero debe apagarla?. Fjate que al encender o apagar la ampolleta, estas cambiando el estado de la ampolleta (una caracterstica que posee) y al apagarla, esto tambin ocurre, pero al estar encendida, esta slo se puede apagar, te das cuenta de la relacin?, si an no queda claro, ac va otro ejemplo. Supongamos que puedes viajar al pasado y logras traer de vuelta a un tiranosaurio rex como mascota, si te fijas bien en su comportamiento, te dars cuenta de que tu nueva mascota, entre todas las cosas que hace, come bastante y adems camina y ruge, fjate adems que para cada una de esas acciones que realiza, la nueva mascota utiliza energa, slo puede realizar las acciones antes descrita si la cantidad de energa es mayor a 0. Ahora bien cada vez que realiza una accin, la cantidad de energa se disminuye una cierta cantidad de unidades, pero cuando come, la cantidad de energa acumulada aumenta. Con esto vemos que los atributos o caractersticas de una clase se ven modificados por las acciones o mtodos, de la misma forma, si el dinosaurio mascota no se alimenta, su cantidad de energa ser 0 y por lo tanto no podr realizar ninguna de las acciones antes descritas.
Muy bien, ahora te debes estar preguntando Y que paso con los grficos del diagrama?, ahora vamos a eso, en UML, la representacin de las clases, sus atributos y sus mtodos se realiza mediante una representacin grfica que muestra un rectngulo dividido en 3 partes, la superior contiene el nombre de
Pgina 132 de 152
la clase, la parte central la definicin de los atributos de las clases y la parte inferior los mtodos o comportamiento de la clase. Para muestra un ejemplo:
Fjate que cada una de las secciones posee ciertas caractersticas con respecto a la forma en que stas se definen.
Nombre de la clase: Esta se debe escribir centrada en la pgina y con formato de texto ennegrecido, adicionalmente existe una nomenclatura para la escritura de los nombres que si bien no es estndar es la que se recomienda. Consiste en escribir el nombre con un formato conocido como PascalCasing, este formato nos solicita que escribamos el nombre con la primera letra en maysculas y el resto en minsculas, por ejemplo Alumno, ahora si el nombre es un nombre compuesto, sugiere que las primeras letras de cada una de las palabras tengan este formato, por ejemplo MascotaSaurio. Atributos: Los atributos se definen dentro de la clase utilizando un formato llamado camelCasing, este formato define que la primera
Pgina 133 de 152
letra se escriba en minsculas al igual que todas las otras, a menos que tengas que crear un atributo compuesto que en este caso solicita que la primera palabra la escribas en minsculas pero la primera letra de la segunda palabra la escribas con maysculas, esta misma lgica se da si tienes ms de dos palabras, por ejemplo edad, fechaNacimiento, tamaoPueraTrasera. Adems cada atributo debe definir su tipo, en UML existen algunos tipos de datos primitivos por ejemplo Integer, String, Boolean, etc, pero tambin se pueden agregar otros tipos que permitan aumentar la capacidad de tu modelo, esto se hace en funcin generalmente del lenguaje de programacin con el que se vaya a generar el software al final. Otra cosa que debes tener presente es que los atributos y los mtodos poseen niveles de visibilidad que determinan si un atributo o mtodo es visible desde fuera de la clase, esto es lo que se denomina como la interfaz de una clase, es decir el conjunto de atributos y de mtodos con los cuales el objeto se comunica con su ambiente, el siguiente ejemplo lo puede clarificar. Lo ms probable es que alguna vez hayas utilizado un reproductor de DVD, el uso general indica que el reproductor se enciende, se abre la bandeja, se pone el DVD en el interior y si todo esta correctamente conectado, se comenzar a reproducir el contenido del DVD. Ahora fjate que t interactuaste con el reproductor de varias formas, pero algunas otras quedaron ocultas, t encendiste el lser del DVD, realizaste la demultiplexin de la seal ptica para ser transformada en audio y video?, lo ms probable es que no, t slo interactuaste con los botones del equipo y con el disco en cuestin, pero el resto del proceso se realiz sin tu
Pgina 134 de 152
intervencin. En este caso la interfaz del DVD es el conjunto de botones con los cuales t puedes hacer que este funcione. Todos los objetos con los cuales interactuamos presentan una interfaz y poseen un conjunto de mtodos y propiedades con las que no podemos interactuar pues estn ocultas para nosotros. Esta caracterstica pues te de ocultar comportamiento ojos quemados y acceso existiran a si las te propiedades de una clase se realiza por un tema de seguridad, imaginas cuantos permitieran manipular el lser o encender la chispa para prender un motor, De esta forma el atributo se define con el siguiente formato: Nombre_atributo: tipo_dato=valor_inicial Si te acuerdas del tema de la visibilidad, los atributos de las clases se clasifican en privados (-) o pblicos (+), para entender de que se trata esto, piensa en lo siguiente, cuando enciendes el DVD, la velocidad del motor que mueve el DVD es imposible que la podamos acelerar o disminuir desde afuera, en este caso la velocidad del motor es una atributo privado para la clase es decir slo se puede modificar desde dentro de la propia clase y se le anota un signo - delante. Sin embargo, cuando por ejemplo apagamos el interruptor de la ampolleta, la estamos apagando y por lo tanto estamos modificando desde afuera una caracterstica de esta clase, en este caso la propiedad se define como pblica y se le anota un signo + delante del atributo. De esta forma los atributos de la clase se anotan de la siguiente forma: -energiaZombi: Integer=100;
Pgina 135 de 152
-escudoProtector: Integer=20; Los mtodos de la clase tambin tienen una nomenclatura especfica, en este caso los mtodos se anotan de la siguiente forma: NombreMetodo(atributo:tipoDato) En este caso tambin debemos explicar algunas cosas respecto al formato, el nombre del mtodo representa el nombre del comportamiento de la clase, este nombre debe ser significativo o sea que te permita saber fcilmente que es lo que el mtodo hace, slo con leer su nombre, por ejemplo, que es ms fcil de determinar, el comportamiento de un mtodo que se llama liquidarZombi(), o un mtodo llamado x25rst45(), si te fijas, el primer mtodo se explica por si slo, mientras que el segundo no. Adicionalmente al nombre si te fijas entre parntesis aparecen variables, es decir valores que se identifican con un nombre y que son de un tipo de dato especfico, estas variables el mtodo las ocupa para poder tener informacin adicional que es parte del mensaje que el objeto recibe para poder ejecutar el mtodo. Los objetos no hacen nada a menos que otro objeto se los pida, por ejemplo el control remoto no enciende el televisor a menos que nosotros se lo solicitemos, o por ejemplo el vehculo no se mueve a menos que nosotros presionemos el pedal del acelerador, en este caso la cantidad de presin que apliquemos al pedal ser la velocidad de salida del automvil, si te fijas en este caso lo podemos representar de la siguiente forma: +acelerar(fuerza:Integer)
Pgina 136 de 152

Por lo tanto ahora podemos representar clases como corresponde, es decir:
Pgina 137 de 152

Relacin entre las clases y las tablas de un modelo entidad relacin.

Como podemos observar, al crear y definir las clases, estas se pueden analizar como un conjunto de datos sobre los cuales se aplican un conjunto de mtodos. Este anlisis de los procesos agrupando primero los datos, se parece mucho al anlisis que se realiza en la disciplina de base de datos para crear las entidades de datos que nos van a permitir agrupar los datos en registros que a su vez construyen lo que se conoce como bases de datos. Las bases de datos no son ms que un conjunto de datos agrupados alrededor de un concepto, o una idea (igual que las clases). Si bien las estructuras se parecen, estas no son iguales y a veces esto lleva a los programadores a cometer algunos errores. Por ejemplo, si te enfrentas a un problema que implique el modelar el comportamiento de un alumno en un sistema de matrcula, entonces, el modelo de la clase se podra graficar de la siguiente forma:
Pgina 138 de 152

Ahora fjate en el modelo de la entidad que se puede crear para la misma estructura.
Si te fijas, los dos elementos se parecen mucho en su definicin, la diferencia est en que la clase posee los mtodos de la clase y adicionalmente, la forma en que se relacionan los elementos son distintos.
Componentes del diagrama esttico de clases.

Ahora lo que vamos a hacer es realizar un diagrama completo de clases, para esto vamos a analizar un problema muy simple, y lo vamos a comenzar a desmenuzar en cada una de sus parte de forma tal que el modelo se vaya construyendo de a poco. La liga de futbol de tu pas necesita establecer el modelo de clases para poder crear un software estadstico para llevar el control de los partidos que se estn por comenzar a jugar en la liga, adems necesita conocer los goles marcados, el goleador por equipo y cada uno de los registros asociados a un partido de ftbol. Debes tener presente que el proceso de anlisis orientado a objetos es un proceso iterativo incremental, es decir que debes darle varias vueltas al asunto antes de que quede 100 por ciento correcto, lo que no quiere decir que vayas a estar iterando
Pgina 139 de 152
eternamente, la experiencia ya te dir cundo es suficiente la iteracin del proceso. Lo primero es tratar de definir las clases propuestas, que aparezcan en el modelo, para esto leemos la definicin del problema o la definicin de requerimientos y comenzamos a analizar el texto, descubriendo con esto todos los sustantivos que aparezcan en el problema, de esta forma hacemos un listado preliminar: Liga. Partidos. Goles. Equipo. Ahora si te fijas bien en el listado anterior todas las clases propuestas intervienen en el proceso que queremos modelar, si apareciera alguna que no intervenga, entonces hay que analizar si se justifica el que la incluyamos en el listado. Analizando el listado vemos que podra ser posible el incluir a los jugadores pues ellos componen los equipos y hacen los goles, por lo tanto su inclusin en el modelo podra ser bastante necesaria. Ahora una vez que tenemos el listado de clases candidatas debes intentar el analizar el problema y tratar de definir qu comportamiento van a realizar cada una de las clases que has definido para el problema, de esta forma, podemos definir la clase inicial para el jugador de la siguiente manera: En el diagrama anterior podemos establecer una relacin entre los mtodos de la clase y los atributos de la misma, as por ejemplo existe un mtodo que se llama marcarGol(), este mtodo de forma interna lo que hace es que modifica la cantidad de goles que ha
Pgina 140 de 152
marcado el jugador y adicionalmente disminuye la cantidad de energa que este posee. Si durante el anlisis te das cuenta que hay un atributo que no es ocupado o algn mtodo que nunca es utilizado, entonces es el momento de modificarlo, pues esto despus al ser transformado en cdigo, ser trabajo extra que tendr que hacer el programador. Como este es un proceso iterativo e incremental, podremos agregar o quitar tantos mtodos o atributos que consideremos que no estn correctamente asignados. Recuerda eso s que la decisin de agregar o quitar
elementos desde el modelo no es antojadizo, es parte del proceso de anlisis que nos lleva a dejar slo aquellos procesos que nos son tiles para solucionar el problema, por ejemplo si analizamos a nuestro jugador nos damos cuenta de que tambin come, y corre y salta y realiza un montn de acciones, pero estas acciones no son relevantes para el proceso que estamos estudiando, este proceso de ignorancia selectiva se conoce como abstraccin y es uno de los procesos ms importantes del diseo de clases. Este proceso de abstraccin permite que te concentres en lo realmente importante para solucionar el problema y dejas de lado lo que no te interese. Una vez que logres determinar la estructura aproximada de las clases, debes documentar el comportamiento de cada una de ellas, y agregar documentacin para los atributos que esta posee, para muestra la siguiente clase documentada.
Nombre de la clase: Atributo 1: Atributo 2:

Pgina 141 de 152
Comportamiento 1: Comportamiento 2:
Relaciones entre las clases.

En el mundo real, las clases no funcionan solas, sino que establecen relaciones entre ellas, estas relaciones, permiten definir la forma en que las clases interactan en el mundo real cuando se transformen en objetos. Recuerda que cuando construimos clases, estas clases se transformarn en objetos cuando se estn ejecutando como un software en el computador. Para clarificar piensa en lo siguiente, t estas definiendo las clases y las estas documentando de forma tal de poder definir el comportamiento de las clases y sus caractersticas. Por otro lado un programador va a tomar esta definicin y la documentacin que t desarrolles y va a construir un software donde estas clases se transformaran en archivos de cdigo. El compilador del lenguaje de programacin va a tomar estos archivos y los va a compilar y a ejecutar, eso significa que el cdigo fuente cuando se ejecute se va a guardar en la memoria RAM del computador y cada uno de los objetos que all se creen, van a ser una instancia de una clase. Es decir cuando pasamos de la clase a la construccin fsica del objeto entonces estamos hablando de la instancia de una clase y por lo tanto podemos asegurar que un objeto es la instancia de una clase. Los objetos deben colaborar unos con otros para solicitar a otras clases que realicen operaciones que ellos por si solos no pueden
Pgina 142 de 152
realizar, ahora te preguntars Por qu no puedo tener un solo objeto que haga todo?, la respuesta es simple, los objetos compuestos son difciles de arreglar cuando estn malos y adems son muy costosos de producir, piensa en lo siguiente, si se te echa a perder el monitor de tu computador, cambias el computador completo o slo el monitor? Si te fijas en este caso, es ms barato cambiar el monitor que el computador completo y adicionalmente para la fbrica es ms barato producir slo monitores que los computadores completos, lo mismo sucede con casi todos los objetos que ves a diario y con los cuales interactas, estos estn compuestos de otros objetos, pues es ms fcil remplazar y construir las partes especficas de cada una. Por lo tanto para lograr un objetivo mayor, un objeto solicita a otro objeto que realice una accin mediante la comunicacin utilizando mensajes, estos mensajes permiten que los objetos colaboren y as los objetos pueden lograr especificidad y hacerse especialistas en una o varias operaciones. Por ejemplo el delantero hace goles como funcin principal, pero adems tambin puede quitar la pelota como el defensa, el defensa a su vez, puede quitar a la pelota y hacer goles, pero cada uno de ellos cumple una funcin de mejor forma, as cuando uno de ellos se lesiona es cambiado por otro que realiza la misma funcin. En el diagrama de clases es posible ilustrar estas relaciones mediante una lnea que une cada una de las clases, y adicionalmente segn el tipo de relacin que se establece, tambin se pueden agregar algunos otros elementos que permitan aclarar la relacin que se establece entre las clases.
Pgina 143 de 152

Bsicamente la relacin que se establece entre dos objetos tiene que ver con la comunicacin que estos establecen, as un objeto se comunica con otro o colabora con otro objeto cuando le solicita que realice una accin para la cual l no fue creado pero que necesita, por ejemplo, cuando utilizas el control remoto para prender o cambiar el canal de la televisin, lo que estas haciendo es utilizar una funcin que est implementada en el control remoto (controlar las funciones del televisor de forma remota) , como tu no puedes prender el televisor ni cambiar los canales de forma remota, necesitas de la ayuda o colaboracin del control remoto para poder realizar la tarea. De esta forma los objetos colaboran y establecen relaciones entre ellos. Ahora no siempre todos los objetos colaboran entre s, y es posible que un objeto colabore slo con otro objeto, eso s, siempre los objetos colaboran con al menos uno. Si te fijas a tu alrededor, todo lo que ves son objetos compuestos de varios otros objetos que estn colaborando unos con los otros. Fjate por ejemplo en tu computador, en la lavadora o la cocina de tu casa, en el cuadro que est colgado en a pared, en el reloj que llevas, en la ropa que tienes puesta, cada uno de esos objetos esta compuesto de otros objetos cuya colaboracin permite que el objeto exista, pregntate lo siguiente Qu es un teclado sin teclas?, Qu hago con un computador sin monitor?, De qu me sirve un auto sin ruedas? Como a veces las relaciones que se establecen entre los objetos son muy complejas, se han establecido categoras o tipos de relaciones que permiten diferenciar los tipos de relaciones
Pgina 144 de 152

existentes, pues aunque no lo creas existen distintos tipos de relaciones entre los objetos, las cuales definiremos a continuacin.
Asociacin.
La relacin de asociacin, se define cuando una clase se asocia con otra para lograr un objetivo, este tipo de relacin es el ms bsico, en este caso cada una de las clases tiene una instancia de la otra. El conector puede incluir el nombre del rol en cada uno de los extremos, la cardinalidad, la direccin de la relacin y las restricciones. Veamos el siguiente ejemplo:
Vamos a describir ahora en qu consiste cada una de las partes que componen el ejemplo anterior. El conector es la lnea que permite establecer que existe una relacin entre las clases. Fjate que el conector adicionalmente puede tener el nombre del rol de esa clase en esa relacin. Por ejemplo en determinado momento tu estableces en tu casa varios roles en funcin de con quin te relaciones, si te relacionas con tus hermanos, tu rol es el de hermano, si te relacionas con tus padres tu rol es el de hijo, la importancia de definir bien el rol radica en el conjunto de comportamientos que implementas para esa relacin en particular.
Pgina 145 de 152

La direccin de la relacin permite establecer cual es la clase que genera las instancias de la otra clase. Las restricciones son bsicamente anotaciones con instrucciones o con caractersticas que no pueden ser escritas en el diagrama de otra forma. Las restricciones suelen encerrarse entre llaves {}, como en el siguiente ejemplo:
Multiplicidad.
La cardinalidad o multiplicidad en una relacin establece el grado y nivel de dependencia, de esta forma podemos determinar que existen varios tipos de cardinalidad:
Asociacin uno a uno (1..1): En una relacin de asociacin uno a uno, sta es en ambas direcciones, por lo mismo los objetos de ambas clases estn asociados slo a un objeto de la otra clase, por ejemplo la relacin de exclusividad que existe entre el gerente de una empresa y la empresa, as el gerente slo puede ser gerente de una empresa y la empresa slo puede tener un gerente. Asociacin uno a muchos(1..*): en esta relacin, se produce una relacin uno a muchos en una direccin y en la otra una relacin uno a uno, por ejemplo la relacin entre el hroe y la
Pgina 146 de 152
cantidad de balas que puede disparar, si te fijas en las pelculas de accin los hroes poseen cargadores infinitos de balas, nunca sabemos cuando se van a acabar. De esta forma, el hroe posee un cargador con muchas balas (no sabemos el nmero exacto) y esas balas pertenecen slo al hroe. Asociacin numricamente especificada(n..m): en este caso la asociacin se realiza un nmero de veces especificado, por ejemplo en un equipo de voleibol, la cantidad mnima de jugadores es 6 y la mxima 12, fjate que las cotas mnimas y mximas estn bien definidas y no pueden ser mayores o menores es decir un equipo no puede tener 5 o 4 jugadores como tampoco puede tener 13 o 14 pero si puede tener 8. Asociacin opcional (0..*): en este caso, la relacin no establece obligatoriedad de existencia en la relacin, por ejemplo la relacin que se da entre el dueo de una cuenta de banco y las tarjetas de crdito que este posee. No todos los dueos de las cuentas de banco poseen tarjeta de crdito. Cabe hacer notar que la relacin que se establece del otro lado siempre es de uno a uno. Asociacin muchos a muchos (*..*): en este caso la relacin se establece entre clases con una asociacin de uno a muchos en ambas direcciones, por ejemplo la relacin que se establece entre los alumnos y las asignaturas que inscriben en el semestre, si te fijas un alumno tiene muchas asignaturas inscritas y cada asignatura a su vez posee muchos alumnos.
Pgina 147 de 152

Asociacin calificativa.
Este tipo de asociacin est asociada a la relacin del tipo uno es a muchos, en el cual se requiere explicitar algn atributo que definir un identificador nico para una clase y de esta forma poder diferenciar cada uno de los objetos de la relacin, por ejemplo cada uno de los buses para un recorrido del Transantiago 9 est asociado al recorrido con una relacin del tipo uno a muchos, para poder identificar a cada bus de forma individual ocupamos el atributo patente del vehculo para establecer la relacin. De esta forma la asociacin calificada quedara de la siguiente forma:
Asociacin reflexiva.
La asociacin reflexiva se da cuando la relacin se establece entre elementos del mismo tipo, es decir la clase se relaciona consigo misma, pudiendo establecer el rol para clarificar la relacin, por ejemplo supongamos que necesitamos establecer la relacin existente entre los trabajadores sabiendo que uno es el jefe y el resto son empleados, si te fijas todos son empleados, pero su rol los diferencia.
http://es.wikipedia.org/wiki/Transantiago
Pgina 148 de 152

Herencia.
La asociacin de herencia permite que las clases que se relacionan, lo puedan hacer en un nivel de especificidad, es decir que las clases que se estn asociando son clases iguales salvo que una de ellas es ms especfica, es decir implementa ms mtodos o los mismos mtodos pero con una implementacin distinta.
Asociacin.
Existen algunos tipos especiales de asociacin que veremos a continuacin, estos tipos especiales permiten representar asociaciones ms complejas. La asociacin ternaria es una asociacin entre tres clases de forma simultnea, la cual no puede ser leda o agrupada slo de a dos clases pues pierde el sentido. Por ejemplo se puede establecer una relacin entre artista, cancin e instrumento o entre jugador,
Pgina 149 de 152
equipo y posicin. En los dos ejemplos anteriores podramos analizar la relacin de a pares pero pierde su significado o semntica, Para establecer la relacin ternaria se dibuja un rombo entre las tres clases. Al igual que en el resto de las asociaciones, puedes agregar caractersticas de cardinalidad a la relacin.
Otra relacin de asociacin particular son las clases de asociacin. Una clase de asociacin aquella que modela una asociacin entre dos o ms clases. Los atributos de la clase de asociacin son los atributos de la asociacin. En el caso de una asociacin compleja entre dos o ms clases, es posible que una clase de asociacin tenga sus propios atributos, los cuales sirven para dar significado a
Pgina 150 de 152
la relacin. Como ejemplo, analicemos la relacin existente entre los alumnos y las asignaturas que cursan este semestre, si analizamos la relacin, nos damos cuenta de que existe una relacin de muchos a muchos, en este caso en particular se puede crear una clase de asociacin llamada horario que permite establecer que alumno esta asociado a que asignatura especfica. Otros tipos de relaciones son las relaciones de composicin y agregacin. Estas relaciones son muy parecidas y se basan en el concepto de que una clase es una parte del todo, por ejemplo la lmpara se compone de un interruptor, el soquete, la ampolleta y la pantalla, se establece una relacin de uno a uno entre la clase lmpara y sus componentes (el todo y las partes). La agregacin es un tipo de relacin en dnde el todo esta compuesto de partes pero la existencia de las partes no est definida por la existencia del todo, por ejemplo, sabemos que los vehculos tienen ruedas, si analizamos esta relacin, sabemos que las ruedas existen y estn presentes en el modelo de forma independiente al medio de transporte en el cual se ocupen. De esta forma si el medio de transporte se destruye, las ruedas siguen existiendo en el modelo. La composicin es un tipo de relacin ms fuerte que la agregacin. La composicin es tambin una relacin entre instancias. As los objetos que participan en la relacin, nacen, viven y mueren relacionados con el todo. A menudo las clases de composicin se asocian a relaciones fsicas entre los objetos. Por ejemplo si observas una camisa, observas que est compuesta por un grupo de partes (mangas, bolsillo, cuello, puos) y que cada uno establece una relacin ms fuerte, en este caso si la camisa se
Pgina 151 de 152
destruye, la utilidad de la manga o del cuello se pierden pues su existencia tiene significado slo cuando es parte de una camisa. La distincin entre las relaciones de composicin y agregacin es muy sutil y a menudo conlleva acalorados debates y discusiones respecto a cuando es una u otra, generando conflictos insolubles entre hermanos, amigos y parejas, al punto de devolverse las cartas y los peluches regalados.
Realizacin.
Una relacin de realizacin esta dada por una clase y una interfaz. En orientacin a objetos, una clase de interfaz es una clase que define el comportamiento de una clase pero jams la implementa, esto que parece tan complejo lo podemos definir como una clase que es un cascaron sin cdigo por dentro. Te estars preguntando Y para que quiero tener una clase que no hace nada y que no tiene cdigo?, la respuesta no es simple pero lo podemos explicar mediante un ejemplo. Supongamos que estas creando un video juego y debes crear las clases de tu juego, si te fijas los objetos de la pantalla se estn moviendo, pero la nave se mueve en funcin de las teclas que presiones en el teclado o de los botones del joystick que presiones, mientras que las balas se desplazan siguiendo una trayectoria que no se puede cambiar, ambos objetos se desplazan pero lo hacen de forma distinta, por lo tanto como ambos poseen el mismo mtodo (mover) pero los dos lo hacen de forma distinta entonces se crea una clase de interfaz que posea el mtodo y como este mtodo o comportamiento no se programa, le da la libertad a las clases que heredan de esta clase de interfaz a que lo implementen de forma independiente.
Pgina 152 de 152

Manual Análisis y Diseño Orientado A Objeto Versión 1.1

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Manual Análisis y Diseño Orientado A Objeto Versión 1.1

Загружено:

Авторское право:

Доступные форматы

Manual para la asignatura de Anlisis y Diseo Orientado a Objetos Versin 1.0.

Santiago Marzo de 2012

Introduccin al anlisis y diseo Orientado a Objetos

Definicin del anlisis y diseo orientado a objetos

Importancia del anlisis y diseo orientado a objetos

Diferentes metodologas de anlisis de sistemas.

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

convencionales, el ADOO tiene muchas ventajas, algunos de ellos

Los datos, la informacin y su importancia para las organizaciones.

Definicin de los datos en el contexto de un problema.

Teora de sistemas bsica y la interaccin de los objetos en una organizacin.

Sistema 1 Medio ambiente

Componente del Sistema

Frontera del Sistema

Patrn ECB (Entity Control Boundary)

UML y Patrones, Capitulo 18. Craig Larman. Prentice Hall. http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o

Datos, comportamiento y relaciones de los objetos.

Marcador Goles del local Goles del visita

Jugador Pelota Arbitro Dar tarjeta amarilla

Dar pase Hacer gol Recuperar el baln Rodar Rebotar

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

Diagrama de estructuras compuestas.

Diagrama de mquina de estados.

Y para el estado final se debe utilizar:

Quedando el diagrama completo de la siguiente forma:

Tcnicas de recopilacin y anlisis de requerimientos.

Ingeniera de Requerimientos ayuda a los

Relacin entre las actividades y los actores.

Anlisis bsico de los requerimientos para la realizacin de un listado de actividades.

Diagrama de flujo de datos (Agile Unified Process).

Entidad Proceso Almacn Entidad Proceso Almacn NO SI NO SI SI SI NO SI NO

Estos son ejemplos no vlidos.

Diagrama de procesos (BPMN 2.0)

Representa un evento de inicio que no tiene condicin o requisito previo.

Los eventos de fin se representan de la siguiente forma:

un proceso. Puede descomponerse en diferentes

diferentes artefactos con objetos de flujo.

Las anotaciones, son un mecanismo para entregar informacin adicional.

Diagrama de casos de uso.

Pgina 100 de 152

Componentes del diagrama de casos de uso.

Pgina 104 de 152

Vamos a ver en detalle los componentes del diagrama de casos de uso.

Pgina 105 de 152

Pgina 107 de 152

Pgina 109 de 152

Pgina 110 de 152

estn completos sin la utilizacin de buscar usuario, pues de este

Identificacin del contexto en el que participan los actores.

Identificacin de los roles.

Definicin de los actores.

Definicin de los casos de uso.

Pgina 116 de 152

Definicin de los casos de uso.

Pgina 118 de 152

Definicin de los tipos de relaciones

Pgina 120 de 152

Documentacin de los casos de uso.

Pgina 121 de 152

Definicin del caso de uso.

Pgina 122 de 152

Pgina 124 de 152

Pgina 125 de 152