DOCSLIB.ORG

The Developer Factor in Software Privacy

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

The Developer Factor in Software Privacy Mohammad Tahaei Doctor of Philosophy School of Informatics University of Edinburgh 2021 Abstract Computer programming operates and controls our personal devices, cars, and infrastructures. These programs are written by software developers who use tools, software development platforms, and online resources to build systems used by billions of people. As we move towards societies that rely on computer programs, the need for private and secure systems increases. Developers, the workforce behind the data economy, impact these systems’ privacy, and consequently, the users and society. Therefore, understanding the developer factor in software privacy provides invaluable inputs to software companies, regulators, and tool builders. This thesis includes six research papers that look at the developer factor in software privacy. We find that developers impact software privacy and are also influenced by external entities such as tools, platforms, academia, and regulators. For example, changes in regulations create challenges and hurdles for developers, such as creating privacy policies, managing permissions, and keeping user data private and secure. Developers interactions with tools and software development platforms, shape their understanding of what privacy means, such as consent and access control. Presentation of privacy information and options on platforms also heavily impact developers’ decisions for their users’ privacy, and platforms may sometimes nudge developers into sharing more of their users’ data by using design (dark) patterns. Other places developers learn about privacy include universities, though they may not learn how to include privacy in software. Some organisations are making efforts to champion privacy as a concept inside development teams, and we find that this direction shows promise as it gives developers direct access to a champion who cares about privacy. However, we also find that their organisation or the wider community may not always support these privacy champions. Privacy champions face an uphill battle to counter many of the same privacy misconceptions seen in the general population, such as the ‘I’ve got nothing to hide’ attitude. Overall, I find that research in developer-centred privacy is improving and that many of the approaches tried show promise. However, future work is still needed to understand how to best present privacy concepts to developers in ways that support their existing workflows. To my parents Acknowledgements I would like to express by gratitude to my supervisor Dr Kami Vaniea for giving me the freedom to explore my ideas while mentoring me; my collaborators Dr Alisa Frik, Dr Naomi Saphra, and Dr Maria Wolters, for their contributions; my host supervisor at the University of British Columbia, Professor Konstantin Beznosov, for giving an opportunity to experience a different working environment and lab, and his contributions to my research; the committee members of my annual reviews Dr Markulf Kohlweiss and Dr Chris Lucas for their feedback; and the thesis committee Professor Sascha Fahl and Professor John Vines, for reading my thesis and their feedback. I would like to also thank my labmates and friends, Sara Albakry, Kholoud Althobaiti, Lucy Havens, Adam Jenkins, Dilara Kekulluoglu, Florian Mathis, and Nicole Meng, for their feedback, support, and fruitful discussions; Microsoft Research and the School of Informatics at the University of Edinburgh for funding my PhD; and my parents and sisters whose support and encouragement have always driven me forward. Thank you all. Declaration of Authorship and Publications I declare that this thesis was composed by myself, that the work contained herein is my own except where explicitly stated otherwise in the text, and that this work has not been submitted for any other degree or professional qualification except as specified. All chapters except for Chapter1: Introduction and Chapter8: Final Thoughts, are published in peer-reviewed venues. I declare that I substantially contributed to all papers and was involved in all phases of the research process, including study conceptualisation, data collection, data analysis and interpretation, and writing of the papers. All included contributions here are confirmed by the co-authors. I Mohammad Tahaei, Alisa Frik, and Kami Vaniea. 2021. Deciding on Person- alized Ads: Nudging Developers About User Privacy. Symposium on Usable Privacy and Security (SOUPS) 2021. Contributions: MT proposed the initial idea, designed the study, conducted the quantitative analysis, and wrote the first draft of the paper. AF assisted in study design and qualitative analysis. KV provided feedback throughout the project. All authors contributed in the writing. I Mohammad Tahaei and Kami Vaniea. 2021. “Developers Are Responsible”: What Ad Networks Tell Developers About Privacy. Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems Extended Abstracts. ACM, New York, NY, USA, 1–12. DOI: 10.1145/3411763.3451805 Contributions: MT proposed the initial idea, conducted the experiment, and wrote the first draft of the paper. KV provided feedback throughout the project. Both authors contributed in the writing. A position paper was pub- lished in ‘What Can CHI Do About Dark Patterns?’ CHI ’21 workshop [328] based on this paper. I Mohammad Tahaei, Alisa Frik, and Kami Vaniea. 2021. Privacy Cham- pions in Software Teams: Understanding Their Motivations, Strategies, and Challenges. Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems. ACM, New York, NY, USA, 1–15. DOI: 10.1145/3411764.3445768 Contributions: MT proposed the initial idea, designed the study, conducted the interviews, and wrote the first draft of the paper. AF was the second coder for the qualitative analysis, and assisted in study design and recruitment. KV provided feedback throughout the project. All authors contributed in the writing. I Mohammad Tahaei, Kami Vaniea, and Naomi Saphra. 2020. Understanding Privacy-Related Questions on Stack Overflow. Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems. ACM, New York, NY, USA, 1–14. DOI: 10.1145/3313831.3376768 Contributions: MT proposed the initial idea, collected the data, and wrote the first draft of the paper. KV was the second coder for the qualitative analysis and provided feedback throughout the project, and NS did the programming for topic modelling. All authors contributed in the writing. I Mohammad Tahaei, Adam Jenkins, Kami Vaniea, and Maria K. Wolters. “I Don’t Know Too Much About It”: On the Security Mindsets of Com- puter Science Students. 9th International Workshop, STAST 2019, Luxem- bourg City, Luxembourg, September 26, 2019, Revised Selected Papers. In: Socio-Technical Aspects in Security and Trust. Ed. by Thomas Groß and Tryfonas Theo. First Edition. Springer International Publishing, June 2021. DOI: 10.1007/978-3-030-55958-8 Contributions: MT proposed the initial idea, designed and conducted the interviews, and wrote the first draft of the paper. AJ was the second coder for the qualitative analysis. KV closely supervised the project, and MW provided additional feedback throughout the project. All authors contributed in the writing. An early version of this paper was published as a Doctoral Consortium poster in ITiCSE ’19 [322]. I Mohammad Tahaei and Kami Vaniea. A Survey on Developer-Centred Security. 2019 IEEE European Symposium on Security and Privacy Work- shops (EuroS&PW), Stockholm, Sweden, 2019, 129–138, DOI: 10.1109/Eu- roSPW.2019.00021 Contributions: MT proposed the initial idea, collected and read the papers, and wrote the first draft of the paper. KV was the second coder for the qualitative analysis and provided feedback throughout the project. Both authors contributed in the writing. Mohammad Tahaei Contents Prologue1 1. Introduction3 1.1. A Survey On Developer-Centred Privacy and Security.......5 1.2. Understanding Privacy-Related Questions on Stack Overflow...6 1.3. Privacy Champions in Software Teams................6 1.4. On the Privacy and Security Mindsets of Computer Science Students 7 1.5. What Ad Networks Tell Developers About Privacy.........8 1.6. Nudging Developers About User Privacy...............9 1.7. Final Thoughts..............................9 1.8. Contributions.............................. 10 Research Papers 11 2. A Survey On Developer-Centred Privacy and Security 13 2.1. Introduction............................... 14 2.2. Systematisation Approach....................... 15 2.3. Methodology Results.......................... 19 2.4. Research Theme Results......................... 23 2.5. Discussion................................ 31 2.6. Conclusion................................ 34 3. Understanding Privacy-Related Questions on Stack Overflow 37 3.1. Introduction............................... 38 3.2. Related Work............................... 39 3.3. Method.................................. 42 3.4. LDA Findings.............................. 47 3.5. Coding Findings............................. 48 3.6. Privacy Aspect Thematic Analysis Findings............. 51 3.7. Discussion................................ 58 3.8. Limitations................................ 62 3.9. Future Work............................... 62 3.10. Conclusion................................ 63 4. Privacy Champions in Software Teams 67 4.1. Introduction............................... 68 4.2. Related Work............................... 69 4.3. Method.................................. 71 4.4. Results.................................
Recommended publications
  • Alexander Vaos ALEXVAOS@ME.Com - 754.281.9609 - Alexvaos.Com

    Alexander Vaos [email protected] - 754.281.9609 - Alexvaos.Com

    SENIOR FullStack SOFTWARE ENGINEER Alexander Vaos [email protected] - 754.281.9609 - alexvaos.com PERSONA Portfolio My name is Alexander Vaos and I love changing the world. Resume alexvaos.com/resume I’ve worn nearly ever hat I could put on in the last 18 years. I truly love being a part of something WEBSITE alexvaos.com meaningful. github github.com/kriogenx0 linkedin linkedin.com/pub/alex-vaos I love every part of creating a product: starting from an abstract idea, working through the experience, writing up it’s features, designing it, architecting it, building the front-end and back-end, integrating with stackoverflow stackoverflow.com/users/327934/alex-v other apps, bringing it together, testing, and ending at a physical result that makes a difference in Behance behance.net/kriogenx someone’s life. At an early age, I pursued design and programming, eventually learning some of the other Flickr flickr.com/alexvaos components of a business: marketing, product management, business development, sales. I worked as a part of every company size, from startup to enterprise. I've learned the delicacy of a startup, and how essential ROI can be for the roadmap of any company. I'd like to make an impact and create products people love, use, and can learn things from. I'd like the change the world one step at a time. FULL-TIME POSITIONS 2015-2018 SENIOR FullSTack ENGINEER Medidata Mdsol.com Overseeing 8 codebases, front-end applications and API services. Configured countless new applications from scratch with Rails, Rack, Express (Node), and Roda, using React/Webpack for front-end.
  • A Specification-Oriented Semantics for the Refinement of Real-Time Systems

    A Specification-Oriented Semantics for the Refinement of Real-Time Systems

    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Elsevier - Publisher Connector Theoretical Computer Science 131 (1994) 219-241 219 Elsevier A specification-oriented semantics for the refinement of real-time systems David Scholefield and Hussein Zedan Formal Systems Research Group, Department of ComputerScience, University of York, Heslington, York, UK He Jifeng Programming Research Group. Oxford University, Keble Road, Oxford, UK Communicated by I. Mitrani Received November 1992 Revised February 1993 Abslract Scholefield, D., H. Zedan and H. Jifeng, A specification-oriented semantics for the refinement of real-time systems, Theoretical Computer Science 131 (1994) 2199241. A refinement calculus for the development of real-time systems is presented. The calculus is based upon a wide-spectrum language called the temporal agent model (TAM), within which both functional and timing properties can be expressed in either abstract or concrete terms. A specifica- tion-oriented semantics for the language is given. Program development is considered as a refine- ment process, i.e. the calculation of a structured program from an unstructured specification. A calculus of decomposition is defined. An example program is developed. 1. Introduction The formal development of a computer system is traditionally separated into four tasks: the formulation of a specification, the formulation of a design, verification between specification and design, and the translation of the design into an implemen- tation. In real-time systems, verification must take into account both functional correctness and the timeliness of results - a consideration which adds further com- plexity to an already difficult task. Correspondence to: D.
  • Removing Redundant Refusals: Minimal Complete Test Suites for Failure Trace Semantics

    Removing Redundant Refusals: Minimal Complete Test Suites for Failure Trace Semantics

    Removing Redundant Refusals: Minimal Complete Test Suites for Failure Trace Semantics Maciej Gazda Robert M. Hierons Department of Computer Science Department of Computer Science University of Sheffield, UK University of Sheffield, UK Abstract—We explore the problem of finding a minimal com- in which no action in X is enabled. Most work uses ioco [21] plete test suite for a refusal trace (or failure trace) semantics. or one of its variants; see [22] for an overview. In ioco, an Since complete test suites are typically infinite, we consider the observation is a trace that can contain instances of quiescence: setting with a bound ` on the length of refusal traces of interest. A test suite T is thus complete if it is failed by all processes that the situation in which the system under test (SUT) cannot contain a disallowed refusal trace of length at most `. produce output or change state without first receiving input. The proposed approach is based on generating a minimal com- The ioco test theory assumes that the SUT cannot refuse inputs plete set of forbidden refusal traces. Our solution utilises several (is input-enabled) and the environment cannot block outputs, interesting insights into refusal trace semantics. In particular, which is why quiescence is the only type of refusal. we identify a key class of refusals called fundamental refusals which essentially determine the refusal trace semantics, and the A refusal of a set X is observed through the tester offering associated fundamental equivalence relation. We then propose a the actions in X and subsequent deadlock (detected through small but not necessarily minimal test suite based on our theory, a timeout).
  • ROOT Package Management: “Lazy Install” Approach

    ROOT Package Management: “Lazy Install” Approach

    ROOT package management: “lazy install” approach Oksana Shadura ROOT Monday meeting Outline ● How we can improve artifact management (“lazy-install”) system for ROOT ● How to organise dependency management for ROOT ● Improvements to ROOT CMake build system ● Use cases for installing artifacts in the same ROOT session Goals ● Familiarize ROOT team with our planned work ● Explain key misunderstandings ● Give a technical overview of root-get ● Explain how root-get and cmake can work in synergy Non Goals We are not planning to replace CMake No change to the default build system of ROOT No duplication of functionality We are planning to “fill empty holes” for CMake General overview Manifest - why we need it? ● Easy to write ● Easy to parse, while CMakeLists.txt is impossible to parse ● Collect information from ROOT’s dependencies + from “builtin dependencies” + OS dependencies + external packages to be plugged in ROOT (to be resolved after using DAG) ● It can be easily exported back as a CMakeLists.txt ● It can have extra data elements [not only what is in CMakeLists.txt, but store extra info] ○ Dependencies description (github links, semantic versioning) ■ url: "ssh://[email protected]/Greeter.git", ■ versions: Version(1,0,0)..<Version(2,0,0) Manifest is a “dump” of status of build system (BS), where root-get is just a helper for BS Manifest - Sample Usage scenarios and benefits of manifest files: LLVM/Clang LLVM use CMake as a LLVMBuild utility that organize LLVM in a hierarchy of manifest files of components to be used by build system llvm-build, that is responsible for loading, verifying, and manipulating the project's component data.
  • A Package Manager for Curry

    A Package Manager for Curry

    A Package Manager for Curry Jonas Oberschweiber Master-Thesis eingereicht im September 2016 Christian-Albrechts-Universität zu Kiel Programmiersprachen und Übersetzerkonstruktion Betreut durch: Prof. Dr. Michael Hanus und M.Sc. Björn Peemöller Eidesstattliche Erklärung Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig ver- fasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Kiel, Contents 1 Introduction 1 2 The Curry Programming Language 3 2.1 Curry’s Logic Features 3 2.2 Abstract Curry 5 2.3 The Compiler Ecosystem 6 3 Package Management Systems 9 3.1 Semantic Versioning 10 3.2 Dependency Management 12 3.3 Ruby’s Gems and Bundler 16 3.4 JavaScript’s npm 19 3.5 Haskell’s Cabal 21 4 A Package Manager for Curry 25 4.1 The Command Line Interface 26 4.2 What’s in a Package? 29 4.3 Finding Packages 35 4.4 Installing Packages 37 4.5 Resolving Dependencies 38 vi A Package Manager for Curry 4.6 Interacting with the Compiler 43 4.7 Enforcing Semantic Versioning 46 5 Implementation 51 5.1 The Main Module 52 5.2 Packages and Dependencies 56 5.3 Dependency Resolution 58 5.4 Comparing APIs 71 5.5 Comparing Program Behavior 73 6 Evaluation 85 6.1 Comparing Package Versions 85 6.2 A Sample Dependency Resolution 88 6.3 Performance of the Resolution Algorithm 90 6.4 Performance of API and Behavior Comparison 96 7 Summary & Future Work 99 A Total Order on Versions 105 B A Few Curry Packages 109 C Raw Performance Figures 117 D User’s Manual 121 1 Introduction Modern software systems typically rely on many external libraries, reusing func- tionality that can be shared between programs instead of reimplementing it for each new project.
  • A Comprehensive Survey of Trends in Oracles for Software Testing

    A Comprehensive Survey of Trends in Oracles for Software Testing

    1 A Comprehensive Survey of Trends in Oracles for Software Testing Mark Harman, Phil McMinn, Muzammil Shahbaz and Shin Yoo Abstract—Testing involves examining the behaviour of a system in order to discover potential faults. Determining the desired correct behaviour for a given input is called the “oracle problem”. Oracle automation is important to remove a current bottleneck which inhibits greater overall test automation; without oracle automation, the human has to determine whether observed behaviour is correct. The literature on oracles has introduced techniques for oracle automation, including modelling, specifications, contract-driven development and metamorphic testing. When none of these is completely adequate, the final source of oracle information remains the human, who may be aware of informal specifications, expectations, norms and domain specific information that provide informal oracle guidance. All forms of oracle, even the humble human, involve challenges of reducing cost and increasing benefit. This paper provides a comprehensive survey of current approaches to the oracle problem and an analysis of trends in this important area of software testing research and practice. Index Terms—Test oracle; Automatic testing; Testing formalism. F 1 INTRODUCTION undecidable problem. For example, attempting to cover all branches [6], [10], [16], [64], [77], Much work on testing seeks to automate as [159], [177] in a system under test can never be much of the test process as practical and de- complete because branch reachability is known sirable, in order to make testing faster, cheaper to be undecidable in general [192]. and more reliable. In order to automate testing, The problem of generating test inputs to we need an oracle, a procedure that determines achieve coverage of test adequacy criterion what the correct behaviour of a system should has been the subject of research interest for be for all input stimuli with which we wish nearly four decades [48], [106] and has been to subject the system under test.
  • Freertos …What’S New in the Freertos Project

    Freertos …What’S New in the Freertos Project

    FreeRTOS …What’s new in the FreeRTOS project Richard Barry Founder, FreeRTOS Project Principal Engineer, AWS IoT © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Agenda The FreeRTOS Kernel Amazon FreeRTOS New Ecosystem Projects New Architecture Ports © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. FreeRTOS—Open source real time kernel © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. FreeRTOS downloads per month over 15 years 14,000 12,000 10,000 8,000 6,000 Downloads 4,000 2,000 0 Date © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved. gbm java apache (http server) cerebro alks-cli oss-attribution-generator libfabric xen devel cryptography tslint-eslint-rules cynical glib incubator mxnet jruby arrow rollbar linux (kvm) hue rgp netlink gerrit-check web socket sharp cni jgi scapy tabular diaporama packer json11 postcss-extract-animations authenticator fast align tez emscripten lmdbjava gucumber securitymonkey linux-nvme-cli t licensee lombok dovecot smack aalto-xml homebrew nodejs pygresql amphtml flink gpy wing slight.alexa 2018 unicode cldr gpyoptapache phoenix libarchive capybara jcommander tslint appium little proxy typescript-fsa kotlinpoet zipper moby go-git cmock plantuml-syntax esp-open-rtos gradle kuromoji github-plugin cbmc elastalert libsoup eclipse paho mariadb-connector-j kappa irate mysql workbench pyzmq cnn r509-ocsp-responder cocoapods cmis_5 flask-sqlalchemy aws iot devkit tensorboard git git lfs rails fortune server server
  • Interval Temporal Logic

    Interval Temporal Logic

    Interval Temporal Logic Antonio Cau and Ben Moszkowski 2021-04-09 HTML version of the ITL home page Abstract Interval Temporal Logic (ITL) is a flexible notation for both propositional and first-order reasoning about periods of time found in descriptions of hardware and software systems. Unlike most temporal logics, ITL can handle both sequential and parallel composition and offers powerful and extensible specification and proof techniques for reasoning about properties involving safety, liveness and pro- jected time [134]. Timing constraints are expressible and furthermore most imperative programming constructs can be viewed as formulas in a slightly modified version of ITL [125]. Tempura provides an executable framework for developing and experimenting with suitable ITL specifications. In addi- tion, ITL and its mature executable subset Tempura [157] have been extensively used to specify the properties of real-time systems where the primitive circuits can directly be represented by a set of simple temporal formulae. In addition, Tempura has been applied to hardware simulation and other areas where timing is important. 1 Contents 1 Finite Interval Temporal Logic3 1.1 Syntax............................................3 1.2 Semantics..........................................3 1.3 Derived Constructs......................................5 1.4 Propositional proof system..................................7 1.5 First order proof system...................................7 2 Finite and Infinite Interval Temporal Logic8 2.1 Syntax............................................8
  • Mdevtalk-Swiftpm.Pdf

    Mdevtalk-Swiftpm.Pdf

    29.09.2016 HONZA DVORSKY @czechboy0 honzadvorsky.com Swift • created by Apple • announced in June 2014 • open sourced December 2015 • Swift 3.0 - September 2016 Swift Package Manager SwiftPM Listen carefully if you’re… • an iOS/macOS developer • backend developer • an Android developer • interested in what Apple sees as the future of programming Agenda • introduction to SwiftPM • demo • advanced topics [SwiftPM] is a tool for managing the distribution of Swift code. It’s integrated with the Swift build system to automate the process of downloading, compiling and linking dependencies. — swift.org/package-manager SwiftPM is a • dependency manager • build tool • test tool SwiftPM is • command line based • cross-platform (macOS, Linux) • decentralized • opinionated • convention over configuration Where to learn more about it • swift.org/package-manager • github.com/apple/swift-package-manager • Mailing list: swift-build-dev • Slack: https://swift-package-manager.herokuapp.com Swift Package Manager Swift Package Manager Package • is a folder • Package.swift • source files • contains modules Module • collection of source files (e.g. .swift files) • build instructions (e.g. “build as a library”) • e.g. Foundation, XCTest, Dispatch, … Example Package: Environment • 1 library module • 1 test module “I already use CocoaPods/Carthage, is this just another dependency manager?” — you “I already support CocoaPods, how can I support SwiftPM?” — you CocoaPods -> SwiftPM • https://github.com/neonichu/schoutedenapus • converts CocoaPods Spec to Package.swift
  • Issue 2005 2 June 2005

    Issue 2005 2 June 2005

    , . Issue 2005-2 FACS June 2005 A FM E C A A C ~v1 L F (~ T ~J1 ETHODS C 1 BCS R S(:S(: M S Z A UM L I FM SI G E E E E E BCS The Newsletter of the Formal Aspects of 6 FACS Computing Science (FACS) Specialist Group ISSN 0950-1231 , " -40 , . FACS FACTS Iss ue 2005-2 June 2005 :~::;'::i(t::·::!:\,,: h\boJi EACS.FACTS .. '::':--'}U},;"";",::,:::: '}::::-::/:W::::::'" :,:':':t\i{\, '::;:=/';tt::-:· . , . EAG,sFACi,s[ I S$N:Q950~12311 U S ! h ~ Q~W~letter . of ·ihe BQ$ Specialist · (Sfoup 8h .·· FpribaIAsp~ Cts ·otCornputihg ·S§ience(FACS}; 'FACSFAGTS.• is· dfstributed in electronic form !ball FACS members. · .... A~from ';605 : FACS ?A hs ~ lii ' b~ ~clbl: g~~a foJ~\iinesayea 6 Mar c ti : • June; September and December. Submissions are always welcome .. p l g<!s~seetQe <3d¥~rt.. .or1 page2~fo r fU~herde! <! i ls of·yisil thenew§lg!ter .•.• areaOfthe FACS websile [ http: //www .bcs ~facs . org/newsletterr .. .. ............ .- ... -..... -,'- . Back issU~s . of FAGSFA GTS~re avai l ~ bl e t6 .downlda d frorTE The FACS FACTS Tea m . ..,., . Newsletted ::ditor . Paul B6ca [editor@fac;sfacts ci nfol Editori.al Team J61lathanBowerl,J udith Ca rlton, John Cooke; . Kevin Lano., Mike Siannett Colu rn nist~.i •. ' Din es Bj0rn er (The •~ ai l waY.oClm a i r1) ...•. Judith Carlton(Puzzles) " ....... ... Contribqtors .to t h.isJsSU€) ; Dines Bj0mer, Eerke Boiten, Jonathan . Bowen , Judith Ca ri ton, Roger Carsley, J o hn . D E! r ri 9~• . George E lef~er<;lki§ ; J ose ; Fiade i ro , Joh n F i tzg~ta l d, Carroll Morgan, Fiona Polack, F.X.
  • Interval Temporal Logic

    Interval Temporal Logic

    Interval Temporal Logic Antonio Cau, Ben Moszkowski and Hussein Zedan Software Technology Research Laboratory December 6, 2007 HTML version of the ITL home page ITL-course: A not so short introduction to ITL Abstract Interval Temporal Logic (ITL) is a flexible notation for both propositional and first-order reasoning about periods of time found in descriptions of hardware and software systems. Unlike most temporal logics, ITL can handle both sequential and parallel composition and offers powerful and extensible specification and proof techniques for reasoning about properties involving safety, liveness and projected time[15]. Timing constraints are expressible and furthermore most imperative pro- gramming constructs can be viewed as formulas in a slightly modified version of ITL [25]. Tempura provides an executable framework for developing and experimenting with suitable ITL specifications. In addition, ITL and its mature executable subset Tempura [9] have been extensively used to specify the properties of real-time systems where the primitive circuits can directly be represented by a set of simple tempo- ral formulae. In addition, various researchers have applied Tempura to hardware simulation and other areas where timing is important. 1 Syntax The key notion of ITL is an interval. An interval σ is considered to be a (in)finite sequence of states σ0; σ1 :::, where a state σi is a mapping from the set of variables Var to the set of values V al. The length jσj of an interval σ0 : : : σn is equal to n (one less than the number of states in the interval (this has always been a convention in ITL), i.e., a one state interval has length 0).
  • Community Engagement

    Community Engagement

    Community Engagement Annual Report 2016-2017 2 2 2 COMMUNITY ENGAGEMENT ANNUAL REPORT 2016 - 2017 PREPARED FOR COMMUNITY ENGAGEMENT OFFICE APPLIED SCIENCE UNIVERSITY Copyright © 2017 by Applied Science University All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher. NOVEMBER 2017 3 4 CONTENTS UNIVERSITY VISION, MISSION, OBJECTIVES AND VALUES VISION The vision of Applied Science University is to be one of the leading private universities supporting practical learning and scientific research in Bahrain and the Gulf. MISSION ASU is committed to offering an education that is accessible to academically competent students of Bahrain, the Gulf and beyond, and to deliver academic programmes of quality that graduate students equipped with knowledge and skills relevant locally and regionally. ASU is further dedicated to the promotion of a culture of learning and scientific research for its students, staff and faculty regionally and globally to engage meaningfully with the community at large. OBJECTIVES · To acknowledge social responsibility and to serve the local and regional community. · To enhance a superior scientific research standard in all fields of knowledge. · To offer new specializations to meet the market demands. · To maintain abreast of scientific development and to provide all the means of academic success. VALUES · Integrity: ASU’s community values honesty, fairness and academic integrity as fundamental to its vision and mission. It recognizes, affirms and upholds this value in a responsible and committed manner. · Collaboration and Team Spirit: ASU’s community recognizes collaboration and team spirit to be at the heart of the institutional culture and to promote these values in a dedicated manner.