Curso de UML Análisis y diseño de sistemas orientado a objetos. Autor: Daniel Rosas Ramírez Julio 2007

Curso de UMLAnálisis y diseño de sistemas

orientado a objetos.

Autor: Daniel Rosas Ramírez

Julio 2007

2

UML (Unified Modeling Language).Lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos.

Origen y proceso de creación. Se origina a partir de la contratación de Grady Booch, Ivar Jacobson y Jim Rumbaugh por la

empresa Rational Software Co. para crear una notación unificada en la que basar la construcción de sus herramientas CASE.

En el proceso de creación de UML han participado, otras empresas como son Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas y desarrolladores.

UML ha puesto fin a las llamadas “guerras de métodos” que se habían mantenido a lo largo de los 90s, en las que los principales métodos sacaban nuevas versiones que incorporaban las técnicas de los demás.

Con UML se fusiona la notación de estas técnicas para formar una herramienta compartida.

Uno de los objetivos principales de la creación de UML era posibilitar el intercambio de modelos entre las distintas herramientas CASE orientadas a objetos del mercado.

Curso de UML - Introducción

3

Imagen 1. Origen y creación de UML


4


Desarrollo iteractivo e incremental.UML se basa en la idea de manejar un desarrollo interactivo e incremental, esto es el desarrollo de sistemas en pequeños pasos donde:

Lista las fases y los productos para cada fase de un proceso interactivo e incremental.

Define su interacción y lista sus actividades.

Identifica y prioriza los procesos riesgosos.

Selecciona un numero de escenarios que enfoca a los más altos riesgos del proyecto.

Al final de la iteración determina que riesgos han sido reducidos o eliminados y actualiza el plan de iteraciones pendientes.

5


Beneficios del desarrollo iterativo e incremental. Reducción de riesgos basada en tempranas revisiones.

Flexibilidad para cambiar, corregir o agregar nuevos requerimientos.

Incrementa la calidad del software.

El ciclo de vida del software es dividido en ciclos pequeños, donde en cada ciclo la salida es la generación de un producto.

Cada ciclo es una sucesión de fases: Inicio, elaboración, construcción, transición.

Los productos obtenido se revisan en temas como son: análisis del requerimiento, diseño, implementación, pruebas y documentación y en su caso se aplican sus correcciones.

Mientras se revisan los productos de un ciclo se avanza con el siguiente ciclo y si es necesario se corrige dependiendo del resultado de la validación de los productos de los ciclos anteriores.

6

Fases del ciclo de vida. Inicio.

Establece la necesidad del negocio para un nuevo sistema o para el mejoramiento de un sistema ya existente, identificando los requerimientos esenciales del sistema y una valoración del riesgo.

Elaboración.

Analiza la solución del problema, identifica los altos riesgos para el proyecto y desarrolla un plan de cómo puede ser llevado a cabo el proyecto.

Construcción.

Desarrolla un producto de software completo el cual esta listo para su transición con la comunidad de usuarios.

Transición.

Paso del software dentro de la comunidad de usuarios, al cual se le evaluará su calidad.


7


¿Qué es un objeto? Es un concepto, abstracción o cosa con límites definidos y significado para una aplicación.

Un objeto es algo que tiene: Estado, comportamiento e identidad.

Un objeto es una instancia de una clase.

Instancia es frecuentemente usado para describir un objeto.

¿Qué son las clases? Es una descripción de un grupo de objetos con propiedades similares, comportamiento común y

que se relaciona de manera común con otros objetos.

8

¿Cómo identificar posibles clases en un requerimiento? Examinando los sustantivos en casos de uso y escenarios, donde los sustantivos pueden ser

objetos, descripciones de objetos, entidades externas o actores o cualquier otra cosa.

Hacer una lista de los sustantivos identificados como posibles objetos.

Filtrar la lista considerando las siguientes condiciones.

Varios términos pueden referir al mismo objeto.

Un termino puede referirse a más de un objeto.

Puede haber sustantivo que aparecen o se describen como verbo o verbos que aparecen o se describen como sustantivos.

¿Cómo nombrar las clases? Se deben de nombrar las clases con el nombre que mejor caracterice su abstracción y que este

relacionado con el problema.

Deben utilizarse nombres simples.

La primera letra debe de ser mayúscula.

En el caso de utilizar múltiples palabras iniciar cada palabra con una mayúscula.


9


Modelos a revisar.En este curso vamos a revisar 6 de los diferentes diagramas que UML utiliza para modelar sistemas y estos son:

Modelos estáticos.

Casos de uso.

Clases

Modelos de iteración.

Secuencia

Colaboración

Estado.

Componentes.

10

Diagrama de casos de uso. Un Diagrama de Casos de Uso muestra la relación y dependencias entre los actores y los casos

de uso del sistema.

Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa.

En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior.

Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea.

No están pensados representar el diseño y no puede describir los elementos internos de un sistema.

Los diagramas de casos de uso sirven para facilitar la comunicación con los futuros usuarios del sistema.

Son útiles para determinar las características necesarias que tendrá el sistema.

Describen qué es lo que debe hacer el sistema, pero no cómo.

Los elementos que pueden modelarse en un Diagrama de Casos de Uso son: actores, casos de uso, el sistema y relaciones entre casos de uso.

Curso de UML - Análisis

11

Actor. Un actor no es parte del sistema.

Representan los roles que un usuario o elemento externo puede tener con el sistema.

Pueden ser personas (Roles), sistemas informáticos u organizaciones y el tiempo.

Tiene comportamiento y realiza algún tipo de interacción con el sistema.

Un actor puede introducir, recibir, introducir y recibir información desde o hacia el sistema.

Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores.

¿Cómo identificar un actor? ¿Quién esta interesado en cierto requerimiento?

¿Quién se beneficia de la información proporcionada por el sistema?

¿Quién puede usar una determinada función?

¿Quién soporta o da mantenimiento al sistema?

¿Qué recursos externos usa el sistema?

¿Puede un actor jugar diferentes roles?

¿Puede diferentes actores jugar un mismo rol? Actor


12

Casos de uso. Modela un dialogo entre actores y el sistema.

Es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica.

Expresa una unidad coherente de funcionalidad.

El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema.

Se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior.

¿Cómo identificar casos de uso? ¿Qué tareas realiza el actor?

¿Puede el actor crear, almacenar, borrar, o leer información en el sistema?

¿Qué caso de uso puede crear, almacenar, borrar o leer esta información?

¿Necesita el actor información de ciertas ocurrencias en el sistema?

¿Qué casos de uso pueden dar soporte y mantenimiento al sistema?

¿Pueden ser realizados todos los requerimientos funcionales por los casos de uso?

¿Es proceso funcional o no funcional?

Caso de uso


13

Reglas para definición de los casos de uso. Un caso de uso es iniciado por un actor que invoca cierta funcionalidad en el sistema.

Un caso de uso es un completo y relevante flujo de eventos.

Considerando juntos todos los casos de uso constituyen todas las formas posibles de interactuar con el sistema.

Cada Caso de Uso está relacionado como mínimo con un actor.

Cada Caso de Uso lleva a un resultado relevante.

Tiene un flujo básico de secuencia de transacciones.

Puede tener varias secuencias de transacciones alternas.

Controla varias secuencias de transacciones alternas controlando situaciones de error.

Tiene bien definida sus pre-condiciones y post-condiciones.

Fuentes de información para casos de uso. Especificaciones del sistema.

Revisión con expertos o usuarios acerca del tema.

Conocimientos personales del tema.

Requerimientos legales.

Limitaciones técnicas y de infraestructura.


14

Documentación de casos de uso. Se puede documentar un caso de uso usando una libre descripción explicando el propósito del

caso de uso en pocas líneas.

O detallar el flujo de eventos que tendrá el caso de uso: incluyendo el flujo básico y los flujos alternos que pueden ejecutarse

Cualquiera de los dos debe de considerarse en términos que el usuario pueda comprender, evite utilizar terminología como “por ejemplo”, “etc.

Documentación de flujos de casos de uso. Se describe solamente lo que ocurre en el caso de uso y no lo que pasa en otros casos de usos.

Describir quién y cuando inicia los casos de uso.

Indicar que información se intercambia entre el actor y los casos de uso.

Describir el flujo básico de eventos numerándolos.

Describir el o los flujos alternos posibles numerándolos.


15

¿Quién lee la documentación de casos de uso? Clientes.- Aprueban lo que el sistema podrá hacer.

Usuarios.- Les provee el entendimiento del sistema.

Desarrolladores de sistema.- Los documenta del comportamiento del sistema.

Revisores.- Examinan los flujos del sistema.

Analistas de sistemas.- Les provee las bases del análisis y diseño.

Testers.- Les da las bases de los casos de prueba.

Lideres de proyecto.- Les ayuda a la planeación del sistema.


16

Sistema. Representa al sistema que se va a diseñar.

Dentro de el deben de quedar los casos de uso.

Fuera de el deben de quedar los autores.

Se representa con un rectángulo con la palabra “system” en la esquina superior derecha.


System

17

Relaciones entre casos de uso. Se utiliza en las ocasiones que es mejor describir Casos de Uso más pequeños que se relacionen

entre si, que describir uno solo caso de uso grande.

Mejoran la comunicación en el equipo de desarrollo por medio de casos de uso más pequeños.

Permite determinar comportamientos condicionados o compartir casos de uso comunes a varios de ellos.

Los tipos de relaciones entre Casos de Uso pueden ser:

Comunica.

Inclusión.

Extensión.

Generalización.


18

Tipos de relaciones entre casos de uso.

Comunica.

Relación entre un autor y un caso de uso que denota la participación del actor en dicho caso de uso. Su estereotipo es <<communicates>>, normalmente no se estereotipa.

Inclusión.

Un Caso de Uso incorpora explícitamente a otro caso de uso el cual puede ser además relacionado por otros Casos de Uso. Su estereotipo es <<include>>, anteriormente su estereotipo era <<use>>.

Extensión.

Un Caso de Uso opcionalmente realiza una iteración adicional basada en ciertos criterios, su estereotipo es <<extend>>.

Generalización.

Un Caso de Uso definido de manera abstracta se particulariza por medio de otro Caso de Uso más específico, el Caso de Uso hijo hereda las asociaciones y características del Caso de Uso padre. Se representa por una línea continua entre los dos casos de uso con un triangulo que indica la generalización. Este tipo de relación es poco usada.

<<extend>>

<<include>>


19

Ejemplo de diagrama de caso de uso - Requerimiento.

Banco “Actual” requiere que se diseñe un sistema que permita realizar consultas y retiros a través de un cajero automático.

En cada operación de retiro es necesario que se realice la impresión del ticket de retiro como comprobante al cliente; alternativamente el usuario podrá realizar consultas de su saldo y opcionalmente realizar la impresión de este.

Como medida de seguridad además de la tarjeta el usuario deberá certificar su autenticidad de cliente mediante un usuario y clave de acceso asignado por Banco “Actual”, en el caso de accesos que no verifiquen la autenticidad del cliente se le devolverá la tarjeta pero se bloqueará su cuenta por 3 días o en el momento que el cliente se ponga en contacto con banco “Actual” y se autentifique.


20

System

Cliente

Acceder al sistema

Retiro de efectivo

Impresion de saldoConsulta de saldos

<<extend>>

<<include>>Imprimir tiquet

de retiro

Bloquear cuenta

<<extend>>


Ejemplo de diagrama de caso de uso - Modelo

21


Puntos de caso de uso. Es un método de estimación de esfuerzo de un proyecto de desarrollo de software a partir de casos

de uso.

El método utiliza actores y casos de uso identificados para calcular el esfuerzo que costará desarrollarlos.

El proceso para calcular los puntos de casos de uso es el siguiente:

A los actores se les asigna una complejidad basada en el tipo de actor, es decir si son interfaces con usuarios o sin interfaces con otros sistemas (UAW).

A los casos de uso se les asigna una complejidad basada en transacciones (UUCW).

Una vez asignada la complejidad a actores y casos de uso se calculan los puntos de caso de uso no ajustados (UUCP),

Se establecen factores de complejidad técnica (TCF).

Se establecen factores de entorno (EF)

Se calcula los puntos de caso de uso ajustados (UCP) en base a los resultados de los puntos de caso de uso no ajustados (UUCP), factor complejidad técnica (TCF) y factor de entorno (EF).

Se traducen los puntos a esfuerzo en horas-hombre (E) mediante los puntos de casos de uso y un valor predefinido por punto de caso de uso.

22

Factor de peso de los actores sin ajustar (UAW).Se calcula mediante el análisis de la cantidad de actores presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de los actores se establece teniendo en cuenta si se trata de una persona o de otro sistema y la forma en que interactúa con el sistema.

UAW = (NumActorSimple * 1 ) + (NumActorMedio * 2) + (NumActorComplejo*3)


Tipo de actor

Descripción Factor de peso

SimpleOtro sistema que interactúa con el sistema a desarrollar mediante una interfaz de programación (API, Aplication Programming Interface).

1

Medio Otro sistema que interactúa con el sistema a desarrollar mediante un protocolo o una interfaz basada en texto.

2

Complejo Una persona que interactúa con el sistema mediante una interfaz gráfica

3

23

Factor de peso de los casos de uso sin ajustar (UUCW).Se calcula mediante el análisis de la cantidad de casos de uso presentes en el sistema y la complejidad de cada uno de ellos. La complejidad de los casos de uso se establece teniendo en cuenta la cantidad de transacciones efectuadas en el mismo, donde una transacción se entiende como una secuencia de actividades completas.

UUCW = (NumCUSimple * 5) + (NumCUMedio * 10) + (NumCUComplejo * 15)


Tipo de caso de uso

Descripción Factor de peso

Simple El caso de uso contiene de 1 a 3 transacciones

5

Medio El caso de uso contiene de 4 a 7 transacciones

10

Complejo El caso de uso contiene 8 o más transacciones

15

24

Puntos de casos de uso sin ajustar (UUCP).Se calcula sumando el factor de peso de los actores más el factor de peso de los casos de uso.

UUCP = UAW + UUCW

Donde UAW es el factor de actores sin ajustar y UUCW es el factor de casos de uso sin ajustar.


25

Factor de complejidad técnica (TCF).Se calcula mediante la cuantificación de un conjunto de factores que determinan la complejidad técnica del sistema, cada uno de los factores se cuantifica con un valor entre 0 y 5, donde 0 significa irrelevante y 5 un aporte muy importante.

TCF = 0.6 + (0.01 x (Suma(PesoTn x valor asignadoTn)))


Factor DescripciónFactor de peso

T1 Sistema distribuido 2

T2 Objetivo de performance o tiempo de respuesta 1

T3 Eficiencia del usuario final 1

T4 Procesamiento interno complejo 1

T5 El código debe ser reutilizable 1

T6 Facilidad de instalación 0.5

T7 Facilidad de uso 0.5

T8 Portabilidad 2

T9 Facilidad de cambio 1

T10 Concurrencia 1

T11 Incluye objetivos especiales de seguridad 1

T12 Provee acceso directo a terceras partes 1

T13 Se requieren facilidades especiales de entrenamiento a usuarios 1

26


Factor de ambiente (EF).Las habilidades y el entrenamiento del grupo involucrado en el desarrollo tienen un gran impacto en las estimaciones de tiempo, el calculo se obtiene considerando un conjunto de factores que se cuantifican con valores entre 0 y 5.

En E1 hasta E4 el valor 0 significa sin experiencia, 3 experiencia media y 5 experto.

En E5 el valor 0 significa sin motivación, 3 motivación media y 5 alta motivación.

En E6 el valor 0 altamente inestables, 3 estabilidad media y 5 estable sin posibilidad de cambio.

En E7 el valor 0 significa que no hay personal, 3 mitad y mitad y 5 todo el personal.

En E8 el valor 0 significa que el lenguaje es fácil de usar, 3 medio y 5 extremadamente difícil.

EF = 1.4 – (0.03 x (Suma(PesoEn * valor asignadoEn)))

Factor DescripciónFactor de

peso

E1 Familiaridad con el modelo de proyecto utilizado 1.5

E2 Experiencia de la aplicación 0.5

E3 Experiencia en orientación a objetos 1

E4 Capacidad de analizar del líder 0.5

E5 Motivación 1

E6 Estabilidad de los requerimientos 2

E7 Personal de medio tiempo -1

E8 Dificultad del lenguaje de programación -1

27


Puntos de casos de uso ajustados (UCP).El resultado de multiplicar los puntos de casos de uso sin ajustar por factor de complejidad técnica por factor de ambiente.

UCP = UUCP * TCF * EF

Donde UUCP es Puntos de casos de uso sin ajustar, TCF es factor de complejidad técnica y EF es el factor de ambiente.

Horas hombre requeridas por cada punto de caso de uso.Las horas hombres consideradas por cada caso de uso pueden variar de organización en organización se recomienda que por cada punto de caso de uso se consideren 20 hrs. tiempo hombre, por lo que considerando este dato el calculo de horas sería.

E = UCP * CF

Donde E es el esfuerzo, UCP es los puntos de casos de uso ajustados y CF es valor de conversión por punto de caso de uso.

28

Ejemplo de cálculo de puntos de caso de uso.Factor de peso de los actores sin ajustar (UAW).

Tipo de actor Usuarios Factor Total

de peso

Simple 0 1 0

Medio 0 2 0

Complejo 1 3 3

Total 3

UAW = 3

Factor de peso de los casos de uso sin ajustar (UUCW).

Tipo de caso de uso Casos de uso Factor de peso Total

Simple 4 5 20

Medio 2 10 20

Alto 0 15 0

Total 40

UUCW = 40

Puntos de casos de uso sin ajustar (UUCP).

UUCP = 3 + 40 = 43


29

Ejemplo de cálculo de puntos de caso de uso.Factor de complejidad técnica (TCF).

Factor Descripción Peso Valor Total Comentarios

asignado

T1 Sistema distribuido 2 5 10 Totalmente

T2 Objetivo de performance o tiempo 1 5 5 Requiere buen tiempo de de respuesta respuesta

T3 Eficiencia del usuario final 1 0 0 No requiere

T4 Procesamiento interno complejo 1 3 3 Medianamente complejo.

T5 El código debe ser reutilizable 1 0 0 No nos interesa

T6 Facilidad de instalación 0.5 3 1.5 No es totalmente importante.

T7 Facilidad de uso 0.5 5 2.5 Debe de ser muy fácil de usar

T8 Portabilidad 2 0 0 No lo requiere.

T9 Facilidad de cambio 1 3 3 Que se mantenible.

T10 Concurrencia 1 5 5 Para más de 1000 usr

simultaneamente

T11 Incluye objetivos especiales de seguridad 1 5 5 Básico para su proceso.

T12 Provee acceso directo a terceras partes 1 5 5 Usuarios y ejecutivos.

T13 Se requieren facilidades especiales de 1 0 0 Ninguno.

entrenamiento a usuarios

Total 40

TCF = 0.6 + (0.01 x 40) = 1


30

Ejemplo de cálculo de puntos de caso de uso.Factor de ambiente (EF).

Factor Descripción Peso Valor Total Comentario

E1 Familiaridad con el modelo de 1.5 3 4.5 Se conoce un poco.

proyecto utilizado

E2 Experiencia de la aplicación 0.5 5 2.5 Total experiencia.

E3 Experiencia en orientación a objetos 1 0 0 Ninguna experiencia

E4 Capacidad de analizar del líder 0.5 5 2.5 Es muy capaz

E5 Motivación 1 5 5 Existe mucha motivación

E6 Estabilidad de los requerimientos 2 3 6 Son medianamente estables

E7 Personal de medio tiempo -1 0 0 Todo el personal es de tiempo

completo

E8 Dificultad del lenguaje de programación -1 3 -3 Medianamente complejo.

Total 17.5

EF = 1.4 – (0.03 x 17.5) = 0.875


31


Ejemplo de cálculo de puntos de caso de uso.Puntos de casos de uso ajustados (UCP).

UCP = 43 * 1 * 0.875 = 37.625

Horas hombre requeridas por cada punto de caso de uso.

El factor de conversión para las horas hombre por punto de caso de uso se considerara con 20 hrs.

E = 37.625 * 20 = 752.5.

Como resultado de nuestro análisis de puntos de casos de uso, la solución de nuestro requerimiento la planeación de nuestro proyecto deberá de basarse en 752.5 hrs.

32


¿Cuáles son los puntos de caso de uso?Es el resultado de multiplicar los puntos de casos de uso no ajustados por el factor de complejidad técnica y por el factor de entorno.

Donde los puntos de casos de uso es la suma de el factor de complejidad del autor más el factor de complejidad de los casos de uso

¿Cómo se determina a partir de los puntos de casos de uso el esfuerzo horas-hombre?

Es el resultado de multiplicar los puntos de casos de uso ajustados por un valor predeterminado por cada punto de caso de uso.

El valor es predeterminado por la organización se recomienda que sea 20 hrs. por cada punto de caso de uso.

33

Diagrama de Clases. Son diagramas de estructura estática.

Muestra un conjunto de Clases y sus interrelaciones (incluyendo relación, herencia, agregación y asociación, etc.).

Se utilizan para mostrar lo que el sistema puede hacer (análisis), como para mostrar como puede ser construido (diseño).

El diagrama de más alto nivel debe de ser un diagrama hecho con paquetes.

Las clases se documentan con una descripción de lo que hacen, sus métodos y sus atributos.

Sus atributos deben de ser privados.

Sus métodos deben de ser públicos.

Las clases se comunican entre sí a través de mensajes.

Las clases se documentan con una descripción de lo que hacen, sus métodos y sus atributos.

Las relaciones entre clases se documentan con una descripción de su propósito, su cardinalidad (cuantos objetos intervienen en una relación) y su opcionalidad (cuando un objeto es opcional que intervenga en una relación).

La descripción de clases complejas se puede documentar con diagramas de estado.

En la relación se puede indicar un rol para cada clase y su multiplicidad en la relación.

Curso de UML - Diseño

34

Cómo elaborar un diagrama de clases. Identificar todas las clases que participan en la solución del software.

Dibuje las clases en un diagrama de clases.

Documente la información de sus atributos.

Documente la información de sus métodos.

Agregue las asociaciones necesarias para dar soporte a la visibilidad requerida de los atributos.

Agregue flechas de navegabilidad a las asociaciones para indicar la dirección de la visibilidad de los atributos.

Los diagramas de clases se pueden relacionar por medio de:

Asociación.

Dependencia

Agregación.

Composición.

Generalización

Los elementos que pueden modelarse en un diagrama de clases son: Clases y relación entre clases.


35

Clase. Se representa por un rectángulo con compartimientos internos, los compartimientos contienen el

nombre, atributos y operaciones de la clase.

Los atributos identifican las características propias de cada clase y generalmente son de tipo simple.

En el caso de los atributos complejos se diagraman a través de relaciones de composición con otras clases

La subclase hereda todos los atributos y mensajes descritos en la superclase.

Clase

-Atributo

+Operation1()


36

Estereotipos de clases.Los estereotipos son utilizados para clasificar las clases y los más comunes son:

Entity.

Modela información de larga vida y su comportamiento asociado, modela abstracciones de entidades del mundo real.

<<Entity>>

Boundary.

Maneja comunicaciones entre el entorno del sistema y el sistema, modelan las interfaces del sistema.

<<Boundary>>

Control.

Modela el comportamiento secuenciado específico de uno o varios casos de uso, coordinan los eventos necesarios para llevar a cabo el comportamiento que se especifica en el caso de uso, representan su dinámica.

<<Control>>


37

Relación entre clases.Una relación en el diagrama de clases se representa mediante una línea que une a dos o más clases. La línea puede ir acompañada de una o más características que definen sus semántica como son asociación (binaria o n-aria), agregación, generalización, dependencia, composición y clasificación.

Dentro de la relación se puede indicar: Rol y multiplicidad

Rol.

Nombra a los elementos que aparecen en el extremo de la línea que denota la relación.

Multiplicidad.

Indica la cardinalidad de la relación ejemplo: 1, 0..*, 1..*.


38

Tipo de relaciones entre clases. Asociación.

Se representa mediante una línea sólida que une dos clases, en esta relación no se exige dependencia existencial ni encapsulamiento.

Dependencia.

Se representa por una línea punteada que termina con una punta de flecha, este tipo de relación indica una dependencia de una clase a otra.

Agregación.

Especifica una relación todo-parte entre el agregado (todo) y una parte que lo compone. Se representa mediante un rombo en el extremo “todo” de la relación.


39

Tipo de relaciones entre clases (continuación). Composición.

Específica una relación más fuerte que la agregación que implica:

Dependencia existencial.- El elemento dependiente desaparece al destruirse el que lo contiene y si es de cardinalidad 1, es creado al mismo tiempo.

Pertenencia fuerte.- Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene.

No compartición.- Los objetos contenidos no son compartidos, es decir no forman parte del estado de otro objeto.

Se representa por un rombo relleno del lado de la clase que contiene a la otra agregación.

Generalización.

Denota herencia entre clases, se representa mediante un triángulo sin rellenar del lado de la superclase.

La subclase hereda todos los atributos y mensajes descritos en la superclase.


40

Ejemplo de diagrama de clases – Requerimiento.Para que un usuario a través del cajero automático tenga acceso a nuestros servicios requiere dos cosas: la tarjeta de débito y certificarse a través de un usuario y una clave de acceso todo esto otorgado por banco “Actual”.

Para llevar a cabo esta validación se revisará que la persona este relacionada con la tarjeta de débito que este intentando acceder, en caso de no certificar su autenticidad será bloqueada su cuenta por seguridad por 3 días o hasta que el cliente se ponga en contacto con el banco.

En caso contrario se le permitirá realizar su consulta o retiro de efectivo (ver sus correspondiente casos de uso para más información).

Cabe aclarar que las tarjetas de crédito por seguridad no tendrán acceso a los cajeros de banco “Actual”.


41

Ejemplo de diagrama de clases - Modelo

Personas

-Id persona-Nombre-Direccion-Telefóno-Fecha de nacimiento

+AltaPersona()+BajaPersona()+MantoPersona()

Clientes

-Id Cliente-Categoría

CuentasDebito

-Id Cuenta-Saldo de la cuenta-Estatus

+AltaCuenta()+CancelarCuenta()+BloquearCuenta()+RehabilitarCuenta()

Tarjeta

-Id Tarjeta-Tipo de tarjeta

+AltaTarjeta()+Baja Tarjeta()

1

1

0..*

1

Movimientos

-Fecha-Importe

+AgregarMovto()

0..1 1


42

Diagrama de Secuencia. Muestra las interacciones entre objetos ordenados en secuencia temporal.

Muestra los objetos que se encuentran en el escenario y la secuencia de mensajes intercambiados entre los objetos para llevar a cabo la funcionalidad descrita en el escenario.

Se utiliza para validar los cosos de uso.

Documentan el diseño desde el punto de vista de los casos de uso.

Nos ayudan a identificar cuellos de botella potenciales, para así evitarlos.

Sus atributos deben de ser privados.

Los elementos que pueden modelarse en un diagrama de secuencia son: Objeto, línea de vida, activación, mensaje y caminos alternos.


43

Elementos para el diagrama de Secuencia.

Objeto.

Es un rectángulo en la parte superior del diagrama que contiene el nombre del objeto y de su clase en un formato nombreObjeto:NombreClase.

Línea de vida de un objeto.

Se representa como una línea vertical punteada con un rectángulo de encabezado y con rectángulos a través a través de la línea principal que denota la ejecución de los métodos.

Activación.

Se representa como un rectángulo delgado sobre la línea de vida del objeto, Muestra el período de tiempo en el cual el objeto se encuentra desarrollando alguna operación, bien sea por sí mismo o por una delegación a alguno de sus atributos.


44

Elementos para el diagrama de Secuencia

Mensaje.

Se denota mediante una línea sólida dirigida , desde el objeto que emite el mensaje hacia el objeto que lo ejecuta, precedida por un número que indica la secuencia del mensaje, a este mensaje se le puede anexar una operación a realizar, esta operación se corresponde con las definidas en las clases.

Caminos alternativos de ejecución.

Se denotan especificando una condición que permita elegir una u otra alternativa, además de denotar caminos alterno, se puede especificar otros como son camino opcional, ciclo, el diseño de los mensajes correspondientes deben de estar dentro de este cuadro para indicar dicho camino.

Camino alternoalt

[Validación verdadera]

[Validación falsa]


45

Ejemplo de diagrama de secuencia - RequerimientoEn base a la especificación definida para el caso de uso “acceder al sistema” diseñar el diagrama de secuencia.


46

Estatus habilitadaopt

Autentificaciónalt

[Correcta]

[Incorrecta]

Autentificaciónalt

[Correcta]

[Incorrecta]

Autentificaciónalt

[Correcta]

[Incorrecta]

[Correcta]

[Incorrecta]

: Tarjeta

: Cliente

: CuentasDebito

1 : Autentificarse()

2 : ValidarEstatus()

3 : BloquearCuenta()

Ejemplo de diagrama de secuencia - Modelo


47

Diagrama de colaboración. Es alternativo al diagrama de secuencia, debiera seleccionarse uno u otro.

Muestra la interacción entre objetos organizadas entorno a los objetos y los enlaces entre ellos.

Proporcionan una forma de ver el escenario de una forma cronológica – que pasa primero, que pasa después-.

Es más fácil de comprender, por lo que resultan ideales en las primeras fases del análisis.

Los principales elementos que se pueden modelarse en un diagrama de colaboración son: Objeto, enlaces, flujo de mensajes.


48

Elementos para el diagrama de colaboración

Objeto.

Se representa con un rectángulo que contiene el nombre y la clase del objeto en el formato nombreObjeto:nombreClase.

Enlaces.

Un enlace es una instancia de una asociación en un diagrama de clases.

Se representa como una línea continua que une a dos objetos, acompañada por un número que indica el orden dentro de la interacción.

Se pueden utilizar estereotipos para indicar si el mensaje que recibe el objeto es un atributo, un parámetro o un objeto local o global.

Flujo de mensajes.

Expresa el envío de un mensaje, se representa mediate una flecha dirigida cerca del enlace.

Objeto : Clase


49

Ejemplo de diagrama de colaboración – Requerimiento.En base a la especificación definida para el caso de uso “acceder al sistema” diseñar el diagrama de colaboración.


50

Ejemplo de diagrama de colaboración – Modelo.


51

Diagrama de transición de estado. Un estado es la condición de una condición durante la vida de un objeto.

Cuando una condición se cumple se espera una acción o la ejecución de un evento.

El estado del objeto se puede identificar por los valores de uno o varios de sus atributos de su clase.

Engloba todos los mensajes que un objeto puede enviar o recibir.

Un escenario representa un camino dentro del diagrama.

En todo diagrama de estados existen por lo menos dos estados: el inicial y el final.

Cada diagrama puede tener un solo valor de inicio pero puede tener varios estados finales.

Una transición de estado puede tener asociada una acción y una guarda (condición).

Una transición puede disparar un evento.

La acción es el comportamiento que se obtiene cuando ocurre la transición.

El evento es un mensaje que se envía a otro objeto del sistema.

La guarda es una expresión lógica sobre los valores de los atributos que hacen que la transición se produzca si el resultado es verdadero.

Tanto las acciones como la guarda son comportamiento del objeto y generalmente se traducen en operaciones de alguna clase.


52

Diagrama de transición de estado (Continuación). Una transición de estados representa un cambio de un estado origen a un estado sucesor

destino y puede estar acompañado de una acción.

Las acciones se asocian a las transiciones y se considera que ocurre de forma rápida e ininterrumpible.

Las actividades se asocian a los estados pudiendo consumir más tiempo, las actividades pueden ser interrumpidas por la ocurrencia de un evento.

Las transiciones de un estado pueden realizarse de manera automática o no automática.

Una transición automática es cuando se acaba la actividad del estado origen (no hay evento asociado a la transición).

Una transición no automática es cuando existe un evento que puede pertenecer a otro objeto o incluso estar fuera del sistema.

Los diagramas de estado muestran el comportamiento de los objetos, es decir el conjunto de estados por los cuales pasa un objeto durante su vida, junto con los cambios que permite pasar de un estado a otro.

Un estado identifica un periodo de tiempo no instantáneo en la vida de un objeto durante el cual esta esperando una operación, tiene cierto comportamiento característico o puede recibir cierto tipo de estimulo.

Los elementos que pueden modelarse en un diagrama de transición de estado son: Estado inicial, estado, transición y estado final.


53

Elementos del diagrama de transición de estado.

Estado.

Se representa mediante un rectángulo con los bordes redondeados, que puede tener tres compartimientos, uno para el nombre, otro para el valor característico de los atributos y otro para las acciones que se realizan al entrar (entry), salir (exit) o estar en un estado (do).

Estado inicial.

Se representa mediante un circulo relleno.

Estado final.

Se representa mediante un círculo relleno (pequeño) bordeado por un circulo vacío más grande con un espacio entre ellos.

Transición.

Se representa mediante una línea recta con punta de flecha, a esta transición se le puede indicar un mensaje o condición (guarda) la cual se representa entre corchetes.


54

Ejemplo de diagrama de transición de estado - RequerimientoEn base a la definición del diagrama de clases diseñar el diagrama de transición de estado del objeto CuentasDébito.


55

Ejemplo de diagrama de transición de estado - Modelo

Vigente Congelada

Cancelada

Cuando es asignada al cliente

[ Autentificación en cajero erronea ]

Cuando el cliente lo solicite

Rehabilitada

[ Después de 3 días o por contacto del usuario con el banco ]


56


Diagrama de actividades. Su idea se basa en los diagramas de Pert en el cual se puede ver el flujo de actividades

que tienen lugar a lo largo del tiempo, así como las tareas concurrentes que pueden realizarse a la vez.

Sirve para representar el comportamiento del sistema desde otra perspectiva, complementando el resto de los diagramas.

Gráficamente el diagrama de actividades es un conjunto de arcos y nodos.

Conceptualmente muestra el cómo fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total, para la consecución de un proceso más complejo.

57


Elementos del diagrama de actividades.

Estado inicial.

Se representa mediante un circulo relleno.

Estado final.

Se representa mediante un círculo relleno (pequeño) bordeado por un circulo vacío más grande con un espacio entre ellos.

Transición.

Se representa mediante una línea recta con punta de flecha, a esta transición se le puede indicar un mensaje o condición (guarda) la cual se representa entre corchetes.

58


Elementos del diagrama de actividades.

Decisión.

Se representa mediante un rombo que permite bifurcar entre varias posibilidades durante la transición de una actividad la cual se puede controlar mediante guardas.

Acción.

Indica la ejecución de una acción atómica (es decir una operación a realizar).

Subactividad.

Indicar la ejecución de una acción no atómica (es decir una actividad que requiere de muchas operaciones para ser completada).

Acción

Subactividad

59

Ejemplo de diagrama de actividades - RequerimientoEn base a la especificación definida para el caso de uso “acceder al sistema” diseñar el diagrama de actividades.


60


Capturar clave yllave de acceso

¿Esta activa la cuenta?

Validar clave y llave deacceso

Envia mensaje de error"Cuenta bloqueada"

Desplegar el menúprincipal

¿Es correcta la información?

si Si

¿Tres intentos erroneos?

si

bloquear cuenta

Ejemplo de diagrama de actividades - Modelo

61


Diagrama de componentes. Muestra la organización y las dependencias entre un conjunto de componentes.

Son útiles para modelar código fuente, versiones ejecutables y sus bibliotecas o para modelar bases de datos.

Los elementos que pueden modelarse en un diagrama de componentes son componentes, interfaces, artefactos y sus relaciones.

62

Elementos del diagrama de componentes.

Componentes.

Representan un bloque de construcción al modelar aspectos físicos de un sistema, se caracteriza por tener una abstracción precisa con una interfaz bien definida, que permita reemplazar fácilmente los componentes más viejos con otros más nuevos y compatibles.

Existen básicamente tres tipos de componentes: componentes de despliegue, componentes de producto del trabajo y componentes de ejecución.

Componentes de despliegue.

Necesarios y suficientes para formar un sistema ejecutable, tales como bibliotecas dinámicas (DLLs) y ejecutables (EXEs).

Componentes producto del trabajo.

Son productos que quedan al final del proceso de desarrollo tales como archivos de código fuente y archivos de datos a partir de los cuales se crean los

componentes de despliegue.

Componentes de ejecución.

Se crean como consecuencia de un sistema en ejecución, tales como objetos COM+ que se instancian a partir de una DLL.


Componente

63


Elementos del diagrama de componentes.

Interfaces.

Son los servicios que realizan la unión entre componentes, se puede representar de forma icónica o de forma expandida en forma de texto.

Artefactos.

Representa una pieza de información que es usada o producida por el desarrollo de un software, puede modelarse en la creación o destrucción de un componente.

Relación

Por medio de la relación se ligan los componentes, interfaces o artefactos puede ser por asociación o por dependencia.

interfaz icónointerfaz textual<<interface>>

Artefacto

DependenciaAsociación

64


Ejemplo de diagrama de componentes - RequerimientoEn base a la especificación definida para el caso de uso “acceder al sistema” diseñar el diagrama de componentes.

65


Ejemplo de diagrama de componentes – Modelo

Ventana J ava Programa.J ava

Autentificación

Log de acceso a la red

66

Revisión básica de StarUML

a) Crear un nuevo proyecto.1. Abrir StarUML2. [File] [New project by approach] [Default approach]3. [File] [Save as..] Teclear el nombre archivo UML desde la ventana “Save as..”.

b) Abrir un proyecto existente.1. Abrir StarUML2. [File] [Open] Buscar el directorio y seleccionar el archivo desde la ventana “Open”.

c) Abrir un proyecto utilizado recientemente.1. Abrir StarUML2. [File] [Recent Files] Seleccionar el documento deseado de la lista.


67

Revisión básica de StarUML

d) Identificar las diferentes ventanas de UML.

La distribución de StarUML de las diferentes ventanas pueden personalizarse de tal manera que muchas veces resulta difícil identificar donde están colocadas, en el caso de estar en esta situación la mejor forma de localizarla es haciendo lo siguiente:

1. Ya con el proyecto abierto o un nuevo proyecto creado.2. [View] dar Click sobre todas las palomitas que aparecen en el menú excepto el que nos interesa localizar, con esto desaparece la palomita del menú y la ventana dentrodel entorno de StarUML.

3. En cualquier momento puede ser visible o invisible una ventana dentro del entorno de StarUML.

e) Crear un diagrama.1. Identificar la ventana “Model Explorer”.2. Sobre <<useCaseModel>> [Click derecho] [Add diagram] [Seleccionar el diagrama] 3. Teclear el nombre que queremos para el diagrama.4. En cualquier momento podemos cambiar el nombre del diagrama de la siguiente manera:

4.1. Dentro del diagrama que queremos cambiar de nombre.4.2 Identificar la ventana “Properties”4.3. Sobre “Name” [Dar click] Teclear o cambiar el nombre.


68

Revisión básica de StarUMLf) Agregar los elementos a diagramas.

1. Ya dentro del diagrama al que deseamos agregar elementos.Identificar la ventana “Toolbox” la cual nos muestra los elementos posibles a agregar al diagrama en el que estamos localizados.

2. Para los elementos diferentes de las relaciones (flechas) que desee agregar se hace lo siguiente:[Click al elemento deseado en la ventana “Toolbox”] [Dar click sobre la ventana del diagrama de caso de uso]

3. En el caso de los elementos que requieran un nombre teclearlo.

4. Para los elementos de relación (Flechas) se hace lo siguiente:[Click al elemento relación (flecha) deseado en la ventana “Toolbox”] [Dar click sin soltar sobre el elemento origen][arrastrar el ratón y soltar el click sobre el elemento destino]

5. Ya dentro del diagrama puede mover los elementos a su gusto en el lugar que desee en el caso de contener elementos de relación estos se desplazaran de acuerdo al elemento que tengan ligado.


69

Revisión básica de StarUMLg) Insertar elementos “libres” en cualquier diagrama de UML

Desde cualquier diagrama de UML se pueden agregar los siguiente elementos de manera libre con el fin de complementar la documentación de nuestros diagramas o facilitar su lectura.

“Texto”.- Agregar texto en cualquier parte de nuestros diagramas.

“Note”.- Agrega notas especificas a un elemento.

“Notelink”.- Identificar que notas van relacionadas a que objeto, por ejemplo una nota se liga a una clase o a un caso de uso especifico.

“Rectángulo”.- Agrega agrega un rectángulo a nuestros diagramas.

“Elipse”.- Agregar un elipse a nuestros diagramas.

“Rectángulo redondeado”.- Agregar un rectángulo redondeado a nuestros diagramas.

Nota

Texto libre


70

Revisión básica de StarUMLh) Agregar elementos “libres” a cualquier diagramas.

1. Ya dentro del diagrama al que deseamos agregar elementos.2. Identificar la ventana “Toolbox” la cual nos muestra los elementos posibles a agregar para casos de uso.3. Dentro de “Toolbox” dar click al subtema “Annotation”.4. Seleccionar el elemento “libre” que desee diagramar.5. Y dar click dentro del diagrama.

i) Documentación.Podemos a través de UML documentar: Diagramas, Elementos, Casos de uso.

j) Documentar diagramas.1. Identificar la ventana “Documentation”.2. Dentro del diagrama que queremos documentar dar click en un área vacía.3. Dentro de la ventana “Documentation” escribir cual es el propósito de ese diagrama tratando de explicar de la manera más amplia su contenido.

k) Documentar elementos.1. Identificar la ventana “Documentation”.2. Dentro del diagrama que se encuentra el elemento que queremos documentar dar click en dicho elemento.3. Dentro de la ventana “Documentation” escribir cual es el propósito de ese elemento dentro del diagrama.


71

Revisión básica de StarUMLl) Documentar casos de uso.

1. Dentro del diagrama de casos de uso.2. Seleccionar el caso de uso que queremos documentar.3. [Model] [Tagged Values..] 4. Seleccionar [UsaCaseSpecification] del combo “Tag definition set”.5. Podemos documentar cada uno de los siguientes datos:

5.1. Flujo básico (BasicFlow).- Señalar con números el orden del proceso básico.

5.2. Flujo alterno (AlternativeFlow).- Señalar que caminos debe de seguir el proceso en caso de darse ciertas condiciones se pueden numerar cada uno de los flujos alternos posibles.

5.3. Requerimientos especiales (Special requirement).- Señalar requerimientos especiales que son necesarios para poder procesar el caso de uso.

5.4. Precondiciones (Preconditions).- Señalar que condiciones son necesarias para poder procesar el caso de uso.

5.5. Postcondiciones (Postconditions).- Señalar que condiciones son necesarias dejar posterior a la ejecución del caso de uso.

5.6. ExtensionPoints (Puntos de extensión).- Indicar que casos de uso pueden dar una extensión a este caso de uso.


72


Fin del curso.

Documents

Curso de UML Análisis y diseño de sistemas orientado a objetos. Autor: Daniel Rosas Ramírez Julio 2007