PDF de programación - TEMA 1 Orientación a objetos, una técnica para mejorar la calidad del software - Programación Orientada a Objetos

Imágen de pdf TEMA 1 Orientación a objetos, una técnica para mejorar la calidad del software - Programación Orientada a Objetos

TEMA 1 Orientación a objetos, una técnica para mejorar la calidad del software - Programación Orientada a Objetosgráfica de visualizaciones

Publicado el 31 de Mayo del 2018
456 visualizaciones desde el 31 de Mayo del 2018
1,4 MB
38 paginas
Creado hace 14a (02/10/2006)
Programación Orientada a Objetos

TEMA 1

Orientación a objetos, una técnica para

mejorar la calidad del software

Facultad de Informática
Universidad de Murcia

Índice

1.- Calidad del software
2.- Modelo de objetos

- Abstracción
- Encapsulación
- Modularidad

- Herencia
- Polimorfismo

3.- Reutilización
4.- Diseño Estructurado vs. Diseño OO
5.- Tipos abstractos de datos

Calidad del Sofware y OO

2

1.- Calidad del Software

• Factores Externos

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

• Factores Internos

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

OBJETIVO

Buenas propiedades

internas

Satisfacer factores

externas

La POO es un conjunto de técnicas para obtener calidad internacomo
medio para obtener calidadexterna(Reutilización y Extensibilidad)
3

Factores de calidad del Software
• Factores Externos

- Corrección
- Robustez
- Extensibilidad
- Reutilización
- Compatibilidad

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

- Economía
- Integridad
- Facilidad de reparación
- Facilidad de verificación

• Factores Internos

- Modularidad
- Legibilidad

Calidad del Sofware y OO

4

Corrección

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

- Definir los requisitos de manera precisa

Robustez

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

Robustez

ESPECIFICACIÓN

Corrección

Tienen que ver con el

comportamiento

(casos previstos o no)

5

Extensibilidad

Es la facilidad de adaptación de los productos software a los
cambios en la especificación.

• Cambios son frecuentes puesto que en la base de todo

software hay algún fenómeno humano.

• Dificultad de adaptación proporcional al tamaño del

sistema.

• Principios esenciales para facilitar la extensibilidad

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

Calidad del Sofware y OO

6

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 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 estándar de comunicación inter- módulos

Calidad del Sofware y OO

7

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- 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 y OO

8

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
• Buen producto software debe estar basado en un pequeño

número de grandes ideas

• Mantener constante el nivel de calidad

Calidad del Sofware y OO

9

Oportunidad

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

Otros factores
• Economía:

completarse con el presupuesto asignado

• Integridad:

proteger contra modificaciones y accesos no autorizados

• Facilidad para reparaciones (de defectos)
• Facilidades de verificación:

datos de prueba y procedimientos para detectar fallos

Calidad del Sofware y OO

10

Consecuencia de estos criterios:

• Necesidad de una BUENA DOCUMENTACIÓN:

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

• Factores pueden entrar en CONFLICTO:

– integridad ⇔ facilidad de uso
– economía ⇔ funcionalidad
– eficiencia ⇔ portabilidad
– ajustarse a la especificación ⇔ reutilización

Calidad del Sofware y OO

11

Mantenimiento del software
• No figura como factor facilidad de mantenimiento
• Mantenimiento es lo que sucede después 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:

MODIFICACIÓN
adaptación a los cambios

– Parte no noble:

DEPURACIÓN

quitar errores
Calidad del Sofware y OO

12

Costes de mantenimiento del software

Mejoras en la

eficiencia

Documentación

Cambios en el

hardware

Arreglos de

rutinas

Cambios de
emergencia

3,50%

4%

5,50%

6,20%

9%

12,40%

17,60%

Otros

[Lientz 1980]

Cambios en
los requisitos
de los usuarios

41,80%

Cambios en

los formatos de

los datos

Calidad del Sofware y OO

13

Conclusiones del estudio

• 41’8% extensiones y modificaciones usuario → Ausencia

de extensibilidad

• 17’6% cambio de los datos → Estructura física de los

datos dispersa por muchas partes del sistema

• 5’5% Documentación → No se hace documentación a

posteriori

• 4% Mejoras en la eficiencia → Cuando el sistema funciona

no se buscan mejoras en eficiencia.

Calidad del Sofware y OO

14

2.- Modelo de Objetos
1. 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” [Budd’02]

[Booch’96]

Calidad del Sofware y OO

15

– Métodos de abstracción:

•Abstracción por parametrización: nos
permite abstraernos de la identidad de los datos
sustituyéndolos por parámetros.

abstraernos de

•Abstracción por especificación: nos
permite
los detalles de
implementación y
el
comportamiento en el que pueden confiar los
usuarios.

fijarnos

sólo

en

Calidad del Sofware y OO

16

– Tipos de abstracciones:

•Abstracción procedural:

– Permite introducir nuevas operaciones.
– Permite abstraer una única acción o tarea.

•Abstracción de datos:

– Permite introducir nuevos tipos de datos
– Se consigue la abstracción por especificación haciendo
tipo que definen el

las operaciones parte del
comportamiento.

•Abstracción de iteración:

– Permite iterar sobre los elementos de una colección sin

revelar la manera en la que se obtiene cada elemento.

Calidad del Sofware y OO

17

2. Encapsulación:

“Proceso de almacenar en un mismo compartimento los
elementos de una abstracción que constituyen su estructura y
su comportamiento” [Booch’96]

Calidad del Sofware y OO

[Booch’96]

18

3. Modularidad:

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

Calidad del Sofware y OO

[Booch’96]

19

• 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 estrechas y

bien definidas.

Calidad del Sofware y OO

20

Principios de diseño modular
• Ocultación de 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”
– Una abstracción de datos puede verse como que tiene dos

caras:
• Interfaz: operaciones que definen el comportamiento

(cliente)

• Implementación (programador)

Calidad del Sofware y OO

[Budd’02]

21

Ocultación de Información

INTERFAZ

IMPLEMENTACIÓN

Calidad del Sofware y OO

22

• 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”

• 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
una propiedad aplicable a c ,

c.saldo saldo es un campo de un registro
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.

Calidad del Sofware y OO

23

• Principio Abierto-Cerrado

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

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

cadena

Calidad del Sofware y OO

24

Principio Abierto-Cerrado

B

C

F

D

A

E
• Dos soluciones:

A’

G

– Adaptar el módulo A
(cambios en cadena en los clientes)
– Crear una copia de A
(explosión de variantes de módulos)

H
¿Es posible adaptar A sin afectar a los clientes?
¿Cómo se pueden obtener módulos que sean a la

vez abiertos y cerrados?

Calidad del Sofware y OO

25

Principio abierto-cerrado

D

E

A

A’

G

B

C

F

H

Solución: HERENCIA
A’ contiene solamente las diferencias :

- nuevas características
  • Links de descarga
http://lwp-l.com/pdf11485

Comentarios de: TEMA 1 Orientación a objetos, una técnica para mejorar la calidad del software - Programación Orientada a Objetos (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios...
CerrarCerrar
CerrarCerrar
Cerrar

Tienes que ser un usuario registrado para poder insertar imágenes, archivos y/o videos.

Puedes registrarte o validarte desde aquí.

Codigo
Negrita
Subrayado
Tachado
Cursiva
Insertar enlace
Imagen externa
Emoticon
Tabular
Centrar
Titulo
Linea
Disminuir
Aumentar
Vista preliminar
sonreir
dientes
lengua
guiño
enfadado
confundido
llorar
avergonzado
sorprendido
triste
sol
estrella
jarra
camara
taza de cafe
email
beso
bombilla
amor
mal
bien
Es necesario revisar y aceptar las políticas de privacidad