La tesis principal de este artículo: el desarrollo de software debe verse como la materialización de ideas a través de la transformación de modelos mentales en código de programa.
El artículo describe el paradigma de materializar ideas en ingeniería de software (en inglés: RPSE: Reification as Paradigm of Software Engineering).
Versión en inglés del artículo:
RPSE: Reificación como paradigma de la ingeniería de software . La abreviatura RPSE se usa más adelante en el texto para indicar el paradigma descrito.
Definiciones clave
Antes de discutir los puntos principales de este artículo, debe ponerse de acuerdo sobre el significado de los términos básicos utilizados en él.
Ingeniería de software
Por
ingeniería de software nos referimos a la definición clásica de la disciplina de Ingeniería de Software del diccionario IEEE [1]: La ingeniería de software es "La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento de software".
Paradigma
El término
paradigma utilizado en este artículo se basa en la definición clásica del paradigma de Thomas Kuhn [2]: un paradigma es un círculo de problemas, un conjunto de conceptos, reglas y leyes generalmente aceptadas, métodos para resolver problemas en un determinado campo de la ciencia.
Más sobre paradigmasPara determinar con mayor precisión el concepto de paradigma utilizado a continuación, es útil citar dos citas bien conocidas del libro de Kuhn:
Por paradigmas, me refiero a logros científicos reconocidos que por algún tiempo le dan a la comunidad científica un modelo para plantear problemas y sus soluciones ...
Al presentar este término, quise decir que algunos ejemplos generalmente aceptados de la práctica real de la investigación científica, ejemplos que incluyen la ley, la teoría, su aplicación práctica y el equipo necesario, todos juntos nos dan modelos de los cuales surgen tradiciones específicas de investigación científica.
El dualismo de este concepto radica en el hecho de que, por un lado, el paradigma se caracteriza a través de una comunidad de especialistas que lo reconocen. Son los especialistas de cierto campo quienes determinan, crean y desarrollan sus partes. Por otro lado, el reconocimiento de cierto paradigma significa que un especialista se una a dicha comunidad.
Thomas Kuhn consideró los paradigmas científicos en su libro. Sin embargo, poco después del lanzamiento de la primera edición del libro, se hizo evidente la utilidad de utilizar este concepto en la tecnología y en varias áreas de la vida social. En este sentido, numerosas publicaciones sobre paradigmas y su cambio en la industria automotriz, la planificación urbana, el tratamiento de ciertas enfermedades, etc. comenzaron a aparecer en la literatura especial y popular.
La ingeniería de software y especialmente su componente importante: la programación, no fueron la excepción. Actualmente hay muchos paradigmas de programación competitivos. Un artículo separado en Wikipedia [3], así como revisiones tan interesantes como [4], están dedicados a su enumeración.
Sobre las limitaciones de los paradigmas de programaciónLos autores de los paradigmas descritos en [3] y [4] se concentran en una subárea estrecha de ingeniería de software, a saber, escribir programas en un lenguaje de programación particular. Creo que muchos profesionales están de acuerdo en que los proyectos de software reales no se pueden completar en el marco de uno de estos paradigmas (por ejemplo, la programación funcional).
El paradigma descrito en este artículo, por el contrario, es aplicable a una amplia variedad de áreas temáticas y fases de desarrollo de software.
Sobre las limitaciones de los paradigmas de gestión de proyectos de softwareAlgunos autores, por ejemplo, en la revisión [5], mencionan varios enfoques o modelos para organizar y realizar proyectos de software como paradigmas. Por ejemplo, se comparan modelos en cascada, modelos V o modelos ágiles. Es poco probable que estos enfoques, en contraste con los paradigmas de programación mencionados anteriormente, puedan llamarse paradigmas en el espíritu de la definición de Kuhn debido a su relativa simplicidad teórica y la falta de una amplia base teórica.
El paradigma propuesto en este artículo tampoco tiene su propia base teórica desarrollada, pero hoy sus caminos de desarrollo ya son visibles.
Materialización de ideas.
El término
materialización de ideas (engl:
reificación ) utilizado en este artículo es una extensión de la definición clásica de reificación en informática: "La reificación es el proceso mediante el cual una idea abstracta sobre un programa informático se convierte en un modelo de datos explícito u otro objeto creado en un lenguaje de programación" [6]
Más sobre el mundo de las ideas, el mundo de las cosas y la materialización.La esencia de la expansión de la definición clásica del concepto de materialización utilizado en este artículo se puede definir de la siguiente manera.
Ya en los primeros tratados filosóficos que nos han llegado, era costumbre contrastar el Ideal (el mundo de las ideas) con el Material (el mundo de las cosas).
Podemos sentir el ideal en el mejor de los casos (o pensar que lo sentimos). Un indicador de tal sentimiento del Ideal puede ser un cambio de humor o de pensamiento después de escuchar una pieza musical, un fragmento de un libro leído, etc. Por supuesto, me refiero al efecto indirecto, por ejemplo de la música, en nuestra conciencia, y no a la subordinación fisiológica primitiva del cuerpo al rugido de un concierto de rock o al ritmo de una discoteca.
Los intentos de formular nuestro sentido del Ideal como regla no conducen al éxito.
El gran poeta ruso Fedor Ivanovich Tyutchev comentó esto notablemente:
¿Cómo se expresa el corazón?
¿De qué otra manera entenderte?
¿Entenderá cómo vives?
El pensamiento pronunciado es una mentira ... [7]
Incluso las ideas prácticas, como reparaciones menores en la casa o la preparación de una nueva variación de un plato familiar, son difíciles de formular al principio. Y solo después de la deliberación o un intento de explicar a otro, la idea adquiere "contornos" cada vez más claros.
Pasamos ahora de la consideración del concepto del Ideal a la consideración del Material. Podemos sentir y registrar objetos materiales a nuestro alrededor, para distinguir cualitativamente sus propiedades. Las propiedades de muchos objetos pueden medirse objetivamente. También podemos identificar objetivamente jerarquías y otras estructuras de objetos materiales.
Para evaluar o medir (para obtener características cuantitativas) no es necesario tener un ítem. Es suficiente tener su modelo. Además, en muchas situaciones prácticamente interesantes, el modelo puede usarse sin un objeto. Los modelos pueden ser discutidos con otros. Los modelos pueden ser negociados. Los modelos pueden ser estandarizados (formalizados).
En algunas áreas de la actividad humana, la estandarización de los modelos ha llegado tan lejos que las partes (por ejemplo, pernos roscados) hechas sobre la base de un modelo estandarizado (por ejemplo, un dibujo) por diferentes personas o ametralladoras serán indistinguibles desde un punto de vista tecnológico.
Al darse cuenta de la relativa inexactitud de la definición propuesta, más adelante en este artículo dividiré el mundo de los fenómenos de nuestro mundo interno y externo
U en dos partes:
U = M + Idonde el conjunto
M consiste en sus fenómenos que pueden registrarse o medirse objetivamente (mundo material) y
yo , todo lo demás.
Si esta fórmula es aplicable a absolutamente todos los fenómenos del mundo que nos rodea es una pregunta filosófica abierta. Más adelante en este artículo, restringimos el alcance de esta fórmula al mundo de los fenómenos desde el mundo de la ingeniería de software.
O, formulándolo como una tesis: todo el conjunto de fenómenos relacionados con la ingeniería de software se puede dividir en un subconjunto del ideal y un subconjunto del material. Además, los fenómenos materiales se registran o miden en función de sus modelos.
El proceso de crear o modificar un sistema de software termina en la mayoría de los casos con la creación de uno u otro código, que, usando una computadora, se muestra en un proceso físico (un fenómeno del mundo real).
Este proceso comienza con la aparición de ciertas ideas sobre el sistema futuro en la mente de los clientes o desarrolladores. Llamaremos a estas ideas e ideas un
modelo mental .
Acerca de los modelos intermediosEn sistemas simples o con adiciones / cambios simples a sistemas grandes, el desarrollador inmediatamente escribe código o configura el sistema en función de su modelo mental. Sin embargo, en la mayoría de los casos, se crean modelos intermedios de diferente complejidad y nivel de formalización, desde una simple lista de requisitos hasta modelos formales extensos (por ejemplo, modelos UML o BPMN)
Materialización de ideas en áreas adyacentes a Ingeniería de Software.
Está claro que la definición anterior no es radicalmente nueva y se usa ampliamente (consciente o inconscientemente) en áreas de trabajo intelectual adyacentes a la programación. Por ejemplo, considere dos de estas áreas: ingeniería mecánica y matemáticas.
Estas dos áreas han estado utilizando materialización de ideas durante mucho tiempo y de manera efectiva. Tienen mucho que aprender sobre programación a este respecto.
En ingeniería mecánica, vemos un ciclo completo de materialización de ideas, desde la aparición de una idea en la cabeza del diseñador hasta su reflexión, detalles, mapeo en un modelo y, finalmente, fabricación a partir de un determinado material.
La situación es diferente en matemáticas.
Sobre la materialización de ideas en matemáticas.Se pueden encontrar hechos y consideraciones interesantes sobre la materialización de ideas en matemáticas en el párrafo 7.3 del libro [8].
El "producto final" de las matemáticas son modelos formales con propiedades estrictamente probadas.
Desde este punto de vista, la programación está en el medio. Esto se puede representar gráficamente de la siguiente manera:
Por lo tanto, las matemáticas utilizan una mayor cantidad de modelos más abstractos y casi no se aplican al campo de modelos extremadamente específicos, como los dibujos de ingeniería.
La ingeniería mecánica, por el contrario, utiliza relativamente pocos modelos abstractos, pero muchos específicos. Por ejemplo, aquellos para los cuales los objetos físicos se pueden hacer sin ambigüedades.
Desde este punto de vista, la programación está en el medio.
¿Por qué la programación está en el medio?El producto de programación final es el código de software. Y aunque, cuando se ejecuta en hardware, se asigna a objetos físicos específicos (señales eléctricas y campos de diversa naturaleza física), estos objetos son difíciles de comparar con tuercas, engranajes y carrocerías. Por otro lado, el código del programa está cerca de fórmulas matemáticas, y a veces es su reflejo directo. Sin embargo, en cualquier sistema de software real, debe tener en cuenta muchos aspectos específicos del entorno y la interacción con los usuarios u otros sistemas. Esto hace que el código del programa sea más específico que las fórmulas matemáticas.
Qué puede aprender la ingeniería de software de las áreas vecinas en términos de uso del modeloConsidere primero las matemáticas.
Multimodelo del mundo
Durante varios miles de años de su desarrollo, las matemáticas han aprendido a describir los mismos fenómenos del mundo real o imaginario en términos muy diferentes. Los antiguos griegos aprendieron a reemplazar las descripciones puramente verbales de tareas con figuras geométricas y con su ayuda a resolver problemas prácticamente importantes. Más tarde, apareció una comprensión sobre la intercambiabilidad de segmentos en el plano y los números. Luego cristalizó el concepto de una variable algebraica y la reducción de problemas geométricos a sistemas de ecuaciones algebraicas.
Hoy en día, los estudiantes de secundaria ya saben que el mismo problema se puede resolver de diferentes maneras (por ejemplo, geométrica o algebraicamente) y que el mismo modelo matemático, por ejemplo, una ecuación algebraica, describe muchos aspectos físicos, químicos, etc. Fenómenos
Morfismo de modelos y consistencia de conceptos y anotaciones.
Las matemáticas han aprendido bien no solo a describir los mismos objetos y procesos reales o imaginarios utilizando modelos de naturaleza matemática muy diferente. Un logro importante de las matemáticas es la capacidad de determinar el grado de similitud de los modelos de diferentes ramas de las matemáticas, así como la capacidad de transformarlos entre sí. Muchas soluciones innovadoras a los problemas matemáticos más importantes de los últimos años son esencialmente cadenas de evidencia separada, cada una de las cuales utiliza un aparato especializado de una sección especial de las matemáticas. En las uniones de esta evidencia altamente especializada, las matemáticas transforman hábilmente modelos de una sección de matemáticas en modelos de otra sección. En la programación, algo similar sucede ahora al compilar el código fuente de un programa y al generar código a partir de DSL (lenguaje específico de dominio) o metadatos. Pero la cultura de trabajar con modelos en el campo de la ingeniería de software está muy por detrás de la matemática.
Modelos en ingenieria mecanica
¿Y qué puede aprender la ingeniería de software de la materialización en ingeniería?
En muchas industrias, e incluso dentro de grandes preocupaciones, existen cadenas de modelos formales y semi formales coordinados. Estas cadenas terminan con modelos, sobre la base de los cuales se fabrican y montan objetos físicos: dispositivos y máquinas. Como regla, para la mayoría de los tipos de modelos intermedios, existen métodos formales para verificar su corrección (estándares técnicos). Los modelos son el principal lenguaje de comunicación de especialistas de varios perfiles en el proceso de diseño y fabricación de productos de ingeniería.
En este contexto, la situación en TI parece mucho peor. Solo en las grandes preocupaciones de TI en los últimos años se han hecho intentos para construir conjuntos comparables de modelos y procesos. Las pequeñas empresas y las nuevas empresas de TI, por regla general, no solo no han desarrollado modelos y procesos formales, sino que ni siquiera sospechan de su existencia. Esta situación está determinada actualmente por los siguientes factores:
- La falta de eficiencia de los modelos y procesos existentes.
- La falta de fama de estos modelos fuera de grandes preocupaciones
- Educación inadecuada para desarrolladores y especialmente gerentes.
- El atraso de la educación universitaria desde las necesidades reales de la ingeniería de software.
Definición y contornos del paradigma de materialización de ideas (RPSE)
Hemos identificado todos los conceptos necesarios para dar una definición básica del paradigma propuesto. Aquí esta:
El desarrollo de software es la materialización de ideas mediante la transformación de modelos mentales en código ejecutado en computadoras.
En el marco del paradigma propuesto:
- Todos los principales procesos de desarrollo de software son variantes específicas (implementaciones) del proceso de construcción de cadenas de modelos mentales y materiales. El último modelo más específico en esta cadena es, por regla general, el código del programa.
- La esencia del desarrollo de software es crear tales cadenas.
- Todos los problemas principales de la optimización del desarrollo, la reducción de su costo y la mejora de su calidad se pueden reducir a la optimización de la construcción de la cadena de modelos correspondiente.
¿Por qué materialización y no modelado?Tenga en cuenta que, aunque la definición de RPSE se refiere a la construcción de cadenas de modelos, se propone llamar al paradigma materialización en lugar de modelado. Por lo tanto, se intenta enfatizar la peculiaridad de las cadenas de modelos que se están volviendo cada vez menos abstractas / ideales y cada vez más concretas / materiales.
La definición anterior tiene sus propias características y variaciones en diferentes áreas de la ingeniería de software. Solo en un número muy pequeño de casos sucede que en la cabeza de un programador, una idea clara de cómo resolver la tarea que tiene ante sí está completamente madura, lo que luego se traduce en un código de lenguaje de programación en poco tiempo. En la mayoría de los proyectos del mundo real, el proceso de encontrar una solución y su implementación coexisten, se desarrollan en paralelo e interactúan entre sí. Es decir Los modelos mentales, el código y, a menudo, los modelos intermedios (en forma de prueba, imágenes, modelos formales como UML) crecen y cambian en paralelo, influyéndose mutuamente.
Opciones de definiciónMuy a menudo, varias personas trabajan en un problema al mismo tiempo. Cada uno de ellos tiene su propio modelo mental y, posiblemente, sus modelos intermedios y fragmentos de código.
A menudo, el código en algún lenguaje de programación está prácticamente ausente, ya que la creación de una nueva solución se reduce a la administración de máscaras de configuradores o generadores, como cuando se trabaja con herramientas de desarrollo en sistemas como SAP o WebSphere.
Las opciones para convertir código escrito manualmente o generado automáticamente en código ejecutable también se han vuelto muy diversos en estos días.
Y finalmente, el concepto mismo del procesador en el que se ejecuta el código también se ha expandido significativamente en los últimos años. Si antes se trataba de procesadores que estaban en las placas, que, a su vez, se insertaban en los cascos de las computadoras de escritorio, computadoras portátiles y bastidores de servidores, ahora este conjunto se ha ampliado con varios chips de varios tamaños integrados en teléfonos móviles, consolas de juegos, cámaras de vigilancia ". "electrodomésticos inteligentes, etc. Sin mencionar las computadoras cuánticas.
Sin embargo, RPSE, en virtud de su generalidad, es aplicable a todas las áreas enumeradas anteriormente.
¿Qué más se puede decir sobre un cierto paradigma hoy en día? ¿Es posible de alguna manera delinear con mayor precisión sus contornos?
El siguiente paso para refinar el paradigma después de intentar dar su definición principal es un intento de enumerar las principales categorías de fenómenos que afecta. Recordando la definición de Kuhn, debemos intentar enumerar los tipos de modelos que RPSE introduce y utiliza.
Los modelos RPSE se pueden dividir en tres categorías principales:
- Modelos mentales
- Código en lenguajes de programación o sus equivalentes como modelos de código ejecutable.
- Modelos intermedios.
Los menos explorados en esta tríada son los modelos mentales. ¿Qué se entiende exactamente por ellos?
Los modelos mentales son un término para las ideas que existen en la cabeza de los clientes, programadores y otros participantes en el proceso y sobre la base de las cuales finalmente surge el código ejecutable. La presencia de tales modelos es indiscutible y puede ser registrada a nivel mental, por ejemplo, por el propio programador.
En el nivel actual de desarrollo tecnológico, estos modelos no pueden ser medidos de manera confiable por instrumentos.Una de las formas que funcionan bien de arreglar y medir tales modelos es usar el medio de la idea. Obviamente, el proceso de la entrevista o similares afectan dramáticamente el modelo mental mismo. Cada uno de nosotros debe haber experimentado una situación más de una vez cuando un intento de formular un problema para consultar con un colega solo condujo a una "comprensión" y, a menudo, a una solución al problema.Las entrevistas permiten, en base a preguntas formuladas correctamente, construir modelos relativamente objetivos de complejidad variable. Los más comunes son:Modelos estructurales:- Listas con binario, enumeración, numérico, cadena y otros valores.
- Gráficas y estructuras de datos de red.
Modelos de descripción de comportamiento:- Siete modelos formales para determinar el comportamiento
- Modelos formales para determinar el comportamiento (por ejemplo, máquinas de estados finitos)
Sobre la teoría de los modelos mentales.Estos patrones son un reflejo de los patrones mentales. El grado de proximidad de los modelos mentales a los modelos reales debe tratarse con psicología o pedagogía teórica. Desafortunadamente, el autor no tiene conocimiento de un trabajo serio en esta área. (Esto no significa que dicho trabajo no exista).
¿Por qué la ingeniería de software necesita un paradigma de extremo a extremo?
La presencia de un paradigma "transversal" abre las siguientes posibilidades para los participantes que usan el paradigma del proceso de creación, modificación y uso de software:- La capacidad de todos los participantes en el proceso de usar la misma terminología.
- La capacidad de construir un proceso de principio a fin para crear nuevo software.
- La capacidad de evaluar sus parámetros de proceso, sus resultados intermedios y gestionarlo.
.
Los objetivos principales del desarrollo del paradigma.
Problemas teóricos
Como se ha señalado repetidamente, incluso en el libro de Kuhn [2], en la mayoría de los casos, los científicos están involucrados en la resolución de problemas potenciales que se están resolviendo, y es menos probable que se enfrenten a aquellos que no tienen muy claro cómo abordarlos. Pero estas son exactamente nuestras tareas. Aquí están los principales:
- Definición constructiva del concepto de modelo mental.
- Encontrar criterios constructivos para evaluar el grado de abstracción / idealidad vs. especificidad / materialidad de los modelos.
- Encontrar criterios para seleccionar candidatos para el papel de modelos intermedios y adicionales.
- Selección y desarrollo de criterios y métodos para comparar modelos de varios tipos, incluido su rastreo directo e inverso.
- Desarrollo de métodos para la transformación automatizada y automática de modelos.
Tareas prácticas
Junto con las tareas teóricas para el desarrollo e implementación del paradigma descrito en la práctica de la ingeniería de software, es necesario resolver al menos los siguientes problemas prácticos:- Creación de herramientas para: a) Extracción y fijación de modelos mentales. b) Transformación automatizada y automática de modelos mentales en modelos intermedios. c) Rastros y estimaciones de cambios en el contenido de modelos transformables
- Creación de la literatura técnica y educativa necesaria y otro material educativo medial.
- Organización de foros y conferencias sobre este tema.
Conclusión
Este artículo intenta definir el paradigma de la ingeniería de software como la materialización de ideas. La palabra para definir (y no abrir) se usa aquí no por casualidad. De hecho, los participantes en proyectos de TI llevan mucho tiempo involucrados en la creación, transformación y uso de modelos, tal vez sin darse cuenta de eso.En el sentido estricto de la definición de Kuhn, el enfoque descrito hasta ahora no puede reclamar el derecho a ser llamado paradigma, sino solo un candidato para un paradigma, ya que no cuenta con una extensa comunidad de personas que lo respalde y tampoco un sistema desarrollado de modelos interconectados. Sin embargo, quiero creer que las deficiencias se superarán pronto.Este es el primer artículo de una serie planificada de artículos. En los siguientes artículos voy a hablar sobre modelos mentales e intermedios.Literatura
1. IEEE Glosario estándar de terminología de ingeniería de software, IEEE std 610.12-1990, 1990.2. Kuhn, Thomas S. La estructura de las revoluciones científicas. 3ra ed. Chicago, IL: University of Chicago Press, 1996.3. Paradigma de programación: en.wikipedia.org/wiki/Programming_paradigm (estado - 27/08/2018)4. Peter A. Henning, Holger Vogelsang Taschenbuch Programmiersprachen. Carl Hanser Verlag GmbH & Co. KG; Auflage: 2., neu bearbeitete (5. septiembre de 2007). ISBN-13: 978-3446407442.5. Paradigmas y modelos de ingeniería de software Ensayo de tecnología de la informaciónwww.uniassignment.com/essay-samples/information-technology/software-engineering-paradigms-and-models-information-technology-essay.php (estado - 27/08/2018)6. Reificación (informática) en.wikipedia.org/wiki/Reification_ (computer_science) (estado - 27/08/2018)7. Fedor Ivanovich Tyutchev. Silentium! (Silence (lat.), 1829.8. Borovik, Alexandre. Matemáticas bajo el microscopio: notas sobre aspectos cognitivos de la práctica matemática. American Mathematical Society. ISBN-13: 978-0821847619.Ilustración: geralt