Objecteering/UML Version 5.3.0 SP3 : Readme

Objecteering/UML Version 5.3.0 SP3 : Readme

1. INTRODUCTION... 4 2. INSTALLATION D'OBJECTEERING/UML... 5 2.1. CONFIGURATION NECESSAIRE... 5 2.2. PRE-REQUIS POUR L'UTILISATION DES DIFFERENTS MODULES... 5 2.3. PROCEDURE D'INSTALLATION... 7 2.4. PROCEDURE DE MISE A JOUR... 8 2.4.1. Migration sans le module "Multi-user"... 9 2.4.2. Migration avec le module "Multi-user"... 9 2.4.3. Migration avec le module "Requirements"...10 2.5. REPERTOIRES D'OBJECTEERING/UML APRES L'INSTALLATION...11 2.6. SIGNALISATION D'ANOMALIES A OBJECTEERING SOFTWARE...12 3. UTILISATION D'OBJECTEERING/UML...13 3.1. LANCEMENT D'OBJECTEERING/UML SOUS WINDOWS NT/2000/XP...13 3.2. LANCEMENT D'OBJECTEERING/UML SOUS UNIX...13 3.3. DROITS D ACCES SUR LE SERVEUR...13 3.4. MODULES DISPONIBLES...15 4. SPECIFICITES PLATES-FORMES UNIX...16 5. INFORMATIONS SUPPLEMENTAIRES...17 5.1. PRECAUTIONS D'USAGE...17 5.2. RESTRICTIONS ET ANOMALIES CONNUES...18 5.2.1. Installation...18 5.2.2. Services sous Windows NT...18 5.2.3. Utilisation des bases de démonstration...18 5.2.4. Récupération des bases Personal Edition en Enterprise Edition...18 5.2.5. UML Profile Builder...18 5.2.6. L'outil Objecteering/UML...19 5.2.7. UML Modeler...19 5.2.8. Import...20 5.2.9. Recherche...20 5.2.10. Diff/Merge...20 5.2.11. CMS...20 5.2.12. Objecteering/PVCS Dimensions...21 5.2.13. Objecteering/SCC...21 5.2.14. Nouvelles balises pour la génération de code C++ et Java...21 5.2.15. Objecteering/Documentation...22 5.2.16. Flux de données...22 5.2.17. Objecteering/C++ Developer...22 5.2.18. Objecteering/C# Developer...23 5.2.19. Objecteering/Java Developer...23 5.2.20. Objecteering/Java Developer et Diff/Merge...24 5.2.21. Objecteering/Java Developer et Multi-User...24 5.2.22. Objecteering/EJB...25 5.2.23. Objecteering/Design Patterns for Java/C++...25 5.2.24. Objecteering/XMI...26 5.2.25. Objecteering/Requirements...27

5.2.26. Notes...28 5.2.27. J...28 6. ANNEXE : LISTE DES PATCHS SOLARIS UTILISES...29 6.1. PATCHS SUN SOLARIS 2.6...29 6.2. PATCHS SUN SOLARIS 7...29 6.3. PATCHS SUN SOLARIS 8...29 6.4. PATCHS SUN SOLARIS 9...30

1. Introduction Ce fichier vous fournit toutes les informations nécessaires pour votre prise en main de l'outil Objecteering/UML. Il ne remplace pas la documentation utilisateur livrée avec Objecteering/UML, mais apporte des informations importantes pour vous aider à démarrer vos travaux avec l'outil. Il vous est fortement recommandé de lire ce fichier avant de commencer à travailler avec Objecteering/UML.

2. Installation d'objecteering/uml 2.1. Configuration nécessaire Objecteering/UML a été testé sur les plates-formes suivantes : Windows NT4 SP6 (x86) Windows 2000 SP4 (x86) Windows XP SP1/SP2 (x86) Windows Server2003 (x86) (serveur uniquement) Solaris 2.6, 7, 8 et 9 (SPARC) (patchs deployés) (serveur uniquement) Linux Red Hat 9 (x86) Linux SuSE 9.2 (x86) Objecteering/Eclipse a été testé avec les versions d Eclipse suivantes : Eclipse 2 WSAD 5 Eclipse 3.0.1 Eclipse 3.0.2 La configuration minimum pour des modèles UML de petite taille (~10Mo) est la suivante : Pentium IV 1 Ghz 512 Mo de mémoire 300 Mo de disque dur La configuration recommandée pour des modèles UML de taille importante est la suivante : Pentium IV 1 Ghz 2 Go de mémoire 600 Mo de disque dur 2.2. Pré-requis pour l'utilisation des différents modules Objecteering/PVCS Dimensions nécessite l'application suivante : o Serena Dimensions 8.0.1.3 Objecteering/SCC nécessite une des applications suivantes : o PVCS Version Manager 6.8.1 o Microsoft Visual Source Safe 6.0 Objecteering/ClearCase nécessite l'application suivante : o Rational ClearCase 2003 Objecteering/CMSynergy nécessite l'application suivante : o Telelogic CMSynergy 6.3 Objecteering/C# Developer nécessite les applications suivantes : o Microsoft.NET Framework 1.1

o Microsoft Visual Studio.NET Professional 2003 Objecteering/C++ Developer nécessite l'application suivante : o Java Runtime Environment 1.4 ou supérieur (http://java.sun.com/) Objecteering/Java Developer nécessite l'application suivante : o J2SE Development Kit (La version 5 est conseillée pour tirer parti des dernières ameliorations du module). Objecteering/DOORS nécessite l'application suivante : o Telelogic Doors 7.1

2.3. Procédure d'installation Il est maintenant possible d'utiliser des noms de répertoire contenant des blancs lors de l'installation. Lors de l'installation d'un serveur Objecteering/UML, vous pouvez choisir d'installer un serveur Objecteering/UML (sans FLEXlm) et/ou un serveur FLEXlm. Lors de l'installation d'un client lourd, vous pouvez sélectionner les modules que vous souhaitez charger sur votre machine. Pour installer la configuration d'objecteering/uml qui correspond à vos besoins, veuillez vous reporter au chapitre "Installation d'objecteering/uml" dans le manuel utilisateur "Introduction" et suivre des étapes correspondant à l'installation de la configuration de votre choix (mono-poste, client/serveur, PC/UNIX...). Conseils supplémentaires concernant l'installation d'objecteering/uml sous Windows : Dans une installation typique, l'utilisateur peut choisir d'installer ou non l'aide en-ligne. Si l'utilisateur décide d'installer cette aide, elle sera automatiquement disponible après l'installation. Si l'utilisateur décide de ne pas l'installer, il pourra l'installer ultérieurement. Dans ce cas pour installer l'aide en-ligne, il suffira de double-cliquer sur "Uninstall", de sélectionner "Modify" et enfin de cocher la case "Documentation". Conseils supplémentaires concernant l'installation d'objecteering/uml sur le serveur : Le répertoire d'installation sur le réseau peut être précisé en utilisant un chemin UNC ou bien une lettre de lecteur réseau monté. Si vous choisissez la deuxième méthode, le lecteur réseau doit être monté avant de lancer l'installation. Une fois l'installation complète, deux nouveaux services sont déclarés dans Windows NT. Par défaut, ces services sont de type "automatique". Vous devez laisser ces services à "automatique", pour qu'ils continuent à fonctionner, sans qu'il y ait une session ouverte. Dans le cas contraire, les clients ne pourront pas accéder au serveur. Le fichier "services" contient une ligne du type : objing 15001/tcp Windows : Lors de la mise à jour d'un site Objecteering/UML, il n'est pas nécessaire de "redémarrer" le serveur NT. Dans d'autres situations, le serveur doit être redémarré, pour que ce nouveau service soit pris en compte. L'opération de déploiement de modules peut prendre du temps. Vous devez laisser la procédure d'installation se terminer, afin de disposer d'une installation Objecteering/UML complète. AVERTISSEMENT : TOUS LES CLIENTS DOIVENT UTILISER LE MEME CHEMIN DU SERVEUR SUR LE RESEAU.

Conseils supplémentaires concernant l'installation d'objecteering/uml sur des postes clients : Il est possible d'installer des postes clients en utilisant un lecteur réseau "monté" ou bien des noms UNC. Si vous utilisez un lecteur réseau "monté", vous devez suivre les étapes décrites ci-dessous : Avant de lancer la procédure d'installation, montez un lecteur réseau qui pointe vers le répertoire d'installation d'objecteering/umlsur le serveur. Avertissement : tous les clients doivent saisir la même lettre pour le lecteur réseau (par exemple, O:\). Lancez la procédure d'installation et sélectionnez le lecteur saisi comme répertoire de destination. Le fichier "services" contient une nouvelle ligne du type : objing 15001/tcp Windows : Lors de la mise à jour d'un site Objecteering/UML, il n'est pas nécessaire de redémarrer le serveur NT. Dans d'autres situations, le PC doit être redémarré, pour que ce nouveau service soit pris en compte. Pour compléter l'installation : Editez la variable system 'PATH' et ajoutez-y le chemin "OBJING_LOCAL_PATH\bin". Exemple : Dans le cas où Objecteering/UML a été installé dans le repertoire "C:\Program Files\Objecteering", la variable "PATH" doit être de la forme : "%SystemRoot%;%SystemRoot%\system32;C:\Program Files\Objecteering\bin;..." 2.4. Procédure de mise à jour La procédure d'installation détecte qu'objecteering/uml a déjà été installé, et vous propose de mettre à jour votre installation. Lorsque la fenêtre de sélection des modules s'affiche, assurez-vous que les modules qui sont à mettre à jour ont été correctement sélectionnés. Pendant la procédure d'installation, un écran indique quelles sont les bases existantes que vous pouvez migrer. Une fois déclarées, des bases sont proposées pour migration à la fin de la procédure d'installation. Il n'est plus nécessaire de migrer des bases Objecteering/UML développées avec des versions antérieures d'objecteering/uml. Les opérations de migration de bases sont automatiquement lancées la première fois qu'objecteering/uml est utilisé. Pour utiliser cette nouvelle version d'objecteering/uml, vous devez disposer d'un nouveau fichier de licence. IMPORTANT : Une version particulière ne peut pas être mise à jour par une autre version. Par exemple, une Personal Edition ne peut pas être mise à jour par une Enterprise Edition ou une Professional Edition ou vice versa. Si deux fichiers de licence sont présents, Objecteering/UML ne fonctionnera pas.

Les licences sont spécifiques à une plate-forme. Autrement dit, une licence pour Windows n'est pas valable pour une plate-forme SOLARIS ou LINUX. Lors de la migration des bases sur les postes clients, et avant de commencer la procédure de migration, vous devez déplacer la base "ObjecteeringModules" dans un répertoire qui est accessible à partir du poste client, en utilisant la commande "baseadm move". Une fois les bases migrées à la version 5.3.0, il ne faut pas essayer de les migrer vers d'autres versions antérieures, ceci pourrait les corrompre. La mise à jour des bases peut prendre du temps. Par exemple, la mise à jour d'une base (un fichier base.ofp de 70 Mo à peu près) contenant plusieurs modules Objecteering/UML et environ 10000 éléments dure quatre minutes sur une machine P4 1.5 GHz sous Microsoft Windows 2000 avec 1Go de mémoire. 2.4.1. Migration sans le module "Multi-user" Pour les bases issues d une version Objecteering/UML inférieure à la 5.3.0, la migration de celles-ci se fait automatiquement à leur ouverture. 2.4.2. Migration avec le module "Multi-user" 2.4.2.1 Depuis une version 5.2.x ou supérieure Pour l utilisateur en charge de la migration du référentiel MU, celle-ci s'effectue automatiquement en sélectionnant les modules AdministrationMultiUser et Multiuser à la nouvelle version. Pour les autres utilisateurs, et une fois le référentiel MU migré, il leur suffit : de migrer leur base (simplement en les ouvrant avec la version à jour d Objecteering) d installer le module MU de la version utilisée pour la migration du référentiel reprendre leur activité normalement 2.4.2.2 Depuis une version 5.1 ou inférieure Pour l utilisateur en charge de la migration du référentiel MU, celle-ci doit être réalisée en respectant la séquence suivante : 1. Mettez à jour le référentiel. Pour chaque base utilisateur, faites un check-in des éléments qui ont été réservés (check-out). Cette opération sert à regrouper des mises à jour au sein du référentiel. 2. Supprimez les références de votre base Objecteering/UML, en désélectionnant le module "Multi-user" ou "SharedProject" dans la fenêtre de sélection des modules. En mode administration des bases de données, lancez la commande "Uninstall" pour le module "Multi-user" => Les étapes 1 et 2 doivent être lancées pour chacune de vos bases. 3. Arrêtez les services nécessaires à Objecteering/UML : "FlexLM Manager" et "FPServer". 4. Lancez la procédure d'installation d'objecteering/uml 5.3.0. 5. Supprimez tous les fichiers placés dans votre référentiel "Multi-user". 6. Ouvrez votre base pour migrer votre modèle.

7. Sélectionnez le module "Multi-user" et confirmez. Si vous souhaitez utiliser la dernière version du module "Multi-user", vérifiez qu'elle est bien installée. 8. Définissez des paramètres nécessaires à la publication initiale dans le référentiel "Multiuser". (Attention : ce traitement peut prendre du temps, selon la taille de la base en question) => après ces opérations, le référentiel est opérationnel et peut être partagé avec d'autres utilisateurs. 9. Mettez à jour les sites Objecteering/UML sur des machines clients. Il est préférable de créer de nouvelles bases et de recharger le modèle à partir du référentiel qui a été mis à jour à la fin de l'étape 8. Note : Si vous avez des problèmes de migration, veuillez noter qu'un fichier.save est généré. Il convient de ne pas détruire ce fichier, il peut être utilisé pour restaurer votre base dans l'état précédant le début des opérations de migration. Pour les autres utilisateurs, et une fois le référentiel Multi-user migré, il leur suffit : Créer une nouvelle base avec la version à jour d Objecteering/UML Installer le module Multi-user à jour et se connecter au référentiel Multi-user migré 2.4.3. Migration avec le module "Requirements" Les exigences créées avec les anciens modules requirements (accompagnant les versions 5.2.2 et 5.2.3 d Objecteering/UML) nécessitent une phase de migration pour pouvoir être manipulés avec les nouveaux modules et Objecteering/UML. Pour la migration de vos anciennes exigences, merci de contacter le support d Objecteering Software (une simple migration des bases ou un import de projet d une ancienne base migrée vers une nouvelle ne suffiront pas). NB : Ceci ne vous concerne pas si vous avez utilisé les modules "RequirementsManager" et RequirementsAdmin" d Objecteering/UML 5.3.0 qui ont remplacé les modules "Requirement" et "ReqPropertiesAdmin".

2.5. Répertoires d'objecteering/uml après l'installation L'installation d'objecteering/uml 5.3.0 définit une arborescence dont la racine correspond aux variables d'environnement OBJING_PATH, OBJING_LOCAL_PATH et OBJING_SERV_PATH. La variable d'environnement OBJING_PATH correspond au chemin d'accès aux ressources, la variable d'environnement OBJING_LOCAL_PATH correspond au chemin d'accès aux ressources locales et la variable d'environnement OBJING_SERV_PATH correspond au chemin d'accès au serveur. Le répertoire OBJING_LOCAL_PATH contient les sous-répertoires suivants : bin Contient des binaires des outils. Inclut objing, baseadm, bundle Contient les outils tierces utilisés par Objecteering/UML. res Contient le fichier version.ifo. site Contient le fichier site.ifo. tpf Contient les fichiers nécessaires à la génération de la documentation. user (Uniquement UNIX) Contient des scripts utilisés pour initialiser l'environnement. work Peut contenir des bases utilisateurs. Le répertoire OBJING_SERV_PATH contient les sous-répertoires suivants : database Contient le fichier site.ofp (la base site). site Contient le fichier de licence Objecteering/UML et la liste de fichiers modules. res Contient le fichier de modules XML. Le répertoire OBJING_PATH contient les sous-répertoires suivants : database gencxx help macros modules res Contient les bases sources (bases, modules, ). Contient les fichiers nécessaires à l'utilisation du module Cxx et de la LibO. Contient l'aide en-ligne d'objecteering/uml (fichiers au format html). Répertoire par défaut pour les fichiers macro. Contient les différents fichiers nécessaires au bon fonctionnement des modules livrés. Contient les fichiers de ressources nécessaires au bon fonctionnement d'objecteering/uml. update Contient les données permettant la migration d'anciennes bases Objecteering/UML à la version 5.3.0. template Contient un certain nombre de types de modèle UML, qui servent à faciliter la création de nouveaux projets de modélisation UML avec certains modules déjà

installés. Le fichier "install.dat" positionné dans le répertoire $OBJING_LOCAL_PATH/site contient des informations sur la version d'objecteering/uml installée sur votre site. 2.6. Signalisation d'anomalies à Objecteering Software Lorsque vous signalez des anomalies à Objecteering Software, n'oubliez pas de préciser des informations suivantes : votre plate-forme, votre système d'exploitation et la version que vous utilisez, votre configuration Objecteering/UML (Client/Serveur ou Monoposte), le type de poste sur lequel l'anomalie a été détectée (Serveur, Client, Monoposte), la configuration d'objecteering/uml (fichier "install.dat" positionné dans le répertoire $OBJING_LOCAL_PATH/site), la description de votre anomalie. Vous devez envoyer ces informations à l'adresse email suivante : support@objecteering.com.

3. Utilisation d'objecteering/uml 3.1. Lancement d'objecteering/uml sous Windows NT/2000/XP SI LE SERVEUR N'EST PAS ACTIF et pour les installations client/serveur seulement, il faut préalablement lancer le serveur. Les services "Fpserver" et "FLEXlm Objecteering" sont déclarés dans l'item "Services" du panneau de configuration sur le serveur de bases Objecteering/UML. Pour de plus amples renseignements, veuillez vous reporter à la documentation ou à la section "Installation" dans ce fichier. 3.2. Lancement d'objecteering/uml sous UNIX SI LE SERVEUR N'EST PAS ACTIF et pour les installations client/serveur seulement, il faut préalablement lancer le serveur : Exécuter du script env.sh ou env.csh selon le shell (rep sh, bash ou csh) sous OBJING_LOCAL_PATH/user. Ex sh/bash:$../env.sh Ex csh:%source./env.csh Lancer les commandes "objingsrv" et "lmgrd c $OBJING_SERV_PATH/site". 3.3. Droits d accès sur le serveur Les utilisateurs d'objecteering/uml doivent disposer des droits d'accès en lecture et en écriture sur la base site (le fichier "database/site.ofp") et sur les répertoires suivants : database/modules help modules macros res/bmp res/xml site template work

Pour de plus amples renseignements, veuillez vous reporter au chapitre "Installation" dans le manuel utilisateur "Introduction". La "Prise en main" d'objecteering/uml est présentée dans le manuel utilisateur "Introduction".

3.4. Modules disponibles Les modules disponibles avec la version 5.3.0 SP3 d'objecteering/uml sont les suivants : ClearCaseModule (version 4.5.i) et ClearCaseAdministration, CMSynergyModule (version 4.5.g) et CMSynergyAdministration, CorbaModule (version 2.1.b), CorbaProfileModule (version 2.1.b), CsModule (version 1.3.f), CxxModule (version 5.2.g) (contient les modules "ReverseCxx" et "MFCModule"), DesignPatterns (version 1.3.b) (CppDesignPatterns, JavaDesignPatterns), DOORS (version 2.0.r), EJB (version 3.5.f), GenDocModule (version 4.8.a), JavaModule (version 3.5.f) (contient les modules "ReverseJava" et "JavaPatterns"), Macros (version 1.2), MetricsModule (version 2.1), MultiUser (version 4.5.g) et AdministrationMultiUser, PVCSDimensionModule (version 4.5.h) et PVCSDimensionAdmin, RequirementsManager (version 2.0.r) et RequirementsAdmin, ReverseCOM (version 1.1), RoseModelImport (version 1.4.d), SCCModule (version 4.5.g) et SCCAdministration, SQLDesigner (version 1.3) et SQLMigrationModule (version 1.3), TestsForJavaEJB (version 3.5.f), TypesEditor (version 1.3), UMLProfileForEJB (version 3.5.f), UMLProfileForSQL (version 1.3), UMLTestDesigner (version 3.5.f), VBModule (version 2.1), Wizards (version 1.3.c) (ProcessManager, AnalysisProfileModule, CodingProfileModule, DesignProfileModule, ProcessProfileModule, ExampleInstaller), XMI (version 2.2.f). Lors de l'installation du poste "Serveur" d'objecteering/uml, la base "demovendingmachine" est disponible dans le répertoire suivant : $OBJING_PATH/database.

4. Spécificités plates-formes Unix Sous Unix, la touche num-lock (verrouillage numérique) a un rôle de "modifier". Cela implique des différences de comportement dans Objecteering selon que la touche la touche Num-Lock soit activée ou non. Lorsque le Num_Lock est activé, les boites dockables ne peuvent être redimensionnées/déplacées et certains champs des éditeurs tabulaires ne sont plus éditables par double-click. La désactivation du Num_Lock réactive ces fonctionnalités. Objecteering/UML est sensible à la valeur de la variable LANG. Par défaut, lors de l'initialisation de l'environnement Objecteering/UML (fichiers env.sh ou env.csh), celle-ci est positionnée à la valeur "en_us". Sa modification peut entraîner certains problèmes d'affichage. Il est conseillé de régler le nombre de couleurs du serveur graphique X11 à 24 ou 32 bits par pixel.

5. Informations supplémentaires 5.1. Précautions d'usage Nous vous recommandons de procéder régulièrement à une archive des bases utilisées (y compris la base site!) Soit en sauvegardant les répertoires des bases ("baseadm -list" permet d'obtenir une liste des bases et leurs chemins d'accès), Soit en utilisant la commande "baseadm" qui permet de créer une base de sauvegarde à partir de la base de travail : baseadm -copy <base_a_sauvegarder> <nouveau_chemin_destination> <copier_nom_de_la_base> Si votre fichier "site.ifo" est verrouillé après l'échec d'une opération d'administration (par exemple, la création ou la suppression d'une base), il faut supprimer le répertoire "$OBJING_LOCAL_PATH/site/lksite". Si votre fichier "modules.xml" est verrouillé après l'échec d'une opération d'administration (par exemple, pendant une opération de "deliver"), il faut supprimer le répertoire "$OBJING_SERV_PATH/res/xml/lk_xml". Si la sauvegarde est interrompue (coupure de courant, problèmes de réseau ou de logiciel, ), il est possible de restaurer la dernière version stable de la base en utilisant l'option "baseadm - unlock" dans une session ligne de commande, ou en utilisant la commande "Unlock" dans le menu "Repair" dans une session interactive. Si la base site est corrompue, vous devez revenir à la dernière sauvegarde de toutes les bases (la base site et l'ensemble des autres bases).

5.2. Restrictions et anomalies connues 5.2.1. Installation Dans le cas d'une installation hétérogène (serveur Solaris/clients Windows), il est préférable d'installer un client lourd plutôt qu'un client léger, car certaines fonctionnalités ne seraient pas disponibles pour des clients légers. Les noms des répertoires ne doivent pas contenir des caractères accentués ou le caractère @. Lorsqu'une installation Objecteering/UML est migrée, dans la fenêtre de sélection de composants et/ou de sélection du type d'installation, l'espace nécessaire indiqué ne prend pas en compte l'espace utilisé par l'installation qui est à migrer. Ceci veut dire que l'installation ne pourra pas continuer s'il n'y a pas suffisamment d'espace libre. 5.2.2. Services sous Windows NT Dans une installation serveur, sous Windows NT/2000, le service "FLEXlm Objecteering" n'est pas toujours lancé à la fin de l'installation. Ceci provoque une erreur lors du lancement de "wobjing". Dans ce cas, le service "FLEXlm Objecteering" doit être lancé manuellement à partir de l'item "Services" dans le panneau de configuration. 5.2.3. Utilisation des bases de démonstration Afin d'éviter la création des doublons d'identifiants d'objets, il est fortement recommandé de ne jamais importer des objets créés directement dans des bases de démonstration, créées lors de l'installation de la version PC d'objecteering/uml. L'utilisation de l'outil d'administration avec les options "-copy" et "-get" vous permet de créer ou initialiser une base à partir des bases de démonstration. Pour les bases créées de cette façon, il n'y a pas de problème de doublons d'identifiants. Par exemple : baseadm -copy demo <nouveau_répertoire_base> demo_new, permet de créer une base qui contient initialement les données de la base de démonstration. 5.2.4. Récupération des bases Personal Edition en Enterprise Edition Dans la Enterprise Edition et la Professional Edition, si vous souhaitez récupérer une base Personal Edition ou Standard Edition, après avoir récupéré la base en question, vous devez lancer l'opération "Check a database's identifiers" avec l'action "Run the repair" sur la base récupérée. Ceci est très important, car si cette action n'est pas effectuée, les doublons d'identifiants peuvent être créés. 5.2.5. UML Profile Builder Nous vous recommandons d'utiliser des projets temporaires comme projets de test.

Sur des opérations "copy/paste" sur "SoMethod", l'opération "paste" s'effectue correctement, mais la suppression de l'élément initial ne s'effectue pas bien. Le résultat de cette opération est l'obtention de la même "SoMethod" deux fois. Si vous essayez d'en supprimer une, l'autre sera également supprimée. Cette opération ne doit donc pas être utilisée. Il est également recommandé de ne pas utiliser des guillemets dans des descriptions de module. La livraison d'un module sur un site peut poser problème si le champ de description du module contient des guillemets. Le nom de racine du projet UML Profile Builder n'est plus Objecteering_Site, mais plutôt le nom de la base. La racine du projet UML Profile Builder ne peut plus être renommée. Dans les versions antérieures, lors de l installation du module, sa méthode moduleinstall est automatiquement appelée, ainsi que ses modules parents. Désormais, la méthode moduleinstall est appelée uniquement sur le module concerné. Si le module redéfinit un autre module, il doit définir un point de vue d installation, et l appel de la méthode moduleinstall sur le module parent doit se faire alors explicitement si nécessaire. 5.2.6. L'outil Objecteering/UML En cas de fin anormale du programme Objecteering/UML, il est possible qu'un répertoire ModulesXML_Lock soit créé dans $OBJING_SERV_PATH/res/xml. Ce répertoire empêche la réouverture de l'outil et doit donc être supprimé (s'il existe), avant de relancer l'outil Objecteering/UML. Il existe une anomalie sur l'opération de suppression de modules dans l'outil d'administration des bases. La liste des modules n'est pas mise à jour lors d'un clic sur le bouton "Apply". Le module supprimé apparaît encore dans la liste, même lorsqu'il a été supprimé du site. Les types de modèle UML sont créés à partir des projets de modélisation UML, pour lesquels la case à cocher "Keep selection as default" a été cochée. Dans le cas contraire, des modules seront installés mais non sélectionnés. Le projet de modélisation UML ne doit pas contenir d'éléments de modèle. De toute façon, aucun élément de modèle ne serait récupéré pendant la création d'un nouveau type de modèle UML. 5.2.7. UML Modeler Les méthodes nommées "create" ou "delete ne sont plus des constructeurs ou des destructeurs. Pour cela, les stereotypes create ou destroy doivent leur être rajoutés. La fenêtre de modification a été améliorée et les méthodes isconstructor et isdestructor mises à jour. La macro "AddStereotypeCreateOrDestroy.jmf" livrée avec Objecteering/UML rajoute automatiquement ces stéréotypes aux méthodes (si les méthodes sont déjà stéréotypées, un message d'avertissement informe l'utilisateur que la méthode n'a pas été modifiée). La variable d'environnement OBJING_BINPATH a été renommée OBJING_LOCAL_PATH.

La commande "Select in model" disponible dans le menu contextuel d'un diagramme permet de sélectionner le diagramme dans l'onglet "Diagrams" de l'éditeur de propriétés et de sélectionner l'élément auquel est rattaché le diagramme dans l'explorateur. Si vous souhaitez avoir "$(GenRoot)" dans les produits de génération lors de leur création, vous devez définir "$$(GenRoot)" au niveau des paramètres de module. Si vous saisissez seulement "$(GenRoot)" au niveau des paramètres, la variable "$(GenRoot)" ne sera pas expansée dans le produit de génération. 5.2.8. Import Pour importer le même élément dans un projet plusieurs fois, il convient de faire une sauvegarde après chaque import. Si vous ne faites pas de sauvegarde, une erreur de doublon d'identifiant est renvoyée. Il existe un problème concernant l'import des contraintes. Pour pouvoir importer une contrainte entre plusieurs éléments de modèle, vous devez importer tous les éléments liés à la contrainte. Sinon, la contrainte n'est pas créée. De Multi-User, il est impossible de récupérer une contrainte entre deux classes dans des paquetages différents, car l'import se fait paquetage par paquetage. Pour contourner ce problème, faites un check-out sur les deux classes dans votre base et lancez un import (à travers la fenêtre ouverte par le menu "Tools/Import") des deux classes à la fois (sélection multiple). Il existe un problème concernant l'import des diagrammes de séquence. Les diagrammes de séquence peuvent perdre des informations après le déplacement des instances visualisées dans le diagramme, ou après des imports partiels. Il est impossible de mettre à jour le diagramme par import ou par Multi-user. 5.2.9. Recherche Les stéréotypes ne peuvent pas être recherchés par leur nom. 5.2.10. Diff/Merge 5.2.11. CMS Le nombre d'éléments dans la hiérarchie Diff/Merge ne peut excéder 65000. Il est fortement recommande de lancer des opérations Diff/Merge sur des souspaquetages plutôt que sur le paquetage racine du projet. Dans certains cas les déplacements d Instance et/ou de Node Instance peuvent provoquer un crash d Objecteering/UML. Sur une sélection multiple, la commande CMS ne traite que le premier élément de la sélection. Si le paramètre "Update generation work products before check-in du module Multiuser a été activé, le contenu des fichiers C++ ou Java modifiés en dehors d'objecteering/uml est récupéré lors des opérations de check-in, et le modèle est mis à jour. En ce qui concerne des fichiers C++, le paramètre "Take the following note as an operation comment" n'est pas utilisé, et les notes créées sont de type

"comment". Pour obtenir le type de note souhaité, la note "comment" du modèle doit être modifiée après avoir lancé un check-out de l'élément. Pourtant, il est préférable de créer la note avant la génération des fichiers C++. Pour pouvoir partager le référentiel, il faut cocher la case "UML model root name" lors de la création d'un nouveau projet de modélisation UML et préciser un nom de projet identique pour tous les utilisateurs. Sans ce nom de projet identique, il serait impossible de se connecter au même référentiel. Pour limiter des incohérences pendant la mise à jour du référentiel, le module Multiuser interdit l'accès simultané au référentiel par plusieurs utilisateurs. Malgré le fait que les caractères *? / \ : " < > et soient autorisés lors du nommage d'un projet au sein d'objecteering/uml, il n'est pas possible de les utiliser avec le module Multi-user. Ne pas lancer un import XMI depuis la racine du projet ceci gêne Multiuser. 5.2.12. Objecteering/PVCS Dimensions Suite à des restrictions du nombre de caractères dans les identifiants de PVCS/Merant Dimensions, les noms de login ne doivent plus excéder 12 caractères et les noms de projet 20 caractères. 5.2.13. Objecteering/SCC Dans le cadre du couplage Objecteering/SCC PVCSVM, le message d erreur suivant apparaît à la création du référentiel : Objecteering/SCC 4.5.a - Copyright 2000-2004 Objecteering Software Added: conf Created Project., 1 Added: v:\pvcs\vm\common\ide_database\work\projectname\conf\version.conf, 1 Saving selected modules list in the repository... Error: / ProjectName/conf/modulesList.conf: The entity (or entities) for "/ProjectName/conf/modulesList.conf" could not be loaded., 1 The entity (or entities) for "/ ProjectName/conf/modulesList.conf" could not be loaded., 1 Added: v:\pvcs\vm\common\ide_database\work\ ProjectName\conf\modulesList.conf, 1 done Cette erreur PVCSVM est sans conséquence sur la création du référentiel et peut donc être ignorée. Dans le cadre du couplage Objecteering/SCC PVCSVM, lors d un CheckOut, si le projet dispose de plusieurs "Promotion Groups" l utilisateur devra sélectionner le bon "Promotion Group" pour chaque élément importé. 5.2.14. Nouvelles balises pour la génération de code C++ et Java Les balises de génération Objecteering/UML peuvent rentrer en conflit dans certaines situations, avec des commentaires qui commencent par : o "//begin" o "//end" Ceci veut dire qu'il est impossible de transférer du code à partir des éditeurs externes ou en éditant du code. Pour rétablir le bon fonctionnement des modules en question, il faut simplement changer des commentaires.