Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introduction à l'Architecture de Software

Introduction à l'Architecture de Software

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

Adrian Kosmaczewski
PRO

February 08, 2005
Tweet

More Decks by Adrian Kosmaczewski

Other Decks in Technology

Transcript

  1. Architecture de Software
    Introduction
    Software Factory
    8 Février 2005

    View Slide

  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

    View Slide

  3. Agenda
    • Introduction
    • L’Architecture par la Pratique
    • Conclusion

    View Slide

  4. Agenda
    • Introduction
    – Evolution Historique
    – Définition
    • L’Architecture par la Pratique
    • Conclusion

    View Slide

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

    View Slide

  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

    View Slide

  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!

    View Slide

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

    View Slide

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

    View Slide

  10. View Slide

  11. View Slide

  12. View Slide

  13. View Slide

  14. View Slide

  15. View Slide

  16. View Slide

  17. View Slide

  18. View Slide

  19. View Slide

  20. View Slide

  21. View Slide

  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

    View Slide

  23. View Slide

  24. View Slide

  25. View Slide

  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

    View Slide

  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

    View Slide

  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 »

    View Slide

  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é!

    View Slide

  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

    View Slide

  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)

    View Slide

  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 »

    View Slide

  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…

    View Slide

  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é

    View Slide

  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)

    View Slide

  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?

    View Slide

  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.

    View Slide

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

    View Slide

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

    View Slide

  40. Agenda
    • Introduction
    – Définition
    – Historique
    • L’Architecture par la Pratique
    • Conclusion

    View Slide

  41. Agenda
    • Introduction
    • L’Architecture par la Pratique
    – Etablissement
    – Communication
    – Maintenance
    • Conclusion

    View Slide

  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 »

    View Slide

  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 »

    View Slide

  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

    View Slide

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

    View Slide

  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 »

    View Slide

  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)

    View Slide

  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

    View Slide

  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 »

    View Slide

  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

    View Slide

  51. IEEE Standard 1471

    View Slide

  52. Agenda
    • Introduction
    • L’Architecture par la Pratique
    – Etablissement
    – Communication
    – Maintenance
    • Conclusion

    View Slide

  53. Agenda
    • Introduction
    • L’Architecture par la Pratique
    • Conclusion
    – Glossaire
    – Links

    View Slide

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

    View Slide

  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

    View Slide

  56. Questions?

    View Slide

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

    View Slide

  58. Merci!
    A bientôt!

    View Slide