Riff News

Portable Common Tool Environment

Norme d'interfaces pour les outils de génie logiciel, élaborée dans le cadre du projet ESPRIT 32 "A Basic for a Portable Common Tool Environment".

De 1986 à 1989, les versions 1.x de PCTE spécifiaient une interface utilisateur. A partir de cette époque, la progression rapide des interfaces utilisateur graphiques dans tous les secteurs du logiciel ont conduit à restreindre PCTE aux interfaces programmatiques (API), en supprimant le volet "interface utilisateur".

La première version de la norme ainsi révisée, élaborée par l'ECMA parut en 1990. La deuxième, en Juin 1993, fut soumis à l'ISO/IEC JTC1 pour progression au statut de norme internationale, atteint grâce à la procédure accélérée ("fast track") en Septembre 1994.

PCTE fait l'objet des normes ECMA-149 et ISO/IEC 13719-1. La version ECMA inclut des considérations additionnelles provenant des normes ECMA-227 (extensions pour le support des objets à granularité fine) et ECMA-255 (extensions pour l'orientation objet).

1986

bac à sable

multi-niveau (ou multiniveau, ou multi-strates)

Architecture logicielle séparant les fonctions des applications sur plusieurs étages (strates) de traitements, typiquement:

• modèle 2-tier : client/serveur : 2 niveaux = client et serveur. Le modèle à deux niveaux maître/esclave n'est pas habituellement considéré dans ce contexte.
• modèle 3-tier : client (interaction utilisateur), serveur d'applications (règles de gestion), serveur de données
• modèles n-tier avec n > 3 : client (interaction utilisateur), divers niveaux de liaison et de traitement de règles (serveur Web, serveurs d'applications, brokers d'objets distants, moniteur transactionnel), serveur de données

Dans la presse francophone peu technique, on rencontre fréquemment les formes erronées "3 tiers" "multi-tiers" et "n tiers", francisations hasardeuses des "3-tier", "multi-tier" et "n-tier" anglais.

90s

Orthographe erronée pour multi-tier.

90s

Par exemple, si un serveur agile reçoit successivement une requête lourde (complexe à calculer, gros jeu de résultats) et une requête légère avant d'avoir fini de répondre à la première, il pourra renvoyer le jeu de résultats de la seconde tout en continuant à traiter la première, alors qu'un serveur non agile l'aurait traité dans l'ordre d'arrivée. L'utilisation de serveurs agiles permet donc d'améliorer les performances ses sites Web en servant rapidement les requêtes simples même en présence de requêtes complexes.

Dans un environnement COM/IIS, un objet peut être rendu agile par l'agrégation d'un distributeur free-threaded (free-threaded marshaler) : lorsqu'un pointeur d'interface est passé entre deux appartements, le distributeur free-threaded est en mesure de fournir un pointeur sur l'objet, et non un accès par mandataire, plus lent. Voir "COM", "IIS".

fin 90s

Object Modeling Technique

mi-90s

Object Oriented Software Engineering

mi-90s

modèle en spirale

Dérivé du modèle de développement en cascade (waterfall model), le modèle de développement en spirale est aussi un modèle de cycle de vie du logiciel (ALM), mais il prend en compte la nécessité pratique d'opérer des aller-retours entre les phases d'analyse, conception, réalisation et test, et produisant des versions intermédiaires à la fin de chaque module.

La modularisation du projet permet d'itérer sur les diverses phases pour chaque module, ne bloquant pas l'équipe en charge d'un module dans l'attente de la fin d'un autre module.

L'explosion de la complexité et des coûts lors de l'analyse rencontrée dans le modèle en cascade est limitée par le fractionnement : un module identifié comme complexe peut être développé plus tôt, limitant l'impact de la progression exponentielle des coûts au fil du temps. En contrepartie, le suivi de l'avancement des projets est plus complexe que dans un modèle en cascade, les outils classiques (WBS, Gantt) n'étant pas directement applicables.

Voir M3, UML, COCOMO.

Most Significant Bit

Least Significant Bit