Está en la página 1de 10

REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN

UNIVERSIDAD ALEJANDRO DE HUMBOLDT

INGENIERÍA EN INFORMÁTICA

DESARROLLO Y VALIDACIÓN
15%

ALUMNO:

JESUS A. GONZALEZ A.

C.I. No. 26819426

04242739392

CARACAS, NOVIEMBRE DEL 2021


Desarrollo modular.

Una vez que ha sido tomado el enfoque de diseño de arriba hacia abajo, el enfoque modular
es útil en la programación. Este enfoque involucra la división de la programación en partes
o módulos lógicos y manejables. El diseño de programación modular tiene tres ventajas
principales:

 Los módulos son más fáciles de escribir y depurar, debido a que son virtualmente
autocontenido. Así corregir un error en un módulo es más fácil ya que este no causa
problemas en otros módulos.
 Los módulos son más fáciles de mantener. Ya que las modificaciones están
determinadas a unos cuantos módulos y no están dispersas en todo el sistema
programado.
 Los módulos son más fáciles de entender, debido a que son subsistemas
autocontenidos, para una o varias funciones específicas.

Algunos lineamientos para la programación modular incluyen:

 Mantenga cada modulo de un tamaño manejable (idealmente incluyendo una sola


función)
 Ponga particular atención a las interfaces críticas (los datos y las variables de
control que son pasados a otros módulos).
 Minimice la cantidad de módulos que necesite el usuario modificar cuando hace
cambios.
 Mantenga las relaciones jerárquicas puestas en las fases de arriba hacia abajo.

 Modularidad en el ambiente Windows

Microsoft desarrollo dos sistemas para enlazar programas en su ambiente Windows. El


primero es llamado intercambio Dinámico de Datos (DDE), el cual comparte código
usando archivos de bibliotecas de enlace dinámico (DDL).
Mediante el uso de DLL un usuario puede guardar en un programa, tal vez una hoja de
cálculo, tal como Excel, y luego usar esos datos en otro programa, tal como un paquete de
procesador de palabras como el Word para Windows. El programa que contiene los datos
originales es llamado el servidor, y el programa que usa los datos es llamado el cliente. El
enlace DDE, puede ser puesto para que cada vez que el archivo de procesador de palabras
cliente sea abierto, los datos sean automáticamente actualizados y se refleje cualquier
cambio realizado en el archivo de hoja de cálculo servidor desde la última vez que fue
abierto el archivo de procesador de palabras.

Un segundo enfoque al enlace de programas en Windows es llamado Enlace e Inclusión de


Objetos (OLE). Este método de conectar programas es superior al DDE para atar datos y
gráficos de la aplicación. Mientras que el DDE usa un enfoque de cortar y pegar para
enlazar los datos, y no conserva el formateo, el OLE conserva todas las propiedades de los
datos creados originalmente. Este enfoque orientado a objetos permite que el usuario final
permanezca en la aplicación cliente y todavía edite los datos originales en la aplicación
servidora.

 Gráficas de estructura

La herramienta recomendada para el diseño de un sistema de arriba hacia abajo modular es


llamada una gráfica de estructura. Una gráfica de estructura es simplemente un diagrama
que consiste de cuadros rectangulares que representan los módulos y de flechas que los
conectan. La figura 5 muestra tres módulos, etiquetados 1, 1.1 y 1.2.El numero a la derecha
del punto decimal en 1.1 y 1.2 significa que esos módulos son subconjuntos del modulo 1.
En la figura 6 pueden verse las gráficas de estructura creadas mediante el uso del programa
Visio. Se muestra una notación alterna para los tres módulos. Estos están etiquetados 100,
110 y 120, y están conectados usando líneas con ángulos rectos. Los módulos de más alto
nivel están numerados por los 100 o 1.000 y, en cambio, los módulos de nivel inferior están
numerados por 10 y 100.
 Dibujo de una gráfica de estructura

Obviamente, se supone que las gráficas de estructuras deben ser trazadas de arriba hacia
abajo, pero, ¿donde comienza uno a encontrar los procesos que van a convertirse en
módulos. La figura 8 es un diagrama de flujo de datos de un sistema de nomina. Las
entidades son EMPLEADOS y GERENTES DE NOMINA. En el diagrama de flujo de
datos están trazados cuatro procesos.

 1. Verificar solicitud de pago


 2. Calcular el pago.
 3. Actualizar registros de nomina.
 4. Preparar cheques y el resumen.

Observe que hay dos almacenes de datos y muchos flujos de datos. Lo que es mas
importante, observe que el diagrama de flujo de datos esta dispuesto en forma lineal. Ahora
el diagrama de flujo de datos será usado para trazar la gráfica de estructura jerárquica.

 Tipos de módulos

Los módulos de las gráficas de estructuras caen en alguna de tres categorías generales:
Control, Transformación (Llamados trabajadores) y funcionales o especializados. Cuando
se diseñe una gráfica de estructura que sea fácil de desarrollar y modificar es necesario no
mezclar los diferentes tipos de módulos.

 Módulos de control:

Estos se encuentran, por lo general, cerca de la parte superior de la gráfica de estructura y


contiene la lógica para ejecutar los módulos de nivel inferior. Estos módulos pueden estar o
no representados en el DFD. Si un módulo de control tiene más de siete o nueve módulos
subordinados, se deben crear nuevos módulos de control que estén subordinados del
original. La lógica de un módulo de control puede ser determinada a partir de un árbol de
decisión o de una tala de decisión.
 Módulos de transformación

Son aquellos que se crean a partir de un DFD. Por lo general ejecutan solo una tarea,
aunque varias tares secundarias pueden ser asociadas con la tarea primaria Por ejemplo un
módulo llamado “IMPRIMIR LINEA DE TOTAL DE CLIENTE “puede formatear la línea
completa, imprimir la línea, hacer suma a los grandes totales y, por último, poner los totales
del cliente en cero en preparación para la acumulación de las cantidades del siguiente
cliente. Estos tienen un lugar inferior en la estructura de los módulos.

 Módulos funcionales o especializados

Son los más bajos de la estructura, teniendo rara vez módulos subordinados bajo ellos.
Ejecutan solamente una tarea, tal como formatear, leer, calcular, escribir, etc. Algunos de
estos módulos se encuentran en los DFD otros son agregados, tal como la lectura de un
registro o la impresión de una línea de error.

 Subordinación de módulos

Un módulo subordinado es uno inferior en la gráfica de estructura llamado por otro módulo
superior en la estructura. Cada módulo subordinado debe representar una tarea que es una
parte de la función del modulo de nivel superior. Si se permite que el modulo de nivel
inferior ejecute una tarea que no es requerida por el modulo que llama, se denomina
“subordinación impropia”. En tal caso, el o los módulos inferiores son movidos hacia arriba
en la estructura. 

Codificación-programación del software.


Durante esta etapa se realizan las tareas que comúnmente se conocen como programación;
que consiste, esencialmente, en llevar a código fuente, en el lenguaje de programación
elegido, todo lo diseñado en la fase anterior. Esta tarea la realiza el programador, siguiendo
por completo los lineamientos impuestos en el diseño y en consideración siempre a los
requisitos funcionales y no funcionales (ERS) especificados en la primera etapa.
Es común pensar que la etapa de programación o codificación (algunos la llaman
implementación) es la que insume la mayor parte del trabajo de desarrollo del software; sin
embargo, esto puede ser relativo (y generalmente aplicable a sistemas de pequeño porte) ya
que las etapas previas son cruciales, críticas y pueden llevar bastante más tiempo. Se suele
hacer estimaciones de un 30% del tiempo total insumido en la programación, pero esta cifra
no es consistente ya que depende en gran medida de las características del sistema, su
criticidad y el lenguaje de programación elegido. 7 En tanto menor es el nivel del lenguaje
mayor será el tiempo de programación requerido, así por ejemplo se tardaría más tiempo en
codificar un algoritmo en lenguaje ensamblador que el mismo programado en lenguaje C.

Mientras se programa la aplicación, sistema, o software en general, se realizan también


tareas de depuración, esto es la labor de ir liberando al código de los errores factibles de ser
hallados en esta fase (de semántica, sintáctica y lógica). Hay una suerte de solapamiento
con la fase siguiente, ya que para depurar la lógica es necesario realizar pruebas unitarias,
normalmente con datos de prueba; claro es que no todos los errores serán encontrados sólo
en la etapa de programación, habrá otros que se encontrarán durante las etapas
subsiguientes. La aparición de algún error funcional (mala respuesta a los requisitos)
eventualmente puede llevar a retornar a la fase de diseño antes de continuar la codificación.

Durante la fase de programación, el código puede adoptar varios estados, dependiendo de la


forma de trabajo y del lenguaje elegido, a saber:

 Código fuente: es el escrito directamente por los programadores en editores de


texto, lo cual genera el programa. Contiene el conjunto de instrucciones codificadas en
algún lenguaje de alto nivel. Puede estar distribuido en paquetes,
procedimientos, bibliotecas fuente, etc.

 Código objeto: es el código binario o intermedio resultante de procesar con


un compilador el código fuente. Consiste en una traducción completa y de una sola vez
de este último. El código objeto no es inteligible por el ser humano (normalmente es
formato binario) pero tampoco es directamente ejecutable por la computadora.
 Se trata de una representación intermedia entre el código fuente y el código
ejecutable, a los fines de un enlace final con las rutinas de biblioteca y entre
procedimientos o bien para su uso con un pequeño intérprete intermedio [a modo de
distintos ejemplos véase EUPHORIA, (intérprete intermedio), FORTRAN (compilador
puro) MSIL (Microsoft Intermediate Language) (intérprete) y BASIC (intérprete puro,
intérprete intermedio, compilador intermedio o compilador puro, depende de la versión
utilizada)].

o El código objeto no existe si el programador trabaja con un lenguaje a modo


de intérprete puro, en este caso el mismo intérprete se encarga de traducir y ejecutar
línea por línea el código fuente (de acuerdo al flujo del programa), en tiempo de
ejecución. En este caso tampoco existe el o los archivos de código ejecutable. Una
desventaja de esta modalidad es que la ejecución del programa o sistema es un poco
más lenta que si se hiciera con un intérprete intermedio, y bastante más lenta que si
existe el o los archivos de código ejecutable. Es decir no favorece el rendimiento en
velocidad de ejecución. Pero una gran ventaja de la modalidad intérprete puro, es
que él está forma de trabajo facilita enormemente la tarea de depuración del código
fuente (frente a la alternativa de hacerlo con un compilador puro). Frecuentemente
se suele usar una forma mixta de trabajo (si el lenguaje de programación elegido lo
permite), es decir inicialmente trabajar a modo de intérprete puro, y una vez
depurado el código fuente (liberado de errores) se utiliza un compilador del mismo
lenguaje para obtener el código ejecutable completo, con lo cual se agiliza la
depuración y la velocidad de ejecución se optimiza.

 Código ejecutable: Es el código binario resultado de enlazar uno o más fragmentos


de código objeto con las rutinas y bibliotecas necesarias. Constituye uno o más archivos
binarios con un formato tal que el sistema operativo es capaz de cargarlo en la
memoria RAM (eventualmente también parte en una memoria virtual), y proceder a su
ejecución directa. Por lo anterior se dice que el código ejecutable es directamente
«inteligible por la computadora». El código ejecutable, también conocido como código
máquina, no existe si se programa con modalidad de «intérprete puro».

 Diseño de la base de datos.


El diseño de una base de datos no es un proceso sencillo. Habitualmente, la complejidad de
la información y la cantidad de requisitos de los sistemas de información hacen que sea
complicado; por este motivo, cuando se diseñan bases de datos es interesante aplicar la
vieja estrategia de dividir para vencer. Por lo tanto, conviene descomponer el proceso del
diseño en varias etapas; en cada una se obtiene un resultado intermedio que sirve de punto
de partida de la etapa siguiente, y en la última etapa se obtiene el resultado deseado.

El diseño de base de datos se descompone entonces en tres etapas a saber:

 Etapa del diseño conceptual: en esta etapa se obtiene una estructura de la


información de la futura base de datos independiente de la tecnología que se
empleará. No se tiene en cuenta todavía qué tipo de base de datos se utilizará
(relacional, orientada a objetos, jerárquica); tampoco se tiene en cuenta con qué
SGBD (sistema de gestión de base de datos) ni con qué lenguaje concreto se
implementará la base de datos.El resultado de esta etapa es un modelo de flujo de
información de alto nivel, uno de los más empleados es el modelo entidad relación
(ER) y se obtiene luego de entrevistas, visitas y una investigación adecuada del
sistema de información.El diagrama de entidad relación utiliza formas para
representar entidades, atributos y relaciones

 Etapa del diseño lógico: en esta etapa se parte del resultado del diseño conceptual,
que se transforma al tipo de base de datos que vamos a utilizar. Más concretamente,
es preciso que se ajuste al modelo del SGBD con el que se desea implementar la
base de datos. Por ejemplo, si se trata de un SGBD relacional, esta etapa obtendrá
un conjunto de relaciones donde las entidades se transforman a tablas normalizadas
con sus atributos, claves primarias y claves foráneas. El proceso de normalización
que se aplica en esta etapa consiste en una serie de reglas que deben cumplir las
tablas y relaciones obtenidas tras el paso del modelo entidad relación al modelo
relacional, para entonces ser un modelo lógico. Las bases de datos relacionales se
normalizan básicamente para: evitar la redundancia de los datos, evitar problemas
de actualización de los datos en las tablas, proteger la integridad de los datos.
Existen varios niveles de normalización de base de datos, en este caso aplicaremos
las tres primeras formas normales que se describen a continuación:

Primera forma normal (1FN)

Se eliminan todos los campos o atributos repetidos

Se asegura la atomicidad de los campos, en caso de existir atomicidad, se evalúa la creación


de una nueva tabla

Cada tabla debe tener una llave primaria

Se asegura una dependencia funcional respecto a la llave primaria

Segunda forma normal (2FN)

Debe cumplir la primera forma normal

No deben existir dependencias parciales: todos los campos no llaves deben depender solo
de la llave primaria

Tercera forma normal (3FN)

Debe cumplir con la segunda forma normal

No deben existir dependencias transitivas: ningún campo debe depender de un campo no


llave

 Etapa del diseño físico: en esta etapa se transforma la estructura obtenida en la etapa
del diseño lógico, con el objetivo de conseguir una mayor eficiencia; además, se
completa con aspectos de implementación física que dependerán del SGBD.

También podría gustarte