Open post

Mjukvaruprojekt med Kanban

Kanban är ett sätt att visualisera projektarbetet och det är enkelt att komma igång med. Det enda som behövs är post-it-lappar och en whiteboard som sitter centralt så att alla kan se den och så att alla ryms kring den. Kanbantavlan används sedan som ett visuellt projektledningsverktyg genom hela mjukvaruprojektet.

Kanbantavlans delar

Backloggen

Första delen av Kanbantavlan består av en Backlog. Det är en lista på alla saker som behöver göras. Varje sak som skall göras skrivs på en Post-it-lapp och placeras i Backloggen på Kanbantavlan.

Ett antal steg

Resterande delar av tavlan består av ett antal steg motsvarande de steg som du tar i din utvecklingsprocess. Föst väljer du en uppgift som skall göras från Backloggen, d.v.s du väljer en Post-it-lapp från Backloggen. Denna lapp skall sedan förflyttas genom varje steg som finns på tavlan. När Post-it-lappen når tavlans slut är funktionen redo att levereras eller driftsättas. Stegen kan t.ex. vara:  "Specificera arbetet", vilket  innebär att bryta ned uppgiften i mindre hanterbara bitar. Uppgifterna som står på lapparna i Backloggen  är oftast alldeles för stora och dessa måste  brytas ner. Nästa steg är att "Göra det" eller  "Implementera det". Och när du väl gjort det blir sista steget att "Verifiera" resultatet innan det levereras till kunden.

Pågår-Klar-kolumner

Varje steg har har en Pågår-kolumn och en Klar-kolumn. Dessa visar vad jag jobbar med nu och vad jag är klar med. Detta är viktigt i Kanban eftersom varje uppgift i Kanban blir klar stegvis och inte i slutet. En anledning till att Klar-kolumnen finns i Kanban är att du verkligen måste tänka till om du verkligen är klar eller ej. Du skall inte flytta lappar hip som hap mellan kolumnerna på tavlan. 

Klar - regler

Varje steg i Kanbantavlan, förutom den första som består av Backloggen, är indelad i kolumnerna Pågår och Klar. Så fort en Post-it-lapp med en uppgift flyttas in till ett nytt steg, t.ex. Implementationssteget, så sätts den i "Pågår". När den är klar flyttas de sedan till "Klar" och väntar där tills den får flyttas in till nästa steg. Men hur vet man när den är klar?

Innan en lapp flyttas från "Pågår" till "Klar" i ett steg så måste arbetet först ha uppfyllt vissa kriterier. Dessa bestäms av dina Klar-regler. Varje steg skall ha sina eget Klar-regler. T.ex. kan reglerna för Specificera-steget säga att "uppgiften skall ha brutits ned i mindre uppgifter som är på mellan 1-3 dagar". Reglerna för Implementationssteget kan vara "kodgranskning gjord, enhetstestning utan fel, integrerad, koden är incheckad osv". Exempel på reglerna för Verifieringssteget kan vara: "Arbetet är satt i produktion i en liten skala, validerad att inga problem uppstod, testad av verklig användare, alla synpunkter lösta osv".

Innan en lapp flyttas från vänster till höger skall någon i teamet kontrollera att Klar-reglerna är uppfyllda. Klar-reglerna kan stå på tavlan direkt efter kolumnerna eller längst ned under respektive kolumn som reglerna gäller för.

WIP-lements

WIP står för Work In Progress och det är ett arbete som pågår men som inte är klart ännu. En Post-it-lapp är ett WIP.

WIP-lements är en siffra som anger det maximala antalet post-it-lappar det får finnas i varje steg.

Varje stegs WIP-lement noteras i varje steg. Siffran säger att det inte får finnas fler lappar/uppgifter totalt i detta steg, dvs sammanlagt i "Pågår" och "Klar"-kolumnerna. Ett undantag är sista kolumnen där siffran endast säger hur många uppgifter som får finnas i "Pågår"-kolumnen. I sista kolumnen får det finnas hur många som helst i "Klar". Wiplementen begränsar alltså arbetet vi arbetar med i varje steg.


Hur man bestämmer dem går vanligtvis till så att man börjar med steget som tar längst tid. Vanligtvis är det "Implementations"-steget. Fundera ut hur många Work In Progress (WIP) som får finnas där. Antalet beror på hur många team-medlemmar det är i projektet.  Man vill att  antalet WIP skall vara ganska lågt, så att arbetet går lätt och flyter på utan stress och utan att någon behöver jobba över, men det skall vara tillräckligt högt för att vi skall får saker gjorda. Sätt  tex 2-3 st per person. En person vill troligtvis inte ha färre än två uppgifter åt gången. Anledningen är att om du kör fast i en uppgift så kan du hoppa till den andra uppgiften.

Nu när du bestämt maximala antalet uppgifter i det största steget kan du börja matcha antalet WIP i de övriga stegen så att flödet genom Kanbantavlan får ett jämnt flöde.

Om arbetet går för fort genom det första steget blir det stockning innan nästa steg. Detta är ett tecken på att du  har för mycket jobb igång och om någonting ändras i projektet (t.ex. nya krav och nya behov hos användaren tillkommer, akuta buggar upptäcks) så är det besvärligt att ändra kurs snabbt. Risken med att ha för många samtidiga uppgifter i ett steg är att du har jobbat med sex sju uppgifter i ett par veckor och upptäcker att hälften skall slänga bort för att de blivit inaktuella nu.

När hastigheten genom tavlan är ganska konstant har vi hittat de mest optimala antalet WIP:s för varje steg.

Det finns modeller för att trimma antalet WIP i varje steg. I boken "Agile Project Management with Kanban" av Eric Brechet" finns ett enkelt kalkylblad för att hantera detta.

Beroenden och blockeringar

Arbeten som beror på andra arbeten, på andra team eller externa parter kan bli blockerade. Du kanske bara har en enda person som kan åta sig just den uppgiften men personen är upptagen med annat  just nu. Du har en WIP, du har en post-it-lapp, men den är blockerad på grund av att vi väntar på någon eller något. Alla känner igen det. En eller flera uppgifter har blivit blockerade. Vi måste hålla koll på dessa på något vis, så att arbetet kan återupptas så fort blockeringen upphört.

Ett sätt att hålla koll på blockerade WIP:ar är att lägga till en ny kolumn i mitten av steget och kalla den nya kolumnen "Håll koll", "Uppsikt" eller "Track". Sätt den blockerade post-it-lappen där och håll koll på den. Vid stand-up så ser alla kring tavlan vilka WIP:ar som är blockerade och alla kan diskutera kring dem.  "Har någon hört hur det går med..., hur går det för dig..., är du klar snart...jag är klar nu och kan börja med det idag...".

Så fort blockeringen är löst flyttas lappen ut igen till "Pågår"-kolumnen igen och ingår i WIP-lemensberäkningen igen. Men om det då är för många lappar i "Pågår" så får den vänta tills det blir ledigt, men så fort det är ledigt så hoppar den ut dit. Man kan tänka att lappen redan har högre prioritet än lappar som vill in från vänster,  eftersom den blockerade lappen redan har varit där tidigare. Det var bara det  att den var blockerad ett litet tag.

Det finns såklart bautastora blockeringar som kan kommer att blockera en  WIP:s i flera månader. Då är det inte lämpligt att ha den i "Track"-kolumnen. Om en lapp sitter där vecka efter vecka och månad efter månad så blir den tillslut ignorerad. Sådana stora blockeringar blir ett projektledningsproblem.

Blockeringar som beror på att bara en enda person sitter på en viss kunskap, eller blockeringar som beror på semestrar, sjukskrivningar, wabbningar o.s.v.  kan förebyggas genom kunskapsspridning i teamet. Försök att inte alltid ge arbetsuppgifter till personen som är stjärna på just den uppgiften. Ge uppgiften till någon annan och låt stjärnan fungera som stöd och mentor istället.

Prioritering av Backloggen

De flesta som arbetat med Backloggar vet att den blir väldigt lång tillslut. Antalet lappar till vänster på tavlan bara växer och växer. Hur skall man kunna sortera dem? Det vanligaste sättet är att Backloggen sorteras genom att sätta de viktigaste lapparna högst upp och de minst viktiga längst ned. Detta rekommenderas i t.ex. Scrum. Det kan fungera väldigt bra. Nackdelen är att när man måste göra omprioriteringar  i projektet (vilket alltid sker) så kan de ta onödigt lång  tid och kännas jobbigt att behöva möblera om alla lapparna på tavlan. Det blir ett hinder. Kanske var det av denna anledning som de, på en arbetsplats jag arbetat på, valde att sortera Backloggen i bokstavsordning, vilket innebar att det inte alls fanns någon logisk ordning bland uppgifterna. Mängder av lapparna blev sittandes i månader utan att det ens diskuterades kring dem.

Ett mycket enkelt sätt att hantera Backloggen på Kanbantavlan är att placera alla lappar som hänger ihop tillsammans i grupper.  Klumpa ihop dem och ha i åtanke "vad skall vi göra sedan".

Varje dag när teamet står vid tavlan och pratar så tittar alla på lapparna, diskuterar med varandra, pratar om lapparna, prioriterar, flyttar runt lapparna osv. Till skillnad mot Scrum så behöver vi i Kanban inte svara på frågorna om vad vi gjorde igår, vad vi skall göra idag och om det finns några hinder. Detta framgår redan av Kanban-tavlan. Det vi talar om kring tavlan är snarare frågor som "Är det någonting som skall läggas till?" och "Behöver vi prioritera om?"  och sedan möblerar vi om lapparna lite snabbt.

Om en kund eller intressent ställer sig framför tavlan kan de enkelt se våra prioriteringar. Säljaren kan säga "Nä hörrni, det är väl viktigare med x än y, kan ni ändra det?". Det är inte komplicerat alls. Det är visuellt och enkelt.

I Scrum är prioriteringarna ganska fixa. Det måste vara så eftersom man jobbar med ett visst antal uppgifter i tidsbegränsade sprintar i Scrum. I Kanban finns inga time-boxar. Det finns istället ett kontinuerligt flöde och man kan leverera varje dag om man så vill. Microsoft levererar nya uppdateringar till sin X-Box varje dag till exempel och det kan de kan göra eftersom de arbetar med Kanban.

Planering och Estimering

Vi har kunder, intressenter och partners (interna och externa) som behöver veta när vi blir klara med saker och ting. De vill kunna planera sitt arbete och kommer med jämna mellanrum att fråga oss när vi blir klara med saker och ting. Det är viktigt att öven i Kanban planera på en hög nivå och att göra estimeringar. Detta kan göras på många sätt t.ex. med Story-points och det är ett alldeles utmärkt sätt att esimera.

På Kanbanvis är det rätt fram att esitmera. Man räknar helt enkelt hur många post-it-lappar, dvs uppgifter, som flödar ut från sista steget på Kanbantavlan  inom en viss tidsperiod, t.ex.  3 - 4 veckor.  Dela antalet lappar som flödade ut med antalet dagar som du räknade över. Detta ger hur många WIPs som teamet gör per dag (benämns som task completion rate).

För att räkna ut när en  viss arbetsprodukt kommer att bli klar så räknar vi först det totala antalet WIP:s för denna arbetsprodukt delat med task completion rate. Totala antalet WIP:s för arbetsprodukten räknas genom att addera

  1. Antal post-it-lappar i backloggen, men dessa är oftast större än en WIP och kommer att brytas ned då den flyttas in i det första steget.  Den behöver en estimering som är intuitiv. Håll upp lappen och fråga alla "om vi skall bryta ned denna hur många post-it-lappar, dvs WIP:ar, tror vi att det kommer att bli?". Folk kan gissa det ganska lätt. Om det verkar svår att intuitivt gissa hur många det blir finns det olika tekniker för detta som till exempel "playing poker"
  2. + Antal post-it-lappar i alla "Pågår"-kolumner på tavlan
  3. + Antal post-it-lappar som är "Blockerade"

Exempel: säg att en kund ringer och undrar när de kommer att få  orderformuläret till deras hemsida levererat. Vi tittar på Kanbantavlan och ser att i gruppen "orderformulär" finns  2 Post-it-lappar i Backloggen. Teamet tror att dessa två lappar kommer att resultera i 5 WIP:s. Vidare ser vi att teamet har  2 pågående WIP:s och 1 WIP som är blockerad. Det blir 8 WIP:s. Säg att WIP:s per dag för teamet är 2. Då beräknar vi 8/2 = 4 dagar. Tid kvar för att färdigställa en grupp av WIP:s = Totalt antal WIP:s för gruppen / Tid per WIP

Litteratur

Om du vill veta mer om Kanban rekommenderar jag boken "Agil Project Management With Kanban" av Eric Brechner.

Open post

De fem kvalitetsperspektiven

Definition av kvalité

Det finns ett antal olika definitioner på mjukvarukvalité. ”Fitness for use” är den mest refererade definitionen och beskrivs i boken ”Jurans Quality Handbook” från 1979. Detta utvidgades senare till ”Fitness of purpose”.  Juran menade att hög kvalité innebär att mjukvaran har alla funktioner som uppfyller kundens behov. Men han menade även att god kvalité dessutom innebär avsaknaden av fel, så att arbetet inte behöver göras om och om igen. God kvalité innebär avsaknaden av missnöjda kunder.  Crosby definierade kvalié som ”conformance to requirements”. Deaming och även Bergman definierade mjukvarukvalité som ”the softwares ability to satisfy the (present and future) needs and expectations of the customers”.  Feigenbaum utvidgade Demings definition och tillade bland annat att produktens pris skulle överensstämma med förväntningarna. ISO definierar kvalitet som: “Quality is the totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs

Problemet med försök att definiera mjukvarukvalitet är att det i princip är omöjligt att i förväg, innan mjukvaran byggts, veta vilka behov användaren har flera månader senare, då mjukvaran levereras. Det är inte lätt att definiera mätbara kvalitetsegenskaper i förväg. Och om vi skulle känna oss nöjda över att ha lyckas definiera mätbara kvalitetskrav i förväg tillsammans med användarna, så har troligtvis användarnas behov ändrats vid leverans, konkurrenter och ny teknik har tillkommit och hela världen ser annorlunda ut.

Garvins fem perspektiv

Professor David Garvin (et al), har gjort ett antal undersökningar av kvalité ur ett flertal olika perspektiv som ekonomiska, marknadsmässiga och filosofiska. Slutsatsen är, kanske inte helt oväntat, att kvalité är komplext och att det inte går att förlita sig på en enda kvalitets-definition. Om man vill undvika att stöta på problem måste man istället se kvalité ur ett antal olika perspektiv, och Professor David Garvin har kommit fram till att det finns fem kvalitetsperspektiv som är gemensamma för alla definitioner av mjukvarukvalite.

  1. Enastående (transcendant): Kvalité kan inte definieras exakt utan är någonting som "känns" och som vi lär oss känna igen av erfarenhet. Det är idealbilden av vad vi vill uppnå, men som förmodligen inte kommer att  uppnås. Ungefär på samma sätt som vi känner igen skönhet eller "jag vet det när jag ser det" eller ”wooow".
  2. Användarbaserat (user based): Kvalité ses utifrån användarens perspektiv. Det skall vara användbart och "kunden/användarna skall vara totalt nöjda”. Den användarbaserade kvalitetssynen är mer konkret än den transcendala synen.
  3. Utvecklings- och tillverkningsbaserat (development and manufacfactoring based): Kvalité ses som "överensstämmelse med kraven”. Det är denna syn som ISO har definierat kvalitet efter. Även CMM Capability Maturity Model, har denna syn. De hävdar att en kvalitets produkt är direkt relaterade till kvaliteten på utvecklingsprocessen.
  4. Produktbaserat (product based): Kvalité  ses som något mätbart och exakt. Produkten eller tjänsten skall innehålla alla nödvändiga funktioner/features och man anser att "god intern kvalité resulterar i god extern kvalité”. Om alla separata delar i den underliggande mjukvaran har god kvalité blir den totala mjukvarans kvalité också god.
  5. Värdebaserat (value based): Kvalitet ställs i relation till kostnader och priset. Det skall finnas funktioner, och ”wow-upplevelser” och användbarhet i mjukvaran till en rimlig kostnad. Även utvecklingsprocessen skall ställas i relation till kostnsderna. ”Quality is the degree of excellence at an acceptable price and the control of variability at an acceptable cost." (R. A. Broh, Managing Quality for Higher Profits, 1982, p. 3)

Om synen på kvalité skiljer sig åt i projektet brukar det värdebaserade perspektivet spela en stor roll. Det värdebaserade kvlitétsperspektivet kan vara budget eller vad kunden är beredd att betala. De övriga perspektiven brukar då få anpassa sig efter detta.

Svårigheten med att uppfylla alla fem perspektiv

Beroende på vilken roll vi har i projekten ser vi olika på kvalitén. En användare kanske värdesätter att systemet är tillförlitligt och att det alltid är tillgängligt. En utvecklare är kanske mer intresserad av att mjukvaran skall vara lätt att underhålla och ha en låg feltäthet. Det kan finnas många fel i koden utan att dessa för den skull påverkar eller stör tillförlitligheten. En säljare kan vara mer intresserad av hur användargränssnittet ser ut och hur enkelt det är att använda. Projektledaren är fokuserad på att alla kundkrav implementeras och att projektet levereras i rätt tid. Ledningsgruppen tycker kanske att det är viktigast att budgeten hålls. Hur vi definierar, ser på och värderar kvalité varierar från projekt till projekt.

I ett projekt som utvecklar styrsystemet hos ett JAS-flygplan skulle kanske några anse att det allra viktigaste är att alla styrfunktionerna måste fungera felfritt medan någon annan anser att det viktigaste är att användargränssnittet är enkelt och intuitivt att använda för piloten. Någon annan anser att dokumentationen är viktigast. 

I ett JAS-projekt är kvalitetsperspektiven inte alls de samma som i projekt som utvecklar ett ordbehandlingsprogram. 

Vilket synsätt skall man välja i ett projekt?

Med alla dessa olika roller och perspektiv i åtanke, är det i princip omöjligt att peka ut en enda definition och ett enda synsätt av mjukvarukvalité som skall passa alla i projektet.

Att försöka uppfylla alla fem perpektiven, för att göra alla nöjda och glada, är ingenting att sträva efter eftersom det då finns en mycket stor risk att projektet blir ett kostsamt evighetsprojekt.

Det uppstår oftast "en dragkamp" om kvalitén inom projektet. Vi drar och stretar åt olika håll vilket resulterar i långa utdragna (ibland meningslösa och mycket kostsamma) diskussioner kring vad som skall göras och hur det skall göras osv.

De fem kvalitétsperspektiven är inte alls absolut ortogonala. Det finns inga skarpa gränser mellan dem, istället går de in i varandra. Det innebär att om ett kvalitétsperspektiv dominerar i ett projekt så fås automatiskt lite av de övriga kvalitéerna på köpet.

Hitta en gemensam syn i projektet

Ett sätt att hitta en gemensam syn och ett gemensamt mål, och för att undvika onödiga slitningar i projektet, är att alla i projektet kommer överens om 1 primärt och 1 sekundärt kvalitétsperspektiv och sedan fokusera på dessa. Jag själv brukar göra på följande vis:

  1. Samla kunder, testare, utvecklare, chefer, VD... ja alla som har något intresse av projektet, i ett rum som har en stor whiteboard.

  2. Brainstorma och skriv på whiteboarden vad alla tycker är bra kvalité. Det kan t.ex. vara "snabbt", "billigt", "lätt att använda", "få resurser", "gedigen dokumentation", "tillförlitligt", "häftigt", "snyggt", "lätt att underhålla", "omfattande hjälp", "räknar rätt" osv.

  3. Diskutera kring alla ord som kommit upp på tavlan och jämför dessa med de fem kvalitetsperspektiven: Produktbaserat, Användarbaserat, Värdebaserat, Enastående, Utvecklingsbaserat.

Kom sedan överens om 1 PRIMÄRT och 1 SEKUNDÄRT kvalitetsperspektiv och fokusera sedan på dessa.

Det har visat sig att om man fokuserar på två kvalitétsperspektiv så får man de resterande med på köpet.

Genom att alla i projektet gemensamt diskuterat och kommit överens om vilka två kvalitétsperspektiv som alla skall fokusera på så går det mycket smidigare att snabbt besluta om vad som skall göras och inte göras. Du slipper både onödigt "tjafs", onödigt arbete, missförstånd och onödiga spänningar i projektet.

Efter ett tag kommer du troligtvis även att märka att ni behöver ändra fokuseringen. Det som var viktigast i början av projektet kanske inte alls är lika viktigt i underhållsfasen.

Lycka till!

Vill du diskutera mer, eller få hjälp och tips i ditt projekt? Kontakta mig. Jag håller workshops eller ingår i ditt team som projektledare eller coach.

References:

Ohlsson N. (1998). Towards Effective Fault Prevention. Department of Computer and Information Science, Linköpings University, Sweden

William Perry. (2000). Effectiv Methods for software testingSecond ed. John Wiley & Sons, Inc.

Quality Assurance Instritute, USA (1999). Common body of knowledge for certified software test engineer (CBOK)
www.affectus.se  

Open post

Hörnstenar för flexibilitet

Vi vill alla ha flexibla system som är lätta att bygga ut och modifiera i framtiden. För att uppnå detta måste vi utveckla system som har egenskaperna hög modularitet, högt sammanhang och låg koppling. Detta är grundprincipen för att ett program eller system skall vara flexibelt.

Med flexibilitet menas att ett system lätt skall kunna modifieras. Om ett system har låg modularitet, lågt sammanhang och hög koppling är det inte flexibelt. Att ändra i en funktion kommer att innebära att ändringar måste göras i andra funktioner som i sin tur innebär att ändringar måste göras osv. Ju mer kod som ändras desto mer sannolikt är det att fel tillförs systemet. Ett flexibelt system består av hög modularitet, högt sammanhang och låg koppling. Om ett system inte är flexibelt är det troligt att man helt enkelt struntar i att göra förändringar i koden. Framtida idéer om förändringar kan gå förlorade.

Hög modularitet

När ett program designas eller kodas skall programmet delas in i ett antal mindre moduler. Om ett program innehåller många moduler säger man att det har hög modularitet. IBM rekommenderar en modulstorlek på mindre än 50 rader kod. En direkt fördel med att begränsa antalet rader är att koden ryms på ett enda A4-ark och ryms på bildskärmen. En annan fördel är relaterad till människans minne. När kod läses skall läsaren lätt kunna plocka ut de viktigaste bitarna ur koden och lägga dem till korttidsminnet.

Högt sammanhang

Varje modul bör designas så att den innehåller en central idé eller ett syfte. Komponenterna som bygger upp denna modul skall endast utföra handlingar som är relevant för att uppfylla modulens syfte. Detta koncept kallas för sammanhang. Det är önskvärt att ha ett högt sammanhang. Idealet är att varje modul i ett system uträttar en, och endast en, definierad funktion inom systemet.

Det finns vissa tumregler för att upptäcka om en funktion/modul har ett högt sammanhang. En regel är att försöka beskriva med en mening vad funktionens uppgift är. Om meningen är enkel och innehåller ett substantiv och ett verb har funktionen ett högt sammanhang. Meningen ”beräkna checksumman och uppdatera PDUn” har lägre sammanhang än meningen ”beräkna checksumman”.

Låg koppling

Koppling är ett mått på växelverkan mellan funktioner eller moduler. Det är önskvärt att ett system har så låg koppling som möjligt. Anledningen är att hög koppling kommer att bidra till att det skapas många vägar som gör det möjligt för ett fel att ”vandra” genom systemet. Om en modul har låg koppling finns det mindre risk att ett fel i en modul sprids vidare till övriga moduler.

Låg koppling kan åstadkommas på många olika sätt, bl a genom att inte låta många variabler skickas mellan funktioner och genom att undvika användning av globala variabler.

Tumregler

Kod skall skrivas så att den blir enkel och läsbar. Enkel kod är motsatsen till komplex kod. Om det tar lång tid att sätta sig in i källkoden, om den är svår att testa eller om det är svårt att modifiera koden, då är koden komplex. Läsbarheten refererar till hur lätt det är att läsa källkoden.

Designerns mål skall vara att designa ett system som har modularitet, högt sammanhang och låg koppling. För att nå dessa mål kan följande enkla tumregler följas:

  1. Kortare är enklare
  2. Färre beslut är enklare
  3. Nästlad logik bör undvikas

Tumregel 1: Kortare är enklare

Ju mindre kod att läsa desto mindre komplex är koden. Det finns studier gjorda för att ta fram faktorer som relaterar till komplexiteten i mjukvaran. Faktorerna är till exempel antalet operatorer och operander i en modul, antalet beslut, loopar mm.
Den mest kraftfulla faktorn att mäta komplexitet är att undersöka hur lång koden är (antalet rader). Ju längre kod ju mer komplex är också koden.

Generellt gäller tumregeln att kortare är enklare, men det finns undantag: om läsbarheten blir sämre på grund av att koden är för kort gäller inte tumregeln.

Tumregel 2: Färre beslut är enklare

Ju fler beslut som en funktion eller modul innehåller desto mer komplex är den. Varje beslut resulterar i minst två olika vägar som kan tas under exekveringen. I bilden nedan visas tre av alla möjliga beslut som ett program kan innehålla. Om det finns många vägar genom programmet ökar risken för fel.

Tumregel 3: Nästlad logik bör undvikas

Allt för mycket nästling i koden är ett tecken på att programmet är komplext. Även om programmeraren använder sig av indragningar i koden så kan det vara mycket svårt att sortera ut de olika nivåerna av if…else:ar. Som riktlinje brukar anges att modulkonstruktioner inte bör nästlas mer än tre eller fyra nivåer djup. Ibland är det möjligt att använda en serie av if-else:ar istället för att nästla dem. if-satser bör ha maximalt nästlingsdjup 3 och maximal längd 7.

 

Open post

OSI/RM

Principen med lager

Kaos i nätverksdjungeln

I mitten av 1970-talet visade det sig att det rådde kaos inom området datakommunikation. Det fanns vid den tiden inget gemensamt ramverk för hur ett datorsystem skulle implementeras. De tidigaste nätverken var enkla och använde sig inte av lager (Black, 1989). Ett typiskt nätverk bestod av en terminal som var kopplad till en dator. I datorn fanns flera program som kontrollerade kommunikationen genom att sända och ta emot data till/från en telefonlinje.

Snart kopplades fler datorer till nätverket och fler applikationer skapades. Varje gång detta skedde behövde kommunikationsprogrammen modifieras och snart blev systemet komplext, storskaligt och ohanterligt. När dessa system skulle förändras hände det allt för ofta att resultatet inte blev det tänkta. Att koppla samman två nätverk var väldigt svårt (om det överhuvud taget gick). Vid denna tidpunkt insåg man att det behövdes en metod för att hantera den komplexitet som uppstår i samband med att datornät utvecklas.

Mot bättre protokoll

I mitten av 1970-talet utvecklades därför OSI/RM (Open System Interconnection Reference Model) för att fungera som ett ramverk vid utveckling av datorsystem. Denna modell är specificerad i dokumentet "Datautbyte mellan öppna system (OSI) - Grundläggande referensmodell" (SS-ISO 7498, 1989).

Ett av målen med OSI/RM är att dela in kommunikationsfunktioner i separata logiska moduler. Genom att analysera en mångfald av funktioner som fanns i typiska datorsystem, kunde man bestämma vilka funktioner som är nödvändiga i ett datorsystem. En arkitekturstruktur som består av sju lager skapades, där varje lager har hand om en specifik funktion.

Ett annat mål med OSI/RM är att definiera en standard som gör att olika system skall kunna kommunicera öppet med varandra, utan att behöva göra några ändringar i protokollen. Black (1989) liknar OSI/RM med att be alla människor i världen att använda samma språk när de talar med varandra.

Lagerprotokoll som är designat enligt OSI/RM kommer att innebära:

  • att komplexiteten minskas genom att systemet delas in i mer begripliga delar (lager).
  • att väldefinierade standardgränssnitt erhålls mellan lagerfunktionerna.
  • symmetri i funktionerna som utförs i varje lager. Varje lager i en nod utför samma funktion som motsvarande lager i andra noder.
  • att förändringar kan göras i ett lager utan att andra lager påverkas.

Modularitet, sammanhang och koppling

Principen med att dela in funktionerna i olika lager härstammar även från principerna som ges för att erhålla strukturerad programmering. Dessa idéer inspirerade till att designa hårdvara och mjukvara så att de har väl definierade gränssnitt. Systemen är indelade i moduler som utför en funktion (eller nära relaterade funktioner) och har högt sammanhangoch låg koppling.

Varierande applikationer

Datorsystem skall resultera i en specifik slutprodukt (eller flera slutprodukter) för användarna. Till exempel kan slutprodukten vara ett system som reglerar temperaturer eller pumpar. Dessa slutprodukter brukar generellt benämnas applikationer.

Applikationerna kan naturligtvis vara många och varierande. OSI/RM utvecklades inte för att vara anpassad till en enda specifik applikation. Tvärtom, utvecklades modellen för att vara anpassad till flera typer av applikationer, dels sådana som går att förutsäga till framtiden och dels sådana som inte går att förutsäga.

OSI-lager som stabil gräns

Precis som det finns ett varierande antal applikationer, finns även ett varierande antal nätverksteknologier, t ex paketförmedlande nätverk, LAN (Local Area Network), satellitnätverk och kabel-TVnätverk. Den snabba utvecklingen av både applikationer och nätverksteknologier får inte hämmas av någon standard.
Likaså måste det vara möjligt för vilken applikation som helst att operera i vilken nätverksteknologi som helst. Det är inte acceptabelt att applikationer måste designas om så fort en ny nätverksteknologi införs. Vidare är det önskvärt att koppla samman nätverk och låta applikationer kommunicera över olika kombinationer av nätverksteknologier.

Bilden nedan illustrerar hur modellen fungerar som en stabil gräns mellan applikationer och det fysiska mediet. Ovanför OSI-lagren kan applikationer operera oberoende av den underliggande nätverksteknologin.

Tjänstekvalitéer

Även om OSI-modellen erbjuder en stabil gräns mellan applikationer och det fysiska mediet, kan det hända att olika applikationer har olika krav på kommunikationen. Till exempel kan det finnas vissa applikationer som kräver att dataöverföringen sker med extremt låg felsannolikhet eller med hög prioritet. Applikationerna behöver därför kunna begära kvalitéer på tjänsterna som det underliggande nätverket har att erbjuda. Dessa tjänstekvalitéer benämns i referensmodellen som QOS (Quality Of Service).

Gemensamma krav

Studier har visat att många applikationer har ett antal gemensamma krav på kommunikationen (Knowlesm fl, 1987). Till exempel behövs det någon form av kontroll av vilken applikation som har tillåtelse att sända data. Applikationer kan även behöva synkroniseringsfunktioner för att hantera fel som uppstår då data förloras i samband med dataöverföringen. Vidare behövs ibland även funktioner som hanterar semantiken, krypterar eller komprimerar.

OSI-arkitektur

OSI-arkitekturen består av de sju lagren som visas i bilden nedan. I bilden kommunicerar applikationerna (AP i bilden) i noderna A och B med varandra. Den tjocka svarta pilen illustrerar den verkliga väg som kommunikationen tar genom nätverket. Applikationerna kommunicerar logiskt direkt med varandra och varje lager i en nod kommunicerar logiskt direkt med motsvarande lager hos en annan nod, vilket illustreras med de streckade linjerna i bilden.

Lagren kan ses som moduler som ligger staplade ovanpå varandra. Ett lager får endast kommunicera med lagren som finns nedanför och ovanför. Till exempel tillåts inte att transportlagret kommunicerar med datalänklagret direkt, utan kommunikationen måste gå via nätverkslagret. Vidare tillåts applikationerna endast tillträde till nätverket via applikationslagret.

Då ett meddelande skall sändas mellan två noder (t ex noderna A och B) i ett nätverk är det mycket vanligt att meddelandet först anländer hos en mellanliggande nod (säg nod C) innan det når slutdestinationen. I sådana fall ser OSI-arkitekturen ut som i bilden nedan. Den verkliga vägen som meddelandena tar från nod A till nod B illustreras med den tjocka svarta pilen i bilden. Observera att bilden visar noder som ingår i samma nätverk och därmed delar samma fysiska länk. I händelse av att flera nätverk är sammankopplade, t ex att nod A tillhör ett nätverk och nod B ett annan, existerar ett fysiskt medium mellan noderna A och C medan ett annat fysiskt medium existerar mellan noderna C och B.

Alla lager ovanför nätverkslagret (lager 3) "ser" inte att meddelandet anländer hos en mellanliggande nod (eller till och med ett annat mellanliggande nätverk) innan meddelandet når slutdestinationen.

De tre lägsta lagren i OSI-modellen brukar kallas för nätverksberoende lager. Nätverkslagret (lager 3) är det högsta lagret i OSI-modellen som är nätverksberoende. Detta lager "döljer" den verkliga nätverksstrukturen för de övre lagren så att dessa blir nätverksoberoende. Nätverkslagret måste därför kunna organisera kommunikationen mellan alla noder på ett sådant sätt att de övre lagren och applikationerna "tycker" att de kommunicerar direkt till den nod som representerar slutdestinationen (se de horisontella linjerna i bilden nedan).

I händelse av att flera nätverk är sammankopplade skall nätverkslagret fungera så att de övre lagren och applikationerna tycker att det endast finns ett underliggande nätverk.

Mellanliggande nod. Lagren 1, 2 och 3 har kunskap om att meddelandet anländer hos den mellanliggande noden C innan meddelandet når slutdestinationen (nod B). Alla lager ovanför lager 3 vet inte att meddelandet anländer hos nod C. De övre lagren har ingen kunskap om nätverkets verkliga struktur och "tycker" att de kommunicerar direkt med nod B.

Gemensamma lagerkoncept

De sju lagren representerar grundstenarna i OSIs referensmodell, vilket beskrevs i föregående avsnitt. Detta avsnitt beskriver koncept som är gemensamma för alla lager. Vad de olika lagren har för uppgifter beskrivs i avsnittet 3.3. "Översikt av de sju lagren".

OSI-omgivning
Enligt referensmodellen innehåller ett verkligt system en eller flera datorer, associerad mjukvara, terminaler, information som överförs, fysiska processer osv som formar en självstyrande enhet som är kapabel att överföra information.

En eller flera applikationsprocesser ingår i OSI-omgivningen. En applikationsprocess kan t ex vara en person som arbetar vid en bankterminal, ett FORTRANprogram som exekveras i en centraldator eller ett kontrollprogram som exekverar i en dator som är kopplad till någon industriell enhet.

Transmissionsmoder
Varje lager kan operera i en förbindelsefri eller förbindelseorienterad transmissionsmod. Den förbindelsefria transmissionen har alltid spelat en viktig roll då tjänster och protokoll har specificerats för datakommunikation (SS-ISO 7498, 1989). Termer som "message mode", "datagram" och "connection-less" används i litteraturen för att beskriva variationer av samma tema: överföring av en enhet av data i en ensam fristående operation utan att upprätta, uppehålla eller bryta en förbindelse.

För att förstå vad en förbindelsefri transmissionsmod innebär är det enklast att först studera den förbindelseorienterade moden.

    • Förbindelseorienterad transmissionsmod i OSIs referensmodell: 

En förbindelseorienterad operationsmod innebär att det skapas en (logisk) förbindelse mellan ett par av noder innan själva dataöverföringen börjar. Med referensmodellens formella terminologi är en förbindelse en association som har upprättats mellan motstående entiteter.

För varje förbindelse skapas det ett par av köer. Vid upprättandet av förbindelsen finns möjlighet för noderna att "förhandla" om olika tjänstekvalitéer. Den förbindelseorienterade moden arbetar enligt följande tre steg: (1) upprätta förbindelse (2) dataöverföring (3) bryt förbindelse.

Den förbindelseorienterade moden är speciellt attraktiv då applikationer använder nätet i långa omgångar, t ex en terminal som arbetar mot en avlägsen dator eller vid filöverföring. Innan dataöverföringen börjar kommer i dessa fall de berörda entiteterna att förhandla och diskutera om hur dataöverföringen skall gå till, t ex om det finns vissa resurser som behöver allokeras för dataöverföringen och vilka tjänstekvalitéer (QOS) som skall finnas.

    • Förbindelsefri transmissionsmod i OSIs referensmodell

Enligt OSIs referensmodell är en förbindelsefri transmissionsmod en överföring av en ensam dataenhet från en SAP  till en eller flera destinations-SAPar utan att en förbindelse upprättas. En förbindelsefri operationsmod innebär således att det inte skapas någon (logisk) förbindelse mellan ett par av noder innan själva dataöverföringen börjar (dvs det sker ingen "handskakning" eller "förhandling" mellan noder).

De köer och buffertar som behövs, skapas vid behov. Varje enhet av data som skall sändas innehåller all information som är associerad med den, t ex den anropande och den anropades adress.

För att lättare förstå skillnaden mellan förbindelsefri och förbindelseorienterad tjänst ges följande jämförelse: (jämförelsen är i stora drag tagen från Piscello och Chapin, 1993).

  • Förbindelsefri: En process (t ex en process i en nod som med vissa tidsintervall vill sända en variabel till en annan nod) meddelar varken de underliggande lagren i den egna maskinen eller lagren i den mottagande slavens maskin, någonting rörande trafiken som kommer att sändas. Det bästa de underliggande lagren kan göra är att försöka hantera det dynamiska uppförandet av processernas kommunikation och hoppas på att historien kan ge en vink om hur kommunikationen kommer att se ut.
  • Förbindelseorienterad: Processerna talar om för nätverket vad de vill göra och begär garantier i samband med överföringen (maximal tid för överföring, maximala fel, maximalt antal gånger ett meddelande skall försöka överföras i händelse av att den mottagande stationen inte svarar osv). I detta fall existerar en förbindelsefas då de begärda resurserna allokeras och utgången av försöket till upprättandet av förbindelsen rapporteras till processen innan själva dataöverföringen börjar.

Entiteter och protokoll

Funktionerna inom ett lager utgörs av ett eller flera element som kallas för entiteter. Entiteter existerar i alla lager. De entiteter som finns i samma lager benämns enligt OSI/RM för peer enteties. Jag benämner dem motstående entiteter (se bilden). OSI/RM definierar en entitet som ett aktivt element.

Entiteter kommunicerar med andra entiteter inom samma lager genom att använda ett eller flera protokoll. Ett protokoll är en mängd regler och format (semantik och syntax) som bestämmer hur kommunikationen mellan lagerentiteter skall gå till (SS-ISO 7498, 1989).

Bilden illustrerar hur entiteterna i lager tre kommunicerar med varandra genom att använda ett protokoll som är specifikt för just det lagret. Entiteter i de övriga lagren kommunicerar på motsvarande sätt.

Entiteter kommunicerar med andra entiteter inom samma lager genom att använda ett protokoll. Entiteter inom samma lager benämns motstående entiteter.

Varje lager, bortsett från det översta lagret, erbjuder tjänster till entiteter som finns i lagret precis ovanför, t ex erbjuder lager 2 tjänster till entiteter som finns i lager 3.

Entiteter kan innehålla funktioner som gör så att lagret ovanför kan använda antingen den ena eller den andra av de två operationsmoderna som beskrevs i föregående avsnitt. Med andra ord, en entitet kan innehålla endast de funktioner som behövs för att kunna erbjuda en förbindelseorienterad operationsmod, eller den kan även innehålla de funktioner som behövs för en förbindelsefri mod, eller den kan innehålla endast de funktioner som behövs för en förbindelsefri operationsmod.

SAP
För att information skall kunna utbytas mellan två eller flera entiteter måste en association upprättas mellan dem i lagret under, genom användningen av ett protokoll. Denna association kallas för en förbindelse. Förbindelsen upprättas mellan service access points (SAP, se även bilden nedan). En SAP är den punkt vid vilken ett par av entiteter i angränsande lager använder eller erbjuder tjänster. Denna SAP kan ha olika former, men den måste unikt identifiera ett specifikt objekt t ex en dator, en person eller en applikation i lagret.

Entiteter kan endast kommunicera genom att använda de tjänster som lagret direkt under erbjuder. En entitet begär tjänster av lagret under via en SAP. När en förbindelse har upprättats mellan två noder sker kommunikationen i varje lager genom ett par av SAPar.

I bilden nedan illustreras de olika lagrens SAPar (bilden är endast ett exempel). Till exempel befinner sig lager nätverkslagrets SAP på gränslinjen mellan lager 3 och 4. Nätverkslagrets SAP benämns NSAP, transportlagrets för TSAP, sessionslagret för SSAP osv.

Till varje SAP finns en adress associerad. Denna adress benämnes SAP-adress. En SAP är lokaliserad vid en SAP-adress. Endast en entitet tillåts att finnas ovanför en viss SAP och därför identifierar SAP-adressen entiteten. En NSAP identifierar således en transportentitet.

Kommunikationen mellan lagren sker vid SAP (service access point).

Tjänsteprimitiver
I varje lager finns definitioner av lagrets tjänster, en s k tjänstedefinition. Denna specificerar en mängd av händelser som kan sändas från ett lager till ett annat. Tjänstedefinitionerna är implementationsoberoende (OSI/RM går att implementera på alla typer av nätverk i vilket operativsystem som helst).

Händelserna, som sker vid SAParna mellan lagren, beskrivs i lagerdefinitioner som tjänsteprimitiver.

De primitiver som används för kommunikationen mellan lagren illustreras i bilden och förklaras nedan:

request: denna primitiv används av ett lager för att begära eller aktivera en tjänst i det underliggande lagret. T ex använder transportlagret primitiven N-DATArequest för att sända data.

indication: denna används av ett undre lager (det lager som erbjuder tjänsten) för att tala om för det övre lagret att en händelse har inträffat vid en SAP. T ex använder nätverkslagret N-DATAindication för att tala om för transportlagret att det har kommit in data.

response: denna används av ett övre lager för att svara på en indication från ett undre lager. T ex en N-CONNECT response från transportlagret innebär att nätverkslagret informeras om att en tidigare begäran om en förbindelse (t ex N-CONNECT request från en annan nod) accepteras.

confirm: denna används för att tala om för den entitet som använde request att uppgiften är slutförd. T ex skulle en N-DATA confirm innebära att transportlagret informeras om att datat är överfört.

Tjänsteprimitiver

Endast de två primitiverna request och indication används vid förbindelsefri kommunikation.

Sammanfattningsvis: Primitiverna används av angränsande lager i en station för att skapa huvuden (PCI, se nästa avsnitt) som används av motstående lager hos en annan station.

Protokollenhet, kontrollinformation och tjänsteenhet

Information överförs i olika typer av dataenheter mellan motstående entiteter och mellan entiteter som är kopplade till en specifik SAP.

De protokollelement som utbyts mellan motstående entiteter betecknas PDU (Protocol Data Unit). T ex betecknas nätverkslagrets protokollelement med NPDU och transportlagrets TPDU (se bild).

För att en PDU skall kunna sändas till en entitet i motsvarande lager i en annan station måste PDUn först sändas till lagret direkt under. När det undre lagret tar emot en PDU "byter den namn" och kallas för en SDU (Service Data Unit). Lagret lägger kontrollinformation (huvud) till SDUn. Denna kontrollinformation kan t ex vara ett sekvens nummer och parametrar som är nödvändig för att de motstående lagren skall kunna "tala med varandra". Informationen betecknas PCI (Protocol Control Information).


De protokollelement som utbyts mellan entiteter i samma lager kallas PDU.

Kontrollinformation (PCI) läggs till tjänste-data-enheten (SDUn). Detta bildar en protokoll-data-enhet (PDU.).

Protokoll från ett lager är nästlat i protokollen som tillhör de undre lagren. Generellt behandlas en SDU (som kommer från de övre lagren) transparent av de undre lagren, men SDUn innehåller inte endast data från de övre lagren utan även protokoll från de övre lagren.

När en PDU har färdats från det översta lagret genom alla sju lagren kommer den slutliga PDUn att byggas upp enligt följande bild.


PDU från alla lager nästlas till en enda PDU som slutligen överförs.

Översikt av de sju lagren - förbindelsefritt

Varje lager i OSI/RM har en väl definierad uppgift att sköta. Vad dessa uppgifter innebär i ett förbindelsefritt protokoll beskrivs nedan. Beskrivningarna är hämtade från standarddokumentet SS-ISO 7498 Datautbyte mellan öppna system (OSI) - Grundläggande referensmodell, 1989 där de förbindelsefria tjänsterna beskrivs i Addendum 1. Bilden nedan illustrerar lagren i OSI/RM.

OSIs referensmodell.

Applikationslagret
Som det högsta lagret i OSI/RM skall applikationslagret erbjuda medel för applikationsprocesser att få tillgång till OSI-omgivningen. Syftet med detta lager är att det skall tjäna som ett fönster mellan korresponderande applikationsprocesser som använder OSI för att utbyta information.

Originalidén med applikationslagret var att definiera tjänstedefinitioner och lagerprotokoll för varje applikation (t ex job- och filöverföring och virtuella terminaler). Det visade sig dock ganska snart att detta var för komplicerat att genomföra. Istället strukturerades applikationslagrets struktur upp och standardprotokollet ISO-9545 "Application Layer Structure" skapades. Standarden betraktar applikationslagret som två sublager. Det övre sublagret innehåller applikationsspecifika tjänster, medan det undre sublagret innehåller olika tjänster av applikationssupport.

Följande tjänster erbjuds av ett förbindelsefritt applikationslager:

  • Identifiering av tänkta kommunicerande partners.
  • Upprättande av kommunikation.
  • Val av kommunikationspartner.
  • Besluta om vilken tjänstekvalité som skall begäras av det underliggande nätverket.
  • Identifiering av begränsningar på datasyntaxen (t ex datastrukturer).

Det är även möjligt att applikationslagret erbjuder de tjänster som definieras för ett förbindelseorienterat applikationslager. Vilka dessa är går att läsa i standarddokumentet SS-ISO 7498, 1989.

Presentationslagret
Presentationslagret har hand om datats syntax, dvs representationen av datat. Det har inte hand om meningen eller semantiken av datat. Lagrets principiella roll är till exempel att acceptera datatyper (character, integer) från applikationslagret och sedan förhandla med dess motsvarande lager i en annan station angående syntaxrepresentationen. Efter det, är detta lagers funktion begränsad. Lagret består av många syntaxtabeller.

Följande tjänster erbjuds av ett förbindelsefritt presentationslager:

  • transformering av syntax, inkluderande t ex komprimering.
  • val av syntax

Sessionslagret
Sessionslagrets syfte är att organisera och synkronisera dialoger (associationer) mellan presentationsentiteter. Lagret ansvarar för att skapa och hantera sessioner. En session kan t ex vara en filöverföringssession. Sessionsentiteter använder tjänsterna som erbjuds av transportlagret för att skapa en sessionsförbindelse.

Det enda syftet med detta lager i ett förbindelsefritt protokoll är att erbjuda mappning av TSAP-adresser till SSAP-adresser.

Transportlagret
Transportlagret erbjuder transparent dataöverföring mellan sessionsentiteter. Sessionsentiteter skall ej behöva ha kunskap om hur en säker och effektiv dataöverföring utförs av det underliggande nätverket.

Transportlagret optimerar användningen av de underliggande nätverkstjänsterna för att erbjuda tjänster till sessionslagret till en minimal kostnad.

Transportlagret har ej någon kunskap om hur det underliggande nätverket verkligen ser ut.

Lagret ger användaren flera alternativ att erhålla/välja vissa nivåer av tjänstekvalitéer från nätverket. Förmågan att hålla dessa tjänstekvalitéer beror dock på kvalitéerna hos nätverkslagret.

Transportlagret som erbjuder förbindelsefri tjänst mappar en begäran om transmission av en transport SDU, på en begäran hos en förbindelsefri nätverkstjänst.

Nätverkslagret
Nätverkslagret skall i ett förbindelsefritt protokoll fungera så att transportentiteter inte behöver ha någon kunskap om det underliggande nätverket (även då flera nätverk är sammankopplade). Hur underliggande resurser används skall nätverkslagret dölja för transportlagret.

Nätverkslagret kanske viktigaste funktion är routing. Denna ser till att meddelanden som sänds mellan transportentiteter når slutdestinationen. När nätverkslagret tar emot ett meddelandet kontrolleras om meddelandet var ämnat för just den noden, om inte, sänds meddelandet vidare, genom att använda datalänklagrets tjänster.

Detta lager ansvarar även för sekvensiering och flödeskontroll av nätverksPDUer (NPDU).

Följande tjänster erbjuds av ett förbindelsefritt nätverksprotokoll:

  • Överföring nätverks-SDUer av en definierad maximal storlek.
  • Hantering av olika parametrar för tjänstekvalitéer.
  • Lokal felkontroll.
  • Mappning mellan NSAP-adresser och DSAP-adresser.
  • Mappning av förbindelsefri nätverkstjänst på förbindelsefri datalänktjänst.
  • Routing.
  • Segmentering.

Datalänklagret
Detta lager ansvarar för att upprätta, uppehålla och avbryta datalänkförbindelser mellan noder samt att överföra frames. Lagret har hand om synkronisering av data för att begränsa flödet av bitar från det fysiska lagret. Det skall garantera att data anländer säkert hos den mottagande enheten. Lagret kontrollerar även dataflödet för att garantera att enheten inte överöses med data vid något tillfälle.

Datalänklagret förväntas även att upptäcka fel som uppstår i det fysiska lagret och eventuellt rätta dessa fel (denna funktion behöver dock inte implementeras). När fel upptäcks men inte rättas, måste dessa fel meddelas till nätverkslagret. Detta beror dock på vilken bitfelssannolikhet som tillåts och har att göra med datalänklagrets tjänstekvalité (QOS).

Följande tjänster erbjuds av datalänklagret:

  • Dölja alla detaljer som har att göra med det underliggande fysiska mediet, så att nätverkslagret inte behöver ha kunskap om dessa detaljer.
  • Överföra data-länk-SDUer. Storleken på en SDU kan begränsas av relationen mellan den fysiska bitfelssannolikheten och datalänklagrets kapacitet att upptäcka fel.
  • lokal felkontroll.
  • parametrar för tjänstekvalitéer. Parametrarna kan t ex vara "transit delay", "throughput" och felsannolikheter av olika slag.

Fysiska lagret
Det är nödvändigt att OSI-arkitekturen tillåter användning av olika sorters fysiskt media. Det fysiska lagret är ansvarigt för att aktivera, uppehålla och deaktivera en fysisk förbindelse, avsedd för bitöverföring mellan datalänkentiteter över en fysisk förbindelse. Detta lager inkluderar specifikationer för fysisk signalering, kablar/trådar och karaktäristiken av kopplingen.
Dataenheterna som överförs kan bestå av en bit (seriell transmission) eller av "n bitar" (parallell transmission) och transmissionen kan vara antingen fullduplex eller halvduplex. Det fysiska lagrets definitioner är tänkta att vara konsistenta med de standardiserade transmissionsteknikerna som finns. Entiteterna i det fysiska lagret är sammankopplade med hjälp av ett fysiskt medium.

Det fysiska lagret erbjuder tjänster till datalänklagret.Dessa tjänster bestäms av karaktäristiken hos det underliggande mediet och är mycket varierande. Många standarder finns för det fysiska lagret, t ex RS232 och EIA 232.

Sammanfattning av de sju lagren
Nedan sammanfattas alla sju lagrens viktigaste funktioner.

  • Applikation: Erbjuda tjänster som gör det möjligt för applikationsprocesser att få tillgång till OSI-omgivningen.
  • Presentation: Hantera datats representation (syntax).
  • Session: Upprätta och hantera sessioner (associationer).
  • Transport: Fungera som ett gränssnitt mellan de tre övre lagren (som är applikationsberoende) och de tre undre lagren (som är nätverksberoende). De övre lagren skall inte behöva ha några detaljkunskape om det fysiska verkliga nätverket.
  • Nätverk: Routing.
  • Datalänk: Synkronisera data för att begränsa flödet av bitar från det fysiska lagret. Lagret kan upptäcka transmissionsfel och om möjligt även rätta dessa.
  • Fysiska: Bitöverföring på ett fysiskt transmissionsmedium.

Referenser
Black U. (1989). DATA NETWORKS: Concepts, Theory and practice. prentince-hall, Englewood Cliffs, new Jersey.
Knowles T et.al (1987). Standards for open systems interconnection. BSP Proffessional books, Oxford.
Piscitello D.M. och Chapin A.L. (1993). Open Systems Networking:TCP/IP and OSI. Addison-Wesley.
SS-ISO 4335 (1989). Datakommunikation - HDLC - Procedurelement.
SS-ISO 7498 (1989). Datautbyte mellan öppna system (OSI) - Grundläggande referensmodell.
SS-ISO 8473 (1989). Datautbyte mellan öppna system (OSI) - Protokoll för förbindelsefri nättjänst.
SS-ISO 8602 (1989). Datautbyte mellan öppna system (OSI) - Protokoll för förbindelsefri transporttjänst.
SS-ISO 8802-2 (1989). Datakommunikation - Lokala nät - Logisk länkstyrning.

Scroll to top