You are on page 1of 86

Programacin Orientada a Objetos

TEMA 1
Orientacin a objetos, una tcnica para
mejorar la calidad del software

Facultad de Informtica
Universidad de Murcia

ndice
1.- Calidad del software
2.- Modularidad
3.- Reutilizacin
4.- Diseo Estructurado vs. Diseo OO
5.- Tipos abstractos de datos
Calidad del Sofware

1.- Calidad del Software


Factores Externos

Pueden ser detectados por los usuarios


Calidad externa es la que realmente preocupa

Factores Internos
Slo los perciben los diseadores e implementadores
Medio de conseguir la calidad externa
OBJETIVO

Buenas propiedades
internas

Satisfacer factores
externas

La POO es un conjunto de tcnicas para obtener calidad interna como


medio para obtener calidad externa (Reutilizacin y Extensibilidad)

Factores de calidad del Software


Factores Externos
- Correccin
- Robustez
- Extensibilidad
- Reutilizacin
- Compatibilidad

- Eficiencia
- Portabilidad
- Facilidad de uso
- Funcionalidad
- Oportunidad

- Economa
- Integridad
- Facilidad de reparacin
- Facilidad de verificacin

Factores Internos
- Modularidad
- Legibilidad
Calidad del Sofware

Correccin
Es la capacidad de los productos software de realizar con
exactitud su tarea, tal y como es definida en la especificacin.
- Definir los requisitos de manera precisa

Robustez
Es la capacidad de los productos software de reaccionar
adecuadamente ante situaciones excepcionales

Tienen que ver con el


Robustez

ESPECIFICACIN
Correccin

comportamiento
(casos previstos o no)

Extensibilidad
Es la facilidad de adaptacin de los productos software a los
cambios en la especificacin.

Cambios son frecuentes puesto que en la base de todo


software hay algn fenmeno humano.
Dificultad de adaptacin proporcional al tamao del
sistema.
Principios esenciales para facilitar la extensibilidad
Simplicidad de la arquitectura del software
Descentralizacin: mdulos autnomos
Calidad del Sofware

Reutilizacin
Es la capacidad de un producto software de ser
utilizado en la construccin de diferentes aplicaciones
No reinventar soluciones para problemas ya resueltos.
Se escribe menos software, luego se puede dedicar mas tiempo
a mejorar otros factores (fiabilidad)

Compatibilidad
Es la facilidad de combinar unos elementos software con
otros
Los sistemas necesitan interactuar con otros
Convenciones estndar de comunicacin inter-mdulos
Calidad del Sofware

Eficiencia
Es la capacidad de un sistema software de requerir la
menor cantidad posible de recursos hardware.

Factor importante para la utilizacin


Algunos estn obsesionados con micro-optimizaciones
Debemos conjugar eficiencia con los otros objetivos
Los mecanismos OO deben ser implementados de un modo
eficiente tanto en tiempo como en espacio

Portabilidad
Es la facilidad de transferir productos software a
diferentes plataformas (entornos hw y sw)
Calidad del Sofware

Facilidad de uso
Es la facilidad con la que personas con diferentes niveles de
experiencia pueden aprender a usar los productos software y
aplicarlos a resolver problemas. Tambin incluye la facilidad
de instalacin, operacin y supervisin.

Funcionalidad
Conjunto de posibilidades ofrecido por un sistema
Evitar aadir propiedades de forma incontrolada
Buen producto software debe estar basado en un pequeo
nmero de grandes ideas
Mantener constante el nivel de calidad
Calidad del Sofware

Oportunidad
Es la capacidad de un sistema software de ser lanzado
cuando los usuarios lo desean, o antes

Otros factores
Economa:
completarse con el presupuesto asignado

Integridad:
proteger contra modificaciones y accesos no autorizados

Facilidad para reparaciones (de defectos)


Facilidades de verificacin:
datos de prueba y procedimientos para detectar fallos

Calidad del Sofware

10

Consecuencia de estos criterios:


Necesidad de una BUENA DOCUMENTACIN:
externa (usuarios) facilidad de uso
interna (desarrolladores) extensibilidad
interfaz del mdulo extensibilidad y reutilizacin

Factores pueden entrar en CONFLICTO:

integridad facilidad de uso


economa funcionalidad
eficiencia portabilidad
ajustarse a la especificacin reutilizacin

Calidad del Sofware

11

Mantenimiento del software


No figura como factor facilidad de mantenimiento
Mantenimiento es lo que sucede despus de que se ha
distribuido un producto de software.
Se le dedica el 70 % del coste del software
Qu significa mantenimiento en software?
Parte noble: MODIFICACIN
adaptacin a los cambios
Parte no noble:
DEPURACIN
quitar errores

Calidad del Sofware

12

Costes de mantenimiento del software


Mejoras en la
eficiencia

[Lientz 1980]

Otros
3,50%
4%

Documentacin

Cambios en
los requisitos
de los usuarios

5,50%

Cambios en el
hardware

6,20%
41,80%
9%

Arreglos de
rutinas

Cambios de
emergencia

Cambios en
los formatos de
los datos

12,40%

17,60%

Calidad del Sofware

13

Conclusiones del estudio


418% extensiones y modificaciones usuario Ausencia
de extensibilidad
176% cambio de los datos Estructura fsica de los
datos dispersa por muchas partes del sistema
55% Documentacin No se hace documentacin a
posteriori
4% Mejoras en la eficiencia Cuando el sistema funciona
no se buscan mejoras en eficiencia.

Calidad del Sofware

14

2.- Modularidad
Extensibilidad + Reutilizacin necesidad de
arquitecturas flexibles hechas con componentes autnomos
Programa modular: formado por un conjunto de mdulos
Mdulo: unidad bsica de descomposicin de un sistema
software
Un mtodo de construccin de software es modular si
ayuda a producir sistemas software a partir de
elementos autnomos interconectados por una
estructura simple y coherente.
Cinco criterios, cinco reglas, cinco principios.
Calidad del Sofware

15

Modularidad: 5 criterios
Requisitos que debe satisfacer un mtodo de
construccin de software para merecer el nombre de
modular:
Permitir una descomposicin modular
Permitir una composicin modular
Producir mdulos fciles de comprender
Favorecer la continuidad del software
Proteccin modular
Calidad del Sofware

16

C1) Descomposicin modular


Un mtodo de construccin de software satisface la
Descomposicin Modular si permite la descomposicin de un
problema en un pequeo nmero de subproblemas menos
complejos, conectados por una estructura simple, y que se
pueden abordar por separado.

Importante que las dependencias sean mnimas y que


se conozcan.
Ejemplo: Diseo descendente
Contra-ejemplo: Mdulos de inicializacin global
Calidad del Sofware

17

C2) Composicin modular


Un mtodo satisface la Composicin Modular si favorece la
produccin de elementos software que pueden ser combinados
para crear nuevos sistemas, posiblemente en un entorno
diferente a aquel en el que se idearon.

Relacionada con el objetivo de reutilizacin


Independiente de la descomposicin modular
Ejemplos: Libreras de rutinas, filtros de Unix
Contra-ejemplo: Preprocesadores de lenguajes
Calidad del Sofware

18

C3) Comprensin Modular


Un mtodos favorece la Comprensin Modular si
facilita que quin lea un mdulo pueda comprenderlo
sin necesidad de acudir a otros mdulos (en el peor
de los casos a unos pocos mdulos).
Relacionado con el mantenimiento
Contra-ejemplo: Dependencias secuenciales
Calidad del Sofware

19

C4) Continuidad Modular


Un mtodo satisface la Continuidad Modular si se favorecen
arquitecturas software en las que un cambio pequeo en la
especificacin origina un cambio en un solo mdulo, o en un
pequeo nmero de mdulos.

Relacionado con la extensibilidad


Ejemplos:
Constantes simblicas y Principio de Acceso Uniforme

Contra- ejemplos:
Diseo de programas basado en la representacin fsica de los datos y el uso
de arrays estticos

Calidad del Sofware

20

C5) Proteccin Modular


Un mtodo satisface la Proteccin Modular si se originan
arquitecturas en las que el efecto de una condicin excepcional
acaecida en tiempo de ejecucin slo afecta al mdulo dnde se
produce, o slo se propaga a los mdulos vecinos.

Relacionado con la robustez


Ejemplo:Mdulos de entrada de datos
comprueben su validez.
Contra-ejemplo: Excepciones no disciplinadas.
Calidad del Sofware

21

Modularidad: 5 reglas
De los criterios anteriores se derivan cinco reglas que
se deben seguir para asegurar la modularidad
Correspondencia directa
Pocas conexiones entre mdulos
Intercambio de informacin intermodular mnimo
Conexiones explcitas
Ocultamiento de Informacin
Las cuatro ltimas se refieren a la comunicacin entre
mdulos: uso o comparticin de datos
Calidad del Sofware

22

R1) Correspondencia directa


La estructura modular ideada en el proceso de
construccin del sistema software debera permanecer
compatible con cualquier estructura modular ideada
en el proceso de modelar el dominio del problema.
Criterios de los que se deriva:

- Descomposicin: la descomposicin del dominio


del problema es un buen punto de partida para
software.

descomponer el

- Continuidad: mantener la estructura del problema en la


solucin hace ms sencillo estimar y limitar el impacto de los
cambios.

Calidad del Sofware

23

R2) Pocas Interfaces


Cada mdulo debera comunicarse con el menor
nmero posible de otros mdulos.
Criterios:
Continuidad y Proteccin: propagacin
de cambios o errores a un gran nmero de mdulos

Composicin: si se quiere utilizar en un nuevo


entorno debe tener pocas dependencias con otros

Comprensin
Descomposicin
24

R3) Interfaces Pequeas


Si dos mdulos se comunican deberan intercambiar la
menor cantidad de informacin posible.
Criterios: Continuidad y Proteccin
(propagacin de cambios y errores)

R4) Interfaces Explcitas


La existencia de una comunicacin entre dos mdulos
cualesquiera, A y B, debe ser obvia del texto de A, B o
ambos.
Calidad del Sofware

25

Criterios:
Composicin y descomposicin: si se necesita
descomponer un mdulo en varios mdulos o componer uno a partir de otros,
debe estar visible cualquier conexin externa.

Continuidad: deber ser fcil detectar a quin puede afectar un cambio


potencial.

Comprensin: no se puede entender A si no se conoce cmo influye B

Problema:

Compartir datos
no hay ninguna conexin aparente

Modulo A

modifica

Dato X

Modulo B

accede

Calidad del Sofware

26

R5) Ocultacin de la Informacin


El diseador de un mdulo debe seleccionar un
subconjunto de las propiedades del mdulo como la
informacin oficial, que estar disponible a los
creadores de mdulos clientes
Qu propiedades deberan ser pblicas y cules secretas?
Parte Pblica (Interface) vs. Parte Privada
(FUNCIONALIDAD)

(IMPLEMENTACIN)

27

EJEMPLO: Mdulo que define cuentas bancarias


Representacin
NombreCli:String
Codigo:String
Saldo:Entero
UltOper: Lista

Interfaz
reintegro()
ingreso()
verSaldo()

Operaciones
reintegro()
ingreso()
verSaldo()
calculaIntereses()

NO

SI

Un modulo incluye una estructura de datos junto con un


conjunto de operaciones para manipularla.
28

R5) Ocultacin de la Informacin (cont.)


Criterios:
- Continuidad: cambios en la parte privada slo afecta
a ese mdulo, no a los clientes

- Descomposicin, composicin y
comprensin: no se pueden desarrollar mdulos por
separado, combinar o entender los mdulos individuales si no
se lo que se puede esperar de ellos.

Calidad del Sofware

29

Modularidad: criterios y reglas


Descomposicin

Correspondencia directa

Composicin

Pocas interfaces

Comprensibilidad

Interfaces pequeas

Continuidad

Interfaces explcitas

Proteccin

Ocultacin de Informacin

Calidad del Sofware

30

Modularidad: 5 principios
A partir de las reglas (e indirectamente de los criterios)
se derivan cinco principios de construccin de software:
Unidades Modulares Lingsticas
Auto-documentacin
Acceso Uniforme
Abierto-Cerrado
Eleccin Unica
Calidad del Sofware

31

P1) Unidades Modulares Lingsticas


Mdulos deben corresponder a unidades sintcticas en
el lenguaje usado
Lenguaje de especificacin, diseo, programacin,..
En el caso de lenguajes de programacin, los mdulos deben ser
compilables por separado.
Un mtodo no puede proponer un concepto de mdulo que no
soporte el lenguaje.
Afecta a:
Criterios: continuidad, composicin, descomposicin y proteccin.
Regla: Correspondencia directa

Calidad del Sofware

32

P2) Auto-documentacin
Toda la documentacin interna sobre el mdulo
debera ser parte del propio mdulo
Se favorecen los criterios:
- comprensin modular
- continuidad: si se tratan como entidades
separadas es difcil garantizar que
permanezcan
compatibles cuando las cosas empiecen cambiar.
Calidad del Sofware

33

P3) Acceso Uniforme


Todos los servicios ofrecidos por un mdulo deben
estar disponibles mediante una notacin uniforme, que
no considere si se han implementado mediante
almacenamiento o clculo
Favorece la continuidad
Sea c una variable representando una cuenta bancaria y saldo
una propiedad aplicable a c,
Cmo expresamos la aplicacin de saldo a c, de un modo
independiente a la implementacin de saldo (almacenamiento o
clculo)?
saldo es un campo de un registro: c.saldo
saldo es una funcin: saldo(c)
Calidad del Sofware

34

P4) Principio Abierto-Cerrado


Los mdulos deberan ser a la vez abiertos y
cerrados
MDULO ABIERTO: Disponible para ampliarlo
MDULO CERRADO: Disponible para su uso

Los dos objetivos son incompatibles con las tcnicas


tradicionales:
- o est abierto no se puede utilizar todava
- o se cierra cualquier cambio provoca cambio en
cadena
Calidad del Sofware

35

Principio Abierto-Cerrado
B

D
A

Dos soluciones:

C
F
A
H

Adaptar el mdulo A
(cambios en cadena en los clientes)
Crear una copia de A
(explosin de variantes de mdulos)

Es posible adaptar A sin afectar a los clientes?


Cmo se pueden obtener mdulos que sean a la
vez abiertos y cerrados?
Calidad del Sofware

36

Principio abierto-cerrado
B

D
A

C
F
A

H
Solucin: HERENCIA
A contiene solamente las diferencias :
- nuevas caractersticas
- redefiniciones para los clientes
Calidad del Sofware

37

P5) Eleccin nica. Ejemplo


Mdulo A:

TYPE Publicacion
autor, titulo: String
ao: Integer;
CASE tipoPubli (libro, revista, articulo) of
libro: (editorial: String);
revista: (editor: Sring; periodicidad: Periodo);
articulo: (revista, volumen, numero: String)
END;

Sea B un cliente de A, tendra p:Publicacin


case p of
libro: acceso a los campos de libro

Si aadimos un nuevo tipo de publicacin?


Cualquier cliente de A tendra que actualizar su estructura

38

Eleccin nica
Siempre que un sistema software debe manejar una
lista de variantes, uno y solo un mdulo del sistema
debe conocer la lista exhaustiva
Consecuencia del Principio Abierto-Cerrado
Forma fuerte de ocultamiento de la informacin
(la lista de variantes a los clientes)
Se favorece la continuidad
Se limita la distribucin del conocimiento
(cliente slo conoce lo necesario para su funcionamiento)
Calidad del Sofware

39

3.- Reutilizacin del software


Por qu el software no es como el hardware (catlogos de
dispositivos que se combinan)?
Por qu cada nuevo proyecto software arranca de la nada?
Creciente importancia de los componentes en la industria del
software: (Frameworks, Active X, JavaBeans, )
Internet favorece la reutilizacin.

La tecnologa OO har realidad en un futuro


cercano el sueo de una industria basada en
componentes
Calidad del Sofware
40

Beneficios esperados de la reutilizacin


A) CONSUMIR elementos reutilizables:
Oportunidad (se reduce el tiempo de desarrollo)
=> Mejora productividad
Disminuye el esfuerzo del mantenimiento
Aumenta fiabilidad
Aumenta eficiencia

B) PRODUCIR elementos reutilizables:


Inversin: preservar la experiencia de los mejores desarrolladores
Si un elemento software se utilizar en muchos proyectos es
rentable invertir en mejorar su calidad

Consumir antes de producir


Calidad del Sofware

41

Qu debemos reutilizar?
PERSONAL:
experiencia previa ayuda en el nuevo desarrollo
necesidad de personal con experiencia para conocer qu aplicar

DISEO:
difcil garantizar compatibilidad diseo-implementacin.
Interesante enfoques donde la diferencia entre mdulo diseo y mdulo de
implementacin desaparece
Nos recuerda la necesidad de generalidad en los componentes

PATRONES DE DISEO:
Ideas aplicables a toda una gama de dominios.
Un patrn propone solucin para un problema de diseo.
No tiene que ser una mera descripcin de un libro sino un componente software

Calidad del Sofware

42

Qu debemos reutilizar?
CDIGO FUENTE:
ninguno de los anteriores se pueden incluir en un nuevo producto de
software => texto fuente
Impedimentos econmicos y psicolgicos
Viola el principio de ocultamiento de informacin y reglas de modularidad
Recuerda la necesidad de que componente reutilizable= elemento software

MDULOS ABSTRACTOS:
Son las unidades de reuso, software directamente
utilizable con una descripcin abstracta de sus
propiedades
Calidad del Sofware

43

Por qu no es comn la reutilizacin?


Naturaleza repetitiva de
(ordenar, buscar, recorrer, ...)

la

programacin

Cuntas veces en los ltimos 6 meses has escrito


cdigo para buscar un elemento en una coleccin?
Problemas tcnicos
ENTONCES?

Problemas no tcnicos

Calidad del Sofware

44

A) Obstculos no tcnicos
Sndrome N.I.H

(Not Invented Here).:

reaccin cautelosa frente a componentes nuevos


coste adicional de aprendizaje

Econmicos:
se centran en los costes a corto plazo

Estrategias de las compaas software:


Y si el cliente no vuelve a necesitarnos?

Acceso a los componentes:


www facilita la bsqueda de informacin til

Formato de distribucin
fuente o binario?

Calidad del Sofware

45

B) Dificultades tcnicas
Disear cdigo reutilizable es difcil.
Hacemos las mismas cosas pero no de la misma
forma.
Difcil captura de las similitudes.
Permitir adaptacin
La nocin correcta de mdulo debe reconciliar:
abierto - cerrado
reutilizacin - extensibilidad
Calidad del Sofware

46

Cul ser la estructura de los mdulos?


Ejemplo: Hay ocurrencia de x en t?
FUNCTION busquedaColeccin (x: elemento; t:coleccion): BOOLEAN
VAR
pos : posicin;
BEGIN
pos:= Comenzar(x,t);
WHILE not Completa(pos,t) and not Encontrado(pos,x,t) DO
pos:=Siguiente(pos, x, t);
busquedaColeccin:=not Completa(pos,t);
END;

Rutina genrica para bsqueda en una tabla


Calidad del Sofware

47

Requerimientos de los mdulos para facilitar


la reutilizacin
1. Variacin en tipos
Un mdulo reutilizable de bsqueda debera ser aplicable a muchos tipos diferentes
de elementos
x: elemento (tabla que contiene tipo Elemento)

2. Variacin en estructuras de datos y algoritmos (= variacin de


implementacin)
El tipo Coleccin puede estar implementado de diferentes formas.
Siguiente(pos,x,t) puede estar ligado a diferentes rutinas.

3. Independencia de la representacin.
Se puede usar una operacin sin conocer su implementacin
siguiente(pos,x,t), comenzar(x,t),
encontrado(pos,x,t), completa(pos,t)
Extensin de la regla de Ocultamiento de la Informacin
Importante para la extensibilidad.

48

Independencia de la representacin
Alternativa: ( Eleccin nica)
if t es de tipo A then
aplicar algoritmo de bsqueda A
elseift es de tipo B then
aplicar algoritmo de bsqueda B
elseif

Este cdigo sera incluido en:


Un nico mdulo: Grande y sujeto a constantes cambios
En cada cliente: Dificulta la extensibilidad
LIGADURA automtico
DINMICA para elegir la versin de
SOLUCIN: mecanismo
busquedaColeccion(x,t) a ejecutar.
Calidad del Sofware
49

Requerimientos de los mdulos para facilitar


la reutilizacin
4. Agrupar rutinas relacionadas
5. Capturar similitudes entre un subgrupo de un conjunto de
posibles implementaciones
Afecta a los creadores de mdulos reutilizables.
Ejemplo:
Una secuencia es un caso particular de coleccin que puede ser
implementada como un array, una lista enlazada, un fichero secuencial, ..
Evitar repeticiones de cdigo en una familia de mdulos relacionados:
Definicin incremental: Esquema General y Aadir propiedades especficas.

Calidad del Sofware

50

Ejemplo:Factorizar comportamientos comunes


Tabla

Secuencial

Lista

Conjunto

Array

Fichero
Secuencial

La operacin bsqueda se escribe una sola vez.


Calidad del Sofware

51

FUNCTION busqueda (x: elemento; t:Secuencia): BOOLEAN


BEGIN
Comenzar;
WHILE not Completa and not Encontrado(x) DO
Avanzar;
busqueda:=not Completa;
END;

ARRAY
Comenzar
Avanzar
Completa
Encontrado

i:=1
i:=i+1
i>tamao
t[i] = x

LISTA
ENLAZADA
l:=cabeza
l:=l^.next
l=nil
l^.item = x

FICHERO
SECUENCIAL
reset
read
eof
f^= x

Una nueva variante slo tiene que especificar


cmo implementar estas cuatro rutinas
Calidad del Sofware

52

Estructuras modulares tradicionales


Rutinas
Paquetes o Mdulos
Por qu no son suficientes?
Posibles soluciones para darles flexibilidad:
Sobrecarga
Genericidad
cubre los requisitos de mdulos
reutilizables?
Calidad del Sofware

53

Rutinas
Unidad de software que puede llamar a otras unidades para ejecutar
un cierto algoritmo.
Enfoque de reutilizacin: libreras de rutinas
Adecuadas en reas donde pueden ser identificado un conjunto de
problemas individuales con las siguientes limitaciones:
1. Admiten especificacin simple: pequeo conjunto de parmetros.
2. No estn implicadas estructuras de datos complejas.
3. Problemas claramente diferenciados.
Calidad del Sofware

54

Ejemplo de las limitacin de una rutina


Soluciones para: "Bsqueda en una coleccin secuencial:

1) Una rutina:
"CASE" enorme.
Muchos argumentos.

2) Conjunto de rutinas:
Rutinas muy similares ( factorizar comportamiento)
Cliente debe buscar en un laberinto de rutinas.
Conclusin: Un mdulo reutilizable debe estar abierto a la
adaptacin y, la nica forma de adaptacin de una
rutina es pasarle diferentes argumentos.
Las rutinas no son suficientemente flexibles
Calidad del Sofware
55

Paquetes/Mdulos
Son unidades de descomposicin de software que:
Cumplen el principio de Unidad Lingstica Modular
Contienen variables y rutinas relacionadas = caractersticas del paquete
Admiten la Ocultacin de la Informacin (mdulos abstractos)
Permite la implementacin de tipos definidos por el programador

Los mdulos slo resuelven rutinas relacionadas


facilita depuracin y cambio al proveedor
es ms fcil para los clientes encontrar y usar los servicios de los mdulos

Calidad del Sofware

56

Ejemplo: Paquetes/Mdulos
package TablaEnteros;
type ArbolBinEnteros
record
info: Integer
izq, der: ArbolBinEnteros
end;

PAQUETE

DECLARACIN DE TIPO

new: ArbolBinEnteros begin end;


aadir(t:ArbolBinEnteros; x: Integer) begin end;
existe(t:ArbolBinEnteros; x: Integer): Boolean begin .. end

OPERACIONES
SOBRE EL TIPO

.
end

Calidad del Sofware

57

Sobrecarga
Identificador con ms de un significado.
Ejemplo: Sobrecarga de rutinas
FUNCTION Bsqueda (x:Cuenta; t: ListaCuentas): Boolean;
FUNCTION Bsqueda (x:CHAR; t: ARRAY [CHAR]): Boolean;
FUNCTION Bsqueda (x:REAL; t: ARRAY[REAL]): Boolean;

Facilidad sintctica orientada a los clientes.


Permite escribir el mismo cdigo cliente usando
diferentes implementaciones de cierto concepto.
Calidad del Sofware

58

Qu nos proporciona la sobrecarga?


Resuelve Variacin
algoritmos?

en

estructuras

de

datos

Resuelve Independencia de la representacin?


En cada invocacin Busqueda(x,t) cliente y compilador
saben de que versin se trata.
Independencia en la representacin exige poder escribir
Busqueda(x,t) significando:
Busca x en t usando el algoritmo adecuado, cualesquiera que
sea la clase de coleccin ligada a t en tiempo de ejecucin
Calidad del Sofware

59

Genericidad
Posibilidad de definir mdulos parametrizados, cuyos
parmetros representan tipos.
Facilidad orientada a los creadores de mdulos permite
escribir el mismo cdigo cuando se usa la misma
implementacin de cierto concepto, aplicado a diferentes
tipos de objetos Ej: Array [T], Lista[T]
Los mdulos cliente deben instanciar el mdulo genrico
Ej: Array [Real], Lista[Figura],
Resuelve variacin en tipos
Calidad del Sofware

60

Ejemplo de Genericidad
Package Tabla[T];
type ArbolBinario
record
info: T
izq, der: ArbolBinario
end;
new: ArbolBinario begin end;
aadir(t:ArbolBinario; x: T) begin end;
existe(t:ArbolBinario; x: T): Boolean begin .. end

.
end

Calidad del Sofware

61

Conclusin
La genericidad resuelve:
1. Variacin en tipos.
Los paquetes/mdulos resuelven:
5. Rutinas relacionadas.
No se resuelve:
2. Variacin en estructuras de datos y algoritmos.
3. Independencia de la representacin.
4. Capturar similitudes entre un subgrupo de un
conjunto de posibles implementaciones.

Calidad del Sofware

62

4.- Diseo estructurado vs diseo OO


Qu criterio usamos para encontrar los mdulos?
Las tres fuerzas
de la
computacin

Acciones/
Funciones

Objetos/
Datos

Procesadores
A) Unidades de descomposicin funcional

Enfoque tradicional

B) Basndose en los principales tipos de datos Enfoque OO

63

A) Descomposicin Funcional
Respuesta tradicional a la cuestin de modularizacin
Responde a
(Continuidad)?

los

Bucle

modularidad

A
Secuencia

de

Calidad del Sofware

D
Condicional

Refinamientos sucesivos

Abstraccin funcional de ms alto nivel

requisitos

64

Inconvenientes de la Descomposicin
Funcional

EXTENSIBILIDAD

Funcin principal: Cima del sistema


El programa principal es una propiedad voltil
Sistemas reales no tienen cima
Mejor la visin de un conjunto de servicios

Centrado en la interfaz
Primera pregunta: Que har el sistema?
La arquitectura del software debe basarse en
propiedades ms profundas.

Ordenacin temporal prematura


Calidad del Sofware

65

REUTILIZACIN

Inconvenientes de la Descomposicin
Funcional
Se desarrollan elementos software para satisfacer
necesidades especficas de otro elemento del nivel
superior.
Cultura del proyecto actual
Las estructuras de datos son descuidadas
Funciones y datos deben jugar un papel complementario

Cuando un sistema evoluciona los datos son ms


estables que los procesos.
Calidad del Sofware

66

Ventajas de
Funcional

la

Descomposicin

Disciplina de pensamiento lgica y bien organizada


Tcnica simple, fcil de aplicar.
til para pequeos programas y algoritmos individuales.
Buena para documentar diseos (describir algoritmos).
Promueve el desarrollo ordenado de sistemas
Adecuada para dominar la complejidad
Calidad del Sofware

67

B) Descomposicin basada en objetos


EXTENSIBILIDAD:
Los objetos son ms estables que las funciones
Punto de vista de alto nivel de los objetos = Descripcin
abstracta

REUTILIZACIN:
Las rutinas no son suficientes como unidades de
reutilizacin. Ej: bsqueda en una tabla
Tipos de objetos equipados con las operaciones asociadas
proporcionan unidades estables para la reutilizacin
Calidad del Sofware

68

Desarrollo de software orientado a objetos


Definicin

Mtodo de desarrollo de software que basa la


arquitectura del sistema en mdulos deducidos de los
tipos de objetos que se manipulan (en lugar de basarse
en la funcin o funciones a las que el sistema est
destinado a asegurar).
No preguntes primero qu hace el sistema, pregunta
A QUIN LO HACE!!
Calidad del Sofware

69

Desarrollo de software OO
CMO?
1. Encontrar tipos de objetos relevantes
2. Encontrar operaciones para tipos de objetos
3. Describir tipos de objetos
4. Encontrar relaciones entre objetos
5. Usar tipos de objetos para estructurar software
Calidad del Sofware

70

Cmo se encuentran los objetos?


Los objetos estn ah para cogerlos
Reutilizacin es una fuente de tipos de objetos
Experiencia e imitacin

Cmo se describen los objetos?


Descripcin de tipos que satisfagan criterios:
Descripciones completas, precisas y no ambiguas.
Descripciones independientes de la representacin
(abstraccin)
Solucin TADs
Calidad del Sofware

71

Los objetos estn ah para cogerlos

Calidad del Sofware

72

Definicin del objeto coche


Funciones que puede realizar:
Ir
Parar
Girar a la derecha
Girar a la izquierda

Tiene las caractersticas:


Color
Velocidad
Tamao
Carburante
Calidad del Sofware
73

Objetos se comunican mediante paso


de mensajes

Calidad del Sofware

74

Los objetos con estados similares


comportamiento se agrupan en clases

Calidad del Sofware

el

mismo

75

Qu clase de relaciones se permiten?


B es un cliente de A si todo objeto de B puede contener
informacin sobre uno o mas objetos de A
B hereda de A si B denota una versin especializada de
A

Estructura del software?


Puesto que los mdulos de basarn en los tipos de
objetos, las relaciones anteriores determinan las
tcnicas de estructuracin disponibles para construir
software a partir de componentes.
Calidad del Sofware

76

Relaciones entre clases. Herencia


TRANSPORTE

Calidad del Sofware

77

Relacin de clientela

Calidad del Sofware

78

Relaciones entre mdulos: clientela/herencia


Publicacion

Revista

Libro

Autor

Actas

Congreso

Libro es una especializacin de Publicacion


Publicacion usa servicios de Autor
Calidad del Sofware

79

5.- Tipos abstractos de datos


Cmo conservar la completitud, precisin y la no
ambigedad sin pagar el precio de una especificacin
excesiva?
Solucin: considerar que las operaciones definen la
estructura de datos.
Es necesario definirlas de manera precisa!
Cmo puede utilizarlas el cliente
Qu realizarn para estos clientes
Calidad del Sofware

80

Tipos abstractos de datos


Un TAD proporciona esta informacin
Permite la especificacin abstracta de un tipo de objeto,
libre de cuestiones de implementacin.
Consta de cuatro prrafos:
TIPO: tipo (=cjto de objetos) que se est especificando.
FUNCIONES: signatura (tipo de los argumentos y resultado)
de las operaciones aplicables.
AXIOMAS: definicin implcita de las propiedades de las
funciones
PRECONDICIONES: dominio de las funciones parciales
Calidad del Sofware
81

Ejemplo: TAD Pila


TIPO Stack[T]
FUNCIONES
put: Stack[T] x T Stack[T]
remove: Stack[T] Stack[T]
item: Stack[T] T
empty: Stack[T] Boolean
new: Stack[T]
Calidad del Sofware

Funciones orden

Funciones de consulta
Funcin de creacin

82

Tipo abstracto de dato Pila


AXIOMAS
Para x: T, s: STACK[T];
item(put(s,x)) = x
remove(put(s,x)) = s
empty(new)
not empty(put(s,x))
PRECONDICIONES
item (s:Stack[T]) require not empty(s)
remove( s: STACK[T]) require not empty(s)
Calidad del Sofware

83

De los TADs a las clases


Tenemos como punto de partida una teora matemtica
para el modelado de estructuras de datos.
Los TAD proporcionan un mecanismo de descripcin
de alto nivel, libre de cuestiones de implementacin.
Una clase es una implementacin de un tipo abstracto
de dato, TAD.
Construccin de software OO consiste en crear
sistemas software como colecciones estructuradas de
implementaciones de TADs
Calidad del Sofware

84

Desarrollo de software OO
Qu necesitamos para implementar un TAD?
La especificacin de un TAD (funciones, axiomas y pre.)
Elegimos una representacin
Correspondencia de las funciones con la representacin
(rutinas y atributos)

TAD y Ocultamiento de informacin


La especificacin del TAD determina la parte pblica
La representacin de los objetos y la implementacin de las
funciones son la parte privada.

Calidad del Sofware

85

Desarrollo de un programa OO
1) Anlisis del problema MODELO de la aplicacin
1.1 Encontrar los objetos relevantes del dominio Ej: Libro,Autor, ..
1.2 Describir los objetos encontrados y clasificar
a) atributos y operaciones; relaciones clientela Ej: autor-libro
b) herencia Ej: Revista - Publicacin
1.3 Implementar las clases en un lenguaje
2) Diseo de la solucin: surgen nuevos objetos no relacionados
con el dominio
2.1 Diseo de la interfaz de usuario (VISTA)
2.2 Establecer el CONTROL: interaccin del usuario con la vista
2.3 Implementar las clases del diseo

Calidad del Sofware

86