En général un développement logiciel peut être représenté via différents étapes qui vont permettre la définition complète de ton logiciel.
Ces différentes étapes peuvent être listées comme suit :

La spécification ==> qu'est-ce que doit faire ton logiciel ? quel est son comportement par rapport aux différents acteurs qui ont des interfaces avec lui ? (acteur = autre logiciel, opérateur humain ...etc.).
Les spécifications décrivent exhaustivement le "Quoi" de ton logiciel .. dans les cas nominaux d'utilisation, mais aussi dans les cas dégradés. En considérant le logiciel comme une boîte noire ... on se fiche de savoir le "Comment", on ne s'intéresse vraiment qu' au "Quoi", en se focalisant sur les interfaces externes de ton logiciel.
En général, pour illustrer et complèter cette phase de spécification avec UML, tu retrouve des diagrammes de contexte, des diagrammes de séquences, des définitions et des scénarios de "Cas d'utilisation" ... Tous ces diagrammes sont générables depuis la "Use Case View" de Rose.

La Conception ==> Tu sais ce que doit faire ton logiciel, il faut maintenant décrire "Comment" il le fait ... Pour ce faire, il ne faut plus seulement le considérer comme une boîte noire mais il faut plonger dans les tripes de ton soft et expliquer : quels sont les différents objets applicatifs qui vont le constituer, et comment ces objets applicatifs vont collaborer entre eux pour réaliser le "Quoi" qui a été dééfini en phase de spécification ...
En général, les diagrammes de classe et de collaboration UML que tu retrouves dans la "Logical View" de Rose sont utilisés à cette étape. Tu peux également décrire des diagrammes de séquence UML un peu plus fins que ceux de la phase d espécification.

Le Codage ==> pas la peine de décrire j'imagine (^_^)
Tu peux effectivement utiliser les propriétés de Rose pour générer ton code applicatif à partir des objets (classes) que tu auras défini dans la "Logical View" ... et pour ce faire il te faudra utiliser la "Component View" de Rose ...

Le test ==> Là aussi UML peut intervenir, plus ou moins directement ... Lorsque tu as spécifié ton logiciel, et si tu l'as spécifié via des Use Cases, (Cas d'utilisation), tu en es arrivé à définir plusieurs scénarios (nominal, dégradé ...etc.) pour chacune des fonctions de ton logiciel ... et bien ces scénarios deviennent des candidats rêvés pour devenir des scénarios de test, qui vont prouver que tu as bien, in fine, un logiciel qui fait correctement ce qui lui était demandé au départ ...

Maintenant, tout est question d'adaptation .. tu as un processus complet d'utilisation d'UML, à toi de voir en fonction de ce à quoi tu veux arriver pour chaque étape, si tu utilise UML ou non.