Antecedentes históricos y problemática Introducción al Diseño Orientado a Objetos

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?

● La Programación Orientada a Objectos (POO) facilita pensar nuestros programas como entes del mundo real interaccionando de manera natural. Programación Orientada a Objetos

● 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] [1] [2] [3] Lenguaje ensamblador [2] Lenguaje estructurado [3] Lenguaje orientado a objetos

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

Complejidad en el desarrollo de software – 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.

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.

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)

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

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.

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.

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)

Modularización ● El diseño modular y la programación estructurada son corrientes que surgen en los años 70, 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.

Modularización ● 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.

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

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

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 ( –

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

Referencias ● Riel, A. J. (1996) Object Orieted 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