Support de cours UML modélisation d’une application informatique, tutoriel & guide de travaux pratiques UML en pdf.

La notion de projet

La notion de projet est souvent considérée différemment selon le secteur d’activité dans lequel on se trouve. Ainsi, un « projet » dans le domaine commercial sera-t-il abordé différemment d’un projet dans un développement de microélectronique, et encore différemment dans un projet informatique. Or, il s’agit fondamentalement d’une seule et même chose! Dans ce cas, on devrait pouvoir utiliser des méthodes identiques pour ces diverses modélisations.
C’est effectivement le cas pour les modélisations orientées objets, mais pas pour les modélisations basées sur la notion de procédure : la procédure est une notion trop abstraite pour être aisément traduite en termes matériels. Un PLL (Phase Locked Loop, boucle asservie en phase) est un objet faisant partie, avec d’autres, d’un objet plus complexe qui est un démodulateur FM. En revanche, comment mettre en relation le circuit intégré implémentant la fonction de démodulation avec les fonctions de Bessel décrivant le spectre de la modulation, de manière à ce que cette relation soit utilisable tout au long de la chaîne de développe-ment ? Clairement, il apparaît que les mathématiques (donc, les algorithmes) ne sont nécessaires qu’à un niveau atomique du fonctionnement de notre système, alors que le fonctionnement global doit être décrit d’une autre manière.
En résumé, il faut idéalement pouvoir décrire un projet sans tenir aucunement compte des moyens utilisés pour venir à bout de ce projet; c’est à cette condition que l’on peut valablement conduire un projet intégrant aussi bien du logiciel que du matériel. La syntaxe utilisée pour la modélisation doit tenir compte de cette condition.
Un projet est constitué de diverses phases, dont toutes sont essentielles, mais dont certaines prennent plus d’importance que d’autres selon l’optique dans laquelle on se place; les figures suivantes montrent un tel cycle vu sous l’angle de la documentation de projet. La division en plusieurs figures est uniquement dûe à des contraintes de mise en page. La description du cycle de vie du projet est faite à l’aide de UML (Unified Modeling Language) dont nous reparlerons plus loin.
Dans la première phase, seul le client et le vendeur sont concernés, le développement n’intervient qu’en guise de conseil au vendeur, et n’a aucun pouvoir exécutif. Les arguments sont économiques, et le développement doit estimer aussi précisèment que possible l’investissement qu’il devra consentir pour réaliser le projet, de manière à ce que le vendeur puisse rédiger une offre aussi réaliste que possible. Cette phase est extrêmement délicate : l’expérience joue un rôle prépondérant. Le vendeur a toute latitude pour moduler les prix selon l’importance du projet pour la société : il peut donc sous-évaluer le projet alors même que le développeur avait donné un préavis nettement moins optimiste; mais le développeur n’a pas non plus intérêt à surévaluer le travail, puisqu’il risque de faire échouer le projet !
Dans la deuxième phase, le développeur est l’acteur principal. La première tâche est la rédaction de la spécification du produit à réaliser, tâche des plus délicates, puisque cette spécification est juridiquement contraignante : si le produit fini ne correspond pas à la spécification, fût-ce sur l’un ou l’autre point de détail, le client peut refuser le paiement du travail. Bien qu’il soit rare que l’on en arrive là, cette procédure est possible, surtout entre partenaires commerciaux ne se connaissant pas très bien.