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

José Ignacio Peláez SánchezUniversidad de MálagaDepartamento de Lenguajes y Ciencias de la Computación

2 de 224

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.


3 de 224

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.


4 de 224


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.


5 de 224


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”


6 de 224

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.

Inicio del proyecto (Entrevistas).Proyecto Iniciado (prototipos, equipos de trabajo, etc).

Recogida de Información.Técnicas de recogida.Lenguaje de representación.


7 de 224






8 de 224

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.


9 de 224

Inicio del Proyecto. Preguntas

Primer conjunto de preguntas. Centradas en el cliente, los objetivos generales y los beneficios esperados.

Ejemplos de preguntas:¿Quién esta detrás de la solicitud de este trabajo?¿Quién utilizará la solución?¿Cuál será el beneficio económico del éxito de una solución?¿Hay alguna otra alternativa para la solución que necesita?


10 de 224


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.Ejemplos de preguntas:

¿Cómo caracterizaría una salida (resultado) generada para una buena solución?.¿A qué tipo de problema(s) va dirigida esta solución?.¿Puede mostrarme o describirme el entorno en que se utilizará la solución?.¿Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de enfocar la solución?.


11 de 224


Tercer conjunto de preguntas. Estas preguntas se concentran en la eficacia de la reunión.Ejemplos de preguntas:

¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas son oficiales?¿Estoy preguntando demasiado?¿Hay alguien más que pueda proporcionar información adicional?¿Hay algo más que debería preguntarle?


12 de 224


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.


13 de 224



Inicio del proyecto (Entrevistas).Proyecto Iniciado (prototipos, equipos de trabajo, etc). Son técnicas enfocadas al equipo.



14 de 224

Proyecto Iniciado

Todas las técnicas cumplen o siguen alguna variación de las siguientes directrices:

La reunión se realiza en lugar neutral donde acuden los clientes y desarrolladores.Se establecen normas de preparación y de participación.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.Un coordinador que controle la reunión.Se usa un mecanismo de definición: pizarras, carteles, gráficos, proyector, etc.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.


15 de 224




Recogida de Información.Técnicas de recogida.Lenguajes de representación.

TÉCNICAS DE RECOGIDA DE INFORMACIÓN

PARTE I


17 de 224

Técnicas de Recogida

Las técnicas más comunes son:Entrevistas (Es la más utilizada, especialmente para determinar el ámbito del problema).Desarrollo Conjunto de Aplicaciones (JAD).Prototipado.Tormenta de Ideas.Observación.Estudio de Documentación.Cuestionarios.Despliegue de la Función de Calidad (DFC).

Estas técnicas se denominan Técnicas para Facilitar las Especificaciones de la aplicación (TFEA) (Facilitated ApplicationSpecification techniques)


18 de 224

Entrevistas

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

Cualidades del Entrevistador.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.Ponderado. No exceder el tiempo de preguntas y preguntar lo justo para no cansar al cliente.Buen oyente. Debe escuchar con interés y adaptarse al ritmo de conversación.Habilidad en el trato.Cordialidad y accesibilidad.Paciencia.


19 de 224

Entrevistas. Modelo de Preparación

IDENTIFICATIVO

FASE

FECHA DE PREPARACIÓN

LUGAR DE PREPARACIÓN

DURACIÓN

PARTICIPANTES

FECHA A REALIZAR

LUGAR HORA

DURACIÓN PREVISTA

PERSONAL A QUIEN SE REALIZA

CARGO DEL PERSONAL

OBJETIVOS

PREGUNTAS

IDENTIFICACIÓN

PREPARACIÓN

CONTENIDO


20 de 224

Entrevistas. Modelo de Desarrollo

IDENTIFICATIVO

ENTREVISTA A LA QUE PERTENECE

FECHA DE REALIZACIÓN

PERSONAL QUE LA REALIZA

DURACIÓN

PARTICIPANTES

CONTESTACIONES

CONCLUSIONES

GRADO DE SATISFACCIÓN

INCIDENCIAS CON LOS PARTICIPANTES

IDENTIFICACIÓN

PREPARACIÓN

INCIDENCIAS

CONTENIDO


21 de 224

Técnicas de Recogida de Información

Desarrollo Conjunto de Aplicaciones (JAD).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.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.


22 de 224


Observación.Consiste en analizar in situ como funciona el sistema.Tiene la ventaja de captar el funcionamiento real de la empresa.

Estudio de Documentación.Se estudia la información existente en la empresa o sistema.

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


23 de 224


Despliegue de la Función de Calidad (DFC).Es una técnica de gestión de calidad que traduce las necesidades del cliente en requisitos técnicos del software.Desarrollada en Japón y aplicada en la Industria Mitsubishi.DFC hace énfasis en entender lo que resulta importante para el cliente.Identifica tres tipos de requisitos:

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.Requisitos esperados. Estos sin implícitos al sistema, y el cliente no siempre los declara.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



26 de 224

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.


27 de 224

Introducción

La orientación a objetos ha tomado por asalto el mundo del software.Principal ventaja para el desarrollo de software:

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.


28 de 224

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.


29 de 224

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


30 de 224

Conceptos

Asociaciones. Los objetos se asocian entre sí y esta asociación puede ser de diversos tipos:

En una dirección:

En dos direcciones:

Encender

Matrimonio


31 de 224

Conceptos

Asociaciones en mas de una forma:

Con más de una clase:

Es colaborador de

Es amigo de

Viaja en

Viaja en


32 de 224

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



34 de 224

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


35 de 224

Concepción de Clase

Un paquete es la manera en que el UML organiza un diagrama de elementos.

Si la clase lavadora es parte de un paquete llamado electrodomésticos. Esta clase se conoce como nombre de ruta:

Electrodomesticos

Electrodomesticos::Lavadora


36 de 224

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.


37 de 224

Atributos

Lavadora

marca

modelo

numeroSerie

capacidad

Una clase y sus atributos


38 de 224

Atributos

Todo objeto de la clase tiene un valor especifico en cada atributo.

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

miLavadora:Lavadora

marca=“LG”

modelo=“7800”

numeroSerie=“LG5674”

capacidad:7


39 de 224

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


40 de 224

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


41 de 224

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


agregarRopa(C:string)

sacarRopa (C:String)

agregarDetergente(D:Integer)

activar():Boolean

La información acerca de una operación se conoce como Firma de la Operación:


42 de 224

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

...


43 de 224

Atributos, Operaciones y Concepción

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.


44 de 224

Atributos, Operaciones y ConcepciónLavadora

<<info identificación>>

marca modelo numeroSerie

<<info máquina>>

capacidad

<<relacionado con la ropa>>

agregarRopa()

sacarRopa ()

agregarDetergente()

<<relacionado con la máquina>>

activar()


45 de 224

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


46 de 224

Restricciones

Una restricción es un texto libre bordeado por llaves, que especifica una o varias reglas que sigue la clase.

Lavadora



sacarRopa (C:String)

agregarDetergente(D:Integer)

activar():Boolean

{capacidad=7, 8 o 9 kg}

Restringe el atributo a tomar uno de estos tres valores


47 de 224

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


48 de 224

Notas Adjuntas

Una nota adjunta proporciona mayor información respecto a la clase.Una nota puede contener tanto una imagen como texto.

Lavadora

marca

modelo

numeroSerie

capacidad


...

Vease la norma de Industria E234x para la generación de números de serie.


49 de 224

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.


50 de 224

Ejemplo

Juego del baloncesto


51 de 224

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?


52 de 224

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.


53 de 224

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


54 de 224

Ejemplo

Sustantivos: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:Estatura de los jugadores, dimensión de la pista, tiempo de posesión del balón de cada equipo, duración del juego.

Verbos:Tirar, avanzar, driblar (o burlar), pasar, infracción, rebotar.

Información implícita:Por ejemplo información acerca de los atributos del balón (volumen, diámetro).


55 de 224

Ejemplo. Diagrama de Clases

Balón

Diámetro

volumen

driblar( )

tirar( )

pasar( )

avanzar( )

Jugador

Nombre, estatura

peso

driblarBalon( )

tirarBalon( )

pasarBalon( )

rebotar( )

infraccionarOponente( )

Defensa

Realiza la mayor parte del drible y pase


56 de 224


Delantero

Realiza la mayor parte de los tiros de media distancia y rebotes

Pivot

Permanece cerca del cesto. Tira de una distancia cercana.


57 de 224


Equipo Cesto Infracción

Tiro Tirolibre LíneaDeTresPuntos

Pista LíneaDeTiroLibre


58 de 224


LapsoDeTiro

{profesional = 24 segundos.

Colegial = 35 segundos.

Internacional = 30 segundos.

CronometroDeJuego

{profesional = 24 segundos.

Colegial = 35 segundos.

Internacional = 30 segundos.

Duracion

{profesional = 48 minutos.

Colegial e internacional = 40 minutos.

Uso de Relaciones



60 de 224

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:

Asociaciones.Multiplicidad.Asociaciones calificadas.Asociaciones reflexivas.Herencia y generalización.Dependencias.


61 de 224

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.

jugador EquipoParticipa en


62 de 224

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.


Empleado Empleador


63 de 224

Asociaciones

La asociación puede funcionar en dirección inversa.

Las asociaciones pueden ser más complejas, conectando varias clases.


Emplea

Equipo

Defensa

Delantero

Participa en

Participa en


64 de 224

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.

Esta asociación indica que el cajero atiende al cliente siguiendo el orden de llegada.

Cajero ClienteAtiende

{ordenado}


65 de 224

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.

El estudiante puede elegir entre ambas especialidades.

Estudiante de educación superior

Académico

Comercial

Elige

Elige

{Or}


66 de 224

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.


Contrato Director General

Negociado por


67 de 224

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.

herreros:jugadorNacional:Equipo

Participa en


68 de 224

Multiplicidad

La multiplicidad señala la cantidad de objetos de una clase que pueden relacionarse con un objeto de una clase asociada.

La asociación indica que:Un jugador puede partipar en un equipo.Un equipo tiene cinco judadores sin contar con los reservas.

Jugador EquipoParticipa en

5 1


69 de 224

Multiplicidades en UML

Esposo esposaEsta casado

1 1

Maestro Estudianteenseña

1 *

Cajero Clienteatiende

1 1..*


70 de 224

Multiplicidad en UML

Casa chimeneatiene

1 0,1

estudiante créditosenseña

1 12..18

triciclo ruedastiene

1 3


71 de 224

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 reservadisponemos de un localizador o número de confirmación.En UML la información para realizar la búsqueda se denomina calificador.

1 *Recepcionista ReservaNúmero de confirmación

localiza


72 de 224

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.

pasajeroconduce

conductor

OcupanteDeAutomovil1

0..4


73 de 224

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


74 de 224

Herencia o Generalización

Una jerarquía de herencia en el reino animal.

ReptilMamiferoAnfibio

Animal

caballo


75 de 224

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.

Formulario

Sistema

mostrarFormulario()


76 de 224

Agregación, Composición ....

En las siguientes secciones continuaremos con las relaciones entre clases.

Agregaciones.Composiciones.Contextos.Interfaces y realizaciones.Visibilidad.


77 de 224

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.

RatónMonitorCpu

Ordenador


78 de 224

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.

PlatoFuerteEnsaladaSopa

Comida

(O)


79 de 224

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.

PataTablero

MesaDeCafe

11 4


80 de 224

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.


81 de 224

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.


82 de 224

Diagrama de Contexto de Composición

CamisaManga Talle Cuello

Boton Ojal

Botonadura

1

11

1

1

1 1

1

0,2,35,6

12

1

esta cosido en

esta cosida en

esta cosida en

esta cosida en

2

esta cosida en

se abotona en


83 de 224

Diagrama de Contexto del Sistema

Camisa

Manga Talle Cuello

Boton Ojal

Botonadura

1

1

1

1

1

1 1

1

0,2,3

5,6

12

1

esta cosido en

esta cosida en

esta cosida en

esta cosida en

2

esta cosida en

se abotona en

1

1

1

1

*

*

Slacks

Atuendo

Guardarropa


84 de 224

Interfaces

Una vez que haya creado varias clases, tal vez se dé cuenta que no pertenecen a una clase principal, pero en su comportamiento debeincluir 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 ciertoaspecto 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.


85 de 224

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

Especificar la palabra <<interfaz>>;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.


86 de 224

Interfaz

<<interfaz>>

MaquinaDeEscribir

Teclazo()

Teclado

marca

cantidad de teclas

Ctrl()

Alt()

RePag()


87 de 224

Representación Omitida de Interfaz

Teclado

MaquinaDeEscribir


88 de 224

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:

Nivel público. La funcionalidad se extiende a otras clases.Nivel protegido de funcionalidad. Este se otorga sólo a las clases que se heredan de la clase original. Nivel privado. Sólo la clase original puede utilizar el atributo u operación.


89 de 224

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:

Público. Anteceder el atributo u operación con el signo +.Protegido. Anteceder con el simbolo #.Privado. Anteceder con el simbolo -.


90 de 224

Visibilidad

Television

+ marca

+ modelo

+ modificarVolumen()

- colorearImagenEnPantalla()


91 de 224

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

Instancia. Cada instancia cuenta con su propio valor en un atributo u operación.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.


92 de 224

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



94 de 224

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.


95 de 224

Definiciones y Términos

Sistema: Combinación de Software, hardware y genteque 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.


96 de 224

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.

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.


97 de 224

La Concepción del UML

El UML es la creación de Grady Booch, James Rumbaughe 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.

DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas instruments, Rational.

Primera versión en 1997.


98 de 224

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.


99 de 224

Diagrama de Clases

Una clase es una categoría o grupo de cosas que tienen atributos y acciones similares.

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

Nombre

Atributos

Acciones

Lavadora

MarcaModeloCapacidad

Abrir ()Cerrar ()Meter_Ropa ()Sacar_Ropa ()


100 de 224

Diagrama de Objetos

Un objeto es una instancia de una clase.

Un objeto puede estar formado de otros objetos.

Mi Lavadora: LavadoraNombre de la Instancia

Nombre de la Clase


101 de 224

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.


102 de 224

Diagrama de Casos de UsoDiagrama:

El actor puede ser una persona u otro sistema.

Lavar Ropa

Actor

Caso de Uso


103 de 224

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

CentrifugadoEnjuagueLavadoRemojo


104 de 224

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:


105 de 224

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.


106 de 224





107 de 224





108 de 224





109 de 224





110 de 224





111 de 224





112 de 224





113 de 224





114 de 224





115 de 224





116 de 224

Diagrama de Secuencias

Tambor DrenajeManguera de Agua

Abastecimiento de Agua

Permanecer Inmovil

DeternerseGirrar de un Lado a Otro

Vaciar el AguaReabastecer de Agua

Girrar de un Lado a Otro

Vaciar el AguaDetenerse

Girrar en un Solo Sentido

Detenerse


117 de 224

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


118 de 224

Diagrama de Colaboraciones

Los elementos de un sistema trabajan en conjunto para cumplir con los objetivos del sistema.

Cronometro Interno

Manguera de Agua

TamborT

1:Deternerse

Girar de un lado a otroLuego de cierto tiempo, el conómetro detendrá el flujo de agua y el tambor comenzará a girar.


119 de 224

Diagrama de Componentes

El desarrollo actual del software utiliza componentes.UML representa los componentes software como sigue:

Componente


120 de 224

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.


121 de 224

Diagrama de Distribución

Procesador Pentium 2 Procesador Motorola

Procesador Pentium 7. Servidor


122 de 224

Otras Características

UML proporciona características que le permiten organizar y extender los diagramas. Para ello dispone de:

Paquetes.Notas.Estereotipos


123 de 224

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.

Clase 1

Clase 2 Clase 3

Paquete 1


124 de 224

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


125 de 224

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.

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.


126 de 224

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.


127 de 224

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?


128 de 224

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.


129 de 224

EJEMPLOS


130 de 224

Ejemplo 1 de Clases

Enunciado:Se pide diseñar una aplicación que describa la situación en una casa en la que viven cinco animales; una ballena llamada ‘MobyDick’ 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.


131 de 224

Ejemplo de Clases

Identificación de clases:Lista de sustantivos:

Casa, perro, animal, pingüino, ballena y loro.Eliminación de sustantivos no significativos:

Casa hace referencia al lugar en el que se describe la situación y no aporta nada.

Identificación de clases adicionalesLa 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.


132 de 224

Ejemplo de Clases

Identificación de atributos: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: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.


133 de 224

Ejemplo de Clases

Representación del diagrama de clases:

Animal

AveMamífero

Perro

-Agresividad

+Ladrar

Ballena PingüinoLoro

+Hablar


134 de 224

Ejemplo 2 de ClasesEnunciado:

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.


135 de 224

Ejemplo de Clases


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.


136 de 224

Ejemplo de Clases

Identificación de clases:Eliminación de sustantivos:

Clases redundantesSe 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).

Clases irrelevantes:mostrador del aeropuerto, billete aéreo, entrevista.

Clases imprecisas:sistema, actividad, preferencia, búsqueda, información, acceso, itinerario.

Renombramiento de claseshorario (hora), fecha (día), aeropuerto (ciudad).


137 de 224

Ejemplo de Clases


Atributos: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).

Operaciones:compra, reserva, consulta.

Clases de Interfaces de usuario:pantalla principal.

Clases del sistema completo:sistema de reserva.

Actores:usuario, operador (en realidad no se trata).


138 de 224

Ejemplo de ClasesIdentificación de clases:

Clases adicionales: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.

Lista definitiva de sustantivos:reserva, vuelo, aerolínea, aeropuerto, tarifa, asiento, día, hora, pasajero, avión, pago, tarjeta de crédito.


139 de 224

Ejemplo de Clases

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


140 de 224

Ejemplo de Clases

Diagrama de clases (primera aproximación):

Día

Aerolínea

Vuelo Aeropuerto

1

1..*1..*

1

1..*

1..*1..*

SalidaLlegada

Destino

EscalasOrigen

1..*1

11

1..* 1..* 1

ConexiónSe supone que una conexión pertenece a un único vuelo

Pertenece

Día Hora1 1


141 de 224

Ejemplo de Clases

Diagrama de clases (segunda aproximación):

Tarifa

Asiento

Vuelo Avión1..*

1..*

Escalas 1..*1..* I/V 1..*

Aerolínea

1..*

1

1

Reserva Pertenece


142 de 224

Ejemplo de Clases

Diagrama de clases (tercera aproximación):

Pasajero

Pago1

1..*

1..*

Tarjeta

1..*

1..*

Vuelo Reserva1..* 1..*

1..*

Realiza

Si una reserva se puede pagar con varias tarjetas le corresponden varios pagos distintos

1..*1


143 de 224

Ejemplo de Clases

Identificación de atributos en las clases definitivas:

Pasajero

- Nombre- Direccion- Ciudad- Pais- CodPostal- TelefonoCasa- TelefonoOficina- Fax- Email- Contraseña

Avion

- Compañía- Tipo- NumPasajeros

Vuelo

- Numero

Aeropuerto

- Ciudad- Pais

Tarjeta

- Nombre- Numero- Tipo- Fecha- Vencimiento

Aerolinea

- Nombre

Pago

- Tipo- Fecha- Cantidad

Reserva

- Clave- CostoTotal

Tarifa

- Clase- Precio- Impuestos

Asiento

- Fila- Letra


144 de 224

Ejemplo de Clases

Diagrama de clases definitivo:1 1..*

Vuelo

- Numero

Aerolinea

- Nombre

Tarjeta

- Nombre- Numero- Tipo- Fecha- Vencimiento

Día Hora

Reserva

- Clave- CostoTotal

Pago

- Tipo- Fecha- Cantidad

Aeropuerto

- Ciudad- Pais

Tiene

Posee

Hace Realiza

TieneEs destino

Destino

Es origen

Origen

Hace escalas

EscalasConexión

Avion

- Compañía- Tipo- NumPasajeros

ContieneLlega

Llegada

Sale

Salida

Asiento

- Fila- Letra

Tarifa

- Clase- Precio- Impuestos

Contiene

Posee

Le pertenece

Es realizado por

I/V

Pasajero

- Nombre- Direccion- Ciudad- Pais- CodPostal- TelefonoCasa- TelefonoOficina- Fax- Email- Contraseña

1

1 1 1

1 1

1

11..*

1..*

1..*

1..*1

1..*

1..*

1..*

1..*

1..*

1..*

1..*

1..*

1..*

1..*

1 1

1..*1..*

1..*1..*

1..* 1..* 1..*


145 de 224

Ejemplo 3 de Clases

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


146 de 224

Ejemplo de Clases

Enunciado: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 undeterminado plato a petición del cliente. Cada solicitud de consumición (comida o bebida) constituye una línea de pedido.


147 de 224

Ejemplo de ClasesEnunciado:

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.


148 de 224

Ejemplo de Clases


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.

Eliminación de sustantivos:Clases redundantes:

Persona (cliente), línea pedido (consumición).Clases irrelevantes:

Dueño, nota, cocina, plato, teléfono, terminal reserva, plano.Atributos:

Numero personas, código.


149 de 224

Ejemplo de Clases


Operaciones:Solicitud consumición.

Clases del sistema completo:Sistema.

Actores:Camarero, jefe cocina.

Lista definitiva de sustantivos:Cliente, reserva, mesa, pedido, restaurante, consumición, ingrediente, bebida, comida.


150 de 224

Ejemplo de Clases

Identificación de relaciones entre clases:Un cliente reserva una o varias mesas, un mesa es reservada por uno o varios clientes.Reserva es una asociación ya que su existencia está condicionada a la relación entre cliente y mesa.Una mesa puede tener o no un pedido.Una mesa pertenece a un restaurante y restaurante posee muchas mesas.Un pedido está formado por consumiciones, relación de agregación.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.Una consumición está formada por ingredientes, relación de agregación.


151 de 224

Ejemplo de Clases

Diagrama de clases (primera aproximación):

Cliente

Reserva

RestauranteMesa

Pedido

Ingrediente

Bebida

Consumición

Comida

Clase Asociación

Hace reserva Pertenece

Tiene

1..*1..* 1..*

10..1

1..*

1..*

1


152 de 224

Ejemplo de Clases

Identificación de atributos y operaciones en las clases definitivas:Cliente

-Nombre

Mesa

- NumMesa- Fumador- NumPersona- Estado- Ubicación

+ obtenerDatosMesa

Restaurante

- Nombre- Plano- Telefono

Reserva

- Fecha- Hora- NumPersonas

+ crearReserva

Pedido

- Hora

Consumición

- Codigo- Precio

Ingrediente

- CantidadDisponible- CantidadMinima


153 de 224

Ejemplo de Clases

Diagrama de clases definitivo:Cliente

-Nombre

Pedido

- Hora

Consumición

- Codigo- Precio

Restaurante

- Nombre- Plano- Telefono

Reserva

- Fecha- Hora- NumPersonas

+ crearReserva

Ingrediente

- CantidadDisponible- CantidadMinima

Mesa

- NumMesa- Fumador- NumPersona- Estado- Ubicación

+ obtenerDatosMesa

Bebida Comida

1..*1..*

1

0..1

Tiene

PerteneceHace reserva

1..* 1..*

Clase Asociación

1..*

11

1


154 de 224

Ejemplo 1 de Diagrama de estados

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


155 de 224

Ejemplo de Diagrama de estados

Enunciado: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 presentarlos 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).


156 de 224


Identificación de clases:Mesa.

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


157 de 224


Descripción de transiciones entre estados: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.


158 de 224


Diagrama de estados de la clase mesa:

Libre ReservadaSe realiza reservaAbre el restaurante

Inicio

Fin

Pasan 20 minutos de la hora fijada

Espera

ServidosEsperando cuenta

Pidiendo

Clientes ocupan la

mesaSolicitud de comida terminada

Nueva solicitud de comida

Comida servidaNueva solicitud de comida

Cuenta pagada

Cierra el restaurante

Clientes ocupan la mesa

Comida finalizada


159 de 224

Ejemplo 2 de Diagrama de estados

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


160 de 224


Identificación de clases:Pedido.Escena.Objeto3D.

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


161 de 224


Descripción de transiciones entre estados: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.


162 de 224


Diagrama de transición de estados:

Escena Vacía Escena NoVacía

Añadir Objeto 3DIniciar SistemaInicio

Fin

ColocandoObjeto en Cesta

CambiandoColor/Textura

Objeto 3D Manipulado

Objeto 3D Seleccionado

Seleccionar Objeto 3D

Enviar objeto a cesta

Cambiar color o texturaSeleccionar Objeto 3D

Manipular

Número de Objetos = 0

Apagar Sistema

Enviar objeto a cesta

Borrando Objeto 3D

Borrar Objeto

Número de Objetos > 0

Añadir Objeto 3D


163 de 224

Ejemplo 1 de Diagrama de secuenciasEnunciado:

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.


164 de 224

Ejemplo de diagrama de secuencias

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


165 de 224

Ejemplo de Diagrama de secuencias

Identificación del actor que desencadena la secuencia:Gestor de Solicitudes (GS).

Identificación de clases participantes: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.


166 de 224

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

Dieta recomendada

Solicitar nutrientes

Fuentes alimenticias

Dieta final revisada


167 de 224

Ejemplo 1 de Diagrama de actividades

Enunciado:Ejemplo de las dietas.

Misma especificación


168 de 224

Ejemplo de Diagrama de actividades

Diagrama de actividades:

:MAD :HistorialClinico

:Enfermedad

:Dietas

:Nutrientes

:GestorSolicitudes

1:Solicitar tratamiento

10:Dieta final revisada

2:Solicitar historial clínico

3:Datos historial clínico

4:Solicitar enfermedades

5:Enfermedades a tratar

6:Solicitar dieta9:Dieta recomendada

7:Solicitar nutrientes8:Fuentes alimenticias

Casos de Uso



170 de 224

Organización del Capítulo

Introducción a los casos de uso.Diagramas de casos de uso.Ejemplos.


171 de 224

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?


172 de 224

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.


173 de 224

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.


174 de 224

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.


175 de 224

Definición de Caso de Uso

Un caso de uso establece un conjunto de escenarios para realizar algo útil para un actor.


176 de 224

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.


177 de 224

Inicio del Análisis de un Caso de Uso

Para iniciar los casos de uso seguirá un conjunto de procedimientos:

Entrevistas con los clientes (y entrevistas con expertos) que nos llevarán a los diagramas de clases.

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.

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.

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.


178 de 224

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.


179 de 224

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.


180 de 224

Representación Caso de Uso

Sistema

Caso de Uso

Actor Actor


181 de 224

Ejemplo

Maquina de bebidas

Comprar gaseosa

Representante

Reabastecer

Recolectar dinero

Recolector

Cliente Cliente

Representante

Recolector


182 de 224

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:

El actor que inicia el caso de uso; Condiciones previas para el caso de uso; Pasos en el escenario; Condiciones posteriores cuando sefinaliza el escenario; El actor que se beneficia del caso de uso.También se pueden utilizar conjeturas del escenario.


183 de 224

Relaciones entre Casos de Uso

Los casos de uso se pueden relacionar entre si como sigue:

Inclusión. Le permite volver a utilizar los pasos de un caso de uso dentro de otro.Extensión. Le permite crear un caso de uso mediante la adición de pasos a uno existente.Generalización. Cuenta con un caso de uso que se hereda de otro.Agrupamiento. Es una manera de agrupar a los casos de uso.


184 de 224

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.


185 de 224

Inclusión

Maquina de bebidas

Comprar gaseosa

Representante

Reabastecer

Recolectar dinero

Recolector

Cliente Cliente

Representante

Recolector

<<incluir>>

<<incluir>>

Exhibir interior

Cubrir interior


186 de 224

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.


187 de 224

Extensión

<<incluir>>

<<incluir>>

Exhibir el interior

Cubrir el interior

Reabastecer de acuerdo

a las ventas

Reabastecer

Punto de extensión llenar los compartimentos


188 de 224

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 cualquierlugar donde aplique el primario.Un caso de uso puede heredar el sentido y comportamiento de otro.

En este ejemplo deberá imaginar un caso de uso “comprar un vaso de gaseosa” que se hereda de “comprar gaseosa”.

Comprar un vaso

de gaseosaComprar gaseosa


189 de 224

Generalización

La herencia también se puede establecer entre actores.

Agente proveedor

RecolectorReabastecedor


190 de 224

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.


191 de 224

Diagramas de Casos de Uso en el Proceso de Análisis

Los pasos son los siguientes:Las entrevistas inician el proceso, generando diagramas de clases.Una vez que conozcamos la terminología general del área del cliente, estamos listos para hablar con los usuarios.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.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


193 de 224

Ejemplo 1 de Casos de Uso

Enunciado: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 carnetpodrá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.


194 de 224

Ejemplo de Casos de UsoCasos de uso identificados:

Petición de llave: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.

Devolución de llave: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.


195 de 224

Ejemplo de Casos de Uso

Representación de Casos de Uso:

Usuario Usuario

Usuario

Petición de llave

Devoluciónde llave

Conserjería

Identificación

<<incluir>>


196 de 224


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


197 de 224

Ejemplo de Casos de uso

Actores identificados:Administrador.Gestor.Vigilante.

Casos de Uso identificados:Activación/Desactivación de alarma:

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.


198 de 224


Casos de uso identificados:Colocación de alarmas:

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 .

Atención de una alarma: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.


199 de 224


Casos de uso identificados:Simulación de alarmas:

El vigilante realizará simulaciones de alarmas periódicamente para comprobar que su estado es correcto.

Ajuste de umbrales de activación:El gestor determinará la sensibilidad de cada sensor.

Determinación de la acción a realizar:El gestor determinará la acción a realizar por el sistema cuando se active una sensor y se dispare una alarma en particular.

Todos los casos de uso incluyen el caso identificación de usuarioya que todos los usuarios deben identificarse para acceder al sistema.


200 de 224


Representación de casos de uso:

Vigilante

Colocación de alarmas Activación /Desactivación

de alarmasActivación /Desactivación

de alarmas

Atención de una alarma

Simulación de alarmas

Ajuste de umbralesde activación

Determinación de la acción a realizar

Identificación de usuario

<<incluir>>

<<incluir>>

<<incluir>><<incluir>>

<<incluir>>

<<incluir>><<incluir>>Administrador

Gestor


201 de 224



Administrador

Colocación de alarmas

Colocar nueva Colocación

de las existentes

<<extender>><<extender>>


202 de 224


Enunciado: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...).


203 de 224


Actores identificados:Propietario.Inquilino.Secretario.

Casos de uso identificados:Gestión de edificio:

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.

Gestión de local: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.


204 de 224


Casos de uso identificados:Gestión de piso:

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.

Alquilar:Un inquilino procede a alquilar un inmueble. Este caso de uso esextendido 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.


205 de 224


Casos de uso identificados:Desalquilar:

Un inquilino deja el alquiler de un inmueble. Incluye el caso de uso Identificación.

Baja:Un inquilino ‘borra’ sus datos. Incluye el caso de uso Identificación. No confundir con el caso de uso referido a los inmuebles.

Modificación:Un inquilino cambia sus datos. Incluye el caso de uso Identificación. No confundir con el caso de uso referido a los inmuebles.

Consulta:Un inquilino consulta sus datos. Incluye el caso de uso Identificación. No confundir con el caso de uso referido a los inmuebles.

Generar recibos:El secretario genera los recibos de cada inmueble.


206 de 224


Casos de uso identificados:Gestor de movimientos bancarios:

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.

Ingresos:Extendido por dos casos de uso; Ingresos piso e Ingresos local.

Gestión de informe económico:Llevada a cabo por el secretario.

Generación de listados: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).


207 de 224


Representación de casos de uso:Gestión de Inmuebles

Alta Baja

Gestión de edificio

Consulta

Alta

Modificación

Baja

Modificación

Consulta

AltaBajaModificaciónConsulta

Gestión delocal

Gestión depiso

<<extender>>

<<extender>>

<<extender>><<extender>><<extender>>


<<extender>>

<<extender>>

<<extender>> <<extender>>

<<extender>>

<<extender>>

<<extender>>

Propietario


208 de 224



Alquilar

Alta inquilino

Alquiler piso

Alquiler local

Alquiler edificio

Identificación

Desalquilar

Baja

Consulta

Modificación

<<extender>>

<<extender>>

<<incluir>>

<<extender>>

Inquilino

<<extender>>

<<extender>>

<<extender>>

<<incluir>>

<<incluir>>

<<incluir>>

<<incluir>>


209 de 224

Ejemplo de Caso de Uso


Generar recibos

Gestor de movimientos

bancarios

Gestión Informe

económico Recibospendientes

Pagos enun año

Generaciónde listados

Ingresos Ingresoslocal

Ingresos piso

Gastos deinmueble

Secretario

<<extender>>

<<extender>>

<<extender>>

<<extender>>

<<extender>>

<<extender>>


210 de 224


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


211 de 224


Actores identificados:Profesor. Administrador.

Casos de uso identificados:Poner nota:

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.

Operaciones Calculadora:Extendido por las operaciones más comunes como Sumar, Restar o Dividir e incluye Volcar el resultado. Incluye el caso de uso Validar usuario.

Gestión alumno: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.


212 de 224


Casos de uso identificados:Integrar grupo:

El profesor une en un solo acta los datos de todos los alumnos de un grupo. Incluye el caso de uso Validar usuario.

Información alumno:Se recogen los datos personales del alumno. Incluye el caso de uso Validar usuario.

Estadística:Generación de estadísticas. Incluye el caso de uso Validar usuario.

Gráfico:Presentación de los resultados en un gráfico como alternativa a los listados. Incluye el caso de uso Validar usuario.

Importar:Convertir datos en formato Excel. Incluye el caso de uso Validar usuario.


213 de 224


Casos de uso identificados:Exportar:

Convertir datos a formato Excel. Incluye el caso de uso Validar usuario.

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

Gestión ABMC alumnos: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.

Matriculación:Gestionado por el administrador. Incluye el caso de uso Validar usuario.


214 de 224


Casos de uso identificados:Gestión Asignaturas:

Llevada a cabo por el administrador. Incluye el caso de uso Validar usuario.

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

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


215 de 224


Representación de casos de uso:Gestión de Calificaciones

Poner notas

OperacionesCalculadora

Volcar resultado

SumarRestar

Dividir

Gráfico

Imprimir

Informaciónalumno

Imprimir Listaprovisional

Exportar Imprimiractas

Importar

Integrargrupo

Estadística

Gestión alumno

AñadirBorrar

Validar usuario

<<extender>>


<<extender>>

<<extender>>

<<extender>>



<<incluir>>

<<incluir>>

<<incluir>>

<<incluir>>

<<incluir>>

<<incluir>>

<<incluir>>

<<incluir>>Profesor


216 de 224


Representación de casos de uso:Gestión de Calificaciones

GestiónABMC

alumnos

AltaBaja

Modificación

ConsultaHistorial

Académico

Validar usuario

Matriculación

Gestión Asignaturas

Gestión Titulaciones

Gestión Grupos

<<extender>>


<<extender>>

<<incluir>>

<<incluir>>

<<incluir>>

<<incluir>>

<<incluir>>

Administrador


217 de 224

Ejemplo 5 de Casos de UsoEnunciado:

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.


218 de 224


Actores identificados:Administrador.Gestor.Operador.Usuario final.

Casos de uso identificados:Instalación de PIU:

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.

Control de funcionamiento: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.


219 de 224


Casos de uso identificados:Gestión de red:

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.

Obtención de información:Consultas realizadas por los usuarios finales. Incluye el caso de uso Identificación.


220 de 224



Operador

Usuario final

Sistema de Información Universitaria

Instalación de nuevo PIU

Instalación de PIU existente

Instalaciónde PIU

Obtención deinformación

Control defuncionamiento

Identificación

Determinar accionesmal funcionamiento

Actualizarparámetro

Observar estado / corregir

Gestiónde red

Obtenerresultados

EstadísticasRealizarinforme

Configurar


<<extender>><<extender>><<extender>>

<<extender>> <<extender>>

<<incluir>>


<<incluir>>

<<incluir>> <<incluir>>

Gestor

Administrador


221 de 224


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


222 de 224


Actores identificados:Jefe de programación.Responsable de abonado.Director general.Abonado.

Casos de uso identificados:Gestionar abonados:

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


223 de 224


Casos de uso identificados:Obtener estadísticas:

Realizado por el director general. Extendido por los casos de uso Visualización de programa, Ventas y Errores de retransmisión. Incluyeel caso de uso Validar usuario.

Determinación de programas:Responsabilidad del jefe de programación. Extiendo por los casos de uso Nuevo programa, Cambiar programa y Eliminar programa. Incluye el caso de uso Validar usuario.

Acceso abonado: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.


224 de 224


Representación de casos de uso:Sistema de televisión

por cable

Validar usuario

Eliminarprograma

Cambiar programa

Nuevo programa

Determinaciónde programas

Obtener estadísticas

Errores deretransmisión

Visualizaciónde programa

Ventas

Gestionar Abonados

Modificación

Alta

CompraAbono nueva

opción

Consulta

Acceso abonado

Reclamación

Baja


<<extender>>

<<extender>>

<<extender>>



<<extender>>

<<extender>>


<<incluir>> <<incluir>>


Jefe de programación

Abonado

Responsable de abonado

Director general

Documents

UML - IOO