Wordsworth, J.B. Desarrollo de Software con Z Captulo I Introduccin 1.1 Por qu fue escrito este libro?

Este libro intenta proporcionar consejos prcticos sobre el uso de Z en el desarrollo de software. Z es una notacin desarrollada por el Grupo de Investigacin de Programacin de la Universidad de Oxford para registrar de alguna forma precisa las mltiples decisiones que se obtienen en el campo del desarrollo de una pieza de software. El autor ha estado asociado durante un nmero de aos con el desarrollo de Z como un profesor de lenguajes de programacin, como un ingeniero de software y como un diseador de software. El libro es, por lo tanto, el fruto de una considerable cantidad de ideas del tema y experiencia prctica. Habiendo dicho que este es una gua prctica, aconsejamos leer sobre la teora de Z, su semntica y sus bases matemticas formales en otra parte, por ejemplo en Spivey (1987). 1.2 Recorrido de los temas Una mirada a los contenidos mostrar que el libro contiene una cierta cantidad de matemticas y notacin matemtica. Afortunadamente las matemticas que son apropiadas para registrar las decisiones del desarrollo de software no son muy difciles. Las notaciones de la teora elemental de conjuntos son de importancia de primera clase, y estas son vistas con ms detalle en el captulo 3, pero siempre en el contexto de su relevancia para el desarrollo del software. Necesitaremos estar familiarizados con las notaciones de conjuntos, relaciones, funciones y secuencias, lo que nos proveer las bases para precisar las cosas que percibimos en un sistema de software. Esta clase de matemticas es generalmente llamada matemtica discreta de nmeros reales que incluye clculo diferencial e integral. La necesitaremos para facilitar hacer las declaraciones sobre las cosas que percibimos y para expresar lo requerido o posibilitar las relaciones entre ellas, y para esto necesitaremos predicados de conjuntos, etc. Z es un mtodo de matemticas actual en un framework legible. Los documentos de Z consisten principalmente de texto en ingls en el cual se encuentran pequeas piezas de matemticas que hacen preciso lo que es descripto informalmente en un lenguaje natural, imagen, etc. La construccin principal de Z es el esquema, en el cual hacemos presente al lector algunas clases de importancia en el sistema de software, y hacemos algunas declaraciones sobre las relaciones de esas clases. Exploraremos el uso de Z registrando las especificaciones de software, decisiones de diseo de datos y (en conjuncin con una notacin de programacin) decisiones de diseo de algoritmos. En una seccin siguiente describiremos detalladamente una clase de proceso de desarrollo de software en el cual esas decisiones son inmersas. El lector descubrir que el uso de Z para escribir especificaciones de sistemas de software es completamente ms abarcativo que en las fases siguientes del proceso de desarrollo. Esto es principalmente debido a que es mayor la experiencia en el uso de Z para la especificacin que para el diseo. Los captulos 6 y 7 han sido escritos con la esperanza de estimular la experimentacin en el uso de Z en las siguientes fases del proceso. No todas las matemticas que estn disponibles para escribir Z son descriptas aqu. Los lectores podrn consultar algunos de los libros en la bibliografa sobre p.321 para ms notaciones matemticas y para aspectos de Z no vistos aqu. 1.3 Cmo usar este libro? Aunque este libro no puede reemplazar a expertos en la materia, aconsejar sobre algunos de los riesgos y da buenos ejemplos prcticos y normas en el uso de Z. Hay ejemplos de tcnicas comunes presentando especificaciones y ejemplos del uso de estructuras de datos comunes para el refinamiento. Los usuarios acadmicos encontrarn un libro base para ejemplos en la aplicacin de matemticas para problemas prcticos. Los profesores, ya sean en industria o en instituciones acadmicas, encontrarn abundantes ejercicios en las partes matemticas y prcticas de Z. Son suministradas soluciones para la mayora de los ejemplos de rutina. Usar mtodos formales podra ser visto como una parte del proceso social del desarrollo de software en el cual la exposicin de una especificacin o diseo por una o ms personas, para un grupo de oyentes crticos, es una parte importante. 1.4 Una visin del desarrollo del software

Pgina 1 de 6

Wordsworth, J.B. Desarrollo de Software con Z Captulo I El desarrollo del software es una actividad importante en el desarrollo de nuestra civilizacin, probablemente jugar un rol importante en el futuro. El software se utiliza para cuidar nuestro dinero en el banco, pagar nuestros salarios, controlar los vuelos de un lugar a otro, controlar las estaciones de potencia nuclear que generan electricidad para alumbrar y calentar nuestros hogares. Hay una necesidad de realizar nuevo software ms rpido y menos costoso como nunca antes, y hay una necesidad a adaptar software existente a nuevas circunstancias. Gran parte del desarrollo de software es una actividad cooperativa que involucra a varios desarrolladores. Aunque el software puede ser desarrollado por una persona trabajando solamente, en el futuro no es probable encontrarse con un grupo de una persona. Donde trabajan juntas personas para crear una gran pieza de software, necesitan acordar sus roles. La idea es que el software puede ser construido en piezas separadas o en mdulos, y gran parte de la divisin del trabajo del desarrollo del software tradicional fue basado en la idea que ms de una desarrollador experimentado podra decidir cmo el sistema puede ser descompuesto, y entonces dar las especificaciones de los mdulos a los menos experimentados para implementarlo. Como los requerimientos para los sistemas tienen mayor complejidad, el trabajo para la descomposicin es ms arduo y propenso a errores. Para muchos un sistema que ha sido modularizado, codificado y testeado por unidad, fracasa en la integracin cuando la naturaleza de las interfaces entre los mdulos no es clara. Una de las tareas del ingeniero de software es realizar una descomposicin de un sistema, y garantizar su responsabilidad por las partes de este. La relacin del ingeniero de software con los desarrolladores es semejante a la de un cliente y los suministradores un cliente fija los requerimientos y los suministradores facilitan el programa material para cumplir con ellos. Si las piezas a ser construdas son muy grandes, entonces la descomposicin de esos requerimientos podra ser la responsabilidad de otro ingeniero de software. Los ingenieros de software tratan cmo un requerimiento podra ser encontrado concluyendo que el sistema puede ser construido desde partes existentes. La nocin de que los componentes de software pueden ser reusados es una recomendacin principal de los sistemas desarrollados orientados a objetos. Para reusar un componente de software previamente escrito, el ingeniero de software debe tener una descripcin precisa de la funcin del componente. Esta precisin es esencial, un concepto errneo sobre la funcin de un componente importado desde otra parte podra no llegar a ser claro y retrasar el proceso de desarrollo con lo cual el cambio ser difcil y costoso. Los desarrolladores de software hacen suposiciones sobre lo que satisfacer al usuario. Los usuarios opinan sobre qu hacen esas suposiciones pero generalmente no es suficiente. Una funcin significativa de un ingeniero de software es asegurar que los requerimientos del cliente estn bien entendidos y bien documentados, y que la descomposicin inicial est fundamentada completamente. Los clientes presentan dos problemas: no conocen lo que necesitan y frecuentemente cambian sus ideas sobre lo que pensaban que necesitaban. Los ingenieros de software tienen la habilidad de saber qu requerimientos de los clientes precisan ser realizados y usan la precisin para explorar y aclarar los requerimientos. Los desarrolladores de software realizan decisiones sobre cmo los requerimientos del usuario son implementados. Esas decisiones estn condicionadas por muchas cosas tales como la capacidad del hardware, la disponibilidad de herramientas de programacin, de lenguajes de programacin, la necesidad de encontrar y fijar los errores, las suposiciones de los usuarios sobre cmo usarn el sistema y los requerimientos de los usuarios para su ejecucin. La filosofa de los mtodos formales del desarrollo del software es que usar matemticas para registrar el desarrollo es muy prctico. Las matemticas se usan por la necesidad de tomar control sobre ciertas ideas intuitivas que se presentan teniendo valores prcticos y el xito de las matemticas es hacer que esas ideas sean precisas. Esta actividad tiene una larga historia y las nociones de aritmtica y geometra Euclideana fueron bien conocidas en el periodo clsico. Ms recientemente, las nociones como tipo de cambio estimuladas por las investigaciones dinmicas y astronmicas del decimosexto y decimosptimo siglo, dieron auge al clculo diferencial. An ms recientemente, la nocin de precisin ha sido precisa en lgica matemtica. El proceso de hacer una vaga nocin precisa es llamado formalizacin, y supone que el proceso puede ser aplicado a varias partes del desarrollo del software como otros campos de las matemticas aplicadas. Miramos ahora un proceso de desarrollo de software examinando alguno de los sitios donde es posible la formalizacin y comprenderemos qu beneficios podran brindarnos. Hay muchos modelos usados para describir el proceso de desarrollo de software, pero en la mayor parte tenemos las siguientes fases en comn: Anlisis de requerimientos, en el que nos encontramos averiguando lo que necesitan los usuarios del software.

Pgina 2 de 6

Wordsworth, J.B. Desarrollo de Software con Z Captulo I Especificacin, en la cul decidimos qu desarrolladores de software se van a proporcionar. Diseo, en el cual las decisiones se realizan sobre la base de cmo se encuentran los requerimientos. Programacin, en la cual las decisiones son embebidas en las declaraciones de un lenguaje de programacin y es realizado algn testing a nivel de mdulos. Testing, en el cual el sistema es construido y puesto en marcha a travs de sus pasos. Mantenimiento, en el cual son fijados los errores reportados por los usuarios.

En muchas organizaciones de desarrollo de software este proceso es repetido muchas veces para producir sucesivas versiones de un producto, cada construccin con su predecesor. El anlisis de requerimientos intenta encontrar averiguar lo que necesitan los usuarios que estn haciendo uso del software necesitado actualmente. Los requerimientos podran incluir funcionalidad, eficiencia, operaciones, implementacin, utilizacin, disponibilidad, costo, escalas de tiempo y otras clases. La especificacin es un proceso que establece cul organizacin de desarrollo se va a proveer. La documentacin de especificacin resultante frecuentemente sigue las extensas lneas de la declaracin de requerimientos, direccionando el mismo objetivo. Una comparacin entre especificacin y requerimientos podra dar a los usuarios confianza de que lo que se est haciendo podra ayudar a resolver los problemas que apuntan a los requerimientos. Esto significa que en la especificacin de la funcin provista, los mtodos formales son generalmente introducidos en el proceso de desarrollo. En parte de este libro se formalizan las notaciones de requerimientos de funciones y se registra su resultado en Z. En una especificacin no describimos el propsito del programa y las estructuras de datos en detalle; en realidad, probablemente no conocemos lo que ellos van a hacer. Mas bien, presentamos un modelo abstracto. El nivel de abstraccin es tal que un usuario no se familiariza con los detalles de programacin y las mquinas pueden calcular el comportamiento estando especificado, y acuerdan qu es lo requerido. En este libro sugerimos que ciertas partes de las matemticas son convenientes para expresar modelos abstractos en especificaciones. Algunas veces los requerimientos son de la forma: Necesito un sistema que acepte cierta informacin como entrada y produzca otra cierta informacin como salida acordando una cierta regla. Ms especficamente podramos tener: Necesito un programa que acepte un archivo de texto confeccionado con ciertos signos especiales y produzca pginas formateadas en una impresora lser, la entrada y la salida estn dadas por la siguiente regla ... Un modelo conveniente para tal sistema es el modelo relacional, basado en la notacin de una relacin matemtica descripta en el captulo 4 e ilustrada en la figura 1.1 Inputs especificacin. La regla de relacin debe presentar claramente su precondicin, i.e. se debe satisfacer la condicin si las entradas son aceptables. La nocin de que slo ciertas entradas deben ser aceptadas es muy importante y su conocimiento est frecuentemente ausente desde las descripciones informales de sistemas. Imprecisiones en esta rea pueden causar a los desarrolladores mucha dificultad y a los usuarios mucha molestia cuando el sistema les es entregado. Para aceptar entradas la regla debe tambin establecer cmo las salidas estn relacionadas con las entradas. El modelo de relacin permite diferentes salidas a derivar de la misma entrada, y esta propiedad es llamada no determinista. Este es un valioso mecanismo de especificacin, este permite requerimientos como En estas circunstancias yo no me preocupo por si ... ... para ser preciso sin forzar el resultado del objetivo de la especificacin. Si no hay libertad en la eleccin de las salidas para obtener las entradas el modelo relacional llega a ser regla de funcin. Forzar un modelo funcional donde un modelo de relacin podra ser ms apropiado es una instancia de sobreespecificacin. Otra clase de sobre-especificacin ocurre cuando el usuario expresa un requerimiento que tiene una precondicin, pero la especificacin exige fijar qu va a suceder en cada circunstancia. El usuario dice: En estas circunstancias yo espero la siguiente funcin ... pero en otras circunstancias yo no me hago responsable de lo que suceder. Construir el comportamiento en estas circunstancias es sobreespecificacin. Regla de Relacin Output figura 1.1 El modelo

de

relacin

en

Pgina 3 de 6

Wordsworth, J.B. Desarrollo de Software con Z Captulo I El modelo de relacin no es conveniente para muchos sistemas. Retornando al ejemplo de procesamiento de texto, podramos desear para controlar el formateo por opciones que pueden ser elegidas independientemente de una forma de ejecucin. Para tal sistema el modelo de mquina de estado es apropiado. En este modelo el estado o dato persistente es retenido en la mquina, y usado para afectar su consecuente comportamiento, como ilustramos en la figura 1.2. Inputs Regla de Relacin Fig. 1.2 El modelo de la mquina de estado en Especificacin. Estado Un modelo de mquina de estado tpico consiste de un modelo abstracto del estado, una descripcin del estado inicial, una relacin o reglas de funcin para cada una de las operaciones del estado. Cada regla describe las entradas de una operacin y el estado de comienzo para las salidas de la operacin y el estado de terminacin. En el ejemplo de procesamiento de texto, el estado podra estar controlando los controles de formateo y las operaciones podran ser las interacciones con el mundo exterior que cambian las opciones, o realizar una ejecucin de formateo de un archivo de texto. Slo una parte de los datos y operaciones significativas que son accedidas constituyen un tipo de dato abstracto. La nocin de que los datos podran estar protegidos es llamada encapsulacin. El Captulo 5 trata ms las tcnicas de los tipos de datos abstractos presentados usando modelos abstractos y reglas de relacin apropiadamente. Las ideas de precondiciones, no-determinismo y sobre-especificacin se refieren a la regla de relacin en el modelo de la mquina de estado del mismo modo que en el modelo relacional. El diseo es un proceso en el cual los desarrolladores realizan y registran decisiones sobre cmo la especificacin va a ser implementada. Hay dos clases de decisiones de diseo a ser realizadas: Cmo son los modelos abstractos de la especificacin a ser representados usando hardware y software? Esto es un diseo de dato. Qu programas necesitaremos construir para manipular el hardware y software para proveer las operaciones descriptas en la especificacin? Esto es diseo de algoritmo. Esas decisiones son realizadas en tal sentido para satisfacer los requerimientos funcionales involucrados en la especificacin, y para encontrar los requerimientos no funcionales de eficiencia, etc. En un mtodo formal de desarrollo esas decisiones son registradas usando matemticas. Un diseo preciso puede ser chequeado junto a una especificacin precisa usando tcnicas de prueba matemtica, un proceso llamado verificacin. Las reglas para la verificacin y ejemplos de pruebas se encuentran en los captulos 6 y 7. En programacin, el diseo de algoritmos es traducible dentro de un programa en la eleccin del lenguaje de programacin. La cantidad de programadores est determinada por el grado de detalle en el diseo del algoritmo y la capacidad del lenguaje. Usualmente el diseador de algoritmo y el programador pueden ser la misma persona, y las dos actividades funcionan juntas. El programador podra hacer el testing de unidad en cada mdulo chequeando graves errores en la implementacin de la especificacin, pero el testing exhaustivo es usualmente imposible, y el xito de los mtodos formales es que el cdigo podra ser correcto por diseo. La fase de testing integra los mdulos dentro de un sistema y los tests para correcciones de la funcin. Si los mtodos formales son usados en el desarrollo las correcciones de la funcin no son probablemente el principal enfoque del testing, pero otras propiedades no funcionales, tales como la eficiencia, operabilidad y sanidad de las publicaciones del usuario probablemente sern examinadas. Sin embargo, la funcin an no es testeada, y una especificacin formal brinda al testeador una importante perspectiva dentro de las clases de direcciones que la funcin del producto puede ejercer. Como aclaracin, la especificacin entrega una especificacin precisa de las precondiciones de la variedad de operaciones, y el comportamiento observable del producto en cada circunstancia que cumplen las precondiciones. En estos planes de tests funcionales bsicos se pueden construir recorridos para todos los casos de las precondiciones y se pueden producir las distintas clases de comportamiento de las cuales el sistema est capacitado. Solamente para el comportamiento que es no determinista, un plan no puede ser realizado solamente desde la especificacin. Para el comportamiento no determinista el testeador debe mirar dentro del diseo para encontrar las circunstancias que deben ser establecidas para provocar los diferentes casos. Outputs

Pgina 4 de 6

Wordsworth, J.B. Desarrollo de Software con Z Captulo I

En mantenimiento, la organizacin de desarrollo responde a dos clases de apremios de los usuarios del producto. La primera es corregir errores en el producto y su especificacin y la segunda es agregar ms facilidades al producto y distribuirlo en otra versin. Se podra pensar que si un producto fue construido desde una especificacin formal con un diseo registrado formalmente y todas las verificaciones realizadas, entonces un error en la funcin podra ser imposible, pero la produccin del software no siempre seguir la perfeccin. En la primer fase del diseo las pruebas son corregidas probablemente slo cuando se hace informalmente. En el segundo paso cada prueba tiene que ser formalmente realizada y podran tener errores. Entonces, cul es la utilidad de un desarrollo registrado formalmente? El punto de correccin de cada error puede ser determinado, y tomada una accin correctiva para reforzar la parte del proceso de decisin examinada. 1.5 Sumario del rol de los mtodos formales Los mtodos formales son mtodos para registrar las decisiones del desarrollo de software una vez realizadas. En el camino, ellos permiten explorar las consecuencias de las decisiones antes que su ejecucin sea irrevocable o muy costosas para arreglar, y ellos podran sugerir algunas decisiones que podran ser pasadas por alto. Ellos ayudan a cada estado a hacer las preguntas sobre qu decisiones deben ser realizadas y cules suspendidas y quizs nos estimularan para registrar las razones para hacer o suspender las decisiones. Ellos proveen una organizacin de desarrollo con un registro completo de las decisiones de diseo que dirigen al producto a seguir este camino, y esto registra una valiosa ventaja en la continuidad de la vida del producto. El rol de un registro formal de desarrollo como algo positivo es visto ms adelante en Wordsworth (1992).

Pgina 5 de 6

Wordsworth, J.B. Desarrollo de Software con Z Captulo I

****

Pgina 6 de 6