Notes de cours IFT2251.doc - igt.net

Pour désagréables que soient pendant un temps les effets de telles ... de Rouen,
s'intéresse aux acquis des élèves sur les nombres réels en début de seconde.
..... Defeated, one had to carry on living amidst the rules of an obscure, unknown
system. ..... Les experts ne sont pas seulement capables de piloter et réguler
leurs ...

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) 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)
1. Tests unitaires
2. Tests d'intégration
3. 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 |Élaboration |Construction |Transition |
|Besoins |______________ |-----¯¯¯¯¯¯¯¯---|---------_______|______________ |
| | |-- |__ | |
|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:
1. Fonctionnel, entrées
2. Fonctionnel, sorties
3. Foncitonnel, calcul
4. Fonctionnel, stockage
5. Non-fonctionnel, Qualité, Facilité de maintenance, amélioration
(perfectif)
6. Non-Fonctionnel, PR, planning/délais
7. Non-Fonctionnel, Qualité, fiabilité/robustesse
8. Plateforme
9. X p.22:
1. Cas d'utilisation
2. acteurs
3. 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