unified modeling language

(UML) – ett språk för modellering av objektorienterade program, lanserat 1997 av företaget Rational. Det utvecklades av Grady Booch, Ivar Jacobson och James Rumbaugh. UML antogs 1997 som standard av branschorganisationen OMG, och har blivit branschstandard. Att UML är ett språk för modellering innebär att det inte används direkt för programmering, utan för att beskriva hur programmen ska vara uppbyggda. – Läs mer på uml.org.

[programspråk] [systemutveckling] [ändrad 10 december 2018]

praktik

(practice) – beprövat tillvägagångssätt – ett väl fungerande sätt att lösa en viss typ av problem, grundat på långvarig erfarenhet. Inom system­ut­veck­ling har Ivar Jacobson infört termen practices för systemutveckling som tar till vara tillvägagångssätt från flera filosofier. Främst bygger practicesUnified process, agil systemutveckling och så kallad process improvement.
– Ordet praktik har flera andra betydelser.

[systemutveckling] [ändrad 4 juni 2017]

Objectory

metod för objektorienterad analys och design, skapad av Ivar Jacobson i hans dåvarande företag som också hette Objectory. Typiskt för Objectory var an­vänd­nings­fall, en grundlig analys av alla sätt som ett system kan användas på. Metoden Objectory kombinerades med Rationals ut­veck­lings­verk­tyg efter att Rational köpte företaget Objectory 1995, först under namnet Rational Objectory Process, sedan under namnet Rational Unified Process. Mo­del­le­rings­språket UML bygger till stor del på Objectory. – Rational ingår sedan 2003 i IBM.

[systemutveckling] [ändrad 4 juni 2017]

Semat

Software engineering method and theory – ett enhetligt sätt att beskriva systemutvecklingsmetoder, utvecklat av bland andra Ivar Jacobson. Semat strävar efter att på ett entydigt sätt beskriva de teoretiska grunderna för systemutveckling och tillvägagångssätten vid realisering av system. Semat är till stor del agnostiskt när det gäller teorier och metoder, men rymmer vissa värderingar. Till exempel att agila metoder vanligtvis är bra och att vattenfallsmetoden inte är bra. – Se semat.org.

Jacobson, Ivar

(1939) – svensk expert på systemutveckling och objektorientering. – Ivar Jacobson deltog runt 1970 i utvecklingen av Ericssons AXE‑växel, och formulerade då principer för systemutveckling som anknöt till vad som senare blev känt som objektorienterad systemutveckling. Han blev särskilt känd för metodiken med användningsfall. Jacobson startade 1987 företaget Objectory som 1991 köptes av Ericsson och sedan, 1995, såldes vidare till amerikanska Rational, som i sin tur 2003 blev uppköpt av IBM. Under tiden på Rational utvecklade Jacobson tillsammans med två andra guruer inom objektorientering, Grady Booch och James Rumbaugh, UML, ett beskrivningsspåk för systemutveckling som blivit branschstandard. (De tre guruerna brukade kallas sig för ”The three amigos” efter en film med samma namn, se IMdB, länk.) De har också utvecklat Unified process. Se också practices. – Ivar Jacobson var vice vd på Rational men slutade strax efter dess uppgående i IBM för att bli fristående konsult. Han leder nu Ivar Jacobson International (ivarjacobson.com). – I början av 2010-talet har han tagit initiativ till Semat, ett enhetligt sätt att beskriva systemutvecklingsmetoder.

[it-historia] [ivar jacobson] [personer] [systemutveckling] [ändrad 4 juni 2017]

AXE

  1. digital telefonväxel från Ericsson – den första telefon­växeln i världen som var helt datoriserad. – Första AXE‑växeln byggdes 1976. AXE‑växeln var dator­styrd, men den hanterade analoga (krets­kopp­lade) samtal. AXE har sedan dess an­pas­sats till mobil­tele­foni och data­över­föring, men nämns numera inte i Ericssons mark­nads­­för­ing. – Bok­stäv­er­na AXE står enligt Ericsson inte för något särskilt. De ska uttalas var för sig: A, eX, E. – Utveckl­ingen av AXE-växeln, där bland andra Ivar Jacobson deltog, beskrivs i Bengt-Arne Vedins (1940—2017) bok Teknisk revolt från 1992. – En redogörelse för AXE:s historia finns på Ericssons webbsidor;
  2. aXe – ett verktyg för att testa ifall webbsidor uppfyller krav på tillgänglig­het. Det är ett tillägg som kan installeras i webbläsarna Chrome och Firefox. Verktyget utgår från W3C:s riktlinjer för tillgänglighet och amerikanska statens standarder för upphandling. – Se denna webbsida.

[it-historia] [telefoni] [tillgängligt] [webbpublicering] [ändrad 19 mars 2018]

användningsfall

(use case) – i systemutveckling: inventering av de behov och krav som olika användare – kunder, opera­törer, reparatörer, andra anslutna apparater och maskiner – ställer på ett system. Det är den första fasen i systemutveckling enligt ett synsätt som lanserades av Ivar Jacobson i hans Objectory-metod, och som har anammats i objekt­orienterad systemutveckling, till exempel i UML. Det är en form av kravfångst. – Se videon Use case 2.0. – 2011 kom Ivar Jacobsons bok Use-case 2.0, som kan laddas ner här. Mer på Ivar Jacobsons webbsidor. – Språkligt: Ob­servera att användnings­fall är originaltermen. Use case är den engelska över­­­sättning som Ivar Jacobson själv använder.

[systemutveckling] [ändrad 14 mars 2019]

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]