dis diseño - cd universidad de oviedodi002.edv.uniovi.es/~fanjul/isofg/curso2006-2007/...•...

DIS Diseño

Introducción.............................................................................2

Diseño Arquitectónico .............................................................4

Diseño de Detalle. ...................................................................11

Diseño de Datos .....................................................................19

El proceso de diseño (DSI) en Métrica ....................................22

La construcción (CSI) en Métrica ............................................23

La implantación y aceptación (IAS) en Métrica........................24

Diseño: DIS-2

ISOFT, (C) Laboratorio de Comunicaciones e Ingeniería del Software (2006)

Introducción

Objetivos del diseño Los objetivos fundamentales del proceso de diseño son la definición de:

• la arquitectura del sistema: especificar la división del sistema en partes físicas (nodos) y lógicas (subsistemas de diseño).

• el detalle del diseño de los subsistemas.

• las estructuras de datos necesarias (entendiendo de forma amplia el concepto “estructura de datos”).

La especificación de dichos objetivos debe hacerse de forma que guíe la codificación posterior del sistema.

Diseño: DIS-3


Relación análisis-diseño El diseño debe tomar como base el trabajo realizado en la fase de análisis:

1

Analisis

2

Diseño

3

Construccion

Analisisfuncional

Analisis dedatos

Analisisdinamico

RequisitosDiseño dearquitectura

Diseño dedetalle

Diseño dedatos

Nota: Además, en METRICA, el analisiscontempla la realizacion de prototipos

Diseño: DIS-4


Diseño Arquitectónico

Objetivos Definir en detalle el entorno tecnológico de nuestro sistema desde los puntos de vista del hardware y sofware.

Para ello seguimos tres pasos:

1. Identificar nodos y las comunicaciones entre ellos.

2. Dividir el sistema analizado en subsistemas de diseño.

3. Asignar los subsistemas de diseño a los nodos.

Subsistemas de diseño

Sistema

Nodos

Diseño: DIS-5


Paso 1. Identificación de nodos. Nodo: Hardware que ejecuta una serie de subsistemas de diseño de un sistema.

Respecto a los nodos se debe documentar detalladamente:

• las características técnicas de cada nodo, tanto en lo que se refiere al hardware como al software. Algunas ideas:

Hardware Software

procesador

memoria

disco

periféricos de todo tipo

tarjetas especiales

sistema operativo

base de datos

drivers

• las características de las comunicaciones entre los nodos, incluyendo el diseño de la red física y lógica (protocolos de comunicación que se usarán).

• la situación física de cada nodo (usando planos si fuera necesario).

Diseño: DIS-6


Paso 2. División del Sistema en Subsistemas de diseño. El sistema analizado debe ser dividido en subsistemas de diseño.

Referencias a tener en cuenta al dividir en subsistemas de diseño:

• Los subsistemas de análisis.

• Los datos.

• Requisitos no funcionales.

• Criterios de “construcción” (por ejemplo, organización en capas).

• Criterios de “implantación” (por ejemplo en cuanto a la localización del software).

La división ideal para cada proyecto depende del tamaño del mismo en cuanto a la especificación y los recursos humanos que se estén dedicando.

Diseño: DIS-7


Paso 3. Asignación de Subsistemas de Diseño a Nodos. Suele especificarse mediante métodos tabulares.

Ejemplo: En el software de gestión de un gran centro comercial tendríamos nodos en los almacenes, en las cajas, en las oficinas... y cada nodo tendría instalados sólo los subsistemas necesarios.

Diseño: DIS-8


Ejemplo de división en subsistemas (paso 2). Sitio web para la gestión de la asignatura “Ingeniería del Software de Gestión”. Se diseña con seis subsistemas:

Web Pública Web Privada Web Admin

Negocio

Acceso BD ASPMail

INegocioAPub

INegocioAPriv

INegocioAAdm

IBD IASPMail

ASPMail es una librería externa, que no implementaremos

Hay tres subsistemas que se encargan exclusivamente de tareas de interacción con el usuario:

• Web pública: Sitio web de acceso público. Contiene información genérica sobre la asignatura y un tablón de anuncios.

• Web privada: Sitio web de acceso restringido a alumnos y profesores. Se permiten, entre otros, consultar notas o apuntarse a prácticas.

• Web admin: Sitio web de acceso restringido a profesores. Permite gestionar los grupos y horarios de prácticas, introducir las notas de los exámenes y las entregas así como publicar anuncios en el tablón virtual.

Diseño: DIS-9


Los otros tres subsistemas NO tienen interacción directa con el usuario, y uno de ellos es un subsistema de soporte que no se deberá programar en el proyecto:

• Negocio: Implementa las tareas de todo el sistema a nivel de caso de uso (Ejemplo: CrearNuevoGrupo).

• Acceso BD: Implementa módulos de acceso a la BD (Ejemplos: InsertarGrupo, InsertarAlumnoEnGrupo).

• ASPMail: Implementa módulos para el envío de mensajes por correo electrónico, ya está codificado y vamos a reutilizarlo en este proyecto.

Diseño: DIS-10


Criterios a seguir en el diseño arquitectónico Entre otros:

• Presupuesto.

• Condiciones del cliente.

• Experiencia del equipo de desarrollo.

• Rendimiento esperado del sistema.

• Aplicación de “estándares” (no inventar la rueda).

Un par de cosas... Siguiendo la metodología MÉTRICA, en el EVS ya se debería haber planteado la necesidad de estudiar las bases de la arquitectura de la solución propuesta (estudio de alternativas).

En el diseño también deben especificarse, si no se ha hecho ya, los entornos de desarrollo y de pruebas que se utilizarán en el proyecto.

Diseño: DIS-11


Diseño de Detalle.

En esta actividad se diseña y especifica cada uno de los subsistemas de diseño.

Para ello se dividirá cada subsistema en unidades y módulos.

Subsistemas de diseño

Sistema

Módulos

Los subsistemas interactúan entre sí. En el diseño de detalle se deben especificar esas interacciones como interfaces

Unidades

Unidades: Cada una de las partes en que los entornos de desarrollo dividen un programa.

Aunque cada entorno de desarrollo cuenta con tipos de unidades específicos, suele haber, al menos, dos tipos:

• Unidades de código (ficheros .BAS en VB).

• Unidades de interacción con el usuario (formularios en VB).

Módulos: Funciones o procedimientos individuales.

Diseño: DIS-12


Interfaces entre partes del diseño Un interfaz entre dos partes del diseño (A y B) es:

• Un salto en la secuencia de control del sistema desde A hasta B (interfaz de control).

• Un intercambio de información entre A y B (interfaz de datos).

• Si los interfaces de control llevan asociados datos, se pueden denominar interfaces mixtos. Por ejemplo, llamadas a funciones con parámetros.

Nótese que puede haber intercambio de información sin que haya un salto en la secuencia de control. Por ejemplo, modificación de una estructura de datos común o de una tabla de la base de datos.

La documentación de los interfaces debe hacerse lo más completa posible, pues es muy probable que quien diseñe el interfaz y quien lo use sean dos personas diferentes.

Diseño: DIS-13


Reutilización en el diseño. Definición (pedestre): No REINVENTAR la rueda y ayudar a que otros no la REINVENTEN.

El concepto de reutilización debe extenderse tanto a módulos como a “mecanismos genéricos” (patrones) del diseño.

En la práctica consiste en:

1. Buscar en el diseño del programa:

Módulos o patrones parecidos a los que ya hemos programado anteriormente

Módulos o patrones que puedan ser útiles para desarrollos futuros

2. Para posteriormente:

• Incluir los módulos ya programados en el diseño

• Seguir los patrones aplicados ya anteriormente

• Diseñar esos módulos de la forma más genérica posible

• Documentar de forma completa los mecanismos genéricos que puedan ser aplicados en el futuro

Diseño: DIS-14


Reutilización en Métrica 3. METRICA 3 denomina “subsistemas de soporte” a los que:

• se reutilizan en un proyecto y fueron diseñados con anterioridad.

• están siendo diseñados con la intención de ser reutilizados.

• ofrecen funcionalidad a varios subsistemas diferentes del mismo proyecto.

Los módulos que deben hacerse únicamente para un proyecto se agrupan en “subsistemas específicos”.

Además METRICA pone énfasis en la identificación de “mecanismos genéricos de diseño” (“patrones” ó “recetas” reutilizables en el diseño y la codificación del software).

Diseño: DIS-15


Diseño en capas Un buen diseño separa los módulos dedicados a la interfaz de usuario de aquellos que implementan, realmente, la funcionalidad o acceden a las estructuras de datos.

Capa de IU (interfaz con el usuario)

Capa de negocio

Capa de acceso a datos

Base de datos

Estructuras de datos

Para conseguirlo hay dos posibilidades:

• Que los subsistemas pertenezcan exclusivamente a una capa (ver ejemplo en el apartado “diseño arquitectónico”).

• Que el diseño detallado de cada subsistema respete la existencia de capas.

Diseño: DIS-16


Por ejemplo: en los manipuladores de eventos asociados a los controles de formularios en entornos como VB ó Builder NUNCA habrá código para actualizar la BD.

Para las prácticas: En las unidades de interacción con el usuario no se permite utilizar código que modifique los contenidos de la BD. Sí permitiremos que haya código, en esas unidades, para obtener información de la base de datos.

Diseño: DIS-17


Más heurísticas del diseño de detalle (I). Primera idea: “No vale con que funcione”.

En cuanto al diseño modular:

• Tamaño del módulo: “pequeño” (repasar este concepto al explicar la “complejidad ciclomática” en el proceso de pruebas).

• Independencia funcional: cada módulo debe centrarse en una subfunción específica, con una interfaz sencilla.

La independencia se mide con dos criterios: la cohesión y el acoplamiento:

• La cohesión de un módulo es una medida proporcional a la relación entre las diferentes tareas que realiza.

El objetivo IDEAL de todo diseño es MAXIMIZAR la cohesión, de forma que cada módulo realice una sola tarea…

• El acoplamiento es una medida de la interconexión entre los módulos. El objetivo IDEAL del diseño es MINIMIZAR el acoplamiento.

Diseño: DIS-18


Más heurísticas del diseño de detalle (II). Un buen diseño es:

• MANTENIBLE.

• REUTILIZABLE.

• ENTENDIBLE.

• “PROBABLE”.

• ÓPTIMO en cuanto al uso de recursos de todo tipo. Habitualmente las optimizaciones implican perder otras buenas características del diseño como las mencionadas en el párrafo anterior.

Diseñar es, entonces, buscar un COMPROMISO entre las posibilidades existentes que resulte ADECUADO al problema que se pretende resolver.

Por ejemplo: es posible que el diseño del acceso a una estructura de datos que sea más complejo (menos “entendible”) resulte más eficiente (se realiza en menos tiempo).

Diseño: DIS-19


Diseño de Datos

Nota importante: Entendemos por estructuras de datos todo soporte que contenga información del sistema como

• Bases de datos.

• Ficheros auxiliares.

• Estructuras de datos propiamente dichas.

Objetivo. En el diseño de datos, a partir del modelo de datos realizado en el análisis, debe especificarse el diseño físico de todas las estructuras de datos.

Diseño: DIS-20


Optimizaciones en el diseño de datos Las formas normales son un paso previo de un buen diseño de datos.

Sobre el modelo de datos del análisis, se deben analizar todos los factores que determinen posibles OPTIMIZACIONES.

Se decidirá, justificadamente, qué optimizaciones aplicar y éstas deben ser especificadas de forma ordenada.

Un par de posibles optimizaciones:

• Crear campos (o tablas) “calculados”.

• “Romper” ó “unir” tablas.

Extracto de “Oracle 9i. Manual del administrador”, Kevin Money y Marlene Theriault. Oracle Press, 2002:

Diseño: DIS-21


Diseño de datos distribuido. Como la arquitectura del sistema puede tener diferentes nodos, debe especificarse qué estructuras de datos deben estar alojadas en cada nodo.

Por ejemplo, si la BD está repartida en varios nodos, debería documentarse un DED para cada nodo indicando qué “vista” del modelo global contiene.

Acceso a las estructuras de datos. Es habitualmente construir subsistemas de soporte para acceder a las estructuras de datos, de forma que actúen como intermediario entre el resto del sistema y la estructura (concepto de TAD).

El proceso de diseño (DSI) en Métrica

En las prácticas NO llevaremos a cabo este proceso:

Diseño: DIS-23


La construcción (CSI) en Métrica


Diseño: DIS-24


La implantación y aceptación (IAS) en Métrica


dis diseño - cd universidad de oviedodi002.edv.uniovi.es/~fanjul/isofg/curso2006-2007/...•...

Documents