Programmeringskomplexitet - Programming complexity

Programmeringskomplexitet (eller mjukvarukomplexitet ) är en term som innehåller många egenskaper hos en programvara, som alla påverkar interna interaktioner. Enligt flera kommentatorer skiljer man mellan termerna komplexa och komplicerade. Komplicerat innebär att det är svårt att förstå men med tid och ansträngning, i slutändan kännbar. Komplex beskriver å andra sidan interaktioner mellan ett antal enheter. När antalet enheter ökar skulle antalet interaktioner mellan dem öka exponentiellt och det skulle nå en punkt där det skulle vara omöjligt att känna till och förstå dem alla. På samma sätt ökar högre nivåer av komplexitet i programvara risken för att oavsiktligt störa interaktioner och ökar därmed chansen att införa defekter vid ändringar. I mer extrema fall kan det göra det omöjligt att ändra programvaran. Idén att länka programvarukomplexitet till programvarans underhåll har utforskats i stor utsträckning av professor Manny Lehman , som utvecklat sina Laws of Software Evolution från sin forskning. Han och hans medförfattare Les Belady utforskade många möjliga mjukvarumätvärden i sin ofta citerade bok, som kunde användas för att mäta programvarans tillstånd och så småningom nå fram till slutsatsen att den enda praktiska lösningen skulle vara att använda en som använder deterministisk komplexitet modeller.

Åtgärder

Många mått på mjukvarukomplexitet har föreslagits. Många av dessa, även om de ger en bra representation av komplexitet, lämpar sig inte för lätt mätning. Några av de vanligaste mätvärdena är

McCabes cyklomatiska komplexitet
Halsteads mjukvaruutveckling
Henry och Kafura introducerade mjukvarustrukturmätningar baserat på informationsflöde 1981 som mäter komplexitet som en funktion av fläkt in och fläkt. De definierar inblåsning av ett förfarande som antalet lokala flöden till det förfarandet plus antalet datastrukturer från vilka det förfarandet hämtar information. Fan-out definieras som antalet lokala flöden från proceduren plus antalet datastrukturer som proceduren uppdateras. Lokala flöden avser data som skickas till och från procedurer som ringer eller anropas av, proceduren i fråga. Henry och Kafuras komplexitetsvärde definieras som "procedurlängden multiplicerad med kvadraten för fläkt-in multiplicerad med fläkt" (Längd × (fläkt-in × fläkt-ut) ²).
En metriksvit för objektorienterad design introducerades av Chidamber och Kemerer 1994 och fokuserade, som titeln antyder, på mått specifikt för objektorienterad kod. De introducerar sex OO-komplexitetsmått; viktade metoder per klass, koppling mellan objektklasser, svar för en klass, antal barn, arvets djup och brist på sammanhållning av metoder

Det finns flera andra mätvärden som kan användas för att mäta programmeringskomplexitet:

Förgreningskomplexitet (Sneed Metric)
Komplexitet för datatillgång (Card Metric)
Datakomplexitet (Chapin Metric)
Dataflödeskomplexitet (Elshof Metric)
Beslutskomplexitet (McClure Metric)

Teslers lag är ett ordspråk i interaktion mellan människa och dator som säger att varje applikation har en inneboende mängd komplexitet som inte kan tas bort eller döljas.

Typer

Associerat med, och beroende på komplexiteten i ett befintligt program, är komplexiteten förknippad med att ändra programmet. Komplexiteten i ett problem kan delas in i två delar:

Oavsiktlig komplexitet: Avser svårigheter som en programmerare står inför på grund av de valda programvaruteknikverktygen. En bättre passande uppsättning verktyg eller ett mer programmeringsspråk på hög nivå kan minska det. Oavsiktlig komplexitet är ofta också en konsekvens av bristen på att använda domänen för att inrama lösningen, dvs. koden. En praxis som kan hjälpa till att undvika oavsiktlig komplexitet är domänstyrd design .
Viktig komplexitet: Beror på att problemets egenskaper ska lösas och kan inte reduceras.

Chidamber och Kemerer Metrics

Chidamber och Kemerer föreslog en uppsättning mätvärden för programmeringskomplexitet, som ofta används i många mätningar och akademiska artiklar. De är WMC, CBO, RFC, NOC, DIT och LCOM, beskrivna nedan:

WMC - viktade metoder per klass
- ${\ displaystyle WMC = \ sum _ {i = 1} ^ {n} c_ {i}}$
- n är antalet metoder på klassen
- ${\ displaystyle c_ {i}}$ är metodens komplexitet
CBO - koppling mellan objektklasser
- antal andra klasser som är kopplade (använder eller används)
RFC - svar för en klass
- ${\ displaystyle RFC = | RS |}$ var
- ${\ displaystyle RS = \ {M \} \ cup _ {all \ i} \ {R_ {i} \}}$
- ${\ displaystyle R_ {i}}$ är en uppsättning metoder som kallas med metod i
- ${\ displaystyle M}$ är uppsättningen metoder i klassen
NOC - antal barn
- summan av alla klasser som ärver den här klassen eller en ättling till den
DIT - arvsträdets djup
- maximalt djup på arveträdet för denna klass
LCOM- brist på sammanhållning av metoder
- Mäter skärningspunkten mellan de attribut som används gemensamt av klassmetoderna
- ${\ displaystyle LCOM = {\ begin {cases} | P | - | Q |, & {\ text {if}} | P |> | Q | \\ 0, & {\ text {annars}} \ end {cases }}}$
- Var ${\ displaystyle P = \ {(I_ {i}, I_ {j}) | I_ {i} \ cap I_ {j} = \ emptyset \}}$
- Och ${\ displaystyle Q = \ {(I_ {i}, I_ {j}) | I_ {i} \ cap I_ {j} \ neq \ emptyset \}}$
- Med är den uppsättning attribut (instansvariabler) som nås (läses från eller skrivs till) med klassens -th-metod ${\ displaystyle I_ {i}}$ ${\ displaystyle i}$