Modularidad: Tipos abstractos de datos · Programación Orientada a Objetos Tema 2: Modularidad CONTENIDOS 2 1. Abstracción 2. Tipos de datos 3. Tipos abstractos de datos 4. Modularidad
Post on 10-Apr-2018
237 Views
Preview:
Transcript
Programación Orientada a Objetos
Tema 2: Modularidad
1
Modularidad:
Tipos abstractos de datos
TEMA 2
Programación Orientada a Objetos
Tema 2: Modularidad
2
CONTENIDOS
1. Abstracción
2. Tipos de datos
3. Tipos abstractos de datos
4. Modularidad
5. Reutilización
6. Paradigmas y lenguajes
7. Diseño estructurado vs. OO
Programación Orientada a Objetos
Tema 2: Modularidad
3
Abstracción
Supresión intencionada, u ocultamiento, de algunos detalles de un proceso o artefacto, con el objeto de destacar de manera más clara otros aspectos, detalles o estructuras.
Capacidad de centrarse en las características esenciales de las distintas partes de un sistema, ignorando sus propiedades accidentales.
Permite dividir la información en componentes aislados que posteriormente se ensamblan para construir el “todo”.
Limitación de la capacidad humana para operar la complejidad:
– Ordenando el caos: ”divide et impera”.
– En SW: Abstracción → Modularidad
Programación Orientada a Objetos
Tema 2: Modularidad
4
Abstracción
Arbol
- altura
- tipo de madera
- tipo de hoja
- tipo de fruto
Castaño
Olmo
Abeto
Chopo
Abedul
Haya
Pino
Persona
DNI
Nombre
Edad
calcularEdad()
Programación Orientada a Objetos
Tema 2: Modularidad
5
Abstracción aplicada:
Diferentes niveles: Nos centramos en los elementos más
grandes e importantes.
Progresivamente: Tratamos volúmenes de información
menores que revelen más detalles.
Diferentes tipos: Funcional o procedural,
de Datos.
Abstracción
Programación Orientada a Objetos
Tema 2: Modularidad
6
Abstracción
Encapsulación:
“Proceso de almacenar en un mismo
compartimento los elementos de una
abstracción que constituyen su estructura y su
comportamiento” [Booch’96]
Programación Orientada a Objetos
Tema 2: Modularidad
7
Tipos de Datos
Un tipo de dato es un conjunto de valores y un
conjunto de operaciones definidas por sus
valores.
Tipo de dato = Representación + Operaciones.
Ejemplos:
– Tipo de datos entero, operaciones de +,-,*,/.
– Tipo cadena, operaciones de concatenación,
subcadena, etc.
Programación Orientada a Objetos
Tema 2: Modularidad
8
Tipos Abstractos de Datos
Los TADs permiten ampliar los tipos de datos definidos por el lenguaje de programación.
Un tipo de dato definido por el programador se denomina TAD.
Un TAD es un tipo de datos que consta de datos y operaciones que se pueden realizar sobre esos datos.
Los TADs ocultan la implementación de las operaciones definidas por el usuario asociadas con el tipo de datos.
La ocultación de información de un TAD significa que poseen interfaces públicos (operaciones que se pueden realizar), sin embargo, las implementaciones de esos interfaces son privados.
Programación Orientada a Objetos
Tema 2: Modularidad
9
• Un TAD consta de :
TIPO: tipo (=cjto de objetos) que se está especificando
FUNCIONES: signatura (tipo de los argumentos y resultado)
AXIOMAS: definición implícita del valor de la función
INVARIANTES: condición booleana que debe mantenerse con exactitud
PRECONDICIONES
POSTCONDICIONES
Tipos Abstractos de Datos
Programación Orientada a Objetos
Tema 2: Modularidad
10
Ejemplo TAD “Pila”
TIPO Pila[X]
FUNCIONES
poner: Pila[X] x X Pila[X]
vacia: Pila[X] Boolean
item: Pila[X] X
new: Pila[X]
AXIOMAS
Para x: T, s: Pila[T];
item(poner(s,x)) = x
vacia(new)
not vacia(poner(s,x))
PRECONDICIONES
item (s:Pila[T]) requiere not vacia(s)
Tipos Abstractos de Datos
Programación Orientada a Objetos
Tema 2: Modularidad
11
Modularidad
“Propiedad que tiene un sistema que ha sido descompuesto en un conjunto de módulos cohesivos y débilmente acoplados” [Booch’96]
Alta cohesión:
– Un módulo con responsabilidades altamente relacionadas y que no hace una gran cantidad de trabajo.
Bajo acoplamiento: – Un módulo que no depende de demasiados otros módulos.
– Favorece: Comprensión modular: Es posible entender un módulo sin conocer los otros.
Continuidad modular: Un cambio en la especificación afecta sólo a un módulo o a unos pocos.
Protección modular: El efecto de una situación anormal producida en un módulo afecta sólo a éste o a unos pocos.
– Los módulos se comunican mediante interfaces bien definidas.
Programación Orientada a Objetos
Tema 2: Modularidad
12
Modularidad
Programa modular: formado por un conjunto de módulos.
Módulo: unidad básica de descomposición de un sistema software. Los módulos deben ser lo más independientes posibles.
Un método de construcción de software es modular si ayuda a producir sistemas software a partir de elementos autónomos interconectados por una estructura simple y coherente.
La programación modular trata de descomponer un programa en un pequeño número de abstracciones coherentes que pertenecen al dominio del problema y cuya complejidad interna esta oculta por el interfaz.
Programación Orientada a Objetos
Tema 2: Modularidad
13
Modularidad
Un módulo se estructura mediante una interfaz y una
implementación.
Esta compuesto por un conjunto de operaciones y
atributos.
Primitivas de
acceso
Atributos Operaciones Sección
Privada
Interfaz
Programación Orientada a Objetos
Tema 2: Modularidad
14
Modularidad
Reglas para obtener módulos:
Unidades modulares:
– El lenguaje debe proporcionar estructuras modulares con las cuales se puedan describir las diferentes unidades.
– POO – Clases.
Ocultación de información:
– Todos los módulos deben seguir el principio de ocultación de información.
– Una abstracción de datos puede verse como que tiene dos caras:
Interfaz: operaciones que definen el comportamiento (cliente)
Implementación (programador)
Programación Orientada a Objetos
Tema 2: Modularidad
15
Modularidad
Principio abierto-cerrado: Un módulo se considera a
la vez cerrado (terminado, útil o activo) y abierto
(cambios y modificaciones). No debe afectar a los
demás módulos.
– Un módulo está abierto si está disponible para ampliarlo.
– Un módulo está cerrado si está disponible para su uso.
– Los dos objetivos son incompatibles con las técnicas
tradicionales:
o está abierto → no se puede utilizar todavía.
o se cierra → cualquier cambio provoca cambios en cadena.
Programación Orientada a Objetos
Tema 2: Modularidad
16
Representación
NombreCli:String
Codigo:String
Saldo:Entero
Operaciones
reintegro()
ingreso()
verSaldo()
calculaIntereses()
Interfaz
reintegro()
ingreso()
verSaldo()
NO SI
EJEMPLO: Módulo que define
“cuentas bancarias”
Un modulo incluye una
estructura de datos junto con
un conjunto de operaciones
para manipularla.
Modularidad
Programación Orientada a Objetos
Tema 2: Modularidad
17
Reutilización
¿Por qué el software no es como el hardware
(catálogos 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: (COM, 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”.
Programación Orientada a Objetos
Tema 2: Modularidad
18
Reutilización
Beneficios esperados de la reutilización:
CONSUMIR elementos reutilizables:
– Oportunidad (se reduce el tiempo de desarrollo).
=> Mejora la productividad.
– Disminuye el esfuerzo del mantenimiento.
– Aumenta fiabilidad.
– Aumenta eficiencia.
PRODUCIR elementos reutilizables:
– Inversión: 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”
Programación Orientada a Objetos
Tema 2: Modularidad
19
Reutilización
¿Qué debemos reutilizar?
PERSONAL:
– La experiencia previa ayuda en el nuevo desarrollo.
DISEÑO:
– Difícil garantizar compatibilidad diseño-implementación.
– Seguir un enfoque donde la diferencia entre módulo diseño y módulo de implementación desaparece.
– Necesidad de generalidad en los componentes.
PATRONES DE DISEÑO:
– Ideas aplicables a toda una gama de dominios.
– Un patrón propone una solución para un problema de diseño.
Programación Orientada a Objetos
Tema 2: Modularidad
20
Reutilización
¿Por qué no es común la reutilización? – Naturaleza repetitiva de la programación (ordenar, buscar, recorrer, ...)
– ¿Cuántas veces en los últimos 6 meses has escrito código para buscar un elemento en una colección?
Obstáculos: – Síndrome N.I.H. (Not Invented Here): Reacción cautelosa frente a componentes
nuevos. Coste adicional de aprendizaje.
– Económicos: Se centran en los costes a corto plazo.
– Estrategias de las compañías software: “¿Y si el cliente no vuelve a necesitarnos?”.
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.
– La noción correcta de módulo debe reconciliar: abierto - cerrado
reutilización - extensibilidad
Programación Orientada a Objetos
Tema 2: Modularidad
21
Paradigmas - Lenguajes • A lo largo del tiempo se han utilizado diferentes maneras de construir sistemas
(paradigmas) persiguiendo parecidos objetivos.
• Paradigma de Construcción de un Sistema:
Colección de conceptos que guían el proceso de construcción de un sistema,
determinando su estructura. Estos conceptos controlan la forma en que pensamos y
formulamos los sistemas.
• Un lenguaje de programación refleja un paradigma:
PARADIGMA
Imperativo
Funcional
Lógico
Orientado a Objetos
LENGUAJE
COBOL, Pascal, C
Lisp, Miranda, Haskel
Prolog
Smalltalk, Eiffel, C++, Java
ELEMENTOS
Algoritmos
Funciones-Reglas If-Then
Predicados-Reglas If-Then
Clases y Objetos
Programación Orientada a Objetos
Tema 2: Modularidad
22
• La abstracción es la clave para diseñar buen software.
• Los lenguajes de programación de alto nivel permiten al
programador abstraerse de la arquitectura de la máquina
donde se ejecuta el software (de propósito general).
• Mecanismos para diseñar programas modulares:
• Procedimientos o funciones
• Módulos
• Tipos abstractos de datos (TADS)
• Objetos
Paradigmas - Lenguajes
Programación Orientada a Objetos
Tema 2: Modularidad
23
Diseño estructurado vs. OO
¿Qué criterio usamos para encontrar los módulos?
Objetos/
Datos
Acciones/
Funciones
Procesadores
A) Unidades de descomposición funcional Enfoque tradicional
B) Basándose en los principales tipos de datos Enfoque OO
Las tres fuerzas de la computación
Programación Orientada a Objetos
Tema 2: Modularidad
24
Diseño estructurado vs. OO
A
B C D
E H G F
Secuencia
Bucle Condicional
Abstracción funcional de más alto nivel
Refin
am
iento
s sucesivo
s
• Descomposición funcional:
• Respuesta tradicional a la cuestión de modularización
•¿Responde a los requisitos de modularidad?
Programación Orientada a Objetos
Tema 2: Modularidad
25
Diseño estructurado vs. OO
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
EX
TE
NS
IBIL
IDA
D
Programación Orientada a Objetos
Tema 2: Modularidad
26
Diseño estructurado vs. OO
Inconvenientes de la descomposición funcional:
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.
RE
UT
ILIZ
AC
IÓN
Programación Orientada a Objetos
Tema 2: Modularidad
27
Diseño estructurado vs. OO
Ventajas de la descomposición funcional:
Disciplina de pensamiento lógica y bien organizada.
Técnica simple, fácil de aplicar.
Útil para pequeños programas y algoritmos individuales.
Buena para documentar diseños (describir algoritmos).
Promueve el desarrollo ordenado de sistemas
Adecuada para dominar la complejidad
Programación Orientada a Objetos
Tema 2: Modularidad
28
Diseño estructurado vs. OO
En la programación tradicional tenemos por un lado
los datos y por otro las operaciones sobre esos datos,
pero son entidades independientes.
datos operaciones
Programación Orientada a Objetos
Tema 2: Modularidad
29
En la programación OO agrupamos (encapsulamos)
conjuntos de datos relacionados entre sí y operaciones
sobre esos datos en entidades que llamamos objetos.
Objeto
Los datos normalmente están
ocultos y únicamente son
accesibles dentro del propio
objeto
Algunas operaciones están
también ocultas, y representan
servicios de utilidad dentro del
propio objeto
Ciertas operaciones son accesibles desde
el exterior y constituyen servicios que
el objeto ofrece a otros objetos
Diseño estructurado vs. OO
Programación Orientada a Objetos
Tema 2: Modularidad
30
•Con la orientación a objetos, construimos pequeños
modelos software de la realidad y simulamos ésta.
•Un sistema O.O. es un conjunto de objetos que
interactúan entre sí enviándose mensajes mediante
los cuáles se solicitan servicios unos a otros.
Diseño estructurado vs. OO
Programación Orientada a Objetos
Tema 2: Modularidad
31
Las abstracciones funcionales son más volátiles que las de datos.
Esa es una de las ventajas de la OO.
Diseño estructurado vs. OO
Programación Orientada a Objetos
Tema 2: Modularidad
32
• Desarrollo de software orientado a objetos :
Definición
Método de desarrollo de software que basa la arquitectura del
sistema en módulos deducidos de los tipos de objetos que se
manipulan (en lugar de basarse en la función o funciones a las que
el sistema está destinado a asegurar).
Hay que centrar la atención no sobre lo que HACE el sistema,
sino principalmente sobre lo que ES el sistema, en términos de
datos, de componentes, en término de manejo de entidades, de
reacción a las solicitudes.
Orientación a Objetos
top related