Texto Capítulo 1 PDF

Ingeniería de Sistemas II IND-225 Capítulo 1
Capítulo No. 1
Modelo de Implementación
1.1 Definición:
Este modelo define “cómo” se podrá en práctica el diseño lógico del sistema,
sin perder de vista que "Diseño es el proceso de aplicar distintas técnicas y
principios con el propósito de definir un dispositivo, proceso, o sistema, con los
suficientes detalles como para permitir su realización física" (E.S.Taylor, An Interim
Report on Engineering Design, Massachusetts Institute of Technology, 1959)
Este modelo se desarrolla en tres etapas:
a. Desarrollar el Modelo de Programas (Ingeniería de Software)

b. Definir la plataforma de Hardware y el Software de Base sobre los que
funcionará el sistema.
c. Desarrollar el Diseño Físico del Sistema.
1.2 El Modelo de Programas: Diseño Estructurado
Se llama Diseño Estructurado al proceso de decidir los componentes necesarios, y

la interconexión entre los mismos, para solucionar un problema de software bien
especificado".
El diseño es una actividad que comienza cuando el analista de sistemas ha

producido un conjunto de requerimientos funcionales lógicos para un sistema, y
finaliza cuando el diseñador ha especificado los componentes del sistema y las
relaciones entre los mismos.
Por tanto, este modelo tiene como objetivo definir cuáles de los procesos que
forman parte del Modelo Esencial serán automatizados (llevados a un
computador)
Una vez que esos procesos hayan sido definidos, el Modelo de Programas debe ser
capaz de interpretar el lenguaje estructurado y transformarlo en un conjunto de
programas, gracias al apoyo de herramientas gráficas.
Frecuentemente analista y diseñador son la misma persona, sin embargo es

necesario que se realice un cambio de enfoque mental al pasar de una etapa a
1
Jimmy Camacho Villazón
Docente Titular Ingeniería de Sistemas
FCyT - UMSS
la otra. Al abordar la etapa de diseño, la persona debe quitarse el sombrero de

analista y colocarse el sombrero de diseñador.
Una vez que se han establecido los requisitos del software (en el análisis), el diseño
del software es la primera de tres actividades técnicas: diseño, codificación, y
prueba. Cada actividad transforma la información de forma que finalmente se
obtiene un software para computadora válido.
Las fases del diseño, codificación y prueba absorben el 75% o más del costo de la
ingeniería del software (excluyendo el mantenimiento). Es aquí donde se toman
decisiones que afectarán finalmente al éxito de la implementación del programa
y, con igual importancia, a la facilidad de mantenimiento que tendrá el software.
Estas decisiones se llevan a cabo durante el diseño del software, haciendo que sea
un paso fundamental de la fase de desarrollo.
La importancia del diseño del software se puede sentar con una única palabra:
calidad. El diseño es el proceso en el que se asienta la calidad del desarrollo del
software. El diseño produce las representaciones del software de las que puede
evaluarse su calidad.
El diseño sirve como base para todas las posteriores etapas del desarrollo y de la
fase de mantenimiento. Sin diseño nos arriesgamos a construir un sistema inestable,
un sistema que falle cuando se realicen pequeños cambios, un sistema que pueda
se difícil de probar, un sistema cuya calidad no pueda ser evaluada hasta más
adelante en el proceso de ingeniería de software, cuando quede poco tiempo y
se haya gastado ya mucho dinero.
1.3 Objetivos Del Diseño Estructurado
"El diseño estructurado, tiende a transformar el desarrollo de software de una

práctica artesanal a una disciplina de ingeniería". Permitirá lograr:
Eficiencia
Mantenibilidad
Modificabilidad
Flexibilidad
Generalidad
Utilidad
"Diseño" significa planear la forma y método de una solución. Es el proceso que

determina las características principales del sistema final, establece los límites en
2
FCyT - UMSS
performance y calidad que la mejor implementación puede alcanzar, y puede

determinar a que costos se alcanzará.
El diseño se caracteriza usualmente por un gran número de decisiones técnicas

individuales. En orden de transformar el desarrollo de software en una disciplina de
ingeniería, se debe sistematizar tales decisiones, hacerlas más explícitas y técnicas,
y menos implícitas y artesanales.
Diseño estructurado y calidad del software
Un concepto importante a considerar es el de calidad. Dentro de este concepto,

se deben tomar encuenta:
9 Eficiencia: Se refiere al incremento de la velocidad de ejecución y

disminución de los requerimientos de memoria central. Estos recursos no
incluyen solamente procesador y memoria, también incluyen
almacenamiento secundario, tiempo de periféricos de entrada salida,
tiempo de líneas de teleproceso, tiempo de personal, y más.
9 Confiabilidad. Es importante notar que si bien la confiabilidad del software

puede ser vista como un problema de depuración de errores en los
programas, es también un problema de diseño. La confiabilidad se expresa
en como MTBF (Mean Time Between Fairules: tiempo medio entre fallas).
9 Mantenibilidad. Se define como:
Mantenibilidad del sistema = ____MTBF___

MTBF + MTTR
donde:
MTBF: tiempo medio entre fallas (mean time between fairules)
MTTR: tiempo medio de reparación (mean time to repair)
Diremos que un sistema es mantenible si permite la detección, análisis, rediseño, y
corrección de errores fácilmente.
1.3 Identificación de Procesadores.
Es el primer paso en el desarrollo del Modelo de Implementación. Tiene como

propósito asignar cada uno de los procesos que forman parte del sistema a un
3
FCyT - UMSS
PROCESADOR, que se encargará de desarrollar el proceso. Esta etapa se

desarrolla a nivel del DFD:
PROCESADOR #1
PROCESADOR #2
PROCESADOR #3
No puede quedar ningún proceso sin asignar.
1.4 Diagramas de Estructura
Tiene como objetivo básico el tratar d enfocar la programación a través de

MÓDULOS, de manera que cada uno de ellos pueda ser programado de manera
independiente.
Características de los Diagramas de Estructura:
9 Es gráfico y, por tanto, conciso, fácil de leer, sencillo de preparar.
4
FCyT - UMSS
9 El diagrama de estructura muestra la descomposición de un sistema en

módulos.
9 Presenta un formato TOP-DOWN: pasar de la forma global a la detallada.
Presenta una estructura jerárquica.
9 Los módulos se consideran cajas negras de las que se conoce:
- Entradas que reciben.
- Salidas que generan.
- La función que lleva a cabo.
- Un diagrama de estructura tiene forma de árbol y refleja:
i. Jerarquía de control qué módulos pueden invocar a otros
módulos.
ii. Parámetros que se pasan en los llamadas.
En cambio no muestra:
- Aspectos de procesamiento del software: secuencias, alternativas o
bucles.
- Ni datos internos de los módulos.
Debe ser parte de la documentación del programa y del sistema, así como debe
servir de ayuda para el mantenimiento y mejoras del sistema.
DEFINICIÓN DE MÓDULO
Un módulo se define como un conjunto de sentencias de programa con cuatro

atributos básicos:
- Entradas/ Salidas: Datos que recibe cuando lo invocan y datos que

devuelve al módulo que lo llamó.
- Función: Qué hace con las entradas para producir las salidas.
- Mecánica: La lógica mediante la cual lleva a cabo su función.
- Datos internos: Zona de datos a los que únicamente puede referirse él.
Además posee otros atributos adicionales cómo:

- Un nombre, por el cual puede ser referenciado como un todo.
- Puede invocar o ser invocado por otros módulos.
Un módulo debe manejarse como una “caja negra”, funcionalmente

independiente, que puede entenderse en forma separada.
El concepto de Caja Negra: 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,
5
FCyT - UMSS
un automóvil, 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 abstracción. Este concepto es de suma utilidad e
importancia en la ingeniería en general, y por ende en el desarrollo de software.
1.5 Comparación entre las estructuras administrativas y el diseño estructurado
Uno de los aspectos más interesantes del diseño de programas es la relación que
puede establecerse con las estructuras de organización humanas, particularmente
la jerarquía de administración encontrada en la mayoría de las grandes
organizaciones.
Observemos por ejemplo el siguiente diagrama de organización 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 analogía con la estructura de programas y es razonable

pensar que un módulo que tenga demasiados módulos subordinados a quienes
controlar, sea sumamente complejo, y susceptible a fallas.
Veamos otro ejemplo
6
FCyT - UMSS
Podemos apreciar a simple vista que la tarea de los jefes A, X, Y, es relativamente

trivial y podría se comprimida en una sola jefatura. Estableciendo un comparación
con la estructura de programas, si tenemos un módulo cuya única función es
llamar a otro, y este a su vez a otro, el cual llama a uno que finalmente realizará la
tarea, los módulos intermedios podrán comprimirse un único módulo de control.
Podemos decir que en una organización perfecta, los administradores no realizan
ninguna tarea operativa. Su labor consiste en coordinar información entre los
subordinados y tomar decisiones. Los niveles inferiores son los que realizan el
trabajo operativo. Análogamente, podemos argumentar que los módulos de nivel
alto en un programa o sistema solamente coordinan y controlan la ejecución de
los módulos de menor nivel, quienes son los que realizan los cómputos y procesos
que el sistema requiere.
Finalmente observaremos que los administradores suministran a sus subordinados

únicamente la información que estrictamente necesitan. Análogamente los
módulos inferiores solo deben tener acceso a la información 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 diseño
estructurado.
1.6 Manejo de la complejidad
En principio diremos que escribir un programa "grande" generalmente lleva más

tiempo que escribir un "pequeño". Esto es valedero si medimos "grande" y
"pequeño" en unidades apropiadas. Claramente, el número de instrucciones de un
programa no es una medida de complejidad ya que existe instrucciones más
complejas que otras, y algoritmos más complejos que otros. En realidad lo que
diremos es que es más difícil resolver un problema difícil! , e intentaremos realizar un
análisis sobre como disminuir la complejidad de un determinado problema.
Si asumimos que hemos podemos medir por algún método la complejidad de un
problema P (no importa aquí que método), 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 responderá 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 tamaño del mismo.
7
FCyT - UMSS
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 razón
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 número
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 pequeñas que una sola más grande, si
ambas solucionan el mismo problema.
Este fenómeno no es solo válida para el campo de la computación. Es verdadero

en cualquier campo de la solución de problemas (matemática, física, etc.).
1.7 Notación de los Diagramas de Estructura
a. Módulo: Representa un grupo de instrucciones que realiza una única

función determinada. Un módulo asocia a uno ó más de los procesos definidos en
el Diseño Lógico. Cada módulo tiene cierta información de entrada y genera
cierta información de salida. El módulo debe tener un nombre dentro el rectángulo
que lo representa.
8
FCyT - UMSS
Módulo CALCULAR SALDOS
Nombre del Módulo
b. Flecha de Invocación. Se presenta como una flecha que va desde el

módulo que llama hasta el que es invocado. Como describe una relación
jerárquica, su dirección es siempre hacia abajo:
Módulo Jefe (Invocador)
Módulo Subordinado (Invocado)
Un módulo puede invocar a varios otros que dependen de él:
A su vez, un módulo puede ser invocado por varios módulos
9
FCyT - UMSS
c. Flecha (Cupla)
Representa a parámetros de información que pasan a través de los módulos. El

sentido de la flecha indica la dirección del flujo.
d. Condicional.- Muestra la existencia de un proceso de selección.
1.8. Formato General de un Diagrama de Estructura
En resumen, un Diagrama de Estructura ilustra la partición del sistema en módulos

funcionales independientes, cada uno de los cuales se programará bajo ese
concepto
10
FCyT - UMSS
Ejemplos
1.9 Acoplamiento y Cohesión.
El Acoplamiento es la medida de la fuerza de relación entre los módulos

La cohesión es la fuerza de la relación entre los elementos de un módulo
11
FCyT - UMSS
1.10 Estrategias de Transformación
12
FCyT - UMSS
Proceso de Transformación
Se deben identificar:
Ramas Aferentes: Procesos que leen y validan los datos a la entrada del sistema.
Para identificarlas se buscan los puntos de entrada de datos a la transacción
(normalmente Entidades Externas que proporcionan datos al sistema) y se recorre
la rama del DFD hasta llegar a un flujo de datos completamente validado.
Ramas Eferentes: Procesos que dan el formato adecuado a los datos para ser
emitidos (visualizados, impresos, guardados, ...) al exterior. Para identificarlas se
buscan los puntos de salida de datos de la transacción (normalmente Entidades
Externas que reciben datos del sistema) y se recorre la rama del DFD hasta llegar a
un flujo de datos lógico, antes de ser formateado.
Transformación Central: Los procesos que no son aferentes, ni eferentes

pertenecen a la transformación central (procesos de cálculo, procesamiento de
datos, actualización de datos, ...).
13
FCyT - UMSS
14
FCyT - UMSS
Ejemplos de transformación de Diagrama de Flujo de Datos a Diagrama de

Estructura
Diagrama Intermedio (Alquilar un jefe)
Antes de desarrollar el Diagrama de Estructura podemos hacer un diagrama

intermedio, entre el DFD y el DE, que sirva como aproximación. Existen dos maneras
de hacerlo: alquilar un jefe o promover un proceso a jefe. En este caso hemos
escogido la primera.
El proceso ‘alquilado’ es un proceso que no se corresponde con ningún otro del
DFD y que se convertirá en el módulo principal de la transacción. Del proceso jefe
alquilado se ‘cuelgan’ las ramas aferentes, eferentes y los procesos de la
transformación central, como sigue:
15
FCyT - UMSS
Resultado Final:
16
FCyT - UMSS
Ejemplo 2
Primer nivel de Factorización
Final
17
FCyT - UMSS
Lectura Complementaria: Análisis de Transformaciones

El principal enfoque del análisis de transformaciones es convertir un DFD,
resultado del análisis estructurado, en un diagrama de estructura. La principal
ventaja de este enfoque es que, el diagrama de estructura resultante tiene una
forma tal que permite un fácil desarrollo y mantenimiento más barato que la
mayoría de los diagramas de estructura que podamos construir ad-hoc. Como
será visto mas adelante, cuando los criterios de calidad son aplicados en los
diagramas de estructura, el resultado es un DE donde, la mayoría de los módulos
son independientes de los dispositivos de entrada y salida, esto es: describe el
diseño de un sistema balanceado. La figura 1 describe los pasos realizados durante
el análisis de transformaciones.
DFDs resultantes del Análisis de la Especificación

Proceso de Analisis
Análisis del Problema
Estructurado
DFDs sin detalles de más y sin

ocultar transformaciones de datos
Identificar el Centro
de Transformación
Marcar el Centro de Transformación;

Caminos Aferentes y Eferentes
Producción de un Primer
DE (First-Cut)
Centro de Transformación=Raiz
Especificación del Analisis Caminos Aferentes=Izquierda
Caminos Eferentes=Derecha
Funcionalmente Mejoramiento del DE
Equivalentes Cohesión, Acoplamiento, etc
Diseño de buena Calidad

Implementación, Asegurar la Funcionalidad Diseño Estructurado de buena
Testeo, etc. del Diseño Calidad(mantenimiento;
eficiencia; claridad; etc)
Fig.1: Pasos del Análisis de Transformaciones
18
FCyT - UMSS
Análisis de la Especificación del Problema
Si un diseño estructurado está siendo desarrollado, luego del análisis estructurado,

entonces habrá un conjunto de DFDs que describen el problema, para los cuales
se debe diseñar una solución. Si el análisis estructurado no precede al diseño,
entonces se pueden reconocer dos situaciones muy diferentes:
• Un problema muy simple: Si el problema puede ser representado en la
memoria de una persona [DeMarco 86], es muy simple y no precisa mayor
esfuerzo que la especificación. En ese caso las herramientas del Análisis no
son necesrias y el DE puede ser desarrollado ad-hoc. Sin embargo, el
análisis estructurado ofrece una colección de técnicas y criterios que
permiten analizar y especificar un problema cuando es muy complejo para
ser comprendido y especificado con una simple declaración narrativa.
Según DeMarco [DeMarco 86], un modelo es una maqueta de una
realidad donde algunas características son estudiadas y, se construyen
diferentes modelos de la misma realidad (cada uno de ellos representando
diferentes características) para estudiar diferentes partes del problema por
separado.
• Un problema complejo: La mayoría de las veces, el problema es mayor
que la capacidad de nuestra memoria principal y diversos modelos
deberán ser desarrollados, en el proceso de análisis estructurado, para
conseguir una buena comprensión y especificación. En ese caso, será
necesario construir algunos DFDs a partir de la narrativa del problema
(declaraciones surgidas de las entrevistas con los diversos usuarios
involucrados).
Para obtener un buen resultado con el análisis de transformaciones, los DFDs no

deben llegar a un nivel de detalle en el que se tenga demasiada cantidad de
procesos. Si un DFD es muy detallado puede ser necesario que se necesite hacer
abstracción de algunos procesos (para reducir la cantidad). El DFD tampoco
puede ser demasiado abstracto y ocultar algunas características que el análisis de
transformaciones debe estudiar. Además, puede ser necesario descender un nivel
(describiendo los flujos de datos y los procesos interiores de algunos procesos
mostrados en el DFD) para que, el DFD presente todas las transformaciones de
datos producidas para llevar los flujos de entrada en dirección de generar los flujos
de salida.
19
FCyT - UMSS
Identificar el Centro de Transformación
El centro de transformación es la parte del DFD que contiene la funcionalidad

principal del sistema y es independiente de la implementación particular de las
entradas y salidas. Por ejemplo, considere el DFD de la figura 2.
Fig. 2: Generación de Informe de Movimientos de una Cuenta Corriente
El diseñador podría considerar al proceso Reunir Movimientos del Cliente como la

transformación principal del DFD, si un proceso tiene mas flujos de entrada que de
salida, la pregunta que deberá ser respondida es: ¿Qué proceso hace el trabajo
principal de la funcionalidad que representa el DFD?.
Claramente, el principal trabajo no es hecho por los procesos: Leer Movimiento del
Cliente, Leer Información del Cliente, Calcular Total o Imprimir Línea. Tampoco es
hecho por alguno de los procesos: Formatear Encabezado, Formatear Línea del
Reporte o Formatear Total por separado. La función que el DFD modela, con
certeza, no es Reunir Movimientos del Cliente, podría corresponderse con un
proceso de abstracción mayor, tal vez llamado Generar Reporte de Movimientos,
que incluya los procesos: Formatear Encabezado, Formatear Línea de Reporte y
Formatear Total.
20
FCyT - UMSS
La elección del centro de transformaciones no es una actividad simple,

generalmente requiere una interpretación detallada de la funcionalidad descripta
por el DFD, y, en muchos casos, podría incluir mas de un proceso. Para eso existe
una estrategia basada en la estructura del DFD, independiente de la
interpretación particular de los procesos, que permite obtener una buena
aproximación de la porción del DFD que debe incluir el centro de
transformaciones.
No es un algoritmo, ya que no establece una secuencia de etapas y tampoco

garantiza la obtención acertada del centro de transformaciones. Una vez
identificada la porción del DFD que incluye el centro de transformaciones, se debe
interpretar detalladamente la función de los procesos incluidos para determinar si
alguno de ellos representa la transformación principal del DFD o si una actividad
de abstracción mayor deberá ser escogida.
Estrategia para Determinar el Centro de Transformación

La estrategia intenta identificar la transformación central siguiendo los caminos de
datos aferentes y eferentes. Este proceso puede ser desarrollado a través de los
tres pasos siguientes:
1. Marcar cada camino aferente partiendo del lado externo del DFD (los flujos
provenientes de depósitos de datos, agentes externos o porciones del DFD
no incluidas en el Análisis 1 ), y terminar en cada flujo eferente alcanzado (los
flujos dirigidos para depósitos de datos, agentes externos o porciones de DFD
no incluidas en el Análisis).
2. Diseñar una curva que una los puntos de intersección de caminos

diferentes. Los procesos incluidos en el interior de la curva son candidatos
iniciales para el centro de transformación.
3. Finalmente, analizar los límites del centro. Generalmente, en el límite, se

puede reconocer la finalización del refinamiento de las entradas (para los
caminos de entrada o aferentes) y el comienzo del refinamiento de las
salidas (para los caminos de salida o eferentes). Si no es así, modifique el
contorno, yendo hacia el interior o exterior de forma tal que, el interior,
incluya solamente datos en estado lógico (independiente de las fuentes y
destinos y totalmente refinados).
1 El DFD analizado es solamente una porción correspondiente a una transformación identificable. Como separar un DFD proveniente del Analisis
en porciones correspondientes a transformaciones es una actividad muy intuitiva, quedará mas claro cuando sea presentado el Analisis de
Transaccioness.
21
FCyT - UMSS
En el ejemplo de la figura 3 se ilustra la actividad descripta arriba. Primero se

marcan todos los caminos de datos a través del DFD comenzando por los flujos de
comienzo de los caminos aferentes y finalizando en los flujos de finalización de los
caminos eferentes. En el ejemplo, los flujos de datos Campo y Registro Maestro son
flujos de comienzo de caminos aferentes y, Nuevo Registro Maestro y Línea de
Informe son flujos de finalización de caminos eferentes.
En el segundo paso se hace una curva uniendo los puntos de intersección de

caminos. La curva reúne los procesos candidatos para centros de transformación,
en el ejemplo, reúne los procesos: Aparear Transacción con Registro Maestro,
Actualizar Registro Maestro y Formatear Nuevo Registro Maestro.
Fin de Camino Linea de

Campo Reunir Eferente Informe
Invalido Transacciones Formatear
Transacción Linea de
Campo Transacción Inválida Informe
Transacción sin
Editar Editado
Campo Registro Maestro
Campo Transacción
Editado Efectuar Válida Aparear
Campo Validación Transacción Registro
Cruzada con Registro Transacción
Registro Maestro Aplicada
Maestro Juntado
Maestro
Registro Válido Registro
Maestro Maestro sin Actualizar
Inválido Validar Transacción
Registro
Registro Maestro
Nuevo
Maestr Formatear
Registro Registro Registro
Maestro
Nuevo
Maestro Registro Maestro
Actualizado
Inicio de Camino Archivo Maestro
Aferente Fin de Camino
Eferente
Fig. 3: Ejemplo de Análisis de Transformaciones

Las líneas punteadas marcan los diferentes caminos de datos a través del DFD. Hay dos
Caminos Aferentes que comienzan en los flujos Campo y Registro Maestro y dos Caminos
Eferentes que finalizan en los flujos Nuevo Registro Maestro y Línea de Informe. Los procesos
en el interior de la curva son candidatos a integrar el centro de transformaciones, ellos son
Aparear Transacción con Registro Maestro y Actualizar Registro Maestro.
La curva también indica la finalización de los caminos aferentes y el comienzo de

los caminos eferentes, verificar eso es el objetivo del tercer paso.
La primera tarea es verificar que, en el interior de la curva, no haya

transformaciones de refinamiento de los flujos de entrada o salida. En el ejemplo, el
flujo de datos Transacción Válida es la versión mas refinada de los datos que
comenzaron con el flujo Campo y, el proceso Aparear Transacción con Registro
Maestro procesan datos de los dos caminos aferentes para crear una salida muy
diferente (el Registro Maestro Apareado).
22
FCyT - UMSS
Con los caminos eferentes no ocurre la misma cosa. El proceso Formatear Nuevo
Registro Maestro, aunque sea integrante del selecto grupo de procesos
candidatos para centro de transformación, ejecuta una tarea de refinamiento de
datos de salida. La tarea de transformación real de datos fue realizada por los
procesos Aparear Transacción con Registro Maestro y Actualizar Registro Maestro.
El módulo Formatear Nuevo Registro Maestro simplemente refina el Registro
Maestro Actualizado o el Registro Maestro sin Transacción para generar el Nuevo
Registro Maestro. Así el proceso Formatear Nuevo Registro Maestro no compone el
centro de transformación e incrementa el camino eferente.
Como podemos ver, existe subjetividad en la elección de la transformación

central, raramente surgen grandes acuerdos relativos a esa elección. El diseñador
se podrá preguntar sobre un proceso aquí o allá, sin embargo, eso parece hacer
poca diferencia en el diseño final. Por eso, si hubiera dudas sobre un proceso, ése
no debe pertenecer al centro de transformación.
En sistemas de información el centro de transformación está compuesto por una

pequeña porción del DFD y no incluye procesos de edición, formateo o
verificación y corrección de errores.
Producir un Primer Diagrama de Estructura (First-Cut)
Una vez reconocido el centro de transformación y los caminos aferentes y

eferentes, una primera versión del DE puede ser desarrollada aplicando los cuatro
pasos siguientes:
1. Convertir el DFD en una jerarquía de módulos: Tirar el DFD desde los
procesos marcados como participantes del centro de transformaciones y
dejar caer los otros procesos, por acción de la gravedad.
b B
c k p g D l
f
A e H
E
d g o h m
C D l
a e C o
i h E F k G
m n
F f H
G B d j q
j q n i
X X p
c
A a
b
2. Substituir los depósitos de datos por módulos de lectura o grabación

(dependiendo de la orientación del flujo), los agentes externos por módulos
de captación o presentación de datos y adicionar módulos debajo de los
flujos sin destinatario u origen.
23
FCyT - UMSS
Se deben asociar nombres adecuados a los g D l

E
módulos adicionales, dependiendo de la actividad h k
m
de lectura (captación) o escritura (presentación) e C
F ? G
n o
que deben ejecutar. B f i j q

H
d p
c ? ? Leer Gra
A X X ?
a b
? ?
3. Convertir los flujos de datos en invocaciones (apuntando al módulo

invocado) y los datos transportados por los flujos en cuplas.
Cada uno de los módulos deberá ser
analizado para determinar y adicionar D l
g E
los datos de entrada necesarios. Por k m o
h
ejemplo, el módulo Leer X debe recibir n
C F Em G H
como entrada la clave de acceso e
f j
i q p
para la lectura del registro. Leer Gra
B Et Er X X Or
c d
A
4. Indicar un único módulo como raíz del a b
DE, sea por selección de uno de los Ic Ec
módulos participantes del centro de
transformaciones o, por la incorporación de un módulo nuevo.
Mejorar el Diagrama de Estructura Obtenido
El diagrama de estructura resultante del paso anterior, con certeza, puede ser
mejorado. Eso simplemente es una primera aproximación y se debe beneficiar con
la aplicación de los criterios de calidad (presentados mas adelante),
especialmente Descomposición, Cohesión y Acoplamiento.
Por lo menos, la siguiente revisión debería ser hecha en el diagrama de estructura:

• Reorganizar, y descomponer si fuese necesario, los módulos aferentes y
eferentes.
• Descomponer la transformación central, si fuese necesario, usando el DFD
como base. Los niveles del DFD son útiles en este caso.
• Adicionar los módulos de manipulación de errores.
• Adicionar detalles de inicialización y terminación (si son requeridos).
24
FCyT - UMSS
• Tener certeza que todos los módulos tengan nombres correspondientes a

su representación en la jerarquía.
• Adicionar todas las cuplas necesarias (de datos y de control).
• Chequear todos los criterios de calidad y mejorar el diseño de acuerdo
con esos criterios.
De esta manera, aplicando los cuatro pasos en el DFD de la figura 3, el DE

resultante es el siguiente:
Actualizar
Archivo
Transacción Maestro Transacción sin
Válida Registro Maestro
FTV
# Cuenta Reg RMV
Maestro TV
Obtener Obtener Valido Juntar Informar
Transacción Registro Registro Transacción
Válida Maestro Maestro Errónea
Transacción Reg Maestro RMV
# Cuenta Transacción
Reg Maestro
FT Reg Maestro Actualizado TV Aplicada
sinTrans Línea
Leer de
Generar Actualizar Imprimir Error
Obtener Registro Registro Transacción
Transacció Maestro Maestro Registro
Maestro Aplicada
Campo Campo
Editado Editado Nuevo Reg Transacción
Maestro Nuevo Reg Línea
Aplicada
FCE FCE Maestro Fmt
Obtener Formatear Grabar Formatear Imprimir
Campo Nuevo Nuevo Línea de Línea de
Editado Registro Registro Informe Informe
Maestro Maestro
Campo
FC
FC Fin de Campo FTV Fin de Transacción Válida
Obtener FCE Fin de Campo Editado RMV Registro Maestro Válido
Campo FT Fin de Transacción TV Transacción Válida
Fig. 4: Resultado de Aplicar Análisis de Transformaciones en el DFD de la figura 3
Garantizar la Funcionalidad del Diseño
El paso final es el paso más importante: tener certeza que el DE es funcionalmente

equivalente al DFD de origen. El propósito del análisis de transformaciones, es
obtener rápidamente un DE que implemente correctamente la especificación del
problema y cumpla los criterios de calidad.
25
FCyT - UMSS
Análisis de Transacción
El análisis de transformaciones es la principal estrategia para convertir un DFD (de

transformación de datos) en un DE. Sin embargo, una pregunta está sin responder:
¿que criterio puede ser aplicable para particionar un DFD mayor en un conjunto
de DFDs de transformación?
Una técnica suplementaria, llamada análisis de transacción es extremadamente

valiosa para dividir un DFD de alto grado de complejidad en DFDs de menor
complejidad. Esta técnica divide en distintos DFDs, uno para cada transformación
que el sistema procesa. Esos DFDs menores serán suficientemente simples como
para permitir su conversión por medio del análisis de transformaciones en
Diagramas de Estructura (DE). El análisis de transacción también puede ser usado
para combinar los diagramas de estructura individuales (de transacciones
separadas) en un diagrama de estructura mayor y más flexible.
Una transacción, en general, es un estímulo para un sistema que posee un

conjunto de actividades a ser realizadas internamente. Ejemplos de transacciones
son: incluir un nuevo cliente, generar una factura por venta de mercaderías,
actualizar el stock de un producto, disminuir la temperatura de un reactor nuclear,
actualizar archivo maestro o generar el reporte de movimientos de cuenta
corriente.
Aplicar
Transacción
Tipo de
Transacción
Obtener Transacción Transacción Transacción

Tipo de Tipo Tipo Tipo
Transacción A B C
Fig.5: La Estructura Típica de los DE Generados por Análisis de Transacción
26
FCyT - UMSS
Los DE que resultan del análisis de transacción tienen la forma descripta por la
figura 5. De manera similar al análisis de transformaciones, la actividad principal
para derivar un DE a partir del DFD, en el análisis de transacción, es identificar el
centro de transacción. Frecuentemente, es muy fácil reconocer transacciones,
centros de transacciones y procesos de transacción a través del formato del
diagrama. Siempre que un flujo de datos entra en un proceso que determina su
tipo y lo envía a un proceso relacionado con el tipo, se puede tener certeza que
fue localizado un centro de transacciones.
El DFD para un centro de transacción de operaciones en cuenta corriente está

representado en la figura 7.
Registro del Cliente Clientes
Saldo
Generar Movimiento
Informe de
Cuenta
Movimiento
C i t
# de Cuenta s Movimiento
Consultar
Operación Saldo
Deseada de Cuenta Saldo
# de Cuenta
Iniciar
Operaçión Movimiento
# de Cuenta
Deseada # de Cuenta Registrar
Depósito
# de Cuenta Movimiento
Registrar
Extracciones
Valor
Fig. 7: Ejemplo de DFD de Transacciones
El proceso Iniciar Operación Deseada contiene el centro de transacción el cual

activa el proceso apropiado dependiendo de la Operación Deseada. Sin
embargo, la manifestación del centro de transacción en un DFD es
frecuentemente más sutil.
27
FCyT - UMSS
Parámetro de
Direccionamiento Direccionar
el Barco Ángulo de Timón
Direccionamiento
Parámetro de
Curso Ajustar
Curso
Terminal
de Control Giroscópo
Parámetro de Curso Corriente
Seguimiento
Localizar Coordenadas
dcl objetivo
Parámetro de Objetivo
Disparo
Disparar Detalle del Misil
Mísil Disparo
Fig.8: Ejemplo de DFD de Transacciones sin Mostrar el Centro
En el DFD de la figura 8, las diferentes transacciones son identificadas claramente

pero, ¿dónde está el centro de transacción?. Una posibilidad es adicionar un
proceso que recibe todos los flujos de entrada y determine la transacción
adecuada pero, esa situación artificial complicaría innecesariamente el diseño y
tornaría el sistema inflexible (ya que un único proceso debería preocuparse de
todos los tipos de transacciones del sistema).
La solución mas adecuada es incorporar un proceso de control que solamente

reciba la información de control necesaria para determinar la transacción que
tiene que ser ejecutada. En la realidad, un centro de transacción tiene la mayoría
de las veces la funcionalidad de un proceso de control. Así, el DFD de la figura
¡Error! Marcador no definido., con el centro de transacción incorporado, es
mostrado en la figura 9.
Parámetro de
Direcionamiento Direccionar
el Barco Ángulo de Timón
Direcionamiento
Parámetro de
Curso Ajustar
Curso
Terminal
de Control Curso Corriente Giroscópo
Parámetro de
Seguimiento
Señal de Localizar Coordenadas
Control del Objetivo
Objetivo
Parámetro de
Inv. Op. Disparo
Disparar Detalle del Misil
Adecuada Mísil Disparo
Fig.9 : Ejemplo de DFD de Transacciones Incorporando el Centro
28
FCyT - UMSS
El ejemplo de las transacciones bancarias de la figura ¡Error! Marcador no definido.

es un poco diferente. El centro de transacción Iniciar Operación Deseada no fue
incluido artificialmente. Eso se muestra en el DFD, tal vez, por algún motivo de
modelado y puede traer alguna otra funcionalidad diferente a la de control. Ese
es un proceso normal que tiene el rol de control y además tiene la función de
control; ese hecho, puede ser modelado de la forma mostrada en la figura 10.
Registro del Cliente Clientes
Saldo
Generar Movimiento
Reporte de Cuenta Corriente
Movimientos
Consultar
Operación Saldo
Deseada de Cuenta Saldo
# de Cuenta
Iniciar
Operación Movimiento
Deseada # de Cuenta Registrar
# de Cuenta
Depósito
Registrar
Extracción
Valor
Fig. 10: Ejemplo de DFD de Transacciones
Una vez identificado el centro de transacción, el DFD original resulta subdividido en

un número de DFDs menores, uno por cada transacción, que pueden ser
derivados por análisis de transformaciones o, nuevamente, por análisis de
transacción. La figura muestra el DE resultante para los ejemplos de las figuras
¡Error! Marcador no definido. y ¡Error! Marcador no definido..
29
FCyT - UMSS
Gobernar
Barco
Señal de
Control
Obtener Controlar
Señal de Ajustar Localizar Disparar
Dirección Curso Objetivo Mísil
Control del Barco
Transacción
Bancarias
# de Cuenta
Operación
Deseada
# de Cuenta
# de Cuenta # de Cuenta
# de Cuenta
Obtener Generar Registrar Registrar

Operación Reporte Consultar
Deseada de Movims Saldo Depósito Extracción
Fig. 1: DE Para los Ejemplos de las figuras ¡Error! Marcador no definido. y

¡Error! Marcador no definido.
El análisis de transacciones genera un esqueleto de diagrama de estructura que

deberá ser unido (substituyendo las hojas) con los diagramas de estructura de
cada una de las transformaciones identificadas.
30
FCyT - UMSS

Texto Capítulo 1 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Texto Capítulo 1 PDF

Cargado por

Copyright:

Formatos disponibles

Ingeniería de Sistemas II IND-225 Capítulo 1

Este modelo se desarrolla en tres etapas:

a. Desarrollar el Modelo de Programas (Ingeniería de Software)

1.2 El Modelo de Programas: Diseño Estructurado

Se llama Diseño Estructurado al proceso de decidir los componentes necesarios, y

El diseño es una actividad que comienza cuando el analista de sistemas ha

Frecuentemente analista y diseñador son la misma persona, sin embargo es

la otra. Al abordar la etapa de diseño, la persona debe quitarse el sombrero de

1.3 Objetivos Del Diseño Estructurado

"El diseño estructurado, tiende a transformar el desarrollo de software de una

"Diseño" significa planear la forma y método de una solución. Es el proceso que

performance y calidad que la mejor implementación puede alcanzar, y puede

El diseño se caracteriza usualmente por un gran número de decisiones técnicas

Diseño estructurado y calidad del software

Un concepto importante a considerar es el de calidad. Dentro de este concepto,

9 Eficiencia: Se refiere al incremento de la velocidad de ejecución y

9 Confiabilidad. Es importante notar que si bien la confiabilidad del software

9 Mantenibilidad. Se define como:

Mantenibilidad del sistema = ____MTBF___

1.3 Identificación de Procesadores.

Es el primer paso en el desarrollo del Modelo de Implementación. Tiene como

PROCESADOR, que se encargará de desarrollar el proceso. Esta etapa se

No puede quedar ningún proceso sin asignar.

1.4 Diagramas de Estructura

Tiene como objetivo básico el tratar d enfocar la programación a través de

Características de los Diagramas de Estructura:

9 Es gráfico y, por tanto, conciso, fácil de leer, sencillo de preparar.

9 El diagrama de estructura muestra la descomposición de un sistema en

Un módulo se define como un conjunto de sentencias de programa con cuatro

- Entradas/ Salidas: Datos que recibe cuando lo invocan y datos que

Además posee otros atributos adicionales cómo:

Un módulo debe manejarse como una “caja negra”, funcionalmente

El concepto de Caja Negra: Una caja negra es un sistema (o un componente) con

Observemos por ejemplo el siguiente diagrama de organización de una empresa

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

Podemos establecer una analogía con la estructura de programas y es razonable

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

Finalmente observaremos que los administradores suministran a sus subordinados

El establecimiento de un paralelo entre las estructuras organizativas humanas y los

1.6 Manejo de la complejidad

En principio diremos que escribir un programa "grande" generalmente lleva más

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

Intentaremos tomar dos problemas separados y en lugar de escribir dos

M(P+Q) > M(P) + M(Q)

Este fenómeno no es solo válida para el campo de la computación. Es verdadero

1.7 Notación de los Diagramas de Estructura

a. Módulo: Representa un grupo de instrucciones que realiza una única

Módulo CALCULAR SALDOS

Nombre del Módulo

b. Flecha de Invocación. Se presenta como una flecha que va desde el

Módulo Jefe (Invocador)

Módulo Subordinado (Invocado)

Un módulo puede invocar a varios otros que dependen de él:

A su vez, un módulo puede ser invocado por varios módulos

Representa a parámetros de información que pasan a través de los módulos. El

d. Condicional.- Muestra la existencia de un proceso de selección.

1.8. Formato General de un Diagrama de Estructura

En resumen, un Diagrama de Estructura ilustra la partición del sistema en módulos

1.9 Acoplamiento y Cohesión.

El Acoplamiento es la medida de la fuerza de relación entre los módulos

1.10 Estrategias de Transformación

Mantenibilidad del sistema = __MTBF_