Está en la página 1de 37

Metodología y Tecnología de la Programación II

Programación Estructurada. Diseño Modular

El software

♦ Características
• Producto lógico, no físico
• Se desarrolla, no se fabrica
• No se deteriora.
• Construcción a medida.
• Mantenimiento complicado

♦ Aplicaciones del Software


• Software de sistemas
• Software de tiempo real
• Software de gestión
• Software de ingeniería y científico
• Software empotrado
• Software de computadoras personales
• Software de inteligencia artificial

Z)[)\^]Y_ ` aYb"cYd
 "!#%$'&)(+*

 ?

,.-)/%021'-)/+3 = >
  ; <
: GH
 6
 : EF
 6 798 CD T"UV"WYX
  45 @BA
IKJ LMNOPLQSRO

Departamento de Informática 1
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Evolución del software

♦ 1ª Época (1950)
• La programación de las computadores era un arte
• No se disponía de métodos sistemáticos para desarrollar
software
• No había planificación

♦ 2ª Época (60-70)
• El software como producto de distribución genérica
• Aparece el concepto de mantenimiento del software
• Aumento de la complejidad del código

♦ 3ª Época (72-85)
• Sistemas multiusuario
• Sistemas en tiempo real
• Bases de datos
• Producto de software

♦ 4ª Época (85-)
• Sistemas personales potentes
• Tecnologías orientadas a objetos
• Sistemas expertos
• Redes neuronales
• Computación en paralelo
• Redes de computadoras
• Biocomputación

Departamento de Informática 2
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Mitos del Software


¿Por qué lleva tanto tiempo terminar los programas?
¿Por qué es el coste de desarrollo tan elevado?
¿Por qué no podemos construir un software sin errores?
¿Por qué existe dificultad en la medición del trabajo y del proceso
de desarrollo?
¿Por qué el programa no hace lo que se esperaba?
¿Por qué es difícil modificar los programas?
¿Por qué un aumento del número de personal no ayuda?

Ingeniería del software


• La búsqueda de técnicas que mejorasen la calidad y permitiesen
reducir los costes de las soluciones basadas en computadores
ha sido uno de los objetivos más perseguidos desde los inicios
de la informática
• A mediados de los 60, la creación de un producto software se
convertía en una tarea ‘angustiosa’ (crisis del software), y se
hizo por tanto necesario introducir una serie de herramientas y
procedimientos que facilitaran por un lado, la labor de creación
de nuevo software y por otro, la comprensión y el manejo del
mismo. Estos fueron los inicios de la ingeniería del software

♦ Definición:
Según Bauer (1969), entendemos por ingeniería del software
“el establecimiento y uso de principios de ingeniería robustos,
orientados a obtener software económico, que sea fiable y funcione
eficientemente sobre máquinas reales”

Departamento de Informática 3
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Elementos de la ingeniería del software


• Procedimientos
• Métodos
• Herramientas

1.- Herramientas: proporcionan un soporte automático o


semiautomático para la aplicación de los procedimientos y los
métodos
2.- Métodos: Indican cómo construir técnicamente el software.
Abarcan una gran cantidad de tareas
3.- Procedimientos: Un procedimiento software se puede
caracterizar por un conjunto de actividades que se pueden aplicar
en el desarrollo de cualquier proyecto software así como la forma
de abarcarlas durante el desarrollo del mismo

* Herramientas CASE (Computer-Aided Software Engineering)


Conjunto de herramientas para soportar las tareas de
Ingeniería del software y diseñadas de manera que la
información generada por una de ellas sirva de entrada a otras
* Metodologías de Diseño
- Diseño funcional descendente. El sistema se observa en
términos de las funciones que suministra
- Diseño orientado a objetos. El sistema se observa como
una sociedad de objetos, donde cada elemento del sistema
(objeto), encapsula datos y operaciones

Departamento de Informática 4
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Fases de la Ingeniería del Software

♦ Definición:
1. Se centra en el QUÉ.
2. Intenta identificar:
• Información a procesar
• Función, rendimiento y comportamiento del sistema
deseados
• Interfaces a establecer
• Restricciones de diseño existentes
• Criterios de validación que se necesitan para definir un
sistema correcto

♦ Desarrollo:
1. Se centra en el CÓMO
2. Se define la forma de:
• Diseñar e implementar de las estructuras de datos
• Implementar la funcionalidad como una arquitectura del
software
• Implementar los detalles procedimentales
• Traducir el diseño a un lenguaje de programación
• Realizar las pruebas sobre el software resultante

♦ Mantenimiento:
1. Se centra en los cambios asociados a:
• La corrección de errores
• Adaptaciones requeridas por la evolución del entorno
• Mejoras producidas por los requerimientos del cliente

Departamento de Informática 5
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Modelos de proceso del software

♦ Modelo lineal secuencial (Paradigma del ciclo de vida


clásico)
Enfoque sistemático y secuencial del desarrollo del software
que comienza en un nivel de sistemas y progresa con el
análisis, diseño, codificación, pruebas y mantenimiento.

Anális is Diseño Código Prueba Mantenim iento

Actividades:
1.- Ingeniería y análisis del Sistema/Información
- Ubicación del software en el ámbito donde va a
funcionar, es decir, se analiza el software como parte
de un sistema mayor
- Se resuelve el problema en términos formales
mediante el uso de alguna herramienta de
especificación formal
- Objetivos:
o Identificar las necesidades del cliente
o Evaluar la viabilidad del sistema (técnica,
económica y legal)
o Asignar funciones al software, al hardware, a la
gente, a la base de datos y a otros elementos del
sistema
o Establecer restricciones de coste y tiempo
o Crear una definición del sistema que sea la base
de todo el trabajo posterior

Departamento de Informática 6
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

2.- Análisis de los requisitos del software


- Proceso de descubrimiento y refinamiento detallado de
las tareas que debe desarrollar un programa
- Se deben conocer los aspectos relacionados con la
información a tratar, la función requerida,
comportamiento, rendimiento, etc del software
- El cliente debe dar el visto bueno
3.- Diseño
Se centra en los siguientes aspectos:
- La estructura de los datos y del programa
- La arquitectura del software
- El detalle procedimental (algoritmo)
- La representación de la interfaz
- Diseño de los casos de prueba
4.- Generación de código o Implementación
- Traducción del diseño a un lenguaje de programación
- Puede automatizarse si el diseño está bien detallado
- Paralelamente se crea el Manual de Usuario
5.- Pruebas
- De Caja Blanca: Análisis de los distintos caminos de
ejecución de los algoritmos
- De Caja Negra: Análisis de los procesos externos
funcionales
6.- Mantenimiento
Gestión de cambios en el software debidos a:
- Errores durante el desarrollo
- Adaptación a nuevos entornos. Ej. Sistema operativo
- Mejoras funcionales o de rendimiento
Departamento de Informática 7
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Departamento de Informática 8
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Documentación
- Todo software debe ir acompañado de una documentación que
permita a sus usuarios aprender a utilizarlo y mantenerlo
- Su correcto desarrollo es una parte importante en la Ingeniería
del Software
- Podemos distinguir los siguientes documentos que deben
acompañar a cualquier desarrollo software, si bien, su extensión
dependerá del alcance del proyecto

Documento de Análisis
1. Análisis básico del sistema
Definición del problema
Estrategia de solución y objetivos del software


Propuestas de solución y estudio de viabilidad




2. Especificación de los requerimientos del software


3. Manual preliminar de usuario

Documento de Diseño
1. Especificación de las representación de la información
2. Diseño Arquitectónico
Descomposición modular, interfaces de los módulos e
interrelación entre ellos
3. Diseño Detallado
Descripción detallada de la funcionalidad de cada módulo
utilizando pseudocódigo o lenguaje natural no ambiguo
4. Documento de pruebas
Plan de pruebas a realizar sobre el software para
detectar fallos

Departamento de Informática 9
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Código y Estilo de programación


Es una de las características más importantes en el desarrollo de software
La calidad de los programas suele tener relación directa con la escritura
de los mismos, su legibilidad y comprensibilidad. Hay que conseguir que
el código sea legible y modificable tanto por el desarrollador como por
otras personas ajenas
El estilo de programación se consigue con la práctica aunque hay algunas


normas que se deben seguir:

1. Buen diseño modular


2. Definir módulos que hagan una sola cosa y bien
3. Evitar el acceso a variables globales en los subprogramas
4. Utilizar identificadores descriptivos
5. Utilizar constantes
6. Utilizar declaraciones de tipos
7. Uso adecuado de los parámetros por variable. ¡Efectos laterales!
8. Uso de comentarios adecuados en código (Ej. Página 15)
De prólogo:


- Tarea del módulo


- Descripción de la interfaz y parámetros
- Lista de módulos que utiliza
- Autor y fecha
Descriptivos


NO parafrasear código
9. Buen manejo de errores
Controlar errores en los datos de entrada y en las operaciones


Departamento de Informática 10
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Evitar mensajes de error en subalgoritmos. Devolver códigos de


error
10. Legibilidad del código
Usar paréntesis
Uso de espacios en blanco en expresiones
Tabulación y sangrado en estructuras
Uso de mayúsculas y minúsculas
Separadores de bloques

Normas generales a seguir para nombrar identificadores:


• Los identificadores son uno de los elementos más importantes en la
documentación del código. Dedicar algún tiempo a elegirlos
adecuadamente

• Utilizar identificadores que reflejen el tipo y uso al que se destinarán

• En caso de utilizar palabras compuestas se suele seguir alguna de


estas dos convenciones
o Palabras concatenadas comenzando por mayúscula cada
palabra a partir de la segunda.
Ejemplo: tempActual, velocidadMaxima
o Separar las palabras que componen el identificador con un guión
bajo.
Ejemplo: temp_actual, velocidad_máxima

• No usar la eñe (ñ) ni vocales acentuadas. En general, no utilizar


caracteres alfanuméricos no incluido en el código ASCII. Aunque
algunos lenguajes las aceptan, dificultan la portabilidad del algoritmo.
Ejemplo: anio, year
• Utilizar siempre los mismos identificadores para tareas comunes, como
o i,j y k, para contadores de ciclos
o encontrado, para centinelas en ciclos
Departamento de Informática 11
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

o total, resultado, acum, para acumuladores de resultados

• Acompañar en su declaración de algún comentario para aclarar aún


más su cometido.
Ejemplo: float desvTipNotas; /*Desviación típica
de las notas de cada alumno */

Normas Particulares
Constantes:
• Utilización de mayúsculas para todo el identificador
Ejemplo: const int PI = 3.14159;

Declaración de Tipos:
• Comenzar todos los tipos definidos por el usuario por una T mayúscula
Ejemplo: Talumno, Tvehiculo,
TdiaDeLaSemana, Tfecha

Variables o parámetros:
• Utilizar la primera letra del identificador en minúscula
Ejemplo: float temperatura;
• Las palabras que los componen suelen ser sustantivos y adjetivos. No
tienen sentido las formas verbales

• Utilizar identificadores en plural para los arrays.


Ejemplo: float temperaturas[10],
float *calificaciones

• Diferenciar las variables que contienen tipos básicos de las que tienen
tipos referenciales (punteros)
Ejemplo: float temperatura, float *Ptemperatura

En el segundo ejemplo tenemos una variable que contiene la dirección


de memoria (puntero) de un dato real que representa una temperatura

Departamento de Informática 12
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Procedimientos y funciones:
• Utilizar la primera letra del identificador en mayúscula
Ejemplo: LeerTemperatura

• Entre las palabras que componen el identificador suele haber alguna


forma verbal que indica la acción que realiza el subalgoritmo
Ejemplo: DibujarPantalla, SeleccionarMenu,
OrdenacionSelección, GuardarDatos

No se suele utilizar en módulos que realizan cálculos matemáticos


Ejemplo: Factorial, Potencia

• Utilizar el mismo tiempo verbal en todos los procedimientos y


funciones.
Ejemplo: DibujarPantalla, SeleccionarMenu o
DibujaPantalla, SeleccionaMenu

Entrada y Salida de datos


- Hay que seguir unas normas generales
- Finalidad: conseguir programas con unas entradas de datos
rápidas, interactivas y correctas; así como una presentación
adecuada de los resultados
- Norma fundamental: independizar los módulos de entrada
de datos, de los de salida de resultados y de los que
realizan cálculos

Departamento de Informática 13
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

• Entrada de datos:
- Dispositivos de entrada de datos:
- Teclado, archivos, etc
- Petición de entradas interactivas:
- Etiquetar las peticiones
- Usar indicativos de “fin de dato”
- No agobiar al usuario
- Uso intensivo de las posibilidades del compilador
- Posibilidad de almacenamiento para volver a ejecutar
el programa con los mismos datos o modificandolos
- Advertencia de valores “peligrosos”
- Validación de datos:
- Comprobación de rangos
- Comprobación de tipos
- Lectura de opciones (Menú):
- Opciones independientes de minúsculas o mayúsculas
- Dar la posibilidad de introducir la opción por alguna
inicial o por un número
- Aconsejable utilizar un sistema de cursores

• Salida de datos
- Etiquetar las salidas de datos
- Posibilitar la salida a otros dispositivos: archivos,
impresora, etc
- Salida ordenada y “elegante”
- Utilización de gráficos
- Evitar la superposición de resultados
- El programa siempre debe aparentar estar “vivo”

Departamento de Informática 14
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

EJEMPLO DOCUMENTACIÓN DEL CÓDIGO


program Media_Datos;
const
MAX = 100; (*Nº máximo de elementos del vector*)
type
datos = ARRAY [1..MAX] of integer;
var
almacen: datos; (*vector con elementos a procesar*)
num: integer;(*Elementos en una ejecución concreta*)
(* ------------------------------------------------- *)
Procedure Mostrar_Datos(VAR V:datos; tam:integer);
(* Muestra por pantalla los ‘tam’ elementos del vector ‘V’ *)
var
i:integer;
begin
for i:=1 to tam do
write(V[i], ‘ ‘);
writeln;
end;
(* ------------------------------------------------- *)
Procedure Generar_Datos(VAR V:datos; tam:integer);
(*Entrada: V, vector vacio y tam, número de elementos
a insertar en el vector
Salida: V, vector con tam números aleatorios*)
var
i:integer;
begin
for i:=1 to tam do
V[i]:=random(10);(* Número entero entre 0 y 9 *)
end;

Departamento de Informática 15
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

(* --------------------------------------------------- *)
Function Media_Datos(VAR V:datos; tam:integer);
(* Función que calcula la Media Aritmética de los
‘tam’ números enteros del vector ‘V’ *)
var
acum:integer;
begin
acum:=0;
for i:=1 to tam do
acum:= acum + V[i];
Media_Datos:= acum / tam;
end;
(* --------------------------------------------------- *)
begin {Programa Principal}
randomize; (*Inicializador del Generador de
Números Aleatorios del T.P. *)
repeat
writeln(‘Introduce el número de elementos
entre (1-‘,MAX,’): ‘);
readln(num);
until ((num>0) and (num <=MAX));
Generar_Datos(almacen,num);
Mostrar_Datos(almacen,num);
writeln (‘La media de los ‘ ,num,‘valores es:‘,
Media_Datos(almacen,num);
readln;
end.

Departamento de Informática 16
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Desarrollo Estructurado
• Existen diferentes metodologías de diseño
• Nosotros nos centraremos en una metodología de diseño
sencilla denominada Desarrollo Estructurado, que se apoya
esencialmente en el uso de la Programación Estructurada y en
el Diseño Modular

Programación estructurada
• Es la metodología más utilizada
• Fue propuesta por Dijkstra a principios de los años 70
• Fue implementada por Wirth en el lenguaje Pascal

♦ Fundamentos de la Programación Estructurada


Se basa en el uso de tres técnicas:
• Diseño descendente (top-down): dividir el problema original
en subproblemas más pequeños hasta llegar a problemas
simples
• Recursos abstractos: una determinada acción compleja se
debe descomponer en función de un número de acciones más
simples. De esta forma el programador podrá resolver un
problema de forma abstracta, sin concretar detalles
• Estructuras de control: las que tienen un único punto de
entrada y un único punto de salida:
• La estructura secuencial
• La estructura condicional
• La estructura repetitiva o iterativa

Departamento de Informática 17
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

♦ Ventajas de la Programación estructurada


• Incremento de la productividad
• Aumento de la calidad del software desarrollado

♦ Teorema de Bohm-Jacopini
También conocido como Teorema general de la Programación
Estructurada:

“Todo programa propio puede escribirse utilizando únicamente


las tres estructuras de control básicas de la programación
estructurada”

Un programa propio es aquel que cumple tres condiciones:


• Tiene una única entrada y una única salida
• Existen caminos desde la entrada hasta la salida que
pasan por todas las partes del programa
• Todas las sentencias sin ejecutables y no aparecen
bucles infinitos

Departamento de Informática 18
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Diseño Modular
• Objetivo: Conseguir una visión del C os te total
C os te
software como una estructura
jerárquica de módulos R e gión de
cos to m ím im o
C os te de la
in te rfaz

E(P1∪P2)>E(P1)+E(P2)

Ideas fundamentales C os to por


m ódu lo
Nº de m ódu los
• Reducir el esfuerzo de desarrollo
• Separación entre estructuras de datos y procedimientos
• Independencia funcional. Cada módulo debe realizar una
tarea concreta que afecte lo menor posible al resto
• Ocultamiento de Información: La información de un
módulo es inaccesible para el resto de módulos
Ventajas
• Evita la propagación de errores
• Facilita las interfaces e independiza la codificación
Conceptos
• Acoplamiento
Grado de interdependencia de los módulos
• Cohesión
Grado del alcance de la tarea de un módulo
Criterios a seguir durante el diseño
• Reducir acoplamiento
• Aumentar la cohesión
• Conseguir módulos con interfaces sencillas

Departamento de Informática 19
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Diseño Estructurado
Concepto
Es el proceso de definición de la arquitectura software:
componentes, módulos, interfaces, procedimientos de prueba
y datos de un sistema, que se crean para satisfacer unos
requisitos previamente especificados
Objetivos
• Obtener una estructura modular y los detalles de proceso
del sistema partiendo solamente de la información obtenida
en la fase de Análisis del Sistema
• Especificar cómo se va a construir el sistema
• Obtener un diseño que funcione, que sea fácil de mantener,
favorezca la reutilización y se pueda probar y comprender
fácilmente
• Utilizar métodos gráficos (diagramas de estructuras) para
representar la estructura modular del sistema
Fases
Atendiendo al nivel de detalle con que abordemos esta fase,
distinguiremos tres fases:
• Diseño procedural o arquitectónico
Proceso de definición de la colección de componentes
del sistema y sus interfaces
• Diseño de la Interfaz
Establecer la forma de comunicación con las entidades
externas ya sean humanas o no humanas
• Diseño detallado
Descripción más detallada de la lógica del proceso
(pseudocódigo) y de las estructuras de datos
Departamento de Informática 20
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Tareas
• Determinar qué módulos implementarán los procesos
terminales obtenidos en la fase de análisis
• Organizar la estructura de estos módulos y definir las
conexiones entre los mismos
• Describir el pseudocódigo para cada módulo

"$#&%('*),+-/.1023#
¿ &¾ ÀuÁ 8¼ ¶· Ãe ¾&À
´ §&¨u¯*°8µ²© £© §&¨ ´ §&¨(¯*°^¢¤£Š¥?¦ §&¨ ¿ ¾&ÀuÁ ¼ÄÅÃŠÆŠÇ ¾&À
¶8·¸!¹º8»/¼» ¶8·3¸!¹bº8» ¼»
´ §&¨(¯*°8µ²© £© §&¨ ½Š¾ ¸¼!»
½Š¾ ¸¼!»
TUWVX/Y8Z[U i1j kBl/monpj q!mr
45687619;:3<5>=(973:?53@ABA*=C9;687 s m&nut*vk/w8xyj z*j mon|{k~}
DFE G8G&HJILKENMO8P8QBR S*R KE ^
\
] &
_ b
` 
a e
c f
d 
\ 
g 
_ h
?€B‚ƒ;„†…‚‡„‰ˆŠ‚&ƒ‹!Œ*„;‚8Ž
¿ ¾&À(Á ¼ÄÅÃŠÆŠÇ ¾&À
 
 ÈÊÉˊÌÍÎË/Ï&ÐÑÒÉÓÔ ¶8·¸!¹º8»/¼»
 ! ÕÖ8×ØÚÙ ÛÖ!Û ½Š¾ ¸¼»
Š‘Š’Š“”•—–˜‘Š•!–• ¤¢ £Š¥?¦Š§o¨ª©|«§¬®­/§o¨u¯*°—±
™š/›&œžŸ ¡ ©(²?£y¬b±&³±1²;¥3§¬~£y°&²¥3§¯°¬b±8­

Departamento de Informática 21
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular



 !"#%$'&)(*,+-/.012143653!.7389:3
;<>=@?BADC EFGHBI@JK#L!M7NH6OQP!F#RTSULV
WX2YZQ[\^]`_ a2bdc
egfih@jklnmpo
qrjsQjit^u`v w x y{z | }~2~2~
€>ƒ‚…„
†‡ˆ„
‡‰BŠ`‹ Œ1)Ž7B’‘“”Ž•–2—d˜–Ž™#š7–6›œi‘’ž!š"#%'Ÿ)—U¡ -™#š –
¢ £1¤¦¥1§4¨©¨!¥¢7¨ª9«:¨¡¢1¬!¥'¬­¤)ª•¨!¢«’¬!¥7¤®B¯!¤¤2¥1§ª°¨#¯-¨2±

²1³2´µ’¶!³·¶-¸¸!¹¸¦º1»µ’¼1½
¾¿ÀÁ@ÀÃÂ-Ä^ÅƔÀÃÇ È”É Ê Ë ÌBÍ
ÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÏ#Ð

#include <stdio.h>
#include <conio.h>
ÑÒ!Ó2ÔÕ1Ö×ÔØrÙUÚÛBÜÃÙÞÝßØiÔ2Ù*ÚiÛ"àá1Ý-â7Ûã4Ô!â1ã“ÚÛ1Ò#Ñ

const iva=0.16;
äåææææææææææææææææææææææææææææææææææ æææææ

ç èßéœêìëêîíêï-ë7èiðBñ-è¡éò#ëíê’ï!ë7èð"ó¡ô#õ“ï!í7è!ñ
êdöBê×è2ë1÷7ïð

øøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøøù#ú
void S_Inicial (float *inicial);
void Proceso (float inicial, float *actual, int *pag,
int *ing);
void Informe (float inicial, float actual, int ing,
int pag);
void Leer (char *tipo, float *cantidad);
void Actualizar (char tipoOper, float cantidad, float
*actual, int *ing, int *pag);

Departamento de Informática 22
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular



 


void main (void) {
float saldoInicial, saldoActual;
int ingresos, pagos;

  !#"$%"&'"(")*,+.-0/21'&34$5361)7982-:'73!/36")
S_Inicial (&saldoInicial);

; < =!=#>?%>@'>(>)=A,B.C0D2E'@F4?5F6E)G9H2CIBJC'D2EKLC(<;
Proceso (saldoInicial, &saldoActual, &ingresos, &pagos);

; <MFN?OA,BPEKFQC'GO@0EBREK S'TVUXWY[Z\]0^!_9`aZb2c%d\Oef
Informe (saldoInicial, saldoActual, ingresos, pagos)
};

fe ghgighgighghgighgighghgighgighghgighgighghgighgighghgighgighghgighgighghgighgighghgighgighghgighgighghgighgighghgighgighghgighgighghgighgighghgighgighghgig
jlk6mn9o)pQkNqLoMksr2mLtuvnwwkQx'r2ymOo)pn9mn9ou9kQx{z|p}yymo)pV~[xMk!rkswk6o)p
h hihihhihihhihihhihihhihihhihihhihihhih hhihihhihihhihihhihihhihihhihihhihihh €
void S_Inicial (float *inicial) {
printf ("Control de una cuenta corriente\n\n");
printf ("Opciones a introducir en cada caso\n");
printf ("i (Ingreso), p (Pago), f (Fin
programa)\n\n");
printf ("Introduzca saldo inicial ");
scanf ("%f",inicial)
}; ‚ƒ„…‡†'ˆ‰sŠ‰6‹)Œ}ƒ‚

Departamento de Informática 23
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

 

          !"$#% & '#% & ( )!&*+ +,-+.#)0/1 02345627 8.#%&+
9:+;<+9.=>?=@=%AB91AC=:+DE+;F
D.=G AC=E<H7AF
DGAID&JAF(9:K)DE L&M
N NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN 
O P
void Proceso (float inicial, float *actual, int *pag, int
*ing) {

char tipoOper; QRST0UVWXIV&UXY(Z[T)\]^ T_]`YX&aV$bWXUVaT)ScVdVeUZ`&VRQ


float cantidad;

*ing = 0;
*pag = 0;
*actual = inicial;

Leer (&tipoOper, &cantidad); fg.h%i.j+klmn8o4m+p0q7imnroimnjp s tgf

while (tipoOper != 'f') {


Actualizar (tipoOper, cantidad, actual, ing,
pag);
Leer (&tipoOper, &cantidad);
};
}; uv&wx
yz{&|y}vu

uv ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~


&€34‚5ƒ6€7„8…†.‡%†&‚+ƒ ˆ}…ƒ_‰ƒ_Šƒ‹†.‡Œ8ƒ@‰†.‡_ŽŒ‰€7„‚
ˆ‘ „’ˆ„‚†Šƒ ˆ‰„&…
“ “““““““““““““““““““““““““““““““““““““““““““““““““““““““““““““““““““““““““““““ ”•
void Informe(float inicial, float actual, int ing, int
pag) {

printf ("Saldo inicial : %f \n", inicial);


printf ("Saldo final : %f \n", actual);
printf ("Numero de ingresos realizados : %.0d \n",
ing);
printf ("Numero de pagos realizados : %.0d \n", pag);
}; –—&˜™+š›œ7ž—–

Departamento de Informática 24
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

  

  
 
 !
void Leer (char *tipo, float *cantidad) {

clrscr();
printf("i (ingreso); p (pago); f (fin) \n");
do {
scanf("%c",tipo);
} while ((*tipo!= 'i')&&(*tipo!='p')&&(*tipo!='f'));
if (*tipo != 'f') {
printf ("Cantidad a procesar \n");
scanf("%.0f",cantidad)
};
}; "$#&%('&'*)#+"
,- ..............................................................................
/1032457698;:<5>=?5
6A@B50 245
6CD8FE0GCHICE2 5CJ603BE235@ KLNM7OQP7L?RSKSIKTUPKS
VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV WX
void Actualizar ( char tipoOper, float cantidad, float
*actual, int *ing, int *pag ) {
switch (tipoOper) {
case 'i':
*actual = *actual + cantidad;
*ing =*ing + 1;
printf ("Ingreso la cantidad %.1f \n",cantidad);
printf ("Saldo actual : %.1f \f \n", *actual);
break;
case 'P':
*actual = *actual - cantidad;
*pag = *pag + 1;
printf ("Pago efectuado: %.0f \n",cantidad);
printf ("Saldo Actual : %.0f \n", *actual);
break;
default: printf ("Operacion %c no válida, ignorada\n"
, tipoOper);
};
};
if (*actual < 0)
printf ("Precaucion, descubierto en cuenta \n");
}; Y$Z&[]\J^$_J`Iacbedf`&gZ+Y

Departamento de Informática 25
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

El diagrama de estructura
La arquitectura de un programa representa la organización jerárquica entre
sus distintos componentes o módulos, es decir, representa la jerarquía de
control

Un diagrama de estructura es un diagrama en forma de árbol. Está


compuesto por tres elementos básicos:
• Módulos
• Conexiones entre módulos
• Comunicación entre módulos
Un módulo es un conjunto de sentencias de programa (programa,
subprograma o rutina) a las cuales podemos referirnos mediante un nombre

m ó d u lo
m ó d u lo
b ib lio tec a

Las conexiones entre módulos representan la llamada a uno de ellos que


se hace desde otro. Se representan mediante arcos dirigidos. 2 conceptos:
abanico de salida y abanico de entrada
A C
A

B C D B

o bte n e r
d atos
La comunicación entre módulos se representa clie nte

utilizando flechas que indican el sentido de la n o m b re c lie n te n ºc ta . c lie n te


información. Dos tipos: datos y control n ºc ta . c o rrec to
e ncontrar
n ombre

• Los indicadores de control sirven para


clie nte

sincronizar los procesos e indicar la ocurrencia de un suceso determinado


• Representan información interna al sistema. No son procesados por el
sistema

Departamento de Informática 26
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Composición de módulos
♦ Secuencia
Indica cuando un módulo llama a varios y esto A

se realiza una vez. La secuencia de ejecución


suele ser de izquierda a derecha
B C D

♦ Iteración
A
Ocurre cuando se llama a los módulos
subordinados varias veces. El arco engloba a los
módulos implicados
B C D

♦ Decisión
A
Representa una elección del módulo superior
sobre el módulo subordinado al que llamará
B C D

♦ División de un diagrama 1
A
Estos símbolos se utilizan para descomponer un
diagrama en varios subconjuntos. Ayuda a D
clarificar el diagrama B C

♦ Almacén de datos 1

Representación física donde van a estar


almacenados los datos en realidad
NO M B RE

♦ Dispositivo Físico
Cualquier dispositivo por el que se puede recibir o
Dispositiv o
enviar información que necesite el sistema

Departamento de Informática 27
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Ejemplo 1
Sistema de gestión de pagos

Departamento de Informática 28
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Ejemplo 2
Sistema de gestión de notas de alumnos

G e s tió n
A lum no s

o pc i ó n po s
po s po s c o dO p

Le e r A lta M o dific a B a ja C o nsulta


O pc ió n A lum no A lum no A lum no A lum no
dato s
al um no dato s
c o ns ul ta dato s
1 al um no
1
nue vo s po s
dato s 2
Leer
E dita r al um no D a to s V is ua liza
A lum no 2 B us que da A lum no
dato s 1
c o dO p 3
al um no dato s c o dO p
po s c o dO p dato s
al um no al um no c o dO p
G ua rda R e c upe ra
A lum no A lum no M o s tr ar
M e ns aje

Departamento de Informática 29
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Evaluación del diseño


Criterios de evaluación:

• Acoplamiento

Mide el grado de interdependencia entre los módulos de un


sistema. Puede definirse como la probabilidad de que al
modificar o codificar un módulo tengan que considerarse
detalles relativos a otros módulos
Los módulos deben tener un acoplamiento bajo. Ser


independientes
Objetivo: Reducir la complejidad de la Interfaz entre


módulos. Regla: si es difícil entender lo que hace una


llamada, la interfaz es compleja

• Cohesión

Es la medida de la fuerza o relación funcional de los




elementos de un módulo, entendidos como el conjunto de


sentencias que lo componen, las definiciones de datos o las
llamadas a otros módulos

Un módulo coherente ejecuta una tarea sencilla y requiere




poca interacción con otros procedimientos que se ejecuten


en otras partes del programa. Idealmente solo hace una
cosa

Los módulos deben tener cohesión alta




Regla de diseño:
Asegurar que los módulos tienen una buena cohesión es la
mejor manera de minimizar el acoplamiento
Departamento de Informática 30
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Clases de Acoplamiento
Normal Mejor
Por datos
Por estampado
Por control

Común


Por variables globales


Por base de datos
Peor
Por contenido


♦ Acoplamiento Normal A

Existe cuando un módulo llama a otro y cuando éste termina su


ejecución le devuelve el control al primero B

• Por Datos
Acoplamiento normal donde solo hay un paso de parámetros sin estructura
interna (carácter, entero, real o tabla homogénea)
Bu s ca r
• Por estampado tra n sis to r

Acoplamiento normal donde alguno de los parámetros tiene tra n sis to r


estructura interna. El módulo llamado depende de esta
estructura. Utilizar solo en el caso de que haga falta toda la Visu a liza
información de la estructura T ra n sis to r

obte ne r
• Por control datos
transistor

Cuando el módulo que llama pasa un dato que tra n sis to r


ref_tra n s
controla el comportamiento interno del módulo llamado
ref_v álida
En sentido inverso puede ser aceptable siempre que
Rec u p er a
no ocurra una Inversión de Autoridad (controlar el T ra n sis to r
módulo superior!!)

Departamento de Informática 31
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

♦ Acoplamiento Común A B
• Por variables globales
x
x
Ocurre cuando varios módulos utilizan una misma
área de datos de ámbito global Ár ea d e
d ato s g lo b a l
Inconvenientes
• Un defecto en un módulo que utilice un área de datos global puede
transmitirse a otros que también la utilicen
• Limita la capacidad de los módulos al trabajar sobre datos con un
único nombre. Frente a esto, los parámetros pueden hacer
referencia a cualquier elemento de datos
• Puede ser difícil conocer qué módulo fue el que actualizó por última
vez el área de datos global

• Por base de datos


En ocasiones es necesaria la utilización de A B
estructuras globales.
x
x

C lu ster
Por ejemplo al acceder a un área de datos muy Escribir Lee r
grande (array) o el acceso a un fichero. En este Transistor Transistor
caso se define un cluster que es un conjunto de
módulos que permiten el acceso al área de datos
Ar ea d e d a to s
global pero que ocultan al resto del sistema su
representación

Los TDA suelen utilizarse para la construcción de clusters

Inconvenientes
• Lejanía entre la creación de un error y su posterior descubrimiento
• Los errores pueden transmitirse entre módulos

Ventajas frente al acoplamiento por área global:


• Un buen diseño del cluster o base de datos evita problemas
• El acceso a los datos suele estar limitado a partes del área de datos

Departamento de Informática 32
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

♦ Acoplamiento por contenido


Un módulo necesita o accede a una parte de
otro, rompiendo la jerarquía de funcionalidad A
del diagrama de estructuras x

x
B C
Cuando ocurre hay que descomponer el
módulo al que se accede o duplicar esa parte
de código en el módulo que realiza la llamada

Los módulos acoplados por contenido son muy dependientes y una


modificación en uno de ellos puede provocar un mal funcionamiento en el
otro

Acceder a una parte de otro puede significar:


• Que uno de ellos salta al interior del otro.
• Que uno de ellos lee o modifica datos internos del otro
• Que uno de ellos cambie instrucciones del otro módulo

• No es necesario en ningún caso y se debe evitar a toda costa.


• El uso de las sentencias de salto incondicional (go to) produce este tipo
de acoplamiento
• Suele encontrarse cuando se programa en ensamblador. Utilizar
subrutinas para evitarlo (call ... ret)

♦ Datos vagabundos
• Son aquellos que pasan por la mayor parte de los módulos sin ser
usados por estos

• Deben ser evitados en cualquiera de los tipos de acoplamiento

• Es un síntoma de una mala estructuración del sistema

Departamento de Informática 33
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

♦ Resumen de tipos de acoplamiento


Cuando dos módulos están acoplados de diferentes formas, entonces se
dicen que están acoplados por el peor tipo

Tipo de Transmisión Modificabilidad Comprensión Reutilización


acoplamiento de errores
De datos Variable Buena Buena Bueno
Por Variable Media Media Medio
estampado
De control Medio Pobre Pobre Pobre
Común Malo Media Mala Pobre
Por contenido Malo Media Mala Malo

Clases de Cohesión

1. Funcional
2. Secuencial Mejor
3. Comunicacional
4. Procedural
5. Temporal Cohesión débil
6. Lógica
7. Casual (Coincidental)
(peor mantenimiento)

♦ Cohesión Funcional
Los elementos del módulo contribuyen a la realización de una tarea única del
sistema. Ejemplo: RaizCuadrada, ActivarAlarma

♦ Cohesión Sencuencial
El módulo realiza diversas tareas de forma secuencial (importa el orden). La
salida de una tarea sirve de entrada para la siguiente. Ejemplo: Módulo que
lee un registro y valida los datos

Departamento de Informática 34
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

♦ Cohesión Comunicacional obte ne r


datos
Varias tareas que se realizan de forma paralela (no clie nte

importa el orden). Utilizan los mismos datos de entrada nclie


o m b re
n te
n ºcta.
clie n te
y/o salida sa ld o
p re stam o
e ncontrar
datos

♦ Cohesión Procedural
clie nte

Las tareas de un módulo realizan actividades diferentes y posiblemente sin


relacionar. El orden de realización es secuencial. Existe poca relación entre
los datos de entrada y salida de las tareas

Ejemplos:

1.- CompruebaDispositivo, ApagaAlarma, CalculaHora,


AvisaUsuario
2.- VisualizaTransistor, EstableceValoresCero,
LeeTransistor

♦ Cohesión Temporal
Las tareas del módulo realizan actividades relacionadas en el tiempo. No
importa el orden de realización
Ejemplo:
Módulo GuardarInformación:
AbrirArchivoA, AbrirArchivoB, GuardarTransistores,
GuardarConfiguración, CerrarArchivoA, CerrarArchivoB

♦ Cohesión Lógica
Un módulo contiene diferentes taréas similares que son seleccionadas desde
fuera del módulo
Ejemplo:
CrearLista, ModificarElemento, InsertarElemento, etc.

Departamento de Informática 35
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

♦ Cohesión Casual
Las tareas del módulo no están relacionadas de forma significativa. Ocurre
cuando se intenta englobar un conjunto de instrucciones parecidas, que no
se van a ejecutar a la vez, dentro de un mismo módulo

Características:
• Difíciles de entender y mantener
• Los módulos que los utilizan deben utilizar datos de control totalmente
artificiales para seleccionar la parte que se desea utilizar

Ejemplo:

SuperMódulo (opcion,...)
En caso de que opcion valga
1: AbrirArchivo
2: CrearLista
3: Buscar Elemento en la Lista
4: Calcular el Factor de Amplificación del transistor
Fin_en_caso

♦ Factores a los que afecta la cohesión

Nivel de Acoplam. Facilidad Comprens. Modificab. Mantenimiento


Cohesión Implantación Sistema
Funcional Bueno Buena Buena Buena Bueno
Secuencial Bueno Buena Buena Buena Bast. buen.
Comunicac. Medio Media Media Media Medio
Procedural Variable Pobre Variable Variable Malo
Temporal Pobre Media Media Media Malo
Lógica Malo Mala Mala Pobre Malo
Casual Malo Pobre Mala Mala Malo

Departamento de Informática 36
Metodología y Tecnología de la Programación II
Programación Estructurada. Diseño Modular

Factores en la calidad del software

Durante el desarrollo de software se deben tener en cuenta diversos factores


que afectarán a su calidad.

Eficiencia
Buen uso de los recursos de la máquina: CPU y memoria

Portabilidad
Facilidad para adaptar el software a diversas plataformas

Verificabilidad
Facilidad a la hora de soportar procedimentos de prueba

Integridad
Protección de los recursos propios frente a efectos externos

Facilidad de utilización
Interfaz de usuario clara y eficaz

Corrección (exactitud)
Realización de las tareas especificadas por el cliente

Robustez
Funcionamiento frente a situaciones anómalas

Extensibilidad
Facilidad de adaptarse a cambios

Reutilización
Volver a utilizar todo o en parte en otros productos

Compatibilidad
Facilidad para interaccionar con otros productos

Departamento de Informática 37