REST

för representational state transfer – ett sätt att programmera webbplatser så att de kan tillhandahålla programtjänster åt andra webbplatser. Detta ska fungera även om webbplatserna har programmerats av utvecklare utan kunskap om varandra eller om den andra webbplatsen. Webbplatserna förses med standardiserade gränssnitt på ett sätt som påminner om hur man gör i objektorienterad programmering. Beteckningen REST infördes år 2000 av Roy Fielding (länk), och har sedan dess blivit det kanske mest använda sättet att bygga upp webbaserade program. Pro­gram och resurser som följer reglerna för REST kallas för RESTful. – Läs mer här och i Wikipedia.

[förkortningar på R] [systemutveckling] [webben] [ändrad 27 mars 2018]

Brooks lag

(Brooks’s law)”Om man sätter in mer personal i ett försenat mjuk­varu­projekt tar det ännu längre tid.” Även: ”Nio kvinnor kan inte få ett barn på en månad.” – Lagen har namn efter Fred Brooks, för­fattare till boken The Mythical Man‑Month, som kom ut 1975. Han skrev där att arbetet som ut­rättas i ett pro­jekt står i direkt pro­portion till an­talet med­arbetare, men pro­jektets kom­plex­itet ökar med kvadraten på an­talet med­arbetare. Alltså tar det längre tid ju fler som är med. – Fred Brooks (1931) var an­ställd på IBM fram till 1965, och ledde där arbetet på operativ­systemet till stor­datorn System 360. 1965 blev han pro­fessor i dataveten­skap på universitetet i Chapel Hill, North Carolina (länk). – Brooks fick 1999 Turingpriset, se denna länk).

[lagar] [projektarbete] [ändrad 6 juli 2017]

objektorientering

programmering som realiseras som objekt i stället för procedurer. Numera det dominerande mönstret för hur man utvecklar större program.

  • – Man ordnar datamängderna i objekt som består både av data som hör ihop på något sätt (till exempel bankkonton) och de instruktioner som används för att bearbeta just dessa data (till exempel beräkna räntan, göra in­sätt­ningar, göra uttag). Dessa kombinationer av data och instruktioner knyts ihop i säckar som kallas för objekt;
  • – Liknelsen med säcken syftar på så kallad inkapsling: när programmeraren väl har skapat ett objekt ska man inte komma åt data och instruktioner i koden direkt, utan bara genom ett antal definierade meddelanden som objektet kan ta emot, utföra och svara på;
  • – Objekten är också ordnade i klasser: en bank kan ha miljoner bank­konton, men man vill inte upprepa samma kod för varje nytt konto. I stället skapas objekt för nya konton som instanser av klassen ”bankkonto”;
  • Klasserna ordnas i en hierarki: överst finns en klass med de egenskaper som alla bankkonton har, sedan finns det underordnade klasser som ärver den överordnade klassens egenskaper, men dessutom har särskilda egen­skaper. Detta kan ske i flera led.

– Det äldre mönstret för programutveckling kallas ibland för procedurorienterat, och innebar att man skilde mellan data och procedurer. Kundens behållning på bankkontot stod i en databas, räntesatsen stod i en annan databas och så fanns det ett program som hämtar siffror från databaserna och beräknade räntan.

– Objektorienterade program i renodlad form kännetecknas av:

  1. – användning av objekt, till exempel ”Nils Nilssons bankkonto”, som innehåller både data om kontot och operationer (metoder) som kan utföras med objektets data;
  2. – användning av meddelanden (metodanrop) – frågor och svar – mellan objekt vid körning av program. Ett objekt är utformat för att ta emot och verkställa endast vissa typer av meddelanden, alla andra meddelanden ignoreras;
  3. – sammanförande av liknande objekt i klasser (”Nils Nilssons bankkonto” hör till klassen ”bankkonton”) som kan ta emot och svara på samma slags meddelanden (till exempel ”beräkna räntan och skicka svaret”);
  4. – ordnande av klasser i hierarkier med arv – klassen ”bankkonton” kan ha subklasser som ”sparkonto” och ”kapitalkonto” som ”ärver” från klassen ”bankkonto” de egenskaper som alla bankkonton har gemensamt, samtidigt som de har en del speciella egenskaper. En ändring i en högre klass ärvs auto­mat­iskt av alla underordnade klasser (om den inte blockeras);
  5. inkapsling som innebär att ett objekt inte kan ”se” in i ett annat objekt. Vill du veta kontoställningen på ”Nils Nilssons bankkonto” måste du skicka ett meddelande till objektet, fråga och begära ett svar. Se metod och attribut.

– Mycket av detta verkar onödigt komplicerat om man tänker sig enklare program, men i stora komplexa system är fördelarna uppenbara. Strikt tillämpning av samtliga principer för objektorientering är inte så vanligt: framför allt är det principen om att olika delar av ett system ska kommunicera genom meddelanden som tillämpas allmänt. De ursprungliga princip­er­na för objektorienterade system utvecklades för slutna datorsystem där man i princip kunde överblicka allt. När det blev vanligt med distribuerade system där ett program i en dator skulle kunna utbyta information med ett program i en annan dator i ett helt annat system måste man utgå från att allt inte är ordnat på samma sätt.

– Objektorienteringens principer formulerades på 1960­-talet av norrmännen Ole-Johan Dahl† och Kristen Nygaard†, och synsättet populariserades av Alan Kay Hans Smalltalk är det programspråk som mest konsekvent tillämpar objektorientering. (Mer spritt är C++.) Vid samma tid var Ivar Jacobson inne på lik­nande tankar. – Läs också om branschorganisationen OMG och Corba.

[systemutveckling] [ändrad 5 juni 2017]

kravfångst

systematisk insamling av de krav som ska ställas på en produkt eller tjänst. – På engelska requirements capture eller requirements capturing (observera plural-s:et). – En metod för kravfångst är användningsfall. – Se också kravfångare och kravhanterare.

Scrum

metodik för ledning av systemutveckling, avsedd för snabb utveckling av system med specifikationer som kan förändras under arbetets gång. – Man utvecklar potentiellt levererbara system i perioder på två till fyra veckor. Efter varje period fastställs nya krav som införs i systemet under nästa omgång. Detta upprepas tills produkten är klar. – Scrum förknippas med så kallad agil systemutveckling, men är förenligt med flera metoder och filosofier för systemutveckling: det är ett sätt att styra arbetet och samla upp lösa trådar. Scrum är iterativt och inkrementellt. – Scrum utvecklades av Jeff Sutherland och Ken Schwaber (externa länkar) i början av 1990-talet. – Läs också om scrummerfall och om DevOps.

[systemutveckling] [ändrad 18 december 2018]

refaktorisering

(refactoring) – i systemutveckling: att strukturera om programkod så att den bli mer överskådlig och systematisk. Detta ska inte förändra kodens funktion. I agil systemutveckling är refaktorisering ett löpande inslag i arbetet. – Benämningen refaktorisering syftar på faktorerna i multi­pli­ka­tion: 16⨯42=672 blir efter refaktorisering kanske 21⨯32=672. Faktorerna byts ut, men produkten förändras inte. – Kallas också för omstrukturering av kod eller omfaktorisering.

 

DevOps

i systemutveckling: en rörelse som vill minska av­ståndet mellan ut­vecklare och it-drift. (Developers och operations.) – Idén an­knyter till agil systemutveckling. – Strävar bland annat efter att hantera para­doxen att de som sköter datadriften vill ha stabila system som inte för­ändras eller beter sig oför­ut­säg­bart, medan ut­vecklarna (i synner­het i agil system­ut­veckling) vill ta sin kod i skarp drift så snart som möjligt för att se hur den fungerar i praktiken. Den motsättningen ska minskas genom att utvecklare och systemansvariga har en löpande dialog, och genom att så mycket som möjligt av installation av nya program och uppdateringar sköts med automatik. – Läs mer om DevOps i Wikipedia. – Läs också om ChatOps, NoOps och kontinuerlig leverans.

[programmering] [systemutveckling] [ändrad 18 december 2018]