Cours AGL 2018-46-70

Plan
Chapitre1: Introduction au Génie Logiciel (AGL)

Chapitre2: Fonctionnalités de base pour le management
d’un projet
Chapitre3: Processus de développement – Exemple
d’une démarche de développement objet basée UML
Chapitre4: Les découpages et les modèles de
développement
Chapitre5: Facteurs et Critères de Qualité du logiciel
14/10/2018 Dr. Aymen LOUATI 46

Étapes du processus de développement
Analyse des
Spécifications
besoins
Analyse du
Maintenance système
Validation Conception
Implémentation

Analyse des besoins
Étape préalable si le client n’a pas une idée précise

du système à réaliser
o Étude informelle des fonctionnalités (externes) du

système sans considération technique: Point de vue
métier / utilisateur
o Aide au formalisme du problème à résoudre
o Production de documents textuels avec schémas,

graphes, etc.

Spécifications
Ce que doit faire le système côté client

o Document précis spécifiant les fonctionnalités
attendues (contour fonctionnel)
o Base du contrat commercial avec le client
o Document facile à comprendre par le client / utilisateur
o (scénarios, interactions, enchaînement d’écrans)
Les spécifications ne sont jamais complètes et définitives

(évolution du domaine, besoins supplémentaires, …)

Analyse du système
Quoi faire ? : comprendre et modéliser le métier

o Réflexion métier hors de toute considération technique
o Reste un support de discussion avec le client/utilisateur
(questions/réponses)
o Premier modèle du système (niveau métier)
o Identifier les éléments intervenant (acteurs) hors et
dans le système: fonctionnalités, structure et
relations, états par lesquels ils passent suivant
certains événements
L’analyse n’est jamais complète, mais elle doit être juste
Établissement du cahier des charges
et des contraintes du système
Conception
Comment faire le système: choix techniques

 Choix d’une architecture technique (matérielle,
logicielle) suivant certaines contraintes (robustesse,
efficacité, performances, portabilité …)
 Expertise informatique: hors compréhension du client
 Modèle de l’architecture logicielle du système
• Décomposition en sous systèmes: application
(interfaces), domaine (métier) et infrastructure
(implémentation)
• Permet la définition des phases d’implémentions,
de validation et de maintenances
Production d’un modèle du système final
en cohérence avec les choix d’architecture
Implémentation
 Trop de temps consacré à cette phase au détriment

d’analyse et de conception: mauvaise pratique, parfois
très coûteuse …
 Nécessite un savoir de la réutilisabilité des

composants, voir d’outils de génération de code (voir
MDA)
 L’activité sera de plus en plus tournée vers la

réutilisation des composants existants

Validation
 Tests de vérification
o Vérification de la robustesse et cohérence du système,
en particulier dans les cas d’exceptions
o Testeur est différent du concepteur ou du développeur
o Logiciels de tests: toute ligne de code doit être testée
o Différentes méthodes de validation (voir cours
méthodes formelles)
 Recette
o Validation client: accord avec les besoins
o Planification dès spécifications: cahier de recettes
 Activité souvent sous estimée

Maintenance
 Deux types de maintenance

o Correction des erreurs du système
o Demande d’évolution (modification de l’environnement
technique, nouvelle fonctionnalités …)
 Facteurs da qualité essentiels
o Corrections: robustesse
o Évolution: modificabilité, portabilité
 Étape longue, critique et coûteuse

o Une enquête effectuée aux USA en 1986 auprès de 55
entreprises a révélé que 53% du budget total d'un
logiciel est affecté à la maintenance

Exemple d’une
démarche Orientée
objets Basée sur le
langage UML

1. Avoir la discipline d’appliquer une bonne
démarche de développement de logiciel.
2. Réaliser son application utilisant le formalisme

UML et le bon outil CASE (Computer-Aided
Software Engineering).
3. Arriver à visualiser les problèmes, préciser les

comportements et les structures, fournir un
guide pour la réalisation, documenter les
décisions.

Modélisation: Contexte et Objectifs
 Complexité croissante des systèmes de plus en plus.
 Coût élevé de l’échec dans les systèmes critiques.
 Besoins de:
o Réutilisation
o Modélisation
o Abstraction
 Une production fiable et une conformité des

besoins.
 Une bonne démarche de modélisation.
 Une Sécurité de communication et une
rapidité d’exécution.
14/10/2018 ISI Kef Workshop 57

Modélisation
 Satisfaction du client.
 Production d’applications de qualité.
 Simplification de la réalité.
 Mieux appréhender le système.
Utiliser les bon outils de communication
 Le choix des modèles simplifie la manière d’aborder le
problème et sa solution.
 Décomposer le système en un ensemble de modèles pour en
améliorer la compréhension.
La modélisation est une des caractéristiques d’un

projet qui réussi
Pourquoi modéliser
 Fournir des spécifications claires : produire, exploiter, etc.
 Clarifier les objets, les concepts, les référentiels, les
processus.
Réponses possibles aux questions suivantes

o Pour quel processus je travaille?
o Quel rôle j’ai dans ce processus?
o Quel est l’ensemble des processus de mon entreprise?
Modéliser  Générer des modèles

 Abstraction de la réalité.
 Vue subjective mais pertinente de la réalité.

Modèle: Exemple
1er modèle
proposé
Système
= Réalité
3ème modèle
2ème modèle proposé
proposé

 Unified Modeling Language (uniquement un
langage et pas une méthode).
 Un fruit d’une évolution des méthodes orientées
objet.
 Une notation de plus en plus répandue (connue,
enseignée, supportée par les outils…).
 Pas de nécessité d’avoir des compétences métier:
fonctionnels et développeurs ont un langage commun.

Les diagrammes UML2.5
Vue statique Vue dynamique
Diagramme Diagramme
Diagramme Machine Diagramme de
de classe d’objets
d’activité d’états UML cas d’utilisation
Diagramme de Diagramme de Diagrammes

composants déploiement d’interaction
Diagramme de Diagramme de
séquence communication
Diagramme de Diagramme de Diagramme de Diagramme global Diagramme

profile structure composite paquetages d’interaction de timing
Nouveaux sous UML2
 Représentation
Possibilité
Diversité dede diagrammes
visualiser
graphiqueet pour
d’une
manipuler
séquence
une des éléments
d’opérations
modélisation de
sous
modélisation
ou de la structure
plusieurs angles d’un système
Domaine d’application
– Les systèmes informatiques d’entreprise,

– Les banques,
– Les télécoms,
– Les transports,
– La défense,
– Le web et etc.
– Même les plus gros projets peuvent être spécifiés et
maintenus en UML.
Quelques problèmes de communication

 Diagrammes complexes: difficiles à comprendre.
 Panoplie de diagrammes: perdre la direction.
Modélisation et Démarche
Un
 UMLbon
est-il Informaticien
la bonne solution? est un bon
 Comment appliquer la bonne démarche?
développeur,
 UML est unOUI c’est vrai
avantage pourmais ?????
la modélisation
ouTrès
une bon
 Comment ANALYSTE
générer
perte delestemps –pour
Trèslivrer
bon modèles? bon un
produit? CONCEPTEUR
1. Echanger avec son client
– Définir ensemble un diagramme de cas d’utilisation.
– Valider ensemble les scénarios.
2. Analyser et concevoir le système

– A partir des Uses Cases et des scénarios, définir le
diagramme de classe.
– A partir des scénarios, définir les diagrammes de
séquence et de collaboration (et enrichir les classes).
– Définir si besoins les diagrammes d’états…..
 Démarche linéaire (Modèle de la cascade),
 Processus Unifié (UP) (Modèle itératif),
 2Truck UP (Modèle en Y),
 Etc.… (panoplie de démarches et de modèles),
Simplifier une démarche

Proposition d’une démarche de
développement itérative et incrémentale par
activités s’inspirant du UP.

Démarche de développement Objet
Nécessité d’un outil de modélisation (CASE) + Sélection
de l’environnement de développement du projet
pivot à toute la conception.

Suite
Diagrammes de séquences
Diagrammes de classes (Modélisation de scénarios par
(Modélisation du domaine) échanges de messages)
Diagrammes d’activités Diagrammes de classe de

(Modélisation de processus conception
d’affaires ou autres) (objets, encapsulation, etc.)
Un même type de diagramme peut :
 Modéliser des concepts différents,
 Être utilisé à des moments différents du processus
de développement,
 Être à différents niveaux d’abstraction,
 Ne pas être utilisé,

Cours AGL 2018-46-70

Transféré par

Droits d'auteur :

Formats disponibles

Cours AGL 2018-46-70

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours AGL 2018-46-70

Transféré par

Droits d'auteur :

Formats disponibles

Plan

Chapitre1: Introduction au Génie Logiciel (AGL)

14/10/2018 Dr. Aymen LOUATI 46

14/10/2018 Dr. Aymen LOUATI 47

Étape préalable si le client n’a pas une idée précise

o Étude informelle des fonctionnalités (externes) du

o Aide au formalisme du problème à résoudre

o Production de documents textuels avec schémas,

14/10/2018 Dr. Aymen LOUATI 48

Ce que doit faire le système côté client

Les spécifications ne sont jamais complètes et définitives

14/10/2018 Dr. Aymen LOUATI 49

Quoi faire ? : comprendre et modéliser le métier

Comment faire le système: choix techniques

 Trop de temps consacré à cette phase au détriment

 Nécessite un savoir de la réutilisabilité des

 L’activité sera de plus en plus tournée vers la

14/10/2018 Dr. Aymen LOUATI 52

 Activité souvent sous estimée

 Deux types de maintenance

 Étape longue, critique et coûteuse

14/10/2018 Dr. Aymen LOUATI 54

14/10/2018 Dr. Aymen LOUATI 55

2. Réaliser son application utilisant le formalisme

3. Arriver à visualiser les problèmes, préciser les

14/10/2018 Dr. Aymen LOUATI 56

 Une production fiable et une conformité des

14/10/2018 ISI Kef Workshop 57

La modélisation est une des caractéristiques d’un

Réponses possibles aux questions suivantes

Modéliser  Générer des modèles

14/10/2018 ISI Kef Workshop 59

14/10/2018 ISI Kef Workshop 60

14/10/2018 ISI Kef Workshop 61

Vue statique Vue dynamique

Diagramme de Diagramme de Diagrammes

Diagramme de Diagramme de Diagramme de Diagramme global Diagramme

Nouveaux sous UML2

– Les systèmes informatiques d’entreprise,

Quelques problèmes de communication

2. Analyser et concevoir le système

Simplifier une démarche

14/10/2018 ISI Kef Workshop 67

14/10/2018 ISI Kef Workshop 68

Diagrammes d’activités Diagrammes de classe de

14/10/2018 ISI Kef Workshop 70

Vous aimerez peut-être aussi