Capitulo 1 Marco Teórico

Transcripción

1 1 1.1 Reingeniería del software Capitulo 1 Marco Teórico La reingeniería del software nace como una necesidad de replantear o actualizar sistemas que por varias razones han perdido funcionalidad, o que simplemente debido a las tareas propias de la vida diaria de un sistema, han sido modificadas y cambiadas con el ánimo de satisfacer las nuevas necesidades de los procesos de una empresa, sin considerar las buenas prácticas de ingeniería del software, a tal punto que se han vuelto frágiles e inestables. El software imposible de mantener no es un problema nuevo, de hecho, el interés por la reingeniería del software ha sido desarrollado por un iceberg de mantenimiento del software que lleva creciendo desde hace más de treinta años Mantenimiento del software La analogía del mantenimiento del software con un iceberg tiene su lógica debido a esperamos que lo que se ve sobre la superficie sea lo único, pero sabemos que existe una enorme masa de potenciales problemas y costos debajo. El mantenimiento del software puede considerarse alrededor del 60% de las inversiones efectuadas por una empresa de desarrollo, el mismo que crece a medida que se desarrolla software. Una explicación de por qué se invierte tanto tiempo en mantenimiento nos la da Osborne y Chikofsky 1 así: Gran parte del software del que dependemos en la actualidad tiene por término medio entre 10 y 15 años de antigüedad. Aún cuando estos programas se crearon empleando las mejores técnicas de diseño y codificación conocidas en su época, se crearon cuando los tamaños de programas y almacenamiento eran las preocupaciones principales. A continuación se trasladaron a las nuevas plataformas, se ajustaron para adecuarlos a las nuevas máquinas y sistemas operativos, se mejoraron para satisfacer nuevas necesidades de usuarios. Todo esto sin tener en cuenta la arquitectura global. Los cambios son inevitables en un sistema computarizado, por lo tanto debemos desarrollar mecanismos para evaluar sus modificaciones. Tipo de mantenimiento: correctivo, adaptativo, mejoras o perfeccionamiento y preventivo o reingeniería. 1 Ingeniería del Software, Pressman

2 Modelo de procesos de reingeniería del software La reingeniería es una tarea de reconstrucción, se la puede entender mejor haciendo analogía a la reconstrucción de una casa. Considerar lo siguiente: - Se adquiere una casa en la que sabemos de antemano que puede ser preciso reconstruirla. - Sería bueno hacer una inspección profesional, para determinar si efectivamente necesita la reconstrucción, se crearía una lista de criterios para que la inspección fuera sistemática. - Revisar la estructura, pues si esta en buen estado es posible conservarla, y simplemente hacer una remodelación. - Entender la forma en que fue construida originalmente. - Si se decide a reconstruir o remodelar, utilice materiales modernos y de buena calidad. - Use herramientas que garanticen calidad. Para implementar estos principios en un proceso de reingeniería de software, se han definido seis actividades, las mismas que en algunas ocasiones pueden presentarse en un modelo secuencial lineal, pero no siempre es así. El paradigma mostrado en el gráfico 1 es un modelo cíclico, lo que significa que cualquiera de las etapas puede visitarse nuevamente en otras ocasiones, el proceso puede terminar en cualquiera de estas actividades. Análisis del Inventario Ingeniería Progresiva Reestruct. De Documentos Reestruct. De Datos Ingeniería Inversa Gráfico 1 Reestruct. De Código Análisis de inventario Hace referencia a los datos que se deben disponer en las aplicaciones de software existentes en una empresa: - nombre de la aplicación - año de creación - número de cambios importantes realizados en ella

3 3 - esfuerzo para aplicar estos cambios (horas/hombre) - fecha último cambio - sistema en que reside - aplicaciones con las cuales tiene relación - base de datos a las que accede - errores presentados en los últimos 18 meses - número de usuarios - números de equipos en los que está instalado - complejidad: arquitectura, código, documentación - calidad de la documentación - mantenibilidad general - longevidad del proyecto - costo anual de mantenimiento - costo anual de funcionamiento - valor anual de negocios - importancia para el negocio De la información recolectada para cada aplicación, aparecen los posible candidatos para reingeniería Reestructuración de documentos Se plantean alternativas ante una situación de documentación escasa: - Representa el caso de programas de los cuales no tenemos documentación, pero que no nos acompañarán por mucho tiempo, en estos casos se recomienda dejar las cosas así. - Si no se dispone de los recursos suficientes, se recomienda documentar únicamente lo que se ha modificando, con el tiempo se dispondrá de una basta documentación. - Redocumentar únicamente aquellos procesos críticos para el negocio Ingeniería Inversa El término Ingeniería Inversa tiene sus orígenes en el mundo del hardware, en donde una empresa desensambla un equipo de la competencia para comprender los secretos del diseño y construcción del mismo. Estos secretos se podrían comprender fácilmente si se obtuvieran las especificaciones de diseño y construcción elaboradas por el fabricante. En el mundo del software, el principio es el mismo, solo que no necesariamente aplica a productos de un competidor, sino de la misma compañía elaborados anteriormente. Consiguientemente, la ingeniería inversa del software es el proceso que consistente en analizar un programa en un esfuerzo por crear una representación del mismo con un nivel de abstracción más elevado que el del código fuente. A diferencia del mantenimiento, la reingeniería implica afectar la estructuras del sistema. La ingeniería inversa es un proceso de recuperación del diseño. Las herramientas de ingeniería inversa extraen información acerca de los datos, arquitectura y diseño de procedimientos de un programa ya existente

4 4 La ingeniería inversa invoca una imagen de ranura mágica, en donde por un lado se inserta un listado de código no estructurado no documentado, y por el otro lado sale la documentación completa del programa, desafortunadamente esta no existe, la ingeniería inversa puede extraer la información de diseño acerca del código fuente, pero el nivel de abstracción, la completitud de la documentación, el grado en el cual trabajan al mismo tiempo las herramientas y el analista humano y la direccionalidad del proceso son sumamente variables. - Nivel de abstracción: aluden a la sofisticación de la información de diseño que se puede extraer del código fuente, lo ideal sería un nivel alto de abstracción. - La completitud: alude al nivel de detalle que se proporciona de un determinado nivel de abstracción, en la mayoría de los casos, la completitud decrece a medida que aumenta el nivel de abstracción. - La interactividad: alude al grado con el cual el ser humado se integra con herramientas automatizadas para crear un proceso de ingeniería inversa - La direccionalidad: es monodireccional, es decir, el único sentido posible es del código fuente al diseño. El ingeniero tiene que evaluar el viejo programa y a partir del código fuente tiene que extraer una especificación significativa del proceso que se realiza, la interfaz de usuario que se aplica y las estructuras de datos de programa o de la base que utiliza. - Ingeniería inversa para comprender el proceso: La primera actividad de ingeniería inversa intenta comprender y luego hacer abstracciones de procedimientos representadas en código fuente. Para comprender las abstracciones de procedimientos se analiza el código en distintos niveles de abstracción, sistema, programa, módulo, trama y sentencia. La funcionalidad de todo el sistema debe ser algo perfectamente comprendido antes que se produzca un trabajo de ingeniería inversa más detallado. Cada uno de los programas de que consta el sistema de aplicaciones representará una abstracción funcional con un elevado nivel de detalle. - Ingeniería inversa para comprender los datos: La ingeniería inversa de datos suele producirse en diferentes niveles de abstracción. En el nivel de programa, es frecuente realizar una ingeniería inversa de las estructuras de datos de programa internas, como parte de un esfuerzo global de reingeniería. En nivel de sistema es frecuente que se efectúe una reingeniería de las estructuras globales de datos, por ejemplo archivos y bases de datos. Estos conceptos se ilustran en el gráfico 2.

5 5 Fuente Sucio Reestructuración Del código Código fuente limpio Procesamiento Extraer Abstracciones Interfaz Base de datos Especificación Inicial Refinar y Simplifiacr Gráfico 2 Especificación Final Estructuras Internas: Las técnicas de ingeniería inversa para datos de programa internos se centran en la definición de clases de objetos, esto se logra analizando el código del programa con la idea de agrupar variables relacionadas. Se identifican indicadores y estructuras de datos locales dentro del programa que registren información importante acerca de estructuras de datos globales. Se define la relación entre estructuras y datos locales con estructuras de datos globales. Estos pasos capacitan al ingeniero del software para identificar las clases dentro del programa que interactúan con las estructuras de datos globales. Estructuras de bases de datos: Independientemente de su organización lógica y estructura física, las bases de datos permiten definir objetos de datos, y admiten algún método para establecer relaciones entre objetos. La reingeniería de un esquema de bases de datos para formar otro, exige una comprensión de los objetos ya existentes y de sus relaciones.. Se construye un modelo de objetos inicial.. Se determinan los candidatos a claves. Se refinan las clases tentativas. Se definen las generalizaciones. Se descubren las asociaciones.

6 6 - Ingeniería inversa de interfaces de usuario: A medida que las GUI (graphic user interface) se han vuelto sofisticadas y los entornos gráficos se hacen más comunes, el desarrollo de interfaces de usuario ha pasado a ser uno de los tipos más comunes de actividades de reingeniería. Para comprender una interfaz de usuario ya existente, es preciso especificar la estructura y comportamiento de la interfaz. Merlo y sus colaboradores 2 sugieren tres preguntas a responder cuando se inicia una actividad de ingeniería inversa de la interfaz de usuario:. Cuáles son las acciones básicas que debe procesar la interfaz, como teclado y clic del ratón.?. Cuál es la descripción de la respuesta del sistema a estas acciones?. Qué concepto de equivalencia de interfaces es relevante en este caso? La descripción de la interfaz hace uso de agentes y acciones. Un agente es algo que da vida a algún aspecto del sistema, las acciones permiten que los agentes se comuniquen entre sí, en escencia el álgebra de procesos es una notación taquigráfica para representar la forma en que los agentes y las acciones dan vida a la función de una interfaz de usuario La reestructuración. La reestructuración del software modifica el código fuente y/o los datos en un intento de hacerlo adecuado para cambios futuros. En general, la reestructuración no modifica la arquitectura global del programa. Tiende a centrarse en los detalles de diseño de módulos individuales y en estructuras de datos locales definidas dentro de los módulos. Si el esfuerzo se extiende más allá de los límites de los módulos y abarca a la arquitectura del software, la estructuración pasa a ser ingeniería progresiva. Algunos de las ventajas de la reestructuración son:. Programas de mayor calidad, con mayor documentación y menos complejidad.. Mejora la comprensión de los ingenieros que deban trabajar con el programa, mejorando por tanto la productividad, y haciendo más sencillo el aprendizaje.. Reduce el esfuerzo en actividades de mantenimiento.. Hace al oftware más sencillo de comprobar y depurar. Reestructuración de código: se lleva a cabo para conseguir un diseño que produzca la misma función pero con mayor calidad que el programa original. En general, las reglas de reestructuración de código modelan la lógica del programa empleando álgebra Booleana. El objetivo es tomar el código en forma de plato de spaguetis y derivar a partir de él en un diseño de procedimientos que se ajuste a la filosofía de la programación estructurada. Reestructuración de datos: antes que pueda comenzar la reestructuración de los datos, es preciso llevar a cabo una ingeniería inversa, un análisis del código fuente. 2 Ingeniería del Software, Pressman

7 7 Se evaluarán primeramente todas las sentencias del lenguaje que contengan definiciones de datos, descripciones de archivos, entrada / salida y descripciones de interfaz. El objetivo es extraer elementos y objetos de datos para obtener información acerca del flujo de datos, así como entender las estructuras de datos existentes. Esta actividad se denomina análisis de datos. Una vez finalizado el análisis de datos empieza el rediseño de datos. En su forma más sencilla se emplea un paso de estandarización de rediseño de datos que clarifica las definiciones de datos para lograr una consistencia entre nombres de objetos de datos o entre formatos de registros físicos. Otra forma de rediseño denominada racionalización de nombres de datos asegura que todas las convenciones de normalización de datos se ajusten a los estándares locales y asegura también que se eliminen los alias a medida que fluyen los datos a través del sistema. Cuando la reestructuración va más allá de la estandarización y de la racionalización, se efectúan modificaciones físicas en las estructuras de datos ya existentes con objeto de hacer que el diseño de datos sea más efectivo. Esto puede significar una traducción de un formato de archivo a otro o en algunos casos, una traducción de un tipo de base de datos a otra Ingeniería progresiva Un programa con un flujo de control equivalente a un plato de espaguetis y que no posea documentación, debe ser modificado para adecuarse a los requisitos del usuario. Existen las siguientes opciones:. Realizar el esfuerzo necesario para lograr implementar los cambios.. Tratar de entender el funcionamiento interno para que las modificaciones sean más efectivas. Rediseñar, recodificar y probar solo aquellas partes que necesitan ser cambiadas, aplicando enfoques de ingeniería de software.. Rediseñar, recodificar y probar el sistema en su totalidad aplicando herramientas CASE No existe una opción única, pues pueden utilizarse según las circunstancias. Miller define la ingeniería progresiva como 3 : la aplicación de las metodologías de hoy a los sistemas de ayer para prestar apoyo a los requisitos del mañana. A primera vista, puede parecer extravagante la reprogramación de sistemas que se encuentran funcionando, sin embargo debemos considerar lo siguiente:. El costo de una línea de mantenimiento puede estar entre 30 y 40 veces por encima del costo de desarrollo.. El rediseño de la estructura del software empleando conceptos modernos puede facilitar mucho el futuro mantenimiento.. Los usuarios tienen conocimiento del software, por lo tanto los nuevos requisitos de cambio pueden manejarse más fácilmente. 3 Ingeniería del Software, Pressman

8 8. Las herramientas CASE para reingeniería pueden hacer algunas tareas automáticamente.. Cuando termine el mantenimiento preventivo, se dispondrá de una configuración completa de software, (documentos programas y datos). El proceso de ingeniería progresiva aplica principios, conceptos y métodos de ingeniería de software para volver a crear las aplicaciones existentes. En la mayoría de los casos, la ingeniería progresiva no se limita a crear un equivalente moderno de un programa anterior, más bien se integran los nuevos requisitos y las nuevas tecnologías en ese esfuerzo de reingeniería. El programa desarrollado de nuevo extiende las capacidades de la aplicación anterior. Ingeniería Progresiva para arquitecturas O.O. La ingeniería de software orientada a objetos se está transformando rápidamente en el paradigma de desarrollo de elección para muchas organizaciones de software. Sin embargo debemos ver la posibilidad de migrar todas aquellas aplicaciones que se han desarrollado considerando metodologías tradicionales. En primer lugar se hace ingeniería inversa del software existente para que sea posible crear los modelos adecuados de datos, funcional y de comportamiento. Los modelos de datos creados durante la ingeniería inversa, se utilizan para establecer la base para la definición de clases. Las jerarquías de clases, los modelos de relaciones entre objetos, los modelos de comportamiento de objetos y los subsistemas se definen a continuación y comienza el diseño orientado a objetos. Si la aplicación existente posee un dominio que ya contiene aplicaciones orientadas a objetos, es probable que exista una robusta biblioteca reutilizable que podemos usar durante la ingeniería progresiva. Para aquellas clases que sea preciso construir partiendo de cero, quizá sea posible reutilizar algoritmos y estructuras de datos procedentes de la aplicación convencional original. Ingeniería Progresiva para (arquitecturas) interfaces de usuario: Se aplica especialmente cuando se migran aplicaciones de ambientes centralizados a ambientes distribuidos, pues los usuarios no están dispuestos a aceptar interfaces basadas en caracteres, precisan de ambientes gráficos modernos. De hecho, una gran parte del esfuerzo invertido en la transición de ambientes centralizados a cliente servidor, se pueden reinvertir en la reingeniería de interfaces de usuario de la aplicación cliente. Merlo y sus colaboradores 4 suguieren el siguiente modelo: 4 Ingeniería del Software, Pressman

9 9. Comprender la interfaz original y los datos que se trasladas entre ella y el resto de la aplicación. Si se ha de desarrollar una nueva IGU, entonces el flujo de datos entre la IGU y el resto del programa debe ser consistente con los datos que en la actualidad fluyen entre la interfaz basada en caracteres y el programa.. Remodelar el comportamiento implícito de la interfaz existente para formar una serie de abstracciones que tengan sentido en el contexto de una IGU. Aún cuando el modo de la interacción sea radicalmente distinto, el comportamiento de negocios interno debe seguir siendo el mismo.. Introducir mejoras que hagan que el modo de interacción sea más eficiente Economía de la reingeniería En un ambiente ideal, todo programa que no se pueda mantener, se retiraría inmediatamente para ser sustituido por aplicaciones de alta calidad, fabricadas mediante reingeniería y desarrolladas empleando prácticas de ingeniería de software modernas. Sin embargo, por las limitantes de recursos deben considerarse costos y prioridades a los procesos a ser sometidos a reingeniería. Sneed 5 propone un modelo de costo y beneficio basado en nueve parámetros: P1 = Ccosto de mantenimiento anual de una aplicación. P2 = Costo de operación anual P3 = Valor de negocios real actual P4 = Costo de mantenimiento anual previsto (después de la reingeniería) P5 = Costo de operaciones anual previsto (después de la reingeniería) P6 = Valor de negocios previsto después de la reingeniería P7 = Vostos estimados de la reingeniería P8 = Fecha estimada de reingeniería P9 = Factor de riesgo de la reingeniería. (1,0 valor nominal) L = Vida esperada del sistema (en años) El costo asociado al mantenimiento continuo se define como: Cmant = [P3 (P1 + P2)] x L El costo asociado a la reingeniería se define como: Creing = [P6 (P4 + P5) x (L P8) (P7 x P9)] Empleando las formulas anteriores, tenemos el beneficio como: Beneficio = Creing Cmant Aquellas aplicaciones que muestren mayor beneficio, son candidatas potenciales a aplicar reingeniería. 5 Ingeniería del Software, Pressman

10 OMT Modelamiento y diseño orientado a objetos constituye una nueva forma de pensar acerca de problemas empleando modelos que se han organizado tomando como base conceptos del mundo real. La construcción fundamental es el objeto que combina las estructuras de datos con los comportamientos en una entidad única. Los modelos orientado a objetos son útiles para comprender los problemas, comunicarse con expertos en esa aplicación, modelar empresas, preparar documentación y diseñar programas y bases de datos. Una de las metodologías orientado a objetos es la llamada Técnica de Modelado de Objetos (OMT), que se extiende desde el análisis hasta la implementación pasando por el diseño. En primer lugar se construye un modelo de análisis para abstraer los aspectos esenciales del dominio de la aplicación sin tener en cuenta la implementación eventual. Estos objetos constituyen el marco de trabajo del modelo de diseño, por último el modelo de diseño se implementa en algún lenguaje de programación, base de datos, y hardware. Se utiliza una notación gráfica para expresar los modelos orientados a objetos. Los objetos de dominio de la aplicación y del dominio de la computadora se pueden modelar, diseñar e implementar utilizando los mismos conceptos y la misma notación orientados a objetos. Orientado a objetos: En términos simples significa que el software se organiza como una colección de objetos discretos que contienen tanto estructuras de datos como un comportamiento. Esto se opone a la programación convencional, en la cual las estructuras de datos y el comportamiento solamente están relacionadas de forma débil. Existe un cierto desacuerdo en cuanto a las características precisas que requiere un enfoque orientado a objetos aunque suelen incluirse cuatro aspectos: identidad, clasificación, polimorfismo y herencia.. Identidad: quiere decir que los datos están cuantificados en entidades discretas y distinguibles denominadas objetos, Ej. Una ventana de mi estación de trabajo, un párrafo de un documento, la reina blanca de un juego de ajedrez.. Clasificación: Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se agrupan para formar una clase. Se dice que cada objeto es una instancia de su clase. Se grafica un ejemplo en el gráfico 3.

11 11 Objetos Polígono clase Polígono Se abstraen Para dar Atributos: Vértices Color de borde Color del interior Operaciones Gráfico 3 Dibujar Borrar mover. Polimorfismo: significa que una misma operación puede comportarse de modos distintos en distintas clases. La operación mover por ej. Puede comportarse de diferente manera en las clases ventana y pieza de ajedrez. Una operación es una acción que se le aplica a un objeto.. Herencia: es compartir atributos y operaciones entre clases, tomando como base una relación jerárquica. En términos generales se puede definir una clase que después se irá refinando sucesivamente para producir subclases. Todas las subclases poseen o heredan todas y cada una de su superclase, y añaden además sus propiedades exclusivas. No es necesario repetir las propiedades de la clase en sus subclases Metodología Orientada a Objetos La metodología consiste en construir un modelo de un dominio de aplicación añadiéndose detalles de implementación durante el diseño de un sistema. Esta aproximación se denomina la Técnica de Modelado de Objetos (OMT), la cual consta de las siguientes fases: Análisis Comenzando desde la descripción del problema, el analista construye un modelo de la situación del mundo real que muestra sus propiedades importantes. Dicho analista debe trabajar con quien hace la solicitud para comprender el problema más porque las definiciones del mismo no suelen ser completas ni correctas. El modelo del análisis es una abstracción resumida y precisa de lo que debe hacer el sistema deseado y no de la forma en que se hará. Los objetos del modelo deberán ser conceptos del dominio de la aplicación y no conceptos de implementación de la computadora tales como estructuras de datos. Un buen modelo podrá ser comprendido y criticado por expertos de la aplicación que no sean programadores. El modelo de análisis no debe contener ninguna decisión de implementación.

12 Diseño del sistema El diseñador de sistemas toma decisiones de alto nivel acerca de la arquitectura global. Durante el diseño, el sistema de destino se organiza en subsistemas basados tanto en la estructura del análisis como en la arquitectura propuesta. El diseñador del sistema deberá decidir qué características de rendimiento hay que optimizar, seleccionando una estrategia para atacar el problema y efectuando unas reservas de recursos tentativas. Por ejemplo el diseñador del sistema podría decidir que los cambios habidos en la pantalla de la estación de trabajo sean rápidos y suaves aunque se muevan o borren ventanas y seleccionará un protocolo de comunicaciones adecuado así como una estrategia de reserva de memoria Diseño de objetos El diseñador de objetos construye un modelo de diseño basándose en el modelo de análisis que lleva incorporados detalles de implementación. El diseñador añade detalles al modelo de acuerdo con la estrategia establecida durante el diseño del sistema. El foco de atención del diseño de objetos son las estructuras de datos y los algoritmos necesarios para implementar cada una de las clases. Las clases de objetos procedentes del análisis siguen siendo significativas pero se aumentan con estructuras de datos y algoritmos del dominio de la computadora seleccionados para optimizar medidas importantes de rendimiento. Tanto los objetos del dominio de la aplicación como los objetos del dominio de la computadora se describen utilizando unos mismos conceptos y una misma notación orientado a objetos aún cuando existan en planos conceptuales diferentes Implementación Las clases de objetos y las relaciones desarrolladas durante su diseño se traducen finalmente en un lenguaje de programación concreto, a una base de datos o a una implementación de hardware. La programación debería ser una parte relativamente pequeña del ciclo de desarrollo y fundamentalmente mecánica porque todas las decisiones importantes deberán hacerse durante el diseño. El lenguaje influye en cierta medida sobre las decisiones de diseño pero este no debería depender de la estructura final de un lenguaje de programación. Durante la implementación es importante respetar las buenas ideas de la ingeniería del software, de tal manera que el seguimiento hasta el diseño sea sencillo y de forma que el sistema implementado siga siendo flexible y extensible. Es posible aplicar conceptos orientado a objetos a lo largo de todo el ciclo de vida de desarrollo del sistema.

13 Temas orientados a objetos Hay varios temas que subyacen a la tecnología orientada a objetos, aunque estos temas no son exclusivos de los sistemas orientada a objetos, están bien apoyados especialmente por es esta tecnología Abstracción La abstracción consiste en centrarse en los aspectos esenciales inherentes a una entidad, e ignorar sus propiedades accidentales. En el desarrollo de sistemas esto significa centrarse en lo que es y lo que hace un objeto antes de decidir cómo debería ser implementado. El uso de la abstracción mantiene nuestra libertad de tomar decisiones durante el mayor tiempo posible evitando comprometernos de forma prematura con ciertos detalles. La mayoría de los lenguajes modernos proporcionan abstracción de datos pero la capacidad de utilizar herencia y polimorfismo proporciona una potencia adicional. El uso de la abstracción durante el análisis significa tratar solamente conceptos del dominio de la aplicación y no tomar decisiones de diseño o de implementación antes de haber comprendido el problema. Un uso adecuado de la abstracción permite utilizar el mismo modelo para el análisis, diseño de alto nivel, estructura del programa, estructura de una base de datos y documentación. Un estilo de diseño independiente del lenguaje pospone los detalles de programación hasta la fase final, relativamente mecánica del desarrollo Encapsulamiento O encapsulación, se denomina también ocultamiento de información, y consiste en separar los aspectos externos del objeto, a los cuales pueden acceder otros objetos, de los detalles internos de implementación del mismo, que quedan ocultos para los demás. La encapsulación evita que el programa llegue a ser tan interdependiente que un pequeño cambio tenga efectos secundarios masivos. La implementación de un objeto se puede modificar sin afectar a las aplicaciones que lo utilizan. Quizá sea necesario modificar la implementación de un objeto para mejorar el rendimiento, corregir un error, consolidar el código o para hacer un transporte a otra plataforma. La encapsulación no es exclusiva de los lenguajes orientados a objetos, pero la capacidad de combinar la estructura de datos y el comportamiento en una única entidad hace que la encapsulación sea aquí más limpia y potente que en los lenguajes convencionales que separan las estructuras de datos y el comportamiento.

14 Combinación de datos y comportamiento Aquel que invoca una operación no necesita considerar cuantas implementaciones existen de una operación dada. El polimorfismo de operadores traslada la carga de decidir qué implementación hay que utilizar llevándola del código que hace la llamada a la jerarquía de clases. Por ejemplo, en código no orientado a objetos, para visualizar el contenido de una ventana debe distinguir el tipo de cada figura (un polígono, círculo, texto) y debe invocar al procedimiento adecuado para visualizarlo. Un programa orientado a objetos invocaría simplemente la operación dibujar para cada figura; la decisión del procedimiento que hay que utilizar es realizada implícitamente por cada objeto basándose en su clase. No es necesario repetir la selección de procedimiento cada vez que se invoque a la operación en el programa de aplicación. El mantenimiento es más sencillo porque el código que hace la llamada no necesita ser modificado cuando se añade una clase nueva. En un sistema orientado a objetos la jerarquía de estructuras de datos es idéntica a la jerarquía de operaciones, como se muestra en el gráfico 4. Enfoque convencional por procedimientos Enfoque orientado a objetos Jerarquía de estructura de datos Gráfico 4 Jerarquía de clases Jerarquía de procedimientos El enfoque orientado a objetos tiene una sola jerarquía unificada.

15 Compartir Las técnicas orientadas a objetos impulsan a compartir en distintos niveles. La herencia tanto de estructuras de datos como de comportamientos, permite compartir una estructura común entre varias subclases similares sin redundancia. Una de las principales ventajas de los lenguajes orientados a objetos es compartir código empleando la herencia. Todavía más importante que el ahorro de código es la claridad conceptual que surge al reconocer que distintas operaciones son todas ellas, realmente, una misma cosa. Esto reduce el número de clases distintas que es preciso comprender y analizar. El desarrollo orientado a objetos no sólo permite compartir información dentro de una aplicación sino que, además ofrece la perspectiva de volver a utilizar diseños y códigos en futuros proyectos. Aún cuando esta posibilidad se ha hecho resaltar excesivamente como justificación de la tecnología orientada a objetos, el desarrollo orientado a objetos no es una fórmula mágica para asegurar la reutilización del código, sin embargo. La reutilización no sucede; debe ser planteada pensando más allá de la aplicación inmediata e invirtiendo un esfuerzo adicional en un diseño más general Énfasis en la estructura de objetos, no de los procedimientos La tecnología orientada a objetos hace hincapié en especificar lo que es un objeto más que en la forma en que éste se utiliza. Las aplicaciones de un objeto dependen mucho de los detalles de la aplicación y suelen cambiar durante el desarrollo. A medida que evolucionan los requisitos, las posibilidades proporcionadas por un objeto son mucho más estables que las formas en que se utilizan; por tanto los sistemas de software construidos sobre una estructura de objetos son más estables en el tiempo. El desarrollo orientado a objetos pone un mayor énfasis en la estructura de objetos y hace menos hincapié en la estructura de procedimientos que las metodologías tradicionales de descomposición funcional. En este aspecto, el desarrollo orientado a objetos es parecido a las técnicas de modelado de información que se utilizan en el diseño de base de datos, si bien el desarrollo orientado a objetos añade el concepto de comportamiento dependiente de la clase Sinergia La identidad, clasificación, polimorfismo y herencia caracterizan los principales lenguajes orientados a objetos. Cada uno de estos conceptos puede ser utilizado aisladamente, pero en su conjunto, se complementan unos a otros de forma sinérgica. Los beneficios de un enfoque orientado a objetos son mayores de lo que podría pensarse en un principio. El hincapié hecho en las propiedades esenciales de los

16 16 objetos obliga al desarrollador de software a pensar en forma más clara y profunda acerca de lo que es y de lo que hace el objeto, alcanzando un resultado consistente en que el sistema puede ser más limpio, más general y más robusto de lo que sería si el hincapié se hiciera únicamente sobre el uso de datos y de operaciones. Según Thomas 6, estas características se unen para crear un estilo distinto de programación. Cox 7 afirma que la encapsulación es el fundamento de la programación orientado a objetos desplazando el énfasis de la técnica de codificación al empaquetamiento mientras que la herencia se basa en la encapsulación para hacer práctica la reutilización del código Modelos de OMT Resulta útil modelar un sistema desde tres puntos de vista distintos, aunque relacionados, cada uno de los cuales captura aspectos importantes del sistema, pero siendo todos ellos necesarios para una descripción completa. La técnica de modelado de Objetos (OMT) es el nombre que se da a una metodología que combina estos tres puntos de vista para el modelado de sistemas. El modelo de objetos representa los aspectos estáticos, estructurales de datos del sistema. El modelo dinámico representa los aspectos temporales, de comportamiento de control del sistema. El modelo funcional representa los aspectos transformacionales de función del sistema. Un procedimiento típico de software contiene estos tres aspectos, utiliza las estructuras de datos (modelo de objetos) secuencia las operaciones en el tiempo (modelo dinámico) y transforma valores (modelo funcional). Cada modelo contiene referencias a entidades de otros modelos, por ejemplo, las operaciones se asocian a los objetos en el modelo de objetos pero se expanden de forma más completa en el modelo funcional. Las tres clases de modelos desglosan el sistema en puntos de vista ortogonales que se pueden representar y manipular empleando una notación uniforme. Los distintos modelos no son completamente independientes (un sistema es algo más que una colección de partes independientes) pero cada modelo puede ser examinado y comprendido por sí mismo en gran parte. Las interconexiones entre los distintos modelos son limitadas y explícitas. Por su puesto siempre es posible crear diseños malos en los cuales los tres modelos estén tan entremezclados que no sea posible separarlos, los buenos diseños en cambio aíslan los distintos aspectos del sistema y limitan el acoplamiento entre ellos. 6 El Lenguaje Unificado de Modelado, Booch, Rumbaugh, Jacobson 7 El Lenguaje Unificado de Modelado, Booch, Rumbaugh, Jacobson

17 Modelo de Objetos Este modelo captura la estructura estática del sistema, mostrando sus objetos, sus relaciones, y los atributos que caracteriza a cada clase. Este es el más importante de los tres modelos, y proporcionan una representación gráfica intuitiva del sistema, mediante la cual podemos comunicarnos con los clientes y documentar las estructuras del sistema. Objetos: El propósito esencial del modelado de objetos es describir objetos. Por ejemplo son objetos: Juan Pérez, la empresa XYZ, el proceso de compras, un objeto es sencillamente algo que tiene sentido en el contexto de una aplicación. Un objeto se define como un concepto, abstracción o cosa con límites bien definidos y con significado a efectos del problema que se tenga que resolver. Los objetos tienen dos propósitos: promover la comprensión del mundo real y proporcionar una base para la implementación en computadora. La descomposición del problema en objetos depende del juicio y de la naturaleza del problema, pueden existir varias representaciones correctas. Todos los objetos poseen identidad propia y se pueden distinguir entre sí. El término identidad significa que los objetos se distinguen por su existencia inherente y no por sus propiedades descriptivas. Cuando se desea ser preciso y aludir a una cosa exactamente se utiliza la frase instancia de objeto, y para aludir a un grupo de cosas similares, clase de objeto. Clases: Una clase de objetos describe un grupo de objetos con atributos y propiedades similares, con relaciones comunes y con una semántica común. Ejemplo de clases de objetos son: persona, compañía, proceso; una persona tiene edad, coeficiente intelectual, y puede realizar cierto trabajo. Los objetos y sus clases pueden aparecer como sustantivos en las descripciones de problemas. Frecuentemente se utiliza la abreviatura clase en lugar de clase de objeto. Los objetos de una clase tienen los mismos atributos y los mismos patrones de comportamiento Los objetos de una clase comparten un propósito semántico común, más allá de los requisitos de comunidad de atributos y de comportamiento, por tanto, aún cuando un granero y un caballo tienen un coste y una edad, pueden pertenecer a diferentes clases, pero si se considera al granero y al caballo como activos financieros, pueden pertenecer a la misma clase. La interpretación de la semántica depende del proceso de cada aplicación. Cada objeto conoce a su clase, la mayoría de los lenguajes de programación orientada a objetos pueden determinar la clase del objeto al momento de la ejecución. Al agrupar objetos en clases se abstrae el problema, la abstracción da al modelado su potencia y capacidad de generalizar, partiendo de unos pocos casos específicos hasta llegar a una multitud de casos similares. Las definiciones comunes se almacenan una sola vez en cada clase, en lugar de almacenarse una vez por instancia. Es posible escribir operaciones una sola vez para cada clase, de forma que todos los objetos de la clase se beneficien utilizándola.

18 18. Diagramas de objetos: Proporcionan una notación gráfica formal para el modelado de objetos, clases y sus relaciones entre sí, son útiles tanto para el modelado abstracto como para diseñar programas reales. Los diagramas de objetos son concisos, fáciles de entender y funcionan bien en la práctica. Existe dos tipo de diagramas de objetos, diagramas de clases y diagramas de instancias.. Diagramas de Clases: es un esquema, patrón o plantilla para describir muchas instancias de datos posibles, describen clases de objetos.. Diagrama de Instancias: describe la forma en que un cierto conjunto de objetos se relacionan entre sí, describe instancias de objetos, son útiles para documentar casos prácticos, escenarios, y para describir ejemplos. Un diagrama de clases dado, se corresponde con un conjunto infinito de diagramas de instancia. Ilustración en el gráfico 5: Gráfico 5 Persona (Persona) Juan Pérez (Persona) Maria García Clase Objetos Diagrama de clases a la izquierda y un posible diagrama descrito por el primero, los objetos Juan Pérez y María García son instancias de la clase persona. El símbolo OMT de un objeto es un cuadro con esquinas redondeado, con el nombre de la clase entre paréntesis y en negrillas. El símbolo OBM de una clase es un cuadrado con el nombre de la clase en negrillas. Los diagramas de clases describen el caso general al modelar un sistema, los de instancias se utilizan para mostrar ejemplos que nos ayuden a clarificar los diagramas de clases complejos. Los diagramas de clases y de instancias pueden aparecer en un mismo diagrama de objetos, pero en general no resulta útil mezclarlos. Atributos: Se lo define como un valor de un dato que está almacenado en los objetos de una clase, por ejemplo nombre, edad, peso son atributos del objeto de tipo Persona. Cada atributo tiene un valor para cada instancia del objeto, por ejemplo el atributo edad tiene un valor de 40 en el objeto Juan Pérez. El nombre de un atributo es único dentro de una clase, pero diferentes clases pueden tener un mismo atributo, por ejemplo la clase persona y la clase compañía pueden tener el atributo dirección. Los atributos se enumeran en la segunda parte del cuadro de clase, pudiendo ir seguido del tipo y valor por omisión, donde el tipo irá precedido por :, y el valor por omisión precedido por un =.

19 19 Los cuadros de clase tiene una línea para dividir el nombre de los atributos, los cuadros de objetos no. Se Ilustra en el gráfico 6 Persona Nombre: cadena Edad: entero= 5 (Persona) Juan Pérez 25 (Persona) María García 30 Clase con atributos Objetos con sus valores Gráfico 6 Algunos medios de implementación como bases de datos, exigen un identificador (ID) único que reconozca a cada objeto, pero estos identificadores de objeto explícitos no son necesarios en el modelado de objetos, cada uno posee su propia identidad única. No hay que confundir los identificadores internos con atributos del mundo real, los identificadores internos son solamente una comodidad de implementación, y no tienen significado en el dominio del problema. Operaciones y métodos: Se define como operación a una función o transformación que se puede aplicar a todos los objetos de una clase. Ejemplos de operaciones una clase Compañía son contratar, despedir, pagar impuestos. Todos los objetos de una clase comparten las mismas operaciones Cada operación tiene un objeto blanco como argumento implícito, el comportamiento de la operación depende de la clase de su blanco. Una misma operación puede aplicarse a muchas clases distintas, tal operación será polimórfica, esto significa que una misma operación adopta distintas formas en distintas clases. Un método es la implementación de una operación para una clase, por ejemplo la clase archivo puede tener una operación llamada imprimir, se podrían implementar distintos métodos para imprimir archivos de diferentes tipos, cada uno de estos efectúa una misma tarea lógica (imprimir) sin embargo, cada método puede estar implementado mediante un segmento de código diferente adecuado para cada tipo de archivo. Una operación puede poseer argumentos, tales argumentos parametrizan la operación. Cuando una operación posee métodos aplicables a distintas clases es importante que todos los métodos tengan la misma signatura, por ejemplo imprimirlo debería tener como argumento el nombre-de-archivo para un método y puntero-del-archivo para otro. El comportamiento de todos los métodos de una operación debería tener una internacionalidad común, lo mejor es no utilizar el mismo nombre para dos operaciones que sean semánticamente distintas, aún cuando sean aplicables a conjuntos distintos.

20 20 Las operaciones se enumeran en el tercio inferior del cuadro de clase, el nombre de cada operación puede ir seguido de detalles opcionales como la lista de argumentos y el tipo de resultado. Una lista de argumentos se escribirá entre paréntesis a continuación del nombre, los argumentos irán separados por comas (,). El nombre y tipo de argumento pueden especificarse también. El tipo y el resultado vienen precedidos por dos puntos (:) y no deberían omitirse. Una lista de argumentos vacía entre paréntesis muestra que no existe argumentos. Ejemplos en los gráficos 7 8 y 9 Nombre edad Persona Gráfico 7 Cambiar de trabajo Cambiar dirección Archivo Nombre del archivo Tamaño en bytes Última actualización Imprimir Color posición Objeto geométrico Gráfico 8 Mover (delta: vector) Seleccionar (p: punto): Bolean Rotar (ángulo) Resumen de la notación: Nombre de la clase Nombre atributo 1 : tipo dato 1 = valor omisión 1 Nombre atributo 2 : tipo dato 2 = valor omisión 2 Gráfico 9 Nombre operación 1 (lista argumentos 1) : tipo resultado 1 Nombre operación 2 (lista argumentos 2) : tipo resultado 2

21 21 Enlaces y asociaciones: Los enlaces y asociaciones son los medios que nos permiten establecer relaciones entre objetos.. Enlace: es una conexión física o conceptual entre instancias de objetos, por ejemplo Juan Pérez trabaja para la compañía XYZ. Matemáticamente se define un enlace como una dupla, esto es, una lista ordenada de instancias de objetos. Un enlace es una instancia de una asociación.. Asociación: describe un grupo de enlaces con estructura y semántica comunes, por ejemplo una persona trabaja para una compañía, todos los enlaces de cada asociación conectan objetos procedentes de las mismas clases. Las asociaciones y los enlaces suelen aparecer como verbos en las definiciones de los problemas. Las asociaciones describen un conjunto de enlaces lo mismo que las clases describen un conjunto de objetos potenciales. Las asociaciones son inherentemente bidireccionales, el nombre de una asociación binaria suele leerse en un cierto sentido, pero la asociación binaria se puede recorrer en ambas direcciones. La dirección implicada por el nombre es la dirección hacia delante, la dirección opuesta es la dirección hacia atrás, por ejemplo: trabaja para conecta a una persona a la compañía, lo inverso sería da trabajo a entonces conecta la compañía a la persona. Las asociaciones suelen implementarse en los lenguajes de programación como punteros que van desde un objeto hasta otro. Un puntero es un atributo de un objeto que contiene una referencia explícita de otro objeto. La implementación de asociaciones en forma de punteros es perfectamente valido, pero las asociaciones, pero las asociaciones no deberían modelarse de esta forma. Los enlaces muestran una relación entre uno o más objetos. El modelado de un enlace como un puntero oculta el hecho consistente en que el enlace no forma parte de ninguno de los objetos por si mismo, sino que depende de ambos a la vez. Todas las conexiones entre clases deberían modelarse como asociaciones, incluso al modelar el programa, se insiste en que las asociaciones no son solamente construcciones de bases de datos, aun cuando las bases de datos relacionales se construyen basándose en el concepto de asociaciones. Aún cuando las asociaciones se modelan como bidireccionales, no es necesario implementarlo en ambos sentidos. Ejemplos en el gráfico 10 País Tiene como capital Ciudad Diagrama de clases nombre nombre (País) Ecuador Tiene como capital Gráfico 10 (Ciudad) Quito Diagrama de Instancias

22 22 La notación OMT para las asociaciones es una línea entre clases, se trazan los enlaces como líneas entre objetos, los nombres de las asociaciones se ponen en cursiva, se puede omitir el nombre de la asociación si su significado es obvia. Es bueno organizar las clases para que en lo posible se lean de izquierda a derecha. Las asociaciones pueden ser binarias, terciarias o de orden superior, en la práctica, la inmensa mayoría son binarias, las terciarias y de orden superior son complejas de dibujar y entender. Multiplicidad: Especifica el número de instancias de una clase que pueden estar relacionadas con una única instancia de una clase asociada. La multiplicidad limita el número de objetos relacionados. Se suele describir la multiplicidad como una o muchas, pero en general se trata de un subconjunto de los número enteros no negativos. Por ejemplo, el número de puertas de un coche es 2 ó 4. La multiplicidad se representa mediante símbolos especiales al final de las líneas de asociación, se pueden expresar mediante un número o mediante un conjunto de intervalos, tal como:. 1 uno exactamente. 1 + uno o más. 3-5 entre tres y cinco, ambos inclusive. 2,4,18 dos, cuatro, o bien dieciocho. Existen ciertos terminadores de líneas especiales que indican valores frecuentes de multiplicidad:. círculo negro es el símbolo OMT que denota muchos. O círculo en blanco denota opcional, es decir cero o uno.. una línea sin símbolos de multiplicidad denota una asociación uno a uno. La multiplicidad se escribe junto al final de la línea. Véase gráfico 11 Estación de trabajo consola Consola Gráfico 11 No hay que preocuparse excesivamente por la multiplicidad en las fases iniciales del desarrollo del software. Primero se determinan los objetos, clases y asociaciones, después se decidirá su multiplicidad. La distinción de multiplicidad más importante es la existente entre uno y muchos, subestimar la multiplicidad puede limitar la flexibilidad de una aplicación. Importancia de las asociaciones: Las asociaciones se han utilizado ampliamente en el modelado de bases de datos desde hace varios años, sin embargo, aquí se hace hincapié en que las asociaciones son estructuras de modelado útiles para los programas, así como para los sistemas de bases de datos y del mundo real, independientemente de la forma en que estén implementados. Atributos de los enlaces: Un atributo es una propiedad de los objetos de una clase. De manera similar, un atributo de enlace es una propiedad de los enlaces de una asociación.

23 23 En el gráfico 12, permiso de acceso es un atributo de puede acceder. Puede acceder Archivo Usuario Gráfico 12 Permiso de acceso Archivo 1 Archivo 2 Archivo 3 (lectura) (lectura escritura) (Lectura escritura) Juan Pérez María García Pedro León La notación OMT para un atributo de enlace es un cuadro ligado a la asociación mediante un lazo, esta notación hace hincapié en la similitud existente entre los atributos de los objetos y los atributos de los enlaces. Modelado de una asociación: (gráfico 13) En algunos casos resulta útil modelar la asociación como clases, cada enlace pasa a ser una instancia de la clase. El cuadro de atributos puede poseer un nombre, unas operaciones y sus atributos. El ejemplo siguiente muestra la información de autorizaciones para usuarios de estaciones de trabajo, los usuarios pueden estar autorizados a trabajar en muchas estaciones, cada autorización conlleva unos privilegios de prioridad de acceso, que se muestran en forma de atributos de enlace, cada usuario tiene un directorio origen para cada estación, pero un mismo directorio puede ser compartido por varios usuarios. Está autorizado en Usuario Est. trabajo Autorización Prioridad privilegios Comenzar sesión Directorio Gráfico 13 Es de utilidad modelar las asociaciones como clases cuando estos pueden participar en asociaciones con otros objetos, o cuando están sometidos a operaciones