Caso de uso completo reciclaje

Foro casos de uso

viernes, marzo 16, 2007

Tutorial de Casos de Uso (Paso a 'pasito')

1diggdigg

Si quisieramos aprender a modelar sistemas orientados a objetos por medio de Casos de Uso, ¿cuales serían los pasos a seguir? es decir, ¿existe una forma generalmente aceptada que nos diga el 'como', para realizarlos?

Bien, efectivamente existe, pero tampoco no es un dogma, son solo guias generales. Dichos pasos son:

1. Identificar actores. Los actores son mejor dicho, los roles que un usuario o usuarios del sistema llevan a cabo en algun momento del tiempo. Tambien pueden ser otros sistemas con los que el 'sistema' en proceso de modelado tiene interacción. Ejemplo: Para un sistema de ventas (directas y por catalogo), nuestros actores pueden ser: Vendedor, Cliente, Supervisor de Ventas.
2. Identificar Metas (Metas, objetivos generales o responsabilidades). Todos los actores en el entorno a modelar tienen metas u objetivos, o en su defecto responsabilidades, o en su defecto, acciones que desean realizar u obtener del sistema. Por ejemplo: Para el sistema de Ventas, el Vendedor tiene como meta, objetivo o responsabilidad (Ofrecer productos, Cerrar Venta, Ganar mucho dinero via Cobrar comisiones).
3. Obtener o identificar los Casos de Uso a partir de las Metas. Las metas son importantes porque a partir de su identificación pasamos a realizarlas y estas se convierten en los Casos de Uso, de esta forma tan sencilla obtenemos la información de funcionalidad que requiere nuestro sistema.
4. Especificar cada Caso de Uso. Una vez identificados seguimos a especificarlos uno a uno, es probable que en el inter, de esos sencillos pasos algunos casos de uso desaparezcan o se fusionen con otros, por ambiguedades detectadas o por detalles que se hayan escapado durante el proceso. Es importante recordar que de eso se trata el modelado, no es indispensable que quede al cien por ciento el modelo desde la primera vez, por eso hay que hacerlo en iteraciones o ciclos. La especificación de los casos de uso contiene varias partes, las fundamentales son Nombre, Descripcion, Actores, Flujo Principal y Flujos Alternos. Este grupo de elementos constituyen lo que se conoce como plantilla (Template), y nos podemos encontrar un sinnumero de plantillas en la red. Por ejemplo ésta:
5. 
   
   1. Id. Clave o numero de control del Caso de Uso
   2. Nombre. Es el Caso de Uso en si
   3. Descripción. Aqui detallamos lo que el caso de uso resuelve con base a su objetivo primordial.
   4. Actores. En esta sección especificamos el actor o actores principales y los actores secundarios o auxiliares en el caso de uso. Podemos detallar su nombre, una breve descripción y en que otros casos de uso intervienen si se desea. Aunque preferentemente esta especificacion se puede hacer por separado en otro documento.
   5. Pre-condiciones. Las reglas o condiciones que se deben cumplir antes de que sea iniciado el caso de uso. Por ejemplo, usuario firmado (logged), pago realizado, etc.
   6. Post-condiciones. Condiciones que se deben cumplir cuando termine el caso de uso.
   7. Flujo Principal En la secuencia de pasos del flujo principal, podemos usar texto solamente numerando cada paso, podemos usar un diagrama de flujo, un diagrama de secuencia, o una grafica de estados para efectos de dar claridad.
   8. Variaciones. Aqui listamos los pasos
   9. Extensiones.
   10. Requerimientos no funcionales.Cualquier elemento indispensable para la realizacion del caso de uso, que no tenga impacto en la funcionalidad.
   11. Diagrama de Contexto. Nos ilustra el alcance del caso de uso, entradas y salidas generales.
   
   12. Diagrama de Navegación. Este diagrama nos ayuda a ilustrar el flujo entre las pantallas (prototipo) que tendra el sistema para el caso de uso.

Foro UML

UML: Diagramas UML. ¿Qué es UML?

Desarrollo de Software Orientado a Objetos

Diagramas UML. ¿Qué es UML? UML es un conjunto de herramientas, que permite modelar (analizar y diseñar) sistemas orientados a objetos.
Ahora la frase más importante de todo el artículo: "El 80% de los problemas se pueden resolver usando tan solo el 20% de UML"

Herramientas UML

Pero volviendo a la definición de UML como "conjunto de herramientas", si nos imaginamos UML como una caja de herramientas con su martillo, destornillador, alicates, etc. Veamos qué contiene nuestra caja de herramientas:

• Diagrama de casos de uso
• Diagrama de clases
• Diagrama de estados
• Diagrama de secuencias
• Diagrama de actividades
• Diagrama de colaboraciones
• Diagrama de componentes
• Diagrama de distribución

Pero siguiendo con la analogía, si vamos a colgar un cuadro no usaremos todas las herramientas de nuestra caja, posiblemente sólo usemos el martillo para clavar el clavo.
Lo mismo pasa con UML, una vez que conozcamos las herramientas usaremos en cada momento las más adecuadas a nuestras necesidades. Nos os voy a decir que esto sea fácil, pues hay que saber para qué sirven y qué limitaciones tienen unas y otras para conocer su utilidad. Pero se puede alcanzar este conocimiento con un poco de práctica y sentido común.

Qué no es UML

UML no es un método de desarrollo. No te va a decir cómo pasar del análisis al diseño y de este al código. No son una serie de pasos que te llevan a producir código a partir de unas especificaciones.
UML al no ser un método de desarrollo es independiente del ciclo de desarrollo que vayas a seguir, puede encajar en un tradicional ciclo en cascada, o en un evolutivo ciclo en espiral o incluso en los métodos ágiles de desarrollo.

Cómo nació UML

Durante los ochenta y principios de los noventa Grady Booch, James Rumbaugh, e Ivar Jacobson trabajaban por separado en desarrollo de notaciones para el análisis y diseño de sistemas orientados a objetos. Los tres llegaron por separado a obtener bastante reconocimiento.
Booch había escrito "Object-Oriented Analysis and Design with Applications" un libro de referencia en el análisis y diseño orientado a objetos desarrollando su propia notación.
Por su parte James Rumbaugh había desarrollado su propia notación de diseño orientado a objetos llamada OMT (Object Modeling Technique) en su libro "Object-Oriented Modeling and Design".
Por otro lado Jacobson se había revelado como un visionario del análisis (padre de los casos de uso) y sobre todo del diseño orientado a objetos, sorprendiendo a todo el mundo en "Object-Oriented Software Engineering: A Use Case Driven Approach".
A mediados de los noventa empezaron a intercambiar documentos y trabajar en conjunto produciendo grandes avances en el modelado de sistemas orientados a objetos.
En 1994 Rational contrató a Rumbaugh en donde ya trabajaba Booch, un año después Jacobson se unía a ellos en Rational.
En 1997 salió a la luz la versión 1.0 de UML.

Enlaces sobre UML

• UML Resource Center en IBM
• UML en OMG

Ejemplos casos de Uso

Video casos de uso

Video UML

cuales son las preguntas útiles para encontrar actores?

1. ¿Quién está interesado en cierto requisito?

2. ¿Dónde está la organización se utilizara el sistema?

3.¿quién proveerá, utilizara y eliminara esta información al sistema?

4.¿quién utilizara esta función?

5. ¿Quién le dará soporte y mantenimiento al sistema?

6.¿usa el sistema un recurso externo?

7. ¿Qué actores necesita el caso de uso?

8. ¿un actor desempeña varios roles?

9. ¿varios agentes desempeñan el mismo rol?

Qué es un diagrama de uso?

Un diagrama Uso-Caso describe lo que hace un sistema desde el punto de vista de un observador externo, debido a esto, un diagrama de este tipo generalmente es de los más sencillos de interpretar en UML, ya que su razón de ser se concentra en un Que hace el sistema, a diferencia de otros diagramas UML que intentan dar respuesta a un Como logra su comportamiento el sistema.

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

El propósito primario del modelo caso de uso es comunicar las funciones y el comportamiento del sistema al cliente o al usuario final.

Por qué el caso de uso es una herramienta valiosa?

Los diagramas de casos de uso son importantes para visualizar, especificar, y documentar el comportamiento de un elemento. Ellos hacen sistemas, subsistemas, y clases entendibles para presentar una vista exterior de cómo estos elementos pueden ser usados dentro del contexto. Los diagramas de caso de uso son también importantes para probar sistemas ejecutables a través de ingeniería hacia adelante y para comprender sistemas ejecutables a través de ingeniería inversa.

Que es un caso de uso?

Un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.

En otras palabras, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos 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.

Objetivos de UML

Uml tiene como objetivo primordial ayudar al usuario a desarrollar un buen sistema , para ello ofrece una serie de tecnicas las cuales seran usadas dependiendo de las ventajas ofrecidas por ellas y las necesidades que posea el usuario gracias a que Uml posee una variedad de diagramas que nos permiten visualizar al sistema desde diferentes perspectivas.

Historia del UML

UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas construidos para toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronáutica, finanzas, etc.

Los principales beneficios de UML son:

• Mejores tiempos totales de desarrollo (de 50 % o más).
  
• Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
  
• Establecer conceptos y artefactos ejecutables.
  
• Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
  
• Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
  
• Mejor soporte a la planeación y al control de proyectos.
  
• Alta reutilización y minimización de costos.

Por qué es necesario el UML?

Es necesario debido a que el UML permite organizar el proceso del diseño en forma clara y entendible tanto para el analista, los desarrolladores como para el cliente y todo aquel que estè relacionado con el desarrollo del sistema o del proceso   

Que es UML

El UML(Lenguaje Unificado de Modelado):

Es una herramienta que permite a los creadores de sistemas generar diseños que capturen sus ideas en forma convencional y fácil de comprender para otras personas.

mapa conceptual requerimientos

Analisis Grafico de las preguntas

Encuestas