Ingénierie Système

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

2. 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

3. 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

4. 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(); } }

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

6. 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

7. 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

8. Cartes CRC

9. Cartes CRC