Temas UNIDAD 3 Introducción Cuando usar UML Por qué usar UML Diagramas de Caso de Uso Actores Asociaciones Dependencias
Introducción Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; aún cuando todavía no es un estándar oficial, está apoyado en gran manera por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables.
Cuando usar UML UML es muy útil cuando se requiere documentar el proyecto. Sin importar el tamaño del proyecto, es recomendable documentarlo, sobre todo pensando en que las personas que se encargan actualmente del desarrollo, pudieran abandonar la empresa por alguna razón. Otra razón de usar UML es cuando se trabaja en equipo, y se requiere de una correcta estructuración de los requerimientos del sistema. Una práctica común en algunos programadores, es no documentar los proyectos que desarrollan. Esto trae consigo problemas posteriores cuando alguna otra persona toma el proyecto y realiza ajustes. No cuenta con la documentación requerida para comprender el cómo funciona el sistema. Se recomienda usar Casos de Uso en casi todos los proyectos. Son de gran ayuda en la exposición y determinación de requerimientos, así como para la planeación de proyectos. Conforme avanza el desarrollo de un proyecto, los casos de uso se hacen más visibles y útiles.
Por qué usar UML Mientras que el valor estratégico del software aumenta para muchas compañías, la industria busca técnicas para automatizar la producción del
software y para mejorar calidad y para reducir costos y el tiempo. Estas técnicas incluyen tecnología, la programación visual, patrones, etc. Los negocios también intentan técnicas para manejar la complejidad de sistemas mientras que aumentan de alcance y complejidad. En detalle, reconocen la necesidad de solucionar problemas arquitectónicos que se repiten, tales como distribución física, concurrencia, réplica, seguridad, balance de la carga y tolerancia de fallas. Además, el desarrollo para el Web a nivel mundial, mientras que hace algunas cosas más simples, ha agraviado estos problemas arquitectónicos. UML fue diseñado para responder a estas necesidades.
Diagramas de Caso de Uso Se emplean para visualizar el comportamiento del sistema, una parte de el o de una sola clase. De forma que se pueda conocer cómo responde esa parte del sistema. El diagrama UML de casos de uso es muy útil para definir como debería ser el comportamiento de una parte del sistema, ya que solo especifica como deben comportarse y no como están implementadas las partes que define. El diagrama también puede ser utilizado para que los expertos de dominio (usuarios del sistema, clientes) se comuniquen con los informáticos sin llegar a niveles de complejidad. En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas relaciones entre ellas: Casos de uso: representado por una elipse, cada caso de uso contiene un nombre, que indique su funcionalidad. Los casos de uso pueden tener relaciones con otros caso de uso. Sus relaciones son: Include: Representado por una flecha, en el diagrama de ejemplo podemos ver como un caso de uso, el de totalizar el coste incluye a dos casos de uso. Extends: Una relación de una caso de Uso A hacia un caso de uso B indica que el caso de uso B implementa la funcionalidad del caso de uso A. Generalization: Es la típica relación de herencia. Actores: se representan por un muñeco. Sus relaciones son: Communicates: Comunica un actor con un caso de uso. Parte del sistema (System boundary): Representado por un cuadro, identifica las diferentes partes del sistema y contiene los casos de uso que la forman.
Actor
Caso de uso
Se debe modelar la relación del sistema con los elementos externos, ya que son estos elementos los que forman el contexto del sistema. Los pasos a seguir son: Identificar los actores que interactúan con el sistema. Organizar a los actores. Especificar sus vías de comunicación con el sistema.
Para modelar los requerimientos es recomendable: Establecer su contexto, para lo que también podemos usar un diagrama de casos de uso. Identificar las necesidades de los elementos del contexto (Actores). Nombrar esas necesidades, y darles forma de caso de uso. Identificar que casos de uso pueden ser especializaciones de otros, o buscar especializaciones comunes para los casos de uso ya encontrados. Tipos Diagrama UML Diagramas de Estado Diagramas de actividad Diagramas de casos de uso
Actores Un actor es un usuario o un sistema externo con el cual interactúa el sistema que se modela. Por ejemplo, un proyecto de sistema de administración, involucra varios tipos de usuarios, incluyendo administradores de proyecto, administradores de personal, recursos humanos y administradores de sistemas. Todos ellos, son actores. Un actor es externo a un sistema, interactúa con el sistema, pudiendo representarlo un ser humano u otro sistema, y las metas y responsabilidades a satisfacer en interacción con el sistema Actores resuelven la pregunta de quién y qué interactúa con el sistema. En UML, un actor es mostrado como un icono simulando a una figura humana o como una clase marcada con la clave actor y etiquetado con el nombre de la clase de actor. La fig 2 muestra varios actores asociados con un sistema de administración de proyectos. Un administrador de proyecto: responsable de asegurarse que el proyecto entregue un producto de calidad dentro de un tiempo y costo específico Un administrador de recursos: responsable de capacitar al recurso humano que participa en el proyecto. Un recurso humano: responsable de asegurar que las habilidades del trabajador estén actualizadas y la calidad del trabajo este acorde al proyecto Un administrador del sistema: responsable de asegurar que el sistema de administración de proyectos esté disponible para el proyecto. Un sistema de respaldo: responsable de respaldar los datos del sistema de administración de proyectos.
Asociaciones Un tipo especializado de asociación, llamada communication association contesta a la pregunta de cómo los actores y los casos de uso se relacionan y qué actores participan o inicializan los casos de uso. Una asociación entre un actor y un caso de uso indica que el actor usa dicho caso de uso, esto es, indica que el actor se comunica con el sistema y participa en el caso de uso. Un caso de uso puede tener asociaciones con múltiples actores, y un actor puede tener asociaciones con múltiples casos de uso. Una asociación se muestra con una línea sólida entre el actor y el caso de uso.
Una flecha de navegación en una asociación dirigida hacia el caso de uso, indica que el actor inicializa la interacción con el sistema. Una flecha de navegación en una asociación con dirección hacia el actor, indica que el sistema inicializa la interacción con el actor. Sea cuidadoso de no mostrar flechas de navegación, ya que puede indicar al modelador que no existe ningún tipo de interacción entre el actor y el caso de uso. Dependencias Un modelo puede tener varios casos de uso, entonces, cómo organizamos esos casos de uso para definir lo que el sistema debe de hacer? cómo usamos esa información para determinar cómo debe ejecutarse el proyecto mientras se considera cómo usar los casos de uso y relacionarlos con otros, incluyendo los
puntos en común que puedan tener?. Las dependencias llamadas include y extend, contestan estas preguntas. Dependencia Include Indica que un caso de uso siempre llama la funcionalidad de otro caso de uso el cuál se decidió separarlo debido a que su funcionalidad podía ser reutilizada. Una dependencia include se muestra con una flecha desde el caso de uso hacia el caso de uso a incluir marcado con la palabra include.
Dependencia Extend La dependencia extend especifica un caso de uso puede o no llamar la funcionalidad de otro caso de uso.