Guiochet CoursN7 vTOTALE

24/09/10
Vers une conception oriente objet des systmes embarqus
Jrmie Guiochet Universit Toulouse 3, LAAS-CNRS guiochet@laas.fr www.laas.fr/~guiochet
Support de Cours ENSEEIHT 3me anne AII
24/09/10
Plan du cours
Partie 1 Les systmes embarqus Une introduction

Chapitre 1: Introduction aux SE (dfinition, exemples, caractristiques gnrales) Chapitre 2: Les lments de la conception matrielle et logicielle Chapitre 3: La sret de fonctionnement Chapitre 4: Le temps rel
Partie 2 Le dveloppement des systmes (embarqus) : vers un processus de dveloppement orient objet

Chapitre 5: Gnralits gnie logiciel Chapitre 6: Unified Modeling Language Chapitre 7: Le Processus Unifi - Une Dmarche Oriente Modle
24/09/10
24/09/10
Crdits

Cours de Mario Paludetto (Conception SE + temps rel)
http://www.laas.fr/~mario http://www.laas.fr/laas/1-4287-Groupe-TSF.php http://www.irisa.fr/triskell/members/pierre-alain.muller
Cours de Jean Claude Laprie (Sret de fonctionnement)
Cours de Pierre Alain Muller (UML)
24/09/10
PARTIE 1 : Les systmes embarqus

Une introduction
24/09/10
24/09/10
Chapitre 1
Introduction aux systmes embarqus
24/09/10
Les systmes embarqus
Dfinition

Systme qui utilise conjointement matriel et logiciel pour raliser une fonction spcifique) pour raliser une fonction spcifique Fait partie d'un systme beaucoup plus vaste qui n'est pas ncessairement un ordinateur (systme enfoui, embedded system) Travaille temps contraint et de faon ractive avec l'environnement Consommation, encombrement, poids, dissipation thermique, etc. Robustesse, scurit, fiabilit, etc. Temps de rponse Cot, maintenance
Fortes contraintes :

Soppose linformatique gnraliste (Multi-usages et multi utilisateurs) Informatique embarque :

Ds les annes 80 Possibilit dembarquer de lintelligence -> souplesse et volution Aujourdhui : 5 % des CPU pour PC et 95 % pour embarqu
24/09/10
24/09/10
Systmes embarqus: Domaines d'application
Systmes orients calcul

Camras, appareils photo et TV numriques, etc. Multimdia, consoles de jeu, etc. Tlcommunications (tlphonie, GPS, etc.) Electro-mnager Automobile: ABS, Commandes moteur, navigation, etc. Chanes de fabrication et de montage, trains de laminoirs, traitements de surface, etc. Avionique, spatial et dfense: Calculateurs de bord, Commandes de vol, rgulation moteurs, guidage, maintenance, etc. Production, gestion et contrle de l'nergie
Systmes orients contrle

24/09/10
Premier exemple : Automobile
65 microcontrleurs embarqus aujourdhui dans une Mercedes-Benz classe S

moteur (richesse du mlange, injection, allumage, pollution, etc.) freins, tableau de bord, airbags, autoradio, vido, page automatique, systme de navigation, climatisation, rgulateur de vitesse, direction, stabilisation, contrle de trajectoire, dtection dobstacles, bote de vitesse dtection de sommeil, stop & go, etc.
24/09/10
24/09/10
Automobile (2)
Ex.: Systme ABS
Automobile (3)
Dans un proche avenir

Coordination vhicule avec infrastructure routire Coordination entre vhicules Par exemple pour faciliter le trafic ou viter les collisions
Disparition des liaisons mcaniques traditionnelles (colonne de direction, commande hydraulique, cble, etc.) est dj programme. Elles seront remplaces par des rseaux de modules lectroniques contrlant des actionneurs et des mulateurs (pour remplacer volant, pdales, etc.). On parle de technologie X-by-Wire.
24/09/10
10
24/09/10
Systmes embarqus dans lautomobile Automobile (4) Contexte gnral

Extrait de la prsentation de Joseph Beretta / PSA - 16 et 17 Juin 2003 http://www.systemes-critiques.org/SECC/ Gnse de Prolifration llectronique de automobile llectronique Intgration et maturit des systmes lectriques & lectroniques
lectricit de base
% du cot de l lectronique dans le vhicule
35 30 25 20 15 10 5 0
Lampes, radio, dmarreur, dynamo 1920 1940
Multimdia, Soupapes lectromagntiques Tlmatique, alternodmarreur Gestion dnergie Multiplexage, ABS Injection lectronique Rgulateur de vitesse Allumage lectronique Alternateur
GMP
Ecole 11 Mines de Nancy des
1960 41
1980
2000
2010
24/09/10 ASS SI144
Deuxime exemple : faux dparts
Systmes Embarqus et performances temporelles

fi Con e? anc bili Fia t?
gr De
e d
rt ca
12
Images IAAF championnat du monde 2003 au stade de France
ave
ra c la
lit
24/09/10
24/09/10
Faux dparts (2)
Le systme ou Les systmes?

Carolina Kluft
Dparts Surveillance Chronomtrage
Anna Guevarra Cathy Freedman
Internet
Camera Camera Salle vido
Chrono Chrono
Michael Johnson
24/09/10
Images IAAF
Faux dparts (3) Exigences fonctionnelles
Le signal de dpart doit tre peru au mme moment par tous les athltes.

=> Dclenchement par un pistolet reli au systme => Haut-parleur pour signal de dpart acoustique dans chaque starting-block => Capteurs d'efforts prcis et identiques sur les 8 couloirs Au moment du dpart, l'athlte agit sur les capteurs. Le Systme collecte les temps de dpart de chaque athlte et les compare au temps de seuil rglementaire (0,1s). Si un athlte a ragi trop vite, le starter reoit un beep dans son casque tlphonique. Affichage et imprimante dsignent la (es) piste(s) fautive(s).
Starting-blocks avec capteurs de dpart intgrs.

Calcul des faux dparts:
14
24/09/10
24/09/10
Faux dparts (4) La vue utilisateur
Technique et dynamique du dpart 100m
15
24/09/10
Faux dparts (5)
Contraintes temporelles et exigences systme
= Propagation son haut-parleur couloir athlte
= Temps de dpart rel
Capteur 150kg Capteur 27kg
t0?
Fentre faux dpart t0? t0? (rglement)
Temps de calcul (grossi) Correction des mesures Affichage et signalisation t
Signal Pistolet 16
Signal hautparleur couloir athlte
Instant de perception Athlte
Limite faux dpart 0,1s
Signal capteur starting-block
24/09/10
24/09/10
Architecture Systmes embarqus
Lister (et/ou dessiner) rapidement les lments dun tlphone portable (le votre par exemple) sans regarder le transparent suivant :
17
24/09/10
Exemple darchitecture: System on Chip (SoC) Le tlphone portable
Contraintes: taille, poids, consommation, performance tlcom, disponibilit
18
24/09/10
Exemple darchitecture: System on Chip (SoC) Appareil photo numrique
Contraintes: taille, poids, consommation, temps dacquisition, stockage, etc.
19
Systmes embarqus: particularits
20
24/09/10
10
24/09/10
Chapitre 2
Les lments de la conception matrielle et logicielle
21
24/09/10
Electronique ou informatique ?
Implmentation matrielle :

Plus rapide mais plus chre Obsolescence rapide des composants et des techniques Plus lent mais plus flexible et volutif
Implmentation logicielle :
Evolution vers toujours plus dintgration (System On Chip : systme sur une puce) Frontire de plus en plus floue avec par exemple les circuits de logique programmable qui offrent rapidit et flexibilit
22
24/09/10
11
24/09/10
Electronique ou informatique ? (2)
Paramtres du choix :
Cot global, fonctionnalits & performances, fiabilit, robustesse, contraintes matrielles (poids, encombrement, consommation,), environnement, dure de vie de lapplication, dlai de mise sur le march, etc. Exemple du spatial : composants prouvs mais de production de une ou quelques units (obsolescence pas un problme)
Approche traditionnelle de dveloppement dun systme embarqu

Choix et dveloppement de larchitecture matrielle : composants, capteurs, processeur, etc. Ralisation du logiciel pour raliser lapplication avec le matriel
24/09/10
23
Electronique ou informatique ? (3)
Complexit croissante

Systmes de plus en plus complexes Optimisation globale en plusieurs itrations Correction des erreurs, maintenance et volution des systmes De plus en plus rduit Participe au cot Concurrence (appel doffre, dlai de mise sur le march, ) Exemple de lindustrie automobile : 1 2 ans aujourdhui pour 3 5 ans avant Il ne faut pas sacrifier la fiabilit/scurit/disponibilit/etc.
24/09/10
Temps de dveloppement

24
12
24/09/10
Technologie cl: Processeurs

Grande varit darchitecture de processeurs Un processeur nest pas ncessairement programmable On distingue gnralement

Les processeurs usage gnraux (GPP) Les processeurs spciques certaines applications (Application Specic Processor, ex: DSP) les processeurs ddis une tache (single purpose processor, ASIC) pSoC (Programmable System-On-Chip) Mixte de technologies

NB : Orientation Systme sur Composant

Association microcontrleur DSP Association microcontrleur logique programmable Autre
25
24/09/10
Loi de Moore

Le nombre de transistors des processeurs (circuits complexes) double tous les deux ans (1975) Remarquablement vrifie pour les processeurs Intel
26
13
24/09/10
Processeurs usage gnral (1)

Processeur programmable utilis pour de nombreuses applications (microprocesseur) Caractristiques

Une mmoire pour le programme Un chemin de donn gnraliste comprenant un unit arithmtique et logique (ALU) puissante et un gros banc de registre Time to market et cot Flexibilit
Intrt :

Exemple: Pentium, PowerPC, ARM, MIPS, etc.

27 24/09/10
Processeurs usage gnral (2) Les CPUs utiliss pour lembarqu
source: T. R. Halfhill. Embedded Market Breaks New Ground. Microprocessor Report, January 2000
Systmes embarqus COO J. Guiochet 24/09/10
14
24/09/10
Processeurs ddis
Circuits intgrs destins excuter exactement un programme: coprocesseur, acclrateur matriel ou priphrique. Caractristiques:

Contient seulement les composants ncessaires lexcution du programme concern en gnral pas de mmoire de programme Rapidit Faible consommation Surface
Intrt :

Exemple: unit de calcul ottant, contrleur USB, PCMCIA, decoder MPEG, etc.
Systmes embarqus COO J. Guiochet 24/09/10
Processeurs spciques
Processeur programmable optimis pour une classe particulire dapplications (ASIP: Application Specic Integrated Processor). Caractristiques:

Mmoire de programme Chemin de donne optimis Units fonctionnelles spciques Flexibilit performances: surface, rapidit, consommation
Intrt :

Exemple: DSP, microcontrleur (processeur 4bits, 8bits).

24/09/10
Systmes embarqus COO J. Guiochet
15
24/09/10
Les moyens de communications embarqus

(Quelques exemples)
24/09/10
Les moyens de communications embarqus (2)
Bluetooth

Faible porte Faible consommation Faible cot Rseaux rduits Communication de priphriques dans un espace dopration personnel
24/09/10
16
24/09/10
Le bus CAN (Controller Area Network)
Wifi : Communication sans fils
2 modes : infrastructure et ad-hoc
Basic Service Set

Independent Basic Service Set

24/09/10
17
24/09/10
I2C : faire communiquer entre eux des composants lectronique trs divers grce seulement 3 fils (Signal de donne ,horloge et masse)
35
24/09/10
La golocalisation

Fournir la position, la vitesse, lorientation, ... dun objet (informatique) une application Ces donnes sont des entres de lapplication Technologies dacquisition

OutDoor : Satellite (GPS), Cellulaire (GSM), InDoor : GSM, WiFi, Bluetooth, RFID,
36
24/09/10
18
24/09/10
La golocalisation : applications outdoor (innombrables)
Civils

Gomtre, Cadastre, BTP, Agriculture, Transport (Assistance la navigation, ) Urgence (Guidage des secours, Quel est le vhicule de patrouille le +proche ) Loisirs (Alpinisme, Randonne,Voile, ) Traabilit(e-Track) (Conteneurs, Courrier rapide, Flot de vhicule, Force commerciale, Flamme olympique pour Atlanta 1996, ) Scurit des biens (vol de vhicule, de conteneurs, ) Ralit augmente et Aide au Handicap (non voyant) Commerce (quel est notre magasin le plus proche de chez vous ?) Guidage darmement (missile de croisire, ) Assistance des troupes
Militaires

37
24/09/10
La golocalisation : applications indoor
Aide la navigation

Supermarch, Muse, Parc thme Bibliothque Hpital
38
19
24/09/10
La golocalisation : GPS Terminals

Modules GPS intgrables Terminaux embarqus
Dans un vhicule, un tlphone cellulaire, un appareil photo, Avec/sans cran Journal de positions intgr

Terminaux portables

Les positions peuvent tre infalsifiables(signature lectronique ?) Fonctions Homme la mer
39
24/09/10
Systmes dexploitation pour lembarqu

Grande htrognit Mmoire et Processeurs limites Capacit de communication Consommation nergie Contraintes temps rel
Non TR, soft RT, hard RT
40
24/09/10
20
24/09/10
Plusieurs approches pour un OS pour lembarqu

Plus dune centaine dOS embarqus Noyau lagu :

Dur dlaguer dans la dnomination (Linux, RTLinux, CLinux, etc.) Cible un march large donc fonctionnalits en trop (VxWorks, QNX, pSOS, etc.) PalmOS, Symbian Couteux en temps. Difficilement portable et maintenable Think, eCos Intermdiaire entre application et systme Souvent trop gros mais invitable dans un systme distribu
24/09/10
OS Commercial OS Domaine
OS Custom

41
OS modulaire et flexible Middleware/Intergiciel
OS pour lembarqu
Acadmique :

ExoKernel, SPIN, Think Choices, OSKit, Coyote, PURE,2K VxWorks, QNX, pSOS, WindowsCE JavaOS, Jbed, MMLite, icWORKSHOP,Pebble Open Source de qualit industrielle : Linux, Clinux,eCos
Commercial

LIRE : L. FFriedrich, J. Stankovic, M. Humphrey, M. Marley, J. Haskins, Survey of Configurable, Component-Based Operating Systems Embedded Applications ,IEEEMicro, May-June 2001, pp54-68
42
24/09/10
21
24/09/10
Comparaison OS / HW
Processeur RAM
43
24/09/10
Chapitre 3
La suret de fonctionnement
44
24/09/10
22
24/09/10
Systmescri,ques
Systmes critiques : Ariane 5 vol 501
46
24/09/10
23
24/09/10
Systmes critiques (2)
Therac 25 1985
Ariane 5 1996 USA Blackout 2003
24/09/10
Systmes embarqus critiques

Critique : la plupart du temps du point de vue de la scurit innocuit mais aujourdhui de plus en plus dimportance de la scurit-confidentialit Systmes embarqus de plus en plus communicants scurit des donnes ou protection contre attaques On distingue plusieurs niveaux de criticit selon quun dysfonctionnement met en jeu:

la scurit des personnes (par ex: accident davion) ; la russite dune mission (par ex: mauvaise trajectoire dun satellite); la russite conomique du produit (par ex: mise sur le march tardive dune console de jeux);
Que faire : valuer les risques et prendre les mesures ncessaires pour les rduire Utilisation de techniques de la sret de fonctionnement

Redondance de certains composants Mode de fonctionnement dgrad mais sr qui permettra dattendre une intervention
24/09/10
48
24
24/09/10
Disponibilit / Fiabilit
Systmescri,ques (4)
Attributs Confidentialit Intgrit Maintenabilit Prvention des fautes Tolrance aux fautes
Dtection derreur Rtablissement du systme Traitement derreur Traitement de faute Vrification statique Vrification dynamique
Scurit-innocuit
Sret de fonctionnement
Moyens
En dveloppement
Vrification Diagnostic Correction
Elimination des fautes

En vie oprationnelle
Vrification de non-rgression Maintenance curative ou prventive
Evaluation ordinale ou qualitative
Prvision des fautes
Evaluation probabiliste ou quantitative De dveloppement
Modlisation Tests oprationnels
Fautes Entraves Erreurs Dfaillances
Physiques Dinteraction
Exemple : Architecture des calculateurs Airbus (1)
Mmoire 28V Alim.
Processeur
E/S
Voie de Commande Voie de Surveillance

Alim. Mmoire Processeur E/S
Protection foudre, EMI, sur/sous tension

50 24/09/10
25
24/09/10
Chanes de production de logiciel diffrentes

quipes de conception diffrentes (Paris / Toulouse) langages diffrents outils de programmation diffrents organisation diffrente des programmes allocations mmoires diffrentes algorithmes diffrents

Rgles damplification de la diversification

trigonomtrie avec coordonnes polaires vs. coordonnes cartsiennes fonctions numriques tabules vs. calcul par quation
optimisations avec des buts diffrents (temps vs. taille programme) prcisions de calcul diffrentes (12 bits vs. 8 bits) calculateurs de fabricants diffrents processeurs de types diffrents
24/09/10
Diversification au niveau systme

51

Airbus 320
Becs et volets
SFCC1 SFCC2
Ailerons
ELAC1 ELAC2
Spoilers
SEC1 SEC2 SEC3
Plan horizontal Gouvernes de profondeur Gouverne de direction

52
FAC1 FAC2
26
24/09/10
Exemple 2 : Boeing 777 (1)

Bus de donnes ARINC 629
Positions des commandes pilote & des gouvernes Voie1 Voie2 Voie3
Gauche Centre Droite

Commandes des gouvernes
AMD 29050
ACE
Motorola 68040 Intel 80486 PFC gauche PFC centre PFC droite
Actuateurs Actuateurs Actuateursde surfaces surfaces de Actionneurs surfaces de vol vol gouvernes vol
Commandes pilote
PFC : Primary Flight Computer ACE : Actuator Control Electronics

Processeurs et compilateurs des PFC Fonctions commande et moniteur des ACE Donnes inertielles par dissimilarit des units
ADIRU (Air Data Inertial Reference Unit) SAARU (Secondary Attitude and Air Data Reference Unit)
Matriel doubl et dissimilaire dans lAFDC (autopilote)
54
24/09/10
27
24/09/10

L C R
Left PFC
Spoilers Flaps Ailerons
Center PFC
Elevator Rudder
Other
ARINC 629
Right PFC
Other PFC : Primary Flight Computer
Other
ACE ACE ACE ACE Pilots
ACE : Actuator Control Electronics

55 24/09/10
Chapitre 4
Le temps rel
56
24/09/10
28
24/09/10
Systmes embarqus: configuration de base
Exemple de configuration classique
Commande en Temps Rel d'un Procd Industriel
Panneau local de commande et de contrle
SYSTEME DE COMMANDE
ACTIONS
PROCEDE Industriel
Compte-rendu d'tat (capteurs) Oprateur. SYSTEME DE COMMANDE : { Systme matriel + Systme logiciel} Systme Electro-Informatique : {
(Hardware) + (Software) }
57
24/09/10
Systmes embarqus: Temps rel
Dfinitions dun systme temps rel
Systme qui doit satisfaire des contraintes temps de rponse explicites et bornes.
Si les bornes temporelles ne sont pas respectes, des dgradations des performances et des mauvais fonctionnements apparaissent.
Systme dont lexactitude dpend non seulement des rsultats logiques mais galement des instants o ces rsultats sont fournis.
Systme Informatique de pilotage Entres Mesures Procd pilot (Chariots, robots, lectrovannes, Capteurs ) Evnements Commandes Evnements Sorties
24/09/10
Signaux changs
58
29
24/09/10
Systmes embarqus: Les besoins dits "temps rel"
Respect des contraintes temporelles

Matrise des temps dexcution (approximation du pire cas) Ordonnancement des diffrents traitements sur la ressource processeur Dtection des Violations Temporelles: Dlais et Chiens de garde.
Diversit des entres/sorties Comportements // et concurrents Support doprations distribues et fiables Sret de fonctionnement Dterminisme Prdiction
59
24/09/10
Systmes embarqus: classes de systmes temps rel
Systmes temps rel strict/dur (Hard Real-Time) dits critiques: le non respect d'une chance temporelle a des consquences graves (humaines, conomiques, cologiques, )
Commande et contrle dans l'avionique, le spatial, le nuclaire, la production de matriaux toxiques,
Systmes temps rel souple/mou (Soft Real-Time): tolrance du non

respect d'une contrainte temporelle ou d'un dfaut systme (fonctionnement en mode dgrad, ou cas d'une garantie probabiliste) ex.: dgradation des performances temporelles de l'injection lectronique mais un dfaut de priodicit relative est de type critique (dtrioration moteur possible)
De nombreux systmes ont des contraintes strictes imposes par les oprations de l'environnement
24/09/10
60
30
24/09/10
Systmes embarqus: Dveloppement des STR - Intro
(1)
Le pass

Mthodes maison (aucun formalisme, aucune vrification) Programmation de bas niveau Recherche de rapidit tout crin (politique du qui peut le plus, peut le moins) valuation des performances posteriori Pas vraiment de mthodologie couvrant le cycle de vie Il faut excuter le plus vite possible Aprs les tests le logiciel ne peut plus faillir
Et les fausses ides

Nombreuses

L'ordonnancement
Ordonnancement par heuristiques Explosion combinatoire Systmes non dterministes Ne peut s'appliquer qu'aux systmes simples (temps de calcul borns et mesurables, ordonnancements faisables tches priodiques- )
24/09/10
tches sur-estimes devient le Problme majeur des STR classiques
61
(2)
Le prsent et le futur

Besoins:
automatismes fiables, sr, puissants, rapides, maintenables et peu coteux

valuation fine des besoins non fonctionnels Fini les Mthodes et outils maison Dveloppement sur des bases formelles Dveloppement en faisant abstraction du support matriel (codesign en VHDL) Cycle de dveloppement compos de nombreux cycles complets itratifs intgrant en priorit:

Ractions (aux erreurs du pass)

Vrification (preuves) Validation (tests fonctionnels, simulation et prototypage virtuel)
Intgration de techniques formelles dans les mthodes Ordonnancement
Intgr aux modles et aux langages

SA-RT, UML, + Automates + RdP Ada, Occam Esterel, Lustre,
A dfaut, noyaux rduits politiques dterministes

24/09/10
62
31
24/09/10
(3)
Vue Globale
L'environnement est asynchrone
Les instants d'arrive des donnes sont quelconques et non connus d'avance Les sorties sont fournir des chances qui peuvent tre variables Environnement Deux types de traitement intimement lis Aspect ractif STR Interaction avec l'environnement Matrise du temps et des chances Contrle des tats des processus Environnement Aspect transformationnel Calculs et traitements propres l'application
Fonctions de transfert, quations diffrentielles, trajectoires,
Calculs de donnes internes inhrentes la structuration

24/09/10
63
Dveloppement des Systmes embarqus - Les courants de pense

STR
Dichotomie Partie ractive Partie transformationnelle

Algorithmes temps constant (any time)
Modles dterministes
Vision synchrone
Ralisme de l'hypothse Synchrone forte? Hypothse synchrone forte: temps de calcul et de communications Dichotomie avec l'environnement = 0 (diffusion, broadcasting ) asynchrone Langages formels: Statecharts, Esterel, Lustre, Signal, Moyens de structuration des systmes complexes? Vision asynchrone

Modles peu formels: SA-RT, HOOD, UML Modles formels : automates, rseaux de Petri Langages peu formels: Assembleur, Ada, Occam Excutifs temps rel
64
Smantique temporelle faible Attention aux excutifs politiques non dterministes Le concepteur doit vrifier le non dterminisme tous les niveaux
24/09/10
32
24/09/10
Dveloppement des Systmes embarqus: Approches Synchrone / Asynchrone (1)
SYNCHRONE: Qui se produit dans le mme temps. []
[En parlant d'un phnomne] Qui se produit au mme moment qu'un autre ou intervalles rguliers par rapport un autre. Mouvement, oscillation synchrone. [] 1. [En parlant d'un mode de transmission informatique] "Dans lequel l'instant de l'mission de chaque lment binaire est dtermin par des signaux rgulirement espacs dans le temps" (SCOM Informat. 1977). 2. [En parlant d'un mcanisme] Qui produit des mouvements synchrones. Calculateur synchrone. "Calculateur numrique ou ordinateur rythm par une horloge mre dans lequel chaque opration lmentaire dmarre sur un top horloge et dure un nombre fini de tops d'horloge" (Morvan 1980). []. [Le TLF informatis, http://zeus.inalf.cnrs.fr/tlf.htm]
65
24/09/10

Approches synchrone et asynchrone
Ractions des stimuli externes
Machine asynchrone Machine synchrone Stimuli externes
Le temps de raction est variable
Le temps de raction est nul (par hypothse)
Lenvironnement est asynchrone par nature : stimulus : raction

24/09/10
Fonctionnement correct si pour chaque couple stimuli-rponse: le temps de raction << temps de rponse
66
33
24/09/10
Dveloppement des Systmes embarqus Approches Synchrone / Asynchrone (3)
Hypothse Synchrone:
Problmes:

Temps de raction du systme ngligeable dynamique de l'environnement Le Systme est toujours "en phase" avec son environnement, toujours prt accepter des entres. Pas besoin de premption (interruption / reprise) Pas de "pseudo-paralllisme". Si paralllisme toutes les oprations se font en phase. Pas d'ordonnancement. Dterminisme par construction. Langages Synchrones: Lustre, industrialis dans l'Outils SCADE de Telelogic (ex-Verilog, www.telelogic.com). Airbus, Eurocopter, Interactions avec l'extrieur Asynchrone. Couplage trs fort entre les modules. Peu flexible.
24/09/10
67

Lapproche synchrone et le temps
Synchronisation des entres
Machine synchrone Stimuli synchroniss par la machine Stimuli externes
En ralit, le temps de raction aux stimuli est non nul; mais les E/S sont synchronises par rapport aux actions. Un nouvel vnement ne provoquera la raction associe qu la fin des ractions en cours. 24/09/10
Fentre dinsensibilit
procd
Machine de synchronisation Machine Synchrone
Machine dexcution
68
34
24/09/10
Hypothse Asynchrone:

La majorit des environnements sont asynchrones ncessit de dialogue Absence de simultanit d'vnements Simultanit des traitements (tches //) Concurrence des ressources Le temps de raction du systme n'est plus nglig une action possde un dbut, une dure de travail et une fin Ncessit de ragir de manire dynamique aux urgences externes (gestion des modes de fonctionnement). Premption ncessaire. Qui prempte qui? Ordonnancement.
24/09/10

Exemple support:
Rgulation de pression carburant
Accumulateur$ Pompe de pression$ Pression$ Valve$ Electro-vanne$ V$ H$ B$ Rservoir$
70
H$ Fonctions Vider$ B$ Remplir$ F$ F$ RgulerBO$ C$ RgulerBF$ P$ P$ R$ V$
Racteur$ C$
P$ Calculateur$ R$
H$ B$
Dpart$ Arrive$
Systme Carburant simpli$
24/09/10
35
24/09/10

Commande ractive synchrone: les entres sont synchronises sur la fin de laction en cours. La raction du systme est perue comme immdiate. Vider$ Remplir$ RgulerBO$ RgulerBF$ Occurrences F des vnements du procd Remplir$ RgulerBO$
Equivalence Occurrences
synchronises sur les actions
Observation par le synchroniseur
C
Prises en compte retardes
Occurrences des vnements du procd
B
Prise en compte immdiate
24/09/10
Dynamique du procd lente par rapport au temps dexcution Commande non premptive 71
Observation immdiate et mmorisation

Ralisation d'une commande synchrone
Initialisations Vecteurs d'IT Dmasquer BCFH
Attente B Masquer CFH Remplir Dmasquer CFH
Attente C Masquer BFH RgulerBF Dmasquer BFH
Attente F Masquer BCH RgulerBO Dmasquer BCH
Attente H Masquer BCF Vider Dmasquer BCF
Fermeture de la fentre d'observation Action Ouverture d'une fentre d'observation
72
24/09/10
36
24/09/10

Commande ractive asynchrone : les vnements du systme sont observs en permanence, la raction du systme peut tre diffre.
Vider$ Remplir$ RgulerBO$ RgulerBF$ Remplir$ RgulerBO$
Remplir plus important que RgulerBO! RgulerBF plus important que Vider Reste de l'Action diffr$
Action immdiate$
Occurrences observes Observation permanente Occurrences des vnements du procd
B
Suspendue$
H
Diffre$
F
Observation immdiate
B
Prise en compte immdiate
24/09/10
73
quivalence

Ralisation d'une commande asynchrone
Initialisations Vecteurs d'IT Dmasquer BCFH
Attente B Masquer CFH Remplir Dmasquer CFH
Attente C Masquer FH RgulerBF Dmasquer ()
Attente F Masquer H RgulerBO Dmasquer BC
Attente H Masquer () Vider Dmasquer B Fermeture l'observation des v. moins importants Action Rouverture de l'observation des v. moins importants
Remplir > RgulerBF > RgulerBO > Vider 74 24/09/10
37
24/09/10
PARTIE 2 : Le dveloppement des systmes (embarqus)

Un processus de dveloppement Orient Objet
75
24/09/10
Chapitre 5
Gnralits en Gnie Logiciel
24/09/10
38
24/09/10
Contexte
(1)
: Technologies
77
24/09/10
Contexte
(2)
: Hard contre Soft
78
24/09/10
39
24/09/10
Contexte
(3)
: La "crise" du Logiciel
79
24/09/10
Nature du Logiciel
Immatriel

Pas de cot de production, uniquement de dveloppement Peut tre copi l'identique, l'infini Rutilisation trs avantageuse
(mais attention au cot d'adaptation !)
Pas d'usure. Les fautes sont l ds le dbut.
Trs sensible aux erreurs.

Pas de continuit du comportement Impossible tester compltement (pas d'interpolation possible)
Pas de structure naturelle. Amorphe. Le logiciel doit tre explicitement et volontairement structur.
24/09/10
40
24/09/10
Qualit du Logiciel
(1)
Point de Vue de lUtilisateur

Utilit

Validit (Exactitude du Comportement par / au Service attendu) Compltude du Comportement Efficacit / Performance Cots d'Utilisation Facilit de Comprhension pour l'Utilisateur Qualit de la Documentation Utilisateur Simplicit dUtilisation Disponibilit Fiabilit Scurit-Innocuit ...
Ergonomie

Sret de Fonctionnement ( Robustesse)

24/09/10
Qualit du Logiciel
(2)
Point de Vue du Dveloppeur

Facilit de Validation

Compltude des spcifications Localit Testabilit Modularit / Structuration Simplicit de Code (Algorithme, Structure) Concision Lisibilit Compltude Indpendance vis vis d'un plate-forme Utilisation de Standards
24/09/10
Facilit d'Adaptation (Extension, Correction)

Portabilit, Compatibilit (Rutilisation)

41
24/09/10
Qualit du Logiciel
(3)
Rpondre aux besoins fonctionnels / non fonctionnels

Fonctionnels: Directement lis la rsolution du problme pour lequel le logiciel est conu. (Le quoi.) Non Fonctionnel: Sret de fonctionnement (Scurit, Confidentialit, Robustesse, ), performances (temporelles, consommation), autres contraintes de dveloppement (ergonomie, compatibilit, etc.), etc.
24/09/10
Projet Logiciel
(1)
84
24/09/10
42
24/09/10
Projet Logiciel
(2)
85
24/09/10
Projet Logiciel
(3)
Notion de Projet Logiciel

Analyse des besoins
Erreurs de besoins
Conception
Erreurs de conception
Codage
Dtection et correction des erreurs
Utilisation Petits Projets : Mthode descendante oriente programme 86 24/09/10
43
24/09/10
Projet Logiciel

(4)
Un projet logiciel = suite d'tapes Produit de l'information. Mais pas uniquement code final. Englobe documentation, partie trs importante.

Documentation externe: pour l'utilisateur Documentation interne:

Retour d'exprience, projets suivants Maintenance: mmoire sur l'intrieur du logiciel Mmoire de ce qui a t fait, pourquoi, comment. Banc de test, jeux de test
Partie du Code non livre, mais essentielle
Chaque tape: transforme de l'information. Une grande partie: forme crite = documentation.
87
24/09/10
Processus de Dveloppement (1) des petits et grands projets Particularits

Petits Projets Utilisateur Documentation utilisateur Validation Cot des modications Spcication des besoins Informations sur l'tat du projet Erreurs courantes Protection contre les erreurs d'utilisation Interactions avec l'environnement versions 88 Contrle des L'utilisateur est le ralisateur minimale (aide mmoire) Minimale (optionnelle) Faible Minimale, optionnelle (inutile?) Toutes dans la tte d'une seule personne de programmations : - algorithmiques, syntaxiques, logiques Optionnelle, minimale Peu Informel Grands Projets L'utilisateur est diffrent du ralisateur Importante (ducative)
Importante et indispensable Elv Ncessaire et importante
Trs rpartie sur les quipes et les personnes - de spcication des besoins hypothses incompatibles, incohrentes - de programmation (les mmes) Indispensable et importante Nombreuses Ncessaire et complet
24/09/10
44
24/09/10
Processus de dveloppement
(2)
Cycle de Vie d'un Logiciel

" tapes par lesquelles passe le processus de dveloppement d'un logiciel. "
[H. Abrias, Dict. Encyclopdique du Gnie Logiciel]
Analyse des besoins
Conception Architecturale
Conception Dtaille
Codage
Vrication et maintenance
24/09/10
Processus de Dveloppement
(6)
Cycle de Vie en V avec tests et prototypes

Le plus utilis ces 20 dernires annes
Planication des Tests Systmes Planication des Tests d'Intgration Planication des Tests Unitaires Tests Unitaires Tests Systmes Tests d'Intgration
Analyse des besoins
Prototypage d'valuation
Conception Prliminaire Conception Dtaille
Prototypage d'valuation
Prototypage d'valuation Systmes embarqus COO J. Guiochet
Codage
24/09/10
45
24/09/10
(7)
Propagation des erreurs dans le cycle de vie en V

Erreurs de Spcications Tests Systmes Tests d'Intgration Tests Unitaire Codage
Analyse des besoins Conception Prliminaire Conception Dtaille
Erreurs de Conception
Erreurs de Codage
91
24/09/10
(8)
Un Processus Itratif: Cycle de Vie en Spirale

Tests REALISATION Tests dintgration unitaires Codage TESTS Tests de validation
Prototypes itratifs
Conception dtaille CONCEPTION
RECETTE EXPLORATION
Conception architecturale Analyse Objets Systmes embarqus COO J. Guiochet Analyse systme ANALYSE
Analyse des besoins
Ampleur / Risques
24/09/10
46
24/09/10
mthodes, techniques, outils
(9)
$ $ $ $ $
Analyse (Sw et Hw)
: DFD, CFD, SADT, SA-RT... OOA, UML
Conception : SA-RT, SASS ... OMT, HOOD, UML, PDL, VHDL, VHDL-AMS... Comportements : Logique, MEF, StateCharts, Rseaux de Petri, ... Langages : Macro-Assembler, C, Pascal, Modula, Ada, C, C++, Java ... Outils : Select-Yourdon, Statemate, Design/IDEF, Rose, Rapsody Design/CPN, STOOD (HOOD), Select-OMT, Umbrello, ArgoUML Rapsody, Rational Rose, ... Prototypage virtuel (simulation et co-simulation): Mentors (VHDL), PTOLEMY,
93 24/09/10
Chapitre 6
Conception oriente objet avec lUnified Modeling Language (UML)
94
Systmes Embarqus COO J. Guiochet
24/09/10
47
24/09/10
Plan
1 - Do vient lapproche objet ? 2 - Les principaux diagrammes dUML 3 - Objets et classes 4 - La dynamique des objets 5 - Les cas dutilisation 6 - Depuis les meilleures pratiques de dveloppement logiciel au Processus Unifi 7 - Exemple dapplication 8 - Annexes
95
24/09/10
1 Do vient lapproche objet ?
96
24/09/10
48
24/09/10
Modlisation objet
Problmatique

Gestion de la complexit Approches de modlisation Gense dUML
Unification des mthodes objet
97
24/09/10
Complexit des logiciels
La problmatique du domaine Le processus de dveloppement Linhrente flexibilit du logiciel
98
24/09/10
49
24/09/10
Consquence de la complexit

Le risque de dfaillances graves est lev La mise au point est lente et chaotique La maintenance est disproportionne Le cot est astronomique Crise du logiciel (70)
99
24/09/10
Gestion de la complexit
A dfaut de rduire la complexit il faut la matriser

Donner une illusion de simplicit => modliser Application de critres de partitionnement => dcomposer
100
24/09/10
50
24/09/10
Notion de Modle
(1)
L'activit de dveloppement d'un systme besoin d'un reprsentation des concepts manipuls (du logiciel, de l'environnement, du matriel, ) Exemple de Modles pour des personnes:
Photo d'identit, statistiques dmographiques, bonhomme "fil de fer"
Notion de Modle / de Modlisation
Peut reprsenter quelque chose (l'original du modle) qui existe dj, mais aussi quelque chose qui n'existe pas encore. Est une abstraction de l'original. Seuls certains aspect, certaines proprits de l'original sont pris en compte. Sert un objectif, a un but. C'est uniquement par rapport ce but que l'on peut juger de la qualit d'un modle.
24/09/10
Notion de Modle
(2)
On utilise un modle quand:

La ralit est trop complexe pour pouvoir directement raisonner sur elle (simplification) On veut oprer une mesure, qui dans l'absolu n'est pas possible (abstraction) Une opration dans la ralit s'avre risque, est difficilement rversible (reprsentation)
Concept Modication risque Modlisation Modle Descriptif Modication "virtuelle" Modle Prescriptif
24/09/10
102
Ralisation Mise en uvre
51
24/09/10
Notion de modle

Un modle = une vision Lhgmonie du bloc et de la flche
24/09/10
Notion de modle
24/09/10
52
24/09/10
Notion de modle
(3)
Lister les langages de modlisation que vous connaissez :

Modlisation comportementale
Modlisation statique/structurelle
105
24/09/10
Rle de la dcomposition

Diviser pour rgner Raffinage rcursif jusqu obtention dlments comprhensibles Division intelligente de lespace des tats dun systme
106
24/09/10
53
24/09/10
Dcomposition algorithmique
(aussi appele fonctionnelle)
Approche traditionnelle Chaque module reprsente une tape du processus global Dcomposition fonctionnelle depuis le cahier des charges jusquau sous-programme
107
24/09/10
Dcomposition algorithmique
La fonction donne la forme du systme
108
24/09/10
54
24/09/10
Dcomposition objet

Approche plus rcente (en informatique) Chaque module reprsente un objet du domaine de lapplication Les objets sont des entits autonomes qui collaborent afin de raliser un projet global
109
24/09/10
Dcomposition objet
La fonction est ralise par des objets collaborants
110
24/09/10
55
24/09/10
Dcomposition / Composition

Le terme dcomposition objet est rducteur Lapproche objet nest pas seulement descendante Approche descendante, ascendante, rcursive, itrative, incrmentale...
111
24/09/10
Comparaison fonctions / objets

Les deux techniques de dcomposition sont intressantes Elles sont trs diffrentes Il faut en choisir une pour commencer dcomposer Puis se servir du rsultat comme cadre pour exprimer lautre point de vue
112
24/09/10
56
24/09/10
Approche fonctionnelle

Semble intuitive Mise en avant du FAIRE Bien adapte lorsque tout est connu MAIS

Architecture rigide Extension difficile Peu adapte la dcouverte
113
24/09/10
Approche objet

Mise en avant de lETRE Simple (petit nombre de concepts de base) Raisonnement par abstraction (objets du domaine) Adapt pour lexploration et lvolution MAIS
Droutant pour les habitus de la dmarche fonctionnelle
114
24/09/10
57
24/09/10
Avantages de lobjet

Conduit des modles plus stables
Bass sur le monde rel Evolutivit Facilite la rutilisation
Structure indpendante des fonctions
Encapsule la complexit
115
24/09/10
La complexit des logiciels : conclusion

Le logiciel est complexe par nature Il faut grer cette complexit Les systmes peuvent tre dcomposs selon ce quils font ou selon ce quils sont Lapproche objet gre plus efficacement la complexit (que lapproche fonctionnelle)
Rutilisabilit, Evolutivit, Stabilit
116
24/09/10
58
24/09/10
Unification des mthodes objet

Appel aux propositions de lOMG (groupe international
de standardisation)
Dmarche dunification UML (Unified Modeling Language)
117
24/09/10
De quoi a-t-on besoin ?
Un langage de modlisation

Notation claire Smantique prcise
Un processus de gnie logiciel
Mthode = Langage + Processus
118
24/09/10
59
24/09/10
Langage de modlisation

Gnrique Expressif Flexible (configurable, extensible) Syntaxe et smantique Unification par convergence
119
24/09/10
La notation unifie UML

Base sur les mthodes de BOOCH, OMT et OOSE Influence par les bonnes ides des autres mthodes Mrie par le travail en commun
120
24/09/10
60
24/09/10
Evolution dUML
aot 2005 Septembre 2001
UML 2.0 (spcification disponible sur

www.omg.org)
UML 1.5
UML 1.0
1996
1995
121
24/09/10
En rsum

UML est une notation, pas une mthode UML est un langage de modlisation objet UML convient pour toutes les mthodes objet UML est dans le domaine public
UML est la notation pour documenter les modles objets

122
24/09/10
61
24/09/10
En rsum (suite)
quoi sert la modlisation ? :

Meilleure comprhension du problme Communiquer entre dveloppeurs Trouver des erreurs et des incohrences Assurer la cohrence entre les besoins et limplmentation Gnrer du code
Modles UML
123
Systme Informatique
24/09/10
2. Les Principaux diagrammes dUML
124
24/09/10
62
24/09/10
Les diagrammes dUML

UML dfinit neuf sortes de diagrammes pour reprsenter les diffrents points de vue de modlisation. Un diagramme contient des attributs de placement et de rendu visuel qui ne dpendent que du point de vue. Les diagrammes peuvent montrer tout ou partie des caractristiques des lments de modlisation, selon le niveau de dtail utile dans le contexte dun diagramme donn
125
24/09/10
Deux types de diagramme : structurels et dynamiques
Un objet a une reprsentation structurelle (ou statique) :
structure interne (de quoi est il compos) et externe (ses relations structurelles avec les autres objets)
Un sous-objet A Un sous-objet B
Un Objet
Et dynamique :
Son comportement dans le temps: les messages quil envoie/ reoit, ses changements dtats, etc.
Un Objet A
initialiser
Un Objet B
126
24/09/10
63
24/09/10
Les diagrammes dUML
(UML1.5)
127
24/09/10
Diagramme dobjets
reprsente les objets et leurs relations (correspond un diagramme de collaboration simplifi, sans reprsentation des envois de messages).
128
24/09/10
64
24/09/10
Diagramme de classes
Reprsente la structure statique en terme de classes et de relations.
129
24/09/10
Diagramme de composants
Reprsente les composants physiques dune application.
130
24/09/10
65
24/09/10
Diagramme de dploiement
Reprsente le dploiement des composants sur les dispositifs matriels.
131
24/09/10
Diagramme de cas dutilisation
Reprsente les objectifs en terme de fonctionnalits du systme du point de vue de lutilisateur.
132
24/09/10
66
24/09/10
Diagramme de squence
Reprsentation temporelle des objets et de leurs interactions.
133
24/09/10
Diagramme de collaboration
Reprsentation spatiale des objets, des liens et des interactions.
134
24/09/10
67
24/09/10
Diagramme dtats-transitions
Reprsente le cycle de vie dun objet
135
24/09/10
Diagramme dactivit
Reprsente un enchanement dactivits au sein dune opration, dun cas dutilisation ou dun processus mtier.
136
24/09/10
[PAM-00 p94]
68
24/09/10
Diagrammes dUML2.0
137
24/09/10
3. Objets et classes
138
24/09/10
69
24/09/10
Les objets

Les objets du monde rel nous entourent, ils naissent, vivent et meurent Les objets informatiques dfinissent une reprsentation simplifie des entits du monde rel Les objets reprsentent des entits concrtes (avec une masse) ou abstraites (concept)
139
24/09/10
Reprsentation graphique des objets
140
24/09/10
70
24/09/10
Les objets sont des abstractions

Une abstraction est un rsum, un condens Mise en avant des caractristiques essentielles Dissimulation des dtails Une abstraction se dfinit par rapport un point de vue
141
24/09/10
Exemples dabstractions

Une carte routire Un nombre complexe Un tlviseur Une transaction bancaire Une porte logique Une pile Un actionneur Un capteur
142
24/09/10
71
24/09/10
Caractristiques fondamentales des objets

Ltat Le comportement Lidentit
143
24/09/10
Ltat

Ltat regroupe les valeurs instantanes de tous les attributs dun objet Ltat volue au cours du temps Ltat dun objet un instant donn est la consquence de ses comportements passs
144
24/09/10
72
24/09/10
Exemples

Pour un signal lectrique : lamplitude, la pulsation, la phase, ... Pour une voiture : la marque, la puissance, la couleur, le nombre de places assises, ...
145
24/09/10
Exemples (suite)
146
24/09/10
73
24/09/10
Le chaos des objets

Le monde qui nous entoure est constitu de trs nombreux objets Pour comprendre le monde, ltre humain a tendance regrouper les lments qui se ressemblent Regrouper des objets suivants des critres de ressemblance sappelle classer Les humains ont class les animaux, les plantes, les champignons, les atomes, ...
147
24/09/10
Le chaos des objets (suite)
148
24/09/10
74
24/09/10
Les classes

La classe est une description abstraite dun ensemble dobjets La classe peut tre vue comme la factorisation des lments communs un ensemble dobjets La classe dcrit le domaine de dfinition dun ensemble dobjets
149
24/09/10
Reprsentation graphique des classes
150
24/09/10
75
24/09/10
Classes et objets
151
24/09/10
Lencapsulation

Chaque objet encapsule des donnes Le genre des donnes encapsules et les oprations applicables un objet sont dcrites dans la classe Les classes permettent de dcrire des contrats qui seront valables pour tous les objets issus de ces classes
152
24/09/10
76
24/09/10
Encapsulation (Suite)
La spcification dune classe dfinit la partie visible des objets, le reste est cach dans la ralisation
Rgles de visibilit + Attribut public # Attribut protg - Attribut priv + Opration publique () # Opration protg() - Opration prives()
153
NombreComplexe - Module - Argument + Addition () + Soustraction () + Division()

24/09/10
Bnfices de lencapsulation
Lencapsulation prsente deux avantages

les donnes encapsules sont protges des accs intempestifs, ce qui permet de garantir leur intgrit les clients dune abstraction ne dpendent pas de la ralisation de labstraction, mais seulement de sa spcification
154
24/09/10
77
24/09/10
Conclusion sur les objets et les classes

Les objets naissent, vivent et meurent Les objets interagissent entre eux Les objets sont regroups dans des classes qui les dcrivent de manire abstraite La classe intgre les concepts de type et de module
155
24/09/10
Les relations entre classes
Lassociation Lagrgation La
composition La gnralisation
156
24/09/10
78
24/09/10
Lassociation

Lassociation exprime une connexion smantique bidirectionnelle entre classes Une association est une abstraction des liens qui existent entre les objets instances des classes associes Les associations se reprsentent de la mme manire que les liens.
Distinction opre en fonction du contexte
157
24/09/10
Exemple
158
24/09/10
79
24/09/10
Nommage des associations
Indication du sens de lecture
159
24/09/10
Nommage des rles
Le rle dcrit une extrmit dune association
160
24/09/10
80
24/09/10
Multiplicit des rles
1 0..1 M .. N * 0 .. * 1 .. *
161
Un et un seul Zro ou un De M N (entiers naturels) Plusieurs De zro plusieurs D'un plusieurs

24/09/10
Lagrgation

Connexions bidirectionnelles dissymtriques L'agrgation EST une association mais qui exprime un couplage plus fort entre classes Reprsentation des relations

matre et esclaves tout et parties compos et composant.
162
24/09/10
81
24/09/10
Exemples
163
24/09/10
La composition
Connexions bidirectionnelles dissymtriques La composition EST une association exprimant un couplage plus fort entre les classes que lagrgation Reprsentation des relations
tout et parties compos et composant.
Destruction du compos entrane destruction composant

164
24/09/10
82
24/09/10
Exemple
165
24/09/10
Hirarchies de classes

Grer la complexit
Arborescences de classes dabstraction croissante Super-classes Sous-classes
Gnralisation
Spcialisation
166
24/09/10
83
24/09/10
Gnralisation
Factoriser les lments communs
attributs, oprations et contraintes
167
24/09/10
Spcialisation
Extension cohrente d'un ensemble de classes
168
24/09/10
84
24/09/10
Proprits de la gnralisation
Signifie toujours : est un ou est une sorte de
169
24/09/10
Proprits de la gnralisation
Non-rflexive, non-symtrique, transitive
170
24/09/10
85
24/09/10
Gnralisation multiple
171
24/09/10
Lhritage

Technique la plus utilise pour raliser la gnralisation Construire une classe partir dune ou plusieurs autres classes, en partageant des attributs, des oprations et parfois des contraintes, au sein d'une hirarchie de classes.
172
24/09/10
86
24/09/10
Hritage et polymorphisme
Polymorphisme :
Une mme mthode peut avoir plusieurs implmentations (voir rdfinition et surcharge en java) Un objet de type Chat peut galement tre vu comme un Fdil ou comme un Animal
173
24/09/10
Exercice 1:
construire le diagramme de classe relatif lnonc suivant
Soient un ensemble de personnes et un ensemble de voitures. Une personne est caractrise par un numro qui lidentifie, son nom et par les voitures dont elle est lunique propritaire. Une voiture est caractrise par un numro de plaque, une marque et une date de mise en circulation.
174
24/09/10
87
24/09/10
Exercice 1: solution possible
175
24/09/10
Exercice 2 :
Les diffrents dpartements dune entreprise occupent des employs. Un employ est dcrit par son numro matricule (unique dans lentreprise), son nom, son grade et le dpartement dans lequel il travaille. Un dpartement est dcrit par son numro dans lentreprise et sa localisation. Un dpartement est dirig par un directeur qui doit tre un de ses employs.
176
24/09/10
88
24/09/10
Exercice 2 : solution possible
177
24/09/10
Exercice 3 :
Un exploitant possde plusieurs salles de cinma. Un film fait gnralement l'objet de plusieurs sances par jour. Dcrire un schma qui permette l'exploitant d'obtenir des renseignements sur le chiffre d'affaire d'un film, d'une salle, d'une sance o d'un jour dtermin.
178
24/09/10
89
24/09/10
Exercice 3 - solution possible : la classe dassociation
179
24/09/10
Exercice 4:
Dfinir un schma dcrivant les liens familiaux (mariage, parent/enfant) d'une population de personnes identifiables par un numro.
180
24/09/10
90
24/09/10
Exercice 4: solution possible
181
24/09/10
Exercice 5 :
Soit un ensemble de personnes (identifies par un numro et caractrises par un nom) et un ensemble d'organisme bancaires (identifis par un numro); une personne peut ouvrir un ou plusieurs comptes dans un organisme bancaire; chaque organisme bancaire affecte chacun de ses comptes un numro identifiant pour lui seul.
182
24/09/10
91
24/09/10
Exercice 5 : solution possible
183
24/09/10
Exercice 6 : MonAuto
Une rparation est toujours relative un vhicule. La facture est envoye au propritaire (qui est toujours un client) du vhicule ou une compagnie d'assurance en cas d'accident; une compagnie d'assurance est un client pour le garage. En cas de rparation en garantie, aucune facture n'est envoye. Le modle doit contenir les renseignements qui permettent de faire la facture, selon les rgles suivantes : - Un vhicule vendu par MonAuto bnficie d'une anne de garantie partir de la date de livraison. Pour bnficier d'une rparation sous garantie, le client doit amener son vhicule l'atelier avant l'expiration du dlai de garantie. En fin de priode de garantie, l'atelier peut tre surcharg et le Chef d'atelier ne pourra pas toujours effectuer la rparation avant la date d'expiration. Pour rsoudre ce dilemme et viter toute rclamation, lorsqu'un client prend un rendez-vous pour effectuer une rparation en garantie le Chef d'atelier prpare une fiche de rparation "garantie" et y indique la date de la demande de rendezvous du client, en plus des 2 dates de rception et restitution du vhicule pour la rparation; cette date de demande de rendez-vous sera utilise comme critre de rparation en garantie. Quelques prcisions : Nous ne grons pas l'historique des changements de propritaires des voitures; chaque fois qu'une voiture change de propritaire, un nouveau vhicule sera cr avec indication de la nouvelle immatriculation, du nouveau propritaire et de la date de livraison s'il s'agit d'une vente de MonAuto.
184
24/09/10
92
24/09/10
Exercice 6 : MonAuto
CRUD CRUD
CRUD
CRUD
CRUD
185
24/09/10
Conclusion

Les classes sont connectes par des relations Lassociation exprime une connexion smantique Lagrgation est une forme dassociation plus forte La gnralisation permet dordonner les objets au sein de hirarchies de classes
186
24/09/10
93
24/09/10
4. La dynamique des objets
187
24/09/10
Communication entre objets

Application = socit d'objets collaborants Les objets travaillent en synergie afin de raliser les fonctions de lapplication Le comportement global dune application repose donc sur la communication entre les objets qui la composent
188
24/09/10
94
24/09/10
Les objets ne vivent pas en ermites
Les objets interagissent les uns avec les autres
189
24/09/10
Communication entre objets
Les objets communiquent en changeant des messages
190
24/09/10
95
24/09/10
Le concept de messages

Lunit de communication entre objets Concept trs gnral pouvant tre mis en oeuvre suivant de nombreuses variantes Regroupe les flots de contrle et les flots de donnes Reprsente galement les vnements
191
24/09/10
Les diagrammes de collaboration

Des objets dans une situation donne Des liens relient les objets qui se connaissent Les messages changs par les objets sont reprsents le long de ces liens Lordre denvoi des messages est matrialis par un numro de squence
192
24/09/10
96
24/09/10
Exemple
Un objet A envoie un message X un objet B, puis lobjet B envoie un message Y un objet C, et enfin C senvoie un message Z.
193
24/09/10
Les diagrammes de squence

L'accent est mis sur la communication, au dtriment de la structure spatiale Chaque objet est reprsent par une barre verticale Le temps s'coule de haut en bas, de sorte que la numrotation des messages est optionnelle.
194
24/09/10
97
24/09/10
Objets et messages
Des lignes verticales pointilles reprsentent des objets (pas des classes!) Le nom de lobjet (ex : objet1) est optionel (on peut noter juste :Sender). reprsente un message reprsente un retour explicite de message (return) La classe Sender devrait avoir une association avec la classe Receiver dans le diagramme de classes
Comparaison entre diagramme de squence et de collaboration
196
24/09/10
98
24/09/10
Exemple : Retrait en espce
Rdigez un diagramme de squence bas sur lnonc suivant:

Le guichetier ouvre une session Le guichetier saisit le numro de compte du client. Le systme guichet valide le compte auprs du systme central. Le systme guichet demande le type dopration au guichetier Le guichetier slectionne le montant du retrait Le systme guichet interroge le systme central pour sassurer que le compte est suffisamment approvisionn Le systme guichet demande au systme central de dbiter le compte Le systme notifie au guichetier quil peut dlivrer le montant demand
Retraite en espce Diagramme de Squence
198
24/09/10
99
24/09/10
Retrait despce Diagramme de Collaboration
199
24/09/10
Exercice : Simple Watch

Button 1 Button 2
A partir du diagramme de classe ci-dessus

1. Rdigez un diagramme de squence pour modliser un scnario o un utilisateur voudrait rgler lheure (particulirement les minutes) sur sa montre.
En appuyant 2X sur le bouton 1 il accde au rglage des minutes (heure clignote puis minute clignote). Ensuite avec le bouton 2 (sans relcher le bouton) il incrmente les minutes, le LCD display est rafrachi. En appuyant sur le bouton 1 un autre fois lheure est enregistre et laffichage sarrte de clignoter.
2. Rdigez un diagramme de collaboration partir du diagramme de squence obtenu

200
24/09/10
100
24/09/10
Simple watch: Diagramme de Squence
UML2 notation
loop
[B2.state = Pushed]
201
24/09/10
Simple Watch: Diagramme de Collaboration
202
24/09/10
101
24/09/10
Diagramme dtats-Transitions
Un Diagramme dtats-transitions est utilis pour montrer

le cycle de vie dun objet instance dune classe, les vnements qui provoquent une transition dun tat un autre, les actions qui rsultent dun changement dtat
203
24/09/10
tats

Ltat dun objet est lune des conditions possibles dans lequel un objet peut exister: Un objet est toujours dans un tat donn, pour un certain temps Un tat = {valeurs des attributs de l'objet} + liens vers d'autres objets Un tat possde un nom qui l'identifie
204
24/09/10
102
24/09/10
tats (suite)
Caractristiques :
un tat initial
des tats intermdiaires

Etat intermdiaire
des tats finaux
205
24/09/10
Transitions
Connexions unidirectionnelles reliant des tats, formant un graphe dirig Traduisent le passage d'un tat un autre tat (instantan car pas d'tat inconnu) Sont dclenches par un vnement si la condition est vraie, et engendrent une action
Etat 1
vnement [condition]/action Etat 2

206
24/09/10
103
24/09/10
vnements, condition et actions
Les vnements :

lments dclencheurs de la transition Gnralement 4 types :

Signaux : une occurrence asynchrone dun vnement externe la machine tats (Ex : Bouton STOP enfonc) Appel : une notification explicite dun autre objet Changement : la modification dun attribut peut tre vu comme un vnement (NiveauEssence=0) Temporel : dlai expir, ou arrive dun temps absolu (ex: delai=30ms)
Les conditions : condition boolenne validant ou non le dclenchement d'une transition l'arrive d'un vnement
207
24/09/10
Les actions

correspondent gnralement des oprations dclares dans la classe oprations attaches une transition instantanes et ne pouvant tre interrompues ont accs aux paramtres de l'vnement et aux attributs de l'objet les tats peuvent aussi contenir des actions pouvant tre excute en entre ou en sortie de l'tat ou lors de l'arrive d'un vnement alors que l'objet est dans l'tat
208
24/09/10
104
24/09/10
Les actions et les activits
209
24/09/10
Les activits

opration attache un tat a une certaine dure peut tre interrompue, ds quune transition de sortie de l'tat est dclenche l'arrt de certaines est soumis au dclenchement d'une transition (cycliques), d'autres s'arrtent d'elles mmes (squentielles), dmarrant l'entre dans l'tat L'arrt d'une activit squentielle peut tre suivi d'une transition automatique
210
24/09/10
105
24/09/10
Exercice 3 - 1
211
24/09/10
Les tats composites

Un tat composite ( ou tat englobant) est dcompos en sous-tats.

tats disjoints Etats concurrents
Cette approche dabstraction procde de la mme dmarche que la dcomposition hirarchique; elle facilite la reprsentation et permet docculter les dtails selon le niveau hirarchique choisi.
212
24/09/10
106
24/09/10
Les tats disjoints

Un tat peut se dcomposer en plusieurs sous-tats disjoints; les sous-tats hritent des caractristiques de leur tat composite, en particulier des transitions externes. La dcomposition en sous-tats est galement appele dcomposition disjonctive (dcomposition de type ou-exclusif) car lobjet doit tre dans un et un seul sous-tat la fois.
213
24/09/10
Exemple
214
24/09/10
107
24/09/10
Exemple
(suite)
Diagramme
dtat-transitions de la classe Personne
215
24/09/10
Sous-tats de EnPhaseEmbauche
EnPhaseEmbauche
216
24/09/10
108
24/09/10
Sous-tats de Embauch
Embauch
217
24/09/10
Les tats concurrents

Un tat peut tre compos de plusieurs sous-tats concurrents. Les sous-tats concurrents sont alors appels rgions. Cette composition est de type conjonctive (composition de type et) ce qui implique que lobjet doit tre simultanment dans tous les tats composant lagrgation dtats. La conjonction dtats reprsente une forme de paralllisme entre tats.
218
24/09/10
109
24/09/10
Exemple
Evnement Etat Synchronisation Start E3 E1 E2 E4 Z,A X,A Y,B Z,B Z,A Indpendance Simultanit Indpendance Dpendance Inddendance
219
24/09/10
La communication entre objets

Les envois de messages entre deux objets sont visualiss de manire abstraite dans le formalisme des diagrammes dtats-transitions par lenvoi dun vnement entre les automates dtats-finis des classes dobjets concerns. La syntaxe dun envoi dvnement vers une classe est:
^Cible.Evnement (Arguments)
o la cible dsigne la classe des objets destinataires de lvnement.
220
24/09/10
110
24/09/10
Exemple
221
24/09/10
Exercice 1 : formation dun contrat

Dessinez un diagramme dtat/transition rsumant les tats possibles dun objet contrat tel que dcrit dans lnonc suivant. Un ensemble de personnes dcident dtablir un contrat. Pour ce faire elles rdigent un projet par itration successive. Le contrat est ensuite informellement accept par les parties, et devient ce que lon appelle un pr-accord. A ce stade il peut toujours tre lobjet de modification et revenir ltat de projet. Une fois le pr-accord dfinitivement tabli, le contrat est sign par les parties. Ds ce moment les partenaires sont lis. Une fois sign le contrat peut tre rendu excutoire par une dcision dune des parties. Un contrat en excution peut faire lobjet de discussions qui sont rgles par un arbitre dsign cet effet. Le contrat une fois excut prend fin.
222
24/09/10
111
24/09/10
Proposition Solution 1
223
24/09/10
Exercice 2 : montre digitale
Ma montre affiche lheure, si jappuie 2X sur le boutton 1, la montre passe en mode modification. Chaque pression sur le boutton 2, incrmente lheure dune unit. Si jappuie encore un fois sur le boutton 1, je peux rgler les minutes de la mme faon que les heures. Si jappuie une quatrime fois sur le boutton 1, la montre affiche nouveau lheure courante.
Button1
Button2
112
24/09/10
225
24/09/10
Exercice 3 : montre digitale plus avance
Lors du rglage de lheure ou des minutes lorsque jappuie sur le bouton 2 plus de deux secondes, les heures ou les minutes avancent trs rapidement jusqu ce que je relche la pression On ajoute un bouton 3 qui permet de rtro-clairer lcran LCD
Button1 Button3
Button2
113
24/09/10
miseEnService
227
24/09/10
Exercice 4 : cabine tlphonique
Modlisez le fonctionnement dune cabine tlphonique
228
24/09/10
114
24/09/10
Proposition de Solution 4
229
24/09/10
5. Les Cas dutilisation
230
24/09/10
115
24/09/10
Les cas dutilisation
Expression des besoins
231
24/09/10
Les cas dutilisations

Formaliss par Ivar Jacobson : Object-Oriented Software Engineering (Addison-Wesley, 1992) Expression du comportement du systme (actions et de ractions), selon le point de vue de lutilisateur Dcrivent le systme et les relations entre le systme et lenvironnement
232
24/09/10
116
24/09/10
Intrt des cas dutilisations

Constituent un moyen de dterminer les besoins dun systme Utiliss par les utilisateurs finaux pour exprimer leur attentes et leur besoins Permettent dimpliquer les utilisateurs ds les premiers stades du dvelopement Constituent une base pour les tests fonctionnels
233
24/09/10
Fil conducteur du projet
234
24/09/10
117
24/09/10
Les acteurs
Un acteur est une personne ou un systme qui interagit avec un systme, en changeant de linformation (en entre et en sortie) On trouve les acteurs en observant les utilisateurs directs du systme, ceux qui sont responsable pour sa maintenance, ainsi que les autres systmes qui interagissent avec le systme
235
24/09/10
Les utilisateurs

Un acteur reprsente un rle jou par un utilisateur qui interagit avec le systme La mme personne physique peut jouer le rle de plusieurs acteurs (vendeur, client) Dautre part, plusieurs personnes peuvent galement jouer le mme rle, et donc agir comme le mme acteur (tous les clients)
236
24/09/10
118
24/09/10
Acteurs et cas dutilisations

Les cas dutilisations reprsentent le dialogue entre lacteur et le systme de manire abstraite Ensemble de scnarios au sein dune description unique Les cas dutilisations doivent tre vus comme des classes de scnarios
237
24/09/10
Dtermination des cas dutilisations

Quelles sont les tches de lacteur ? Quelles informations lacteur doit-il crer, sauvegarder, modifier, dtruire ou simplement lire ? Lacteur devra-t-il informer le systme de changements externes ? Le systme devra-t-il informer lacteur de conditions internes au systme ?
238
24/09/10
119
24/09/10
Structurer les cas dutilisation
Les relations extend et include
Extend : un cas dutilisation X tend un cas dutilisation Y lorsque le cas dutilisation X peut tre appel au cours de lexcution du cas dutilisation Y Include : un cas dutilisation est constitu de sous cas dutilisation
Exemple de canevas pour une description textuelle

Cas dutilisation Acteurs Point de vue Prconditions Droulement normal Description dtaille
Postconditions Droulement alternatif Exceptions
Variantes
240
24/09/10
120
24/09/10
Exercice 1 : Le cas MonAuto

MonAuto est une entreprise qui fait le commerce, l'entretien et les rparations de voitures. MonAuto dsire exploiter un logiciel de gestion des rparations; elle dispose dj d'un logiciel comptable. Les factures de rparations seront imprimes et gres par le logiciel comptable. Le logiciel de gestion des rparations devra communiquer avec le logiciel comptable pour lui transmettre les rparations facturer.
241
24/09/10
Exercice 1 : Le cas MonAuto (suite)

Le logiciel de gestion des rparations est destin en priorit au chef d'atelier, il devra lui permettre de saisir les fiches de rparations et le travail effectu par les divers employs de l'atelier. Pour effectuer leur travail, les mcaniciens et autres employs de l'atelier vont chercher des pices de rechange au magasin. Lorsque le logiciel sera install, les magasiniers ne fourniront des pices que pour les vhicules pour lesquels une fiche de rparation est ouverte; ils saisiront directement les pices fournies depuis un terminal install au magasin. Lorsqu'une rparation est termine, le chef d'atelier va essayer la voiture. Si tout est en ordre, il met la voiture sur le parc clientle et bouclera la fiche de rparation informatise. Les fiches de rparations boucles par le chef d'atelier devront pouvoir tre importes par le comptable dans le logiciel comptable.
242
24/09/10
121
24/09/10
Solution possible
Consulter Fiches
243
24/09/10
Exercice 2: Le cas MonAuto

Dcouvrez les besoins implicites Nous n'avons pas explicit la manire dont les employs et leur qualification sont grs, tout comme pour le stock de pices de rechange, les clients, les employs, les ventes de voitures... Nous pouvons imaginer que le logiciel de gestion des rparations offre les fonctionnalits implicites de gestion des clients, employs, ventes de voitures, pices de rechange...
244
24/09/10
122
24/09/10
Solution
245
24/09/10
Acteurs et objets
Les acteurs sont des objets particuliers du systme MAIS :
Ils napparatront pas forcment en tant quobjet dans les diagrammes de classes ( quoi servirait un objet de type
Direction ?, voir transp. prcdent)
Ils ny apparaissent dans le diagramme de classes que sils sont la fois acteur et ressource du systme (exemple : la classe tudiant dans un systme denseignement distance)
246
24/09/10
123
24/09/10
-6Un Processus de dveloppement ultralger pilot par les cas dutilisation
247
24/09/10
Le virage vers lobjet
248
24/09/10
124
24/09/10
Le virage vers lobjet
249
24/09/10
Exemple / Le cas dutilisation retrait en espce
250
24/09/10
125
24/09/10
Cas dutilisation Acteurs Point de vue Prconditions Droulement normal
Exemple / reprsentation textuelle

Retrait en espce Guichetier (principal) et Systme central (secondaire) Analyste systme Le client est inscrit et possde un numro de compte
Description dtaille
1. Le guichetier saisit le numro de compte du client. 2. Lapplication valide le compte auprs du systme central. 3. Lapplication demande le type dopration au guichetier. 4. Le guichetier slectionne un retrait de 200 euros. 5. Le systme guichet interroge le systme central pour sassurer que le compte est suffisamment approvisionn. 6. Le systme central effectue le dbit du compte. 7. Le systme notifie au guichetier quil peut dlivrer le montant demand. Une fois le montant dbit, le compte doit prsenter le solde prcdent moins la somme retire a) Le numro de compte client nest pas valide : recommencer en 1 b) Approvisionnement insuffisant : message derreur, aller en 4 ou abandon
Postconditions Droulement alternatif Exceptions
Variantes
251
24/09/10
Exemple / Diagramme de squence systme

du CU retrait en espce
252
24/09/10
126
24/09/10
Exemple (suite) - Diagramme de squence de conception (incomplet)

du CU retrait en espce
253
24/09/10
Exemple (suite) Diagramme de classes de conception

(classes collaborantes du CU retrait en espce)
254
24/09/10
127
24/09/10
Synthse des tapes dun processus de dveloppement simplifi (miniprojet solo)

1. 2. 3. 4. 5. 6. 7.
255
Dtermination des acteurs et de leurs tches respectives Dtermination des cas dutilisation et dfinition des frontires du systme Pour chaque CU dveloppement des diagrammes de squence systme (le systme entier est vu comme un seul objet) Choix des cas dutilisation critique (entre 3 et 5) Dveloppement des diagrammes de squence faisant apparatre les objets et ralisation du diagramme de classes. Programmation des cas dutilisation critiques Dveloppement des autres cas dutilisation
24/09/10
Rfrences bibliographiques

P. A. MULLER et N. GAERTNER, Modlisation objet avec UML, Eyrolles, 2000 G. BOOCH, J. RUMBAUGH et Y. JACOBSON, Le guide de l'utilisateur UML , Eyrolles, 2000 E. GAMMA et al., Design Patterns, Thomson, 1996
256
24/09/10
128
24/09/10
Liens utiles
Norme UML disponible sur le site de lOMG :
http://www.omg.org/technology/documents/ modeling_spec_catalog.htm http://lgl.isnetne.ch/uml/ http://www.isys.ucl.ac.be/etudes/cours/geti2101/tutorialslides/ http://deptinfo.cnam.fr/Enseignement/CycleSpecialisation/MAI/
Autres cours en ligne (parmi beaucoup dautres) :

Logiciels de modlisation UML gratuits multi plate-formes

argoUML : http://argouml.tigris.org PoseidonCE : http://www.gentleware.com Plugin eclipse : http://www.omondo.org http://staruml.sourceforge.net/en/index.php

Logiciels windows gratuits :
257
24/09/10
Chapitre 8
Le Processus Unifi - Une Dmarche Oriente Modle
258
24/09/10
129
24/09/10
Sommaire
Prsentation gnrale du Processus Unifi Artefacts Enchanement ditrations Rles Gestion de la configuration et des changements
259
COO SE J. Guiochet 24/09/10
Prsentation gnrale du Processus Unifi
260
24/09/10
130
24/09/10
Dvelopper le logiciel de faon itrative (1/2)

Risque
Analyse des besoins Conception Codage
Tests
Temps Le cycle de vie en cascade

261 COO SE J. Guiochet 24/09/10
Dvelopper le logiciel de faon itrative (2/2)

Analyse des besoins Planification Planification initiale Dploiement Evaluation Tests Chaque itration a pour rsultat une version excutable
Analyse et conception Implmentation
Un processus itratif et incrmental
262
131
24/09/10
Grer les exigences
Problmatiques

Modifications des exigences au cours du dveloppement Identification et intgration de lensemble des besoins au cours du processus Organiser et dcrire les fonctionnalits et les contraintes du systme (compltude et cohrence) Evaluer les changements apporter au cahier des charges et estimer leur impact (modifiabilit) Dcrire les diffrentes dcisions prises et en faire le suivi (traabilit)
Propositions

263
Utiliser des architectures base de composants
Larchitecture repose sur des dcisions concernant :

Lorganisation du systme Les choix des lments structurels et de leurs interfaces Leur comportement Leur composition en sous systmes Les contraintes non fonctionnelles (rutilisation, robustesse, fiabilit, etc.)
(Exemples : Composants Com, Corba, EJB, classes .Net, etc.)
264
132
24/09/10
Modliser graphiquement le logiciel

Utilisation des diagrammes UML, et plus globalement de la notion de modle. Tout nest pas modle Tout modle nest pas UML Tout nest pas modle UML !
265
Vrifier la qualit du logiciel
Fonctionnalits, fiabilit et performances
Tests (de benchmark , de configuration, de fonctionnement, dinstallation, dintgrit, de charge, de performance, de stress, ) Rapports de conception (ou revues)
266
133
24/09/10
Exercice
Dcrivez en quelques lignes lorganisation du processus de dveloppement que vous avez pu observer au cours de vos stages (prcisez la taille des quipes de dveloppement). Dterminez si ce processus intgre votre connaissance les cinq pratiques vues prcdemment.
267
Quest ce que le Processus Unifi ?
(1/3)
Le Processus Unifi ou UP (Unified Process) est une mthode gnrique de dveloppement de logiciel dveloppe par les concepteurs dUML

Gnrique signifie qu'il est ncessaire d'adapter UP au contexte du projet, de l'quipe, du domaine et/ou de l'organisation. Il existe donc un certain nombre de mthodes issues de UP comme par exemple RUP (Rational Unified Process), 2TUP (Two Track Unified Process) Il existe dautres approches (qui ne sont en gnral pas compltement antinomique), comme par ex. les mthodes agile, beaucoup moins orientes modle, comme XP (eXtreme Programming)
268
134
24/09/10
(2/3)
Le processus unifi permet daffecter des tches et des responsabilits au sein dune organisation de dveloppement logiciel

Approche discipline pour des gros projets (chef de projet, analystes, intgrateur, intervenants, etc.) Approche adapter pour des petits projets Pas particulirement conu pour le dveloppement de systmes embarqus
269
(3/3)
Le processus unifi utilise le langage UML Le processus unifi est pilot par les cas dutilisation Centr sur larchitecture Itratif et incrmental
270
135
24/09/10
La structure logique du Processus

[Rational UP]
Phases Lancement (inception) Elaboration Construction Transition
Modlisation mtier
Recueil des besoins Analyse et Conception
Principales activits du processus
Implmentation
Tests Gestion de projet Itr.Init lab. 1 lab. 2 Cstr.1 Cstr.2 Tran1 Tran2
271
Les quatre phases

Modlisation mtier
Implmentation
272
136
24/09/10
ressources
V1
Lancement Elaboration Construction Transition temps
Jalon 1 :
Objectifs dfinis (livraison interne)
Jalon 2 :
Architecture dfinie
Premire livraison externe (bta)
Jalon 3 :
Jalon 4 :
Livraison finale
Les Jalons correspondent des tapes dvaluation de la phase termine, et de lancement de la phase suivante
Les enchanements dactivits

Modlisation mtier
Implmentation
274
137
24/09/10
Gestion de projet
La gestion de projet est la mise en uvre de connaissances, de ressources, de comptences, doutils et de techniques qui permettent le lancement, la planification, la ralisation, le pilotage et la clture dun projet dans un cadre temporel et budgtaire, pour atteindre des objectifs prcis. De nombreux aspects ne sont pas couverts dans cette prsentation (gestion personnel, budget, contrats, etc.)
Objectifs

Planifier/valuer un projet itratif Grer les risques Contrler les progrs (dlais, cots, qualit, efforts, satisfaction client, productivit, etc.)
275
Modlisation mtier
Comprhension de la structure et la dynamique de lorganisation Comprendre les problmes poss dans le contexte de lorganisation Conception dun glossaire
276
138
24/09/10
Recueil et expression des besoins

Auprs des clients et parties prenantes du projet Ce que le systme doit faire Expression des besoins dans les cas dutilisation (exigences fonctionnelles) Spcification des cas dutilisation en scnarios Limites fonctionnelles du projet et exigences non fonctionnelles (utilisabilit, fiabilit, performances) Planification et prvision de cot Ebauche de lIHM (prototypage et validation par lutilisateur)
277
Analyse et conception

Transformation des besoins utilisateurs en modles UML Unified Modeling Language (pas une mthode mais un langage ) Modle danalyse et modle de conception, (ventuellement modle de donnes) tape importante : de lanalyse la conception : assigner des responsabilits aux classes Les patrons GRASP (General Responsability Assignment Software Patterns) [Prsentation ultrieure]
278
139
24/09/10
Implmentation
Dveloppement incrmental Dcoupage en couches Composants darchitecture Retouche des modles et des besoins Units indpendantes, quipes diffrentes
279
Tests
Etapes (unitaire, dintgration, systme, acceptation) Types :
De benchmark (comparaison) De configuration (diffrentes config matrielles et logicielles) De fonctionnement (vrification des CU) Dinstallation Dintgrit (fiabilit, robustesse, rsistance) De charge (conditions oprationnelles plus lourdes = nb utilisateurs, transactions,) De performance (en modifiant les configurations) De stress (conditions anormales oprationnelles)
280
140
24/09/10
Exercice

Dcrivez en quelques lignes les phases que vous suivez lorsque vous tes seul dvelopper un logiciel. Est ce que vous retrouvez certains lments du Processus Unifi ? Quels tests effectuez vous lorsque vous dveloppez seul ?
281
Les artefacts (ou livrables, ou dlivrables)
282
24/09/10
141
24/09/10
Les artefacts
Elments produits lors du dveloppement (documents, modles, fichiers compils, composants, etc.) Nous nous intresserons ici aux artefacts de documentation et leur gestion (cration, modification, livraison)
283
Prambule

Les parties des documents sont prsentes ici titre dexemple. Suivant la taille du projet, il faut tendre ou rduire ces documents (voire les supprimer) Dans tous les cas, les documents doivent tre mis rgulirement jour, avec une gestion des changements (tableau de mise jour dans len-tte de chaque doc)
284
142
24/09/10
Artefact ou pas ? Rgles de base
Objectif des artefacts : produire un meilleur logiciel Trop dartefacts produit perte de temps, dispersion de lquipe, augmentation des cots Restez concentr sur le logiciel excutable En cas de doute sur lopportunit dun artefacts, abstenez vous
285
Template des documents

<nom du projet> Nom du document Version <1.0>
Historique des rvisions
Date <jj/mm/aa>
Sommaire 1. Introduction
1. 2. 3.
Version <x.x> <details>
Description
Auteur <name> ..
Objectifs Dfinitions, acronymes, et abrviations Rfrences
2.
<Sections spcifiques au document>
286
143
24/09/10
Ensemble dartefacts

Lensemble de gestion Lensemble des exigences Lensemble de conception Lensemble dimplmentation Lensemble de dploiement
287
Lensemble de gestion de projet

Document de vision Plan de dveloppement logiciel (planning des phases,rles,

responsabilits, jalons, activits)
Liste des risques Planning ditration tude de rentabilit Points en suspens

Glossaire Donnes sur des anomalies
288
144
24/09/10
Document de vision
[En-tte]
Sommaire
1. Problme
[motivations pour la cration du logiciel]
2. nonc de la vision
[description du concept du systme et intrts]
3. Principaux acteurs concerns

[acteurs du dveloppement et utilisateurs]
4. Caractristiques du logiciel
[liste des principaux CU, performances, etc.]
289
Exemple de sommaire du document de vision tendu

1. Introduction 1.1 Purpose 1.2 1.3 1.4 Scope Definitions, Acronyms, and Abbreviations References 5. 4. Product Overview 4.1 Product Perspective 4.2 Summary of Capabilities 4.3 Assumptions and Dependencies 4.4 Cost and Pricing 4.5 Licensing and Installation Product Features 5.1 <aFeature> 5.2 <anotherFeature> Constraints Quality Ranges Precedence and Priority
1.5 Overview 2. Positioning 2.1 2.2 2.3 Business Opportunity Problem Statement Product Position Statement
3. Stakeholder and User Description 3.1 Market Demographics 3.2 Stakeholder Summary 3.3 3.4 3.5 User Summary User Environment Stakeholder Profiles 3.5.1 <Stakeholder Name> 3.6 User Profiles 3.7 3.8 3.6.1 <User Name> Key Stakeholder or User Needs Alternatives and Competition 3.8.1 <aCompetitor> 3.8.2 <anotherCompetitor>
6. 7. 8. 9.
Other Product Requirements 9.1 Applicable Standards 9.2 System Requirements 9.3 Performance Requirements 9.4 Environmental Requirements 10. Documentation Requirements 10.1 User Manual 10.2 Online Help 10.3 10.4 Installation Guides, Configuration Labeling and Packaging
145
24/09/10
Plan de dveloppement
Distribution dans le temps des ressources humaines (rles et responsabilits) et matrielles
1. 2. 3.
Structure organisationnelle Rles et responsabilits Planning du projet

1. 2. 3. 4.
Planning des phases Objectifs des itrations Dlivrables Dcoupage en phases, identification des jalons et objectifs des itrations
Nb : Utilisation de tableaux, diagrammes (Gant par ex. pour des projets importants)
Liste des risques
1 <Identificateur de risque> [nom descriptif ou numro]

1.1 1.2 1.3 1.4 1.5 Niveau de risque Description Consquences Indicateurs Stratgie de traitement du risque
2 <Risque suivant>
[]
146
24/09/10
Planning ditration
[en-tte] Sommaire 1. Planning
[Description temporelles des jalons intermdiaires, versions beta, demos, etc.] [Matrielles, humaines, et financires] [C.U. et scnarios qui seront dvelopps dans cette itration] [Fonctionalits, performances, mesures de qualit, etc.]
2. Ressources
3. Cas dutilisation
4. Critres dvaluation
Lensemble des exigences

Demandes des intervenants Modle des CU Spcifications supplmentaires Modle mtier
294
147
24/09/10
Demandes des intervenants
Document permettant de noter et rfrencer les demandes des intervenants (dveloppeurs, sous-traitants, clients, etc.), concernant des modifications dexigences (fonctionnelles ou non) Date / Nom / Description / Prise en compte ou non
295
Modle des cas dutilisation

(Ensemble des fiches de C.U. et du diagramme des C.U.)
1. 2. 3. 4.
Nom Rsum Acteurs Description des scnarios

1. 2.
Scnario nominal Scnarios alternatifs
5. 6. 7. 8.
Pr conditions Post conditions Enchanements alternatifs (description textuelle ou tableau) Autres spcifications :
1. 2.
Besoins dIHM, ergonomie Robustesse, confidentialit, performances (temps de rponse, charge), disponibilit, etc.
Action de lacteur principal 1. action1
Action du systme
Action de lacteur secondaire
2. Rponse du systme et traitement

296
3. Rception dune information COO SE J. Guiochet 24/09/10
148
24/09/10
Spcifications supplmentaires
1. 2.
Introduction Fonctionnalits 2.1 <Exigence fonctionnelle 1>
6. 7. 8. 9.
3.
Utilisabilit (anglicisme de
usability) 3.1 <Exigence dutilisabilit1>
Contraintes de conception 6.1 <Contrainte 1> Aide en ligne et systme daide Composants achets Interfaces
9.1 9.2 9.3 9.4 Interfaces utilisateur Interfaces matrielles Interfaces logicielles Interfaces de communication
4. 5.
Sret de fonctionnement 4.1 <Exigence SdF 1> Performance 5.1 <Exigence de performance 1>
11. 12. 13.
Exigences de licence Copyright Normes applicables
297
Modle mtier

Diagramme de classes mtier Diagramme de C.U. mtier Diagramme dactivits mtier
298
149
24/09/10
Lensemble de conception

Modle de conception (Diagrammes UML) Description de larchitecture (privilgier un reprsentation graphique UML ou non) Plan de test Cas de test
299
Plan de test
3. Types et techniques de test
1. lments cibls par les tests 2. Vue densemble des tests planifis
2.1 Descriptif des test inclus dans le plan de dev. 2.2 Descriptif des autres tests exclus du plan de dev. 2.3 Descriptif des tests candidats une inclusion dans le plan de dev.
3.1 Test dintgrit 3.2 Test fonctionnel 3.3 Test de benchmark 3.4 Test de linterface graphique 3.5 Test de performance 3.6 Test de charge 3.7 Robustesse 3.8 Test de stress 3.9 Test de scurit et de contrle daccs 3.11 Test de configuration 3.12 Test dinstallation
Il faut documenter les tests envisags pour lapplication

300
150
24/09/10
Plan de test
Objectifs de la technique : Technique: Oracles: [Description des objectifs] [Description de la technique utilise, par ex. Excuter chaque scnario et vrifier que ] [Stratgies utilises par la technique pour observer prcisment le succs ou la dfaillance du test] [Besoins en terme de scripts, fichiers de log, etc] [Condition pour que lensemble du test soit positif] [Contraintes lies au type de test, recommandations, remarques, etc]
Outils requis : Critre de succs : Considerations particulires :

301
Cas de test
[Les valeurs possibles de catgorie sont Fonctionnel et Performance]
1. Introduction
Cas de test : <Nom du cas de test> Numro didentification : <Identifiant> Catgorie : <Catgorie de cas de test>
[Cette section dcrit brivement le rle et lobjectif du Cas de Test]

2. Enchanement des vnements
[Dcrire les tapes que le testeur doit suivre. Les rponses (R) sont les rsultats attendus par le test.] 1. tape 1 R. 2. 3.
3.
Rponse 1. Rponse 2 Rponse 3
tape 2 R. tape 3 R.
Besoins techniques
[Besoins techniques lis ce cas de test, par. Ex. un simulateur denvironnement, une machine sous windowsNT, etc.]
3.1 < Premier besoin > []
302
151
24/09/10
Lensemble dimplmentation
Le code source et les excutables Les fichiers de donnes associs (par ex. Javadoc) ou les fichiers permettant de les produire
303
Lensemble de dploiement
Scripts et guide dinstallation Documentation utilisateur Matriel de formation
304
152
24/09/10
Les enchanements ditration
305
24/09/10
Phase de lancement
Phases
Lancement (inception)
Modlisation mtier
Elaboration
Construction
Transition
Recueil des besoins
Principaux enchanements du processus
Analyse et Conception
Implmentation
Tests
It#1 306 COO SE J. Guiochet 24/09/10
153
24/09/10
Phase de lancement

Comprendre les objectifs et la porte du projet Objectifs : 1. Comprendre le systme construire 2. Identifier la fonctionnalit principale du systme 3. Dterminer au moins une solution (architecture) possible 4. Dcider du processus appliquer et des outils utiliser 5. Evaluer les cots et planning 6. Les principaux risques
Nb : en gnral une seule itration, sauf pour projets importants, innovants, ou trs risqus
Objectif 1 : Comprendre le systme
Produire une vision (artefact:document de vision), i.e. opportunits apportes par lapplication, les utilisateurs cibles, quelques cas dutilisation cls (un ou deux), certains besoins non fonctionnels (artefact:spcifications supplmentaires) Gnrer une description large et superficielle (laboration du diagramme de contexte (artefact: modle danalyse) et identification des acteurs et des C.U. principaux (artefact: modle des C.U.), dcrire les C.U., crer un artefact:glossaire et/ou un artefact:modle mtier, dvelopper des prototypes dinterface jetables si besoin) Comprendre les besoins en terme de contrle et identifier les contraintes (complter artefact:modle danalyse avec diagrammes de squence systme et diagramme temporels)
308
154
24/09/10
Objectif 2 : Identifier la fonctionnalit essentielle du systme
Collaboration chef de projet, architecte, et client (artefact: demandes des intervenants) pour dterminer les C.U. les plus critiques

La fonctionnalit est le noyau de lapplication Elle DOIT tre livre
309
Objectif 3 : Dterminer au moins une solution possible

Architecture (client-serveur, centralise, distribue, etc.) Choisir technologies et ventuellement faire des tests dimplmentation pour estimer les risques lis une technologie
1. 2. 3. 4. 5.
Effectuer un partitionnement matriel/logiciel du systme Complter larchitecture du substrat matriel Choisir les technologies matrielles de la partie matrielle (FPGA/VHDL) Choisir les technologies matrielles de la partie logicielle (Microcontrleurs) Choisir les technologies logicielles de la partie logicielle (langage, compilateurs, etc.)
310
155
24/09/10
Partitionnement HW/SW

connaissance et ltude du march des technologies matrielles et logicielles utilisables. La veille technologique et le maintien jour des connaissances techniques des ingnieurs sont la base indispensable lefficacit de lactivit Etudes dimplmentation et partitionnement logiciel/matriel .
311
Choisir les technologies matrielles de la partie logicielle

Processeurs / SoC / Mmoire / Bus / etc. + critres spcifiquement logiciels comme la disponibilit et/ ou la performance de tel systme dexploitation ou de tel middleware sur la plateforme matrielle envisage
312
156
24/09/10
Choisir les technologies logicielles de la partie logicielle
Les langages de programmation:
le choix dun langage de programmation ne doit se faire que sur des critres purement techniques fonds sur

la disponibilit la qualit des compilateurs les performances attendues la maturit industrielle du langage et des outils associs.
313
Les systmes dexploitation:
La problmatique lie au choix du systme dexploitation pour une plateforme matrielle donne sarticule autour de trois points principaux:

Les facilits de dveloppement, dintgration et dvolution Les performances (CPU, rseau, temps rel) Le cot (licences de dveloppement et excutifs)
314
157
24/09/10
Lors du dveloppement logiciel il est aujourdhui quasi impossible de ne pas intgrer au moins une des technologies suivante :

Bibliothques COTS (Components On The Shelf) Des environnements et des cadres de dveloppement (frameworks) Des gnrateurs de codes Des middleware
Problmatique de maintenance, cot, performances, validation, volutivit, etc. Quelques pistes : certification, support, communaut
315
Objectif 4 : Comprendre les cots, les dlais et les risques
Examiner la faisabilit du projet (tude de rentabilit, artefact: liste des risques) tablir le plan du projet (artefact : plan de dveloppement du logiciel)
316
158
24/09/10
Objectif 5 : Dcider du processus appliquer et des outils utiliser
Faire des choix :

Processus de dveloppement Outils de dveloppement Complter le plan de dveloppement avec les choix, mettre jour liste de risques, cots et dlais
317
Revue de projet : Jalon fin de lancement
Les diffrents intervenants valident:

le primtre du projet, cots et dlais la liste des exigences
Les risques initiaux sont identifis et il existe une stratgie de rduction pour chacun deux Lensemble des artefacts produit est complet, jour et cohrent
Lancement
Elaboration
Construction
Transition
318
159
24/09/10
Exercice : Lister ci dessous lensemble des artefacts produits pendant la phase de lancement
319
Phase dlaboration
Phases
Modlisation mtier
Elaboration
Construction
Transition
Recueil des besoins
Implmentation
Tests
320
ItElab1
ItElab2
160
24/09/10
La phase dlaboration
Construction dun squelette darchitecture en intgrant les risques majeurs et affiner les plans de projet Objectifs :
1. 2. 3. 4.
Comprendre en dtail les exigences Concevoir, implmenter, valider larchitecture (proto architectural excutable) Rduire les risques essentiels et estimer plus exactement le budget Affiner le plan de dveloppement
NB: en gnral une trois itrations (artefact : plan ditration)

Objectif 1 : comprendre les exigences en dtail
Mettre jour tout au long de cette phase :

Le modle des C.U. (certains C.U. trs simples et ne prsentant aucun risque ne doivent pas tre formaliss) Le glossaire
Hirarchiser et faire des packages de C.U.
322
161
24/09/10
Objectif 2 : Concevoir, implmenter, et valider larchitecture

Architecture: dfinir les sous-systmes, les composants, et leurs interfaces (utiliser au maximum des frameworks darchitecture)(artefact : description de l'architecture) Dterminer les C.U. significatifs du point de vue architectural Concevoir les C.U. critiques Regrouper en packages les classes identifies (artefact : modle de conception) Rvaluer la couverture architecturale par les scnarios critiques Concevoir la base de donnes Dcrire la concurrence, les processus, les threads, et la distribution physique Identifier les patterns Implmenter et tester les scnarios critiques (artefact : plan de test, cas de test)
323
Objectifs 3 & 4
Rduire les risques essentiels et estimer au mieux les dlais et cots et raffiner le plan de dveloppement
Utiliser toutes les informations provenant des activits de conception pour mettre jour les risques, dlais et cots.
324
162
24/09/10
Revue de projet : jalon fin dlaboration
valuer :

Stabilit vision et exigences Stabilit architecture Crdibilit du plan ditration
En cas de doute : refaire une itration
Lancement
Elaboration
Construction
Transition
325
Phase de construction
Phases
Modlisation mtier
Elaboration
Construction
Transition
Recueil des besoins
Implmentation
Tests
Cstr1 Cstr2
326
163
24/09/10
Phase de construction (3/4)
Gestion des ressources matrielles (installation sur plateformes choisies) Optimisation du processus pour rduire les cots de dveloppement Amliorer la qualit Complter les modles suivant les besoins dimplmentation Produit : le logiciel install sur les plate-formes choisies, les manuels dutilisation, description de la version mise en place
327
La phase de construction

Phase concentre sur la conception, limplmentation et les tests Objectifs :

1. 2.
Minimiser les cots de dveloppement et obtenir un certain degr de paralllisme Dvelopper de faon itrative un logiciel prt la transition vers les utilisateurs
NB : mme pour de petits projets, il faut plusieurs itrations (entre 2 et 4)

164
24/09/10
Objectif 1 : Minimiser les cots de dveloppement et obtenir un certain degr de paralllisme
Sorganiser autour de larchitecture Gestion de la configuration Gestion des demandes de changement Appliquer larchitecture Assurer une progression continue
329
Objectif 2 : Dvelopper de faon itrative un logiciel prt la transition vers les utilisateurs
Dcrire les C.U. restants et les spcifications supplmentaires Terminer la conception Concevoir la base de donnes Coder et excuter les tests unitaires Effectuer les tests dintgration et systme Premiers dploiements et boucle de rtroaction
165
24/09/10
Revue de projet : le jalon fin de Construction
valuation :

Version du logiciel est elle stable ? Tous les intervenants sont prts ? Dpenses relles/prvisionnelles acceptables ?
Lancement
Elaboration
Construction
Transition
331
Phase de transition
Phases
Modlisation mtier
Elaboration
Construction
Transition
Recueil des besoins
Implmentation
Tests
332
166
24/09/10
Phase de transition
(4/4)
Dployer Tester Valider (rponse aux attentes des utilisateurs) Accompagner lutilisateur final (packaging, documentation, formations, manuels )
333
Phase de transition
Objectifs :

Excuter les tests bta Former les utilisateurs Prparer le site de dploiement Prparer le lancement Obtenir laccord des intervenants Amliorer les performances futures
334
167
24/09/10
Revue de projet : Jalon Fin de la Transition
valuation :

Satisfaction des utilisateurs Bilan sur les ressources rellement consommes
Lancement
Elaboration
Construction
Transition
335
Bibliographie
P. Kroll et P. Kruchten, Guide pratique du RUP, CampussPress, 2003 P. Kruchten, Introduction au Rational Unified Process, Eyrolles, 2000 Craig Larman, Applying UML and patterns - An introduction to object oriented analysis and design and the Unified Process, Prentice Hall, 2004 Exemple de projet entirement RUP : http://jdbv.sourceforge.net/
336
168

Guiochet CoursN7 vTOTALE

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Guiochet CoursN7 vTOTALE

Enviado por

Direitos autorais:

Formatos disponíveis

24/09/10

Vers une conception oriente objet des systmes embarqus

Jrmie Guiochet Universit Toulouse 3, LAAS-CNRS guiochet@laas.fr www.laas.fr/~guiochet

Support de Cours ENSEEIHT 3me anne AII

Partie 1 Les systmes embarqus Une introduction

Cours de Mario Paludetto (Conception SE + temps rel)

http://www.laas.fr/~mario http://www.laas.fr/laas/1-4287-Groupe-TSF.php http://www.irisa.fr/triskell/members/pierre-alain.muller

Cours de Jean Claude Laprie (Sret de fonctionnement)

Cours de Pierre Alain Muller (UML)

PARTIE 1 : Les systmes embarqus

Les systmes embarqus

Soppose linformatique gnraliste (Multi-usages et multi utilisateurs) Informatique embarque :

Systmes embarqus: Domaines d'application

Systmes orients calcul

Systmes orients contrle

Premier exemple : Automobile

65 microcontrleurs embarqus aujourdhui dans une Mercedes-Benz classe S

Ex.: Systme ABS

Dans un proche avenir

Systmes embarqus dans lautomobile Automobile (4) Contexte gnral

% du cot de l lectronique dans le vhicule

Ecole 11 Mines de Nancy des

24/09/10 ASS SI144

Deuxime exemple : faux dparts

Systmes Embarqus et performances temporelles

Faux dparts (2)

Le systme ou Les systmes?

Dparts Surveillance Chronomtrage

Anna Guevarra Cathy Freedman

Camera Camera Salle vido

Faux dparts (3) Exigences fonctionnelles

Starting-blocks avec capteurs de dpart intgrs.

Calcul des faux dparts:

Faux dparts (4) La vue utilisateur

Technique et dynamique du dpart 100m

Faux dparts (5)

Contraintes temporelles et exigences systme

= Propagation son haut-parleur couloir athlte

= Temps de dpart rel

Capteur 150kg Capteur 27kg

Fentre faux dpart t0? t0? (rglement)

Temps de calcul (grossi) Correction des mesures Affichage et signalisation t

Signal hautparleur couloir athlte

Instant de perception Athlte

Limite faux dpart 0,1s

Signal capteur starting-block

Architecture Systmes embarqus

Exemple darchitecture: System on Chip (SoC) Le tlphone portable

Contraintes: taille, poids, consommation, performance tlcom, disponibilit

Exemple darchitecture: System on Chip (SoC) Appareil photo numrique

Contraintes: taille, poids, consommation, temps dacquisition, stockage, etc.

Systmes embarqus: particularits

Electronique ou informatique ? (2)

Approche traditionnelle de dveloppement dun systme embarqu

Electronique ou informatique ? (3)

Technologie cl: Processeurs

NB : Orientation Systme sur Composant

Association microcontrleur DSP Association microcontrleur logique programmable Autre

Processeurs usage gnral (1)

Processeur programmable utilis pour de nombreuses applications (microprocesseur) Caractristiques

Exemple: Pentium, PowerPC, ARM, MIPS, etc.

Processeurs usage gnral (2) Les CPUs utiliss pour lembarqu

Exemple: DSP, microcontrleur (processeur 4bits, 8bits).