Prediseño. Laboratorio de software de gestión

Transcripción

1 Prediseño Laboratorio de software de gestión Cristina Manresa Panorámica Definición de los estándares de diseño Diseño físico de la base de datos Diseño físico de las aplicaciones

2 Entregas Estándares de diseño Estándares de diseño GUI Estándares de programación Convenciones de nombrado de diseño Diseño conceptual de las aplicaciones Guiones gráficos de las aplicaciones Estructura de módulos de las aplicaciones Referencia de los módulos en los requisitos Descripciones funcionales de cada módulo Plan de diseño Plan de diseño de la base de datos Plan de diseño de aplicaciones Estándares de diseño

3 Estándares de diseño de GUI Capacidades de Designer son limitadas Satisfecho con las generadas automáticamente? Completar el desarrollo de los módulos de pantalla? Ideal: restringir al primer tipo en la medida de lo posible GUI. Compromiso Generar el módulo de pantalla y modificarlo y realizar un seguimiento de las modificaciones. Romper vínculo con CASE No posibilidad de Ing. Inversa completa

4 GUI. Consecuencias generación automática Más módulos y pantallas de lo que se desearía Pantallas que no son tan atractivas y bien diseñadas como deberían serlo Menos información en cada pantalla Pantallas con apariencia menos profesional que si las hubiera construido un experto en GUI partiendo desde cero. GUI. Aspectos a tener en cuenta Determinar funciones de la barra de herramientas Resolución y color de la pantalla Aprovechamiento de la pantalla Títulos Logos Etiqueta dentro de los marcos Botones Listas emergentes Etc. Estética

5 Estándares de programación Uso de minúsculas % en declaraciones que correspondan a objetos de la bbdd Dos espacios en vez de tabuladores Cursores explícitos. Reducen accesos Funciones y procedimientos en librerías. Almacén en bbdd Lista estándar de abreviaturas para nombres de variables Excepciones Convenciones de nombrado de diseño Nombres excesivamente largos de tablas y columnas dificultan la legibilidad del código Lista de abreviaturas de 5 caracteres para todas las palabras de la bbdd Se crea una procedimiento que pase los nombres Añadir abreviatura de tabla a columna, alarga innecesariamente Nombres descriptivos Idem con módulos

6 Diseño conceptual de las aplicaciones Selección de las herramientas de diseño Qué herramienta se utilizará para construir las aplicaciones: Developer, Visual Basic, C++, HTML Developer. Integración completa con Oracle. Permite portabilidad entre diferentes plataformas con pocas modificaciones

7 Creación de guión gráfico para las aplicaciones Un guión gráfico es un prototipo sin funcionamiento que permite a los usuarios y desarrolladores valorar la calidad del diseño de una aplicación. Pasos: bbdd generada por defecto, módulos basados en definiciones de las funciones de análisis, refinamiento. Estructura de módulos de las aplicaciones Determinar que módulos del guión gráfico se utilizarán en la aplicación final Pueden combinarse varios módulos en uno sólo o descomponer o construir nuevos Estudiar los módulos: ver si se pueden utilizar directamente del repositorio, descartar módulos del repositorio

8 Referencia de los módulos en los requisitos Las referencias existentes en los requisitos hacia la jerarquía de funciones deben cambiarse hacia los nuevos módulos Descripciones funcionales Cada módulo tiene que tener unas observaciones que describan en detalle cómo funcionará ese módulo. Creará el libro de diseño: pantallazos, requisitos de sistema, pseudocódigo para los disparadores Guiará al desarrollador

9 Plan de diseño Plan diseño para diseño bbdd Debe incluir previsiones de Seguridad (acceso roles, inicio sesión ) Mantenimiento de históricos: cuales se mantendrán errores de datos, cambios reales a lo largo del tiempo Desnormalización: por rendimiento Instancias de la bbdd: desarrolladores/pruebas/producción Planificación de capacidad

10 Plan diseño para diseño aplicaciones Identificar el uso de las columnas por cada módulo y la especificación plena de los módulos Finaliza en construcción Cuando concluye? Un desarrollador experimentado debe juzgar los estándares GUI Control de los estándares: ni muy simples ni tampoco demasiado complejos Guiones gráficos están completos cuando los usuarios dan el visto bueno Equipo de diseño debe juzgar si las aplicaciones están bien modularizadas Revisión de requisitos y descripciones funcionales: fácil de hacer

11 Fase de prediseño en Designer Guión gráfico Actividad o entrega Estándares de diseño GUI Insertar uso de atributos en funciones Integración de los cambios en las tablas a partir del guión gráfico Integración de los cambios en los módulos a partir del guión gráfico Reestructuración de la red de módulos Referencia de los módulos en los requisitos Herramienta en Designer Navegador de preferencias y plantillas de módulo Matriz función/atributo Experto en diseño de bbdd, de aplicaciones, generadores Util. Ing. Inversa de la bbdd Util. Ing. Inversa para Forms y Reports Diagramador de la estructura de módulos RON Navegador de preferencias Preferencias específicas para cada tipo de generador que se esté utilizando Hay más de 450, cada una con varios niveles de opciones Está en el editor de diseño

12 Experto en diseño de bbdd DDW: Database Design Wizard. Permite crear tablas para la fase de diseño a partir de entidades de la fase de análisis. Se generará un primer repositorio de datos para poder utilizarlo como base para los módulos del guión gráfico, En diseño, se acabará de refinar el primer esbozo de tablas y columnas Experto en diseño de bbdd Elemento datos Análisis Entidad Atributo Id. único primario Id. Único no primario Relación 1 a N Relación N a N Relaciones arco y subtipo/supertipo Columna Elemento datos diseño Tabla (Plural de entidad nombre tabla, espacios subrayados) Restricción de clave primaria Restricción única Restricción clave externa y columna de clave externa Tabla de intersección con restricciones y columnas de clave externa Tablas individuales o tablas múltiples con columnas especiales de unión

13 Experto en diseño de bbdd Resolución de supertipos/subtipos Implementación del supertipo (tabla única) Implementación de subtipo explícito (tablas separadas) Implementación implícita del subtipo Implementación de arco Implementación del supertipo (tabla única) El supertipo y todos sus subtipos son combinados en una sola definición de tabla: El nombre de la definición se deriva del supertipo Los atributos del supertipo se convierten en columnas Los atributos de todos los subtipos son incluidos como columnas opcionales Se necesita una columna adicional que identifique el subtipo de cada fila Posteriormente se definirá manualmente código que fuerce las columnas obligatorias de los subtipos

14 Implementación del supertipo (tabla única) Método de implementación en DDW Incluir sólo el supertipo en el conjunto ejecutable. Los subtipos deben tener el Map Type como Included Implementación de subtipo explícito (tablas separadas) Cada subtipo es implementado en una tablas con las siguiente características: El nombre de cada definición de tabla es derivado a partir del subtipo correspondiente Todas las definiciones de tablas heredan los atributos del supertipo Los atributos mantienen la opcionalidad original Las relaciones son asociados a los subtipos del modo siuguiente: Las relaciones de los subtipos de convierten en claves ajenas en la tabla correspondiente al subtipo Las relaciones del supertipo son heredados en todas las tablas subtipo

15 Implementación de subtipo explícito (tablas separadas) Método de implementación en DDW Especificar los subtipos pero no el supertipo en el conjunto ejecutable Implementación implícita del subtipo (no recomendado) En esta opción el supertipo y cada subtipo con implementados en sus tablas propias con las siguientes características: La tabla derivada del supertipo y contiene sólo columnas del supertipo y sus filas serán aquellas que no correspondan con ningún subtipo Los atributos del supertipo se convierten en columnas de las tablas derivadas de los subtipo Todas las columnas mantienen su opcionalidad inicial Ventaja: permite incluir instancias del supertipo que no estén clasificadas en ningún subtipo

16 Implementación implícita del subtipo (no recomendado) Método de implementación en DDW Especificar el supertipo y los subtipos en el conjunto ejecutable Implementación de arco El supertipo y cada subtipo se implementan en sus tablas propias, sin columnas comunes y con unas relaciones en arco que enlazan el supertipo con cada uno de los subtipos con las siguientes características: La tabla derivada del supertipo contiene solo columnas del supertipo La tablas derivadas de los subtipos contienen solo columnas del subtipo en cuestión Las columnas mantienen su opcionalidad original La claves ajenas en el supertipo soportan la estructura de arco

17 Implementación de arco Método de implementación en DDW Se ejecuta dos veces el DDW Primera vez: especificar el supertipo y los subtipos para el conjunto ejecutable, pero no las columnas o claves Segunda vez: activar la casilla Arc de cada subtipo y especificar las creaciones de tablas, columnas y claves Selección del tipo de transformación Los factores a considerar para la selección de una transformación u otra son: Factor Atributos comunes Relaciones comunes Modo de consulta Modo de consulta Instancias Acceso Consideraciones Mayoría atributos del supertipo Mayoría relaciones del supertipo Info. de los subtipos aparece a menudo en el mismo informe Info. de los subtipos aparece en distintos informes Existen instancias del supertipo que no se pueden clasificar en ningún subtipo Cuando el supertipo es el más accedido, pero los subtipo soportan el volumen mayor de información Implement ación Supertipo Supertipo Supertipo Explicito Implícito Arco

18 Relaciones tipo arco La relaciones tipo arco se resuelven de forma explícita, es decir cada entidad es implementada con una tabla, y se implementan las relaciones con claves ajenas, una por cada relación de arco Es necesario implementar el código que sólo permita rellenar una de las claves ajenas (disparadores de BD o a nivel de cliente) Diseño Diseño de la base de datos

19 Diseño de la base de datos Especificar las tablas Determinar las claves primarias Implementar las dependencias Asignar atributos a las tablas Implementar las reglas de negocio complejas (triggers) Diseño de la base de datos Crear columnas redundantes (columnas calculadas, campos de clave) Crear tablas y vistas de acumulación y resumen: tablas redundantes, o vistas vistas ocupa menos, pero las consultas son más lentas que las tablas Crear tablas de descripciones de códigos Listas pequeñas de valores: restricciones Listas grandes: tablas de descriptores de códigos Realizar un seguimiento histórico

20 Fase de diseño de datos en Designer Actividad o entrega Diseño refinado de las tablas Desnormalización Tablas resumen, diario y de códigos Integración de las tablas existentes no incorporadas durante la fase de análisis Sincronización de columnas pertenecientes a dominios Código para la desnormalización Documentar diseño de la bbdd Herramientas de Designer Diagramador de modelo de serv y RON Diagramador de modelo de serv y RON Diagramador de modelo de serv y RON Util. Ing. Inversa de la bbdd Util. de actualización de las columnas de un dominio Navegador lógico de módulos Informes del repositorio Editor de diseño

21 Editor de diseño para datos Editor lógico Componentes diseño Navegador diseño (server model, DB Admin y Distribution) Server Model Diagram Paleta propiedades Paleta de preferencias Navegador de bbdd Tareas Crear, editar y borar elementos de diseño de la bbdd Crear, editar y borrar elementos lógicos Propiedades de los elementos Especificar lógica del lado del servidor Especificar las preferencias de generación Visualizar bbdd online Diagrama de modelo de servidor Modela el diseño físico de la bbdd La fase de diseño se inicia con un borrador de las definiciones de las tablas del repositorio Permite realizar diagramas de correspondencias (tablas, vistas e instantáneas) con sus relaciones Parecido al diagramador E/R de análisis

22 Diagrama de modelo de servidor Diagrama de modelo de servidor Basar el modelo en lo creado en el repositorio Edit Include Borrar elementos del diagrama Borrar también del repostiorio: bt dcho Delete from repository Borrar sólo del diagrama: Edit Cut

23 Diagrama de modelo de servidor Tablas Columnas Primary keys Unique keys Check constraints (((c1 IS NULL) AND (C2 IS NOT NULL)) OR ((c2 IS NULL) AND (C1 IS NOT NULL))) Foreign keys Secuencias Ref_codes Diagrama de modelo de servidor Aclaraciones sobre la anotación: XFACTURA # XIDFACTURA o XFECHAFACT tiene es de XDETALLE FACT o XCANTIDAD La barrita sobre la relación aquí significa que la regla de borrado es restrictiva XFACTURAS (xdesigner) XDETFACT_XFACT_FK XDETALLESFACTS (xdesigner)