Fig. 3: Métodos de Desarrollo de Software
4 Introducción En el corriente curso: Metodologías de Desarrollo de Software I nos centraremos en los mé- todos de desarrollo de software orientados a función/datos y en las herramientas propuestas para el modelado de los diferentes aspectos de un sistema: datos, control y funciones. Adicionalmente, se presentaran métodos formales, específicamente Z, y métodos orientados a objetos.
Capítulo I. — Estructura de la Metodología 5 I Capítulo I. ASML: A System Modeling Language Contenido
Estructura de la Metodología………………………………5 El Modelo Esencial……………….5 El Modelo de Implementación……………………………6 Secuencia de Creación de los Modelos………………….9
ASML es una metodología de desarrollo estructurado de sistemas que cubre todo el ciclo de vida de desarrollo. Esta metodología integra las principales ideas del Análisis Estructurado [De- Marco 79; Gane 79] y el Diseño Estructurado [Constant74; Yourdon 78] en un marco conceptual único y consistente. Si bien la definición original de la metodología puede reconocerse en los libros de Ward [Ward 83; 86] y MacMenamim [MacMenam84], le cabe una mejor definición al ser interpretada como: la conjunción del Análisis Estructurado Moderno [Yourdon 89] y el Diseño Estructurado [Constant74; Yourdon 78], con extensiones para el modelado de sistemas de tiempo real [Ward 86].
I.1. Estructura de la Metodología
ASML es una metodología que integra todas las ideas involucradas en el análisis y diseño es- tructurado. Conjuga las técnicas y herramientas de modelado usadas en el Análisis Estructurado Moderno y en el Diseño Estructurado dentro de una organización que destaca los diferentes mode- los necesarios para: obtener una buena comprensión del problema, y diseñar una solución de buena calidad (mantenible, adaptable, etc.). Separa el modelado de un sistema en una jerarquía de modelos necesarios para comprender diferentes propiedades del mismo. Dicha jerarquía de modelos se pre- senta en la Fig. I-1. El Modelo del Sistema está dividido en dos modelos generales: P
P El Modelo Esencial [McMenam84; Yourdon89]: Representa la etapa de Análisis Estructura- do. Construcción de un modelo libre de detalles tecnológicos. El Modelo de Implementación [Page88; Ward86; Yourdon78; Yourdon89]: Representa la etapa de Diseño Estructurado. Instanciación de un Modelo Esencial con una tecnología dada.
I.1.1. El Modelo Esencial
Puede ser considerado como la aplicación de la metodología de Análisis Estructurado Moder- no de Yourdon. La idea fundamental con la que el modelo esencial es concebido es la de Tecnolo- gía Perfecta en la cual no hay restricciones de cantidad de memoria, tamaño del disco o velocidad del procesador. Dos modelos componen el modelo esencial:
6 Capítulo I. — Estructura de la Metodología P
P El Modelo del Ambiente: Declaración de los objetivos. Creación de un Diagrama de Contexto y de una Lista de Eventos, describe los estímulos que recibe el sistema y las respuestas gene- radas por los estímulos. Definición del Diccionario de Datos inicial. Tabla de Estímulo- Respuesta. El Modelo de Comportamiento: Creación de un DFD, y un ERD por cada uno de los eventos de la Lista de Eventos. Los DFDs por eventos se unen en un único DFD (el Modelo Funcio- nal) y los ERDs por eventos se unen en un único ERD (el Modelo de Datos). Se acostumbra, también, modelar el comportamiento externo del sistema con DTE, árboles de pantallas o me- núes, etc. La creación simultánea del modelo de datos, modelo funcional y modelo de interfaz o comportamiento externo, ayuda en la validación y completitud del modelo esencial (descu- briendo, por ejemplo, eventos no considerados). Todos los criterios de modelado y, principalmente de validación, descriptos en la metodología de Análisis Estructurado Moderno pueden (y deben) ser aplicados en esta etapa para obtener un modelo esencial de calidad y que sea consistente.
I.1.2. El Modelo de Implementación
A partir de esta etapa, el modelo esencial es instanciado en una tecnología dada. Se debe con- siderar ahora, las imperfecciones de la tecnología y determinar: la cantidad de procesadores necesa- rios, las cualidades de estos procesadores, el tamaño de disco necesario de acuerdo al volumen de la información a ser almacenada, etc. Luego se diseña la solución sobre la base de esas restricciones tecnológicas. La creación del modelo de implementación se fundamenta en la creación de tres modelos, uno de ellos en forma independiente (el modelo del usuario o de la interfaz hombre-máquina) y los otros dos en forma encadenada en un proceso incremental de refinamiento e incorporación de detalles: Modelo del Sistema Modelo Esencial Modelo del Ambiente Modelo de Comportamiento Modelo de Implementación Modelo del Usuario Modelo de Distribución Modelo de Programa Modelo de Procesadores
Capítulo I. — Estructura de la Metodología 7 P
P
P
P
P El Modelo del Usuario: La interfaz hombre-máquina es modelada en todos sus detalles, estilo (árboles de menús, lenguajes de comandos, manipulación directa, etc.), lay-out y formato de pantallas, formato de informes y listados, diseño de pantallas para el ingreso de datos y pre- sentación de resultados, estilo de mensajes de error, secuencialidad, etc. La creación de este modelo es independiente del resto de los modelos que conforman el de implementación, y puede ser desarrollado en paralelo. Las interfaces deben ser diseñadas para cada uno de los procesadores (del modelo de procesadores) y para cada una de las tareas (del modelo de ta- reas). El Modelo de Distribución: Describe todas las decisiones relativas a la arquitectura de hard- ware (modelo de procesadores) y a la estructuración general de la arquitectura de software (modelo de tareas). Se incorporan, en los modelos creados hasta este punto algunas Distorsio- nes destinadas a optimizar el uso de esa tecnología. El criterio fundamental es: Minimizar to- do lo posible las distorsiones agregadas. El Modelo de Procesadores: El modelo comportamental (modelo de datos, modelo funcional y modelo de comportamiento externo o de interfaz) es subdividido por procesadores. Se apli- can criterios cualitativos (por ejemplo: necesidad de monitores de alta resolución gráfica) y cuantitativos (por ejemplo: velocidad del procesador, volumen de información almacenada, etc.) para seleccionar los procesadores, sistemas operativos, software y hardware de red, etc. Las distorsiones agregadas corresponden a la partición del DFD, ERD, DTE en procesadores, refinamiento de procesos y entidades o depósitos de datos (para asociar parte en un procesa- dor y parte en otro) y a la incorporación de procesos para el control de la comunicación entre procesadores (siempre que la tecnología no solucione el problema de manera transparente). El Modelo de Tareas: Los modelos resultantes de la creación del modelo de procesadores son estudiados por separado (un procesador por vez), para determinar tareas diferentes (que serán programas diferentes de manera tal que se pueden ejecutar concurrentemente o no). La distor- sión agregada en esta etapa representa la subdivisión del modelo funcional de un procesador (el DFD) en distintos DFDs (uno por tarea) agrupando procesos batch, interactivos o de tiem- po real, partes del DFD aisladas del resto (comunicación solamente a través de depósitos de datos), etc. Además, es probable que sea necesario agregar procesos de control de concurren- cia y sincronización para el acceso a recursos compartidos (como por ejemplo los depósitos de datos). El Modelo de Programas: La estructura del programa que implementa cada una de las tareas resultantes de las etapas de modelado de procesadores y tareas, es diseñada mediante la apli- cación de las técnicas y estrategias descriptas por el Diseño Estructurado (por ejemplo: Análi- sis de Transformaciones y Transacciones) y mejorada con la aplicación de criterios de calidad (por ejemplo: Cohesión, Acoplamiento, etc.).
8 Capítulo I. — Secuencia de Creación de los Modelos Modelo del Ambiente Modelo de Comportamiento
Modelo del Usuario
Modelo de Procesadores
Modelo de Tareas
Modelo de Programas de Datos I.2. Secuencia de Creación de los Modelos
cv := cliente vie c := cliente cn := cliente nu p := prov gte := gerente
Diccionario cv := cliente vie c := cliente cn := cliente nu p := prov gte := gerente
Diccionario de Datos Modelo de Datos Modelo de Datos, Funcional y de Interfaz para cada Procesador Arquitectura de Hardware
Un DFD para cada Tarea de cada Procesador
Uno o más DEs para cada tarea Arquitectura de Software
Especificación de los Módulos Informes, Listados, Lay-out de Pantallas
cv := cliente vie c := cliente cn := cliente nu p := prov gte := gerente
Diccionario de Datos Modelo de Comportamiento Externo
Árboles de Pantallas Modelo Funcional 1.- cliente 2.- cliente nue 3.- cliente vie 4.- proveedor 5.- gerente Lista de Eventos Diagrama de Contexto
Capítulo II. — Introducción 9 II Capítulo II. Análisis Estructurado Moderno Contenido
Introducción……………………………9 El Modelo Esencial……………..10 Dificultades en la Construcción del Modelo Esencial……………………..10 Componentes del Modelo Esencial……………………11 ¿Cuándo es Necesario Desarrollar un Modelo del Sistema Actual?…..11 El Modelo Ambiental……………..11 La Declaración de Objetivos…………………………….13 El Diagrama de Contexto…………………………………13 Construcción del Diagrama de Contexto………………….. 14 La Lista de Eventos……………..16 Construcción de la Lista de Eventos……………………….. 18 ¿Qué va primero: el Diagrama de Contexto o la Lista de Eventos?…..18 El Diccionario de Datos Inicial…………………………19 El Modelo Comportamental ………………………………19 Creación del DFD ……………….19 Creación del Modelo de Datos………………………….22 Subdivisión en Niveles…………23 El Diccionario de Datos……….24
El análisis estructurado fue la metodología de análisis de sistemas que tuvo uno de los impac- tos más grandes en el ambiente de producción del software. Desde sus orígenes a mediados de los años setenta, con los libros de Tom Demarco [Demarco 79] y, Chris Gane y Trish Sarson [Gane 79], luego durante la década siguiente se extendió rápidamente hasta volverse en una metodología standard. En los ochenta, muchos autores trabajaron en su modernización y en la incorporación de nuevas herramientas y estrategias de modelamiento [McMenam 84; Ward 85a, 86b; y otros]. La metodología presentada en este capítulo, Análisis Estructurado Moderno [Yourdon 89], es una propuesta de Edward Yourdon que, establece el modelo standard para el análisis estructurado e incorpora las ideas, criterios y herramientas presentados por los libros que lo precedieron, en una estructura de trabajo muy organizada y consistente.
II.1. Introducción
El propósito del Análisis de Sistemas es producir una declaración de requisitos esenciales del sistema que deben llevarse a cabo. Un requisito esencial es una característica que el sistema debe presentar, cualquiera sea la tecnología que llegara a ser usada para implementarlo. Frecuentemente, los analistas de sistemas incluyen falsos requisitos en las especificaciones. Un requisito falso es un característica irrelevante o necesaria sólo para el empleo de una cierta tec-
nología. También pueden estar creándose requisitos falsos en términos de la implementación de un requisito esencial. Al realizar un análisis de sistemas que confunde requisitos falsos por esenciales, o dejando de incluir características esenciales, debido al exceso de requisitos falsos que confundieron las consi- deraciones de los analistas, se pueden producir resultados desastrosos y retardar el desarrollo del proyecto considerablemente. Según McMenamim [McMenam 84], el análisis tradicional intentó resolver este problema instruyendo a los analistas a que separasen los requisitos lógicos de los aspectos físicos del sistema pero, sus proponentes eran incapaces de definir los términos lógicos y físicos apropiadamente, y ellos no proporcionaron los procedimientos detallados para distinguir los requisitos esenciales. Para buscar una solución es aconsejable la construcción de un Modelo Esencial del sistema, evitando el modelamiento del sistema actual y las características que dependen de la tecnología, desarrollando un modelo del nuevo sistema deseado por el usuario.
II.1.1. El Modelo Esencial
El modelo esencial del sistema indica lo que el sistema debe hacer para satisfacer los requisi- tos del usuario y debe mencionar el mínimo posible (preferentemente nada) de como el sistema se llevará a cabo. Eso significa que el modelo del sistema presupone tecnología perfecta (la capacidad ilimitada de almacenamiento, velocidad infinita del procesador, etc.) y que eso pueda ser obtenida a costo cero. De una manera específica, cuando el analista de sistemas deba discutir con los clientes y usua- rios sobre los requisitos del sistema, debe evitar consideraciones sobre las implementaciones especí- ficas de los procesos del sistema. Por supuesto, si el objetivo final es la implementación de un grupo de programas que ejecutan y atiendan los propósitos y la conducta requerida, deben ser incluidas las propias características de una tecnología en particular, pero eso se pospone para una fase posterior: la fase de diseño. Si las características de una tecnología son consideradas como requisitos en el análisis, el modelo resul- tante estará viciado con esa tecnología y la complejidad (medida en la cantidad de características que el analista tiene que considerar en un momento dado) puede ser tan grande que es posible olvi- darse de algunos de los requisitos esenciales (el árbol esconde el bosque). Sin embargo, una vez desarrollado el modelo esencial, éste puede ser instanciado con cualquier tecnología.
II.1.2. Dificultades en la Construcción del Modelo Esencial
A pesar que las pautas podrían parecer simples y obvias, muchas veces se torna bastante difí- cil eliminar completamente del modelo esencial todos los detalles de implementación. Algunos ejemplos comunes de detalles de implementación pueden ser: P
P
10 Las secuencias arbitrarias de actividades en un proceso de transformación de datos: La fun- cionalidad del sistema se planea en base a las transformaciones de los datos. Así, la secuencia de actividades debe ser aquella exigida por los datos (una actividad B puede exigir un elemen- to de los producidos por la actividad A y no podrá comenzar su trabajo hasta que la actividad A lo haya producido). Archivos innecesarios: (Depósitos de datos que no serían necesarios si estuviera disponible la tecnología perfecta). Los archivos temporales o intermedios pueden aparecer en el modelo de implementación porque los procesos son escalonados en el tiempo para trabajar en momentos diferentes. También se introducen en dicho modelo para el resguardo de información (back- up) y recuperación, debido a que la tecnología de implementación es propensa a fallas, así como las personas que operan las computadoras son propensas a cometer errores.
Capítulo II. — Introducción
Capítulo II. — El Modelo Ambiental 11 P
P La verificación y validación innecesaria de errores: Las actividades de validación son nece- sarias en un modelo de implementación por ser necesario trabajar con procesos (humanos y programas) propensos a errores, debido a los canales ruidosos en la transferencia de datos en- tre tales procesos. Datos redundantes o derivados: A veces ciertos datos redundantes son incluidos en depósitos con el objetivo de mejorar la eficiencia; aunque esto es normalmente razonable, debe hacerse durante la fase de diseño y no durante el modelamiento de las funciones y datos esenciales. Por otra parte, un analista de sistemas desprevenido puede incluir elementos de datos que pueden ser derivados, o calculados a partir de los valores de otros datos.
II.1.3. Componentes del Modelo Esencial
El modelo esencial está compuesto de dos componentes principales: P
P El Modelo Ambiental: este modelo define la frontera entre el sistema y el resto del mundo (es decir, el ambiente donde el sistema reside). El modelo ambiental está compuesto de un Dia- grama de Contexto, una Lista de Eventos y una descripción pequeña del propósito del siste- ma, la Declaración de Objetivos. El Modelo Comportamental: describe la conducta, del interior del sistema, necesaria para interactuar exitosamente con el ambiente. Esta compuesto de Diagramas de Flujo de Datos, Lista de Eventos, Diagramas de Entidades y Relaciones, Diagramas de Transición de Estados, Diccionario de Datos y Especificación de Procesos.
II.1.4. ¿Cuándo es Necesario Desarrollar un Modelo del Sistema Actual?
Existen circunstancias en que el analista de sistemas puede encontrar necesario elaborar un modelo del sistema actual antes de construir el Modelo Esencial del sistema. Normalmente esto es necesario debido a que el usuario (o el propio analista) no tiene suficiente conocimiento del pro- blema actual. Lo primero a considerar, si el modelo del sistema actual es construido, es que su objetivo principal es obtener el conocimiento y una visión general del sistema existente. El objetivo no es documentar el sistema actual detalladamente.
II.2. El Modelo Ambiental
Para el analista de sistemas, la tarea más difícil en la especificación de un sistema es, muchas veces, la determinación de qué forma parte del sistema y qué no. Todos los sistemas, no importando cuan ambiciosos o grandiosos sean, todavía serán parte de un sistema más grande. De esta manera, el primer modelo importante por desarrollar es el que define las interfaces entre el sistema y el resto del universo, es decir, el ambiente. El Modelo Ambiental describe los límites del sistema, los estí- mulos que recibe y como reacciona a ellos. Además de determinar lo que está dentro del sistema y lo que está fuera de él (definiendo la frontera entre el sistema y el ambiente), también es de fundamental importancia definir las interfa- ces entre el sistema y el ambiente, es decir, que información penetra en el sistema proveniente del ambiente externo, y que información del sistema es transmitida al ambiente externo.
P
12 El deseo del cliente de obtener una cierta porción del mercado para un servicio, o para aumentarlo más allá de su nivel actual. Esto podría ser hecho por la oferta de un nuevo servicio o por el aumento de la funcionalidad de un servicio existente (por ejemplo, mayor funcionalidad ofrecida por los sistemas de cajeros automáticos y sistemas bancarios en línea). O el usuario podría intentar aumentar su participación en el mercado a través de la oferta de un servicio mejor o más rápido.
Capítulo II. — El Modelo Ambiental Ambiente Sistema Ambiente Sistema a) b) Fig. II-1: Frontera entre el ambiente externo y el sistema. La parte a) muestra los límites del sistema, la porción a ser estudiada. La parte b) muestra el área gris entre el sistema y el ambiente.
Naturalmente, no se producen entradas y salidas por casualidad: ningún sistema de informa- ción incluye a todos los datos disponibles del universo, ni cualquier sistema real emite información de forma aleatoria para el consumo del ambiente externo. Los sistemas que construimos son racio- nales y objetivos; específicamente, producen salidas como respuesta a un evento, o a un estímulo del ambiente. Así, otro aspecto básico del modelo ambiental es la identificación de los eventos que ocurren en el ambiente a los que el sistema debe reaccionar (los eventos que ocurren en el exterior y que exigen una respuesta del sistema). Como se presenta en la Fig. II-1-a, la frontera entre un sistema y su ambiente es arbitraria. Puede ser establecida por una decisión de la gerencia, como resultado de una negociación política, o simplemente por accidente. Es algo en que el analista de sistemas, habitualmente, tiene alguna opor- tunidad de influenciar. En general, el cliente tiene una idea buena de los límites generales pero, como mostró en la Fig. II-1-b, existe muchas veces un Área Nebulosa, abierta para las negociaciones, en el que el cliente no está muy seguro, en que todavía no pensó, tiene algunas ideas que necesitan ser analiza- das, o todo esto junto. Si el analista de sistemas escoge, en ese área gris, un ámbito demasiado pequeño para un pro- yecto, este se destina al fracaso, porque el cliente puede haber estado identificando el síntoma del problema en lugar de la causa. Si el analista de sistemas, escoge un ámbito demasiado grande para un proyecto, estará destinado a fallar por exceso de confianza o ingenuidad, porque estará lidiando con una situación política mucho más compleja, y estará intentando desarrollar un sistema que será probablemente demasiado grande de ser desarrollado bajo cualquier circunstancia, o puede estar tratando con problemas que al cliente no le interesan o no pueden modificarse de ninguna manera. De esta manera, es importante dedicar el tiempo necesario y obtener del usuario bastante participa- ción en la determinación de un límite del sistema apropiado. Algunos de los factores más importantes en la elección del ámbito del proyecto se listan a continuación:
| Página siguiente |