Comment planifier l'architecture d'une application avant d'écrire un code? [fermé]

je considère ce qui suit:

1. ce que le système est censé faire, c'est, qu'est-ce que le problème est que le système est en train d'essayer de régler les
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 de l'héritage qui doivent être pris en considération
5. quelles sont les interactions de l'utilisateur
6. etc...

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

1. quelles sont les interactions qui doivent passer avec cette boîte noire
2. quels sont les comportements qui doivent se produire à l'intérieur de la boîte noire, c.-à-d. ce qui doit se produire lors de ces interactions pour que la boîte noire affiche le comportement désiré à un niveau plus élevé, p. ex. recevoir et traiter les messages entrants d'un système de réservation, mettre à jour une base de données etc.

alors 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 plus loin dans 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 seulement deux des nombreux composants de UML, à savoir:

• class diagrammes, et
Diagrammes de séquence
• .

vous pouvez également avoir besoin de diagrammes d'activités s'il y a un parallélisme dans le comportement qui doit être décrit.

Une bonne ressource pour l'apprentissage de l'UML est Martin Fowler excellent livre "UML Distillée" ( lien Amazon - juste pour le script kiddie lien nazis (-: ). Ce livre vous donne un aperçu des éléments essentiels de chacun des composants de UML.

Oh. Ce que j'ai décrit est à peu près Ivar Jacobson. Jacobson est l'un des trois Amigos de 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 oeil au Code complet de Steve McConnell- et surtout à son chapitre giveaway sur "Design in Construction"

vous pouvez le télécharger à partir de son site web:

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

si vous développez pour .NET, Microsoft viennent de publier (comme un e-book gratuit!) le l'Architecture de l'Application du Guide 2.0b1 . Il fournit des tas de très bonnes informations sur la planification de votre architecture avant d'écrire n'importe quel code.

si vous étiez désespéré, je m'attends à ce que vous puissiez utiliser de grandes portions de celui-ci pour des architectures non basées sur.NET.

je vais commencer ceci en disant que je fais principalement le développement web où une grande partie de l'architecture est déjà décidée à l'avance (formulaires Web, maintenant MVC) et la plupart de mes projets sont raisonnablement Petits, des efforts d'une personne qui prennent moins d'un an. Je sais aussi que je vais avoir un ORM et un DAL pour gérer mon objet d'affaires et l'interaction de données, respectivement. Récemment, je suis passé à L'utilisation de LINQ pour cela, une grande partie du "design" devient la conception de base de données et la cartographie via le designer DBML.

en général, je travaille D'une manière TDD (test driven development). Je ne passe pas beaucoup de temps à travailler sur des détails d'architecture ou de design. Je ne recueille 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 whiteboarding pendant ce processus avec le client -- parfois capturer des détails avec un appareil photo numérique si elles semblent suffisamment important pour garder sous forme de diagramme. Principalement mes histoires sont capturées sous forme d'histoire dans un wiki. Finalement, les histoires s'organisent en versions et itérations.

à ce moment-là, j'ai habituellement une assez bonne idée de l'architecture. Si c'est compliqué ou s'il y a des choses inhabituelles -- des choses qui diffèrent de mes pratiques normales -- ou si je travaille avec quelqu'un d'autre (pas typique), je vais dessiner des choses (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 flux sur un tableau blanc, en le gardant (ou en le capturant par caméra) jusqu'à ce que j'en ai fini 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. D'habitude, ça fait: "OK, pour faire ça, j'ai besoin de ces cours. Je vais commencer avec celui-ci et il doit le faire."Ensuite, je commence à plaisanter et l'architecture / design se développe à partir des besoins de l'application.

périodiquement, je me retrouve à vouloir réécrire quelques morceaux de code ou à penser "ça sent vraiment" et je vais reformuler mon design pour supprimer la duplication ou remplacer les morceaux puants par quelque chose de plus élégant. La plupart du temps, je suis préoccupé par obtenir la fonctionnalité tout en suivant de bons principes de conception. Je trouve que l'utilisation de modèles connus et de prêter attention à de bons principes comme vous allez le long fonctionne assez bien.

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

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

" les planches blanches, les croquis et les notes Post-it sont un excellent design outils. Compliqué d'outils de modélisation ont tendance à être plus distrayant que d'éclairer."De pratiques D'un développeur Agile par Venkat Subramaniam et Andy Hunt .

UML est une notation. C'est une façon d'enregistrer votre dessin, mais pas (à mon avis) de faire un dessin. Si vous avez besoin d'écrire des choses, je recommande UML, cependant, pas parce que c'est le "meilleur", mais parce que c'est une norme que d'autres savent probablement déjà lire, et c'est mieux que d'inventer votre propre "norme".

je pense que la meilleure introduction à UML est encore UML distillé , par Martin Fowler, parce qu'il est concis, donne pratique des conseils pour l'utiliser, et il est clair que vous n'avez pas à acheter dans l'ensemble de l'UML/RUP histoire pour qu'il soit utile

faire le design est difficile.Il ne peut pas vraiment être capturé dans une réponse StackOverflow. Malheureusement, mes compétences en design, telles qu'elles sont, ont évolué au fil des ans et je n'ai donc pas une seule source à laquelle je peux vous adresser.

cependant, un modèle que j'ai trouvé utile est l'analyse de Robustesse (google pour elle, mais il ya 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 que les choses sont impliquées, alors j'ai trouvé l'analyse de Robustesse un outil utile pour relier les deux et de travailler sur ce que les composants clés du système doivent être.

mais le meilleur conseil est lu largement, pensez dur, et la pratique. Ce n'est pas une compétence purement didactique, il faut vraiment le faire.

Je ne suis pas convaincu que quelque chose can soit planifié à l'avance avant la mise en œuvre. J'ai 10 ans d'expérience, mais ça n'a été que dans 4 entreprises (y compris 2 sites dans une entreprise, qui étaient presque des opposés polaires), et presque toute mon expérience a été en termes de regarder colossal cluster********s se produisent. Je commence à penser que des choses comme le remaniement est 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 il se peut que je réagisse à ce que j'ai vu. Ce que j'aimerais vraiment savoir, c'est comment acquérir la meilleure expérience pour être en mesure d'arriver à des conclusions appropriées, mais il semble qu'il n'y ait pas de raccourci et que 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 les choses bien (comme en témoignent les déploiements réussis de produits), pour savoir si je suis juste un bâtard contrarien, ou si je suis vraiment aussi intelligent que je le pense.

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

fondamentalement, je fais aussi peu de travail que je peux 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? Si non, nous avons besoin d'une conception différente. Chacune de ces questions peut être répondue avec une pointe. Si les piques semblent bonnes, alors nous avons le design et il est temps d'étendre sur elle.

je code dans le sens d'obtenir une valeur client réelle le plus tôt possible, afin qu'un client puisse me dire où je devrais aller.

parce que je me trompe toujours, je compte sur le remaniement pour m'aider à faire les bonnes choses. Le remaniement est risqué, donc je dois faire des tests à l'unité. Écrire des tests unitaires après le fait est difficile en raison de l'accouplement, donc je écris mes tests en premier. Rester discipliné à ce sujet est difficile, et un cerveau différent voit les choses différemment, donc j'aime avoir un ami codant avec moi. Mon pote de codage A un nez, donc je me douche régulièrement.

appelons-le"Programmation extrême".

Je ne suis pas d'accord: UML peut être utilisé pour l'architecture d'application, mais est plus souvent utilisé pour l'architecture technique (cadres, diagrammes de classe ou de séquence, ...), parce que c'est là où ces diagrammes peuvent plus facilement en phase 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 aucune des hypothèses concernant l'avenir de mise en œuvre), et vous transformer en spécifications techniques.

Ces caractéristiques représentent les applications dont vous avez besoin pour mise en œuvre certaines entreprises et les besoins fonctionnels.

donc, si vous avez besoin de traiter plusieurs grands portefeuilles financiers (spécification fonctionnelle), vous pouvez déterminer que vous avez besoin de diviser cette grande spécification en:

• un répartiteur pour attribuer ces lourds calculs pour différents serveurs
• un lanceur pour s'assurer que tous les serveurs de calcul sont opérationnels avant de commencer à traiter ces portfolios.
• un GUI pour être en mesure de montrer ce qui se passe.
• un composant "commun" pour développer les algorithmes de portfolio spécifiques, indépendamment du reste de l'architecture d'application, afin de faciliter les tests unitaires, mais aussi quelques tests de fonctionnement et de régression.

donc fondamentalement, penser à architecture d'application est de décider quel" groupe de fichiers " vous devez développer d'une manière cohérente (vous ne pouvez pas développer dans le même groupe de fichiers un lanceur, Un GUI, un répartiteur, ...: ils ne seraient pas en mesure d'évoluer au même rythme)

Lorsqu'une architecture d'application est bien définie, chacune de ses components est généralement un bon candidat pour un configuration composant, qui est un groupe de fichier qui peut être versionné comme un tout dans un VCS (système de contrôle de Version), ce qui signifie tous ses fichiers seront étiquetés ensemble chaque fois que vous avez besoin d'enregistrer un instantané de cette application (encore une fois, il serait difficile d'étiqueter tous votre système, chacun de son application ne peut pas être dans un état stable en même temps)

je fais de l'architecture depuis un moment. J'utilise D'abord BPML pour affiner le processus d'affaires et ensuite UML pour capturer divers détails! La troisième étape est généralement la Dre! Lorsque vous aurez terminé avec BPML et UML, votre DRE sera assez stable! Aucun plan n'est parfait et aucune abstraction ne sera à 100%. Planifier le remaniement, le but est de minimiser le remaniement autant que possible!

j'essaie de décomposer ma réflexion en deux domaines: une représentation des choses que j'essaie de manipuler, et ce que j'ai l'intention de faire avec elles.

quand j'essaie de modéliser les choses que j'essaie de manipuler, je trouve une série de définitions d'éléments discrets - un site de commerce électronique aura un SKU, un produit, un client, et ainsi de suite. 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 faire un modèle de domaine qui montre comment ces objets sont liés entre eux - une commande a un client et plusieurs SKUs, beaucoup de skus sont regroupés dans un produit, et ainsi de suite.

ces modèles de domaines peuvent être représentés sous forme de modèles de domaines UML, de diagrammes de classes et de SQL ERD.

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 passent pour commettre un ordre. Il s'agit généralement de mappez assez bien pour utiliser des cas de mes exigences fonctionnelles - la façon la plus facile d'exprimer ces que j'ai trouvé est la séquence UML, des diagrammes d'activité ou de collaboration ou des diagrammes de natation.

il est important de penser à ceci comme un processus itératif; je vais faire un petit coin du domaine, puis travailler sur les actions, et puis revenir en arrière. Idéalement, je vais avoir le temps d'écrire le code pour essayer des choses que je vais le long - vous ne voulez jamais le design pour aller trop loin en avance de l'application. Ce processus est habituellement terrible si vous pensez que vous construisez l'architecture complète et finale pour tout; vraiment, tout ce que vous essayez de faire est d'établir les bases de base que l'équipe partagera en commun pendant qu'ils se déplacent à travers le développement. Vous créez principalement un vocabulaire partagé pour les membres de l'équipe à utiliser comme ils décrivent le système, pas de fixer la loi pour la façon dont il doit être fait.

j'ai du mal à imaginer un système avant de le coder. Il est tout simplement trop facile d'apporter seulement un coup d'oeil superficiel à certains composants que vous réalisez seulement plus tard sont beaucoup plus compliqués que vous pensiez qu'ils étaient.

une solution est de juste essayer vraiment dur. Écrivez UML partout. Aller à travers chaque classe. Pensez comment il va interagir avec vos autres classes. Cela est difficile à faire.

Ce que j'aime faire est de faire une générale vue d'ensemble au premier abord. Je n'aime pas UML, mais j'aime dessiner des diagrammes qui font passer le point. Puis je commence à la mettre en œuvre. Même si je suis juste en train d'écrire 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 mon design. Je vais réaliser que j'ai besoin de faire quelque chose de différent, donc je vais mettre à jour mon design. C'est un processus itératif . Le concept de "tout concevoir d'abord, puis mettre en œuvre tout" est connu sous le nom de modèle en cascade, et je pense que d'autres ont montré que c'est une mauvaise façon de faire du logiciel.

Essayez Archimate.