Notes pour mon étude. À relire juste avant l'examen
Problème: Utilisation souhaitée de plusieurs composants alternatifs qui présentent des « interfaces » différentes
Solution: Mettre un objet intermédiaire entre les deux (l’adaptateur) qui nous sert d’interprète
Bon début, permet d'utiliser deux composants alternatifs de manière centralisé.
Par contre, on se ramasse avec des fonctions contenant beaucoup de "Ifs" ou encore des "Switch/case" pour gérer chaque composants différement
L'adapteur est abstrait ici, ce qui veut dire qu'on doit implémenter un adapteur par composants alternatifs.
Plus de classes, mais chaque classes à un rôle et on évite le désavantage vu précédemment
Si on regarde les Adapters vus précédemment, qui va créé les objets?
Si la classe qui utilise l'adapteur doit implémenté celui spécifique au besoin, ça brise le concept... (On se ramasse à nouveau avec un if / else pour gérer quel adapteur on instancie)
Il faut une classe responsable de déterminer pour quelle sous-classe il faut créer une instance.
C'est ça une Factory
Quand j’ai besoin d’un objet, plutôt que de le créer moi-même en faisant un :
On délègue la responsabilité à une usine à objets :
On vient complexifié un peu le tout.
À la place d'avoir une Factory qui contient un if / else pour déterminer quelle sous-classe retournée, la Factory devient abstraite.
Chaque implémentation de la Factory abstraite va savoir tout de suite quelle sous-classe retournée selon le contexte.
Il s'agit d'un cas d'utilisation un peu plus précis, mais qui peut simplifié le code dans ses cas.
Contexte / Problème : Une et une seule instance d’une classe est autorisée (un singleton). Les classes utilisatrices ont besoin d’un point d’accès global et unique à cette instance.
Solution : Définir une méthode statique de la classe qui retourne la seule et unique instance
Problème : Différentes versions d'un algorithme sont appelés à coexister
Solution : Définir les versions de l'algorithme comme des classes distinctes plutôt qu'en tant que méthode
Problème : Comment traiter un groupe d'objet de la même manière qu'un des objets individuel
Solution : S'assurer que le "conteneur" implémente la même interface que le "contenu"
Problème :
Solution :
Problème : On désire définir un point de contact unique pour plusieurs objets disparates constituant en quelque sorte un sous-systèmem
Solution : Définir une "façade" qui encapsule ce sous-système. Il présentera une interface unifiée de plus haut niveau rendant le sous-système plus facile à utiliser
Avantages :
Un autre diagramme servant à représenter le comportement dynamique du système
Montre en même temps les flots de contrôle et les flots de données
Représenté par une bulle dans le diagramme
L'action peut être étiquetée en langage naturel, en pseudocode ou avec un langage de programmation
Exemples :
Représentées par des flèches dans le diagrammes
Les actions sont reliées par des transitions
Lorsque l'action se termine, la transition est automatiquement déclenchée et l'action du prochain état-action démarre
Il est généralement inutile de mettre un nom d'événement sur la transition
Représentés comme une condition entre crochet []
Les transitions peuvent prendre des conditions de garde booléennes mutuellement exclusives appelées décisions
Exemple :
Représenté par un losange
Permet d'afficher un split, par exemple un split de chemin avec des conditions
Ou encore une fusion de différentes branches
Représenté par une barre de départ et de sortie
Une barre de synchronisation permet d'ouvrir et de fermer des branches parallèles dans un flot d'exécution d'une méthode ou d'un use-case
Les transitions qui quittent une barre de synchronisation sont déclenchées simultanément
Une traque pour chaque partie impliquée, similaire aux diagrammes de séquence
À la place de mettre une simple action dans une bulle, il est possible de mettre un nouveau diagramme d'activité
Assez straight-forward
L’architecture physique du système à l’étude s’intéresse à la description détaillée de celui-ci sur les plans du matériel et des composants logiciels
Vient répondre aux questions suivantes :
Les composantes logicielles sont les implantations physiques des concepts et fonctionnalités définis dans le modèle logique du système
Trois notations différentes
Interfaces
Un composant peut implémenter une / des interfaces
Représentées par une ligne terminée par un cercle, avec le nom de l'interface sous le cercle
