manual análisis y diseño orientado a objeto versión 1.1 (1)
TRANSCRIPT
Página 1 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Manual para la asignatura de Análisis y Diseño Orientado a
Objetos Versión 1.0. Santiago Marzo de 2012
Este material ha sido diseñado para el uso de los alumnos y
profesores de la asignatura de Análisis y Diseño Orientado a
Objetos de las carreras del área informática. Queda
estrictamente prohibido el uso en otros cursos ya sean en
línea o presenciales sin el consentimiento explícito de
INACAP.
Página 2 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Agradecimientos.
Agradecemos a todas las personas que de forma directa o indirecta
han colaborado en la elaboración de este manual.
De forma significativa agradecemos a los docentes de las sedes que
nos han apoyado y colaborado con ejercicios y propuestas durante
la presentación de este proyecto.
Vayan nuestros sinceros agradecimientos a los siguientes docentes:
Cristian Leiva Marín, Miguel Palma Esquivel, Marcelo Montecinos
Cabrera, Rodrigo Toledo de los Santos, Paola Cifuentes Berrios,
Servando Campillay Briones, Emerson Ilaja Villarroel, Hugo Herrera
Valenzuela, Fernando Santolaya, Manuel Morales, Roberto Pérez
Fuentes, Fernando Neyra Castro, Victor Bórquez, Francisco Andrés
Díaz Rojas, Ademar Araya Fuentes, Ricardo Vera Muñoz, Mauricio
Torres Pizarro, Ernesto Ramos Vega, Alberto Garrido Burgos, Helton
Bustos Sáez, Beatriz Contreras Guajardo, José Landeta Parra, Luis
Pacheco Toro, Patricio Araya Castro, Iván Torres, Hinojoza Vega
Mauricio, Yasna Hernández, Víctor Orellana, Rene Valderas Aros,
Ricardo Toledo Barría, Cesar Eduardo Arce Jara, Luis Ponce
Cuadra, Javier Miles Avello, Carolina Ehrmantraut Caballero, Pedro
Alfonso Fuentealba Martínez, Jorge Hormazabal Valdés, Pedro
Ernesto Ulloa Morales, María del Pilar Gallego Martínez, Claudio
Fuenzalida Medina, María Encarnación Sepúlveda, Francisco San
Martin, Christian Sarmiento Zampillo, Román Gajardo Robles,
Ricardo Hidalgo Hidalgo, Nelson Fredy Ganga Calderón, Manuel
Reveco Cabellos, Jacqueline San Martin Grandon, Sergio Vergara
Salvatierra, Pablo López Chacón, Cinthya Acosta, Jocelyn Oriana
Página 3 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
González Cortés, Carlos Felipe Alten López, Francisco Prieto Rossi,
Giannina Costa Lizama, Christian Silva, Sebastián Pastén Díaz.
El aporte realizado por ustedes durante las jornadas de capacitación
ha significado mejorar enormemente la calidad del material
entregado.
Saludos.
Página 4 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Índice
Introducción al análisis y diseño Orientado a Objetos .............................................................................................8
Definición del análisis y diseño orientado a objetos ......................................................................................... 11
Importancia del análisis y diseño orientado a objetos ...................................................................................... 11
Diferentes metodologías de análisis de sistemas. ............................................................................................. 12
Los datos, la información y su importancia para las organizaciones. ............................................................... 18
Definición de los datos en el contexto de un problema. ................................................................................... 20
Teoría de sistemas básica y la interacción de los objetos en una organización................................................ 24
Patrón ECB (Entity – Control – Boundary) ......................................................................................................... 27
Datos, comportamiento y relaciones de los objetos. ........................................................................................ 31
Definición de UML ............................................................................................................................................. 36
Etapas del ciclo de vida utilizando RUP (Rational Unified Process) .................................................................. 37
Diagramas de Estructura. .................................................................................................................................. 41
Diagrama de clases ........................................................................................................................................ 41
Diagrama de objeto ....................................................................................................................................... 49
Diagrama de estructuras compuestas. .......................................................................................................... 52
Diagramas de componentes. ......................................................................................................................... 54
Diagrama de despliegue. ............................................................................................................................... 57
Diagrama de paquete. ................................................................................................................................... 59
Diagramas de comportamiento. ........................................................................................................................ 61
Diagrama de casos de uso. ............................................................................................................................ 61
Diagrama de máquina de estados. ................................................................................................................ 64
Diagrama de actividad. .................................................................................................................................. 66
Diagramas de Interacción. ................................................................................................................................. 68
Diagrama de secuencias. ............................................................................................................................... 68
Diagrama de tiempo. ..................................................................................................................................... 71
Técnicas de recopilación y análisis de requerimientos. ........................................................................................ 75
Técnicas de captura de requerimientos. ........................................................................................................... 75
Entrevista. ...................................................................................................................................................... 79
Página 5 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Encuesta. ....................................................................................................................................................... 79
Observación directa. ...................................................................................................................................... 80
Definición de actividades. .................................................................................................................................. 80
Relación entre las actividades y los actores. ..................................................................................................... 82
Análisis básico de los requerimientos para la realización de un listado de actividades. .................................. 83
Diagrama de flujo de datos (Agile Unified Process). ......................................................................................... 85
Diagrama de procesos (BPMN 2.0) .................................................................................................................... 91
Diagrama de casos de uso. .................................................................................................................................. 100
Componentes del diagrama de casos de uso. ................................................................................................. 103
Actores. ........................................................................................................................................................ 105
Casos de uso. ............................................................................................................................................... 106
Relaciones. ................................................................................................................................................... 110
Identificación del contexto en el que participan los actores. ......................................................................... 113
Identificación de los roles. ............................................................................................................................... 114
Definición de los actores. ................................................................................................................................ 115
Definición de los casos de uso. ........................................................................................................................ 116
Definición de los casos de uso. ........................................................................................................................ 117
Definición de los tipos de relaciones ............................................................................................................... 119
Comunicación. ............................................................................................................................................. 119
Inclusión. ...................................................................................................................................................... 119
Extensión. .................................................................................................................................................... 120
Generalización. ............................................................................................................................................ 121
Documentación de los casos de uso................................................................................................................ 121
Definición del caso de uso. .............................................................................................................................. 122
Flujo Normal. ................................................................................................................................................... 122
Pre-condiciones. .............................................................................................................................................. 123
Post-condiciones. ............................................................................................................................................ 123
Diagrama estático de clases. ............................................................................................................................... 126
Introducción al diagrama estático de clases. .................................................................................................. 126
Utilidad del diagrama estático de clases. .................................................................................................... 127
Componentes del diagrama estático de clases. .......................................................................................... 128
Página 6 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Relación entre las clases y las tablas de un modelo entidad relación. ............................................................ 138
Componentes del diagrama estático de clases. .............................................................................................. 139
Relaciones entre las clases. ............................................................................................................................. 142
Asociación. ................................................................................................................................................... 145
Multiplicidad. ............................................................................................................................................... 146
Asociación calificativa. ................................................................................................................................. 148
Asociación reflexiva. .................................................................................................................................... 148
Herencia. ...................................................................................................................................................... 149
Asociación. ................................................................................................................................................... 149
Realización. .................................................................................................................................................. 152
Página 7 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Página 8 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Introducción al análisis y diseño
Orientado a Objetos
Bienvenido al mundo de los objetos! te felicito por emprender este
camino, aprenderás a ver tu entorno de una forma distinta. Para
ello comenzaremos trabajando con la forma en que piensas y
cambiaremos el modo en la que analizas las cosas, el objetivo es
convertirte en una persona capaz de hacer un buen análisis sobre
las situaciones que te rodean, ya que esto tendrá un directo
beneficio en los programas computacionales que crearás en el
futuro próximo y la forma en la que entregarás soluciones al medio
que te rodea. Mientras mejor entendamos nuestro entorno
podremos tomar mejores decisiones. Todos hemos utilizado
software alguna vez y de seguro que has encontrado algunos
mejores que otros, probablemente en este momento estés
recordando dos o más software que hayas usado y cuál de ellos te
agradó más, no sólo considerando la usabilidad o lo vistoso del
software, sino a un mundo completo que esta detrás que aún no
conoces pero del cual serás partícipe muy pronto, que va en desde
cómo utiliza el hardware en el que funciona, la velocidad en la que
se comunica por la red con otros componentes de software e
incluso con la optimización con la que realiza cálculos y los entrega
al usuario. ¿Quién se encarga de todo eso? ¿Existe algún
responsable de que todas las partes trabajen en forma eficiente?
¿Quién debe velar porque lo que se construye solucione de la
mejor forma posible un problema? Como me imagino ya lo
adivinarás esa persona en un futuro cercano serás tú.
Página 9 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Por eso es tan importante tener una buena capacidad de análisis,
de esta forma comprenderás mejor las cosas y podrás tomar
mejores decisiones, mientras más comprendemos menos
deberemos memorizar.
El primer paso consiste en hacer análisis, entender el problema de
tu cliente e identificar una buena solución. El segundo paso será
diseñarla, el paso previo a construirla. Muchos software comienzan
a ser codificados sin un buen análisis, lo que da como resultado un
producto deficiente que no soluciona el problema del cliente. Un
mal diseño provocara un software con errores en el cual se habrá
trabajado probablemente el doble de lo necesario, los errores en
diseño comienzan notarse tarde en el desarrollo haciendo que una
gran cantidad de programas queden en el 90% de su construcción,
haciendo que el 10% restante implique incluso más trabajo que el
90% anterior. Para que te hagas una idea esto no es algo que no
pase en el resto de las disciplinas, ¿has pensado en cómo quedaría
un edificio si la constructora comienza su tarea sin un análisis y
diseño apropiado? y si lo logra, ¿soportará el próximo temblor?
Ahora pensemos en qué sucede si el diseño es apropiado, pero
proviene de un mal análisis de requerimiento y si bien el edificio
queda bonito con 80 pisos, grandes ventanales y piscina en la
azotea, pero después de construido y luego de una larga y
pausada conversación con tu cliente en la cual te tomas más
tiempo para entenderlo, haces un mejor análisis y te das cuenta
que lo que en realidad necesitaba era un bunker subterráneo para
sobrevivir al paso de un tornado. A estas alturas ya no hay nada
que hacer, desarmar el edificio, para dejar el terreno libre para
luego comenzar a diseñar y construir un bunker llevará sin duda a
tu empresa a un fracaso, deja a tus clientes sin un bunker y a tí en
Página 10 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
un serio problema, por esto una buena capacidad tanto de análisis
como de diseño es tan importante.
Página 11 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Definición del análisis y diseño
orientado a objetos
El análisis y diseño orientado a objetos es un enfoque de la
ingeniería de software que permite modelar un sistema como un
conjunto de objetos relacionados que interactúan entre si. Para
lograr esta tarea, el análisis y diseño orientado a objetos propone
una serie de diagramas entre los que destacan los diagramas
propuestos en UML (Unified Modeling Language o Lenguaje
Unificado de Modelado) que surge como una estandarización de los
diagramas propuestos por muchos teóricos de esta disciplina
alrededor del mundo.
El proceso de análisis y diseño orientado a objetos (desde ahora
ADOO) se basa en analizar un problema (generalmente asociado al
manejo de datos) y tratar de resolverlo utilizando para esto
estructuras del mundo real. La unidad básica es el objeto, que
combina datos y comportamientos que se realizan con estos datos
y que se unen en una estructura atómica.
Importancia del análisis y diseño
orientado a objetos
El ADOO es parte de un proceso que se conoce como Ingeniería de
Requerimientos, que consiste en tratar de recopilar la mayor
cantidad de datos disponible respecto a una serie de procesos para
los cuales se requiere construir una solución utilizando tecnologías
de información. Las tecnologías de información son un grupo de
tecnologías cuyo propósito es gestionar los datos que son
importantes para una organización. Por lo tanto los sistemas que
Página 12 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
utilizan tecnologías de información, no sólo hacen referencia al
software, sino que también a los procesos, las personas y la
infraestructura (hardware) necesario para poder administrar de la
mejor forma posible los datos que son necesarios para que la
organización realice su propósito.
Un correcto proceso de análisis permitirá a los ingenieros de
software tomar mejores decisiones para la creación, gestión y
administración de proyectos de tecnologías de información. Un
análisis incorrecto puede generar un enorme costo para la
organización, pues ésta puede tomar malas decisiones respecto a
su negocio por no contar con la información correcta en el
momento adecuado. Adicionalmente, el desarrollo de un proyecto
de tecnologías de información no es un proceso que se realiza de
un día para otro, sino que requiere de un tiempo que es difícil de
estimar en un principio y por lo tanto su costo puede elevarse en
demasía si el análisis inicial no está bien hecho, por lo que esta
etapa resulta crucial en el desarrollo de los proyectos de
tecnologías de información.
Diferentes metodologías de análisis
de sistemas.
Al realizar el análisis de procesos en las organizaciones, existen
diferentes metodologías que se pueden ocupar para lograr el
resultado esperado.
Como definición formal podemos decir que una metodología
“…hace referencia al conjunto de procedimientos racionales,
Página 13 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
utilizados para alcanzar una gama de objetivos que rigen en una
investigación científica, una exposición doctrinal o tareas que
requieran habilidades, conocimientos o cuidados específicos.
Alternativamente puede definirse la metodología como el estudio o
elección de un método pertinente para un determinado objetivo.”1.
De esta forma podemos decir que las metodologías como un
conjunto de pasos para lograr un objetivo, se pueden clasificar
utilizando el enfoque que se aplica para el proceso, existiendo dos
metodologías básicas, una metodología estructurada y una
metodología orientada a objetos.
La metodología estructurada se originó en los lenguajes de
programación estructurados para dar soporte a las necesidades del
lenguaje. Esta metodología sentó las primeras estructuras para la
definición de la llamada “ingeniería de software” es decir se
definieron fases y etapas para dar solución a proyectos de software
que se van a desarrollar utilizando un lenguaje de programación
estructurado.
Adicionalmente a ésta, surge la metodología orientada a objetos,
la cual se ha desarrollado y ha permanecido en el tiempo siendo el
paradigma de análisis y diseño de proyectos de tecnologías de
información más utilizada en estos tiempos. Esta metodología que
comenzó a desarrollarse a finales de los años sesenta de la mano
del desarrollo de lenguajes de programación orientados a objetos,
ha evolucionado durante todos estos años, estableciendo una serie
de pasos que han sido extraordinariamente probados en una serie
de proyectos. Esta metodología evoluciona constantemente y los
estudiosos del tema desarrollan nuevas formas optimizadas y cada
1 http://es.wikipedia.org/wiki/Metodolog%C3%ADa
Página 14 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
vez más específicas para el análisis y diseño en situaciones
particulares llamadas patrones de diseño.
El desarrollo de proyectos de tecnologías de información
orientados a objetos, requieren técnicas orientadas a objetos que
se aplican durante las etapas de análisis, construcción e
implementación del proyecto. Estas metodologías requieren que se
detecten los objetos del sistema, cómo éstos interactúan, cómo se
comportan en el tiempo y las responsabilidades que asumen al
relacionarse con otros objetos. El análisis orientado a objetos mira
todos los objetos en el sistema, agrupa sus características y
comportamientos comunes, estudia sus diferencias y cómo el
sistema maneja estos objetos para lograr su objetivo.
En términos sencillos, el análisis y diseño orientado a objetos está
basado en identificar a los objetos en un sistema y sus
interrelaciones. Una vez que esta parte está hecha, es necesario
modelar el sistema, esta etapa es similar a la etapa de la
metodología estructurada, pues también se sigue un proceso
secuencial pero con una aproximación diferente. Las etapas
básicas del diseño de sistemas en un modelo orientado a objetos,
se pueden listar de la siguiente forma:
Análisis de Sistemas.
Diseño del sistema.
Diseño de los objetos.
Implementación.
La etapa de análisis de sistemas es la primera parte del proceso de
desarrollo de proyectos de tecnologías de información orientados a
objetos, al igual que en las otras metodologías. En esta fase es
Página 15 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
necesario interactuar con los usuarios del sistema (los que realizan
las acciones) para identificar sus necesidades y analizar el sistema
para entender su funcionalidad.
Basándose en el sistema estudiado, se prepara un modelo del
sistema definido. Este modelo está basado puramente en lo que se
requiere que el sistema haga. En esta etapa los detalles de
implementación (como se van a hacer las cosas) no son tomados
en cuenta. Sólo se prepara un modelo del sistema basándose en la
idea de que el sistema es un conjunto de objetos que interactúan.
La etapa de diseño del sistema es la siguiente etapa de desarrollo
dónde se decide la arquitectura del modelo completo (hardware y
software). Este sistema complejo es organizado en un conjunto de
sub procesos, cada uno con su proyecto individual, los cuales van
a interactuar unos con otros. Mientras se diseña el sistema, es
necesario poner especial atención a las especificaciones de los
procesos definidos en la etapa anterior por parte de los usuarios.
Como el análisis orientado a objetos percibe los sistemas como un
conjunto de objetos que interactúan, así mismo los sistemas más
grandes y complejos se pueden ver como un conjunto de pequeños
sistemas que interactúan entre sí.
En la etapa de diseño de los objetos, se definen los detalles del
análisis del sistema y del diseño para definir cómo serán
implementados. Acá se decide la forma en la que se van a
construir los objetos de manera de implementar las estructuras de
datos, los comportamientos y las relaciones entre cada uno de los
objetos.
Página 16 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
La fase de implementación implica transformar el diseño de los
objetos a código, utilizando algún lenguaje de programación.
Adicionalmente se construyen todas las estructuras que darán
soporte al funcionamiento del software (hardware y
procedimientos). También se construyen los almacenes de datos o
bases de datos, para dar una forma lo más funcional posible al
sistema.
Las metodologías orientadas a objeto se basan en la identificación
de los objetos del sistema. Cuando se observan de forma detenida,
los objetos muestran ciertas características y comportamientos
que les son propios.
Mientras se desarrolla el proyecto, se utilizan ciertos modelos para
identificar a los objetos. Básicamente se usan tres modelos:
a) Modelo de objetos: Este modelo describe a los objetos en un
sistema y sus interrelaciones. Analiza al sistema como un conjunto
de elementos estáticos y no se preocupa de la dinámica que estos
puedan tener.
b) Modelo dinámico: Este modelo describe a los objetos en su
aspecto dinámico, es decir muestra los cambios ocurridos en el
estado de varios objetos que estén interactuando en un momento
determinado.
c) Modelo de flujo de datos: Este modelo describe básicamente los
datos que han sido transformados por el sistema. De esta forma se
describen los flujos de los datos y los cambios que ocurren a los
datos a través del sistema
Página 17 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Comparada con las técnicas de desarrollo de sistemas
convencionales, el ADOO tiene muchas ventajas, algunos de ellos
son:
Reusabilidad: Las estructuras que se construyen pueden
ser utilizadas en otros proyectos, esto permite reducir los
tiempos de desarrollo, pues las clases que se construyen se
crean de tal forma que pueden ser mantenidas para usos
posteriores.
Herencia: El concepto de herencia ayuda al programador a
usar código existente de otra forma, es decir se pueden
agregar nuevas funcionalidades o extender la funcionalidad
ya existente para crear nuevas clases.
Ignorancia selectiva: la encapsulación es la técnica que
permite al programador esconder el funcionamiento interno
de los métodos al usuario. La encapsulación separa la
funcionalidad interna del objeto de las funciones externas
provistas al usuario. Esto permite al programador proteger el
código de cambios realizados por el usuario.
Los sistemas diseñados utilizando este enfoque están más
cercanos al mundo real pues las funciones del mundo real se
mapean directamente a los sistemas.
La metodología orientada a objetos representa el dominio del
problema, pues es fácil reproducir e interpretar los diseños.
Los objetos en el modelo son inmunes a los cambios en los
requerimientos, un objeto alumnos será un objeto alumno
independiente de más o menos atributos o comportamientos que
Página 18 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
se agreguen. Por lo tanto los cambios se pueden desarrollar de
forma más fácil.
Los diseños realizados con esta metodología enfatizan la
reutilización. Las nuevas aplicaciones pueden usar módulos ya
existentes, por lo tanto se reduce el tiempo de análisis y
desarrollo, redundando esto en un costo final menor al término del
ciclo de vida.
Las metodologías orientadas a objetos, tienen una aproximación
más natural, esto entrega mejores estructuras para el
pensamiento y la abstracción y permite un diseño más modular.
Los datos, la información y su
importancia para las
organizaciones.
Todas las organizaciones basan su quehacer en la toma de
decisiones, estas decisiones se toman utilizando los datos que la
organización posee.
Los sistemas de información que poseen las organizaciones y los
que nosotros tengamos que construir se basan en el proceso de
capturar datos, almacenarlos, procesarlos y obtener un resultado
que es mostrado al usuario. Los datos que son capturados
corresponden a un par ordenado de atributo con valor (atributo,
valor) que representa el registro de un hecho importante para la
organización sucedido en algún momento específico. El atributo
define qué es lo que quieres guardar y el valor define el tipo de
valor asociado, es decir los rangos máximos y mínimos, y el tipo
Página 19 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
de dato. Los datos siempre están formados por un par ordenado,
ya que cada una de las partes por separado no tienen sentido. Por
ejemplo (edad, 21 años).
Cuando una organización registra información relativa a procesos
que son importantes, lo hace exclusivamente para poder procesar
estos datos, transformarlos en información y luego analizar esta
información y tomar decisiones más acertadas. Este proceso de
toma de decisiones se ha especializado en extremo, como por
ejemplo con la minería de datos, que consiste en analizar los datos
ya almacenados y extraer información que se desconocía que
existía ahí, esto que si bien parece ser un poco complicado,
permite a las organizaciones descubrir nuevas interpretaciones de
los datos que tienen almacenados, siempre con el propósito de
tomar mejores decisiones.
Página 20 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Definición de los datos en el
contexto de un problema.
Cuando se definen los datos a almacenar es necesario siempre
pensar en el proceso que se desea registrar. Recuerda que en
todas las organizaciones, el proceso de registro de datos no se
hace al azar, es decir cuando se registra el proceso es necesario
determinar el contexto en el cual se encuentra inmerso el proceso.
Por ejemplo, si tu organización realiza un proceso de compra y
venta de productos, te va a interesar fundamentalmente registrar
esos procesos y todos los otros anexos a ese proceso, por eso es
necesario determinar cuál es el proceso que se quiere registrar,
pues de este análisis dependerán los datos que se elijan. Un punto
muy importante a recalcar en esta etapa es el hecho de que las
organizaciones realizan distintas acciones durante su ciclo de
proceso, pero hay algunos procesos que conforman el quehacer
básico de la organización. Ahora si bien es posible detectar el
quehacer de una organización de forma relativamente simple, es
necesario siempre hacer un análisis en función de determinar los
datos que se deben registrar, por ejemplo, si analizamos los
procesos que realiza una panadería, nos podemos dar cuenta
fácilmente que el proceso fundamental de una panadería, en la
mayoría de los casos es fabricar y vender pan. Ahora bien si te
fijas también hay otros procesos en el ciclo de vida de la
organización como por ejemplo pagar los sueldos, comprar las
materias primas, distribuir el pan entre los clientes, llevar el
registro contable, registrar las ventas, etcétera. Ahora, una vez
que has definido los procesos, debes seleccionar los procesos más
relevantes para los cuales vas a registrar los datos, siempre
Página 21 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
pensando en un contexto determinado. Así si lo que te interesa es
registrar los procesos productivos de la empresa, deberás registrar
los datos de las compras de insumos, transformación de materias
primas a pan y su posterior venta.
Página 22 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Si te fijas en este contexto dejamos varios procesos fuera, pero
eso es lo interesante de este trabajo, debes concéntrate en lo
importante, es decir sólo en el ámbito que te incumbe en ese
momento, pues no existe una solución para todas las áreas al
mismo tiempo. Esta lógica de división de los proyectos en
pequeños proyectos que se preocupen de áreas específicas de la
organización garantiza dos cosas fundamentales, primero garantiza
menos costos iniciales en el desarrollo de la solución y segundo,
disminuye el tiempo de análisis y desarrollo pues se disminuye la
complejidad de los procesos a analizar (son menos los procesos
que se deben analizar al mismo tiempo), lo cual genera la
sensación al usuario de que todo avanza más rápido.
Volviendo a la definición de los datos en el contexto, una vez que
defines el contexto y defines los procesos básicos asociados a ese
contexto, puedes definir las estructuras de los datos. La estructura
de un dato, está asociada al concepto de dominio del dato, es decir
al tipo de dato que se seleccione (número entero, decimal,
caracteres, verdadero o falso, un objeto, etc.) y además los
valores permitidos, máximos y mínimos. Por ejemplo si analizamos
los datos que podemos registrar de un alumno al momento de
matricularlo (este es el contexto), nos podrían interesar datos
como los siguientes:
Página 23 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Si analizamos ahora el dato de la edad, y nos detenemos a pensar
un momento, podemos determinar que este dato por ejemplo es
un valor numérico entero (raramente tengo 15,76789 años), ahora
el rango de los posibles valores enteros es muy extenso y por lo
tanto es necesario el determinar cuales de estos valores me sirven,
así logro determinar que cuando recién vi la luz del mundo, tenía 0
años y según Wikipedia, la persona más longeva de la tierra tuvo
122 años2, por lo tanto el valor máximo para este dato debería ser
al menos 122, de esta forma tenemos que la edad está compuesta
por valores numéricos enteros entre 0 y al menos 122.
2 http://es.wikipedia.org/wiki/Jeanne_Calment
Página 24 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Teoría de sistemas básica y la
interacción de los objetos en una
organización.
Existe una teoría básica para el análisis de las organizaciones
llamada teoría de sistemas. Esta teoría de forma muy simplificada
nos indica que un sistema es un conjunto de elementos que están
interrelacionados entre sí con un propósito en común, por lo tanto
el conjunto de elementos y sus interrelaciones conforman a un
sistema. Adicionalmente este sistema existe dentro de lo que se
conoce como la frontera del sistema (su contexto) y está sumido
en un medio ambiente.
Entrada Salida
Sistema 1
Sistema 2
Frontera del Sistema
Componente del Sistema
Medio ambiente
Página 25 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Todos los sistemas poseen un propósito específico y para lograrlo
reciben elementos (entradas) desde el medio ambiente, los
procesan y generan un resultado que se incorpora al medio
ambiente. Esta salida modifica el medio ambiente, el que al mismo
tiempo está siendo modificado por otros sistemas que también
consumen recursos del medio y generan salidas, esto provoca un
desbalance en el medio ambiente el cual es equilibrado
nuevamente por los mismos sistemas formando un delicado
balance en el ecosistema.
Con la información que tenemos ahora podemos implícitamente
definir algunas cosas, como por ejemplo que el conjunto de
sistemas que se encuentra en un medio ambiente determinado
también conforman un sistema, el cual a su vez esta compuesto
por otros sistemas. Un ejemplo de esto es un ser humano, está
compuesto de un conjunto de órganos que forman sub sistemas,
sistema digestivo, reproductor, nervioso central, etc. A su vez,
cada sistema está compuesto de órganos que están compuestos de
células y estas a su vez están compuestas de una serie de
componentes (membrana, núcleo, citoplasma). Ahora, si
analizamos al ser humano, éste pertenece a una familia, el
conjunto de familias forman una comunidad que está inserta en un
pueblo, que a su vez esta inserto en una ciudad que pertenece a
una región y esta a un país etc., etc...
Página 26 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
En las organizaciones la teoría de sistemas se aplica para poder
realizar un análisis más específico de las distintas áreas que
componen las organizaciones, sobre todo cuando se trata de
organizaciones complejas. Muchas veces las organizaciones son
separadas en departamentos (departamento contable, de personal,
de finanzas, de producción, etc.), esta separación permite analizar
cada sub sección de forma más específica, adicionalmente esta
separación permite que cada una de las secciones se especialice en
su trabajo.
Cuando realizamos un análisis de las organizaciones, nuestro
trabajo consiste en aplicar esta teoría de sistemas y
Página 27 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
complementarla con la orientación a objetos. De esta forma
debemos definir un contexto para la organización (frontera del
sistema), después debemos definir los objetos que están insertos
en el sistema (componentes del sistema) y las relaciones que se
establecen (relaciones del sistema).
Patrón ECB (Entity – Control –
Boundary)
Una forma relativamente simple de graficar la relación entre los
elementos que componen un sistema es ocupar los gráficos que
nos entrega el patrón ECB (Entity-Control-Boundary). Antes de
mostrar los gráficos, es necesario entender qué es un patrón en el
mundo del diseño y análisis de sistemas. Un patrón se puede
definir como: “…una solución a un problema de diseño que aparece
con frecuencia.”3 O también como está definido en Wikipedia “Los
patrones de diseño son la base para la búsqueda de soluciones a
problemas comunes en el desarrollo de software y otros ámbitos
referentes al diseño de interacción o interfaces”.
Un patrón de diseño es una solución a un problema de diseño.
Para que una solución sea considerada un patrón debe poseer
ciertas características. Una de ellas es que debe haber comprobado
su efectividad resolviendo problemas similares en ocasiones
anteriores. Otra es que debe ser reutilizable, lo que significa que
es aplicable a diferentes problemas de diseño en distintas
circunstancias.”4
3 “UML y Patrones”, Capitulo 18. Craig Larman. Prentice Hall.
4 http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o
Página 28 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
El patrón Entity Control Boundary (Entidad Control Frontera)5 se
basa en la detección de cada uno de los componentes del modelo
al momento de realizar el análisis, de esta forma podemos definir
que las entidades (Entity) son objetos que entregan o reciben
datos que son útiles para el sistema, la frontera (boundary) son
objetos que representan interfaces del sistema (métodos o
acciones con las cuales interactúan las entidades), los objetos de
control (Control) son objetos que intermedian entre las entidades y
las fronteras, están encargadas de orquestar la ejecución de
comandos que vienen definidos desde la frontera. La
representación gráfica de cada uno de los componentes es de la
siguiente forma:
5 Se optó por mantener el nombre del patrón tal cual como fue definido para evitar la confusión al leer otros apuntes.
Página 29 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Este gráfico nos permite entender de mejor forma como funciona
un sistema asociándolo a la forma en que cada uno de las
entidades interactúa con el sistema y como esta interacción gatilla
la ejecución de una serie de funciones que no se ven desde afuera
pero que deben ser analizadas para entender cómo funcionan las
cosas. Analicemos el siguiente caso: supongamos que vas a sacar
plata de un cajero automático. Si analizamos el proceso, vemos
que existe una interacción de tu parte con la interfaz del cajero lo
que gatilla alguna de las acciones que aparecen graficadas a
continuación.
Página 30 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Fíjate que sólo analizamos las funciones básicas del cajero (sacar
plata, solicitar el saldo, transferir fondos), pero ¿qué pasa si
además necesitamos realizar un depósito en efectivo?, en ese caso
el modelo cambia un poco y entran otras entidades y procesos a
jugar.
Página 31 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Datos, comportamiento y relaciones
de los objetos.
Durante el transcurso de este curso, aprenderemos un hermoso
camino, que comienza con la necesidad de un cliente y que
termina con una solución para él, producto de un esfuerzo en
conjunto, una buena planificación y un conjunto de reuniones en el
que nos sentaremos a entender el problema de nuestro cliente,
ayudarlo y asesorarlo en lo que encontremos que no está bien.
Página 32 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Todo este proceso lo iremos documentando aplicando un conjunto
de técnicas que veremos más adelante, sin embargo antes de
entrar en aspectos técnicos deberemos conocer algunos conceptos
básicos y realizar ciertos análisis simples, los cuales nos darán un
punto de inicio, con falencias y omisión de buenas prácticas, pero
que más adelante aprenderemos a corregir. Durante el desarrollo
de la asignatura realizaremos mucho análisis, sin embargo la
forma en que lo haremos no será al azar, aplicaremos una técnica
que ve todo como un objeto, muy similar a la forma en la que se
comporta el mundo real, el cual esta lleno de éstos, monitores,
papeles, botellas, cuentas, tarjetas de crédito, personas etc. Todo
durante esta asignatura será considerado un objeto, sin embargo
si queremos realizar un buen análisis sobre las situaciones que nos
rodean debemos comprender qué objetos participan en ello,
hagámoslo más simple y veámoslo a través de un ejemplo
haciendo un pequeño análisis de un partido de futbol. Como
podrás darte cuenta un partido de futbol no esta compuesto por
un solo objeto, es más, si observamos con detención podremos
concluir que existen muchos, enumeremos algunos:
1) 22 jugadores
2) Pelota
3) Marcador
4) arbitro
Si sumamos obtendremos que: 22 jugadores + una pelota + un
marcador + un arbitro dan un total de 25 objetos, si bien la suma
esta correcta, el análisis que debemos realizar durante esta
asignatura es más simple, ya que 22 jugadores es sólo la cantidad
Página 33 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
de veces que existe el objeto jugador en la cancha, pero en
realidad el objeto es el jugador, sólo podríamos determinar que
ellos son objetos distintos si existiese algo que los diferencie, por
ello nos bastará con determinar que existe un objeto jugador,
quedando nuestra lista simplificada de la siguiente forma:
Jugador
Pelota
Marcador
arbitro
Volviendo al tema de los 22 jugadores, podemos a decir que si
bien todos son un jugador y por ende el objeto es uno sólo, esto
no significa que los 22 jugadores sean iguales, muy por el
contrario, incluso el reglamento ordena que cada uno tenga un
número de camiseta distinto dentro de su mismo equipo, también
sabemos que cada uno tiene un nombre, un Rut, una posición etc.
Con este pequeño análisis podemos asegurar que todos los
objetos tienen ciertos datos asociados a ellos que permiten
identificarlos. Hagamos una lista con los datos que consideremos
son importantes para estos objetos:
Jugador
Dorsal (número de la camiseta)
Nombre
Posición
Goles anotados
Pases dados
Recuperaciones
Pie con que juega
Página 34 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Pelota
Marca
Marcador
Goles del local
Goles del visita
Arbitro
Nacionalidad
Ahora imaginemos a los jugadores, la pelota, el marcador y al
árbitro sobre la cancha sin moverse ¿eso sería realmente un
partido de futbol? sabemos que con sólo poner a todos los objetos
sobre la cancha no basta para llamar a eso un partido de futbol,
entendemos dada nuestra experiencia que los jugadores realizan
acciones y esto permitirá dar un dinamismo propio de un partido,
analicemos comportamientos de cada uno de estos objetos:
Jugador
Dar pase
Hacer gol
Recuperar el balón
Pelota
Rodar
Rebotar
Arbitro
Dar tarjeta amarilla
Página 35 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Dar tarjeta roja
Iniciar partido
Finalizar partido
Marcador
Incrementar en uno el gol de la visita
Incrementar en uno el gol del local
Como puedes ver todos los objetos tienen datos y algún
comportamiento (una acción) que pueden realizar, sin embargo
será posible que un jugador dé pases o haga goles si no existe una
pelota y un compañero a quien darlo, pues no, esto significa que
los objetos por si solos no representan un sistema y para que
pueda llevarse a cabo el objetivo es necesario que se asocien
entre ellos, algunas interacciones relevantes en un partido de
futbol son:
Partido se asocia con Marcador
Partido se asocia con arbitro
Página 36 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Partido se asocia con equipo
Equipo se asocia con jugador
Jugador se asocia con pelota
Al igual como lo hemos realizado ahora, siempre reconocer los
objetos, conocer las acciones que pueden realizar y con quién se
asocian nos servirá como un buen comienzo para realizar un buen
análisis posterior.
Definición de UML
UML, cuya sigla significa lenguaje unificado de modelado, es un
lenguaje visual (basado en diagramas), que nos sirve para
visualizar y documentar el software que deseamos construir y
colaborar con la documentación de todo el conocimiento de los
sistemas que deseamos construir, existen en UML distintos tipos
de diagramas, el objetivo de cada uno de ellos es presentar de
distintos puntos de vista una parte de un sistema, esto quiere
decir que por ejemplo una misma situación puede ser diagramada
(dibujada) varias veces y con más de un tipo de diagrama, donde
cada uno de ellos nos entrega un enfoque de la misma situación
pero resaltando factores como el tiempo o el orden en el que
ocurren, sin embargo uno de los mayores beneficios es
proporcionar a todas las partes integrantes del equipo un lenguaje
común, UML consta de una semántica y un conjunto de notaciones
que hacen que todos leamos y entendamos lo mismo de un
diagrama UML.
UML nos permite representar un sistema desde el punto de vista
estático y dinámico, el punto de vista estático nos muestra los
Página 37 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
elementos y como ellos se relacionan para en su conjunto dar
como resultado con éxito la implementación del sistema que se
desea construir. La vista dinámica en cambio modela el
comportamiento de alguna parte del software en algún momento
del futuro, con ello podremos aclarar más las ideas y lo que
deseamos lograr, detectar y corregir errores antes de que sea
demasiado tarde.
Etapas del ciclo de vida utilizando
RUP (Rational Unified Process)
Un ciclo de vida en el desarrollo de software se entiende como un
conjunto de etapas que se definen para poder realizar una tarea,
en el caso de la orientación a objetos, es muy común utilizar una
metodología llamada RUP (Rational Unified Process), que fue
desarrollada por la empresa Rational, hoy parte de IBM.
El ciclo de vida es una implementación del modelo en espiral. Se
desarrolló pensando en el ensamble de elementos de un contexto
determinado pasando por una secuencia de pasos semi ordenados.
La ventaja de RUP es que la estructura puede ser personalizada
según las necesidades específicas del proyecto (de ahí lo de semi
ordenadas). El ciclo de vida RUP organiza las tareas en fases e
iteraciones.
Fase de inicio
Fase de elaboración
Fase de construcción
Fase de transición
Página 38 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Cada parte se termina con un hito bien definido, es decir un
momento en el tiempo en que se deben tomar decisiones
importantes, y en al cual ciertas metas ya deberían haber sido
alcanzadas.
La fase de inicio: en esta fase se deben definir algunas
características del proyecto a emprender (proyecto de tecnologías
de información) como el contexto del negocio6, los factores de
éxito (expectativas que se quieren lograr) y tratar de definir los
tiempos y los costos (aproximados). Lo que necesitas definir en
esta etapa es si tu y tu contraparte entienden a cabalidad el
sistema. Por ejemplo debes tener presente que el proyecto esté
alineado con los planes de la organización, que se haya
considerado en el presupuesto y que sea posible al final del
proyecto comparar los requisitos establecidos de forma inicial con
el proyecto entregado.
La fase de elaboración: el propósito de la fase de elaboración es
analizar el dominio del problema, establecer las bases de la
tecnología a utilizar en el proyecto (hardware y software),
desarrollar el plan del proyecto y eliminar los riesgos más altos del
proyecto. Las decisiones respecto de la arquitectura deberán ser
tomadas considerando una vista amplia y lo más completa del
ámbito, funciones principales y requerimientos de rendimiento. La
fase de elaboración es dónde el proyecto comienza a tomar forma.
6 Se entiende por contexto del negocio al contexto del problema a analizar, se trata de una actividad cualquiera que no
necesariamente tiene lucro de por medio.
Página 39 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
En esta fase se hace el análisis del dominio del problema y los
proyectos de arquitectura comienzan a tomar forma.
Las salidas para esta fase son:
Un modelo de casos de uso (que veremos más adelante)
Captura adicional de requerimientos funcionales y no
funcionales y de cualquier requerimiento que no esté asociado con
un caso de uso específico
La descripción de la arquitectura del proyecto (hardware y
software)
Una lista revisada de los riesgos
Una planificación de la construcción completa del proyecto,
incluyendo la planificación de las subtareas o subproyectos que
vayas encontrando en cada iteración.
Una especificación de los casos especificando los procesos a
realizar
La fase de construcción: durante la fase de construcción, todos
los componentes y aplicaciones restantes son desarrolladas e
integradas al producto, y todas las características de
funcionamiento son testeadas de forma exhaustiva. La fase de
construcción es un proceso de manufactura dónde el énfasis está
puesto en el manejo de los recursos y el control de las operaciones
para optimizar los costos, el calendario planificado y la calidad. En
esta fase se realiza la construcción de código y la configuración de
la plataforma de hardware y software. En proyectos muy grandes,
se deben realizar muchas iteraciones de construcción en un
esfuerzo por dividir los casos de uso en partes que se puedan
transformar en prototipos demostrables y construibles.
Página 40 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Las salidas de la fase de construcción son una serie de productos
que están listos para ser utilizados por el usuario final, como
mínimo, están compuestos por:
Una aplicación de software integrada en una plataforma de
servicios y hardware adecuado.
Los manuales de usuario
Una descripción de la versión actual.
La fase de transición: el propósito de la fase de transición es el
transmitir el producto a los usuarios de la comunidad. Una vez que
el producto ha sido entregado al usuario final, siempre van a
existir algunos problemas que van a obligar al desarrollo de
nuevos proyectos o a la corrección de parte de ellos. La fase de
transición comienza cuando se ha alcanzado una cierta madurez de
los productos a entregar como para que estos sean probados por
los usuarios finales (aunque no estén completamente terminados).
También es necesario que la documentación para los usuarios esté
disponible para que estos puedan probar la funcionalidad y
retroalimentar el proceso. Algunas tareas que es necesario
realizar:
Usuarios de prueba, para validar el sistema con las experiencias
del usuario.
Operaciones en paralelo entre el sistema antiguo y el nuevo.
Conversión a las bases de datos operacionales.
Entrenamiento de los usuarios y la gente de soporte.
Si todos los objetivos se cumplen, el punto de entrega final del
proyecto se alcanza y el ciclo de desarrollo del proyecto termina.
Página 41 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Diagramas de Estructura.
Diagrama de clases
En el paradigma de programación orientada a objeto (POO) todos
los componentes de un software son llamados objetos, por
ejemplo, en un software que registra las notas de un curso algunos
objetos serán, el objeto nota, el curso, el alumno y la asignatura,
no te sientas mal por que se haya tratado al alumno como un
objeto, pero en orientación a objeto todo lo construido en un
software recibe esa denominación, cada uno de estos objetos tiene
un conjunto de características (atributos), estados y
comportamientos que debemos conocer con anticipación antes de
construir el software, con el fin de no cometer errores, de esta
forma lo más adecuado es generar un plano, que indique qué
atributos, estados y comportamientos tienen cada uno (acciones
que realizan), a este plano es el que en informática conocemos
como clase, donde tendremos que crear una clase para cada
objeto que deseamos construir, al conjunto de todas las clases se
le denomina diagrama de clases.
Una vez todas las clases han sido construidas debemos proseguir
con el paso número dos, el cual identificamos las asociaciones que
existen entre ellos, por ejemplo, en el ejemplo anterior una
asignatura puede contener de cero a muchos cursos (o secciones)
y cada curso puede tener entre 15 (el mínimo) y hasta 34 (el
máximo) alumnos, a su vez un alumno puede tener desde 3 a 8
notas, de aquí se desprenden dos conceptos, el primero llamado
asociación que es la vinculación de dos o más clases y la
multiplicidad, que dice con cuantos objetos se asociará.
Página 42 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
El diagrama de clases por tanto se construye antes de construir el
software y es un plano de todo lo que deseamos construir. En él
van las clases que va a contener tu software y sus asociaciones,
además podemos decir que es una forma normada de representar
un software, de esta forma todos hablamos el mismo idioma y
conocemos a priori lo que debemos construir, evitando así errores
o interpretaciones por parte del equipo de programadores.
El diagrama de clases sea probablemente uno de los diagramas en
UML más utilizados y sirve para representar las relaciones
estáticas que existen entre las clases que lo componen,
aclaramos qué significa esto, cuando tenemos una clase llamada
auto que tiene los atributos de color, velocidad, marca y modelo,
un estado (encendido o apagado) y algunos comportamientos
como acelerar, frenar, encender, etc., estamos diciendo que a
partir de esta clase vamos a construir un vehículo, pero no lo
hemos realizado aún, sólo definimos en un plano (clase) llamado
auto, las características y acciones que debemos construir, cuando
asociamos está clase a una clase llamada rueda podemos decir que
se asocian y que su multiplicidad es de 0 a 4, debido a que un
vehículo eventualmente podría no tener ruedas, Sin embargo,
ninguno de los dos objetos existe aún, vale decir que no hay
ningún auto ni tampoco ruedas, es por esto que la relación es
considerada estática, más adelante veremos que una vez
construido el objeto auto éste podrá tener una rueda, dos o todas
si se las instalan y es en este momento en que la relación se
vuelve realidad, pero fue posible sólo debido a que nuestro
diagrama de clases nos guío para que pudiésemos construir un
objeto con la capacidad de poder contener entre 0 y 4 ruedas.
Página 43 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
En UML una clase es representada por un rectángulo que se
encuentra sub dividido en 3 rectángulos, el primero de arriba debe
ir el nombre de la clase, el cual debe representar el objeto que se
construye a partir de esta clase, en el segundo espacio va una lista
con todos los atributos o características que deseas tenga tu
objeto y en el último una lista con todos los comportamientos que
tu futuro objeto podrá realizar.
Veámoslo con un ejemplo, supongamos que deseas construir un
automóvil, el primer paso es definir cuáles son los atributos, los
comportamientos y estados que tiene un auto, para que los
agrupemos de forma tal que generemos una clase llamada
vehículo, entonces procedemos a ubicar el nombre de la clase en
el primer rectángulo utilizando la primera letra con mayúsculas.
¡Felicitaciones!, en el segundo espacio ubicaremos todos los
atributos que deseamos tenga nuestro objeto, debes tener cuidado
aquí y ser selectivo con los atributos que deseas incluir en tu clase,
si miramos un vehículo es probable que encontremos una gran
Página 44 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
cantidad de ellos, pero según para que queramos el auto sólo
serán útiles algunos, por ejemplo, si lo que deseas es utilizar el
vehículo como parte de una carrera de autos, tal vez sólo nos
baste con el nombre del piloto, el modelo del auto, su categoría,
número (único en cada carrera) y la cantidad de vueltas que lleva.
El tercer rectángulo debe contener todos los comportamientos
(acciones) que realizará el objeto que construirás a partir de esta
clase, al igual que en el caso anterior, las acciones que pueden
realizarse con un auto son más de las que necesitamos para este
caso, es por eso que sólo seleccionaremos algunas, las cuales
pueden ser: dar vuelta, pasar a Pitt, acelerar y frenar.
Página 45 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
¡Listo! hemos diagramado como será nuestra clase vehículo, la que
construiremos más adelante utilizando algún lenguaje de
programación, la cual podremos utilizar para construir todos los
vehículos necesitemos.
Asociaciones.
Un diagrama se dice que presenta las relaciones estáticas entre las
clases con el fin de establecer qué clases se relacionarán y cual
será su multiplicidad, en el caso anterior por ejemplo, el vehículo
no es lo único que debemos considerar para que podamos decir
que construimos un software que permita gestionar una carrera,
así también tendremos que crear la clase pista con sus respectivos
atributos y comportamientos siguiendo la misma técnica anterior,
pero si construyo ambos objetos a partir de estas clases ¿servirían
por separado?, pues no si lo queremos realizar es una carrera, es
Página 46 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
por eso que debemos especificar una asociación entre ellas, de
forma tal que cuando se construyan estos objetos también esté
definida las asociaciones entre ellas, evitando así errores en la
construcción, por ejemplo, para este caso es natural que la pista
este asociada a los vehículos, para ello en el diagrama es
necesario unirlas a ambas con una línea para representar esta
asociación.
De esta forma sabemos que el vehículo esta asociado a la pista,
pero aún nos queda determinar quien esta asociado con quien, ya
que la línea no lo explica por si sola, pudiendo alguien pensar que
un vehículo esta asociado a 3 pistas, lo que, al menos en lo que
nosotros deseamos representar ahora no es correcto.
Página 47 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Multiplicidad.
Uno a uno: esta relación se da cuando dos instancias de una clase
tiene una asociación de uno es a uno en ambos sentidos, un buen
ejemplo es el matrimonio, en el que un hombre se asocia a una
sola mujer y una mujer a un solo hombre, variables como el
divorcio, no interfieren con este ejemplo, debes tener presente que
un diagrama de clases es una foto de un momento, no de lo que
puede hacer un hombre o mujer a lo largo de su vida.
Uno a muchos: Esta relación se da cuando un objeto esta
asociado a más de un objeto de otro tipo, un buen ejemplo es que
una madre puede tener más uno o varios hijos.
Página 48 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Uno a una cantidad limitada de elementos: esta relación se da
cuando un objeto puede estar asociada con una cantidad limite de
otros elementos, cuyo limite puede encontrarse en el número
mínimo o máximo, por ejemplo un curso para formarse necesita un
mínimo de 15 alumnos, pero puede tener como máximo 34,
también es posible que un objeto pueda asociarse con un mínimo
de cero, en este caso se define que podría no existir una
asociación si lo requiere, por ejemplo, si tratas de lanzarte en una
carrera presidencial necesitarás un mínimo de firmas que avalen tu
candidatura, este proceso de recolección es una asociación de cero
a muchos, ya que podrías no conseguir votos como podrías tener
millones.
Mucho es a Muchos: Representa una asociación donde un objeto
se asocia de uno a es a mucho en cualquier dirección, por ejemplo,
un alumno tiene muchas asignaturas y una asignatura tiene
muchos alumnos.
Página 49 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Diagrama de objeto
Los diagramas de objetos son similares en su anotación al de
diagrama de clases y son un complemento que se utiliza para
enfatizar la relación que existe entre dos instancias de clases en un
momento específico de tiempo, la diferencia de este diagrama es
que no se presenta como una relación estática con su respectiva
multiplicidad, a cambio, muestra cómo un objeto se relaciona con
otros objetos luego de haberse construido, es decir un ejemplo de
cómo se verá en el futuro en algún instante de su vida, ¿recuerdas
el ejemplo del vehículo y su relación estática con una posible
cantidad de cero a cuatro ruedas?, podríamos realizar un ejemplo
de la relación con sus ruedas, pero para eso debemos tener
objetos de tipo vehículo y algunas ruedas, así que el primer paso
será construir un objeto de tipo vehículo según lo que definimos en
nuestra clase, por si no lo recuerdas en ella especificamos que un
vehículo tendría un color, una marca y un modelo, no te preocupes
si no sabes como armar un auto por que no lo vas a necesitar, en
informática un objeto es sólo una agrupación de información y
acciones que se pueden realizar con ella, debido a esto se
considera un objeto a una agrupación de valores dados a cada una
de los atributos definidos en el diagrama de clases, por ejemplo si
construimos un objeto auto de tipo vehículo bastará con darle un
nombre, el cual podría ser miObjetoAuto, un valor para el atributo
color, que te parece rojo, una marca, le pondremos Ford, al
modelo Mustang, y a la velocidad cero. Cuando nuestro objeto
ya esta construido es cuando las acciones que pueden realizar
toman sentido, por ejemplo si utilizas el comportamiento encender
Página 50 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
el estado del vehículo pasará de apagado a encendido y si aceleras
un cálculo matemático hará que la velocidad avance de cero a uno,
como puedes darte cuenta la construcción de un objeto pasa por
dar valores a sus atributos y al igual que las clases, los objetos
también se pueden representar de la siguiente forma:
En lo más alto del rectángulo está el nombre del objeto y separado
por dos puntos el tipo de objeto que es, en la parte inferior van los
atributos y los valores que tienen, así como este puedes crear
todos los objetos que desees, incluso otro con iguales valores en
sus atributos, la única regla es no repetir el nombre del objeto,
vale decir que el próximo objeto no podrá llamarse miObjetoAuto.
Esta representación es un ejemplo que ayuda a los programadores
a entender mejor cómo se debe comportarán los objetos cuando
sean construidos. También se dijo que un vehículo puede tener de
cero a cuatro ruedas y así está especificado en el diagrama de
clases, pero en el diagrama de objetos es cuando puedes mostrar
un ejemplo de cómo esa relación luce en algún momento de la
vida de tu auto, habrá ocasiones en la que el vehículo tendrá todas
las ruedas y otras ocasiones en las que tendrá 3 o menos. Así
Página 51 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
puedes dibujar un diagrama para cada situación que consideres
vale la pena aclarar, el siguiente ejemplo muestra un vehículo
asociado a una sola rueda, la cual proviene de una clase llamada
Rueda que define que para cada rueda se debe especificar su
marca y el aro de llanta para la cual esta hecha.
Página 52 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Diagrama de estructuras compuestas.
La relación de asociación entre clases se da muy a menudo en un
diagrama de clases, sin embargo este diagrama no permite
presentar el contexto en la que la relación deberá efectuarse. Para
que sea más clara, este caso es principalmente dado en la relación
de composición. Para que podamos comprender bien cómo
funciona, vamos primero a aclarar qué es la composición en el
diseño orientado a objetos: si miras a tu alrededor podrás ver que
hay muchos objetos que se asocian con otros para realizar una
actividad, como lo son el chofer y su auto o el ascensor y el
edificio, sin embargo, es posible tener un auto sin chofer o un
ascensor sin edificio, por ello en ambos casos la relación es de 0 a
N, vale decir que puede no tener como también podría tener
varios, pero hay casos en la que dos objetos dependen uno del
otro para formar un todo, si pensamos en el vehículo notaremos
que está compuesto por carrocería, motor y ruedas entre otros, o
dicho de otra forma podemos decir que se encuentran asociados
(tienen relación), pero esta relación en particular no es una
relación de asociación, dado que si bien el motor existe sin las
ruedas o viceversa, el auto no puede existir sin motor ni
carrocería, esto es debido a que el vehículo esta compuesto de
ellas, entonces, cuando hacemos un diagrama de clases podemos
especificar que dicho vehículo se asocia con un motor y que el
motor moverá cuatro ruedas, pero para los que no conocen bien el
funcionamiento del auto podría ser difícil determinar que de las
cuatro ruedas dos son las de adelante y dos las de atrás, dada esta
dificultad, el diagrama de estructuras compuestas nos permite
representar esta situación con un ejemplo, que representa algún
Página 53 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
momento de la vida del objeto cuando se esté llevando a cabo la
composición.
Abordemos con más profundidad el ejemplo del vehículo para que
veas como el diagrama ayuda a presentar información del
funcionamiento interno que a simple vista no es posible apreciar,
si en nuestro diagrama de clases, decimos que un auto tiene una
relación con un mínimo y máximo de un motor, esto quiere decir
debe tener uno de forma obligatoria y una relación de cero a
cuatro rueda a menos que desees construir el troncomovil de
Pedro Picapiedra. A pesar de que la información parece clara y
completa, si analizamos más a fondo la información que se nos ha
entregado comenzarán a salir dudas, por ejemplo, ¿qué hace el
motor con las ruedas?, ¿es el encargado de moverlas?, ¿si fuese el
motor, debe mover las cuatros al mismo tiempo, sólo las de
adelante o sólo las de atrás?, ¿o es un vehículo extraño que puede
mover las dos ruedas de un mismo lado? Con el diagrama de
estructuras estas dudas son aclaradas, presentan como un dibujo
un ejemplo del auto ya construido, es decir, posterior a llevar la
clase a un objeto, en él se dibujan las partes que le componen y
qué tipo de vinculación tiene las partes, cuáles se asocian con cuál
y con cuántas, así podríamos dibujar de forma clara que un auto
tiene una parte llamada motor y cuatro ruedas, pero dos de ellas
son las traseras y dos las delanteras y que es el motor el
encargado de mover las delanteras. (Esto cambiará dependiendo
del tipo tracción que tenga el vehículo).
Veamos un ejemplo de cómo será este diagrama:
Página 54 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Diagramas de componentes.
El diagrama de componentes es un diagrama de alto nivel de
abstracción, en él van modelados todos los componentes
(elementos) que componen un software. En él vamos a
representar los componentes que van incluidos pero no funcionan,
sin embargo si debemos especificar cuáles se comunicarán entre
sí, tal vez la palabra componente sea algo que aún no te haga
mucho sentido, pero para explicarlo de otra forma, un componente
es una pieza de software, es muy similar como cuando armas un
puzzle, imagínate con un nuevo puzzle en la mano recién
comprado y llegas con él a casa para comenzar a armarlo, lo
primero que notarás es que no viene armado donde sólo podrás
Página 55 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
ver piezas sueltas que parecen no tener una conexión entre sí, sin
embargo en la mayoría de los puzzles en la tapa de la caja traen
una vista del puzzle armado ¿podrías armarlo sin eso?
Probablemente no y el puzzle al igual que el software muchas
veces se construye de la misma forma, por piezas, y alguien debe
encargarse de realizar un diagrama que muestre cómo deben
ensamblarse, también notarás que cada pieza del puzzle esta
diseñada para comunicarse con alguna otra pieza, a esto en
informática le llamamos interfaces, la cual expone una forma de
comunicación con otros componentes, entonces un software esta
compuesto por varias piezas llamadas componentes y cada una de
ellas tiene una o mas interfaces para comunicarse con otras, sin
embargo el software tiene una ventaja por sobre la pieza del
puzzle, ya que, en el caso del puzzle cada pieza sirve sólo para
ensamblarse con una pieza en particular, en el software en cambio
las interfaces expuestas sirven para conectarse con más de un
componente, creando piezas que permitirán tener más de un uso.
Un componente de software es una pieza que representa un
conjunto de funcionalidades que dependerán del tipo de software
va a realizar, por ejemplo, si pensamos en un software que va a
permitir que los usuarios utilicen una página web, en la cual
pueden chatear luego de registrarse y cumplir con ciertas
condiciones, los componentes serían los siguientes:
Componente de negocio: un componente encargado de aplicar
cálculos matemáticos o de verificación de formato de datos para
saber si un usuario cumple con los requisitos que le pide el
software para poder registrarse, por ejemplo, si es mayor de edad,
si escribió su número de celular respetando el formato solicitado.
Página 56 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Componente de páginas Web: el cual representará un conjunto
de páginas web con las que el usuario va a interactuar.
Componente de chat: el cual va a representar un software más
pequeño (conjunto de clases) que permitirá a los usuarios
comunicarse entre si en tiempo real.
El siguiente dibujo muestra cómo debe representarse un
componente.
Para que un componente pueda comunicarse con otro componente
debe tener lo que se conoce como interfaces, una interfaz es un
punto de entrada para que otros componentes puedan obtener del
él el servicio que presta, un buen ejemplo es un componente que
valida el Rut, es posible que si deseas registrarte en una página
Web y entre los datos que solicitas está el Rut, es muy probable
que desees que el Rut sea válido, para llevar a cabo esto el
componente de negocio tendrá entonces una interfaz que permita
recibir el Rut para luego informar si esta correcto o no, este
componente a través de dicha interfaz, podría reutilizarse en todos
los software que requieran validar el Rut, de esta forma tenemos
un componente de software que a diferencia de la pieza del
Página 57 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
puzzle podemos volver a utilizar en cada software en el que se
necesite.
Una interfaz se representa de la siguiente forma:
Diagrama de despliegue.
El diagrama de despliegue es un diagrama que permite mostrar la
relación física que tendrán los componentes de software y
hardware de un sistema, la mayoría de los programas de hoy
están distribuidos en más de un computador, un buen ejemplo es
el Windows Live Messenger o Gtalk, estos software presentan ante
el usuario una ventana para que éstos puedan escribir un mensaje
y enviarlo a otros usuarios, pero ¿has pensado que sucede al
presionar el botón enviar?, pues al hacerlo los datos son tomados
y son enviados a otra aplicación, la cual posiblemente esté incluso
en otro país, este software es el encargado por medio de una
interfaz de recibir tu mensaje, ubicar al destinatario y enviárselo
para que lo pueda leer. Como puedes ver la aplicación que instalas
en tu computador de poco serviría sin la otra, la cual es la que
hace posible que cientos de miles de personas se comuniquen, ese
equipo que presta el servicio de comunicar se le denomina
Página 58 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
servidor, nombre que se le puede aplicar a todo equipo que
preste algún servicio, así como este ejemplo existen muchos, que
incluso tienen componentes en más de dos equipos. Cuando se da
este tipo de casos el diagrama de despliegue nos sirve para ubicar
en que Hardware (en que equipo físico) debe ir cada componente
para que los encargados de instalar el software sepan como
hacerlo, por supuesto esto no es una receta de cocina, también
hay miles de otros software donde todos sus componentes van en
el mismo lugar, en dicho caso el diagrama de despliegue será
mucho menos necesario.
Un ejemplo del caso mencionado lucirá así:
Cada uno de los cuadrados dibujados con profundidad son
denominados nodos y representan un equipo donde se realizará la
instalación, por ejemplo el software de chat esta instalado en el
cliente y el segundo componente, el cual se encarga de reunir a
todos los componentes de chat para que puedan comunicarse esta
en el equipo denominado servidor.
Página 59 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Diagrama de paquete.
El diagrama de paquete sirve para formar una mejor visión de qué
queremos construir, para ello lo divide en subsistemas más
pequeños, la agrupación de los elementos se define en función de
algo que ellos tengan en común y que los identifique como grupo,
para luego mediante flechas representar la dependencia que existe
entre ellos, es decir los elementos de un grupo que dependen de
otro que se encuentran en un grupo distinto, esto se hace para dar
orden y claridad en el diagrama, de esta forma evitamos tener
ciclos dentro de nuestra estructura, ¿conoces el dilema de si es
primero la gallina o el huevo?, pues casos similares a estos
también se dan en el software, la dependencia es un tema que hay
que tomar muy en serio a la hora de construir un programa, un
error de dependencia de software sería el equivalente a tratar de
hacer una vela en una caverna sin luz, donde para realizarla
necesitas luz, pero para generar luz necesitas la vela, como
puedes ver hay una dependencia mutua que hace imposible que
podamos generar la luz necesaria, en el software esto también se
da: imaginemos que estamos en un lugar donde arriendan internet
y en cada equipo hay una aplicación que bloquea el teclado cuando
recibe la orden desde el computador del encargado del lugar,
adicionalmente para que los usuarios no puedan engañar al
sistema y piensen en apagar y encender el equipo el software para
iniciar tiene un componente que busca en la red si el equipo del
operario esta activo para regular el uso, de no ser así el sistema no
permite usar el equipo y lo apaga, por otra parte el sistema del
operario tiene un componente que se encarga de verificar cuáles
computadores están funcionado en la red para que puedan ser
gestionados, pero si no encuentra ninguno la aplicación se cierra.
Página 60 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Cuando llegue la noche y apagues todos los Pcs, al día siguiente no
podrás volver a usar el sistema, dado que el software del operario
espera a los clientes y el software que está en los clientes espera
al operario.
El error de lógica anterior que refleja una dependencia de
componentes puede ser aún peor dentro de la construcción del
software, dado que mientras desarrollas un programa puedes
cometer también un error de dependencia, es decir, puede verse
afectado por esto incluso mucho antes de que el programa
concluya, ¿Cómo es esto posible? Muy sencillo, imagina que dentro
de tu software para crear un archivo utilizas el componente
llamado “creador de archivos” y este a su vez mediante su interfaz
espera un componente llamado “leerDisco” el cual verifica que el
espacio sea suficiente en el disco, el problema es que la
información del disco en el que se quiere guardar el archivo va en
el componente “creador de archivos”, el cual para iniciarse
requiere que mediante su interfaz el componente leer disco le
entregue la información necesaria para escribir el archivo, en este
caso el software nunca podrá instalarse, dado que hay dos
componentes que están iterativamente esperando al otro para
poder iniciarse.
De esta forma el diagrama de paquetes permite ver de forma
agrupada en paquetes los elementos que componen el software,
uniendo los paquetes con líneas discontinuas entre aquellos que
exista dependencia de algún tipo.
Página 61 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Diagramas de comportamiento.
Diagrama de casos de uso.
Este tipo de diagramas es esencialmente útil durante la etapa de
análisis, es decir cuando estas comenzado a entender lo que
necesita construir tu cliente, ya que su finalidad es describir los
actores que interactúan con el software y los procesos que deben
realizar. Un actor se considera a cualquier elemento que interactúa
con tu programa, que pueden ir desde otros software, un robot o
humanos, el caso de uso se refiere a todas las acciones que tu
software realizará, por ejemplo si estas considerando realizar un
software que simule una agenda entonces tendrás un solo actor,
(el encargado de agregar información a la agenda) y los procesos
o casos de uso que realizará serán, agregar un contacto, agregar
una actividad a realizar, ver las actividades pendientes, verificar
los datos de un contacto previamente agregado, etc. De todas
estas acciones no es necesario tener con toda claridad toda la
Página 62 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
lógica que hay tras el proceso, la idea principal es sólo identificar
los procesos y quién es el encargado de realizarlos. Este tipo de
diagramas es muy útil para apoyar el proceso de análisis con tu
cliente sobre lo que deseas que haga el software, debes considerar
lo difícil que es para ellos explicar sus necesidades de programa y
más aún todos los procesos que ellos mismos quieren realizar,
donde olvidar alguno podría ser catastrófico, para el software, para
tu cliente y para ti, ya que terminará agregándolo al final,
trabajando más de lo pactado y potencialmente atrasando la
entrega. Es posible pensar que si se ha olvidado de algo la
responsabilidad sea del cliente, en parte sí, pero también debes
recordar que tú eres el experto y si notas que la ausencia de un
proceso generará un problema en el software es parte de tu
trabajo advertirlo. Todos los procesos que deseen incluirse
posteriormente deben ser pactados como un nuevo requerimiento,
lo cual tendrá un nuevo costo para el cliente.
Un actor en un sistema es representado con un dibujo de persona
con cuerpo de palito, el siguiente ejemplo representa un actor y su
respectivo rol en el software.
Actor1
Página 63 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Un actor es el encargado de ingresar información al software, es él
quien a través de las interfases que tiene el sofware agrega la
información que se desea almacenar y procesar, también es quien
recibe la información procesada en el momento en que lo requiera.
Un caso de uso, por otro lado, permite mostrar la forma en que el
sistema presenta sus procesos para que sean usados por los
distintos usuarios que interactúan con el.
El siguiente ejemplo muestra cómo un actor interactúa con la
agenda, especificando que el actor realiza una acción llamada
agregar contacto.
Según los requerimientos que desees modelar, puedes agregar
más procesos dentro del mismo diagrama o dibujarlos por
separado según lo necesites, agregando todos los procesos que
requieras que se encuentren asociados a un mismo actor o bien
agregando un segundo actor y todos sus procesos.
Agregar Contacto
Buscar contactoActor1
Página 64 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Diagrama de máquina de estados.
Este diagrama muestra los estados por los que pasa un único
objeto en respuesta a los eventos que este efectúa.
Para que lo entendamos mejor primero veamos lo relativo a los
estados, un estado es una condición en la que se encuentra un
objeto en un determinado momento de su vida, esto sucede en
cualquier orden de cosa, a tu alrededor podrás encontrar muchos
ejemplos, tu mismo tienes varios estados: alegre, triste,
concentrado, etc. Sin embargo para que estos eventos vayan
cambiando debe suceder “algo” para que tu estado cambie. Por
ejemplo, si hoy por la tarde llegas a casa y descubres que eres el
único ganador de un millonario premio, seguramente tu estado
pasará a “ultra feliz al borde del colapso nervioso”, sin embargo
para que esto ocurra ha tenido que suceder lo que denominamos
un evento, en este caso particular al evento le podríamos llamar
“ganar la lotería”, al igual que en este ejemplo, en el software los
objetos que lo componen también pasan por eventos, los cuales
van cambiando su estado, un ejemplo sencillo puedes verlo en tu
navegador, cuando haces clic en el ícono por primera vez el estado
inicial de este es “a la espera” en la que el navegador no esta
haciendo otra cosa que esperando que hagas algo, cuando escribas
una dirección de internet y presiones el botón de búsqueda, habrás
generado un evento en él, el cual podríamos llamar “buscar” este
evento hará que el navegador pase del estado en el que se
encontraba a un nuevo estado que podríamos llamar “mostrando
página” en el que el navegador lee la información que le llega de
internet para mostrársela al usuario, así puedes identificar varios
Página 65 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
eventos que cambiarán el estado de tu navegador, por ejemplo si
haces clic en el botón para minimizar o maximizar.
Este diagrama presenta el estado inicial del objeto y va
representando con flechas acompañadas de un nombre el evento
que se ejerció sobre el objeto, para luego finalizar en un nuevo
estado, se puede ver un ejemplo en la siguiente figura:
En el diagrama de estados se debe definir un comienzo y un final,
de esta forma podremos saber cuál es el estado inicial y cuál es el
final.
Para especificar el estado inicial se utiliza el siguiente símbolo:
Y para el estado final se debe utilizar:
Quedando el diagrama completo de la siguiente forma:
Página 66 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Se podría pensar que en un diagrama de estados el estado inicial y
final podrán omitirse debido a que las flechas determina la
dirección en la que los estados van cambiando, sin embargo estos
no pueden omitirse debido a que un diagrama de estados no es
necesariamente lineal, por ejemplo, una persona podría pasar de
estar divorciado a casado si vuelve a contraer matrimonio, sin
embargo si vuelve a romper su relación volverá a estar divorciado,
este ejemplo es representado en la siguiente imagen:
De esta manera queda definido que nuestro objeto sin importar la
combinatoria que realice siempre finalizará casado.
Diagrama de actividad.
Este diagrama es muy similar al diagrama de máquinas de estado,
la diferencia principal es que en el diagrama de actividad no
muestra los estados de los objetos si no que modela cómputos y
flujos de trabajo, especificando el orden en el que se llevan a cabo,
además se asume que no existen interrupciones externas para
dichos flujos, de ser así será mejor modelar utilizando el diagrama
de maquina de estados visto previamente.
Página 67 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
En este diagrama se modelarán uno o más estados de actividad,
donde cada uno de ellos representa el funcionamiento de una
actividad que ocurre en un flujo de trabajo, para cada flujo es
necesario definir un inicio y de allí se da paso a la ejecución de la
primera actividad, cada una va iniciándose conforme va
terminando su actividad predecesora, lo que implica que es el
termino de una actividad dentro del flujo la que da inicio a otra,
este diagrama permite además modelar bifurcaciones dentro del
diagrama, de esta forma según el resultado de la actividad que se
ha ejecutado es posible tomar más de un camino, en otros casos y
según se requiera también es posible que dos actividades se
ejecuten de forma simultanea.
Veamos un ejemplo, supongamos que hoy vas al teatro, el proceso
es relativamente simple, vas, pagas, si gustas dejas tus datos para
futuras promociones y luego de cancelar se asigna un asiento para
ti. Para modelar este flujo representaremos en un diagrama de
actividades cada una de ellas como un cuadrado con los vértices
redondeados y en el centro el nombre de la actividad, también
utilizaremos una flecha que una las actividades para poder
modelar el orden en el que se ejecutan.
Por lo tanto cada uno de las actividades descritas deberá ir de la
siguiente forma:
Página 68 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
El orden en el que se ejecutarán son modelados con una flecha
que índice que orden del flujo del proceso.
Si el término de una actividad puede dar inicio a más de una
actividad dependiendo de alguna condición la bifurcación que allí
se produce se representa con un rombo:
Diagramas de Interacción.
Diagrama de secuencias.
El diagrama de secuencia es un diagrama que muestra la forma en
la que interactúan los objetos dentro de un software agregando el
factor tiempo, de esta forma se puede visualizar el orden en el que
se ejecutan las llamadas en forma ordenada a partir de una
petición, la mayoría de las veces con un diagrama de caso de uso
es suficiente para comprender como interactúan las partes, sin
embargo hay algunos casos en los que el proceso puede ser más
complejo o requiera una explicación mayor, es por ello que el
diagrama de secuencias viene casi siempre a partir de un caso de
uso especifico.
Página 69 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Para representar los objetos en este diagrama UML utiliza
rectángulos con sus nombres subrayados.
La diferencia es que abajo del objeto agregaremos una línea
segmentada que simbolizará el tiempo de vida del objeto durante
el proceso que deseamos representar de la siguiente forma:
El paso se siguiente es dibujar las llamadas entre los objetos si es
que las hay, una llamada hará que un objeto realice alguna acción
que tarda algún tiempo, la cual al finalizar podrá realizar otra
llamada para ejecutar alguna tarea de otro objeto o de el mismo si
es necesario. Veamos con un ejemplo que representa la
interacción entre las personas de un restaurante, veremos como
interactúa el cliente, el mesero, el cocinero y el encargado de la
caja, a través de este ejemplo veremos el orden en el que
participa cada uno, también permite apreciar cuando una actividad
comienza y cuando otras terminan.
Página 70 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Como puedes ver en el diagrama, al seguir la línea de tiempo del
cliente verás que se une con el mesero con una línea (una
llamada) que simboliza el momento en el que se ordena la cena al
mesero, a partir de ese momento ambas líneas tienen un
rectángulo, lo cual significa que la llamada que hace la solicitud de
comida activa a ambos (cliente y mesero) por lo cual los dos
Página 71 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
generan una acción, cuando ambos se han puesto de acuerdo el
mesero solicita al cocinero que prepare el plato, a partir de ahí, el
cliente y el mesero quedan a la espera mientras el cocinero
prepara el plato, como el proceso de preparar el plato tarda
tiempo, el mesero aprovecha para servir la bebida al cliente, luego
la interacción entre el cliente y el mesero vuelve a quedar a la
espera, tiempo después el cocinero hace una llamada al mesero
(entrega), en el cual le entrega el alimento al mesero, cuando eso
sucede sólo el mesero comienza a tener actividad, el cual
corresponde al tiempo en el que el mesero prepara la bandeja y
lleva la comida al cliente, cuando ésta es entregada el mesero
queda en actividad, sin embargo el cliente queda con la
satisfactoria tarea de comer lo que ha solicitado y disfrutar un
momento de su familia, los cuales posiblemente estén celebrando
que su hijo ahora es estudiante de educación superior y que ahora
lee este manual, cuando finalizan de cenar pagan y así finaliza el
proceso.
Diagrama de tiempo.
Este diagrama permite mostrar el cambio de estado o valor de los
elementos a través del tiempo, prácticamente todos los objetos
durante su vida van cambiando sus valores o estados y muchas
veces estos cambios son producidos por factor que tiene relación
con el tiempo, antes de continuar es bueno aclarar que el estado
la mayoría de las veces también produce un cambio en el
valor del objeto, por ejemplo, si tienes un termómetro digital,
Página 72 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
que acompaña la temperatura con un mensaje que dice “mucho
calor” es por que el valor de los grados Celsius es mayor a 25,
cuando dicho valor baje a 18, el estado cambiará a “templado” .
Con este diagrama puedes mostrar los cambios de estado por los
que pasa un objeto a través del tiempo, un ejemplo sencillo es el
funcionamiento de una lavadora, ya que, las lavadoras
actualmente se encargan de pasar por varios procesos, determina
el peso de la ropa, llena el tambor con agua, lava, enjuaga y
centrifuga, este proceso por ejemplo esta definido en función del
tiempo, para diagramar esto, utilizaremos un grafico con
coordenadas X e Y, donde el eje X representa el tiempo e Y los
estados, así como muestra el siguiente figura:
Página 73 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Página 74 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Página 75 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Técnicas de recopilación y
análisis de requerimientos.
Técnicas de captura de
requerimientos.
Por lo general las personas que hacemos software nos encanta, es
un entretenido reto que se lleva en conjunto con un equipo de
trabajo, en el cual ponemos todo nuestro esfuerzo en construir un
software que utilice datos provenientes de nuestros clientes, los
procese para luego entregar información relevante para ellos, la
cual por lo general va agrupada y ordenada según ciertos criterios,
sin embargo muchos software tienen defectos y cuando digo esto
no me refiero en particular a que cada cierto rato muestren un
mensaje de error o produzcan una caída en el rendimiento de
nuestro equipo, sino que, muchos software que nacen de una
necesidad del cliente pero que no cumplen con lo que el cliente ha
solicitado, veamos el siguiente ejemplo para ilustrar el concepto,
supongamos que hoy te regalaré el auto de tus sueños y lo mejor
de todo es que el vehículo será como tu lo especifiques, como
muchos que lean este libro sus requerimientos serán mas o menos
así:
Llantas aro 17’.
Deportivo.
Motor muy poderoso.
De algún color que te guste.
Página 76 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Ahora supongamos que ha pasado algún tiempo, y he venido a
entregar el vehículo, aquel que esperas con muchas ansias y
medida que ves que lo van bajando del camión estas cada vez más
contento cuando descubres que tiene unas llantas preciosas, que el
color es tal y cual lo imaginaste, en la cola del vehículo pone un
numero que dice 3.5 haciendo referencia la cilindradas del motor,
al fin el auto esta en el suelo y el encargado de construirlo hace un
gestos de amabilidad para que te acerques a recoger tus llaves y
entres al vehículo, una vez adentro sin mirar más pones la llave,
haces contacto y escuchas como ruge el motor mientras te
imaginas la expresión de tus amigos cuando te vean en el, ha
llegado el momento, estiras las piernas para acelerar y descubres
que no hay pedales, pensando que a lo mejor es acelerador esta
en el manubrio comienzas a palpar la parte de atrás pero no
encuentras nada, a tu derecha notas la ausencia de una caja de
cambios, de aire acondicionado, de la tracción de las ruedas ni
hablar, apenas el motor esta conectado al sistema de arranque, no
hay tacómetro, no hay luces y así sigue, muy enojado bajas del
vehículo y encaras al encargado, el cual mira el documento en el
que especificaste lo que necesitabas, hace una revisión y te das
cuenta que todo lo que pediste esta ahí y que en realidad reclamas
por lo que no hay que jamás pediste, ¿Quién es el culpable? ¿El
mecánico? ¿Tú por no especificar bien lo que necesitas? Y la
respuesta es… ambos, el problema que aquí hubo es de
comunicación, a pesar de que da la sensación es que es más
culpable el mecánico es por que tu sabes los comportamientos que
un vehículo debiese tener, pero, ¿que pasa cuando tratamos de
construir algo que el cliente ni el constructor conocen? Aquí es
cuando el asunto se pone difícil, en el análisis de requerimientos
Página 77 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
esta situación se da mucho más habitual de lo que perece, la razón
de ello se debe a que la persona que debe construir el software
debe hacerlo de forma tal que se adecue a las necesidades de una
empresa que la cual no conoce sus procesos, pero por otra parte
el cliente conoce bien su empresa, pero jamás ha hecho software.
Mucho antes de siquiera pensar en como construir un software
encontraremos la etapa de captura de requerimientos, esta etapa
es de vital importancia para lo que viene luego, ya que, es durante
esta etapa en la que obtenemos los requerimientos (las
necesidades) desde nuestro cliente, en la que mediante
conversaciones, formularios, encuestas u otras formas obtenemos
la información sobre los procesos del negocio que desean el apoyo
de software, es muy común que se confundan la palabra requisito
y requerimiento, sin embargo en informática no debieses ser
utilizadas de forma indistinta, los requerimientos son la palabra
más común usada por las personas y viene de la necesidad de
algo, por lo tanto, la palabra correcta para definir las necesidades
que tiene tu clientes debe ser requerimiento, otra forma de
explicar lo mismo es la ubicar la captura de requerimiento en el
tiempo, con esto nos referimos a que en algún lugar existe una
persona con un problema o necesidad de mejora para la cual
necesita una solución que pasa principalmente por un conjunto de
herramientas informáticas que apoye uno o más de sus procesos,
cuando el profesional encargado de suplir esa necesidad se acerca
a conocer los procesos que la empresa realiza para las cuales
necesita un apoyo informático y lo que realmente la empresa
necesita de ellos para mejorar o solucionar una carencia estamos
hablando entonces de requerimientos.
Página 78 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Pressman dice “Ingeniería de Requerimientos ayuda a los
ingenieros de software a entender mejor el problema en cuya
solución trabajarán. Incluye el conjunto de tareas que conducen a
comprender cuál será el impacto del software sobre el negocio,
qué es lo que el cliente quiere y cómo interactuarán los usuarios
finales con el software”.
El proceso de toma de requerimiento, puede ser una tarea difícil y
que requiere trabajo y una habilidad para tratar y comprender a
las personas con las que se entrevista, muchas personas siempre
consideraron al informático como un ermitaño que vive frente a un
computador, pero se equivocan, por que son ellos los encargados
de extraer de sus clientes las necesidades que permiten el
desarrollo de una solución, por lo general durante la toma de
requerimientos descubrirás que los propios usuarios no saben lo
que quieren, adicional a lo anterior la tarea se vuelve algo mas
compleja debido a que los usuarios no tienen una visión como
conjunto, lo que provocará que escucharás versiones distintas de
una misma necesidad dependiendo a quien se entreviste, a lo
anterior, como si fuera poco, debes agregar que muchas veces los
requerimientos no son detallados correctamente, lo que suele
conducir a error y a incongruencias entre los clientes , es por esto,
el encargado de la toma de requerimiento debe tener una habilidad
que le permita mediar con ellos, ya que descubrirá con el tiempo
que una misma necesidad es vista de distintos puntos de vista
según a quien se entrevista y en muchos casos descubrirás que ni
ellos tienen claridad de lo que realmente desean.
Lo que debemos obtener de una buena toma de requerimientos es
enumerarlos, comprender el contexto en el que se encuentran.
Página 79 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Para lidiar con esto hoy aprenderemos algunas técnicas de
extracción de requerimientos desde el cliente, las cuales son:
entrevista, encuesta y observación directa, más adelante en
asignaturas posteriores verás metodologías más elaboradas sobre
la captura de requerimientos, las cuales consisten en un conjunto
de técnicas, sin embargo en este semestre veremos tres de las
formas mas naturales de comunicación existentes para extraer
información.
Entrevista.
La entrevista es posiblemente la forma más natural y rápida de
comunicación con una persona, en informática la entrevista debe ir
enfocada a aquellas personas que más conocen sobre los procesos
de la organización y a las personas que utilizarán el sistema, estas
entrevistas pueden ser individuales o grupales y se recomienda
hacerlas cada cierto tiempo, ya que verás que los requerimientos
van a ir cambiando producto de la falta de entendimiento que los
clientes suelen tener sobre sus propios procesos.
Encuesta.
Las encuestas son documentos que tienen un conjunto de
preguntas relevantes del sistema que se desea construir, de esta
forma podemos obtener información más precisa sobre los puntos
sobre los cuales necesitamos una respuesta cerrada, las preguntas
se hacen de forma verbal al encuestado, siendo el mismo
encargado de marcar la respuesta según lo que el encuestado
haya dado como respuestas, las encuestas puede llevar preguntas
abiertas o de selección múltiple, en la que los encuestados deberán
seleccionar una alternativa, esta técnica es buena cuando lo que
Página 80 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
deseas es obtener información puntual desde un grupo grande de
personas que no pueden reunirse ya sea por horario o por
limitaciones de espacio.
Observación directa.
Esta técnica consiste en que el encargado de la toma de
requerimientos observa las personas mientras realizan su trabajo,
de esta forma se conoce cuáles son los procedimientos que se
realizan, quiénes son los encargados de hacerlos y cuál es el orden
en el que se ejecuta.
Definición de actividades.
Una vez los requerimientos han sido extraídos del cliente
pasaremos a una nueva etapa en la cual tomaremos cada uno de
los procesos del cliente y lo dividiremos en actividades más
pequeñas, las cuales juntas y en algún orden en particular dan
como resultado alguna acción que deseamos convertir en software
más adelante, por ejemplo, si existe un proceso en el que los
clientes compran utilizando el método tradicional y esto lo quieres
llevar a un servicio de pago por internet, debes determinar todas
las actividades que hay que realizar para lograrlo, en este caso las
actividades a realizar comienzan por construir una página web con
un catalogo de productos donde el usuario pueda especificar el o
los productos que quiera comprar, luego una interfaz de pago que
permita ingresar el número de la tarjeta bancaria con la que se
desea realizar dicho pago, la información ingresada deberá
enviarse al banco que corresponde, sólo 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
Página 81 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
software y en ella incluye los datos del comprador y algunos datos
de la venta, como la fecha, el total y el detalle, el cual consiste en
una lista de los productos que compró.
Adicionalmente a lo anterior, para que un cliente pueda comprar
en una página web que permita navegar por los productos,
seleccionarlos y comprarlos, será necesario unos cuantos pasos
previos, ya que dichos productos deben ser agregados a la página
antes de que el cliente navegue por ellos, entonces, alguien debe
ingresar la información de los productos, subir sus fotos,
establecer el valor y agregarlos a la categoría que corresponde,
adicionalmente especificar algún tipo de descuento si lo hubiese.
Si hacemos un mejor análisis de la situación notarás que hace un
momento acordamos que cuando un cliente realiza una compra la
información que almacenaremos incluirá los datos del comprador,
es por ello que antes de la compra hay una actividad que
corresponde al registro del usuario, en la cual se almacenan los
datos del mismo.
Es muy probable que la necesidad de transformar en software este
flujo tenga principalmente dos objetivos, el primero, una mejora
en la forma en la que las personas obtienen los productos,
cambiando de la tradicional, en la que el cliente debía salir de su
hogar para adquirir los productos a una cómoda, rápida y ágil
forma de comprar sin salir de su hogar, la segunda razón es que al
tener la información de las ventas la organización podrá llevar de
mejor forma su contabilidad y podrá tomar mejores decisiones
basadas en los reportes que el sistema entregará, como por
ejemplo, los productos más vendidos, las fechas de mayor compra,
lo que alertará aquellas temporadas en las que hay que tener una
Página 82 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
mayor cantidad de stock de productos, estos informes se
generarán de forma automática por el sistema en respuesta a una
solicitud de quien los desee ver, todo esto a cambio de lo que
antes deben haber sido engorrosas planillas o largas sumas y
restas realizadas en papel.
A pesar de que pereciera que la lista de actividades para un portal
de ventas esta completa, más adelante con un mejor análisis
veremos que lo aquí descrito no es sólo una pequeña parte, que
por ahora obviaremos.
Relación entre las actividades y los
actores.
Del análisis anterior realizado se obtiene una lista de actividades
que pueden realizarse para llevar a cabo los procesos de la
empresa, el paso siguiente una vez identificados dichos procesos
es determinar las responsabilidades, o dicho de otra forma quién o
quiénes son los encargados de cada uno de ellos, a cada elemento
(usualmente personas) que interactúen con nuestro software lo
llamaremos un actor, por ejemplo y siguiendo con el caso anterior
la persona encargada de la compra a través de internet es el actor
llamado “cliente”, la carga de productos en el sistema será
realizada por el actor denominado “encargado de ventas” y los
reportes que permitirán tomar decisiones a una persona con un rol
más gerencial, con esto no sólo logamos identificar lo que los
actores deben hacer, sino que también lo que no deben hacer.
Página 83 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Análisis básico de los
requerimientos para la realización
de un listado de actividades.
En los procesos de análisis de requerimientos siempre se
determinan necesidades múltiples para las organizaciones que se
están estudiando. Es necesario por lo tanto que determines un
ámbito de acción para tu proyecto, y de esta forma dar una
solución acotada y precisa. Lo primero que debes tener en cuenta
es que las organizaciones siempre tienen una razón de ser y esta
razón de ser determina las actividades que la organización realiza.
Por un tema de complejidad de las organizaciones, poseen
diferentes procesos que dan soporte a la realización del quehacer
de la organización y adicionalmente otra serie de actividades que
si bien no son parte del quehacer de la organización, estas sirven
de soporte a estos procesos principales. Por ejemplo, el propósito
de la panadería es hacer y vender pan (proceso principal), pero
adicionalmente necesita realizar proceso tales como hacer aseo,
comprar materiales, contratar personal, etc. Como te puedes dar
cuenta existe una gran cantidad de operaciones que pueden ser
realizadas como soporte de las actividades principales, y mientras
más compleja sea la organización, más complejas serán las
actividades de soporte y más específicas.
Cuando estás analizando requerimientos, es importante que
puedas agrupar las actividades que estés analizando. Este
agrupamiento de actividades permitirá que analices los procesos y
las necesidades de la organización de forma mucho más eficiente
(aplicando la teoría de sistemas). Una vez que hayas agrupado los
Página 84 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
requerimientos en relación a su funcionalidad es necesario que
determines los grados de importancia de los requisitos
identificados. El grado de importancia esta asociado a los procesos
que realiza la organización como parte de su quehacer. Debes
considerar que para cualquier organización los requerimientos
principales a considerar son aquellos que tienen que ver con el
quehacer de la organización, es decir con los procesos que hacen
que la organización funcione.
Con todos estos antecedentes a la mano es posible ahora realizar
un listado de los principales requerimientos y ordenarlos en
función de las principales necesidades de la organización. Este
listado servirá entonces para realizar un listado de actividades que
deben ser realizadas para poder alcanzar los requerimientos. Este
listado de actividades te dará la pauta para poder definir las
actividades importantes en el desarrollo de tu proyecto, y en que
cosas debes fijar tu atención al momento de planificar y desarrollar
el proyecto.
Página 85 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Diagrama de flujo de datos (Agile
Unified Process).
Los diagramas de flujo de datos (DFD) fueron herramientas muy
utilizadas por la metodología estructurada como una forma de
representar los flujos de datos entre las entidades externas y el
sistema que se estaba analizando. Adicionalmente a este análisis
los DFD permiten mostrar el flujo de datos entre cada uno de los
procesos que componen el sistema y su almacenamiento lógico.
Para construir estos diagramas existen cuatro elementos
principales:
Los rectángulos representan entidades externas, las cuales son
orígenes o destinos de los datos, es decir son todas aquellas cosas,
personas o sistemas que aportan o reciben datos como resultado
del proceso.
Página 86 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Los rectángulos redondeados representan los procesos, los cuales
toman los datos de entrada para hacer algo (un proceso) y
generan una salida.
Las flechas representan los flujos de datos, los cuales viajan entre
las entidades y los procesos y entre los procesos y los almacenes
de datos.
Finalmente un rectángulo con el lado izquierdo abierto representa
un almacén de datos, el cual puede ser un archivo, un documento
en papel, un archivador o cualquier cosa que pueda almacenar
datos de un proceso que nos interese.
El proceso de generación de estos diagramas consiste en definir un
escenario para con esa información definir las entidades y los
procesos que se realizan. Una vez que hayas definido el escenario
comienzas a dibujar las entidades en el lado izquierdo del
diagrama, a continuación defines los procesos que se realizan en el
Página 87 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
sistema y unes a estas entidades con los procesos. Recuerda que
esta unión entre procesos y entidades no se realiza al azar sino
que es fruto de un proceso de análisis en el cual se identifica si la
entidad entrega o recibe datos de un proceso en particular, para
muestra el siguiente ejemplo.
Fíjate que en el contexto del sistema de compra en línea, el
proceso de validación de usuario está relacionado con la entidad
usuario que es la que envía los datos y estos se buscan en el
almacén de datos del usuario, estos datos son analizados por el
proceso de validación de datos y con esto se generan los permisos
de acceso del usuario de esta misma forma se van a analizando y
uniendo las entidades con los procesos, los procesos con otros
procesos, los almacenes con los procesos, la siguiente tabla
muestra la relación existente entre cada uno de los elementos del
diagrama mediante los flujos de datos que son los conectores.
Entidad Proceso Almacén
Entidad NO SI NO
Proceso SI SI SI
Almacén NO SI NO
Página 88 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Utilizando esta tabla anterior, podemos definir algunos ejemplos de
cosas que jamás podrías hacer:
En el caso anterior, si bien en la vida real el profesor y el alumno
se relacionan, en el caso del uso de un sistema ellos nunca
conversan pues ambos conversan por separado con el sistema y
finalmente eso es lo que nos interesa reflejar en este análisis.
En el ejemplo anterior, las entidades nunca pueden enviar un flujo
de datos directamente al almacén, pues siempre los datos al
menos pasan por un proceso de validación antes de ser guardados
en un almacén de datos.
Página 89 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Como puedes ver los almacenes de datos tampoco se pueden
relacionar, pues al ser sólo repositorios, ellos no pueden ejecutar
ninguna acción, sólo almacenan datos.
Adicionalmente a lo visto existen algunas otras reglas que debes
observar respecto a los DFD:
a) Todos los procesos deben tener al menos un flujo de entrada y
uno de salida.
Estos son ejemplos válidos.
Página 90 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Estos son ejemplos no válidos.
b) Todos los procesos deben modificar los datos de entrada
produciendo nuevas formas de datos de salida. Algunos
procesos comunes son validaciones, ordenamientos, búsquedas,
etc.
c) Cada uno de los almacenes de datos debe tener al menos un
flujo de datos, ya sea de entrada, salida o actualización de
datos.
d) Cada una de las entidades externas debe estar relacionada con
al menos un flujo de datos.
e) Cada flujo de datos debe estar asociado al menos a un proceso.
Si bien estos diagramas son una buena alternativa para
representar la relación entre las entidades, los procesos y los
almacenes de datos utilizando para esto los flujos de datos,
también es necesario mantener el control respecto a la
complejidad de los procesos representados. Utilizando conceptos
de teoría de sistemas, trata siempre de mantener los diagramas lo
más simple posibles, si el diagrama no es suficiente, lo puedes
documentar, es decir puedes definir por escrito los procesos y el
trabajo que cada uno de los componentes realiza en el contexto
del problema.
Página 91 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Diagrama de procesos (BPMN 2.0)
Cuando estés trabajando, muchas veces tendrás que realizar
análisis de sistemas que son muy complejos. Una herramienta que
te permite representar gráficamente los sistemas es utilizando un
diagrama que se llama BPMN, Business Process Model and
Notation (BPMN) es decir Modelo de Procesos de Negocio y
Notación.
Esta es una notación gráfica que describe los pasos que se
realizan en un proceso. Esta notación ha sido especialmente
diseñada para coordinar la secuencia de los procesos y los
mensajes que fluyen entre los participantes de las diferentes
actividades.
BPD (Bussines Process Diagram) o diagrama de procesos de
negocio es un diagrama diseñado para representar gráficamente la
secuencia de todas las actividades que ocurren durante un
proceso, basado en la técnica de diagrama de flujo incluye además
toda la información que se considera necesaria para el análisis.
BPD es un diagrama diseñado para ser usado por los
analistas, quienes diseñan, controlan y gestionan procesos.
Dentro de un Diagrama de Procesos de Negocio BPD se utiliza un
conjunto de elementos gráficos, agrupados en categorías, que
permite el fácil desarrollo de diagramas simples y de fácil
comprensión.
El modelado de proceso es la captura de una secuencia de
actividades de negocio, y de la información de soporte. Los
procesos de negocio describen la manera cómo una empresa
alcanza sus objetivos. Es decir acá lo que analizamos y tratamos
Página 92 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
de graficar son los procesos de negocio. Recuerda que los
procesos de negocio son todas las actividades que realiza una
organización y que tienen que ver con la gestión de los datos para
obtener un resultado.
Existen diferentes niveles del proceso de modelado:
Mapas de proceso. Son diagramas de flujo simple de las
actividades.
Descripciones de proceso. Conforman una extensión
del anterior, y manejan información adicional pero no
suficiente para definir completamente el funcionamiento
actual.
Modelos de proceso. Son diagramas de flujo extendido con
suficiente información para que el proceso pueda ser
analizado, simulado, y/o ejecutado
Para realizar los diagramas, BPMN clasifica los elementos de la
siguiente forma:
Objetos de flujo, que son elementos que permiten definir cosas
que “suceden” durante el proceso de negocio. De esta forma
tenemos los eventos de inicio, los eventos intermedios y los
eventos de fin.
Los eventos de inicio se grafican de la siguiente forma:
Representa un evento de inicio que no tiene condición o
requisito previo.
Página 93 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Un proceso o una aplicación que da inicio a un proceso
mediante un mensaje.
Representa una fecha o una hora en la cual se iniciará el
proceso o tarea.
Los eventos intermedios forman parte del flujo del proceso en la
secuencia normal del mismo. Pueden o no anteceder a una
actividad o subproceso.
Representa el envío o la recepción de un mensaje desde
otros procesos.
Representa un mecanismo de retraso dentro del proceso.
Puede estar definido como una fecha o unidad de tiempo.
Permite conectar dos secciones de un proceso para
graficar situaciones repetitivas o para evitar líneas de
secuencia de flujo largas o cruzadas que puedan ser muy
complejas.
Los eventos de fin se representan de la siguiente forma:
Representa un evento de fin que no tiene condición o
requisito previo.
Representa un evento de fin que termina con un mensaje.
Página 94 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Las actividades son la representación de un trabajo que se realiza
en el sistema analizado. Se representa con un rectángulo
redondeado. Una actividad puede ser atómica o compuesta. Los
tipos de actividades son:
Una tarea es una actividad atómica que está incluida dentro de un
proceso.
Se habla de tarea cuando el trabajo que representa en el proceso
no puede descomponerse en un nivel mayor de detalle.
Un subproceso es un conjunto de actividades incluidas
dentro de un proceso. Puede descomponerse en diferentes
niveles de detalle denominadas tareas. Se representa con un
símbolo de suma en la parte central inferior de la figura. A
continuación se presentan los tipos de subprocesos:
Una tarea contraída o colapsada muestra una
tarea cuyos subprocesos no pueden ser
visualizados. El signo + indica que la actividad en
un subproceso y que tiene el nivel más bajo de
detalle.
Página 95 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Un proceso expandido muestra los subprocesos, es decir está en el
mismo nivel de detalle del proceso y tiene un evento de inicio y fin
del proceso.
Las compuertas o gateway se representa con un diamante y
representa una divergencia o convergencia de la secuencia de
flujo. Estas siempre determinan bifurcaciones, combinaciones o
fusiones del proceso.
La compuerta exclusiva puede ser de dos tipos
convergente o divergente, la divergente son
decisiones que toma el usuario del sistema para
saber que camino seguir, las convergentes
sincronizan los caminos salientes al cumplir una condición del
negocio.
La compuerta compleja representa un punto
donde aparecen varios caminos y sólo uno de
ellos es válido.
Página 96 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
La compuesta paralela indica un punto en el
proceso donde pueden ser llevadas a cabo varias
actividades en paralelo.
Los objetos conectores conectan los objetos de flujo de un
proceso, y definen el orden de ejecución de las actividades. Los
tipos de conectores son:
Conector de secuencia, muestra el orden de los
eventos, actividades y decisiones que se
realizan dentro del proceso.
Conector de mensaje, indica el flujo de mensaje
entra las distintas entidades de los procesos.
Conector de asociación, permite asociar
diferentes artefactos con objetos de flujo.
Página 97 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Los swimlanes o canales son un mecanismo empleado para
organizar actividades en categorías separadas visualmente, con
el fin de ilustrar diferentes capacidades funcionales o
responsabilidades.
Representa a los actores externos o internos con los cuales
interactúa un proceso, contiene un conjunto de actividades
asociadas a su rol.
Los artefactos son objetos gráficos que proveen información
adicional de los elementos dentro de un proceso, sin afectar el
flujo del proceso.
Los grupos se utilizan para agrupar un conjunto
de actividades, la agrupación se puede realizar
con propósitos de documentación o de análisis.
Las anotaciones, son un mecanismo para
entregar información adicional.
Página 98 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Acá vemos un ejemplo de un proceso de compra y venta de
productos con el posterior despacho de este producto por parte del
vendedor. Fíjate que la representación de los procesos se hace
cada una en su propio canal o swimline para separar las tareas
que están asociadas a cada uno de los roles en el proceso.
Página 99 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Página 100 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Diagrama de casos de uso.
El diagrama de casos de uso, es el primer diagrama que
aprenderás a crear en profundidad, este diagrama te permitirá
analizar los problemas que vayas estudiando de una manera
gráfica que es mucho más cercana a la realidad que conoces. Este
diagrama permite a los analistas tener una visión primitiva
respecto de cómo funciona o debería funcionar el sistema que se
está analizando y ver cómo cada uno de los entes que participan
en el proceso van a interactuar con este sistema.
Recuerda que cuando hablamos de sistema, estamos hablando de
un conjunto de objetos que se interrelacionan con el fin de lograr
un propósito común, por lo tanto los sistemas que analicemos
pueden ser de cualquier tipo, pero por el perfil de nuestra carrera
tenemos que acercarnos a los sistemas de información. Recuerda
que los sistemas de información son un conjunto de normas y
procedimiento que definen el cuándo, dónde y por qué se realizan
las cosas, un conjunto de personas que realizan las acciones y las
corrigen y un conjunto de hardware y software que permiten
automatizar los procesos que sean monótonos o que lleven mucho
tiempo y que generalmente están asociados a la gestión de los
datos. Por lo tanto siempre recuerda que un sistema de
información no es sólo software o sólo hardware es un todo mucho
más complejo. También debes tener la seguridad que nunca se
construye el uno sin el otro (o al menos no se recomienda) pues
están relacionados y el uno sin el otro, provoca que el sistema
quede incompleto.
Página 101 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Te preguntarás ¿Y cómo hago todo esto?, pues bien, la respuesta
por un lado es simple, pues lo único que debes hacer es pensar y
por otro compleja dado que hay que pensar y mucho, básicamente
debes aprender a resolver problemas como si fueras un detective,
es decir, recopilar información asociada a los hechos, luego
proponer soluciones, reconstruir procesos o acciones que
ocurrieron y luego establecer la forma de corregir los errores. Para
esto tienes dos aliados que son indispensables, el hardware y el
software.
Como ya sabes que hay que pensar debes hacer que tu cerebro te
obedezca e intente resolver problemas por ti. Para esto lo primero
que debes hacer es recopilar toda la información respecto a como
funcionan los sistemas que estás analizando y luego generar un
diagrama que te ayude a ver si lo que pensaste se ajusta o no a la
realidad.
El diagrama de casos de uso cumple esta función, ahora dado que
se puede malinterpretar pues es sólo una representación gráfica de
la realidad de un proceso, es necesario documentar este diagrama,
para aclarar algunos conceptos que puedan quedar en el aire. Es
importante comprender que este es un proceso iterativo e
incremental que fue pensado para ser de esta forma ,es decir para
que puedas analizar en como solucionar las cosas, debes tener en
cuenta es que no es recomendable trabajar solo pues dos o más
cerebros piensan más que uno, adicionalmente si no puedes
verbalizar una idea o explicarla en palabras o texto, significa que
tu cerebro aún no lo puede resolver del todo y debes tratar volver
a analizar. Este proceso es muy entretenido pues implica el
investigar y tratar de dar soluciones a problemas cotidianos
Página 102 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
aplicando tecnología y todo el conocimiento que vayas adquiriendo
durante tu carrera.
Básicamente los sistemas de información se encargan de realizar
cuatro procesos:
Captura de datos.
Almacenamiento.
Procesamiento.
Entregar de resultados.
Todos los sistemas de información realizan básicamente estos
cuatro procesos desde el procesador de texto hasta los video
juegos pasando por software empresarial y páginas web.
Básicamente lo que hacemos es dar soluciones basándonos en una
combinación de hardware, software y mucho análisis respecto a los
procesos que realiza la organización que estamos estudiando para
realizar sus tareas, todo ángulo del almacenamiento,
procesamiento y entrega de resultados del proceso.
A lo mejor te estas haciendo algunas preguntas del tipo ¿Para que
almacenar datos?, ¿Quién define los procesos de la organización?,
¿Es lo mismo un dato que información?, ¿El fin del mundo será el
2012?, ¿Cómo es posible que los vampiros que son seres de la
noche puedan caminar de día en la película Crepúsculo?, estas y
otras preguntas las responderemos durante el desarrollo de este y
los siguientes capítulos.
La comunicación que se establece entre las personas siempre es
compleja, una persona que emite una frase o comentario puede
ser mal interpretada por el receptor pues, su interpretación de lo
que está escuchando depende de muchos factores. Como nuestro
Página 103 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
objetivo al construir diagramas es poder transformarlos en
software o en una solución informática, no nos podemos dar el lujo
de que esto suceda. El diagrama de casos de uso, nos facilita
mucho la tarea de mostrar a la contraparte mediante un dibujo lo
que hemos entendido y de contener errores es fácil de corregir.
Las organizaciones requieren gestionar la información de sus
procesos para poder tomar decisiones respecto a como están
haciendo las cosas para continuar haciéndolo bien o para mejorar
lo que están haciendo mal. Por ejemplo, si fabricamos 3000 litros
de helados en marzo y vendemos pocos litros en invierno lo más
probable es que el próximo año ajustemos la cuota de producción
en función de las ventas del año anterior, para no tener que botar
2999 litros como la temporada anterior. Este tipo de decisiones
están asociadas a todos los procesos
Componentes del diagrama de
casos de uso.
Para poder realizar de forma correcta un diagrama de casos de
uso, debes saber que este está compuesto por tres elementos: los
actores, los casos de uso y las relaciones. Cada uno de estos
elementos permite que tengas una visión de los componentes de
un sistema (personas, reglas y procedimientos) y cómo estos se
relacionan.
Recuerda que un diagrama de casos de uso se circunscribe a un
momento en el tiempo, es decir que lo que nos muestra es la
relación entre los procesos y las personas en un momento
específico o como se suele decir, en un escenario particular.
Página 104 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
En los casos de uso, el escenario se define como un momento
específico en la vida de un proceso que esta siendo analizado, esta
separación se hace para poder simplificar el análisis de los
procesos. Por ejemplo, cuando compras un producto en una
multitienda, se producen muchos procesos de traspaso de
información, por ejemplo cuando vas a comprar un producto el
proceso comienza cuando tu buscas ropa por modelo, marca,
color, o precio, en función de estos parámetros (todos, una
combinación de ellos o sólo uno), tú seleccionas un artículo, te
acercas al vendedor, vas a la caja y cancelas, ya sea con tarjeta de
crédito, con efectivo o con cheque y luego de la impresión de los
comprobantes de la venta, te puedes llevar el artículo. Si te fijas
este es un escenario del proceso, pero ¿Qué pasa si el artículo es
muy pesado como un refrigerador y no te lo puedes llevar y este
debe ser enviado a tu casa?, ¿Qué sucede si debes devolver el
artículo porque no te gustó, o porque presenta fallas?, si te fijas
cada una de estas situaciones, son parte del proceso de venta de
un producto pero son escenarios diferentes, es decir situaciones
que van más allá del proceso “normal” y conocido de una venta.
Por eso cada vez que hacemos un diagrama de casos de uso es
muy importante que definamos el escenario en el cual se va a
desarrollar. Este escenario tiene como misión fundamental el
circunscribir el problema y definir los factores que puedan afectar
el comportamiento del sistema, piensa que el comportamiento del
sistema para un vendedor que realiza una venta es distinto que
para un vendedor que desea procesar una devolución o un cambio,
por lo tanto es necesario establecer el modelo en función del
escenario específico que se está analizando.
Página 105 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Vamos a ver en detalle los componentes del diagrama de casos de
uso.
Actores.
Los actores se definen en un diagrama de casos de uso como entes
externos que interactúan con funciones del sistema. De esta forma
un actor no necesariamente es una persona, puede ser una
entidad o una idea. Lo que sucede es que cuando las
organizaciones son complejas, el software que da soporte a la
organización también lo es, y ya no hablamos de personas usando
el software sino que de departamentos (que finalmente son un
conjunto de personas), pero que no tienen un “rostro” visible. En
estos casos el actor no es una persona, sino que una
representación de varias personas o de ninguna en particular.
Los actores se representan como una persona dibujada con palitos,
como cuando éramos pequeños y aún no aprendíamos a dibujar.
Página 106 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Fíjate que el actor posee un nombre que define su rol, es decir el
papel que le corresponde realizar en ese escenario específico, este
rol del usuario esta definido por el escenario, así en un sistema
llamado “casa”, probablemente desempeñes alguno de los
siguientes roles: “hermano(a)”, pololo(a), hijo(a), esposo(a), papa
o mamá, etc., fíjate que es posible que tú cumplas más de un rol,
por ejemplo, hermana, polola, mamá dentro del mismo sistema,
pero las acciones que realizas y como las realizas son distintas en
función del rol que te toca representar en ese escenario en
particular. Por ejemplo supongamos que sabes cocinar y al mismo
tiempo eres hijo de tus padres, cuando estás en la cocina,
estableces un rol de usuario de la cocina, cocinero y por lo tanto
vas a interactuar como usuario cocinero con el sistema cocina, el
cual se encuentra dentro del sistema casa, cuando ya serviste la
comida, entonces interactúas con tus padres de forma distinta,
pues tu rol de cocinero cambió por el rol de hijo.
Casos de uso.
Un caso de uso se define como una función que tiene o debe tener
el sistema y que es utilizada por un usuario. De esta forma los
casos de uso se transforman en las acciones que debe
implementar el sistema, recuerda que en el análisis de casos de
uso, la vista desde la cual analizamos el problema es como
usuarios del sistema que deben cumplir una serie de tareas que
van asociadas a nuestro rol en un escenario específico. De esta
forma si analizamos las tareas que debe realizar un vendedor para
poder vender algún artículo en una multitienda (fíjate que el
problema se circunscribe a ese escenario en particular), este debe
poder consultar por los precios de los productos, vender uno o más
Página 107 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
productos a un cliente, consultar el total de la venta, imprimir el
comprobante de la venta, recibir el pago, y dar vuelto si
corresponde, recuerda que este es una aproximación inicial al
problema por lo que las etapas pueden cambiar, así que si
descubres más, siéntete libre de agregarlas . Una vez que
determines las tareas que debe hacer el actor, estas deben ser
analizadas pues a veces este análisis inicial puede llevar a una
confusión.
Realicemos el siguiente análisis, supongamos que tenemos la
siguiente definición de procesos:
“Necesitamos representar un sistema que permita a los médicos de
una clínica dental, definir sus horarios de atención y a los clientes
de la clínica el registrarse y el solicitar hora a través de una página
web”
Pese a que esta es una definición de procesos extremadamente
simple, ya podemos definir algunas características iniciales para el
modelo y basándonos en estas características iniciales podemos
con posterioridad hacernos algunas preguntas respecto a como
funcionan las cosas y tendremos la posibilidad de mejorar el
modelo.
Lo primero es definir a los actores (personas o sistemas u
organizaciones) que participan del proceso. De esta forma
identificamos al menos dos, médico y paciente.
Página 108 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Una vez que identificamos a los actores, lo que debemos hacer es
definir los casos de uso, es decir a las acciones que estos actores
van a realizar para lograr el objetivo propuesto.
Para el ejemplo anterior vemos que podemos detectar ciertas
acciones o comportamientos que debe realizar cada uno de los
actores como usuarios del sistema, así podemos dividir las
acciones que realiza cada uno de la siguiente forma:
Médico: Define su horario de atención
Usuario: Registrarse, solicitar hora.
Si te fijas la definición de los casos de uso define el qué, pero no el
cómo, pues aún no interesa, recuerda que estamos primero
definiendo qué es lo que hay que hacer, concéntrate en este
punto, pues si bien la tecnología es importante antes de identificar
y solucionar el problema, hay que saber qué es lo que necesitamos
Página 109 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
que el sistema haga. Un punto importantísimo que debes analizar
son los datos que necesita el proceso para poder realizarse
completamente o de otra forma tratar de definir los datos que la
organización necesita registrar como parte del proceso para la
toma de decisiones, por lo tanto el diagrama final quedaría de la
siguiente forma:
Página 110 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Relaciones.
Las relaciones permiten establecer la forma en que los actores y
los casos de uso se comunican y adicionalmente muestra la
relación existente entre los casos de uso.
Existen cuatro tipos de relaciones en los diagramas de casos de
uso, asociación de comunicación, extensión, inclusión y
generalización.
La relación de asociación de comunicación se establece entre el
actor y el caso de uso y nos permite definir en el contexto del
diagrama que el actor está utilizando que el caso de uso. Recuerda
que cada uno de los actores que aparezca en el diagrama debe
estar relacionado al menos con un caso de uso, pues la relación
entre el actor y el caso de uso nos indica qué funcionalidad del
sistema será utilizada por cada uno de los actores que están
representados en ese escenario particular.
En la relación de inclusión, la que graficamos con una línea
segmentada que une dos casos de uso más una flecha que indica
la dirección de la relación, estamos representando dos casos de
uso que son complementarios. En la relación de inclusión, un caso
de uso necesita de otro caso de uso para poder realizar una
operación en particular. Recuerda que en la inclusión el resultado
del caso de uso incluido afecta el caso de uso que incluye por lo
tanto están íntimamente relacionados los resultados de ambos.
Este tipo de relaciones se grafica utilizando la palabra
<<include>> sobre la línea que muestra la relación.
Página 111 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
En la imagen anterior fíjate que el caso de uso denominado “login”,
incluye su funcionalidad al caso de uso “buscar usuario”, que
también es utilizado por el caso de uso “registro” para evitar que el
usuario se registre dos veces. En este ejemplo ambos casos de uso
incluyen su funcionalidad, y así la ejecución o no del caso de uso
se relaciona con el resultado obtenido por el caso de uso incluido,
es decir, el caso de uso “login” y el caso de uso “registro” no
están completos sin la utilización de “buscar usuario”, pues de este
segundo caso de uso depende el resultado del primero.
Cuando se trata de relaciones de extensión las cuales se grafican
con la palabra <<extend>>, también se puede analizar la relación
como si los dos casos de uso fueran sólo uno. Pero una de las
diferencias básicas es que hay situaciones en que el caso de uso
de extensión no es indispensable que ocurra, y cuando lo hace
ofrece un valor extra el cual extiende al objetivo original del caso
de uso base, mientras que en el <<include>> es necesario que
ocurra el caso incluido sólo para satisfacer el objetivo del caso de
uso base.
Un ejemplo de lo anterior lo podemos analizar en el siguiente
ejemplo:
Página 112 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
En el ejemplo anterior el caso de uso “servir café” extiende hacia el
caso de uso “agregar azúcar”, fíjate que para “servir café” no es
siempre necesario el “agregar azúcar”, pero cuando se hace, le
agrega un valor al caso de uso anterior, sin que exista la
dependencia del uno con el otro.
Otro tipo de relación que se establece en los casos de uso es la
relación de generalización, la cual se dibuja en el diagrama
mediante una flecha con sentido, la punta de flecha a diferencia de
los otros tipos de relación a parte se rellena. La generalización está
asociada al concepto de especialización, en esta situación un caso
de uso puede dar origen a una forma especializada de realizar una
acción para muestra un ejemplo:
En el diagrama anterior el proceso de pago en el sistema se puede
realizar de dos formas, con la tarjeta de la multitienda o en
efectivo. Si te fijas cada uno de estos procesos en sí es un pago,
Página 113 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
por lo tanto, como ambos son una forma de pagar, podemos
definir que la generalización del proceso es el pago el cual hereda
su comportamiento a los otros casos de uso.
Identificación del contexto en el
que participan los actores.
Uno de los puntos principales para poder realizar un buen análisis
de la situación actual, es poder determinar el contexto en el cual
participan los actores. Es importante recalcar que muchas veces el
contexto del problema es importante para determinar las acciones
que se deben considerar a implementar como casos de uso. Para
muestra el siguiente ejemplo:
“Un taller mecánico recibe vehículos para ser reparados, los
clientes que desean atender su vehículo, primero deben registrar
sus datos y los del vehículo, adicionalmente se registra el motivo
de la visita en el taller y se procede a la evaluación preliminar del
vehículo. Junto con esto se hace una cotización basándose en la
detección de los problemas que presenta el vehículo. Una vez se
recibe esa cotización y el cliente da la autorización para ejecutar el
trabajo, este es asignado a uno o más técnicos mecánicos los
cuales proceden a la ejecución del trabajo que está asociado a su
especialidad (falla mecánica del motor, amortiguación, sistema
eléctrico, mantención periódica, etc.). El proceso se lleva cabo por
cada uno de los técnicos y es revisado por un jefe de taller el cual
fiscaliza la correcta ejecución del trabajo. Una vez que el trabajo
completo es realizado, el vehículo es entregado al cliente.”.
Página 114 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Identificación de los roles.
El proceso de identificación de los actores, pasa por determinar,
personas o sistemas que entreguen información al sistema o
reciban información de este (entes pasivos), ahora tanto el envío
como la recepción de la información está asociada al contexto del
problema. Si te fijas en el enunciado del ejercicio anterior, nuestro
contexto se remite a la recepción del vehículo, el diagnóstico del
problema, la asignación de tareas, el proceso de verificación de la
ejecución de las tareas y la devolución del vehículo reparado,
jamás se consideró el cobro a los clientes ni el pago a los
proveedores de insumos, ni el pago a los trabajadores, pues
nuestro contexto es sólo el de la definición de procesos. Es posible
que un análisis posterior nos pudiera mostrar que existe relación
con otras áreas pero siempre es necesario determinar las fronteras
del sistema para realizar un análisis acotado.
Una vez que hayamos determinado el contexto del problema, es
necesario determinar a los actores que pueden ser personas,
entidades u otros sistemas que envían o reciben información desde
y hacia el sistema. Recuerda que cuando hablamos de un sistema
en el análisis de casos de uso, estamos hablando de un conjunto
de procesos que nos permiten lograr un resultado, en el caso
anterior, reparar nuestro auto.
Si analizamos la definición de procesos del ejemplo podemos
detectar algunos actores iniciales:
Cliente: quien lleva el auto.
Recepcionista: quien recibe y anota los datos del vehículo y el
cliente.
Página 115 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Técnico mecánico: quien recibe la información de las tareas que
debe realizar asociadas a un vehículo.
Jefe de taller: Es el que revisa que el trabajo se haya realizado de
forma correcta.
Fíjate que podemos hacer un análisis un poco más avanzado del
proceso y podríamos pensar en lo siguiente ¿Qué pasa si el
recepcionista, el técnico y el jefe del taller son la misma persona?,
la mejor respuesta a esto es que lo que estamos analizando son
los roles que cumplen las personas al enfrentarse al uso del
sistema, por lo tanto independiente de que sean 1 o 100 personas
que estén interactuando con el sistema, lo que nos interesa es
encontrar los roles que ellos están ejerciendo.
De esta forma podemos definir que cada uno de los roles tiene
asociada una serie de tareas que debe realizar para poder aportar
su parte en el proceso. Por ejemplo el técnico mecánico le podrían
eventualmente corresponder realizar más tareas que las definidas
(recibe las tareas realizadas). Utilizando esta misma línea de
pensamiento, podemos identificar que existen varios actores
asociados a un rol en particular, en este caso por ejemplo pueden
existir varios clientes y varios mecánicos, además si te fijas el
cliente puede no sólo traer el vehículo, sino que además en otro
contexto debe pagar por el servicio.
Definición de los actores.
Una vez que defines los roles en la organización o en el sistema
que estas analizando, es necesario que definamos los actores
asociados a los roles que has encontrado, para esta identificación,
debes poner especial atención en que pueden existir varios actores
Página 116 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
que estén asociados a un mismo rol, por ejemplo en el análisis de
nuestro caso, podríamos encontrar a varios mecánicos, pero sólo
registramos uno. Ahora esto nos podría llevar a pensar que existen
tanto usuarios como roles, pero no es así, pues es posible que un
mismo actor pueda cumplir varios roles en función de su contexto.
Esto puede parecer un poco complejo, pero no lo es, piensa que un
rol está asociado a una tarea, mientas que un actor puede cumplir
varios de estos roles en diferentes contextos, es decir que un
mecánico puede realizar más tareas que las detectadas en otro
contexto. Ahora recuerda que si identificas a varios actores
(alumnos de un curso, pasajeros de un bus, jugadores de un
equipo), estos se consideran como uno solo, pues el rol que están
cumpliendo es el mismo para todos.
Definición de los casos de uso.
Un caso de uso se entiende como una acción con la cual interactúa
un actor, esta acción es parte del sistema que estamos analizando.
Esta acción se puede descomponer en un conjunto de acciones
distintas, pero eso es parte de análisis posteriores. Recuerda que
los casos de uso pueden recibir información del actor o pueden
entregar información al actor. En cada uno de esos casos el
proceso siempre tiene un objetivo dentro del proceso general de la
organización. Recuerda que cada uno de los casos de uso que
logres identificar están asociados al propósito del sistema que
estás analizando. Así, en nuestro ejemplo podemos identificar las
acciones que debe realizar cada uno de los usuarios como
muestran las siguientes imágenes.
Página 117 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Definición de los casos de uso.
Existen distintas formas para poder detectar los casos de uso para
un sistema que estemos analizando, algunas de esas formas
pueden ser una lluvia de ideas en la cual los participantes aporten
ideas respecto a los casos de uso que cada uno identifica por
separado al hacer el análisis de la descripción de los procesos. Otra
forma de realizar este análisis es utilizando a los actores que ya se
han definido, analizando a cada uno de ellos podemos determinar
los procesos en cuales ellos participan o inician. Adicionalmente
Página 118 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
nos podemos hacer una serie de preguntas relativas al sistema que
estamos analizando.
¿Cuáles son las tareas que debe realizar un actor?
¿Qué información crea, guarda, modifica, destruye o lee el actor?
¿Debe el actor notificar al sistema los cambios externos?
¿Debe el sistema informar al actor de los cambios internos?
Respondiendo las preguntas anteriores y realizando una
combinación de los procesos descritos, ya que no hay ninguno
mejor que el otro, podemos identificar sin mayor problema a los
casos de uso del sistema.
Página 119 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Definición de los tipos de relaciones
Las relaciones en el diagrama de casos de uso se dan entre los
actores y los casos de uso y adicionalmente entre los casos de uso.
Estas relaciones nos permiten establecer de forma gráfica como un
caso de uso se asocia con otro caso de uso para complementar su
funcionalidad o con un usuario para mostrar la forma en que estos
son utilizados.
Comunicación.
Es el tipo de relación que se establece entre el usuario y el caso de
uso, se define con una línea continua que une al actor y el caso de
uso.
Inclusión.
La relación de inclusión nos permite mostrar la forma en que los
casos de uso se complementan con otros casos de uso a los cuales
incluyen para poder realizar una acción. Cuando el caso de uso
incluye a otro, el caso incluido sirve para complementar la acción
del primer caso de uso, vale decir, sin el caos de uso incluido, el
caso de uso inicial no puede completar su tarea.
Página 120 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Extensión.
En la relación de extensión el caso de uso extendido, completa su
acción con el caso de uso extendido, es decir, el caso de uso
extendido, aumenta su funcionalidad con el caso de uso extendido,
pero el caso de uso extendido no es necesario siempre.
Página 121 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Generalización.
La relación de generalización en los casos de uso permite definir
un caso de uso especializado para una situación en particular, es
decir existe un caso de uso específico que realiza una acción, pero
también un caso de uso que se especializa en realizar un proceso
en particular.
Documentación de los casos de uso.
La documentación de los casos de uso es un proceso que permite
aumentar el grado de comprensión de los procesos asociados a los
casos de uso. Esta documentación está orientada a servir como
complemento al diagrama pues el diagrama muchas veces no
permite representar con claridad los procesos ni cómo estos se
implementan. Adicionalmente la documentación es una guía
práctica para que los desarrolladores de las aplicaciones a futuro
puedan implementar de mejor forma la funcionalidad de la
aplicación. Otro aporte fundamental de la documentación es el
hecho de que también puede ser revisada por la contraparte
Página 122 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
cliente y se podrá trabajar con ellos en la definición correcta de los
procesos acá descritos.
Existen muchos formatos para realizar la documentación de los
casos de uso, vamos a usar un formato básico pero completo para
poder establecer de la mejor forma la descripción de los casos de
uso.
Nuestro documento constará de las siguientes partes:
Definición del caso de uso.
En esta parte se define el nombre del caso de uso, su identificador
y se da un breve descripción del caso de uso, fundamentalmente la
descripción está orientada a definir el proceso general que se está
describiendo.
Flujo Normal.
La sección del flujo normal pretende que definamos el flujo normal
de actividades que se pueden identificar en un caso de uso, este es
el “camino feliz” es decir el proceso en su estado ideal en donde
nada falla y todo está como queremos.
Adicionalmente al flujo normal se suele definir una serie de
caminos alternos que nos permitan saber cómo se comporta el
sistema que estamos analizando cuando el proceso no llega a buen
puerto. La realización de este tipo de análisis es muy importante
pues muchas veces el flujo alterno puede definir una regla
importante respecto al flujo del proceso.
Página 123 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Pre-condiciones.
Las precondiciones permiten formalizar todas aquellas condiciones
de deben considerarse como requisitos para la ejecución de
nuestro caso de uso
Post-condiciones.
Las post-condiciones con estados finales con los cuales termina el
caso de uso y que son obligatorios. Esto significa que el caso de
uso debe terminar su proceso con alguna de las condiciones
definidas en esta sección.
Para clarificar el concepto, fíjate en la definición del caso de uso
que esta hecha en el siguiente texto:
• Nombre del caso de uso: Registro de usuario
• Actores: Usuario/Administrador
• Objetivos: Registrar al usuario/administrador en el sistema
• Pre-condiciones:
1. El usuario no debe estar registrado con anterioridad.
• Flujo Normal:
1. El usuario solicita el registro.
2. El usuario llena el formulario de registro.
3. El sistema valida que los datos estén completos y que la información
sea del tipo correcto.
4. El sistema chequea que el usuario no se encuentre registrado con
anterioridad.
5. El sistema almacena los datos del usuario, asignándole los permisos
necesarios.
Página 124 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
6. El sistema muestra un mensaje de exito en el proceso de registro.
• Post-condiciones:
1. El usuario es registrado en el sistema y se le envía un correo el cual
contiene un hipervínculo que debe ser seguido para validar el registro.
• Excepciones:
1. El usuario cancela el registro
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.
Página 125 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Página 126 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Diagrama estático de clases.
Introducción al diagrama estático
de clases.
Como se vio en los capítulos anteriores, el mundo de los
diagramas UML es bastante extenso y cada diagrama tiene un
propósito específico y entre ellos muchas veces se complementan
para entregar información más específica respecto a un proceso en
particular, o la forma en que se deben realizar las cosas.
Uno de los diagramas que nos va a permitir mostrar la forma en
que los diferentes componentes del software interactúan entre si,
es el diagrama estático de clases.
Piensa en lo siguiente, la mayoría de las cosas que conocemos
están formadas por varias partes las cuales se complementan para
realizar una tarea específica, la cual no podría ser realizada por
ninguna de las partes por separado.
Por ejemplo cuando quieres prender tu televisor y te encuentras a
una distancia apreciable, vas a tener la tendencia natural a utilizar
el control remoto, si te fijas, para lograr prender el televisor, tú
como objeto, estás interactuando con el control remoto (otro
objeto) el cual envía una señal al televisor (otro objeto) y
finalmente el televisor se enciende.
Página 127 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Si analizas el comportamiento que tienen los objetos, podemos
definir que el objeto persona envía un mensaje al objeto control
remoto que a su vez se comunica con el objeto televisor para
realizar una acción. De esta forma tú no enciendes el televisor, es
el control remoto el que solicita al televisor que se encienda.
Una de las funciones del diagrama estático de clases es el poder
mostrar la forma en que los objetos se comunican y relacionan.
Utilidad del diagrama estático de
clases.
El diagrama estático de clases como lo vimos, permite obtener
información referente a 2 vistas en particular. La primera dice
relación con la forma en que los objetos se componen, es decir sus
características y la forma en que se comportan, y la segunda es
analizar la forma en que las clases se relacionan.
El diagrama permite tener una vista estática del problema el cual
no va a cambiar con el tiempo. Este diagrama adicionalmente nos
va a permitir avanzar en una concepción más acabada de cómo
todos los procesos que determinamos en el diagrama de casos de
uso se van a convertir en una aplicación de software o en un
proyecto de algún otro tipo (recuerda que una de las ventajas de
UML es que no sólo sirve para diseñar software). Cabe señalar que
el diagrama estático de clases no hace sólo referencia a como las
distintas partes del software interactúan sino que también puede
incluir hardware, y todos los otros componentes que forman un
proyecto informático.
Página 128 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
En cursos más avanzados en la línea de programación verás el
cómo poder interpretar este diagrama estático de clases y
convertirlo en una aplicación o al menos en una parte de ella. Una
de las ventajas de la orientación a objetos es que las aplicaciones
de software se pueden construir por partes sin que esto afecte el
total de la aplicación y adicionalmente esta parte que construyes la
puedes reutilizar en otros proyectos.
Componentes del diagrama estático de
clases.
Para comprender cómo podemos construir un diagrama estático de
clases primero vamos a conocer los distintos componentes de este
diagrama y que representan, además de cómo se relacionan unos
con otros y los diferentes significados que estos van a tomar en
función de como se relacionen.
Lo primero que debes entender es que existe una diferencia entre
la clase y el objeto, aunque muchas veces tendemos a confundirlos
producto de malos entendidos.
La clase es la muy parecido al plano de construcción de un edificio
o al diseño que hace un ingeniero en electrónica de un circuito
impreso, es decir acá se define la forma en que se van a construir
los objetos. Por lo tanto podemos decir que un objeto es la
construcción física basándonos en las especificaciones de una
clase. A continuación se define formalmente el concepto de clases
y objetos.
Página 129 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
“descripción generalizada (por ejemplo, una plantilla, un patrón o
un prototipo) que describe una colección de objetos similares”7
“descriptor de un conjunto de objetos que comparten los mismos
atributos, operaciones, métodos, relaciones y comportamiento”8
Si te fijas en las definiciones anteriores, éstas siempre hacen
referencia a un descriptor o plantilla o prototipo, es decir en una
clase es necesario hacer la definición de las características y las
acciones que realizarán los objetos. Para lograr este cometido
primero debes tener en claro el modelo que quieres representar.
Recuerda que una de las partes más complejas del desarrollo de
proyectos de tecnologías de información es tratar de definir de
forma correcta los requerimientos que tenga la contraparte.
Recuerda el ejemplo del bunker para el apocalipsis zombi. Si bien
un bunker para un apocalipsis nuclear te podría servir, el bunker
para el apocalipsis zombi tiene otras características que son
necesarias, por ejemplo muchas motosierras, y por lo tanto
suficiente combustible, y un sin número de armas corto punzantes
(machetes, espadas, katanas, etc.) que serán de mucha utilidad
cuando salgas a explorar los alrededores.
Una vez que tengas muy claro las necesidades de la contraparte
puedes comenzar a pensar en la funcionalidad que debe tener el
sistema y como cada una de estas funciones está pensada para un
tipo de usuario. Por ejemplo el sistema de transporte público tiene
funciones pensadas para diferentes usuarios (pasajeros, pasajeros
con capacidades de desplazamiento limitadas y choferes). Cada
7 Ingeniería del Software: Un enfoque práctico, Roger S. Pressman, McGraw-Hill/Interamericana de España, S.A.U. © 2002,
ISBN 84-481-3214-9 8 El Lenguaje Unificado de Modelado. Manual de Referencia, Pearson Educación, S.A. © 2000, ISBN 84-7829-037-0
Página 130 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
uno de ellos utiliza funcionalidades distintas del sistema, por
ejemplo sólo el chofer puede manejar. Cuando logras definir las
funciones y quien las utiliza en el sistema, entonces puedes
construir un diagrama de casos de uso (visto en el capítulo
anterior). ¿y que paso con las clases? Cuando logras establecer el
comportamiento del sistema y los usuarios que interactúan con el
sistema analizado, entonces estás en condiciones de pasar a la
siguiente etapa del proceso de análisis, que corresponde a tratar
de hacer una agrupación de funcionalidades que implementa el
sistema y agrupar estas funciones, si bien esto suena complejo, no
te preocupes esto lo has hecho de forma natural durante toda tu
vida, la diferencia es que no te habías dado cuenta. Para muestra
un ejemplo.
Supongamos que te encuentras leyendo este manual en la sala de
clases, si te fijas, la sala esta llena de objetos que interactúan
entre si y que en conjunto logran un objetivo, que en este caso es
el traspaso de conocimiento desde el docente al alumno. Ahora
debes tener en cuenta que los objetos que viven en esta sala de
clases, lo hacen con un propósito, este propósito está asociado a
su entorno, es decir, las actividades que realiza el alumno en la
sala de clases son diferentes a las acciones que realiza la misma
persona cuando va a comprar al supermercado, aunque se trate de
la misma persona.
Lo anterior nos demuestra que existe un ámbito para los objetos
en el cual el objeto se comporta de una forma específica y posee
ciertas características que están asociadas a los procesos que este
realiza. Por ejemplo, para estudiar, el alumno necesita materia que
le entrega el profesor, adicionalmente el profesor califica el
Página 131 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
desempeño del alumno con una nota, si te fijas en el ejemplo
anterior, cada uno de los objetos realiza un proceso y ese proceso
lo realiza con un conjunto de datos que les es propio o que algún
otro objeto les entrega. Este proceso de abstracción mental en el
análisis de los procesos que se ve tan complejo en realidad tú lo
llevas haciendo desde pequeño seguramente sin darte cuenta.
Volvamos ahora hacia las clases y su representación en el modelo.
Como vimos anteriormente, en el mundo real los objetos
interactúan entre sí y poseen datos que les permiten realizar sus
procesos, esos datos a su vez definen el comportamiento posible
de los objetos. Volvamos a ver un ejemplo, si tuviéramos que
definir un lápiz en orientación a objetos, tendríamos que definir
sus características o atributos y su funcionalidad.
Definición del lápiz
En los objetos la función y las características siempre están unidos
y nunca se separan, de esta forma, la función afecta a la
característica y viceversa, por ejemplo cuando el lápiz raya, esta
acción hace que la cantidad de tinta disminuya, cuando la cantidad
de tinta llega a 0, ¿Puede seguir rayando el lápiz? . Si analizas los
comportamientos de muchos objetos que te rodean te darás
cuenta de que esta unión entre las características y la función
Página 132 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
siempre se encuentra y es fácil de descubrir, por ejemplo, si
enciendo la ampolleta con el interruptor, ¿que otra cosa puede
hacer el interruptor? , ¿Puede volver a encender la luz?, ¿o
primero debe apagarla?. Fíjate que al encender o apagar la
ampolleta, estas cambiando el estado de la ampolleta (una
característica que posee) y al apagarla, esto también ocurre, pero
al estar encendida, esta sólo se puede apagar, ¿te das cuenta de la
relación?, si aún no queda claro, acá va otro ejemplo.
Supongamos que puedes viajar al pasado y logras traer de vuelta
a un tiranosaurio rex como mascota, si te fijas bien en su
comportamiento, te darás cuenta de que tu nueva mascota, entre
todas las cosas que hace, come bastante y además camina y ruge,
fíjate además que para cada una de esas acciones que realiza, la
nueva mascota utiliza energía, sólo puede realizar las acciones
antes descrita si la cantidad de energía es mayor a 0. Ahora bien
cada vez que realiza una acción, la cantidad de energía se
disminuye una cierta cantidad de unidades, pero cuando come, la
cantidad de energía acumulada aumenta. Con esto vemos que los
atributos o características de una clase se ven modificados por las
acciones o métodos, de la misma forma, si el dinosaurio mascota
no se alimenta, su cantidad de energía será 0 y por lo tanto no
podrá realizar ninguna de las acciones antes descritas.
Muy bien, ahora te debes estar preguntando ¿Y que paso con los
gráficos del diagrama?, ahora vamos a eso, en UML, la
representación de las clases, sus atributos y sus métodos se
realiza mediante una representación gráfica que muestra un
rectángulo dividido en 3 partes, la superior contiene el nombre de
Página 133 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
la clase, la parte central la definición de los atributos de las clases
y la parte inferior los métodos o comportamiento de la clase. Para
muestra un ejemplo:
Fíjate que cada una de las secciones posee ciertas características
con respecto a la forma en que éstas se definen.
Nombre de la clase: Esta se debe escribir centrada en la página y
con formato de texto ennegrecido, adicionalmente existe una
nomenclatura para la escritura de los nombres que si bien no es
estándar es la que se recomienda. Consiste en escribir el nombre
con un formato conocido como PascalCasing, este formato nos
solicita que escribamos el nombre con la primera letra en
mayúsculas y el resto en minúsculas, por ejemplo “Alumno”, ahora
si el nombre es un nombre compuesto, sugiere que las primeras
letras de cada una de las palabras tengan este formato, por
ejemplo “MascotaSaurio”.
Atributos: Los atributos se definen dentro de la clase utilizando un
formato llamado camelCasing, este formato define que la primera
Página 134 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
letra se escriba en minúsculas al igual que todas las otras, a
menos que tengas que crear un atributo compuesto que en este
caso solicita que la primera palabra la escribas en minúsculas pero
la primera letra de la segunda palabra la escribas con mayúsculas,
esta misma lógica se da si tienes más de dos palabras, por
ejemplo “edad”, fechaNacimiento”, tamañoPueraTrasera”.
Además cada atributo debe definir su tipo, en UML existen algunos
tipos de datos primitivos por ejemplo Integer, String, Boolean, etc,
pero también se pueden agregar otros tipos que permitan
aumentar la capacidad de tu modelo, esto se hace en función
generalmente del lenguaje de programación con el que se vaya a
generar el software al final.
Otra cosa que debes tener presente es que los atributos y los
métodos poseen niveles de visibilidad que determinan si un
atributo o método es visible desde fuera de la clase, esto es lo que
se denomina como la interfaz de una clase, es decir el conjunto de
atributos y de métodos con los cuales el objeto se comunica con su
ambiente, el siguiente ejemplo lo puede clarificar.
Lo más probable es que alguna vez hayas utilizado un reproductor
de DVD, el uso general indica que el reproductor se enciende, se
abre la bandeja, se pone el DVD en el interior y si todo esta
correctamente conectado, se comenzará a reproducir el contenido
del DVD. Ahora fíjate que tú interactuaste con el reproductor de
varias formas, pero algunas otras quedaron ocultas, ¿tú encendiste
el láser del DVD, realizaste la demultiplexión de la señal óptica
para ser transformada en audio y video?, lo más probable es que
no, tú sólo interactuaste con los botones del equipo y con el disco
en cuestión, pero el resto del proceso se realizó sin tu
Página 135 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
intervención. En este caso la interfaz del DVD es el conjunto de
botones con los cuales tú puedes hacer que este funcione. Todos
los objetos con los cuales interactuamos presentan una interfaz y
poseen un conjunto de métodos y propiedades con las que no
podemos interactuar pues están ocultas para nosotros. Esta
característica de ocultar comportamiento y acceso a las
propiedades de una clase se realiza por un tema de seguridad,
pues te imaginas cuantos ojos quemados existirían si te
permitieran manipular el láser o encender la chispa para prender
un motor,
De esta forma el atributo se define con el siguiente formato:
Nombre_atributo: tipo_dato=valor_inicial
Si te acuerdas del tema de la visibilidad, los atributos de las clases
se clasifican en privados (-) o públicos (+), para entender de que
se trata esto, piensa en lo siguiente, cuando enciendes el DVD, la
velocidad del motor que mueve el DVD es imposible que la
podamos acelerar o disminuir desde afuera, en este caso la
velocidad del motor es una atributo privado para la clase es decir
sólo se puede modificar desde dentro de la propia clase y se le
anota un signo - delante. Sin embargo, cuando por ejemplo
apagamos el interruptor de la ampolleta, la estamos apagando y
por lo tanto estamos modificando desde afuera una característica
de esta clase, en este caso la propiedad se define como pública y
se le anota un signo + delante del atributo.
De esta forma los atributos de la clase se anotan de la siguiente
forma:
-energiaZombi: Integer=100;
Página 136 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
-escudoProtector: Integer=20;
Los métodos de la clase también tienen una nomenclatura
específica, en este caso los métodos se anotan de la siguiente
forma:
NombreMetodo(atributo:tipoDato)
En este caso también debemos explicar algunas cosas respecto al
formato, el nombre del método representa el nombre del
comportamiento de la clase, este nombre debe ser significativo o
sea que te permita saber fácilmente que es lo que el método hace,
sólo con leer su nombre, por ejemplo, que es más fácil de
determinar, el comportamiento de un método que se llama
liquidarZombi(), o un método llamado x25rst45(), si te fijas, el
primer método se explica por si sólo, mientras que el segundo no.
Adicionalmente al nombre si te fijas entre paréntesis aparecen
variables, es decir valores que se identifican con un nombre y que
son de un tipo de dato específico, estas variables el método las
ocupa para poder tener información adicional que es parte del
mensaje que el objeto recibe para poder ejecutar el método. Los
objetos no hacen nada a menos que otro objeto se los pida, por
ejemplo el control remoto no enciende el televisor a menos que
nosotros se lo solicitemos, o por ejemplo el vehículo no se mueve
a menos que nosotros presionemos el pedal del acelerador, en este
caso la cantidad de presión que apliquemos al pedal será la
velocidad de salida del automóvil, si te fijas en este caso lo
podemos representar de la siguiente forma:
+acelerar(fuerza:Integer)
Página 137 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Por lo tanto ahora podemos representar clases como corresponde,
es decir:
Página 138 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Relación entre las clases y las
tablas de un modelo entidad
relación.
Como podemos observar, al crear y definir las clases, estas se
pueden analizar como un conjunto de datos sobre los cuales se
aplican un conjunto de métodos.
Este análisis de los procesos agrupando primero los datos, se
parece mucho al análisis que se realiza en la disciplina de base de
datos para crear las “entidades” de datos que nos van a permitir
agrupar los datos en registros que a su vez construyen lo que se
conoce como bases de datos.
Las bases de datos no son más que un conjunto de datos
agrupados alrededor de un concepto, o una idea (igual que las
clases). Si bien las estructuras se parecen, estas no son iguales y a
veces esto lleva a los programadores a cometer algunos errores.
Por ejemplo, si te enfrentas a un problema que implique el
modelar el comportamiento de un alumno en un sistema de
matrícula, entonces, el modelo de la clase se podría graficar de la
siguiente forma:
Página 139 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Ahora fíjate en el modelo de la entidad que se puede crear para la
misma estructura.
Si te fijas, los dos elementos se parecen mucho en su definición, la
diferencia está en que la clase posee los métodos de la clase y
adicionalmente, la forma en que se relacionan los elementos son
distintos.
Componentes del diagrama estático
de clases.
Ahora lo que vamos a hacer es realizar un diagrama completo de
clases, para esto vamos a analizar un problema muy simple, y lo
vamos a comenzar a desmenuzar en cada una de sus parte de
forma tal que el modelo se vaya construyendo de a poco.
La liga de futbol de tu país necesita establecer el modelo de clases
para poder crear un software estadístico para llevar el control de
los partidos que se están por comenzar a jugar en la liga, además
necesita conocer los goles marcados, el goleador por equipo y cada
uno de los registros asociados a un partido de fútbol.
Debes tener presente que el proceso de análisis orientado a
objetos es un proceso iterativo incremental, es decir que debes
darle varias vueltas al asunto antes de que quede 100 por ciento
correcto, lo que no quiere decir que vayas a estar iterando
Página 140 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
eternamente, la experiencia ya te dirá cuándo es suficiente la
iteración del proceso. Lo primero es tratar de definir las clases
propuestas, que aparezcan en el modelo, para esto leemos la
definición del problema o la definición de requerimientos y
comenzamos a analizar el texto, descubriendo con esto todos los
sustantivos que aparezcan en el problema, de esta forma hacemos
un listado preliminar:
Liga.
Partidos.
Goles.
Equipo.
Ahora si te fijas bien en el listado anterior todas las clases
propuestas intervienen en el proceso que queremos modelar, si
apareciera alguna que no intervenga, entonces hay que analizar si
se justifica el que la incluyamos en el listado.
Analizando el listado vemos que podría ser posible el incluir a los
jugadores pues ellos componen los equipos y hacen los goles, por
lo tanto su inclusión en el modelo podría ser bastante necesaria.
Ahora una vez que tenemos el listado de clases candidatas debes
intentar el analizar el problema y tratar de definir qué
comportamiento van a realizar cada una de las clases que has
definido para el problema, de esta forma, podemos definir la clase
inicial para el jugador de la siguiente manera:
En el diagrama anterior podemos establecer una relación entre los
métodos de la clase y los atributos de la misma, así por ejemplo
existe un método que se llama marcarGol(), este método de forma
interna lo que hace es que modifica la cantidad de goles que ha
Página 141 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
marcado el jugador y adicionalmente disminuye la cantidad de
energía que este posee. Si durante el análisis te das cuenta que
hay un atributo que no es ocupado o algún método que nunca es
utilizado, entonces es el momento de modificarlo, pues esto
después al ser transformado en código, será trabajo extra que
tendrá que hacer el programador. Como este es un proceso
iterativo e incremental, podremos agregar o quitar tantos métodos
o atributos que consideremos que no están correctamente
asignados. Recuerda eso sí que la decisión de agregar o quitar
elementos desde el modelo no es antojadizo, es parte del proceso
de análisis que nos lleva a dejar sólo aquellos procesos que nos
son útiles para solucionar el problema, por ejemplo si analizamos a
nuestro jugador nos damos cuenta de que también come, y corre y
salta y realiza un montón de acciones, pero estas acciones no son
relevantes para el proceso que estamos estudiando, este proceso
de ignorancia selectiva se conoce como abstracción y es uno de los
procesos más importantes del diseño de clases. Este proceso de
abstracción permite que te concentres en lo realmente importante
para solucionar el problema y dejas de lado lo que no te interese.
Una vez que logres determinar la estructura aproximada de las
clases, debes documentar el comportamiento de cada una de ellas,
y agregar documentación para los atributos que esta posee, para
muestra la siguiente clase documentada.
Nombre de la clase:
Atributo 1:
Atributo 2:
Página 142 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Comportamiento 1:
Comportamiento 2:
Relaciones entre las clases.
En el mundo real, las clases no funcionan solas, sino que
establecen relaciones entre ellas, estas relaciones, permiten definir
la forma en que las clases interactúan en el mundo real cuando se
transformen en objetos. Recuerda que cuando construimos clases,
estas clases se transformarán en objetos cuando se estén
ejecutando como un software en el computador. Para clarificar
piensa en lo siguiente, tú estas definiendo las clases y las estas
documentando de forma tal de poder definir el comportamiento de
las clases y sus características. Por otro lado un programador va a
tomar esta definición y la documentación que tú desarrolles y va a
construir un software donde estas clases se transformaran en
archivos de código. El compilador del lenguaje de programación va
a tomar estos archivos y los va a compilar y a ejecutar, eso
significa que el código fuente cuando se ejecute se va a guardar en
la memoria RAM del computador y cada uno de los objetos que allí
se creen, van a ser una instancia de una clase. Es decir cuando
pasamos de la clase a la construcción “física” del objeto entonces
estamos hablando de la instancia de una clase y por lo tanto
podemos asegurar que un objeto es la instancia de una clase.
Los objetos deben colaborar unos con otros para solicitar a otras
clases que realicen operaciones que ellos por si solos no pueden
Página 143 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
realizar, ahora te preguntarás ¿Por qué no puedo tener un solo
objeto que haga todo?, la respuesta es simple, los objetos
compuestos son difíciles de arreglar cuando están malos y además
son muy costosos de producir, piensa en lo siguiente, si se te echa
a perder el monitor de tu computador, ¿cambias el computador
completo o sólo el monitor? Si te fijas en este caso, es más barato
cambiar el monitor que el computador completo y adicionalmente
para la fábrica es más barato producir sólo monitores que los
computadores completos, lo mismo sucede con casi todos los
objetos que ves a diario y con los cuales interactúas, estos están
compuestos de otros objetos, pues es más fácil remplazar y
construir las partes específicas de cada una. Por lo tanto para
lograr un objetivo mayor, un objeto solicita a otro objeto que
realice una acción mediante la comunicación utilizando mensajes,
estos mensajes permiten que los objetos colaboren y así los
objetos pueden lograr especificidad y hacerse especialistas en una
o varias operaciones. Por ejemplo el delantero hace goles como
función principal, pero además también puede quitar la pelota
como el defensa, el defensa a su vez, puede quitar a la pelota y
hacer goles, pero cada uno de ellos cumple una función de mejor
forma, así cuando uno de ellos se lesiona es cambiado por otro que
realiza la misma función.
En el diagrama de clases es posible ilustrar estas relaciones
mediante una línea que une cada una de las clases, y
adicionalmente según el tipo de relación que se establece, también
se pueden agregar algunos otros elementos que permitan aclarar
la relación que se establece entre las clases.
Página 144 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Básicamente la relación que se establece entre dos objetos tiene
que ver con la comunicación que estos establecen, así un objeto se
comunica con otro o colabora con otro objeto cuando le solicita
que realice una acción para la cual él no fue creado pero que
necesita, por ejemplo, cuando utilizas el control remoto para
prender o cambiar el canal de la televisión, lo que estas haciendo
es utilizar una función que está implementada en el control remoto
(controlar las funciones del televisor de forma remota) , como tu
no puedes prender el televisor ni cambiar los canales de forma
remota, necesitas de la ayuda o colaboración del control remoto
para poder realizar la tarea.
De esta forma los objetos colaboran y establecen relaciones entre
ellos. Ahora no siempre todos los objetos colaboran entre sí, y es
posible que un objeto colabore sólo con otro objeto, eso sí,
siempre los objetos colaboran con al menos uno.
Si te fijas a tu alrededor, todo lo que ves son objetos compuestos
de varios otros objetos que están colaborando unos con los otros.
Fíjate por ejemplo en tu computador, en la lavadora o la cocina de
tu casa, en el cuadro que está colgado en a pared, en el reloj que
llevas, en la ropa que tienes puesta, cada uno de esos objetos esta
compuesto de otros objetos cuya colaboración permite que el
objeto exista, pregúntate lo siguiente ¿Qué es un teclado sin
teclas?, ¿Qué hago con un computador sin monitor?, ¿De qué me
sirve un auto sin ruedas?
Como a veces las relaciones que se establecen entre los objetos
son muy complejas, se han establecido categorías o tipos de
relaciones que permiten diferenciar los tipos de relaciones
Página 145 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
existentes, pues aunque no lo creas existen distintos tipos de
relaciones entre los objetos, las cuales definiremos a continuación.
Asociación.
La relación de asociación, se define cuando una clase se asocia con
otra para lograr un objetivo, este tipo de relación es el más básico,
en este caso cada una de las clases tiene una instancia de la otra.
El conector puede incluir el nombre del rol en cada uno de los
extremos, la cardinalidad, la dirección de la relación y las
restricciones. Veamos el siguiente ejemplo:
Vamos a describir ahora en qué consiste cada una de las partes
que componen el ejemplo anterior.
El conector es la línea que permite establecer que existe una
relación entre las clases. Fíjate que el conector adicionalmente
puede tener el nombre del rol de esa clase en esa relación. Por
ejemplo en determinado momento tu estableces en tu casa varios
roles en función de con quién te relaciones, si te relacionas con tus
hermanos, tu rol es el de hermano, si te relacionas con tus padres
tu rol es el de hijo, la importancia de definir bien el rol radica en el
conjunto de comportamientos que implementas para esa relación
en particular.
Página 146 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
La dirección de la relación permite establecer cual es la clase que
genera las instancias de la otra clase.
Las restricciones son básicamente anotaciones con instrucciones o
con características que no pueden ser escritas en el diagrama de
otra forma. Las restricciones suelen encerrarse entre llaves {},
como en el siguiente ejemplo:
Multiplicidad.
La cardinalidad o multiplicidad en una relación establece el grado y
nivel de dependencia, de esta forma podemos determinar que
existen varios tipos de cardinalidad:
Asociación uno a uno (1..1): En una relación de asociación uno
a uno, ésta es en ambas direcciones, por lo mismo los objetos de
ambas clases están asociados sólo a un objeto de la otra clase, por
ejemplo la relación de exclusividad que existe entre el gerente de
una empresa y la empresa, así el gerente sólo puede ser gerente
de una empresa y la empresa sólo puede tener un gerente.
Asociación uno a muchos(1..*): en esta relación, se produce
una relación uno a muchos en una dirección y en la otra una
relación uno a uno, por ejemplo la relación entre el héroe y la
Página 147 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
cantidad de balas que puede disparar, si te fijas en las películas de
acción los héroes poseen cargadores infinitos de balas, nunca
sabemos cuando se van a acabar. De esta forma, el héroe posee
un cargador con muchas balas (no sabemos el número exacto) y
esas balas pertenecen sólo al héroe.
Asociación numéricamente especificada(n..m): en este caso la
asociación se realiza un número de veces especificado, por
ejemplo en un equipo de voleibol, la cantidad mínima de jugadores
es 6 y la máxima 12, fíjate que las cotas mínimas y máximas están
bien definidas y no pueden ser mayores o menores es decir un
equipo no puede tener 5 o 4 jugadores como tampoco puede tener
13 o 14 pero si puede tener 8.
Asociación opcional (0..*): en este caso, la relación no establece
obligatoriedad de existencia en la relación, por ejemplo la relación
que se da entre el dueño de una cuenta de banco y las tarjetas de
crédito que este posee. No todos los dueños de las cuentas de
banco poseen tarjeta de crédito. Cabe hacer notar que la relación
que se establece del otro lado siempre es de uno a uno.
Asociación muchos a muchos (*..*): en este caso la relación se
establece entre clases con una asociación de uno a muchos en
ambas direcciones, por ejemplo la relación que se establece entre
los alumnos y las asignaturas que inscriben en el semestre, si te
fijas un alumno tiene muchas asignaturas inscritas y cada
asignatura a su vez posee muchos alumnos.
Página 148 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Asociación calificativa.
Este tipo de asociación está asociada a la relación del tipo uno es a
muchos, en el cual se requiere explicitar algún atributo que
definirá un identificador único para una clase y de esta forma
poder diferenciar cada uno de los objetos de la relación, por
ejemplo cada uno de los buses para un recorrido del Transantiago9
está asociado al recorrido con una relación del tipo uno a muchos,
para poder identificar a cada bus de forma individual ocupamos el
atributo patente del vehículo para establecer la relación. De esta
forma la asociación calificada quedaría de la siguiente forma:
Asociación reflexiva.
La asociación reflexiva se da cuando la relación se establece entre
elementos del mismo tipo, es decir la clase se relaciona consigo
misma, pudiendo establecer el rol para clarificar la relación, por
ejemplo supongamos que necesitamos establecer la relación
existente entre los trabajadores sabiendo que uno es el jefe y el
resto son empleados, si te fijas todos son empleados, pero su rol
los diferencia.
9 http://es.wikipedia.org/wiki/Transantiago
Página 149 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
Herencia.
La asociación de herencia permite que las clases que se relacionan,
lo puedan hacer en un nivel de especificidad, es decir que las
clases que se están asociando son clases iguales salvo que una de
ellas es más específica, es decir implementa más métodos o los
mismos métodos pero con una implementación distinta.
Asociación.
Existen algunos tipos especiales de asociación que veremos a
continuación, estos tipos especiales permiten representar
asociaciones más complejas.
La asociación ternaria es una asociación entre tres clases de forma
simultánea, la cual no puede ser leída o agrupada sólo de a dos
clases pues pierde el sentido. Por ejemplo se puede establecer una
relación entre artista, canción e instrumento o entre jugador,
Página 150 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
equipo y posición. En los dos ejemplos anteriores podríamos
analizar la relación de a pares pero pierde su significado o
semántica, Para establecer la relación ternaria se dibuja un rombo
entre las tres clases. Al igual que en el resto de las asociaciones,
puedes agregar características de cardinalidad a la relación.
Otra relación de asociación particular son las clases de asociación.
Una clase de asociación aquella que modela una asociación entre
dos o más clases. Los atributos de la clase de asociación son los
atributos de la asociación. En el caso de una asociación compleja
entre dos o más clases, es posible que una clase de asociación
tenga sus propios atributos, los cuales sirven para dar significado a
Página 151 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
la relación. Como ejemplo, analicemos la relación existente entre
los alumnos y las asignaturas que cursan este semestre, si
analizamos la relación, nos damos cuenta de que existe una
relación de muchos a muchos, en este caso en particular se puede
crear una clase de asociación llamada horario que permite
establecer que alumno esta asociado a que asignatura específica.
Otros tipos de relaciones son las relaciones de composición y
agregación. Estas relaciones son muy parecidas y se basan en el
concepto de que una clase es una parte del todo, por ejemplo la
lámpara se compone de un interruptor, el soquete, la ampolleta y
la pantalla, se establece una relación de uno a uno entre la clase
lámpara y sus componentes (el todo y las partes).
La agregación es un tipo de relación en dónde el todo esta
compuesto de partes pero la existencia de las partes no está
definida por la existencia del todo, por ejemplo, sabemos que los
vehículos tienen ruedas, si analizamos esta relación, sabemos que
las ruedas existen y están presentes en el modelo de forma
independiente al medio de transporte en el cual se ocupen. De esta
forma si el medio de transporte se destruye, las ruedas siguen
“existiendo” en el modelo.
La composición es un tipo de relación más fuerte que la
agregación. La composición es también una relación entre
instancias. Así los objetos que participan en la relación, nacen,
viven y mueren relacionados con el todo. A menudo las clases de
composición se asocian a relaciones físicas entre los objetos. Por
ejemplo si observas una camisa, observas que está compuesta por
un grupo de partes (mangas, bolsillo, cuello, puños) y que cada
uno establece una relación más fuerte, en este caso si la camisa se
Página 152 de 152
UNIVERSIDAD TECNOLÓGICA DE CHILE INACAP - ÁREA INFORMÁTICA Y TELECOMUNICACIONES
destruye, la utilidad de la manga o del cuello se pierden pues su
existencia tiene significado sólo cuando es parte de una camisa.
La distinción entre las relaciones de composición y agregación es
muy sutil y a menudo conlleva acalorados debates y discusiones
respecto a cuando es una u otra, generando conflictos insolubles
entre hermanos, amigos y parejas, al punto de devolverse las
cartas y los peluches regalados.
Realización.
Una relación de realización esta dada por una clase y una interfaz.
En orientación a objetos, una clase de interfaz es una clase que
define el comportamiento de una clase pero jamás la implementa,
esto que parece tan complejo lo podemos definir como una clase
que es un cascaron sin código por dentro. Te estarás preguntando
¿Y para que quiero tener una clase que no hace nada y que no
tiene código?, la respuesta no es simple pero lo podemos explicar
mediante un ejemplo.
Supongamos que estas creando un video juego y debes crear las
clases de tu juego, si te fijas los objetos de la pantalla se están
moviendo, pero la nave se mueve en función de las teclas que
presiones en el teclado o de los botones del joystick que presiones,
mientras que las balas se desplazan siguiendo una trayectoria que
no se puede cambiar, ambos objetos se desplazan pero lo hacen
de forma distinta, por lo tanto como ambos poseen el mismo
método (mover) pero los dos lo hacen de forma distinta entonces
se crea una clase de interfaz que posea el método y como este
método o comportamiento no se programa, le da la libertad a las
clases que heredan de esta clase de interfaz a que lo implementen
de forma independiente.