Nos problèmes informatiques sont-ils tous réglés et partis pour autant ? Sûrement pas ! Ils sont plutôt remplacés par de nouveaux défis portant notamment sur la conception de systèmes, la visualisation, le débogage, la validation, la vérification et l’interopérabilité. Bran Selic, vice-président d’ObjecTime et coauteur de la méthodologie ROOM (Real-time Object-Oriented Modeling, maintenant UML-RT), illustrait avec humour, lors d’une conférence, la complexité du problème. Il y mentionnait que s’il est depuis fort longtemps possible de faire des programmes dits spaghetti avec les langages de programmation traditionnels, la venue de CORBA et des objets répartis mène tout droit vers du spaghetti avec boulettes (les objets) ! Bien qu’ils nous aident à résoudre certains problèmes de conception et de réalisation, ces objets, sur lesquels nous n’avons pas une totale maîtrise, qui sont créés et détruits à la volée et qui communiquent entre eux dans tous les sens, ajoutent de nouveaux défis d’une complexité sans précédent.
Il y a cependant une solution connue à ces nouveaux problèmes : encore et toujours l’information et surtout la formation. Les problèmes liés aux systèmes répartis sont souvent d’une subtilité telle que nous n’avons guère le choix de nous les faire présenter et expliquer pour bien les comprendre. Bien sûr, ces problèmes n’ont pas encore été entièrement résolus, et les solutions existantes sont souvent simplistes et loin d’offrir la flexibilité et l’efficacité souhaitables. La formation ne cherche pas à se substituer à la recherche et au développement, mais plutôt à en diffuser et à en enseigner les résultats et les leçons. Il ne faut donc pas hésiter à aller chercher de l’aide afin de maintenir ou d’acquérir des compétences dans ce domaine.
L’ouverture des systèmes et des normes n’est pas gage d’interopérabilité. Encore trop souvent malheureusement, deux applications se conformant à la même norme auront des problèmes de compatibilité et ne pourront interagir correctement. Les systèmes « ouverts » fonctionnant aujourd’hui le sont souvent parce qu’ils partagent le même code. Au début des années 80, l’un des buts de l’OSI (« Open Systems Interconnection ») visait justement à promouvoir une ouverture basée sur le fait que tous devaient utiliser les mêmes concepts spécifiés formellement. OSI s’est malheureusement soldé par un échec, et nous avons donc dû nous rabattre sur des solutions plus simples.
Beaucoup d’efforts et de bonne volonté sont nécessaires à la définition de normes et de standards de qualité, ce qui est d’autant plus difficile à réaliser dans un contexte de compressions budgétaires et de pressions du marché où le temps alloué à la sortie d’un produit est de plus en plus réduit. Ceci pourrait avoir un effet dramatique à long terme. Il faut prendre dès maintenant le temps de bien faire les choses et d’établir formellement des architectures et des fondations solides qui sauront résister à l’usure du temps et qui simplifieront la création et l’évolution des systèmes et applications informatiques de demain.
Peut-être devrons-nous aussi, en tant que
consommateurs de produits informatiques, faire la part des choses et nous
assurer de la maturité de tels produits avant de nous précipiter
pour les acheter et les utiliser... Le tout se joue déjà dans
notre cour !
Sincères remerciements à toutes
et à tous,
DanielAmyot,
ift.a.
Rédacteur en chef
Daniel.Amyot@apiiq.qc.ca