Análisis Estructurado

Consideraciones

Dependencia en
procesadores de transacción

Existen casos especiales donde el
procesamiento y transmisión
incorpora un proceso de decisión
estado-dependiente, el cual solo sucede
cuando la salida de una determinada
decisión depende neamente no de un
solo dato de entrada, sino además de
los valores ingresado con anterioridad

Procesamiento de transacciones

Estas tienden a ser muy semejantes
a la mayoría de profesionales de EDP
La experiencia establece que dichos
sistemas son mas eficientes y sencillos
de componer inicialmente, pero son mas
hostiles de modificar y poder mantener
en su posterioridad

Transacciones sintácticas
y semánticas

Los elementos sintácticos son aquellos
aspectos de procesamiento que se relacionan
a la forma en la que se manipula la transacción;
por otro lado tenemos el semántico el cual
corresponde a las acciones resultantes de:
el "que" y "el como"

Estrategias

Estas se componen por:

1. Identificar las fuentes de transacción
2. Especificación sobre la organización
centrada en la transacción apropiada
3. Identificar las transacciones y el modo
por el cual están definidas
4. Poder identificar situaciones especificas
por las cuales se puedan combinar los
módulos
5. Para cada transacción o colección
especificar su respectivo módulo de
transacción para de esta manera poder
procesarlo por completo
6. Para cada acción que se ejecute en una
transacción, especificar un modulo de
detalle subordinado a algún modulo de
acción que lo requiera
7. Para cada paso de tallado en un modulo
de acción, especificar un módulo de detalle

Centro de transacción

El centro de transacción se caracteriza
principalmente por reconocer los DFD
de la forma en la que se plantea y pre-
vialmente estos pueden mapearse como
una estructura en partícula

Una subestructura que se
encuentra por debajo del
modulo de despacho y esta
puede ser modelada en un
sistema de 4 niveles, los cuales
son los siguientes:

- Procesador de transacción (o nivel P)
- Nivel de transacción (o nivel T)
- Nivel de Acción (o nivel A)
- Nivel de Detalle (o nivel D)

Capacidades

Un sistema debe ser capaz de:
- Obtener o responder a las transacciones
de forma "cruda"
- Analizar cada transacción para poder
de esta manera definir su tipo
- Despachar acorde al tipo de transacción
que se realice
- Completar el procesamiento en cada una
de sus respectivas transacciones

También poseemos algo que se
llama salidas y estas consisten en:

- Una versión de conversión o formateo de la
transacción entrante las cuales pueden ser
enviadas hacia arriba para de esta manera
poder alimentar los niveles superiores
- Usar una bandera como un indicador
para saber que al momento en el que entro
la transacción esta fue valida
- Suministra formas de actualizar y/o modificar
un elemento o elementos de la respectiva
base de datos independientemente de que
sean internos o externos

Subtopic

Características principales

1. Plantear el problema a partir de un
diagrama de flujo de datos
2. Identificar los elementos aferentes
y eferentes
3. Factorizar el primer nivel
4. Factorizar las ramas aferente, eferente
y de transmisión

Pasos para su realización

1. Obtención del diagrama de flujo de los
datos del problema: Para ello habitualmente
se emplea un diagrama de flujo de datos
conocido como (DFD) del sistema que se
esta desarrollando, es importante recalcar
que un DFD no es un modelo porcentual, por
lo general los diseñadores emplean el uso
de entradas físicas para comenzar
2. Reconocimiento de los elementos de datos
Aferentes y Eferentes: Para este caso introducimos
los conceptos de flujo de datos aferente y eferente
Los datos aferentes son aquellos elementos que
representan datos de alto nivel que una vez son
removidos de sus respectivas entradas físicas
todavía entran en consideración para la entrada de
un sistema
3. Factorización del primer nivel: Una vez identificados
los elementos aferentes y eferentes del sistema,
proseguimos a especificar el modulo principal, el cual
una vez activado, se encargara de realizar todas
las tareas del sistema invocado a sus subordinados

4. Factorización de los flujos Aferentes, Eferentes
y de transformación: Tras implementar distintas
estrategias comúnmente son usadas para
factorizar los tres tipos de módulos en módulos
de bajo nivel. Por ende no existe una razón
particular para ser selectivo por el módulo que se
quiera implementar inicialmente
5. Desviaciones: Esa se encarga de asumir la ortodoxa
en la cual el flujo de datos es entrante y saliente
en cualquiera de sus ramas, por lo general se espera
que los módulos aferentes tengan un solo
subordinado aferente y de transformación
6. Como finalizar la factorización: Para esta ultima etapa
son varios los criterios que pueden llegar a implementarse
o utilizar cuando la factorización funcional de los módulos
debe terminarse. El principal fin de esta etapa es que pueda
alcanzarse, a diferencia de una transformación sabiendo
que para ella es mas difícil distinguir las subtareas

Analisis procedural

Definición
Este se caracteriza principalmente por se un conjunto
de criterios que se implementan con el fin de determinar
que módulos deben permanecer a la misma unidad de carga
en pro de maximizar la eficiencia.
Es importante aclarar que no existen una reglas previamente
determinadas para realizar un empaquetado de módulos
en unidades de carga, será propiamente el criterio del
diseñador el que deberá tomar la decisión sobre como se
compongan las unidades de carga.

Caracteristicas

Iteraciones

Estas deben incluirse obligatoriamente
en la misma unidad de carga de los módulos
conectados mediante referencias iterativas o
también llamadas loops.
Se estipula que siempre que sea posible, debe
incluirse en la misma unidad de carga al
módulo referenciado y al referenciante.

Volumen

Esta característica menciona que debe incluirse
en la misma unidad de carga los módulos con
alto volumen de referencias de conexión
propiamente entre ellos.
Para realizar esto como primera acción debe
estimarse la cantidad de veces que un módulo
invocará a otro durante su ejecución

Frecuencia

Cuando hablamos de frecuencia de referencia nos
referimos explícitamente a que es un criterio observable,
por ende la regla de pensamiento es que los módulos
relacionados por referencias altamente frecuentes deben
ubicarse en la misma unidad de carga a su vez que debe
observarse que las invocaciones condicionales reducen la
frecuencia de invocación

Intervalo

Para los intervalos se deben incluir en la misma unidad de carga los módulos con intervalos que sean cortos y breves en cuestión de tiempo entre activaciones.
También podemos observar que existen situaciones particulares donde será deseable que dos módulos no pertenezcan a la misma unidad de carga.

Estos criterios los definimos como:

Funciones Opcionales

Debe ubicarse obligatoriamente
en una unidad de carga por
separado cualquier función que
este definida como opcional

Funciones por única vez

Estas deben ubicarse en
una unidad de carga por separado
de las funciones que se utilicen
una única vez en el sistema

Sorts

Se ubican en los módulos
aplicados a la entrada y
salida de un proceso sorts
en unidades de carga
que se encuentra
separadas

La optimización posee diferentes
enfoques y características,
entre ellas encontramos:

Filosofías de optimización

La eficiencia de un sistema depende
depende completamente de la
competencia del diseñador, en la
mayoría de los casos el camino
mas simple es el mas eficiente

En ellos encontramos los

Sistemas Modulares Simples que pueden
ser optimizados con facilidad, el énfasis principal
de la optimización va dirigido a los objetivos
del diseñador y por ultimo es importante recalcar
que la optimización es irrelevante si el programa
no funciona correctamente

Enfoque para la optimización
de módulos

Existen dos enfoques para la optimización
de un sistema

Optimizar el código dentro de los módulos

Modificar la estructura del sistema
para mejorar su performance

Esquema general

Un esquema general consta de los siguientes
pasos

1.
Determina el tiempo de ejecución
para cada uno de los módulos
o unidades de carga, para ello
se implementan monitores
de hardware y paquetes
para la medición de performance

2.
Examinar cada modulo
para así poder estimar
su potencial mejora.
Esto implica un proceso
de estimación y depende
precisamente del conocimiento
y la experiencia del programador
en el lenguaje, sistema operativo
y hardware

3.
Estima el costo que involucra
cada mejora, esto encapsula
el salario del programador o
analista, tiempo de computador,
y otros costos que van variando
en la producción de una versión
mejor optimizada del sistema

4.
Establece prioridades para realizar
las determinadas mejoras
Estas mejoras podemos establecerlas
como prioridad Pi mediante la siguiente
expresión:
Pi = A * li * Ti - B * Ci
Donde A y B son factores de peso
apropiado

5.
Optimizar los módulos con
mayor prioridad

Cambios de estructuración
que garanticen eficiencia

Macro o código
incluido lexicográficamente

Antes de llevar a cabo alguna modificación
en la estructura actual, el diseñador debe
ser consiente de pensar en la posibilidad
de cambiar el tipo de modulo preservando
su respectiva estructura.
El programador debe recordar que los macros
(rutinas lexicográficamente incluidas en el
cuerpo del modulo) y subrutinas representa
el compromiso entre el tiempo de ejecución
y los requerimientos de la memoria.

Estructura Panqueque

Como regla general se entiende que las estructuras
que poseen una mayor profundidad( hacemos referencia
a niveles cuando hablamos de profundidad) tienen
a menudo una gran sobrecarga debido a los procedimientos
que invocaron intramedulares.
Sin embargo existe una gran cantidad de excepciones a esta
regla que no siempre puede ser aplicada con seguridad

Compresión

Esta es la mas ubicua de todas las manipulaciones
estructurales para mejorar la eficiencia, por ende
se conoce comúnmente como "desmodularización"
ya que consiste esencialmente en comprimir todo
o parte de un modulo en otro.
Para representar el caso mas simple donde esto
ocurre es a través de la inclusión lexicográfica
de un modulo en otro