Architecture logicielle

3.3518005539831 (1083)
Posté par seb 07/04/2009 @ 06:09

Tags : architecture logicielle, développement, high-tech

Dernières actualités
6 cores pour l'Opteron Istanbul - Tom's Hardware
AMD pense aussi aux entreprises en proposant quelques options intéressantes comme la possibilité de limiter le nombre de cores de façon logicielle. Une idée qui semble ridicule, mais qui a un intérêt avec certains programmes dont les licences sont...
Developpeur c#.net - PC-InfoPratique
Vous avez de bonnes notions d'architecture logicielle. Vous travaillez en autonomie et appréciez également le travail d'équipe. Votre sensibilité aux nouvelles technologies sera un atout pour ce poste. Un bon relationnel est impératif afin de vous...
Avaya présente Contact Center Express 4.0 - Silicon.fr
Sa nouvelle architecture Aura ouvre l'accès à ses solutions indépendamment des infrastructures. Fournisseur de solutions de communication unifiée et de gestion de la relation client (CRM), notamment pour les travers les centres de contacts,...
MIPS : un code source optimisé pour Android - Clubic
... d'Android spécialement optimisé pour les appareils basés sur l'architecture MIPS. Cela devrait permettre l'adoption du système d'exploitation bien au-delà du téléphone portable et viser le marché du logiciel embarqué à l'image de Windows Embedded....
SugarCRM 5.5 débarque avec de nouvelles options - l'Informaticien
Au menu, une interface qui supporte maintenant le référentiel de thèmes REST (Representational State Transfer) notamment, beaucoup utilisée pour l'architecture des services web. REST permettra également de rendre plus simple l'interaction avec des...
Nouveaux Athlon et Phenom : AMD se concentre sur le double-coeur - Silicon.fr
Compatible socket AM3 et son architecture hypertransport jusqu'à 4 ghz, le Phenom II 550 voit sa consommation grimper à 80 W. Soit des caractéristiques assez proches de l'Athlon II X2 250. Mais le Phenom 550 s'en détache en permettant l'overclocking de...
Processeurs multicœurs pour serveurs : le logiciel suivra-t-il ? - Indexel.net
La virtualisation apparaît comme un moyen d'exploiter les architectures multicœurs. L'hyperviseur pourra par exemple allouer un cœur par machine virtuelle. Cela a de l'intérêt dans un contexte de consolidation de serveurs existants mais aussi pour...
Pilotes projet, Ingénieurs, Techniciens - L'Usine Nouvelle
Informatique : Développement logiciel embarqué Avionique et Ferroviaire, qualité logiciel, codage automatique (SCADETM , RTWTM ), développements logiciels langages C/C++/JAVA/ADA, architecture client serveur, WEB, bases de données, OS, couches basses...
Google Search Appliance 6.0 indexe près de 30 millions de documents - Vnunet.fr
"Avec le perfectionnement de l'architecture de ce logiciel, les entreprises peuvent proposer des recherches professionnels sécurisées au sein de millions de sources internes et externes à partir d'un seul système Google Search Appliance",...
Open Object - Un nouveau site communautaire pour Open ERP - LinuxFr
... par exemple Medical (http://medical.sf.net), un logiciel de gestion des patients et hôpitaux. Open Object permet de développer rapidement des applications haut niveau en Python. Il est basé sur une architecture 3 tiers (PostgreSQL, serveur,...

Architecture logicielle

logo universel du recyclage

L’architecture logicielle décrit d’une manière symbolique et schématique les différents composants d’un ou de plusieurs systèmes informatiques, leurs interrelations et leurs interactions. Contrairement aux spécifications produites par l’analyse fonctionnelle, le modèle d'architecture, produit lors de la phase de conception, ne décrit pas ce que doit réaliser un système informatique mais plutôt comment il doit être conçu de manière à répondre aux spécifications. L’analyse décrit le « quoi faire » alors que l’architecture décrit le « comment le faire ».

La phase de conception logicielle est l'équivalent, en informatique, à la phase de conception en ingénierie traditionnelle (mécanique, civile ou électrique); cette phase consiste à réaliser entièrement le produit sous une forme abstraite avant la production effective. Par contre, la nature immatérielle du logiciel (modelé dans l'information et non dans la matière), rend la frontière entre l'architecture et le produit beaucoup plus floue que dans l'ingénierie traditionnelle. L'utilisation d'outils CASE (Computer-aided software engineering) ou la production de l'architecture à partir du code lui-même et de la documentation système permettent de mettre en évidence le lien étroit entre l'architecture et le produit.

L'architecture logicielle constitue le plus gros livrable d'un processus logiciel après le produit (le logiciel lui-même). En effet, la phase de conception devrait consommer autour de 40 % de l'effort total de développement et devrait être supérieure ou égale, en effort, à la phase de codage. 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. Dans une méthode linéaire, les activités de conception se retrouvent regroupées en une seule grande phase alors qu'elles sont distribuées dans l'ensemble des micro-cycles d'une méthode itérative. Dans les deux cas, l'effort total de conception devrait être proche de 40 % mais il peut être moindre. L'effort dépend grandement du type de logiciel développé, de l'expertise de l'équipe de développement, du taux de réutilisation et du processus logiciel.

Les deux objectifs principaux de toute architecture logicielle sont la réduction des coûts et l'augmentation de la qualité du logiciel; la réduction des coûts est principalement réalisée par la réutilisation de composants logiciels et par la diminution du temps de maintenance (correction d'erreurs et adaptation du logiciel). La qualité, par contre, se trouve distribuée à travers plusieurs critères; la norme ISO 9126 est un exemple d'un tel ensemble de critères.

L'interopérabilité exprime la capacité du logiciel à communiquer et à utiliser les ressources d'autres logiciels comme, par exemple, les documents créés par une certaine application.

La portabilité exprime la possibilité de compiler le code source et/ou d'exécuter le logiciel sur des plates-formes (machines, systèmes d'exploitation, environnements) différents.

La compatibilité exprime la possibilité, pour un logiciel, de fonctionner correctement dans un environnement ancien (compatibilité descendante) ou plus récent (compatibilité ascendante).

La validité exprime la conformité des fonctionnalités du logiciel avec celles décrites dans le cahier des charges.

La vérifiabilité exprime la simplicité de vérification de la validité.

L'intégrité exprime la faculté du logiciel à protéger ses fonctions et ses données d'accès non autorisés.

La fiabilité exprime la faculté du logiciel à gérer correctement ses propres erreurs de fonctionnement en cours d'exécution.

La maintenabilité exprime la simplicité de correction et de modification du logiciel, et même, parfois, la possibilité de modification du logiciel en cours d'exécution.

La réutilisabilité exprime la capacité de concevoir le logiciel avec des composants déjà conçus tout en permettant la réutilisation simple de ses propres composants pour le développement d'autres logiciels.

L'extensibilité exprime la possibilité d'étendre simplement les fonctionnalités d'un logiciel sans compromettre son intégrité et sa fiabilité.

L'efficacité exprime la capacité du logiciel à exploiter au mieux les ressources offertes par la ou les machines où le logiciel sera implanté.

L'autonomie exprime la capacité de contrôle de son exécution, de ses données et de ses communications.

La transparence exprime la capacité pour un logiciel de masquer à l'utilisateur (humain ou machine) les détails inutiles à l'utilisation de ses fonctionnalités.

La composabilité exprime la capacité pour un logiciel de combiner des informations provenant de sources différentes.

La simplicité d'utilisation décrit la facilité d'apprentissage et d'utilisation du logiciel par les usagers.

Une architecture faible ou absente peut entraîner de graves problèmes lors de la maintenance du logiciel. En effet, toute modification d'un logiciel mal architecturé peut déstabiliser la structure de celui-ci et entraîner, à la longue, une dégradation (principe d'entropie du logiciel). L'architecte devrait donc concevoir, systématiquement, une architecture maintenable et extensible.

Dans les processus itératifs comme UP (Unified Process), la gestion des changements est primordiale. En effet, il est implicitement considéré que les besoins des utilisateurs du système peuvent changer et que l'environnement du système peut changer. L'architecte a donc la responsabilité de prévoir le pire et de concevoir l'architecture en conséquence; la plus maintenable possible et la plus extensible possible.

Bien des logiciels ont été créés sans architecture par plusieurs générations de développeurs ayant chacune usé d'une imagination débordante pour réussir à maintenir l'intégrité du système. Une telle absence d'architecture peut être qualifiée d'architecture organique. En effet, un développeur confronté à une telle architecture a plus l'impression de travailler avec un organisme vivant qu'avec un produit industriel. Il en résulte que la complexité du logiciel fait en sorte que celui-ci est extrêmement difficile à comprendre et à modifier. À la limite, modifier une partie du système est plus proche, en complexité, de la transplantation cardiaque que du changement de carburateur.

La réutilisation de composants logiciels est l'activité permettant de réaliser les économies les plus substantielles, encore faut-il posséder des composants à réutiliser. De plus, la réutilisation de composants nécessite de créer une architecture logicielle permettant une intégration harmonieuse de ces composants. Le développement par la réutilisation logicielle impose donc un cycle de production-réutilisation perpétuel et une architecture logicielle normalisée.

Une réutilisation bien orchestrée nécessite la création et le maintien d'une bibliothèque logicielle et un changement de focus; créer une application revient à créer les composants de bibliothèque nécessaires puis à construire l'application à l'aide de ces composants. Une telle bibliothèque, facilitant le développement d'application est un framework (cadriciel) d'entreprise et son architecture, ainsi que sa documentation sont les pierres angulaires de la réutilisation logicielle en entreprise.

Le rôle de l'architecte se déplace donc vers celui de bibliothécaire. L'architecte doit explorer la bibliothèque pour trouver les composants logiciels appropriés puis créer les composants manquants, les documenter et les intégrer à la bibliothèque. Dans une grande entreprise, ce rôle de bibliothécaire est rempli par l'architecte en chef qui est responsable du développement harmonieux de la bibliothèque et de la conservation de l'intégrité de son architecture.

La description d'un système complexe comme un logiciel informatique peut être faite selon plusieurs points de vue différents mais chacun obéit à la formule de Perry et Wolf : Architecture = Elements + Formes + Motivations. Selon le niveau de granularité, les éléments peuvent varier en tailles (lignes de code, procédures ou fonctions, modules ou classes, paquetages ou couches, applications ou systèmes informatiques), ils peuvent varier en raffinement (ébauche, solution à améliorer ou solution finale) et en abstraction (idées ou concepts, classes ou objets, composants logiciels physiques). Les éléments peuvent également posséder une temporalité (une existence limité dans le temps) et une localisation (une existence limité dans l'espace).

Si les éléments sont, en général, représentés par des rectangles ou des ovales, les formes sont quant-à-elles constituées, la plupart du temps, d'éléments reliés par des droites ou des flèches. La sémantique des liens détermine la majeure partie de la sémantique du diagramme et l'aspect du système qui y est décrit.

La dépendance fonctionnelle, signifie que l'élément source nécessite l'élément de destination pour réaliser ses fonctionnalités.

Le flot de contrôle, signifie que l'élément de destination prendra le contrôle de l'exécution après la terminaison de l'élément source.

La transition d'état, signifie que le système passera de l'état source à l'état de destination.

Le changement d'activité, signifie que le système réalisera l'activité de destination après l'activité source.

Le flot de données, signifie que l'information s'écoule de l'élément source vers l'élément de destination.

Le lien de communication, signifie que deux éléments échangent de l'information.

La composition, signifie que l'élément source est composé d'une ou de plusieurs données du type de l'élément de destination.

L'héritage (généralisation), signifie que l'élément source possède l'ensemble des données et des comportements de l'élément de destination.

L'envoi de message, signifie que l'élément source envoie un message à l'élément de destination.

Indépendamment de la forme que prend un diagramme d'architecture, celui-ci ne représente toujours qu'un point de vue sur le système considéré, le plus important étant les motivations. En effet, à quoi sert de produire un diagramme s'il est inutile (pas utilisé) ou si les raisons des choix architecturaux sont vagues et non-explicités. Pour éviter de formuler les motivations pour chaque diagramme, l'architecte produira les différents diagrammes en fonction d'un modèle de conception et réutilisera des patrons de conception éprouvés.

Un modèle de conception (ou d'architecture) est composé d'un ensemble de points de vue, chacun étant composé d'un ensemble de différentes sortes de diagrammes. Il propose également des moyens pour lier les différentes vues et diagrammes les uns aux autres de manière à naviguer aisément, il s'agit des mécanismes de traçabilité architecturale. La traçabilité doit également s'étendre aux spécifications systèmes et même jusqu'aux besoins que ces spécifications comblent. La devise des trois pères fondateurs d'UML est « Centré sur l'architecture, piloté par les cas d'utilisation et au développement itératif et incrémentiel ». Cette devise indique clairement qu'aucune décision architecturale ne doit être prise sans que celle-ci ne soit dirigée (pilotée) par la satisfaction des spécifications systèmes (cas d'utilisation).

Ce diagramme décrit, à gauche, les spécifications systèmes qui sont également représentées par des diagrammes (Entités-Relations, Flux de données, États-Transitions). Et à droite, nous avons les différentes activités de conception prenant comme intrants les livrables de la phase d'analyse. Nous voyons que l'architecture logicielle traditionnelle nécessiterait de produire au moins quatre vues distinctes : une architecture des données (conception des données), une architecture fonctionnelle et/ou modulaire (conception architecturale), une autre architecture fonctionnelle et/ou modulaire pour les interfaces utilisateurs (conception des interfaces) et une architecture détaillée (ordinogrammes, états-transitions) des différents modules (conception des composants).

La pyramide exprime que chaque couche est bâtie sur la précédente. En effet, les composants réalisant les fonctionnalités du logiciel doivent manipuler des éléments de données qui doivent donc être préalablement décrits. De même, les composants réalisant les interfaces utilisateurs doivent utiliser les fonctionnalités du logiciel préalablement décrites. Et finalement, la création de l'architecture détaillée de chacun des composants du logiciel nécessite, évidemment, que ceux-ci soient préalablement inventés.

Ce modèle d'architecture impose une séparation claire entre les données, les traitements et la présentation.

Puisque l'analyse produit également des diagrammes, il est naturel de se questionner, en effet, quand se termine l'analyse et quand commence l'architecture ? La réponse à cette question est fort simple : les éléments des diagrammes d'analyse correspondent à des éléments visibles et compréhensibles par les utilisateurs du système, alors que les éléments des diagrammes d'architectures ne correspondent à aucune réalité tangible pour ceux-ci.

Le modèle de Kruchten dit modèle des 4 + 1 vues est celui adopté dans l'Unified Process. Ici encore, le modèle d'analyse, baptisé vue des cas d'utilisation, constitue le liant et motive la création de tous les diagrammes d'architecture.

La vue des cas d'utilisation est un modèle d'analyse formalisé par Ivar Jacobson. Un cas d'utilisation est défini comme un ensemble de scénarios d'utilisation, chaque scénario représentant une séquence d'interaction des utilisateurs (acteurs) avec le système.

L'intérêt des cas d'utilisation est de piloter l'analyse par les exigences des utilisateurs. Ceux-ci se sentent concernés car ils peuvent facilement comprendre les cas d'utilisation qui les concernent. Cette méthode permet donc d'aider à formaliser les véritables besoins et attentes des utilisateurs; leurs critiques et commentaires étant les briques de la spécification du système.

Chaque cas d'utilisation est représenté par un diagramme de cas d'utilisation, chacun des scénarios de celui-ci étant décrit par un ou plusieurs diagrammes dynamiques : diagrammes d'activités, de séquence, diagrammes de communication ou d'états-transitions.

La vue logique constitue la principale description architecturale d'un système informatique et beaucoup de petits projets se contentent de cette seule vue. Cette vue décrit, de façon statique et dynamique, le système en terme d'objets et de classes. La vue logique permet d'identifier les différents éléments et mécanismes du système à réaliser. Elle permet de décomposer le système en abstractions et est le cœur de la réutilisation. En effet, l'architecte récupérera un maximum de composants des différentes bibliothèques et cadriciels (framework) à sa disposition. Une recherche active de composants libres et/ou commerciaux pourra également être envisagée.

La vue logique est représentée, principalement, par des diagrammes statiques de classes et d'objets enrichis de descriptions dynamiques : diagrammes d'activités, de séquence, diagrammes de communication ou d'états-transitions.

La vue des processus décrit les interactions entre les différents processus, threads (fils d'exécution) ou tâches, elle permet également d'exprimer la synchronisation et l'allocation des objets. Cette vue permet avant tout de vérifier le respect des contraintes de fiabilité, d'efficacité et de performances des systèmes multitâches.

Les diagrammes utilisés dans la vue des processus sont exclusivement dynamiques : diagrammes d'activités, de séquence, diagrammes de communication ou d'états-transitions.

La vue de réalisation permet de visualiser l'organisation des composants physiques (bibliothèque dynamique et statique, code source...) dans l'environnement de développement. Elle permet aux développeurs de se retrouver dans le capharnaüm que peut être un projet de développement informatique. Cette vue permet également de gérer la configuration (auteurs, versions...).

Les seuls diagrammes de cette vue sont les diagrammes de composants.

La vue de déploiement représente le système dans son environnement d'exécution. Elle traite des contraintes géographiques (distribution des processeurs dans l'espace), des contraintes de bandes passantes, du temps de réponse et des performances du système ainsi que de la tolérance aux fautes et aux pannes. Cette vue est fort utile pour l'installation et la maintenance régulière du système.

Les diagrammes de cette vue sont les diagrammes de composants et les diagrammes de déploiement.

L'architecture logicielle, tout comme l'architecture traditionnelle, peut se catégoriser en styles. En effet, malgré les millions de systèmes informatiques construits de par le monde au court des cinquante dernières années, tous se classent parmi un nombre extrêmement restreint de styles architecturaux. De plus, un système informatique peut utiliser plusieurs styles selon le niveau de granularité ou l'aspect du système décrit. Nous ferons remarquer que, comme en architecture traditionnelle, c'est souvent par le mélange d'anciens styles que les nouveaux apparaissent.

Cette architecture est basée sur le raffinement graduel proposé par Niklaus Wirth. Cette approche, également appelée décomposition fonctionnelle, consiste à découper une fonctionnalité en sous-fonctionnalités qui sont également divisées en sous sous-fonctionnalités et ainsi de suite; la devise diviser pour régner est souvent utilisée pour décrire cette démarche.

Si à l'origine cette architecture était basée sur l'utilisation de fonctions, le passage à une méthode modulaire ou objet est toute naturelle; la fonctionnalité d'un module ou d'un objet est réalisée par des sous-modules ou des sous-objets baptisés travailleurs (worker). Le terme hiérarchie de contrôle est alors utilisé pour décrire l'extension de cette architecture au paradigme modulaire ou objet. Une forme dérivée de cette architecture est l'architecture distribuée où les fonctions, modules ou classes se retrouvent répartis sur un réseau.

La conception de logiciels nécessite de recourir à des bibliothèques. Une bibliothèque très spécialisée utilise des bibliothèques moins spécialisées qui elles-mêmes utilisent des bibliothèques génériques. De plus, comme nous l'avons déjà mentionné, le développement efficace de composants réutilisables nécecessite de créer une bibliothèque logicielle; l'architecture en couche est la conséquence inéluctable d'une telle approche. En effet, les nouveaux composants utilisent les anciens et ainsi de suite, la bibliothèque tend donc à devenir une sorte d'empilement de composants. La division en couches consiste alors à regrouper les composants possédant une grande cohésion (sémantiques semblables) de manière à créer un empilement de paquetages de composants; tous les composants des couches supérieures dépendants fonctionnellement des composants des couches inférieures.

Dans cette architecture, un composant central (SGBD, Datawarehouse, Blackboard) est responsable de la gestion des données (conservation, ajout, retrait, mise-à-jour, synchronisation, ...) . Les composants périphériques, baptisés clients, utilisent le composant central, baptisé serveur de données, qui se comporte, en général, de façon passive (SGBD, Datawarehouse). Un serveur passif ne fait qu'obéir aveuglément aux ordres alors qu'un serveur actif (Blackboard) peut notifier un client si un changement aux données qui le concerne se produit.

Cette architecture sépare clairement les données (serveurs) des traitements et de la présentation (clients) et permet ainsi une très grande intégrabilité, en effet, des clients peuvent être ajoutés sans affecter les autres clients. Par contre, tous les clients sont dépendants de l'architecture des données qui doit rester stable et qui est donc peu extensible. Ce style nécessite donc un investissement très important dans l'architecture des données. Les datawarehouses et les bases de données fédérées sont des extensions de cette architecture.

Cette architecture est composée de plusieurs composants logiciels reliés entre eux par des flux de données. L'information circule dans le réseau et est transformée par les différents composants qu'elle traverse. Lorsque les composants se distribuent sur une seule ligne et qu'ils ne font que passer l'information transformée à leur voisin, on parle alors d'architecture par lot (batch). Si les composants sont répartis sur un réseau informatique et qu'ils réalisent des transformations et des synthèses intelligentes de l'information, on parle alors d'architecture de médiation.

Les composants du système (objets) intègrent des données et les opérations de traitement de ces données. La communication et la coordination entre les objets sont réalisées par un mécanisme de passage de messages. Cette architecture est souvent décrite par les trois piliers : encapsulation, héritage et polymorphisme. L'encapsulation concerne l'architecture détaillée de chaque objet, les données étant protégées d'accès direct par une couche d'interface. De plus, les sous-fonctions, inutiles pour utiliser l'objet, sont masquées à l'utilisateur de l'objet. L'héritage permet d'éviter la redondance de code et facilite l'extensibilité du logiciel, les fonctionnalités communes à plusieurs classes d'objets étant regroupées dans un ancêtre commun. Le polymorphisme permet d'utiliser des objets différents (possédant des comportements distincts) de manière identique, cette possibilité est réalisée par la définition d'interfaces à implémenter (classes abstraites).

L'architecture agent est le produit du passage du composant objectif vers le composant projectif. En effet, l'objet est essentiellement un composant passif offrant des services et utilisant d'autres objets pour réaliser ses fonctionnalités; l'architecture objet est donc une extension de l'architecture en appels et retours. L'agent, par contre, utilise de manière intelligente les autres agents pour réaliser ses objectifs; il établi des dialogues avec les autres agents, il négocie et échange de l'information.

L’origine de la notion d’architecture logicielle remonte à la fin des années 1960 avec l’invention de la programmation structurée. Un programme informatique était alors conceptualisé comme une suite d’étapes (flux de contrôle) représentée par les premiers diagrammes d’architecture, les organigrammes (ordinogrammes). Au début des années 1970, avec le développement de la programmation modulaire, les programmes informatiques furent considérés comme des ensembles de composants (les modules) échangeant de l’information. Les diagrammes de flux de données furent alors utilisés pour représenter ce type d’architecture.

C’est au cours de la décennie 1970–80 que les grands principes architecturaux furent élaborés. L’on distingua l’architecture système décrivant les relations et interactions de l’ensemble des composants logiciels de l’architecture détaillée décrivant l’architecture individuelle de chacun des composants. L’on sépara l’architecture statique décrivant les interrelations temporellement invariables (dépendances fonctionnelles, flux de contrôle, flux de données) de l’architecture dynamique, décrivant les interactions et l’évolution du système dans le temps (diagrammes d’activité, de séquence, d’états, réseaux de Petri, etc.). C’est également au cours de cette décennie que furent élaborés les principes directeurs de l’architecture logicielle contemporaine : masquage de l'information, indépendance fonctionnelle, forte cohésion et couplage faible. Les principaux styles architecturaux virent également le jour : architecture en appels et retours (hiérarchie de contrôle), architecture centrée sur les données, architecture en flot de données, architecture en couches et architecture orientée objets.

La décennie 1980-90 fut celle du développement de l’architecture orientée objet. Ce type d’architecture introduisit trois nouveaux types de composants logiciels : l’objet, la classe et la méta-classe (classe paramétrée ou gabarit de classe); ainsi que des relations ontologiques entre ces composants : est un (héritage), est composé de (composition), etc. La relation d’héritage est une innovation majeure permettant la réutilisation de code et facilitant son adaptation à d’autres contextes d’utilisation.

Au niveau industriel, par contre, cette décennie est sans conteste celle de l’architecture à trois couches centrée sur les données (3-tiers). Ce type d’architecture logicielle, séparant l’architecture des programmes de l’architecture des données, s’oppose ainsi complètement au principe de forte cohésion prôné par l’architecture objet. L’accent est mis sur l’architecture des données; les diagrammes de ce type d’architecture sont les modèles conceptuels de données et les schémas entités relations. Le développement des systèmes de gestion de bases de données relationnelles, des protocoles multibases ainsi que leurs normalisations (standardisations) constituent les fondations technologiques de ce choix architectural.

Au début de la décennie 1990-2000 on dénombrait un très grand nombre de représentations architecturales distinctes. En 1995, UML (Unified Modeling Language) devint la norme internationale de représentation de l’architecture logicielle. Le développement orienté objet se répand dans l’industrie, les systèmes de gestion de bases de données sont maintenant perçus comme une façon commode d’assurer la persistance des objets. Les systèmes de gestion de base de données objet-relationnels et objets font leurs apparitions. On voit également apparaître les architectures distribuées; les programmes informatiques ne sont plus simplement perçus comme devant offrir des services à des êtres humains mais également à d’autres programmes. L’arrivée des réseaux ouverts, en particulier Internet, change complètement le paysage architectural. L’architecture à trois couches centrée sur les données (3-tiers) est maintenant réalisée par le triplet serveur de base de données, serveur d’application web et navigateur web.

La recherche universitaire sur l’architecture logicielle se concentre davantage sur les problèmes de couplage entre objets et d’interopérabilité syntaxique et sémantique. Le problème du couplage est essentiellement perçu comme un problème de communication entre objets, voir de dialogues entre agents intelligents; l’architecture orientée agent apparaît. Le principe de réutilisation des composants logiciels est maintenant appliqué à l’architecture. Des façons de faire, principes ou styles architecturaux peuvent être réutilisés; les patrons de conception apparaissent.

Notre décennie est caractérisée par un retour des bases de données distribuées rendu possible grâce à la technologie XML. Le XML est un langage d'interface, syntaxiquement normalisé et possédant une très grande puissance d'expression sémantique. L'architecture 3-tiers traditionnelle se retrouve maintenant sous la forme de trois couches de médiations de données : gestion de données XML, transformation et fusion de données XML et présentation de données XML. La technologie XML permet la spécification syntaxique (DTD, XSD), la transformation (XSLT), la présentation (XSL) et la spécification sémantique (RDF, RDFS, OWL). Il existe maintenant plusieurs bibliothèques logicielles permettant de gérer les données XML et la plupart des systèmes de gestion de base de données supportent maintenant XML.

Le développement orienté agent (OA) sort progressivement des universités, il existe maintenant une multitude d'outils logiciels pour la conception de systèmes basés sur les agents mais la plupart ne sont pas encore destinés à devenir des outils de production. Le langage KQML (Knowledge Query and Manipulation Langage) est un langage de communication inter-agent qui pourrait très bien s'imposer dans un proche avenir. Il n'y aura pas de révolution au niveau des langages de programmation, les différentes fonctionnalités des agents sont implémentées à l'aide de bibliothèques logicielles. Les trois types d'architectures OA qui se dégagent sont : l'architecture réfléchie, l'architecture réactive et l'architecture hybride.

En haut



AUTOSAR

AUTOSAR (AUTomotive Open System ARchitecture) est une association internationale de développement regroupant des constructeurs automobiles, des équipementiers et des sociétés spécialisées dans l’électronique et l’informatique, créée en 2003 dans le but de développer et d’établir une architecture logicielle standardisée et ouverte pour les véhicules.

En facilitant les échanges et la mise à jour des logiciels et matériels, AUTOSAR permettra de mieux gérer la complexité croissante des systèmes embarqués, et de gagner en rentabilité sans compromis sur la qualité.

Les principaux partenaires d’AUTOSAR sont BMW Group, Bosch, Continental, Daimler Chrysler, Ford, Opel, PSA Peugeot Citroën, Siemens VDO (rachetés fin 2007 par Continental), Toyota et Volkswagen AG.

À ces entreprises, s’ajoutent une centaine de membres privilégiés (Premium members) ou associés (Associate Members) qui participent activement à la réussite de ce partenariat.

Les spécifications AUTOSAR sont mises gracieusement à la disposition de toute entreprise rejoignant le consortium.

En haut



Projet MILLE

MILLE est un projet québécois de promotion des logiciels sous licence libre au sein des établissements scolaires québécois.

MILLE signifie « Modèle d'Infrastructure de Logiciel Libre en Éducation». Le projet a pour but de réduire les coûts d'acquisition et de maintenance des infrastructures matérielles et logicielles, de réduire les coûts de développement et de maintenance des services et d'accroître l'accès à ces derniers tant à l'école qu'à la maison en proposant une architecture logicielle basée sur les logiciels libres.

Le modèle proposé s'appuie en partie sur l'utilisation d'un réseau à large bande et se compose d'une architecture matérielle où les postes clients sont centrés réseau. Grâce à cette architecture les postes clients pourront être légers, semi-légers ou lourds.

Le projet MILLE offre aux élèves, aux professeurs et aux parents une fenêtre virtuelle sur l'école, la classe et les ressources du réseau. L'utilisateur a accès à un environnement de travail personnalisé qui lui fournit un accès sécurisé aux différents services pédagogiques en ligne offerts par l'école et utilisés dans sa classe. Un Bureau Virtuel intègre l'ensemble des services et en gère l'accès.

En haut



Java (langage)

Java Logo.svg

Le langage Java est un langage de programmation informatique orienté objet créé par James Gosling et Patrick Naughton employés de Sun Microsystems avec le soutien de Bill Joy (cofondateur de Sun Microsystems en 1982), présenté officiellement le 23 mai 1995 au SunWorld.

Le langage Java a la particularité principale que les logiciels écrits avec ce dernier sont très facilement portables sur plusieurs systèmes d’exploitation tels que UNIX, Microsoft Windows, Mac OS ou Linux avec peu ou pas de modifications… C’est la plate-forme qui garantit la portabilité des applications développées en Java.

Le langage reprend en grande partie la syntaxe du langage C++, très utilisé par les informaticiens. Néanmoins, Java a été épuré des concepts les plus subtils du C++ et à la fois les plus déroutants, tels que l’héritage multiple remplacé par l’implémentation des interfaces. Les concepteurs ont privilégié l’approche orientée objet de sorte qu’en Java, tout est objet à l’exception des types primitifs (nombres entiers, nombres à virgule flottante, etc.).

Java permet de développer des applications client-serveur. Côté client, les applets sont à l’origine de la notoriété du langage. C’est surtout côté serveur que Java s’est imposé dans le milieu de l’entreprise grâce aux servlets, le pendant serveur des applets, et plus récemment les JSP (JavaServer Pages) qui peuvent se substituer à PHP, ASP et ASP.NET.

Java a donné naissance à un système d'exploitation (JavaOS), à un environnement de développement (eclipse/JDK), des machines virtuelles (MSJVM, JRE) applicatives multiplate-formes (JVM), une bibliothèque Java (J2ME) avec interface graphique (awt/swing), des applications java (logiciels, servlet, applet). La portabilité du code java est assuré par la machine virtuelle. JRE, - la machine virtuelle qui effectue la traduction et l'exécution du bytecode en code natif - supporte plusieurs processus de compilation (à la volée/bytecode, natif). La portabilité est dépendante de la qualité de portage des JVM sur chaque OS.

Cet historique provient d’une traduction libre d’un article du wikipedia anglophone Java programming language. N’hésitez pas à vérifier la qualité de la traduction pour être certain qu’il n’y ait pas de contresens.

La plate-forme et le langage Java sont issus d’un projet de Sun Microsystems datant de 1990. L’ingénieur Patrick Naughton n’était pas satisfait par le langage C++ utilisé chez Sun, ses interfaces de programmation en langage C, ainsi que les outils associés. Alors qu’il envisageait une migration vers NeXT, on lui proposa de travailler sur une nouvelle technologie et c’est ainsi que le Projet Stealth (furtif) vit le jour.

Le Projet Stealth fut rapidement rebaptisé Green Project avec l’arrivée de James Gosling et de Mike Sheridan. Ensemble, et aidés d’autres ingénieurs, ils commencèrent à travailler dans un bureau de la rue Sand Hill de Menlo Park en Californie. Ils essayèrent d’élaborer une technologie pour le développement d’applications d’une nouvelle génération, offrant à Sun la perspective d’opportunités uniques.

L’équipe envisageait initialement d’utiliser le langage C++, mais l’abandonna pour différentes raisons. Tout d’abord, ils développaient sur un système embarqué avec des ressources limitées, estimaient que l’utilisation du C++ demandait un investissement trop important et que cette complexité était une source d’erreur pour les développeurs. Les lacunes de ce langage au niveau du ramasse-miettes impliquaient que la gestion de la mémoire devait être programmée manuellement, un défi mais aussi une source d’erreur. L’équipe était aussi troublée par les lacunes du langage au niveau de la sécurité, de la programmation distribuée, du multi-threading. De plus, ils voulaient une plate-forme qui puisse être portée sur tout type d’appareils.

Bill Joy avait envisagé un nouveau langage combinant le meilleur du langage de programmation Mesa et du langage C. Dans un article appelé Plus loin (Further), il proposa à Sun que ses ingénieurs développent un environnement orienté objet basé sur le langage C++. À l’origine, Gosling envisageait de modifier et d’améliorer le langage C++, qu’il appelait C++ ++ --, mais l’idée fut bientôt abandonnée au profit du développement d’un nouveau langage de programmation qu’ils appelèrent Oak (chêne) en référence, on pense, à un arbre planté juste devant la fenêtre de leur bureau.

L’équipe travailla avec acharnement et, à l’été 1992, ils furent capables de faire une démonstration incluant le système d’exploitation Green, le langage Oak (1992), les bibliothèques et le matériel. Leur première réalisation, présentée le 3 septembre 1992, fut la construction d’un PDA appelé Star7 ayant une interface graphique et un agent intelligent appelé Duke pour prêter assistance à l’utilisateur. En novembre de la même année, le Green Project fut abandonné pour devenir FirstPerson, Inc, appartenant en totalité à Sun Microsystems et l’équipe fut relocalisée à Palo Alto. L’équipe FirstPerson était intéressée par la construction d’outils hautement interactifs et quand Time Warner publia un appel d’offres en faveur d’un décodeur multifonction, FirstPerson changea d’objectif pour proposer une telle plate-forme. Cependant, l’industrie de la télé par câble trouva qu’elle offrait trop de possibilités à l’utilisateur et FirstPerson perdit le marché au profit de Silicon Graphics. Incapable d’intéresser l’industrie audiovisuelle, la société fut réintroduite au sein de Sun.

De juin à juillet 1994, après trois jours de remue-méninge avec John Gage, James Gosling, Joy, Naughton, Wayne Rosing et Eric Schmidt, l’équipe recentra la plate-forme sur le web. Ils pensaient qu’avec l’avènement du navigateur Mosaic, Internet était le lieu où allait se développer le même genre d’outil interactif que celui qu’ils avaient envisagé pour l’industrie du câble. Naughton développa comme prototype un petit navigateur web, WebRunner qui deviendra par la suite HotJava.

La même année le langage fut renommé Java après qu’on eut découvert que le nom Oak était déjà utilisé par un fabricant de carte vidéo. Le nom Java fut inventé dans un petit bar fréquenté par quelques membres de l’équipe. Il n’a pas été déterminé clairement si oui ou non le nom est un acronyme, bien que certains prétendent qu’il signifie James Gosling, Arthur Van Hoff et Andy Bechtolsheim ou tout simplement Just Another Vague Acronym (littéralement « juste un acronyme vague de plus »). La croyance selon laquelle Java doit son nom aux produits vendus dans le bar est le fait que le code sur 4 octets (également appelé nombre magique) des fichiers de classe est en hexadécimal 0xCAFEBABE. Certaines personnes prétendent également que le nom de Java vient du fait que le programme était destiné à pouvoir tourner sur des systèmes embarqués, comme des cafetières (Java signifie café en argot américain). En octobre 1994, HotJava et la plate-forme Java furent présentés pour Sun Executives. Java 1.0a fut disponible en téléchargement en 1994 mais la première version publique du navigateur HotJava arriva le 23 mai 1995 à la conférence SunWorld. L’annonce fut effectuée par John Gage, le directeur scientifique de Sun Microsystems. Son annonce fut accompagnée de l’annonce surprise de Marc Andressen, vice président de l’exécutif de Netscape que Netscape allait inclure le support de Java dans ses navigateurs. Le 9 janvier 1996, le groupe Javasoft fut constitué par Sun Microsystems pour développer cette technologie. Deux semaines plus tard la première version de Java était disponible.

La possibilité des navigateurs web de lancer des applets Java garantit la pérennité de l’utilisation de Java par le grand public. Les concurrents récents des applets Java sont principalement Macromedia Flash et Javascript, mais bientôt Xul ou XAML concurrenceront ces technologies.

Les avantages de Java par rapport à Javascript sont essentiellement la portabilité. Plus l’interface est lourde, plus il est épuisant voire impossible d’adapter l’interface à tous les navigateurs du marché. Les avantages de Java par rapport à Flash sont aussi valables par rapport à Javascript : Java propose un style de langage plus élégant, et extrêmement bien documenté et propose surtout un environnement de développement intégré très efficace.

Les applets sur le poste Client peuvent communiquer avec des servlets sur le Serveur, tout comme Javascript peut communiquer avec le Serveur au moyen d’AJAX. Flash utilise la technologie Flex.

La puissance de Java est souvent utilisée pour des applications plus consistantes comme les jeux Yahoo et plus récemment les lecteurs vidéo multiplate-formes.

Côté serveur, on retrouve des classes Java qui permettent de définir des objets (classes POJO) et d'autres classes qui permettent de définir des actions sur ces objets (classes métiers). On effectue ici un travail sur les données en les modélisant sous formes d'objets. Ces objets peuvent être modifiés par des méthodes issues de classes spécialement conçues pour effectuer des opérations. Ainsi on pourra trouver par exemple une classe pour définir une pomme en tant qu'objet (taille, poids, calibre) et une autre classe pour définir des opérations sur une pomme (acheter, vendre, manger). Avec les serveurs d’applications, on utilise des EJB pour encapsuler les classes définies précédemment. Ces éléments sont utilisés dans des architectures J2EE pour des applications multi-couches. L'avantage qu'on tire de ce travail est de pouvoir cacher au client l'implémentation du code côté serveur.

L’utilisation native du langage Java pour des applications sur un poste de travail restait jusqu'à présent relativement rare à cause de leur manque de rapidité. Cependant, avec l’accroissement rapide de la puissance des ordinateurs, les améliorations au cours de la dernière décennie de la machine virtuelle Java et de la qualité des compilateurs, plusieurs technologies ont gagné du terrain comme par exemple Netbeans et l’environnement Eclipse, les technologies de fichiers partagés Limewire et Azureus. Java est aussi utilisé dans le programme de mathématique Matlab au niveau de l’interface homme machine et pour le calcul formel. Les applications Swing apparaissent également comme une alternative à la technologie .NET.

Le 13 novembre 2006, Sun annonce le passage de Java, c’est-à-dire le JDK (JRE et outils de développement) et les environnements Java EE (déjà sous licence CDDL) et Java ME sous licence GPL. En mai 2007, Sun publie effectivement OpenJDK sous licence libre. Cependant OpenJDK dépend encore de fragments de code non libre que Sun ne détient pas. C'est pourquoi la société Redhat lance en juin 2007 le projet IcedTea qui vise à remplacer les fragments de code non libre et ainsi rendre OpenJDK utilisable sans aucun logiciel propriétaire. En juin 2008, le projet IcedTea a passé les tests rigoureux de compatibilité Java (TCK) . On peut donc dire que Java devient un logiciel libre.

Cet exemple itère l’objet Iterable widgets de la classe Widget, assignant chacun de ces éléments à la variable w et ensuite appelle la méthode display() sur l’élément w (Specifié dans JSR 201).

En plus des changements au niveau du langage, des changements plus importants ont eu lieu au fil des années qui ont conduit des quelques centaines de classes dans le JDK 1.0 à plus de 3 000 dans J2SE 5.0. Des API entières, comme Swing ou Java2D ont été ajoutées et beaucoup de méthodes de l’original JDK 1.0 ont été déclarées deprecated (c’est-à-dire obsolètes et pouvant être supprimées à tout moment).

La première caractéristique, le caractère orienté objet (« OO »), fait référence à une méthode de programmation et de conception du langage. Bien qu’il existe plusieurs interprétations de l’expression orienté objet, une idée phare dans ce type de développement est que les différents types de données doivent être directement associés avec les différentes opérations qu’on peut effectuer sur ces données. En conséquence, les données et le code sont combinés dans une même entité appelé objet. Un objet peut être vu comme une entité unique regroupant un comportement, le code, avec un certain état, les données. Le principe est de séparer les choses qui changent de celles qui ne changent pas ; souvent un changement au niveau d’une structure de données va impliquer un changement dans le code servant à manipuler ces données et réciproquement. Ce découpage en entités cohérentes appelées objets permet d’avoir des fondations plus solides pour bâtir une architecture logicielle de qualité. L’objectif est de pouvoir développer des projets plus simples à gérer et de réduire le nombre de projets aboutissant à un échec.

Un autre objectif majeur de la programmation orientée objet est de développer des objets génériques de façon à ce que le code puisse être réutilisable entre différents projets. Un objet « client » générique par exemple doit avoir globalement le même comportement dans les différents projets, en particulier si ces différents projets se recoupent comme c’est souvent le cas dans les grandes organisations. Dans ce sens, un objet peut être vu comme un composant logiciel enfichable, permettant à l’industrie du logiciel de bâtir des projets d’envergure à partir d’éléments de base réutilisables et à la stabilité éprouvée tout en diminuant de manière drastique le temps de développement.

La réutilisation de code, lorsqu’elle est soumise à l’épreuve de la pratique, rencontre deux difficultés majeures : la création d’objets génériques réellement réutilisables est une notion très mal comprise et une méthodologie pour diffuser de l’information nécessaire à la réutilisation de code manque cruellement. Certaines communautés du monde « Open Source » veulent contribuer à résoudre ce problème en fournissant aux programmeurs la possibilité de diffuser largement de l’information sur les objets réutilisables et les bibliothèques objet.

La deuxième caractéristique, l’indépendance vis-à-vis de la plate-forme, signifie que les programmes écrits en Java fonctionnent de manière parfaitement similaire sur différentes architectures matérielles. On peut effectuer le développement sur une architecture donnée et faire tourner l’application sur toutes les autres.

Ce résultat est obtenu par les compilateurs Java qui compilent le code source « à moitié » afin d’obtenir un bytecode (plus précisément le bytecode Java, un langage machine spécifique à la plate-forme Java). Le code est ensuite interprété sur une machine virtuelle Java (JVM en anglais), un programme écrit spécifiquement pour la machine cible qui interprète et exécute le bytecode Java. De plus, des bibliothèques standard sont fournies pour pouvoir accéder à certains éléments de la machine hôte (le graphisme, le multithreading, la programmation réseau…) exactement de la même manière sur toutes les architectures. Notons que même s’il y a explicitement une première phase précoce de compilation, le bytecode Java est interprété ou alors converti à la volée en code natif par un compilateur juste-à-temps (just in time, JIT).

Il existe également des compilateurs Java qui compilent directement le Java en code objet natif pour la machine cible, comme par exemple GCJ, supprimant la phase intermédiaire du bytecode mais le code final produit par ces compilateurs ne peut alors être exécuté que sur une seule architecture.

La licence de Sun pour Java insiste sur le fait que toutes les implémentations doivent être compatibles. Ceci a abouti à la plainte en Justice contre Microsoft après que Sun a constaté que l’implémentation de Microsoft ne supportait pas les interfaces RMI et JNI et comportait des éléments spécifiques à certaines plates-formes par rapport à la plate-forme initiale de Sun. Sun obtint des dommages et intérêt (20 millions de dollars) et l’acte de justice renforça encore les termes de la licence de Sun. En réponse, Microsoft arrêta le support de Java sur ses plates-formes et, sur les versions récentes de Windows, Internet Explorer ne supporte pas les applets Java sans ajouter de plug-in. Cependant, Sun met à disposition gratuitement des environnements d’exécution de Java pour les différentes plates-formes Microsoft.

Les premières implémentations du langage utilisaient une machine virtuelle interprétée pour obtenir la portabilité. Ces implémentations produisaient des programmes qui s’exécutaient plus lentement que ceux écrits en C ou en C++, si bien que le langage souffrit d’une réputation de faibles performances. Des implémentations plus récentes de la machine virtuelle Java (JVM) produisent des programmes beaucoup plus rapides qu’auparavant, en utilisant différentes techniques.

La première technique est de compiler directement en code natif comme un compilateur traditionnel, supprimant complètement la phase de bytecode. On obtient ainsi de bonnes performances mais aux dépens de la portabilité. Une autre technique appelée compilation juste-à-temps (just in time, JIT) traduit le byte code en code natif durant la phase de lancement du programme. Certaines machines virtuelles plus sophistiquées utilisent une recompilation dynamique durant laquelle la machine virtuelle analyse le comportement du programme et en recompile sélectivement certaines parties. La recompilation dynamique permet d’obtenir de meilleurs résultats que la compilation statique car les compilateurs dynamiques peuvent optimiser en fonction de leur connaissance de l’environnement cible et des classes qui sont utilisées. La compilation JIT et la recompilation dynamique permettent à Java de tirer profit de la rapidité du code natif sans perdre la portabilité.

La portabilité est techniquement un objectif difficile à atteindre et le succès de Java en ce domaine est mitigé. Quoiqu’il soit effectivement possible d’écrire des programmes pour la plate-forme Java qui fonctionnent correctement sur beaucoup de machines cibles, le nombre important de plates-formes avec de petites erreurs et des incohérences a abouti à un détournement du slogan de Sun « Write once, run anywhere » (« Écrire une fois, exécuter partout ») en « Write once, debug everywhere » (« Écrire une fois, déboguer partout ») !

L’indépendance de Java vis-à-vis de la plate-forme est cependant un succès avec les applications côté serveur comme les services web, les servlets et le Java Beans aussi bien que les systèmes embarqués sur OSGi, utilisant l’environnement Embedded Java.

Un argument possible à l’encontre de langages comme le C++ est la lourde tâche d’avoir à programmer manuellement la gestion de la mémoire. En C++, la mémoire est allouée directement par le programmeur pour créer un objet et est désallouée lors de la destruction de celui-ci. Si le programmeur oublie de désallouer la mémoire, ceci peut aboutir à un manque de mémoire, et le programme consomme petit à petit de la mémoire sans nettoyer derrière lui. Pire encore, si une zone mémoire est désallouée deux fois, le programme peut devenir instable et aboutir à un plantage.

En java, ce problème est évité grâce au ramasse-miettes (en anglais Garbage collector). Les objets qui sont créés sont placés dans un tas. Le programme et les autres objets peuvent accéder à l’objet grâce à sa référence dans le tas. Quand il ne reste plus aucune référence vers l’objet, le ramasse-miettes détruit automatiquement l’objet devenu inaccessible, libérant la mémoire et prévenant ainsi un manque de mémoire. Les manques de mémoire peuvent néanmoins survenir quand un programme garde une référence vers un objet dont il n’a plus besoin ; ils continuent à exister, mais uniquement à un niveau concept beaucoup plus élevé. Mais dans l’ensemble, le ramasse-miettes rend la création et la destruction d’objets en Java plus simple, potentiellement plus sûre et souvent plus rapide qu’en C++.

Une grande faiblesse de ce système étant que si deux objets se référencent entre eux sans que le programme les utilise, le ramasse-miettes ne remarque pas que ces objets ne sont plus liés à la fonction principale du programme et ne seront plus utilisés. C'est donc une fuite de mémoire.

Le ramasse-miettes est transparent pour le développeur et est appelé régulièrement et automatiquement. Cependant, le programmeur peut au besoin suggérer à la machine virtuelle de lancer le ramasse-miettes à l’aide de la méthode System.gc().

Le système Java est basé sur le langage Java, la machine virtuelle Java et l’API Java (ces deux derniers composants forment l’environnement d’exécution, ou JRE, pour Java Runtime Environment).

Java est habituellement compilé vers une machine virtuelle standardisée, sous forme de bytecode. Cette machine peut fonctionner avec un interpréteur, un compilateur just-in-time (à la volée), ou, le plus couramment, avec un mélange des deux.

La première caractéristique, l’orienté objet, se réfère à une méthode moderne de programmation et de conception de langage. Sa principale caractéristique est de rassembler (encapsuler) en une seule entité logique (Classe) un ensemble de données (Propriétés) et les fonctions qui les traitent (Méthodes). Le code devient ainsi plus facilement réutilisable, car il est intrinsèquement modulaire.

D’autres mécanismes tels l’héritage permettent d’exploiter toutes les caractéristiques d’une Classe précédemment écrite (la plupart du temps par quelqu’un d’autre) dans ses propres programmes sans même avoir à en connaître le fonctionnement interne, on n’en voit que l’interface (les principales commandes).

Ce paradigme de programmation vise à rendre les grands projets logiciels plus faciles à gérer, à améliorer la qualité des logiciels et à réduire le nombre d’échecs de projet.

Dans la version 1.5 du langage ont été rajoutés les génériques, un mécanisme de polymorphisme semblable (mais différent) aux templates du langage C++ ou aux foncteurs d’Objective Caml. Les génériques permettent d’exprimer d’une façon plus simple et plus sûre les propriétés d’objets comme des conteneurs (listes, arbres…) : le type liste est alors considéré génériquement par rapport au type d’objet contenu dans la liste.

La plate-forme Java fut l’un des premiers systèmes à offrir le support de l’exécution du code à partir de sources distantes. Une applet peut fonctionner dans le navigateur web d’un utilisateur, exécutant du code téléchargé d’un serveur HTTP. Le code d’une applet fonctionne dans un espace très restrictif, ce qui protège l’utilisateur des codes erronés ou mal intentionnés. Cet espace est délimité par un objet appelé gestionnaire de sécurité. Un tel objet existe aussi pour du code local, mais il est alors par défaut inactif.

Les éditeurs d’applet peuvent demander un certificat pour leur permettre de signer numériquement une applet comme sûre, leur donnant ainsi potentiellement (moyennant l’autorisation adéquate) la permission de sortir de l’espace restrictif et d’accéder aux ressources du système local.

Remarque : vous pouvez également utiliser la structure de contrôle switch sur une énumération; par ailleurs le switch ne fonctionne pas sur toutes les constantes de type numérique mais seulement sur les entiers.

La commande break sort immédiatement la boucle en cours (for, while, do), et permet de sortir d’une clause contenue dans un switch.

L’énoncé return termine une méthode.

Avec return uneValeur, uneValeur sera renvoyée à la méthode appelante.

Le bloc de code "finally" sera exécuté quel que soit le résultat lorsque le programme sortira du bloc "try-catch".

Cet exemple permet d’illustrer le mécanisme des exceptions en Java. Dans le cas d’une erreur d’entrée/sortie dans le bloc "try", l’exécution reprend dans le bloc "catch" correspondant à cette situation (exception de type "IOException"). Dans ce bloc "catch", la variable "e" référence l’exception qui s’est produite. Ici, nous invoquons la méthode "printStackTrace()" qui affiche dans la console des informations sur l’exception qui s’est produite : nom, motif, état de la pile d’appels au moment de la levée de l’exception et, éventuellement, numéro de ligne auquel l’erreur s’est produite. Le bloc finally est ensuite exécuté (ici pour refermer les resources utilisées). Il ne s’agit ici que d’un exemple, l’action à mettre en œuvre lorsqu’une exception survient dépend du fonctionnement général de l’application et de la nature de l’exception.

Pour assurer la portabilité entre plates-formes, les noms de classes devraient néanmoins être formés uniquement de caractères ASCII.

Les JavaStyle sont des conventions de programmation en langage Java définies par Sun. Le respect de conventions strictes assure une homogénéité dans le code source d’une application développée par toute une équipe et favorise la diffusion du code source auprès d’une communauté partageant les mêmes conventions de codage.

Le langage est stable depuis le JDK 1.0 ; les bibliothèques de classes fournies se sont agrandies et ont changé en partie. À partir de la version 1.2, les JDK ont été renommés en J2SDK (Java 2 Software Development Kit, kit de développement de logiciels Java 2) et on appelle souvent ces versions Java 2.

Du fait de l’accroissement des bibliothèques et des changements entre version, la compatibilité est assurée dans un seul sens : les programmes Java compilés avec une version antérieure du JDK (par exemple 1.2) continueront à fonctionner avec un JRE plus récent (par exemple 1.5), mais le contraire n’est pas vrai.

Le 13 novembre 2006, Sun Microsystems annonce que tout le code source de Java sera publié en Open Source sous la Licence publique générale GNU d’ici mars 2007 sous le nom de projet OpenJDK.

Il existe plusieurs versions interprétées de Java (langages de scripts s’exécutant sur une JVM) : beanshell et Groovy font l’objet de standardisations au sein du JCP (Java Community Process). Jython, JRuby, Jacl (Tcl) et d’autres langages de scripts proposent des langages sur ce même principe. L’interpréteur de ces langages peut être embarqué dans une application Java pour la rendre scriptable. À noter qu’à partir de Java 6, le moteur Rhino (JavaScript) est embarqué dans la JRE.

Dans un premier temps, le langage s’appelait Oak (« Chêne »), mais ce nom étant déjà utilisé, il est renommé Java.

La programmation peut se faire pour des exemples simples avec le compilateur javac, mais pour avoir plus de confort il est préférable d’utiliser un environnement de développement intégré ou IDE, certains sont gratuits.

En haut



Framework

En informatique, un framework est un ensemble de bibliothèques, d'outils et de conventions permettant le développement d'applications. Il fournit suffisamment de briques logicielles et impose suffisamment de rigueur pour pouvoir produire une application aboutie et dont la maintenance est aisée. Ces composants sont organisés pour être utilisés en interaction les uns avec les autres (voir urbanisation).

Des tentatives de francisation du terme ont été faites. On trouve ainsi parfois les termes cadre d'applications, proposé par l'Office québécois de la langue française ou cadriciel.

Un framework fournit un ensemble de fonctions facilitant la création de tout ou d'une partie d'un système logiciel, ainsi qu'un guide architectural en divisant le domaine visé en modules. Un framework est habituellement implémenté à l'aide d'un langage à objets, bien que cela ne soit pas strictement nécessaire : un framework objet fournit ainsi un guide architectural en divisant le domaine visé en classes et en définissant les responsabilités de chacune ainsi que les collaborations entre classes. Ces classes peuvent être subdivisées en classes abstraites.

Le déploiement à grande échelle de bibliothèques d'objets exige un framework ; celui-ci fournit un contexte où les composants sont ré-utilisés.

Si l'utilisation du terme bibliothèque est limitée à l'ensemble des fonctions du système, le terme de framework peut être employé par extension pour inclure également l'architecture logicielle préconisée pour cette bibliothèque (organisation en couches, utilisation du modèle MVC, etc), voire l'environnement de développement bâti autour (Microsoft .NET + Visual Studio, etc) même si celui-ci est capable de gérer différents frameworks.

Les principaux avantages de ces frameworks sont la réutilisation de leur code, la standardisation du cycle de vie du logiciel (Spécification, développement, maintenance, évolution), ils permettent de formaliser une architecture adaptée au besoin de l'entreprise. Ils tirent parti de l'expérience des développements antérieurs.

Ces frameworks sont en quelque sorte des progiciels extrêmement souples et évolutifs.

En haut



Source : Wikipedia