Test intégré dans composants logiciels dérivés d'UML Franck Barbier

1. Test intégré dans composants logiciels dérivés d'UML Franck Barbier LORIA – QSL – J. Souquières – 27 mars 2003

2. Contexte • Component+ : 12 partenaires, 3M€, 2,5 années (www.component-plus.org) • Test intégré (Built-In Test) dans composants logiciels • « Commercial Off-The-Shelf (COTS) components » (www.iccbss.org)

3. Infrastructure de résultat de Component+

4. Component+, vision • « Contract testing » : basé état, niveau assemblage • « Quality of service testing » (e.g. « deadlock testing ») : temps réel, systèmes critiques, niveau assemblage • « COTS-based product testing » : « trustworthiness », acquisition

5. Instrumentation du processus d’acquistion

6. Test et composant sur étagère “The dominant software testing theories and methods are based upon “white box” testing that assumes the program code or other detailed representation of the software module to be available. (This is generally untrue of commercial, off-the-shelf (COTS) software and much legacy software.)” National Coordination Office for Information Technology Research and Development, January 2001. High Confidence Software and Systems Research Needs, available from: http://www.ccic.gov/iwg/hcss.html

7. UML 1.4 et composants logiciels « Component & Deployment Diagrams » • Niveau « implementation » • Pas de sémantique sinon que le métatype « Component » hérite de « Classifier » • Aucune dépendance formelle avec les autres types de modèles (Class Diagrams…) • Ambiguïté des relations entre composants, e.g. stéréotype « reside »

8. “Model checking versus testing”: un chemin étroit intermédiaire ? “For example, automated validation technology is needed that can consider “correct-by-construction” techniques (…) As one example, methods might be explored that are analogous to proof-carrying code for certifying software” National Coordination Office for Information Technology Research and Development, January 2001. High Confidence Software and Systems Research Needs, available from: http://www.ccic.gov/iwg/hcss.html

9. Hypothèses fortes • Mécanisme d’acquisition assis sur spécification -> UML • Intelligibilité, appréhension -> exécutabilité • Nouveau facteur déploiement -> configurabilité, test in-situ • Standards -> recherche de conformité

10. Composant sur étagère “A product that is • Sold, leased, or licensed to the general public • Offered by a vendor trying to profit it • Supported and evolved by the vendor, which retains theintellectual property rights • Available in multiple, identical copies • Used without internal modification by a consumer” Meyers & Oberndorf, 2001. Managing Software Acquistion – Open Systems and COTS Products, Addison-Wesley

11. Composant et environnements réflexifs Langages : Smalltalk, Python, Java (java.lang.reflect), C#? Infrastructures de composants : EJB, CCM, .NET? Intergiciels (« middleware ») réflexifs : priorité 6e programme cadre / TESSS, domaine de recherche « distributed systems »

12. Composant BIT

13. Librairie BIT/J

14. Java Management Extensions (JMX)

15. Scénario d’évolution: 1ère approche

16. 2e approche: ré-ingénierie

17. “Stack” Java (1/3)

18. “Stack” Java (2/3) // embedding of a common Java Stack instance: private java.util.Stack _stack = new java.util.Stack(); // states: protected BIT_state _Empty; protected BIT_state _Only_one; protected BIT_state _More_than_one; protected BIT_state _Not_empty; // state machine monitor: protected BIT_state_monitor _BIT_stack; private void init_behavior() throws Statechart_exception { _Empty = new BIT_state("Empty"); _Only_one = new BIT_state("Only one"); _More_than_one = new BIT_state("More than one"); // states are bound together: _Not_empty = (BIT_state)(_Only_one.xor(_More_than_one)).name("Not empty"); _BIT_stack = new BIT_state_monitor(_Empty.xor(_Not_empty),"BIT stack"); _Empty.inputState(); }

19. “Stack” Java (3/3) public Object push(Object item) throws Statechart_exception { Object result = _stack.push(item); // candidate transitions: _BIT_stack.fires(_Empty,_Only_one); _BIT_stack.fires(_Only_one,_More_than_one); _BIT_stack.fires(_More_than_one,_More_than_one); // interpretation cycle: _BIT_stack.used_up(); return result; }

20. 3e approche: nouvelle technique de conception, composant à forte granularité

21. Délimitation decomposant (1/2)

22. Délimitation de composant (2/2)

23. Organisation canonique

24. Exemple

25. Perspectives • Relations verticales (i.e. même nœud de déploiement) composant et « sous-composant » à couplage fort : agrégation et composition UML (contribution pour v. 2.0) • JMX « Relationship Service » : 1 Agent (« Management ») pour 1 « BIT Tout » + n « BIT Parties » • Composabilité de propriétés de qualité de service (France Télécom R&D)

26. Bibliographie Journals • F.Barbier: Built-In Test for COTS-Based Products, IEE Proceedings -Software, IEE, in press, 2003 Book Chapters • C.Atkinson, H.-G.Groß, F.Barbier: Component Integration through Built-In Contract Testing in Component-Based Software Quality: Methods and Techniques, Lecture Notes in Computer Science, Springer, in press, 2003 • H.-G.Groß, C.Atkinson, F.Barbier, N.Belloir, J.-M.Bruel:Built-in Contract Testing for Component-Based Development in Business Component-Based Software Engineering, Kluwer, pp. 65-82, 2003 International Conferences • F.Barbier, N.Belloir: Component Behavior Prediction and Monitoring through Built-In Test, proceedings of The 10th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems, Huntsville, USA, IEEE Computer Society Press, in press, April 7-10, 2003 • F.Barbier, N.Belloir, J.-M.Bruel: Incorporation of Test into Software Components, proceedings of The 2nd International Conference on COTS-Based Software Systems, Ottawa, Canada, Lecture Notes in Computer Science #2580, Springer, pp. 25-35, February 10-12, 2003

27. Test intégré dans composants logiciels dérivés d’UML Franck Barbier LIUPPA, Université de Pau BP 1155 64013 Pau CEDEX, France Franck.Barbier@univ-pau.fr Résumé. Cet exposé présente les résultats du projet européen Component+ (IST 1999-20162). On s’intéresse spécifiquement aux composants logiciels sur étagère (COTS components) et leur processus d’acquisition. En tant que structures fermées (encapsulation), un blocage réside dans la confiance dans de tels composants : ils ne sont pas ou peu spécifier et donc intelligibles avec difficulté, la prédiction de leurs comportements (« sémantique » de leur fonctionnement, de leur potentiel de collaboration/échange avec des composants tiers, contrats qu’ils sont en mesure de respecter…) et la connaissance de leur qualité de service (temps de réponse, encombrement de ressources, aptitude au déploiement rapide…) ne sont envisageables que si leur conception l’a prévu. Le test intégré vise donc à instrumenter le code pour évaluer in-situ les COTS composants. La contribution consiste essentiellement en une technique de conception fondée sur des Statecharts UML où il existe une bijection entre code et spécification : idée de spécification exécutable. Les acquéreurs bénéficient alors de modèles didactiques avec lesquels ils peuvent « jouer » dans leurs environnements réels d’exécution. Une libraire Java nommée BIT/J supporte cette démarche. Utilisant le modèle de composants JMX (Java Management Extensions) généralisant le concept de « manageable component » ou MBean, il devient alors possible de tester les composants à distance, de piloter les composants (« monitoring ») et par conséquent, piloter la machine d’état embarquée dans le composant. Une démonstration de cette librairie sera faite à la fin de l’exposé.