Etude de Cas SI d ’un bureau d ’étude Hydraulique

Présentation au sujet: "Etude de Cas SI d ’un bureau d ’étude Hydraulique"— Transcription de la présentation:

1 Etude de Cas SI d ’un bureau d ’étude Hydraulique
UNESP/FEG/DEE 02/04/2017 Etude de Cas SI d ’un bureau d ’étude Hydraulique Michel TOLLENAERE professeur laboratoire GILCO Dominique RIEU Professeur laboratoire LSR/équipe SIGMA Eric BLANCO Maître de Conférence laboratoire GILCO Khadidja GREBICI doctorante laboratoires GILCO / LSR. ã (c) JCFJ

2 Conception de Systèmes d ’Information
UNESP/FEG/DEE 02/04/2017 Conception de Systèmes d ’Information Cours : Systèmes d ’Information Michel TOLLENEAR Dominique RIEU. ã (c) JCFJ

3 Notion de modèle Qu’est ce qu’un modèle ? (Minsky 1968) Observateur
UNESP/FEG/DEE 02/04/2017 Notion de modèle Qu’est ce qu’un modèle ? (Minsky 1968) A* est un modèle de A pour un observateur O ssi A* aide O à répondre aux questions qu’il se pose sur A. Observateur Modèle Système observé Où sont construites les ailes ? ã (c) JCFJ

4 UNESP/FEG/DEE 02/04/2017 notions de base: objet, acteur, collaboration, activité, Evénements, scénarios, états… Objet: entité d ’un monde réel ou virtuel, capable de sauvegarder un état (une information) et qui offre des opérations (un comportement) pour observer ou modifier cet état. Acteur: classe d ’utilisateur du système, personne physique ou morale, entité fonctionnelle ou organisationnelle. Activité: opération interruptible exécutée durant un état zone d ’activités Collaboration: interaction entre objets collaborants. Relation: dépendance entre entités. Paquetage: partition du modèle. Cas d ’utilisation: manière dont les acteurs utilisent le système. la notion d ’objet regroupe les structures de données et traitement. ã (c) JCFJ

5 UNESP/FEG/DEE 02/04/2017 notions de base: objet, acteur, collaboration, activité, Evénements, scénarios, états… Un événement est un stimuli externe visible, avec ses réponses. On commence la modélisation dynamique par l'extraction d'un résumé des séquences d'événements ; pour chaque objet il faut établir un diagramme d'états avec les événements entrants et sortants et qui montre les interactions entre objets. On n'établit pas d'algorithme, ce qui relève de l'implantation, si l'événement n'est pas externe. Ces diagrammes sont essentiels pour les systèmes interactifs, contrairement aux systèmes statiques comme les Bases de Données. Il faut aussi noter qu'ils ne sont pas suffisants pour les systèmes temps réel. Un scénario est une séquence type d'événements, il permet de décrire les interactions courantes pour l'extraction des événements et l'identification des objets cibles. Le suivi des séquences et des états permet d'établir les diagrammes d'états et de les comparer afin d'obtenir la correspondance événement-objet. L'ensemble des diagrammes d'état définit le modèle dynamique. Un état est une abstraction des valeurs des attributs et des liens d'un objet. Ces valeurs sont groupées selon les propriétés qui affectent le comportement de l'objet. Il faut établir, pour chaque objet non trivial un diagramme d'états qui décrit ses événements d'entrées et de sortie. Un scénario correspond à un chemin dans un tel diagramme. Pour ce faire il faut considérer un objet unique et ses interactions type, ce qui définit un chemin constitué d'un ensemble d'arcs étiquetés par les événements d'une colonne du suivi. L'intervalle entre deux événements correspond à une activité continue ou qui prend du temps ; c'est un état, représenté par un noeud et auquel on peut donner un nom si nécessaire. La modification d'un état par un événement donne lieu à une transition. ACTIVITE CHOMAGE Plus de 60 ans Perte d ’emploi recrutement RETRAITE EXEMPLE ã (c) JCFJ

6 Axes de modélisation d ’un système
UNESP/FEG/DEE 02/04/2017 Axes de modélisation d ’un système Statique (ce que le système EST) diagramme de classes diagramme d’objets diagramme de composants diagramme de déploiement Dynamique (comment le système EVOLUE) Fonctionnel (ce que le système FAIT) diagramme de séquence diagramme de collaboration diagramme d’états-transitions diagramme d’activités diagramme de cas d’utilisation diagramme de collaboration diagramme FAST ã (c) JCFJ

7 Révision UML UML: Définition UML: Bibliographie et sites. UML: Genèse
UNESP/FEG/DEE 02/04/2017 Révision UML UML: Définition UML: Bibliographie et sites. UML: Genèse pourquoi UML? UML, modèles et diagrammes, parcours général Les Données : diagramme de classes - structure statique Organiser les documents : les packages Analyser par les Cas d’Utilisation Compléments sur les langages et concepts ã (c) JCFJ

8 analyse et conception orientée objet une notation
UNESP/FEG/DEE 02/04/2017 langage semi formel analyse et conception orientée objet une notation une méthode: « the Unified Software Development Process outils : rational Rose, objecteering... ã (c) JCFJ

9 UNESP/FEG/DEE 02/04/2017 Bibliographie « MODELISATION OBJET AVEC UML » P.Muller N.Gaertner, Editions Eyrolles - mars 2000 « UML EN Action : de l’analyse des besoins à la conception en Java » P.Roques F.Vallée, Editions Eyrolles - février 2000 «Advanced Object-Oriented Analysis & Design Using UML», Odell J., SIGS Publications, 1997. « UML DISTILLED : A Brief Guide to the Standard Object Modeling Language » M.Fowler K.Scott, Addison & Wesley - août 1999 « LE GUIDE DE L’UTILISATEUR UML » G.Booch I.Jacobson J.Rumbaugh, Editions Eyrolles - février 2000 « LE PROCESSUS UNIFIE DE DEVELOPPEMENT LOGICIEL » I.Jacobson G.Booch J.Rumbaugh, Editions Eyrolles - juin 2000. « UML POUR L’ANALYSE D’UN S.I. : Le cahier des charges du maître d'ouvrage » C.Morley J.Hugues B.Leblanc, Dunod - février 2000 « Business Modeling with UML : Business Patterns at work » H.Eriksson M.Penker Wiley & Sons - janvier 2000 « Concevoir des application Web avec UML » , J.Conallen, Eyrolles, sept 2000 ã (c) JCFJ

10 UNESP/FEG/DEE 02/04/2017 Bibliographie « Unified Modeling Langage Reference Manual », J.Rumbaugh I.Jacobson G.Booch, Addison-Wesley, 1998. « UML en Action », Pascal Rocques, Vallée F , Eyrolles, 2000. ã (c) JCFJ

11 Des sites... Des sites en français Des sites industriels
UNESP/FEG/DEE 02/04/2017 Des sites... Des sites en français // (site de mulhouse) //free.uml.fr/ Des sites industriels // // // Des livres sur UML répertoriés par // ã (c) JCFJ

12 Genèse d’UML Révision Révision Mineur Novembre : Acceptation
UNESP/FEG/DEE 02/04/2017 Genèse d’UML Révision UML 2.0 2002 Révision Mineur UML 1.4 2000 UML 1.3 UML 1.2 1999 1998 Novembre : Acceptation Septembre : soumission final Janvier : soumission OMG UML 1.1 UML 1.0 1997 1997 UML 0.9 1996 80-90: apparition de plusieurs méthodes : Méthodes systémiques et des méthodes cartésiennes, capacité à modéliser des objets complexes. OOA: Objects Oriented Analysis (Peter Coad & Edward Yourdon). OMT: Objects Modeling Technique (James Rumbaugh). «  objet acteurs: qui requièrent des opérations mais n ’en offrent pas. objets serveurs: qui offrent des opérations mais n ’en requièrent pas. objets agents: qui offrent et requièrent des opérations. » Jacobson: objets entités, objets interfaces, objets contrôleurs. OOM: Merise Object: A.Rochfeld,…Y.Tabourier,…D.Nanci.. 90-95:+ de 50 méthodes orientées objet. 95: premières version UML 97: standardisation OMG (Object Management Groupe) 2000: UML 1.4 2002: UML2.0 Spécification sur internet Méthode unifiée 0.8 1995 Autres Méthodes OOAD Booch OMT Rumbaugh... OOSE Jacobson... Partenaires ã (c) JCFJ

13 Pourquoi UML ? Besoin d’un Langage de Modélisation
UNESP/FEG/DEE 02/04/2017 Pourquoi UML ? Besoin d’un Langage de Modélisation notation claire des diagrammes de modèles variés/points de vue flexibilité unificateur Besoin d’un Processus de Modélisation (dirigé par les cas d’utilisation) modèles et vues intégrant l’architecture itératif et incrémental non standard mais à ADAPTER... Pour Documenter les besoins l’architecture la conception le codage, les tests.... Dans X Environnements de systèmes à support logiciels : SI de l’entreprise Systèmes bancaires, financiers Télécoms, transports Aérospatiale, scientifique Électronique, médical Services Web ã (c) JCFJ

14 UML, Modèles et Diagrammes Parcours Général
UNESP/FEG/DEE 02/04/2017 UML, Modèles et Diagrammes Parcours Général ã (c) JCFJ

15 Un Modèle = Un point de vue sur le système
UNESP/FEG/DEE 02/04/2017 Un Modèle = Un point de vue sur le système Modèle de Classes qui capture la structure statique Modèle des Cas d’Utilisation – Use Case, UC – qui décrit les besoins, les fonctions Modèle d’Interaction qui représente les scénarios et les flots de messages Modèle des États qui exprime le comportement dynamique des objets, classes... Modèle de Réalisation qui montre des unités de travail Modèle de Déploiement qui précise la répartition des processus Descriptions abstraites pour capturer la sémantique d’un système les modèles sont regardés et manipulés au moyen de vues graphiques, véritables projections... à chaque vue correspond un ou plusieurs diagrammes… 2 catégories de modèles : - Modèles dynamiques: décrit l ’évolution et comportement des objets et modification des états des objets suite aux réceptions de messages . -Modèle d ’objets: décrit la structure et les liens statiques , montre les objets et leurs liens. ã (c) JCFJ 9

16 Diagrammes ã Diagrammes Classes Objets Séquence Collaboration
UNESP/FEG/DEE 02/04/2017 Diagrammes Diagrammes Classes Objets Séquence Collaboration Activités Cas d'Utilisation États-Transitions Composants Déploiement ã (c) JCFJ

17 ã lien d’héritage : «est un diagramme»,
UNESP/FEG/DEE Diagrammes 02/04/2017 lien d’héritage : «est un diagramme», chacun est une spécialisation de la classe diagramme Diagrammes Classes Objets Séquence Collaboration Activités Cas d'Utilisation États-Transitions Composants Déploiement Un diagramme est un « langage graphique » de phrases traduisant entre les concepts « éléments du vocabulaire du diagramme », icônifiés aux nœuds des relations matérialisées par des arcs du graphe, écrits avec un forme particulière. L’ensemble donne la syntaxe, graphique du langage associé ã (c) JCFJ

18 Aspects structurels statiques
UNESP/FEG/DEE Diagrammes 02/04/2017 Diagrammes Classes Objets Séquence Collaboration Activités Cas d'Utilisation États-Transitions Composants Déploiement Ce que le système EST Aspects structurels statiques diagramme de classes : classes et relations statiques diagramme des objets : objets et liens Aspects fonctionnels et dynamiques diagramme de cas d’utilisation : acteurs et utilisation du système Ce que le système FAIT ã (c) JCFJ

19 UNESP/FEG/DEE Diagrammes 02/04/2017 Diagrammes Classes Objets Séquence Collaboration Activités Cas d'Utilisation États-Transitions Composants Déploiement Aspects dynamiques diagramme de séquence : vision temporelle des interactions diagramme de collaboration : vision spatiale des interactions diagramme d’états-transitions : comportement des objets diagramme d’activités : flot de contrôle interne aux opérations comment le système EVOLUE ã (c) JCFJ

20 UNESP/FEG/DEE Diagrammes 02/04/2017 Diagrammes Classes Objets Séquence Collaboration Activités Cas d'Utilisation États-Transitions Composants Déploiement Aspects implantation diagramme de composants : codage diagramme de déploiement : implantation, distribution Les diagrammes des classes physiques participant aussi à cette description ã (c) JCFJ

21 Organiser les documents, Les Packages
UNESP/FEG/DEE 02/04/2017 Organiser les documents, Les Packages ã (c) JCFJ

22 UNESP/FEG/DEE 02/04/2017 Structurer : Package Unité de stockage d’un ensemble d’informations variées ayant trait à une même unité d’information pour l’application modélisée. Appliqué selon plusieurs points de vue : Pkg-projet Pkg-exigences Pkg-analyse Pkg-maintenance Pkg-conception «trace» Pkg-réalisation «realise» package exigences package analyse package conception package réalisation package maintenance Packetage veut dire partition du modèle. Vue cycle de développement ã (c) JCFJ

23 UNESP/FEG/DEE Structurer : Package 02/04/2017 Graphisme Chaque package peut avoir divers modèles (UC, Classes, textes, ….) lesquels constituent une unité de documentation pour le niveau auquel on se trouve…. Analyse Conception Réalisation ã (c) JCFJ

24 Analyser par les Cas d’Utilisation, Cas d’Utilisation,
UNESP/FEG/DEE 02/04/2017 Analyser par les Cas d’Utilisation, Cas d’Utilisation, Scénarios : Collaborations et Séquences ã (c) JCFJ

25 Diagrammes de Cas d’Utilisation
UNESP/FEG/DEE 02/04/2017 Diagrammes de Cas d’Utilisation Un CU est : une réponse à la question « dans quel cas tel acteur utilise-t-il le système?. C ’est un ensemble d ’interactions entre acteur et système. une technique d ’expression des besoins mise en œuvre par Ivar Jacobson (objectory). une manière spécifique d’utiliser un système représenté dans un diagramme de CU faisant référence aux acteurs, i.e: « choses » externes au système qui communiquent avec ce dernier (principaux, secondaires, matériels ou non) et aux relations (communication, utilisation, extension) de propriétés : - exclusivité les uns des autres, le système est dans une situation donnée pour un acteur donné et à un instant donné. - couverture d ’une utilisation complète depuis la connexion jusqu ’à la déconnexion. L’analyse d’un cas d’utilisation par des scénarios : Diagrammes de Collaboration (modèles organisationnels) Diagrammes de Séquence (modèles chronologiques) pour des regroupements et la mise en évidence des objets et des cas d’utilisation Communication entre acteurs et cas: dans un diagramme de cas d ’utilisation l ’accent est mis sur le rôle et non pas sur le type réel des objets en relation avec le système. Il est quelque fois judicieux d ’indiquer les informations (qui deviendront des objets dans le développement) échangées entre acteurs et système, par rapport au cas. Il est possible d ’utiliser des mécanismes communs tels que les étiquettes, contraintes ou notes. ã (c) JCFJ

26 Modéliser le comportement d’un :
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation 02/04/2017 Modéliser le comportement d’un : élément, système, sous-système, classe. Un acteur fait avec le système qui lui offre ce service : « un client fait un virement » Ce que fait l’élément et NON Comment il le fait « généralise » Identification Client Virement <<include>> Client distant Virement minitel ã (c) JCFJ

27 Exemple1 : Réserver sur un vol à une date donnée
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation 02/04/2017 Exemple1 : Réserver sur un vol à une date donnée Le client interroge le système, soit en passant dans une agence, soit par un système télé-informatique (minitel ou internet) pour s’assurer de pouvoir faire la réservation souhaitée. La réservation peut concerner un déplacement de passagers (un ou plusieurs) ou une demande de transport de fret. Une solution réalisable étant trouvée, il enregistre la réservation (nom des passagers ou volumes et caractéristiques du fret) et paye par le moyen adapté à l’environnement (liquide, chèque, carte de crédit). Le ou les billets correspondants lui sont délivrés (directement, à l’agence, par la poste, par mise à disposition à l’aéroport pour télépayement ou aussi par impression de bons de transports sur connexion internet. une note est attachée à tout UC, pour définir son rôle et son contenu Client Réserver ã (c) JCFJ

28 Exemple 1 – Requirements
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation 02/04/2017 Exemple 1 – Requirements (Système) RESERVER Interroger au guichet Interroger possibilité-vol Interroger par le net Généralisation/spécialisation selon les « modes d ’accès » Client Vue analyse des besoins : un acteur, le client Le diagramme d’UC du package RESERVER, décompose l ’UC RESERVER ã (c) JCFJ

29 ã Vue analyse des besoins
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation – Exemple 1 : Requirements 02/04/2017 (Système) RESERVER Interroger au guichet Interroger possibilité-vol Interroger par le net enregistrer réservation Client Vue analyse des besoins ã (c) JCFJ

30 ã Spécialisation par l’objet du transport Vue analyse des besoins
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation – Exemple 1 : Requirements 02/04/2017 (Système) RESERVER Interroger au guichet Interroger possibilité-vol Interroger par le net Spécialisation par l’objet du transport enregistrer réservation enregistrer fret Client enregistrer passagers Vue analyse des besoins ã (c) JCFJ

31 ã Vue analyse des besoins
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation – Exemple 1 : Requirements 02/04/2017 (Système) RESERVER Interroger au guichet Interroger possibilité-vol Interroger par le net enregistrer réservation enregistrer fret Client payer enregistrer passagers Vue analyse des besoins ã (c) JCFJ

32 ã Vue analyse des besoins les liens d’activation du système
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation – Exemple 1 : Requirements 02/04/2017 (Système) RESERVER Interroger au guichet Interroger possibilité-vol Interroger par le net enregistrer réservation enregistrer fret Client payer enregistrer passagers obtenir billets Vue analyse des besoins les liens d’activation du système ã (c) JCFJ

33 Vue Analyse (raffinement)
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation 02/04/2017 Exemple 1 – Analyse (Système) RESERVER Interroger au guichet Généralisation/spécialisation selon les « modes d ’accès » Interroger possibilité-vol Gestionnaire des vols Interroger par le net Gestion interface Sous-systèmes externes Client Vue Analyse (raffinement) spécification ã (c) JCFJ

34 ã Spécialisation par l’objet du transport Vue Analyse
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation – Exemple 1 : Analyse 02/04/2017 (Système) RESERVER Interroger au guichet Interroger possibilité-vol Gestionnaire des vols Interroger par le net Spécialisation par l’objet du transport Gestion interface enregistrer fret enregistrer réservation enregistrer passagers Client Vue Analyse ã (c) JCFJ

35 ã Vue Analyse Diagrammes de Cas d’Utilisation – Exemple 1 : Analyse
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation – Exemple 1 : Analyse 02/04/2017 (Système) RESERVER Interroger au guichet Interroger possibilité-vol Gestionnaire des vols Interroger par le net Gestion interface enregistrer fret enregistrer réservation enregistrer passagers payer Gestionnaire financier Client Vue Analyse ã (c) JCFJ

36 ã des acteurs secondaire des acteurs secondaires principal Vue Analyse
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation – Exemple 1 : Analyse 02/04/2017 (Système) RESERVER Interroger au guichet des acteurs Interroger possibilité-vol Gestionnaire des vols Interroger par le net secondaire Gestion interface enregistrer fret des acteurs secondaires enregistrer réservation enregistrer passagers principal payer Gestionnaire financier Client obtenir billets Vue Analyse ã (c) JCFJ

37 Extension : Systèmes Évolutifs
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation 02/04/2017 Extension : Systèmes Évolutifs Interroger possibilité-vol Consulter les promotions Interroger par le net <<extend>> relation d’extension : une évolution demandée avec indication de l’endroit où elle vient s’insérer extension points : commande complémentaire - les bonnes occases- après rechercher un vol. ã (c) JCFJ

38 Système de Réservation
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation 02/04/2017 Exemple 1 – Conception Système de Réservation ss-système Gérer-réservation Télé-système Agence <<realize>> <<include>> Valider la commande <<include>> Réserver Agent-réservation Enregistrer <<include>> demande <<include>> Client Éditer billet Gérer Enregistrer Enregistrer paiements passager fret ã (c) JCFJ

39 Relations dans les Diagrammes d’UC
UNESP/FEG/DEE Diagrammes de Cas d’Utilisation 02/04/2017 Relations dans les Diagrammes d’UC Pas de Composition-Décomposition: (pour le raffinement) mais un UC se décrit en détail à travers un package associé à l ’UC à détailler et décrit par des diagrammes d’UC définissant le contenu du package. Inclusion « include »: (pour la réutilisation) A inclut B & l’utilise  relation de dépendance entre UC d’un même diagramme; l’UC, inclus, peut être réutilisé dans d’autres diagrammes ; (exemple type : Réserver, Éditer billet) Extension « extend »: (pour l’extensibilité) B étend A, en ...  relation de dépendance entre UC d’un même diagramme; l’UC, qui « étend », doit avoir un point d’insertion dans l’UC « étendu » ; (exemple : « Consulter les promotions ») Généralisation : (pour les mécanismes d’héritages et de versions) relation hiérarchique (une spécialisation assure la fonction de l’UC parent) qui permet d’avoir plusieurs environnements pour le même objectif. (exemple : Interroger possibilité-vol et Interroger par le net…) Lorsque la description textuelle fait apparaître des interactions communes à plusieurs cas. Pour éviter la ré-écriture. Cas d'utilisation A Cas d'utilisation B <<include>> Permettre d ’étendre les interactions et donc les fonctionnalités décrites par les interactions typique d ’une situation optionnelle. Cas d'utilisation B Cas d'utilisation A <<extend>> Les relations entre cas d ’utilisation: ce sont des relations entre ensembles d ’interaction et ne représentent pas une décomposition fonctionnelle c ’est juste pour organiser les interactions. Sans oublier entre les niveaux les dépendances de « trace » ou « réalisation »... ã (c) JCFJ

40 Diagrammes d’Interaction
UNESP/FEG/DEE 02/04/2017 Diagrammes d’Interaction Ensemble des objets, acteurs, systèmes qui collaborent pour contribuer à la réalisation d’un U.C. A l’expression d’une collaboration est associé un diagramme de collaboration qui met en évidence les parties de système, acteurs et objets collaborants Deux Types : Collaboration ou Séquences ã (c) JCFJ

41 Diagrammes de Collaboration
UNESP/FEG/DEE 02/04/2017 Diagrammes de Collaboration Modéliser les Flux de Contrôle Utilisé pour décrire des scénarios du modèle : formes de séquences des vies relationnelles des objets Utilisé pour décrire les interactions entre objets ensembles de messages échangés entre les objets, liens créés par ces échanges et leurs successions et/ou alternatives messages (orientés), flux de données Syntaxe d’un OBJET joël:ETUDIANT Collaboration englobe 2 types de construction : un contexte composé d ’une description de la structure statique des objets et une interaction représenté par une séquence de messages échangés par les objets. Ces diagrammes expriment à la fois le contexte d ’un groupe d ’objets (à travers les objets et les liens) et les interactions entre ces objets (par la représentation des messages). Les diagrammes de collaboration sont des extensions des diagrammes d ’objets. Ces diagrammes montrent des cas particuliers des comportements au sein d ’un cas d ’utilisation. objet, nommé 1-objet pas de classe associée 1-objet: :ETUDIANT l ’objet, nommé Joël de la classe ETUDIANT un objet anonyme de la classe étudiant ã (c) JCFJ

42 Un Use Case est un « classifier », unité de regroupement, de Scénarios
UNESP/FEG/DEE Diagrammes de Collaboration 02/04/2017 f : Gestionnaire financier b : Billets 7: éditer réservation c : Client r : Réserve 8: demander billet : Gestion interface 1: demander réservation 2: réserve 3: réservation possible 4: évaluer réservation 5: afficher prix à payer 6: payer 9: m à dispo-billet Exemple : Ce scénario traduit ce qui se passe quand tout est OK  à étudier, les autres cas : pas de “vol” et pas de “place” Dans ce modèle, on ne se préoccupe pas de l’aspect “gestion d’interface-client”, serveur d’agence ou de télécommunication, gestionnaire du dialogue, qui serait seul à communiquer avec les sous-systèmes du système de réservation. C’est ici une vue purement “fonctionnelle” Séquencement chronologique sans notion d’écoulement de temps Message action : Verbe Chaque message crée un lien entre les objets, une relation entre leurs classes Un Use Case est un « classifier », unité de regroupement, de Scénarios ã (c) JCFJ

43 Exprimer une alternative :
UNESP/FEG/DEE Diagrammes de Collaboration 02/04/2017 Exprimer une alternative : 1 : demander réservation c : Client r : Réserve 2.0 [choix = OK]: confirme-réservation 2.0 [non(choix = OK)]: propose-alternatives 2.1 [non(choix = OK)]: choisir-alternative 2.2 [non(choix= OK)] : confirme-alternative Même numéro de séquence de l’action suivie d’une condition. Pour la cohérence du modèle, il faut que les conditions soient exclusives et totalement définies, mais rien dans les outils ne valide cela, pour l’instant Pour la lisibilité, il est souvent opportun de multiplier les modèles descriptifs chacun d’une situation, càd d’un scénario pour le cas « normal » et les exceptions ã (c) JCFJ

44 Modéliser les Flux de Contrôle selon le Temps
UNESP/FEG/DEE 02/04/2017 Diagramme de Séquence Modéliser les Flux de Contrôle selon le Temps Utilisé pour modéliser des scénarios du modèle entre des objets Utilisé pour décrire les interaction entre objets selon un point de vue temporel : ensembles d’opérations échangées entre les objets, liens, messages (orientés) séquencement chronologique avec la notion de “vie de l’objet” écoulement du temps vertical/échange de message horizontal avec du parallélisme d’existence, des alternatives ... Deux utilisations : documentation des cas d’utilisation (événements, ...) représentation précise des interactions entre objets (messages, ...) Messages synchrones, asynchrones, délai de transmission, contraintes temporelles... Création, destruction d’objets / durée d’activation d’un objet / boucles, conditionnelles Utilisé aussi pour documenter la dynamique des processus au niveau de la conception physique du système Pas de contexte d ’objets. Pas de distinction entre le flot de contrôle et le flot de données. Le diagramme de séquences est un diagramme d ’interaction qui montre des cas particuliers de comportement au sein d ’un cas d ’utilisation (comme le diagramme de collaboration). Pour les utilisations du diagramme de séquences: - diagramme de haut niveau sans détailler les messages, ils sont exprimés en langage naturel - diagramme détaillé; usage informatique, toute forme de communication: appel à procédure, événement discret, signal entre flot d ’exécution. Message synchrone: l ’émetteur est bloqué, il doit attendre la réponse du destinataire message asynchrone: l ’émetteur n ’est pas bloqué. Délai de transmission: délai de propagation. Contrainte temporelle: lorsque la propagation d ’un message prend un temps significatif par rapport à la dynamique du système , les instants d ’émission et de réception de messages sont matérialisés par un couple (nom, nom prime). ã (c) JCFJ

45 ã :Unobjet :autreobjet :Unobjet Message asynchrone création
UNESP/FEG/DEE Diagrammes de Séquence 02/04/2017 :Unobjet :autreobjet Message asynchrone Retour explicite :Unobjet :autreobjet X création destruction :Unobjet :autreobjet Message synchrone Retour implicite ã (c) JCFJ

46 Un dual du diagramme de collaboration avec insistance sur le temps
UNESP/FEG/DEE Diagrammes de Séquence 02/04/2017 Exemple : c : Client r : Réserve f : Gestionnaire financier b : Billets : Gestion interface demander billet éditer réservation demander réservation réserve réservation possible évaluer réservation afficher prix à payer payer m à dispo-billet Un dual du diagramme de collaboration avec insistance sur le temps ã (c) JCFJ

47 Syntaxe Entête des colonnes : Message : deux types
UNESP/FEG/DEE Diagrammes de Séquence 02/04/2017 Syntaxe Entête des colonnes : Objets Acteur, si il est acteur de l’UC dont le DS est un scénario (rattachement) Message : deux types message synchrone : A attend la réponse de B message asynchrone : A envoie un signal et ne s’en occupe plus Alternatives entre les mêmes objets A B ã (c) JCFJ

48 UNESP/FEG/DEE 02/04/2017 Diagrammes de Classes – Données Classes, Attributs, Opérations, Associations, Agrégation, Composition, Héritage ã (c) JCFJ

49 UNESP/FEG/DEE 02/04/2017 Classes - Propriétés Les classes : ensemble d’objets ayant les mêmes attributs, les mêmes opérations, les mêmes relations et la même sémantique Représentation graphiques Vol numVol hdep har définir-périodes() définit la desserte d’une ligne (ville de départ, ville d’arrivée) selon un horaire donné nom de classe (unique) attributs, typés ou non, simples ou multiples, avec valeur initiale éventuelle opérations() avec ou sans leurs paramètres Responsabilités : représentées comme une note ou dans la doc de la classe Une classe peut être présentée sans ses attributs e/ou sans ses opérations. ã (c) JCFJ

50 Classes - Instances Donc, il faut « classer », càd,
UNESP/FEG/DEE 02/04/2017 Classes - Instances « instancie » Grenoble-Paris1 :VOL GREPA01 5h37 6h41 Paris-Grenoble1 :VOL PAGRE01 7H15 8H20 Vol numVol hdep har définir-périodes() Une classe = un type + un conteneur d’objets de ce type Donc, il faut « classer », càd, reconnaître les familles d’éléments, « ensembles » cohérents leur rôle, « responsabilité » les données associées « attributs » les actions que font les éléments « actifs » les actions que l’on fait sur les éléments « passifs » les « signaux » qu’ils envoient les « opérations » ã (c) JCFJ

51 Responsabilités Utiliser en phase d’analyse de besoins
UNESP/FEG/DEE Diagrammes de Classes 02/04/2017 Responsabilités Utiliser en phase d’analyse de besoins pour décrire le rôle des objets de la classe par rapport à l’environnement pour se concentrer sur le « pourquoi » avant d’aborder les structures : attributs mettre en évidence les relations fonctionnelles pour l’utilisateur Concerne particulièrement les «objets clients» un badge, identifie une des personnes autorisées un lecteur, veille & détecte la présentation d’un badge et en lit le code informe le système de contrôle et affiche le résultat du contrôle … Exemple Contrôle d’Access ã (c) JCFJ

52 Propriétés Statiques - Attributs
UNESP/FEG/DEE Diagrammes de Classes 02/04/2017 Propriétés Statiques - Attributs Concernent la structure des données Une syntaxe [visibilité] nom [multiplicité] [ : type ][= valeur-initiale] [ {chaîne-propriété} ] Trois valeurs de visibilité : +, public (visible de toute classe), #, protégé (visible dans la classe et ses sous-classes), -, privé (visible dans la classe uniquement), ã (c) JCFJ

53 Propriétés Dynamiques - Opérations
UNESP/FEG/DEE Diagrammes de Classes 02/04/2017 Propriétés Dynamiques - Opérations Une syntaxe et quelques propriétés [visibilité] nom [ (liste-paramètre) ] [ : type-retour ] [ {chaîne-propriété} ] Des propriétés de contrôle de flots dynamiques : sequential : coordination extérieure pour que les appels soient séquentiels (1à1) guarded : contrôle d’intégrité sémantique, pas d’appels concurrents sur les gardes concurrent ã (c) JCFJ

54 UNESP/FEG/DEE Diagrammes de Classes 02/04/2017 Exemples Étudiant nom : String numéro : Integer = 0 age : Integer grade ajouter(Nom : String) : void s-inscrire() : Boolean Sport nom ajouter() invalider() Inscription date : Date Formation : cycle d’étude auquel les étudiants peuvent s’inscrire dans le cadre de l’institution que l’on gère. Créée ou invalidée par l’administration après habilitation Archivée pour l’historique de la vie de l’établissement Lors de la création d’une classe, donner sa definition comme une Note ou avec la Documentation de la Classe Formation nom : String ajouter(nom : String) : void valider(nom : String) : void Note Les opérations de création d’un objet sont implicites car « standard ». ã (c) JCFJ

55 Une classe « interface » est une
UNESP/FEG/DEE Diagrammes de Classes 02/04/2017 Variétés Spécifiques «stéréotype» : type de méta-classe qui sert de «définition de type» pour une famille de classe <<boundary>>, <<control>>, <<entity>>... «interface» : associée à une classe, elle décrit un comportement visible  Ne contient que des opérations (un type de stéréotype) POSterminal I-Store Store storeId : Integer POSlist : list create() login() find() getPOStotals() updateStoreTotals() get() <<uses>> Une classe « interface » est une Classe abstraire. Autre représentation ã (c) JCFJ

56 UNESP/FEG/DEE Diagrammes de Classes 02/04/2017 Les Relations Lien entre les objets ou les classes qui crée des dépendances fortes entre les classes du diagramme Trois types de liens de base, statiques, structurants : association agrégation, composition héritage Aussi, des liens de dépendance, plus faibles concernant la conception/réalisation du modèle de base  ce sont les dépendances : « réalise » entre classe et une interface « réalise » entre des composants logiciels et une classe « trace » entre classe « utilisateur » issue de l’analyse et classe « composant » qui est le résultat de la conception du logiciel ã (c) JCFJ

57 Associations ! ã Rôle (pas nécessairement des deux côtes)
UNESP/FEG/DEE Diagrammes de Classes – Les Relations 02/04/2017 Associations Rôle (pas nécessairement des deux côtes) Nom de la association (en italique) > Comment lire l’association Étudiant nom : String numéro : Integer = 0 age : Integer grade ajouter(Nom : String) : void s-inscrire() : Boolean Formation ajouter() valider() 1..4 1..n Inscription > +inscrits Cardinalités (inversées) ! La formation à laquelle l’étudiant est inscrit ne figure pas en « doublon » dans les attributs de Étudiant  C’est la relation qui traduit la propriété. ã (c) JCFJ

58 UNESP/FEG/DEE Diagrammes de Classes – Les Relations – Association 02/04/2017 Classe Associative Étudiant nom : String numéro : Integer = 0 age : Integer grade ajouter(Nom : String) : void s-inscrire() : Boolean Formation ajouter() valider() 1..4 1..n Inscription > +inscrits Inscription date : Date Action pour un étudiant de s’inscrire à une formation de l’établissement, créé et daté par la scolarité lors de cette inscription. Archivé pour l’historique de la vie de l’étudiant Classe associative : un objet de la classe est identifié par le « couple » d’objets liés par l’association ã (c) JCFJ

59 Généralisation-Spécialisation
UNESP/FEG/DEE Diagrammes de Classes – Les Relations 02/04/2017 Généralisation-Spécialisation Généralisation : plus général… super-classe sous-classe (hérite de) Spécialisation : plus spécial Généraliser : factoriser attributs, opérations, contraintes Spécialiser : extension COHERENTE…au sens ensembliste... Instance-Vol associerAvion() Instance-Pass res1 res2 réserver1() réserver2() Instance-Fret fret reserver-fret() Héritage Polymorphisme ã (c) JCFJ

60 UNESP/FEG/DEE Diagrammes de Classes – Les Relations – Généralisation-Spécialisation 02/04/2017 Héritage Multiple ã (c) JCFJ

61 UNESP/FEG/DEE Diagrammes de Classes – Les Relations – Généralisation-Spécialisation 02/04/2017 « Classe Abstraite » Classe, regroupant des propriétés communes à ses sous-classes Pas d’instances propres, sert juste à la « factorisation », « abstraction » Personne nom : String prénom : String n-insee : Integer adresse : String identifier() Employe salaire : Double indice : Double Etudiant n-inscription : Integer Nom en italique ã (c) JCFJ

62 Quelques Considérations
UNESP/FEG/DEE Diagrammes de Classes – Les Relations – Généralisation-Spécialisation 02/04/2017 Quelques Considérations Sens : « est un » , « est une sorte de » , « est de la famille des » Propriétés : non réflexive : A n’hérite pas de lui-même ; il EST lui-même non-symétrique : B sous-classe de A, interdit A sous-classe de B (pas de cycle) transitive : C sous classe de B, B sous-classe de A => C sous-classe de A A A A B B C ã (c) JCFJ

63 composition = agrégation forte
UNESP/FEG/DEE Diagrammes de Classes – Les Relations 02/04/2017 Agrégation Type de relation orientée, du tout vers les parties Forte : Composition Un module appartient à une seule filière (et disparaît avec elle) composition = agrégation forte pas de partage mort simultanée Tout Partie Faible : Agrégation Les modules sont partagés par plusieurs filières ã (c) JCFJ

64 Dépendances Réalisation La dépendance « type de dépendance »
UNESP/FEG/DEE Diagrammes de Classes 02/04/2017 Dépendances Réalisation La dépendance « type de dépendance » bind , entre des classes paramétrées et les paramètres effectifs derive, attribut dérivé : âge dérivé de date-de naissance friend, visibilité du but par la source instanceOf, instantiate pour des relations classe/objet powertype dans une relation enfants d’un même parent refine par raffinement d’abstraction de classe (analyse...implémente) ã (c) JCFJ

65 UNESP/FEG/DEE 02/04/2017 Dynamique des Classes Diagramme d’ État-Transition, Diagramme d’Activités. ã (c) JCFJ

66 Diagrammes d’États-Transitions
UNESP/FEG/DEE 02/04/2017 Diagrammes d’États-Transitions Automates d’états finis de type State Charts de Harel (visual Formalism for complexe systems, Sciences of Computer Programming vol 8). Exprime contraintes dynamiques Abstraction des comportements possibles des objets d’une classe (le plus souvent...) d’un U.C. d’un système Un état est caractérisé par une notion de durée et de stabilité Automates déterministes avec un état initial et des états finaux Transitions déclenchées par des événements avec conditions, actions et activités Décomposition disjonctive et composition conjonctive d’états Historique Etat initial Etat intermédiaire Etat final ACTIVITE CHOMAGE Plus de 60 ans Perte d ’emploi recrutement RETRAITE Un objet peut être décrit de manière formelle en terme d ’état et d ’événements à l ’aide d ’un automate. Un objet qui ne possède pas de comportement réactif est un objet considéré restant dans le même état et sa classe ne possède pas d ’automate. Pour représenter un automate, le formalisme UML s ’inspire des States Chartes (Harel, 1987, State Sharts: A visual Formalism for complexe systems, Sciences of Computer Programming vol 8). Un automate est une abstraction des comportements possibles. Comme les classes pour la structure statique. Les automates et les scénarios sont complémentaires: les scénarios se représentent par une collaboration entre objets.Quant à la forme de l ’interaction entre les objets collaborants dans un scénario est déterminée par les états respectifs des objets. L ’automate spécifie le comportement d ’une collaboration. Les automates sont utilisés pour décrire le comportement de groupes d ’objets (un automates peut représenter un composite ou même un cas d ’utilisation). ã (c) JCFJ

67 Exemple 1 ã Diagramme d’États-Transition pour la Classe Station-Lavage
UNESP/FEG/DEE Diagrammes d’États-Transition 02/04/2017 Exemple 1 Diagramme d’États-Transition pour la Classe Station-Lavage Classe Station-Lavage Attente <<idle>> Lavage Rinçage Séchage Fin( programme ) Suite( Programme ) Suite( programme ) Démarrer( programme ) [ présence(véhicule) ] ã (c) JCFJ

68 ã événement états garde transitions Classes
UNESP/FEG/DEE Diagrammes d’États-Transition – Exemple 1 02/04/2017 événement Les objets se comportent comme des éléments passifs, contrôlés par les événements provenant du système et déclenchant des transitions (passages d ’un état à un autre). Attente <<idle>> Lavage Rinçage Séchage Fin( programme ) Suite( programme ) Démarrer( programme ) [ présence(véhicule) ] transitions états garde Syst-Commande « signal » démarrer(programme) fin(programme) Classes Station-Lavage Un événement est une occurrence d ’une situation donnée dans le domaine du problème. C ’est une information instantanée qui doit être traitée sans plus attendre. C ’est le déclencheur pour passer d ’un état à un autre. L ’événement indique quel chemin (s) doit être suivi. Un événement est complètement spécifié s ’il comprend : un nom, la liste des paramètres, l ’objet expéditeur, l ’objet destinataire, la description de la signification de l ’événement. Transition: les états sont reliés par des connexions unidimensionnelles, ceux sont les transitions. Le passage est effectué d ’un état à un autre lorsque la transition est déclenchée par un événement survenant dans le domaine du problème. Le passage est instantané car l ’objet doit toujours être dans un état donné. Garde: c ’est une condition booléenne qui valide ou non le déclenchement d ’une transition lors de l ’occurrence d ’un événement. démarrer(programme) est un « signal » du Système de commande [présence(véhicule)] est une « garde », condition qui est évaluée pour accepter ou refuser la transition. Le développement des diagrammes d’états entraîne la mise à jour en cohérence des diagrammes de classes (statique) ã (c) JCFJ

69 UNESP/FEG/DEE Diagrammes d’États-Transition – Exemple 1 02/04/2017 événement Attente <<idle>> Actif Lavage Rinçage Séchage Démarrer( programme )[ présence(véhicule) ] Fin( programme ) Syst-Commande « signal » démarrer(programme) fin(programme) Classes Station-Lavage En regroupant toutes les transitions « fin programme » on met en évidence un sur-état Actif ã (c) JCFJ

70 Diagramme « hiérarchisé »
UNESP/FEG/DEE 02/04/2017 Attente <<idle>> Lavage Démarrer( programme ) [ présence(véhicule) ] Rinçage Séchage Fin( programme ) Suite( programme ) Diagramme « plat » Diagramme « hiérarchisé » Attente <<idle>> Actif ... Démarrer( programme )[ présence(véhicule) ] Fin( programme ) Lavage Rinçage Séchage les sous-états héritent des transitions de sortie ã (c) JCFJ

71 Histoire des sous-états dans un état
UNESP/FEG/DEE Diagrammes d’États-Transition – Exemple 1 02/04/2017 Histoire des sous-états dans un état Actif Lavage Rinçage Séchage H Attente <<idle>> Fin( programme ) Problème Démarrage( programme )[ présence(véhicule) ] État “historique” – indique un retour avec mémorisation ã (c) JCFJ

72 UNESP/FEG/DEE Diagrammes d’États-Transition 02/04/2017 Concepts 1 État : (d’un objet ou d’une classe) : ensemble des valeurs, des attributs, des relations et des opérations exécutables (pour l’objet et ceux qui sont visibles par lui) nom: nomme l’état, mais il peut être anonyme ; pas obligatoire actions : d’entrée/sortie, opérations instantanées, non interruptive exécutées à l’entrée ou la sortie de l’état, (au passage de la transition) transitions internes : transitions qui ne changent pas l’état, et s’exécutent sous le contrôle des sous états sous états : états contenus dans l’état impliquant des sous-états, disjoints (séquentiels) ou concurrents pseudo états : il existent trois : état initial : correspond à l’état implicite “le diagramme d’états est crée” état final : correspond à l’état implicite “le diagramme d’états est détruit” état “indicateur d’historique” : une transition vers cet état déclenche une transition au dernier sous-état atteint lors du dernier passage à cet état ã (c) JCFJ

73 UNESP/FEG/DEE Diagrammes d’États-Transition 02/04/2017 Concepts 2 État “idle”, inactif, attente : état neutre de l’objet après une transition, il attend d’autres événements pour effectuer une transition. État actif : état actif càd une activité se déroule pendant que l’objet est dans cet état, en attendant un événement déclencheur d’une transition (avec durée) Activité - do/activity (faire/activité) Ensemble d’opérations qui peuvent se produire pendant que l’objet est dans un état. Ex.: do/op1(a); op2(b); op3(c) Séquence d’actions (chaque action est non interruptive) Une activité met un certain temps à s’exécuter. Elle est interruptive (entre deux actions) par un événement déclencheur. Elle peut faire référence à un autre diagramme d’état qui la décrit ; États Transition d’État Nom de l’État entry: action d’entrée entry: ^class.événement exit: action de sortir exit: ^ class.événement do: activité do: ^class.événement Nom Événement[Garde]/Action Initial Final ã (c) JCFJ

74 État : une situation assez stable pour « durer » !
UNESP/FEG/DEE Diagrammes d’États-Transition 02/04/2017 Concepts 3 Les événements provoquant les transitions sont classables suivant 4 natures : change event :changements de valeur, atteintes de limites time event : date, jour-heure, fin ou début de période signal : signaux venant d ’une autre classe (classe-active) avec ou sans paramètre call event : appel de procédure qui déclenche une action qui fait transiter… Comment les reconnaître ? Et trouver les états : en examinant dans les scénarios, les appels de procédure inter-objets ou les signaux envoyés en regardant les qualificatifs associés aux objets dans ces mêmes scénarios en examinant les attributs des objets et leurs valeurs critiques en établissant une trace des divers points importants du «calendrier » qui rythme la vie du système et des objets État : une situation assez stable pour « durer » ! ã (c) JCFJ

75 Exemple 2 ã Diagramme d’États-Transition pour une Classe Fax
UNESP/FEG/DEE Diagrammes d’États-Transition 02/04/2017 Exemple 2 Diagramme d’États-Transition pour une Classe Fax super-état sous-état <<idle>> Réception Attendre sonnerie entry/ décrocher exit/ déconnecter Connecté Connecté Entête-Ok raccrocher En-traitement En-traitement Envoie-fax actions do/ recevoir do/ recevoir Transmission Effacer Effacer Erreur / imprimer-rapport [ parité-Faux ] transitions sans déclencheur état final (fin du scénario) état initial (début du scénario) ã (c) JCFJ

76 Diagrammes d’Activités
UNESP/FEG/DEE 02/04/2017 Diagrammes d’Activités Autre diagramme pour exprimer de la dynamique  un organigramme qui présente le flux de contrôle entre des activités Utilisé principalement pour la modélisation d’étapes séquentiels (ou concurrents...) d’un processus de calcul Modélise le comportement interne d’une méthode (d’un seul objet) ou d’un cas d’utilisation (d’une société d’objets) Une variante du diagramme d’états transition Diagramme d’États Transition : mis en valeur des états et des transitions Diagramme d’Activités : mis en valeur des activités et des transitions Zones d’activités pour exprimer en analyse de besoin, les grandes étapes du système pour montrer globalement des interactions avec le temps et les contraintes logiques ã (c) JCFJ

77 UNESP/FEG/DEE Diagrammes d’Activités 02/04/2017 A cause de la nature procédurale des opérations (la plupart des événements correspondent simplement à la fin de l’activité précédente) la distinction systématique entre état, activité et événement est parfois inutile  Les diagrammes d’activités offrent une manière simplifiée pour la visualisation des activités. Par rapport aux Diagrammes d’Interaction, que mettent en valeur le flux de contrôle entre les objets, les Diagrammes d’Activités mettent en valeur le contrôle d’une activité vers une autre. Les Diagrammes d’Activités peuvent exister pour qu’on puisse d’une manière indépendante , visualiser, spécifier, construire et documenter la dynamique d’un ensemble d’objets  peuvent aussi servir à modéliser le flux de contrôle d’une opération. ã (c) JCFJ

78 Concepts 1 État d’Action et État d’Activité :
UNESP/FEG/DEE Diagrammes d’Activités 02/04/2017 Concepts 1 État d’Action et État d’Activité : États d’Action : représentent un calcul exécutable atomique (ne peut pas être divisé)  des états du système que représentent chacun l’exécution d’une action. Un État d’Action ne peut pas être décomposé Un État d’Action est atomique : des événements peuvent se produire sans que l’action réalisée par l’état soit interrompue. La durée d’exécution de l’action dans un état d’action est considéré non significative. États d’Activités : sont des états dont l’activité peut éventuellement être représentée par d’autres diagrammes d’activités  un État d’Action peut être considéré comme un cas spécial d’État d’Activité qui ne peut plus être divisé. Un État d’Activité peut être décomposé Les États d’Activités ne sont pas atomiques : ils peuvent être interrompus par des événements La durée d’exécution de l’activité dans un État d’Activité peut être mesuré, elle est significative Étudier devis index:= index + 1 Action simple Expression Début Construction() entry / bloquer() Action d’entre Contrôle Finance(f) Sous-diagramme ã (c) JCFJ

79 UNESP/FEG/DEE Diagrammes d’Activités 02/04/2017 Concepts 2 États Initial et Final : utilisés au même sens que dans les Diagrammes d’États Transition. Transition : quand l’action ou activité d’un état se termine, le flux de contrôle passe immédiatement à l’activité suivante  ce flux est indiqué avec les Transitions que permettent de montrer le chemin entre les états d’action ou d’activité. Division Conditionnelle du Flux : est utilisée pour spécifier les différents chemins qui peut prendre le flux à partir de l’évaluation d’une expression booléenne. Un division doit avoir une transition entrante et une ou plusieurs transitions sortantes Chaque transition sortante doit avoir une expression booléenne qui est évalue lorsque la division est atteinte  les conditions de garde de chacune de ces transitions doivent être mutuellement exclusives et doivent couvrir toutes les possibilités pour maintenir le déterminisme On peut utiliser le mot clef else pour indiquer la transition que doit être suivie dans le cas où aucune autre n’est vrai État initial État d’Action État 1 Transition État 2 État final Ordre début des travails division [matériel pas prêt] On parle ici de flux de contrôle. Replanifier Condition de garde [matériel prêt] Attribuer taches ã (c) JCFJ

80 Concepts 3 Synchronisation de Flux Concurrents:
UNESP/FEG/DEE Diagrammes d’Activités 02/04/2017 Concepts 3 Synchronisation de Flux Concurrents: Utilisées pour représenter la division et le regroupement de flux de contrôle parallèles. Une fourche concurrente représente la division du flux de contrôle  au dessous de la division, les activités associées aux flux se développent en parallèle. Une jonction concurrente peut avoir deux ou plus transitions entrantes et généralement une unique sortante  après que toutes les transitions aient atteint la jonction, la transition de sortie est réalisée. ã (c) JCFJ

81 Concepts 4 Travées : Flot d’Objet :
UNESP/FEG/DEE Diagrammes d’Activités 02/04/2017 Concepts 4 Travées : Est une division que peut être appliquée à un Diagramme d’Activités pour représenter les différents responsabilités d’un mécanisme ou d’une organisation. Chaque responsabilité est assuré par un ou plusieurs objets et chaque action d’état ou activité est attachée à un une travée en particulier. Chaque travée est divisée avec des lignes verticales. Les transitions peuvent traverser les travées. Flot d’Objet : Est un ensemble composé d’une relation de dépendance entre un objet et l’action ou l’activité à l’origine de sa création, destruction ou modification. Présente les objets qui participent au flux de contrôle d’un Diagramme d’Activités. Peut présenter pour les objets qui participent du diagramme ses états et les valeurs de ses attributs. Des objets peuvent être connectés à différentes actions d’états ou d’activités  son état est représenté pour faire la différence Des flots d’objets peuvent être utilisés avec de diagrammes d’activités simples ou en travée. La notion de travée fait référence à la notion de couloir d ’activités. Permet de montrer les différentes responsabilités au sein d ’une organisation ou d ’un mécanisme. Un objet peut changer d ’état selon l ’état d ’avancement du mécanisme. L ’objet peut figurer dans le diagramme à plusieurs reprises avec une spécification de son état à chaque occurrence dans une expression entre crochets. ã (c) JCFJ

82 ã Ouvrir la fenêtre (activité) (état) aérer Fermer la fenêtre
UNESP/FEG/DEE Diagrammes d’Activités – Concepts 4 : Travées et Flot d’Objets 02/04/2017 travées flot d’objet objet état Remarque: un diagramme d ’activités peut contenir des états et des événements représentés de la même manière que dans les diagrammes d ’états-transitions: exemple: Ouvrir la fenêtre (activité) flot d’objet aérer (état) ã Consigne atteinte Fermer la fenêtre (activité) (c) JCFJ

83 DEMARCHE ORIENTEE OBJET
UNESP/FEG/DEE 02/04/2017 DEMARCHE ORIENTEE OBJET Le domaine d ’étude n ’est pas le système d ’information dans sa globalité (l ’organisation n ’est pas prise en compte). Il est réduit au système informatique. La démarche proposée (à travers UML) vise donc à spécifier et à implanter les fonctions informatisées du système d ’information. A.Expression des besoins A.1 Cas d ’utilisation (Use Case)  à partir des fonctions attendues du système informatique, établir un diagramme de cas d ’utilisation. A.2 Diagramme de séquence de haut niveau pour chaque cas d ’utilisation, décrire le scénario principal et éventuellement les scénarios secondaires en langue naturelle B.Analyse B.1 diagramme de séquence intermédiaire «pour chaque diagramme de séquences de haut niveau construire le diagramme de séquences intermédiaire qui exprime les demandes de services fondamentales entre objets. B.2 diagramme de classe intermédiaire construire progressivement le diagramme de classes: classes, attributs et associations. Ajouter les classes application et ses opérations (cas d ’utilisation définis du système. C.conception C.1diagramme de Séquences Détaillé  à chaque diagramme se séquences interm. Construire le D S D: exprimer les demandes de services détaillées entre objets et spécifier leurs paramètres. C.2 Diagramme de Classe Détaillé compléter le diagramme de classe conformément aux Diagrammes de Séquences Détaillés. C.3 Diagramme de Classes Généralisé principes d ’abstraction et de polymorphisme. C.4 Langage de conception D.Implantation Les étapes B1 et B2 sont menées en parallèle. Les étapes expression des besoins, analyse et conception sont menées de manière cyclique où les diagrammes d ’état-transition, d ’activité, de séquences… permettent d ’affiner le système informatique(selon des points de vue différents) en introduisant plus de détailles concernant les rôles, les objets, les liens… et par conséquent élargir le périmètre du SI. ã (c) JCFJ

84 UNESP/FEG/DEE Démarche Orienté Objet 02/04/2017 Conclusion Les étapes expression des besoins, analyse et conception sont menées de manière cyclique où les diagrammes d ’état-transition, d ’activité, de séquences… permettent d ’affiner le système informatique(selon des points de vue différents) en introduisant plus de détailles concernant les rôles, les objets, les liens… et par conséquent élargir le périmètre du SI. ã (c) JCFJ

85 Etude de Cas ã

86 UNESP/FEG/DEE 02/04/2017 Décrire la Réalisation et son Implantation Diagrammes de Composant, Diagrammes de Déploiement ã (c) JCFJ

87 Diagrammes de Composants
UNESP/FEG/DEE 02/04/2017 Diagrammes de Composants Fournit une vue statique (l’architecture logicielle) représentant la mise en oeuvre d'un système, dessiné sous la forme d'un graphique de composants logiciels connectés par des relations : dépendance, généralisation, association et réalisation. Éléments : composants (avec plusieurs stéréotypes) et interfaces. Utilisés pour définir les dépendances et relations entre objets à un niveau “supérieure” à celui du diagramme de classes  les AGLs permettent de créer un lien entre les classes du modèle logique et les composants. Modélisent la structure du logiciel et montrent les dépendances entre le code source, le code binaire et les composants exécutables, de sorte que l'impact d'une modification puisse être évalué  Les dépendances entre composants permettent notamment d'identifier les contraintes de compilation et de mettre en évidence la réutilisation de composants. Le composants peuvent être organisés en packages, qui définissent des sous-systèmes. Sybase® - PowerAMC™ - Modèle Orienté Objet Guide de l'utilisateur Version Janvier 2002 ã (c) JCFJ

88 Exemple ã Diagrammes de Composants
UNESP/FEG/DEE Diagrammes de Composants 02/04/2017 Exemple Cours UML : UML, le langage de modélisation objet unifié ã (c) JCFJ

89 Diagrammes de Déploiement
UNESP/FEG/DEE 02/04/2017 Diagrammes de Déploiement Architecture matérielle et répartition logicielle Éléments : des nœuds (ressources matérielles) et des relations de dépendance et d’association  aussi des composants qui doivent résider sur un nœud et de packages. Des Diagrammes de Classes centrées sur les nœuds d’un système Stéréotypes utilisés pour les nœuds : <<processeur>>, <<mémoire>>, <<dispositif>> Connections bi-directionnelles avec cardinalités des nœuds et des connections Diagrammes de Classes Diagrammes de Composants Structure du Logiciel Diagrammes de Séquences Diagrammes de Collaboration Diagrammes de États-Transition Diagrammes d’Activités Comportement du Logiciel Diagrammes de Déploiement A la frontière matériel/logiciel du système pour planifier la topologie des processeurs et des périphériques sur lesquels le système tourne ã (c) JCFJ

90 Exemple ã Diagrammes de Déploiement
UNESP/FEG/DEE Diagrammes de Déploiement 02/04/2017 Exemple Cours UML : UML, le langage de modélisation objet unifié ã (c) JCFJ