Produit
|
Objet
|
Personnalisation (facultatif, recommandé)
|
Modèle d'analyse (Classe d'analyse)
|
Un modèle d'analyse est utile pour mieux comprendre les requêtes avant de prendre des décisions
relatives à la conception. Dans les systèmes complexes, il peut être maintenu pour fournir une vue
d'ensemble conceptuelle du système.
|
Facultatif.
Dans beaucoup de projets, un modèle de conception initial est utilisé à la place du modèle
d'analyse.
Dans les projets qui créent effectivement un modèle d'analyse, il s'agit généralement d'un artefact
temporaire qui va évoluer en modèle de conception.
|
Carte de navigation, Prototype d'interface utilisateur
|
Les projets ayant une interface utilisateur large et complexe devraient considérer l'utilisation d'une
conception d'interface utilisateur.
|
Facultatif.
Une conception d'interface utilisateur plus informelle peut suffire aux efforts fournis sur des
projets plus petits.
|
Modèle de conception
|
La plupart des systèmes, y compris les petits systèmes, devraient être conçus avant d'être implémentés
afin d'éviter de devoir retravailler dessus à cause d'erreurs de conception car cela est coûteux. Les
modèles visuels permettent de communiquer la conception facilement. Les outils utilisés pour la
rétro-conception et la génération de code peuvent assurer une cohérence avec le modèle d'implémentation
et éviter trop d'efforts.
|
Recommandé pour la plupart des projets.
Sur les projets plus petits, l'utilisation d'outils automatisés n'est pas critique, elle peut avoir
une productivité à long terme.
|
Classe de conception ; Package de conception
|
Les classes et les packages représentent une partie élémentaire de toute conception orientée objet. La
conception orientée objet est l'approche de conception standard utilisée pour la plupart des projets.
|
Recommandé pour la plupart des projets.
Les principales questions relatives à la personnalisation concernent les stéréotypes utiliser (vous
pouvez trouver cela dans les Instructions relatives à la conception).
|
Réalisation de cas d'utilisation
|
Fournit un pont à partir des cas d'utilisation vers la conception.
|
Recommandé pour la plupart des projets.
|
Interface
|
Les interfaces sont généralement utilisées pour définir le comportement indépendamment des composants à
forte granularité qui effectuent ce comportement.
|
Recommandé pour la plupart des projets.
La conception basée sur les composants devient une approche de conception standard.
|
Sous-système de conception
|
Les sous-systèmes de conception sont utilisés pour encapsuler le comportement à l'intérieur d'un
composant qui fournit les interfaces. Ils sont utilisés pour encapsuler les interactions de classes
et/ou d'autres sous-systèmes.
|
Recommandé pour la plupart des projets.
Les sous-systèmes sont souvent très utiles pour élever le niveau d'abstraction de la conception.
Ils facilitent la compréhension des systèmes.
|
Evénement
|
Peut être utile pour les systèmes qui répondent à beaucoup d'événements externes.
|
Recommandé pour les systèmes en temps réel.
|
Protocole
|
Requis pour les systèmes en temps réel.
|
Recommandé pour les systèmes en temps réel.
|
Signal
|
Peut être utile pour les systèmes qui requièrent un accès concurrent et sont déclenchés par un
événement.
Requis pour les systèmes en temps réel.
|
Peut être utile pour les systèmes qui requièrent un accès concurrent et sont déclenchés par un
événement.
Recommandé pour les systèmes en temps réel.
|
Capsule
|
Utilisé pour les systèmes en temps réel mais peut s'avérer utile pour la modélisation et la conception
de tout système ayant un degré d'accès concurrent très élevé.
|
Recommandé pour les systèmes en temps réel.
|
Modèle de données
|
Utilisé pour décrire la structure logique et éventuellement physique de l'information persistante.
|
Recommandé pour les projets utilisant une base de données.
|
Modèle de déploiement
|
Montre la configuration des noeuds de traitement en cours d'exécution, les liens de communication entre
eux et les instances de composants et les objets qu'ils contiennent.
|
Facultatif.
Beaucoup de systèmes ont de multiples noeuds de traitement et doivent donc traiter le modèle de
déploiement. Vous pouvez cependant trouver une section s'y rapportant dans le document
d'architecture logicielle. Il n'a pas besoin d'exister en tant qu'artefact identifié séparément.
|
Bien-fondé de la conception d'architecture
|
Utilisé pour déterminer s'il existe une solution qui satisfasse les requêtes importantes du point du
vue de l'architecture.
|
Recommandé pour la plupart des projets.
Beaucoup de projets vont utiliser un bien-fondé de la conception d'architecture pour déterminer la
faisabilité des requêtes. Cela peut se faire sous différentes formes :
-
une liste des technologies connues qui semblent appropriées à la solution
-
un schéma d'un modèle conceptuel d'une solution
-
une simulation de solution
-
un prototype exécutable
|
Architecture de référence
|
Les architectures de référence accélèrent le développement et réduisent les risques en réutilisant les
solutions qui ont fait leurs preuves.
|
Recommandé pour la plupart des projets.
Si du matériel approprié d'architecture de référence existe, cela peut considérablement accélérer
le développement et réduire les risques.
|
Document d'architecture logicielle (SAD)
|
Le document d'architecture logicielle fournit une présentation complète de l'architecture du système.
Cette présentation aide à comprendre le système et à répertorier les décisions clés relatives à
l'architecture.
|
Recommandé pour la plupart des projets.
Une présentation de niveau élevé de l'architecture logicielle sert pour tous les systèmes sauf les
plus petits. Les systèmes complexes requièrent généralement un niveau de détail plus élevé et
davantage de vues que les projets plus petits.
|
Prototype d'interface utilisateur
|
Utilisé pour exposer et tester la fonctionnalité et la convivialité avant que le développement réel ne
démarre. C'est un moyen très efficace de valider la conception avant que trop de temps ne soit perdu.
|
Recommandé pour la plupart des projets.
|