J.Printz / CNAM - CMSL / Conception des logiciels - Analyse fonctionnelle / Vers. 5.3Page 1 CONCEPTION DES LOGICIELS : Chapitre 2 LE SYSTÈME ET SON ENVIRONNEMENT

J.Printz / CNAM - CMSL / Conception des logiciels - Analyse fonctionnelle / Vers. 5.3 Page 1

CONCEPTION DES LOGICIELS : Chapitre 2

LE SYSTÈME ET SON ENVIRONNEMENT : ÉLÉMENTS D’ANALYSE FONCTIONNELLE

C E N T R E D E

M A I T R I S E D E S

S Y S T E M E S E T

D U L O G I C I E L

J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 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


1ère partie

Notions de théorie des systèmes


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]

Intrants ExtrantsProcessus P de

S

Pilote

Régulation RMesures M Commandes C

• Temps de réponse

• Sphère de contrôle

• Proactive• Réactive

• Temps de latence

• Hystérésis / inertie

Stimulis Réponses


Perturbations(Bruit)

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

• • •

• • •

• • •

• • •Mémoire Mémoire

ObservateurObservateur

Canal detransmission

Sourcesd'Information

Puitsd'Information

ÉmetteurÉmetteur DestinataireDestinataire

Capteurs• Personne/Organisation• Système+Erreurs humaines/Incertitudes

Actionneurs• Personne/Organisation• Système+Erreurs humaines/Incertitudes

Décodage+

Distribution

Fusion+

Codage

ÉM

ISS

ION

RÉ

CE

PT

ION • A t-il bien reçu le message ?

(intégrité, délai, sécurité, etc.)• A t-il reçu le bon message ?

Canal decorrection

Langage Métier L1

Langage Informatique L2

états


2ème partie

Description du contexte système et de la collaboration

entre acteurs


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 sortantContinu / 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


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 technologiquesNature 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


Les frontières : diagrammes de contexte / diagrammes de collaboration

(1/2)

Exemple d'une billetterie

BILLETTERIEAGENCE

SOURCES

PROCESSUSSOURCE

Règles d'interopérabilité (conventions entre les systèmes)

Requêtes :•Carte ID, code, montant, reçuRéponses :•Remise des billets,•Refus,•Renseignements complémentaires,•Mise à jour de la carte.

AUTRESAGENCES

AUTRESBANQUES

CENTRECARTES

BANCAIRES

<<Acteur>>Système

et/ou application

externe

<<Acteur>>Système

et/ou application

externe

<<Acteur>>Système

et/ou application

externe

FLUX

FLUX

FLUX

FLUX


CompensationInter-banques

Les frontières : diagrammes de contexte / diagrammes de collaboration (2/2)

Distributeur

Mise à Jourclient agence

VérificationCB

Transfertautres

agences

Transfertautres

banques

Comptes clients Transferts agences Compensation

ON/OFF ON/OFF

Décomposition du processus BILLETERIE AGENCE

Autresagences

Autresbanques

Centre cartes bancaires

Processus de stockage de l’information

(fichiers ou BD)


Symboles et icônes

Acteurs• Développement• Exploitation/Support

Acteurs usagers du SI

<<Acteur>>Système

et/ou application

externeStéréotype

Acteurs non humains Équipements ; Autres systèmes

PROCESSUS PROCESSUSOU

Typologie des messages

Émetteur RécepteurMessages

(Poussés / Tirés)

• 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.

mx


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

<<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

<<Usager expert>>Usager ayant déjà une grande

expérience du système

<<Usager novice>>Usager sans expérience

<<Support>>Dépannage de 1er niveau, mise à

jour des versions

Variété{Typologie, Nombre

d’occurrences}

Liste des caractéristiques et attributs (FURPSE) des différents

acteurs(Notion de classe d’acteurs)


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înementDescription 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.


Les processus de traitement (2/2)

P1

CÉLIBATAIRE «CLONES» IDENTIQUES

HIÉRARCHIE DE PROCESSUS

M1

MONITEUR / Pilote de transformation

PÈRE

FILS

PETIT-FILS

MONITEUR (Scrutateur / Event poller)

PROCESSUSRÉENTRANT

P1

M1

Évènements reçus

Évènements émis

Ordre de balayage

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.


3ème partie

Cas d’emploi – « Use case »Approche UML


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


Symbologie et représentation graphique

Cas d’utilisation

Scénario N°3Scénario N°2Scénario N°1

Description textuelle du cas

d’utilisation(Processus et

fonctions)

Diagrammes d’activités

Diagrammes états-transitions

Diagrammes de collaboration –

contexte acteurs

Diagrammes de séquences

Ensemble de scénarios explicitant le cas d’utilisation de façon à permettre la traduction

en concepts informatiques

Si nécessaires à la compréhension des scénarios


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


De la description d’un cas d’utilisationDe la description d’un cas d’utilisationla mise en pratique indispensable à une bonne communicationla 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


De la description d’un cas d’utilisationDe la description d’un cas d’utilisationd’un point de vue plus organisationneld’un point de vue plus organisationnel

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

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 :

Stricto sensu,c’est de la gestionde configuration

C.M.

Nécessaire dès qu’ontravaille en équipe et/ou sur la duréeet pour obtenir les satisfecits ISO, CMM,etc.


4ème partie

Comment modéliser - Méthodes et outils


Outils théoriques et concepts pour l’architecte modélisateur

Descriptions statiques du système

Descriptions dynamiques du système

OUTILLAGEEnsemblesRelations

Fonctions calculablesLangages formels

Systèmes de classification

OUTILLAGEAutomates

Machines à états finis(machines abstraites)

Systèmes à états-transitionsCommunication et théorie de

l’information

Nombreuses interactions et dépendances entre tous ces aspects (relations de dualité), d’où :

GRANDE COMPLEXITÉ


Fondements des sciences de l’information

Caractéristiques des problèmes

Peu de variablesPeu de variables Beaucoup de variablesBeaucoup de variables

Déte

rmin

iste

Déte

rmin

iste

Sto

chast

ique

Sto

chast

ique

Ordre simple Ordre complexe

Désordre simple Désordre 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

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


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 fonctionnelleDonnées / FluxInstructions-Fonctions / ProcessusContrôles / Pilotage

FONCTIONSCaractérisent la nature des transformations à effectuer ; elles

s’expriment à l’aide de langages (syntaxe + sémantique) Textes


Modèles dynamiques

Répond à la question : Comment ça marche Description des enchaînements des transformations

effectuées par les fonctionsModè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çusDescription 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 – TransitionsMachines à états finis (automates à mémoire)


5ème partie :

Exemple : Un contrôle aérien rudimentaire


Scène réelle

SYSTÈME DE CONTRÔLEDU TRAFFIC AÉRIEN

DÉTECTION de TOUS LES OBJETS

VIS

UA

LISA

TIO

N

CONTRÔLES / COMMANDES

E

Surveillance RADAR

ACTEURS

E/S


Diagramme de contexte / collaboration

RADARSCTA

DÉFENSEAÉRIENNE

RADARRADAR

VISU-ALISATION

OPÉRA-TEURS

PLANSDE

VOLS

EURO-CONTROL

Visualisation en temps réelde la situation aérienne auvoisinage de l'aéroport

Gestion de l'espace aérienpar les contrôleurs

Tenue à jour des plans de volpar les différentes compagniesaériennes accréditées

Dialogues avec les centres decontrôle européens

Dialogues avec la défense aérienne France + OTAN

Couverture aériennepar les radars civils

MÉTÉONATION-

NALE


FLOTS DE DONNÉES, PROCESSUS, STOCKAGE (1/2)

PLANSDE

VOLS

MONITEURCONSOLES

OPÉRATEURS

MONITEURCONSOLES

VISUALISATION

NOYAUDU

SYSTÈME

MONITEURDES

RADARS

TAMPON

ACTIVATION DUSYSTÈME DEVISUALISATION

ACTIVATION DUSYSTÈME DECOMMANDES

POSITION {x,y,z} ETIDENTIFICATIONDES OBJETSVOLANTS

Contient les extraits desplans de vol des avionssous contrôle du système

FORMATION DESTRAJECTOIRES

«PISTES»

COMMANDES DEGESTION DES «PISTES»

Msgx,y,… vers les SI des compagnies aériennes, avec accusés de réception (AR)


FLOTS DE DONNÉES, PROCESSUS, STOCKAGE (2/2)

RADARS

Mécanismede« polling»

GESTIONRADAR

FICHIERPISTES

COMMAN-DES

VISU

FICHIER PISTES

1 File d'attentepar RADAR

INTERFACE VISUALISATION

INTERFACE COMMANDESOPÉRATEURS

Messages àVisualiser avec AR

L'intégrité de cefichier est primordiale

TIMER

Gestionphysique

Gestionlogique

Pile

2 canaux sont prévus selon la nature des commandes(courtes, longues, prioritaires, …) avec accusés de réception AR

+AR

évènements

évènements

Documents

J.Printz / CNAM - CMSL / Conception des logiciels - Analyse fonctionnelle / Vers. 5.3Page 1 CONCEPTION DES LOGICIELS : Chapitre 2 LE SYSTÈME ET SON ENVIRONNEMENT