Refinando el Anlisis

Como primer paso de la etapa de diseo, se debe refinar los diagramas desarrollados durante el anlisis.

Del Anlisis al Diseo

Refinando el Anlisis. Diagrama de Secuencia del Sistema. Diagrama de Actividades.

Diagrama Casos de Uso Diagrama de Clases

Diapositiva 1

Diapositiva 2

Refinando el Diagrama Casos de Uso

El diagrama de Casos de Uso debe presentar solamente la funcionalidad que va a ser implementada en el sistema. No se deben incluir procedimientos externos al sistema o que no se van a implementar. Como parte de la etapa de diseo, los escenarios (primario y secundario) sern modelados utilizando los diagramas de secuencia del sistema y los diagramas de actividades.

Refinando el Diagrama de Clases

El diagrama de clases debe presentar solo las clases que van a ser implementadas como parte del sistema, a menos que dichas clases contribuyen a hacer mas claro el modelo. Se identificaran los mtodos en cada una de las clases de tal forma que correspondan a las caractersticas propias de las mismas. En la etapa de diseo, estos mtodos deben ser complementados con los mtodos que responden a eventos internos del sistema. Se debe validar que los mtodos obtenidos sirvan para atender todos los eventos que el objeto reciba de otros objetos.

Diapositiva 3

Diapositiva 4

Diagrama de Secuencias del Sistema

Una vez definidas las clases con las que el sistema soportar sus procesos es necesario identificar los eventos y las operaciones con las que el sistema interactuar con los actores. Para mostrar grficamente estos eventos, que fluyen de los actores al sistema, UML define los Diagramas de Secuencia del Sistema. Los diagramas de secuencias del sistema toman a la aplicacin software como una caja negra, describindose lo que hace esta sin importar como lo haga. Para su elaboracin se utiliza como informacin inicial, las especificaciones de los casos de uso, aislando las operaciones que el actor solicita al sistema, permitiendo detallar en un determinado escenario de un caso de uso los eventos generados por los actores, su orden as como los eventos internos del sistema. En este diagrama, el tiempo se muestra avanzando hacia abajo y el ordenamiento de los eventos debe seguir el indicado en el Caso de Uso.
Diapositiva 5

Diagrama de Secuencias del Sistema (2)

Para elaborar el diagrama de secuencia del sistema se debe seguir con los siguientes pasos:
Identificar el sistema como una caja negra, de la cual nace una lnea que representa la secuencia de eventos en el tiempo que el sistema recibe. Identificar los actores que operan directamente el sistema, trazando tambin una lnea que representa la secuencia de eventos que estos ejecutan. A partir del flujo de eventos del caso de uso, identificar los eventos generados por los actores para el sistema. Cada evento entre los actores y el sistema es mostrado con flechas cuyo origen es la lnea de secuencia del actor que lo realiza y su destino es la lnea de secuencia del sistema. El comportamiento del sistema es mostrado como flechas (reflexivas) que nacen de la lnea de secuencias del sistema hacia a si misma.

Diapositiva 6

Diagrama de Secuencias del Sistema (3)

Para nombrar cada evento, es conveniente que muestren el propsito del mismo y no el medio fsico de entrada o interfaz del sistema que usan. Adems, se recomienda para incrementar la claridad del mismo usar verbos. La respuesta del sistema a la accin invocada por el actor puede ser representada como una flecha con lneas punteadas, que nace de la lnea de secuencia del sistema y su destino es la lnea de secuencia del actor que invoc el proceso. Es posible utilizar comentarios los cuales pueden ser colocados a la izquierda del diagrama. Estos comentarios pueden ser recogidos de la misma especificacin del caso de uso.

Diagrama de Secuencias del Sistema (4)

Ejemplo:
El Sistema se maneja como una caja negra.

Actor Zona de Observaciones. Texto que aclara el control de la lgica, iteraciones, etc.

:Sistema
evento1(par11, par12, ... ) accion1(par21, par22, ... ) valor de retorno evento2(par31, par32, ... )

...

Diapositiva 7

Diapositiva 8

Diagrama de Actividades
Los diagramas de actividades han sido usados en varias formas, con diferentes nombres y en distintas notaciones. En UML, los diagramas de actividades son definidos como una variante de los diagramas de estado, donde cada estado se ha convertido en una accin que especifica un proceso o funcin. Es una herramienta muy til para modelar los procesos del negocio y los flujos de datos de los mismos, permitiendo trabajarlos como una coleccin de actividades y transiciones entre estas actividades. Adems permiten compartir fcilmente la informacin de los procesos con clientes y otros usuarios no familiarizados en las tcnicas de Ingeniera de Software.
Diapositiva 9

Diagrama de Actividades (2)

Este diagrama, trabaja con los aspectos dinmicos de un sistema, al detallar el comportamiento del mismo. Es importante que estos diagramas contengan, para comunicar su contenido, la mnima informacin necesaria (evitar volverlos muy complejos.) Los diagramas de actividades estn relacionados con los casos de uso as como con las clases identificadas. Tambin pueden ser usados para modelar procesos de negocio as como flujos de trabajo.

Diapositiva 10

Diagrama de Actividades (3)

Los diagramas de actividades adems pueden describir:
Puntos de decisin (Condiciones que cambian el flujo de las acciones) Caminos paralelos de ejecucin. Objetos afectados por las acciones. Seales con envo y recepcin explcita de mensajes.

Diagrama de Actividades (4)

Accin (Action State)
Es un estado dentro de un proceso cuyo propsito es ejecutar una operacin puntual. Es el mnimo bloque de construccin de los diagramas de actividades. El proceso asociado a la accin es indicado con una expresin, la cual se recomienda sea un pseudo-cdigo o una frase verbal. Se debe considerar que este proceso es ejecutado en el momento en que el estado es accesado. Las acciones tienen las siguientes caractersticas:
Son atmicas, no pueden ser descompuestas en piezas ms pequeas. Son no interrumpibles, una vez empezadas, siempre progresan hasta finalizarse. Son instantaneas, el tiempo requerido por el proceso para ejecutarse es generalmente considerado insignificante.

Tienen bsicamente dos objetivos claramente definidos:

Ayudar a describir el proceso del negocio permitiendo descubrir actividades paralelas. (Principalmente en la etapa de anlisis) Modelar con un mayor detalle las especificaciones de un mtodo o el escenario de un caso de uso. (Principalmente en la etapa de diseo.)

Diapositiva 11

Diapositiva 12

Diagrama de Actividades (5)

En UML, las acciones son representados como cajas con las esquinas redondeadas.

Diagrama de Actividades (6)

Actividad (Activity State)
Es un estado destinado a ejecutar una operacin compleja. Las actividades tienen las siguientes caractersticas:
Pueden ser descompuestas en otras actividades o acciones. Pueden ser interrumpidas. Su ejecucin puede tomar una cantidad finita de tiempo.

Notacin:
<Expresin>

Ejemplos:

Ingresar Nombre A:=B+C Enviar Mensaje

Acciones

Son usadas principalmente para modelar los pasos de un algoritmo o procedimiento. Tambin pueden ser utilizadas para modelar complejos procesos de negocios, donde cada elemento del mismo puede ser modelado como una actividad que pueda ser desmenuzada en actividades ms simples o en simples acciones. Una actividad, puede a su vez referenciar a otro diagrama de actividades.

Diapositiva 13

Diapositiva 14

Diagrama de Actividades (7)

En UML, las actividades tambin son representados como cajas con las esquinas redondeadas. En algunas notaciones, se utiliza un indicador especial en la esquina inferior derecha para distinguirlas de las acciones.

Diagrama de Actividades (8)

Estado Inicial y Estado Final en los diagramas de Actividades
Todo proceso o algoritmo tiene un inicio y un final. En un diagrama de actividades tambin es necesario indicar los estados de inicio y de fin del proceso que se detalla.

Notacin:
<Expresin>

Ejemplos:

Registrar Factura Procesar Orden Disear Producto

Notacin:
Actividades

Estado Inicial Estado Final

Diapositiva 15

Diapositiva 16

Diagrama de Actividades (9)

Transicin:
Cuando una accin o actividad termina su trabajo, hay un paso del estado actual al siguiente estado. Este paso es conocido como transicin. Una transicin ocurre automticamente cuando un estado ha finalizado su trabajo. Las transiciones representan las relaciones entre acciones y/o actividades indicando el posible camino por el cual puede transcurrir un proceso. Las transiciones indican que el flujo de eventos que se encuentra en un estado (accin o actividad) inicial puede pasar uno final cuando el mismo termina y si se cumple alguna determinada condicin. Es posible detallar en una transicin una condicin que debe ser necesaria para que pueda ocurrir el cambio del estado inicial al estado final.

Diagrama de Actividades (10)

En UML, la transicin se representa como una flecha que nace en la accin o actividad inicial, apuntando a la accin o actividad siguiente. De existir una condicin, esta se muestra sobre la lnea entre corchetes.

Notacin:
Estado 1 [Condicin] Estado 2

Diapositiva 17

Diapositiva 18

Diagrama de Actividades (11)

Ejemplos de Transiciones:
Registrar pedido Aprobar Pedido

Diagrama de Actividades (12)

Decisiones (Decisions)
Los procesos a lo largo de su flujo, en ocasiones requieren especificar caminos alternos, los cuales pueden ser tomados en funcin de ciertos valores. Los diagramas de actividades definen las decisiones para especificar y detallar tales caminos alternos de los procesos. Para controlar por cual camino alterno fluir el proceso, se definen expresiones booleanas (guard expressions) las cuales en funcin de si son verdaderas o no ejecutan un camino alterno o no respectivamente. En las decisiones es detallado un nico camino de ingreso as como varios caminos de salida, uno por cada camino alterno posible en el flujo del proceso. Es importante tener en cuenta que las expresiones booleanas deben ser formuladas cuidadosamente de tal forma que sean exclusivas entre ellas con la finalidad que el diagrama sea siempre determinstico.

Obtener Fecha de Vencimiento

[fecha > 3 meses] [fecha <= 3 meses]

Devolver mercadera Recibir mercadera

Diapositiva 19

Diapositiva 20

Diagrama de Actividades (13)

En UML, las decisiones son denotadas utilizando un smbolo en forma de diamante, de donde salen los caminos alternativos. Las expresiones son denotadas encerrndolas entre corchetes.

Diagrama de Actividades (14)

Ejemplos de Caminos Alternos:
Ingresar Password [password vlido] [password invlido] Activar Usuario Emitir mensaje de error

Notacin:
Actividad 1 [condicin] [condicin] Actividad 2 A:=X+Y Actividad 3

[A<0] [A=0] [A>0]

B:=C/A B:=C B:=A/C

Diapositiva 21

Diapositiva 22

Diagrama de Actividades (15)

Divisiones (Forks) y Uniones (Joins)
Los diagrama de actividades son herramientas muy tiles para modelar flujos concurrentes (flujos que se ejecutan en forma paralela sin que ello implique una condicin). En ellos es posible dividir el flujo del proceso en dos o ms caminos concurrentes. Las divisiones tienen exactamente una transicin de entrada y dos o ms transiciones de salida, mientras que las uniones tienen dos o ms transacciones de entrada y una nica transicin de salida que es disparada cuando todos los caminos de entrada han sido terminados de ejecutar.

Diagrama de Actividades (16)

En UML, las divisiones y sus posteriores uniones de los diagramas de actividades son representadas con barras de sincronizacin.

Notacin:
Actividad 1 Divisin (Fork) La Actividad 2 y Actividad 3 se realizan paralelamente. La Actividad 4 se ejecuta una vez terminada la Actividad 2 y la Actividad 3.

Actividad 2

Actividad 3

Unin (Join)

Actividad 4

Diapositiva 23

Diapositiva 24

Diagrama de Actividades (17)

Ejemplo de Divisiones y Uniones
Copiar Archivo:

Diagrama de Actividades (18)

Particin (Swimlane)
Cuando se modelan procesos de negocio, es til separar las actividades en grupos (usualmente cada grupo representa las unidades de negocio o reas de la empresa responsable de dichas actividades). Cuando se utilizan particiones, cada una debe tener un nombre nico dentro del diagrama y si bien la particin no tiene ningn vnculo con otro diagrama dentro de UML, debe tener alguna relacin con el mundo real. Los criterio para definir particiones suelen ser:
Unidades organizacionales en el modelo de negocios, Roles de trabajo, Casos de Uso, Clases o Componentes.

Calcular espacio libre del disco

Leer Archivo

Escribir Archivo

[Disco no lleno] [Disco Lleno]

Mostrar Estado

Diapositiva 25

Diapositiva 26

Diagrama de Actividades (19)

Notacin:
Area 1 Area 2 Area 3

Diagrama de Actividades (20)

Ejemplo:
Compras Registra Orden Compra Almacn

Actividad 1 Actividad 2 Actividad 4 Actividad 3

Aprobar Orden Compra

[orden aprobada]

Listar Artculos Ordenados

Imprimir Orden de Compra

[orden no aprobada]

Diapositiva 27

Diapositiva 28

Diagrama de Actividades (21)

Flujo de Objetos (Object Flow)
Las acciones o actividades pueden modificar los estados de los objetos del sistemas. El uso de relaciones de dependencia y objetos en los diagramas de actividades es llamado flujo de objetos (object flow) debido a que representa la participacin de un objeto dentro de un flujo de control. Los diagramas de actividades con flujo de objetos permiten modelar el efecto de un proceso sobre los estados de un objeto. Un diagrama de actividades puede detallar varios flujos de objetos, pero nicamente se deben detallar los objetos importantes para el modelo.

Diagrama de Actividades (22)

Los estados de los objetos se expresan dentro de cajas rectangulares con el nombre del objeto encima del estado del mismo entre corchetes ( [ ] ). El nombre dado a un estado debe corresponder al que se utilizar en el diagrama de estados del mismo objeto.

Notacin:
Actividad 1 Actividad 2 :Objeto [estado 1] :Objeto [estado 2] Estado del Objeto

Diapositiva 29

Diapositiva 30

Diagrama de Actividades (23)

Ejemplo:
Compras Registra Orden Compra
[orden no aprobada]

Diagrama de Actividades (24)

Relacin con otros diagramas de UML
Almacn

Con el diagrama de clases:

Todos los objetos presentados en el diagrama de actividades deben estar modelados en el diagrama de clases. Cuando se utiliza un diagrama de actividades para modelar el escenario de un caso de uso, las clases de los objetos presentados en el diagrama de actividades deben tener al menos un mtodo que realice la accin o actividad que lo referencia.

:OCompra [registrada]

Aprobar Orden Compra

:OCompra [Aprobada]

Listar Artculos Ordenados

[orden aprobada]

Con el diagrama Casos de Uso:

Imprimir Orden de Compra
[orden aprobada] :OCompra [Impresa] [orden no aprobada]

:OCompra [No Aprobada]

Cada una de las acciones y actividades detalladas en la especificacin de los casos de uso se convierte en una actividad del diagrama de actividades. Las actividades que no se ejecutan en forma concurrente deben pertenecer a casos de uso distintos.
Diapositiva 32

Diapositiva 31

Caso: Sistema Car Rental

Car Rental desea automatizar su actual sistema manual de reservacin de autos, los cuales operan en varias localidades en el Per. El sistema deber permitir que cualquier Cliente est en la posibilidad de hacer bsquedas de autos en los diferentes locales y reservarlos en caso lo desee (a travs de Internet). Una vez reservado un auto, el cliente deber recogerlo del local de origen especificado, solicitndoselo a algn operario de la oficina, y podr entregarlo en cualquier otro local de la empresa. (En caso esto ocurra este auto deber ser regresado al local de origen del mismo por algn operario). Los carros son ofrecidos segn sus tipos (sedan, camioneta, limosina, etc.) y los clientes pueden escoger entre algunas facilidades como aire acondicionado, cambios automticos, etc. Los autos son registrados y administrados en cada local de Car Rental. Es decir, cada local es responsable de asignar nuevos autos a su flota as como del mantenimiento y reparaciones de los mismos. (Se debe considerar que los autos pueden estar fuera de servicio mientras duren estos mantenimientos o reparaciones efectuados por el Departamento de Servicio).

Caso: Sistema Car Rental (2)

Las tarifas de alquiler estn definidas en base a los tipos de autos y son cargadas de forma diaria y/o semanal. Habiendo un algoritmo para alquileres por tiempos mayores y para los casos en que el local de origen sea distinto del local de entrega del auto. Cada local es libre de poner sus propias tarifas para cada tipo de auto. (Diferentes locales podran tener precios distintos). El responsable de hacer la actualizacin de las tarifas a cobrar es el Administrador del Local. Existe el requerimiento de tener acceso directo de los clientes por medio de Internet para tener acceso a la disponibilidad de vehculos y a la reserva de los mismo. Para los casos de uso identificados del caso anterior definir los diagramas de secuencias del sistema y los diagramas de actividades.

Diapositiva 33

Diapositiva 34