Conception logicielle ou architecture logicielle
Quelqu'un pourrait-il expliquer la différence entre la conception logicielle et l'architecture logicielle?
Plus précisement; si vous demandez à quelqu'un de vous présenter le "design", que voudriez-vous qu'il présente? Il en va de même pour 'architecture'.
Ma compréhension actuelle est:
- Conception: diagramme UML/diagramme de flux/structures filaires simples (pour l'interface utilisateur) pour un module/une partie spécifique du système
- Architecture: diagramme de composants (montrant comment les différents modules du système communiquent entre eux et avec d'autres systèmes), quel langage doit être utilisé, modèles ...?
Corrige moi si je me trompe. J'ai référé à Wikipédia qui a publié des articles sur http://en.wikipedia.org/wiki/Software_design et http://en.wikipedia.org/wiki/Software_architecture , mais Je ne sais pas si je les ai bien comprises.
Tu as raison oui. L'architecture d'un système est son "squelette". C'est le plus haut niveau d'abstraction d'un système. Quel type de stockage de données est présent, comment les modules interagissent-ils entre eux, quels systèmes de récupération sont en place. Tout comme les modèles de conception, il existe des modèles architecturaux: MVC, conception en couches à 3 niveaux, etc.
La conception logicielle consiste à concevoir les modules/composants individuels. Quelles sont les responsabilités, les fonctions du module x? De classe Y? Que peut-il faire et quoi pas? Quels modèles de conception peuvent être utilisés?
En bref, l'architecture logicielle concerne davantage la conception de l'ensemble du système, tandis que la conception logicielle met l'accent sur le niveau module/composant/classe.
Dans certaines descriptions de SDLC (cycle de vie du développement de logiciel) , elles sont interchangeables, mais il est évident qu'elles sont distinctes. Ils sont à la fois: différents (1) étapes , (2) zones de responsabilité et (3) niveaux de prise de décision .
- Architecture est la vue d'ensemble: le choix des cadres, des langages, de la portée, des objectifs et des méthodologies de haut niveau ( Rational , cascade , - agile , etc.).
- Design est la plus petite image: le plan de la façon dont le code sera organisé; à quoi ressembleront les contrats entre les différentes parties du système; l'implémentation en cours des méthodologies et des objectifs du projet. Les spécifications sont écrites pendant cette étape.
Ces deux étapes sembleront se mélanger pour des raisons différentes.
- Les projets plus petits n’ont souvent pas la possibilité de séparer la planification en étapes.
- Un projet peut faire partie d'un projet plus vaste et, par conséquent, une partie des deux étapes est déjà décidée. (Il existe déjà des bases de données, conventions, normes, protocoles, frameworks, code réutilisable, etc.)
- Les nouvelles façons de penser à la SDLC (voir Méthodologies Agiles ) réorganisent quelque peu cette approche traditionnelle. La conception (dans une moindre mesure l’architecture) est intentionnelle dans tout le SDLC . Il y a souvent plus de itérations où tout le processus se répète.
- Le développement de logiciels est compliqué et difficile à planifier de toute façon, mais les clients/responsables/vendeurs le rendent généralement plus difficile en modifiant les objectifs et les exigences à mi-parcours. Les décisions de conception et même d’architecture doivent être effectuées ultérieurement dans le projet, qu’il s’agisse ou non du plan.
Même si les étapes ou les domaines de responsabilité se mélangent et se produisent partout, il est toujours bon de savoir quel niveau de prise de décision est en cours. (Nous pourrions continuer indéfiniment avec ceci. J'essaie de garder un résumé.) Je terminerai par: Même s'il semble que votre projet n'a pas d'étape formelle d'architecture ou de conception/AOR/documentation, il IS Que cela se produise, que quelqu'un le fasse consciemment ou non. Si personne ne décide de faire de l'architecture, il se produit un défaut qui est probablement médiocre. Idem pour le design. Ces concepts sont presque plus importants s’il n’ya pas d’étapes formelles les représentant.
L'architecture est stratégique, tandis que le design est tactique.
L'architecture comprend les frameworks, les outils, les paradigmes de programmation, les normes d'ingénierie logicielle à base de composants, les principes de haut niveau.
Alors que la conception est une activité liée aux contraintes locales, telles que les modèles de conception, les idiomes de programmation et les refactorisations.
J'ai trouvé cela alors que je cherchais moi-même une distinction simple entre l'architecture et le design;
Que pensez-vous de cette façon de les regarder:
- l'architecture est "ce que" nous construisons;
- le design est "comment" nous construisons;
L'architecture désigne la structure conceptuelle et l'organisation logique d'un ordinateur ou d'un système informatique.
Conception désigne un plan ou un dessin produit pour montrer l'aspect et la fonction ou le fonctionnement d'un système ou d'un objet avant sa fabrication.
Si vous "concevez" un composant, vous définissez son comportement dans le système plus vaste.
Si vous "concevez" le même composant, vous définissez son comportement interne.
Toute architecture est design mais tout design n'est pas architecture.
La partie What est la conception, la How est la mise en œuvre concrète et l'intersection de What et How est l'Architecture.
Image pour différencier l'architecture et la conception :
Il y a également des décisions de conception, qui ne sont pas significatives sur le plan architectural, c'est-à-dire qui n'appartiennent pas à la branche architecture de la conception. Par exemple, les décisions de conception interne de certains composants, telles que le choix de l’algorithme, la sélection de la structure de données, etc.
Toute décision de conception qui n’est pas visible en dehors de la limite de son composant est une conception interne du composant et n’est pas architecturale. Telles sont les décisions de conception laissées par un architecte système à la discrétion du concepteur de modules ou de l’équipe de mise en œuvre, à condition que leur conception ne brise pas les contraintes architecturales imposées par l’architecture de niveau système.
Le lien qui donne bonne analogie
Je dirais que vous avez raison, avec mes propres mots;
Architecture correspond à l'affectation de la configuration système requise aux éléments du système. Quatre déclarations sur une architecture:
- Il peut introduire des exigences non fonctionnelles telles que le langage ou les modèles.
- Il définit l'interaction entre les composants, les interfaces, la synchronisation, etc.
- Il ne doit pas introduire de nouvelles fonctionnalités,
- Il attribue les fonctions (conçues) que le système est censé exécuter pour les éléments.
L'architecture est une étape d'ingénierie essentielle quand une complexité du système est subdivisée.
Exemple: Pensez à votre maison, vous n'avez pas besoin d'architecte pour votre cuisine (un seul élément est impliqué), mais le bâtiment complet nécessite des définitions d'interaction, telles que des portes et un toit .
Design est une représentation informative de la mise en oeuvre (proposée) de la fonction. Il est destiné à susciter des réactions et à discuter avec les parties prenantes. C'est peut-être une bonne pratique mais n'est pas une étape d'ingénierie essentielle.
Il serait agréable de voir la conception de la cuisine avant de l’installer, mais cela n’est pas essentiel pour les besoins de la cuisine :
Si j'y pense, vous pouvez dire:
- l'architecture est pour un public/ingénieurs sur un niveau d'abstraction plus détaillé
- la conception est destinée au public sur un niveau d'abstraction moins détaillé
Mon rappel:
- Nous pouvons changer le design sans demander à quelqu'un
- Si nous changeons l'architecture, nous devons la communiquer à quelqu'un (équipe, client, intervenant, ...)
Je pense que nous devrions utiliser la règle suivante pour déterminer quand nous parlons de conception par rapport à architecture: Si les éléments d’une image logicielle que vous avez créée peuvent être mappés un à un dans une construction syntaxique de langage de programmation, c’est alors Design, sinon Architecture.
Ainsi, par exemple, si vous voyez un diagramme de classes ou un diagramme de séquence, vous pouvez mapper une classe et ses relations sur un langage de programmation orientée objet à l'aide de la construction syntaxique de la classe. C'est clairement Design. En outre, cela pourrait indiquer que cette discussion a un lien avec le langage de programmation que vous utiliserez pour mettre en œuvre un système logiciel. Si vous utilisez Java, l'exemple précédent s'applique car Java est un langage de programmation orienté objet. Si vous créez un diagramme montrant les packages et leurs dépendances, c'est aussi Design. Vous pouvez mapper l'élément (un package dans ce cas) sur une construction syntaxique Java.
Supposons maintenant que votre application Java est divisée en modules et que chaque module est un ensemble de packages (représenté par une unité de déploiement de fichier jar). Un diagramme contenant les modules et leurs dépendances vous est présenté. c'est l'architecture. Il n’existe aucun moyen dans Java (du moins jusqu’à Java 7) de mapper un module (un ensemble de packages) sur une construction syntaxique. Vous remarquerez peut-être également que ce diagramme représente une étape supplémentaire dans le niveau d'abstraction de votre modèle de logiciel. Tout diagramme ci-dessus (plus grossier que) un diagramme de package, représente une vue architecturale lors du développement dans le langage de programmation Java. Par contre, si vous développez dans Modula-2, un diagramme de module représente une conception.
(Un fragment de http://www.copypasteisforword.com/notes/software-architecture-vs-software-design) )
Personnellement, j'aime bien celui-ci:
"Le concepteur se préoccupe de ce qui se passe lorsqu'un utilisateur appuie sur un bouton, et l'architecte de ce qui se passe lorsque dix mille utilisateurs appuient sur un bouton."
Guide d'étude de SCEA pour Java ™ EE par Mark Cade et Humphrey Sheil
Je suis d'accord avec beaucoup d'explications. nous reconnaissons essentiellement la distinction entre la conception architecturale et la conception détaillée des systèmes logiciels.
L’objectif du concepteur est d’être aussi précis et concret dans le cahier des charges que nécessaire au développement; L'architecte vise essentiellement à spécifier la structure et le comportement global du système, autant que nécessaire pour la conception détaillée.
Un bon architecte empêchera les hyper-spécifications - l'architecture ne doit pas être trop spécifiée, mais juste suffisante, les décisions (architecturales) n'étant établies que pour les aspects présentant les risques les plus coûteux à gérer, et fournissant efficacement un cadre ("standard") au sein duquel la conception détaillée peut être travaillée, c'est-à-dire la variabilité de la fonctionnalité locale.
En effet, le processus d'architecture ou le cycle de vie ne fait que suivre ce thème: un niveau d'abstraction suffisant pour décrire la structure des exigences métier (architecturales) importantes et laisser plus de détails à la phase de conception pour obtenir des résultats plus concrets.
L'architecture est conception, mais toute conception n'est pas architecturale. Par conséquent, à proprement parler, il serait plus logique d'essayer de différencier conception architecturale et conception non architecturale . Et quelle est la différence? Ça dépend! Chaque architecte logiciel peut avoir une réponse différente (ymmv!). Nous développons nos heuristiques pour trouver une réponse, par exemple "Les diagrammes de classes sont une architecture et les diagrammes de séquence sont conçus". Voir livre DSA pour plus d'informations.
Il est courant de dire que l'architecture est à un niveau d'abstraction supérieur à celui de la conception, ou que l'architecture est logique et que la conception est physique. Mais cette notion, bien que communément acceptée, est en pratique inutile. Où tracez-vous la ligne de démarcation entre abstraction haute ou basse, entre logique et physique? Ça dépend!
Donc, ma suggestion est la suivante:
- créer un seul document de conception.
- nommez ce document de conception comme vous le souhaitez ou, mieux encore, comme le lecteur y est plus habitué. Exemples: "Architecture logicielle", "Spécification de conception logicielle".
- divisez ce document en vues et gardez à l’esprit que vous pouvez créer une vue pour affiner une autre vue.
- rendre les vues du document navigables en ajoutant des références croisées ou des hyperliens
- vous aurez ensuite des vues de niveau supérieur montrant une vue d'ensemble large mais superficielle de la conception, et des vues plus proches de l'implémentation montrant des détails de conception étroits mais plus profonds.
- vous voudrez peut-être regarder un exemple de document d'architecture multi-vues ( here ).
Ayant dit tout cela ... , une question plus pertinente que nous devons nous poser est la suivante: combien de design suffit-il? C'est-à-dire, quand dois-je arrêter de décrire conception (en diagrammes ou en prose) et devrait passer au codage?
Bonne question ... Bien que la ligne qui les sépare ne soit guère une ligne nette, à mon sens, si vous utilisez les deux termes, alors Architecture englobe des décisions plus techniques ou structurelles sur la manière de construire ou de construire quelque chose, en particulier celles qui seront difficiles ( ou plus difficile) à changer une fois implémenté, alors que Design englobe les décisions qu'il est facile de changer plus tard (comme les noms de méthodes, la structure organisationnelle de la classe <->, les modèles de conception, s'il faut utiliser un singleton ou une classe statique pour résoudre un problème spécifique , etc.) et/ou ceux qui affectent l'apparence ou les aspects esthétiques d'un système ou d'une application (interface humaine, facilité d'utilisation, apparence, etc.)
Oui, cela me semble juste. La conception est ce que vous allez faire, et l’architecture est la manière dont les éléments de la conception seront assemblés. Cela peut être indépendant de la langue, mais devrait normalement spécifier les technologies à utiliser, par exemple LAMP v Windows, Web Service v RPC.
L'architecture logicielle d'un programme ou d'un système informatique est la ou les structures du système, qui comprennent les composants logiciels, les propriétés visibles de l'extérieur de ces composants et leurs relations.
(de Wikipedia, http://en.wikipedia.org/wiki/Software_architecture )
La conception de logiciels est un processus de résolution de problèmes et de planification d'une solution logicielle. Une fois que l'objectif et les spécifications du logiciel sont déterminés, les développeurs de logiciels conçoivent ou emploient des concepteurs pour élaborer un plan de solution. Il inclut les problèmes de mise en œuvre de composant et d'algorithme de bas niveau, ainsi que la vue architecturale.
(de Wikipedia, http://en.wikipedia.org/wiki/Software_design )
Je n'aurais pas dit mieux moi même :)
Je considère l'architecture comme Patrick Karcher - la grande image. Par exemple, vous pouvez fournir l'architecture d'un bâtiment, voir son support structurel, les fenêtres, les entrées et sorties, le drainage de l'eau, etc. Mais vous n'avez pas "conçu" l'aménagement du sol, les positions des cellules, etc.
Ainsi, pendant que vous avez architecturé le bâtiment, vous n'avez pas conçu la disposition de chaque bureau. Je pense que la même chose vaut pour les logiciels.
Vous pouvez voir la conception de la mise en page, comme "l'architecture de la mise en page" si ...
Assez subjectif mais mon avis:
Architecture La conception globale du système, y compris les interactions avec d'autres systèmes, la configuration matérielle requise, la conception globale des composants et le flux de données.
Conception L'organisation et le flux d'un composant dans le système global. Cela inclurait également l'API du composant pour une interaction avec d'autres composants.
L'architecture logicielle est "concernée par des problèmes ... au-delà des algorithmes et des structures de données du calcul.
L'architecture ne concerne pas spécifiquement… les détails des implémentations (par exemple, les algorithmes et les structures de données). La conception architecturale implique une collection plus complète d'abstractions que celle fournie par OOD ”(conception orientée objet).
Design concerne la modularisation et les interfaces détaillées des éléments de conception, leurs algorithmes et procédures, ainsi que les types de données nécessaires à la prise en charge de l'architecture et à la satisfaction du client. exigences.
"Architecture" est souvent utilisé comme simple synonyme de "design" (parfois précédé de l'adjectif "de haut niveau"). Et beaucoup de gens utilisent le terme "modèles architecturaux" comme synonyme de "modèles de conception".
Découvrez ce lien.
Définition des termes architecture, conception et implémentation
... il y a longtemps, dans un lieu lointain, les philosophes s'inquiétaient de la distinction entre le un et le multiple. L'architecture concerne les relations, ce qui nécessite le plus grand nombre. L'architecture a des composants. Le design concerne le contenu, ce qui nécessite celui-ci. Le design a des propriétés, des qualités, des caractéristiques. Nous pensons généralement que le design se situe dans l'architecture. La pensée dualiste donne le multiple comme primordial. Mais l'architecture fait aussi partie du design. C'est la façon dont nous choisissons de voir ce qui est devant nous - l'un ou l'autre.
Architecture:
Les travaux de conception structurelle à des niveaux d'abstraction supérieurs, qui répondent aux exigences techniques importantes du système. L'architecture jette les bases d'une conception ultérieure.
Design:
L’art de combler ce que l’architecture ne fait pas par un processus itératif à chaque couche d’abstraction.
J'ai vraiment aimé ce papier pour une règle de base sur la séparation de l'architecture du design:
http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf
Cela s'appelle l'hypothèse Intension/Localité. Les déclarations sur la nature du logiciel, qui sont non locales et intensives, sont architecturales. Les déclarations qui sont locales et intensional sont design.
si quelqu'un construit un navire, le moteur, la coque, les circuits électriques, etc. seront ses "éléments architecturaux". Pour lui, la construction du moteur sera un "travail de conception".
S'il délègue ensuite la construction du moteur à une autre équipe, ils créeront une "architecture de moteur" ...
Donc, cela dépend du niveau d'abstraction ou de détail. L'architecture d'une personne pourrait être la conception d'un autre!
L'architecture est "les décisions de conception qui sont difficiles à changer."
Après avoir travaillé avec TDD, ce qui signifie pratiquement que votre conception change constamment, je me suis souvent retrouvé aux prises avec cette question. La définition ci-dessus est extraite de Patterns of Enterprise Application Architecture , de Martin Fowler
Cela signifie que l'architecture dépend de la langue, de la structure et du domaine de votre système. Si vous pouvez simplement extraire une interface de votre classe Java en 5 minutes, il ne s'agit plus d'une décision d'architecture.
L'architecture logicielle est mieux utilisée au niveau du système, lorsque vous devez projeter des activités et des fonctions identifiées par des niveaux d'architecture supérieurs dans des applications.
Par exemple, votre activité concerne les "profits et pertes" des traders et vos fonctions principales impliquent "l'évaluation du portefeuille" et le "calcul du risque".
Mais quand un architecte logiciel détaillera sa solution, il réalisera que:
"évaluation de portefeuille" ne peut pas être une seule application. Il doit être affiné dans des projets gérables tels que:
- Interface graphique
- Lanceur
- Répartiteur
- ...
(parce que les opérations impliquées sont si énormes, elles doivent être réparties sur plusieurs ordinateurs, tout en étant surveillées en permanence via une interface graphique commune)
une conception logicielle examinera les différentes applications, leurs relations techniques et leurs sous-composants internes.
Il produira les spécifications nécessaires au dernier couche d'architecture ("l'architecture technique") au travail sur (en termes de cadre technique ou de composantes transversales), et pour les équipes de projet (plus axées sur la mise en œuvre des fonctions commerciales ) pour commencer leurs projets respectifs.
La conception de logiciels a une histoire plus longue que l'architecture de logiciel terme a à peine 20 ans. Par conséquent, il traverse des douleurs de croissance en ce moment.
Les universitaires ont tendance à considérer l’architecture comme faisant partie du vaste domaine de la conception de logiciels. Bien que l'on reconnaisse de plus en plus qu'Arch est un domaine qui lui est propre.
Les praticiens ont tendance à considérer Arch comme une décision de conception de haut niveau qui est stratégique et peut être coûteuse dans un projet à annuler.
La ligne exacte entre Arch et Design dépend du domaine logiciel. Par exemple, dans le domaine des applications Web, l’architecture en couches gagne le plus de popularité à l’heure actuelle (couche logique du commerce, couche d’accès aux données, etc.). ) Cela serait défini différemment dans les domaines des systèmes intégrés, des systèmes d’exploitation, des compilateurs, etc.
Version Cliff Notes:
Conception: Implémentation d'une solution basée sur les spécifications du produit souhaité.
Architecture: la fondation/outils/infrastructure/composants qui prennent en charge votre conception.
C'est une question assez large qui appellera beaucoup de réponses.
L'architecture est la collection résultante de modèles de conception permettant de construire un système.
Je suppose que le design est la créativité utilisée pour mettre tout cela ensemble?
J'aime la définition et l'explication de Roy Thomas Fielding sur l'architecture du logiciel dans son article: Styles architecturaux et conception d'architectures logicielles en résea
Une architecture logicielle est une abstraction des éléments d'exécution d'un système logiciel au cours d'une phase de son fonctionnement. Un système peut être composé de plusieurs niveaux d'abstraction et de nombreuses phases de fonctionnement, chacune avec sa propre architecture logicielle.
Il insiste sur les "éléments d'exécution" et les "niveaux d'abstraction".
L'architecture et le design sont étroitement liés; La principale différence entre eux réside dans la manière dont nous sommes confrontés. L'architecture est tournée vers la stratégie, la structure et le but, vers l'abstrait. Concevez les visages vers la mise en œuvre et la pratique, vers le concret.
Il n’ya pas de réponse définitive à cette question car "architecture logicielle" et "conception logicielle" comportent un grand nombre de définitions et il n’existe pas non plus de définition canonique.
Len Bass, Paul Clements et Rick Kazman affirment que "toute architecture est une conception, mais toute conception est une architecture". Je ne suis pas sûr d’être tout à fait d’accord avec cela (car l’architecture peut inclure d’autres activités), mais cela montre bien que l’architecture est une activité de conception qui traite du sous-ensemble critique de la conception.
Ma définition légèrement désinvolte (indiquée sur le page de définitions SEI ) est que c'est l'ensemble des décisions qui, si elles sont mal prises, entraînent l'annulation de votre projet.
Amnon Eden et Rick Kazman ont, il y a quelques années, tenté de séparer architecture, conception et implémentation en tant que concepts, dans un document de recherche intitulé "Architecture, Design, Implementation" qui peut être trouvé ici: http: // www .sei.cmu.edu/library/assets/ICSE03-1.pdf . Leur langage est assez abstrait, mais ils disent simplement que l’architecture est une conception qui peut être utilisée dans de nombreux contextes et qui est censée être appliquée à l’ensemble du système design est un concept (err) utilisable dans de nombreux contextes mais appliqué dans une partie spécifique du système, et implémentation est une conception spécifique à un contexte et appliquée à ce contexte.
Donc, une décision architecturale pourrait être une décision d’intégrer le système via la messagerie plutôt que le RPC (c’est donc un principe général qui pourrait s’appliquer à de nombreux endroits et qui est destiné à s’appliquer à l’ensemble du système), une décision de conception pouvant consister à utiliser un maître/structure de threads esclave dans le module de traitement des demandes d'entrée du système (principe général pouvant être utilisé n'importe où, mais dans ce cas uniquement dans un module) et, finalement, une décision d'implémentation pourrait consister à transférer les responsabilités de sécurité du routeur de demandes. au gestionnaire de demandes dans le module Gestionnaire de demandes (décision pertinente uniquement dans ce contexte, utilisée dans ce contexte).
J'espère que ça aide!
Design: Pour en savoir plus sur les modules, quels types de relations entre les modules, les fonctionnalités de chaque module, les classes et ses fonctions membres, les interfaces de chaque module communiquant entre eux.
Architecture: L'architecture est la structure entière d'un système logiciel. Tous les modules, classes et composants effectuent différentes tâches et donneront un résultat unique.
Par exemple: il y a une maison qui a 5 pièces. Il y a aussi des salles de bains attachées. La cuisine est également là dans la maison. Il y a donc différentes choses à la maison et toutes ces choses ont des relations différentes les unes des autres. Il s’agit donc de la "CONCEPTION" d’une maison.
Alors que lorsque vous regardez de l'extérieur d'une maison, toute la structure que vous regardez est entièrement consacrée à l'architecture.
L'architecture est de haut niveau, de conception abstraite et logique alors que la conception de logiciel est de bas niveau, de conception détaillée et physique.
L'architecture est conçue avec une logique qui découle de divers facteurs, dont les plus importants sont les exigences non fonctionnelles, telles que l'évolutivité par exemple, et l'expérience n'est pas le moindre. Sans justification, vous vous retrouvez avec un schéma simple, ou comment faire. Qu'il s'agisse de concevoir à un niveau supérieur ou au niveau de la classe son design immobile.
OU en d'autres termes
L’architecture est une méta-conception, c’est-à-dire la conception de la conception. Vous avez quelques modèles connus pour s’adapter à un certain espace de solutions, lequel choisiriez-vous et pourquoi? L'architecture est quand vous répondez le "qui" et le "pourquoi" (le "comment" est déjà donné par la conception). Cela ne dépend certainement pas du niveau d'abstraction, par exemple, l'implémentation de sessions distribuées n'est pas une tâche de niveau classe, mais quelques conceptions peuvent être sélectionnées pour une architecture donnée.
De même, l'architecture se reflète même dans une conception de niveau classe. Sous une architecture évolutive, la conception de classe est souvent différente si vous le faites sans tenir compte du facteur d'évolutivité. Pourquoi vous devez avoir une méthode "BeginAsyncUpload" par rapport à "Upload" est une décision architecturale.
Il est intéressant de noter que plus nous nous concentrons sur l’élément système du système, plus les questions "qui et pourquoi" deviennent plus importantes et "comment" devient moins pertinent. Dans la direction opposée, la partie "comment" devient plus importante, également parce que l'utilisation répétée rend évident le choix entre, par exemple, Abstract Factory ou Prototype.
À mon avis, l’architecture n’est qu’une vision, elle rassemble les exigences et structure les blocs de construction de manière appropriée
si la conception permet de construire un bloc particulier, il existe 100 solutions possibles, mais pour répondre à des exigences précises, nous devons choisir la bonne méthode. Le choix de la bonne méthode ou du bon algorithme n'est donc pas de la conception.
L'architecture s'apparente davantage à l'intégration de diverses fonctionnalités d'un système pour atteindre un objectif du système dans son ensemble, tandis que la conception tient compte de chaque exigence fonctionnelle.
Par exemple, prenons l'exemple de MVVM, qui est un modèle architectural. Pour la fonctionnalité de notification, MVVM utilise Observator Pattern, qui est à son tour un motif de conception.
Comme d'autres l'ont également souligné, la mise en place de l'architecture d'un logiciel revient en réalité à prendre les grandes décisions de conception qui ont une influence générale sur le cycle de développement ou d'exécution du logiciel; de manière simpliste, l’architecture n’est qu’une conception de haut niveau.
Même si une décision d’architecture n’affecte pas tous les composants (est donc locale), elle doit néanmoins avoir une pertinence globale, c’est-à-dire qu’elle a une incidence sur l’ensemble du système; sinon, c'est simplement une décision de conception locale.
Ce que je voudrais cependant souligner, est qu’une question plus pertinente liée à l’architecture pourrait être Architecture vs Organisation, telle que définie par Hennessy & Patterson dans Computer Architecture. Sur cette base, nous pourrions considérer l'architecture comme l'abstraction du modèle de données (entrée/sortie, état) du système et l'organisation comme les décisions de conception typiques prises lors du processus de mise en œuvre (développement logiciel).
ARCHITECTURE: - Une architecture crée la mise en page des plans à différentes étapes de la construction conformément au cahier des charges.
DESINER: - Un desiner est une activité qui remplit toutes les exigences essentielles des plans d'architecture avec la fonctionnalité, l'asthetectic & appreance aux dispositions.
Je pense que l'architecture concerne les interfaces avec les humains et/ou les systèmes. Par exemple, un contrat de service Web, comprenant des protocoles, etc., est une architecture. Comment un écran est composé, pas de couleurs et autres mais quels sont les champs, c’est l’architecture.
Le design, c'est comment quelque chose doit être construit. Quels cadres, langage, technologie, etc. Cela doit bien sûr être aligné sur les directives et restrictions de l'entreprise en ce qui concerne les plateformes, la sécurité, etc.
L'architecture identifie les composants fondamentaux du système, décrit leur organisation et la manière dont ils sont liés pour créer un cadre pour le système.
La conception décrit divers composants et la manière dont ils doivent être développés pour fournir les fonctionnalités requises dans le cadre fourni par l’architecture du système.
http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns
L'architecture vous indique comment votre système est aménagé. Un exemple de modèle architectural traditionnel est un système à 3 niveaux dans lequel votre système est divisé en couches de présentation, métier et données.
La conception pilotée par le domaine favorise une architecture à 4 niveaux. Couches de présentation, d'application, de domaine et d'infrastructure. Et le modèle de référentiel réside entre la couche de domaine et la couche d'infrastructure. Vos modèles de domaine ne doivent rien savoir de l'infrastructure, ils doivent également rester purs et indépendants de celle-ci. C'est pourquoi nous avons le référentiel pour médier ces deux couches.
Le modèle de référentiel est toujours un modèle puisqu'il s'agit d'une solution réutilisable et qu'il résout les problèmes qui se répètent. Cependant, le modèle de référentiel ne devient pertinent que lorsque nous parlons de l'architecture. Il a ses rôles et ses responsabilités dans l'architecture de conception pilotée par le domaine. Ce n'est pas une solution générale de type mathématique telle que le modèle d'usine abstrait qui peut être appliqué n'importe où dans votre système.