Analyse logicielle

L’objectif principale de l’analyse logicielle est de maitriser la complexité. La modélisation est une abstraction de la réalité pour mieux comprendre le système à réaliser/ réalisé. Pour vérifier ou fabriquer un modèle, ce dernier doit être relié au monde réel, savoir ce qui existe avant les travaux, le réalisé et le restant à réaliser. Un modèle peut être exprimé avec différents niveaux d’abstraction/raffinement, une seule vue du système n’est pas suffisante pour comprendre tout son fonctionnement et les interactions intrinsèques.

La modélisation s’appuie sur des graphiques des systèmes informatiques. Les graphiques les plus utilisés font parti de l’Unified Modeling Langage (UML). Ce dernier comporte un ensemble d’outils et de règles permettant de définir des diagrammes.

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 informatique produira les différents diagrammes en fonction d’un modèle de conception et réutilisera des patrons de conception éprouvés.

4+1 vues de Kruchten

Dans l’analyse logicielle, le modèle « 4+1 » vues, dit de Kruchten, d’un système informatique permet d’organiser la description du système en plusieurs vues complémentaires, chacune présentant le système selon un point de vue différent. L’utilisation de vues permet de traiter séparément les intérêts des divers groupes d’intervenants et ainsi de mieux séparer les préoccupations fonctionnelles et les préoccupations extrafonctionnelles.

La figure schématise le modèle « 4+1 » vues. Ce modèle est composé de cinq vues.

• La vue « logique » décrit les aspects statiques et dynamiques d’un système en termes de classes, d’objets, de connexions et de communications. Elle se concentre sur l’abstraction et l’encapsulation.
• La vue « processus » capte les aspects de concurrence et de synchronisation, et les décompose en flux d’exécution (processus, fil d’exécution, etc.). Elle se rapporte aux objets actifs et aux interactions.
• La vue « développement » représente l’organisation statique des modules (exécutable, codes source, paquetages, etc.) dans l’environnement de développement.
• La vue « physique » décrit les différentes ressources matérielles et l’implantation logicielle tenant compte de ces ressources. Donc, elle se rapporte aux nœuds physiques d’exécution et au placement des objets sur les nœuds.
• La dernière vue, appelée « cas d’utilisation », se concentre sur la cohérence en présentant des scénarios d’utilisation qui mettent en œuvre les éléments des quatre premières vues. Les scénarios sont une abstraction des exigences fonctionnelles de l’application. Cette dernière vue valide en quelque sorte les autres vues et assure la cohérence globale. C’est aussi cette dernière vue qui est construite en premier, juste après l’établissement du cahier des charges, pour fixer les contours du système à réaliser avec ses fonctionnalités appelées, dans la terminologie UML, des cas d’utilisation.