Diagramme de classes : Représentation statique des classes, de leurs attributs, méthodes et relations.
- Identifier les entités du système
- Créer les classes correspondantes
- Définir les attributs de chaque classe
- Spécifier les méthodes de chaque classe
- Établir les relations entre classes
- Valider la cohérence du modèle
Système de Gestion de Bibliothèque - Classes
- titre: String
- auteur: String
- genre: String
- disponible: Boolean
+ rendre(): void
+ estDisponible(): Boolean
- nom: String
- prenom: String
- email: String
+ rendre(l: Livre): void
+ consulterHistorique(): List<Livre>
- dateFin: Date
- rendu: Boolean
+ estEnRetard(): Boolean
• Emprunteur : Gère les utilisateurs du système
• Emprunt : Représente les transactions
• Emprunteur ↔ Emprunt : Association (un emprunt est fait par un emprunteur)
• Multiplicité : 1 Livre ↔ 0..n Emprunts, 1 Emprunteur ↔ 0..n Emprunts
Déterminer les objets principaux du système de gestion de bibliothèque.
Modéliser chaque entité comme une classe avec ses attributs.
Spécifier les comportements de chaque classe.
Diagramme de classes complet avec Livre, Emprunteur et Emprunt, avec leurs attributs, méthodes et relations.
• Abstraction : Chaque classe doit représenter une entité claire
• Encapsulation : Les attributs sont privés, les méthodes publiques
• Relations : Les associations doivent être pertinentes et documentées
Diagramme de composants : Représentation des composants logiciels et de leurs dépendances.
- Identifier les modules logiciels du système
- Regrouper les modules en composants
- Spécifier les interfaces fournies et requises
- Établir les relations de dépendance
- Représenter les ports d'interaction
- Valider l'architecture modulaire
Application Mobile - Composants
• Logique Métier : Traite les règles de gestion
• Accès Données : Gère la persistance
• API Externe : Services tiers
• Logique Métier → Accès Données : Persistance des données
• Accès Données ← API Externe : Services externes
• Interfaces : API clairement définies
Décomposer l'application en modules logiciels cohérents.
Regrouper les modules en composants fonctionnels.
Spécifier les interfaces fournies et requises par chaque composant.
Diagramme de composants avec Interface Utilisateur, Logique Métier, Accès Données et API Externe, avec leurs relations.
• Modularité : Chaque composant doit avoir une responsabilité claire
• Interfaces : Les interfaces doivent être bien définies et documentées
• Dépendances : Les relations doivent refléter les véritables dépendances
Diagramme de paquetages : Représentation de l'organisation hiérarchique des paquetages.
- Identifier les groupes logiques d'éléments
- Créer des paquetages pour chaque groupe
- Organiser les paquetages en hiérarchie
- Spécifier les dépendances entre paquetages
- Représenter les importations et exportations
- Valider la structure organisationnelle
Application Web - Paquetages
• models
• views
• utils
• controllers : Gestion des requêtes
• models : Modèles de données
• views : Composants d'affichage
• services : Services métiers
• controllers → services : Services métiers
• models → utils : Utilitaires
• services → models : Persistance
Regrouper les classes/modules selon leur fonction ou responsabilité.
Créer des paquetages pour chaque groupe logique.
Organiser les paquetages dans une structure arborescente.
Diagramme de paquetages avec com.app.web, controllers, models, views et services, organisés hiérarchiquement.
• Cohésion : Les paquetages doivent contenir des éléments cohérents
• Couplage : Minimiser les dépendances entre paquetages
• Hiérarchie : Organiser les paquetages de manière logique
Diagramme d'objets : Représentation d'une instance particulière du système à un moment donné.
- Identifier une situation spécifique du système
- Représenter les instances des classes
- Spécifier les valeurs des attributs
- Montrer les relations entre objets
- Indiquer les liens d'association
- Valider la cohérence avec la structure
Panier d'Achat - Objet
| Objet | Classe | Attributs | Valeurs |
|---|---|---|---|
| panier1 | Panier | id, date, articles, total | 1, 2023-10-15, [prod1, prod2], 45.99 |
| client1 | Client | id, nom, email | 101, Dupont, j.dupont@email.com |
| prod1 | Produit | ref, nom, prix | P001, T-shirt, 19.99 |
| prod2 | Produit | ref, nom, prix | P002, Pantalon, 25.00 |
date: 2023-10-15
total: 45.99
nom: Dupont
email: j.dupont@email.com
nom: T-shirt
prix: 19.99
nom: Pantalon
prix: 25.00
• Valeurs : Les attributs ont des valeurs spécifiques
• Relations : Les objets sont liés selon les associations
• État : Représente une situation à un moment donné
Choisir un état spécifique du système à représenter.
Créer des objets avec des noms d'instance spécifiques.
Spécifier les valeurs concrètes des attributs.
Montrer les liens entre objets selon les associations de classes.
Diagramme d'objets montrant le panier d'achat avec les produits et le client à un instant donné.
• Instantiation : Chaque objet est une instance d'une classe
• Spécification : Les attributs doivent avoir des valeurs concrètes
• Cohérence : Les relations doivent respecter la structure de classes
Diagramme de profil : Extension d'UML pour un domaine spécifique d'application.
- Identifier le domaine d'application spécifique
- Définir les stéréotypes nécessaires
- Créer des métaclasses si nécessaire
- Établir les contraintes de modèle
- Documenter les propriétés des stéréotypes
- Valider la pertinence du profil
Profil IoT - Domaine spécifique
| Stéréotype | Métaclass | Propriétés | Description |
|---|---|---|---|
| <<Capteur>> | Class | type, précision, portée | Composant de mesure |
| <<Actionneur>> | Class | type, puissance, fréquence | Composant d'action |
| <<Connectivité>> | Association | protocole, bande_passante | Communication |
| <<ContrainteTemporelle>> | Constraint | délai, priorité | Exigence de temps |
Température
précision: ±0.5°C
portée: -40 à 85°C
Relais
puissance: 10A
fréquence: 50Hz
WiFi
bande_passante: 150Mbps
• Métaclass : Classe UML étendue
• Propriétés : Attributs spécifiques
• Contraintes : Règles de modèle
• Tagged Values : Valeurs personnalisées
Déterminer le domaine spécifique pour lequel le profil est nécessaire.
Créer des stéréotypes pour les concepts spécifiques du domaine.
Définir les propriétés spécifiques pour chaque stéréotype.
Vérifier que le profil répond aux besoins du domaine.
Profil IoT défini avec des stéréotypes Capteur, Actionneur, Connectivité et ContrainteTemporelle.
• Spécialisation : Le profil doit être adapté au domaine spécifique
• Extensibilité : Les stéréotypes doivent enrichir UML sans le modifier
• Documentation : Chaque élément du profil doit être bien documenté
- Clarté : Utiliser des noms explicites pour les classes et composants
- Modularité : Organiser les éléments en modules cohérents
- Hiérarchie : Établir une structure hiérarchique logique
- Documentation : Commenter les relations et dépendances
- Les diagrammes structurels doivent représenter l'architecture statique du système
- Les relations entre éléments doivent être cohérentes et documentées
- La granularité des éléments doit être adaptée au niveau d'abstraction
- Les diagrammes doivent être lisibles et maintenables
- Classe : Modèle d'objet avec attributs et méthodes
- Composant : Unité de modularité logicielle
- Paquetage : Groupe d'éléments liés
- Objet : Instance d'une classe à un instant donné
- Profil : Extension d'UML pour un domaine spécifique
