Introduction à l'Architecture de Software

Présentation donné à Thalès Genève, Février 2005

Transcript

1. Architecture de Software Introduction Software Factory 8 Février 2005
2. Objectifs • Connaître raison, contexte et enjeux de l’Architecture de Software • Savoir décrire une architecture • Apprendre une approche pour l'établissement d’une architecture • Arriver à communiquer cette architecture de manière satisfaisante
3. Agenda • Introduction • L’Architecture par la Pratique • Conclusion
4. Agenda • Introduction – Evolution Historique – Définition • L’Architecture par la Pratique • Conclusion
5. Introduction • Une question simple: – Thales est-elle une entreprise « high-tech », oui ou non? – Pourquoi?
6. Observations • Augmentation de la complexité des problèmes de nos clients • Diminution des ressources – Temps de réalisation – Temps de résolution de problèmes – Budgets • Nouvelles Technologies – Défis – Risques
7. Une Approche Possible • Faire rentrer le concept d’Architecture dans le processus de création de software – Ce paradigme doit s'intégrer naturellement, de manière appropriée • « No Silver Bullet » disait Frederick P. Brooks en 1974! – Pas de solution miracle!
8. Opportunité • Tout développeur est, au fond, un architecte – Donc chez Thales on en a un paquet! … mais qu’est-ce que c’est qu’un « architecte de software »???
9. L'architecture tout court Voici ce que l’on entend par architecture dans le monde réel:
22. Evolution Historique • On parle depuis longtemps d’architecture dans le monde du hardware: – Architecture « Von Neumann » • Séparation de la CPU du stockage des données – Harvard Architecture • « Inverse » de l’architecture Von Neumann
26. Software Architecture • Concept introduit vers 1960 – Edsger Dijkstra – Premiers grands projets (+1000 développeurs) – Langages de deuxième génération – Début de la « Software Crisis » (OS/360) • Gain de popularité dans les années 90 – Rational Corporation (UML) – NeXT, Sun, Microsoft (Frameworks) • Universités – Carnegie Mellon University – University of California, Irvine
27. Définition (selon Wikipedia) • « Software architecture is a coherent set of abstract patterns guiding the design of each aspect of a larger software system » • http://en.wikipedia.org/wiki/Software_architecture
28. Définition (selon IEEE) • « The fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution »
29. Définition (selon moi) • Architecture: vision globale d’un système d’information, non seulement en termes de composants et de comportements, mais aussi en termes de son interaction avec l’environnement humain, économique, technologique et historique. • Contrôle de la Complexité!
30. Contexte • L'architecture d’un système, donc, doit pouvoir gérer deux genres de complexité: – La Complexité Intellectuelle • Taille • Dépendances • Technologies – La Complexité Administrative • Equipes • Processus • Clients
31. Défis • L'architecture pose des questions nouvelles: – Comment décomposer un problème pour trouver la meilleure solution? – Quelle est l’infrastructure déjà en place? – Toutes les pièces du puzzle peuvent travailler en harmonie? • Ces trois problèmes doivent être contemplés avec deux optiques complémentaires: – Interne (le système lui même) – Externe (son environnement)
32. Décisions Architecturales • Toute décision stratégique de haut impact prise a niveau du système – Permet de distinguer les décisions de design et implémentation (locales) des architecturales (globales) – Les décisions architecturales ont souvent comme conséquence des « trade-offs »
33. Classification des Décisions Peu d’impact Grand impact Niveau Global Non architecturelles (Attention!) Centre d'intérêt Niveau Local Non architecturelles Généralement pas… mais…
34. Types de Décisions • Priorités • Décomposition et Composition du Système • Propriétés du système – Spécialement les « cross-cutting concerns » • Contexte • Intégrité
35. « Cross-Cutting » • C’est un terme qui apparaît souvent lors de l'établissement d’Architectures • Il s’agit des propriétés globales d’un système dont l’impact est difficile a évaluer en premier abord: – Sécurité – Logging – Traitement d’erreurs – Parameter Validation – Database connections / External Resources • Programmation Oriente Aspects! (AOP)
36. Attention! • Une Architecture diminue fortement la capacité de mouvement des designers et implémentateurs des sous-systèmes! • Comment justifier cela? N’y a-t-il pas là un frein a la créativité? N’est-ce pas un danger pour la réussite du projet?
37. Principes de l’Architecture • La seule raison justifiable pour restreindre la liberté de mouvement des designers et des implémentateurs est la résolution effective de problèmes pratiques qui ne pourraient pas être résolus autrement. • La vision systémique permet cela, mais ne peut résoudre tous les problèmes.
38. Principes de l’Architecture • Une architecture doit être: – « minimaliste » (Contradiction?) – « de qualité » – « correcte » – « réussie » • « Small is beautiful »
39. Exemples d’Architectures • Client Serveur • Distributed Computing • Peer-to-peer • Tableau Noir (Blackboard) • Systèmes Monolithiques • 3-Tier Model • Service-Oriented Architecture (SOA)
40. Agenda • Introduction – Définition – Historique • L’Architecture par la Pratique • Conclusion
41. Agenda • Introduction • L’Architecture par la Pratique – Etablissement – Communication – Maintenance • Conclusion
42. Sept Étapes 1. L'architecture d’une solution doit être un travail d'équipe – Mais avec un seul architecte responsable qui donne la direction et l’orientation à l'équipe. 2. Un bon design est simplement un « framework » qui cache les détails les plus complexes – Possibilité de réutilisation! – Design « top-down » and code « outside-in »
43. Sept Étapes 3. Les composants font ce qu’ils doivent faire sans faire attention a qui leur parle – Rend possible la réutilisation 4. Faire attention aux aspects statiques et dynamiques d’un problème – Un système en mouvement n’est pas identique a un système en « stand by »
44. Sept Étapes 5. L’organisation logique de l’architecture doit se voir dans – L’organisation du code – L’organisation de l'équipe qui implémente le design 6. Ne pas se soucier de problèmes d’efficience lors de l'établissement d’une architecture – A moins que ce soit une condition – Privilégier l’entretien du code et la rapidité d'implémentation
45. Sept Étapes • Last but not least… 7. Maintenir l’architecture a jour! – Il est impensable que l’architecture d’une application ne puisse changer! – Il faut maintenir les documents actualises – Le plus de design fait « upstream » veut dire une moindre possibilité de changements intempestifs lors du coding, « downstream ».
46. Communication • Une Architecture ne sert a rien si elle n’est pas connue! • Buts: – Garder une trace de la pensée de l’Architecte • Documents • Diagrammes – Communiquer convenablement l’information • Il faut savoir quoi dire a chacun des interlocuteurs! • Risque de « Shelfware »
47. Vues Architecturales Architecture Conceptuelle (Diagramme d’Architecture, CRC Cards) Architecture Logique (Spécifications de Composants et Interfaces) Architecture d'Exécution (Diagrammes de Collaboration, schémas de processus)
48. Vues Architecturales Vue des Comportements Vue Structurelle Architecture Conceptuelle Tracé de Collaborations Informels Diagramme d’Architecture + CRC Cards Architecture Logique Diagramme de Collaborations Diagramme avec Interfaces + Specs d’Interfaces Architecture d’Exécution Diagrammes de Collaboration avec Processus Diagramme avec Composants Actifs
49. Documents • Minimum Nécessaire: – Référence Spécifications • Views • Environment • Requirements – Management Overview • Vision • Business Strategy – Component Descriptions • Logical Architecture Diagram • Component & Interface Spécifications • Eventuellement Standards et « Guidelines »
50. IEEE Standard 1471 • http://standards.ieee.org • Offre un schéma conceptuel pour l’établissement d’une Architecture • Définitions – Séparation entre l’Architecture et sa représentation Graphique – « Stakeholder » – « Viewpoints » • C’est seulement une « Recommended Practice », non pas une méthode
51. IEEE Standard 1471
52. Agenda • Introduction • L’Architecture par la Pratique – Etablissement – Communication – Maintenance • Conclusion
53. Agenda • Introduction • L’Architecture par la Pratique • Conclusion – Glossaire – Links
54. Glossaire • Frameworks • Components • Design Patterns • Antipatterns – « Creeping Featurism » – « DLL Hell » – « Reinventing the Wheel » – « Not-Invented-Here (NIH) Syndrome » – « Spaghetti Code » • Data Models • Ontologies
55. Links • IEEE Std 1471-2000 http://standards.ieee.org • .NET Architecture Center http://msdn.microsoft.com/architecture • Bredemeyer Consulting http://www.bredemeyer.com • Architecture Book Online http://www.softwarearchitect.biz/arch.htm
56. Questions?
57. Prochain Cours • Comparaison J2EE / .NET – Date non prévue! – Historique – Avantages / Désavantages – Evolution • N’hésitez pas à nous donner vos idées!
58. Merci! A bientôt!