SlideShare una empresa de Scribd logo
AÑO DE LA CONSOLIDACIÓN DEL MAR DE
GRAU
INSTITUTO SUPERIOR TECNOLÓGICO PRIVADO
“JUAN MEJÍA BACA”
CURSO:
INGENIERIA DE SOFTWARE I
TEMA:
DIAGRAMAS DE CASOS DE USO
GRUPO:
Trabajogrupalsoftware
INTEGRANTES:
Victor Hugo Vasquez Vallejos
Erika Inga Milian
CICLO: TURNO: CODIGO:
V NOCHE
1615NA
ESPECIALIDAD:
COMPUTACIÓN E INFORMÁTICA
DOCENTE:
MARCO AURELIO PORRO CHULLI
DIAGRAMAS DE CASO DE USO
DEFINICION:
En el Lenguaje de Modelado Unificado,
un diagrama de casos de uso es una forma
de diagrama de comportamiento UML
mejorado. El Lenguaje de Modelado
Unificado (UML), define una notación
gráfica para representar casos de uso
llamada modelo de casos de uso.
Los diagramas de casos de uso son a
menudo confundidos con los casos de uso.
Mientras los dos conceptos están
relacionados, los casos de uso son mucho
más detallados que los diagramas de casos
de uso. En los conceptos se debe detallar
más de un caso de uso para poder identificar
qué es lo que hace un caso de uso.
 La descripción escrita del comportamiento del
sistema al afrontar una tarea de negocio o
un requisito de negocio. Esta descripción se
enfoca en el valor suministrado por el sistema a
entidades externas tales como usuarios humanos
u otros sistemas.
 La posición o contexto del caso de uso entre otros
casos de uso. Dado que es un mecanismo de
organización, un conjunto de casos de uso
coherentes y consistentes promueven una imagen
fácil de comprender del comportamiento del
sistema, un entendimiento común entre el
cliente/propietario/usuario y el equipo de
desarrollo.
 En esta práctica es común crear especificaciones
suplementarias para capturar detalles de requisitos
que caen fuera del ámbito de las descripciones de
los casos de uso. Ejemplos de esos temas
incluyen restricciones de diseño como:
rendimiento, temas de escalabilidad/gestión, o
cumplimiento de estándares.
ELEMENTOS DE CASO DE USO
 Caso de uso
Un caso de uso describe, —desde el punto de vista de los actores—, un grupo de actividades de un
sistema que produce un resultado concreto y tangible.
Los casos de uso son descriptores de las interacciones típicas entre los usuarios de un sistema y ese
mismo sistema. Representan el interfaz externo del sistema y especifican qué requisitos de funcionamiento
debe tener este (recuerde, únicamente el qué, nunca el cómo).
Cuando se trabaja con casos de uso, es importante tener presentes algunas sencillas reglas:
Cada caso de uso está relacionado como mínimo con un actor
Cada caso de uso es un iniciador (es decir, un actor)
Cada caso de uso lleva a un resultado relevante (un resultado con «valor intrínseco»)
Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones más
comunes entre casos de uso son:
<<include>> que especifica una situación en la que un caso de uso tiene lugar dentro de otro caso de uso
<<extends>> que especifica que en ciertas situaciones, o en algún punto (llamado punto de extensión) un
caso de uso será extendido por otro.
Generalización que especifica que un caso de uso hereda las características del «super» caso de uso, y
puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases.
 Actor
Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y
normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del
sistema), otros ordenadores o eventos externos.
Los actores no representan a personas físicas o a sistemas, sino su rol. Esto significa que cuando una
persona interactúa con el sistema de diferentes maneras (asumiendo diferentes papeles), estará
representado por varios actores. Por ejemplo, una persona que proporciona servicios de atención telefónica
a clientes y realiza pedidos para los clientes estaría representada por un actor «equipo de soporte» y por
otro actor «representante de ventas».
Relaciones de Casos de Uso
Las tres relaciones principales entre los casos de uso son soportadas por el
estándar UML, el cual describe notación gráfica para esas relaciones. Veamos una
revisión de ellas a continuación:
 Inclusión (include )
Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro
caso de uso. El primer caso de uso a menudo depende del resultado del caso de
uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes
desde múltiples casos de uso a una descripción individual(si el actor realiza el
caso de uso base tendrá que realizar también el caso de uso incluido), desde
el caso de uso. El estándar de Lenguaje de Modelado Unificado de OMG define
una notación gráfica para realizar diagramas de casos de uso, pero no el formato
para describir casos de uso. Mucha gente sufre la equivocación pensando que un
caso de uso es una notación gráfica (o es su descripción). Mientras la notación
gráfica y las descripciones esto no sirve.
*Extensión (extend)
Es otra forma de interacción, un caso de uso dado (la extensión)
puede extender a otro. Esta relación indica que el comportamiento del caso
de la extensión se utiliza en casos de uso, un caso de uso a otro caso
siempre debe tener extensión o inclusión. El caso de uso extensión puede
ser insertado en el caso de uso extendido bajo ciertas condiciones. La
notación, es una flecha de punta abierta con línea discontinua, desde el
caso de uso extensión al caso de uso extendido, con la etiqueta «extend».
Esto puede ser útil para lidiar con casos especiales, o para acomodar
nuevos requisitos durante el mantenimiento del sistema y su extensión .
"La extensión, es el conjunto de objetos a los que se aplica un concepto.
Los objetos de la extensión son los ejemplos o instancias de los
conceptos."
documentan el comportamiento de un sistema desde el punto de vista de
un usuario
En otras palabras será utilizado cuando un caso de uso sea similar a otro
pero con ciertas variaciones, un ejemplo claro es que se necesite comprar
azúcar y podemos seleccionar de entre azúcar rubia, blanca o su unidad
de medida bolsa , kilo, etc.
 Generalización
"Entonces la Generalización es la actividad de identificar elementos
en común entre conceptos y definir las relaciones de una
superclase (concepto general) y subclase (concepto especializado).
Es una manera de construir clasificaciones taxonómicas entre
conceptos que entonces se representan en jerarquías de clases.
Las subclases conceptuales son conformes con las superclases
conceptuales en cuanto a la intención y extensión."
En la tercera forma de relaciones entre casos de uso, existe una
relación generalización/especialización. Un caso de uso dado puede
estar en una forma especializada de un caso de uso existente. La
notación es una línea sólida terminada en un triángulo dibujado
desde el caso de uso especializado al caso de uso general. Esto se
asemeja al concepto orientado a objetos de sub-clases, en la
práctica puede ser útil factorizar comportamientos comunes,
restricciones al caso de uso general, describirlos una vez, y
enfrentarse a los detalles excepcionales en los casos de uso
especializados.
Diagramas de caso de uso porro
Diagramas de caso de uso porro

Más contenido relacionado

La actualidad más candente

Casos de Uso ejercicios
Casos de Uso ejerciciosCasos de Uso ejercicios
Casos de Uso ejercicios
Walter Chacon
 
Analisis y diseño diagrama de caso de uso
Analisis y diseño diagrama de caso de usoAnalisis y diseño diagrama de caso de uso
Analisis y diseño diagrama de caso de uso
Yovana Connie Roca Avila
 
Consejos para escribir buenos casos de uso
Consejos para escribir buenos casos de usoConsejos para escribir buenos casos de uso
Consejos para escribir buenos casos de uso
kaolong
 

La actualidad más candente (20)

Diagramas de caso de uso1
Diagramas de caso de uso1Diagramas de caso de uso1
Diagramas de caso de uso1
 
Casos de Uso ejercicios
Casos de Uso ejerciciosCasos de Uso ejercicios
Casos de Uso ejercicios
 
Diagramas De Caso De Uso
Diagramas De Caso De UsoDiagramas De Caso De Uso
Diagramas De Caso De Uso
 
Casos de Uso en UML
Casos de Uso en UMLCasos de Uso en UML
Casos de Uso en UML
 
UML: CASOS DE USO
UML: CASOS DE USOUML: CASOS DE USO
UML: CASOS DE USO
 
Casos de uso
Casos de usoCasos de uso
Casos de uso
 
Diagramas de Casos de Uso del Negocio y del Sistema
 Diagramas de Casos de Uso del Negocio y del Sistema Diagramas de Casos de Uso del Negocio y del Sistema
Diagramas de Casos de Uso del Negocio y del Sistema
 
Modelado de caso de uso y Diagrama de Caso de Uso
Modelado de caso de uso  y Diagrama de Caso de UsoModelado de caso de uso  y Diagrama de Caso de Uso
Modelado de caso de uso y Diagrama de Caso de Uso
 
Gonzalorojas 07 U M L, Casos De Uso ( Final)
Gonzalorojas 07  U M L,  Casos De  Uso ( Final)Gonzalorojas 07  U M L,  Casos De  Uso ( Final)
Gonzalorojas 07 U M L, Casos De Uso ( Final)
 
Caso De Uso
Caso De UsoCaso De Uso
Caso De Uso
 
Diagramas Casos de Uso
Diagramas Casos de UsoDiagramas Casos de Uso
Diagramas Casos de Uso
 
Analisis y diseño diagrama de caso de uso
Analisis y diseño diagrama de caso de usoAnalisis y diseño diagrama de caso de uso
Analisis y diseño diagrama de caso de uso
 
Consejos para escribir buenos casos de uso
Consejos para escribir buenos casos de usoConsejos para escribir buenos casos de uso
Consejos para escribir buenos casos de uso
 
Introducción a UML y Diagrama de Casos de Uso
Introducción a UML y Diagrama de Casos de UsoIntroducción a UML y Diagrama de Casos de Uso
Introducción a UML y Diagrama de Casos de Uso
 
Casos de uso
Casos de usoCasos de uso
Casos de uso
 
Uml diagramas-caso-de-uso
Uml diagramas-caso-de-usoUml diagramas-caso-de-uso
Uml diagramas-caso-de-uso
 
Como Documentar Casos De Uso
Como Documentar Casos De UsoComo Documentar Casos De Uso
Como Documentar Casos De Uso
 
Modelado de casos de uso
Modelado de casos de usoModelado de casos de uso
Modelado de casos de uso
 
Modelado de casos de uso
Modelado de casos de usoModelado de casos de uso
Modelado de casos de uso
 
Unidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De UsoUnidad 4 Mad Modelado Analisis Casos De Uso
Unidad 4 Mad Modelado Analisis Casos De Uso
 

Similar a Diagramas de caso de uso porro

05 Casos Uso Bis
05 Casos Uso Bis05 Casos Uso Bis
05 Casos Uso Bis
Carylu
 
9 Clase Captura De Los Requisitosa 9 10
9 Clase Captura De Los Requisitosa 9 109 Clase Captura De Los Requisitosa 9 10
9 Clase Captura De Los Requisitosa 9 10
Julio Pari
 
9 Clase Captura De Los Requisitosa 9 10
9 Clase Captura De Los Requisitosa 9 109 Clase Captura De Los Requisitosa 9 10
9 Clase Captura De Los Requisitosa 9 10
Julio Pari
 
tarea dce analisis
tarea dce analisistarea dce analisis
tarea dce analisis
guestbe2e66d
 

Similar a Diagramas de caso de uso porro (20)

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
 
Caso de uso
Caso de usoCaso de uso
Caso de uso
 
04 casos de uso
04   casos de uso04   casos de uso
04 casos de uso
 
Diagrama de dominio armando
Diagrama de dominio armandoDiagrama de dominio armando
Diagrama de dominio armando
 
Diagramas Uml
Diagramas UmlDiagramas Uml
Diagramas Uml
 
05 Casos Uso Bis
05 Casos Uso Bis05 Casos Uso Bis
05 Casos Uso Bis
 
Tms 03 modelo_negocio
Tms 03 modelo_negocioTms 03 modelo_negocio
Tms 03 modelo_negocio
 
UML: CASOS DE USO
UML: CASOS DE USOUML: CASOS DE USO
UML: CASOS DE USO
 
Tania
TaniaTania
Tania
 
Presentacion Casos De Uso1
Presentacion Casos De Uso1Presentacion Casos De Uso1
Presentacion Casos De Uso1
 
Casos de uso 2016 Lina diagrama Ade casos de suso
Casos de uso  2016 Lina diagrama Ade casos de susoCasos de uso  2016 Lina diagrama Ade casos de suso
Casos de uso 2016 Lina diagrama Ade casos de suso
 
diagramas-de-casos-de-uso.ppt
diagramas-de-casos-de-uso.pptdiagramas-de-casos-de-uso.ppt
diagramas-de-casos-de-uso.ppt
 
9 Clase Captura De Los Requisitosa 9 10
9 Clase Captura De Los Requisitosa 9 109 Clase Captura De Los Requisitosa 9 10
9 Clase Captura De Los Requisitosa 9 10
 
9 Clase Captura De Los Requisitosa 9 10
9 Clase Captura De Los Requisitosa 9 109 Clase Captura De Los Requisitosa 9 10
9 Clase Captura De Los Requisitosa 9 10
 
Dario ramirez
Dario ramirezDario ramirez
Dario ramirez
 
Dario ramirez
Dario ramirezDario ramirez
Dario ramirez
 
Diagramas UML
Diagramas UMLDiagramas UML
Diagramas UML
 
Dario ramirez
Dario ramirezDario ramirez
Dario ramirez
 
tarea dce analisis
tarea dce analisistarea dce analisis
tarea dce analisis
 
Uml
UmlUml
Uml
 

Más de Trabajos Grupal Ing de Software (10)

Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de software
 
CALIDAD DE SOFTWARE
CALIDAD DE SOFTWARECALIDAD DE SOFTWARE
CALIDAD DE SOFTWARE
 
Modelo COCOMO
Modelo COCOMOModelo COCOMO
Modelo COCOMO
 
DIAGRAMA DE COMPONENTES
DIAGRAMA DE COMPONENTESDIAGRAMA DE COMPONENTES
DIAGRAMA DE COMPONENTES
 
Diagramas de despliegue
Diagramas de despliegueDiagramas de despliegue
Diagramas de despliegue
 
Diagrama de actividades
Diagrama de actividadesDiagrama de actividades
Diagrama de actividades
 
Diagrama de interaccion
Diagrama de interaccionDiagrama de interaccion
Diagrama de interaccion
 
Metodologias rup
Metodologias rupMetodologias rup
Metodologias rup
 
Clasificaion de las metodologias de desarrollo de software
Clasificaion de las metodologias de desarrollo de softwareClasificaion de las metodologias de desarrollo de software
Clasificaion de las metodologias de desarrollo de software
 
Ingenieria de software i
Ingenieria de software   iIngenieria de software   i
Ingenieria de software i
 

Último

Tema 14. Aplicación de Diagramas 26-05-24.pptx
Tema 14. Aplicación de Diagramas 26-05-24.pptxTema 14. Aplicación de Diagramas 26-05-24.pptx
Tema 14. Aplicación de Diagramas 26-05-24.pptx
Noe Castillo
 
PRÁCTICAS PEDAGOGÍA.pdf_Educación Y Sociedad_AnaFernández
PRÁCTICAS PEDAGOGÍA.pdf_Educación Y Sociedad_AnaFernándezPRÁCTICAS PEDAGOGÍA.pdf_Educación Y Sociedad_AnaFernández
PRÁCTICAS PEDAGOGÍA.pdf_Educación Y Sociedad_AnaFernández
Ruben53283
 
evalaución de reforzamiento de cuarto de secundaria de la competencia lee
evalaución de reforzamiento de cuarto de secundaria de la competencia leeevalaución de reforzamiento de cuarto de secundaria de la competencia lee
evalaución de reforzamiento de cuarto de secundaria de la competencia lee
MaribelGaitanRamosRa
 
Presentación de medicina Enfermedades Fotográfico Moderno Morado (1).pdf
Presentación de medicina Enfermedades Fotográfico Moderno Morado (1).pdfPresentación de medicina Enfermedades Fotográfico Moderno Morado (1).pdf
Presentación de medicina Enfermedades Fotográfico Moderno Morado (1).pdf
juancmendez1405
 
diagnostico final (1). analisis - encuestas
diagnostico final (1). analisis - encuestasdiagnostico final (1). analisis - encuestas
diagnostico final (1). analisis - encuestas
ansomora123
 
Productos contestatos de la Séptima sesión ordinaria de CTE y TIFC para Docen...
Productos contestatos de la Séptima sesión ordinaria de CTE y TIFC para Docen...Productos contestatos de la Séptima sesión ordinaria de CTE y TIFC para Docen...
Productos contestatos de la Séptima sesión ordinaria de CTE y TIFC para Docen...
Monseespinoza6
 

Último (20)

CALENDARIZACION DEL MES DE JUNIO - JULIO 24
CALENDARIZACION DEL MES DE JUNIO - JULIO 24CALENDARIZACION DEL MES DE JUNIO - JULIO 24
CALENDARIZACION DEL MES DE JUNIO - JULIO 24
 
Tema 14. Aplicación de Diagramas 26-05-24.pptx
Tema 14. Aplicación de Diagramas 26-05-24.pptxTema 14. Aplicación de Diagramas 26-05-24.pptx
Tema 14. Aplicación de Diagramas 26-05-24.pptx
 
Sesión de clase: Luz desde el santuario.pdf
Sesión de clase: Luz desde el santuario.pdfSesión de clase: Luz desde el santuario.pdf
Sesión de clase: Luz desde el santuario.pdf
 
Portafolio de servicios Centro de Educación Continua EPN
Portafolio de servicios Centro de Educación Continua EPNPortafolio de servicios Centro de Educación Continua EPN
Portafolio de servicios Centro de Educación Continua EPN
 
Fase 3; Estudio de la Geometría Analítica
Fase 3; Estudio de la Geometría AnalíticaFase 3; Estudio de la Geometría Analítica
Fase 3; Estudio de la Geometría Analítica
 
PRÁCTICAS PEDAGOGÍA.pdf_Educación Y Sociedad_AnaFernández
PRÁCTICAS PEDAGOGÍA.pdf_Educación Y Sociedad_AnaFernándezPRÁCTICAS PEDAGOGÍA.pdf_Educación Y Sociedad_AnaFernández
PRÁCTICAS PEDAGOGÍA.pdf_Educación Y Sociedad_AnaFernández
 
5.Deicticos Uno_Enfermería_EspanolAcademico
5.Deicticos Uno_Enfermería_EspanolAcademico5.Deicticos Uno_Enfermería_EspanolAcademico
5.Deicticos Uno_Enfermería_EspanolAcademico
 
1º GRADO CONCLUSIONES DESCRIPTIVAS PRIMARIA.docx
1º GRADO CONCLUSIONES DESCRIPTIVAS  PRIMARIA.docx1º GRADO CONCLUSIONES DESCRIPTIVAS  PRIMARIA.docx
1º GRADO CONCLUSIONES DESCRIPTIVAS PRIMARIA.docx
 
3.Conectores uno_Enfermería_EspAcademico
3.Conectores uno_Enfermería_EspAcademico3.Conectores uno_Enfermería_EspAcademico
3.Conectores uno_Enfermería_EspAcademico
 
32 LECTURAS CORTAS PARA NIÑOS.pdf · versión 1.pdf
32 LECTURAS CORTAS PARA NIÑOS.pdf · versión 1.pdf32 LECTURAS CORTAS PARA NIÑOS.pdf · versión 1.pdf
32 LECTURAS CORTAS PARA NIÑOS.pdf · versión 1.pdf
 
evalaución de reforzamiento de cuarto de secundaria de la competencia lee
evalaución de reforzamiento de cuarto de secundaria de la competencia leeevalaución de reforzamiento de cuarto de secundaria de la competencia lee
evalaución de reforzamiento de cuarto de secundaria de la competencia lee
 
Presentación de medicina Enfermedades Fotográfico Moderno Morado (1).pdf
Presentación de medicina Enfermedades Fotográfico Moderno Morado (1).pdfPresentación de medicina Enfermedades Fotográfico Moderno Morado (1).pdf
Presentación de medicina Enfermedades Fotográfico Moderno Morado (1).pdf
 
PRESENTACION DE LA SEMANA NUMERO 8 EN APLICACIONES DE INTERNET
PRESENTACION DE LA SEMANA NUMERO 8 EN APLICACIONES DE INTERNETPRESENTACION DE LA SEMANA NUMERO 8 EN APLICACIONES DE INTERNET
PRESENTACION DE LA SEMANA NUMERO 8 EN APLICACIONES DE INTERNET
 
diagnostico final (1). analisis - encuestas
diagnostico final (1). analisis - encuestasdiagnostico final (1). analisis - encuestas
diagnostico final (1). analisis - encuestas
 
Evaluación de los Factores Internos de la Organización
Evaluación de los Factores Internos de la OrganizaciónEvaluación de los Factores Internos de la Organización
Evaluación de los Factores Internos de la Organización
 
Poemas de Beatriz Giménez de Ory_trabajos de 6º
Poemas de Beatriz Giménez de Ory_trabajos de 6ºPoemas de Beatriz Giménez de Ory_trabajos de 6º
Poemas de Beatriz Giménez de Ory_trabajos de 6º
 
ACERTIJO DE CARRERA OLÍMPICA DE SUMA DE LABERINTOS. Por JAVIER SOLIS NOYOLA
ACERTIJO DE CARRERA OLÍMPICA DE SUMA DE LABERINTOS. Por JAVIER SOLIS NOYOLAACERTIJO DE CARRERA OLÍMPICA DE SUMA DE LABERINTOS. Por JAVIER SOLIS NOYOLA
ACERTIJO DE CARRERA OLÍMPICA DE SUMA DE LABERINTOS. Por JAVIER SOLIS NOYOLA
 
Productos contestatos de la Séptima sesión ordinaria de CTE y TIFC para Docen...
Productos contestatos de la Séptima sesión ordinaria de CTE y TIFC para Docen...Productos contestatos de la Séptima sesión ordinaria de CTE y TIFC para Docen...
Productos contestatos de la Séptima sesión ordinaria de CTE y TIFC para Docen...
 
Presentación Revistas y Periódicos Digitales
Presentación Revistas y Periódicos DigitalesPresentación Revistas y Periódicos Digitales
Presentación Revistas y Periódicos Digitales
 
corpus-christi-sesion-de-aprendizaje.pdf
corpus-christi-sesion-de-aprendizaje.pdfcorpus-christi-sesion-de-aprendizaje.pdf
corpus-christi-sesion-de-aprendizaje.pdf
 

Diagramas de caso de uso porro

  • 1. AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU INSTITUTO SUPERIOR TECNOLÓGICO PRIVADO “JUAN MEJÍA BACA” CURSO: INGENIERIA DE SOFTWARE I TEMA: DIAGRAMAS DE CASOS DE USO GRUPO: Trabajogrupalsoftware INTEGRANTES: Victor Hugo Vasquez Vallejos Erika Inga Milian CICLO: TURNO: CODIGO: V NOCHE 1615NA ESPECIALIDAD: COMPUTACIÓN E INFORMÁTICA DOCENTE: MARCO AURELIO PORRO CHULLI
  • 2. DIAGRAMAS DE CASO DE USO DEFINICION: En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una forma de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado (UML), define una notación gráfica para representar casos de uso llamada modelo de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso. En los conceptos se debe detallar más de un caso de uso para poder identificar qué es lo que hace un caso de uso.
  • 3.  La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.  La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes y consistentes promueven una imagen fácil de comprender del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.  En esta práctica es común crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen restricciones de diseño como: rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.
  • 4. ELEMENTOS DE CASO DE USO  Caso de uso Un caso de uso describe, —desde el punto de vista de los actores—, un grupo de actividades de un sistema que produce un resultado concreto y tangible. Los casos de uso son descriptores de las interacciones típicas entre los usuarios de un sistema y ese mismo sistema. Representan el interfaz externo del sistema y especifican qué requisitos de funcionamiento debe tener este (recuerde, únicamente el qué, nunca el cómo). Cuando se trabaja con casos de uso, es importante tener presentes algunas sencillas reglas: Cada caso de uso está relacionado como mínimo con un actor Cada caso de uso es un iniciador (es decir, un actor) Cada caso de uso lleva a un resultado relevante (un resultado con «valor intrínseco») Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones más comunes entre casos de uso son: <<include>> que especifica una situación en la que un caso de uso tiene lugar dentro de otro caso de uso <<extends>> que especifica que en ciertas situaciones, o en algún punto (llamado punto de extensión) un caso de uso será extendido por otro. Generalización que especifica que un caso de uso hereda las características del «super» caso de uso, y puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases.  Actor Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del sistema), otros ordenadores o eventos externos. Los actores no representan a personas físicas o a sistemas, sino su rol. Esto significa que cuando una persona interactúa con el sistema de diferentes maneras (asumiendo diferentes papeles), estará representado por varios actores. Por ejemplo, una persona que proporciona servicios de atención telefónica a clientes y realiza pedidos para los clientes estaría representada por un actor «equipo de soporte» y por otro actor «representante de ventas».
  • 5. Relaciones de Casos de Uso Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe notación gráfica para esas relaciones. Veamos una revisión de ellas a continuación:  Inclusión (include ) Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro caso de uso. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción individual(si el actor realiza el caso de uso base tendrá que realizar también el caso de uso incluido), desde el caso de uso. El estándar de Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocación pensando que un caso de uso es una notación gráfica (o es su descripción). Mientras la notación gráfica y las descripciones esto no sirve.
  • 6. *Extensión (extend) Es otra forma de interacción, un caso de uso dado (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de la extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusión. El caso de uso extensión puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión . "La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensión son los ejemplos o instancias de los conceptos." documentan el comportamiento de un sistema desde el punto de vista de un usuario En otras palabras será utilizado cuando un caso de uso sea similar a otro pero con ciertas variaciones, un ejemplo claro es que se necesite comprar azúcar y podemos seleccionar de entre azúcar rubia, blanca o su unidad de medida bolsa , kilo, etc.
  • 7.  Generalización "Entonces la Generalización es la actividad de identificar elementos en común entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonómicas entre conceptos que entonces se representan en jerarquías de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intención y extensión." En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea sólida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la práctica puede ser útil factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.