Cours IFT2251 ? Introduction au génie logiciel Cours 1, Lundi 9 ...
Maintenance corrective (corriger les erreurs); Maintenance adaptative ... p.13: L'
analyste peut être lié au test système et le concepteur au test d'intégration (pour
leur planification, pas leur réalisation) .... OMG: Object Management Group.
part of the document
Cours IFT2251 Introduction au génie logiciel
Cours 1, Lundi 9 janvier 2006
Diagramme UML = Non formel (Semi-formel)
Il y a des méthodes formelles, surtout pour les applications critiques.
2/3 semestre: Méthodes semi-formelles
1/3 semestre: Réseaux de pétri et vérification (jeux de tests)
HYPERLINK "http://www.iro.umontreal.ca/~pift2251" www.iro.umontreal.ca/~pift2251
4 TPs à remettre
UML (1.8 ou 1.9 pour le cours, 2.0 est sorti, mais pas pour les cours)
Rational rolls (ou roads) (outils plus avancé)
SmartDraw ou MagicDraw comme outils de dessin (suffisant pour le cours)
Pas de livre comme tel, quelques références sur le plan de cours (par exemple pour des exercices).
Association d'idées:
La modularité: Principe
Théorie musicale: Notation (UML, Un langage de programmation)
Le grand guide du jardinage: Méthodologie (au sens d'ensemble de techniques)
Le jazz: Paradigme (Un style, une façon de faire)
Le tri par bulle: Méthode/Technique
Le compilateur java: Outil
Cours 2, mercredi 11 janvier 2006
Faute (
) ( Erreur (interne) ( Défaillance (externe)
Le test rend visible les erreurs en engendrant des défaillances.
Le débogage s'intéresse à éliminer les erreurs.
Le coût des modifications ou corrections d'erreur augmente exponentiellement. On cherche à rapprocher la courbe cloche de détection des erreurs de celle similaire de la création de celles-ci afin de minimiser les coûts.
La vérification s'assure que les spécifications sont correctes. [Correction au 2e sens]
Diapos:
p.9 VFFV, p.13 FVF, p.14 FF, p.16 VFF
p.22 Correction, p.23 Fiabilité, p.24 Robustesse, p.25 Performance, p.26 Convivialité,
p.27 Vérifiabilité, p.28 Facilité de maintenance (Maintenabilité), p.31 Réutilisabilité,
p.32 Portabilité, p.33 Interpérabilité (MS Office),
Cours 3, vendredi 13 janvier 2006
Logiciel système:
OS
Pilote
Logiciel temps réel: 1ms à 1s de temps de réponse. (logiciel réactif)
Pilote automatique
Appareil médicaux (échographie)
Logiciel affaire:
Paie
Gestion des comptes
Scientifiques / Ingénérie:
MathLab
Mathematica
RationalRoad
Compilateurs
Logiciel embarqué: (sert à controler un appareil, souvent temps réel aussi)
ABS (freins)
Électro-ménagers
Avions
Montres
Stimulateur cardiaque
Applications web:
Services genre convertisseur monétaire, maps, etc.
Intelligence artificielle: (Algorithmes non-numériques)
Jeux d'échecs avancé
Système expert (avec stratégies de recherche)
Système diagnostique (avec sous-questions)
Système qui apprend
Réseaux neuronaux.
Qualités d'un logiciel:
Interne:
Portabilité, correction, robustesse, facilité de maintenance, interopérabilité.
Externe:
Fiabilité, robustesse, performance, convivialité
Métric (exemple) déterminant d'une qualité pour un logiciel, par exemple, le nombre de liens entre les classes si on cherche à définir la maintenabilité d'un code en fonction de l'indépendance des classes.
Nature des changements dans un système: (p.53)
Perfectifs (nouveaux beosins)
Correctifs
Adaptatifs
Cours 4, lundi 16 janvier 2006
À quel autre principe l'abstraction est-il intimement lié? La Généralité
À quelles qualités logicielles le principe d'abstraction contribue-t-il directement? Réutilisation, Portabilité, Vérifiabilité, Correction
L'anticipation du changement, la généralité et l'incrémentalité sont des principes davantage liés au génie logiciel qu'aux autres disciplines d'ingénérie classiques. Pourquoi? À cause de la maléabilité du produit fini, on peut le modifier, en faire des versions.
Chap2,p.4: Pas très réaliste puisqu'on n'y prévoit pas de retour en arrière.
L'analyse se passe en dialogue entre le client et l'analyste. (p.6)
Exigences fonctionnelles versus non-fonctionnelles:
[Bibliothèque] Prêt, réservation, etc.
Facile pour personnes agées,
Cahier des charges: Un contrat en quelque sorte.
Le plan de test: Un autre contrat.
Conception architechturale: «macroscopique» p.6 ex.: Base de donnée 'clients'
Conception détaillée: «microscopique» ex.: Ce qu'est un client.
Interfaces du système: Capteur, périphériques, etc. (p.7)
Vérification (p.10)
Tests unitaires
Tests d'intégration
Test du système
Installation:
Mise en fonctionnement
(par exemple beta testers)
Maintenance (p.11)
Maintenance corrective (corriger les erreurs)
Maintenance adaptative (mdifications)
Maintenance perfective (améliorations)
Maintenance préventive (prévoir les mises-à-jour automatiques par exemple, logfiles pour évaluer la performance, etc.)
Validation: Par rapport au client
Vérification: Répond à la spécification
Gestion du risque: Financier (besoins trop grands?) ou au niveau du logiciel (cul-de-sac à prévoir)
p.13: L'analyste peut être lié au test système et le concepteur au test d'intégration (pour leur planification, pas leur réalisation)
Cours 5, mercredi 18 janvier 2006
Planification stratégique:
Budget, Risques, etc.
L'analyste doit aussi avoir des connaissance sur son environnement, voire en gestion, de même en relations.
Diagramme du contexte: Déterminer ce qui fait partie du système
Complet lorsqu'il rencontre le cahier des charges.
Un bon outil pour une méthodologie de gestion des changements: CVS
Chap2,p.29: Prototype jetable
Prototype évolutif (ou réutilisable) on doit s'assurer de sa rigueur.
Un autre processus de développement: RUP (Rational Unified Process) ( Larman
Le modèle en spirale est un modèle dit «évolutif»
Montrer/Livrer quelque chose au client
Évaluer la plus-value pour le client + critiques.
Ajuster le design et les objectifs
RUP est aussi un processus évolutif
InceptionÉlaborationConstructionTransitionBesoins______________-----¯¯¯¯¯¯¯¯--------------_______________________Analyse_______-----------------¯¯¯¯¯¯¯¯-------___________________________Design_____________________---------¯¯¯¯¯¯¯¯¯--------------_____________Implémentation___________________-----------¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯---__________Test______----___________--___--___----___--___--____---¯¯¯-----_______Itération 1, ité2, ité3, ité4, ité5, ité6, ité7, ité8, ité9, ité10,
Inception: Phase préliminaire, première conception, visualisation, etc
Processus évolutif: Processus où on reprend les étapes avec des ajouts.
RUP est itératif et incrémental, à chaque quelques itérations, on va livrer une version du système. (Le noyau, le noyau et un service, etc.)
Chapître 3: Analyse et spécification
p.8: Services, Contraintes
Besoins non-foncitonnels:
Fonctionalités supplémentaires (FURPS, Fonctionality, Usability, Reuability, Performance, S...)
p.10: Traçable: Être capable d'associer le besoin aux modules, au moyens utilisés pour y répondre (numérotation?)
Cours 6, lundi 23 janvier 2006
Réponses du .doc:
Fonctionnel, entrées
Fonctionnel, sorties
Foncitonnel, calcul
Fonctionnel, stockage
Non-fonctionnel, Qualité, Facilité de maintenance, amélioration (perfectif)
Non-Fonctionnel, PR, planning/délais
Non-Fonctionnel, Qualité, fiabilité/robustesse
Plateforme
X
p.22:
Cas d'utilisation
acteurs
scénarios
p.23:
à faire
(exercice)
nota: Jad, méthode par réunions intensives (genre brainstorming), méthodologie prescrite à suivre.
Cours 7, mercredi 25 janvier 2006
Cahier des charges:
Services du système ( Besoins fonctionnels
Contraintes du système ( Besoins non-fonctionnels
p.34: Manque: Réutilisabilité et Facilité de maintenance.
p.32: Besoins, Modules de conception, code, tests, documentation.
Degré de formalisme:
Formel: notament quand on peut le prouver.
pp.36-36, UML serait semi-formel, et surtout opérationnel.
Chap3.2, p.6: externes, temporels, d'état
Cours 8, lundi 30 janvier 2006
Chap4,p.8: Analyse structurée: 1980
Cours 9, mercredi 1er février 2006
OMG: Object Management Group
Architectures: Pipeline, Client-Serveur, Par tableau, etc.
Objets (p.39): Par comportement on parle plus d'opération que de méthode (plusieurs méthodes possibles pour une opération)
Exemple (système de télémarketing):
Cours 10, lundi 6 février 2006
Élément: Ce qu'on veut stocker.
Association: Entre des classes, (représente l'ensemble des liens)
Lien: Entre des instances
Dans le diagramme de classe: uniquement des liens.
Agrégation: Les éléments peuvent exister par eux-même et appartenir à plusieurs agrégats. (Segment d'un chemin)
Composition: Les éléments ne peuvent exister sans le composite. Ni appartenir à plusieurs composites. (Appartement d'un immeuble)
Cours 11, mercredi 8 février 2006
DFD: Agent externe DFD de la démo2#1, revu et corrigé:
UML: Acteur
Diagramme de classe: Pendant l'analyse et puis version revisée après. (Pas tout au départ)
(pas de qualifiant)
Association dérivée: Avec un backslash en avant.
Attributs dérivés: Avec un \ aussi.
Sac de liens: Ensemble avec redondances possibles.
Emploi, dans 4.2.26/27 = un travail précis, pas "travaille chez".
Exercices: (Instanciation, Généralisation, Spécialisation, Association, Agrégation, Composition ou Attribution)
Roger est un restaurateur: Instanciation
Un restaurateur est une personne: Spécialisation (point de vue du restaurateur)
Un repas complet a (entrée/plat pr./dessert): Agrégation
Un plat est une entrée, un plat pr. ou un dessert: Généralisation
Table 3 est une table du restaurant: Instanciation
La table 3 est vide: Attribution
Une boisson est soit de l'eau, du vin ou du café: Généralisation
L'eau est froide, le café est chaud: Attribution
Le café va bien avec le dessert: Association
Cours 12, lundi 13 février 2006
Diagramme de cas d'utilisation: En lien avec la limite automatisable du système.
(en opposition avec contexte qui parle du système complet)
p.3.5: On devrait, dans n cas réel, parler de «préposé au prêt».
Cours 13, mercredi 15 février 2006
Les flèches pour les include et les extends NE SONT PAS des flots de données.
Extend: pour répondre aux cas entrainant des scénarios secondaires (cas d'exception). (if)
Cours 14, lundi 20 février 2006
4.4.10:
Cours 15, mercredi 22 février 2006
p.4.5.10: Ordre: b1-c1-a2 ...
Cours 16, lundi 6 mars 2006
Diag. d'état: Normalement, les transitions ont un événement et une garde, mais quand il s'agit d'une transition de sortir dite «de complétion», on n'a besoin que d,une garde.
Point d'entrée: toujours (noter l'état initial)
Point de sortie: surtout pour les états composites, pas trop grave pour le shéma global.
Cours 18, lundi 13 mars 2006
Deux types de diagramme d'interaction: Séquence et Collaboration
Diagramme de séquence: On représente des objets, pas des classes.
Cours 19, mercredi 15 mars 2006
p.23: abab
Diag. de collaboration: «une instance du diagramme de classes»
Collaboration: «réalisation d'un cas d'utilisation»
Soit par un diagramme de collaboration
Soit par un diagramme de séquence ET un diagramme de classes.
métrique: la mesure d'une qualité. (par exemple la cohésion)
Cours 20, lundi 20 mars 2006
Approche de conception (BCE)
Reviser les scénarios des uses case
Schéma de robustesse * Inclure les classes interface au diagramme de classes
Diagramme de collaboration/squence * Ajouter les opérations au diagramme des classes
Réviser
Les objets entity, s'ils ne sont pas en mémoire, il faut prévoir uen interface pour y accéder (base de donées, etc.)
Cours 21, mercredi 22 mars 2006
- Analyse: - Diagramme de cas d'utilisation + document(scénario)
- Diagramme de classes (éléments du domaine)
- Autres diagrammes (état, activités, séquence) [liés au scénario]
- Conception: 1) Réviser scénarios des cas d'utilisation
2) Schéma de robustesse
3) Diagramme de séquence ou collaboration* | attribuer les responsabilités
4) Réviser la cohérence inter-diagrammes
*collaboration = réalisation d'un cas d'utilisation
p.5.1.52: L'ovale en pointillé est une collaboration. On affiche les rôles sur les liens et on défini la collaboration ailleurs, par exemple avec un autre diagramme de classes, ...
«Design pattern GoF»: Un catalogue de design patterns
Cours 22, lundi 27 mars 2006
Composant: mini-programme exécutable avec entrées/sorties. (en oposition à la notion de classe)
Cours 23, mercredi 29 mars 2006
p.5.2.13: Observer
Plusieurs clients: ne peut être tableau noir, plutôt client-serveur
Cours 24, lundi 3 avril 2006
p6.6: Inflow = {(kp,A),(ks,A)} (compote p.4)
Outflow={(A,pc),(A,pg)}
p6.8: In(A) = kp,ks
Out(A) = pc,pg
p6.9 M(kp)=nombre de jetons dans kp (Marquage / État)
Cours 25, mercredi 5 avril 2006
p.6.27, Pour modéliser un tampon de n unités, il suffit d'initialiser le contenu du tampon avec n jetons et de changer le sens des deux places modélisant le tampon pour 'nombre d'éléments dans le tampon' et 'nombre de position libres'.
Cours 26, lundi 10 avril 2006
p.6.65: pas k-borné pcq contient un w
pas réversible pcq pas de boucle sur un état qui match l'initial (avec ou sans w), (ou pcq contient un blocage)
pas vivant, parce que blocage
Cours 27, mercredi 12 avril 2006
Caractéristiques fondamentales du graphe des marcages accessibles:
GA(): Un marquage M est atteignable ssi il existe un sommet M dans GA().
GC(): Si le marquage M est atteignable dans alors il existe un sommet qui couvre M dans GC().
Réseau vivant si toutes les transitions sont vivantes.
À partir d'un graphe de couverture on ne peut pas décider de la vivacité, mais on peut décider d'un deadlock.
Propriété: R réversible + R quasi-vivant ( R vivant
quasi-vivant ( toutes transitions atteignable à partir de M0
vivant ( toutes transitions atteignable à partir de tous les M.
Donc, si quasi-vivant et réversible, alors forcément vivant.
Matrice d'incidence C: R=
c(p,t) = W(t,p) W(p,t) (sortants moins entrants)
T1T2T3T4T5T6P1-101000P21-10000P301-1000P40-110-11P5000-101P60001-10P700001-1
On obttient l'équation caractéristique du réseau de Petri: M = M0 + C(u
où u est un vecteur ensemble de transitions.
EMBED Equation.DSMT4 EMBED Equation.DSMT4
Note:
Si on trouve un u, on ne sait pas si c'est franchissable car la matrice ne teste pas les préconditions.
Si on trouve ne trouve pas de u, on peut toutefois dire qu'il n'y a pas de façon d'y arriver.
Si C(u = 0, alors les solutions pour les u franchissables sont des invariants de transition
(T-invariant).
MT(x = (M0 + C(u)T(x
MT(x = M0T + uT(CT(x
Si CT(x = 0, alors MT(x = M0T alors les solutions pour x sont des invariants de place
(P-invariants)
Ex.: CT(x = 0 dans notre exemple, x1=(1,1,1,0,0,0,0) est une solution
x2=(0,0,1,1,0,0,1)
M(p1) + M(p2) + M(p3) = M0T(x1 = 1
Trappe: Ensemble de places telles que les t sortantes sont un sous-ensemble des t entrantes.
Chaque t qui enlève un jeton d'une place de la trappe, doit remettre au moins unjeton dans la trappe.
Une trappe est dite marquée ssi il y a au moins un jeton dans la trappe au départ.
Si une trappe est marquée dans M0 alors elle est aussi marquée dans tous les MA.
P1 est une trappe, P3-P4 est une trappe
Fin du cours.
EMBED SmartDraw.2
EMBED SmartDraw.2
EMBED SmartDraw.2
EMBED SmartDraw.2
EMBED SmartDraw.2
EMBED SmartDraw.2
EMBED SmartDraw.2
