Conception logicielle vs architecture logicielle [fermé]

Quelqu'un pourrait-il expliquer la différence entre la conception de logiciels et l'architecture de logiciels?

Plus précisement; si vous dites à quelqu'un de vous présenter le «design» - que vous attendriez-vous qu'il présente? Il en va de même pour «l'architecture».

Ma compréhension actuelle est:

• Conception: diagramme UML / organigramme / wireframes simples (pour UI) pour un module spécifique / une partie du système
• Architecture: diagramme des composants (montrant comment les différents modules du système communiquent entre eux et avec les autres systèmes), quel langage utiliser, modèles ...?

Corrige moi si je me trompe. J'ai mentionné que Wikipedia a des articles sur http://en.wikipedia.org/wiki/Software_design et http://en.wikipedia.org/wiki/Software_architecture , mais je ne suis pas sûr de les avoir bien compris.

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 de logiciels 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 non? Quels modèles de conception peuvent être utilisés?

Donc, 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 du SDLC (Software Development Life Cycle), ils sont interchangeables, mais le problème est qu'ils sont distincts. Ils sont à la fois: différents (1) stades , (2) domaines de responsabilité et (3) niveaux de prise de décision .

• L'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 ( rationnel , cascade , agile , etc.).
• La conception est la plus petite image: le plan de l'organisation du code; à quoi ressembleront les contrats entre les différentes parties du système; la mise en œuvre continue des méthodologies et des objectifs du projet. Les spécifications sont écrites au cours de cette étape.

Ces deux étapes sembleront se confondre pour différentes raisons.

1. Les petits projets n'ont souvent pas assez de portée pour séparer la planification en ces étapes.
2. Un projet peut faire partie d'un projet plus vaste, et donc des parties des deux étapes sont déjà décidées. (Il existe déjà des bases de données, des conventions, des normes, des protocoles, des cadres, du code réutilisable, etc.)
3. De nouvelles façons de penser le SDLC (voir Méthodologies Agiles ) réorganisent quelque peu cette approche traditionnelle. La conception (l'architecture dans une moindre mesure) a lieu à travers le SDLC à dessein . Il y a souvent plus d' itérations où tout le processus se répète encore et encore.
4. Le développement de logiciels est de toute façon compliqué et difficile à planifier, mais les clients / gestionnaires / vendeurs compliquent généralement les choses en modifiant les objectifs et les exigences en cours de route. La conception et même les décisions architecturales doivent être prises plus tard dans le projet, que ce soit le plan ou non.

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 se produit. (Nous pourrions continuer indéfiniment avec cela. J'essaie de garder un résumé.) Je terminerai par: Même s'il semble que votre projet n'ait pas d'étape architecturale ou de conception formelle / AOR / documentaiton, il se passe que quelqu'un soit le faire consciemment ou non. Si personne ne décide de faire de l'architecture, alors une erreur par défaut se produit qui est probablement médiocre. Idem pour le design. Ces concepts sont presque plus importants s'il n'y a pas d'étapes formelles les représentant.

L'architecture est stratégique, tandis que le design est tactique.

L'architecture comprend les cadres, les outils, les paradigmes de programmation, les normes d'ingénierie logicielle basées sur les composants, les principes de haut niveau.

Alors que la conception est une activité qui s'intéresse aux contraintes locales, telles que les modèles de conception, les idiomes de programmation et les refactorisations.

J'ai trouvé cela en cherchant 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;

1. L'architecture désigne la structure conceptuelle et l'organisation logique d'un ordinateur ou d'un système informatique.

   La conception désigne un plan ou un dessin produit pour montrer l'apparence et la fonction ou le fonctionnement d'un système ou d'un objet avant qu'il ne soit créé.

2. Si vous «architecturez» un composant, vous définissez comment il se comporte dans le plus grand système.

   Si vous «concevez» le même composant, vous définissez comment il se comporte en interne.

Toute architecture est conception mais PAS toute conception est architecture.

Whatune partie est la conception, l' Howest la mise en œuvre concrète et l'intersection de Whatet Howest l'architecture.

Image pour différencier architecture et design :

Il existe également des décisions de conception, qui ne sont pas importantes 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, comme le choix de l'algorithme, la sélection de la structure des données, etc.

Toute décision de conception, qui n'est pas visible en dehors de la limite de ses composants, est la conception interne d'un composant et n'est pas architecturale. Ce sont les décisions de conception qu'un architecte système laisserait à la discrétion du concepteur de module ou de l'équipe d'implémentation tant que leur conception ne brise pas les contraintes architecturales imposées par l'architecture au niveau du système.

Le lien qui donne une bonne analogie

Je dirais que vous avez raison, selon mes propres mots;

L'architecture est l'allocation des exigences du système aux éléments du système. Quatre déclarations sur une architecture:

1. Il peut introduire des exigences non fonctionnelles comme le langage ou les modèles.
2. Il définit l'interaction entre les composants, les interfaces, le timing, etc.
3. Il ne doit pas introduire de nouvelles fonctionnalités,
4. Il alloue les fonctions (conçues) que le système est censé exécuter aux éléments.

L'architecture est une étape d'ingénierie essentielle lorsqu'une complexité du système est subdivisée.

Exemple: Pensez à votre maison, vous n'avez pas besoin d'un architecte pour votre cuisine (un seul élément impliqué) mais le bâtiment complet a besoin de définitions d'interaction, comme des portes et un toit .

La conception est une représentation informative de la mise en œuvre (proposée) de la fonction. Il vise à susciter des commentaires et à discuter avec les parties prenantes. Ce pourrait être une bonne pratique, mais ce n'est pas une étape d'ingénierie essentielle .

Ce serait bien de voir la conception de la cuisine avant l'installation de la cuisine, mais ce n'est pas essentiel pour l'exigence de cuisson :

Si j'y pense, vous pouvez dire:

• l'architecture est destinée à un public / ingénieurs à un niveau d'abstraction plus détaillé
• la conception est destinée au public à 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, partie prenante, ...)

Je pense que nous devrions utiliser la règle suivante pour déterminer quand nous parlons de conception vs architecture: si les éléments d'une image logicielle que vous avez créée peuvent être mappés un à un à une construction syntaxique de langage de programmation, 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 leurs relations avec un langage de programmation orienté objet à l'aide de la construction syntaxique de classe. C'est clairement du design. De plus, cela pourrait apporter à la table que cette discussion a une relation avec le langage de programmation que vous utiliserez pour implémenter 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 venez avec un diagramme qui montre les packages et ses dépendances, c'est aussi Design. Vous pouvez mapper l'élément (un package dans ce cas) à une construction syntaxique Java.

Supposons maintenant que votre application Java soit divisée en modules et que chaque module soit un ensemble de packages (représenté comme une unité de déploiement de fichier jar) et qu'un diagramme contenant des modules et ses dépendances vous soit présenté, c'est-à-dire Architecture. Il n'y a aucun moyen en Java (du moins pas avant Java 7) de mapper un module (un ensemble de packages) à une construction syntaxique. Vous remarquerez peut-être également que ce diagramme représente une étape plus élevée dans le niveau d'abstraction de votre modèle logiciel. Tout diagramme ci-dessus (à grain plus fin que) un diagramme de package, représente une vue architecturale lors du développement dans le langage de programmation Java. D'un autre côté, si vous développez dans Modula-2, alors, 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 se préoccupe de ce qui se produit lorsque dix mille utilisateurs appuient sur un bouton."

Guide d'étude SCEA pour Java ™ EE par Mark Cade et Humphrey Sheil

Je suis d'accord avec de nombreuses explications; nous reconnaissons essentiellement la distinction entre la conception architecturale et la conception détaillée des systèmes logiciels.

Alors que l'objectif du concepteur est d'être aussi précis et concret dans les spécifications qu'il sera nécessaire pour le 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 évitera les hyper-spécifications - l'architecture ne doit pas être trop spécifiée mais juste assez, les décisions (architecturales) établies uniquement pour les aspects qui présentent les risques les plus coûteux à gérer, et fournissent efficacement un cadre («commun») dans lequel le la conception détaillée peut être travaillée, c'est-à-dire la variabilité des fonctionnalités locales

En effet, le processus d'architecture ou le cycle de vie ne fait que suivre ce thème - un niveau d'abstraction adéquat pour définir la structure des exigences commerciales importantes (architecturales) et laisser plus de détails à la phase de conception pour des livrables plus concrets.

L'architecture est le design, mais tout le design n'est pas architectural. Par conséquent, à strictement parler, il serait plus logique d'essayer de faire la différence entre la conception architecturale et la 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 notre heuristique pour trouver une réponse, comme «les diagrammes de classes sont l'architecture et les diagrammes de séquence sont la conception». Voir le livre DSA pour plus.

Il est courant de dire que l'architecture est à un niveau d'abstraction plus élevé que la conception, ou que l'architecture est logique et que la conception est physique. Mais cette notion, bien que communément admise, est en pratique inutile. Où tracez-vous la ligne entre l'abstraction haute ou basse, entre logique et physique? Ça dépend!

Donc, ma suggestion est:

• créer un seul document de conception.
• nommez ce document de conception comme vous le souhaitez ou, mieux, de la façon dont les lecteurs sont plus habitués. Exemples: "Architecture logicielle", "Spécification de conception logicielle".
• divisez ce document en vues et gardez à l'esprit que vous pouvez créer une vue en tant qu'affinement d'une autre vue.
• rendre les vues du document navigables en ajoutant des références croisées ou des hyperliens
• vous aurez alors des vues de niveau supérieur montrant une vue d'ensemble large mais superficielle de la conception, et des vues plus proches de la mise en œuvre montrant des détails de conception étroits mais plus profonds.
• vous voudrez peut-être jeter un œil à un exemple de document d'architecture à vues multiples ( ici ).

Cela dit, une question plus pertinente que nous devons nous poser est la suivante: combien de design suffit-il? Autrement dit, quand dois-je arrêter de décrire la conception (dans des diagrammes ou de la prose) et dois-je passer au codage?

Oui, cela me semble juste. Le design est ce que vous allez faire, et l'architecture est la façon dont les éléments du design seront réunis. Il 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 les relations entre eux.

(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 le but et les spécifications du logiciel déterminés, les développeurs de logiciels concevront ou emploieront des concepteurs pour développer un plan de solution. Il comprend des problèmes d'implémentation de composants et d'algorithmes 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 vois l'architecture comme le fait Patrick Karcher - la vue d'ensemble. Par exemple, vous pouvez fournir l'architecture d'un bâtiment, voir son support structurel, les fenêtres, les entrées et les sorties, le drainage de l'eau, etc. Mais vous n'avez pas "conçu" la disposition du sol, la position des cellules, etc.

Ainsi, bien que vous ayez architecturé le bâtiment, vous n'avez pas conçu l'agencement de chaque bureau. Je pense qu'il en va de même pour les logiciels.

Vous pouvez voir la conception de la mise en page comme une "architecture de la mise en page" ...

Bonne question ... Bien que la ligne qui les sépare ne soit pas une ligne claire et nette, à mon humble avis, si vous utilisez les deux termes, l'architecture englobe des décisions plus techniques ou structurelles sur la façon de construire ou de construire quelque chose, en particulier les décisions qui seront difficiles ( ou plus difficile) à changer une fois implémenté, tandis que Design englobe les décisions qui sont faciles à changer plus tard (comme les noms de méthode, la structure organisationnelle du fichier classe <->, les modèles de conception, que ce soit pour 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.)

L' architecture logicielle «s'intéresse aux 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 d'abstractions plus riche que celle généralement fournie par OOD »(conception orientée objet).

La conception 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 pour prendre en charge l'architecture et satisfaire les exigences.

«Architecture» est souvent utilisé comme un simple synonyme de «design» (parfois précédé de l'adjectif «haut niveau»). Et de nombreuses personnes utilisent le terme «motifs architecturaux» comme synonyme de «motifs de conception».

Consultez ce lien.

Définition des termes Architecture, conception et implémentation

Architecture:
travaux de conception structurelle à des niveaux d'abstraction plus élevés qui réalisent des exigences techniquement significatives dans le système. L'architecture pose les bases d'une conception ultérieure.

Design:
L'art de remplir ce que l'architecture ne fait pas à travers un processus itératif à chaque couche d'abstraction.

J'ai vraiment aimé cet article pour une règle d'or sur la séparation de l'architecture de la conception:

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 des logiciels non locaux et intensionnels sont architecturales. Les déclarations qui sont locales et intensionnelles sont de conception.

... il y a longtemps, dans un endroit lointain, les philosophes s'inquiétaient de la distinction entre l'un et le multiple. L'architecture, c'est la relation, qui nécessite le plus. L'architecture a des composants. Le design concerne le contenu, qui requiert celui-là. Le design a des propriétés, des qualités, des caractéristiques. Nous pensons généralement que le design fait partie de l'architecture. La pensée dualiste donne le multiple comme primordial. Mais l'architecture fait également partie du design. C'est toute la façon dont nous choisissons de voir ce qui est devant nous - l'un ou plusieurs.

Assez subjectif mais mon avis:

Architecture La conception globale du système, y compris les interactions avec d'autres systèmes, les exigences matérielles, 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 l'interaction avec d'autres composants.

L'architecture logicielle est mieux utilisée au niveau du système, lorsque vous avez besoin de projeter des activités et des fonctions identifiées par des niveaux d'architecture supérieurs dans des applications.

Par exemple, votre entreprise s'occupe de «profits et pertes» pour les traders, et vos fonctions principales impliquaient «l'évaluation de portefeuille» et le «calcul des risques».

Mais quand un architecte logiciel détaillera sa solution, il se rendra compte que:

«l'évaluation de portefeuille» ne peut pas être une seule application. Il doit être affiné dans des projets gérables comme:

• GUI
• Lanceur
• Dispatcher
• ...

(parce que les opérations impliquées sont si énormes qu'elles doivent être réparties entre plusieurs ordinateurs, tout en étant toujours surveillées via une interface graphique commune)

a La conception du logiciel examinera les différentes applications, leur relation technique et leurs sous-composants internes.
Il produira les cahiers des charges nécessaires au travail sur la dernière couche d'Architecture ("Architecture Technique") (en terme de cadre technique ou de composants transversaux), et pour les équipes de projet (plus orientées sur la mise en œuvre des fonctions métiers ) pour commencer leurs projets respectifs.

si quelqu'un construit un navire, le moteur, la coque, les circuits électriques, etc. seront ses "éléments architecturaux". Pour lui, la construction de moteurs sera un "travail de conception".

S'il délègue ensuite la construction du moteur à une autre équipe, ils créeront une "architecture moteur" ...

Donc - cela dépend du niveau d'abstraction ou de détail. L'architecture d'une personne pourrait être la conception d'une autre!

L'architecture est «les décisions de conception difficiles à modifier».

Après avoir travaillé avec TDD, ce qui signifie pratiquement que votre conception change tout le temps, je me suis souvent retrouvé aux prises avec cette question. La définition ci-dessus est extraite de Patterns of Enterprise Application Architecture , par Martin Fowler

Cela signifie que l'architecture dépend du langage, du framework et du domaine de votre système. Si vous pouvez simplement extraire une interface de votre classe Java en 5 minutes, ce n'est plus une décision d'architecture.

Version de Cliff Notes:

Conception: Implémentation d'une solution basée sur les spécifications du produit souhaité.

Architecture: la base / les outils / l'infrastructure / les composants qui soutiennent votre conception.

Il s'agit d'une question assez large qui appellera de nombreuses réponses.

L'architecture est la collection résultante de modèles de conception pour construire un système.

Je suppose que le design est la créativité utilisée pour mettre tout cela ensemble?

La conception de logiciels a une histoire plus longue alors que le terme architecture logicielle a à peine 20 ans. Par conséquent, il traverse actuellement des douleurs croissantes.

Les universitaires ont tendance à considérer l'architecture comme faisant partie du domaine plus large de la conception de logiciels. Bien qu'il soit de plus en plus reconnu que Arch est un domaine en soi.

Les praticiens ont tendance à voir Arch comme des décisions de conception de haut niveau qui sont stratégiques et peuvent être coûteuses à annuler dans un projet.

La ligne exacte entre Arch et la conception dépend du domaine du logiciel. Par exemple, dans le domaine des applications Web, l'architecture en couches gagne actuellement en popularité (Couche logique Biz, Couche d'accès aux données, etc.). Les parties de niveau inférieur de cette Arch sont considérées comme de la conception (diagrammes de classes, signatures de méthode, etc. ) Cela serait défini différemment dans les domaines des systèmes embarqués, des systèmes d'exploitation, des compilateurs, etc.

L'architecture est une conception de haut niveau, abstraite et logique tandis que la conception de logiciels est une conception de bas niveau, détaillée et physique.

Consultez également: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

J'aime la définition et l'explication de Roy Thomas Fielding sur ce qu'est l'architecture logicielle dans son article: Styles architecturaux et conception d'architectures logicielles basées sur les réseaux

Une architecture logicielle est une abstraction des éléments d'exécution d'un système logiciel pendant une phase de son fonctionnement. Un système peut être composé de plusieurs niveaux d'abstraction et de plusieurs phases de fonctionnement, chacun avec sa propre architecture logicielle.

Il met l'accent sur les «éléments d'exécution» et les «niveaux d'abstraction».

Il n'y a pas de réponse définitive à cela car «architecture logicielle» et «conception logicielle» ont un certain nombre de définitions et il n'y a pas non plus de définition canonique.

Une bonne façon d'y penser est la déclaration de Len Bass, Paul Clements et Rick Kazman selon laquelle "toute architecture est design mais pas tout design est architecture" [Architecture logicielle en pratique]. 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 capture l'essence 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 (trouvée sur la page des définitions SEI ) est que c'est l'ensemble des décisions qui, si elles sont prises à tort, provoquent l'annulation de votre projet.

Amnon Eden et Rick Kazman ont fait une tentative utile de séparer l'architecture, la conception et la mise en œuvre en tant que concepts il y a quelques années 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 de façon simpliste, ils disent que l' architecture est une conception qui peut être utilisée dans de nombreux contextes et est destinée à être appliquée à travers le système, la conception est (err) une conception qui peut être utilisée dans de nombreux contextes mais est appliquée dans une partie spécifique du système, et la mise en œuvre est une conception spécifique à un contexte et appliquée dans ce contexte.

Donc, une décision architecturale pourrait être une décision d'intégrer le système via la messagerie plutôt que RPC (c'est donc un principe général qui pourrait être appliqué à de nombreux endroits et est destiné à s'appliquer à l'ensemble du système), une décision de conception pourrait être d'utiliser un maître / structure de thread esclave dans le module de gestion des demandes d'entrée du système (un principe général qui pourrait être utilisé n'importe où mais dans ce cas n'est utilisé que dans un module) et enfin, une décision d'implémentation pourrait être de déplacer les responsabilités de sécurité du routeur de demande au gestionnaire de demandes dans le module Gestionnaire de demandes (une décision pertinente uniquement pour ce contexte, utilisée dans ce contexte).

J'espère que ça aide!