Captulo 1: Modelado de Sistemas

Un modelo es una representacin abstracta y simplificada de un sistema real, con la cual

se puede explicar o probar su comportamiento como un todo o en partes. A modo general, los
modelos de SI representan:
Componentes: Elementos que componen un modelo
Propiedades de los componentes: Atributos o caractersticas que describen a los
componentes del sistema.
Relaciones entre los componentes
Caractersticas deseables de los modelos
Simplicidad: Se desea que un modelo sea simple, pero no simplista
Precisin: Los modelos no deben ser ambiguos
Rigurosidad: Se buscan modelos definidos formalmente
Documentacin: Los modelos deben facilitar la posibilidad de adjuntar documentacin.
Graficacin: Mediante la utilizacin de grafos. Se busca que los modelos sean expresivos.
Jerarquizacin: Capacidad de poder organizar un modelo en distintos niveles de detalle. La
jerarquizacin puede ser recursiva los componentes, entre distintos niveles, son siempre los
mismos o no recursiva.
Criterios de calidad de los modelos
Bsicos:
Completitud: Un modelo se dice completo si representa todos los elementos relevantes
del dominio del problema.
Correctitud: Un modelo se entiende correcto si no representa errores sintcticos ni
semnticos.
Temporalidad: Un modelo se dice con temporalidad si refleja adecuadamente la historia
antes de la situacin actual. Es un criterio opcional, ya que no siempre se requiere un
histrico. Generalmente se aplica a modelos estticos.
Avanzados:
Minimalidad: Los elementos de un sistema son representados una nica vez, es decir, no
existe redundancia en el modelo.
Expresividad: Los conceptos son representados sin requerir informacin adicional (auto-
explicativos).
Simplicidad: Es un concepto relativo, ya que depende de la comparacin con otra versin
del modelo del mismo sistema. Un modelo simple es aquel que logra representar lo mismo
con un menor nmero de elementos.
Muchas veces los criterios de expresividad y simplicidad son contrapuestos. No obstante,
en modelos ms complejos, la simplicidad adquiere un mayor nivel de importancia que la
expresividad.

1
Algunas propiedades
El costo de eliminar un componente incluido en el modelo, que despus termina siendo
externo, es siempre menor al costo de incluir un componente excluido del modelo, que
despus termina siendo interno. Esto permite concluir que ante la duda razonable de si un
elemento es parte o no del sistema, se recomienda siempre incluirlo en el modelo.
Un modelo conceptual describe el sistema en forma independiente de posibles
implementaciones. En otras palabras, define qu hace el sistema asumiendo que usar
recursos organizacionales ilimitados para su implementacin y TI perfectas.
Un buen modelador debe tratar de plantear un modelo lo ms general posible para
acomodar situaciones futuras con el mnimo impacto. La generalidad es mayor cuando se
opta por tener un componente en vez de una propiedad.
Ley de complejidad inevitable: Expresa que la complejidad del modelo de un sistema
no se puede evitar, sino apenas distribuir entre modelos complementarios.
Propiedades de sistemas y dimensiones de modelado
Un sistema posee tres propiedades generales:
1. Funcionalidad: Cules son las funciones que el sistema entrega al entorno?
2. Comunicacin: Cules son las interacciones entre las funciones y de stas con el entorno?
Se debe definir la organizacin espacialmente de las funciones.
3. Comportamiento: Cmo se comporta el sistema frente a estmulos del entorno? Se debe
organizar temporalmente las funciones.
Para construir un modelo, el sistema es descompuesto de acuerdo con los siguientes
criterios para encontrar los componentes, sus relaciones y propiedades correspondientes:
Descomposicin funcional
Particionamiento por estmulos
Agentes externos: Utilizado para construir DCU
Conceptos de dominio
Los componentes del modelo deben organizarse para poder atender las propiedades del
sistema que representan.
Dimensiones del modelado
Esttica: Se busca capturar el aspecto permanente del sistema
Dinmica: Se interesa en el comportamiento del sistema. Una distincin arbitraria que puede
hacerse en esta dimensin es considerar los niveles de comportamiento e interaccin, siendo
ambos mutuamente dependientes. Esta relacin comportamiento-interaccin es recursiva con
respecto a la descomposicin del sistema.
Funcional: Indica qu hace el sistema: Su nfasis est en la transformacin de entradas en
salidas. En esta dimensin los procesos se conciben como cajas negras.
No existe una secuencia dada para definir qu dimensin modelar primero
Analoga del acuario: Ninguna dimensin es ms bsica, fundamental o esencial: Cada
una representa una vista parcial y estn relacionadas entre s porque describen lo mismo.

2
Patrones
Un patrn es un modelo predefinido como una solucin estandarizada para problemas
recurrentes de modelado.
Paradigmas del modelado
Un paradigma define una forma de ver la constitucin de los sistemas, lo cual influye en la
manera en que son modelados. Existen dos visiones prevalecientes:
1. Paradigma de proceso: Asume que el sistema est compuesto por funciones o procesos
que operan sobre datos. Bajo este paradigma se asume que los componentes para el
modelo de un sistema son los procesos. Por otra parte, la funcionalidad que presenta el
sistema ser fcilmente identificable con los procesos que componen dicho sistema.
La agregacin del sistema es hecha agrupando procesos que juntos constituyen un
proceso de ms alto nivel o superproceso.
2. Paradigma de objeto: Asume que el sistema est compuesto por objetos que encapsulan
atributos y operaciones. Un objeto est encapsulado: Agrupa los datos y los procesos en
una unidad atmica.
No existe correlacin entre la funcionalidad que el sistema exhibe para el entorno y la
composicin de objetos del mismo sistema.
La agregacin del sistema no existe en el sentido de generar superobjetos
No es posible simular procesos con modelo de objetos, ya que sera necesario desintegrar o
desencapsular el objeto.

3
Captulo 2: Diagramas Entidad Relacionamiento y de Clases

Con un DE es posible responder a las siguientes preguntas-tipo:

Cules son los conceptos principales del dominio considerado?
Qu relaciones existen entre estos conceptos?
En particular, cuando el DER es enfocado en la solucin de un problema, sirve para
responder a las siguientes preguntas-tipo:
Qu datos deben quedar en la memoria del sistema?
Qu debe registrarse en el sistema?
Qu estructuras se requieren para los datos del sistema?
Cuando el DCla es enfocado en la solucin de un problema, debe responder a las siguientes
preguntas-tipo:
Qu clases de objetos forman parte del sistema?
Qu asociaciones existen entre estas clases del sistema?
Diagrama Estructural
A continuacin se presentan las caractersticas comunes a ambos diagramas:
Entidad/Clase: Es una abstraccin que destaca propiedades comunes a los elementos de un
conjunto. Las instancias/objetos de una entidad/clase se agrupan porque presentan ciertas
propiedades comunes y relevantes para efectos del modelado. Sin embargo, las
instancias/objetos deben poder ser distinguibles entre s.
Las propiedades comunes que presentan las instancias/objetos de una entidad
corresponden justamente a lo que se definir como atributo.
Relacionamiento/Asociacin: Es un conjunto variable de conexiones entre las
instancias/objetos de una o ms entidades/clases. An cuando la definicin de relacionamiento
y de asociacin es la misma, existe una diferencia de interpretacin con respecto a la forma de
concebir las conexiones:
En el DER, los relacionamientos tienen instancias, al igual que las entidades. En la
figura, puede entenderse que las instancias del relacionamiento compra son pares
ordenados, con el primer elemento toma de entre las instancias de CLIENTE y el
segundo elemento de entre las instancias de ARTCULO.

4
 En el DCla, las asociaciones no tienen instancias, ya que simplemente representan
conexiones directas entre objetos.

Cardinalidad de los relacionamientos y multiplicidad de las asociaciones: Representa

las restricciones sobre la cantidad de instancias/objetos de una entidad/clase que participan en
un relacionamiento/asociacin. Para el caso del DER, la cardinalidad se representa como un par
ordenado (, ); mientras que para el DCla, la multiplicidad se expresa como un
rango numrico . . .

Convencionalmente, el par (1, n) que define la cardinalidad de CLIENTE con

relacin a ARTCULO se anota al lado de ARTCULO.
Si la cardinalidad/multiplicidad mnima es cero para una entidad/clase, entonces se
dice que el relacionamiento/asociacin es opcional para la entidad/clase; en otro
caso, es obligatorio.
Clasificacin de relacionamientos/asociaciones:
Una forma de clasificar los R/A dice relacin con la cantidad de E/C involucradas. De
acuerdo a este criterio, es posible distinguir las siguientes categoras:
1. Unarios: Conexin de I/O de una misma E/C.
2. Binarios: Conexin de I/O entre dos E/C distintas.
Un caso particular de relacionamientos binarios es el auto-relacionamiento, el
cual conectan dos instancias diferentes de una misma entidad. La consideracin ms
importante es indicar cul es el papel o rol que desempea cada lado de la entidad,
de tal manera de poder interpretar correctamente la conexin de las instancias que
configuran el par ordenado.

5
 En la figura, una de las instancias de ASIGNATURA
es la requirente que exige a otra instancia de
ASIGNATURA como pre-requisito.

3. Mltiples o n-arios: R/A que involucra tres o ms E/C.

Para determinar la cardinalidad de una entidad en un relacionamiento n-ario, es
necesario fijarse en una instancia de la entidad en cuestin, agrupar las otras n-1
entidades y definir cuntas veces, como mnimo y mximo, puede participar dicha
instancia con el grupo de n-1 instancias de las otras entidades.

Atributos: Es una propiedad comn a todas las instancias/objetos de una entidad/clase, cuya
valoracin permite describir dichas instancias/clases. Para ser considerados atributos, las
propiedades deben ser:
Relevantes: Es decir, importantes o significativas para el dominio que se est
modelando.
Determinantes: Es decir, que presenten una valoracin que permita describir
efectivamente a las instancias/objetos.
Intrnsecas: Es decir, que de preferencia sean esenciales o propias slo de la entidad
o clase que describan.
Los atributos constituyen el medio por el cual se pueden describir las entidades/clases en
un DE. En este sentido, se podra asumir errneamente que si una entidad/clase no posee
atributos entonces debe eliminarse del modelo.
Clasificacin de atributos: Los atributos se pueden clasificar de acuerdo a las
siguientes categoras:
Descriptivos: Son aquellos atributos que son claramente intrnsecos a la
entidad o clase.
Nominativos: Corresponde a atributos que permiten la identificacin de las
instancias/objetos de una entidad/clase.
Referenciales: Son los atributos que expresan una relacin con algn
elemento no representado como entidad/clase en el modelo. Por ejemplo, la
marca de un automvil se considera referencial, ya que no es una propiedad
nica de AUTOMVIL.

6
 Cardinalidad/multiplicidad de atributos: Se debe indicar las restricciones sobre la
cantidad de valores de un atributo que puede tener una instancia/objeto de una
entidad/clase. La valoracin de un atributo puede ser:
nica: Significa que la instancia/objeto posee exactamente un valor del
atributo. Se asume esta valoracin por omisin.
Opcional: Significa que la instancia/objeto puede o no posee valor para el
atributo.
Mltiple: Significa una multivaloracin, es decir, que la instancia/objeto puede
tener varios valores para el atributo.
La forma de anotar la cardinalidad/multiplicidad es con un par ordenado
(, ) frente al crculo del atributo para el caso del DER, y con un rango
entre parntesis cuadrado [ , ] seguido al nombre del atributo en el
DCla.
Aspectos avanzados del DE
Restricciones: Es una condicin que debe ser siempre verdadera para una porcin
determinada del DE. Las restricciones son enunciados anotados entre parntesis de llave {} y
permiten representar precisamente lo que se quiere, cuando los elementos de representacin
del DE sean insuficientes.

Atributo global - Atributo de clase: Es una propiedad cuyo valor es del conjunto del
conjunto de instancias/objetos de la entidad/clase como un todo. Muchas veces es identificado
a partir de un atributo valorado idnticamente por todas las instancias/objetos.
Jerarqua de tipos: Define una relacin tipo y subtipo entre entidades/clases.
Herencia: Mecanismo a travs del cual todos los atributos y R/A de una E/C estn
implcitamente definidos en todas y cada una de sus subentidades/subclases. Su
fundamento es simple: Se trata de las mismas instancias de la entidad que han sido
representadas como subentidad.
La jerarqua de tipos permite lograr modelos ms expresivos, ya que se indica
explcitamente qu subconjuntos poseen atributos o relacionamientos/asociaciones
especficos. En caso de no utilizarla, dichos atributos y relacionamientos/asociaciones
debern ser representados como opcionales en el padre.
Taxonomas de las jerarquas de tipos: La categorizacin puede hacerse de
acuerdo a los siguientes criterios no excluyentes:

7
 1. Subtipo: Entiende una entidad/clase como una categora que es particionada en
subcategoras generalmente disjuntas. Por ejemplo, una figura geomtrica
particionada en polgono, elipse, etc.
2. Restriccin: Define que existe un subconjunto de instancias/objetos al cual es
aplicable una restriccin, es decir, constituyen un caso particular de todas las
instancias/objetos existentes. Por ejemplo, un camin es un vehculo restringido
para los efectos de transporte de carga.
3. Extensin: Se define un subconjunto cuyas instancias/objetos poseen atributos
y/o relacionamientos/asociaciones que no aplican a las dems.
4. Estados: Se categoriza en funcin de los estados que pueden presentar las
instancias/objetos. Bajo este criterio, las instancias pueden migrar de subentidad
durante su existencia.
5. Vistas: Se aplica cuando existen mltiples categoras sobrepuestas entre s.
Propiedades de las jerarquas de tipos:
a) Cobertura: Muestra si se est considerando, en las subentidades, todas o slo
alguna de las instancias de la entidad. Existen dos posibilidades:
Total o completa: Se dice que la jerarqua es total (en el DER) o
completa (en el DCla) si todas las I/O de la E/C pertenecen a alguna de las
subentidades/subclases.
Parcial o incompleta: Algunas de las I/O de una E/C no pertenecen a
ninguna subentidad/subclase.
b) Interseccin: Muestra si existen o no instancias en comn entre las
subentidades. Existen tambin dos posibilidades:
Exclusiva o disjunta: Una jerarqua es exclusiva (DER) o disjunta (DCla)
cuando la interseccin entre las I/O de las subentidades/subclases es
vaca.
Sobreposicin: Una jerarqua es sobrepuesta cuando la interseccin
entre las I/O de las subentidades/subclases no es vaca, es decir, se
permite que hayan I/O en comn entre las subentidades/subclases.

8
 Tipo potencia: Es aquel que mantiene como instancias los nombres de las
subentidades de otra entidad. La idea es poder sustituir la jerarqua de esta entidad por
un relacionamiento con el tipo potencia. Esta sustitucin tiene sentido cuando se
estima que las subentidades de la jerarqua pueden cambiar frecuentemente.
Diagrama de Entidad-Relacionamiento
A continuacin se presentan las caractersticas propias del DER, las cuales no son
compartidas por el DCla:
Entidad agregada: Es una entidad generada a partir de la abstraccin de un relacionamiento
base, que permite que este ltimo sea entendido tambin como una entidad. La idea es que las
instancias del relacionamiento base, por medio del mecanismo de la entidad agregada, se
interpretan ahora como instancias de una entidad, de tal manera que sea posible relacionarla
con otras entidades.
Constituyen una manera de simplificar los relacionamientos mltiples
Atributos:
1. Atributos de relacionamientos: Para determinar si un atributo es de una entidad o
de un relacionamiento, se debe analizar si su valoracin depende de la instancia del
relacionamiento que conecta las instancias de las entidades o si slo depende de la
instancia de una entidad.
2. Atributo compuesto: Son atributos definidos como un conjunto de otros atributos
componentes. Tambin pueden ser opcionales y multivalorados.
3. Atributo identificador: Es la coleccin mnima de atributos que permite la
identificacin de las instancias de entidades y de relacionamientos. Buenos candidatos
a identificadores son los atributos nominativos, an cuando no siempre existan y
eventualmente se requiere ms de un atributo para conformar el identificador.

9
 4. Relacionamiento identificador: Es un mecanismo que permite identificar las
instancias de una entidad denominada dbil, por medio de un relacionamiento con otra
entidad. Las instancias de una entidad dbil no pueden ser identificadas utilizando
sus atributos, por lo que requieren que su identificacin se haga por medio de un
relacionamiento en el cual participa.
En la figura, no es posible identificar las instancias de DEPARTAMENTO slo con
el atributo nmero, ya que perfectamente puede haber varios departamentos con el
mismo nmero en distintos edificios. Entonces, para asegurar su identificacin, se debe
conocer previamente el edificio al cual pertenece, lo cual se muestra por medio del
relacionamiento identificador:

Jerarquizacin: La jerarquizacin del DER es hecha mediante la agrupacin de componentes

en los denominados clusters. Esta jerarquizacin no es recursiva, ya que un cluster es muy
diferente a una entidad.
Un cluster es una agrupacin cohesionada de entidades y sus
correspondientes relacionamientos. Se busca que los clusters tengan la
mayor cohesin (fuerza interna de los relacionamientos) posible.
Espectro de cohesiones fuertes:
1. Cohesin por dominancia: Incluye los relacionamientos con una entidad
dominante, es decir, con una entidad que participa en al menos dos
relacionamientos cuyas cardinalidad mximas son del tipo 1: o : .

2. Cohesin por abstraccin: Incluye a todas las entidades que forman parte de
una jerarqua de tipos.
3. Cohesin por restriccin: Se agrupa a todos los elementos que forman parte de
la restriccin, de tal manera que permitan su interpretacin dentro de un solo
cluster.
Espectro de cohesiones dbiles:
1. Relacionamiento simple: Con un espectro propio ordenado de mayor a
menor fuerza, dependiendo de las cardinalidades mximas de los
relacionamientos:
Unarios: El auto-relacionamiento es el ms fuerte entre los dbiles

10
 Binarios 1:1
Binarios 1:n
Binarios n:n
2. Relacionamientos mltiples
3. Sin relacionamientos: Uso de criterios no estticos o simple coincidencia
Proceso de clusterizacin:
1. Identificar potenciales clusters con la mayor cohesin posible, buscando
descendentemente en el orden del espectro.
2. Delimitar los clusters que tengan la mayor cohesin cubriendo al mximo el DER. Si
hay conflictos, resolver con el rbol de decisiones:

3. Construir el nivel superior con los clusters seleccionados y los relacionamientos

resultantes.
Algunas consideraciones adicionales para la clusterizacin son:
a) Los nombres de los cluster dependen de la cohesin: Si sta es fuerte, el cluster
hereda el nombre de la entidad que lo rige; si es dbil, se deber asignar un
nombre representativo.
b) Una entidad agregada se puede entender como un cluster bsico, por lo que no
debe dividirse.
c) Los cluster no tiene auto-relacionamientos.
Relacionamientos en la jerarquizacin:
Relacionamiento agregado: Es un relacionamiento
que representa dos o ms relacionamientos paralelos de
un cluster con una entidad o con otro cluster.
Relacionamiento abstracto: Representa a un
relacionamiento con una entidad que no es la que rige
el cluster fuerte cohesionado, o es con cualquier
entidad en un cluster dbilmente cohesionado.

11
 Ejemplos de jerarquizacin:

Diagrama de Clases
Atributos derivados: Es un atribuyo cuyo valor puede obtenerse mediante
algn tipo de operacin de los otros elementos del DCla, tales como atributos
o asociaciones. En el DCla no necesariamente deben eliminarse, siempre y
cuando se anoten claramente.
Identificador de objetos: A diferencia de las entidades en el DER, las clases no requieren la
definicin de identificadores, ya que se asume que todos los objetos, por omisin, tienen un
oid (object identifier) valorado propio.
Clases asociativas: Una clase asociativa es una asociacin entre clases que se entiende como
una clase.
Es til para representar propiedades de una asociacin siempre y cuando no se tenga
duplicidad de conexiones en la asociacin, ya que slo existe un objeto de la clase
asociativa por cada par de objetos distintos conectados en la asociacin. Si las
duplicidades son requeridas para la asociacin, la nica posibilidad es la reificacin de la
asociacin, es decir, crear una nueva clase en vez de la asociacin, cuyos objetos se
conectan con los objetos de las clases originales.
Asociaciones derivadas: Una asociacin derivada es una asociacin que conecta objetos que
ya estn conectados directa o indirectamente por medio de otras asociaciones, bajo un mismo
significado. Cabe destacar que, al igual que los atributos derivados, deben ser anotadas
explcitamente por medio de un / antes del nombre.
Estructura todo/parte: Es un caso particular de asociacin entre un objeto todo y otros
objetos entendidos como sus partes. Los tipos posibles de ETP estn determinados por la
combinacin de tres restricciones o propiedades:
Configuracin: Aplica cuando las partes poseen una relacin estructural o funcional
determinada con respecto a otras partes y/o con respecto al todo que constituyen.
Carcter homemero: Aplica cuando las partes son del mismo tipo que el todo.

12
 Inmutabilidad: Aplica cuando las partes no pueden separarse del todo sin destruirlo.
Estas tres propiedades se pueden combinar generando seis posibilidades de ETP:
1. Componente integral: Es el tipo de estructura todo/parte ms comn y define una
configuracin de partes dentro de un todo. Un objeto integral es dividido en partes
componentes, las cuales tienen un rol especfico a desempear con respecto a las otras
partes y/o dentro del todo.
2. Material: Define una ETP en trminos de una configuracin inmutable de partes
materiales dentro de un todo. Por ejemplo, un pan es en parte harina.
3. Porcin: Define una configuracin homeomrica de las partes respecto del todo. En
otras palabras, esta divisin ocurre cuando las partes son del mismo tipo del todo, con
lo cual es frecuente que se tenga una ETP entre objetos de la misma clase (una auto-
asociacin).
4. Lugar de rea: Define una configuracin inmutable y homeomrica de las partes
dentro del todo. Se agrega entonces a la divisin porcin anterior, la restriccin de la
inmutabilidad en este tipo de ETP, es decir, las partes no pueden ser removidas.
5. Miembro de grupo: Es el tipo de ETP menos restrictiva desde el punto de vista de la
configuracin: las partes no requieren cumplir un rol especfico dentro del todo. Se
define, entonces, como una coleccin de partes de un mismo tipo dentro del todo.
6. Miembro de sociedad: Define una coleccin inmutable de partes de un mismo tipo
para conformar el todo.
Representacin de la ETP: Las ETP se pueden representar de acuerdo a dos
posibilidades: Agregacin y composicin.
Agregacin Composicin

Independencia del todo: El objeto agregado Dependencia del todo: El objeto compuesto
puede existir sin sus objetos constituyentes. no debe existir sin sus objetos componentes.

Compartimiento de las partes: El objeto Exclusividad de partes: El objeto

constituyente puede formar parte de ms de componente debe formar parte de un solo
un objeto agregado a la vez. objeto compuesto a la vez.

Homogeneidad de partes: Todos los Heterogeneidad de partes: Los objetos

objetos constituyentes deben pertenecer a la componentes pueden pertenecer a clases
misma clase. distintas.

13
Captulo 3: Diccionario de Datos
El DD es un modelo esttico que sirve para la documentacin de los datos que aparecen
representados en los distintos modelos de un sistema. En este sentido, un DD sirve para describir:
Elementos estructurales, como las entidades o clases en trminos de sus atributos;
Variables y parmetros de modelos dinmicos, tales como los usados en condiciones
y mensajes en un SCH o un DInt;
Flujos de datos y depsitos, que aparecen en modelos funcionales tales como el DCU y
DFD;
Valores y significados de datos elementales, que componen los elementos descritos
de los diferentes modelos.
Elementos de un DD
1. Datos compuestos y componentes:
Un dato compuesto es un dato cuya composicin, en trminos de datos componentes, es
relevante de definir. Por su parte, un dato componente es un dato que forma parte de la
definicin de un dato compuesto.
Toda definicin de un DD debe tener un dato compuesto y al menos un dato componente
(la nica excepcin son las definiciones de datos elementales). De esta manera, el DD define
cul es la composicin de los datos, en trminos de otros datos, y no cul es su contenido.
Dicha composicin debe indicar adems, cules son las relaciones entre los datos
componentes, definindose as la estructura que tiene un dato compuesto.

2. Composicin: Toda definicin de un DD es una relacin de composicin entre un dato

compuesto y uno o ms datos componentes.
3. Concatenacin: Es la relacin que se establece entre dos o ms datos componentes, de tal
manera que estos deben estar siempre presentes en el dato compuesto. La concatenacin
indica una relacin del tipo AND entre los datos componentes de la definicin de un dato
compuesto.
4. Opcionalidad: Es la propiedad de un dato componente de estar o no presente en la definicin
de un dato compuesto. El nico cuidado que se debe tener con la opcionalidad es no definir un
dato compuesto slo en trminos de opcionalidades de datos componentes (lo ideal es que
nunca falten todos los datos componentes).

14
5. Seleccin: Es la relacin que se establece entre dos o ms datos componentes, de tal manera
de exigir la presencia de exactamente uno de ellos en la definicin del dato compuesto.
6. Repeticin: Es la propiedad que posee un dato componente para estar presente varias veces,
en la forma de un conjunto, en la definicin de un dato compuesto. La repeticin indica que lo
que est adentro del parntesis de llave es repetido 0 o ms veces. En el caso de la
representacin textual, es posible agregar lmites de la siguiente forma: { }, donde .
7. Datos elementales: Un dato elemental es un dato que no requiere composicin y se define
en trminos de valoracin. Se dice que son unidades atmicas sobre las cuales se construyen
todas las definiciones del DD.
Datos elementales auto-definidos: Son aquellos sobre los cuales existe un
consenso general acerca de su significado. Un ejemplo podra ser nombre cliente.
Datos elementales no auto-definidos: Se debe indicar cul es el significado que se
le est asignando en el contexto del modelado del sistema, y cul es la posible
valoracin que pueden asumir.
Los datos elementales se definen usando un comentario (que se anota entre asteriscos),
indicando el significado acompaado de la valoracin, en trminos de rangos o valores
enumerados, la unidad de medida y cualquier otra informacin que se juzgue necesaria.
estatura = medida longitudinal de una persona; unidad = cm; rango: 50. .250
8. Identificador: El uso del identificador se justifica claramente al entender el rol
complementario que el DD presenta con respecto al DER.
9. Aliases: Son nombres alternativos para un mismo dato, los cuales se deben indicar por medio
de comentarios que hacen referencia al nombre que s tiene una definicin en el DD.
Relaciones entre un DER y un DD
Para complementar al DER, el DD sirve para definir las entidades y los relacionamientos, en
trminos de sus atributos. De esta manera, es posible simplificar el DER eliminando los atributos
del mismo y documentndolos en el DD.
Es importante tener en claro que, bajo ninguna circunstancia, el DD persigue reemplazar al
DER. Por ejemplo, en l no aparecen elementos como las cardinalidades de los
relacionamientos; restricciones en general; clusters; etc.

almacenamiento = * alias de se almacena en *

bodega = @nombre + (superficie) + direccin

producto = @cdigo + nombre + unidad

se almacena en = *relacionamiento entre PRODUCTO y BODEGA * stock + stock mnimo + 1{localizacin}

15
 Convenciones:
Relacionamiento sin atributos: Los relacionamientos sin atributos tambin deben
aparecer en el DD, pero por una razn ms bien pragmtica: Evitar los errores por
emisin. Se recomienda utilizar un comentario que simplemente describa las entidades
que relaciona.
Entidades agregadas:

consulta = *agregacin de MEDICO atiende PACIENTE* @rcm+ @rut + @fecha-hora

Atributos compuestos: Se representa ms adecuadamente haciendo uso de

definiciones jerrquicas.
persona = @rut + { direccin }
direccin = calle + nmero + (departamento) + ciudad + regin
Atributos globales:

Jerarquas de tipos:

Relaciones entre un DCla y un DD

El DD puede cumplir los siguientes roles complementarios, dependiendo de la forma en que
se hayan representado las clases en el DCla:
Si se representan en forma compacta (slo con el nombre), el DD servir para describir
las clases en trminos de atributos, de manera anloga al DER.
Si se representan de forma extendida, el DD sirve para describir los atributos
entendidos como datos elementales no auto-definidos.
Formato de la definicin de atributos:

16
Captulo 4: DTE, SCH y DME (modelos de dimensin dinmica)
DTE es el modelo bsico de la dimensin dinmica enfocado en el comportamiento.
Mquina
. Secuencial de Estados Finitos (MEF): DTE fue formalizado para representar conceptualmente el
comportamiento de las MEF.
Una MEF es una mquina hipottica que:
Posee un conjunto finito de estados, de los cuales slo uno de ellos se encuentra activo a la
vez.
Responde a estmulos, generando respuestas y cambiando internamente de estado.
Como la MEF puede encontrarse en slo un estado en cada momento del tiempo, el cambio
del estado actual al prximo estado se considera instantneo. Lo anterior impide que la MEF pueda
presentar paralelismo o concurrencia de estados.
Tanto la respuesta como el prximo estado dependen del estado actual y del estmulo. As
entonces, es posible que una MEF responda diferentemente a un mismo estmulo, ya que puede
encontrarse en distintos estados cada vez que lo reciba.
Los estados internos son los encargados de mantener la memoria de los estmulos que se
han recibido.
Diagrama de Transicin de Estados
La representacin ms utilizada para representar una MEF es un DTE, el cual se compone
de los siguientes elementos:
1. Estado: Un estado es una situacin o circunstancia
especfica distinguible en la que puede encontrarse el
sistema y que existe en un intervalo de tiempo. Los estados
pueden ser: (1) De espera por la ocurrencia de un evento o
(2) de realizacin de una actividad.
2. Transicin: Es el cambio de un estado de origen a uno de destino, representando que el
sistema abandona el estado de origen y asume el estado de destino en forma
instantnea. La transicin se anota como un arco dirigido entre dos estados no
necesariamente distintos.
3. Evento: Es la ocurrencia en el entorno de un hecho instantneo, atmico que no puede
descomponerse y relevante, al cual el sistema debe responder. El nombre del evento
debe reflejar justamente algo que ocurri, por ejemplo: Contacto recibido, inicio-pausa
presionado.
4. Accin: Es una operacin instantnea, realizada por el sistema, a consecuencia de un
evento. Su nombre est conformado por un verbo en infinitivo, seguido de un objeto:
verificar pago.
a) Variante Mealy: Define que las acciones se representan en
las transiciones: Las acciones se entiende como un efecto
directo de la ocurrencia de una transicin (no interesa cul
es el estado de destino).

17
 b) Variante Moore: Se asume que las acciones se representan en los estados: Las
acciones se entienden como una consecuencia de asumir un estado (no interesa cul
es la transicin que lleva al estado).
Consideraciones adicionales
Un DTE tiene, de forma no excluyente: Un nico estado inicial; un conjunto de estados
finales (incluyendo el conjunto vaco), que corresponde a los estados terminales a los
cuales se puede llegar, pero no se puede salir; y un conjunto de estados intermedios
(incluyendo el conjunto vaco).
Las transiciones pueden tener slo un evento. Puede haber situaciones que no generen una
accin, sino que slo un cambio de estado.
Las transiciones pueden tener asociados ms de una accin. Las acciones en la lista
separadas con comas no tienen ninguna secuencia especfica y pueden realizarse en
cualquier orden.
Jerarquizacin
La jerarquizacin del DTE es hecha por medio de los estados particionados, los cuales
tienen un DTE aparte. Esta jerarquizacin es recursiva, ya que se tiene estados y transiciones en
todos los niveles.
Para crear un estado particionado se debe:
1. Agrupar una porcin arbitraria de un DTE que tenga una sola transicin de entrada, y
representarla como un DTE separado (denominado DTE hijo).
2. Reemplazar la porcin original por un estado particionado.

Consistencia entre transiciones entre DTE padre e hijo

DTE padre DTE hijo

Transicin de entrada al estado Transicin inicial

particionado

Transicin implcita de los estados finales, o

Transicin de salida del estado
particionado (si la hay) Transicin indicada explcitamente por medio de una
restriccin del tipo {regresa a estado x en el DTE padre}

En las transiciones de entrada a los estados particionados, puede dividirse de diferentes

formas la representacin del evento y accin. La forma recomendada es dejar el evento en el DTE
padre y la accin en el DTE hijo.
Tabla de transicin de estados
Cuando el comportamiento de excepcin es importante de ser representado, el DTE no es
el modelo ideal. Las excepciones pueden sobrecargar el DTE y para esto es recomendable utilizar
una TTE.

18
 Una TTE es una manera tabular de representar una MEF:
Las filas muestran todos los estados posibles de la MEF
Las comunas muestran todos los eventos posibles de ocurrir
Al organizar la TTE como el producto cartesiano de estados/eventos, obliga a analizar
sistemticamente todas las posibilidades. Cada entrada de la TTE puede completarse con una de
las siguientes alternativas:
Prximo estado / acciones asociadas: En este caso, cuando ocurre el evento en el
estado, se gatilla la transicin a prximo estado y se realizan las acciones
asociadas.
Evento ignorado: La ocurrencia del evento en el estado no es considerada en
absoluto, ya que no produce ningn efecto.
No puede ocurrir: La ocurrencia del evento en el estado es anmala y representa
un error de comportamiento.

Una forma de intentar distinguir los casos de eventos ignorados de aquellos que no pueden
ocurrir, es representar slo los primeros como auto-transiciones. Todo lo no representado
en un DTE correspondera a los casos que no pueden ocurrir.
Si se quiere representar una MEF variante Moore con una TTE, se aade una ltima
columna que representa las acciones asociadas con los estados de cada fila.
Statechart
El SCH asume las propiedades del DTE, en el sentido de concebir los
mismos elementos de representacin (con algunos cambios notacionales menores)
y aporta adems algunas propiedades que se indican a continuacin:
Con respecto a los estados:
1. Jerarquizacin de estados:
Una jerarqua de estados est constituida de tal forma que cuando el sistema se
encuentra en un estado dado, implica que tambin se encuentra en otro estado de ms
alto nivel.
Si dos estados tienen una transicin de salida hacia un mismo estado de destino
provocada por un mismo evento, entonces es posible agrupar dichos estados en un
superstado con una transicin mltiple.
2. Estados concurrentes:
La concurrencia entre estados es la posibilidad de que el sistema se encuentre en
ms de un estado a la vez, sin que exista relacin jerrquica entre ellos. De esta forma, el
SCH puede modelar un sistema como dos o ms MEF en paralelo, lo cual aumenta
significativamente su poder de expresin por sobre el DTE.
El sistema siempre se encontrar en algn subestado de cada MEF representada.
Si se quisiera modelar un sistema que presenta concurrencia con una MEF, entonces se
tendra tantos estados compuestos como nmero de combinaciones posibles de los
estados del sistema.

19
 Eventos concurrentes: Son dos o ms eventos que ocurren simultneamente. Ante tal
situacin, un SCH gatilla simultneamente tantas transiciones como sea posible. En algunos
casos los eventos concurrentes son:
Imposibles de responder: Cuando no existen estados concurrentes
Imposibles: Cuando no pueden ocurrir en la realidad
En estados concurrentes: Perfectamente posibles
Sincronizacin de transiciones: Existe sincronizacin cuando dos o ms transiciones
denominadas sincronizadas son gatilladas simultnea e independientemente por un
mismo evento. Se dice que son independientes porque si se tiene n transiciones
sincronizadas y ocurre el evento comn, puede gatillarse cualquier subconjunto de stas
(incluyendo el conjunto vaco), dependiendo de cules son los estados activos en el
momento de la ocurrencia del evento.
Lo anterior implica necesariamente que las transiciones sincronizadas pertenecen a
superestados concurrentes.
Existe una situacin indeterminada de eventos con el mismo nombre, que no est
asociada a estados concurrentes (ver ejemplo pgina 194). En estos casos, en SCH se
prefiere la transicin que conecta estados de ms alto nivel.
Encadenamiento de eventos: Existe encadenamiento de eventos cuando dos o ms
transiciones son gatilladas secuencial y dependientemente, por medio de las
realizaciones de acciones, a partir de un nico evento. En este caso, la dependencia se da
porque necesariamente debe gatillarse la primera transicin para que la segunda pueda
gatillarse: Basta que una transicin dentro de la secuencia no se gatille para impedir que
las restantes transiciones dependientes puedan gatillarse.
Lo anterior implica que las transiciones en la secuencia deben pertenecer a
superestados concurrentes.
Con respecto a las transiciones:
1. Condiciones:
Una guardia o condicin de una transicin representa una expresin lgica, que al
ser evaluada como verdadera, permite gatillar la transicin. Para que una transicin se
provoque, por tanto, necesita que el evento asociado ocurra (si existe) y que adems la
condicin sea verdadera. En general, una transicin debe etiquetarse de la siguiente forma:
evento (condicin) / accin, pudindose omitir hasta dos de los tres elementos.
Verificacin de estados: Es una condicin que evala la situacin del sistema con
respecto a estados especficos. La forma bsica de la verificacin de estados es: (in
superestado.estado.subestado). Al ser una condicin, la verificacin de estados
permite expresiones lgicas, por lo que puede utilizarse operadores lgicos para situaciones
ms complejas.
2. Transicin mltiple:
Una transicin mltiple es una transicin que tiene ms de un estado de origen o
ms de un estado de destino. Al representar, para una transicin, varios estados de origen
o varios estados de destino, se busca evitar redundancia (criterio de minimalidad).

20
 : Representacin de transiciones mltiples desde un estado comn que difieren slo
por una condicin (que contiene variables locales).
Diagrama de Mquina de Estados
El DME asume propiedades del SCH, en el sentido de la representacin de todos sus
elementos (con cambios notacionales mnimos en los superestados y en las condiciones), pero
tambin modifica nomenclatura y la semntica de algunos comportamientos modelados.
Nomenclatura y notacin del DME:

Semntica:
Cuando se tiene un mismo evento en dos o ms transiciones que conectan estados
de distintos niveles en la jerarqua, en DME se prefiere la transicin que conecta
estados de ms bajo nivel.
Los eventos concurrentes se entienden serializados por una interfaz entre el
entorno y el sistema.
Cuando se tiene encadenamiento de eventos, y ocurren eventos internos en forma
concurrente con eventos externos, se asume que el sistema puede posponer la
respuesta a cualquier evento (se responden en secuencia al ser serializados).
Acciones en los estados
El DME permite acciones en los estados, adems de las que se representan en las
transiciones. De esta forma, el DME combina las variantes Mealy y Moore del DTE.
Dentro de las acciones en un estado del DME, se distinguen dos eventos especiales:
entry: Este evento ocurre siempre cuando se ingresa al estado
exit: Este evento ocurre cuando se abandona el estado

21
Secuenciacin de acciones en las transiciones
Una diferencia con respecto al DTE y el SCHE, es que se asume que las acciones ahora
separadas por punto y coma se realizan en secuencia, de acuerdo a cmo son mostradas.
Actividad en los estados
Una actividad es una operacin realizada por el sistema durante la permanencia en un
estado, que toma tiempo en completarse y puede ser interrumpida a propsito de la ocurrencia de
un evento.
Se anotan con el evento especial do
Permiten representar transiciones que omitan eventos asociados, con lo que los cambios de
estado se producen al finalizar la actividad. En otras palabras, es posible tener situaciones
en que la permanencia en un estado actividad depende nica y exclusivamente de la
duracin que tome al sistema realizar la actividad correspondiente.
Lo anterior tambin permite un estado tenga transiciones de salida slo con condiciones.
Transiciones interna a estados
Una transicin interna es una reaccin que se produce durante la permanencia en un
estado, a causa de un evento, que no produce ningn cambio de estado. La idea de las transiciones
internas surge de la incorporacin de las acciones de entrada y de salida en los estados.
Las transiciones internas son equivalentes a las auto-transiciones en ausencia de acciones y
actividades en el estado.
Las reacciones acciones, actividades y transiciones internas de un estado s, son
equivalentes a los transiciones en una submquina de estados auxiliar de s, que es
concurrente con las submquinas de estados normales s y con otras acciones, actividades y
transiciones internas que existan (ver pgina 206).
Estado final
Los estados finales terminan el comportamiento exhibido
por un sistema y se anotan en la forma de un ojo de buey.

Criterio de simplicidad
Para simplificar un DTE, SCH y DME, existe una transformacin simple que hacer para un
caso muy comn de encontrarse: Los estados colgantes.
Estado colgante: Es un estado no inicial que posee transiciones con un nico estado
(puede tener auto-transiciones, pero ninguna reaccin de estado).
Al eliminar el estado colgante, sus auto-transiciones, si las tiene, se transfieren al nico
estado conectado y sus transiciones se transforman tambin en auto-transiciones de este estado.

22
Captulo 5: Red de Petri
La RP es un modelo esencialmente de la dimensin dinmica de los sistemas de
informacin. Con ella, es posible responder a las siguientes preguntas-tipo:
Qu estados puede presentar el sistema?
Qu sucede con el sistema cuando recibe un estmulo o evento?
En qu orden son alcanzados los estados del sistema?
La RP presenta los siguientes elementos:
1. Lugares: Son representados con crculos
2. Conexiones: Representados por rectngulos
3. Arcos: Conectan los lugares y las conexiones
4. Anotaciones: Textos asociados a los lugares y conexiones
Reglas de funcionamiento de una RP
La RP, adems de los lugares, conexiones, arcos y anotaciones, tambin posee reglas de
funcionamiento, las cuales definen cmo puede alcanzar distintas marcaciones en el tiempo.
Una marca en un lugar es la indicacin de que ste se encuentra activo. El conjunto de
marcas, en un instante de tiempo determinado en una RP, constituyen una marcacin. Por
ejemplo, en la figura la marcacin sera: {Pieza no pulida, Pulidora libre}
Toda RP debe tener explcitamente indicada una marcacin inicial, esto porque as se
define cmo comienza el comportamiento representado en el modelo.
Alteraciones:
Un paso o alteracin es un cambio de marcacin en la RP. La ocurrencia de una alteracin
en la RP consume las marcas de todos los lugares de entrada y produce marcas en todos los
lugares de salida.
Es importante mencionar que no siempre es posible que ocurra cualquier alteracin. Por
ejemplo, en la figura no puede ocurrir Fin de pulimiento, ya que no existe una Pieza en
pulimiento ni Pulidora ocupada. En este sentido, una alteracin en una RP se dice que est
habilitada para una marcacin dada, si todas las marcas de entrada estn presentes y todas
las marcas de salida estn ausentes:

Algunas consideraciones importantes con respecto a las marcas en los lugares:

Todos los lugares tienen capacidad para soportar slo una ficha: RP segura

23
 No existe ninguna ley de la conservacin de marcas, es decir, una alteracin no tiene
por qu mantener el mismo nmero de marcas consumidas que de marcas producidas.
Cabe destacar que el solo hecho de que una alteracin est habilitada no significa que
deba ocurrir. Lo anterior porque una conexin tiene un evento asociado y la ocurrencia de
ste permite que la alteracin habilitada realmente se produzca.
Cuando dos alteraciones estn habilitadas, stas pueden estar relacionadas concurrente o
conflictivamente:
Alteraciones habilitadas concurrentes: Son aquellas que no poseen en comn
lugares marcados de entrada ni lugares marcados de salida.
Alteraciones habilitadas en conflicto: Son aquellas que poseen en comn al
menos un lugar marcado de entrada o al menos un lugar desmarcado de salida.

Interpretaciones de la RP
Los lugares se entiende que representan estados del sistema. La anotacin asociada sirve
como nombre del estado.
Las conexiones, por medio de los arcos, conectan lugares, configurando as transiciones de
estado.
Las anotaciones de las conexiones se entiende como los eventos que regulan la ocurrencia
de la transicin de estado.
No obstante lo anterior, tambin existe una interpretacin de estados y transiciones sin
anotaciones:
Una transicin sin evento (una conexin sin anotacin en la RP) se interpreta como una
alteracin que ocurrir apenas se habilita, ya que no existe ningn evento que la regule.
Un estado sin nombre (un lugar sin anotacin en la RP) se interpreta como un estado que
no tiene significacin para el sistema modelado, pero que es til como un estado auxiliar
para otro propsito, como por ejemplo habilitar una alteracin.

24
Aspectos avanzados de la RP
Anotaciones en las conexiones: Es posible realizar anotaciones dentro de las conexiones,
pudiendo indicar:
Una accin que se realiza cuando la transicin ocurre y que no toma tiempo en concluir
Una condicin que se evala en el momento en que ocurre el evento en la alteracin
habilitada; si sta es falsa, la transicin no ocurre.
En la figura, la transicin se dar si es que est
habilitada la conexin, si ocurre el evento Recepcin
pedido y si la condicin de crdito es verdadera. En el
caso de que la transicin ocurra, entonces la accin
consultar stock es realizada.
Ramas restauradoras: Una rama es una asociacin de un estado con una transicin por
medio de un arco. Existen ramas de entrada y de salida, as como tambin alteradoras y
restauradoras. Las ramas alteradoras se llaman as porque efectivamente alteran el lugar, ya
sea consumiendo o produciendo marcas. Por su parte, se dice que una rama es restauradora
cuando no alteran en lugar en forma neta.
Las ramas restauradoras son utilizadas en situaciones donde se desea que una transicin
dependa de un estado, pero que su ocurrencia no altere este estado. Existen dos tipos de
ramas restauradoras:
1. Rama restauradora de entrada: Permite habilitar una alteracin con la presencia de
una marca de entrada, pero la ocurrencia de la alteracin no consume dicha marca.
Una rama restauradora de entrada permite, entonces, verificar la presencia de una
marca en un lugar, pero sin consumirla.
An cuando la rama restauradora puede parecer una solucin que viola las reglas
de funcionamiento definidas anteriormente, en realidad corresponde a una
representacin simplificada para una solucin en forma de un patrn:

25
 2. Rama restauradora de salida: Permite habilitar una alteracin con la ausencia de
una marca de salida, pero la ocurrencia no genera dicha marca. Una rama restauradora
de salida permite, entonces, verificar la ausencia de marca en un lugar, pero sin
producirla definitivamente.
Criterio de Expresividad
Desde el punto de vista de este criterio, se privilegia el uso de ramas restauradoras en vez
de condiciones por su mayor poder expresivo (vase pgina 231).
Jerarquizacin de la RP
La jerarquizacin de la RP es hecha mediante la agrupacin de componentes en una red
abstracta del tipo canal/actividad. Esta jerarquizacin no es recursiva, ya que se pierden varias
caractersticas de la red en esta abstraccin.
Clases de RP: Las redes presentadas anteriormente corresponden a una clase denominada
sistemas de redes elementales o condicin/evento. Sin embargo, existen otras clases tales
como:
Redes lugar/transicin: Su rasgo caracterstico es que un lugar puede contener ms
de una marca. Cada rama, por consiguiente, tiene asociado un nmero que especifica
cuntas marcas se consumen o se producen por el efecto de la ocurrencia de una
transicin.
Redes compactas: Estas redes presentan mecanismos de representacin de marcas,
con lo cual se logra un poder de expresin mucho mayor y tambin una mayor
abstraccin.
Redes canal/actividad: Es una clase informal, sin reglas de funcionamiento, pero til
para efectos de jerarquizacin. Consta de actividades (representadas con rectngulos),
canales (representados con crculos) y arcos.
Red canal/actividad y jerarquizacin: Para relacionar las RP detalladas y abstracta, se
deben respetar las siguientes reglas:
1. Cada componente abstracto, ya sea canal o actividad, representa un conjunto no vaco
de componentes detallados (lugares y conexiones).
2. Todo componente detallado debe estar representado en algn componente abstracto.
3. Los arcos abstractos deben respetar el sentido de los arcos detallados. Como
convencin, las ramas restauradoras se asumen como entrada o salida segn
corresponda.
4. Los componentes detallados en un componente abstracto deben ser consistentes con el
entorno local del mismo: Las actividades contienen conexiones en los lmites y los
canales contienen lugares en los lmites.
Es necesario destacar que no existen criterios objetivos que permitan agrupar los
componentes detallados dentro de los componentes abstractos, dejndose esta decisin a cargo del
modelador.

26
Captulo 6: Diagrama de actividades
Es un modelo mayoritariamente dinmico. Con un DAct es posible responder a las siguientes
preguntas:
Qu actividades se realizan en el sistema?
Cmo se organizan temporalmente las actividades?
Qu actividades pueden ejecutarse en paralelo
Componentes de un DAct
1. Actividad: Es una tarea o paso simple dentro de un procedimiento, que toma
tiempo en completarse. Una actividad no se concibe en forma aislada, sino es
en el contexto de un procedimiento. En este sentido, las actividades
constituyen divisiones arbitrarias de las tareas o pasos que deben realizarse.
Existen dos casos particulares de actividad:
Nodo inicial: Muestra la actividad del comienzo del procedimiento representado por el
DAct. Se anota con un crculo negro como origen.
Nodo final: Muestra el trmino del procedimiento en el DAct. Se anota con un crculo
negro dentro de uno blanco como destino.
2. Transicin: Es el paso instantneo desde una actividad de origen a una actividad de destino.
Toda actividad tiene, al menos, una transicin de entrada y una de salida.
3. Componentes organizativos:
Las actividades de un DAct se pueden organizar de tres formas:
Secuencia: Implica que las actividades se realizan una despus de la otra en orden
estricto.
En general, se dice que dos actividades A y B son secuenciales si la actividad A
debe realizarse necesariamente antes que la actividad B, porque B utiliza algn
resultado generado por A.
Condicionada: Implica que las actividades se realizan o no dependiendo del valor de
verdad de ciertas condiciones.
Una actividad se dice condicionada si requiere que una condicin dada sea
verdadera para poder realizarse.
Concurrente: Implica que las actividades se realizan simultneamente sin ningn
orden secuencial.
Dos actividades se dicen concurrentes si pueden realizarse en cualquier orden de
forma independiente entre ellas.
Los componentes organizativos son:
a) Nodos decisin/unin:
Nodo de decisin: Es un componente organizativo que abre hilos condicionados
excluyentes de actividades, contando con una nica transicin de entrada y dos o
ms transiciones de salida, cada una de las cuales tiene una condicin excluyente
de las dems.

27
 Nodo de unin: Es un componente organizativo que cierra hilos condicionados
excluyentes de actividades, contando con dos o ms transiciones de entrada y una
nica transicin de salida.
Para un uso disciplinado de los nodos decisin/unin, se recomienda que siempre
vayan pareados y que se cierren la misma cantidad de hilos excluyentes que se abrieron.
b) Nodos fork/join:
Nodo fork: Es un componente organizativo que abre hilos paralelos de actividad
simultneamente, contando con una nica transicin de entrada y dos o ms
transiciones de salida.
Nodo join: Es un componente organizativo que cierra hilos paralelos de actividad,
contando con dos o ms transiciones de entrada y una nica transicin de salida,
lanzada cuando terminan todas las actividades de todos los hilos paralelos.
Para un uso disciplinado de los nodos fork/join, debern ir siempre pareados,
manteniendo igual nmero de hilos paralelos abiertos y cerrados.

Desde el punto de vista de un procedimiento implantado, que dos actividades sean

concurrentes significa que pueden implantarse en cualquier secuencia que se desee si los
recursos no permiten la concurrencia. En el caso de poder implantarse concurrentemente,
significa importantes ahorros de tiempo en la realizacin del procedimiento.
Contracciones
Bsicamente, la idea de las contracciones es simplificar un poco el formalismo asociado
principalmente con los componentes organizativos. Para estos efectos, algunos componentes
consecutivos pueden fundirse o contraerse notacionalmente:
Nodos de unin consecutivos pueden fundirse en uno solo.
Uno o ambos nodos decisin/unin pueden fundirse con las actividades que los anteceden
(para el nodo decisin) o suceden (para el nodo unin).
Las transiciones inicial y final pueden fundirse con los nodos de decisin y unin,
respectivamente.
Nodos fork consecutivos o nodos join consecutivos pueden fundirse
Un nodo fork puede fundirse con un nodo decisin consecutivo, creando de esta forma
tantos hilos condicionados como condiciones presente el nodo.
Si uno de los hilos condicionados es nulo, es decir, si no tiene ninguna actividad,
entonces puede eliminarse.
Un nodo unin puede fundirse con un nodo decisin consecutivo. Esto tambin es posible
para un nodo join con un nodo fork consecutivo.

No representan un uso indisciplinado de los componentes organizativos, ya que las

contracciones provienen de situaciones iniciales bien estructuradas.
Repeticin de actividades

28
 Desde el punto de vista de las posibilidades de organizacin de actividades que ofrece un
DAct, la repeticin puede ser:
1. Secuencial: La actividad se realiza nuevamente cada vez que termina una realizacin.
Para esta organizacin, el resultado de una actividad debe ser necesario para la siguiente.
Para su representacin, se utilizan nodos de unin y decisin (en dicho orden).
2. Concurrente simple: La actividad es realizada simultneamente varias veces. Se utilizan
nodos fork/join para su representacin.
3. Concurrente dinmico: Representacin implcita de la repeticin expresada con un * en
la actividad.
Representacin de repeticin de actividades

Particiones
Los carriles o particiones sirven en el DAct como clasificadores por responsabilidad de las
actividades. Es importante destacar que las particiones slo clasifican las actividades sin alterar
de ninguna forma la organizacin que stas presentan.
Grficamente, las particiones son reas verticales u horizontales que representan cargos,
SI, organizaciones, etctera, dentro de las cuales se clasifican las actividades realizadas.
Alternativamente, es posible representar la asignacin de las responsabilidades dentro de las
actividades, anotando el responsable respectivo entre parntesis, antes del nombre de la actividad.
En algunos casos las actividades son realizadas en forma compartida entre dos o ms
responsables. Convencionalmente, la actividad queda dibujada entre cada una de las
particiones correspondientes.
Otras notaciones
Conectores: Permiten descontinuar arcos de transiciones para evitar representaciones
complejas que dificulten la comprensin del DAct.
Pines: Permite que una actividad entregue un determinado dato a otra.
Flujos de datos: Equivalentes a los pines, en sentido de que una actividad emite un flujo
de datos para otra actividad

29
 Depsito: Son diferentes de los flujos de datos, porque se asume que existen a pesar del
trmino de las actividades directamente involucradas.
Nodo de trmino de flujo: Permite concluir temprana y localmente un hilo en el DAct.
Por medio de este nodo, es posible terminar hilos excluyentes o paralelos sin necesidad de
conectarlos con nodos unin o join, respectivamente. Su notacin es:
Criterio de simplicidad
Desde el punto de vista de la simplicidad del DAct, es posible mencionar dos
transformaciones ya mencionadas: Contracciones y eliminacin de hilos condicionados nulos.
Jerarquizacin
La jerarquizacin del DAct es posible por medio de las actividades, es decir, algunas
actividades pueden ser compuestas, lo que significa que tienen otro DAct asociado. Esta jerarqua
es recursiva, y consiste en agrupar una porcin arbitraria del DAct y representarla en uno separado,
reemplazando la porcin del DAct original por una actividad compuesta.

Ante la posibilidad de jerarquizar vertical y horizontalmente, un DAct padre puede tener

uno o ms DAct hijos, los cuales a su vez pueden ser DAct padres de otros diagramas.
Dicha jerarquizacin permite desacoplar los DAct padre e hijos, de tal manera que facilite la
reutilizacin de actividades compuestas en diferentes DAct.

30
Captulo 7: Diagrama de Procesos de Control
El DPC es un modelo predominantemente dinmico, con nfasis en la interaccin de los
sistemas de informacin (se complementa con modelos de comportamiento). Con l, es posible
responder a las siguientes preguntas-tipo:
Cmo se organizan en el tiempo los componentes (procesos) del sistema?
Qu interacciones son posibles entre estos componentes?
Qu controla la realizacin de los componentes?
Componentes de un DPC
1. Controlador: Es un papel o rol de coordinacin que ejerce un componente del sistema, que le
permite organizar temporalmente a los componentes controlados por medio de flujos de
control. Estos flujos le permiten comunicarse con los terminadores, con los componentes que
controla y, eventualmente, con otros controladores con los cuales deba coordinarse.
El DPC asume un modelo centralizado de control, por lo que en todo flujo de control debe
necesariamente participar al menos un controlador. Para ejercer este rol, el controlador activa a
los controlados de acuerdo a una organizacin temporal conocida por l, la cual generalmente
se expresa por medio de un modelo de comportamiento asociado.
Cabe destacar que su nombre debe ser representativo del aspecto que se est controlando.
Por otra parte, es importante mencionar que no tiene sentido que exista un controlador que no
tenga qu controlar.
2. Controlado: Es un papel o rol que ejerce un componente del sistema, que le permite formar
parte de la organizacin temporal coordinada por un controlador.
Es posible que un mismo componente pueda ser controlador con respecto a algn
componente, pero a la vez ser controlado frente a otro controlador. En este caso, se
conviene representar al componente como controlador.
3. Terminador: Es un elemento externo al sistema con el cual existe comunicacin. En el
contexto del DPC, el terminador interacta con el sistema emitiendo y/o recibiendo flujos de
control.
4. Flujo de control: Es una activacin o evento que es comunicado por medio de una seal
binaria. El nombre debe ser significativo con respecto a lo que se est comunicando: si se est
activando, basta con la palabra activar (que en este caso puede omitirse); pero si se est
comunicando un evento, el nombre debe reflejar el resultado de algn proceso.
Dada la centralizacin del control en el controlador que supone el DPC, no puede haber
ningn flujo de control entre controlados, ni entre terminadores y controlados en un
DPC.

31
Organizacin temporal
El DPC muestra los controladores en relacin con sus controlados, de tal manera que estos
ltimos resultan organizados temporalmente para satisfacer el comportamiento que se espera del
sistema. Dependiendo de la necesidad de secuenciacin de los procesos del sistema, as como
tambin de las posibilidades de concurrencia que tengan los controladores, el DPC puede requerir
uno o ms controladores.

Considerando dichas caractersticas, se puede analizar qu sucede con sistemas dentro del
espectro, desde el punto de vista de controladores que se requieren para un sistema que
representa n controlados:
Sistemas totalmente secuenciales: En este caso, bastara un nico controlador. Una
MEF, por consiguiente, es suficiente para activar secuencialmente los n controlados del
sistema.
Sistemas totalmente concurrentes: En este caso, dependiendo de la capacidad de
concurrencia intracontrolador, podra ser necesario n controladores (sin concurrencia
interna), cada uno de los cuales se hara cargo de un controlado de manera concurrente
con los otros controladores. Si los controladores tienen concurrencia interna, entonces es
posible tener cualquier cantidad de controladores entre 1 y n.
Sistemas en parte secuencial y en parte concurrentes: Generalmente se requerira
una cantidad entre 1 y n controladores, de manera de atender aquellos controlados
secuencialmente al mismo tiempo que aquellos concurrentes.
Si se tiene dos controlados: Cmo saber si ocurren en secuencia o concurrentemente? Se
debe analizar si la realizacin de uno depende o no de que el otro se haya finalizado antes. La
dependencia se da a veces cuando el resultado de la realizacin de un controlado sirve al
controlador para decidir sobre la realizacin de otro controlado.

32
Captulo 8: Diagramas de interaccin
Con un DInt es posible responder a las siguientes preguntas:
Cul es la interaccin entre los componentes u objetos del sistema?
Cul es la cronologa de estas interacciones?
Qu intercambios de eventos son posibles entre los componentes del sistema?
Al ser un modelo de interaccin, naturalmente un DInt requerir del complemento de
modelos de comportamiento para tener la visin completa del sistema desde el punto de vista
dinmico.
Elementos comunes de los DInt
1. Componente: Representan unidades de comportamiento que interactan
con otros componentes de tal manera de atender la funcionalidad que se
espera del sistema.
2. Actor: Es un papel o rol que algo o alguien del entorno desempea con relacin al sistema. Se
puede entender al actor como un conjunto de actores reales o instancias que viven fuera del
sistema, pero que requieren interactuar de alguna forma con l
3. Mensaje: Es una solicitud de realizar algo que un emisor hace a un receptor. Al definir un
mensaje en los DInt, se debe tener en consideracin el emisor, receptor, operacin y
parmetros datos necesarios para que la operacin se realice del mismo.
Propsito del mensaje:
a) Informativo: Informa al objeto receptor de algo ya ocurrido en el mundo real
para que ste se actualice.
b) Interrogativo: Consulta por alguna informacin que actualmente posee el
receptor.
c) Imperativo: Solicita al receptor que realice algo en el futuro inmediato.
Flujo de control: Los mensajes pueden dividirse, de acuerdo a los tiempos involucrados
en el emisor y receptor, en:
a) Procedimentales: Representa la idea de llamada a un procedimiento.
Corresponde a la idea de un mensaje sincrnico, es decir, aquel en donde el emisor
espera a que el receptor complete la operacin.
b) Plano: Representa un paso dentro de un procedimiento, es decir, sirve para
mostrar mensajes en secuencia, sin preocuparse si estos son sincrnicos o
asincrnicos.
c) Asncrono: Representa un mensaje que no espera respuesta del receptor.
d) De retorno: Representa la respuesta correspondiente a un mensaje
procedimental. Este tipo de mensaje puede omitirse.
Para los efectos de simplificacin del modelado de SI, se adoptan los mensajes
procedimentales. As la interaccin entre objetos se da en forma sincrnica y
bidireccional, lo que significa que:
Slo un emisor puede enviar de a un mensaje a la vez

33
 El emisor espera a que el receptor acepte el mensaje
Como consecuencia, slo un receptor recibe de a un mensaje a la vez
Si la interaccin es asincrnica, entonces un emisor puede emitir un mensaje y
continuar su propio hilo de control, sin tener que esperar un retorno de parte
del receptor.
Anidamiento de mensajes: Existe cuando, dada la ocurrencia de un mensaje inicial,
se emite uno o ms mensajes dependientes llamados anidados y se reciben sus
correspondientes retornos antes del retorno del mensaje inicial.

Diagrama de Comunicacin
El DCom sirve para mostrar un conjunto de interacciones entre componentes, en forma
topogrfica, para un contexto situacional determinado. Entre sus elementos exclusivos se
encuentra:
1. Va de comunicacin: Es un conducto o medio bidireccional establecido entre emisor y
receptor para poder enviar y recibir mensajes. Se dice que establecen una asociacin de
conocimiento entre emisores y receptores, en el sentido que le permite a cada uno conocer la
existencia del otro, de tal manera de poder dirigirle mensajes.
Un mensaje no puede fluir sin una va de comunicacin
2. Numeracin de mensajes: En el DCom es posible enumerar los mensajes con el propsito
de mostrar la secuencia en que se emiten:
El primer mensaje, que origina toda la secuencia, no se enumera
El orden de los mensajes sigue los nmeros naturales
Si existen mensajes anidados, se anexa una nueva secuencia usando la notacin punto
decimal (por ejemplo: 1.1, 1.2, 1.21, 1.22, 1.3,)

De acuerdo con la figura presentada, los mensajes y retornos

ocurren en la siguiente secuencia: mensaje m1, mensaje m2,
mensaje m3, retorno m3, retorno m2, mensaje m4, mensaje
m5, retorno m5, mensaje m6, retorno m6, retorno m4,
retorno m1.

Diagrama de Secuencia
Los DSec muestran un conjunto de interacciones entre componentes, en forma cronolgica,
para un contexto temporal delimitado. Entre sus elementos exclusivos se encuentran:

34
 Lnea de vida y caja de activacin:
Lnea de vida: Representa la vida del componente o actor durante
la interaccin, como un transcurso del tiempo
Caja de activacin: Representa el periodo, dentro de la lnea de
vida, durante el cual el componente se encuentra activo a causa de
una interaccin.
Los componentes se activan, por tanto, cuando reciben un mensaje procedimental
y terminan la activacin cuando responden finalmente a este mensaje. Adems, durante la
activacin, el componente puede emitir mensajes a su vez.
La secuencia de los mensajes puede apreciarse en el hecho de que cada mensaje
se representa un poco ms abajo que el anterior, indicando con esto que ocurre un
tiempo despus.
Mediante la longitud relativa de las cajas de activacin entre un componente emisor y
un componente receptor, se puede reconocer el anidamiento de mensajes.
Diagrama de secuencia avanzado
Algunos elementos propios del DSec son:
1. Invariantes de estado: Representan el estado en que debe permanecer un componente
durante una interaccin. Se entiende como una restriccin en el sentido de que el componente
no puede sufrir un cambio de estado a propsito de la recepcin y/o emisin de un mensaje.
Notacin: Estados sobrepuestos a las cajas de activacin.
2. Reutilizacin de interacciones: En el DSec es posible reutilizar porciones de interaccin.
Esta reutilizacin es posible gracias a los marcos:

Marco: Es un contexto porttil para un diagrama, que permite la

reutilizacin de los diagramas.

Al insertar un marco en un DSec, se tiene la ocurrencia de interaccin que es

referenciada en ese DSec. Para esto se utiliza el encabezado ref, teniendo como
contenido el nombre del diagrama reutilizado.
Por simplicidad en las figuras slo se muestra el marco si ste es efectivamente
reutilizado.
3. Fragmentos combinados: La idea bsica es representar la lgica de interaccin en forma
ms detallada. Los denominados fragmentos o fragmentos de interaccin, son porciones de
interaccin que pueden combinarse de diferentes maneras para permitir modelar un sistema.
Fragmento combinado: Conjunto de fragmentos de interaccin relacionados por
medio de los operadores de interaccin.
Operadores de interaccin: Es un mecanismo para agrupar fragmentos de
interaccin. Entre los principales estn:
a) alt: Indica que los fragmentos son alternativos, dependiendo del valor de
verdad de una condicin o guardia.

35
 b) opt: Indica que el fragmento de interaccin puede o no ocurrir, es decir, es
opcional (para ocurrir la condicin asociada debe ser verdadera).
c) par: Indica que los fragmentos de interaccin son concurrentes o paralelos. En
este caso no se requieren condiciones.
d) neg: Indica que el fragmento de interaccin no debe ocurrir, es decir, es un
fragmento negado.
e) loop: Indica que el fragmento de interaccin es realizado repetidamente. El
nmero de veces es determinado por los parmetros del operador o por una
condicin.
Los fragmentos combinados son recursivos, en el sentido que un fragmento combinado
puede contener, a su vez, otros fragmentos combinados y, adems, pueden utilizarse un
conjunto de ocurrencias de interaccin (cuadros de reutilizacin).

DCom versus DSec

Criterio DCom DSec

nfasis En la comunicacin, en trminos de una En la secuencia, en trminos temporales

superficie (topografa). (cronologa)

Diagramacin Ms flexible ya que puede crecer Ms rgido ya que crece unidimensionalmente

bidimensionalmente (por la derecha)

Flujo de mensajes Por vas de comunicacin Entre cajas de activacin de las lneas de vida

Secuenciacin Slo con mensajes numerados Presentada grficamente

Particionamiento No existe Por medio de fragmentos combinados

Reutilizacin No existe Por medio de ocurrencias de interaccin

mbito til para contextos situacionales. Puede

aplicarse a todo un sistema sin numerar til para contextos temporales delimitados
mensajes.

Equivalencia Puede convertirse en un DSec equivalente, Puede convertirse en un DCom equivalente

si los mensajes estn enumerados.

Mensajera avanzada en los DInt

1. Mensajes iterados: Representan la situacin en que un mismo mensaje es enviado repetidas
veces. En los DInt, esta situacin se nota con un asterisco * antepuesto al nombre del
mensaje. En el caso en que cada mensaje repetido sea enviado a un objeto distinto de la
misma clase, puede mostrarse mltiples receptores apilados.
En el caso de necesitar repetir un par de mensajes juntos y no por separados, es posible
agruparlos bajo un operador de interaccin loop.

36
2. Auto-mensajes: Un objeto puede enviar un mensaje a s mismo. Esto significa que puede
solicitar realizar una de las operaciones que el objeto dispone, con el fin de completar alguna
tarea encomendada.
3. Mensajes condicionados: Un objeto puede enviar dos o ms mensajes que pueden ser
excluyentes entre s. La condicin, que permite decidir cul de los mensajes es enviado, puede
o no representarse (tambin sirve para mensajes opcionales). En cuanto a su notacin, en los
DSec se anotan en forma diagonal, mientras que en el DCom se agregan las letras a, b, c... a
la numeracin de los mensajes para indicar que son alternativos.
Centralizacin/Descentralizacin del control
Los DInt, como modelos de interaccin, soportan cualquier grado de
centralizacin/descentralizacin. Esto quiere decir que no es necesario que algn objeto de control
centralice todas las interacciones, as como tampoco es necesario distribuir el control
uniformemente entre los objetos involucrados.
Cuando la interaccin es centralizada, entonces el comportamiento tambin se centraliza:
El objeto que centraliza todos los mensajes tiene un comportamiento ms complejo; el
resto tiene un comportamiento trivial.
Cuando la interaccin es descentralizada, el comportamiento tiende a desconcentrarse
tambin.
El modelo centralizado encapsula la lgica de interaccin en el controlador: El objeto que
centraliza todos los mensajes es el nico que conoce cul es la lgica propia de la solicitud
de una orden. De esta forma, los objetos restantes tienen un mayor grado de reutilizacin,
en el sentido que pueden ofrecer sus operaciones en otros contextos diferentes.
En situaciones que no existe un componente que centralice las interacciones, es posible
introducir un objeto que asuma dicho rol.
Modelo semi-centralizado: El modelo de interaccin puede asumir controladores locales.
Es recomendable para describir la interaccin entre objetos.
Diagrama de interaccin global
Los DInt son especialmente tiles para representar contextos situacionales o temporales
delimitados; sin embargo, se vuelven poco prcticos a la hora de requerir representar la interaccin
de todos los componentes del sistema, an cuando el DCom pueda servir parcialmente. El DIG sirve
para este propsito al combinar el flujo de control del DAct, con la especializacin de mensajes del
DSec.
El DIG ofrece una visin ms macro de las
interacciones del sistema, organizndolas
temporalmente como un DAct. An cuando los
elementos organizados pueden ser interacciones y
ocurrencias de interacciones, es ms frecuente slo
trabajar con estas ltimas como una forma de
jerarquizar la complejidad del modelo.

37
Captulo 9: Diagrama de Flujo de Datos
El DFD es un modelo predominantemente funcional. Con l, es posible responder a las
siguientes preguntas-tipo:
Cules son los procesos que presenta el sistema?
Cul es la transformacin de flujos de datos de entrada en flujos de datos de salida?
Qu flujos y depsitos de datos internos son necesarios en el sistema?
El DFD es un modelo que se complementa con una especificacin de procesos. Este
complemento debe ser equilibrado de tal manera de que la complejidad del diagrama sea
comparable al detalle de la especificacin.
Componentes de un DFD
1. Proceso: Es una transformacin semntica de uno o ms flujos de datos
de entrada en uno o ms flujos de datos de salida. Su nombre debe ser
representativo de la funcin de conversin que ste realiza, por lo que se
recomienda utilizar un verbo activo seguido de un objeto.

2. Flujo de datos: Es un conducto o va de comunicacin por donde fluyen elementos de datos

de un mismo tipo (es decir, que pertenecen a un mismo bloque de datos). El nombre del flujo
de datos debe representar adecuadamente el significado del mismo y no el medio que contiene
el flujo o que implementa la comunicacin del bloque de datos.
Flujos de datos y la transformacin semntica: Antes de definir la relacin entre
la transformacin semntica llevada a cabo por un proceso y los flujos de datos, es
necesario revisar tres conceptos asociados a estos ltimos:
Semntica del flujo de datos: Representa el significado que el flujo de
datos tiene dentro del contexto del DFD.
Composicin del flujo de datos: Representa los componentes relacionados
que definen el flujo de datos. Por ejemplo, el flujo de datos movimiento
producto puede estar compuesto por un cdigo producto, un tipo de
movimiento y la cantidad asociada.
Valoracin del flujo de datos: Representa la ocurrencia especfica del flujo
de datos (una instancia).
A continuacin se presentan los tres casos en que puede ocurrir una
transformacin semntica:
a) Misma composicin y misma valoracin: En este caso slo cambia el
significado del flujo de datos de entrada al de salida, sin que se altere ni su
composicin ni su valoracin.

38
 b) Misma composicin y diferente valoracin: En este caso el flujo de datos
no se ve alterado en su composicin, pero s en su valoracin.

c) Diferente composicin y diferente valoracin: Los flujos de datos de

entrada pueden ser muy diferentes en trminos del tipo de datos.

Flujos de datos mltiples:

Paralelos: Es perfectamente posible que exista ms de un flujo de datos entre
dos procesos. Esto puede deberse a que los tipos de datos son distintos y/o
porque ocurren en distintos momentos del tiempo.
Excluyentes: Ocurren cuando existen tipos de datos que no pueden fluir
simultneamente. Estos flujos de datos pueden representarse en forma
separada o pueden fundirse siempre y cuando sean generados bajo un nico
criterio (por ejemplo, los flujos crdito aprobado y crdito reprobado
pueden ser fundidos en estado crdito). Cabe destacar que no se utiliza
ninguna notacin especial para indicar esta exclusividad (slo se documenta en
un DD).
Divergentes: Un flujo de datos puede tener mltiples destinos (por ejemplo,
puede servir de entrada a ms de un proceso). Estos flujos pueden
corresponder a dos casos:
a) Generacin de copias: El flujo de datos es auto-multiplicado tantas
veces como sea necesario. Grficamente, se entiende de que se trata de
una generacin de copia al colocar slo el nombre en el flujo de datos
comn y no en sus ramas.
b) Descomposicin de flujo de datos: El flujo de datos es dividido en
parte, cada una de las cuales es dirigida a un destino diferente.
Cabe destacar que no es necesario introducir un proceso para la
generacin de flujos de datos divergentes, ya que en ambos casos
no existe una transformacin semntica.
Flujos de datos y procesos: Con relacin a los flujos de datos, los procesos de un
DFD no indican:
Si solicitan los flujos de datos de entrada, o estos llegan cuando ocurran;
Si generan los flujos de datos de salida bajo pedido, o los generan por una
decisin propia;

39
 Si combinan todos o algunos de los flujos de datos de entrada para generar
alguno o todos los flujos de datos de salida.
En definitiva, el DFD no muestra cmo el proceso combina sus flujos de datos de
entrada, para generar sus flujos de datos de salida. Este detalle corresponde a la EP.
Un DFD no muestra ningn tipo de ordenamiento temporal, ni la frecuencia de ocurrencia
de los flujos de datos de entrada y, por ende, de los procesos. En este sentido, los
procesos de un DFD pueden entenderse, en general, como asincrnicos, es decir, se
realizan en tiempos independientes unos con otros.
3. Depsito de datos: Es un conjunto de bloques de datos del mismo tipo
que se encuentran en un reposo relativo. En otras palabras, los depsitos
corresponden a almacenamientos temporales requeridos por los procesos.
Un depsito de datos es representado en un DFD, por la necesidad de comunicacin de
datos entre procesos que pueden operar en distintos momentos del tiempo.
Acceso a los depsitos: Los depsitos de datos son accedidos por medio de flujos de
datos, los cuales pueden ser en ambos sentidos.
Acceso desde un depsito: Significa la recuperacin de un solo bloque de
datos; varios bloques de datos; partes de uno o varios bloques de datos. Dado
que por los flujos de datos slo pueden transitar bloques completos de datos
de un mismo tipo, para el ltimo caso mencionado, se entiende que el proceso
efectivamente recibe el bloque completo, pero slo utiliza las partes que
necesita (es recomendable etiquetar el flujo con el nombre de aquello que
especficamente se est consultando).
Un rasgo que caracteriza los flujos de datos desde un depsito, es que
nunca destruyen o modifican la valoracin del depsito que acceden.
Finalmente, cabe destacar que los depsitos de datos son pasivos, es
decir, no tienen ninguna iniciativa con respecto a los accesos de consulta,
simplemente esperan a que un proceso decida accederlos copiando datos de su
valoracin.
Acceso hacia un depsito: Significa la alteracin del depsito por medio de
la creacin, eliminacin o modificacin de bloque(s) de datos. El rasgo
caracterstico de los flujos de datos hacia un depsito es que siempre alteran
de alguna forma la valoracin del depsito al que acceden.
Accesos desde/hacia un depsito: Significa que el proceso,
separadamente, recupera partes o bloque(s) de datos y altera el depsito.
Flujo de datos neto: Se utiliza en caso de que se consulte el depsito
slo con el propsito de actualizarlo. El sentido del flujo de datos, por
consiguiente, ser slo hacia el depsito.

40
4. Terminador: Es un elemento externo al sistema con el cual existe comunicacin. Los
terminadores pueden recibir y/o emitir flujos de datos hacia el sistema, as como tambin
pueden comunicarse con ste por medio de depsitos.
Es importante no confundir al terminador con algn manipulador, transportador o medio
por el cual la comunicacin se hace efectiva. El terminador es quien realmente origina un flujo
de datos de entrada al sistema o a quien est destinado un flujo de salida. Tambin es el
terminador el que consulta un depsito de datos actualizado por el sistema, o actualiza un
depsito consultado por el sistema.
Debe representarse el flujo de datos entre terminadores en un DFD?
En caso de que sea relevante para el sistema dicha comunicacin, entonces ser
necesario extender los lmites del mismo, a fin de incorporar total o parcialmente uno o
ms terminadores, para que as el flujo de datos en cuestin pase a formar parte del
sistema.
Correctitud del DFD
Identificacin de procesos: Los nombres asignados a los procesos deben ser lo ms
representativos posible de la funcin de conversin que realizan (se debe cuidar que stos no
sean demasiado genricos). Por otra parte, los procesos tambin pueden ser enumerados de
manera secuencial; sin embargo, dicha enumeracin no implica ningn orden temporal de
realizacin de los procesos.
Flujos de control: Son utilizados con el propsito de activar procesos, por lo que no portan
datos. Un DFD no representa los flujos de control, por lo que si se identifican flujos de esta
naturaleza, deben eliminarse del modelo.
Consistencia lgica: En trminos de la consistencia lgica interna de los DFD, se deben:
Eliminar los procesos tipo agujeros negros o generacin espontnea
Etiquetar todos los procesos, flujos de datos y depsitos
Revisar los depsitos que slo tienen consultas o actualizaciones: Si en un DFD se
identifican depsitos en estas condiciones, se deben analizar para agregar aquellos
accesos faltantes o verificar que son depsitos que estn en los lmites y sus
consultas/actualizaciones son realizadas externamente.
Aspectos avanzados del DFD
DFD Fsico y Lgico: Los DFD pueden utilizarse para reflejar aspectos de implementacin de
un sistema, as como tambin para reflejar aspectos esenciales o conceptuales del mismo.
DFD Fsico: Representa la forma en que se realiza un sistema en la realidad. Un DFD
se dice fsico, por tanto, si usa referentes de implementacin de un sistema para los
procesos, flujos y depsitos de datos. Son tiles cuando son usados como modelos
descriptivos, para efectos de la validacin por los usuarios y para aumentar la
comprensin del sistema por parte del modelador.

41
 DFD Lgico: Un DFD se dice que es lgico si enfoca los aspectos funcionales del
sistema independiente de referentes fsicos. Interesa qu hace el proceso, no quin o
qu se encarga de hacerlo; qu datos fluyen, no qu medio o formato tienen; y qu
datos son almacenados, no qu estructuras de registro se han implementado o los
modos de acceso que existen.
Dado un DFD fsico, existe slo un DFD lgico equivalente; sin embargo, dado un DFD
lgico, pueden proponerse muchos DFD fsicos alternativos.
Complejidad en los DFD: Frente a la situacin de muchos depsitos con posibilidad de
flujos de datos de accesos cruzados, puede optarse por una representacin que abstraiga el
detalle de los depsitos individuales en uno solo ms abstracto y agregado. Por otro lado,
cuando existen procesos que tiene muchos flujos de datos, es posible agrupar algunos de
estos en nuevos flujos de datos ms abstractos, los cuales debern etiquetarse lo ms
significativamente posible (el criterio ms frecuente para agrupar es el de colocar juntos
aquellos flujos que tienen un mismo destino). Finalmente, se recomienda que un DFD contenga
entre 5 y 9 procesos, para que as pueda ser fcilmente comprendido en su totalidad por un
lector del modelo.
Jerarquizacin del DFD
La idea bsica es agrupar conjuntos de procesos en sperprocesos y construir un DFD ms
abstracto para ellos. Este proceso de agregacin puede volver a aplicarse, de forma recursiva,
hasta llegar a un DFD que contiene un nico proceso: el Diagrama de Contexto.
Reglas de balanceo:
Flujos de datos: Es importante mantener una equivalencia entre los flujos que entran
y salen de un proceso, con respecto al diagrama que describe con ms detalle dicho
proceso. Un aspecto importante de destacar es que, al pasar de un diagrama a otro,
los orgenes y destinos de los flujos de datos de un proceso no son repetidos en el
diagrama que lo representa.
Procesos en DFD:
El diagrama n descompone al proceso n.
Los subprocesos o procesos del diagrama n se enumeran correlativamente a
partir de 1 en forma decimal: n.1, n.2, n.3
Depsitos de datos:
Un depsito de datos se representa, en un diagrama dado, siempre que dos o
ms procesos o terminadores lo usen en ese diagrama.
No se representa un depsito de datos en un diagrama si es accedido por un
solo proceso, salvo que el proceso sea elemental.

42
 Construccin de DFD jerarquizados:
a) Descomposicin funcional: Es un mtodo de construccin top-down, es decir, se
construyen los DFD desde los niveles abstractos hacia los niveles ms detallados. Su
aplicacin consiste en los siguientes pasos:
1. Identificar las principales funciones o procesos que conforman el sistema y
representarlos en un Diagrama 0.
2. Descomponer recursiva y funcionalmente cada uno de los procesos del Diagrama 0.
3. Detener la descomposicin funcional en forma arbitraria, dependiendo del nivel de
detalle que estime necesario el modelador.
4. Construir finalmente el Diagrama de Contexto.
Debilidad: La descomposicin funcional requiere mucho de la experiencia del
modelador, de su imaginacin para encontrar los subprocesos y de un amplio
conocimiento acerca del sistema que est modelando.
b) Agregacin por datos: Es un mtodo de construccin botton-up, es decir, se
construyen los DFD desde los niveles detallados hacia los niveles ms abstractos, bajo el
criterio de agrupar procesos en torno a depsitos de datos. Consta de los siguientes pasos:
1. Identificar los procesos elementales que acceden a los depsitos de datos
necesarios para el sistema.
2. Agregar, agrupando los procesos que acceden a los mismos depsitos de datos, de
forma recursiva. Incluir en las agregaciones los procesos relacionados por flujos de
entrada o de salida que no acceden a depsitos.
3. Detener la agregacin por datos cuando se alcance el Diagrama 0.
4. Construir finalmente el Diagrama de Contexto.
No obstante lo anterior, se pueden producir conflictos cuando existen procesos que
acceden a ms de un depsito de datos. Para esto, existen las siguientes recomendaciones:
Se debe analizar los accesos que el proceso tiene con cada depsito y privilegiar la
agregacin con el grupo asociado al depsito en orden de preferencia:

En caso de que el proceso tenga accesos de un mismo tipo, se debe optar por el
mayor nmero de accesos detallados.

43
 En todo otro caso se puede optar por cualquiera, privilegiando algn sentido de
agrupacin funcional.
Debilidad: An cuando puede ser ms ventajoso usar esta estrategia en vez de la
descomposicin funcional, no ofrece guas claras para poder definir cules son los
procesos elementales a modelar.
c) Particionamiento por estmulos: Es un mtodo end-to-end: Los DFD se construyen
de acuerdo a los estmulos recibidos por el sistema y utilizando una combinacin de las
estrategias anteriores.
Un estmulo consiste en cualquier evento que se recibe del entorno y que provoca
alguna accin por parte del sistema. Cabe destacar que los estmulos pueden portar o no
flujos de datos; ocurrir en cualquier momento o con regularidad; y afectar o no la memoria
del sistema.
La aplicacin de la estrategia de Particionamiento por estmulos consiste en los
siguientes pasos:
1. Identificar los estmulos a los cuales el sistema debe responder.
2. Construir un diagrama por cada estmulo, para representar qu procesos realiza el
sistema para generar la respuesta correspondiente.
3. Si es necesario, descomponer funcionalmente aquellos procesos resultantes ms
complejos.
4. Agregar por datos de manera recursiva. Incluir procesos relacionados por entradas
o salidas que no acceden a depsitos.
5. Detener la agregacin cuando se alcance el Diagrama 0.
6. Construir finalmente el Diagrama de Contexto.
Consideraciones finales: Se recomienda que la jerarqua resultante en los DFD sea lo ms
homognea posible, as como tambin se sugiere tener como mximo un nivel de diferencia de
profundidad en la jerarqua (vase pgina 369).
Aplicacin de criterios de calidad
Minimalidad: Se recomienda representar porciones de funcionalidad que sean comunes a
dos o ms procesos en un nuevo proceso.
Expresividad: Se refleja en un DFD cuando se opta por dividir o expandir un proceso
complejo, pero sin recurrir a una descomposicin funcional en un diagrama de nivel
inferior.
Simplicidad: Se refleja fundamentalmente en la condensacin de procesos, abstraccin de
depsitos de datos y fusin de flujos de datos.

44
Captulo 10: Especificacin de Procesos
La EP tiene como propsito:
Describir qu sucede en cada uno de los procesos elementales del DFD.
Definir lo que debe hacerse para convertir los flujos de datos de entradas en los de salida.
Representar en detalle la esencia o lgica del dominio del sistema.
La EP tiene un rol complementario al DFD: Abre los procesos elementales, considerados
como cajas negras en el DFD jerarquizado, y los especifica en detalle, transformndolos as en
cajas blancas.
Esencia de la especificacin
Una EP debe ser independiente de la implementacin del sistema; es decir, no debe
imponer decisiones de diseo de software o de procedimientos. Para realizarla, se debe responder
a la pregunta: Qu debe hacer el proceso?, ms que responder cmo el proceso realiza lo que
tiene que hacer. Tener claridad sobre la esencia del proceso permite expresar qu rol le cabe
desempear en el contexto del sistema, el cual puede ser implementado de muy distintas maneras.
Relacin entre el DFD y la EP
Existe una EP por cada proceso elemental en el DFD y viceversa. Adems, la EP de un
proceso elemental debe respetar su entorno local de acuerdo al DFD, es decir, debe considerar la
recepcin de todos sus flujos de datos de entrada, la emisin de todos sus flujos de datos de salida
y la consulta y/o actualizacin de todos los depsitos de datos que correspondan.
Ley de complejidad inevitable: Un nivel ms bajo de granularidad, implica que los
procesos elementales son ms numerosos y de menor tamao, por lo cual la EP promedio
ser ms simple y el DFD ms complejo. Por otra parte, un nivel ms alto de granularidad,
implica que el proceso elemental nico es de gran tamao, pero su EP es mucho ms
compleja, a la par que el DFD es simplsimo (slo el Diagrama de Contexto).
Pre y Post Condiciones
Las PPC establecen una relacin contractual entre el sistema y el proceso elemental que lo
compone, donde cada uno tiene un derecho y un deber:
El sistema debe asegurar el cumplimiento de las pre-condiciones para que el proceso
elemental pueda hacer su trabajo. El proceso, entonces, tiene el derecho a exigir las
pre-condiciones al sistema.
El proceso elemental debe asegurar el cumplimiento de las post-condiciones para el
sistema, una vez hecho su trabajo. El sistema, entonces, tiene el derecho a exigir las
post-condiciones de parte del proceso.
Para efectos de convencin, se muestran en negrita todos los datos que son referenciados
en las PPC, ya sean flujos de datos, depsitos de datos o elementos de datos. Los nombres de los
depsitos se anotan adems en mayscula y en plural acorde a los DFD.

45
 Pre-condicin: Es una condicin que debe ser verdadera para que el proceso elemental se
realice. Las pre-condiciones pueden categorizarse de manera no excluyente en:
Estmulo activador: Exige slo la ocurrencia del estmulo activador del proceso
elemental especificado. De esta forma, los flujos de entrada no son necesarios para
que el proceso se inicie, sino que forman parte de la realizacin del mismo.
Relaciones entre las entradas: Se requiere que las entradas del proceso cumplan
ciertas condiciones para que ste se inicie.
Relaciones entre entradas y depsitos: El proceso elemental requiere que las
entradas a recibir cumplan determinadas relaciones con respecto a los depsitos de
datos. Por ejemplo:
PRE-CONDICIN
Existe un pedido cliente con nmero de cuenta cliente que
corresponde a un nmero de cuenta cliente en el depsito CLIENTES.
Relaciones intra/inter depsitos de datos: El proceso elemental exige se den
ciertas relaciones dentro (intra) de depsitos de datos o entre (inter) ellos.
Post-condicin: Es una condicin que debe ser verdadera despus de que el proceso
elemental se haya realizado. Las post-condiciones pueden categorizarse de manera no
excluyente en:
Salidas generales: Slo indica cul es la salida generada por el proceso elemental.
Por ejemplo: Se emite una factura.
Relaciones entre entradas y salidas: El proceso elemental genera una salida
acorde con la entrada recibida.
Relaciones entre salidas y depsitos de datos: El proceso elemental resulta en
ciertas relaciones entre las salidas y los depsitos a los que accede.
Cambios en los depsitos de datos: Esta categora representa a las post-
condiciones que resultan en la alteracin de depsitos de datos.

Alternativas en las PPC: Suele suceder que

muchos procesos elementales requieran manejar
ms de una situacin, es decir, deben
considerarse alternativas con respecto a la
situacin considerada como estndar, normal o al
menos ms frecuente. Esto obliga a introducir
ms pares de PPC.

Secuenciacin de procesos: Dada las caractersticas de las PPC, es posible utilizarlas de tal
manera que permitan la secuenciacin de procesos elementales.

46
Captulo 11: Diagrama de Casos de Uso
Con un DCU es posible responder a las siguientes preguntas:
Cules son los requerimientos funcionales del sistema?
Qu funciones debe proveer al entorno?
Qu debe hacer el sistema para sus distintos usuarios?
El DCU se caracteriza por ser un diagrama que muestra qu hace el sistema sin indicar el
cmo lo hace. Los CU listan las funcionalidades del sistema, pero no indican el procedimiento que
cada uno lleva a cabo.
Componentes de un DCU
1. Sistema: Es un conjunto explcitamente delimitado de los CU internos provedos a los actores
externos. En otras palabras, un sistema es la frontera que separa lo que forma parte del mismo
de lo que se considera externo.
2. Actor: Es un papel o rol que algo o alguien del entorno desempea con relacin al sistema.
Los actores pueden clasificarse de acuerdo a tres criterios:
a) Participacin en el inicio de la interaccin:
Activo: Es el actor que toma la iniciativa e inicia la interaccin con el CU.
Pasivo: Es cualquier otro actor que interacta con el CU, pero no lo inicia.
b) Objetivo del actor con la interaccin en un caso de uso:
Primario o principal: Es el actor beneficiario del valor que genera el CU.
De apoyo o secundario: Es cualquier otro actor que interacta con el CU.
El actor principal es para quien el CU existe
Por convencin se representan los actores principales al lado izquierdo del
sistema y los secundarios al lado derecho.
c) Jerarqua de actores:
General: Es un actor construido por abstraccin a partir de actores
especializados en un rol comn general.
Especializado: Es un actor que posee un rol particular de un actor general.
El actor especializado hereda el rol de un actor general, es decir, tiene
implcitamente acceso a todos los CU que el general puede utilizar.
Lo anterior permite configurar una jerarqua de actores en donde, a
medida que se baja, mayor funcionalidad estar disponible para los
actores.
3. Casos de uso: Conjunto de actividades que no son identificadas ni representadas de
un sistema, que proporciona un valor identificable a un actor principal.

47
 El CU se justifica en trminos del actor principal al que le proporciona valor. Por
esto, un CU slo puede tener un nico actor principal.
El nombre de un CU representa su funcionalidad, y se define desde la perspectiva
del actor principal.
Escenario: Es una realizacin especfica de un CU, donde instancias de actores
involucrados intercambias datos y eventos con el sistema. Un escenario es,
entonces, una instancia de un CU.
Desde la perspectiva anterior, un CU es un conjunto de escenarios
posibles que tienen un objetivo comn para el actor principal.
Asociacin de comunicacin
La asociacin entre los actores y sus diferentes CU, representan una va de comunicacin
por el cual pueden transitar los datos y eventos entre ellos.
Un DCU muestra la funcionalidad del sistema sin consideraciones temporales de ningn
tipo: No indica si los CU se puede hacer en paralelo o requieren sincronizacin, y no indica que los
CU se realizan en alguna secuencia definida. No obstante lo anterior, es una buena prctica de
legibilidad el disponer ordenadamente de arriba hacia abajo los CU que eventualmente se realicen
en una secuencia.
Aspectos avanzados del DCU
Relaciones entre los CU:
1. Inclusin: Una relacin de inclusin existe cuando se extrae una porcin de funcionalidad
de un CU denominado base y se representa aparte en un CU denominado incluido.
Tiene como objetivo evitar la representacin redundante de cierta porcin de
funcionalidad: El CU incluido es una factorizacin de porciones comunes de
funcionalidad de varios CU base.

La realizacin del CU incluido slo es posible si es hecha a partir de un escenario

de su correspondiente CU base, ya que no es posible instanciar
independientemente un CU incluido.
Tambin es posible que exista un CU incluido para un nico CU base. Esta situacin
puede darse cuando:
a) Se desea representar explcitamente una porcin relevante de la
funcionalidad del CU base (a criterio del modelador)
b) Se estima que el CU incluido es potencialmente compartible

48
 Es importante destacar que un CU incluido es un caso particular del concepto de
CU, ya que entrega valor a los CU base de los cuales forma parte y no directamente a un
actor principal. Por esta razn, ms bien contribuye parcialmente a la generacin de valor
de los CU base.
Slo puede tener asociados actores pasivos secundarios
2. Extensin: Una relacin de extensin existe cuando se agrega una porcin adicional
condicionada de funcionalidad, en forma de un CU denominado extensor, a la funcionalidad
de un CU denominado base.
No se modifica en lo absoluto la funcionalidad del CU base, ya que la extensin se
agrega condicionalmente como un extra al CU base. De esta forma, el CU extensor
interrumpe al CU base, cuando la condicin no representada en el DCU es
verdadera, para poder realizarse y, una vez que haya concluido, se retorna al CU
base en el punto que se abandon.

El CU base y el CU extensor son distintos y se realizan por separado; no existe una

relacin de inclusin, ya que ningn CU forma parte del otro.
El CU extensor, al ser condicionado, no necesariamente participar de un escenario
del CU base.
A diferencia de la inclusin, el CU extensor no est subordinado a un CU base, por
lo que podra ser instanciado separadamente. En este sentido, al ser un CU por
derecho propio, el CU extensor puede ser realizarse por medio del CU base, o por
medio de una iniciacin directa de un actor activo.
Puntos de Extensin: Es el punto, dentro de la funcionalidad del CU base, donde
es evaluada la condicin que puede implicar la realizacin de un CU extensor.
3. Generalizacin: Una relacin de generalizacin existe cuando es posible distinguir
funcionalidad general que reside en un CU denominado general, de una variacin o caso
particular de esta funcionalidad general que reside en un CU denominado especializado.
El CU especializado hereda del CU general su funcionalidad, sus relaciones con
otros CU y sus actores. Adems, puede extender o modificar esta funcionalidad
heredada, puede participar de otras relaciones o agregar nuevos actores a los del
CU general. De esta forma, un CU especializado genera valor por s mismo.
El conjunto de CU general y especializados constituye una jerarqua de CU,
donde las funcionalidades ms generales se representan arriba en la jerarqua y los
casos particulares se ubican abajo en la jerarqua.

49
 CU general abstracto: CU general que carece de toda funcionalidad. Los CU
especializados denominados concretos poseen toda la funcionalidad, heredando
las relaciones con otros CU y los actores del CU general abstracto.

Jerarquas de Actores y de CU:

En la figura, el actor Servicio tcnico empresa tiene acceso al CU
Entregar soporte tcnico, lo que incluye tambin al CU especializado
Entregar soporte in situ. Por otra parte, el actor Servicio tcnico
contratista slo tiene acceso a Entregar soporte tcnico in situ.

Patrn CRUD
Un patrn es un modelo predefinido como solucin estandarizada. Si un actor requiere
crear, consultar, actualizar y eliminar informacin, y estas operaciones son breves y simples, es
posible definir un nico caso de uso del tipo CRUD que las abstraiga.
Aplicacin de criterios de calidad
1. Criterio de Minimalidad: La minimalidad busca eliminar la redundancia en un modelo. En el
caso de jerarquas de actores y de CU, la redundancia se puede dar cuando algn actor o CU
herede algo ms de una vez.
La relacin de inclusin entre CU tiene como propsito original el evitar redundancia
de la funcionalidad en dos o ms CU. Es decir, se logra minimalidad cuando se extrae
funcionalidad comn de dos o ms CU y se representa como un CU incluido.
2. Criterio de Expresividad: En trminos de expresividad del CU, es posible transformar
relaciones de inclusin y de extensin en generalizaciones, y agregar relaciones de inclusin.
Una forma de lograr jerarquas es transformar dos o ms CU base que posean varios
CU incluidos en comn, en una jerarqua con un CU general que rena las inclusiones
comunes.
Una relacin de extensin se puede transformar en una generalizacin al hacer que el
CU especializado asuma la funcionalidad del CU base ms la del CU extensor.
En los casos en que los actores participen puntualmente en un CU, o cuando se tenga
un CU extensor (en un punto de extensin), se debe analizar el CU en cuestin para
verificar si es posible distinguir una porcin en la funcionalidad, generando un CU
incluido, que aloje la participacin del actor o que contenga el punto de extensin para
el CU extensor.
3. Criterio de simplicidad: La simplicidad en los modelos se refiere a la posibilidad de tener un
menor nmero de componentes, relaciones y propiedades. Para la simplicidad en un DCU, es
posible eliminar CU incluidos, extensores y especializados colgantes:
Un CU incluido colgante es un CU cuya nica razn de existencia es servir como
inclusin a un nico CU base.

50
 Un CU extensor colgante es un CU cuya nica razn de existencia es servir como
extensin a un nico CU base. En otras palabras, dicho CU no es inicializado por ningn
actor activo, sino slo por medio del CU base.
Un CU especializado colgante es un CU del ltimo nivel de una jerarqua de CU,
que no tiene actores asociados especficos, ni ninguna relacin especfica con otros CU.
Procedimiento de construccin
El procedimiento descendiente (top-down) es el ms utilizado, ya que se orienta de lo
externo a lo interno; es decir, comienza desde los actores hacia los CU. Los pasos son los que se
indican a continuacin:
1. Construir una lista con todos los actores posibles para el sistema.
2. Identificar, para cada actor, los CU en los cuales pueda participar como principal o
secundario. Utilizar para esto el cuestionario presentado ms adelante.
3. Si es necesario, los actores pueden organizarse en jerarquas. Esto es ms evidente cuando
se est asociando los actores a los CU.
4. Relacionar los CU en forma preliminar, sujeto a modificaciones producto de la
documentacin y de las transformaciones de los criterios de calidad.
5. Documentar todos los CU del DCU.
6. Aplicar las transformaciones para mejorar la minimalidad, expresividad y simplicidad del
DCU.
7. Corregir las relaciones entre actores y entre CU, de acuerdo a los pasos 5 y 6.
Cuando se tiene una lista de actores, se debe utilizar el siguiente cuestionario para poder
identificar la participacin que tengan en algn CU:
Cules son las tareas que le competen al actor en el sistema?
Debe el actor crear, consultar, actualizar y/o eliminar algn tipo de informacin en el
sistema?
Debe el actor informar al sistema de algo?
Se le debe informar al actor de los cambios que suceden en el sistema?

51
Captulo 12: Documentacin de Casos de Uso
Los principales propsitos de la DoCU son:
Representar los requerimientos principalmente funcionales que debe satisfacer el
sistema, con un nivel de detalle mayor que el DCU.
Describir o documentar la interaccin que ocurre entre el sistema y los actores del CU.
Mostrar la organizacin temporal de la interaccin entre el sistema y los actores
del CU.
Indicar explcitamente los flujos de datos y eventos entre el sistema y los actores del CU.
Idealmente esta descripcin debe ser independiente de la implementacin, poniendo
nfasis en lo que debe hacer el sistema, por sobre la forma de cmo debe hacerlo.
Qu se debe esperar que incluya una DoCU? Toda DoCU debiera indicar al menos:
Objetivo del CU: Qu se propone lograr con el CU? Qu valor debiera generar y a quin?
Inicio: Cundo y qu actor inicia el CU?
Fin: Cundo termina exitosamente el CU?
Interaccin entre actores y CU: Qu intercambios o dialogo se produce entre los actores y
el sistema en el CU?
Cronologa de las interacciones: Cul es la secuencia de interacciones que debiera darse
entre los actores y el sistema en el CU?
Situaciones alternativas y excepcionales: Qu opciones pueden presentarse en el CU?
Relacin entre el DCU y la DoCU
Existe una DoCU por cada CU que exista en el DCU y viceversa. Esto significa que todos los
CU de un DCU deben documentarse, independiente de los roles que desempeen: Base, incluido,
extensor, general o especializado.
Desde el punto de vista de la DoCU, el DCU se puede entender como un mecanismo para
particionar y organizar toda la documentacin necesaria para el sistema.
Ley de complejidad inevitable: Un nivel ms bajo de granularidad implica que los
CU son de un tamao relativamente menor, lo cual significa que la DoCU promedio es
ms simple, pero a cambio el DCU es ms complejo. La complejidad, por tanto, no
puede evitarse: Slo puede distribuirse de diferentes formas entre el diagrama y la
documentacin.
Documentacin completa de CU
Posee las siguientes caractersticas:
Se presenta como una planilla en texto sin uso de tablas
No posee estructuras binarias. Las decisiones de este tipo se representan por medio de
escenarios alternativos.
Puede usar estructuras de control del tipo seleccin mltiple y repeticin:
a) La seleccin mltiple permite seleccionar una accin entre un conjunto de 3 o ms
opciones, de acuerdo a un igual nmero de condiciones excluyentes entre s.

52
 HACER CASO
CASO cliente selecciona girar dinero:
1. Sistema verifica saldo.
2. Sistema autoriza giro y actualiza saldo.

CASO cliente selecciona consultar saldo:
4. Sistema despliega saldo.
FIN CASO
b) La repeticin permite repetir un conjunto de acciones de acuerdo al cumplimiento o no
de una condicin:
PARA condicin de repeticin:
Acciones repetidas
FIN PARA
No se justifica realizar una estructura de control de repeticin para una sola accin;
basta con enunciar la repeticin en la misma accin.
Pasos son enumerados estrictamente
Plantilla de DoCU completa
Caso de uso: Nombre del CU
Objetivo: Descripcin del objetivo, en trminos del valor que ofrece al actor principal
mbito
Actor principal
Actores secundarios
Pre-condicin: Condicin verdadera antes de realizar CU (para que ste se realice)
Garantas mnimas: Lo mnimo que es posible asegurar aunque el CU no logre terminar exitosamente
Post-condicin: Condicin verdadera al finalizar exitosamente el CU
Inicio: Actor activo del CU
Escenario Principal: Es la lgica positiva del CU, es decir, es la secuencia de pasos
necesarios para realizar exitosamente el CU. Debe comenzar con el paso El CU se inicia
cuando y finalizar con el paso El CU termina.
Escenario alternativo: Se generan como alternativas lgicas con respecto a la secuencia
ideal del escenario principal.

Nx: Alternativa x del paso N del escenario principal

Ejemplo:
6a. Cliente es cliente frecuente:
6a1: Sistema solicita identificacin del cliente
6a1: Cliente proporciona identificacin

6a5: Cliente confirma los datos. Regresar al paso 7.
Excepciones: Situaciones anmalas o de error referidas a pasos del escenario principal.
Posee la misma notacin que un escenario alternativo.
Puntos de extensin: Opcional
Observaciones

53
Construccin de Escenario y Excepciones
Es altamente recomendable construir los escenarios y
excepciones del DCU en forma de espiral: Construir primero
todos los escenarios principales de todos los CU, despus seguir
con los escenarios alternativos de los CU y finalmente todas las
excepciones de los CU. Lo anterior asegura un menor esfuerzo
de documentacin y una mejor consistencia en general.
Relaciones de inclusin y extensin entre CU
La forma de invocar un CU incluido es: Incluye nombre del CU incluido
La DoCU extensor se debe definir en forma separada de la DoCU base, pero consistente con
ella en trminos de la condicin del punto de extensin.
Slo es posible la extensin como un escenario alternativo o excepcin completos, ya que stos
son regulados por condiciones. No puede haber una combinacin de pasos e invocacin a un
CU extensor en el escenario principal, ni en un escenario alternativo o excepcin.
Relaciones de generalizacin entre CU
La DoCU especializado hereda de la DoCU general. La convencin N.n establece que los
pasos del escenario principal del CU especializado hacen referencia numrica a los pasos del CU
general de la siguiente forma:
N: Implica que el paso N del CU especializado sobrescribe el mismo paso N del CU
general.
N.n: Implica que los pasos N.n del CU especializados son adicionados al paso N del CU
general (esta regla se puede combinar con la anterior).
Si un paso N del CU general no es referenciado de ninguna de las formas anteriores en el
CU especializado, entonces es heredado sin cambios. La nica excepcin es el paso final
de trmino del CU, que se conviene sobrescribir siempre para terminar el escenario
principal del CU especializado.
Convencin HEN:
H: Implica que el paso es heredado del CU general
E: Implica que el paso es heredado, pero adems es modificado (especializado)
en el CU especializado.
N: Implica que es un paso nuevo a los pasos heredados
Estos smbolos se anotan entre [] al trmino de cada paso del escenario principal
del CU especializado, referenciando los pasos heredados y el nombre del CU general. Por
ejemplo: [H paso 3, CU Negociar precio]

54
Procesos de Negocios
Un proceso de negocio es el conjunto organizado de actividades interfuncionales que
colectivamente crean valor para un cliente. Dentro de sus rasgos caractersticos se encuentran:
Lgica de realizacin repetible: Est definida la organizacin de las actividades
Iniciado por un estmulo: Reacciona frente a un evento relevante que ocurre en el
entorno.
Tiene su tiempo de ciclo propio: Su periodo de realizacin comienza con el estmulo y
termina con una salida.
Consume recursos: Requiere diversos tipos de recursos para la realizacin de las
actividades.
El cliente del proceso de negocios es un rol que se entiende como el beneficiario del valor
generado. Puede ser desempeado por una persona, grupo de personas, empresa, institucin o
incluso por otro proceso.
Las definiciones del cliente y del proceso de negocios son mutuamente dependientes
Caractersticas Necesarias de un Proceso de Negocio

Un proceso de negocios, para ser considerado como tal, debe:

1. Presentar dos o ms actividades:
Varias actividades, de diferentes especialidades, son aplicadas para completar el
proceso de negocio.
Todo proceso de negocio posee una lgica positiva, es decir, una organizacin
temporal de las actividades que asegure la generacin exitosa de valor.
2. Crear valor para algn cliente: El proceso de negocios deben proporcionar algo til,
importante o deseable para un cliente. Este valor, en consecuencia, es el que motiva al
cliente a demandar el proceso de negocio.
3. Cruzar barreras funcionales: Sus participantes concurren desde diferentes funciones en
la realizacin del proceso. Las actividades, por tanto, requieren diferentes especializaciones
que residen en distintas funciones de la organizacin, o incluso en distintas organizaciones.
En nuestra sociedad, la creacin de valor es por definicin multidisciplinaria

55
Definicin Bsica de un Proceso de Negocio
Objetivo: En trminos del valor generado al cliente
Cliente: Receptor principal del valor
Estmulo: Qu o quin inicia el proceso
Funciones: Responsables involucrados en la realizacin del proceso
Actividades: Conjunto de tareas componentes
mbito o contexto: Relacin con otros procesos o stakeholders
Lgica: Organizacin temporal de las actividades
Control: Quin o cmo se controla el proceso
Por qu disear negocios y sistemas basados en procesos?
Visin ms permanente que la estructura funcional
nfasis en actividades internas cooperativas ms que competitivas
Mayor facilidad de medir desempeo
Mayor visibilidad del valor proporcionado al cliente
Tipos de Procesos
Los procesos de negocio pueden clasificarse de acuerdo a la experticia requerida:
1. Procesos medulares: Tambin denominados crticos o primarios, incorporan experticia
nica y central de la organizacin para generar productos y/o servicios a los clientes.
2. Procesos de apoyo: Tambin denominados suplementarios o secundarios, facilitan la
operacin de otros procesos, ya sea medulares o de apoyo. Sus clientes, por consiguiente,
son otros procesos.
Jerarqua de Procesos
Cadenas de valor o macroprocesos: Son los procesos de gran escala que se inician con
los ciclos de vida de productos/servicios.
Procesos: Componen los macroprocesos, y pueden dividirse en subprocesos.
Subprocesos: Subconjuntos arbitrarios de actividades dentro de un proceso
Actividades: Tareas atmicas de procesos y subprocesos
Identificacin de Procesos de Negocio
Enfoque tradicional: El proceso de negocio se inicia con un estmulo, es decir, mediante un
evento proveniente de su entorno. Como consecuencia, se gatillan actividades organizadas
dentro de un marco temporal, el cual constituye el tiempo de ciclo del negocio. Se concluye con
la entrega de valor al cliente: Se define quin recibe qu valor del proceso.
El proceso de negocios emerge, por consiguiente, de la coordinacin, organizacin y/o
integracin de las actividades:
Se debe identificar las funciones y las actividades bajo su responsabilidad
Se aplica un enfoque de descomposicin funcional

56
 Es una visin fcilmente sesgada por la forma en que est implementada la lgica del
proceso.
Enfoque de entidades de negocio: Bajo este enfoque, el proceso de negocios es entendido
como un conjunto de actividades que produce o transforma una o ms entidades de negocio,
hasta alcanzar uno o ms estados valorados por el cliente. Su visin, por consiguiente, es
guiada por el concepto de ciclos de vida de entidades de negocio.
El proceso de negocios se inicia con la creacin de una instancia de la entidad de negocios.
Luego, las actividades componentes ocurren en las transiciones de estado de dicha entidad,
para finalmente concluir con l o los estados valiosos para el cliente.
Para la entidad de negocios el modelador debe:
Identificar sus estados y transiciones
Representar su ciclo de vida con un modelo de comportamiento
El enfoque de entidades de negocio consta de los siguientes pasos:
1. Identificar la o las entidades de negocios centrales al proceso de negocio (paso ms
difcil).
2. Establecer el ciclo de vida de las entidades: Todos los estados valiosos y transiciones
autorizadas.
3. Derivar actividades a partir de las transiciones de estado (una transicin puede
significar una o ms actividades).
4. Asignar las actividades a los actores participantes (definir responsabilidades).
Ventajas del enfoque:
Se minimiza el sesgo de la implementacin funcional actual del proceso
Comprensin facilitada: El ciclo de vida aglutina las actividades del proceso
Perturbaciones, excepciones y alternativas incorporadas en el modelo del ciclo de vida.
Actividades no estn limitadas por funciones existentes (ms independencia de la
implementacin).
Definicin de roles, como ltimo paso, entrega ms libertad para redisear los
procesos.

57
Modelamiento de Procesos de Negocio
El modelamiento de procesos de negocio tiene como propsito representar la organizacin
temporal de las actividades que constituyen un proceso de negocio.
Diagrama de procesos con UML
El enfoque convencional UML asume representar el contexto de los procesos mediante DCU
y su lgica a travs de DAct por cada CU.
Contexto para procesos de negocios:
El concepto de CU es anlogo a la concepcin de procesos de negocio:
CU: Conjunto de actividades de un sistema que proporciona un valor identificable a un
actor principal.
Proceso de negocio: Conjunto organizado de actividades interfuncionales que
colectivamente crean valor para un cliente.
Los actores del CU se entienden como participantes de un proceso de negocio: El actor
principal es el cliente receptor del valor del proceso, mientras que los actores secundarios son
las funciones o roles participantes.
Los CU iniciados directamente por actores principales representan los procesos de
negocio.
Relaciones entre CU:
Muestran organizacin de la funcionalidad de los procesos de negocio
El CU incluido y CU extensor corresponden a subprocesos
El CU incluido se justifica como subproceso reutilizado o no en ms de un proceso
El CU extensor puede ser un proceso de negocio, siempre que sea iniciado
directamente y tenga su propio actor principal.
Las jerarquas de CU mantienen su significado
Lgica del proceso de negocio:
Los DAct sirven al propsito de representacin lgico de un proceso de negocio: Muestran
una secuencia de actividades con soporte para comportamiento condicional y concurrente. Sus
carriles y particiones sirven para representar los participantes responsables de realizar las
actividades, mientras que su jerarquizacin sirve para representar subprocesos que pueden o
no obedecer las relaciones entre CU.
Diagramas de procesos con BPMN
Dentro de los objetivos del BPMN se encuentran el proveer una notacin grfica fcil de
usar para modelar procesos de negocio y el permitir la representacin de distintos niveles de
detalle en los diagramas de proceso.

58
Categorizacin de procesos:
Orquestacin: Implica una perspectiva de coordinacin centralizada de las actividades de
un proceso. Es la forma ms comn y usada por omisin.
Colaboracin: Implica una interaccin sincronizada, sin control centralizado, entre dos o
ms procesos participantes. Se utilizan mensajes para representar la comunicacin.
Elementos de un BPMN:
1. Tarea: Actividad atmica que no se describe en otro diagrama
2. Subproceso: Representa una actividad compuesta, la cual debe describirse con otro
diagrama. Puede representarse de manera colapsada o expandida, y puede ser o no
reutilizada.
3. Nodo excluyente: Es un operador lgico XOR. Abre dos o ms condiciones mutuamente
excluyentes que definen alternativas de secuencia.
4. Evento de trmino: Representa el fin de un hilo o camino dentro del proceso. Puede
generar algn resultado.
5. Flujo de secuencia: Define el orden temporal de las actividades, eventos y nodos del
diagrama. Los flujos de secuencia no cruzan piscinas.
Eventos e interrupciones:
Evento de mensaje de inicio: El proceso se inicia con la recepcin de un mensaje, el
cual debe originarse en otro proceso participante (otra piscina).
Interrupcin de actividades: Las actividades pueden ser interrumpidas por eventos
representados en sus lmites.
Evento intermedio temporizador: Muestra la dependencia del tiempo en un
proceso.
Mltiples eventos:
Nodo excluyente de eventos: Utilizado cuando una decisin depende de dos o ms
eventos.
Evento intermedio de mensaje: El mensaje ocurre slo entre procesos participantes
(entre piscinas). Puede ser de emisin (representado en negro) o recepcin
(representado en blanco).
Grupos: Sirven slo para destacar o categorizar elementos del diagrama
Piscinas y carriles:
Flujos de mensajes: Define la comunicacin entre procesos participantes (distintas
piscinas). Slo se muestra en las colaboraciones.
Piscina: Representa un proceso participante de una interaccin con otros procesos.
Puede contener un proceso orquestado o ser una caja negra.

59
 Carril: Es una particin de una piscina que representa una responsabilidad dentro del
proceso.
Flujos de documentos:
Objetos de dato: Representa datos y documentos del proceso. Se muestra con una
asociacin como entrada o salida de una actividad.
Asociacin: Conecta elementos de un diagrama. Puede ser dirigida o no
Seales de un proceso:
Evento intermedio de seal: Representa la emisin o captura de seales internas a
un proceso. La seal no es dirigida.
Evento intermedio de comportamiento: Representa un evento que se puede
emitir o capturar dentro de flujos de secuencia.
Flujos condicionados:
Nodo inclusivo: Representa decisiones con ms de un flujo de secuencia saliente. Es
el operador lgico OR. Puede ser de divisin o unin.
Nodo paralelo: Representa varios flujos salientes bajo el operador lgico AND. Es
anlogo a los nodos Fork y Join del DAct.
Flujo de secuencia condicional: Es un flujo de secuencia con una condicin interna
que slo est disponible desde una actividad o un nodo excluyente o inclusivo.

60
Sistemas de Informacin de Apoyo a los Procesos de Negocio

Es posible distinguir dos propsitos de los SI de apoyo a los procesos de negocio:

1. SI de apoyo a la operacin: Tpicamente representados como un participante de la
lgica del proceso.
2. SI de apoyo al control: Tpicamente representados por medio de modelos de control por
retroalimentacin.
Los modelos del proceso de negocio (lgica y control) sirven para:
Contextualizar los SI
Definir sus requerimientos funcionales para efectos de modelar los SI
Explicitar la dependencia que tienen los sistemas respecto a los procesos, es decir, que los
sistemas sirven para apoyar al proceso.
Guiar el desarrollo de los sistemas
Identificar las TI ms apropiadas.
Sistema de informacin de apoyo a la operacin
Apoya la operacin del proceso mediante la automatizacin de actividades, por lo que est
fundamentalmente orientado a mejorar la productividad del proceso. Es un habilitador para la
implementacin de la operacin del proceso.
Idealmente, el sistema debe representarse como un participante (en un carril) dentro del
modelo de lgica del proceso. En caso de ser as, ser posible observar las actividades
automatizadas y semi-automatizadas en las que participa, as como tambin la organizacin
temporal de ambos tipos de actividades.
Sistemas de informacin con UML:
Existe un problema de impedancia entre el BPMN y el DCU, por lo que se debe determinar
qu actividades del sistema constituyen un CU para el DCU (recordar que un CU es una
abstraccin que representa un conjunto de actividades).
Existen diversas tcnicas para construir un DCU a partir de diagramas de procesos:
Abstraccin de CU: Definir CU agrupando criteriosamente actividades del sistema
(implica una mayor dependencia del modelador).

61
 rbol de metas: Definir estados o metas que puedan reconocerse como resultados
intermedios para definir CU.
Anlisis de cohesin: Consiste en analizar la relacin entre las actividades para
determinar los mejores conjuntos que definan CU. Las cohesiones posibles para las
actividades son:
1. Funcional: Se pueden abstraer como una nica funcin bien definida, que genera
valor en el CU.
2. Secuencial: Usan los mismos datos en secuencia (dentro del CU).
3. Comunicacional: Usan los mismos datos de entrada y/o salida, sin importar la
secuencia.
4. Procedimental: Siguen un procedimiento controlado
5. Temporal: Se realizan en un mismo tiempo (dentro del CU)
6. Lgica: Pueden clasificarse en una categora general
7. Coincidental: Simplemente coinciden en el CU
Sistemas de informacin con AEM/ES:
Se puede interpretar una actividad del diagrama de procesos como un proceso del DFD
del sistema? No existe impedancia entre los modelos, pues las actividades pueden
fcilmente interpretarse como procesos elementales del DFD, jerarquizndolos por agregacin
por datos.
Sistemas de informacin con ED:
Qu relacin existe entre las actividades del sistema en el diagrama de procesos y los
ciclos de vida en las entidades dinmicas?
Naturalmente, se debe abordar desde la perspectiva del ciclo de vida de la entidad de
negocio y su relacin con el ciclo de vida de las entidades dinmicas. Con la delimitacin del
sistema dentro del proceso, entonces el ciclo de vida de la entidad de negocios incluye al
ciclo de vida de la entidad dinmica principal.
Si el diagrama de procesos se construy sin usar como base un modelo de ciclo de vida,
entonces se puede construir una por ingeniera reversa: Por ejemplo, identificar las actividades
que producen cambios de estado, como una transicin para el ciclo de vida de la entidad de
negocios.
Control de procesos de negocio
La gestin del proceso de negocio posee una visin desde el punto de vista de la
conduccin del proceso; realiza anlisis utilizando un modelo de control del proceso de negocio y
requiere de un SI de apoyo al control del proceso.

62
 Modelo de control:

Conduccin: Tarea de gestin del proceso

Operacin: Tarea de conversin del proceso
Sistema de informacin: Atenuador de variedad entre Operacin y Control, compuesto
por:
BD: Representacin de Operacin en trminos de datos
SGI: Conjunto de operaciones sobre los datos de la BD para generar informacin a la
Conduccin.
Relaciones:
Activacin: Conduccin descompone y asigna sub-objetivos a Operacin
Ajuste: Conduccin toma acciones correctivas sobre Operacin
Eventos: Hechos relevantes ocurridos en Operacin
Datos: Eventos registrados en la BD
Informacin: Mensaje

[Falta el resumen de las ltimas diapositivas]

63