Apuntes de Papers fundacionales (Ingeniería II)

De Cuba-Wiki
Saltar a: navegación, buscar
Back.png Volver a la página de la materia

Dijkstra[editar]

Es clave la visión de Dijkstra del programa como una fórmula, como un manipulador abstracto de símbolos. Un lenguaje tiene una sintaxis formal y reglas semánticas, su ejecución no es más que un modelo para la interpretación del mismo.

A debate on teaching CS[editar]

Del paper On the cruelty of really teaching computer science salen las principales críticas a la ingeniería de software. Su primera objeción está en que el método de enseñanza por analogía sirve solamente para los cambios graduales, y la ciencia de la computación es un cambio radical, con lo que debe ser enseñada dentro de un nuevo paradigma. Las radical novelties tienen el problema de que las experiencias y asociaciones pasadas no son más relevantes, con lo que dichas novelties tienden a ser rechazadas o negadas.

La computación implica dos radical novelties. La primera, el gran nivel de jerarquía y descomposición de los programas, muchos niveles de abstracción que deben ser manejados al mismo tiempo. La segunda, es que la computadora es el primer gran dispositivo digital, del que no es posible determinar un cambio pequeno (comportamiento no continuo respecto a cambios).

La ingenieria de software es descripta como The dommed disciple, pues se basa en la premisa How to program if you cannot. Busca esconder la radical novelty de la CS escondiéndola detrás de la imagen familiar de una ingeniería y aplicando métodos ingenieriles (ilusion de controlar algo si se conoce su nombre y es familiar). Algunas de sus prácticas inútiles son el control de calidad (testing no puede demostrar la ausencia de bugs), mantenimiento (el soft no se desgasta), herramientas (no deberian ser indispensables para programar), IA (esfuerzos carentes de sentido).

Dijkstra ve un programa como un manipulador abstracto de símbolos, al cual se le da un computador para volverlo concreto y poder ejecutar. El programa no es mas que una formula. Sostiene que así debería enseñarse CS, usando un lenguaje imperativo simple sobre el papel.

Entre los contrarios a su vision tiene a los matematicos (que no creen que sea posible lograr el sueno de Leibniz de tener un manipulador de simbolos alternativo al razonamiento humano), a la comunidad de negocio, de programadores compulsivos, de los ingenieros (que solo se centran en mas poder de procesamiento), los militares (plata compra seguridad), ciencias blandas (en las que la computacion juega de manera interdisciplinaria) y la educación (principal objetivo del paper).

Sus sugerencias son evitar la palabra bug (usar error, es más realista y se lava menos las manos), evitar metáforas antropomórficas, usar cálculo de predicados, especificación, imperativo simple en papel y trabajar con demostraciones formales.


Parnas[editar]

Parnas es el autor de Design for change, pero también son interesantes sus opiniones acerca de la visión de Dijsktra de CS.

A debate on teaching CS (reply)[editar]

Parnas no ve a la ingeniería como un conjunto de heurísticas simplemente, sino que defiende sus prácticas y las considera necesarias. Los ingenierios usan métodos formales, como dice Dijkstra, no se basa en heurísticas ni en metáforas antropomórficas. Considera que la programacion aun no es una ingenieria pero deberia serlo.

La ingenieria agrega metodos mas alla de los matematicos cuando estos son impracticables. El testing permite chequear que no haya habido errores en la demostracion formal, y que el modelo formal se adapte a la realidad. Testing no asegura ausencia de bugs, sino que da una probabilidad de ésta, lo cual es muy valioso.

Respecto de las radical novelties, los small changes ya se encuentran en otras ingenierías, mientras que los niveles de complejidad pueden atacarse mediante divide and conquer.

Design for change[editar]

El nombre completo del paper es Designing software for ease of extension and contraction. El objetivo es que los sistemas resultan familias de productos, que se generan a partir de favorecer la flexibilidad más que la generalidad (el poder modificar el programa fácilmente para que haga algo distinto, en lugar de que abarque demasiadas cosas simultáneamente). Se debe considerar tanto agregar como quitar funcionalidad con el mínimo impacto posible.

La familia de programas se define como tal cuando es más conveniente estudiar a los programas en su conjunto por sus cualidades en común en lugar de por separado. Se busca generar subconjuntos de problemas. La técnica propuesta es partir de las unidades mínimas (aunque no tengan sentido implementarlas por sí solas) e ir agregando cambios incrementales mínimos, así generando los subproblems.

La falta de subsets y extensiones se manifiesta de distintas maneras, entre ellas: excesiva distribucion de la informacion, cadenas de data transformation components, múltiples responsabilidades en un solo componente, ciclos en la relación usa.

Para lograr una mejor estructura, Parnas propone refinamiento de requerimientos (identificar subsets de la manera antes mencionada), information hiding (interfaces), introducir el concepto de virtual machine, generar una estructura de la relación usa apropiada. Respecto de esto último, distingue la diferencia entre usa e invoca (pueden darse independientemente, A usa a B si A requiere de la correctitud de B para funcionar), propone una estructura en layers y propone que A use a B simplemente porque resulta conveniente.

Da un ejemplo de un Address processing system, con todos sus componentes, y define una serie de primitivas simil assembler para cada componente del sistema.

Los puntos que resume como de mayor importancia son:

  • Considerar subsets y extensiones a nivel requerimientos
  • Uso del enfoque de virtual machine
  • Diferencia entre flexibilidad y generalidad del soft
  • Diferencia entre modulo, subprograma y nivel
  • Evitar duplicacion de codigo de ser necesario
  • Design orientado a subsets y extensions reduce costos de support
  • Extensiones en runtime contra extensiones a nivel SYSGEN
  • Importancia de un modelo (en el ejemplo del sistema de direcciones, jerárquico)


Brooks[editar]

Fred Brooks, autor del Mythical Man Month, software engineer, PhD en matematica aplicada.

The computer scientist as a toolsmith II[editar]

Comienza sosteniendo que el nombre de Ciencia de la Computación es incorrecto, ya que no es una ciencia puesto estas se basan en el descubrimiento de hechos y leyes, y no en la construcción, sea de sistemas, algoritmos, etc. CS es una disciplina sintética, una ingenieria de objetos abstractos e intangibles. La ingenieria de soft construye bienes para otras disciplinas. El cientifico construye para estudiar, el ingeniero estudia para construir.

El problema de considerar la computacion como una ciencia es que nos elevamos a categoria de cientificos, hablamos en un lenguaje esoterico, alejandonos de los usuarios, embrollandonos en modelos formales y abstracciones, olvidandonos de las verdaderas necesidades de los clientes. Al intentar honrar el enfoque más formal y matematico en la educacion, se aleja a los estudiantes de los verdaderos problemas.

La complejidad espanta a los matematicos que se dedican a CS, estan acostumbrados a problemas de facil planteo; mientras que a los provenientes de fisica o biologia atormenta la arbitrariedad, pues tienden a trabajar con una serie de principios basicos, que no se dan en los requerimientos de un sistema. Por lo tanto, CS no es para cientificos.

Hace un analisis de todo el esfuerzo desarrollado en AI (artificial intelligence) y considera que los resultados, salvo en dominios muy acotados y con ciertos sistemas expertos, no fueron satisfactorios, llevando a la disciplina en la direccion equivocada; aunque ciertos resultados obtenidos fueron muy utiles para la disciplina. Considera que la clave esta en sistemas de IA (intelligence amplifying), en la que el sistema asiste al usuario.

El computer scientist debe ser un toolsmith, un colaborador en trabajo interdisciplinario. Es en esta colaboracion que se testea a la disciplina en un entorno real, completo, y se la enriquece verdaderamente con las adiciones que son necesarias para tratar a estos problemas reales. Se puede demostrar el verdadero exito o fracaso del sistema.

La colaboracion tiene costos aparejados. Es necesario entender la otra disciplina con la que se trabaja, y muchas veces caer en tareas estilo soporte tecnico, pero las ventajas lo valen. La colaboracion se considera exitosa cuando los tools producidos son lo suficientemente faciles y utiles como para que un profesor senior lo use.

Finalmente considera el entretenimiento en la sociedad de consumo americana, y analiza la television, viendo que falla en los tres aspectos griegos de true, beautiful y good; considera una solucion creando mundos virtuales desde la computacion grafica salidos de la imaginacion. Como nota de color, remarca la importancia de la television como medio visual, pero tiene los problemas de ser pasivo y no social.

Design of design[editar]

El centro de la presentacion es estudiar el proceso de diseño, con el objetivo de disenar mejor, ensenar mejor y organizar mejor el proceso de design.

El modelo principal de design es el enfoque sistematico, un arbol de decisiones que realiza el designer buscando el optimo mediante un simil backtracking. El problema es que no se conoce el objetivo (goal) inicialmente, no se sabe hacia donde se debe ir, ademas de que los objetivos, goals y constraints se encuentran en constante cambio. El modelo waterfall esta simplemente mal, se basa en que lo unico que importa es funcionalidad y performance y no otros atributos de calidad.

El modelo co evolutivo es preferible, donde se testea un soft minimo con los clientes y luego se agrega funcionalidad en increments. En otras palabras, metodologia incremental (RUP, agiles). Es robusto frente a cambios en el dominio y testea pronto.

Anteriormente, los designs eran individuales, no habia colaboracion. El problema es la integridad conceptual. Se tiene un arquitecto del sistema que cumple el rol de aprobador.

Otro modelo es el de la comunidad linux, el modelo Bazaar, en la que los desarrolladores son los mismos usuarios. Lamentablemente este modelo dificilmente se puede llevar a otros escenarios.

La colaboracion y telecolaboracion constrained es la mas productiva, se debe trabajar con interfaces claras, y mantener control sobre los cambios en el design. La colaboracion ayuda para determinar necesidades de usuarios, para exploraciones conceptuales y para reviews de design, pero no para hacer el diseno detallado o conceptual. La colaboracion debe usarse solamente cuando realmente ayuda a la calidad del design, y no solamente para agilizar la schedule.

Los great designs, de todas maneras, provienen de los great designers, en un proceso casi artistico. Se deben identificar en el ambito profesional y dar las posibilidades de crecimiento y ambiente de trabajo que necesitan para desarrollarse. Deben generarse deliberadamente, manejarlos imaginativamente y protegerlos del management vacio. Para volverse un great designer es importante ejercitarse y estudiar el trabajo de otros.

No silver bullet[editar]

La dificultad principal del desarrollo de soft no esta en su implementacion sino en la especificacion, design y testing del mismo. Brooks identifica las cuatro dificultades esenciales del software:

  • Complejidad: hace que el soft sea inmanejable, y una vista que abstraiga la complejidad tambien abstrae la esencia del sistema; esto genera problemas no solamente tecnicos sino tambien de management.
  • Conformidad: el software debe cumplir con limitaciones arbitrarias impuestas por personas y reglas de negocio.
  • Modificabilidad: todo sistema es constantemente presionado a sufrir cambios luego de su salida al mercado, a diferencia de otros bienes; los cambios surgen tanto de nuevas necesidades de los usuarios como de cambios en el hard sobre el cual corre el sistema.
  • Invisibilidad: el soft es invisible, no hay manera de representarlo visualmente de una manera manejable, completa y entendible.

Los logros anteriores simplemente resolvieron dificultades accidentales: lenguajes de alto nivel (movieron la dificultad esencial a otro nivel), time sharing, entornos de desarrollo unificados.

Las hopes for the silver que considera pero refuta son: lenguajes de alto nivel, programacion orientada a objetos (resuelven solo problemas de expresion del design), sistemas expertos (proveen asistencia sin resolver nada esencial), programacion automatica (inutil fuera de dominios acotados como parsing o matematica), programacion grafica (no anda por invisibilidad), verificacion de programas (demasiado esfuerzo y requiere especificacion completa), herramientas y workstations.

Las soluciones propuestas son el buy not build y el refinamiento de requerimientos y prototipado en la etapa de desarrollo, grow dont build. En este paper Brooks vuelve sobre el concepto de los great designers.