Kontraktbaseret Programmering Anker Mørk Thomsen 1. udgave ISBN:

Transkript

1 -1 Kontraktbaseret Programmering Anker Mørk Thomsen 1. udgave ISBN:

2 Forord Denne bog er blevet til gennem undervisning i faget Kontraktbaseret Udvikling på bacheloruddannelsen i Softwareudvikling. Emnet har jeg opdelt i to dele. Den første del omfatter konstruktion og udvikling af algoritmer ved at anvende formelle metoder. Denne første del indeholder også diskret matematik, som danner grundlag for at kunne arbejde med de formelle metoder. Bog 1 indeholder pensum for den første del af faget, som kaldes Kontraktbaseret Programmering. Bog 2 Kontraktbaseret Design omhandler design af programmodulerne i et objektorienteret sprog. Januar 2014 Anker Mørk Thomsen 0

3 Indhold I Matematik 9 1 Matematisk argumentation Deduktive argumentationsformer Modus Ponens Modus Tollens Den hypotetiske syllogisme Den disjunktive syllogisme Reductio ad Absurdum Afslutningsvis om argumentation Notation Det direkte bevis Det indirekte bevis Bevis ved modstrid (Proof by contradiction) Bevis ved at opdele i flere tilfælde Simpel Induktion Øvelser Stærk Induktion Strukturel induktion Beviser med fejl Simple og vanskelige påstande Spilteori Øvelser I

4 INDHOLD II 2 Mængder og logik At definere mængder ved hjælp af egenskaber Mængdeoperationer boolsk algebra Boolsk Algebra Kardinalitet Relationer Relationelle databaser Binære relationer Ordningsrelationer Funktioner Venn-diagrammer Øvelser Udsagnslogik Øvelser Boolske operatorer Boolske udtryk Øvelser Regneregler for de boolske operatorer Øvelser Prædikatlogik Øvelser Tilfredsstillelsesmængden Øvelser Kvantificerede udtryk Kvantorer Øvelser Regneregler for kvantificerede udtryk Et-punkts-reglen Sammensætte og adskille termer Sammensætte og adskille rangen Distribution

5 INDHOLD III Den tomme rang Konstant term Øvelser Associativitet Associative operatorer Venstre-associative operatorer Højre-associative operatorer De logiske kvantorer Alkvantoren Eksistenskvantoren Øvelser Mere om prædikater og kvantificerede udtryk II Programkonstruktion 67 5 Imperative Programmer og Programtilstande Lidt om Java Variabler i Java Værdier og referencer Lidt om udførelse af Java-programmer Programtilstande Øvelser Korrekthed Øvelser Hvad er programmering? Specifikationer Øvelser Programnotation Programmeringssprogets kommandoer skip abort Sekvens af kommandoer

6 INDHOLD IV Tilordningskommandoen Selection eller alternativer, IF Iteration eller gentagelse, DO Non-determinisme Klasser og interface-moduler Funktioner Procedurer Eksempler Udvalgssortering Beregning af de første n Fibonacci-tal Øvelser Prædikattransformeren WP Korrekthed Semantik Prædikattransformeren wp Prædikattransformeren wp s egenskaber Øvelser Programmeringssprogets semantik - skip, abort og tilordning Sætningen skip Sætningen abort Tilordningssætningen Øvelser Semantik: Array-variabler Øvelser Programmeringssprogets semantik: Sekvens Programmeringssprogets semantik: IF-sætningen Øvelser Programmeringssprogets semantik: DO-sætningen Kaffekandeproblemet DO-sætningens semantik Øvelser Checklisten for løkker Øvelser

7 INDHOLD V 8 Udvikling af programmer uden løkker At beregne udtryk i tilordningssætninger Øvelser Udvikling af IF-sætninger Øvelser Konstruktion af løkker Konstruktion af løkker Metoden Opsummering af metoden Effektivisering Øvelser At slette en konjunkt Slette en konjunkt Heltalsdivision Beregne heltalsdelen af n Ubegrænset lineær søgning Anvendelser af ubegrænset lineær søgning Sortering af tre værdier Konstruktion af invariant og variant Løkken Begrænset lineær søgning Øvelser Erstatte en konstant med en variabel Erstatte konstanter med variabler Øvelser Beregne heltalsdelen af n Binær søgning generelt Anvendelser af binær søgning Den mest brugte anvendelse af binær søgning Beregne heltalsdelen af n Øvelser Begrænset lineær søgning (igen)

8 INDHOLD VI 12 At forøge en variabels virkefelt At forøge en variabels virkefelt Den sociale bedrager Øvelser A Løsninger til udvalgte øvelser 182

9 Introduktion En kravspecifikation er en aftale mellem systemudvikleren og aftageren. Kravspecifikationen beskriver de egenskaber, der kræves af det færdige produkt. Til brug for skrivning af kravspecifikationer anvendes mange forskellige beskrivelsesværktøjer, hvoraf nogle er formelle og andre er uformelle, dvs. baseret på figurer, tegninger, eksempler, benchmarks og tekstlig beskrivelse. De formelle specifikationer kan være formuleret i diagrammer eller formelle sprog. I praksis anvendes en blanding af de forskellige beskrivelsesformer. Se Søren Lauesen: Software Requirements. Styles and Techniques Lauesen [2000], som indeholder en udførlig beskrivelse af metoder og teknikker til at danne kravspecifikationer i samarbejde med brugere. Bogen indeholder desuden en række gennemarbejdede eksempler. Se også hjemmesiden Søren Lauesen. En kravspecifikation er i denne sammenhæng en aftale mellem systemudvikleren og slutbrugeren. I Kontraktbaseret Udvikling fokuserer vi på aftaler mellem systemudviklere, hvor den ene er klient og den anden aftager. Den samme systemudvikler eller programmør kan have begge roller. Kontrakterne er i Kontraktbaseret Udvikling aftaler om programmodulers funktionelle egenskaber. Lad os antage, at en programmør skal udvikle et programmodul, og at hun har tænkt sig at anvende et modul, som andre har skrevet. Det modul, der skal anvendes kalder vi en server. Det modul, som skal udvikles, kalder vi en klient. I kontraktbaseret udvikling udstyrer vi serveren med en specifikation, der beskriver, i hvilke procestilstande programmøren må anvende modulet. Programmøren, der skal udvikle klienten, skal altså sikre sig, at procedurer og funktioner i serveren kun kaldes i de programtilstande, som er anført i kravspecifikationen som gyldige tilstande. Under forudsætning af, at serveren anvendes korrekt, så skal specifikationen beskrive serverens funktion. Specifikationen skal altså beskrive serverens virkning. Vi siger, at der er en kontrakt mellem klient og server. På den anden side, hvis serveren anvendes forkert, så kan klienten ikke stille krav til serverens funktion. Kontrakten beskriver på den måde, hvad programmet eller programmodulet skal udføre. Det er så programudviklerens opgave at sikre konstruktion af et korrekt program, det vil sige et program, der lever op til kontrakten. Kontrakter indgås altså mellem programudvikleren, som kan være en systemudvikler eller en programmør, og de systemudviklere, der skal anvende programmet til konstruktion af andre programmer. I Kontraktbaseret Udvikling beskæftiger man sig altså ikke med aftaler med slutbrugere. Design af brugergrænsefalden og databasedesign ligger derfor udenfor emneområdet for Kontraktbaseret Udvikling. I forhold til en slutbruger kan det opfattes som en dyd at skrive programmer, der kan acceptere ethvert input, som brugeren kan finde på at anvende. Vi kan godt lide robuste programmer. 1

10 INDHOLD 2 Man kan vejlede eller tvinge slutbrugeren til at gøre det rigtige. Mellem programmoduler er sagen en anden. Her stiller vi eksplicitte krav til klienten. En kontrakt mellem klient og programmør kan være mere eller mindre formaliseret. I mange tilfælde er kontrakter løst formulerede og upræcise. Prøv blot at kigge på dokumentationen af klasserne i Java. Se Java SE 7 API Documentation. En kontrakt kaldes også en specifikation, og den består af mindst følgende to dele: En præbetingelse, der beskriver i hvilke tilstande, programmet eller programdelen må udføres. For en metode er præbetingelsen en beskrivelse af de tilstande 1, hvor man må kalde metoden. Hvis man ikke overholder præbetingelsen, kan man ikke kræve, at programmet opfylder postbetingelsen. Den, der kalder en metode i en ugyldig tilstand, kan ikke stille krav til resultatet. En postbetingelse, der beskriver programmets eller programmodulets resultat. Postbetingelsen beskriver de mulige tilstande, som programmet vil etablere under udførelsen, forudsat at programmet starter udførelsen med præbetingelsen opfyldt. Eksempel 0.1. En procedure, der sorterer en liste af typen Person, kan beskrives uformelt ved en specifikation i stil med /*@ pre Det forudsættes, at alle elementer i listen er af typen post Listen l er sorteret i ikke-aftagende void sorter(list l) hvor pre er præbetingelsen og post er postbetingelsen. Den uformelle specifikation er altså skrevet som en kommentar. Nøgleordt pre angiver præbetingelsen, og nøgleordet post angiver postbetingelsen. Specifikationen anvender JML-syntaks. Se figur Her følger et eksempel på en uformel specifikation af en funktion, der returnerer det største tal i en talrække. Variablen r gør det muligt at referere til funktionens returværdi (resultat). /*@ pre post r >= alle tal i func max(int[] t)->double r 1 En tilstand er en funktion fra mængden af variabler til de tilhørende værdier. Man medtager i beskrivelsen af tilstande kun de variabler, som er berørt af programmet eller programmodulet.

11 INDHOLD 3 Figur 0.0.1: Kontrakt for et program Udover pre- og postbetingelsen består kontrakter for procedurer og funktioner desuden af et hoved, der beskriver modulets navn, metodens parametre og evantuelt returtype. Modulets hoved kaldes ofte modulets signatur. For at anvende modulet (kalde funktionen eller proceduren) korrekt, skal man overholde de typer, som signaturen angiver for parametre og returtype. Signaturen er en syntaktisk specifikation. Præ- og postbetingelser er semantiske specifikationer, som omhandler virkningen af at anvende metoden. Formaliserede kontrakter er formuleret i et matematisk sprog eller i et programmeringssprog og består af udsagn om programmets variabler. Sådanne udsagn kaldes prædikater. Prædikater er udsagn, der kan være sande eller falske. Et prædikat P(x, y) er altså et udsagn eller påstand om variablerne x og y. Udsagnets værdi er enten sand eller f alsk afhængig af indholdet af variablerne x og y. I programmeringsssprog kalder vi ofte prædikater for logiske udtryk eller boolske udtryk. Eksempelvis er x>y+k et prædikat. Sandhedsværdien afhænger af de aktuelle værdier af variablerne x, y og k. I tilstanden {x = 3, y = 2, k = 2} er udtrykket sandt. I tilstanden {x = 3, y = 1, k = 4} er udtrykket falsk.

12 INDHOLD 4 Vi vil arbejde med at formulere kontrakter i form af prædikater. Desuden vil vi anvende de formelle kontrakter på to måder. Vi vil anvende kontrakter som værktøj til at udvikle programmerne, og vi vil anvende kontrakter som grundlag for afprøvning (test) af programmerne. Vi har til hensigt at tilegne os og anvende en teknik, hvor man ud fra en specifikation (kontrakt) konstruerer et program eller et programmodul. Principielt er en specifikation i sig selv et program. Hvis man havde en virtuel maskine til rådighed, som kunne fortolke kontrakten direkte, så ville man slippe for arbejdet med at omforme kontrakten til et andet sprog. I en vis forstand er det netop, hvad man gør i et sprog som SQL. Her beskriver man ikke en beregningsproces. Man beskriver det ønske resultat. F. eks. beskriver select distinct nr from T where T.nr>7 at man ønsker en tabel (relation) med attributten nr. Værdierne i kolonnen nr skal alle være større en 7 og der må ikke forkomme to ens værdier. Værdierne i A skal hentes fra tabellen T. Man kalder også et sprog af denne type for et deklarativt sprog. Man kan med en vis ret sige, at SQL-sætningen er en udførbar specifikation. Hvis vi derimod skriver // T er en given relation create empty relation R foreach (Row r in T){ if (r.nr>7) R.addRow(r) } er der tale om at beskrive en fremgangsmåde til beregning af resultatet. Her er der tale om et imperativt program. Programmet består af en række kommandoer, som skal udføres i en bestemt rækkefølge. De programmer, som vi skal arbejde med, kaldes imperative programmer. Imperative programmer fører under udførelsen computeren fra en starttilstand til en sluttilstand. De fleste af de programmeringssprog, som benyttes i praksis, er imperative, hvor programmerne udføres gennem en række trin, der hver ændrer på computerens tilstand. Der findes dog mange programmeringssprog, der ikke er imperative. Vi har allerede nævnt SQL. Af andre sprogparadigmer kan nævnes funktionelle sprog (f. eks. Lisp og Haskell) og logiksprog (f.eks. Prolog). Se Wikipedia 2. En programs tilstand består af en mængde af benævnte værdier. Navnene kalder vi variabler, og værdierne tages fra de sædvanlige værdimængder: Hele tal, naturlige tal, brøker, tegn osv. 2 Java og C # er også imperative sprog. Der findes også objektorienterede funktionelle sprog.

13 INDHOLD 5 En tilstand er en afbildning (funktion) fra mængden af variabler til værdier, og vi kan beskrive en tilstand ved en tabel: Tilstand 0 : a 23 x 4.5 i 7 Tilstand 1 : a 23 x 5 i 7 Tilstand 0 og Tilstand 1 adskiller sig kun ved værdien af variablen x. Begge tilstande er præcist beskrevet, idet vi kender den præcise værdi af variablerne. Udførelsen af et program kaldes en proces. En program begynder udførelsen i en starttilstand, hvor alle variabler i programmet har givne værdier eller eventuelt ukendte værdier, og programmet slutter udførelsen i en sluttilstand, hvor variablerne har værdier, som er etableret gennem programmets udførelse. I en konkret udførelse kan man eventuelt aflæse disse værdier ved hjælp af en debugger. I nogle tilfælde kan det således ske, at et program må starte i en ukendt tilstand. Et sådant program har en startbetingelse, der er sand, dvs. programmet må udføres i enhver starttilstand. Som programmør og som udvikler er man normalt ikke interesseret i de konkrete tilstande, som et program gennemløber under udførelsen med et givet input. De konkrete tilstande er kun interessante for den, som vil følge udførelsen af programmet med et givet input. I stedet er det interessant at se på forholdet mellem input og output og i de mulige tilstande, som programmet kan være i under udførelsen. De gyldige inputtilstande bekriver vi i en præbetingelse i form af et prædikat, f.eks. x 0 n > 0. Dette prædikat er sandt i alle tilstande, hvor x er støre end eller lig med 0, dvs. alle ikke-negative værdier af x, og hvor n er positiv. Resultatet af et program beskrives i en postbetingelse igen i form af et prædikat, f. eks. x = b[i], dvs. variablen x har samme værdi som variablen b[i]. Prædikater er boolske funktioner dvs. funktioner, der kan antage en af værdierne true og f alse, afhængig af værdierne af de variabler, som ingår i prædikatet. Prædikatet x 0 n > 0 er således f alse i tilstanden {x = 1, n = 2} og true i tilstanden {x = 2, n = 3}. Antag, at b er arrayen int[] b = {2, 4, 2, 4, 1} og x = 2 og i = 2. Så er x = b[i] lig med true. Normalt består undervisningen i programmering i, at man simultant lærer et programmeringssprog og at skrive programmer i dette sprog. Man lærer at gætte, hvad programmerne skal indeholde på grundlag af nogle skabeloner og at afprøve programmerne. Hvis afprøvningen ikke giver det ønskede resultat, udfører man en rettelse (evt. ved et nyt gæt) og gentager afprøvningen. Dette fortsætter, indtil man tror, at programmet er korrekt. I denne bog lærer man at konstruere programmer ved at anvende en teknik, hvor programmers indhold (tekst) kan beregnes. Derved opnår man en større sikkerhed for, at programmerne er korrekte. Lad os se på et eksempel. Funktionen /*@ pre post r er den midterste værdi af x, y og func midt(int x, int y, int z)->int r {... }

14 INDHOLD 6 påstås ifølge specifikationen at returnere den midterste værdi af de tre tal: x, y og z. F. eks skal kaldet midt(7,3,12) returnere værdien 7. Vi har ikke vist kildekoden til funktionens krop. Antallet af forskellige mulige input til midt(x,y,z) er (2 32 ) 3 = En afprøvning af alle mulige input er i praksis umuligt. Ved at vælge en teststrategi, kan vi afprøve udvalgte input. Det kan bruges til at øge tilliden til, at funktionen regner rigtigt. Men vi kan i princippet kun være sikker, hvis alle muligheder er afprøvet. Hvis et input giver en fejl, f. eks. hvis midt(-7,3,12)=-7, så er vi blevet oplyst. Vi ved, at der er en fejl, og vi kan rette i programmet, så fejlen forsvinder. Desværre kan rettelsen give anledning til nye fejl. Læren af dette er. Hvis funktionen regner rigtigt med et givet input, er vi ikke blevet meget klogere. De andre input mangler at blive afprøvet. Gennem afprøvning af programmer kan man i bedste fald afsløre, om der er fejl. Det er generelt ikke muligt gennem afprøvning at afgøre, om et program er korrekt. Den eneste måde, hvorpå vi kan bevise, at funktionen regner rigtigt for alle gyldige input, er ved at studere, hvorledes funktionen er programmeret. Dette kræver, at vi studerer kildekoden. Skal man så ikke anvende test. Jo, test bør være en del af de værktøjer, som vi bruger til at øge sikkerheden for, at vore programmer regner rigtigt. Den teknik, som bogen benytter, er baseret på matematik og især på anvendelse af logik. Det er derfor nødvendigt, at den studerende bliver fortrolig med denne disciplin. Man skal være fortrolig med almindelig algebra (aritmetik), mængdelære, udsagnslogik og prædikatkalkyle for at kunne arbejde med udvikling af programmer efter bogens teknik. Besværet med at lære dette lønner sig, idet man som programmør opnår en større sikkerhed i at skrive korrekte programmere. I tilgift reducerer man den tid, man ellers skulle anvende til test. At udvikle programsystemer til computere er en vanskelig og udfordrende opgave. Hvis kravene til et program er upræcise og uklare, er opgaven også at finde ud af, hvilken opgave programmet skal løse. Upræcise beskrivelser af krav og ønsker til programmer er en kilde til mange fallerede projekter. De fleste har lært programmering baseret på uformelle, tekstlige og til tider upræcise beskrivelser af, hvad programmerne skal udføre. Samtidig har man udviklet programmerne baseret på intuition og gætteri kombineret med erfaring. De fejl, der opstår ved denne fremgangsmåde, kalder man lus (eng. bugs), og man investerer mange kræfter i at finde og rette fejl, kaldet aflusning (eng. debugging). Problemet er, at man ikke kan vide, om en funden fejl er den sidste, eller om rettelse af fejlen har introduceret flere fejl. Ved aflusning af store systemer såsom operativsystemer, store administrative systemere mv. vil man ofte introducere nye fejl. Allerede i 1960 erne blev det klart, at fejlbehæftede programmer var et stort problem. Dette gjaldt ikke mindst operativsystemer. Et operativsystem kunne indeholde omkring 1000 alvorlige fejl. F. eks. udsendte CDC hver uge rettelser til operativsystemet på deres CDV Rettelserne kom på hulkort og fyldte flere hundrede hulkort. Hver rettelsesrunde gav anledning til nye fejl; men antallet af fejl, der skulle rettes hver uge blev mindre og mindre. På et tidpunkt valgte man at udsende en ny version af operativsystemet. Men også applikationer kunne give anledning til alvorlige problemer, hvis programmerne havde fejl. Englænderen C. A. R. Hoare foreslog i artiklen An Axiomatic Basis for Computer Programming Hoare [1969] at indføre en formel matematisk metode til at hjælpe med at skrive

15 INDHOLD 7 korrekte programmer. Det er i stor udstrækning en videreudvikling af denne metode, som bliver præsenteret i denne bog. I bogen A Dicipline of Programming Dijkstra [1976]beskriver E. W. Dijkstra udførligt idéen bag de teknikker, vi skal arbejde med. Bertrand Meyer introducerede i programmeringssproget Eiffel begrebet Design by Contract, hvor man kan forsyne programmer med formelle specifikationer (se f. eks. Meyer [2009]), der fastlægger kravene til input (præbetingelser) og præcise beskrivelser af output (postbetingelser). Disse krav kan så blive kontrolleret under udførelsen af programmet. Kontrol af formelle specifikationer under udførelse af et program svarer til at udføre en test. Hvis udførelsen gennemføres uden fejlreaktioner, har man kun sikret sig, at programmet udføres korrekt med de givne inputdata og i de givne omgivelser. Det beviser ikke, at programmet er korrekt. Vi vil benytte de formelle specifikationer til at konstruere korrekte programmer. På samme måde, som ingeniører anvender matematik som værktøj til at konstruere bygninger, maskiner, broer mv, vil vi anvende matematik til at konstruere programmer. Dette kræver dels, at vi tilegner os de matematiske værktøjer, som skal anvendes til konstruktionen og dels, at vi lærer at skrive præcise formelle specifikationer. Den matematik, som vi benytter os af, kaldes diskret matematik, idet den i modsætning til den matematik, som ingeniører og fysikere benytter sig af, ikke behandler kontinuerte størrelser, men alene arbejder med størrelser, der kan antage diskrete (adskilte) værdier, såsom hele tal og boolske værdier (falsk og sand). Vi anvender diskret matematik, fordi den digitale computer kun kan arbejde med hele tal. Alt, hvad der lagres i en computer og alt, hvad der behandles i en computer, er hele tal. I computeren er tallene repræsenteret på binær form, dvs. hvor kun cifrene 0 og 1 anvendes. Al information i en computer er således kodet ved brug af hele tal. En omfattende præsentation af diskret matematik findes i David Gries og Fred B Schneiders A logical Approach to discrete Math Gries and Schneider [1993]. Den del af diskret matematik, som vi har speciel interesse i er: Mængder Relationer Funktioner Udsagnslogikken Prædikatkalkulen Til brug for programmering vil vi arbejde med: En simpel programnotation, som er en modificeret delmængde af sproget Java. Herved får vi adgang til at afprøve programmerne, hvis dette er ønskeligt. Programsemantik ved brug af prædikattransformeren wp (weakest precondition)

16 INDHOLD 8 Programsemantik er beskrivelsen af virkningen af udførelse af et program. Typisk beskriver man virkningen af de enkelte sætningstyper i sit programmeringssprog. I Java vil vi således beskrive virkningen af tilordningssætninger, if-sætninger og while-sætninger mv. Valget er faldet på wp, da det er et kraftfuldt værktøj, og da det umiddelbart er muligt at anvende wp til at konstruere programmer, der opfylder givne postbetingelser.

17 Del I Matematik 9

18 Kapitel 1 Matematisk argumentation Dette kapitel handler om at kunne forstå og gennemføre en matematisk argumentation for, at et udsagn eller en påstand er sand. En matematisk argumentation for en påstand kaldes et bevis. Det matematiske bevis er baseret på anvendelse af symboler og nogle faste slutningsregler og adskiller sig i præcision og entydighed fra den måde, hvorpå vi argumenterer for en påstand i dagligt sprog. Alligevel er der en klar sammenhæng mellem matematisk bevisførelse og dagligdagens argumentation. Lad os tage et eksempel fra Sherlock Holmes i historien»silver Blaze«Doyle. Sherlock Holmes siger: A dog was kept in the stalls, and yet, though someone had been in and fetched out a horse, the dog had not barked... Obviously the visitor was someone whom the dog knew well... Holmes argumentation indeholder to præmisser. Den første er»hunden gøede ikke ad den besøgende i stalden«. Den anden præmis er implicit, nemlig at»hunde gør ikke af folk, de kender«. De to præmisser medfører, at»hunden kendte den besøgende«. Dette er et eksempel på en type argumentation, som vi kender fra dagligdagen. I matematikken ville man opstille begge præmisser, så det var tydeligt, på hvilket grundlag man drog sin slutning. I matematikken ville man opstille argumenationen således: 1. Præmis. Hunden gøede ikke af den, der kom ind i stalden. 2. Præmis. Hunde gør ikke af folk, de kender. 3. Konklusion. Ergo, hunden kendte den besøgende. Læg mærke til det underforståede alle i præmissen Hunde gør ikke af folk, de kender. Der menes, at alle hunde opfører sig på den måde. Men der kan jo være hunde, som opfører sig anderledes. Nogle hunde ville gø af glæde ved at se en person, som de kender. Men vi udtaler os ikke om rigtigheden af præmisserne. Vi udtaler os kun om argumentationen, dvs. 10

19 KAPITEL 1. MATEMATISK ARGUMENTATION 11 hvis præmisserne er sande, så er slutningen også sand. Sherlock Holmes mener altså, at hans præmisser holder. Og det er netop akilleshælen i hans metode. Måske holder hans præmisser ikke. Selv om resultatet af et argument er forkert, kan selve argumentationen være rigtig. F. eks. Præmis. Alle rige mennesker bor nord for København Præmis. X er rig Konklusion. Altså bor X nord for København Argumentationen er korrekt, men mindst den ene præmis er forkert. Hvilken? Argumentationsformen er et eksempel på en syllogisme. En syllogisme er en logisk slutning, som består af to eller flere præmisser og en konklussion. Præmisserne og konklusionen skal være såkaldte katagoriske udsagn, dvs. udsagn om, at der består en given relation mellem to genstande eller begreber. I eksemplet ovenfor er der en relation mellem rige mennesker og København samt mellem X og rige mennesker. Begrebet rige mennesker er mellembegrebet, som knytter X til København. Se Weston [1992]for mere information om syllogismer. Man kan også hente information om syllogismer på Internet, f. eks. i Den store Danske. Se også Wikipedia. Linket til Wikipedia indeholder en oversigt over forskellige former for syllogismer. På Ludvig Holbergs tid var studiet af syllogismere en vigtig del af universitetsuddannelserne. Her følger et eksempel på en ukorrekt syllogisme hentet fra Ludvig Holbergs skuespil Erasmus Montanus. Rasmus Berg var på besøg i sit hjem, og han ville brillere med det, han havde lært på universitetet. Her er hans syllogisme. En sten kan ikke f lyve Morlille kan ikke f lyve Ergo er morlille en sten Der er ingen egenskab, der forbinder en sten med morlille. At de har samme egenskab, nemlig ikke at kunne flyve gør dem ikke ens. Der er intet mellembegreb som i argumentationen ovenfor på denne side. Her er rig mellembegrebet, der forbinder X med bor nord for København Deduktive argumentationsformer Vi skal se på nogle metoder, som kan anvendes ved argumentation for påstande. Metoderne baseres på det, vi kalder en implikation P Q. Hvis P er sand, så er Q også sand.