DesarrolladoresDesarrolladores Domine el lenguaje de modelado más utilizado en la actualidad » Paradigma orientado a objetos y su relación con UML » Detalles de uso y aplicación de los diagramas » Modelado dinámico y funcional » Adaptación a Visual Paradigm » Guías de análisis y diseño de sistemas » Razonamiento basado en propiedades UML U M L D e s a r r o l l a d o r e s CONTENIDO 1 | EL MODELADO Introducción al modelado / Surgimiento de los modelos / Modelos y sistemas / El rol de los modelos en la Ingeniería de Software / Errores, ingeniería y modelos de software / Características del modelado 2 | INTRODUCCIÓN A UML Historia de UML / Primeros pasos / Herramientas / Visual Paradigm / Sabores de la herramienta / Instalar Visual Paradigm / Configurar el entorno / Modelos dinámicos / Estructura estática y dinámica 3 | COMENZAR A MODELAR Modelado estático / Modelar clases / Constructores de clase para UML / Atributos y operaciones / Notas / Modelar relaciones / Generalizaciones / Dependencias / Asociaciones / Agregación y composición / Asociaciones como clases 4 | ORGANIZAR LOS DIAGRAMAS Organización de diagramas / Tipos de diagrama / Metamodelo de UML / Diagrama de clases / Composición y objetivos / Interfaces y herencia múltiple / Diagrama de objetos / Diferencias entre instancias y clases / Independencia / Composición / Modelado / Diagrama de objetos en Visual Paradigm / Multiplicidad / Expresividad / Diagrama de paquetes / Paquetes en UML / Modelar la arquitectura / Diagrama de componentes 5 | REQUERIMIENTOS Y CASOS DE USO Requerimientos / Definiciones / Clasificación / Características / Ciclo / Capturar requerimientos / Casos de uso / Constructores / Clasificación / Especificación en Visual Paradigm / Estructura interna / Descripción / Formalidad e informalidad 6 | MODELAR LAS ACCIONES Modelado dinámico / Conceptos dinámicos / Constructores / Diagramas de interacción / Clasificación / Completitud / Diagramas de secuencia / Categorías de los mensajes / Diagramas de colaboración / Diagramas de actividad / Origen y elementos / Los diagramas en Visual Paradigm 7 | MÁQUINAS DE ESTADO Modelado dinámico avanzado / Máquinas de estado / Estados / Transiciones / Diagramas de estado en Visual Paradigm / Especificar estados, transiciones y requerimientos temporales 8 | MODELADO AVANZADO Herramientas avanzadas y automáticas / Generación automática de código y documentación / Ingeniería inversa / Ingeniería Inversa en Visual Paradigm / Generación de modelos desde máquinas de estado / Construcción APÉNDICE: OTRAS HERRAMIENTAS DE MODELADO Este libro es la guía adecuada para iniciarse en el mundo del modelado. A través de ejemplos concretos, conoceremos todos los constructores y elementos necesarios para comprender la construcción de modelos, y adquiriremos las habilidades para razonar modelos que reflejen los comportamientos de los sistemas. Una obra que trasciende UML: nos acerca a la etapa de modelado de sistemas y nos permite sumergirnos dentro de una visión llena de abstracciones, propiedades y comportamiento. Introduce técnicas de análisis y diseño de sistemas y explora en profundidad Visual Paradigm for UML. Una oportunidad de ver el software desde una perspectiva de modelos, alejándonos del concepto de software como código y reconociendo la importancia de la etapa del modelado dentro de los procesos actuales de desarrollo de software y de los modelos para la construcción robusta de programas. En este sitio encontrará una gran variedad de recursos y software re- lacionado, que le servirán como complemento al contenido del libro. Además, tendrá la posibilidad de estar en contacto con los editores, y de participar del foro de lectores, en donde podrá intercambiar opiniones y experiencias. libros.redusers.com Para más información comuníquese con nuestro Servicio de Atención al Lector
[email protected] ARGENTINA ✆ (11) 4110 8700 CHILE ✆ (2) 335 7477 ESPAÑA ✆ (93) 635 4120 MÉXICO ✆(55) 5350 3099 UML An ideal work to those willing to set off for the modelling voyage. A book that will help us recognize the importance of the modelling stage in present software development processes as well as that of models to construct robust software. NIVEL EXPERTO AVANZADO INTERMEDIO PRINCIPIANTE Desarrollador .NET Fernando Asteasuain tapa uml.qxp 06/04/2009 08:41 a.m. PÆgina 1 CONÉCTESE CON LOS MEJORES LIBROS DE COMPUTACIÓN EL LIBRO IDEAL PARA QUIENES NO ADMITEN LOS LÍMITES MANUALES USERS I 320 páginas I ISBN 978-987-1347-90-2 CONOZCA LAS TÉCNICAS DE LOS HACKERS MANUALES USERS I 320 páginas I ISBN 978-987-1347-93-3 GRABACIÓN, MEZCLA, EDICIÓN Y MASTERING MANUALES USERS I 320 páginas I ISBN 978-987-1347-75-9 usershop. redusers. com APRENDA A PROGRAMAR CON EL LENGUAJE MÁS FLEXIBLE DESARROLLADORES I 368 páginas I ISBN 978-987-1347-81-0 RT_Bombo_LIBROUML.qxp 31/03/2009 11:04 Página RT2 El modelado Introducción al modelado 14 Modelos y sistemas 22 El rol de los modelos en la Ingeniería de Software 23 Resumen 29 Actividades 30 Capítulo 1 En este capítulo comprenderemos qué son los lenguajes de modelado y las principales razones de su utilización. Conoceremos nociones básicas de Ingeniería de Software, aprenderemos a diferenciar entre modelo y sistema, y entenderemos las principales características de un lenguaje de modelado. UML SERVICIO DE ATENCIÓN AL LECTOR:
[email protected] 01_UML.qxp 31/03/2009 3:20 PÆgina 13 ❘❘❘ INTRODUCCIÓN AL MODELADO En la actualidad, pensar en un desarrollo de software sin pasar por una etapa de modelado es prácticamente imposible. La utilización de modelos es una metodo- logía aceptada y recomendada no sólo académicamente, sino también dentro del ambiente profesional privado. De hecho, desde las más altas jerarquías en la pirá- mide empresarial determinan las políticas que se aplicarán para el empleo de modelos en el desarrollo de productos de software. Los modelos actuales que representan sistemas de software son creados a través de lenguajes de modelado. Como los lenguajes de programación, éstos también tie- nen una sintaxis (la forma de los elementos del lenguaje) y una semántica (el sig- nificado de esos elementos) definida. Existen muchos lenguajes de modelado, cada uno con diferentes propósitos. Algunos son específicos para un área en particular, como base de datos o sistemas de tiempo real, y otros son de propósito general, para todo tipo de aplicaciones. Nuevamente, notamos que hay una similitud con los lenguajes de programación. Sin embargo, los lenguajes de modelado tuvieron que luchar bastante para tener el respeto y el merecimiento que tienen hoy día. En este libro trataremos en pro- fundidad el lenguaje de modelado UML, considerado prácticamente como un estándar dentro de la comunidad científica. Antes de adentrarnos en UML, es necesario definir el contexto y precisar algunas cuestionas generales. En el resto de este capítulo inicial conoceremos qué son los lenguajes de modelado, su importancia dentro del desarrollo de software, la necesidad de modelar y su evo- lución desde sus comienzos hasta la actualidad. ¿Qué son los lenguajes de modelado? Los lenguajes de modelado son la herramienta que utilizamos para construir nues- tros modelos del sistema. Ahora bien, ¿qué son los modelos? Seguramente no poda- mos dar en este momento una respuesta precisa (esperemos poder hacerlo cuando terminemos el último capítulo del libro), pero es seguro que hemos utilizado el con- cepto previamente en muchísimas situaciones. Veamos algunos ejemplos. 1. EL MODELADO 14 Los lenguajes de modelado son, estructuralmente, similares a los de programación. Así como un lenguaje de programación nos da errores de compilación por no respetar su sintaxis, lo mismo pasará en el modelado si no respetamos las formas establecidas. La mayoría de los len- guajes de modelado no se ejecutan, pero es posible la generación de código a partir de modelos. COMO LOS LENGUAJES DE PROGRAMACIÓN 01_UML.qxp 31/03/2009 3:20 PÆgina 14 Una de las primeras cosas que hacemos cuando llegamos al destino de nuestras vaca- ciones es pasar por la oficina de turismo a buscar un folleto con un mapa donde estén las referencias de los lugares para comer, para alojarse, de entretenimiento y las princi- pales atracciones turísticas del lugar. Ese mapa, que nos acompañará durante toda nues- tra estadía (si tenemos suerte de no perderlo), no es más que un modelo de nuestro des- tino de vacaciones. Generalmente es pequeño, puede doblarse fácilmente para guar- darlo en algún bolsillo y tiene todo lo necesario para que podamos desenvolvernos tran- quilamente en la ciudad y disfrutemos de nuestras vacaciones. Otra característica importante es que es visualmente atractivo y fácil de comprender, de manera que en un vistazo rápido reconoceremos los aspectos más importantes. Usualmente, en la parte de atrás, tenemos más información de cada lugar, por ejemplo, los teléfonos de los hoteles disponibles en la región. De esta manera, tenemos un panorama general, pero al mismo tiempo podemos obtener información más específica fácilmente. Entonces, podemos decir que un modelo es una abstracción de una entidad del mundo real, que nos ayuda a entenderla y a comprenderla en todas sus caracterís- ticas y funcionalidades. Como en el ejemplo del folleto turístico, es fundamental que sea simple, capaz de adaptarse a las necesidades de mayor o menos abstracción (esto es, poder ver los elementos con distintos niveles de detalle), y con una nota- ción gráfica. Este último aspecto es trascendental y vital: de nada sirve un mode- lo si visualmente resulta extraño de comprender. Figura 1. Esquema con las características de los lenguajes de modelado. Surgimiento de los modelos El surgimiento de los modelos de software está íntimamente relacionado con la evolu- ción de las Ciencias de la Computación y, en particular, de la Ingeniería de Software. Los primeros sistemas de software eran puramente aplicaciones científicas, llevadas a Semántica Sintaxis Lenguajes de Modelado Poseen Características Abstracción Visual Simplificación Introducción al modelado 15 01_UML.qxp 31/03/2009 3:20 PÆgina 15 cargo generalmente por una sola persona. A medida que los cambios tecnológicos, científicos y de hardware fueron sucediendo, la situación cambió drásticamente. Podemos enumerar esta evolución desde cuatro puntos de vista: según los lenguajes de programación, según las aplicaciones, según el perfil del programador y según la con- fiabilidad esperada. Analicemos cada uno de ellos. Evolución desde los lenguajes de programación Podemos nombrar la evolución en los lenguajes de programación de la siguiente manera. Inicialmente, los primeros programas se codificaban a través de tarjetas perforadas. Una tarjeta perforada es un pedazo de papel que representa informa- ción digital a través de la presencia o ausencia de agujeros en posiciones fijas. Luego, los lenguajes fueron mutando de programar con tarjetas perforadas a emplear ceros y unos, accediendo directamente a registros de memoria con directivas del lengua- je Assembler. Luego pasaron a instrucciones de alto nivel de Java, como por ejem- plo, GetConnection, para conectarse a una base de datos o a los constructores para recorrer estructuras de datos como el foreach. Los lenguajes de programación incorporan cada vez más constructores de mayor nivel de abstracción para asegurarnos una programación más simple y carente de errores. Otra evolución importante surge con los entornos cada vez más completos de programación como Eclipse, NetBeans o Spring, que brindan mayor poder de expresividad y seguridad al programador. Figura 2. Dispositivo para trabajar con tarjetas perforadas La utilización de estos modernos frameworks complejos dio lugar a lo que se cono- ce como middleware. En estos frameworks es bastante común encontrar funciona- 1. EL MODELADO 16 01_UML.qxp 31/03/2009 3:20 PÆgina 16 lidad predefinida para manejar conceptos como seguridad, transacciones o persis- tencia. Asimismo, proveen capacidad para manejar trabajo en equipos distribuidos. En este sentido, una de las mayores dificultades en los ambientes distribuidos es el debugging de código. Encontrar un error en ambientes de ejecución paralela o con- currente es extremadamente difícil. Evolución desde las aplicaciones Las primeras aplicaciones consistían en complejos cálculos matemáticos sobre enor- mes computadoras que ocupaban habitaciones enteras. Por ejemplo, la computa- dora ENIAC, presentada en público en 1946, ocupaba una superficie de 167 metros cuadrados y pesaba unas 27 toneladas. En cuanto a su capacidad, podía resolver 5.000 sumas y 360 multiplicaciones en un segundo. Con el paso del tiem- po, la tecnología avanzó y las aplicaciones fueron creciendo cada vez más, hasta lle- gar a la actualidad. Hoy tenemos prácticamente cualquier tipo de computación sobre pequeñísimos chips para teléfonos celulares u hornos microondas, por men- cionar dos casos. La computación interactúa con nosotros constantemente al estar presente en cajeros, sistemas de videoclub, manejo de información, telefonía, comu- nicación, Internet, juegos, animación, cine, música, sistemas de monitoreo de pacientes y reactores, entre algunos ítems de una lista infinita. La presencia y la posibilidad de cómputo actuales han influido y potenciado otras áreas como la medicina, el desarrollo de medicamentos, la robótica, el reconocimiento de huellas digitales o de retina, la biogenética, etcétera. Figura 3. Una imagen de la computadora ENIAC. Introducción al modelado 17 01_UML.qxp 31/03/2009 3:20 PÆgina 17 Evolución desde el perfil del desarrollador En la actualidad, los equipos de trabajo dedicados al desarrollo de software son multipersonales e interdisciplinarios, con jerarquías desde arquitectos, líderes de proyecto, analistas funcionales, testers, programadores, etcétera. Estos estructurados equipos actuales de desarrollo son fruto de investigaciones en la teoría de las inte- rrelaciones y manejo de grupos. Por el contrario, en los primeros programas de computación el equipo de desarrollo consistía, en general, de una única persona que llevaba toda la responsabilidad del proyecto. Evolución desde la confiabilidad esperada Como dijimos, las primeras computadoras eran enormes aparatos que ocupaban habitaciones enteras. Programarlas para llevar a cabo una tarea no era para nada tri- vial, y su preparación llegaba a ocupar días enteros. Bajo este contexto, los errores eran esperables y se tardaba días o semanas en corregirlos. La anécdota cuenta que por esos tiempos nació el concepto de bug (del inglés, insecto) para nombrar el error de un programa ya que la presencia de insectos dentro de las computadoras causaba fácilmente problemas de hardware. En la actualidad, en cambio, se busca intensamente y cada vez más la ausencia de errores en el software. Para esto, se han desarrollado sofisticadas estrategias forma- les para la detección de errores, manejo de riesgo, mantenimiento y evolución. Figura 4. La evolución del software transformó la utilización de modelos. De una etapa considerada como poco productiva o inútil, pasó a ser una etapa imprescindible en cualquier proceso de desarrollo. Cambios en los procesos de desarrollo Como vimos, mucho ha cambiado en lo que se refiere al empleo y a la utilización de computadoras, mostrándose un gran avance y maduración. Todos estos cambios influyeron en la manera y en los pasos que se siguen durante el proceso de crear y Aplicaciones Evolución M O D E L O S Perfil Lenguaje Confiabilidad Demanda 1. EL MODELADO 18 01_UML.qxp 31/03/2009 3:20 PÆgina 18 desarrollar software específico. Como mencionamos, los primeros programas eran implementados por una sola persona sin que existiera la noción de análisis o mode- lo más allá de la idea en la mente del único programador a cargo. A medida que los proyectos fueron creciendo en magnitud y se fue acrecentando la injerencia de la computación en el desenvolvimiento de la sociedad, este prototipo de equipo quedó obsoleto. Más personas fueron asignadas a cada proyecto y nació la necesi- dad de primero poner en papel los conceptos que luego serían implementados. Este período es conocido como la Crisis del Software (año 1968), momento en el que se reunieron expertos de la comunidad para enfrentar los siguientes proble- mas en el desarrollo del software: • Los proyectos no terminaban en los plazos estipulados. • No se cumplían los presupuestos planeados. • Se obtenía un código final de baja calidad que no cumplía las especificaciones planteadas inicialmente. Estos cambios introdujeron nuevas etapas en los procesos de desarrollo. Básicamente, los procesos de desarrollo cuentan con las siguientes etapas. La pri- mera de ellas consiste en la recolección de requerimientos, es decir, establecer las responsabilidades y funcionalidades del sistema. La segunda etapa se concentra en el análisis y el diseño. En ésta, los actores protagónicos son los lenguajes de modelado y los modelos que son creados a partir de ellos. El principal objetivo de esta etapa es obtener una visión completa del sistema, a través de modelos que correctamente abstraigan las principales características y el comportamiento espe- rado del sistema. Luego, se pasa a la etapa de implementación del producto. Esto significa su codificación y programación. Finalmente, se lanza el sistema a pro- ducción, pasando previamente por una etapa de testing en la que se valida el com- portamiento del sistema. Una vez que el sistema entra en funcionamiento, los cam- bios en los requerimientos y la corrección de errores involucran las tareas princi- pales en la actividad que se conoce como mantenimiento del sistema. Sin embargo, los más novedosos procesos de desarrollo incorporan dos etapas más. La primera de ellas, conocida como arquitectura del sistema, se sitúa entre la captura Introducción al modelado 19 En muchos procesos de desarrollo, la parte de verificación formal está presente a lo largo de todo el proyecto. Muchas propiedades son verificadas a través de un proceso automatizado cono- cido como Model Checking. Se basa en componer el sistema bajo análisis con la propiedad a ser verificada, para poder obtener conclusiones sobre el sistema completo. ❴❵ MODEL CHECKING 01_UML.qxp 31/03/2009 3:20 PÆgina 19 de requerimientos y el análisis y diseño. El objetivo es modelar los principales com- ponentes del sistema junto con su interacción básica. Algunos esquemas clásicos de arquitectura son la cliente/servidor o la Pipe and Filter. La segunda nueva etapa es de validación y verificación formal, la cual se sitúa generalmente antes del lanza- miento del software en pos de asegurarnos el correcto funcionamiento del sistema, a través de técnicas matemáticas formales. Existen varios procesos de desarrollo de software, pasando por el clásico modelo de cascada hasta los más modernos, como los procesos ágiles de desarrollo. Si bien son bastante diferentes entre sí, con distintos objetivos y áreas de aplicación, las eta- pas que mencionamos anteriormente se ven reflejadas en cualquier proceso de desa- rrollo, de una manera u otra. Figura 5. Esquema de los procesos de desarrollos modernos. Como anécdota final de esta sección, vale la pena mencionar cómo nacieron los procesos ágiles de desarrollo. El proceso de desarrollo a través de métodos ágiles sigue un manifiesto creado en 2001. En un paradisíaco spa en Salt Lake City se reu- nieron varios expertos críticos de los sistemas tradicionales y plasmaron el resulta- do de la reunión en un manifiesto con cuatro puntos principales: Análisis y Diseño Arquitectura Requerimientos Codificación Testing Mantenimiento 1. EL MODELADO 20 ❘❘❘ REPETICIÓN DE ETAPAS Una parte de los procesos de software lleva varias iteraciones hasta alcanzar el producto final. Es bastante común, por ejemplo, que una vez que está terminada la etapa de diseño se vuelvan a controlar los requerimientos a través de la nueva información obtenida. Cambios en los reque- rimientos generarán nuevos modelos y así sucesivamente hasta obtener un modelo sólido. 01_UML.qxp 31/03/2009 3:20 PÆgina 20 • En primer lugar, valorar más a los individuos y a su interacción que a los pro- cesos y las herramientas. • Valorar la funcionalidad del software por sobre su documentación exhaustiva. • Valorar más la colaboración con el cliente que la negociación contractual. • Valorar más la respuesta a los cambios que el seguimiento de un plan. Lenguajes de modelado: un poco de su historia Si bien se vio la necesidad de contar con lenguajes de modelado y se reconoció su rol fundamental en el proceso de desarrollo, la industria profesional tardó en adop- tarlos y ponerlos en práctica. Las principales dificultades que se encontraron aque- llos que defendían la noción de lenguajes de modelado y de modelos que repre- sentaran la funcionalidad del sistema radicaron, esencialmente, en la inversión de tiempo y recursos para aprender todo un nuevo lenguaje y que la salida de todo este proceso no fuera nada que se pudiera ejecutar. El proceso de modelado se veía entonces como un proceso costoso y poco productivo. Sin embargo, dos cuestiones trascendentales acontecieron y favorecieron el éxito de los lenguajes de modelado. La primera de ellas fue el reconocimiento, por parte de la industria, de que cuanto antes sea encontrado un error, más considerables serán los beneficios económicos, ya que el costo de corregir una equivocación aumenta de forma exponencial en el tiempo a medida que el proyecto avanza. Es decir, si repa- rar una falla en la etapa de modelado en la segunda semana del proyecto tiene costo dos, hacerlo durante la etapa de testing, en el séptimo mes del proyecto, tiene un costo de dos mil cuarenta y ocho. El segundo factor decisivo provino de la comu- nidad que abogaba por el empleo de lenguajes de modelado. Comprendieron que para que fueran utilizados, estos lenguajes debían ser mucho más simples, maneja- bles, con una semántica clara y visualmente atractivos. En la actualidad, los modelos tienen un rol preponderante en el desarrollo de soft- ware. Modelos del sistema circulan entre los analistas funcionales, los programa- dores, los gerentes y los clientes, y todas las partes involucradas comprenden lo que están viendo y pueden debatir las distintas opciones para el mejor desempeño del producto que se va a desarrollar. La utilización de modelos tiene un beneficio Introducción al modelado 21 Como sucede con otras especialidades, en las Ciencias de la Computación existen diversas defi- niciones para los conceptos generales que son clave, como sistema, software o, incluso, Ingeniería de Software. Lo importante, más allá de nuestra preferencia de alguna sobre las demás, es comprender todos los elementos involucrados detrás de cada definición. ❘❘❘ DEFINICIONES 01_UML.qxp 31/03/2009 3:20 PÆgina 21 1. EL MODELADO 22 implícito que es, justamente, proveer una base común de entendimiento para que todas las partes implicadas puedan comunicarse y estar hablando de las mismas cosas, refiriéndose a los mismos conceptos. Es decir, los modelos nos permiten transmitir información sobre el sistema de manera clara y precisa. Figura 6. Ejemplo de trabajo con código y modelos en un entorno moderno como Eclipse. MODELOS Y SISTEMAS Los modelos representan una abstracción de nuestro sistema que nos permite con- centrarnos en los detalles que más nos interesan, dejando de lado otros aspectos secundarios. En este sentido, es importante reconocer que los modelos no son el sis- tema. Los modelos deberán seguir su proceso hasta convertirse, en el futuro, en el sistema implementado. Una pregunta razonable que nos podemos hacer en este momento es cómo podemos estar seguros de que la implementación que nos da como salida la etapa de codificación respeta los modelos planteados en la etapa de análisis y diseño. Podemos abarcar esta cuestión desde tres lugares. Como primera medida, es fundamental el total entendimiento del lenguaje de modelado y de los modelos desarrollados por estos lenguajes, tanto por parte de los programadores como de los líderes de proyecto. De esta manera, nos asegura- mos de que los programadores codifiquen correctamente el comportamiento expresado en nuestros modelos. Por otro lado, también es importante tener en cuenta que si hay una situación en la que por razones de implementación (por ejemplo, la ubicación física de un servidor) es necesario introducir cambios en los 01_UML.qxp 31/03/2009 3:20 PÆgina 22 modelos del sistema, éstos sean correctamente documentados para así poder man- tener siempre una relación estrecha y directa entre los modelos y el código. Otra alternativa es brindada directamente por los entornos de los lenguajes de mode- lado. Esto lo veremos en particular más adelante cuando nos centremos en el len- guaje de modelado UML y la herramienta Visual Paradigm. En general, la situa- ción es similar con otros entornos y lenguajes donde existe la posibilidad de ir lle- vando el rastro de nuestras entidades en un modelo hasta su resultante entidad en el código. Manteniendo este mapeo, es decir, esta unión entre los conceptos del modelo y los conceptos del código, detectar cualquier ambigüedad o incon- sistencia es muchísimo más simple y consume menos tiempo. Por último, existen procesos de desarrollo que intentan maximizar los procesos de automatización dentro del desarrollo de software, es decir, partir de modelos que automáticamente se transforman en el producto final. Esta técnica se conoce como Model-Driven Development o Desarrollo Basado en Modelos. Otras herra- mientas nos permiten, a partir de modelos, crear esqueletos o armazones de nues- tro sistema, a través de los cuales podemos imaginarnos cómo será el producto final. Resulta claro que introducir cambios en estos esqueletos es mucho más sen- cillo que hacerlo en el sistema final, de la misma manera que llevar a cabo modi- ficaciones en el plano de una habitación es mucho más sencillo que efectuarlos en la habitación en sí. Imaginemos que realizar una nueva división en la habitación consiste en trazar una línea en el plano, mientras que levantar realmente la pared en la habitación es una tarea mucho más compleja. EL ROL DE LOS MODELOS EN LA INGENIERÍA DE SOFTWARE La utilización de modelos es el caballito de batalla de la Ingeniería de Software. Pero ¿qué es la Ingeniería de Software? Y aún antes, ¿qué entendemos por software? La definición tradicional sugiere que un sistema de software es una colección de com- El rol de los modelos en la Ingeniería de Software 23 El primer tipo de herramienta para la construcción de software basada en transformación suce- siva de modelos fue la herramienta CASE (Computer-Aided Software Engineering), aparecida en 1980. Las herramientas CASE pueden clasificarse según las plataformas que soportan, los ciclos de desarrollo que afectan y las arquitecturas de software que resultan de su aplicación. ❴❵ CASE 01_UML.qxp 31/03/2009 3:20 PÆgina 23 ponentes interrelacionados que trabajan conjuntamente para cumplir algún obje- tivo. Sin embargo, una definición más adecuada sería: un conjunto de entidades cuyo comportamiento dará solución a un problema inicial, y será ejecutado automáticamente (por computadoras). Esta definición es más adecuada por las siguientes razones: • Entidad es un concepto más abstracto que el concepto de componente. Además, hablar de componentes puede orientar hacia la Programación Basada en Componentes y generar, así, una confusión. • Hace explícita la palabra comportamiento, que resulta más precisa y adecua- da que la palabra interacción. • Hace referencia explícita también a un problema inicial, el cual se quiere resolver. Es fundamental comprender que el sistema de software no es únicamente el CD o DVD que contiene el programa, sino que el concepto de entidad abarca también, además del código, toda la documentación del sistema, incluyendo sus modelos. Además, se desprende de la definición que las entidades colaborarán entre sí para lograr su objetivo, y que el comportamiento individual afectará e impactará en las demás. Por lo tanto, es fundamental que la interacción de las entidades esté correc- tamente ilustrada y reflejada en nuestros modelos del sistema. Finalmente, la IEEE (Institute of Electrical and Electronics Engineers) define al software como la suma total de los programas de computadora, procedimientos, reglas, la docu- mentación asociada y los datos que pertenecen a un sistema de cómputo. Errores del software versus errores del diseño En algunas ocasiones, se confunden los errores propios del software con errores del diseño. El software es intrínsecamente flexible y debemos estar preparados para ello. Supongamos que hemos desarrollado un sistema para capturar mensajes de transmisión por radio. Es implementado correctamente, es instalado y su funcio- namiento es el esperado. Sin embargo, por razones operativas, un mes después, el servidor donde funciona nuestro software se cambia de piso en el edificio donde 1. EL MODELADO 24 ❴❵ IEEE La IEEE auspicia y organiza muchas conferencias de Ingeniería de Software a nivel mundial. Entre ellas, podemos mencionar ICSE (International Conference on Software Engineering). También mantiene numerosas revistas y publicaciones en todos los temas relacionados con las Ciencias de la Computación. La mayoría de las publicaciones están disponibles en su sitio web. 01_UML.qxp 31/03/2009 3:20 PÆgina 24 funciona la empresa cliente. En este nuevo lugar, se producen interferencias con otros aparatos tecnológicos y nuestro programa comienza a fallar. La solución con- siste en mejorar la recepción de la señal, pero estos cambios degradan notable- mente la perfomance y vuelven demasiado lenta la ejecución normal de nuestro sistema. ¿Estamos frente a una falla de software o frente a una falla en el diseño? La segunda opción es la correcta. Debió estar mejor contemplada la interacción entre la perfomance y el impacto de cada entidad en ella. Ingeniería de Software Ahora que tenemos una definición más certera de los sistemas de software, pode- mos encarar la definición de Ingeniería de Software. Algunas definiciones que encontramos son las siguientes: • La Ingeniería de Software es la rama de la Ingeniería que aplica los principios de las Ciencias de la Computación y las Matemáticas para lograr soluciones costo-efectivas (eficaces en costo o económicas) a los problemas de desarrollo de software, es decir, permite elaborar consistentemente productos correctos, utilizables y costo-efectivos. • La Ingeniería de Software involucra construir un producto de software de alta calidad lidiando con las múltiples restricciones (tiempo, presupuesto y demás). • La disciplina de Ingeniería de Software involucra conocimiento, herramientas y métodos para definir y capturar los requerimientos, realizar el diseño del sis- tema y su correspondiente codificación, validación y mantenimiento. La Ingeniería de Software se nutre de conocimientos de otras áreas como Ingeniería Computacional, Ciencias de la Computación, Administración de Empresas, Matemática, Administración de Proyectos, Administración de Calidad e Ingeniería de Sistemas. • Por último, la definición de IEEE dice que la Ingeniería de Software es la apli- cación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software. En términos prácticos, es un área o disciplina de la Informática que ofrece métodos y técnicas para desarrollar y mantener software de calidad. De todas estas definiciones podemos obtener en claro los siguientes aspectos: la Ingeniería de Software debe lidiar con la escalabilidad y la complejidad de siste- mas de software, identificando claramente aquello que se pretende por software de alta calidad. A su vez, requiere, como todas las ingenierías, rigor, creatividad, docu- mentación y gestión. Por último, es una actividad multidisciplinaria. Como toda ingeniería, se rige a través de principios. Cubrirlos está fuera del alcan- ce de este libro, pero bien vale la pena, al menos, enunciarlos. Algunos de ellos son: El rol de los modelos en la Ingeniería de Software 25 01_UML.qxp 31/03/2009 3:20 PÆgina 25 rigor y formalidad, separación de conceptos, abstracción, modularidad, flexibi- lidad, anticipación al cambio, incrementabilidad, rastreabilidad, manejo de errores, cohesión y acoplamiento, correctitud, confiabilidad, portabilidad, reusabilidad, eficiencia y, finalmente, facilidad de uso. A través de la utilización de estos principios y siguiendo un método claro de Ingeniería de Software, desa- rrollaremos software de alta calidad que cumple con su objetivo. Modelos de software Con lo que hemos visto hasta ahora sabemos que los modelos son una simplifica- ción del sistema que queremos construir. La principal razón para modelar es com- prender más profundamente el sistema que vamos a desarrollar. A través del mode- lado obtenemos los siguientes beneficios: • Visualizar en etapas tempranas del desarrollo el comportamiento del sistema. • Especificar tanto el comportamiento como la estructura del sistema. • Documentación formal del sistema. • Guiar el desarrollo del sistema. Los modelos no sólo son útiles en grandes proyectos, sino que también lo son en proyectos pequeños y medianos. Aún las golosinas para niños que vienen con pequeños juguetes para armar tienen un folleto de instrucciones y un dibujo de cómo se ve el juguete una vez armado. Es decir, la golosina viene acompañada no sólo con el juguete, sino también con su modelo. También es cierto que aunque la construcción de modelos en sistemas pequeños es sumamente recomendable, quizás el sistema puede implementarse sin ellos. Sin embargo, para proyectos o sistemas con mayor estructura y comportamiento, es directamente imposible. Un sistema puede ser tomado desde muchos puntos de vista: a partir de su estructura, su jerarquía, su comportamiento, sus características, de manera interna, de manera externa, desde alguna funcionalidad en especial (por ejem- plo, el sistema la seguridad, etcétera). En ocasiones, será necesario concentrarse en detalle en un componente en especial, conociendo sus atributos, sus métodos 1. EL MODELADO 26 ❴❵ ORIGEN DE INGENIERÍA DE SOFTWARE El término Ingeniería de software fue usado por primera vez en 1968 durante una reunión de la OTAN por la crisis del software. Si bien es atribuido a F.L. Bauer, Edsger Dijkstra lo utilizó en su libro The Humble Programmer. Uno de los problemas más graves detectados en ese momento fue la falta de técnicas para poder estimar el costo y el tiempo de los proyectos de software. 01_UML.qxp 31/03/2009 3:20 PÆgina 26 y la funcionalidad que provee. En otras, quizá queramos apreciar cómo interactúa con otros componentes, por lo que nos alcanzará con ver únicamente el nombre del componente y obviar su comportamiento interno. Existen muchos modelos para nuestro sistema y cada uno muestra un punto de vista en particular, o pro- vee menor o mayor nivel de detalle sobre los componentes. Así como un sistema se divide en subsistemas menores de manera tal que la cola- boración de todos ellos permite solucionar el problema planteado, un modelo tam- bién se divide en distintos submodelos, y cada uno de ellos muestra y se enfoca en un área en particular. Planteado en términos de operaciones de conjuntos, la inter- sección de todos ellos dará como resultado el modelo de nuestro sistema. Características del modelado Así como mencionamos los principios de la Ingeniería de Software, también existen características distintivas para la especificación de propiedades y el comportamiento a partir de modelos de software. A continuación, las encontraremos descriptas: • Los modelos son multimórficos: los modelos pueden tomar múltiples formas. El estilo particular de cada modelo está íntimamente relacionado con el tipo de proyecto en marcha. Si necesitamos simular el comportamiento de las mareas en una determinada laguna, quizás un modelo matemático a partir de integra- les de Gauss y software de simulación sea el modelo adecuado. Si, en cambio, necesitamos estudiar el trayecto óptimo para que un viajante pueda recorrer todas las ciudades que necesita en el menor tiempo posible, entonces el mode- lo matemático de grafos nos viene a la perfección. Lo mismo ocurre con nues- tros sistemas: existen modelos enfocados en la arquitectura, en la estructura estática, basados en el comportamiento, etcétera. Ante cada sistema, debemos pensar en los tipos de modelos que vamos a utilizar. • Los modelos deben manejar distintos niveles de abstracción: supongamos que tenemos el modelo finalizado de nuestro sistema y lo queremos presentar a los gerentes del proyecto. Si llevamos todos y cada uno de los diferentes mode- los, la reunión será un fracaso ya que habrá una cantidad enorme de modelos. Quizá, lo más conveniente sea llevar un modelo de la arquitectura donde se vea El rol de los modelos en la Ingeniería de Software 27 Los modelos del sistema forman una parte crítica en la documentación del sistema. Todos los cambios introducidos en la etapa de implementación tienen que reflejarse a través de cambios en los modelos. Un modelo desactualizado tiene escaso valor. Tener los modelos actualizados es fundamental para facilitar la tarea al momento de introducir cambios. ❘❘❘ ACTUALIZAR LOS MODELOS 01_UML.qxp 31/03/2009 3:20 PÆgina 27 la interacción de los principales componentes. En caso de querer profundizar en el comportamiento de alguno de ellos, tendremos listo el modelo de ese compo- nente en particular. De esta manera, logramos el efecto zoom in-zoom out sobre las propiedades salientes del sistema. • Los modelos deben ser coherentes: de poco sirve un modelo sobre el compor- tamiento de un tren si no tiene en cuenta la capacidad de peso que soportan las vías. Es decir, debemos incorporar a nuestro modelo la mayor cantidad de infor- mación posible del entorno sobre el cual nuestro sistema se ejecutará. Cualquier tipo de información que sea relevante y no sea incorporada a nuestro modelo ter- minará repercutiendo negativamente en la calidad del software desarrollado. • Todos los modelos cuentan: hemos visto cómo diferentes modelos capturan dis- tintos puntos de vista del sistema. No es aconsejable tomar decisiones basándonos en uno solo, ignorando el resto, ya que hay variables y parámetros que están sien- do excluidos y que son importantes para la decisión en cuestión. Por ejemplo, si seguimos únicamente el punto de vista de eficiencia, obtendremos un sistema que se ejecute muy rápido, pero seguramente muy poco amigable. Todos los distintos criterios y puntos de vista deben balancearse. Figura 7. Un modelo UML que describe las características del modelado. Modelar el mundo de la orientación a objetos Un alto porcentaje de los modelos construidos en la actualidad tienen como meca- nismo subyacente el mundo de la orientación a objetos. La principal razón de este hecho es que el modelado con objetos permite mantener una relación casi directa con la realidad, y así poder comprender más fácilmente la interacción entre todos los componentes, por más compleja que sea. Por ejemplo, si quisiéramos modelar - Vista parcial - Multimórfico - Coherente - Abstracción + Comportamiento () + Documentación () + Análisis () + Propiedades() Modelado 1. EL MODELADO 28 01_UML.qxp 31/03/2009 3:20 PÆgina 28 este libro con objetos, tendríamos una clase Libro, que tendría como atributos su autor, su editorial, y la cantidad de páginas. Estaría formado por objetos de tipo Capítulo, con atributos que reflejarían su nombre y sus objetivos. Como vemos, el modelo resultante sería idéntico a lo que podemos encontrarnos en el mundo real. En este libro nos enfocaremos en un lenguaje de modelado basado en la orientación a objetos. Vale la pena aclarar que los modelos resultantes pueden luego ser imple- mentados o no sobre un lenguaje orientado a objetos. Los modelos, en este senti- do, son independientes de la implementación. Figura 8. Trabajo con modelos en una de las herramientas basadas en UML. El rol de los modelos en la Ingeniería de Software 29 … RESUMEN El rol de los modelos es fundamental. A través de herramientas gráficas y compactas nos muestran las principales propiedades del sistema, de manera de poder imaginarnos aún en etapas tempranas del desarrollo el futuro comportamiento del sistema. Nos permiten, así, detectar errores y cambiar especificaciones y comportamientos que, de mantenerse en nues- tro sistema, se convertirían en peligrosos amenazas para el éxito de nuestro proyecto. 01_UML.qxp 31/03/2009 3:20 PÆgina 29 30 ✔ PREGUNTAS TEÓRICAS 1 ¿Cuáles son los objetivos de los lenguajes de modelado? 2 ¿Cuáles fueron las principales razones del éxito de los lenguajes de modelado? 3 Enumere las diferencias y similitudes entre un lenguaje de programación y un lenguaje de modelado. 4 ¿Cuál es la motivación principal detrás del desarrollo basado en modelos? 5 Defina en sus propios términos la discipli- na de Ingeniería de Software. 6 Explicite los beneficios de la utilización de modelos en los procesos de software. 7 Analice la relación entre los modelos y la documentación de un proyecto de software. 8 ¿De qué maneras se puede lograr una evo- lución consistente de los modelos? 9 ¿Por qué es importante el concepto de abs- tracción en los modelos? 10¿Por qué es importante la parte gráfica y visual en un lenguaje de modelado? 11Analice el impacto de modelar bajo otros paradigmas aparte de la programación con objetos. ACTIVIDADES EJERCICIOS PRÁCTICOS 1 ¿Qué lenguajes de modelados conoce? Represente un mismo modelo sencillo en cada uno de ellos para puntualizar fortale- zas y debilidades de cada uno. 2 Investigue al menos cinco herramientas basadas en el concepto de desarrollo guia- do por modelos. 3 Muestre ejemplos concretos que ilustren la diferencia entre sistemas y modelos. 4 Muestre en una línea temporal la evolu- ción de los procesos de desarrollo. 5 ¿Cuáles son todos los componentes que integran un sistema de software? 01_UML.qxp 31/03/2009 3:20 PÆgina 30 REDISEÑO BOMBOS LIBROS - ISSU - Base Editable - Sep 10.indd 1 08/09/2010 15:54:03