Manual Análisis y Diseño Orientado a Objeto versión 1.1 (1)

Manual para la asignatura de Análisis y Diseño Orientado a Objetos Versión 1.0. Santiago Marzo de 2012

Este material ha sido diseñado para el uso de los alumnos y profesores de la asignatura de Análisis y Diseño Orientado a Objetos de las carreras del área informática. Queda estrictamente prohibido el uso en otros cursos ya sean en línea o presenciales sin el consentimiento explícito de INACAP.

Página 1 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Agradecimientos. Agradecemos a todas las personas que de forma directa o indirecta han colaborado en la elaboración 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 presentación de este proyecto. Vayan nuestros sinceros agradecimientos a los siguientes docentes: Cristian Leiva Marín, Miguel Palma Esquivel, Marcelo Montecinos Cabrera, Rodrigo Toledo de los Santos, Paola Paola Cifuentes

Berrios,

Servando Campillay Briones, Emerson Ilaja Villarroel, Hugo Herrera Valenzuela, Fernando Santolaya, Manuel Morales, Roberto Pérez Fuentes, Fernando Neyra Castro, Victor Bórquez, Francisco Andrés Díaz Rojas, Ademar Araya Fuentes, Ricardo Vera Muñoz, Mauricio Torres Pizarro, Ernesto Ramos Vega, Alberto Garrido Burgos, Helton Bustos Sáez, Beatriz Contreras Guajardo, José Landeta Parra, Luis Pacheco Toro, Patricio Araya Castro, Iván Torres, Hinojoza Vega Mauricio, Yasna Hernández, Víctor Orellana, Rene Valderas Aros, Ricardo

Toledo Barría, Cesar Eduardo Arce Jara, Luis Ponce

Cuadra, Javier Miles Avello, Carolina Ehrmantraut Caballero, Pedro Alfonso Fuentealba Martínez, Jorge Hormazabal Valdés, Pedro Ernesto Ulloa Morales, María del Pilar Gallego Martínez, Claudio Fuenzalida Medina, María Encarnación Sepúlveda, Francisco San Martin, Christian Sarmiento Zampillo, Román Gajardo Robles, Ricardo Hidalgo Hidalgo, Nelson Fredy Ganga Calderón, Manuel Reveco Cabellos, Jacqueline San Martin Grandon, Sergio Vergara Salvatierra, Pablo López Chacón, Cinthya Acosta, Jocelyn Oriana


González Cortés, Carlos Felipe Alten López, Francisco Prieto Rossi, Giannina Costa Lizama, Christian Silva, Sebastián Pastén Díaz.

El aporte realizado por ustedes durante las jornadas de capacitación ha significado mejorar enormemente la calidad del material entregado. Saludos.


Índice Introducción al análisis y diseño Orientado a Objetos .............................................................................................8 Definición del análisis y diseño orientado a objetos ......................................................................................... 11 Importancia del análisis y diseño orientado a objetos ...................................................................................... 11 Diferentes metodologías de análisis de sistemas. ............................................................................................. 12 Los datos, la información y su importancia para las organizaciones. ........................ .................................. ................... .................. .................. ........... .. 18 18 Definición de los datos en el contexto de un problema. ................................................................................... 20 Teoría de sistemas básica y la interacción de los objetos en una organización............... organización........................ ................... ................... .............. ..... 24 Patrón ECB (Entity – Control – Boundary) ......................................................................................................... 27 Datos, comportamiento y relaciones de los objetos. ........................................................................................ 31 Definición de UML ............................................................................................................................................. 36 Etapas del ciclo de vida utilizando RUP (Rational Unified Process) .......................... ................................... .................. .................. .................. ............. .... 37 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 máquina de estados. ................................................................................................................ 64 Diagrama de actividad. .................................................................................................................................. 66 Diagramas de Interacción. ................................................................................................................................. 68 Diagrama de secuencias. ............................................................................................................................... 68 Diagrama de tiempo. ..................................................................................................................................... 71 Técnicas de recopilación y análisis de requerimientos. ........................................................................................ 75 Técnicas de captura de requerimientos. ........................................................................................................... 75 Entrevista. ...................................................................................................................................................... 79 Página 4 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Encuesta. ....................................................................................................................................................... 79 Observación directa. ...................................................................................................................................... 80 Definición de actividades. .................................................................................................................................. 80 Relación entre las actividades y los actores. ..................................................................................................... 82 Análisis básico de los requerimientos para la realización 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 Identificación del contexto en el que participan los actores. ......................................................................... 113 Identificación de los roles. ............................................................................................................................... 114 Definición de los actores. ................................................................................................................................ 115 Definición de los casos de uso. ........................................................................................................................ 116 Definición de los casos de uso. ........................................................................................................................ 117 Definición de los tipos de relaciones ............................................................................................................... 119 Comunicación. ............................................................................................................................................. 119 Inclusión. ...................................................................................................................................................... 119 Extensión. .................................................................................................................................................... 120 Generalización. ............................................................................................................................................ 121 Documentación de los casos de uso................................................................................................................ 121 Definición del caso de uso. .............................................................................................................................. 122 Flujo Normal. ................................................................................................................................................... 122 Pre-condiciones. .............................................................................................................................................. 123 Post-condiciones. ............................................................................................................................................ 123 Diagrama estático de clases. ............................................................................................................................... 126 Introducción al diagrama estático de clases. .................................................................................................. 126 Utilidad del diagrama estático de clases. .................................................................................................... 127 Componentes del diagrama estático de clases. .......................................................................................... 128 Página 5 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Relación entre las clases y las tablas de un modelo entidad relación............................................................. relación............................................................. 138 Componentes del diagrama estático de clases. .............................................................................................. 139 Relaciones entre las clases. ............................................................................................................................. 142 Asociación. ................................................................................................................................................... 145 Multiplicidad. ............................................................................................................................................... 146 Asociación calificativa. ................................................................................................................................. 148 Asociación reflexiva. .................................................................................................................................... 148 Herencia. ...................................................................................................................................................... 149 Asociación. ................................................................................................................................................... 149 Realización. .................................................................................................................................................. 152



Introducción al análisis y diseño Orientado a Objetos Bienvenido al mundo de los objetos! te felicito por emprender este camino, aprenderás 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 análisis sobre las situaciones que te rodean, ya que esto tendrá un directo beneficio en los programas computacionales que crearás en el futuro próximo y la forma en la que entregarás soluciones al medio que te rodea. Mientras mejor entendamos nuestro entorno podremos tomar mejores decisiones. Todos hemos utilizado software alguna vez y de seguro que has encontrado algunos mejores que otros, probablemente en este momento estés recordando dos o más software que hayas usado y cuál de ellos te agradó más, no sólo considerando la usabilidad o lo vistoso del software, sino a un mundo completo que esta detrás que aún no conoces pero del cual serás partícipe muy pronto, que va en desde cómo 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 optimización con la que realiza cálculos y los entrega al usuario. ¿Quién se encarga de todo eso? ¿Existe algún responsable de que todas las partes trabajen en forma eficiente? ¿Quién debe velar porque lo que se construye solucione de la mejor forma posible un problema? Como me imagino ya lo adivinarás esa persona en un futuro cercano serás tú.


Por eso es tan importante tener una buena capacidad de análisis, de esta forma comprenderás mejor las cosas y podrás tomar mejores

decisiones,

mientras

más

comprendemos

menos

deberemos memorizar. El primer paso consiste en hacer análisis, entender el problema de tu cliente e identificar una buena solución. El segundo paso será diseñarla, el paso previo a construirla. Muchos software comienzan a ser codificados sin un buen análisis, lo que da como resultado un producto deficiente que no soluciona el problema del cliente. Un mal diseño provocara un software con errores en el cual se habrá trabajado probablemente el doble de lo necesario, los errores en diseño comienzan notarse tarde en el desarrollo haciendo que una gran cantidad de programas queden en el 90% de su construcción, haciendo que el 10% restante implique incluso más 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 cómo quedaría un edificio si la constructora comienza su tarea sin un análisis y diseño apropiado? y si lo logra, ¿soportará el próximo temblor? Ahora pensemos en qué sucede si el diseño es apropiado, pero proviene de un mal análisis de requerimiento y si bien el edificio queda bonito con 80 pisos, grandes ventanales y piscina en la azotea, pero después de construido y luego de una larga y pausada conversación con tu cliente en la cual te tomas más tiempo para entenderlo, haces un mejor análisis y te das cuenta que lo que en realidad necesitaba era un bunker subterráneo 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 diseñar y construir un bunker llevará sin duda a tu empresa a un fracaso, deja a tus clientes sin un bunker y a tí en Página 9 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

un serio problema, por esto una buena capacidad tanto de análisis como de diseño es tan importante.


Definición del análisis y diseño orientado a objetos El análisis y diseño orientado a objetos es un enfoque de la ingeniería de software que permite modelar un sistema como un conjunto de objetos relacionados que interactúan entre si. Para lograr esta tarea, el análisis y diseño 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 estandarización de los diagramas propuestos por muchos teóricos de esta disciplina alrededor del mundo. El proceso de análisis y diseño 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 básica es el objeto, que combina datos y comportamientos que se realizan con estos datos y que se unen en una estructura atómica.

Importancia del análisis y diseño orientado a objetos El ADOO es parte de un proceso que se conoce como Ingeniería 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 solución utilizando tecnologías de información. Las tecnologías de información son un grupo de tecnologías cuyo propósito es gestionar los datos que son importantes para una organización. Por lo tanto los sistemas que Página 11 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

utilizan tecnologías de información, no sólo hacen referencia al software, sino que también 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 organización realice su propósito. Un correcto proceso de análisis permitirá a los ingenieros de software tomar mejores decisiones para la creación, gestión y administración de proyectos de tecnologías de información. Un análisis incorrecto puede generar un enorme costo para la organización, pues ésta puede tomar malas decisiones respecto a su negocio por no contar con la información correcta en el momento adecuado. Adicionalmente, el desarrollo de un proyecto de tecnologías de información no es un proceso que se realiza de un día para otro, sino que requiere de un tiempo que es difícil de estimar en un principio y por lo tanto su costo puede elevarse en demasía si el análisis inicial no está bien hecho, por lo que esta etapa resulta crucial en el desarrollo de los proyectos de tecnologías de información.

Diferentes metodologías de análisis de sistemas. Al realizar el análisis de procesos en las organizaciones, existen diferentes metodologías que se pueden ocupar para lograr el resultado esperado. Como definición formal podemos decir que una metodología “…hace referencia al conjunto de procedimientos racionales, Página 12 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

utilizados para alcanzar una gama de objetivos que rigen en una investigación científica, una exposición doctrinal o tareas que requieran

habilidades,

conocimientos

o

cuidados

específicos.

Alternativamente puede definirse la metodología como el estudio o elección de un método pertinente para un determinado objetivo.” 1. De esta forma podemos decir que las metodologías como un conjunto de pasos para lograr un objetivo, se pueden clasificar utilizando el enfoque que se aplica para el proceso, existiendo dos metodologías

básicas,

una

metodología

estructurada

y

una

metodología orientada a objetos. La metodología estructurada se originó en los lenguajes de programación estructurados para dar soporte a las necesidades del lenguaje. Esta metodología sentó las primeras estructuras para la definición de la llamada “ingeniería de software” es decir se definieron fases y etapas para dar solución a proyectos de software que se van a desarrollar utilizando un lenguaje de programación estructurado. Adicionalmente a ésta, surge la metodología orientada a objetos, la cual se ha desarrollado y ha permanecido en el tiempo siendo el paradigma de análisis y diseño de proyectos de tecnologías de información más utilizada en estos tiempos. Esta metodología que comenzó a desarrollarse a finales de los años sesenta de la mano del desarrollo de lenguajes de programación orientados a objetos, ha evolucionado durante todos estos años, estableciendo una serie de pasos que han sido extraordinariamente probados en una serie de proyectos. Esta metodología evoluciona constantemente y los estudiosos del tema desarrollan nuevas formas optimizadas y cada 1

http://es.wikipedia.org/wiki/Metodolog%C3%ADa

Página 13 de 152

UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

vez más específicas para el análisis y diseño en situaciones particulares llamadas patrones de diseño. El

desarrollo

de

proyectos

de

tecnologías

de

información

orientados a objetos, requieren técnicas orientadas a objetos que se

aplican

durante

las

etapas

de

análisis,

construcción

e

implementación del proyecto. Estas metodologías requieren que se detecten los objetos del sistema, cómo éstos interactúan, cómo se comportan en el tiempo y las responsabilidades que asumen al relacionarse con otros objetos. El análisis orientado a objetos mira todos los objetos en el sistema, agrupa sus características y comportamientos comunes, estudia sus diferencias y cómo el sistema maneja estos objetos para lograr su objetivo. En términos sencillos, el análisis y diseño 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 metodología estructurada, pues también se sigue un proceso secuencial pero con una aproximación diferente. Las etapas básicas del diseño de sistemas en un modelo orientado a objetos, se pueden listar de la siguiente forma: 

Análisis de Sistemas.



Diseño del sistema.



Diseño de los objetos.



Implementación.

La etapa de análisis de sistemas es la primera parte del proceso de desarrollo de proyectos de tecnologías de información orientados a objetos, al igual que en las otras metodologías. En esta fase es Página 14 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

necesario interactuar con los usuarios del sistema (los que realizan las acciones) para identificar sus necesidades y analizar el sistema para entender su funcionalidad. Basándose 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 implementación (como se van a hacer las cosas) no son tomados en cuenta. Sólo se prepara un modelo del sistema basándose en la idea de que el sistema es un conjunto de objetos que interactúan. La etapa de diseño del sistema es la siguiente etapa de desarrollo dónde 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 diseña el sistema, es necesario poner especial atención a las especificaciones de los procesos definidos en la etapa anterior por parte de los usuarios. Como el análisis orientado a objetos percibe los sistemas como un conjunto de objetos que interactúan, así mismo los sistemas más grandes y complejos se pueden ver v er como un conjunto de pequeños sistemas que interactúan entre sí. En la etapa de diseño de los objetos, se definen los detalles del análisis del sistema y del diseño para definir cómo serán 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.


La fase de implementación implica transformar el diseño de los objetos a código, utilizando algún lenguaje de programación. Adicionalmente se construyen todas las estructuras que darán soporte

al

funcionamiento

del

software

(hardware

y

procedimientos). También se construyen los almacenes de datos o bases de datos, para dar una forma lo más funcional posible al sistema. Las metodologías orientadas a objeto se basan en la identificación de los objetos del sistema. Cuando se observan de forma detenida, los objetos muestran ciertas características y comportamientos que les son propios. Mientras se desarrolla el proyecto, se utilizan ciertos modelos para identificar a los objetos. Básicamente 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 estáticos y no se preocupa de la dinámica que estos puedan tener.

b)Modelo b) Modelo dinámico: Este modelo describe a los objetos en su aspecto dinámico, es decir muestra los cambios ocurridos en el estado de varios objetos que estén interactuando en un momento determinado.

c) Modelo de flujo de datos: Este modelo describe básicamente 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 través del sistema Página 16 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Comparada

con

las

técnicas

de

desarrollo

de

sistemas

convencionales, el ADOO tiene muchas ventajas, algunos de ellos son: 

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 código existente de otra forma, es decir se pueden agregar nuevas funcionalidades o extender la funcionalidad ya existente para crear nuevas clases.



Ignorancia selectiva: la encapsulación es la técnica que permite al programador esconder el funcionamiento interno de los métodos al usuario. La encapsulación separa la funcionalidad interna del objeto de las funciones externas provistas al usuario. Esto permite al programador proteger el código de cambios realizados por el usuario. usu ario.

Los sistemas diseñados utilizando este enfoque están más cercanos al mundo real pues las funciones del mundo real se mapean directamente a los sistemas. La metodología orientada a objetos representa el dominio del problema, pues es fácil reproducir e interpretar los diseños. Los objetos en el modelo son inmunes a los cambios en los requerimientos, un objeto alumnos será un objeto alumno independiente de más o menos atributos o comportamientos que


se agreguen. Por lo tanto los cambios se pueden desarrollar de forma más fácil. Los

diseños

realizados

con

esta

metodología

enfatizan

la

reutilización. Las nuevas aplicaciones pueden usar módulos ya existentes, por lo tanto se reduce el tiempo de análisis y desarrollo, redundando esto en un costo final menor al término del ciclo de vida. Las metodologías orientadas a objetos, tienen una aproximación más

natural,

esto

entrega

mejores

estructuras

para

el

pensamiento y la abstracción y permite un diseño más modular.

Los datos, la información 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 organización posee. Los sistemas de información 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 organización sucedido en algún momento específico. El atributo define qué es lo que quieres guardar y el valor define el tipo de valor asociado, es decir los rangos máximos y mínimos, y el tipo Página 18 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

de dato. Los datos siempre están formados por un par ordenado, ya que cada una de las partes por separado no tienen sentido. Por ejemplo (edad, 21 años).

Cuando una organización registra información relativa a procesos que son importantes, lo hace exclusivamente para poder procesar estos datos, transformarlos en información y luego analizar esta información y tomar decisiones más acertadas. Este proceso de toma de decisiones se ha especializado en extremo, como por ejemplo con la minería de datos, que consiste en analizar los datos ya almacenados y extraer información que se desconocía que existía 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 propósito de tomar mejores decisiones.


Definición 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 organización 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 cuál es el proceso que se quiere registrar, pues de este análisis dependerán 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 básico de la organización. Ahora si bien es posible detectar el quehacer de una organización de forma relativamente simple, es necesario siempre hacer un análisis en función de determinar los datos que se deben registrar, por ejemplo, si analizamos los procesos que realiza una panadería, nos podemos dar cuenta fácilmente que el proceso fundamental de una panadería, en la mayoría de los casos es fabricar y vender pan. Ahora bien si te fijas también hay otros procesos en el ciclo de vida de la organización como por ejemplo pagar los sueldos, comprar las materias primas, distribuir el pan entre los clientes, llevar el registro contable, registrar las ventas, etcétera. Ahora, una vez que has definido los procesos, debes seleccionar los procesos más relevantes para los cuales vas a registrar los datos, siempre Página 20 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

pensando en un contexto determinado. Así si lo que te interesa es registrar los procesos productivos de la empresa, deberás registrar los datos de las compras de insumos, transformación de materias primas a pan y su posterior venta.


Si te fijas en este contexto dejamos varios procesos fuera, pero eso es lo interesante de este trabajo, debes concéntrate en lo importante, es decir sólo en el ámbito que te incumbe en ese momento, pues no existe una solución para todas las áreas al mismo tiempo. Esta lógica de división de los proyectos en pequeños proyectos que se preocupen de áreas específicas de la organización garantiza dos cosas fundamentales, primero garantiza menos costos iniciales en el desarrollo de la solución y segundo, disminuye el tiempo de análisis 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 sensación al usuario de que todo avanza más rápido. Volviendo a la definición de los datos en el contexto, una vez que defines el contexto y defines los procesos básicos 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 (número entero, decimal, caracteres, verdadero o falso, un objeto, etc.) y además los valores permitidos, máximos y mínimos. Por ejemplo si analizamos los datos que podemos registrar de un alumno al momento de matricularlo (este es el contexto), nos podrían interesar datos como los siguientes:


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 numérico entero (raramente tengo 15,76789 años), 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 recién vi la luz del mundo, tenía 0 años y según Wikipedia, la persona más longeva de la tierra tuvo 122 años2, por lo tanto el valor máximo para este dato debería ser al menos 122, de esta forma tenemos que la edad está compuesta por valores numéricos enteros entre 0 y al menos 122.

2

http://es.wikipedia.org/wiki/Jeanne_Calment


Teoría de sistemas básica y la interacción de los objetos en una organización. Existe una teoría básica para el análisis de las organizaciones llamada teoría de sistemas. Esta teoría de forma muy simplificada nos indica que un sistema es un conjunto de elementos que están interrelacionados entre sí con un propósito en común, 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

Componente del Sistema

Medio ambiente

Frontera del Sistema

Sistema 2


Todos los sistemas poseen un propósito específico 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 también 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 información que tenemos ahora podemos implícitamente definir algunas cosas, como por ejemplo que el conjunto de sistemas que se encuentra en un medio ambiente determinado también 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 están compuestos de células y estas a su vez están compuestas de una serie de componentes

(membrana,

núcleo,

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 región y esta a un país etc., etc...


En las organizaciones la teoría de sistemas se aplica para poder realizar un análisis más específico 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 producción, etc.), esta separación permite analizar cada sub sección de forma más específica, adicionalmente esta separación permite que cada una de las secciones se especialice en su trabajo. Cuando realizamos un análisis de las organizaciones, nuestro trabajo

consiste

en

aplicar

esta

teoría

de

sistemas

y


complementarla con la orientación a objetos. De esta forma debemos definir un contexto para la organización (frontera del sistema), después debemos definir los objetos que están insertos en el sistema (componentes del sistema) y las relaciones que se establecen (relaciones del sistema).

Patrón ECB (Entity

–

Control

–

Boundary) Una forma relativamente simple de graficar la relación entre los elementos que componen un sistema es ocupar los gráficos que nos entrega el patrón ECB (Entity-Control-Boundary). Antes de mostrar los gráficos, es necesario entender qué es un patrón en el mundo del diseño y análisis de sistemas. Un patrón se puede definir como: “…una solución a un problema de diseño que aparece con frecuencia.” 3 O también como está definido en Wikipedia “Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces” interfaces ” . Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. 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 diseño 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


El patrón Entity Control Boundary (Entidad Control Frontera)5 se basa en la detección de cada uno de los componentes del modelo al momento de realizar el análisis, 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 (métodos o acciones con las cuales interactúan las entidades), los objetos de control (Control) son objetos que intermedian entre las entidades y las fronteras, están encargadas de orquestar la ejecución de comandos

que

vienen

definidos

desde

la

frontera.

La

representación gráfica de cada uno de los componentes es de la siguiente forma:

5

Se optó por mantener el nombre del patrón tal cual como fue definido para evitar la confusión a l leer otros apuntes.


Este gráfico nos permite entender de mejor forma como funciona un sistema asociándolo a la forma en que cada uno de las entidades interactúa con el sistema y como esta interacción gatilla la ejecución de una serie de funciones que no se ven desde afuera pero que deben ser analizadas para entender cómo funcionan las cosas. Analicemos el siguiente caso: supongamos que vas a sacar plata de un cajero automático. Si analizamos el proceso, vemos que existe una interacción de tu parte con la interfaz del cajero lo que gatilla alguna de las acciones que aparecen graficadas a continuación.


Fíjate que sólo analizamos las funciones básicas del cajero (sacar plata, solicitar el saldo, transferir fondos), pero ¿qué pasa si además necesitamos realizar un depósito en efectivo?, en ese caso el modelo cambia un poco y entran otras entidades y procesos a jugar.


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 solución para él, producto de un esfuerzo en conjunto, una buena planificación 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. Página 31 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Todo este proceso lo iremos documentando aplicando un conjunto de técnicas que veremos más adelante, sin embargo antes de entrar en aspectos técnicos deberemos conocer algunos conceptos básicos y realizar ciertos análisis simples, los cuales nos darán un punto de inicio, con falencias y omisión de buenas prácticas, pero que más adelante aprenderemos a corregir. Durante el desarrollo de la asignatura realizaremos mucho análisis, sin embargo la forma en que lo haremos no será al azar, aplicaremos una técnica 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 crédito, personas etc. Todo durante esta asignatura será considerado un objeto, sin embargo si queremos realizar un buen análisis sobre las situaciones que nos rodean debemos comprender qué objetos participan en ello, hagámoslo más simple y veámoslo a través de un ejemplo haciendo un pequeño análisis de un partido de futbol. Como podrás darte cuenta un partido de futbol no esta compuesto por un solo objeto, es más, si observamos con detención podremos concluir que existen muchos, enumeremos algunos:

1)22 1) 22 jugadores 2)Pelota 2) Pelota 3)Marcador 3) Marcador 4)arbitro 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 análisis que debemos realizar durante esta asignatura es más simple, ya que 22 jugadores es sólo la cantidad Página 32 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

de veces que existe el objeto jugador en la cancha, pero en realidad el objeto es el jugador, sólo podríamos 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 sólo, esto no significa que los 22 jugadores sean iguales, muy por el contrario, incluso el reglamento ordena que cada uno tenga un número de camiseta distinto dentro de su mismo equipo, también sabemos que cada uno tiene un nombre, un Rut, una posición etc. Con este pequeño análisis 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 (número de la camiseta)



Nombre



Posición



Goles anotados



Pases dados



Recuperaciones



Pie con que juega Página 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 sería realmente un partido de futbol? sabemos que con sólo 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 

Dar pase



Hacer gol



Recuperar el balón



Rodar



Rebotar

Pelota

Arbitro 

Dar tarjeta amarilla Página 34 de 152






Dar tarjeta roja



Iniciar partido



Finalizar partido

Marcador 

Incrementar en uno el gol de la visita



Incrementar en uno el gol del local

Como puedes ver todos los objetos tienen datos y algún comportamiento (una acción) que pueden realizar, sin embargo será posible que un jugador dé pases o haga goles si no existe una pelota y un compañero 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 Página 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 quién se asocian nos servirá como un buen comienzo para realizar un buen análisis posterior.

Definición 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 documentación 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 situación puede ser diagramada (dibujada) varias veces y con más de un tipo de diagrama, donde cada uno de ellos nos entrega un enfoque de la misma situación 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 común, UML consta de una semántica 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 estático y dinámico, el punto de vista estático nos muestra los Página 36 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

elementos y como ellos se relacionan para en su conjunto dar como resultado con éxito la implementación del sistema que se desea

construir.

La

vista

dinámica

en

cambio

modela

el

comportamiento de alguna parte del software en algún momento del futuro, con ello podremos aclarar más 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 orientación a objetos, es muy común utilizar una metodología llamada RUP (Rational Unified Process), que fue desarrollada por la empresa Rational, hoy h oy parte de IBM. El ciclo de vida es una implementación 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 según las necesidades específicas 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 elaboración



Fase de construcción



Fase de transición Página 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 deberían haber sido alcanzadas.

La fase de inicio: en esta fase se deben definir algunas características del proyecto a emprender (proyecto de tecnologías tecnologías de información) 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 organización, 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 elaboración: el propósito de la fase de elaboración es analizar el dominio del problema, establecer las bases de la tecnología a utilizar en el proyecto (hardware y software), desarrollar el plan del proyecto y eliminar los riesgos más altos del proyecto. Las decisiones respecto de la arquitectura deberán ser tomadas considerando una vista amplia y lo más completa del ámbito, funciones principales y requerimientos de rendimiento. La fase de elaboración es dónde 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.


En esta fase se hace el análisis 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 más adelante)



Captura

adicional

de

requerimientos

funcionales

y

no

funcionales y de cualquier requerimiento que no esté asociado con un caso de uso específico 

La descripción de la arquitectura del proyecto (hardware y

software) 

Una lista revisada de los riesgos



Una planificación de la construcción completa del proyecto,

incluyendo la planificación de las subtareas o subproyectos que vayas encontrando en cada iteración. 

Una especificación de los casos especificando los procesos a

realizar

La fase de construcción: durante la fase de construcción, todos los componentes y aplicaciones restantes son desarrolladas e integradas

al

producto,

y

todas

las

características

de

funcionamiento son testeadas de forma exhaustiva. La fase de construcción es un proceso de manufactura dónde 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 construcción de código y la configuración de la plataforma de hardware y software. En proyectos muy grandes, se deben realizar muchas iteraciones de construcción en un esfuerzo por dividir los casos de uso en partes que se puedan transformar en prototipos demostrables y construibles. Página 39 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Las salidas de la fase de construcción son una serie de productos que están listos para ser utilizados por el usuario final, como mínimo, están compuestos por: 

Una aplicación de software integrada en una plataforma de

servicios y hardware adecuado. 

Los manuales de usuario



Una descripción de la versión actual.

La fase de transición: el propósito de la fase de transición 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 corrección de parte de ellos. La fase de transición 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 estén completamente terminados). También es necesario que la documentación 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.



Conversión 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. Página 40 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Diagramas de Estructura. Diagrama de clases En el paradigma de programación 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 serán, 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 orientación a objeto todo lo construido en un software recibe esa denominación, cada uno de estos objetos tiene un

conjunto

de

características

(atributos),

estados

y

comportamientos que debemos conocer con anticipación antes de construir el software, con el fin de no cometer errores, de esta forma lo más 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 informática informática 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 número dos, el cual identificamos identificamos las asociaciones que 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 mínimo) y hasta 34 (el máximo) alumnos, a su vez un alumno puede tener desde 3 a 8 notas, de aquí se desprenden dos conceptos, el primero llamado asociación que es la vinculación de dos o más clases y la multiplicidad, que dice con cuantos objetos se asociará. Página 41 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

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, además 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 más utilizados y sirve para representar las relaciones

estáticas 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 vehículo, pero no lo hemos realizado aún, sólo definimos en un plano (clase) llamado auto, las características 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 vehículo eventualmente podría no tener ruedas, Sin embargo, ninguno de los dos objetos existe aún, vale decir que no hay ningún auto ni tampoco ruedas, es por esto que la relación es considerada

estática,

más

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 relación se vuelve realidad, pero fue posible sólo debido a que nuestro diagrama de clases nos guío para que pudiésemos construir un objeto con la capacidad de poder contener entre 0 y 4 ruedas. Página 42 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

En UML una clase es representada por un rectángulo que se encuentra sub dividido en 3 rectángulos, 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 características que deseas tenga tu objeto y en el último una lista con todos los comportamientos que tu futuro objeto podrá realizar. Veámoslo con un ejemplo, supongamos que deseas construir un automóvil, el primer paso es definir cuáles son los atributos, los comportamientos y estados que tiene un auto, para que los agrupemos de forma tal que generemos una clase llamada vehículo, entonces procedemos a ubicar el nombre de la clase en el primer rectángulo utilizando la primera letra con mayúsculas.

¡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 vehículo es probable que encontremos una gran Página 43 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

cantidad de ellos, pero según para que queramos el auto sólo serán útiles algunos, por ejemplo, si lo que deseas es utilizar el vehículo como parte de una carrera de autos, tal vez sólo nos baste con el nombre del piloto, el modelo del auto, su categoría, número (único en cada carrera) y la cantidad de vueltas que lleva.

El tercer rectángulo debe contener todos los comportamientos (acciones) que realizará el objeto que construirás a partir de esta clase, al igual que en el caso anterior, las acciones que pueden realizarse con un auto son más de las que necesitamos para este caso, es por eso que sólo seleccionaremos algunas, las cuales pueden ser: dar vuelta, pasar a Pitt, acelerar y frenar.


¡Listo! hemos diagramado como será nuestra clase vehículo, la que construiremos

más

adelante

utilizando

algún

lenguaje

de

programación, la cual podremos utilizar para construir todos los vehículos necesitemos.

Asociaciones. Un diagrama se dice que presenta las relaciones estáticas entre las clases con el fin de establecer qué clases se relacionarán y cual será su multiplicidad, en el caso anterior por ejemplo, el vehículo no es lo único que debemos considerar para que podamos decir que construimos un software que permita gestionar una carrera, así también tendremos que crear la clase pista con sus respectivos atributos y comportamientos siguiendo la misma técnica anterior, pero si construyo ambos objetos a partir de estas clases ¿servirían por separado?, pues no si lo queremos realizar es una carrera, es Página 45 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

por eso que debemos especificar una asociación entre ellas, de forma tal que cuando se construyan estos objetos también esté definida las asociaciones entre ellas, evitando así errores en la construcción, por ejemplo, para este caso es natural que la pista este asociada a los vehículos, para ello en el diagrama es necesario unirlas a ambas con una línea para representar esta asociación.

De esta forma sabemos que el vehículo esta asociado a la pista, pero aún nos queda determinar quien esta asociado con quien, ya que la línea no lo explica por si sola, pudiendo alguien pensar que un vehículo esta asociado a 3 pistas, lo que, al menos en lo que nosotros deseamos representar ahora no es correcto.


Multiplicidad. Uno a uno: esta relación se da cuando dos instancias de una clase tiene una asociación 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 relación se da cuando un objeto esta asociado a más de un objeto de otro tipo, un buen ejemplo es que una madre puede tener más uno o varios hijos.


Uno a una cantidad limitada de elementos: esta relación se da cuando un objeto puede estar asociada con una cantidad limite de otros elementos, cuyo limite puede encontrarse en el número mínimo o máximo, por ejemplo un curso para formarse necesita un mínimo de 15 alumnos, pero puede tener como máximo 34, también es posible que un objeto pueda asociarse con un mínimo de cero, en este caso se define que podría no existir una asociación si lo requiere, por ejemplo, si tratas de lanzarte en una una carrera presidencial necesitarás un mínimo de firmas que avalen tu candidatura, este proceso de recolección es una asociación de cero a muchos, ya que podrías no conseguir votos como podrías tener millones.

Mucho es a Muchos: Representa una asociación donde un objeto se asocia de uno a es a mucho en cualquier dirección, por ejemplo, un alumno tiene muchas asignaturas y una asignatura tiene muchos alumnos.


Diagrama de objeto Los diagramas de objetos son similares en su anotación al de diagrama de clases y son un complemento que se utiliza para enfatizar la relación que existe entre dos instancias de clases en un momento específico específico de tiempo, la diferencia de este diagrama es que no se presenta como una relación estática con su respectiva multiplicidad, a cambio, muestra cómo un objeto se relaciona con otros objetos luego de haberse construido, es decir un ejemplo de cómo se verá en el futuro en algún instante de su vida, ¿recuerdas el ejemplo del vehículo y su relación estática con una posible cantidad de cero a cuatro ruedas?, podríamos realizar un ejemplo de la relación con sus ruedas, pero para eso debemos tener objetos de tipo vehículo y algunas ruedas, así que el primer paso será construir un objeto de tipo vehículo según lo que definimos en nuestra clase, por si no lo recuerdas en ella especificamos que un vehículo tendría 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 informática un objeto es sólo una agrupación de información y acciones que se pueden realizar con ella, debido a esto se considera un objeto a una agrupación de valores dados a cada una de los atributos definidos en el diagrama de clases, por ejemplo si construimos un objeto auto de tipo vehículo bastará con darle un nombre, el cual podría 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 Página 49 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

el estado del vehículo pasará de apagado a encendido y si aceleras un cálculo matemático hará que la velocidad avance de cero a uno, como puedes darte cuenta la construcción de un objeto pasa por dar valores a sus atributos y al igual que las clases, los objetos también se pueden representar de la siguiente forma:

En lo más alto del rectángulo 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 próximo objeto no podrá llamarse miObjetoAuto. Esta representación es un ejemplo que ayuda a los programadores a entender mejor cómo se debe comportarán los objetos cuando sean construidos. También se dijo que un vehículo 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 cómo esa relación luce en algún momento de la vida de tu auto, habrá ocasiones en la que el vehículo tendrá todas las ruedas y otras ocasiones en las que tendrá 3 o menos. Así Página 50 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

puedes dibujar un diagrama para cada situación que consideres vale la pena aclarar, el siguiente ejemplo muestra un vehículo 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.


Diagrama de estructuras compuestas. La relación de asociación 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 relación deberá efectuarse. Para que sea más clara, este caso es principalmente dado en la relación de composición. Para que podamos comprender bien cómo funciona, vamos primero a aclarar qué es la composición en el diseño orientado a objetos: si miras a tu alrededor podrás ver que hay muchos objetos que se asocian con otros 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 relación es de 0 a N, vale decir que puede no tener como también podría tener varios, pero hay casos en la que dos objetos dependen uno del otro para formar un todo, si pensamos en el vehículo notaremos que está compuesto compuesto por carrocería, carrocería, motor y ruedas ruedas entre entre otros,

o

dicho de otra forma podemos decir que se encuentran asociados (tienen relación), pero esta relación en particular no es una relación de asociación, dado que

si bien el motor existe sin las

ruedas o viceversa, el auto no puede existir sin

motor ni

carrocería, esto es debido a que el vehículo esta compuesto de ellas, entonces, cuando hacemos un diagrama de clases podemos especificar que dicho vehículo se asocia con un motor y que el motor moverá cuatro ruedas, pero para los que no conocen bien el funcionamiento del auto podría ser difícil determinar que de las cuatro ruedas dos son las de adelante y dos las de atrás, dada esta dificultad, el diagrama de estructuras compuestas nos permite representar esta situación con un ejemplo, que representa algún Página 52 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

momento de la vida del objeto cuando se esté llevando a cabo la composición. Abordemos con más profundidad el ejemplo del vehículo para que veas como el diagrama ayuda a presentar información del funcionamiento interno que a simple vista no es posible apreciar, si en nuestro diagrama de clases, decimos que un auto tiene una relación con un mínimo y máximo de un motor, esto quiere decir debe tener uno de forma obligatoria y

una relación de cero a

cuatro rueda a menos que desees construir el troncomovil de Pedro Picapiedra. A pesar de que la información parece clara y completa, si analizamos más a fondo la información que se nos ha entregado comenzarán 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, sólo las de adelante o sólo las de atrás?, ¿o es un vehículo extraño 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 vinculación tiene las partes, cuáles se asocian con cuál y con cuántas, así podríamos 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 tracción que tenga el vehículo). Veamos un ejemplo de cómo será este diagrama: diagrama :


Diagramas de component componentes. es. El diagrama de componentes es un diagrama de alto nivel de abstracción, en él van modelados todos los componentes (elementos)

que

componen

un

software.

En

él

vamos

a

representar los componentes que van incluidos pero no funcionan, sin embargo si debemos especificar cuáles se comunicarán entre sí, tal vez la palabra componente sea algo que aún 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, imagínate con un nuevo puzzle en la mano recién comprado y llegas con él a casa para comenzar a armarlo, lo primero que notarás es que no viene armado donde sólo podrás Página 54 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

ver piezas sueltas que parecen no tener una conexión conexión entre sí, sin embargo en la mayoría de los puzzles en la tapa de la caja traen una

vista

del

puzzle

armado

¿podrías

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 cómo deben ensamblarse,

también notarás que cada pieza del puzzle esta

diseñada para comunicarse con alguna otra pieza, a esto en informática le llamamos interfaces, la cual expone una forma de comunicación 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 sólo para ensamblarse con una pieza en particular, en el software en cambio las interfaces expuestas sirven para conectarse con más de un componente, creando piezas que permitirán tener más de un uso. Un componente de software es una pieza que representa un conjunto de funcionalidades que dependerán del tipo de software va a realizar, por ejemplo, si pensamos en un software que va a permitir que los usuarios utilicen una página web, en la cual pueden chatear luego de registrarse y cumplir con ciertas condiciones, los componentes serían los siguientes:

Componente de negocio : un componente encargado de aplicar cálculos matemáticos o de verificación 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 número de celular respetando el formato solicitado. soli citado. Página 55 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Componente de páginas Web: el cual representará un conjunto de páginas web con las que el usuario va a interactuar.

Componente de chat : el cual va a representar un software más pequeño (conjunto de clases) que permitirá a los usuarios comunicarse entre si en tiempo real. El

siguiente

dibujo

muestra

cómo

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 página Web y entre los datos que solicitas está el Rut, es muy probable que desees que el Rut sea válido, 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 través de dicha interfaz, podría 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 Página 56 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

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 relación física que tendrán los componentes de software y hardware de un sistema, la mayoría de los programas de hoy están distribuidos en más 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 botón enviar?, pues al hacerlo los datos son tomados y son enviados a otra aplicación, la cual posiblemente esté incluso en otro país, este software es el encargado por medio de una

interfaz de recibir tu mensaje, ubicar al destinatario y enviárselo para que lo pueda leer. Como puedes ver la aplicación que instalas en tu computador de poco serviría 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 Página 57 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

servidor, nombre que se le puede aplicar a todo equipo que preste algún servicio, así como este ejemplo existen muchos, que incluso tienen componentes en más de dos equipos. Cuando se da este tipo de casos el diagrama de despliegue nos sirve para ubicar en que Hardware (en que equipo físico) debe ir cada componente para que los encargados de instalar el software sepan como hacerlo, por supuesto esto no es una receta de cocina, también 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 instalación, 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.


Diagrama de paquete. El diagrama de paquete sirve para formar una mejor visión de qué queremos construir, para ello lo divide en subsistemas más pequeños, la agrupación de los elementos se define en función de algo que ellos tengan en común 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 también 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 sería 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 también se da: imaginemos que estamos en un lugar donde arriendan internet y en cada equipo hay una aplicación que bloquea el teclado cuando recibe la orden desde el computador del encargado del lugar, adicionalmente para que los usuarios no puedan engañar 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 cuáles computadores están funcionado en la red para que puedan ser gestionados, pero si no encuentra ninguno la aplicación se cierra. Página 59 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Cuando llegue la noche y apagues todos los Pcs, al día siguiente no podrás 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 lógica anterior que refleja una dependencia de componentes puede ser aún peor dentro de la construcción del software, dado que mientras desarrollas un programa puedes cometer también un error de dependencia, dependencia, es decir, puede verse afectado por esto incluso mucho antes de que el programa concluya, ¿Cómo 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 información del disco en el que se quiere guardar el archivo va en el componente “creador “creador de archivos”, el cual para iniciarse requiere que mediante su interfaz el componente leer disco le entregue la información necesaria para escribir el archivo, en este caso el software nunca podrá instalarse, dado que hay dos componentes que están 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 líneas discontinuas entre aquellos que exista dependencia de algún tipo.


Diagramas de comportamiento. Diagrama de casos de uso. Este tipo de diagramas es esencialmente útil durante la etapa de análisis, es decir cuando estas comenzado a entender lo que necesita construir tu cliente, ya que su finalidad es describir los actores que interactúan con el software y los procesos que deben realizar. Un actor se considera a cualquier elemento que interactúa 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 tendrás un solo actor, (el encargado de agregar información a la agenda) y los procesos o casos de uso que realizará serán, 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


lógica que hay tras el proceso, la idea principal es sólo identificar los procesos y quién es el encargado de realizarlos. Este tipo de diagramas es muy útil para apoyar el proceso de análisis con tu cliente sobre lo que deseas que haga el software, debes considerar lo difícil que es para ellos explicar sus necesidades de programa y más aún todos los procesos que ellos mismos quieren realizar, donde olvidar alguno podría ser catastrófico, para el software, para tu cliente y para ti, ya que terminará agregándolo al final, trabajando más 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 también 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


Un actor es el encargado de ingresar información al software, es él quien a través de las interfases que tiene el sofware agrega la información que se desea almacenar y procesar, también es quien recibe la información procesada en el momento m omento 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 interactúan con el.

El siguiente ejemplo muestra cómo un actor interactúa con la agenda, especificando que el actor realiza una acción llamada agregar contacto. Según los requerimientos que desees modelar, puedes agregar más procesos dentro del mismo diagrama o dibujarlos por separado según 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


Diagrama de máquina de estados. Este diagrama muestra los estados por los que pasa un único objeto en respuesta a los eventos que este efectúa. Para que lo entendamos mejor primero veamos lo relativo a los estados, un estado es una condición en la que se encuentra un objeto en un determinado momento de su vida, esto sucede en cualquier orden de cosa, a tu alrededor podrás encontrar muchos ejemplos,

tu

mismo

concentrado, etc.

tienes

varios

estados:

alegre,

triste,

Sin embargo para que estos eventos vayan

cambiando debe suceder “algo” para que tu estado cambie. 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 podríamos llamar “ganar la lotería”, al igual que en este ejemplo, en el software los objetos que lo componen también 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 navegador no esta haciendo otra cosa que esperando que hagas algo, cuando escribas una dirección de internet y presiones el botón de búsqueda, habrás generado un evento en él, el cual podríamos llamar “buscar” este evento hará que el navegador pase del estado en el que se encontraba a un nuevo estado que podríamos llamar “mostrando página” en el que el navegador lee la información que le llega de internet para mostrársela al usuario, así puedes identificar varios Página 64 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

eventos que cambiarán el estado de tu navegador, por ejemplo si haces clic en el botón para minimizar o maximizar. Este

diagrama

presenta

el

estado

inicial

del

objeto

y va

representando con flechas acompañadas 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 l a siguiente figura:

En el diagrama de estados se debe definir un comienzo y un final, de esta forma podremos saber cuál es el estado inicial y cuál es el final. Para especificar el estado inicial se utiliza el siguiente símbolo:

Y para el estado final se debe utilizar:

Quedando el diagrama completo de la siguiente forma:


Se podría pensar que en un diagrama de estados el estado inicial y final podrán omitirse debido a que las flechas determina la dirección 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 podría pasar de estar divorciado a casado si vuelve a contraer matrimonio, sin embargo si vuelve a romper su relación 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 máquinas de estado, la diferencia principal es que en el diagrama de actividad no muestra los estados de los objetos si no que modela cómputos y flujos de trabajo, especificando el orden en el que se llevan a cabo, además 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. Página 66 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

En este diagrama se modelarán uno o más 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 ejecución de la primera

actividad,

cada

una

va

iniciándose

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 además modelar bifurcaciones dentro del diagrama, de esta forma según el resultado de la actividad que se ha ejecutado es posible tomar más de un camino, en otros casos y según se requiera también 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 vértices redondeados y en el centro el nombre de la actividad, también 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:


El orden en el que se ejecutarán son modelados con una flecha que índice que orden del flujo del proceso.

Si el término de una actividad puede dar inicio a más de una actividad dependiendo de alguna condición la bifurcación que allí se produce se representa con un rombo:

Diagramas de Interacción. Diagrama de secuencias. El diagrama de secuencia es un diagrama que muestra la forma en la que interactúan 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 petición, la mayoría de las veces con un diagrama de caso de uso es suficiente para comprender como interactúan las partes, sin embargo hay algunos casos en los que el proceso puede ser más complejo o requiera una explicación mayor, es por ello que el diagrama de secuencias viene casi siempre a partir de un caso de uso especifico.


Para representar los objetos en este diagrama UML utiliza rectángulos con sus nombres subrayados.

La diferencia es que abajo del objeto agregaremos una línea 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 acción que tarda algún 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

interacción entre las personas de un restaurante, veremos como interactúa el cliente, el mesero, el cocinero y el encargado de la caja, a través de este ejemplo veremos el orden en el que participa cada uno, también permite apreciar cuando una actividad comienza y cuando otras terminan. Página 69 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Como puedes ver en el diagrama, al seguir la línea de tiempo del cliente verás que se une con el mesero con una línea (una llamada) que simboliza el momento en el que se ordena la cena al mesero, a partir de ese momento ambas líneas tienen un rectángulo, lo cual significa que la llamada que hace la solicitud de comida activa a ambos (cliente y mesero) por lo cual los dos Página 70 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

generan una acción, 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 interacción entre el cliente y el mesero vuelve a quedar a la espera, tiempo después el cocinero hace una llamada al mesero (entrega), en el cual le entrega el alimento al mesero, cuando eso sucede sólo 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 estén celebrando que su hijo ahora es estudiante de educación 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 través del tiempo, prácticamente todos los objetos durante su vida van cambiando sus valores o estados y muchas veces estos cambios son producidos por factor que tiene relación con el tiempo, antes de continuar es bueno aclarar que el estado

la mayoría de las veces también produce un cambio en el valor del objeto, por ejemplo, si tienes un termómetro digital, Página 71 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

que acompaña 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 través 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 función 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:




Técnicas de recopilación y análisis de requerimientos. Técnicas 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 información relevante para ellos, la cual por lo general va agrupada y ordenada según 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 caída 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 sueños y lo mejor de todo es que el vehículo será como tu lo especifiques, como muchos que lean este libro sus requerimientos serán mas o menos así: 

Llantas aro 17’ .



Deportivo.



Motor muy poderoso.



De algún color que te guste.


Ahora supongamos que ha pasado algún tiempo, y he venido a entregar el vehículo, aquel que esperas con muchas ansias y medida que ves que lo van bajando del camión estas cada vez más contento cuando descubres que tiene unas llantas preciosas, que el color es tal y cual lo imaginaste, en la cola del vehículo 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 vehículo, una vez adentro sin mirar más pones la llave, haces contacto y escuchas como ruge el motor mientras te imaginas la expresión 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 atrás pero no encuentras nada, a tu derecha notas la ausencia de una caja de cambios, de aire acondicionado, de la tracción de las ruedas ni hablar, apenas el motor esta conectado al sistema de arranque, no hay tacómetro, no hay luces y así sigue, muy enojado bajas del vehículo y encaras al encargado, el cual mira el documento en el que especificaste lo que necesitabas, hace una revisión y te das cuenta que todo lo que pediste esta ahí y que en realidad reclamas por lo que no hay que jamás pediste, ¿Quién es el culpable? ¿El mecánico? ¿Tú por no especificar bien lo que necesitas? Y la respuesta es… ambos, el e l problema que aquí hubo es de comunicación, a pesar de que da la sensación es que es más culpable el mecánico es por que tu sabes los comportamientos que un vehículo debiese tener, pero, ¿que pasa cuando tratamos de construir algo que el cliente ni el constructor conocen? Aquí es cuando el asunto se pone difícil, en el análisis de requerimientos Página 76 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

esta situación se da mucho más habitual de lo que perece, la razón 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 jamás 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

necesidades)

en

la

desde

que

obtenemos

nuestro

cliente,

los en

requerimientos la

que

(las

mediante

conversaciones, formularios, encuestas u otras formas obtenemos la información sobre los procesos del negocio que desean el apoyo de software, es muy común que se confundan la palabra requisito y requerimiento, sin embargo en informática no debieses ser utilizadas de forma indistinta, los requerimientos son la palabra más común 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 algún lugar existe una persona con un problema o necesidad de mejora para la cual necesita una solución que pasa principalmente por un conjunto de herramientas informáticas que apoye uno o más 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 informático

y lo que realmente la empresa

necesita de ellos para mejorar o solucionar una carencia estamos hablando entonces de requerimientos. Página 77 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Pressman dice

“Ingeniería de Requerimientos ayuda a los

ingenieros de software a entender mejor el problema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software”. El proceso de toma de requerimiento, puede ser una tarea difícil y que requiere trabajo y una habilidad para tratar y comprender a las personas con las que se entrevista, muchas personas siempre consideraron al informático como un ermitaño 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 solución, por lo general durante la toma de requerimientos descubrirás 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 visión como conjunto, lo que provocará que escucharás 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 según a quien se entrevista y en muchos casos descubrirás 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. Página 78 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Para lidiar con esto hoy aprenderemos algunas técnicas de extracción de requerimientos desde el cliente, las cuales son: entrevista, encuesta y observación directa, más adelante en asignaturas posteriores verás metodologías más elaboradas sobre la captura de requerimientos, las cuales consisten en un conjunto de técnicas, sin embargo en este semestre veremos tres de las formas mas naturales de comunicación existentes para extraer información.

Entrevista. La entrevista es posiblemente la forma más natural y rápida de comunicación con una persona, en informática la entrevista debe ir enfocada a aquellas personas que más conocen sobre los procesos de la organización y a las personas que utilizarán el sistema, estas entrevistas pueden ser individuales o grupales y se recomienda hacerlas cada cierto tiempo, ya que verás 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 información más 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 según lo que el encuestado haya dado como respuestas, las encuestas puede llevar preguntas abiertas o de selección múltiple, en la que los encuestados deberán seleccionar una alternativa, esta técnica es buena cuando lo que Página 79 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

deseas es obtener información puntual desde un grupo grande de personas que no pueden reunirse ya sea por horario o por limitaciones de espacio.

Observación directa. Esta técnica consiste en que el encargado de la toma de requerimientos observa las personas mientras realizan su trabajo, de esta forma se conoce cuáles son los procedimientos que se realizan, quiénes son los encargados de hacerlos y cuál es el orden en el que se ejecuta.

Definición de actividades. Una vez los requerimientos han sido extraídos del cliente pasaremos a una nueva etapa en la cual tomaremos cada uno de los procesos del cliente y lo dividiremos en actividades más pequeñas, las cuales juntas y en algún orden en particular dan como resultado alguna acción que deseamos convertir en software más adelante, por ejemplo, si existe un proceso en el que los clientes compran utilizando el método 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 página 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 número de la tarjeta bancaria con la que se desea realizar dicho pago, la información ingresada deberá enviarse al banco que

corresponde, sólo sólo si esta habilitada habilitada y el

monto disponible para compra supera el valor del producto, entonces se genera la venta, esta venta es registrada por el Página 80 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

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 página 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 página antes de que el cliente navegue por ellos, entonces, alguien debe ingresar la información de los productos, subir sus fotos, establecer el valor y agregarlos a la categoría que corresponde, adicionalmente especificar algún tipo de descuento si lo hubiese. Si hacemos un mejor análisis de la situación notarás que hace un momento acordamos que cuando un cliente realiza una compra la información 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 debía salir de su hogar para adquirir los productos a una cómoda, rápida y ágil forma de comprar sin salir de su hogar, la segunda razón es que al tener la información de las ventas la organización 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 más vendidos, las fechas de mayor compra, lo que alertará aquellas temporadas en las que hay que tener una Página 81 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

mayor cantidad de stock de productos, estos informes se generarán de forma automática 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, más adelante con un mejor análisis veremos que lo aquí descrito no es sólo una pequeña parte, que por ahora obviaremos.

Relación entre las actividades y los actores. Del análisis 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 quién o quiénes son los encargados de cada uno de ellos, a cada elemento (usualmente personas) que interactúen con nuestro software lo llamaremos un actor, por ejemplo y siguiendo con el caso anterior la persona encargada de la compra a través 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 permitirán tomar decisiones a una persona con un rol más gerencial, con esto no sólo logamos identificar lo que los actores deben hacer, sino que también lo que no deben hacer.


Análisis básico de los requerimientos para la realización de un listado de actividades. En los procesos de análisis de requerimientos siempre se determinan necesidades múltiples para las organizaciones que se están estudiando. Es necesario por lo tanto que determines un ámbito de acción para tu proyecto, y de esta forma dar una solución acotada y precisa. Lo primero que debes tener en cuenta es que las organizaciones siempre tienen una razón de ser y esta razón de ser determina las actividades que la organización realiza. Por un tema de complejidad de las organizaciones, poseen diferentes procesos que dan soporte a la realización del quehacer de la organización y adicionalmente otra serie de actividades que si bien no son parte del quehacer de la organización, estas sirven de soporte a estos procesos principales. Por ejemplo, el propósito de la panadería 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 más compleja sea la organización, más complejas serán las actividades de soporte y más específicas. Cuando estás analizando requerimientos, es importante que puedas agrupar las actividades que estés analizando. Este agrupamiento de actividades permitirá que analices los procesos y las necesidades de la organización de forma mucho más eficiente (aplicando la teoría de sistemas). Una vez que hayas agrupado los Página 83 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

requerimientos en relación 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 organización como parte de su quehacer. Debes considerar que para cualquier organización los requerimientos principales a considerar son aquellos que tienen que ver con el quehacer de la organización, es decir con los procesos que hacen que la organización funcione. Con todos estos antecedentes a la mano es posible ahora realizar un listado de los principales requerimientos y ordenarlos en función de las principales necesidades de la organización. 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 atención al momento de planificar y desarrollar el proyecto.


Diagrama de flujo de datos (Agile Unified Process). Los diagramas de flujo de datos (DFD) fueron herramientas muy utilizadas por la metodología estructurada como una forma de representar los flujos de datos entre las entidades externas y el sistema que se estaba analizando. Adicionalmente a este análisis los DFD permiten mostrar el flujo de datos entre cada uno de los procesos que componen el sistema y su s u almacenamiento lógico. Para

construir

estos

diagramas

existen

cuatro

elementos

principales: Los rectángulos representan entidades externas, las cuales son orígenes o destinos de los datos, es decir son todas aquellas cosas, personas o sistemas que aportan o reciben datos como resultado del proceso.


Los rectángulos 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 rectángulo con el lado izquierdo abierto representa un almacén 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 generación de estos diagramas consiste en definir un escenario para con esa información 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 continuación defines los procesos que se realizan en el Página 86 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

sistema y unes a estas entidades con los procesos. Recuerda que esta unión entre procesos y entidades no se realiza al azar sino que es fruto de un proceso de análisis en el cual se identifica si la entidad entrega o recibe datos de un proceso en particular, para muestra el siguiente ejemplo.

Fíjate que en el contexto del sistema de compra en línea, el proceso de validación de usuario está relacionado con la entidad usuario que es la que envía los datos y estos se buscan en el almacén de datos del usuario, estos datos son analizados por el proceso de validación 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 relación existente entre cada uno de los elementos del diagrama mediante los flujos de datos da tos que son los conectores.

Entidad Proceso Almacén Entidad

NO

SI

NO

Proceso

SI

SI

SI

Almacén

NO

SI

NO


Utilizando esta tabla anterior, podemos definir algunos ejemplos de cosas que jamás podrías 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 análisis.

En el ejemplo anterior, las entidades nunca pueden enviar un flujo de datos directamente al almacén, pues siempre los datos al menos pasan por un proceso de validación antes de ser guardados en un almacén de datos.


Como puedes ver los almacenes de datos tampoco se pueden relacionar, pues al ser sólo repositorios, ellos no pueden ejecutar ninguna acción, sólo 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 válidos.


Estos son ejemplos no válidos.

b) Todos los procesos deben modificar los datos de entrada produciendo nuevas formas de datos de salida. Algunos Alg unos procesos comunes son validaciones, ordenamientos, búsquedas, etc. c) Cada uno de los almacenes de datos debe tener al menos un flujo de datos, ya sea de entrada, salida o actualización 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 relación entre las entidades, los procesos y los almacenes de datos utilizando para esto los flujos de datos, también es necesario mantener el control respecto a la complejidad de los procesos representados. Utilizando conceptos de teoría de sistemas, trata siempre de mantener los diagramas d iagramas lo más 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. Página 90 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Diagrama de procesos (BPMN 2.0) Cuando estés trabajando, muchas veces tendrás que realizar análisis de sistemas que son muy complejos. Una herramienta que te permite representar gráficamente los sistemas es utilizando un diagrama que se llama BPMN, Business Process Model and Notation (BPMN) es decir Modelo de Procesos de Negocio y Notación. Esta es una notación gráfica que describe los pasos que se realizan en un proceso. Esta notación ha sido especialmente diseñada para coordinar la secuencia de los procesos y los mensajes que fluyen entre los participantes de las diferentes actividades. BPD (Bussines Process Diagram) o diagrama de procesos de negocio es un diagrama diseñado para representar gráficamente la secuencia de todas las actividades que ocurren durante un proceso, basado en la técnica de diagrama de flujo incluye además toda la información que se considera necesaria para el análisis. BPD

es

analistas,

un

diagrama

quienes

diseñado

diseñan,

para

controlan

ser

usado

por

los

y gestionan procesos.

Dentro de un Diagrama de Procesos de Negocio BPD se utiliza un conjunto de elementos gráficos, agrupados en categorías, que permite el fácil desarrollo de diagramas simples y de fácil comprensión. El modelado de proceso es la captura de una secuencia de actividades de negocio, y de la información de soporte. Los procesos de negocio describen la manera cómo una empresa alcanza sus objetivos. Es decir acá lo que analizamos y tratamos Página 91 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

de graficar son los procesos de negocio. Recuerda que los procesos de negocio son todas las actividades que realiza una organización y que tienen que ver con la gestión 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 extensión del anterior, y suficiente

manejan información adicional adiciona l pero no

para definir completamente el funcionamiento

actual. 

Modelos de proceso. Son diagramas de flujo extendido con suficiente información para que el proceso pueda ser analizado, simulado, y/o ejecutado

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 condición o requisito previo. Página 92 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Un proceso o una aplicación 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 envío o la recepción 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 líneas 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 condición o requisito previo. Representa un evento de fin que termina con un mensaje.


Las actividades son la representación de un trabajo que se realiza en el sistema analizado. Se representa con un rectángulo redondeado. Una actividad puede ser atómica o compuesta. Los tipos de actividades son: Una tarea es una actividad atómica 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

dentro

de

es

un

conjunto

de

actividades

incluidas

un proceso. Puede descomponerse en diferentes

niveles de detalle denominadas tareas. Se representa con un símbolo de suma en la parte central inferior de la figura. A continuación se presentan los tipos de subprocesos: Una tarea contraída 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 más bajo de detalle.


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 condición del negocio. La compuerta compleja representa un punto donde aparecen varios caminos y sólo uno de ellos es válido.


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 ejecución de las actividades. Los tipos de conectores son: Conector de secuencia, muestra el orden de los eventos,

actividades

y

decisiones

que

se

realizan dentro del proceso. Conector de mensaje, indica el flujo de mensaje entra las distintas entidades de los procesos. Conector

de

asociación,

permite

asociar

diferentes artefactos con objetos de flujo.


Los swimlanes o canales son un mecanismo empleado para organizar actividades en categorías separadas visualmente, el

fin

de

ilustrar

diferentes

capacidades

funcionales

con o

responsabilidades.

Representa a los actores externos o internos con los cuales interactúa un proceso, contiene un conjunto de actividades asociadas a su rol.

Los artefactos son objetos gráficos que proveen información 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 agrupación se puede realizar con propósitos de documentación o de análisis.

Las anotaciones, son un mecanismo para entregar información adicional.


Acá vemos un ejemplo de un proceso de compra y venta de productos con el posterior despacho de este producto por parte del vendedor. Fíjate que la representación de los procesos se hace cada una en su propio canal o swimline para separar las tareas que están asociadas a cada uno de los roles en el proceso.



Diagrama de casos de uso. El diagrama de casos de uso, es el primer diagrama que aprenderás a crear en profundidad, este diagrama te permitirá analizar los problemas que vayas estudiando de una manera gráfica que es mucho más cercana a la realidad que conoces. Este diagrama permite a los analistas tener una visión primitiva respecto de cómo funciona o debería funcionar el sistema que se está analizando y ver cómo 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 propósito común, 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 información. Recuerda que los sistemas de información son un conjunto de normas y procedimiento que definen el cuándo, dónde 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 monótonos o que lleven mucho tiempo y que generalmente están asociados a la gestión de los datos. Por lo tanto siempre recuerda que un sistema de información no es sólo software o sólo hardware es un todo mucho más complejo. También debes tener la seguridad que nunca se construye el uno sin el otro (o al menos no se recomienda) pues están relacionados y el uno sin el otro, provoca que el sistema quede incompleto.


Te preguntarás ¿Y cómo 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, básicamente debes aprender a resolver problemas como si fueras un detective, es decir, recopilar información 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 información respecto a como funcionan los sistemas que estás 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 función, ahora dado que se puede malinterpretar pues es sólo una representación gráfica 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 más cerebros piensan más que uno, adicionalmente si no puedes verbalizar una idea o explicarla en palabras o texto, significa que tu cerebro aún 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 Página 101 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

aplicando tecnología y todo el conocimiento que vayas adquiriendo durante tu carrera. Básicamente los sistemas de información se encargan de realizar cuatro procesos: 

Captura de datos.



Almacenamiento.



Procesamiento.



Entregar de resultados.

Todos los sistemas de información realizan básicamente estos cuatro procesos desde el procesador de texto hasta los video juegos

pasando

por

software

empresarial

y

páginas

web.

Básicamente lo que hacemos es dar soluciones basándonos en una combinación de hardware, software y mucho análisis respecto a los procesos que realiza la organización 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?, ¿Quién define los procesos de la organización?, ¿Es lo mismo un dato que información?, ¿El fin del mundo será el 2012?, ¿Cómo es posible que los vampiros que son seres de la noche puedan caminar de día en la película Crepúsculo?, estas y otras preguntas las responderemos durante el desarrollo de este y los siguientes capítulos. La comunicación 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 interpretación de lo que está escuchando depende de muchos factores. Como nuestro Página 102 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

objetivo al construir diagramas es poder transformarlos en software o en una solución informática, 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 fácil de corregir. Las organizaciones requieren gestionar la información de sus procesos para poder tomar decisiones respecto a como están haciendo las cosas para continuar haciéndolo bien o para mejorar lo que están haciendo mal. Por ejemplo, si fabricamos 3000 litros de helados en marzo y vendemos pocos litros en invierno lo más probable es que el próximo año ajustemos la cuota de producción en función de las ventas del año anterior, para no tener que botar 2999 litros como la temporada anterior. Este tipo de decisiones están 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 visión de los componentes de un sistema (personas, reglas y procedimientos) y cómo 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 relación entre los procesos y las personas en un momento específico o como se suele decir, en un escenario particular. Página 103 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

En los casos de uso, el escenario se define como un momento específico en la vida de un proceso que esta siendo analizado, esta separación se hace para poder simplificar el análisis de los procesos. Por ejemplo, cuando compras un producto en una multitienda, se producen muchos procesos de traspaso de información, por ejemplo cuando vas a comprar un producto el proceso comienza cuando tu buscas ropa por modelo, marca, color, o precio, en función de estos parámetros (todos, una combinación de ellos o sólo uno), tú seleccionas un artículo, te acercas al vendedor, vas a la caja y cancelas, ya sea con tarjeta de crédito, con efectivo o con cheque y luego de la impresión de los comprobantes de la venta, te puedes llevar el artículo. Si te fijas este es un escenario del proceso, pero ¿Qué pasa si el artículo 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 artículo 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 más 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 misión 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 devolución o un cambio, por lo tanto es necesario establecer el modelo en función del escenario específico que se está analizando.


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 interactúan 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 organización también 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

representación de varias personas o de ninguna en particular. particul ar. Los actores se representan como una persona dibujada con palitos, como cuando éramos pequeños y aún no aprendíamos a dibujar.


Fíjate que el actor posee un nombre que define su rol, es decir el papel que le corresponde realizar en ese escenario específico, este rol del usuario esta definido por el escenario, así en un sistema llamado

“casa”,

probablemente

desempeñes

alguno

de

los

siguientes roles: “hermano(a)”, pololo(a), hijo(a), esposo(a), papa o mamá, etc., fíjate que es posible que tú cumplas más de un rol, por ejemplo, hermana, polola, mamá dentro del mismo sistema, pero las acciones que realizas y como las realizas son distintas en función 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 estás 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 interactúas 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 función 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 análisis 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 específico. De esta forma si analizamos las tareas que debe realizar un vendedor para poder vender algún artículo en una multitienda (fíjate que el problema se circunscribe a ese escenario en particular), este debe poder consultar por los precios de los productos, vender uno o más Página 106 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

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 aproximación inicial al problema por lo que las etapas pueden cambiar, así que si descubres más, siéntete libre de agregarlas . Una vez que determines las tareas que debe hacer el actor, estas deben ser analizadas pues a veces este análisis inicial puede llevar a una confusión. Realicemos el siguiente análisis, supongamos que tenemos la siguiente definición de procesos: “Necesitamos representar un sistema que permita a los médicos de una clínica dental, definir sus horarios de atención y a los clientes de la clínica el registrarse y el solicitar hora a través de una página web” Pese a que esta es una definición de procesos extremadamente simple, ya podemos definir algunas características iniciales para el modelo y basándonos en estas características 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, médico y paciente.


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: Médico: Define su horario de atención Usuario: Registrarse, solicitar hora. Si te fijas la definición de los casos de uso define el qué, pero no el cómo, pues aún no interesa, recuerda que estamos primero definiendo qué es lo que hay que hacer, concéntrate en este punto, pues si bien la tecnología es importante antes de identificar y solucionar el problema, hay que saber qué es lo que necesitamos Página 108 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

que el sistema haga. Un punto importantísimo 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 organización necesita registrar como parte del proceso para la toma de decisiones, por lo tanto el diagrama final quedaría de la siguiente forma:


Relaciones. Las relaciones permiten establecer la forma en que los actores y los casos de uso se comunican y adicionalmente muestra la relación existente entre los casos de uso. Existen cuatro tipos de relaciones en los diagramas de casos de uso,

asociación

de

comunicación,

extensión,

inclusión

y

generalización. La relación de asociación de comunicación 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 relación entre el actor y el caso de uso nos indica qué funcionalidad del sistema será utilizada por cada uno de los actores que están representados en ese escenario particular. En la relación de inclusión, la que graficamos con una línea segmentada que une dos casos de uso más una flecha que indica la dirección de la relación, estamos representando dos casos de uso que son complementarios. En la relación de inclusión, un caso de uso necesita de otro caso de uso para poder realizar una operación en particular. Recuerda que en la inclusión el resultado del caso de uso incluido afecta el caso de uso que incluye por lo tanto están íntimamente relacionados los resultados de ambos. Este

tipo

de

relaciones

se

grafica

utilizando

la

palabra

<> sobre la línea que muestra la relación.


En la imagen anterior fíjate que el caso de uso denominado “login”, incluye su funcionalidad al caso de uso “buscar usuario”, que también 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 ejecución 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”

no

están completos sin la la utilización de “buscar usuario”, pues de este segundo caso de uso depende el resultado del primero. Cuando se trata de relaciones de extensión las cuales se grafican con la palabra <>, también se puede analizar la relación como si los dos casos de uso fueran sólo uno. Pero una de las diferencias básicas es que hay situaciones en que el caso de uso de extensión 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 <> es necesario que ocurra el caso incluido sólo para satisfacer el objetivo del caso de uso base. Un ejemplo de lo anterior lo podemos analizar en el siguiente ejemplo: Página 111 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

En el ejemplo anterior el caso de uso “servir café” extiende café” extiende hacia el caso de uso “agregar azúcar”, fíjate que para “servir café” no es siempre necesario el “agregar azúcar”, 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 relación que se establece en los casos de uso es la relación de generalización, la cual se dibuja en el diagrama mediante una flecha con sentido, la punta de flecha a diferencia de los otros tipos de relación a parte se rellena. La generalización está asociada al concepto de especialización, en esta situación un caso de uso puede dar origen a una forma especializada de realizar una acción 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, Página 112 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

por lo tanto, como ambos son una forma de pagar, podemos definir que la generalización del proceso es el pago el cual hereda su comportamiento a los otros casos de uso.

Identificación del contexto en el que participan los actores. Uno de los puntos principales para poder realizar un buen análisis de la situación 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 mecánico recibe vehículos para ser reparados, los clientes que desean atender su vehículo, primero deben registrar sus datos y los del vehículo, adicionalmente se registra el motivo de la visita en el taller y se procede a la evaluación preliminar del vehículo. Junto con esto se hace una cotización basándose en la detección de los problemas que presenta el vehículo. Una vez se recibe esa cotización y el cliente da la autorización para ejecutar el trabajo, este es asignado a uno o más técnicos mecánicos los cuales proceden a la ejecución del trabajo que está asociado a su especialidad (falla mecánica del motor, amortiguación, sistema eléctrico, mantención periódica, etc.). El proceso se lleva cabo por cada uno de los técnicos y es revisado por un jefe de taller el cual fiscaliza la correcta ejecución del trabajo. Una vez que el trabajo completo es realizado, el vehículo es entregado al cliente.”. Página 113 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Identificación de los roles. El proceso de identificación de los actores, pasa por determinar, personas o sistemas que entreguen información al sistema o reciban información de este (entes pasivos), ahora tanto el envío como la recepción de la información está asociada al contexto del problema. Si te fijas en el enunciado del ejercicio anterior, nuestro contexto se remite a la recepción del vehículo, el diagnóstico del problema, la asignación de tareas, el proceso de verificación de la ejecución de las tareas y la devolución del vehículo reparado, jamás 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 sólo el de la definición de procesos. Es posible que un análisis posterior nos pudiera mostrar que existe relación con otras áreas pero siempre es necesario determinar las fronteras del sistema para realizar un análisis 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 envían o reciben información desde y hacia el sistema. Recuerda que cuando hablamos de un sistema en el análisis 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 definición de procesos del ejemplo podemos detectar algunos actores iniciales: Cliente: quien lleva el auto. Recepcionista: quien recibe y anota los datos del vehículo y el cliente. Página 114 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Técnico mecánico: quien recibe la información de las tareas que debe realizar asociadas a un vehículo. Jefe de taller: Es el que revisa que el trabajo se haya realizado de forma correcta. Fíjate que podemos hacer un análisis un poco más avanzado del proceso y podríamos pensar en lo siguiente ¿Qué pasa si el recepcionista, el técnico 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 estén interactuando con el sistema, lo que nos interesa es encontrar los roles que ellos están 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 técnico mecánico le podrían eventualmente corresponder realizar más tareas que las definidas (recibe las tareas realizadas). Utilizando esta misma línea 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 mecánicos, además si te fijas el cliente puede no sólo traer el vehículo, sino que además en otro contexto debe pagar por el servicio.

Definición de los actores. Una vez que defines los roles en la organización o en el sistema que estas analizando, es necesario que definamos los actores asociados a los roles que has encontrado, para esta identificación, debes poner especial atención en que pueden existir varios actores Página 115 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

que estén asociados a un mismo rol, por ejemplo en el análisis de nuestro caso, podríamos encontrar a varios mecánicos, pero sólo registramos uno. Ahora esto nos podría 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 función 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 mecánico puede realizar más 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 están cumpliendo es el mismo para todos.

Definición de los casos de uso. Un caso de uso se entiende como una acción con la cual interactúa un actor, esta acción es parte del sistema que estamos analizando. Esta acción se puede descomponer en un conjunto de acciones distintas, pero eso es parte de análisis posteriores. Recuerda que los casos de uso pueden recibir información del actor o pueden entregar información al actor. En cada uno de esos casos el proceso siempre tiene un objetivo dentro del proceso general de la organización. Recuerda que cada uno de los casos de uso que logres identificar están asociados al propósito del sistema que estás analizando. Así, en nuestro ejemplo podemos identificar las acciones que debe realizar cada uno de los usuarios como muestran las siguientes imágenes.


Definición 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 análisis de la descripción de los procesos. Otra forma de realizar este análisis 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 Página 117 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

nos podemos hacer una serie de preguntas relativas al sistema que estamos analizando. ¿Cuáles son las tareas que debe realizar un actor? ¿Qué información 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

combinación 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.


Definición 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 gráfica 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.

Comunicación. Es el tipo de relación que se establece entre el usuario y el caso de uso, se define con una línea continua que une al actor y el caso de uso.

Inclusión. La relación de inclusión 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 acción. Cuando el caso de uso incluye a otro, el caso incluido sirve para complementar la acción del primer caso de uso, vale decir, sin el caos de uso incluido, el caso de uso inicial no puede completar su tarea. Página 119 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Extensión. En la relación de extensión el caso de uso extendido, completa su acción 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 nec esario siempre.


Generalización. La relación de generalización en los casos cas os de uso permite definir un caso de uso especializado para una situación en particular, es decir existe un caso de uso específico que q ue realiza una acción, pero también un caso de uso que se especializa en realizar un proceso en particular.

Documentación de los casos de uso. La documentación de los casos de uso es un proceso que permite aumentar el grado de comprensión de los procesos asociados a los casos de uso. Esta documentación está orientada a servir como complemento al diagrama pues el diagrama muchas veces no permite representar con claridad los procesos ni cómo estos se implementan. Adicionalmente la documentación es una guía práctica para que los desarrolladores de las aplicaciones a futuro puedan implementar de mejor forma la funcionalidad de la aplicación. Otro aporte fundamental de la documentación es el hecho de que también puede ser revisada por la contraparte


cliente y se podrá trabajar con ellos en la definición correcta de los procesos acá descritos. Existen muchos formatos para realizar la documentación de los casos de uso, vamos a usar un formato básico pero completo para poder establecer de la mejor forma la descripción de los casos de uso. Nuestro documento constará de las siguientes partes:

Definición del caso de uso. En esta parte se define el nombre del caso de uso, su identificador y se da un breve descripción del caso de uso, fundamentalmente la descripción está orientada a definir el proceso general que se está describiendo.

Flujo Normal. La sección 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 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 cómo se comporta el sistema que estamos analizando cuando el proceso no llega a buen puerto. La realización de este tipo de análisis es muy importante pues muchas veces el flujo alterno puede definir una regla importante respecto al flujo del proceso.


Pre-condiciones. Las precondiciones permiten formalizar todas aquellas condiciones de deben considerarse como requisitos para la ejecución 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 sección. Para clarificar el concepto, fíjate en la definición 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 estén completos y que la información 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, asignándole los permisos necesarios. Página 123 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

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 envía un correo el cual contiene un hipervínculo que debe ser seguido para validar el registro. • Excepciones: 1. El usuario cancela el registro r egistro 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.



Diagrama estático de clases. Introducción al diagrama estático de clases. Como se vio en los capítulos anteriores, el mundo de los diagramas UML es bastante extenso y cada diagrama tiene un propósito específico y entre ellos muchas veces se complementan para entregar información más específica 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 interactúan entre si, es el diagrama estático de clases. Piensa en lo siguiente, la mayoría de las cosas que conocemos están formadas por varias partes las cuales se complementan para realizar una tarea específica, la cual no podría 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, estás interactuando con el control remoto (otro objeto) el cual envía una señal al televisor (otro objeto) y finalmente el televisor se enciende.


Si analizas el comportamiento que tienen los objetos, podemos definir que el objeto persona envía un mensaje al objeto control remoto que a su vez se comunica con el objeto televisor para realizar una acción. 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 estático de clases es el poder mostrar la forma en que los objetos se comunican y relacionan.

Utilidad del diagrama estático de clases. El diagrama estático de clases como lo vimos, permite obtener información referente a 2 vistas en particular. La primera dice relación con la forma en que los objetos se componen, es decir sus características 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 estática del problema el cual no va a cambiar con el tiempo. Este diagrama adicionalmente nos va a permitir avanzar en una concepción más acabada de cómo todos los procesos que determinamos en el diagrama de casos de uso se van a convertir en una aplicación de software o en un proyecto de algún otro tipo (recuerda que una de las ventajas de UML es que no sólo sirve para diseñar software). Cabe señalar que el diagrama estático de clases no hace sólo referencia a como las distintas partes del software interactúan sino que también puede incluir hardware, y todos los otros componentes que forman un proyecto informático.


En cursos más avanzados en la línea de programación verás el cómo poder interpretar este diagrama estático de clases y convertirlo en una aplicación o al menos en una parte de ella. Una de las ventajas de la orientación a objetos es que las aplicaciones de software se pueden construir por partes sin que esto afecte el total de la aplicación y adicionalmente esta parte que construyes la puedes reutilizar en otros proyectos.

Componentess del diagrama estático de Componente clases. Para comprender cómo podemos construir un diagrama estático de clases primero vamos a conocer los distintos componentes de este diagrama y que representan, además de cómo se relacionan unos con otros y los diferentes significados que estos van a tomar en función 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 construcción de un edificio o al diseño que hace un ingeniero en electrónica 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 construcción física basándonos en las especificaciones de una clase. A continuación se define formalmente el concepto de clases y objetos.


“descripción generalizada (por ejemplo, una plantilla, un patrón o un prototipo) que describe una colección de objetos similares” 7 “descriptor de un conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y comportamiento” 8 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 definición de las características y las acciones que realizarán los objetos.

Para lograr este cometido

primero debes tener en claro el modelo que quieres representar. Recuerda que una de las partes más complejas del desarrollo de proyectos de tecnologías de información 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 podría servir, el bunker para el apocalipsis zombi tiene otras características que son necesarias, por ejemplo muchas motosierras, y por lo tanto suficiente combustible, y un sin número de armas corto punzantes (machetes, espadas, katanas, etc.) que serán 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 público tiene funciones pensadas para diferentes usuarios (pasajeros, pasajeros con capacidades de desplazamiento limitadas y choferes). Cada 7

Ingeniería del Software: Un enfoque práctico, Roger S. Pressman, McGraw-Hill/Interamericana de España, S.A.U. © 2002, ISBN 84-481-3214-9 8 El Lenguaje Unificado de Modelado. Manual de Referencia, Pearson Educación, S.A. © 2000, ISBN 84-7829-037-0


uno de ellos utiliza funcionalidades distintas del sistema, por ejemplo sólo 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 capítulo anterior). ¿y que paso con las clases? Cuando logras establecer el comportamiento del sistema y los usuarios que interactúan con el sistema analizado, entonces estás en condiciones de pasar a la siguiente etapa del proceso de análisis, que corresponde a tratar de hacer una agrupación 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 habías 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 interactúan 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 propósito, este propósito 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 específica y posee ciertas características que están 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 Página 130 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

desempeño 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 algún otro objeto les entrega. Este proceso de abstracción mental en el análisis de los procesos que se ve tan complejo en realidad tú lo llevas haciendo desde pequeño seguramente sin darte cuenta. Volvamos ahora hacia las clases y su representación en el modelo. Como vimos anteriormente, en el mundo real los objetos interactúan 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 tuviéramos que definir un lápiz en orientación a objetos, tendríamos que definir sus características o atributos y su funcionalidad. Definición del lápiz

En los objetos la función y las características siempre están unidos y nunca se separan, de esta forma, la función afecta a la característica y viceversa, por ejemplo cuando el lápiz raya, esta acción hace que la cantidad de tinta disminuya, cuando la cantidad de tinta llega a 0, ¿Puede seguir rayando el lápiz? . Si analizas los comportamientos de muchos objetos que te rodean te darás cuenta de que esta unión entre las características y la función Página 131 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

siempre se encuentra y es fácil 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?. Fíjate que al encender o apagar la ampolleta, estas cambiando el estado de la ampolleta (una característica que posee) y al apagarla, esto también ocurre, pero al estar encendida, esta sólo se puede apagar, ¿te das cuenta de la relación?, si aún 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 darás cuenta de que tu nueva mascota, entre todas las cosas que hace, come bastante y además camina y ruge, fíjate además que para cada una de esas acciones que realiza, la nueva mascota utiliza energía, sólo puede realizar las acciones antes descrita si la cantidad de energía es mayor a 0. Ahora bien cada vez que realiza una acción, la cantidad de energía se disminuye una cierta cantidad de unidades, pero cuando come, la cantidad de energía acumulada aumenta. Con esto vemos que que los atributos o características de una clase se ven modificados por las acciones o métodos, de la misma forma, si el dinosaurio mascota no se alimenta, su cantidad de energía 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 gráficos

del

diagrama?,

ahora

vamos

a

eso,

en

UML,

la

representación de las clases, sus atributos y sus métodos se realiza mediante una representación gráfica que muestra un rectángulo dividido en 3 partes, la superior contiene el nombre de Página 132 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

la clase, la parte central la definición de los atributos de las clases y la parte inferior los métodos o comportamiento de la clase. Para muestra un ejemplo:

Fíjate que cada una de las secciones posee ciertas características con respecto a la forma en que éstas se definen.

Nombre de la clase: Esta se debe escribir centrada en la página y con formato de texto ennegrecido, adicionalmente existe una nomenclatura para la escritura de los nombres que si bien no es estándar 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 mayúsculas y el resto en minúsculas, 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 Página 133 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

letra se escriba en minúsculas 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 minúsculas pero la primera letra de la segunda palabra la escribas con mayúsculas, esta misma lógica se da si tienes más de dos palabras, por ejemplo “edad”, fechaNacimiento”, tamañoPueraTrasera”. Además cada atributo debe definir su tipo, en UML existen algunos tipos de datos primitivos por ejemplo Integer, String, Boolean, etc, pero también se pueden agregar otros tipos que permitan aumentar la capacidad de tu modelo, esto se hace en función generalmente del lenguaje de programación con el que se vaya a generar el software al final. Otra cosa que debes tener presente es que los atributos y los métodos poseen niveles de visibilidad que determinan si un atributo o método 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 métodos con los cuales el objeto se comunica con su ambiente, el siguiente ejemplo lo puede clarificar. Lo más 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 fíjate que tú interactuaste con el reproductor de varias formas, pero algunas otras quedaron ocultas, ¿tú encendiste el láser del DVD, realizaste la demultiplexión de la señal óptica para ser transformada en audio y video?, lo más probable es que no, tú sólo interactuaste con los botones del equipo y con el disco en cuestión, pero el resto del proceso se realizó sin tu Página 134 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

intervención. 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 métodos y propiedades con las que no podemos interactuar pues están ocultas para nosotros. Esta característica

de

ocultar

comportamiento

y

acceso

a

las

propiedades de una clase se realiza por un tema de seguridad, pues

te

imaginas

cuantos

ojos

quemados

existirían

si

te

permitieran manipular el láser 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 públicos (+), 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 sólo 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 característica de esta clase, en este caso la propiedad se define como pública 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; Página 135 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

-escudoProtector: Integer=20; Los métodos de la clase también tienen una nomenclatura específica, en este caso los métodos se anotan de la siguiente forma: NombreMetodo(atributo:tipoDato) En este caso también debemos explicar algunas cosas respecto al formato, el nombre del método representa el nombre del comportamiento de la clase, este nombre debe ser significativo o sea que te permita saber fácilmente que es lo que el método hace, sólo con leer su nombre, por ejemplo, que es más fácil de determinar, el comportamiento de un método que se llama liquidarZombi(), o un método llamado x25rst45(), si te fijas, el primer método se explica por si sólo, mientras que el segundo no. Adicionalmente al nombre si te fijas entre paréntesis aparecen variables, es decir valores que se identifican con un nombre y que son de un tipo de dato específico, estas variables el método las ocupa para poder tener información adicional que es parte del mensaje que el objeto recibe para poder ejecutar el método. 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 vehículo no se mueve a menos que nosotros presionemos el pedal del acelerador, en este caso la cantidad de presión que apliquemos al pedal será la velocidad de salida del automóvil, si te fijas en este caso lo podemos representar de la siguiente forma: +acelerar(fuerza:Integer) Página 136 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Por lo tanto ahora podemos representar clases como corresponde, es decir:


Relación entre las clases y las tablas de un modelo entidad relación. 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 métodos. Este análisis de los procesos agrupando primero los datos, se parece mucho al análisis 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 más 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 matrícula, entonces, el modelo de la clase se podría graficar de la siguiente forma:


Ahora fíjate 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 definición, la diferencia está en que la clase posee los métodos de la clase y adicionalmente, la forma en que se relacionan los elementos son distintos.

Componentes del diagrama estático 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 país necesita establecer el modelo de clases para poder crear un software estadístico para llevar el control de los partidos que se están por comenzar a jugar en la liga, además necesita conocer los goles marcados, el goleador por equipo y cada uno de los registros asociados a un partido de fútbol. Debes tener presente que el proceso de análisis 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 Página 139 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

eternamente, la experiencia ya te dirá cuándo es suficiente la iteración del proceso. Lo primero es tratar de definir las clases propuestas, que aparezcan en el modelo, para esto leemos la definición del problema o la definición 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 podría ser posible el incluir a los jugadores pues ellos componen los equipos y hacen los goles, por lo tanto su inclusión en el modelo podría 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 relación entre los métodos de la clase y los atributos de la misma, así por ejemplo existe un método que se llama marcarGol(), este método de forma interna lo que hace es que modifica la cantidad de goles que ha Página 140 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

marcado el jugador y adicionalmente disminuye la cantidad de energía que este posee. Si durante el análisis te das cuenta que hay un atributo que no es ocupado o algún método que nunca es utilizado, entonces es el momento de modificarlo, pues esto después al ser transformado en código, será trabajo extra que tendrá que hacer el programador. Como este es un proceso iterativo e incremental, podremos agregar o quitar tantos métodos o atributos que consideremos que no están correctamente asignados. Recuerda eso sí que la decisión de

agregar o quitar

elementos desde el modelo no es antojadizo, es parte del proceso de análisis que nos lleva a dejar sólo aquellos procesos que nos son útiles para solucionar el problema, por ejemplo si analizamos a nuestro jugador nos damos cuenta de que también come, y corre y salta y realiza un montón de acciones, pero estas acciones no son relevantes para el proceso que estamos estudiando, este proceso de ignorancia selectiva se conoce como abstracción y es uno de los procesos más importantes del diseño de clases. Este proceso de abstracción 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 documentación para los atributos que esta posee, para muestra la siguiente clase documentada.

Nombre de la clase: Atributo 1: Atributo 2: Página 141 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

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 interactúan en el mundo real cuando se transformen en objetos. Recuerda que cuando construimos clases, estas clases se transformarán en objetos cuando se estén 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 características. Por otro lado un programador va a tomar esta definición y la documentación que tú desarrolles y va a construir un software donde estas clases se transformaran en archivos de código. El compilador del lenguaje de programación va a tomar estos archivos y los va a compilar y a ejecutar, eso significa que el código 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 construcción “física” 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 Página 142 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

realizar, ahora te preguntarás ¿Por qué no puedo tener un solo objeto que haga todo?, la respuesta es simple, los objetos compuestos son difíciles de arreglar cuando están malos y además 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 sólo el monitor? Si te fijas en este caso, es más barato cambiar el monitor que el computador completo y adicionalmente para la fábrica es más barato producir sólo monitores que los computadores completos, lo mismo sucede con casi todos los objetos que ves a diario y con los cuales interactúas, estos están compuestos de otros objetos, pues es más fácil remplazar y construir las partes partes específicas de cada una.

Por lo tanto para para

lograr un objetivo mayor, un objeto solicita a otro objeto que realice una acción mediante la comunicación 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 función principal, pero además también 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 función de mejor forma, así cuando uno de ellos se lesiona es cambiado por otro que realiza la misma función. En el diagrama de clases es posible ilustrar estas relaciones mediante

una

línea

que

une

cada

una

de

las

clases,

y

adicionalmente según el tipo de relación que se establece, también se pueden agregar algunos otros elementos que permitan aclarar la relación que se establece entre las clases.


Básicamente la relación que se establece entre dos objetos tiene que ver con la comunicación que estos establecen, así un objeto se comunica con otro o colabora con otro objeto cuando le solicita que realice una acción 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 televisión, lo que estas haciendo es utilizar una función 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 colaboración 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 sólo 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 están colaborando unos con los otros. Fíjate 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 colaboración permite que el objeto exista, pregúntate 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 categorías o tipos de relaciones que permiten diferenciar los tipos de relaciones Página 144 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

existentes, pues aunque no lo creas existen distintos tipos de relaciones entre los objetos, las cuales definiremos a continuación.

Asociación. La relación de asociación, se define cuando una clase se asocia con otra para lograr un objetivo, este tipo de relación es el más básico, 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 dirección de la relación 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 línea que permite establecer que existe una relación entre las clases. Fíjate que el conector adicionalmente puede tener el nombre del rol de esa clase en esa relación. Por ejemplo en determinado momento tu estableces en tu casa varios roles en función de con quién 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 relación en particular.


La dirección de la relación permite establecer cual es la clase que genera las instancias de la otra clase. Las restricciones son básicamente anotaciones con instrucciones o con características 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 relación establece el grado y nivel de dependencia, de esta forma podemos determinar que existen varios tipos de cardinalidad:



Asociación uno a uno (1..1): En una relación de asociación uno

a uno, ésta es en ambas direcciones, por lo mismo los objetos de ambas clases están asociados sólo a un objeto de la otra clase, por ejemplo la relación de exclusividad que existe entre el gerente de una empresa y la empresa, así el gerente sólo puede ser gerente de una empresa y la empresa sólo puede tener un gerente.



Asociación uno a muchos(1..*): en esta relación, se produce

una relación uno a muchos en una dirección y en la otra una relación uno a uno, por ejemplo la relación entre el héroe y la Página 146 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

cantidad de balas que puede disparar, si te fijas en las películas de acción los héroes poseen cargadores infinitos de balas, nunca sabemos cuando se van a acabar. De esta forma, el héroe posee un cargador con muchas balas (no sabemos el número exacto) y esas balas pertenecen sólo al héroe.



Asociación numéricamente especificada(n..m): en este caso la

asociación se realiza un número de veces especificado, por ejemplo en un equipo de voleibol, la cantidad mínima de jugadores es 6 y la máxima 12, fíjate que las cotas mínimas y máximas están 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.



Asociación opcional (0..*): en este caso, la relación no establece

obligatoriedad de existencia en la relación, por ejemplo la relación que se da entre el dueño de una cuenta de banco y las tarjetas de crédito que este posee. No todos los dueños de las cuentas de banco poseen tarjeta de crédito. Cabe hacer notar que la relación que se establece del otro lado siempre es de uno a uno.



Asociación muchos a muchos (*..*): en este caso la relación se

establece entre clases con una asociación de uno a muchos en ambas direcciones, por ejemplo la relación 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.


Asociación calificativa. Este tipo de asociación está asociada a la relación del tipo uno es a muchos, en el cual se requiere explicitar algún atributo que definirá un identificador único para una clase y de esta forma poder diferenciar cada uno de los objetos de la relación, por ejemplo cada uno de los buses para un recorrido del Transantiago9 está asociado al recorrido con una relación del tipo uno a muchos, para poder identificar a cada bus de forma individual ocupamos el atributo patente del vehículo para establecer la relación. De esta forma la asociación calificada quedaría de la siguiente forma:

Asociación reflexiva. La asociación reflexiva se da cuando la relación se establece entre elementos del mismo tipo, es decir la clase se relaciona consigo misma, pudiendo establecer el rol para clarificar la relación, por ejemplo supongamos que necesitamos establecer la relación 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.

9

http://es.wikipedia.org/wiki/Transantiago


Herencia. La asociación de herencia permite que las clases que se relacionan, lo puedan hacer en un nivel de especificidad, es decir que las clases que se están asociando son clases iguales salvo que una de ellas es más específica, es decir implementa más métodos o los mismos métodos pero con una implementación distinta.

Asociación. Existen algunos tipos especiales de asociación que veremos a continuación,

estos

tipos

especiales

permiten

representar

asociaciones más complejas. La asociación ternaria es una asociación entre tres clases de forma simultánea, la cual no puede ser leída o agrupada sólo de a dos clases pues pierde el sentido. Por ejemplo se puede establecer una relación entre artista, canción e instrumento o entre jugador, Página 149 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

equipo y posición. En los dos ejemplos anteriores podríamos analizar la relación de a pares pero pierde su significado o semántica, Para establecer la relación ternaria se dibuja un rombo entre las tres clases. Al igual que en el resto de las asociaciones, puedes agregar características de cardinalidad a la relación.

Otra relación de asociación particular son las clases de asociación. Una clase de asociación aquella que modela una asociación entre dos o más clases. Los atributos de la clase de asociación son los atributos de la asociación. En el caso de una asociación compleja entre dos o más clases, es posible que una clase de asociación tenga sus propios atributos, los cuales sirven para dar significado a Página 150 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

la relación. Como ejemplo, analicemos la relación existente entre los alumnos y las asignaturas que cursan este semestre, si analizamos la relación, nos damos cuenta de que existe una relación de muchos a muchos, en este caso en particular se puede crear una clase de asociación llamada horario que permite establecer que alumno esta asociado a que asignatura específica. Otros tipos de relaciones son las relaciones de composición y agregación. Estas relaciones son muy parecidas y se basan en el concepto de que una clase es una parte del todo, por ejemplo la lámpara se compone de un interruptor, el soquete, la ampolleta y la pantalla, se establece una relación de uno a uno entre la clase lámpara y sus componentes (el todo y las partes). La agregación es un tipo de relación en dónde 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 vehículos tienen ruedas, si analizamos esta relación, sabemos que las ruedas existen y están 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 composición es un tipo de relación más fuerte que la agregación. La composición es también una relación entre instancias. Así los objetos que participan en la relación, nacen, viven y mueren relacionados con el todo. A menudo las clases de composición se asocian a relaciones físicas entre los objetos. Por ejemplo si observas una camisa, observas que está compuesta por un grupo de partes (mangas, bolsillo, cuello, puños) y que cada uno establece una relación más fuerte, en este caso si la camisa se Página 151 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

destruye, la utilidad de la manga o del cuello se pierden pues su existencia tiene significado sólo cuando es parte de una camisa. La distinción entre las relaciones de composición y agregación 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.

Realización. Una relación de realización esta dada por una clase y una interfaz. En orientación a objetos, una clase de interfaz es una clase que define el comportamiento de una clase pero jamás la implementa, esto que parece tan complejo lo podemos definir como una clase que es un cascaron sin código por dentro. Te estarás preguntando ¿Y para que quiero tener una clase que no hace nada y que no tiene código?, 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 están moviendo, pero la nave se mueve en función 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 método (mover) pero los dos lo hacen de forma distinta entonces se crea una clase de interfaz que posea el método y como este método 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. Página 152 de 152 UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES

Manual Análisis y Diseño Orientado a Objeto versión 1.1 (1)

Recommend Documents