Rapport De Projet 3150 Hanifa Mallek

Total Page:16

File Type:pdf, Size:1020Kb

Rapport De Projet 3150 Hanifa Mallek YAKINDU STATECHART TOOLS Rapport IFT3150 – PROJET INFORMATIQUE HANIFA MALLEK Sous la direction du Dr. Eugène SYRIANI Avril 30, 2019 Table des matières Introduction ………………………………………………… 2 1.1 Objectif ………………………………………………… 2 1.2 Motivation ……………………………………………………… 2 1.3 Terminologie ……………………………………………. 3 2 Analyse des besoins ……………………………………… 7 3 Méthodologie et approche adoptée ………………………. 8 4 Conception ………………………………………………... 8 5 Modélisation ……………………………………………... 9 5.1 Justification du choix de modélisation ………………………... 9 5.2 Stabilité et abstraction ………………………………………… 10 6 Design de la machine d’états ……………………………. 11 7 Implémentation …………………………………………. 14 8 Tests et documentation ………………………………… 16 8.1 Tests fonctionnels ……………………………………………. 16 8.2 Tests structurels ……………………………………………… 17 8.3 Documentation ………………………………………………. 19 9 Maintenance ……………………………………………. 19 9.1 Analyse d’impact des modifications sur le code fourni ……... 19 9.2 Maintenance du statechart …………………………………… 20 Conclusion ………………………………………………… 21 Remerciements ……………………………………………. 22 Bibliographie ……………………………………………… 23 Page 1 Introduction Depuis les dernières décennies, nous remarquons un grand progrès quant à l’utilisation des patrons de conceptions dans le domaine du génie logiciel. Ceci permet de résoudre beaucoup des conflits rencontrés lors du développement, sauf que l’interaction entre les interfaces graphiques et l’application en question restent plutôt conflictuels car la GUI sera directement liée à l’API, ce qui n’est très recommandé. On y trouve beaucoup de couplage, les interfaces deviennent trop lourdes et interagissent beaucoup avec les méthodes internes de l’application. Pour résoudre ce conflit, une solution simple est mise au point. On utilise souvent la modélisation des problèmes par les machines d’état fini, ceux-ci peuvent aussi être utilisées pour interagir entre l’interface graphique et l’application. 1.1 Objectif Pour permettre une meilleure souplesse de l’interface graphique et une réduction considérable du couplage entre celle-ci et l’application, la machine d’état va interagir avec l’application suivant chaque action faite par l’usager. La couche interface graphique reste superficielle, les méthodes propres à l’application vont être dans une couche de bas niveau de sorte que seul la machine d’état communique entre les deux couches respectives. Nous tentons d’introduire des machines d’état grâce à l’outil YAKINDU Statechart Tools (SCT). Nous avons choisi une application de gestion des voyages par différents moyens de transport afin de concrétiser la performance de l’outils YAKINDU SCT. 1.2 Motivation Une machine d’état (statechart) est un langage de spécification qui permet de construire un modèle et de le vérifier. Cette implémentation permet d’encapsuler l’état de l’entité dans des classes séparées qui correspondent à l’état voulu. Distingué les évènement, gardes, actions, procédures d’entrées (entries procedures) et de sorties (exit procedure). Page 2 La solution à cette motivation est modélisée dans le diagramme UML du patron des états suivant : 1.3 Terminologie YAKINDU Statechart Tools (YAKINDU SCT) est un outil de spécification et de développement de systèmes réactifs, pilotés par les événements, à l’aide de machines à états finis. YAKINDU SCT est un outil utiliser pour l'édition graphique de diagrammes statistiques et fournit des générateurs de validation, de simulation et de code source pour diverses plates-formes cibles et langages de programmation. Toute interaction entre les machines d’états et les méthodes de l’application et vice versa est gérée par un contrôleur. Page 3 Figure 4.2 The UCM architecture for user interface software L’IDE Eclipse est doté d’une perspective qui supporte la modélisation des machines d’états. Il est indispensable d’expliquer les différents termes de l’usage de YAKINDU SCT, certains sont en anglais et perdent leurs sens au recours à la traduction : Contenu de la perspective de modélisation Modèle de la machine d’état (Statechart model) : est le modèle qui va loger la machine d’états. Le nom du fichier choisit a pour extension .sct, son format externe est un XML Metadata Interchange ou XMI, qui est un langage XML. L’IDE Eclipse est muni d’une perspective qui supporte la modélisation des machines d’états, celle-ci comporte les vues suivantes : • Explorateur de projet (Project Explorer) : Cette vue affiche l’espace de travail et peut également servir pour examiner la structure interne du modèle d'états. • Vue propriété : Dans celle-ci, les propriétés du modèle sont là. Page 4 • Vue problème : Dans cette vue, on y voit les potentielles erreurs du modèle. • Vue tâche : Toutes les tâches à faire sont là. • Vue simulation : C’est une vue très utile, elle permet de montrer l’exécution de la machine d’état, et de voir la logique de conception. Aussi, on trouve la section de déclaration et la palette pour dessiner le modèle. Éléments des machines d’états Ce sont des éléments essentiels à la modélisation, et on compte : État : C’est l’élément central de la machine d’état. Il doit être placé dans une région, doit avoir un nom unique dans celle-ci. Lors de l’exécution, l’état est soit passif ou actif. Un état peut avoir un comportement qui spécifie quelle action est exécutée et sous quelle condition. Ces actions sont exécutées soit en entrant dans l’état ou en sortant suivant des gardes, un évènement temporel ou un évènement venant de l’extérieur (par exemple presser un bouton). La spécification du comportement de l’état est une instruction ou plusieurs (séparées d’un point-virgule) qui consiste en une série de réactions locales. État Idle : C’est l’état repos de la région qui est associé à l’entrée du statechert, une fois l’action effectuée la machine revient à cet état par une transitions définie. État composite : C’est un état qui peut contenir une seule région ou plusieurs pouvant être exécuter simultanément. États orthogonaux : Un état orthogonal est un état composite avec plus d'une région. Ces régions sont exécutées simultanément. Cependant, ce parallélisme n’est pas garanti dans les fonctionnalités actuelles de Yakindu SCT. C’est surtout un moyen de faire travailler deux ou plusieurs actions, mais ils sont exécutés les uns après les autres dans chaque cycle et dans un ordre défini: de haut en bas, de gauche à droite. Ceci est aussi applicable à plusieurs régions dans l'état même. Transition : Une transition permet le transfert d'un état source à un état cible. Elle est représentée sous la forme d'une flèche. Lorsqu'une transition est effectuée, l'état source n’est plus actif, il devient par conséquent passif et l'état cible devient actif. Page 5 Une transition devrait avoir une réaction. La réaction d’une transition spécifie qu’elles sont les conditions pour que cette transition soit prise, et quelles actions doivent être exécutées lors de cette transition. L'occurrence d'un événement, le fait qu'une condition devienne vraie ou le temps qui passe peut déclencher une transition. La réaction de la transition est associée à la flèche de la transition sous forme de texte. Les points d’entrée : Pour démarrer une machine d’état, il est nécessaire d’avoir un point d’entrée. Si le modèle contient plusieurs régions, chaque région à son propre point d’entrée. Région : Les machines d’états sont organisées en régions, ce qui permet d’avoir plusieurs machines d’états dans différentes régions et de les exécuter simultanément. Les régions contiennent des états et des transitions. Interface : C’est une classe qui agit comme une interface permettant d’avoir la logique d’encapsulation. Elle contient l’état de l’entité actuelle qu’il soit élémentaire ou composite, les évènements, les variables ainsi que les opérations. Variable : Les variables doivent être définies dans une interface interne ou externe. Les variables de l'étendue interne ne sont visibles par aucun code client. Les variables définies dans une interface nommée doivent être référencées à l'aide du nom d'interface. Évènement : Un événement est très important, il se produit à un moment donné dans le contexte d'une machine à états (bouton cliqué, une période de temps écoulée, etc…). Un événement peut être internes (destinés uniquement à être générés et traités par la machine à états), externes (définis dans une étendue d'interface et sont entrants ou sortants et définis référencés à l'aide du nom de l'interface si celle-ci est nommée). Les événements peuvent être traités dans des déclencheurs. Opération : Une opération connecte une machine à états au monde extérieur (lire des données d'un capteur, engager un actionneur, etc.) en rendant le comportement externe accessible à la machine à états. Le logiciel client doit fournir un comportement tel que des fonctions ou des méthodes dans un langage de programmation pour que la machine à états peut interagir avec. Une opération est le Page 6 moyen utilisé par le langage de l’état statistique pour appeler une telle procédure externe à partir du statechart. Les opérations peuvent avoir aucun, un ou plusieurs paramètres. Un paramètre est déclaré avec un nom et un type. Une opération peut avoir un type de retour unique ou nul similaire aux langages de programmation habituels. Générateur de code (CodeGenerator) : Outil qui transforme la machine d’état en un code source du langage de programmation cible. il est toujours valide, dans le sens où il correspond à la machine d’état modélisée Deep Java intégration : C’est une fonctionnalité qui a été mise en place récemment. Elle permet d’accéder au code Java depuis la machine d’état ce qui facilite l’intégration de celle-ci dans le processus de développement. Cependant, cette fonctionnalité est encore en version bêta. 2 Analyse des besoins Le besoin initial était d’intégrer les machines d’états dans toute l’application, c’est-à-dire couvrir le côté administrateur et le côté client d’une part, et permettre le parallélisme de sorte que n’importe quel changement du côté administrateur se répercute sur le côté client instantanément d’une autre, mais vu l’ampleur du projet, il a été décidé de faire la partie administrateur, et de s’assurer ensuite que les machines d’états répondent aux tests unitaires.
Recommended publications
  • Textual, Executable, Translatable UML⋆
    Textual, executable, translatable UML? Gergely D´evai, G´abor Ferenc Kov´acs, and Ad´amAncsin´ E¨otv¨osLor´andUniversity, Faculty of Informatics, Budapest, Hungary, fdeva,koguaai,[email protected] Abstract. This paper advocates the application of language embedding for executable UML modeling. In particular, txtUML is presented, a Java API and library to build UML models using Java syntax, then run and debug them by reusing the Java runtime environment and existing de- buggers. Models can be visualized using the Papyrus editor of the Eclipse Modeling Framework and compiled to implementation languages. The paper motivates this solution, gives an overview of the language API, visualization and model compilation. Finally, implementation de- tails involving Java threads, reflection and AspectJ are presented. Keywords: executable modeling, language embedding, UML 1 Introduction Executable modeling aims at models that are completely independent of the ex- ecution platform and implementation language, and can be executed on model- level. This way models can be tested and debugged in early stages of the devel- opment process, long before every piece is in place for building and executing the software on the real target platform. Executable and platform-independent UML modeling changes the landscape of software development tools even more than mainstream modeling: graphical model editors instead of text editors, model compare and merge instead of line based compare and merge, debuggers with graphical animations instead of de- buggers for textual programs, etc. Figure 1 depicts the many different use cases such a toolset is responsible for. Models are usually persisted in a format that is hard or impossible to edit directly, therefore any kind of access to the model is dependent on different features of the modeling toolset.
    [Show full text]
  • Segédlet a Rendszermodellezés (VIMIAA00) Házi Feladathoz
    Segédlet a Rendszermodellezés (VIMIAA00) házi feladathoz Kritikus Rendszerek Kutatócsoport 2021 Tartalomjegyzék 1. Előszó 1 4.1. Yakindu projekt importálása ... 6 4.2. A modell megnyitása ........ 6 2. Alapismeretek 2 4.3. A modell kimentése ......... 6 2.1. Eclipse bevezető .......... 2 2.2. Az Eclipse munkaterület ...... 2 5. Modellezés, szimuláció 6 2.3. A Eclipse felhasználói felület ... 2 5.1. Állapot alapú modellezés ...... 6 2.4. Yakindu bevezető .......... 2 5.2. Modellezés Yakinduban ...... 7 5.3. A modell működésének szimulálása 8 3. A modellező eszköz telepítése 3 5.4. A modell működésének tesztelése . 8 3.1. Java környezet ........... 3 5.5. A modell kipróbálása ........ 9 3.2. A Yakindu telepítése létező Eclipse példányra .............. 3 5.6. Kódgenerálás ............ 9 3.3. A Yakindu telepítése a hivatalos ol- 6. Feladatkiadás és feladatbeadás 10 dalról ................ 4 6.1. HF portál használata ........ 10 3.4. Telepített verzió ellenőrzése .... 5 6.2. Az automatikus kiértékelőről ... 11 3.5. Yakindu virtuális gépen ...... 5 6.3. Tiltott elemek ............ 11 4. Projekt létrehozása, importálása 6 6.4. Ismert problémák .......... 12 Bevezetés 1. Előszó Jelen segédanyag a BME VIK elsőéves informatikus hallgatói számára készült a Méréstechnika és Információs Rendszerek Tanszéken Lucz Soma és Farkas Rebeka munkájának felhasználásával, és a Rendszermodellezés (VIMIAA00) című tárgy házi feladatainak elkészítésében segít. A Yakindu eszköz1 egy állapot alapú modellezést, szimulációt és kódgenerálást támogató eszköz. Figyelem! A szöveg a Yakindu 3.5.2-es verziójával van összhangban. Nyomatékosan kérjük, hogy idén (2021-ben) a házi feladat elkészítéséhez is ezt a verziót használják, mert más (akár újabb, akár régebbi) verziókkal kompatibilitási probléma léphet fel! 1http://statecharts.org/ 1 Rendszermodellezés Segédlet a Rendszermodellezés (VIMIAA00) házi feladathoz 2.
    [Show full text]
  • Segédlet a Rendszermodellezés (VIMIAA00) Házi Feladathoz
    Segédlet a Rendszermodellezés (VIMIAA00) házi feladathoz Kritikus Rendszerek Kutatócsoport 2021 Tartalomjegyzék 1. Előszó 2 4.1. Yakindu projekt importá- lása ............ 8 2. Alapismeretek 2 4.2. A modell megnyitása ... 8 2.1. Eclipse bevezető ..... 2 4.3. A modell kimentése .... 9 2.2. Az Eclipse munkaterület . 2 2.3. A Eclipse felhasználói fe- 5. Modellezés, szimuláció 9 lület ............ 3 5.1. Állapot alapú modellezés . 9 2.4. Yakindu bevezető ..... 3 5.2. Modellezés Yakinduban . 9 5.3. A modell működésének 3. A modellező eszköz telepíté- szimulálása ........ 11 se 4 5.4. A modell működésének 3.1. Java környezet ...... 4 tesztelése ......... 11 3.2. A Yakindu telepítése léte- 5.5. A modell kipróbálása ... 13 ző Eclipse példányra ... 4 5.6. Kódgenerálás ....... 13 3.3. A Yakindu telepítése a hi- vatalos oldalról ...... 6 6. Feladatkiadás és feladatbe- 3.4. Telepített verzió ellenőr- adás 14 zése ............ 7 6.1. HF portál használata ... 14 3.5. Yakindu virtuális gépen . 8 6.2. Az automatikus kiértéke- lőről ............ 15 4. Projekt létrehozása, impor- tálása 8 6.3. Tiltott elemek ....... 16 1 RendszermodellezésSegédlet a Rendszermodellezés (VIMIAA00) házi feladathoz 6.4. Ismert problémák ..... 17 Bevezetés 1. Előszó Jelen segédanyag a BME VIK elsőéves informatikus hallgatói számára készült a Méréstechnika és Információs Rendszerek Tanszéken Lucz Soma és Farkas Rebe- ka munkájának felhasználásával, és a Rendszermodellezés (VIMIAA00) című tárgy házi feladatainak elkészítésében segít. A Yakindu eszköz1 egy állapot alapú model- lezést, szimulációt és kódgenerálást támogató eszköz. Figyelem! A szöveg a Yakindu 3.5.2-es verziójával van összhangban. Nyo- matékosan kérjük, hogy idén (2021-ben) a házi feladat elkészítéséhez is ezt a verziót használják, mert más (akár újabb, akár régebbi) verziókkal kompati- bilitási probléma léphet fel! 2.
    [Show full text]
  • Megam@Rt2 EU Project: Open Source Tools for Mega-Modelling at Runtime of Cpss
    MegaM@Rt2 EU Project: Open Source Tools for Mega-Modelling at Runtime of CPSs 1 2 3 4 Jesus Gorroñogoitia Cruz ,​ Andrey Sadovykh ,​ Dragos Truscan ,​ Hugo Bruneliere ,​ ​ 5 ​ 1 ​ ​ Pierluigi Pierini ,​ Lara Lopez Muñiz ​ ​ 1 ATOS,​ Spain {jesus.gorronogoitia,lara.lopez}@atos.net 2 ​ Innopolis University, Russia [email protected] 3 ​ Åbo Akademi University, Finland [email protected] 4 ​ IMT Atlantique, LS2N (CNRS) & ARMINES, Nantes, France [email protected] 5 ​ Intecs Solutions S.p.A., Italy [email protected] Abstract. In this paper, we overview our experiences of developing large set of open ​ source tools in ECSEL JU European project called MegaM@Rt2 whose main objective is to propose a scalable model-based framework incorporating methods and tools for the continuous development and runtime support of complex software-intensive Cyber-Physical Systems (CPSs). We briefly present the MegaM@Rt2 concepts, discuss our approach for open source, enumerate tools and give an example of a tools selection for a specific industrial context. Our goal is to introduce the reader with open source tools for the model-based engineering of CPSs suitable for diverse industrial applications. Keywords: Model-driven engineering, Model-based system engineering, ​ Cyber-physical systems, Open Source, Tools 1 Introduction MegaM@Rt2 is a three-years project, which started in April 2017[1], [2] and which is ​ ​ ​ funded by European Components and Systems for European Leadership Joint Undertaking (ECSEL JU) under the H2020 European program. The main goal of MegaM@Rt2 is to create an integrated framework incorporating scalable methods and tools for continuous system engineering and runtime validation and verification (V&V).
    [Show full text]
  • Minisy@Dmis 2017
    PROCEEDINGS OF THE 24TH PHDMINI-SYMPOSIUM (MINISY@DMIS 2017) JANUARY 30–31, 2017 BUDAPEST UNIVERSITY OF TECHNOLOGY AND ECONOMICS BUILDING I BUDAPEST UNIVERSITY OF TECHNOLOGY AND ECONOMICS DEPARTMENT OF MEASUREMENT AND INFORMATION SYSTEMS c 2017 Department of Measurement and Information Systems, Budapest University of Technology and Economics. For personal use only – unauthorized copying is prohibited. Head of the Department: Dr. Tamas´ Daboczi´ Conference chairman: Bela´ Pataki Organizers: Csaba Debreceni Andras´ Szabolcs Nagy Andras´ Pataki Tamas´ Toth´ Homepage of the Conference: http://minisy.mit.bme.hu/ Sponsored by: Schnell Laszl´ o´ Foundation ISBN 978-963-313-243-2 FOREWORD This proceedings is a collection of the lectures of the 24th Minisymposium held at the Department of Measurement and Information Systems of the Budapest University of Technology and Economics. In the previous years the main purpose of these symposiums was to give an opportunity to the PhD students of our department to present a summary of their work done in the preceding year. It is an interesting additional benefit, that the students get some experience: how to organize such events. Beyond this actual goal, it turned out that the proceedings of our symposiums give an interesting overview of the research and PhD education carried out in our department. Last year the scope of the Minisymposium had been widened; foreign partners and some of the best MSc students were also involved. This was a real benefit, therefore, this year we have kept this widened scope. The lectures reflect partly the scientific fields and work of the students, but we think that an insight into the research and development activity of our and partner departments is also given by these contribu- tions.
    [Show full text]
  • HOW to INSTALL YAKINDU and TRICKS ABOUT IT 1-Installation First You Need to Download the YAKINDU Statechart Tools
    HOW TO INSTALL YAKINDU AND TRICKS ABOUT IT 1-Installation First you need to download the YAKINDU Statechart Tools . Unzip the archive to an arbitrary directory and start SCT. Choose "Install New Software..." from the "Help" menu. Select the "Add..." button in the upper right corner to add a new update site. Copy the following URL to the "Location" text field: https://wendehals.github.io/arduino_sct_tools/releases/ . Use any value for the "Name" field and select "OK". Select YAKINDU Statechart Tools for Arduino and press the "Next>" button to switch to the next page. 2-Arduino Toolchain Setup Before starting development for your Arduino you need to install and setup the Arduino toolchain and libraries in your freshly installed Eclipse environment. Open the Arduino Downloads Manager from the Help menu. In the Platforms tab add a new toolchain by clicking the "Add" button and choosing the target platform. In our case it's the Arduino AVR Boards package. The Arduino toolchain and libraries are now installed. To upload the program to your Arduino you need to connect it to Eclipse. First, connect your Arduino via USB to your computer. If you have connected and used your Arduino with your computer before there should already be a driver installed. If not, make sure you have installed the Arduino IDE from arduino.cc , you need it for the USB driver. There is a wizard that helps you to create a connection to your Arduino. You can open the wizard either by choosing "New Launch Target" from the toolbar or by clicking the "New Connection" button in the "Connections" view of the C/C++ perspective.
    [Show full text]
  • Surveys, Collections, Handbooks, Etc
    Graph Layout Support for Model-Driven Engineering Dipl.-Inf. Miro Spönemann Dissertation zur Erlangung des akademischen Grades Doktor der Ingenieurwissenschaften (Dr.-Ing.) der Technischen Fakultät der Christian-Albrechts-Universität zu Kiel eingereicht im Jahr 2014 Kiel Computer Science Series (KCSS) 2015/2 v1.0 dated 2015-3-13 ISSN 2193-6781 (print version) ISSN 2194-6639 (electronic version) Electronic version, updates, errata available via https://www.informatik.uni-kiel.de/kcss Published by the Department of Computer Science, Kiel University Real-Time and Embedded Systems Group Please cite as: Ź Miro Spönemann. Graph layout support for model-driven engineering. Number 2015/2 in Kiel Computer Science Series. Dissertation, Faculty of Engineering, Christian-Albrechts- Universität zu Kiel, 2015. @book{Spoenemann15, author = {Miro Sp{\"o}nemann}, title = {Graph layout support for model-driven engineering}, publisher = {Department of Computer Science}, year = {2015}, isbn = {9783734772689}, series = {Kiel Computer Science Series}, number = {2015/2}, note = {Dissertation, Faculty of Engineering, Christian-Albrechts-Universit\"at zu Kiel} } © 2015 by Miro Spönemann Herstellung und Verlag: BoD – Books on Demand, Norderstedt ISBN 978-3-7347-7268-9 ii About this Series The Kiel Computer Science Series (KCSS) covers dissertations, habilitation theses, lecture notes, textbooks, surveys, collections, handbooks, etc. written at the Department of Computer Science at Kiel University. It was initiated in 2011 to support authors in the dissemination of their work in electronic and printed form, without restricting their rights to their work. The series provides a unified appearance and aims at high-quality typography. The KCSS is an open access series; all series titles are electronically available free of charge at the department’s website.
    [Show full text]
  • Model Driven Software Development and Service Integration Lecture
    Budapest University of Technology and Economics Department of Measurement and Information Systems Fault Tolerant Systems Research Group Model Driven Software Development and Service Integration Lecture Notes and Laboratory Instructions Oszkár Semeráth Gábor Szárnyas May 10, 2013 Contents 1 Introduction 6 2 An overview of the Eclipse development environment7 2.1 Introduction.....................................................7 2.2 Project management................................................8 2.2.1 Workspace..................................................8 2.2.2 Project....................................................8 2.2.3 Package Explorer and Project Explorer.................................8 2.2.4 Build in Eclipse...............................................9 2.2.5 Copying and linking............................................9 2.2.6 Pictograms..................................................9 2.2.7 Subversion..................................................9 2.3 User interface.................................................... 10 2.3.1 Workbench.................................................. 10 2.3.2 Editors.................................................... 10 2.3.3 Views..................................................... 10 The Problems view and the Error Log view............................... 10 2.3.4 Perspective.................................................. 11 2.3.5 SWT...................................................... 11 2.3.6 Search.................................................... 11 2.4 Configuration...................................................
    [Show full text]
  • Code Generation for Sequential Constructiveness
    Christian-Albrechts-Universität zu Kiel Diploma Thesis Code Generation for Sequential Constructiveness Steven Patrick Smyth July 24, 2013 Department of Computer Science Real-Time and Embedded Systems Group Prof. Dr. Reinhard von Hanxleden Advised by: Dipl.-Inf. Christian Motika Eidesstattliche Erklärung Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig verfasst und keine anderen als die angegebenen Hilfsmittel verwendet habe. Kiel, Abstract Many programming languages in the synchronous world employ a classical Model of Computation which allows them to implement determinism since they rule out race conditions. However, to do so, they impose heavy restrictions on which programs are considered valid. The newly refined Sequentially Constructive Model of Computation, developed by von Hanxleden et al. in 2012, aims to lift some of these restrictions by allowing sequential and concurrent dependent variable accesses to proceed as long as the program stays statically schedulable. The code generation approach presented in this thesis introduces a chain of key steps for deriving code automatically out of sequentially constructive statecharts, or SCCharts. It explains the intermediate language SCL, its graphical representation, the SCG, and clarifies each particular step of the transformation chain. Especially the determination of schedulability is elucidated. Additionally, pointers to optimizations are given and since the approach is embedded in the Kiel Integrated Environment for Layout Eclipse Rich Client (KIELER),
    [Show full text]
  • Introduction to Computational Techniques
    Chapter 2 Introduction to Computational Techniques Computational techniques are fast, easier, reliable and efficient way or method for solving mathematical, scientific, engineering, geometrical, geographical and statis- tical problems via the aid of computers. Hence, the processes of resolving problems in computational technique are most time step-wise. The step-wise procedure may entail the use of iterative, looping, stereotyped or modified processes which are incomparably less stressful than solving problems-manually. Sometimes, compu- tational techniques may also focus on resolving computation challenges or issues through the use of algorithm, codes or command-line. Computational technique may contain several parameters or variables that characterize the system or model being studied. The inter-dependency of the variables is tested with the system in form of simulation or animation to observe how the changes in one or more parameters affect the outcomes. The results of the simulations, animation or arrays of numbers are used to make predictions about what will happen in the real system that is being studied in response to changing conditions. Due to the adoption of computers into everyday task, computational techniques are redefined in various disciplines to accommodate specific challenges and how they can be resolved. Fortunately, computational technique encourages multi-tasking and interdisciplinary research. Since computational technique is used to study a wide range of complex systems, its importance in environmental disciplines is to aid the interpretation of field measurements with the main focus of protecting life, prop- erty, and crops. Also, power-generating companies that rely on solar, wind or hydro sources make use of computational techniques to optimize energy production when extreme climate shifts are expected.
    [Show full text]
  • A Method for Testing and Validating Executable Statechart Models
    Software & Systems Modeling https://doi.org/10.1007/s10270-018-0676-3 THEME SECTION PAPER A method for testing and validating executable statechart models Tom Mens1 · Alexandre Decan1 · Nikolaos I. Spanoudakis2 Received: 29 August 2016 / Accepted: 11 April 2018 © Springer-Verlag GmbH Germany, part of Springer Nature 2018 Abstract Statecharts constitute an executable language for modelling event-based reactive systems. The essential complexity of statechart models solicits the need for advanced model testing and validation techniques. In this article, we propose a method aimed at enhancing statechart design with a range of techniques that have proven their usefulness to increase the quality and reliability of source code. The method is accompanied by a process that flexibly accommodates testing and validation techniques such as test-driven development, behaviour-driven development, design by contract, and property statecharts that check for violations of behavioural properties during statechart execution. The method is supported by the Sismic tool, an open-source statechart interpreter library in Python, which supports all the aforementioned techniques. Based on this tool- ing, we carry out a controlled user study to evaluate the feasibility, usefulness and adequacy of the proposed techniques for statechart testing and validation. Keywords Statechart · Executable modeling · Behaviour-driven development · Design by contract · Runtime verification 1 Introduction cial tools such as IBM Rational’s StateMate and Rhapsody, the Mathworks’ Stateflow, itemis’ Yakindu Statechart Tools Statecharts were introduced nearly three decades ago by and IAR Systems’ visualSTATE. There are also multiple Harel [27,28] as a visual executable modelling language. open-source frameworks defining domain-specific languages From a formal point of view, they can be considered as (DSLs) based on statecharts, such as the ATOMPM [47] web- an extension of hierarchical finite-state machines with char- based domain-specific modelling environment with support acteristics of both Mealy and Moore automata.
    [Show full text]
  • Statecharts.Pdf
    AperTO - Archivio Istituzionale Open Access dell'Università di Torino On checking delta-oriented product lines of statecharts This is the author's manuscript Original Citation: Availability: This version is available http://hdl.handle.net/2318/1671322 since 2018-12-16T17:13:33Z Published version: DOI:10.1016/j.scico.2018.05.007 Terms of use: Open Access Anyone can freely access the full text of works made available as "Open Access". Works made available under a Creative Commons license can be used according to the terms and conditions of said license. Use of all other works requires consent of the right holder (author or publisher) if not exempted from copyright protection by the applicable law. (Article begins on next page) 06 October 2021 On checking delta-oriented product lines of statecharts I Michael Lienhardta, Ferruccio Damiania,∗, Lorenzo Testaa, Gianluca Turina aUniversity of Torino, Italy ([email protected], [email protected], {lorenzo.testa, gianluca.turin}@edu.unito.it) Abstract A Software Product Line (SPL) is a set of programs, called variants, which are generated from a common artifact base. Delta-Oriented Programming (DOP) is a flexible approach to implement SPLs. In this article, we provide a foundation for rigorous development of delta-oriented product lines of statecharts. We introduce a core language for statecharts, we define DOP on top of it, we present an analysis ensuring that a product line is well-formed (i.e., all variants can be generated and are well-formed statecharts), and we illustrate how an implementation of the analysis has been applied to an industrial case study.
    [Show full text]