Professional Documents
Culture Documents
TECNOLOGÍA DE
OBJETOS
Orientación a Objetos
Objetivos
Describir los conceptos fundamentales de tecnología y terminología
relacionada
Describir los beneficios de la construcción de aplicaciones OO
Describir los procesos incremental e iterativo para el desarrollo de
aplicaciones utilizando la tecnología de objetos, y como difieren de
los enfoques tradicionales, como el modelo en cascada
Describir los principales productos, que son desarrollados para dar
soporte al desarrollo de aplicaciones que utilizan la tecnología de
objetos y sus relaciones
Describir el impacto del diseño de una aplicación para manipular
posibles cambios y los diferentes enfoques para soportar tales
diseños
Describir las tendencias actuales en el soporte de la programación
orientada a objetos, incluyendo metodologías, herramientas y
marcos de trabajo
Listar las similitudes y diferencias entre el desarrollo de aplicaciones
procedural y el desarrollo de aplicaciones orientado a objetos
Introducción
La Crisis del SW
Factores Internos
Modularidad
Legibilidad
La calidad del software
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.
Hay que definir los requisitos de manera precisa.
Robustez:
Es la capacidad de los productos software de
reaccionar adecuadamente ante situaciones
excepcionales.
La calidad del software
Factores de calidad externos
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.
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.
Eficiencia:
Es la capacidad de un sistema software de
requerir la menor cantidad posible de recursos
hardware.
Factor importante para la utilización.
Debemos conjugar eficiencia con los otros objetivos.
Portabilidad:
Es la facilidad de transferir productos software a
diferentes plataformas (entornos hw y sw).
La calidad del software
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.
Oportunidad:
Es la capacidad de un sistema software de ser lanzado
cuando los usuarios lo desean, o antes.
Otros factores:
Economía:
Debe completarse con el presupuesto asignado.
Integridad:
Protección del sistema contra modificaciones y accesos no
autorizados.
Facilidad para reparaciones (de defectos)
Facilidades de verificación:
Datos de prueba y procedimientos para detectar fallos.
La calidad del software
Consecuencias 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 que pueden entrar en CONFLICTO:
integridad ↔ facilidad de uso
economía ↔ funcionalidad
eficiencia ↔ portabilidad
ajustarse a la especificación ↔ reutilización
La calidad del software
Factores de calidad internos
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.
La calidad del software
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.
La calidad del software
Modularidad
Abstracción (I):
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
Modularidad:
Tipos abstractos de datos
Abstracción (II):
Modularidad:
Tipos abstractos de datos
Encapsulación:
“Proceso de almacenar en un mismo
compartimento los elementos de una abstracción
que constituyen su estructura y su
comportamiento” [Booch’96]
Modularidad:
Tipos abstractos de datos
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.
Modularidad:
Tipos abstractos de datos
Un “paquete” de software
independiente formado por
un conjunto de datos junto
con los procedimientos que
operan sobre estos datos.
Se especifican sus
atributos.
Este coche tiene ahora
una “existencia
informática”.
Está en condiciones de
participaren las
secuencias de
interacciones.
Programación OO
Clase
Reutilización de software.
Mayor seguridad, menor coste.
Reutilización de componentes.
Rápido prototipado.
Consistencia de la interface.
Comportamiento similar de todas las clases que
heredan de una superclase.
Programación OO
Clases abstractas
Unificación de la sintaxis
funciones:
restar ( a, b ) : restar a de b o restar b de a ?
mensaje: a restar: b, a - b
Simplificación de la sintaxis
"El gato come al ratón"
¿Qué es lo más natural ?
Comer (gato, ratón)
gato.come(ratón)
Programación OO
Polimorfismo
Significa tener o asumir distintas formas. En el contexto de POO
se refiere a la capacidad de los diferentes objetos para
responder de distinta forma a la misma operación. Esta
característica habilita al programador para tratar uniformemente
objetos que provienen de clases diferentes.
Permite enviar el mismo mensaje a objetos diferentes y que
cada uno responda en la forma apropiada según el tipo de objeto
que sea, ejecutando su método.
El polimorfismo está asociado a la ligadura dinámica
(“dynamic binding”). La asociación de un método con su nombre
no se determina hasta el momento de su ejecución.
El polimorfismo es una aplicación particular de la herencia de
comportamiento. Una misma operación (un mismo elemento de
comportamiento) podrá interpretarse de diversas maneras según
la posición en la que se encuentre dentro de la jerarquía.
Usualmente requiere del empleo de clases abstractas.
Programación OO
Polimorfismo
Programación OO
Polimorfismo
Ventajas:
Da uniformidad a la sintaxis.
Disminuye la cantidad del código a escribir (por
eliminación de las estructuras alternativas con
opciones múltiples).
Facilita el tratamiento de colecciones
heterogéneas.
Análisis y Diseño
Orientado a Objetos con UML
Ingeniería del Software
2. 1) Análisis:
Se intenta llegar a una buena comprensión del problema por
parte del equipo de desarrollo, sin entrar en cómo va a ser la
solución en cuanto a detalles de implementación.
Trabajamos con los modelos de casos de uso construidos en la
fase anterior, ampliándolos y refinándolos.
Se construye un Modelo de Objetos Conceptual o Modelo de
Análisis mediante un diagrama de clases, compuesto de
clases y relaciones entre las clases.
Se deberán identificar los conceptos más importantes del
sistema (objetos físicos, roles de una persona, etc.), los
atributos de los mismos y las relaciones existentes entre
ellos. Por ejemplo en un sistema bancario se pueden identificar
conceptos como cuenta, cliente, tarjeta de crédito, saldo, recibo,
etc.
Análisis y Diseño
Orientado a Objetos con UML
El proceso de desarrollo OO (IV)
Análisis y Diseño
Orientado a Objetos con UML
El proceso de desarrollo OO (V)
2. 2) Diseño:
En la fase de Diseño se crea una solución a nivel lógico para
satisfacer los requisitos, basándose en el conocimiento reunido
en la fase de análisis.
Las tareas que se realizan en esta fase son las siguientes:
Definir el Diagrama de Clases de Diseño detallado.
Definir las estructuras de datos necesarias para almacenar la
información que utiliza el sistema.
Definir la Interfaz de Usuario e Informes.
Los diagramas de clases definidos en la fase anterior se
pueden refinar con la especificación de atributos y operaciones
para cada una de las clases y las relaciones con otras clases
(generalización, agregación, composición, uso, etc). Con la
información obtenida en los casos de uso, se pueden derivar las
operaciones y asignarse a las clases existentes.
Análisis y Diseño
Orientado a Objetos con UML
UML (I)
Ejemplo: Casos
de uso de un
empleado de un
banco que
gestiona
clientes y
cuentas:
Análisis y Diseño
Orientado a Objetos con UML
Notación UML: Diagrama de clases (I)