1 / 28

BusinessCAM

BusinessCAM. Mars 2001. Plan de la présentation. 1. Objectif 2. Outils choisis 3. Fonctions de l’automate 4. Principes de BusinessCAM 5. Composants de l'automate 6. Application produite. Plan de la présentation. 7. Séquence de génération 8. Architecture modulaire

ramona-golden
Download Presentation

BusinessCAM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BusinessCAM Mars 2001

  2. Plan de la présentation • 1. Objectif • 2. Outils choisis • 3. Fonctions de l’automate • 4. Principes de BusinessCAM • 5. Composants de l'automate • 6. Application produite

  3. Plan de la présentation • 7. Séquence de génération • 8. Architecture modulaire • 9. Customisation de l'application • 10. Intégration de code spécifiques • 11. Limites et évolutions • 12. Projet réel

  4. 1. Objectif • L'objectif : Bâtir un outil proche d'un automate en partant de nos acquis métho/technologiques, permettant : • D’intégrer des personnes peu formées • D’accélérer le développement • De changer l'ensemble des éléments rapidement

  5. 1. Objectif • Comment ? • Un uppercase du marché • Support de la démarche méthodologique • Customisable et extensible (Repository) • Un lowercase du marché • Utilisable par des personnes peu formées • Participant à la production des applications • Réalisation d'un "module de commande" ayant les fonctions de pilotage et d'automate

  6. 2. Outils choisis • UpperCase choisi : Cool:Jex • Support de tous les modèles dynamiques d’UML • Méta modèle extensible • Système de gestion de versions intégré • Bonne tenue en charge avec des modèles lourds et complexes • Nécessitant peu d'adaptations pour satisfaire nos objectifs court terme

  7. 2. Outils choisis • LowerCase choisi : Versata • Outil industriel simple d’utilisation • Repository ouvert en XML • Génére dèjà une part du code côté client et serveur • Déploiement automatique avancé

  8. 3. Fonctions de l’automate • Automatismes à créer • Fonctions de CAO couvrant : • Les phases de conception fonctionnelle et technique • Les transformations entre modèles • Les itérations • Fonctions de FAO intégrant : • Versata et son repository • La génération du code • La base de données • Les transactions • Les différentes intégrités et les règles de gestion

  9. 3. Fonctions de l’automate • Limites prises en compte • Garder la maîtrise et permettre de faire intervenir des experts techniques (création d'un automate et non d'un système expert) • Rester indépendant des outils utilisés • Rester dans une fenêtre de temps compatible avec celle du projet • Le résultat : BusinessCAM

  10. Analyse et traduction Resitution Génération Output Input Connaissance Inférence 4. Principes de BusinessCAM

  11. Input 4. Principes de BusinessCAM • En input, toute forme de représentation des spécifications : • Diagrammes (UML, NIAM, merise, ...) • Composants logiciels existants (classes, code source, tables) • Connaissances importées (au format XML par exemple) • Langage naturel (texte, voix) • ...

  12. Connaissance 4. Principes de BusinessCAM • La connaissance est indépendante de la forme des Inputs et des Outputs. • Contenu : • La description des données • La description des actions • Les règles métier intégrant les règles de : • Les statistiques • calcul • transition • cardinalité • contrôle • action • présentation

  13. Output 4. Principes de BusinessCAM • En sortie, tout ce qui peut être produit à partir d’une connaissance existante : • Un rapport (document texte, diagramme, ...) • Des applications (Versata, Oracle OBC4J, Silverstream,Websphere, WAP,....) • Des requêtes (Cristal report, Style report, Business Objects univers, ...) • Des simulations de processus métiers

  14. 4. Principes de BusinessCAM Vue dynamique Vue statique Diagrammes de processus et/ou d’action Diagrammes de composants Input Input Moteur CAO Connaissance (actions) Connaissance (données) BusinessCAM BusinessCAM Interface graphique Tables relationnelles Objets règles de gestion Output Output

  15. 5. Composants de l’automate Cool:JEX Modélisation Métier : actions, processus Tech : Diag de classes, existant Diagrammes de processus (Activity diagram) Diagrammes d’actions (Statechart diagram) Diagrammes de composants (Class diagram) CAO Interprétation, contrôle Corrélation, déduction Génération de code Tech : spécifiques, Outils ergonomiques avancés, Interface externes Déploiement BusinessCAM Vue dynamique Vue statique FAO VERSATA SGBD Ecrans Objets & règles Persistence Structure des données (DDL) PRODUIT APPLICATION Présentation (Browser) Application (serveur VLS) Base de données (Oracle) Métier : Essais, recette

  16. Client N Client 2 Client 1 6. Application produite Serveur de base de données Serveur(s) de traitement Serveur(s) de présentation Browser SGBD/R Serveur de base de données Browser Serveur d’application VLS (Corba) Serveur HTTP SGBD/R Browser

  17. 7. Séquence de génération

  18. Diagrammes Diagrammes Diagrammes CoolJex d'action de processus de classe Lecture Lecture Lecture Génération 3 2 1 5 Généralisation 5 Générer un diagramme de composants ? Correlation Vue Vue Déduction statique dynamique 4 Générer la repository Versata ? Génération 6 BusinessCAM Génération 8 Modèle relationnel Repository Générer Versata le DDL ? (fichier XML) Génération 7 Génération Génération 10 9 DataObjects RelationShips QueryObjects Forms Fichiers (fichiers XML (fichiers XML (fichiers XML (fichiers XML) DDL et JAVA) et JAVA) et JAVA) Oracle Versata

  19. 8. Architecture modulaire • L’ensemble est évolutif • Composé de modules très fins (micro générateurs) • Chaque module prend des données en entrée et produit un résultat en sortie • A l’utilisation • L’utilisateur demande un résultat • L’automate retrouve les modules à utiliser et le séquencement nécessaire pour obtenir le résultat demandé (recherche d’itinéraire sur une carte)

  20. 9. Customisation de l'application • L’application obtenue n’est pas figée : • Les spécifications expriment un besoin • Le générateur s’appuie sur des templates • Les templates expriment la façon de traduire le besoin en composants logiciels. Ils permettent de maîtriser : • L’aspect • Les composants unitaires utilisés • Les assemblages à réaliser en fonction des cas rencontrés • La dynamique générale de l’application

  21. 9. Customisation de l'application • L’application obtenue n’est pas figée : • Il est possible de spécifier ses propres règles ergonomiques, et de créer ses propres composants techniques • L’automate construit alors l’application avec vos règles et vos composants techniques

  22. 10. Intégration de code spécifique • Le développeur peut prendre la main • L’automate génére du code • Un développeur peut ajouter des compléments ou modifier le code généré • Tout le temps que les modifications ne sont pas contraires aux spécifications et aux règles ergonomiques en place, l’automate intégrera puis préservera ces modifications lors des itérations suivantes • Le résultat est alors indépendant de l'automate : l'application peut même évoluer "à la mano"

  23. 10. Intégration de code spécifique • Exemples de code spécifique • Automatisation de séquences de saisie pour des cas types • Intégration d’outils tierces • Ajout de composants ergonomiques particuliers (planning, …) • …

  24. 11. Limites et évolutions • Limites fondamentales • Les composants ergonomiques trop spécifiques resteront du ressort des experts (tableaux multidimensionnels, arboresences, …) • Il n’est pas envisagé de couvrir les interface d’échange de donnèes avec des systèmes existants ou spécifiques • La reprise des données entre versions reste traditionnelle

  25. 11. Limites et évolutions • Limites temporaires • Intégration des applications existantes par les modèles de classe : Pas de reverse engineering • Pas de gestion de Workflow : La totalité des informations des diagrammes de processus n’est pas exploitée (automatisation des transitions entre les étapes d’un processus) • Pas de génération d’états à l’intérieur des applications • Pas de génération des informations de sécurité (droits/profils)

  26. 11. Limites et évolutions • Evolutions : • Utilisation de l’option EJB de Versata • Génération de clients HTML • Intégration totale de la partie processus/workflow (VIS Versata) • Génération des états dans les applications

  27. 11. Limites et évolutions • Evolutions • Intégration d’autres cibles de génération : • Autres technologies semblables (Oracle OBC4J, SilverStream, Blaze, …) • Applications WAP • Technologies futures • Intégration d’autres uppercases : • Rose, TogetherJ, ObjectDomain, …

  28. 12. Projet réel • Une méga application • 1 an de délai maximum sans spécialistes "New Tech" • 300 Utilisateurs répartis dans toute la France (70 sites) • Un besoin qui doit pouvoir être remis en cause chaque année

More Related