Discussion :

[randriano]

Bonjour,

Je me demande seulement comment gère-t-on le développement des logiciels qui existent pour plusieurs plate-formes (écrits avec un langage non portable comme Java)
Ex: Mozilla Firefox

Sur quelle plate-forme a travaillé d'abord l'équipe de développement?

[hegros]

Bonjour,

Je me demande seulement comment gère-t-on le développement des logiciels qui existent pour plusieurs plate-formes (écrits avec un langage non portable comme Java)
Ex: Mozilla Firefox

Sur quelle plate-forme a travaillé d'abord l'équipe de développement?

Justement java est portable, ceci explique cela.

La plate-forme cela peut-être n'importe quoi pourvu qu'il y existe un compilateur (java par exemple) ou un cross-compilateur dans le cas de langage compilé(c++ par exemple)

[wiztricks]

Un développement dépend de fonctionnalités qu'à ou n'a pas la plateforme.

Si on veut réduire les soucis de "portage", on utilisera un langage disponible partout: Java, C, C++ ou encore Python, Ruby, etc... sont de bons candidats.

Ensuite vous allez définir les fonctionnalités "au sens large" que devra avoir la plateforme pour supporter votre logiciel et arbitrer à partir de quels composants vous allez construire ces fonctionnalités.

Ex: Si vous avez besoin de persistence, vous pourrez utiliser des fichiers plats ou une base de donnée. Et dans ce cas, choisir un SGDB qui sera disponible sur l'ensemble des "OS" que vous ciblez.

Pour revenir à Mozilla/Firefox, les spécificités de l'OS sont masquées par la Netscape Portable Runtime. C'est une bibliothèque qui fourni des API indépendantes de l'OS.
=> Mozilla est développé "au-dessus" de cette couche abstraite.
Si on souhaite porter "Mozilla" sur une plate-forme non encore supportée, on porte d'abord la NSPR puis on compile Mozilla.

-W

[randriano]

Pour revenir à Mozilla/Firefox, les spécificités de l'OS sont masquées par la Netscape Portable Runtime. C'est une bibliothèque qui fourni des API indépendantes de l'OS.
=> Mozilla est développé "au-dessus" de cette couche abstraite.

Là c'est clair !!

Donc l'équipe doit donc développer ce genre de couche logicielle avant tout?

[souviron34]

ben oui..

En fait, le fond du problème est : minimiser le travail pour passer d'un OS à l'autre..

Donc en fait, il faut maximiser le code portable (quel qu'il soit : langage C, C++, ...).

Si on a des GUI, c'est pareil.. Maximiser le code portable (méthodes et traitements).

Ensuite on peut si on le souhaite utiliser un outil graphique portable (style Java). Mais ce n'est pas obligatoire.... Tout dépend des différences entre OS sur ce qu'on veut, des standards existants, des contraintes, etc etc...

Pour mémoire, les navigateurs style Netscape/I.E. sont conçus autour du même code développé par le CERN/NCSA, en C.. Autour, il y avait le widget d'interprétation/présentation HTML, qui était X, et qui a été porté à Windows avec la Windows API.

En gros, la structure d'un tel projet serait :

• bibliothèques indépendantes
• bibliothèques dépendantes
• sources dépendants
• sources indépendants
• Makefile

Pour répondre à ta question, la plupart ont été développés au départ sur des platefrmes unixoides (Unix ou Linux)

[wiztricks]

Cette approche n'est pas seulement nécessaire au développement d'applications portable.

Le design de haut niveau définit une abstraction souvent éloignée des API bruptes offertes par l'OS ou les autres composants qui seront utilisés.
C'est une démarche descendante certes mais on s'arrête à la définition de primitives de haut niveau qui seront organisées/groupées par domaines/composants/packages.

Dans le design détaillé, on va spécifier la réalisation de ces primitives de haut niveau à partir des API "bruptes" s'il n'y a pas de contrainte de portabilité ou en encapsulant encore ces "API bruptes" via un "adaptateur" ou un wrapper.

Sans parler de portabilité, si demain il est judicieux de changer ou faire évoluer la technologie, seul l'adaptateur est à ré-écrire et/ou à tester de façon "forte".

L'adaptateur permet de visibiliser les dépendances que l'application a avec le composant qu'elle utilise. De plus, l'API du composant est parfois bien trop riche par rapport aux besoins d'une application: l'adaptateur permet de simplifier et éventuellement optimiser l'utilisation de cette API.

-W

[randriano]

Dans le design détaillé, on va spécifier la réalisation de ces primitives de haut niveau à partir des API "bruptes" s'il n'y a pas de contrainte de portabilité ou en encapsulant encore ces "API bruptes" via un "adaptateur" ou un wrapper.

Alright! Mais avec ces logiciels open source où tout le monde participe, gérer l'écriture des codes est dure?
En fait, en développement normal, il y a donc une sorte de 2 équipes: l'une pour l'API ou l'adapteur et l'autre pour le logiciel proprement parler

[wiztricks]

Alright! Mais avec ces logiciels open source où tout le monde participe, gérer l'écriture des codes est dure?

Heu... Sur la masse des logiciels qu'on peut trouver en open source (aller voir à FreshMeat), je ne connais pas la proportion de ceux qui sont disponibles sur plusieurs plate-formes.

"Disponible" recouvre des exigences fortes: disponibilité de binaires ou package compilable sans soucis, le passage d'un minimum de tests, un minimum d'utilisateurs "satisfaits"...

Maintenant essayez de réaliser vous même le port d'un logiciel open source sur une plate-forme exotique, vous verrez que les deux premières étapes ne sont pas toujours triviales car ca coince souvent sur:
- des bouts qui manquent et qui gonflent l'enveloppe du boulot à faire,
- la mise au point qui butte sur des aspects assez ardus.

Pour peu que vous ayez survécu à l'épreuve, il vous faudra ensuite négocier avec les "propriétaires" du logiciel pour qu'ils veuillent bien ré-intégrer les modifications que vous aurez pu faire dans leurs versions.
Dans le cas contraire, à chaque nouvelle version vous devrez recommencer une bonne partie du boulot.

En fait, en développement normal, il y a donc une sorte de 2 équipes: l'une pour l'API ou l'adapteur et l'autre pour le logiciel proprement parler

Si vous avez fait correctement le boulot de design détaillé en amont, vous pourrez effectivement découper la réalisation du projet en activités qui pourront être effectuées par des équipes différentes.

Il peut y avoir aussi des soucis côté compétences/savoir-faire: pour réaliser l'API, il vous faut non seulement connaître ce que vous voulez faire mais aussi comment cela peut être fait avec les API de bases que vous allez utiliser.
- W

[bruno_pages]

la portabilité sur plusieurs OS peut être résolue en utilisant une plateforme masquant autant que faire ce peut l'OS utilisé

J'utilise Qt pour Bouml ce qui le rend disponible sous Windows, les Linux, les Unix, MacOS X

[wiztricks]

Et techniquement c'est un choix que j'apprécie puisque cela me permet d'utiliser Bouml sur MAC OS X, Windows NT et Linux.

Je n'ai pas eu l'occasion de regarder les sources de Bouml pour déterminer son adhérence avec Qt3. Mais il est de notoriété publique que le passage de Qt3 à Qt4 peut s'avérer douloureux.

Et ce d'autant qu'on a omis de formaliser une couche d'abstraction homogène et cohérente au dessus de Qt.

Les qualités "homogène" et "cohérent" doivent à priori satisfaire:

• la définition d'objets mis en évidence par le "comment" ou mieux dans le "quoi",
• des méthodes (API) définies en fonction des services attendus,
• la possibilité de les construire et de les tester indépendamment de l'application (et éventuellement de choix de type "avec" comme Qt, ou GTK ou...)

Il est vrai que j'extrapole la question de portabilité à celle, beaucoup plus générique de la nécessité (ou non) de l'ajout d'une couche "abstraite" plus ou moins épaisse au dessus des différents composants ou bibliothèques utilisés.

Note: Et je ne parle pas ici d'API qui se réduisent à renommer les primitives de base... Exemple: open, connect, select, ... remplacés par des my_open, my_connect, my_select,... Ce qui a, pour l'application, une valeur ajoutée assez discutable.

C'est du boulot... donc çà coûte et c'est luxueux pour ceux qui doivent livrer vite. Inutile de s'embarquer là dedans si vous réalisez un prototype, mais cela peut être indispensable si l'application doit vivre longtemps.

Dans ce cas (et à défaut), faire évoluer un des composants majeurs de l'application aura des implications dissuasives côté des tests de non-régression à organiser, passer, vérifier.
-W

[randriano]

En effet, il y a la biblio Qt qui permet d'émuler la portabilité d'un logiciel écrit en C++.
Mais il y a aussi le choix d'une production de ne pas aimer certains produits disons Qt car ça rend l'application trop dépendante et le business de Trolltech devient rentable

Il y a donc une nécessité de développer soi-même la couche d'abstraction, qui est couteux en personnel développant car c'est pas si facile, on ne peut pas rivaliser avec Mozilla et ses nombreux collaborateurs

Pour conclure, pour une ptite équipe, il faut recourir à une biblio du genre de Qt (C++ mais je ne sais pas pour les autres langages) ou rester sur le plate-forme favori (ne rien faire)

[millie]

Je précise juste clairement (enfin je vais essayer ) qu'il y a 2 ou 3 niveaux de portabilités.


Portabilité juste au niveau langage -> nécessite une recompilation par OS et par processeur (et dans ce cas, il faut utiliser des fonctionnalités existantes sur les OS)
Portabilité du langage compilé -> ne nécessite pas de recompilation par OS (en théorie) -> c'est le cas des langages qui sont compilés vers un bytecode à machine virtuelle (java, net)
Portabilité du langage de script -> ça n'a pas besoin d'être compilé et est exécuté directement par une machine virtuelle. Ca ressemble à la portabilité du langage compilé.


Par exemple pour le C, si j'utilise l'API réseau de base, il y a des choses à porter spécifiquement pour Windows et des choses à porter spécifiquement pour les environnements UNIX. Si tu as de la chance, tu peux utiliser des API multiplateformes (même spécifications, binaires différents) pour éviter ce problème et n'écrire qu'une seule source (mais tu devras compiler plusieurs fois (en testant éventuellement sur chaque plateforme) ).

[wiztricks]

...
Il y a donc une nécessité de développer soi-même la couche d'abstraction, qui est couteux en personnel développant car c'est pas si facile, on ne peut pas rivaliser avec Mozilla et ses nombreux collaborateurs

Le coût de la couche d'abstraction dépend de son épaisseur....
Et présente l'inconvénient de n'avoir aucune valeur ajoutée côté fonctionnel: votre application ne fera rien de mieux ou de moins qu'elle ait été pensée pour être portable ou pas.
Eventuellement, le département marketing vous y incitera en faisant miroiter des clients potentiels dans les environnements x, y, z
Mais les vraies implications sont du côté coût de maintenance...
Tant que le client est prêt à payer, vous n'avez pas de soucis...

Mettez vous à la place d'une équipe comme Mozilla
- leurs revenus sont limités à des dons,
- ils veulent se différencier par rapport à Internet Explorer qui n'est disponible que sous Windows (et peut être MAC OS)
Leurs choix ont été motivés par leurs ambitions plus que par leurs moyens.

Pour conclure, pour une ptite équipe, il faut recourir à une biblio du genre de Qt (C++ mais je ne sais pas pour les autres langages) ou rester sur le plate-forme favori (ne rien faire)

En gros, une application est constituée d'un assemblage de composants qui ont des rôles et des responsabilités sur des domaines bien définis.

Tout en restant dans le modèle économique standard - (je ne dépense un sous que si ca me rapporte tout de suite), il y a quand même quelques pistes à ne pas évacuer d'emblée:

- factoriser : nombre de composants ont des dépendances avec des fonctionnalités particulières de Qt ou d'une autre bibliothèque. Il peut être intéressant de factoriser ces dépendances en une couche de services "au dessus de".
-> c'est toujours çà de gagné côté tests unitaires.
- confiner : vous utilisez Qt (ou autre) pour par exemple l'IHM - et je sais que Qt est beaucoup plus vaste que cela. Le composant IHM peut être construit avec Qt tout en offrant des interfaces avec le reste qui seront indépendantes (de Qt).

-W

[wiztricks]

Par exemple pour le C, si j'utilise l'API réseau de base, il y a des choses à porter spécifiquement pour Windows et des choses à porter spécifiquement pour les environnements UNIX. Si tu as de la chance, tu peux utiliser des API multiplateformes (même spécifications, binaires différents) pour éviter ce problème et n'écrire qu'une seule source (mais tu devras compiler plusieurs fois (en testant éventuellement sur chaque plateforme) ).

La question telle que je l'ai comprise ne portait pas sur la portabilité des langages mais plus généralement sur les pré-requis à l'écriture d'applications portables. Autrement dit comment forcer "la chance" et limiter les tests à effectuer lorsqu'on passait d'une plate-forme à une autre...

Utiliser un langage et des composants externes disponibles a peu près partout est un pré-requis.
Ceci dit les composants externes évoluent eux aussi: nouvelles versions, disparition, ... cela pourra demander une re-qualification plus ou moins poussée.

- W