Modelado de un requisito funcional

Modelado de un requisito no funcional
Cómo dibujar un diagrama de casos de uso
A la hora de dibujar un diagrama de casos de uso te recomendamos que compruebes que has
realizado previamente todos estas tareas, respondiendo a las preguntas que te escribimos a
continuación:
 Recopilar fuentes de información: ¿cómo se supone que debo saber eso?
 Identificar actores potenciales: ¿qué usuarios utilizan los bienes y servicios del
sistema empresarial?. Para más información te recomiendo la guía para identificar
actores y casos de uso.
 Identificar posibles casos de uso: ¿a qué bienes y servicios pueden recurrir los
actores?
 Conectar los casos de uso: ¿quién puede hacer uso de los bienes y servicios del
sistema empresarial?
 Describir actores: ¿a quién o qué representan los actores?
 Buscar más casos de uso: ¿Qué más debe hacer el sistema?
 Documentar casos de uso: ¿qué sucede exactamente en cada caso de uso?
 Relacionar modelos entre casos de uso empresarial: ¿qué actividades se realizan
repetidamente?
 Verificar la vista, ¿todo es correcto?
Los pasos se han escrito en este orden a propósito, ya que es la forma lógica de seguirlos. Sin
embargo, este orden no es obligatorio, ya que en la práctica, los pasos individuales a menudo se
superponen unos con otros.
Para poder seguir los pasos de una forma óptima, es importante comprender el negocio/sistema
para conseguir seguir cada paso individual. En algunos casos tambien es necesario consultar a
los expertos o consultores del negocio. No tiene sentido aferrarse a la visión personal del
analista, si este no tiene mucho conocimiento del área de negocio de la aplicación.
Ejemplos de un diagrama de casos de uso

Ejemplo clínica veterinaria:
A modo de ejemplo se propone un ejercicio de un diagrama de casos de uso que consiste en el
diseño de una aplicación que gestione los tramites a realizar en una clínica veterinaria en base a
las siguientes premisas:
 La clínica veterinaria almacena datos de contacto de todos sus clientes como
pueden ser: Nombre, Apellidos, DNI, Fecha de nacimiento, Teléfono o Email.
Estos datos son introducidos y gestionados por los auxiliares, que ejercen las
funciones administrativas.
 Además se almacena información de cada uno de las mascotas de las que es
dueño cada cliente. Obviamente, cada cliente puede tener más de una mascota,
pero cada mascota solo puede pertenecer a un único cliente. Se permite, además,
cambiar el dueño de una mascota por otro.
 Al dar de alta un nuevo animal, se comprobará en el registro del REIAC (Red
Española de Identificación de Animales de Compañía) si el animal está
correctamente dado de alta. Este proceso unicamente se hará en animales que
tengan la obligación de estar identificados.
 Cada vez que un veterinario realiza una consulta sobre un animal, esta queda
almacenada incluyendo datos básicos como: Tiempo de consulta, Identificación
de la persona que lo ha tratado, Animal tratado, Importe total, Resolución,
Recetas… Para calcular el tiempo de la consulta el veterinario tendrá un botón en
la aplicación donde pueda pulsar cuando comienza la consulta para calcular el
tiempo a modo de cronómetro y otro botón para finalizar.
 En caso de que el animal se quede ingresado en la clínica, el cliente debe ser
capaz de acceder al estado en tiempo real del animal. Además podrá comunicarse
con una cámara que tendrá el animal colocada, donde podrá ver su situación
actual. La gestión de estas cámaras no corresponde al sistema, sino que se
utilizará una aplicación ya presente en el veterinario.
 Las recetas y otros documentos relacionados con el servicio se incluirán en un
gestor de contenidos que ya está en funcionamiento en la clínica veterinaria.
 Una vez terminado el servicio, el cliente no tiene porque realizar inmediatamente
el pago, sino que puede identificarse posteriormente en la aplicación vía web y
realizar el pago. Si el cliente tarda más de una semana se efectuará un recargo
sobre el precio inicial.
 Además, el cliente debe ser capaz de obtener un histórico de todas las consultas
que ha recibido cualquiera de sus mascotas.

Ejemplo Diagrama de casos de uso del actor «auxiliar»
Ejemplo Diagrama de casos de uso del actor «Cliente»
Ejemplo Diagrama de casos de uso del actor «veterinario»
No obstante, dependiendo del nivel de profundidad, el diagrama puede variar
significativamente descomponiendo, añadiendo, omitiendo o fusionando alguno de los casos de
uso que se han expuesto.
Ejemplo centro educativo:

¿Qué es un diagrama de clases en UML?

El Lenguaje Unificado de Modelado (UML, por sus siglas en inglés)
puede ayudarte a modelar sistemas de diversas formas. Uno de los
tipos más populares en el UML es el diagrama de clases. Popular
entre los ingenieros de software para documentar arquitectura de
software, los diagramas de clases son un tipo de diagrama de
estructura porque describen lo que debe estar presente en el sistema
que se está modelando. Sin importar tu nivel de familiaridad con
diagramas UML o diagramas de clases, nuestro software UML está
diseñado para ser simple y fácil de usar.
El UML se estableció como un modelo estandarizado para describir
un enfoque de programación orientada a objetos (POO). Como las
clases son los componentes básicos de los objetos, los diagramas de
clases son los componentes básicos del UML. Los diversos
componentes en un diagrama de clases pueden representar las
clases que se programarán en realidad, los objetos principales o la
interacción entre clases y objetos.
La figura de clase en sí misma consiste en un rectángulo de tres filas.
La fila superior contiene el nombre de la clase, la fila del centro
contiene los atributos de la clase y la última expresa los métodos o
las operaciones que la clase puede utilizar. Las clases y las subclases
se agrupan para mostrar la relación estática entre cada objeto.
Beneficios de los diagramas de clases
Los diagramas de clases ofrecen una serie de beneficios para toda
organización. Usa los diagramas de clases UML para:
Ilustrar modelos de datos para sistemas de información, sin
importar qué tan simples o complejos sean.
Comprender mejor la visión general de los esquemas de una
aplicación.

Expresar visualmente cualesquier necesidades específicas de un
sistema y divulgar esa información en toda la empresa.
Crear diagramas detallados que resalten cualquier código
específico que será necesario programar e implementar en la
estructura descrita.
Ofrecer una descripción independiente de la implementación
sobre los tipos empleados en un sistema que son
posteriormente transferidos entre sus componentes.
Componentes básicos de un diagrama
de clases
El diagrama de clases estándar está compuesto por tres partes:
Sección superior: Contiene el nombre de la clase. Esta sección
siempre es necesaria, ya sea que estés hablando del
clasificador o de un objeto.
Sección central: Contiene los atributos de la clase. Usa esta
sección para describir cualidades de la clase. Esto solo es
necesario al describir una instancia específica de una clase.
Sección inferior: Incluye operaciones de clases (métodos). Esto
está organizado en un formato de lista. Cada operación
requiere su propia línea. Las operaciones describen cómo una
clase puede interactuar con los datos.
Modificadores de acceso a miembros
Todas las clases poseen diferentes niveles de acceso en función del
modificador de acceso (visibilidad). A continuación, te mostramos los
niveles de acceso con sus símbolos correspondientes:
Público (+)

Privado (-)
Protegido (#)
Paquete (~)
Derivado (/)
Estático (subrayado)
Alcance de los miembros
Hay dos alcances para los miembros: clasificadores e instancias.
Los clasificadores son miembros estáticos, mientras que las instancias
son las instancias específicas de la clase. Si estás familiarizado con
POO, esto no es nada nuevo.
Componentes adicionales del diagrama de clases
En función del contexto, las clases de un diagrama de clases pueden
representar los objetos principales, las interacciones en la aplicación
o las clases que se programarán. Para responder la pregunta "¿Qué
es un diagrama de clases en UML?" , primero deberías comprender
su composición básica.
Clases: Una plantilla para crear objetos e implementar un
comportamiento en un sistema. En UML, una clase representa
un objeto o un conjunto de objetos que comparte una
estructura y un comportamiento comunes. Se representan con
un rectángulo que incluye filas del nombre de la clase, sus
atributos y sus operaciones. Al dibujar una clase en un
diagrama de clases, solo se debe cumplimentar la fila
superior. Las otras son opcionales y se usan si deseas agregar
más detalles.
o Nombre: La primera fila en una figura de clase.

o Atributos: La segunda fila en una figura de clase. Cada
atributo de una clase está ubicado en una línea
separada.
o Métodos: La tercera fila en una figura de clase.
También conocidos como "operaciones", los métodos
se organizan en un formato de lista donde cada
operación posee su propia línea.
Señales: Símbolos que representan comunicaciones
unidireccionales y asincrónicas entre objetos activos.
Tipos de datos: Clasificadores que definen valores de datos. Los
tipos de datos pueden modelar tanto enumeraciones como
tipos primitivos.
Paquetes: Figuras diseñadas para organizar clasificadores
relacionados en un diagrama. Se simbolizan con una figura de
un gran rectángulo con pestañas.
Interfaces: Una recopilación de firmas de operaciones o de
definiciones de atributo que define un conjunto uniforme de
comportamientos. Las interfaces son similares a una clase,
excepto por que una clase puede tener una instancia de su
tipo, y una interfaz debe poseer, como mínimo, una clase para
implementarla.
Enumeraciones: Representaciones de tipos de datos definidos
por el usuario. Una enumeración incluye grupos de
identificadores que representan valores de la enumeración.
Objetos: Instancias de una clase o clases. Los objetos se pueden
agregar a un diagrama de clases para representar instancias
prototípicas o concretas.
Artefactos: Elementos modelo que representan las entidades
concretas de un sistema de software, como documentos,

bases de datos, archivos ejecutables, componentes de
software y más.
Interacciones
El término "interacciones" se refiere a múltiples relaciones y enlaces
que pueden existir en diagramas de objetos y de clases. Algunas de
las interacciones más comunes incluyen:
Herencia: El proceso en el que una subclase o clase derivada
recibe la funcionalidad de una superclase o clase principal,
también se conoce como "generalización". Se simboliza
mediante una línea de conexión recta con una punta de flecha
cerrada que señala a la superclase.
En este ejemplo, el objeto "Auto" heredaría todos los
atributos (velocidad, números de pasajeros, combustible) y los
métodos (arrancar(), frenar(), cambiar Dirección()) de la clase principal
("Vehículo"), además de los atributos específicos (tipo de modelo,
número de puertas, fabricante del auto) y métodos de su propia clase
(Radio(), limpiaparabrisas(), aire acondicionado/calefacción()). La
herencia se muestra en un diagrama de clases por medio de una
línea continua con una flecha cerrada y vacía.

Asociación bidireccional: La relación predeterminada entre dos
clases. Ambas clases están conscientes una de la otra y de la
relación que tienen entre sí. Esta asociación se representa
mediante una línea recta entre dos clases.
En el ejemplo anterior, la clase Auto y la clase Viaje están
interrelacionadas. En un extremo de la línea, el Auto recibe la
asociación de "auto_Asignado" con el valor de multiplicidad de 0..1,
de modo que cuando la instancia de Viaje existe, puede tener una
instancia de Auto asociada a ella o no tener instancias de Autos
asociadas a ella. En este caso, una clase Casa_Rodante separada con
un valor de multiplicidad de 0..* es necesaria para demostrar que un
Viaje puede tener múltiples instancias de Autos asociadas a ella.
Dado que una instancia de Auto podría tener múltiples asociaciones
"iniciarViaje", en otras palabras, un auto podría realizar múltiples
viajes, el valor de multiplicidad se establece en 0..*
Asociación unidireccional: Una relación un poco menos común
entre dos clases. Una clase está consciente de la otra e
interactúa con ella. La asociación unidireccional se dibuja con
una línea de conexión recta que señala una punta de flecha
abierta desde la clase "knowing" a la clase "known".

Como ejemplo, en tu viaje por Arizona, podrías encontrarte con una
trampa de velocidad donde un radar de tráfico registra la velocidad a
la que conducías, pero no lo sabrás hasta que recibas la notificación
por correo. Esto no está dibujado en la imagen, pero en este caso, el
valor de multiplicidad sería 0..* en función de cuántas veces hayas
conducido frente al radar de tráfico.
Relaciones del diagrama de clases
Agregación es un tipo especial de asociación en la que los objetos se ensamblan o configuran
juntos para crear un objeto más complejo. Una agregación describe un grupo de objetos y cómo
se interactúa con ellos.

Dependencia es una relación en la que un elemento utiliza o depende de otro elemento.
Composición representa relaciones de partes enteras y es una forma de agregación.
Generalización es una relación en la que un elemento del modelo (hijo) se basa en otro
elemento del modelo (padre).
Asociación es una relación entre dos clasificadores, como clases o casos de uso, que muestra
las razones de la relación y las reglas que la rigen.
Restricción es un mecanismo de extensión que permite refinar la semántica de un elemento del
modelo UML.
Nota contiene comentarios o información textual.
Ejemplos de diagrama de clases
Crear un diagrama de clases para trazar flujos de procesos es sencillo.
Considera los dos ejemplos siguientes al crear tus propios diagramas
de clases en UML.

Diagrama de clases para un sistema administrativo hotelero
Un diagrama de clases puede mostrar las relaciones entre cada
objeto en un sistema administrativo hotelero, incluidas la información
de huéspedes, las responsabilidades del personal y la ocupación por
habitación. El siguiente ejemplo proporciona un panorama útil del
sistema administrativo hotelero. Inicia un diagrama de clases
haciendo clic en la plantilla siguiente.
Diagrama de clases para un sistema de cajero automático ATM
Los ATM son aparentemente simples. Aunque los clientes solo
necesitan oprimir algunos botones para recibir efectivo, hay muchas
capas de seguridad que un ATM seguro y efectivo debe pasar para
evitar fraude y brindar valor a los clientes bancarios. Las diversas
partes humanas e inanimadas de un sistema de ATM son ilustradas

por este diagrama sencillo de leer. Cada clase tiene su título y los
atributos se detallan debajo. Puedes editar, guardar y compartir este
diagrama abriendo el documento y registrándote a una cuenta
gratuita de Lucidchart.