Tema1 MTP2

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
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
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”
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
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
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
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
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
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

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
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
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
• 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”
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;
(* --------------------------------------------------- *)
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.
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
♦ 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
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
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
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Â ¾&À
´ §&ü¯*°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ü¯*°±
/& ¡ ©(²?£y¬b±&³±1²;¥3§¬~£y°&²¥3§¯°¬b±8

!"#%$'&)(*,+-/.012143653!.7389:3
;<>=@?BADC EFGHBI@JK#L!M7NH6OQP!F#RTSULV
WX2YZQ[\^]`_ a2bdc
egfih@jklnmpo
qrjsQjitû`v w x y{z | }~2~2~
>

B` 1)7B2d#76i!"#%')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);

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àZb2c%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)
}; 's6)}

!"$#% & '#% & ()!&*++,-+.#)0/1 02345627 8.#%&+
9:+;<+9.=>?=@=%AB91AC=:+DE+;F
D.=GAC=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 stgf
while (tipoOper != 'f') {

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

&345678.%&+ }__.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

!
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@B50245
6CD8FE0GCHICE25CJ603BE235@ 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Ìacbedf`&gZ+Y
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
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
Ejemplo 1
Sistema de gestión de pagos
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
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
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!!)
♦ 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
♦ 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
♦ 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
♦ 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.
♦ 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
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

Tema1 MTP2

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Tema1 MTP2

Загружено:

Авторское право:

Доступные форматы

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

Programación Estructurada. Diseño Modular

♦ Aplicaciones del Software

Evolución del software

Mitos del Software

Ingeniería del software

Elementos de la ingeniería del software

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

* Herramientas CASE (Computer-Aided Software Engineering)

Fases de la Ingeniería del Software

Modelos de proceso del software

♦ Modelo lineal secuencial (Paradigma del ciclo de vida

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

2.- Análisis de los requisitos del software

Propuestas de solución y estudio de viabilidad

2. Especificación de los requerimientos del software

Código y Estilo de programación

normas que se deben seguir:

1. Buen diseño modular

- Tarea del módulo

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

Normas generales a seguir para nombrar identificadores:

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

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

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

o total, resultado, acum, para acumuladores de resultados

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

• Utilizar identificadores en plural para los arrays.

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

• Entre las palabras que componen el identificador suele haber alguna

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

• Utilizar el mismo tiempo verbal en todos los procedimientos y

Entrada y Salida de datos

EJEMPLO DOCUMENTACIÓN DEL CÓDIGO

♦ Fundamentos de la Programación Estructurada

♦ Ventajas de la Programación estructurada

“Todo programa propio puede escribirse utilizando únicamente

Un programa propio es aquel que cumple tres condiciones:

Ideas fundamentales C os to por

char tipoOper; QRST0UVWXIV&UXY(Z[T)\]^ T_]`YX&aV$bWXUVaT)ScVdVeUZ`&VRQ

Leer (&tipoOper, &cantidad); fg.h%i.j+klmn8o4m+p0q7imnroimnjp s tgf

while (tipoOper != 'f') {

uv ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~

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

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

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

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

• Los indicadores de control sirven para

sincronizar los procesos e indicar la ocurrencia de un suceso determinado

se realiza una vez. La secuencia de ejecución

Representación física donde van a estar

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

Evaluación del diseño

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

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

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

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

Un módulo coherente ejecuta una tarea sencilla y requiere

poca interacción con otros procedimientos que se ejecuten

Los módulos deben tener cohesión alta

Por variables globales

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

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

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

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

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