Análisis Estructurado

Больше похоже на это

Línea de Tiempo "Historia, Evolución, Hechos Destacables, Situación Actual y Expectativas de las Investigaciones de Mercado"

от Alex M.Esquivel

procesos integradores del pensamiento

от Diego Santana

TIPOS DE BASES DE DATOS

от brian castañeda

mapa conceptual inventario

от CAROLINA OCHOA

Análisis Estructurado

Optimización

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

Cambios de estructuración que garanticen eficiencia

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

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

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.

Enfoque para la optimización de módulos

Esquema general

Un esquema general consta de los siguientes pasos

5. Optimizar los módulos con mayor prioridad

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

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

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

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

Existen dos enfoques para la optimización de un sistema

Modificar la estructura del sistema para mejorar su performance

Optimizar el código dentro de los módulos

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

Empaquetamiento (Paking)

Analisis procedural

Caracteristicas

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:

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

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

Funciones Opcionales

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

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

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

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.

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.

Análisis de transformación

Pasos para su realización

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

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

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

Análisis de transacción

Subtopic

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

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)

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

Consideraciones

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"

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

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