Buenos Aires, 14 de Diciembre de 2000
Autor: Alejandro F. Reimondo ([email protected])
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).
Se denomina paradigma al conjunto de herramientas y técnicas que conforman el soporte de una tecnología.
La tecnología utilizada tradicionalmente para construir software esta 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 maquina.
Este principio puede ser extendido al asociar varias máquinas para formar una maquina compuesta.
De esta manera, acoplando maquinas y "encapsulando" en éstas tareas específicas se logra resolver problemáticas complejas.
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.
La labor humana consiste en:
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. Este lenguaje de programación sirve de nexo entre la parte humana y la maquina.
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.
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ó solo 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 primera alternativa que se ensayo para salir de la denominada crisis del software fue la parametrización de los sistemas.
Se trato 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.
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 logro 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.
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".
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). [el hombre es el único animal que comete el mismo error más de tres veces ;-) ]
Es sorprendente como con el pasar de los años la gente puede cambiar de herramientas, pero no se plantea si la herramienta es valida. [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.
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 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.
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.
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.
Bueno, mucho hemos hablado ya sin aclarar que alternativas tecnológicas son aplicables hoy para quien desea "construir software que no se ponga viejo antes de nacer".
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 limites accesibles a los objetos que contiene. Uno o más sistemas informáticos pueden estar contenidos en un Ambiente de Objetos.
Los limites 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 esta 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.
Arriba decíamos que 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 escencia 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 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 solo a los objetos virtuales, sino que pueden aplicarse a los sistemas de información evolutivos en general.
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 ultimo 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.
Que es un componente?
Un componente es una pieza de software única (unicidad) que posee una interfaz (protocolo), que define su capacidad de intercambio con otra pieza de idéntica interfaz.
Así es como un componente posee tres características fundamentales:
El encapsulamiento permite definir el componente de manera corpuscular, permitiendo poseer componentes internamente.
La unicidad permite focalizar el uso del componente, es decir, procurar un mecanismo de uso selectivo.
La interfaz define la capacidad de dialogo que tenga el componente, es decir, como va a ser usado en el futuro. Esta interfaz prometía ser la "garantía" de funcionamiento del componente, aunque es bien conocido hoy (en teoría y práctica) lo poco acertado que es esta afirmación.
En la practica la mantención de esta interfaz tiene un costo muy alto y es el mayor limitante para el mantenimiento de sistemas de componentes.
Unido a esto hay que resaltar que en la práctica la interfaz solo da una certeza sintáctica de funcionamiento, pero no esta garantizada de manera alguna la seguridad semántica de un sistema de componentes.
Es un hecho real que no es común el intercambio de componentes en un sistema construido orientado a objetos si estos cambios no fueron planificados antes de diseñar el sistema.
Un objeto es una pieza de software única.
Que habilidades (comportamiento) tiene un objeto dependen de su especie y esta 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.
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.
Smalltalk es un Ambiente de Objetos 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 un sintaxis o el uso de las opciones de los menúes de una herramienta.
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.
Un sistema que puede expresar su comportamiento en el mismo, permite evolución, si además 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 el comportamiento de este. 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.
Sistemas flexibles y evolutivos. Sistemas distribuidos o fácilmente distribuibles.
Sistemas fácilmente extensibles,… solo agregando nuevos objetos.
Sistemas entendibles por un apersona 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"
Si.
Toda librería o componente tradicional puede ser utilizado por un Ambiente de objetos; con los condicionamientos clásicos que esto produzca (por ejemplo, el sistema no podrá evolucionar allí); y la fragilidad que esto produzca (por ejemplo un componente frente a un error grave puede decidir matar la aplicación que lo contiene, destruyendo todo el ambiente… cosa inaceptable para un ambiente de objetos, pero muy común en el software tradicional).
Los componentes permiten el uso de estos componentes varias veces sin modificación.
Normalmente esto es llamado re-uso por.
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 una 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.
En la aplicación de componentes intercambiables no se re-usa, solo se usa.
En los casos donde se este "virtualizando" un sistema real, es decir copiándolo en un ambiente virtual de objetos, se puede observar como resultado de la virtualizacion parcial cambios en el sistema real.
El proceso de virtualizacion permite no solo tener una nueva herramienta para ensayos, sino que muchas veces refuerza las técnicas aplicadas por los expertos en el sistema real.
Este espejado entre ambos sistemas es posible si el sistema virtual tiene una capacidad de cambio(evolución) mayor o igual al sistema real.
Un sistema construido seriamente con Smalltalk permite una cinética equivalente a un sistema real.
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 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.
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.
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.
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.
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!.
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!
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.
Un ambiente define los limites de un sistema de objetos, aunque es común extender estos limites 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 escencia 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.
Internet y otros mecanismos de transporte
Los protocolos de Internet y de comunicación interprocesos e intersistemas (DDE, RPC, CORBA) permiten la manipulación y visualización de objetos del sistema en medios remotos o externos al ambiente mismo.
Es común que se utilicen las soluciones de virtualizacion sobre canales de comunicación para permitir acceso remoto a sistemas de objetos, para transporte de información y/o de comportamiento en rutinas de actualización o de mantenimiento, como en trabajos colaborativos.
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 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.
Decíamos que 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).
Decíamos que 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… ;-)
Mmmm. esto 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.
Es una técnica para determinar la conveniencia de encarar un proyecto o emprendimiento.
Es simple, se usan tres tarjetas, en una se colocan los puntos positivos de hacer el emprendimiento, en otra los puntos negativos y en la ultima los puntos interesantes.
No se emplea mucho tiempo para llenar las tres tarjetas (aprox 2 min).
Se juntan las tarjetas de varias personas y se computan los puntos más convergentes.
Es importante hacer notar que los puntos positivos son aquellos que incitan directamente a realizar el emprendimiento. Los negativos son los que producen algún tipo de daño o esfuerzo desmedido. Los puntos interesantes son los que resultan motivadores o atractivos.
A continuación agrego las fichas según mis opiniones aplicadas al uso de la Tecnología de Objetos para un nuevo emprendimiento.
Puntos Positivos de utilizar la T.O.
Puntos Negativos de utilizar la T.O.
Puntos Interesantes de utilizar la T.O.
En Argentina
Smalltalking - Un sitio para el desarrollo y estudio de Ambientes de Objetos Virtuales.
Sugar - Smalltalk User Group de Argentina
En el mundo
Smalltalk Industry Council
Why Smalltalk? - Un sitio con respuestas a preguntas más comunes.
Smalltalk.org - Un sitio con material sobre Smalltalk
Monty Kamath's GoodStart
Es recomendable ver la página de links de SUGAR en http://www.sugarweb.com/links/links.htm
Hay tres listas interesantes en:
Proyectos Smalltalk en Argentina (incompleta y desactualizada)
http://www.sugarWeb.com/Projects/Projects.htm
Monty Kamath's GoodStart
http://www.goodstart.com/whoswho.shtml