Introducción a Herramientas CASE y System Architect

Transcripción

1 Introducción a Herramientas CASE y System Architect 1 Herramientas CASE CASE es un acrónimo para Computer-Aided Software Engineering, aunque existen algunas variaciones para lo que actualmente se entiende por CASE, tal como se ilustra a continuación: C A S E Computer Aided Assisted Automated Software Systems Engineering Variaciones del acrónimo CASE Esencialmente, un CASE es una herramienta que ayuda al ingeniero de software a desarrollar y mantener software. A continuación se presentan algunas definiciones dadas para el término CASE. En Terminology for Software Engineering and Computer-aided Software Engineering by B.Terry & D.Logee, Software Engineering Notes, Abril 1990, CASE es definido como: Herramientas individuales para ayudar al desarrollador de software o administrador de proyecto durante una o más fases del desarrollo de software (o mantenimiento). En The CASE Experience, Carma McClure, BYTE Abril 1989 p.235 se ofrece la siguiente definición: Una combinación de herramientas de software y metodologías de desarrollo La pieza fundamental, y más importante avance tecnológico asociado a una herramienta CASE, es su repositorio integrado. En el repositorio se almacena toda la información de uno o varios sistemas de información, por ejemplo, datos acerca de: El dominio (problema) de los sistemas desarrollados o en desarrollo Modelos de solución e implementación Información de la metodología que está siendo usada Historia de los proyectos, recursos, presupuestos, etc. Contexto organizacional: organigramas, planes estratégicos, factores críticos de éxito, etc. 1

2 Cada ítem en el repositorio es descrito en detalle. Atributos típicos podrían ser: identificación, definición (significado), tipo, alias, ítems componentes, ítems padres, reglas de uso, quién y cuándo lo creó, quién y cuándo lo actualizó por última vez, quiénes pueden actualizarlo y/o consultarlo, cuál es su estado (por ejemplo: incompleto, completo etc.), número de versión, dónde está almacenado físicamente. 1.1 Ingeniería de Software y herramientas CASE La evolución de las herramientas CASE está ligada a la evolución de la Ingeniería de Software como disciplina. El término Ingeniería de Software fue usado por primera vez en una conferencia OTAN en En dicha conferencia se reveló la existencia de la llamada Crisis del Software, causada por los problemas inherentes al desarrollo de software. El ciclo de vida del software es entendido como la secuencia de fases por las cuales atraviesa un proyecto de desarrollo de software desde su concepción hasta el fin del uso del producto software obtenido, pasando por su construcción y mantenimiento. En el Diccionario de la Real Academia de la Lengua Española una metodología se define como: Conjunto de métodos que se siguen en una investigación científica o en una exposición doctrinal. y un método como: Procedimiento que se sigue en las ciencias para hallar la verdad y enseñarla. Una metodología en Decline & Fall of the American Programmer, Edward Yourdon, Yourdon Press 1993 es definida como: Un plan de batalla paso a paso, o libro de cocina, para ejecutar algún resultado deseado. Una metodología de software usualmente identifica las principales actividades- por ejemplo, análisis, diseño, codificación y pruebas- a ser realizadas e indica qué personas (usuarios, administradores, técnicos) deben estar involucrados en cada actividad y qué papel desempeñan en ellas. Las metodologías a menudo describen criterios de entrada (por ejemplo condiciones para comenzar una fase), criterios de salida y puntos de revisión A veces se utiliza ciclo de vida como sinónimo de metodología pues cada metodología ofrece su particular visión de las fases por las cuales debe pasar un proyecto de desarrollo de software. Un método es entendido como un enfoque técnico para ser utilizado en toda o parte de una metodología. Tanto las metodologías como los métodos están basados en diversas técnicas principalmente gráficas y/o textuales. 2

3 Las siguientes son algunas actividades típicamente incluidas en el ciclo de vida del software: planificación del proyecto, gestión del proyecto, análisis, diseño, codificación, pruebas, documentación, mantenimiento, validación y verificación. Los esfuerzos iniciales por resolver la Crisis del Software se orientaron en el ámbito de la codificación, apareciendo las primeras técnicas de programación. A fines de los 60 s y comienzos de los 70 s surgieron gran cantidad de técnicas para programar y documentar programas. Un ejemplo representativo lo constituyen la Programación Estructurada y los Diagramas de Flujo. Sin embargo, las mejoras introducidas al proceso de desarrollo no eran suficientes. A fines de los 70 s y comienzos de los 80 s la atención se centró en resolver problemas de especificación, diseño, métricas y gestión dentro del desarrollo de software. Es decir, el interés fue dirigido a otras actividades del desarrollo dentro del ciclo de vida del software. Actualmente la Ingeniería de Software como disciplina se ve plasmada en una gran variedad de enfoques y metodologías para el desarrollo de software. Algunos enfoques para el desarrollo de software son: Desarrollo en Cascada, Desarrollo con Prototipación, Desarrollo Incremental, Desarrollo en Espiral. Las metodologías se basan en algún enfoque o combinación de ellos. Actualmente existe un gran número de metodologías tanto comerciales como en el ámbito académico y de investigación. Ellas pueden ser agrupadas en dos grandes corrientes: Metodologías Estructuradas y Metodologías Orientado a Objeto. Metodologías Estructuradas Aparecieron a fines de los 60 s con la Programación Estructurada, posteriormente a mediados de los 70 s extendidas con el Diseño Estructurado y a fines de los 70 s con el Análisis Estructurado. Versiones más recientes incorporan Diagramas Entidad-Relación y Diagramas de Transición de Estados. Ejemplos de metodologías estructuradas impulsadas por organismos gubernamentales lo constituyen: MERISE (Francia), METRICA (España), SSADM (Reino Unido). Otras metodologías estructuradas en el ámbito académico y comercial son: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco y Information Engineering. Esta última propuesta por James Martin pone un énfasis adicional en el modelado de datos y la incorporación de los desarrollos informáticos dentro del contexto organizacional (planificación, objetivos, etc.). Metodologías Orientadas a Objeto Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60 s SIMULA, a fines de los 70 s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java. Sólo a fines de los 80 s comenzaron a consolidarse algunas metodologías Orientadas a Objetos. 3

4 Algunas de las más representativas en el ámbito comercial son: OMT de Rumbaugh, OOAD de Grady Booch, OOSE de I.Jacobson, la propuesta por Peter Coad & Edward Yourdon, la propuesta por S. Shaler & S.J. Mellor y la propuesta por J.Martin y J.J.Odell. En los últimos años se ha realizado un esfuerzo de estandarización notacional materializado en UML (Unified Modeling Language), el cual aglutina características de algunas de las propuestas OO más conocidas. En 1997 UML fue aprobado como notación estándar por el OMG. 1.2 Evolución de las herramientas CASE Las primeras herramientas para apoyar el proceso de desarrollo de software fueron los editores y procesadores de texto, usados para escribir programas y su documentación. Así, también algunos programas de dibujo comenzaron a incorporar las notaciones gráficas de técnicas para diseño de programas. La consolidación de metodologías de desarrollo integrando diferentes técnicas impulsó la aparición de paquetes de propósito más amplio. Surgió la necesidad de un diccionario de datos del sistema que almacene las definiciones usadas en las diferentes fases del desarrollo (este diccionario es lo que comúnmente se denomina repositorio). Esto contribuyó a implementar funciones de integración y verificación de consistencia entre técnicas (asociadas a distintas actividades en el desarrollo). La automatización de tareas también ha sido un aspecto de interés. En programación automática esto se ha traducido en: generadores de pantallas e informes, generadores de esquemas físicos de bases de datos y generadores de código para prototipos o partes de programas. Actualmente, en Ingeniería de Software todos los desafíos y los correspondientes enfoques de solución están normalmente concebidos y llevados a la práctica dentro del contexto de un CASE. 1.3 Expectativas del uso de un CASE El propósito de una herramienta CASE es dar soporte automatizado para la aplicación de todas o algunas técnicas usadas por una o varias metodologías. Cualquier mejora orientada a resolver problemas asociados a la Crisis del Software se enmarca dentro de los siguientes niveles de solución, desde el más general al más particular: 1. Enfrentar el proceso de desarrollo de software como un proyecto de Ingeniería de Software. 2. Aplicar una o varios metodos de forma integrada cubriendo todas las actividades del ciclo de vida del software 3. Usar una herramienta CASE para apoyar la aplicación de los métodos utilizados. 4

5 Si consideramos que cada nivel debe implicar al anterior, se pone de manifiesto que la sola utilización de una herramienta CASE no garantiza una mejora en el proceso de desarrollo de software. Por otra parte, las metodologías incluyen gran cantidad de técnicas, y el esfuerzo de documentación (y actualización de dicha documentación) es por lo general considerable. Por lo tanto, es difícil aplicar una metodología sin la ayuda de una herramienta CASE. Así, los beneficios de utilización de un CASE se entremezclan con los beneficios de aplicar una metodología con éxito. El valor agregado indudable de utilizar un CASE es el aumento en la productividad en las actividades soportadas por la herramienta. Mientras los costos del hardware han ido en continuo descenso, sucede todo lo contrario con los costos del software. Las exigencias en complejidad y envergadura han sobrepasado a las mejoras en cuanto a métodos de desarrollo. El uso de metodologías de desarrollo junto a herramientas CASE no es una panacea, pero sin lugar a dudas ofrece la mejor alternativa actual para enfrentar proyectos de desarrollo de software de complejidad y/o envergadura. El énfasis en planificación, análisis y diseño promovido por una herramienta CASE tiene un fuerte impacto y recompensa en la mejora de la calidad del producto obtenido y en el aumento de productividad (disminución de tiempos, costes y esfuerzos) en las actividades de desarrollo y mantenimiento. El beneficio adicional obtenido por la utilización de un CASE actual (si se compara con la utilización de una metodología sin el uso de un CASE) se representa en los siguientes aspectos: Facilita la verificación y mantenimiento de la consistencia de la información del proyecto. Facilita el establecimiento de estándares en el procesos de desarrollo y documentación. Facilita el mantenimiento del sistema y las actualizaciones de su documentación. Facilita la aplicación de las técnicas de una metodología. Disponibilidad de funciones automatizadas tales como: obtención de prototipos, generación de código, generación de pantallas e informes, generación de diseños físicos de bases de datos, verificadores automáticos de consistencia. Facilita la aplicación de técnicas de reutilización y reingeniería. Facilita la planificación y gestión del proyecto informático. 5

6 2 Introducción a System Architect System Architect (SA) es una herramienta CASE. SA provee soporte para técnicas variadas para el desarrollo de sistemas de información. Dichas técnicas están asociadas a las principales metodologías actualmente en uso. SA permite generar automáticamente plantillas de código en varios lenguajes de programación y también esquemas de implementación para gestores de bases de datos relacionales. Toda la información introducida mediante la herramienta es almacenada en un directorio, el cual en SA se denomina encyclopedia (repositorio en terminología CASE). Una enciclopedia puede contener información de uno o más sistemas (proyectos) en desarrollo. La herramienta provee mecanismos para importar y exportar información entre enciclopedias. En un entorno de desarrollo real podría existir una o más enciclopedias para los sistemas ya construidos y una para cada sistema (subsistema) en construcción, importando/exportando definiciones existentes y nuevas según corresponda. Físicamente, una enciclopedia en SA contiene: Una base de datos relacional compuesta de dos tablas y algunos índices Un fichero por cada diagrama Un metafile (WMF) por cada diagrama Cuatro ficheros que determinan la configuración de la enciclopedia Un fichero de bloqueos si se está ejecutando la versión de SA en red Uno o más stylesheets 2.1 Abriendo una enciclopedia Si se desea abrir una enciclopedia existente seleccionar File Encyclopedia Open, en el cuadro de diálogo introducir el path de la enciclopedia. 2.2 Aspectos Generales La primera entrada que hay que proporcionar es el Audit Id, un identificador del usuario para propósitos de auditoría (control de cambios realizados sobre la enciclopedia). La pantalla al inicio de sesión se presenta como lo muestra la Figura en la cual se indican las principales secciones. El Browser permite acceder a la enciclopedia, la información registrada está agrupada en diagramas y definiciones. El Toolbox ofrece el conjunto de símbolos que pueden ser dibujados en un diagrama y varía dependiendo del tipo de diagrama que este activo. El Toolbar contiene comandos del Menu Bar que son frecuentemente utilizados. 6

7 Menubar Toolbar Toolbox Browser Figura 2.2.1: Secciones de una pantalla en SA Área de Dibujo Básicamente el trabajo de análisis y diseño con la herramienta consiste en editar diagramas y definiciones. Cada elemento gráfico de un diagrama tiene una definición y a su vez las definiciones pueden utilizar otras definiciones. Algunos diagramas pueden tener una relación padre-hijo, esto sucede cuando un símbolo del diagrama padre se detalla en un nuevo diagrama (hijo). SA provee un conjunto de informes que permiten verificar el trabajo realizado de acuerdo a las técnicas empleadas. En módulos adicionales se proporcionan funciones tales como: generación de pantallas, esquemas de bases de datos y generación de código. 2.3 Uso del Help La forma más directa de acceder al help de SA es presionando F1. SA tiene un help bastante completo. En adelante se utilizará la notación F1 Búsqueda cadena para indicar una entrada del help que describe en mayor detalle algún tema de interés. 2.4 Creando una enciclopedia Para crear una enciclopedia seleccionar File Encyclopedia Open, en el cuadro de diálogo introducir el nombre de la enciclopedia (directorio) que se va a crear. Crear una enciclopedia implica crear el directorio (si éste no existe) y generar en él todos los ficheros iniciales para la enciclopedia. 7

8 En la Figura se seleccionan las técnicas que se utilizarán. Cada técnica tiene asociado un conjunto de diagramas. Además se establece el sistema gestor de bases de datos y el lenguaje de programación. Estas elecciones determinan ciertas propiedades relacionadas con la generación automática del diseño físico de la base de datos y de plantillas de código en el lenguaje de programación. Con el botón Advanced se accede a un cuadro de diálogo donde es posible modificar la lista detallada de diagramas y propiedades disponibles. Figura 2.4.1: Selección de técnicas utilizadas en la enciclopedia 2.5 Estableciendo preferencias para la sesión Mediante el diálogo presentado después de acceder por Tools Preferences pueden definirse una serie de características opcionales que tienen efecto sobre los diagramas. La descripción de cada característica está en F1 Búsqueda Preferences Command. Es conveniente activar la opcióny Delete Definition que permite la actualización inmediata del diccionario, conforme se borran elementos o datos. 8

9 3 Creando un Diagrama Mediante la opción del Menu Bar File New Diagram o usando el correspondiente botón en el Toolbar, se accede a la pantalla de diálogo Figura 3.1. En ella introducir el nombre del diagrama a construir y seleccionar su tipo. Posteriormente se activará una ventana de dibujo para el diagrama y aparecerá la Toolbox asociada al tipo de diagrama. Figura 3.1 Básicamente, un diagrama está compuesto de símbolos (los disponibles en la Toolbox). La forma de conectar símbolos puede ser modificada accediendo a Format Symbol Style Line. Cada símbolo puede ser descrito por una definición. Estas definiciones constituyen parte de la enciclopedia de la herramienta y pueden ser compartidas por diferentes diagramas. SA mantiene independencia entre las propiedades de los símbolos dibujados y las definiciones asociadas. Es decir, al dibujar un símbolo no es obligatorio proporcionarle propiedades (nombre y descripción por ejemplo) ni una definición (una definición de clase, si el símbolo representa a una clase). De la misma forma, el símbolo podría tener propiedades y no tener una definición asociada. Figura 3.2 Para efectuar alguna operación sobre uno o más símbolos, estos se seleccionan pinchando una vez (si son más de uno se utiliza la tecla Shift). Posteriormente se debe escoger la operación a realizar en el Menu Bar o presionando el botón derecho del ratón; en este caso aparece una lista de opciones similar a la que se muestra en la Figura

10 Al mismo tiempo pueden estar varios diagramas abiertos. Para cerrar un diagrama lo más directo es presionar el botón derecho del ratón y seleccionar la opción Close. Para eliminar el diagrama que está activo utilizar File Delete Diagram. Si el diagrama que se desea eliminar no está activo seleccionarlo en el Browser y con el botón derecho del ratón elegir Delete. 4 Modificando un Diagrama o Definición Para modificar un diagrama o una definición acceder al Browser mediante File Open Diagram o usando el botón correspondiente en el Toolbar. En el Browser seleccionar diagramas o definiciones según se desee. En la parte inferior del Browser aparecerá el diagrama reducido (ejemplo en Figura 4.1) o una descripción de la definición seleccionada. A continuación hacer doble click sobre la entrada que se desea modificar. 5 Reusando definiciones Figura 4.1 Una de las principales contribuciones de un repositorio integrado es facilitar la verificación de consistencia y reutilización de definiciones. SA permite seleccionar una definición asociada a un símbolo desde una lista de definiciones existentes y arrastrarla sobre el diagrama activo, con lo cual automáticamente se dibuja el símbolo (manteniendo su definición). 10

11 Figura 5.1 Una oportunidad de reutilizar definiciones se presenta cuando se está definiendo algun elemento y debe introducirse un elemento subordinado ya definido, en este caso, existirá un botón llamado Choices... el cual presenta un lista de definiciones del mismo tipo ya registradas en el repositorio. Se puede seleccionar una de ellas y arrastrarla sobre el cuadro de texto activo. En la Figura 5.1 se muestra un ejemplo de lo anterior. En la definición de los atributos de una clase, mediante el botón Choices... se presenta una lista de los atributos ya definidos. 6 Organizando y balanceando diagramas Los diagramas describen algún aspecto en particular del sistema. Cuando el sistema tiene cierta envergadura representar dicho aspecto en un solo diagrama puede resultar difícil de manipular y comprender. En este caso es conveniente descomponer la descripción del aspecto que se está modelando en varios diagramas del mismo tipo, creando una jerarquía de diagramas mediante relaciones padre-hijo entre ellos. La mayoría de las técnicas proveen pautas para realizar dicha descomposición y establecen criterios de corrección entre diagramas padre-hijo. El proceso de verificación y corrección de dichos criterios se denomina comúnmente balanceo de diagramas. Por ejemplo, en Análisis Estructurado el procedimiento de crear diagramas hijos se denomina explosión de proceso, para lo cual se realiza balanceo de DFDs, verificando por ejemplo que las entradas y salidas del proceso padre (en el diagrama padre) se correspondan con las entradas y salidas en el diagrama hijo. En un diagrama SA se permite asociar a cualquier símbolo un nuevo diagrama de cualquier tipo (de acuerdo a una técnica particular la asociación padre-hijo puede no tener sentido). Para asociar un diagrama hijo hacer clik sobre el símbolo y con el botón derecho del ratón seleccionar Child Create o Child Attach dependiendo si el diagrama hijo se va a crear o se seleccionará entre los ya existentes. Las relaciones padre-hijo entre diagramas pueden observarse fácilmente en el Browser, donde se muestran en 11

12 forma de árbol. La Figura 6.1 presenta un caso de diagramas relacionados y cómo ellos son presentados en el Browser. Figura 6.1 En el diagrama padre, un símbolo que tiene asociado un diagrama hijo tiene un indicador de expansión en la parte superior. Esta situación se ilustra en la Figura 6.2, donde el símbolo P tiene en su parte superior el indicador de expansión por tener asociado un diagrama hijo. Cliente Número Tarjeta PIN P Cajero Automático Listado Movimientos Datos Saldo Figura 6.2 Cuando un símbolo tiene un diagrama hijo asociado, las opciones Child Create o Child Attach son reemplazadas por Child Detach y Child Open las cuales permiten deshacer el vínculo o acceder al diagrama hijo. En el diagrama hijo, al presionar el botón derecho sobre un área sin símbolos, se ofrecen las opciones Parent y Top, con las cuales se accede al diagrama padre o al diagrama en el tope de la jerarquía de diagramas. 12

13 7 Solución a problemas con la herramienta SA. A continuación detallamos una serie de recomendaciones típicas que no forman parte de la documentación de la herramienta pero que por nuestra experiencia hemos podido constatar de imprescindibles. 7.1 Precaución al hacer backup de la enciplopedia. Cuando se desee hacer una copia del directorio que contiene la enciclopedia (típicamente a diskette) es imprescindible haber cerrado antes el CASE SA, en otro caso se obtendrá un error que indica que diversos diagramas están en uso (en cuyo caso se soluciona por alguno de los dos siguientes apartados). 7.2 Qué hacer ante el aviso Diagram xx is in use by usuario. Este error puede surgir cuando SA no tuvo constancia de haberse cerrado el diagrama xx por el usuario con audit usuario. Puede ocurrir cuando hay un fallo, por ejemplo, del sistema operativo teniendo que rearrancar SA. En este caso, el procedimiento pasa por desbloquear el(los) diagrama(s) bloqueado(s). Los pasos son los siguientes: 1. Tools Access Control. 2. Escoger la opción unlock locked item de la lista desplegable superior. 3. Hacer click en New List. 4. Aportar un nombre de fichero inventado, p.e., kk.lst. 5. Seleccionar en la nueva ventana un diagrama bloqueado con doble click. 6. En la ventana que aparece pulsar OK. 7. Aparecerá una ventana con el mensaje:... now unlocked Si el mensaje obtenido indica que se requiere ser supervisor, entonces verificar que el audit con el que se conectó a SA es el mismo que el que creó el diagrama bloqueado. 9. Repetir el procedimiento por cada diagrama bloqueado. 7.3 Qué hacer ante el aviso Enciclopedia Busy. Este error aparece cuando SA cree que la enciclopedia está abierta por otro usuario. En este caso, si se está seguro que SA no está abierto en otra ventana, el error se soluciona borrando el fichero network.lck que se encuentra en el mismo directorio de la enciclopedia. Rearrancar despúes SA. Es posible que aparezcan errores como el descrito en el punto Confección de documentos personalizados Para componer memorias en cualquier editor de textos es posible incorporar los diagramas dibujados con SA a partir de los ficheros con extensión *.wmf. Estos ficheros incorporan imágenes con el mismo formato con el que se muestra en las distintas ventanas del CASE SA. También puede seleccionar los diagramas y utilizar los comandos Copiar Pegar del menú de Edición. 13