Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Génie Logiciel Avancé Cours 3 — Le modèle à objets Stefano Zacchiroli zack@pps.

Génie Logiciel Avancé Cours 3 — Le modèle à objets Stefano Zacchiroli zack@pps.jussieu.fr Laboratoire PPS, Université Paris Diderot - Paris 7 17 février 2010 URL http://upsilon.cc/zack/teaching/1011/gla/ Copyright © 2011 Stefano Zacchiroli © 2010 Yann Régis-Gianas License Creative Commons Attribution-ShareAlike 3.0 Unported License http://creativecommons.org/licenses/by-sa/3.0/ Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 1 / 74 Sommaire 1 Le modèle à objets 2 Un processus associé au modèle à objets 3 Spéciﬁcation à l’aide d’UML Vues de cas d’utilisation Vues d’architecture Vues dynamiques Vues statiques 4 Synthèse Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 2 / 74 Sommaire 1 Le modèle à objets 2 Un processus associé au modèle à objets 3 Spéciﬁcation à l’aide d’UML Vues de cas d’utilisation Vues d’architecture Vues dynamiques Vues statiques 4 Synthèse Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 3 / 74 Le modèle à objets Lorsque l’on développe un système ayant une contrepartie physique, une association de la forme « 1 objet physique ↔1 composant logiciel » peut être tentante. Dans le cours de programmation objet vous avez vu le « triangle sémiotique » : les analogies « référent »/« instance » et « signiﬁé »/« interface » peuvent faciliter le raisonnement et, surtout, la validation d’une spéciﬁcation vis-à-vis des besoins ▶Est-ce que je construis le bon logiciel ? Cette correspondance facilite la discussion avec un non-expert ▶on peut utiliser un composant logiciel par son nom devant un client non informaticien et celui-ci peut comprendre à peu près de quoi il retourne. Note Ce cours suppose quelques connaissances en programmation orientée objet. Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 4 / 74 Principes généraux de GL. . . dans le modèle à objets Déﬁnition (Objet) Un objet est formé d’un état et d’un ensemble de comportements modélisés comme des réactions à des messages. Il a une identité. Sa durée de vie est limitée. Il joue un ou plusieurs rôles dans le système. Principes : Modularité La logique interne de l’objet est décorrélée de son utilisation. Encapsulation La seule façon d’inﬂuer sur l’état d’un objet est de lui envoyer des messages. Abstraction Les objets sont généralement classiﬁés suivant une relation de généralisation. Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 5 / 74 Les forces du modèle à objets En plus des apports mentionnés plus tôt, les objets facilitent un raﬃnement progressif du modèle logique à l’implémentation. En eﬀet, les concepts importants du système sont souvent modélisés par des classes abstraites dont les sous-classes fournissent des concrétisations. De plus, les objets améliorent la réutilisabilité grâce à leur relative indépendance vis-à-vis du contexte d’utilisation. Enﬁn, l’extension a posteriori d’un composant est autorisée par le mécanisme d’héritage. ▶Cette extension n’est pas intrusive : elle ne nécessite pas de reprendre à zéro le raisonnement sur le système dans sa globalité (separation of concerns). Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 6 / 74 Les faiblesses du modèle à objets Malgré son utilisation très répandue, le modèle à objet n’est pas la solution ultime aux problèmes de la déﬁnition de composants logiciel réutilisables, corrects et robustes. Faiblesses du modèle à objets 1 La non-transparence observationnelle : à cause de son état interne, la réaction d’un objet à un message n’est pas toujours la même. Ceci rend diﬃcile le raisonnement sur les objets. 2 Le mécanisme d’héritage ne reﬂète pas la même intention en fonction du niveau d’abstraction auquel on se place. En eﬀet, dans un modèle logique, l’héritage sert à reﬂéter la relation de généralisation/spécialisation. Plus on se rapproche d’une spéciﬁcation technique et plus cette relation est un mécanisme de réutilisation de code. ⇒Le cours de POCA de Master 2. Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 7 / 74 Les faiblesses du modèle à objets (cont.) Malgré son utilisation très répandue, le modèle à objet n’est pas la solution ultime aux problèmes de la déﬁnition de composants logiciel réutilisables, corrects et robustes. Faiblesses du modèle à objets (cont.) 3 Les opérations n-aires sont peu compatibles avec le modèle objet (e.g. le problème du multiple dispatching) 4 La notion de message n’est pas de première classe, ce qui rend compliquée l’expression de mécanismes calculatoires de la forme « pour tout message, ... » (solution partielle : aspect oriented programming). 5 On aimerait parfois raisonner sur le système comme un monde clos en interdisant certaines extensions futures dangereuses (solution partielle : ﬁnal classes). ⇒Le cours de POCA de Master 2. Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 7 / 74 Sommaire 1 Le modèle à objets 2 Un processus associé au modèle à objets 3 Spéciﬁcation à l’aide d’UML Vues de cas d’utilisation Vues d’architecture Vues dynamiques Vues statiques 4 Synthèse Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 8 / 74 Le Rational Uniﬁed Process (RUP) Le Rational Uniﬁed Process (RUP) développé par IBM est une famille de processus. Ce sont des processus itératifs incrémentaux centrés sur le modèle à objets. Les validations de chaque phase s’appuient sur des cas d’utilisation. Le système est décrit comme la somme de multiples vues. Son architecture est le soucis permanent : le RUP préconise le développement préliminaire d’une architecture exécutable, c’est-à-dire une version du système avec un nombre très limité de fonctionnalités mais dont le “squelette” est ﬁxé. Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 9 / 74 Les diﬀérentes variantes du RUP Le Uniﬁed Process (UP) est la version la plus documentée du RUP. ▶C’est une version générique adaptable aux besoins particuliers. Le Agile Uniﬁed Process (AUP) ajoute un caractère évolutif à RUP. ▶On s’appuie sur une haute qualiﬁcation des développeurs pour limiter le plus possible la production de documents préliminaires au développement. Les cas d’utilisation sont représentés par des tests exécutables. Un prototype est développé très rapidement et dirigés par la validation de ces tests. La spéciﬁcation est construite en même temps que le logiciel, une fois que celui-ci est confronté sous une forme exécutable aux utilisations des clients. Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 10 / 74 Les phases du RUP http://en.wikipedia.org/wiki/File:Development-iterative.gif Dans ce diagramme, les lignes correspondent aux work-ﬂows. Les colonnes correspondent aux phases. La hauteur détermine l’intensité des phases. Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 11 / 74 Innovations du RUP Séparation phases / work-ﬂows ▶chaque work-ﬂow est inter-phase, comme dans la réalité du projets de développement Work-ﬂow explicite pour le deployment du logiciel Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 12 / 74 RUP : phase « initialisation » (inception) Cette phase correspond à l’étude de faisabilité dont nous avons parlée dans le cours précédent. établir un business case pour le système il peut amener à l’abandon du projet (donc il est plus intense vers le début du projet, pour minimiser les risques) Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 13 / 74 Phase « élaboration » Il s’agit de l’analyse des besoins. Celle-ci fait un usage intensif des cas d’utilisation (et donc de scenarios) pour raﬃner la compréhension du problème posé et expliciter les spéciﬁcités du domaine. Des prototypes (parmi lesquels on trouve l’architecture exécutable) sont développés pour évaluer concrètement des points techniques risqués. Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 14 / 74 Phase « construction » Cette phase correspond à la conception et au développement. Elle est répète plusieurs fois pour une progression incrémentale aboutissant à diverses versions du système, résolvant les problèmes techniques à hauts risques en priorité. Dans une conception orienté objet, il est parfois diﬃcile de bien distinguer la spéciﬁcation de l’implémentation. ▶Certains spécialistes préconisent la déﬁnition de deux modèles disjoints : un modèle logique et un modèle d’implémentation (voir : model-driven engineering). ▶Cette distinction est importante car il doit toujours exister une spéciﬁcation servant de référence aux développements et sur laquelle appuyé le cahier des charges. Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 15 / 74 Phase « transition » La phase de transition de ce processus correspond à l’activité de maintenance et de déploiement. Il s’agit de vériﬁer la mise en place du système auprès des utilisateurs (production de manuel d’utilisation, formation, . . . ) et de préparer ses futures évolutions. Cette phase a été ignoré par plusieurs modèles de développement précédents au RUP. Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 16 / 74 Cours d’aujourd’hui Nous allons nous intéresser à l’utilisation d’UML dans ces diﬀérentes phases pour les trois premières itérations. ▶Dans ce processus, elles correspondent à la spéciﬁcation du système. Stefano Zacchiroli (Paris 7) Le modèle à objets 17 février 2010 17 / 74 Sommaire 1 Le modèle à objets 2 Un processus associé au modèle à objets 3 Spéciﬁcation à l’aide d’UML Vues de cas d’utilisation Vues d’architecture Vues dynamiques Vues statiques 4 Synthèse Stefano Zacchiroli (Paris 7) uploads/Sante/ genie-logiciel-avance-cours-3-le-modele-a-objets-stefano-zacchiroli.pdf