Pourquoi ne pouvons-nous pas capturer la conception de logiciels plus efficacement? [fermé]

En tant qu'ingénieurs, nous "concevons" tous des artefacts (bâtiments, programmes, circuits, molécules ...). C'est une activité (conception-le-verbe) qui produit une sorte de résultat (conception-le-nom).

Je pense que nous sommes tous d'accord pour dire que design-the-noun est une entité différente de l'artefact lui-même.

Une activité clé dans le secteur des logiciels (en effet, dans toute entreprise où l'artefact produit résultant doit être amélioré) est de comprendre la «conception (le-nom)». Pourtant, nous semblons, en tant que communauté, être à peu près des échecs complets à l'enregistrer, comme en témoigne la quantité d'efforts que les gens mettent pour redécouvrir des faits sur leur base de code. Demandez à quelqu'un de vous montrer la conception de son code et de voir ce que vous obtenez.

Je pense qu'une conception de logiciel a:

• Une spécification explicite pour ce que le logiciel est censé faire et dans quelle mesure il le fait
• Une version explicite du code (cette partie est facile, tout le monde l'a)
• Une explication de la façon dont chaque partie du code sert à atteindre la spécification (par exemple, une relation entre les fragments de spécification et les fragments de code)
• Une justification pour expliquer pourquoi le code est tel qu'il est (par exemple, pourquoi un choix particulier plutôt qu'un autre)

Ce qui n'est PAS une conception est une perspective particulière sur le code. Par exemple [ne pas choisir spécifiquement] les diagrammes UML ne sont pas des conceptions. Ce sont plutôt des propriétés que vous pouvez dériver du code, ou sans doute, des propriétés que vous souhaitez que vous puissiez dériver du code. Mais en règle générale, vous ne pouvez pas dériver le code d'UML.

Pourquoi est-ce qu'après plus de 50 ans de construction de logiciels, pourquoi n'avons-nous pas des moyens réguliers d'exprimer cela? (N'hésitez pas à me contredire avec des exemples explicites!)

Même si nous le faisons, la plupart de la communauté semble tellement concentrée sur l'obtention de "code" que design-the-noun se perd de toute façon. (À mon humble avis, jusqu'à ce que la conception devienne le but de l'ingénierie, avec l'artefact extrait de la conception, nous n'allons pas contourner cela).

Qu'avez-vous vu comme moyen d'enregistrer des dessins (dans le sens où je l'ai décrit)? Des références explicites aux articles seraient bien. Pourquoi pensez-vous que les moyens spécifiques et généraux n'ont pas réussi? Comment pouvons-nous changer ceci?

[J'ai mes propres idées qui étoffent le point de vue ci-dessus, mais je suis intéressé par les réponses des autres ... et c'est difficile de mettre en œuvre mon schéma [[et c'est peut-être le vrai problème: -]]]

EDIT 2011/1/3: L'un des fils de réponse laisse entendre que la «documentation» (vraisemblablement textuelle, en particulier non formelle) pourrait être adéquate. Je suppose que je devrais préciser que je ne le crois pas. Les outils CASE sont apparus sur la scène à partir des années 80, mais les premiers outils ont principalement capturé des pixels pour les diagrammes de tout ce que vous avez dessiné; Bien que les outils aient sans doute réussi sur le plan commercial, ils n'étaient vraiment pas très utiles. Un aperçu clé était que si les artefacts de "conception" supplémentaires ne sont pas formellement interprétables, vous ne pouvez pas obtenir d'aide sérieuse sur les outils. Je crois que la même idée s'applique à toute forme utile de capture de conception à long terme: si elle n'a pas de structure formelle, elle ne sera pas vraiment utile. Les documents texte échouent à peu près à ce test.

Je pense qu'il y a plusieurs raisons pour lesquelles nous ne sommes toujours pas bons dans ce domaine.

1. Les gens ont longtemps pensé que les logiciels étaient comme des maisons et utilisaient des processus et des idées issus de la construction. "Architecte logiciel" était un titre recherché par tous les programmeurs. Au cours des dix dernières années, l'architecte logiciel a presque disparu. L'idée de processus en cascade où vous avez d'abord un architecte disant comment le logiciel devrait fonctionner et ressembler, puis amener les gens à faire des diagrammes de la façon dont il devrait être construit et enfin avoir un singe de code implémentant ces beaux diagrammes de flux de travail / UML à spécifier, cette idée est maintenant largement tourné en dérision. Donc, en fait, toute l'industrie a suivi la mauvaise voie pendant 40 ans.

2. Les outils que nous utilisons changent et s'améliorent constamment. La programmation est un puzzle logique, et nous proposons de meilleures idées et techniques pour résumer ce puzzle et le rendre compréhensible. La façon dont nous modélisons cela doit évoluer à la même vitesse, mais elle est à la traîne. Les techniques améliorées pour résumer le puzzle de la programmation signifient également que nous pouvons augmenter la complexité. Et c'est ce que nous faisons. La programmation se situe toujours aux limites de la complexité que nous, en tant que programmeurs, pouvons gérer.

3. Trouver des façons de décrire le programme est une sorte d'abstraction. Si nous pouvons trouver un bon moyen d'abstraire le logiciel, nous pouvons également mettre cette abstraction directement dans les outils de développement, et donc ajouter une autre abstraction / simplification à la programmation. Cela s'est produit plusieurs fois. Des exemples de telles abstractions sont les fonctions, les classes et les bibliothèques.

4. Donc; Si vous disposez d'un modèle de logiciel réussi et précis , ce modèle sera équivalent au logiciel. Ce qui rend tout l'effort inutile, ce qui corrobore à son tour le point 1 ci-dessus: La modélisation du logiciel est beaucoup moins utile qu'on ne le pensait auparavant. Il est plutôt préférable d'extraire des données sur le logiciel du code. Créer un modèle UML à partir de l'apparence réelle du code est beaucoup plus instructif que de créer un modèle UML et d'essayer de mettre en œuvre ce modèle théorique.

Vous pourriez être intéressé à consulter la documentation sur la traçabilité des logiciels. Dans aucun ordre particulier:

• CUBRANIC, D., MURPHY, GC, SINGER, J., ET BOOTH KELLOGG, S. Hipikat: une mémoire de projet pour le développement de logiciels. Transactions on Software Engineering 31, 6 (2005), 446–65.
• TANG, A., BABAR, MA, GORTON, I., ET HAN, J. Enquête sur l'utilisation et la documentation de la justification de la conception de l'architecture. In Proc of the 5th Working IEEE / IFIP Conference on Software Architecture (2005).
• RAMESH, B., POWERS, T., STUBBS, C., ET EDWARDS, M. Mise en œuvre de la traçabilité des exigences: une étude de cas. In Proc of the Int'l Symp on Requirements Engineering (York, 1995).
• HORNER, J., ET ATWOOD, ME Justification de la conception: la justification et les obstacles. In Proc of the 4th Nordic Conference on Human-Computer Interaction: Changing Roles (Oslo, Norvège, 2006).
• CLELAND-HUANG, J., SETTIMI, R., ROMANOVA, E., BERENBACH, B., ET CLARK, S. Meilleures pratiques pour la traçabilité automatisée. Computer 40, 6 (juin 2007), 27–35.
• ASUNCION, H., FRANÇOIS, F., ET TAYLOR, RN Un outil de traçabilité logicielle industrielle de bout en bout. In Proc of the 6th Joint Meeting of the European Software Eng Conf and the ACM SIGSOFT Int'l Symp on the Foundations of Software Engineering (ESEC / FSE) (Dubrovnik, 2007).

Notez que ce n'est que la pointe de l'iceberg, et je suis sûr que j'ai oublié certains documents clés.

Sur une note distincte, mon propre travail sur Arcum était un moyen pour les programmeurs d'exprimer à l'IDE l'utilisation d'idiomes de conception transversaux. Une fois exprimé, les programmeurs pourraient ensuite transformer leur code source pour utiliser des implémentations alternatives:

• Macneil Shonle, William G. Griswold et Sorin Lerner. Au-delà du refactoring: un cadre pour la maintenance modulaire des idiomes de conception transversale . Dans les actes de la 6e réunion conjointe de la Conférence européenne du génie logiciel et du Symposium ACM SIGSOFT sur les fondements du génie logiciel (ESEC-FSE '07; 3-7 septembre 2007). 175-184.

Soit dit en passant, Arcum est également lié à votre travail DMS.

UML est à un programme ce que les plans sont à un bâtiment à mon humble avis. Les plans seuls ne sont pas une conception hors cours, vous avez besoin de spécifications de matériaux (outils de code utilisés) pour cela, d'une vue générale du bâtiment (une représentation schématique de l'ensemble du logiciel, y compris des conceptions GUI), de la façon dont le bâtiment est planté dans les environs (un schéma clair de la façon dont le logiciel interagit avec les autres / est planté dans le système d'exploitation), comment il se présente au climat et au sol (interaction avec le matériel), ... Beaucoup de livres sur le design essaient de le définir, mais comme avec beaucoup de choses en science, chaque scientifique a un peu sa propre définition.

Maintenant, je ne suis pas d'accord non plus avec votre observation selon laquelle vous ne pouvez pas dériver le code d'UML. Vous pouvez, si vous disposez des informations complémentaires mentionnées. Mais le vrai code n'est plus la conception, c'est l'artefact. Vous ne pouvez pas non plus extraire les vraies pierres et le béton d'un plan, mais vous avez besoin du plan pour mettre les vraies pierres et le béton dans la bonne forme et au bon endroit.

Dans cette optique, j'ai trouvé l' article suivant intéressant (je l'ai rencontré dans un contexte différent lorsque je cherchais un logiciel graphique, mais néanmoins ...). L'approche graphique pour décrire un design avait du sens pour moi, même si - encore une fois - ce n'est qu'une partie du design à mon avis. La chose intéressante est que cette approche donne un cadre pour comprendre et refactoriser les conceptions (par opposition à refactoriser le logiciel), comme indiqué dans les articles suivants:

• Wermelinger et Fiadeiro

• Tsantalis et al

Il existe de nombreuses autres approches pour décrire (une partie de) la conception, comme la conception structurée (cartes HIPO) ou la conception de programmes intégrés , les modèles de conception , ...

Pourtant, tant qu'il n'y a pas d'ensemble standard de l'industrie, il est peu probable d'avoir une façon «régulière» d'exprimer cela. Même après 50 ans et plus. Et soyez honnête, si votre entreprise trouve un bon moyen d'exprimer un design, le partagerez-vous avec le monde?

D'après ma propre expérience personnelle, je dirais que nous sommes bien capturer la conception de logiciels. Nous avons une base de données de documents d'exigences et de conception pour chaque fonctionnalité que nous avons jamais implémentée sur notre plateforme. Je suppose que ma circonstance est peut-être unique. Voici quelques éléments auxquels penser.

Chaque personne de mon équipe a un diplôme d'ingénieur ... principalement EE ou CE. L'ingénierie vous apprend la conception dans le cadre du programme d'études.

Je pense qu'il y a beaucoup de soi-disant ingénieurs logiciels qui viennent d'horizons CS. La conception de logiciels ne fait pas partie intégrante de la plupart des programmes CS. Je ne dis pas que toutes les majors CS sont mauvaises en conception, mais je parierais que la plupart n'ont aucune éducation formelle qui leur a enseigné. Je pense que beaucoup de gens supposent que si vous pouvez programmer, vous pouvez concevoir un logiciel, ce qui n'est pas vrai. Étant donné que de nombreux programmeurs n'ont pas de formation en ingénierie, il n'est pas vraiment surprenant que de nombreux projets logiciels ne disposent pas d'une équipe capable de capturer la conception.

Je vois deux problèmes.

Le premier est qu'il est extrêmement difficile de synchroniser le code et la documentation. S'ils sont séparés, ils divergent et la documentation devient inutile. Les programmeurs ont essayé d'utiliser des outils pour faire le travail de les garder synchronisés (comme les outils CASE), mais ces outils se sont intercalés entre les programmeurs et leur code, ce qui a fait plus de dégâts que de bien. L'une des idées clés de la conception pilotée par domaine (Evans, 2004) est qu'une bonne conception est vraiment difficile, donc pour en tirer quelque chose, vous devez:

• choisissez la plus petite zone possible de votre programme où une bonne conception apportera de grands avantages, le domaine dit de base
• travailler très dur pour obtenir un bon design sous la forme d'un langage omniprésent que tous les membres de l'équipe utilisent tout le temps
• dans la mesure du possible, intégrez la conception au code

L'autre gros problème avec notre façon de concevoir, c'est que nos méthodes de conception ne sont pas assez mathématiques. Les abstractions qui fuient ne se prêtent pas à en tirer des conclusions solides, et le monde de la logique strictement appliquée et de la vérité claire s'appelle les mathématiques, ce que les programmeurs évitent le plus souvent.

Les quelques outils mathématiques dont nous disposons, comme les méthodes formelles, sont très lourds.

Map-Reduce est un bel exemple de mathématiques en programmation. L'idée centrale est la suivante: lorsque vous avez une opération binaire associative, vous pouvez distribuer son exécution très facilement. Une opération binaire est une fonction à deux paramètres, l'associativité implique que (a + b) + c = a + (b + c)

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99 est

(a1 + a2 + ... + a99) + (b1 + b2 + ... + b99) + (c1 + c2 + ... + c99) où les As, Bs et Cs peuvent être ajoutés trivialement à différents endroits, leurs résultats collectés et résumé en peu de temps.

Réduire la carte est une idée ridiculement simple. Il peut être décrit sur une seule feuille de papier. Si vous pouvez supposer que le lecteur a une solide compréhension du concept d'associativité, s'il tient sur une assez petite feuille de papier. Essayez maintenant d'expliquer map-Reduce à quelqu'un sans utiliser le terme d'associativité ou y faire référence indirectement. Je vous défie.

La conception de logiciels sans abstractions mathématiques, c'est comme essayer de faire de l'architecture sans jamais se soucier d'apprendre la géométrie.

Haskell peut peut-être résoudre ce problème au fil du temps. L'utilisation de concepts de la théorie des catégories pour décrire les programmes me semble prometteuse. La théorie des catégories est si abstraite que même les mathématiciens l'ont peu utilisée, mais apparemment les catégories, qui sont abstraites au-delà de la reconnaissance, semblent être suffisamment abstraites pour décrire la structure du logiciel. Nous le saurons. Lentement.