Unidad 1: Programación – Conceptos Básicos

Programación: Es el proceso de planificar todo el conjunto de actividades que hay que llevar a cabo desde que el usuario nos
plantea un problema, hasta que tenemos una solución instalada en una computadora.

Etapas del proceso de programación

A) Diseño de la solución (creación del programa, trabajo de escritorio) – sus fases son:
1) Análisis del problema  datos (input); salida (output); proceso sobre los datos; personal informático; que
equipamiento informático; dividir problemas complejos en subproblemas.

2) Búsqueda de una posible solución  Algoritmación

Programa modular Diagrama de flujo
Como lo hago Programa estructurada Algoritmo TD
Programa orientada a objetos Pseudocodigo

3) Codificación  Programa escrito en papel

B) Implementación de la solución (actividades que se llevan a cabo para instalar el programa en la memoria interna del
computador) – sus fases son:
1) Edición  Escritura del programa con ayuda del editor de textos  Prog. fuente (es decir un programa escrito en
lenguaje de alto nivel).
2) Traducción  Se transcribe el programa fuente al lenguaje máquina  Prog. objeto.
3) Montaje  Consisten incorporar al programa principal todos los subprogramas externos que se compilaron por
separado (se hace con la ayuda del sistema operativo  LINKER).
4) Ejecución  Se comprueba la corrección del programa con la ayuda de datos de prueba. El compilador por cada
instrucción debe hacer un análisis lexicografico, un análisis sintáctico (respetar gramática) y un análisis semántico (significado 
ejecutar la acción).

Programa: Es un conjunto de instrucciones ordenadas que le indican al computador las tareas específicas que debe realizar. En la
estructura de todo programa se visualizan tres componentes:
• Entrada de datos (validación de datos): Ingreso datos desde el interior hacia la memoria interna; el
programador tiene que hacer un listado de entrada (los que validan la entrada) todos los datos que requiere,
el formato (tipo de datos) y fuente de procedencia (de donde los sacamos).
• Proceso sobre datos: Es el conjunto de instrucciones que opera sobre los datos de entrada y los transforma
de acuerdo a las necesidades (resultados esperados); almacena en la memoria interna del computador.
• Salida de resultados: Es el conjunto de instrucciones que permiten extraer los datos desde la memoria
interna hacia el exterior mediante los dispositivos periféricos de salida. El programador tiene que realizar un
listado con todas las salidas esperadas, el formato y el medio.
Tipos de programa: (hay diferentes dependiendo del tipo de instrucciones que maneja ese programa)
1) Lineales: Son aquellos cuyas instrucciones se ejecutan en el mismo orden en que han sido codificado, no contienen
instrucciones de bifurcaciones ni saltos, por eso se llaman secuenciales.

2) Cíclicos: Son aquellos cuyas instrucciones se ejecutan iterativamente un determinado número de veces hasta que se cumple
una determinada condición; están en bloques de procesos de datos  para saltar de bucle necesita una bifurcación.
Estructura de dato del prog. cíclico. Instrucciones previas Lazo o bucle
Instrucciones finales Salida de resultado

3) Alternativos: Son aquellos cuyo conjunto de instrucciones permiten seleccionar entre los procesos a realizar o ejecutar en
función de la evaluación de una determinada condición. Instrucciones de entrada
Instrucciones previas
¿Condición?
Instrucciones finales
Salida de resultados.

Elementos básicos de un programa (hacemos referencia a aquellos elementos que no pueden faltar en el programa, si o si
deben estar):
1) Palabras reservadas: Son palabras que tienen un significado para cada uno de los lenguajes y no pueden ser utilizados como
nombres de variable. Incluye el nombre de las instrucciones, comandos, funciones, operadores.

2) Constantes: Es un campo o posición de memoria cuyo valor no se modifica durante la ejecución de un programa. Para
designar una constante se debe designar su valor concreto y es de alguno de los tipos de datos.

3) Variables: Es un campo o posición de memoria cuyo valor se modifica durante la ejecución del programa. Para definirla hay
que darle un nombre simbólico y asignarle un tipo.

4) Expresiones: Es una combinación de constantes, variables, nombres de funciones, operadores, paréntesis de apertura y
cierre.
a) Exp. Simples: Formada por un elemento simple perseguido del signo +, -, NOT; Ej. +5, -2, NOT 3.
b) Exp. Compuestas: Formada por dos o mas elementos simples combinados con uno o mas operadores. Dependiendo del
resultado de la evaluación de la expresión se clasifican en;
*- Aritméticas: Combina elementos aritméticos con operadores aritméticos y el resultado es aritmético. Ej: 3 * 6
= 18.
*- Lógicas: Combinan un elemento lógico, con operadores lógicos, con otro elemento lógico y el resultado es
lógico. Ej: V and V = V,
Elemento aritmético Operador relativo Elemento aritmético Resultado lógico
5 = 3 F

5) Operadores: Son símbolos que conectan los operandos dentro de una expresión y que indican el tipo de operación que hay
que realizar.
 Elementos Auxiliares de un programa:

1) Contadores: es un campo o posición de memoria cuyo valor se va incrementando por una cantidad fija positiva o negativa y
que globalmente esta asociado a un lazo común. Por lo general se inicializa en 0 y se incremente en 1 cada vez que ocurre el
elemento que queremos contar.
2) Acumuladores: Es un campo o posición de memoria que se incrementa en una cantidad variable. Ej: Prod=1;
Prod=Prod*Edad.
3) Interruptores (banderas): Es un campo o posición de memoria que solamente puede tomar un valor lógico o booleano.

Instrucciones: Son acciones, conjuntos de símbolos que respetan reglas sintácticas y semánticas; esos símbolos son palabras
reservadas, constantes, variables, expresiones, funciones.
Clasificación: Las instrucciones pueden ser:

1) E/S: Las de entrada transfieren datos desde el exterior hacia la memoria interna del computador a través de los dispositivos
periféricos de entrada. Las de salida transfieren datos desde la memoria interna hacia el exterior a través de dispositivos
periféricos de salida.
2) Asignación/movimiento: Los de asignación son las que nos permitan dar valores a las variables, asigno el valor que esta a la
derecha del generador de asignación al valor que esta a la izquierda. Los de movimiento permiten transferir el valor de un campo
de memoria hacia otro campo, manteniendo intacto el valor del emisor y modificando el valor del campo receptor
3) Matemáticas: Son todas las instrucciones que nos permiten realizar operaciones aritméticas, para ello utilizamos los
operadores (+, -, *, /) y además resolver funciones (sen, cos, tg…).
4) Lógicas: Permiten realizar las operaciones lógicas usando los operadores booleanos (AND, OR, EXOR) aplicando tablas de
verdad.
5) Relación: Permiten comparar dos o + elementos aritméticos, para ello se utilizan los operadores de relación (<, =, <>, <=,
>=).
6) Transferencia de control (bifurcación): Permiten romper con la secuencia normal de ejecución del programa al permitirnos
saltar a otro punto del mismo programa (pueden ser saltos hacia delante o atrás) y además el salto puede ser condicional (son las
que se ejecutan siempre que se cumpla una determinada condición) o incondicional (se realiza siempre y cada vez que se ejecuta
la instrucción; transferencia de control con el GOTO).
7) Especiales
a) Ordenación: Nos permite clasificar un conjunto de caracteres ya sea en orden creciente o decreciente (SORT).
b) Conversión: Facilitan el paso de un código de numeración a otro (bin a hexa; bin a octal), también de un sistema de
codificación a otro.
c) Manejo de gráficos: Facilitan el manejo gráfico de la pantalla (diseño de pantallas graficas, estadísticas, postales).
d) Edición: Son todas las instrucciones que facilitan la presentación de resultados (eliminan 0 a la izquierda que no tiene
valor).
e) Declarativos: Nos permiten reservar campos o posiciones de memoria para el almacenamiento de datos o de estructura
de datos.

Datos (pueden ser):

1) Numéricos (cantidades): Están sujetos a operaciones matemáticas que a su vez pueden ser:
a) Reales: pueden tomar cualquier valor dentro de la recta numérica real, pueden ser (+) o (-) y por lo general, están
compuestos por una parte entera y una parte decimal, separados por un punto decimal.
b) Enteros: Tienen un único valor, no tienen parte fraccionaria ni decimal; pueden ser (+) o (-).

2) Alfanuméricos o string: Están sujetos a operaciones lógicas. Dentro de los alfanuméricos se consideran todas las letras del
alfabeto (MAY., min., de [A_Z], [a_z]), caracteres especiales y los símbolos: *char *cadena *booleanos (V o F – 1 o 0)

Unidad 2: Programación Estructurada

Algoritmo eficiente => Programa eficiente => Código simple y claro

Estilo de Codificación

Esto se logra aplicando:

Metodología: La metodología de programación es la técnica que más permite que la programación sea lo más eficiente posible,
tanto en la etapa de desarrollo como en la etapa de mantenimiento de los programas. Si la complejidad de los programas aumenta
es necesario recurrir a técnicas que nos ayuden en la descripción de nuestros organigramas y fundamentalmente algoritmos. Las
técnicas de desarrollo y diseño de programas que se utilizan en la programación convencional, tienen inconvenientes, sobre todo a
la hora de verificar un programa.
Una forma de simplificar los programas haciendo mas sencilla su lectura y mantenimiento, es usando la técnica de diseño
descendente de programa (TOP DOWN). La técnica más usada que sigue las directivas TOP DOWN es la programación
estructurada.

Programación Convencional
La realización de un programa sin seguir un método de programación riguroso, por mas que funcione a lo larga no va a ser mas
que un conjunto mas o menos grande de instrucciones. La definición de las diferentes etapas adolecen en general de indefinición y
falta de continuidad (desarrollo y mantenimiento). La consecuencia inmediata de todo esto se recoge en la siguiente relación de
problemas y defectos que suelen tener los programas escritos sin un determinado método.
Problemas y defectos
• Estructuras rígidas
• Programadores no leen programas escritos por otros
• Programadores dueños del programa
• No hay comunicación entre programadores del grupo
• Objetivos diferentes
• No son fáciles de modificar
• Documentación
 Para que no ocurra esto, hay que establecer una serie de “Normas o Guías de Programación” (que permitan el paso de un
programa artesanal a uno que permita conseguir una Estandarización).
Estandarización (homogeneizar el código) y en consecuencia:
• Disminuir los costos informáticos
• Mayor independencia del programador
• Mayor seguridad en el funcionamiento de los programas

Características de un programa (un programa debe ser):

1) Correcto: Cuando satisface los requerimientos planteados por el usuario. Si hace lo que se quiere que haga.
2) Legible: Cuando el programa tiene una estructura clara, es fácil de interpretar, de leer y de comprender.
3) Depurable: Tiene que ser fácil la localización del error y su corrección.

4) Modificable: debe tener una estructura flexible, eso es para que se adapte fácilmente a las modificaciones y a las
actualizaciones que se deben hacer con el correr del tiempo.
5) Portable: Debe aceptar corridas en distintos sistemas operativos o en diferentes lenguajes.
6) Modular: Programa complejo, que lo podamos dividir en subprogramas, módulos o en bloques, donde cada uno debe ser
independiente.
7) Estructurado: debe respetar las reglas de la programación estructurada, facilidad en el mantenimiento (actualización,
modificación).
8) Eficiente: Que aproveche al máximo los recursos de los sistemas, esto implicaría minimizar el tiempo de ejecución y el espacio
de memoria que se requiera para su almacenamiento.

Programación modular (PM)

La PM consiste en dividir un programa en módulos. Es un método de diseño que tiende a dividir el problema, de forma lógica,
en partes perfectamente diferenciadas que pueden ser analizadas, programadas y puestas a punto independientemente. Esa
división
En módulos o programas independientes exige otro módulo que controle y relacione a todos los demás, se lo denomina módulo
base o principal del problema. La PM es un intento para diseñar programas de forma tal que cualquier función lógica pueda ser
intercontrolada sin afectar a otras partes del programa.
Para resolver los problemas se debe realizar una descomposición del mismo, cuyo objetivo es dividir cada problema en
subproblemas más pequeños, donde a la vez cada uno de estos también puedan dividirse en otros más pequeños y así
sucesivamente. Estos subproblemas resultan entonces más simples de resolver. Al realizar esta descomposición se debe tener
en cuenta que cada subproblema esta en un mismo nivel de detalle y se pueden resolver independientemente; y que las
soluciones de cada uno pueden combinarse para resolver el problema original.

Programación Estructurada (PE)

Es el enfoque disciplinado que permite escribir programas estructurados, utilizando tres estructuras de control bien definidas
que son, la secuencial, la condicional y la iterativa.
Los programas estructurados son fáciles de probar, depurar y modificar. La PE es una programación orientada a acciones donde
la unidad básica es la función.
Para aumentar la eficiencia de la programación y el mantenimiento se necesita dotar a los programas de una estructura. Las
razón de esto no solo es el aumento de fiabilidad y eficiencia, sino también asegurar que los programas sean adaptables,
manejables, fácilmente comprensibles y transportables; a esto se le puede añadir la claridad y simplicidad.

Programación Orientada a Objetos (POO)

En el paradigma de la orientación a objetos, un sistema se concibe como un conjunto de objetos que se comunican entre sí
mediante mensajes. Un objeto es una entidad percibida en el sistema que se esta desarrollando, mientras que en el nivel de
implementación, un objeto corresponde con un encapsulamiento de un conjunto de operaciones y datos. Algunas características de
la POO son:
- Encapsula datos (atributos) y métodos (comportamiento) en objetos.
- Objetos: componentes de software reutilizables que modelan cosas del mundo real (estudiantes, profesores, materias,
etc.).
- Los datos y métodos de un objeto están internamente relacionados entre sí.
Programación Orientada a Eventos
Los programas visuales orientados al evento al evento y con manejo de componentes dan al usuario que no cuenta con mucha
experiencia en desarrollo, la posibilidad de construir sus propias aplicaciones utilizando interfaces gráficas sobre la base de
ocurrencia de eventos. Para soportar este tipo de desarrollo interactúan dos tipos de herramientas con las cuales es posible
desarrollar cualquier tipo de aplicaciones basadas en el entorno; dichas herramientas son las que permiten realizar diseños
gráficos y un lenguaje de alto nivel que permite calificar los eventos.
• Un programa secuencial: Es un programa que arranca, lee los datos que necesita, realiza los cálculos e imprime o guarda
en el disco los resultados. Mientras esta ejecutándose no necesita ninguna intervención del usuario.
• Los programas interactivos: Exigen la intervención del usuario en tiempo de ejecución, ya sea para suministrar datos o
bien para indicar al programa lo que debe hacer por medio de menús; además estos programas limitan y orientan la
acción del usuario.
• Los programas orientados a eventos: Como Word, Excel y otros, cuando arrancan, lo único que hacen es quedarse a la
espera de las acciones del usuario y respondiendo a ellas. Esas acciones del usuario sobre el programa se denominan
eventos. Cada vez que se produce un evento sobre un determinado tipo de control, arranca una determinada función o
procedimiento que realiza la acción programada por el usuario para ese evento en concreto. Esos procedimientos se
llaman son un nombre que se forma a partir del nombre del objeto y del evento.
Además de los eventos, la mayor parte de los objetos, como los formularios y controles, son suministrados con
propiedades y métodos. Una propiedad es una asignación que describe algo sobre un objeto como formulario.
Dependiendo de la propiedad, se la puede asignar en tiempo de diseño usando la ventana “propiedades” y/o un tiempo de
ejecución al programa.

Programación Estructurada
Es la técnica de construcción de programas que utiliza al máximo los recursos del lenguaje, limita el conjunto de estructuras
aplicables a leer y presenta una serie de reglas que coordinan adecuadamente el desarrollo de las diferentes fases de la
programación. Utiliza en su diseño estructuras de control, recursos abstractos y diseño descendente “arriba-abajo” (TOP DOWN).
 Programa propio: Es otro concepto que utiliza la PE en su diseño, y se basa en que toda estructura debe tener un solo punto de
entrada y un solo punto de salida. Es propio en sí, si cumple con 3 características fundamentales:
• Unicidad de puntos de E/S.
• Tiene que pasar al menos una vez por sus caminos lógicos.
• Todas las sentencias sean ejecutables y que no existan bucles infinitos.

Teorema de la Estructura o Teorema de Jacofini y Bohm

Todo diagrama o programa propio, cualquiera que sea el trabajo que tenga que realizar, se puede hacer utilizando 3 únicas
estructuras de control que son la secuencia, alternativa e iterativa. Con estas 3 se pueden generar otros del mismo tipo.

Estructuras Básicas de Control

Estructura secuencial: es aquella que ejecuta las acciones sucesivamente, una a continuación de la otra sin posibilidad de omitir
ninguna y naturalmente sin bifurcaciones. Todas estas estructuras tendrán una entrada y una salida.

Estructura Alternativa: Es aquella en la que únicamente se realiza una alternativa, es decir una determinada secuencia de
instrucciones, dependiendo del valor de una determinada condición. Pueden se de 3 tipos:
• Simple: Son aquellas en que la existencia o cumplimiento de la condición implica la ruptura de la secuencia y la ejecución
de una determinada acción.
• Doble: es aquella que permite la elección entre dos acciones o tratamientos en función de que se cumpla o no
determinada condición.
• Múltiple: Se adoptan cuando la condición puede tomar valores enteros distintos. Según sea el valor que tome la variable
de control en la condición se realizaran una de las acciones.

Estructura iterativa: Son aquellos en las que las acciones se ejecutan un número determinado de veces y dependen de un valor
predefinido o del cumplimiento de una determinada condición. Permiten representar aquellas acciones que pueden descomponerse
en otras subacciones primitivas. La iteración es el hecho de repetir la ejecución de una secuencia de acciones o de una acción. Un
bucle o lazo es el conjunto de acciones iterativas. Las 3 estructuras más usuales dependiendo de que la condición se encuentre al
principio o al final de la iteración son:
• Estructura Mientras: Determina la repetición de un grupo de instrucciones mientras la condición se cumpla inicialmente.
• Estructura Repetir (DO WHILE): Existe otra en la que el número de iteraciones o repeticiones del grupo de instrucciones
se ejecuta hasta que la condición deja de cumplirse. Y si esa condición se cumple al final (DO UNTIL).
• Estructura Para: Es aquella que se repite un número fijo de veces, el incremento puede ser positivo o negativo.

Recursos abstractos
La estructuración debe cumplir el uso de recursos abstractos. El proceso de realización de diferentes pasos hasta encontrar la
solución de un problema es un proceso abstracto. Consiste en no tener en cuenta la maquina que lo va a resolver así como el
lenguaje de programación que se va a utilizar. Esto lleva consigo que incluyen, se hace abstracción de los valores específicos.
Igualmente el concepto de variable implica una abstracción cuando se da un nombre a una operación determinada, y se utiliza
considerando lo que hace pero sin preocuparnos por como lo hace.
Una vez encontrada la solución se la analiza con la computadora y el lenguaje de programación que se va a utilizar, a fin de
comprobar si las diferentes acciones son susceptibles de ser ejecutadas por la maquina tal y como han sido concebidas; si eso no
es posible, será preciso descomponer las acciones en otras subacciones mas elementales, continuándose el precio hasta que cada
subacción pueda ser codificada en el lenguaje elegido y por consiguiente ejecutado en la computadora del usuario.

Unicidad de puntos de entrada. Teorema fundamental de composición de estructuras.

Cada una de las estructuras de control tiene un solo punto de entrada y un solo punto de salida. Se las utiliza para escribir
programas completos, mediante la combinación de diversas maneras. Para esto existen reglas fundamentales de composición que
dice: “es posible combinar las estructuras de control de secuenciación, selección e iteración condicional, utilizando para tal fin la
secuenciación, selección e iteración condicional”. Esta regla es recursiva ya que define nuevas estructuras de control a partir de
los 3 tipos básicos. Un razonamiento recursivo tiene dos partes, que son la base y la regla recursiva de construcción. La base no
es recursiva y es el punto tanto de partida como de terminación de la definición. Se puede reconsiderar nuestra regla de formación
de estructuras validas de control de la siguiente manera:
Base: La secuenciación, se lección e iteración condicional son estructural validas de control que pueden ser consideradas
como enunciados.
Regla: Las estructuras de control que pueden formar combinando de manera valida la secuenciación, selección e iteración
condicional también serán validas.
Esto da origen al concepto de PE. Un programa estará bien constituido si esta formado por estructuras de control validas de
acuerdo con la regla precedente.

Diseño de Programas Estructurados

La realización del diseño estructurado se basa en:
• Ir de lo general a lo particular, descendiendo en la estructura del programa y en su nivel de detalle.
• De la definición inicial del problema se pasa a un esquema de algoritmo descrito en pseudocódigo.
• Independencia inicial del lenguaje.
• Diseño por niveles, dejando los detalles para niveles posteriores. Verificar en cada nivel el esquema correcto.
• Finalizar con un trabajo de recomposición del algoritmo completo.

Técnica de Diseño Descendente (TOP DOWN)

Consiste en establecer una serie de niveles de menor a mayor complejidad que den solución al problema. En esencia consiste
en efectuar una relación entre las etapas de la estructuración de forma que una etapa jerárquica y su inmediatamente inferior se
relacionan mediante Entrada y Salida de información. El diseño se basa en la realización de diferentes niveles. El 1º nivel resuelve
totalmente el problema y el 2º y sucesivos niveles son refinamientos sucesivos del 1º y se sigue siempre la metodología de
recursos abstractos. Si el diseño y planeamiento es correcto, nunca será preciso volver atrás ya que los niveles anteriores al que
se esté situando en un momento dado ya habrán resuelto el problema en su totalidad.

Unidad 3: Programación modular

La PM es una técnica de diseño muy potente que nos permite dividir un problema en partes perfectamente diferenciadas de tal
manera que cada una de esas partes pueda ser analizada, codificada y puesta a punto de manera independiente.
Ventajas de la PM (un programa modular es:)
• Mas fácil de escribir (subprograma sencillo)
• Fácil de depurar
• Fácil de modificar (mas fácil de mantener)
• Fácil de controlar
• Reusabilidad del código (evitamos la estructura repetitiva de modulas)
• Facilita la comprensión de la lógica subyacente en el módulo tanto por programadores como por usuarios

Inconvenientes de la PM (según Presuman en la modularidad)

• No existen algoritmos formales de modularidad.
• Ocupa mayor espacio de memoria y mayor tiempo de ejecución

Objetivos de la PM
• Simplificación del problema, en otras palabras disminuir la complejidad
• Disminuir el costo total del proyecto
• Aumenta el control del proyecto
• Aumenta la confiabilidad del software
• Facilita la ampliación de los programas

Razones para utilizar la PM (Para dividir tareas cuando):

• Se nos presenta un problema muy complejo
• Se repiten varias operaciones
• El tiempo disponible es poco

Criterios para un buen diseño

El diseñador o programador debe tener en cuenta los siguientes principios de división que son:
1) Dividir para limitar el tamaño de un módulo a menos de 50 líneas de código fuente en lenguaje de alto nivel.
2) Dividir para hacer los programas mas fáciles de leer, entender y mantener.
3) Dividir para ahorrar memoria y simplificar el mantenimiento, fomentando la utilización común de las funciones entre
módulos.
4) No dividir cuando un módulo esta constituido por una sola función, esto es un buen indicio de que la subdivisión ha
llegado a un punto aceptable.
5) No dividir cualquier conjunto de sentencias de un módulo. Solo aquellos que constituyen a una función sencilla y bien
definida; deben ser extractadas de un módulo.
6) No dividir cuando el módulo padre tenga que pasar una gran cantidad de los datos al módulo extractado.
7) Es mejor exederce en la división (obteniendo muchos módulos pero más pequeños y sencillos) que quedarse cortos
(obteniendo menos módulos pero más grandes y complejos).
Módulos
Esta formado por una o varias instrucciones físicamente contiguas y lógicamente encadenadas que se pueden referenciar
mediante un valor y que pueden ser llamadas desde diferentes puntos de un programa.
Tienen la característica de que no son directamente ejecutables (alguien las tiene que llamar para que empiecen a trabajar) el
que lo llama (el que se es ejecutable) es el programa principal o módulo maestro.
El programa principal: Está compuesto por llamadas a los subprogramas. Su función es la de coordinar la ejecución de todos
los módulos.
Los subprogramas: Tienen una función determinada, es decir cumple una tarea específica y básicamente la estructura es
similar a la del programa principal (difiere en el encabezado/terminación). Estos pueden ser:
Internos: Figuran junto con el programa principal y dependiendo de los lenguajes de programación se llaman:
- Basic  subrutina y se lo convoca con el GOSUB.
- Cobol  Párrafos y se lo convoca con el PERFORM.
- Pascal  Procedimientos o funciones y se lo convoca con el NOMBRE (que elije el programador).
- C++ 
Externos: Figuran separados del programa principal (son independientes del mismo). Se compilan por separado pero luego hay
que integrarlos, se los integra en la etapa de “linkeado” (cuando ya son módulos objetos).

Procedimiento: Es un subprograma que ejecuta una tarea especifica y que no devuelve ningún valor al módulo que lo llamó.
Funciones: Recibe un determinado valor (lo que lo diferencia del procedimiento), los procesa y devuelve un valor resultante al
módulo que lo llamó.
Esquema de funcionamiento
1) La ejecución comienza con la 1º instrucción del programa principal.
2) Continua dentro del programa principal hasta que encuentre una sentencia CALL o equivalente.
3) Se transfiere el control del programa al procedimiento que es llamado.
4) Continua allí hasta que aparezca la sentencia RETURN, que devuelve el control al programa principal y continua su
ejecución.
Variables
Locales: Es aquella que se define dentro de un módulo y solo tiene un significado para él.
Globales: Es o puede ser accedida por todos los módulos y por lo general se define dentro del programa principal.
 Ámbito variable: El ámbito de la variable es la parte del programa donde se crea la variable, es decir donde se la define. Una
variable definida en el ámbito del procedimiento solo puede ser accedida por ese procedimiento y por sus interiores.

* C no puede llamar a B, pero si devolverle el control.

Parámetros o Variables de enlace

Es un método que nos permite pasar información o datos desde el programa a los subprogramas o viceversa. El proceso de
emisión de datos y recepción de resultados por medio de variables de enlace se denomina pasos de parámetros: - actuales, reales,
argumentos. – formales, fingidos, ficticios.
Formales: Son solamente los nombres locales con que va reconocer los valores que están siendo enviados. Son siempre fijos
para cada ejecución del programa.
Actuales: Contiene los valores que el módulo le pasa al que lo está llamando. Cambia por cada corrida. Siempre debe haber una
correspondencia (para formales y actuales) en a cuanto a número, posición, tipo.

Programación modular (PM): Se basa en una metodología de diseño o TOP-DOWN, que consiste en la descomposición del
problema inicial en subproblemas, mediante el refinamiento progresivo del repertorio de instrucciones que va a formar parte del
programa. Esto da lugar a un diagrama de estructura del programa que muestra la organización de los componentes del programa
en una jerarquía de control que se representa con una estructura de árbol.

Pasos de la metodología
1) Comenzamos por identificar el módulo maestro que describe la función global del programa.
2) Lo descomponemos en sus principales funciones o componentes,
3) Cuando ya estamos parados en el 2º nivel del diagrama de estructura, repetimos el proceso considerando cada uno de
estos módulos como si fuera el módulo principal.
4) Nos detenemos cuando ya no existe una función que pueda partirse en otras, esto es cuando cada función es una tarea
cohesiva que corresponde a un módulo cohesivo (ejecuta una función sencilla y en lo posible una única función).

Heurística de diseño (Recomendaciones).

1) Tamaño de módulos: Optimizar la cantidad de líneas de código fuente (LCF). Un buen diseño no debe tener módulos
demasiado grandes ni demasiado pequeños. 10<Tamaño de módulo<100 LCF
Número pequeño de módulos grandes
Programas complejos Número grande de módulos pequeños

Solución para el tamaño de módulos

a) Módulos grandes: Su solución es revisar el análisis y tratar de subdividirlos en funciones más sencillas.
b) Módulos pequeños: Su solución es combinarlos para formar módulos más grandes.

2) Ramificación de Control (RC): es equivalente al abanico de salida (fan-out)

La RC de un módulo dado es el número de subordinados de dicho módulo y de todos los que dependen de estos. Una RC
aceptable debe ser simple: 1<RC<=7 
RC=1, significa que el módulo es muy grande y en consecuencia habrá que subdividirlo
RC>7, significa que hay módulos muy pequeños que deberán combinarse.

La Inspección visual al diagrama de estructura, nos va a indicar si la RC es ancha o si es reducida. En ambos casos hay que
modificar el diseño porque son errores.
3) Abanico de entrada (fan-in)
El AE de un módulo dado se define como el número de superiores de ese módulo.

AE(E)=4

En una jerarquía estricta esto no está permitido, cada módulo debe tener un único padre. En la práctica se es recomendable
porque indica reusabilidad de código.

Módulo E (lo diseñamos, lo compilamos por separado)  lo incorporamos a los módulos.

4) Principio de ocultación de información

Este principio nos dice que los módulos deben diseñarse de tal manera que se oculten unos de otros, esto implica que la
información (datos + procedimientos) contenida en el módulo sea inaccesible para cualquier otro. Esto es que se respete el
principio de caja negra para cada módulo, lo que es posible lograr si somos capaces de producir módulos independientes que se
comuniquen con otros solo por la información necesaria para realizar su función.

5) Principio de Independencia funcional

Este principio nos indica que cada módulo debe realizar una tarea sencilla y no tener comunicación con otros, salvo que lo
necesite para llevar a cabo su tarea. O sea que los módulos deben tener aversión o interacción con otros módulos (en exceso). En
definitiva los módulos deben responder a una función sencilla además tener una interfaz sencilla.
- La independencia funcional es la base de un buen diseño, y un buen diseño es la base de la calidad del software según
Yourdon-Constantine la YF se mide con cohesión y acoplamiento.
Yourdon nos dice que la cohesión es la medida de la fuerza funcional relativa de un módulo, es decir la cohesión nos mide el
número de funciones que realiza un módulo. Y el acoplamiento es la medida de la interrelación entre módulos o de la
interdependencia relativa de un módulo. También nos dice que un buen diseño debe tener máxima cohesión (función sencilla) y
mínimo acoplamiento (interfaz sencilla).
 Cohesión: Nos indica el grado de relación de sentencia de un módulo, por eso se dice que es una medida intramodular. Un
módulo cohesivo es aquel que ejecuta una función sencilla y en lo posible una única función. La función cohesiva es aquella que se
puede describir en pocas palabras.
El principio de cohesión es un principio asociativo (característica)

Tipos y niveles de cohesión

• C. Funcional: Un módulo se dice funcionalmente cohesivo si las sentencias del módulo ejecutan una función sencilla y bien
definida, y cada sentencia del módulo contribuye a lograr esa función. Ej: Un módulo que calcule la tg de un ángulo es
mas sencillo que el que calcula la tg + el sen.
• C. Secuencial: Cuando las sentencias del módulo se deben ejecutar respetando una secuencia especificada, porque la
salida de una sentencia de la secuencia se transforma en la entrada de la siguiente. Es decir que estos módulos se
diseñan en base a pasos que se ejecutan en secuencia.
• C. Comunicativa: (o relativa a los datos), cuando el módulo contiene sentencias que se relacionan únicamente porque
manejan los mismos elementos de datos (esta compartiendo datos).
• C. Procedimental: Cuando las sentencias del módulo están asociadas a estructuras de control del programa (alternativas
o iterativas), por lo general, lo usan quienes tratan de modularizar a partir del diagrama de flujo.
• C. Temporal: (factor tiempo), cuando el módulo contiene sentencias que necesariamente debe ejecutarse al mismo
tiempo durante la ejecución del sistema.
• C. Lógica: (relativa a una clase), cuando el módulo contiene sentencias que pertenecen a una misma clase de acciones o
funciones lógicas.
• C. Coincidente: (sin cohesión), cuando el módulo contiene un conjunto aleatorio de sentencias que no tienen ninguna
relación entre ellos y que el programador a veces no sabe llamarlos. Generalmente es como la consecuencia de la
modularización de un programa que ya esta escrito, una consecuencia de las mal interrupción de la programación
estructurada.

Diagrama de Cohesión

Criterios para establecer el grado de cohesión

Una técnica muy útil para saber si un módulo esta acotado funcionalmente es escribir una frase que describa la función del
módulo y luego examinar dicha frase. Puede hacerse de la siguiente manera:
1) Si la frase resulta ser una sentencia compuesta, contiene una coma o mas de un verbo, probablemente el módulo realiza
+ de una función por lo tanto, probablemente tiene vinculación secuencial a de comunicación.
2) Si la frase contiene palabras relativas al tiempo (1º, a continuación, entonces, después, etc), entonces probablemente
tiene una vinculación secuencial o temporal.
3) Si el predicado de la frase no contiene un objeto especifico a continuación del verbo, probablemente el módulo este
acotado lógicamente. Ej: editar todos los datos tiene vinculación lógica, editar sentencia fuente tiene vinculación
funcional.
4) Palabras tales como inicializar, limpiar, etc; implica vinculación temporal.

Acoplamiento: Es la relación entre módulos (interacción: transferencia de datos entre módulos).

El acoplamiento alto entre dos módulos se da cuando existen muchas dependencias, es decir cuanto mas datos comparten; y el
acoplamiento bajo se da cuando existen algunas dependencias y las interconexiones son débiles. Cuando los módulos son
independientes y no existe ninguna dependencia se dice que no están acoplados.
Un buen diseño debe tener un mínimo acoplamiento (acoplamiento bajo).
Las dependencias se establecen por:
• Referencias realizadas o hechas de un módulo a otro.
• Cantidad de datos pasados de un módulo a otro.
• Complejidad de la interfaz entre módulos.

El acoplamiento bajo, solamente lo obtenemos si en el diseño somos capaces de realizar acciones como:
• Controlar la cantidad de datos pasados
• Controlar no pasar datos innecesarios
• Asegurar que lo que pasemos sean datos y no información de control (esto produce alto acoplamiento).

El acoplamiento bajo es deseable y lo que queremos para:

• Facilitar la detección de errores
• Facilitar su modificación Todo esto no evita el “efecto onda”
• Facilitar su mantenimiento (propagación de errores)

Niveles de acoplamiento
• A. de Datos: Se produce cuando dos o más módulos se refieren al mismo elemento no global de datos. Elemento simple
definido como no global, ese elemento simple se transfiere como un parámetro. Ej: Se realiza la búsqueda del menor
elemento de un vector o lo transfiere al módulo N para que calcule su !
 • A. de Marcas/estampado: Se produce cuando dos módulos se refieren a una estructura no global de datos (arreglo,
matriz, registro). También están definidas como variables locales, y se los pasa como parámetros o argumentos. Se debe
tener en cuenta no pasar datos innecesarios. Ej: A le transfiere a B un vector de 10 elementos para que B calcule el
menor.
• A. de Control: Se produce cuando un módulo le pasa a otro una bandera o un indicador con el objeto de controlarle la
lógica interna. El acoplamiento es alto porque estamos violando el principio de caja negra.
• A. de Extremo: Se produce cuando dos módulos se refieren al mismo elemento global de datos.
• A. Común: Se produce cuando dos o más módulos se refieren a la misma estructura de datos definida como global. Tiene
alto acoplamiento.
• A. de Contenido: Se produce cuando un módulo bifurca a la mitad de otro módulo, o modifica algo que esta dentro de
otro módulo. No estructurado (GO TO). Viola todos los principios. Este acoplamiento debe evitarse.
Hay dos tipos distintos de acoplamiento:
a) Inclusión lexicografica: Cuando un módulo esta incluido dentro de otro.
b) Solapamiento parcial: Cuando un módulo esta en interrelación con otro módulo. Es el peor de todos.

Heurística de Diseño para una modularidad efectiva.

Una vez desarrollada la estructura del programa se puede conseguir una modularidad efectiva aplicando los conceptos de
diseño. La arquitectura del programa se manipula de acuerdo a un conjunto de Heurísticas (directrices o consejos) que son:

1) Evaluar la “1º iteración” de la estructura del programa para reducir el acoplamiento y mejorar la cohesión
Una vez que se a desarrollado la estructura del programa, se puede explosionar o implosionar los módulos con vistas a mejorar
la independencia del módulo. Un módulo explosionado se convierte en dos o más módulos en la estructura final del programa. Un
módulo implosionado (de agregación) es el resultado de combinar el procesamiento implicado en dos o más módulos.

2) Intentar minimizar las estructuras con mucho grado de salida; intentar concretar a medida que aumenta la
profundidad
Las estructuras planas (con demasiada anchura) no hacen un empleo eficiente de la partición. Todos los módulos están al
mismo nivel debajo de un solo módulo de control. En general una estructura mejor distribuida debe tomar una forma oval,
indicando varias capas de control y módulos de alta utilidad (reusables) en las capas inferiores.

3) Mantener el alcance del efecto de un módulo dentro del alcance de control de ese módulo
Se define el ámbito del efecto de un módulo E como todos los demás módulos afectados por una decisión tomada en el módulo
E. El alcance del control del módulo E son todos los módulos subordinados al módulo E.

4) Evaluar las interfaces de los módulos para reducir la complejidad, la redundancia y mejorar la consistencia
La complejidad de la interfaz de un módulo es una causa principal de los errores en el software. Las interfaces deberían
diseñarse para pasar información de manera sencilla y deberían ser consistentes con la función del módulo. La inconsistencia de
una interfaz es una indicación de poca cohesión. El módulo en cuestión debería reevaluarse.

5) Definir módulos cuya función sea predecible, pero evitar módulos que sean demasiado restrictivos
Un módulo es predecible cuando puede tratarse como una caja negra, es decir, se producirán los mismos datos externos
independientemente de los detalles del procesamiento interno. Un módulo que restringe el procesamiento a una sola subfunción
exhibe una gran cohesión. Sin embargo un módulo que arbitrariamente restringe el tamaño de una estructura de datos local, las
opciones dentro del flujo de control a los modos de interfaz externa requerirá invariablemente mantenimiento para quitar esas
restricciones.

6) Intentar conseguir módulos de “entrada controlada” evitando “conexiones patológicas”

Esta heurística de diseño advierte contra el acoplamiento de contenido. El software es mas fácil de entender y por lo tanto mas
fácil de mantener cuando los módulos que se interaccionan están restringidos y controlados. Las “conexiones patológicas” se
refieren a bifurcaciones o referencias en el medio de un módulo.
7) Empaquetar el software basándose en las restricciones del diseño y los requisitos de portabilidad
El empaquetamiento alude a las técnicas usadas para ensamblar el software para un entorno procedimental específico. Las
restricciones de diseño dictan a veces que un programa se superponga a sí mismo en memoria. Cuando tenga que pasar esto,
puede ser necesario reorganizar la estructura de diseño para agrupar los módulos por el grado de repetición, frecuencia de acceso
e intervalos entre llamadas. Además, los módulos opcionales o de un solo uso, pueden separarse en la estructura de manera que
sean superpuestos eficazmente.

Técnicas de la PM (las fases de la resolución de un problema con PM son):

• Estudio de las especificaciones del problema. En esta etapa las TD son una herramienta de gran utilidad.
• Confección del diagrama de flujo o TD para cada módulo.
• Clasificación de cada módulo en el lenguaje adecuado.
• Pruebas parciales de cada uno de los módulos componentes.
• Prueba final de los módulos enlazados.
La PM se basa en el diseño descendente, que permite comprobar el funcionamiento de cada módulo, mediante módulos ya
comprobados. El montaje de la red se hace en modo ascendente (BOTTOM-UP) por lo que un programador puede estar escribiendo
un módulo y otro uno distinto. Los datos que forman parte de un programa modular se dividen en dos grupos de variables, las
internas o locales y las externas o globales. Los módulos se comunican entre si por medio de las variables externas.

Unidad 4: Prueba de programas

Prueba: Es el proceso de ejecutar un programa con determinados datos de entrada con el fin de encontrar errores mediante la
identificación de las diferencias entre los resultados obtenidos y esperados a partir de los datos de prueba introducidos como
entrada.
La prueba del software es un elemento de un tema más amplio que se conoce como verificación y validación (V y V).
 Verificación: es el conjunto de actividades que aseguran que el software implementa correctamente una función específica.
Validación: se refiere al conjunto de actividades que aseguran que el software construido se ajusta a los requerimientos del
cliente. Las pruebas constituyen una técnica para la verificación y validación del software. No se debe probar un programa para
mostrar que funciona, es conveniente comenzar con la suposición de que contiene errores y luego probarlo para encontrar tantos
como sea posible.

Objetivos de Prueba
• Descubrir un error
• Un buen caso de prueba es aquel que tiene una alta probabilidad de encontrar errores no descubiertos hasta entonces.
• Una prueba tiene éxito si descubre un error no detectado antes.

En definitiva el objetivo es diseñar pruebas que saquen a la luz diferentes clases de errores haciéndolo con la menor cantidad de
tiempo y esfuerzo.
Un caso de prueba exitoso es el que descubre un error; y un caso de prueba no exitoso es el que hace que el programa
produzca un resultado correcto.
La prueba no puede asegurar la ausencia de defectos, solo puede demostrar que existen defectos en el software. También
permiten la rectificación del software.

Principios de prueba (las consideraciones generales más comunes a toda prueba son):
1) Cada caso de prueba debe definir el resultado de salida esperado.
Ese resultado se debe comparar con el resultado que realmente se obtenga de la ejecución con los datos de prueba como
entrada.
Por eso un caso de prueba debe constar de dos componentes:
• Descripción de los datos de entrada del programa
• Descripción de la salida esperada para esos datos de prueba
2) El programa debe evitar probar sus propios programas.
Porque resulta muy difícil para un programador que a sido constructivo durante todo el tiempo, cambiar súbitamente y adoptar
una actitud totalmente destructiva con respecto a su mismo programa, por lo tanto es de esperar que tenga la misma falsa
interpretación cunado intente probar su programa.
3) Una empresa no debería probar sus propios programas.
4) Inspeccionar con detalle el resultado de cada prueba.
Un importante número de errores son errores expuestos previamente por casos de prueba pero que se escaparon a la detección
debido a fallas en la inspección cuidadosa de los resultados de esos casos de prueba.
5) Deben incluirse tanto entradas inválidas e inesperadas, como válidas y esperadas.
Debido a que por lo general existe una tendencia natural a centrarse en lo esperado y lo válido.
6) Examinar el programa para comprobar:
* Que hace lo que se supone debe hacer;
* Y si hace lo que no se supone que debe hacer.
El objetivo es tratar de demostrar siempre que el programa puede fallar en un aspecto u otro.
7) Evitar los casos de prueba desechables a menos que el programa sea verdaderamente desechable.
8) No planear pruebas suponiendo que no habrá errores.
9) La probabilidad de la existencia de nuevos errores en una sección del programa es proporcional al número de errores ya
encontrados en esa misma sección.
Es decir, que a mayor número de errores descubiertos, mayor probabilidad de encontrar otros nuevos.
10) Las pruebas constituyen una tarea creativa y son un desafío intelectual.
Es creativa porque aunque existan técnicas para conseguir un conjunto razonable de casos de prueba, su aplicación requiere
tanta o más creatividad que el diseño del software; y se convierte en un desafío intelectual, porque debe recurrirse al ingenio para
acercarse al objeto ideal de detectar la mayor cantidad de errores.

Ciclo completo de la prueba

1) Comienza con la generación de un plan de pruebas, apoyándose en la documentación sobre el proyecto y sobre el software a
probar.
2) A partir de ese plan de pruebas se entra en detalle diseñando las pruebas específicas, basándose en la documentación del
software a probar.
3) Una vez detalladas las pruebas se puede tomar la configuración del software para ejecutar en el computador las pruebas,
teniendo en cuenta, a efectos de notificar resultados, los posibles defectos en el software para ejecutar en el computador las
pruebas, teniendo en cuenta, a efectos de notificar resultados, los posibles defectos en el software no localizados y corregidos aún,
pero con sus mismos síntomas ya detectados.
La configuración del software incluye:
• Especificación de los requerimientos
• Especificación del diseño
• Código fuente
4) A partir de los resultados de salida que produce la ejecución de las pruebas, se pasa a la fase de evaluación (comparar los
resultados de la prueba con los esperados). De ello surgen dos actividades principales:
a) La depuración, que se alimenta de la información sobre errores especificados en informes y cuadernos históricos de
prueba.
b) El análisis de errores reflejados en las estadísticas de errores que pretende obtener una predicción o un módulo de
fiabilidad.
5) La depuración puede fijar y corregir o no los errores. Si no consigue localizarlos, pueden realizarse pruebas adicionales que
ayuden a su fijación (notificando los defectos que se persiguen)

Estrategia de prueba
1) Nivel del módulo  Prueba de unidad
2) Integrando cada módulo probado hasta formar el programa completo  Prueba de Integración (interfaces)
3) Prueba de aceptación (la realiza el usuario)

Prueba de Unidad: es el conjunto de uno o más módulos con sus datos y los procedimientos de uso y operación. Verificamos que
cada módulo funcione correctamente.
Ficticios: Conductor o Impulsor (padre):
• Llamada al módulo a probar
• Datos
• Recibe los resultados
Resguardos (hijos): Se encargan de la recepción de llamada.
Caja blanca (sentencias)
Diseño de casos Caja negra (datos, etc.)

La interfaz es la comunicación del módulo con su padre y con sus hijos. Probamos las estructuras de datos locales para
asegurarnos que los datos mantienen su integridad durante todo el proceso del módulo. Probamos las condiciones límites para
asegurarnos que el módulo trabaja correctamente dentro de los límites establecidos por las restricciones de procesamiento.
Probamos los caminos básicos para asegurarnos que cada sentencia del módulo se ejecute al menos una vez. Probamos los
caminos de manejo de errores (excepciones).

Pruebas de Interpretación: Es una progresión ordenada de pruebas en el que se combinan módulos que ya han sido probados
para formar el programa completo.

Estrategias
La prueba de Interpretación Incremental: Consiste en incorporar un módulo el conjunto de módulos ya probados. Tiene 2
métodos:

1) Método Ascendente: implica comenzar por los módulos del nivel mas bajo y subir por la estructura de red. Comienza con
los módulos atómicos.
Pressman: dice que hay que combinar los modelos formando grupos (subfunción), luego escribir un impulsor para el grupo, a
continuación se prueba ese grupo y después se reemplaza el impulsor por el módulo real.
Ventajas
• No necesitamos resguardos
• Los errores se detectan más fácil (módulos pequeños que corresponden a funciones sencillas)
• El diseño de los casos de prueba es mas sencilla
• Es ventajoso si existen grandes fallas en los niveles inferiores, ya que se detectan antes.
Desventajas
• Se retrasa la prueba de módulos importantes
• Necesidad de contar con los módulos impulsores que son difíciles de codificar
• Myers, no lo aconseja porque dice que el programa como entidad no existe hasta que no se incorpore el último módulo.

2) Método Descendente: Implica comenzar por los niveles superiores. Se incorporan los módulos progresivamente
descendiendo en la estructura del programa Este método puede hacerse:
a) Primero en profundidad (verticalmente): Consiste en integrar progresivamente los módulos que pertenecen a un
camino básico de control.
b) Primero en anchura (horizontalmente): consiste en combinar los módulos de un mismo nivel moviéndonos en forma
horizontal.
Ventajas
• Que las funciones más importantes del programa y las de control (que generalmente están en los niveles más altos) se
prueban antes.
• Que las grandes fallas en los niveles superiores, también se detectan antes.
• Nos asegura que el programa total o en su totalidad es correcto antes de desagregar o refinar.
Desventajas
• Necesidad de contar resguardos (ficticios), trabajo adicional.
• Dificultades de prueba asociados a los resguardos.

La prueba de Integración no Incremental (Big-Bang o explosiva): Los módulos que han sido probados de manera
independiente (3 de unidad) se combinan todos juntos de una sola vez para formar el programa completo. Es útil para programas
pequeños.
Una práctica recomendada es la prueba del sándwich intercalada.

El proceso de integración se realiza en una serie de 5 pasos:

1) Se usa el módulo de control principal como controlador de la prueba (impulsor) disponiendo de resguardos para todos los
módulos directamente subordinados al módulo de control principal.
2) Dependiendo del enfoque de integración elegido (1º en anchura o 1º en profundidad) se van sustituyendo los resguardos
subordinados uno por uno por los módulos reales.
3) Se llevan a cabo pruebas cada vez que se integra un nuevo módulo.
4) Tras terminar cada conjunto de pruebas, se reemplaza cada resguardo con el módulo real que sustituía.
5) Se hace la prueba de regresión, osea repetir casos de prueba para asegurarse de que no se han introducido nuevos errores.
El proceso continua desde el paso (2) hasta que se haya construido la estructura del programa entero.

Diseño de casos – Técnicas de diseño de casos

Se debe determinar si es posible probar un programa para encontrar todos sus errores. Esto no es práctico y más aún es
imposible encontrar todos los errores en un programa; por eso se dice que hay imposibilidad de una prueba completa.
Para realizar la verificación de un producto, el especialista diseña un conjunto de datos con los que realiza la prueba funcional.
Esta prueba determina si la función que especifica un producto coincide con las funciones implementadas en ese producto. Hay dos
enfoques posibles para la prueba funcional del software que implican dos técnicas de diseño distintas, que son:

a) Técnicas de Caja Blanca

b) Técnicas de Caja Negra

a) Técnicas de Caja Blanca

 También llamada cobertura lógica o pruebas basadas en la estructura, pretende examinar la estructura interna del programa.
Consiste en recorrer todas las posibles secuencias de sentencias. Es una prueba exhaustiva de secuencias, es decir, si se ejecutan
todas las posibles secuencias del flujo de control del programa probablemente se podrá decir que esta completamente probado.

Tiene dos inconvenientes:

1) El número de secuencias lógicas distintas en un programa es muy grande, con lo que la prueba exhaustiva de
secuencias no resulta práctica o es directamente imposible de practicar.
2) Es que aunque se haya probado cada secuencia posible de flujo de control, este podría estar todavía plagado de
errores.

Para esto hay 3 explicaciones:

1) Que ésta prueba no garantiza de ninguna manera que el programa cumpla con su especificación.
2) Un programa puede ser incorrecto por causas de secuencias faltantes.
3) Puede no detectar errores de sensitividad de los datos (como el caso del valor absoluto)

Esto no es una razón para desechar este tipo de técnica, ya que pueden probarse ciertos caminos o secuencias lógicas
importantes, seleccionadas según un criterio de cobertura lógica, que ofrezcan una seguridad aceptable en el descubrimiento de
errores.
Esos criterios son:
Cobertura de Sentencias: Requiere que cada sentencia en el programa se ejecuta al menos una vez. Es un criterio necesario
pero no suficiente para una prueba razonable de caja blanca.

Cobertura de Decisión/Ramificación: Establece que es necesario escribir un número suficiente de cosas para que cada decisión
tenga, por lo menos una vez, un resultado V y uno F. Es decir que cada dirección en una rama debe ser recorrida por lo menos
una vez.

Cobertura de Condición: Es necesario presentar un número suficiente de casos de prueba de tal modo que cada condición en
una decisión tenga todos los resultados posibles, al menos una vez. Su utilidad:
 Más fuerte que la cobertura de decisión, ya que explora cada condición individual, haciendo que se ejecute con sus dos
resultados posibles.
 Sin embargo, este criterio no es siempre mejor porque puede que no cumpla el criterio de decisión.

Cobertura de Decisión/Condición: Requiere presentar un número suficiente de casos de prueba de tal modo que cada condición
en una determinada decisión tenga todas las posibles salidas y que cada punto de entrada sea activado, por lo menos una vez.

Cobertura de Condición Múltiple: Requiere que se escriban un número suficiente de casos de prueba como para que todos las
combinaciones posibles de resultados de cada condición en cada decisión se invoquen al menos una vez.

b) Técnicas de Caja Negra

También llamada prueba producida por los datos o por entrada/salida. Su interés se dirige a encontrar circunstancias en las
cuales el programa no se comporta de acuerdo a sus especificaciones. Los datos de prueba se preparan de acuerdo a las
especificaciones.
El criterio es probar la entrada de datos exhaustivamente. Para detectar errores de este tipo habría que usar no solamente los
datos de entrada válidos sino también todos los datos de entrada posibles.
El objetivo debe ser maximizar el rendimiento de la inversión en pruebas, osea maximizar el número de errores encontrados en
un número finito de casos de prueba.
Debe buscarse el subconjunto de casos con mayor probabilidad de encontrar errores.

Las propiedades de un caso bien elegido, osea para formar ese subconjunto son:
(1) Reduce el número de otros casos, eso implica que el caso invoque el máximo número de condiciones de entrada
diferentes para minimizar el número total de casos.

(2) Cubre un conjunto extenso de otros casos posibles, dice algo acerca de la ausencia o presencia de errores con respecto al
conjunto específico de valores de entrada y también de otros.

Las técnicas de Caja Negra de mayor aplicación son:

1) Particiones de equivalencia
Se basa en las dos propiedades (1 y 2) consideradas para definir un caso de prueba bien elegido. Es decir que si un caso de
prueba perteneciente a una clase de equivalencia detecta un error, se espera que cualquier otro caso perteneciente a la misma
clase detecte el mismo error.
Etapas: El proyecto de casos de prueba por medio de partición de equivalencias se realiza en dos pasos.

a) Identificación de las clases de equivalencias

Las clases de equivalencias se identifican tomando cada condición de entrada (usualmente sacada de la especificación) y
dividiéndola en dos o más grupos. Se identifican dos tipos de clases:
• Clases de equivalencias válidas: Representan entradas válidas al programa.
• Clases de equivalencias inválidas: Representan todos los otros estados posibles de la condición, valores erróneos de
entrada.

b) Identificación de los casos de prueba (el proceso consiste en):

- Asignar un único número a cada clase de equivalencia.
- Hasta que todas las clases de equivalencias hayan sido cubiertas por casos de prueba, escribir un nuevo caso que cubra tantas
clases de equivalencias válidas no cubiertas como sea posible.
- Hasta que todas las clases de equivalencias inválidas hayan sido cubiertas por casos de prueba, escribir un caso para cubrir, una
y solo una, de las clases de equivalencias no cubiertas.
 2) Análisis de Valores Límites (AVL)
Las condiciones límites son las situaciones que se hallan directamente arriba y debajo de los márgenes de las clases de
equivalencias de entrada y de salida. Es una técnica de diseño que complementa a la de particiones de equivalencia; las
diferencias son:
• Más que elegir cualquier caso como representativo de una clase de equivalencia, se requiere la selección de uno o más
elementos, tal que los márgenes se sometan a prueba.
• Más que concentrarse en el dominio de la entrada, los casos de prueba se generan considerando también el espacio de
salida.

3) Gráficos Causa-Efecto
Constituyen una técnica que ayuda de una manera sistemática en la selección de un conjunto productivo de casos de prueba. Es
una técnica para la representación concisa de las condiciones lógicas y de sus correspondientes acciones. Sigue 4 pasos:
1º) Se listan para un módulo las causas (condiciones de entrada) y los efectos (condiciones de salida, acciones), asignando un
identificador a cada uno de ellos. Luego se identifican las causas y los efectos en la especificación.
2º) Se desarrolla un gráfico causa-efecto. El contenido semántico de la especificación se analiza y se transforma en un gráfico
booleano que une causas con efectos. Este es el gráfico causa-efecto.
3º) Se convierte el grafo en una TD. Cada columna en la tabla representa un caso de prueba.
4º) Se convierten las reglas de la TD a casos de prueba.

4) Conjetura de errores
La idea básica es enumerar una lista de errores posibles o de situaciones propensas a ciertos errores y generar casos de prueba
en base a esa lista (suelen ser errores que aparecen comúnmente y no con aspectos funcionales).
Ésta técnica también se ha denominado generación de casos o valores especiales, no obtenidos en base a otros métodos sino
mediante la intuición o la experiencia.
Enfoque Práctico Recomendado: Pretende mostrar el uso más apropiado de cada técnica para la obtención de un conjunto de
casos útiles sin perjuicio de las estrategias de niveles de prueba.
Documentación de la ejecución de pruebas (se puede distinguir 2 grupos principales):
• Documentación de entrada, constituida principalmente por las especificaciones de los casos de pruebas a usar y de los
procedimientos de prueba.
• Documentación de salida o informe sobre la ejecución, cada ejecución de pruebas va a generar 2 tipos de documentos:
o Histórico de pruebas: documenta todos los hechos relevantes ocurridos durante la ejecución de las pruebas.
o Informe de los incidentes ocurridos durante la ejecución: documenta cada incidente ocurrido en la prueba que
requiere una posterior investigación.

La documentación de salida correspondiente a un mismo diseño de prueba se recoge en un informe resumen de pruebas. Ese
informe resume los resultados de las actividades de pruebas reseñadas en el informe y proporciona una evaluación, basada en
esos resultados del software.
Unidad 5: Documentación y Mantenimiento de Programa

Documentación: Es el nexo entre las distintas actividades que se realizan y es la que permite ejercer el control efectivo del
Proyecto.

Objetivos internos: Se refiere a la necesidad de transmitir información de un grupo a otro. Se documenta con el propósito de:
• Comprender con claridad los compromisos que se asumen, las políticas que se definen y los riesgos que se corren.
• Comunicar información referida a los productos de un sector del área a otro.

Objetivos Externos: Se persigue la comunicación con el usuario, por lo tanto se debe lograr que entienda la documentación para
que pueda ejercer el control. Podemos citar como objeto a:
• Controlar las alternativas que sufre el proyecto y prevenir con anticipación situaciones indeseables.
• Comunicar a los usuarios las decisiones de diseño referidos a los productos.
Se considera como documentación del programa al conjunto de descripciones escritas que explican al lector qué hace el programa
y como lo hace.
Existen 3 grupos de personas que necesitan conocer la documentación del programa, donde los requerimientos de cada uno suelen
ser diferentes, en función de las misiones de cada grupo:
• Programadores: Manual de mantenimiento del programa.
• Operadores o administradores de red: Manual de operación.
• Usuario: Manual de usuario.
La documentación del programa debe ser de 2 tipos, para personal informático y documentación del usuario.

Manual de mantenimiento del programa: Es la documentación requerida para mantener el programa durante su ciclo
de vida. Se divide en dos categorías:
a) Documentación interna: Contiene información dirigida a quienes leerán el código fuente del programa. Se incluye información
sumaria para identificar el programa y describir algoritmos, estructuras de datos y flujo de control. Usualmente esta información
se ubica al comienzo de cada módulo en un conjunto de comentarios que se denomina bloque de encabezamiento.
Encabezamiento: Al comienzo de los programas es necesario incluir encabezamiento que contenga información acerca de cada
módulo o componente. Porque el nombre del módulo debe aparecer en un lugar destacado de la documentación, también se
identificará al autor. Debido a que un módulo es parte de un sistema mayor, este bloque debe indicar como encaja en la jerarquía
de componentes. En el encabezamiento también puede explicarse la forma en que es invocado el módulo.
Otros comentarios del programa: El encabezamiento actúa como una introducción al programa. Los comentarios adicionales
indican a los lectores a medida que se desplazan a lo largo del programa, ayudándoles a comprender como las intenciones
enunciadas en el encabezamiento están implementadas en el código. Estos comentarios resultan particularmente útiles toda vez
que deba agregarse información de ayuda a un módulo o componente. Es importante comprobar que estas agreguen nueva
información en lugar de enunciar lo que resulta obvio al usar etiquetas y nombres de variables apropiados.
Documentación de los datos: Para los lectores de programas, la comprensión de la forma en que se estructuran y utilizan los
datos es uno de los aspectos que presentan más dificultades. Un mapa de datos es muy útil para la interpretación de las acciones
de código, especialmente cuando el sistema maneja varios archivos de distintos tipos y propósitos, acoplados por medio de
señales de control (banderas) y pasaje de parámetros.
 En consecuencia la documentación interna debe incluir las descripciones de las estructuras de datos y su utilización.

b) Documentación externa: Se prepara para ser leída por quienes tal vez nunca verán el código real. Brinda una oportunidad
para explicar las cosas en forma amplia; constituyen un informe totalmente desarrollado.
La documentación externa de módulos es parte de la documentación total del sistema.
Descripción del problema: En la primera sección de la documentación del código se debe explicar el problema tratado por el
módulo. Aquí se describen las opciones que se consideran como vías de solución y de porqué se seleccionó una en particular.
Descripción de los algoritmos: Se deben explicar todos los utilizados en el módulo; incluyendo fórmulas, condiciones especiales
o de límite.
Descripción de los datos: Los usuarios y los programadores deben ser capaces de ver el flujo de datos a nivel del módulo.
La documentación externa debe incluir:
• Listado actual del programa fuente, mapas de memorias, referencias cruzadas, etc.
• Especificación del programa; documento que define el propósito y modo de funcionamiento del mismo
• Diagrama de estructura que represente la organización jerárquica de los módulos que comprende el programa.
• Explicaciones de formulas complejas
• Especificación de los datos o procesos: archivos externos incluyendo el formato de las estructuras de los registros,
campos, etc.
• Formatos de pantallas utilizados para interactuar con los usuarios.

Manual de usuario: La documentación para clientes y usuarios debe incluir, en lenguaje natural, una descripción general de
las tareas que realiza el programa, asi como una descripción detallada de todas las instrucciones que sean necesarias para su
instalación, puesta en marcha y funcionamiento, además de consejos, recomendaciones de uso, etc.
Contiene descripciones de los módulos o componentes del sistema.

Mantenimiento: Se considera como mantenimiento cualquier trabajo que se realice para cambiar un sistema después de
ponerlo en operación. Muchas personas piensan que el mantenimiento del software es igual al del hardware; pero no es así, la
principal diferencia es que el software se construye para que incorpore cambios. Salvo los casos más simples, los sistemas
desarrollados son evolutivos. Es decir una o más características que definen un sistema cambian normalmente durante la vida del
sistema.
Si se usan componentes muy cohesivos, con mínimo acoplamiento, si la documentación es completa y esta actualizada es
posible construir un sistema o programa correcto en el primer intento. Pero no hay manera de garantizar que los sistemas
requerirán cambios, por eso se deben construirlos para que los cambios puedan realizarse fácilmente.
Presman dice que los programas de computadoras siempre están cambiando, y que hay que solucionar errores, añadir mejoras
y llevar a cabo optimizaciones. Pero que no solo hay que cambiar la versión actual, sino también la pasada y la que viene. Además
de los problemas que requieren la realización de cambios para solucionarlos, el hecho mismo del cambio lleva problemas
adicionales.
Como el cambio es inevitable cuando se construyen sistemas basados en computadoras, se deben desarrollar mecanismos para
evaluar, controlar y hacer las modificaciones.

Actividades y roles del mantenimiento (el mantenimiento enfoca simultáneamente 4 aspectos de la evolución del
sistema)
1) Mantener el control sobre las funciones diarias del sistema (Mant. Correctivo)
2) Mantener el control sobre las modificaciones del sistema (Mant. Adaptativo)
3) Perfeccionar las funciones aceptables existentes (Mant. Perfectivo)
4) Impedir que el desempeño del sistema se degrade a niveles inaceptables (Mant. Preventivo)

Mantenimiento Correctivo: Es el proceso que incluye el diagnostico y la corrección de uno o mas errores. A medida que
ocurren las fallas se ponen a consideración del equipo: se encuentra la causa de la falla y se hacen las consideraciones y cambios
a los requerimientos, el diseño, código, sesiones de prueba y documentación según sea necesario.

Mantenimiento Adaptativo: Es la actividad que modifica el software para que interaccione adecuadamente con su entorno
cambiante.

Mantenimiento Perfectivo: Se lleva a cabo para satisfacer las peticiones recibidas por los usuarios en cuanto a
recomendaciones sobre nuevas posibilidades sobre modificaciones de funciones ya existentes y sobre mejoras en general. Implica
hacer cambios para mejorar algún aspecto del sistema, incluso los cambios no sugeridos por los defectos.

Mantenimiento Preventivo: Involucra la modificación de algún aspecto del sistema a fin de prevenir fallas. A partir del
momento en que se encuentra un defecto real o potencial se procede a corregirlo antes de que se produzca el daño. Fue liderado
por Hillar bajo la denominación de retroajuste estructurado y lo define como “la aplicación de las metodologías actuales a sistemas
de ayer para facilitar los requerimientos del mañana”.

Unidad 6: Programación orientada a objetos (POO)

El concepto de POO se basa en la idea natural de la existencia de un mundo lleno de objetos, de modo que la resolución del
problema se realiza en términos de objetos. Constituye una nueva forma de pensar acerca de problemas empleando modelos que
se han organizado tomando como base conceptos del mundo real. La construcción fundamental es el objeto que combina las
estructuras de datos con los comportamientos en una entidad única. Su ecuación básica es CODIGO + DATOS = OBJETO.
Según Booch, la POO, es un método de implantación donde los programas se organizan como colecciones cooperativas de
objetos, cada uno de los cuales representa una instancia de alguna clase, y cuyas clases son todos miembros de una jerarquía de
clases unidas a través de relaciones de herencia.
Un programa constituido con el de objetos es una colección de objetos cooperantes, que se comunican entre si a través del
intercambio de mensajes. Un lenguaje se dice que está basado en objetos, si soporta objetos como característica fundamental del
lenguaje, es decir, si brinda los mecanismos que soportan el estilo de orientación a objetos de manera relativamente fácil,
confiable y segura.

Diseño de software orientado a objetos

 Las fases de proceso ya no se realizan en cascada (una a continuación de otra) sino que actúan de forma similar a un espiral. El
ciclo de vida es repetitivo, es decir, está gobernado por numerosos procesos de realimentación (feed back), donde cada etapa se
revisa continuamente en función de los resultados de los demás.
Análisis de la Aplicación: En esta etapa el cliente y el desarrollador deben ponerse de acuerdo en la aplicación a realizar. El
analista debe hacer uso de su capacidad de abstracción para construir modelos del problema real. Esa abstracción provoca la
descomposición del problema en objetos, que representan las entidades que van a formar parte de la aplicación. La construcción
de un modelo hace que el cliente pueda entender la representación que se ha hecho de sus necesidades y pueda evaluar si ha sido
comprendido o no por el analista.
Diseño: Se caracteriza por el agrupamiento en clases de los objetos y el establecimiento de la jerarquía. En esta fase se deben
definir también los elementos de las bibliotecas disponibles y que se puedan aplicar y reutilizar en la aplicación. Con todo esto se
refina la estructura del programa, ese refinamiento sigue la filosofía “bottom-up”, es decir de abajo hacia arriba, ya que comienza
por los objetos, se agrupan en clases y se construye la estructura hasta llegar a la raíz de la jerarquía.
Codificación: Es la etapa en la que se procede a la creación del código de aquellos métodos nuevos, o bien se modifica aquellos
obtenidos de la biblioteca de objetos y que no se adapten en su totalidad a los requisitos establecidos en las fases anteriores.
Pruebas: A diferencia de la programación tradicional, la POO no es necesario esperar al final de la aplicación para comenzar las
pruebas. Gracias al encapsulamiento, las distintas clases son totalmente independientes y pueden revisarse por separado a medida
que se construyen.

Conceptos básicos:
El enfoque orientado a objetos esta compuesto por dos aspectos: Un modelo computacional y Una filosofía de desarrollo.
Un modelo computacional basado en objetos, es un mundo poblado por objetos que trabajan y cooperan entre sí, a través del
intercambio de mensajes, para realizar una determinada tarea. En este enfoque los objetos y las clases son los pilares, mientras
que los métodos, los mensajes y la herencia constituyen los mecanismos primarios.
Objeto: Es una entidad que posee atributos y características que describen su naturaleza y funcionalidad, es decir que tienen un
conjunto de responsabilidades y qie encapsula un estado interno. Cuando se desea ser preciso y aludir a una cosa exactamente se
utiliza la frase instancia de objetos y clase de objetos para aludir a un grupo de cosas similares. Un objeto se dice instancia de una
clase. Un objeto individual es una instancia de una clase más amplia.
Clases: Una clase de objetos describe un grupo de objetos con propiedades (atributos) similares, con relaciones comunes con
otros y con una semántica común.
Los objetos de una clase tienen los mismos atributos y los mismos patrones de comportamiento. Cada objeto conoce su clase y
la clase de objeto es una propiedad implícita de si mismo. Al agrupar los objetos en clases se abstrae el problema, esa abstracción
da al modelado su potencia y capacidad para generalizar, partiendo de unos pocos casos específicos hasta llegar a una multitud de
cosas similares. Es posible escribir operaciones una sola vez para cada clase de tal manera que todos los objetos de la clase se
benefician de la reutilización del código.
Un primer nivel de abstracción permite identificar las clases de tal forma que cada objeto pertenece a una clase y de ella hereda
las propiedades comunes a todos sus hermanos de la misma clase.
Un segundo nivel de abstracción permite ver que las clases identificadas muestran propiedades comunes que permiten
agruparlos en superclases, de manera que s e forma una jerarquía “super clase / clase / objeto”.
Los diagramas de objetos proporcionan una notación gráfica formal para el modelado de objetos, clases y sus relaciones. Un
diagrama de clase es un esquema para describir instancias de objetos. Los diagramas de instancias son útiles para documentar
casos prácticos y para describir ejemplos.
Atributos: es un valor de un dato que esta almacenado en los objetos de una clase (nombre, edad, son atributos de los objetos
Persona). Cada atributo tiene un valor para cada instancia y su nombre es único dentro de la clase. Se enumeran en la segunda
parte del cuadro de clase.

Operaciones y métodos
Operaciones: Es una función o transformación que se puede aplicar o ser aplicada por los objetos de una clase. Todos los
objetos de una clase comparten las mismas operaciones y una misma operación puede aplicarse a clases distintas. Tal operación
será polimorfita, esto es, una misma operación adopta distintas formas en distintas clases. Se enumeran en el tercio inferior del
cuadro de clases
Método: Es la implementación de una operación para una clase.
Hay que evitar utilizar el mismo nombre para dos operaciones que sean semánticamente distintas, aún cuando sean aplicables a
conjuntos distintos de clases.
Mensaje: Es un requerimiento a un objeto para que realice alguna de sus operaciones. Los objetos solo interactúan entre ellos
a través del pasaje de mensajes que requiere que se ejecuten ciertas operaciones.
Todo procedimiento es activado por mensajes entre objetos. Un objeto que reciba un mensaje va a ejecutar una acción
específica como respuesta (alterando su estado interno, enviando mensajes a otros objetos, etc).

Características de los objetos

Identidad: Todos los objetos poseen su propia identidad y se pueden distinguir entre si. Identidad significa que los objetos se
distinguen por su existencia inherente y no por las propiedades descriptivas que puedan tener, esto quiere decir que los datos
están cuantificados en entidades discretas y distinguibles denominados objetos. Si cada objeto posee su propia identidad
inherente, entonces, dos objetos serán distintos aún cuando los valores de todos sus atributos (como nombre y tamaño) sean
idénticos.
Denominación: Dentro de un lenguaje de programación cada objeto posee una denominación mediante la cual se puede hacer
alusión a él de modo exclusivo. La denominación se puede implementar de distintas maneras como una dirección, un índice de una
matriz o un valor exclusivo de un atributo. Las referencias de los objetos son uniformes e independientes del contenido de los
objetos permitiendo crear colecciones mixtas de objetos.
Clasificación: Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se
aglutinan para formar una clase. Toda clase describe un conjunto posiblemente infinito de objetos individuales. Se dice que cada
objeto es una instancia de su clase, donde cada uno de ellas posee su propio valor para cada uno de los atributos pero comparte
los nombres de estos y las operaciones con las demás instancias de la clase.
Una instancia es entonces un objeto creado a partir de una clase.

Propiedades de la POO
Encapsulamiento: es el estado de un objeto, se implementa mediante un conjunto de propiedades o atributos encapsulados. El
encapsulamiento consiste en la creación de objetos que funcionan como unidades completas. La combinación de características y
métodos (código y datos) dentro del mismo objeto se denomina encapsulamiento. Es decir que los objetos encapsulan y abstraen
tanto datos como procesos.
También se lo denomina ocultamiento de información, ya que implica incluir en un objeto todo lo que necesite y además
haciéndolo de tal forma que ningún otro objeto necesite enterarse nunca de su estructura interna. De esta manera la
implementación de un objeto se puede modificar sin afectar a las aplicaciones que la utilizan.
Beneficios:
• Los detalles de implementación interna de datos y procedimientos están ocultos al mundo exterior (ocultamiento de
información). Esta reduce la propagación de efectos colaterales cuando ocurren cambios.
• Las estructuras de datos y las operaciones que los manipulan están mezclados en una entidad sencilla, la clase. Eso
facilita la reutilización de componentes.
• Las interfaces entre objetos encapsulados están simplificados. Por lo tanto simplifica la interacción y el acoplamiento del
sistema a reducirse.
Herencia: Significa compartir atributos y operaciones entre clases tomando como base una relación jerárquica. Se puede definir
una clase que después se irá refinando sucesivamente para producir subclases; las cuales poseen o heredan todas y cada uno de
las propiedades de su superclase y añaden, además, sus propiedades exclusivas. No es necesario repetir las propiedades de las
superclases en con subclase.
La herencia permite no escribir código de más.
Una de las ventajas principales de un sistema orientado a objetos, es la capacidad de sacar factor común a las propiedades de
varias clases en una superclase común y de heredar las propiedades de la superclase puede reducir muchísimo la repetición en el
diseño y en los programas. Es importante destacar que en cada nivel de la jerarquía de clases, pueden añadirse nuevos atributos y
operaciones a aquellos que han sido heredados de niveles superiores de la jerarquía. Por lo tanto cada vez que se debe crear una
clase, el ingeniero de software tiene varias opciones:
• La clase puede diseñarse y construirse de la nada. Esto es, no se usa la herencia.
• La jerarquía de clases puede ser rastreada para determinar si una clase ascendente contiene la mayoría de los atributos y
operaciones requeridas.
• La nueva clase hereda de su clase ascendente, y pueden añadirse los elementos requeridos.
• La jerarquía de clases puede reestructurarse de tal manera que los atributos y operaciones requeridos puedan heredarse
por la nueva clase.

Herencia simple: Cuando una subclase hereda los atributos y los comportamientos de una única clase padre.

Herencia múltiple: Brinda la posibilidad de que una subclase pueda adquirir los atributos y comportamientos de más de una
clase padre. La mayor dificultad es que en algunas ocasiones, las propiedades que se heredan de dos o más clases padres pueden
ser directa o parcialmente contradictorias. Esta herencia complica la jerarquía de clases y crea problemas en el control de la
configuración.
Si una clase A es subclase de B, los objetos de A van a tener las características descriptas en A más los heredados de B.
Herencia de comportamiento: Cuando los objetos de A entienden todos los mensajes definidos en A más los de B.
Herencia de atributos: Cuando los objetos de A tienen los atributos definidos en A más los de B.

Beneficios de la herencia:
• Adicionar nuevos atributos y funcionalidad.
• Cambiar el comportamiento heredado.
• La herencia múltiple suma flexibilidad.
• Crear nuevas clases de objetos a partir de clases existentes.

Herencia simple: Diseño claro y limpio (ventaja). Pobre adecuación (desventaja).

Herencia múltiple: Mayor flexibilidad (ventaja). Mayor complejidad (desventaja).

Polimorfismo: Se refiere a la capacidad de un determinado comportamiento de ser común a varia clases, o de tener varias
interpretaciones de acuerdo a la clase a que se haga referencia. Es decir, una misma operación puede comportarse de distintos
modos en distintas clases, es decir, una misma operación adopta distintas formas en distintas clases.
Una implementación específica de una operación para una cierta clase se denomina método. En un sistema con polimorfismo
una operación puede tener más de un método que lo implemente.
En lenguaje de POO se diseña para seleccionar automáticamente el método correcto para implementar una operación, los datos
asociados con la operación como parámetros, y el nombre de la clase de objeto.
Desarrollo de software usando POO
El proceso de construcción de software en el paradigma de objetos, consiste en definir clases.
Beneficios de la POO:
• Código reusable.
• Código extensible.
• Código modular.
• Código fácil de modificar.
Esto trae como consecuencia:
• Alta productividad del programador.
• Software más capaz, con menos errores.

Las características que presenta la orientación a objeto son muy útiles para el mantenimiento. Estas son:
a) La modularidad atenúa los efectos que puedan producir los cambios en los programas.
b) La herencia permite construir un nuevo programa sin destruir el antiguo.
c) Los métodos están localizados (sin repetición) lo que hace que sean más fáciles de ubicar y modificar.
d) El polimorfismo reduce el número de procedimientos y en consecuencia el tamaño del programa.

Ventajas de la orientación a objetos:

• Posibilidad de modificar continuamente el software durante las distintas fases de desarrollo a bajo costo.
• En cualquier fase se pueden realizar modificaciones y retornos que conduzcan a una mejor definición de las clases y
métodos del sistema.
• En el desarrollo orientado a objetos estas modificaciones no afectan al resto de los elementos del sistema ya que este se
compone de un conjunto de objetos y métodos donde cada objeto es una entidad aislada. Es muy sencillo agregar clases
nuevas al sistema.
• El encapsulamiento otorga grandes posibilidades al desarrollo de software, tanto para dotarle de gran potencia como para
facilitar su mantenimiento.
• Lleva implícito el concepto de reutilización de desarrollos anteriores.
• Incorporan una biblioteca de clases, lo que permite saber a los diseñadores de que clases pueden disponer, ya que les
ahorrará mucho tiempo y hará que sus desarrollos ganen en potencia.
• El mayor esfuerzo se aplica en la fase de diseño y análisis.