Qu’est-ce que l’Architecture ?
- En informatique, l’Architecture est la nature et la structure d’un système qui détermine la façon dont il fonctionne.
Ce que l’Architecture n’est pas :
- L’Architecture n’est pas un Framework : Bien qu’une architecture puisse prendre en compte l’utilisation d’un framework, la définition d’un framework n’est pas suffisante ! Un framework n’est qu’un composant.
L’Architecture Technique (ou Modèle d’Architecture) est la nature du système. Par exemple, elle pourrait être :
- Monolithique
- Client Serveur
- Distribuée
- N-tier
Les paradigmes peuvent être intégrés, tels que :
- Modèle-Vue-Contrôleur
- Composants Logiciels
- Modèles de conception
Un framework peut être défini, dans le cadre de l’architecture technique.
L’architecture métier définit la structure du système. Elle devrait décrire les différentes parties du système, leur rôle et leurs relations.
Que Signifie l’Architecture de Composants pour RUP ?
- Les composants sont des groupes cohésifs de code, sous forme source ou exécutable, avec des interfaces et comportements bien définis qui fournissent une encapsulation forte de leur contenu, et sont donc remplaçables.
- Les architectures basées autour de composants tendent à réduire la taille effective et la complexité de la solution, et sont donc plus robustes et résilientes.
- Dans les exemples ci-dessous, il y a le même nombre d’objets, mais un niveau différent de complexité :
Définition d’un Composant Logiciel
Un Composant Logiciel est une portion indépendante de code qui est accédée à travers une interface définie.
Les Composants Logiciels peuvent être juste imaginaires, et peuvent toujours être définis quelle que soit la technologie utilisée !
Les Composants Logiciels peuvent aussi être des entités physiques, telles qu’une bibliothèque (par exemple DLL) ou un composant distribué (par exemple EJB, CORBA, DCOM, Services Web, etc.)… mais pas nécessairement… et ce n’est pas parce que les EJB sont utilisés que c’est une Architecture de Composants Logiciels bien pensée.
Les Composants Logiciels physiques peuvent être réutilisés, achetés et/ou remplacés.
Les composants métier sont ceux qui implémentent la fonctionnalité spécifique à un métier. Un « Moteur de Calcul », qui fournit des services de calcul spécifiques, est un exemple de composant métier. Les composants métier sont plus difficiles à réutiliser que les composants techniques, en raison de leur nature spécifique.
Les composants techniques sont ceux qui implémentent une fonctionnalité générique. Un exemple de composant technique est « Impression de Document ». Les composants techniques peuvent être conçus afin d’être réutilisés. Ils peuvent faire partie d’un framework technique.
Pourquoi utiliser des Composants Logiciels ?
Ils parviennent généralement à réduire la complexité d’un logiciel, en identifiant des interfaces bien définies et des portions indépendantes de code.
Alors qu’il est plutôt inefficace de donner des Cas d’Utilisation à développer aux Programmeurs directement, il est beaucoup plus efficace de donner des composants à implémenter. ==> Envisageriez-vous d’externaliser le développement d’un cas d’utilisation ? Il est facile d’externaliser le développement d’un composant, ou d’en acheter un existant.
Cette approche facilite et améliore les estimations de charge de travail, la planification et l’affectation des tâches.
Réutiliser des composants est un moyen efficace car ils sont déjà développés et testés.
Les composants peuvent être développés afin d’être réutilisables, spécialement les composants qui fournissent des solutions communes à un large éventail de problèmes communs. Ces composants réutilisables, qui peuvent être plus importants que de simples collections d’utilitaires ou de bibliothèques de classes, forment la base de la réutilisation au sein d’une organisation, augmentant la productivité et la qualité globales du logiciel. Avant de promouvoir une réutilisabilité effrénée cependant, assurez-vous qu’une grande expérience et connaissance a été acquise dans le domaine des composants logiciels.
Parce qu’ils sont bien définis, les Composants peuvent être refactorisés avec moins de douleur que dans une Architecture pas-si-bien structurée/organisée. L’interface du composant peut être en grande partie inchangée, tandis que l’implémentation est entièrement revue. Même si l’interface est changée, trouver le code impacté sera plus facile que de trouver ce qui utilise les multiples classes et méthodes qui composent le composant.
Au début du Développement Logiciel, la documentation et l’intégration système étaient généralement mal entreprises, l’Architecte était souvent demandé pour contribuer à l’effort de développement, et le Client devait effectuer la plupart des tests.
RUP recommande d’implémenter les « Packages de Cas d’Utilisation » comme composants pour les exigences, afin de rassembler les exigences par type de fonctionnalité. En effet cette approche facilitera l’analyse et la conception suivantes de l’application avec des composants logiciels.
Identifier les composants peut être effectué de cette façon :
Identifier différents modules, packages, sous-systèmes et couches, par exemple modules de Facturation et d’Abonnement.
Essayer de trouver des fonctionnalités communes, par exemple l’impression.
Diviser les modules, définir les interfaces et relations avec d’autres modules.
Itérer et aller plus profondément pour trouver autant de composants que possible. Utiliser l’approche descendante, de l’Interface Graphique vers les Données, et l’approche ascendante en même temps.
Puis appliquer des modèles tels que Modèle-Vue-Contrôleur.
La spécification des Composants fournira une brève description des composants et de leurs relations. Le résultat est généralement décrit avec des Diagrammes de Structure Composite ou de Composants et un texte d’accompagnement, fournissant une description de haut niveau pour chaque composant.
L’Analyse des Composants fournira une brève définition de chaque composant, et une définition détaillée de ses interfaces et relations. À ce stade, les Composants sont des boîtes noires. Le résultat est généralement obtenu et décrit avec des Diagrammes de Séquence et/ou des Diagrammes de Collaboration. Les Diagrammes de Classes peuvent être utilisés pour décrire les interfaces.
La Conception des Composants fournira la description détaillée de ce qui se trouve à l’intérieur de chaque composant/à l’intérieur de la boîte. Le résultat est généralement obtenu et décrit avec des Diagrammes de Séquence, des Diagrammes de Collaboration, des Diagrammes de Classes, des Diagrammes d’État, etc.
L’implémentation des composants peut maintenant facilement être effectuée par un Développeur ou une Équipe. L’équipe sera responsable de maintenir la conception du composant et de tester unitairement le composant. L’équipe pourrait être le fournisseur et/ou le client pour un autre composant/équipe.
Les composants peuvent être individuellement testés et graduellement intégrés pour former le système entier. Lors de l’exécution de tests unitaires d’un composant, des composants fictifs (donnant de fausses réponses) peuvent être utilisés pour former le banc d’essai du composant à tester.
Notez aussi que les Architectures Orientées Services (SOA) sont nécessairement basées sur les Architectures de Composants Logiciels. Les composants sont alors implémentés comme services (Services Web, CORBA, RMI, etc.), qui fournissent le bénéfice d’être faiblement couplés.