Uml - Ioo

TEMA 3
COMUNICACIÓN EN EL
DESARROLLO DE SISTEMAS
Dr. José Ignacio Peláez Sánchez

E.T.S.I. Informática de Sistemas. 3er Curso. Año 2004/2005
Conceptos y Principios del Análisis
La ingeniería de requisitos del software es un proceso de
descubrimiento, refinamiento, modelado y especificación.
Se refinan en detalle los requisitos del sistema y el papel
asignado al software.
Se crean modelos de los requisitos de datos, flujo de
información y control, y del comportamiento operativo.
Se analizan soluciones alternativas y el modelo completo
del análisis es creado.
José Ignacio Peláez Sánchez

Universidad de Málaga 2 de 224
Departamento de Lenguajes y Ciencias de la Computación
Ingeniería de Requisitos
La ingeniería de requisitos es el uso sistemático de
procedimientos, técnicas, lenguajes y herramientas para
obtener con un coste reducido, el análisis, documentación,
evolución continua de las necesidades del usuario y la
especificación del comportamiento externo de un sistema
que satisfaga las necesidades del usuario. Tenga en
cuenta que todas las disciplinas de la ingeniería son
semejantes, la ingeniería de requisitos no se guía por
conductas esporádicas, aleatorias o por modas pasajeras,
si no que se deben basar en el uso sistemático de
aproximaciones contrastadas.

Tanto el desarrollador como el cliente tienen un papel
activo en la ingeniería de requisitos del software – un
conjunto de actividades que son denominadas análisis.
El cliente intenta replantear un sistema confuso, a nivel de
descripción de datos, funciones y comportamiento, en
detalles concretos.
El desarrollador actúa como un interrogador, como
consultor, como persona que resuelve problemas y como
negociador.

El análisis y la especificación de los requisitos puede
parecer tarea sencilla, pero no es así.
El contenido de comunicación es muy denso.
Abundan las ocasiones para las malas interpretaciones o
falta de información. Es muy probable que haya
ambigüedad.
El dilema al que se enfrenta el ingeniero se puede resumir
con la siguiente frase de un cliente anónimo:
“Sé cree que entendió lo que piensa que dije, pero no
estoy seguro de que se dé cuenta de que lo que escuchó
no es lo que yo quise decir”

Identificación de Requisitos
Antes que los requisitos puedan ser analizados,
modelados o especificados, deben ser recogidos a través
de un proceso de obtención.
Recogida de Información.
z Inicio del proyecto (Entrevistas).
z Proyecto Iniciado (prototipos, equipos de trabajo, etc).
z Técnicas de recogida.
z Lenguaje de representación.


Inicio del Proyecto
Al principio de un proyecto de software las cosas siempre están un
poco borrosas.
Se ha definido una necesidad y se han enunciado las metas y
objetivos básicos, pero todavía no se ha establecido la información
necesaria para definir el ámbito.
El analista y el cliente deben establecer un primer contacto.
Las preguntas en el primer contacto deben ser de contexto libre y
sirven para romper el hielo entre el analista y el cliente.
El primer conjunto de cuestiones de contexto libre se centran en el
cliente, en los objetivos globales y en los beneficios.

Inicio del Proyecto. Preguntas
Primer conjunto de preguntas. Centradas en el cliente, los
objetivos generales y los beneficios esperados.
Ejemplos de preguntas:
z ¿Quién esta detrás de la solicitud de este trabajo?
z ¿Quién utilizará la solución?
z ¿Cuál será el beneficio económico del éxito de una solución?
z ¿Hay alguna otra alternativa para la solución que necesita?

Segundo conjunto de preguntas. Su objetivo es que
podamos obtener un mejor entendimiento del problema y
que el cliente pueda comentar sus opiniones sobre la
solución.
z ¿Cómo caracterizaría una salida (resultado) generada para una
buena solución?.
z ¿A qué tipo de problema(s) va dirigida esta solución?.
z ¿Puede mostrarme o describirme el entorno en que se utilizará la
solución?.
z ¿Hay aspectos o restricciones especiales del rendimiento que
afecten a la manera de enfocar la solución?.

Tercer conjunto de preguntas. Estas preguntas se
concentran en la eficacia de la reunión.
z ¿Es usted la persona adecuada para responder a estas preguntas?
¿Sus respuestas son oficiales?
z ¿Estoy preguntando demasiado?
z ¿Hay alguien más que pueda proporcionar información adicional?
z ¿Hay algo más que debería preguntarle?

Las preguntas ayudan a romper el hielo e iniciar la
comunicación tan esencial para el éxito del análisis.
Problemas. El formato de reunión tipo –
pregunta/respuesta- no es un enfoque que tenga mucho
éxito.
Este tipo de preguntas solo debe emplearse en el
encuentro(s) inicial, después se emplean otras técnicas.

z Proyecto Iniciado (prototipos, equipos de trabajo, etc). Son
técnicas enfocadas al equipo.

Proyecto Iniciado
Todas las técnicas cumplen o siguen alguna variación de las
siguientes directrices:
z La reunión se realiza en lugar neutral donde acuden los clientes y
desarrolladores.
z Se establecen normas de preparación y de participación.
z Se sugiere una agenda lo suficientemente formal como para cubrir todos
los puntos importantes, pero lo suficientemente informal como para
animar el libre flujo de ideas.
z Un coordinador que controle la reunión.
z Se usa un mecanismo de definición: pizarras, carteles, gráficos,
proyector, etc.
z El objetivo es identificar el problema, proponer elementos de solución,
negociar diferentes enfoques y especificar un conjunto preliminar de
requisitos de la solución en una atmósfera que permita alcanzar el
objetivo.

z Lenguajes de representación.

TÉCNICAS DE RECOGIDA DE
INFORMACIÓN
PARTE I
Técnicas de Recogida
Las técnicas más comunes son:
z Entrevistas (Es la más utilizada, especialmente para determinar el ámbito
del problema).
z Desarrollo Conjunto de Aplicaciones (JAD).
z Prototipado.
z Tormenta de Ideas.
z Observación.
z Estudio de Documentación.
z Cuestionarios.
z Despliegue de la Función de Calidad (DFC).
Estas técnicas se Técnicas para Facilitar las
denominan
Especificaciones de la aplicación (TFEA) (Facilitated Application
Specification techniques)

Entrevistas
Características.
z Es la técnica más empleada.
z Mayor preparación por parte del analista.
Cualidades del Entrevistador.

z Imparcial. No se debe mostrar interés por ningún tema en concreto, pues el
cliente puede sentirse reacio y no facilitar alguna información necesaria.
z Ponderado. No exceder el tiempo de preguntas y preguntar lo justo para no
cansar al cliente.
z Buen oyente. Debe escuchar con interés y adaptarse al ritmo de conversación.
z Habilidad en el trato.
z Cordialidad y accesibilidad.
z Paciencia.

Entrevistas. Modelo de Preparación
IDENTIFICATIVO
FASE
IDENTIFICACIÓN
FECHA DE PREPARACIÓN
LUGAR DE PREPARACIÓN
DURACIÓN
PARTICIPANTES
FECHA A REALIZAR
PREPARACIÓN
LUGAR HORA
DURACIÓN PREVISTA
PERSONAL A QUIEN SE REALIZA
CARGO DEL PERSONAL
OBJETIVOS
CONTENIDO
PREGUNTAS

Entrevistas. Modelo de Desarrollo
IDENTIFICATIVO
ENTREVISTA A LA QUE PERTENECE
IDENTIFICACIÓN
FECHA DE REALIZACIÓN
PERSONAL QUE LA REALIZA
PREPARACIÓN
DURACIÓN
PARTICIPANTES
CONTESTACIONES
CONCLUSIONES CONTENIDO
GRADO DE SATISFACCIÓN
INCIDENCIAS CON LOS INCIDENCIAS

PARTICIPANTES

Técnicas de Recogida de Información
Desarrollo Conjunto de Aplicaciones (JAD).
z Se crean equipos de usuarios y analistas que se reúnen para
trabajar conjuntamente con el objetivo de determinar las
características que debe tener el software.
z Tiene mayor probabilidad de éxito ya que involucra al usuario en
el proyecto, y de esta forma lo aprecia como algo propio.
Prototipado.
Tormenta de Ideas.

Observación.
z Consiste en analizar in situ como funciona el sistema.
z Tiene la ventaja de captar el funcionamiento real de la empresa.
Estudio de Documentación.
z Se estudia la información existente en la empresa o sistema.
Cuestionarios.
z Son de utilidad para recoger información de un gran número de
personas en poco tiempo o existe una gran dispersión geográfica.

Despliegue de la Función de Calidad (DFC).
z Es una técnica de gestión de calidad que traduce las necesidades del
cliente en requisitos técnicos del software.
z Desarrollada en Japón y aplicada en la Industria Mitsubishi.
z DFC hace énfasis en entender lo que resulta importante para el cliente.
z Identifica tres tipos de requisitos:
9 Requisitos normales. Se declaran los objetivos y metas en una reunión con el
cliente. Si estos requisitos están presentes el cliente esta satisfecho.
9 Requisitos esperados. Estos sin implícitos al sistema, y el cliente no siempre
los declara.
9 Requisitos innovadores. Son características que van más allá de las
expectativas del cliente y suelen ser muy satisfactorias.

TÉCNICAS DE MODELADO
PARTE II
Introducción a la
Orientación a Objetos

Organización del Capítulo
Introducción.
Conceptos sobre Orientación a Objetos.
Uso de la Orientación a Objetos.
Uso de relaciones.
Agregación, composición, interfaces y
realización.

Introducción
La orientación a objetos ha tomado por asalto el mundo
del software.
Principal ventaja para el desarrollo de software:
z Fomenta el uso de componentes ª Reuzabilidad del código ª
Menor tiempo de desarrollo.
La orientación a objetos es un paradigma que depende de
unos principios fundamentales (abstracción, herencia, ... )
Un objeto es una instancia de una clase.
Una clase es una categoría genérica de objetos que tienen
los mismo atributos y acciones.

Conceptos
Abstracción. Consiste en quitar las propiedades y
acciones de un objeto para dejar sólo aquellas que sean
necesarias.
Herencia. Un objeto hereda los atributos y operaciones
de su clase. Una clase también puede heredar atributos y
acciones de otra.
Polimorfismo. Una acción puede tener el mismo nombre
en diferentes clases y cada clase ejecutará tal operación
de forma distinta.

Conceptos
Encapsulamiento. Los objetos ocultan su funcionalidad
de otros objetos y del mundo exterior. Cada objeto
presenta una interfaz para que otros objetos (y personas)
puedan aprovechar su funcionalidad.
Envio de Mensajes. Los objetos funcionan en conjunto
mediante el envío de mensajes entre ellos. Los mensajes
son peticiones para realizar operaciones.
Mensaje listo para imprimir

Conceptos
Asociaciones. Los objetos se asocian entre sí y esta
asociación puede ser de diversos tipos:
z En una dirección:
Encender
z En dos direcciones:
Matrimonio

Conceptos
z Asociaciones en mas de una forma:
Es colaborador de
Es amigo de
z Con más de una clase:

Viaja en
Viaja en

Conceptos
Agregación. Es un tipo de asociación. Un objeto
agregado consta de un conjunto de objetos que lo
componen y una composición es un tipo especial de
agregación. En un objeto compuesto, los componentes
sólo existen como parte del objeto compuesto.

Uso de la Orientación a Objetos

Concepción de una Clase
Una clase se representa mediante un rectangulo.
El nombre de la clase, por convención, es una palabra con
la primera letra en mayuscula, que es colocada en la parte
superior del rectangulo.
Lavadora

Concepción de Clase
Un paquete es la manera en que el UML organiza un
diagrama de elementos.
Electrodomesticos
Si la clase lavadora es parte de un paquete llamado

electrodomésticos. Esta clase se conoce como nombre de
ruta:
Electrodomesticos::Lavadora

Atributos
Un atributo es una propiedad o característica de una clase
y describe un rango de valores que la propiedad podrá
contener en los objetos (instancias) de la clase.
Una clase podrá contener varios o ningún atributo.
Por convención si el atributo consta de una palabra se
escribe en minuscula; si consta de dos palabras, la
primera en minuscula y, la segunda concatenada a la
primera pero comenzando por mayúscula.

Atributos
Lavadora
marca
modelo
Una clase y sus atributos numeroSerie
capacidad

Atributos
Todo objeto de la clase tiene un valor especifico en cada
atributo.
miLavadora:Lavadora
marca=“LG”
modelo=“7800”
numeroSerie=“LG5674”
capacidad:7
Una instancia anónima, se representa como :Lavadora.

Atributos
El UML permite información adicional en los atributos.
También permite valores predeterminados.
Lavadora
marca:string=“LG”
modelo=string
numeroSerie=string
capacidad:integer

Operaciones
Una operación es algo que la clase puede realizar, o que usted (u otra
clase) pueden hacer con la clase.
El nombre de las operaciones se escribe en minuscula si tiene una
palabra y en caso de tener dos palabras la segunda se concatena
comenzando por mayuscula.
Lavadora
marca modelo
numeroSerie capacidad
agregarRopa()
sacarRopa ()
agregarDetergente()
activar()

Operaciones
En las operaciones también es posible añadir información adicional.
En los paréntesis que preceden al nombre de la operación podrá
mostrar el parámetro con el que funcionará la operación, junto con el
tipo de dato que regresará la función
Lavadora
marca modelo
La información acerca numeroSerie capacidad
de una operación se
agregarRopa(C:string)
conoce como Firma
sacarRopa (C:String)
de la Operación:
agregarDetergente(D:Integer)
activar():Boolean

Atributos, Operaciones y Concepción
En la práctica, no siempre mostrará todos los atributos y operaciones
de una clase, ya que el diagrama podría aparecer muy saturado. Este
proceso donde se suprimen de forma total o parcial los atributos u
operaciones se denomina abreviar una clase.
Cuando se muestrán de forma parcial se colocan tres puntos
suspensivos.
Lavadora
Lavadora marca
...
agregarRopa
...

Se podrá usar un estereotipo para organizar una lista de
atributos u operaciones.
El UML permite este tipo de agrupaciones tanto en los
atributos como en las operaciones para facilitar el
desarrollo.
Esto es una forma de extender el lenguaje, creando
nuevos elementos que son específicos de un problema.

Lavadora
<<info identificación>>
marca modelo numeroSerie
<<info máquina>>
capacidad
<<relacionado con la ropa>>

agregarRopa()
sacarRopa ()
agregarDetergente()
<<relacionado con la máquina>>
activar()

Responsabilidades
La responsabilidad es una descripción de lo que hará la clase, es
decir, lo que sus atributos y operaciones intentan realizar en
conjunto.
Lavadora
marca
...
agregarRopa
...
Recibe ropa sucia y

devuelve ropa limpia

Restricciones
Una restricción es un texto libre bordeado por llaves, que
especifica una o varias reglas que sigue la clase.
Lavadora
marca modelo
numeroSerie capacidad {capacidad=7, 8 o 9 kg}
sacarRopa (C:String)
agregarDetergente(D:Integer)
Restringe el atributo a tomar
activar():Boolean
uno de estos tres valores

Responsabilidades y Restricciones
El UML funciona con otra forma – aún más formal – de agregar
restricciones que hacen más explícitas las definiciones. Es todo un
lenguaje conocido como OCL (Lenguaje de restricciones de objetos).
OCL cuenta son su propio conjunto de reglas, términos y operadores,
lo que lo convierten en una herramienta avanzada y, en ocasiones,
útil

Notas Adjuntas
Una nota adjunta proporciona mayor información respecto
a la clase.
Una nota puede contener tanto una imagen como texto.
Lavadora
marca
Vease la norma de
modelo
Industria E234x para
numeroSerie la generación de
números de serie.
capacidad
...

Cómo Encontrar las Clases
Las clases son el vocabulario y terminología de un área del
conocimiento.
En las conversaciones con los clientes preste atención a los
sustantivos que utilizan para describir las entidades de sus negocios,
ya que dichos sustantivos se convertirán en las clases.
Los verbos constituirán las operaciones de sus clases.
Los atributos serán sustantivos relacionados con los nombres de las
clases.
Una vez que tengamos una lista básica de las clases, pregunte a los
clientes que hacen dentro de su negocio. Las respuestas serán las
responsabilidades de la clase.

Ejemplo
Juego del baloncesto

Ejemplo
Analista: Entrenador ¿En qué consiste el juego?
Entrenador: Consiste en lanzar el balón a través de un aro, conocido como
cesto, y hacer una mayor puntuación que el oponente. Cada equipo consta de
cinco jugadores: dos defensas, dos delanteros y un central. Cada equipo lleva
el balón al cesto del equipo oponente con el objetivo de hacer que el balón
sea encestado.
Analista: ¿cómo se hace para llevar el balón al otro cesto?.
Entrenador: Mediante pases y dribles. Pero el equipo tendrá que encestar
antes de que termine el tiempo para tirar.
Analista: ¿Tiempo para tirar?
Entrenador: Así es, son 24 segundo en los partidos de profesionales, 30
segundos en los internacionales y 35 en los colegiales. El tiempo comienza a
contar desde que el equipo toma posesión del balón.
Analista: ¿cómo funciona la puntuación?

Ejemplo
Entrenador: Cada canasta vale dos puntos, a menos que el tiro haya
sido detrás de la línea de tres puntos. En tal caso, serán tres puntos.
Un tiro libre contará como un punto. A propósito, un tiro libre es la
penalización que paga un equipo por cometer una infracción. Si un
jugador infracciona a un oponente, se detiene el juego y el oponente
puede realizar diversos tiros al cesto desde la línea de tiro libre.
Analista: Hábleme más acerca de lo que hace cada jugador.
Entrenador: Quienes juegan de defensa son, en general, quienes
realizan la mayor parte de los dribles y pases. Por lo general tiene
menor estatura que los delanteros, y éstos, a su vez, son menos altos
que el central (que también se conoce como pivot). Se supone que
todos los jugadores pueden burlar, pasar, tirar y rebotar. Los
delanteros realizan la mayoría de los rebotes y los disparos de
mediano alcance, mientras que el central se mantiene cerca del cesto
y dispara desde un alcance corto.

Ejemplo
Analista: ¿Qué hay de las dimensiones de la pista?. Y ya que
estamos en eso. ¿cuánto dura el juego?.
Entrenador: En un juego internacional, la pista mide 28 metros de
longitud y 15 de ancho; el cesto se encuentra a 3.05 metros del piso.
En un juego profesional, el juego dura 48 minutos, divididos en cuatro
tiempos de 12 minutos. En un juego colegial e internacional, la
duración es de 40 minutos, divididos en cuatro tiempos de 10
minutos. Un cronómetro del juego lleva un control del tiempo
restante.
....
....

Ejemplo
Sustantivos:
z Balón, cesto, equipo, jugadores, defensas, delanteros, pivot, tiro, tiempo
para tirar, línea de los tres puntos, tiro libre, infracción, línea de tiro libre,
pista, cronómetro del tiempo.
Información de algunos sustantivos:
z Estatura de los jugadores, dimensión de la pista, tiempo de posesión del
balón de cada equipo, duración del juego.
Verbos:
z Tirar, avanzar, driblar (o burlar), pasar, infracción, rebotar.
Información implícita:
z Por ejemplo información acerca de los atributos del balón (volumen,
diámetro).

Ejemplo. Diagrama de Clases
Balón Jugador Defensa
Diámetro Nombre, estatura

volumen peso
driblar( ) driblarBalon( ) Realiza la mayor parte

del drible y pase
tirar( ) tirarBalon( )
pasar( ) pasarBalon( )
avanzar( ) rebotar( )
infraccionarOponente( )

Delantero Pivot
Realiza la mayor parte Permanece cerca del

de los tiros de media cesto. Tira de una
distancia y rebotes distancia cercana.

Equipo Cesto Infracción
Tiro Tirolibre LíneaDeTresPuntos
Pista LíneaDeTiroLibre

{profesional = 24 segundos.
LapsoDeTiro Colegial = 35 segundos.
Internacional = 30 segundos.
{profesional = 24 segundos.
CronometroDeJuego Colegial = 35 segundos.
Internacional = 30 segundos.
{profesional = 48 minutos.
Duracion Colegial e internacional = 40 minutos.

Uso de Relaciones

Uso de Relaciones
En el ejemplo anterior hemos construido las clases, pero,
¿falta algo?.
La respuesta es Si. Falta como se relacionan entre si las
clases.
Ahora vamos a ver las conexiones entre las clases:
z Asociaciones.
z Multiplicidad.
z Asociaciones calificadas.
z Asociaciones reflexivas.
z Herencia y generalización.
z Dependencias.

Asociaciones
Las asociaciones es la forma conceptual en que se
conectan las clases.
La asociación se representa con un nombre significativo
seguido de una flecha que indica la dirección de la
asociación.
Participa en
jugador Equipo

Asociaciones
Cuando una clase se asocia con otra, cada una de ellas
juega un papel dentro de tal asociación.
Dicho papel se representa escribiéndolo junto a la clase.
Participa en
jugador Equipo
Empleado Empleador

Asociaciones
La asociación puede funcionar en dirección inversa.
Participa en
jugador Equipo
Emplea
Las asociaciones pueden ser más complejas, conectando

varias clases. Parti
c
Defensa ipa e
n
Equipo
Delantero art i ci p a en
P

Restricciones en las Asociaciones
En ocasiones una asociación entre dos clases debe seguir
cierta regla. Ésta se indica al establecer una restricción
junto a la línea de asociación.
{ordenado}
Atiende
Cajero Cliente
Esta asociación indica que el cajero atiende al cliente

siguiendo el orden de llegada.

Restricciones en las Asociaciones
Otro tipo de restricción es la relación O (distinguida por
{Or}) en una línea discontinua que conecte a dos líneas
de asociación.
Elige Académico
Estudiante de
educación {Or}
superior Elige
Comercial
El estudiante puede elegir entre ambas especialidades.

Clases de Asociación
Una asociación, al igual que una clase, puede contener
atributos y operaciones.
Cuando éste sea el caso, tendremos una clase de
asociación.
Participa en
jugador Equipo
Negociado por
Contrato Director
General

Vinculos
Un vinculo es la instancia de una asociación. Conecta a los
objetos en lugar de las clases. Deberá subrayar el nombre
del vínculo, como se hace en el nombre de un objeto.
Participa en
Nacional:Equipo
herreros:jugador

Multiplicidad
La multiplicidad señala la cantidad de objetos de una clase
que pueden relacionarse con un objeto de una clase
asociada.
Participa en
5 1
Jugador Equipo
La asociación indica que:

z Un jugador puede partipar en un equipo.
z Un equipo tiene cinco judadores sin contar con los reservas.

Multiplicidades en UML
Esta casado
1 1
Esposo esposa
enseña
1 *
Maestro Estudiante
atiende
1 1..*
Cajero Cliente

Multiplicidad en UML
tiene
1 0,1
Casa chimenea
enseña
1 12..18
estudiante créditos
tiene
1 3
triciclo ruedas

Asociaciones Calificadas
Cuando la multiplicidad de una asociación es de uno a muchos, con
frecuencia se presenta el problema de buscar. Por ejemplo, cuando
hacemos la reserva de un hotel, para preguntar por dicha reserva
disponemos de un localizador o número de confirmación.
En UML la información para realizar la búsqueda se denomina
calificador.
1 localiza *
Recepcionista Número de confirmación Reserva

Asociaciones Reflexivas
En ocasiones, una clase es una asociación consigo misma. Por
ejemplo, un ocupante de automovil puede ser conducto o pasajero.
Una asociación reflexiva, trazará la línea de la clase hacia sí misma y
podrá incluir los papeles, nombre de la asociación y su dirección, así
como su multiplicidad.
1 OcupanteDeAutomovil
conductor
conduce
0..4 pasajero

Herencia o Generalización
En UML la Herencia es denominada Generalización.
En la generalización, una clase secundaria (hija) es sustituible por una
clase principal (madre). Es decir, donde quiera que se haga referencia
a la clase madre, también se hace referencia a la clase hija. Sin
embargo, en el caso contrario no es aplicable.
Cuando una clase no proviene de una clase principal, se denomina
clase base o raíz.
Cuando una clase no tiene clases secundarias se denomina clase hoja.
Si una clase tiene exactamente una clase principal, tendrá herencia
simple, mientras que tiene más de una será una herencia múltiple.

Herencia o Generalización
Una jerarquía de herencia en el reino animal.
Animal
Anfibio Mamifero Reptil
caballo

Clases Abstractas y Dependencia
Las clases abstractas son aquellas que no proveen objetos. Se
distinguen por tener su nombre en cursiva.
Cuando una clase utiliza a otra, se dice que existe una dependencia.
Una flecha representada por una línea discontinua con una punta de
flecha en forma de triángulo sin relleno simboliza una dependencia.
Sistema
Formulario
mostrarFormulario()

Agregación, Composición ....
En las siguientes secciones continuaremos con las
relaciones entre clases.
z Agregaciones.
z Composiciones.
z Contextos.
z Interfaces y realizaciones.
z Visibilidad.

Agregaciones
En ocasiones una clase consta de otras clases. Éste es un tipo
especial de relación conocida como agregación o acumulación.
Una asociación por agregación se representa por una línea entre el
componente y el todo con un rombo sin relleno que conforma un
todo.
Ordenador
Cpu Monitor Ratón

Restricciones en las Agregaciones
En ocasiones el conjunto de componentes posibles en una agregación
se establece dentro de una relación O. En ciertos lugares de comida
rápida, una comida consta de sopa o ensalada, y un plato fuerte.
Puede establecer una restricciones a una agregación para mostrar
que un componente u otro es parte del todo.
Comida
(O)
Sopa Ensalada PlatoFuerte

Composiciones
Una composición es un tipo muy representativo de una agregación.
En una composición, cada componente pertenece solamente a un
todo. Un rombo relleno representa esta relación.
MesaDeCafe
1
1 4
Tablero Pata

Contextos
Cuando se modela un sistema puede producirse, con
frecuencia, agrupamientos de clases, como agregaciones
o composiciones. En tal caso, deberá enfocar su atención
en un agrupamiento o en otro.
El diagrama de contexto proporciona la característica de
modelaje que se requiere para tal fin. Las composiciones
figuran en gran medida dentro de los diagramas de
contexto.
Un diagrama de contexto es como un mapa detallado de
alguna sección de un mapa con mayores dimensiones.
Pueden ser necesarias varias secciones para capturar toda
la información detallada.

Diagrama de Contexto y Composición
Un diagrama de contexto de composición le muestra los
componentes de una clase como un diagrama anidado
dentro de un enorme rectángulo de clase.
Un diagrama de contexto del sistema le muestra los

componentes de una clase y la forma en que la clase se
relaciona con las otras que hay en el sistema.

Diagrama de Contexto de Composición
esta cosida en
Camisa 1
2 2 esta cosido en
Manga Talle Cuello
1 1
1
esta cosida en
esta cosida en 1 5,6 esta cosida en
0,2,3
Botonadura
1 1
1 se abotona en 1
Boton Ojal

Diagrama de Contexto del Sistema
Guardarropa
esta cosida en esta cosido en
Camisa
1
2 2
1 * Manga
1
Talle
1
Cuello
1
* esta cosida
esta cosida en 1
5,6 en esta cosida en
0,2,3
Slacks Botonadura
1 1
1 1 1
1 se abotona en 1
1 Boton Ojal
Atuendo

Interfaces
Una vez que haya creado varias clases, tal vez se dé cuenta que no
pertenecen a una clase principal, pero en su comportamiento debe
incluir operaciones de una clase principal.
¿Podría codificar las operaciones en una clase y reutilizarlas en otras
clases?
La interfaz es la estructura del UML que le permite hacerlo.
Una interfaz es un conjunto de operaciones que especifica cierto
aspecto de la funcionalidad de una clase, y es un conjunto de
operaciones que una clase presenta a otras.
Por ejemplo. El teclado del computador es una interfaz reutilizable, ya
que proviene de las máquinas de escribir, aunque este represente un
subconjunto de operaciones respecto a un teclado de computador.

Interfaces y realización
La interfaz se modela del mismo modo que una clase, con un símbolo
rectángulo. La diferencia radica en que la interfaz no tiene atributos.
¿cómo se distingue una interfaz de una clase?:
z Especificar la palabra <<interfaz>>;
z Colocar la letra “I” al principio del nombre de una interfaz.
La relación entre una clase y una interfaz se conoce como realización.

Esta relación se representa como una línea discontinua con una punta
de flecha en forma de triángulo sin rellenar que adjunte y apunte a la
interfaz.

Interfaz
Teclado
<<interfaz>>
marca
MaquinaDeEscribir
cantidad de teclas
Ctrl() Teclazo()
Alt()
RePag()

Representación Omitida de Interfaz
MaquinaDeEscribir
Teclado

Visibilidad
El concepto de visibilidad esta muy ligado con las interfaces y la
realización.
La visibilidad se aplica a atributos u operaciones, y establece la
proporción en que otras clases podrán utilizar los atributos y
operaciones de una clase dada.
Existen tres niveles de visibilidad:
z Nivel público. La funcionalidad se extiende a otras clases.
z Nivel protegido de funcionalidad. Este se otorga sólo a las clases que se
heredan de la clase original.
z Nivel privado. Sólo la clase original puede utilizar el atributo u operación.

Visibilidad
Por ejemplo en una televisión, modificarVoluven() y cambiarCanal()
son operaciones públicas, en tanto que dibujarImagenEnPantalla() es
privada.
En un automóvil, acelerar() y frenar() son operaciones públicas, pero
actualizarKilometraje() o actualizarMillaje() es protegida.
La realización implica que el nivel público se aplique a cualquier
operación en una interfaz.
Para indicar el nivel:
z Público. Anteceder el atributo u operación con el signo +.
z Protegido. Anteceder con el simbolo #.
z Privado. Anteceder con el simbolo -.

Visibilidad
Television
+ marca
+ modelo
+ modificarVolumen()
- colorearImagenEnPantalla()

Ámbito
Es otro concepto referente a los atributos y operaciones, y la forma
en que se relacionan dentro de un sistema.
Dos tipos de ámbitos:
z Instancia. Cada instancia cuenta con su propio valor en un atributo u
operación.
z Archivado. Solo habrá un valor del atributo u operación en todas las
instancias de la clase.
Un atributo u operación con el ámbito de archivador, aparece con su
nombre subrayado.
El ámbito de instancia es, por mucho, el tipo más común del ámbito.

Objetivo de las Relaciones
La meta de las relaciones es

crear una visión estática del
sistema con todas las conexiones
entre las clases que lo
conforman.

Lenguajes Unificado de
Modelado: UML

Organización
Definiciones y términos.
Por qué es necesario UML.
La concepción de UML.
Diagramas de UML.
Para que tantos diagramas.
Taller
UML = Lenguajes Unificado de Modelado.

Definiciones y Términos
Sistema: Combinación de Software, hardware y gente
que da una solución a un problema de negocios.
Desarrollo de sistemas: Creación de un programa para
un cliente.
Analista: Persona que documenta el problema del cliente
y lo comunica a los desarrolladores.
Desarrolladores: Programadores que generan el
problema que resuelve el problema y lo distribuyen en
equipos de computación.

Por Qué es Necesario UML
El desarrollo de sistemas es una actividad humana.
Importancia de la comunicación: usuario, analistas,
desarrolladores, otros.. .
El diseño de sistemas complejos obliga a disponer de
herramientas que permitan planificar el trabajo.
z Ejemplo. Los planos de un arquitecto.
Tradicionalmente el diseño de sistemas ha sido una
aventura, donde no existía un lenguaje común para todos
los actores (cliente, analista, desarrolladores) que
participaban en el desarrollo de un producto.
UML pretende ser el lenguaje o notación para el desarrollo
de sistemas.

La Concepción del UML
El UML es la creación de Grady Booch, James Rumbaugh
e Ivar Jacobson.
Cada uno de estos tres personajes tenia su propia
metodología para el análisis y el diseño orienta a objetos.
Se crea un consorcio cuando se aprecia su utilidad.
z DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas
instruments, Rational.
Primera versión en 1997.

Diagramas del UML
UML está compuesto por diversos elementos gráficos que
se combinan para conformar diagramas.
Dispone de reglas para conformar dichos elementos.
La finalidad de los diagramas es presentar diversas
perspectivas de un sistema , a las cuales se les conoce
como Modelo.
UML otorga formas de organizar y extender dichos
diagramas.
Los diagramas serán mostrados siguiendo el ejemplo de
una lavadora.

Diagrama de Clases
Una clase es una categoría o grupo de cosas que tienen atributos y
acciones similares.
Nombre Lavadora
Marca
Atributos Modelo
Capacidad
Abrir ()
Acciones
Cerrar ()
Meter_Ropa ()
Sacar_Ropa ()
Un diagrama de clases está formado por varios rectángulos de este

tipo conectados por líneas que muestran la manera en que las clases
se relacionan entre sí.

Diagrama de Objetos
Un objeto es una instancia de una clase.
Nombre de Nombre de
la Instancia
Mi Lavadora: Lavadora la Clase
Un objeto puede estar formado de otros objetos.

Diagrama de Casos de Uso
Un caso de uso es una descripción de las acciones de
un sistema desde el punto de vista del usuario.
Es una técnica de aciertos y errores para obtener los
requerimientos del sistema desde el punto de vista del
usuario.
Su finalidad es crear un sistema que pueda ser utilizado
por la gente en general y no por expertos en
computación.

Diagrama de Casos de Uso
Diagrama:
Actor
Caso de Uso
Lavar Ropa
El actor puede ser una persona u otro sistema.

Diagrama de Estados
Un objeto se encuentra en un estado en particular, el diagrama de
estados es el encargado de capturar esa realidad.
Inicio Fin
Remojo Lavado Enjuague Centrifugado

Diagrama de Secuencias
Los diagramas de clases y objetos representan información estática.
No obstante, en un sistema funcional los objetos interactúan entre sí,
y tales interacciones suceden en el tiempo.
El diagrama de secuencias UML muestra la mecánica de la interacción
con base en tiempos.
Continuando con el ejemplo de la lavadora, entre los componentes se

encuentran: una manguera de agua, un tambor y un sistema de
drenaje.
Si suponemos que hemos añadido la ropa, el detergente y hemos
activado la lavadora la secuencia sería la siguiente:

Secuencia de Acciones
1. El agua empezará a llenar el tambor mediante una manguera.
2. El tambor permanecerá inactivo durante cinco minutos.
3. La manguera dejará de abastecer agua.
4. El tambor girará de un lado a otro durante quince minutos.
5. El agua jabonosa saldrá por el drenaje.
6. Comenzará nuevamente el abastecimiento de agua.
7. El tambor continuará girando.
8. El abastecimiento de agua se detendrá.
9. El agua el enjuague saldrá por el drenaje.
10. El tambor girará en una sola dirección y se encrementará su
velocidad por cinco minutos.
11. El tambor dejará de girar y el proceso de lavado habrá finalizado.











Diagrama de Secuencias
Manguera de Agua Tambor Drenaje
Abastecimiento de Agua
Permanecer Inmovil
Deternerse
Girrar de un Lado a Otro
Vaciar el Agua
Reabastecer de Agua
Girrar de un Lado a Otro
Vaciar el Agua
Detenerse
Girrar en un Solo Sentido
Detenerse

Diagrama de Actividades
Las actividades que ocurren dentro de un caso de uso o dentro del
comportamiento de un objeto se dan, normalmente, en secuencia,
como el diagrama de secuencias.
Girar el tambor de un lado a otro 15”
Vaciar el Agua Jabonosa
Reiniciar Abastecimiento Agua

Diagrama de Colaboraciones
Los elementos de un sistema trabajan en conjunto para cumplir con
los objetivos del sistema.
Cronometro Interno 1:Deternerse
Manguera de Agua
Girar de un lado a otro

Luego de cierto tiempo, el
TamborT conómetro detendrá el flujo de
agua y el tambor comenzará a
girar.
Diagrama de Componentes
El desarrollo actual del software utiliza componentes.
UML representa los componentes software como sigue:
Componente

Diagrama de Distribución
El diagrama de distribución UML muestra la arquitectura
física de un sistema informático. Puede representar los
equipos y dispositivos, mostrar interconexiones y el
software que se encontrará en cada máquina.
Las computadoras se representan mediante cubos.
Las interacciones entre las computadoras están

representadas por líneas que conectan a los cubos.

Diagrama de Distribución
Procesador Pentium 7.
Servidor
Procesador Pentium 2 Procesador Motorola

Otras Características
UML proporciona características que le permiten organizar
y extender los diagramas.
Para ello dispone de:
z Paquetes.
z Notas.
z Estereotipos

Paquetes
En algunas ocasiones es necesario organizar los
elementos de un diagrama en un grupo. Tal vez queramos
mostrar que ciertas clases o componentes son parte de un
subsistema en particular.
Paquete 1
Clase 1
Clase 2 Clase 3

Notas
Es frecuente que alguna parte del diagrama no presente
una clara explicación del porqué está allí o la manera en
que trabaja. Cuando éste sea el caso la nota UML será
útil.
Devuelve una copia del objeto receptor

Estereotipos
De vez en cuando necesitamos elementos hechos a
medida.
Los estereotipos o clisés permiten tomar elementos de
UML y convertirlos a otros.
Ejemplo. Una interfaz es una clase que realiza
operaciones y no tiene atributos, es un conjunto de
acciones que tal vez quiera utilizar una y otra vez en su
modelo.
z En lugar de inventar un nuevo elemento para representar una
interfaz, podrá utilizar el símbolo de una clase con <<Interfaz>>
situado justo sobre el nombre de la clase.

Para qué tantos Diagramas
Los diagramas UML permiten examinar el sistema desde
diferentes puntos de vista.
Un sistema por lo general implica diferentes personas,
que tiene enfoques particulares en diversos aspectos del
sistema.
El diseño de un sistema involucra todas las posibles
perspectivas, y el diagrama UML le da una forma de
incorporar una perspectiva en particular. El objetivo es
satisfacer a cada persona implicada.

Taller. Cuestionario
¿Porqué es necesario contar con diversos diagramas en el
modelo de un sistema?
¿Cuáles diagramas le dan una perspectiva estática de un

sistema?
¿Cuáles diagramas de dan una perspectiva dinámica de

un sistema, es decir, muestran el cambio progresivo?

Soluciones. Cuestionario
1. Cualquier sistema cuenta con usuarios con intereses
distintos. Cada tipo de diagrama UML presenta una idea
que podrá ser comprendida por cualquiera de los
usuarios.
2. Los diagramas de clases, objetos, componentes y
distribución.
3. Los diagramas de casos de uso, estados, secuencias,
actividades y colaboraciones.

EJEMPLOS

Ejemplo 1 de Clases
Enunciado:
z Se pide diseñar una aplicación que describa la situación en una
casa en la que viven cinco animales; una ballena llamada ‘Moby
Dick’ que no dice nada, un perro fiero llamado ‘Caín’ que ladra, un
perro manso llamado ‘Abel’ que ladra0, un pingüino llamado
‘Adela’ que no dice nada y un loro que habla.

Ejemplo de Clases
Identificación de clases:
z Lista de sustantivos:
9 Casa, perro, animal, pingüino, ballena y loro.
z Eliminación de sustantivos no significativos:
9 CasaÆ hace referencia al lugar en el que se describe la situación y no
aporta nada.
z Identificación de clases adicionales
9 La introducción de las clases Mamífero y Ave ayudará a la
organización del modelo de clases y, por tanto, a la comprensión del
sistema.

Ejemplo de Clases
Identificación de atributos:
z Se identifica una propiedad de la clase Perro que indica que sus objetos
pueden ser fieros o manso, la denominamos Agresividad y será privado
puesto que no tiene porqué conocerse externamente.
Identificación de operaciones:
z En el enunciado se hace referencia a que los perros ladran y el loro habla.
En este caso las operaciones serán públicas ya que se conocen
externamente.

Ejemplo de Clases
Representación del diagrama de clases:
Animal
Mamífero Ave
Perro Loro
Ballena Pingüino
-Agresividad
+Ladrar +Hablar

Ejemplo 2 de Clases
Enunciado:
z Se desea diseñar un sistema de reserva de vuelos que permita al usuario hacer
consultas y reservas de vuelos además de poder comprar billetes de forma remota,
se desea que sea accesible desde la web. Para poder utilizar el sistema es
necesario identificarse en la pantalla principal, antes hay que haberse registrado
(email como login y contraseña). Las consultas de vuelos se pueden hacer por
horarios, tarifas o buscar información de un vuelo concreto en cuanto a plazas
disponibles, o cumplimiento del horario. La búsqueda puede incluir preferencias
como fecha, horario, categoría del asiento o aerolínea. Es posible reservar un
itinerario compuesto por varios vuelos o por un vuelo directo para uno o más
pasajeros. La compra consiste en la adquisición de billetes dada una reserva de
vuelo y una tarjeta de crédito válida (su número), éstos pueden ser enviados al
cliente o recogidos directamente en el mostrador del aeropuerto. Además de las
operaciones antes descritas, el usuario podrá acceder a su registro para leerlo,
modificarlo o cancelarlo. Existe un operador encargado del mantenimiento del
sistema, pero su labor se pospone para futuras entrevistas.

Ejemplo de Clases
9 Sistema de reserva de vuelo, sistema, usuario, consulta, reserva,
vuelo, billete aéreo, pantalla principal, email, login, contraseña,
registro, consulta de vuelos, reserva de vuelos, asiento, tarjeta de
crédito, billete, preferencia, búsqueda, fecha, horario, web,
mostrador del aeropuerto, número de tarjeta de crédito, compra de
billetes, horario de vuelos, tarifa de vuelos, información de vuelos,
aerolínea, aeropuerto, tarifa, información, categoría de asiento, vuelo
directo, cliente, itinerario, pasajero, compra, operador, entrevista.

Ejemplo de Clases
z Eliminación de sustantivos:
9 Clases redundantes
8 Se elimina cliente (usuario), consulta de vuelo (consulta), reserva de
vuelo (reserva), compra de billete (compra), billete (billete aéreo),
sistema de reservas de vuelo (sistema de reservas), tarifa de vuelo
(tarifa), vuelo directo (vuelo), horario (hora), fecha (día), login (email).
9 Clases irrelevantes:
8 mostrador del aeropuerto, billete aéreo, entrevista.
9 Clases imprecisas:
8 sistema, actividad, preferencia, búsqueda, información, acceso, itinerario.
9 Renombramiento de clases
8 horario (hora), fecha (día), aeropuerto (ciudad).

Ejemplo de Clases
9 Atributos:
8 número de tarjeta de crédito (de tarjeta de crédito), categoría de
asiento (de asiento), información de vuelo (de vuelo), horario de
vuelo (de vuelo).
9 Operaciones:
8 compra, reserva, consulta.
9 Clases de Interfaces de usuario:
8 pantalla principal.
9 Clases del sistema completo:
8 sistema de reserva.
9 Actores:
8 usuario, operador (en realidad no se trata).

Ejemplo de Clases
z Clases adicionales:
9 Se introduce pasajero como clase puesto que es mucho más
específica que usuario (o su equivalente cliente) que quedará
identificado como actor, email y contraseña pasarán a ser un atributo
de esta nueva clase y registro se considera equivalente a pasajero.
También se introduce la clase avión que ha sido omitida en el
enunciado aunque quizá pueda interpretarse en algún punto del
mismo como sinónimo de vuelo. Finalmente se introduce la clase
activa pago que constará de atributos como la fecha y la cantidad y
que se realizará siempre con tarjeta de crédito.
z Lista definitiva de sustantivos:
9 reserva, vuelo, aerolínea, aeropuerto, tarifa, asiento, día, hora,
pasajero, avión, pago, tarjeta de crédito.

Ejemplo de Clases
Identificación de relaciones entre clases:
z Reserva de vuelos. (‘El vuelo contiene reservas’, ‘El pasajero tiene
reservas’, ‘El pasajero posee tarjeta de crédito’)
z Asientos en un vuelo.(‘El vuelo contiene asientos’)
z Fecha y horario de un vuelo.(‘El vuelo tiene fecha y hora’)
z Aerolínea deseada.(‘El vuelo pertenece a una aerolínea’)
z Tarifa de vuelo.(‘El vuelo tiene tarifas’)
z Itinerario de vuelos.(‘El vuelo se compone de un itinerario’)

Ejemplo de Clases
Diagrama de clases (primera aproximación):
1..* Salida 1 1..* Origen 1
1..* Llegada 1 1..* Escalas 1..*
Día Vuelo Aeropuerto
1
1..* 1..* 1..* 1

Destino
Se supone que una Conexión
conexión pertenece a
un único vuelo
Pertenece
Aerolínea
1
Día 1 1 Hora

Ejemplo de Clases
Diagrama de clases (segunda aproximación):
1..* I/V 1..* 1..* Escalas 1..*

Tarifa Vuelo Avión
1 1..*
Reserva Pertenece
1..* 1
Asiento Aerolínea

Ejemplo de Clases
Diagrama de clases (tercera aproximación):
1..* 1..* 1 1..*

Vuelo Reserva Pago
1..* 1..*
Si una reserva se puede
pagar con varias tarjetas
le corresponden varios
pagos distintos
Realiza
1..* 1..*
1 1..*
Pasajero Tarjeta

Ejemplo de Clases
Identificación de atributos en las clases definitivas:
Vuelo Aeropuerto Aerolinea Avion Asiento
- Numero - Ciudad - Nombre - Compañía - Fila

- Pais - Tipo - Letra
- NumPasajeros
Reserva Pago Tarjeta Pasajero Tarifa
- Clave - Tipo - Nombre - Nombre - Clase

- CostoTotal - Fecha - Numero - Direccion - Precio
- Cantidad - Tipo - Ciudad - Impuestos
- Fecha - Pais
- Vencimiento - CodPostal
- TelefonoCasa
- TelefonoOficina
- Fax
- Email
- Contraseña

Ejemplo de Clases
Diagrama de clases definitivo:
1 1..*
Posee
Aerolinea Avion Aeropuerto
1
- Nombre - Compañía - Ciudad
- Tipo - Pais
- NumPasajeros 1 1 1..*
1..* Destino Origen Escalas
Le pertenece Conexión
Es realizado por
1..* 1..*
Reserva Pago
1..* 1
Vuelo 1..* 1 Tiene 1..*
1..* Es destino - Clave - Tipo
1..* I/V 1..* - Numero 1..* Es origen - CostoTotal - Fecha
Tarifa 1..* - Cantidad
1..* Hace escalas
1 1 1 1..*
1..*
- Clase Hace
- Precio Contiene Realiza
Sale Llega
- Impuestos
1..* 1..*
Pasajero Tarjeta
Contiene - Nombre - Nombre

Salida Llegada - Direccion 1 Posee 1..*
1..* - Numero
1..* 1..* - Ciudad - Tipo
Asiento 1 Tiene 1 - Pais
Día Hora - Fecha
- CodPostal - Vencimiento
- Fila - TelefonoCasa
- Letra - TelefonoOficina
- Fax
- Email
- Contraseña

Ejemplo 3 de Clases
Enunciado:
z El dueño de un restaurante desea realizar de forma automática las
reserva de mesas, la gestión de pedidos, la solicitud de los pedidos a la
cocina y la solicitud de suministro de ingredientes a los almacenes. La
reserva de mesas puede llevarse a cabo por teléfono o mediante un
terminal de reserva ubicado en la calle. Estos terminales, provistos de un
plano del restaurante, proporcionan la ventaja de poder elegir la mesa
en función de su ubicación. Las mesas están separadas en mesas de
fumador y de no fumador y llevan un indicador del número de personas
para el que están pensadas. Para hacer la reserva el usuario selecciona la
mesa que desea, si es fumador, el número de personas que la ocuparán y
el día y hora para el que desea hacer la reserva, el sistema comprueba
que la mesa cumpla todos los requisitos, incluido estar libre, en caso
afirmativo se realiza la reserva que será válida hasta pasados veinte
minutos de la hora fijada. Una vez pasado ese tiempo la mesa volverá a
estar libre.

Ejemplo de Clases
Enunciado:
z Si un cliente llega al restaurante y no tiene reserva, bien porque no la hizo o bien
porque superó el tiempo de retraso, el encargado buscará una mesa en función de
las preferencias del cliente. Si no hay ninguna mesa libre con esas características el
sistema debe proporcionar un estimación del tiempo que resta para que quede
libre una mesa con esas características. El tiempo aproximado se calculará en
función del estado en el que se encuentren las distintas mesas; libre, reservada,
ocupada, pidiendo, en espera de comida, servidos, esperando cuenta y pagando.
Una vez los clientes están a la mesa se les toma nota. Los camareros disponen de
unos dispositivos que controlan los pedidos dentro del sistema. El camarero
introduce en primer lugar el número de la mesa, quedando grabada la hora en la
que se realizaron los pedidos, y posteriormente el pedido, cada bebida o comida se
identifica con un código. Los dispositivos permiten solicitar los ingredientes de un
determinado plato a petición del cliente. Cada solicitud de consumición (comida o
bebida) constituye una línea de pedido.

Ejemplo de Clases
Enunciado:
z Cuando el camarero introduce el código de una consumición el sistema no le
permite introducir la siguiente hasta comprobar que se dispone de los ingredientes
necesarios para hacer frente al pedido. Una vez cerrado el pedido, aunque
posteriormente se podrá volver a abrir, el camarero pulsa el botón de fin y el
sistema avisa a la cocina de la existencia de un nuevo pedido compuesto por las
distintas líneas de pedido. Se recorren los ingredientes de cada línea de pedido y
se disminuye la cantidad de cada uno en la cocina de modo que si se supera el
umbral mínimo para un determinado ingrediente se realice una petición automática
al almacén. El encargado de cocina, cuando los platos están listos, establece el
pedido como cocinado y manda un mensaje al camarero para que lo recoja, el
camarero lo lleva a la mesa correspondiente e indica que la mesa está servida.
Cuando terminan de comer los clientes solicitan la cuenta, momento en el cual el
camarero cierra definitivamente el pedido y establece el estado de la mesa como
esperando nota. Una vez entregada, los clientes pagan, mesa pagando, el
camarero vuelve con la nota cobrada y establece la mesa como libre.

Ejemplo de Clases
9 Dueño, restaurante, reserva, mesa, pedido, solicitud consumición,
bebida, comida, plato, cliente, teléfono, terminal reserva, día, hora,
plano, número personas, persona, camarero, dispositivo,
consumición, jefe cocina, código, ingredientes, línea pedido, nota,
cocina.
9 Clases redundantes:
8 Persona (cliente), línea pedido (consumición).
9 Clases irrelevantes:
8 Dueño, nota, cocina, plato, teléfono, terminal reserva, plano.
9 Atributos:
8 Numero personas, código.

Ejemplo de Clases
9 Operaciones:
8 Solicitud consumición.
9 Clases del sistema completo:
8 Sistema.
9 Actores:
8 Camarero, jefe cocina.
z Lista definitiva de sustantivos:
9 Cliente, reserva, mesa, pedido, restaurante, consumición, ingrediente,
bebida, comida.

Ejemplo de Clases
Identificación de relaciones entre clases:
z Un cliente reserva una o varias mesas, un mesa es reservada por uno o
varios clientes.
z Reserva es una asociación ya que su existencia está condicionada a la
relación entre cliente y mesa.
z Una mesa puede tener o no un pedido.
z Una mesa pertenece a un restaurante y restaurante posee muchas
mesas.
z Un pedido está formado por consumiciones, relación de agregación.
z Una consumición puede ser una comida o una bebida, herencia en la que
Consumición es la superclase y Comida y Bebida las subclases.
z Una consumición está formada por ingredientes, relación de agregación.

Ejemplo de Clases
Diagrama de clases (primera aproximación):
Hace reserva Pertenece
Cliente Mesa Restaurante
1..* 1..* 1..* 1
1
Tiene
0..1
Clase
Pedido
Asociación
Reserva
1..*
1..*
Consumición Ingrediente
Bebida Comida

Ejemplo de Clases
Identificación de atributos y operaciones en las clases definitivas:
Reserva
-Nombre - NumMesa - Nombre
- Fecha
- Fumador - Plano
- Hora
- NumPersona - Telefono
- NumPersonas
- Estado
- Ubicación + crearReserva
+ obtenerDatosMesa
Pedido Consumición Ingrediente
- Hora - Codigo - CantidadDisponible

- Precio - CantidadMinima

Ejemplo de Clases
Diagrama de clases definitivo:
Pertenece
Hace reserva
-Nombre - NumMesa - Nombre
1..* 1..*
- Fumador 1..* 1 - Plano
- NumPersona - Telefono
- Estado
- Ubicación
Clase
Asociación + obtenerDatosMesa
1
Tiene
Reserva
0..1 Consumición Ingrediente
- Fecha Pedido 1 1..* 1 1..*
- Hora - Codigo - CantidadDisponible
- NumPersonas - Hora - Precio - CantidadMinima
+ crearReserva
Bebida Comida

Ejemplo 1 de Diagrama de estados
Enunciado:
z Se quiere automatizar el conjunto de procesos relacionados con un
restaurante; reservas, pedidos de cada mesa y control de cantidad de un
ingrediente en el almacén (reposición del mismo en caso de ser
necesario). Se realizará mediante unos terminales que permitan elegir la
mesa en función de su ubicación en el restaurante. Las mesas se separan
en mesas de fumador y de no fumador y tienen un indicador del número
de personas para el que están pensadas. Cuando un cliente llega a un
restaurante puede tener reserva o no, en caso afirmativo debe presentar
el ticket de reserva cuya validez expira pasados veinte minutos de la hora
fijada en la reserva. Si el cliente cumple las condiciones la mesa pasa de
libre a ocupada, en caso contrario la mesa una vez superados los veinte
minutos de reserva pasará de reservada a libre.

Ejemplo de Diagrama de estados
Enunciado:
z En caso de que el cliente no tuviera reserva o hubiera incumplido las
condiciones de la misma reiniciaría el proceso con el encargado de
reservas, si no hubiera mesas libres el encargado deberá obtener el
tiempo aproximado que resta para que alguna mesa quede libre en
función del estado de las diferentes mesas. Las mesas pueden presentar
los siguientes estados; libre (nadie la ha reservado), reservada (es objeto
de una reserva y no se ha cumplido el tiempo de reserva), ocupada (ya
hay comensales a la mesa), pidiendo (el camarero está tomando nota en
esa mesa), en espera (los clientes esperan a que se les sirva), servidos
(el pedido ya está en la mesa), esperando cuenta (los comensales han
pedido la cuenta) y pagando (los clientes ya disponen de la cuenta).

z Mesa.
Identificación de estados:
z Libre.
z Reservada.
z Pidiendo.
z Esperando.
z Servidos.
z Esperando cuenta.

Descripción de transiciones entre estados:
z Cuando el restaurante abre las mesas se encuentra libres, bajo
esta condición pueden ser reservadas. Una mesa reservada puede
ser ocupada en el plazo fijado o quedar libre una vez superado
dicho plazo. La mesa puede ocuparse desde cualquiera de los
estados anteriores, libre o reservada, por un nuevo cliente o por el
cliente que realizó la reserva respectivamente. Un vez ocupada se
realiza el pedido, estado pidiendo, tras lo cual habrá que esperar a
su preparación, estado espera, en este estado es posible ampliar
el pedido. Una vez servido el pedido se pasa al estado servidos
durante el cual también es posible ampliar el pedido. Una vez
terminada la comida se pide la cuenta, estado esperando cuenta,
tras su recepción se paga y la mesa vuelve a estar libre. Esta
secuencia se repite cíclicamente hasta que cierra el restaurante.

Diagrama de estados de la clase mesa:
Inicio
Abre el restaurante Se realiza reserva
Libre Reservada
Pasan 20 minutos
Cierra el de la hora fijada Clientes ocupan la mesa
restaurante Clientes
ocupan la Solicitud de
mesa comida terminada
Pidiendo Espera
Fin Cuenta pagada
Nueva solicitud de
comida
Comida servida
Nueva solicitud
de comida
Esperando
Servidos
cuenta Comida finalizada

Ejemplo 2 de Diagrama de estados
Enunciado:
z Se pretende diseñar un sistema para venta de productos por
Internet de forma que el cliente pueda consultar el catálogo de
productos y efectuar varias operaciones sobre los mismo. Se dará
la posibilidad al cliente de visualizar los productos en tres
dimensiones y se le dejará liberta para determinar aspectos como
el color, las dimensiones, etc... en tiempo real. Por supuesto, el
sistema también ofrece la posibilidad de hacer pedidos y seguir su
evolución. Cuando el cliente accede al sistema el escenario en el
que se visualizan los productos seleccionados estará vacío y se irá
llenando conforme seleccionen nuevos productos. Las
posibilidades de manipulación son la rotación, el cambio de
dimensiones y el cambio de posición.

z Pedido.
z Escena.
z Objeto3D.
Identificación de estados:
z Escena vacía.
z Escena no vacía.
z Colocando objeto en cesta.
z Borrando objeto 3D.
z Objeto 3D seleccionado.
z Cambiando Color/Textura.
z Objeto 3D manipulado.

Descripción de transiciones entre estados:
z Cuando se enciende el sistema la escena permanecerá vacía hasta
que se añada un producto, paso a escena no vacía. Cuando hay
un objeto seleccionado se pueden realizar dos acciones; borrarlo,
estado borrando objeto 3D, añadirlo a la cesta tal cual, colocando
objeto en cesta, o modificarlo antes de añadirlo a la cesta, objeto
3D seleccionado. A un objeto seleccionado se le pueden realizar
modificaciones, cambiando color/textura, o enviarlo a la cesta,
colocando objeto en cesta. Si se modifica el objeto seleccionado,
tras cambiar el color, cambiando color/textura, se pasa a
manipularlo, objeto 3D manipulado. Se podrá rotar, redimensionar
o cambiar de posición el objeto seleccionado. Una vez modificado
el objeto se vuelve al estado objeto 3D seleccionado y se decide si
se va a modificar de nuevo o si se envía a la cesta
definitivamente.

Diagrama de transición de estados: Añadir Objeto 3D
Inicio
Iniciar Sistema Añadir Objeto 3D
Escena No
Escena Vacía
Vacía
Enviar objeto a
Número de cesta
Apagar Sistema
Objetos > 0
Número de Seleccionar
Objetos = 0
Borrar Objeto Objeto 3D Colocando
Objeto en Cesta
Borrando
Fin Objeto 3D Objeto 3D Enviar objeto a cesta
Seleccionado
Seleccionar Cambiar color o textura

Objeto 3D
Objeto 3D Cambiando
Manipulado Manipular Color/Textura

Ejemplo 1 de Diagrama de secuencias
Enunciado:
z Se pretende desarrollar una herramienta que facilite al doctor la asignación de
dietas a los pacientes, MAD (Módulo Automatizado de Dietética). El MAD podrá
consultar información sobre los pacientes (historial clínico), las enfermedades y los
posibles tratamientos (dietas). Para ello, el MAD cuenta con un módulo
subordinado que recibe las solicitudes, DIETAS, encargado de definir las dietas
para el MAD. Pasos para la realización de diagnósticos y tratamientos:
1. Un gestor de solicitudes, GS, solicita al MAD un tratamiento proporcionándole como
única información el paciente a tratar.
2. El MAD obtiene su historial clínico, si el paciente está adscrito al servicio de Nutrición, en
caso contrario se genera una excepción y se informa la MAD y al GS, dándose por
finalizada la petición.
3. Para cada enfermedad reflejada en el historial el MAD emite una solicitud a DIETAS.
4. En base a las peticiones de dieta que recibe, DIETAS solicita información de todos los
alimentos asociados con los nutrientes cuyo déficit provocan la enfermedad a tratar,
generando posteriormente la dieta más apropiada.

Ejemplo de diagrama de secuencias
Enunciado:
z El MAD, una vez recibida todas las dietas aconsejadas por DIETAS para
todas las enfermedades reflejadas en el historial, las readapta para dar
lugar a una dieta final que envía al GS.

Ejemplo de Diagrama de secuencias
Identificación del actor que desencadena la secuencia:
z Gestor de Solicitudes (GS).
Identificación de clases participantes:
z Pasos:
1. El GS solicita un tratamiento para un paciente concreto al MAD.
2. El MAD solicita el historial clínico del paciente. Clase HistorialClínico.
3. Si el paciente está registrado, HistorialClínico devuelve los datos al MAD.
4. Para cada enfermedad reflejada en el historial el MAD envía a una clase Enfermedad una
solicitud de los datos asociados a ésta.
5. Una vez obtenidos los datos de todas las enfermedades el MAD envía a la clase Dietas
una solicitud de dietas.
6. Dietas envía una solicitud a la clase Nutrientes para conocer los nutrientes cuya ausencia
provoca las enfermedades tratadas.
7. Una vez recibidos los nutrientes, Dietas elabora la dieta adecuada y se la envía al MAD.
8. MAD revisa la dieta y la envía al GS.

Ejemplo de Diagrama de secuencias
Diagrama de secuencias:
:MAD :HistorialClinico :Enfermedad :Dietas :Nutrientes
:GestorSolicitudes
Solicitar tratamiento
Solicitar historial clínico
Datos historial clínico
Solicitar enfermedades
Enfermedades a tratar
Solicitar dieta
Solicitar nutrientes
Fuentes alimenticias
Dieta recomendada
Dieta final revisada

Ejemplo 1 de Diagrama de actividades
Enunciado:
z Ejemplo de las dietas.
Misma especificación

Ejemplo de Diagrama de actividades
Diagrama de actividades:
1:Solicitar tratamiento 2:Solicitar historial clínico

:HistorialClinico
:MAD
10:Dieta final revisada 3:Datos historial clínico
:GestorSolicitudes
6:Solicitar dieta
9:Dieta recomendada
5:Enfermedades a tratar
4:Solicitar enfermedades
:Dietas
7:Solicitar nutrientes
:Enfermedad 8:Fuentes alimenticias
:Nutrientes

Casos de Uso

Organización del Capítulo
Introducción a los casos de uso.

Diagramas de casos de uso.
Ejemplos.

Introducción
Los diagramas vistos en capítulos precedentes muestran
una visión estática de los sistemas. Éstos ayudan a que un
analista se comunique con un cliente.
Ahora se van a presentan los diagramas que proporcionan
una visión dinámica del sistema. Éstos ayudan a que un
analista se comunique con un grupo de desarrolladores.
Pero, ¿los clientes y los desarrolladores son todos los
participantes?

Introducción
Los diagramas vistos en capítulos precedentes muestran
una visión estática de los sistemas. Éstos ayudan a que un
analista se comunique con un cliente.
Ahora se van a presentan los diagramas que proporcionan
una visión dinámica del sistema. Éstos ayudan a que un
analista se comunique con un grupo de desarrolladores.
Pero, ¿los clientes y los desarrolladores son todos los
participantes?
No. Faltan los usuarios.
Los casos de uso son los encargados de modelar el uso
del sistema, haciendo que éstos sean fáciles de usar,
divertidos, incluso operativos.

Qué son los Casos de Uso
Cuando vamos a comprar por ejemplo una máquina de
fax, ¿qué hacemos para comprarla?, la respuesta es
simple, que es lo que necesitamos hacer.
Cuando hacemos una compra, no compulsiva, realizamos
un análisis de casos de uso.
Este tipo de análisis es particularmente crucial para la fase
de análisis del desarrollo de un sistema.

Importancia de los Casos de Uso
Los casos de uso son una excelente herramienta para
estimular a que los usuarios potenciales hablen, de un
sistema, desde sus propios puntos de vista.
La idea es involucrar a los usuarios en las etapas iniciales
del análisis y diseño del sistema. Esto aumenta la
probabilidad de que el sistema sea de mayor provecho
para la gente a la que supuestamente ayudará, en lugar
de ser un manojo de expresiones de computación
incomprensibles e inmanejables por los usuarios finales.

Definición de Caso de Uso
Un caso de uso establece un conjunto de

escenarios para realizar algo útil para un
actor.

Casos de Uso
Cuando realizamos un análisis de casos de uso, no nos
preocupamos por la forma de implementarlo. Tan solo nos
preocupamos de cómo el sistema se comportará para
alguien que tenga que utilizarlo.
El objetivo es derivar una colección de casos de uso que,
finalmente, mostraremos a las personas que diseñan y
desarrollan el sistema, de manera que el resultado sea un
sistema fácil de utilizar.

Inicio del Análisis de un Caso de Uso
Para iniciar los casos de uso seguirá un conjunto de
procedimientos:
z Entrevistas con los clientes (y entrevistas con expertos) que nos
llevarán a los diagramas de clases.
9 Esto nos dará cierta idea del área en la que trabajará y una
familiaridad con los términos que utilizará. Posteriormente,
contaremos con un fundamento para hablar con los usuarios.
z Seguidamente, entrevistaremos a los usuarios (preferentemente
en grupos) y les pediremos que nos indiquen lo que ellos harían
con el sistema que usted diseñará. Sus repuestas conformarán un
conjunto candidato de casos de uso.
9 Es importante describir brevemente cada caso de uso, además, de
una lista de todos los actores que iniciarán y se beneficiarán de los
casos de uso.

Inicio del Análisis de un Caso de Uso
Los casos de uso aparecerán en varias fases del proceso
de desarrollo. Le ayudarán con el diseño de una interfaz
del usuario, coadyuvarán con las opciones de desarrollo
de los programadores y establecerán las bases para
probar el sistema recién generado.

Representación de un Modelo
de Caso de Uso
Los casos de uso se representan por una elipse.
Una figura agregada al caso de uso representa el actor.
El actor que inicia el caso de uso se encuentra a la
izquierda mientras que el que recibe la acción se
encuentra a la derecha. El nombre del actor aparece justo
debajo de él, y el nombre del caso de uso aparece ya sea
dentro de la elipse o justo debajo de ella.
Una línea asociativa conecta a un actor con el caso de
uso, y representa la comunicación entre el actor y el caso
de uso. La línea asociativa es solida, como la que conecta
a las clases asociadas.

Representación Caso de Uso
Sistema
Caso de Uso
Actor Actor

Ejemplo
Maquina de bebidas
Comprar
gaseosa
Cliente Cliente
Reabastecer
Representante Representante
Recolectar
dinero
Recolector
Recolector
Secuencia de Pasos en los Escenarios
Cada caso de uso es una colección de escenarios y cada
escenario es una secuencia de pasos.
El uso de los diagramas de casos de uso será, por lo
general, parte de un documento de diseño que el cliente y
el equipo de diseño tomarán como referencia. Cada
diagrama tendrá su propia página, de igual manera, cada
escenario de caso de uso tendrá su propia página, donde
se listará en modo de texto a:
z El actor que inicia el caso de uso; Condiciones previas para el caso
de uso; Pasos en el escenario; Condiciones posteriores cuando se
finaliza el escenario; El actor que se beneficia del caso de uso.
z También se pueden utilizar conjeturas del escenario.

Relaciones entre Casos de Uso
Los casos de uso se pueden relacionar entre si como
sigue:
z Inclusión. Le permite volver a utilizar los pasos de un caso de uso
dentro de otro.
z Extensión. Le permite crear un caso de uso mediante la adición de
pasos a uno existente.
z Generalización. Cuenta con un caso de uso que se hereda de otro.
z Agrupamiento. Es una manera de agrupar a los casos de uso.

Inclusión
Indica que un caso de uso esta formado por otros.
La representación se hace utilizando el símbolo que usó
para la dependencia entre clases: una línea discontinua
con una punta de flecha que conecta las clases apuntando
hacia la clase dependiente. Justo sobre la línea, se
agregará un estereotipo: la palabra <<incluir>> bordeada
por dos pares de paréntesis angulares.
Un caso de uso incluido nunca aparecerá solo, ya que
simplemente funciona como parte de un caso de uso que
lo incluya.

Inclusión
Maquina de bebidas
Comprar
gaseosa
Cliente Cliente
Reabastecer
Representante Representante
Exhibir interior
<<incluir>>
Recolectar
dinero <<incluir>>
Cubrir interior
Recolector
Recolector
Extensión
El caso de uso reabastecer, podría ser la base de otro
caso de uso denominado “reabastecer de acuerdo a las
ventas”. Es decir, reabastecer la máquina con aquellas
bebidas que tienen mayor aceptación. Entonces podemos
decir que el nuevo caso de uso extiende al original dado
que agrega otros pasos a la secuencia del caso de uso
original, que se conoce como el caso base.
La extensión solo se puede realizar en determinados
puntos que son conocidos como puntos de extensión.

Extensión
Reabastecer <<incluir>> Cubrir el interior

Punto de extensión llenar
los compartimentos
<<incluir>>
Exhibir el interior
Reabastecer de acuerdo
a las ventas

Generalización
Los casos de uso pueden heredar entre si.
En la herencia de los casos de uso, el caso de uso secundario hereda
las acciones y significado del primario, y además agrega sus propias
acciones. Podemos aplicar el caso de uso secundario en cualquier
lugar donde aplique el primario.
Un caso de uso puede heredar el sentido y comportamiento de otro.
Comprar un vaso
Comprar gaseosa
de gaseosa
En este ejemplo deberá imaginar un caso de uso “comprar un vaso de

gaseosa” que se hereda de “comprar gaseosa”.

Generalización
La herencia también se puede establecer entre actores.
Agente proveedor
Reabastecedor Recolector

Agrupamiento
Cuando se dispone de varios casos de uso que se quieran
agrupar, se puede hacer mediante paquetes.
Por ejemplo, esto puede ocurrir cuando un sistema consta
de varios subsistemas. Otra posibilidad es cuando
entrevistamos a los usuarios para obtener los
requerimientos de un sistema. Cada requerimiento podría
ser representado como un caso de uso por separado.

Diagramas de Casos de Uso en el Proceso de
Análisis
Los pasos son los siguientes:
z Las entrevistas inician el proceso, generando diagramas de clases.
z Una vez que conozcamos la terminología general del área del
cliente, estamos listos para hablar con los usuarios.
z Las entrevistas iniciales darán como resultado la revelación de los
actores y casos de uso de alto nivel que describirán los
requerimientos funcionales en términos generales. Esta
información establece los confines y ámbito del sistema.
z Las entrevistas posteriores profundizarán en estos requerimientos,
que dará por resultado modelos de casos de uso que mostrarán
los escenarios y las secuencias detalladamente.

Ejemplos de Casos de Uso
Ejemplo 1 de Casos de Uso
Enunciado:
z Para el uso de los laboratorios de la facultad de
Informática será necesario poseer un carnet de
laboratorio. Los usuarios en posesión de dicho carnet
podrán pedir una llave de cualquier laboratorio para
hacer uso del mismo. El usuario que reciba una llave
deberá identificarse con su carnet de laboratorio y
dejarlo en conserjería hasta que reponga la llave,
momento en el cual se le devolverá su carnet.

Ejemplo de Casos de Uso
Casos de uso identificados:
z Petición de llave:
8 El usuario realiza una petición y, si posee carnet, recibe la llave.
Por tanto es necesario que el usuario se identifique por lo que
podemos incluir un caso de uso denominado Identificación que
compruebe la identidad del usuario.
z Devolución de llave:
8 El usuario devuelve la llave que es recibida por la conserjería.
Notar que el actor conserjería no identifica a una persona sino a
un departamento, en este caso el actor es ‘algo’ que interactúa
con el sistema.

Representación de Casos de Uso:
Petición de llave
<<incluir>>
Usuario Usuario
Identificación
Devolución
de llave
Usuario Conserjería

Enunciado:
z Se pretende crear un sistema de vigilancia permanente. El citado sistema
estará provisto por sensores capaces de detectar los siguientes eventos;
irrupciones (aperturas no autorizadas de cualquier puerta o ventana) y
accidentes (incendios e inundaciones). El administrador es la persona
encargada de la instalación de los dispositivos de alarma y su notificación.
El gestor determinará la sensibilidad de cada dispositivo así como las
acciones que desencadenará su activación, también se encarga de su
mantenimiento. El vigilante se encarga del seguimiento de todos los
dispositivos, de la atención de una alarma disparada y de la
reinicialización de los dispositivos una vez atienda dicha alarma, también
realizará simulaciones de alarmas para comprobar su funcionamiento.
Ningún usuario podrá asumir una responsabilidad que no le corresponda
ni podrá acceder al sistema sin identificarse debidamente.

Ejemplo de Casos de uso
Actores identificados:
z Administrador.
z Gestor.
z Vigilante.
Casos de Uso identificados:

z Activación/Desactivación de alarma:
8 Tanto el administrador cuando decide qué dispositivos, la
configuración de sensores de una casa en particular, como
el vigilante cuando atiende alarmas y cuando realiza
simulaciones, tienen capacidad para activar o desactivar
las distintas alarmas.

z Colocación de alarmas:
8 La
colocación de alarmas es responsabilidad del
administrador, que cómo se indicó anteriormente se
encarga de la configuración de sensores para una casa en
particular. Extendido por los casos de uso Colocar Nueva y
Colocar Existente .
z Atención de una alarma:
8 El vigilante debe atender las alarmas que se activen
actuando en consecuencia y reinicializando posteriormente
las alarmas de la casa para poder atender debidamente
otros eventos.

z Simulación de alarmas:
8 El vigilante realizará simulaciones de alarmas
periódicamente para comprobar que su estado es correcto.
z Ajuste de umbrales de activación:
8 El gestor determinará la sensibilidad de cada sensor.
z Determinación de la acción a realizar:
8 El gestor determinará la acción a realizar por el sistema
cuando se active una sensor y se dispare una alarma en
particular.
z Todos los casos de uso incluyen el caso identificación de usuario
ya que todos los usuarios deben identificarse para acceder al
sistema.

Representación de casos de uso:
Colocación de
alarmas Activación /Desactivación
Activación /Desactivación
de alarmas de alarmas
<<incluir>>
Administrador <<incluir>>
<<incluir>>
Ajuste de umbrales
<<incluir>> Identificación <<incluir>> Atención de
de activación de usuario una alarma
<<incluir>> <<incluir>>
Vigilante
Determinación de la Simulación de
acción a realizar alarmas
Gestor

Colocación
de alarmas
Administrador
<<extender>> <<extender>>
Colocar
nueva
Colocación
de las existentes

Enunciado:
z Una empresa gestiona un conjunto de inmuebles que administra en
calidad de propietaria. Cada inmueble puede ser un local, un piso o un
edificio que contenga locales y pisos. Los inmuebles se podrán dar de
alta, de baja, modificarlos o consultarlos. Los clientes deben pueden
darse de alta, de baja, modificar sus datos o consultarlos. Cada mes, el
secretario genera el recibo de cada inmueble, asimismo gestionará los
movimientos bancarios asociados a cada inmueble, éstos pueden ser un
gasto (por ejemplo reparaciones) o un ingreso (pago del recibo). Se
requiere una aplicación que cumpla los requisitos anteriores y que genere
los listados que requiera el secretario (inquilinos ordenados por fecha,
estado de los pagos...).

z Propietario.
z Inquilino.
z Secretario.

z Gestión de edificio:
9 Llevada a cabo por el propietario. Extendido por los casos de uso
Alta, Baja, Modificación y Consulta referidos a un edificio ya que
estas operaciones pueden llevarse a cabo o no.
z Gestión de local:
9 Extensión del caso de uso Gestión de edificio. Extiende los mismos
casos de uso que éste pero referidos a los locales. Se emplea la
relación extensión porque la gestión de un edificio puede conllevar o
no la gestión de un local.

z Gestión de piso:
9 Extensión del caso de uso Gestión de edificio. Extiende los mismos
casos de uso que éste pero referidos a los pisos. Se emplea la
relación extensión porque la gestión de un edificio puede conllevar o
no la gestión de un local.
z Alquilar:
9 Un inquilino procede a alquilar un inmueble. Este caso de uso es
extendido por los casos de uso Alquiler piso, Alquiler local y Alquiler
edificio ya que para los tres casos se cumple que el alquiler puede
hacer referencia a ese tipo de inmueble o no. Estos tres casos de uso
serán extendidos por el caso de uso Alta inquilino puesto que sólo
será necesario cuando el inquilino es nuevo. Independientemente del
tipo de inmueble alquilado y de si el inquilino es nuevo o no, éste
debe identificarse por lo que se incluye el caso de uso Identificar.

z Desalquilar:
9 Un inquilino deja el alquiler de un inmueble. Incluye el caso de uso
Identificación.
z Baja:
9 Un inquilino ‘borra’ sus datos. Incluye el caso de uso Identificación. No
confundir con el caso de uso referido a los inmuebles.
z Modificación:
9 Un inquilino cambia sus datos. Incluye el caso de uso Identificación. No
z Consulta:
9 Un inquilino consulta sus datos. Incluye el caso de uso Identificación. No
z Generar recibos:
9 El secretario genera los recibos de cada inmueble.

z Gestor de movimientos bancarios:
9 El secretario de la empresa gestiona los movimientos bancarios. Este
caso de uso es extendido por los casos de uso Ingresos y Gastos de
inmueble.
z Ingresos:
9 Extendido por dos casos de uso; Ingresos piso e Ingresos local.
z Gestión de informe económico:
9 Llevada a cabo por el secretario.
z Generación de listados:
9 Llevada a cabo por el secretario. Extendido por un caso de uso por
cada tipo de listado que genere. Ejemplos; Recibos pendientes y
Pagos en un año (de un inquilino).

Gestión de Inmuebles
Alta Baja Modificación Consulta

<<extender>>
<<extender>> Alta
Gestión de <<extender>>
edificio <<extender>>
<<extender>> Baja
Gestión de
<<extender>> local <<extender>>
Gestión de Modificación
Propietario
piso <<extender>> <<extender>>
<<extender>>
<<extender>> Consulta
<<extender>>
Consulta Modificación Baja Alta

Alquiler
piso Alta
Alquiler <<extender>>
inquilino
Alquilar
<<extender>> local
<<extender>>
<<extender>>
Alquiler
edificio
<<incluir>>
Desalquilar
<<incluir>>
<<incluir>>
Inquilino
Baja Identificación
<<incluir>>
Modificación
<<incluir>>
Consulta

Ejemplo de Caso de Uso
Ingresos
Generar <<extender>> piso
recibos
Ingresos <<extender>>
Gestor de
<<extender>> Ingresos
movimientos local
<<extender>>
bancarios
Gastos de
inmueble
Gestión
Informe
Secretario
económico Recibos
<<extender>> pendientes
Generación
de listados <<extender>> Pagos en
un año

Enunciado:
z Se desea desarrollar una aplicación de gestión de calificaciones. El
profesor recibe las actas en blanco, cada acta consta de los datos de una
asignatura y del listado de alumnos, y puede completarlas, añadir o
borrar un alumno e integrar varios grupos de una misma asignatura en
una sola acta. La aplicación también debe ofrecer listado de asignaturas
por alumno, estadísticas en base a las calificaciones, y permitirá otras
consultas como el porcentaje de asistencia al examen, presentando los
resultados, si se desea, en gráficos. Además proporciona una calculadora
para el cálculo de porcentajes, permite importación/exportación con MS
Excel e imprimir las actas y los listados. Se requiere también una
aplicación extra para la que es necesario identificarse como administrador
que permita la gestión de altas, bajas, modificaciones y consultas de los
datos de un alumno, la gestión de asignaturas, y la de titulaciones.
Además, esta aplicación adicional permitirá consultas sobre rechazos de
matrícula y sus motivos y sobre el historial académico de un alumno.

z Profesor.
z Administrador.
z Poner nota:
9 Lo lleva a cabo el profesor. Para la posterior generación de
estadísticas se extiende por el caso de uso Operaciones Calculadora.
Incluye el caso de uso Validar usuario.
z Operaciones Calculadora:
9 Extendido por las operaciones más comunes como Sumar, Restar o
Dividir e incluye Volcar el resultado. Incluye el caso de uso Validar
usuario.
z Gestión alumno:
9 El profesor gestionará los datos de sus alumnos, extendido por los
casos de uso Añadir y Borrar. Incluye el caso de uso Validar usuario.

z Integrar grupo:
9 El profesor une en un solo acta los datos de todos los alumnos de un grupo.
z Información alumno:
9 Se recogen los datos personales del alumno. Incluye el caso de uso Validar
usuario.
z Estadística:
9 Generación de estadísticas. Incluye el caso de uso Validar usuario.
z Gráfico:
9 Presentación de los resultados en un gráfico como alternativa a los listados.
z Importar:
9 Convertir datos en formato Excel. Incluye el caso de uso Validar usuario.

z Exportar:
9 Convertir datos a formato Excel. Incluye el caso de uso Validar
usuario.
z Imprimir:
9 Llevado a cabo por el profesor, extendido por los casos de uso
Imprimir actas e Imprimir Lista provisional cuando se imprime sólo
una lista. Incluye el caso de uso Validar usuario.
z Gestión ABMC alumnos:
9 Llevado a cabo por el administrador extendido por, como su propio
nombre indica los casos de uso Alta, Baja, Modificación, Consulta
Historial Académico. Incluye el caso de uso Validar usuario.
z Matriculación:
9 Gestionado por el administrador. Incluye el caso de uso Validar
usuario.

z Gestión Asignaturas:
9 Llevada a cabo por el administrador. Incluye el caso de uso Validar
usuario.
z Gestión Titulaciones:
usuario.
z Gestión Grupos:
usuario.

Gestión de Calificaciones
Poner notas Sumar

<<extender>>
<<extender>> Restar
<<extender>>
Operaciones
Integrar <<incluir>>
<<incluir>> Calculadora <<extender>> Dividir
grupo
Información <<incluir>> Volcar
alumno
<<incluir>> resultado
Estadística <<incluir>>
<<incluir>> Validar usuario

Gráfico
<<incluir>>
Importar
<<incluir>>
<<incluir>>
Profesor
Exportar <<incluir>>
<<extender>> Imprimir
actas
Imprimir
Añadir
<<extender>> Imprimir Lista
Gestión
Borrar provisional
<<extender>> alumno <<extender>>

Gestión de Calificaciones
<<extender>> Alta
Baja
Gestión <<extender>>
ABMC <<extender>>
Modificación
alumnos <<extender>>
Consulta
<<incluir>> Historial
Matriculación Académico
<<incluir>>
Gestión
<<incluir>>
Asignaturas Validar usuario
Administrador
<<incluir>>
Gestión
Titulaciones <<incluir>>
Gestión
Grupos

Enunciado:
z Se pretende instalar un conjunto de Puntos de Información Universitaria (PIU) a
través de los cuales se pueda facilitar información a la comunidad universitaria.
Cada PIU constará de información general (actividades), información administrativa
(plazos de matrícula...) e información privada que variará en función del tipo de
usuario; profesores o alumnos. El sistema informático que soporten los PIU’s será
utilizado por; un administrador responsable de la instalación (colocación y carga
inicial) de los PIU’s, un gestor responsable del mantenimiento de los PIU’s que
determinará la situación de cada uno (conectado/desconectado) y las acciones que
desencadenaría un mal funcionamiento (notificación, reinicialización...), un
operador responsable del control, gestión y generación de estadísticas de la red de
PIU’s y de la notificación de errores al gestor, finalmente los usuarios finales
(profesores y alumnos) acceden al sistema para realizar consultas y solicitudes.
Todos los usuarios deben identificarse y tendrán disponibles únicamente las
operaciones definidas para la categoría a la que pertenece.

z Administrador.
z Gestor.
z Operador.
z Usuario final.

z Instalación de PIU:
9 Llevada a cabo por el administrador. Extendido por los casos de uso
Instalación de PIU existente e Instalación de nuevo PIU. Incluye el
caso de uso Identificación.
z Control de funcionamiento:
9 Llevado a cabo por el gestor. Extendido por los casos de uso
Determinar acciones mal funcionamiento, Actualizar parámetro y
Observar estado/Corregir. Incluye el caso de uso Identificación.

z Gestión de red:
9 Llevada a cabo por el operador. Extendido por los casos de uso
Realizar informe, Estadísticas que a su vez incluye Configurar y
Obtener resultados. Incluye el caso de uso Identificación.
z Obtención de información:
9 Consultas realizadas por los usuarios finales. Incluye el caso de uso
Identificación.

Sistema de Información
Universitaria
Instalación de Instalación de
PIU existente nuevo PIU Obtener
Configurar resultados
Realizar
Instalación Estadísticas
<<incluir>> informe
de PIU <<extender>>
Administrador <<extender>>
Gestión Operador
Identificación <<incluir>>
de red
<<incluir>>
<<incluir>>
Control de
funcionamiento
<<extender>>
<<extender>> <<extender>> Obtención de
Gestor
información
Determinar acciones Actualizar Observar
Usuario final
mal funcionamiento parámetro estado / corregir

Enunciado:
z Se pretende diseñar un sistema informático para gestionar las
operaciones propias de un canal de televisión por cable. El sistema será
utilizado por las siguientes personas; el jefe de programación será
responsable de la elaboración de la parrilla de programación, el
responsable de los abonados gestionará las suscripciones de los
abonados así como las compras por taquilla y recibirá las reclamaciones
de éstos, el director general tomará las decisiones en base a estadísticas
de visualización de programas, de ventas y de errores en las
retransmisiones, por último, los abonados accederán desde sus casas
para realizar compras, consultas, reclamaciones o abonarse a nuevas
opciones. Todos los usuarios deben identificarse debidamente al acceder
al sistema.

z Jefe de programación.
z Responsable de abonado.
z Director general.
z Abonado.

z Gestionar abonados:
9 Gestión del censo de abonados por parte del responsable de
abonado. Extendido por los casos de uso Alta, Baja y Modificación
referentes a los datos de un abonado. Incluye el caso de uso Validar
usuario.

z Obtener estadísticas:
9 Realizado por el director general. Extendido por los casos de uso
Visualización de programa, Ventas y Errores de retransmisión. Incluye
el caso de uso Validar usuario.
z Determinación de programas:
9 Responsabilidad del jefe de programación. Extiendo por los casos de
uso Nuevo programa, Cambiar programa y Eliminar programa.
z Acceso abonado:
9 Lo realizan los usuarios. Extendido por los casos de uso Consulta,
Reclamación, Compra y Abono nueva opción. Incluye el caso de uso
Validar usuario.

Sistema de televisión
por cable
Cambiar
Modificación Nuevo
Baja programa
programa
<<extender>>
<<extender>> Eliminar
programa
Gestionar Determinación
<<extender>>
Abonados <<incluir>> <<incluir>> de programas
Alta <<extender>>
Responsable
de abonado Jefe de
Validar usuario <<extender>> Consulta programación
Obtener
Acceso abonado
estadísticas <<extender>>
Ventas <<extender>>
<<extender>>
<<extender>>
Director general
<<extender>> <<extender>> Reclamación Abonado
Errores de
Visualización Abono nueva
retransmisión Compra
de programa opción


Uml - Ioo

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uml - Ioo

Uploaded by

Copyright:

Available Formats

TEMA 3

Dr. José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 Cualidades del Entrevistador.

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

INCIDENCIAS CON LOS INCIDENCIAS

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

Dr. José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

z Con más de una clase:

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

Dr. José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 Si la clase lavadora es parte de un paquete llamado

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

 Una instancia anónima, se representa como :Lavadora.

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

<<relacionado con la ropa>>

José Ignacio Peláez Sánchez

Recibe ropa sucia y

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

Juego del baloncesto

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

José Ignacio Peláez Sánchez

Balón Jugador Defensa

Diámetro Nombre, estatura

Cualidades del Entrevistador.

Si la clase lavadora es parte de un paquete llamado

Una instancia anónima, se representa como :Lavadora.

Las asociaciones pueden ser más complejas, conectando

Esta asociación indica que el cajero atiende al cliente

El estudiante puede elegir entre ambas especialidades.

La asociación indica que:

Un diagrama de contexto del sistema le muestra los

La relación entre una clase y una interfaz se conoce como realización.

Un diagrama de clases está formado por varios rectángulos de este

Un objeto puede estar formado de otros objetos.

El actor puede ser una persona u otro sistema.

Continuando con el ejemplo de la lavadora, entre los componentes se