Introduction

Premiére generation

• 1954-1958
• Fortran, Algol 58
• Calcul scientifique

Deuxieme generation

• 1959-1961
• Fortran II, Algol 60, Cobol, Lisp
• Compilation separée
• Type de données
• Pointeurs
• Listes
• Ramasse-miettes (garbage collector)

Troisieme generation

• 1962-1970
• Pascal, algol 68
• abstraction de données

Quatrieme generation

• 1970 =>
• C, C++, Java

1ere generation

3eme generation

Les languages objets

• Pas de données globales
• classes et objets remplacent les modules
• notion de type

Les principaux langages objets

• Java
• C++ (C objet)
• C#
• delphi (pascal objet)
• Objective C (remplacé par swift prochainement)
• python
• ruby
• php (à partir de la version 5)
• dart
• coffeescript
• javascript 

Cycle de vie d'une application

• Analyse des besoins et faisabilité
  • expression, recueil et formalisation des besoins du client et de l'ensemble des contraintes ;

• Spécifications ou conception générale (modelisation)

  • il s'agit de l'élaboration des spécifications de l'architecture générale du logiciel ;

• Code 

  • traduction dans un langage de programmation des fonctionnalités définies lors de phases de conception ;

• Tests unitaires

  • permettent de vérifier individuellement que chaque sous-ensemble du logiciel est implémenté conformément aux spécifications ;

• Qualification (ou recette)

  • verifie ques les specifications ont été réspecté ;

La programmation orienté objet se concentre sur les données alors que la programmation procedurale est avant tout centrée autours des fonctionnalités ( fonctions et procedures ).

Différences avec la programmation procédurale

Avec l'approche procédurale, nous allons reflechir aux differentes étapes qui nous permettrons d'arriver au resultat souhaiter.

Représentation graphique d'une approche fonctionnelle.

Techniquement il nya rien qu'on puisse faire avec un langage objet qu'on ne puisse faire avec un language fonctionnel.

Les caractéristiques de l'approche objet

L'approche objet

Logiciel formé d'une collection d'objets
indépendants qui incorporent à la fois une
structure de données et un comportement.
Notions caractéristiques :

• Identité
• Classification
• Héritage
• Polymorphisme

Qu’est-ce qu’un objet ?

• Toutes instructions et toutes données sont stockées dans des objets.
• Un objet regroupe un ensemble de caractéristiques et de méthodes (on parle aussi de fonctionnalités) .
• Exemple
  • Un couteau est tranchant => caractéristique
  • Un couteau peut couper=>  méthode

Les objets sont des entités

• Dans notre application, deux objets qui auraient les mêmes valeurs pour leurs attributs seraient indistinguables l’un de l’autre.
• 2 pieces de 1 euro.
• 2 timbres identiques de la même série.
• 2 points de mêmes couleurs aux mêmes coordonnées.

Les entités ont une identité

• MAIS ils sont différents: leur identité est différente

• Dans un programme, ces objets existent à des adresses différentes de la mémoire.

• Souvent dans des bases de données on leur associe un champ unique (clé).

Qu’est-ce qu’un objet ?(suite)

• Un objet est avant tout créé a partir d’un modèle(une modélisation)

  • Modélise une chose tangible

    • ex: ville, service hospitalier, scanner, véhicule, étudiant

  • Modélise une chose conceptuelle

    • ex: réunion, planning de réservation scanner, date

  • Elément constitutif d’une application logicielle (collections..)

Modèles

Pour modéliser et comprendre quelque chose de complexe

• Une voiture
• Un immeuble
• Un logiciel

Les modèles peuvent être spécifiques à chaque destinataire n’exprimant que ce qu’il lui est nécessaire.

exemple : la modélisation d’un avion pour un constructeur sera plus detaillée, voire différente que pour un acheteur.

Exemple de l’immeuble

• Quel immeuble ? Pour quel usage ?
• De quoi aura-t-il l’air ?
• Combien coûtera t’il ? Combien de temps pour le construire ?
• Par ou passent les câbles réseau ?
• Où se situera t’il ?
• Combien d’étages ?

Qu’est-ce qu’un modèle

• Un modele M est un modèle d’un objet O si M permet de répondre à des questions au sujet de O.

• Nous construisons M parce qu’il est plus pratique que O.

  • O n’est pas encore construit.

  • Des choix restreints à faire (impossible de construire O maintenant).

  • M est moins cher à construire.

     

Un modèle est abstrait

• Le modèle ne décrit pas tous les aspects de l’objet modélisé.(on ne peux pas décrire totalement un être humain)

• M est plus simple que O.

• Parfois M est une version idéalisée de O.

Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du système. C'est également un bon moyen de maîtriser sa complexité et d'assurer sa cohérence.

Les objets (1/5)

La programmation orientée objet consiste en la définition et l’assemblage de briques logicielles appelées objets.

Un objet est une structure de données qui répond à un ensemble de messages. Cette structure définit son état et l’ensemble des messages décrit son comportement.

Les objets (2/5)

Terminologie des objets :

• Les données internes sont appelées attributs.

• La réponse à la réception d’un message par l’interface est appelée méthode.
  

• • L’objet est une boîte noire.

  • Droits d’accès aux attributs et aux méthodes.

• Principe d’encapsulation.

Les objets (3/5)

• Encapsulation (suite)

  • Visibilité des attributs et méthodes :

    • Partie privée: connue uniquement de l’objet

    • Partie publique

  • Les données membres (attributs) doivent toujours être privées.

  • Les méthodes doivent être publiques seulement si elles sont utilisées par d’autres objets.

     

Les objets (4/5)

• Une classe est un modèle utilisé pour créer les objets.
• Chaque objet est une instance d’une classe.
  • Avec son propre état (même si deux instances sont strictement identiques).
  • Toutes les instances d’une classe ont le même comportement.
  • Les instances peuvent partager des attributs.

Ici le moule represente la classe (le modèle), et la gauffre représente l'objet.

Les objets (5/5)

Exemple d’objet : un compte bancaire

• Les données (attributs) :

  • Type de compte

  • Solde

• Les traitements (méthodes) :

  • Débiter

  • Créditer

     

Constructeur et destructeur

Le constructeur

• Construction de l’objet en mémoire ;
• Mise en place des données ;
• Création du diagramme d’héritage ;
• Un objet peut ne pas contenir de constructeur explicite ;
• Un objet peut avoir plusieurs constructeurs: l’utilisateur choisit celui qui doit être appelé ;

Le destructeur

« Inverse » du constructeur

(Pas de destructeur en java)

• Destruction de l’instance de l’objet ;
• Un objet peut ne pas contenir de destructeur explicite ;

Les relations entre objets

Un système objet est composé d’un ensemble d’objets qui ont différents types de relations entre eux.

Les relations entre objets :

• L’association ;

• La composition ;

   

Association (1/2)

Une association exprime une connexion entre deux classes.

Une association est généralement représentable avec un verbe :

• Une personne travaille pour une entreprise ;
• Un client commande un produit ;

Association (2/2)

La cardinalité c’est le nombre d’instances qui participent à l’association.

Les cardinalités :

• N        Exactement N éléments (N>0) ;

• N..M    Entre N et M éléments (N>0 et M>N) ;

• *        Plusieurs ;

Composition (1/2)

La composition consiste à utiliser une classe comme attribut d’une autre classe.

Par exemple: une classe voiture  peut contenir une classe  moteur.

On représente une composition par un trait plein terminé par un losange (du côté de la classe qui contient l’autre).

Composition (2/2)

Quand un objet A est un attribut d’un objet B, le constructeur de l’objet A sera appelé avant celui de l’objet B.

Exemple: le constructeur de la classe « moteur » est appelé avant celui de la classe voiture.

La composition est une relation forte, la destruction d’un objet entraîne la destruction des objets qui le composent.

L’héritage (1/3)

 Favorise la réutilisabilité et l’adaptabilité des objets.

Principe proche de l’arbre généalogique :

• Une classe fille est une classe qui hérite des caractéristiques de sa mère ;

• Une classe fille caractérise / specialise ce que représente la classe mère ;

L’héritage (2/3)

Lors d’un héritage, une classe hérite de :

• Tous les attributs et peut en ajouter ;

• Toutes les méthodes et peut en ajouter ou en redéfinir

Graphiquement, on représente l’héritage avec un triangle

L’héritage est une relation de type " est un(e) ".

• Exemple : une voiture est un véhicule ;

L’héritage (3/3)

Nouveau type de portée :

• Privé : inaccessible en dehors de la classe, une classe fille ne peut pas accéder aux attributs de la classe mère ;
• Protégé : inaccessible en dehors de la classe sauf pour les classes filles ;

Polymorphisme (1/2)

Polymorphisme: peut prendre plusieurs formes.

Polymorphisme d’héritage :

• Possibilité de redéfinir une méthode dans une classe fille (qui hérite d’une classe mère) : spécialisation ;
• On peut alors appeler la méthode d’un objet sans se soucier de son type en se basant sur la classe mère (ou classe de base) ;

Polymorphisme (2/2)

Un jeu d’échec comporte des objets :

• roi, reine, fou, cavalier, tour et pion ;
• Chacun hérite de l’objet pièce ; 

La méthode déplacement() peut avec le polymorphisme d’héritage effectuer le mouvement de la pièce sans savoir quelle pièce se cache réellement derrière le type de base.

Les methodes et classes abstraites

Une méthode est dite abstraite lorsqu'on connaît son entête, mais pas la manière dont elle peut être réalisée.

Une classe est dite abstraite lorsqu'elle définit au moins une méthode abstraite ou lorsqu'une classe parent contient une méthode abstraite non encore réalisée.

On ne peut instancier une classe abstraite.

Si une classe ne contient que des methodes abstraites, on parle alors d'une interface.

La modelisation objet : la notation U.M.L.

Unified modelling language

Méthodologie orientée objet

Processus :

• Spécification initiale du système;
• Analyse ;
• Conception du système ;
• Conception des classes ;
• Implémentation ;

Spécification initiale

Spécification de l’application entre
analystes métier et utilisateurs.

Analyse

Précise l'objectif du système et non la façondont il sera construit.

Deux modèles :

• Modèle du domaine : description des objets du
  monde réel manipulés par le système ;
• Modèle de l!application : décrit les parties du
  système visibles par l'utilisateur ;

Conception du système

Architecture du système

Conception des classes

Elaboration des objets du domaine et de ceux de l’application avec la même notation.

Choix des structures de données et algorithmes.

Implémentation

Transposition des classes et de leurs relations en concepts propres à un.

langage, une base de données ou une plateforme.

U.M.L.

comment ?

En informatique UML (de l'anglais Unified Modeling Language), ou Langage de modélisation unifié, est un langage de modélisation graphique à base de pictogrammes. Il est utilisé en développement logiciel, et en conception orientée objet. UML est couramment utilisé dans les projets logiciels.

UML est l'accomplissement de la fusion de précédents langages de modélisation objet : Booch, OMT, OOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à présent un standard défini par l'Object Management Group (OMG). La dernière version diffusée par l'OMG est UML 2.5 bêta 2 depuis septembre 20131.

Wikipedia

Historique

• 1991 : première édition de Modélisation et conception orientées objet basée sur OMT, Object Modeling Technique , issue de la R&D de General Electric.
• 1994 : James Rumbaugh rejoint Rational et travaille avec Grady
  Booch à la fusion des notations OMT et Booch.
• 1995 : Ivar Jacobson rejoint Rational et intègre Objectory au travail
  d'unification.
• 1997 : l'OMG (Object Management Group) accepte UML, proposé
  par Rational, comme standard de modélisation objet.
• 2001 : révision par l'OMG d'UML 1.
• 2004 : adoption d!UML 2.0

Les principaux diagrammes

• cas d'utilisation
• séquence
• classes
• objet
• déploiement
• ...

Nous nous interesserons ici aux diagrammes de classes, de séquences et des cas d'utilisation (use case).

Diagramme de cas d'utilisation (use case)

Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une vision globale du comportement fonctionnel d'un système logiciel.

Wikipedia

Cas d'utilisation d'un restaurant

Il permet d'identifier les possibilités d'intéraction entre le système et les acteurs (intervenants extérieurs au système), c'est-à-dire toutes les fonctionnalités que doit fournir le système. Il permet aussi de délimiter le système.

Les acteurs (1/2)

Il représente un élément externe qui intéragit avec le système. Cet élément peut être un utilisateur ou un système tiers (autre ordinateur, autre programme, base de donnée).

Tous les éléments extérieurs qui stimulent le système et tous les éléments extérieurs qui sont utilisés par le système sont représentés par des acteurs.

Les acteurs(2/2)

Il est possible de représenter un acteur sous forme d'un bonhomme comme ci-dessous à gauche ou sous forme d'un classeur comme ci-dessous à droite.

Le cas d'utilisation

Un cas d'utilisation représente une fonctionnalité du système.

Cette fonctionnalité est définie par une action déclenchante, un ou plusieurs déroulements possibles et éventuellement une fin.

Les différents déroulements, aussi appelés scénarios, seront modéliser par des diagrammes de séquence, d'activité ou d'état.

Le cas d'utilisation

Le cas d'utilisation se représente par une ellipse contenant un nom décrivant la fonctionnalité et éventuellement un stéréotype.

Le nom du use case doit se composer d'un verbe à l'infinitif qui décrit une action.

Relations entre acteurs et cas d'utilisation

Une relation d'association est un chemin de communication entre un acteur et un cas d'utilisation.

 Elle est représentée par un trait continu.

Multiplicité

Lorsqu'un acteur peut intéragir plusieurs fois avec un cas d'utilisation, il est possible d'ajouter une multiplicité sur l'association du côté du cas d'utilisation.

Le symbole * signifie "plusieurs".

Acteur principaux et secondaire

Un acteur est qualifié de principal pour un cas d'utilisation lorsque ce cas rend service à cet acteur.

Les autres acteurs sont alors qualifiés de secondaires.

Un cas d'utilisation a au plus un acteur principal.

Le stéréotype << primary >> vient orner l'association reliant un cas d'utilisation à son acteur principal.

Le stéréotype << secondary >> est utilisé pour les acteurs secondaires.

Relations entre cas d'utilisations

Inclusion

L'inclusion « include » : Cela implique obligatoirement l'inclusion d'un cas d'utilisation dans un autre

Extension

• L'extension « extend » : Cela permet éventuellement l'extension d'un cas d'utilisation par un autre
• Le point d'extension : Il est possible de préciser exactement à quel moment une extension est appelée
• La condition d'extension : Il est possible d'ajouter en note sous quelle condition l'extension doit se produire

Heritage

permet de définir la spécialisation d'un cas d'utilisation

Cas d'utilisation d'un dab

Relations entre acteur

Un acteur qui hérite d'un autre acteur hérite de toutes ses associations.

Diagramme de classe

Introduction

Le diagramme de classes est considéré comme le plus important de la modélisation orientée objet, il est le seul obligatoire lors d'une telle modélisation.

le diagramme de classes permet de modéliser les classes du système et leurs relations indépendamment d'un langage de programmation particulier.

Les principaux éléments de cette vue statique sont les classes et leurs relations : association, généralisation et plusieurs types de dépendances, telles que la réalisation et l'utilisation.

Les classes

Elle est représentée par un rectangle divisé en trois à cinq compartiments

1. nom de la class
2. attributs
3. methode
4. futures taches
5. exeptions

Visibility

• Public ou + : tout le monde

• Protected ou # : la classe ou les enfants

• Private ou - : la classe uniquement

• En general les attributs sont privés et les methodes public
• Pour acceder aux attributs on utilise des methodes

Les associations binaires

• Une association binaire est matérialisée par un trait plein entre les classes associées
• Elle peut être ornée d'un nom, avec éventuellement une précision du sens de lecture (▸ ou ◂).
• Quand les deux extrémités de l'association pointent vers la même classe, l'association est dite réflexive.

Association n-aire

Une association n-aire lie plus de deux classes.

Cardinalités

• Comme dans un M.C.D. de merise, nous pouvons preciser des cardinalité aux relations :
  • exactement un : 1 ou 1..1 
  • plusieurs : * ou 0..* ;
  • au moins un : 1..* ;
  • de un à six : 1..6.

Il faut noter que, pour les habitués du modèle entité/relation, les multiplicités sont en UML « à l'envers » (par référence à Merise) pour les associations binaires et « à l'endroit » pour les n-aires avec n>2.

Navigabilité

Il est possible de specifier un sens pour la relation

Deux modélisations équivalentes.

Qualification

• Généralement, une classe peut être décomposée en sous-classes ou posséder plusieurs propriétés.
• Quand une classe est liée à une autre classe par une association, il est parfois préférable de restreindre la portée de l'association à quelques éléments ciblés
• Ces elements sont appelé qualificatif

En bas les diagrammes avec qualificatif

Classe-association

Une classe-association possède les caractéristiques des associations et des classes : elle se connecte à deux ou plusieurs classes et possède également des attributs et des opérations.

• Il n'est pas possible de rattacher une classe-association à plus d'une association
• solution : heritage !

• Hors du cadre de l'entreprise une personne n'est pas superieure à une autre.
• l'association superieur de est donc plus pertinente sur la classe association emploie que sur la classe personne

Association multiple {bag}

• Plusieurs instances d'une même association ne peuvent lier les mêmes objet.
• La contrainte {bag} permet d'autoriser plusieurs paire impliquant les mêmes objets.

Que choisir ?

Si un cours doit pouvoir exister indépendamment d'un lien entre un enseignant et un groupe, il faut utiliser le modèle de droite.

Agregation

• Une agrégation est une association qui représente une relation d'inclusion structurelle.
• Graphiquement, on ajoute un losange vide du coté de l'agrégat

Composition

• également appelée agrégation composite.
• decrit une relation composite
• la destruction de l'objet composite implique la destruction de ses composants.
• Graphiquement, on ajoute un losange plein du coté de la composition

• La destruction du camion entraine la destruction.
• La destruction de l'entreprise n'entraine pas la destruction du camion

Heritage

• L'heritage décrit une relation entre une classe générale (classe parent) et une classe spécialisée (sous-classe).
• Le symbole utilisé pour la relation d'héritage ou de généralisation est une flèche avec un trait plein dont la pointe est un triangle fermé désignant le cas le plus général.

Les propriétés principales de l'héritage sont :

• la classe enfant possède toutes les caractéristiques de ses classes parents, mais elle ne peut accéder aux caractéristiques privées de cette dernière .
• une classe enfant peut redéfinir une ou plusieurs méthodes de la classe parent.
• toutes les associations de la classe parent s'appliquent aux classes dérivées ;
• une instance d'une classe peut être utilisée partout où une instance de sa classe parent est attendue.

• Toute opération acceptant un objet d'une classe Animal doit accepter un objet de la classe Chat.
• En java pas d'heritage multiple (ornythorynque).

Dependance

On parle de dependance lorsqu'une methode de classe, utilise une instance d'une autre classe.

Interface

• Une classe dont toutes les methode sont abstraite est appelée une interface.
• Une classe peut heriter de plusieurs interfaces.
• Graphiquement, cela est représenté par un trait discontinu terminé par une flèche triangulaire et le stereotype « realise ».
• Une classe peut egalement dependre d'une interface.
• On représente cela par une relation de dépendance et le stéréotype « use ».

Diagramme de sequence

Le diagramme de sequence permet d'établir un lien entre les diagrammes de cas d'utilisation et les diagrammes de classes : ils montrent comment des objets communiquent pour réaliser une certaine fonctionnalité. Ils apportent ainsi un aspect dynamique à la modélisation du système.

Les principales informations contenues dans un diagramme de sequence sont les messages échangés entre les lignes de vie, présentés dans un ordre chronologique.

Ligne de vie

Une ligne de vie se représente par un rectangle, auquel est accroché une ligne verticale pointillée, contenant une étiquette dont la syntaxe est :

[<nom_du_rôle>] : [<Nom_du_type>]

Au moins un des deux noms doit être spécifié dans l'étiquette, les deux points (:) sont, quant à eux, obligatoires.

Message

• Un message définit une communication particulière entre des lignes de vie :

  • l'envoi d'un signal.

  • la création ou la destruction d'une instance.

  • invocation d'une operation

L'invocation peut être asynchrone ou synchrone. Dans la pratique, la plupart des invocations sont synchrones, l'émetteur reste alors bloqué le temps que dure l'invocation de l'opération.

Message synchrone

Graphiquement, un message synchrone se représente par une flèche en traits pleins et à l'extrémité pleine partant de la ligne de vie d'un objet expéditeur et allant vers celle de l'objet cible . Ce message peut être suivi d'une réponse qui se représente par une flèche en pointillé (figure ).

Message de creation et de destruction

• La création d'un objet est matérialisée par une flèche qui pointe sur le sommet d'une ligne de vie
• La destruction d'un objet est matérialisée par une croix qui marque la fin de la ligne de vie de l'objet

Message asynchrone

Graphiquement, un message asynchrone se représente par une flèche en traits pleins et à l'extrémité ouverte partant de la ligne de vie d'un objet expéditeur et allant vers celle de l'objet cible

Réponse

Dans la plupart des cas, la réception d'un message est suivie de l'exécution d'une méthode d'une classe

Syntaxe

[<attribut> = ] message [ : <valeur_de_retour>]

où message représente le message d'envoi.

Object actif, Objet passif

Un objet actif (à gauche) et d'une exécution sur un objet passif (à droite).

Execution simultanée

Fragments d'interaction combinés

Un fragment combiné permet de realiser des operations particuliere sur une portion du diagramme, comme par exemple :

• boucle
• condition
• traitement parallele

Il est représenté dans un rectangle dont le coin supérieur gauche contient un pentagone. Dans le pentagone figure le type de la combinaison, appelé opérateur d'interaction.

Diagramme de sequence du demineur

Operateur opt

• L'operateur opt comporte une condition, si celle ci est vraie le sous block est executé
• equivalent du if

Operateur alt

• L'opérateur alternative, ou alt, est un opérateur conditionnel possédant plusieurs opérandes
• Equivalent du switch

Operateur loop

loop[ '('<minInt> [ ',' <maxInt> ] ')' ]

L'operateur loop permet de repeter une partie du diagramme jusqu'a ce qu'une condition booléene doit remplie.

Operateur par

• execute ses sous fragment en parallèle.
• possede au moins deux sous fragment

Diagramme d'activités

Introduction

Les diagrammes d'activités permettent de mettre l'accent sur les traitements. Ils sont donc particulièrement adaptés à la modélisation du cheminement de flots de contrôle et de flots de données.

Les diagrammes d'activités permettent de spécifier des traitements a priori séquentiels et offrent une vision très proche de celle des langages de programmation impératifs comme C++ ou Java.

Noeud d'activité

Un nœud d'activité est un type d'élément abstrait permettant de représenter les étapes le long du flot d'une activité. Il existe trois familles de nœuds d'activités :

Les transitions

UML n'impose aucune syntaxe pour la description d'une activité.

Noeud de controle

Il existe plusieurs types de nœuds de contrôle :

• nœud initial (initial node en anglais) ;
• nœud de fin d'activité (final node en anglais) ;
• nœud de fin de flot (flow final en anglais) ;
• nœud de décision (decision node en anglais) ;
• nœud de fusion (merge node en anglais) ;
• nœud de bifurcation (fork node en anglais) ;
• nœud d'union (join node en anglais).

Un nœud de contrôle est un nœud d'activité abstrait utilisé pour coordonner les flots entre les nœuds d'une activité.

Les différents types de noeud

Exemple de diagramme d'activité illustrant l'utilisation de nœuds de contrôle.

• Noeud initial
  • Un nœud initial est un nœud de contrôle à partir duquel le flot débute lorsque l'activité enveloppante est invoquée.
• Noeud final
  • Un nœud final est un nœud de contrôle possédant un ou plusieurs arcs entrants et aucun arc sortant.
    • Noeud de fin d'activité
    • Noeud de fin de flot

• Noeud de décision
  • Un nœud de décision est un nœud de contrôle qui permet de faire un choix entre plusieurs flots sortants. Il possède un arc entrant et plusieurs arcs sortants ;
  • Ces derniers sont généralement accompagnés de conditions de garde pour conditionner le choix ;
• Noeud de fusion
  • Un nœud de fusion est un nœud de contrôle qui rassemble plusieurs flots alternatifs entrants en un seul flot sortant. Il n'est pas utilisé pour synchroniser des flots concurrents (c'est le rôle du nœud d'union), mais pour accepter un flot parmi plusieurs.

• Noeud de bifurcation
  • Un nœud de bifurcation, est un nœud de contrôle qui sépare un flot en plusieurs flots concurrents. Un tel nœud possède donc un arc entrant et plusieurs arcs sortants. On apparie généralement un nœud de bifurcation avec un nœud d'union pour équilibrer la concurrence ;
• Noeud d'union
  • Un nœud d'union est un nœud de contrôle qui synchronise des flots multiples. Un tel nœud possède donc plusieurs arcs entrants et un seul arc sortant.

Noeud objet

Un noeud objet permet de modeliser le flux de données,

Un flot d'objets permet de passer des données d'une activité à une autre. Un arc reliant un pin de sortie à un pin d'entrée est, par définition même des pins, un flot d'objets

Noeud  tampon central

Exemple d'utilisation d'un nœud tampon central pour centraliser toutes les commandes prises par différents procédés, avant qu'elles soient traitées.

Noeud de stockage de données

Un nœud de stockage des données est un nœud tampon central particulier qui assure la persistance des données.

Partitions

Les partitions n'ont pas de signification bien arrêtée, mais correspondent souvent à des unités d'organisation du modèle.

Illustration de l'utilisation de nœuds d'objets et de partitions dans un diagramme d'activités.

Exception

Une exception est générée quand une situation anormale entrave le déroulement nominal d'une tâche.

Diagramme d'état -transition

Les diagrammes d'états-transitions d'UML décrivent le comportement interne d'un objet à l'aide d'un automate à états finis. Ils présentent les séquences possibles d'états et d'actions qu'une instance de classe peut traiter au cours de son cycle de vie en réaction à des événements discrets

Un automate à états finis est graphiquement représenté par un graphe comportant : 

• des états, matérialisés par des rectangles aux coins arrondis;
• et des transitions, matérialisées par des arcs orientés liant les états entre eux;

un état simple

état

état initial

état final

Etat composite

en version simplifié

Etat historique

Mémorise le dernier état actif

H

Backup

Événement

Un événement est quelque chose qui se produit pendant l'exécution d'un système et qui mérite d'être modélisé.

• clic / touch
• clavier

Événement d'appel

Un événement d'appel représente la réception de l'appel d'une opération par un objet.

Événement de changement

Un événement de changement est généré par la satisfaction (i.e. passage de faux à vrai) d'une expression booléenne sur des valeurs d'attributs.

 when ( <condition_booléenne> )

Événement temporel

Les événements temporels sont générés par le passage du temps. Ils sont spécifiés : 

• de manière absolue (date précise),
• de manière relative (temps écoulé).

Par défaut, le temps commence à s'écouler dès l'entrée dans l'état courant.

Transition

Une transition définit la réponse d'un objet à à un événement. Elle lie, généralement, deux états et indique qu'un objet dans un état E1 peut entrer dans l'état E2 et exécuter certaines activités, si un événement déclencheur se produit et qu'une condition

Transition interne

Les mêmes régles s'appliquent aux transitions internes.

A la difference d'une transition externe, une transition interne ne posséde pas d'état cible, l'état de l'objet ne changent pas à la fin de la transition.

Exemple de transitions interne

Les transitions internes possèdent des noms d'événement prédéfinis correspondant à des déclencheurs particuliers :

• entry : l'activité s'execute lorsque l'on rentre dans l'état ;
• do : s'execute juste aprés entry ;
• exit : s'execute lorsque l'on quitte l'état

Point de choix

Il est possible de représenter des alternatives pour le franchissement d'une transition :

• les points de jonction (représentés par un petit cercle plein);
• les points de décision (représentés par un losange);

   

Points de jonction

Les points de jonction permettent de partager des segments de transition, l'objectif étant d'aboutir à une notation plus compacte ou plus lisible des chemins alternatifs.

Point de decision

Contrairement à un point de jonction, les gardes situées après le point de décision sont évaluées au moment où il est atteint.

Il est possible d'utiliser le mot clef else, sur un des segments en aval d'un point de choix.

c'est même recommandé pour avoir un diagramme bien construit.

Concurence

Exercices

Les outils

Les web app (gratuites ou presque) :

• draw.io
• lucidchart
• gliffy

Cas d'utilisations

Dans un établissement scolaire, on désire gérer la réservation des salles de cours ainsi que du matériel pédagogique (ordinateur portable ou/et Vidéo projecteur).

Seuls les enseignants sont habilités à effectuer des réservations (sous réserve de disponibilité de la salle ou du matériel).

Le planning des salles peut quant à lui être consulté par tout le monde (enseignants et étudiants). Par contre, le récapitulatif horaire par enseignant (calculé à partir du planning des salles) ne peut être consulté que par les enseignants.

Enfin, il existe pour chaque formation un enseignant responsable qui seul peut éditer le récapitulatif horaire pour l’ensemble de la formation.

Exercice 1 L'ecole

Dans un magasin, le processus de vente est le suivant : le client entre, passe dans les rayons, demande éventuellement des renseignements ou procède à des essais, prend des articles (si le stock est suffisant), passe à la caisse où il règle ses achats (avec tout moyen de paiement accepté). Il peut
éventuellement bénéficier d’une réduction.

Exercice 2 Le magasin

Exercice 3 la gestion du stock

Dans un magasin, un commerçant dispose d’un système de gestion de son stock d’articles, dont les fonctionnalités sont les suivantes :

• Edition de la fiche d’un fournisseur ;
• Possibilité d’ajouter un nouvel article (dans ce cas, la fiche fournisseur est automatiquement éditée. Si le fournisseur n’existe pas, on peut alors le créer) ;
• Edition de l’inventaire. Depuis cet écran, on a le choix d’imprimer l’inventaire, d’effacer un article ou d’éditer la fiche d’un article).

Exercice 4 Le D.a.b.

On considère le système suivant de gestion d’un DAB (Distributeur automatique de billets) :

• le distributeur délivre de l’argent à tout porteur de carte (carte Visa ou carte de la banque) ;
• Pour les clients de la banque, il permet :
  • La consultation du solde du compte ;
  • Le dépôt d’argent (chèque ou numéraire) ;
• Toute transaction est sécurisée et nécessite par conséquent une authentification ;
• dans le cas où une carte est avalée par le distributeur, un opérateur de maintenance se charge de la récupérer. C’est la même personne qui collecte également les dépôts d’argent et qui recharge le distributeur.

Diagramme de classes

Le système de fichier est un ensemble de fichiers contenus dans un répertoire racine. Il y a au plus un répertoire racine par système de fichiers. Les répertoires sont des types particuliers de fichiers.
Sous Linux un fichier est toujours désigné par un nom. Il possède un unique inode. Un fichier possède les fonctionnalités suivantes : ouverture, fermeture, lecture, écriture. Il existe plusieurs sortes de fichiers : les fichiers normaux, les répertoires, les liens symboliques, les pseudo-fichiers. Un répertoire peut contenir plusieurs fichiers. Un lien symbolique fait référence à (« pointe vers ») un autre fichier. Un pseudo-fichier est souvent un fichier servant d'interface pour divers périphériques.
Chaque fichier est associé à un unique inode qui contient différentes informations (qu’il n’est pas important de détailler ici). Un utilisateur peut posséder un ou plusieurs fichiers et possède au plus un répertoire « home ». Un nœud ne peut être possédé que par un seul utilisateur. Un utilisateur appartient à au moins un groupe. Un utilisateur est repéré par identifiant d’utilisateur (UID) et un groupe (GID) par un identifiant de groupe.

Exercice 1 Le systeme de fichier

Exercice 2

Définissez la classe UML représentant un étudiant, caractérisé, entre autres, par un identifiant, un nom, un prénom et une date de naissance.

Définissez la classe UML représentant un enseignant, caractérisé, entre autres, par un identifiant, un nom, un prénom et une date de naissance.

Définissez la classe UML représentant un cours, caractérisé par un identifiant, un nom, le nombre d’heures de cours magistral, le nombre d’heures de travaux dirigés et un nombre d’heures de travaux pratiques que doit suivre un étudiant.

Définissez les associations qui peuvent exister entre un enseignant et un
cours.

Définissez la classe UML représentant un groupe d’étudiants en utilisant les associations.

Définissez l’association possible entre un groupe d’étudiants et un cours.

Pensez-vous qu’il soit possible de définir un lien d’héritage entre les classes UML représentant respectivement les étudiants et les enseignants ?

Pensez-vous qu’il soit possible de définir un lien d’héritage entre les classes UML représentant respectivement les étudiants et les groupes d’étudiants ?

On nomme coursDeLetudiant() l’opération permettant d’obtenir l’ensemble des cours suivis par un étudiant. Positionnez cette opération dans une classe, puis précisez les paramètres de cette opération.

On nomme coursDeLenseignant() l’opération permettant d’obtenir l’ensemble des cours dans lesquels intervient un enseignant. Positionnez cette opération dans une classe, puis précisez les paramètres de cette opération.

Expliquer ce diagramme

Positionnez toutes vos classes ( Etudiant , Enseignant ,
GroupeEtudiant ) dans un package nommé Personnel.

Liez vos classes pour faire en sorte qu’un créneau soit lié à un cours.

Étudiants et enseignants sont des personnes caractérisées par un numéro INSEE, un nom, un prénom et une adresse. Chaque enseignant possède de plus un grade et on souhaite mémoriser pour chaque étudiant son année d’étude et le diplôme préparé.

Exercice 3 l'université

Les cours sont organisés en modules caractérisés par un code et un intitulé. Plusieurs enseignants peuvent intervenir dans un module, à une date, une heure et dans une salle données. Un enseignant intervient habituellement dans plusieurs modules. Les étudiants s’inscrivent dans les modules à une date et à une heure données, mais seuls les étudiants qui suivent effectivement le module obtiennent une note moyenne en fin d’année.

Des contrôles sont organisés pour chaque module. Ils sont caractérisés par un numéro de contrôle et une date. Les étudiants ayant effectué le contrôle possèdent une note pour ce contrôle.

Diagramme de sequence

Exercice 1  Le Dab

Le déroulement normal d’utilisation d’un distributeur automatique de billets est le suivant :

• le client introduit sa carte bancaire
• la machine vérifie alors la validité de la carte et demande le code au client
• si le code est correct, elle envoie une demande d’autorisation de prélèvement au groupement de banques. Ce dernier renvoie le solde autorisé à prélever.
• le distributeur propose alors plusieurs montants à prélever
• le client saisit le montant à retirer
• après contrôle du montant par rapport au solde autorisé, le distributeur demande au client s’il désire un ticket
• Après la réponse du client, la carte est éjectée et récupérée par le client
• les billets sont alors délivrés (ainsi que le ticket)
• le client récupère enfin les billets et son ticket

Exercice 2

Pour passer une commande, le client fournit son numéro de téléphone (qui va permettre de l’identifier) et le contenu de sa commande qu’on représente sous la forme d’une liste de couples (nom d’une pizza, quantité).
Le système commence par vérifier que le client existe dans la base des clients et conserve l’objet client qui lui correspond. Le système vérifie ensuite que la commande est faisable (elle peut être fabriquée dans un
Point Pizza qui fait toutes les pizzas spéciales demandées) puis crée la commande dans le système et en indique le numéro et le prix au client. Pour vérifier que la commande est faisable, le système récupère la liste des Points Pizza pour chaque spécialité de la commande puis vérifie que l’intersection de ces listes n’est pas
vide, c’est-à-dire qu’il existe au moins un Point Pizza qui peut satisfaire la commande. C’est une façon de faire un peu naïve, on peut trouver d’autres méthodes. Le système crée ensuite une commande en créant les objets DétailsCommande correspondant à chaque pizza (avec l’attribut état initialisé à enAttente) et en ajoutant chaque couple (pizza,détails) à l’objet commande créé. Il attribue ensuite le client à la commande puis ajoute la commande aux commandes du client. Il conserve l’objet commande créé (quand on crée un objet, on le renvoie nécessairement à celui qui l’a créé) puis il renvoie le numéro et le prix de la commande au client.

Diagramme d'activité

Exercice 1

Construire un diagramme d’activité représentant l’utilisation d’une cafetière électrique:

• premier état: chercher du café
• dernier état: Servir du café

Exercice 2

Pour créer une fiche de réparation, le chef d’atelier saisit les critères de recherche de voitures dans le système. Le logiciel de gestion des réparation lui donne la liste des voitures correspondant aux critères entrés. Si la voiture existe, le chef d’atelier va sélectionner la voiture. Le logiciel va, ensuite, fournir les informations sur le véhicule. Si la voiture est sous garantie, le chef devra saisir la date de demande de réparation. Si la voiture n’existe pas, le chef va saisir les informations concernant  ce nouveau véhicule. Dans tous les cas, le chef d’atelier devra saisir la date de réception et de restitution. Si le dommage de la voiture est payé par l’assurance, le logiciel va fournir une liste d’assurances au chef d’atelier. Ce dernier sélectionnera l’assurance adéquate. Enfin, le logiciel enregistre la fiche de réparation.

Exercice 3 : le gâteau

commencer par casser le chocolat en morceaux, puis le faire fondre. En parallèle, casser les œufs en séparant les blancs des jaunes. Quand le chocolat est fondu, ajouter les jaunes d’œuf.
Battre les blancs en neige jusqu’à ce qu’ils soient bien fermes. Les incorporer délicatement à la préparation chocolat sans les briser. Verser dans des ramequins individuels.
Mettre au frais au moins 3 heures au réfrigérateur avant de servir.

Maintenant si ça n'est pas déjà fait rajouter les nœuds objets.

Diagramme d'état

exercice 2

Réaliser le diagramme d’état d'un radio réveil.

• on peut mettre l'alarme sur on ou off
• quand l'heure courante devient egale à l'heure d'alarme, le reveil sonne.
• on doit pouvoir interompre la sonnerie.

Exercice 2

Réalisez le diagramme d'état d'un dab.

Modélisez le comportement du vidéoprojecteur lors d’une session de formation.

Commencez par identifier les états et transitions nominaux. Ajoutez les périodes de préchauffage et de refroidissement de la lampe. Représentez ensuite le fait qu’il faut appuyer successivement deux fois en moins de 5 s sur le bouton power pour interrompre la vidéoprojection. Envisagez enfin la panne de la lampe…

Ajoutons le comportement suivant : si l’on éteint le vidéoprojecteur sans le déconnecter de sa source, il repassera directement dans l’état Connecté quand on le rallumera. Les deux états Allumé et Connecté intègrent chacun une activité durable : respectivement la projection d’un écran bleu ou de la source d’entrée.

Ajoutons maintenant les activités continues de préchauffage et de refroidissement de la lampe. Il est donc nécessaire d’introduire deux états supplémentaires autour de l’état Éteint.

Comment sortir de ces états supplémentaires : soit en utilisant un évènement de changement (when) testant la température de la lampe, soit plus simplement une transition automatique. Nous utiliserons cette dernière solution, plus simple et n’obligeant pas à spécifier les températures visées.

Pour éviter de perdre trop de temps lors d’un appui intempestif sur power dans l’état Connecté, les vidéoprojecteurs modernes demandent une confirmation sous la forme d’un deuxième appui sur power en moins de 5 s.

la lampe peut griller dès lors que le projecteur n’est pas éteint. Le plus simple consiste à introduire un nouvel état composite à l’intérieur de Branché mais excluant Éteint

Design pattern

Etude de cas : Le Démineur

Le jeu est composé d’un plateau rectangulaire, d’un chronomètre et d’un compteur de mines. Le plateau est un quadrillage de cases. Au début du jeu, toutes les cases du plateau sont couvertes, le compteur de mines indiquant le nombre de mines restant à localiser. Le chronomètre compte le nombre de secondes écoulées depuis le début de la partie. La partie commence lorsque la première case est découverte.

Quand une case est découverte, son contenu est affiché. Le contenu d’une case peut être : rien, une mine ou un nombre indiquant le nombre de mines présentes dans les cases voisines. Les scénarios suivants peuvent se produire lorsqu’une case est découverte, en fonction de son contenu :

• Un chiffre : Il ne se passe rien.
• Un blanc : Toutes les cases voisines sont dévoilées, à condition qu’elles ne soient pas
  signalées par un drapeau. Si l’une de ces cases voisines ne contient rien, le processus
  de découverte continue automatiquement à partir de cette case.
• Une mine – Le jeu est terminé et le joueur a perdu.

Si elle est toujours couverte, une case peut être marquée en respectant les règles suivantes :

• Marquer une case qui n’est ni découverte ni marquée décrémente le compteur de mines restant à localiser et un drapeau apparaît sur la case. Il indique que cette case contient potentiellement une mine. Une case marquée d’un drapeau ne peut pas être découverte ;
• Marquer une case déjà signalée d’un drapeau permet de la remettre dans son état
  initial, à savoir couverte et non marquée. Le compteur de mines est alors incré-
  menté de 1.

Développez un diagramme de cas d’utilisation pour le jeu de démineur.

diagramme de use case

Développez un diagramme de séquence système pour le cas d’utilisation "Jouer une partie de démineur".

Diagramme de sequence globale

Realisez un diagramme de classe.

Diagramme de classes

Diagramme d'etat d'une case

Realisez le diagramme de sequence

La solution consite à utiliser un design-pattern etat pour modeliser l'etat de la case.

Diagramme de sequence final

On pourrait egalement utiliser le pattern singleton pour la classe partie afin de n'avoir qu'une seule instance à la fois.

Correction

Diagramme de Cas d'utilisation

L'école

Diagramme de classes

Exercice 1

Exercice 2

Diagramme de sequence

Diagramme d'activité

Diagramme d'état

Introduction aux Design-Patterns

Quelqu’un a déjà résolu vos problèmes.

Dans ce chapitre, nous allons voir comment (et pourquoi) exploiter l’expérience et les leçons tirées par d’autres développeurs qui ont déjà suivi le même chemin, rencontré les mêmes problèmes de
conception et survécu au voyage.

Qu'est ce qu'un design pattern

• Solution empirique pour résoudre un probléme identfié et partagé.
• Apparu à la fin des années 70.
• independant du language.
• s'applique aux languages orientés objet.

Gang of four (gof)

Ce "gang" est composée de 4 developpeur qui sont les auteurs d'un ouvrage de reference : 

"Design Patterns: Elements of Reusable Object-Oriented Software"

• Erich Gamma
• Richard Helm
• Ralph Johnson
• John Vissides

Dans cet ouvrage il detaille 22 patrons de conception qui permettent de repondre à des problématique claires.

Les principaux pattern

Les design pattern sont regroupés en trois categorie :

• pattern createur
• pattern structurel
• pattern comportementaux

​Utilisé pour construire des objets découplés du systéme

• Factory
• Builder
• Singleton
• Prototype
• ...

Pattern createur 

Rend le système indépendant de la manière dont les objets
sont créés, composés et représentés.

Permet de préciser  QUOI (l’objet), QUI (l’acteur), COMMENT (la manière) et QUAND (le moment) de la création.

Factory

Ce pattern est à utiliser dans les situations où existe le besoin
de standardiser le modèle architectural pour un ensemble
d’applications, tout en permettant à des applications
individuelles de définir elles-mêmes leurs propres objets à
créer.

• Avantage : Elimination du besoin de code spécifique à l’application dans le code du framework ; 
• Desavantage : Multiplication du nombre de classes ;

Nous definissons une interface pour la creation d'un objet, mais nous deleguons l'instanciation de cette classe à une autre.               

Singleton

le but de ce pattern est d'avoir une seule instance d’une classe et pouvoir
l’accéder et la manipuler facilement

Pattern singleton

Pattern structurel

Abstraction de la manière dont les classes et les objets sont composés pour former des structures plus importantes.

• Proxy
• Decorator
• Facade
• ...

Pattern comportementaux

Permet de gerer des relations entre objet independament du type d'objet.

• Iterator
• Strategie
• Observer
• ...