Développement de logiciel

Le contenu est basé aux transparents du 7ème édition

de «Software Engineering» de Ian Sommerville

B.Shishedjiev - Génie logiciel 1

Développement de logiciel

http://www.software-engin.com/




Styles de développement

• Développement rapide– DR incrémental– DR par prototypes– Développement agile

• Développement extrémal

• Développement avec réutilisation

– Composants


Développement rapide

• Besoins– L’environnement n’est pas stabile et les sociétés

doivent répondre aux nouvelles circumstances. – Ça exige un développement rapide.– Les clients peuvent accepter une qualité médiocre si

la foncionalité de base est assurée vite.

• Particularités– Besoins instables– Processus itérative


Développement itératif

Validateincrement

Build systemincrement

Specify systemincrement

Design systemarchitecture

Define systemdeliverables

Systemcomplete?

Integrateincrement

Validatesystem

Deliver finalsystem

YES

NO


Développement rapide

• Avantages– Rapide– Participation des clients

• Désavantages– Gestion difficile– Contracte flou – il n’y a pas une spécification claire– Validation– Maintenance – les changement continus gâtent le

système


Prototypes• Particularités

– Utilisés quand on veut identifier les besoins.– Quand le besoin est spécifié le prototype est jeté et détruit

• Comparaison avec la méthode incrémentale– Incrémentale - on commence du besoin le plus claire– Prototype - on commence du besoin le plus flou

Incrementaldevelopment

Thr ow-awayprototyping

Delivered system

Executable prototype +System specification

Outlinerequirements


Les méthodes agiles


Les méthodes agiles

• Principes– Participation des clients– Produit incrémental– Les gens sont importants, pas le processus – un peu

discutable– Attends les changements– Maintiens simplicité


Programmation extrémal

• C’est une approche extrémale– On paut faire des nouvelles versions plusieurs fois

par jour– Les améliorations sont livrées aux clients chaque 2

semaines.– Chaque versions doit être testée. Elle n’est acceptée

sauf tous les tests ont passé.


Programmation extrémal• Le cycle de la version

Break downstories to tasks

Select userstories for this

releasePlan release

Releasesoftware

Evaluatesystem

Develop/integrate/test software



• Pratiques– Petits incréments – Petits version délivrées– Conception simple– Développement basé aux tests automatisés– Amélioration continue du code– Programmation en paires– Possession collective du code– Soutenable rythme de travail– Présence permanente du client



• Besoins– Histoires des utilisateurs– Scénarios– Tâches

• Changements– Les changements sont faits directement quand ils

sont nécessaires



• Tests– Les tests d’abord

• Les tests sont écrits avant le code

• Ils sont écrits comme des programmes afin d’être exécutés automatiquement

• Tous les tests sont exécutés – les vieux et les nouveaux – quand on ajoute une nouvelle fonctionnalité.

– Les tests sont dérivés depuis les scénarios– Les utilisateurs participent– On utilise des programmes de test automatiques



• Programmation en pairs– Un code est développer par paires de programmeurs

ensemble– Le code est possédé par tout l’équipe– Ça propage le savoir dans l’équipe


Développement appliqué rapide

• Plus traditionnelles• Application d’accès aux bases de données• Outils

– Langage de programmation de BD– Générateur d’interface– Liaisons vers application de Bureautique– Générateurs de rapports


Développement appliqué rapide• Environnement de développement rapide

DBprogramming

language

Interfacegenerator

Officesystems

Reportgenerator

Database management system

Rapid applicationdevelopment environment


Développement appliqué rapide

• Génération d’interface– Générer des formulaires complexes par des

techniques visuelles– Assurer l’enchaînement des formulaires et la

validation de la saisie

• Programmation visuelle– Problèmes

• Mauvaise structure

• Difficile de travailler en équipes

• Maintenance compliquée


Réutilisation

• Applications• Composants• Objets et fonctions


Réutilisation• Avantages

– Sécurité améliorée– Risque de processus diminué– Utilisation effective des spécialistes– Conformité aux standard– Développement plus rapide– Moins cher

• Problèmes– Maintenance plus difficile – quand le code source n’est pas

disponible– Manque des outils de support – Jalousie – Création et maintenance d’une bibliothèque de composants– Comprendre et assembler les composants


Différents types de réutilisation

Designpatterns

Component-baseddevelopment

Componentframeworks

Service-orientedsystems

COTSintegration

Applicationproduct lines

Legacy systemwrapping

Programlibraries

Programgenerators

Aspect-orientedsoftware development

Configurable verticalapplications


Approches• Modèles de conception (Design patterns)• Basé aux Composants• Structure appliquée (Application framework) • Enveloppe d’un système hérédité• Système orienté service• Intégration COTS (Commercial off the Shelf System)• Ligne de production• Application configurable verticalement• Bibliothèques de programmes• Générateur de programmes• Aspect orienté


Design paterns

• Il présente la description du problème et sa solution

• Eléments– Nom– Description du problème– Description de la solution – modèle qui peut être

implémenté de façons différentes– Conséquences – les résultats et les compromis qu’on

doit faire en utilisant le modèle


L’observateur• Nom

– Observer.

• Description– Sépare la présentation d’état d’objet de l’objet lui-même

• Description du problème– On l’utilise quand on a besoin de nombreux présentations.

• Description de la solution– Vois le diagramme UML.

• Conséquences– Optimiser pour améliorer les présentation à l’écran ne sont

pas utiles


Nombreux écrans

A: 40B: 25C: 15D: 20

Observer 1

A

B

C

D

Observer 2

Subject

0

50

25

A B C D


Le modèle observateur

Subject Observer

Attach (Observer)Detach (Observer)

Notify ()

Update ()

ConcreteSubject

GetState ()

subjectState

ConcreteObserver

Update ()

observerState

observerState = subject -> GetState ()return subjectState

for all o in observers o -> Update ()


Réutilisation de modèle

• Le plus abstrait et le plus générale• Types

– Générateurs du programmes– Modèles de conception


Générateurs de programmes

• Types– Pour application de traitements de données– Pour analyseur lexique et analyseur syntactique des

processeurs de langages – yacc, JavaCC– Les générateurs de code dans les outils CASE


Générateurs de programmes

Program generator Generated programApplicationdescription

Application domainknowledge Database


Développement aspect orienté

• On utilise des tisserands d’aspect

Generated code

Aspect 1 Aspect 2

AspectWeaver

<statements 1>Aspect 1

<statements 2>Aspect 2

<statements 3>

Input source code

<statements 1>join point 1

<statements 2>join point 2

<statements 3>


Structures appliquées (Frameworks)

• Ce sont des collections de classes abstraites et concrètes et les interfaces entre eux.

• Types– Infrastructure système (communication, compilateurs,

UI)– Intégration – communication entre composants et

échange de données– Application d’entreprise

• Extension • Problèmes

– Très complexes


Model-view controller• Modèle de GUI• Nombreux présentation d’un objet et interraction avec

les présentations individuellement

Model methods

Controller methods View methods

Userinputs

view modificationmessages

Model edits

Model queriesand updates

Controller state View state

Model state


Réutilisation des systèmes d’application

• Types– COTS– Ligne de production


COTS• Système d’acquisition

Client

Web browser E-mail system

Server

E-commercesystem

Ordering andinvoicing system

E-mail system

Adaptor

Adaptor


COTS

• Problèmes d’intégration– Manque de contrôle sur l’effectivité et fonctionnalité– Manque de contrôle d’évolution– Manque de support– Difficultés avec l’interopérabilité


Ligne de production

• Ce sont application d’une fonctionnalité générique qui peut être configurée pour les besoins du client

• Adaptation– Configuration du système ou de composants– Ajouter des nouveaux composants – Sélectionner d’une bibliothèque de composants– Modifier des composants


ERP • Enterprise Ressource Planning System

Configurationdatabase

System database

Generic ER

P system

Configurationplanning tool


Architecture

• Architecture de Ressource management System

User interface

Resourcemanagement

Resource policycontrol

Resourceallocation

Userauthentication

Querymanagement

Resource database

Resourcedelivery

T ransaction management

Développement d’un produit


Elicitstakeholder

requirements

Chooseclosest-fit

family memberDeliver new

family member

Renegotiaterequirements

Adapt existingsystem

Documents

Développement de logiciel