j.printz / cnam - cmsl / conception des logiciels - analyse fonctionnelle / vers. 5.3page 1...
Post on 04-Apr-2015
117 Views
Preview:
TRANSCRIPT
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
J.Printz / CNAM - CMSL / Conception des logiciels - Analyse fonctionnelle / Vers. 5.3 Page 3
1ère partie
Notions de théorie des systèmes
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 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]
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
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 5
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
J.Printz / CNAM - CMSL / Conception des logiciels - Analyse fonctionnelle / Vers. 5.3 Page 6
2ème partie
Description du contexte système et de la collaboration
entre acteurs
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 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 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
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 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 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
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 9
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
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 10
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)
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 11
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
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 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
<<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)
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 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î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.
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 14
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.
J.Printz / CNAM - CMSL / Conception des logiciels - Analyse fonctionnelle / Vers. 5.3 Page 15
3ème partie
Cas d’emploi – « Use case »Approche UML
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 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
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 17
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
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 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
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 19
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
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 20
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.
J.Printz / CNAM - CMSL / Conception des logiciels - Analyse fonctionnelle / Vers. 5.3 Page 21
4ème partie
Comment modéliser - Méthodes et outils
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 22
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É
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 23
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
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 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 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
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 25
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)
J.Printz / CNAM - CMSL / Conception des logiciels - Analyse fonctionnelle / Vers. 5.3 Page 26
5ème partie :
Exemple : Un contrôle aérien rudimentaire
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 27
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
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 28
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
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 29
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)
J.Printz / CNAM - CMSL / Conception des logiciels – Analyse fonctionnelle / Vers. 5.3 Page 30
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
top related