Quels outils de conception vous utilisez pour penser l'architecture d'un logiciel?

Développement
#1

Bonjour,

Comme beaucoup, j’ai appris des outils comme UML et Merise à l’école. Cependant, je ne les ai jamais utilisé dans un projet concret. Je suis plutôt amateur de Scrum et du BDD.

Pour moi, un produit doit avoir des specs qu’il faut définir avant de commencer. On prend ces specs et on établi les fonctionnalités minimales que doit avoir le produit pour le rendre fonctionnel. Ensuite, on fonctionne par itération en apportant des briques au produit. On doit pouvoir fournir un produit fonctionnel régulièrement.

Pour discuter, on peut faire des schémas de formulaires, des storyboard, etc…

Lorsque l’on débute une spec, on commence par écrire le test d’intégration, avec RSpec et Capybara dans mon cas. Ensuite, on laisse les tests nous dire où sont les erreurs à résoudre et on bâti les tests unitaire puis le code en fonction de ces erreurs. Une fois le test d’intégration passé, on refactorise.

Cette technique fonctionne bien mais je ne sais pas si c’est une bonne raison d’oublier l’UML. Des fois, ça fait du bien d’avoir un schéma pour comprendre. Ça peut être utile pour penser quand l’architecture devient complexe.

Qu’en pensez-vous? Utilisez vous la même technique que moi? Quels sont vos trucs?

#2

Pour ma part j’ai le même process mais je tient toujours à jour des specs techniques sur l’architecture des entités.
Dès qu’on modifie une entité, une relation, un attribut, qu’on ajoute une entité, en supprime, etc. d’un point de vue métier, on fait la même chose sur notre diagramme de classe.

J’utilise Omnigraffle pour ça.

#3

Donc tu fais quand même un diagramme de classe. Quel langage utilise-tu? Je pense que ça peut avoir son important étant donné qu’avec Ruby on Rails, les modèles sont suffisamment explicite pour comprendre les associations en lisant. Je pense qu’il existe des générateur de schéma avec Rails.

#4

Je n’ai pas la même méthodologie que toi, car on m’en impose une autre malheureusement. Cependant je trouve qu’un schema est toujours un bon élément lorsqu’on veut discuter avec quelqu’un. Et quoi de mieux que l’UML puisqu’on est censé tous avoir des notions.

Avant toute chose mes diagrammes sont souvent des versions abstraites ou de premier jet de discussion donc peut être pas adapté a des diagrammes très lourd.

J’utilise personnellement PlantUML car j’adore l’approche d’écriture textuelle qui est un plus lorsqu’on veut versionner ou retravailler son diagramme cross-platform (j’attache toujours la source à l’image).

Bien que puissant si vous faites des choses qui sort un peu des sentiers battu vous pouvez vous heurtez à des problèmes.

De plus PlantUML propose un service online pour générer ou tester http://www.plantuml.com/plantuml/ mais aussi l’executable (un jar) pour l’héberger chez soi.

Sans oublier son integration dans pas mal d’outil (ou dans le cas contraire la simplicité d’integration), je l’utilise par exemple dans mes specs que j’écris en .rst, dans notre doc sous Sphinx et même dans notre issue tracker Redmine.

2 « J'aime »
#5

Plusieurs langages, mais Ruby/Rails essentiellement.

#6

@benjamin_bnds , et tu penses qu’un Digramme est utile même en utilisant des modèles avec des belongs_to ou has_many?

Je viens d’essayer https://github.com/preston/railroady. Ça fonctionne bien.

@kakawait , encore une fois, je ne sais quel language/framework tu utilises mais je pense qu’écrire simplement les modèles suffit. Surtout si tu préfère utiliser un format texte.

#7

Java avec Spring.

Mais je t’avoue que je fait rarement des diagrammes de classes vu que les IDE (IntellijIDEA) moderne avec un langage compilé comme Java sont capable de générer un diagramme de classe.

Je fais dans 80% des diagrammes de sequences et 19% des diagrammes d’états donc indépendant du langage.

#8

Effectivement, je comprend l’utilité des diagrammes de séquence. Ceci dit, je pense que je préférerais un tableau blanc et un crayon plutôt que d’utiliser un logiciel. L’intérêt serait de la faire à plusieurs, de discuter des solutions et de prendre une photo ou mettre au propre. Est-ce que c’est ce que tu fais?

#9

Même si je suis assez allergique à Eclipse, j’aime assez Modelio ( https://www.modeliosoft.com/fr.html )
cela permet de poser une architecture assez rapidement, et de découper les différents modules plus ou moins finement.
D’un point de vue UML, il n’a normalement pas de limitation dans les choix de diagramme.

Je l’ai toujours utilisé dans sa version communautaire, donc je ne peux pas parler de ces fonctionnalités avancés.
Mais pour un premier découpage de module, la version simple suffit.

Sinon, pour faire des schémas rapides, j’utilise de plus en plus les applis Web type ; https://www.lucidchart.com/
Travaillant sur de multiple machine, j’y gagne en portabilité.

#10

Oui. C’est plutôt indépendant du langage je pense.
Un diagramme de classe me permet d’avoir à tout moment une vision globale du projet.

#11

Oui désolé j’ai pas été très précis mais sur ce point je te rejoins. On fait le brainstorming ensemble sur un whiteboard et après seulement on décrit le schéma en plantUML dans le but de le rattacher à la spec ou au ticket Redmine.

Car les photos c’est bien sur l’instant mais si tu veux faire évoluer…

#12

@benjamin_bnds @kakawait je vous recommande de lire ceci : http://playbook.thoughtbot.com/. Je pense que ça correspond à ma philosophie.

#13

C’est là que le Flow programming devient intéressant. Voici un exemple avec NoFlo : la structure visuelle de l’architecture est au cœur même du concept.

2 « J'aime »
#14

Franchement j’ai du mal avec le diagramme de classes. Il peut être efficace pour communiquer sur un point précis de conception (encore que faire des boîtes reliées et donner oralement le type de relation est plus parlant). Mais il ne me dit pas comment interagissent les éléments du logiciel. Je ne vois pas l’utilité de le mettre dans une spec, à part pour montrer qu’on est super malins et qu’on sait faire des diagrammes bizarres.

Le diagramme de séquence est plus utile quand on veut montrer des interactions. Actuellement je ne l’utilise pas en conception mais après des dev. Je le génère à partir des logs avec seqdiag (voir sur pypi) pour montrer au client des séquences d’appels de Web services.

La meilleure spec, ce sont des tests. Le design de l’application peut alors être monté de façon incrementale et sa lisibilité retravaillée.

#15

“La meilleure spec, ce sont des tests. Le design de l’application peut alors être monté de façon incrémentale et sa lisibilité retravaillée.” -> ah oui mais non … On ne va pas rentrer dans le mythe de l’œuf ou la poule … mais les tests sont les résultats de tes specs et pas l’inverse. D’ailleurs test F ou test U ?

Si tu n’as pas à minima, une idée du dimensionnement de ton application, tu ne peux pas poser l’architecture initiale, donc faire le choix de ton environnements, de tes frameworks … et de décrire tes webservices.

Après je suis d’accord, des specs ultra détaillées ne servent pas à grand chose car un projet vie, mais un minimum permet de limiter la casse. Aller dès le début sur les diagrammes de classe, c’est pas toujours utile … mais aller au niveau composant, c’est déjà un bon début.

Après c’est un fait, tout dépend de la taille du projet, de sa durée et de son potentiel de scalabilité.

1 « J'aime »
#16

Ce que je veux dire ces que les tests ont aussi un rôle de documentation fonctionnelle sur ton application. C’est l’enjeu de la spécification par l’exemple et de l’approche BDD, pouvoir exécuter ta définition de use cases pour savoir si ton appli répond bien au besoin.

La documentation d’architecture c’est utile parce que les boites ont encore besoin de faire du provisionning, même si aujourd’hui avec le développement des IaaS PaaS, tu peux clairement t’en passer en étape préliminaire. Et pour un doc d’architecture, je vais plutôt utiliser des applis pour faire des carrés et des flèches et un tableur pour faire des calculs de dimensionnement en fonction des objectifs du métier. Mais bon, ce n’est plus vraiment de la conception mais plus du choix d’infra.

Faire des choix de framework upfront ? Pour quoi faire ? C’est peut-être super limitant, non ? Qu’est-ce qui motive le choix d’un framework d’ailleurs ? (culture de la boite, connaissance de l’équipe, conference driven development). A propos de conference, celle-ci décrit plus en détail ce que je veux dire :

Quand ils ont expérimenté avec Fitnesse, ils ont repoussé super loin le choix d’utiliser un SGBD. Les premières releases de demo stockaient tout en mémoire ! Je trouve ça vachement inspirant.

Enfin, on est d’accord, ça dépend du contexte et je parle de l’idéal pour moi. Habituellement, les clients cassent les pieds pour avoir des romans de specs fonctionnelles illisibles, invalidables sur lesquels on se bat sur 2 ans de projets alors qu’on pourrait livrer de la valeur. Ca fait partie du métier.

#17

@Delapouite, as tu déjà utilisé NoFlo? Quel est ton retour d’expérience?

Human Coders - Le centre de formation recommandé par les développeur·se·s pour les développeur·se·s