Discussion:Architecture logicielle

Avant de proposer des modifications, je lance une discussion... L'article est intéressant, mais me parait "décalé". Il me semble y avoir parfois confusion entre architecture et points de vues. Le modele 4+1 n'a rien à voir ici. Le positionnement par rapport aux processus oui ; entre analyse/besoin et conception (l'architecture est de mon point de vue, la première phase de la conception ; on commence à s'intéresser au comment). Il manque de nombreuses références sur les approches de David Garlan et Mary Shaw où l'architecture est définie comme composants + connecteurs = configuration ; il n'y a pas non plus de références sur les langages de description d'architecture (ADL) n'existe pas en français Un mot sur les qualité, vues comme des propriétés émergente de l'assemblage (architecture), me semblerait également utile. Cela justifie la définition d'architecture ; pour réfléchir aux propriétés émergentes : les qualités (propriétés non-fonctionnelles) C'est une réorientation forte... d'où cette discussion préalable. ABeugnard (d) 5 novembre 2009 à 10:35 (CET)

Il ne faut surtout pas utiliser un terme comme décalé lorsque l'on parle d'un article écrit par un architecte logiciel de métier qui a fait des études supérieures dans ce domaine.

Je suis pas un grand fan de l'argument d'autorité, surtout dans le contexte de wikipedia. L'important, c'est l'argumentation, les sources, l'absence de travail original. Ce qui devrait ne poser aucun problème dans ton cas. Et aussi l'intégration du point de vue des autres, si il est pertinent. TomT0m (d) 18 mars 2010 à 18:15 (CET)

Je ne suis pas un grand fan du terme décalé lorsqu'il m'est adressé.

Forcément si tu prends ça comme une attaque personnelle ... Il s'agissait de l'article, pas de toi personnellement. À partir de là il me semble aussi nécessaire soit de clarifier et d'expliciter les références de l'article, soit d'évoquer un peu plus précisément ce qu'est concrêtement une architecture logicielle sur le terrain, les concepts utilisés pour la décrire

Nous nous définissons en grande partie par notre carrière. Ma personne est indissociable de ma profession.

Proposition : Il me semble y avoir parfois confusion entre architecture et points de vues. Le modèle 4+1 n'a rien à voir ici.

Contre argument : Pour son 25e anniversaire, la revue IEEE Software's vient de publier la liste des 35 articles les plus importants dans le domaine du développement logiciel. L'article de Kruchten fait partie des quatre plus importants et il est le seul concernant le sujet de l'architecture. S'agit-il d'une prise de position du IEEE déclarant que le modèle de Kruchten est l'architecture logicielle ?

Proposition : Le positionnement par rapport aux processus oui ; entre analyse/besoin et conception (l'architecture est de mon point de vue, la première phase de la conception ; on commence à s'intéresser au comment).

Contre argument : Tu viens d'ouvrir ton premier livre abordant le sujet... bravo.

Proposition : Il manque de nombreuses références sur les approches de David Garlan et Mary Shaw où l'architecture est définie comme composants + connecteurs = configuration.

Contre argument : Il sont dans la liste mais bien en dessous de Kruchten 35 articles de IEEE. De toute façon, la conception équivalente de Perry et Wolf exposée dans l'article fait très bien l'affaire (elle est même supérieure).

Proposition : il n'y a pas non plus de références sur les langages de description d'architecture (ADL).

Contre argument : As-tu déjà entendu parler d'UML ?

Il me semble pas que le diagramme d'UML qui permet de modéliser les architectures soit le diagramme de classe.

Il est vraiment désagréable de s'obstiner avec une personne qui ne possède pas le minimum du cursus nécessaire.

Il me semble surtout que c'est un signe que l'article ne donne pas le minimum de billes pour comprendre et n'est pas clair du tout. L'article n'est pas destiné à être lu que par des spécialistes. TomT0m (d) 19 mars 2010 à 10:11 (CET)

Non, pas du tout, dans l'article il est très clair que la vue logique de l'architecture logicielle est définie avec des diagrammes de classes. Je ne comprend pas comment tu peux prétendre avoir une opinion alors que clairement tu n'y connais rien.

Notion de Composants

J'ai vu ça dans l'article : Les composants du système (objets) dans la partie sur l'architecture orientée objet. Ça me semble un contresens : les composants ne sont pas au même niveau que les objets ...

Tout dépend de ce que tu entends par niveau. De ta sémantique de la parenthèse () synonyme, généralisation, spécialisation. Un contresens nécessite des antonymes, objet est donc pour toi un antonyme de composant

Dans ma culture, un Composant logiciel c'est ça ... d'ou la confusion peut être. Pour moi un composant c'est une vue différente par rapport à une classe. De ce que je sais, mais je peux me tromper, un composant est plus vu en terme de connecteur et d'interface, quand une classe est vue en terme de passage de message, de méthode. Dans tout les cas il faut des références pour sourcer tout ça. Parce que là, en l'état actuel de l'article, je vois pas la différence entre la programmation et la conception orientée objet, et l'architecture logicielle avec un style architectural OO. C'est la même chose, pour toi ? Des références solides si c'est bien le cas ? D'ailleurs je note que dans composant logiciel que j'ai filé sur les composants, c'est bien UML qui est utilisé sur le schéma, et il représente bien un composant et pas une classe. Pour toi alors la programmation par composant c'est quoi, un style architectural ? Note que j'essaye de comprendre ce qui est pas clair pour moi et que je trouve pas clair dans l'article. TomT0m (d) 19 mars 2010 à 17:26 (CET)

En aucun cas je ne parle de composant logiciel qui est simplement un moyen de réaliser la réutilisation de composant provenant de langage de programmations différents et/ou de plate-formes différentes en utilisant un proxy et/ou le marshalling. Le mot composant est un terme totalement générique de la langue française pouvant être utilisé à toute sorte de sauce. Par exemple, dans un diagrammes de composants dont je parle dans l'article, un composant est un fichier source (module). La notion de composant logiciel tel que présenté dans l'article composant logiciel est trop limitative de toute façon (orienté proxy et marshalling) et non composants réutilisables.--Nipou (d) 19 mars 2010 à 22:49 (CET)

D'après mes lecture, cette notion de composant logiciel est un peu au coeur des approches formelles (ou semi formelles plutot) de description des architectures logicielles, et en faisant une recherche sur google scholar l'approche semble plutôt commune [1], quoi que les papiers soient pas tous récents, mais quand même, c'est à mon avis au moins à aborder dans l'article, au moins dans une perspective historique... Et d'indiquer le cas échéant pourquoi les approches ont été modifiées. L'article wp:en sur les architectures logicielles parle d'ailleurs de composants logiciels comme éléments d'une architecture.

Ce n'est pas historique, c'est juste rare. La conception d'un logiciel hypercritique peut utiliser une méthode formelle. Le développement formel est très très couteux. Par contre, l'approche dont tu parles ne concerne pas l'architecture logicielle mais bien le processus logiciel.

C'est pas très dur de trouver des liens sur le net qui parlent du diagramme de composant d'UML pour modéliser l'architecture d'un logiciel, plus haut niveau qu'un diagramme de classe par exemple : [2] [3] ... donc du coup je m'interroge. TomT0m (d) 19 mars 2010 à 21:30 (CET)

Pour le diagramme de composant en UML, il me semble que la notion est plus abstraite que le module/fichier source. Tu peux modéliser n'importe quel composant logiciel avec ce diagramme, si je me trompe pas TomT0m (d) 19 mars 2010 à 21:32 (CET)

Tout à fait, j'utilise d'ailleurs ces diagrammes pour exprimer l'organisation de mes dll. Je ne voulais pas trop rentrer dans les détails qui concerne une erreur de l'article diagrammes de composants. Que je crois que tu pourrais très bien réécrire.--Nipou (d) 19 mars 2010 à 22:49 (CET)

On peut aussi regarder Programmation_orientée_composant, liée aussi dans l'article anglais qui indique que la programmation par composant est très clairement orientée architecture logicielle. Et noter que sur en: Composant logiciel redirige vers programmation orientée composant, que l'article "architecture logicielle" sur en: commence par « The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them. » donc je suis pas le seul à m'interroger sur les liens entre tout ça ... TomT0m (d) 19 mars 2010 à 21:52 (CET)

Dans mon travail, un composant est un module (un fichier de déclaration et de définition c++) contenant une ou plusieurs classes pouvant constituer un paquetage et pouvant être réutilisée tel quel par des programmes c++. Ou encore, une version compilée de ce paquetage, générant une dll et pouvant être réutilisée tel quel par n'importe quel langage de programmation générant du code natif sur une plate-forme windows. Cette dll peut également être marshaller pour se connecter avec du code managé .net ou java. --Nipou (d) 19 mars 2010 à 23:02 (CET)

D'autre part apparemment c'est pas vraiment le seul ADL existant, si j'en crois cette thèse : [4]

Il en existe des centaines mais c'est le seul qui est resté vivant et qui est enseigné et utilisé partout, c'est un standard ISO (ISO/IEC 19501). C'est certain qu'il existe encore des tonnes de diagrammes legacy en entreprise, comme des centaines de millions de lignes de Cobol et de Fortran.

Une thèse est une très mauvaise référence. Lit des manuels universitaires reconnus.

C'est à dire ? Références ? Je veux bien qu'une thèse soit issue du monde académique et pas forcément en phase avec l'industrie, mais sur wikipedia la règle qui prime c'est la neutralité de point de vue, donc a priori il faudrait au moins évoquer les autres points de vue sur la question. TomT0m ([[Discussion

Merci pour la thèse. On y apprend que le seul pays au monde où l'on s'acharne à faire des recherches sur les ADL sont la France et la Tchécoslovaquie. Les américains ont gagné la guerre depuis déjà quinze ans et tous les pays du monde (France comprise) enseignent et utilisent maintenant UML. En fait, c'est une petite entreprise américaine, Rational Software fondée en 1981, qui a gagné la guerre. Elle a été vendu en 2003 à IBM pour 2.1 milliards (US).

Proposition : Un mot sur les qualité, vues comme des propriétés émergente de l'assemblage (architecture), me semblerait également utile. Cela justifie la définition d'architecture ; pour réfléchir aux propriétés émergentes : les qualités (propriétés non-fonctionnelles)

Contre argument : Les qualités n'émergent pas par magie, elles sont recherchés par l'architecte qui utilise ses compétences architecturales pour les obtenir.

--Nipou (d) 11 mars 2010 à 23:37 (CET)

Manques de l'article

Salut, je suis étonné de ne voir aucune référence ou wikilien vers génie logiciel ou composant logiciel dans l'article, il me semblait que la notion de composant était centrale dans certaine définitions de l'architecture logicielle.

Je ne suis pas un wikignome, j'aime bien les wikignomes. Il faudrait plutôt un lien vers la phase de conception du processus logiciel et du génie logiciel vers l'architecture logicielle. L'architecture logicielle ne couvre qu'un des 31 chapitres du Pressman (bible nord américaine du génie logiciel).

Une phrase comme . Il est important, ici, de ne pas confondre la phase d'élaboration du macro-cycle de développement d'une méthode itérative comme UP (Unified Process) et la phase de conception d'une méthode linéaire. me semble aussi complètement incompréhensible, et extrêmement technique pour le deuxième paragraphe de l'article, sans de très très solides connaissances, et références externes, qui ne sont pas non plus citées ou pas de manière explicites :/ Idéalement cette partie de l'article devrait être "autosuffisante" pour qu'un béotien puisse la lire sans trop de problème, là j'ai l'impression qu'il faut de très très solides connaissances en génie logiciel, et peut être pire, les mêmes que l'auteur, pour comprendre ...

Tout à fait d'accord, c'est retiré.

En lisant ce paragraphe personnellement je ne vois aucune vision globale de ce qu'est l'architecture logicielle, de comment elle se situe dans le génie logiciel, des différentes définitions et écoles qu'on pourrait trouver.

C'est à l'article génie logiciel de référencer l'architecture logicielle et de la situer en son sein, pas le contraire.

Ce domaine est maintenant normalisé. Les écoles n'existent plus. Il ne faut surtout pas introduire plus de confusion qu'il n'y a déjà. Profitons d'une seule vision sémantiquement homogène. Cette vision est de toute façon tellement riche qu'elle synthétise tout ce qui c'est fait depuis le début. La seule chose de vraiment importante concernant l'architecture logicielle est de la normaliser de manière à ce que tous les informaticiens du monde entier peuvent se comprendre et comprendre le travail de leurs prédécesseurs.

Je continue avec le paragraphe suivant, et les critères de qualité logicielle : ils n'auraient pas plus leur place dans l'article qualité logicielle ?

Tout à fait d'accord, mais une fusion sans perte.

TomT0m (d) 18 mars 2010 à 18:42 (CET)