DISEO DE LA SOLUCIN

F.J. Zarazaga Soria, J. Nogueras Iso, M.A. Latre Abada Ingeniera del Software I
Febrero 2010

Departamento de Informtica e Ingeniera en Sistemas

ndice
1. La tcnica del Diseo Estructurado 2. Las labores del diseo

24-feb-10

Diseo de la solucin
1. La tcnica del diseo estructurado

F.Javier Zarazaga Soria Javier Nogueras Iso Ingeniera del Software I

Departamento de Informtica e Ingeniera en Sistemas

ndice
1.1. Introduccin 1.2. El Diagrama de Estructura de Cuadrados de Constantine 1.3. El Diseo Estructurado
1.3.1. Principios 1.3.2. Estrategias de diseo: Anlisis de la transformacin y anlisis de la transaccin 1.3.3. Evaluacin y refinamiento del diseo 1.3.4. Definicin de programas

24-feb-10

1.1. Introduccin
Una definicin posible de Diseo, es la que aparece en el Glosario de Trminos de Calidad e Ingeniera del Software de la Asociacin Espaola de Control de Calidad:
"Es el proceso de definicin de la arquitectura software: componentes, mdulos, interfaces, procedimientos de prueba y datos de un sistema que se crean para satisfacer unos requisitos especificados

24-feb-10

Definiciones de conceptos relacionados

Mdulo
Conjunto de instrucciones (programa, subprograma, rutina) que implementan una funcin del sistema

Componente
Parte fsica y reemplazable de un sistema que encapsula e implementa un conjunto de interfaces Se utilizan para modelar elementos fsicos de un nodo del sistema tales como ejecutables, bibliotecas, tablas, archivos,

Interfaz
Conjunto de operaciones reconocibles (nombre asociado) que caracterizan el comportamiento de un elemento

24-feb-10

Objetivos del diseo

Realizar una descripcin de cmo va a ser el sistema desde un punto de vista fsico
El Diseo de la Arquitectura del Sistema El Diseo de la Estructura fsica de datos

Dos partes diferenciadas del diseo atendiendo al nivel de detalle:

Diseo de arquitectura: Proceso de definicin de la coleccin de componentes del sistema y sus interfaces. Diseo detallado: Proceso de descripcin ms detallada de la lgica del proceso y de las estructuras de datos.

24-feb-10

Qu se espera?
Se toma como punto de partida el conjunto de especificaciones funcionales (requisitos + anlisis) Dependiente del entorno tecnolgico
por ejemplo, no ser nunca igual realizar un diseo de la estructura de datos para ficheros convencionales que para una Base de Datos, donde existe un Sistema de Gestin de Base de Datos, el cual permite automatizar en gran medida las distintas tareas a realizar

Resultado -> especificacin del conjunto de programas a construir

24-feb-10

Diseo estructurado
Objetivos:
Obtener la estructura modular y los detalles de proceso del sistema partiendo solamente de los "productos" obtenidos en la fase de Anlisis del Sistema. Cambiar la atencin del QU al CMO. Obtener un diseo que no slo "funcione", sino que tambin sea mantenible, mejore la reutilizacin y se pueda probar y entender fcilmente.

Utilizar herramientas grficas (Diagramas de Estructura de Cuadros) para representar la estructura modular del sistema

24-feb-10

Caractersticas de los mdulos (I)

Mdulos de pequeo tamao
El impacto de un cambio a realizar puede ser perfectamente aislado. Si el tamao de los mdulos es reducido, una determinada modificacin afectar a un nmero mayor de mdulos, sin embargo, la cantidad de cdigo a considerar ser menor.

Independencia modular
Cuanto mayor es la independencia de un mdulo es ms sencillo trabajar con l, por tanto, el diseo debe reducir la comparticin de ficheros, de datos, la de dispositivos, las interfases comunes con el Sistema Operativo y las llamadas desde o hacia otros mdulos.

Caractersticas de Caja Negra

La caracterstica de Caja Negra se aplica a cualquier sistema, programa o mdulo para dar una visin exclusiva de sus entradas y salidas, sin tener en cuenta los detalles de cmo se realiza el proceso. El uso de la Caja Negra permite una visin ms fcil del conjunto, posponiendo la consideracin de los detalles para una etapa posterior

24-feb-10

10

Caractersticas de los mdulos (II)

Modelizacin conceptual
Un sistema ser ms fcil de mantener si el modelo utilizado en su diseo se ha basado en los conceptos lgicos de la organizacin, los cuales sern ms familiares y comprensibles para el personal de mantenimiento que las descripciones fsicas (equipo, organizacin de la unidad, cmo se realiza el trabajo en la actualidad...)

Aislamiento de los detalles

En un sistema existen partes que reflejan la filosofa y otras partes que reflejan los detalles. Debido a que los detalles son ms susceptibles de cambiar, ambas partes deben disearse por separado para evitar que una variacin en los detalles afecte a la filosofa del sistema.

24-feb-10

11

Diseo de procesos (I)

Una vez finalizada la Fase de Anlisis del Sistema, se dispondr, al iniciar la Fase de Diseo de un conjunto de especificaciones funcionales que describan, con trminos precisos:
Las entradas que suministran al sistema las entidades externas Las salidas aportadas por el sistema a dichas entidades externas Las funciones descompuestas que se han de realizar por ese sistema El modelo de datos lgico del sistema

Toda esta informacin estar almacenada en el diccionario del proyecto mediante la descripcin de Diagramas de Flujo de Datos, Procesos, Flujos de Datos, Diagramas de Estructuras de Datos, Diagramas de Entidades y Atributos

24-feb-10

12

Diseo de procesos (II)

Para pasar a construir el nuevo sistema es necesario convertir toda esta informacin en especificaciones de programas. Las tareas a realizar son:
Determinar qu mdulos implantarn los procesos terminales obtenidos en la Fase Anlisis del Sistema Organizar la estructura de estos mdulos y definir las conexiones entre los mismos Describir el pseudocdigo para cada mdulo

24-feb-10

13

1.2. Diagrama de estructura de cuadrados Structure Chart, Diagrama Estructurado (DEC) o mtodo de Constantine Permite definir cundo, bajo qu condiciones y cuntas veces se tienen que realizar los tratamientos identificados en los Procesos. Los datos se contemplan como la interfaz entre tratamientos sucesivos Este diagrama est compuesto por tres elementos bsicos:
Mdulos Conexiones entre mdulos Comunicacin entre mdulos

24-feb-10

14

Elementos de un DEC (I)

Mdulo
El mdulo representa un programa, subprograma o rutina, dependiendo del lenguaje que se vaya a utilizar. Se representa en el Diagrama mediante un rectngulo

El diseo estructurado NO ha impuesto la restriccin de que un mdulo tenga que ser compilado independientemente Se considera al mdulo como aquella parte de cdigo que se puede llamar Es, por tanto, algo que admite parmetros de llamada y retorna algn valor, si es preciso

24-feb-10

15

Elementos de un DEC (II)

Conexin
La conexin entre mdulos se representa mediante una lnea. En la figura se representa que: A llama a B B hace su funcin B retorna a A, inmediatamente despus del lugar donde se produjo la llamada a A a B El diagrama no dice nada sobre el cdigo de A ni sobre el de B, lo nico que sabe es que en A existe una sentencia del tipo CALL B.

24-feb-10

16

Elementos de un DEC (III)

Comunicacin
Dos tipos de informacin a intercambiar entre mdulos: datos, flags (o controles) Datos: informacin a ser procesada (pertenecen al entorno del problema) Mediante los "flag" o controles, se puede representar: Paso de control entre mdulos: un mdulo comunica a otro mdulo que ha terminado su proceso y traspasa al mdulo llamado el control del sistema. Comunicacin de que se ha producido un error en el proceso. Comunicacin de que se puede proceder a una operacin concreta, por ejemplo, en el caso de una insercin de datos del sistema, un mdulo puede "inspeccionar" los datos existentes y comunicar a otro que el dato a insertar no existe. El "mdulo" insertara el dato, etc.

24-feb-10

17

Elementos de un DEC (IV)

En la figura siguiente OBTENER DATOS CLIENTE llama a ENCONTRAR NOMBRE CLIENTE comunicndose la siguiente informacin: Nmero cuenta cliente (Dato). Nombre cliente (Dato). Nmero cuenta OK (Flag).

24-feb-10

18

Elementos de un DEC (V)

Qu diferencias existen entre datos y flags o controles? (a) Los datos son la informacin compartida por los mdulos, tanto por el llamado como por el que llama. La posicin de la flecha (hacia arriba o hacia abajo) indica el sentido de la comunicacin. Algo esencial es que los datos se van a procesar, mientras que los controles no. Los controles van a indicar el mdulo que llama la terminacin EOF, o error del mdulo llamado y deben ir siempre en sentido ascendente. (b) Los datos tienen gran importancia para el sistema en s mismo, hacia el exterior. Los flags tienen importancia en la comunicacin de informacin en el interior; son los que sincronizan la operativa de los mdulos.

24-feb-10

19

Otros smbolos de un DEC (I)

Secuencia:
Cuando un mdulo llama a varios, y esto se realiza solamente una vez La secuencia de ejecucin suele ser de izquierda a derecha y de arriba a abajo. En el ejemplo, la secuencia ser 1, 2 y 3. Los mdulos inferiores son los que realizan las tareas correspondientes y los superiores los que coordinan, por medio de los datos que se les va entregando.

24-feb-10

20

Otros smbolos de un DEC (II)

Iteracin:
Si adems de haber llamadas a varios mdulos, cada uno de estos mdulos inferiores se ejecuta varias veces, se representa como iteracin Este smbolo representa llamadas mltiples a los tres mdulos ms bajos en la jerarqua, y en este caso se realizarn los tres en esa secuencia, un nmero n de veces.

24-feb-10

21

Otros smbolos de un DEC (III)

Decisin:
Cuando existe una seleccin de camino, el mdulo superior tendr que realizar una decisin. Grficamente se representa por medio de un diamante que abarcar aquellas conexiones que formen parte de esta toma de decisin Decisin. El mdulo CALCULAR PREMIO contiene una decisin del tipo:

24-feb-10

22

Otros smbolos de un DEC (IV)

Adems de los ya vistos anteriormente, hay otros objetos que forman parte de la tcnica de Constantine como son:
Mdulo predefinido Es un mdulo que est disponible en la librera del sistema o de la propia aplicacin Almacn de datos Es la representacin fsica de dnde van a estar los datos en la realidad, en nuestro sistema Dispositivo fsico Es cualquier dispositivo por el cual se puede recibir o enviar informacin que necesite el sistema
NOMBRE

NOMBRE

DEVICE

24-feb-10

23

Ejemplo de DEC completo (I)

24-feb-10

24

Ejemplo de DEC completo (II)

Sobre la figura anterior se pueden aadir cuatro detalles:
El mdulo CALCULAR DEDUCCIONES NORMALES aparece slo una vez, aunque tiene dos "padres": Esto se hace para simplificar la escritura y el mantenimiento Escribir el mdulo slo una vez hace ms fcil comprobar el nmero y tipo de parmetros con los que los mdulos padres le llaman (consistencia de interfaz) Se seguir un criterio de lectura de izquierda a derecha para conocer el orden en que se realizan las llamadas a los mdulos

24-feb-10

25

Ejemplo de DEC completo (III)

Est permitido que un mdulo, por ejemplo el que realiza la llamada, reconozca una variable con un nombre, y otro, por ejemplo el llamado, la reconozca con uno diferente (En el grfico PAGO BRUTO POR HORAS y PAGO BRUTO POR CONTRATO se refieren a lo mismo y pueden ser reconocidos en CALCULAR DEDUCCIONES NORMALES como PAGO BRUTO). El nombre de un mdulo resume su funcin, es decir, lo que realiza para su padre. No tiene que resumir la funcin que realizan sus hijos

24-feb-10

26

Consejos
Un mdulo realiza una funcin y debe ser llamado por todos los mdulos que requieran esa funcin Un mdulo de nivel inferior puede llamar a otro mdulo de nivel superior de otra rama del diagrama Es desaconsejable que un mdulo de nivel inferior llame a otro de nivel superior de la misma rama ya que esto puede dar lugar a bucles sin salida

24-feb-10

27

1.3. El Diseo estructurado

1.3.1. Principios 1.3.2. Estrategia de diseo: Anlisis de la transformacin y anlisis de la transaccin 1.3.3. Evaluacin y refinamiento del diseo 1.3.4. Definicin de programas

24-feb-10

28

1.3.1. Principios del Diseo Estructurado (I)

Descomposicin / factorizacin
La descomposicin es la separacin de una funcin en otras que estuvieran contenidas en la primera La descomposicin consigue los siguientes objetivos: (a) Reducir el tamao del mdulo. (b) Hacer el sistema ms fcil de entender y modificar.
o En el ejemplo CALCULO SUELDO NETO POR HORAS se compone de dos funciones (bruto y deducciones). o Si se tuviera que modificar una de ellas, se tendra que tener cuidado en no tocar ninguna sentencia relacionada con la otra

24-feb-10

29

Principios del Diseo Estructurado (II)

En el diseo "top-down", de arriba a abajo, permite descomponer paso a paso, segn se vaya observando que los mdulos realizan mltiples funciones, acercndonos cada vez ms a la solucin ptima.

CALCULAR DEDUCCIONES NORMALES

24-feb-10

30

Principios del Diseo Estructurado (III)

(c) Minimizar la duplicidad de cdigo.
o Se evita tener que realizar una funcin en ms de un mdulo (En la figura el mdulo CALCULAR DEDUCCION NORMAL para CALCULO SUELDO NETO POR HORAS Y POR CONTRATO).

(d) Crear mdulos tiles (En la figura el mdulo VALIDAR CAMPO ALFABETICO puede utilizarse en cualquier otra parte del sistema, o en otros sistemas que se desarrollen. Por ejemplo, para hacer un chequeo en provincias o ciudades).

24-feb-10

31

Principios del Diseo Estructurado (IV)

El problema puede surgir cuando el diseador se pregunte en qu momento debe dejar de descomponer mdulos Se debe dejar de descomponer cuando no se encuentren funciones bien definidas
o No se debe crear un mdulo con una serie de lneas de cdigo agrupadas aleatoriamente

Se puede parar la descomposicin cuando la interfaz con un mdulo sea tan complicada como el mdulo en s mismo Un mdulo de mil lneas es malo, ya que trata demasiados asuntos en su interior, pero mil mdulos de una lnea son peores

24-feb-10

32

Principios del Diseo Estructurado (V)

Jerarqua
Al dividir los mdulos jerrquicamente, es posible controlar el nmero de ellos que interactan directamente con cualquiera de los otros El objetivo de aplicar una jerarqua de mdulos es conseguir separar los mdulos que realizan tareas de clculo y edicin de aquellos que toman decisiones y llaman a otros mdulos Se debe lograr un tipo de organizacin en donde los mdulos de niveles medios y altos del diagrama ejerzan el trabajo de coordinacin y manipulacin de los mdulos de niveles ms bajos, que son los que deben realizar tareas de clculo y edicin

24-feb-10

33

Principios del Diseo Estructurado (VI)

Se debern conseguir diseos lo ms equilibrados que sea posible. Puede decirse que un diseo est equilibrado si y slo si, trata con datos lgicos en su parte alta y con datos fsicos en su parte baja

24-feb-10

34

Principios del Diseo Estructurado (VII)

Independencia
Si los mdulos individuales son completamente independientes unos de otros, entonces el esfuerzo total implicado en el desarrollo del sistema es una funcin lineal del nmero de mdulos del sistema La definicin de mdulos est cerca de la idea de CAJA NEGRA: un mdulo no tiene que preocuparse de los detalles de la construccin interna del resto de los mdulos Hay que ver a los mdulos solamente por su funcin y por su apariencia externa

24-feb-10

35

1.3.2. Estrategias de diseo

Habr que estudiar la forma del DFD sobre el que se vaya a realizar el diseo y dependiendo de su estructura, utilizar una de las estrategias que se describen a continuacin El uso de una de las dos estrategias no supone que la otra no pueda ser utilizada. Depender nicamente de la forma del DFD y del peso de la actividad de los procesos A partir de esta primera estructura se realizar la evaluacin y refinamiento del diseo hecho, consiguindose, de esa forma, un diseo con una calidad alta Estas estrategias son:
Anlisis de Transformacin Anlisis de Transaccin

El objeto de estas estrategias es desarrollar una representacin global de la Arquitectura del Sistema. Una vez que se define la estructura, podemos evaluar y refinar esta Arquitectura, vindola como un todo

24-feb-10

36

Anlisis de transformacin (I)

El "Anlisis de Transformacin" es una estrategia, no un algoritmo
Si se siguen los pasos de un algoritmo los resultados estn asegurados y son correctos. Una estrategia consigue resultados buenos, pero no perfectos en una primera aproximacin.

El anlisis de transformacin es un conjunto de pasos que permiten obtener, a partir de un DFD con caractersticas de transformacin, la estructura del sistema El DFD con caractersticas de transformacin es aqul en el que se pueden distinguir tres zonas:
Flujo de llegada o entrada Flujo de transformacin o centro de transformacin Flujo de salida

24-feb-10

37

Anlisis de transformacin (II)

Esta divisin en tres partes va a facilitar que los datos que necesite el sistema se recojan por los mdulos que se encuentren en la/s rama/s de la izquierda, los datos que se intercambian en esa rama sern ascendentes: informacin de entrada al sistema. En las ramas centrales habr movimiento de informacin compartida tanto ascendente como descendente porque aqu los mdulos elaboran nuevos datos. En la/s rama/s de la derecha, la informacin ya ser la definitiva y el sentido de los datos debe ser descendente. En algn caso particular puede suceder que alguna de las partes sea vaca, esto es, no exista.

24-feb-10

38

Anlisis de transformacin (III)

Pasos del anlisis de transformacin
Aislar el centro de transformacin Convertir el DFD en la estructura adecuada al proceso de transformacin Factorizar la estructura de cada camino de accin Refinar la estructura del sistema utilizando medidas y gua de diseo

24-feb-10

39

Aislar el centro de transformacin (I)

El centro de transformacin es la parte del DFD que contiene las funciones esenciales del sistema y es independiente de las caractersticas particulares de la entrada y de la salida Para aislar el centro de transformacin habr que especificar los lmites del flujo de llegada y salida Los lmites de flujo de llegada y salida estn abiertos a interpretacin de cada uno y se pueden derivar soluciones de diseo alternativas variando la colocacin de los lmites de flujo, aunque una pequea variacin tendr poco impacto sobre la estructura final

24-feb-10

40

Aislar el centro de transformacin II

En el ejemplo siguiente, se ha aislado uno de los posibles Centros de Transformacin:

24-feb-10

41

Convertir la estructura (I)

La estructura del programa debe representar una distribucin descendente del control El resultado del paso de DFD a DEC debe ser una estructura en la que los mdulos de nivel superior toman las decisiones de ejecucin y los mdulos de nivel inferior ejecutan la mayora del trabajo de entrada, de clculo y de salida Convertir la estructura en la que aparecern subordinados a un mdulo de control del sistema, tres mdulos:
Mdulo controlador del proceso de la informacin de llegada Mdulo controlador del centro de transformacin Mdulo controlador del proceso de la informacin de salida

24-feb-10

42

Convertir la estructura (II)

Esto se representa en el diagrama siguiente

24-feb-10

43

Convertir la estructura (III)

Conversin de las transformaciones de cada proceso de un DFD en los mdulos correspondientes del diagrama de estructura. Se comienza en el lmite del centro de transformacin y se va hacia afuera a lo largo de los caminos de llegada y salida.

I
24-feb-10 44

Ejemplo de un sistema de bsqueda

El DFD corresponde con una parte del anlisis de un sistema que ofrece servicios para buscar informacin en catlogos electrnicos
4 Datos geogrficos 3 Datos Multimedia Datos bsqueda 5 Pginas Web

Usuario
Resultados bsqueda

1 Leer restriccin de bsqueda

5 Presentar resultados

4 Ejecutar bsqueda Bsqueda en catlogo

Restriccin de bsqueda verificada 2 Construir llamada al catlogo

Listado resultados

Estadsticos de bsqueda

Usuario

24-feb-10

45

Anlisis de la transformacin?
Flujo Entrada
Datos bsqueda 5 Pginas Web

Datos geogrficos 3 Datos Multimedia

Usuario
Resultados bsqueda

1 Leer restriccin de bsqueda

5 Presentar resultados

4 Ejecutar bsqueda Bsqueda en catlogo

Restriccin de bsqueda verificada 2 Construir llamada al catlogo

Listado resultados

Estadsticos de bsqueda

Flujo salida

Usuario

Centro Transformacin

24-feb-10

46

Anlisis de transaccin
El anlisis de transaccin se aplica cuando un DFD toma una forma en la que un dato determina la eleccin de uno o ms flujos de informacin La transaccin es evaluada y, basndose en su valor, el flujo se inicia por uno de los muchos caminos de accin El centro de flujo de informacin desde el que emanan varios caminos de accin se llama centro de transaccin Pasos del anlisis de transaccin:
Identificar el centro de transaccin Transformar el DFD en la estructura adecuada al proceso de transacciones Factorizar la estructura de cada camino de accin Refinar la estructura del sistema utilizando medidas y gua de diseo

24-feb-10

47

Ejemplo tipo

24-feb-10

48

Identificar el centro de transacciones

La posicin del centro de transaccin puede descubrirse inmediatamente a partir del DFD, viendo cul es el origen de una serie de caminos de informacin que fluyen radialmente Cada camino de llegada y todos los caminos de accin deben tambin aislarse. Cada camino de accin debe evaluarse en funcin de sus caractersticas individuales de flujo

24-feb-10

49

Transformar el DFD
El flujo de transacciones se convierte en una estructura de programa formada por una bifurcacin de entrada y una bifurcacin de salida
EL SISTEMA

24-feb-10

50

Factorizar la estructura
La estructura de la bifurcacin de entrada se desarrolla de la misma forma que el anlisis de transformacin, comenzando en el centro de transaccin y continuando desde el lmite hacia afuera a lo largo del camino de llegada Cada camino de flujo de accin del DFD se convierte en una estructura que se corresponde con las caractersticas especficas del flujo (flujo de transformacin o de transaccin) Cada camino de accin estudiado se desarrolla usando los pasos de diseo discutidos anteriormente

24-feb-10

51

Ejemplo de un sistema de preparacin de comidas

El DFD corresponde con una parte del anlisis del sistema de una empresa que se dedica a la preparacin de comidas y su servicio a domicilio
Peticin postre a elaborar

1 Recepcin pedido Datos pedido

Pedido

2 Desglose pedido

Peticin postre

3 Clasificar postre

4 Elaboracin postre

Peticin 1 plato

Peticin 2 plato

Cliente

8 Preparacin 1 plato 1 plato 9 Empaquetar 1 plato

7 Preparacin 2 plato

Peticin postre sin elaborar 6 Obtencin postre Postre

Postre 5 Empaquetar postre Postre empaquetado

2 plato

10 Empaquetar 2 plato

2 plato empaquetado 11 Preparar envo

Cliente
Pedido
24-feb-10 52

1 plato empaquetado

Anlisis de la transaccin?
Centro Transaccin
1 Recepcin pedido Datos pedido Pedido 2 Desglose pedido Peticin postre 3 Clasificar postre Peticin postre a elaborar

Transaccin C
4 Elaboracin postre

Peticin 1 plato

Peticin 2 plato

Cliente

8 Preparacin 1 plato 1 plato

7 Preparacin 2 plato

Peticin postre sin elaborar 6 Obtencin postre Postre

Postre 5 Empaquetar postre Postre empaquetado

2 plato

Transaccin B
10 Empaquetar 2 plato 2 plato empaquetado 11 Preparar envo

Transaccin A

9 Empaquetar 1 plato

Cliente
Pedido

1 plato empaquetado

24-feb-10

53

1.3.3. Evaluacin y refinamiento del diseo

Un buen diseo debe organizar la complejidad del problema de manera que el esfuerzo asociado con su desarrollo, prueba, entendimiento y mantenimiento pueda ser controlado y minimizado Para evaluar y mejorar el diseo obtenido con las estrategias mencionadas se utilizan dos unidades de medida:
Acoplamiento Es la medida del grado de interdependencia entre los mdulos de un sistema Cohesin Es una medida del grado de conexin funcional entre los elementos de un mismo modulo

24-feb-10

56

Acoplamiento
Un acoplamiento bajo es deseable por los siguientes motivos
Cuantas menos conexiones existan entre dos mdulos, menos oportunidad habr de que aparezca el efecto onda (un defecto de un mdulo, que puede aparecer afectando a otros mdulos) Para facilitar el mantenimiento de un mdulo sin tener que cambiar otros mdulos Para poder modificar un mdulo determinado sin necesidad de tener que mirar en el interior de otros mdulos

Tipos de acoplamiento
Normal De datos Por estampado Por control Comn Por contenido

Menor acoplamiento, mejor

Mayor acoplamiento, peor

24-feb-10 57

Acoplamiento normal
Dos mdulos estn acoplados normalmente si cumplen las siguientes condiciones
A invoca a B B realiza su funcin y retorna control a A La nica informacin que comparten es el paso de parmetros

Acoplamiento por datos

Todos los datos o parmetros que se intercambian son datos elementales, es decir, datos bsicos sin estructura interna: enteros, reales, caracteres,

Producir factura
Km das importe

Calcular alquiler Coche

24-feb-10

58

Acoplamiento por datos (II)

Hay que evitar pasar parmetros de un mdulo a otro, a menos que tengan una utilidad prctica
En el ejemplo del grfico REGISTRO MAESTRO se obtiene demasiado lejos de donde se utiliza. La solucin sera subordinar OBTENER MAESTRO CLIENTE a ACTUALIZAR MAESTRO.

24-feb-10

59

Acoplamiento por estampado (I)

Acoplamiento por estampado
Alguno de los parmetros es un dato compuesto, es decir, un dato con estructura interna (ej: registro, vector, etc.)
Producir factura
registro alquiler coche importe

Normalmente, es conveniente reducir el nmero de parmetros que intercambian los mdulos tanto como sea posible. Suele ser mejor que los datos de comunicacin que se pasen sean elementos de registros.

Calcular alquiler Coche

24-feb-10

60

Acoplamiento por estampado (II)

Pero
Evitar tendencia a agrupar parmetros que no tienen relacin ninguna, en un registro que los contenga. Esto lo nico que consigue es complicar el diseo. Nunca pasar registros que contengan muchos campos cuando en realidad el mdulo slo necesita algunos, ese paso introduce una complejidad extra y reduce la flexibilidad Ej: REGISTRO CLIENTE contiene los campos: Nm. Licencia, Nm. Socio, Gasolina Usada, Tipo Coche, Kms. Conducidos y Das Utilizados y el mdulo CALCULAR PRECIO ALQUILER, slo necesita los tres ltimos.

24-feb-10

61

Acoplamiento por control (I)

Acoplamiento por control
Alguno de los parmetros pretende controlar la lgica interna.

Normalmente ocurre con controles (flag) en sentido descendente que pretenden coordinar la lgica interna de un mdulo
Control nocivo
Obtener Registro
Valores flag seleccin 1: leer de teclado 2: leer de fichero registro teclado registro fichero

flag seleccion

Control Sistema E/S

24-feb-10 62

Acoplamiento por control (II)

Se tiene que evitar en lo posible que un mdulo "hijo" d rdenes al "padre".
Existen dos posibles soluciones para mejorarlo: Incluir la escritura del mensaje de error en ENCONTRAR NOMBRE. Que ENCONTRAR NOMBRE informe solamente que el nmero de cuenta no se ha encontrado y el "padre" tome la decisin de qu hacer con esa informacin.

Control OK
Producir informe de pago
nmero cuenta cliente nombre cliente numero cuenta invalido

Encontrar nombre
24-feb-10 63

Acoplamiento comn (I)

Acoplamiento comn
Dos mdulos A y B estn acoplados globalmente (presentan acoplamiento comn, global o por variables globales) si se refieren/acceden a una misma zona global de datos o variable global.

Ejemplo:
Acceso a la misma variable global Mdulos que acceden al mismo repositorio de datos Particularmente nocivo
A B Alta de Libros Prestamo de Libros

Variable global

LIBROS
24-feb-10 64

Acoplamiento comn (II)

Se recomienda no utilizar variables globales por CINCO razones:
Efecto onda: Un defecto (o mala prctica al programar) de cualquier mdulo que utiliza un rea global, puede transmitirse a cualquier otro mdulo que utilice ese rea global. Poca reusabilidad: Los mdulos que se refieren a datos globales siempre los utilizan con el mismo nombre disminuyendo la flexibilidad de los mdulos. Escasa trazabilidad: Se introduce un tipo de distanciamiento en el sistema en el tiempo. Puede ser difcil entender cmo lleg a tomar un valor determinado una variable. Difcil comprensin: Los sistemas son ms difciles de entender al tener que saber qu datos se utilizan en cada mdulo particular. Dificultad en el mantenimiento: Es difcil encontrar qu mdulos se deben cambiar cuando una parte de los datos cambia.

24-feb-10

65

Acoplamiento por contenido

Se dice que dos mdulos estn acoplados por contenido si uno se refiere al interior del otro en alguna de las siguientes formas:
modificando o leyendo sus datos saltando al interior de su cdigo (GOTO) cambiando el cdigo interno del mismo

El resultado de este acoplamiento son mdulos que no son reutilizables en absoluto

A cambia Instrucciones de B

Salto a una etiqueta (GOTO)

C se refiere a datos internos de B

24-feb-10 66

Factores a los que afecta el acoplamiento

Dos mdulos pueden presentar ms de un tipo de acoplamiento. En este caso se considera que tienen el peor de los acoplamientos que presentan
Tipo acoplamiento Por datos Por estampado Por control Comn Contenido Sensible a efecto onda Variable Variable Media Mala Mala Modificabilidad Comprensin Reusabilidad de mdulos Buena Media Pobre Pobre Mala

Buena Media Pobre Media/Pobre Mala

Buena Media Pobre Mala Mala

24-feb-10

67

Cohesin (I)
La cohesin es una medida de la fuerza de la relacin funcional entre los elementos de un mdulo, donde un elemento es:
Una instruccin, un grupo de instrucciones, una definicin de datos, o una llamada a otro mdulo

Es deseable tener mdulos con una cohesin funcional alta

Los elementos de un mdulo fuertemente cohesionado tendrn poca relacin con los elementos de otros mdulos. Por el contrario, si los elementos de un mdulo estn poco relacionados (poca cohesin), aumentar el nivel de trfico en las conexiones entre mdulos (aumenta el acoplamiento)

24-feb-10

68

Cohesin (II)
Tipos de cohesin
Funcional (caja negra) Secuencial (no demasiada) Comunicacional (caja negra) Procedural (caja gris) Temporal Lgica (caja blanca o transparente) Coincidental Mayor cohesin, mejor

Menor cohesin, peor

24-feb-10

69

Cohesin (III)
Cohesin funcional
Los elementos contribuyen a realizar una sola funcin. Ejemplos Mdulo para calcular raz cuadrada Mdulo para validar entrada por teclado

Cohesin Secuencial
Un mdulo cuyos elementos envueltos en tareas secuenciales. La salida de una tarea sirve como entrada para la siguiente. Ejemplo El mdulo repintar un coche se compone de:
o o o o o 1. Lavar carrocera 2. Rellenar huecos 3. Lijar carrocera 4. Aplicar capa de pintura 5. Aplicar capa final de pintura

24-feb-10

70

Cohesin (IV)
Cohesin comunicacional
El mdulo contiene actividades que comparten los mismos datos (no se pasan pasan datos, se trabaja sobre los mismos datos) Ejemplo: Mdulo para Completar un registro de un libro:
o Encontrar ttulo, encontrar precio, encontrar editorial, encontrar autor

Cohesin procedural
Mdulo cuyos elementos realizan actividades diferentes pero el flujo de control fluye de una a otra. Se ha decidido que las actividades se lleven a cabo en un orden determinado. Ejemplo: Mdulo para re-iniciar una aplicacin
o 1. Guardar datos o 2. Pedir nuevo login o 3. Lanzar ventana principal

24-feb-10

71

Cohesin (V)
Cohesin temporal
La nica conexin de sus elementos es que se ejecutan a la vez (las actividades estn relacionadas en el tiempo). Ejemplo Mdulo de inicio de una aplicacin = {Comprobar licencia de la aplicacin, Chequear presencia de impresora, comprobar mnimo espacio en disco,...}

Cohesin lgica
Los elementos contribuyen a actividades de la misma categora general. No comparten flujo de control. Ejemplo: Mdulo de algoritmos de ordenacin = {Ordenacin de enteros, Ordenacin de reales, Ordenacin de cadenas de caracteres, ...}

Cohesin casual o coincidental

Los elementos contribuyen a actividades diferentes sin relaciones significativas entre ellas Ejemplo: Mdulo de herramientas = {Buscar una subcadena, Determinar el mayor de dos nmeros, ...}
24-feb-10 72

Determinar la cohesin funcional

Realiza el mdulo una sola funcin?
NO SI

Cmo estn relacionadas las actividades dentro del mdulo?

Cohesin funcional
POR DATOS

Es importante la secuencia?
POR FLUJO CONTROL

SI NO SI NO

Secuencial Comunicacional Procedural Temporal Lgica Casual

Es importante la secuencia?
NINGUNA DE LAS DOS

Son las actividades de la misma categora general?

SI NO

Cuando todas las actividades de un mdulo estn relacionadas por ms de un nivel de cohesin, tiene la cohesin del nivel ms fuerte Si las actividades estn relacionadas por diferentes niveles de cohesin, entonces el mdulo tendr la cohesin del nivel ms dbil.

24-feb-10

73

Factores a los que afecta la cohesin

Tipo cohesin Funcional Secuencial Comunicac. Procedural Temporal Lgica Casual /Coincidental Acoplamiento Bueno Bueno Medio Variable Pobre Malo Malo Facilidad implantacin Buena Buena Media Pobre Media Mala Pobre Comprensin Buena Buena Media Variable Media Mala Mala Modificabilidad Buena Buena Media Variable Media Pobre Mala Mantenibilidad Buena Bast. Buena Medio Malo Mala Mala Mala

24-feb-10

74

1.3.4. Definicin de programas

Por ltimo, el diseador debe agrupar todos los mdulos que ha definido en distintos programas Existen en este sentido dos posturas muy contrastadas:
Construir un programa por cada mdulo. Se garantiza que los campos de trabajo de un mdulo no sean accesibles para otro para asegurar por tanto, que no se dan acoplamientos patolgicos (acoplamientos por contenido) Como contrapartida el funcionamiento se hace ms lento, puesto que los programas realizan continuas llamadas "CALL" a pequeos programas. Adems, un programa que sea llamado por otros estar cargado en memoria tantas veces como programas lo llamen. Agrupar todos los mdulos en un programa, asociando cada uno de ellos a un prrafo. Funcionamiento ms rpido, sin necesidad de realizar "CALL". Las desventajas son evidentes: desbordamientos de memoria, encarecimiento de las modificaciones, rigidez, etc.

24-feb-10

75

Criterios para definir programas

Se deben clasificar los mdulos en programas teniendo en cuenta las restricciones de equipo fsico y sistema operativo, de modo que el resultado sea lo ms eficiente posible, con programas pequeos y manejables. Los factores a tener en cuenta son:
Iteracin: Si un mdulo llama a otro iterativamente, se pueden evitar muchos CALL poniendo ambos mdulos en el mismo programa Volumen: Si se conoce el nmero de veces que un mdulo llama a otro, se deben poner en el mismo programa aquellos mdulos con un gran volumen de llamadas entre ellos Intervalo: Aquellos mdulos que en un pequeo intervalo tengan una alta frecuencia de llamada deben ir en el mismo programa Funcin opcional: Los mdulos que realicen funciones secundarias u opcionales pueden ir en programas independientes Ejecucin nica: Los mdulos que se ejecutan una nica vez en el sistema deben ser programas independientes

24-feb-10

76

Documentacin de programas (I)

Cada programa de una aplicacin debe documentarse exhaustivamente con el fin de facilitar su futuro mantenimiento por cualquier persona del departamento de desarrollo. Para ello se deber disponer de la siguientes informacin:
Estructuras de datos de los distintos ficheros de entrada y salida que utiliza el programa Diagrama de correspondencias entre ficheros de entrada y salida Estructura del programa una vez integradas las estructuras de entrada y salida Comentarios sobre el programa, indicando: Colisiones detectadas y forma de resolverlas Normas especiales de ejecucin Limitaciones Tablas de decisin

24-feb-10

77

Documentacin de programas (II)

Lista detallada de operaciones Estructura del programa conteniendo la asignacin de operaciones Lgica esquemtica (pseudocdigo) Listado del programa fuente, compilado y sin errores Listado de referencias cruzadas para facilitar la bsqueda de variables y entidades a lo largo del programa, cuando sea necesario efectuar su mantenimiento Listado de ocupacin de memoria Cualquier otro listado que proporcione el compilador o sistema operativo Documentacin de la prueba definitiva que se realiz para obtener la aceptacin del programa, adjuntando juegos de ensayo, condiciones de prueba, tiempo invertido, y resultados obtenidos

24-feb-10

78

Diseo de la solucin
2. Las labores del diseo

F.Javier Zarazaga Soria Javier Nogueras Iso Ingeniera del Software I

Departamento de Informtica e Ingeniera en Sistemas

ndice
2.1. Introduccin 2.2. Especificacin del entorno tecnolgico del sistema 2.3. Diseo de la arquitectura fsica del sistema
2.3.1. Estructura modular del sistema 2.3.2. Interfaces entre mdulos 2.3.3. Interfaces con otros sistemas 2.3.4. Interfaz con el usuario 2.3.5. Definicin de componentes del sistema

2.4. Diseo de la estructura fsica de los datos 2.5. Completar las especificaciones del diseo

24-feb-10

80

2.1. Introduccin: Contexto de Mtrica

24-feb-10

81

Diseo de sistemas

24-feb-10

82

2.2. Entorno tecnolgico del sistema

Descripcin de los componentes del equipo fsico y lgico en que funcionar el sistema Descripcin de las restricciones fsicas impuestas por los componentes anteriores Diseo de la configuracin de la red de comunicaciones del sistema, atendiendo a la distribucin geogrfica del mismo Definicin de los estndares tcnicos que se aplicarn al diseo y desarrollo del sistema, incluyendo:
Lenguajes. Procedimientos de entrada y salida de datos, acceso al sistema, manejo de errores y copias de seguridad

Posibilidad de existencia de directrices tecnolgicas dentro de la organizacin (tanto del cliente, como del desarrollador)

24-feb-10

83

Entorno tecnolgico del sistema (II)

Determinar las caractersticas del entorno tecnolgico en que va a funcionar el nuevo sistema Componentes tecnolgicos necesarios para proporcionar soporte a las funciones desarrolladas por el sistema, a la gestin de la informacin manejada y a la distribucin geogrfica de dicho sistema
Equipo fsico: Procesadores, dispositivos de almacenamiento, PCs, etc Gestin de datos: Sistemas de gestin de bases de datos, diccionarios de datos, etc Comunicaciones: Controladores de red, interfaces externas, protocolos, etc Equipo lgico: SO, lgica de red, generadores de aplicaciones, lenguajes de consulta, facilidades para el desarrollo de aplicaciones, herramientas CASE Gestin de operaciones en explotacin: Herramientas de control de trabajos, planes de contingencia, etc

La definicin del entorno tecnolgico del nuevo sistema influye de manera decisiva en el Diseo de la Arquitectura fsica del sistema y en el Diseo de la estructura fsica de datos del sistema

24-feb-10

84

Entorno tecnolgico del sistema (III)

Diagramas del entorno tecnolgico
Notacin informal
1 Worksattion, 2 monitores, tarjeta digitalizadora, S.O. Unix v.xx

1 Mdem Fax 33.000

PCs Pentium III, 3 256 Mb RAM, S.O. Windows NT 4.0, ...

LAN
Impresora Lser ....

24-feb-10

85

Requisitos de comunicaciones (I)

Disear las comunicaciones para el sistema En el caso de que el sistema est localizado en diferentes puntos geogrficos, se disear la configuracin de la red de intercambio de datos entre estos puntos, teniendo en cuenta los requisitos no funcionales especificados
Crecimiento y evolucin estimada del sistema, con respecto a cambios esperados en su distribucin geogrfica, descentralizacin de funciones, etc Puntos geogrficos o nodos de tratamiento de datos Volmenes de intercambio de datos entre las distintas redes, especificando "picos" o perodos de sobrecarga Tiempos de respuesta exigidos

24-feb-10

86

Requisitos de comunicaciones (II)

Configuracin de la red de comunicaciones del sistema:
Seleccionar las caractersticas de la red de comunicaciones (topologa, medios de transmisin, equipo lgico de la red, tipo de acceso, etc.) Especificar los nodos de la red y asignar requisitos de rendimiento a cada uno, teniendo en cuenta la distribucin geogrfica de las funciones del sistema y los requisitos de rendimiento del sistema Asignar terminales a los nodos de la red Especificar accesos locales en cada uno de los nodos

24-feb-10

87

2.3. Diseo de la arquitectura fsica

Diseo global del sistema a desarrollar
El Diseo de la arquitectura modular del sistema La definicin de las interfaces entre los mdulos creados La definicin de las interfaces con otros sistemas y de usuarios La descripcin de los componentes del sistema

Este conjunto de productos se integrarn en la documentacin general junto con la especificacin de los programas a realizar en la fase de codificacin Para la realizacin de este diseo se han de tener en cuenta las caractersticas tcnicas del entorno en que funcionar el nuevo sistema

24-feb-10

88

2.3.1. Diseo de la estructura modular (I)

Objetivo:
Identificar un conjunto inicial de actividades fsicas a realizar por el Sistema

Hay que tener en cuenta:

La divisin del sistema en subsistemas La divisin de subsistemas en funciones La divisin de funciones en subfunciones La divisin de subfunciones en los procesos que las describen El tipo de tratamiento por lotes o interactivo, de los procesos y subfunciones Las caractersticas de las funciones y procesos Elaboracin de informes y consultas Actualizacin de entidades del sistema Realizacin de algoritmos especficos

24-feb-10

89

Diseo de la estructura modular (II)

Es preciso asegurar que todas las funciones realizadas por el Sistema estn soportadas por el conjunto de actividades identificado
Necesidad de bsqueda de patrones dentro de las actividades con el fin de promover la reutilizacin de cdigo Necesidad de determinar actividades ya existentes en libreras generales de desarrollo, en forma de rutinas de uso general dentro de la instalacin

24-feb-10

90

Diseo de la estructura modular (III)

Mediante Diagramas de Estructuras de Cuadros de Constantine se obtiene:
Una Estructura de alto nivel que muestre el sistema descompuesto en los subsistemas que lo componen Se parte del DFD de nivel de subsistema se aplican las estrategias de paso del DFD al DEC Un conjunto de DEC para cada una de las actividades fsicas identificadas al comienzo de esta tarea mostrando: conjunto de mdulos que describen y controlan el tratamiento de la actividad fsica, comunicacin entre estos mdulos, y la jerarqua de los mismos Para ello se toman como punto de partida los DFD de nivel funcin, los DFD de nivel subfuncin y los DFD de nivel proceso, y se aplican las estrategias de paso de DFD a DEC

24-feb-10

91

Diseo de la estructura modular (IV)

Refinar los diagramas obtenidos, aadiendo mdulos con el fin de detallar el tratamiento de las actividades fsicas y que, por referirse a aspectos fsicos no considerados en los DFD de partida, no han sido determinados anteriormente Tratamientos de entradas y salidas Ediciones y validaciones de datos Asimismo, se incorporarn a los diagramas construidos, smbolos que detallen aspectos del tratamiento de las actividades, entre ellos: Iteracin en el tratamiento de los mdulos Opcionalidad en el tratamiento de mdulos Por ltimo se considerarn refinamientos en el diseo como consecuencia de la aplicacin de criterios de calidad especficos (acoplamiento y cohesin)

24-feb-10

92

2.3.2. Interfaz entre mdulos del sistema

Definir las interfaces entre los Mdulos del Sistema, incluyendo la comunicacin de informacin de control, as como la de los datos de la aplicacin. Cada interfaz entre mdulos debe incluir:
Los datos comunicados y su formato El origen y el destino de esos datos

Para la descripcin de estas interfaces entre mdulos, es preciso tener en cuenta las siguientes consideraciones:
Facilidad de mantenimiento Esto se conseguir mediante el diseo de interfaces sencillas que permitan reducir la complejidad de comunicaciones entre los mdulos (reducir el acoplamiento) Lmites del lenguaje o generador de cdigo

Mediante DEC

24-feb-10

93

2.3.3. Interfaz con otros sistemas

Definir las interfaces con otros sistemas que ya estn desarrollados y en funcionamiento, o bien que estn planificados o desarrollndose en paralelo En la definicin de estas interfaces se han de contemplar los siguientes aspectos:
Modo de operacin de la interfaz: por lotes o interactivo. Medio Frecuencia Evento que desencadenar ese traspaso de datos con otros Sistemas Formato de los datos que sern transferidos

Mediante DEC

24-feb-10

94

2.3.4. Interfaz de usuario

Establecer el diseo detallado de las interfaces de usuario para cada Componente del Sistema, que deber estar referido al entorno tcnico en el que trabajarn estas interfaces Se parte del prototipado de pantallas realizado en las labores de anlisis En algunos casos podr ser de inters definir nuevos dilogos especficos para los distintos tipos de usuarios definidos en el sistema, dependiendo de los requisitos de seguridad identificados

24-feb-10

95

Cmo realizar el diseo del interfaz de usuario? Depender de:

El tipo de interfaz de usuario El modelo de interaccin con el usuario

Veremos un ejemplo para el tratamiento de GUI en Windows

24-feb-10

96

Diferentes tipos y estilos de interfaz de usuario a lo largo de la historia

Interfaz basada en comandos (Sistemas Operativos como MS-Dos, Unix)
El programa espera a que el usuario introduzca comandos (escribiendo o mediante combinacin de teclas)

Interfaz con mens y formularios (ej. Edit de MS-DOS)

El programa presenta un conjunto de mens (generalmente estructura arborescente) mediante los cuales el usuario elige el comando que desea ejecutar. Tambin se presentan pantallas especiales, llamadas formularios, para que el usuario introduzca los datos.

Interfaz con ventanas (ej. Borland C++)

El programa permite trabajar con varias pantallas virtuales (ventanas) de forma simultnea (ej: editores que trabajan con varios documentos a la vez, mostrar varias tareas en sistemas multitarea).

Interfaz grfica (ej. Paint, Autocad)

El programa trabaja en modo grfico. Se incorporan, adems de los mens, formularios y ventanas, iconos que sustituyen a algunos mens (o incluso a todos). Suelen requerir la utilizacin de un dispositivo apuntador, como el ratn, que permite seleccionar de forma visual los comandos.

24-feb-10

97

Ejemplos de interfaz

24-feb-10

98

El modelo de interaccin con el usuario

Hay distintos mecanismos que dirigen la ejecucin de un programa
Programacin dirigida por el control La ejecucin del programa la dirige el propio programa y es ste quien indica en todo momento las acciones que se deben realizar y en qu orden Programacin dirigida por los datos Los datos de entrada son quienes sealan el orden de ejecucin de las acciones a realizar Programacin dirigida por eventos Los sucesos externos al programa (eventos) son los que dirigen la ejecucin

24-feb-10

99

Interaccin con el usuario en un sistema con GUI

Habitualmente, los sistemas con GUI manejan interacciones con el usuario utilizando un modelo dirigido por eventos
Cuando el usuario ejecuta una accin tal como mover un ratn, apretar una tecla, etc., se genera un evento del mismo tipo Un sistema GUI tal como Java, Microsoft Windows, MacOS, se ejecuta entorno a un bucle de eventos que est esperando a que esos eventos ocurran

El modo en que se llama al cdigo de la aplicacin para tratar los eventos puede variar entre los distintos sistemas:
En las distintas versiones de Windows, el programa de usuario tiene que escribir su propio bucle de eventos, y cuando ocurre un evento es la aplicacin quien tiene que indicar qu hacer con l

24-feb-10

100

Interaccin con el usuario en un sistema con GUI II

En sistemas como Java, la aplicacin slo necesita incorporar un manejador de eventos (listener o escuchador) para cada tipo de evento que emita y trate un componente de la interfaz. Ese manejador ser llamado si ocurre ese tipo de evento en ese objeto, sin necesidad de que intervenga el programador de la aplicacin [Modelo de delegacin de eventos]

Objeto evento

SI

NO Vista

Escuchador (Controlador)
ejecutar acciones (calcular, actualizar fichero, )

Objeto evento

Modelo
24-feb-10 101

GUI en Windows (lenguaje C)

Sistema basado en eventos Cada ventana dispone de un procedimiento que se encarga de gestionar los eventos que provienen de ella Cada evento que se produce se transmite como un mensaje compuesto por tres elementos: Tipo mensaje, parmetro izquierdo y parmetro derecho Los mensajes correspondientes a eventos sobre las ventanas son del tipo WM_COMMAND

24-feb-10

102

Organizacin del cdigo fuente

Funciones genricas, constantes, etc.

Control GUI

Programa principal Funcionalidad de la aplicacin

Incluidos por Windows

Base de datos sobre sistema de ficheros

Tipos de datos

Constantes que enlazan los recursos con el resto del sistema

Fichero de recursos
24-feb-10 103

Diagrama de secuencia, control GUI

usuario WinMain hInstance:HA NDLE pWindClass: PWINDCLASS (ventanaPrincipal) 1: iniciar aplicacin 2: applicationInit 3: creacin dilogo About
Bucle espera eventos

4: asignar mtodo applicationWndProc para tratar eventos

5: elegir opcin de men Ayuda 6: dispatchMessage 7: applicationWndProc 8: creacin 9: elegir botn aceptar 10: dispatchMessage 11: applicationWndProc

12: about

24-feb-10

104

Ejemplo GUI en Windows I

int CALLBACK WinMain(... ) /* metodo principal que crea ventanas e inicializa el sistema*/ { ... if (!hPrevInstance) if (!applicationInit (hInstance)) return (0); ... hWnd = CreateWindow ("Punto de venta", "Punto de venta", .... hInstance, ...); /* hWnd es el manejador de la ventana */ ... ShowWindow (hWnd, nCmdShow); /* Se muestra la ventanta. nCmdShow indica el modo de mostrar las ventanas*/ ...
24-feb-10 105

Ejemplo GUI en Windows II

... status = loadProductDataBase(); /* Intento cargar la base de datos de un fichero */ if(status != STATUS_OK) /* Si se ha producido un error, aviso e inicializo a vacia */ MessageBox(hWnd,"Problemas al abrir la base de datos de productos ...); ... /* Gestin de eventos. Bucle hasta llegar al evento de finalizacin de aplicacin (mensaje WM_QUIT) */ while (GetMessage (&msg, NULL, 0, 0)){ /* GetMessage obtiene mensajes de la cola de eventos */ TranslateMessage (&msg); DispatchMessage (&msg); /* pasa el evento al procedimiento que trate los eventos */ } return(msg.wParam); }
24-feb-10 106

Ejemplo GUI en Windows III

BOOL applicationInit (HANDLE hInstance) /* Inicializa la instancia de la aplicacin */ { PWNDCLASS pWndClass; ... pWndClass = (PWNDCLASS) LocalLock (hMemory); pWndClass->lpfnWndProc = (WNDPROC) applicationWndProc; /* Se indica cul es la funcin que se encargar de tratar los eventos */ ... pWndClass->hIcon = LoadIcon (hInstance, MAKEINTRESOURCE(IDI_ICON)); pWndClass->hCursor = LoadCursor (NULL, IDC_ARROW); pWndClass->lpszMenuName = MAKEINTRESOURCE(IDR_MENUPPAL); pWndClass->lpszClassName = (LPSTR) "Punto de venta"; ... }

24-feb-10

107

Ejemplo GUI en Windows IV

LONG CALLBACK applicationWndProc (

HWND hWnd /* ventana que ha producido el evento */ , UINT message /* mensaje (evento grafico a tratar */ , WPARAM wParam, LPARAM lParam /* extensiones del parmetro mensaje */
) /* funcin que gestiona los eventos de windows */ { switch (message){ case WM_COMMAND: /* se ha producido algn evento en la ventana */ switch (LOWORD(wParam)){ /* wParam identifica el origen del evento */ case ID_ADD_PRODUCT: ... case ID_ABOUT: DialogBox (hInst,"ABOUTBOX", hWnd, about); /* about es el procedimiento que gestiona los eventos del dilogo */ break;
24-feb-10 108

Ejemplo GUI en Windows V

case ID_EXIT: DestroyWindow (hWnd); break; default: return(DefWindowProc(hWnd, message, wParam, lParam)); } break; case WM_DESTROY: /* destruccin de la ventana */ if(saveProductDataBase() != STATUS_OK) MessageBox(hWnd,"Error al salvar la base de datos de productos); ... PostQuitMessage (0); /* Genera un WM_QUIT, terminar la aplicacin */ break; default: return(DefWindowProc(hWnd, message, wParam, lParam)); /* Se devuelve el evento tal como se recibi */ } return TRUE; }

24-feb-10

109

Ejemplo GUI en Windows VI

BOOL CALLBACK about (HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam) { switch (message){ case WM_COMMAND: switch (LOWORD(wParam)){ case IDOK: EndDialog (hDlg,0); return(FALSE); break; default: break; } return(FALSE); }

24-feb-10

110

Ejemplo GUI en Windows VII

#include "gestionVentas.h /* funciones relacionadas con la gestin de ventas */ #include "gestionProductos.h" /* funciones relacionadas con la gestin de productos * #include "productDataBase.h /* acceso a la base de datos de productos */ #include "ticketDataBase.h /* acceso a la base de datos de tickets */ #include "resource.h /* se definen los identificadores de los eventos IDOK, ID_ABOUT, */

24-feb-10

111

Implicaciones en el diseo de ventanas y mens Definir el gestor de eventos de Windows como un mdulo de librera Tratar cada evento susceptible de ser manejado como un flag de control Construir un mdulo gestor de flags asociado a cada ventana
Gestor de la ventana
Opcin pulsada

Sistema de eventos de Windows

Tratar pulsar botn aceptar

Tratar pulsar botn cancelar

...
24-feb-10 112

2.3.5. Componentes del sistema

Definir los componentes o unidades bsicas del desarrollo, describiendo, de forma breve, su funcionamiento
En principio, cada uno de los mdulos identificados en los DECs del Diseo de la Estructura Modular del Sistema constituir un programa (menor unidad de construccin de cdigo fuente) Sin embargo, se podrn agrupar mdulos con el fin de optimizar y disminuir el esfuerzo en la fase de Construccin Agrupar mdulos que procesan el mismo grupo de registros Agrupar mdulos con la misma lgica de tratamiento Agrupar mdulos con un alto nmero de iteraciones, altos volmenes de acceso a datos o gran frecuencia de proceso
o Para ello sern de utilidad los requisitos de rendimiento

Componentes
Se utilizan para modelar los elementos fsicos que se pueden encontrar en un nodo tales como ejecutables, bibliotecas, tablas, archivos, documentos,

24-feb-10

113

Componentes del sistema (II)

Producir una especificacin detallada de cada Componente a desarrollar
La lgica de tratamiento La llamada a otros componentes del sistema, o bien a un paquete adquirido La secuencia en que los parmetros van a pasarse a otros componentes

Definir el pseudo-cdigo necesario para su construccin, incluyendo:

Las entradas y salidas del sistema que se disearon en la Descripcin de interfaces de usuario Los accesos a bases de datos o ficheros Las llamadas a otros componentes del sistema descritas en la Descripcin de interfaces entre mdulos del Sistema La estructura de control interno de cada uno de los mdulos y especficamente las condiciones de fin de iteracin (bucles) o las condiciones para la toma de decisiones Las interfaces con otros sistemas definidos en la Descripcin de interfaces con otros sistemas

24-feb-10

114

2.4. Disear la estructura fsica de datos

En esta actividad se define la estructura fsica de datos que utilizar el sistema y se revisar dicha estructura con el fin de satisfacer los requisitos de rendimiento especificados El diseo fsico de la estructura de datos estar ntimamente relacionado con el entorno tecnolgico que se describe en la Especificacin del entorno tecnolgico del sistema Adems, se ha de garantizar que el diseo fsico de datos satisface las necesidades de tratamiento del nuevo sistema, y que las transacciones o dilogos crticos identificados se ejecutan dentro de los mrgenes de rendimiento exigidos, lo cual puede requerir una labor de optimizacin del diseo fsico de datos

24-feb-10

115

Modelo fsico de datos

Producir un modelo de datos fsico que tenga en cuenta la estructura de ficheros del entorno tecnolgico donde va a funcionar el sistema (Ficheros convencionales o Sistemas de Gestin de Base de Datos: Jerrquica, Relacional, en Red). Pasos:
Definir cmo se implantarn las entidades y relaciones del Modelo de datos Definir las claves, ndices u otras posibles maneras de acceder fsicamente a los datos, para cumplir todos los requisitos de acceso Definir las vistas o subesquemas de la Base de Datos para cada componente del sistema Revisar el Modelo fsico de datos, para asegurar que es consistente con el diseo de componentes del sistema

Uso de los diagramas de Entidad-Relacin

24-feb-10

116

Optimizar el modelo fsico (I)

Optimizar el modelo fsico de datos construido para las transacciones y dilogos crticos identificados de manera que se ajusten a los requisitos de rendimiento exigidos para el sistema en cuanto a tiempos de respuesta Criterios:
Volmenes estimados de las entidades de datos Tipos de accesos a las entidades (por clave primaria o clave secundaria, accesos a travs de otras entidades, etc.) Frecuencia de cada tipo de acceso Entidades a que accede cada transaccin

24-feb-10

117

Optimizar el modelo fsico (II)

Ante inconsistencias con respecto a los requisitos de rendimiento exigidos para el sistema se puede recurrir a una desnormalizacin del modelo de datos con el fin de reducir el nmero de accesos para las transacciones crticas
Introducir redundancias en los elementos de datos Introducir elementos repetitivos Redefinir o aadir relaciones entre entidades para hacer ms directo el acceso entre entidades Dividir entidades Modificar el tratamiento realizado por las transacciones crticas Combinar entidades, si los accesos para ellas son frecuentes dentro de la misma transaccin

24-feb-10

118

Normalizacin vs desnormalizacin
3 FN
1FN= No hay ningn atributo con valores mltiples 2FN = 1FN + Ningn subconjunto de atributos depende funcionalmente de parte de la clave 3FN = 2FN + Todos los subconjuntos de atributos no clave son independientes entre s

3FNBC =3FN+Las claves candidatas son los nicos atributos sobre los que se facilita informacin Ejemplo en 3 FNBC
Menor redundancia, ms accesos para recuperar el nombre del socio Dependencias del ejemplo anterior
numSocio codLibro fechaPrestamo nombreSocio

Ejemplo en 3FN
Mayor redundancia, menos accesos para recuperar el nombre del socio
PRESTAMO numSocio nombreSocio CC codLibro fechaPrestamo CasaEditorial CP: editorial pais

codLibro editorial

editorial pais

CC C.Aj

Diseo lgico final

PRESTAMO C.Aj CP: numSocio CP: codLibro fechaPrestamo SOCIO CP: numSocio nombreSocio
24-feb-10 119

C.Aj

Libro CP: codLibro editorial

C.Aj

Normalizacin vs desnormalizacin II
Ejemplo de combinacin de entidades
Repositorio de metadatos Implementado mediante un modelo relacional: una tabla por seccin de metadatos Implementado como una nica tabla almacenando cada registro como XML
<<RelationalTable>> La persistencia del dat aset METADATAREFERENCE pasa a ser sobre la tabla (from bdMetadat a) ME TA DATAREFERE NCE CREATION : DATE LASTREVIEW : DATE FUTUREREVIEW : DATE <<RelationalTable>> STANDARDNAME : VARCHAR CONTACT STANDARDVERSION : VARCHAR <<RelationalTable>> <<Relat ionalTable>> TIMECONVENTION : VARCHAR IAAAMETADATA <<FK>> LEFTOVER LANGUAGE : VARCHAR SOURCE : V ARCHAR <<FK>> DATASET_ID : INTEGER FK_LO_MDR TEXTT : CLOB IAAAPROVIDER : VARCHAR PK_METADATAREFERENCE = DATASET_ID TEXTTYPE : VARCHAR FK_IAAAMET_MDR DATASET_ID = DATASET_ID M OBTAINDATE : DATE ACCESSCONSTRAINTS : VARCHAR PK_LEFTOVER = DATASET_ID,STANDARD DATASET_ID = DATASET_ID OBTAINPROCESS : VARCHAR USECONSTRAINTS : VARCHAR STANDARD : VARCHAR UPDATE PROCESS : VARCHAR OTHERCONSTRAINTS : VARCHAR METADATA : CLOB PUBLISHLEVEL : VARCHAR FILEIDENTIFIER : VARCHAR COST : VARCHAR PARENTIDENTIFIER : VARCHAR REMARK : VARCHAR STATUS : VARCHAR PK_METADATA = DATASET_ID <<FK>> DROPDATE : DATE HIERARCHYLEVELCODE : VARCHAR FK_REFSYS_MDR SECURITYCLASSIFICATIONSYSTEM : VARCHAR <<FK>> SECURITYCLASSIFICATION : VARCHAR DATASET_ID = DATASET_ID Desaparecer SECURITYHANDLINGDESCRIPTION : VARCHAR FK_DQ_MDR <<RelationalTable>> REFERENCESYSTEM
(from bdIdentification)

<<Relat ionalTable>> IDENTIFICATIONINFORMATION

<<FK>>

DATASET_ID = DATASET_ID FK_IDE_MDR

(from bdReferenceSystem)

DATASET_ID = DATASET_ID <<RelationalTable>> DATAQUALITY

(from bdQuality) M

<<FK>> FK_DI S_MDR

<<RelationalTable>> SPATIALDOMAIN
(from bdIdentification)

<<FK>> FK_EAI_MDR DATASET_ID = DATASET_ID

REFSYSID_CODE : VARCHAR PROJECTION_CODE : VARCHAR ELLIPSOID_CODE : VARCHAR DATUM_CODE : VARCHAR TYPE : CHAR PK_REFERENCESYSTEM = DATASET_ID,TYPE

<<RelationalTable>> CITATION CITATION_ID : INTEGER TITLE : VARCHAR PUBLICATIONDATE : DATE EDITION : VARCHAR SERIESNAME : VARCHAR ISSUEIDENTIFICATION : VARCHAR PUBLICATIONPLACE : VARCHAR PUBLISHER : VARCHAR OTHERCITATIONDETAILS : VARCHAR GEOSPATIALDATAPRESENTATIONFORM : VARCHAR ONLINELINKAGE : VARCHAR ORIGINATOR : VARCHAR PK_CITATION = CITATION_ID IDENTIFIER : VARCHAR2 IDENTIFIERTYPE : VARCHAR2 ISBN : VARCHAR2 ISSN : VARCHAR2

DATASET_ID = DATASET_ID <<RelationalTable>> ENTITYANDATTRIBUTEINFORMATION

(f rom b dEntit yAn dAttribute)

<<Relat ionalTable>> DISTRIBUTIONINFORMATION

(from bdDistribution)

PK_ENTATTINF = DATASET_ID

<<RelationalView>>M DATASETS

24-feb-10

120

2.5. Completar las especificaciones del sistema Diagramas de despliegue Requisitos de Operacin, Seguridad y Control Planes de construccin Planes de implantacin

24-feb-10

121

Diagramas de despliegue
Ubicacin de los programas en los equipos Inclusin de otros componentes Notacin ms o menos formal

Equipo2 Equipo1 Gestor Clientes Facturas Clientes Gestor Facturas

24-feb-10

122

Otro ejemplo

24-feb-10

123

R. de Operacin, Seguridad y Control (I)

Definir, para cada uno de los componentes del sistema, los requisitos de operacin del mismo
Componentes del sistema que se ejecuten de forma regular Identificar los requisitos de tratamiento interactivo. Identificar los requisitos de tratamiento diario y definir la secuencia en que deben ser realizados, as como sus interdependencias Examinar el resto de los procesos que no sean diarios y establecer otros perodos de tiempo requeridos Componentes del sistema que slo se realicen si hay peticin Identificar el tipo de peticin de tratamiento de los componentes que no se vayan a utilizar de forma regular Establecer los procedimientos de peticin y acordarlos con los usuarios

24-feb-10

124

R. de Operacin, Seguridad y Control (II)

Especificar en detalle los requisitos de seguridad y control, que debern minimizar o eliminar la prdida o alteracin de los datos Revisar los requisitos no funcionales del sistema y especificar los procedimientos necesarios para cumplirlos
Especificacin de claves de acceso al sistema Especificacin de claves de acceso a los datos o a funciones especficas del Sistema Desarrollo de ficheros que permitan controlar los accesos al sistema ("dietarios o logs") Limitacin del nmero de intentos de acceso Especificacin de recuperacin y reanudacin de trabajos Especificacin de copias de seguridad o respaldo peridicas Especificacin en detalle de los procedimientos de control de trabajos

24-feb-10

125

R. de Operacin, Seguridad y Control (III)

Productos a construir:
Procedimientos de operacin de los componentes del sistema, tanto peridicos como mediante peticin Procedimientos de seguridad y control (acceso, copias de respaldo y recuperacin, etc...)

24-feb-10

126

Planificacin de la construccin
Preparar los planes para el desarrollo e integracin del nuevo equipo lgico y de los procedimientos de operacin necesarios para el nuevo sistema
Definicin de la secuencia de construccin de los componentes Especificacin de recursos necesarios Necesidades de personal de desarrollo. Tiempos y costes estimados para la realizacin de las distintas tareas de construccin Equipo fsico y equipo lgico requerido

24-feb-10

127

Ejemplo

24-feb-10

128

Planes de implantacin
Estimar a grandes rasgos las tareas necesarias para la implantacin
Personal necesario para introducir datos no existentes en el sistema actual Personal necesario para la conversin de datos al nuevo sistema Personal necesario para la realizacin de pruebas en paralelo del nuevo sistema Preparacin de un calendario de implantacin Fechas previstas de instalacin de equipos necesarios Tiempo estimado para la formacin

24-feb-10

129

24-feb-10

130