1 / 17

Formale Methoden der Systemspezifikation Logische Spezifikation von Hard- und Software

Formale Methoden der Systemspezifikation Logische Spezifikation von Hard- und Software. Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik. Aufbau der Veranstaltung.

dafydd
Télécharger la présentation

Formale Methoden der Systemspezifikation Logische Spezifikation von Hard- und Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Formale Methoden der SystemspezifikationLogische Spezifikation von Hard- und Software Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

  2. Aufbau der Veranstaltung • Blockkurs „Algebraische Spezifikation von Software und Hardware“ • Dr. Markus Roggenbach, Univ. Swansea • voraussichtlich 23.-25.5. und 30.5.-1.6.2008 (n.V.) • wie im SS2007 (VL & Ü) • Vorlesung (2SWS) „Logische Spezifikation“ • diese Veranstaltung • Übungsaufgaben zur VL • Dipl. Inf. Jan Calta, CZ • Bearbeitung zum Bestehen der Prüfung essentiell

  3. Lernziele • Kenntnisse über formale Spezifikationsmethoden zur Festlegung der Funktion von Systemen • Historische Entwicklung, Stärken/Schwächen, Möglichkeiten und Grenzen • Fähigkeiten, diese für praktische Anwendungen einsetzen zu können • Spielbeispiele / realistische Systeme • industrielles Interesse (vgl. IEC61508) • Umgang mit formalen Werkzeugen • Checker, Prover, Transformatoren, …

  4. Einordnung • praktische Informatik • Spezifikation ist Teil der Systementwicklung • Bezug zur theoretischer Informatik • Verwandtes Modul: „Methoden und Modelle des Systementwurfs“ (W. Reisig) • Fokus: hier Spezifikation, dort Modellierung • fließende Übergänge, aber kaum Überlappung • Methodenwissen ähnlich • Weitere Bezüge • Modellbasierte Softwareentwicklung (J. Fischer) • Logik, Spiele und Automaten (M. Grohe) • …

  5. weitere Ankündigungen • Einschreibung in GOYA? • Studien- und Diplomarbeiten • Jobs bei FIRST • Sokrates-Austausch mit UWales@Swansea • Folien in Englisch?

  6. Definition of Terms • System = „something composed“, i.e., everything • here only: computational system (SW/HW) • computation = transformation or transport of information • Specification = written description of a system • „species facere“, making something visible • can be informal or formal (we consider formal specs only) • Formal = in a certain fixed appearance • syntax, semantics, derivation • Logic = principles of reasoning • logos = word, thought, reason • „logic“ can also denote a certain formal language

  7. Specification of Systems • Should be one of the first activities in software development • requirements  specification  modelling  module decomposition  implementation  integration  deployment • Often neglected, mostly only informal • Quality problems, acceptance problems • Specification „a posteriori“

  8. Motivation FIRST: “Understanding and mastering complex systems” Examples: • a video camera • a car control unit • a banking machine system • a mobile phone communication protocol • a fault tolerant computer for routing of trains • an aircraft mission management system • Understanding:Being able to describe what these systems are supposed to do • Mastering: Being able to check whether they do what they are supposed to do  Understanding and mastering human behaviour?

  9. A first example A new video camcorder (“DCR-PC330”) • owner's manual almost incomprehensible • can be found in the internet • typical for such devices • Multifunctional on-off switch: • up: off • down: cycles through "tape", "memory" and "play/edit" mode • Intuitively, tape mode is for video, memory mode for pictures and play mode for viewing recorded material

  10. off tape play dn up up up dn dn memory dn Transition system • How can we formally describe the behaviour of this switch? (Natural language description is ambivalent: What does "cycle" mean? What if I push dn-dn-up-dn?) • Modelling by finite transition system: • States: {off, tape, memory, play} • Transition relations: {up, dn}

  11. Hybrid logic • An alternative way to describe this switch: modal theory (description logic T-Box) (For experts: additional axioms necessary, such as nondeterminism p -> []p) (For nonexperts: I assume you know about propositional logic) tape dn memory up off memory dn play up off play dn tape up off off dn tape  [up] false

  12. Modal logic Classical modal logic does not allow the use of state names. • Boolean properties describing the states: (For experts: additional axioms necessary to inhibit impossible states) (For the experts: this is a boolean encoding with three propositions.In principle, two would be enough, since on  rec  dv ) {tape, memory, play}||- on off||-  on /* on = powered */ {tape, memory}||- rec {play, off}||- rec /* rec = can record */ {tape, play}||- dv {memory, off}||- dv /* dv = head spinning */ • off ||-  on  rec  dv • tape ||- on  rec  dv • memory ||- on  rec  dv • play ||- on  rec  dv

  13. Signature: P={on, rec, dv}, R={up, dn} Language: Some valid properties: • rec  dv  on • on  [up] on • on dn on • dv dn (dv dndv)

  14. Unique description of the behaviour of this switch!? • Questions I might ask: • in which state is the camcorder if I push dn-dn-up-dn? dndnupdn tape or dndnupdn (dv  rec) • can I always switch it off? upon • how long will it stay on if I don't? • In practice, no spec is ever complete! power failure while on shuts system off, power resume brings it to “tape" mode

  15. offbut_hi dn up up up tape play dn dn dn memory pwr_fail offbut_lo pwr_resume • to model power failures, we have to distinguish between the state of the button (but_hi, but_lo) and the state of the camcorder (off, tape,...)

  16. play tape camera switch on but_hi but_lo off dn memory dn,pwr_res dn up up,pwr_fail dn dn on dn • Every model abstracts from details (e.g., there is a little green button within the switch which arrests it in the "off" position) • A model is a means of communication between humans (designers, users, ...) • Structuring the model as parallel hierarchical transition system gives a statechart / state machine diagram

  17. Such models can help in the development of complex systems ("model-driven design") • The more concrete the formalism, the closer it is to an implementation • executable code may be generated from state diagrams • We might add additional information such as timing, communication, variables and such. • Specification as opposed to modeling describes properties of the targeted system • not aiming at a complete description of the system • not aiming at the generation of executable code

More Related