Vous êtes sur la page 1sur 168

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)

Systmes embarqus COO J. Guiochet

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

Systmes embarqus COO J. Guiochet

24/09/10

16

24/09/10

Les moyens de communications embarqus (3)

Le bus CAN (Controller Area Network)

Systmes embarqus COO J. Guiochet

Les moyens de communications embarqus (4)

Wifi : Communication sans fils

2 modes : infrastructure et ad-hoc

Basic Service Set


Systmes embarqus COO J. Guiochet

Independent Basic Service Set


24/09/10

17

24/09/10

Les moyens de communications embarqus (5)

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

Exemple : Architecture des calculateurs Airbus (2)

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

Exemple : Architecture des calculateurs Airbus (3)


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

Exemple 2 : Boeing 777 (2)


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

Exemple 2 : Boeing 777 (3)


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

Systmes embarqus: Dveloppement des STR - Intro

(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

Systmes embarqus: Dveloppement des STR - Intro

(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

Dveloppement des Systmes embarqus: Approches Synchrone / Asynchrone (2)


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

Dveloppement des Systmes embarqus Approches Synchrone / Asynchrone (4)


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

Dveloppement des Systmes embarqus Approches Synchrone / Asynchrone (5)

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

Systmes embarqus COO J. Guiochet

Dveloppement des Systmes embarqus Approches Synchrone / Asynchrone (6)


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

Dveloppement des Systmes embarqus: Approches Synchrone / Asynchrone (7)


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

Dveloppement des Systmes embarqus: Approches Synchrone / Asynchrone (8)


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

Dveloppement des Systmes embarqus: Approches Synchrone / Asynchrone (9)


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

Dveloppement des Systmes embarqus: Approches Synchrone / Asynchrone (10)


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

Systmes embarqus COO J. Guiochet

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

Systmes embarqus COO J. Guiochet

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)


Systmes embarqus COO J. Guiochet

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)


Systmes embarqus COO J. Guiochet

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.

Systmes embarqus COO J. Guiochet

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

Systmes embarqus COO J. Guiochet

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

Processus de Dveloppement

(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

Processus de Dveloppement

(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

Processus de Dveloppement
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

Systmes Embarqus COO J. Guiochet

24/09/10

1 Do vient lapproche objet ?

96

Systmes Embarqus COO J. Guiochet

24/09/10

48

24/09/10

Modlisation objet

Problmatique

Gestion de la complexit Approches de modlisation Gense dUML

Unification des mthodes objet

97

Systmes Embarqus COO J. Guiochet

24/09/10

Complexit des logiciels

La problmatique du domaine Le processus de dveloppement Linhrente flexibilit du logiciel

98

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes embarqus COO J. Guiochet

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

Systmes embarqus COO J. Guiochet

24/09/10

Notion de modle

Systmes embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

Dcomposition algorithmique

La fonction donne la forme du systme

108

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

Dcomposition objet

La fonction est ralise par des objets collaborants

110

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

59

24/09/10

Langage de modlisation

Gnrique Expressif Flexible (configurable, extensible) Syntaxe et smantique Unification par convergence

119

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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
Systmes Embarqus COO J. Guiochet

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
Systmes Embarqus COO J. Guiochet

Systme Informatique
24/09/10

2. Les Principaux diagrammes dUML

124

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

63

24/09/10

Les diagrammes dUML

(UML1.5)

127

Systmes Embarqus COO J. Guiochet

24/09/10

Diagramme dobjets

reprsente les objets et leurs relations (correspond un diagramme de collaboration simplifi, sans reprsentation des envois de messages).

128

Systmes Embarqus COO J. Guiochet

24/09/10

64

24/09/10

Diagramme de classes

Reprsente la structure statique en terme de classes et de relations.

129

Systmes Embarqus COO J. Guiochet

24/09/10

Diagramme de composants

Reprsente les composants physiques dune application.

130

Systmes Embarqus COO J. Guiochet

24/09/10

65

24/09/10

Diagramme de dploiement

Reprsente le dploiement des composants sur les dispositifs matriels.

131

Systmes Embarqus COO J. Guiochet

24/09/10

Diagramme de cas dutilisation

Reprsente les objectifs en terme de fonctionnalits du systme du point de vue de lutilisateur.

132

Systmes Embarqus COO J. Guiochet

24/09/10

66

24/09/10

Diagramme de squence

Reprsentation temporelle des objets et de leurs interactions.

133

Systmes Embarqus COO J. Guiochet

24/09/10

Diagramme de collaboration

Reprsentation spatiale des objets, des liens et des interactions.

134

Systmes Embarqus COO J. Guiochet

24/09/10

67

24/09/10

Diagramme dtats-transitions

Reprsente le cycle de vie dun objet

135

Systmes Embarqus COO J. Guiochet

24/09/10

Diagramme dactivit

Reprsente un enchanement dactivits au sein dune opration, dun cas dutilisation ou dun processus mtier.

136

Systmes Embarqus COO J. Guiochet

24/09/10
[PAM-00 p94]

68

24/09/10

Diagrammes dUML2.0

137

Systmes Embarqus COO J. Guiochet

24/09/10

3. Objets et classes

138

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

Reprsentation graphique des objets

140

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

71

24/09/10

Caractristiques fondamentales des objets


Ltat Le comportement Lidentit

143

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

Exemples (suite)

146

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

Le chaos des objets (suite)

148

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

Reprsentation graphique des classes

150

Systmes Embarqus COO J. Guiochet

24/09/10

75

24/09/10

Classes et objets

151

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

Les relations entre classes

Lassociation Lagrgation La

composition La gnralisation
156
Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

Exemple

158

Systmes Embarqus COO J. Guiochet

24/09/10

79

24/09/10

Nommage des associations

Indication du sens de lecture

159

Systmes Embarqus COO J. Guiochet

24/09/10

Nommage des rles

Le rle dcrit une extrmit dune association

160

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

81

24/09/10

Exemples

163

Systmes Embarqus COO J. Guiochet

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


Systmes Embarqus COO J. Guiochet

164

24/09/10

82

24/09/10

Exemple

165

Systmes Embarqus COO J. Guiochet

24/09/10

Hirarchies de classes

Grer la complexit

Arborescences de classes dabstraction croissante Super-classes Sous-classes

Gnralisation

Spcialisation

166

Systmes Embarqus COO J. Guiochet

24/09/10

83

24/09/10

Gnralisation

Factoriser les lments communs

attributs, oprations et contraintes

167

Systmes Embarqus COO J. Guiochet

24/09/10

Spcialisation

Extension cohrente d'un ensemble de classes

168

Systmes Embarqus COO J. Guiochet

24/09/10

84

24/09/10

Proprits de la gnralisation

Signifie toujours : est un ou est une sorte de

169

Systmes Embarqus COO J. Guiochet

24/09/10

Proprits de la gnralisation

Non-rflexive, non-symtrique, transitive

170

Systmes Embarqus COO J. Guiochet

24/09/10

85

24/09/10

Gnralisation multiple

171

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

87

24/09/10

Exercice 1: solution possible

175

Systmes Embarqus COO J. Guiochet

24/09/10

Exercice 2 :
construire le diagramme de classe relatif lnonc suivant

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

Systmes Embarqus COO J. Guiochet

24/09/10

88

24/09/10

Exercice 2 : solution possible

177

Systmes Embarqus COO J. Guiochet

24/09/10

Exercice 3 :
construire le diagramme de classe relatif lnonc suivant

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

Systmes Embarqus COO J. Guiochet

24/09/10

89

24/09/10

Exercice 3 - solution possible : la classe dassociation

179

Systmes Embarqus COO J. Guiochet

24/09/10

Exercice 4:

construire le diagramme de classe relatif lnonc suivant

Dfinir un schma dcrivant les liens familiaux (mariage, parent/enfant) d'une population de personnes identifiables par un numro.

180

Systmes Embarqus COO J. Guiochet

24/09/10

90

24/09/10

Exercice 4: solution possible

181

Systmes Embarqus COO J. Guiochet

24/09/10

Exercice 5 :

construire le diagramme de classe relatif lnonc suivant

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

Systmes Embarqus COO J. Guiochet

24/09/10

91

24/09/10

Exercice 5 : solution possible

183

Systmes Embarqus COO J. Guiochet

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
Systmes Embarqus COO J. Guiochet

24/09/10

92

24/09/10

Exercice 6 : MonAuto
CRUD CRUD

CRUD

CRUD

CRUD

185

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

93

24/09/10

4. La dynamique des objets

187

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

94

24/09/10

Les objets ne vivent pas en ermites

Les objets interagissent les uns avec les autres

189

Systmes Embarqus COO J. Guiochet

24/09/10

Communication entre objets

Les objets communiquent en changeant des messages

190

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

99

24/09/10

Retrait despce Diagramme de Collaboration

199

Systmes Embarqus COO J. Guiochet

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
Systmes Embarqus COO J. Guiochet

24/09/10

100

24/09/10

Simple watch: Diagramme de Squence

UML2 notation

loop

[B2.state = Pushed]

201

Systmes Embarqus COO J. Guiochet

24/09/10

Simple Watch: Diagramme de Collaboration

202

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

102

24/09/10

tats (suite)

Caractristiques :

un tat initial

des tats intermdiaires


Etat intermdiaire

des tats finaux

205

Systmes Embarqus COO J. Guiochet

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


Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

104

24/09/10

Les actions et les activits

209

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

105

24/09/10

Exercice 3 - 1

211

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

Exemple

214

Systmes Embarqus COO J. Guiochet

24/09/10

107

24/09/10

Exemple

(suite)

Diagramme

dtat-transitions de la classe Personne

215

Systmes Embarqus COO J. Guiochet

24/09/10

Sous-tats de EnPhaseEmbauche

EnPhaseEmbauche

216

Systmes Embarqus COO J. Guiochet

24/09/10

108

24/09/10

Sous-tats de Embauch
Embauch

217

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

110

24/09/10

Exemple

221

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

111

24/09/10

Proposition Solution 1

223

Systmes Embarqus COO J. Guiochet

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

Proposition Solution 2

225

Systmes Embarqus COO J. Guiochet

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

Proposition Solution 3

miseEnService

227

Systmes Embarqus COO J. Guiochet

24/09/10

Exercice 4 : cabine tlphonique

Modlisez le fonctionnement dune cabine tlphonique

228

Systmes Embarqus COO J. Guiochet

24/09/10

114

24/09/10

Proposition de Solution 4

229

Systmes Embarqus COO J. Guiochet

24/09/10

5. Les Cas dutilisation

230

Systmes Embarqus COO J. Guiochet

24/09/10

115

24/09/10

Les cas dutilisation

Expression des besoins

231

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

Fil conducteur du projet

234

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

122

24/09/10

Solution

245

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

123

24/09/10

-6Un Processus de dveloppement ultralger pilot par les cas dutilisation

247

Systmes Embarqus COO J. Guiochet

24/09/10

Le virage vers lobjet

248

Systmes Embarqus COO J. Guiochet

24/09/10

124

24/09/10

Le virage vers lobjet

249

Systmes Embarqus COO J. Guiochet

24/09/10

Exemple / Le cas dutilisation retrait en espce

250

Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

24/09/10

Exemple / Diagramme de squence systme


du CU retrait en espce

252

Systmes Embarqus COO J. Guiochet

24/09/10

126

24/09/10

Exemple (suite) - Diagramme de squence de conception (incomplet)


du CU retrait en espce

253

Systmes Embarqus COO J. Guiochet

24/09/10

Exemple (suite) Diagramme de classes de conception


(classes collaborantes du CU retrait en espce)

254

Systmes Embarqus COO J. Guiochet

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
Systmes Embarqus COO J. Guiochet

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

Systmes Embarqus COO J. Guiochet

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


Systmes Embarqus COO J. Guiochet

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

134

24/09/10

Quest ce que le Processus Unifi ?

(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

COO SE J. Guiochet 24/09/10

Quest ce que le Processus Unifi ?

(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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

Les quatre phases


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

272

COO SE J. Guiochet 24/09/10

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
273 COO SE J. Guiochet 24/09/10

Les enchanements dactivits


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

274

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

Modlisation mtier

Comprhension de la structure et la dynamique de lorganisation Comprendre les problmes poss dans le contexte de lorganisation Conception dun glossaire

276

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

139

24/09/10

Implmentation
Dveloppement incrmental Dcoupage en couches Composants darchitecture Retouche des modles et des besoins Units indpendantes, quipes diffrentes

279

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

143

24/09/10

Ensemble dartefacts

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

287

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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)
291 COO SE J. Guiochet 24/09/10

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>
[]
292 COO SE J. Guiochet 24/09/10

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
293 COO SE J. Guiochet 24/09/10

Lensemble des exigences


Demandes des intervenants Modle des CU Spcifications supplmentaires Modle mtier

294

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

Modle mtier

Diagramme de classes mtier Diagramme de C.U. mtier Diagramme dactivits mtier

298

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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
COO SE J. Guiochet 24/09/10

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]
COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

Lensemble de dploiement

Scripts et guide dinstallation Documentation utilisateur Matriel de formation

304

COO SE J. Guiochet 24/09/10

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
307 COO SE J. Guiochet 24/09/10

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)
COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

Choisir les technologies logicielles de la partie logicielle

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

COO SE J. Guiochet 24/09/10

157

24/09/10

Choisir les technologies logicielles de la partie logicielle

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
COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

159

24/09/10

Exercice : Lister ci dessous lensemble des artefacts produits pendant la phase de lancement

319

COO SE J. Guiochet 24/09/10

Phase dlaboration
Phases
Lancement (inception)
Modlisation mtier

Elaboration

Construction

Transition

Recueil des besoins

Principaux enchanements du processus

Analyse et Conception

Implmentation

Tests

320

ItElab1

ItElab2

COO SE J. Guiochet 24/09/10

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)


321 COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

Phase de construction
Phases
Lancement (inception)
Modlisation mtier

Elaboration

Construction

Transition

Recueil des besoins

Principaux enchanements du processus

Analyse et Conception

Implmentation

Tests
Cstr1 Cstr2

326

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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)


328 COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

330 COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

Phase de transition
Phases
Lancement (inception)
Modlisation mtier

Elaboration

Construction

Transition

Recueil des besoins

Principaux enchanements du processus

Analyse et Conception

Implmentation

Tests

332

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

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

COO SE J. Guiochet 24/09/10

168