Diagrama De Casos De Uso 2 Punto

Diagrama De La Practica Caso Dos

Formato De Casos De Uso

Diagrama De La Practica Caso Uno

Formato De Casos De Uso

1. Un caso de uso especifica un comportamiento deseado del sistema.

Representan los requisitos funcionales del sistema.

“Un caso de uso especifica un conjunto de secuencias de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor.”                                               

Describen qué hace el sistema, no cómo lo hace.

2. ¿Por que el caso de uso es una herramienta valiosa?

Por que es un poderoso consecto que ayuda a un analista a comprender la forma en que debe comportarse el sistema. Le ayuda a obtener los requerimientos desde el punto de vista del usuario.

3. Cual es el propósito primario del modelo de caso de uso?

se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

Aparte de mejorar una comunicación entre el analista y el usuario final.

4. ¿Que es un diagrama de uso?

Es una representación grafica del entorno del sistema (actores) y su funcionalidad principal (casos de uso), nos muestra los distintos requisitos fucionales que se esperan de una aplicación o sistema y como se relaciona con su entorno(usuarios u otras aplicaciones).

5. ¿Cuales son las preguntas útiles para encontrar actores?

Actores principales y de apoyo. 
Recordemos que los actores principales tienen objetivos de usuario que se satisfacen mediante el uso de los servicios del sistema. Acuden al sistema para que les ayude. Al contrario que los actores de apoyo, que proporcionan servicios al sistema que se está diseñando. Por ahora, nos centraremos en encontrar los actores principales, no los de apoyo. 

Recordemos también que los actores principales pueden ser - entre otras cosas - otros sistemas informáticos, como procesos software "guardianes". 

¿Quién arranca y para el sistema? 
¿Quién gestiona a los usuarios y la seguridad? 
¿Existe un proceso de control que reinicie el sistema si falla? 
¿Quién se encarga de la administración del sistema? 
¿Es un actor el "tiempo" porque el sistema hace algo como respuesta a un evento de tiempo? 
¿Quién evalúa la actividad o el rendimiento del sistema? 
¿Cómo se gestionan las actualizaciones de software? 
¿Actualizaciones automáticas o no? 
¿Quién evalúa los registros? 
¿Se recuperan de manera remota? 

6. Cuales son las preguntas útiles para encontrar casos de uso?

Identificar Nuevos Casos a Partir de los Existentes

Uno de los principales errores que se pueden cometer al identificar requerimientos es algo que parece obvio, pero que muchas veces ocurre: ¡olvidarse de algún requerimiento! Como los requerimientos están en la cabeza de los usuarios, el éxito de esta tarea depende de la habilidad del analista. Para ayudarnos a identificar nuevos casos de uso a partir de los casos existentes, podemos aplicar las mismas técnicas utilizadas para identificar eventos según el análisis estructurado. Algunas de las preguntas que debemos hacernos son:

• ¿Cuáles son las tareas de un actor?
• ¿Necesita el actor estar informado de ciertas ocurrencias del sistema?
• ¿Necesita el actor informar al sistema de cambios externos súbitos?
• ¿Proporciona el sistema el comportamiento correcto al negocio?
• ¿Pueden ser todos los requerimientos funcionales, desarrollados por los casos de uso?
• ¿Qué casos de uso soportarán y mantendrán al sistema?
• ¿Qué información debe ser modificada o creada?

7. Resumen del caso de uso: “Comprar gaseosa” (utilice viñetas) hasta el tema “exclusión de los casos de uso”.

La función principal de la máquina de gaseosa es permitir a un cliente (autor) adquirir una lata de gaseosa: “Comprar gaseosa” (caso de uso).

Sin embargo hay otros usuarios que intervienen, como el proveedor que tiene que reabastecer a la máquina y el recolector de dinero que tiene que recoger el dinero de la alcancía de la máquina.

8. En que consisten las relaciones de inclusión y extensión (dibuje sus respectivos símbolos, e inserte la figura ejemplo de Relaciones de casos de uso).

La inclusión, le permite volver a utilizar los pasos de un caso se uso dentro de otro. La otra, es extensión, le permite crear un caso de uso mediante la adición de pasos a uno existente.
Existen otros dos tipos de relaciones que son generalización y agrupamiento como en las clases, la generalización cuenta con un caso de uso que se hereda de otro. El agrupamiento es una manera de organizar los casos de uso.

Para representar a la inclusión utilizaremos el símbolo que se usa para la dependencia entre clase: una línea discontinua con una punta de flecha que conecta a las clases apuntando hacia la clase dependiente. Justo doble la línea agregara un estereotipo: la palabra “incluir” 

bordeada por dos pares de () angulares. 

La extensión solo puede realizarse en puntos indicados de manera específica dentro de las secuencias del caso de uso base.

A estos puntos se les conoce como puntos de extensión.

Como la inclusión podrá concebir la extensión con una línea de dependencia (líneas discontinuas con una punta de flecha), junto con un estereotipo que muestre “extender” (angulares dentro del caso se uso básico, el punto de extensión aparecerá debajo del nombre del caso de uso).

9. Inserte las imágenes de las figuras: modelo de caso de usos proveniente de la máquina de gaseosas y con inclusión, extensión-inclusión.

10. ¿que es un escenario?. Describa un ejemplo.

Escenarios

Especifican el comportamiento de un caso de uso por

descripción, no por modelamiento

Ejemplos incluyen texto estructurado informal, texto

estructurado formal con condiciones y pseudocódigo.

Típicamente especifica:

Cómo y cuándo el caso de uso comienza y termina
Interacción con actores e intercambio de objetos
Flujo de eventos: normal (exitoso), alternativo (exitoso) y

excepcional (falla)

Ejemplo

En un sistema de RRHH, para el caso de uso

“Contratar Empleado”, los siguientes escenarios

pueden darse:

Escenario normal: Contratar una persona que no

pertenece a la compañía

Escenario alternativo: Contratar a un persona que

pertenece a la compañía, pero en un departamento

distinto.

Escenario fallido: No pude ser encontrada ninguna

persona calificada

11. Enumere la secuencia de pasos en los escenarios

Cada caso de uso es una colección de escenarios y cada escenario es una secuencia de pasos, los cuales no aparecen en el diagrama como tal.

La claridad es clave en la generación de cualquier diagrama y el adjuntar notas a cada caso de uso podrían volverlo confuso .El uso de estos diagramas es por lo general parte de un documento de diseño que el cliente y el equipo de diseño tomara como referencia, cada escenario de caso de uso tendrá su propia página donde se listara en modo de texto a:

•Actor principal
•Condiciones previas para el caso de uso

•Pasos en el escenario
•Condiciones posteriores cuando se finaliza el escenario

•El actor que se beneficia del caso de uso

12. ¿Que son los escenarios secundarios? Enumere escenarios secundarios del caso de uso: “Comprar gaseosa”.

Ejemplo Casos De Uso

Casos de uso.

UML

Foro De Casos De Uso

¿Que Es Lo Realmente Importante En Caso De Uso?

Las imagenes como lo son para UML:

O un documento como este:

o uml y casos de uso son lo mismo en que se diferencian?

Foro De UML

Creen ustedes que esta bien la definicion que tengo de UML o si debo mejorar Ayuda!!!

Lenguaje Unificado de Modelado, es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema.

Gracias...

1. ¿Que es UML?

UML:Lenguaje Unificado de Modelado, es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema.

2. ¿Porque es necesario el UML?

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir.

3. Breve resumen de la historia del UML.

El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología del software).
El objetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool ). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML.
Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a construir.

4. Objetivos del UML.

Durante el desarrollo del UML sus autores tuvieron en cuenta:
Proporcionar una notación y semánticas suficientes para poder alcanzar una gran cantidad de aspectos del modelado contemporáneo de una forma directa y económica.
Proporcionar las semánticas suficientes para alcanzar aspectos del modelado que son de esperar en un futuro, como por ejemplo aspectos relacionados con la tecnología de componentes, el cómputo distribuido, etc.
Proporcionar mecanismos de extensión de forma que proyectos concretos puedan extender el meta-modelo a un coste bajo.
Proporcionar mecanismos de extensión de forma que aproximaciones de modelado futuras podrían desarrollarse encima del UML.
Permitir el intercambio del modelos entre una gran variedad de herramientas.
Proporcionar semánticas suficientes para especificar las interfaces a bibliotecas para la comparición y el almacenamiento de componentes del modelo.
Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir.

5. ¿Que es un diagrama, cual es su finalidad?

Un diagrama es un tipo de esquema de información que representa datos numéricos tabulados.
Su finalidad es mostrar una cadena de mando o sucesos de un proceso de forma grafica.

6. Enumere los tipos de diagrama de UML y defínalos

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado:

• Diagrama de clases: es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.

• Diagrama de componentes: Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.
• Diagrama de objetos: Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.
• Diagrama de estructura compuesta: es un tipo de diagrama de estructura estática en el Lenguaje de Modelado Unificado (UML), que muestra la estructura interna de una clase y las colaboraciones que esta estructura hace posibles. Esto puede incluir partes internas, puertas mediante las cuales, las partes interactúan con cada una de las otras o mediante las cuales, instancias de la clase interactúan con las partes y con el mundo exterior, y conectores entre partes o puertas. Una estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempo de ejecución para lograr algún propósito. Cada elemento tiene algún rol definido en la colaboración.
• Diagrama de despliegue:  Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.
  En el UML 2.0 los componentes ya no están dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo.
  Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto más amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje de programación, a un sistema operativo, un ordenador o un cluster de terminales.
  La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.
• Diagrama de paquetes:  muestra cómo un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquía lógica de un sistema.

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado:

• Diagrama de actividades:  representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general.
  En SysML el diagrama de Actividades ha sido extendido para indicar flujos entre pasos que mueven elementos físicos (e.g., gasolina) o energía (e.g., presión). Los cambios adicionales permiten al diagrama soportar mejor flujos de comportamiento y datos continuos.
• Diagrama de casos de uso:  es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto 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.
• Diagrama de estados:  es un diagrama utilizado para identificar cada una de las rutas o caminos que puede tomar un flujo de información luego de ejecutarse cada proceso.
  Permite identificar bajo qué argumentos se ejecuta cada uno de los procesos y en qué momento podrían tener una variación.
  El diagrama de estados permite visualizar de una forma secuencial la ejecución de cada uno de los procesos.
  
  
  Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:
• Diagrama de secuencia:  muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos. 
• Diagrama de comunicación:  modela las interacciones entre objetos o partes en términos de mensajes en secuencia. Los diagramas de comunicación representan una combinación de información tomada desde el diagrama de clases, secuencia, y diagrama de casos de uso describiendo tanto la estructura estática como el comportamiento dinámico de un sistema.
  Los diagramas de comunicación y de secuencia describen información similar, y con ciertas transformaciones, pueden ser transformados unos en otros sin dificultad.
• Diagrama de tiempos: Un cronograma puede contener cualquier número de señales relacionadas entre sí. Examinando un diagrama de tiempos, se puede determinar los estados, nivel alto o nivel bajo, de cada una de las señales en cualquier instante de tiempo especificado, y el instante exacto en que cualquiera de las señales cambia de estado con respecto a las restantes.
• Diagrama global de interacciones o Diagrama de vista de interacción: El diagrama global de las interacciones es un diagrama de comportamiento, más precisamente, uno de los cuatro diagramas de interacción. Muestra una cierta vista sobre los aspectos dinámicos de los sistemas modelados. Aunque un diagrama global de las interacciones es una representación gráfica de una interacción, éste se distingue fuertemente de los diagramas de secuencia y de comunicación, dos de los otros diagramas de interacción. De hecho, algunos elementos gráficos del diagrama global de las interacciones están tomados del diagrama de actividades, otro diagrama de comportamiento para el modelado de actividades.
 

7. ¿Que es un modelo?

Los modelos se utilizan en muchas actividades de la vida humana: antes de construir una casa el arquitecto utiliza un plano, los músicos representan la música en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los óleos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo. La OMT, por ejemplo, intenta abstraer la realidad utilizando tres clases de modelos OO: el modelo de objetos, que describe la estructura estática; el modelo dinámico, con el que describe las relaciones temporales entre objetos; y el modelo funcional que describe las relaciones funcionales entre valores. Mediante estas tres fases de construcción de modelos, se consigue una abstracción de la realidad que tiene en sí misma información sobre las principales características de ésta.

8. Para que sirven los modelos. Enumere.

• Los modelos permiten una mejor comunicación con el cliente.
• Es posible  enseñar  al cliente una posible aproximación de lo que será el producto  final .
• Proporcionan una primera aproximación al  problema  que permite visualizar cómo quedará el resultado.
• Reducen la complejidad del original en subconjuntos que son fácilmente tratables por separado.

9. Significado de un modelo

Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión.

10. ¿Que es una vista en UML?

Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. 

11. ¿Que describe el comportamiento dinámico?

Describe los aspectos de un sistema que cambian con el tiempo. El modelo dinámico se utiliza para especificar e implementar los aspectos de control del sistema. Los modelos dinámicos contienen diagramas de estado, los cuales no son más que grafos cuyos nodos son estados y cuyos arcos son transiciones entre estados causadas por sucesos.

12. Enumere los tipos de vistas de UML

• Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos.

• Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema.

• Vista de Componentes: Muestra la organización de los componentes de código.

• Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente.

• Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos llamados nodos.