manual análisis y diseño orientado a objeto versión 1.1 (1)

de 152

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

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.

de 152


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 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

de 152


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.

de 152


Í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

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................................................ 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

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

de 152


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

de 152


Relación entre las clases y las tablas de un modelo entidad 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

de 152


de 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ú.

de 152


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

de 152


un serio problema, por esto una buena capacidad tanto de análisis

como de diseño es tan importante.

de 152


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

de 152


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,

de 152


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

de 152


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

de 152


necesario interactuar con los usuarios del sistema (los que realizan

las acciones) para identificar sus necesidades y analizar el sistema

para entender su funcionalidad.

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 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.

de 152


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 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

de 152


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.

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

de 152


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

de 152


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.

de 152


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

de 152


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.

de 152


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:

de 152


Si analizamos ahora el dato de la edad, y nos detenemos a pensar

un momento, podemos determinar que este dato por ejemplo es

un valor 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

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

de 152


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

Sistema 2

Frontera del Sistema

Componente del Sistema

Medio ambiente

de 152


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...

de 152


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

de 152


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”.

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 “UML y Patrones”, Capitulo 18. Craig Larman. Prentice Hall.

4 http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o

http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o

de 152


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 al leer otros apuntes.

de 152


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.

de 152


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.

de 152


Datos, comportamiento y relaciones

de los objetos.

Durante el transcurso de este curso, aprenderemos un hermoso

camino, que comienza con la necesidad de un cliente y que

termina con una 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.

de 152


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 jugadores

2) Pelota

3) Marcador

4) arbitro

Si sumamos obtendremos que: 22 jugadores + una pelota + un

marcador + un arbitro dan un total de 25 objetos, si bien la suma

esta correcta, el análisis que debemos realizar durante esta

asignatura es más simple, ya que 22 jugadores es sólo la cantidad

de 152


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

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

Pelota

Rodar

Rebotar

Arbitro

Dar tarjeta amarilla

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

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

de 152


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 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

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

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.

de 152


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.

de 152


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.

de 152


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 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 las asociaciones que

existen entre ellos, por ejemplo, en el ejemplo anterior una

asignatura puede contener de cero a muchos cursos (o secciones)

y cada curso puede tener entre 15 (el 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á.

de 152


El diagrama de clases por tanto se construye antes de construir el

software y es un plano de todo lo que deseamos construir. En él

van las clases que va a contener tu software y sus asociaciones,

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.

de 152


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

de 152


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.

de 152


¡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

de 152


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.

de 152


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.

de 152


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

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.

de 152


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 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

de 152


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í

de 152


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.

de 152


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 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 por carrocería, motor y ruedas 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

de 152


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:

de 152


Diagramas de componentes.

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

de 152


ver piezas sueltas que parecen no tener una 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.

de 152


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

de 152


puzzle podemos volver a utilizar en cada software en el que se

necesite.

Una interfaz se representa de la siguiente forma:

Diagrama de despliegue.

El diagrama de despliegue es un diagrama que permite mostrar la

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

de 152


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.

de 152


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.

de 152


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, 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 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.

de 152


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

de 152


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

de 152


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 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

Buscar contactoActor1

de 152


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 tienes varios estados: alegre, triste,

concentrado, etc. Sin embargo para que estos eventos vayan

cambiando debe suceder “algo” para que tu estado cambie. Por

ejemplo, si hoy por la tarde llegas a casa y descubres que eres el

único ganador de un millonario premio, seguramente tu estado

pasará a “ultra feliz al borde del colapso nervioso”, sin embargo

para que esto ocurra ha tenido que suceder lo que denominamos

un evento, en este caso particular al evento le 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 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

de 152


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 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:

de 152


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.

de 152


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:

de 152


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.

de 152


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.

de 152


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

de 152


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,

de 152


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:

de 152


de 152


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.

de 152


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 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

de 152


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 en la que obtenemos los requerimientos (las

necesidades) desde nuestro cliente, en la que 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.

de 152


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.

de 152


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

de 152


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 si esta habilitada y el

monto disponible para compra supera el valor del producto,

entonces se genera la venta, esta venta es registrada por el

de 152


software y en ella incluye los datos del comprador y algunos datos

de la venta, como la fecha, el total y el detalle, el cual consiste en

una lista de los productos que compró.

Adicionalmente a lo anterior, para que un cliente pueda comprar

en una 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

de 152


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.

de 152


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

de 152


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.

de 152


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 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.

de 152


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

de 152


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 que son los conectores.

Entidad Proceso Almacén

Entidad NO SI NO

Proceso SI SI SI

Almacén NO SI NO

de 152


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.

de 152


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.

de 152


Estos son ejemplos no válidos.

b) Todos los procesos deben modificar los datos de entrada

produciendo nuevas formas de datos de salida. Algunos

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 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.

de 152


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 un diagrama diseñado para ser usado por los

analistas, quienes diseñan, controlan 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

de 152


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 manejan información adicional pero no

suficiente 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.

de 152


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.

de 152


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 es un conjunto de actividades incluidas

dentro de 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.

de 152


Un proceso expandido muestra los subprocesos, es decir está en el

mismo nivel de detalle del proceso y tiene un evento de inicio y fin

del proceso.

Las compuertas o gateway se representa con un diamante y

representa una divergencia o convergencia de la secuencia de

flujo. Estas siempre determinan bifurcaciones, combinaciones o

fusiones del proceso.

La compuerta exclusiva puede ser de dos tipos

convergente o divergente, la divergente son

decisiones que toma el usuario del sistema para

saber que camino seguir, las convergentes

sincronizan los caminos salientes al cumplir una condición del

negocio.

La compuerta compleja representa un punto

donde aparecen varios caminos y sólo uno de

ellos es válido.

de 152


La compuesta paralela indica un punto en el

proceso donde pueden ser llevadas a cabo varias

actividades en paralelo.

Los objetos conectores conectan los objetos de flujo de un

proceso, y definen el orden de 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.

de 152


Los swimlanes o canales son un mecanismo empleado para

organizar actividades en categorías separadas visualmente, con

el fin de ilustrar diferentes capacidades funcionales 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.

de 152


Acá vemos un ejemplo de un proceso de compra y venta de

productos con el posterior despacho de este producto por parte del

vendedor. 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.

de 152


de 152


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.

de 152


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

de 152


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

de 152


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.

de 152


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.

de 152


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

uso.

Actores.

Los actores se definen en un diagrama de casos de uso como entes

externos que 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.

Los actores se representan como una persona dibujada con palitos,

como cuando éramos pequeños y aún no aprendíamos a dibujar.

de 152


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

de 152


productos a un cliente, consultar el total de la venta, imprimir el

comprobante de la venta, recibir el pago, y dar vuelto si

corresponde, recuerda que este es una 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.

de 152


Una vez que identificamos a los actores, lo que debemos hacer es

definir los casos de uso, es decir a las acciones que estos actores

van a realizar para lograr el objetivo propuesto.

Para el ejemplo anterior vemos que podemos detectar ciertas

acciones o comportamientos que debe realizar cada uno de los

actores como usuarios del sistema, así podemos dividir las

acciones que realiza cada uno de la siguiente forma:

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

de 152


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:

de 152


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

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

de 152


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 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 <<extend>>, 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 <<include>> 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:

de 152


En el ejemplo anterior el caso de uso “servir 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,

de 152


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.”.

de 152


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.

de 152


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

de 152


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.

de 152


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

de 152


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.

de 152


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.

de 152


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 siempre.

de 152


Generalización.

La relación de generalización en los casos 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 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

de 152


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 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.

de 152


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.

de 152


6. El sistema muestra un mensaje de exito en el proceso de registro.

• Post-condiciones:

1. El usuario es registrado en el sistema y se le 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

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.

de 152


de 152


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.

de 152


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.

de 152


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.

Componentes del diagrama estático de

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.

de 152


“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

de 152


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

de 152


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

de 152


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 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

de 152


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

de 152


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

de 152


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;

de 152


-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)

de 152


Por lo tanto ahora podemos representar clases como corresponde,

es decir:

de 152


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:

de 152


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

de 152


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

de 152


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:

de 152


Comportamiento 1:

Comportamiento 2:

Relaciones entre las clases.

En el mundo real, las clases no funcionan solas, sino que

establecen relaciones entre ellas, estas relaciones, permiten definir

la forma en que las clases 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

de 152


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 específicas de cada una. Por lo tanto 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.

de 152


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

de 152


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.

de 152


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

de 152


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.

de 152


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

de 152


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,

de 152


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

de 152


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

de 152


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.

manual análisis y diseño orientado a objeto versión 1.1 (1)

Documents