DSN_XP y Building blocks

Bloques de construcción

DSN_XP estudia bajo las perspectivas arquitectónicas del software, el concepto de modularidad, el cual se aplica para modelar escenarios de uso requeridos en el proceso de abstracción y diseño de prototipos conceptuales como soluciones por experimentación.

¿Qué es un bloque de construcción?

DSN_XP encuentra el concepto de bloques de construcción o "building blocks" mientras estudiamos TOGAF como marco de trabajo para diseños arquitectónicos empresariales.

Características

Como característica general, un bloque de construcción tiene las siguientes características genéricas:

• Un bloque de construcción es un paquete funcional definido para cumplir las necesidades del negocio a través de una organización.
• Un bloque de construcción tiene públicas sus interfaces para acceder a su funcionalidad.
• Un bloque de construcción puede interoperar con otros bloques de construcción interdependientes .
• Un buen bloque de construcción tiene las siguientes características:
• Considera su implementación y usabilidad e involucra desarrollar tecnología y estándares.
• Puede ser ensamblado desde otros bloques de construcción.
• Puede ser subensamblado con otros bloques de construcción.
• Idealmente un bloque de construcción es reutilizable y reemplazable y altamente especificado.
• Un bloque de construcción puede tener múltiples implementaciones pero con diferentes inter-dependientes bloques de construcción.

Un bloque de construcción es, por lo tanto, simplemente un paquete de funcionalidad definido para satisfacer las necesidades del negocio. La forma en que la funcionalidad, los productos y los desarrollos personalizados se ensamblan en bloques de construcción variará ampliamente entre las arquitecturas individuales. 

Bloques de construcción organizacionales

Cada organización debe decidir por sí misma qué disposición de bloques de construcción funcionales es mejor para ella. Una buena elección de bloques de construcción puede conducir a mejoras en la integración del sistema heredado, interoperabilidad y flexibilidad en la creación de nuevos sistemas y aplicaciones

DSN_XP y la noción de componentes

Sistematización por componentes

Componentización en el análisis del todo

DSN_XP parte desde la escuela estructurada, sin embargo, al investigar el paradigma orientado a objetos descubre los principios de diseño avanzado y en base a esta noción aterriza su conceptualización del proceso de abstracción mediante la noción de componente como unidad de diseño modular a las soluciones propuestas por experimentación.

Historia sobre componentes

Nuestra investigación nos puso en contacto con las ideas de MD. McIlroy y sus ideas sobre componentes software producidos en masa.

Escaneado de P. Naur y B. Randell, 

"Software Engineering, OTAN, Garmisch, Alemania, 7 al 11 de octubre de 1968", 

Componentes de software producidos en masa

MD McILROY 

RESUMEN

Componentes de software (rutinas), para ser ampliamente aplicables a diferentes máquinas y usuarios, deben estar disponibles en familias dispuestas según precisión, robustez, generalidad y desempeño espacio-temporal. 

Fuentes existentes de componentes - fabricantes, casas de software, usuarios grupos y colecciones de algoritmos - carecen de la amplitud de interés o coherencia de propósito para reunir a más de uno o dos miembros de tal familias, sin embargo, la producción de software en general se vería enormemente ayudada por la disponibilidad de espectros de rutinas de alta calidad, así como el diseño mecánico es cómplice de la existencia de familias de componentes estructurales. formas, tornillos o resistencias. 

La charla examinará los tipos de variabilidad necesaria en los componentes de software, formas de producir útiles inventarios, tipos de componentes que están maduros para dicha estandarización y métodos para instituir la producción piloto. 

La industria del software no está industrializada 

Indudablemente, producimos software con técnicas retrógradas. Nosotros sin duda obtenemos el extremo corto del palo en los enfrentamientos con el hardware y su gente porque ellos son los industriales y nosotros los artesanos. 

La producción de software aparece hoy en la escala de la industrialización en algún lugar por debajo de las industrias de la construcción más atrasadas. Creo que es lugar adecuado es considerablemente más alto y me gustaría investigar desde la perspectivas de las técnicas de producción en masa en el software. 

En la frase "técnicas de producción en masa", mi énfasis está en 'técnicas' y no en el plano de la producción en masa. Por supuesto, la producción en masa, en el sentido de replicación ilimitada de un prototipo, es trivial para el software. 

Pero ciertas ideas de la técnica industrial que pretendo son importantes. La idea de los sub ensamblajes se traslada directamente y está bien explotado. La idea de partes intercambiables corresponde aproximadamente a nuestra término 'modularidad' y se respeta esporádicamente. 

La idea de las máquinas herramientas, tiene un análogo en programas ensambladores y compiladores. Sin embargo, este frágil analogía se desmiente cuando buscamos análogos de otros símbolos tangibles de producción en masa. No existen fabricantes de piezas estándar, mucho menos catálogos de piezas estándar. No se pueden pedir piezas a particulares, especificaciones de tamaño, robustez, velocidad, capacidad, precisión o carácter a establecer.

El pináculo del software son los sistemas - sistemas con exclusión de casi todas las demás consideraciones. Componentes, dignos como en el campo del hardware, se desconoce como una rama legítima del software. Cuando nos comprometemos a escribir un compilador, comenzamos diciendo '¿Qué mecanismo de tabla construiremos?' No, '¿Qué mecanismo usaremos?' sino '¿Qué mecanismo construiremos?' 

Afirmo que hemos hecho lo suficiente como para empezar a quitar esas cosas del estante. 

Componentes de software 

Mi tesis es que la industria del software tiene una base débil y que un aspecto de esta debilidad es la ausencia de componentes de software como sub industria  Tenemos suficiente experiencia para percibir el contorno de tal sub industria 

Tengo la intención de elaborar un poco este esquema, pero sospecho que el mismo nombre `componentes de software' probablemente ya haya evocado para usted una idea de cómo podría funcionar la industria. 

También argumentaré que una industria de componentes podría ser inmensamente útil y sugerir por qué no se ha materializado. Por último, plantearé la cuestión de poner en marcha una 'planta piloto' para componentes de software. 

La característica más importante de una industria de componentes de software es que ofrecerá familias de rutinas para cualquier trabajo dado. Ningún usuario de un miembro particular de una familia debe pagar una pena, en generalidad no deseada, por el hecho de que está empleando una rutina modelo estándar. 

Por otra parte, es decir, el comprador de un componente de una familia elegirá uno a medida a sus necesidades exactas. Consultará un catálogo que ofrece rutinas en diversos grados de precisión, robustez, rendimiento espacio-temporal y generalidad. Estará seguro de que cada rutina en la familia es de alta calidad, confiable y eficiente. Esperará que la rutina sea inteligible, sin duda expresado en un lenguaje de nivel superior apropiado para el propósito del componente, aunque no necesariamente compilable instantáneamente en cualquier procesador que tenga para su máquina. 

Él esperará familias de rutinas que se construyan sobre principios racionales para que las familias encajen juntos como bloques de construcción. En resumen, debe ser capaz de considerar con seguridad componentes como cajas negras. 

Así, el constructor de un ensamblador podrá decir `Usaré un Tabla de símbolos A4 de String Associates, en tamaño 500x8' y con ello considere que está hecho. Como beneficio adicional, puede experimentar más tarde con alternativas a este opción, sin incurrir en costos extremos. 

Un ejemplo conocido

Considere la humilde rutina del seno. ¿Cuántas ofertas estándar debe tener el catalogo? De entrada uno piensa en varias dimensiones a lo largo de las cuales desea tener variabilidad: 

• Precisión, para la cual quizás diez funciones de aproximación diferentes podría ser suficiente.
• Cálculo flotante frente a fijo Argumento rangos 0-pi/2, O-2pi, también -pi/2 a pi/2, -pi a pi, -grande a +grande.
• Robustez: desde la validación sin argumentos hasta la señalización de la pérdida completa de significado, a la señalización de especificado violaciones de rango.

Tenemos aquí 10 precisiones, 2 escalas, 5 rangos y 3 robusteces. La última opción de rango y la última opción de robustez son en realidad parámetros arbitrarios especificables por el usuario. Esto nos da un inventario básico de 300 rutinas de seno. Además, uno podría esperar un catálogo completo para incluir una rutina de seno estándar de medición, que entregaría (a un precio) como resultado de cualquier precisión especificada en tiempo de ejecución. 

Otra dimensión de variabilidad, que es quizás difícil de implementar, ya que atiende a necesidades muy detalladas es:

•  Compensación de espacio-tiempo por búsqueda de tabla, ajustable en varias 'sub dimensiones': 
• (a) Tamaño de la mesa 
• (b) Cuantización de entradas (por ejemplo, se sabe que las entradas sean números enteros de grados) Otra posibilidad es 
• (c) Aprovechar las propiedades conocidas de la entrada esperada secuencias, por ejemplo, beneficiándose de la ocurrencia de llamadas sucesivas de seno y coseno del mismo argumento. 

Una empresa que se propone escribir 300 rutinas sinusoidales de una en una y con la esperanza de recuperar el volumen de ventas, sin duda quebraría. no puedo imaginar algunos de los artículos de su catálogo nunca se han pedido. Afortunadamente el costo de ofrecer tal "inventario" no tiene por qué ser casi 300 veces el costo de manteniendo una rutina. 

Existen técnicas automatizadas para generar aproximaciones de diferentes grados de precisión. varias ediciones y las técnicas de vinculación son posibles para insertar o eliminar código pertinente a cada grado de robustez. Quizás solo la dicotomía flotante versus fija en realidad necesitaría rutinas fundamentalmente diferentes. 

Así parece que el inventario básico no sería difícil de crear. El ejemplo de la rutina del seno vuelve a enfatizar un hecho interesante sobre este negocio. Es seguro afirmar que casi todos los senos son computados en punto flotante en estos días, sin embargo, eso no justificaría descartando la opción de punto fijo, porque eso bien podría tirar por la borda un gran parte del negocio en distintas rutinas hechas a medida para miríadas de pequeños control de procesos y otras aplicaciones en tiempo real en todo tipo de diferentes hardware. 

'Producción en masa' de software significa multiplicidad de lo que industria manufacturera llamaría 'modelos' o 'tamaños' en lugar de multiplicidad de repeticiones de cada uno. 

Familias parametrizadas de componentes 

Una frase contiene gran parte del secreto de hacer familias de componentes de software: 'tiempo de vinculación'. Esta es una frase 'de moda' este año, pero es más popular en teoría que en el campo. Casi el único las aplicaciones de múltiples tiempos de enlace que puedo pensar son generadores de clasificación y los llamados tipos de aplicación 'Sysgen': rellenar parámetros en las rutinas de tiempo se compilan para controlar los tamaños de las tablas y, hasta cierto punto, para controlar la elección entre varios cuerpos de código. 

El más conocido de estos, OS/360 Sysgen de IBM es realmente elaborado: las casas de software han establecido ellos mismos como expertos en este trabajo. Sysgen difiere, sin embargo, en un par de formas de lo que tengo en mente como la forma en que una industria de componentes de software podría operar. 

Primero, Sysgen crea sistemas no por construcción, sino por escisión, de un modelo intencionalmente gordo. Los tipos de ajuste en Sysgen son bastante limitados. Por ejemplo, puede asignar cantidades diferentes de espacio para un compilador, pero no puede ajustar el ancho de los campos de enlace de lista en proporción al tamaño del espacio de la lista. Una industria de componentes por otro lado, no produce componentes para su aplicación a un determinado sistema, tendría que ser flexible en más dimensiones, y tendría que proporcionar rutinas cuyos nichos en un sistema estaban menos claramente delineados. 

En segundo lugar, Sysgen no pretende reducir el código objeto o ejecutar tiempo. Por lo general, Sysgen proporciona el preajuste de los valores predeterminados, como si los listados de código de objeto son o no una salida estándar de un compilador. 

Todo el aparato de tiempo de ejecución para interrogar y ejecutar todavía hay opciones, aunque un cliente podría garantizar que nunca lo utilizó si fuera realmente rentable abstenerse. Volviendo a la rutina del seno, esto es algo así como construir una rutina de baja precisión y computar con alta precisión y luego desechar con cuidado los menos bits significativos. 

Habiendo demostrado que Sysgen no es el patrón exacto para un industria de componentes, me apresuro a añadir que en espíritu es casi la única forma en que podría funcionar una industria de componentes exitosa. Para proporcionar un racional espectro de componentes de alta calidad que un fabricante tendría que sistematizar su producción Uno no podría almacenar 300 rutinas sinusoidales a menos que todas fueran en cierto sentido instancias de unos pocos modelos, altamente parametrizados, en los que todos menos algunos parámetros estaban destinados a estar vinculados permanentemente antes de ejecutarse en el  tiempo. 

Uno podría llamar a estos parámetros de límite anticipado parámetros de 'tiempo de venta'. Muchos de los parámetros de un componente de software básico serán cualitativamente diferente de los parámetros de las rutinas que conocemos hoy. 

• Habrá al menos Elección de precisión. Tomado en un sentido generalizado precisión incluye cosas como el ancho de los caracteres y el tamaño de la dirección o el puntero campos. 
• Elección de robustez. La compensación exacta entre confiabilidad y compacidad en el espacio y el tiempo puede afectar fuertemente el rendimiento de un sistema. 
• Este aspecto de la parametrización y el siguiente probablemente clasificarán primero en importancia para los clientes. 
• Elección de Generalidad. El grado en que se dejan los parámetros ajustables en tiempo de ejecución. 
• Elección del comportamiento espacio-temporal. 
• Elección del algoritmo. En las rutinas numéricas, como lo ejemplifica aquellos en el MCCA, esta elección ya está bastante bien atendida. Para rutinas no numéricas, sin embargo, esta elección por lo general se debe decidir en base del folclore. Como algunos algoritmos no numéricos suelen ser espectacularmente inadecuados para un hardware en particular, una amplia variedad es quizás aún más imperativo para ellos. 
• Elección de interfaces. Rutinas que utilizan varios insumos y rinden varias salidas deben venir en una variedad de estilos de interfaz. Por ejemplo, estos diferentes estilos de comunicación de salidas de error deben estar disponibles: 
• Devoluciones alternativas 
• Devolución de código de error 
• Llamar a un controlador de errores 
• Señal (en el sentido de PL/I) 

Otro ejemplo de la variabilidad de la interfaz es que las dimensiones de la matriz para los parámetros deben ser cobrables en formas características de varios de los principales lenguajes de programación. 

• Elección del método de acceso. Diferentes accesos de almacenamiento se deben apoyar las disciplinas, para que un cliente pueda elegir la mejor ajustándose a sus requisitos de velocidad y espacio, las capacidades de direccionamiento de su hardware, o su gusto en el estilo de programación. 
• Elección de estructuras de datos. Ya tocado bajo el tema de interfaces, este delicado asunto requiere una cuidadosa planificación para que los algoritmos sean tan insensibles a los cambios en la estructura de datos como sea posible. Cuando estructuras radicalmente diferentes son útiles para problemas similares (por ejemplo, matriz de incidencia y representaciones de lista para gráficos), varios algoritmos pueden ser requeridos. 
• Áreas de aplicación. Tenemos que empezar a pensar en pequeño. A pesar de los anuncios del efecto de que los compiladores completos están disponibles en una base 'prácticamente lista para usar', no creo que estemos listos para hacer sub ensamblajes de software de eso tamaño en base a la producción. Los componentes más prometedores para empezar son estas: 
• Rutinas de aproximación numérica. Estos se entienden muy bien, y las dimensiones de la variabilidad de estas rutinas también son bastante claras. 
• Ciertos otros procesos numéricos no son tan buenos candidatos; buscadores de raíces y las rutinas de ecuaciones diferenciales, por ejemplo, siguen siendo asuntos para investigación, no producción en masa. 
• Todavía otros procesos 'numéricos', tales como rutinas de inversión de matriz, son simplemente patrones lógicos para secuenciar que están casi desprovistos de variabilidad. Estos pueden ser vendidos por componentes industria en aras de la exhaustividad, pero también pueden tomarse de el MCCA. 
• Conversión de entrada-salida. Las piezas básicas aquí son radix. rutinas de conversión, algunas rutinas de escaneo triviales y crackers de formato. A partir de una colección de familias bien diseñada, debería ser posible fabricar cualquier cosa, desde un simple paquete octal en línea para un pequeño computadora de laboratorio a un paquete de conversión Fortran IV. la variabilidad aquí, especialmente en materia de precisión y robustez es sustancial. Evidentemente, se necesitará una planificación considerable para obtener suficiente flexibilidad sin tener demasiadas rutinas básicamente diferentes. 
• Geometría bidimensional y tridimensional. Las aplicaciones de este tipo van en una clase muy amplia de máquinas y hoy por lo general se mantienen propiedad. Uno puede enumerar fácilmente unas pocas docenas de rutinas fundamentales para geometría. La dimensión pegajosa de la variabilidad aquí está en las estructuras de datos. Según qué aspecto de las figuras geométricas se considera fundamental - puntos, superficies, topología, etc. - se realizarán rutinas muy diferentes requerido. Una línea completa debe atender a diferentes abstractos estructuras y también ser insensible a las estructuras concretas. 
• Procesamiento de texto. Nadie usa los analizadores generales de otra persona o escáneres de hoy, en parte porque una rutina lo suficientemente general para cumplir con cualquier necesidades individuales particulares probablemente tiene tanta generalidad como para ser ineficiente. El principio de tiempos de vinculación variables podría ser muy fructíferamente explotado aquí. Entre el corpus de rutinas en esta área serían generadores de diccionarios y rutinas de búsqueda, escáneres y resultados sintetizadores, todos capaces de trabajar en flujos continuos, en la unidad registros, y varios formatos de listas enlazadas, y bajo modos de acceso adecuados a varios hardware. 
• Administración de almacenamiento. La asignación dinámica de almacenamiento es un tema popular para su publicación, sobre los cuales aún no existe suficiente conocimiento real. Antes construyendo una línea de productos para esta aplicación, uno debería hacer comparación considerable de esquemas conocidos que funcionan en entornos prácticos. Sin embargo, la gestión del almacenamiento es muy importante, especialmente para la manipulación de texto, que debería ser un candidato temprano. 

El mercado 

Viniendo de uno de los usuarios más sofisticados de máquinas, creo tener una amplia oportunidad de ver el trágico desperdicio de la escritura de técnicas de software actual En Bell Telephone Laboratories tenemos alrededor de 100 máquinas de propósito general de una docena de fabricantes. Aunque muchos están dedicados a aplicaciones especiales, una enorme cantidad de software similar debe escribirse para cada uno. Todos necesitan conversión de entrada-salida, a veces solo caracteres alfabéticos individuales y números octales, algunos Fortran completos estilo E/S. Todos necesitan ensambladores y podrían usar macro procesadores, aunque no compilando necesariamente en el mismo hardware. Muchos necesitan números básicos rutinas o generadores de secuencias. La mayoría quiere velocidad a toda costa, unos pocos quieren robustez considerable. 

No hace falta decir que gran parte de esta programación de soporte se realiza sub óptimamente y con una severa sanción científica de desviar a los propietarios de máquinas de sus investigaciones centrales. Para construir estos sistemas de componentes de clase alta tendríamos que rodear cada una de unas 50 máquinas con una camarilla permanente de especialistas en software. Si fuera posible rápidamente y con confianza para aprovechar lo mejor que hay en apoyo algoritmos, un equipo de consultores de software podría guiar a los científicos hacia soluciones rápidas y mejoradas para el apoyo más mundano problemas de sus sistemas personales. 

Al describir la forma en que los laboratorios Bell podrían usar los componentes de software, he intentado describir el mercado en microcosmos. Laboratorios Bell no es el típico de los usuarios de computadoras. como una investigación y establecimiento de desarrollo, por fuerza debe pasar más de su tiempo afilando sus herramientas y usándolas menos que una computadora de producción de tienda. Pero es exactamente ese mercado orientado a los sistemas hacia el cual un la industria de componentes estaría dirigida. 

El mercado estaría formado por especialistas en construcción de sistemas, que serían capaz de usar partes probadas para todas las partes más comunes de sus sistemas. Los mayores clientes de todos serían los fabricantes. (Si no fuera así, sería una señal segura de que los productos ofrecidos no eran suficientemente buenos).  El consumidor final de sistemas basados ​​en componentes debería ver una confiabilidad y un rendimiento considerablemente mejorados, ya que sería ser posible gastar proporcionalmente más esfuerzo en partes críticas de sistemas, y también para evitar las fallas ahora prevalentes de loas más mundanas partes de sistemas, que han sido especificadas por expertos, y luego han sido escritas por hackers. 

Proveedores actuales 

Puede preguntar, bueno, ¿no tenemos exactamente lo que he estado pidiendo ya en varios lugares? ¿Qué pasa con los algoritmos recopilados por el CACM? Qué sobre los grupos de usuarios? ¿Qué pasa con las casas de software? Y que hay con los enormes paquetes de software de los fabricantes? Ninguna de estas fuentes satisface exactamente el propósito que tengo en mente, ni creo que sea probable que ninguno de ellos realmente evolucione a llenar la necesidad. 

Los algoritmos CACM, en un campo limitado, quizás se acerquen más a ser un producto listo para usar generalmente disponible que el de productos comerciales, pero adolecen de fuertes carencias. Primero son una recopilación de contribuciones personales, a menudo estilísticamente variadas. Ellas no encajan en ningún plan, pues el editor sólo puede publicar lo que los autores voluntarios. 

En segundo lugar, al estar efectivamente ligado a un solo lenguaje compilable, logran la arbitrariedad, pero por fuerza deben evitar por completo algoritmos para los que Algol no es adecuado o utilizar circunloquios para abominable que el producto sólo pueda ser considerado como un juguete. 

Tercero, como un adjunto de una sociedad científica, la sección de algoritmos del CACM no puede ocuparse de gran número de variantes del mismo algoritmo. 

La variabilidad sólo puede ser proporcionada por costosos parámetros de tiempo de ejecución. Creo que los grupos de usuarios se pueden descartar sumariamente, y los perdonaré, una arenga sobre sus deficiencias. 

Las casas de software generalmente no tienen los recursos para desarrollar sus propias líneas de productos; su trabajo debe ser financiado, y la gran financiación generalmente solo se puede obtener para productos grandes. Entonces vemos que el software alberga sistemas de suministro, o programas muy grandes, como compiladores Fortran, paquetes de programación lineal o diagramas de flujo. No espero ver ninguna casa de software que anuncia una familia de funciones de Bessel o tabulación de símbolos con rutinas en el futuro predecible. 

Los fabricantes producen cantidades increíbles de software. En general, como este es el material que más se usa, es del todo bastante confiable, un buen gris conservador, que no incluye la mejor rutina para cualquier cosa, pero eso es mejor de lo que el programador promedio es probable que haga. Como escuchamos ayer, los fabricantes tienden a ser bastante pragmáticos en su elección de métodos. Golpean en gran medida razonable equilibrios entre generalidad y especificidad y rara vez utilizan absolutamente enfoques inapropiados en cualquier componente de software individual. Pero el motivo de lucro de donde brotan estas virtudes también engendra su principal cuelgue de los sistemas ahora. 

El sistema es lo primero; los componentes son simplemente incidentes molestos. Fuera de estas cintas de correr no espero ver aparecer componentes de alta clase de utilidad general. 

Una fábrica de componentes 

Habiendo demostrado que es poco probable que nazca entre los tradicionales proveedores de software Paso ahora a la cuestión de cómo un componente la industria podría comenzar. Hay un tamaño crítico que la industria debe alcanzar antes de que sea útil. Nuestro proveedor de 300 rutinas sinusoidales probablemente iría a la quiebra esperando clientes si eso es todo lo que ofreció, solo como un empresa de electrónica que vende módulos de circuito para un solo propósito habría problemas en el mercado. 

Tomará algún tiempo desarrollar un inventario útil, y durante que se necesitará tiempo, dinero y talento. La primera fuente de apoyo que viene a la mente es gubernamental, tal vez canalizado a través de corporaciones de investigación semi-independientes. Parece que el hecho de que el gobierno es el mayor usuario y propietario de las máquinas, debe proporcionar incentivo suficiente para tal empresa que tiene la promesa de hacer una mejora general en el desarrollo de sistemas. 

Incluso antes de fundar una planta piloto, sería prudente tener técnicas demostradas para crear una familia parametrizada de rutinas para un par de propósitos familiares, digamos una rutina sinusoidal y un módulo de E/S de Fortran. Se debe demostrar que estas rutinas se pueden usar como reemplazos en una serie de entornos radicalmente diferentes. Esta demostración podría realizarse por una agencia gubernamental, un contratista de investigación o por un gran usuario, pero ciertamente sin la expectativa de una recompensa inmediata. 

La orientación industrial de una planta piloto debe ser constantemente tomada en cuenta. Creo que todo el proyecto es improbable para la investigación universitaria. Se necesitará talento de calibre de la investigación para hacer el trabajo con economía y confiabilidad satisfactorias, pero el espíritu guía de la  empresa debe estar orientado a la producción. La capacidad de producir miembros de una familia no es suficiente. Distribución, catalogación y planificación racional de la combinación de familias de productos será a la larga más importante para el éxito de la empresa que será el logro puramente técnico. 

El personal de una planta piloto debe parecerse al personal de muchos grandes proyectos de software, con las masas de codificadores eliminados. Serán necesarias una muy buena planificación y una supervisión fuertemente centrada en el producto. Ahí habrá quizás más sabor de investigación incluido de lo que podría estar en un ordinario proyecto de software, porque el nivel de programación aquí será más abstracto: gran parte del trabajo estará en crear generadores de rutinas en lugar de hacer las propias rutinas. 

Las pruebas tendrán que hacerse de varias maneras. Cada miembro de una familia, sin duda, será probado contra algún modelo muy general para asegurar que el enlace de tiempo de venta no cause degradación sobre el enlace de tiempo de ejecución. Probar el producto implicará transliterar las rutinas para que encajen en el hardware. Al monitorear la facilidad con la que las personas relativamente jóvenes hacen prueba del producto, los gerentes podrían estimar la claridad del producto, que es importante para predecir la aceptación del cliente. 

La distribución será un problema delicado. La entrega rápida bien puede ser el estimulante de ventas más valioso de un proveedor de componentes. uno al instante piensa en distribución por enlace de comunicación. Entonces incluso los componentes muy pequeños pueden comercializarse de forma rentable. El catálogo será igualmente importante. Un documento completo y físicamente condensado como el El catálogo de Sears-Roebuck es lo que me gustaría tener para mí si fuera de compras de componentes. 

Una vez que se estableció un corpus de líneas de productos y las ganancias potencial demostrado, esperaría que las casas de software se hicieran cargo del industria. De hecho, si se necesitara apoyo externo durante mucho tiempo, yo diría que la aventura había fracasado (y trato de olvidar que alguna vez me lo había propuesto). 

Tocando los estándares 

No creo que una industria de componentes pueda estandarizarse en existencia. Como es habitual con los estándares, sería precipitado estandarizar antes de que tengamos los modelos. Estándares lingüísticos, siempre que sean flexibles lo suficiente para no impedir modos útiles de cálculo, por supuesto será útil. Muy pronto uno esperaría que una industria de componentes converja en algunos tipos estándar de interfaz. La experiencia sin duda revelará otros estándares para ser útiles, por ejemplo, tamaños de palabras populares y juegos de caracteres, pero de nuevo, a menos que los estándares abarquen la mayor parte de los sistemas de software (como distinguirse de los usuarios), la industria de componentes morirá por falta de mercado. 

Resumen 

Me gustaría ver que los componentes se conviertan en una rama digna de la Ingeniería de software. Me gustaría ver catálogos estándar de rutinas, clasificados por precisión, robustez, desempeño espacio-temporal, límites de tamaño, y el tiempo de enlace de los parámetros. Me gustaría aplicar rutinas en el catálogo a cualquiera de una gran clase de máquinas a menudo muy diferentes, sin demasiado dolor. No insisto en que pueda compilar una rutina particular directamente, pero insisto en que la transliteración sea esencialmente directa. No quiero que la rutina sea intrínsecamente ineficiente debido a que se expresa en términos independientes de la máquina. quiero tener confianza en la calidad de las rutinas. Quiero los diferentes tipos de rutina en el catálogo que son similares en propósito para ser diseñados uniformemente, de modo que dos rutinas similares deben estar disponibles con similar opciones y dos opciones de la misma rutina deben ser intercambiables en situaciones indiferentes a esa opción. 

Lo que acabo de pedir es simplemente industrialismo, con términos de programación sustituidos por algunos de los términos más orientados mecánicamente apropiados para la producción en masa. Creo que hay áreas considerables de software listo, si no atrasado, para este enfoque.

DISCUSIÓN 

Ross: Lo que ha estado hablando Mcllroy son cosas que hemos estado jugando con por ejemplo, en el sistema DEA tenemos los llamados característica-característica. Esto nos permite sortear el problema de los cargadores. Nosotros siempre podemos incrustar nuestro sistema en cualquier sistema de carga disponible, el problema de la vinculación está muy entrelazado allí, por lo que estamos a merced del medio ambiente. Un ejemplo es un sistema generalizado de notificación de alarmas en que puede informar cosas sobre la marcha o sacar todo tipo de información dinámica. El mismo sistema da 14 versiones diferentes del manejo de alarmas. Me parece que la macro-expansión es el punto de partida para algunos de los problemas técnicos que hay que resolver para poner estos ideas muy importantes en la práctica. 

McIlroy: Parece que ha automatizado algunos tipos de variabilidad que yo pensaba eran más especulativos. 

Opler: El sistema TOOL producido hace seis años para Honeywell fue complementaria a la descrita por McIlroy. Tiene facilidades para poner cosas juntas, pero no proporcionó los componentes. La dificultad fue que produjimos componentes rudimentarios para ver cómo funcionaría el trabajo del sistema, pero las personas para quienes desarrollamos el sistema no entendían que iban a proporcionar sus propios componentes, por lo que simplemente se quejaron que el sistema no era bueno. Pero estoy muy entusiasmado con lo que usted sugiere. 

Perlis: El sistema GP de la primera Univac era un sistema para desarrollar software personalizado mientras permanezca en esa máquina. Los autores de este sistema me preguntó: ¿Cómo se generalizaría esto a otras computadoras? No sabían cómo hacerlo en ese momento, y supongo que no ha sido hecho. Tengo una pregunta para Mcllroy. No te escuché mencionar qué me es la más obvia de las parametrizaciones, a saber, construir sistemas de manejo de archivos de datos comerciales. Entiendo que Informática tiene uno fuera de lo cual todo el mundo dice que está bien, pero -. Esto parece ser una típica actitud hacia los sistemas parametrizados. 

McIlroy: Mi razón para dejar eso fuera es que esta es que no se sobre ello. 

Perlis: Probablemente sería una de las áreas más fáciles, y una con la mayoría de los clientes Antes de que d'Agapeyeff hable, tengo otro comentario. [Risas]. Los especialistas en cada parte del software tienen una curiosa visión de el mundo: Todas las partes del software excepto la suya son simples y fáciles parametrizado; la suya es totalmente variable. 

d'Agapeyeff: No hay paquete que haya recibido más atención por parte de los fabricantes que el manejo de archivos. Sin embargo, apenas existe un sistema importante, sé que eso se basa únicamente en el sistema estándar producido por el fabricante. Es extremadamente difícil construir este software en un manera que sea eficiente, confiable y conveniente para todos los sistemas y donde la naturaleza del paquete no se impone al usuario. La razón es que no puedes atomizarlo. Cuando el trabajo ha tenido éxito, tiende a preocuparse por los paquetes que tienen alguna estructura. Cuando llegas a pequeñas unidades no es económico hacerlos aplicables a un gran conjunto de usuarios, usando diferentes máquinas con diferentes idiomas, y hacer todo el trabajo de encuadernación, de modo que no se tarde el doble en descubrir cómo cárgalo. Los problemas con Sysgen no se pueden prescindir, son inherentes. Pero, ¿por qué necesitamos sacar átomos del estante? Lo que tu quieres es una descripción que se puede entender, porque el tiempo necesario para codificarlo en su propio sistema es realmente muy pequeño. De esa manera puedes insertar tus propios matices. El primer paso en tu dirección debería ser mejor descripciones 

Endres: Dos notas de precaución: descartaste los algoritmos en el Comm. ACM en parte porque están escritos en lenguaje de alto nivel, así que entiende que te refieres a rutinas escritas en un lenguaje más orientado a lenguaje de máquina. Creo que simplifica demasiado el problema de la transliteración o asumes un estándar de máquina de facto? Segunda pregunta: Usted se refiere a la problemática de Sysgen, donde recortas piezas de una gran colección. Si en cambio, quieres armar sistemas, creo que los problemas de Sysgen pueden convertirse en una dimensión más grande. ¿Quién asumirá este costo y mantendrá el ¿sistema? 

McIlroy: Los algoritmos en el Comm. ACM usa efectivamente un lenguaje, que es adecuado para una clase particular de aplicaciones. esto puede no ser el correcto para cosas como paquetes de entrada/salida. En la segunda pregunta: Estoy convencido, con usted, de que al principio será más difícil construir sistemas por acreción, en lugar de por escisión. Las personas que construyen los componentes tendrán que ser constructores de sistemas calificados, no comunes y corrientes usuarios.

Kjeldaas: Estoy totalmente a favor de esta idea. Creo que los ejemplos mencionados son dentro del estado del arte. Sin embargo, más adelante querremos macros que necesiten parámetros que tienen relaciones más intrincadas, por ejemplo, si desea algunos relación funcional entre los parámetros. Necesitaremos algo de lenguaje para describir los parámetros. Otro punto: la documentación también puede ser incluido en este. Cuando le hayas dado los parámetros al programa, puede dar los mismos parámetros a la documentación, y la documentación para el uso particular se puede producir automáticamente alimentación para diferentes máquinas que plantearán grandes problemas, que necesitan investigación. 

Kolence: ¿Puedo enfatizar un punto: Mcllroy afirmó que el la industrialización tiene que ver con el diseño, no con la replicación proceso. Estamos interesados ​​en un problema de diseño en masa. al hablar de la implementación de componentes de software, todo el concepto de cómo uno se ignora el software de diseños. Sin embargo, esto es algo clave. 

Naur: Lo que me gusta de esto es el énfasis en los principios básicos de construcción, y en el hecho de que los grandes sistemas están hechos de componentes más pequeños. Este tiene una fuerte influencia en la educación. Lo que queremos en la educación, particularmente en el nivel más elemental, es empezar a adoctrinar el conocimiento de los componentes de nuestros sistemas. Una comparación con nuestros colegas de hardware es relevante. ¿Por qué tienen mucho más éxito que nosotros? Yo creo que una fuerte razón es que hay un campo bien establecido de ingeniería electrónica, que los jóvenes empiecen a aprender sobre la tecnología de la Ley de Ohm a la edad de catorce años o por ahí, y que las resistencias y similares son componentes conocidos con características que han sido expuestas en duración en el primer nivel de educación. Los principios componentes de nuestro Los sistemas deben clasificarse de tal forma que puedan ponerse en educación elemental. 

Gill: Dos puntos: primero sobre la cuestión del catálogo. espero que podamos hacer mejor que el catálogo de Sears-Roebuck. Seguramente lo que queremos es un catálogo conversacional computarizado. Segundo punto: ¿qué es lo que Ud. realmente vendes cuando vendes una pieza de software, ¿qué hace exactamente un ¿Se parece el contrato de software? 

Barton: La charla de Mcllroy estuvo tan bien hecha que me tomó cerca de tres minutos para darse cuenta de lo que está mal con esta idea. Otro cumplido: si yo estuviera ejecutando Intergalactic Software, contrataría a Mcllroy como gerente. Ahora el punto serio: Durante los últimos años he enseñado el ACM Curso 'Estructuras de información' y usó el juego para no dejar que nadie codificara o escribir cualquier cosa en cualquier lenguaje de programación en absoluto. acabamos de pensar sobre representaciones de datos. Si de esta manera logras que la gente se deshaga de la costumbre de escribir código de inmediato, de pensar procedimentalmente, luego algunos muy diferentes puntos de vista sobre las representaciones de la información vienen a la vista. En McIlroy´s hablar de componentes estándar que tienen que ver con estructuras de datos tengo la sintiendo que esto no es un problema para sacar de las universidades todavía. Ahora una visión herética: no creo que hayamos suavizado las cosas lo suficiente en máquinas todavía. No creo que lleguemos a ninguna parte tratando de cuantificar el compensación de espacio-tiempo a menos que descartemos tamaños de palabra fijos, caracteres fijos tamaños, representaciones numéricas fijas, todo junto en máquinas. Sin que estos, lo propuesto por Mcllroy demostrará ser no del todo práctico. 

Fraser: Deseo discrepar con d'Agapeyeff. creo que será posible parametrizar la representación de datos y la gestión de archivos. A partir de una experiencia particular del sistema de archivos aprendí dos lecciones: primero, hay una gran cantidad de parámetros, para ser seleccionados de forma no excluyente manera. La selección de los parámetros es tan complicada que es apropiado poner un compilador en la parte delantera de la distribución de software mecanismo. Quizás estemos hablando más de compiladores de lo que creemos. En cuanto a los catálogos: en Inglaterra, un catálogo de materiales de construcción es un catálogo muy ad hoc, tienes bridas a la izquierda para ir con la mano izquierda puertas, etc. Creo que es probable que el catálogo sea ad hoc en esa naturaleza, en lugar de como un catálogo de electrónica donde los componentes son más intercambiable. El segundo problema es la cuestión de escribir este compilador. Nuestro generador de gestión de archivos efectivamente generaría una gran cantidad de diferentes sistemas de gestión de archivos, muy por encima de los 500 que mencionó Mcllroy. No había duda de probar todos estos. Nosotros produjo una solución ad hoc a este problema, pero hasta que se realicen más investigaciones hecho sobre este problema, no creo que la sugerencia de McIlroy sea realista. 

Graham: Hablaré de un adjunto a esta idea. En Multics usamos un subconjunto de PL/I, aunque PL/I es bastante inadecuado, en que el primitivo Las operaciones del lenguaje no son realmente adecuadas para el diseño del sistema. En Multics realiza una gran cantidad de administración de directorios, operaciones simples como agregar y borrar entradas, pero en un directorio complicado. Con un nivel superior lenguaje con estas operaciones como primitivas uno podría fácilmente escribir un nuevo sistema. Al simular las primitivas, se podría probar el desempeño del sistema antes de construirlo realmente. Si uno tuviera el catálogo de Mcllroy almacenado en el sistema, con los tiempos de muchas rutinas, luego la simulación hacer una copia de seguridad de este lenguaje de nivel superior podría, de hecho, referirse al catálogo y use los tiempos reales para una nueva máquina que esta compañía ofreció y obtener tiempos realistas. Otro punto, deseo refutar la sugerencia de McIlroy que esto no es para universidades; Creo que es. hay muy dificiles problemas en esta área, como la parametrización de rutinas más sofisticadas, en particular los del área del compilador. Estos son aptos para las universidades. 

Bemer: Estoy de acuerdo en que el método del catálogo no es adecuado. nosotros no tener los descriptores para ir a buscar. No hay nada tan mal descrito. como formatos de datos, no hay estándares y no hay señales de que estén siendo desarrollado. Antes de que tengamos estos, no tendremos los componentes. 

McIlroy: Es por esa razón que ahora sugiero el tipo Sears-Roebuck. La búsqueda en línea puede no ser la respuesta correcta todavía.