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

1
Orientación a objetos, una técnica para mejorar
la calidad del software
Ingeniería del Software
TEMA 1
Facultad de Informatica Universidad de Murcia
2
Indice de Contenidos

• Calidad del software
• Modularidad
• Ocultamiento de información
• Principio Abierto-Cerrado
• Reutilización
• Diseño Estructurado vs. Diseño OO
• Tipos abstractos de datos

3
Paradigma de Programación

• Colección de conceptos que guían el proceso de
  construcción de un programa, determinando la
  estructura de un programa. Estos conceptos
  controlan la forma en que pensamos y formulamos
  los programas.
• Un lenguaje de programación refleja un paradigma

4
Paradigmas de Programación

• Imperativo (C, Pascal, Cobol,..)
• Funcional (Lisp, Hope, Miranda, ..)
• Lógico (Prolog, Parlog,..)
• Orientado a Objetos (Smalltalk, C, Eiffel,
  Java, ..)

5
Problemas en la creación del software

• Hay crisis del software?
• Dificultad inherente
• Gran complejidad
• Número de estados posibles es muy elevado
• Conexiones entre entidades
• Complejidad arbitraria que surge de instituciones
  humanas
• Sujeto a continuos cambios
• No tiene representación gráfica
• Especificación de requisitos
• Comunicación del equipo

6
Problemas en la creación del software

• La construcción de software siempre será una
  tarea difícil. No hay bala de plata
• (F. Brooks, 1987)
• Soluciones
• Reutilizar componentes (Comprar y no construir)
• Prototipado
• Buenos programadores/diseñadores

7
Calidad del Software

• Factores externos
• Pueden ser detectados por los usuarios
• Calidad externa es la que realmente preocupa
• Factores Internos
• Sólo los percibe el programador
• Medio de conseguir la calidad externa

8
Factores Externos

• Corrección
• Robustez
• Extensibilidad
• Reutilización
• Compatibilidad

• Eficiencia
• Portabilidad
• Facilidad de uso
• Funcionalidad

Factores Internos

• Modularidad
• Legibilidad

9
Objetivo

• La POO es un conjunto de técnicas para obtener
  calidad interna como medio para obtener calidad
  externa (Reutilización y Extensibilidad)

10
Corrección

• Es la capacidad de los productos software de
  realizar con exactitud su tarea, tal y como es
  definida en la especificación.

Robustez

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

11
Extensibilidad

• Es la facilidad de adaptación de los productos
  software a los cambios en los requisitos.
• Cambios son frecuentes.
• Dificultad proporcional al tamaño
• Principios esenciales para facilitar la
  extensibilidad
• Simplicidad de la arquitectura del software
• Descentralización módulos autónomos

12
Reutilización

• Es la capacidad de un producto software de ser
  utilizado en la construcción de diferentes
  aplicaciones.
• No reinventar soluciones para problemas ya
  resueltos.
• Se acorta el tiempo de desarrollo
• Se reducen los costes

Compatibilidad

• Es la facilidad de combinar unos elementos
  software con otros.
• Convenciones standard de comunicación
  inter-módulos

13
Eficiencia

• Es la capacidad de un sistema software de
  requerir la menor cantidad posible de recursos
  hardware.
• Factor importante para la utilización
• Algunos están obsesionados con micro-optimizacione
  s
• Debemos conjugar eficiencia con los otros
  objetivos
• Los mecanismos OO deben ser implementados de un
  modo eficiente

Portabilidad

• Es la facilidad de transferir productos software
  a diferentes plataformas

14
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.

Funcionalidad

• Conjunto de posibilidades ofrecido por un sistema
• Evitar añadir propiedades de forma incontrolada
• Buen producto software debe estar basado en un
  pequeño número de grandes ideas
• Mantener constante el nivel de calidad

15
Otros factores

• Oportunidad
• Economía
• Integridad
• Facilidad para reparaciones
• Facilidades de verificación
• Buena documentación
• Factores puedan entrar en conflicto

16
Mantenimiento del software

• Parte noble MODIFICACION
• Parte no noble DEPURACION
• Se le dedica el 70 del coste del software
• Distribución coste según Lientz79
• Cambios solicitados por los usuarios (41.8)
• Cambios en los formatos de los datos (17.4)
• Cambios de emergencia (12.4)
• Depuración rutinaria (9)
• Costes de documentación (5.5)

17
Mantenimiento del software

• Conclusiones del estudio
• Ausencia de extensibilidad
• Estructura física de los datos dispersa por
  muchas partes del sistema
• No se hace documentación a posteriori
• Cuando el sistema funciona no se buscan mejoras
  en eficiencia.

18
Módulo

• Un programa está formado por una colección de
  módulos.
• Unidad básica de descomposición de un sistema
  software.
• Medio para dominar la complejidad del software.
• Método de Desarrollo de Software Modular?
• Cinco criterios, cinco reglas, cinco principios.

19
Modularidad

• Un método de construcción de software es modular
  si favorece

Software formado por elementos autónomos
interconectados mediante una estructura simple y
coherente.
20
Modularidad
Requisitos que debe satisfacer un buen método de
diseño modular

• Permitir una composición modular
• Permitir una descomposición modular
• Producir módulos fáciles de comprender
• Favorecer la continuidad del software
• Favorecer la protección modular

21
Descomposición modular

• Se permite la descomposición de un problema en un
  pequeño número de subproblemas menos complejos,
  conectados por una estructura simple, y que se
  pueden abordar por separado.
• Importante que las dependencias sean mínimas y
  que se conozcan.
• Ejemplo Diseño Descendente
• Contra-ejemplo Módulos de Inicialización

22
Composición modular

• Se favorece la producción de elementos software
  que pueden ser combinados para crear nuevos
  sistemas, posiblemente en un entorno diferente a
  aquel en el que se idearon.
• Orientada a la reutilización.
• Independiente de la descomposición modular
• Ejemplos librerías de rutinas, filtros de Unix

23
Comprensión Modular

• Se facilita que quién lea un módulo pueda
  comprenderlo sin necesidad de acudir a otros
  módulos (en el peor de los casos a unos pocos
  módulos).
• Relacionado con el mantenimiento
• Contra-ejemplo Dependencias secuenciales

24
Continuidad Modular

• Si se favorecen arquitecturas software en las que
  un cambio pequeño en la especificación origina un
  cambio en un solo módulo, o en un pequeño número
  de módulos.
• Relacionado con la extensibilidad
• Ejemplos
• Constantes simbólicas y Principio de Acceso
  Uniforme
• Contra- ejemplos
• Diseño de programas basado en la representación
  física de los datos y el uso de arrays estáticos

25
Protección Modular

• Se satisface si se originan arquitecturas en la
  que el efecto de una condición excepcional
  acaecida en tiempo de ejecución sólo afecta al
  módulo dónde se produce, o sólo se propaga a los
  módulos vecinos.
• Relacionado con la robustez
• Ejemplo
• Módulos de entrada de datos comprueben su
  validez.
• Mecanismo de Excepciones disciplinado.

26
Modularidad
Reglas que aseguran una buena modularidad

• Correspondencia directa
• Pocas conexiones entre módulos
• Mínimo intercambio de información entre módulos

• Conexiones explícitas
• Ocultación de Información

27
Correspondencia directa

• La estructura modular ideada en el proceso de
  construcción del sistema software debería
  permanecer compatible con cualquier estructura
  modular ideada en el proceso de modelar el
  dominio del problema.
• Criterios
• Facilita el cambio (Continuidad)
• Facilita encontrar los módulos software
  (Descomposición)

28
Formas de Comunicación entre Módulos

• Relación de uso
• Un módulo puede invocar a otro (si son rutinas)
• Compartir datos
• La comunicación debe ocurrir de una forma
  controlada y disciplinada

29
En los Sistemas Software interesa ...
Acoplamiento mínimo

• Numero de conexiones sea mínimo
• Flujo de información sea mínimo
• Comunicaciones explícitas

Cohesión interna

• Cohesión de datos
• Cohesión funcional

30
Pocas Interfaces

• Cada módulo debería comunicarse con el menor
  número posible de otros módulos.
• Criterios Continuidad y Protección
• También con los otros tres criterios

31
Interfaces Pequeñas

• Si dos módulos se comunican deberían intercambiar
  la menor cantidad de información posible.
• Criterios Continuidad y Protección
• Contra-ejemplo Variables globales

32
Interfaces Explícitas

• La existencia de una comunicación entre dos
  módulos cualesquiera, A y B, debe ser obvia del
  texto de A, B o ambos.
• Criterios Composición, Descomposición
• Continuidad, Comprensión

Problema
Modulo B
Dato X
Modulo A
accede
modifica
33
Ocultación de la Información

• El diseñador de un módulo debe seleccionar un
  subconjunto de las propiedades del módulo como la
  información oficial, que estará disponible a los
  creadores de módulos clientes
• Parte Pública (Interfaz) vs. Parte Privada

CLIENTE
SERVIDOR
34
Ocultación de la información
PRIVADA
INTERFAZ
Especificación funcionalidad
Implementación
Separar función de implementación
Especificación? Implementación?
35
Ocultación de la información

• Toda la información de un módulo debería ser
  privada excepto la declarada como pública.
• Cambios que no afectan a la interfaz no afectan a
  los clientes.
• Se favorece la continuidad, también
  descomposición, composición y comprensión.
• Un módulo cliente no puede usar un módulo
  confiando en información de la parte privada.

36
Encapsulación de información
Un modulo incluye una estructura de datos junto
con un conjunto de operaciones para manipularla.
37
Modularidad
De las reglas se derivan cinco principios

• Unidades Modulares Lingüísticas
• Auto-documentación
• Acceso Uniforme
• Abierto-Cerrado
• Elección Unica

38
Unidades Modulares Lingüisticas

• Módulos deben corresponder a unidades
  sintácticas en el lenguaje usado
• Lenguaje de especificación, diseño,
  programación,..
• En el caso de lenguajes de programación, los
  módulos deben ser compilables por separado.
• Un método no puede proponer un concepto de módulo
  que no soporte el lenguaje empleado.

39
Auto-documentación

• Toda la documentación interna sobre el módulo
  debería ser parte del propio módulo
• No conviene separar el software de su
  documentación.
• Se favorece el criterio de continuidad y
  comprensión.

40
Acceso Uniforme

• Sea c una variable representando una cuenta
  bancaria y saldo una propiedad aplicable a c,
• Cómo expresamos la aplicación de saldo a c, de
  un modo independiente a la implementación de
  saldo (almacenamiento o cálculo)?
• saldo es un campo de un registro c.saldo
• saldo es una función saldo(c)

41
Acceso Uniforme

• Todos los servicios ofrecidos por un módulo
  deben ser disponibles mediante una notación
  uniforme, que no considere si se han implementado
  mediante almacenamiento o cálculo
• Se favorece la continuidad.

42
Principio Abierto-Cerrado
Los módulos deberían ser a la vez abiertos y
cerrados

• MÓDULO ABIERTO Disponible para ser extendido
• MÓDULO CERRADO Disponible para su uso

Los dos objetivos son incompatibles con las
técnicas tradicionales.
43
Principio Abierto-Cerrado
B
D
E
A
C
F
A
G
H
44
Principio abierto-cerrado

• Dos soluciones
• Adaptar el módulo A
• Origina una serie de cambios en clientes, que a
  su vez originan nuevos cambios.
• Crear una copia de A
• Control de configuraciones
• Mejor prevenir que curar
• Es posible adaptar A sin afectar a los clientes?

45
Solución Clásica

• Módulos cerrados que son abiertos para
  modificarlos
• REABRIR todos los clientes para actualizarlos

Es posible una técnica que permita escribir
módulos que sean a la vez abiertos y cerrados?
46
Elección Única
Supuesta la siguiente declaración
type Publicacion autor, titulo String año
Integer case tipoPubli (libro, revista,
articulo) libro (editorial String) revista
(editor Sring periodicidad Periodo) articul
o (revista, volumen, numero String) end end
47
Elección Unica

• Sea
• p Publicación
• entonces
• case p of
• libro
• revista
• articulo
• end

Si añadimos un nuevo tipo de publicación?
48
Elección única

• Siempre que un sistema software debe manejar
  una lista de variantes, uno y solo un módulo del
  sistema debe conocer la lista exhaustiva
• Se favorece la continuidad
• Se limita la distribución del conocimiento
• Consecuencia del Principio Abierto-Cerrado
• Una forma de Ocultación de Información

49
Reutilización del software

• Por qué el software no es como el hardware?
• Por qué cada nuevo proyecto software arranca de
  la nada?

Librerías de software Software-IC
50
Componentes, Internet y OO

• Creciente importancia de los componentes en la
  industria del software
• Frameworks, Active X, JavaBeans,
• Internet favorece la reutilización
• La tecnología OO hará realidad en un futuro
  cercano el sueño de una industria basada en
  componentes

51
Consumir elementos reutilizables
Dos posibles perspectivas Consumidor vs.
Productor

• Reduce el tiempo de desarrollo
• Mejora productividad
• Disminuye el esfuerzo del mantenimiento
• Aumenta fiabilidad
• Aumenta eficiencia

52
Producir elementos reutilizables

• Inversión de la empresa
• Crea un cátalogo de componentes reutilizables
• Preservar la experiencia
• Si un elemento software se utilizará en muchos
  proyectos es rentable invertir en mejorar su
  calidad
• Consumir antes de producir

53
Qué debemos reutilizar?

• Personal
• Diseño
• Patrones de diseño
• Código fuente
• Módulos abstractos
• Son las unidades de reuso, software
  directamente utilizable con una descripción
  abstracta de sus propiedades

54
Repetición en el desarrollo del software

• Cuántas veces en los últimos 6 meses has escrito
  código para buscar un elemento en una colección?
• Naturaleza repetitiva de la programación
  (ordenar, buscar, recorrer, ...)
• Por qué no es frecuente?
• Dificultades técnicas y no técnicas

55
Obstáculos no técnicos

• Síndrome N.I.H.
• Económicos
• Estrategias de las compañías software
• Acceso a los componentes
• Formato de distribución

56
Dificultades técnicas

• Diseñar código reutilizable es difícil.
• Hacemos las mismas cosas pero no de la misma
  forma.
• Difícil captura de las similitudes.
• Permitir adaptación

57
Ejemplo
FUNCTION buscar (x Elemento c Coleccion)
BOOLEAN VAR pos Posicion BEGIN pos
Comenzar (x,c) WHILE not Completa (pos,c) and
not Encontrado (pos, x, c) DO pos Siguiente
(pos, x, c) buscar not Completa (pos,c) END

• Rutina genérica para búsqueda en una colección

58
Requisitos de los módulos para facilitar la
reutilización
FUNCTION buscar (x Elemento c Coleccion)
BOOLEAN VAR pos Posicion BEGIN pos
Comenzar (x,c) WHILE not Completa (pos,c) and
not Encontrado (pos, x, c) DO pos Siguiente
(pos, x, c) buscar not Completa (pos,c) END

• 1. Variación en tipos
• Aplicable a diferentes tipos de elementos
• x Elemento

59
Requerimientos de los módulos para facilitar la
reutilización
FUNCTION buscar (x Elemento c Coleccion)
BOOLEAN VAR pos Posicion BEGIN pos
Comenzar (x,c) WHILE not Completa (pos,c) and
not Encontrado (pos, x, c) DO pos Siguiente
(pos, x, c) buscar not Completa (pos,c) END
2. Variación en estructuras de datos y
algoritmos El tipo Coleccion puede estar
implementado de diferentes formas y
Siguiente(pos,x,c) puede estar ligado a
diferentes rutinas FAMILIAS DE MODULOS
relacionados
60
Requerimientos de los módulos para facilitar la
reutilización
FUNCTION buscar (x Elemento c Coleccion)
BOOLEAN VAR pos Posicion BEGIN pos
Comenzar (x,c) WHILE not Completa (pos,c) and
not Encontrado (pos, x, c) DO pos Siguiente
(pos, x, c) buscar not Completa (pos,c) END
3. Independencia de la representación Se puede
usar una operación sin conocer su
implementación siguiente(pos,x,c),
comenzar(x,c), encontrado(pos,c),
completa(pos,c)
61
Independencia de la representación

• existe Boolean op Opcion i Integer c
  Coleccion
• obtenerColeccion (op, c)
• existe buscar (i, c)
• Se usa una operación sin conocer la
  implementación exacta.
• Importante para la extensibilidad
• Necesidad de un mecanismo automático para elegir
  la versión de buscar(x,c) a ejecutar.

62
Independencia de la representación

• Alternativa
• if c es de tipo A then
• aplicar algoritmo de búsqueda A
• elseif c es de tipo B then
• aplicar algoritmo de búsqueda B
• elseif
• Este código sería incluido en
• Un único módulo Grande y sujeto a constantes
  cambios
• Código cliente Dificulta la extensibilidad

63
Requerimientos de los módulos para facilitar la
reutilización.
FUNCTION buscar (x Elemento c Coleccion)
BOOLEAN VAR pos Posicion BEGIN pos
Comenzar (x,c) WHILE not Completa (pos,c) and
not Encontrado (pos, x, c) DO pos Siguiente
(pos, x, c) buscar not Completa (pos,c) END
4. Factorizar comportamientos comunes dentro de
una familia de implementaciones 5. Rutinas
relacionadas
64
Factorizar comportamientos comunes

• Afecta a los creadores de módulos reutilizables.
• Ejemplo
• Una secuencia es un caso particular de
  colección que puede ser implementada como un
  array, una lista enlazada, un fichero secuencial,
  ..
• Evitar repeticiones de código en una familia de
  módulos relacionados
• Cómo capturamos similitudes?
• Definición incremental Esquema General y Añadir
  propiedades específicas.

65
Factorizar comportamientos comunes
Coleccion
Conjunto
Secuencia
Lista
Array
Fichero Secuencial

• La operación buscar se escribe una sola vez.

66
FUNCTION buscar (x Elemento c Coleccion)
BOOLEAN BEGIN pos Comenzar WHILE not
Completa and not Encontrado (x) DO pos
Siguiente buscar not Completa END
67
RUTINAS, MODULOS, SOBRECARGA Y GENERICIDAD COMO
MECANISMOS DE REUTILIZACION?
68
Rutinas
Abstracción por especificación y por
parametrización

• Adecuadas en áreas donde pueden ser identificado
  un conjunto de problemas individuales con las
  siguientes limitaciones
• 1. Admiten especificación simple pequeño
  conjunto de parámetros.
• 2. No estén implicadas estructuras de datos
  complejas.
• 3. Problemas claramente diferenciados.

69
Rutinas

• INADECUADO para el problema de "Búsqueda en una
  colección secuencial. Dos posibles soluciones
• 1) Una rutina
• "CASE" enorme.
• Muchos argumentos.
• No extensible.
• 2) Conjunto de rutinas
• Rutinas muy similares.
• Cliente debe buscar en un laberinto de rutinas.

70
Paquetes/Módulos (Ada, Modula, CLU,..)

• Permiten
• 1. Agrupar elementos software relacionados.
• 2. Ocultación de la información.
• 3. Definición de tipos definidos por el
  programador.
• 4. Abstracción de datos Especificación y
  Parametrización.
• Es fácil para los programadores cliente buscar y
  usar los servicios disponibles por un módulo.
• Los módulos sólo resuelven rutinas relacionadas

71
Paquetes/Módulos

• package TablaEnteros
• type ArbolBinEnteros
• record
• info Integer
• izq, der ArbolBinEnteros
• end
• new ArbolBinEnteros begin end
• añadir(tArbolBinEnteros x Integer) begin
  end
• existe(tArbolBinEnteros x Integer)
  Boolean begin .. end
• .
• end

72
Ejemplo 1

• Módulo que encapsula una variable que representa
  un directorio mediante un árbol de búsqueda
  binaria y el conjunto de operaciones para
  manipular la variable.

Ejemplo 2
Módulo anterior como paquete genérico
Ejemplo 3
Definición de un tipo de dato directorio
Ejemplo 4
Definición de un tipo de dato pila
73
Ejemplo 1
Declaración PACKAGE directorio IS PROCEDURE
insertar (nombre IN Nombres numero IN
Number) PROCEDURE buscar (nombre IN
Nombres numero OUT Numberexiste Boolean) END
Directorio. Implementación

• PACKAGE BODY directorio IS
• TYPE ElemDir
• TYPE DirPtr IS ACCESS ElemDir
• TYPE ElemDir IS RECORD
• nombreElem Nombre
• numeroElem Number
• iz, dr DirPtr
• END RECORD
• raiz DirPtr Arbol Binario de Búsqueda
• PROCEDURE insertar (nombre IN Nombres numero
  IN Number)
• BEGIN ... END
• PROCEDURE buscar (nombre IN Nombres numero IN
  Number existe Boolean)
• BEGIN .. END
• END Directorio.

74

• Uso del paquete del Ejemplo 1
• USE Directorio
• directorio. insertar(Irene, 171093)
• directorio. Insertar(Elena, 281295)

Ejemplo 2
GENERIC PACKAGE Directorio IS Resto igual que
en Ejemplo 1 END PACKAGE BODY Directorio IS
Resto igual que en Ejemplo 1 END Directorio
USE Directorio PACKAGE dirOcio IS NEW
Directorio PACKAGE dirTrabajo IS NEW
Directorio dirTrabajo.insertar(I.
Verdu, 101010) dirOcio. buscar(I. Sastre,
tlfno, ok)
75
Ejemplo 3
Declaración PACKAGE tipoDirectorio IS TYPE
Directorio IS LIMITED PRIVATE PROCEDURE
insertar (dir IN OUT Directorio nombre IN
Nombres numero IN Number) PROCEDURE buscar
(dir IN OUT Directorio nombre IN Nombres
numero OUT Number existe Boolean)
PRIVATE TYPE ElemDir TYPE
Directorio IS ACCESS ElemDir TYPE
ElemDir IS RECORD nombreElem Nombre
numeroElem Number iz, dr, Directorio
END RECORD END tipoDirectorio. Implement
ación

• PACKAGE BODY tipoDirectorio IS
• PROCEDURE insertar (dir IN OUT Directorio
  nombre IN Nombres numero IN Number)
• BEGIN ... END
• PROCEDURE buscar (dir IN OUT Directorio
  nombre IN Nombres numero IN Number
  existe Boolean)
• BEGIN .. END
• END tipoDirectorio.

76

• Uso del paquete del Ejemplo 3
• USE tipoDirectorio
• dirTrabajo, dirOcio Directorio
• insertar(dirTrabajo, Irene, 171093)
• buscar(dirOcio, I. Sastre, tlfno, ok)

Ejemplo 4
PACKAGE TipoPila IS TYPE PilaCar IS LIMITED
PRIVATE PROCEDURE push (x IN Character st IN
OUT PilaCar) PROCEDURE pop (x OUT Character
st IN OUT PilaCar) FUNCTION top (st IN OUT
PilaCar) RETURN Character PRIVATE TYPE
PilaCarImp -- Definido en la parte de
implementación TYPE PilaCar IS ACCESS
PilaCarImp END Pila.
77
Sobrecarga

• Identificador con más de un significado.
• Ejemplo Sobrecarga de rutinas
• FUNCTION buscar (eCuenta c ListaCuentas)
  Boolean
• FUNCTION buscar (eCHAR c ARRAY CHAR)
  Boolean
• FUNCTION buscar (eREAL c ARRAYREAL)
  Boolean
• Facilidad sintáctica orientada a los clientes.
• Permite escribir el mismo código cliente al usar
  diferentes implementaciones de cierto concepto.

78
Sobrecarga

• Resuelve Variación en estructuras de datos y
  algoritmos?
• Resuelve Independencia de la representación?
• En cada invocación buscar(x,c) cliente y
  compilador saben de que versión se trata.
• Independencia en la representación exige poder
  escribir buscar(x,c) significando
• Busca x en c usando el algoritmo adecuado,
  cualesquiera que sea la clase de colección ligada
  a c en tiempo de ejecución

79
Genericidad

• Posibilidad de definir módulos parametrizados,
  cuyos parámetros representan tipos.
• Facilidad orientada a los creadores de módulos
• Array G, ListaG, ArbolBinarioG
• Los módulos cliente deben instanciar el módulo
  genérico
• Array Real, ListaFigura, ArbolBinarioPalabr
  a
• Resuelve variación en tipos

80
Genericidad

• Facilidad para los proveedores de módulos.
  Permite escribir el mismo código cuando se usa
  la misma implementación de cierto concepto,
  aplicado a diferentes tipos de objetos
• Ejemplo típico Definir estructuras de datos para
  cualquier posible tipo base.

81
Genericidad

• package TablaG
• type ArbolBinario
• record
• info G
• izq, der ArbolBinario
• end
• new ArbolBinario begin end
• añadir(tArbolBinario x G) begin end
• existe(tArbolBinario x G) Boolean begin
  .. end
• .
• end

82
Conclusión

• La genericidad resuelve
• 1. Variación en tipos.
• Los paquetes/módulos resuelven
• 5. Rutinas relacionadas.
• No se resuelve
• 2. Variación en estructuras de datos y
  algoritmos.
• 3. Independencia de la representación.
• 4. Capturar similitudes entre un subgrupo de un
  conjunto de posibles implementaciones.

83
Arquitecturas modulares

• Qué criterio usamos para encontrar los módulos?

Acciones/ Funciones
Objetos/ Datos
Procesadores
84
Arquitecturas modulares

• Dos principales criterios a considerar
• Extensibilidad (Continuidad)
• Reutilización
• Cómo la estructura del software soportará los
  cambios?
• Funciones y datos deben tenerse en cuenta.

85
Descomposición Funcional
Secuencia
Condicional
Bucle
86
Inconvenientes de la Descomposición Funcional

• Función principal Cima del sistema
• El programa principal es una propiedad volátil
• Sistemas reales no tienen cima
• Mejor la visión de un conjunto de servicios
• Centrado en la interfaz
• Primera pregunta Que hará el sistema?
• La arquitectura del software debe basarse en
  propiedades más profundas.
• Ordenación temporal prematura

87
Inconvenientes de la Descomposición Funcional

• No favorece la reutilización
• Se desarrollan elementos software para satisfacer
  necesidades específicas 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 más
  estables que los procesos.

88
Ventajas de la Descomposición Funcional

• Técnica simple, fácil de aplicar
• Util para pequeños programas y describir
  algoritmos.
• Buena para documentar diseños.
• Facilita desarrollo sistemático de sistemas
• Adecuada para dominar la complejidad

89
Descomposición basada en objetos

• Los objetos son más estables que las funciones
  cuando el sistema evoluciona (Extensibilidad).
• Tipos de objetos equipados con las operaciones
  asociadas (Reutilización).
• El diseñador lista las operaciones aplicables a
  cierto tipo de objetos, especificando su efecto.
• Se retrasa todo lo posible el orden en que se
  ejecutan las operaciones.

90
Desarrollo de software orientado a objetos

• Método de desarrollo de software basado en
  arquitecturas cuyos módulos son deducidos de los
  tipos de objetos que se manipulan
• No preguntes primero qué hace el sistema,
  pregunta
• A QUÉ SE LO HACE?

91
Desarrollo software OO

• 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

92
Descripción de los objetos

• Describimos tipos de objetos.
• Las descripciones deberían ser completas,
  precisas y no ambiguas, y no deberían basarse en
  la representación física.
• Necesidad de una especificación abstracta.
• Utilizar operaciones.
• Especificaciones algebraicas son adecuadas.

93
Tipos abstractos de datos

• Permiten la especificación abstracta de un tipo
  de objetos
• Funciones
• Axiomas
• Precondiciones
• Independiente de la implementación
• Descripciones precisas y no ambiguas

94
Tipo abstracto de dato Pila

• TIPO StackT
• FUNCIONES
• put StackT x T ? StackT
• remove StackT ? T
• item StackT ?T
• empty StackT ? Boolean
• new StackT

95
Tipo abstracto de dato Pila

• AXIOMAS
• Para x T, s STACKT
• item(put(s,x)) x
• remove(put(s,x)) s
• empty(new)
• not empty(put(s,x))
• PRECONDICIONES
• item (sStackT) require not empty(s)
• remove( s STACKT) require not empty(s)

96
Desarrollo de software OO

• Una clase es una implementación de un tipo
  abstracto de dato, TAD.
• Construcción de software OO consiste en crear
  sistemas software como colecciones estructuradas
  de implementaciones de TAD

97
Clases

• Abstracción de datos.
• Nuevo tipo definido por el programador
• clase tipo
• Herencia entre clases

98
Desarrollo de software OO

• Las clases son diseñadas como entidades de
  interés y utilidad por sí mismas,
  independientemente de los sistemas a los que
  pertenecen.
• Dos tipos de relaciones entre clases
• Cliente
• Herencia

99
Cuenta
Cliente
C_Ahorro
C_Vivienda
C_Corriente
Seguro
C_Corriente es una especialización de Cuenta
Cuenta usa servicios de Cliente
100
Desarrollo de software OO

• Cómo pasamos de la especificación de un TAD a
  una clase?
• Elegimos una representación.
• A cada función del tad le asignamos una rutina de
  la clase, basándonos en la representación.
• Ocultación de información
• El tad determina la parte pública.
• La representación de los objetos y la
  implementación de las funciones son la parte
  privada.

101
TAD y Clase
Teoría TAD Operaciones Sintaxis y
Semántica
Software Clase Elegir representación e
implementar operaciones
102
TAD y Clase
Teoría TAD Funciones Axiomas Precondi
ciones
Software Clase Métodos Asertos
103
Clase Pila

• class PilaG
• feature
• elem ARRAYG
• feature
• count INTEGER
• capacity INTEGER
• empty BOOLEAN is do .. end
• full BOOLEAN is do .. end
• put (xG) is do .. end
• remove is do .. end
• item G is do .. end
• end.

104
Ejemplo Clase en Eiffel