La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

CONCEPTION DES LOGICIELS : Chapitre 2

Présentations similaires


Présentation au sujet: "CONCEPTION DES LOGICIELS : Chapitre 2"— Transcription de la présentation:

1 CONCEPTION DES LOGICIELS : Chapitre 2
LE SYSTÈME ET SON ENVIRONNEMENT : ÉLÉMENTS D’ANALYSE FONCTIONNELLE

2 Plan du chapitre Notions de théorie des systèmes
Description du contexte système et de la collaboration entre acteurs Cas d’emploi « Use case » - Approche UML Comment modéliser - Méthodes et outils Exemple : Un contrôle aérien rudimentaire

3 Notions de théorie des systèmes
1ère partie Notions de théorie des systèmes

4 Concepts de la théorie des systèmes (1/2)
Système (modèle cybernétique de N.Wiener [1948]) : Ensemble d’éléments [autres systèmes] en interactions [communicants], ouvert sur l’extérieur, qui opèrent en vue d’une finalité [contrat de service] Pilote Sphère de contrôle Processus P de S Intrants Extrants Stimulis Réponses Temps de réponse Hystérésis / inertie Mesures M Régulation R Commandes C Proactive Réactive Temps de latence

5 Concepts de la théorie des systèmes (2/2)
Chaîne de communication (modèle de C.Shannon[1959]) : Dans tout acte de communication, il y a un émetteur [langage L1], un destinataire [langage L2] et du bruit Émetteur Destinataire Sources d'Information Puits d'Information Canal de correction Observateur ÉMISSION Canal de transmission RÉCEPTION A t-il bien reçu le message ? (intégrité, délai, sécurité, etc.) A t-il reçu le bon message ? Fusion + Codage Décodage + Distribution • • • • • • Perturbations (Bruit) Langage Métier L1 Langage Informatique L2 • • • Mémoire Mémoire • • • Capteurs Personne/Organisation Système +Erreurs humaines/Incertitudes Actionneurs Personne/Organisation Système +Erreurs humaines/Incertitudes états

6 Description du contexte système et de la collaboration entre acteurs
2ème partie Description du contexte système et de la collaboration entre acteurs

7 L'observation de la réalité (1/2)
Les frontières du modèle et les interactions avec l’extérieur Identification des sources d'information (émetteurs et récepteurs) Notion d’acteurs Nature des flux d'information entrant et sortant Continu / discret, régulier / aléatoire, commandes-contrôles, événements Les flux de données (messages) Modèles conceptuel des données échangées Identification des canaux de communications qui relient les éléments du modèle et par lesquels transitent l'information ; Fusion / Distribution-Répartition des flux (selon exigences comportementales ) Organes de stockage (mémoire persistante / mémoire non persistante) Les processus Identification d'un ensemble d'opérations (algorithmes) et/ou de procédures (opérateurs humains) qui transforment l'information et qui régulent/contrôlent l’enchaînement des opérations Nomenclature et terminologie courantes : Tâches, activités, fonctions, actions

8 L'observation de la réalité (2/2)
Distinction aussi rigoureuse que possible entre TRANSFORMATION et PILOTAGE/CONTRÔLE Nomenclature des entités du système telles que perçues par les exploitants et usagers (gestion des configurations) Fonctions et organes assurant la transformation : Nom du canal et caractéristiques générales (débit, QOS, …) : c’est déjà de l’implémentation résultant des choix technologiques Nature des informations qui transitent dans le canal et des transformations associées : notion purement fonctionnelle (abstraction) Nécessité de classifications rigoureuses (selon points de vue) Notion de « système immunitaire » (intégrité / sécurité) Contraintes à satisfaire qui garantissent la finalité du système (support des caractéristiques dites non fonctionnelles  FURPSE) Reconnaissance et élimination des éléments qui ne font pas partie du système (intrusions volontaires ou involontaires ; « fuite » de mémoire ; etc.) États incohérents et/ou interdits (notion de droits/privilèges ; invariants) Surveillance des capacités (capacity planning) et system management

9 CENTRE CARTES BANCAIRES
Les frontières : diagrammes de contexte / diagrammes de collaboration (1/2) AUTRES AGENCES Exemple d'une billetterie <<Acteur>> Système et/ou application externe SOURCE PROCESSUS FLUX AUTRES BANQUES BILLETTERIE AGENCE <<Acteur>> Système et/ou application externe FLUX SOURCES FLUX Requêtes : Carte ID, code, montant, reçu Réponses : Remise des billets, Refus, Renseignements complémentaires, Mise à jour de la carte. FLUX <<Acteur>> Système et/ou application externe Règles d'interopérabilité (conventions entre les systèmes) CENTRE CARTES BANCAIRES

10 Les frontières : diagrammes de contexte / diagrammes de collaboration (2/2)
Décomposition du processus BILLETERIE AGENCE Distributeur ON/OFF ON/OFF Compensation Inter-banques Mise à Jour client agence Vérification CB Transfert autres agences Transfert autres banques Comptes clients Transferts agences Compensation Processus de stockage de l’information (fichiers ou BD) Centre cartes bancaires Autres agences Autres banques

11 Symboles et icônes Acteurs Développement Exploitation/Support
PROCESSUS Acteurs Développement Exploitation/Support PROCESSUS OU Typologie des messages mx Émetteur Récepteur Messages (Poussés / Tirés) Acteurs usagers du SI Message simple (lettre) / recommandée Message avec accusé de réception (AR) Message avec une priorité Message à traiter avant un délai t Message déclenchant l’activation d’une fonction (Signal synchrone ou asynchrone) Message déclenchant l’arrêt temporaire/définitif et/ou la destruction d’une entité Etc. <<Acteur>> Système et/ou application externe Stéréotype Acteurs non humains  Équipements ; Autres systèmes

12 Classification et typologie des acteurs (1/2)
<<Acteur générique>> Acteur généralisé abstrait <<Acteur humain>> Diverses catégorie d’utilisateurs <<Acteur NON humain>> Diverses catégories d’équipements Variété {Typologie, Nombre d’occurrences} <<Opérateur système>> Pilote du système global <<Administrateur SI>> Un ou plusieurs administrateur par SI <<Administrateur BD>> Administration du référentiel des données <<Administrateur COM>> Supervision et administration des différents réseaux <<Administrateur sécurité>> Authentification, droit d’accès <<Support>> Dépannage de 1er niveau, mise à jour des versions <<Usager expert>> Usager ayant déjà une grande expérience du système <<Usager novice>> Usager sans expérience Liste des caractéristiques et attributs (FURPSE) des différents acteurs (Notion de classe d’acteurs)

13 Les processus de traitement (1/2)
Différentes catégories de processus Processus de transformation Description des transformations (ce sont des traductions et/ou des calculs) des différents flux jusqu’à obtention du résultat souhaité Constituants d’un processus : Tâches/activités ; Fonctions/procédures ; Blocs/actions/transactions Processus de contrôle/enchaînement Description des règles et procédures qui définissent le comportement (ce sont des régulations) d’un ou plusieurs processus par rapport à la finalité du système Caractéristiques du contrôle Évènements déclenchant, exceptions, priorités, partage de ressources, synchronisation, parallélisme, surveillance, etc.

14 Les processus de traitement (2/2)
CÉLIBATAIRE «CLONES» IDENTIQUES PROCESSUS RÉENTRANT MONITEUR / Pilote de transformation P1 M1 M1 P1 Évènements reçus Évènements émis PÈRE HIÉRARCHIE DE PROCESSUS MONITEUR (Scrutateur / Event poller) FILS Ordre de balayage PETIT-FILS Ensemble de ressources à surveiller (et les évènements associés) Nombreux exemples de ce type de structure en transactionnel (plusieurs instances, imbrication de transactions, etc.

15 Cas d’emploi – « Use case » Approche UML
3ème partie Cas d’emploi – « Use case » Approche UML

16 Définition Qu’est ce qu’un cas d’utilisation
C’est un ensemble de séquences d’actions réalisées par le système et produisant un résultat observable sémantiquement intéressant pour un acteur particulier (humain et/ou non humain) Un cas d’utilisation modélise un service rendu par le système. Il exprime les interactions acteurs/système et permet de comprendre ce que fait exactement l’acteur(s) concerné(s) par le cas d’utilisation Le cas d’utilisation porte la sémantique du point de vue des acteurs Un cas d’utilisation est décrit à l’aide de scénarios : c’est une succession particulière d’enchaînement jugés significatifs et porteur de sémantique par rapport aux opérations futures C’est une représentation en extension du système

17 Symbologie et représentation graphique
Diagrammes d’activités Description textuelle du cas d’utilisation (Processus et fonctions) Diagrammes états-transitions Cas d’utilisation Ensemble de scénarios explicitant le cas d’utilisation de façon à permettre la traduction en concepts informatiques Scénario N°3 Scénario N°2 Scénario N°1 Diagrammes de collaboration – contexte acteurs Diagrammes de séquences Si nécessaires à la compréhension des scénarios

18 Description textuelle du cas d’utilisation
Informations obligatoires : Identification Description des enchaînements – caractéristiques fonctionnelles du/des fonctions (ce que ça fait dans un monde « parfait ») En particulier : interopérabilité avec d’autres systèmes ; sécurité Caractéristiques non fonctionnelle (FURPSE) – prise en comte du monde réel et des contraintes associées En particulier : pré et post-conditions conformément au processus/fonctions génériques NB : l’absence d’information sur le comportement est déjà une information !!! Évènements gérés et/ou générés par le cas d’utilisation

19 De la description d’un cas d’utilisation la mise en pratique indispensable à une bonne communication
Chaque cas d’utilisation doit être commenté. Typiquement entre 1 et 3 pages : Un titre décrivant le cas d’utilisation Un résumé bâti en trois parties (idéalement) le déclenchement : « ce cas d ’utilisation commence lorsque… » les actions : « ce cas d ’utilisation consiste en… » la terminaison : « ce cas d ’utilisation prend fin lorsque… » Une description textuelle qui développe les quatre points (idéalement) : quand : à quel moment, ordonnancement qui : les acteurs quoi : les actions comment : les contraintes Le but exprimé selon le point de vue métier de l’acteur principal Les acteurs participants au cas d’utilisation Les flux d’information (informations échangées) par les acteurs Le flot normal des actions : qui correspond au comportement nominal liste de points numérotés du point de vue des acteurs, sans les détails d’implémentation Les flots d’actions alternés : les erreurs, les exceptions ou des cas très particuliers comment ce flot s’insère-t-il dans le flot normal ? comment se fait le retour au flot normal ? ressemblent souvent à des extends (extension d’un cas d ’utilisation)  détailler les conditions de déclenchement Nom : le choix du nom d’un cas d’utilisation est important doit permettre de deviner ce que recouvre le cas d’utilisation utiliser une forme verbale active mettre l’accent sur le rôle de l’acteur qui initie le cas d’utilisation (adopter son point de vue) acteur qui initie  acteur qui y trouve une plus value (à défaut, acteur ayant une responsabilité) « retirer de l’argent », « entrer code », « passer commande », « manger », etc. Acteurs : répertorier les acteurs qui participent à chaque cas d’utilisation quel acteur initie le cas d’utilisation ? Quelle valeur en retire-t’il ? quels sont les messages échangés par les acteurs dans ce cas d ’utilisation ? Flot normal : scénario nominal Flots alternés : scénarios exeptionnels

20 De la description d’un cas d’utilisation d’un point de vue plus organisationnel
Dans le cadre de la gestion d’un projet important (ou d’un système) on devra probablement ajouter des éléments informatifs tels que : Identification de l’équipe en charge de ce use-case Et pour la traçabilité, historique des équipes ayant travaillé sur ce use-case Plusieurs équipes dans l’équipes des uses-cases Numéro de version du use-case (et peut être ID use-case lui même) Gestion de configuration, gestion des évolutions, traçabilité Personnes, équipes, chargée de la validation Rapports de validation Travail en groupe, contrôle global de la cohérence Priorité du use-case Numéro de version du prototype à partir duquel il doit figurer dans le système Dans le cadre d’un développement itératif et incrémental Liens avec d’autres use-cases termes définis dans un glossaire commun au projet ou à un système Références vers des documents Faisant parti du projet, système de références croisées avec et / ou glossaire / lexique normatifs : ANSI, ISO, OMG, W3C, etc. extérieurs : au projet ou à l’organisation : manuels de référence, documentation APIs antérieurs : travaux menés antérieurement et réutilisables Stricto sensu, c’est de la gestion de configuration C.M. Nécessaire dès qu’on travaille en équipe et/ou sur la durée et pour obtenir les satisfecits ISO, CMM, etc. Nom : le choix du nom d’un cas d’utilisation est important doit permettre de deviner ce que recouvre le cas d’utilisation utiliser une forme verbale active mettre l’accent sur le rôle de l’acteur qui initie le cas d’utilisation (adopter son point de vue) acteur qui initie  acteur qui y trouve une plus value (à défaut, acteur ayant une responsabilité) « retirer de l’argent », « entrer code », « passer commande », « manger », etc. Acteurs : répertorier les acteurs qui participent à chaque cas d’utilisation quel acteur initie le cas d’utilisation ? Quelle valeur en retire-t’il ? quels sont les messages échangés par les acteurs dans ce cas d ’utilisation ? Flot normal : scénario nominal Flots alternés : scénarios exeptionnels

21 Comment modéliser - Méthodes et outils
4ème partie Comment modéliser - Méthodes et outils

22 Outils théoriques et concepts pour l’architecte modélisateur
Descriptions statiques du système Descriptions dynamiques du système OUTILLAGE Ensembles Relations Fonctions calculables Langages formels Systèmes de classification OUTILLAGE Automates Machines à états finis (machines abstraites) Systèmes à états-transitions Communication et théorie de l’information Nombreuses interactions et dépendances entre tous ces aspects (relations de dualité), d’où : GRANDE COMPLEXITÉ

23 Fondements des sciences de l’information
Caractéristiques des problèmes Peu de variables Beaucoup de variables Ordre simple Ordre complexe Physique classique et sciences de l’ingénieur correspondantes Calcul différentiel et intégral Équations différentielles et aux différences finies Géométrie analytique Physique moderne et sciences de l’ingénieur correspondantes Programmation mathématique Programmation et algèbre linéaire Calcul tensoriel, analyse spectrale, opérateurs et espaces de Hilbert Déterministe Désordre simple Désordre complexe Physique statistique/Thermodynamique et sciences de l’ingénieur correspondantes Probabilités et statistiques Sciences du comportement et de la vie; science de la décision et de la communication Recherche opérationnelle (graphes, complexité) Théorie de l’information et de la communication (langages, grammaires et automates) Logique floue ; modélisation qualitative Systèmes non linéaires et chaos Stochastique

24 Modèles statiques Répond à la question : Comment c’est fait
Plan de montage / Construction du système (Intégration) cf. les notions de bibliothèques et/ou de packages (gestion de configuration) Modèles de classes basés sur les concepts (issus de la logique) de : ENSEMBLES et RELATIONS appliqués aux trois catégories d’entités de l’analyse fonctionnelle Données / Flux Instructions-Fonctions / Processus Contrôles / Pilotage FONCTIONS Caractérisent la nature des transformations à effectuer ; elles s’expriment à l’aide de langages (syntaxe + sémantique)  Textes

25 Modèles dynamiques Répond à la question : Comment ça marche
Description des enchaînements des transformations effectuées par les fonctions Modèles de traitements ; Diagrammes d’activités (UML) Pilotage et contrôle du système Ordonnancement et séquençage des opérations à partir des évènements et/ou messages reçus Description des séquences d’envoi/réception de messages (MSC en UML)  Notion de protocole Modèles de comportements du système (issus de la théorie des automates) : Systèmes à États – Transitions Machines à états finis (automates à mémoire)

26 Exemple : Un contrôle aérien rudimentaire
5ème partie : Exemple : Un contrôle aérien rudimentaire

27 Scène réelle E E/S DÉTECTION de TOUS LES OBJETS Surveillance RADAR
ACTEURS VISUALISATION SYSTÈME DE CONTRÔLE DU TRAFFIC AÉRIEN E E/S DÉTECTION de TOUS LES OBJETS CONTRÔLES / COMMANDES

28 Diagramme de contexte / collaboration
VISU- ALISATION Couverture aérienne par les radars civils Visualisation en temps réel de la situation aérienne au voisinage de l'aéroport SCTA RADAR RADAR RADAR OPÉRA- TEURS Gestion de l'espace aérien par les contrôleurs PLANS DE VOLS Tenue à jour des plans de vol par les différentes compagnies aériennes accréditées MÉTÉO NATION- NALE DÉFENSE AÉRIENNE EURO- CONTROL Dialogues avec les centres de contrôle européens Dialogues avec la défense aérienne France + OTAN

29 FLOTS DE DONNÉES, PROCESSUS, STOCKAGE (1/2)
MONITEUR CONSOLES VISUALISATION ACTIVATION DU SYSTÈME DE VISUALISATION «PISTES» POSITION {x,y,z} ET IDENTIFICATION DES OBJETS VOLANTS FORMATION DES TRAJECTOIRES MONITEUR DES RADARS NOYAU DU SYSTÈME COMMANDES DE GESTION DES «PISTES» MONITEUR CONSOLES OPÉRATEURS Contient les extraits des plans de vol des avions sous contrôle du système PLANS DE VOLS ACTIVATION DU SYSTÈME DE COMMANDES Msgx,y,… vers les SI des compagnies aériennes, avec accusés de réception (AR) TAMPON

30 FLOTS DE DONNÉES, PROCESSUS, STOCKAGE (2/2)
INTERFACE VISUALISATION RADARS TIMER VISU Gestion physique Gestion logique +AR évènements GESTION RADAR FICHIER PISTES Messages à Visualiser avec AR Pile évènements COMMAN- DES FICHIER PISTES L'intégrité de ce fichier est primordiale Mécanisme de« polling» INTERFACE COMMANDES OPÉRATEURS 1 File d'attente par RADAR 2 canaux sont prévus selon la nature des commandes (courtes, longues, prioritaires, …) avec accusés de réception AR


Télécharger ppt "CONCEPTION DES LOGICIELS : Chapitre 2"

Présentations similaires


Annonces Google