Analisis_Larman, Uml y Patrones 2da Edición_copia-100-110

[Audio] 68 UML Y PATRONES 6.13. Diagramas de casos de uso UML proporciona notación para los diagramas de casos de uso con el fin de ilustrar los nombres de los casos de uso y los actores, y las relaciones entre ellos (ver Figura 6.2). comunicación límite del sistema NuevaEra Procesar Venta notación alternativa para un actor que representa un sistema informático Cajero Gestionar Devoluciones Servicio de Autorización de Pagos actor Procesar Alquiler «actor» Calculador de Impuestos Abrir Caja «actor» Sistema de Contabilidad Analizar Actividad «actor» Sistema de Actividad de Ventas «actor» Sistema RRHH Gestionar Seguridad Gestionar Usuarios Administrador del Sistema caso de uso . . . Figura 6.2. Diagrama de contexto de casos de uso parcial. Los diagramas de caso de uso y las relaciones entre los casos de uso son secundarios en el trabajo con los casos de uso. Los casos de uso son documentos de texto. Trabajar con los casos de uso significa escribir texto. Un signo típico de un modelador de casos de uso novato (o un estudiante) es la preocupación por los diagramas de casos de uso y las relaciones entre los casos de uso, en lugar de escribir texto. Los expertos mundiales en casos de uso, como Anderson, Fowler, Cockburn, entre otros, minimizan la importancia de los diagramas de casos de uso y las relaciones entre los casos de uso, y en lugar de eso se centran en escribir. Con eso como advertencia, un simple diagrama de casos de uso proporciona un conciso diagrama de contexto visual del sistema, que muestra los actores externos y cómo utilizan el sistema. Sugerencia Dibuje un diagrama de casos de uso sencillo junto con la lista actor-objetivo..

[Audio] MODELO DE CASOS DE USO: ESCRITURA DE REQUISITOS EN CONTEXTO 69 Un diagrama de casos de uso es una excelente representación del contexto del sistema; conforma un buen diagrama de contexto, esto es, muestra los límites de un sistema, lo que permanece fuera de él, y cómo se utiliza. Sirve como herramienta de comunicación que resume el comportamiento de un sistema y sus actores. La Figura 6.2 presenta una muestra de diagrama de contexto de casos de uso parcial para el sistema NuevaEra. Sugerencias en la realización de los diagramas La Figura 6.3 muestra algunos consejos sobre los diagramas. Nótese que la caja del actor contiene el símbolo «actor». Este símbolo se denomina estereotipo UML; se trata de un mecanismo para clasificar un elemento en cierto modo. El nombre de un estereotipo se escribe entre comillas francesas —signo ortográfico especial formado por un único carácter (no "<<" y ">>") conocido sobre todo por su uso en la tipografía francesa para indicar una cita—. Para un diagrama de contexto de casos de uso, limite los casos de uso a casos de uso de nivel de objetivos de usuario. Muestre los actores que representan sistemas informáticos con una notación alternativa a los actores humanos. NuevaEra Procesar Venta «actor» Servicio de Autorización de Pagos Cajero . . . Actores principales a la izquierda Actores de apoyo a la derecha Figura 6.3. Sugerencias sobre la notación. Para clarificar, algunos prefieren destacar los actores que se corresponden con sistemas informáticos externos con una notación alternativa, como se ilustra en la Figura 6.4. NuevaEra Algunas alternativas UML para representar actores externos que son otros sistemas informáticos. Procesar Venta «actor» Servicio de Autorización de Pagos ... Servicio de Autorización de Pagos «system» Servicio de Autorización de Pagos El estilo de caja de clase se puede utilizar para cualquier actor, informático o humano. Utilizarlo para los actores informáticos proporciona una distinción visual. Figura 6.4. Notación alternativa para los actores..

[Audio] 70 UML Y PATRONES Advertencia sobre el exceso de diagramas Reiteramos que la importancia del trabajo de los casos de uso es escribir texto, no diagramas o centrarse en las relaciones entre los casos de uso. Si una organización dedica muchas horas (o peor, días) trabajando en los diagramas de casos de uso y debatiendo las relaciones en los casos de uso, en lugar de centrarse en escribir texto, se ha desaprovechado el esfuerzo. 6.14. Requisitos en contexto y listas de características de bajo nivel Como queda implícito en el título del libro Uses Cases: Requirements in Context [GK00], una motivación clave de la idea de caso de uso es considerar y organizar los requisitos en el contexto de los objetivos y escenarios de uso de un sistema. Eso es bueno —mejora la cohesión y comprensión—. Sin embargo, los casos de uso no son los únicos artefactos de requisitos necesarios. Algunos requisitos no funcionales, reglas de dominio y contexto, y otros elementos difíciles de ubicar, se capturan mejor en la Especificación Complementaria, que se describirá en el siguiente capítulo. Una idea detrás de los casos de uso es sustituir las listas de características de bajo nivel (típicas de los métodos de requisitos tradicionales) por los casos de uso (con algunas excepciones). Estas listas tendían a ser como sigue, normalmente agrupadas por áreas funcionales: ID Característica CARAC1.9 El Sistema aceptará entradas de los identificadores de los artículos. … … CARAC2.4 El Sistema registrará los pagos a crédito en el sistema de cuentas por cobrar. De tales listas detalladas de las características de bajo nivel se puede aprovechar algo. Sin embargo, la lista completa no se recoge en media página; es más probable que ocupe docenas o cientos de páginas. Esto nos conduce a algunos obstáculos, que los casos de uso ayudan a abordar. Éstos incluyen: Listas de funciones largas y detalladas no relacionan los requisitos en un contexto cohesivo; las diferentes funciones y características aparecen progresivamente como una "lista de la lavandería" inconexa de elementos. En cambio, los casos de uso sitúan los requisitos en el contexto de las historias y objetivos de uso del sistema. Si se utilizan tanto los casos de uso como las listas de características detalladas, hay duplicación. Más trabajo, mayor volumen para escribir y leer, más problemas de consistencia y sincronización. Sugerencia Esfuércese en sustituir las listas detalladas de características de bajo nivel por casos de uso..

[Audio] MODELO DE CASOS DE USO: ESCRITURA DE REQUISITOS EN CONTEXTO 71 Son aceptables las listas de características de alto nivel del sistema Es típico y útil resumir la funcionalidad del sistema con una lista breve de características de alto nivel, denominadas características del sistema, en un documento de Visión. A diferencia de las 100 páginas de características detalladas de bajo nivel, la lista de características del sistema tiende a incluir sólo unas pocas docenas de elementos. La lista proporciona un resumen muy conciso de la funcionalidad del sistema, independiente de la vista del caso de uso. Por ejemplo: Resumen de características del sistema capturar las ventas. autorización del pago (crédito, débito, cheque). administración del sistema para los usuarios, seguridad, tablas de códigos y constantes, etcétera. procesamiento automático de ventas sin conexión, cuando fallan los componentes externos. transacciones en tiempo real, en base a los estándares industriales, con sistemas de terceras partes, que incluye inventario, contabilidad, recursos humanos, cálculo de impuestos y servicios de autorización de pagos. definición y ejecución de reglas de negocio adaptadas y que se pueden añadir en ejecución en puntos típicos, fijados en los escenarios de proceso. … Esto se estudiará en el siguiente capítulo. ¿Cuándo son apropiadas las listas de características detalladas? Algunas veces los casos de uso no encajan realmente; algunas aplicaciones exigen un punto de vista dirigido por las características. Por ejemplo, los servidores de aplicaciones, productos de bases de datos y otros sistemas middleware o back-end necesitan ante todo ser considerados y evolucionar en términos de las características ("Necesitamos el soporte de XML en la siguiente versión"). Los casos de uso no se ajustan de manera natural a estas aplicaciones o al modo en que necesitan evolucionar en términos de las fuerzas del mercado. 6.15. Los casos de uso no son orientados a objetos No hay nada orientado a objetos en los casos de uso; uno no está realizando un análisis orientado a objetos si escribe casos de uso. Esto no es un defecto sino una aclaración. De hecho, los casos de uso constituyen una herramienta para el análisis de requisitos ampliamente aplicable, que se puede utilizar en proyectos no orientados a objetos, lo cual.

[Audio] 72 UML Y PATRONES incrementa su utilidad como método de requisitos. Sin embargo, como estudiaremos, los casos de uso son una entrada fundamental en las actividades clásicas de A/DOO. 6.16. Casos de uso en el UP Los casos de uso son vitales y centrales en el UP, que fomentan el desarrollo dirigido por casos de uso. Esto implica: Los requisitos se recogen principalmente en casos de uso (el Modelo de Casos de Uso); otras técnicas de requisitos (como las listas de funciones) son secundarias, si es que se utilizan. Los casos de uso son una parte importante de la planificación iterativa. El trabajo de una iteración se define —en parte— eligiendo algunos escenarios de caso de uso, o casos de uso completos. Los casos de uso son una entrada clave para hacer estimaciones. Las realizaciones de los casos de uso dirigen el diseño. Es decir, el equipo diseña objetos y subsistemas que colaboran para ejecutar o realizar los casos de uso. Los casos de uso, a menudo, influyen en la organización de los manuales de usuario. El UP diferencia entre casos de uso del sistema y del negocio. Los casos de uso del sistema son los que se han estudiado en este capítulo, como Procesar Venta. Se crean en la disciplina Requisitos, y forman parte del Modelo de Casos de Uso. Los casos de uso del negocio se escriben con menos frecuencia. Si se hace, se crean en la disciplina Modelado del Negocio, como parte de un esfuerzo de reingeniería de los procesos de negocio a gran escala, o para ayudar a entender el contexto de un nuevo sistema en el negocio. Describen una secuencia de acciones de un negocio como un todo para cumplir un objetivo de un actor del negocio (un actor en el entorno del negocio, como un cliente o un proveedor). Por ejemplo, en un restaurante, un caso de uso del negocio es Servir una Comida. Casos de uso y especificación de requisitos a lo largo de las iteraciones Esta sección reitera la idea clave del UP y el desarrollo iterativo: medir el tiempo y el nivel de esfuerzo de la especificación de requisitos a lo largo de las iteraciones. La Tabla 6.1 presenta una muestra (no una receta) de la estrategia del UP sobre el modo de desarrollar los requisitos. Nótese que el equipo técnico comienza construyendo los fundamentos de la producción del sistema cuando, quizás, sólo se han detallado el 10% de los requisitos, y de hecho, se retrasa de manera deliberada la continuación del trabajo de los requisitos concertados hasta casi el final de la primera iteración de elaboración. Ésta es la diferencia clave entre el proceso iterativo y el proceso en cascada: el desarrollo con calidad de producción de los fundamentos del sistema comienza rápidamente, mucho antes de conocer todos los requisitos. Obsérvese que cerca del final de la primera iteración de elaboración, hay un segundo taller de requisitos, durante el que quizás, el 30% de los casos de uso se escriben en.

[Audio] MODELO DE CASOS DE USO: ESCRITURA DE REQUISITOS EN CONTEXTO 73 Tabla 6.1. Muestra del esfuerzo de los requisitos a lo largo de las primeras iteraciones; no es una receta. Disciplina Artefacto Comentarios y nivel de esfuerzo de los requisitos Inicio Elab 1 Elab 2 Elab 3 Elab 4 1 semana 4 semanas 4 semanas 3 semanas 3 semanas Requisitos. Modelo de Casos de Uso. Repetir, se completa el 70% de todos los casos de uso en detalle. Repetir con la intención de clarificar y escribir en detalle del 8090% de los casos de uso. 2 días de taller de requisitos. Se identifican por el nombre la mayoría de los casos de uso y se resumen en un párrafo breve. ` Sólo el 10% se escribe en detalle. Sólo una pequeña parte de éstos se construyen durante la elaboración; el resto se aborda durante la construcción. Cerca del final de esta iteración, tiene lugar un taller de requisitos de dos días. Se obtiene una mejor comprensión y retroalimentación a partir del trabajo de implementación, entonces se completa el 50% de los casos de uso en detalle. Cerca del final de esta iteración, tiene lugar un taller de requisitos de 2 días. Se obtiene un mejor entendimiento y retroalimentación a partir del trabajo de implementación, entonces se completa el 30% de los casos de uso en detalle. Repetir. Repetir. Nada. Diseño. Modelo de Diseño. Repetir. Deberían ahora estabilizarse los aspectos de alto riesgo significativos para la arquitectura. Diseño de un pequeño conjunto de requisitos de alto riesgo significativos desde el punto de vista de la arquitectura. Nada. Repetir. Se construye el 15% del sistema final. Repetir. Se construye el 10% del sistema final. Repetir. Se construye el 5% del sistema final. Implementación. Modelo de Implementar esto. Implementación (código, etc.) Un poco mejor... Un poco mejor... La estimación comienza a tomar forma. Estimación muy imprecisa del esfuerzo total. Gestión Plan del Proyecto. de Desarrollo de SW. Ahora se pueden establecer racionalmente la duración global del proyecto, los hitos más importantes, estimación del coste y esfuerzo. detalle. Este análisis de requisitos escalonado se beneficia de la retroalimentación a partir de la construcción de un poco del núcleo del software. La retroalimentación incluye la evaluación del usuario, pruebas y "conocimiento de lo que no conocemos" mejorado. Es decir, el acto de construir software rápidamente hace que surjan suposiciones y preguntas que necesitan aclararse. Momento de la creación de los artefactos del UP La Tabla 6.2 muestra algunos de los artefactos del UP y un ejemplo de la planificación de sus momentos de comienzo y refinamiento. El Modelo de Casos de Uso comienza en la fase de inicio, con quizás sólo el 10% de los casos de uso escritos con algo de detalle. La mayoría se escriben incrementalmente a lo largo de las iteraciones de la fase de elaboración, de manera que, al final de la elaboración se ha escrito un gran cuerpo de casos de uso detallados y otros requisitos (en la Especificación Complementaria), proporcionando una base realista para hacer una estimación precisa hasta el final del proyecto..

[Audio] 74 UML Y PATRONES Tabla 6.2. Muestra de los artefactos UP y evolución temporal. c - comenzar; r – refinar. Disciplina Artefacto Inicio Elab. Const. Trans. Iteración � I1 E1…En C1…Cn T1…T2 Modelado del Negocio Modelo del Dominio c Requisitos Modelo de Casos de Uso c r Visión c r Especificación Complementaria c r Glosario c r Diseño Modelo de Diseño c r Documento de Arquitectura SW c Modelo de Datos c r Implementación Modelo de Implementación c r r Gestión del Proyecto Plan de Desarrollo SW c r r r Pruebas Modelo de Pruebas c r Entorno Marco de Desarrollo c r Casos de uso en la fase de inicio La siguiente discusión detalla la información presentada en la Tabla 6.1. No todos los casos de uso se escriben en formato completo durante la fase de inicio. Más bien, suponga que se lleva a cabo un taller de requisitos durante dos días al comienzo del estudio de NuevaEra. La primera parte del día se dedica a identificar los objetivos y el personal involucrado, y especular sobre lo que queda dentro y fuera del alcance del proyecto. Se escribe una tabla de casos de uso actor-objetivo y se presenta con el proyector del ordenador. Se inicia el diagrama de contexto de casos de uso. Tras unas pocas horas, quizás se identifican unos 20 objetivos de usuario (y por tanto, casos de uso de nivel de usuario), que incluye Procesar Venta, Gestionar Devoluciones, etcétera. La mayoría de los casos de uso interesantes, complejos o arriesgados, se escriben en formato breve; cada uno escrito con una duración media de dos minutos. El equipo comienza a formarse un esquema de alto nivel de la funcionalidad del sistema. Después de esto, entre el 10% y el 20% de los casos de uso que representan las funciones complejas principales, o que son especialmente arriesgadas en alguna dimensión, se escriben en formato completo; el equipo investiga con algo más de profundidad para entender mejor la magnitud, complejidad y demonios ocultos en el proyecto, a través de una pequeña muestra de casos de uso interesantes. Quizás esto puede implicar dos casos de uso: Procesar Venta y Gestionar Devoluciones. Se utiliza una herramienta de gestión de requisitos integrada con un procesador de texto para la escritura, y el trabajo se muestra por medio de un proyector mientras el equipo colabora en el análisis y la escritura. Se escriben las listas de Intereses y Personal Involucrado para estos casos de uso, para descubrir requisitos más refinados (y quizás costosos) funcionales y no funcionales —o cualidades del sistema— claves, como la fiabilidad y el rendimiento..

[Audio] MODELO DE CASOS DE USO: ESCRITURA DE REQUISITOS EN CONTEXTO 75 El objetivo del análisis no es completar los casos de uso de manera exhaustiva, sino dedicar unas horas a comprenderlos mejor. El promotor del proyecto necesita decidir si merece la pena un estudio profundo (esto es, la fase de elaboración). La intención del trabajo de inicio no es hacer este estudio, sino adquirir una idea de poca fidelidad (y claramente propensa a errores) acerca del alcance, riesgo, esfuerzo, viabilidad técnica, y análisis del negocio, para decir avanzar, dónde comenzar si se hace, o si parar. Quizás la fase de inicio del proyecto NuevaEra duró cinco días. La combinación del taller de requisitos de dos días y su análisis de casos de uso breve, y otros estudios durante la semana, condujeron a tomar la decisión de continuar con la fase de elaboración para el sistema. Casos de uso en la elaboración La siguiente discusión detalla la información presentada en la Tabla 6.1. Se trata de una fase de múltiples iteraciones de duración fija (por ejemplo, cuatro iteraciones) en las cuales se construyen incrementalmente partes del sistema arriesgadas, de alto valor o significativas desde el punto de vista de la arquitectura, y se identifican y clarifican la "mayoría" de los requisitos. La retroalimentación de los pasos concretos de programación influye e informa del conocimiento de los requisitos por parte del equipo, que se refina de manera iterativa y adaptable. Quizás se aborda un taller de requisitos de dos días en cada iteración —cuatro talleres—. Sin embargo, no se estudian todos los casos de uso en cada taller. Se priorizan; los primeros talleres se centran en un subconjunto de los casos de uso más importantes. En cada siguiente taller de requisitos breve, es el momento de adaptar y refinar la visión de los requisitos principales, que serán inestables en las primeras iteraciones y se irán estabilizando en las últimas. Por tanto, hay una interacción iterativa entre el descubrimiento de los requisitos y la construcción de partes del software. Durante cada taller de requisitos se refinan los objetivos de usuario y la lista de casos de uso. Se escriben, y reescriben, la mayoría de los casos de uso, en formato completo. Al final de la elaboración, se escriben en detalle del "80 al 90%" de los casos de uso. Para el sistema PDV con 20 casos de uso de nivel de objetivo de usuario, 15 o más de los más complejos y arriesgados deberían investigarse, escribirse y reescribirse en formato completo. Nótese que la elaboración conlleva programar partes del sistema. Al final de esta etapa, el equipo NuevaEra no sólo debería tener una mejor definición de los casos de uso, sino también algo de software ejecutable de calidad. Casos de uso en la construcción La etapa de construcción está compuesta de iteraciones de duración fija (por ejemplo, 20 iteraciones de dos semanas cada una) que se centra en completar el sistema, una vez que las principales cuestiones arriesgadas e inestables se han establecido en la elaboración. Tendrá lugar todavía la escritura de casos de uso menores y quizás talleres de requisitos,.

[Audio] 76 UML Y PATRONES pero mucho menos de lo que se hizo en la elaboración. En esta etapa, la mayoría de los requisitos funcionales y no funcionales principales deberían haberse estabilizado de manera iterativa y adaptable. La intención no es dar a entender que los requisitos se congelan o el estudio termina, sino que el grado de cambio es mucho menor. 6.17. Caso de estudio: casos de uso en la fase de inicio de NuevaEra Como se ha descrito en la sección anterior, no todos los casos de uso se escriben en el formato completo durante la fase de inicio. El Modelo de Casos de Uso de esta fase para el caso de estudio podría detallarse como sigue: Completo Informal Breve Procesar Venta Procesar Alquiler Abrir Caja Gestionar Devoluciones Analizar Actividad de Ventas Cerrar Caja Gestionar Seguridad Gestionar Usuarios … Poner en Marcha Suspender Operación Gestionar Tablas del Sistema … 6.18. Lecturas adicionales La guía de casos de uso de mayor éxito, traducida a varios idiomas es Writing Effective Use Cases [Cockburn01]8. Por buenas razones se ha convertido en el libro de casos de uso más ampliamente leído y seguido y, por tanto, se recomienda como referencia fundamental. Este capítulo se basa, y es consistente, con su contenido. Sugerencia: no rechace el libro como consecuencia del uso de iconos para los diferentes niveles de casos de uso por parte de los autores, o el énfasis temprano en los niveles y la taxonomía de casos de uso. Los iconos son opcionales y no muy importantes. Y aunque el debate acerca de los niveles y objetivos podría parecer al principio que distrae la atención a aquellos nuevos en los casos de uso, los que han trabajado con ellos durante algún tiempo estiman que el nivel y alcance de los casos de uso son cuestiones prácticas claves, porque su incomprensión es una fuente típica de complicaciones en el modelado de casos de uso. "Structuring Use Cases with Goals" [Cockburn97] es el artículo sobre casos de uso más citado, disponible on-line en www.usecases.org. Use Cases: Requirements in Context [GK00] es otro texto útil. Destaca el importante punto de vista —como establece el título— de que los casos de uso no son únicamente 8 Nótese que Cockburn rima con slow burn (N. del T.: En una comunicación personal, el autor nos ha comentado que introdujo esta aclaración a petición de A. Cockburn para señalar que su apellido no se pronuncia como cock-burn y evitar chistes por la connotación sexual.).

[Audio] MODELO DE CASOS DE USO: ESCRITURA DE REQUISITOS EN CONTEXTO 77 otro artefacto de los requisitos, sino que constituyen el vehículo central que dirige el trabajo de los requisitos y la información. Otra lectura que merece la pena destacar es Applying Use Cases: A Practical Guide [SW98], escrita por un profesor y experto en casos de uso que entiende y comunica cómo aplicar los casos de uso en un ciclo de vida iterativo. 6.19. Artefactos UP y contexto del proceso Como se ilustra en la Figura 6.5 los casos de uso influyen en muchos artefactos UP. Muestra de artefactos UP Modelo del Dominio Modelado del Negocio * * Artefactos parciales, refinados en cada iteración términos, atributos, relaciones términos, atributos, validación Modelo de Casos de Uso Glosario Visión Especificación Complementaria Requisitos requisitos, restricciones requisitos requisitos, escenarios claves requisitos, eventos de E/S Modelo de Diseño Doc. de Arquitectura Software Diseño requisitos, prioridades Plan de Desarrollo de Software Gestión del Proyecto pruebas de aceptación Plan de Pruebas Marco de Desarrollo Pruebas Entorno Figura 6.5. Muestra de la influencia entre los artefactos UP..

[Audio] 78 UML Y PATRONES En el UP, el trabajo de los casos de uso es una actividad de la disciplina de requisitos que podría inicializarse durante un taller de requisitos. La Figura 6.6 presenta algunos consejos acerca del momento y el lugar para llevar a cabo este trabajo. Dónde En un taller de requisitos. Cuándo Una vez durante la fase de inicio. Breve; no intente definir o refinar todos los requisitos. Varias veces durante las iteraciones de elaboración. Enero Febrero Dos proyecciones adyacentes. Caso de Uso: Capturar una Venta . . . Escenario principal de éxito: 1. . . . 2. . . . 3. . . . Extensiones: Caso de Uso: Gestionar Devoluciones . . . Escenario principal de éxito: 1. . . . 2. . . . 3. . . . Extensiones: Cliente Analista del Sistema Desarrollador Arquitecto de Software Usuario Final Quién Muchos, incluyendo usuarios finales y desarrolladores, jugarán el rol de especificadores de requisitos, ayudando a escribir los casos de uso. Liderados por el analista del sistema, que es el responsable de la definición de los requisitos. Cómo: Herramientas Software: Para el texto de los casos de uso, utilice una herramienta web de requisitos integrada con un procesador de texto conocido. Para los diagramas de casos de uso, una herramienta CASE para UML. Establezca enlaces entre los casos de uso; preséntelos a través del sitio web del proyecto. Hardware: Utilice dos proyectos acoplados a tarjetas de vídeo dual y establezca el ancho de la pantalla doble, para mejorar la espaciosidad del área de dibujo o mostrar 2 ventanas de procesadores de texto adyacentes. Figura 6.6. Proceso y establecimiento del contexto..