Diseno casos uso Unidad3 01 UML

(1)

Administración de Proyectos de desarrollo de Software Ciclo de vida de un proyecto

Enfoque moderno

Temas

• Introducción

• Cuando usar UML

• Por qué usar UML

• Diagramas de Caso de Uso

• Actores

• Asociaciones

• Dependencias

(2)

Diagramas UML de un Caso de Uso

Bibliografía

(3)

Administración de Proyectos de desarrollo de Software Ciclo de vida de un proyecto

Enfoque moderno

Fin de la presentación

Continúe en la siguiente actividad

(4)

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

(5)

Introducción

• Es un lenguaje gráfico para visualizar, especificar, construir y

(6)

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.

(7)

Cuando usar UML

• 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.

(8)

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

(9)

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 como 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

(10)

• 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.

(11)

• Actores: se representan por un muñeco. Sus relaciones son: – Communicates: Comunica un actor con un caso de uso.

(12)

Actor Caso de Uso

(13)

• 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.

(14)

Administrador del proyecto

Administrador de recursos

<<Actor>> Sistema de Respaldo

Administrador del Sistema

Manejo de recursos Administración

del proyecto

Administrar el sistema

(15)

Diagramas de Caso de Uso 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

(16)

Tipos Diagrama UML

• Diagramas de Estado • Diagramas de actividad

(17)

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

(18)

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 quien y que interactúa con el sistema

(19)

Actores

• 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 este disponible para el proyecto

(20)

Actores

<<actor>>

Sistema de respaldo

Administrador de Recursos Administrador del

Proyecto

Recurso Humano

Administrador del Sistema

Fig. 2 Actores

(21)

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.

(22)

Asociaciones

Administrador del proyecto

Administrador de recursos

<<Actor>> Sistema de Respaldo

Administrador del Sistema

Manejo de recursos Administración

del proyecto

Administrar el sistema

Sistema de Administración del Proyecto

(23)

Asociaciones

• 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

(24)

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

(25)

Dependencias

• 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 reutlizada.

– Una dependencia include se muestra con una flecha desde el caso de uso hacia el caso de uso a incluir marcado con la

(26)

Diagramas UML de un Caso de Uso Dependencias Administrador del Proyecto Administración del Proyecto Registro de Actividades Administración De Recursos <<actor>> Sistema de Respaldo

Administrador del Sistema

Administrador de Recursos <<include>> <<include>> <<include>> Administración del Sistema

(27)

Dependencias

• Dependencia Extend

– La dependencia extend especifica un caso de uso puede o no llamar la funcionalidad de otro caso de uso.

Mantenimiento del Proyecto Mantenimiento De Actividades Mantenimiento de Tareas Administrador del Proyecto Administración del Proyecto <<extend>> <<extend>> <<extend>>

(28)

Dependencias

Puntos de extensión y dependencias extend

Recuperación de datos Inicio de Sistema

Puntos de Extensión Before: antes de inicio After: después de inicio

Apagado de Sistema

Puntos de Extensión Before: antes de apagado After: después de apagado

Administración del sistema

Puntos de Extensión Funciones de Administración

Menú de Administración

<<actor>> Sistema de Respaldo Administrador del sistema <<extend>> [Opciones de Inicio]

[Funciones de administración]

<<extend>> [Opciones de Apagado]

[Funciones de administración]

[Before]

Respaldo de datos

[After]