Conception de logiciels par pseudocodage?

9

Connaissez-vous un bon moyen de concevoir (c.-à-d. Écrire) un logiciel avec une méthode basée sur le pseudocode?

Je suis nouveau dans la conception de logiciels et je lis des informations sur UML. Mes humbles hiérarchies de classe sont bonnes jusqu'à présent, cependant, après que cela soit devenu complexe, je remarque qu'avec "voir la totalité", j'aurais pu utiliser une structure différente pour plus d'extensibilité future. Comme Python est bon pour le prototypage, je suis presque d'accord pour commencer à écrire, mais pas tout à fait.

J'ai donc essayé les diagrammes de classes UML, mais ils ne semblent pas m'aider beaucoup. Les problèmes que je résous là-bas, je peux les faire trivialement dans ma tête. Mais je remarque des exigences de conception supplémentaires une fois que j'ai commencé à pseudo-coder les méthodes réelles.

Donc, si vous vouliez concevoir par pseudocode, comment feriez-vous? Je crois que pour moi, une méthode qui est à peu près 1 contre 1 avec du code fonctionne mieux. Mais la plupart des logiciels UML ne montrent même pas le code de la méthode (contrairement aux images dans GoF par exemple).

Quelqu'un a prétendu que l'UML est uniquement destiné à la documentation et à la présentation et pas génial pour la conception? J'ai aussi ce sentiment. Je pensais que l'UML pur et quelques esquisses de tableau blanc simplistes étaient le moyen de concevoir un logiciel jusqu'à ce que je recherche Google sur Envision APDT.

Donc, le développement agile est-il quelque chose que je devrais rechercher ou est-ce qu'ils appellent aléatoirement cela agile - je pensais que l'agile ne concernait que le calendrier? Ou est-ce que je conçois mal (avec UML) - quelqu'un conçoit-il par pseudocode? Comment puis-je trouver un bon outil pour cela?

Gerenuk
la source
3
Steve McConnell décrit le processus de programmation de pseudocode (PPP) dans son livre Code Complete 2 . La méthode se concentre sur la conception et l'implémentation de bas niveau, mais ce pourrait être une bonne lecture si c'est ce que vous recherchez.
thiton

Réponses:

8
 I thought agile is about schedule only?

Ce n'est pas seulement de la planification. Le développement logiciel agile consiste davantage à être un développement évolutif et une livraison itérative dans le temps avec une planification adaptative qui encourage une réponse flexible aux changements demandés par le propriétaire du produit.

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

Dans mon expérience, les graphiques sont beaucoup plus faciles à comprendre du point de vue du client. Ils sont visuellement attrayants et souvent très colorés et faciles à suivre. Cependant, il est très difficile de maintenir des graphiques en raison de la nature de la déconnexion avec le code d'application réel. Chaque fois qu'un changement est effectué dans l'application, le développeur doit prendre le temps de mettre à jour toute la documentation, y compris les graphiques. Cependant, ce problème peut être facilement éliminé une fois qu'il y a un BA dans l'équipe ou l'entreprise, qui comprend bien le processus métier du client et peut gérer les diagrammes UML.

Des outils comme UML peuvent faciliter ce processus mais ne fonctionnent bien qu'avec la programmation orientée objet. Le pseudo-code est beaucoup plus facile pour les équipes techniques. Le processus de création de ce code augmente considérablement la vitesse de la phase de développement du langage de programmation.

Il existe également d'autres alternatives:

  • Diagrammes de flux de données
  • Diagrammes d'état
  • Diagrammes de flux de processus

Bonnes références à regarder: Tutoriels de conception de logiciels . De plus, je conseillerais personnellement de lire un bon blog sur Pseudocode ou Code? publié par Coding Horror - mon blog préféré à lire :)

Dans l'ensemble, vous devez prendre en compte certains compromis.

Yusubov
la source
3
+1 pour le lien vers le pseudocode ou le code . Écrivez simplement ce fichu code.
kevin cline
@ElYusubov: Merci pour l'explication. Il semble que vous impliquiez également que UML est davantage destiné à la présentation? Pour la conception actuelle, je n'y mets pas l'accent? Au final vous proposez 3 schémas. Peuvent-ils être faits 1 à 1 avec du code dans une certaine mesure. Je veux dire au contraire certaines choses qui fonctionnent dans le diagramme peuvent ne pas fonctionner avec du code - que je veux éviter.
Gerenuk
@Gerenuk, les diagrammes de flux de données peuvent être créés 1 à 1 avec le flux de code. Cependant, les diagrammes sont généralement utilisés pour voir la conception de haut niveau et l'interaction entre les composants / modules / cas d'utilisation.
Yusubov
3

Lors de la programmation en langage assembleur, l'écriture de pseudo-code a beaucoup de sens. L'algorithme a pu être vérifié avant de déployer des efforts pour le traduire manuellement en langage assembleur, puis déboguer la traduction. Cela avait toujours du sens pour les langages compilés de première génération comme FORTRAN IV, où la seule construction de contrôle était GOTO, toutes les variables (à l'exception des arguments formels) étaient globales et les noms de variables étaient limités à six caractères.

Aujourd'hui, nous faisons très peu de programmation en langage assembleur, et je vois peu de valeur à écrire du pseudo-code au lieu de simplement écrire du code. Dans une langue décente, le code réel suivra le pseudo-code presque mot pour mot, et le pseudo-code n'est qu'une perte de temps.

Cependant, je ne commence pas à coder en bas. Je suis TDD et commence par un test. Ensuite, je commence à coder en haut, et je progresse progressivement vers le bas au besoin pour faire passer les tests.

L'alternative au pseudo-code n'est pas d'écrire 1000 lignes de classes de bas niveau. Commencez plutôt par le haut, en appelant l'API idéale mais inexistante pour votre domaine. Créez ensuite l'API.

kevin cline
la source
Quand je commence juste à coder, parfois plus tard, je remarque que du point de vue de la conception, j'aurais pu prendre en compte du code. Bien que le refactoring soit OK, il aurait quand même pu l'éviter si j'avais d'abord vu l'aperçu de tout le code et utilisé un peu de créativité. Une vue graphique de pseudocode pourrait tout présenter dans un graphique condensé. Mon erreur est-elle ailleurs?
Gerenuk
2
Votre erreur est de croire que la refactorisation du code est en quelque sorte plus de travail que la refactorisation du pseudo-code. Avec un IDE moderne, il est plus facile et plus rapide d'écrire du code réel que de jouer avec le pseudo-code soit sur papier dans un éditeur de texte brut.
Kevin Cline
1

Je trouve que les diagrammes de classes valent à peine l'effort, même lorsque vous ignorez la liste de toutes les méthodes et montrez simplement la hiérarchie d'héritage. Les diagrammes de séquence sont bons, mais je me sens gêné lorsque je les dessine (probablement juste moi).

Je trouve que les diagrammes de flux de données et les diagrammes de structure sont plus utiles (bien que les diagrammes de structure soient couramment associés à BDUF et ne sont donc pas en faveur pour le moment). Les DFD sont particulièrement utiles pour la décomposition fonctionnelle. Chaque "bulle" d'un DFD peut être décomposée en son propre DFD jusqu'à ce que vous atteigniez le niveau de détail souhaité.

TMN
la source
0

Je pense que les outils graphiques sont meilleurs que le pseudocodage, mais UML est tellement tellement compliqué qu'il combine le mauvais dans ces méthodes :-)

Pour être un peu plus clair: je pense que la programmation est principalement un moyen d'analyser un certain problème, de le séparer de composants plus petits et de leur interaction. C'est "un voyage, pas une destination", vous améliorez constamment vos connaissances sur le problème, donc le graphe des composants évolue: les couches apparaissent et s'estompent, les fonctions et les éléments de données montent et descendent, etc.

L'outil naturel pour suivre ce processus est un tableau de croquis, aussi simple que possible, mais suffisamment complexe pour permettre une compréhension rapide (mêmes couleurs, formes, flèches pour la même signification logique). Je n'ai pas trouvé la solution miracle, et j'écrirai peut-être la mienne un jour, mais maintenant j'utilise gliffy ; combiné avec la fonction de zoom de prezi, il serait presque parfait.

Pourquoi pas le pseudocodage? Le pseudocodage est un pas en avant vers la mise en œuvre, une "forme sérialisée du graphique des composants", lorsque vous façonnez encore vos idées. Pas bon, limite la tête. D'après mon expérience, j'ai constaté que plus je commence à coder tard, moins je dois jeter de code ...

Mais c'est peut-être parce que j'ai écrit tous ces codes jetés, donc je n'ai pas à les écrire maintenant, l'expérience que j'ai acquise d'eux est avec moi lors de la conception du système? Eh bien, je dois modifier la déclaration.

Si vous êtes perdu avec votre graphique et voyez de nombreuses solutions équivalentes possibles, allez au pseudocode, ou même écrivez ce code avec des objets fictifs - en Java, cela ne fait presque aucune différence. Voir le code, sentir la structure et la convivialité de ces composants, il vous aidera à réparer votre graphique et à prendre des décisions. Mais cela ne fonctionne QUE si vous êtes prêt à jeter ce code si vous pensez qu'il est mauvais. Je pense que c'est l'avantage du pseudocode: moins de tentation de le garder lorsqu'il fonctionne, mais sa structure est mauvaise (et comme toujours, vous n'avez pas assez de temps). :-)

Lorand Kedves
la source