Plan du chapitre

Architecture logicielle : 1. Architecture logicielle : de quoi sagit-il ?

introduction
Jean-Paul Arcangeli
UPS IRIT / Equipe SMAC
UPS, M1 Informatique
UE AL , Sp. DL & IHM
4 & 11 janvier 2016
Problmatique et primtre
2. Les exigences
3. Quelques dfinitions et concepts
Architecture logicielle
Composants et rutilisation
Style/pattern darchitecture
4. Conception architecturale
Mthode ADD (Attribute-Driven Development)
5. Documentation
Catgories et types de vues
2

Quelques ressources Quelques ressources

Software Architecture in Practice (3rd edition)

Fondements de l'ingnierie des exigences et modlisation
L. Bass, P. Clements, R. Kazman
avec URN
Addison Wesley, 2013
http://fr.slideshare.net/rickkazman/
Daniel Amyot, Confrence, M1 Informatique, UPS, 12/11/15

Documenting Software Architectures, Views and Software Architecture : an informal introduction

Beyond (2nd edition) David Schmidt, Kansas State University

P. Clements et al.
http://santos.cis.ksu.edu/schmidt/EJCP/talk08.pdf

Addison Wesley, 2011 Architectural Styles and the Design of Network-based

Software Architectures
Software Engineering (10th edition) R. T. Fielding, PhD dissertation, Univ. of Califormia, Irvine, 2000
I. Sommerville
SEI
Pearson, 2016
http://www.sei.cmu.edu/architecture/index.cfm
http://fr.slideshare.net/software-engineering-book/ 3 4
 Un peu dhistoire

Crise du logiciel la fin des annes 60

1. Architecture logicielle : Nouvelle gnration de machines
Plus puissantes
de quoi sagit-il ? Nouvelles applications
Retards de livraison, cots de dveloppement dpassant largement les
prvisions, manque de fiabilit des produits, faible performance,
difficults de maintenance
Les mthodes de dveloppement ne conviennent plus !

5 6

Un peu dhistoire Exemple de logiciel complexe

La production du logiciel a chang dchelle et augment en CATIA (v5 - 1998) : logiciel de CAO de Dassault Systmes
complexit 5 millions de lignes de code C++
Programmeur unique quipes de dveloppement 50.000 classes
Comment grer le dveloppement ? Une volutivit forte
Application mono-composant application multi-composant Une release tous les 4 mois
Quelles interconnexions ? Quelle organisation ? Extensibilit
Concurrence, rpartition Le client peut implanter et intgrer des fonctionnalits complmentaires
Construction from scratch rutilisation de composants Environ 1000 ingnieurs pour le dveloppement
Fabriqus pour dautres projets, ou acquis/achets par ailleurs 20.000 clients
Comment assembler/intgrer ? 180.000 licences

Passer dune dmarche artisanale une dmarche industrielle

Le logiciel est un produit issu dun processus de fabrication rationnel et
contrl
Naissance du gnie logiciel 7 8
 Exemple de logiciel complexe Autres exemples

SENIT (Systme dExploitation Naval dInformations

Principales sources de complexit (CATIA v5)
Nombre de lignes de code (et de composants )
5 millions de lignes de code (CATIA v5) 200 volumes de 500 pages !
Nombre dutilisateurs
Nombre dingnieurs et taille de lquipe de dveloppement
Forte frquence des changements (release)
Organiser le logiciel, le travail sur le logiciel, documenter
Tactiques) : systme de combat de la marine nationale
5 millions de lignes de code ADA et C++
Application temps-rel, rpartie et embarque (sur le porte-avions
CDG) avec des capteurs, des commandes darmes
Adaptable toutes sortes de navires (gnricit)
AGORA : systme dinfo. de la Mutualit Sociale Agricole
26 millions de lignes de COBOL
1,5 millions de lignes Java pour laccs en ligne
800 types darticles dans la BD

Microsoft Windows
Windows 7 : 20 40 millions de lignes de code ?
9 10

Architecture logicielle Le terme Architecture Logicielle

Un peu dhistoire encore
dsigne
Programming in the large (DeRemer & Kron, 1976)
Modules de code
Connexion des modules (niveau structurel)
plusieurs choses diffrentes
Dfinition des interfaces, contrles de visibilit (import/export)
En rapport avec la composition/dcomposition dun systme logiciel
vs Programming in the small (complexe) en parties (ou lments, ou composants ) et les
relations entre les parties
Cration des modules
Systme = ensemble dlments en interaction organiss pour atteindre un
ou plusieurs rsultats dclars (AFIS, 2004)
2 niveaux de conception et deffort diffrents
Abstraction et composition
Rq : dvelopper du logiciel, cest toujours faire des abstractions et de la Le domaine est (relativement) jeune
composition Dfinitions et processus pas toujours normalises
Styles
Dfinis par ce que lon compose et comment on compose (p. ex. (styles
de programmation)
11 12
 Le terme Architecture Logicielle Le terme Architecture Logicielle
dsigne (1) une (des) structure(s) dsigne (1) une (des) structure(s)

Spcifications
Ce que fait ou doit faire le logiciel c.--d. le quoi (un ensemble de
Larchitecture logicielle dsigne la (les) structure(s) dun proprits)
systme logiciel
Ensemble dlments logiciels (parties), de natures diverses,
Architecture logicielle
constitutifs du systme Structure organisationnelle du logiciel, labore pour raliser le quoi,
c.--d. le comment
Modules, classes, fichiers, archives, objets, processus (au sens systme
dexploitation ) Organisation
Relations entre ces lments Du code (dpendances entre lments, paquetages)
Dpendances fonctionnelles, flot de contrle ou de donnes, Du systme lexcution (dynamique, distribution)
communication, synchronisation, hritage Et mme davantage
Avec un certain niveau dabstraction (vision globale ou macro)
Proprits des lments, visibles vs caches
13 14

Le terme Architecture Logicielle Le terme Architecture Logicielle

dsigne (1) une (des) structure(s) dsigne (2) une activit

Larchitecture logicielle est une activit ou un ensemble

dactivits
En ce sens, larchitecture est donc le fruit dun travail de Relative(s) la structure du produit
conception de haut niveau Mene(s) dans le cadre dun projet
Larchitecture reflte les dcisions de conception de plus haut niveau Projet vs produit !
(D. Garlan, 2000)
A contrario, les design patterns visent un niveau de conception non
But de lactivit
architectural ( architecture du code ) -voir lUE MCPOOA-
Rsoudre un problme !
Quoique le pattern MVC Par exemple, dans le cadre de la fabrication ou de la modification dun
logiciel
Satisfaire des exigences (requirements) qui manent de diffrentes
parties prenantes (stakeholders)

15 16
 Le terme Architecture Logicielle Le terme Architecture Logicielle
dsigne (2) une activit dsigne (2) une activit

Partie prenante (stakeholder)

Individu, groupe dindividus ou organisation, concern par (ayant un
intrt pour) le produit logiciel et son dveloppement (et par les
dcisions les concernant)
Chaque partie prenante a des exigences -besoins-
(requirements)
Client
Utilisateur
Concernant le produit
Ingnieur marketing Comportement du systme, fonctionnalits attendues
Administrateur systme (rseau, BD) Utilisabilit, performance, sret de fonctionnement, scurit
Ingnieur en maintenance Maintenabilit, qualit (vs qualit des produits concurrents)
Concernant le projet
Chef de projet Cot de production, dlais de livraison, utilisation des ressources
humaines et des comptences disponibles
Concepteur, testeur

Et larchitecte logiciel !
17 18

Le terme Architecture Logicielle Le terme Architecture Logicielle

dsigne (2) une activit dsigne (2) une activit

Ne se limite pas une activit de conception

Comprendre les diffrents besoins/exigences (et arbitrer)
Dveloppement, dploiement, exploitation, maintenance
Essentielle et fondamentale lors de la conception du produit Concevoir (choisir et motiver les choix)
Reprsenter (formaliser) et documenter
Descriptions architecturales
Couvre toute la vie du produit logiciel diffrents stades Communiquer avec les diffrentes parties prenantes au projet
Pas uniquement son dveloppement (initial) Raisonner, analyser, valuer, mesurer, valider, vrifier
Dploiement, exploitation, maintenance Revues darchitecture
Phase activit ! Participer la gestion du projet
Organisation du travail de dveloppement
Planification
Etc.
19 20
 Le terme Architecture Logicielle Le terme Architecture Logicielle
dsigne (2) une activit dsigne (2) une activit

Conception architecturale vs conception non architecturale

Architecture vs conception, en rsum
Une partie de la conception est architecturale, mais pas tout !
Le distinguo nest pas trivial cela dpend du contexte
Conception architecturale
Choix et dcisions qui impactent significativement et durablement le Architecture
Conception
produit et le projet
CONCEPTION
En matire de comportement, de qualit, de dveloppement, de
ARCHITECTURALE
maintenance
Comprhension Algorithmique
Exemple : un systme de messagerie lectronique
Choix dune architecture client-serveur (architectural) Vrification
Choix dune structure de donnes ou dun algorithme, conception de la
structure interne dun service (non architectural)
Mais architectural si cela rpond une exigence essentielle !

21 22

Le terme Architecture Logicielle Le terme Architecture Logicielle

dsigne (2) une activit dsigne (3) une discipline
L architecte logiciel est la personne (ou lquipe) qui
pratique lactivit darchitecture
Interagit avec les parties prenantes
Larchitecture logicielle est une discipline
Prend les dcisions stratgiques et critiques
Dfinition des principales caractristiques du systme Du gnie logiciel
Scurit, sret de fonctionnement, temps-rel, donnes Dont lobjet est ltude de tout ce qui est relatif aux structures des
Choix de conception et arbitrages systmes logiciels
Par ex. plateforme et langage de programmation
Nature des lments et des relations
Reprise et intgration de lexistant vs refactoring
Avec un certain niveau dabstraction
Etc. Qui a merg il y a une vingtaine dannes et qui est encore immature
aujourdhui
Dfinit ou manipule la (les) structure(s)
venir : maturit, une vraie science, une pratique industrielle (D.
Coordonne lquipe projet Garlan, 2000)
Plutt un consultant-expert
Expriment
Capable de communiquer et de ngocier 23 24
 Les visions de larchitecture logicielle
acadmiques et industrielles diffrent !
Dans le milieu acadmique (discipline), on sintresse plutt
La formalisation darchitectures (au moyen de langages ddis)
Aux mthodes pour lanalyse et la preuve de proprits sur ces
architectures
Dans le milieu industriel (activit), la pratique de larchitecture logicielle
est plus empirique
laboration de mthodes et de solutions technologiques (pratique)
Lexprience de larchitecte est primordiale
La rutilisation est (parfois/souvent) vise
25
Larchitecture des btiments (2/3)
Lactivit darchitecture demande Transposition au domaine du logiciel et des systmes
La matrise et la mise en uvre diffrentes connaissances et
comptences
Comprhension des besoins prsents et futurs
Connaissance des matriaux assembler (avantages et limites)
Connaissance des procds de construction
Lexprience personnelle de larchitecte
Est un facteur prpondrant de qualit du produit
27
Larchitecture des btiments (1/3)
Travaux de C. Alexander (70s)
En gnie civil, larchitecte
Conoit le projet ou intervient sur un btiment existant
Il considre les contraintes techniques, les cots de fabrication
Il fait abstraction de la fabrication des briques, des murs, des portes, etc.
Il fait des choix (de niveau architectural)
Produit diffrents plans (reprsentations)
Plan de masse, coupes, faades, plans dtaills, plans des rseaux
Destins donner diffrentes vues de la construction des interlocuteurs
diffrents ayant des proccupations diffrentes
Produit un planning pour la ralisation de la construction
Coordonne les corps de mtier, planifie et suit les travaux, etc.
26
Larchitecture des btiments (3/3)
Terminologie
Matre douvrage, matre duvre, sous-traitant
Brique logicielle, maquette
Style darchitecture
Mais, ne pas pousser trop loin lanalogie
Les constructions logicielles sont immatrielles (frontire plus floue entre
architecture et produit)
Les besoins dvolution et de rutilisation du logiciel sont trs suprieurs
Le logiciel est plus facilement testable quun ouvrage de gnie civil
28
 Le concept dexigence

Un concept cl en architecture logicielle !

Un exigence est une proprit que la solution (produit ou

projet) doit satisfaire
2. Les exigences Une contrainte est une forme dexigence qui ne laisse pas (ou peu)
de choix en matire de solution

Formuler les exigences, cest poser le problme (que la

conception devra rsoudre)
Les exigences sont le pourquoi de la solution
Elles sexpriment avec DOIT , DEVRAIT ou PEUT
29 30

Classification possible des exigences Exigences fonctionnelles

FONCTIONNELLES
Exemples
Permettre lutilisateur de visualiser sous nimporte quel angle des
TECHNIQUES formes complexes en 3D
Me permettre de faire apparatre et disparatre des images dans mon
NON FONCTIONNELLES ou diaporama
PRODUIT
EXTRA-FONCTIONNELLES
Aider un automobiliste se dplacer dans un environnement urbain et
le guider
NON TECHNIQUES
EXIGENCES

Non fonctionnelles ou
extra-fonctionnelles
Expression de services rendus lutilisateur
Prcision
PROJET
Reprsentation possible par des
diagrammes de cas dutilisation
31 32
 Exigences techniques extra-fonctionnelles Exigences techniques extra-fonctionnelles

De natures diverses
Efficacit (performance)
Capacit du logiciel exploiter au mieux les ressources offertes par la ou
les machines htes et offrir des temps dexcution convenables
De natures diverses (suite)
Par ex., une transaction doit tre traite en moins de 5
Utilisabilit
Capacit du logiciel tre facile utiliser et matriser
Disponibilit
Par ex., le serveur doit pouvoir traiter jusqu 1000 requtes/min. Adaptabilit
Capacit du logiciel tre adaptable des besoins du client et
Fiabilit (sret de fonctionnement) personnalisable
Capacit du logiciel grer correctement ses propres erreurs de Configurabilit
fonctionnement en cours d'excution
Gestion des configurations
Confidentialit et intgrit (scurit)

Capacit du logiciel protger ses fonctions et ses donnes d'accs non
autoriss
Interoprabilit, portabilit, etc.
33 34

Exigences techniques extra-fonctionnelles Exigences extra-fonctionnelles (encore !)

Techniques mais pas seulement !

Testabilit
Vrifiabilit
CATIA v5 Conformit du produit avec les spcifications
Indpendance par rapport la plateforme dexcution Maintenabilit (simplicit, intelligibilit, modifiabilit) et volutivit,
Adquation avec les besoins spcifiques du client et son mtier (flexibilit, extensibilit)
Do une architecture ouverte Facilit de correction, de modification, dajout de fonctionnalits
Une infrastructure volutive dans laquelle on peut intgrer diffrentes En lien avec le volume du code et de la qualit de la documentation
fonctionnalits mtier A noter
Dassault Systmes fournit un kit de dveloppement pour ces produits Cot de maintenance dun avion approximativement gal au prix
intgrables dachat vs cot de maintenance dun logiciel sensiblement suprieur
Mais ne fournit pas le code source au prix dachat
Pour un produit logiciel, 80% des cots sont engendrs aprs la mise
en production (Bass et. al. 2013)

35

36
 Focus sur une exigence majeure : lvolutivit Typologie de lvolution dun produit (1/4)

Pourquoi ? -sources de lvolution-

Evolutivit (maintenance volutive) Correction de bugs
Ncessaire du fait de lusure du logiciel Maintenance corrective
Dtrioration au fur et mesure de la maintenance Adaptation un changement de contexte technique ou utilisateur
Evolution de lenvironnement : besoins, matriel, donnes (personnalisation) c.--d des conditions dexcution nouvelles
Traabilit ncessaire des besoins et des choix de conception Maintenance adaptative
Ajout de nouvelles fonctionnalits
Penser cent ans (Le Corbusier) Maintenance volutive
Mais cest difficile danticiper sur les exigences (futures) dvolution Amlioration des performances
Maintenance perfective

37 38

Typologie de lvolution dun produit (2/4) Typologie de lvolution dun produit (3/4)

Quand ?
froid (hors excution)
Alors que le logiciel est en cours de dveloppement
Quoi ? -sur quoi porte lvolution- Alors que le logiciel est en production
lment (ajout, retrait, modification) Anticipe ou pas
Configuration et liaisons (organisation logique globale), distribution chaud (pendant lexcution)
physique
Egalement documentation Qui ?
Humain
Logiciel (auto-adaptation dynamique)
Self-*

39 40
 Typologie de lvolution dun produit (4/4) Limites lvolutivit

Comment ?
Techniques Le couplage entre constituants
Paramtrage
Transformation de code, programmation par aspects
Couplage (entre modules A et B) = degr dinterdpendance entre A et
B en termes dvolution
Rflexivit
Etc.
Couplage faible : un changement dans A (ou B) a peu dimpact sur B (ou
A)
Contrle
Couplage fort : un changement dans A (ou B) demande des changements
Garantie de leffet attendu importants dans B (ou A)
Garantie dabsence deffets indsirables (cohrence)
tapes Do le besoin dune bonne (?) architecture
Dclenchement, dcision, ralisation Rduire les couplages (idem pour les design patterns)

Attention la traabilit
41 42

Exigences projet Exigences projet

Egalement de natures diverses

Faisabilit de larchitecture et productivit
CATIA v5
Capacit raliser le produit
Contraintes techniques
Impratifs de productivit
Charge, dlai (limitation du time-to-market), comptences
Lis au processus de dveloppement et de maintenance
Contraint pas le contexte projet Gestion de configuration
Nombre de parties prenantes et taille des quipes Gestion de version
Distribution gographique des parties prenantes et des quipes Gestion des dveloppements concurrents (travail collaboratif)
Paralllisation du travail Compilation
Coordination, communication et coopration Limiter les temps de compilation lors dune modification (impossible de tout
recompiler chaque fois), donc bien matriser les dpendances
Testabilit, vrifiabilit ?
...

43 44
 Classification des exigences extra-
Exigences projet
fonctionnelles (Sommerville, 2016)

Extraits du site www.osgi.org

Software complexity is increasing at an alarming rate. Today, a large
part of this complexity is caused by shortened product cycles,
requirements for drastically increased functionality, and an increasing
number of variations of the same product (e.g. different hardware and
operating systems). These trends have caused software costs to
become a larger percentage of almost any manufacturer's
development cost.
Today, software development largely consists of adapting existing
functionality to perform in a new environment A key issue is that
today's software environments focus on writing new software, instead
of integrating existing software into new systems. In reality, integrating
existing code has become a large part of the work of software
developers.
45 46

Comment grer les exigences ? Comment grer les exigences ?

Quelques problmes avec les exigences Ingnierie des exigences

Distinguer une catgorie dexigence dune autre nest pas vident
Les exigences ne sont pas indpendantes les unes des autres (par ex.
scurit)
Quid de la cohrence de lensemble des exigences ?
Quid de la compltude de lensemble des exigences ?
Quid de lvolution des exigences ?
Identifier (liciter), analyser, raffiner, formaliser, valider, documenter
les exigences
Exprimer plus ou moins formellement les exigences
Langage naturel (plus ou moins structur), notations graphiques, notations
mathmatiques
Prcisment et quantitativement afin de pouvoir mesurer/valuer leur
satisfaction

47 48
 Comment grer les exigences ? Finalement
(extrait de SWEBOK 3.0,
IEEE CS, 2014)

Lactivit darchitecture logicielle consiste donc uvrer sur

et pour la (les) structure(s) de systmes logiciels complexes
Abstraire, cacher et maitriser la complexit
Considrer le systme comme un ensemble cohrent dlments
en interaction
Dcomposer, composer
diffrents stades de la vie du logiciel

Cf. I. Sommerville, Soft. Eng. 10, Chap 4

49 50

Finalement Finalement

La difficult vient la fois de la nature du projet et de la

nature du produit
Et de la multiplication des exigences satisfaire : produit et projet, Comment matriser la complexit logicielle et rpondre aux
techniques et non techniques, fonctionnelles et non fonctionnelles exigences ?
Complexit temporelle (performance, contraintes temps-rel, dure de Comment grer les exigences ?
dveloppement)
Complexit spatiale (nombre de composants, nombre de parties
Quelle(s) mthode(s) pour la conception architecturale ?
prenantes, distribution gographique, interactions) Quelle place pour la documentation ?
Complexit conomique et technique (contexte)
Matriser (rduire) les cots

51 52