Sound Regular Expression Semantics for Dynamic Symbolic Execution Of

Total Page:16

File Type:pdf, Size:1020Kb

Sound Regular Expression Semantics for Dynamic Symbolic Execution Of Sound Regular Expression Semantics for Dynamic Symbolic Execution of JavaScript Blake Loring Duncan Mitchell Johannes Kinder Information Security Group Department of Computer Science Research Institute CODE Royal Holloway, University of London Royal Holloway, University of London Bundeswehr University Munich United Kingdom United Kingdom Germany [email protected] [email protected] [email protected] Abstract 1 Introduction Support for regular expressions in symbolic execution-based Regular expressions are popular with developers for match- tools for test generation and bug finding is insufficient. Com- ing and substituting strings and are supported by many pro- mon aspects of mainstream regular expression engines, such gramming languages. For instance, in JavaScript, one can as backreferences or greedy matching, are ignored or impre- write /goo+d/.test(s) to test whether the string value of cisely approximated, leading to poor test coverage or missed s contains "go",followedbyoneormoreoccurrencesof "o" bugs. In this paper, we present a model for the complete reg- and a final "d". Similarly, s.replace(/goo+d/,"better") ular expression language of ECMAScript 2015 (ES6), which evaluates to a new string where the first such occurrence in is sound for dynamic symbolic execution of the test and s is replaced with the string "better". exec functions. We model regular expression operations us- Several testing and verification tools include some degree ing string constraints and classical regular expressions and of support for regular expressions because they are so com- use a refinement scheme to address the problem of matching mon[24, 27, 29, 34, 37]. In particular, SMT (satisfiability mod- precedence and greediness. We implemented our model in ulo theory) solvers now often support theories for strings ExpoSE, a dynamic symbolic execution engine for JavaScript, and classical regular expressions [1, 2, 6, 15, 25, 26, 34, 38–40], and evaluated it on over 1,000 Node.js packages containing which allow expressing constraints such as s ∈ L(goo+d) regular expressions, demonstrating that the strategy is effec- for the test example above. Although any general theory tive and can significantly increase the number of successful of strings is undecidable [7], many string constraints are ef- regular expression queries and therefore boost coverage. ficiently solved by modern SMT solvers. SMT solvers support regular expressions in the language- CCS Concepts • Software and its engineering → Soft- theoretical sense, but “regular expressions” in programming ware verification and validation; Dynamic analysis; • languages like Perl or JavaScript—often called regex, a term Theory of computation → Regular languages. we also adopt in the remainder of this paper—are not lim- ited to representing regular languages [3]. For instance, the Keywords Dynamic symbolic execution, JavaScript, regu- expression /<(\w+)>.*?<\/\1>/ parses any pair of match- lar expressions, SMT ing XML tags, which is a context-sensitive language (be- cause the tag is an arbitrary string that must appear twice). ACM Reference Format: Problematic features that prevent a translation of regexes Blake Loring, Duncan Mitchell, and Johannes Kinder. 2019. Sound to the word problem in regular languages include capture arXiv:1810.05661v4 [cs.PL] 13 Mar 2020 Regular Expression Semantics for Dynamic Symbolic Execution of groups (the parentheses around \w+ in the example above), JavaScript. In Proceedings of the 40th ACM SIGPLAN Conference on backreferences (the \1 referring to the capture group), and ProgrammingLanguage Designand Implementation(PLDI ’19), June greedy/non-greedy matching precedence of subexpressions 22–26, 2019, Phoenix, AZ, USA. ACM, New York, NY, USA, 15 pages. (the .*? is non-greedy). In addition, any such expression hps://doi.org/10.1145/3314221.3314645 could also be included in a lookahead (?=), which effec- tively encodes intersection of context sensitive languages. In tools reasoning about string-manipulating programs, these features are usually ignored or imprecisely approximated. PLDI ’19, June 22–26, 2019, Phoenix, AZ, USA © 2019 Copyright held by the owner/author(s). Publication rights licensed This is a problem, because they are widely used, as we demon- to ACM. strate in §7.1. This is the author’s version of the work. It is posted here for your personal In the context of dynamic symbolic execution (DSE) for use. Not for redistribution. The definitive Version of Record was published test generation, this lack of support can lead to loss of cover- in Proceedings of the 40th ACM SIGPLAN Conference on Programming Lan- age or missed bugs where constraints would have to include guage Design and Implementation (PLDI ’19), June 22–26, 2019, Phoenix, AZ, USA, hps://doi.org/10.1145/3314221.3314645. membership in non-regular languages. The difficulty arises 1 PLDI’19,June22–26,2019,Phoenix,AZ,USA BlakeLoring,Duncan Mitchell, and Johannes Kinder from the typical mixing of constraints in path conditions— offer the match, split, search and replace methods that simply generating a matching word for a standalone regex is expect a RegExp argument. easy (without lookaheads). To date, there has been only lim- A regex accepts a string if any portion of the string matches ited progress on this problem, mostly addressing immediate the expression, i.e., it is implicitly surrounded by wildcards. needs of implementations with approximate solutions, e.g., The relative position in the string can be controlled with an- for capture groups [29] and backreferences [27, 30]. How- chors, with ^ and $ matching the start and end, respectively. ever, neither matching precedence nor lookaheads have been Flags in regexes can modify the behavior of matching op- addressed before. erations. The ignore case flag i ignores character cases when In this paper, we propose a novel scheme for support- matching. The multiline flag m redefines anchor characters ing ECMAScript regex in dynamic symbolic execution and to match either the start and end of input or newline char- show that it is effective in practice. We rely on the specifica- acters. The unicode flag u changes how unicode literals are tion of regexes and their associated methods in ECMAScript escaped within an expression. The sticky flag y forces match- 2015 (ES6). However, our methods and findings should be ing to start at RegExp.lastIndex, which is updated with easily transferable to most other existing implementations. the index of the previous match. Therefore, RegExp objects In particular, we make the following contributions: become stateful as seen in the following example: • We fully model ES6 regex in terms of classical regular r = /goo+d/y; languages and string constraints (§4) and cover sev- r.test("goood"); // true; r.lastIndex = 6 eral aspects missing from previous work [27, 29, 30]. r.test("goood"); // false; r.lastIndex = 0 We introduce the notion of a capturing language to The meaning of the global flag g varies. It extends the effects make the problem of matching and capture group as- of match and replace to include all matches on the string signment self-contained. and it is equivalent to the sticky flag for the test and exec • We introduce a counterexample-guided abstraction re- methods of RegExp. finement (CEGAR) scheme to address the effect of greed- iness on capture groups (§5), which allows us to de- 2.2 Capture Groups ploy our model in DSE without sacrificing soundness Parentheses in regexes not only change operator precedence for under-approximation. (e.g., (ab)* matches any number of repetitions of the string • We present the first systematic study of JavaScript "ab" while ab* matches the character "a" followed by any regexes, examining feature usage across 415,487 pack- number of repetitions of the character "b") but also cre- ages from the NPM software repository. We show that ate capture groups. Capture groups are implicitly numbered non-regular features are widely used (§7.1). from left to right by order of the opening parenthesis. For 1 2 In the remainder of the paper we review ES6 regexes (§2) example, /a|((b)*c)*d/ is numbered as /a|( ( b)*c)*d/. and present an overview of our approach by example (§3). Where only bracketing is required, a non-capturing group We then detail our regex model using a novel formulation (§4), can be created by using the syntax (?: ... ). and we propose a CEGAR scheme to address matching prece- For regexes, capture groups are important because the dence (§5). We discuss an implementation of the model as regex engine will record the most recent substring matched part of the ExpoSE symbolic execution engine for JavaScript against each capture group. Capture groups can be referred (§6) and evaluate its practical impact on DSE (§7). Finally, we to from within the expression using backreferences (see §2.3). review related work (§8) and conclude (§9). The last matched substring for each capture group is also returned by some of the API methods. In JavaScript, the re- turn values of match and exec are arrays, with the whole 2 ECMAScript Regex match at index 0 (the implicit capture group 0), and the last We review the ES6 regex specification, focusing on differ- matched instance of the ith capture group at index i. In the ences to classical regular expressions. We begin with the example above, "bbbbcbcd".match(/a|((b)*c)*d/) will regex API and its matching behavior (§2.1) and then explain evaluate to the array ["bbbbcbcd", "bc", "b"]. capture groups (§2.2), backreferences (§2.3), and operator precedence (§2.4). ES6 regexes are comparable to those of 2.3 Backreferences other languages but lack Perl’s recursion and lookbehind A backreference in a regex refers to a numbered capture group and do not require POSIX-like longest matches. and will match whatever the engine last matched the cap- ture group against. In general, the addition of backreferences 2.1 Methods, Anchors, Flags to regexes makes the accepted languages non-regular [3].
Recommended publications
  • Technical Standard
    Technical Standard X/Open Curses, Issue 7 The Open Group ©November 2009, The Open Group All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior permission of the copyright owners. Technical Standard X/Open Curses, Issue 7 ISBN: 1-931624-83-6 Document Number: C094 Published in the U.K. by The Open Group, November 2009. This standardhas been prepared by The Open Group Base Working Group. Feedback relating to the material contained within this standardmay be submitted by using the web site at http://austingroupbugs.net with the Project field set to "Xcurses Issue 7". ii Technical Standard 2009 Contents Chapter 1 Introduction........................................................................................... 1 1.1 This Document ........................................................................................ 1 1.1.1 Relationship to Previous Issues ......................................................... 1 1.1.2 Features Introduced in Issue 7 ........................................................... 2 1.1.3 Features Withdrawn in Issue 7........................................................... 2 1.1.4 Features Introduced in Issue 4 ........................................................... 2 1.2 Conformance............................................................................................ 3 1.2.1 Base Curses Conformance .................................................................
    [Show full text]
  • Data Structure
    EDUSAT LEARNING RESOURCE MATERIAL ON DATA STRUCTURE (For 3rd Semester CSE & IT) Contributors : 1. Er. Subhanga Kishore Das, Sr. Lect CSE 2. Mrs. Pranati Pattanaik, Lect CSE 3. Mrs. Swetalina Das, Lect CA 4. Mrs Manisha Rath, Lect CA 5. Er. Dillip Kumar Mishra, Lect 6. Ms. Supriti Mohapatra, Lect 7. Ms Soma Paikaray, Lect Copy Right DTE&T,Odisha Page 1 Data Structure (Syllabus) Semester & Branch: 3rd sem CSE/IT Teachers Assessment : 10 Marks Theory: 4 Periods per Week Class Test : 20 Marks Total Periods: 60 Periods per Semester End Semester Exam : 70 Marks Examination: 3 Hours TOTAL MARKS : 100 Marks Objective : The effectiveness of implementation of any application in computer mainly depends on the that how effectively its information can be stored in the computer. For this purpose various -structures are used. This paper will expose the students to various fundamentals structures arrays, stacks, queues, trees etc. It will also expose the students to some fundamental, I/0 manipulation techniques like sorting, searching etc 1.0 INTRODUCTION: 04 1.1 Explain Data, Information, data types 1.2 Define data structure & Explain different operations 1.3 Explain Abstract data types 1.4 Discuss Algorithm & its complexity 1.5 Explain Time, space tradeoff 2.0 STRING PROCESSING 03 2.1 Explain Basic Terminology, Storing Strings 2.2 State Character Data Type, 2.3 Discuss String Operations 3.0 ARRAYS 07 3.1 Give Introduction about array, 3.2 Discuss Linear arrays, representation of linear array In memory 3.3 Explain traversing linear arrays, inserting & deleting elements 3.4 Discuss multidimensional arrays, representation of two dimensional arrays in memory (row major order & column major order), and pointers 3.5 Explain sparse matrices.
    [Show full text]
  • Synchronizing Threads with POSIX Semaphores
    3/17/2016 POSIX Semaphores Synchronizing Threads with POSIX Semaphores 1. Why semaphores? 2. Posix semaphores are easy to use sem_init sem_wait sem_post sem_getvalue sem_destroy 3. Activities 1 2 Now it is time to take a look at some code that does something a little unexpected. The program badcnt.c creates two new threads, both of which increment a global variable called cnt exactly NITER, with NITER = 1,000,000. But the program produces unexpected results. Activity 1. Create a directory called posixsem in your class Unix directory. Download in this directory the code badcnt.c and compile it using gcc badcnt.c -o badcnt -lpthread Run the executable badcnt and observe the ouput. Try it on both tanner and felix. Quite unexpected! Since cnt starts at 0, and both threads increment it NITER times, we should see cnt equal to 2*NITER at the end of the program. What happens? Threads can greatly simplify writing elegant and efficient programs. However, there are problems when multiple threads share a common address space, like the variable cnt in our earlier example. To understand what might happen, let us analyze this simple piece of code: THREAD 1 THREAD 2 a = data; b = data; a++; b--; data = a; data = b; Now if this code is executed serially (for instance, THREAD 1 first and then THREAD 2), there are no problems. However threads execute in an arbitrary order, so consider the following situation: Thread 1 Thread 2 data a = data; --- 0 a = a+1; --- 0 --- b = data; // 0 0 --- b = b + 1; 0 data = a; // 1 --- 1 --- data = b; // 1 1 So data could end up +1, 0, -1, and there is NO WAY to know which value! It is completely non- deterministic! http://www.csc.villanova.edu/~mdamian/threads/posixsem.html 1/4 3/17/2016 POSIX Semaphores The solution to this is to provide functions that will block a thread if another thread is accessing data that it is using.
    [Show full text]
  • Precise Analysis of String Expressions
    Precise Analysis of String Expressions Aske Simon Christensen, Anders Møller?, and Michael I. Schwartzbach BRICS??, Department of Computer Science University of Aarhus, Denmark aske,amoeller,mis @brics.dk f g Abstract. We perform static analysis of Java programs to answer a simple question: which values may occur as results of string expressions? The answers are summarized for each expression by a regular language that is guaranteed to contain all possible values. We present several ap- plications of this analysis, including statically checking the syntax of dynamically generated expressions, such as SQL queries. Our analysis constructs flow graphs from class files and generates a context-free gram- mar with a nonterminal for each string expression. The language of this grammar is then widened into a regular language through a variant of an algorithm previously used for speech recognition. The collection of resulting regular languages is compactly represented as a special kind of multi-level automaton from which individual answers may be extracted. If a program error is detected, examples of invalid strings are automat- ically produced. We present extensive benchmarks demonstrating that the analysis is efficient and produces results of useful precision. 1 Introduction To detect errors and perform optimizations in Java programs, it is useful to know which values that may occur as results of string expressions. The exact answer is of course undecidable, so we must settle for a conservative approxima- tion. The answers we provide are summarized for each expression by a regular language that is guaranteed to contain all its possible values. Thus we use an upper approximation, which is what most client analyses will find useful.
    [Show full text]
  • Openextensions POSIX Conformance Document
    z/VM Version 7 Release 1 OpenExtensions POSIX Conformance Document IBM GC24-6298-00 Note: Before you use this information and the product it supports, read the information in “Notices” on page 73. This edition applies to version 7, release 1, modification 0 of IBM z/VM (product number 5741-A09) and to all subsequent releases and modifications until otherwise indicated in new editions. Last updated: 2018-09-12 © Copyright International Business Machines Corporation 1993, 2018. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents List of Tables........................................................................................................ ix About This Document............................................................................................xi Intended Audience......................................................................................................................................xi Conventions Used in This Document.......................................................................................................... xi Where to Find More Information.................................................................................................................xi Links to Other Documents and Websites.............................................................................................. xi How to Send Your Comments to IBM....................................................................xiii Summary of Changes for z/VM
    [Show full text]
  • Regular Languages
    id+id*id / (id+id)*id - ( id + +id ) +*** * (+)id + Formal languages Strings Languages Grammars 2 Marco Maggini Language Processing Technologies Symbols, Alphabet and strings 3 Marco Maggini Language Processing Technologies String operations 4 • Marco Maggini Language Processing Technologies Languages 5 • Marco Maggini Language Processing Technologies Operations on languages 6 Marco Maggini Language Processing Technologies Concatenation and closure 7 Marco Maggini Language Processing Technologies Closure and linguistic universe 8 Marco Maggini Language Processing Technologies Examples 9 • Marco Maggini Language Processing Technologies Grammars 10 Marco Maggini Language Processing Technologies Production rules L(G) = {anbncn | n ≥ 1} T = {a,b,c} N = {A,B,C} production rules 11 Marco Maggini Language Processing Technologies Derivation 12 Marco Maggini Language Processing Technologies The language of G • Given a grammar G the generated language is the set of strings, made up of terminal symbols, that can be derived in 0 or more steps from the start symbol LG = { x ∈ T* | S ⇒* x} Example: grammar for the arithmetic expressions T = {num,+,*,(,)} start symbol N = {E} S = E E ⇒ E * E ⇒ ( E ) * E ⇒ ( E + E ) * E ⇒ ( num + E ) * E ⇒ (num+num)* E ⇒ (num + num) * num language phrase 13 Marco Maggini Language Processing Technologies Classes of generative grammars 14 Marco Maggini Language Processing Technologies Regular languages • Regular languages can be described by different formal models, that are equivalent ▫ Finite State Automata (FSA) ▫ Regular
    [Show full text]
  • So You Think You Know C? [Pdf]
    So You Think You Know C? And Ten More Short Essays on Programming Languages by Oleksandr Kaleniuk Published in 2020 This is being published under the Creative Commons Zero license. I have dedicated this work to the public domain by waiving all of my rights to the work worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission. Table of Contents Introduction......................................................................................................... 4 So you think you know C?..................................................................................6 APL deserves its renaissance too.......................................................................13 Going beyond the idiomatic Python..................................................................30 Why Erlang is the only true computer language................................................39 The invisible Prolog in C++..............................................................................43 One reason you probably shouldn’t bet your whole career on JavaScript.........54 You don't have to learn assembly to read disassembly......................................57 Fortran is still a thing........................................................................................64 Learn you a Lisp in 0 minutes...........................................................................68 Blood, sweat,
    [Show full text]
  • Formal Languages
    Formal Languages Discrete Mathematical Structures Formal Languages 1 Strings Alphabet: a finite set of symbols – Normally characters of some character set – E.g., ASCII, Unicode – Σ is used to represent an alphabet String: a finite sequence of symbols from some alphabet – If s is a string, then s is its length ¡ ¡ – The empty string is symbolized by ¢ Discrete Mathematical Structures Formal Languages 2 String Operations Concatenation x = hi, y = bye ¡ xy = hibye s ¢ = s = ¢ s ¤ £ ¨© ¢ ¥ § i 0 i s £ ¥ i 1 ¨© s s § i 0 ¦ Discrete Mathematical Structures Formal Languages 3 Parts of a String Prefix Suffix Substring Proper prefix, suffix, or substring Subsequence Discrete Mathematical Structures Formal Languages 4 Language A language is a set of strings over some alphabet ¡ Σ L Examples: – ¢ is a language – ¢ is a language £ ¤ – The set of all legal Java programs – The set of all correct English sentences Discrete Mathematical Structures Formal Languages 5 Operations on Languages Of most concern for lexical analysis Union Concatenation Closure Discrete Mathematical Structures Formal Languages 6 Union The union of languages L and M £ L M s s £ L or s £ M ¢ ¤ ¡ Discrete Mathematical Structures Formal Languages 7 Concatenation The concatenation of languages L and M £ LM st s £ L and t £ M ¢ ¤ ¡ Discrete Mathematical Structures Formal Languages 8 Kleene Closure The Kleene closure of language L ∞ ¡ i L £ L i 0 Zero or more concatenations Discrete Mathematical Structures Formal Languages 9 Positive Closure The positive closure of language L ∞ i L £ L
    [Show full text]
  • Formal Languages
    Formal Languages Wednesday, September 29, 2010 Reading: Sipser pp 13-14, 44-45 Stoughton 2.1, 2.2, end of 2.3, beginning of 3.1 CS235 Languages and Automata Department of Computer Science Wellesley College Alphabets, Strings, and Languages An alphabet is a set of symbols. E.g.: 1 = {0,1}; 2 = {-,0,+} 3 = {a,b, …, y, z}; 4 = {, , a , aa } A string over is a seqqfyfuence of symbols from . The empty string is ofte written (Sipser) or ; Stoughton uses %. * denotes all strings over . E.g.: * • 1 contains , 0, 1, 00, 01, 10, 11, 000, … * • 2 contains , -, 0, +, --, -0, -+, 0-, 00, 0+, +-, +0, ++, ---, … * • 3 contains , a, b, …, aa, ab, …, bar, baz, foo, wellesley, … * • 4 contains , , , a , aa, …, a , …, a aa , aa a ,… A lnlanguage over (Stoug hto nns’s -lnlanguage ) is any sbstsubset of *. I.e., it’s a (possibly countably infinite) set of strings over . E.g.: •L1 over 1 is all sequences of 1s and all sequences of 10s. •L2 over 2 is all strings with equal numbers of -, 0, and +. •L3 over 3 is all lowercase words in the OED. •L4 over 4 is {, , a aa }. Formal Languages 11-2 1 Languages over Finite Alphabets are Countable A language = a set of strings over an alphabet = a subset of *. Suppose is finite. Then * (and any subset thereof) is countable. Why? Can enumerate all strings in lexicographic (dictionary) order! • 1 = {0,1} 1 * = {, 0, 1 00, 01, 10, 11 000, 001, 010, 011, 100, 101, 110, 111, …} • for 3 = {a,b, …, y, z}, can enumerate all elements of 3* in lexicographic order -- we’ll eventually get to any given element.
    [Show full text]
  • String Solving with Word Equations and Transducers: Towards a Logic for Analysing Mutation XSS (Full Version)
    String Solving with Word Equations and Transducers: Towards a Logic for Analysing Mutation XSS (Full Version) Anthony W. Lin Pablo Barceló Yale-NUS College, Singapore Center for Semantic Web Research [email protected] & Dept. of Comp. Science, Univ. of Chile, Chile [email protected] Abstract to name a few (e.g. see [3] for others). Certain applications, how- We study the fundamental issue of decidability of satisfiability ever, require more expressive constraint languages. The framework over string logics with concatenations and finite-state transducers of satisfiability modulo theories (SMT) builds on top of the basic as atomic operations. Although restricting to one type of opera- constraint satisfaction problem by interpreting atomic propositions tions yields decidability, little is known about the decidability of as a quantifier-free formula in a certain “background” logical the- their combined theory, which is especially relevant when analysing ory, e.g., linear arithmetic. Today fast SMT-solvers supporting a security vulnerabilities of dynamic web pages in a more realis- multitude of background theories are available including Boolector, tic browser model. On the one hand, word equations (string logic CVC4, Yices, and Z3, to name a few (e.g. see [4] for others). The with concatenations) cannot precisely capture sanitisation func- backbones of fast SMT-solvers are usually a highly efficient SAT- tions (e.g. htmlescape) and implicit browser transductions (e.g. in- solver (to handle disjunctions) and an effective method of dealing nerHTML mutations). On the other hand, transducers suffer from with satisfiability of formulas in the background theory. the reverse problem of being able to model sanitisation functions In the past seven years or so there have been a lot of works and browser transductions, but not string concatenations.
    [Show full text]
  • Software Engineering Standards Introduction
    6/21/2008 Software Engineering Standards Introduction 1028 9126 730 12207 9000 CMM 15288 CMMI J-016 1679 Outline 1. Definitions 2. Sources of Standards 3. Why Use Standards ? 4. ISO and Software Engineering Standards 5. IEEE Software Engineering Collection Sources: IEEE Standards, Software Engineering, Volume Three: Product Standards, Introduction to the1999 Edition, pages i to xxiii. Horch, J., ‘Practical Guide to Software Quality management’, Artech House, 1996, chap 2. Wells, J., ‘An Introduction to IEEE/EIA 12207’, US DoD, SEPO, 1999. Moore, J., ‘Selecting Software Engineering Standards’, QAI Conference, 1998. Moore, J., ‘The Road Map to Software Engineering: A Standards-Based Guide’, Wiley-IEEE Computer Society Press, 2006. Moore, J.,’An Integrated Collection of Software Engineering Standards’, IEEE Software, Nov 1999. Gray, L., ‘Guidebook to IEEE/EIA 12207 Standard for Information Technology, Software Life Cycle Processes’, Abelia Corporation, Fairfax, Virginia, 2000. Coallier, F.; International Standardization in Software and Systems Engineering, Crosstalk, February 2003, pp. 18-22. 6/21/2008 2 1 6/21/2008 Exemple d’un système complexe Système de transport aérien Système de transport Système de Transport Aérien terrestre Système de Système de gestion du trafic réservation aérien Système Système aéroportuaire de distribution du kérosène SystèmeSystème avionique avion Système de Système de gestion de la Structure vie à bord SystèmeSystème de de équipage propulsionpropulsion Système SystèmeNavigation de de SystèmeVisualisation Système de navigationsystem de visualisation contrôle de vol SystèmeSystème de de réception réception Système de GPSGPS transport terrestremaritime 6/21/2008 3 Toward a Software Engineering Profession • What does it take ? 1. Body of Knowledge (e.g. SWEBOK) 2.
    [Show full text]
  • JTC1 and SC22 - Terminology
    JTC1 AD Hoc Terminology, August 2005 1 JTC1 and SC22 - Terminology Background Following my offer to collect together the definitions from SC22 standards, SC22 accepted my offer and appointed me as its terminology representative (I was later also asked to represent UK and BSI) on the JTC1 ad hoc group on terminology. These notes summarise the results of collecting the SC22 definitions, and my impressions of the JTC1 ad hoc group. Roger Scowen August 2005 A collection of definitions from SC22 standards SC22 asked me to prepare a collected terminology for SC22 containing the definitions from standards for which SC22 is responsible, and asked the project editors to send me the definitions in text form. Many, but not all, project editors did so. However there are sufficient for SC22 to judge whether to complete the list or abandon it as an interesting but unprofitable exercise. Adding definitions to the database The project editor of a standard typically sends the definitions from the standard as a Word file, but it may be plain text or in Latex or nroff format. These definitions are transformed into a uniform format by a series of global ‘find & replace’ operations to produce a Word file where each definition is represented as a row of a table with three columns: the term, its definition, and any notes and/or examples. It is often easier to check this has been accomplished by copying and pasting successive attempts into Excel than examining the Word file itself. Sometimes there are special cases such as exotic characters (for example Greek or mathematical characters), special fonts, illustrations, diagrams, or tables.
    [Show full text]