modelos de desarrollo de programas - fiwiki.orgmdp... · • debe ser breve y concisa y constituye...

Modelos de Desarrollo de Programas

Modelos de Desarrollo Estructurados

Andrés Martín Martín

Curso 2008/2009

1

Índice

1. Examen (Survey) 3 2. Análisis Estructurado 4 2.1. Modelo Ambiental 4 2.2. Modelo de Comportamiento 7 2.2.1. Modelo de Proceso 7 2.2.2. Modelo de Datos 17 2.3. Modelo de implantación del usuario 20 - Conclusiones 22 3. Diseño 23 3.1. Modelo de implantación del sistema 23 3.2. Modelo de implantación de programas 23 - Diseñar el diagrama de estructura 24 - Diseñar los módulos 37 - Diseñar las bases de datos o ficheros 41 - Empaquetar el diseño 41 - Conclusiones 43 4. Implementación 44

- Estrategias estándar para la construcción de un programa (y para la selección de los módulos) 45

- Complejidad de los stubs y drivers según el módulo que constituyen 46 - Estrategias de implementación mixta 47 - Costes de implementación 48 - Implementación de la agenda personal 49 - Ejemplo de codificación en C++ 50 - Conclusiones 54

2

MDP - ESTRUCTURADO Introducción

Una forma de representar el espacio problema, que surgió a partir de los años 70, es describiendo el problema a través del flujo de datos que lo definen. En esta modalidad de desarrollo, el problema a modelar en la computadora se contempla como un conjunto de diferentes datos de entrada (fuentes) que sufren una serie de transformaciones como consecuencia de diferentes procesos que actúan sobre los datos, obteniéndose como resultado unos flujos de salida que reciben los receptores de la información (sumideros). A esta metodología de desarrollo de programas se la denomina “metodología estructurada orientada al flujo de datos”, o simplemente “metodología estructurada”.

El tema tiene por objeto presentar en tres lecciones la Metodología Estructurada Orientada al Flujo de Datos, describiendo su ciclo de vida básico consistente en:

- Examen (o Survey), que determina la viabilidad del proyecto.

- Análisis, que modela una especificación estructurada del sistema.

- Diseño, que desarrolla las especificaciones estructuradas del sistema.

- Implementación, que consiste en seleccionar los módulos a implementar, codificarlos e integrarlos en el sistema.

En la primera lección se describen las dos primeras etapas de la metodología: el Examen (o Survey) y el Análisis. En la segunda lección se describe la etapa de Diseño. Y en la tercera lección se describe la etapa de Implementación.

Objetivos de la lección: Examen y Análisis

• El Examen (o Survey) se inicia cuando el usuario solicita automatizar una parte o todo su sistema de negocio. Esta actividad se conoce como estudio de viabilidad o estudio inicial del sistema, ya que tiene como objetivo determinar si el sistema de negocio se puede informatizar o no.

• El Análisis, llamado en esta metodología Análisis Estructurado, tiene como objetivo transformar las políticas del usuario y el esquema del proyecto, en una especificación estructurada. Esto implica modelar el sistema desde tres puntos de vista: analizando las características externas del sistema, las características internas y las peculiaridades de instalación del usuario. Ello proporciona un modelo del sistema que describe los requerimientos del usuario.

Desarrollo Estructurado aplicando la metodología orientada al flujo de datos

En esta metodología el problema se describe a través del flujo de datos que lo define. El problema se puede contemplar como un conjunto diferente de datos de entrada (fuentes) que sufren una serie de transformaciones como consecuencia de diferentes procesos que actúan sobre los datos, obteniéndose como resultado unos flujos de salida que reciben los receptores de la información (sumideros)

A esta metodología se la denomina "metodología estructurada orientada al flujo de datos", o simplemente "metodología estructurada".

El ciclo de vida de un proyecto orientado al flujo de datos consta básicamente de las seis etapas que se describen en la figura adjunta: Examen (o survey), Análisis Estructurado, Diseño Estructurado, Implementación Estructurada, Generación del Test de Aceptación, y Control de Calidad.

3

Desarrollo Estructurado aplicando la metodología orientada al flujo de datos

Aquí estudiaremos las cuatro primeras: Examen, Análisis Estructurado, Diseño Estructurado e Implementación Estructurada, que son las que se aplican en los proyectos pequeños.

1. Examen (Survey)

Definición

Objetivo: Consiste en realizar el estudio inicial del sistema para determinar su viabilidad (no se realiza en problemas pequeños porque se supone que son viables).

Actividades: las actividades que se desarrollan en esta etapa son las siguientes:

• Identificar a los usuarios responsables y definir la actividad del sistema.

• Identificar las deficiencias actuales del sistema.

• Establecer metas y objetivos para el nuevo sistema.

• Determinar si es factible automatizar el nuevo sistema y, en caso afirmativo, presentar escenarios aceptables.

• Preparar el esquema del proyecto que se usará para guiar el resto del proyecto (consiste en describir los detalles del ciclo de vida que seguirá el resto del proyecto).

El Esquema del Proyecto incorpora la siguiente información: resumen del proyecto; restricciones legales, técnicas y económicas que tiene el proyecto; escenarios aceptables (si va ser centralizado, distribuido, etc.); e informe de costes/beneficios para ver si el proyecto es rentable.

4

2. Análisis Estructurado

Introducción

Objetivo: Consiste en “modelar una especificación estructurada del sistema”

Producto: Proporciona una “Especificación Estructurada”

Para realizar el análisis estructurado hay que desarrollar los modelos: ambiental, de comportamiento y de implantación del usuario.

2.1 Modelo Ambiental

Introducción

“El Modelo Ambiental modela el exterior del sistema”

Para lo cual:

• Define las interfaces entre el sistema y el resto del mundo.

• Indica qué cosas forman parte del sistema y cuáles no.

El Modelo Ambiental consta de tres componentes: declaración de objetivos, diagrama de contexto y lista de sucesos.

Declaración de Objetivos

“Es una declaración textual del propósito del sistema desde el punto de vista del usuario”

• Debe ser breve y concisa y constituye el enunciado del problema.

Vamos a aplicar esta Metodología Estructurada orientada al Flujo de Datos al ejemplo de modelar una agenda personal que presenta el siguiente enunciado:

Se trata de realizar un programa que gestione una agenda personal. En esta agenda el usuario podrá almacenar dos tipos de elementos: datos de las personas que conoce y datos de las citas que tiene con esas personas.

– Personas: nombre completo (apellido 1, apellido 2 y nombre), número de teléfono y dirección de correo electrónico.

– Citas: fecha, horas de comienzo y fin, persona con la que se establece y el lugar.

Las operaciones que puede realizar el usuario con su agenda son de dos tipos: modificación de la agenda y consulta de la información almacenada.

– Agregar elementos en la agenda (personas y citas), para lo cual deberá proporcionar todos los datos correspondientes al tipo de elemento creado.

– Eliminar elementos, identificando el elemento que desee eliminar. Para ello deberá proporcionar el nombre completo (para las personas) o la fecha y hora de comienzo (para las citas).

– Consultar la información contenida en la agenda. Por un lado podrá solicitar todos los datos de una persona, dado su nombre completo. Por otro, podrá obtener una lista de todas las citas pendientes para un día concreto.

5

Por último, deben tenerse en cuenta las siguientes restricciones al funcionamiento de la agenda.

– Las personas deben ordenarse alfabéticamente por el nombre completo. Las citas deben ordenarse por fecha de celebración y, si hay dos citas el mismo día, se ordenarán por hora de comienzo.

– No pueden existir dos personas que tengan el mismo nombre completo. El programa deberá comprobarlo cuando se metan datos de una nueva persona.

– No pueden existir dos citas el mismo día y a la misma hora. El programa deberá comprobarlo cuando se creen nuevas citas.

– Todas las citas que se introduzcan deberán ser con personas que aparezcan en la agenda. El programa deberá comprobarlo cuando se creen nuevas citas.

Diagrama de Contexto

• “Define las fronteras del sistema”

• “Describe entidades, flujos de datos y almacenes externos”

Notación de los diagramas de flujos de datos (DFD):

La notación utilizada para representar el diagrama de contexto y los diagramas de flujos de datos en general es la siguiente:

a. Entidad externa: es un productor o consumidor de información que reside fuera de los límites del sistema que se modela. Se denomina también fuente o sumidero. Sólo suele aparecer en el DFD de nivel 0 (diagrama de contexto). Por ejemplo, la entidad usuario.

b. Flujo de datos: es un elemento o colección de elementos de datos. Se representa mediante un arco dirigido etiquetado. Las etiquetas llevan un ‘_’ para separar palabras. Por ejemplo, datos_personales.

Nota: Los flujos de datos que van o salen de los almacenes no suelen llevar nombre.

c. Almacén de datos: es un sistema de almacenamiento de información. Por ejemplo, el almacén Persona.

d. Proceso: es una función que transforma los flujos de datos de entrada en uno o varios de salida. Se representan como círculos, con un identificador y un nombre. Por ejemplo, el proceso de Leer Datos.

6

El Diagrama de Contexto es una burbuja (proceso) con entidades externas, flujos de datos y almacenes externos, si los hubiere.

Ejemplo: el Diagrama de Contexto de la agenda personal es el siguiente:

• Tiene una entidad externa que actúa como fuente y sumidero que es el Usuario.

• Tiene como flujos de datos de entrada: datos_alta_persona (dap), datos_consulta_persona (dcp), datos_baja_persona (dbp), datos_alta_cita (dac), datos_consulta_cita (dcc), datos_baja_cita (dbc), y datos_erróneos (de).

• Tiene como flujos de datos de salida: inf_alta_persona (iap), inf_consulta_persona (icp), inf_baja_persona (ibp), inf_alta_cita (iac), inf_consulta_cita (icc), inf_baja_cita (ibc), inf_error_datos (ied).

• No tiene ningún almacén externo.

Lista de Sucesos

La lista de sucesos comprende los sucesos (o eventos) externos a los cuales debe responder el sistema. La lista de suceso debe ser consistente con el diagrama de contexto.

Para hacer consistente el diagrama de contexto con la lista de sucesos hay que tener en cuenta que cada flujo de entrada es necesario para producir un suceso y cada flujo de salida da respuesta a un suceso.

Ejemplo: La lista de sucesos de la agenda es la siguiente:

- Alta de una persona: (corresponde a los flujos dap e iap)

- Consulta de una persona: (corresponde a los flujos dcp e icp)

- Baja de una persona: (corresponde a los flujos dbp e ibp)

- Alta de una cita: (corresponde a los flujos dac e iac)

- Consulta de una cita: (corresponde a los flujos dcc e icc)

- Baja de una cita: (corresponde a los flujos dbc e ibc)

- Error de datos: (corresponde a los flujos de e ied)

7

2.2 Modelo De Comportamiento

Modelo de Comportamiento

“Modela el comportamiento interno del sistema de acuerdo con el modelo ambiental”

Se divide en tres modelos: modelo de proceso, modelo de datos y diagrama de transición de estados.

2.2.1 Modelo de Proceso

DFD (diagrama de flujo de datos)

El Diagrama de Flujo de Datos es una técnica gráfica que representa el flujo de información y las transformaciones que se aplican a los datos al moverse desde la entrada a la salida. El DFD se describe por niveles: 0 (diagrama de contexto), 1,2, ... y dentro de cada nivel se divide en procesos más pequeños. Para su descripción se utilizan como herramientas: los procesos, los flujos de datos y los almacenes.

El DFD se va refinando por niveles: el Diagrama de Contexto (nivel 0) se transforma en un diagrama con varios procesos más detallados (diagrama 0, de nivel 1). Cada proceso se numera (del 1 en adelante).

Los procesos de nivel 1 se pueden expandir en procesos más pequeños obteniéndose un diagrama de nivel 2 para cada proceso de nivel 1. La numeración de los procesos de nivel 2 se indica como <padre>.<hijo> (1.1, 1.2, ...).

La figura adjunta describe el esquema de un DFD por niveles:

La expansión de un proceso tiene que estar equilibrada en las entradas y salidas. Es decir, si una burbuja de un nivel superior tiene, por ejemplo, 2 entradas y 2 salidas de flujos, y se expande en varias burbujas del nivel siguiente, este nivel inferior también tiene que tener 2 entradas y 2 salidas de flujos (ver proceso 3 del nivel 1, y procesos 3.1, 3.2 y 3.3 del nivel 2, en la figura anterior).

Ejemplo. A continuación se presentan los diagramas de flujo de datos de la agenda personal.

8

• DFD 0 (Nivel 1):

El Diagrama de Contexto (nivel 0) se descompone en cuatro procesos: Leer Datos, Tratar Personas, Tratar Citas y Escribir Resultados.

Leer Datos lee todos los datos de la entrada. Si son datos relativos a personas se los pasa al proceso Tratar Persona. Si son datos relativos a citas se los pasa a Tratar Cita. Y si los datos tienen algún error de formato se los pasa directamente a Escribir Resultado.

El proceso Tratar Persona lee y escribe en el almacén Persona para realizar su trabajo de gestión de los datos de las personas. También debe leer y escribir en el almacén Cita, dado que al eliminar una persona se eliminan todas las citas con esa persona.

Por otro lado, el proceso Tratar Cita lee y escribe en el almacén Cita y sólo lee del almacén Persona (al agregar una cita se debe localizar su persona).

Vemos que Leer Datos y Escribir Resultado son procesos unitarios que no precisan descomponerlos en otros más pequeños. Mientras que Tratar Persona y Tratar Cita exigen expandirlos en otros procesos más pequeños ya que tratan varias funciones como las de agregar, consultar y eliminar una persona o una cita.


El proceso Tratar Persona se ha descompuesto en tres procesos: Agregar Persona, Consultar Persona y Eliminar Persona.

Agregar Persona da de alta a una persona, para lo cual accede al almacén Persona para ver si existe esa persona y en caso de que no exista la agrega. Consultar Persona trata las consultas sobre personas, para lo cual accede al almacén Persona en modo de lectura para extraer los datos de esa persona en caso de que exista. Eliminar Persona da de baja a una persona, para lo cual accede al almacén Persona para ver si existe esa persona, y en caso de que exista la elimina y accede al almacén Cita para eliminar todas las citas existentes con esa persona.

9


El proceso Tratar Cita se ha descompuesto en tres procesos: Agregar Cita, Consultar Citas y Eliminar Cita.

Agregar Cita da de alta a una cita, para lo cual accede al almacén Persona en modo de lectura para ver si existe la persona citada y, en caso de que exista, accede al almacén Cita para ver si existe esa cita y en caso de que no exista la agrega. Consultar Citas trata las consultas sobre citas, para lo cual accede al almacén Cita en modo de lectura para extraer los datos de esa Cita en caso de que exista.

Eliminar Cita da de baja a una cita, para lo cual accede al almacén Cita para ver si existe esa Cita, y en caso de que exista la elimina.

10

Especificación de Proceso

Para la especificación de procesos se utiliza el lenguaje de descripción de proceso (LDP) siguiente:

• Especificación Secuencial: indica una secuencia de acciones.

Acción 1

Acción 2

………

Acción n

• Especificación Condicional Simple: si se cumple una condición se realiza una serie de acciones.

if condición

then

acciones

endif

• Especificación Condicional Doble: si se cumple una condición se realiza una serie de acciones y, en caso contrario, otras acciones distintas.

if condición

then

acciones

else

acciones

endif

• Especificación Condicional Múltiple: se evalúa una expresión y para cada posible resultado se llevan a cabo acciones distintas. “default” indica el resto de los valores que no se han considerado antes.

case expresión

= valor 1

acciones

= valor 2

acciones

…

default

acciones

endcase

11

• Especificación repetitiva Mientras: se repiten una serie de acciones mientras se cumpla una condición. La condición se evalúa antes de comenzar la repetición.

while condición

acciones

endwhile

• Especificación repetitiva Hasta: se repiten una serie de acciones hasta que se cumpla una condición. La condición se evalúa después de haber realizado al menos una repetición.

repeat

acciones

until condición

• Especificación repetitiva Para: se repite una secuencia de acciones un número determinado de veces, indicado por los valores inicial (valor1) y final (valor2) de una variable (var). Opcionalmente se puede indicar el incremento que se aplica en cada iteración (valor3).

for var from valor1 to valor2 by valor3

acciones

endfor

• Especificación repetitiva Paratodo: se repite una secuencia de acciones sobre cada uno de los elementos de una colección de datos.

forall elemento in colección

acciones

endforall

• Especificación de una actividad

Nombre_actividad (argumentos)// comentar lo que hace

• Comentarios

// esto es un comentario

/* esto es un comentario*/

En la especificación de un proceso se utiliza el siguiente formato:

12

Donde <id> indica el número del proceso en el DFD, y <nombre> es el nombre del proceso en el DFD. Entrada: son los flujos de datos y almacenes que entran al proceso, y Salida: son los flujos de datos y almacenes que salen del proceso.

Ejemplo:

En el caso de la agenda personal los procesos finales que habría que especificar son: Leer Datos, Agregar Persona, Consulta Persona, Eliminar Persona, Agregar Cita, Consultar Cita, Eliminar Cita, y Escribir Resultado.

A continuación se describen, a título de ejemplo, los procesos: Leer Datos, Agregar Persona y Consultar Cita. Para ello hay que tener presente los DFD’s, diseñados anteriormente.

• Leer Datos:

- Entrada tiene el flujo datos que está formado por el tipo de operación (1= alta persona, 2= consulta persona, etc.) y por los datos de la operación (por ejemplo, si es “alta de persona” los datos de la operación son el nombre, el teléfono y el email).

- Proceso tiene dos actividades: Pedir tipo de operación, que puede ser del 1al 6 (o ser erróneo); y Pedir datos de la operación, que puede ser desde alta de persona a baja de cita.

- Salida tiene tres flujos de datos: datos operación persona (estos datos dependen del tipo de operación realizado, por ejemplo, si ha sido una “consulta de persona” será el nombre de la persona) que van a los procesos 2.1, 2.2 y 2.3 según el tipo de operación de persona, datos operación cita (por ejemplo, si ha sido una “alta de cita” serán la fecha, hora de inicio, hora de fin, persona citada y lugar) que van a los procesos 3.1, 3.2 y 3.3 según el tipo de operación de cita y error datos (se producen cuando existe un error de formato o el tipo de operación es desconocido) que va al proceso 4 Escribir Resultado.

Proceso 1: Leer Datos

Entrada:

datos // tipo_operación + datos_operación

Proceso:

Pedir tipo_operación

case tipo_operación

= 1 Pedir datos_operación_alta_Persona

if error de formato

then

error_datos = “Error datos alta Persona”

Ir al proceso 4

else

Ir al proceso 2.1

endif

= 2 Pedir datos_operación_consulta_Persona

if error de formato

13

then

error_datos = “Error datos consulta Persona”

Ir al proceso 4

else

Ir al proceso 2.2

endif

= 3 Pedir datos_operación_baja_Persona

if error de formato

then

error_datos = “Error datos baja Persona”

Ir al proceso 4

else

Ir al proceso 2.3

endif

= 4 Pedir datos_operación_alta_cita

if error de formato

then

error_datos = “Error datos alta cita”

Ir al proceso 4

else

Ir al proceso 3.1

endif

= 5 Pedir datos_operación_consulta_cita

if error de formato

then

error_datos = “Error datos consulta cita”

Ir al proceso 4

else

Ir al proceso 3.2

endif

= 6 Pedir datos_operación_baja_cita

if error de formato

14

then

error_datos = “Error datos baja cita”

Ir al proceso 4

else

Ir al proceso 3.3

endif

default:

error_datos = “Comando desconocido”

Ir al proceso 4

end case

end proceso 1

Salida:

datos_op_persona | datos_op_cita | error_datos

• Agregar Persona:

- Entrada tiene el flujo de datos operación de alta de persona (nombre, teléfono y el email), y la información del almacén Persona.

- Proceso tiene dos actividades: BuscarPersona, que busca a una persona en el almacén Persona; y AlmacenarNuevaPersona, que incorpora los datos de alta de una persona en el almacén Persona.

- Salida tiene el flujo de datos resultados de alta de persona (“Persona ya existe:”, “Persona agregada con éxito”, más el nombre de la persona) que va al proceso 4 Escribir Resultado, y el almacén Persona.

Proceso 2.1: Agregar Persona

Entrada:

datos_op_alta_persona // nombre_completo + teléfono + email

Persona (almacén)

Proceso:

existe = BuscarPersona(nombre_completo, Persona)

if existe

then

res_alta_persona = “Persona ya existe: ” +

nombre_completo

Ir a proceso 4

15

else

AlmacenarNuevaPersona(datos_op_alta_persona, Persona)

res_alta_persona = “Persona agregada con éxito: ” +

nombre_completo

Ir a Proceso 4

endif

end proceso 2.1

Salida:

res_alta_persona // [“Persona ya existe: ” |

// “Persona agregada con éxito: ”]

// + nombre_completo

Persona (almacén)

• Consultar Citas:

- Entrada tiene el flujo de datos de la operación consulta cita (fecha de la cita); y el almacén Cita.

- Proceso tiene la actividad de ObtenerCitas, que obtiene del almacén Cita todas las citas con una determinada fecha.

- Salida tiene el flujo de datos resultados de consulta de cita (“No hay citas ese día:” más la fecha, o datos de las citas) que va al proceso 4 Escribir Resultado.

Proceso 3.2: Consultar citas

Entrada:

datos_op_consulta_cita // fecha [día, mes, año]

Cita (almacén)

Proceso:

citas = ObtenerCitas(fecha, Cita)

if no hay citas

then

res_consulta_cita = "No hay citas ese día: " + fecha

Ir a Proceso 4

else

res_consulta_cita = Vacío

forall c in citas

16

res_consulta_cita = res_consulta_cita + datos de c

end forall

Ir al proceso 4 // datos de citas

endif

end proceso 3.2

Salida:

res_consulta_cita // “No hay citas ese día: ” + fecha |

Datos de las citas

Diccionario de Datos

“El Diccionario de datos describe los flujos y almacenes”

Es un listado ordenado de todos los datos que se describen en el sistema para que el usuario y el analista del software tengan una misma comprensión de los datos de entrada, salida, flujos intermedios y almacenes.

Cada dato del diccionario incorpora los siguientes campos:

Nombre Alias Uso Descripción

Nombre: Es el nombre del dato que tiene en el DFD o en los almacenes. Ej. datos_op_alta_persona, hora_inicio, etc.

Alias: En un nombre nemotécnico del datos. Ej. dap para datos_op_alta_persona, hi para hora_ inicio

Uso: Indica lo que se va a hacer con ese dato. Ej. el dato res_alta_persona es entrada del proceso 4.

Descripción: Indica la información que tiene ese dato. Ej. datos_op_alta_persona contiene el nombre, teléfono y email de la persona.

Para la descripción del dato se utiliza la siguiente notación:

= el elemento de la izquierda está compuesto de varios datos según la expresión

derecha

+ Secuencia de datos. Unión (y)

[ | ] Selección entre conjunto de datos. Disyunción (o)

{}^n Agrupación repetida n veces. Iteración

( ) Datos opcionales

*...* Delimita comentarios

Ejemplo:

A continuación se presenta una descripción de algunos datos de la agenda personal

datos = tipo_operación + datos_operación

17

tipo_operación = [ 1 *agregar_persona* | 2 *consultar_persona* | 3 *eliminar_persona*| 4 *agregar_cita*| 5 *consultar_cita*| 6 *eliminar_cita*| otro *comando_erróneo_o_desconocido* ]

datos_operación = [datos_operación_persona | datos_operación_cita]

datos_operación_persona = [datos_operación_alta_persona | datos_operación_consulta_persona | datos_operación_baja_persona]

datos_operación_alta_persona = nombre_completo + teléfono + email

datos_alta_persona = tipo_operación + datos_operación_alta_persona

Cita= {fecha + hora_inicio + hora_final + nombre_completo + lugar}n

2.2.2 Modelo de Datos

Modelo de Datos

“El Modelo de Datos desarrolla el diagrama E-R para describir los datos almacenados en el sistema y las relaciones existentes entre ellos”

El diagrama E-R es un modelo en red que consta de los siguientes elementos:

• Tipo de objeto: define un conjunto de objetos cuyos miembros individuales (instancias) se identifican de una manera única. En un tipo de objeto se indican sus atributos (propiedades) y cuál es el identificador del objeto (atributo o atributos representados con “#”). Un tipo de objeto se representa con un rectángulo dividido en dos partes: la superior lleva el nombre del tipo de objeto, y la inferior los atributos. Ej. Alumno es un tipo de objeto que tiene los atributos: número de matrícula (que es el identificador) y la dirección.

• Relación: Es una asociación entre entidades. La relación representa un conjunto de conexiones y cada instancia de la relación representa una asociación entre una ocurrencia de un objeto y una ocurrencia del otro.

En una relación se indica la cardinalidad que es el número (mínimo y máximo) de instancias con las que puede relacionarse una instancia con otras del extremo opuesto. La cardinalidad se representa por 0:1 (una instancia se relaciona con 0 o 1), 1:1 (una instancia se relaciona con sólo una), 0:N (una instancia se relaciona con 0 o varias), 1:N (una instancia se relaciona con 1 o varias), M:N (una instancia se relaciona M o N). Y el grado, que es el número de entidades que participan en la relación (la relación puede ser binaria, ternaria, n-aria)

La relación se representa con un rombo en cuyo interior viene el nombre de la relación, unido por líneas rectas con las entidades que se relaciona.

Ejemplos:

“Alumno estudia Asignatura”. Es una relación binaria, compuesta por dos tipos de objetos: Alumno y Asignatura, y la relación Estudia. La cardinalidad de Alumno con Asignatura es de 1:N (un alumno estudia 1 ó varias asignaturas), y la de Asignatura con Alumno es de 0:N (una asignatura es estudiada por o ó varios alumnos). Se representa por:

18

“Ciudad capital País”. Es una relación binaria, compuesta por dos tipos de objetos: Ciudad y País, y la relación Capital. La cardinalidad de Ciudad con País es de 0:1 (una ciudad es o no capital de un país), y la de País con Ciudad es de 1:1 (un país tiene como capital a un sola ciudad). Se representa como se indica más abajo.

“Profesor enseña Alumno Asignatura”. Es una relación ternaria, compuesta de tres tipos de objetos: Profesor, Alumno y Asignatura, y la relación de enseña. La cardinalidad de Profesor-Alumno con Asignatura es de 0:N (un profesor enseña a un alumnos 0 ó varias asignaturas), la de Profesor-Asignatura con Alumno es de 1:N (un profesor enseña una asignatura a 1 o varios alumnos), y la de Asignatura-Alumno con Profesor es de 1:N (una asignatura de un alumno es enseñada por 1 o varios profesores). Se representa como se indica más abajo.

• Indicador de supertipo: Representa jerarquías de herencia. Indica que “es una clase de”. Se representa gráficamente por un objeto colgando de él, a través de un rombo, sus diferentes alternativas de tipo de objeto. Ej. Un PC es un tipo de ordenador.

Ejemplo:

El diagrama E-R de la agenda personal está formado por tres entidades: Agenda, Persona y Cita. Agenda es un contenedor de Persona (contiene 0 ó varias personas), y de Cita (contiene 0 ó varias citas). Tanto Persona como Cita están relacionadas con una única Agenda.

Persona tiene como atributos el nombre (que es su identificador), el teléfono y el email. Cita tiene la fecha (que es identificador), la hora de inicio (que es identificador), la hora de fin y el lugar de la cita. Una cita tiene una persona citada, y una persona puede tener o ó varias citas.

NOTA: Normalmente no se define una entidad que representa a todo el programa. En el caso de la agenda tiene sentido la entidad “Agenda”, como contenedor de personas y citas.

19

2.2.3 Diagrama de Transición de Estados

Diagrama de Transición de Estados

El diagrama de transición de estados (DTE) modela el comportamiento en tiempo real del sistema y relaciona los sucesos con los estados:

• “Modela el comportamiento en tiempo real”: describe el comportamiento dinámico del sistema ante los sucesos (eventos) que se producen en el mismo.

• “Relaciona sucesos y estados”: cuando surge un suceso el sistema pasa a un nuevo estado dependiendo del estado actual y del suceso (un cambio de estado causado por un suceso se denomina transición).

El DTE es un grafo cuyos nodos son estados y cuyos arcos son transiciones etiquetadas con los nombres de los eventos y las acciones originadas por ellos.

La notación utilizada en un DTE es la siguiente:

Ejemplos:

a) DTE del juego del ajedrez. Al arrancar el juego se tiene el tablero con la posición inicial, en el que sólo pueden mover las blancas. En ese punto le toca jugar a las negras y se van turnando hasta que termina la partida. La partida termina cuando un jugador acepta un jaque mate o cuando se encuentra ahogado (es decir, que no puede moverse sin sufrir un jaque mate).

20

b) DTE de la agenda personal. Al arrancar el programa la agenda está vacía y sólo se pueden agregar personas, pasando a un estado en el que sólo tiene personas. En este punto se pueden realizar todas las tareas de persona y agregar cita. Al eliminar una persona, si se borra la última se pasa al estado de agenda vacía. Al agregar una cita se pasa al estado de agenda con personas y citas. En este estado se pueden realizar todas las tareas de persona y de cita. Al eliminar una persona se puede mantener el estado (y hay más de una persona y la persona eliminada no tiene todas las citas), pasar al estado de agenda con personas (si hay más de una persona y la persona eliminada tiene todas las citas) o bien pasar al estado de agenda vacía (si se elimina la última persona). Al eliminar una cita se puede mantener el estado (si hay más de una cita) o pasar al estado de agenda con personas (si se elimina la última cita).

2.3 Modelo de implantación del usuario

Introducción

“El Modelo de implantación del usuario modela las características del sistema adaptadas a las peculiaridades del usuario”

Son características de implementación que el usuario debe aprobar antes de que se inicie el desarrollo del sistema.

El desarrollo de este modelo consta de cuatro pasos: Establecer los límites hombre-máquina, definir la interfaz de usuario, indicar las actividades manuales adicionales que hay que realizar, y señalar las restricciones operativas del sistema.

Establecer límites hombre - máquina

“Consiste en indicar qué procesos reciben tratamiento manual y cuáles no”.

Ejemplo: En el caso de la agenda sería un proceso manual “recopilar datos de otras agendas de ese usuario y pasarlos a un documento de entrada”. O en el sistema de matriculación de un alumno serían procesos manuales “recoger la carta de pago en secretaría, ir a un banco a pagarla y entregar el resguardo correspondiente en secretaría”.

Definir la interfaz de usuario

Consiste en:

• Seleccionar los dispositivos E/S (ej. pantalla, impresora, módem)

21

• Diseñar los formularios de E/S (ej. recogida de datos y listados de salida)

• Diseño de pantallas gráficas o en modo texto: consiste en diseñar las pantallas e indicar la secuencia de aparición de las mismas; es decir, la secuencia de navegación.

Ejemplo de la agenda:

a) La interfaz de usuario en modo texto de la agenda sería la siguiente:

b) La interfaz en modo gráfico incorporaría una pantalla para la Agenda, y otra para cada una de sus opciones: Agregar persona, Consultar persona, etc. A continuación se presentan dos pantallas gráficas: Agenda, y Agregar persona.

Actividades adicionales manuales

Consiste en definir una serie de normas de verificación y salvaguarda:

• “Normas de verificación de datos de entrada y resultados”

Ejemplo: obtener un listado de la agenda y comprobar los datos de las personas y citas.

• “Normas para salvaguarda de datos”

Ejemplo de salvaguarda de datos en la aplicación Nómina: para salvaguardar los datos de la nómina de una empresa, lo normal es utilizar tres ficheros que van rotando en la salvaguarda de datos. Si el fichero maestro de la nómina de enero es el nº1, el fichero maestro de la de febrero será el nº2, y el maestro de la de marzo será el nº3. Siendo el maestro de la de abril de nuevo el nº1 (se perdería el maestro de enero), el maestro de la de mayo el nº2, etc. De esta forma, se guardan los tres últimos meses de la nómina en tres ficheros que van rotando: fichero nº1 (meses 1, 4, 7,10), fichero nº2 (meses 2, 5, 8, 11), fichero nº3 (meses 3, 6, 9, 12).

22

Restricciones operativas

Consiste en señalar una serie de restricciones operativas que son importantes para el desarrollo de la aplicación, tales como:

• “Tiempos de respuesta” (indicar qué tiempo de respuesta ha de tener la aplicación). Ej. la nómina se ha de explotar todos los meses para que el personal pueda tener sus haberes en el banco el día 1 de cada mes.

• Valorar el nº de transacciones de entrada y el tamaño para los almacenes

• Restricciones de configuración (tipo de ordenador que se va a utilizar), ambientales (humedad, temperatura), etc.

• Otras Restricciones, tales como: fiabilidad (“MTBF: meantime between faults”) para que el tiempo medio entre errores sea máximo; mantenibilidad (“MTTR: meantime to repair”) para que el tiempo medio entre que se detecta un error y se corrige sea mínimo; disponibilidad, para que MTBF/(MTBF+MTTR) sea próximo a 1; seguridad, para que exista protección ante un uso no autorizado.

Conclusiones (2. Análisis Estructurado)

- En la Metodología Estructurada orientada al flujo de datos el problema se describe mediante flujos de datos de entrada que sufren transformaciones en los procesos, produciendo como resultado unos flujos de salida.

- El ciclo de vida de un proyecto orientado al flujo de datos consta de seis etapas: Examen, Análisis Estructurado, Diseño Estructurado, Implementación Estructurada, Generación del Test de Aceptación, y Control de Calidad.

- El Examen es un estudio inicial del sistema que determina su viabilidad.

- El Análisis Estructurado desarrolla el Modelo Ambiental (que modela el exterior del sistema mediante la Declaración de Objetivos, el Diagrama de Contexto, y la Lista de Sucesos), el Modelo de Comportamiento (que modela el interior del sistema mediante el Modelo de Procesos, el Modelo de Datos y el Diagrama de Transición de Estados), y el Modelo de Implantación del Usuario.

- El Modelo de Procesos desarrolla el DFD por niveles, las Especificaciones de Proceso mediante el lenguaje de descripción de procesos y el Diccionario de Datos que describe flujos y almacenes.

- El Modelo de Datos desarrolla el Diagrama Entidad-Relación que consta de tipos de objetos y relaciones.

- El Diagrama de Transición de Estados modela el comportamiento dinámico del sistema, relacionando sucesos y estados.

- El Modelo de Implantación del Usuario modela las características peculiares del usuario, y consiste en: Establecer los límites hombre-máquina, definir la interfaz de usuario, definir las actividades adicionales manuales, y señalar las restricciones operativas del sistema.

23

3. Diseño

Introducción

El Diseño desarrolla las Especificaciones Estructuradas del sistema. En concreto, desarrolla los modelos de implantación del sistema y de programas”

Objetivos de la leccion: Diseño

El Diseño, denominado aquí Diseño Estructurado, tiene por objeto la creación de una jerarquía apropiada de módulos de programas, y de interfaces entre ellos, para implantar las especificaciones producidas en la etapa de análisis. También tiene como objetivo, transformar los modelos de datos de entidad-relación en unas estructuras de datos o de bases de datos, según proceda. Previamente, es necesario asignar las especificaciones estructuradas producidas durante el Análisis entre los diferentes procesadores que componen el sistema, así como las tareas que va a realizar cada procesador.

3.1 Modelo de implantación del sistema

Modelo de implantación del sistema

El Modelo de implantación del sistema tiene por objeto repartir el modelo de análisis entre los diferentes procesadores que participan en el sistema.

Cuando la aplicación es distribuida es normal que los DFD’s obtenidos durante el análisis se repartan entre los distintos procesadores y que en cada procesador se ejecuten tareas distintas.

3.1.1 Modelo de procesador

“El modelo procesador asigna el modelo esencial (modelo ambiental + modelo de comportamiento) entre los distintos procesadores asignados al sistema”

Ejemplo:

En la gestión de un centro docente diseminado en diferentes sedes, es normal que el tratamiento de E/S se realice en el PC de cada centro y que cada centro gestione su información y la envíe al centro principal, pero la información global y su tratamiento estarán centralizados en el centro principal.

3.1.2 Modelo de tareas

“El modelo de tareas asigna funcionalidad a las diferentes tareas de un procesador”

Ejemplo:

En el centro principal del ejemplo anterior se deberán tener procesos concurrentes de tareas que agregan datos, consultan o eliminan.

3.2 Modelo de implantación de programas

Introducción

El modelo de implantación de programas consiste en diseñar una tarea individual que permita implementar el programa informático correspondiente.

“Las acciones que incorpora son: diseñar el diagrama de estructura, refinarlo, diseñar los módulos, las bases de datos o ficheros y empaquetar el diseño”

24

Diseñar el diagrama de estructura

“Consiste en obtener el diagrama de estructura aplicando el análisis de transformaciones y de transacciones”

El Diagrama de estructura es un modelo del sistema, independiente del tiempo, que informa de la arquitectura estructural del sistema. Es un árbol formado por módulos. Su diseño se realiza de arriba - abajo y de izquierda a derecha.

Notación:

• La notación básica de un diagrama de estructura consiste en un módulo principal o coordinador (módulo padre), y una serie de módulos subordinados de proceso (módulos hijo).

• Transferencias: Es la información que fluye entre los módulos. Esta información puede ser de datos (ej. nombre, apellidos y email de una persona), de control (ej. un valor booleano que indica si hay o no más datos a leer), o híbrida.

• Tipos de procesos (control): Estos pueden ser de tres tipos: la secuencia, que indica que los módulos se ejecutan uno a continuación del otro; la iteración, que indica que los módulos se ejecutan repetidamente dependiente de una condición de terminación: y la condición, que indica que los módulos se ejecutan uno u otro dependiendo de una condición.

• Tipos de módulos (por su función): Un módulo por el tipo de función que realiza puede ser: normal, es un módulo de proceso que hay que desarrollar (ej. leer datos de un perceptor de la nómina); predefinido, es un módulo que ya está implementado en una librería (ej. la raíz cuadrada); sólo de datos, es un módulo que almacena únicamente datos (ej. un COMMON de FORTRAN); un dispositivo de E/S, es un módulo que especifica un dispositivo software de entrada/salida (ej. el manejador de una impresora lasser); un entorno operativo (ej. una base de datos, un sistema operativo).

25

• Tipos de módulos (por su comunicación): Un módulo por la forma de comunicarse con los demás puede ser: aferente (de entrada), obtiene la información de un subordinado y la pasa sin transformar o transformada al módulo superior; eferente (de salida), recibe la información de su módulo superior y la pasa sin transformar o transformada al subordinado; de transformación, recibe la información de su módulo superior y se la devuelve transformada; coordinador, coordina y gestiona el trabajo de los otros módulos. Está en niveles superiores de la jerarquía.

Ejemplo:

A continuación presentamos el DFD y el diagrama de estructura de un programa que “ordena una serie de números que lee desde un dispositivo primario”.

El DFD tiene tres procesos básicos: Leer Datos, que lee los números; Ordenar datos, que los ordena; y Escribir resultado, que visualiza los números ordenados.

El Diagrama de estructura tiene cuatro módulos: un módulo coordinador Ordenar, que solicita que se lean los datos, que se ordenen y que se escriban; un módulo aferente Leer datos, que pasa a Ordenar cada dato leído (elementos) y al finalizar la lectura envía el número de datos leídos (nº els); un módulo de transformación Ordenar datos, que recibe de Ordenar los datos leídos y el número de datos leídos, y devuelve los datos ordenados (d. ord); un módulo eferente Escribir resultado, que recibe los datos ordenados y el número de datos leídos y los visualiza.

Hay que tener presente que cada proceso básico del DFD se transforma en un módulo hoja del diagrama de estructura.

A continuación se presentan el DFD y el diagrama de estructura del programa ordenar números.

Análisis de transformaciones

El problema que presenta la metodología orientada al flujo de datos es que el análisis produce un diagrama en red de procesos y flujos de datos, mientras que el diseño utiliza una estructura en árbol como es el diagrama de estructura. El paso del DFD al diagrama de estructura exige una estrategia de diseño, siendo la más paradigmática el análisis de transformaciones.

26

El análisis de transformaciones es una estrategia de "arriba abajo", modular, y basada en la morfología centrada en transformaciones de Constantine, consistente en definir estructuras equilibradas entre las ramas aferentes (que obtienen información y la pasan al nivel superior), y las eferentes, (que toman información de un nivel superior y la pasan al inferior).

La morfología centrada en transformaciones produce diagramas de estructura equilibrados, modulares y bien dimensionados.

Para realizar un análisis de transformaciones y obtener un diagrama de estructura equilibrado se ejecuta la siguiente estrategia que consta de cuatro etapas:

1. Tratar el problema como un único DFD hasta obtener todos los procesos finales.

2. Identificar las ramas aferentes (entrada) y eferentes (salida). Son ramas aferentes aquellas que están formadas por procesos aferentes que finalizan en un proceso de transformación. Y son ramas eferentes aquellas que están formadas por procesos eferentes que finalizan en un sumidero.

3. Factorización del 1er nivel: se define un módulo principal que controla y coordina al resto de los módulos. Un módulo por cada rama aferente. Un módulo por cada rama eferente. Un módulo para cada módulo de transformación.

4. Factorizar las ramas aferentes, eferentes y de transformación obtenidas en el punto 3, y así sucesivamente.

Ejemplo:

Si aplicamos esta estrategia al problema de “ordenar números”, las etapas serían las siguientes:

1. El DFD sería el obtenido anteriormente con sus tres procesos: Leer Datos, Ordenar datos, y Escribir resultado.

2. Habría una rama aferente que incluiría el proceso Leer Datos, una rama eferente que incluiría el proceso Escribir resultado, y una de transformación que incluiría el proceso Ordenar datos.

3. Al factorizar el 1º nivel, tendríamos un módulo coordinador Ordenar, el módulo Leer Datos como rama aferente, el módulo Escribir resultado para la eferente, y el módulo Ordenar datos para la de transformación.

27

4. Como las ramas aferente, eferente, y de transformación están constituidas por un único proceso, no procede una posterior factorización, por lo que pasaríamos a indicar sobre el diagrama resultante los flujos existentes entre los módulos.

El resultado sería el diagrama de estructura visto anteriormente:

Análisis de transacciones

Fue planteado por Vincet y sus colaboradores de la Bell Telephone de Canadá como una ampliación del análisis de transformaciones.

Se aplica cuando una "burbuja" del DFD divide el flujo de entrada en varios flujos de salida, construyéndose un sistema alrededor de esa transacción. En la figura adjunta, el proceso OA divide el flujo de entrada en cuatro procesos de salida, por lo que procede diseñar estos procesos mediante un análisis de transacciones.

El análisis de transacciones tiene por objeto transformar esa parte del DFD que divide el flujo entrante, en un Centro de Transacciones. El Centro de Transacciones ha de realizar las siguientes funciones: obtener la transacción, analizarla para determinar su tipo, despachar cada tipo y completar su proceso.

El Centro de Transacciones se diseña como un árbol con un módulo cabeza “transacción” que coordina la transacción, del cual dependen: un módulo que “obtiene y analiza” la transacción y otro que “despacha” la transacción. El módulo que “obtiene y analiza” se puede descomponer, atendiendo a su complejidad, en dos módulos: uno que “obtiene la transacción” y otro que la “analiza”. El módulo que “despacha” define un proceso alternativo con varios módulos subordinados cada uno de los cuales trata una de las variantes de esa transacción (ej. en el caso de una nómina, las variantes que trata el módulo “despacha” serían: tratar alta, tratar alteración, tratar baja, tratar consulta):

28

Para realizar un análisis de transformaciones complementado con un análisis de transacciones, con el fin de obtener un diagrama de estructura equilibrado, se ejecuta la siguiente estrategia de diseño que consta de cinco etapas:

1. Tratar el problema como un único DFD hasta obtener todos los procesos finales.

2. Identificar las ramas aferentes (entrada) y eferentes (salida). Son ramas aferentes aquellas que están formadas por procesos aferentes que finalizan en un proceso de transformación. Y son ramas eferentes aquellas que están formadas por procesos eferentes que finalizan en un sumidero.

3. Factorización del 1er nivel: se define un módulo principal que controla y coordina al resto de los módulos. Un módulo por cada rama aferente. Un módulo por cada rama eferente. Un módulo para cada módulo de transformación.

4. Si se detectan centros de transacciones, definir cada centro de transacciones conforme al formato anterior.

5. Factorizar las ramas aferentes, eferentes y de transformación obtenidas en el punto 3, y así sucesivamente.

Ejemplo:

Obtener el diagrama de estructura de un programa que “actualiza un fichero maestro de una empresa que tiene altas, alteraciones y bajas, a partir de datos del personal, previamente ordenados, que se introducen por la consola”.

Para ello vamos a aplicar las diferentes etapas del análisis de transformaciones, complementado si procede con el análisis de transacciones.

1. Diseñar el DFD con procesos finales.

• Diagrama de Contexto: El diagrama de contexto consiste en el proceso “Actualizar FM”, la unidad externa “Usuario” que introduce los datos y recibe los resultados, y los ficheros maestros antiguo “FMA” (el que se quiere actualizar) y nuevo “FMN” (el actualizado)

29

• DFD0: El DFD0 está formado por cinco procesos: “Leer Datos”, que lee los datos de alta, alteración y baja; “Generar Movimiento”, que transforma los datos leídos en un movimiento de alta, alteración o baja; “Leer FMA”, que lee registros de personal del fichero maestro que se va a actualizar; “Actualizar”, que actualiza un registro leído del fichero maestro FMA con un moviendo de alta, alteración o baja; y “Grabar en FMN”, que graba en el fichero maestro nuevo el registro actualizado.

Nota: dato de entrada es información no analizada, ni clasificada. Movimiento es información de entrada ya clasificada como alta, alteración o baja. Registro de personal es información completa de un empleado (ej. NIF, datos personales, datos laborales, datos económicos, etc.)

• DFD2: Los procesos 1 (Leer Datos) , 3 (Leer FMA), 4 (Actualizar), y 5 (Grabar en FMN) son procesos primitivos que no precisan una mayor subdivisión; mientras que el proceso 2 (Generar Movimiento) necesita ser divido en tres procesos: Generar Alta, Generar Alteración y Generar Baja.

Atendiendo al DFD de procesos finales, el sistema de actualización del fichero maestro de la empresa sería pues el siguiente: “Se lee un dato desde la entrada y este dato se transforma en un movimiento de alta, alteración o baja. Seguidamente se lee un registro de personal del FMA, si el indicativo del registro (ej. su NIF), no coincide con el del movimiento leído, y el indicativo del registro es menor se graba directamente el registro leído del FMA en el FMN; pero si el indicativo del movimiento es menor se procede como sigue: si es una alta se graba en el FMN, si es una alteración o una baja se rechaza como errónea.

Si el indicativo del registro y del movimiento coinciden entonces los trata el proceso “Actualizar” de la siguiente forma: si el movimiento es una alta se rechaza por “registro ya existente”, si es una alteración se modifican los datos del registro del FMA con los datos del movimiento y el nuevo registro se pasa para su grabación al FMN, y si es una baja no se graba el registro del FMA en el FMN.

30

2. Identificar las ramas aferentes (entrada) y eferentes (salida).

Al analizar el DFD con procesos finales anteriormente desarrollado, vemos que hay una rama aferente formada por los procesos “Leer Datos” y “Generar Movimiento”; otra rama aferente formada por el proceso “Leer FMA”; una rama eferente formada por “Grabar FMN”; y una rama de transformación formada por el proceso “Actualizar”.

3. Factorización del 1er nivel.

Para factorizar el 1º nivel ponemos un módulo coordinador “Actualizar FM”, y dependientes de él cuatro módulos: dos aferentes “Tratar datos entrada” y “Leer FMA” (uno por cada rama aferente), uno de transformación “Actualizar”, y uno eferente “Grabar FMN”.

4. Diseñar Centros de Transacciones, si los hubiere.

Al analizar el DFD con procesos finales de la etapa 1, vemos que el proceso “Leer Datos” divide el flujo de datos entrante en tres flujos salientes: datos leídos de alta, alteración y baja; por lo tanto, aquí existe un centro de transacciones que hay que diseñar siguiendo el formato del análisis de transacciones.

El módulo “Tratar datos entrada” es el módulo coordinador del centro de la transacción. Existirá un módulo “Leer datos”, que obtiene y analiza la transacción, y envía los datos leídos al módulo coordinador. Existirá un módulo “Generar transacción”, que recibe los datos leídos del módulo coordinador y los despacha (envía) a los módulos “Generar alta”, “Generar alteración”, o “Generar baja”, dependiendo del tipo de movimiento leído.

El resultado de este proceso es el diagrama de estructura siguiente:

31

Leyenda:

eod: fin de datos; eof: fin de registros; err: error datos; mov: movimiento; da: datos alta; dal: datos alteración; db: datos baja; reg: registro; reg act: registro actualizado; reg FMA: registro del fichero maestro antiguo.

5. Factorizar las ramas aferentes, eferentes y de transformación obtenidas en el punto 3.

El resto de las ramas corresponden a procesos primitivos, por lo que no se necesita una mayor factorización. Siendo el diagrama anterior el diagrama de estructura final.

Interesa recalcar que cada proceso final se ha de corresponder con un módulo del diagrama de estructura. En el ejemplo de actualizar el fichero maestro vemos que los procesos finales del DFD (“Leer Datos”, “Generar Alta”, “Generar Alteración”, “Generar Baja”, “Leer FMA”, “Actualizar” y “Grabar FMN”) tienen su correspondiente módulo en el diagrama de estructura.

Ejemplo: Obtener el diagrama de estructura de la agenda personal

Para diseñar el diagrama de estructura de la agenda personal vamos a aplicar el análisis de transformaciones y el de transformaciones, si procede.

1. Diseñar el DFD con procesos finales.

El DFD con procesos finales de la agenda es el siguiente (ya visto anteriormente):

32

2. Identificar las ramas aferentes (entrada) y eferentes (salida).

En el DFD final vemos que hay una rama aferente (proceso Leer Datos), una eferente (proceso Escribir Resultado), y seis de transformación (Agregar, Consultar y Eliminar Persona o Cita).

3. Factorización del 1er nivel.

Al realizar la primera factorización obtenemos el módulo coordinador “Agenda”; el módulo aferente “Leer Datos”, los seis módulos de transformación: “Agregar persona”, ..., “Eliminar cita”, y el módulo eferente “Escribir resultado”.

“Agenda” es un proceso iterativo (se va leyendo dato a dato y se trata), y condicional porque de cada dato leído sólo se ejecuta uno de los módulos de transformación.

4. Diseñar Centros de Transacciones, si los hubiere.

Al analizar el DFD con procesos finales de la etapa 1, vemos que el proceso “Leer Datos” divide el flujo de datos entrante en seis flujos salientes; por lo tanto, aquí existe un centro de transacciones a diseñar siguiendo el formato del análisis de transacciones.

El módulo “Agenda” es el módulo coordinador del centro de la transacción. Existirá un módulo “Leer datos”, que obtiene y analiza los datos, y los envía a “Agenda”. Existirá un módulo “Tratar Personas y Citas”, que recibirá los datos leídos de “Agenda” y los despacha (envía) a los módulos “Agregar Persona”, “Consultar Persona”, “Eliminar Persona”, “Agregar Cita”, “Consultar Cita”, “Eliminar Cita”, dependiendo del tipo de movimiento leído.

El resultado de este proceso es el diagrama de estructura siguiente:

33

Leyenda:

to: tipo operación; do: datos operación; doap, docp, dobp, doac, docc, dobc: datos operación alta, consulta, baja de persona o cita; rsap, rsbp, rsac, rsbc: resultados de alta, baja de persona o cita; retap, retcp, retbp, retac, retcc, retbc: datos de control de retorno de alta, consulta, baja de persona o cita; agenda: datos de la agenda; resultado: resultado de tratar persona y cita; retorno: datos de control de retorno de persona y cita; fin: control de fin de datos.

5. Factorizar las ramas aferentes, eferentes y de transformación obtenidas en el punto 3.

El resto de las ramas corresponden a procesos primitivos, por lo que no se necesita una mayor factorización. Siendo el diagrama anterior el diagrama de estructura final.

Refinarlo

“El Diagrama de Estructura obtenido mediante los análisis de transformaciones y transacciones suele ser necesario refinarlo utilizando para ello heurísticas de diseño”

Las heurísticas de diseño son reglas de buena lógica que la experiencia aconseja su aplicación para obtener un diagrama de estructura con una implementación más adecuada y un mantenimiento menos costoso. Estas heurísticas son las siguientes:

1. Bajo acoplamiento entre los módulos:

Se trata de que los módulos obtenidos en el diagrama de estructura estén poco acoplados. Se dice que un módulo está acoplado con otro cuando al modificarlo hay que tener en cuenta al otro módulo.

El acoplamiento puede existir por:

1.1 El tipo de conexión entre módulo.

La conexión que puede existir entre dos módulos es (de peor a mejor):

a) Entorno común: ocurre cuando los módulos comparten variables globales (ej. un COMMON en FORTRAN)

b) Contenido: ocurre cuando un módulo está contenido en el otro; es decir, existe código anidado.

c) Control: ocurre cuando al llamar un módulo a otro uno de los argumentos es una variable de control (ej. Leerdatos (bool eod, char* nom, char* apellidos, char* email); // eod indica el fin de los datos)

d) Datos: ocurre cuando al llamar un módulo a otro sólo pasa argumentos con datos. Esta es la forma normal de llamar a un módulo y produce el mínimo acoplamiento.

1.2 Complejidad de la interfaz

Se dice que dos módulos están muy acoplados cuando al llamarse uno a otro el número de argumentos que participan es alto y/o los argumentos son complejos (ej. float arearectangulo(float x0, float y0, float x1, float y1); es una interfaz más compleja que float arearectangulo(float ladoa, float ladob);)

2. Alta cohesión de cada módulo.

Se trata de que cada módulo presente una fuerte relación entre sus elementos. La cohesión (de peor a mejor) puede ser:

a) Coincidental: ocurre cuando se agrupan en un módulo elementos sin ninguna relación (ej. cuando existe un conjunto de sentencias que se llaman reiteradamente y se forma un módulo para ellas). Su valor es 0.

34

b) Lógica: ocurre cuando en un módulo se agrupan funciones similares (ej. módulo input que realiza todas las lecturas de diferente tipo, o módulo output que realiza todas las salidas de diferente tipo). Su valor es 1.

c) Temporal: ocurre cuando un módulo agrupa varias funciones distintas que se ejecutan en un mismo periodo de tiempo. (ej. un módulo de inicialización que abre ficheros, pone contadores a cero, lee datos de control, etc; o un módulo de finalización que realice las funciones de cierre). Su valor es 3.

d) Procedural: ocurre cuando un módulo agrupa elementos que forman parte de un algoritmo: por ejemplo, las dos ramas de un if-then-else (ej. tener un único módulo en la agenda que trate personas y citas). Su valor es 5.

e) Comunicacional: ocurre cuando se define un módulo con varios procesos y todos ellos tratan el mismo flujo de datos de entrada y/o salida (ej. un módulo que incorpora los procesos agregar personas, consultar personas, y eliminar personas). Su valor es 7.

f) Secuencial: ocurre cuando se define un módulo que incorpora varios procesos en serie con acciones consecutivas (ej. tener un módulo que lea números, los ordene ascendentemente, y los imprima ordenados). Su valor es 9.

g) Funcional: ocurre cuando un módulo realiza una única función (ej. los módulos Agregar Persona, Consultar Persona, ect. son funcionales porque realizan una función). Su valor es 10.

El nivel mínimo de cohesión que debe tener un módulo es el procedural cuyo valor es 5.

3. Anchura de control (“fan_out”) apropiada.

Se denomina anchura de control de un módulo al número de módulos que dependen de él. La regla general es mantener el fan-out en un valor de 5±2. Sin embargo, en programas pequeños lo aconsejable es que la anchura sea de 3 ó 4 módulos (ej. el módulo Agenda tiene una anchura de control de 3).

4. Maximizar el “fan-in”

Se denomina “fan-in” de un módulo al número de módulos que le llaman. Interesa que el número de módulos que llaman a un módulo sea el mayor posible, siempre que se respeten las heurísticas de diseño (ej. en la agenda todos los módulos tienen un “fan-in” de 1).

5. El ámbito del efecto ha de estar incluido en el ámbito de control.

Esta heurística se refiere a que cuando se produce un evento en un módulo, la acción de este evento no debe repercutir en módulos que no están bajo su control. (ej. Si en el módulo Leer Datos de la agenda se produce un error, éste error no debe afectar al módulo Escribir Resultado que no está bajo su control).

6. Dimensión apropiada de cada módulo

Se aconseja que el número de sentencias fuente de un módulo no sea superior a 100.

Ejemplo: Refinado de la agenda

• Disminuir el “fan-out”

Al analizar el diagrama de estructura de la agenda vemos que el módulo Tratar Personas y Citas tiene un fan-out de 6 que hay que reducir. Además, este módulo tiene cohesión procedural. Por todo lo cual, dividimos este módulo en dos: Tratar Personas dirigido a personas, y Tratar Citas que se encargará de las citas.

35

• Aumentar el “fan-in”

Al analizar el diagrama de estructura anterior, vemos que la información que generan todos los módulos tiene que retornar al módulo Agenda para que ésta la pase al módulo Escribir resultado. Todo ello origina un trasiego de información que genera una gran complejidad en el diagrama de estructura. Ello se resuelve si aumentamos el “fan-in” del módulo Escribir resultado, de forma que todos los módulos pasen sus resultados directamente a él.

• Reducir la cohesión lógica

El diagrama de estructura resultante presenta al módulo Escribir resultado con una alta cohesión lógica y una gran complejidad. Como la información de salida del resto de los módulos hacia este módulo no es compleja, es información simple. Lo mejor es que cada módulo escriba sus propios resultados. Con ello eliminamos este módulo, aunque disminuimos la cohesión funcional del resto de los módulos.

36

• Reducir el acoplamiento por complejidad de la interfaz

Al analizar el diagrama de estructura anterior, vemos que el módulo Leer datos tiene cohesión lógica y presenta una interfaz compleja con el módulo Agenda, dado que el número de argumentos que tiene que pasar a Agenda es distinto según sea una persona o una cita, y según sea la operación a realizar. Por ello, y dado que los datos se leen desde el teclado y su tratamiento es sencillo, resulta apropiado eliminar este módulo e incorporar sus acciones en el módulo Agenda. Ciertamente, con esta acción el módulo Agenda tiene una funcionalidad más compleja, pero merece la pena.

Leyenda de los retornos de los módulos en el diagrama de estructura

retap = [Bien | ErrExisteCita | ErrMem]

retcp = [Bien | ErrNoCitas | ErrNoExisteCita]

retep = [Bien | ErrNoCitas | ErrNoExisteCita]

retac = [Bien | ErrNoExisteCita | ErrExisteCita | ErrMem]

retcc = [Bien | ErrNoCitas | ErrNoExisteCita]

retec = [Bien | ErrNoCitas | ErrNoExisteCita]

37

Diseñar los módulos

“Consiste en detallar el comportamiento procedimental de cada uno de los módulos identificados en el diagrama de estructura (Diseño detallado procedimental)”.

La descripción procedimental de un módulo se puede realizar de forma textual utilizando un pseudocódigo estructurado (ej. el lenguaje de descripción de procesos LDP, descrito durante el análisis) o de forma gráfica utilizando los diagramas estructurados arborescentes o los de Chapín” (denominados también de N-S).

Notación gráfica de los diagramas arborescentes y de los de Chapín:

a) Secuencia:

En la representación arborescente es un árbol cuyo nodo raíz lleva la palabra “BLOCK”, y los nodos hoja son los diferentes tratamientos que forman la secuencia.

En la representación de Chapín es una pila de rectángulos, cada uno de los cuales es un tratamiento de la secuencia.

b) Condición:

• if p then f else g. En la representación arborescente es un árbol cuya raíz lleva el literal “ifthenelse”, y los nodos hoja son la condición p, y los tratamientos f y g. En la representación de Chapín es un rectángulo que lleva en la parte superior el predicado p y los valores true y false, y en la parte inferior el tratamiento f de true y el g de false.

• if p then f. En la representación arborescente es un árbol cuya raíz lleva el literal “ifthen”, y los nodos hoja son la condición p, y el tratamiento f. En la representación de Chapín es un rectángulo que lleva en la parte superior el predicado p y los valores true y false, y en la parte inferior sólo el tratamiento f de true.

• case p =a fa, =b fb, … En la representación arborescente es un árbol cuya raíz lleva el literal “caseof”, y los nodos hoja son el predicado p, y los diferentes tratamientos fa, fb, ..., fz. En la representación de Chapín es un rectángulo que lleva en la parte superior el predicado p y los diferentes valores a,b,..,z del case,y en la parte inferior los correspondientes tratamientos fa,fb,... fz.

38

c) Iteración:

• while p do f. En la representación arborescente es un árbol cuya raíz lleva el literal “dowhile”, y los nodos hoja son la condición p y el tratamiento f. En la representación de Chapín son dos rectángulos anidados, el exterior lleva en la parte superior el predicado p y el interior contiene el tratamiento f.

• repeat f until p. En la representación arborescente es un árbol cuya raíz lleva el literal “dountil”, y los nodos hoja son el tratamiento f y la condición p. En la representación de Chapín son dos rectángulos anidados, el exterior lleva en la parte inferior el predicado p y el interior contiene el tratamiento f.

• for vc from vi to vf by k. En la representación arborescente es un árbol cuya raíz lleva el literal “dofor”, y los nodos hoja son el predicado vc=vi,k,vf, y el tratamiento f . En la representación de Chapín son dos rectángulos anidados, el exterior lleva en la parte superior el predicado vc=vi,k,vf y el interior contiene el tratamiento f.

Ejemplo:

Diseñar el módulo “ordenar datos” del problema ordenar visto anteriormente.

Si la ordenación se realiza ascendentemente utilizando el algoritmo de selección directa, el resultado sería:

a) En la representación arborescente:

39

b) En la representación de Chapín:

c) Utilizando el pseudocódigo LDP:

void OrdenAscendente (a[], n)

for i from 0 to n-2 by 1

k=i

tem = a[i]

for j from i+1 to n-1 by 1

if a[j] < tem

then

k=j

tem = a[j]

endif

endfor

a[k] = a[i]

a[i] = tem

endfor

Diseño Procedimental de la agenda personal: Módulos Agenda y Agregar Cita

• Módulo Agenda.

El diseño procedimental del módulo Agenda se realiza a partir del diagrama de estructura, teniendo en cuenta que además de ser el módulo principal incorpora la función de lectura de los datos.

El módulo ha de pedir el tipo de operación y según sea un 1, 2, …, 6, ha de pedir datos de ese tipo de operación y llamar a los módulos TratarPersonao TratarCita. En el caso de que el tipo de operación no sea del 1 al 6, señalará “Comando desconocido”. Agenda también ha de tratar el caso de que al realizar una alta de persona o de cita no haya memoria suficiente produciéndose un error de memoria (erm), mostrando en ese caso un mensaje de error al usuario y volviendo a pedir un nuevo tipo de operación (dado que es posible que no se puedan añadir elementos pero sí consultarlos o eliminarlos).

40

• Módulo AgregarCita:

El diseño procedimental del módulo AgregarCita se realiza a partir del diagrama de estructura, teniendo en cuenta que ha de realizar los siguientes tratamientos: ver si la agenda está vacía de personas, ver si existe la persona citada y ver si existe ya esa cita. En el caso de que no se produzcan estos hechos, deberá crear una nueva cita y meterla en al agenda. Si no existe memoria suficiente para crar la cita devolverá un mensaje de error (erm). El módulo recibirá como argumentos de entrada la agenda y los datos de alta de la cita; y devolverá la agenda con la nueva cita ya incorporada.

41

Diseñar las Bases de Datos o ficheros

Consiste en diseñar físicamente las bases de datos y los ficheros correspondientes a los almacenes de los DFD. Para ello, se parte del modelo de datos de análisis.

Ejemplo: Estructura de datos de la agenda personal

La agenda personal la vamos a diseñar físicamente en la memoria de la computadora mediante una estructura de listas enlazadas. Si analizamos el Diagrama Entidad-Relación de la agenda, vemos que existen tres tipos de datos:

• Tipo Agenda (TAgenda), que lo representamos mediante una estructura lineal con dos punteros: uno a tipo de personas, y otro a tipo de citas.

• Tipo Persona (TPersona), que lo representamos mediante una lista enlazada cuyo contenido son: nombre de la persona, teléfono, email, y un puntero al siguiente elemento de la lista.

• Tipo Cita (TCita), que lo representamos mediante una lista enlazada cuyo contenido son: fecha de la cita, hora de inicio, hora de fin, un puntero a la persona citada, el lugar, y un puntero al siguiente elemento de la lista.

Empaquetar el diseño

“Consiste en descomponer el diagrama de estructura en módulos físicos ejecutables”

Ejemplo: Sistema Retributivo

• El DFD de un Sistema Retributivo se suele plantear con tres proceso fundamentales:

1. Actualizar FM: consiste en actualizar el fichero maestro del mes de pago de la nómina (FMN), a partir del fichero maestro del mes anterior (FMA), y de los movimientos (altas, alteraciones y bajas) producidas durante el mes (FMOV).

2. Calcular nóminas: consiste en calcular la nómina de cada empleado de la empresa, a partir de los datos del empleado existentes en el FMN. Como resultado se obtienen unos datos calculados de nómina (importe total, descuentos, importe neto, etc.) que, junto con los datos del FMN, se almacenan en un fichero denominado “F. Calculado”.

3. Listar: consiste en imprimir todos los documentos de pago de cada perceptor, tales como: hoja de retribuciones del empleado, transferencia bancaria, TC1, TC2, etc. Para ello, se lee cada registro del “F. Calculado” y se obtienen los documentos anteriores para cada perceptor.

42

• El diagrama de estructura está formado por un módulo principal Sistema Retributivo, y tres módulos coordinadores subordinados: Actualización (que coordina a los módulos Leer Fichero de Movimientos, Leer Fichero Maestro Antiguo, Actualizar y Grabar Fichero Maestro Nuevo), Cálculo (que coordina a los módulos Leer Fichero Maestro Nuevo, Calcular Nómina y Grabar Fichero Calculado), y Listado (que coordina a los módulos Leer Fichero Calculado, e Imprimir Resultados Nómina).

El funcionamiento del diagrama de estructura es el siguiente:

El módulo Sistema Retributivo pide a Actualización que actualice el FMA. A tal efecto, Actualización pide al módulo Leer Fichero de Movimientos que le proporcione un movimiento de un perceptor, y al módulo Leer Fichero Maestro Antiguo le pide el registro con los datos de ese perceptor. Esta información se la entrega al módulo Actualizar, que retorna un registro ya actualizado. Este registro pasa al módulo Grabar Fichero Maestro Nuevo para que lo grabe en el FMN. Este proceso se repite hasta que todos los registros del FMA han sido leídos y actualizados (cuando procede) con los movimientos del fichero de movimientos, pasando seguidamente al FMN.

Seguidamente el módulo Sistema Retributivo pide al módulo Cálculo que calcule la nómina de cada perceptor. A tal efecto, Cálculo pide al módulo Leer Fichero Maestro Nuevo que le proporcione un registro de un perceptor. Este registro se lo pasa al módulo Calcular para que calcule todos los datos de nómina de ese perceptor. Seguidamente, el módulo Cálculo envía el registro, más los datos calculados de nómina, al módulo Grabar Fichero Calculado para que los grabe en el “F. Calculado”. Este proceso se repite hasta que todos los registros del FMN han sido leídos, calculados y grabados en el “F. Calculado”.

Por último, el módulo Sistema Retributivo pide al módulo Listado que imprima todos los documentos de nómina de cada perceptor. A tal efecto, Listado pide al módulo Leer Fichero Calculado que le proporcione un registro calculado de un perceptor. Este registro se lo pasa al módulo Imprimir Resultado Nómina para que liste todos los documentos de nómina de ese perceptor. Este proceso se repite hasta que todos los registros del “F. Calculado” han sido leídos, tratados y listados los documentos correspondientes.

Como se desprende de todo lo dicho, el diagrama de estructura no se puede ejecutar en un solo paso, ya que se precisa hacer comprobaciones de que todo va bien después de la Actualización (comprobando una muestra del FMN), después del Cálculo (comprobando una muestra del “F. Calculado”) y después del Listado (comprobando una muestra de los documentos de pago de la nómina). Para lo cual, se descompone el diagrama de estructura en tres módulos ejecutables: cadena de Actualización, cadena de Cálculo y cadena de Listado.

La figura siguiente describe gráficamente todos estos procesos.

43

Conclusiones (3. Diseño)

- El Diseño estructurado desarrolla los modelos de implantación del sistema y de programas.

- El modelo de implantación del sistema desarrolla el modelo de procesador, que asigna el modelo esencial entre los distintos procesadores, y el modelo de tareas, que asigna funcionalidad a las diferentes tareas de un procesador.

- El modelo de implantación de programas diseña una tarea individual (que se implementa en un programa informático), mediante las siguientes acciones: diseñar el diagrama de estructura, refinarlo, diseñar los módulos, las bases de datos o ficheros, y empaquetar el diseño.

- El diagrama de estructura describe la arquitectura estructural del sistema. Es un árbol formado por un módulo principal o coordinador, y una serie de módulos subordinados de proceso. Para su diseño se aplican los análisis de transformaciones y de transacciones.

- El análisis de transformaciones es una estrategia de diseño consistente en definir estructuras modulares y equilibradas entre las ramas aferentes (que obtienen información y la pasan al nivel superior), y las eferentes (que toman información de un nivel superior y la pasan al inferior). Produce un diagrama de estructura equilibrado, modular y bien dimensionado.

- El análisis de transacciones es una estrategia de diseño complementaria al análisis de transformaciones, y se aplica cuando un proceso del DFD divide el flujo de entrada en varios flujos de salida. Su objetivo es transformar esa parte del DFD en un centro de transacciones con las siguientes funciones: obtener la transacción, analizarla para determinar su tipo, y despacharla según su tipo.

- Para realizar un análisis de transformaciones, complementado con uno de transacciones, se ejecutan las siguientes etapas: Tratar el problema como un único DFD, Identificar las ramas aferentes y eferentes, Factorizar el 1º nivel, Definir cada centro de transacciones, Factorizar el resto de los niveles.

- Para refinar el diagrama de estructura hay que aplicar heurísticas de diseño, tales como: bajo acoplamiento entre los módulos, alta cohesión de cada módulo, una anchura de control (“fan-out”) apropiada, maximizar el “fan-in”, tener un ámbito de efecto menor que el de control, y una dimensión apropiada de los módulos.

- El acoplamiento entre módulos por tipo de comunicación es, de menor a mayor: de entorno común, de contenido, de control, de datos. Por otro lado el acoplamiento se ve afectado por la complejidad de la interfaz entre los módulos.

- La cohesión de un módulo es de menor a mayor: coincidental, lógica, temporal, procedural, comunicacional, secuencial y funcional.

- Diseñar un módulo consiste en detallar su comportamiento procedimental, describiéndolo de forma textual mediante pseudocódigo estructurado, o de forma gráfica utilizando los diagramas estructurados arborescentes o los de Chapín.

- Diseñar las Bases de Datos o ficheros, consiste en diseñar físicamente las estructuras de datos, y cada uno de los datos, correspondientes a los almacenes definidos en el modelo de datos del análisis.

- Empaquetar el diseño consiste en descomponer el diagrama de estructura en módulos físicos ejecutables. Por ejemplo, la agenda personal es un único módulo ejecutable porque para cada dato de entrada se recorre todo el diagrama de estructura en su tratamiento, mientras que para el sistema retributivo son necesarios tres módulos ejecutables: uno para la actualización, otro para el cálculo, y otro para el listado de los resultados.

44

4. Implementación

Introducción

El proceso de implementación consiste en codificar cada uno de los módulos obtenidos en el diagrama de estructura y realizar las pruebas necesarias para demostrar que el sistema software funciona correctamente. Ello comporta las siguientes acciones:

• “Seleccionar el módulo a implementar”, atendiendo a la prioridad o interés del usuario por desarrollar alguna parte del sistema.

• “Codificarlo”, incluyendo las pruebas de unidad.

• “Integrarlo en el sistema”, realizando las pruebas de integración.

Objetivos de la lección: Implementación

La Implementación tiene como objetivo la codificación de cada módulo y su integración en un esqueleto progresivamente más completo produciendo como resultado el sistema final. En esta metodología la programación será estructurada y la integración mixta. La Implementación incorpora también como tareas las pruebas de cada módulo, y del sistema integrado.

Estrategias estándar para la construcción de un programa (y para la selección de los módulos)

Estas estrategias se aplican cuando el cliente no propone una implementación determinada para definir sus prioridades.

1. Implementación “top-down” (descendente)

En el caso de una implementación de “arriba abajo” o descendente, se sigue la siguiente estrategia:

• Se empieza la codificación y pruebas por los módulos superiores del diagrama de estructura, continuando por los módulos de los siguientes niveles inferiores.

• Se avanza por niveles: se programan todos los módulos de un nivel antes de avanzar al siguiente (recorrido en anchura primero).

• Para las pruebas de unidad e integración se tienen que codificar unos módulos falsos que simulan los inferiores. Ello es debido a que todavía no se han codificado los módulos inferiores por lo que hay que simular su funcionalidad. Estos módulos ficticios se denominan stubs.

Esta estrategia de implementación produce un sistema integral de forma progresiva e incremental.

Ejemplo: Implementar “top-down” el diagrama de estructura adjunto.

45

El proceso de implementación sería el siguiente:

1.Codificar el módulo A (main) y diseñar dos stubs: uno del módulo B y otro del C para probar A.

2.Codificar el módulo B y diseñar dos stubs: uno del módulo D y otro del E para probar B. Integrar B con el A.

3.Codificar el módulo C y diseñar dos stubs: uno del módulo E (distinto del anterior, ya que ahora la llamada se realiza desde A) y otro del F para probar C. Integrar C en la estructura anterior.

4.Codificar y probar el módulo D e integrarlo en la estructura anterior. No hay que desarrollar nuevos stubs.

5.Codificar y probar el módulo E e integrarlo en la estructura anterior. Codificar y probar el módulo F e integrarlo en la estructura anterior.

La tabla adjunta describe con detalle el proceso de implementación anterior:

• Codificar y probar: indica el módulo que se codifica y luego se prueba.

• Con módulos: indica los módulos ya existentes que se utilizan para probar el actual (pueden no ser todos los módulos existentes)

• Stubs: indica aquellos stubs que hay que diseñar y que se utilizan para probar el módulo actual. Cuando se definen dos stubs para el mismo módulo, por ejemplo: E y E´, quiere decir que el stub E simula la funcionalidad necesaria para probar el módulo B. Y el stub E´ simula la funcionalidad necesaria para probar el módulo C.

En el ejemplo anterior, con implementación “top-down”, hay que desarrollar 6 “stubs”

2. Implementación “bottom-up” (ascendente)

En el caso de una implementación de “abajo a arriba” o ascendente, se sigue la siguiente estrategia:

• Se empieza la codificación y pruebas por los módulos inferiores del diagrama de estructura, continuando por los módulos de los siguientes niveles superiores. También se progresa por niveles: se programan y pruebas todos los módulos de un nivel antes de subir al nivel superior.

• Para las pruebas de unidad e integración se tienen que codificar unos módulos ficticios, llamados drivers (monitores de prueba), que coordinan la ejecución de los de abajo. Ello es debido a que todavía no se han codificado los módulos superiores por lo que hay que simular su funcionalidad.

Ejemplo: Implementar “bottom-up” el diagrama de estructura anterior.


46

1. Codificar el módulo D y diseñar un driver de B para probar D.

2. Codificar el módulo E y diseñar dos drivers que simulen las llamadas de los módulos B y C, para probar E.

3. Codificar el módulo F y diseñar un driver de C para probar F.

4. Codificar le módulo B y diseñar un driver de A para probar B.

5. Codificar el módulo C y diseñar un driver de A para probar C.

6. Codificar el módulo A y probar el sistema completo. No se desarrollan más drivers.

La tabla adjunta describe con detalle el proceso de implementación anterior:

• Codificar y probar, y Con módulos: indican lo mismo que en la implementación “top-down”

• Drivers: indica aquellos drivers que hay que diseñar para probar el módulo actual. Cuando se definen dos drivers diferentes del mismo módulo, por ejemplo: B y B´, quiere decir que el driver B simulará la funcionalidad necesaria para probar el módulo D. Y el driver B´ simulará la funcionalidad necesaria para probar el módulo E.

En el ejemplo anterior, con implementación “bottom-up”, hay que desarrollar 6 “drivers”

El problema que presenta este tipo de implementación es que se prueba todo el sistema al final, no ocurre como en el tipo anterior que se va probando el sistema progresivamente.

Complejidad de los stubs y drivers según el módulo que sustituyen

Codificar un módulo stub o un driver no supone el mismo esfuerzo de programación. Depende fundamentalmente de las tareas que debe realizar en esa simulación. A tal efecto, hay que distinguir entre un stub aferente, eferente y de transformación, y un driver aferente, eferente y de transformación.

En la tabla adjunta se indican las tareas que tienen que realizar los distintos tipos de stubs y drivers señalados anteriormente.

Al analizar la tabla anterior se constata lo siguiente:

• Es más simple un “driver para un módulo aferente” que “un stub aferente”

• Es más simple un “stub eferente” que “un driver para un módulo eferente”

47

Estrategia de implementación mixta

La estrategia de implementación mixta es una mezcla de las estrategia “top-down” y “bottom- up”, que tiene en cuenta las ventajas de una y otra, comentadas anteriormente. A tal efecto, el proceso de implementación mixto consiste en:

• Implementa el sistema siguiendo la estrategia “bottom-up” sobre las ramas aferentes y la “top-down” sobre las ramas eferentes.

• Para las ramas que no son aferentes, ni eferentes se sigue la estrategia “top-down”

Esta estrategia, al igual que la “top-down”, produce un sistema integral y el esfuerzo de programación para desarrollar stubs y drivers es inferior a las dos anteriores.

Ejemplo: Implementar con estrategia mixta el diagrama de estructura del ejemplo anterior


1. Codificar el módulo D y diseñar un driver de B para probar D.

2. Codificar el módulo B y diseñar un driver de A y un stub de E, para probar B.

3. Codificar el módulo A y diseñar un stub de C para probar A.

4. Codificar el módulo C y diseñar dos stub: uno de E y otro de F probar C. Integrar C en la estructura anterior.

5. Codificar y probar el módulo E e integrarlo en la estructura anterior.

6. Codificar y probar el módulo F e integrarlo en la estructura anterior.

La tabla adjunta describe con detalle el proceso de implementación mixta del ejemplo:

48

• Codificar/probar, Con módulos, Drivers y Stubs: indican lo mismo que en las implementaciones anteriores.

Costes de implementación

Como se ha señalado anteriormente el esfuerzo de implementación de un stub y de un driver es diferente atendiendo a las tareas que realizan. De acuerdo con ello, se ha diseñado la tabla adjunta en la que se ha considerado que supone el mismo esfuerzo de programación:+

• Implementar un stub aferente y un driver para un módulo eferente (valor 7).

• Implementar un stub eferente y un driver para un módulo aferente (valor 4)

• Implementar un stub de transformación y un driver para un módulo de transformación (valor 9)

Ejemplo: Costes de implementación del ejemplo anterior

La tabla adjunta indica los costes de implementación top-down, bottom-up, y mixta. Las flechas indican quién llama a quién (ej. A->B, indica que A es el módulo que se codifica y prueba, y que necesita un stub B para ello)

49

Al analizar la tabla anterior se ve que la implementación mixta es la más barata (valor 34), y que las implementaciones top-down y bottom-up tienen el mimo coste (valor 40). Esto último es debido a que el diagrama de estructura del ejemplo es simétrico, por lo que da lo mismo implementarlo de “arriba abajo” que de “abajo arriba”. No obstante, a igualdad de esfuerzos la implementación top-down es mejor porque va produciendo una estructura integral de un modo incremental.

Implementación de la agenda personal

En el caso de la agenda personal vamos a analizar su coste de implementación con dos diagramas de estructura diferentes. Uno antes del refinado final cuando todavía existe el módulo “Leer datos”, y otro con el diagrama de estructura final.

a) Costes de implementación de la agenda personal con el módulo “Leer datos”

Se ve, por la tabla adjunta, que el coste de implementación top-down es de 69, el bottom-up es de 72, y la implementación mixta es de 66; es decir, el más barato. Se comprueba que al existir una rama aferente (“Leer datos”->“Agenda”) y ninguna eferente, y dos módulos eferentes “Consultar persona” y “Consultar cita”, el coste top-down es más barato que el bottom-up.

b) Costes de implementación del diagrama de estructura final de la agenda personal

En la tabla adjunta se ve que el coste de implementación top-down y mixta es de 62, y el de bottom-up es de 68. En este caso, aunque la estructura es simétrica (no existen ramas aferentes, ni eferentes), existen dos módulos eferentes (“Consultar persona” y “Consultar cita”) y ninguno aferente, lo que hace que la implementación top-down sea más barata que la bottom-up y exactamente igual a la estrategia mixta.

50

Ejemplo de codificación en C++ de la agenda personal

Vamos a finalizar la etapa de implementación presentando el proceso de codificación de la agenda personal en el lenguaje C++.

La estrategia a seguir es la siguiente:

1. Codificar los tipos de datos

2. Declarar las funciones y procedimientos

3. Codificar el programa principal

4. Definir las funciones y procedimientos

1. Codificar los tipos de datos

Consiste en codificar todos los tipos de datos que existen en la aplicación. La estructura de la agenda se compone de tres tipos de datos TAgenda, TPersona y TCita. Para el tipo TCita hay que definir dos tipos auxiliares más: TFecha y THora. También se han incorporado dos tipos enumerados: TRes, que incorpora los valores de retorno de los módulos; y TOp, que incorpora los tipos de operación de la agenda.

51

La codificación de estos tipos de datos es:

2. Declarar las funciones y procedimientos

Consiste en codificar la interfaz de todos los módulos, bien como una función (incorpora un valor de retorno) o como un procedimiento (no incorpora valor de retorno). Para ello se utiliza el diagrama de estructura.

En el caso de la agenda personal, tenemos que declarar las siguientes funciones: TratarPersonas, TratarCitas, AgregarPersona, ConsultarPersona, EliminarPersona, AgregarCita, ConsultorCita, y EliminarCita.

52

3. Codificar el programa principal

Para ello, se utiliza el diagrama estructurado obtenido en la etapa de diseño.

53

4. Definir las funciones y procedimientos

Consiste en codificar cada una de las funciones y procedimientos declarados anteriormente. Para ello, se utiliza el diagrama estructurado de cada función o procedimiento definido en el diseño.

A continuación presentamos la codificación de la función AgregarCita de la agenda personal.

54

Conclusiones (4. Implementación)

- La implementación comporta tres acciones: seleccionar el módulo a implementar, codificarlo, e integrarlo en el sistema.

- Cuando el cliente no propone una implementación determinada se utiliza una de las tres estrategias estándar: top-down, bottom-up, o mixta.

- En la implementación top-down se realiza la codificación y pruebas partiendo de los módulos superiores y siguiendo nivel a nivel por los inferiores. Para las pruebas se utilizan unos módulos ficticios denominados stubs que simulan la funcionalidad de los módulos inferiores no codificados.

- En la implementación bottom-up se realiza la codificación y pruebas partiendo de los módulos inferiores y siguiendo nivel a nivel hacia los módulos superiores. Para las pruebas se utilizan unos módulos ficticios denominados drivers que coordinan la ejecución de los de abajo ya codificados.

- En la implementación mixta se sigue la estrategia bottom-up sobre las ramas aferentes y la top-down sobre las eferentes. Se utilizan stubs y drivers.

- Las estrategias top-down y mixta producen de forma progresiva un sistema integral, mientras que en la bottom-up se prueba todo el sistema al final.

- La implementación bottom-up es más barata que la top-down si se necesitan más drivers aferentes que stubs eferentes. En todo caso, la implementación mixta es la más barata.

- La estrategia a seguir en la codificación de un programa en C++ es la siguiente: 1.- Codificar los tipos de datos; 2.- Declarar las funciones y procedimientos; 3.- Codificar el programa principal; 4.- Definir las funciones y procedimientos.

- La declaración de una función o procedimiento consiste en codificar su interfaz, bien como función o como procedimiento. Mientras que la definición de una función o procedimiento consiste en codificar el cuerpo de la función o procedimiento.

modelos de desarrollo de programas - fiwiki.orgmdp... · • debe ser breve y concisa y constituye...

Documents