En général, dans la plupart des domaines de développement, il est généralement mauvais de mélanger des niveaux d'abstraction. À bien des égards, OO est un moyen d'organiser les niveaux d'abstraction tandis que l'encapsulation est une façon de l'imposer.
À mon avis, cela s'applique également au design. Donc je pense que vous devriez créer vos diagrammes au niveau d'abstraction approprié. Si vous n'êtes pas sûr du matériel utilisé et du logiciel SW utilisé, vous devrez peut-être utiliser un diagramme de déploiement distinct. Si la mise en page du logiciel est une évidence, vous pouvez commencer à dessiner des idées en utilisant des diagrammes de classes ou des diagrammes de séquence.
Je pense qu'il est approprié d'appliquer la règle 7 + -2 - en ce sens que les développeurs ne peuvent garder avec succès que 7 (+ -2) concepts dans leur esprit en même temps - avec un diagramme englobant tous les niveaux d'abstraction briserait cette règle !!! Cela dit, ne perdez pas de temps à créer un diagramme si cela peut être bénéfique pour l'équipe et faire avancer le projet. Si la meilleure façon de procéder est comprise par l'équipe, alors le fait de schématiser cette compréhension ne va vraiment pas ajouter de valeur. Cependant, si vous n'êtes pas sûr de l'étape suivante, la création de diagrammes peut être un moyen utile de communiquer des idées entre l'équipe - en ajoutant seulement suffisamment de détails pour que l'idée soit claire. Mais n'ayez pas peur de jeter des diagrammes aussi!
À mon avis, le livre suivant donne la meilleure démonstration du niveau et de détail de schématisation qui est utile pour un projet:
http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258
Dans mon livre, l'utilisation du mot « méthode » est un symptôme précoce qui précède la paralysie d'analyse aiguë;) –
Qui est le public? –
Visual Studio 2010 Architect dispose d'une telle capacité de filtrage granulaire. –