PDF de programación - Tema 1: Orientación a Objetos, una técnica para mejorar la calidad del software

TEMA 1: Orientación a Objetos, una técnica
para mejorar la calidad del software

Programación Orientada a Objetos

Curso 2009/2010

Índice

Calidad del software
Modularidad
Reutilización
Criterios para encontrar los módulos:

Orientación a Objetos

Lenguajes de Programación OO
Modelo de objetos

Curso 2009/2010

Calidad del Sofware y OO

2

Problemas en la creación de software

A finales de los 60 se acuñó el término crisis del

software:
Los proyectos no cumplían los plazos y presupuestos.

Dificultades inherentes a la naturaleza del software:

Complejidad

Dificultad de enumerar todos los estados posibles del

programa

Dominios de aplicación complejos
Dificultad de comunicación entre los miembros del equipo

Sujeto a continuos cambios

Curso 2009/2010

Calidad del Sofware y OO

3

Problemas en la creación de software

“La construcción de software siempre será una

tarea difícil. No hay bala de plata”
[Brooks,1987]

Soluciones:

Reutilizar código de calidad
Buenos programadores/diseñadores

Curso 2009/2010

Calidad del Sofware y OO

4

Calidad del software

Factores externos:

Pueden ser detectados por los usuarios
Calidad externa es la que realmente preocupa

Factores internos:

Sólo lo perciben los diseñadores e implementadores
Medio para conseguir la calidad externa

Objetivo:

Buenas propiedades

internas

Satisfacer factores

externas

Curso 2009/2010

Calidad del Sofware y OO

5

Calidad del software
Factores Externos

- Corrección
- Eficiencia
- Robustez
- Portabilidad
- Extensibilidad
- Facilidad de uso
- Reutilización
- Funcionalidad
- Compatibilidad - Oportunidad

Factores Internos

- Modularidad
- Legibilidad

Curso 2009/2010

Calidad del Sofware y OO

6

Factores de calidad externos

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

Curso 2009/2010

Calidad del Sofware y OO

7

Factores de calidad externos

Extensibilidad:

Es la facilidad de adaptación de los productos

software a los cambios en la especificación.

La dificultad de adaptación es proporcional al

tamaño del sistema.

Principios esenciales para facilitar la

extensibilidad
Simplicidad de la arquitectura del software
Descentralización: módulos autónomos

Curso 2009/2010

Calidad del Sofware y OO

8

Factores de calidad externos

Reutilización:

Es la capacidad de un producto software de ser

utilizado en la construcción de diferentes
aplicaciones

Se escribe menos software, luego se puede dedicar

mas tiempo a mejorar otros factores como la
fiabilidad (corrección y robustez)

Compatibilidad:

Es la facilidad de combinar unos elementos

software con otros

Curso 2009/2010

Calidad del Sofware y OO

9

Factores de calidad externos

Eficiencia:

Es la capacidad de un sistema software de

requerir la menor cantidad posible de
recursos hardware.

Portabilidad:

Es la facilidad de transferir productos

software a diferentes plataformas (entornos
hw y sw)

Curso 2009/2010

Calidad del Sofware y OO

10

Factores de calidad externos

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. También incluye la facilidad de
instalación, operación y supervisión.

Funcionalidad:

Conjunto de posibilidades ofrecido por un sistema
Evitar añadir propiedades de forma incontrolada
Mantener constante el nivel de calidad

Oportunidad:

Es la capacidad de un sistema software de ser lanzado cuando

los usuarios lo desean, o antes.

Curso 2009/2010

Calidad del Sofware y OO

11

Otros factores de calidad
externos

Economía:

completarse con el presupuesto asignado

Integridad:

proteger contra modificaciones y accesos no

autorizados

Facilidad para reparación de errores
Facilidades de verificación:

datos de prueba y procedimientos para detectar

fallos

Curso 2009/2010

Calidad del Sofware y OO

12

Consecuencia de los criterios
de calidad

Buena documentación:

externa (usuarios) facilidad de uso
interna (desarrolladores) extensibilidad
interfaz del módulo extensibilidad y reutilización

Pueden entrar en conflicto. Por ejemplo:

Eficiencia y portabilidad
Corrección y reutilización
Facilidad de uso e integridad
Economía y funcionalidad

Curso 2009/2010

Calidad del Sofware y OO

13

Mantenimiento del software

Fase del ciclo de vida del software que sucede

después de que se haya distribuido.

Se le dedica el 70% del coste del software
El mantenimiento comprende:

DEPURACIÓN: quitar errores
MODIFICACIÓN: adaptación a los cambios

Se favorece el mantenimiento si:

El sistema es extensible y reutilizable
Es fácil reparar errores

Curso 2009/2010

Calidad del Sofware y OO

14

Calidad del software
Factores Externos

- Corrección
- Eficiencia
- Robustez
- Portabilidad
- Extensibilidad
- Facilidad de uso
- Reutilización
- Funcionalidad
- Compatibilidad - Oportunidad

Factores Internos

- Modularidad
- Legibilidad

Curso 2009/2010

Calidad del Sofware y OO

15

Factores de calidad internos:
Modularidad



tiene un sistema que ha sido
“Propiedad que
descompuesto en un conjunto de módulos cohesivos
y débilmente acoplados”

Curso 2009/2010

Calidad del Sofware y OO

[Booch’96]

16

Modularidad

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

Curso 2009/2010

Calidad del Sofware y OO

17

Principios de diseño modular

Ocultación de Información
Auto-documentación
Acceso Uniforme
Abierto-Cerrado
Elección Única

Curso 2009/2010

Calidad del Sofware y OO

18

Ocultación de la Información
“El diseñador de cada módulo debe seleccionar
un subconjunto de propiedades de un módulo
como información oficial para ponerla a
disposición de los autores de módulos
clientes”

Consiste en ocultar los detalles de la

implementación al código cliente

Curso 2009/2010

Calidad del Sofware y OO

19

Ocultación de Información

INTERFAZ
parte pública visible a
los clientes

IMPLEMENTACIÓN
Parte privada visible sólo
dentro del módulo

Curso 2009/2010

Calidad del Sofware y OO

20

Ocultación de Información.
Ejemplo: Pila

INTERFAZ
Push(x:T)
Pop(X:T)

IMPLEMENTACIÓN
contenido = array [1.. MAX] de T
Constante MAX = 100
Variable tope: entero

Curso 2009/2010

Calidad del Sofware y OO

21

Auto-documentación

“El diseño de un módulo debería esforzarse

para lograr que toda la información relativa al
módulo forme parte del propio módulo”

Útiles herramientas que generan la

documentación de usuario a partir de los
módulos documentados

Curso 2009/2010

Calidad del Sofware y OO

22

Principio de acceso uniforme

“Todos los servicios ofrecidos por un módulo deben estar

disponibles mediante una notación uniforme, que no
considere si se han implementado mediante almacenamiento o
cálculo”
Sea c una variable representando una cuenta bancaria
y saldo un servicio proporcionado por el módulo de
cuentas bancarias,
c.saldo saldo es un campo
saldo(c) saldo es una función

Necesitamos constructores sintácticos que nos permitan
expresar de la misma manera el acceso a una función y
a un atributo.

Curso 2009/2010

Calidad del Sofware y OO

23

Principio de Abierto-Cerrado

“Los módulos deberían ser a la vez abiertos y

cerrados”

Un módulo está abierto si está disponible para

ampliarlo
Extender o modificar la funcionalidad

Un módulo está cerrado si está disponible para

su uso

Curso 2009/2010

Calidad del Sofware y OO

24

Principio de Abierto-Cerrado

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 cambio en

cadena o gestión de versiones

Necesitamos un mecanismo que nos permita:

Adaptar un módulo sin afectar a los clientes
Que un módulo esté cerrado y abierto al mismo

tiempo

SOLUCIÓN: mecanismo de Herencia
Curso 2009/2010

Calidad del Sofware y OO

25

Principio de Elección Única

if (tipo == CIRCULO)
else if (tipo == CUADRADO)
else if (tipo == RECTANGULO)

print "Circulo. r=" + radio;
print “Cuadrado. lado=" + longLado;
print "Rect. h=" + altura + " b=" + base;

La misma estructura para el cálculo de:

área, intersección, …

¿Si añadimos un