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

Manual para la asignatura de Anlisis y Diseo Orientado a
Objetos Versin 1.1. Santiago Marzo de 2012
Este material ha sido diseado para el uso de los alumnos y

profesores de la asignatura de Anlisis y Diseo Orientado a
Objetos de las carreras del rea informtica. Queda
estrictamente prohibido el uso en otros cursos ya sean en
lnea o presenciales sin el consentimiento explcito de
INACAP.
Pgina 1 de 154
UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

Agradecimientos.
Agradecemos a todas las personas que de forma directa o indirecta
han colaborado en la elaboracin de este manual.
De forma significativa agradecemos a los docentes de las sedes que

nos han apoyado y colaborado con ejercicios y propuestas durante
la presentacin de este proyecto.
Vayan nuestros sinceros agradecimientos a los siguientes docentes:
Cristian Leiva Marn, Miguel Palma Esquivel, Marcelo Montecinos

Cabrera, Rodrigo Toledo de los Santos, Paola Cifuentes Berrios,
Servando Campillay Briones, Emerson Ilaja Villarroel, Hugo Herrera
Valenzuela, Fernando Santolaya, Manuel Morales, Roberto Prez
Fuentes, Fernando Neyra Castro, Victor Brquez, Francisco Andrs
Daz Rojas, Ademar Araya Fuentes, Ricardo Vera Muoz, Mauricio
Torres Pizarro, Ernesto Ramos Vega, Alberto Garrido Burgos, Helton
Bustos Sez, Beatriz Contreras Guajardo, Jos Landeta Parra, Luis
Pacheco Toro, Patricio Araya Castro, Ivn Torres, Hinojoza Vega
Mauricio, Yasna Hernndez, Vctor Orellana, Rene Valderas Aros,
Ricardo Toledo Barra, Cesar Eduardo Arce Jara, Luis Ponce
Cuadra, Javier Miles Avello, Carolina Ehrmantraut Caballero, Pedro
Alfonso Fuentealba Martnez, Jorge Hormazabal Valds, Pedro
Ernesto Ulloa Morales, Mara del Pilar Gallego Martnez, Claudio
Fuenzalida Medina, Mara Encarnacin Seplveda, Francisco San
Martin, Christian Sarmiento Zampillo, Romn Gajardo Robles,
Ricardo Hidalgo Hidalgo, Nelson Fredy Ganga Caldern, Manuel
Reveco Cabellos, Jacqueline San Martin Grandon, Sergio Vergara
Salvatierra, Pablo Lpez Chacn, Cinthya Acosta, Jocelyn Oriana
Pgina 2 de 154

Gonzlez Corts, Carlos Felipe Alten Lpez, Francisco Prieto Rossi,
Giannina Costa Lizama, Christian Silva, Sebastin Pastn Daz.
El aporte realizado por ustedes durante las jornadas de capacitacin

ha significado mejorar enormemente la calidad del material
entregado.
Saludos.
Pgina 3 de 154

ndice
Introduccin al anlisis y diseo Orientado a Objetos .............................................................................................8

Definicin del anlisis y diseo orientado a objetos ......................................................................................... 11
Importancia del anlisis y diseo orientado a objetos ...................................................................................... 11
Diferentes metodologas de anlisis de sistemas.............................................................................................. 12
Los datos, la informacin y su importancia para las organizaciones. ............................................................... 18
Definicin de los datos en el contexto de un problema.................................................................................... 20
Teora de sistemas bsica y la interaccin de los objetos en una organizacin................................................ 24
Patrn ECB (Entity Control Boundary) ......................................................................................................... 27
Datos, comportamiento y relaciones de los objetos. ........................................................................................ 31
Definicin de UML ............................................................................................................................................. 36
Etapas del ciclo de vida utilizando RUP (Rational Unified Process) .................................................................. 37
Diagramas de Estructura. .................................................................................................................................. 41
Diagrama de clases ........................................................................................................................................ 41
Diagrama de objeto ....................................................................................................................................... 49
Diagrama de estructuras compuestas. .......................................................................................................... 52
Diagramas de componentes. ......................................................................................................................... 54
Diagrama de despliegue. ............................................................................................................................... 57
Diagrama de paquete. ................................................................................................................................... 59
Diagramas de comportamiento......................................................................................................................... 61
Diagrama de casos de uso. ............................................................................................................................ 61
Diagrama de mquina de estados. ................................................................................................................ 64
Diagrama de actividad. .................................................................................................................................. 66
Diagramas de Interaccin. ................................................................................................................................. 68
Diagrama de secuencias. ............................................................................................................................... 68
Diagrama de tiempo. ..................................................................................................................................... 71
Tcnicas de recopilacin y anlisis de requerimientos. ........................................................................................ 75
Tcnicas de captura de requerimientos. ........................................................................................................... 75
Entrevista. ...................................................................................................................................................... 79
Pgina 4 de 154

Encuesta. ....................................................................................................................................................... 79
Observacin directa....................................................................................................................................... 80
Definicin de actividades................................................................................................................................... 80
Relacin entre las actividades y los actores. ..................................................................................................... 82
Anlisis bsico de los requerimientos para la realizacin de un listado de actividades. .................................. 83
Diagrama de flujo de datos (Agile Unified Process). ......................................................................................... 85
Diagrama de procesos (BPMN 2.0) .................................................................................................................... 91
Diagrama de casos de uso. .................................................................................................................................. 100
Componentes del diagrama de casos de uso. ................................................................................................. 103
Actores. ........................................................................................................................................................ 105
Casos de uso. ............................................................................................................................................... 106
Relaciones. ................................................................................................................................................... 110
Identificacin del contexto en el que participan los actores. ......................................................................... 113
Identificacin de los roles. ............................................................................................................................... 114
Definicin de los actores. ................................................................................................................................ 115
Definicin de los casos de uso. ........................................................................................................................ 116
Definicin de los casos de uso. ........................................................................................................................ 117
Definicin de los tipos de relaciones ............................................................................................................... 119
Comunicacin. ............................................................................................................................................. 119
Inclusin....................................................................................................................................................... 119
Extensin. .................................................................................................................................................... 120
Generalizacin. ............................................................................................................................................ 121
Documentacin de los casos de uso................................................................................................................ 121
Definicin del caso de uso. .............................................................................................................................. 122
Flujo Normal. ................................................................................................................................................... 122
Pre-condiciones. .............................................................................................................................................. 123
Post-condiciones. ............................................................................................................................................ 123
Diagrama esttico de clases. ............................................................................................................................... 126
Introduccin al diagrama esttico de clases. .................................................................................................. 126
Utilidad del diagrama esttico de clases. .................................................................................................... 127
Componentes del diagrama esttico de clases. .......................................................................................... 128
Pgina 5 de 154

Relacin entre las clases y las tablas de un modelo entidad relacin............................................................. 138
Componentes del diagrama esttico de clases. .............................................................................................. 139
Relaciones entre las clases. ............................................................................................................................. 144
Asociacin. ................................................................................................................................................... 146
Multiplicidad. ............................................................................................................................................... 148
Asociacin calificativa. ................................................................................................................................. 149
Asociacin reflexiva. .................................................................................................................................... 150
Herencia....................................................................................................................................................... 151
Asociacin. ................................................................................................................................................... 151
Realizacin. .................................................................................................................................................. 154
Pgina 6 de 154

Pgina 7 de 154

Introduccin al anlisis y diseo
Orientado a Objetos
Bienvenido al mundo de los objetos! te felicito por emprender este
camino, aprenders a ver tu entorno de una forma distinta. Para
ello comenzaremos trabajando con la forma en que piensas y
cambiaremos el modo en la que analizas las cosas, el objetivo es
convertirte en una persona capaz de hacer un buen anlisis sobre
las situaciones que te rodean, ya que esto tendr un directo
beneficio en los programas computacionales que crears en el
futuro prximo y la forma en la que entregars soluciones al medio
que te rodea. Mientras mejor entendamos nuestro entorno
podremos tomar mejores decisiones. Todos hemos utilizado
software alguna vez y de seguro que has encontrado algunos
mejores que otros, probablemente en este momento ests
recordando dos o ms software que hayas usado y cul de ellos te
agrad ms, no slo considerando la usabilidad o lo vistoso del
software, sino a un mundo completo que esta detrs que an no
conoces pero del cual sers partcipe muy pronto, que va en desde
cmo utiliza el hardware en el que funciona, la velocidad en la que
se comunica por la red con otros componentes de software e
incluso con la optimizacin con la que realiza clculos y los entrega
al usuario. Quin se encarga de todo eso? Existe algn
responsable de que todas las partes trabajen en forma eficiente?
Quin debe velar porque lo que se construye solucione de la
mejor forma posible un problema? Como me imagino ya lo
adivinars esa persona en un futuro cercano sers t.
Pgina 8 de 154

Por eso es tan importante tener una buena capacidad de anlisis,
de esta forma comprenders mejor las cosas y podrs tomar
mejores decisiones, mientras ms comprendemos menos
deberemos memorizar.
El primer paso consiste en hacer anlisis, entender el problema de

tu cliente e identificar una buena solucin. El segundo paso ser
disearla, el paso previo a construirla. Muchos software comienzan
a ser codificados sin un buen anlisis, lo que da como resultado un
producto deficiente que no soluciona el problema del cliente. Un
mal diseo provocara un software con errores en el cual se habr
trabajado probablemente el doble de lo necesario, los errores en
diseo comienzan notarse tarde en el desarrollo haciendo que una
gran cantidad de programas queden en el 90% de su construccin,
haciendo que el 10% restante implique incluso ms trabajo que el
90% anterior. Para que te hagas una idea esto no es algo que no
pase en el resto de las disciplinas, has pensado en cmo quedara
un edificio si la constructora comienza su tarea sin un anlisis y
diseo apropiado? y si lo logra, soportar el prximo temblor?
Ahora pensemos en qu sucede si el diseo es apropiado, pero
proviene de un mal anlisis de requerimiento y si bien el edificio
queda bonito con 80 pisos, grandes ventanales y piscina en la
azotea, pero despus de construido y luego de una larga y
pausada conversacin con tu cliente en la cual te tomas ms
tiempo para entenderlo, haces un mejor anlisis y te das cuenta
que lo que en realidad necesitaba era un bunker subterrneo para
sobrevivir al paso de un tornado. A estas alturas ya no hay nada
que hacer, desarmar el edificio, para dejar el terreno libre para
luego comenzar a disear y construir un bunker llevar sin duda a
tu empresa a un fracaso, deja a tus clientes sin un bunker y a t en
Pgina 9 de 154

un serio problema, por esto una buena capacidad tanto de anlisis
como de diseo es tan importante.
Pgina 10 de 154

Definicin del anlisis y diseo
orientado a objetos
El anlisis y diseo orientado a objetos es un enfoque de la
ingeniera de software que permite modelar un sistema como un
conjunto de objetos relacionados que interactan entre si. Para
lograr esta tarea, el anlisis y diseo orientado a objetos propone
una serie de diagramas entre los que destacan los diagramas
propuestos en UML (Unified Modeling Language o Lenguaje
Unificado de Modelado) que surge como una estandarizacin de los
diagramas propuestos por muchos tericos de esta disciplina
alrededor del mundo.
El proceso de anlisis y diseo orientado a objetos (desde ahora

ADOO) se basa en analizar un problema (generalmente asociado al
manejo de datos) y tratar de resolverlo utilizando para esto
estructuras del mundo real. La unidad bsica es el objeto, que
combina datos y comportamientos que se realizan con estos datos
y que se unen en una estructura atmica.
Importancia del anlisis y diseo

orientado a objetos
El ADOO es parte de un proceso que se conoce como Ingeniera de
Requerimientos, que consiste en tratar de recopilar la mayor
cantidad de datos disponible respecto a una serie de procesos para
los cuales se requiere construir una solucin utilizando tecnologas
de informacin. Las tecnologas de informacin son un grupo de
tecnologas cuyo propsito es gestionar los datos que son
importantes para una organizacin. Por lo tanto los sistemas que
Pgina 11 de 154

utilizan tecnologas de informacin, no slo hacen referencia al
software, sino que tambin a los procesos, las personas y la
infraestructura (hardware) necesario para poder administrar de la
mejor forma posible los datos que son necesarios para que la
organizacin realice su propsito.
Un correcto proceso de anlisis permitir a los ingenieros de

software tomar mejores decisiones para la creacin, gestin y
administracin de proyectos de tecnologas de informacin. Un
anlisis incorrecto puede generar un enorme costo para la
organizacin, pues sta puede tomar malas decisiones respecto a
su negocio por no contar con la informacin correcta en el
momento adecuado. Adicionalmente, el desarrollo de un proyecto
de tecnologas de informacin no es un proceso que se realiza de
un da para otro, sino que requiere de un tiempo que es difcil de
estimar en un principio y por lo tanto su costo puede elevarse en
demasa si el anlisis inicial no est bien hecho, por lo que esta
etapa resulta crucial en el desarrollo de los proyectos de
tecnologas de informacin.
Diferentes metodologas de anlisis

de sistemas.
Al realizar el anlisis de procesos en las organizaciones, existen
diferentes metodologas que se pueden ocupar para lograr el
resultado esperado.
Como definicin formal podemos decir que una metodologa

hace referencia al conjunto de procedimientos racionales,
Pgina 12 de 154

utilizados para alcanzar una gama de objetivos que rigen en una
investigacin cientfica, una exposicin doctrinal o tareas que
requieran habilidades, conocimientos o cuidados especficos.
Alternativamente puede definirse la metodologa como el estudio o
eleccin de un mtodo pertinente para un determinado objetivo. 1.
De esta forma podemos decir que las metodologas como un

conjunto de pasos para lograr un objetivo, se pueden clasificar
utilizando el enfoque que se aplica para el proceso, existiendo dos
metodologas bsicas, una metodologa estructurada y una
metodologa orientada a objetos.
La metodologa estructurada se origin en los lenguajes de

programacin estructurados para dar soporte a las necesidades del
lenguaje. Esta metodologa sent las primeras estructuras para la
definicin de la llamada ingeniera de software es decir se
definieron fases y etapas para dar solucin a proyectos de software
que se van a desarrollar utilizando un lenguaje de programacin
estructurado.
Adicionalmente a sta, surge la metodologa orientada a objetos,

la cual se ha desarrollado y ha permanecido en el tiempo siendo el
paradigma de anlisis y diseo de proyectos de tecnologas de
informacin ms utilizada en estos tiempos. Esta metodologa que
comenz a desarrollarse a finales de los aos sesenta de la mano
del desarrollo de lenguajes de programacin orientados a objetos,
ha evolucionado durante todos estos aos, estableciendo una serie
de pasos que han sido extraordinariamente probados en una serie
de proyectos. Esta metodologa evoluciona constantemente y los
estudiosos del tema desarrollan nuevas formas optimizadas y cada
1
http://es.wikipedia.org/wiki/Metodolog%C3%ADa
Pgina 13 de 154

vez ms especficas para el anlisis y diseo en situaciones
particulares llamadas patrones de diseo.
El desarrollo de proyectos de tecnologas de informacin

orientados a objetos, requieren tcnicas orientadas a objetos que
se aplican durante las etapas de anlisis, construccin e
implementacin del proyecto. Estas metodologas requieren que se
detecten los objetos del sistema, cmo stos interactan, cmo se
comportan en el tiempo y las responsabilidades que asumen al
relacionarse con otros objetos. El anlisis orientado a objetos mira
todos los objetos en el sistema, agrupa sus caractersticas y
comportamientos comunes, estudia sus diferencias y cmo el
sistema maneja estos objetos para lograr su objetivo.
En trminos sencillos, el anlisis y diseo orientado a objetos est

basado en identificar a los objetos en un sistema y sus
interrelaciones. Una vez que esta parte est hecha, es necesario
modelar el sistema, esta etapa es similar a la etapa de la
metodologa estructurada, pues tambin se sigue un proceso
secuencial pero con una aproximacin diferente. Las etapas
bsicas del diseo de sistemas en un modelo orientado a objetos,
se pueden listar de la siguiente forma:
Anlisis de Sistemas.
Diseo del sistema.
Diseo de los objetos.
Implementacin.
La etapa de anlisis de sistemas es la primera parte del proceso de

desarrollo de proyectos de tecnologas de informacin orientados a
objetos, al igual que en las otras metodologas. En esta fase es
Pgina 14 de 154

necesario interactuar con los usuarios del sistema (los que realizan
las acciones) para identificar sus necesidades y analizar el sistema
para entender su funcionalidad.
Basndose en el sistema estudiado, se prepara un modelo del

sistema definido. Este modelo est basado puramente en lo que se
requiere que el sistema haga. En esta etapa los detalles de
implementacin (como se van a hacer las cosas) no son tomados
en cuenta. Slo se prepara un modelo del sistema basndose en la
idea de que el sistema es un conjunto de objetos que interactan.
La etapa de diseo del sistema es la siguiente etapa de desarrollo

dnde se decide la arquitectura del modelo completo (hardware y
software). Este sistema complejo es organizado en un conjunto de
sub procesos, cada uno con su proyecto individual, los cuales van
a interactuar unos con otros. Mientras se disea el sistema, es
necesario poner especial atencin a las especificaciones de los
procesos definidos en la etapa anterior por parte de los usuarios.
Como el anlisis orientado a objetos percibe los sistemas como un
conjunto de objetos que interactan, as mismo los sistemas ms
grandes y complejos se pueden ver como un conjunto de pequeos
sistemas que interactan entre s.
En la etapa de diseo de los objetos, se definen los detalles del

anlisis del sistema y del diseo para definir cmo sern
implementados. Ac se decide la forma en la que se van a
construir los objetos de manera de implementar las estructuras de
datos, los comportamientos y las relaciones entre cada uno de los
objetos.
Pgina 15 de 154

La fase de implementacin implica transformar el diseo de los
objetos a cdigo, utilizando algn lenguaje de programacin.
Adicionalmente se construyen todas las estructuras que darn
soporte al funcionamiento del software (hardware y
procedimientos). Tambin se construyen los almacenes de datos o
bases de datos, para dar una forma lo ms funcional posible al
sistema.
Las metodologas orientadas a objeto se basan en la identificacin

de los objetos del sistema. Cuando se observan de forma detenida,
los objetos muestran ciertas caractersticas y comportamientos
que les son propios.
Mientras se desarrolla el proyecto, se utilizan ciertos modelos para

identificar a los objetos. Bsicamente se usan tres modelos:
a) Modelo de objetos: Este modelo describe a los objetos en un

sistema y sus interrelaciones. Analiza al sistema como un conjunto
de elementos estticos y no se preocupa de la dinmica que estos
puedan tener.
b) Modelo dinmico: Este modelo describe a los objetos en su

aspecto dinmico, es decir muestra los cambios ocurridos en el
estado de varios objetos que estn interactuando en un momento
determinado.
c) Modelo de flujo de datos: Este modelo describe bsicamente los

datos que han sido transformados por el sistema. De esta forma se
describen los flujos de los datos y los cambios que ocurren a los
datos a travs del sistema
Pgina 16 de 154

Comparada con las tcnicas 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 cdigo existente de otra forma, es decir se pueden
agregar nuevas funcionalidades o extender la funcionalidad
ya existente para crear nuevas clases.
Ignorancia selectiva: la encapsulacin es la tcnica que
permite al programador esconder el funcionamiento interno
de los mtodos al usuario. La encapsulacin separa la
funcionalidad interna del objeto de las funciones externas
provistas al usuario. Esto permite al programador proteger el
cdigo de cambios realizados por el usuario.
Los sistemas diseados utilizando este enfoque estn ms

cercanos al mundo real pues las funciones del mundo real se
mapean directamente a los sistemas.
La metodologa orientada a objetos representa el dominio del

problema, pues es fcil reproducir e interpretar los diseos.
Los objetos en el modelo son inmunes a los cambios en los

requerimientos, un objeto alumnos ser un objeto alumno
independiente de ms o menos atributos o comportamientos que
Pgina 17 de 154

se agreguen. Por lo tanto los cambios se pueden desarrollar de
forma ms fcil.
Los diseos realizados con esta metodologa enfatizan la

reutilizacin. Las nuevas aplicaciones pueden usar mdulos ya
existentes, por lo tanto se reduce el tiempo de anlisis y
desarrollo, redundando esto en un costo final menor al trmino del
ciclo de vida.
Las metodologas orientadas a objetos, tienen una aproximacin

ms natural, esto entrega mejores estructuras para el
pensamiento y la abstraccin y permite un diseo ms modular.
Los datos, la informacin y su

importancia para las
organizaciones.
Todas las organizaciones basan su quehacer en la toma de
decisiones, estas decisiones se toman utilizando los datos que la
organizacin posee.
Los sistemas de informacin que poseen las organizaciones y los

que nosotros tengamos que construir se basan en el proceso de
capturar datos, almacenarlos, procesarlos y obtener un resultado
que es mostrado al usuario. Los datos que son capturados
corresponden a un par ordenado de atributo con valor (atributo,
valor) que representa el registro de un hecho importante para la
organizacin sucedido en algn momento especfico. El atributo
define qu es lo que quieres guardar y el valor define el tipo de
valor asociado, es decir los rangos mximos y mnimos, y el tipo
Pgina 18 de 154

de dato. Los datos siempre estn formados por un par ordenado,
ya que cada una de las partes por separado no tienen sentido. Por
ejemplo (edad, 21 aos).
Cuando una organizacin registra informacin relativa a procesos

que son importantes, lo hace exclusivamente para poder procesar
estos datos, transformarlos en informacin y luego analizar esta
informacin y tomar decisiones ms acertadas. Este proceso de
toma de decisiones se ha especializado en extremo, como por
ejemplo con la minera de datos, que consiste en analizar los datos
ya almacenados y extraer informacin que se desconoca que
exista ah, esto que si bien parece ser un poco complicado,
permite a las organizaciones descubrir nuevas interpretaciones de
los datos que tienen almacenados, siempre con el propsito de
tomar mejores decisiones.
Pgina 19 de 154

Definicin de los datos en el
contexto de un problema.
Cuando se definen los datos a almacenar es necesario siempre
pensar en el proceso que se desea registrar. Recuerda que en
todas las organizaciones, el proceso de registro de datos no se
hace al azar, es decir cuando se registra el proceso es necesario
determinar el contexto en el cual se encuentra inmerso el proceso.
Por ejemplo, si tu organizacin realiza un proceso de compra y
venta de productos, te va a interesar fundamentalmente registrar
esos procesos y todos los otros anexos a ese proceso, por eso es
necesario determinar cul es el proceso que se quiere registrar,
pues de este anlisis dependern los datos que se elijan. Un punto
muy importante a recalcar en esta etapa es el hecho de que las
organizaciones realizan distintas acciones durante su ciclo de
proceso, pero hay algunos procesos que conforman el quehacer
bsico de la organizacin. Ahora si bien es posible detectar el
quehacer de una organizacin de forma relativamente simple, es
necesario siempre hacer un anlisis en funcin de determinar los
datos que se deben registrar, por ejemplo, si analizamos los
procesos que realiza una panadera, nos podemos dar cuenta
fcilmente que el proceso fundamental de una panadera, en la
mayora de los casos es fabricar y vender pan. Ahora bien si te
fijas tambin hay otros procesos en el ciclo de vida de la
organizacin como por ejemplo pagar los sueldos, comprar las
materias primas, distribuir el pan entre los clientes, llevar el
registro contable, registrar las ventas, etctera. Ahora, una vez
que has definido los procesos, debes seleccionar los procesos ms
relevantes para los cuales vas a registrar los datos, siempre
Pgina 20 de 154

pensando en un contexto determinado. As si lo que te interesa es
registrar los procesos productivos de la empresa, debers registrar
los datos de las compras de insumos, transformacin de materias
primas a pan y su posterior venta.
Pgina 21 de 154

Si te fijas en este contexto dejamos varios procesos fuera, pero
eso es lo interesante de este trabajo, debes concntrate en lo
importante, es decir slo en el mbito que te incumbe en ese
momento, pues no existe una solucin para todas las reas al
mismo tiempo. Esta lgica de divisin de los proyectos en
pequeos proyectos que se preocupen de reas especficas de la
organizacin garantiza dos cosas fundamentales, primero garantiza
menos costos iniciales en el desarrollo de la solucin y segundo,
disminuye el tiempo de anlisis y desarrollo pues se disminuye la
complejidad de los procesos a analizar (son menos los procesos
que se deben analizar al mismo tiempo), lo cual genera la
sensacin al usuario de que todo avanza ms rpido.
Volviendo a la definicin de los datos en el contexto, una vez que

defines el contexto y defines los procesos bsicos asociados a ese
contexto, puedes definir las estructuras de los datos. La estructura
de un dato, est asociada al concepto de dominio del dato, es decir
al tipo de dato que se seleccione (nmero entero, decimal,
caracteres, verdadero o falso, un objeto, etc.) y adems los
valores permitidos, mximos y mnimos. Por ejemplo si analizamos
los datos que podemos registrar de un alumno al momento de
matricularlo (este es el contexto), nos podran interesar datos
como los siguientes:
Pgina 22 de 154

Si analizamos ahora el dato de la edad, y nos detenemos a pensar
un momento, podemos determinar que este dato por ejemplo es
un valor numrico entero (raramente tengo 15,76789 aos), ahora
el rango de los posibles valores enteros es muy extenso y por lo
tanto es necesario el determinar cuales de estos valores me sirven,
as logro determinar que cuando recin vi la luz del mundo, tena 0
aos y segn Wikipedia, la persona ms longeva de la tierra tuvo
122 aos2, por lo tanto el valor mximo para este dato debera ser
al menos 122, de esta forma tenemos que la edad est compuesta
por valores numricos enteros entre 0 y al menos 122.
2
http://es.wikipedia.org/wiki/Jeanne_Calment
Pgina 23 de 154

Teora de sistemas bsica y la
interaccin de los objetos en una
organizacin.
Existe una teora bsica para el anlisis de las organizaciones
llamada teora de sistemas. Esta teora de forma muy simplificada
nos indica que un sistema es un conjunto de elementos que estn
interrelacionados entre s con un propsito en comn, por lo tanto
el conjunto de elementos y sus interrelaciones conforman a un
sistema. Adicionalmente este sistema existe dentro de lo que se
conoce como la frontera del sistema (su contexto) y est sumido
en un medio ambiente.
Entrada Salida
Sistema 1 Componente del Sistema
Medio ambiente
Frontera del Sistema
Sistema 2
Pgina 24 de 154

Todos los sistemas poseen un propsito especfico y para lograrlo
reciben elementos (entradas) desde el medio ambiente, los
procesan y generan un resultado que se incorpora al medio
ambiente. Esta salida modifica el medio ambiente, el que al mismo
tiempo est siendo modificado por otros sistemas que tambin
consumen recursos del medio y generan salidas, esto provoca un
desbalance en el medio ambiente el cual es equilibrado
nuevamente por los mismos sistemas formando un delicado
balance en el ecosistema.
Con la informacin que tenemos ahora podemos implcitamente

definir algunas cosas, como por ejemplo que el conjunto de
sistemas que se encuentra en un medio ambiente determinado
tambin conforman un sistema, el cual a su vez esta compuesto
por otros sistemas. Un ejemplo de esto es un ser humano, est
compuesto de un conjunto de rganos que forman sub sistemas,
sistema digestivo, reproductor, nervioso central, etc. A su vez,
cada sistema est compuesto de rganos que estn compuestos de
clulas y estas a su vez estn compuestas de una serie de
componentes (membrana, ncleo, citoplasma). Ahora, si
analizamos al ser humano, ste pertenece a una familia, el
conjunto de familias forman una comunidad que est inserta en un
pueblo, que a su vez esta inserto en una ciudad que pertenece a
una regin y esta a un pas etc., etc...
Pgina 25 de 154

En las organizaciones la teora de sistemas se aplica para poder
realizar un anlisis ms especfico de las distintas reas que
componen las organizaciones, sobre todo cuando se trata de
organizaciones complejas. Muchas veces las organizaciones son
separadas en departamentos (departamento contable, de personal,
de finanzas, de produccin, etc.), esta separacin permite analizar
cada sub seccin de forma ms especfica, adicionalmente esta
separacin permite que cada una de las secciones se especialice en
su trabajo.
Cuando realizamos un anlisis de las organizaciones, nuestro

trabajo consiste en aplicar esta teora de sistemas y
Pgina 26 de 154

complementarla con la orientacin a objetos. De esta forma
debemos definir un contexto para la organizacin (frontera del
sistema), despus debemos definir los objetos que estn insertos
en el sistema (componentes del sistema) y las relaciones que se
establecen (relaciones del sistema).
Patrn ECB (Entity Control

Boundary)
Una forma relativamente simple de graficar la relacin entre los
elementos que componen un sistema es ocupar los grficos que
nos entrega el patrn ECB (Entity-Control-Boundary). Antes de
mostrar los grficos, es necesario entender qu es un patrn en el
mundo del diseo y anlisis de sistemas. Un patrn se puede
definir como: una solucin a un problema de diseo que aparece
con frecuencia.3 O tambin como est definido en Wikipedia Los
patrones de diseo son la base para la bsqueda de soluciones a
problemas comunes en el desarrollo de software y otros mbitos
referentes al diseo de interaccin o interfaces.
Un patrn de diseo es una solucin a un problema de diseo.

Para que una solucin sea considerada un patrn debe poseer
ciertas caractersticas. Una de ellas es que debe haber comprobado
su efectividad resolviendo problemas similares en ocasiones
anteriores. Otra es que debe ser reutilizable, lo que significa que
es aplicable a diferentes problemas de diseo en distintas
circunstancias.4
3
UML y Patrones, Capitulo 18. Craig Larman. Prentice Hall.
4
http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o
Pgina 27 de 154

El patrn Entity Control Boundary (Entidad Control Frontera)5 se
basa en la deteccin de cada uno de los componentes del modelo
al momento de realizar el anlisis, de esta forma podemos definir
que las entidades (Entity) son objetos que entregan o reciben
datos que son tiles para el sistema, la frontera (boundary) son
objetos que representan interfaces del sistema (mtodos o
acciones con las cuales interactan las entidades), los objetos de
control (Control) son objetos que intermedian entre las entidades y
las fronteras, estn encargadas de orquestar la ejecucin de
comandos que vienen definidos desde la frontera. La
representacin grfica de cada uno de los componentes es de la
siguiente forma:
5
Se opt por mantener el nombre del patrn tal cual como fue definido para evitar la confusin al leer otros apuntes.
Pgina 28 de 154

Este grfico nos permite entender de mejor forma como funciona
un sistema asocindolo a la forma en que cada uno de las
entidades interacta con el sistema y como esta interaccin gatilla
la ejecucin de una serie de funciones que no se ven desde afuera
pero que deben ser analizadas para entender cmo funcionan las
cosas. Analicemos el siguiente caso: supongamos que vas a sacar
plata de un cajero automtico. Si analizamos el proceso, vemos
que existe una interaccin de tu parte con la interfaz del cajero lo
que gatilla alguna de las acciones que aparecen graficadas a
continuacin.
Pgina 29 de 154

Fjate que slo analizamos las funciones bsicas del cajero (sacar
plata, solicitar el saldo, transferir fondos), pero qu pasa si
adems necesitamos realizar un depsito en efectivo?, en ese caso
el modelo cambia un poco y entran otras entidades y procesos a
jugar.
Pgina 30 de 154

Datos, comportamiento y relaciones
de los objetos.
Durante el transcurso de este curso, aprenderemos un hermoso
camino, que comienza con la necesidad de un cliente y que
termina con una solucin para l, producto de un esfuerzo en
conjunto, una buena planificacin y un conjunto de reuniones en el
que nos sentaremos a entender el problema de nuestro cliente,
ayudarlo y asesorarlo en lo que encontremos que no est bien.
Pgina 31 de 154

Todo este proceso lo iremos documentando aplicando un conjunto
de tcnicas que veremos ms adelante, sin embargo antes de
entrar en aspectos tcnicos deberemos conocer algunos conceptos
bsicos y realizar ciertos anlisis simples, los cuales nos darn un
punto de inicio, con falencias y omisin de buenas prcticas, pero
que ms adelante aprenderemos a corregir. Durante el desarrollo
de la asignatura realizaremos mucho anlisis, sin embargo la
forma en que lo haremos no ser al azar, aplicaremos una tcnica
que ve todo como un objeto, muy similar a la forma en la que se
comporta el mundo real, el cual esta lleno de stos, monitores,
papeles, botellas, cuentas, tarjetas de crdito, personas etc. Todo
durante esta asignatura ser considerado un objeto, sin embargo
si queremos realizar un buen anlisis sobre las situaciones que nos
rodean debemos comprender qu objetos participan en ello,
hagmoslo ms simple y vemoslo a travs de un ejemplo
haciendo un pequeo anlisis de un partido de futbol. Como
podrs darte cuenta un partido de futbol no esta compuesto por
un solo objeto, es ms, si observamos con detencin podremos
concluir que existen muchos, enumeremos algunos:
1) 22 jugadores
2) Pelota
3) Marcador
4) arbitro
Si sumamos obtendremos que: 22 jugadores + una pelota + un

marcador + un arbitro dan un total de 25 objetos, si bien la suma
esta correcta, el anlisis que debemos realizar durante esta
asignatura es ms simple, ya que 22 jugadores es slo la cantidad
Pgina 32 de 154

de veces que existe el objeto jugador en la cancha, pero en
realidad el objeto es el jugador, slo podramos determinar que
ellos son objetos distintos si existiese algo que los diferencie, por
ello nos bastar con determinar que existe un objeto jugador,
quedando nuestra lista simplificada de la siguiente forma:
Jugador
Pelota
Marcador
arbitro
Volviendo al tema de los 22 jugadores, podemos a decir que si

bien todos son un jugador y por ende el objeto es uno slo, esto
no significa que los 22 jugadores sean iguales, muy por el
contrario, incluso el reglamento ordena que cada uno tenga un
nmero de camiseta distinto dentro de su mismo equipo, tambin
sabemos que cada uno tiene un nombre, un Rut, una posicin etc.
Con este pequeo anlisis podemos asegurar que todos los
objetos tienen ciertos datos asociados a ellos que permiten
identificarlos. Hagamos una lista con los datos que consideremos
son importantes para estos objetos:
Jugador
Dorsal (nmero de la camiseta)
Nombre
Posicin
Goles anotados
Pases dados
Recuperaciones
Pie con que juega
Pgina 33 de 154

Pelota
Marca
Marcador
Goles del local
Goles del visita
Arbitro
Nacionalidad
Ahora imaginemos a los jugadores, la pelota, el marcador y al

rbitro sobre la cancha sin moverse eso sera realmente un
partido de futbol? sabemos que con slo poner a todos los objetos
sobre la cancha no basta para llamar a eso un partido de futbol,
entendemos dada nuestra experiencia que los jugadores realizan
acciones y esto permitir dar un dinamismo propio de un partido,
analicemos comportamientos de cada uno de estos objetos:
Jugador
Dar pase
Hacer gol
Recuperar el baln
Pelota
Rodar
Rebotar
Arbitro
Dar tarjeta amarilla
Pgina 34 de 154

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 algn

comportamiento (una accin) que pueden realizar, sin embargo
ser posible que un jugador d pases o haga goles si no existe una
pelota y un compaero a quien darlo, pues no, esto significa que
los objetos por si solos no representan un sistema y para que
pueda llevarse a cabo el objetivo es necesario que se asocien
entre ellos, algunas interacciones relevantes en un partido de
futbol son:
Partido se asocia con Marcador

Partido se asocia con arbitro
Pgina 35 de 154

Partido se asocia con equipo
Equipo se asocia con jugador
Jugador se asocia con pelota
Al igual como lo hemos realizado ahora, siempre reconocer los

objetos, conocer las acciones que pueden realizar y con quin se
asocian nos servir como un buen comienzo para realizar un buen
anlisis posterior.
Definicin de UML
UML, cuya sigla significa lenguaje unificado de modelado, es un
lenguaje visual (basado en diagramas), que nos sirve para
visualizar y documentar el software que deseamos construir y
colaborar con la documentacin de todo el conocimiento de los
sistemas que deseamos construir, existen en UML distintos tipos
de diagramas, el objetivo de cada uno de ellos es presentar de
distintos puntos de vista una parte de un sistema, esto quiere
decir que por ejemplo una misma situacin puede ser diagramada
(dibujada) varias veces y con ms de un tipo de diagrama, donde
cada uno de ellos nos entrega un enfoque de la misma situacin
pero resaltando factores como el tiempo o el orden en el que
ocurren, sin embargo uno de los mayores beneficios es
proporcionar a todas las partes integrantes del equipo un lenguaje
comn, UML consta de una semntica y un conjunto de notaciones
que hacen que todos leamos y entendamos lo mismo de un
diagrama UML.
UML nos permite representar un sistema desde el punto de vista

esttico y dinmico, el punto de vista esttico nos muestra los
Pgina 36 de 154

elementos y como ellos se relacionan para en su conjunto dar
como resultado con xito la implementacin del sistema que se
desea construir. La vista dinmica en cambio modela el
comportamiento de alguna parte del software en algn momento
del futuro, con ello podremos aclarar ms las ideas y lo que
deseamos lograr, detectar y corregir errores antes de que sea
demasiado tarde.
Etapas del ciclo de vida utilizando

RUP (Rational Unified Process)
Un ciclo de vida en el desarrollo de software se entiende como un
conjunto de etapas que se definen para poder realizar una tarea,
en el caso de la orientacin a objetos, es muy comn utilizar una
metodologa llamada RUP (Rational Unified Process), que fue
desarrollada por la empresa Rational, hoy parte de IBM.
El ciclo de vida es una implementacin del modelo en espiral. Se

desarroll pensando en el ensamble de elementos de un contexto
determinado pasando por una secuencia de pasos semi ordenados.
La ventaja de RUP es que la estructura puede ser personalizada
segn las necesidades especficas del proyecto (de ah lo de semi
ordenadas). El ciclo de vida RUP organiza las tareas en fases e
iteraciones.
Fase de inicio
Fase de elaboracin
Fase de construccin
Fase de transicin
Pgina 37 de 154

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

caractersticas del proyecto a emprender (proyecto de tecnologas
de informacin) como el contexto del negocio6, los factores de
xito (expectativas que se quieren lograr) y tratar de definir los
tiempos y los costos (aproximados). Lo que necesitas definir en
esta etapa es si tu y tu contraparte entienden a cabalidad el
sistema. Por ejemplo debes tener presente que el proyecto est
alineado con los planes de la organizacin, que se haya
considerado en el presupuesto y que sea posible al final del
proyecto comparar los requisitos establecidos de forma inicial con
el proyecto entregado.
La fase de elaboracin: el propsito de la fase de elaboracin es

analizar el dominio del problema, establecer las bases de la
tecnologa a utilizar en el proyecto (hardware y software),
desarrollar el plan del proyecto y eliminar los riesgos ms altos del
proyecto. Las decisiones respecto de la arquitectura debern ser
tomadas considerando una vista amplia y lo ms completa del
mbito, funciones principales y requerimientos de rendimiento. La
fase de elaboracin es dnde el proyecto comienza a tomar forma.
6
Se entiende por contexto del negocio al contexto del problema a analizar, se trata de una actividad cualquiera que no
necesariamente tiene lucro de por medio.
Pgina 38 de 154

En esta fase se hace el anlisis del dominio del problema y los
proyectos de arquitectura comienzan a tomar forma.
Las salidas para esta fase son:
Un modelo de casos de uso (que veremos ms adelante)

Captura adicional de requerimientos funcionales y no
funcionales y de cualquier requerimiento que no est asociado con
un caso de uso especfico
La descripcin de la arquitectura del proyecto (hardware y
software)
Una lista revisada de los riesgos
Una planificacin de la construccin completa del proyecto,
incluyendo la planificacin de las subtareas o subproyectos que
vayas encontrando en cada iteracin.
Una especificacin de los casos especificando los procesos a
realizar
La fase de construccin: durante la fase de construccin, todos

los componentes y aplicaciones restantes son desarrolladas e
integradas al producto, y todas las caractersticas de
funcionamiento son testeadas de forma exhaustiva. La fase de
construccin es un proceso de manufactura dnde el nfasis est
puesto en el manejo de los recursos y el control de las operaciones
para optimizar los costos, el calendario planificado y la calidad. En
esta fase se realiza la construccin de cdigo y la configuracin de
la plataforma de hardware y software. En proyectos muy grandes,
se deben realizar muchas iteraciones de construccin en un
esfuerzo por dividir los casos de uso en partes que se puedan
transformar en prototipos demostrables y construibles.
Pgina 39 de 154

Las salidas de la fase de construccin son una serie de productos
que estn listos para ser utilizados por el usuario final, como
mnimo, estn compuestos por:
Una aplicacin de software integrada en una plataforma de

servicios y hardware adecuado.
Los manuales de usuario
Una descripcin de la versin actual.
La fase de transicin: el propsito de la fase de transicin es el

transmitir el producto a los usuarios de la comunidad. Una vez que
el producto ha sido entregado al usuario final, siempre van a
existir algunos problemas que van a obligar al desarrollo de
nuevos proyectos o a la correccin de parte de ellos. La fase de
transicin comienza cuando se ha alcanzado una cierta madurez de
los productos a entregar como para que estos sean probados por
los usuarios finales (aunque no estn completamente terminados).
Tambin es necesario que la documentacin para los usuarios est
disponible para que estos puedan probar la funcionalidad y
retroalimentar el proceso. Algunas tareas que es necesario
realizar:
Usuarios de prueba, para validar el sistema con las experiencias

del usuario.
Operaciones en paralelo entre el sistema antiguo y el nuevo.
Conversin a las bases de datos operacionales.
Entrenamiento de los usuarios y la gente de soporte.
Si todos los objetivos se cumplen, el punto de entrega final del

proyecto se alcanza y el ciclo de desarrollo del proyecto termina.
Pgina 40 de 154

Diagramas de Estructura.
Diagrama de clases
En el paradigma de programacin orientada a objeto (POO) todos
los componentes de un software son llamados objetos, por
ejemplo, en un software que registra las notas de un curso algunos
objetos sern, el objeto nota, el curso, el alumno y la asignatura,
no te sientas mal por que se haya tratado al alumno como un
objeto, pero en orientacin a objeto todo lo construido en un
software recibe esa denominacin, cada uno de estos objetos tiene
un conjunto de caractersticas (atributos), estados y
comportamientos que debemos conocer con anticipacin antes de
construir el software, con el fin de no cometer errores, de esta
forma lo ms adecuado es generar un plano, que indique qu
atributos, estados y comportamientos tienen cada uno (acciones
que realizan), a este plano es el que en informtica conocemos
como clase, donde tendremos que crear una clase para cada
objeto que deseamos construir, al conjunto de todas las clases se
le denomina diagrama de clases.
Una vez todas las clases han sido construidas debemos proseguir
con el paso nmero dos, el cual identificamos las asociaciones que
existen entre ellos, por ejemplo, en el ejemplo anterior una
asignatura puede contener de cero a muchos cursos (o secciones)
y cada curso puede tener entre 15 (el mnimo) y hasta 34 (el
mximo) alumnos, a su vez un alumno puede tener desde 3 a 8
notas, de aqu se desprenden dos conceptos, el primero llamado
asociacin que es la vinculacin de dos o ms clases y la
multiplicidad, que dice con cuantos objetos se asociar.
Pgina 41 de 154

El diagrama de clases por tanto se construye antes de construir el
software y es un plano de todo lo que deseamos construir. En l
van las clases que va a contener tu software y sus asociaciones,
adems podemos decir que es una forma normada de representar
un software, de esta forma todos hablamos el mismo idioma y
conocemos a priori lo que debemos construir, evitando as errores
o interpretaciones por parte del equipo de programadores.
El diagrama de clases sea probablemente uno de los diagramas en

UML ms utilizados y sirve para representar las relaciones
estticas que existen entre las clases que lo componen,
aclaramos qu significa esto, cuando tenemos una clase llamada
auto que tiene los atributos de color, velocidad, marca y modelo,
un estado (encendido o apagado) y algunos comportamientos
como acelerar, frenar, encender, etc., estamos diciendo que a
partir de esta clase vamos a construir un vehculo, pero no lo
hemos realizado an, slo definimos en un plano (clase) llamado
auto, las caractersticas y acciones que debemos construir, cuando
asociamos est clase a una clase llamada rueda podemos decir que
se asocian y que su multiplicidad es de 0 a 4, debido a que un
vehculo eventualmente podra no tener ruedas, Sin embargo,
ninguno de los dos objetos existe an, vale decir que no hay
ningn auto ni tampoco ruedas, es por esto que la relacin es
considerada esttica, ms adelante veremos que una vez
construido el objeto auto ste podr tener una rueda, dos o todas
si se las instalan y es en este momento en que la relacin se
vuelve realidad, pero fue posible slo debido a que nuestro
diagrama de clases nos guo para que pudisemos construir un
objeto con la capacidad de poder contener entre 0 y 4 ruedas.
Pgina 42 de 154

En UML una clase es representada por un rectngulo que se
encuentra sub dividido en 3 rectngulos, el primero de arriba debe
ir el nombre de la clase, el cual debe representar el objeto que se
construye a partir de esta clase, en el segundo espacio va una lista
con todos los atributos o caractersticas que deseas tenga tu
objeto y en el ltimo una lista con todos los comportamientos que
tu futuro objeto podr realizar.
Vemoslo con un ejemplo, supongamos que deseas construir un

automvil, el primer paso es definir cules son los atributos, los
comportamientos y estados que tiene un auto, para que los
agrupemos de forma tal que generemos una clase llamada
vehculo, entonces procedemos a ubicar el nombre de la clase en
el primer rectngulo utilizando la primera letra con maysculas.
Felicitaciones!, en el segundo espacio ubicaremos todos los

atributos que deseamos tenga nuestro objeto, debes tener cuidado
aqu y ser selectivo con los atributos que deseas incluir en tu clase,
si miramos un vehculo es probable que encontremos una gran
Pgina 43 de 154

cantidad de ellos, pero segn para que queramos el auto slo
sern tiles algunos, por ejemplo, si lo que deseas es utilizar el
vehculo como parte de una carrera de autos, tal vez slo nos
baste con el nombre del piloto, el modelo del auto, su categora,
nmero (nico en cada carrera) y la cantidad de vueltas que lleva.
El tercer rectngulo debe contener todos los comportamientos

(acciones) que realizar el objeto que construirs a partir de esta
clase, al igual que en el caso anterior, las acciones que pueden
realizarse con un auto son ms de las que necesitamos para este
caso, es por eso que slo seleccionaremos algunas, las cuales
pueden ser: dar vuelta, pasar a Pitt, acelerar y frenar.
Pgina 44 de 154

Listo! hemos diagramado como ser nuestra clase vehculo, la que
construiremos ms adelante utilizando algn lenguaje de
programacin, la cual podremos utilizar para construir todos los
vehculos necesitemos.
Asociaciones.
Un diagrama se dice que presenta las relaciones estticas entre las
clases con el fin de establecer qu clases se relacionarn y cual
ser su multiplicidad, en el caso anterior por ejemplo, el vehculo
no es lo nico que debemos considerar para que podamos decir
que construimos un software que permita gestionar una carrera,
as tambin tendremos que crear la clase pista con sus respectivos
atributos y comportamientos siguiendo la misma tcnica anterior,
pero si construyo ambos objetos a partir de estas clases serviran
por separado?, pues no si lo queremos realizar es una carrera, es
Pgina 45 de 154

por eso que debemos especificar una asociacin entre ellas, de
forma tal que cuando se construyan estos objetos tambin est
definida las asociaciones entre ellas, evitando as errores en la
construccin, por ejemplo, para este caso es natural que la pista
este asociada a los vehculos, para ello en el diagrama es
necesario unirlas a ambas con una lnea para representar esta
asociacin.
De esta forma sabemos que el vehculo esta asociado a la pista,

pero an nos queda determinar quien esta asociado con quien, ya
que la lnea no lo explica por si sola, pudiendo alguien pensar que
un vehculo esta asociado a 3 pistas, lo que, al menos en lo que
nosotros deseamos representar ahora no es correcto.
Pgina 46 de 154

Multiplicidad.
Uno a uno: esta relacin se da cuando dos instancias de una clase
tiene una asociacin de uno es a uno en ambos sentidos, un buen
ejemplo es el matrimonio, en el que un hombre se asocia a una
sola mujer y una mujer a un solo hombre, variables como el
divorcio, no interfieren con este ejemplo, debes tener presente que
un diagrama de clases es una foto de un momento, no de lo que
puede hacer un hombre o mujer a lo largo de su vida.
Uno a muchos: Esta relacin se da cuando un objeto esta

asociado a ms de un objeto de otro tipo, un buen ejemplo es que
una madre puede tener ms uno o varios hijos.
Pgina 47 de 154

Uno a una cantidad limitada de elementos: esta relacin se da
cuando un objeto puede estar asociada con una cantidad limite de
otros elementos, cuyo limite puede encontrarse en el nmero
mnimo o mximo, por ejemplo un curso para formarse necesita un
mnimo de 15 alumnos, pero puede tener como mximo 34,
tambin es posible que un objeto pueda asociarse con un mnimo
de cero, en este caso se define que podra no existir una
asociacin si lo requiere, por ejemplo, si tratas de lanzarte en una
carrera presidencial necesitars un mnimo de firmas que avalen tu
candidatura, este proceso de recoleccin es una asociacin de cero
a muchos, ya que podras no conseguir votos como podras tener
millones.
Mucho es a Muchos: Representa una asociacin donde un objeto

se asocia de uno a es a mucho en cualquier direccin, por ejemplo,
un alumno tiene muchas asignaturas y una asignatura tiene
muchos alumnos.
Pgina 48 de 154

Diagrama de objeto
Los diagramas de objetos son similares en su anotacin al de
diagrama de clases y son un complemento que se utiliza para
enfatizar la relacin que existe entre dos instancias de clases en un
momento especfico de tiempo, la diferencia de este diagrama es
que no se presenta como una relacin esttica con su respectiva
multiplicidad, a cambio, muestra cmo un objeto se relaciona con
otros objetos luego de haberse construido, es decir un ejemplo de
cmo se ver en el futuro en algn instante de su vida, recuerdas
el ejemplo del vehculo y su relacin esttica con una posible
cantidad de cero a cuatro ruedas?, podramos realizar un ejemplo
de la relacin con sus ruedas, pero para eso debemos tener
objetos de tipo vehculo y algunas ruedas, as que el primer paso
ser construir un objeto de tipo vehculo segn lo que definimos en
nuestra clase, por si no lo recuerdas en ella especificamos que un
vehculo tendra un color, una marca y un modelo, no te preocupes
si no sabes como armar un auto por que no lo vas a necesitar, en
informtica un objeto es slo una agrupacin de informacin y
acciones que se pueden realizar con ella, debido a esto se
considera un objeto a una agrupacin de valores dados a cada una
de los atributos definidos en el diagrama de clases, por ejemplo si
construimos un objeto auto de tipo vehculo bastar con darle un
nombre, el cual podra ser miObjetoAuto, un valor para el atributo
color, que te parece rojo, una marca, le pondremos Ford, al
modelo Mustang, y a la velocidad cero. Cuando nuestro objeto
ya esta construido es cuando las acciones que pueden realizar
toman sentido, por ejemplo si utilizas el comportamiento encender
Pgina 49 de 154

el estado del vehculo pasar de apagado a encendido y si aceleras
un clculo matemtico har que la velocidad avance de cero a uno,
como puedes darte cuenta la construccin de un objeto pasa por
dar valores a sus atributos y al igual que las clases, los objetos
tambin se pueden representar de la siguiente forma:
En lo ms alto del rectngulo est el nombre del objeto y separado

por dos puntos el tipo de objeto que es, en la parte inferior van los
atributos y los valores que tienen, as como este puedes crear
todos los objetos que desees, incluso otro con iguales valores en
sus atributos, la nica regla es no repetir el nombre del objeto,
vale decir que el prximo objeto no podr llamarse miObjetoAuto.
Esta representacin es un ejemplo que ayuda a los programadores

a entender mejor cmo se debe comportarn los objetos cuando
sean construidos. Tambin se dijo que un vehculo puede tener de
cero a cuatro ruedas y as est especificado en el diagrama de
clases, pero en el diagrama de objetos es cuando puedes mostrar
un ejemplo de cmo esa relacin luce en algn momento de la
vida de tu auto, habr ocasiones en la que el vehculo tendr todas
las ruedas y otras ocasiones en las que tendr 3 o menos. As
Pgina 50 de 154

puedes dibujar un diagrama para cada situacin que consideres
vale la pena aclarar, el siguiente ejemplo muestra un vehculo
asociado a una sola rueda, la cual proviene de una clase llamada
Rueda que define que para cada rueda se debe especificar su
marca y el aro de llanta para la cual esta hecha.
Pgina 51 de 154

Diagrama de estructuras compuestas.
La relacin de asociacin entre clases se da muy a menudo en un
diagrama de clases, sin embargo este diagrama no permite
presentar el contexto en la que la relacin deber efectuarse. Para
que sea ms clara, este caso es principalmente dado en la relacin
de composicin. Para que podamos comprender bien cmo
funciona, vamos primero a aclarar qu es la composicin en el
diseo orientado a objetos: si miras a tu alrededor podrs ver que
hay muchos objetos que se asocian con otros para realizar una
actividad, como lo son el chofer y su auto o el ascensor y el
edificio, sin embargo, es posible tener un auto sin chofer o un
ascensor sin edificio, por ello en ambos casos la relacin es de 0 a
N, vale decir que puede no tener como tambin podra tener
varios, pero hay casos en la que dos objetos dependen uno del
otro para formar un todo, si pensamos en el vehculo notaremos
que est compuesto por carrocera, motor y ruedas entre otros, o
dicho de otra forma podemos decir que se encuentran asociados
(tienen relacin), pero esta relacin en particular no es una
relacin de asociacin, dado que si bien el motor existe sin las
ruedas o viceversa, el auto no puede existir sin motor ni
carrocera, esto es debido a que el vehculo esta compuesto de
ellas, entonces, cuando hacemos un diagrama de clases podemos
especificar que dicho vehculo se asocia con un motor y que el
motor mover cuatro ruedas, pero para los que no conocen bien el
funcionamiento del auto podra ser difcil determinar que de las
cuatro ruedas dos son las de adelante y dos las de atrs, dada esta
dificultad, el diagrama de estructuras compuestas nos permite
representar esta situacin con un ejemplo, que representa algn
Pgina 52 de 154

momento de la vida del objeto cuando se est llevando a cabo la
composicin.
Abordemos con ms profundidad el ejemplo del vehculo para que

veas como el diagrama ayuda a presentar informacin del
funcionamiento interno que a simple vista no es posible apreciar,
si en nuestro diagrama de clases, decimos que un auto tiene una
relacin con un mnimo y mximo de un motor, esto quiere decir
debe tener uno de forma obligatoria y una relacin de cero a
cuatro rueda a menos que desees construir el troncomovil de
Pedro Picapiedra. A pesar de que la informacin parece clara y
completa, si analizamos ms a fondo la informacin que se nos ha
entregado comenzarn a salir dudas, por ejemplo, qu hace el
motor con las ruedas?, es el encargado de moverlas?, si fuese el
motor, debe mover las cuatros al mismo tiempo, slo las de
adelante o slo las de atrs?, o es un vehculo extrao que puede
mover las dos ruedas de un mismo lado? Con el diagrama de
estructuras estas dudas son aclaradas, presentan como un dibujo
un ejemplo del auto ya construido, es decir, posterior a llevar la
clase a un objeto, en l se dibujan las partes que le componen y
qu tipo de vinculacin tiene las partes, cules se asocian con cul
y con cuntas, as podramos dibujar de forma clara que un auto
tiene una parte llamada motor y cuatro ruedas, pero dos de ellas
son las traseras y dos las delanteras y que es el motor el
encargado de mover las delanteras. (Esto cambiar dependiendo
del tipo traccin que tenga el vehculo).
Veamos un ejemplo de cmo ser este diagrama:
Pgina 53 de 154

Diagramas de componentes.
El diagrama de componentes es un diagrama de alto nivel de
abstraccin, 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 cules se comunicarn entre
s, tal vez la palabra componente sea algo que an no te haga
mucho sentido, pero para explicarlo de otra forma, un componente
es una pieza de software, es muy similar como cuando armas un
puzzle, imagnate con un nuevo puzzle en la mano recin
comprado y llegas con l a casa para comenzar a armarlo, lo
primero que notars es que no viene armado donde slo podrs
Pgina 54 de 154

ver piezas sueltas que parecen no tener una conexin entre s, sin
embargo en la mayora de los puzzles en la tapa de la caja traen
una vista del puzzle armado podras armarlo sin eso?
Probablemente no y el puzzle al igual que el software muchas
veces se construye de la misma forma, por piezas, y alguien debe
encargarse de realizar un diagrama que muestre cmo deben
ensamblarse, tambin notars que cada pieza del puzzle esta
diseada para comunicarse con alguna otra pieza, a esto en
informtica le llamamos interfaces, la cual expone una forma de
comunicacin con otros componentes, entonces un software esta
compuesto por varias piezas llamadas componentes y cada una de
ellas tiene una o mas interfaces para comunicarse con otras, sin
embargo el software tiene una ventaja por sobre la pieza del
puzzle, ya que, en el caso del puzzle cada pieza sirve slo para
ensamblarse con una pieza en particular, en el software en cambio
las interfaces expuestas sirven para conectarse con ms de un
componente, creando piezas que permitirn tener ms de un uso.
Un componente de software es una pieza que representa un

conjunto de funcionalidades que dependern del tipo de software
va a realizar, por ejemplo, si pensamos en un software que va a
permitir que los usuarios utilicen una pgina web, en la cual
pueden chatear luego de registrarse y cumplir con ciertas
condiciones, los componentes seran los siguientes:
Componente de negocio: un componente encargado de aplicar

clculos matemticos o de verificacin de formato de datos para
saber si un usuario cumple con los requisitos que le pide el
software para poder registrarse, por ejemplo, si es mayor de edad,
si escribi su nmero de celular respetando el formato solicitado.
Pgina 55 de 154

Componente de pginas Web: el cual representar un conjunto
de pginas web con las que el usuario va a interactuar.
Componente de chat: el cual va a representar un software ms

pequeo (conjunto de clases) que permitir a los usuarios
comunicarse entre si en tiempo real.
El siguiente dibujo muestra cmo debe representarse un

componente.
Para que un componente pueda comunicarse con otro componente

debe tener lo que se conoce como interfaces, una interfaz es un
punto de entrada para que otros componentes puedan obtener del
l el servicio que presta, un buen ejemplo es un componente que
valida el Rut, es posible que si deseas registrarte en una pgina
Web y entre los datos que solicitas est el Rut, es muy probable
que desees que el Rut sea vlido, para llevar a cabo esto el
componente de negocio tendr entonces una interfaz que permita
recibir el Rut para luego informar si esta correcto o no, este
componente a travs de dicha interfaz, podra reutilizarse en todos
los software que requieran validar el Rut, de esta forma tenemos
un componente de software que a diferencia de la pieza del
Pgina 56 de 154

puzzle podemos volver a utilizar en cada software en el que se
necesite.
Una interfaz se representa de la siguiente forma:
Diagrama de despliegue.
El diagrama de despliegue es un diagrama que permite mostrar la
relacin fsica que tendrn los componentes de software y
hardware de un sistema, la mayora de los programas de hoy
estn distribuidos en ms de un computador, un buen ejemplo es
el Windows Live Messenger o Gtalk, estos software presentan ante
el usuario una ventana para que stos puedan escribir un mensaje
y enviarlo a otros usuarios, pero has pensado que sucede al
presionar el botn enviar?, pues al hacerlo los datos son tomados
y son enviados a otra aplicacin, la cual posiblemente est incluso
en otro pas, este software es el encargado por medio de una
interfaz de recibir tu mensaje, ubicar al destinatario y envirselo
para que lo pueda leer. Como puedes ver la aplicacin que instalas
en tu computador de poco servira sin la otra, la cual es la que
hace posible que cientos de miles de personas se comuniquen, ese
equipo que presta el servicio de comunicar se le denomina
Pgina 57 de 154

servidor, nombre que se le puede aplicar a todo equipo que
preste algn servicio, as como este ejemplo existen muchos, que
incluso tienen componentes en ms de dos equipos. Cuando se da
este tipo de casos el diagrama de despliegue nos sirve para ubicar
en que Hardware (en que equipo fsico) debe ir cada componente
para que los encargados de instalar el software sepan como
hacerlo, por supuesto esto no es una receta de cocina, tambin
hay miles de otros software donde todos sus componentes van en
el mismo lugar, en dicho caso el diagrama de despliegue ser
mucho menos necesario.
Un ejemplo del caso mencionado lucir as:
Cada uno de los cuadrados dibujados con profundidad son

denominados nodos y representan un equipo donde se realizar la
instalacin, por ejemplo el software de chat esta instalado en el
cliente y el segundo componente, el cual se encarga de reunir a
todos los componentes de chat para que puedan comunicarse esta
en el equipo denominado servidor.
Pgina 58 de 154

Diagrama de paquete.
El diagrama de paquete sirve para formar una mejor visin de qu
queremos construir, para ello lo divide en subsistemas ms
pequeos, la agrupacin de los elementos se define en funcin de
algo que ellos tengan en comn y que los identifique como grupo,
para luego mediante flechas representar la dependencia que existe
entre ellos, es decir los elementos de un grupo que dependen de
otro que se encuentran en un grupo distinto, esto se hace para dar
orden y claridad en el diagrama, de esta forma evitamos tener
ciclos dentro de nuestra estructura, conoces el dilema de si es
primero la gallina o el huevo?, pues casos similares a estos
tambin se dan en el software, la dependencia es un tema que hay
que tomar muy en serio a la hora de construir un programa, un
error de dependencia de software sera el equivalente a tratar de
hacer una vela en una caverna sin luz, donde para realizarla
necesitas luz, pero para generar luz necesitas la vela, como
puedes ver hay una dependencia mutua que hace imposible que
podamos generar la luz necesaria, en el software esto tambin se
da: imaginemos que estamos en un lugar donde arriendan internet
y en cada equipo hay una aplicacin que bloquea el teclado cuando
recibe la orden desde el computador del encargado del lugar,
adicionalmente para que los usuarios no puedan engaar al
sistema y piensen en apagar y encender el equipo el software para
iniciar tiene un componente que busca en la red si el equipo del
operario esta activo para regular el uso, de no ser as el sistema no
permite usar el equipo y lo apaga, por otra parte el sistema del
operario tiene un componente que se encarga de verificar cules
computadores estn funcionado en la red para que puedan ser
gestionados, pero si no encuentra ninguno la aplicacin se cierra.
Pgina 59 de 154

Cuando llegue la noche y apagues todos los Pcs, al da siguiente no
podrs volver a usar el sistema, dado que el software del operario
espera a los clientes y el software que est en los clientes espera
al operario.
El error de lgica anterior que refleja una dependencia de

componentes puede ser an peor dentro de la construccin del
software, dado que mientras desarrollas un programa puedes
cometer tambin un error de dependencia, es decir, puede verse
afectado por esto incluso mucho antes de que el programa
concluya, Cmo es esto posible? Muy sencillo, imagina que dentro
de tu software para crear un archivo utilizas el componente
llamado creador de archivos y este a su vez mediante su interfaz
espera un componente llamado leerDisco el cual verifica que el
espacio sea suficiente en el disco, el problema es que la
informacin del disco en el que se quiere guardar el archivo va en
el componente creador de archivos, el cual para iniciarse
requiere que mediante su interfaz el componente leer disco le
entregue la informacin necesaria para escribir el archivo, en este
caso el software nunca podr instalarse, dado que hay dos
componentes que estn iterativamente esperando al otro para
poder iniciarse.
De esta forma el diagrama de paquetes permite ver de forma

agrupada en paquetes los elementos que componen el software,
uniendo los paquetes con lneas discontinuas entre aquellos que
exista dependencia de algn tipo.
Pgina 60 de 154

Diagramas de comportamiento.
Diagrama de casos de uso.

Este tipo de diagramas es esencialmente til durante la etapa de
anlisis, es decir cuando estas comenzado a entender lo que
necesita construir tu cliente, ya que su finalidad es describir los
actores que interactan con el software y los procesos que deben
realizar. Un actor se considera a cualquier elemento que interacta
con tu programa, que pueden ir desde otros software, un robot o
humanos, el caso de uso se refiere a todas las acciones que tu
software realizar, por ejemplo si estas considerando realizar un
software que simule una agenda entonces tendrs un solo actor,
(el encargado de agregar informacin a la agenda) y los procesos
o casos de uso que realizar sern, agregar un contacto, agregar
una actividad a realizar, ver las actividades pendientes, verificar
los datos de un contacto previamente agregado, etc. De todas
estas acciones no es necesario tener con toda claridad toda la
Pgina 61 de 154

lgica que hay tras el proceso, la idea principal es slo identificar
los procesos y quin es el encargado de realizarlos. Este tipo de
diagramas es muy til para apoyar el proceso de anlisis con tu
cliente sobre lo que deseas que haga el software, debes considerar
lo difcil que es para ellos explicar sus necesidades de programa y
ms an todos los procesos que ellos mismos quieren realizar,
donde olvidar alguno podra ser catastrfico, para el software, para
tu cliente y para ti, ya que terminar agregndolo al final,
trabajando ms de lo pactado y potencialmente atrasando la
entrega. Es posible pensar que si se ha olvidado de algo la
responsabilidad sea del cliente, en parte s, pero tambin debes
recordar que t eres el experto y si notas que la ausencia de un
proceso generar un problema en el software es parte de tu
trabajo advertirlo. Todos los procesos que deseen incluirse
posteriormente deben ser pactados como un nuevo requerimiento,
lo cual tendr un nuevo costo para el cliente.
Un actor en un sistema es representado con un dibujo de persona

con cuerpo de palito, el siguiente ejemplo representa un actor y su
respectivo rol en el software.
Actor1
Pgina 62 de 154

Un actor es el encargado de ingresar informacin al software, es l
quien a travs de las interfases que tiene el sofware agrega la
informacin que se desea almacenar y procesar, tambin es quien
recibe la informacin procesada en el momento en que lo requiera.
Un caso de uso, por otro lado, permite mostrar la forma en que el

sistema presenta sus procesos para que sean usados por los
distintos usuarios que interactan con el.
El siguiente ejemplo muestra cmo un actor interacta con la

agenda, especificando que el actor realiza una accin llamada
agregar contacto.
Segn los requerimientos que desees modelar, puedes agregar

ms procesos dentro del mismo diagrama o dibujarlos por
separado segn lo necesites, agregando todos los procesos que
requieras que se encuentren asociados a un mismo actor o bien
agregando un segundo actor y todos sus procesos.
Agregar Contacto
Buscar contacto
Actor1
Pgina 63 de 154

Diagrama de mquina de estados.
Este diagrama muestra los estados por los que pasa un nico
objeto en respuesta a los eventos que este efecta.
Para que lo entendamos mejor primero veamos lo relativo a los

estados, un estado es una condicin en la que se encuentra un
objeto en un determinado momento de su vida, esto sucede en
cualquier orden de cosa, a tu alrededor podrs encontrar muchos
ejemplos, tu mismo tienes varios estados: alegre, triste,
concentrado, etc. Sin embargo para que estos eventos vayan
cambiando debe suceder algo para que tu estado cambie. Por
ejemplo, si hoy por la tarde llegas a casa y descubres que eres el
nico ganador de un millonario premio, seguramente tu estado
pasar a ultra feliz al borde del colapso nervioso, sin embargo
para que esto ocurra ha tenido que suceder lo que denominamos
un evento, en este caso particular al evento le podramos llamar
ganar la lotera, al igual que en este ejemplo, en el software los
objetos que lo componen tambin pasan por eventos, los cuales
van cambiando su estado, un ejemplo sencillo puedes verlo en tu
navegador, cuando haces clic en el cono por primera vez el estado
inicial de este es a la espera en la que el navegador no esta
haciendo otra cosa que esperando que hagas algo, cuando escribas
una direccin de internet y presiones el botn de bsqueda, habrs
generado un evento en l, el cual podramos llamar buscar este
evento har que el navegador pase del estado en el que se
encontraba a un nuevo estado que podramos llamar mostrando
pgina en el que el navegador lee la informacin que le llega de
internet para mostrrsela al usuario, as puedes identificar varios
Pgina 64 de 154

eventos que cambiarn el estado de tu navegador, por ejemplo si
haces clic en el botn para minimizar o maximizar.
Este diagrama presenta el estado inicial del objeto y va

representando con flechas acompaadas de un nombre el evento
que se ejerci sobre el objeto, para luego finalizar en un nuevo
estado, se puede ver un ejemplo en la siguiente figura:
En el diagrama de estados se debe definir un comienzo y un final,

de esta forma podremos saber cul es el estado inicial y cul es el
final.
Para especificar el estado inicial se utiliza el siguiente smbolo:
Y para el estado final se debe utilizar:
Quedando el diagrama completo de la siguiente forma:
Pgina 65 de 154

Se podra pensar que en un diagrama de estados el estado inicial y
final podrn omitirse debido a que las flechas determina la
direccin en la que los estados van cambiando, sin embargo estos
no pueden omitirse debido a que un diagrama de estados no es
necesariamente lineal, por ejemplo, una persona podra pasar de
estar divorciado a casado si vuelve a contraer matrimonio, sin
embargo si vuelve a romper su relacin volver a estar divorciado,
este ejemplo es representado en la siguiente imagen:
De esta manera queda definido que nuestro objeto sin importar la

combinatoria que realice siempre finalizar casado.
Diagrama de actividad.
Este diagrama es muy similar al diagrama de mquinas de estado,
la diferencia principal es que en el diagrama de actividad no
muestra los estados de los objetos si no que modela cmputos y
flujos de trabajo, especificando el orden en el que se llevan a cabo,
adems se asume que no existen interrupciones externas para
dichos flujos, de ser as ser mejor modelar utilizando el diagrama
de maquina de estados visto previamente.
Pgina 66 de 154

En este diagrama se modelarn uno o ms estados de actividad,
donde cada uno de ellos representa el funcionamiento de una
actividad que ocurre en un flujo de trabajo, para cada flujo es
necesario definir un inicio y de all se da paso a la ejecucin de la
primera actividad, cada una va inicindose conforme va
terminando su actividad predecesora, lo que implica que es el
termino de una actividad dentro del flujo la que da inicio a otra,
este diagrama permite adems modelar bifurcaciones dentro del
diagrama, de esta forma segn el resultado de la actividad que se
ha ejecutado es posible tomar ms de un camino, en otros casos y
segn se requiera tambin es posible que dos actividades se
ejecuten de forma simultanea.
Veamos un ejemplo, supongamos que hoy vas al teatro, el proceso

es relativamente simple, vas, pagas, si gustas dejas tus datos para
futuras promociones y luego de cancelar se asigna un asiento para
ti. Para modelar este flujo representaremos en un diagrama de
actividades cada una de ellas como un cuadrado con los vrtices
redondeados y en el centro el nombre de la actividad, tambin
utilizaremos una flecha que una las actividades para poder
modelar el orden en el que se ejecutan.
Por lo tanto cada uno de las actividades descritas deber ir de la

siguiente forma:
Pgina 67 de 154

El orden en el que se ejecutarn son modelados con una flecha
que ndice que orden del flujo del proceso.
Si el trmino de una actividad puede dar inicio a ms de una

actividad dependiendo de alguna condicin la bifurcacin que all
se produce se representa con un rombo:
Diagramas de Interaccin.
Diagrama de secuencias.
El diagrama de secuencia es un diagrama que muestra la forma en
la que interactan los objetos dentro de un software agregando el
factor tiempo, de esta forma se puede visualizar el orden en el que
se ejecutan las llamadas en forma ordenada a partir de una
peticin, la mayora de las veces con un diagrama de caso de uso
es suficiente para comprender como interactan las partes, sin
embargo hay algunos casos en los que el proceso puede ser ms
complejo o requiera una explicacin mayor, es por ello que el
diagrama de secuencias viene casi siempre a partir de un caso de
uso especifico.
Pgina 68 de 154

Para representar los objetos en este diagrama UML utiliza
rectngulos con sus nombres subrayados.
La diferencia es que abajo del objeto agregaremos una lnea

segmentada que simbolizar el tiempo de vida del objeto durante
el proceso que deseamos representar de la siguiente forma:
El paso se siguiente es dibujar las llamadas entre los objetos si es

que las hay, una llamada har que un objeto realice alguna accin
que tarda algn tiempo, la cual al finalizar podr realizar otra
llamada para ejecutar alguna tarea de otro objeto o de el mismo si
es necesario. Veamos con un ejemplo que representa la
interaccin entre las personas de un restaurante, veremos como
interacta el cliente, el mesero, el cocinero y el encargado de la
caja, a travs de este ejemplo veremos el orden en el que
participa cada uno, tambin permite apreciar cuando una actividad
comienza y cuando otras terminan.
Pgina 69 de 154

Como puedes ver en el diagrama, al seguir la lnea de tiempo del
cliente vers que se une con el mesero con una lnea (una
llamada) que simboliza el momento en el que se ordena la cena al
mesero, a partir de ese momento ambas lneas tienen un
rectngulo, lo cual significa que la llamada que hace la solicitud de
comida activa a ambos (cliente y mesero) por lo cual los dos
Pgina 70 de 154

generan una accin, cuando ambos se han puesto de acuerdo el
mesero solicita al cocinero que prepare el plato, a partir de ah, el
cliente y el mesero quedan a la espera mientras el cocinero
prepara el plato, como el proceso de preparar el plato tarda
tiempo, el mesero aprovecha para servir la bebida al cliente, luego
la interaccin entre el cliente y el mesero vuelve a quedar a la
espera, tiempo despus el cocinero hace una llamada al mesero
(entrega), en el cual le entrega el alimento al mesero, cuando eso
sucede slo el mesero comienza a tener actividad, el cual
corresponde al tiempo en el que el mesero prepara la bandeja y
lleva la comida al cliente, cuando sta es entregada el mesero
queda en actividad, sin embargo el cliente queda con la
satisfactoria tarea de comer lo que ha solicitado y disfrutar un
momento de su familia, los cuales posiblemente estn celebrando
que su hijo ahora es estudiante de educacin superior y que ahora
lee este manual, cuando finalizan de cenar pagan y as finaliza el
proceso.
Diagrama de tiempo.
Este diagrama permite mostrar el cambio de estado o valor de los
elementos a travs del tiempo, prcticamente todos los objetos
durante su vida van cambiando sus valores o estados y muchas
veces estos cambios son producidos por factor que tiene relacin
con el tiempo, antes de continuar es bueno aclarar que el estado
la mayora de las veces tambin produce un cambio en el
valor del objeto, por ejemplo, si tienes un termmetro digital,
Pgina 71 de 154

que acompaa la temperatura con un mensaje que dice mucho
calor es por que el valor de los grados Celsius es mayor a 25,
cuando dicho valor baje a 18, el estado cambiar a templado .
Con este diagrama puedes mostrar los cambios de estado por los
que pasa un objeto a travs del tiempo, un ejemplo sencillo es el
funcionamiento de una lavadora, ya que, las lavadoras
actualmente se encargan de pasar por varios procesos, determina
el peso de la ropa, llena el tambor con agua, lava, enjuaga y
centrifuga, este proceso por ejemplo esta definido en funcin del
tiempo, para diagramar esto, utilizaremos un grafico con
coordenadas X e Y, donde el eje X representa el tiempo e Y los
estados, as como muestra el siguiente figura:
Pgina 72 de 154

Pgina 73 de 154

Pgina 74 de 154

Tcnicas de recopilacin y
anlisis de requerimientos.
Tcnicas de captura de
requerimientos.
Por lo general las personas que hacemos software nos encanta, es
un entretenido reto que se lleva en conjunto con un equipo de
trabajo, en el cual ponemos todo nuestro esfuerzo en construir un
software que utilice datos provenientes de nuestros clientes, los
procese para luego entregar informacin relevante para ellos, la
cual por lo general va agrupada y ordenada segn ciertos criterios,
sin embargo muchos software tienen defectos y cuando digo esto
no me refiero en particular a que cada cierto rato muestren un
mensaje de error o produzcan una cada en el rendimiento de
nuestro equipo, sino que, muchos software que nacen de una
necesidad del cliente pero que no cumplen con lo que el cliente ha
solicitado, veamos el siguiente ejemplo para ilustrar el concepto,
supongamos que hoy te regalar el auto de tus sueos y lo mejor
de todo es que el vehculo ser como tu lo especifiques, como
muchos que lean este libro sus requerimientos sern mas o menos
as:
Llantas aro 17.

Deportivo.
Motor muy poderoso.
De algn color que te guste.
Pgina 75 de 154

Ahora supongamos que ha pasado algn tiempo, y he venido a
entregar el vehculo, aquel que esperas con muchas ansias y
medida que ves que lo van bajando del camin estas cada vez ms
contento cuando descubres que tiene unas llantas preciosas, que el
color es tal y cual lo imaginaste, en la cola del vehculo pone un
numero que dice 3.5 haciendo referencia la cilindradas del motor,
al fin el auto esta en el suelo y el encargado de construirlo hace un
gestos de amabilidad para que te acerques a recoger tus llaves y
entres al vehculo, una vez adentro sin mirar ms pones la llave,
haces contacto y escuchas como ruge el motor mientras te
imaginas la expresin de tus amigos cuando te vean en el, ha
llegado el momento, estiras las piernas para acelerar y descubres
que no hay pedales, pensando que a lo mejor es acelerador esta
en el manubrio comienzas a palpar la parte de atrs pero no
encuentras nada, a tu derecha notas la ausencia de una caja de
cambios, de aire acondicionado, de la traccin de las ruedas ni
hablar, apenas el motor esta conectado al sistema de arranque, no
hay tacmetro, no hay luces y as sigue, muy enojado bajas del
vehculo y encaras al encargado, el cual mira el documento en el
que especificaste lo que necesitabas, hace una revisin y te das
cuenta que todo lo que pediste esta ah y que en realidad reclamas
por lo que no hay que jams pediste, Quin es el culpable? El
mecnico? T por no especificar bien lo que necesitas? Y la
respuesta es ambos, el problema que aqu hubo es de
comunicacin, a pesar de que da la sensacin es que es ms
culpable el mecnico es por que tu sabes los comportamientos que
un vehculo debiese tener, pero, que pasa cuando tratamos de
construir algo que el cliente ni el constructor conocen? Aqu es
cuando el asunto se pone difcil, en el anlisis de requerimientos
Pgina 76 de 154

esta situacin se da mucho ms habitual de lo que perece, la razn
de ello se debe a que la persona que debe construir el software
debe hacerlo de forma tal que se adecue a las necesidades de una
empresa que la cual no conoce sus procesos, pero por otra parte
el cliente conoce bien su empresa, pero jams ha hecho software.
Mucho antes de siquiera pensar en como construir un software

encontraremos la etapa de captura de requerimientos, esta etapa
es de vital importancia para lo que viene luego, ya que, es durante
esta etapa en la que obtenemos los requerimientos (las
necesidades) desde nuestro cliente, en la que mediante
conversaciones, formularios, encuestas u otras formas obtenemos
la informacin sobre los procesos del negocio que desean el apoyo
de software, es muy comn que se confundan la palabra requisito
y requerimiento, sin embargo en informtica no debieses ser
utilizadas de forma indistinta, los requerimientos son la palabra
ms comn usada por las personas y viene de la necesidad de
algo, por lo tanto, la palabra correcta para definir las necesidades
que tiene tu clientes debe ser requerimiento, otra forma de
explicar lo mismo es la ubicar la captura de requerimiento en el
tiempo, con esto nos referimos a que en algn lugar existe una
persona con un problema o necesidad de mejora para la cual
necesita una solucin que pasa principalmente por un conjunto de
herramientas informticas que apoye uno o ms de sus procesos,
cuando el profesional encargado de suplir esa necesidad se acerca
a conocer los procesos que la empresa realiza para las cuales
necesita un apoyo informtico y lo que realmente la empresa
necesita de ellos para mejorar o solucionar una carencia estamos
hablando entonces de requerimientos.
Pgina 77 de 154

Pressman dice Ingeniera de Requerimientos ayuda a los
ingenieros de software a entender mejor el problema en cuya
solucin trabajarn. Incluye el conjunto de tareas que conducen a
comprender cul ser el impacto del software sobre el negocio,
qu es lo que el cliente quiere y cmo interactuarn los usuarios
finales con el software.
El proceso de toma de requerimiento, puede ser una tarea difcil y

que requiere trabajo y una habilidad para tratar y comprender a
las personas con las que se entrevista, muchas personas siempre
consideraron al informtico como un ermitao que vive frente a un
computador, pero se equivocan, por que son ellos los encargados
de extraer de sus clientes las necesidades que permiten el
desarrollo de una solucin, por lo general durante la toma de
requerimientos descubrirs que los propios usuarios no saben lo
que quieren, adicional a lo anterior la tarea se vuelve algo mas
compleja debido a que los usuarios no tienen una visin como
conjunto, lo que provocar que escuchars versiones distintas de
una misma necesidad dependiendo a quien se entreviste, a lo
anterior, como si fuera poco, debes agregar que muchas veces los
requerimientos no son detallados correctamente, lo que suele
conducir a error y a incongruencias entre los clientes , es por esto,
el encargado de la toma de requerimiento debe tener una habilidad
que le permita mediar con ellos, ya que descubrir con el tiempo
que una misma necesidad es vista de distintos puntos de vista
segn a quien se entrevista y en muchos casos descubrirs que ni
ellos tienen claridad de lo que realmente desean.
Lo que debemos obtener de una buena toma de requerimientos es

enumerarlos, comprender el contexto en el que se encuentran.
Pgina 78 de 154

Para lidiar con esto hoy aprenderemos algunas tcnicas de
extraccin de requerimientos desde el cliente, las cuales son:
entrevista, encuesta y observacin directa, ms adelante en
asignaturas posteriores vers metodologas ms elaboradas sobre
la captura de requerimientos, las cuales consisten en un conjunto
de tcnicas, sin embargo en este semestre veremos tres de las
formas mas naturales de comunicacin existentes para extraer
informacin.
Entrevista.
La entrevista es posiblemente la forma ms natural y rpida de
comunicacin con una persona, en informtica la entrevista debe ir
enfocada a aquellas personas que ms conocen sobre los procesos
de la organizacin y a las personas que utilizarn el sistema, estas
entrevistas pueden ser individuales o grupales y se recomienda
hacerlas cada cierto tiempo, ya que vers que los requerimientos
van a ir cambiando producto de la falta de entendimiento que los
clientes suelen tener sobre sus propios procesos.
Encuesta.
Las encuestas son documentos que tienen un conjunto de
preguntas relevantes del sistema que se desea construir, de esta
forma podemos obtener informacin ms precisa sobre los puntos
sobre los cuales necesitamos una respuesta cerrada, las preguntas
se hacen de forma verbal al encuestado, siendo el mismo
encargado de marcar la respuesta segn lo que el encuestado
haya dado como respuestas, las encuestas puede llevar preguntas
abiertas o de seleccin mltiple, en la que los encuestados debern
seleccionar una alternativa, esta tcnica es buena cuando lo que
Pgina 79 de 154

deseas es obtener informacin puntual desde un grupo grande de
personas que no pueden reunirse ya sea por horario o por
limitaciones de espacio.
Observacin directa.
Esta tcnica consiste en que el encargado de la toma de
requerimientos observa las personas mientras realizan su trabajo,
de esta forma se conoce cules son los procedimientos que se
realizan, quines son los encargados de hacerlos y cul es el orden
en el que se ejecuta.
Definicin de actividades.
Una vez los requerimientos han sido extrados del cliente
pasaremos a una nueva etapa en la cual tomaremos cada uno de
los procesos del cliente y lo dividiremos en actividades ms
pequeas, las cuales juntas y en algn orden en particular dan
como resultado alguna accin que deseamos convertir en software
ms adelante, por ejemplo, si existe un proceso en el que los
clientes compran utilizando el mtodo tradicional y esto lo quieres
llevar a un servicio de pago por internet, debes determinar todas
las actividades que hay que realizar para lograrlo, en este caso las
actividades a realizar comienzan por construir una pgina web con
un catalogo de productos donde el usuario pueda especificar el o
los productos que quiera comprar, luego una interfaz de pago que
permita ingresar el nmero de la tarjeta bancaria con la que se
desea realizar dicho pago, la informacin ingresada deber
enviarse al banco que corresponde, slo si esta habilitada y el
monto disponible para compra supera el valor del producto,
entonces se genera la venta, esta venta es registrada por el
Pgina 80 de 154

software y en ella incluye los datos del comprador y algunos datos
de la venta, como la fecha, el total y el detalle, el cual consiste en
una lista de los productos que compr.
Adicionalmente a lo anterior, para que un cliente pueda comprar

en una pgina web que permita navegar por los productos,
seleccionarlos y comprarlos, ser necesario unos cuantos pasos
previos, ya que dichos productos deben ser agregados a la pgina
antes de que el cliente navegue por ellos, entonces, alguien debe
ingresar la informacin de los productos, subir sus fotos,
establecer el valor y agregarlos a la categora que corresponde,
adicionalmente especificar algn tipo de descuento si lo hubiese.
Si hacemos un mejor anlisis de la situacin notars que hace un

momento acordamos que cuando un cliente realiza una compra la
informacin que almacenaremos incluir los datos del comprador,
es por ello que antes de la compra hay una actividad que
corresponde al registro del usuario, en la cual se almacenan los
datos del mismo.
Es muy probable que la necesidad de transformar en software este

flujo tenga principalmente dos objetivos, el primero, una mejora
en la forma en la que las personas obtienen los productos,
cambiando de la tradicional, en la que el cliente deba salir de su
hogar para adquirir los productos a una cmoda, rpida y gil
forma de comprar sin salir de su hogar, la segunda razn es que al
tener la informacin de las ventas la organizacin podr llevar de
mejor forma su contabilidad y podr tomar mejores decisiones
basadas en los reportes que el sistema entregar, como por
ejemplo, los productos ms vendidos, las fechas de mayor compra,
lo que alertar aquellas temporadas en las que hay que tener una
Pgina 81 de 154

mayor cantidad de stock de productos, estos informes se
generarn de forma automtica por el sistema en respuesta a una
solicitud de quien los desee ver, todo esto a cambio de lo que
antes deben haber sido engorrosas planillas o largas sumas y
restas realizadas en papel.
A pesar de que pereciera que la lista de actividades para un portal

de ventas esta completa, ms adelante con un mejor anlisis
veremos que lo aqu descrito no es slo una pequea parte, que
por ahora obviaremos.
Relacin entre las actividades y los

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

Anlisis bsico de los
requerimientos para la realizacin
de un listado de actividades.
En los procesos de anlisis de requerimientos siempre se
determinan necesidades mltiples para las organizaciones que se
estn estudiando. Es necesario por lo tanto que determines un
mbito de accin para tu proyecto, y de esta forma dar una
solucin acotada y precisa. Lo primero que debes tener en cuenta
es que las organizaciones siempre tienen una razn de ser y esta
razn de ser determina las actividades que la organizacin realiza.
Por un tema de complejidad de las organizaciones, poseen
diferentes procesos que dan soporte a la realizacin del quehacer
de la organizacin y adicionalmente otra serie de actividades que
si bien no son parte del quehacer de la organizacin, estas sirven
de soporte a estos procesos principales. Por ejemplo, el propsito
de la panadera es hacer y vender pan (proceso principal), pero
adicionalmente necesita realizar proceso tales como hacer aseo,
comprar materiales, contratar personal, etc. Como te puedes dar
cuenta existe una gran cantidad de operaciones que pueden ser
realizadas como soporte de las actividades principales, y mientras
ms compleja sea la organizacin, ms complejas sern las
actividades de soporte y ms especficas.
Cuando ests analizando requerimientos, es importante que

puedas agrupar las actividades que ests analizando. Este
agrupamiento de actividades permitir que analices los procesos y
las necesidades de la organizacin de forma mucho ms eficiente
(aplicando la teora de sistemas). Una vez que hayas agrupado los
Pgina 83 de 154

requerimientos en relacin a su funcionalidad es necesario que
determines los grados de importancia de los requisitos
identificados. El grado de importancia esta asociado a los procesos
que realiza la organizacin como parte de su quehacer. Debes
considerar que para cualquier organizacin los requerimientos
principales a considerar son aquellos que tienen que ver con el
quehacer de la organizacin, es decir con los procesos que hacen
que la organizacin funcione.
Con todos estos antecedentes a la mano es posible ahora realizar

un listado de los principales requerimientos y ordenarlos en
funcin de las principales necesidades de la organizacin. Este
listado servir entonces para realizar un listado de actividades que
deben ser realizadas para poder alcanzar los requerimientos. Este
listado de actividades te dar la pauta para poder definir las
actividades importantes en el desarrollo de tu proyecto, y en que
cosas debes fijar tu atencin al momento de planificar y desarrollar
el proyecto.
Pgina 84 de 154

Diagrama de flujo de datos (Agile
Unified Process).
Los diagramas de flujo de datos (DFD) fueron herramientas muy
utilizadas por la metodologa estructurada como una forma de
representar los flujos de datos entre las entidades externas y el
sistema que se estaba analizando. Adicionalmente a este anlisis
los DFD permiten mostrar el flujo de datos entre cada uno de los
procesos que componen el sistema y su almacenamiento lgico.
Para construir estos diagramas existen cuatro elementos

principales:
Los rectngulos representan entidades externas, las cuales son

orgenes o destinos de los datos, es decir son todas aquellas cosas,
personas o sistemas que aportan o reciben datos como resultado
del proceso.
Pgina 85 de 154

Los rectngulos redondeados representan los procesos, los cuales
toman los datos de entrada para hacer algo (un proceso) y
generan una salida.
Las flechas representan los flujos de datos, los cuales viajan entre
las entidades y los procesos y entre los procesos y los almacenes
de datos.
Finalmente un rectngulo con el lado derecho abierto representa

un almacn de datos, el cual puede ser un archivo, un documento
en papel, un archivador o cualquier cosa que pueda almacenar
datos de un proceso que nos interese.
El proceso de generacin de estos diagramas consiste en definir un

escenario para con esa informacin definir las entidades y los
procesos que se realizan. Una vez que hayas definido el escenario
comienzas a dibujar las entidades en el lado izquierdo del
diagrama, a continuacin defines los procesos que se realizan en el
Pgina 86 de 154

sistema y unes a estas entidades con los procesos. Recuerda que
esta unin entre procesos y entidades no se realiza al azar sino
que es fruto de un proceso de anlisis en el cual se identifica si la
entidad entrega o recibe datos de un proceso en particular, para
muestra el siguiente ejemplo.
Fjate que en el contexto del sistema de compra en lnea, el

proceso de validacin de usuario est relacionado con la entidad
usuario que es la que enva los datos y estos se buscan en el
almacn de datos del usuario, estos datos son analizados por el
proceso de validacin de datos y con esto se generan los permisos
de acceso del usuario de esta misma forma se van a analizando y
uniendo las entidades con los procesos, los procesos con otros
procesos, los almacenes con los procesos, la siguiente tabla
muestra la relacin existente entre cada uno de los elementos del
diagrama mediante los flujos de datos que son los conectores.
Entidad Proceso Almacn
Entidad NO SI NO
Proceso SI SI SI
Almacn NO SI NO
Pgina 87 de 154

Utilizando esta tabla anterior, podemos definir algunos ejemplos de
cosas que jams podras hacer:
En el caso anterior, si bien en la vida real el profesor y el alumno

se relacionan, en el caso del uso de un sistema ellos nunca
conversan pues ambos conversan por separado con el sistema y
finalmente eso es lo que nos interesa reflejar en este anlisis.
En el ejemplo anterior, las entidades nunca pueden enviar un flujo

de datos directamente al almacn, pues siempre los datos al
menos pasan por un proceso de validacin antes de ser guardados
en un almacn de datos.
Pgina 88 de 154

Como puedes ver los almacenes de datos tampoco se pueden
relacionar, pues al ser slo repositorios, ellos no pueden ejecutar
ninguna accin, slo almacenan datos.
Adicionalmente a lo visto existen algunas otras reglas que debes

observar respecto a los DFD:
a) Todos los procesos deben tener al menos un flujo de entrada y

uno de salida.
Estos son ejemplos vlidos.
Pgina 89 de 154

Estos son ejemplos no vlidos.
b) Todos los procesos deben modificar los datos de entrada

produciendo nuevas formas de datos de salida. Algunos
procesos comunes son validaciones, ordenamientos, bsquedas,
etc.
c) Cada uno de los almacenes de datos debe tener al menos un
flujo de datos, ya sea de entrada, salida o actualizacin de
datos.
d) Cada una de las entidades externas debe estar relacionada con
al menos un flujo de datos.
e) Cada flujo de datos debe estar asociado al menos a un proceso.
Si bien estos diagramas son una buena alternativa para

representar la relacin entre las entidades, los procesos y los
almacenes de datos utilizando para esto los flujos de datos,
tambin es necesario mantener el control respecto a la
complejidad de los procesos representados. Utilizando conceptos
de teora de sistemas, trata siempre de mantener los diagramas lo
ms simple posibles, si el diagrama no es suficiente, lo puedes
documentar, es decir puedes definir por escrito los procesos y el
trabajo que cada uno de los componentes realiza en el contexto
del problema.
Pgina 90 de 154

Diagrama de procesos (BPMN 2.0)
Cuando ests trabajando, muchas veces tendrs que realizar
anlisis de sistemas que son muy complejos. Una herramienta que
te permite representar grficamente los sistemas es utilizando un
diagrama que se llama BPMN, Business Process Model and
Notation (BPMN) es decir Modelo de Procesos de Negocio y
Notacin.
Esta es una notacin grfica que describe los pasos que se

realizan en un proceso. Esta notacin ha sido especialmente
diseada para 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 diseado para representar grficamente la
secuencia de todas las actividades que ocurren durante un
proceso, basado en la tcnica de diagrama de flujo incluye adems
toda la informacin que se considera necesaria para el anlisis.
BPD es un diagrama diseado para ser usado por los

analistas, quienes disean, controlan y gestionan procesos.
Dentro de un Diagrama de Procesos de Negocio BPD se utiliza un
conjunto de elementos grficos, agrupados en categoras, que
permite el fcil desarrollo de diagramas simples y de fcil
comprensin.
El modelado de proceso es la captura de una secuencia de

actividades de negocio, y de la informacin de soporte. Los
procesos de negocio describen la manera cmo una empresa
alcanza sus objetivos. Es decir ac lo que analizamos y tratamos
Pgina 91 de 154

de graficar son los procesos de negocio. Recuerda que los
procesos de negocio son todas las actividades que realiza una
organizacin y que tienen que ver con la gestin de los datos para
obtener un resultado.
Existen diferentes niveles del proceso de modelado:
Mapas de proceso. Son diagramas de flujo simple de las

actividades.
Descripciones de proceso. Conforman una extensin
del anterior, y manejan informacin adicional pero no
suficiente para definir completamente el funcionamiento
actual.
Modelos de proceso. Son diagramas de flujo extendido con
suficiente informacin 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 condicin o

requisito previo.
Pgina 92 de 154

Un proceso o una aplicacin que da inicio a un proceso
mediante un mensaje.
Representa una fecha o una hora en la cual se iniciar el

proceso o tarea.
Los eventos intermedios forman parte del flujo del proceso en la

secuencia normal del mismo. Pueden o no anteceder a una
actividad o subproceso.
Representa el envo o la recepcin de un mensaje desde

otros procesos.
Representa un mecanismo de retraso dentro del proceso.

Puede estar definido como una fecha o unidad de tiempo.
Permite conectar dos secciones de un proceso para

graficar situaciones repetitivas o para evitar lneas de
secuencia de flujo largas o cruzadas que puedan ser muy
complejas.
Los eventos de fin se representan de la siguiente forma:
Representa un evento de fin que no tiene condicin o

requisito previo.
Representa un evento de fin que termina con un mensaje.
Pgina 93 de 154

Las actividades son la representacin de un trabajo que se realiza
en el sistema analizado. Se representa con un rectngulo
redondeado. Una actividad puede ser atmica o compuesta. Los
tipos de actividades son:
Una tarea es una actividad atmica que est incluida dentro de un

proceso.
Se habla de tarea cuando el trabajo que representa en el proceso

no puede descomponerse en un nivel mayor de detalle.
Un subproceso es un conjunto de actividades incluidas

dentro de un proceso. Puede descomponerse en diferentes
niveles de detalle denominadas tareas. Se representa con un
smbolo de suma en la parte central inferior de la figura. A
continuacin se presentan los tipos de subprocesos:
Una tarea contrada o colapsada muestra una

tarea cuyos subprocesos no pueden ser
visualizados. El signo + indica que la actividad en
un subproceso y que tiene el nivel ms bajo de
detalle.
Pgina 94 de 154

Un proceso expandido muestra los subprocesos, es decir est en el
mismo nivel de detalle del proceso y tiene un evento de inicio y fin
del proceso.
Las compuertas o gateway se representa con un diamante y

representa una divergencia o convergencia de la secuencia de
flujo. Estas siempre determinan bifurcaciones, combinaciones o
fusiones del proceso.
La compuerta exclusiva puede ser de dos tipos

convergente o divergente, la divergente son
decisiones que toma el usuario del sistema para
saber que camino seguir, las convergentes
sincronizan los caminos salientes al cumplir una condicin del
negocio.
La compuerta compleja representa un punto

donde aparecen varios caminos y slo uno de
ellos es vlido.
Pgina 95 de 154

La compuesta paralela indica un punto en el
proceso donde pueden ser llevadas a cabo varias
actividades en paralelo.
Los objetos conectores conectan los objetos de flujo de un

proceso, y definen el orden de ejecucin de las actividades. Los
tipos de conectores son:
Conector de secuencia, muestra el orden de los

eventos, 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 asociacin, permite asociar

diferentes artefactos con objetos de flujo.
Pgina 96 de 154

Los swimlanes o canales son un mecanismo empleado para
organizar actividades en categoras separadas visualmente, con
el fin de ilustrar diferentes capacidades funcionales o
responsabilidades.
Representa a los actores externos o internos con los cuales

interacta un proceso, contiene un conjunto de actividades
asociadas a su rol.
Los artefactos son objetos grficos que proveen informacin

adicional de los elementos dentro de un proceso, sin afectar el
flujo del proceso.
Los grupos se utilizan para agrupar un conjunto

de actividades, la agrupacin se puede realizar
con propsitos de documentacin o de anlisis.
Las anotaciones, son un mecanismo para

entregar informacin adicional.
Pgina 97 de 154

Ac vemos un ejemplo de un proceso de compra y venta de
productos con el posterior despacho de este producto por parte del
vendedor. Fjate que la representacin de los procesos se hace
cada una en su propio canal o swimline para separar las tareas
que estn asociadas a cada uno de los roles en el proceso.
Pgina 98 de 154

Pgina 99 de 154

Diagrama de casos de uso.
El diagrama de casos de uso, es el primer diagrama que
aprenders a crear en profundidad, este diagrama te permitir
analizar los problemas que vayas estudiando de una manera
grfica que es mucho ms cercana a la realidad que conoces. Este
diagrama permite a los analistas tener una visin primitiva
respecto de cmo funciona o debera funcionar el sistema que se
est analizando y ver cmo cada uno de los entes que participan
en el proceso van a interactuar con este sistema.
Recuerda que cuando hablamos de sistema, estamos hablando de

un conjunto de objetos que se interrelacionan con el fin de lograr
un propsito comn, por lo tanto los sistemas que analicemos
pueden ser de cualquier tipo, pero por el perfil de nuestra carrera
tenemos que acercarnos a los sistemas de informacin. Recuerda
que los sistemas de informacin son un conjunto de normas y
procedimiento que definen el cundo, dnde y por qu se realizan
las cosas, un conjunto de personas que realizan las acciones y las
corrigen y un conjunto de hardware y software que permiten
automatizar los procesos que sean montonos o que lleven mucho
tiempo y que generalmente estn asociados a la gestin de los
datos. Por lo tanto siempre recuerda que un sistema de
informacin no es slo software o slo hardware es un todo mucho
ms complejo. Tambin debes tener la seguridad que nunca se
construye el uno sin el otro (o al menos no se recomienda) pues
estn relacionados y el uno sin el otro, provoca que el sistema
quede incompleto.
Pgina 100 de 154

Te preguntars Y cmo hago todo esto?, pues bien, la respuesta
por un lado es simple, pues lo nico que debes hacer es pensar y
por otro compleja dado que hay que pensar y mucho, bsicamente
debes aprender a resolver problemas como si fueras un detective,
es decir, recopilar informacin asociada a los hechos, luego
proponer soluciones, reconstruir procesos o acciones que
ocurrieron y luego establecer la forma de corregir los errores. Para
esto tienes dos aliados que son indispensables, el hardware y el
software.
Como ya sabes que hay que pensar debes hacer que tu cerebro te
obedezca e intente resolver problemas por ti. Para esto lo primero
que debes hacer es recopilar toda la informacin respecto a como
funcionan los sistemas que ests analizando y luego generar un
diagrama que te ayude a ver si lo que pensaste se ajusta o no a la
realidad.
El diagrama de casos de uso cumple esta funcin, ahora dado que

se puede malinterpretar pues es slo una representacin grfica de
la realidad de un proceso, es necesario documentar este diagrama,
para aclarar algunos conceptos que puedan quedar en el aire. Es
importante comprender que este es un proceso iterativo e
incremental que fue pensado para ser de esta forma ,es decir para
que puedas analizar en como solucionar las cosas, debes tener en
cuenta es que no es recomendable trabajar solo pues dos o ms
cerebros piensan ms que uno, adicionalmente si no puedes
verbalizar una idea o explicarla en palabras o texto, significa que
tu cerebro an no lo puede resolver del todo y debes tratar volver
a analizar. Este proceso es muy entretenido pues implica el
investigar y tratar de dar soluciones a problemas cotidianos
Pgina 101 de 154

aplicando tecnologa y todo el conocimiento que vayas adquiriendo
durante tu carrera.
Bsicamente los sistemas de informacin se encargan de realizar

cuatro procesos:
Captura de datos.
Almacenamiento.
Procesamiento.
Entregar de resultados.
Todos los sistemas de informacin realizan bsicamente estos

cuatro procesos desde el procesador de texto hasta los video
juegos pasando por software empresarial y pginas web.
Bsicamente lo que hacemos es dar soluciones basndonos en una
combinacin de hardware, software y mucho anlisis respecto a los
procesos que realiza la organizacin que estamos estudiando para
realizar sus tareas, todo ngulo del almacenamiento,
procesamiento y entrega de resultados del proceso.
A lo mejor te estas haciendo algunas preguntas del tipo Para que

almacenar datos?, Quin define los procesos de la organizacin?,
Es lo mismo un dato que informacin?, El fin del mundo ser el
2012?, Cmo es posible que los vampiros que son seres de la
noche puedan caminar de da en la pelcula Crepsculo?, estas y
otras preguntas las responderemos durante el desarrollo de este y
los siguientes captulos.
La comunicacin que se establece entre las personas siempre es

compleja, una persona que emite una frase o comentario puede
ser mal interpretada por el receptor pues, su interpretacin de lo
que est escuchando depende de muchos factores. Como nuestro
Pgina 102 de 154

objetivo al construir diagramas es poder transformarlos en
software o en una solucin informtica, no nos podemos dar el lujo
de que esto suceda. El diagrama de casos de uso, nos facilita
mucho la tarea de mostrar a la contraparte mediante un dibujo lo
que hemos entendido y de contener errores es fcil de corregir.
Las organizaciones requieren gestionar la informacin de sus

procesos para poder tomar decisiones respecto a como estn
haciendo las cosas para continuar hacindolo bien o para mejorar
lo que estn haciendo mal. Por ejemplo, si fabricamos 3000 litros
de helados en marzo y vendemos pocos litros en invierno lo ms
probable es que el prximo ao ajustemos la cuota de produccin
en funcin de las ventas del ao anterior, para no tener que botar
2999 litros como la temporada anterior. Este tipo de decisiones
estn asociadas a todos los procesos
Componentes del diagrama de

casos de uso.
Para poder realizar de forma correcta un diagrama de casos de
uso, debes saber que este est compuesto por tres elementos: los
actores, los casos de uso y las relaciones. Cada uno de estos
elementos permite que tengas una visin de los componentes de
un sistema (personas, reglas y procedimientos) y cmo estos se
relacionan.
Recuerda que un diagrama de casos de uso se circunscribe a un

momento en el tiempo, es decir que lo que nos muestra es la
relacin entre los procesos y las personas en un momento
especfico o como se suele decir, en un escenario particular.
Pgina 103 de 154

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

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

como cuando ramos pequeos y an no aprendamos a dibujar.
Pgina 105 de 154

Fjate que el actor posee un nombre que define su rol, es decir el
papel que le corresponde realizar en ese escenario especfico, este
rol del usuario esta definido por el escenario, as en un sistema
llamado casa, probablemente desempees alguno de los
siguientes roles: hermano(a), pololo(a), hijo(a), esposo(a), papa
o mam, etc., fjate que es posible que t cumplas ms de un rol,
por ejemplo, hermana, polola, mam dentro del mismo sistema,
pero las acciones que realizas y como las realizas son distintas en
funcin del rol que te toca representar en ese escenario en
particular. Por ejemplo supongamos que sabes cocinar y al mismo
tiempo eres hijo de tus padres, cuando ests en la cocina,
estableces un rol de usuario de la cocina, cocinero y por lo tanto
vas a interactuar como usuario cocinero con el sistema cocina, el
cual se encuentra dentro del sistema casa, cuando ya serviste la
comida, entonces interactas con tus padres de forma distinta,
pues tu rol de cocinero cambi por el rol de hijo.
Casos de uso.
Un caso de uso se define como una funcin que tiene o debe tener
el sistema y que es utilizada por un usuario. De esta forma los
casos de uso se transforman en las acciones que debe
implementar el sistema, recuerda que en el anlisis de casos de
uso, la vista desde la cual analizamos el problema es como
usuarios del sistema que deben cumplir una serie de tareas que
van asociadas a nuestro rol en un escenario especfico. De esta
forma si analizamos las tareas que debe realizar un vendedor para
poder vender algn artculo en una multitienda (fjate que el
problema se circunscribe a ese escenario en particular), este debe
poder consultar por los precios de los productos, vender uno o ms
Pgina 106 de 154

productos a un cliente, consultar el total de la venta, imprimir el
comprobante de la venta, recibir el pago, y dar vuelto si
corresponde, recuerda que este es una aproximacin inicial al
problema por lo que las etapas pueden cambiar, as que si
descubres ms, sintete libre de agregarlas . Una vez que
determines las tareas que debe hacer el actor, estas deben ser
analizadas pues a veces este anlisis inicial puede llevar a una
confusin.
Realicemos el siguiente anlisis, supongamos que tenemos la

siguiente definicin de procesos:
Necesitamos representar un sistema que permita a los mdicos de

una clnica dental, definir sus horarios de atencin y a los clientes
de la clnica el registrarse y el solicitar hora a travs de una pgina
web
Pese a que esta es una definicin de procesos extremadamente

simple, ya podemos definir algunas caractersticas iniciales para el
modelo y basndonos en estas caractersticas iniciales podemos
con posterioridad hacernos algunas preguntas respecto a como
funcionan las cosas y tendremos la posibilidad de mejorar el
modelo.
Lo primero es definir a los actores (personas o sistemas u

organizaciones) que participan del proceso. De esta forma
identificamos al menos dos, mdico y paciente.
Pgina 107 de 154

Una vez que identificamos a los actores, lo que debemos hacer es
definir los casos de uso, es decir a las acciones que estos actores
van a realizar para lograr el objetivo propuesto.
Para el ejemplo anterior vemos que podemos detectar ciertas

acciones o comportamientos que debe realizar cada uno de los
actores como usuarios del sistema, as podemos dividir las
acciones que realiza cada uno de la siguiente forma:
Mdico: Define su horario de atencin
Usuario: Registrarse, solicitar hora.
Si te fijas la definicin de los casos de uso define el qu, pero no el

cmo, pues an no interesa, recuerda que estamos primero
definiendo qu es lo que hay que hacer, concntrate en este
punto, pues si bien la tecnologa es importante antes de identificar
y solucionar el problema, hay que saber qu es lo que necesitamos
Pgina 108 de 154

que el sistema haga. Un punto importantsimo que debes analizar
son los datos que necesita el proceso para poder realizarse
completamente o de otra forma tratar de definir los datos que la
organizacin necesita registrar como parte del proceso para la
toma de decisiones, por lo tanto el diagrama final quedara de la
siguiente forma:
Pgina 109 de 154

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

uso, asociacin de comunicacin, extensin, inclusin y
generalizacin.
La relacin de asociacin de comunicacin se establece entre el

actor y el caso de uso y nos permite definir en el contexto del
diagrama que el actor est utilizando que el caso de uso. Recuerda
que cada uno de los actores que aparezca en el diagrama debe
estar relacionado al menos con un caso de uso, pues la relacin
entre el actor y el caso de uso nos indica qu funcionalidad del
sistema ser utilizada por cada uno de los actores que estn
representados en ese escenario particular.
En la relacin de inclusin, la que graficamos con una lnea

segmentada que une dos casos de uso ms una flecha que indica
la direccin de la relacin, estamos representando dos casos de
uso que son complementarios. En la relacin de inclusin, un caso
de uso necesita de otro caso de uso para poder realizar una
operacin en particular. Recuerda que en la inclusin el resultado
del caso de uso incluido afecta el caso de uso que incluye por lo
tanto estn ntimamente relacionados los resultados de ambos.
Este tipo de relaciones se grafica utilizando la palabra
<<include>> sobre la lnea que muestra la relacin.
Pgina 110 de 154

En la imagen anterior fjate que el caso de uso denominado login,
incluye su funcionalidad al caso de uso buscar usuario, que
tambin es utilizado por el caso de uso registro para evitar que el
usuario se registre dos veces. En este ejemplo ambos casos de uso
incluyen su funcionalidad, y as la ejecucin o no del caso de uso
se relaciona con el resultado obtenido por el caso de uso incluido,
es decir, el caso de uso login y el caso de uso registro no
estn completos sin la utilizacin de buscar usuario, pues de este
segundo caso de uso depende el resultado del primero.
Cuando se trata de relaciones de extensin las cuales se grafican

con la palabra <<extend>>, tambin se puede analizar la relacin
como si los dos casos de uso fueran slo uno. Pero una de las
diferencias bsicas es que hay situaciones en que el caso de uso
de extensin no es indispensable que ocurra, y cuando lo hace
ofrece un valor extra el cual extiende al objetivo original del caso
de uso base, mientras que en el <<include>> es necesario que
ocurra el caso incluido slo para satisfacer el objetivo del caso de
uso base.
Un ejemplo de lo anterior lo podemos analizar en el siguiente

ejemplo:
Pgina 111 de 154

En el ejemplo anterior el caso de uso servir caf extiende hacia el
caso de uso agregar azcar, fjate que para servir caf no es
siempre necesario el agregar azcar, pero cuando se hace, le
agrega un valor al caso de uso anterior, sin que exista la
dependencia del uno con el otro.
Otro tipo de relacin que se establece en los casos de uso es la

relacin de generalizacin, la cual se dibuja en el diagrama
mediante una flecha con sentido, la punta de flecha a diferencia de
los otros tipos de relacin a parte se rellena. La generalizacin est
asociada al concepto de especializacin, en esta situacin un caso
de uso puede dar origen a una forma especializada de realizar una
accin para muestra un ejemplo:
En el diagrama anterior el proceso de pago en el sistema se puede

realizar de dos formas, con la tarjeta de la multitienda o en
efectivo. Si te fijas cada uno de estos procesos en s es un pago,
Pgina 112 de 154

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

que participan los actores.
Uno de los puntos principales para poder realizar un buen anlisis
de la situacin actual, es poder determinar el contexto en el cual
participan los actores. Es importante recalcar que muchas veces el
contexto del problema es importante para determinar las acciones
que se deben considerar a implementar como casos de uso. Para
muestra el siguiente ejemplo:
Un taller mecnico recibe vehculos para ser reparados, los

clientes que desean atender su vehculo, primero deben registrar
sus datos y los del vehculo, adicionalmente se registra el motivo
de la visita en el taller y se procede a la evaluacin preliminar del
vehculo. Junto con esto se hace una cotizacin basndose en la
deteccin de los problemas que presenta el vehculo. Una vez se
recibe esa cotizacin y el cliente da la autorizacin para ejecutar el
trabajo, este es asignado a uno o ms tcnicos mecnicos los
cuales proceden a la ejecucin del trabajo que est asociado a su
especialidad (falla mecnica del motor, amortiguacin, sistema
elctrico, mantencin peridica, etc.). El proceso se lleva cabo por
cada uno de los tcnicos y es revisado por un jefe de taller el cual
fiscaliza la correcta ejecucin del trabajo. Una vez que el trabajo
completo es realizado, el vehculo es entregado al cliente..
Pgina 113 de 154

Identificacin de los roles.
El proceso de identificacin de los actores, pasa por determinar,
personas o sistemas que entreguen informacin al sistema o
reciban informacin de este (entes pasivos), ahora tanto el envo
como la recepcin de la informacin est asociada al contexto del
problema. Si te fijas en el enunciado del ejercicio anterior, nuestro
contexto se remite a la recepcin del vehculo, el diagnstico del
problema, la asignacin de tareas, el proceso de verificacin de la
ejecucin de las tareas y la devolucin del vehculo reparado,
jams se consider el cobro a los clientes ni el pago a los
proveedores de insumos, ni el pago a los trabajadores, pues
nuestro contexto es slo el de la definicin de procesos. Es posible
que un anlisis posterior nos pudiera mostrar que existe relacin
con otras reas pero siempre es necesario determinar las fronteras
del sistema para realizar un anlisis acotado.
Una vez que hayamos determinado el contexto del problema, es

necesario determinar a los actores que pueden ser personas,
entidades u otros sistemas que envan o reciben informacin desde
y hacia el sistema. Recuerda que cuando hablamos de un sistema
en el anlisis de casos de uso, estamos hablando de un conjunto
de procesos que nos permiten lograr un resultado, en el caso
anterior, reparar nuestro auto.
Si analizamos la definicin de procesos del ejemplo podemos

detectar algunos actores iniciales:
Cliente: quien lleva el auto.
Recepcionista: quien recibe y anota los datos del vehculo y el

cliente.
Pgina 114 de 154

Tcnico mecnico: quien recibe la informacin de las tareas que
debe realizar asociadas a un vehculo.
Jefe de taller: Es el que revisa que el trabajo se haya realizado de

forma correcta.
Fjate que podemos hacer un anlisis un poco ms avanzado del

proceso y podramos pensar en lo siguiente Qu pasa si el
recepcionista, el tcnico y el jefe del taller son la misma persona?,
la mejor respuesta a esto es que lo que estamos analizando son
los roles que cumplen las personas al enfrentarse al uso del
sistema, por lo tanto independiente de que sean 1 o 100 personas
que estn interactuando con el sistema, lo que nos interesa es
encontrar los roles que ellos estn ejerciendo.
De esta forma podemos definir que cada uno de los roles tiene
asociada una serie de tareas que debe realizar para poder aportar
su parte en el proceso. Por ejemplo el tcnico mecnico le podran
eventualmente corresponder realizar ms tareas que las definidas
(recibe las tareas realizadas). Utilizando esta misma lnea de
pensamiento, podemos identificar que existen varios actores
asociados a un rol en particular, en este caso por ejemplo pueden
existir varios clientes y varios mecnicos, adems si te fijas el
cliente puede no slo traer el vehculo, sino que adems en otro
contexto debe pagar por el servicio.
Definicin de los actores.

Una vez que defines los roles en la organizacin o en el sistema
que estas analizando, es necesario que definamos los actores
asociados a los roles que has encontrado, para esta identificacin,
debes poner especial atencin en que pueden existir varios actores
Pgina 115 de 154

que estn asociados a un mismo rol, por ejemplo en el anlisis de
nuestro caso, podramos encontrar a varios mecnicos, pero slo
registramos uno. Ahora esto nos podra llevar a pensar que existen
tanto usuarios como roles, pero no es as, pues es posible que un
mismo actor pueda cumplir varios roles en funcin de su contexto.
Esto puede parecer un poco complejo, pero no lo es, piensa que un
rol est asociado a una tarea, mientas que un actor puede cumplir
varios de estos roles en diferentes contextos, es decir que un
mecnico puede realizar ms tareas que las detectadas en otro
contexto. Ahora recuerda que si identificas a varios actores
(alumnos de un curso, pasajeros de un bus, jugadores de un
equipo), estos se consideran como uno solo, pues el rol que estn
cumpliendo es el mismo para todos.
Definicin de los casos de uso.

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

Definicin de los casos de uso.
Existen distintas formas para poder detectar los casos de uso para
un sistema que estemos analizando, algunas de esas formas
pueden ser una lluvia de ideas en la cual los participantes aporten
ideas respecto a los casos de uso que cada uno identifica por
separado al hacer el anlisis de la descripcin de los procesos. Otra
forma de realizar este anlisis es utilizando a los actores que ya se
han definido, analizando a cada uno de ellos podemos determinar
los procesos en cuales ellos participan o inician. Adicionalmente
Pgina 117 de 154

nos podemos hacer una serie de preguntas relativas al sistema que
estamos analizando.
Cules son las tareas que debe realizar un actor?
Qu informacin crea, guarda, modifica, destruye o lee el actor?
Debe el actor notificar al sistema los cambios externos?
Debe el sistema informar al actor de los cambios internos?
Respondiendo las preguntas anteriores y realizando una

combinacin de los procesos descritos, ya que no hay ninguno
mejor que el otro, podemos identificar sin mayor problema a los
casos de uso del sistema.
Pgina 118 de 154

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

Extensin.
En la relacin de extensin el caso de uso extendido, completa su
accin con el caso de uso extendido, es decir, el caso de uso
extendido, aumenta su funcionalidad con el caso de uso extendido,
pero el caso de uso extendido no es necesario siempre.
Pgina 120 de 154

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

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

cliente y se podr trabajar con ellos en la definicin correcta de los
procesos ac descritos.
Existen muchos formatos para realizar la documentacin de los

casos de uso, vamos a usar un formato bsico pero completo para
poder establecer de la mejor forma la descripcin de los casos de
uso.
Nuestro documento constar de las siguientes partes:
Definicin del caso de uso.

En esta parte se define el nombre del caso de uso, su identificador
y se da un breve descripcin del caso de uso, fundamentalmente la
descripcin est orientada a definir el proceso general que se est
describiendo.
Flujo Normal.
La seccin del flujo normal pretende que definamos el flujo normal
de actividades que se pueden identificar en un caso de uso, este es
el camino feliz es decir el proceso en su estado ideal en donde
nada falla y todo est como queremos.
Adicionalmente al flujo normal se suele definir una serie de

caminos alternos que nos permitan saber cmo se comporta el
sistema que estamos analizando cuando el proceso no llega a buen
puerto. La realizacin de este tipo de anlisis es muy importante
pues muchas veces el flujo alterno puede definir una regla
importante respecto al flujo del proceso.
Pgina 122 de 154

Pre-condiciones.
Las precondiciones permiten formalizar todas aquellas condiciones
de deben considerarse como requisitos para la ejecucin de
nuestro caso de uso
Post-condiciones.
Las post-condiciones con estados finales con los cuales termina el
caso de uso y que son obligatorios. Esto significa que el caso de
uso debe terminar su proceso con alguna de las condiciones
definidas en esta seccin.
Para clarificar el concepto, fjate en la definicin del caso de uso

que esta hecha en el siguiente texto:
Nombre del caso de uso: Registro de usuario
Actores: Usuario/Administrador
Objetivos: Registrar al usuario/administrador en el sistema
Pre-condiciones:
1. El usuario no debe estar registrado con anterioridad.
Flujo Normal:
1. El usuario solicita el registro.

2. El usuario llena el formulario de registro.
3. El sistema valida que los datos estn completos y que la informacin
sea del tipo correcto.
4. El sistema chequea que el usuario no se encuentre registrado con
anterioridad.
5. El sistema almacena los datos del usuario, asignndole los permisos
necesarios.
Pgina 123 de 154

6. El sistema muestra un mensaje de exito en el proceso de registro.
Post-condiciones:
1. El usuario es registrado en el sistema y se le enva un correo el cual

contiene un hipervnculo que debe ser seguido para validar el registro.
Excepciones:
1. El usuario cancela el registro

2. El usuario no llena todos los datos.
3. El usuario ingresa datos que no corresponde.
4. El usuario intenta registrarse, pero sus datos ya existen en el
sistema.
Pgina 124 de 154

Pgina 125 de 154

Diagrama esttico de clases.
Introduccin al diagrama esttico

de clases.
Como se vio en los captulos anteriores, el mundo de los
diagramas UML es bastante extenso y cada diagrama tiene un
propsito especfico y entre ellos muchas veces se complementan
para entregar informacin ms especfica respecto a un proceso en
particular, o la forma en que se deben realizar las cosas.
Uno de los diagramas que nos va a permitir mostrar la forma en

que los diferentes componentes del software interactan entre si,
es el diagrama esttico de clases.
Piensa en lo siguiente, la mayora de las cosas que conocemos

estn formadas por varias partes las cuales se complementan para
realizar una tarea especfica, la cual no podra ser realizada por
ninguna de las partes por separado.
Por ejemplo cuando quieres prender tu televisor y te encuentras a

una distancia apreciable, vas a tener la tendencia natural a utilizar
el control remoto, si te fijas, para lograr prender el televisor, t
como objeto, ests interactuando con el control remoto (otro
objeto) el cual enva una seal al televisor (otro objeto) y
finalmente el televisor se enciende.
Pgina 126 de 154

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

mostrar la forma en que los objetos se comunican y relacionan.
Utilidad del diagrama esttico de

clases.
El diagrama esttico de clases como lo vimos, permite obtener
informacin referente a 2 vistas en particular. La primera dice
relacin con la forma en que los objetos se componen, es decir sus
caractersticas y la forma en que se comportan, y la segunda es
analizar la forma en que las clases se relacionan.
El diagrama permite tener una vista esttica del problema el cual

no va a cambiar con el tiempo. Este diagrama adicionalmente nos
va a permitir avanzar en una concepcin ms acabada de cmo
todos los procesos que determinamos en el diagrama de casos de
uso se van a convertir en una aplicacin de software o en un
proyecto de algn otro tipo (recuerda que una de las ventajas de
UML es que no slo sirve para disear software). Cabe sealar que
el diagrama esttico de clases no hace slo referencia a como las
distintas partes del software interactan sino que tambin puede
incluir hardware, y todos los otros componentes que forman un
proyecto informtico.
Pgina 127 de 154

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

clases.
Para comprender cmo podemos construir un diagrama esttico de
clases primero vamos a conocer los distintos componentes de este
diagrama y que representan, adems de cmo se relacionan unos
con otros y los diferentes significados que estos van a tomar en
funcin de como se relacionen.
Lo primero que debes entender es que existe una diferencia entre

la clase y el objeto, aunque muchas veces tendemos a confundirlos
producto de malos entendidos.
La clase es la muy parecido al plano de construccin de un edificio

o al diseo que hace un ingeniero en electrnica de un circuito
impreso, es decir ac se define la forma en que se van a construir
los objetos. Por lo tanto podemos decir que un objeto es la
construccin fsica basndonos en las especificaciones de una
clase. A continuacin se define formalmente el concepto de clases
y objetos.
Pgina 128 de 154

descripcin generalizada (por ejemplo, una plantilla, un patrn o
un prototipo) que describe una coleccin de objetos similares7
descriptor de un conjunto de objetos que comparten los mismos

atributos, operaciones, mtodos, relaciones y comportamiento8
Si te fijas en las definiciones anteriores, stas siempre hacen

referencia a un descriptor o plantilla o prototipo, es decir en una
clase es necesario hacer la definicin de las caractersticas y las
acciones que realizarn los objetos. Para lograr este cometido
primero debes tener en claro el modelo que quieres representar.
Recuerda que una de las partes ms complejas del desarrollo de
proyectos de tecnologas de informacin es tratar de definir de
forma correcta los requerimientos que tenga la contraparte.
Recuerda el ejemplo del bunker para el apocalipsis zombi. Si bien
un bunker para un apocalipsis nuclear te podra servir, el bunker
para el apocalipsis zombi tiene otras caractersticas que son
necesarias, por ejemplo muchas motosierras, y por lo tanto
suficiente combustible, y un sin nmero de armas corto punzantes
(machetes, espadas, katanas, etc.) que sern de mucha utilidad
cuando salgas a explorar los alrededores.
Una vez que tengas muy claro las necesidades de la contraparte

puedes comenzar a pensar en la funcionalidad que debe tener el
sistema y como cada una de estas funciones est pensada para un
tipo de usuario. Por ejemplo el sistema de transporte pblico tiene
funciones pensadas para diferentes usuarios (pasajeros, pasajeros
con capacidades de desplazamiento limitadas y choferes). Cada
7
Ingeniera del Software: Un enfoque prctico, Roger S. Pressman, McGraw-Hill/Interamericana de Espaa, S.A.U. 2002,
ISBN 84-481-3214-9
8
El Lenguaje Unificado de Modelado. Manual de Referencia, Pearson Educacin, S.A. 2000, ISBN 84-7829-037-0
Pgina 129 de 154

uno de ellos utiliza funcionalidades distintas del sistema, por
ejemplo slo el chofer puede manejar. Cuando logras definir las
funciones y quien las utiliza en el sistema, entonces puedes
construir un diagrama de casos de uso (visto en el captulo
anterior). y que paso con las clases? Cuando logras establecer el
comportamiento del sistema y los usuarios que interactan con el
sistema analizado, entonces ests en condiciones de pasar a la
siguiente etapa del proceso de anlisis, que corresponde a tratar
de hacer una agrupacin de funcionalidades que implementa el
sistema y agrupar estas funciones, si bien esto suena complejo, no
te preocupes esto lo has hecho de forma natural durante toda tu
vida, la diferencia es que no te habas dado cuenta. Para muestra
un ejemplo.
Supongamos que te encuentras leyendo este manual en la sala de

clases, si te fijas, la sala esta llena de objetos que interactan
entre si y que en conjunto logran un objetivo, que en este caso es
el traspaso de conocimiento desde el docente al alumno. Ahora
debes tener en cuenta que los objetos que viven en esta sala de
clases, lo hacen con un propsito, este propsito est asociado a
su entorno, es decir, las actividades que realiza el alumno en la
sala de clases son diferentes a las acciones que realiza la misma
persona cuando va a comprar al supermercado, aunque se trate de
la misma persona.
Lo anterior nos demuestra que existe un mbito para los objetos

en el cual el objeto se comporta de una forma especfica y posee
ciertas caractersticas que estn asociadas a los procesos que este
realiza. Por ejemplo, para estudiar, el alumno necesita materia que
le entrega el profesor, adicionalmente el profesor califica el
Pgina 130 de 154

desempeo del alumno con una nota, si te fijas en el ejemplo
anterior, cada uno de los objetos realiza un proceso y ese proceso
lo realiza con un conjunto de datos que les es propio o que algn
otro objeto les entrega. Este proceso de abstraccin mental en el
anlisis de los procesos que se ve tan complejo en realidad t lo
llevas haciendo desde pequeo seguramente sin darte cuenta.
Volvamos ahora hacia las clases y su representacin en el modelo.

Como vimos anteriormente, en el mundo real los objetos
interactan entre s y poseen datos que les permiten realizar sus
procesos, esos datos a su vez definen el comportamiento posible
de los objetos. Volvamos a ver un ejemplo, si tuviramos que
definir un lpiz en orientacin a objetos, tendramos que definir
sus caractersticas o atributos y su funcionalidad.
Definicin del lpiz
En los objetos la funcin y las caractersticas siempre estn unidos

y nunca se separan, de esta forma, la funcin afecta a la
caracterstica y viceversa, por ejemplo cuando el lpiz raya, esta
accin hace que la cantidad de tinta disminuya, cuando la cantidad
de tinta llega a 0, Puede seguir rayando el lpiz? . Si analizas los
comportamientos de muchos objetos que te rodean te dars
cuenta de que esta unin entre las caractersticas y la funcin
Pgina 131 de 154

siempre se encuentra y es fcil de descubrir, por ejemplo, si
enciendo la ampolleta con el interruptor, que otra cosa puede
hacer el interruptor? , Puede volver a encender la luz?, o
primero debe apagarla?. Fjate que al encender o apagar la
ampolleta, estas cambiando el estado de la ampolleta (una
caracterstica que posee) y al apagarla, esto tambin ocurre, pero
al estar encendida, esta slo se puede apagar, te das cuenta de la
relacin?, si an no queda claro, ac va otro ejemplo.
Supongamos que puedes viajar al pasado y logras traer de vuelta

a un tiranosaurio rex como mascota, si te fijas bien en su
comportamiento, te dars cuenta de que tu nueva mascota, entre
todas las cosas que hace, come bastante y adems camina y ruge,
fjate adems que para cada una de esas acciones que realiza, la
nueva mascota utiliza energa, slo puede realizar las acciones
antes descrita si la cantidad de energa es mayor a 0. Ahora bien
cada vez que realiza una accin, la cantidad de energa se
disminuye una cierta cantidad de unidades, pero cuando come, la
cantidad de energa acumulada aumenta. Con esto vemos que los
atributos o caractersticas de una clase se ven modificados por las
acciones o mtodos, de la misma forma, si el dinosaurio mascota
no se alimenta, su cantidad de energa ser 0 y por lo tanto no
podr realizar ninguna de las acciones antes descritas.
Muy bien, ahora te debes estar preguntando Y que paso con los
grficos del diagrama?, ahora vamos a eso, en UML, la
representacin de las clases, sus atributos y sus mtodos se
realiza mediante una representacin grfica que muestra un
rectngulo dividido en 3 partes, la superior contiene el nombre de
Pgina 132 de 154

la clase, la parte central la definicin de los atributos de las clases
y la parte inferior los mtodos o comportamiento de la clase. Para
muestra un ejemplo:
Fjate que cada una de las secciones posee ciertas caractersticas

con respecto a la forma en que stas se definen.
Nombre de la clase: Esta se debe escribir centrada en la pgina y

con formato de texto ennegrecido, adicionalmente existe una
nomenclatura para la escritura de los nombres que si bien no es
estndar es la que se recomienda. Consiste en escribir el nombre
con un formato conocido como PascalCasing, este formato nos
solicita que escribamos el nombre con la primera letra en
maysculas y el resto en minsculas, por ejemplo Alumno, ahora
si el nombre es un nombre compuesto, sugiere que las primeras
letras de cada una de las palabras tengan este formato, por
ejemplo MascotaSaurio.
Atributos: Los atributos se definen dentro de la clase utilizando un

formato llamado camelCasing, este formato define que la primera
Pgina 133 de 154

letra se escriba en minsculas al igual que todas las otras, a
menos que tengas que crear un atributo compuesto que en este
caso solicita que la primera palabra la escribas en minsculas pero
la primera letra de la segunda palabra la escribas con maysculas,
esta misma lgica se da si tienes ms de dos palabras, por
ejemplo edad, fechaNacimiento, tamaoPueraTrasera.
Adems cada atributo debe definir su tipo, en UML existen algunos

tipos de datos primitivos por ejemplo Integer, String, Boolean, etc,
pero tambin se pueden agregar otros tipos que permitan
aumentar la capacidad de tu modelo, esto se hace en funcin
generalmente del lenguaje de programacin con el que se vaya a
generar el software al final.
Otra cosa que debes tener presente es que los atributos y los
mtodos poseen niveles de visibilidad que determinan si un
atributo o mtodo es visible desde fuera de la clase, esto es lo que
se denomina como la interfaz de una clase, es decir el conjunto de
atributos y de mtodos con los cuales el objeto se comunica con su
ambiente, el siguiente ejemplo lo puede clarificar.
Lo ms probable es que alguna vez hayas utilizado un reproductor

de DVD, el uso general indica que el reproductor se enciende, se
abre la bandeja, se pone el DVD en el interior y si todo esta
correctamente conectado, se comenzar a reproducir el contenido
del DVD. Ahora fjate que t interactuaste con el reproductor de
varias formas, pero algunas otras quedaron ocultas, t encendiste
el lser del DVD, realizaste la demultiplexin de la seal ptica
para ser transformada en audio y video?, lo ms probable es que
no, t slo interactuaste con los botones del equipo y con el disco
en cuestin, pero el resto del proceso se realiz sin tu
Pgina 134 de 154

intervencin. En este caso la interfaz del DVD es el conjunto de
botones con los cuales t puedes hacer que este funcione. Todos
los objetos con los cuales interactuamos presentan una interfaz y
poseen un conjunto de mtodos y propiedades con las que no
podemos interactuar pues estn ocultas para nosotros. Esta
caracterstica de ocultar comportamiento y acceso a las
propiedades de una clase se realiza por un tema de seguridad,
pues te imaginas cuantos ojos quemados existiran si te
permitieran manipular el lser o encender la chispa para prender
un motor,
De esta forma el atributo se define con el siguiente formato:
Nombre_atributo: tipo_dato=valor_inicial
Si te acuerdas del tema de la visibilidad, los atributos de las clases

se clasifican en privados (-) o pblicos (+), para entender de que
se trata esto, piensa en lo siguiente, cuando enciendes el DVD, la
velocidad del motor que mueve el DVD es imposible que la
podamos acelerar o disminuir desde afuera, en este caso la
velocidad del motor es una atributo privado para la clase es decir
slo se puede modificar desde dentro de la propia clase y se le
anota un signo - delante. Sin embargo, cuando por ejemplo
apagamos el interruptor de la ampolleta, la estamos apagando y
por lo tanto estamos modificando desde afuera una caracterstica
de esta clase, en este caso la propiedad se define como pblica y
se le anota un signo + delante del atributo.
De esta forma los atributos de la clase se anotan de la siguiente

forma:
-energiaZombi: Integer=100;
Pgina 135 de 154

-escudoProtector: Integer=20;
Los mtodos de la clase tambin tienen una nomenclatura

especfica, en este caso los mtodos se anotan de la siguiente
forma:
NombreMetodo(atributo:tipoDato)
En este caso tambin debemos explicar algunas cosas respecto al

formato, el nombre del mtodo representa el nombre del
comportamiento de la clase, este nombre debe ser significativo o
sea que te permita saber fcilmente que es lo que el mtodo hace,
slo con leer su nombre, por ejemplo, que es ms fcil de
determinar, el comportamiento de un mtodo que se llama
liquidarZombi(), o un mtodo llamado x25rst45(), si te fijas, el
primer mtodo se explica por si slo, mientras que el segundo no.
Adicionalmente al nombre si te fijas entre parntesis aparecen

variables, es decir valores que se identifican con un nombre y que
son de un tipo de dato especfico, estas variables el mtodo las
ocupa para poder tener informacin adicional que es parte del
mensaje que el objeto recibe para poder ejecutar el mtodo. Los
objetos no hacen nada a menos que otro objeto se los pida, por
ejemplo el control remoto no enciende el televisor a menos que
nosotros se lo solicitemos, o por ejemplo el vehculo no se mueve
a menos que nosotros presionemos el pedal del acelerador, en este
caso la cantidad de presin que apliquemos al pedal ser la
velocidad de salida del automvil, si te fijas en este caso lo
podemos representar de la siguiente forma:
+acelerar(fuerza:Integer)
Pgina 136 de 154

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

Relacin entre las clases y las
tablas de un modelo entidad
relacin.
Como podemos observar, al crear y definir las clases, estas se
pueden analizar como un conjunto de datos sobre los cuales se
aplican un conjunto de mtodos.
Este anlisis de los procesos agrupando primero los datos, se

parece mucho al anlisis que se realiza en la disciplina de base de
datos para crear las entidades de datos que nos van a permitir
agrupar los datos en registros que a su vez construyen lo que se
conoce como bases de datos.
Las bases de datos no son ms que un conjunto de datos

agrupados alrededor de un concepto, o una idea (igual que las
clases). Si bien las estructuras se parecen, estas no son iguales y a
veces esto lleva a los programadores a cometer algunos errores.
Por ejemplo, si te enfrentas a un problema que implique el

modelar el comportamiento de un alumno en un sistema de
matrcula, entonces, el modelo de la clase se podra graficar de la
siguiente forma:
Pgina 138 de 154

Ahora fjate en el modelo de la entidad que se puede crear para la
misma estructura.
Si te fijas, los dos elementos se parecen mucho en su definicin, la

diferencia est en que la clase posee los mtodos de la clase y
adicionalmente, la forma en que se relacionan los elementos son
distintos.
Componentes del diagrama esttico

de clases.
Ahora lo que vamos a hacer es realizar un diagrama completo de
clases, para esto vamos a analizar un problema muy simple, y lo
vamos a comenzar a desmenuzar en cada una de sus parte de
forma tal que el modelo se vaya construyendo de a poco.
La liga de futbol de tu pas necesita establecer el modelo de clases

para poder crear un software estadstico para llevar el control de
los partidos que se estn por comenzar a jugar en la liga, adems
necesita conocer los goles marcados, el goleador por equipo y cada
uno de los registros asociados a un partido de ftbol.
Debes tener presente que el proceso de anlisis orientado a

objetos es un proceso iterativo incremental, es decir que debes
darle varias vueltas al asunto antes de que quede 100 por ciento
correcto, lo que no quiere decir que vayas a estar iterando
Pgina 139 de 154

eternamente, la experiencia ya te dir cundo es suficiente la
iteracin del proceso. Lo primero es tratar de definir las clases
propuestas, que aparezcan en el modelo, para esto leemos la
definicin del problema o la definicin de requerimientos y
comenzamos a analizar el texto, descubriendo con esto todos los
sustantivos que aparezcan en el problema, de esta forma hacemos
un listado preliminar:
Liga.
Partidos.
Goles.
Equipo.
Ahora si te fijas bien en el listado anterior todas las clases

propuestas intervienen en el proceso que queremos modelar, si
apareciera alguna que no intervenga, entonces hay que analizar si
se justifica el que la incluyamos en el listado.
Analizando el listado vemos que podra ser posible el incluir a los

jugadores pues ellos componen los equipos y hacen los goles, por
lo tanto su inclusin en el modelo podra ser bastante necesaria.
Ahora una vez que tenemos el listado de clases candidatas debes

intentar el analizar el problema y tratar de definir qu
comportamiento van a realizar cada una de las clases que has
definido para el problema, de esta forma, podemos definir la clase
inicial para el jugador de la siguiente manera:
Pgina 140 de 154

En el diagrama anterior podemos establecer una relacin entre los
mtodos de la clase y los atributos de la misma, as por ejemplo
existe un mtodo que se llama marcarGol(), este mtodo de forma
interna lo que hace es que modifica la cantidad de goles que ha
marcado el jugador y adicionalmente disminuye la cantidad de
energa que este posee. Si durante el anlisis te das cuenta que
hay un atributo que no es ocupado o algn mtodo que nunca es
utilizado, entonces es el momento de modificarlo, pues esto
despus al ser transformado en cdigo, ser trabajo extra que
tendr que hacer el programador. Como este es un proceso
iterativo e incremental, podremos agregar o quitar tantos mtodos
o atributos que consideremos que no estn correctamente
asignados. Recuerda eso s que la decisin de agregar o quitar
elementos desde el modelo no es antojadizo, es parte del proceso
de anlisis que nos lleva a dejar slo aquellos procesos que nos
son tiles para solucionar el problema, por ejemplo si analizamos a
nuestro jugador nos damos cuenta de que tambin come, y corre y
salta y realiza un montn de acciones, pero estas acciones no son
relevantes para el proceso que estamos estudiando, este proceso
de ignorancia selectiva se conoce como abstraccin y es uno de los
procesos ms importantes del diseo de clases. Este proceso de
Pgina 141 de 154

abstraccin permite que te concentres en lo realmente importante
para solucionar el problema y dejas de lado lo que no te interese.
Una vez que logres determinar la estructura aproximada de las

clases, debes documentar el comportamiento de cada una de ellas,
y agregar documentacin para los atributos que esta posee, para
muestra la siguiente clase documentada.
Nombre de la clase: Jugador
cantidadGoles: atributo que almacena la cantidad de goles

anotados por el jugador.
energia: atributo que almacena la cantidad de energa del jugador.
nroEspalda: atributo que representa el nmero de la camiseta que

viste el jugador.
nombre: atributo que representa el nombre del jugador

Pgina 142 de 154

pases: atributo que permite registrar los pases que ha realizado el
jugador.
quites: atributo que permite registrar las pelotas que ha quitado el

jugador.
marcarGol: comportamiento que permite registrar cada uno de los

goles marcados por el jugador. Cuando se ejecuta suma una
unidad a atributo cantidadGoles
darPase: comportamiento que se encarga de registrar los pases

que ha hecho el jugador y que se han efectuado de forma correcta.
Cuando se ejecuta incrementa en una unidad el atributo pases.
quitarPelota: comportamiento que se encarga de registrar los

quites de baln que ha efectuado el jugador. Cuando se ejecuta se
aumenta en una unidad el atributo quites.
Pgina 143 de 154

Relaciones entre las clases.
En el mundo real, las clases no funcionan solas, sino que
establecen relaciones entre ellas, estas relaciones, permiten definir
la forma en que las clases interactan en el mundo real cuando se
transformen en objetos. Recuerda que cuando construimos clases,
estas clases se transformarn en objetos cuando se estn
ejecutando como un software en el computador. Para clarificar
piensa en lo siguiente, t estas definiendo las clases y las estas
documentando de forma tal de poder definir el comportamiento de
las clases y sus caractersticas. Por otro lado un programador va a
tomar esta definicin y la documentacin que t desarrolles y va a
construir un software donde estas clases se transformaran en
archivos de cdigo. El compilador del lenguaje de programacin va
a tomar estos archivos y los va a compilar y a ejecutar, eso
significa que el cdigo fuente cuando se ejecute se va a guardar en
la memoria RAM del computador y cada uno de los objetos que all
se creen, van a ser una instancia de una clase. Es decir cuando
pasamos de la clase a la construccin fsica del objeto entonces
estamos hablando de la instancia de una clase y por lo tanto
podemos asegurar que un objeto es la instancia de una clase.
Los objetos deben colaborar unos con otros para solicitar a otras
clases que realicen operaciones que ellos por si solos no pueden
realizar, ahora te preguntars Por qu no puedo tener un solo
objeto que haga todo?, la respuesta es simple, los objetos
compuestos son difciles de arreglar cuando estn malos y adems
son muy costosos de producir, piensa en lo siguiente, si se te echa
a perder el monitor de tu computador, cambias el computador
completo o slo el monitor? Si te fijas en este caso, es ms barato
Pgina 144 de 154

cambiar el monitor que el computador completo y adicionalmente
para la fbrica es ms barato producir slo monitores que los
computadores completos, lo mismo sucede con casi todos los
objetos que ves a diario y con los cuales interactas, estos estn
compuestos de otros objetos, pues es ms fcil remplazar y
construir las partes especficas de cada una. Por lo tanto para
lograr un objetivo mayor, un objeto solicita a otro objeto que
realice una accin mediante la comunicacin utilizando mensajes,
estos mensajes permiten que los objetos colaboren y as los
objetos pueden lograr especificidad y hacerse especialistas en una
o varias operaciones. Por ejemplo el delantero hace goles como
funcin principal, pero adems tambin puede quitar la pelota
como el defensa, el defensa a su vez, puede quitar a la pelota y
hacer goles, pero cada uno de ellos cumple una funcin de mejor
forma, as cuando uno de ellos se lesiona es cambiado por otro que
realiza la misma funcin.
En el diagrama de clases es posible ilustrar estas relaciones

mediante una lnea que une cada una de las clases, y
adicionalmente segn el tipo de relacin que se establece, tambin
se pueden agregar algunos otros elementos que permitan aclarar
la relacin que se establece entre las clases.
Bsicamente la relacin que se establece entre dos objetos tiene

que ver con la comunicacin que estos establecen, as un objeto se
comunica con otro o colabora con otro objeto cuando le solicita
que realice una accin para la cual l no fue creado pero que
necesita, por ejemplo, cuando utilizas el control remoto para
prender o cambiar el canal de la televisin, lo que estas haciendo
es utilizar una funcin que est implementada en el control remoto
Pgina 145 de 154

(controlar las funciones del televisor de forma remota) , como tu
no puedes prender el televisor ni cambiar los canales de forma
remota, necesitas de la ayuda o colaboracin del control remoto
para poder realizar la tarea.
De esta forma los objetos colaboran y establecen relaciones entre

ellos. Ahora no siempre todos los objetos colaboran entre s, y es
posible que un objeto colabore slo con otro objeto, eso s,
siempre los objetos colaboran con al menos uno.
Si te fijas a tu alrededor, todo lo que ves son objetos compuestos

de varios otros objetos que estn colaborando unos con los otros.
Fjate por ejemplo en tu computador, en la lavadora o la cocina de
tu casa, en el cuadro que est colgado en a pared, en el reloj que
llevas, en la ropa que tienes puesta, cada uno de esos objetos esta
compuesto de otros objetos cuya colaboracin permite que el
objeto exista, pregntate lo siguiente Qu es un teclado sin
teclas?, Qu hago con un computador sin monitor?, De qu me
sirve un auto sin ruedas?
Como a veces las relaciones que se establecen entre los objetos

son muy complejas, se han establecido categoras o tipos de
relaciones que permiten diferenciar los tipos de relaciones
existentes, pues aunque no lo creas existen distintos tipos de
relaciones entre los objetos, las cuales definiremos a continuacin.
Asociacin.
La relacin de asociacin, se define cuando una clase se asocia con
otra para lograr un objetivo, este tipo de relacin es el ms bsico,
en este caso cada una de las clases tiene una instancia de la otra.
El conector puede incluir el nombre del rol en cada uno de los
Pgina 146 de 154

extremos, la cardinalidad, la direccin de la relacin y las
restricciones. Veamos el siguiente ejemplo:
Vamos a describir ahora en qu consiste cada una de las partes

que componen el ejemplo anterior.
El conector es la lnea que permite establecer que existe una

relacin entre las clases. Fjate que el conector adicionalmente
puede tener el nombre del rol de esa clase en esa relacin. Por
ejemplo en determinado momento tu estableces en tu casa varios
roles en funcin de con quin te relaciones, si te relacionas con tus
hermanos, tu rol es el de hermano, si te relacionas con tus padres
tu rol es el de hijo, la importancia de definir bien el rol radica en el
conjunto de comportamientos que implementas para esa relacin
en particular.
La direccin de la relacin permite establecer cual es la clase que

genera las instancias de la otra clase.
Las restricciones son bsicamente anotaciones con instrucciones o

con caractersticas que no pueden ser escritas en el diagrama de
otra forma. Las restricciones suelen encerrarse entre llaves {},
como en el siguiente ejemplo:
Pgina 147 de 154

Multiplicidad.
La cardinalidad o multiplicidad en una relacin establece el grado y
nivel de dependencia, de esta forma podemos determinar que
existen varios tipos de cardinalidad:
Asociacin uno a uno (1..1): En una relacin de asociacin uno

a uno, sta es en ambas direcciones, por lo mismo los objetos de
ambas clases estn asociados slo a un objeto de la otra clase, por
ejemplo la relacin de exclusividad que existe entre el gerente de
una empresa y la empresa, as el gerente slo puede ser gerente
de una empresa y la empresa slo puede tener un gerente.
Asociacin uno a muchos(1..*): en esta relacin, se produce

una relacin uno a muchos en una direccin y en la otra una
relacin uno a uno, por ejemplo la relacin entre el hroe y la
cantidad de balas que puede disparar, si te fijas en las pelculas de
accin los hroes poseen cargadores infinitos de balas, nunca
sabemos cuando se van a acabar. De esta forma, el hroe posee
un cargador con muchas balas (no sabemos el nmero exacto) y
esas balas pertenecen slo al hroe.
Pgina 148 de 154

Asociacin numricamente especificada(n..m): en este caso la
asociacin se realiza un nmero de veces especificado, por
ejemplo en un equipo de voleibol, la cantidad mnima de jugadores
es 6 y la mxima 12, fjate que las cotas mnimas y mximas estn
bien definidas y no pueden ser mayores o menores es decir un
equipo no puede tener 5 o 4 jugadores como tampoco puede tener
13 o 14 pero si puede tener 8.
Asociacin opcional (0..*): en este caso, la relacin no establece

obligatoriedad de existencia en la relacin, por ejemplo la relacin
que se da entre el dueo de una cuenta de banco y las tarjetas de
crdito que este posee. No todos los dueos de las cuentas de
banco poseen tarjeta de crdito. Cabe hacer notar que la relacin
que se establece del otro lado siempre es de uno a uno.
Asociacin muchos a muchos (*..*): en este caso la relacin se

establece entre clases con una asociacin de uno a muchos en
ambas direcciones, por ejemplo la relacin que se establece entre
los alumnos y las asignaturas que inscriben en el semestre, si te
fijas un alumno tiene muchas asignaturas inscritas y cada
asignatura a su vez posee muchos alumnos.
Asociacin calificativa.
Este tipo de asociacin est asociada a la relacin del tipo uno es a
muchos, en el cual se requiere explicitar algn atributo que
definir un identificador nico para una clase y de esta forma
poder diferenciar cada uno de los objetos de la relacin, por
ejemplo cada uno de los buses para un recorrido del Transantiago 9
9
http://es.wikipedia.org/wiki/Transantiago
Pgina 149 de 154

est asociado al recorrido con una relacin del tipo uno a muchos,
para poder identificar a cada bus de forma individual ocupamos el
atributo patente del vehculo para establecer la relacin. De esta
forma la asociacin calificada quedara de la siguiente forma:
Asociacin reflexiva.
La asociacin reflexiva se da cuando la relacin se establece entre
elementos del mismo tipo, es decir la clase se relaciona consigo
misma, pudiendo establecer el rol para clarificar la relacin, por
ejemplo supongamos que necesitamos establecer la relacin
existente entre los trabajadores sabiendo que uno es el jefe y el
resto son empleados, si te fijas todos son empleados, pero su rol
los diferencia.
Pgina 150 de 154

Herencia.
La asociacin de herencia permite que las clases que se relacionan,
lo puedan hacer en un nivel de especificidad, es decir que las
clases que se estn asociando son clases iguales salvo que una de
ellas es ms especfica, es decir implementa ms mtodos o los
mismos mtodos pero con una implementacin distinta.
Asociacin.
Existen algunos tipos especiales de asociacin que veremos a
continuacin, estos tipos especiales permiten representar
asociaciones ms complejas.
La asociacin ternaria es una asociacin entre tres clases de forma

simultnea, la cual no puede ser leda o agrupada slo de a dos
clases pues pierde el sentido. Por ejemplo se puede establecer una
relacin entre artista, cancin e instrumento o entre jugador,
equipo y posicin. En los dos ejemplos anteriores podramos
analizar la relacin de a pares pero pierde su significado o
semntica, Para establecer la relacin ternaria se dibuja un rombo
entre las tres clases. Al igual que en el resto de las asociaciones,
puedes agregar caractersticas de cardinalidad a la relacin.
Pgina 151 de 154

Otra relacin de asociacin particular son las clases de asociacin.
Una clase de asociacin aquella que modela una asociacin entre
dos o ms clases. Los atributos de la clase de asociacin son los
atributos de la asociacin. En el caso de una asociacin compleja
entre dos o ms clases, es posible que una clase de asociacin
tenga sus propios atributos, los cuales sirven para dar significado a
la relacin. Como ejemplo, analicemos la relacin existente entre
los alumnos y las asignaturas que cursan este semestre, si
analizamos la relacin, nos damos cuenta de que existe una
relacin de muchos a muchos, en este caso en particular se puede
crear una clase de asociacin llamada horario que permite
establecer que alumno esta asociado a que asignatura especfica.
Pgina 152 de 154

Otros tipos de relaciones son las relaciones de composicin y
agregacin. Estas relaciones son muy parecidas y se basan en el
concepto de que una clase es una parte del todo, por ejemplo la
lmpara se compone de un interruptor, el soquete, la ampolleta y
la pantalla, se establece una relacin de uno a uno entre la clase
lmpara y sus componentes (el todo y las partes).
La agregacin es un tipo de relacin en dnde el todo esta

compuesto de partes pero la existencia de las partes no est
definida por la existencia del todo, por ejemplo, sabemos que los
vehculos tienen ruedas, si analizamos esta relacin, sabemos que
las ruedas existen y estn presentes en el modelo de forma
independiente al medio de transporte en el cual se ocupen. De esta
forma si el medio de transporte se destruye, las ruedas siguen
existiendo en el modelo.
La composicin es un tipo de relacin ms fuerte que la

agregacin. La composicin es tambin una relacin entre
instancias. As los objetos que participan en la relacin, nacen,
viven y mueren relacionados con el todo. A menudo las clases de
composicin se asocian a relaciones fsicas entre los objetos. Por
ejemplo si observas una camisa, observas que est compuesta por
un grupo de partes (mangas, bolsillo, cuello, puos) y que cada
uno establece una relacin ms fuerte, en este caso si la camisa se
destruye, la utilidad de la manga o del cuello se pierden pues su
existencia tiene significado slo cuando es parte de una camisa.
La distincin entre las relaciones de composicin y agregacin es

muy sutil y a menudo conlleva acalorados debates y discusiones
respecto a cuando es una u otra, generando conflictos insolubles
Pgina 153 de 154

entre hermanos, amigos y parejas, al punto de devolverse las
cartas y los peluches regalados.
Realizacin.
Una relacin de realizacin esta dada por una clase y una interfaz.
En orientacin a objetos, una clase de interfaz es una clase que
define el comportamiento de una clase pero jams la implementa,
esto que parece tan complejo lo podemos definir como una clase
que es un cascaron sin cdigo por dentro. Te estars preguntando
Y para que quiero tener una clase que no hace nada y que no
tiene cdigo?, la respuesta no es simple pero lo podemos explicar
mediante un ejemplo.
Supongamos que estas creando un video juego y debes crear las
clases de tu juego, si te fijas los objetos de la pantalla se estn
moviendo, pero la nave se mueve en funcin de las teclas que
presiones en el teclado o de los botones del joystick que presiones,
mientras que las balas se desplazan siguiendo una trayectoria que
no se puede cambiar, ambos objetos se desplazan pero lo hacen
de forma distinta, por lo tanto como ambos poseen el mismo
mtodo (mover) pero los dos lo hacen de forma distinta entonces
se crea una clase de interfaz que posea el mtodo y como este
mtodo o comportamiento no se programa, le da la libertad a las
clases que heredan de esta clase de interfaz a que lo implementen
de forma independiente.
Pgina 154 de 154

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

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

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

Cargado por

Copyright:

Formatos disponibles

Manual para la asignatura de Anlisis y Diseo Orientado a

Objetos Versin 1.1. Santiago Marzo de 2012

Este material ha sido diseado para el uso de los alumnos y

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

De forma significativa agradecemos a los docentes de las sedes que

Vayan nuestros sinceros agradecimientos a los siguientes docentes:

Cristian Leiva Marn, Miguel Palma Esquivel, Marcelo Montecinos

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

El aporte realizado por ustedes durante las jornadas de capacitacin

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

Introduccin al anlisis y diseo Orientado a Objetos .............................................................................................8

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

El primer paso consiste en hacer anlisis, entender el problema de

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

El proceso de anlisis y diseo orientado a objetos (desde ahora

Importancia del anlisis y diseo

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

Un correcto proceso de anlisis permitir a los ingenieros de

Diferentes metodologas de anlisis

Como definicin formal podemos decir que una metodologa

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

De esta forma podemos decir que las metodologas como un

La metodologa estructurada se origin en los lenguajes de

Adicionalmente a sta, surge la metodologa orientada a objetos,

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

El desarrollo de proyectos de tecnologas de informacin

En trminos sencillos, el anlisis y diseo orientado a objetos est

La etapa de anlisis de sistemas es la primera parte del proceso de

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

Basndose en el sistema estudiado, se prepara un modelo del

La etapa de diseo del sistema es la siguiente etapa de desarrollo

En la etapa de diseo de los objetos, se definen los detalles del

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

Las metodologas orientadas a objeto se basan en la identificacin

Mientras se desarrolla el proyecto, se utilizan ciertos modelos para

a) Modelo de objetos: Este modelo describe a los objetos en un

b) Modelo dinmico: Este modelo describe a los objetos en su

c) Modelo de flujo de datos: Este modelo describe bsicamente los

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

Reusabilidad: Las estructuras que se construyen pueden

Los sistemas diseados utilizando este enfoque estn ms

La metodologa orientada a objetos representa el dominio del

Los objetos en el modelo son inmunes a los cambios en los

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

Los diseos realizados con esta metodologa enfatizan la

Las metodologas orientadas a objetos, tienen una aproximacin

Los datos, la informacin y su

Los sistemas de informacin que poseen las organizaciones y los

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

Cuando una organizacin registra informacin relativa a procesos

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

Volviendo a la definicin de los datos en el contexto, una vez que

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

UNIVERSIDAD TECNOLGICA DE CHILE INACAP - REA INFORMTICA Y TELECOMUNICACIONES

Sistema 1 Componente del Sistema

Frontera del Sistema