Cycle de vie des logiciels:* l’analyse du besoin.
* l’élaboration des spécifications.
* la conceptualisation.
* le développement.
* la phase de test.
* la maintenance.
Notion de qualité pour un logiciel:En génie logiciel, divers travaux ont mené à la définition de la qualité du logiciel en termes de facteurs, qui dépendent, entre autres, du domaine de l’application et des outils utilisés. Parmi ces derniers nous pouvons citer :
- Validité :
- aptitude d’un produit logiciel à remplir exactement ses fonctions, définies par le cahier des charges et les spécifications.
- Fiabilité ou robustesse :
- aptitude d’un produit logiciel à fonctionner dans des conditions anormales.
- Extensibilité (maintenance) :
- facilité avec laquelle un logiciel se prête à sa maintenance, c’est-à-dire à une modification ou à une extension des fonctions qui lui sont demandées.
- Réutilisabilité :
- aptitude d’un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applications.
- Efficacité :
- Utilisation optimales des ressources matérielles.
- Portabilité :
- facilité avec laquelle un logiciel peut être transféré sous différents environnements matériels et logiciels.
- Vérifiabilité :
- facilité de préparation des procédures de test.
- Intégrité :
- aptitude d’un logiciel à protéger son code et ses données contre des accès non autorisés.
- Facilité d’emploi :
- facilité d’apprentissage, d’utilisation, de préparation des données, d’interprétation des erreurs et de rattrapage en cas d’erreur d’utilisation.
Qu’est-ce qu’un modèle ?
Un modèle est une représentation abstraite et simplifiée (i.e. qui exclut certains détails), d’une entité (phénomène, processus, système, etc.) du monde réel en vue de le décrire, de l’expliquer ou de le prévoir. Modèle est synonyme de théorie, mais avec une connotation pratique : un modèle, c’est une théorie orientée vers l’action qu’elle doit servir.
Pourquoi modéliser ?
Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du système. C’est également un bon moyen de maîtriser sa complexité et d’assurer sa cohérence. Un modèle est un langage commun, précis, qui est connu par tous les membres de l’équipe et il est donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est essentielle pour aboutir à une compréhension commune aux différentes parties prenantes (notamment entre la maîtrise d’ouvrage et la maîtrise d’œuvre informatique) et précise d’un problème donné.
Dans le domaine de l’ingénierie du logiciel, le modèle permet de mieux répartir les tâches et d’automatiser certaines d’entre elles. C’est également un facteur de réduction des coûts et des délais. Par exemple, les plateformes de modélisation savent maintenant exploiter les modèles pour faire de la génération de code (au moins au niveau du squelette) voire des aller-retours entre le code et le modèle sans perte d’information. Le modèle est enfin indispensable pour assurer un bon niveau de qualité et une maintenance efficace. En effet, une fois mise en production, l’application va devoir être maintenue, probablement par une autre équipe et, qui plus est, pas nécessairement de la même société que celle ayant créée l’application.
Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les systèmes non-triviaux sont mieux modélisés par un ensemble de modèles indépendants. Selon les modèles employés, la démarche de modélisation n’est pas la même.
De la programmation structurée à l’approche orientée objet
Méthodes fonctionnelles ou structurées:
Les méthodes fonctionnelles (également qualifiées de méthodes structurées) trouvent leur origine dans les langages procéduraux. Elles mettent en évidence les fonctions à assurer et proposent une approche hiérarchique descendante et modulaire.
Ces méthodes utilisent intensivement les raffinements successifs pour produire des spécifications dont l’essentielle est sous forme de notation graphique en diagrammes de flots de données. Le plus haut niveau représente l’ensemble du problème (sous forme d’activité, de données ou de processus, selon la méthode). Chaque niveau est ensuite décomposé en respectant les entrées/sorties du niveau supérieur. La décomposition se poursuit jusqu’à arriver à des composants maîtrisables (cf. figure 1.3).
L’approche fonctionnelle dissocie le problème de la représentation des données, du problème du traitement de ces données
. Sur la figure 1.3, les données du problème sont représentées sur la gauche. Des flèches transversalles matérialisent la manipulation de ces données par des sous-fonctions. Cet accès peut-être direct (c’est parfois le cas quand les données sont regroupées dans une base de données), ou peut être réalisé par le passage de paramètre depuis le programme principal.
La SADT (Structured Analysis Design Technique) est probablement la méthode d’analyse fonctionnelle et de gestion de projets la plus connue. Elle permet non seulement de décrire les tâches du projet et leurs interactions, mais aussi de décrire le système que le projet vise à étudier, créer ou modifier, en mettant notamment en évidence les parties qui constituent le système, la finalité et le fonctionnement de chacune, ainsi que les interfaces entre ces diverses parties. Le système ainsi modélisé n’est pas une simple collection d’éléments indépendants, mais une organisation structurée de ceux-ci dans une finalité précise.
En résumé, l’architecture du système est dictée par la réponse au problème (i.e. la fonction du système).
L’approche orientée objet:
L’approche orientée objet considère le logiciel comme une collection d’objets dissociés, identifiés et possédant des caractéristiques. Une caractéristique est soit un attribut (i.e. une donnée caractérisant l’état de l’objet), soit une entité comportementale de l’objet (i.e. une fonction). La fonctionnalité du logiciel émerge alors de l’interaction entre les différents objets qui le constituent. L’une des particularités de cette approche est qu’elle rapproche les données et leurs traitements associés au sein d’un unique objet.
Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :
- L’identité –
- L’objet possède une identité, qui permet de le distinguer des autres objets, indépendamment de son état. On construit généralement cette identité grâce à un identifiant découlant naturellement du problème (par exemple un produit pourra être repéré par un code, une voiture par un numéro de série, etc.)
- Les attributs –
- Il s’agit des données caractérisant l’objet. Ce sont des variables stockant des informations sur l’état de l’objet.
- Les méthodes –
- Les méthodes d’un objet caractérisent son comportement, c’est-à-dire l’ensemble des actions (appelées opérations) que l’objet est à même de réaliser. Ces opérations permettent de faire réagir l’objet aux sollicitations extérieures (ou d’agir sur les autres objets). De plus, les opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre des valeurs des attributs, ou bien les modifier.
La difficulté de cette modélisation consiste à créer une représentation abstraite, sous forme d’objets, d’entités ayant une existence matérielle (chien, voitu
re, ampoule, personne, …) ou bien virtuelle (client, temps, …).
La Conception Orientée Objet (COO) est la méthode qui conduit à des architectures logicielles fondées sur les objets du système, plutôt que sur la fonction qu’il est censé réaliser.
En résumé, l’architecture du système est dictée par la structure du problème.
Concepts importants de l’approche objet:
Notion de classe
Tout d’abord, introduisons la notion de classe. Une classe est un type de données abstrait qui précise des caractéristiques (attributs et méthodes) communes à toute une famille d’objets et qui permet de créer (instancier) des objets possédant ces caractéristiques. Les autres concepts importants qu’il nous faut maintenant introduire sont l’encapsulation, l’héritage et l’agrégation.
Encapsulation
L’encapsulation consiste à masquer les détails d’implémentation d’un objet, en définissant une interface. L’interface est la vue externe d’un objet, elle définit les services accessibles (offerts) aux utilisateurs de l’objet.
L’encapsulation facilite l’évolution d’une application car elle stabilise l’utilisation des objets : on peut modifier l’implémentation des attributs d’un objet sans modifier son interface, et donc la façon dont l’objet est utilisé.
L’encapsulation garantit l’intégrité des données, car elle permet d’interdire, ou de restreindre, l’accès direct aux attributs des objets.
Héritage, Spécialisation, Généralisation et Polymorphisme
L’héritage est un mécanisme de transmission des caractéristiques d’une classe (ses attributs et méthodes) vers une sous-classe. Une classe peut être spécialisée en d’autres classes, afin d’y ajouter des caractéristiques spécifiques ou d’en adapter certaines. Plusieurs classes peuvent être généralisées en une classe qui les factorise, afin de regrouper les caractéristiques communes d’un ensemble de classes.
Ainsi, la spécialisation et la généralisation permettent de construire des hiérarchi
es de classes. L’héritage peut être simple ou multiple. L’héritage évite la duplication et encourage la réutilisation.
Le polymorphisme représente la faculté d’une méthode à pouvoir s’appliquer à des objets de classes différentes. Le polymorphisme augmente la généricité, et donc la qualité, du code.
Agrégation
Il s’agit d’une relation entre deux classes, spécifiant que les objets d’une classe sont des composants de l’autre classe. Une relation d’agrégation permet donc de définir des objets composés d’autres objets. L’agrégation permet donc d’assembler des objets de base, afin de construire des objets plus complexes.
UML en œuvre
UML 2.0 comporte treize types de diagrammes représentant autant de
vues distinctes pour représenter des concepts particuliers du système d’information. Ils se répartissent en deux grands groupes :
- Diagrammes structurels ou diagrammes statiques (UML Structure):
- * diagramme de classes (Class diagram)
- * diagramme d’objets (Object diagram)
- * diagramme de composants (Component diagram)
- * diagramme de déploiement (Deployment diagram)
- * diagramme de paquetages (Package diagram)
- * diagramme de structures composites (Composite structure
- diagram)
- Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior)
- * diagramme de cas d’utilisation (Use case diagram)
- * diagramme d’activités (Activity diagram)
- * diagramme d’états-transitions (State machine diagram)
- * Diagrammes d’interaction (Interaction diagram)
- diagramme de séquence (Sequence diagram)
- diagramme de communication (Communication diagram)
- diagramme global d’interaction (Interaction overview diagram)
- diagramme de temps (Timing diagram)
Diagramme de cas d
’utilisation
Éléments des diagrammes de cas d’utilisation
Acteur:
Un acteur est l’idéalisation d’un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système. Il se représente par un petit bonhomme avec son nom (i.e. son rôle) inscrit dessous.
