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
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
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!
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 »???
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
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
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
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 »
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é!
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
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)
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 »
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…
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é
« 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)
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?
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.
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 »
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 »
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
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 ».
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 »
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
Prochain Cours • Comparaison J2EE / .NET – Date non prévue! – Historique – Avantages / Désavantages – Evolution • N’hésitez pas à nous donner vos idées!
akosma
nttcom
miura55
orgachem
ybrliiu
takahashikazutaro
hayatokudou
nasa9084
tsubakimoto_s
blue_goheimochi
toshiaizawa
uzulla
aiji42
philnash
thekraken
jonyablonski
geeforr
dougneiner
ammeep
myddelton
paulrobertlloyd
caitiem20
colly
chriscoyier
jrom