Introduction et démarche de modélisation

1. Pourquoi modéliser avant de développer ?

Une équipe peut écrire un programme qui fonctionne et livrer malgré tout une application inadaptée. Le problème vient parfois d’une question mal posée : qui utilisera le service ? Quel résultat attend cette personne ? Que se passe-t-il lorsque les données sont incomplètes ? La modélisation rend ces questions visibles avant qu’elles ne deviennent des corrections coûteuses.

Un modèle sélectionne les informations utiles pour répondre à une question. Le plan d’un bâtiment montre ses pièces sans représenter chaque câble ; de même, un diagramme de classes montre les concepts et leurs relations sans afficher chaque instruction du programme. Un bon modèle annonce donc son objectif, son périmètre et son niveau de détail.

UML signifie Unified Modeling Language, ou langage de modélisation unifié. Il fournit des notations pour représenter la structure et le comportement d’un système. Il sert à discuter une solution, à documenter des décisions et à préparer des vérifications. Le dessin reste un moyen : sa valeur dépend de la précision de ce qu’il explique.

2. Le projet fil rouge : NKILItech Services

Dans cette étude pédagogique, NKILItech est une entreprise de services numériques dirigée par M. Joel Stephane Yankam Ngueguim, PDG. L’équipe souhaite centraliser les demandes de ses clients : maintenance d’une application, création d’un site ou accompagnement technique. Les règles qui suivent sont des hypothèses de travail pour les exercices ; elles ne décrivent pas un fonctionnement réel vérifié de l’entreprise.

Le portail « NKILItech Services » doit permettre au client de soumettre une demande, au chargé d’affaires de préparer un devis et au responsable technique d’organiser l’intervention après acceptation. Le comptable suit la facturation. Le PDG consulte les indicateurs et arbitre les dossiers dont le devis dépasse le seuil interne retenu pour l’étude.

• R1. Toute demande enregistrée appartient à un seul client.
• R2. Une demande peut recevoir plusieurs versions de devis ; au plus une version est acceptée.
• R3. Un devis contient au moins une ligne de prestation. Son total est calculé à partir des quantités et des prix unitaires.
• R4. Un devis supérieur à 1 000 000 FCFA exige un accord du PDG avant son envoi au client.
• R5. L’acceptation d’un devis autorise la planification. Une notification manquée ne doit pas effacer cette acceptation.
• R6. Le client accède uniquement à ses dossiers ; les collaborateurs disposent de droits liés à leur rôle.

Ces identifiants serviront à relier les besoins, les diagrammes et les tests. Une modification de R4 doit ainsi conduire à revoir la décision d’approbation et les scénarios concernés.

3. Analyse, conception et réalisation

L’analyse précise le problème métier : ce qu’est une demande, qui accepte un devis et quelles restrictions s’appliquent. La conception répartit les responsabilités entre objets et services. La réalisation traduit les décisions dans une technologie. Un modèle d’analyse peut contenir Client et Devis ; un modèle de conception peut ajouter ServiceDevis et DepotDevis.

UML est un langage ; il n’impose pas une méthode unique ni un ordre obligatoire des diagrammes. Dans ce cours, nous adoptons une progression itérative : partir d’un besoin, dessiner une première vue, tester cette vue sur un exemple, puis corriger les autres vues si nécessaire. Il est possible de revenir aux classes après avoir découvert une information manquante dans une séquence.

1. Interroger les utilisateurs et relever des exemples concrets.
2. Définir le système et les résultats attendus par chaque acteur.
3. Écrire les règles et les scénarios, y compris les refus.
4. Identifier les objets métier et leurs liens.
5. Décrire les échanges, les cycles de vie et les traitements.
6. Confronter chaque vue aux règles et aux tests d’acceptation.

4. Les notions objet indispensables

Un objet possède une identité, des valeurs et un comportement. Le devis D-2026-018 reste le même objet lorsque son statut change. Une classe décrit ce que plusieurs objets ont en commun. Devis est une classe ; D-2026-018 est une instance.

L’encapsulation protège les règles : accepter() contrôle les conditions d’acceptation, au lieu de laisser chacun modifier librement le statut. L’abstraction retient ce qui compte : le modèle métier ne détaille pas la police de caractères du bouton. L’héritage exprime une spécialisation cohérente ; il ne sert pas seulement à économiser quelques attributs.

Le polymorphisme permet à plusieurs objets de répondre au même contrat selon leur implémentation. Un service peut appeler envoyer() sur un canal de notification sans connaître tous les détails d’un courriel ou d’un SMS. La composition organise un tout et ses parties lorsque leur appartenance et leur cycle de vie le justifient.

5. Choisir la vue qui répond à la question

UML comporte d’autres vues. Ce parcours s’arrête volontairement aux activités. Il ne développe pas les composants ni le déploiement.

6. Construire un dossier de modélisation utile

Commencer par un glossaire évite des ambiguïtés durables. Ici, une demande exprime un besoin, un devis propose une réponse chiffrée, une intervention réalise les prestations acceptées et une facture réclame un paiement. Ces mots ne sont pas interchangeables. Une demande peut exister sans devis et un devis refusé n’est pas une facture.

Chaque diagramme reçoit un titre, un périmètre et une légende lorsque la notation l’exige. Les mêmes noms doivent se retrouver d’une page à l’autre. On distingue une règle décidée par le métier d’une hypothèse à confirmer, puis on conserve les raisons des choix importants.

Exercices corrigés