Support de cours méthodologie des systèmes d’information UML, tutoriel & guide de travaux pratiques UML en pdf.

Le processus unifié est centré sur l’architecture

Dès le démarrage du processus, on aura une vue sur l’architecture à mettre en place.
L’architecture d’un système logiciel peut être décrite comme les différentes vues du système qui doit être construit. L’architecture logicielle équivaut aux aspects statiques et dynamiques les plus significatifs du système. L’architecture émerge des besoins de l’entreprise, tels qu’ils sont exprimés par les utilisateurs et autres intervenants et tels qu’ils sont reflétés par les cas d’utilisation.
Elle subit également l’influence d’autres facteurs :
– la plate-forme sur laquelle devra s’exécuter le système ;
– les briques de bases réutilisables disponibles pour le développement ;
– les considérations de déploiement, les systèmes existants et les besoins non fonctionnels (performance, fiabilité..)

Liens entre cas d’utilisation et architecture ?

Tout produit est à la fois forme et fonction. Les cas d’utilisation doivent une fois réalisés, trouver leur place dans l’architecture. L’architecture doit prévoir la réalisation de tous les cas d’utilisation. L’architecture et les cas d’utilisation doivent évoluer de façon concomitante.

Marche à suivre :

??L’architecte crée une ébauche grossière de l’architecture, en partant de l’aspect qui n’est pas propre aux cas d’utilisation (plate forme..). Bien que cette partie de l’architecture soit indépendante des cas d’utilisation. L’architecte doit avoir une compréhension globale de ceux ci avant d’en esquisser l’architecture.
??Il travaille ensuite, sur un sous ensemble des cas d’utilisations identifiés, ceux qui représentent les fonctions essentielles du système en cours de développement.
??L’architecture se dévoile peu à peu, au rythme de la spécification et de la maturation des cas d’utilisation, qui favorisent, à leur tour, le développement d’un nombre croissant de cas d’utilisation.
Ce processus se poursuit jusqu’à ce que l’architecture soit jugée stable.

Le processus unifié est itératif et incrémental

Le développement d’un produit logiciel destiné à la commercialisation est une vaste entreprise qui peut s’étendre sur plusieurs mois. On ne va pas tout développer d’un coup. On peut découper le travail en plusieurs parties qui sont autant de mini projets. Chacun d’entre eux représentant une itération qui donne lieu à un incrément.
Une itération désigne la succession des étapes de l’enchaînement d’activités, tandis qu’un incrément correspond à une avancée dans les différents stades de développement.
Le choix de ce qui doit être implémenté au cours d’une itération repose sur deux facteurs :
• Une itération prend en compte un certain nombre de cas d’utilisation qui ensemble, améliorent l’utilisabilité du produit à un certain stade de développement.
• L’itération traite en priorité les risques majeurs.
Un incrément constitue souvent un additif.
A chaque itération, les développeurs identifient et spécifient les cas d’utilisations pertinents, créent une conception en se laissant guider par l’architecture choisie, implémentent cette conception sous forme de composants et vérifie que ceux ci sont conformes aux cas d’utilisation. Dés qu’une itération répond aux objectifs fixés le développement passe à l’itération suivante.
Pour rentabiliser le développement il faut sélectionner les itérations nécessaires pour atteindre les objectifs du projet. Ces itérations devront se succéder dans un ordre logique.
Un projet réussi suivra un déroulement direct, établi dés le début par les développeurs et dont ils ne s’éloigneront que de façon très marginale. L’élimination des problèmes imprévus fait partie des objectifs de réduction des risques.

Avantages d’un processus itératif contrôlé

??Permet de limiter les coûts, en termes de risques, aux strictes dépenses liées à une itération.
??Permet de limiter les risques de retard de mise sur le marché du produit développé (identification des problèmes dès les premiers stades de développement et non en phase de test comme avec l’approche « classique »).
??Permet d’accélérer le rythme de développement grâce à des objectifs clairs et à court terme.
??Permet de prendre en compte le fait que les besoins des utilisateurs et les exigences correspondantes ne peuvent être intégralement définis à l’avance et se dégagent peu à peu des itérations successives
L’architecture fournit la structure qui servira de cadre au travail effectué au cours des itérations, tandis que les cas d’utilisation définissent les objectifs et orientent le travail de chaque itération. Il ne faut donc pas mésestimer l’un des trois concepts.

Le cycle de vie du processus unifié

Le processus unifié répète un certain nombre de fois une série de cycles.
Tout cycle se conclut par la livraison d’une version du produit aux clients et s’articule en 4 phases : création, élaboration, construction et transition, chacune d’entre elles se subdivisant à son tour en itérations.
Chaque cycle se traduit par une nouvelle version du système. Ce produit se compose d’un corps de code source réparti sur plusieurs composants pouvant être compilés et exécutés et s’accompagne de manuels et de produits associés. Pour mener efficacement le cycle, les développeurs ont besoin de construire toutes les représentations du produit logiciel.
Tous ces modèles sont liés. Ensemble, ils représentent le système comme un tout. Les éléments de chacun des modèles présentent des dépendances de traçabilité ; ce qui facilite la compréhension et les modifications ultérieures.

Conclusion : un processus intégré

Le processus unifié est basé sur des composants. Il utilise UML et est basé sur les cas d’utilisation, l’architecture et le développement incrémental. Pour mettre en pratique ces idées il faut recourir à un processus multi-facettes prenant en considération les cycles, les phases, les enchaînements d’activités, la réduction des risques, le contrôle qualité, la gestion de projet et la gestion de configuration. Le processus unifié a mis en place un cadre général (framework) intégrant chacune de ces facettes.

UP – LE PROCESSUS UNIFIE
I. LE PROCESSUS DE DEVELOPPEMENT : NOUVELLE APPROCHE
II. LE PROCESSUS UNIFIE : CADRE GENERAL
III.LE PROCESSUS UNIFIE EST PILOTE PAR LES CAS D’UTILISATION
IV.LE PROCESSUS UNIFIE EST CENTRE SUR L’ARCHITECTURE
V. LE PROCESSUS UNIFIE EST ITERATIF ET INCREMENTAL
VI.LE CYCLE DE VIE DU PROCESSUS UNIFIE
VII. CONCLUSION : UN PROCESSUS INTEGRE
APPROCHE DU LANGAGE UML
I. LES METHODES OBJET ET LA GENESE D’UML
II. CARACTERISTIQUES DE LA METHODE UML
III.INTRODUCTION A LA NOTATION UML
IV.MODELISER AVEC UML
INTRODUCTION AU LANGAGE UML
I. LES CAS D’UTILISATION
II. LE DIAGRAMME DE CLASSES
III. LE DIAGRAMME DE COLLABORATION