Vers la conception objet Ingénierie Système Vers la conception objet

La conception objet dans la démarche A/COO on a un modèle du domaine, on a des fonctions : et ensuite ...? allouer des responsabilités aux classes trouver les classes logicielles décrire leurs interactions Conception objet + organisation classes en packages UML (composants) = Architecture logique

Modèles statiques et modèles dynamiques Il existe deux sortes de modèles objet : dynamiques et statiques Les modèles dynamiques comme les diagrammes séquence : Aident à concevoir la logique comportementale, le corps des méthodes dans le code Tendent à être les plus difficiles et les plus intéressants à créer Les modèles statiques tels que les diagrammes de classe ou de packages : Permettent de définir les packages, les noms de classes, les attributs et les signatures des méthodes, mais pas le corps de celles-ci Modèle dynamique Modèle statique

Diagrammes de séquence de conception (DSC) UML fournit des diagrammes d’interaction qui permettent de représenter la façon dont les objets interagissent via des messages On les utilise dans le cadre de la modélisation dynamique On va présenter succinctement la notation des diagrammes de séquence qui sont les diagrammes dynamiques les plus utilisés public class A { private B monB = new B(); public void messageUn() monB.messageDeux(); monB.messageTrois(); }

Lien entre diagramme de séquence et modèle de classes

Conception pilotée par les responsabilités (CPR) Nous pouvons penser la conception des objets logiciels (et des composants à plus grand échelle) en termes de responsabilités, de rôles et de collaborations Ces notions font partie d’une approche plus vaste nommée conception piloté par les responsabilités (CPR) Dans le CPR, les objets ont deux types de responsabilités : savoir et faire Les responsabilités de faire d’un objet peuvent être : Faire quelque chose lui-même, par exemple créer un autre objet ou effectuer un calcul Déclencher une action d’un autre objet Contrôler et coordonner les activités d’autres objets Les responsabilités de savoir d’un objet peuvent être : Connaître les données privées encapsulées Connaître les objets connexes Connaître des éléments qu’il peut dériver ou calculer GRASP : General Responsibility Assignment Software Patterns

CPR (suite) Les responsabilités sont affectées aux classes d’objets lors de la conception objet Ex. Vente a la responsabilité de créer les objets de la classe LigneArticles (faire) et connaître son total (savoir) Les objets du domaine inspirent souvent les responsabilités liées au « savoir » (à partir des attributs) La traduction des responsabilités en classes et méthodes est influencée par la granularité de celles-ci Ex. la responsabilité « fournir un accès à une BD relationnelle » peut nécessiter deux cents classes et des milliers de méthodes En revanche, la responsabilité de « créer une Vente » ne demandera peut-être qu’une seule méthode dans une seule classe

Cartes CRC - lien responsabilité et diagramme d’interaciton : interaction autour de la table

Cartes CRC