Bonjour.

Nous essaierons de suivre les étapes de base les plus importantes pour la
réalisation de la tâche, en essayant de spécifier les actions les plus importantes
à réaliser dans chacune d'entre elles.
Il faut partir de la description du problème et des aspects à automatiser. Par
conséquent, nous partons de l'énoncé de la description du problème et
essayons de "marquer" (dans l'exemple, nous les mettons en gras) les noms
que nous trouvons, car ces noms peuvent être candidats à la constitution d'une
classe de notre modèle. Par exemple, essayons de suivre le processus pour le
premier paragraphe de la description.
Extraction de noms à partir de la description du problème.

"Les utilisateurs du système naviguent sur le web pour voir quels articles,
chaussures, sacs et accessoires sont vendus dans le magasin. Nous
sommes intéressés par le nom, la description, le matériau, la couleur, le prix
et le stock. Pour les exigences du système, nous avons également besoin
d'une photographie. Nous nous intéressons à la taille et au type de
chaussures. Nous sommes intéressés par le type de sacs. Pour les
accessoires(ceintures et gants), leur taille...".

À partir de ces noms marqués, nous pouvons créer un premier tableau

potentiel d'objets ou de classes :
 Classe/objet potentiel. Catégorie.

Utilisateur. Entité ou rôle externe.

Le système. Unité organisationnelle.

Web. Unité organisationnelle.

Article. Chose.

Chaussure. Chose.

Sac à main. Chose.

Complément. Chose.

Magasin. Chose.

Nom. Attribut

Description. Attribut

Matériau. Attribut

Couleur. Attribut

Prix. Attribut

Stock. Attribut

Photographie. Attribut

Nombre. Attribut

Type. Attribut

Ceinture. Chose.

Gant. Chose.

Taille. Attribut

Campagne. Chose

Sélection des noms en tant qu'objets/classes du système.

À ce stade, nous pouvons également supprimer un nom en tant que classe/objet

de notre modèle parce qu'il "échoue" à l'un des critères décrits à la section 3.5
"Lignes directrices pour la création de diagrammes de classes", qui sont
essentiellement les suivants :

Une fois la liste complétée, chaque classe potentielle devra être étudiée pour
voir si elle est finalement incluse dans le schéma. Pour nous aider à décider,
nous pouvons utiliser les critères suivants :
 1. Les informations relatives à la classe sont nécessaires au fonctionnement
du système.
2. La classe possède un ensemble d'attributs que l'on peut retrouver dans
toutes les occurrences de ses objets. Si un seul attribut apparaît, il sera
normalement rejeté et ajouté en tant qu'attribut d'une autre classe.
3. La classe possède un ensemble d'opérations identifiables qui peuvent
modifier la valeur de ses attributs et qui sont communes à tous ses
objets.
4. Entité externe qui consomme ou produit des informations essentielles à
la production de toute solution dans le système.

La classe est considérée comme telle si elle remplit tous (ou presque tous) les
critères.

Les points ci-dessus sont ceux applicables dans la colonne "Critères

applicables" du tableau suivant.

Tableau Classe potentielle/objet. Critères

Classe/objet potentiel. Critères applicables.

Utilisateur. 4 Rejeté.

Le système. Échec 1, 2, 3 et 4 Rejeté .

Web. Échec 1, 2, 3 et 4 Rejeté .

Article. 1,2,3.

Chaussure. 1,2,3.

Sac à main. 1,2,3.

Complément. 1,2,3.

Magasin. Échec 1, 2, 3 et 4 Rejeté .

Ceinture. Échec 1, 2, 3 et 4 Rejeté .

Gant. Échec 1, 2, 3 et 4 Rejeté

Campagne. 1,2,3.

Obtention des attributs des objets.

 Tableau Classe potentielle/objet. Attributs

Classe/objet potentiel. Attributs.

Article. Nom, prix, description, matériau, stock, photographie.

Chaussure. Nombre, type.

Sac à main. Type.

Complément. Taille

Campagne. Année, saison.

Partenaire. Nom, e-mail, adresse, ville.

Commande. Date de la commande, total, date de livraison.

Détails de la commande. Quantité.

Carte bancaire. Nombre.

Entreprise de transport. Nom, numéro de TVA, domicile fiscal.

Itinéraire. Zone d'influence, jours de livraison.

Incidence. Date, description.

Méthodes d'obtention.

En première approximation, il est possible d'obtenir un ensemble de méthodes

qui peuvent ensuite être modifiées et/ou étendues lors d'une seconde révision.
En tout état de cause, la liste donnée à titre d'exemple n'est pas exhaustive et il
convient d'évaluer la pertinence de toute autre méthode conforme à la
déclaration. Les méthodes énumérées se réfèrent à l'ensemble de la déclaration
:
 Tableau Classe potentielle/Objet. Méthodes
Classe/objet potentiel. Méthodes.

Article.

Chaussure.

Complément.

openCampaign(année, saison) closeCampaign(année¡

Campagne.
saison) addArticle()

voirCatalogue(),
register(name, email, address)
makeOrder0
Partenaire.
cancelOrder()
modifierlesdonnéespersonnelles()
checkOrderStatus()

addDetail(item, quantity) calculateTotal()

Commande.
assignRoute()

Détails de la commande.

Carte bancaire. contrôleValiditéO

Entreprise de transport.

Itinéraire.

Incidence.

Obtenir des relations.

Les classes étant déjà extraites et partiellement définies (des méthodes et des
attributs déduits de raffinements ultérieurs et de nos connaissances doivent
encore être ajoutés), nous pouvons commencer à établir des relations entre
elles.

• Nous commencerons par mettre en relation les articles, il y a une

généralisation évidente, car les chaussures, les sacs et les accessoires
sont des spécialisations de l'article.
• Les articles, à leur tour, sont organisés en campagnes, bien qu'ils
puissent exister en tant que tels, et nous les relierons donc par
agrégation.
• Les partenaires sont associés aux commandes. Un partenaire peut
passer plusieurs commandes, mais une commande ne peut être passée
que par un seul partenaire. Les membres ont une ou plusieurs cartes
bancaires qui leur sont associées.
• Les ordres sont constitués de plusieurs détails d'ordre, par le biais d'une
relation de composition, car le détail n'a pas de sens sans son ordre.
• Les commandes sont associées à des itinéraires, une commande
appartient à un seul itinéraire, les itinéraires peuvent avoir plusieurs
commandes qui leur sont affectées.
 • Les occurrences, qui correspondent à un ordre spécifique au sein d'un
itinéraire, sont modélisées comme un attribut de lien.

Les itinéraires sont regroupés en compagnies de transport en fonction de

leur composition.

En tenant compte de ces aspects, une partie du diagramme de classes, sans

tenir compte des attributs et des méthodes, pourrait ressembler à ceci :

Ajouter des Getters, des Setters et des constructeurs.

Dans le projet highlight, les attributs et leurs types de données correspondants

doivent être créés au préalable afin que les getters et setters soient générés
correctement.

Premier raffinement.

Dans le premier raffinement, les attributs et les méthodes déduits du travail avec
le diagramme et de la connaissance du diagrammeur sont ajoutés. Dans ce cas,
nous pouvons ajouter les méthodes suivantes :

• Commande: calculateDateDeparture(), une fois que la commande a été

affectée à un itinéraire, la date de départ est calculée en fonction des
jours de départ de l'itinéraire.
• Itinéraire: non indiqué dans la déclaration, mais le diagramme peut être
affiné.
ajouter des informations sur le moyen de transport (par exemple, un
camion) et le livreur.

Ajouter de la documentation.

Au moins les classes du diagramme doivent être documentées, en fournissant

une brève description des classes dans la section documentation de la
spécification des classes. Exemple :

• Article: un des noyaux centraux du système. Représente les articles

vendus par l'intermédiaire du système. Pour un article, nous stockons
son nom, sa description, son prix, son matériau, son stock et une
photographie.