¿Por qué Objetos?

por Alejandro F. Reimondo - Diciembre 2000

Introducción
Este documento pretende resaltar algunos puntos relevantes de la Tecnología de Objetos y su
aplicación en la resolución de sistemas informáticos. No pretende ser una lista completa de las
características de la producción de sistemas de objetos, aunque si incluye los puntos más relevantes
que distinguen al software de este tipo.

Consta de una presentación cronológica de las "alternativas" tecnológicas actuales, una definición
de que es un sistema de objetos virtuales, algunos puntos referentes a las características de un
sistema construido con objetos, algunas reflexiones sobre el futuro, un estudio PNI del uso de la
tecnología y por último un conjunto de referencias a material complementario.

La información contenida en este documento puede ser utilizada libremente, siempre y cuando se
haga referencia al autor de manera clara y explícita (nombre y dirección de correo electrónico).

Referencia histórica

Paradigma tradicional
La tecnología utilizada tradicionalmente para construir software está basada en un conjunto de
elementos básicos bien conocidos actualmente, como lo son el Dato y el Programa. Un programa
puede activarse sobre un conjunto de datos (input) para producir un conjunto de datos de resultado
(output). Esta activación del programa requiere de un determinado tiempo donde se realiza un trabajo
(termodinámico) sobre los datos. A esta actividad se la denomina proceso.

Este principio tan simple y elegante sirve para definir cualquier actividad (trabajo) realizada por
una máquina. Este principio puede ser extendido al asociar varias máquinas para formar una máquina
compuesta. De esta manera, acoplando máquinas y "encapsulando" en éstas tareas específicas se
logra resolver problemáticas complejas.

Herramientas y técnicas tradicionales

Este paradigma tradicional es simple porque se basa en el concepto de que el dato es pasivo y
existe para ser manipulado por un programa durante el desarrollo de un proceso. Así mismo, el
programa posee la inteligencia acerca de cómo manipular los datos.

Bajo este enfoque, el computador provee un soporte para la ejecución de procesos informáticos y
la labor humana consiste en definir los objetivos del programa y cómo lo hace, y procurar la existencia
de los datos necesarios (iniciales) para la activación del proceso.

Página 1
 Los datos iniciales pueden ser construidos manualmente o como resultado de la activación de
otros procesos preliminares.

Para la definición de los objetivos del programa y su forma de resolución se utiliza un lenguaje de
programación que sirve de nexo entre la parte humana y la máquina. Los lenguajes de programación
están definidos tratando de ser universales. Innumerables alternativas en lenguajes de programación
se han utilizado en las últimas décadas.

La crisis del software

El mayor condicionamiento que sufre el paradigma tradicional es consecuencia de su punto más

fuerte, la simpleza. El dato no puede "hacer" pues solo es sustrato sobre el que actúa un programa.
Un programa requiere de un esfuerzo enorme a medida que se requiere de más procesos en
sistemas no triviales.

La variedad presente en los sistemas de hoy en día (y de hace 20 años) revela claramente que
esta estructura "simple" y tradicional no es adecuada para soportar variedad o cambios constantes.
La extrapolación acostumbrada "un proceso grande es la suma de procesos pequeños" adolece del
mismo defecto conceptual que las leyes gravitatorias de Newton.

Este paradigma tradicional alcanzó sólo cuando los computadores eran tan pequeños como para
poder ser expresados en términos de las leyes básicas de la matemática y los lenguajes. Al crecer las
expectativas respecto de lo que puede hacer un sistema informático, ocurrió el nacimiento de lo que
se denominara la crisis del software, en la que no era suficiente la mano de obra en informática como
para mantener todos los programas existentes.

La parametrización
La primera alternativa que se ensayó para salir de la denominada crisis del software fue la
parametrización de los sistemas. Se trató de ubicar en datos externos al programa el conjunto de
alternativas posibles para que durante la ejecución del proceso se determine que política utilizar para
resolver un problema. Esta técnica no alcanzó a cubrir siquiera las necesidades inmediatas.

La Modularización
Comenzando con Pascal allá por la década del '60 comenzó a definirse una alternativa a la
parametrización que estaba basada en encapsular comportamiento en módulos de inteligencia. El
advenimiento de lenguajes como Modula II y Ada, el los '70, fueron muy promisorios y parecieron ser
la solución "definitiva" para la construcción de sistemas de software "grande". En estos lenguajes, se
logró agrupar funciones aplicables a conjuntos de datos similares (estructuralmente equivalentes) y
de esta manera poder usar estas funciones como mini-programas existentes en una librería de
programas.

Página 2
Encapsulamiento de comportamiento
Estos módulos permitían encapsular un conjunto de funciones aplicables a datos equivalentes;
pero los datos seguían siendo pasivos y se necesitaba un programa que los "entendiera".

Los Componentes
Una pequeña mejora a esto lo plantearon nuevas alternativas en las que los datos, además hacían
de librerías de funciones; facilitando así el acceso a estas por estar íntimamente ligadas a la
estructura del dato. Así fue planteado que un dato unido a su comportamiento podía ser utilizado
como piedra fundamental de una obra de software.

Esto dio lugar a nuevas extrapolaciones, ahora no con datos y programas, sino con los que se
denominan componentes, los cuales son los ladrillos con los que se construye la "arquitectura de un
sistema informático"; dando lugar entonces a la denominada "Ingeniería de Software".

Resulta que, planteado de esta manera, la construcción de software parece ser un área de la
ingeniería (ingeniería de sistemas). Y parece además que una obra de software podría ser vista como
una "arquitectura" lograda por asociación de piezas más pequeñas denominadas componentes.

Mas allá de ser esto interesante o no, los resultados de aplicar componentes para construir
software son bastante pobres y con el pasar de los años se ha hecho cada vez más evidente que
nuevamente se ha cometido el error de extrapolar técnicas y herramientas útiles en contextos simples
pensando que serán igualmente útiles en sistemas de otras magnitudes o con una cinética muy
marcada. Nuevamente vemos cometerse el mismo error que hace casi 30 años, pensando que un
sistema grande es la suma de sistemas pequeños (componentes).

Lenguajes y Herramientas
Es sorprendente como con el pasar de los años la gente puede cambiar de herramientas, pero no
se plantea si la herramienta es válida. [Cuando tenemos un martillo, todo lo que vemos son clavos]

Han pasado ya 50 años donde se vienen usando lenguajes de programación y programas. Se ha

tratado de alterar los datos para que tengan programas asociados, pero nunca se ha planteado
(masivamente) la validez del uso de un lenguaje de programación universal. Tampoco se ha objetado
(masivamente) la forma de producir software ni los ciclos de producción. Tampoco se ha objetado la
validez de la idea de "programa".

Solo vemos que, con el pasar de los años, el producir software es más costoso; más difícil es
mantenerlo y cada vez es más reducida su vida útil.

La segunda crisis del software

O la confirmación de que la primera crisis no se resolvió…

Con la popularidad de los equipos personales aparece nuevamente la crisis en informática,

aunque esta vez ya no se le presta tanta atención (la relación hombre-computador esta muy venida a
menos) pues la existencia de un medio como Internet requiere de soluciones menos comprometidas

Página 3
con informática (y más con el área de negocios) dando más tiempo para madurar las técnicas en la
construcción de sistemas.

Los sistemas informáticos no son materia de las ciencias exactas. Esta vulgarización de la
informática permite, entre otras cosas, contar con más tiempo para promover cambios más profundos
en los profesionales de informática.

Un cambio paradigmático es muy profundo y requiere de mucho esfuerzo para ser adoptado
globalmente. Es profundo y requiere de tiempo, por ser un cambio tecnológico. Es inocente pensar
que un cambio tecnológico se puede realizar por medio de la difusión de material escrito o por
transferencia horizontal. Todo cambio tecnológico requiere de la condensación de experiencias
fundamentales en el área de la nueva tecnología. Así es como en el caso de la informática, requerirá
bastante tiempo el adoptar una nueva tecnología que resuelva el problema actual.

En las últimas décadas se han ensayado varias alternativas tecnológicas y hoy ya se observa
claramente la dirección más prometedora: la Tecnología de Objetos.

La difusión de lo "orientado" a objetos

Debido al costo de implantar una nueva tecnología a nivel masivo, hoy se pueden observar
alternativas menos ambiciosas aunque muy difundidas globalmente. La "orientación a objetos" es un
conjunto de técnicas de la nueva tecnología de objetos adaptadas a las técnicas tradicionales. Esto
permite ir cambiando gradualmente, pero a costos muchos más altos.

La gran ventaja de las "técnicas orientadas a objetos" es que no requieren de experiencia real con
objetos; sino que solo requieren una rudimentaria capacitación en nuevas herramientas. Esto permite
una propagación horizontal de las herramientas y una gran oportunidad de marketing; aunque
producen además que mucha gente interesada en resolver sus problemas en la producción de
software se confunda al pensar que esta haciendo un cambio tecnológico o que esta ganando
experiencia en el trabajo con objetos.

Las modas en informática

Un hecho inobjetable que nos muestra la poca ambición de las alternativas "orientadas a objetos"
es la fácil proliferación de herramientas "novedosas" que son obsoletas rápidamente.

Las modas y el cambio vertiginoso es un indicador noble de desorden. La rápida difusión de

lenguajes orientados a objetos y herramientas novedosas demuestran además el poco valor
agregado que aportan, pues al ser de propagación horizontal, no requieren de experiencia real para
ser adoptadas. "Hoy en día, todo sale orientado a objetos" Es una realidad que la gente ya no
entiende que diferencia hay entre moda y tecnología; hecho agravado con la posibilidad de difusión
que permite un medio como Internet.

Definición de la Tecnología de Objetos

Página 4
Tecnología de Objetos
La tecnología para el desarrollo de sistemas de información con objetos, parte del principio
paradigmático que asevera que toda unidad informática se caracteriza por ser única y acotada, esta
unidad se denomina "objeto informático". El principio de unicidad permite tratar a cada objeto
informático con un carácter único en el espacio que lo contiene.

Los limites que tiene un objeto informático permite hacer analogías con los objeto reales
(corpusculares); y gracias a esto permite el uso de herramientas de conceptualización básicas como
la focalización, manipulación e introspección e incluso reflexión.

El conjunto de objetos informáticos define un espacio informático denominado también "Ambiente

de Objetos". Un Ambiente de Objetos define los límites accesibles a los objetos que contiene. Uno o
más sistemas informáticos pueden estar contenidos en un Ambiente de Objetos. Los límites de un
Ambiente de Objetos vienen dados por la capacidad de actuar que tienen los objetos contenidos en
este.

Es importante resaltar que los objetos contenidos en un Ambiente pueden o no ser objetos físicos
reales. A los objetos informáticos que no tienen representación real se los denomina objetos virtuales
(o virtualizados en caso de referir a objetos del espacio real). La Tecnología de Objetos es el conjunto
de herramientas y técnicas que permiten trabajar sobre objetos contenidos en un Ambiente.

La comunicación entre objetos se realiza por medio de diálogos formulados por el envío de
mensajes en el lenguaje definido por los objetos que intervienen en este intercambio. Un mensaje
tiene el objetivo de alterar el comportamiento de un objeto y está en la naturaleza del objeto que
recibe el mensaje la reacción que pueda desencadenar dicho envío de mensaje.

En el paradigma de objetos no es necesario el concepto de programa, pues cada objeto tiene una
razón de ser para el ambiente que lo contiene y su comportamiento viene dado por su naturaleza.

En el trabajo en Ambientes de Objetos la tarea de construcción de sistemas esta gobernada por

técnicas de carácter evolutivo. La concreción de un sistema de información es el resultado de una
evolución del ambiente hasta alcanzar el grado de satisfacción y estabilidad necesario.

En el paradigma de objetos se define solo lo que es un objeto. Esto parece dejar de lado la
inteligencia (que antes era cubierta por el "programa"), aunque si reflexionamos un poco nos daremos
cuenta que la "inteligencia de un sistema" es parte de su esencia y no debe estar fuera de este, sino
más bien ser su sustento. En la Tecnología de Objetos, el comportamiento de un objeto es también
un objeto. Es decir, si un objeto sabe comportarse de una manera, es porque posee en su naturaleza
ese conocimiento. Este conocimiento también es un objeto y puede ser compartido, por ejemplo, por
objetos de la misma especie.

En el trabajo con objetos se acostumbra a clasificar los objetos por su especie y así es como hay
en los ambientes objetos (denominados clases o especies) que contienen el comportamiento
conocido por los objetos de una determinada especie (clase).

Esta facilidad de permitir la manipulación de la inteligencia (comportamiento) de un sistema por el

sistema mismo permite construir sistemas evolutivos y que crecen por interacción constante con
entrenadores humanos.

Aquí el rol del humano ya no es el de la definición de las tareas (o rutinas) de un sistema, sino que
es una tarea más constructiva (construcción de objetos) y centrada en la manipulación y evolución del
sistema en si mismo, expresado en el lenguaje del sistema y no en un lenguaje "universal". El

Página 5
programador (palabra quizás inapropiada aquí) se encuentra trabajando EN el sistema y ya no es
quien solo lo define y traduce al lenguaje de programación. Aprender a trabajar con objetos es
aprender técnicas de evolución incremental de sistemas de objetos; técnicas que son más
fundamentales que las de la programación tradicional y que son aplicables no sólo a los objetos
virtuales, sino que pueden aplicarse a los sistemas de información evolutivos en general.

"Orientación" a Objetos
En la bibliografía y revistas técnicas abundan las referencias a la "Programación Orientada a
Objetos" y a los "Lenguajes Orientados a Objetos" a tal punto que es común que la gente no preste
atención a la palabra "Orientado" o que no note diferencias cuando uno habla de "Tecnología DE
Objetos".

Hoy ocurre lo mismo que en los '80 cuando se hablaba de módulos, componentes, y programación
estructurada; solo un pequeño grupo de profesionales construían arquitecturas del software. Hoy se
habla de objetos, pero nadie en realidad usa objetos, solo piensan orientado a objetos y en el mejor
de los casos logran tener las ventajas del trabajo modular con componentes de software.

Incluso existe mucha bibliografía incluso técnicas que promueven el "modelado" con objetos y
proponen el uso de papel o dibujos (estáticos) para definir un sistema. Este tipo de técnicas
orientadas a objetos no son recomendables para la construcción de sistemas evolutivos o de bajo
costo de mantenimiento.

Las técnicas acostumbradas de trabajo orientado a objetos están fuertemente condicionadas por
las herramientas tradicionales de producción de software y principalmente basadas en el concepto de
que el software puede ser definido antes de ser "vivido". Por lo general tienen como último fin la
construcción de una arquitectura donde sus piezas son intercambiables dinámicamente gracias a
conectores sintácticos, denominados interfaces. Este razonamiento es simplista y hace aguas
rápidamente al ganar magnitud el sistema "modelado". El principal defecto, lo no planificado no esta
encapsulado (por naturaleza); y rompe con la arquitectura planificada.

¿Qué es un objeto?
Un objeto es una pieza de software única. Las habilidades (comportamiento) que tiene un objeto
dependen de su especie y ésta, al ser un objeto más, puede cambiar mientras el sistema esta en
funcionamiento.

Uno podría asegurar que en un instante dado de la vida del sistema, un objeto tiene una interfaz,
pero nadie puede garantizar que esta se mantenga constante con el paso del tiempo. Es decir, un
sistema de objetos puede desarrollar o absorber (en su funcionamiento) nuevo comportamiento
expresado por un operador humano o por un objeto cualquiera del sistema. En los sistemas de
objetos es posible que un objeto aprenda nuevos comportamientos según sus experiencias. El
desarrollo del sistema es un caso en particular donde el comportamiento es aportado por agentes
humanos.

En un sistema de objetos existen las mismas garantías que en un sistema tradicional u orientado a
objetos, pero además permite generar cambios y experimentar evoluciones mientras el sistema esta
funcionando.

Página 6
Ambientes de Objetos
Para desarrollar con objetos es necesario tener un lugar que sirva de soporte a los objetos
informáticos que compondrán el sistema. No es apropiado empezar a construir el sistema desde cero,
es decir, desde el Big Bang.

Normalmente se parte de un Ambiente de Objetos existente y se construyen dentro de este

objetos que resuelven la problemática del sistema informático específico de nuestro dominio. El
ambiente de objetos de uso comercial más utilizado se denomina Smalltalk, que cuenta con 27 años
de antigüedad. El primer Smalltalk fue construido entre los años 1972 y 1976, desde entonces, este
ambiente viene evolucionando, cambiando de soporte de hardware y sistemas operativos hasta
nuestros días. Esto permitió la maduración de objetos y herramientas para permitir construir sistemas
de información evolutivos, y que permitan cambios de comportamiento a bajo costo.

El solo uso de un Ambiente de objetos no garantiza la buena construcción de un sistema

informático, sino que además en necesaria experticia en el uso de las nuevas herramientas y en la
creación de sistemas evolutivos. Esta es una de las razones por las que no se utiliza Smalltalk
masivamente, pues requiere de un aprendizaje vertical, basado en la adquisición de experiencia en la
nueva tecnología no bastando aprender una sintaxis o el uso de las opciones de los menúes de una
herramienta.

¿Qué es un sistema de objetos?

Un sistema de objetos es entonces un conjunto de objetos que se relacionan generando un
ambiente estable, el cual realiza un trabajo (producto de la naturaleza de los objetos contenidos, y no
por la definición formal de sus atributos o funciones). El comportamiento es también un objeto,
permitiendo la denominada Metaprogramación (programación de la programación) y reflexión del
sistema en si mismo.

Evolución en sistemas de información

Un sistema que puede expresar su comportamiento en el mismo permite evolución si pueden
generarse alteraciones a dicho conocimiento mientras el sistema esta en funcionamiento.

Para ello se utiliza normalmente a seres humanos que condensan sus experiencias en el sistema
por medio de cambios en su comportamiento. Ocasionalmente, ocurre que el sistema mismo puede
generar el comportamiento faltante a medida que lo necesita. En estos casos ocurre que un objeto
puede "programar" a otro o incluso programarse a si mismo. El caso en que un sistema se auto-
programe no es muy común, pero es importante que esto pueda hacerse cuando sea posible.

El hecho que el comportamiento sea un objeto es útil en el caso de requerir mudar

comportamiento de un puesto de trabajo a otro. A modo de ejemplo, podemos comentar que es
posible generar comportamiento en un Ambiente (por ejemplo un puesto de desarrollo en una ciudad)
e inyectarlo en otro Ambiente (por ejemplo, un puesto de trabajo en otra ciudad) sin tener que detener
el funcionamiento del sistema en ningún puesto. Esto permite mantener servidores de objetos
distribuidos físicamente e incluso migrar objetos con su comportamiento de manera "transparente", es
decir, sin requerir cambios de programación o paradas de los sistemas.

Página 7
¿Cómo distinguir si un software NO es con objetos?
• Si el proveedor dice que el software fue escrito utilizando un "lenguaje de programación" (por
ejemplo C++ o Java) y no un Ambiente de Objetos (Smalltalk, LOOPS, Objective C), es
posible que no conozca la diferencia entre "orientado a" y "de" objetos.

• Si un cambio de programación o de estructura de los objetos del sistema requiere de la

parada del sistema o de demoras excesivas. A modo de ejemplo, si el sistema maneja
objetos que requieren de una propiedad y comportamiento nuevos y hay 1.000.000 de estos
objetos. Si al hacer el cambio hay que esperar más de 5 segundos, probablemente el sistema
no sea evolutivo y no ha sido construido con objetos (o al menos no eficientemente).

• Si no se puede saber al instante cuantos objetos de una especie (clase) cualquiera hay en el
sistema.

• Si requiere de cambios importantes en la programación para hacerlo distribuido o persistente

en medios magnéticos.

• Si requiere de lenguajes extraños al dominio del sistema (por ejemplo, SQL o algún lenguaje
de scripting que no sea del mismo sistema)

Características de su aplicación
• Sistemas flexibles y evolutivos.

• Sistemas distribuidos o fácilmente distribuibles.

• Sistemas fácilmente extensibles,… solo agregando nuevos objetos.

• Sistemas entendibles por una persona experta en el domino del sistema (sintaxis del dominio
y no en un lenguaje extraño de programación).

• Son sistemas que no acostumbran a colapsar ni a dejar memoria sin uso alocada; por la
características con las que se los construye, no pueden existir errores graves porque son
sistemas "vividos"

Uso y Re-uso
Los componentes permiten el uso de estos componentes varias veces sin modificación.
Normalmente esto es llamado re-uso. Pero es inapropiado llamar re-uso al uso reiterado de cualquier
pieza (de software o no) pues el usar una cosa muchas veces es "usarla", y no "re-usarla". Re-uso es
otra cosa… Si no fuera así, solo necesitaríamos la palabra uso. Re-uso es el resultado de tomar una
cosa, refinarla y luego usar el resultado de ese refinamiento.

En los Ambientes de Objetos es común tomar la especie (clase) de un objeto, obtener una nueva
especie a partir de esta refinándola de manera tal que al utilizar esta nueva especie para crear
objetos, produzcan objetos más aptos para un domino dado (etapa básica de la evolución). En el
trabajo con ambientes de objeto es muy común el refinar conceptos más básicos (viejos) para obtener
diferencias más aptas para un contexto especifico. Esta actividad se denomina refinamiento y
factorización.

Página 8
Nuevas alternativas implican nuevos objetos
En el desarrollo de sistemas con objetos, las nuevas alternativas (naturalezas) que se conocen
requieren de nuevos objetos y no de cambios en el sistema existentes. Esto permite el crecimiento del
sistema con menos costos de mantenimiento.

A sistemas más grandes menos código

A medida que un sistema de objetos crece, es más probable que ya existan objetos útiles para
realizar las nuevas tareas que se requieran, por lo que a medida que el sistema crece, la cantidad de
trabajo necesaria para lograr novedades disminuye.

Uno de los pilares más importantes de la Tecnología de Objetos es que se focaliza la atención en
con qué se hacen las cosas y no en qué se hace. En la realidad uno realiza diferentes cosas día a
día… pero con las mismas cosas.

A modo de ejemplo, uno puede usar un lápiz y papel para muchas cosas tan variadas como para
hacer una cuenta o una carta de amor. Así, si programamos un lápiz y un papel, el sistema puede ser
utilizado para muchas más cosas que si lo hacemos para que haga cuentas. Nuevamente, esto se
logra luego de ganar experiencia en el trabajo con objetos. Lo importante es que pueda hacerse
realidad.

Transparencia de soluciones
La tecnología de objetos permite generar cambios de comportamiento sin requerir reprogramación
en muchos casos, solo cambiando objetos pueden lograrse efectos muy valiosos.

Distribución de objetos
En Smalltalk la distribución de sistemas puede lograrse sin esfuerzo y a veces sin requerir
programación alguna. La existencia de soluciones robustas y antiguas (amplio uso) permiten resolver
el problema de la distribución de sistemas de una manera transparente y elegante. En el caso de
requerir interacción con sistemas tradicionales pueden utilizarse soluciones basadas en CORBA.

Persistencia de objetos
En el caso de utilizar una base de objetos, el comportamiento de los objetos se almacena en la
misma base de datos. Además la persistencia de los objetos es automática, solo por estar en la base.
El almacenamiento como la liberación de recursos necesarios es dinámica y no requiere de
programación alguna. En ese caso no se requiere de un lenguaje adicional para la base, sino que se
utiliza el mismo lenguaje de los objetos.

Página 9
 No se requiere de ningún cambio para que un objeto sea almacenado, pues los servidores de la
base de datos de objetos proveen de Ambientes virtuales que funcionan directamente sobre medios
magnéticos. Si un objeto es alojado en un servidor, "vivirá" en este espacio mientras sea útil y luego
desaparecerá solo con el tiempo cuando no sea necesario su almacenamiento. Esto sin requerir
programación alguna.

Migración y movilidad de soluciones

Hay muchas alternativas de Smalltalk y cada una tiene ventajas particulares para un tipo de
aplicación. En algunos casos el ambiente de objetos es independiente de la plataforma e incluso
puede ser utilizado en varias plataformas sin requerir reprogramación (ni siquiera recompilación). El
ambiente es completamente portable, no solo el comportamiento (las clases) sino también los objetos
del sistema mismo. Si uno detiene la ejecución de un sistema Smalltalk con algunos objetos
realizando algunas tareas y luego lo rearranca en otro sistema operativo, estos objetos seguirán
funcionando sin sorpresas ni reprogramación.

La información lleva su comportamiento

En los sistemas de objetos, no puede existir un objeto si no esta antes su comportamiento, así es
como un objeto informático lleva consigo toda su naturaleza.

Medios de interacción con un sistema de objetos

Un ambiente define los límites de un sistema de objetos, aunque es común extender estos límites
gracias a los que se conocen como interfaces de interacción. La interfaz de usuario es un canal de
interacción que hace a un sistema de objetos "abierto" (a nivel informático).

Servidor de objetos
Un ambiente de objetos puede tener canales de interacción con otros ambientes y/o sistemas
tradicionales adicionales a la interfaz de usuario. En esencia, todo sistema de objetos es un "servidor
de objetos" si tiene alguna forma de permitir el acceso a sistemas externos a los objetos que
contiene.

Dominio sobre lo producido

En un Ambiente de Objetos todo es un objeto, por lo que uno, como desarrollador tiene dominio
sobre cualquier parte del sistema.

Actualmente las técnicas del uso de componentes no solo producen fragilidad y rigidez en un
sistema, sino que además producen perdida importante de dominio sobre la solución que se
implementa. Esto se ha querido subsanar haciendo a los componentes open-source, pero cada vez
se esta más lejos de la aplicación de esta política, por ser además insuficiente, porque las técnicas de
componentes no aseguran homogeneidad en la forma de resolver problemáticas, resultando esto en
un alto costo de mantenimiento de software concebido como componentes aunque se tengan los
fuentes (el alto costo es además engrosado por el uso de tecnología tradicionales en la

Página 10
implementación de los componentes, como Basic o herramientas poco ambiciosas e inmaduras,
como Java).

OpenSource
Los ambientes Smalltalk tienen un porcentaje mayor al 99% expresado en Smalltalk con los
fuentes. Estos objetos son enteramente modificables, pudiendo producirse así ambientes muy
diferentes al de partida.

Objetos como bienes de uso

Los objetos de un sistema son bienes de uso. En un Ambiente de objetos, los expertos (tanto de
informática como del dominio del sistema) conviven con el ambiente día a día, logrando así un
sistema "vivido". Las características de las técnicas utilizadas garantizan la estabilidad del sistema, no
por la rigidez en su definición sino por la estabilidad lograda de manera evolutiva. Esta estabilidad es
más robusta (no requiere de grandes pensadores, solo de vivencias) no condicionando esto la
capacidad de alteración frente a un cambio del sistema.

¿Qué vendrá después?

Smalltalk es un Ambiente de Objetos que esta evolucionando desde hace 27 años. Esto indica que
en los Smalltalks que encontraremos hoy hay aun objetos que se originaron en aquel entonces (por
ejemplo hay un objeto que es un lápiz y se llama Turtle, idéntico a la tortuga de Logo, de aquellas
épocas; este objeto, es conceptualmente el mismo que nació en aquel entonces, aunque hoy ha
cambiado ya varias veces de implementación y sistemas operativos; claro, siempre "siendo" el mismo
objeto).

Smalltalk es un Ambiente de Objetos, es decir, un lugar donde hay cosas (objetos virtuales). ¿Que
sería algo mejor que un lugar donde hay cosas? Un lugar donde hay cosas mejores… Lo que seguiría
siendo un lugar donde hay cosas. Es decir, seguiría siendo un Smalltalk. Así ha sido durante más de
25 años.

Uso de la Tecnología de Objetos

Puntos Positivos de utilizar la T.O.

• Producen una diferencia tecnológica importante.

• Herramienta competitiva real que nos distingue del vecino "que leyó un librito y habla".

• Valorizan el software producido por lo que se produce y no por la herramienta (lenguaje, tools
o modas) con que se los hace.

• Permite realizar proyectos más ambiciosos.

Página 11
 • Permite aprender la naturaleza del sistema que se esta produciendo a medida que se lo
construye y usa día a día.

• Permite construir sistemas estables y evolutivos.

Puntos Negativos de utilizar la T.O.

• Requiere de al menos un experto para guiar al grupo.

• Requiere de capacitación real.

• Requiere de cambios en la formación de grupos de producción (se produce distinto).

• No se puede planificar con exactitud cuando uno utiliza una nueva tecnología hasta no tener
experiencia real del grupo de trabajo. (solo después de un tiempo se pueden aplicar métricas
de producción como resultado del seguimiento de producción real)

Puntos Interesantes de utilizar la T.O.

• Es algo realmente distinto, es un cambio tecnológico.

• No esta atado a las modas.

• No es un lenguaje de programación más.

• No es orientado a objetos (para que esperar, si puedo trabajar con objetos hoy?).

• Hay una comunidad muy activa y hay varios profesionales de experiencia en nuestro país.

Sitios de interés

En Argentina

• Smalltalking - Un sitio para el desarrollo y estudio de Ambientes de Objetos Virtuales.

www.smalltalking.net

• Sugar - Smalltalk User Group de Argentina www.SugarWeb.com

En el mundo

• Smalltalk Industry Council www.stic.org/

• Why Smalltalk? - Un sitio con respuestas a preguntas más comunes. www.whysmalltalk.com/

Página 12
• Smalltalk.org - Un sitio con material sobre Smalltalk www.smalltalk.org/

• Monty Kamath's GoodStart www.goodstart.com/

Referencias Bibliográficas

• Succeding with Objects. Decisión Frameworks for Project Management - Goldberg, A. &
Rubin, K. - AddisonWesley

• Smalltalk-80: The Language and its Implementation - Goldgerg, A. & Robson, D. -

AddisonWesley

• Smalltalk-80: Bits of History, Words of Advice - Glenn Krasner - AddisonWesley

• Design Patterns. Elements of Reusable Object-Oriented Software - Gamma, E. & Helm, R. &
Johnson, R. & Vlissides, J.

• Principios de Diseño de Smalltalk - Daniel H Ingalls - en:

www.smalltalking.net/Papers/StDesign/stDesign.htm

Página 13