Comment planifiez-vous l'architecture d'une application avant d'écrire du code?
Une chose avec laquelle je me bats est de planifier l'architecture d'une application avant d'écrire du code.
Je ne parle pas de rassembler des exigences pour restreindre ce que l'application doit faire, mais plutôt de réfléchir efficacement à un bon moyen de présenter la classe globale, les données et les structures de flux, et d'itérer ces pensées afin d'avoir un plan crédible de l'action à l'esprit avant même d'ouvrir l'IDE. Pour le moment, il est très facile d'ouvrir simplement l'IDE, de créer un projet vierge, de commencer à écrire des bits et des bobs et de laisser le design "grandir" à partir de là.
Je suppose que l'UML est une façon de le faire, mais je n'ai aucune expérience avec cela, donc cela semble un peu nébuleux.
Comment vous planifiez-vous l'architecture d'une application avant d'écrire du code? Si UML est la voie à suivre, pouvez-vous recommander une introduction concise et pratique pour un développeur d'applications de petite taille?
J'apprécie votre contribution.
Je trouve vraiment qu'un début d'écriture sur papier ou tableau blanc est vraiment crucial. Passez ensuite à UML si vous le souhaitez, mais rien ne vaut la flexibilité de simplement le dessiner à la main au début.
Je considère ce qui suit:
- ce que le système est censé faire, c'est-à-dire quel est le problème que le système essaie de résoudre
- qui est le client et quels sont ses souhaits
- avec quoi le système doit s'intégrer
- y a-t-il des aspects hérités qui doivent être pris en compte
- quelles sont les interactions utilisateur
- etc...
Ensuite, je commence à regarder le système comme une boîte noire et:
- quelles sont les interactions qui doivent se produire avec cette boîte noire
- quels sont les comportements qui doivent se produire à l'intérieur de la boîte noire, c'est-à-dire ce qui doit arriver à ces interactions pour que la boîte noire présente le comportement souhaité à un niveau supérieur, par ex. recevoir et traiter les messages entrants d'un système de réservation, mettre à jour une base de données, etc.
Ensuite, cela commencera à vous donner une vue du système qui se compose de diverses boîtes noires internes, dont chacune peut être décomposée de la même manière.
UML est très bon pour représenter un tel comportement. Vous pouvez décrire la plupart des systèmes en utilisant simplement deux des nombreux composants d'UML, à savoir:
- diagrammes de classes, et
- diagrammes de séquence.
Vous pouvez également avoir besoin de diagrammes d'activité s'il existe un parallélisme dans le comportement qui doit être décrit.
Une excellente ressource pour apprendre UML est l'excellent livre de Martin Fowler "UML Distilled" ( lien Amazon - aseptisé pour le script kiddie link nazis là-bas (-:). Ce livre vous donne un aperçu rapide de l'essentiel parties de chacun des composants d'UML.
Oh. Ce que j'ai décrit est à peu près l'approche d'Ivar Jacobson. Jacobson est l'un des trois amigos d'OO. En fait, UML a été initialement développé par les deux autres personnes qui forment les Trois Amigos, Grady Booch et Jim Rumbaugh
Vous devriez certainement jeter un coup d'œil au Code Complete de Steve McConnell - et en particulier à son chapitre cadeau sur "Design in Construction"
Vous pouvez le télécharger depuis son site Internet:
Si vous développez pour .NET, Microsoft vient de publier (sous forme d'e-book gratuit!) Le Application Architecture Guide 2.0b1 . Il fournit de très bonnes informations sur la planification de votre architecture avant d'écrire du code.
Si vous étiez désespéré, je m'attends à ce que vous puissiez en utiliser de gros morceaux pour des architectures non basées sur .NET.
Je préfère ceci en disant que je fais principalement du développement Web où une grande partie de l'architecture est déjà décidée à l'avance (WebForms, maintenant MVC) et la plupart de mes projets sont des efforts d'une personne relativement petits qui prennent moins d'un an. Je sais également que j'aurai un ORM et un DAL pour gérer respectivement mon objet métier et l'interaction des données. Récemment, je suis passé à l'utilisation de LINQ pour cela, une grande partie de la "conception" devient la conception et le mappage de base de données via le concepteur DBML.
En règle générale, je travaille de manière TDD (test driven development). Je ne passe pas beaucoup de temps à l'avance à travailler sur les détails architecturaux ou de conception. Je rassemble l'interaction globale de l'utilisateur avec l'application via des histoires. J'utilise les histoires pour élaborer la conception d'interaction et découvrir les principaux composants de l'application. Je fais beaucoup de tableaux blancs au cours de ce processus avec le client - parfois en capturant des détails avec un appareil photo numérique s'ils semblent suffisamment importants pour rester sous forme de diagramme. Mes histoires sont principalement capturées sous forme d'histoire dans un wiki. Finalement, les histoires sont organisées en versions et itérations.
À cette époque, j'ai généralement une assez bonne idée de l'architecture. Si c'est compliqué ou qu'il y a des éléments inhabituels - des choses qui diffèrent de mes pratiques normales - ou si je travaille avec quelqu'un d'autre (pas typique), je vais schématiser les choses (encore une fois sur un tableau blanc). Il en va de même pour les interactions complexes - je peux concevoir la mise en page et le flux sur un tableau blanc, en le conservant (ou en le capturant via une caméra) jusqu'à ce que j'en ai terminé avec cette section. Une fois que j'aurai une idée générale de l'endroit où je vais et de ce qui doit être fait en premier, je commencerai à écrire des tests pour les premières histoires. Habituellement, cela se passe comme suit: "D'accord, pour ce faire, j'ai besoin de ces cours. Je vais commencer par celui-ci et il doit le faire." Ensuite, je commence joyeusement TDDing et l'architecture/design se développe à partir des besoins de l'application.
Périodiquement, je me retrouverai à vouloir réécrire quelques morceaux de code ou penser "ça sent vraiment" et je remanierai ma conception pour supprimer la duplication ou remplacer les bits puants par quelque chose de plus élégant. Surtout, je souhaite réduire la fonctionnalité tout en suivant de bons principes de conception. Je trouve que l'utilisation de modèles connus et l'attention portée aux bons principes au fur et à mesure fonctionnent assez bien.
http://dn.codegear.com/article/3186
J'utilise UML et je trouve ce guide assez utile et facile à lire. Faites-moi savoir si vous avez besoin de quelque chose de différent.
"Les tableaux blancs, les croquis et les post-it sont d'excellents outils de conception. Les outils de modélisation compliqués ont tendance à être plus distrayants qu'éclairants." De Pratiques d'un développeur agile par Venkat Subramaniam et Andy Hunt .
Je ne suis pas assez malin pour planifier plus que peu. Quand je planifie à l'avance, mes plans sont toujours mauvais, mais maintenant j'ai passé n jours sur de mauvais plans. Ma limite semble être d'environ 15 minutes sur le tableau blanc.
En gros, je fais le moins de travail possible pour savoir si je vais dans la bonne direction.
Je regarde ma conception pour des questions critiques: quand A fait B à C, sera-t-il assez rapide pour D? Sinon, nous avons besoin d'un design différent. Il est possible de répondre à chacune de ces questions par un pic. Si les pointes semblent bonnes, nous avons le design et il est temps de l'étendre.
Je code dans le sens d'obtenir une valeur réelle pour le client dès que possible, afin qu'un client puisse me dire où je dois aller.
Parce que je me trompe toujours, je compte sur la refactorisation pour m'aider à les corriger. Le refactoring est risqué, je dois donc passer des tests unitaires au fur et à mesure. Écrire des tests unitaires après coup est difficile à cause du couplage, donc j'écris d'abord mes tests. Rester discipliné à ce sujet est difficile, et un cerveau différent voit les choses différemment, donc j'aime avoir un copain codant avec moi. Mon copain de codage a un nez, donc je me douche régulièrement.
Appelons cela "Extreme Programming".
UML est une notation. C'est une façon d'enregistrer votre design, mais pas (à mon avis) de faire un design. Si vous avez besoin d'écrire des choses, je recommanderais UML, non pas parce que c'est le "meilleur" mais parce que c'est un standard que d'autres savent probablement déjà lire, et il vaut mieux inventer votre propre "standard".
Je pense que la meilleure introduction à UML est toujours ML Distilled , par Martin Fowler, parce qu'il est concis, donne des conseils pratiques sur où l'utiliser et indique clairement que vous n'avez pas à acheter dans l'ensemble Histoire UML/RUP pour qu'elle soit utile
Faire du design est difficile, il ne peut pas vraiment être capturé dans une seule réponse StackOverflow. Malheureusement, mes compétences en conception, telles qu'elles sont, ont évolué au fil des ans et je n'ai donc pas une seule source à laquelle je peux vous référer.
Cependant, un modèle que j'ai trouvé utile est l'analyse de robustesse (google pour cela, mais il y a une intro ici ). Si vous avez vos cas d'utilisation pour ce que le système devrait faire, un modèle de domaine de ce qui est impliqué, alors j'ai trouvé l'analyse de robustesse un outil utile pour connecter les deux et déterminer ce que les composants clés du système doivent être. .
Mais le meilleur conseil est lu largement, réfléchissez bien et pratiquez. Ce n'est pas une compétence purement enseignable, vous devez le faire.
Je ne suis pas convaincu quoi que ce soit peut être planifié à l'avance avant la mise en œuvre. J'ai 10 ans d'expérience, mais cela n'a été que dans 4 entreprises (dont 2 sites dans une entreprise, qui étaient presque des opposés polaires), et presque toute mon expérience a été en termes de regarder un cluster colossal ****** ** s se produisent. Je commence à penser que des trucs comme le refactoring sont vraiment la meilleure façon de faire les choses, mais en même temps je me rends compte que mon expérience est limitée, et je pourrais juste réagir à ce que j'ai vu. Ce que j'aimerais vraiment savoir, c'est comment acquérir la meilleure expérience possible afin que je puisse arriver à des conclusions correctes, mais il semble qu'il n'y ait pas de raccourci et cela implique juste beaucoup de temps à voir les gens faire les choses mal :(. J'aimerais vraiment essayer de travailler dans une entreprise où les gens font bien les choses (comme en témoignent les déploiements de produits réussis), pour savoir si je suis juste un salaud contrariant, ou si je suis vraiment aussi intelligent que je le pense Je suis.
Je fais de l'architecture depuis un moment. J'utilise BPML pour affiner d'abord le processus métier, puis j'utilise UML pour capturer divers détails! La troisième étape est généralement ERD! Au moment où vous avez terminé avec BPML et UML, votre ERD sera assez stable! Aucun plan n'est parfait et aucune abstraction ne sera à 100%. Prévoyez une refactorisation, l'objectif est de minimiser au maximum la refactorisation!
Je vous prie de différer: UML peut être utilisé pour l'architecture d'application, mais est plus souvent utilisé pour l'architecture technique (frameworks, diagrammes de classe ou de séquence, ...), car c'est là que ces diagrammes peuvent le plus facilement être synchronisés avec le développement .
Architecture d'application se produit lorsque vous prenez certaines spécifications fonctionnelles (qui décrivent la nature et les flux des opérations sans faire d'hypothèses sur un avenir et vous les transformez en spécifications techniques.
Ces spécifications représentent les applications dont vous avez besoin pour implémenter certains besoins commerciaux et fonctionnels.
Donc, si vous devez traiter plusieurs grands portefeuilles financiers (spécification fonctionnelle), vous pouvez déterminer que vous devez diviser cette grande spécification en:
- un répartiteur pour affecter ces calculs lourds à différents serveurs
- un lanceur pour vous assurer que tous les serveurs de calcul sont opérationnels avant de commencer à traiter ces portefeuilles.
- une interface graphique pour pouvoir montrer ce qui se passe.
- un composant "commun" pour développer les algorithmes spécifiques du portefeuille, indépendamment du reste de l'architecture de l'application, afin de faciliter les tests unitaires, mais aussi certains tests fonctionnels et de régression.
Donc, en gros, penser à architecture d'application, c'est décider quel "groupe de fichiers" vous devez développer dans un manière cohérente (vous ne pouvez pas développer dans le même groupe de fichiers un lanceur, une interface graphique, un répartiteur, ...: ils ne pourraient pas évoluer au même rythme)
Lorsqu'une architecture d'application est bien définie, chacun de ses composants est généralement un bon candidat pour un composant configuration, c'est-à-dire un groupe de fichiers qui peut être versionné comme un tout dans un VCS (Version Control System), ce qui signifie all ses fichiers seront étiquetés ensemble chaque fois que vous aurez besoin d'enregistrer un instantané de cette application (encore une fois, il serait difficile d'étiqueter all votre système, chacune de ses applications ne peut pas être dans un état stable en même temps)
J'essaie de décomposer ma pensée en deux domaines: une représentation des choses que j'essaie de manipuler et ce que j'ai l'intention d'en faire.
Lorsque j'essaie de modéliser ce que j'essaie de manipuler, je propose une série de définitions d'articles discrets - un site de commerce électronique aura une référence, un produit, un client, etc. J'aurai aussi des choses non matérielles avec lesquelles je travaille - une commande ou une catégorie. Une fois que j'ai tous les "noms" dans le système, je vais créer un modèle de domaine qui montre comment ces objets sont liés les uns aux autres - une commande a un client et plusieurs SKU, de nombreux skus sont regroupés dans un produit, et ainsi sur.
Ces modèles de domaine peuvent être représentés comme des modèles de domaine UML, des diagrammes de classes et des ERD SQL.
Une fois que j'ai compris les noms du système, je passe aux verbes - par exemple, les opérations que chacun de ces éléments traverse pour valider une commande. Ceux-ci sont généralement assez bien mappés pour utiliser les cas de mes exigences fonctionnelles - la manière la plus simple de les exprimer que j'ai trouvée est les diagrammes de séquence UML, d'activité ou de collaboration ou les diagrammes de couloirs.
Il est important de considérer cela comme un processus itératif; Je vais faire un petit coin du domaine, puis travailler sur les actions, puis revenir en arrière. Idéalement, j'aurai le temps d'écrire du code pour essayer des trucs au fur et à mesure - vous ne voulez jamais que le design devienne trop en avance sur l'application. Ce processus est généralement terrible si vous pensez que vous construisez l'architecture complète et finale pour tout; vraiment, tout ce que vous essayez de faire, c'est d'établir les bases de base que l'équipe partagera en commun au cours de son développement. Vous créez principalement un vocabulaire partagé à utiliser par les membres de l'équipe lorsqu'ils décrivent le système, et non pas à définir la loi sur la façon dont cela doit être fait.
J'ai du mal à bien réfléchir à un système avant de le coder. Il est tout simplement trop facile de ne jeter qu'un coup d'œil rapide sur certains composants dont vous vous rendez compte plus tard qu'ils sont beaucoup plus compliqués que vous ne le pensiez.
Une solution est d'essayer vraiment fort. Écrivez UML partout. Passez par chaque classe. Pensez à la façon dont il interagira avec vos autres classes. C'est difficile à faire.
Ce que j'aime faire, c'est d'abord faire un aperçu général. Je n'aime pas UML, mais j'aime dessiner des diagrammes qui font passer le message. Ensuite, je commence à le mettre en œuvre. Même lorsque j'écris simplement la structure de la classe avec des méthodes vides, je vois souvent des choses que j'ai manquées plus tôt, alors je mets à jour ma conception. En codant, je me rendrai compte que je dois faire quelque chose différemment, donc je mettrai à jour ma conception. C'est un processus itératif. Le concept de "tout concevoir d'abord, puis de tout mettre en œuvre" est connu sous le nom de modèle en cascade, et je pense que d'autres ont montré que c'était une mauvaise façon de faire un logiciel.
Essayez Archimate.