diagrama de casos de uso

alexdaniel2012
Mind Map by , created over 5 years ago

Mind Map on diagrama de casos de uso, created by alexdaniel2012 on 06/20/2014.

75
1
0
Tags
alexdaniel2012
Created by alexdaniel2012 over 5 years ago
Diagrama de flujo S.O.
Maycol Collazos
Diagrama de flujo M.P
Karen Ramos
El algoritmo
sandra macias arcila
GCSE PHYSICS: Energy Transfer
magykman1998
C1, C2, C3 keywords
Jessica Phillips
Servicios de Call Processing
GUSTAVO SEGURA
Diagrama de flujo, Árbol Binario
Miguel Vázquez
ALGORITMO
efrainag1020
Diagrama de Gantt
DannyCore PAMELA
Como crear un diagrama Causa y Efecto
Damaris Paramo
diagrama de casos de uso

Annotations:

  • el caso de uso es un poderoso concepto que ayuda a un analista c mprender la forma de un sistema debera comportarse. le ayudara a obeter los requerimientos desde el pinto de vista del usuario. es necesario aprender a visualizar los conceptos del caso de uno que conocio en la hora anterior. en esta hora se trataran los siguientes temas: *representacion de un modelo de caso de uso *concepción de las relaciones entre casos de uso *diagramas de casos de uso en el proceso de analistas *aplicacion de los modelos de caso de uso.*vera la idea general del UML.
1 representacion de un modelo de caso de uso
1.1 hay un actor que inicia un caso de uso y otro (posiblemente el que inicio, pero no necesariamente) que recibira algo de valor de el. la representacion grafica es directa. una elipse represnta a un caso de uso una figura agrafada representa a un acotr. el actor que inicia se encuentra a la izquierda del caso de uso, y el qye recibe a la derecha.
1.1.1
2 una nueva visita a la maquina de gaseosas
2.1 apliquemos los simbolos al ejemplo de la hora anterior. como recuerda, desarrollo los casos de uno para una maquina de gaseosas. el caso de uso "comprar gaseosa" se encuentra dentrodel sistema junto con "Reabastecer" y "recoletar dinero". los actores son el cliente, erepresentante del proveedor y el recolector.
3 secuencia de pasos en los escenarios
3.1 cada caso de uso es una coleccion de escenarios y cada escenario no es una secuencia de pasos. como puede ser, tales pasos no aparecen en el diagrma. o se encuentran en notas adjuntas a los casos de uso. aunque el UML no lo prohibe, la claridad es clave en la generacion de cualquier diagrama y el adjuntar notas a cada caso de uso podria volver consuso.
4 secuencia de pasos en los escenarios
4.1 cada caso de uso es una coleccion de escenarios y cada escenario es una secuencia de pasos. como puede ver, tales pasos no aparecen en el diagrama. NO se encuentran en notas adjuntas a los casos de uso. aunque el UML nno lo prohibe, la claridad es clave en la generacion de cualquier diagrama y el adjuntar notas a cada caso de uso podria volverlo confunso.
5 concepcion de las relaciones entre casos de uso
5.1 inclusión
5.1.1 examinemos los casos de uno "Rabastecer" y "Recolectar dinero" del ejemplo de la hora 6. ambos de inician mediante la apertura de la maquina, y finalizan con el cierre y sellado de la misma. el caso de uso "exhibir el interior" se creo para capturar el primer par de pasos; y "cubrir el interior" para el segundo.
5.2 extensión
5.2.1 la hora 6 mostro que el caso de uso "Rabastecer" podria ser base de otro caso de uso: "reabastecer de acuerdo a las ventas". en lugar de solo reabastecer la maquina de gaseosas opara que todas las marcas tengan la misma cantidad de latas, el representante podria anotar aquellas que se venden mejor y reabastecer acorde con ello.
5.3 generalizacion
5.3.1 las clases pueden heredarse entre sí y esto tanbién se aplica alos casos de uso en la herencia de los casos de uso, elc aso de uso secundario hereda las acciones y significado del primario, y adem´as agraga sus propias acciones. puede aplicar el caso de uso secundario en cualquier lugar donde aplique el primario. con lineas continuas y una punta de flecha el triángulo sin rellenar que apunta hacia el caso de uso primario, como se ve en la figura:
5.3.1.1
5.3.1.1.1 la relacion de genarilación puede establecer entre actores, así como entre caso de uso. quizá tenga personificados al representante del proveedor, al recolector y al gente del proveedor. Si cambia el nombre del representante como Reabastecedor, tanto éste como el Recolector serán secundarios del Agente proveedor, como muestra la figura:
5.3.1.1.1.1
6 Agrupamiento
6.1 En ciertos diagramas de casos de uso, podría tener varios casos de uso que querrá organizar. esto puede ocurrir cuando un sistema de varios subsistemas. Otra posibilidad sería cuando entrevista a los ususarios para obtener los requerimientos de un sistema
7 Diagramas de casos de uso en el proceso de análisis
7.1 Con el ejemplo dado y con el cual ha trabajado, aplicó directamente la simbología del caso de uso. haora nos regresamos un poco y colocaremos los casos de uso en el contexto de un esfuerso de análisis. las entrevistas con los usuarios comienzan en la terinología del dominio, aunque deberán revelar a los actores y casos de uso de alto nivel que descibirá los requerimientos funcionales en términos generales. Esta imformación establece los confines y ámbito del sistema. las entrevistas posteriores con los usuarios profundizarán en estos requerimientos. que dará por resuelto modelos de casos de uso que mostrarán los escenarios y las secuencias detalladamente
8 Aplicación de los modelos de caso uso
8.1 Para ayudarle a comprender con más profundidad los modelos de casos de uso y cómo aplicarlos, vamos a ver un ejemplo más complejo que una maquina de gaseosas. suponga que deberá diseñar una red de àrea local (LAN) para una firma de consultorìa,y que tendrá que comprender la funcionalidad para poder crearla. ¿cómo empesaría?
8.1.1 Compresión del dominio
8.1.1.1 empecaremos con las entrevistas el cliente para crear un diagrama de clases que refleje Cómo es la vida en el mundo de la consultoría. El diagrama de clases podría incluir las siguientes clases: consultor, cliente, proyecto, propuesta, datos e Informe. la figura lmuestra la forma en que podría lucir el diagrama.
8.1.1.1.1
8.1.2 comprensión de los usuarios
8.1.2.1 Ahora que el dominio está a la mano, vuelva la atención a los usuarios debido a que el objetivo sera entender los tipos de funcionalidad por crear en el sistema. Un grupo de usuarios serán consultores, otros podrían ser oficinistas. Entre otros usuarios en potencia se encuentrarán funcionarios corporativos, vendedores, administradores de red, administradores de oficina y administradores de proyectos. En el punto, sería conveniente a mostrar a los usuarios en una jerarquía de generación como se observa en la figura:
8.1.2.1.1
8.1.3 Profundización
8.1.3.1 Elaboremos uno de los casos de uso de alto nivel y generemos un modelo de caso de uso. una actividad extremadamente importante en una firma de consultoría es la genera de propuestas, así que examinanemos el caso de uso "crear una propuesta". Luego de recibir los comentarios y hacer las modificaciones necesarias (uevamente con el software integrado para oficina), el condultor imprime la propuesta y laa envia por correo al cliente. cando todo termina, el consultor se retira de la red. El consultor habrá completado una propuesta y es el actor que se benficia del caso de uso. en la siguiente figura le mustra el diagrama de casos de uso que resulta de este anális del caso de uso "crear una propuesta".
8.1.3.1.1
8.1.4 Elementos estructurales
8.1.4.1 Las clases, objetos , actores, interfaces y casos de uso son cinco de los elementos estructurales en el UML. aunque tiene diversas direfencias (mismas que , como ejercicio, deberá indicar), son similares en el sentido de que representan partes ya sea física o conceptuales de un modelo.
8.1.5 Relaciones
8.1.5.1 La asociacion, generalizacion, dependencia y realización, son las relaciones en el UML. (La inclución y extensión son dos tipos de dependencias.)Sin las relaciones, los modelos UML no seria más que listas de elementos estructurales. las relaciones conectan elementos y de ese modo conectan los modelos con la realidad.
8.1.6 Agrupamiento
8.1.6.1 El paquete es el único elemento de agrupamiento en el UML, éste le permite organizar los elementos estructurales en un modelo. Un paquete puede contener cualquier tipo de elemento estructural, y diferentes tipos a la vez.
8.1.7 Anotacion
8.1.7.1 La nota es el elemento de anotación del UML; éstas adjuntar restricciones, comentarios, requerimientos y graficos explicativos a sus modelos