Fundamentos de Programacin Orientada a Objetos
Pgina 1 Ing. Isis Espinosa Salazar
I.- FUNDAMENTOS DE PROGRAMACIN ORIENTADA A OBJETOS 1.1 Evolucin de la programacin 1.2 Conceptos fundamentales de la Programacin Orientada a Objetos
1.2.1 Los lenguajes orientados a objetos 1.3 Relaciones entre clases y objetos 1.4 El papel de clases y objetos en el anlisis y el diseo
Fundamentos de Programacin Orientada a Objetos
Pgina 2 Ing. Isis Espinosa Salazar
I.- FUNDAMENTOS DE PROGRAMACIN ORIENTADA A OBJETOS 1.1 Evolucin de la programacin 1.2 Conceptos fundamentales de la Programacin Orientada a Objetos
1.2.1 Los lenguajes orientados a objetos 1.3 Relaciones entre clases y objetos 1.4 El papel de clases y objetos en el anlisis y el diseo
1.1 Evolucin de la programacin La evolucin de la programacin puede sintetizarse en tres modelos o paradigmas:
El significado de paradigma (paradigma en latn; paradeigma en griego) en su origen significaba un ejemplo ilustrativo; en particular, enunciado modelo que mostraba todas las inflexiones de una palabra. Un paradigma es una forma establecida de pensar acerca de cmo hacer algo. En el libro The Structure of Scientific Revolutions, el historiador Thomas Kuhn describa un paradigma como un conjunto de teoras, estndares y mtodos que juntos representan un medio de organizacin del conocimien-to: es decir, un medio de visualizar el mundo.
La programacin mediante procedimientos (procedural), La programacin estructurada y La programacin orientada a objetos
PROGRAMACION MEDIANTE PROCEDIMIENTOS [PROCEDURAL]
Programacin y abstraccin La abstraccin es el proceso de extraer las propiedades relevantes de un objeto al tiempo que se ignoran los detalles
no esenciales. Las propiedades extradas definen una vista del objeto. En esencia, la abstraccin supone la capaci-dad de encapsular y aislar, la informacin del diseo, de la ejecucin.
Definir una abstraccin significa describir una entidad del mundo real, no importa lo compleja que pueda ser y, a
continuacin, utilizar esta descripcin en un programa. La abstraccin es fundamental para gestionar la complejidad del diseo y escritura del software. La abstraccin es la
clave para disear buen software. La abstraccin es uno de los medios ms importantes, mediante el cual nos enfren-tamos con la complejidad inherente al software.
Una abstraccin se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento esencial
de un objeto de su implementacin Como describe Wulft: Los humanos hemos desarrollado una tcnica excepcionalmente potente para tratar la comple-
jidad: abstraemos de ella. Incapaces de dominar en su totalidad los objetos complejos, se ignora los detalles no esen-ciales, tratando en su lugar con el modelo ideal del objeto y centrndonos en el estudio de sus aspectos esenciales.
El proceso de abstraccin fue evolucionando desde la aparicin de los primeros lenguajes de programacin. La abstraccin es esencial para el funcionamiento de una mente humana normal y es una herramienta muy potente
para tratar la complejidad. El mtodo ms idneo para controlar la complejidad es aumentar los niveles de abstraccin. Las personas normalmente comprenden el mundo construyendo modelos mentales de partes del mismo; tratan de
comprender cosas con las que pueden interactuar. Un modelo mental es una vista simplificada de cmo funciona, de modo que se pueda interactuar con ella.
En esencia, este proceso de construccin de modelos es lo mismo que el diseo de software, aunque el desarrollo de
software es nico: el diseo de software produce el modelo que puede ser manipulado por una computadora. Sin embargo, los modelos mentales deben ser ms sencillos que el sistema al cual imitan, o en caso contrario sern
intiles. Por ejemplo, consideremos un mapa como un modelo de su territorio. A fin de ser til, el mapa debe ser ms sencillo que el territorio que modela. Un mapa nos ayuda, ya que abstrae slo aquellas caractersticas del territorio que deseamos modelar. Un mapa de carreteras modela cmo conducir mejor de una posicin a otra. Un mapa topogrfico modela el contorno de un territorio, quiz para planear un sistema de largos paseos o caminatas.
Fundamentos de Programacin Orientada a Objetos
Pgina 3 Ing. Isis Espinosa Salazar
De igual forma que un mapa debe ser ms pequeo significativamente que su territorio e incluye slo informacin seleccionada cuidadosamente, as los modelos mentales abstraen esas caractersticas de un sistema requerido para nuestra comprensin, mientras ignoran caractersticas irrelevantes. Este proceso de abstraccin es psicolgicamente necesario y natural: la abstraccin es crucial para comprender este complejo mundo.
Un conjunto se puede definir por abstraccin como una coleccin no ordenada de elementos en el que no existen
duplicados. Utilizando esta definicin, se puede especificar si sus elementos se almacenan en un arreglo, una lista en-lazada o cualquier otra estructura de datos.
Un vendedor de coches podra ver un coche desde el punto de vista de sus caractersticas de venta. Propiedades
relevantes seran el precio, el color, el equipo opcional y la duracin de la garanta. Por otro lado, un mecnico vera el coche desde el punto de vista de los sistemas que necesitan mantenimiento. Para l, propiedades relevantes seran el motor, sistema electrnico de encendido, tipo de aceite, el tamao del filtro de aceite y el nmero y tipo de bujas. Las propiedades relevantes de un objeto vienen definidas por la forma en que se usa o manipula el objeto.
Claramente las propiedades de un coche, importantes para un vendedor, son distintas de las de un mecnico. En-
focndose sobre las propiedades relevantes e ignorando los detalles irrelevantes, se puede reducir la complejidad de manejo de un objeto.
Consideremos la tarea de encontrar un archivo en un disco y leer su contenido. Si tuvisemos que manejar todos los
detalles de bajo nivel para saber cmo encontrar un archivo concreto en el disco y cmo leer sus contenidos, sera una tarea bastante difcil. Deberamos comprender cmo se almacenan los datos en los discos y todos los mandatos de ba-jo nivel que controlan las operaciones del manejador de disco. Afortunadamente, existe un sistema de archivos que proporciona una visin abstracta de la informacin en un disco, de forma que se pueden ignorar los detalles de bajo ni-vel. Se puede acceder al archivo sin ms que proporcionar su nombre. El sistema de archivos maneja los detalles de bajo nivel para leer los datos en el disco y devolverlos al programa.
El arte de la programacin es el mtodo por el que se describir a una computadora (mediante un lenguaje de pro-
gramacin) un fenmeno, una accin, un comportamiento o una idea. En general, un programa no es ms que una descripcin abstracta de un procedimiento o fenmeno que existe o sucede en el mundo real. Frecuentemente, un programa imita un comportamiento o accin humana; otras veces simula (es decir, reproduce) un fenmeno fsico.
Sin embargo, la relacin entre abstraccin y lenguaje de programacin es doble: por un lado se utiliza el lenguaje de programacin para escribir un programa que es una abstraccin del mundo real; por otro lado se utiliza el lenguaje de programacin para describir de un modo abstracto el comportamiento fsico de la computadora que se est utilizando (por ejemplo, utilizando nmeros decimales en lugar de nmeros binarios, variables en lugar de celdas de memoria di-reccionadas explcitamente, etc.).
En los primeros das de la informtica, los programadores enviaban instrucciones binarias a una computadora, manipu-lando directamente interrupciones en sus paneles frontales.
En la dcada de los cincuenta, los nicos mecanismos de abstraccin eran el lenguaje de mquina y el lenguaje en-
samblador. El lenguaje ensamblador ofreca la posibilidad de utilizar mnemnicos, que eran abstracciones diseadas para evitar que los programadores tuvieran que recordar las secuencias de bits que componen las instrucciones de un programa. Ofrece tambin la posibilidad de utilizar nombres simblicos para representar celdas de memoria.
El siguiente nivel de abstraccin se consigue agrupando instrucciones primitivas para formar macroinstrucciones. Un
conjunto de instrucciones realizadas por un usuario se pueden invocar por una macroinstruccin; una macroinstruccin instruye a la mquina para que realice muchas cosas.
Tras los lenguajes de programacin ensambladores aparecieron los lenguajes de programacin de alto nivel, que
supusieron un nuevo nivel de abstraccin. Los lenguajes de programacin de alto nivel permitieron a los programadores distanciarse de las caractersticas arqui-
tectnicas especficas de una mquina dada. Cada instruccin en un lenguaje de alto nivel puede invocar varias ins-trucciones mquina, dependiendo de la mquina especfica donde se compila el programa. Esta abstraccin permita a los programadores escribir software para propsito genrico, sin preocuparse sobre qu mquina ejecutara el progra-ma.
Secuencias de sentencias de lenguajes de alto nivel se pueden agrupar en procedimientos y se invocan por una sen-
tencia. El mundo en que vivimos se halla plagado de objetos: aviones, trenes, automviles, telfonos, libros, computadoras,
etctera. Sin embargo, en esa poca las tcnicas de programacin no reflejaban esto. Lo procedural [procedimientos] fue el paradigma principal de la programacin, el cual define un programa como un algoritmo escrito en algn lenguaje de programacin. Las razones de este nfasis son principalmente histricas.
Fundamentos de Programacin Orientada a Objetos
Pgina 4 Ing. Isis Espinosa Salazar
Desde la poca de su desarrollo, durante los aos cuarenta, las computadoras fueron utilizadas por los matemticos con propsitos militares: el clculo de trayectorias de bombas y la decodificacin de transmisiones hecha por el enemi-go o por diplomticos son algunos ejemplos de estos propsitos. Despus de la segunda guerra mundial, las computa-doras todava eran utilizadas, principalmente, por los matemticos para resolver problemas con su disciplina. Este pa-norama se reflej en el primer lenguaje de programacin de alto nivel comercialmente disponible, el cual se introdujo en 1957. Este lenguaje fue FORTRAN, cuyas siglas son un acrnimo para FORmula TRANslation (traduccin de frmulas).
Un reflejo adicional de este uso predominante es el hecho de que en los aos sesenta casi todos los cursos de compu-
tacin se impartan en los departamentos de ingeniera o matemticas. El trmino de ciencia de la computacin todava no era de uso comn y los departamentos de ciencia de la computacin se encontraban en desarrollo.
Esta situacin sufri un cambio drstico principalmente por dos razones. Una de las desventajas con los programas
orientados a procedimientos es el fracaso de los lenguajes tradicionales basado en procedimientos en proporcionar medios adecuados para limitar el costo del software, lo cual incluye todos los costos asociados al desarrollo inicial del programa y su mantenimiento subsecuente.
La inversin en sofware contribuye en gran medida a los costos totales del proyecto porque estn relacionados direc-
tamente con la productividad humana (son sensibles al esfuerzo laboral), mientras que el costo asociado al hardware se relaciona con la tecnologa de fabricacin. Por ejemplo, los microchips que se adquiran por ms de 500 dlares hace diez aos, ahora se pueden comprar por menos de un dlar.
Es mucho ms fcil, aumentar drsticamente la productividad de fabricacin en un 1000% con la consecuente reduc-
cin en costo del hardware, que los programadores dupliquen la cantidad o la calidad del cdigo que producen. Si bien los costos del hardware se desplomaron, la productividad de software y los costos relacionados con su desarrollo per-manecieron relativamente constantes.
Otra de las desventajas de la programacin basada en procedimientos fue la aparicin de pantallas grficas y el interes
subsecuente en las aplicaciones utilizando ventanas. El acceso a una interfaz grfica de usuarios (GUI) donde un usuario puede moverse con facilidad alrededor de una sola ventana es un desafo cuando se intenta lograrlo con un cdigo procedural. La programacin mltiple y las posibles ventanas que se traslapan en una misma pantalla grfica simplemente aumenta la enorme complejidad cuando se utiliza cdigo procedural.
Las razones anteriores movitaron la bsqueda de nuevas soluciones o mejoras a la programacin mediante procedi-
mientos, lo que condujo a la programacin estructurada.
PROGRAMACION ESTRUCTURADA
Durante la dcada de los sesenta, muchos de los grandes esfuerzos para el desarrollo de software encontraron seve-ras dificultades:
Los tiempos del desarrollo de software generalmente se retrasaban Los costos rebasaban en gran medida a los presupuestos y Los productos terminados no eran confiables
La gente comenz a darse cuenta de que el desarrollo de software era una actividad mucho ms compleja de lo que
haban imaginado. Las actividades de investigacin en la dcada de los sesenta dieron como resultado la evolucin de la programacin mediante procedimientos a la programacin estructurada, un mtodo disciplinado para escribir pro-gramas que son:
Ms claros Fciles de probar y corregir y Ms fciles de modificar que los no estructurados
Estas mejoras de la programacin mediante procedimientos condujeron a nuevos conceptos como son: Estructuras de control, funciones y mdulos.
Estructuras de control
Tal como los arquitectos disean edificios empleando la sabidura colectiva de su profesin, as deberan los progra-madores disear sus programas. Nuestro campo es ms joven que la arquitectura y nuestra sabidura colectiva es considerablemente menor.
Fundamentos de Programacin Orientada a Objetos
Pgina 5 Ing. Isis Espinosa Salazar
Aprendimos que la programacin estructurada produce programas que son ms fciles de entender, probar, corregir, modificar, e incluso comprobar en el sentido matemtico, que los programas que no estn estructurados.
La figura 1.1 utiliza diagramas de actividad (o de flujo) para resumir las estructuras de control. Los estados inicial y final indican la entrada y salida sencillas de cada estructura de control. Conectar de manera arbitraria smbolos individuales en un diagrama de actividad puede provocar que los programas
no estn estructurados. Por lo tanto, la profesin de computacin eligi un conjunto limitado de estructuras de control que se pueden combinar
solamente de dos sencillas maneras para construir programas estructurados.
Figura 1.1. Estructuras de secuencia de entrada sencilla/salida sencilla, seleccin y repeticin de C++.
Por simplicidad, solamente se utilizan estructuras de entrada sencilla /salida sencilla; slo existe una forma de entrar y
una forma de salir de cada estructura de control. Conectar estructuras de control en secuencia para formar programas estructurados es sencillo, el estado final de una
estructura de control se conecta con el estado inicial de la siguiente estructura de control, esto es, las estructuras de control se colocan una sobre la otra en el programa. A esto le llamamos apilar estructuras de control.
Las reglas para formar programas estructurados permiten, adems, anidar estructuras de control. La figura 1.2 muestra las reglas para formar programas estructurados. Adems, las reglas suponen que comenzamos
con el diagrama de actividad ms sencillo (figura 1.3), el cual consiste solamente en un estado inicial, un estado de ac-cin, un estado final y flechas de transicin.
Fundamentos de Programacin Orientada a Objetos
Pgina 6 Ing. Isis Espinosa Salazar
Reglas para formar programas estructurados
1. Comience con el diagrama de actividad ms sencillo (figura 1.3). 2. Cualquier estado de accin se puede reemplazar por dos estados de accin en secuencia. 3. Cualquier estado de accin se puede representar mediante cualquier estructura de control (secuencia, if, if/else,
switch, while, do/while o for). 4. Las reglas 2 y 3 se pueden aplicar con la frecuencia que usted desee, en cualquier orden.
Figura 1.2. Reglas para formar programas estructurados.
Figura 1.3. Diagrama de actividad ms sencillo.
Aplicando las reglas de la figura 1.2 se produce un diagrama de actividad con la apariencia de una cuidadosa cons-truccin con bloques.
Por ejemplo, al aplicar de manera repetida la regla 2 al diagrama de actividad ms sencillo, provoca un diagrama de
actividad que contiene muchos estados de accin en secuencia (figura 1.4). La regla 2 genera una pila de estructuras de control, de manera que llamaremos a la regla 2 la regla del apilado. [Nota: Las lneas verticales punteadas de la figura 1.4 no son parte del UML. Las utilizamos para separar los cuatro
diagramas de actividad que muestran la aplicacin de la regla 2 de la figura 1.2.]
Figura 1.4. Aplicacin repetida de la regla 2 de la figura 1.2 al diagrama de actividad ms sencillo.
La regla 3 se llama regla de anidamiento. Al aplicar de manera repetida la regla 3 al diagrama de actividad ms sencillo, provoca un diagrama de actividad con
estructuras de control anidadas ms pulcras. Por ejemplo, en la figura 1.5 el estado de accin del diagrama de actividad ms sencillo se reemplaza con una estruc-
tura de seleccin doble (if/else). Entonces, la regla 3 se aplica de nuevo a los estados de accin en la estructura de seleccin doble, y reemplaza cada
uno de estos estados de accin con una estructura de seleccin doble. Los smbolos punteados de estados de accin alrededor de cada una de las estructuras de seleccin doble represen-
tan el estado de accin que se reemplaz en el diagrama de actividad ms simple original.
Fundamentos de Programacin Orientada a Objetos
Pgina 7 Ing. Isis Espinosa Salazar
[Nota: Las flechas punteadas y los smbolos de estados de accin punteados que aparecen en la figura 1.5 no son parte del UML. Aqu los utilizamos como ayudas pedaggicas para mostrar que cualquier estado de accin se puede representar mediante una estructura de control].
Figura 1.5. Aplicacin repetida de la regla 3 de la figura 1.2 al diagrama de actividad ms sencillo
La regla 4 genera estructuras anidadas ms grandes, ms involucradas y ms profundas. Los diagramas que surgen de la aplicacin de las reglas de la figura 1.2 constituyen un conjunto de todos los diagra-
mas de actividad posibles y, por lo tanto, el conjunto de todos los posibles programas estructurados. La belleza del mtodo estructurado es que utilizamos slo siete estructuras de control de entrada sencilla/salida senci-
lla y las ensamblamos solamente de dos maneras posibles. Si se siguen las reglas de la figura 1.2, no se puede escribir un diagrama de actividad con sintaxis incorrecta (tal como
el de la figura 1.6). Si no est seguro de si un diagrama en particular es correcto, aplique las reglas de la figura 1.2 a la inversa, para
reducir el diagrama al diagrama de actividad ms sencillo. Si el diagrama se reduce al diagrama de actividad ms sen-cillo, el original est estructurado, de lo contrario, no lo est.
Fundamentos de Programacin Orientada a Objetos
Pgina 8 Ing. Isis Espinosa Salazar
Figura 1.6. Diagrama de actividad con sintaxis no permitida.
Resumiendo
Los resultados de Bohm y Jacopini indican que slo se necesitan tres formas de estructuras de control: Secuencia. Seleccin. Repeticin.
La estructura de secuencia es trivial. Simplemente liste las instrucciones a ejecutar, en el orden en el que se deben ejecutar:
La seleccin se implementa en una de estas tres maneras:
Estructura if (seleccin simple). Estructura if/else (seleccin doble). Estructura switch (seleccin mltiple).
De hecho, es bastante sencillo probar que la estructura if sencilla es suficiente para proporcionar cualquier forma de seleccin, todo lo que se puede hacer con la estructura if/else y la estructura switch se puede implementar mediante la combinacin de estructuras if (aunque quiz no sea tan claro y eficiente).
La repeticin se implementa en una de estas tres formas:
estructura while. estructura do/while. estructura for.
Es sencillo probar que la estructura while es suficiente para proporcionar cualquier forma de repeticin. Todo lo que se puede hacer con una estructura do/while y con la estructura for, se puede hacer con la estructura while (aunque quiz no de manera sencilla).
La combinacin de estos resultados muestra que cualquier forma de control necesaria en un programa en C++ se
puede expresar en trminos de las siguientes estructuras de control:
secuencia. estructura if (seleccin). estructura while (repeticin).
Estas estructuras de control se pueden combinar solamente de dos maneras, apiladas o anidadas. En realidad, la programacin estructurada promueve la simplicidad. La programacin estructurada alienta el uso de abstracciones de control, tales como ciclos, sentencias if-then, que se han incorporado en lenguajes de alto nivel. Estas sentencias de control permitieron a los programadores abstraer las condiciones comunes para cambiar la secuencia de ejecucin.
Nuestro objetivo es explicar cmo crear programas a partir de estructuras de control que contienen estados de accin y
decisin. Veremos a continuacin otra unidad de programacin estructurada llamada funcin. Aprenderemos a crear programas
grandes mediante la combinacin de funciones que, a su vez, estn compuestas por estructuras de control. Tambin explicaremos cmo es que las funciones promueven la reutilizacin del software.
Fundamentos de Programacin Orientada a Objetos
Pgina 9 Ing. Isis Espinosa Salazar
Funciones Las funciones o procedimientos fueron uno de los primeros mecanismos de abstraccin que se utilizaron amplia-
mente en los lenguajes de programacin. Las funciones permiten realizar tareas que se ejecutaban repetidamente, o son ejecutadas con ligeras variaciones,
que se reunen en una entidad y se reutilizan, en lugar de duplicar el cdigo varias veces. Por otra parte, el concepto de funcin proporcion la primera posibilidad de ocultamiento de la informacin. Un pro-
gramador puede escribir un procedimiento o conjunto de procedimientos que utilizan otros programadores. Estos pro-gramadores no necesitaban conocer con exactitud los detalles de la implementacin; slo necesitaban el interfaz ne-cesario.
Sin embargo, las funciones no resuelven todos los problemas. En particular, no es un mecanismo efectivo para ocultar
la informacin, tampoco resuelve el problema que se produce al trabajar mltiples programadores con nombres de procedimientos idnticos.
Para resolver este problema se ha desarrollado un mecanismo de estructuracin diferente.
Mdulos
La modularidad se refiere al proceso de dividir un objeto en piezas ms pequeas, o mdulos, para que algn objetivo sea ms fcil de conseguir. Por ejemplo, se podra dividir un sistema complejo en componentes, de forma que cada componente pueda ser probado de forma individual. Cuando se monta un automvil, sus distintos componentes, tales como el motor, la transmisin y el radio, han sido ya probados individualmente. La modularidad reduce el tiempo para probar el coche y la probabilidad de que un coche sea montado con un defecto.
La mayora de los sistemas complejos son modulares. Estn construidos combinando componentes o paquetes, de
funcionamiento ms sencillo. Una adecuada modularizacin de un sistema complejo tambin ayuda a manejar su complejidad. Dividir las cosas en piezas ms pequeas y ms sencillas de entender hace que un sistema grande sea ms sencillo de comprender.
Como se ver la modularidad es la propiedad de un sistema que permite su descomposicin en un conjunto de mdu-
los cohesivos y dbilmente acoplados. En computacin la modularidad es la propiedad que permite subdividir una aplicacin en partes ms pequeas (lla-
madas mdulos), cada una de ellas debe ser tan independiente como sea posible de la aplicacin en s y de las res-tantes partes.
La modularizacin, como indica Liskov, consiste en dividir un programa en mdulos que se puedan compilar por
separado, pero que tienen conexiones con otros mdulos. Un mdulo es una tcnica que proporciona la posibilidad de dividir sus datos y procedimientos en una parte privada -
slo accesible dentro del mdulo- y parte pblica -accesible fuera del mdulo-. Se pueden definir tipos, datos (variables y procedimientos) en cualquiera de las dos partes.
El criterio a seguir en la construccin de un mdulo es que si no se necesita algn tipo de informacin, no se debe
tener acceso a ella. Este criterio es el ocultamiento de la informacin. Una clasificacin de objetos basada en alguna relacin entre ellos es una jerarqua. Las jerarquas tambin ayudan a
comprender sistemas y organizaciones complejas. La figura 1.7 incluye un diagrama de organizacin de una compa-a tpica. El diagrama muestra la jerarqua de empleados basndose en la relacin de quin informa a quin. La jerar-qua de la compaa ayuda a los empleados a comprender la estructura de su compaa y su relacin dentro de ella.
Fundamentos de Programacin Orientada a Objetos
Pgina 10 Ing. Isis Espinosa Salazar
Figura 1.7. Diagrama de la organizacin de una compaa
Los cientficos han usado esta tcnica desde hace mucho tiempo para identificar y clasificar especies del reino animal
y vegetal. Un orden jerrquico basado en las relaciones de la naturaleza se denomina taxonoma. Tal jerarqua hace que las abstracciones sean ms fciles de entender porque expone la relacin entre caractersticas y comportamientos comunes.
Un concepto importante introducido con la programacin estructurada, ya comentado anteriormente, es el de abstrac-
cin, que se puede definir como la capacidad para examinar algo sin preocuparse de sus datos internos. Una forma de ordenar abstracciones similares, en sistemas complejos compuestos de abstracciones, es ir del concep-
to ms general al menos general. La tcnica top-down, descendente, o refinamiento sucesivo comienza descomponiendo el programa en piezas mane-
jables ms pequeas, conocidas como funciones (subrutinas, subprogramas o procedimientos), que realizan tareas menos complejas.
En un programa estructurado es suficiente conocer que un procedimiento dado realiza una tarea especfica. El cmo
se realiza esta tarea no es importante, sino conocer cmo se utiliza correctamente la funcin y lo que hace.
Figura 1.8. Programa estructurado. Un programa estructurado se construye rompiendo el programa en funciones. Esta divisin permite escribir cdigo ms
claro y mantener el control sobre cada funcin.
Director
Director de ventas
Tesorero Director de investigacin
Director de operaciones
Gerente ventas zona
Gerente de ventas zona
Gerente ventas zona
Gerente ventas zona
Jefe cientfico Gerente de patentes
Desarrollo de lenguajes de
programacin
Desarrollo sistema
Desarrollo de aplicaciones
Investigacin de patentes
Aplicacin de patentes
Funciones
Funcin1 Funcin2 Funcin3 Funcin4
Funcin11 Funcin21 Funcin22 Funcin31 Funcin41 Funcin42
Fun-cin221
Fun-cin311
Fun-cin411
Fundamentos de Programacin Orientada a Objetos
Pgina 11 Ing. Isis Espinosa Salazar
Los mdulos resuelven algunos problemas, pero no todos los problemas del desarrollo de software. Por ejemplo, los mdulos permitirn a nuestros programadores ocultar los detalles de la implementacin de su pila,
pero qu sucede si otros usuarios desean tener dos o ms pilas? Supongamos que un programador ha desarrollado un tipo de dato complejo o (representacin de un nmero comple-
jo) y ha definido las operaciones aritmticas sobre nmeros complejos -suma, resta, multiplicacin y divisin-; asimis-mo ha definido rutinas para convertir nmeros convencionales a complejos. Se presenta un problema: slo puede ma-nipular un nmero complejo. El sistema de nmeros complejos no ser til con esta restriccin, pero es la situacin en que se encuentra el programador con mdulos simples.
Los mdulos proporcionan un mtodo efectivo de ocultamiento de la informacin, pero no permiten realizar instancia-
cin, que es la capacidad de hacer mltiples copias de las zonas de datos.
A medida que la complejidad de un programa crece, tambin crece su independencia de los tipos de datos fundamen-tales que procesa.
En un programa estructurado, las estructuras de datos de un programa son tan importantes como las operaciones realizadas sobre ellas. Esto se hace ms evidente a medida que crece un programa en tamao.
Los tipos de datos se procesan en muchas funciones dentro de un programa estructurado, y cuando se producen cambios en esos tipos de datos, las modificaciones se deben hacer en cada sentencia que acta sobre esos tipos de datos dentro del programa.
Esta tarea puede ser frustrante y consumir un tiempo considerable en programas con millones de lneas de cdigo y miles de funciones.
En un programa estructurado, los datos locales se ocultan dentro de funciones y los datos compartidos se pasan como argumentos (Fig. 1.9).
Accesibles, por cualquier funcin
Accesible slo por funcin A Accesible slo por funcin B
Figura 1.9. Variables globales y locales.
Dado que muchas funciones acceden a los mismos datos, el medio en que se almacenan los datos se hace ms crti-co.
La disposicin de los datos no se puede cambiar sin modificar todas las funciones que accedan a ellos. Si, por ejem-plo, se aaden nuevos datos, se necesitar modificar todas las funciones que accedan a los datos, de modo que ellos puedan tambin acceder a esos elementos.
Variables globales
Funcin A
Funcin B
Variables locales Variables locales
Fundamentos de Programacin Orientada a Objetos
Pgina 12 Ing. Isis Espinosa Salazar
Figura 1.10. Descomposicin de un programa en mdulos (funciones)
Resumiendo
La programacin estructurada se emplea desde el principio de la dcada de los setenta y es uno de los mtodos ms utilizados en el campo de la programacin.
Uno de los resultados ms tangibles de esta investigacin fue el desarrollo del lenguaje de programacin estructurado
Pascal por Niklaus Wirth, en 1971. Pascal, cuyo nombre se debe al aniversario de los setecientos aos del nacimiento del filsofo y matemtico Blas Pascal, fue diseado para la enseanza de la programacin estructurada en ambientes acadmicos; convirtindose en el lenguaje de programacin favorito en varias universidades.
Desafortunadamente, el lenguaje careca de muchas de las caractersticas necesarias para poder utilizarse en aplica-
ciones comerciales, industriales y gubernamentales, de manera que no ha sido muy aceptado fuera de las universida-des.
Desventajas de la programacin estructurada
Los programas basados en funciones son difciles de disear. El problema es que sus componentes principales -funciones y estructuras de datos- no modelan bien el mundo real.
Por ejemplo, supongamos que se est escribiendo un programa para crear los elementos de un interfaz grfico de
usuario: mens, ventanas, cuadros de dilogo, etc. Qu funciones se necesitarn? Qu estructuras de datos? La solucin sera ms aproximada si hubiera una correspondencia lo ms estrecha posible entre los mens y ventanas
y sus correspondientes elementos de programa. Cuando diferentes programadores trabajan en equipo para disear una aplicacin, a cada programador se le asigna la
construccin de un conjunto especfico de funciones y tipos de datos. Dado que los diferentes programadores manipu-lan funciones independientes que relacionan a tipos de datos compartidos mutuamente, los cambios que un programa-dor hace a los datos se deben reflejar en el trabajo del resto del equipo.
Aunque los programas estructurados son ms fciles de disear en grupo, los errores de comunicacin entre miem-
bros de equipos pueden conducir a gastar tiempo en reescrituracin. Por otra parte, los lenguajes tradicionales presentan dificultad en la creacin de nuevos tipos de datos. Los lengua-
jes de programacin tpicamente tienen tipos de datos incorporados: enteros, punto flotante, caracteres, etc. Cmo crear sus propios tipos de datos?
Los tipos definidos por el usuario y la facilidad para crear tipos abstractos de datos en determinados lenguajes es la
propiedad conocida como extensibilidad. Los lenguajes tradicionales normalmente no son extensibles, y eso hace que los programas tradicionales sean ms complejos de escribir y mantener.
En resumen, con los mtodos tradicionales, un programa se divide en dos componentes: procedimientos y datos.
Cada procedimiento acta como una caja negra. Esto es, es un componente que realiza una tarea especfica, tal como convertir un conjunto de nmeros o visualizar una ventana. Este procedimiento permite empaquetar cdigo programa en funciones, pero qu sucede con los datos?
Las estructuras de datos utilizadas en programas son con frecuencia globales o se pasan explcitamente como par-
metros. Una forma para aumentar significativamente la productividad del programador consiste en crear un cdigo que se
Datos globales
Datos globales
Datos globales
Funcin1 Funcin2 Funcin3 Funcin4
Fundamentos de Programacin Orientada a Objetos
Pgina 13 Ing. Isis Espinosa Salazar
pueda reutilizar sin realizar una revisin extensiva y sin volver a probarlo y evaluarlo. La incapacidad del cdigo estruc-turado en base a procedimientos, para proporcionar su reutilizacin condujo a la bsqueda de otros enfoques de soft-ware.
PROGRAMACION ORIENTADA A OBJETOS
Para entender mejor la programacin orientada a objetos, haremos un breve estudio sobre las causas fundamentales que llevaron a cabo la creacin de la misma. Podemos resumir como causas principales las siguientes:
La complejidad inherente al software La crisis del software Los Factores de la calidad del software
La complejidad inherente al software
A medida que las computadoras se han vuelto ms rpidas, baratas y ms potentes, se han convertido en herramien-
tas indispensables para cientficos e ingenieros. Quiz lo ms importante es que se han vuelto parte de nuestra vida. Sin embargo, tener computadoras rpidas y bara-
tas es slo la mitad de la ecuacin. Aunque ha habido tremendos avances en el campo del hardware, no han existido avances de la misma magnitud en el diseo de software.
Parte del problema es que las expectativas para el software han crecido considerablemente. La figura 1.11 muestra lo
que se conoce como paradoja de la complejidad: la complejidad del sistema crece a medida que se intenta hacer ms fcil su uso.
Alta
Complejidad total del software Complejidad Sencillez para el usuario Baja
Figura 1.11. A medida que el software es ms fcil de usar, se incrementa su complejidad interna. Por ejemplo, los primeros sistemas grficos necesitaban que los usuarios especificaran detalles de cmo debera verse
el grfico, dando informacin tan variada como los puntos finales del grfico, la escala, cmo y dnde habra que colo-car las etiquetas.
Esencialmente, el usuario tena que hacer la mayor parte del trabajo. Actualmente las nuevas herramientas para hojas
de clculo contienen sistemas expertos, que analizan los datos y producen un grfico de forma automtica. Tales sis-temas de representacin automtica son mucho ms fciles de usar, pero esta facilidad tiene un precio, el incremento de la complejidad del software.
Se dice que la complejidad del software es una propiedad esencial no accidental (si hay software, hay complejidad!). Esta complejidad se deriva de dos elementos:
La complejidad del dominio del problema La dificultad de gestionar el proceso de desarrollo (la interaccin entre componentes)
Fundamentos de Programacin Orientada a Objetos
Pgina 14 Ing. Isis Espinosa Salazar
La complejidad del dominio del problema
Los problemas a resolver mediante software implican normalmente elementos ineludibles de complejidad, en la que se encuentran una gran cantidad de requisitos, en muchas ocasiones contradictorios.
Esta complejidad se produce por:
Las difciles interacciones entre los usuarios de un sistema y sus desarrolladores.
Los usuarios encuentran generalmente muy difcil precisar sus necesidades de forma que los desarrolladores
puedan comprender. En casos extremos los usuarios suelen tener slo ideas vagas de lo que desean que haga el sistema.
Los usuarios y desarrolladores tienen diferentes perspectivas de la naturaleza del problema y hacen suposicio-
nes diferentes sobre la naturaleza de la solucin. El medio comn de expresar los requisitos hoy en da es utili-zar un gran volumen de textos, en ocasiones acompaados por esquemas y dibujos. Tales documentos son difci-les de comprender, estn abiertos a diferentes interpretaciones y con frecuencia contienen elementos que son di-seos en lugar de requisitos esenciales.
Los requisitos de un sistema de software cambian durante su desarrollo. Esto supone que un sistema grande
tiende a evolucionar con el tiempo y el mantenimiento del software en ocasiones es un trmino que no siempre est bien acuado.
Para ser ms preciso, existen diferentes trminos a definir: El mantenimiento que busca errores; la evolucin
que responde a cambios de requisitos y la conservacin cuando se utilizan medios para mantener piezas de software en funcionamiento. Desgraciadamente, la realidad sugiere que un porcentaje alto de los recursos de de-sarrollo de software se gastan en la conservacin del software.
La dificultad de gestionar el proceso de desarrollo
El tamao de un programa no es una gran virtud en un sistema de software. Sin embargo, la elaboracin de un pro-
grama de gran dimensin requiere la escritura de grandes cantidades de nuevo software y la reutilizacin del software existente.
Recordemos que hace dos o tres dcadas los programas en lenguaje ensamblador se construan a base de centena-
res de lneas. Hoy es usual encontrar sistemas en funcionamiento cuyo tamao se mide en cientos de miles o incluso millones de lneas de cdigo.
Esta caracterstica se facilita descomponiendo nuestras implementacin en centenares y a veces millones de mdulos
independientes. No es inusual que los programas de aplicacin, tales como las hojas de clculo, procesadores de texto y programas de
dibujo, consten de cientos de miles de lneas de cdigo. Otro factor que incrementa la complejidad es la interaccin entre componentes. Por ejemplo, un procesador de texto
puede contener un componente para correccin ortogrfica y otro que proporcione servicios de diccionario de sinni-mos.
Consideremos el corrector ortogrfico. Cuando se detecta un posible error de ortografa, el corrector debe notificarlo al
usuario. Por lo tanto, el corrector ortogrfico, debe relacionarse con el componente de la aplicacin que crea una ven-tana o caja de dilogo, de forma que el posible error pueda mostrarse en pantalla y que se pueda preguntar al usuario acerca de la accin a ejecutar, si se debe hacer algo. Si el usuario est de acuerdo en que hay un error ortogrfico, el corrector puede corregirlo. Para hacer la correccin, el corrector debe interaccionar con el componente del procesador de texto responsable de reemplazar texto en el documento. Obviamente, a medida que el nmero de componentes crece, el nmero de interacciones entre componentes crece rpidamente.
Fundamentos de Programacin Orientada a Objetos
Pgina 15 Ing. Isis Espinosa Salazar
Ingeniera de Software La Ingeniera de Software es el rea de la computacin que tiene que ver con las tcnicas de construccin de softwa-
re de gran tamao. El objetivo de un Ingeniero de Software es producir un software que sea:
Fiable. Comprensible. Rentable. Adaptable. Reutilizable. Examinemos cada una de estas propiedades.
Un software debera ser fiable, es decir, debera funcionar correctamente y sin fallas. Imagine que ha pasado varias horas escribiendo un texto para un curso en un procesador de textos y, cuando lo tiene
casi terminado, el procesador de textos falla de forma inesperada. Se pierde todo su trabajo. Sin duda, estara muy en-fadado y tendra todo el derecho a estarlo.
Aunque la falla de un procesador de textos es molesta, la prdida es insignificante comparada con la prdida potencial
cuando falla un sistema crtico: las vidas humanas. Un sistema de seguridad crtico es aquel en el que una falla podra significar la prdida de una vida humana. Ejem-
plos de este tipo de sistemas son los aviones militares y civiles, las mquinas de terapia radioactiva y los marcapasos. Una falla del software en cualquiera de estos sistemas podra tener consecuencias desastrosas.
Una forma de conseguir que el software sea ms fiable es hacerlo ms fcil de comprender o comprensible. Es
decir, lograr que la operacin y el diseo del sistema sean fcilmente entendibles por otros profesionales del software. La comprensibilidad es muy importante porque los software de gran tamao son construidos por muchas personas
agrupadas en equipos de trabajo. La construccin del software ir mejor y con menos errores si todo el mundo que trabaja en la aplicacin entiende la
operatividad global del sistema y sus componentes. La comprensibilidad es tambin muy importante debido a la larga vida del software. Un producto de software suele
evolucionar con el tiempo y a menudo Ingenieros del Software, que no tienen nada que ver con el producto original, son los que se encargan de introducir mejoras y arreglar los errores del producto.
Este proceso se llama mantenimiento del software. Si la prxima generacin de Ingenieros del Software comprende cmo funciona, las modificaciones de los sistemas complejos, aunque difciles, se podrn llevar a cabo.
Por el contrario, es extremadamente difcil hacer modificaciones o correcciones para un sistema pobremente diseado.
A menudo, es ms econmico reconstruir el sistema desde el principio. Como medida de la dificultad del mantenimiento del software, los expertos estiman que el 67% del costo de desarrollo
del software se dedica al mantenimiento. Este costo puede reducirse cuando el diseo y el funcionamiento del sistema son comprensibles.
Por la discusin previa, se puede ver que un software debera ser rentable. Es decir, el costo de desarrollo y manteni-
miento del software no debera exceder el beneficio esperado por la venta del producto. Muchas compaas de softwa-re han ido a la bancarrota por haber subestimado los costos de desarrollo de un sistema.
Un componente muy relacionado con el costo es el tiempo que se necesita para disear y construir el software. Ser el
primero en introducir un producto en el mercado da a una compaa una decidida ventaja sobre sus competidores. Re-ducir el tiempo para desarrollar un producto puede reducir costos y por lo tanto, incrementar los beneficios.
Debido a la larga vida del software, el software debera ser adaptable. A menudo, es difcil predecir qu caractersticas
y capacidades pueden querer los clientes del software. El mantenimiento adaptativo involucra cambios y aadiduras al software que mejoran la efectividad o competitividad del producto.
Diseando software al que puedan aadir fcilmente en el futuro nuevas caractersticas y capacidades, el Ingeniero del
Software puede reducir los costos de mantenimiento global. Por el alto costo de desarrollo, el software debera ser reutilizable. Si se ha de gastar muchos millones de dlares en
un software, tiene sentido hacer sus componentes flexibles de forma que puedan ser reutilizados cuando se desarrolle
Fundamentos de Programacin Orientada a Objetos
Pgina 16 Ing. Isis Espinosa Salazar
un nuevo sistema. Esta estrategia es ciertamente una prctica frecuente en otros negocios. La reutilizacin puede me-jorar la fiabilidad, reducir los costos de desarrollo y mejorar el mantenimiento.
La cantidad de trabajo que conlleva exige el uso de un equipo de desarrolladores, aunque se trata por todos los me-
dios de que este equipo sea lo ms pequeo posible. Ahora bien, a medida que hay mas desarrolladores, se producen comunicaciones entre ellos mas complejas, e incluso con coordinacin difcil entre ellos, particularmente si el equipo est disperso geogrficamente, como suele ser el caso de proyectos grandes.
La descomposicin de una aplicacin en entidades y relaciones que son significativas a los usuarios es un anlisis
convencional con tcnicas de diseo. Con la programacin orientada a objetos, este proceso de descomposicin se extiende a la fase de implementacin. Es ms fcil disear e implementar aplicaciones orientadas a objetos, ya que los objetos en el dominio de la aplicacin
se corresponden directamente con los objetos en el dominio del software. Los Ingenieros del Software han desarrollado un cierto nmero de principios de diseo que ayudan a llevar a cabo
los objetivos marcados en la seccin anterior gestionando la inevitable complejidad del software de sistemas grandes, estos principios son: Principios de diseo en Ingeniera de Software
Abstraccin. Modularidad. Encapsulamiento u ocultamiento de la informacin.
Estos principios de diseo de la Ingeniera de Software ya han sido tratados en otra parte de estas notas, sin embargo, es conveniente comprender que los tipos abstractos de datos es uno de los conceptos ms interesantes de la abstraccin; el principio de encapsulamiento u ocultamiento de la informacin tiene caractersticas mucho ms poderosas que las que se realizan en la programacin estructurada, aclaremos un poco ms estos conceptos. Un Tipo Abstracto de Dato (TAD) es un tipo de dato definido por el programador que se puede manipular de un modo
similar a los tipos de datos definidos por el sistema. Al igual que los tipos definidos por el sistema, un tipo abstracto de dato corresponde a un conjunto (puede ser de
tamao indefinido) de valores legales de datos y un nmero de operaciones primitivas que se pueden realizar sobre esos valores.
Los usuarios pueden crear variables con valores que estn en el rango de valores legales y pueden operar sobre esos
valores utilizando las operaciones definidas. Por ejemplo, en el caso de una pila se puede definir dicha pila como un tipo abstracto de datos y las operaciones sobre
la pila como las nicas operaciones legales que estn permitidas para ser realizadas sobre instancias de la pila. Los mdulos se utilizan frecuentemente como una tcnica de implementacin para tipos abstractos de datos. El tipo
abstracto de datos es un concepto ms terico. Para construir un tipo abstracto de datos se debe poder:
Exponer una definicin del tipo. Hacer disponible un conjunto de operaciones que se puedan utilizar para manipular instancias de ese
tipo. Proteger los datos asociados con el tipo de modo que slo se pueda actuar sobre ellos con las rutinas
proporcionadas. Permitir instancias mltiples del tipo.
Los mdulos son mecanismos de ocultamiento de informacin y no cumplen bsicamente ms que los apartados 1 y 2. El encapsulamiento u ocultamiento de la informacin, es el proceso de separar los aspectos de un objeto en exter-
nos e internos. Los aspectos externos de un objeto deben ser visibles o conocidos, para otros objetos del sistema. Los aspectos internos son detalles que no deberan afectar a otras partes del sistema. Ocultar ciertos aspectos de un obje-to permite modificarlos sin afectar a otras partes del sistema. Por ejemplo, los aspectos externos del radio de un coche son los controles y los tipos de conexiones necesarios para conectar el radio al sistema elctrico, los altavoces y la an-tena. Los aspectos internos son los detalles del funcionamiento del radio. Para instalar y usar el radio en un coche, no se necesita conocer nada de ingeniera elctrica. Esencialmente, el radio puede verse como una caja negra con boto-nes y cables.
Fundamentos de Programacin Orientada a Objetos
Pgina 17 Ing. Isis Espinosa Salazar
El encapsulamiento es la propiedad que permite asegurar que el contenido de la informacin de un objeto est oculta al mundo exterior: el objeto A no conoce lo que hace el objeto B y viceversa.
El encapsulamiento (tambin se conoce como ocultamiento de la informacin), en esencia, es el proceso de ocultar
todos los secretos de un objeto que no contribuyen a sus caractersticas esenciales. El encapsulamiento permite la divisin de un programa en mdulos. Estos mdulos se implementan mediante clases,
de forma que una clase representa el encapsulamiento de una abstraccin. En la prctica, esto significa que cada clase debe tener dos partes: un interfaz y una implementacin. El interfaz de una clase captura slo su vista externa y la implementacin contiene la representacin de la abstraccin,
as como los mecanismos que realizan el comportamiento deseado. Un gran beneficio del ocultamiento de informacin es que ayuda a hacer cambios en sistemas complejos. Se puede
reemplazar la radio de un coche por un reproductor de CD sin afectar a otros componentes del vehculo. Debido a que el manejo de la radio ha sido encapsulado y su vista externa est definida mediante controles y conectores, se puede quitar el radio viejo, insertar el nuevo y conectarlo.
Cuando se aplica al diseo de sistemas de software, el encapsulamiento permite que se pueda cambiar el comporta-
miento interno de un componente software sin afectar a otros aspectos del sistema. Por ejemplo, si el principio de encapsulamiento ha sido aplicado correctamente a un sistema automtico de correo de
voz, debera ser capaz de cambiar el componente que se encarga de almacenar los mensajes sin afectar a otras par-tes del sistema. Se podra incrementar el nmero de mensajes que un usuario puede almacenar. Si el sistema de al-macenamiento de mensajes ha sido debidamente ocultado y aislado, este cambio no debera afectar a la forma en que los usuarios acceden al sistema y dictan o leen mensajes.
La crisis del software
En 1968 una conferencia sobre software, patrocinada por la OTAN, asumi los trminos ingeniera del software y
crisis del software. Con estos trminos se quera expresar que el software era caro, poco fiable y escaso. Las metodologas y tcnicas estructuradas que han reinado en la dcada de los setenta y ochenta no han eliminado el
problema, de hecho la crisis del software contina hoy en da. Pese a las muchas herramientas y mtodos utilizados, los problemas del diseo descendentes permanecen igual,
posiblemente debido a que la complejidad del problema ha crecido considerablemente. Entre las diferentes fases del ciclo de vida del software (Figura 1.12), el mantenimiento, aunque en otro tiempo fue
despreciada su importancia, se considera actualmente como uno de los problemas ms graves en el desarrollo del software. Muchos investigadores sugieren que los costos del mantenimiento requieren ms de la mitad de los costos y recursos globales del desarrollo total del software.
Figura 1.12. Ciclo de vida del software
Anlisis
Diseo
Implementacin
Depuracin
Mantenimiento
Fundamentos de Programacin Orientada a Objetos
Pgina 18 Ing. Isis Espinosa Salazar
Figura 1.13. Costos de las diferentes fases del ciclo de vida de un proyecto software. Los cambios realizados en la evolucin de un programa son el punto dbil de los mtodos tradicionales de desarrollo
de software, siendo paradjicamente uno de los puntos fuertes de los mtodos de desarrollo de software orientado a objetos.
En 1986, Fredrick P. Brooks, en un famoso artculo, apuntaba que en los ltimos diez aos no se haba producido
ningn progreso significativo en el desarrollo de software, y analizaba crticamente todas las tecnologas ms pro-metedoras. Aunque l confesaba que tena ms confianza en la programacin orientada a objetos que en cualquier otra tecnologa, mantena dudas sobre sus ventajas efectivas.
Recientemente, las propuestas de reusabilidad o reutilizacin, de componentes software, se consideran como bloques iniciales para la construccin del programa, de modo similar a la construccin de cualquier objeto complejo (tal como un automvil) que se construye ensamblando sus partes.
En respuesta al artculo de Brooks, Brad Cox, el inventor de Objective-C, public un artculo en el que esencialmente
rebata las tesis de Brooks:
Existe una bala de plata. Es un arma tremendamente potente, impulsada por vastas fuerzas econmi-cas a la que nuevos obstculos tcnicos slo pueden resistir brevemente. La bala de plata es un cambio cultural en lugar de un cambio tecnolgico. Es un nuevo paradigma; una revolucin industrial basada en partes reutilizables e intercambiables que modificarn el universo del software, de igual modo que la revolucin industrial cambi la fabricacin.
Por consiguiente, la POO (Programacin Orientada a Objetos) no slo son nuevos lenguajes de programacin, sino un nuevo modo de pensar y disear aplicaciones que pueden ayudar a resolver problemas que afectan al desarrollo del software.
Sin embargo, el lenguaje debe ser capaz de soportar el nuevo paradigma, siendo por consiguiente una parte esencial
de esta revolucin.
Diseo 5%
Anlisis 6%
Implementacin7 %
Depuracin15 %
Mantenimiento 67%
Fundamentos de Programacin Orientada a Objetos
Pgina 19 Ing. Isis Espinosa Salazar
Los factores de la calidad del software
La construccin de software de calidad requiere el cumplimiento de numerosas caractersticas. Entre ellas se destacan las siguientes:
Eficiencia La eficiencia del software es su capacidad para hacer un buen uso de los recursos que manipula.
Transportabilidad (portabilidad) La transportabilidad o portabilidad es la facilidad con la que un software puede ser transportado sobre diferentes siste-mas fsicos o lgicos.
Verificabilidad La verificabilidad es facilidad de verificacin de un software; es su capacidad para soportar los procedimientos de valida-cin y de aceptar juegos de pruebas o ensayos de programas.
Integridad La integridad es la capacidad de un software para proteger sus propios componentes contra los procesos que no tengan derecho de acceso.
Fcil de utilizar Un software es fcil de utilizar si se puede comunicar con l de manera cmoda.
Correccin Capacidad de los productos software de realizar exactamente las tareas definidas por su especificacin.
Robustez Capacidad de los productos software de funcionar incluso en situaciones anormales.
Extensibilidad Facilidad que tienen los productos de adaptarse a cambios en su especificacin. Existen dos principios fundamentales pa-ra conseguir esto:
diseo simple descentralizacin
Reutilizacin Capacidad de los productos para ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones.
Compatibilidad Facilidad de los productos para ser combinados con otros.
Fundamentos de Programacin Orientada a Objetos
Pgina 20 Ing. Isis Espinosa Salazar
Para poder enfrentar todos los problemas anteriores, as como cumplir con los requerimientos de Inge-niera de sofware y los factores de calidad, se hace necesario el desarrollo de una nueva forma de pensar y de desarrollar programas, esto se logra con la programacin orientada a objetos.
En un determinado sentido, las tcnicas orientadas a objetos pueden verse como un producto natural de
una larga progresin histrica que va desde las estructuras de control, pasando por las funciones o procedi-mientos, los mdulos, los tipos abstractos de datos y los objetos ( este ltimo concepto se ver ms adelante ).
La dcada de los noventa fu, sin lugar a dudas, la dcada de la programacin orientada a objetos. Como Rentsch
predijo, la programacin orientada a objetos ser en los ochenta lo que la programacin estructurada fue en la dcada de los setenta.
En la actualidad la programacin orientada a objetos se ha hecho enormemente popular. Escritores y diseadores
de software, junto a compaas importantes en el campo del software, se dedican de modo continuo a producir compi-ladores de lenguajes, sistemas operativos, bases de datos, etc., orientados a objetos.
Qu es la programacin orientada a objetos? Por qu es tan popular?
La programacin orientada a objetos es algo ms que una coleccin de lenguajes de programacin, tales como Small-
talk, Object Pascal, C++, etc. Se podra decir que este tipo de programacin es un nuevo modo de pensar sobre lo que significa computar (computarizar), es decir, cmo se puede estructurar informacin en una computadora.
Grady Booch, autor del mto Booch de diseo orientado a objetos muy popular en la dcada de los noventa, creador de la empresa Racional fabricante de la herramienta Rose para ingeniera de software orientada a objetos - e impul-sor del lenguaje unificado de modelado UML, define la programacin orientada a objetos (POO) como:
Un mtodo de implementacin en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representan una
instancia de alguna clase, y cuyas clases son todas miembros de una jerarqua de clases unidas mediante relaciones de herencia. Existen tres importantes partes en la definicin: la programacin orientada a objeteos 1) utiliza objetos, no algoritmos,
como bloques de construccin lgicos (jerarqua de objetos); 2) cada objeto es una instancia de una clase, y 3) las cla-ses se relacionan unas con otras por medio de relaciones de herencia.
Algunos autores de libros an recuerdan la gran frustracin que sentan las empresas de desarrollo de software, espe-cialmente aquellas que desarrollaban proyectos a gran escala, como por ejemplo, el desarrollo de sistemas operativos con tiempo compartido y memoria virtual. La realidad llegaba cuando la empresa decida producir de manera comercial el sistema en el que cientos de personas haban trabajado durante muchos aos. Era difcil poner a punto este softwa-re. El software es un asunto complejo.
Las mejoras a la tecnologa de software comenzaron a aparecer con los beneficios de la denominada programacin
estructurada (y las disciplinas relacionadas como el anlisis y diseo de sistemas estructurados) que se realizaba en la dcada de los setenta.
Pero no fue hasta que la tecnologa de la programacin orientada a objetos se hizo popular en la dcada de los
noventa, que los desarrolladores de software sintieron que tenan las herramientas necesarias para realizar mayores adelantos en el proceso de desarrollo de software.
Antes de la aparicin de los lenguajes orientados a objetos, los lenguajes de programacin (tales como FORTRAN,
Pascal, Basic y C) se basaban en acciones (verbos), en lugar de cosas u objetos (sustantivos). Los programadores, que viven en un mundo de objetos, programan primordialmente mediante el uso de verbos. Este
cambio de paradigma complic la escritura de programas. Ahora, con la disponibilidad de los lenguajes orientados a objetos tales como Java y C++, los programadores siguen viviendo en un mundo orientado a objetos y pueden pro-gramar de una manera orientada a objetos.
ste es un proceso ms natural de programacin y ha dado como resultado un mayor grado de productividad. Un problema fundamental con la programacin basada en procedimientos es que las unidades de programacin no
reflejan de manera fcil y efectiva a las entidades del mundo real; as, estas unidades no son particularmente reutiliza-bles.
Con gran frecuencia los programadores deben comenzar de nuevo cada nuevo proyecto y escribir cdigo similar desde
cero: esto significa gasto de tiempo y de dinero, ya que tiene que reinventar las cosas repetidamente. Mediante la tecnologa de objetos, las entidades de software creadas (llamadas clases), si se disean apropiadamente
tienden a ser mucho ms reutilizables en proyectos futuros.
Fundamentos de Programacin Orientada a Objetos
Pgina 21 Ing. Isis Espinosa Salazar
Con las bibliotecas de componentes reutilizables, tales como la MFC (Microsoft Foundation Classes) y las creadas por Rogue Wave y muchas otras empresas desarrolladoras de software, se puede reducir la cantidad del esfuerzo requeri-do para implementar ciertas clases de sistemas (comparadas con el esfuerzo que se hubiera requerido para reinventar estas capacidades en nuevos proyectos).
Algunas empresas indican que la reutilizacin de software no es, de hecho, el principal beneficio que obtienen de la
programacin orientada a objetos. Ms bien, mencionan que la programacin orientada a objetos tiende a producir software que es ms comprensible, mejor organizado y fcil de mantener, modificar y corregir.
Esto puede ser importante debido a que se estima que el 80% de los costos de software no estn asociados con los esfuerzos originales para el desarrollo de software, estn asociados con la continua evolucin y mantenimiento de ese software durante su vida til.
Cualesquiera que sean los beneficios que se perciban de la programacin orientada a objetos, es claro que sta ser
la metodologa clave de la programacin para las siguientes dcadas. La desventaja es el tiempo y esfuerzos que implica el diseo e implementacin de nuevo cdigo. La orientacin a objetos fuerza a reconsiderar nuestro pensamiento sobre la computacin, sobre lo que significa reali-
zar computacin y sobre cmo se estructura la informacin dentro de la computadora. Jenkins y Glasgow observan que la mayora de los programadores trabajan en un lenguaje y utilizan slo un estilo de
programacin. Ellos programan en un paradigma forzado por el lenguaje que utilizan. Con frecuencia, no se enfrentan a mtodos alternativos de resolucin de un problema, y por consiguiente tienen dificultad en ver la ventaja de elegir un estilo ms apropiado al problema a manejar.
Bobrow y Stefik definen un estilo de programacin como un medio de organizacin de programas sobre la base de
algn modelo conceptual de programacin y un lenguaje apropiado para hacer programas en un estilo claro. Sugieren que existen cuatro clases de estilos de programacin:
Orientados a procedimientos Algoritmos Orientados a objetos Clases y objetos Orientados a lgica Expresado en clculo de predicados Orientados a reglas Reglas If-then
No existe ningn estilo de programacin idneo para todas las clases de programacin. La orientacin a objetos se acopla a la simulacin de situaciones del mundo real.
Qu son los objetos y por qu son tan especiales?
En realidad, la tecnologa de objetos es un esquema de compactacin que permite crear unidades tiles de software. Existen objetos de datos, de tiempo, de cheques, de facturas, de audio, vdeo, de archivo, de registro, y otros ms. De
hecho, casi cualquier sustantivo puede representarse razonablemente como un objeto. Vivimos en un mundo de objetos. Slo mire a su alrededor. Existen automviles, aviones, gente, animales, edificios,
semforos, elevadores, y otras cosas. Desde el enfoque de un TAD, un objeto es, sencillamente, un tipo abstracto de dato al que se aaden importantes
innovaciones en lo referente a compartir cdigo y la reutilizacin. Los objetos son tipos de datos que encapsulan con el mismo nombre estructuras de datos y las operaciones o algoritmos que manipulan esos datos.
Los mecanismos bsicos de orientacin a objetos son: objetos, mensajes y mtodos, clases e instancias, heren-
cia y persistencia.
Una idea fundamental es la comunicacin de los objetos a travs de paso de mensajes. Adems de esta idea se aaden los mecanismos de herencia y polimorfismo. La herencia permite diferentes tipos de datos para compartir el mismo cdigo, permitiendo una reduccin en el tamao
del cdigo y un incremento en la funcionalidad. El polimorfismo permite que un mismo mensaje pueda actuar sobre objetos diferentes y comportarse de modo distinto. La persistencia se refiere a la permanencia de un objeto, esto es, la cantidad de tiempo para el cual se asigna espa-
cio y permanece accesible en la memoria del computador.
Fundamentos de Programacin Orientada a Objetos
Pgina 22 Ing. Isis Espinosa Salazar
Figura 1.9. Principios bsicos de la orientacin a objetos.
Razones fundamentales que estn influyendo en la importancia de la POO
Algunas de las causas que estn influyendo considerablemente en el notable desarrollo de las tcnicas orientadas a objetos son:
La POO (Orientacin a Objetos) es especialmente adecuada para realizar determinadas aplicaciones, sobre todo realizacin de prototipos y programas de simulacin.
Los mecanismos de encapsulamiento de la POO soportan un alto grado de reutilizacin de cdigo, que se incre-
menta por sus mecanismos de herencia. En el entorno de las bases de datos, la POO se adjunta bien a los modelos semnticos de datos para solucionar las
limitaciones de los modelos tradicionales, incluido el modelo relacional. Aumento espectacular de LPOO (Lenguajes de Programacin Orientada a Objetos). Interfaces de usuario grficos (por iconos) y visuales. Los interfaces de usuario de una aplicacin manipulan la
entrada y salida del usuario. Por consiguiente, su funcin principal es la comunicacin con el usuario final. La en-trada al sistema se puede controlar a travs de lneas de rdenes (enfoque utilizado por DOS y UNIX), o alterna-tivamente el usuario puede interactuar con el sistema, con construcciones de programacin visuales, tales como iconos de mens, Windows, Macintosh, etc.
Estas razones hacen fundamentalmente que dentro de las tendencias actuales de la ingeniera de software, el marco
de POO se revela como el ms adecuado para la elaboracin del diseo y desarrollo de aplicaciones. Est marco se caracteriza por la utilizacin del diseo modular OO y la reutilizacin del software. Los TAD (Tipo Abstracto de Dato) han aumentado la capacidad para definir nuevos tipos (clases) de objetos, cuyo
significado se definir abstractamente, sin necesidad de especificar los detalles de implementacin, tales como la es-tructura de datos a utilizar para la representacin de los objetos definidos.
Los objetos pasan a ser los elementos fundamentales en este nuevo marco, en detrimento de los subprogramas que lo
han sido en los marcos tradicionales.
Introduciremos tambin otras unidades de programacin estructurada llamadas clases. Despus, crearemos objetos a partir de clases y procederemos con nuestra explicacin acerca de la programacin orientada a objetos.
Conceptos clave
Abstraccin Encapsulacin Persistencia
Herencia Polimorfismo Genericidad
Entidades bsicas
Objeto Mensajes, Mtodos
Clases, Instancias
Herencia, Jerarqua
Fundamentos de Programacin Orientada a Objetos
Pgina 23 Ing. Isis Espinosa Salazar
1.2 Conceptos fundamentales de la Programacin Orientada a Objetos
Comenzaremos nuestra introduccin a la orientacin a objetos. Veremos que la orientacin a objetos es una manera natural de pensar acerca del mundo real y de escribir programas de cmputo.
En esta seccin introduciremos los conceptos bsicos, es decir, pensar en objetos y la terminologa, es decir, hablar
de objetos. Comenzaremos nuestra introduccin a la programacin orientada a objetos con la terminologa clave de sta. Mire a su alrededor en el mundo real. Por donde quiera que voltee los puede ver, objetos!, gente, animales, plantas,
automviles, edificios, computadoras, etctera. Los humanos pensamos en trminos de objetos. Tenemos la maravillosa habilidad de abstraccin que nos permite
ver imgenes en pantalla como objetos tales como gente, aviones, rboles y montaas, en lugar de puntos individuales de color. Podemos, si lo deseamos, pensar en trminos de playas en vez de granos de arena, bosques en vez de rbo-les y casas en lugar de ladrillos.
Quiz nos inclinemos a dividir los objetos en dos categoras: objetos animados y objetos inanimados. Los objetos
animados estn vivos de alguna manera. Se mueven y hacen cosa. Los objetos inanimados, como las toallas, parecen no hacer nada en absoluto. Parecen que slo estn ah.
Sin embargo, todos los objetos tienen algo en comn, todos tienen atributos, como tamao, forma, color, peso, etcte-
ra, que los describen. Todos exhiben un comportamiento, o realizan operaciones (por ejemplo, una bola rueda, rebota, se infla y se desin-
fla; un beb llora, duerme, gatea, camina y parpadea; un automvil acelera, frena y gira; una toalla absorbe agua, etc-tera) que especifican lo que hacen.
Los humanos aprendemos de los objetos al estudiar sus atributos y al observar su comportamiento. Objetos diferentes pueden tener atributos similares y comportamiento similares. Por ejemplo, se pueden hacer compa-
raciones entre bebs y adulto, y entre humanos y chimpancs. Los automviles, camiones, vagones y patinetas tienen mucho en comn.
La programacin orientada a objetos (POO) toma como modelo a los objetos reales para elaborar su contraparte en
software. Toma ventaja de las relaciones entre clases, en donde objetos de cierta clase, tal como una clase de vehculos, tiene
atributos y operaciones similares. Toma ventaja de las relaciones de herencia e incluso de las relaciones de herencia mltiple, en donde las nuevas
clases de objetos creadas se derivan mediante la absorcin de atributos y operaciones de clases existentes y mediante la adicin de sus propias caractersticas nicas.
Un objeto de la clase convertible ciertamente tiene las caractersticas de la clase ms general automvil, pero el
techo del convertible puede quitarse o ponerse. La programacin orientada a objetos nos brinda una forma natural de ver el proceso de programacin, a saber, me-
diante el modelado de objetos reales, sus atributos y comportamiento. La programacin orientada a objetos proporcio-na tambin comunicacin entre los objetos. Tal como las personas se envan mensajes entre s (por ejemplo, un sar-gento que le ordena a un soldado que se coloque en posicin de firmes), los objetos tambin se comunican mediante mensajes.
La programacin orientada a objetos encapsula datos (atributos) y funciones (operaciones) en paquetes llamados
objetos; los datos y las funciones de un objeto estn ntimamente ligados. Los objetos tienen la propiedad de ocultar informacin. Esto significa que aunque los objetos pueden saber cmo
comunicarse con otros a travs de interfaces bien definidas, por lo general, los objetos no saben cmo se implemen-tan otros objetos, los detalles de implementacin se ocultan dentro de los mismos objetos. Con seguridad, es posible manejar un automvil de manera efectiva sin tener que conocer a fondo los detalles de cmo funcionan internamente los sistemas del motor y la transmisin.
Fundamentos de Programacin Orientada a Objetos
Pgina 24 Ing. Isis Espinosa Salazar
Tambin, veremos por qu el ocultamiento de informacin es crucial para la buena ingeniera de software. En C y otros lenguajes de programacin por procedimientos, la programacin tiende a ser orientada a acciones;
mientras que en C++, la programacin tiende a ser orientada a objetos. En C, la unidad de programacin es la funcin. En C++, la unidad de programacin es la clase, a travs de la cual se
obtienen las instancias. En C++, las clases contienen funciones que implementan el comportamiento y datos que implementan los atributos de
la clase. Los programadores de C se concentran en escribir funciones. Los programadores agrupan acciones dentro de funcio-
nes que realizan alguna tarea comn y agrupan funciones para formar programas. Ciertamente, los datos son importantes en C, pero la idea es que los datos existen primordialmente para apoyar las
acciones que realizan las funciones. Los verbos en una especificacin de sistema ayudan al programador en C a determinar un conjunto de funciones que
trabajan juntas para implementar el sistema. Los programadores en C++ se concentran en crear sus propios tipos definidos por el usuario llamados clases y com-
ponentes. Cada clase contiene datos, as como un conjunto de funciones que manipulan esos datos. En C++, a los componentes de datos de una clase se les llama dato miembro. En C++, a las funciones que componen una clase se les llama funciones miembro (por lo general, en otros lenguajes
de programacin orientados a objetos, como Java, se les denomina mtodos). Tal como a una instancia de un tipo predefinido como int se le llama variable, a una instancia de un tipo definido por el
usuario (es decir, una clase) se le llama objeto. El programador utiliza tipos predefinidos (y otros tipos definidos por el usuario) como bloques de construccin, para
construir tipos definidos por el usuario (clases). El foco de atencin en C++ se centra en las clases (desde las que se crean los objetos) en vez de funciones. Los
sustantivos en una especificacin de sistema ayudan al programador en C++ a determinar el conjunto de clases des-de el que se crean los objetos que trabajan juntos para implementar un sistema.
Las clases son a los objetos lo que los planos son a las casas. Podemos construir muchas casas a partir de un plano, y
podemos crear instancias de muchos objetos a partir de una clase. Adems, las clases pueden tener relacin con otras clases.
Por ejemplo, en el diseo orientado a objetos de un banco, la clase CajeroBanco necesita relacionarse con la clase
CuentaBanco. La ms simple de estas relaciones se denomina asociacin. Veremos que el software empaquetado como clases puede reutilizarse en futuros sistemas de software. A menudo,
grupos de clases relacionadas se empaquetan como componentes reutilizables. La orientacin a objetos puede describirse como el conjunto de disciplinas (ingeniera) que desarrollan y mode-
lan software que facilitan la construccin de sistemas complejos a partir de componentes. El atractivo intuitivo de la orientacin a objetos es que proporciona conceptos y herramientas con las cuales se mo-
dela y representa el mundo real tan fielmente como sea posible. Las ventajas de la orientacin a objetos son muchas en programacin y modelado de datos. Como apuntaban Ledbet-
ter y Cox (1985):
La programacin orientada a objetos permite una representacin ms directa del modelo de mundo real en el cdigo. El resultado es que la radicalmente transformacin normalmente llevada a cabo de los requisitos del sistema (defini-do en trminos de usuario) a la especificacin del sistema (definido en trminos de computadora) se reduce considera-blemente.
Fundamentos de Programacin Orientada a Objetos
Pgina 25 Ing. Isis Espinosa Salazar
La Figura 1.15 ilustra el problema. Utilizando tcnicas convencionales, el cdigo generado para un problema del mun-do real consta de una primera codificacin del problema y, a continuacin, la transformacin del problema en trminos de un lenguaje de computadora Von Newmann.
Las disciplinas y tcnicas orientadas a objetos manipulan la transformacin automticamente, de modo que el volumen de cdigo del problema y la transformacin se minimiza. De hecho, cuando se compara con estilos de programacin convencionales (procedimentales, o por procedimientos), las reducciones de cdigo van desde un 40% hasta un orden de magnitud elevado cuando se adopta un estilo de programacin orientado a objetos.
Transformacin de Von Newmann
Programa
Codificacin del programa
Figura 1.15. Construccin de software Los conceptos y herramientas orientados a objetos son tecnologas que permiten que los problemas del mundo real
sean expresados de modo fcil y natural. Las tcnicas orientadas a objetos proporcionan mejoras y metodologas para construir sistemas de software complejos
a partir de unidades de software modularizado y reutilizable. Se necesita un nuevo enfoque para construir software en la actualidad. Este nuevo enfoque debe ser capaz de mani-
pular tanto sistemas grandes como pequeos y debe crear sistemas fiables que sean flexibles, mantenibles y capaces de evolucionar para cumplir las necesidades de cambio.
La tecnologa orientada a objetos puede cubrir estos cambios y algunos otros ms en el futuro. La orientacin a objetos trata de cumplir las necesidades de los usuarios finales, as como las propias de los desarro-
lladores de productos software. Estas tareas se realizan mediante la modelizacin del mundo real. El soporte funda-mental es el modelo objeto. Las propiedades ms importantes de este modelo son:
Abstraccin Encapsulamiento Modularidad Jerarqua Polimorfismo Otras propiedades: concurrencia (multitarea), persistencia, genericidad, manejo de excepciones.
Como sugiere Booch, si alguno de estos elementos no existe se dice que el modelo no es orientado a objetos.
Como algunos de estos temas ya han sido tratados (abstraccin, encapsulamiento, modularidad, jerarqua ), no lo haremos aqu, salvo que se quisiera agregar algun comentario extra.
Problemas del mundo real
Fundamentos de Programacin Orientada a Objetos
Pgina 26 Ing. Isis Espinosa Salazar
Jerarqua
La jerarqua es una propiedad que permite una ordenacin de las abstracciones. Las dos jerarquas ms importantes de un sistema complejo son: estructura de clases (jerarqua es-un (is-a):
generalizacin/especializacin) y estructura de objetos (jerarqua parte-de (part-of): agregacin). No se debe confundir clases y objetos de la misma clase: un coche rojo y un coche azul no son objetos de clases
diferentes, sino objetos de la misma clase con un atributo diferente. Las jerarquas de generalizacin/especializacin se conocen como herencia. Bsicamente, la herencia define una
relacin entre clases, en donde una clase comparte la estructura o comportamiento definido en una o ms clases (herencia simple y herencia mltiple, respectivamente).
La agregacin es el concepto que permite el agrupamiento fsico de estructuras relacionadas lgicamente. As, un
camin se compone de ruedas, motor, sistema de transmisin y chasis; en consecuencia, camin es una agregacin, y ruedas, motor, transmisin y chasis son agregados de camin.
Polimorfismo
La quinta propiedad significativa de los lenguajes de programacin orientados a objetos es el polimorfismo. Esta
propiedad no suele ser considerada como fundamental en los diferentes modelos de objetos propuestos, pero dada su importancia, no tiene sentido considerar un modelo objeto que no soporte esta propiedad.
Polimorfismo es la propiedad que indica, literalmente, la posibilidad de que una entidad tome muchas formas. En trminos prcticos, el polimorfismo permite referirse a objetos de clases diferentes mediante el mismo elemento
de programa y realizar la misma operacin de diferentes formas, segn sea el objeto que se referencia en ese momen-to.
Por ejemplo, cuando se describe la clase mamferos se puede observar que la operacin comer es una operacin
fundamental en la vida de los mamferos, de modo que cada tipo de mamfero debe poder realizar la operacin o fun-cin comer. Por otra parte, una vaca o una cabra que pastan en un campo, un nio que se come un bombn o cara-melo y un len que devora a otro animal, son diferentes formas que utilizan los distintos mamferos para realizar la misma funcin (comer).
El polimorfismo implica la posibilidad de tomar un objeto de un tipo (mamfero, por ejemplo) e indicarle que ejecute
comer; esta accin se ejecutar de diferente forma, segn sea el objeto mamfero sobre el que se aplica. Clases, herencia y polimorfismo son aspectos claves en la programacin orientada a objetos y se reconocen a estos
elementos como esenciales en la misma. El polimorfismo adquiere su mxima expresin en la derivacin o extensin de clases, es decir, cuando se obtiene
una clase a partir de una clase ya existente, mediante la propiedad de derivacin de clases o herencia. As, por ejemplo, si se dispone de una figura que represente figuras genricas, se puede enviar cualquier mensaje,
tanto a un tipo derivado (elipse, crculo, cuadrado, etc.) como al tipo base. Por ejemplo, una clase figura puede aceptar los mensajes dibujar, borrar y mover. Cualquier tipo derivado de una figura es un tipo de figura y puede recibir el mismo mensaje.
Cuando se enva un mensaje, por ejemplo dibujar, esta tarea ser distinta segn que la clase sea un tringulo, un
cuadrado o una elipse. Esta propiedad es el polimorfismo, que permite que una misma funcin se comporte de dife-rente forma segn sea la clase sobre la que se aplica.
La funcin dibujar se aplica igualmente a un crculo, a un cuadrado o a un tringulo y el objeto ejecutar el cdigo
apropiado dependiendo del tipo especfico. El polimorfismo requiere ligadura tarda o postergada (tambin llamada dinmica), y esto slo se puede producir
en lenguajes de programacin orientados a objetos. Los lenguajes no orientados a objetos soportan ligadura temprana o anterior; esto significa que el compilador genera
una llamada a un nombre especfico de funcin y el enlazador (linker) resuelve la llamada a la direccin absoluta del cdigo que se ha de ejecutar.
Fundamentos de Programacin Orientada a Objetos
Pgina 27 Ing. Isis Espinosa Salazar
En POO, el programa no puede determinar la direccin del cdigo hasta el momento de la ejecucin; para resolver este concepto, los lenguajes orientados a objetos utilizan el concepto de ligadura tarda.
Cuando se enva un mensaje a un objeto, el cdigo que se llama no se determina hasta el momento de la ejecucin. El
compilador asegura que la funcin existe y realiza verificacin de tipos de los argumentos y del valor de retorno, pero no conoce el cdigo exacto a ejecutar.
Para realizar la ligadura tarda, el compilador inserta un segmento especial de cdigo en lugar de la llamada absoluta. Este cdigo calcula la direccin del cuerpo de la funcin para ejecutar en tiempo de ejecucin utilizando informacin
almacenada en el propio objeto. Por consiguiente, cada objeto se puede comportar de modo diferente de acuerdo al contenido de ese puntero. Cuando se enva un mensaje a un objeto, ste sabe qu ha de hacer con ese mensaje.
Otras propiedades
El modelo objeto ideal no slo tiene las propiedades anteriormente citadas, sino que es conveniente que soporte, adems, estas otras propiedades:
Concurrencia (multitarea). Persistencia Genericidad Manejo de excepciones
Algunos lenguajes soportan todas estas propiedades y otros slo algunas de ellas. As, por ejemplo, Ada soporta concurrencia y Ada y C++ soportan genericidad y manejo de excepciones.
La persistencia o propiedad de que las variables -y por extensin los objetos- existan entre las invocaciones de un
programa es posiblemente la propiedad menos implantada en los LPOO, aunque ya es posible considerar la persisten-cia en lenguajes tales como Smalltalk y C++, lo que facilitar el advenimiento de las bases de datos orientadas a obje-tos, como as est sucediendo.
REUTILlZACIN DE SOFTWARE
Cuando se construye un automvil, un edificio o un dispositivo electrnico, se ensamblan una serie de piezas indepen-dientes, de modo que estos componentes se reutilicen, en vez de fabricarlos cada vez que se necesita construir un automvil o un edificio.
En la construccin de software, esta pregunta es continua. Por qu no se utilizan programas ya construidos para
formar programas ms grandes? Es decir, si en electrnica los computadores y sus perifricos se forman esencialmen-te con el ensamblado de circuitos integrados, existe algn mtodo que permita realizar grandes programas a partir de la utilizacin de otros programas ya realizados? Es posible reutilizar estos componentes de software?
Las tcnicas orientadas a objetos proporcionan un mecanismo para construir componentes de software reutilizables
que posteriormente puedan ser interconectados entre s y formar grandes proyectos de software. En los sistemas de programacin tradicionales y en particular en los basados en lenguajes de programacin estructu-
radas (tales como FORTRAN, C, etc.), existen las bibliotecas de funciones, que contienen funciones (o procedimientos, segn el lenguaje) que pueden ser incorporados en diferentes programas.
En sistemas orientados a objetos se pueden construir componentes de software reutilizables, al estilo de las bibliote-
cas de funciones, normalmente denominados bibliotecas de software o paquetes de software reutilizables. Ejemplos de componentes reutilizables comercialmente disponibles son: Turbo Visin de Turbo Pascal, OLE 2.0 de
C++, jerarqua de clases Smalltalk, clases MacApp para desarrollo de interfaces grficos de usuario en Object Pascal, disponibles en Apple, la coleccin de clases de Objective-C, etc.
En el futuro inmediato, los ingenieros de software dispondrn de catlogos de paquetes de software reutilizable, al
igual que sucede con los catlogos de circuitos integrados electrnicos, como les ocurre a los ingenieros de hardware. Las tcnicas orientadas a objetos ofrecen una alternativa de escribir el mismo programa una y otra vez. El programa-
dor orientado a objetos modifica una funcionalidad del programa sustituyendo elementos antiguos u objetos por nuevos objetos, o bien conectando simplemente nuevos objetos en la aplicacin.
Fundamentos de Programacin Orientada a Objetos
Pgina 28 Ing. Isis Espinosa Salazar
La reutilizacin de cdigo en programacin tradicional se puede realizar copiando y editando, mientras que en pro-gramaci
Recommended
![EDUCAÇÃO 2009 - natal.rn.gov.br · eja fund] eja fund] ens. med. fund./ ens. med. fund./ ens. med. fund./ eja ... escola cristo rei faculdade da crianca centro educacional uirapuru](https://img.document.onl/doc/110x75/5c5f01c509d3f2515c8d053f/educacao-2009-natalrngovbr-eja-fund-eja-fund-ens-med-fund-ens.jpg)
