Orientacion objetos - UNEG - Profesor Mauricio Paletta

1. Presentación
Introducción a la Orientación a Objetos
Ing. Mauricio Paletta, Msc
INGENIERÍA EN INFORMÁTICA
Programación II
UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA
Programación II

2. La Crisis del Software
• Fenómeno ocurrido en la década de los
80’s como consecuencia del auge de la
automatización haciendo uso de
computadoras.
• La mayoría del software se construye a la
medida, en vez de ensamblar componentes
existentes.
• Los programadores no disponen / usan
“componentes” de software reutilizables 
empezar desde cero.
Programación II

3. La Crisis del Software
• “Complejidad del Software”.
Programación II

4. La Crisis del Software
Brooks: “… es una propiedad esencial, no
accidental”
“… es una característica
inherente, por lo tanto
debemos tratar de
administrar la
complejidad”
Programación II

5. La Crisis del Software
• No terminar los proyectos a tiempo.
• Consumir más presupuesto del planificado.
• Baja productividad.
• Hacer productos de baja calidad.
• Gran cantidad de personal especializado
dedicado a labores de mantenimiento.
• Usuarios insatisfechos con los sistemas y
con los departamentos o grupos de
desarrollo.
Programación II

6. La Crisis del Software
• Usuarios se preguntan:
¿Por qué el desarrollo
de software es tan
costoso?
¿Por qué toma tanto
tiempo?
¿Hay alguna perspectiva
de mejora?
Programación II

7. La Complejidad del Software
Programación II

8. La Complejidad del Software
4 factores que influyen en la complejidad:
Complejidad del dominio del problema:
• Problemas que involucran elementos de
gran complejidad.
• Existencia de requerimientos
contradictorios.
• Distancia entre el usuario y el
desarrollador (diferentes perspectivas del
problema).
Programación II

9. La Complejidad del Software
Dificultad de administrar el proceso de
desarrollo:
• Dar la ilusión de simplicidad.
• Manejo de un grupo de trabajo
(problemas de comunicación,
coordinación e integración).
Programación II

10. La Complejidad del Software
Flexibilidad exigida al software:
• Eficiencia versus eficacia.
• Optimización de recursos versus calidad
en la respuesta.
• Bueno / bonito / barato.
Programación II

11. La Complejidad del Software
Mantenimiento del software:
• Correctivo – corregir errores en
programas (20 %).
• Adaptativo – cambios en los
requerimientos (25 %).
• Perfectivo – tratar de mantener el
software operativo (55 %).
Programación II

12. Llegada al Caos
A medida que aumentó la complejidad del
software requerido, se redujo las habilidades
para manejar la complejidad.
CAOS
Programación II

13. Llegada al Caos
Solución de la Ingeniería de Software:
• Tratar el software como una ingeniería.
• Uso de metodologías estructuradas.
• Mayor participación del usuario.
• Pruebas planificadas
y documentadas.
• Uso de herramientas
automatizadas.
Programación II

14. Llegada al Caos
Un médico, un ingeniero civil y un profesional de la
computación estaban discutiendo sobre cuál era la
profesión más antigua del mundo:
El médico: En la Biblia dice que Dios creó a Eva de la
costilla de Adán, por lo tanto la mía es la profesión más
antigua.
El ingeniero civil: Pero en el génesis dice que Dios impuso
el orden y sacó a la tierra del CAOS en que se encontraba
en siete días; esta fue la primera y más espectacular
aplicación de ingeniería civil.
El profesional de la computación: Pero, ¿quién creen
ustedes que creó el CAOS?
Programación II

15. Características ideales Software (McCall)
• Mantenibilidad • Portabilidad
• Flexibilidad • Reusabilidad
• Verificabilidad • Interoperabilidad
Revisión Transición
del del
Producto Producto
Características
Operacionales
• Corrección • Integridad
• Fiabilidad • Usabilidad
• Eficiencia
Programación II

16. Características ideales Software (McCall)
Revisión del producto:
• Mantenibilidad: fácil corregir errores.
• Flexibilidad: fácil de modificar.
• Verificabilidad: fácil de probar.
Programación II

17. Características ideales Software (McCall)
Transición del producto:
• Portabilidad: fácil de transportar entre
ambientes.
• Reusabilidad: grado en que el todo o
alguna de las partes se pueda usar en
otros desarrollos.
• Interoperabilidad: fácil de acoplar.
Programación II

18. Características ideales Software (McCall)
Características operacionales:
• Corrección: grado de satisfacción de
requerimientos.
• Fiabilidad: grado de funcionamiento
esperado.
• Eficiencia: minimización de recursos.
• Integridad: grado de seguridad.
• Usabilidad: facilidad de aprendizaje y
operación.
Programación II

19. Características ideales Software (McCall)
Otros aspectos:
• Comprensibilidad: grado de poderse leer y
comprender.
• Robustez: capacidad de funcionar en
condiciones anormales.
• Extensibilidad: facilidad de crecer/ mejorar.
• Modularidad: grado de independencia
funcional de cada uno de los
componentes.
Programación II

20. 3 Puntos para traer orden al Caos
Descomposición:
• Descomponer el software en partes
pequeñas para ser refinadas de forma
independiente.
• La complejidad del problema se restringe
a la complejidad de cada una de las
partes.
• Es necesario hacer una división
inteligente.
Programación II

21. 3 Puntos para traer orden al Caos
Conceptos relacionados
• Modularidad.
• Programación estructurada.
Programación II

22. 3 Puntos para traer orden al Caos
Abstracción:
• Ignorar los detalles no significativos de
cada elemento y trabajar con modelos
ideales de éstos.
• Brinda enorme poder para manejar la
complejidad.
• Ayuda a vencer las limitaciones de
nuestra memoria intermedia para el
manejo de la información.
Programación II

23. 3 Puntos para traer orden al Caos
Conceptos relacionados
• Tipo abstracto de datos.
• Conceptualización del dominio.
Programación II

24. 3 Puntos para traer orden al Caos
Jerarquía:
• Organizar los elementos en niveles de
categoría.
• Relaciones estructurales y semánticas.
• Incrementa el contenido semántico de las
piezas de información.
• Ayuda a la comprensión del
funcionamiento del sistema.
Programación II

25. 3 Puntos para traer orden al Caos
Conceptos relacionados
• Clasificación /
generalización /
tipo de.
• Composición /
agregación /
parte de.
Programación II

26. Orientación a Objetos
Fórmula conceptual:
Orientación a Objetos = Descomposición +
Abstracción +
Jerarquía
Programación II

27. Orientación a Objetos
Descomposición ¿Cómo hacer que el
conjunto de elementos
resuelvan el problema?
Abstracción ¿Cómo identificar los
elementos basado en los
conceptos del problema?
Jerarquía ¿Cómo relacionar los
elementos para reducir la
complejidad de cada uno
de ellos?
Programación II

28. Orientación a Objetos
• Surge como una respuesta hacia la crisis
del software.
• Es una nueva forma de pensar usando
conceptos del mundo real.
• Significa que el software se organiza
como un conjunto de objetos discretos
cada uno de los cuales incorpora su
estructura de datos y su comportamiento.
Programación II

29. Orientación a Objetos
• “Ejecutar un programa o sistema, es algo
tan sencillo como crear objetos y disparar
mensajes” (A. Goldberg)
• Término introducido en el léxico con la
llegada del lenguaje de programación
Smalltalk.
• Conceptos a manejar: clase, objeto,
método, mensaje, subclase, superclase,
instancia, herencia, encapsulamiento,
polimorfismo, interfaz.
Programación II

30. Orientación a Objetos
Descomposición Orientación
funcional a Objetos
Módulos construidos Módulos construidos
alrededor de las alrededor de las clases
operaciones
Datos globales o Clases débilmente
distribuidos entre los acopladas y sin datos
módulos globales
Entrada / Proceso / Salida Encapsulamiento /
Mensajes
Organigramas de flujos de Diagramas jerárquicos de
datos clases
Programación II

31. Orientación a Objetos
Programación II

32. Orientación a Objetos
Beneficios:
• Desarrollos más rápidos – basado en la
reusabilidad de elementos.
• Calidad más alta – basado en el uso de
objetos eficientes y eficaces ya existentes.
• Mantenimiento más fácil – basado en el
uso de objetos libres de errores.
Programación II

33. Orientación a Objetos
• Costos más bajos (programación, diseño
y administración).
• Soporte a sistemas de gran escala.
• Mejores estructuras de información.
• Aumento de la adaptabilidad.
Programación II

34. Evolución Histórica
1957 Ten Dyke & Kunz usaron técnicas rudimentarias de orientación a
objetos en el diseño del misil Minuteman.
1967 Desarrollo del lenguaje de simulación de sucesos discretos –
Simula, en Noruega, por K. Nygaard. Introdujo los conceptos
básicos de OO. La idea fue definir un lenguaje para construir
modelos de sistemas físicos complejos que pueden contener miles
de componentes. Los módulos están basados en los objetos físicos
presentes en el entorno del problema.
1970 Desarrollo del lenguaje de programación Smalltalk en el Centro de
Investigaciones de Palo Alto (PARC), basado en el trabajo doctoral
de Alan Kay. Visión de un PC pequeño, universal, capaz de tratar
cualquier clase de problema de gestión de información.
1970 Desarrollo de la máquina Flex – Dynabook en PARC, basado en
Smalltalk.
Programación II

35. Evolución Histórica
1975 Fertilización recíproca entre la OOP y la investigación y el
desarrollo en IA: LISP, FLAVORS, LOOPS y CLOS, KEE y ART
(ideas sobre la representación del conocimiento fundamentadas en
redes y marcos semánticos – importante para el concepto de
herencia).
1976 Desarrollo del lenguaje Alphard por Wulf y compañía.
1977 Desarrollo del lenguaje CLU por Liskov y compañía.
1980 Explosión de interés por las interfaces de usuario: WIMP –
Windows, Icons, Mice and Pointers (Apple); GUI – Graphical User
Interface; Presentation Manager, Microsoft Windows; Sistemas
estandarizados abiertos basados en UNIX.
Programación II

36. Evolución Histórica
1986 Sistemas de Actores – Ahga, dirigidos normalmente a aplicaciones
en tiempo real y concurrentes.
1986 Desarrollo del lenguaje de programación C++, por Bjarne Stroustup
(AT&T).
1988 Desarrollo del lenguaje de programación Eiffel, por Bertrand Meyer.
1989 Sistemas de pizarra (Englemore y Morgan) para la representación
y manejo del conocimiento.
1989 Desarrollo de herramientas CASE e IPSE.
1990 Interés hacia el análisis y diseño orientado a objetos: Biggerstaff y
Richter, Prieto-Díaz y Freeman, Sommerville, Booch, Rumbaugh
(OMT), Jakobson (OOSE)
Programación II

37. Evolución Histórica
1990 Interés hacia la definición de estándares. El principal protagonista
es el grupo OMG (UML, OMA, CORBA, MDA, etc.)
1990 Base de datos orientada a objetos
1996 Desarrollo del lenguaje de programación Java, por Sun
Microsystems
2000 Desarrollo del lenguaje de programación C#. Búsqueda de
conceptos de niveles de abstracción más altos que un objeto:
Agente, Cubo, etc. Base de toda plataforma de software:
operativa, desarrollo, gráfica, etc.
Programación II

38. Evolución Histórica
Fase I Fase II Fase III Fase IV
década de los 70 década de los 80 década de los 90 del 2000 hasta hoy
(época de invención) (época de confusión) (época de madurez) (época actual)
Simulación de Interfaces WIMP Énfasis en el análisis Búsqueda de niveles
sucesos discretos y el diseño más altos de
abstracción (Agentes,
cubos, etc.)
Simula Xerox y Apple Sistemas abiertos C#
Kay: máquina FLEX Extensiones LISP Aplicaciones Paradigma de todas
las plataformas de
desarrollo
PARC: Dynabook Entornos de Bases de datos UML versión …
inteligencia artificial orientadas a objetos
Smalltalk Nuevos lenguajes: Estándares Software => Objetos
Eiffel, C++, …
Programación II

39. Evolución Histórica
Programación II

40. Evolución Histórica
Algoritmos y Programación III
Programación II