DOCSLIB.ORG

Formal Specification Methods What Are Formal Methods? Objectives Of

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Formal Specification Methods What Are Formal Methods? Objectives Of ICS 221 Winter 2001 Formal Specification Methods What Are Formal Methods? ! Use of formal notations … Formal Specification Methods ! first-order logic, state machines, etc. ! … in software system descriptions … ! system models, constraints, specifications, designs, etc. David S. Rosenblum ! … for a broad range of effects … ICS 221 ! correctness, reliability, safety, security, etc. Winter 2001 ! … and varying levels of use ! guidance, documentation, rigor, mechanisms Formal method = specification language + formal reasoning Objectives of Formal Methods Why Use Formal Methods? ! Verification ! Formal methods have the potential to ! “Are we building the system right?” improve both software quality and development productivity ! Formal consistency between specificand (the thing being specified) and specification ! Circumvent problems in traditional practices ! Promote insight and understanding ! Validation ! Enhance early error detection ! “Are we building the right system?” ! Develop safe, reliable, secure software-intensive ! Testing for satisfaction of ultimate customer intent systems ! Documentation ! Facilitate verifiability of implementation ! Enable powerful analyses ! Communication among stakeholders ! simulation, animation, proof, execution, transformation ! Gain competitive advantage Why Choose Not to Use Desirable Properties of Formal Formal Methods? Specifications ! Emerging technology with unclear payoff ! Unambiguous ! Lack of experience and evidence of success ! Exactly one specificand (set) satisfies it ! Lack of automated support ! Consistency ! Lack of user friendly tools ! A specificand exists that satisfies it ! Ignorance of advances ! Completeness ! High learning curve ! All aspects of specificands are specified ! Requires perfection and mathematical sophistication ! Inference ! Techniques not widely applicable ! Consequences of the specification and properties ! Techniques not scalable of its satisfying specificands are discovered ! Too many in-place tools and techniques © 2001 David S. Rosenblum 1 ICS 221 Winter 2001 Formal Specification Methods Different Kinds of Formal Tool Support for Specification Languages Specification Languages ! Axiomatic specifications ! Modeling ! Defines system in terms of logical assertions ! Editors and word processors ! State transition specifications ! Analysis ! Defines system in terms of states & transitions ! Syntax checking ! Abstract model specifications ! Model checking ! Defines system in terms of mathematical model ! Proving and proof checking ! Algebraic specifications ! Property checking ! deadlock, reachability, data flow, liveness, safety, … ! Defines system in terms of equivalence relations ! Runtime checking ! Temporal logic specifications ! Synthesis ! Defines operations in terms of time-ordered assertions ! Refinement ! Concurrency specifications ! Code generation ! Defines operations in terms of concurrent event occurrences ! Test case and test oracle generation A Closer Look: History of Axiomatic Axiomatic Specification Specification ! Formal specification in which statements in ! Attempts to put program development on a first-order predicate logic are used to define formal basis date at least to John McCarthy’s the semantics of a system and its constituent 1962 paper (w.r.t recursive functions) elements (statements, functions, modules) ! Floyd’s 1967 paper presented the first worked-out approach (in terms of flowcharts) ! Usually taken to mean specification with ! Hoare’s 1969 paper formed the basis for ! Pre-conditions much of the later work in formalized ! Post-conditions development ! Invariants ! Formal specification languages ! Point Assertions ! Formal verification ! Axiomatic semantics of programming languages Axiomatic Specification of Hoare’s Basic Approach Programs P {S} Q (nowadays written {P} S {Q}) {P} S {Q} ! One typically specifies (components of) whole ! If environment of S makes assertion P true programs ! And if S terminates ! S is a program, module, method, etc. ! Then assertion Q must be true ! P is the desired pre-condition of S ! But ! Q is the desired post-condition of S ! If the environment doesn’t establish P, Q need not be true ! The axiomatic semantics of the language of S ! If S doesn’t terminate, Q need not be true comprises Hoare-style axiom schemas for the ! Proving {P} S {Q} establishes partial correctness constituent statements of S ! To establish total correctness, one must also prove that S terminates, which in general is undecidable ! assignments, conditionals, loops, etc. ! Used for verifying S with respect to P and Q © 2001 David S. Rosenblum 2 ICS 221 Winter 2001 Formal Specification Methods A Simple Example of an Axiomatic Specification Hoare’s Axiom Schemas (I) class BankAccount is { public Amount Balance() { … } ! Axiom of Assignment public void Deposit(Amount a) {P[f/x]} x := f {P} // PRE: a > 0; // POST: Balance() = (in Balance()) + a; ! { … } Rules of Consequence ⇒ ⇒ public void Withdraw(Amount a) {P}S{Q} and Q Q’ {P}S{Q} and P’ P // PRE: a > 0 and Balance() >= a; {P}S{Q’} {P’}S{Q} // POST: Balance() = (in Balance()) – a; { … } }; ! Rule of Composition ! Can embellish with open/close, interest, {P}S1{Q} and {Q}S2{R} credit limit, ID/PIN, etc. {P}S1;S2{R} An Example Verification: Hoare’s Axiom Schemas (II) Integer Square Root procedure sqrt(N : Integer; R : out Integer); ! Rule of Iteration P and {C}S{P} S, T : Integer; begin {P}while C do S{not C and P} R := 0; ! P is the loop invariant, which typically must S := 1; be supplied by the specifier T := 1; ! Rules have been defined for other while S <= N loop R := R + 1; common language features T := T + 2; ! arrays, do-until, if-then, if-then-else, S := S + T; subprogram calls, … end loop; end sqrt; Specifying the Specifying the Pre- and Post-Conditions Loop Invariant { pre: N >= 0 } { pre: N >= 0 } begin begin R := 0; R := 0; S := 1; S := 1; T := 1; T := 1; while S <= N loop while S <= N loop { I: (T = 2*R + 1) and (S = (R+1)2) and (R2 <= N) R := R + 1; and (R >= 0) } T := T + 2; R := R + 1; T := T + 2; S := S + T; S := S + T; end loop; end loop; end; end; { post: (R2 <= N < (R+1)2) and (R >= 0) } { post: (R2 <= N < (R+1)2) and (R >= 0) } © 2001 David S. Rosenblum 3 ICS 221 Winter 2001 Formal Specification Methods Verification Via Backward Verification Via Backward Substitution (I) Substitution (II) Apply Rule of Iteration and Rule of Consequence: Apply Axiom of Assignment and Rule of Consequence: begin begin R := 0; R := 0; S := 1; S := 1; T := 1; T := 1; while S <= N loop while S <= N loop 2 2 { I: (T = 2*R + 1) and (S = (R+1)2) and (R2 <= N) { I: (T = 2*R + 1) and (S = (R+1) ) and (R <= N) and (R >= 0) } and (R >= 0) } R := R + 1; I implies { ((T+2) = 2*(R+1) + 1) T := T + 2; and ((S+(T+2)) = ((R+1)+1)2) S := S + T; 2 end loop; and ((R+1) <= N) and ((R+1)>=0) { (T = 2*R + 1) and (S = (R+1)2) and (R2 <= N) and ((S+(T+2)) > N) } ? R := R + 1; and (R>=0) and (S > N) } implies post? T := T + 2; end; S := S + T; { post: (R2 <= N < (R+1)2) and (R >= 0) } end loop; end; Verification Via Backward Anthony Hall’s Seven Myths of Substitution (III) Formal Methods (I) Apply Axiom of Assignment and Rule of Consequence: 1) Formal methods can guarantee that { pre: N >= 0 } software is perfect begin pre implies { (1 = 2*0 + 1) and (1 = (0+1)2) ! How do you ensure the initial spec is perfect? and (02 <= N) and (0>=0) } ? 2) Formal methods are all about program R := 0; proving S := 1; T := 1; ! They’re also about modeling, communication, while S <= N loop analyzing, demonstrating { I: (T = 2*R + 1) and (S = (R+1)2) and (R2 <= N) and (R >= 0) } 3) Formal methods are only useful for safety- R := R + 1; T := T + 2; critical systems S := S + T; ! Can be useful in any system end loop; end; Anthony Hall’s Seven Myths of Anthony Hall’s Seven Myths of Formal Methods (II) Formal Methods (III) 4) Formal methods require highly trained 7) Formal methods are not used on real, mathematicians large-scale software ! Many methods involve nothing more than set theory and logic ! They’re used daily in many branches of 5) Formal methods increase the cost of industry development ! There is evidence that the opposite is true 6) Formal methods are unacceptable to users ! When properly presented, users find them helpful © 2001 David S. Rosenblum 4 ICS 221 Winter 2001 Formal Specification Methods Bertrand Meyer’s Seven Sins Bertrand Meyer’s Seven Sins of the Specifier (I) of the Specifier (II) 1) Noise 4) Contradiction ! the presence in the specification text of an ! the presence in the text of two or more elements element that does not carry information relevant that define a feature of the system in an to any feature of the problem incompatible way ! Includes redundancy and remorse 5) Ambiguity 2) Silence ! the presence in the text of an element that ! the existence of a feature of the problem that is makes it possible to interpret a feature of the not covered by any element of the text problem in at least two different ways 3) Overspecification 6) Forward reference ! the presence in the text of an element that ! the presence in the text of an element that uses corresponds not to a feature of the problem but features of the problem not defined until later in to features of a possible solution the text Bertrand Meyer’s Seven Sins Limits to the Notion of of the Specifier (III) “Correctness” 7) Wishful thinking ! Correctness of a program is always relative ! It’s relative to assumption that compiler is correct, ! the presence in the text of an element which is relative to that defines a feature of the problem in ! Assumption that hardware architecture is correct, such a way that a candidate solution which is relative to ! Assumption that digital approximations of cannot reasonably be validated continuous electromagnetic phenomena are correct, which is relative to ! Assumption that the laws of physics are correct ! In other words, correctness is always a matter of demonstrating consistency of one spec with another, where the latter is assumed to be correct © 2001 David S.
Load more

Recommended publications
  • The Essence Initiative
    The Essence Initiative Ivar Jacobson Agenda Specific Problems A Case for Action - Defining a solid theoretical base - Finding a kernel of widely agreed elements Using the Kernel Final Words Being in the software development business Everyone of us knows how to develop our software, but as a community we have no widely accepted common ground A CASE FOR ACTION STATEMENT • Software engineering is gravely hampered today by immature practices. Specific problems include: – The prevalence of fads more typical of fashion industry than of an engineering discipline. – The lack of a sound, widely accepted theoretical basis. – The huge number of methods and method variants, with differences little understood and artificially magnified. – The lack of credible experimental evaluation and validation. – The split between industry practice and academic research. Agenda Specific Problems A Case for Action - Defining a solid theoretical base - Finding a kernel of widely agreed elements Using the Kernel Final Words The SEMAT initiative Software Engineering Method and Theory www.semat.org Founded by the Troika in September 2009: Ivar Jacobson – Bertrand Meyer – Richard Soley What are we going to do about it? The Grand Vision We support a process to refound software engineering based on a solid theory, proven principles and best practices The Next Steps Defining A Kernel of a solid widely agreed theoretical basis elements There are probably more than 100,000 methods Desired solution: Method Architectureincl. for instance SADT, Booch, OMT, RUP, CMMI, XP, Scrum, Lean, Kanban There are around 250 The Kernel includes identified practices incl such elements as for instance use cases, Requirement, use stories, features, Software system, components, Work, Team, Way-of- working, etc.
    [Show full text]
  • Design by Contract: the Lessons of Ariane
    . Editor: Bertrand Meyer, EiffelSoft, 270 Storke Rd., Ste. 7, Goleta, CA 93117; voice (805) 685-6869; [email protected] several hours (at least in earlier versions of Ariane), it was better to let the computa- tion proceed than to stop it and then have Design by to restart it if liftoff was delayed. So the SRI computation continues for 50 seconds after the start of flight mode—well into the flight period. After takeoff, of course, this com- Contract: putation is useless. In the Ariane 5 flight, Object Technology however, it caused an exception, which was not caught and—boom. The exception was due to a floating- point error during a conversion from a 64- The Lessons bit floating-point value, representing the flight’s “horizontal bias,” to a 16-bit signed integer: In other words, the value that was converted was greater than what of Ariane can be represented as a 16-bit signed inte- ger. There was no explicit exception han- dler to catch the exception, so it followed the usual fate of uncaught exceptions and crashed the entire software, hence the onboard computers, hence the mission. This is the kind of trivial error that we Jean-Marc Jézéquel, IRISA/CNRS are all familiar with (raise your hand if you Bertrand Meyer, EiffelSoft have never done anything of this sort), although fortunately the consequences are usually less expensive. How in the world everal contributions to this made up of respected experts from major department have emphasized the European countries, which produced a How in the world could importance of design by contract report in hardly more than a month.
    [Show full text]
  • Certification of a Tool Chain for Deductive Program Verification Paolo Herms
    Certification of a Tool Chain for Deductive Program Verification Paolo Herms To cite this version: Paolo Herms. Certification of a Tool Chain for Deductive Program Verification. Other [cs.OH]. Université Paris Sud - Paris XI, 2013. English. NNT : 2013PA112006. tel-00789543 HAL Id: tel-00789543 https://tel.archives-ouvertes.fr/tel-00789543 Submitted on 18 Feb 2013 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. UNIVERSITÉ DE PARIS-SUD École doctorale d’Informatique THÈSE présentée pour obtenir le Grade de Docteur en Sciences de l’Université Paris-Sud Discipline : Informatique PAR Paolo HERMS −! − SUJET : Certification of a Tool Chain for Deductive Program Verification soutenue le 14 janvier 2013 devant la commission d’examen MM. Roberto Di Cosmo Président du Jury Xavier Leroy Rapporteur Gilles Barthe Rapporteur Emmanuel Ledinot Examinateur Burkhart Wolff Examinateur Claude Marché Directeur de Thèse Benjamin Monate Co-directeur de Thèse Jean-François Monin Invité Résumé Cette thèse s’inscrit dans le domaine de la vérification du logiciel. Le but de la vérification du logiciel est d’assurer qu’une implémentation, un programme, répond aux exigences, satis- fait sa spécification. Cela est particulièrement important pour le logiciel critique, tel que des systèmes de contrôle d’avions, trains ou centrales électriques, où un mauvais fonctionnement pendant l’opération aurait des conséquences catastrophiques.
    [Show full text]
  • Making Sense of Agile Methods Bertrand Meyer Politecnico Di
    Making sense of agile methods Bertrand Meyer Politecnico di Milano and Innopolis University Some ten years ago, I realized that I had been missing something big in software engineering. I had heard about Extreme Programming early thanks to a talk by Pete McBreen at a summer school in 1999 and another by Kent Beck himself at TOOLS USA in 2000. But I had not paid much attention to Scrum and, when I took a look, noticed two striking discrepancies in the state of agile methods. The first discrepancy was between university software engineering courses, which back then (things have changed) often did not cover agility, and the buzz in industry, which was only about agility. As I started going through the agile literature, the second discrepancy emerged: an amazing combination of the best and the worst ideas, plus much in-between. In many cases, faced with a new methodological approach, one can quickly deploy what in avionics is called Identification Friend or Foe: will it help or hurt? With agile, IFF fails. It did not help that the tone of most published discussions on agile methods (with a few exceptions, notably [1]) was adulatory. Sharing your passion for a novel approach is commendable, but not a reason to throw away your analytical skills. A precedent comes to mind: people including me who championed object-oriented programming a decade or so earlier may at times have let their enthusiasm show, but we did not fail to discuss cons along with pros. The natural reaction was to apply a rule that often helps: when curious, teach a class; when bewildered, write a book.
    [Show full text]
  • Implementing a Transformation from BPMN to CSP+T with ATL: Lessons Learnt
    Implementing a Transformation from BPMN to CSP+T with ATL: Lessons Learnt Aleksander González1, Luis E. Mendoza1, Manuel I. Capel2 and María A. Pérez1 1 Processes and Systems Department, Simón Bolivar University PO Box 89000, Caracas, 1080-A, Venezuela 2 Software Engineering Department, University of Granada Aynadamar Campus, 18071, Granada, Spain Abstract. Among the challenges to face in order to promote the use of tech- niques of formal verification in organizational environments, there is the possi- bility of offering the integration of features provided by a Model Transforma- tion Language (MTL) as part of a tool very used by business analysts, and from which formal specifications of a model can be generated. This article presents the use of MTL ATLAS Transformation Language (ATL) as a transformation artefact within the domains of Business Process Modelling Notation (BPMN) and Communicating Sequential Processes + Time (CSP+T). It discusses the main difficulties encountered and the lessons learnt when building BTRANSFORMER; a tool developed for the Eclipse platform, which allows us to generate a formal specification in the CSP+T notation from a business process model designed with BPMN. This learning is valid for those who are interested in formalizing a Business Process Modelling Language (BPML) by means of a process calculus or another formal notation. 1 Introduction Business Processes (BP) must be properly and formally specified in order to be able to verify properties, such as scope, structure, performance, capacity, structural consis- tency and concurrency, i.e., those properties of BP which can provide support to the critical success factors of any organization. Formal specification languages and proc- ess algebras, which allow for the exhaustive verification of BP behaviour [17], are used to carry out the formalization of models obtained from Business Process Model- ling (BPM).
    [Show full text]
  • Behavioral Verification of Distributed Concurrent Systems with BOBJ
    Behavioral Verification of Distributed Concurrent Systems with BOBJ Joseph Goguen Kai Lin Dept. Computer Science & Engineering San Diego Supercomputer Center University of California at San Diego [email protected] [email protected] Abstract grams [4]), whereas design level verification is easier and more likely to uncover subtle bugs, because it does not re- Following condensed introductions to classical and behav- quire dealing with the arbitrary complexities of program- ioral algebraic specification, this paper discusses the veri- ming language semantics. fication of behavioral properties using BOBJ, especially its These points are illustrated by our proof of the alternat- implementation of conditional circular coinductive rewrit- ing bit protocol in Section 4. There are actually many dif- ing with case analysis. This formal method is then applied ferent ways to specify the alternating bit protocol, some of to proving correctness of the alternating bit protocol, in one which are rather trivial to verify, but our specification with of its less trivial versions. We have tried to minimize mathe- fair lossy channels is not one of them. The proof shows that matics in the exposition, in part by giving concrete illustra- this specification is a behavioral refinement of another be- tions using the BOBJ system. havioral specification having perfect channels, and that the latter is behaviorally equivalent to perfect transmission (we thank Prof. Dorel Lucanu for this interpretation). 1. Introduction Many important contemporary computer systems are distributed and concurrent, and are designed within the ob- Faced with increasingly complex software and hardware ject paradigm. It is a difficult challenge for formal meth- systems, including distributed concurrent systems, where ods to handle all the features involved within a uniform the interactions among components can be very subtle, de- framework.
    [Show full text]
  • Object-Oriented Software Construction
    Quotes from∗ Object-Oriented Software Construction Bertrand Meyer Prentice-Hall, 1988 Preface, p. xiv We study the object-oriented approach as a set of principles, methods and tools which can be instrumental in building \production" software of higher quality than is the norm today. Object-oriented design is, in its simplest form, based on a seemingly elementary idea. Computing systems perform certain actions on certain objects; to obtain flexible and reusable systems, it is better to base the structure of software on the objects than on the actions. Once you have said this, you have not really provided a definition, but rather posed a set of problems: What precisely is an object? How do you find and describe the objects? How should programs manipulate objects? What are the possible relations between objects? How does one explore the commonalities that may exist between various kinds of objects? How do these ideas relate to classical software engineering concerns such as correct- ness, ease of use, efficiency? Answers to these issues rely on an impressive array of techniques for efficiently producing reusable, extendible and reliable software: inheritance, both in its linear (single) and multiple forms; dynamic binding and poly- morphism; a new view of types and type checking; genericity; information hiding; use of assertions; programming by contract; safe exception handling. Efficient implementation techniques have been developed to allow practical application of these ideas. [T]he book relies on the object-oriented language Eiffel. 4.1 Process and Data (p. 41) A software system is a set of mechanisms for performing certain actions on certain data.
    [Show full text]
  • Title of Presentation
    Essence Kernel Kristian Sandahl Essence/Kristian Sandahl 2021-01-18 2 Software Engineering Method And Theory • A common ground for software engineering • Moving away from SE methods “fashion” industry. • Founded in 2009 by: – Ivar Jacobson – Bertrand Meyer – Richard Soley • OMG Standard under the name Essence • The SEMAT Kernel – manifestation of the common ground Essence/Kristian Sandahl 2021-01-18 3 The Kernel • comprises the central elements for all SE methods; • provides a common language for comparing, applying, and improving methods; • supports progress monitoring; • works in small- and large-scale projects; • works for well documented and less documented projects; • comes with a language and tool for developing practices. • Uptake in China, Russia, South Africa, Japan, Silicon Valley, Florida, Mexico, Germany Essence/Kristian Sandahl 2021-01-18 4 What’s in it for us? • It is highly probable that this will be used much more in the future. • By focusing on the Essentials, the project groups have more freedom and responsibility. • Our students will not become “methodists”. • Taught in TDDE46 Software quality. Essence/Kristian Sandahl 2021-01-18 5 Areas of concern Use and exploitation of the system Specification and development The team and approach of work Essence/Kristian Sandahl 2021-01-18 6 What is an ALPHA? • Alpha is an acronym for an Abstract-Level Progress Health Attribute. • A critical indicator of things that are most important to monitor and progress. Essence/Kristian Sandahl 2021-01-18 7 The Kernel ALPHAs Source of picture: Ivar Jacobson International Essence/Kristian Sandahl 2021-01-18 8 Brief explanation Source of picture: Ivar Jacobson International Essence/Kristian Sandahl 2021-01-18 9 The structure of an ALPHA Source of picture: Ivar Jacobson International Essence/Kristian Sandahl 2021-01-18 10 Requirements– one of the alphas What the software system must do to address the opportunity and satisfy the stakeholders.
    [Show full text]
  • Practice to Perfect: the Quality First Model
    Editor: Bertrand Meyer, EiffelSoft, 270 Storke Rd., Ste. 7, Goleta, CA 93117; voice (805) 685-6869; [email protected] It’s the spiral model. Barry Boehm’s great contribution (“A Spiral Model of Practice Software Development and Enhance- ment,” Computer, May 1988) was to emphasize the need to handle risk in soft- Object Technology ware project management. But Quality To Perfect: First does not use spiral’s idea of repeated analysis-design-implementation cycles. It builds the software, cluster by cluster, using a seamless, reversible process, The Quality as described by Kim Walden in this column (“Reversibility in Software Engineering,” Sept. 1996). First Model It’s just.... Probably not. Few basic ideas are completely new in software; to a certain extent, all had been said in 1974 Bertrand Meyer, EiffelSoft by Edsger Dijkstra, Tony Hoare, Knuth, Harlan Mills, Niklaus Wirth, and a few Ich bin der Geist, der stets verneint, I’ve always worked that way. If that’s others. What counts is how you put the und das mit Recht Mephistopheles really true, congratulations. But I’d like to basic ideas together: what you do, and – Goethe’s Faust, part I (for the trans- see it before I believe it, because some as- also what you don’t do. lation, read on) pects of this process go directly against con- ventional ideas of software development. It’s a personal software process and will not work for large developments. Large aving recently completed a mul- It’s just literate programming. Donald developments are aggregates of personal tiyear writing project, I now Knuth’s literate programming is a great processes, as described by Watts have time to program again.
    [Show full text]
  • 1 an Introduction to Formal Modeling in Requirements Engineering
    University of Toronto Department of Computer Science University of Toronto Department of Computer Science Outline An Introduction to ‹ Why do we need Formal Methods in RE? you are here! Formal Modeling ‹ What do formal methods have to offer? ‹ A survey of existing techniques in Requirements Engineering ‹ Example modeling language: SCR ƒ The language ƒ Case study Prof Steve Easterbrook ƒ Advantages and disadvantages Dept of Computer Science, ‹ Example analysis technique: Model Checking University of Toronto, Canada ƒ How it works ƒ Case Study [email protected] ƒ Advantages and disadvantages http://www.cs.toronto.edu/~sme ‹ Where next? © 2001, Steve Easterbrook 1 © 2000-2002, Steve Easterbrook 2 University of Toronto Department of Computer Science University of Toronto Department of Computer Science What are Formal Methods? Example formal system: Propositional Logic ‹ First Order Propositional Logic provides: ‹ Broad View (Leveson) ƒ a set of primitives for building expressions: ƒ application of discrete mathematics to software engineering variables, numeric constants, brackets ƒ involves modeling and analysis ƒ a set of logical connectives: ƒ with an underlying mathematically-precise notation and (Ÿ), or (⁄), not (ÿ), implies (Æ), logical equality (≡) ƒ the quantifiers: ‹ Narrow View (Wing) " - “for all” $ - “there exists” ƒ Use of a formal language ƒ a set of deduction rules ÿ a set of strings over some well-defined alphabet, with rules for distinguishing which strings belong to the language ‹ ƒ Formal reasoning about formulae in the language Expressions in FOPL ÿ E.g. formal proofs: use axioms and proof rules to demonstrate that some formula ƒ expressions can be true or false is in the language (x>y Ÿ y>z) Æ x>z x+1 < x-1 x=y y=x ≡ "x ($y (y=x+z)) x,y,z ((x>y y>z)) x>z) ‹ For requirements modeling… " Ÿ Æ x>3 ⁄ x<-6 ƒ A notation is formal if: ‹ Open vs.
    [Show full text]
  • Teaching Devops in Academia and Industry: Reflections and Vision
    Teaching DevOps in academia and industry: reflections and vision Evgeny Bobrov1, Antonio Bucchiarone3, Alfredo Capozucca2 Nicolas Guelfi2, Manuel Mazzara1, Sergey Masyagin1 1 Innopolis University, Russian Federation 2 University of Luxembourg 3 Fondazione Bruno Kessler, Trento, Italy Abstract. This paper describes our experience of delivery educational programs in academia and in industry on DevOps, compare the two ap- proaches and sum-up the lessons learnt. We also propose a vision to implement a shift in the Software Engineering Higher Education curric- ula. 1 Introduction DevOps is a natural evolution of the Agile approaches [1,2] from the software itself to the overall infrastructure and operations. This evolution was made pos- sible by the spread of cloud-based technologies and the everything-as-a-service approaches. Adopting DevOps is however more complex than adopting Agile [3] since changes at organisation level are required. Furthermore, a complete new skill set has to be developed in the teams [4]. The educational process is therefore of major importance for students, developers and managers. DevOps way of working has introduced a set of software engineering activities and corresponding supporting tools that has disrupted the way individual devel- opers and teams produce software. This has led both the world of research and industry to review software engineering life-cycle and all the supporting tech- niques to develop software in continuous operation and evolution. If we want to enclose DevOps in one word, it is continuous. Modelling, integration, testing, and delivery are significant part of DevOps life-cycle that, respect to enterprise or monolithic applications developed some years ago, must be revised contin- uously to permit the continuous evolution of the software and especially an easy adaptability at context changes and new requirements.
    [Show full text]
  • Object- Oriented Software Composition
    Oscar Nierstrasz and Dennis Tsichritzis, Object-Oriented Software Composition, Prentice Hall, 1995. Reproduced with the permission of the Publisher, Prentice Hall (a Pearson Education company). This work is protected by copyright and may not be reproduced other than when downloaded and viewed on a single Central Processor Unit (CPU) for private use only. It is not otherwise to be reproduced or transmitted or made available on a network without prior written permission of Prentice Hall. All other rights reserved. Object- Oriented Software Composition EDITED BY Oscar Nierstrasz UNIVERSITY OF BERNE AND Dennis Tsichritzis UNIVERSITY OF GENEVA First published 1995 by Prentice Hall International (UK) Ltd Campus 400, Maylands Avenue Hemel Hempstead Hertfordshire, HP2 7EZ A division of Simon & Schuster International Group © Prentice Hall 1995 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 prior permission, in writing, from the publisher. For permission within the United States of America contact Prentice Hall Inc., Englewood Cliffs, NJ 07632 Printed and bound in Great Britain by T.J. Press (Padstow) Ltd, Padstow, Cornwall. Library of Congress Cataloging-in-Publication Data Object-oriented software composition / edited by Oscar Nierstrasz and Dennis Tsichritzis. p. cm.—(The Object-oriented series) Includes bibliographical references and index. ISBN 0-13-220674-9 1. Object-oriented
    [Show full text]