30/8/2006

Documentación de Modelo de Datos................................................................................ 2 Objetivo ........................................................................................................................ 2 Herramienta a utilizar: Case Studio .............................................................................. 2 Instalación del CaseStudio............................................................................................ 2 Documentación requerida para cada versión ................................................................ 3

Modelo completo de Datos ....................................................................................... 3 Modelo de diferencias con la versión anterior.......................................................... 3

Anexo 1 – Información que puede ser de utilidad............................................................ 5 Bugs de CaseStudio ...................................................................................................... 5 Propagación de campos por relaciones sin duplicarlos ................................................ 5 Pasaje de Descripciones entre CaseStudio y PostgreSQL ............................................ 6 Control de Versiones con CaseStudio .......................................................................... 6 Bloqueo de Edición con CaseStudio........................................................................... 10 División de un Modelo en SubModelos ..................................................................... 12 Manejar el Layout de las Relaciones a mano ............................................................. 13 Ingeniería Reversa y Guardado de Layout.................................................................. 13 Precios......................................................................................................................... 15

Documentación de Modelo de Datos

Objetivo

Unificar la forma en que documentamos los modelos de datos de las soluciones que brinda el SIU, consiste en:

Realizar el modelado de datos con el producto CaseStudio2 o al menos documentar con esta herramienta. Mantener el modelo de todas las versiones y las diferencias existentes entre las versiones en un repositorio único de información sobre los sistemas.

Herramienta a utilizar: Case Studio

Si bien el SIU utilizó en sus principios la herramienta ERWin, e incluso adquirió algunas licencias de la misma, se utilizará el CaseStudio debido a que incluye algunas ventajas interesantes:

Conexión a PostgreSQL. Generación de modelo en HTML, inclusive el Diagrama. Manejo de Versionado. Reporte de diferencias, inclusive en HTML. Posibilidad de Salvar y Recuperar el Layout, el cual incluye los Submodelos. Precio significativamente menor al ERWin.

Instalación del CaseStudio

La versión que se está utilizando es la 2.23 a la que se le deben incorporar los templates existentes en el archivo ComponentesCaseStudioSIU.zip y deberán importarse de la siguiente forma:

Abrir el CaseStudio Abrir un Modelo de Datos o Crear uno nuevo (es necesario para que visualice la opción Model) Entrar a la opción Model Edit Templates Entrar a la opción Templates Import Templates

o Seleccionar uno de los archivos con extensión .te2 que se encuentran

dentro del .zip anteriormente mencionado mediante el icono ( ).

o Importarlo presionando el botón de ejecución ( ). Repetir las dos últimas acciones para todos los archivos .te2 Cerrar la ventana de Importación de Templates. Cerrar la ventana de Edición de Templates.

(De esta forma se incorporaron las castellanizaciones de exportación)

Documentación requerida para cada versión

Modelo completo de Datos

La exportación se debe realizar en forma homogénea para todos los sistemas y consiste en ejecutar la opción File HTML Report... y seleccionar las siguientes opciones:

Sobre el directorio en el que se generó el HTML, en el subdirectorio “Img” hay que copiar el archivo “logo.gif” que está en este .zip. Sobre el mismo directorio hay que copiar los archivos “fBg.png” y “yellow.jpg” que también están en este .zip pero a los que se les debe haber aplicado el color correspondiente al sistema que se está documentando. Cuando el modelo de datos es complejo se recomienda definir áreas(en la nomenclatura de ERWin) o SubModelos(en CaseStudio) para las visualizaciones parciales de los distintos componentes o subdominios. El tilde que se indica al final de la pantalla es justamente para que el HTML muestre los gráficos de los Submodelos en forma separada.

Modelo de diferencias con la versión anterior

Cuando se está editando el modelo de versión actual se debe seleccionar la opción Model Compare Versions. Si está trabajando con versionado en CaseStudio puede seleccionar la versión anterior

mediante el combo , de lo contrario puede abrir el modelo de la versión anterior, que debe haber guardado en su momento, mediante el

icono .

En castellano

Sin flash, con menú superior

Formato estándar

Con ERD para cada Submodelo

Una vez seleccionada la versión anterior a comparar el CaseStudio mostrará las

diferencias y para generar el reporte HTML deberá presionar el botón ( ). Le mostrará una ventana similar a la de exportación completa del modelo HTML y debe seleccionar las mismas opciones con excepción del último tilde que no estará visible.

Anexo 1 – Información que puede ser de utilidad

Bugs de CaseStudio 1) El CaseStudio tiene el problema de no habilitar la opción de guardar el modelo

si no se ha realizado una edición (por ejemplo agregado de entidad) en el archivo que se está editando. Por esa razón, si importa un modelo realizando ingeniería reversa desde la base de datos no verá la forma de salvarlo hasta que cree una entidad (que luego puede borrar inmediatamente).

2) Ingeniería reversa desde Informix a. Tiene problemas con las longitudes de nombre de tablas y campos

mayor a 18, hasta el momento no se encontró la solución. b. En algunas bases da error la importación de “aggregates” y

“permissions”, como normalmente no son usados o útiles debe pedirse no importarlos.

Propagación de campos por relaciones sin duplicarlos Inicialmente si en CS2 se relacionan tablas se puede visualizar el siguiente problema:

En este caso la tabla E2 posee tres copias diferentes del campo clave k1 debido a que dicho campo está como parte de la clave primaria de las otras tres tablas que son padres de E2.

La forma de unificar este campo (que es la realidad en la base de datos) es posicionarse en cada una de las relaciones (presionar botón derecho y en el menú contextual seleccionar “Foreing keys”) como se ve en la figura siguiente:

Aparecerá el siguiente menú y en el mismo hay que asignar en el combo de “New FK” el campo deseado (en este caso es otro k1). El modelo automáticamente borrará el k1 que quedó sin relación. Haciendo esto en todas las relaciones se unifican los campos.

Pasaje de Descripciones entre CaseStudio y PostgreSQL

CaseStudio y PostgreSQL: Un dato importante es que los COMMENT de tablas y atributos son levantados y bajados a CS en el campo “Descripción”. Para lograr que la exportación de CS genere el SQL para cargar las Descripciones en COMMENT hay que tildar en la solapa “Advanced” del formulario de Exportación los dos CheckBox de “Generate Descriptions ...”.

Control de Versiones con CaseStudio Cuando se crea un proyecto con Administración de Versionado te permite visualizar todas las versiones disponibles en una ventana de la siguiente forma. Sobre esta lista se puede seleccionar cualquiera de las versiones para visualizarla e inclusive trabajar sobre ella.

En este caso se abrió la versión 1.5 y se puede trabajar en ella.

Luego, teniendo abierta por ejemplo esa versión (o cualquier otra), se puede ir a la opción control de versionado que permite seleccionar cualquier otra versión para comparar con la que está abierta (pantalla siguiente).

Una vez seleccionada la versión muestra las diferencias entre ambas, pudiendo seleccionar en el árbol de la izquierda el nivel de información que deseas ver en el cuadro de la derecha.

Si se desea un reporte de todos los cambios entre ambas versiones hay dos opciones (generación a html y a rtf), son los botones a la derecha del combo de versión. A continuación se puede ver una porción de la generación a html que permite visualizar todas las variaciones.

Los archivos que utiliza para el modelado con control de versiones son los siguientes:

Un archivo para el proyecto versionado (.dp2) en formato XML que contiene todos los datos de las versiones:

ID consecutivo. GUID único también. ID del padre. Número de versión (completo y dividido en MINOR y MAJOR). Nota escrita en la versión. Fecha y hora de creación y última modificación. Nombre del archivo (.dv2) que contiene esa versión del modelo de datos.

Cada archivo (.dv2) contiene TODA la información de esa versión del modelo en un formato binario.

Por otro lado toda versión de un modelo (archivo .dv2) puede ser File Export a formato XML (.dmx) pero no es el formato nativo de CaseStudio y por lo tanto no se puede trabajar utilizando como repositorio este tipo de archivo.

Bloqueo de Edición con CaseStudio

El Case Studio permite bloquear los Controladores de Versionado (dp2) y lo hace bloqueando el archivo de tal forma que no se puede abrir y copiar con nada (bloqueo de Windows).

La explicación que figura en el help es:

Lock models

If checked, the program will lock up this file at opening. The file is locked up then and nobody can open it or write anything into it. It is recommended that you set this option in the same way on all your computers in the network.

Run only one instance of CASE Studio 2

In case that a new one instance with a parameter "file_name" is called, the initial instance takes control over it.

Y el tilde es el siguiente:

División de un Modelo en SubModelos

Cuando el modelo de datos es muy complejo es conveniente definir áreas o SubModelos para las visualizaciones parciales de los distintos componentes o subdominios. Luego es importante poder visualizar los distintos modelos dentro del mismo HTML, la forma de hacerlo es tildando la opción ‘GEN_ER_DIAGRAM_ALL’ como se ve debajo:

Entonces la solapa de Entidad-relación permite seleccionar y visualizar todos los modelos como se ve a continuación:

Manejar el Layout de las Relaciones a mano

Desgraciadamente no guarda esta información en el layout ¡

Ingeniería Reversa y Guardado de Layout

Para los proyectos en los que la “realidad” está guardada en la base de datos es importante poder documentar el esquema. En esos casos el proceso de “File

Reverse Engineering” tiene el problema de que no puede graficar las tablas y relaciones con una distribución conceptual. Los pasos para realizar esto son los siguientes:

Levantar la base una primera vez mediante “File Reverse Engineering”. Distribuir convenientemente las tablas e inclusive incorporar los SubModelos/Vistas deseadas mediante “Model Submodels”. Exportar el Layout mediante “Model Layout Save…”. Guardar el archivo “?????.la2”.

Luego para las nuevas versiones de la base habría que realizar: Levantar la base mediante “File Reverse Engineering”. Importar el archivo de Layout salvado anteriormente mediante “Model

Layout Load…”.

De esta forma todos los Submodelos y posiciones de las tablas que existían en ellos pasarán a las posiciones definidas en la primer versión. Las tablas nuevas habrá que redistribuirlas. El archivo “?????.la2” tiene formato XML y posee todas las tablas del MainModel más cada uno de los Submodelos con sus tablas. Para cada tabla posee posición y color de la misma. Ejemplo: . . . <SUBMODELS> <SUBMODEL> <NAME>SubModeloPrueba</NAME> <ZOOM>100</ZOOM> <ENTITIES> <ENTITY> <NAME>Continentes</NAME>

<TABLENAME>Continentes</TABLENAME> <LEFT>43</LEFT> <TOP>10</TOP> <COLOR>16777215</COLOR> </ENTITY> . . .

Finalmente también se puede utilizar el CaseStudio para comparar dos versiones de la base y generar el HTML de diferencias sin la necesidad de cargar las modificaciones en el mismo y simplemente realizando la Ingeniería Reversa.

Precios