• Comprendre et modéliser une conception détaillée et l’implanter avec un langage à objets

• FA1-A : Analyse d’une solution informatique
• FA1-B : Conception technique d’une solution informatique
• FA1-C : Réalisation d’une solution informatique
• FA1-D : Tests de validation d’une solution informatique

Slack

afin de faciliter les discussions entre les tous (profs et étudiants) nous utiliserons SLACK, comme moyen de communication qui est très utilisé dans les entreprises.

• Téléchargez l'application sur vos machines personnelles et/ou téléphones, c'est un moyen vite adopté pour communiquer rapidement dans un contexte professionnel
• Lien d'invitation valable jusqu'au 22 janvier Puis rejoindre le canal #bases-de-la-coo.

Volume

• 8*1h de cours
• 8*4h de TD

Description

1. Introduction à la modélisation Cours Introduction à UML sem. 21 janvier
2. Un système pourquoi? pour qui? Les cas d'utilisation
   • Cours Cas d'utilisation sem. 21 janvier
   • TD Diagrammes de cas d'utilisation - Introductionsem. 21 janvier
   • TD Diagrammes de cas d'utilisation - Relationssem. 21 janvier
   • TD Diagrammes de cas d'utilisation - Descriptions sem. 28 janvier
   • TD Diagrammes de cas d'utilisation - Synthèse sem. 28 janvier
3. Description du domaine
   • Cours Diagramme de classes sem. 21 janvier
   • Pour en savoir plus en autonomie (à voir avant la semaine du : 11 février)
     • Cours sur les principes "objets"
     • Cours sur la Notion de classe
   • TD sur les diagrammes de classes pour modéliser le domaine sem. 4 février
   • TD avancé sur les diagrammes de classes pour modéliser le domaine sem. 4 février
4. Diagrammes de Séquences Cours diagramme de séquence sem. 7 février
   • TD sur les diagrammes de séquence sem. 11 février
5. Exemple d'application pour aller plus loin sur les diagrammes de classes sem. 11 février
6. De la modélisation au code Cours sur le passage en conception et au code sem. 11 & 28 février & 4 mars
   • Des modèles aux codes et vis-versa sem. 28 février
   • De la modélisation au code : FINALE sem. 4 mars
7. Révisions sem. 11 mars
8. EXAMEN sem. 28 mars

• Un examen final sanctionne ce module. (coeff. 1)

• Les TD (coeff. 0,75)
  • Chaque semaine, une heure est consacrée à l'évaluation individuelle.
  • Des rendus demandés peuvent compléter cette notation.
• Autres (coeff. 0,75)
  • Des contrôles surprises
  • Un rendu-final de type carnet de bord
    • Rendu le 28 mars à 9h, juste avant l'examen, dans le dépôt jalon avec comme nom : CB_NumeroGroupeTD – Noms des étudiants participants au rendu.)
    • Ce rendu peut se faire par binôme (exceptionnellement trinômes)
    • Son contenu correspond aux différents TDs, et plus particulièrement l'étude de cas à faire seul(l'étude de cas sur le “smart garage”), et vise à mettre en relief ce que vous avez appris.
      • Vous éviterez d'utiliser l'étude de la galerie d'art qui est très utilisée dans les précédents carnets de bord.
    • Sa forme peut être un document textuel ou un document web.
    • Il a pour cible d'expliquer à d'autres développeurs, l'art de l'analyse/conception sur la base de l'expérience acquise dans ce module. Voici quelques éléments de notations :
      • Forme du document
      • Choix des exemples utilisés pour expliquer les notions
      • Adéquation avec les objectifs pédagogiques de cet exercice (Clarté des explications, intérêt pour d'autres étudiants)
      • Qualité des codes et modèles présentés
      • Quels “trucs” à retenir? Que faut-il absolument retenir? Chaque étudiant du groupe identifie au moins un élément de cet enseignement qui lui semble important de transmettre. Le correcteur doit pouvoir identifier au moins un “truc” par étudiant.
      • Quelles erreurs sont les erreurs à ne pas commettre? Chaque étudiant du groupe identifie au moins une erreur à ne pas commettre. Le correcteur doit pouvoir identifier au moins une erreur signalée par étudiant.
      • Des tests pour s'auto-évaluer. Chaque étudiant du groupe propose au moins un test pour s'auto-évaluer. Le correcteur doit pouvoir identifier au moins un test proposé par chaque étudiant.
      • Couverture du module (tous les aspects ont-ils bien été couverts par le cahier de bord?)

``

• Le système ne doit pas prendre en charge la saisie des informations par les auteurs : les UC doivent justement vous permettre de délimiter le système.

Et toujours les mêmes !! (comment le dire?)

• Comme très souvent, l'internaute n'est pas un objet du système…
• Encore des relations à l'envers, en particulier l'héritage entre classes !
• Des S aux acteurs : consultants, …
• Des losanges au petit bonheur avec généralement aucune cardinalité ou rôle !
• Pas de rôles sur les associations

• Rendus en 2018 :
  • http://yann.fzcommunication.fr/index.php/conception-oriente-objet : YANN ZAVATTERO
  • 2018-03-29_08h28m30s_carnet_de_bord.zip : NASTASSIA MANA
• Rendus en 2017 :
  • Guillaume BARILLET - Titouan VEAUVY
  • (Saurel Nadaud bientôt disponible)
• Rendu en 2016 : http://alexandre-lang.fr/CPOO/Semestre_2/index.html Alexandre Bruyat, Alexandre Lang et Rémy Munier
• Rendu en 2014 : http://www.coo.maximecarrillo.fr, mais attention les consignes ont un peu changées.

Voici des examens issus de l'ancien PPN.

• Examen 2011
• Examen 2012

Comprendre les objets...excellent cours par vidéos

http://www.afceurope.com/uml.html

Comprendre les objets au travers des Tajines !!

Des uses cases extraits de business Process !!