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

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 full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size slide

  10. 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 full-size slide

  11. 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 full-size slide

  12. 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 full-size slide

  13. 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 full-size slide

  14. 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 full-size slide

  15. 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 full-size slide

  16. 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 full-size slide

  17. 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 full-size slide

  18. 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 full-size slide

  19. 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 full-size slide

  20. « 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 full-size slide

  21. 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 full-size slide

  22. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  27. 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 full-size slide

  28. 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 full-size slide

  29. 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 full-size slide

  30. 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 full-size slide

  31. 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 full-size slide

  32. 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 full-size slide

  33. 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 full-size slide

  34. 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 full-size slide

  35. 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 full-size slide

  36. IEEE Standard 1471

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  40. 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 full-size slide

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

    View full-size slide

  42. Merci!
    A bientôt!

    View full-size slide