INSTITUTO TECNOLGICO SUPERIOR

DE CALKIN EN EL ESTADO DE
CAMPECHE
CARRERA: INGENIERA INFORMTICA
DESARROLLO E IMPLEMENTACION
DE SISTEMAS DE INFORMACION
DOCENTE: Dra. Marlene Mndez Moreno

ALUMNO: CARLOS ALBERTO POOT

CHAN
MATRCULA: 4196
GRADO Y GRUPO: 6 A
"Los obstculos son esas cosas
espantosas
Que ves cuando apartas los ojos de la
meta."
Henry Ford

Calkin, Campeche a 19 de Abril del 2016

Tabla de contenido
2. Diseo De Sistemas........................................................................3

2.1 Diseo Estructurado De Sistemas................................................8

2.1.1 Conceptos Bsicos....................................................................9

2.1.2. Diagramas De Flujo De Datos................................................18

2.1.3 Aplicaciones Para Sistemas De Tiempo Real..........................31

2.2. Diagramas De Interaccin De Objetos......................................33

2.2.1. De Secuencia..........................................................................36

2.2.2. De Colaboracin.....................................................................40

Referencias........................................................................................49

2. DISEO DE SISTEMAS
El DISEO DE SISTEMAS toma los requerimientos de las funcionalidades de un
SI (entrada, procesamiento, salida, almacenamiento y control) identificadas en la
fase de anlisis y los sintetizan un nuevo proyecto de sistema.
Se cuenta con una especificacin preliminar de lo que el nuevo sistema de
informacin debe hacer y se tiene claro que es necesario realizar un nuevo
sistema: para arreglar los problemas del sistema actual y responder a las nuevas
necesidades y a las oportunidades para usar la informacin.
Existe mucha incertidumbre debido a que se concilian diferentes ideas de lo que
los usuarios consideran debera hacer el sistema, con las alternativas existentes
acerca del ambiente de aplicacin del nuevo sistema.

El Diseo del sistema es el proceso de describir, organizar y estructurar los

componentes del sistema. Tanto a nivel arquitectnico como a nivel detallado, con
la intencin de construir el sistema propuesto.
El diseo de ms alto nivel tambin es llamado: diseo general, arquitectnico o
conceptual.
Tambin es una actividad de modelaje.
La informacin modelada en la identificacin de los requerimientos se convierte
en modelos que representan la solucin.

ALTERNATIVAS DE ESTRATEGIA DE DISEO

Para concluir el proceso de anlisis, se debe trabajar en tomar estos requisitos
estructurados y transformarlos en varias estrategias de diseo, donde una de ellas
ser la que se seguir en la fase de diseo del ciclo de vida.

 ESTRATEGIA DE DISEO. Declaracin de alto nivel sobre el enfoque del SI a

desarrollar. Incluye la funcionalidad del sistema, el hardware y la plataforma de
software del sistema, y el mtodo para su adquisicin o desarrollo. La seleccin
de la mejor alternativa del diseo del sistema incluye al menos dos pasos bsicos:
Generacin de un conjunto comprehensivo de alternativas de estrategias de
diseo y, Seleccin de la mejor alternativa para el SI deseado, sobre la base de
todas las restricciones organizacionales, econmicas y tcnicas, que limitan su
desarrollo.

PROCESO DE SELECCIN DE LA MEJOR ALTERNATIVA DE ESTRATEGIA DE

DISEO
La configuracin de alternativas de estrategias de diseo de sistemas abarca los
siguientes procesos:
1) Dividir los requerimientos en conjuntos de capacidades, en un rango que vaya
de lo ms simple que los usuarios aceptaran (los requerimientos mnimos) hasta
lo ms elaborado y avanzado en sistemas que la compaa podra llegar a
desarrollar (incluye todas las caractersticas deseadas por todos los usuarios).
Alternativamente, combinaciones de diferentes conjuntos de capacidades podran
representar la posicin de aquellas unidades organizacionales que tienen
conflictos acerca de lo que el sistema debera hacer.
2) Enumerar los diferentes ambientes de implementacin (HW, SW, red) que
potencialmente podran ser usados para acometer los diferentes conjuntos de
capacidades.
3) Proponer diferentes maneras de acometer y desarrollar varios conjuntos de
capacidades con los diferentes ambientes de implementacin.

PROCESO DE SELECCIN DE LA MEJOR ALTERNATIVA DE ESTRATEGIA DE

DISEO

Los analistas pueden recomendar lo que ellos creen es la mejor alternativa, pero
el cuerpo gerencial (una combinacin de un comit y de los encargados de hacerle
seguimiento al desarrollo del proyecto de sistema) tomarn la ltima decisin
sobre cual estrategia de diseo de sistemas seguir.
Los documentos que deben surgir como resultado de la generacin de
alternativas de diseo de sistemas y, la seleccin de la mejor estrategia, son:
1) Por lo menos tres (3) estrategias de diseo de sistemas sustancialmente
diferentes para la construccin del nuevo SI.
2) La mejor estrategia de diseo para alcanzar el SI deseado.
3) La lnea base del Proyecto de planificacin para convertir la mejor estrategia de
diseo en un SI en plena operacin

GENERANDO ALTERNATIVAS DE ESTRATEGIAS DE DISEO

Cmo saber los lmites del posible espacio solucin? El equipo de analistas ya
tiene recolectada la informacin necesaria para identificar el espacio solucin.
Pero primero debe organizar sistemticamente la informacin. En este sentido,
existen dos (2) consideraciones:
La primera se refiere a los requerimientos del nuevo sistema que son
mandatorios; si alguno de ellos es olvidado, hace que la estrategia no tenga
sentido. Para comparar diferentes estrategias de diseo, los requerimientos del
sistema pueden ser divididos en tres categoras: mandatorios, esenciales y
deseados.
Las segunda se refiere a las restricciones para el desarrollo del sistema, tales
como: fechas de entrega del sistema, disponibilidad de recursos humanos y
financieros, elementos del sistema actual que deben conservarse, restricciones
legales y contractuales y, la importancia o dinmica del problema, ya que puede
limitar cmo adquirir el sistema (comprar vs. desarrollar). Tanto los requerimientos

como las restricciones deben ser identificados y clasificados en orden de

importancia.
PUNTOS A CONSIDERAR EN LA GENERACIN DE ALTERNATIVAS DE
ESTRATEGIAS DE DISEO
SELECCIN DE SOFTWARE OFF-THE-SHELF. Cuando se piensa comprar un
software off-the-shelf, hay que comparar el paquete de software y el proceso de
desarrollo de la misma aplicacin en casa, segn los siguientes criterios: costo,
funcionalidad, soporte del vendedor, viabilidad del vendedor, flexibilidad,
documentacin, tiempo de respuesta y facilidad de instalacin. Adems, hay que
recurrir a mtodos cuantitativos cuando se comparan distintos paquetes de
software.
HARDWARE Y SOFTWARE. Es necesario determinar si la plataforma de HW y
SW existente en la organizacin soporta el nuevo sistema o si es necesario
realizar mejoras de HW y/o adquisicin de SW (manejadores de bases de datos,
lenguajes de programacin, sistemas operativos, SW de red, generadores de
cdigo, entre otros). Esto tiene que ser parte esencial de las alternativas de
estrategias de diseo.

PUNTOS A CONSIDERAR EN LA GENERACIN DE ALTERNATIVAS DE

ESTRATEGIAS DE DISEO
IMPLEMENTACIN. Es necesario tener en cuenta los aspectos tcnicos y
sociales de la implementacin del nuevo SI como parte de las alternativas de
estrategias de diseo. Los gerentes y los usuarios deben conocer qu tiempo
tomar a implementacin, qu entrenamiento se requerir, cmo ser el impacto
en los procesos, qu nuevas habilidades sern necesarias, qu tan doloroso
ser el proceso.
ORGANIZACIONALES. El costo (financiero y humano), la forma en que la
gerencia ser soportada y, la aceptacin y uso que le darn los usuarios al nuevo
SI, son temas que las alternativas de estrategias de diseo no pueden dejar fuera.

No hay que olvidar que el SI a desarrollar est inmerso dentro de una organizacin
y que sta influye directamente sobre el uso y aprovechamiento del SI, as como el
funcionamiento de ste influye en el desempeo de la organizacin

2.1 Diseo estructurado de sistemas

El diseo estructurado de sistemas se ocupa de la identificacin, seleccin y
organizacin de los mdulos y sus relaciones. Se comienza con la especificacin
resultante del proceso de anlisis, se realiza una descomposicin del sistema en
mdulos estructurados en jerarquas, con caractersticas tales que permitan la
implementacin de un sistema que no requiera elevados costos de mantenimiento.
La idea original del diseo estructurado fue presentada en la dcada de los '70,
por Larry Constantine, y continuada posteriormente por otros autores: Myers,
Yourdon y Stevens.
El diseo estructurado es un enfoque disciplinado de la transformacin de qu es
necesario para el desarrollo de un sistema, a cmo deber ser hecha la
implementacin.
La definicin anterior implica que: el anlisis de requerimientos del usuario
(determinacin del qu) debe preceder al diseo y que, al finalizar el diseo se
tendr medios para la implementacin de las necesidades del usuario (el cmo),
pero no se tendr implementada la solucin al problema. Cinco aspectos bsicos
pueden ser reconocidos:
1. Permitir que la forma del problema gue a la forma de la solucin. Un concepto
bsico del diseo de arquitecturas es: las formas siempre siguen funciones.
2. Intentar resolver la complejidad de los grandes sistemas a travs de la
segmentacin de un sistema en cajas negras, y su organizacin en una jerarqua
conveniente para la implementacin.
3. Utilizar herramientas, especialmente grficas, para realizar diseos de fcil
comprensin.

Un diseo estructurado usa diagramas de estructura (DE) en el diseo de la

arquitectura de mdulos del sistema y adiciona especificaciones de los mdulos y
cuplas (entradas y salidas de los mdulos), en un Diccionario de Datos (DD).
4. Ofrecer un conjunto de estrategias para derivar el diseo de la solucin,
basndose en los resultados del proceso de anlisis.
5. Ofrecer un conjunto de criterios para evaluar la calidad de un diseo con
respecto al problema a ser resuelto, y las posibles alternativas de solucin, en la
bsqueda de la mejor de ellas. El diseo estructurado produce sistemas fciles de
entender y mantener, confiables, fcilmente desarrollados, eficientes y que
funcionan.
Objetivos Del Diseo Estructurado
"El diseo estructurado, tiende a transformar el desarrollo de software de una
prctica artesanal a una disciplina de ingeniera".

Eficiencia
Mantenibilidad
Modificabilidad
Flexibilidad
Generalidad
Utilidad

2.1.1 Conceptos Bsicos

Como alcanzar sistemas de mnimo costo
Cuando se trata con un problema de diseo, por ejemplo un sistema que pueda
ser desarrollado en un par de semanas, no se tienen mayores problemas, y el
desarrollador puede tener todos los elementos del problema "en mente" a la vez.
Sin embargo cuando se trabaja en proyectos de gran escala, es difcil que una

sola persona sea capaz de llevar todas las tareas y tener en mente todos los
elementos a la vez.
El diseo exitoso se basa en un viejo principio conocido desde los das de Julio
Cesar: Divide y conquistars.
Especficamente, diremos que el costo de implementacin de un sistema de
computadora podr minimizarse cuando pueda separarse en partes

manejablemente pequeas
solucionables separadamente.

Por supuesto la interpretacin de manejablemente pequea vara de persona en

persona. Por otro lado muchos intentos de particionar sistemas en pequeas
partes arribaron incrementos en los tiempos de implementacin. Esto se debe
fundamentalmente al segundo punto: solucionables separadamente En muchos
sistemas para implementar la parte A, debemos conocer algo sobre la B, y para
implementar algo de B, debemos conocer algo de C.
De manera similar, podemos decir que el costo de mantenimiento puede ser
minimizado cuando las partes de un sistema son:

fcilmente relacionables con la aplicacin

manejablemente pequeas
corregibles separadamente

Muchas veces la persona que realiza la modificacin no es quien diseo el

sistema.
Es importante que las partes de un sistema sean manejablemente pequeas en
orden de simplificar el mantenimiento. Un trabajo de encontrar y corregir un error
en una "pieza" de cdigo de 1.000 lneas es muy superior a hacerlo con piezas de
20 lneas. No solo disminuye el tiempo de localizar la falla sino que si la
modificacin es muy engorrosa, puede reescribirse la pieza completamente. Este
concepto de "mdulos descartables" ha sido utilizado con xito muchas veces.

Por otra parte, para minimizar los costos de mantenimiento debemos lograr que
cada pieza sea independiente de otra. En otras palabras debemos ser capaces de
realizar modificaciones al mdulo A sin introducir efectos indeseados en el mdulo
B.
Finalmente, diremos que el costo de modificacin de un sistema puede
minimizarse si sus partes son:

fcilmente relacionables con la aplicacin

modificables separadamente

En resumen, podemos afirmar lo siguiente: los costos de implementacin,

mantenimiento, y modificacin, generalmente sern minimizados cuando cada
pieza del sistema corresponda a exactamente una pequea, bien definida pieza
del dominio del problema, y cada relacin entre las piezas del sistema
corresponde a relaciones entre piezas del dominio del problema.

Como se logra el costo mnimo con Diseo Estructurado

Un buen diseo estructurado es un ejercicio de particionamiento y organizacin de
los componentes de un sistema.
Entenderemos

por

particionamiento,

la

subdivisin

de

un

problema

en

subproblemas ms pequeos, de tal forma que cada subproblema corresponda a

una pieza del sistema.
La cuestin es: Dnde y cmo debe dividirse el problema? Qu aspectos del
problema deben pertenecer a la misma pieza del sistema, y cuales a distintas
piezas?. El diseo estructurado responde estas preguntas con dos principios
bsicos:

Partes del problema altamente interrelacionadas debern pertenecer a la

misma pieza del sistema.

Partes sin relacin entre ellas, deben pertenecer a diferentes piezas del
sistema sin relacin directa.

Otro aspecto importante del diseo estructurado es la organizacin del sistema.

Debemos decidir cmo se interrelacionan las partes, y que parte est en relacin
con cual. El objetivo es organizar el sistema de tal forma que no existan piezas
ms grandes de lo estrictamente necesario para resolver los aspectos del
problema que ella abarca. Igualmente importante, es el evitar la introduccin de
relaciones en el sistema, que no existe en el dominio del problema.
El concepto de Cajas Negras
Una caja negra es un sistema (o un componente) con entradas conocidas, salidas
conocidas, y generalmente transformaciones conocidas, pero del cual no se
conoce el contenido en su interior.
En la vida diaria existe innumerable cantidad de ejemplos de uso cotidiano: una
radio, un televisor, un automvil, son cajas negras que usamos a diario sin
conocer (en general) como funciona en su interior. Solo conocemos como
controlarlos (entradas) y las respuestas que podemos obtener de los artefactos
(salidas).
El concepto de caja negra utiliza el principio de abstraccin. Este concepto es de
suma utilidad e importancia en la ingeniera en general, y por ende en el desarrollo
de software. Lamentablemente muchas veces para poder hacer un uso efectivo de
determinado mdulo, el diseador debe revisar su contenido ante posibles
contingencias como ser comportamientos no deseados ante determinados valores.
Por ejemplo es posible que una rutina haya sido desarrolla para aceptar un
determinado rango de valores y falla si se la utiliza con valores fuera de dicho
rango, o produce resultados inesperados. Una buena documentacin en tales
casos, es de utilidad pero no transforma al mdulo en una verdadera caja negra.
Podramos hablar en todo caso de "cajas blancas".

Los mdulos de programas de computadoras pueden variar en un amplio rango de

aproximacin al ideal de caja negra. En la mayora de los casos podemos hablar
de "cajas grises".
Comparacin entre las estructuras administrativas y el diseo estructurado
Uno de los aspectos ms interesantes del diseo de programas es la relacin que
puede establecerse con las estructuras de organizacin humanas, particularmente
la jerarqua de administracin encontrada en la mayora de las grandes
organizaciones.
Observemos por ejemplo el siguiente diagrama de organizacin de una empresa

A simple vista podemos apreciar que el presidente de la empresa tiene

demasiados subordinados, y consecuentemente su trabajo involucrar el manejo
de demasiados datos y la toma de demasiadas decisiones, demasiada
complejidad, que lo llevar a cometer posibles errores.
Podemos establecer una analoga con la estructura de programas y es razonable
pensar que un mdulo que tenga demasiados mdulos subordinados a quienes
controlar, sea sumamente complejo, y susceptible a fallas.
Veamos otro ejemplo

Podemos apreciar a simple vista que la tarea de los jefes A, X, Y, es relativamente

trivial y podra ser comprimida en una sola jefatura. Estableciendo una
comparacin con la estructura de programas, si tenemos un mdulo cuya nica
funcin es llamar a otro, y este a su vez a otro, el cual llama a uno que finalmente
realizar la tarea, los mdulos intermedios podrn comprimirse un nico mdulo
de control.
Podemos decir que en una organizacin perfecta, los administradores no realizan
ninguna tarea operativa. Su labor consiste en coordinar informacin entre los
subordinados y tomar decisiones. Los niveles inferiores son los que realizan el
trabajo operativo. Anlogamente, podemos argumentar que los mdulos de nivel
alto en un programa o sistema solamente coordinan y controlan la ejecucin de los
mdulos de menor nivel, quienes son los que realizan los cmputos y procesos
que el sistema requiere. Finalmente observaremos que los administradores
suministran a sus subordinados nicamente la informacin que estrictamente
necesitan. Anlogamente los mdulos inferiores solo deben tener acceso a la
informacin que necesitan, y no a otras.
El establecimiento de un paralelo entre las estructuras organizativas humanas y
los programas de computadora nos ser muy til en el estudio del diseo
estructurado.
Manejo de la complejidad

En principio diremos que escribir un programa "grande" generalmente lleva ms

tiempo que escribir un "pequeo". Esto es valedero si medimos "grande" y
"pequeo" en unidades apropiadas. Claramente, el nmero de instrucciones de un
programa no es una medida de complejidad ya que existe instrucciones ms
complejas que otras, y algoritmos ms complejos que otros. En realidad lo que
diremos es que es ms difcil resolver un problema difcil! , e intentaremos realizar
un anlisis sobre como disminuir la complejidad de un determinado problema.
Si asumimos que hemos podemos medir por algn mtodo la complejidad de un
problema P (no importa aqu que mtodo), diremos que la complejidad del mismo
ser M(P), y que el costo de realizar un programa que resuelva el problema P ser
C(P). Los enunciados previos respondern a la siguiente regla:
Dados dos problemas P y Q observaremos lo siguiente
Si M(P) > M(Q) entonces C(P) > C(Q)
Es decir el costo de resolver un determinado problema es directamente
proporcional al tamao del mismo.
Intentaremos tomar dos problemas separados y en lugar de escribir dos
programas, crear un programa combinado. Si juntamos los dos problemas,
obtendremos uno mayor que si tomamos los dos por separado. La razn
fundamental para no combinar los problemas, es que los humanos tenemos
inconvenientes para tratar adecuadamente grandes complejidades, y en la medida
que esta se incrementa somos susceptibles a cometer un mayor nmero de
errores. En virtud de esto podemos afirmar que
M(P+Q) > M(P) + M(Q)
y consecuentemente
C(P+Q) > C(P) + C(Q)
Siempre ser preferible crear dos piezas pequeas que una sola ms grande, si
ambas solucionan el mismo problema.

Este fenmeno no es solo vlida para el campo de la computacin. Es verdadero

en cualquier campo de la solucin de problemas (matemtica, fsica, etc.).
Complejidad en trminos humanos
En el punto anterior realizamos un anlisis sobre la incidencia de la complejidad
en los costos, y como manejarla a travs de la subdivisin de un problema en
problemas menores. Vimos que muchos de nuestros problemas en diseo y
programacin se deben a la limitada capacidad de la mente humana para lidiar
con la complejidad.
La cuestin ahora es:
Qu es lo complejo para los humanos?
En otras palabras:
Qu aspectos del diseo de sistemas y programas son considerados complejos
por el diseador?
Y por extensin
Qu podemos hacer para realizar sistemas menos complejos?
En primer trmino podemos decir que el tamao de un mdulo es una medida
simple de la complejidad. Generalmente un mdulo de 1000 sentencias, ser ms
complejo que uno de 10. Obviamente el problema es mayor ya que existen
sentencias ms complejas que otras.
Por ejemplo las sentencias de decisin son uno de los primeros factores que
contribuyen a la complejidad de un mdulo. Otro factor de importancia es el
"espacio" de vida o alcance de los elementos de dato, es decir el nmero de
sentencias durante las cuales el estado y valor de un elemento de datos debe ser
recordado por el programador en orden de comprender que es lo que hace el
mdulo.
Otro aspecto relacionado con la complejidad es el alcance o amplitud del flujo de
control, esto es el nmero de sentencias lexicogrficamente contiguas que deben

examinarse antes de encontrar un seccin de cdigo caja-negra con un punto de

entrada y un punto de salida. Es interesante notar que la teora detrs de la
programacin estructurada provee el medio de reducir este alcance a una mnima
longitud organizando la lgica en combinaciones de operaciones de "secuencia",
"decisin", e "iteracin".
Todas estas medidas reconocen que la complejidad de los programas percibida
por humanos, se ve altamente influenciada por el tamao del mdulo.
Tres factores, implcitos en el enfoque previo, han sido identificados como
afectando la complejidad de las sentencias:

la cantidad de informacin que debe ser comprendida correctamente.

la accesibilidad de la informacin.
la estructura de la informacin.

Estos factores determinan la probabilidad de error humano en el procesamiento de

informacin de todo tipo.
Mientras que la complejidad de todo tipo de sentencias de programas puede
evaluarse segn estos criterios, enfocaremos la atencin en aquellas que
establecen relaciones intermodulares.

2.1.2. Diagramas de flujo de datos.

Concepto

Los diagramas de flujos de datos (DFD), es una tcnica de modelizacin, que nos
muestra un sistema como una red de procesos conectados entre ellos por flujos y
almacenamientos de datos.
Es un modelo que proporciona en forma grfica el punto de vista funcional de un
sistema.
En sntesis, el Diagrama de Flujo de Datos describe:
-

Los lugares de origen y destino de los datos (los lmites del sistema),

Las transformaciones a las que son sometidos los datos (los procesos
internos),

Los lugares en los que se almacenan los datos dentro del sistema, y

Los canales por donde circulan los datos.

Los diagramas de flujo de datos fueron inventados por Larry Constantine, el

desarrollador original del diseo estructurado, basado en el modelo de
computacin de Martin y Estrin: "flujo grfico de datos".

Es importante tener en mente: los DFD no slo se pueden utilizar para modelar
sistemas de proceso de informacin, sino tambin como manera de modelar
organizaciones enteras, es decir, como una herramienta para la planeacin
estratgica y de negocios.
Componentes de un Diagrama de Flujo de Datos
Los componentes de un diagrama tpico de flujo de datos son:

Proceso.

Flujo.

Almacn.

Terminador.

Simbologa

Proceso:
Indican aquellos lugares dentro del sistema en donde la informacin (flujos de
datos) que ingresa se procesa o transforma. Es decir, son las funciones o
procedimientos que transforman entradas de datos en salidas de informacin.
Su nombre deber ponerse mediante una frase imperativa, que consistir
idealmente de un verbo activo seguido por una clusula objeto, cuanto mas simple
mejor.
El proceso se representa grficamente como un crculo. Los sinnimos comunes
son burbuja, funcin o transformacin.

Proceso
Flujo de datos:
Representa un transporte de paquetes de datos desde su origen hasta su destino,
es decir que representa una estructura de datos en movimiento de una parte del
sistema a otro.
Puede imaginarse como una tubera por donde se envan paquetes de datos, pero
deber tener una descripcin de su contenido la cual deber elegirse de forma que
sea lo ms til posible a los usuarios que revisen el DFD.
Se representa grficamente por medio de una flecha que entra o sale de un
proceso. El sentido de la flecha indica la direccin del flujo.

Flujo de datos

Almacn:
Representa un archivo lgico en donde se agregan o de donde se extraen datos.
Es una estructura de datos, pero esttica.
Puede ser fsicamente un archivo de tarjetas, una microficha, archivos de papel, o
un archivo en cinta o diskette.
Deber elegirse el nombre que sea ms descriptivo para el usuario, que identifique
los paquetes de datos que contiene.
Implica escritura, actualizacin o borrado de datos.
Implica lectura o recuperacin de informacin almacenada.

Almacenamiento
Terminador:
Representan fuentes (origen) o destinos externos de datos que pueden ser
personas, programas, organizaciones u otras entidades que interactan con el
sistema pero se encuentran fuera de su frontera.
Cuando el sistema que est bajo anlisis acepta datos de otro sistema o bien se
los provee, este otro sistema es un terminador.
El analista no puede cambiar ni los contenidos ni la forma de trabajo de un
terminador.
El terminador se representa grficamente como un
rectngulo.

Terminador

Componentes de un Diagrama de Flujo de Datos

Niveles de los Diagramas de Flujo de Datos
Los diagramas derivados de los procesos principales se clasifican en niveles, los
cuales son:

Nivel 0: Diagrama de contexto.

Nivel 1: Diagrama de nivel superior.

Nivel 2: Diagrama de detalle o expansin.

Caractersticas de los Niveles

Diagrama de Contexto: Nivel 0

En el diagrama de contexto solo se dibuja el proceso principal y los flujos entre

este y sus entidades externas.

Diagrama de Nivel Superior: Nivel 1

En el diagrama de nivel superior se plasman todos los procesos que describen al
proceso principal. En este nivel los procesos no pueden interrelacionarse
directamente, sino que entre ellos siempre debe existir algn almacenamiento o
entidad externa que los una.
Diagrama de Detalle o Expansin: Nivel 2
A partir del nivel 2 de detalle, los procesos pueden interrelacionarse directamente,
sin necesidad de almacenamiento que los una. Cabe destacar que en el nivel 1 y 2
siempre los procesos deben tener las entradas y las salidas dadas en el diagrama
de contexto.
Tipos de diagramas de flujo de datos
Los diagramas de flujo de datos son de dos tipos:
Diagramas fsicos de flujo de datos
Proporcionan un panorama del sistema en uso, muestra las tareas que se llevan a
cabo y como se hacen. Las caractersticas fsicas incluyen:

Nombre de personas

Nombre o formatos de documentos

Nombres de departamento

Archivo de maestro y de transacciones

Equipo y dispositivos utilizados

Ubicaciones

El empleo de estos diagramas es aconsejable por tres razones:

Para los analistas de sistema es ms fcil describir la interaccin entre los

componentes fsicos que comprender las polticas empleadas. De modo

que identifican las personas, lo que hacen, los documentos que inician las
actividades y el equipo para su procesamiento.

Los diagramas fsicos de flujos de datos son de utilidad para comunicarse

con los usuarios. Estos relacionan con facilidad a las personas, las
ubicaciones y los documentos ya que trabajan todos los das con estas
entidades (Los diagramas lgicos van a resultar abstractos para los
usuarios).

Los diagramas fsicos proporcionan un camino para validar o verificar el

punto de vista del usuario sobre la forma en que opera el sistema en uso.

Diagramas lgicos de flujo de datos

Proporcionan un panorama del sistema independiente de la implantacin, que se
centra en el flujo de datos entre los procesos sin considerar los dispositivos
especficos y la localizacin de almacenes de datos o personas en el sistema.
Los diagramas fsicos de flujos de datos, no son un fin en si mismos, sino son un
medio para describir la implantacin del sistema existente. El diagrama lgico es
un visin retrospectiva de la implantacin actual y proporciona la base para
examinar la combinacin de procesos, flujo de datos, almacenes de datos,
entradas y salidas sin importarnos los dispositivos fsicos, personas o aspectos de
control que caracterizan la implantacin.
As que el diagrama lgico se obtiene del diagrama fsico al llevar a cabo lo
siguiente:

Sealar los datos necesarios en este momento para un proceso, no

documentos que los contienen.

Indicar los flujos entre los procedimientos y no entre personas, oficinas o

localidades.

Eliminar herramientas y dispositivos.

Eliminar informacin de control.

Consolidar los almacenes de datos redundantes.

Eliminar los procesos innecesarios (v.gr los que no cambian los datos,
independientes de los dispositivos donde ocurren, los que representan un
proceso nico dentro del sistema).

Cuando se inicia el estudio de sistemas en un rea de la Organizacin, el analista

necesita obtener una visin del sistema. Primero los elementos fsicos: personas,
documentos, listados. No es difcil recordar lugares o personas importantes (' Este
trabajo lo realiza Prez ', ' La autorizacin del pago de facturas se realiza en el
departamento de contabilidad ', etc.). Los diagramas fsicos representan estos
elementos.
Una vez superada esta primera fase de conocimiento del sistema actual, es
necesario descifrar los aspectos ms importantes de cada actividad. Los
diagramas lgicos nos permiten describir los datos, procesos y eventos de forma
abstracta, ya que el analista debe conocer el trabajo que debe realizarse mas que
las personas que en la actualidad lo realizan. Los analistas generalmente
comienzan por la construccin de un modelo fsico por que los componentes
fsicos se pueden identificar realmente durante el anlisis y despus lo convierten
a un modelo lgico. Pero veamos como podemos hacer esto con un ejemplo:
Partamos del siguiente DFD fsico, donde podemos apreciar dos componentes
fsicos:

El encargado de recepcin, que recibe un pedido y lo verifica para

determinar si es del tipo que fabrica la organizacin. Si la respuesta es no,
el pedido no se acepta; si es s, pasa a la seccin de produccin.

La seccin de produccin, que comprueba si la mquina para hacer el

pedido est disponible. Si no, el pedido no se acepta; en otro caso, se
encargan los recursos para la produccin del pedido.

Durante la conversin, primero se pasan todos los procesos que hacen referencia
a actividades fsicas, en el ejemplo y enviar a la seccin de produccin.

El resto de los procesos fsicos se expanden despus dentro de sus funciones

lgicas. Para ello se toma cada proceso fsico, se busca qu es lo que hace y se
reemplaza por un DFD de funciones lgicas expandido que represente las
actividades de un objeto fsico. En la figura 19 podemos apreciar como el
encargado de recepcin se reemplaza por dos funciones que son registrar pedido
y comprobar tipo de pedido. De la misma forma seccin de produccin es
reemplazado por sus dos funciones comprobar recursos disponibles y encargar
recursos a produccin.

Despus se examina este ltimo DFD, y cualquier funcin comn o similar se

combina para formar un proceso de nivel ms alto que se convierte el DFD
superior, en la siguiente figura podemos apreciar como los procesos comprobar
pedido y comprobar recursos disponibles se combinan en uno slo pues tiene un
propsito similar dando como resultado el proceso comprobar factibilidad
produccin.
Tambin se aaden al nuevo DFD los procesos registrar pedido y encargar
recursos a produccin.

Pasos para la elaboracin de un Diagrama de Flujo de Datos

Debe de indicar claramente dnde inicia y dnde termina el diagrama.

Cualquier camino del diagrama debe de llevarte siempre a la terminal de fin.

Organizar los smbolos de tal forma que siga visualmente el flujo de arriba
hacia abajo y de izquierda a derecha.

No usar lenguaje de programacin dentro de los smbolos.

Centrar el diagrama en la pgina.

Las lneas deben ser verticales u horizontales, nunca diagonales.

No cruzar las lneas de flujo empleando los conectores adecuados sin hacer
uso excesivo de ellos.

No fraccionar el diagrama con el uso excesivo de conectores.

Solo debe llegar una sola lnea de flujo a un smbolo. Pero pueden llegar
muchas lneas de flujo a otras lneas.

Las lneas de flujo deben de entrar a un smbolo pro la parte superior y/o
izquierda y salir de l por la parte inferior y/o derecha.

Evitar que el diagrama sobrepase una pgina; de no ser posible, enumerar

y emplear los conectores correspondientes.

Usar lgica positiva, es decir, realizar procesos cuando es verdadera la

condicin y expresar las condiciones de manera clara (por ej., "no es a =/=
de b" ==> "a=b").

Comentar al margen nicamente cuando sea necesario.

Reglas adicionales para el dibujo de DFD:

Ya se han identificado la mayor parte de los lineamientos que se siguen para el
dibujo de los DFD, he aqu algunas ms:

Cualquier flujo de datos que abandone un proceso debe estar basado en

los datos que entran al proceso

Todos los flujos de datos tienen un nombre que refleja los datos que fluyen
entre procesos, almacenes de datos, fuentes o destinos

Solo deben entrar al proceso, los datos necesarios para llevarlo a cabo

Un proceso no debe saber nada de ningn otro en el sistema, es decir debe

ser independiente, la nica dependencia que debe existir es aquella basada
en sus propios datos de entrada y salida

Los procesos siempre estn en continua ejecucin, no se inician ni tampoco

se detienen. Los analistas siempre deben suponer que un proceso est listo
para ejecutar su trabajo

La salida de los procesos puede tomar una de las siguientes formas

Flujo de datos con informacin aadida por el proceso (i.e: una anotacin a
una factura)

Una respuesta o cambio en la forma de los datos (i.e: un cambio en la

forma de expresar las utilidades -de a $-)

Un cambio de condicin (i.e: de autorizado a no autorizado)

Cambio de contenido (i.e: integracin o separacin de la informacin

contenida en uno o ms flujos entrantes de datos)

Cambios en la organizacin (i.e: separacin fsica o redondeo de datos)

La norma comn es definir cada nivel inferior en trminos de 3 a 7 procesos

para cada proceso de nivel superior, si son necesarios ms detalles se
puede hacer en el siguiente nivel.

Los almacenes y flujos de datos que son relevantes solo para el interior del
proceso, son ocultados hasta que el proceso se extiende con mayor detalle

Los datos que fluyen hacia los procesos experimentan cambios. Por
consiguiente, el flujo de datos de salida tiene un nombre diferente al de la
entrada; si no se efecta algn cambio en el flujo de datos, entonces cul
es la finalidad del proceso?

En cuanto a los nombres de los procesos lo ms apropiado es escoger un

verbo y un sujeto que reciba la accin y no nombre generales que no digan
nada. Si un nombre de proceso es vago o complejo tal vez se deba
subdividir el proceso an ms.

2.1.3 APLICACIONES PARA SISTEMAS DE TIEMPO REAL

Los Sistemas Operativos de tiempo real son la plataforma para establecer
un sistema de tiempo real ya que en los SOTR no tiene importancia el usuario,
sino los procesos.
Algunos ejemplos de Sistemas Operativos de tiempo real son:

VxWorks,

Solaris,

Lyns OS

Spectra

Por

lo

regular Sistema

Operativo de

tiempo

real

suele

tener

la

misma arquitectura que un Sistema Operativo convencional, pero su diferencia

radica en que proporciona mayor prioridad a los elementos de control y
procesamiento que son utilizados para ejecutar los procesos o tareas.

El SOTR debe ser multitarea y permisible

Un SOTR debe poder asignar prioridades a las tareas

El SOTR debe proporcionar medios de comunicacin y sincronizacin entre

tareas

Un SOTR debe poder evitar el problema de inversin de prioridades

El comportamiento temporal del SOTR debe ser conocido

Clasificacin de los sistemas de tiempo real

Los sistemas de tiempo real pueden ser de dos tipos, esto es en funcin de su
severidad en el tratamiento de los errores que puedan presentarse:
Sistemas de tiempo real blandos o Soft real-time systems: estos pueden tolerar un
exceso en el tiempo de respuesta, con una penalizacin por el incumplimiento del
plazo. Estos sistemas garantizan que las tareas crticas se ejecutan en tiempo.
Aqu

los datos son

almacenados

en memorias no

voltiles,

no

utilizan tcnicas de memoria virtual ni tiempo compartido, estas tcnicas no

pueden ser implementadas en hardware.
Sistemas de tiempo real duros o Hard real-time systems: aqu la respuesta fuera
de trmino no tiene valor alguno, y produce la falla del sistema. Estos sistemas
tienen menos utilidades que los implementados por hard.

2.2. Diagramas de interaccin de objetos.

Qu es una Interaccin?
Es un esquema de intercambios de mensajes que se realizan para lograr un
propsito especfico es lo que se denomina una interaccin. Un mensaje es una
comunicacin unidireccional entre dos objetos, un flujo de objeto con la
informacin de un remitente a un receptor. Un mensaje puede tener parmetros
que transporten valores entre objetos. Un mensaje puede ser una seal o una
llamada.
DIAGRAMAS DE INTERACCIN

Conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden

enviar entre ellos. Estos

objetos interactan para realizar colectivamente los

servicios ofrecidos por las aplicaciones. En s, los diagramas de interaccin

muestran cmo se comunican los objetos.
La vista de interaccin describe secuencias de intercambios de mensajes entre los
roles que implementan el comportamiento de un sistema. Un rol clasificador, o
simplemente "un rol", es la descripcin de un objeto, que desempea un
determinado papel dentro de una interaccin, distinto de los otros objetos de la
misma clase. Esta visin proporciona una vista integral del comportamiento del
sistema, es decir, muestra el flujo de control a travs de muchos objetos. La vista
de interaccin se exhibe en dos diagramas centrados en distintos aspectos pero
complementarios: centrados en los objetos individuales y centrados en objetos
cooperantes.
Los diagramas de interaccin se utilizan para modelar los aspectos dinmicos de
un sistema, lo que conlleva modelar instancias concretas o prototpicas de clases
interfaces, componentes y nodos, junto con los mensajes enviados entre ellos,
todo en el contexto de un escenario que ilustra un comportamiento. En el contexto
de las clases describen la forma en que grupos de objetos colaboran para proveer
un comportamiento. Mientras que un diagrama de casos de uso presenta una
visin externa del sistema, la funcionalidad de dichos casos de uso se recoge
como un flujo de eventos utilizando para ello interacciones entre sociedades de
objetos.
El flujo de eventos de un caso de uso puede recogerse en una especificacin texto
acompaada de distintos escenarios especificados mediante diagramas de
interaccin (interaction diagrams), donde cada diagrama ser una visin grfica de
un escenario.
Todos los sistemas tienen una estructura esttica y un comportamiento dinmico, y
el UML proporciona diagramas para capturar y describir ambos aspectos. Los
diagramas de clases se usan para documentar y expresar la estructura esttica de

un sistema, es decir, las clases y sus relaciones. Los diagramas de estado y los
diagramas de interaccin describen el comportamiento de un sistema, para
demostrar cmo los objetos interactan dinmicamente en diferentes momentos
durante la ejecucin del sistema.
Los objetos dentro de un sistema se comunican unos con otros, envindose
mensajes. Un mensaje es justo una operacin donde un objeto llama a otro objeto.
As pues la dinmica de un sistema se refiere a cmo los objetos dentro del
sistema cambian de estado durante el ciclo de vida del mismo y tambin a cmo
dichos objetos colaboran a travs de la comunicacin. En el primer caso se utilizan
los diagramas de estado y los diagramas de actividad. En el segundo caso, la
comunicacin entre los objetos se representa mediante los diagramas de
interaccin, que a su vez agrupan a dos tipos de diagramas: secuencia y
colaboracin.
Los diagramas de interaccin son modelos que describen como grupos de
objetos colaboran para conseguir algn fin.
Estos diagramas muestran objetos, as como los mensajes que se pasan entre
ellos dentro del caso de uso
Los diagramas de interaccin capturan el comportamiento de un caso de uso.

ASPECTOS COMUNES EN UNA INTERACCIN

Objetos
Participantes en la interaccin.
Roles
Son las acciones de los objetos.
Enlaces
Conexin entre objetos.
Mensajes
Comunicacin entre objetos.

 Secuenciacin
Orden de los mensajes.

CARACTERISTICAS
Son tcnicas grficas para modelar el comportamiento dinmico del
sistema.
Son modelos que describen grupo de objetos que colaboran para conseguir
algn fin.
Estos diagramas muestran objetos, as como los mensajes que se pasan
entre ellos.

OBJETIVO
Describir el comportamiento dinmico del sistema.
Para la representacin precisa de las interacciones entre objetos.
Verificar la coherencia del sistema.

Pero, en esencia, su misin es localizar el comportamiento de los objetos.

UTILIDAD

Son muy tiles porque cada diagrama (casos de usos), ser una visin
grafica de un escenario.

Los diagramas de interaccin se utilizan para modelar los aspectos

dinmicos de un sistema, lo que conlleva modelar instancias concretas o
prototpicas de clases interfaces.

VENTAJAS

Son dinmicos.

Se sabe el tiempo de vida de un determinado objeto.

Representan Objetos y mensajes de objetos.

Son Isomorficos.

CLASIFICACIN

Diagrama de Colaboracin
Diagrama de Secuencia

2.2.1. De secuencia.
Los diagramas de secuencia muestran la interaccin de un conjunto de objetos a
travs del tiempo. Esta descripcin es importante porque puede dar detalle a los
casos de uso, aclarndolos al nivel de mensajes de los objetos existentes. Es
decir, nos proporciona la interaccin entre los objetos, que se sucede en el tiempo,
para un escenario especfico durante la ejecucin del sistema (por ejemplo,
cuando se utiliza un requisito funcional concreto).
Grficamente, un diagrama de secuencia es una tabla con dos ejes: el eje
horizontal muestra el conjunto de objetos y el eje vertical muestra el conjunto de
mensajes, ordenados en el tiempo.

Objetos

Los objetos se representan en el eje horizontal, y cada uno de ellos mediante un

rectngulo que contiene el nombre y la clase del objeto en el siguiente formato:
nombre del objeto: nombre de la clase.
En los diagramas de secuencia hay dos caractersticas que los distinguen de los
diagramas de colaboracin: lnea de vida y activacin de un objeto.
Lnea de vida
La lnea de vida de un objeto representa la existencia de un objeto durante un
cierto perodo de tiempo. Se dibuja mediante una lnea vertical discontinua desde
el rectngulo que contiene al objeto hasta la parte final del diagrama.
Activacin
La activacin de un objeto muestra el perodo de tiempo en el cual un objeto se
encuentra desarrollando alguna accin. Un objeto activado est bien ejecutando
su propio cdigo o bien esperando la vuelta de otro objeto al cual ha enviado
previamente un mensaje. Se dibuja como un rectngulo delgado sobre la lnea de
vida del objeto. La parte superior del rectngulo est alineada con el comienzo de
la accin y la inferior alineada con su trmino (y puede estar marcada por un
mensaje de vuelta).
Nota:
1. En un diagrama de colaboracin no podemos mostrar de forma explcita la lnea
de la vida de un objeto, pero s los mensajes create y destroy.
2. Tampoco podemos mostrar la activacin de un objeto, aunque el nmero de
secuencia de cada mensaje nos puede indicar si hay o no anidamiento.
Mensajes
Los mensajes representan la comunicacin entre los objetos y se dibujan como
lneas horizontales continuas, dirigidas desde el objeto que enva el mensaje hasta
el objeto que lo ejecuta. La flecha especifica si el mensaje es simple, sncrono o
asncrono, tal como podemos ver en la Figura 4.1.

Figura 4.1
En UML se distinguen los siguientes tipos de mensajes:
Simple: Representa un flujo de control simple. Muestra cmo el control se pasa
de un objeto a otro sin describir ningn detalle sobre la comunicacin. Este tipo de
mensajes se utiliza cuando los detalles sobre la comunicacin no son conocidos o
no se consideran relevantes en el diagrama. Tambin se usa para mostrar la
vuelta de un mensaje sncrono.
Sncrono: Representa un flujo de control anidado, implementado como una
llamada a una operacin. La operacin que soporta el mensaje se termina
(incluyendo otros mensajes anidados) antes de que el objeto que envi el mensaje
contine con su ejecucin. La vuelta se puede mostrar como un mensaje simple.
Asncrono: Representa un flujo de control asncrono. No hay vuelta explcita al
objeto que envi el mensaje, el cual contina ejecutndose despus de enviar el
mensaje sin esperar ninguna respuesta. Este tipo de mensajes se utiliza en los
sistemas de tiempo real donde los objetos se ejecutan concurrentemente.
Los mensajes tienen un nombre, el cual puede aparecer o no acompaado de
parmetros. Tambin pueden tener condiciones, expresadas entre corchetes, que
se usan para modelar ramas o decidir si se enva o no un mensaje. Si las
condiciones describen ramas, se pueden dar dos posibilidades. Una alternativa es
que las condiciones sean excluyentes y entonces slo se ejecute un mensaje cada

vez. La otra es que no se excluyan, con lo cual los mensajes son enviados
concurrentemente.
En el ejemplo de la Figura 4.2 podemos observar los componentes descritos
anteriormente para un diagrama de secuencia.

Figura 4.2
Creacin y destruccin de un objeto
Los diagramas de secuencia pueden mostrar cmo los objetos son creados o
destruidos como parte del escenario bien documentado. El mensaje que crea o
destruye un objeto es normalmente un mensaje sncrono.
Un objeto puede crear otro objeto por medio de un mensaje, estereotipado como
create. El objeto creado se dibuja con el smbolo que representa al objeto
situndolo donde se crea (en el eje vertical). Asimismo se puede eliminar un objeto
va un mensaje, estereotipado como destroy. Cuando se destruye un mensaje,
se marca con una X larga y adems la lnea de vida del objeto slo se dibuja hasta
el punto en el que se ha eliminado. En el ejemplo de la Figura 4.3 podemos ver
tanto la creacin como la destruccin de un objeto de la clase BilleteAgente, por lo
que a este tipo de objeto se le cataloga como transitorio. Tambin se puede
observar que una instancia de la clase BilleteAgente se enva un mensaje a s
mismo, llamando a la operacin HallarRuta.
El tipo de mensaje ms comn es la llamada, en la cual un objeto solicita una
operacin de otro objeto (o del mismo). Si un objeto, tal como c de la clase Cliente,

llama a la operacin PonerItinerario en una instancia de la clase BilleteAgente,

entonces dicha operacin no slo tiene que estar definida en la clase BilleteAgente
(es decir, tiene que estar declarada en la clase BilleteAgente o en uno de sus
padres), sino que tambin debe ser visible al objeto c que le ha llamado. Cuando
el objeto de la clase BilleteAgente devuelve el control al objeto c, se puede
modelar como un mensaje sncrono o simple y de forma optativa incluir el valor
devuelto.

2.2.2. De colaboracin.
Qu es una Colaboracin?
Es una descripcin de una coleccin de objetos que interactan para implementar
un cierto comportamiento dentro de un contexto.
DIAGRAMAS DE COLABORACIN

El Diagrama de Colaboracin ofrece una mejor visin espacial mostrando

los enlaces de comunicacin entre objetos, muestra las relaciones entre

objetos y son mejores para comprender todos los efectos que tiene un
objeto y para el diseo de procedimientos. El diagrama de Colaboracin
puede obtenerse automticamente a partir del correspondiente diagrama de
Secuencia (o viceversa).

OBJETIVOS

Un diagrama de colaboracin destaca la organizacin de los objetos que

participan en una interaccin.

Dar una visualizacin clara del flujo de control en el contexto de la

organizacin estructural de los objetos que colaboran.

Enfatizar la organizacin estructural de los objetos que envan y reciben

mensajes.

CARACTERSTICAS

Dan una visin clara del flujo de control en el contexto en el que se

desarrollan.

Son tiles en la fase exploratoria para identificar objetos.

La distribucin de los objetos en el diagrama permite observar

adecuadamente la interaccin de un objeto con respecto a los dems.

La estructura esttica viene dada por los enlaces; la dinmica por el envo
de mensajes por los enlaces.

Los diagramas de colaboracin tienen dos caractersticas principales que los

distinguen de los diagramas de secuencia:

1. El Camino:
Para indicar cmo se enlaza un objeto a otro
2. El Nmero de Secuencia:
Para indicar la ordenacin temporal de un mensaje

VENTAJAS
1. Son tiles en la fase exploratoria para identificar objetos.
2. La distribucin de los objetos en el diagrama permite observar
adecuadamente la interaccin de un objeto con respecto de los dems.
3. La estructura esttica viene dada por los enlaces; la dinmica por el envo
de mensajes por los enlaces.
4. se puede saber el orden de los mensajes fcilmente.
5. se puede saber los objetos que estn relacionados.
DESVENTAJAS

No se lo usa mucho en la fase de anlisis.

No se deben crear en paralelo con los diagramas de clase.

En un diagrama de secuencia existen en consecuencias los siguientes

elementos:
Objetos.
Mensajes.
Vnculos
ELEMENTOS Y REGLAS DE GRAFICACIN
Objetos
Son las instancias de las clases.

Vnculo
Es una instancia de una asociacin en un diagrama de clases.

Mensajes

INTERACCIONES ENTRE OBJETOS

Diagrama de colaboracin con interacciones

PASOS PARA HACER UN DIAGRAMA DE COLABORACIN

1) Colocar los objetos que participan en la interaccin como los vrtices en
una grfica.
2) Interpretar las ligas que conectan a estos objetos como los arcos de la
grfica.
3) Adornar estas ligas con los mensajes que los objetos envan y reciben.
4) Establecer una ruta, para indicar como un objeto es ligado a otro.
5) Podemos unirle un estereotipo al final de una liga.

6) Establecer un nmero de secuencia, para indicar el orden de tiempo de un

mensaje. ste debe ser nico.

EJEMPLO Cajero Automtico

DIFERENCIAS ENTRE LOS DIAGRAMAS DE SECUENCIA Y COLABORACIN

Diagrama de secuencia:

Lnea de vida de los objetos: representa la existencia de un objeto sobre un

perodo de tiempo.

Foco de control: muestra el perodo de tiempo durante el cual un objeto

est representando una accin.

Diagrama de colaboracin:

Ruta: indica como un objeto es ligado a otro.

Nmero secuencial: para indicar el orden de tiempo de un mensaje.

USOS COMUNES
Usamos diagramas de interaccin para modelar los aspectos dinmicos de un
sistema. Estos aspectos dinmicos pueden involucrar la interaccin de cualquier
tipo de instancias en cualquier vista de una arquitectura del sistema, incluyendo
instancias de clases (incluyendo clases activas), interfaces, componentes y nodos.
Al usar estos diagramas, lo hacemos en el contexto del sistema como un todo, un
subsistema, una operacin, o una clase. Podemos unir diagramas de interaccin
para casos de uso (para modelar un escenario) y para colaboraciones (para
modelar los aspectos dinmicos de una sociedad de objetos).
SUGERENCIAS Y TIPS
Un diagrama de interaccin bien estructurado:

Esta enfocado en comunicar el aspecto dinmico de un sistema.

Contiene solamente a los elementos que son esenciales para entender ese
aspecto.

Provee un detalle coherente con sus niveles de abstraccin y debera

revelar solamente los adornos que son esenciales para su entendimiento.

No es tan minimalista

Cuando dibujamos un diagrama de interaccin, debemos:

Darle un nombre que comunique su propsito.

Usar un diagrama de secuencia si queremos enfatizar el orden de tiempo

de los mensajes. Usar un diagrama de colaboracin si queremos enfatizar
la organizacin de los objetos involucrados en la interaccin.

Colocar sus elementos para minimizar las lneas que cruzan.

Usar notas y color como indicaciones visuales para prestar atencin a

caractersticas importantes de nuestro diagrama.

Usar bifurcaciones limitadas; podemos representar mucho mejor bifurcaciones

complejas usando diagramas de actividad.

Referencias

http://www.ciens.ucv.ve:8080/genasig/sites/disist/archivos/clase1.pdf
http://informaticatesci.wikispaces.com/file/view/ApuntesDiagramaEstructura.

pdf/564917477/ApuntesDiagramaEstructura.pdf
http://documents.mx/documents/introduccion-al-diseno-estructurado.html
https://es.scribd.com/doc/307143761/Diagramas-de-Flujo-de-Datos01-1
http://www.academia.edu/8365897/Desarollo_e_implementaci

%C3%B3n_de_sistemas_de_informaci%C3%B3n_completo
http://www.infor.uva.es/~mlaguna/cd/CD4.PDF
http://datateca.unad.edu.co/contenidos/204023/Otero_M._s.f._._Diagramas

_De_Interaccion.pdf
https://deberesfacilitos.files.wordpress.com/.../diagramas_interaccion.doc