Introduction to Software Architecture

Architecture de Software Introduction Software Factory 8 F évrier 2005

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

Agenda
Introduction
L’Architecture par la Pratique
Conclusion

Agenda
Introduction
Evolution Historique
Définition
Conclusion

Introduction
Une question simple:
Thales est-elle une entreprise « high-tech », oui ou non?
Pourquoi?

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 »???

L'architecture tout court Voici ce que l’on entend par architecture dans le monde réel:

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 (s elon 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 Généralement pas… mais… Non architecturelles Niveau Local Centre d'intérêt Non architecturelles (Attention!) Niveau Global Grand impact Peu d’impact

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.

Principes de l’Architecture
Une architecture doit être:
« minimaliste » (Contradiction?)
« de qualit é »
« correcte »
« réussie »
« Small is beautiful »

Exemples d’Architectures
Client Serveur
Distributed Computing
Peer-to-peer
Tableau Noir (Blackboard)
Syst èmes Monolithiques
3-Tier Model
Service-Oriented Architecture (SOA)

Agenda
Introduction
Définition
Historique
Conclusion

Agenda
Introduction
Etablissement
Communication
Maintenance
Conclusion

Sept Étapes
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.
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
Les composants font ce qu’ils doivent faire sans faire attention a qui leur parle
Rend possible la réutilisation
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
L’organisation logique de l’architecture doit se voir dans
L’organisation du code
L’organisation de l'équipe qui implémente le design
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…
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 »

Vues Architecturales Architecture d'Exécution (Diagrammes de Collaboration, sch émas de processus ) Architecture Logique (Spécifications de Composants et Interfaces) Architecture Conceptuelle (Diagramme d’Architecture, CRC Cards)

Vues Architecturales Diagramme avec Composants Actifs Diagrammes de Collaboration avec Processus Architecture d’Ex é cution Diagramme avec Interfaces + Specs d’Interfaces Diagramme de Collaborations Architecture Logique Diagramme d’Architecture + CRC Cards Trac é de Collaborations Informels Architecture Conceptuelle Vue Structurelle Vue des Comportements

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 »

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

IEEE Standard 1471

Agenda
Introduction
Etablissement
Communication
Maintenance
Conclusion

Agenda
Introduction
Conclusion
Glossaire
Links

Glossaire
Frameworks
Components
Design Patterns
Antipatterns
« Creeping Featurism »
« DLL Hell »
« Reinventing the Wheel »
« Not-Invented-Here (NIH) Syndrome »
« Spaghetti Code »
Data Models
Ontologies

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

Questions?

Prochain Cours
Comparaison J2EE / .NET
Date non pr évue!
Historique
Avantages / D ésavantages
Evolution
N’h ésitez pas à nous donner vos idées!

Merci! A bient ôt !

Introduction to Software Architecture

by Adrian Kosmaczewski on Sep 10, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 31

Statistics

Introduction to Software Architecture — Presentation Transcript

http://kosmaczewski.net	25
http://www.slideshare.net	6