Conception de logiciels et architecture logicielle

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 les uns avec les autres, 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 à trois niveaux, etc.

La conception du logiciel consiste à concevoir les différents modules / composants. Quelles sont les responsabilités, fonctions, du module x? De classe Y? Que peut-il faire et quoi? Quels modèles de conception peuvent être utilisés?

En résumé, 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), elles sont interchangeables, mais le consesus est qu’elles sont distinctes. Ils sont simultanément: différentes étapes (1), (2) domaines de responsabilité et (3) niveaux de prise de décision .

• L’architecture est la plus vaste: le choix des frameworks, des langages, de la scope, des objectives et des méthodologies de haut niveau ( rationnel , cascade , agile , etc.).
• Le design est la plus petite image: le plan de l’organisation du code; comment les contrats entre les différentes parties du système vont ressembler; la mise en œuvre continue des méthodologies et des objectives du projet. Les spécifications sont écrites pendant cette étape.

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

1. Les projets de moindre envergure n’ont souvent pas assez de place pour séparer la planification en plusieurs étapes.
2. Un projet peut faire partie d’un projet plus vaste et des parties des deux étapes sont déjà décidées. (Il existe déjà des bases de données, conventions, normes, protocoles, frameworks, code réutilisable, etc.)
3. De nouvelles façons de penser au SDLC (voir les méthodologies Agile ) réorganisent quelque peu cette approche traditionnelle. La conception (architecture dans une moindre mesure) se fait tout au long du SDLC à dessein . Il y a souvent plus d’ itérations où tout le processus se répète.
4. Le développement de logiciels est compliqué et difficile à planifier de toute façon, mais les clients / gestionnaires / commerciaux rendent généralement les choses plus difficiles en modifiant les objectives et les exigences à mi-parcours. La conception et même les décisions architecturales doivent être sockets 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 sur cette lancée. J’essaie de garder un résumé.) Je terminerai avec ceci: même si votre projet ne semble pas avoir d’étape architecturale ou de conception / AOR / documentaiton formelle, le faire consciemment ou non. Si personne ne décide de faire de l’architecture, alors il se produit un défaut qui est probablement faible. 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 basées sur les composants, les principes de haut niveau.

Tandis que le design est une activité qui concerne les contraintes locales, telles que les modèles de conception, les idiomes de programmation et les refactorisations.

J’ai trouvé cela car je cherchais une distinction simple entre l’architecture et le design moi-même;
Que pensez-vous de cette façon de les regarder:

• l’architecture est “quoi” nous construisons;
• le design est “comment” nous construisons;

1. Architecture désigne la structure conceptuelle et l’organisation logique d’un ordinateur ou d’un système informatique.

   Design désigne un plan ou un dessin produit pour montrer l’aspect et la fonction d’un système ou d’un object avant sa création.

2. Si vous «architectez» un composant, vous définissez son comportement dans un système plus vaste.

   Si vous «concevez» le même composant, vous définissez son comportement interne.

Toute l’architecture est design mais tous les designs ne sont pas architecturaux.

What est le rôle de la conception, 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 le design :

Il existe également des décisions de conception qui n’ont pas d’importance architecturale, c’est-à-dire qu’elles ne font pas partie de la twig architecture du design. Par exemple, les décisions de conception internes de certains composants, 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 des limites de son composant, est la conception interne d’un composant et n’est pas architecturale. Tels sont les choix de conception qu’un architecte de système laisserait à la discrétion du concepteur de module ou à l’équipe d’implémentation, à condition que leur conception ne brise pas les contraintes architecturales imposées par l’architecture de niveau 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 énoncés sur une architecture:

1. Il peut introduire des exigences non fonctionnelles telles que 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 destiné à exécuter pour les é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 est impliqué), mais l’ensemble du bâtiment nécessite des définitions d’interaction, comme des portes et un toit .

Le design est une représentation informative de la mise en œuvre (proposée) de la fonction. Il est destiné à susciter des réactions et à discuter avec les parties prenantes. Cela peut être une bonne pratique mais ce n’est pas une étape d’ingénierie essentielle .

Ce serait bien de voir le design de la cuisine voir avant l’installation de la cuisine mais ce n’est pas essentiel pour la cuisson :

Si j’y pense, vous pouvez dire:

• l’architecture est pour un public / ingénieurs sur un niveau d’abstraction plus détaillé
• le design est destiné 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, partie prenante, …)

Je pense que nous devrions utiliser la règle suivante pour déterminer quand nous parlons de Design vs Architecture: Si les éléments d’une image de logiciel que vous avez créés peuvent être mappés individuellement à une construction syntaxique de langage de programmation, alors Design, sinon Architecture.

Ainsi, par exemple, si vous voyez un diagramme de classe ou un diagramme de séquence, vous pouvez mapper une classe et ses relations avec un langage de programmation orienté object en utilisant la construction syntaxique de classe. Ceci est clairement la conception. De plus, cela pourrait amener à la table que cette discussion a un rapport 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é object. Si vous avez un diagramme qui montre les paquets et leurs 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é par une unité de déploiement de fichiers JAR). Un diagramme contenant des modules et ses dépendances vous est présenté. Il n’y a pas de moyen en Java (du moins pas jusqu’à Java 7) de mapper un module (un ensemble de paquets) à une construction syntaxique. Vous remarquerez peut-être que ce diagramme représente une étape supérieure dans le niveau d’abstraction de votre modèle de logiciel. Tout diagramme ci-dessus (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 un Design.

(Un fragment de http://www.copypasteisforword.com/notes/software-architecture-vs-software-design )

Personnellement, j’aime bien celui-ci:

“Le concepteur est concerné par ce qui se passe lorsqu’un utilisateur appuie sur un bouton, et l’architecte s’inquiète de ce qui se passe lorsque dix mille utilisateurs appuient sur un bouton.”

Guide d’étude SCEA for Java ™ EE par Mark Cade et Humphrey Sheil

Je suis d’accord avec beaucoup des explications; Nous reconnaissons essentiellement la distinction entre la conception architecturale et la conception détaillée des systèmes logiciels.

Bien que le but du concepteur soit d’être aussi précis et concret que possible dans le cahier des charges pour le développement; L’architecte vise essentiellement à spécifier la structure et le comportement global du système tout autant que cela est 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 assez, les décisions (architecturales) ne sont établies que pour les aspects présentant les risques les plus coûteux à gérer et fournissent un cadre (“points communs”) dans lequel la conception détaillée peut être travaillée, c.-à-d. la variabilité pour la fonctionnalité locale.

En effet, le processus d’architecture ou le cycle de vie ne font que suivre ce thème – niveau d’abstraction suffisant pour définir la structure des besoins opérationnels importants (sur le plan architectural) et laisser plus de détails à la phase de conception pour des livrables plus concrets.

L’architecture est la conception, mais toutes les conceptions ne sont pas architecturales. Par conséquent, à proprement parler, il serait plus judicieux d’essayer de différencier la conception architecturale de 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 nos heuristiques pour trouver une réponse, tels que «les diagrammes de classes sont l’architecture et les diagrammes de séquence sont la conception». Voir le 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, quoique communément acceptée, est en pratique inutile. Où tracez-vous la ligne entre abstraction haute ou basse, logique et physique? Ça dépend!

Donc, ma suggestion est la suivante:

• créer un document de conception unique.
• nommez ce document de conception comme vous le souhaitez ou, mieux, comme le font les lecteurs. Exemples: “Architecture logicielle”, “Spécification de conception de logiciel”.
• 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 plus haut niveau 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 oeil à un exemple de document d’architecture multi-vues ( ici ).

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

Oui, ça me semble bien. Le design est ce que vous allez faire, et l’architecture est la façon dont les éléments du design seront réunis. Cela peut être indépendant de la langue, mais doit 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 structure ou les structures du système, qui comprennent des composants logiciels, les propriétés visibles de l’extérieur de ces composants et les relations entre eux.

(extrait 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 pour une solution logicielle. Une fois l’objective et les spécifications du logiciel déterminés, les développeurs de logiciels concevront ou utiliseront des concepteurs pour élaborer un plan de solution. Il inclut les problèmes d’implémentation des composants et algorithmes de bas niveau ainsi que la vue architecturale.

(extrait de Wikipedia, http://en.wikipedia.org/wiki/Software_design )

Je n’aurais pas dit mieux moi même 🙂

Je considère l’architecture comme le fait Pasortingck Karcher – la grande image. Par exemple, vous pouvez fournir l’architecture à un bâtiment, voir son support structurel, les fenêtres, les entrées et les sorties, le drainage de l’eau, etc.

Donc, pendant que vous avez conçu 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 “architecturer la mise en page” si …

Bonne question … Bien que la limite entre les deux termes ne soit pas très 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 ou plus difficile) de changer une fois implémenté, alors que Design englobe les décisions faciles à modifier ultérieurement (comme les noms de méthode, la structure organisationnelle des fichiers de classe <->, les modèles de conception, l’utilisation d’un singleton ou d’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 est «concernée par les 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 object).

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 simple synonyme de «design» (parfois précédé de l’adjectif «high level»). Et beaucoup de gens utilisent le terme «modèles architecturaux» comme synonyme de «modèles de conception».

Consultez ce lien.

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

Architecture:
La conception structurelle fonctionne à des niveaux d’abstraction plus élevés, qui réalisent des exigences techniquement significatives dans le système. L’architecture jette les bases pour la conception ultérieure.

Conception:
L’art de remplir ce que l’architecture ne fait pas par un processus itératif à chaque niveau 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

C’est ce qu’on appelle l’hypothèse Intension / Localité. Les déclarations sur la nature du logiciel non local et intensional sont architecturales. Les déclarations locales et intensives sont conçues.

… il y a longtemps, dans un pays lointain, les philosophes s’inquiétaient de la distinction entre l’un et le multiple. L’architecture concerne la relation, ce qui nécessite le plus grand nombre. L’architecture a des composants. Le design concerne le contenu, ce qui nécessite l’un. Le design a des propriétés, des qualités et des caractéristiques. Nous pensons généralement que le design est dans l’architecture. La pensée dualiste donne le plus grand nombre. Mais l’architecture fait également partie du design. C’est tout ce que nous choisissons pour voir ce qui est devant nous – l’un ou l’autre.

Assez subjective mais ma prise:

Architecture 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 stream de données.

Conception Organisation et stream 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 la mieux adaptée au niveau du système, lorsque vous devez projeter des activités et des fonctions à des niveaux d’architecture plus élevés dans des applications.

Par exemple, votre activité concerne les «pertes et profits» pour les traders, et vos principales fonctions impliquent une «évaluation de portefeuille» et un «calcul de risque».

Mais quand un architecte de 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:

• GUI
• Lanceur
• Répartiteur
• …

(parce que les opérations impliquées sont énormes, elles doivent être réparties entre plusieurs ordinateurs, tout en étant contrôlées à tout moment via une interface graphique commune)

Une conception de logiciel examinera les différentes applications, leur relation technique et leurs sous-composants internes.
Il produira les spécifications requirejses pour la dernière couche d’architecture (l’architecture technique) à utiliser (en termes de cadre technique ou de composants transversaux), et pour que les équipes de projet (plus axées sur la mise en œuvre des fonctions commerciales ) commencent à travailler. leurs projets respectifs.

si quelqu’un construit un navire, alors le moteur, la shell, les circuits élecsortingques, etc. seront ses “éléments architecturaux”. Pour lui, la construction du moteur sera “travail de conception”.

S’il délègue ensuite la construction du moteur à une autre équipe, ils vont créer 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 des autres!

L’architecture est “les décisions de conception difficiles à changer”.

Après avoir travaillé avec TDD, ce qui signifie pratiquement que votre conception change tout le temps, je me suis souvent heurté à 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 de la langue, 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 la décision d’architecture.

Version Cliff Notes:

Conception: implémenter une solution basée sur les spécifications du produit souhaité.

Architecture: la fondation / les outils / l’infrastructure / les composants qui prennent en charge votre conception.

C’est une question assez large qui invoquera beaucoup de 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 longue histoire, tandis que le terme architecture de logiciel a à peine 20 ans. Par conséquent, il traverse actuellement des difficultés de croissance.

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 à part entière.

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

La ligne exacte entre Arch et le design dépend du domaine du logiciel. Par exemple, dans le domaine des applications Web, l’architecture en couches gagne actuellement en popularité (couche logique, couche d’access aux données, etc.). Les parties inférieures de cette architecture sont considérées comme des diagrammes de classes, des signatures de méthodes, 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 de haut niveau, la conception abstraite et logique alors que la conception de logiciel est de bas niveau, la conception détaillée et physique.

Voir aussi: 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 un réseau

Une architecture logicielle est une abstraction des éléments d’exécution d’un système logiciel pendant certaines phases de son fonctionnement. Un système peut être composé de plusieurs niveaux d’abstraction et de nombreuses phases de fonctionnement, chacune ayant 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 à cette question car “l’architecture logicielle” et la “conception logicielle” ont un certain nombre de définitions et il n’y a pas de définition canonique pour l’une ou l’autre.

Len Bass, Paul Clements et Rick Kazman pensent que «toute l’architecture est le design, mais pas le design, c’est l’architecture». Je ne suis pas certain d’être d’accord avec cela (parce que l’architecture peut inclure d’autres activités), mais elle capture l’essence même de l’architecture en tant qu’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 de définitions SEI ) est que c’est l’ensemble des décisions qui, si elles sont mal faites, entraînent l’annulation de votre projet.

Il y a quelques années, Amnon Eden et Rick Kazman ont tenté de séparer l’architecture, la conception et la mise en œuvre en tant que concepts dans un document de recherche intitulé «Architecture, Design, Implementation», disponible ici: http: //www.sei.cmu .edu / library / assets / ICSE03-1.pdf . Leur langage est assez abstrait mais ils disent de manière simpliste que l’ architecture est un design qui peut être utilisé dans de nombreux contextes et est destiné à être appliqué dans tout le système, le design est (err) design qui peut être utilisé dans de nombreux contextes du système, et la mise en œuvre est spécifique à un contexte et appliquée dans ce contexte.

Une décision architecturale pourrait donc être une décision d’intégration du 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 s’applique à l’ensemble du système), une décision de conception Structure de thread / slave dans le module de traitement des requêtes d’entrée du système (un principe général qui pourrait être utilisé n’importe où mais dans ce cas, il est utilisé dans un seul module) et une décision d’implémentation au gestionnaire de requêtes dans le module Request Manager (décision pertinente uniquement pour ce contexte, utilisée dans ce contexte).

J’espère que ça aide!