Différences

Ci-dessous, les différences entre deux révisions de la page.

--- doc:poo [2017/08/22 15:28] – ↷ Page déplacée de concept:poo à doc:poo root
+++ doc:poo [2020/05/11 00:24] (Version actuelle) – Suppression de la taille par défaut pour les images root
@@ Ligne 3: / Ligne 3: @@
 Une interface est un contrat qui définit un ensemble de méthodes. Les classes qui implémenteront cette interface devront au minimum implémenter ces méthodes.
-{{:concept:poo:interface.png?398|Interface}}
+Les interfaces peuvent servirent dans plusieurs cas :
+  * Forcer un groupe de classes à implémenter au minimum certaines méthodes. L'exemple classique est la classe ''Animal'' avec la méthode ''Aller''. Un cheval, il va utiliser 4 pattes, une poule deux, une araignée huit et un poisson va battre de la queue,
+  * Permettre de développer une fonctionnalité utilisant l'interface en attendant qu'une autre personne développe la classe qui respectera l'interface,
+  * Faciliter l'écriture des tests. Si une classe manipule un matériel physique, il peut être difficile de tester une autre classe exploitant le matériel. Il pourra être alors intéressant de remplacer la classe matériel par une fausse classe dite ''mock''.
+  * "Les composants sont visibles des autres composants exclusivement à travers des interfaces".
+{{doc:poo:interface.png|Interface}}
 ====Abstraction====
 Représenter la réalité comme étant un objet.
-En pratique cela consiste à définir des méthodes et des attributs dans une classe. Les méthodes peuvent être déjà implémentées ou alors également laissées abstraites pour forcer le développeur à les implémenter ultérieurement.
+En pratique cela consiste à définir des méthodes dans une classe. Les méthodes peuvent être déjà implémentées ou alors également laissées abstraites pour forcer le développeur à les implémenter ultérieurement.
 ====Encapsulation====
 L'encapsulation regroupe toutes les données et les méthodes implémentées pour les exploiter. Les données peuvent être regroupées dans des ''POJO''/''POCO''/… et invisibles, si besoin, de l'extérieur.
-{{:concept:poo:encaps.gif?577|Encapsulation}}
+{{doc:poo:encaps.gif|Encapsulation}}
-[[http://hdd34.developpez.com/cours/artpoo/|Source]], {{:concept:poo:introduction_a_la_programmation_orientee_objet.htm.maff|Archive}}
+[[http://hdd34.developpez.com/cours/artpoo/|Introduction à la Programmation Orientée Objet]] {{ :doc:poo:artpoo.pdf |Archive du 10/09/2011 le 26/04/2020}}
+  * Partage de données
+<blockquote>The tempting and straight forward approach for realizing undo is to store the state information directly in the command objects. In many cases this will expose parts of the internal structure of the model and violate the principle of encapsulation.<cite>[[https://dl.acm.org/citation.cfm?doid=1411732.1411738|A framework for command processing in Java/Swing programs based on the MVC pattern]] {{ :helloworld:design_pattern:command:undomanager:a_framework_for_command_processing_in_javaswing_pr.pdf |Archive}}</cite></blockquote>
 ====Héritage====
 L'héritage permet de spécialiser une classe. Il reprend toutes les caractéristiques d'une classe en redéfinissant ou ajoutant des méthodes et en ajoutant des attributs.
-{{:concept:poo:poo1.png?350|Héritage}}
+{{doc:poo:poo1.png|Héritage}}
-[[http://www.geek-directeur-technique.com/tag/classe|Source]], {{:concept:poo:classe_de_geek_a_directeur_technique.htm.maff|Archive}}
+[[https://www.geek-directeur-technique.com/2012/01/10/les-langages-de-programmation-partie-2-le-modele-objet|classe – De geek à directeur technique]] {{ :doc:poo:les_langages_de_programmation_partie_2_le_modele_objet_de_geek_a_directeur_technique_2020-04-26_11_08_19_pm_.html |Archive du 10/01/2012 le 26/04/2020}}
 ====Polymorphisme / redéfinition====
 Le polymorphisme est donc la capacité du système à choisir la méthode qui correspond au type réel de l'objet en cours.
-{{:concept:poo:polym.gif?129|}}
+{{doc:poo:polym.gif|}}
-<note important>La méthode appelée variera si sa définition est virtuelle ou non.</note>
+<WRAP center round important 60%>
+La méthode appelée variera si sa définition est virtuelle ou non.
+</WRAP>
 ====Surcharge====
@@ Ligne 39: / Ligne 49: @@
 Exemple : une classe homme est composée avec une classe cœur.
-{{:concept:poo:composition.svg.png?400|}}
+{{doc:poo:composition.svg.png|}}
 ====Agrégation====
@@ Ligne 46: / Ligne 56: @@
 Exemple : une classe bibliothèque est agrégé avec une classe livre.
-{{:concept:poo:agregation.png?490|Agrégation}}
+{{doc:poo:agregation.png|Agrégation}}
 ====Association====
@@ Ligne 52: / Ligne 62: @@
 Exemple : étudiant et professeur. Même s'il existe dans la réalité une notion de hiérarchie, elle n'a rien à voir dans la notion d'association. Un étudiant peut être dissocié d'un professeur et inversement sans que cela ne pose le moindre problème.
-[[http://javarevisited.blogspot.fr/2014/02/ifference-between-association-vs-composition-vs-aggregation.html|Source]], {{ :concept:poo:difference_between_association_composition_and_aggregation_in_java_uml_and_object_oriented_programming.html.maff |Archive}}
+[[https://javarevisited.blogspot.com/2014/02/ifference-between-association-vs-composition-vs-aggregation.html|Difference between Association, Composition and Aggregation in Java, UML and Object Oriented Programming]] {{ :doc:poo:difference_between_association_composition_and_aggregation_in_java_uml_and_object_oriented_programming_2020-04-26_11_13_44_pm_.html |Archive du 05/02/2017 le 26/04/2020}}
-=====SysML=====
-SysML est à UML ce que NoSQL est à SQL. On passe d'une approche document à une approche modèle.
-Modélisation intégrée : il faut adresser tous les aspects du Système. Base commune pour la conception, la compréhension et la validation. Gérer le développement, documentation, représentation plus complète.
-On commence par modéliser la couche la plus haute (le niveau opérationnel) et on descend jusqu'à (la couche composants).
-   * Opérationnel : boite noire qui rend des services, des cas d'utilisation, des interfaces, IHM.
-   * Système : architecture : assemblages des composants liés par des connecteurs.
-   * Connecteur : respect des spécifications.
-Langage graphique.
-Supporte la spécification, l'analyse, la conception, la vérification (conforme aux process) et la validation (le résultat).
-SysML contient une bonne partie de UML2 plus des extensions : blocs, item flow, value properties, allocations, exigences, paramétriques, flots continus.
-Un bloc peut contenir des (une rubrique dans chaque case de l'UML) :
-   * propriétés : valeurs (avec type, unité, dimension, probabilité/précision), références (aggrégation, partage entre plusieurs éléments), parties (composition),
-   * opérations : méthodes,
-   * contraintes,
-   * allocations : lien (mapping) de/vers d'autres éléments d'autres diagrammes, d'activités souvent,
-     * comportementale : fonction vers un constituant/composant,
-     * structurelle : élément logique vers élément physique. logiciel -> oracle,
-     * logiciel vers matériel.
-     * allocation explicite avec des couloirs d'activités.
-   * exigences,
-   * comportements : définis par l'utilisateur.
-Les ports :
-   * Ils sont points d'interaction sur les blocs et les parties.
-   * Ils ont un nom et un type.
-   * Deux catégories :
-     * port standard (UML, définit des services/API/etc requis ou fourni),
-     * Flow port, flux continu (définit ce qui transite par le port).
-   * Délégation de ports : proposer une interface/boite noire.
-Type de diagrammes :
-   * Diagrammes de structure (structure diagrams) (UML 2) :
-     * Diagramme de structure composite (block definition diagram BDD) (UML 2 modifié) : peut se définir comme une classe avec un stéréotype bloc. Renseigne de quoi est fait le système physique (les composants, les logiciels, l'humain, …). Possibilité d'héritage. Définition des relations entre blocs (composants) avec des connecteurs pour représenter des architectures/hiérarchies. L'usage des blocs est dans les diagrammes d'activités.
-     * Diagramme de structure composite (internal block diagram IBD) (UML 2 modifié) : définit les propriétés d'un bloc et indique les interactions via des connecteurs entre les composants (diagramme interne). Les flèches indiquent l'interaction. Les blocks en composition sont en trait plein et les blocks en agrégation sont en trait pointillé.
-     * Diagramme des paquets (package diagram) (UML 2) : c'est une sorte de répertoire. Classement au choix : par phase de projet, par sous-système. Possibilité de regrouper les paquets dans des vues.
-   * Diagramme de comportement (behavior diagram) (UML 2) : description des activités.
-     * Diagramme d'activité (activity diagram ACT) (UML 2 modifié) :
-       * verbaliser les actions, analyse fonctionnelle.
-       * Effectue une liste contrôlée d'action en fonction des paramètres d'entrée.
-       * Responsabilité va des séparations en "couloir d'activités".
-       * Extension : Flux continus (courant électrique, …) et diagramme fonctionnel de flux amélioré (noter les échanges d'information entre les actions et quand un bloc/flux se déclenche/s'arrête).
-       * Une action peut être décrite comme une activité.
-       * Une action prend une entrée fixe qui ne peut pas être modifiée durant l'action, elle est de type non Stream. Si l'entrée peut être modifiée (continue, échantionnée), elle s'appelle un stream.
-       * Type d'action :
-         * atomique (call operation action),
-         * complexe (call behavior action), détaillé dans un diagramme d'activité.
-         * réception d'un événement (accept event action),
-         * émission d'un signal (send signal action).
-       * Dessin :
-         * Activité : rectangle à bords arrondis.
-         * Pin In/Out : rectangle.
-           * Sur le bord contour du diagramme s'ils sont des paramètres d'entrée ou des flux de sortie de l'activité.
-           * Contre le bloc si la pin reste interne au diagramme. Possibilité de remplacer les 2 pin par un bloc.
-         * Trait continu : transfert d'information/signal/…, trait pointillé : flot de contrôle, événement déclenchant une activité.
-         * Rond plein : début de l'activité.
-         * Rond plein avec auréole blanche : fin de l'activité.
-         * Rond blanche avec croix interne : fin de l'activité d'un jeton.
-         * Barre gras : dédoublement d'un jeton (fork) ou attente synchro jeton (seul le premier arrivé passe).
-         * symbole de terre en électronique en haut à droite du rectangle action : activité décomposable.
-         * cadre en pointillé à l'intérieur du diagramme : zone interruptible.
-         * Trait séparant tout le diagramme : couloir d'activité et mettre pour chaque couloir le stéréotype ''allocate''.
-     * Diagramme d'interaction/de séquence (sequence diagram) (UML 2),
-       * Comportement d'un système et non d'un logiciel.
-       * Opérateurs : ref (à un diagramme de séquence), opt + condition (optionnel), alt (alternative), par (parallèle), loop, break, critical, neg, assert, seq(weak)/strict, consider, ignore.
-     * Diagramme états-transitions (state machine diagram) (UML 2) :
-       * représente le cycle de vie d'un bloc.
-       * Les événements déclenchent la transition entre les blocs. Événement Change, time et signal.
-     * Diagramme des cas d'utilisation (use-case diagram) (UML 2) : décrire les fonctionnalités (buts et usages) d'un système.
-       *
-   * Diagramme d'exigence (requirement diagram) (SysML) :
-     * Stéréotype « Requirement »
-     * À quoi répondre comme besoin : l'ensemble des exigences font les spécifications.
-     * Deux attributs : id + text (description). Les exigences systèmes se transforment en exigence sur les constituants.
-     * Chaque exigence peut être composé d'autres exigences. Représentation ⊕ : rond avec un + à l'intérieur.
-     * Relation de type :
-       * DeriveReqt : relation de dépendance (puissance d'un moteur avec l'accélération d'une voiture),
-       * Satisfy : un bloc doit satisfaire une exigence,
-       * Verify,
-       * Refine,
-       * Trace,
-       * Copy.
-   * Diagramme paramétrique (parametric diagram PAR) (SysML) : indique quelles sont les paramètres nécessaires pour chaque équation. Simulink : permet de vérifier que les assert sont correct en fonction des paramètres d'entrée.