I. Introduction Les systèmes deviennent plus complexes Exemple

Transcription

04/10/2008
1
Les systèmes deviennent plus complexes
2
• Volume croissant
– Des données
– Du code
• Évolutivité croissante
I. Introduction
– De la partie métier (mondialisation, concentration, restructuration, …)
– De la partie plate-forme d'exécution
• Hétérogénéité croissante
a) Pourquoi une « encore » nouvelle approche du
développement logiciel
–
–
–
–
Etat des lieux
Des langages et des paradigmes
Des supports de données et des protocoles d'accès
Des systèmes et des plates-formes
Des technologies
• Le rythme d'arrivée des nouvelles technos s'accélère
• Ce rythme ne se ralentira pas
• Les vieilles technos ne meurent pas, elles se cachent
Ingé
Ingénierie des Modè
Modèles Logiciels
Exemple typique
•
•
CoursBlay-Fornarino
#3 Bezivin– 2008
Mireille
EPU département SI, Master STIC
Mireille Blay-Fornarino – 2008
3
La croissance de la complexité des spécifications
Un jeune ingénieur en sortie de Bac+5 et ayant des connaissances de base en Java, XML et
UML se voit invité, lors de son arrivée en entreprise et avant de commencer son travail, à
lire le lundi le rapport public J2EE v1.4 de 228 pages
– Dans les six premières pages de ce rapport il est fait référence à : EJB, JSP, JMS,
JMX, JCA, JAAS, JAXP, JDBC, JNDI.
– Cette nouvelle version de J2EE est la version Web services et on suppose donc connus
les concepts SOAP, SAAJ, JAX-RPC et JAXR
– Chacun des acronymes cités correspond à une spécification
– La spécification de EJB 2.1 correspond à un document pdf de 640 pages qui sera lue le
mardi
– Le mercredi sera consacré à la lecture du document Servlet 2.4 PFD specification de
307 pages
– Le jeudi il s'attaque à la lecture du document JSP 2.0 PFD specification de 374 pages
– Et ainsi de suite …
Au bout d'un mois de lectures, notre ingénieur est enfin prêt à commencer le travail
productif …
d'après Interactive-Objects
D'après "Is complexity hurting Java?" de Jason Weiss,
dans Java Developer's Journal, Vol. 7, Issue 10, Octobre 2002.
Ingé
Modèles Logiciels
Cours
Bezivin
Mireille#3Blay-Fornarino
– 2008
Ingé
Modèles Logiciels
Et aussi : http://www.theserverside.com/home/thread.jsp?thread_id=11273
Constats du développement logiciel
•
4
CoursBlay-Fornarino
#3 Bezivin– 2008
Mireille
5
Génie du logiciel
•
Spécifications mouvantes
– Evolution des besoins, de la législation, des groupements de sociétés, des technologies, …)
•
Variations des environnements
•
Besoin important d’Intégration des applications existantes
•
Nécessité d’une forte expertise des domaines métiers
•
Intégration de propriétés non-fonctionnelles complexes (sécurité, persistance, tracabilité,
…)
•
Multiplicité des points de vues sur le logiciels
– Langues, supports, connectiques, embarquées, …
•
– Transports, médecine, finances, ….
6
Pris dans un sens large, le génie logiciel englobe en effet les «règles de l'art» de l'ingénierie de la réalisation des
systèmes manipulant de l'information, qu'on appelle encore systèmes à logiciel prépondérant. Pour les systèmes de
plus en plus complexes qu'on cherche à construire, il s'agit de trouver un compromis entre un système
parfaitement bien conçu (qui pourrait demander un temps infini pour être construit) et un système trop vite fait
(qu'il serait difficile de mettre au point et de maintenir), en conciliant trois forces largement antagonistes : les
délais, les coûts, et la qualité. Il ne s'agit donc pas de produire le système parfait, mais bien de produire, en
respectant un coût et des délais raisonnables, un système suffisamment bon compte tenu de son contexte
d’utilisation.
Le principal problème du génie logiciel ne se pose plus en termes de « donnez-moi une spécification immuable et
je produis une implantation de qualité » mais plutôt en « comment réaliser une implantation de qualité avec des
spécifications continuellement mouvantes ». De plus, il arrive de plus en plus fréquemment de ne plus avoir à
produire un produit donné à un moment donné, mais simultanément toute une gamme (ou famille) de produits
pour prendre en compte des variations de fonctionnalités ou d'environnements [1]. À cet égard on peut citer des
constructeurs emblématiques tels que Microsoft, qui adaptent certains de leurs logiciels à des dizaines de platesformes différentes ainsi qu'à des centaines d'environnements culturels, ou encore l'éditeur de jeux vidéos Gameloft
qui a développé rien moins que 700 versions du jeu Tom Clancy's Splinter Cell Chaos Theory, conçu par Ubisoft,
afin de l'adapter à quelque 180 modèles de téléphones portables, dans différentes langues et dans 65 pays (des
acteurs du secteur expliquent que chaque nouvelle version peut coûter entre 1.000 et 2.000 dollars). La maîtrise de
cette double variabilité spatiale et temporelle est donc devenue un des enjeux majeurs de l'industrie du logiciel.
•
Quel qu'il soit, un processus de développement logiciel englobe un certain nombre d'activités (comme l'expression
des besoins, l'analyse, la conception, l'implantation ou encore la validation) qui chacune produisent un ou
plusieurs artefacts tels que documentation, diagrammes, codes sources, fichiers de configuration, fiches de tests,
rapports de qualification, etc. Ces artefacts donnent de multiples points de vue sur le logiciel en cours de
développement et, en pratique, sont souvent indépendants les uns des autres. Un problème ici, est d’être capable
d’assurer une cohérence entre ces vues, ou au minimum une tracabilité entre les éléments des différents artefacts.
•
Extrait du livre [IDM06], chapitre Génie logiciel et IDM.
– Expression des besoins, analyse, conception, implantation, validation, évolution, maintenance,
clients, …
¾ La complexité a atteint un tel niveau qu'il est hors de portée d'un seul individu
d'avoir une vision globale sur un système en évolution
1
04/10/2008
7
8
Interopérabilité et intégration ?
•
•

Langages de programmation
–
~3 million COBOL programmers
–
~1.6 million VB programmers
–
~1.1 million C/C++ programmers
Supports de développements
Operating systems
–
Unix, MVS, VMS, MacOS, Windows, Windows(3.1->XP), PalmOS…
–
Embedded devices
Les objets
Les intergiciels
Les « design Patterns »
La programmation par aspects
Les intégrateurs
Networks
–
Ethernet, ATM, IP, SS7, Firewire,
–
Bluetooth, 802.11b, HomeRF
9
Once upon a time…
software development looked simple
Abstraction… simplification… généralisation….
10
(d’après JM Jezequel)
• From the object as the only one concept
1980
1990
2000
– As e.g. in Smalltalk
Collaborations
• To a multitude of concepts
Middleware (middle war)
It's difficult -- in fact, next to impossible – for a large enterprise
to standardize on a single middleware platform. (R. Soley)
Soley)
Design patterns
HTTP
HTML
COM+
DCOM
ReceiverI
Components
Sun’s
Java &
EJB
Microsoft
DataI
Required port
Da
Proprietary
Middleware
(eg. automotive)
XML
SOAP
Aspects
DecoderI
C# & .Net
<<Component>>
Decoder
CORBA
IIOP
Procédures
Modules
…..
+
Services
Orchestration
Chorégraphies
Contrats
Business process
…
Provided Port
+ until the next ultimate middleware
platform (~2005)
"Because of the wonderful unifying properties
of the object paradigm, the transition from
procedural technology to object technology will
bring huge conceptual simplification to the
software engineering field. Since everything
will be considered as an object, we shall
observe a dramatic reduction in the number of
necessary concepts."
All together, circa 1980
Object technology failed to
achieve its promises
of simplification.
12
[JB03]
•
The object-oriented approach does not adequately address the computing
requirements of the future.
•
Object-oriented languages have lost the simplicity—some would say purity—that
made them special and which were the source of their expressive and development
power.
•
Powerful concepts like encapsulation were supposed to save people from
themselves while developing software, but encapsulation fails for global properties
or when software evolution and wholesale changes are needed. …
•
Objects promised reuse, and we have not seen much success. …
•
People enthused by objects hogged the road, would not get out of the way, would
not allow alternatives to be explored—not through malice but through exuberance—
and now resources that could be used to move ahead are drying up. But sometimes
this exuberance was out-and-out lying to push others out of the way.
http://www.dreamsongs.com/ObjectsHaveFailedNarrative.html
[JB03]
D’aprèsEPU
http://lifc.univ-fcomte.fr/~philippe/composants/JC2001.htm
département SI, Master STIC
Objects have failed (Richard Gabriel, OOPSLA
2002)
11
Les objets : promesses…
Objets,
Classes,
Méthodes
...
Beans,
Components,
Containers,
Packages,
Interfaces,
Layers, Tiers,
Use cases,
Patterns,
Frameworks
...
2
04/10/2008
13
Vers l’interopérabilité
•Il n’y aura pas de consensus sur
• Intergiciels… prolifération
–
–
–
–
–
–
-les plates-formes “hardware”
-Les « operating systems »
-Les protocoles network
-Les langages de programmation
intergiciels (courtiers, « Middleware »)
• Comment préserver l’investissement logiciel quand les
infrastructures changent?
Couche logicielle qui masque l’hétérogénéité
Intégrer ce que vous avez construit avec :
- ce que vous construisez
- ce que vous construirez
Placée entre l’OS et les composants de l’application
…. OMG & CORBA
CORBA®: Vendor, OS & language independent middleware
COM/DCOM/MTS
Java/EJB
XML/SOAP
C#/.Net
Aucun ne prévaut sur les autres… “What will be Next Best Thing?”
Le problème demeure……..
Une solution : Se mettre d’accord à un niveau plus haut: les
14
Intergiciels (Courtier, Middleware)
15
Tir sur cible mobile
16
Évolutions mineures
Business Model 1
BM 2
AOP/AOSD :
un problème
bien identifié
…
BM 3
Product line or application development
Specification
Platform 1
Implementation
and Tests
Pf 2
Pf 3
Usage and maintenance
Évolutions majeures
Pf 4
Pf 5
Pf 6
Pf 7
Pf 8
Pf 9
La séparation
Des
Préoccupations
Pascal; C; ADA; Linux; Smalltalk; C++; Com/DCOM; Apple OS; PowerBuilder; CORBA; Java; EJB; DotNet; C#;
XML; SOAP; Web services; Spring, etc.
Le changement de plate-forme était jusqu'à présent un événement exceptionnel;
Il devient de plus en plus une opération de routine.
Cette opération doit être prise en compte de façon explicite dans le cycle
de développement du logiciel.
AOP/AOSD : un problème bien identifié …
•
We have found many programming problems for which
neither procedural nor object-oriented programming
techniques are sufficient to clearly capture some of the
important design decisions the program must implement.
This forces the implementation of those design decisions to
be scattered through-out the code, resulting in "tangled"
code that is excessively difficult to develop and maintain.
We present an analysis of why certain design decisions
have been so difficult to clearly capture in actual code. We
call the properties these decisions address aspects, and
show that the reason they have been hard to capture is that
they cross-cut the system's basic functionality. We present
the basis for a new programming technique, called aspectoriented programming, that makes it possible to clearly
express programs involving such aspects, including
appropriate isolation, composition and re-use of the aspect
code.
17
18
Les aspects : de la transformation de code
AOP: le code comme référentiel unique.
Optimisation
directives
Debugging
directives
Synchronization
from Gregor Kiczales, John Lamping, Anurag Mendhekar
Chris Maeda, Cristina Videira Lopes,
Jean-Marc Loingtier, John Irwin.
In proceedings of the European Conference
Algorithmique
preconditions
postconditions
Exceptions
Code
d'organization
(#include, etc.)
on Object-Oriented Programming (ECOOP),
Finland. Springer-Verlag LNCS 1241. June 1997.
Code
exécutable
Aspect Oriented Programming / Aspect-Oriented Software Development
Ingé
Modèles Logiciels
CoursBlay-Fornarino
#3 Bezivin– 2008
Mireille
Ingé
Modèles Logiciels
CoursBlay-Fornarino
#3 Bezivin– 2008
Mireille
3
04/10/2008
Intégration des codes : le syndrome du wrapper fou
19
En bref, les technos se suivent et se complètent
• Chaque technologie a un apport historique qui
persiste.
• Les principes de la programmation structurée,
issus de la technologie procédurale n'ont pas été
perdus ni oubliés lors du passage à la technologie
des objets dans les années 1980.
• Les contributions des différentes technologies
(procédures, objets, composants, services,
modèles, etc.) ne sont jamais perdues mais
laissent des traces positives même longtemps
après leur période d'impact maximum.
• "Tchernobilization du logiciel" consiste à
recouvrir l'existant de chapes technologiques
successives.
Tchernobyl
20
• Avantages et inconvénients de l’utilisation des
emballeurs d’objets (wrappers) pour
applications existantes.
TdP
Un sarcophage de béton recouvre
désormais le réacteur #4
de la centrale de Tchernobyl.
There is no
silver bullet !
TdO
TdC
TdS
IdM
Ingé
Modèles Logiciels
CoursBlay-Fornarino
#3 Bezivin– 2008
Mireille
•Il ne faut pas jeter le bébé avec l'eau du
bain : la contribution de la technologie
des objets entre 1980 et 2000 aura été
essentielle à l'évolution de
l'informatique.
Mais les défis des nouvelles applications évoluent
Mireille Blay-Fornarino
– 2008
Séminaire X-Aristote
21
du 12 décembre 2002
La nouvelle crise du logiciel
• Dirigées par le métier versus dirigées par les
technologies
22
• Première crise : 1965
– Solutions? (NATO Summer School 1967):
• "Software engineering"
• "Structured programming"
• "Top-down approaches"
– Nécessite une connaissance approfondie du métier
– Complexité rend obligatoire des collaborations inter
disciplines et un développement dirigé par les experts du
domaine
– Enterprise Application Platforms (SAP, PeopleSoft…)
vs. Technology Platforms (J2EE, .NET, Unix,
Mainframes)
• Seconde crise : 2000
– Solutions? (OMG november 2000):
• La PPO ou la PPC ne constituent que des réponses très partielles à la
montée en complexité. Seules elles sont aujourd'hui insuffisantes.
• "MDA : Decouple neutral business models from variable platforms"
• "Transformations as assets"
[jb03] Extrait de « MDA™
MDA™ : From Hype to Hope,
and Reality
».
Mireille
Blay-Fornarino
– 2008
J
Constat – des projets qui échouent
http://www.irisa.fr/prive/jezequel/enseignement/IFSIC....2006.pdf
Bé i i
UML‘2003
23
Résultat
24
http://www.irisa.fr/prive/jezequel/enseignement/IFSIC....2006.pdf
4
04/10/2008
25
Offshore et MDA
26
http://www.uae.ma/dossiers/down/formations/unia+uae/4-CHAFIK_KHALID_UAE.pdf
Extrait de : http://www.orchestranetworks.com/fr/soa/pdf/ON-MDA-SOA-Offshore.pdf
5