SlideShare una empresa de Scribd logo
1 de 15
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.

Más contenido relacionado

La actualidad más candente

Modelo e r
Modelo e rModelo e r
Modelo e rgarci17
 
Sesion 3 2 modelo de analisis
Sesion 3 2 modelo de analisisSesion 3 2 modelo de analisis
Sesion 3 2 modelo de analisisJulio Pari
 
Caso de Uso
Caso de UsoCaso de Uso
Caso de Usoutrilla
 
UML - Casos de Uso y Diagramas de Clase
UML - Casos de Uso y Diagramas de ClaseUML - Casos de Uso y Diagramas de Clase
UML - Casos de Uso y Diagramas de ClaseGuillermo Díaz
 
Curso Uml 2.1 Diagramas De Cu Y Clases
Curso Uml   2.1 Diagramas De Cu Y ClasesCurso Uml   2.1 Diagramas De Cu Y Clases
Curso Uml 2.1 Diagramas De Cu Y ClasesEmilio Aviles Avila
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clasesjmachado614
 
Modelos De Datos (Segunda Parte)
Modelos De Datos (Segunda Parte)Modelos De Datos (Segunda Parte)
Modelos De Datos (Segunda Parte)esacre
 
Dependencias Funcionales en Bases de Datos
Dependencias Funcionales en Bases de DatosDependencias Funcionales en Bases de Datos
Dependencias Funcionales en Bases de DatosEsteban Andres Diaz Mina
 
Diagramas estados
Diagramas estadosDiagramas estados
Diagramas estadosloco8888
 
Ejercicios resueltos diagramas de claseaula (1)
Ejercicios resueltos diagramas de claseaula (1)Ejercicios resueltos diagramas de claseaula (1)
Ejercicios resueltos diagramas de claseaula (1)William Lozano
 
Mapa conceptual unidad 1 benita
Mapa conceptual unidad 1 benitaMapa conceptual unidad 1 benita
Mapa conceptual unidad 1 benitaTAtiizz Villalobos
 
Sem 8 Modelo De Analisis
Sem 8 Modelo De AnalisisSem 8 Modelo De Analisis
Sem 8 Modelo De Analisisguest0a6e49
 
Otras relaciones y modelos bases de datos
Otras relaciones y modelos bases de datosOtras relaciones y modelos bases de datos
Otras relaciones y modelos bases de datosEmer Gio
 

La actualidad más candente (20)

Diagrama de Componentes
Diagrama de ComponentesDiagrama de Componentes
Diagrama de Componentes
 
Modelo e r
Modelo e rModelo e r
Modelo e r
 
Sesion 3 2 modelo de analisis
Sesion 3 2 modelo de analisisSesion 3 2 modelo de analisis
Sesion 3 2 modelo de analisis
 
Caso de Uso
Caso de UsoCaso de Uso
Caso de Uso
 
Uml clase 04_uml_clases
Uml clase 04_uml_clasesUml clase 04_uml_clases
Uml clase 04_uml_clases
 
UML - Casos de Uso y Diagramas de Clase
UML - Casos de Uso y Diagramas de ClaseUML - Casos de Uso y Diagramas de Clase
UML - Casos de Uso y Diagramas de Clase
 
Diagramas de clases
Diagramas de clasesDiagramas de clases
Diagramas de clases
 
Curso Uml 2.1 Diagramas De Cu Y Clases
Curso Uml   2.1 Diagramas De Cu Y ClasesCurso Uml   2.1 Diagramas De Cu Y Clases
Curso Uml 2.1 Diagramas De Cu Y Clases
 
Diagrama de clases
Diagrama de clasesDiagrama de clases
Diagrama de clases
 
Uml
UmlUml
Uml
 
Modelos De Datos (Segunda Parte)
Modelos De Datos (Segunda Parte)Modelos De Datos (Segunda Parte)
Modelos De Datos (Segunda Parte)
 
Diagramas de actividades
Diagramas de actividadesDiagramas de actividades
Diagramas de actividades
 
Guía de Visual Fox Pro 9.0
Guía de Visual Fox Pro 9.0Guía de Visual Fox Pro 9.0
Guía de Visual Fox Pro 9.0
 
Dependencias Funcionales en Bases de Datos
Dependencias Funcionales en Bases de DatosDependencias Funcionales en Bases de Datos
Dependencias Funcionales en Bases de Datos
 
Diagramas estados
Diagramas estadosDiagramas estados
Diagramas estados
 
Ejercicios resueltos diagramas de claseaula (1)
Ejercicios resueltos diagramas de claseaula (1)Ejercicios resueltos diagramas de claseaula (1)
Ejercicios resueltos diagramas de claseaula (1)
 
Mapa conceptual unidad 1 benita
Mapa conceptual unidad 1 benitaMapa conceptual unidad 1 benita
Mapa conceptual unidad 1 benita
 
Diagrama de estado
Diagrama de estadoDiagrama de estado
Diagrama de estado
 
Sem 8 Modelo De Analisis
Sem 8 Modelo De AnalisisSem 8 Modelo De Analisis
Sem 8 Modelo De Analisis
 
Otras relaciones y modelos bases de datos
Otras relaciones y modelos bases de datosOtras relaciones y modelos bases de datos
Otras relaciones y modelos bases de datos
 

Similar a Diagrama de caso de uso.docx

Metodologã­a orientada-a-objetos-omt.-rumbaugh
Metodologã­a orientada-a-objetos-omt.-rumbaughMetodologã­a orientada-a-objetos-omt.-rumbaugh
Metodologã­a orientada-a-objetos-omt.-rumbaughviisistemas
 
Modelado del AnáLisis
Modelado del AnáLisisModelado del AnáLisis
Modelado del AnáLisisCarolina Rojas
 
planeacion de software
planeacion de softwareplaneacion de software
planeacion de softwareMaria Lopez
 
Metodología orientada a objetos (omt). rumbaugh
Metodología orientada a objetos (omt). rumbaughMetodología orientada a objetos (omt). rumbaugh
Metodología orientada a objetos (omt). rumbaughWilfredy Inciarte
 
4-modelo-de-caso-de-usos.ppt
4-modelo-de-caso-de-usos.ppt4-modelo-de-caso-de-usos.ppt
4-modelo-de-caso-de-usos.pptAnder Gonzalez
 
Diseño de sistemas - UML - compendio
Diseño de sistemas  -  UML - compendioDiseño de sistemas  -  UML - compendio
Diseño de sistemas - UML - compendioJose Diaz Silva
 
6.modelado de los requerimientos escenarios y clases
6.modelado de los requerimientos  escenarios y clases6.modelado de los requerimientos  escenarios y clases
6.modelado de los requerimientos escenarios y clasesRamiro Estigarribia Canese
 
Diagramas de flujo
Diagramas de flujoDiagramas de flujo
Diagramas de flujolordXDie
 
Metodologias_desarrollo_SOFTWARE.pptx
Metodologias_desarrollo_SOFTWARE.pptxMetodologias_desarrollo_SOFTWARE.pptx
Metodologias_desarrollo_SOFTWARE.pptxElmerCadilloLimas1
 
UML(Diseños de Sistemas)
UML(Diseños de Sistemas)UML(Diseños de Sistemas)
UML(Diseños de Sistemas)josue salas
 
Patrones de programación y uml en java
Patrones de programación y uml en javaPatrones de programación y uml en java
Patrones de programación y uml en javaGuille Villaf
 

Similar a Diagrama de caso de uso.docx (20)

Metodologã­a orientada-a-objetos-omt.-rumbaugh
Metodologã­a orientada-a-objetos-omt.-rumbaughMetodologã­a orientada-a-objetos-omt.-rumbaugh
Metodologã­a orientada-a-objetos-omt.-rumbaugh
 
Diagramas UML
Diagramas UMLDiagramas UML
Diagramas UML
 
04 modelo dean�lisis-2
04 modelo dean�lisis-204 modelo dean�lisis-2
04 modelo dean�lisis-2
 
Diagramas UML
Diagramas UMLDiagramas UML
Diagramas UML
 
Modelado del AnáLisis
Modelado del AnáLisisModelado del AnáLisis
Modelado del AnáLisis
 
planeacion de software
planeacion de softwareplaneacion de software
planeacion de software
 
Metodología orientada a objetos (omt). rumbaugh
Metodología orientada a objetos (omt). rumbaughMetodología orientada a objetos (omt). rumbaugh
Metodología orientada a objetos (omt). rumbaugh
 
4-modelo-de-caso-de-usos.ppt
4-modelo-de-caso-de-usos.ppt4-modelo-de-caso-de-usos.ppt
4-modelo-de-caso-de-usos.ppt
 
Secme 23279
Secme 23279Secme 23279
Secme 23279
 
Diseño de sistemas - UML - compendio
Diseño de sistemas  -  UML - compendioDiseño de sistemas  -  UML - compendio
Diseño de sistemas - UML - compendio
 
3 analisis
3 analisis3 analisis
3 analisis
 
Jhon fredy
Jhon fredyJhon fredy
Jhon fredy
 
6.modelado de los requerimientos escenarios y clases
6.modelado de los requerimientos  escenarios y clases6.modelado de los requerimientos  escenarios y clases
6.modelado de los requerimientos escenarios y clases
 
Diagramas de flujo
Diagramas de flujoDiagramas de flujo
Diagramas de flujo
 
Metodologias_desarrollo_SOFTWARE.pptx
Metodologias_desarrollo_SOFTWARE.pptxMetodologias_desarrollo_SOFTWARE.pptx
Metodologias_desarrollo_SOFTWARE.pptx
 
Entidad
EntidadEntidad
Entidad
 
UML(Diseños de Sistemas)
UML(Diseños de Sistemas)UML(Diseños de Sistemas)
UML(Diseños de Sistemas)
 
Diagramadeflujo 140115215731-phpapp02
Diagramadeflujo 140115215731-phpapp02Diagramadeflujo 140115215731-phpapp02
Diagramadeflujo 140115215731-phpapp02
 
Patrones de programación y uml en java
Patrones de programación y uml en javaPatrones de programación y uml en java
Patrones de programación y uml en java
 
Diagramas UML
Diagramas UMLDiagramas UML
Diagramas UML
 

Diagrama de caso de uso.docx

  • 1. Modelado de un requisito funcional
  • 2. 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
  • 3. 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.
  • 4. 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:
  • 5. ¿Qué es un diagrama de clases en UML?
  • 6. 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.
  • 7. 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 (+)
  • 8. 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.
  • 9. 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,
  • 10. 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.
  • 11. 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".
  • 12. 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.
  • 13. 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.
  • 14. 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
  • 15. 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.