Refinando el Ana lisis

–Como primer paso de la etapa de diseño, se debe refinar los diagramas desarrollados durante el analisis.
* 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) seran 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 me todos en cada una de las clases de tal forma que correspondan a las caracterısticas propias de las
mismas.
– En la etapa de diseno, estos me todos deben ser complementados con los me todos que responden a eventos internos
del sistema.
– Se debe validar que los me 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 gra 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 aplicacio n software
como una caja negra, describiendose lo que hace esta sin importar como lo
haga.
– Para su elaboracio n se utiliza como informacio 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 Caso de Uso.

– 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
tambien 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

propo 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 accio 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 especificacio 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 accio n que especifica un proceso o funcio n.
– Es una herramienta muy u til para modelar los procesos del
negocio y los flujos de datos de los mismos, permitiendo
trabajarlos como una coleccio n de actividades y transiciones
entre estas actividades.
– Adema s permiten compartir fa cilmente la informacio n de los
procesos con clientes y otros usuarios no familiarizados en las
te cnicas de Ingenierıa de Software.

– Este diagrama, trabaja con los aspectos dina micos de un sistema,

al detallar el comportamiento del mismo.
– Es importante que estos diagramas contengan, para comunicar
su contenido, la mınima informacio n necesaria (evitar volverlos
muy complejos.)
– Los diagramas de actividades esta n relacionados con los casos
de uso asıcomo con las clases identificadas.
– Tambien pueden ser usados para modelar procesos de negocio
asıcomo flujos de trabajo.

– Los diagramas de actividades adema s pueden describir:

é Puntos de decisio n (Condiciones que cambian el flujo de las acciones)
é Caminos paralelos de ejecucio n.
é Objetos afectados por las acciones.
é Senales con envıo y recepcio n explıcita de mensajes.
– Tienen ba sicamente dos objetivos claramente definidos:
é Ayudar a describir el proceso del negocio permitiendo descubrir
actividades paralelas. (Principalmente en la etapa de ana lisis)
é Modelar con un mayor detalle las especificaciones de un metodo o el
escenario de un caso de uso. (Principalmente en la etapa de diseno.)

– Accio n (Action State)

é Es un estado dentro de un proceso cuyo propo sito es ejecutar una
operacio n puntual.
é Es el mınimo bloque de construccio n de los diagramas de actividades.
é El proceso asociado a la accio n es indicado con una expresio n, la cual se
recomienda sea un pseudo-co 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 ato micas, no pueden ser descompuestas en piezas ma s pequenas.
– Son no interrumpibles, una vez empezadas, siempre progresan hasta
finalizarse.
– Son instantaneas, 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 operacio n compleja.
é Las actividades tienen las siguientes caracterısticas:
– Pueden ser descompuestas en otras actividades o acciones.
– Pueden ser interrumpidas.
– Su ejecucio n 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 tambien es necesario indicar los estados de inicio y de fin del proceso que se detalla.

Notacion:

– Transicion:
é Cuando una accio n o actividad termina su trabajo, hay un paso del estado
actual al siguiente estado. Este paso es conocido como transicio n.
é Una transicio n ocurre automa ticamente 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 condicio n.
é Es posible detallar en una transicio n una condicio n que debe ser necesaria
para que pueda ocurrir el cambio del estado inicial al estado final.

é En UML, la transicio n se representa como una flecha que nace en

la accio n o actividad inicial, apuntando a la accio n o actividad siguiente.
é De existir una condicio n, 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 funcio n 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 funcio n de si
son verdaderas o no ejecutan un camino alterno o no respectivamente.
é En las decisiones es detallado un u 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 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 encerra ndolas entre corchetes.
Notacio n:

Ejemplos de Caminos Alternos:

– Divisiones (Forks) y Uniones (Joins)
é Los diagrama de actividades son herramientas muy u tiles para
modelar flujos concurrentes (flujos que se ejecutan en forma
paralela sin que ello implique una condicio n). En ellos es
posible dividir el flujo del proceso en dos o ma s caminos
concurrentes.
é Las divisiones tienen exactamente una transicio n de entrada y
dos o ma s transiciones de salida, mientras que las uniones
tienen dos o ma s transacciones de entrada y una u nica
transicio n 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 de

actividades son representadas con barras de sincronizacio n.
Notacio n:

Ejemplo de Divisiones y Uniones

– Particio n (Swimlane)
é Cuando se modelan procesos de negocio, es u til 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 u nico
dentro del diagrama y si bien la particio n no tiene ningu n vınculo con otro
diagrama dentro de UML, debe tener alguna relacio n 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.

Notacio n:
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.