diagramas uml

Diagramas UML

Curso: Desarrollo de Sistemas de Información

10 de Agosto

UML

Aprendizajes Esperados

• Comprender los conceptos asociados a la clase y el diseño de un diagrama de clases que representen la solución para proyectos planteados.

UML

Actividades a Realizar

• Conocer términos básicos de Orientación a Objetos.

• Estudiar las técnicas de modelado de datos UML.• Comprender diagramas de clases para ser

aplicados a una problemática.• Construir clases sencillas, aplicando conceptos

aprendidos.

UML

Introducción

• “El término de Programación Orientada a Objetos indica más una forma de diseño y una metodología de desarrollo de software que un lenguaje de programación.”

UML

UML

• Lenguaje Unificado de Modelado (Unified Modeling Language).

• Lenguaje de modelado de sistemas de software.

• Lenguaje gráfico para construir, documentar, visualizar y especificar un sistema de software.

UML

Diagramas UML• Modela procesos de negocios, funciones, esquemas de bases de

datos, expresiones de lenguajes de programación, etc. En UML 2.0 hay 13 tipos de diagramas.

- Diagramas de estructura:Diagrama de clasesDiagrama de componentesDiagrama de objetosDiagrama de estructura compuesta (UML 2.0)Diagrama de despliegueDiagrama de paquetes

UML

Diagramas UML -Diagramas de comportamiento:

Diagrama de actividadesDiagrama de casos de usoDiagrama de estados

-Diagramas de interacción:Diagrama de secuenciaDiagrama de comunicaciónDiagrama de tiempos (UML 2.0)Diagrama de vista de interacción (UML 2.0)

Algunos programas gratuitos para modelar en UML son:

ArgoUML, Dia, gModeler, MonoUML, StarUML, TCM, Umbrello Herramienta, UMLet.

UML

Paradigma OO

• Resultado de la evolución natural de la programación, devenido en metodología de programación de propósito general que simula la forma en que el hombre trabaja y cuya idea básica es que percibimos al mundo que nos rodea como una variedad de objetos.

UML

Ejemplo: Enviar flores a una persona de otra ciudad

UML

Beneficios que se obtienen con el desarrollo de la P.O.O.

Permite obtener aplicaciones más modificables, fácilmente extendibles y a partir de componentes reusables. Esta reusabilidad del código disminuye el tiempo que se utiliza en el desarrollo y hace que el desarrollo del software sea mas intuitivo.

El esfuerzo del programador ante una aplicación orientada a objetos se centra en la identificación de las clases, sus atributos y operaciones asociadas

Beneficios POO

UML

Un Objeto es una entidad con una estructura de datos interna bien definida, junto a un conjunto de acciones que describen su comportamiento. Es la unidad básica de la POO.

Ejemplo:María la florista Perla la floristaJosé el florista

Conceptos Básicos

UML

•Un objeto o instancia es una variable concreta de una clase con su propia copia de variables miembros.

Un objeto tiene estado, comportamiento e identidad.

• Tiene datos internos que le dan el estado.

• Tiene métodos para producir comportamiento.

• Cada objeto tiene una dirección única en memoria lo que le da identidad.

Objetos

UML

“…son cosas que se pueden percibir por los 5 sentidos..”

“…representación real ó abstracta del mundo real.”

“…cualquier cosa real o abstracta, en la que se almacenan datos y que contienen métodos que los manipulan”

Ejemplo de objetos reales:

• carro• reloj• barco• teléfono• ……..

Objetos

UML

Características de Objetos Reales

• Tienen propiedades específicas

• Tienen un comportamiento

• Relaciones.

Ejemplos:

Perro:• Propiedades su nombre, su color, su estado de hambre.• Comportamiento está ladrando, está corriendo..

Bicicleta:• Propiedades marca, cadencia de los pedales, velocidades.• Comportamientos frenado, acelerado, cambios.

Objetos

UML

Los objetos, son modelados a partir de los objetos reales, basándose en sus propiedades y comportamientos.Las propiedades o atributos de un objeto se almacenan en

VARIABLES

Los comportamientos se implementan utilizando los METODOS

Variable: es un item de data referenciado por un identificador.

Metodo: es una función o procedimiento asociado a un objeto. Son las operaciones que pueden realizarse sobre el objeto.

Objetos

UML

Mensajes

Instrucción que se envía a un objeto.

Un objeto sólo no es muy útil....

Un objeto normalmente forma parte de un programa que contiene muchos otros objetos.

Los objetos interactúan mediante el envío de mensajes.

Objetos

UML

Mensajes

Instrucción que se envía a un objeto.

El objeto al cual se le envía el mensajeEl método que se desea ejecutar.Cualquier otra información que necesite el método para poder actuar (parámetros).

Telefono.llamar(2416881)

Objeto.método(parámetros)

Ejemplo:

Objetos

UML

Objeto

MensajeCliente Servidor

Emisor Receptor

Objeto,Usuario,Aplicación

Mensaje: Forma de solicitar una acción a un objeto.

Conceptos Básicos

UML

Una clase es:• una categoría de objetos con características comunes.• una plantilla que se usa para crear múltiples objetos con características similares.

Las clases engloban las características de un conjunto particular de objetos.

Ejemplo: Florista

Conceptos Básicos

UML

• Las clases son tipos de variables o tipos de datos creados por el usuario.

• Las clases pueden estar formadas por variables miembros y funciones miembros.

Conceptos Básicos

UML

Cada clase puede estar compuesta por:

• Atributos: definen el estado de la clase.• atributos pasivos,• variables miembros,• campos.

• Métodos: definen el comportamiento de la clase. • funciones miembros, • atributos activos, • operaciones,• comportamiento,• responsabilidades.

Conceptos Básicos

UML

Variables Miembros

Funciones miembros

FloristaNombreSalarioEdadVender floresEnviar flores a otra ciudad

Ejemplos:

Variables Miembros

Funciones miembros

BombilloConsumoEncender ApagarAumentar BrilloDisminuir brillo

Notación UML para representar una clase

UML

• Mientras que un objeto es una entidad concreta que existe en tiempo y espacio, una clase representa sólo una abstracción, la escencia del objeto.

• Una clase es un conjunto de objetos

• Un objeto es simplemente la instancia de una clase.

• Cuando se crea una clase se involucran dos procesos:• La definición de atributos que se utilizarán para

almacenar la data de un objeto.• La definición de los mensajes que se desea que los

objetos entiendan. Para cada mensaje se crea un método.

Clases

UML

Instancias de una Clase

Son aquellos objetos de esa clase, que aunque tienen las mismas características tienen valores asociados diferentes para esas características.

Ejemplo:Clase Teléfono

014-975874 9785482

Clases

UML

¿Consultas?

• Buscar 4 ejemplos de clase indicando sus características (atributos) y comportamiento (métodos).

• Para cada clase, mencionar tres instancias e indicar los valores de los atributos.

Ejercicios

UML

Resumen clase anterior…

Motocicleta

colorcilindradavelocidad máxima

arrancar()acelerar()frenar()

Motocicleta

colorcilindradavelocidad máxima

arrancar()acelerar()frenar()

CLASE(Motocicleta)

Verde180

(Motocicleta)Negro

210

OBJETOS…

UML – DISEÑO DE CLASES


• Conocer la estructura de atributos y métodos de una clase.

• Entender la visibilidad de una clase.• Comprender las relaciones entre las clases.• Aplicar las buenas prácticas para el diseño de

Clases.• Trabajar con las herramientas StarUML y/o

ArgoUML para diseñar Clases.


Atributos de Diagrama de Clases• Atributo: Representa una propiedad de una entidad. Cada atributo de un

objeto tiene un valor que pertenece a un dominio de valores determinados.

• El nombre del atributo es un sustantivo y empieza en minúsculas. • Las sintaxis de una atributo es:

Visibilidad <nombre>: tipo = valor

• Donde visibilidad es uno de los siguientes:+ público.# protegido.- privado.


Operaciones de Diagrama de clases• Operación: Conjunto de operaciones que describen el comportamiento

de los objetos de una clase.

• El nombre empleará un verbo con un sustantivo. La primera letra se escribirá en minúscula.

• La sintaxis de una operación en UML es:Visibilidad <nombre> (lista de parámetros): tipo que retorna

• Donde visibilidad es uno de los siguientes:+ público.# protegido.- privado.


Visibilidad• Publico: Un atributo, propiedad o método público es visible

fuera de clase en cualquier parte. Se nos ocultan otros detalles técnicos. (+)

• Protegido: Un elemento protegido es visible solamente en la unidad donde se declare la clase y en cualquier clase que descienda de ésta. (#)

• Privado: Un atributo, propiedad o método privado es invisible fuera de la unidad donde se lo declara. (sólo sus métodos de la misma clase lo pueden accesar).(-)


Ejemplo

Persona

#nombre: cadena = " "#rut: cadena = " "#edad: entero = 0

+mostrarEdad(rutPersona): entero


Diagrama de Clases


Relaciones entre clases

•Las relaciones existentes entre las distintas clases indican como se comunican los objetos de esas clases entre sí.

•Los mensajes navegan por las relaciones existentes entre las distintas clases.


Relaciones entre Clases

Multiplicidad nombre 0..1 Trabaja-para * empleador empleado rol


Relaciones entre Clases• Nombre: Identifica la asociación entre los objetos,

caracterizándola.

• Rol: Identificado como un nombre a los finales de la línea, describe la semántica de la relación en el sentido indicado. Cada asociación tiene dos roles; cada rol es una dirección en la asociación. El rol puede estar representado en el nombre de la clase.


Relaciones entre Clases• Multiplicidad: Describe la cardinalidad de la relación, es decir, cuanto

objetos de esa clase pueden participar en la relación dada.

• Cada asociación tiene 2 multiplicidades (una en cada extremo)

• Exactamente 1 1• Cero 0..1 0..1• Cero o más 0..*• Uno o más 1..*• Subrango m..n

• Si la multiplicidad mínima = 0 establece una relación OPCIONAL.• Si la multiplicidad mínima >= 1 establece una relación OBLIGATORIA.


Ejemplos:


Ejemplos


Tipos de relaciones entre Clases

• Asociación (conexión entre clases)• Dependencia (relación de uso)• Generalización / Especialización (relación de

herencia)


Asociación

• Relación estructural que describe una conexión entre objetos.

• Línea que une dos o más clases.Tipos de asociaciones• Unaria• Binaria• N-aria


Asociación

• Asociación Binaria: Representa una relación sencilla entre dos clases, no muy fuerte (es decir, no se exige dependencia existencial). Se indica como una línea sólida que une dos clases.

• Asociación n-aria: Es una asociación entre tres o más clases. Se representa como un diamante del cual salen líneas de asociación a las clases.


Asociación Binaria

ProfesorDepartamento

10..1

director

1

dirige

0..1

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.


Asociación n-aria

Empresa Empleado

1..** 1..**

trabajadoresempleador

Cargo

nombresueldo 0..1

1..*

superior

subordinado 1..*

0..1


Relaciones involutivas

• Cuando la misma clase aparece en los dos extremos de la asociación.


Casos particulares de Asociaciones

ComposiciónAgregación


Composición ó…• Por Valor: Es un tipo de relación estática, en

donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye.

• Es una asociación fuerte que implica:– Dependencia existencial. El elemento dependiente

desaparece al destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo.

– Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene.


Composición– Los objetivos contenidos no son compartidos, esto es, no

hacen parte del estado de otro objeto. – Son relaciones que impliquen en su significado que una

clase “está compuesta por” otras clases dependientes.

Se denota dibujando un rombo coloreado del lado de la clase que contiene a la otra en la relación.


Ejemplo 1: Composición



La relación entre ambos objetos es tal, que el contenido es una parte importante del contenedor, de tal forma que el primero no tiene sentido suelto, y el segundo, necesita definir al primero para ampliar su significado.El avión tiene sentido por si solo, pero esta claro que esta compuesto de 2 alas, esta claro, que un avión siempre tendrá sus dos alas, y estas siempre serán del mismo avión.


http://go2.wordpress.com/?id=725X1342&site=icrovett.wordpress.com&url=http://icrovett.files.wordpress.com/2010/02/compocionuml2.jpg&sref=http://icrovett.wordpress.com/2010/02/08/uml-diseno-de-agregacion-vs-composicion/

Agregación ó…• Por Referencia: Tipo de relación dinámica, en donde el tiempo

de vida del objeto incluido es independiente del que lo incluye.

• Son relaciones que implican en su significado que una clase “contiene a” otras clases independientes.

• Cuando deja de existir la clase agregada no tiene por qué dejar de existir el resto de las clases de la agregación

• Se denota por un rombo sin rellenar en un o de los extremos.


Ejemplo 1: Agregación

Un objeto de tipo, ciudad tiene una lista de objetos de tipo aereopuerto, esto quiere decir, que una ciudad, tiene un número de aereopuertos, destacar, que la cardinalidad del extremo que lleva el rombo, es siempre uno.


http://go2.wordpress.com/?id=725X1342&site=icrovett.wordpress.com&url=http://icrovett.files.wordpress.com/2010/02/composicionuml.jpg&sref=http://icrovett.wordpress.com/2010/02/08/uml-diseno-de-agregacion-vs-composicion/

Ejemplo 2: Agregación


Ejemplo: Agregación y Composición

•Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias). •Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.


Dependencia• Relación (más débil que una asociación) que muestra la

relación entre un cliente y el proveedor de un servicio usado por el cliente.

• Es una relación donde existen entidades independientes y otras dependientes, lo que implica que cambiar el elemento independiente puede requerir cambios en los dependientes.

• Se representa con una línea punteada direccional, indicando el sentido de la dependencia.


Ejemplo: Dependencia


La Clase Aplicación depende de la Clase Ventana

Generalización/Especialización

• Relación entre una superclase (clase padre) y sus subclases (clases hijos).

• Objetos de distintas clases pueden tener atributos similares y exhibir comportamientos parecidos (ej. Animales, mamíferos…)


Ejemplo 1: Generalización


Ejemplo 2: Generalización


Clase Abstracta

• Se denota con el nombre de la clase y de los métodos con letra "itálica". Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos (aún no han sido definidos, es decir, sin implementación). La única forma de utilizarla es definiendo subclases, que implementan los métodos abstractos definidos.


Ejemplo 1: Clase Abstracta


Identificación de Clases


Problema

• Una biblioteca contiene libros y revistas. Puede haber varias copias de un libro. Algunos de los libros son reservados sólo para préstamos a corto plazo. Todos los otros pueden ser prestados a cualquier miembro de la biblioteca por tres semanas. Los miembros de la biblioteca pueden normalmente solicitar hasta seis items de una vez, pero miembros del staff pueden solicitar hasta doce items a la vez. Solamente miembros del staff pueden obtener prestado revistas.

• El sistema debe conservar la pista de cuando los libros y revistas son prestados y retornados forzando las reglas de la biblioteca.


Problema

• Una biblioteca contiene libros y revistas. Puede haber varias copias de un libro. Algunos de los libros son reservados sólo para préstamos a corto plazo. Todos los otros pueden ser prestados a cualquier miembro de la biblioteca por tres semanas. Los miembros de la biblioteca pueden normalmente solicitar hasta seis items de una vez, pero miembros del staff pueden solicitar hasta doce items a la vez. Solamente miembros del staff pueden obtener prestado revistas.

• El sistema debe conservar la pista de cuando los libros y revistas son prestados y retornados forzando las reglas de la biblioteca.


ENCONTRAR LOS SUSTANTIVOS

Clases Candidatas• Biblioteca Nombre del Sistema• Libro• Revista• Copia• PréstamosACortoPlazo evento• MiembroDeBiblioteca• Semana medida• Itemlibro o revista• Tiempo término abstracto• MiembroDelStaff• Sistema término general• Regla término general


Relaciones entre Clases

• Libro es unItem• Revista es unItem• Copia es una copia de Libro• MiembroDeBiblioteca• Item• MiembroDeStaffes unMiembroDeBiblioteca

¿Es el Item necesario?


Operaciones

• MiembroDeBiblioteca pide prestado Copia• MiembroDeBiblioteca devuelve Copia• MiembroDeStaff pide prestado Revista• MiembroDeStaff devuelve Revista


Diagrama de Clases


Ejemplo 2: Club de Baile


Club de BaileU

ML

– D

ISEÑ

O D

E CL

ASES

Definición de las reglas del negocioU

ML

– D

ISEÑ

O D

E CL

ASES

Consejos Prácticos

• No lanzarse a dibujar clases y asociaciones sin sentido

• Elaborar un modelo simple• Los nombres de objetos, asociaciones, atributos

y operaciones deben ser significativos • Tratar de usar asociaciones binarias• Utilizar los elementos necesarios• Documentar el modelo



• Conocer y diseñar los documentos asociados al Análisis de sistema.

• Conocer y aplicar Diagramas de casos de Uso, escenario, diseño de prototipo en el proceso de Análisis de Sistema.

UML

Actividades a Realizar

• Repasar conceptos de especificación de requisitos (requerimientos).

• Conocer composición de Casos de Uso

• Definir Escenarios y Sub-escenarios dentro del contexto de casos de Uso.

• Diagramar casos de Uso de una problemática en particular.

UML

Especificación de Requisitos o requerimientos

• En el análisis lo más relevante es determinar y documentar adecuadamente los requisitos.

• Es difícil definir los requerimientos.

• Los requisitos funcionales (que debe hacer el sistema) se pueden especificar por niveles y estos deben corresponder con diagramas de casos de uso.

• Los requerimientos mal planteados incrementan los costos.

UML – DIAGRAMAS DE CASOS DE USO

Requerimientos Funcionales

• Son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares.

• Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que éste provea.


Ejemplo de Requerimiento Funcional Sistema de Biblioteca

• El usuario deberá tener la posibilidad de buscar referencias bibliográficas en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella.

• El sistema deberá proveer visores adecuados para que el usuario lea documentos en el almacén de documentos.

• A cada pedido se le deberá asignar un identificador único

que el usuario podrá copiar al área de almacenamiento permanente de la cuenta.


Ejemplo de Requerimientos Funcionales

Id RF-001

Nombre Alquilar un ejemplar

Entradas Bonos, datos de la película

Salidas Comprobante con los ejemplares solicitados y la fecha de devolución

Excepciones No tiene bonos para alquilar. Los bonos que tiene no sirven para alquilar el tipo de película deseado. El cliente no ha devuelto todas las películas del alquiler anterior


Requerimientos No Funcionales

• Restricciones de los servicios o funciones ofrecidos por el sistema.

• Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.


Ejemplos Requerimientos No Funcionales

• La respuesta en el tiempo.

• La capacidad de almacenamiento.

• Alternativamente definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en la interface del sistema.


Tipos de Requerimientos

• Requerimientos del producto. – Especifican el comportamiento del producto;

• como los requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta memoria se requiere;

– Los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable;

– Los de portabilidad.



• Requerimientos organizacionales. Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador: – estándares en los procesos que deben utilizarse;

requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar.

– los requerimientos de entrega que especifican cuándo se entregará el producto y su documentación.



• Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de desarrollo. – Requerimientos que definen la manera en que el sistema

interactúa con los otros sistemas de la organización.– Requerimientos legales que deben seguirse para

asegurar que el sistema opere dentro de la ley.– Requerimientos éticos. Estos últimos son impuestos al

sistema para asegurar que será aceptado por el usuario y por el público en general.


Casos de Uso

• Describen el comportamiento del sistema bajo la forma de acciones y reacciones bajo el punto de vista del usuario.

• Los casos de uso describen funcionalidad del sistema sin dar detalles de implementación. Permiten la comunicación entre desarrolladores y usuarios.

• Permiten definir los límites de un sistema y las relaciones

entre el sistema y el entorno.


Casos de Usos

• Un diagrama de Casos de Uso muestra la distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuario u otras aplicaciones).

• Es una herramienta esencial para la captura de requerimientos y para la planificación y control de un proyecto interactivo.


Casos de Usos

• Se representa en el diagrama por una elipse que denota un requerimiento solucionando por el sistema.

• Cada caso de uso de uso es una operación completa desarrollada por los actores y por el sistema en un diálogo.

• El conjunto de casos de uso representa la totalidad de operaciones desarrolladas por el sistema.


Informatica II - 2002 88

… Casos de Uso Ejemplo:

Actor ACaso de Uso A

Actor BCaso de Uso B


Ejemplos

Supervisor Verificar Situación del Cliente

Administrativo Preparar Catálogo Sistema Inventario


Un actor es una entidad que interactúa con el sistema


Actor

• Es un usuario del sistema, que necesita o usa alguno de los casos de uso.

• Un usuario puede jugar más de un rol. Un solo actor puede actuar en muchos casos de uso; recíprocamente, un caso de uso puede tener varios actores. Los actores no necesitan ser humanos pueden ser sistemas externos que necesitan alguna información del sistema actual.


Un Actor…

• Puede ser…– Un usuario humano– Un sistema que provee o recibe información del

sistema– Es una Abstracción un Rol, no es una persona o un

cargo determinado.


Tipos de Actores

• Principal: Inicia el Caso de Uso• Secundario: Participa en el caso de uso.


Diagramas de Casos de Uso

• Es una relación entre Casos de Uso, Actores y relación entre si.

• Los diagramas de casos de uso son útiles para:– Determinar Requerimientos– Comunicación entre usuarios y desarrolladores– Generar caso de Prueba


Escenarios

• Los Casos de uso describen la funcionalidad del sistema a alto nivel, los escenarios describen la funcionalidad de una parte.


Tipos de Relación en los diagramas de Caso de Uso

• Comunicación• Inclusión• Extensión


Comunicación

ActorCaso de Uso


Entre un actor y un caso de uso, denota la participación del actor en el caso de uso determinado.

Inclusión

• Una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino.

• <<include>> en su versión actual, reemplazó al denominado <<uses>>


99

… Casos de Uso: Relaciones

Caso de Uso Origen Caso de Uso Destino

<<include>>


Ejemplo Inclusión


Extensión

• El Caso de Uso origen extiende el comportamiento del Caso de Uso destino.

<<extends>>


102

… Casos de Uso: Relaciones

Caso de Uso Destino Caso de Uso Origen

<<extend>>


Ejemplo extend


Include vs extend

• <<include>> pretende evitar duplicación de interacciones en distintos casos de uso, la relación <<extends>> pretende describir una variación del comportamiento normal de un caso de uso, sobre todo cuando dicha variación pudiera complicar la legibilidad del caso de uso.


Ejemplo Extend / Include


106

Casos de Uso: Construcción Un caso de uso debe ser simple, claro y conciso.

Generalmente hay pocos actores asociados a cada Caso de Uso


107

Preguntas clave:– ¿cuáles son las tareas del actor?– ¿qué información crea, guarda, modifica,

destruye o lee el actor?– ¿debe el actor notificar al sistema los

cambios externos?– ¿debe el sistema informar al actor de los

cambios internos?

Casos de Uso: Construcción


108

… Casos de Uso: Construcción

La descripción del Caso de Uso comprende:– el inicio: cuándo y qué actor lo produce?– el fin: cuándo se produce y qué valor devuelve?– la interacción actor-caso de uso: qué mensajes

intercambian ambos?


109

– objetivo del caso de uso: ¿qué lleva a cabo o intenta?

– cronología y origen de las interacciones– repeticiones de comportamiento: ¿qué

operaciones son iteradas?– situaciones opcionales: ¿qué escenarios

alternativos se presentan en el caso de uso?

… Casos de Uso: Construcción


Casos de Usos


Resumen para recopilar RF mediante CU

1. Especificar la misión del sistema.2. Identificar quiénes utilizarán el sistema

(actores primarios).3. Averiguar cuáles objetivos desean cumplir los

actores al usar el sistema (casos de uso).4. Identificar los pasos o eventos de cada caso

de uso (especificación del caso de uso).


diagramas uml

Documents