Las definiciones de un Sistema son numerosas, casi infinitas, según quien las redacte. Y eso confiere universalidad a los sistemas, los pone por encima de los paradigmas, de las religiones, del origen del Mundo… la Cosmogonía misma es un sistema.
Luego, nadie lo duda: el Sistema es una estructura viviente. Fue creado para actuar y, más que para dar, para promover respuestas; ayuda y orienta al Hombre a buscar las soluciones que necesita. El sistema nace, se desarrolla, puede enfermarse y curarse, puede morir, y también resucitar si es que su existencia terminó en alguna parte pero vuelve a vivir y actuar en otro entorno, reencarnado, con otro ropaje.
Su vigencia puede ser corta o larga, eterna, provisional, limitada a términos finitos. Vive asediado por nuevas generaciones que intentaran desplazarlo. Por eso, es fascinante, mágico, alucinante, odiado. Y tiene un depredador incansable y malvado: el Usuario.
Aunque lo parezcan, estas imágenes no son retóricas, sino totalmente valederas. Significan que, como toda obra humana, el Sistema se renueva con expresiones que son, cada vez, la culminación de valores agregados que el Hombre soñó, después los descubrió, y llamó a una Tecnología que les diera vida y forma.
En Informática, podría decirse que el Sistema nació en un solo programa, de ejecución manual, mecánica, o semiautomática. El entorno le hizo crecer en complejidad, en responsabilidades, en prestigio. Pero, siempre se mostró atado a la Semiótica (Teoría General de los Signos) y más aún, a sus hijas llamadas Pragmatics, Sintaxis y Semántica, característica ésta que por sus continuas fallas y traspiés dentro de los sistemas ha dado lugar a una nueva rama de estudio llamada Sistemántica.
De ahí la importancia de la aparición y presentación del Análisis, Diseño y Desarrollo de Sistemas orientados a objetos. Se trata de una nueva manera de enfocar las aplicaciones empleando modelos basados en conceptos del mundo real donde se desenvuelve el sistema. La metodología tradicional enfatiza en la descomposición funcional del sistema de la empresa. El nuevo enfoque se orienta a identificar “objetos” pertenecientes al dominio de la aplicación y a establecer las entidades que constituirán su representación final mediante procedimientos y acciones, computarizadas o no. Primero define conceptualmente los objetos; para después, queda la forma como estos se utilizan.
Se persigue la comprensión del espacio o escenario del problema, antes de proponer las soluciones. Es bien sabido que a menudo los problemas percibidos son sólo síntomas, no las causas del problema real. La representación de una empresa mediante “modelos” del sistema que la rige, permite capturar los aspectos conceptuales, en lugar de orientarse a la implementación final de las soluciones y cambios. Es más rigurosa en el estudio de la información y en la definición de los mecanismos del proceso, y por ello soporta con más vigor las nuevas ingenierías de los negocios.
La experiencia dice que en general no acorta tiempo con respecto al desarrollo convencional, pues su esencia exige esfuerzos adicionales en el diseño; pero en cambio provee beneficios como la reutilización de sus elementos, la reducción de errores que generalmente se propagan en el proceso de diseño y especialmente enormes ventajas en el mantenimiento, que resultará así blindado frente a las “maldades” de la Sistemántica.
El modelado de Objetos
Sin que esto implique una definición completa y formal, podremos decir que un objeto es una abstracción, una percepción de la que surge un concepto, o algo con limites bien definidos y que tiene significado para la aplicación (también vale decir “que es capaz de hacer variar el comportamiento del sistema”).
Una taquilla de un Banco, un Jinete que conduce caballo de carrera, un formulario de pago de Impuesto, un programa de computadora, una pantalla de micro, un reloj, pueden ser considerados un objeto.
Luego, y como premisa, el diseñador debe comprender al objeto antes de construirlo. La abstracción es aquella capacidad humana que permite una visualización clara del flujo de las ideas, abre caminos en medio de la maleza de conceptos o propuestas, captura los aspectos cruciales de la situación. Puede ser imperfecta, pero establece bases de acción para los creativos.
Cada objeto tiene su propia identidad y se distingue de los otros objetos. El contenido de un modelo de objetos está determinado por su relevancia para la solución buscada.
El modelo puede ser simple, o constar de módulos que capacitan al diseñador a usar segmentos manejables. Mediante estructuras de nomenclatura variada, que incluyen jerarquías, herencias, asociaciones y otras numerosas y tal vez excesivas - definiciones, los objetos pueden conformar diseños que conviertan a un sistema en multidimensionado.
Y… ¿Como representar y documentar?
Hay otras propuestas innovadoras. La metodología de diseño orientado a objetos, si bien es amplia en sus esferas de aplicación, se centra y desarrolla en el área informática y en particular en la creación de software para Sistemas de Información, sus verdaderas columnas vertebrales.
No escapa a las etapas clásicas como reuniones multidisciplinarias preliminares, estudio del sistema actual o propuesto, fijación de alcance y objetivos, diseño en sí, desarrollo, documentaciones concurrentes, implementación, pruebas de operación y de aceptación por el usuario, corridas, en paralelo y finalmente la representación documentada total, siguiendo normas y estándares propios de cada instalación.
Y aquí se pregunta: ¿si el ámbito de los objetos es universal y multidimensional, de dónde se obtendrá una representación gráfica del sistema y de los objetos dinamizando al mundo real e interactuando con él?
Las técnicas gráficas universales de documentación en Ingeniería de Software están en proceso de desarrollo y consolidación. El advenimiento de Internet con lenguajes de alta creatividad como Macromedia Flash y Microsoft Front Page, la Animación y la Realidad Virtual, entre otros, están creando valiosas iniciativas entre los sistematizadores
Los objetos son las unidades en que dividimos al Mundo del sistema que percibimos o sentimos, y visualizamos, siendo el Modelo de Objetos el más importante de la tecnología OMT, desarrollado por Rumbaugh junto con otros autores, una de las más aceptadas. Se corresponde de manera más fiel con el mundo real y por lo tanto es más flexible frente a los cambios, allana el camino para comunicarse con el usuario y el resto de la gente de desarrollo.
El modelo describe la estructura de los objetos del sistema, su identidad, atributos, operaciones y relaciones con otros objetos. Crea el contexto en el cual se situarán los siguientes modelos llamados Dinámico y Funcional. En cuanto a su representación gráfica, usa diagramas que contienen clases relacionadas jerárquicamente y que podrán estar asociadas con otras clases.
A partir del Mundo Real, el modelo debe reflejarlo de modo que tenga sentido para los usuarios finales. Posteriormente, el diseño mantiene y se apoya en la estructura básica del modelo, y finalmente, el código de programación se debiera generar de la manera más automática posible a partir del diseño, lo que se logra mediante la nomenclatura funcional común. Se reitera: en OO, todos utilizan el mismo modelo conceptual: analistas, diseñadores, programadores y -muy importante- los usuarios.
Los conceptos más importantes que se manejan -y que son claves para dominar esta tecnología- son: Clases, Enlaces, Asociaciones, Herencia y Generalizaciones. La descomposición de una situación (vulgarmente llamada “problema”) depende de su naturaleza, y del juicio del analista. No hay una representación correcta única.
Una pregunta interesante es: ¿Cómo aparecen los objetos en un sistema la primera vez? Conceptualizando, se van observando objetos que pertenecerán a un mismo “tipo” porque poseen características similares, y eso nos lleva a la concepción de Clase, como plantilla o prototipo para cada tipo de objetos.
CLASES: La Clase agrupa a objetos con idénticos atributos (properties), similares relaciones con otros y con una semántica y comportamiento comunes. Las Clases son importantes porque al agrupar los objetos en clases se abstrae el problema. Es cierto que en la concepción tradicional siempre se piensa en el “archivo que reunirá a los registros”, pero la abstracción que se impone como disciplina en esta tecnología y sus herramientas adicionales otorgan al modelado de objetos mayor potencia y capacidad superior para generalizar su uso en las siguientes fases del desarrollo.
Las Clases proporcionan la ventaja de la reutilización. Los programadores pueden usar una clase cada vez que quieran crear nuevos objetos que, con distintos o más atributos, compartan una sola implementación de método.
Por ejemplo, el impacto del lenguaje JAVA en Internet es un rico conjunto de clases que contienen las abstracciones básicas para el entorno con el cual interactúan sus programas. Así, se ofrece a miles de programadores la oportunidad de crear objetos que interactúan sobre el Java en la red, y hasta los protocolos de Internet que suelen ser complejos y con abstrusos detalles técnicos, son fáciles de manejar como clases preestablecidas de Java.
Diagramas
Los diagramas ayudan a pensar con claridad, son otra forma de proceso del pensamiento. Hay progresos notorios en cuanto a generación automática de código y conversión de tipos de diagramas, que dotarían de un poderoso lenguaje común a las partes de la organización involucradas en los Sistemas.
Como formatos universales consistentes, se pueden adoptar los diagramas OMT, suficientemente maduros como una primera generación de estándares.
Los objetos se presentan como Instancias de una Clase. Por lo tanto los diagramas a graficarse serán:
a) de CLASES
La Clase se dibuja como un rectángulo, dividido verticalmente en hasta tres rectángulos que contienen: Nombre de la Clase, Atributos con su estructura de datos, y Operaciones inherentes a esos objetos (no las operaciones externas que puedan hacerse sobre ellos) Los diagramas de Clases describen clases de objetos.
b) de INSTANCIAS
La Instancia se dibuja como rectángulo de vértices redondeados. El nombre de la Clase se pone entre paréntesis en letra negrita en la parte superior del cuadro y los atributos y valores de cada instancia, en letra normal. El diagrama de instancias describe así la forma en que un cierto conjunto de objetos se relacionan entre sí. Un diagrama de Clases dado se puede corresponder con un conjunto infinito de diagramas de instancias.
Los diagramas de Clase describen el caso general al modelar un sistema.
Especifican la estructura de datos y los métodos operativos que se aplican a cada uno de sus objetos. Los diagramas de instancias son muy útiles para clarificar diagramas de Clases complejos; se recomienda no mezclar unos con otros en el mismo gráfico, para mantener el nivel conceptual de cada cosa.
El modelo final de objetos consistirá en un Grafo cuyos nodos son clases de objetos y cuyos arcos son relaciones horizontales o jerárquicas entre clases.
Elementos del Objeto
Un ATRIBUTO es una propiedad de los objetos de una Clase. Los objetos de la Clase Empleado podrían tener como atributos la edad, código del departamento donde trabaja, número de Cedula de Identidad, entre otros.
Se acompaña al atributo con el tipo de representación de su valor precedido por dos puntos, ej, Nombre: string, Sueldo: integer, etc. Opcionalmente también puede agregarse el valor por defecto.
Importante: cada atributo tiene un valor para cada instancia del objeto, aunque las instancias distintas de cierto objeto podrán tener el mismo o distinto valor para un atributo dado. El nombre del atributo es único dentro de la clase, pero puede repetirse en distintas clases con el mismo o diferente significado. Como se dijo, los atributos se colocan en el segundo rectángulo de la Clase.
En el modelado, los objetos no requieren identificadores explícitos (claves) ya que por definición cada uno posee su propia identidad única. Los lenguajes orientados a objetos normalmente hacen referencia a los objetos generando automáticamente identificadores implícitos para ellos que, por lógica, no tienen significado en el mundo real sino dentro del computador.
Una OPERACIÓN es una transformación aplicable a los objetos de una Clase, o que puede ser aplicada por esos objetos. Todos los objetos de una Clase comparten las mismas operaciones indicadas en el tercer rectángulo (inferior) del gráfico de Clase.
Una operación puede aplicarse con el mismo nombre en muchas clases distintas, adoptando distintas formas en cada una de ellas. De ahí la condición de “polimórficas”.
Una FUNCIÓN es intrínsecamente una asociación, y en esta tecnología se ratifica ese concepto. La función asocia objetos de una clase con un conjunto de objetos de otra clase, (es decir, desde un conjunto de objetos hacia otro conjunto de objetos) y su notación de flechas es similar a la usada en Matemática Conjuntista.
Dominio y Rango también deben manejarse aquí: Dominio es la colección de todos los objetos posibles de ser asociados por la función, o la Clase desde la cual la función puede asociar objetos, mientras el Rango es la colección de todos los objetos con los cuales la función puede asociar a los objetos del dominio.
Enlaces y Asociaciones
Un ENLACE es una conexión conceptual o física entre instancias de objetos. Por ejemplo Abreu “juega en” el Caracas conecta una instancia de la Clase Peloteros con otra instancia de la Clase Equipos. Una ASOCIACIÓN describe un conjunto de enlaces con estructura y semántica comunes.
Las Asociaciones describen un grupo de Enlaces potenciales del mismo modo que las Clases describen un grupo de Objetos potenciales. De ahí que un Enlace es una instancia de una Asociación. En una Asociación, todos los enlaces conectarán objetos procedentes de las mismas Clases.
Nótese que son conceptos conocidos y trabajados en la programación tradicional, pero que se le presentan en forma diferente a los lenguajes orientados a objetos, donde un programa consta de una colección de elementos discretos como Clases, Objetos, Operaciones, Herencias, Asociaciones (siendo el modelo de objetos el que contiene la mayoría de las estructuras declarativas).
La noción de Asociación no es un concepto nuevo. Viene siendo usada desde hace años en el modelado de bases de datos y el uso de punteros o apuntadores sigue siendo el recurso más práctico (tanto en lo relacional como en lo orientado a objetos…)
Herencia y Generalización
Si se necesita crear un objeto similar a otro definido previamente, pero con algunas características adicionales, se deberá “heredar” una nueva clase a partir de la anterior. Así, la HERENCIA es el proceso de crear una nueva clase (subclase) con las características de una ya existente, incluyendo datos y métodos, junto con características adicionales específicas de la nueva clase.
El principal valor de la Herencia en esta tecnología es proporcionar un mecanismo poderoso y a la vez natural, de organización y estructuración de programas, permitiendo así una máxima flexibilidad, al tiempo que posibilita reutilizar las veces que se quiera el código de la superclase, ahorrando tiempo y eliminando errores potenciales. La complejidad de los programas crece así en forma lineal, en lugar de geométrica.
La GENERALIZACIÓN es entonces, la relación entre una Clase, y una o más versiones organizadas y sucesivamente refinadas, de esa misma Clase.
Es la manera jerárquica como el hombre organiza su volumen de conocimientos. Herencia y Generalización son potentes abstracciones: mediante ellas, el desarrollador, después de modelar un sistema, examina las clases obtenidas, agrupa aquellas que tienen similitudes y puede reutilizar el código común.
La Herencia, por su parte, provee la simplificación conceptual que resulta de reducir el número de características independientes dentro del sistema.
Recomendaciones a los programadores
El proceso de desarrollo de los modelos orientados a objetos es puramente iterativo, de añadir detalles, siempre buscando optimizaciones. Entre los síntomas de que el programador haya pasado por alto algunos objetos se pueden mencionar:
- Atributos y relaciones dispares e incoherentes en una clase; debe fraccionarse la clase.
- Si una clase desempeña dos papeles, no cuadrará la organización, y debería también fraccionarla.
- Si una operación no tiene una clase destino, ésta debe ser añadida.
- Para Asociaciones duplicadas, de igual nombre y propósito, generalizar y crear la superclase que las una.
- Clases innecesarias, debido a carencia de atributos, operaciones y asociaciones de esa clase.- Pregúntese por qué es necesaria.
- Si faltan vías de acceso para alguna operación, es que hace falta alguna asociación que la haga posible.
- Asociaciones innecesarias por información redundante.
- Cada clase debe ser responsable de cumplir con las operaciones que se le han asignado, y de proveer la información que le corresponde.
- Evite un método que a la vez implemente un algoritmo de trabajo y tome decisiones dependientes del contexto o los resultados.
- Y algo más:
- No comience a construir el modelo diseñando cosas. Comprenda bien el problema antes de atacar el trabajo.
- Trate de mantener un modelo sencillo, evite las complicaciones.
- Escoja cuidadosamente los nombres, evite que tiendan hacia un cierto aspecto particular de un objeto.
- No intente determinar la multiplicidad en una fase excesivamente temprana del desarrollo.
- Haga revisar sus modelos por otras personas.
- No todas las estructuras OMT son necesarias para todos los problemas, use sólo las que necesite.
- Cree métodos comprensibles, pequeños, coherentes y legibles.
- No acceda al interior de una clase en busca de datos. Oculte su herencia interna a las demás clases. La técnica de “encapsulamiento” la protege de cambios caprichosos y “perversidades” de los usuarios.
- No exporte hacia otras clases las estructuras de datos que son propias del algoritmo de un método. Si lo hace tendrá problemas futuros al cambiar el algoritmo.
- No optimice el programa antes de que funcione. Valide rigurosamente los argumentos.
Cada modelo, una vez completado, debiera compararse con el Mundo Real, para discutir cuán válido ha resultado.
