Comment planifier l’architecture d’une application avant d’écrire du code?

Une chose avec laquelle j’ai du mal à planifier l’architecture d’une application avant d’écrire du code.

Je ne veux pas dire qu’il faut rassembler des exigences pour préciser ce que l’application doit faire, mais plutôt réfléchir à une bonne manière d’établir la structure globale des classes, des données et des stream, et d’parsingr ces idées pour avoir un plan crédible. action en tête avant même d’ouvrir l’IDE. Pour le moment, il est facile d’ouvrir simplement l’EDI, de créer un projet vierge, de commencer à écrire des bits et des bobs et de laisser la conception se développer à partir de là.

Je pense que l’UML est une façon de faire cela, mais je n’ai aucune expérience avec cela, donc cela semble plutôt nébuleux.

Comment planifier 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 de petites applications?

J’apprécie votre consortingbution.

Je trouve vraiment que le premier écrit sur papier ou tableau blanc est vraiment crucial. Passez ensuite à UML si vous le souhaitez, mais rien ne vaut la flexibilité de le dessiner à la main.

Je considère ce qui suit:

  1. ce que le système est censé faire, c’est-à-dire quel est le problème que le système tente de résoudre
  2. qui est le client et quels sont ses souhaits
  3. ce que le système doit intégrer avec
  4. Y a-t-il des aspects hérités à prendre en compte
  5. quelles sont les interactions utilisateur
  6. etc…

Puis je commence à regarder le système comme une boîte noire et:

  1. Quelles sont les interactions qui doivent se produire avec cette boîte noire
  2. Quels sont les comportements qui doivent se produire dans la boîte noire, c.-à-d. ce qui doit arriver à ces interactions pour que la boîte noire présente le comportement souhaité à un niveau supérieur, par exemple, recevoir et traiter les messages entrants d’un système de réservation .

Ensuite, cela va commencer à vous donner une vue du système qui se compose de différentes boîtes noires internes, chacune pouvant être décomposée de la même manière.

UML est très bien pour représenter un tel comportement. Vous pouvez décrire la plupart des systèmes en utilisant deux des nombreux composants de UML, à savoir:

  • diagrammes de classes et
  • diagrammes de séquence.

Vous aurez peut-être aussi besoin de diagrammes d’activité s’il y a un parallélisme dans le comportement à décrire.

L’excellent livre de Martin Fowler, “UML Distilled”, est une bonne ressource pour apprendre UML (ce lien vous donne un aperçu des parties essentielles de chacun des composants de UML.

Oh. Ce que j’ai décrit est à peu près l’approche de 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 Three 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 sur le «Design in Construction».

Vous pouvez le télécharger depuis son site web:

http://cc2e.com/File.ashx?cid=336

Si vous développez pour .NET, Microsoft vient de publier (sous forme de livre électronique gratuit!) Le Guide d’architecture d’application 2.0b1 . Il fournit des informations très utiles sur la planification de votre architecture avant d’écrire du code.

Si vous étiez désespéré, je pense que vous pourriez en utiliser de gros morceaux pour des architectures non basées sur .NET.

Je vais commencer par dire 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 relativement modestes et nécessitent moins d’une année. Je sais également que j’aurai un ORM et un DAL pour gérer respectivement mon object métier et l’interaction de données. Récemment, je suis passé à l’utilisation de LINQ pour cela, une grande partie de la “conception” devient la conception de firebase database et le mappage via le concepteur DBML.

En règle générale, je travaille de manière TDD (test piloted development). Je ne passe pas beaucoup de temps à travailler sur des 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 le design d’interaction et découvrir les principaux composants de l’application. Je fais beaucoup de tableau blanc au cours de ce processus avec le client – capturant parfois des détails avec un appareil photo numérique si cela semble assez important pour restr sous forme de diagramme. Principalement mes histoires sont capturées sous forme de récit dans un wiki. Finalement, les histoires s’organisent en versions et en itérations.

A cette époque, j’ai généralement une bonne idée de l’architecture. Si c’est compliqué ou s’il y a des éléments inhabituels – des choses qui diffèrent de mes pratiques habituelles – ou je travaille avec quelqu’un d’autre (pas typique), je vais schématiser (encore une fois sur un tableau blanc). Il en va de même pour les interactions compliquées. Je peux concevoir la mise en page et le stream 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 ce que je vais faire 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’aurai besoin de ces cours. Je vais commencer par celui-ci et il doit le faire.” Ensuite, je commence joyeusement TDDing et l’architecture / la conception se développe à partir des besoins de l’application.

Périodiquement, je vais me retrouver à écrire des bouts de code ou penser que “ça sent vraiment” et je vais refactoriser mon design pour supprimer les doublons ou remplacer les bits malodorants par quelque chose de plus élégant. Généralement, je m’inquiète de réduire la fonctionnalité tout en suivant les principes de conception. Je trouve que l’utilisation de modèles connus et l’attention scope aux bons principes au fur et à mesure que vous avancez fonctionnent assez bien.

http://dn.codegear.com/article/31863

J’utilise UML et trouve ce guide très utile et facile à lire. Faites-moi savoir si vous avez besoin de quelque chose de différent.

“Les tableaux blancs, les esquisses et les notes post-it sont d’excellents outils de conception. Les outils de modélisation compliqués ont tendance à être plus distrayants qu’illuminants.” Des pratiques d’un développeur agile par Venkat Subramaniam et Andy Hunt .

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 les choses, je recommanderais UML, non pas parce que c’est le “meilleur” mais parce que c’est un standard que les autres savent probablement déjà lire, et il vaut mieux inventer votre propre “standard”.

Je pense que la meilleure introduction à UML est encore UML Distilled , de Martin Fowler, car il est concis, donne des conseils pratiques sur l’utilisation, et indique clairement que vous n’avez pas à acheter toute l’histoire UML / RUP. sois utile

Faire de la conception est difficile.Il ne peut pas vraiment être capturé dans une réponse StackOverflow. Malheureusement, mes compétences en matière de conception, telles qu’elles sont, ont évolué au fil des ans et je n’ai donc aucune source à laquelle je puisse vous référer.

Cependant, un modèle que j’ai trouvé utile est l’parsing de robustesse (google pour cela, mais il y a une introduction ici ). Si vous avez des exemples d’utilisation de ce que le système doit faire, un modèle de domaine de ce qui est impliqué, j’ai trouvé l’parsing de robustesse un outil utile pour relier les deux et déterminer les composants clés du système. .

Mais le meilleur conseil est de lire largement, de réfléchir et de pratiquer. Ce n’est pas une compétence purement enseignable, vous devez réellement le faire.

Je ne suis pas convaincu que quelque chose puisse être planifié avant la mise en œuvre. J’ai 10 ans d’expérience, mais ce n’est que dans 4 sociétés (dont 2 sites dans une entreprise, qui étaient presque totalement opposées), et la quasi-totalité de mon expérience a consisté à regarder un cluster colossal ****** ** s se produisent. Je commence à penser que des choses 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 que je réagis peut-être juste à ce que j’ai vu. Ce que je voudrais vraiment savoir, c’est comment obtenir la meilleure expérience possible, alors je peux arriver à des conclusions correctes, mais il semble qu’il n’y ait pas de raccourci et que cela demande beaucoup de temps à voir des gens faire des erreurs :(. voudrais vraiment essayer de travailler dans une entreprise où les gens font les choses correctement (comme le prouve le succès des déploiements de produits), pour savoir si je suis un bâtard à contre-courant ou si je suis aussi intelligent que je le pense Je suis.

Je ne suis pas assez intelligent pour planifier d’avance plus qu’un peu. Quand je planifie à l’avance, mes plans sont toujours erronés, mais j’ai passé des jours sur de mauvais plans. Ma limite semble être d’environ 15 minutes sur le tableau blanc.

Fondamentalement, je fais le moins de travail possible pour savoir si je vais dans la bonne direction.

Je regarde ma conception pour les questions critiques: quand A fait B à C, sera-t-il assez rapide pour D? Sinon, nous avons besoin d’un design différent. Chacune de ces questions peut être une réponse avec un pic. Si les pointes semblent bonnes, alors nous avons le design et il est temps de le développer.

Je code dans le sens d’obtenir une réelle valeur client dès que possible, afin qu’un client puisse me dire où je devrais aller.

Parce que je me trompe toujours, je compte sur le refactoring pour m’aider à bien les résoudre. Le refactoring est risqué, je dois donc écrire des tests unitaires. L’écriture des tests unitaires après le fait est difficile à cause du couplage, donc j’écris d’abord mes tests. Rester discipliné à propos de ce genre de choses est difficile, et un cerveau différent voit les choses différemment, alors j’aime bien avoir un contact avec moi. Mon copain de codage a un nez, alors je prends une douche régulièrement.

Appelons ça “Extreme Programming”.

Je ne suis pas d’accord: UML peut être utilisé pour l’architecture des applications, mais il est plus souvent utilisé pour les architectures techniques (frameworks, diagrammes de classes ou de séquences, …), car ces diagrammes peuvent être facilement synchronisés avec le développement. .

L’architecture d’application se produit lorsque vous prenez des spécifications fonctionnelles (qui décrivent la nature et les stream des opérations sans faire d’hypothèses sur une future mise en œuvre) et vous les transformez en spécifications techniques.

Ces spécifications représentent les applications dont vous avez besoin pour mettre en œuvre certains besoins métier et fonctionnels.

Donc, si vous devez traiter plusieurs grands portefeuilles financiers (spécifications fonctionnelles), vous pouvez déterminer que vous devez diviser cette spécification importante en:

  • un répartiteur pour atsortingbuer ces calculs lourds à différents serveurs
  • un lanceur pour s’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 de portefeuille spécifiques, indépendamment du rest de l’architecture de l’application, afin de faciliter les tests unitaires, mais aussi certains tests fonctionnels et de régression.

Donc, fondamentalement, penser à l’ architecture de l’application revient à décider quel “groupe de fichiers” vous devez développer de manière cohérente (vous ne pouvez pas développer dans un même groupe de fichiers un lanceur, une interface graphique, un répartiteur, …). ne pourrait 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 de configuration , c’est-à-dire un groupe de fichiers pouvant être versé en tant que tout dans un système VCS (Version Control System). étiquetés ensemble chaque fois que vous avez besoin d’enregistrer un instantané de cette application (encore une fois, il serait difficile d’étiqueter tout votre système, chacune de ses applications ne peut pas être dans un état stable en même temps)

Je fais de l’architecture depuis un moment. J’utilise BPML pour d’abord affiner le processus métier, puis utiliser 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%. Planifier le refactoring, l’objective est de minimiser le refactoring autant que possible!

J’essaie de décomposer ma reflection en deux parties: une représentation des choses que j’essaie de manipuler et ce que j’ai l’intention de faire avec elles.

Lorsque j’essaie de modéliser les éléments que j’essaie de manipuler, je propose une série de définitions d’éléments discrets: un site de commerce électronique aura une SKU, un produit, un client, etc. Je vais aussi avoir 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 objects sont liés les uns aux autres – une commande a un client et plusieurs SKU, de nombreux skus sont regroupés dans un produit, etc. sur.

Ces modèles de domaine peuvent être représentés sous forme de modèles de domaine UML, de diagrammes de classes et de DRE SQL.

Une fois que les noms du système sont compris, je passe aux verbes, par exemple, les opérations que chacun de ces éléments passe pour passer une commande. Celles-ci correspondent généralement à des cas d’utilisation de mes exigences fonctionnelles. La manière la plus simple de les exprimer est celle des diagrammes de séquence, d’activité ou de collaboration UML ou des diagrammes de couloir.

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. Dans l’idéal, j’aurai le temps d’écrire du code pour essayer des choses au fur et à mesure, car 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; En fait, tout ce que vous essayez de faire, c’est d’établir les bases de base que l’équipe partagera au fur et à mesure de son développement. Vous créez principalement un vocabulaire partagé à utiliser par les membres de l’équipe pour décrire le système, sans définir la loi à suivre.

J’ai du mal à penser complètement à un système avant de le coder. Il est trop facile d’apporter un coup d’œil rapide à certains composants que vous réalisez plus tard sont beaucoup plus compliqués que vous le pensiez.

Une solution consiste à simplement essayer vraiment fort. Écrivez UML partout. Parcourez chaque classe. Pensez à la façon dont il va interagir avec vos autres classes. C’est difficile à faire.

Ce que j’aime faire, c’est faire une vue d’ensemble au début. Je n’aime pas UML, mais j’aime bien dessiner des diagrammes pour faire passer le message. Ensuite, je commence à le mettre en œuvre. Même si j’écris simplement la structure de la classe avec des méthodes vides, je vois souvent des choses qui me manquaient plus tôt, alors je mets à jour mon design. En codant, je me rendrai compte que je dois faire quelque chose différemment, alors je vais mettre à jour mon design. C’est un processus itératif . Le concept de «tout concevoir en premier lieu, 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 du logiciel.

Essayez Archimate.