Desarrollo de aplicaciones con rup y uml
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Desarrollo de aplicaciones con rup y uml

on

  • 796 views

 

Statistics

Views

Total Views
796
Views on SlideShare
779
Embed Views
17

Actions

Likes
0
Downloads
41
Comments
0

1 Embed 17

http://comunidad.itsae.edu.ec 17

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • a <br />

Desarrollo de aplicaciones con rup y uml Presentation Transcript

  • 1. Desarrollo de Aplicaciones con RUP y UML Guía Teórica desarrollada por el profesor del curso: Ing. Jorge Nolasco Valenzuela
  • 2. Introducción
  • 3. I. RATIONAL UNIFIED PROCESS ¿Qué es RUP? Es una metodología RUP es un proceso de desarrollo de software que forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo). ¿Qué es UML? ( versión 2.3 ) UML tiene por objetivo ser un lenguaje de modelado de proposito general. No tiene propietario y esta basado en el común acuerdo de la gran parte de la comunidad informática. ¿Qué es Rational Rose? Es una Herramienta ( versión 7.0 )
  • 4. II. FASES PRINCIPALES DEL CICLO DE VIDA ITERATIVO E INCREMENTAL Flujos de Trabajo de Ingeniería Flujos de Trabajo de Apoyo
  • 5. III. ESTRUCTURA DEL RUP El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes: El eje horizontal representa tiempo y muestra el aspecto dinámico del proceso, expresado en términos de ciclos, fases, iteraciones, y metas. El eje vertical representa el aspecto estático del proceso; como está descrito en términos de actividades, artefactos, trabajadores y flujos de trabajo.
  • 6. ¿Qué es UML?  UML = Unified Modeling Language  Un lenguaje de propósito general para el modelado orientado a objetos  UML combina notaciones provenientes desde: Modelado Orientado a Objetos ( mejora la captura de requerimientos)  Modelado de Datos ( base de datos )  Modelado de Componentes ( piezas de software ) 
  • 7. ¿Qué es UML? El Lenguaje Unificado de Modelado es un lenguaje gráfico para visualizar, especificar, construir y documentar los artefactos de un sistema con gran cantidad de software. UML proporciona una forma estándar de escribir los planos de un sistema, cubriendo tanto las cosas conceptuales, tales como procesos del negocio y funciones del sistema, como las cosas concretas, tales como las clases escritas en un lenguaje de programación específico, esquemas de bases de datos y componentes software reutilizables.
  • 8. UML AGLUTINA ENFOQUES OO Booch Rumbaugh Jacobson Odell Meyer Pre- and Post-conditions Shlaer-Mellor Object life cycles Harel State Charts Gamma et. al. Frameworks, patterns, notes Embly Singleton classes Wirfs-Brock Fusion Operation descriptions, message numbering Responsabilities
  • 9. Modelo del Negocio
  • 10. ¿POR QUÉ MODELAMOS? • Construimos modelos para: comunicar, visualizar y controlar la arquitectura, comprender mejor el sistema y para controlar los riesgos. • La importancia de modelar • Principios del modelado • Modelado orientado a objetos
  • 11. ¿POR QUÉ MODELAMOS? MODELO DE DATOS Entidad : Empleado codigo nombre dni fechaIngreso telefono direccion cargo sueldo MODELO DE OBJETOS Clase : Empleado Persona Direccion ATOMIZACION COMPONENTES REUTILIZABLES HOMOGENEIZACION Empleado Telefono Cargo UNIFORMIZACION ENTE CON DATOS HETEROGENEOS ENTES CON DATOS HOMOGENEOS
  • 12. LA IMPORTANCIA DE MODELAR • ¿Qué es un modelo? Un modelo es una simplificación de la realidad. • ¿Por qué modelamos? Construimos modelos para comprender mejor el sistema que estamos desarrollando. • A través del modelado conseguimos: visualizar cómo es, especificar la estructura o el comportamiento, guías para la construcción, documentar. •Construimos modelos de sistemas complejos porque no podemos comprender en sistema en su totalidad. •Construimos La palabra clave aquí es “formal”. En realidad, incluso en el proyecto más simple los desarrolladores hacen algo de modelado, si bien muy informalmente.
  • 13. PRINCIPIOS DEL MODELADO • Primero: La elección de qué modelos crear tiene una profunda influencia sobre cómo se acomete un problema y cómo se da forma a una solución • Segundo: Todo modelo puede ser expresado a diferentes niveles de precisión. • Tercero: Los mejores modelos están ligados a la realidad. • Cuarto: Un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes.
  • 14. Modelado Orientada a Objetos Caracteriza la estructura estática de los objetos, en términos de grupos de objetos análogos (clases), la herencia y relaciones de importancia con otros objetos. Pasos para el modelamiento: 1ro. Identificación de objetos y clases:  Cosas tangibles, concretas; e intangibles.  Funciones desempeñadas por personas u otros.  Incidencias, ocurrencias y eventos que suceden.  Interacciones “transacciones”. Ej. Compra (comprador, vendedor y producto comprado).
  • 15. MODELADO ORIENTADA A OBJETOS 2do. Identificación de atributos:  ¿ Qué características posee cada objeto?  ¿Qué información se necesita conocer, proposito de una entidad? 3ro. Identificación de Relacionamiento:  Relaciones  Multiplicidad o cardinalidad.
  • 16. BUSINESS MODELING AND SYSTEM DEVELOPMENT Use-Case Business Model Object Model Business Modeling Use-Case Model Analysis Model Design Model Deployment Model Implementation Model System Development Business modeling results can be used as input to system development. Test Model
  • 17. MODELO DE DESARROLLO OO ITERATIVO E INCREMENTAL MOD. NEG. OO ANALISIS OO Clases DISEÑO OO y Objetos N VECES IMPLEMENTACION OO INTEGRACION OO
  • 18. CICLO DE VIDA DE LOS PROYECTOS ITERATIVO E INCREMENTAL “Iteración” se refiere a un paso en el ciclo de vida, formado por un conjunto de actividades, con un plan y criterios de evaluación, que acaba en una versión. Una iteración resulta en un “incremento” o crecimiento del proyecto general. El Proceso de Desarrollo de Software Unificado sugiere que se itere a través del ciclo produciendo actualizaciones incrementales. Cada incremento mejora, corrige y se construye sobre los incrementos previos.
  • 19. CICLO DE VIDA DE LOS PROYECTOS ITERATIVO E INCREMENTAL En cada iteración se deben hacer las siguientes actividades: Seleccionar y analizar los casos de uso relevantes Crear un diseño utilizando la arquitectura elegida Implementar el diseño en componentes Verificar que los componentes satisfacen los casos de uso Cuando una iteración alcanza sus objetivos, se procede con la siguiente iteración
  • 20. FASES PRINCIPALES DEL CICLO DE VIDA ITERATIVO E INCREMENTAL • • Fases – Iniciación: la idea inicial se lleva al punto de estar suficientemente bien fundamentada para garantizar la entrada en la fase de elaboración. – Elaboración: se definen la visión del producto y su arquitectura. Se expresan con claridad los requisitos del sistema, se priorizan se usan para producir una base arquitectónica – Construcción: el software se lleva desde una base arquitectónica ejecutable hasta su disponibilidad para los usuarios. – Transición: el software es puesto en manos de los usuarios, se erradican errores y se añaden características nuevas. Cada fase contiene una o más iteraciones
  • 21. Rational Unified Process El proceso para desarrollo de Software
  • 22. Rational Unified Process (RUP) • Captura varias de las mejores prácticas en el desarrollo moderno de software en una forma que es aplicable para un amplio rango de proyectos y organizaciones. • Es una guía de cómo utilizar de manera efectiva UML. • Provee a cada miembro de un equipo un fácil acceso a una base de conocimiento con guías, plantillas y herramientas para todas las actividades críticas de desarrollo. • Crea y mantiene modelos, en lugar de enfocarse en la producción de una gran cantidad de papeles de documentación.
  • 23. Estructura de RUP Cont. Fases Flujos de Trabajo de Procesos Inicio Elaboración Construcción Transición Modelación de Negocios Requerimientos Análisis y Diseño Contenido Implementación Prueba Implantación Flujos de Trabajo de Soporte Admin. Configuración Administración Ambiente Iteración(es) Preliminar Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iteraciones Iter. #m Iter. #m+1
  • 24. Flujos de Trabajo y Modelos Disciplinas Business Modeling Modelos Realized By Business UseCase Model Analysis & Design Implementation Realized By Requirements Implemented By Verified By Use-Case Model OK OK B B Test B B Business Object Model Automated By Fail Design Model Implementation Model Test Model
  • 25. El Proceso Unificado Fases Flujos de Trabajo de Procesos Inicio Elaboración Construcción Transición Modelación de Negocios Requerimientos Análisis y Diseño Implementación Prueba Implantación Flujos de Trabajo de Soporte Workflow de Iteración Admin. Configuración Administración Ambiente Iteración(es) Preliminar Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iteraciones Iter. #m Iter. #m+1
  • 26. Modelo del Negocio Objetivo: Comprender el conjunto de procesos de negocio que tienen lugar dentro de una empresa, como paso previo a establecer los requisitos del sistema a desarrollar. ¿Cómo consigue la empresa sus objetivos? Reingeniería.
  • 27. Como ...? • Identificar y delimitar los procesos de negocio según los objetivos de la organización. • Definir un caso de uso del negocio para cada proceso del negocio, utilizando un diagrama de casos de uso del negocio para mostrar el contexto y los límites de la organización bajo estudio. • Identificar los roles implicados en los diferentes procesos del negocio y describirlos en un diagrama de roles.
  • 28. Propósito • El modelo del negocio “no implica” que se hagan cambios en la forma como se hace el negocio. Simplemente es una técnica para documentar visualmente lo que su negocio hace. • Comprender los problemas organización y su impacto. actuales de la
  • 29. Propósito • Comprender la estructura y la dinámica de la organización para la que se desarrolla el proyecto. • Asegurar que los clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización. Visión compartida. • Obtener, de forma preliminar, los requerimientos del sistema que necesita la organización.
  • 30. Propósito • El modelo del negocio es una técnica que permite responder algunas preguntas críticas:  ¿Cómo sabe usted que ha identificado todos los casos de uso del sistema (funcionalidades del sistema).?  ¿Qué hacen los trabajadores (usuarios) antes de usar el sistema?  ¿Qué valor del negocio brinda el sistema?  ¿Cuál es el sistema de negocio (proceso) que el sistema computarizado apoya?
  • 31. Propósito • ¿Cómo aseguramos que el sistema tendrá valor si no entendemos como, quién y en que circunstancias se usará? • Para asegurar que estamos construyendo soluciones orientadas al cliente (es decir sistemas de información que satisfacen a nuestros clientes) no debemos pasar por alto: – El ambiente en el que estos sistemas trabajarán, – Los roles y responsabilidades de los empleados que usan el sistema, – Las "cosas" que son manejadas por el negocio,
  • 32. Beneficios • Uno de los grandes beneficios de modelar el negocio es mejorar la obtención de requisitos del sistema, requisitos que conducirán a la creación de sistemas de información que realmente encajen en la organización y sean usados por usuarios finales.
  • 33. Problema • Un problema que frecuentemente se produce la dificultad para que los analistas del negocio comuniquen sus resultados eficazmente a los participantes del equipo. • Dicho problema se puede resolver usando el UML.
  • 34. Modelado del Negocio • Artefactos del modelo del negocio Modelo de Casos de Uso del Negocio Actores del Negocio Especificación de Casos de Uso del Negocio Casos de Uso del Negocio Modelo de Objetos del Negocio Trabajadores del Negocio Entidades del Negocio Visión Glosario de Términos
  • 35. Notación UML Para el Modelo del Negocio Icono Nombre UML Definición Actor del Negocio Alguien o Algo, fuera del negocio que interactúa con el negocio. Trabajador del Negocio Rol o conjunto de roles dentro del negocio. Un trabajador del negocio interactúa con otros trabajadores del negocio y manipula entidades del negocio. Entidad del Negocio una "cosa" manipulada trabajadores del negocio. Caso de uso del negocio Una sucesión de acciones que un negocio ejecuta para producir un resultado de valor observable a un actor de negocio particular. (En este caso, sinónimo de proceso del negocio) o usada por
  • 36. Diagramas UML (M. Negocio) • Cada diagrama de UML proporciona una vista diferente del negocio: – Diagramas de casos de uso describen el contexto del negocio. – Diagramas de actividad describen las conductas en el negocio, o el flujo de trabajo del negocio. – Diagramas de clase que describen la estructura estática del negocio. – Diagramas de interacción describen la interacción dinámica entre los empleados y las cosas que ellos manipulan.
  • 37. Actores del Negocio Negocio Organización Mundo Exterior
  • 38. Actores del Negocio • ¿Dónde encontrar a los actores del negocio? – – – – – – – – Clientes. Socios. Proveedores. Autoridades. Entidades legales y reguladoras. Sucursales. Dueños e inversionistas Sistemas informáticos fuera del negocio con los que se interactúa. – Otras partes de la organización.
  • 39. Actores del Negocio • La lista de los actores del negocio se realiza especificando: – Nombre del actor: • Debe dar idea clara de la función que realiza o desempeña. • Sustantivo con letra inicial mayúscula. – Descripción: • Describir la función que realiza fuera del negocio y la responsabilidad que tiene para el negocio.
  • 40. Trabajador del Negocio Negocio Organización Mundo Exterior
  • 41. Trabajador del Negocio • ¿Dónde encontrar trabajadores del negocio? – Roles dentro del negocio. – Personas que ejecutan los proceso o actividades del negocio. – Hardware o sistemas informáticos dentro del negocio con los que se intercambia información directamente.
  • 42. Trabajador del Negocio • La lista de los trabajadores del negocio se realiza especificando: – Nombre del trabajador: • Debe dar idea clara de la función que realiza o desempeña. • Sustantivo con letra inicial mayúscula. – Descripción: • Describe la función que realiza dentro del negocio y su responsabilidad.
  • 43. Caso del Uso del Negocio Negocio Organización Mundo Exterior
  • 44. Caso del Uso del Negocio • ¿Dónde encontrar casos de uso del negocio? – Principales procesos del negocio. – Servicios principales para el cliente. – Procesos de servicio a otras entidades.
  • 45. Caso del Uso del Negocio • La lista de los casos del negocio se realiza especificando: – Nombre del caso de uso: • Debe dar idea clara de las acciones a realizar. • Se concibe desde el punto de vista del actor. • Debe ser un verbo o una frase verbal en infinitivo. – Descripción: • Se indica el objetivo fundamental del caso de uso
  • 46. Entidad del Negocio Negocio Organización Mundo Exterior
  • 47. Entidad del Negocio • Una entidad del negocio (business entity) representa a un conjunto de información con propiedades, comportamiento y semántica similares y que es manipulado o manejado por trabajadores del negocio. • Ejemplo: – Factura. – Solicitud de pago. – Tarjeta de crédito. Factura
  • 48. Entidad del Negocio • ¿Dónde encontrar entidades del negocio? – – – – – – – Áreas, departamentos, direcciones. Objetos físicos. Transacciones. Personas. Sistemas externos. Organizaciones. Socios.
  • 49. Entidad del Negocio • La lista de las entidades del negocio se realiza especificando: – Nombre de la entidad: • Debe dar idea clara de la función que realiza o desempeña. • Sustantivo con letra inicial mayúscula. – Descripción: • Describir la función que realiza dentro del negocio.
  • 50. Diagrama de Casos de uso del Negocio • Un diagrama de Casos de Uso del negocio representa visualmente la interacción entre los servicios primarios (casos del uso del negocio) que su negocio proporciona y aquellos a quienes los servicios se proporcionan (los actores del negocio).
  • 51. Diagramas de clase (objetos) • Los diagramas de clase del negocio documentan la estructura interior del negocio. • Cada clase en este diagrama o representa a un trabajador del negocio (el empleado del negocio) o a una entidad del negocio (una 'cosa' que el negocio manipula).
  • 52. D. Objetos “Caso Cuentas” verifica Documento Indentidad verifica Boleta incripción Especialista en Cuentas Genera (from Actores y Trabajadores) Abre Tarjeta de Ahorro Conjunta Cuenta Individual Indistinta
  • 53. Diagrama de Casos de Uso Los diagramas de casos de uso representan, en sus dos versiones, diferentes conceptos: Los casos de uso de negocio representan los procesos del negocio que son usados por los roles del negocio. los casos de uso de sistema describen un sistema desde el punto de vista del usuario. Atender Reservas Caso de Uso de Negocio Cliente Atender Bar Caso de Uso de Sistema Programar entrega Despachador
  • 54. “Caso Salsa Dance” Lea y analice con detenimiento el caso de estudio propuesto y elabore los siguientes diagramas: Diagrama CUN Actores del negocio Diagrama Modelo de objeto de Negocio Trabajadores del negocio Entidades del negocio Diagrama Caso de estudio Academia de Baile “Salsa Dance” La academia de baile “Salsa Dance” ofrece a sus clientes lecciones privadas y por grupos. Se dan lecciones privadas todo el día, y las lecciones por grupo se ofrecen en las noches. Los estudiantes que reciben lecciones privadas algunas veces provienen de lecciones en grupo y los grupos también se pueden haber formado por estudiantes que han tomado lecciones privadas, en este momento no se puede determinar que cambio es mas frecuente pero no se han venido incrementando, lo que mas preocupa a la academia es que después de tres cambios un cliente normalmente abandona la academia. La academia está interesada en determinar las razones por las que un estudiante pasa entre lecciones de grupo a privadas y viceversa, para ello cada vez que un estudiante que esta recibiendo un tipo de lección decide cambiar a otro tipo, se le toma un cuestionario. La academia emplea dos tipos de instructores de tiempo completo y por horas, de los últimos se debe tener su disponibilidad horaria. Los instructores son asignados a lecciones privadas como a lecciones por grupo indistintamente. Además de las lecciones, la academia auspicia dos noches en la semana de concursos de baile. El propósito de los concursos es dar a los estudiantes un lugar para que practiquen sus habilidades y también para buscar nuevos valores. A la academia le gustaría desarrollar un sistema de información para registrar a los estudiantes y las clases que han tomado y registrar los resultados de los cuestionarios que son tomados cada vez que un estudiante cambia de tipo de lección. Los administradores también desearían saber cuántos y cuáles tipos de lecciones ha enseñado cada instructor. Finalmente, es deseable registrar los concursos en los que ha participado cada estudiante y el puesto obtenido.
  • 55. MODELADO DEL NEGOCIO “Caso Salsa Dance” I. Evaluar la organización Organización: Nombre de la Organización : Escuela Salsa Dance II. Modelo de Casos de Uso del Negocio 1. Lista de los actores del negocio Cliente Estudiante 2. Lista de los casos de uso del negocio Inscribir Dar Lecciones Programar Horario Cambiar Modalidad Concursar Encuestar 3. Diagrama de casos de uso del negocio ( Rational Rose )
  • 56. RATIONAL ROSE
  • 57. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 58. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 59. MODELADO DEL NEGOCIO “Caso Salsa Dance” Ver / ocultar documentación o Ir a diagramas de clase, de interacción, de componentes, de estado, de despliegue, de caso de uso. Al activar estos botones se muestra una lista con los diagramas del tipo correspondiente, para seleccionar cuál se quiere visualizar. o Ir al diagrama padre o Ir al diagrama anterior o Aumentar zoom, disminuir zoom o Ajustar a ventana, deshacer ajustar o Ayuda general
  • 60. MODELADO DEL NEGOCIO “Caso Salsa Dance” Esta ventana tiene los siguientes componentes: • “Browser”: muestra de forma jerárquica todos los elementos de los modelos de un proyecto. Documentación: muestra texto asociado al elemento seleccionado. Permite también modificar ese texto. • “Log”: muestra mensajes sobre errores, progreso de tareas, etc. • Diagramas: cada diagrama se muestra con una ventana diferente. Las ventanas de diagrama cuentan con un botón “overview”, que permite desplazarse rápidamente por el contenido de diagramas
  • 61. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 62. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 63. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 64. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 65. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 66. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 67. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 68. MODELADO DEL NEGOCIO “Caso Salsa Dance” Ahora continuamos creando los casos de uso de negocio : Inscribir Dar Lecciones Programar Horario Cambiar Modalidad Concursar Encuestar Para ello debemos crear un p a q u e t e donde crearemos los casos de
  • 69. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 70. MODELADO DEL NEGOCIO “Caso Salsa Dance” Ahora continuamos creando los casos de uso de negocio : Inscribir Dar Lecciones Programar Horario Cambiar Modalidad Concursar Encuestar Comenzamos creando el primer caso de uso de negocio para ello seguimos los pasos a la derecha
  • 71. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 72. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 73. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 74. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 75. MODELADO DEL NEGOCIO “Caso Salsa Dance” Ahora crearemos los caso de uso de negocia que faltan crear de la manera anterior : Dar Lecciones Programar Horario Cambiar Modalidad Concursar Encuestar
  • 76. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 77. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 78. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 79. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 80. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 81. MODELADO DEL NEGOCIO “Caso Salsa Dance” 1.- Proceso de Negocio 2.- Objetivo Inscribir Selección de Candidatos mas adecuados para la academia 3.- Actores Postulante , secretaria 4.- Precondiciones divulgar lecciones que ofrece la Academia 5.- Flujos 1.- Recepción de Documentos 2.- Si documentación esta conforme 2.1- Llenado de ficha de inscripción 2.2.- Elegir Horario 2.3.-Pago de Inscripción 2.4 Llenado de Boleta de Pago 2.5 Entrega de Boleta al Postulante 3.- de lo contrario 3.1 No conforme 6.- Pos condiciones Informe de fecha de Inicio de Clases 7.- Excepciones No exista Vacante Reclutamiento directo por el área vacante
  • 82. MODELADO DEL NEGOCIO “Caso Salsa Dance” Para especificar cada caso de uso deberíamos de tomar en consideración los siguientes aspectos: 1.Interacciones. Mencionar la participación del actor primario y la de cada actor secundario desde que inicia el caso de uso hasta que termina. Eventos. Indicar cada uno de los eventos que ocurren durante el caso de uso (consulta de datos, capturas, cálculos, etc.) Nivel de detalle. Los casos de uso y sus especificaciones son la base del contrato que establecemos con nuestro cliente, por lo que debemos de buscar especificarlo al máximo detalle. Recuerda que entre más sepamos de la funcionalidad del sistema más precisas serán las estimaciones de nuestro plan de trabajo. Escenarios. Un caso de uso muestra diferentes escenarios posibles y no una sola forma de ejecutarlo. Debemos de explicar cada uno de esos escenarios, mediante un flujo principal y sus diferentes flujos alternos y excepcionales. Claridad y Enfoque de Usuario. Busca claridad en la explicación de los casos de uso utilizando la jerga de negocio a la hora de redactarlo sin mencionar detalles técnicos a los que no está acostumbrado. Sobre todo te interesa poder validar con éste que lo documentado en las espceificaciones de los casos de uso es lo que requiere para su sistema, así que si no los entiende no cumplirán su propósito principal. Durante los cursos y consultoría que impartimos a los analistas, les pido que me “platiquen” de qué se trata el caso de uso solicitado por su cliente, y después escribimos eso mismo en las especificaciones, generalmente logramos así un documento más claro que cuando lo escriben directamente sin platicarlo. La experiencia me dice que, por lo menos en sistemas, la gente explica mejor las cosas oralmente que de forma escrita. 2.Generalmente se recomiendan varios elementos adicionales para documentar los casos de uso. Pero, puedo asegurarte que la esencia es lo mencionado anteriormente. Pero, a continuación se mencionan algunos de esos elementos extras con los que puedes complementar la plantilla para documentar tus especificaciones de casos de uso. 3.Propósito. Si comienzas por este punto se te facilitará definir los pasos más relevantes para ejecutar el caso de uso. 4.Precondiciones. Son las condiciones que se deben de cumplir en el sistema antes de iniciarlo. El estado en que se debe encontrar el sistema antes de ejecutarlo. (Ej: Algún catálogo debe estar actualizado, debe estar en conexión con otro sistema, el usuario debe estar conectado con cierto perfil específico) 5.Postcondiciones. Te indica como queda el sistema después de ejecutar el caso de uso. Imagina que eres un tester y quieres comprobar si alguien acaba de ejecutar el caso de uso. ¿Qué cosas buscarías en el sistema? Seguramente datos nuevos, modificados, eliminados o la posibilidad de elegir nuevas opciones en el sistema. 6.Requerimientos Especiales. Cualquier requerimiento extra del sistema, asociado al caso de uso especificado. 7.Puntos de Extensión. Puntos donde se extiende el caso de uso mediante una relación de <<extend>>.
  • 83. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 84. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 85. MODELADO DEL NEGOCIO “Caso Salsa Dance” Una entidad del negocio (business entity) representa a un conjunto de información con propiedades, comportamiento y semántica similares y que es manipulado o manejado por trabajadores del negocio. Ejemplo: Factura. Solicitud de pago. Tarjeta de crédito. ¿Dónde encontrar entidades del negocio? Áreas, departamentos, direcciones. Objetos físicos. Transacciones. Personas. Sistemas externos. Organizaciones. Socios.
  • 86. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 87. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 88. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 89. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 90. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 91. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 92. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 93. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 94. MODELADO DEL NEGOCIO “Caso Salsa Dance”
  • 95. Capítulo N°4 Aplicación de los Casos de Uso
  • 96. TEMAS • Diagramas de Casos de Uso de Sistema – Relación de Generalización – Relación Incluye – Relación Extiende – Especificación de casos de uso – Prototipos
  • 97. Relación de Generalización  Es una relación de Herencia  Puede ocurrir entre actores o entre casos de uso Representación Gráfica  Mediante una línea sólida con cabeza de flecha hueca  Apunta desde el Hijo hacia el Padre
  • 98. Relación de Generalización Actor 2 es el padre de Actor 1 Caso Uso 2 es el padre de Caso Uso 1
  • 99. Ejemplos de Generalización Entre Actores En una empresa comercial, el Supervisor de Ventas realiza las funciones de cualquier vendedor, pero además supervisa a otros vendedores. Muestre los actores y la relación entre ellos
  • 100. Solución
  • 101. Ejemplos de Generalización Uc Casos de Uso «inherits» «include» Validar Usuario Seguir Pedido Comprobar clave «inherits» «include» Examinar Retina Hacer Pedido ____________ Establecer Prioridad «extends» Hacer Pedido Urgente
  • 102. Ejemplos de Generalización (Entre Casos de Uso) Cliente Realizar llamada telefónica Realizar llamada Realizar llamada internacional nacional
  • 103. Ejemplos de Generalización (Entre Casos de Uso) Realizar orden Cliente Realizar orden por teléfono Usuario Realizar orden por internet
  • 104. Relación Incluye  Es una relación de dependencia (para CU)  Factoriza comportamientos comunes para no repetir la definición  Los casos de uso “factorizados” pueden ser utilizados por otros Casos de Uso Representación Gráfica  Estereotipado: <<includes>>  Apunta desde el CU base hacia el CU incluido Uc Casos de Uso «include» Caso de Uso Base Caso de uso incluido
  • 105. Relación Incluye <<include>>  Caso Uso 1 debe también incluir el comportamiento especificado por el Caso Uso 2  Cada que se use el caso de uso 1, siempre se utilizará el caso de uso 2
  • 106. Ejemplo Relación Incluye En un sistema de ventas de una Ferretería tenemos los Casos de uso Registrar Pedido y Consultar Estado de Documento en ambos casos es necesario Validar Cliente. Muestre los casos de uso y sus relaciones Registrar Pedido Consultar Estado Doc <<include>> <<include>> Validar Cliente
  • 107. Ejemplo Relación Incluye • Venta de productos y compra de insumos en un supermercado. • Las acciones para Cajero Realizar venta de producto Realizar movimiento de producto “Realizar movimiento de producto” en kardex puede separarse en un caso de uso <<include>> <<include>> Comprador Realizar compra de insumos
  • 108. Relación Extiende  Es una relación de dependencia (para CU)  Se ejecuta el CU base pero bajo ciertas condiciones Representación Gráfica  Estereotipado: <<extend>>  Apunta desde el CU extendido hacia el CU base.
  • 109. Relación Entiende <<extend>>  Caso Uso 2 puede ser extendida por el comportamiento especificado por el Caso Uso 1  El CU1, será ejecutado cuando al ser ejecutado el CU2, se den las condiciones que activen el CU1
  • 110. Ejemplo Relación Entiende En un sistema de ventas de una Ferretería tenemos el caso de Uso Enviar Orden y se podrá Enviar Orden Parcial cuando falte algún producto en sus almacenes. Muestre los casos de uso y sus relaciones