Tema 1. Introducción al Paradigma Orientado a Objetos

Presentación del tema: "Tema 1. Introducción al Paradigma Orientado a Objetos"— Transcripción de la presentación:

1 Tema 1. Introducción al Paradigma Orientado a Objetos
Objetivo: El alumno se familiarizará con los conceptos básicos de la teoría de Orientación a objetos.

2 1 Introducción al Paradigma Orientado a Objetos
Antecedentes históricos y problemática. Complejidad del software Modularización Reutilización de código Paradigma Orientado a Objetos Introducción al lenguaje de programación Java.

3 Antecedentes históricos y problemática
Programación Orientada a Objetos Paradigma de programación que facilita modelar el mundo real dentro de nuestros programas. ¿Quién ha visto una función “reproducirSonido” haciendo ruido por la universidad? ¿Y a un perro ladrar?

4 Antecedentes históricos y problemática
La Programación Orientada a Objetos (POO) facilita pensar nuestros programas como entes del mundo real interaccionando de manera natural.

5 Antecedentes históricos y problemática
Riel (1996) afirma que es un paso natural para alejar al programador de software de los detalles de la máquina sobre la que se programa. Lenguaje máquina [1] Lenguaje ensamblador [2] Lenguaje estructurado [3] Lenguaje orientado a objetos [1] [2] [3]

6 Complejidad en el desarrollo de software
Los programas son difíciles de escribir por naturaleza. Brooks (1987) identifica dos tipos de complejidad en el software: Complejidad esencial. Complejidad accidental. COMPLEJIDAD ESENCIAL Se debe a que los problemas que intentamos modelar son intrínsecamente complejos, con muchas variantes y estados. Interacciones entre personas Mercados Redes Si simplificamos el problema, se dejan fuera propiedades esenciales del fenómeno a modelar.

7 Complejidad en el desarrollo de software
COMPLEJIDAD ESENCIAL El software que se comunica con otro software debe de adaptarse a los requerimientos del segundo, aumentando su complejidad. Los requerimientos no son estáticos, cambian conforme se interactúa con el usuario. Pues se descubren nuevas maneras de usarlo o campos de aplicación para los que no se había diseñado. Es difícil de visualizar. Cuando se intenta representar el comportamiento del software se requiere un gran número de diagramas (p. ej. UML), que no se pueden analizar al mismo tiempo.

8 Complejidad en el desarrollo de software
COMPLEJIDAD ACCIDENTAL Se debe a las dificultades externas al problema. Comunicar instrucciones a una computadora es difícil. Lenguaje máquina Mantener un código limpio y consistente entre versiones requiere mucha disciplina. Cada modificación tiene una gran probabilidad de introducir bugs. En el paso del diseño a la implementación se pueden perder detalles importantes.

9 Complejidad en el desarrollo de software
¡No todo está perdido! La POO ayuda a eliminar la complejidad accidental al proveernos un paradigma que puede usarse consistentemente en las fases de análisis, diseño e implementación de software - Riel(1996)

10 Modularización Modularización Según Niklaus Wirth (1974): "Nuestra herramienta mental más importante para competir con la complejidad es la abstracción. Por tanto, un problema complejo no deberá considerarse inmediatamente en términos de instrucciones de un lenguaje, sino de elementos naturales del problema mismo, abstraídos de alguna manera".

11 Modularización Se trata de construir modelos mentales que reproduzcan situaciones reales, y encapsulen y aíslen información y comportamientos, como piezas ejecutables. Éstas deben tener una interfaz de comunicación con el exterior conocida. Así mismo deben tener una ejecución correcta y ser de la máxima reutilización en otras situaciones similares.

12 Modularización El concepto básico del diseño modular es muy simple. Consiste en dividir un programa en módulos que puedan ser analizados, programados y depurados por separado. La máxima que rige esta filosofía es: Divide y vencerás. Realmente, la programación modular es un intento por diseñar programas por componentes, de forma que cualquiera de ellos pueda ser sustituido sin afectar al conjunto.

13 Modularización Un esquema que resume el proceso de diseño de programas podría ser: Descomposición del problema en bloques o módulos de sólida cohesión interna (Diseño modular) Programación de cada módulo mediante métodos estructurados (Programación estructurada) Integración de módulos mediante procedimientos descendentes (TOP-DOWN) o ascendentes (BOTTOM-UP)

14 Modularización El diseño modular y la programación estructurada son corrientes que surgen en los años 70’s, en el momento en que empieza el auge de los lenguajes de alto nivel, y hacen uso de procedimientos y funciones para la consecución de sus objetivos. A partir de aquí el interés principal del diseño de software evoluciona y se desplaza desde la importancia de los algoritmos (enfoque procedimental) como medios para la obtención de resultados, hasta centrarse en la propia naturaleza de los datos u objetos como elementos principales de interés. Se constituye entonces el diseño de software en un proceso de modelado de la realidad a través de los datos como su representación concreta.

15 Reutilización de código
Re-uso de código “La mejor manera de atacar la [complejidad] esencia de construir software, es ni si quiera construirlo” (Brooks, 1995) El re-usar código permite desarrollar software de manera más rápida: Es más fácil usar código ya construido que crearlo de cero. ¿Cuantas veces han leído directamente del buffer del teclado? ¿Y cuantas veces han usado scanf( )? Facilita su mantenimiento: Si se encuentra algún defecto en el software o una implementación mejor (más rápida, mas eficiente en memoria) solo se debe modificar en un solo punto para que todos quienes lo usan se vean beneficiados.

16 Reutilización de código
Formas de re-uso de código Copiar y pegar ¡La peor! ni siquiera debería aparecer en esta lista. NUNCA se debe usar Funciones Código que reciben datos de entrada, los procesa y devuelve un resultado sin efectos colaterales (modificar archivos, enviar mensajes). Módulos Conjunto de piezas de software que realiza un proceso en específico. Módulo de Inteligencia Artificial Módulo de render Modulo de procesamiento de imágenes Bibliotecas Conjunto de implementaciones de software escritas para un lenguaje o plataforma específico

17 Reutilización de código
Formas de re-uso de código API (Application Program Interface) Es la definición de funcionalidad que debe proveer una biblioteca. Es independiente de la implementación. Dice “Que” hace el software no “Como” lo hace Servicios web Es la tendencia actual para el desarrollo de software re-utilizable. Permite exponer en Internet APIs específicos aplicaciones. Google maps API ( Twitter REST API ( Facebook (

18 Reutilización de código
Diseñando para el re-uso Cuando desarrollamos software siempre debemos tener como meta que sea re-utilizable. POO (bien aplicada) nos ayuda a crear elementos de software altamente re-utilizables, ya que sus principios están orientados a ello: Abstracción Programación a interfaces Composición Polimorfismo Herencia

19 1 Introducción al Paradigma Orientado a Objetos
Referencias Riel, A. J. (1996). “Object Oriented Design Heuristics”. Estados Unidos: Addison-Wesley Brooks F.P. Jr. (1987). “Concepual Essence of Software Egineering or There is No Silver Bullet”. IEEE Computer, Octubre 1987 Brooks F.P. Jr. (1995). “The mythical man-month: essays on software engineering”