Refinando el Ana lisis

–Como primer paso de la etapa de diseño, se debe refinar los diagramas desarrollados durante el análisis.
* Diagrama Casos de Uso
* Diagrama de Clases

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 diseño, los escenarios (primario y secundario) serán 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 métodos en cada una de las clases de tal forma que correspondan a las características
propias de las mismas.
En la etapa de diseño, estos métodos deben ser complementados con los métodos que responden a eventos
internos del sistema.
De tal forma que se valide que los métodos obtenidos sirvan para atender todos los eventos que el objeto
reciba de otros objetos.

Diagrama de Secuencias del Sistema

– Una vez definidas las clases con las que el sistema soportara sus procesos es necesario identificar los
eventos y las operaciones con las que el sistema interactuara con los actores.
– Para mostrar gráficamente 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 aplicación software como una caja negra,
describiéndose lo que hace esta sin importar como lo haga.
– Para su elaboración se utiliza como información 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 Use Case.

– 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 lınea que representa la secuencia de eventos
en el tiempo que el sistema recibe.
* Identificar los actores que operan directamente el sistema, trazando también una lınea 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 lınea de secuencia del
actor que lo realiza y su destino es la lınea de secuencia del sistema.
* El comportamiento del sistema es mostrado como flechas (reflexivas) que nacen de la lınea de secuencias
del sistema hacia a si misma.

* Para nombrar cada evento, es conveniente que muestren el propósito del mismo y no el medio físico de
entrada o interfaz del sistema que usan. Adema s, se recomienda para incrementar la claridad del mismo usar
verbos.
* La respuesta del sistema a la acción invocada por el actor puede ser representada como una flecha con
líneas punteadas, que nace de la
Lınea de secuencia del sistema y su destino es la lınea de secuencia del actor que invoco el proceso.
* Es posible utilizar comentarios los cuales pueden ser colocados a la izquierda del diagrama. Estos
comentarios pueden ser recogidos de
la misma especificación del caso de uso.
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 acción que especifica un proceso o función.
– Es una herramienta muy útil para modelar los procesos del negocio y los flujos de datos de los mismos,
permitiendo trabajarlos como una colección de actividades y transiciones entre estas actividades.
– Además permiten compartir fácilmente la información de los procesos con clientes y otros usuarios no
familiarizados en las
técnicas de Ingeniería de Software.

– Este diagrama, trabaja con los aspectos dinámicos de un sistema, al detallar el comportamiento del mismo.
– Es importante que estos diagramas contengan, para comunicar su contenido, la mínima información
necesaria (evitar volverlos
muy complejos.)
– Los diagramas de actividades están relacionados con los casos de uso así como con las clases identificadas.
– También pueden ser usados para modelar procesos de negocio así como flujos de trabajo.

– Los diagramas de actividades adema s pueden describir:

* Puntos de decisión (Condiciones que cambian el flujo de las acciones)
* Caminos paralelos de ejecución.
* Objetos afectados por las acciones.
* Señales con envió y recepción explıcita de mensajes.

– Tienen básicamente dos objetivos claramente definidos:

* Ayudar a describir el proceso del negocio permitiendo descubrir actividades paralelas. (Principalmente en la
etapa de análisis)
* Modelar con un mayor detalle las especificaciones de un método o el escenario de un caso de uso.
(Principalmente en la etapa de diseño.)

– Acción (Action State)

* Es un estado dentro de un proceso cuyo propósito es ejecutar una operación puntual.
* Es el mínimo bloque de construcción de los diagramas de actividades.
* El proceso asociado a la acción es indicado con una expresión, la cual se recomienda sea un pseudo-código 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 características:
– Son atómicas, no pueden ser descompuestas en piezas mas pequeñas.
– Son no interrumpibles, una vez empezadas, siempre progresan hasta finalizarse.
– Son instantáneas, el tiempo requerido por el proceso para ejecutarse es generalmente considerado
insignificante.

* En UML, las acciones son representados como cajas con las esquinas redondeadas.
– Actividad (Activity State)
* Es un estado destinado a ejecutar una operacion compleja.
* Las actividades tienen las siguientes caracterısticas:
– Pueden ser descompuestas en otras actividades o acciones.
– Pueden ser interrumpidas.
– Su ejecucion puede tomar una cantidad finita de tiempo.

* Son usadas principalmente para modelar los pasos de un algoritmo o procedimiento.

* Tambien 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 ma s simples o
en simples acciones.
* Una actividad, puede a su vez referenciar a otro diagrama de actividades.
* En UML, las actividades tambien 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.

– 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 también es necesario indicar los estados de inicio y de fin del proceso que se
detalla.

Notacion:

– Transicion:
* Cuando una accion o actividad termina su trabajo, hay un paso del estado actual al siguiente estado. Este
paso es conocido como transicion.
* Una transicion ocurre automaticamente 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 (accio n o actividad) inicial
puede pasar uno final cuando el mismo termina y si se cumple alguna determinada condicion.
- Es posible detallar en una transicion una condicion que debe ser necesaria para que pueda ocurrir el cambio
del estado inicial al estado final.
* En UML, la transicion se representa como una flecha que nace en la accion o actividad inicial, apuntando a la
accion o actividad siguiente. De existir una condicion, esta se muestra sobre la lınea entre corchetes.

Notacion:
Ejemplos de Transiciones:

– Decisiones (Decisions)
*Los procesos a lo largo de su flujo, en ocasiones requieren especificar caminos alternos, los cuales pueden
ser tomados en funcion 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 fluira el proceso, se definen expresiones booleanas(guard
expressions) las cuales en funcion de si
son verdaderas o no ejecutan un camino alterno o no respectivamente.

la finalidad que el diagrama

* En las decisiones es detallado un unico 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 sea siempre determinıstico.

* En UML, las decisiones son denotadas utilizando un sımbolo en forma de diamante, de donde salen los
caminos alternativos.
* Las expresiones son denotadas encerrandolas entre corchetes.
Notacion:

Ejemplos de Caminos Alternos:

– Divisiones (Forks) y Uniones (Joins)

* Los diagrama de actividades son herramientas muy utiles para modelar flujos concurrentes (flujos que se
ejecutan en forma
paralela sin que ello implique una condicion). En ellos es posible dividir el flujo del proceso en dos o mas
caminos concurrentes.
* Las divisiones tienen exactamente una transicion de entrada y dos o mas transiciones de salida, mientras
que las uniones tienen dos o mas transacciones de entrada y una unica transicion de salida que es disparada
cuando todos los caminos de entrada han sido terminados de ejecutar.
* En UML, las divisiones y sus posteriores uniones de los diagramas deactividades son representadas con
barras de sincronizacion.

Notacion:

Ejemplo de Divisiones y Uniones

– Particion (Swimlane)
* Cuando se modelan procesos de negocio, es util separar las actividades en grupos (usualmente cada grupo
representa las unidades de negocio o a reas de la empresa responsable de dichas actividades).
* Cuando se utilizan particiones, cada una debe tener un nombre unico dentro del diagrama y si bien la
particion no tiene ningun vınculo con otro diagrama dentro de UML, debe tener alguna relacion 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.

Notacion:

Ejemplo:
– 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 participacio n 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
u nicamente se deben detallar los objetos importantes para el modelo.

é 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 utilizara en el
diagrama de estados del mismo objeto.
Notacio n:

Ejemplo:

– Relacio n con otros diagramas de UML

é 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 me todo que
realice la accio n o actividad que lo referencia.
é Con el diagrama Casos de Uso:
–Cada una de las acciones y actividades detalladas en la especificacio n
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.

Caso: Sistema Car Rental

– Car Rental desea automatizar su actual sistema manual de reservacio n de autos, los cuales operan en varias localidades en el Peru .
– El sistema debera permitir que cualquier Cliente este en la posibilidad de hacer bu squedas de autos en los diferentes locales y reservarlos en caso lo desee (a
traves de Internet). Una vez reservado un auto, el cliente debera recogerlo del local de origen especificado, solicita ndoselo a algu n operario de la oficina, y
podra entregarlo en cualquier otro local de la empresa. (En caso esto ocurra este auto debera ser regresado al local de origen del mismo por algu n operario).
– Los carros son ofrecidos segu n sus tipos (sedan, camioneta, limosina, etc.) y los clientes pueden escoger entre algunas facilidades como aire acondicionado,
cambios automa ticos, 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).

– Las tarifas de alquiler esta n 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 podrıan tener precios distintos). El responsable de hacer la actualizacio n 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 vehıculos y a la reserva
de los mismo.
– Para los casos de uso identificados del caso anterior definir lo s
diagramas de secuencias del sistema y los diagramas de actividad es.

Diagrama de Estados
Evento:
Es un acontecimiento importante o digno de senalar que le acontece a un objeto.
En el caso de un tele fono un evento es ”Levantar Auricular„.
Estado:
* Es la condicio n o situacio n de un objeto en un momento
determinado (el tiempo que transcurre entre eventos).
ñ En el caso de un tele fono, e ste se encuentra en estado ”Ocioso„una
vez que el auricular es puesto en su sitio y mientras e ste no es
levantado.

ñ El estado de un objeto es definido por:

– El valor de uno de sus atributos.
– La relacio n con otro objeto.
– Una actividad en ejecucio n por el objeto.
ñ Todo objeto se caracteriza por:
– Tener un estado actual.
– Tener un estado inicial cuando este es creado.
– Puede cambiar sus estados a trave s de eventos.
– Pueden asociarse acciones o actividades a ejecutarse cuando se
produzca un cambio de estado determinado.
– Tiene un estado final antes de ser destruido.

Transicio n:
ñ Es la especificacio n de co mo los estados esta n relacionados.
ñ La transicio n se produce cuando ocurre un evento, en el momento
en que un objeto pasa de un estado inicial a un siguiente estado.
ñ Un objeto en un estado ejecutara una accio n y posiblemente pasara
a otro estado cuando un evento ocurre y una condicio n sea
satisfecha. Este hecho es conocido como transicio n.
ñ En el ejemplo del tele fono, cuando ocurre el evento ”Levantar
Auricular„, el tele fono realiza la transicio n de ”Ocioso„a ”Activo„.

Diagrama de Estados
– Los diagramas de Estado describen gra ficamente los eventos y
los estados de los objetos.
– En ellos se indican los eventos del sistema indicados en los
casos de uso y detallados en la etapa de analisis.
– Permiten modelar el ciclo de vida dinamico de un objeto,
donde cada objeto es tratado como un entidad aislada que se
comunica con el exterior detectando eventos y respondiendo a
ellos.
– Es representado a trave s de grafos que indican las respuestas de
un objeto, de una clase dada, a un evento externo.

– Para cada clase existe un diagrama de estados, que

modela todas las transiciones como respuesta de algu n
evento entre los estados de la misma.
– Dado que los objetos de una clase pueden participar en
varios casos de uso, se define que un diagrama de estados
modela el comportamiento de los objetos a traves de
todos los casos de uso en los que e ste participe.

Notacio n:
ñ Las Transiciones
– Son modeladas con flechas.
ñ Los Eventos
– Son escritos sobre las transiciones de las que son
disparadores.
ñ Los Estados
– Se muestran en rectangulos redondeados con el
nombre del estado dentro del mismo.

– Similar al diagrama de actividades se incluye un seudo

estado inicial que cumple automa ticamente con la
transicio n a otro estado en el momento de crearse la
instancia de la clase modelada y un seudo estado final
(so lo en el caso el objeto sea eliminado).
– Estos seudo estados se representan con un punto y con
un punto encerrado en un cırculo respectivamente.

Ejemplos:

– Condiciones de cambio de estado: (Guards)

ñ En ocasiones para que un objeto realice una transicio n de un
estado a otro es necesario que se cumpla con una determinada
condicio n (Guard).
ñ En los diagramas de estado las condiciones se representan como
una expresio n que puede ser verdadera o falsa entre un par de
corchetes ”[ ]„.

– Objetos Independientes y Dependientes del Estado respecto

a un Evento.
ñ Si un objeto reacciona igual ante un evento, se le considera
independiente del estado respecto a dicho evento.
– Por ejemplo, si un objeto recibe un mensaje y su metodo de respuesta
siempre hace lo mismo, el metodo no tendra una lo gica condicional,
entonces el objeto es independiente del estado respecto a ese mensaje o
evento.
ñ Si un objeto reacciona de forma distintas a un evento en funcio n al
estado actual del mismo, se le considera dependiente del estado
respecto a dicho evento.
– Por ejemplo, si un objeto recibe un mensaje y su metodo de respuesta hace
distintas acciones en funcio n del estado en que se encuentre, entonces el
objeto es dependiente del estado respecto a ese mensaje o evento.

– čCuando se requiere un Diagrama de Estados?

ñ Como se ha indicado, es posible desarrollar un diagrama de
estados para cualquier clase.
ñ Pero por lo general es conveniente preparar diagramas de estados
para clases:
– Clases dependientes del estado respecto a algu n evento.
– Clases de comportamiento relativamente complejo (tres o mas
estados).

– Otras aplicaciones de los Diagramas de Estado

ñ Tambien es posible aplicar los diagramas de estados para modelar
el comportamiento de los siguientes elementos:
– Ventanas. Por ejemplo la accio n de editar y pegar es so lo va lida
cuando hay algo guardado en el portapapeles.
– Controladores. Son clases especiales que no administran
aplicaciones ni ventanas y que se encargan de manejar los eventos
del sistema.
– Casos de Uso. La reaccio n del caso de uso ante la interaccio n de un
actor puede depender de los pasos previos que haya realizado.
– Sistemas y/o Subsistemas. La interaccio n entre los distintos
componentes de un sistema puede ser representada utilizando
diagrama de estados.

– Transacciones. La forma como una transaccio n reacciona ante un evento

a menudo depende de su estado actual a lo largo de todo su ciclo de vida.
(Por ejemplo si una venta recibe el mensaje de CrearLıneaVenta despue s
del evento TerminarVenta, deberıa presentar un condicio n de error o ser
omitida).
– Dispositivos. Por ejemplo un televisor, una lampara, un mo dem
reaccionan de forma distinta ante un evento particular segu n su estado
actual.
– Mutadores. Objetos que cambian su rol o papel. Por ejemplo una persona
que cambia de Civil a Militar.

Tipos de Eventos
Evento Externo:
ñ Llamado tambien evento del sistema.
ñ Se debe a algu n factor (un actor por ejemplo) situado fuera de la frontera
del sistema.
ñ Por ejemplo cuando un cajero oprime el boto n ”Introducir Producto„ en
una caja registradora, significa que ha ocurrido un evento externo.
Evento Interno:
ñ Se debe a un factor interno del sistema.
ñ Un evento interno tiene lugar cuando se invoca a una operacio n a trave s
de un mensaje o senal que partio de otro objeto.
ñ Por ejemplo cuando una venta recibe un mensaje ”Hacer Lınea de
Producto„significa que ha ocurrido un evento interno.

Evento Temporal:
ñ Se debe a la ocurrencia de una fecha u hora especıficas o bien al transcurso
del tiempo.
ñ Un reloj de tiempo real o de tiempo simulado son los que conducen este tipo
de eventos.
ñ Por ejemplo suponga que una vez realizada una operacio n ”Terminar Venta„
debe realizarse una operacio n ”Efectuar Pago„ en un plazo de cinco minutos
pues de lo contrario se depurara automa ticamente la venta actual.

Estados Anidados
– En un Diagrama de Estados un estado puede contener subestados.
– Un subestado hereda las transiciones de su superestado (El estado
incluyente).
– Los subestados pueden describirse gra ficamente anidandolos en una
casilla o rectangulo que representa al superestado.

Ejemplo:

Caso Asiento
– Toda empresa requiere llevar la contabilidad de los distintos procesos y/o transacciones que en ella se realizan.
– Para llevar este trabajo se utiliza de un documento llamado asiento el cual puede ser generado por distintas a reas de la empresa. Este
documento siempre debe registrarse de tal forma que los valores que en e l se detallan esten cuadrados, en cuyo caso el asiento es va lido. En
caso los valores detallados en el asiento no cuadren el asiento tendra el estado de inva lido.
– Una vez que el asiento ha sido registrado pasa por una revisio n para verificar que los valores en e l detallados sean los correctos. Si el
asiento esta correcto este pasa a un estado Aprobado, en caso contrario pasa a estado ”Por Revisar„ para que sea revisado posteriormente y
corregido.
– Una vez corregido el asiento e ste regresa al estado Valido o Inva lido dependiendo si cuadra o no el documento.
– Despue s de la revisio n de los asientos se ejecuta el proceso de mayorizacio n, el cual cambia el estado del documento a Mayorizado.
– Se debe considerar que en cualquier momento el asiento puede ser eliminado a excepcio n de cuando e ste esta en estado Mayorizado.
Desarrollar el diagrama de estados del caso anterior.

Caso Transferencia
– En una empresa distribuidora con almacenes en distintas ciudades se quiere implementar un sistema para las transferencias de artıculos entre las
distintas sucursales de la companıa.
– El proceso empieza cuando un asistente de compras define la necesidad de realizar una transferencia de uno o varios productos de una sucursal a otra.
Esta necesidad es revisada por el jefe de compras el cual la aprueba o desaprueba.
– Una vez aprobada la transferencia es enviada a la sucursal de origen donde se evalu a la disponibilidad de la mercaderıa. En caso hubiera suficiente
existencia se realiza la transferencia, en caso contrario se realiza por una cantidad menor a la especificada (en ningu n caso la transferencia se
realizara por una cantidad mayor a la indicada por compras).
– Cuando la transferencia es enviada en su totalidad debera pasar al estado Enviada y si so lo se envıa parcialmente se debera pasar al estado
Parcialmente Enviado.

– En caso no existiera ningu n artıculo a transferir por problemas de stock se procederıa a cancelar la transferencia.
– La transferencia puede realizarse en varios envıos (en varios camiones), pudiendo llegar estos en distintos tiempos. Obligando a que se puedan
registrar estos tambien en tiempos distintos. Cuando la transferencia ha llegado a destino parcialmente, esta se encontrara en estado Backorder y si
ha llegado completamente, e sta pasara al estado Recibida.
– En los casos en que la mercaderıa fue enviada pero por algu n motivo esta no llego a la sucursal de destino la transferencia debera ser Cerrada y el
stock
asociado a la misma debera regresar a la bodega de origen.
Desarrollar el diagrama de estado del caso anterior.