🤳🏻 👨🏽‍✈️ 🧝 Programação é a materialização de idéias. 🚽 🏄 🍄

A tese principal deste artigo: O desenvolvimento de software deve ser considerado como a materialização de idéias através da transformação de modelos mentais em código de programa.
O artigo descreve o paradigma de materializar idéias em engenharia de software (engl .: RPSE: Reification as Paradigm of Software Engineering).

Versão em inglês do artigo: RPSE: Reificação como paradigma de engenharia de software . A abreviação RPSE é usada posteriormente no texto para indicar o paradigma descrito.

Definições-chave

Antes de discutir os pontos principais deste artigo, você precisa concordar com o significado dos termos básicos usados nele.

Engenharia de software

Por engenharia de software , entendemos a definição clássica da disciplina Engenharia de Software do dicionário IEEE [1]: Engenharia de software é "A aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção de software".

Paradigma

O termo paradigma usado neste artigo baseia-se na definição clássica do paradigma de Thomas Kuhn [2]: Um paradigma é um círculo de problemas, um conjunto de conceitos, regras e leis geralmente aceitas, métodos para resolver problemas em um determinado campo da ciência.

Mais sobre paradigmas

Para determinar com mais precisão o conceito de paradigma usado abaixo, é útil citar duas citações conhecidas do livro de Kuhn:

Por paradigmas, quero dizer conquistas científicas reconhecidas que, por algum tempo, dão à comunidade científica um modelo para apresentar problemas e suas soluções ...

Introduzindo esse termo, eu quis dizer que alguns exemplos geralmente aceitos da prática real da pesquisa científica - exemplos que incluem direito, teoria, sua aplicação prática e o equipamento necessário - todos juntos nos dão modelos a partir dos quais surgem tradições específicas da pesquisa científica.

O dualismo desse conceito reside no fato de que, por um lado, o paradigma é caracterizado por uma comunidade de especialistas que o reconhecem. São os especialistas de um determinado campo que determinam, criam e desenvolvem suas partes. Por outro lado, o reconhecimento de um certo paradigma significa que um especialista se junta a essa comunidade.

Thomas Kuhn considerou paradigmas científicos em seu livro. No entanto, logo após o lançamento da primeira edição do livro, a utilidade de usar esse conceito em tecnologia e em várias áreas da vida social tornou-se aparente. Nesse sentido, numerosas publicações sobre paradigmas e suas mudanças na indústria automotiva, planejamento urbano, tratamento de certas doenças etc. começaram a aparecer na literatura especial e popular.

A engenharia de software e, especialmente, seu componente importante - programação, não foram exceção. Atualmente, existem muitos paradigmas de programação concorrentes. Um artigo separado na Wikipedia [3], bem como críticas interessantes como [4], são dedicadas à sua enumeração.

Sobre as limitações dos paradigmas de programação

Os autores dos paradigmas descritos em [3] e [4] concentram-se em uma subárea estreita da engenharia de software, a saber, a escrita de programas em uma linguagem de programação específica. Eu acho que muitos profissionais concordam que projetos de software reais não podem ser concluídos dentro da estrutura de apenas um desses paradigmas (por exemplo, programação funcional).

O paradigma descrito neste artigo, por outro lado, é aplicável a uma ampla variedade de áreas e fases do desenvolvimento de software.

Sobre as limitações dos paradigmas de gerenciamento de projetos de software

Alguns autores, por exemplo, na revisão [5], nomeiam várias abordagens ou modelos para organizar e conduzir projetos de software como paradigmas. Por exemplo, modelos em cascata, modelos V ou modelos ágeis são comparados. É improvável que essas abordagens, em contraste com os paradigmas de programação mencionados acima, possam ser chamadas de paradigmas no espírito da definição de Kuhn, devido à sua relativa simplicidade teórica e à falta de uma ampla base teórica.

O paradigma proposto neste artigo também ainda não possui base teórica desenvolvida, mas hoje seus caminhos de desenvolvimento já são visíveis.

Materialização de idéias

O termo materialização de idéias (engl: reification ) usado neste artigo é uma extensão da definição clássica de reificação em ciência da computação: “Reificação é o processo pelo qual uma idéia abstrata sobre um programa de computador é transformada em um modelo de dados explícito ou outro objeto criado em uma linguagem de programação” [6]

Mais sobre o mundo das idéias, o mundo das coisas e a materialização

A essência da expansão da definição clássica do conceito de materialização usada neste artigo pode ser definida da seguinte forma.

Já nos primeiros folhetos filosóficos que chegaram até nós, era costume contrastar o Ideal (o mundo das idéias) com o Material (o mundo das coisas).

Podemos sentir o ideal na melhor das hipóteses (ou pensar que o sentimos). Um indicador desse sentimento do Ideal pode ser uma mudança de humor ou uma linha de pensamento depois de ouvir uma peça musical, um fragmento lido de um livro etc. É claro, quero dizer o efeito indireto, por exemplo, da música, em nossa consciência, e não a subordinação fisiológica primitiva do corpo ao rugido de um show de rock ou ao ritmo de uma discoteca.

Tentativas de formular nosso senso do Ideal como regra não levam ao sucesso.
O grande poeta russo Fedor Ivanovich Tyutchev observou isso notavelmente:

Como o coração se expressa?
Como mais para entender você?
Ele vai entender como você mora?
O pensamento pronunciado é uma mentira ... [7]

Mesmo idéias práticas, como pequenos reparos em casa ou preparar uma nova variação de um prato familiar, são difíceis de formular no início. E somente após deliberação ou tentativa de explicação para outra pessoa, a ideia assume "contornos" cada vez mais claros.

Passamos agora da consideração do conceito do Ideal para a consideração do Material. Podemos sentir e registrar objetos materiais ao nosso redor, para distinguir qualitativamente suas propriedades. As propriedades de muitos objetos podem ser medidas objetivamente. Também podemos identificar objetivamente hierarquias e outras estruturas de objetos materiais.

Para avaliar ou medir (para obter características quantitativas), não é necessário ter um item. Basta ter o seu modelo. Além disso, em muitas situações praticamente interessantes, o modelo pode ser usado sem um objeto. Modelos podem ser discutidos com outras pessoas. Modelos podem ser negociados. Os modelos podem ser padronizados (formalizados).

Em algumas áreas da atividade humana, a padronização de modelos foi tão longe que as peças (por exemplo, parafusos roscados) feitas com base em um modelo padronizado (por exemplo, um desenho) por diferentes pessoas ou metralhadoras serão indistinguíveis do ponto de vista tecnológico.

Percebendo a relativa imprecisão da definição proposta, mais adiante neste artigo, dividirei o mundo dos fenômenos de nosso mundo interno e externo U em duas partes:

U = M + I

onde o conjunto M consiste em seus fenômenos que podem ser objetivamente registrados ou medidos (mundo material) e I - tudo o resto.

Se esta fórmula é aplicável a absolutamente todos os fenômenos do mundo ao nosso redor é uma questão filosófica aberta. Mais adiante neste artigo, restringimos o escopo dessa fórmula ao mundo dos fenômenos do mundo da engenharia de software.

Ou, formulando-o como uma tese: todo o conjunto de fenômenos relacionados à engenharia de software pode ser dividido em um subconjunto do ideal e um subconjunto do material. Além disso, os fenômenos materiais são registrados ou medidos com base em seus modelos.
O processo de criação ou modificação de um sistema de software termina na maioria dos casos com a criação de um ou outro código, que, usando um computador, é exibido em um processo físico (um fenômeno do mundo real).

Esse processo começa com o surgimento de certas idéias sobre o futuro sistema nas mentes dos clientes ou desenvolvedores. Vamos chamar essas idéias e idéias de modelo mental .

Sobre modelos intermediários

Em sistemas simples ou com simples adições / alterações em sistemas grandes, o desenvolvedor imediatamente escreve o código ou configura o sistema com base em seu modelo mental. No entanto, na maioria dos casos, modelos intermediários de complexidade e nível de formalização diferentes são criados - de uma lista simples de requisitos a modelos formais extensivos (por exemplo, modelos UML ou BPMN)

Materialização de idéias em áreas adjacentes à Engenharia de Software

É claro que a definição acima não é radicalmente nova e é amplamente usada (consciente ou inconscientemente) em áreas de trabalho intelectual adjacentes à programação. Por exemplo, considere duas dessas áreas - engenharia mecânica e matemática.

Essas duas áreas vêm usando materialização de idéias há muito tempo e de forma eficaz. Eles têm muito a aprender sobre programação a esse respeito.

Na engenharia mecânica, vemos um ciclo completo de materialização de idéias - desde o surgimento de uma idéia na cabeça de um projetista, passando pelo pensamento, elaboração, mapeamento em um modelo e, finalmente, fabricação de um determinado material.

A situação é diferente em matemática.

Sobre a materialização de idéias em matemática

Fatos e considerações interessantes sobre a materialização de idéias em matemática podem ser encontrados no parágrafo 7.3 do livro [8].

O "produto final" da matemática são modelos formais com propriedades estritamente comprovadas.

Deste ponto de vista, a programação está no meio. Isso pode ser representado graficamente da seguinte maneira:

Assim, a matemática usa um número maior de modelos mais abstratos e quase não se aplica ao campo de modelos extremamente específicos, como desenhos de engenharia.

A engenharia mecânica, pelo contrário, usa relativamente poucos modelos abstratos, mas muitos modelos específicos. Por exemplo, aqueles para os quais objetos físicos podem ser feitos sem ambiguidade.

Deste ponto de vista, a programação está no meio.

Por que a programação está no meio?

O produto final de programação é o código do software. E, embora seja executado no hardware, seja mapeado para objetos físicos específicos (sinais elétricos e campos de várias naturezas físicas), é difícil comparar esses objetos com porcas, engrenagens e carrocerias. Por outro lado, o código do programa está próximo das fórmulas matemáticas e, às vezes, é seu reflexo direto. No entanto, em qualquer sistema de software real, é necessário considerar muitos aspectos específicos do ambiente e a interação com usuários ou outros sistemas. Isso torna o código do programa mais específico do que as fórmulas matemáticas.

O que a engenharia de software pode aprender com as áreas vizinhas em termos de uso do modelo

Considere primeiro a matemática.

Multimodelo do mundo

Por vários milhares de anos de seu desenvolvimento, a matemática aprendeu a descrever os mesmos fenômenos do mundo real ou imaginário em termos muito diferentes. Os gregos antigos aprenderam a substituir descrições puramente verbais de tarefas por figuras geométricas e com sua ajuda para resolver problemas praticamente importantes. Posteriormente, surgiu um entendimento sobre a intercambiabilidade de segmentos no plano e números. Em seguida, o conceito de variável algébrica e redução de problemas geométricos para sistemas de equações algébricas cristalizaram.

Hoje, os alunos do ensino médio já sabem que o mesmo problema pode ser resolvido de maneiras diferentes (por exemplo, geometricamente ou algebricamente) e que o mesmo modelo matemático, por exemplo, uma equação algébrica, descreve muitos aspectos físicos, químicos etc. fenômenos.

Morfismo de modelos e consistência de conceitos e notações

A matemática aprendeu bem não apenas a descrever os mesmos objetos e processos reais ou imaginários, usando modelos de natureza matemática muito diferente. Uma conquista importante da matemática é a capacidade de determinar o grau de similaridade dos modelos de diferentes ramos da matemática, bem como a capacidade de transformá-los um no outro. Muitas soluções inovadoras para os problemas matemáticos mais importantes dos últimos anos são essencialmente cadeias de evidências separadas, cada uma das quais utiliza um aparato especializado de uma seção especial de matemática. Nas junções dessa evidência altamente especializada, a matemática habilmente transforma modelos de uma seção da matemática em modelos de outra seção. Na programação, algo semelhante acontece agora ao compilar o código fonte de um programa e ao gerar código a partir de DSL (Domain Specific Language) ou metadados. Mas a cultura de trabalhar com modelos no campo da engenharia de software está muito atrás da matemática.

Modelos em engenharia mecânica

E o que a engenharia de software pode aprender com a materialização em engenharia?
Em muitas indústrias, e mesmo dentro de grandes preocupações, existem cadeias de modelos coordenados formais e semi-formais. Essas correntes terminam com modelos, com base nos quais objetos físicos são fabricados e montados - dispositivos e máquinas. Como regra, para a maioria dos tipos de modelos intermediários, existem métodos formais para verificar sua correção (padrões técnicos). Os modelos são a principal linguagem de comunicação de especialistas de vários perfis no design e fabricação de produtos de engenharia.

Nesse contexto, a situação na TI parece muito pior. Somente em grandes preocupações de TI nos últimos anos foram feitas tentativas para criar conjuntos comparáveis de modelos e processos. As pequenas empresas e as startups de TI, por regra, não apenas não desenvolveram modelos e processos formais, como sequer suspeitam de sua existência. Atualmente, esta situação é determinada pelos seguintes fatores:

A falta de eficiência dos modelos e processos existentes
A falta de fama desses modelos fora de grandes preocupações
Educação inadequada para desenvolvedores e especialmente gerentes
O atraso da educação universitária a partir das reais necessidades da engenharia de software.

Definição e contornos do paradigma de materialização de idéias (RPSE)

Identificamos todos os conceitos necessários para fornecer uma definição básica do paradigma proposto. Aqui está:

Desenvolvimento de software é a materialização de idéias através da transformação de modelos mentais em código executado em computadores.

No quadro do paradigma proposto:

Todos os principais processos de desenvolvimento de software são variantes específicas (implementações) do processo de construção de cadeias de modelos mentais e materiais. O último modelo mais específico dessa cadeia é, via de regra, o código do programa.
A essência do desenvolvimento de software é criar essas cadeias.
Todas as principais questões de otimização do desenvolvimento, reduzindo seu custo e melhorando sua qualidade, podem ser reduzidas para otimizar a construção da cadeia de modelos correspondente.

Por que materialização e não modelagem?

Observe que, embora a definição de RPSE se refira à construção de cadeias de modelos, é proposto, no entanto, chamar a materialização do paradigma em vez de modelar. Assim, tenta-se enfatizar a peculiaridade das cadeias de modelos que estão se tornando cada vez menos abstratas / ideais e cada vez mais concretas / materiais.

A definição acima possui características e variações próprias em diferentes áreas da engenharia de software. Somente em um número muito pequeno de casos acontece que, na cabeça de um programador, uma idéia clara de como resolver o problema antes dele amadurece completamente, o que ele traduz em um código de linguagem de programação em pouco tempo. Na maioria dos projetos do mundo real, o processo de encontrar uma solução e sua implementação coexiste, desenvolve-se em paralelo e interage entre si. I.e. modelos mentais, código e, geralmente, modelos intermediários (na forma de teste, imagens, modelos formais como UML) crescem e mudam em paralelo, influenciando-se mutuamente.

Opções de definição

Muitas vezes, várias pessoas trabalham em um problema ao mesmo tempo. Cada um deles tem seu próprio modelo mental e, possivelmente, seus modelos intermediários e fragmentos de código.

Geralmente, o código em alguma linguagem de programação está praticamente ausente, pois a criação de uma nova solução se resume ao gerenciamento de máscaras de configuradores ou geradores, como quando se trabalha com ferramentas de desenvolvimento em sistemas como SAP ou WebSphere.

As opções para transformar código escrito manualmente ou gerado automaticamente em código executável também se tornaram muito diversas atualmente.

E, finalmente, o próprio conceito de processador no qual o código é executado também se expandiu significativamente nos últimos anos. Se anteriormente eram processadores que estavam nas placas, que por sua vez eram inseridos nas capas de desktops, laptops e racks de servidores, agora esse conjunto foi expandido por vários chips de vários tamanhos que são incorporados a telefones celulares, consoles de jogos, câmeras de vigilância " eletrodomésticos inteligentes etc. Sem mencionar computadores quânticos.

No entanto, o RPSE, em virtude de sua generalidade, é aplicável a todas as áreas listadas acima.

O que mais se pode dizer sobre um certo paradigma hoje em dia, é possível delinear de maneira mais precisa seus contornos?

O próximo passo para refinar o paradigma depois de tentar definir sua definição principal é uma tentativa de listar as principais categorias de fenômenos que ele afeta. Recordando a definição de Kuhn, precisamos tentar listar os tipos de modelos que o RPSE apresenta e usa.

Os modelos RPSE podem ser divididos em três categorias principais:

Modelos mentais
Código em linguagens de programação ou seus equivalentes como modelos de código executável.
Modelos intermediários.

Os menos explorados nessa tríade são os modelos mentais. O que exatamente se entende por eles?

Modelos mentais são um termo para idéias que existem na cabeça de clientes, programadores e outros participantes do processo e com base nas quais o código executável finalmente surge. A presença de tais modelos é indiscutível e pode ser registrada no nível mental, por exemplo, pelo próprio programador.No atual nível de desenvolvimento tecnológico, esses modelos não podem ser medidos com segurança por instrumentos.

Uma das maneiras eficazes de corrigir e medir esses modelos é usar o meio da ideia. Obviamente, o processo de entrevista ou similar afeta drasticamente o próprio modelo mental. Cada um de nós deve ter experimentado a situação mais de uma vez, quando apenas uma tentativa de formular um problema com o objetivo de consultar um colega levou ao "insight" e, freqüentemente, a uma solução para o problema.

A entrevista permite, com base em perguntas formuladas corretamente, construir de maneira relativamente objetiva modelos de complexidade variada. Os mais comuns são:
Modelos estruturais:

Lista com valores binários, enumeração, numéricos, sequência e outros.
Estruturas de dados de redes e gráficos

Modelos de descrição comportamental:

Modelos sete-formais para determinar o comportamento
Modelos formais para determinar o comportamento (por exemplo, máquinas de estados finitos)

Sobre a teoria dos modelos mentais

Esses padrões são um reflexo dos padrões mentais. O grau de proximidade dos modelos mentais com os modelos reais deve ser tratado pela psicologia ou pela pedagogia teórica. Infelizmente, o autor não tem conhecimento de trabalhos sérios nessa área. (Isso não significa que esse trabalho não exista).

Por que a engenharia de software precisa de um paradigma de ponta a ponta?

A presença de um paradigma “transversal” abre as seguintes possibilidades para os participantes usarem o paradigma do processo de criação, modificação e uso de software:

A capacidade de todos os participantes do processo usarem a mesma terminologia.
A capacidade de criar um processo completo para criar um novo software.
A capacidade de avaliar seus parâmetros de processo, seus resultados intermediários e gerenciá-lo.

Os principais objetivos do desenvolvimento de paradigmas

Problemas teóricos

Como já foi observado repetidamente, inclusive no livro de Kuhn [2], na maioria dos casos, os cientistas estão envolvidos na solução de problemas potenciais que estão sendo resolvidos e são menos propensos a enfrentar aqueles que não são muito claros sobre como abordar. Mas essas são exatamente nossas tarefas. Aqui estão os principais:

Definição construtiva do conceito de modelo mental.
Encontrar critérios construtivos para avaliar o grau de abstração / idealidade vs. especificidade / materialidade dos modelos.
Encontrar critérios para selecionar candidatos para o papel de modelos intermediários e adicionais.
Seleção e desenvolvimento de critérios e métodos para comparar modelos de vários tipos, incluindo o rastreamento direto e reverso.
Desenvolvimento de métodos para transformação automatizada e automática de modelos.

Tarefas práticas

Juntamente com as tarefas teóricas para o desenvolvimento e implementação do paradigma descrito na prática da engenharia de software, é necessário resolver pelo menos os seguintes problemas práticos:

Criação de ferramentas para: a) Extração e fixação de modelos mentais. b) Transformação automatizada e automática de modelos mentais em modelos intermediários. c) Traços e estimativas de mudanças no conteúdo de modelos transformáveis
Criação da literatura técnica e educacional necessária e outro material educacional medial.
Organização de fóruns e conferências sobre este assunto

Conclusão

Este artigo tenta definir o paradigma da engenharia de software como a materialização de idéias. A palavra para definir (e não abrir) é usada aqui, não por acaso. De fato, os participantes de projetos de TI há muito tempo se envolvem na criação, transformação e uso de modelos, talvez sem perceber.

No sentido estrito da definição de Kuhn, a abordagem descrita ainda não pode reivindicar o direito de ser chamado de paradigma, mas apenas um candidato a um paradigma, porque não possui uma extensa comunidade de pessoas apoiando-o e um sistema bem desenvolvido de modelos interconectados. No entanto, quero acreditar que as deficiências serão superadas em breve.

Este é o primeiro artigo de uma série planejada de artigos. Nos artigos a seguir, vou falar sobre modelos mentais e intermediários.

Literatura

1. Glossário Padrão IEEE de Terminologia de Engenharia de Software, IEEE std 610.12-1990, 1990.
2. Kuhn, Thomas S. A Estrutura das Revoluções Científicas. 3rd ed. Chicago, IL: University of Chicago Press, 1996.
3. Paradigma de programação: 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. de setembro de 2007). ISBN-13: 978-3446407442.
5. Ensaio sobre tecnologia da informação e modelos de paradigmas e modelos de engenharia de software
www.uniassignment.com/essay-samples/information-technology/software-engineering-paradigms-and-models-information-technology-essay.php (estado - 27/08/2018)
6. Reificação (ciência da computação) en.wikipedia.org/wiki/Reification_ (computer_science) (estado - 27/08/2018)
7. Fedor Ivanovich Tyutchev. Silêncio! (Silence (lat.), 1829.
8. Borovik, Alexandre. Matemática ao microscópio: notas sobre aspectos cognitivos da prática matemática. American Mathematics Society. ISBN-13: 978-0821847619.

Ilustração: geralt

Programação é a materialização de idéias.