C9
Architecture logicielle avec UML
Objectifs
|
- Un PC pour deux stagiaires
- Bonne connaissance du langage UML
- Tout ingénieur ou technicien en systèmes embarqués possédant les prérequis ci-dessus.
- Les prérequis sont vérifiés avant l'entrée en formation, sur la base des prérequis publiés sur cette fiche.
- Pendant la formation, les acquis sont évalués en continu : quiz de fin de séquence et observation directe du formateur.
- À l'issue de la formation, chaque participant reçoit une attestation de fin de formation.
Plan du cours
- Définitions de l'architecture
- Architecture système
- Architecture métier
- Architecture logicielle
- Architecture technique
- Architecture de ligne de produits
- Architecture d'entreprise
- Qu'est-ce que l'architecture logicielle
- Quel problème vise-t-elle
- Ce qui n'est pas de l'architecture logicielle
- Pourquoi avons-nous besoin d'architecture logicielle
- La norme ANSI/IEEE-1471-2000
- Architecture et descriptions architecturales
- Le cadre conceptuel de l'IEEE 1471
- Vues et points de vue
- Éléments et principes d'architecture
- Modules
- Composants et connecteurs
- Parties prenantes et préoccupations
- Styles d'architecture
- Langages de description d'architecture
- Vision architecturale du développement logiciel
- Architectures système et logicielle
- Architecture logicielle et cycles de développement
- Architecture logicielle et conception
- Définitions
- L'architecture n'est pas la conception
- Composants et relations
- Interfaces
- Modèles d'architecture
- Le processus de base de conception d'architecture
- Les grandes étapes
- Les préoccupations clés
- Ce qu'il faut faire et ne pas faire
- Les décisions d'architecture
- Portée
- Impact
- La qualité d'une architecture
- Bonnes et mauvaises architectures
- Avoir raison
- Réussir
- Faire vivre les architectures
- L'attitude de la direction
- L'attitude des développeurs
- Définir les exigences fonctionnelles
- Définir les exigences non fonctionnelles
- Identifier les composants
- Modéliser le comportement du système
- Créer et documenter les interfaces
- Allouer les composants
- Valider les descriptions d'architecture
- Structure à base de modules
- Décomposition
- Utilisation
- En couches
- Objet
- Structure composants et connecteurs
- Processus communicants
- Concurrence
- Données partagées
- Client-serveur
- Structure d'allocation
- Déploiement
- Implémentation
- Répartition du travail
- Les vues d'architecture
- Vues et parties prenantes
- Points de vue
- Le modèle 4+1 vues de Kruchten
- Vue logique
- Vue processus
- Vue développement
- Vue physique
- Vue cas d'utilisation
- Le modèle 4 vues de Siemens (S4V)
- Vues conceptuelle, module et code
- Vue d'exécution et architecture matérielle
- Le modèle 3 vues du Software Engineering Institure (SEI)
- Module
- Composants et connecteurs
- Allocation
- La justification de conception et la vue décision
- La nécessité de capturer la justification de conception
- La vue décision et les autres modèles de vues
- Patterns, modèles de référence et architectures de référence
- Patterns de base
- Event-driven
- Pipes and filters
- Architecture en couches
- Architecture trois tiers (MVC)
- Client-serveur
- Pair à pair
- Share-nothing
- Plugins
- Architecture orientée objet
- Classes et relations
- Composants et paquetages
- Interfaces et dépendances
- Les contraintes et compromis du réparti
- Client-serveur
- Absence d'état
- Cacheabilité spécifiée
- Interface et opérations uniformes
- Système en couches
- Ajout dynamique de code
- Les architectures orientées services
- Composants et services
- Domaines et cycles de vie
- Programmation par contrat
- Annuaires et courtiers
- Couplage lâche ou tardif
- L'exemple OSGi/Java
- Architecture orientée ressources : ReST (Representational Resource Transfer)
- Que sont les ressources
- Noms de ressources
- La notion de représentation de ressource
- Contraintes d'interface
- État de l'application
- Le Rational Unified Process (RUP)
- Artefacts, rôles, workflows et résultats
- Fondamentaux et bonnes pratiques
- Les quatre phases
- Pourquoi RUP n'a-t-il pas eu tant de succès ?
- L'Eclipse Process Framework et OpenUP
- OpenUP comme variante du Unified Process
- OpenUP comme processus agile
- EPF Composer comme outil de support d'OpenUP
- Le Two Tracks Unified Process (2TUP)
- Le cycle en Y
- La branche technique
- La branche fonctionnelle
- La branche de réalisation
- Le Visual Architecting Process (VAP)
- Le processus technique
- Le processus organisationnel
- Les principes directeurs
- Diriger, suivre ou s'effacer ?
- Leadership et management
- Diriger implique de suivre
- Pourquoi il faut savoir s'effacer
Plus d'information
Pour vous enregistrer ou pour toute information supplémentaire, contactez nous par email à l'adresse info@ac6-formation.com.
Les inscriptions aux sessions de formation sont acceptées jusqu'à une semaine avant le début de la formation. Pour une inscription plus tardive nous consulter
Vous pouvez aussi remplir et nous envoyer le bulletin d'inscription
Ce cours peut être dispensé dans notre centre de formation près de Paris ou dans vos locaux, en France ou dans le monde entier.
Les sessions inter-entreprises programmées sont ouvertes dès deux inscrits. Sous condition d'un dossier complet, les inscriptions sont acceptées jusqu'à une semaine avant le début de la formation.
Dernière mise à jour du plan de cours : 2 juillet 2026
L'inscription à nos formations est soumise à nos Conditions Générales de Vente
Sur le même sujet :
Yocto ou Buildroot : comment choisir pour votre projet Linux embarqué