DOCSLIB.ORG

Formality, Agility, Security, and Evolution in Software Development

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Formality, Agility, Security, and Evolution in Software Development SOFTWARESTANDARDS TECHNOLOGIES Formality, Agility, Security, and Evolution in Software Development Jonathan P. Bowen, Birmingham City University Mike Hinchey, Lero—the Irish Software Engineering Research Centre, University of Limerick Helge Janicke and Martin Ward, De Montfort University Hussein Zedan, Applied Science University Combining formal and agile techniques in software development has the potential to minimize change-related problems. omplex systems have problems if used carefully, follow- and security are central aspects of always been problematic ing standard patterns of use. Formal the system to be designed. While with respect to software methods have been advocated for im- a formal approach can be used to development. Simplic- proving the correctness of software derive a proof, potentially at great C 1 ity is desirable, but the reality of systems, and agile software develop- cost, a formal specification also pro- dealing with a customer means that ment has been promoted by the Agile vides a framework for undertaking requirements are likely to change, Manifesto (http://agilemanifesto.org) rigorous testing, potentially with resulting in a corresponding loss of and others for enabling adaptive de- cost savings since the specification elegance in the solution. velopment in the face of changing can be used to direct the tests that A good software engineer will requirements, typically introducing are needed.3 Without a formal speci- design with the knowledge that additional complexity in the process. fication, software testing is a much the system is likely to evolve over more haphazard affair. time, even if the exact nature of the FORMALITY Misunderstanding the term changes is unknown. Such exper- Although using formal methods to “formal methods” can also be an tise only comes with experience develop a software system can be issue. The relevance of the formal ap- and an innate aptitude, especially slow and cumbersome, these meth- proach must be understood by every in the understanding and use of ods deliver lower error rates because team member, even if formality won’t abstraction. Software engineering ap- they use a mathematical approach actually be used by everyone. In fact, proaches such as object orientation from the requirements specifica- teaching software engineers to read and modularization—for example, tion onward.2 Formal methods are formal specifications is much easier the Z notation schema construct— an important software engineer- than teaching engineers how to write can help minimize change-related ing technique in cases when safety them. Reading and understanding 86 COMPUTER Published by the IEEE Computer Society 0018-9162/14/$31.00 © 2014 IEEE the specification is necessary for and XP continue their advance into process is similar to the widely most members of a software de- mainstream software development, known agile technique planning velopment team—for example, with sometimes impressive results, poker, which is used to establish programmers and testers—whereas there are still reservations in areas effort estimates for user stories. specification writing requires the in- where security is a paramount The recent adaptation of Micro- volvement of a much smaller number concern to stakeholders. Until rela- soft’s Secure Development Lifecycle of more highly trained people. tively recently there was little focus (SDL) to integrate with agile prod- on how to integrate security best ucts shows that security is a major AGILITY Agile software development pro- vides an iterative approach where It’s necessary to integrate security activities in the the requirements and the associated agile development process and its practices. solution evolve through the collabo- ration of team members, and rapid response to change is encouraged. This contrasts with the traditional practices into agile development, concern for companies employing view of formal methods, but modern although these shortcomings have agile methodologies. The key prob- tools can enable a much more agile existed for at least a decade. lem addressed by Bryan Sullivan approach even within formal devel- To address this problem, it’s is how activities from the SDL can opment. For example, the RODIN tool important to make security re- be integrated effectively into the (http://rodin.cs.ncl.ac.uk) minimizes quirements explicit and to include short-release cycles that charac- the amount of re-proof that is needed security concerns in the product terize agile development projects.6 if the system is changed. Tools like backlog with adequate priority, so This approach divides SDL activi- the Alloy Analyzer (http://alloy.mit. that the concerns continue to be ad- ties into three categories: every edu) are relatively easy for a capable dressed by the development team sprint, such as running automated software engineer to learn and can during the iterations. Agile methods security-analysis tools and updating be quickly used in an agile manner.4 strive to satisfy the customer, which the threat model; bucket require- The concept of agile formal meth- frequently prioritizes the develop- ments consisting of verification ods first appeared in the literature ment of functionality that produces tasks, design review activities, and in the mid-2000s, with events such the primary business value. Secu- response planning; and one-time as the Formal Methods and Agile rity, on the other hand—because it’s requirements such as the develop- Methods (FM+AM) Workshop explic- concerned with managing risk and ment of a baseline threat model. itly addressing the issue.5 In 2009, a preventing the developed function- So, while efforts to integrate position paper on formal methods ality from being misused—is often security practices in agile method- and agile software development was unfortunately not as highly valued ologies are well underway, there published in Computer to highlight and therefore isn’t addressed in is a risk that many actual devel- the debate.4 early sprints. Consequently, it’s nec- opment efforts will ignore these While we don’t really hold the essary to integrate security activities efforts or that development teams view that agility may be used by in the agile development process lack the knowledge and training to “unscrupulous” developers, in and its practices. actually create secure products in general we do believe that agile de- One way to address security the short term. However, agile prin- velopers could benefit from some early in an agile development con- ciples such as communication and training on formal methods, at least text is by using evil stories. This is practices such as pair programming in reading formal specifications, an agile adoption of misuse cases to may help disseminate knowledge even if developers don’t apply the describe the functionality that an at- throughout the development team. approach rigorously. tacker would be able to exploit. The Certification remains a potential development then takes on two di- issue, as it requires detailed and SECURITY mensions: to implement user stories sometimes formal documentation. Can agile methods produce secure and to avoid implementing evil sto- The approach discussed in Sulli- software, perhaps in cases in which ries. Another practice that integrates van’s article6 can help by mandating the security properties have been security principles in agile develop- activities that need to be included formalized? Opinions regarding ment is a technique called protection in every sprint and by requiring this question remain split. While poker, in which security risks are a (scope-reduced) final security agile methodologies such as Scrum quantified by the agile team. This review at the end of each sprint. OCTOBER 2014 87 SOFTWARE TECHNOLOGIES so if a large body of assembler code The transformation process will typ- Formal Informal can be replaced by a smaller amount ically include the following stages: program implementation of high-level language code— specication ideas preserving its correctness without • formal specification; seriously affecting performance— • elaboration of the specification; then the potential savings in the • dividing and conquering to form of software and hardware handle the general case; Program 1 maintenance costs are very large. • recursion introduction; A sound agile approach to soft- • recursion removal, if an itera- ware evolution that is based on tive solution is desired; and Program n transformation theory and associ- • optimization, if required. ated with the industrial-strength FermaT program transformation Subspecifications can be ex- Figure 1. Transformational system has been developed. The ap- tracted and transformed separately programming method of algorithm proach to agility and evolution via at any stage in the process. The derivation. transformation involves four stages: main difference between this ap- proach and the invariant-based EVOLUTION • Translate the assembler to Wide programming approach (and similar Real software systems continually Spectrum Language (WSL). stepwise refinement methods) is that evolve. Their evolution is often in • Translate and restructure data loops can be introduced and manip- response to the evolution of their declarations. ulated while maintaining program environments: new functionalities • Apply generic semantics- correctness with no need to derive are added and/or existing ones are preserving WSL to WSL loop invariants. Another difference removed due to the need to address transformations. is that at every stage in the process, changes
Load more

Recommended publications
  • 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.
    [Show full text]
  • August 2018 FACS a C T S
    Issue 2018-1 August 2018 FACS A C T S The Newsletter of the Formal Aspects of Computing Science (FACS) Specialist Group ISSN 0950-1231 FACS FACTS Issue 2018-1 August 2018 About FACS FACTS FACS FACTS (ISSN: 0950-1231) is the newsletter of the BCS Specialist Group on Formal Aspects of Computing Science (FACS). FACS FACTS is distributed in electronic form to all FACS members. Submissions to FACS FACTS are always welcome. Please visit the newsletter area of the BCS FACS website for further details at: http://www.bcs.org/category/12461 Back issues of FACS FACTS are available for download from: http://www.bcs.org/content/conWebDoc/33135 The FACS FACTS Team Newsletter Editors Tim Denvir [email protected] Brian Monahan [email protected] Editorial Team Jonathan Bowen, John Cooke, Tim Denvir, Brian Monahan, Margaret West. Contributors to this issue Jonathan Bowen, John Cooke, Tim Denvir, Sofia Meacham. Brian Monahan, Bill Stoddart, Botond Virginas, Margaret West BCS-FACS websites BCS: http://www.bcs-facs.org LinkedIn: http://www.linkedin.com/groups?gid=2427579 Facebook: http://www.facebook.com/pages/BCS-FACS/120243984688255 Wikipedia: http://en.wikipedia.org/wiki/BCS-FACS If you have any questions about BCS-FACS, please send these to Paul Boca [email protected] 2 FACS FACTS Issue 2018-1 August 2018 Editorial Dear readers, welcome to our first issue of FACS FACTS for 2018. This year, 2018, marks the 40th anniversary of FACS. At least one editor recalls an article by Dan Simpson, member of the editorial team at the time, FACS at 10 in 1988.
    [Show full text]
  • 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).
    [Show full text]
  • Online Communities: Visualization and Formalization
    Online Communities: Visualization and Formalization Jonathan P. Bowen Museophile Limited, Oxford, UK [email protected] www.jpbowen.com Abstract. Online communities have increased in size and importance dramat- ically over the last decade. The fact that many communities are online means that it is possible to extract information about these communities and the con- nections between their members much more easily using software tools, despite their potentially very large size. The links between members of the community can be presented visually and often this can make patterns in the structure of sub-communities immediately obvious. The links and structures of layered com- munities can also be formalized to gain a better understanding of their modelling. This paper explores these links with some specific examples, including visualiza- tion of these relationships and a formalized model of communities using the Z notation. It also considers the development of such communities within the Com- munity of Practice social science framework. Such approaches may be applicable for communities associated with cybersecurity and could be combined for a better understanding of their development. 1 Introduction The development of collective human knowledge has always depended on communities. As communities have become more computer-based, it has become easier to monitor the activity of such interactions [7]. Recently the increasing use of online communities by the wider population (e.g., for social networking) has augmented the ways that com- munities can form and interact since geographical co-location is now much less critical than before the development of the Internet and the web [1,2].
    [Show full text]
  • Facing the Challenge of Automated Negotiation with Humans
    Facing the Challenge of Automated Negotiation with Humans A dissertation submitted by Angela Fabregues Vinent at Universitat Aut`onomade Barcelona to fulfill the degree of PhD in Computer Science. Bellaterra, September 18th, 2012 Director: Prof. Carles Sierra Tutor: Dr. Josep Puyol Elaborated at: Institut d’ Investigaci´o en Intel·lig`encia Artificial Consejo Superior de Investigaciones Cient´ıficas (IIIA-CSIC) Acknowledgements Voldria agrair a molta gent el temps que ha compartit amb mi aquests darrers anys corresponents a la realitzaciod'aquesta tesi doctoral. Especialment, voldria donar les graciesa en Juan Carlos. Sempre m'has acompanyat. Sempre m'has ajudat. Sempre has estat allaquan t'he necessitat, ja fossis al meu costat o a milles enfora. Ara que nos veim cada dia, esper no te cansis de jo. T'estim! Molts coneixements previs he hagut de menester. Molts altres els he adquirit pel cam.L'escola, l'institut, la carrera i el mastera l'IIIA m'han aportat molts d'ells. Tambeel meu pas per l'empresa privada, per tot arreu s'apren. Els valors, en canvi, s'aprenen a casa. Els vaig aprendre a Menorca graciesals meus pares i tambeals meus germans. Papa! Mama! Me vau donar una infanciaimpressionant, envoltada d'un entorn ple de coses per experimentar sentint-me segura i protegida. Me vau deixar creixer,que formessa meva propia personalitat, que anesagafant responsabilitats, i que fos lliure de decidir per jo mateixa lo que ningumespodia decidir. Vau conar en jo i me vau nancar els estudis a Barcelona. Casi res! Moltes graciesper tot. Bep, amb tu vaig aprendre a enraonar, a donar mil voltes a ses coses i a poder veure-les des de diferents punts de vista.
    [Show full text]
  • Engineering Trustcom/Bigdatase 2018
    2018 17th IEEE International Conference on Trust, Security and Privacy in Computing and Communications/ 12th IEEE International Conference on Big Data Science and Engineering (TrustCom/BigDataSE 2018) New York, New York, USA 31 July - 3 August 2018 Pages 1-650 IEEE Catalog Number: CFP18TRU-POD ISBN: 978-1-5386-4389-1 1/3 Copyright © 2018 by the Institute of Electrical and Electronics Engineers, Inc. All Rights Reserved Copyright and Reprint Permissions: Abstracting is permitted with credit to the source. Libraries are permitted to photocopy beyond the limit of U.S. copyright law for private use of patrons those articles in this volume that carry a code at the bottom of the first page, provided the per-copy fee indicated in the code is paid through Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923. For other copying, reprint or republication permission, write to IEEE Copyrights Manager, IEEE Service Center, 445 Hoes Lane, Piscataway, NJ 08854. All rights reserved. *** This is a print representation of what appears in the IEEE Digital Library. Some format issues inherent in the e-media version may also appear in this print version. IEEE Catalog Number: CFP18TRU-POD ISBN (Print-On-Demand): 978-1-5386-4389-1 ISBN (Online): 978-1-5386-4388-4 ISSN: 2324-898X Additional Copies of This Publication Are Available From: Curran Associates, Inc 57 Morehouse Lane Red Hook, NY 12571 USA Phone: (845) 758-0400 Fax: (845) 758-2633 E-mail: [email protected] Web: www.proceedings.com 2018 17th IEEE International Conference On Trust, Security
    [Show full text]
  • Towards Verified Systems
    TOWARDS VERIFIED SYSTEMS edited by Jonathan Bowen TOWARDS VERIFIED SYSTEMS edited by Jonathan Bow en safemos i This page delib erately left blank for publisher's use ii This page delib erately left blank for publisher's use iii This page delib erately left blank for publisher's use iv This page delib erately left blank for publisher's use Contents Foreword xvii Preface xix Contact Addresses xxiii I Intro duction 1 1 Safety-Critical Systems and Formal Metho ds 3 1.1 A Brief Historical Persp ective ::::::::::::::::::::::::: 3 1.2 Safety-critical Computer Systems ::::::::::::::::::::::: 5 1.2.1 Dep endable computer systems :: :: :: :: :: ::: :: :: :: :: 6 1.2.2 Formal metho ds ::::::::::::::::::::::::::::: 7 1.2.3 The cost of software safety ::::::::::::::::::::::: 9 1.3 Industrial-scale Examples of Use :: ::: :: :: :: :: ::: :: :: :: :: 11 1.3.1 Aviation ::::::::::::::::::::::::::::::::: 12 1.3.2 Railway systems :: :: :: ::: :: :: :: :: ::: :: :: :: :: 13 1.3.3 Nuclear p ower plants :: :: ::: :: :: :: :: ::: :: :: :: :: 13 1.3.4 Medical systems ::::::::::::::::::::::::::::: 14 1.3.5 Ammunition control :: :: ::: :: :: :: :: ::: :: :: :: :: 16 1.3.6 Emb edded micropro cessors ::::::::::::::::::::::: 17 1.4 Areas of Application of Formal Metho ds :: :: :: :: ::: :: :: :: :: 18 1.4.1 Requirements capture ::::::::::::::::::::::::: 19 1.4.2 Design : ::: :: :: :: :: ::: :: :: :: :: ::: :: :: :: :: 19 1.4.3 Compilation ::::::::::::::::::::::::::::::: 20 1.4.4 Programmable hardware :: ::: :: :: :: :: ::: :: :: :: :: 21 1.4.5 Do cumentation :::::::::::::::::::::::::::::
    [Show full text]
  • 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.
    [Show full text]
  • Current Issue of FACS FACTS
    Issue 2021-2 July 2021 FACS A C T S The Newsletter of the Formal Aspects of Computing Science (FACS) Specialist Group ISSN 0950-1231 FACS FACTS Issue 2021-2 July 2021 About FACS FACTS FACS FACTS (ISSN: 0950-1231) is the newsletter of the BCS Specialist Group on Formal Aspects of Computing Science (FACS). FACS FACTS is distributed in electronic form to all FACS members. Submissions to FACS FACTS are always welcome. Please visit the newsletter area of the BCS FACS website for further details at: https://www.bcs.org/membership/member-communities/facs-formal-aspects- of-computing-science-group/newsletters/ Back issues of FACS FACTS are available for download from: https://www.bcs.org/membership/member-communities/facs-formal-aspects- of-computing-science-group/newsletters/back-issues-of-facs-facts/ The FACS FACTS Team Newsletter Editors Tim Denvir [email protected] Brian Monahan [email protected] Editorial Team: Jonathan Bowen, John Cooke, Tim Denvir, Brian Monahan, Margaret West. Contributors to this issue: Jonathan Bowen, Andrew Johnstone, Keith Lines, Brian Monahan, John Tucker, Glynn Winskel BCS-FACS websites BCS: http://www.bcs-facs.org LinkedIn: https://www.linkedin.com/groups/2427579/ Facebook: http://www.facebook.com/pages/BCS-FACS/120243984688255 Wikipedia: http://en.wikipedia.org/wiki/BCS-FACS If you have any questions about BCS-FACS, please send these to Jonathan Bowen at [email protected]. 2 FACS FACTS Issue 2021-2 July 2021 Editorial Dear readers, Welcome to the 2021-2 issue of the FACS FACTS Newsletter. A theme for this issue is suggested by the thought that it is just over 50 years since the birth of Domain Theory1.
    [Show full text]
  • 1 Publications
    1 Publications Chronological list [1] Martin Fränzle. Verification of compilers for recursive occam-like languages. ProCoS Technical Report Kiel MF 8/1, Christian-Albrechts-Universität Kiel, Germany, 1990. [2] Martin Fränzle. Operational failure approximation. In Dines Bjørner, Hans Langmaack, and C. A. R. Hoare, editors, Monograph of the ESPRIT BRA 3104 ProCoS (Provably Correct Systems), pages 165–206. Technical Report, Dept. of Computer Science, Technical University of Denmark, 1992. [3] B. Buth, K.-H. Buth, M. Fränzle, B. von Karger, Y. Lakhneche, H. Langmaack, and M. Müller- Olm. Provably correct compiler development and implementation. In U. Kastens and P. Pfahler, editors, Compiler Construction, volume 641 of Lecture Notes in Computer Science, pages 141–155. Springer-Verlag, 1992. [4] Jonathan P. Bowen, Martin Fränzle, Ernst-Rüdiger Olderog, and Anders P. Ravn. Developing correct systems. In Proc. 5th Euromicro Workshop on Real-Time Systems, Oulu, Finland, pages 176–189. IEEE Computer Society Press, June 1993. [5] Martin Fränzle and Markus Müller-Olm. Drift and granularity of time in real-time system implementation. ProCoS Technical Report Kiel MF 10/2, Christian-Albrechts-Universität Kiel, Germany, August 1993. [6] Martin Fränzle and Burghard von Karger. Proposal for a programming language core for ProCoS II. ProCoS Technical Report Kiel MF 11/3, Christian-Albrechts-Universität Kiel, Ger- many, August 1993. [7] M. R. Hansen, E.-R. Olderog, M. Schenke, M. Fränzle, B. von Karger, M. Müller-Olm, and H. Rischel. A Duration Calculus semantics for real-time reactive systems. ProCoS II document [OLD MRH 1/1], Oldenburg Universität, Germany, September 1993. [8] Martin Fränzle and Markus Müller-Olm.
    [Show full text]
  • August 2014 FACS a C T S
    Issue 2014-1 August 2014 FACS A C T S The Newsletter of the Formal Aspects of Computing Science (FACS) Specialist Group ISSN 0950-1231 FACS FACTS Issue 2014-1 August 2014 About FACS FACTS FACS FACTS (ISSN: 0950-1231) is the newsletter of the BCS Specialist Group on Formal Aspects of Computing Science (FACS). FACS FACTS is distributed in electronic form to all FACS members. Submissions to FACS FACTS are always welcome. Please visit the newsletter area of the BCS FACS website for further details (see http://www.bcs.org/category/12461). Back issues of FACS FACTS are available for download from: http://www.bcs.org/content/conWebDoc/33135 The FACS FACTS Team Newsletter Editors Tim Denvir [email protected] Brian Monahan [email protected] Editorial Team Jonathan Bowen, Tim Denvir. Brian Monahan, Margaret West. Contributors to this Issue Jonathan Bowen, Tim Denvir, Eerke Boiten, Rob Heirons, Azalea Raad, Andrew Robinson. BCS-FACS websites BCS: http://www.bcs-facs.org LinkedIn: http://www.linkedin.com/groups?gid=2427579 Facebook: http://www.facebook.com/pages/BCS- FACS/120243984688255 Wikipedia: http://en.wikipedia.org/wiki/BCS-FACS If you have any questions about BCS-FACS, please send these to Paul Boca <[email protected]> 2 FACS FACTS Issue 2014-1 August 2014 Editorial Welcome to issue 2014-1 of FACS FACTS. This is the first issue produced by your new joint editors, Tim Denvir and Brian Monahan. One effect of the maturity of formal methods is that researchers in the topic regularly grow old and expire. Rather than fill the issue with Obituaries, we have taken the course of reporting on most of these sad events in brief, with references to fuller obituaries that can be found elsewhere, in particular in the FAC Journal.
    [Show full text]
  • When Shannon Met Turing
    DOI: http://dx.doi.org/10.14236/ewic/EVA2017.9 Life in Code and Digits: When Shannon met Turing Tula Giannini Jonathan P. Bowen Dean and Professor Professor of Computing School of Information School of Engineering Pratt Institute London South Bank University New York, USA London, UK http://mysite.pratt.edu/~giannini/ http://www.jpbowen.com [email protected] [email protected] Claude Shannon (1916–2001) is regarded as the father of information theory. Alan Turing (1912– 1954) is known as the father of computer science. In the year 1943, Shannon and Turing were both at Bell Labs in New York City, although working on different projects. They had discussions together, including about Turing’s “Universal Machine,” a type of computational brain. Turing seems quite surprised that in a sea of code and computers, Shannon envisioned the arts and culture as an integral part of the digital revolution – a digital DNA of sorts. What was dreamlike in 1943, is today a reality, as digital representation of all media, accounts for millions of “cultural things” and massive music collections. The early connections that Shannon made between the arts, information, and computing, intuit the future that we are experiencing today. This paper considers foundational aspects of the digital revolution, the current state, and the possible future. It examines how digital life is increasingly becoming part of real life for more and more people around the world, especially with respect to the arts, culture, and heritage. Computer science. Information theory. Digital aesthetics. Digital culture. GLAM. 1. INTRODUCTION 2016, Copeland et al.
    [Show full text]