Diagramas de Casos de Uso ‘Gando obtenemos los requerimientos de un nuevo sistema, necesitamos una forma de tar dichos requerimientos y aun mds, debido a que el sistema debe cumplirtos, el flo del sistema debe girar en torno a ellos. Durante mucho tempo, tanto.en el desarrollo de 1aS Y adicionales como en los primeros desarrollos oriéntados @ objetos,'los desarrolladores ‘sofware Se ayudaban de fos escenarios para comprender los requerimientos de un sistema, ‘sin documentarlos debidamente y més bien se llevaba a cabo de manera informal. Ivar Jacobson se da cuenta de este detallé ye dio la Importancia que merece. Hacia ‘propuso los Casos de Uso (Use Cases) como una técnica formal para capturar imientos, que luego se constituy6 en un elemento fundamental én la elaboracién de ientos y la planificacion de proyectos. Las Casos de Uso son considerados por muchos ‘alistas como una excelente forma de especificar el comportamiento externo de un sistema, es su comportamiento con el mundo real. Ena actualidad los Diagramas de Casos de Uso son un estdndar de UML, el lenguaje ‘en el modelado de sistemas, y del USDP (Unified Software Development Process 0 Proceso iffcado de Desarrollo de Software), la metodologia lider en el desarrollo de sistemas. eS Diagramas de Casos de Uso pocas palabras un Diagrama de Casos de Uso representa lo que hace el sistema y como se ciona con su entorno. Justamente a lo que hace el Sistema se le conoce como Casos de Uso piamente dichos, mientras que a los que provocan su ejecucidn (el entorno) se les conoce jmo Actores. Los Casos de Uso y Actores interacttian produciendo Relaciones. Se Casos de Uso r Caso de Uso (Use Case) es una secuencia de acciones realizadas por el sistema que ducen un resultado observable y valioso para alguien en particular. Todo sistema ofrece s usuarios una serie de servicios. Un caso de uso es justamente una forma de representar } alguien (persona u otro sistema) usa nuestro sistema. Caso de Uso al dar una respuesta a un evento que inicia un agente externo (llamado actor), n ser desarrollados en funcién a lo que los usuarios necesitan, Un caso de uso es pues esencia una interaccién tipica entre el usuario y el sistema, aunque un caso de uso también fe ser invocado por otro caso de uso. idea fundamental en los Casos de Uso es definir los requerimientos desde el punto de vista quien usa el sistema y no de quien lo construye. De esta manera, nos aseguramos que Casos de Uso permitan conocer los requerimientos del usuario para poder construir el software iéenotan una operacién completa desarrollada por el sistema. Debemos mencionar que se puede licar la técnica de los Casos de Uso a todo el sistema, a partes del sistema incluyendo a sus bsistemas, 0 a un elemento individual como pueden ser las clases e interfaces. rtRepresentac rafica de los Casos de Uso Los casos de uso se representan mediante elipses en cuyo interior se i encuentra su nombre. Los casos de uso son acciones que debe _rrie realizar el sistema, es por ello que debe nombrarseles mediante un Representacion grafica verbo seguido por el principal objeto que es afectado por la accién. A de un caso de uso aces es conveniente utilizar un prefijo delante del nombre de caso de uso, el cual debe indicar el paquete en el que se ubica (un paquete es un elemento para agrupar a otros), este nombre es llamado path name, mientras que § solo se muestra el nombre del caso de uso se le llamaré simple name. Ejemplos de casos de uso con simple name son: colocar orden, validar usuario, etc., y de casos de uso con path name serén ventas::ingresar pedido, almacén::despachar producto, etc., donde ventas y almacén son los nombre dados a los paquetes que agrupan a los casos de uso ingresar pedido y despachar producto respectivamente. = Actores Un Actor es un conjunto uniforme de personas, sistemas 0 maquinas externos al sistema que estamos modelando, que cumplen un rol determinado y que interactuan con él, El Actor, modela un tipo de objeto fuera del dominio del sistema pero que interactia directamente con él; lo que significa que, al definirlos empezamos a dar los limites a nuestro sistema. Por ejemplo en un Sistema de Ventas, el caso de uso realizar una venta tiene un solo actor el Vendedor; sin embargo, el rol de Vendedor puede ser realizado por un Vendedor, por el Supervisor 0 por el Jefe de Ventas. Si existiera un caso de uso especificamente para el Supervisor 0 el Jefe de Ventas entonces recién deberén considerarse a éstos como actores. Los dispositivos de hardware y sistemas que interactian con el sistema que estamos modelando también pueden ser considerados Actores. Representaci Grafic Actor Los actores se representan mediante "hombres de palo” (stick man). Usted puede utilizar los mecanismos de extension previstos en el UML para estereotipar un Actor proveyendo un icono diferente que pueda ofrecer mejor visibilidad para su propésito. Por ejemplo puede representar un Actor mediante un rectangulo con el estereotipo <>. Cuando el Actor resulta ser un Sistema se suele representar mediante una computadora, para resaltar este hecho. k Ey es Posibles represeataciones de un Actor. El "hombre de palo” es la més utilizada. La Gltima representacién es utilizada solo cuando se trata de sistemas, Ya que para cada caso de uso, pueden existir diversos Actores a cada uno de ellos se le tiene que asignar un nombre. El nombre del Actor se escribe debajo del icono que representa a dicho Actor.Casos de Uso eS Relaciones en los Diagramas de cones de asociacién entre actores y casos de uso. jaciones de generalizacién entre actores. jaciones de generalizacién entre casos de uso. jones incluye (include) entre casos de uso. sciones extiende (extend) entre casos de uso. @ Relaciones de Asociacién los Diagramas de Casos de Uso, una Relacién de Asociacién representa la participacién jun Actor en un Caso de Uso. Es la mas general de las relaciones y la relacién seméntica mas i, siempre parte de los actores y viajan en una sola direccién. A esta relacidn también se le ce como relacién de comunicacién y suele estereotiparse como <>, aunque no es indispensable pues es la tinica posible entre un actor y un caso de uso. esentacién grafica de una asociacion representa mediante una linea sdlida. Como siempre parten de los res hacia los Casos de Uso no necesita colocarse una cabeza de flecha indique la direccién, Represenacin de una relacién de asociacion | rmaimente no se acostumbra a darle un nombre, pero cuando se desea | lat la asociacién puede darsele un nombre e incluso indicar su estereotipo para distinguir el 6sito de la relaci6n. Lo mas comin es estereotipar a la relacién de asociacién como ‘comunicates>>, 6 | jagrama muestra una Relacién de iaci6n genérica entre un Actor y el Caso ae Uso, En los diagramas de casos de uso, oO 5 las lineas que salen del actor hacia un de uso denotan este tipo de relacién. Actor © Relaciones de Generali ta de representar la relacién entre dos objetos del mismo tipo en el cual uno de ellos se porta igual que otro pero que ademas contiene caracteristicas adicionales que lo diferencian. eneralizacién es una relacién de herencia y en los Diagramas Casos de Uso puede ocurrir un actor y otro actor y, entre un caso de uso y otro caso de uso. ijo hereda el comportamiento y significado del padre, y eventualmente el hijo puede sustituir al re. ‘Sin embargo, el hijo puede redefinir algdn comportamiento del padre, o definir algiin otro 'portamiento que el padre no presenta. Representacién de una relacién de generalizacién ntando desde el Caso de Uso Hijo hacia el Caso de Uso Padre, o desde ctor Hijo hacia el Actor Padre. La direccién de la flecha representa el nismo de herencia "el hijo hereda del padre”. A esta relacién no es rio colocarle un nombre pues representa en si misma un mecanismo de herencia. Se representa mediante una linea sdlida con cabeza de flecha hueca, {