TD 1 : Consolidons les bases
Les phases d’analyse et de conception tels que nous les avons revues dans le TD précédent servent à produire des documents, des ressources qui seront utiles au programmeur pour mieux cernés les attentes du client et savoir vers quel type d’application se diriger.
En revanche pendant ces phases on peut aller plus loin que simplement définir les acteurs, leur(s) action(s) ou bien encore les classes correspondantes car on peut aussi réfléchir à l’architecture qu’on va adopter ou bien encore à la persistance de nos futures données.
Avec le TD 0 nous avons revu les grandes lignes des notions abordées l’année passée pendant le second semestre. Aussi nous avions déjà vu une grande partie de la conception avec les diagrammes de classes et de séquences (le diagramme de cas d’utilisation étant un diagramme d’analyse).
Pour ce premier TD nous vous proposons d’approfondir la notion de conception en allant plus loin que les digrammes vus.
Voyons donc quels éléments peuvent aussi être réalisés pendant la phase de conception ou bien quels éléments peuvent être rajoutés aux diagrammes déjà réalisés.
A noter que dans cette 1ère partie on approfondira simplement ce qui avait déjà été vu au semestre précédent tandis que dans la 2ème partie on abordera de nouvelles notions.
Les objectifs de ce TD :
- Approfondir vos connaissances
- Vous familiariser avec de nouveaux concepts/éléments
2.1. Les packages dans le diagramme de classes
Le diagramme de classes est le diagramme UML le plus proche du code puisqu’il modélise l’architecture de notre future application. Ainsi il est nécessaire d’organiser ses classes pour pouvoir mettre déjà en place l’architecture. Par conséquent il est préférable que chaque classe soit attribuée à un package.A noter qu’on peut faire des packages constitués uniquement d’autres packages.
2.2. L'architecture globale
Une application ne possède pas que des fonctionnalités mais aussi une interface graphique (le plus souvent) et aussi un moyen de sauvegarder les données, c’est la persistance.Ainsi, lors de la conception on peut déjà se demander quels vont être les écrans de l’application et aussi réfléchir à comment vont être sauvegardées les données de l’application (base de données, fichier par exemple).
On voit alors apparaitre une application qui possède une architecture dite en « couches », layer en anglais.
On a alors :
- La couche regroupant les fonctionnalités de l’application traduites les classes. C’est le layer Core
- La couche regroupant les interfaces graphiques (user interface (UI) en anglais). C’est le layer UI
- La couche regroupant les données sauvegardées ou du moins les éléments permettant leur sauvegarde. C’est le layer persist.
Néanmoins si l’on ne choisit pas forcement de réaliser cette architecture pour l’application globale il est important de la réaliser sur le diagramme de séquence comme nous allons le voir dans la partie suivante.
2.3. L’UI et le controller dans le diagramme de séquence
Le diagramme de séquence permet de représenter graphiquement des interactions entre les acteurs et le système selon un ordre chronologique dans le cadre d'un scénario.Comme on l’a vu, une application ne possède pas que des fonctionnalités mais aussi des écrans qui permettent à l’acteur d’interagir avec le système.
Aussi on va représenter l’ensemble de ces écrans par un nouvel objet avec lequel l’acteur va devoir interagir pour réaliser une action. C’est l’interface graphique que l’on représente comme suit :
Or, en règle générale, ce n’est pas l’interface graphique qui s’occupe d’appeler telle ou telle fonction dans l’application mais c’est un objet intermédiaire appelé controller qui va se charger de faire la traduction d’une action physique en fonctionnalité. Il est représenté comme suit :
Ces deux nouveaux éléments essentiels vont permettre de structurer d’ores et déjà l’application.
On aura donc des diagrammes de séquence de cette forme :
Remarque : Comme nous avons à présent une interface graphique à notre disposition inutile que les messages de retours arrivent jusqu’à l’acteur, ils s’arrêteront à l’interface graphique et implicitement l’acteur pourra voir le retour sur l’interface graphique.
Remarque 2 : La notion de contrôleur est complexe et fait référence à un « pattern » que nous aborderons plus en détail dans le TD suivant.