robusthet

i datorvetenskap: förmåga hos ett it‑system att fungera tillfredsställande, trots fel. Ett robust program ska vid fel inte producera felaktiga utdata, inte krascha och inte gå in i en slinga. – Fel kan vara:

  • – tekniska fel vid programkörningen (en sladd rycks ut, glappkontakt, avbrott i nätverket…);
  • indata som programmet inte kan behandla (fel datatyp, division med noll, andra värden som programmeraren inte har förutsett…)
  • – fel i programkoden.

– Robust programmering går ut på dels att förebygga sådana fel, dels att se till att systemet kan hantera dem. Programmet bör alltså kunna känna igen fel när de uppstår. Programmet bör rapportera fel till användaren, och om möjligt fortsätta med andra delar av programmet tills felet är rättat. (Se abort, retry, ignore, fail?.) – Fyra principer för robust programmering är:

  • – Sjuklig misstänksamhet. Andra kan vara ute efter att missbruka eller sabotera programmet; programmeraren är medveten om att hon själv kan göra fel;
  • Dumhet. Om det går att göra fel så kommer någon användare att göra fel. (Se Murphys lag.) Skriv därför tydliga och lättfattliga felmeddelanden – inte obskyra felkoder;
  • Dölj farliga redskap. Ge inte användarna möjlighet att modifiera programmet;
  • Sådant händer aldrig. – Jo det gör det. Gardera även mot osannolika fel.

– På engelska: robustness.

[datorvetenskap] [fel] [it-system] [15 oktober 2018]

orakel

i testning av datorprogram: verktyg som kan avgöra ifall programmet ger rätt resultat. – I enklare fall är detta trivialt: utvecklaren kan avgöra den saken själv, men när man testar mer komplicerade system kan det vara svårt att kontrollera resultatets riktighet. Algoritmerna som räknade fram resultatet kan ju inte gärna också kontrollera ifall de räknar rätt, eller ifall utvecklaren har tänkt rätt. – Ordet orakel används också om verktyg för kontroll av program som behandlar transaktioner i den materiella världen. Motsvarar en digital registrering av en transaktion verkligen motsvarande händelse i den materiella världen? Om Bilregistrets datorer registrerar att en bil har bytt ägare, hur vet datorerna att bilen verkligen har överlåtits till den nya ägaren, och att den förra ägaren har fått betalt? Hur kan ett postorderföretags datorer kontrollera att kunden verkligen har tagit emot de beställda varorna? Ett verktyg som ger ett tillförlitligt svar på sådana frågor kallas för orakel. Man talar om orakelproblemet, the oracle problem. Det har blivit aktuellt med anledning av smarta kontrakt. – På engelska: oracle. – I antiken var ett orakel (av latinets orare – att tala) ett slags spåman eller spåkvinna som gav vanligtvis svårtolkade och mångtydiga svar på frågor om fördolda ting.

[datorvetenskap] [testning] [ändrad 14 juni 2018]

race condition

ett svårlöst problem vid programkörning: det att resultatet av programkörningen förändras beroende på varierande indata: det kan antingen bero på exakt när indata blir inlästa eller på i vilken ordning de blir inlästa. Detta förutsätts vara något som programmeraren inte kan påverka. Race conditions nämns ofta som exempel på heisenbuggar: när man försöker rätta till dem försvinner de – för att senare återkomma. Att förebygga och rätta till race conditions är ett klassiskt problem i datorvetenskap. Någon etablerad svensk översättning finns inte. – Jämför med data race, se kapplöpning.

[datorvetenskap] [programkörning] [28 maj 2018]

deterministisk

om datorprogram: som ger exakt samma resultat varje gång programmet körs, förutsatt att indata är identiska. Rena matematiska beräkningar är deterministiska (12+3 blir alltid 15), men sökningarGoogle är inte deterministiska. (Som indata räknas då sökorden.) – På engelska: deterministic. – Determinism är den filosofiska åskådningen att allt som händer är förutbestämt, betingat av vad som har hänt tidigare.

[datorvetenskap] [filosofi] [programmering] [ändrad 28 juni 2018]

bysantinska generalsproblemet

i datorvetenskap: utmaningen att få ett it-system att fatta bästa möjliga beslut, som måste verkställas av alla delar av systemet, när det är tänkbart att någon del av systemet lämnar felaktig information eller inte kommunicerar alls. Eller att olika delar av systemet lämnar olika information om samma sak. Problemet formulerades först med tanke på krångel i it‑system. Det bysantinska generalsproblemet är också relevant för så kallade konsensusalgoritmer, alltså algoritmer som fastställer att en viss transaktion eller annan åtgärd är giltig om den godkänns av ett visst antal noder, eller alla, i ett nätverk. – Det bysantiska generalsproblemet har tre delar:

  1. – att få alla delar att medverka till ett välgrundat gemensamt beslut;
  2. – att förhindra att någon del av systemet skickar felaktig eller vilseledande information till andra delar av systemet;
  3. – att hantera eventuell brist på kommunikation (att någon del av systemet inte deltar i arbetet med att lösa problemet).

– Det bysantinska generalsproblemet har namn efter ett scenario där ett antal bysantinska generaler belägrar en stad. De måste komma överens om ifall de ska anfalla staden eller låta bli. Ett anfall kan bli framgångsrikt bara om alla generalerna låter sina arméer anfalla samtidigt (konsensus). Om några generaler anfaller men andra låter bli slutar det med nederlag. Generalerna kan inte träffas, utan skickar budbärare till varandra. Det är nödvändigt att alla generalerna talar om för varandra om de vill anfalla eller avstå. Beslut fattas först när alla har jämfört sina bedömningar med varandra. Man måste ha kommunikation med alla generalerna, och man måste gardera sig mot förräderi: som att någon av generalerna skickar ett besked till några av generalerna och ett annat besked till andra. Man måste också gardera sig mot att budbärarna fifflar med beskeden. – En ingående analys från 1982 av det bysantinska generalsproblemet, författad av Leslie Lamport, Robert Shostak och Marshall Pease, kan laddas ner här. – Kallas också för bysantinska generalerna, på engelska the Byzantine generals problem. – Varför problemet har uppkallats efter just bysantinska generaler är okänt.

  • Byzantine fault – bysantinskt fel – är ett fel som ter sig olika för olika komponenter i ett datorsystem. Det är därför ett problem för systemet att avgöra vad det ska göra åt felet, eller ifall det verkligen är ett fel;
  • Byzantine fault tolerance – bysantinsk feltolerans – system för feltolerans som kan hantera bysantinska fel (se ovan);
  • Byzantine failure – bysantinskt funktionsfel – funktionsfel (det att datorsystemet helt eller delvis slutar att fungera) som orsakas av ett bysantinskt fel.

[datorvetenskap] [fel] [ändrad 9 oktober 2018]

suffixträd

(suffix tree) – systematisk uppställning av alla suffix (betydelse 2) av en teckensträng. Teckensträngen ”ananas”, till exempel, har suffixen ”nanas”, ”anas”, ”nas”, ”as” och ”s”. I ett suffixträd ordnas de på ett sätt som gör det lätt att söka bland dem (det vill säga att datorn kan göra det med så få operationer som möjligt). – Suffixträd har praktisk användning vid sökningar i textmassor, dels i ordbehandling, dels vid sökningar i kemiska formler och i medicinska och biovetenskapliga datamängder. –Läs mer i Wikipedia.

[datorvetenskap] [programmering] [13 juni 2017]

deobfuskering

(deobfuscation) – omvandling av tillkrånglad programkod till pro­gramkod som är lätt att överblicka och förstå. Termen används främst när det gäller programkod som är avsiktligt tillkrånglad, se obfuskering. – En dator­veten­skap­lig artikel om tekniker för deobfuskering finns på denna länk.

[datorvetenskap] [programmering] [26 maj 2017]