Clase 05 Tecnicas de Busqueda de Requerimientos 22 12 23

CARRERA: DESARROLLO DE SISTEMAS DE INFORMACION
Curso
Técnicas de búsqueda de requerimientos.
Clase 5: Visión General del Proceso Unificado. Lenguaje Unificado de Modelado

(UML). Diagramas y Vistas.
.
Lima, 22 de diciembre de 2023
Prof. Juan Daniel Daza Hermoza
Diapositiva 2 Fecha: 22/12/2023
ingenieria.sistemas.2030@gmail.com
1. Tener los micrófonos apagados.
2. Sólo active su micrófono si va a participar,

después lo desactiva.

Para participar levante la
mano, indique su nombre y
el lugar de donde se conecta

Participación de todos ustedes
¡¡¡¡¡Poner en
el Zoom sus
nombres
completos!!!!!

¿Que vimos la clase pasada?

MÉTODOS DE RECOLECCIÓN
DE INFORMACIÓN
Uno de los problemas básicos de la Ingeniería de Requerimientos
consiste en identificar las fuentes de las que se puede obtener el
conocimiento necesario para la formulación de los requerimientos.
La identificación de fuentes resulta especialmente
dificultosa porque habitualmente debe ejecutarse
en condiciones de ignorancia e incertidumbre.
La exigencia de ser una búsqueda exhaustiva de
fuentes deriva de que una característica tan
importante de la calidad de una SRS (Software
Requirements Specification) especificación de
requerimientos de software; como la completitud
está directamente relacionada con la posibilidad
de acceder a todas las fuentes.
La Entrevista
En el análisis de sistemas hay que distinguir las formas cualitativas y cuantitativas de
información. La cualitativa está relacionada con opiniones, políticas y descripciones
narrativas de actividades o problemas y las cuantitativas con números, frecuencias o
cantidades. A menudo las entrevistas son la mejor fuente de información cualitativa.
Análisis de
Sistemas
Cualitativas Cuantitativas
Descripciones
Opiniones Políticas Números Frecuencias Cantidades
Narrativas

EL CUESTIONARIO.
Los cuestionarios constituyen la única
forma posible de poder relacionarse con
un gran número de personas para conocer
varios aspectos del sistema, sin tener que
estar presente.
Los cuestionarios como medio para
recoger opiniones o hacer encuestas
pueden ser de gran utilidad si se usa en
forma adecuada, o sea, si se aplican en
una situación especifica para la cual
fueron diseñados especialmente y
además este diseño reúne una serie de
requisitos
Hay dos formas de cuestionarios: abiertos y cerrados.
Abiertos
Se utilizan para recoger sentimientos, opiniones, referencias. no aparece limitado o
preestablecido el modo de responder a las mismas y no se definen variantes de
respuesta, por lo que el individuo tiene libertad para contestar de acuerdo a la forma en
que interprete la pregunta.
Cerrados
Son denominadas también preguntas de alternativas fijas, ya que las posibilidades de
respuesta del sujeto están expresamente fijadas con anterioridad. Estas preguntas
pueden ser dicotómicas o politómicas.

Respuestas de
cuestionario cerrado
Dicotómicas: Las respuestas se refieren a variables dicotomizadas o
polarizadas, por lo que existen dos posibilidades: Si o No; Verdadero
o Falso; De Acuerdo o En Desacuerdo, Etc.
Politómicas: Son preguntas de selección múltiple, donde se establecen varias posibilidades de
respuestas

¿CÓMO DESARROLLAR UN CUESTIONARIO?
Los buenos cuestionarios se deben diseñar previamente.
Un pensamiento cuidadoso, • Determine qué datos necesitan recopilarse y que personas son las
más calificadas para proporcionarlos.
acompañado de una prueba
1 • Si otros grupos pueden proporcionar datos variantes y mayor
previa, tanto del formato como
de las preguntas, son la base de
• Seleccione el tipo de cuestionario (abierto o cerrado).
una recopilación de datos Reconozca cuales pueden ser más útiles, si contienen una
significativa a través de 2 sección de respuestas cerradas y otras de respuestas abiertas.
cuestionarios.
Pautas para ayudarles en la • Desarrolle un grupo de preguntas para incluirlas en el
cuestionario. Las preguntas extras que son intencionalmente
confección de un cuestionario: redundantes, pueden ser útiles al asegurar respuestas consistentes
3 por parte de quien responda.

• Examine el cuestionario para encontrarle fallas y defectos como:
a)Interrogantes innecesarias.
b)Preguntas que puedan ser mal interpretadas debido a su enfoque o forma de escritura.
c) Preguntas que el sujeto no pueda responder.
4 d)Preguntas que están escritas de forma que se escogerá la respuesta preferida.

e)Preguntas que se interpretaran en forma diferente dependiendo del marco de referencia de cada
entrevistado.
f) Preguntas que no proporcionan opciones adecuadas de respuesta.
g)Un ordenamiento no adecuado de las preguntas y respuestas.
• Pruébelo previamente en un grupo pequeño para detectar problemas posibles
5
• Analice la respuesta del grupo de prueba para asegurar que el
análisis de los datos que se busca se puede llevar a cabo con los
datos recopilados. Si los datos no revelan algo que el analista no
6 conoce, el cuestionario puede no ser necesario.
• Realice cambios finales de edición e imprimalo en una forma

legible
7
• Distribuya el cuestionario. Cuando sea posible anote el nombre de

cada persona.
8

Formulario para entrevista de
toma de requisitos

Especificación de
Requisitos del Sistema
Objetivo de la Especificación de Requisitos del Sistema
El objetivo principal de la Especificación de Requisitos del Sistema
(ERS) es servir como medio de comunicación entre clientes, usuarios, ingenieros de
requisitos y desarrolladores.
En la ERS deben recogerse tanto las necesidades de clientes y usuarios (necesidades del
negocio, también conocidas como requisitos de usuario, requisitos de cliente,
necesidades de usuario, etc.) como los requisitos que debe cumplir el sistema software a
desarrollar para satisfacer dichas necesidades (requisitos del producto, también
conocidos como requisitos de sistema o requisitos software).
La ERS debe ser un documento consensuado entre todas las partes y tener un
carácter contractual, de forma que cualquier cambio que se desee realizar en él una
vez acordada la primera línea base deba aplicarse siguiendo el Procedimiento de
Control de Cambios establecido en el proyecto.
Empecemos
la Clase!!!!

Visión General del El Proceso Unificado (RUP) es un proceso de desarrollo de
Proceso Unificado software:“Conjunto de actividades necesarias para transformar
los requisitos del usuario en un sistema software”.
❑RUP es un marco genérico que puede especializarse para una

variedad de tipos de sistemas, diferentes áreas de aplicación,
tipos de organizaciones, niveles de aptitud y diferentes
tamaños de proyectos.
❑RUP está basado en componentes. El software esta formado
por componentes interconectados a través de interfaces.
❑RUP está dirigido por casos de uso, centrado en la arquitectura,
y es iterativo e incremental.
Dirigidos por Caso de Uso
➢ Un caso de uso es un fragmento de funcionalidad del sistema

que proporciona un resultado de valor a un usuario. Los casos
de uso modelan los requerimientos funcionales del sistema.
➢ Todos los casos de uso juntos constituyen el modelo de casos de uso.
➢ Los casos de uso también guían el proceso de desarrollo (diseño, implementación, y

prueba). Basándose en los casos de uso los desarrolladores crean una serie de
modelos de diseño e implementación que llevan a cabo los casos de uso. De este
modo los casos de uso no solo inician el proceso de desarrollo sino que le
proporcionan un hilo conductor, avanza a través de una serie de flujos de trabajo que
parten de los casos de uso.

Centrado en la Arquitectura
Arquitectura: Conjunto de decisiones significativas acerca de la

organización de un sistema software, la selección de los elementos
estructurales a partir de los cuales se compone el sistema, las interfaces entre ellos,
su comportamiento, sus colaboraciones, y su composición.
❑ La arquitectura de un sistema software se describe mediante diferentes vistas

del sistema en construcción.
❑ El concepto de arquitectura software incluye los aspectos estáticos y dinámicos
más significativos del sistema.
❑ La arquitectura es una vista del diseño completo con las características más
importantes resaltadas, dejando los detalles de lado.

Iterativo e Incremental
❑ Es práctico dividir el esfuerzo de desarrollo de un proyecto de

software en partes más pequeñas o mini proyectos.
❑ Cada mini proyecto es una iteración que resulta en un incremento.
❑ Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos a
crecimientos en el producto.
❑ Las iteraciones deben estar controladas. Esto significa que deben seleccionarse y
ejecutarse de una forma planificada.
❑ Los desarrolladores basan la selección de lo que implementarán en cada iteración en
dos cosas: el conjunto de casos de uso que amplían la funcionalidad, y en los riesgos
más importantes que deben mitigarse.
❑ En cada iteración los desarrolladores identifican y especifican los casos de uso
relevantes, crean un diseño utilizando la arquitectura seleccionada como guía, para
implementar dichos casos de uso.
2. m. En las obras de ingenio y en las acciones
morales, ejemplar que por su perfección se
debe seguir e imitar.
1. m. Arquetipo o punto de referencia Sin.:
para imitarlo o reproducirlo. ejemplo, paradigma, dechado, espejo, ideal.
Sin.: 3. m. Representación en pequeño de alguna
arquetipo, prototipo, original, patrón, cosa.
ejemplar, machote. Sin.:
Ant.: maqueta, miniatura.
copia, imitación, reproducción.

El modelado de sistemas software
es una técnica para tratar con la
complejidad inherente a estos
sistemas. El uso de modelos ayuda
al ingeniero de software a
"visualizar" el sistema a construir.
Además, los modelos de un nivel
de abstracción mayor pueden
utilizarse para la comunicación
con el cliente.

Lenguaje Unificado de
Modelado (UML)
El Lenguaje Unificado de Modelado (UML) fue creado para forjar un

lenguaje de modelado visual común y semántica y sintácticamente
rico para la arquitectura, el diseño y la implementación de sistemas de
software complejos, tanto en estructura como en comportamiento.
UML tiene aplicaciones más allá del desarrollo de software, p. ej., en el
flujo de procesos en la fabricación.
Es comparable a los planos usados en otros campos y consiste en
diferentes tipos de diagramas. En general, los diagramas UML
describen los límites, la estructura y el comportamiento del sistema y
los objetos que contiene.
UML no es un lenguaje de programación, pero existen herramientas
que se pueden usar para generar código en diversos lenguajes usando
los diagramas UML. UML guarda una relación directa con el análisis y el
diseño orientados a objetos.
Características
❖ UML es un lenguaje de modelado para visualizar, especificar,

construir y documentar partes de un sistema software desde
distintos puntos de vista
❖ Puede usarse con cualquier proceso de desarrollo, a lo
largo de todo el ciclo de vida y puede aplicarse a todos
los dominios de aplicación y plataformas de
implementación
❖ También puede usarse en tres áreas, como la ingeniería
de negocio y modelado de procesos gracias a los
mecanismos de adaptación/extensión mediante perfiles
Lo que no es:
❑ UML no es una notación propietaria

❑ UML no es un método, ni un
proceso ni una metodología
❖ El objetivo de UML es la unificación Booch es un método de desarrollo de
de los métodos de modelado de software orientado a objetos Booch se centra
objetos (Booch, OMT y OOSE) por en el modelado visual de sistemas de
medio de la Identificación y definición software utilizando diagramas de clases,
de la semántica de los conceptos diagramas de objetos y diagramas de
fundamentales y elección de una estados.
representación gráfica con una Estos diagramas ayudan a los desarrolladores
sintaxis simple, expresiva e intuitiva a comprender la estructura y el
❖ La especificación UML se define comportamiento de un sistema de software, y
usando el enfoque de un metamodelo a identificar y resolver problemas de diseño.

OMT se basa en el concepto El método desarrollado
de objetos, que son entidades por Ivar Jacobson OOSE
que tienen propiedades y ha sido llamado “un Un modelo de casos de uso
comportamientos. Los enfoque para el manejo describe la funcionalidad
objetos se pueden relacionar de casos de uso”, en este completa del sistema,
entre sí mediante enfoque el modelo de identificando como, todo lo
asociaciones, que son casos de uso sirve como que está fuera del sistema,
conexiones que representan un modelo central del interactúa con él. El modelo
cómo los objetos interactúan cual todos los otros de casos de uso de acuerdo
entre sí. OMT también utiliza modelos son derivados. con Jacobson, es la base en
diagramas para representar la etapa de análisis,
los sistemas de software. construcción y prueba.

El Object
Management Group
(OMG) es un
consorcio, formado
en 1989, dedicado al
cuidado y el
establecimiento de
diversos estándares
de tecnologías
orientadas a objetos

Diagramas y Vistas:
UML define varios modelos para la
representación de los sistemas que pueden
verse y manipularse mediante un conjunto de Diagramas de comportamiento:
diagramas diferentes: • Diagrama de casos de uso
• Diagramas de estructura • Diagrama de actividad
• Diagrama de clases • Diagramas de interacción:
• Diagrama de estructuras compuestas ✓ Diagrama de secuencia
• Diagrama de componentes ✓ Diagrama de comunicación o
• Diagrama de despliegue colaboración
• Diagrama de objetos ✓ Diagrama de visión global de la
• Diagrama de paquetes interacción
✓ Diagrama de tiempo
• Diagrama de maquina de estados
Una vista es un subconjunto de las construcciones de modelado de
UML que representa un aspecto del sistema. Los diagramas UML se
pueden organizar en las siguientes vistas [Rumbaugh et al., 2007]
Vista estática.
Vista de diseño.
✓ Diagramas de clases.
✓ Diagramas de estructuras compuestas.
Vista de casos de uso.
✓ Diagramas de colaboración.
✓ Diagramas de casos de uso.
✓ Diagramas de componentes.
Vista de interacción.
Vista de despliegue.
✓ Diagramas de secuencia.
✓ Diagramas de despliegue.
✓ Diagramas de comunicación.
Vista de gestión del Modelo.
Vista de actividad.
✓ Diagramas de paquetes.
✓ Diagramas de actividad.
Perfiles.
Vista de la máquina de estados.
✓ Diagramas de paquetes.
✓ Diagramas de máquina de estados.
El Proceso Unificado consiste en una serie de disciplinas o flujos
de trabajo que van desde los requisitos hasta las pruebas.
Los flujos de trabajo desarrollan modelos desde el modelo de casos de uso hasta el
modelo de pruebas.

❑ Un caso de uso es una técnica de modelado usada para describir lo
que debería hacer un sistema nuevo o lo que hace un sistema que
ya existe.
✓ Los casos de uso describen bajo la forma de acciones y reacciones el
comportamiento de un sistema desde el punto de vista de un usuario,
permiten definir los límites del sistema y las relaciones entre el sistema y el
entorno.
❑ Los componentes primarios de un modelo de casos de uso (case-use model) son los casos
de uso (use cases), los actores y el sistema modelado.
❑ Los casos de uso son descripciones funcionales del sistema; describen cómo los actores
pueden usar un sistema
✓ Los límites del sistema se definen por la funcionalidad que
se maneja en el sistema.
✓ La funcionalidad se representa mediante diversos casos de
uso, especificando cada uno una funcionalidad completa
(desde su inicio por parte de un actor externo hasta que
haya realizado la funcionalidad requerida). Un caso de uso
siempre debe devolver algún valor a un actor, siendo el
valor cualquier cosa que el actor desee del sistema.
✓ El actor es una entidad externa que tiene interés en
interactuar con el sistema. A menudo, es una persona que
usa el sistema, pero también puede ser otro sistema o
alguna clase de dispositivo hardware que necesita
interactuar con el sistema.
❑En el modelado de casos de uso, el sistema se observa Diagrama de Secuencia
como un caja negra que proporciona casos de uso. Cómo
lo haga el sistema, cómo se implementen los casos de uso
y cómo trabajen internamente no importa.
❑Las clases e interacciones implementan los casos de uso
del sistema.
✓ Las interacciones se expresan en diagramas de
secuencia, colaboración y actividad, así, hay un
Diagrama de Colaboración
enlace entre las vistas funcional y dinámica del
sistema.
✓ Las clases en la implementación de los casos de
uso se modelan y se describen en diagramas de
clases y de estados.
Los propósitos primarios de los casos de uso son:
✓ Decidir y describir los requerimientos funcionales del sistema, dando lugar a un acuerdo
entre el cliente (y/o usuario final) y los programadores que desarrollan el sistema.
✓ Dar una descripción clara y consistente de lo que debería hacer el sistema, de modo que
el modelo se use a lo largo del proceso de desarrollo.
✓ Proporcionar una base para realizar
verificaciones (tests) del sistema que
comprueben su funcionamiento.
✓ Proporcionar la capacidad para rastrear
requerimientos funcionales en clases y
operaciones reales del sistema, verificando
los casos de uso afectados por cambios y
extensiones al sistema.
El modelado de casos de uso también se utiliza cuando se
desarrolla una nueva versión del sistema.
✓ Se añade la nueva funcionalidad al modelo de
casos de uso existente insertando nuevos actores
y casos de uso, o modificando la especificación de
los casos de uso actuales.
Un modelo de casos de uso se describe en UML mediante un
diagrama de casos de uso (use-case diagram) y puede
dividirse en varios diagramas de casos de uso.
Un diagrama de casos de uso contiene elementos del modelo

para el sistema, los actores y los casos de uso, y muestra las
diferentes relaciones entre estos elementos.
Estos diagramas dan una visión del modelo, pero las descripciones
reales de los casos de uso suelen ser textuales, usando el lenguaje
y terminología del cliente/usuario.
Un sistema en un diagrama de casos de

uso se describe mediante un rectángulo
que contiene el nombre del sistema y
los símbolos de los casos de uso en el
sistema.

Un actor es alguien o algo que interactúa con el sistema, pero que
es externo al sistema.
❖ El actor envía o recibe mensajes a y desde el
sistema, o intercambia información con el sistema.
❖ Un caso de uso siempre es iniciado por un actor
que le envía un mensaje o estímulo (stimulus). Los
actores llevan a cabo casos de uso.
❖ Cuando un caso de uso se realiza, el caso de uso
podría enviar mensajes a uno o más actores. Estos
mensajes también puede ir a otros actores
además del que inició el caso de uso.

Un actor es una clase, no una instancia. El actor representa un
papel, no a un usuario individual del sistema.
❖ Por ejemplo, una persona puede ser
diferentes actores en el sistema,
dependiendo de su papel en éste.
❖ Los papeles que una persona puede
tener en un sistema pueden estar
restringidos. Por ejemplo, puede estar
prohibido que la misma persona registre
una factura y la apruebe.
❖ Un actor tiene un nombre que debería
reflejar el papel del actor.

Para identificar los actores, se establecen las entidades interesadas
en usar e interactuar con el sistema:
❖ Los usuarios de la funcionalidad principal del sistema (actores primarios). Por ejemplo,
en un sistema de seguros, un actor primario podría ser uno que maneja el registro y
administración de los seguros.
❖ Los que mantienen, administran y tienen el sistema en funcionamiento (actores
secundarios). Un ejemplo de actor secundario podría ser una tarjeta que usa las
funciones del sistema para recuperar estadísticas sobre los negocios o la compañía.
❖ Los dispositivos hardware que necesita manejar el sistema.
❖ Los otros sistemas con que necesita interactuar, que incluyen otros sistemas
computadores, así como otras aplicaciones en el computador en que operará este
sistema.
❖ Los que tienen interés en los resultados que produce el sistema.
Un actor debe tener alguna asociación con uno o más casos de
uso.
❖ Aunque un actor podría no
iniciar un caso de uso, ese
actor se comunicará con uno
en algún punto.
❖ Un actor activo inicia un caso
de uso, mientras que un actor
pasivo nunca inicia un caso de
uso, sino que sólo participa en
uno o más casos de uso.

Los actores en UML son clases con el estereotipo <<actor>> y tienen
un estereotipo icono estándar. El nombre de la clase es el nombre
del actor.
❖ Una clase actor puede tener atributos y comportamiento.
❖ Los actores pueden tener las mismas relaciones que las
clases.
Cuando varios actores, como parte de sus papeles, también

representan un papel más generalizado, se describe
mediante una relación de generalización.
❖ El comportamiento del papel general se describe en una
superclase actor. Los actores especializados heredan el
comportamiento de la superclase y extienden ese
comportamiento de algún modo.
Un caso de uso representa una funcionalidad completa tal como la
percibe un actor.
Un caso de uso en UML se define como una secuencia de acciones que realiza un sistema y que
conduce a un resultado observable.
❖ Las acciones pueden envolver comunicación con diversos actores (usuarios y otros sistemas) así
como realización de cálculos y trabajos dentro del sistema.
❖ Las características de un caso de uso son:
✓ Un caso de uso siempre es iniciado por un actor: se realiza en interés de un actor que,
directa o indirectamente, debe ordenar al sistema que inicie el caso de uso.
✓ Un caso de uso proporciona un valor a un actor: debe entregar alguna clase de valor
tangible para el usuario.
✓ Un caso de uso es completo: debe ser una descripción completa. Un caso de uso no está
completo hasta que se produce el valor final, incluso si a lo largo del camino ocurren varias
comunicaciones (tales como diálogos con el usuario).
Un caso de uso se representa en UML mediante una elipse que
contiene el nombre del caso de uso, o con el nombre del caso de uso
debajo.
Los casos de uso se conectan a los actores mediante
asociaciones, denominadas líneas de comunicación
(communication lines).
❖ Las asociaciones muestran con qué actores se
comunica el caso de uso, incluyendo el actor que
inicia la ejecución del caso de uso.
❖ La asociación normalmente es una relación uno a
uno sin dirección. Esto significa que una instancia de
actor se comunica con una instancia de caso de uso y
que pueden comunicarse en ambas direcciones.
Un caso de uso es un tipo de clasificador que describe la
funcionalidad como un todo, incluyendo posibles alternativas,
errores y excepciones que puedan ocurrir durante la ejecución del caso de uso en
colaboración con uno o más actores.
Los casos de uso se determinan precisando actor por actor:
❖Las funciones que requiere el actor del sistema, si el actor necesita leer, crear, destruir,
modificar o almacenar alguna clase de información en el sistema.
❖Si hay que informar al actor de los eventos del sistema o el actor necesita notificar algo al
sistema y qué representan esos eventos en términos de funcionalidad.
❖Si se podría simplificar o hacer más eficiente el trabajo del actor añadiendo nuevas
funciones del sistema.
❖Las entradas/salidas que necesita el sistema.
❖Los principales problemas de la implementación actual del sistema.

Cualquier duda o consulta escribir al:
correo
Página web
repasovirtual.jimdofree.com
Mi FanPage
https://www.facebook.com/AsesoriaEducativa.JDDH
Feliz Navidad
Eres dueño de tu propio destino!!!!!
Gracias Totales!!!

Clase 05 Tecnicas de Busqueda de Requerimientos 22 12 23

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Clase 05 Tecnicas de Busqueda de Requerimientos 22 12 23

Cargado por

Copyright:

Formatos disponibles

CARRERA: DESARROLLO DE SISTEMAS DE INFORMACION

Clase 5: Visión General del Proceso Unificado. Lenguaje Unificado de Modelado

2. Sólo active su micrófono si va a participar,

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

4 d)Preguntas que están escritas de forma que se escogerá la respuesta preferida.

• Pruébelo previamente en un grupo pequeño para detectar problemas posibles

• Realice cambios finales de edición e imprimalo en una forma

• Distribuya el cuestionario. Cuando sea posible anote el nombre de

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

❑RUP es un marco genérico que puede especializarse para una

➢ Un caso de uso es un fragmento de funcionalidad del sistema

➢ Los casos de uso también guían el proceso de desarrollo (diseño, implementación, y

Prof. Juan Daniel Daza Hermoza

Arquitectura: Conjunto de decisiones significativas acerca de la

❑ La arquitectura de un sistema software se describe mediante diferentes vistas

Prof. Juan Daniel Daza Hermoza

❑ Es práctico dividir el esfuerzo de desarrollo de un proyecto de

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un

❖ UML es un lenguaje de modelado para visualizar, especificar,

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Un diagrama de casos de uso contiene elementos del modelo

Un sistema en un diagrama de casos de

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Prof. Juan Daniel Daza Hermoza

Cuando varios actores, como parte de sus papeles, también

Prof. Juan Daniel Daza Hermoza

También podría gustarte