3.

UML
La notacin o lenguaje UML define una gran nmero de productos o artefactos que se ven involucrados en las diferentes etapas del desarrollo del software.

Los ms importantes se muestran a continuacin:

El ciclo de vida del desarrollo del software se puede simplificar en tres grandes etapas: anlisis, diseo y programacin. Durante esta asignatura para a trabajar con este ciclo de vida, aplicable a cualquier metodologa gil de desarrollo, como puede ser Scrum. A continuacin se detallan estas etapas, destacando los productos o artefactos UML que se obtienen en cada una de ellas. Documentacin/Planificacin: Anlisis: Diseo: Preeliminar o de alto nivel: funcionalidad global del sistema y su interaccin. o Especificacin de la arquitectura y agrupacin de las unidades de programacin: Diagrama de Componentes y Diagramas de paquetes. o Refinar los casos de uso: descripcin detallada de los casos de uso. o Aplicacin de los patrones de diseo. Detallado: detalles propios del desarrollo del software. o Especificacin de las clases que van a formar parte del desarrollo del software. o Refinar los Diagramas de clases del modelo de dominio, Diagramas de actividad, Diagramas de interaccin (colaboracin y secuencia), etc. o Aplicacin de los patrones de diseo. Documento que represente el conocimiento del problema: Modelo de Dominio (Diagrama de clases). Definicin de los requisitos: Modelo de Casos de Uso (Diagrama de casos de uso). Propuesta de prototipos. Definicin de documentos a entregar y planificacin del proyecto.

Implementacin: Programacin de la solucin software diseada, partiendo de los diagramas de componentes. Programacin de las clases a partir de los diagramas de paquetes y de clase. Programacin de los mtodos a partir de los diagramas de actividad, interaccin y estado.

3.1. DIAGRAMAS DE CLASE 3.1.1. ASOCIACIN

Se puede indicar propiedades de la relacin: {ordered}, {unordered}, {unique}, {nonunique}, {bag}

3.1.2. DEPENDENCIAS
Existe entre dos objetos cuando un cambio en la definicin de uno (destino o suministrador) puede causar cambios en el otro (origen o cliente). Si la clase una clase cambia su interfaz, la clase cliente no funcionar.

Palabras clave de dependencia: <<call>>: El cliente llama a una operacin del suministrador. Se puede decir que el <<create>>: El cliente crea una instancia del suministrador. <<use>>: El cliente necesita al suministrador para su implementacin.

3.1.3. NOTAS Y COMENTARIOS

3.2. CASOS DE USO

http://www.infor.uva.es/~mlaguna/is1/materiales/BookDraft1.pdf http://geeks.ms/blogs/rcorral/archive/2006/06/18/497.aspx Un caso de uso es un contrato que refleja las responsabilidades del sistema para lograr un objetivo. Un caso de uso refleja posibles interacciones o escenarios en forma de acciones o sub-objetivos para lograr el fin principal. El escenario primario es el escenario ms tpico o frecuente en el cual se logra el objetivo (pe, Retirar dinero). El resto de escenarios se recogen como extensiones, donde se puede conseguir el objetivo principal o no (pe, Pin incorrecto). Por ejemplo, para poder llegar al objetivo principal Retirar dinero se necesitarn realizar una serie de acciones o sub-objetivos como introducir pin, teclear cantidad, etc. Slo se detallarn aquellos casos de uso que requieran ms profundidad de detalle o que no hayan quedado claros con la descripcin breve que se debe de hacer de ellos. Los casos de uso tipo CRUD, no se detallarn. Si alguna accin dentro del CRUD, como por ejemplo Dar de alta requiere ms detalle o es una actividad crtica dentro del sistema, se sacar como un caso de uso independiente. Referencia de la notacin: http://uml.kirfa.com/use-case-reference.html.

3.2.1. DESCRIPCIN DETALLADA DE UN CASO DE USO:

1. 2. Nombre del caso de uso: Objetivo principal que busca un usuario. Identificar actores: a. Primario: El que da nombre al caso de uso. b. Secundario: Cualquier otro que ayude a lograr el objetivo. Precondiciones: Condiciones que debe cumplir el sistema para lograrlo (el usuario se ha validado). No se comprueban en el caso de uso porque se han tenido que cumplir previamente. Pueden coincidir con algn caso de uso ya existente (usuario validado), algn caso de uso que se ha reutilizado con <<include>> (se ha seleccionado una cita) o un estado general del sistema (el sistema debe estar parado).

3.

En el caso de la Fig. 11, la precondicin de Visualizar Estado Expediente no ser ninguno de los dos casos de uso, sino el tener algn expediente abierto. Como conclusin de este apartado, se puede seguir el siguiente consejo para diferenciar entre una precondicin y la primera accin del escenario, ya que existe gran confusin en este sentido. Se puede analizar el caso de uso como una sucesin de acciones en el tiempo. Por ejemplo, en un sistema operativo, ser una precondicin validarse en el sistema para ejecutar una aplicacin. Para escribir un comentario en un peridico, la identificacin del usuario ser la primera accin, ya que se puede entender que forma parte del conjunto de la accin. 4. 5. Trigger: Evento que inici el caso de uso. Generalmente ser iniciado por el usuario. En ocasiones podr ser un instante de tiempo (8:00 am), un estado (temperatura > 29), etc. Escenario Primario: Expresado en frases activas en tiempo presente. Suelen ser frases del tipo: a. Interaccin entre usuario y sistema. El usuario introduce sus datos personales. El usuario selecciona un expediente cargado (RN01). El sistema muestra los asientos disponibles. b. Una validacin. El sistema comprueba la validez del NIF. El sistema comprueba que el expediente no est facturado. El sistema comprueba los asientos disponibles. Ojo con estos sub-objetivos ya que se solapan muchas veces con la propia interaccin del usuario y el sistema. El ltimo del punto a) es mucho ms descriptivo que no el ltimo del b) para posteriormente indicar que se listan. c. Un cambio de estado lgico del sistema. El sistema registra el nuevo expediente. El libro pasa estar prestado (RN02). El sistema pasa a estar off-line.

Las acciones descritas en el escenario deben cumplir con las siguientes propiedades: Deben tener siempre una perspectiva externa (no describir que hace exactamente el sistema) Indiciar la verdadera intencin del actor (no describir lo pasos que da, sino el sub-objetivo) No hacer referencia a la UI. Mejorar la legibilidad con descripcin de datos y reglas de negocio.

Ejemplo: 1. El usuario selecciona una pelcula. 2. El usuario selecciona una fecha y hora. 3. El usuario selecciona los asientos deseados. 4. El sistema comprueba disponibilidad. 5. El sistema confirma la reserva. Extensiones: Describen escenarios alternativos al escenario principal que pueden suceder en el intento de consecucin del objetivo que define el caso de uso. Estas extensiones o escenarios secundarios se activan por una respuesta generada por el sistema. En el caso de uso Retirar efectivo una extensin podr ser El usuario no posee saldo. Las extensiones deben nume rarse a partir de la accin que genera la derivacin del flujo del escenario primario y se debe utilizar una notacin idntica a la utilizada en el escenario primario. Ejemplo: 5a. El sistema informa de la no disponibilidad para esos criterios de bsqueda. 7. Descripcin de los Datos: Se describen aquellos datos no triviales, asignndolos un alias. Ejemplo: Datos Personales: Nombre + DNI + Telfono. Fuera del caso de uso y general para todos, se indicarn otros requerimientos y las Reglas de Negocio. Reglas de Negocio: RN01: Un expediente se dice que est cargado cuando se ha finalizado. RN02: El libro est prestado cuando lo tiene en posesin algn usuario. RN03: Las valoraciones deben estar entre 0 y 6.

6.

3.2.2. RELACIONES ENTRE CASOS DE USO

Los casos de uso permiten evitar duplicidades de funcionalidad o alternar el flujo entre ellos mediante el uso de varios tipos de relaciones:

<<INCLUDE>>
La relacin de tipo <<include>> se aplica a un caso de uso cuando existe una funcionalidad o tareas que pueden ser reutilizadas por varios casos de uso. El caso de uso referenciado siempre se llevar a cabo de forma secuencial.

[Usuario]-(Crear Expediente) [Usuario]-(Modificar Expediente) (Crear Expediente)>(Visualizar Expediente) (Modificar Expediente)>(Visualizar Expediente)
http://yuml.me/diagram/scruffy/usecase/draw

Muchas ocasiones este hecho no resulta tan fcil de ver, ya que el propio nombre del caso de uso no se puede ver la inclusin. En estos casos debemos analizar las acciones o sub-objetivos del caso de uso, como se muestra a continuacin mediante un ejemplo. Caso de Uso A 1. 2. 3. 4. 5. Subobjetivo1 Subobjetivo2 Subobjetivo3 Subobjetivo9 Subobjetivo10 Caso de Uso B 1. 2. 3. 4. 5. Subobjetivo4 Subobjetivo5 Subobjetivo6 Subobjetivo9 Subobjetivo10

Se podra decir que estamos ante dos casos de uso que reutilizan un comportamiento: Caso de Uso A 1. 2. 3. 4. Subobjetivo1 Subobjetivo2 Subobjetivo3 (include de X) Caso de Uso B 1. 2. 3. 4. Subobjetivo4 Subobjetivo5 Subobjetivo6 (include de X) Caso de Uso X 1. 2. Subobjetivo9 Subobjetivo10

Donde A puede ser Alquilar Material, B Renovar Alquiler Material y X Generar Factura.
[Usuario]-(A) [Usuario]-(B) (A)>(X) (B)>(X)
http://yuml.me/diagram/scruffy/usecase/draw

<<EXTENDS>>
Se aplica la relacin de tipo <<extends>> cuando un caso de uso puede tener varias alternativas o tipos de comportamientos especficos en su objetivo final. No hay que confundir esta relacin con las extensiones de los escenarios primarios. La diferencia fundamental est en que las extensiones no son un objetivo en s y no son un tipo de accin particular del caso de uso en el que se definen. La ltima accin o sub-objetivo del caso de uso principal ser un punto de extensin hacia alguno de los casos de uso que realicen <<extends>> sobre l.

[Usuario]-(Realizar Pago) (Realizar Pago)<(Tarjeta de Crdito) (Realizar Pago)<(Transferencia)

http://yuml.me/diagram/scruffy/usecase/draw

Analizando las descripciones detalladas de los casos de uso A y B, se llegara a una relacin <<extends>> de la siguiente forma: Caso de Uso A 1. 2. 3. 4. 5. Subobjetivo1 Subobjetivo2 Subobjetivo3 Subobjetivo4 Subobjetivo5 Caso de Uso B 1. 2. 3. 4. 5. Subobjetivo1 Subobjetivo2 Subobjetivo3 Subobjetivo7 Subobjetivo8

Se podra decir que estamos ante el mismo caso de uso con dos especializaciones: Caso de Uso X: Pto de Extensin 3. 1. 2. 3. Subobjetivo1 Subobjetivo2 Subobjetivo3 Caso de Uso A 1. 2. Subobjetivo4 Subobjetivo5 Caso de Uso B 1. 2. Subobjetivo7 Subobjetivo8

Donde X puede ser Realizar la matrcula, A Con beca del ministerio y B Beca convencional.
[Usuario]-(X) (X)<(A) (X)<(B)
http://yuml.me/diagram/scruffy/usecase/draw

HERENCIA
Se produce una relacin de herencia entre dos casos de uso cuando semnticamente se produce una relacin del tipo es un, como ocurre en la herencia tpica de programacin. En este caso, lo importante es el significado del caso sin importarnos las acciones que se lleven a cabo, que pueden ser completamente distintas. El smil con la programacin sera hablar de la redefinicin de mtodos sin reutilizar el cdigo de la clase padre. En una relacin del tipo <<extends>> se llevan a cabo ambos casos de uso, mientras que cuando se produce herencia slo se ejecuta uno de los dos, por lo que se habla del caso heredado como un caso de uso independiente.

Figura 20. Ejemplo de <<extends>>. Siempre se ejecutarn los dos.

Figura 21. Herencia entre casos de uso. Se ejecuta uno u otro.

Tambin se puede producir herencia entre actores. En estos casos el actor heredado podr realizar sus casos de uso y los asociados al actor padre.