Qu est ce que la modélisation? La modélisation est la conception d'un modèle. Selon son objectif et les moyens utilisés, la modélisation est dite

Daphné Nougier 1

2

3

Qu est ce que la modélisation? La modélisation est la conception d'un modèle. Selon son objectif et les moyens utilisés, la modélisation est dite mathématique, géométrique, 3D, informatique, d'entreprise, économique, humaine 4

Modèle informatique En informatique, un modèle a pour objectif de structurer les informations et activités d'une organisation : données, traitements, et flux d'informations entre entités. Les modèles informatiques développés dans les années 1970 étaient tous du type entitérelation. Par exemple Merise (MCD). Ces modèles comportaient en général trois composantes principales : Les données : modèle de données Les traitements : modèle de traitements Les flux : diagramme de flux On a traditionnellement distingué trois niveaux de préoccupation : le niveau conceptuel, le niveau logique ou organisationnel, le niveau physique. Ces modèles ont généralement été appliqués à l'échelle des applications, voire des domaines, mais rarement à l'échelle des entreprises, de sorte que l'on trouvait des incohérences d'un domaine à l'autre dans une même entreprise. D'où des interfaces difficiles à établir lorsque les données n'étaient pas définies de la même façon d'un domaine à l'autre. Dans les années 1990, la nécessité de remplacer ou de rénover les applications affectées par les problèmes de date (passage à l an 2000) a entraîné la mise en œuvre de progiciels de gestion intégrés à l'échelle des entreprises. Les données et applications ont été mises en cohérence souvent en fonction de la structure de ces progiciels, qui en général ont été conçus dans l'esprit des modèles entité-relation. 5

modèle de données relationnel C'est le type de modèle de données le plus couramment utilisé pour la réalisation d'une base de données. Selon ce type de modèle, la base de données est composée d'un ensemble de tables (les relations) dans lesquelles sont placées les données ainsi que les liens. Chaque ligne d'une table est un enregistrement. Ces modèles sont simples à mettre en œuvre, fondés sur les mathématique (la théorie des ensembles), ils sont très populaires et fortement normalisés. modèle de données entité-association Ce type de modèle est le plus couramment utilisé pour la conception de modèles de données logiques. Selon ce type de modèle, Une base de données est un lot d'entités et d'associations. Une entité est un sujet concret, un objet, une idée, pour laquelle il existe des informations. Un attribut est un renseignement concernant ce sujet - exemple le nom d'une personne. À chaque attribut correspond un domaine: un ensemble de valeurs possibles. Une association désigne un lien entre deux entités - par exemple un élève et une école. modèle de données objet Ce type de modèle est fondé sur la notion d objet de la programmation orientée objet. Selon ce type de modèle une base de données est un lot d objets de différentes classes. Chaque objet possède des propriétés - des caractéristiques propres, et des méthodes qui sont des opérations en rapport avec l'objet. Une classe est une catégorie d'objets et reflète typiquement un sujet concret5. modèle de données hiérarchique Ce type de modèle de données a été créé dans les années 1960; c'est le plus ancien modèle de données. Selon ce type de modèle, les informations sont groupées dans des enregistrements, chaque enregistrement comporte des champs. Les enregistrements sont reliés entre eux de manière hiérarchique: à chaque enregistrement correspond un enregistrement parent5. modèle de données réseau Ce type de modèle de données est semblable au modèle hiérarchique. Les informations sont groupées dans des enregistrements, chaque enregistrement possède des champs. Les enregistrements sont reliés entre eux par des pointeurs. Contrairement aux modèles hiérarchiques, l'organisation des liens n'est pas obligatoirement hiérarchique, ce qui rend ces modèles plus polyvalents. 6

modèle de données Le schéma ou modèle de données, est la description de l'organisation des données. Il se trouve à l'intérieur de la base de données, et renseigne sur les caractéristiques de chaque type de donnée et les relations entre les différentes données qui se trouvent dans la base de données. entité Une entité est un objet, un sujet, une notion en rapport avec le domaine d'activité pour lequel la base de données est utilisée, et concernant lequel des données sont enregistrées (exemple: des personnes, des produits, des commandes, des réservations, ). attribut Un attribut est une caractéristique d'une entité susceptible d'être enregistrée dans la base de données. Par exemple une personne (entité), son nom et son adresse (des attributs). Les attributs sont également appelés des champs ou des colonnes. Dans le schéma les entités sont décrites comme un lot d'attributs en rapport avec un sujet1. enregistrement Un enregistrement est une donnée composite qui comporte plusieurs champs dans chacun desquels est enregistrée une donnée. Cette notion a été introduite par le stockage dans des fichiers dans les années 19601. association Les associations désignent les liens qui existent entre différentes entités, par exemple entre un vendeur, un client et un magasin. cardinalité La cardinalité d'une association - d'un lien entre deux entités A et B - est le nombre de A pour lesquelles il existe un B et inversement. Celle-ci peut être un-a-un, un-a-plusieurs ou plusieurs-à-plusieurs. Par exemple un compte bancaire appartient à un seul client, et un client peut avoir plusieurs comptes bancaires (cardinalité un-a-plusieurs) nul Dans les modèles de données relationnels, un attribut peut avoir une valeur nulle, indiquant que la donnée est absente, non disponible ou inapplicable. 7

Modèle Entité Association ou ER Model (Entity Relationship Model) Le modèle Entité-Association a été développé par Peter Chen dans une publication de 1976 pour la conception des bases de données. La méthode MERISE, développée vers 1975 par les sociétés Sema-Metra et Compagnie Générale d'informatique (CGI) utilise largement le modèle entité/association. La CGI a adjoint des modèles de développement informatiques. A la place des objets de gestion, on parle aujourd'hui des objets métier. Utilisation du modèle Le modèle entité/association a été très employé pour l'automatisation des processus de gestion dans les années 1970 et 1980. Il est utile pour rationaliser les traitements administratifs : la comptabilité, la paye, la facturation, l'administration des ventes, les achats, le service client,... Progressivement tous les domaines de gestion ont été gérés en utilisant ces modèles. Dans les années 1990, la plupart des domaines de gestion étant déjà automatisés, l'enjeu était de remplacer ou d'adapter des systèmes de gestion devenus obsolescents. A 60 % environ dans les grandes entreprises, les applications spécifiques ont été remplacées par des progiciels de gestion intégrés. Ces progiciels ont conservé le principe du modèle entité-association, d'une façon standardisée : les modèles souvent incohérents d'un domaine de gestion à un autre ont dû être harmonisés pour faire fonctionner les interfaces entre domaines. Données et traitements Le modèle entité-association porte essentiellement sur les données de gestion. Un système informatique nécessite de traiter des les données et traitements. Les modèles de données et traitements ont permis de réduire considérablement les coûts de gestion par l automatisation des tâches. Les modèles de traitements utilisés dans les méthodes d analyse et de conception ont eu certains effets relativement négatifs : Processus et tâches souvent gérés de façon séquentielle, la modélisation des traitements s'est révélée quelquefois lourde, Cloisonnement entre les domaines de gestion et les services impliqués dans l innovation (recherche et marketing), d'où une difficulté à intégrer les processus de gestion (séquentiels) et les processus transversaux (qualité, sécurité, environnement, énergie, santé) dont les enjeux deviennent de plus en plus cruciaux. 8

Edgar Frank «Ted» Codd (1923-2003), informaticien britannique est considéré comme l'inventeur du modèle relationnel. Il publie un article dans lequel il présente le modèle relationnel «A Relational Model of Data for Large Shared Data Banks" ("Un modèle de données relationnel pour de grandes banques de données partagées"), en 1970, mais une première description de ce modèle avait déjà été publiée l'année précédente dans un rapport technique : «Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks», IBM Research Report RJ599. Le modèle relationnel est une manière de modéliser les informations contenues dans une base de données. Il repose sur des principes mathématiques mis en avant par Codd. On appelle relation un ensemble d'attributs qui définissent un fait, un objet, un sujet. Par exemple un employé a un matricule donné, son nom est untel, il travaille dans tel service et a été embauché à telle date. Chaque instance d une relation est appelée un tuple. Par définition, chaque tuple d'une relation est unique, et est identifié par un attribut ou une combinaison de plusieurs attributs qui forme la clef. L'ordre des tuples n'est pas significatif. Codd a défini une algèbre relationnelle et des opérateurs qui permettent de construire d'autres relations à partir de relations. Les idées de Codd ont été implémentées -- plus ou moins fidèlement -- dans les systèmes de gestion des bases de données relationnelles ou SGBD, comme le projet expérimental IBM System R. Puis des produits commerciaux tels que Oracle, DB2 ou MySQL. Le modèle relationnel est aujourd hui l'un des modèles les plus utilisés. Les premiers SGBD bâtis sur ce modèle ont été SQL/DS et DB2 de IBM où est né le langage de manipulation de bases relationnelles, SQL (Structured Query Language).». Opérateurs relationnels Le modèle relationnel définit 5 opérateurs de base que sont l'union, la différence, la sélection (ou restriction), la projection et le produit cartésien. Ces opérateurs présentent l'avantage d'être fermés (ils travaillent sur des relations et retournent des relations qui peuvent de nouveau être utilisées avec des opérateurs,...). Le langage support applicatif d'un Système de Gestion de Bases de Données reposant sur un modèle relationnel est le SQL. 9

La règle informationnelle : Toutes les informations dans la base des données sont explicites et portent la même structure logique et sont représentées par valeurs dans les tableaux. La règle de certitude : Toutes les données sont dans le modèle relationnel accessibles par la combinaison de nom de tableau, la valeur de clé principale et le nom de la colonne. Le traitement des valeurs nulles systématique : Les valeurs nulles sont bien adoptées par le modèle relationnel et pour représentation de l information qui n est pas définie et ne sont pas dépendantes du type de données. Le catalogue en ligne basé sur le modèle relationnel : La description de la base des données est exprimée sur le même niveau logique et de même manière que les dates de client. Alors un utilisateur autorisé peut appliquer la même langue relationnelle pour appliquer sa demande comme utilisateur qui travaille avec les données. La langue de définition des données : Le système relationnel peut soutenir plusieurs langues et modes pendant l utilisation de terminal. Mais il faut qu il y ait au moins une langue vaste qui puisse définir la structure des données, la manipulation interactive, restrictions intégrales, autorisation pour accéder à la base des données, les commandes transactionnelles etc. (SQL) La règle de création de vue : Toutes les vues sont théoriquement possibles et sont aussi créées par système. Le pouvoir de créer, insérer et effacer : Il est possible de préserver les règles relationnelles sur les relations de base et aussi relations dérivées non seulement en regardant les données, mais aussi pendant les opérations d intersection, l union et effacement des données. L indépendance physique des données : Les programmes d application sont indépendants de la structure physique des données. L indépendance de la logique des données : Les programmes d application sont indépendants de la structure logique de base des données. L indépendance intégrale : Les restrictions intégrales doivent être définies par les moyens de la base des données relationnelle ou son langage et doivent être situées dans le catalogue et non dans le programme d application. L indépendance de la distribution : Il est nécessaire que le système de gestion de base des données relationnel soit capable d être implémenté sur les autres architectures informatiques. La règle d'accès sur la base des données : Si le système relationnel a la langue de niveau bas, on ne peut pas utiliser ce niveau pour exprimer les restrictions intégrales et il est nécessaire de les exprimer en langue relationnelle de niveau supérieur. 10

La modélisation relationnelle La modélisation relationnelle permet de présenter les relations sous forme des tables de deux dimensions. Chaque colonne possède un identificateur qui représente un domaine. On appelle tuple un ensemble de valeurs d attributs désordonnés, ou ligne de table. Chaque opération relationnelle sur une table génère une nouvelle relation et les opérateurs relationnels Le langage SQL permet de décrire le résultat que l on veut obtenir sans avoir à décrire la procédure nécessaire pour arriver au résultat : on dit que la langue relationnel est «non procédural» Pour lier les relations entre elles on utilise la clé primaire et la clé étrangère. La clé primaire est constituée d un ou plusieurs attributs permettant de désigner d une façon unique un tuple. La clé étrangère est un identificateur qui fait référence à une clé unique dans une autre table ou la même table. Exemple de Table Relationnelle Cette relation R est représentée par une table constituée de 3 colonnes (trois attributs) A1, A2, A3 dont chaque ligne est caractérisée par différente valeurs dans les domaines A1, A2, A3. Pour modéliser l entité «voiture» on prendra comme attributs : la marque, la couleur, la plaque d immatriculation et la date de création. Cardinalité de relation Le modèle relationnel prévoit 3 différents types de relations entre tables : 1:1, 1:N et M:N. Relation 1:1 Dans deux tables A et B de relation 1:1, un élément de la table A se rapporte seulement à un élément de la table B. Relation 1:N Dans deux tables A et B de relation 1:N, un élément de la table A se rapporte à un ou plusieurs éléments de la table B. Relation M:N Dans deux tables A et B de relation M:N, un élément de la table A se rapporte à un ou plusieurs éléments de la table B et un élément de la table B se rapporte à un ou plusieurs éléments de la table A. Une relation M:N peut donc être décomposées en deux relations 1:N. 11

Forme normale (bases de données relationnelles) Dans une Base de données relationnelle, une forme normale désigne un type de relation particulier entre les entités. Le but essentiel de la normalisation est d'éviter les anomalies transactionnelles pouvant découler d'une mauvaise modélisation des données et ainsi éviter un certain nombre de problèmes potentiels tels que les anomalies de lecture, les anomalies d'écriture, la redondance des données et la contre-performance. La normalisation des modèles de données permet de vérifier la robustesse de leur conception pour améliorer la modélisation (et donc obtenir une meilleure représentation) et faciliter la mémorisation des données en évitant la redondance et les problèmes sous-jacents de mise à jour ou de cohérence. La normalisation s applique à toutes les entités et aux relations porteuses de propriétés. Les formes normales s'emboitent les unes dans les autres, tant et si bien que le respect d'une forme normale de niveau supérieur implique le respect des formes normales des niveaux inférieurs. Dans le modèle relationnel de type OLTP. Il existe huit formes normales, les trois premières étant les plus connues et utilisées. La forme normale vient après la simple validité d'un modèle relationnel, c'est-à-dire que les valeurs des différents attributs soient bien en dépendance fonctionnelle avec la clé primaire (complètement déterminés par la clé primaire). 12

Les différentes formes normales Les formes normales sont construites selon le principe des dépendances fonctionnelles. 1FN Première forme normale Relation dont tous les attributs : toutes les informations sont atomiques contiennent une valeur scalaire (les valeurs ne peuvent pas être divisées en plusieurs sousvaleurs dépendant également individuellement de la clé primaire) contiennent des valeurs non répétitives (le cas contraire consiste à mettre une liste dans un seul attribut). sont constants dans le temps (utiliser par exemple la date de naissance plutôt que l'âge). Le non-respect des deux premières conditions de la 1FN rend la recherche parmi les données plus lente parce qu'il faut analyser le contenu des attributs. La troisième condition quant à elle évite qu'on doive régulièrement mettre à jour les données. 13

Les différentes formes normales 1FN Première forme normale Relation dont tous les attributs : toutes les informations sont atomiques contiennent une valeur scalaire (les valeurs ne peuvent pas être divisées en plusieurs sousvaleurs dépendant également individuellement de la clé primaire) contiennent des valeurs non répétitives (le cas contraire consiste à mettre une liste dans un seul attribut). sont constants dans le temps (utiliser par exemple la date de naissance plutôt que l'âge). Le non-respect des deux premières conditions de la 1FN rend la recherche parmi les données plus lente parce qu'il faut analyser le contenu des attributs. La troisième condition quant à elle évite qu'on doive régulièrement mettre à jour les données. Exemples de violation (les * indiquent les attributs appartenant à la clé primaire) 14

Les différentes formes normales 2FN Deuxième forme normale Respecte la deuxième forme normale, la relation respectant la première forme normale et respectant le principe suivant : Les attributs d'une relation sont divisés en deux groupes : le premier groupe est composé de la clé (un ou plusieurs attributs). Le deuxième groupe est composé des autres attributs (éventuellement vide). La deuxième forme normale stipule que tout attribut du deuxième groupe ne peut pas dépendre d'un sous-ensemble (strict) d'attribut(s) du premier groupe. En d'autres termes : «Un attribut non clé ne dépend pas d'une partie de la clé». Le non-respect de la 2FN entraîne une redondance des données qui encombrent alors inutilement la mémoire et l'espace disque. 15

Les différentes formes normales 2FN Deuxième forme normale Respecte la deuxième forme normale, la relation respectant la première forme normale et respectant le principe suivant : Les attributs d'une relation sont divisés en deux groupes : le premier groupe est composé de la clé (un ou plusieurs attributs). Le deuxième groupe est composé des autres attributs (éventuellement vide). La deuxième forme normale stipule que tout attribut du deuxième groupe ne peut pas dépendre d'un sous-ensemble (strict) d'attribut(s) du premier groupe. En d'autres termes : «Un attribut non clé ne dépend pas d'une partie de la clé». Le non-respect de la 2FN entraîne une redondance des données qui encombrent alors inutilement la mémoire et l'espace disque. Exemple de violation 16

Les différentes formes normales 3FN Troisième forme normale Respecte la troisième forme normale, la relation respectant la seconde forme normale et respectant le principe suivant : Les attributs d'une relation sont divisés en deux groupes : le premier groupe est composé de la clé (un ou plusieurs attributs). Le deuxième groupe est composé des autres attributs (éventuellement vide). La troisième forme normale stipule que tout attribut du deuxième groupe ne peut pas dépendre que d'un sous-ensemble (strict) d'attribut(s) du deuxième groupe. En d'autres termes : «Un attribut non clé ne dépend pas d'un ou plusieurs attributs ne participant pas à la clé». Le respect de la 3FN ne garantit pas une absence de redondance des données d'où la FNBC. 17

Les différentes formes normales 3FN Troisième forme normale Respecte la troisième forme normale, la relation respectant la seconde forme normale et respectant le principe suivant : Les attributs d'une relation sont divisés en deux groupes : le premier groupe est composé de la clé (un ou plusieurs attributs). Le deuxième groupe est composé des autres attributs (éventuellement vide). La troisième forme normale stipule que tout attribut du deuxième groupe ne peut pas dépendre que d'un sous-ensemble (strict) d'attribut(s) du deuxième groupe. En d'autres termes : «Un attribut non clé ne dépend pas d'un ou plusieurs attributs ne participant pas à la clé». Le respect de la 3FN ne garantit pas une absence de redondance des données d'où la FNBC. Exemple de violation 18

Les différentes formes normales FNBC Forme normale de Boyce-Codd Respecte la forme normale de Boyce-Codd, la relation respectant la troisième forme normale et dont : tous les attributs non-clé ne sont pas source de dépendance fonctionnelle (DF) vers une partie de la clé Le non-respect de la 2FN, 3FN et la FNBC entraîne de la redondance. Une même information étant répétée un nombre considérable de fois. 19

Les différentes formes normales 4FN - quatrième forme normale Pour toute relation de dimension n en forme normale de Boyce-Codd, les relations de dimension n-1 construites sur sa collection doivent avoir un sens. Il ne doit pas être possible de reconstituer les occurrences de la relation de dimension n par jointure de deux relations de dimension n-1. Cette normalisation conduit parfois à décomposer une relation complexe en deux relations plus simples. 5FN - cinquième forme normale Pour toute relation de dimension n (avec n supérieur à 2) en quatrième forme normale, il ne doit pas être possible de retrouver l ensemble de ses occurrences par jointure sur les occurrences des relations partielles prises deux à deux. Cette normalisation conduit parfois à décomposer une relation complexe en plusieurs relations plus simples. Le non-respect de la 4FN et 5FN entraîne de la perte de données et les informations manquent de précision. 20

Les différentes formes normales FNDC - forme normale domaine clef Une relation est en FNDC si et seulement si toutes les contraintes sont la conséquence logique des contraintes de domaines et des contraintes de clefs qui s'appliquent à la relation. Pour se souvenir de l'ordre et des caractéristiques des trois premières formes normales, il suffit de se rappeler le serment que tous les témoins doivent prêter devant la justice : Je jure de dire la vérité, toute la vérité, rien d'autre que la vérité. Ce qui donne : 1FN = La clé. 2FN = Toute la clé. 3FN = Rien que la clé. La phrase originale étant : «The key, the whole key, nothing but the key» (Chris Date). Elle est empruntée à l'œuvre de Shakespeare. 21

Développement en cascade Waterfall Le développement Waterfall se déroule à travers une série de phases, en commençant par l analyse des besoins du système jusqu à la mise en production du système et maintenance. Le modèle comprend 6 phases distinctes : 1. Analyse des besoins: Cette première étape est aussi la plus importante, car elle implique la collecte d'informations sur ce que les besoins des clients et de définir, dans les termes les plus clairs possibles, le problème que le produit devrait résoudre. Analyse comprend la compréhension du contexte et des contraintes de l'entreprise du client, les fonctions du produit doit exécuter, les niveaux de performance, il doit respecter, et les systèmes externes, il doit être compatible avec. Les techniques utilisées pour obtenir cette compréhension comprennent entretiens avec les clients, les cas d'utilisation, et les «listes d'achats» des fonctionnalités du logiciel. Les résultats de l'analyse sont habituellement pris dans un cahier des charges formel, qui sert d'entrée à l'étape suivante. 2. Design: Cette étape consiste à "définir l'architecture matérielle et logicielle, les composants, les modules, les interfaces et les données... pour satisfaire les exigences spécifiées. Il s'agit de définir l'architecture matérielle et logicielle, spécifier les paramètres de performance et de sécurité, la conception des conteneurs de stockage de données et les contraintes, le choix de l'ide et langage de programmation, et indiquant les stratégies pour faire face à des questions telles que la gestion des exceptions, la gestion des ressources et la connectivité d'interface. C'est aussi le stade où la conception de l'interface utilisateur est adressée, y compris les questions relatives à la navigation et accessibilité. La sortie de cette étape est une ou plusieurs des spécifications de conception, qui sont utilisés dans l'étape suivante de mise en œuvre. 3. Mise en œuvre: Cette étape consiste à construire effectivement le produit selon le cahier des charges (s) développé à l'étape précédente. Typiquement, cette étape est réalisée par une équipe de développement composée de programmeurs, les concepteurs d'interfaces et d'autres spécialistes, en utilisant des outils tels que des compilateurs, des débogueurs, des interprètes et rédacteurs des médias. La sortie de cette étape est un ou plusieurs composants du produit, construit selon une norme de codage et de débogage, testés et intégrés pour satisfaire aux exigences de l'architecture du système. Pour les projets impliquant une grande équipe, contrôle de version est recommandé de suivre les changements dans l'arbre de code et revenir à des instantanés précédents en cas de problèmes. 22

Développement en cascade Waterfall (suite) Le développement Waterfall se déroule à travers une série de phases, en commençant par l analyse des besoins du système jusqu à la mise en production du système et maintenance. Le modèle comprend 6 phases distinctes : 4. Tests: Dans cette étape, les deux composants et le tout intégré sont méthodiquement vérifiés pour s'assurer qu'ils sont exempts d'erreurs et répondre pleinement aux exigences énoncées dans la première étape. Une équipe d'assurance qualité indépendante définit les "cas de test" pour évaluer si le produit remplit totalement ou partiellement les exigences énoncées dans la première étape. Trois types de tests ont généralement lieu: les tests unitaires de modules de code individuels; l'essai du système du produit intégré; et les tests d'acceptation, formellement effectuée par ou pour le compte du client. Défauts, s'il est reconnu, sont enregistrés et les commentaires fournis à l'équipe de mise en œuvre pour permettre la correction. C'est aussi le stade où la documentation du produit, comme un mode d'emploi, est préparé, révisé et publié. 5. Mise en production : Cette étape se produit une fois que le produit a été testé et certifié apte à l'emploi, et consiste à préparer le système ou le produit pour l'installation et l'utilisation sur le site du client. La livraison peut se faire via Internet ou un support physique, et le livrable est généralement marqué par un nombre formel de révision afin de faciliter les mises à jour à une date ultérieure. 6. Maintenance : Cette étape survient après l'installation, et consiste à faire des modifications apportées au système ou un composant individuel de modifier les attributs ou améliorer les performances. Ces modifications surviennent soit en raison de demandes de changement initiées par le client, ou des défauts découverts lors de l'utilisation en direct du système. En règle générale, toutes les modifications apportées au produit pendant le cycle d'entretien est enregistré et une nouvelle version du produit (appelé «version de maintenance" et présentant un numéro de révision mise à jour) est effectuée pour permettre au client de tirer le meilleur profit de la mise à jour. 23

Méthode agile Les méthodes agiles sont des groupes de pratiques de projets de développement en informatique (conception de logiciel), pouvant s'appliquer à divers types de projets. Elles ont pour dénominateur commun l'agile manifesto. Rédigé en 2001, celui ci consacre le terme d'«agile» pour référencer de multiples méthodes existantes. Les méthodes agiles se veulent plus pragmatiques que les méthodes traditionnelles. Elles impliquent au maximum le demandeur (client) et permettent une grande réactivité à ses demandes. Elles visent la satisfaction réelle du client en priorité aux termes d'un contrat de développement. Les méthodes agiles reposent sur une structure (cycle de développement) commune (itérative, incrémentale et adaptative), quatre valeurs communes déclinées en douze principes communs desquels découlent une base de pratiques, soit communes, soit complémentaires. Les premières méthodes agiles apparues sont EVO (Evolutionary Project Management) (1976), RAD (développement rapide d'applications) (1991), puis DSDM, la version anglaise du RAD (1995). Plusieurs autres méthodes, comme ASD ou FDD, reconnaissent leur parenté directe avec RAD. Les trois méthodes agiles désormais les plus utilisées sont : la méthode Kanban, issue de la méthode industrielle Lean, la méthode Scrum publiée en 2001 par Ken Schwaber et Jeff Sutherland, et la méthode XP Extreme programming publiée en 1999 par Kent Beck. Un mouvement plus large (management agile) couple les valeurs agiles aux techniques de l'amélioration continue de la qualité (plus particulièrement le Lean). On constate un élargissement de l'utilisation d'agile à l'ensemble de la structure de l'entreprise. 24

CASE*METHOD 1. Niveau Conceptuel: Ce niveau regroupe les phases de modélisation organisationnelles et conceptuelles : la phase STRATEGY qui correspond à l ébauche du modèle fonctionnel des processus métier et des structures de données du système d information à développer. la phase ANALYSIS qui correspond à l analyse détaillée de ce modèle. A ce niveau on définit les structures de données par un regroupement d Attributs fonctionnels qui constituent ainsi les Entités du système. Le Modèle Conceptuel de Données (MCD) est représenté sous forme graphique par des diagrammes d entités/associations (Entity/Relationship Diagram). Les traitements sont modélisés par des hiérarchies de fonctions représentées également par des diagrammes (Function Hierarchy Diagram). Les termes consacrés à ce niveau pour désigner les structures de données sont entités (entity), attributs (attributes) et associations (relationship). Pour les traitements on parle de fonction de gestion (business function), processus (process) et flux (flow) 2. Niveau Développement C est à ce niveau que l on développe, programme et génère les éléments du projet qui vont constituer le futur système d information. la phase DESIGN concerne les étapes de conception et de programmation proprement dites. Le modèle conceptuel est transformé en modèle logique. La phase BUILD comprend les opérations de génération du code et du modèle physique de données. La DOCUMENTATION utilisateur est générée à ce niveau. Les termes employés sont tables ou fichiers en ce qui concerne les données, modules pour nommer les étapes des traitements. 3. Niveau Déploiement TRANSITION regroupe l ensemble des étapes qui précédent la mise en exploitation du projet. Le critères d implantation physique sont définis ici. Par exemple création des bases de données de production, déploiement des applications, optimisation et réglages des instances de base de données, correction des anomalies La recette du projet s effectue également à cette étape. La phase PRODUCTION comprend la mise en exploitation du projet, la production proprement dite, les opérations de mise à jour et de maintenance des applications, ainsi que la prise en compte de l évolution fonctionnelle du projet. 25

Cycle de vie en cascade Waterfall En appliquant ce type d approche, les différentes phases du cycle de vie sont réalisées en une seule passe pour tous les besoins exprimés dans le cahier des charges. Cela conduit souvent à ne découvrir que pendant les tests les divers problèmes de qualité demeurés insoupçonnés lors de la conception et l implémentation. Ces problèmes étant découverts tardivement dans le processus de développement, il est souvent trop tard ou trop coûteux de les corriger. Par exemple, il est fréquent de s apercevoir que les performances du système de gestion de base de données sont insuffisantes après la mise en exploitation ou bien que la stratégie de sauvegarde s avère inopérante pour un type de panne spécifique. 26

Le Modèle Waterfall Le modèle Waterfall ou modèle en cascade est un modèle de conception séquentielle utilisée dans les processus de développement de logiciels dans lequel la progression est constante vers le bas à travers les phases de conception, d initiation, d analyse, de construction, de production de mise en œuvre et de maintenance. Le modèle est originaire de l industrie pour des environnements très structurés pour lesquels les changements sont coûteux, voire impossible. La première présentation a été faite pour décrire les méthodes de programmation avancées pour les ordinateurs numériques en 1956. Cette présentation portait sur le développement de logiciels pour SAGE. En 1983, cette présentation a été revue et soulignait que le processus n était pas en fait effectué de manière top-down (vers le bas) de manière stricte mais dépendait du prototypage. Il existe de nombreuses références au modèle en cascade et de nombreuses méthodes peuvent être qualifiée de waterfall modifié. La thèse selon laquelle le modèle en cascade est une méthode de développement non itérative est un mythe et un argument utilisé uniquement pour défendre les méthodes de développement alternatif. 27

Quel est le problème du Waterfall? Aujourd'hui encore, les projets sont dirigés au moins en apparence sous forme de waterfall, c'est à dire un cycle unique en V (Analyse - spécifications & modélisation - conception, codage, tests unitaires et l'intégration, livraison et recette). On retrouve ce cycle en V décrit sur la diapositive et ci-dessus avec humour) : Vu de "l'extérieur", le client voit donc 5 grandes phases. Certes, en interne, il peut en être autrement, mais si ce n'était pas le cas, voilà ce que cela signifierait : pas de retour entre les phases : une fois que l'analyse est faite, c'est terminé, tout le monde travaille sur la conception. Une fois que la conception est faite, c'est terminé... etc., des dates fixes pour chaque phase, qui servent de références pour juger de l'état d'avancement des développeurs, pas de critère de complétion pour l'analyse et la conception : ces phases se finissent... quand le calendrier l'indique. Et, du coup, la plupart du temps, ces phases se terminent dans les temps! Mais elles ne sont pas réellement "finies". 28

Approche itérative Intégration continue : on ne rassemble pas les morceaux juste avant la recette finale. On le fait tout au long du projet versions exécutables intermédiaires fréquentes : le client doit souvent avoir l'occasion de voir l'avancement du projet pour mieux "corriger le tir», gestion des risques : le projet doit s'attaquer aux parties impliquant les plus gros risques (techno mal maîtrisée, produits peu connus,...). Conséquences : développement continu : les versions intermédiaires (qui sont, rappelons-le, de véritables exécutables remplissant n% des fonctionnalités attendues, en commençant par les plus "risquées") forcent le projet à remplir toutes les fonctionnalités exigées par le client. Il n'y a donc pas de phénomène du type : "90% du projet fait, 10% restent à faire». intégration progressive des évolutions : les besoins du client changent ou, pour le moins, s'affinent au fil du projet. Le cycle itératif permet de détecter ces changements au plus tôt et des les intégrer soit directement, soit via des avenants. Découpage en tranches Tout l'enjeu du cycle itératif est de bien réaliser que, dans un projet, il n'y a que 2 dates connues : - le T0 (prononcez «t zéro», date de début du projet). - la date de livraison (donc, de "fin" du projet). Entre ces 2 dates, il s'agit de diviser le projet en tranche (itérations) qui ne sont pas des milestones (comme celle du cycle en V du Waterfall : analyse, conception, codage,...), donc qui n'ont pas de date fixe qui leur serait attachée! Cela ne signifie pas pour autant qu'on ne pourrait manager son projet en en mesurant l'état d'avancement. Une itération a pour caractéristique d'être : - un cas d'utilisation (ou une partie). Il ne s'agit pas de sous-système technique mais bien de quelque chose auquel le client peut donner un sens, - une fonctionnalité. Cela permet, plus tard dans le projet, lorsque l'on décide d'éliminer telle ou telle partie pour rester dans les délais, d'éliminer des itérations et non de nombreuses parties d'une ou plusieurs itérations, - un exécutable : une itération doit pouvoir être évaluée par le client, avec des critères d'appréciations, - court : une itération se compte en jours, une à deux semaines maxi, pas en mois. - un mini-cycle en V : non seulement en sortie on a un programme exécutable, mais on a aussi des documents d'analyse et de conception qui viennent compléter ceux des itérations précédentes. - indépendante des itérations à venir : il s'agit d'avoir bien pensé son découpage de façon à ce que chaque itération utilise les fonctionnalités des itérations précédentes et le moins possible celle des itérations suivantes. 29

la première itération est la plus importante La première itération est celle à choisir avec le plus de soin. Elle doit à la fois être celle comportant les difficultés techniques les plus importantes et être "visuelle", et ce pour 2 raisons : - savoir le plus tôt possible si l'on peut réussir le projet ou non (donc s'attaquer aux difficultés en premier), - calibrer les délais le plus "large" possible, en multipliant la durée de la première itération (qui, en générale, est longue) par le nombre d'itérations prévues. Cependant : - les fonctionnalités les plus complexes ne sont pas toujours abordables en premier car elles peuvent dépendre d'autres, plus simples. Il faudra néanmoins les aborder le plus tôt possible, - les itérations peuvent se "paralléliser", mais les 2 premières doivent, de préférence, se faire séquentiellement. Planifier, Estimation continuelle L'avantage du Watefall et de ses 5 milestones, avec ses dates fixes, c'est qu'un manager peut à tout moment "voir dans le temps" où il en est. Les itérations, auxquelles - initialement - aucune date n'est attachée, n'empêchent pas ce type d'évaluation. Simplement, celles-ci se raffinent dans le temps. Lorsque la première itération se termine, on a : - un exécutable représentant n% des fonctionnalités du projet et dont on sait qu'il marche (!), - l'analyse et la conception pour cette partie du projet, - la durée nécessaire pour réaliser cette itération. On peut alors faire une première - grossière - estimation de la durée du projet en multipliant celle de la première itération par le nombre d'itération. On n'en tirera pas de conclusion définitive d'autant que la deuxième itération est souvent un peu plus longue que la premières, les développeurs se rendant compte d'un certains nombre d'erreurs dans la première (justement!). L'enseignement tiré de ces premières itérations permet ensuite d'affiner les suivantes, qui, pour le coup, seront plus courtes, moins complexes, mieux maîtrisées et s'appuieront sur des fonctionnalités déjà évaluées par le client. 30

Méthodologie de développement rapide (RAD) CASE*Method a également évolué. Grâce à l expérience terrain des projets qui utilisaient CASE*Method, les pratiques se sont enrichies avec l utilisation des outils de l AGL Oracle qui facilitaient le prototypage et la génération rapide de maquettes en début de projet. Dés 1994 la méthodologie Oracle abandonnait la démarche en cascade (waterfall) au profit d une démarche plus pragmatique : RAD Fast-Trask. Cette démarche méthodologique utilisait notamment l approche Itérative ainsi que les «timeboxe» notions que l on retrouve dans d autres méthodes comme DSDM. Définition d un timeboxe (manuel DSDM V3 en ligne : «http://www.dsdmfrance.com/doc/manuelv3») Parmi les différentes définitions du terme «timeboxe», il en est une qui s impose, c est «le temps écoulé entre la date de début et la date de fin du projet». La date de fin est fixe ; c est la date de livraison du système (ou d une partie de celui-ci). En jargon DSDM, on parle de timeboxe globale. DSDM a étendu le concept de timeboxe en créant des timeboxes de bas niveau pour chaque développement incrémental, fixant ainsi une série de dates de livraison (intermédiaire ou finale) pour le produit. Evolution des outils AGL Fast-Track a induit des évolutions sur l outil AGL d Oracle, en particulier sur les fonctions de «reverse engineering». Cependant, 1994 a vu apparaître un autre projet interne de refonte complète de l AGL d Oracle qui semble-t-il devait s appuyer sur une technologie Microsoft. Ce projet faisait fausse route et a été arrêté du jour au lendemain. Néanmoins, cela a du retarder considérablement l évolution de l AGL Oracle que l on a vu ré-apparaître sous le nom Designer 2000 (bien avant l an 2000) dans l environnement Windows uniquement. Les outils CASE d Oracle fonctionnaient auparavant principalement sur des stations de travail Unix (en particulier SUN) dans un environnement X11 pour CASE*Designer. La dernière évolution majeure qui adapte le produit à une démarche méthodologique itérative est la gestion de version. L outil de «versioning» est très sophistiqué et implémente les standards modernes du marché en la matière. Chaque utilisateur peut posséder un espace de travail qui lui est propre et maquetter ou prototyper différents éléments d une ou plusieurs itérations d un projet sans pour autant empiéter sur un espace de travail qui ne lui est pas affecté. Le moteur de «versioning» autorise la fusion des travaux communs provenant d espaces de travail différents. 31

Rapid Application Development Aujourd'hui, de nombreuses organisations de développement adoptent des méthodologies de développement itératifs soulignés par le développement rapide d'applications (RAD) des cycles. Contrairement à des cycles de vie de développement de cascade, où le dépistage se fait à la fin du projet, les cycles de vie itératifs précisent tester à plusieurs points au cours du développement. Il est facile de comprendre l'importance d'inclure l'analyse de la performance du système et le réglage prédictif dans le processus. Identifier les flux d'adressage précoce, en particulier les limitations de performance, a comme avantage des réductions de coût pour les corriger et en même temps minimise l'impact sur le calendrier du projet. RAD a été prouvé être une stratégie de logiciels utiles. Introduction Rapid Application Development (RAD) est une nouvelle approche des systèmes hautement interactifs, de développement qui a émergé dans les années 1990. RAD est un concept où les produits peuvent être développés plus rapidement et de meilleure qualité. En outre RAD tente de répondre à deux faiblesses des méthodologies structurées de développement, qui sont: les temps de développement long et la difficulté à comprendre un système de description sur papier. La méthodologie RAD a adapté les phases du cycle de vie du développement des systèmes (SDLC) pour obtenir une partie du système développé rapidement et dans les mains des utilisateurs. Comment utiliser RAD La plupart des méthodes de RAD recommandent que les analystes utilisent des techniques spéciales et des outils informatiques pour accélérer l'analyse, la conception et les phases de mise en œuvre, tels que les outils CASE (Computer-Aided Software Engineering), des sessions JAD (Joint Application Design), des langages de programmation de quatrième génération / visuel qui simplifient la vitesse de programmation (par exemple, Visual Basic), et des générateurs de code qui produisent automatiquement des programmes à partir de spécifications de design. C'est la combinaison des phases SDLC changé et l'utilisation de ces outils et des techniques qui améliore la vitesse et la qualité du développement des systèmes. Ils ont des méthologies orientées processus, orientées données et orientées objet qui suivent les approches de base RAD. Deux méthodes communes de RAD sont les phases de développement et de prototypage. 32

Étapes de RAD Le chemin de développement rapide d'application peut être adaptée à différents outils CASE et les environnements de développement. Cette section décrit brièvement les quatre étapes de la RAD. Planification des besoins L'étape Exigences de planification consiste en un examen des zones immédiatement associées au système proposé. Cet examen donne une définition large des exigences du système en termes de fonctions supporté par le système. Les livrables de la planification des besoins en scène incluent un modèle de zone de système de lignes (modèles d'entités et processus) de la zone d'étude, une définition de la portée du système, et une justification des coûts pour le nouveau système. Conception de l'utilisateur La phase de conception de l'utilisateur consiste en une analyse détaillée des activités commerciales liées au système proposé. Les principaux utilisateurs, répondre à des ateliers, se décomposent fonctions de l'entreprise et de définir les types d'entités associés au système. Ils complètent l'analyse par la création de diagrammes d'action définissant les interactions entre les processus et les données. Suite à l'analyse, la conception de ce système est décrite. Les procédures système sont conçus, et les plans préliminaires d'écrans sont développés. Des prototypes de procédures critiques sont construits et examinés. Un plan de mise en œuvre du système est préparé. Construction Dans la phase de construction, une petite équipe de développeurs, en travaillant directement avec les utilisateurs, finalise la conception et construit le système. Le processus de construction du logiciel se compose d'une série de mesures «conception construction» dans lequel les utilisateurs ont la possibilité d'affiner les besoins et examiner l'application de logiciel en résultant. Cette étape comprend également la préparation pour le parterre de coupe à la production. En plus du logiciel testé, livrables en scène construction incluent la documentation et les instructions nécessaires pour faire fonctionner la nouvelle application, et des routines et des procédures nécessaires à la mise en service du système [7]. Exécution La phase de mise en œuvre implique la mise en œuvre du nouveau système et la gestion du changement de l'environnement de l'ancien système vers le nouveau. Il peut s'agir de la mise en œuvre des passerelles entre les systèmes existants et nouveaux, la conversion des données, et la formation des utilisateurs. L'acceptation de l'utilisateur est le point de la phase de mise en œuvre [7] de fin. 33

Avantages de RAD Tout d'abord RAD est conçu pour aider à fournir les systèmes de minimiser plus rapidement avec le coût et la qualité assurés. Les livrables sont parfois plus faciles à porter, car ils font une plus grande utilisation de l'abstraction de haut niveau, des scripts et de code intermédiaire. En outre, le développement est mené à un niveau d'abstraction plus élevé parce que les outils RAD fonctionnent à ce niveau. RAD offre à ses utilisateurs une visibilité précoce en raison de prototypage, une plus grande flexibilité, car les développeurs peuvent repenser à volonté, et la réduction du codage manuel en raison des magiciens, des générateurs de code, la réutilisation du code. En outre, RAD tend à raccourcir les cycles de développement et de minimiser les défauts parce que les outils CASE peuvent générer beaucoup de code ou d'autres applications préconçus. Inconvénients de RAD D'autre part, RAD pourrait causer des problèmes adéquates. Le coût de l'ensemble des outils et matériel intégré couvre une quantité suffisante d'argent. Il pourrait être plus difficile de mesurer les progrès accomplis car il n'y a pas de jalons classiques, ou pourrait moins efficace parce que le code n'est pas conçu à la main. En outre, il ya la possibilité de la perte de précision scientifique, car aucune des méthodes formelles sont utilisées, ou peuvent accidentellement habiliter un retour aux pratiques incontrôlées des premiers jours de développement de logiciels. Il ya aussi le danger les exigences peuvent ne pas converger parce que les intérêts des clients peuvent diverger d'une itération à l'autre Risque de développement rapide: La nature du danger Développement rapide d'applications de plus en plus essentielle à la survie de l'entreprise. Il existe, cependant, un risque inhérent à développement rapide. Les entreprises sont souvent tentés d'utiliser des techniques de RAD pour construire des systèmes autonomes pour résoudre un problème particulier de l'isolement. De tels systèmes si elles répondent aux besoins des utilisateurs, ils deviennent institutionnalisée. Si l'entreprise et s'appuie beaucoup de ces systèmes isolés à résoudre des problèmes particuliers, le résultat est une grande masse, indiscipliné d'applications qui ne fonctionnent pas ensemble. Dans la pratique, la plupart des applications d'entreprise sont étroitement liées à d'autres applications et bases de données de partager avec eux, ce qui rend une infrastructure commune essentielle. En outre, les systèmes informatiques grandissent, ils deviennent encore plus complexes, et ces systèmes sont difficiles à changer, sauf si elles ont été créées au sein d'architectures habilement conçues qui permettent une seule pièce à changer sans changer les autres pièces. Par conséquent, la solution à tout problème est de développer un ensemble soigneusement planifiée des architectures. L'approche qui développe des systèmes dans un environnement architectural est connu comme "l'ingénierie de l'information». 34

Les outils CASE Chaque fois qu'un nouveau système est installé, la mise en œuvre intègre un certain nombre de tâches connexes et différentes. tâches. Le processus doit être bien organisée et c'est pour cette raison que les outils CASE se sont développés. Avec l'aide de CASE, le processus d'installation peut être automatisé et coordonné dans le cycle de vie du système élaboré et adopté. Les Outils CASE sont les outils de génie logiciel qui permettent le développement collaboratif de logiciels et la maintenance. Presque toutes les phases du cycle de vie du logiciel de développement sont supportés comme l'analyse; conception y compris les activités de coordination telles que la gestion de projet, la configuration, la gestion. En général, les méthodes de développement de logiciels standard tels que la structure de programmation Jackson ou l'analyse de système structuré et méthode de conception sont également pris en charge par les outils CASE. Les Outils CASE peuvent soutenir les étapes de développement suivantes pour le développement de l'application de base de données: La création d'un flux de données et des modèles d'entités Établir une relation entre les exigences et les modèles Elaboration du design de haut niveau Développement de description fonctionnelle et processus Développement de cas de test. Pourquoi développer des outils CASE? Les Outils CASE sont conçus pour améliorer et mettre à niveau le système informatique adopté et utilisé. c'est très important en ce qui concerne la dépendance à l'égard d'un environnement informatique pour les entreprises et / ou activités personnelles. Il est une partie intégrante des diverses stratégies de croissance des entreprises. Les outils CASE sont mis au point pour les raisons suivantes: installation rapide. Gain de temps en réduisant le codage et la durée des tests. techniques graphiques enrichies et flux de données Utilisation optimale de l'information disponible. Analyse et développement de conception améliorée. Création et manipulation des documents. Transfert des informations entre les outils de manière efficace. Rapidité pendant le développement du système. 35

Comment l'organisation utilise les outils CASE? Les outils CASE joue un rôle majeur dans les activités suivantes : Gestion de projet Dictionnaire de données Génération de code Conception d'interface graphique Génération de schéma Création de métadonnées pour datawarehouse Reverse engineering Génération de documentation Contrôle de version Analyse orientée objet et conception Test logiciel Modélisation des données Planification de projet Estimation des coûts Fondamentalement, les outils CASE sont utilisés pour : Réduire le coût car ils automatisent de nombreuses tâches manuelles répétitives. Réduire le temps de développement du projet car ils supportent la standardisation et évitent la répétition et réutilisation. Développer des projets complexes de qualité car ils offrent une plus grande cohérence et coordination. Créer une documentation de qualité. Créer des systèmes qui sont maintenable car la maîtrise du contrôle de configuration qui supporte les besoins de traçabilité. 36

Catégories de outils CASE : Les outils CASE sont parfois classés dans les catégories suivantes en raison de leurs activités : Outils CASE de niveau supérieur : Ils supportent l'analyse et la phase de conception. Ils comprennent des outils pour l'analyse de modélisation, des rapports et génération de formulaires. Outils CASE de niveau inférieur : Ils supportent la phase de codage, la gestion de configuration Outils CASE intégrés: Connus comme I-CASE qui prennent également en charge l'analyse, la conception et les phases de codage. 37

Caractéristiques des outils CASE Les outils CASE doivent avoir les caractéristiques suivantes afin d'être utilisés de manière efficace: Une méthodologie standard: Les outils CASE doivent supporter une méthodologie de développement logiciel et des techniques modélisation standard. Dans le scénario actuel la plupart des outils CASE se dirigent vers UML. Flexibilité: la flexibilité dans l'utilisation des éditeurs et autres outils. Les outils CASE doivent offrir une flexibilité et le choix à l'utilisateur des environnements de développement des éditeurs. Intégration forte: Les outils CASE doivent être intégrés pour supporter toutes les phases. Ceci implique que, si un changement est effectué à n'importe quel stade, par exemple, dans le modèle, il doit se refléter dans la documentation du code et tous les autres documents liés à la conception, pour offrir ainsi une cohésion dans l'environnement pour le développement de logiciels. Intégration avec le logiciel de test: Les outils CASE doivent fournir des interfaces pour des outils automatiques de test qui prennent soin des régressions et d'autres types de logiciels de test dans le cadre du changement des exigences. Soutien à l'ingénierie inverse (Reverse engineering) : : Les outils CASE doivent être en mesure de générer des modèles complexes depuis tout le code déjà généré. Aide en ligne: Les outils CASE fournissent un tutoriel en ligne. 38

Avantages et inconvénients des outils CASE Avantages Produit un système avec un cycle de vie opérationnel plus efficace Produit un système correspondant étroitement aux besoins et exigences des utilisateurs Produit un système avec une excellente documentation Produit un système avec moins de support système Produit un système plus flexible Inconvénients Produit un système initial plus couteux à construire et à maintenir Nécessite des définitions plus importantes et précises des besoins et exigences utilisateurs Peut être difficile à personnaliser Nécessite la formation de l'équipe de maintenance Peut être difficile à utiliser avec un système existant 39

Evolution des outils CASE Oracle L arrivée de Designer 2K à introduit de nouvelles techniques de modélisation des processus (BPR Business Process Reengineering) avec l outil Process Modeler. Les outils de reverse engineering ont également évolués, il est maintenant possible d effectuer le «retrofit» jusqu au niveau conceptuel. Cette caractéristique est précieuse si l on utilise une méthodologie itérative car cela facilite le passage des fonctionnalités d une itération vers une autre plus évoluée ainsi que l intégration progressive des évolutions lorsque les besoins changent ou s affinent au fil du projet. Basée sur l approche itérative, Oracle à introduit une méthodologie de développement dénommée C.D.M (Custom Developement Method) qui regroupe un certain nombre de règles et de «best practices» élaborées par l entité conseil d Oracle. Cette méthodologie est vendue en supplément du produit Designer dans le kit de développement rapide «idevelopment Accelerator Suite» qui inclus également Headstart : un ensemble de bibliothèques PL/SQL et de modèles (templates) pour notamment FORM & REPORT. 40

Application de la méthodologie avec l outil Oracle Designer Les 7 phases du cycle de vie de CASE*Method sont mises en application avec l outil Designer comme le montre la diapositive : Le niveau Conceptuel qui regroupe les phases Strategy et Analysis utilise les outils Process Modeler, Data flow Diagrammer, Function Hierarchy Diagrammer et Entity Relationship Diagrammer. Les phases Design, Build du niveau Développement sont appliquées principalement avec Design Editor et la Documentation utilisateur peut être produite via l outil Repository Report. Le niveau Déploiement des phases Transition et Production utilise également Design Editor et éventuellement les outils de modélisation lors des opérations de maintenance ou de «reverse engineering». 41

42