Download Modularidad - WordPress.com

Document related concepts

Scala (lenguaje de programación) wikipedia , lookup

Polimorfismo (informática) wikipedia , lookup

Dylan (lenguaje de programación) wikipedia , lookup

Axiom wikipedia , lookup

Programación funcional wikipedia , lookup

Transcript
TEMA 2
Modularidad:
Tipos abstractos de datos
Programación Orientada a Objetos
Tema 2: Modularidad
1
CONTENIDOS
1.
2.
3.
4.
5.
6.
7.
Abstracción
Tipos de datos
Tipos abstractos de datos
Modularidad
Reutilización
Paradigmas y lenguajes
Diseño estructurado vs. OO
Programación Orientada a Objetos
Tema 2: Modularidad
2
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
3
4
Abstracción
Abedul
Olmo
Castaño
Pino
Chopo
Abeto
Haya
Arbol
- altura
- tipo de madera
- tipo de hoja
- tipo de fruto
Programación Orientada a Objetos
Tema 2: Modularidad
Persona
DNI
Nombre
Edad
calcularEdad()
Abstracción
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.
Programación Orientada a Objetos
Tema 2: Modularidad
5
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
6
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
7
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
8
Tipos Abstractos de Datos
• 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
Programación Orientada a Objetos
Tema 2: Modularidad
9
Tipos Abstractos de Datos
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)
Programación Orientada a Objetos
Tema 2: Modularidad
10
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
11
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
12
Modularidad


Un módulo se estructura mediante una interfaz y una
implementación.
Esta compuesto por un conjunto de operaciones y
atributos.
Interfaz
Sección
Privada
Primitivas de
acceso
Atributos
Operaciones
Programación Orientada a Objetos
Tema 2: Modularidad
13
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
14
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
15
16
Modularidad
EJEMPLO: Módulo que define
“cuentas bancarias”
Un modulo incluye una
estructura de datos junto con
un conjunto de operaciones
para manipularla.
Representación
NombreCli:String
Codigo:String
Saldo:Entero
Interfaz
reintegro()
ingreso()
verSaldo()
Operaciones
reintegro()
ingreso()
verSaldo()
calculaIntereses()
NO
Programación Orientada a Objetos
Tema 2: Modularidad
SI
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
17
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
18
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
19
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
20
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
LENGUAJE
ELEMENTOS
Imperativo
COBOL, Pascal, C
Algoritmos
Funcional
Lisp, Miranda, Haskel
Funciones-Reglas If-Then
Lógico
Prolog
Predicados-Reglas If-Then
Orientado a Objetos
Smalltalk, Eiffel, C++, Java
Clases y Objetos
Programación Orientada a Objetos
Tema 2: Modularidad
21
Paradigmas - Lenguajes
• 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
Programación Orientada a Objetos
Tema 2: Modularidad
22
Diseño estructurado vs. OO

¿Qué criterio usamos para encontrar los módulos?
Acciones/
Funciones
Objetos/
Datos
Las tres fuerzas
de la
computación
Procesadores
A) Unidades de descomposición funcional
 Enfoque tradicional
B) Basándose en los principales tipos de datos  Enfoque OO
Programación Orientada a Objetos
Tema 2: Modularidad
23
24
Diseño estructurado vs. OO
• Descomposición funcional:
• Respuesta tradicional a la cuestión de modularización
•¿Responde a los requisitos de modularidad?
B
A
C
Secuencia
Bucle
E
F
G
D
Condicional
Programación Orientada a Objetos
Tema 2: Modularidad
H
Refinamientos sucesivos
Abstracción funcional de más alto nivel
Diseño estructurado vs. OO
EXTENSIBILIDAD




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
Programación Orientada a Objetos
Tema 2: Modularidad
25
Diseño estructurado vs. OO
REUTILIZACIÓN





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.
Programación Orientada a Objetos
Tema 2: Modularidad
26
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
27
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.
operaciones
datos
Programación Orientada a Objetos
Tema 2: Modularidad
28
Diseño estructurado vs. OO
En la programación OO agrupamos (encapsulamos)
conjuntos de datos relacionados entre sí y operaciones
sobre esos datos en entidades que llamamos objetos.
Ciertas operaciones son accesibles desde
el exterior y constituyen servicios que
el objeto ofrece a otros objetos
Objeto
Algunas operaciones están
también ocultas, y representan
servicios de utilidad dentro del
propio objeto
Programación Orientada a Objetos
Tema 2: Modularidad
Los datos normalmente están
ocultos y únicamente son
accesibles dentro del propio
objeto
29
Diseño estructurado vs. OO
•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.
Programación Orientada a Objetos
Tema 2: Modularidad
30
Diseño estructurado vs. OO
Las abstracciones funcionales son más volátiles que las de datos.
Esa es una de las ventajas de la OO.
Programación Orientada a Objetos
Tema 2: Modularidad
31
Orientación a Objetos
• 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.
Programación Orientada a Objetos
Tema 2: Modularidad
32