Synthèse des différents modèles résultant de la phase de conception par points de vue

En suivant la même démarche que celle utilisée ci-dessus pour le point de vue Client, nous avons élaboré les modèles structurels et comportementaux des autres points de vue. Les trois sous-sections suivantes donnent une synthèse des résultats du développement des modèles structurels et comportementaux des points de vue ChefAgence et du ResponsableAtelier.

V.3.3.4.1. Point de vue ChefAgence

Diagramme de classes du point de vue ChefAgence

Dans le diagramme de classes associé au point de vue ChefAgence (cf. Figure V.9), nous remarquons que les fragments liés à la supervision de l'agence et à la gestion financière sont beaucoup plus développés par rapport au point de vue Client. En effet, ces fragments expriment des fonctionnalités représentant des préoccupations importantes pour le chef d'agence. Néanmoins nous avons réduit le modèle aux éléments pertinents en liaison avec la tâche de gestion des voitures notamment les classes Voiture, AgenceReparation et DossierFinancier.

- 144 -

Nous avons représenté les besoins et les fonctions (en liaison avec la gestion des voitures) du chef d'agence au niveau de son diagramme de classes de la façon suivante :

- les ordres d'acheminement de la voiture en panne vers le garage, l'ordre d'expertise, l'ordre de réparation, l'ordre de test et l'ordre de livraison sont représentés dans la classe Voiture par les attributs suivants : permissionAchemin, permissionExp, permissionRep, permissionTest et permissionSortir ;

- la gestion financière est assurée par la classe DossierFinancier et ses trois sous-classes. La classe ContratFournisseur présente les contrats avec les fournisseurs de l'agence, lors que la classe DepenseInterne représente les dépenses nécessaires au fonctionnement de l'agence. La gestion des contrats de réparation avec les clients est représentée par la classe ContratReparationClient et également à travers l'attribut contrat_etabli de la classe Voiture. On associe à chaque type de DossiersFinancier un ensemble de factures à travers la classe Facture ;

- on organise le test de validation du client à travers les attributs suivants de la classe Voiture : rdv_test et test_valide.

La classe OperationMaintenance ainsi que ses sous-classes OperationExpertise, OperationReparation et OperationTest sont également importantes pour le point de vue ChefAgence dans la mesure où elles donnent une vision sur les opérations effectuées sur la voiture, celles qui sont en cours et celles qui sont planifiées ; elles permettent également d'estimer le coût des opérations à travers l'opération estimerCoutOperation de la classe OperationMaintenance.

- 145 -

- 146 -

Machine-vue de la classe Voiture pour le point de vue ChefAgence

La machine à états représentée dans la Figure V.10 exprime le comportement des objets de type Voiture selon la vision du chef d'agence. Au cours du développement de cette dernière, plusieurs moyens de spécification de comportement ont été utilisés.

Communication par utilisation d'attributs. Le fait de rendre certains attributs publics dans

une classe permet aux objets du système d'accéder directement à ces attributs. Nous avons utilisé ce mode de communication au sein de la machine à états de la classe Voiture à plusieurs reprises comme par exemple les attributs booléens permissionAchemin et permissionSortir. Ces deux attributs expriment, respectivement, que le chef d'agence a donné sa permission pour l'acheminement de la voiture en panne, et pour la livraison de la voiture à son propriétaire.

- 147 -

Communication par échange de signaux. Nous avons utilisé également ce mode de

communication basé sur l'échange de signaux. Par exemple, c'est le cas du signal voitureEnregistree envoyé par la classe AgenceReparation suite à l'enregistrement de la voiture et utilisé par la machine à états pour démarrer le processus d'acheminement de la voiture en panne. La Figure V.9 donne l'ensemble des signaux utilisés dans le modèle comportemental du point de vue ChefAgence ; nous avons regroupé ces signaux dans le paquetage Signal_Package_ChefAgence_Viewpoint.

Communication par utilisation de sondes d'événement. Nous avons déclaré un ensemble

de sondes abstraites dans les cas où le comportement n'a pas pu être spécifié. Nous donnons deux exemples de sondes utilisées dans la machine à états développée :

- la transition depuis l'état "Acheminement" vers l'état "Reception_garage" est déclenchée par l'événement de l'arrivée de la voiture au garage après son acheminement. Cependant, cette activité ne rentre pas dans les responsabilités du chef de l'agence et aucune information permettant d'identifier cet événement n'est disponible dans les modèles associés au chef de l'agence. Par conséquent, pour pouvoir continuer la spécification comportementale et pallier ce manque d'information, nous avons déclaré la sonde reception_voiture_probe.

- La sonde fin_test_probe est déclarée pour informer le chef d'agence du moment de la réalisation du test de validation des réparations effectuées sur la voiture.

Le référencement de ces sondes par la classe Voiture est montré dans la Figure V.9 par le stéréotype « probeUse ». Les sondes utilisées dans le modèle comportemental du chef d'agence sont regroupées dans le paquetage Probe_Package_ChefAgence_Viewpoint.

V.3.3.4.2. Point de vue ResponsableAtelier

Diagramme de classes du point de vue ResponsableAtelier

Le diagramme de classes associé au point de vue ResponsableAtelier est représenté par la Figure V.11. Le responsable d'atelier s'intéresse aux fonctionnalités liées à la gestion du matériel, du personnel de l'agence et le suivi du travail des mainteniciens. Dans ce diagramme, nous faisons également les simplifications faites au niveau des autres points de vue, et nous ne présentons que les classes pertinentes en liaison avec la tâche de gestion des voitures. Les classes clés de ce diagramme sont : Voiture, AgenceReparation, OperationMaintenance, Personnel et RessourceAgence.

La tâche de gestion du matériel est représentée par la classe RessourceAgence et également par ses classes dérivées telles que Parking, Atelier, Outil et PieceRechange. Ces classes sont munies des opérations affecter() et liberer() et de l'attribut booléen disponibilité qui permettent de gérer la réservation des différentes ressources pour l'utilisation dans les opérations de maintenance.

La gestion du personnel est assurée par la classe Personnel. Le responsable d'atelier a la tâche d'assurer l'affectation des mainteniciens (mécanicien ou électricien) aux voitures en cours d'une opération de maintenance. Il a également la tâche de suivi du travail de ces mainteniciens en leur donnant les ordres concernant le début de l'opération de maintenance, la rédaction des rapports de ces opérations, la gestion du stock de pièces de rechange, etc.

- 148 -

- 149 -

Machine-vue de l'objet Voiture pour le point de vue ResponsableAtelier

Nous représentons dans la machine à états de la Figure V.12 les états/transitions essentiels à la réalisation du comportement des objets de type Voiture selon la vision d'un responsable d'atelier. Cette vision a un objectif principal qui est la préparation du contexte nécessaire aux éventuelles opérations de maintenance à effectuer sur la voiture.

Figure V.12. Machine à états de la classe Voiture pour le point de vue ResponsableAtelier

Le cycle de vie commence par l'attente de la permission d'acheminement de la voiture vers le garage ; cela est réalisé par la déclaration de la sonde permission_achemin_probe qui va permettre de mettre à jour l'attribut booléen permission_achemin. Si la réponse est favorable, la voiture entre dans l'état Procedure_acheminement. Après sa réception dans le garage et après réservation d'une place dans l'atelier pour effectuer l'expertise, on attend la permission du chef d'agence, information qui va être observée par la sonde permission_expertise_probe. Suite à cette décision, le responsable d'atelier effectue

- 150 -

les réservations nécessaires au bon déroulement de l'opération d'expertise telles que la réservation des mainteniciens et des outils adéquats, et donne ensuite les ordres à ces mainteniciens de commencer leur travail. Une fois l'expertise réalisée, le responsable d'atelier participe à l'édition du rapport de l'opération et la voiture entre dans un état Attente_ordre_reparation. Nous avons déclaré la sonde permission_rep_probe pour observer l'événement traduisant cette permission. Après la réponse favorable de réparation, on effectue à nouveau les réservations nécessaires. Quand la réparation est faite, le cycle de vie se termine par le test de vérification des réparations effectuées pour attendre la permission de livraison de la voiture à son propriétaire à travers la sonde permission_sortir_probe.

La Figure V.11 donne un aperçu des signaux utilisés dans le modèle comportemental du point de vue ResponsableAtelier, regroupés dans le paquetage Signal_Package_ChefAgence_Viewpoint. Le référencement des sondes utilisées par la classe Voiture est montré dans la Figure V.11 par le stéréotype « probeUse ». L'ensemble des sondes utilisées dans le modèle comportemental du point de vue ResponsableAtelier sont regroupées dans le paquetage Probe_Package_ChefAgence_Viewpoint.