RELACIÓN CON EL DERECHO INTERNACIONAL PÚBLICO (FLUJO DE DATOS TRANSFRONTERAS)

La relación entre el derecho internacional públicon con la informatica, es que gracias a los avances tecnológicos se pueden llevar a cabo diferentes relaciones entres las entidades del estado con las de otros países.

El flujo de datos transfronteras hace alusión a la libre circulación de datos entre países fornterizos, cabe resaltar que estos datos debe contar cno una seguridad para que en ningún momento agreda la soberania del país vecino.
Recordemos que el diseño es una actividad que consta de una serie de pasos,
en los que partiendo de la especificación del sistema (de los propios
requerimientos), obtenemos una representación de la arquitectura del sistema,
de las estructuras de datos y de los procedimientos.
Se trata de una actividad en la que se toman decisiones muy importantes, ya
que sobre él se realizará la traducción al código que implementan realmente las
funciones.
Recordar también que el diseño comparte aspectos con la programación, pero
que no son lo mismo ni mucho menos, ya que el nivel de detalle es muydiferente.
En este capítulo estudiaremos el método de Diseño Orientado al Flujo de
Datos, cuyo objetivo es el de proporcionar un enfoque sistemático que nos
permita obtener las estructuras de programa.
1. DISEÑO Y FLUJO DE LA INFORMACIÓN
A partir del Diagrama de contexto (DFD de nivel 0), la información puede
representarse mediante un flujo continuo que sufre una serie de
transformaciones (procesos) conforme se dirige de la entrada a la salida.
El Diagrama de Flujo de Datos (DFD) se utiliza como herramienta gráfica para
la descripción del flujo de la información.
El Diseño Orientado al Flujo de Datos (DOFD) define varias representaciones
que transforman el flujo de la información en la estructura del programa.
El DOFD tiene sus orígenes en los primeros conceptos de diseño que
consideraban la modularidad, el diseño descendente o refinamiento y la
programación estructurada. EL DOFD amplió estas técnicas integrando el flujo
de información en el proceso de diseño.
La elección de un método de diseño depende del área de aplicación. El método
de DOFD es particularmente útil cuando la información se procesa de forma
secuencial y no existe una estructura de datos jerárquica.
Para las aplicaciones de tiempo real, conducidas por interrupciones, se realizan
con una ampliación del DOFD, que lo que hacen es una adaptación del
método.
En el caso en que el flujo de datos no importe realmente, se suelen utilizar
métodos de diseño orientados a objetos.
Diseño orientado al flujo de datos
2
2. CONSIDERACIONES SOBRE EL PROCESO DE DISEÑO
El DOFD permite una traducción sencilla de las representaciones de la
información de los DFD contenidas en la especificación del sistema a una
descripción del diseño de la estructura del programa.
La traducción desde el flujo de la información hasta la estructura consta de
cinco pasos:
􀂃 Establecer el tipo de flujo de información
􀂃 Determinar los límites del flujo
􀂃 Convertir el DFD en la estructura del programa
􀂃 Definir la jerarquía de control mediante factorización
􀂃 Refinar la estructura resultante mediante heurísticas de diseño
El tipo de flujo de información es el que determina cómo se realiza la
conversión del DFD a la estructura del programa.
Los tipos de flujo de información son:
􀂃 Flujo de transformación
􀂃 Flujo de transacción
2.1 Flujo de transformación
En el Diagrama de Contexto (modelo fundamental del sistema) la información
entra y sale de una forma.
A veces esta información tiene que ser convertida a una forma interna para el
procesamiento. La información entra al sistema mediante caminos que
transforman los datos externos a una forma interna y se identifica como flujo
entrante. Es decir, un flujo entrante es un camino en el que se transforma la
información externa en interna.
Los datos entrantes pasan a través de un proceso de transformación,
moviéndose a través de caminos que conducen hacia la salida del software. El
flujo saliente transforma la información interna en externa. El flujo de datos
global ocurre de forma secuencial.
Cuando una parte de un DFD muestra estas características tenemos un flujo
de transformación.
Diseño orientado al flujo de datos
3
Figura 1. Flujo de transformación
2.2. Flujo de transacción
El Diagrama de Contexto implica un flujo de transformación. Sin embargo, a
veces ocurre que un flujo de datos puede desencadenar otro flujo de datos
entre uno de varios caminos.
El flujo de transacción se caracteriza por el movimiento de datos a través de un
camino de llegada, que convierte la información, la evalúa, (centro de
transacción) y de acuerdo con el valor de la comparación, el flujo sigue por
alguno de los caminos de acción.
Figura 2. Flujo de transacción
3. ANÁLISIS DE TRANSFORMACIÓN
El análisis de transformación es un conjunto de pasos de diseño que permiten
convertir un DFD, con características de flujo de transformación, en una
estructura de programa
3.1. Pasos del diseño
Los pasos comienzan con una comprobación del trabajo realizado durante el
análisis de requerimientos y luego evoluciona hasta las estructura del
programa.
Diseño orientado al flujo de datos
4
Paso 1. Revisión del modelo fundamental del sistema
El paso de diseño comienza con una evaluación de la especificación del
sistema y de la especificación de requisitos del software. Estos dos
documentos describen el flujo y la estructura de la información.
Paso 2. Revisión y refinamiento de los DFD del software
Con el fin de conseguir un mayor detalle, se refina la información contenida en
los DFD.
Se trata de ver que los niveles de los DFD muestren una cohesión
relativamente alta, es decir, que cada proceso realice una función sencilla y
clara. De esta forma se podría proceder sin necesidad de refinar más.
Paso 3. Determinar si el DFD tiene características de transformación o de
transacción
En este paso el diseñador selecciona la característica general del flujo
basándose en la naturaleza del DFD (transformación o transacción. Para ello
se verían si existen centros de transacción claramente definidos). A
continuación se aislan las regiones locales de flujo de transformación o de
transacción.
Paso 4. Aislar el centro de transformación especificando los límites de los
flujos entrantes y salientes
La interpretación de los límites de los flujos entrantes y salientes es algo
subjetivo, dependiendo del lugar en el que se decida donde se realiza la
transformación de externa a interna (transformación) y de interna a externa
(transacción). Es decir, diferentes diseñadores pueden establecer límites
diferentes para la situación de los límites del flujo.
Aunque se debe tener cuidado al establecer los límites, una variación de una
burbuja en un camino de flujo, normalmente tendrá poco impacto en la
estructura final del programa.
En general se trata de establecer unos límites razonables, más que en
establecer grandes discusiones sobre la ubicación de las separaciones.
Paso 5. Realización del Primer Nivel de Factorización
La estructura de programa o jerarquía de control representa una distribución
descendente de control. La factorización da como resultado una estructura de
programa en la que los módulos de nivel superior toman las decisiones de
ejecución y los módulos de nivel inferior ejecutan la mayor parte del trabajo de
entrada, computacional y de salida. Los módulos intermedios realizan algunas
tareas de control y algunas tareas de trabajo.
Cuando se encuentra un flujo de transformación, el DFD se organiza en una
estructura específica que proporciona el control para procesamiento de la
información entrante, de transformación y de salida.
La figura siguiente muestra este primer nivel de factorización
Diseño orientado al flujo de datos
5
Figura 3. Primer nivel de factorización
En la parte superior de la estructura de programa se encuentra un módulo de
control, que sirve para controlar las funciones de control subordinadas.
El número de módulos del primer nivel debe limitarse al mínimo necesario para
obtener buenas características de cohesión y acoplamiento.
Paso 6. Ejecución del Segundo Nivel de Factorización
El segundo nivel de factorización se realiza mediante la conversión de las
burbujas de un DFD en los módulos correspondientes de la estructura de
programa.
La conversión se realiza comenzando desde dentro y yendo hacia afuera
comenzando por los caminos de entrada, y luego continuando con los caminos
de salida como se muestra en la figura siguiente.
Figura 4. Segundo nivel de factorización
Diseño orientado al flujo de datos
6
Aunque la figura anterior muestra una correspondencia uno a uno entre las
burbujas y los módulos del software, se pueden combinar varias burbujas en un
solo módulo (con el consecuente problema de cohesión) o una burbuja puede
dividirse en varios módulos.
Paso 7. Refinar la estructura inicial del programa utilizando medidas y
heurísticas de diseño
La estructura inicial del programa siempre puede refinarse aplicando los
conceptos de independencia funcional. Se puede aumentar o reducir el
número de módulos con el fin de conseguir una factorización sensata, una
buena cohesión, un acoplamiento mínimo y una estructura que se pueda
implementar sin dificultad, probarse sin confusión y mantenerse sin problemas.
4. ANÁLISIS DE TRANSACCIÓN
El análisis de transacción es un conjunto de pasos de diseño que permiten
convertir un DFD, con características de flujo de transacción, en una
estructura de programa
4.1. Pasos del diseño
Los pasos del diseño para el análisis de transacciones son similares (y en
algunos casos idénticos) a los pasos para el análisis de transformaciones. La
principal diferencia se encuentra en la conversión del DFD en la estructura del
programa.
Paso 1. Revisar el modelo fundamental del sistema
Paso 2. Revisar y refinar los DFD para el software
Paso 3. Determinar si el DFD tiene características de transformación o de
transacción
Si en un DFD apareciesen características de transformación y de transacción
habría que establecer los límites para ambos tipos de flujo.
Paso 4. Identificar el centro de transacción y las características del flujo
de cada camino de acción
La situación del centro de transacción puede localizarse de forma inmediata en
el DFD, ya que es el origen de varios caminos de información que fluyen
radialmente desde él.
También debe aislarse el camino entrante (es decir, el camino de flujo que
recibe un centro de transacción) y todos los caminos de acción (es decir, todos
los caminos de flujo que salen del centro de transacción).
Paso 5. Transformar el DFD en una estructura de software adecuada al
procesamiento de transacciones
El flujo de transacción se convierte en una estructura de programa que
contiene una rama entrante y una rama de distribución.
Diseño orientado al flujo de datos
7
La estructura para la rama entrante se desarrolla de la misma forma que en el
análisis de transformaciones. Es decir, comenzando desde el dentro de
transacción, se van convirtiendo en módulos las burbujas a lo largo del camino
entrante.
La estructura de la rama de distribución contiene un módulo distribuidor que
controla todos los módulos de acción subordinados. El flujo de cada camino de
acción del DFD se econvierte en una estructura que se corresponda con las
características del flujo.
Este proceso se muestra en la figura siguiente
Figura 5. Transformación de un flujo transaccional
Paso 6. Factorizar y refinar la estructura de transacciones y la estructura
de cada camino de acción
Cada camino de acción del DFD tiene sus propias características de flujo de
información. La subestructura correspondiente a cada camino de acción se
desarrolla dependiendo de la característica del flujo de información de la
subestructura.
Paso 7. Refinar la estructura inicial del software usando heurísticas de
diseño para mejorar la calidad
5. HEURÍSTICAS DE DISEÑO
Una vez que se ha desarrollado una estructura de programa utilizando el
método del DOFD, se puede conseguir una modularidad efectiva aplicando los
principios de diseño y manipulando la estructura resultante de acuerdo con este
conjunto de heurísticas.
1. Evaluar la estructura de programa preliminar para reducir el
acoplamiento y reducir la cohesión
A menudo, se expande un módulo cuando en dos o más módulos existe un
componente de procesamiento común que puede redefinirse como un módulo
cohesivo aparte.
Diseño orientado al flujo de datos
8
Para reducir el acoplamiento, se pueden juntar varios módulos para evitar las
interfaces complejas y reducir el número de referencias a datos globales.
2. Intentar minimizar las estructuras con alto grado de salida. Fomentar
un alto grado de entrada conforme aumente la profundidad
La estructura de control no debe ser demasiado ancha, sino que se opta por
estructuras con varias capas de control y gran utilización de los módulos
inferiores.
3. Mantener el efecto de un módulo dentro del ámbito de control de ese
módulo
4. Evaluar las interfaces de los módulos para reducir la complejidad y la
redundancia y mejorar la consistencia
La complejidad en las interfaces es una causa principal de los errores del
software. Las interfaces deben diseñarse para que sólo se pase la información
necesaria y deben ser consistentes con la función del módulo.
5. Definir módulos cuyas funciones sean predecibles
Los módulos deben tener una apariencia de caja negra, ocultando los detalles
de procesamiento.
6. Fomentar módulos con entrada única y salida única
El software es más fácil de comprender, y por tanto, es más fácil de mantener,
si a los módulos se entra por el principio y se sale por el final.
7. RESUMEN
El Diseño Orientado al Flujo de Datos (DOFD) es una metodología que utiliza
las características del flujo de información para derivar la estructura del
programa.
Un DFD se convierte en una estructura de programa en función de las
características del flujo de información: de transformación o de transacción.
El análisis de transformación se aplica a un flujo de información que muestra
unos límites claros para los datos entrantes y los salientes. El DFD se convierte
en una estructura de control que asigna control a la entrada, al procesamiento y
a la salida, en tres jerarquías de módulos factorizadas por separado.
El análisis de transacción se aplica cuando un elemento de información hace
que el flujo se bifurque hacia uno entre muchos caminos. El DFD se convierte
en una estructura que asigna el control a una subestructura que toma y evalúa
una transacción. Otras subestructuras controlan todas las acciones basadas en
una transacción.

0 comentarios:

Publicar un comentario