Programmeringskomplexitet

Ej att förväxla med beräkningskomplexitetsteori .

Programmeringskomplexitet (eller mjukvarukomplexitet ) är en term som inkluderar många egenskaper hos en mjukvara, som alla påverkar interna interaktioner. Enligt flera kommentatorer finns det en skillnad mellan begreppen komplext och komplicerat. Komplicerat innebär att det är svårt att förstå men med tid och ansträngning, i slutändan kännbar. Complex, å andra sidan, beskriver interaktionerna mellan ett antal enheter. När antalet enheter ökar, skulle antalet interaktioner mellan dem öka exponentiellt, och det skulle komma till 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 komplexitetsnivåer i mjukvara risken för att oavsiktligt stör interaktioner och ökar därmed risken för att införa defekter vid ändringar. I mer extrema fall kan det göra modifiering av programvaran praktiskt taget omöjlig. Idén att koppla mjukvarans komplexitet till mjukvarans underhållsbarhet har utforskats flitigt av professor Manny Lehman , som utvecklade sina lagar om mjukvaruutveckling utifrån sin forskning. Han och hans medförfattare Les Belady utforskade många möjliga programvarumått i deras ofta citerade bok, som kunde användas för att mäta programvarans tillstånd, och så småningom kom de 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å mjukvarans komplexitet har föreslagits. Många av dessa, även om de ger en bra representation av komplexitet, lämpar sig inte för enkel mätning. Några av de vanligaste mätvärdena är

• McCabes cyklomatiska komplexitetsmått
• Halsteads mjukvaruvetenskapliga mätvärden
• Henry och Kafura introducerade Software Structure Metrics Based on Information Flow 1981 som mäter komplexitet som en funktion av fläkt in och fläkt ut. De definierar fan-in av en procedur som antalet lokala flöden in i den proceduren plus antalet datastrukturer från vilka den proceduren hämtar information. Fan-out definieras som antalet lokala flöden från den proceduren plus antalet datastrukturer som proceduren uppdaterar. Lokala flöden avser data som skickas till och från procedurer som anropar eller anropas av den aktuella proceduren. Henry och Kafuras komplexitetsvärde definieras som "procedurlängden multiplicerad med kvadraten av fan-in multiplicerad med fan-out" (Längd ×(fan-in × fan-out)²).
• En Metrics Suite för objektorienterad design introducerades av Chidamber och Kemerer 1994 med fokus, som titeln antyder, på mätvärden 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, djup av arvsträd och bristande 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)
• Dataåtkomstkomplexitet (kortmått)
• Datakomplexitet (Chapin Metric)
• Dataflödeskomplexitet (Elshof Metric)
• Beslutskomplexitet (McClure Metric)
• Vägkomplexitet (Bang Metric)

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

Typer

Förknippad med, och beroende av komplexiteten i ett befintligt program, är komplexiteten förknippad med att ändra programmet. Ett problems komplexitet kan delas in i två delar:

1. Oavsiktlig komplexitet: Relaterar till svårigheter som en programmerare möter på grund av de valda mjukvaruteknikverktygen. En bättre passande uppsättning verktyg eller ett mer högnivåprogrammeringsspråk kan minska det. Oavsiktlig komplexitet är ofta också en konsekvens av att domänen inte används för att rama in lösningens form dvs koden. En praxis som kan hjälpa till att undvika oavsiktlig komplexitet är domändriven design .
2. Essentiell komplexitet: Orsakas av egenskaperna hos problemet som ska lösas och kan inte reduceras.

Chidamber och Kemerer Metrics

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

• WMC - viktade metoder per klass
  • $WMC=\sum _{i=1}^{n}c_{i}$
  • n är antalet metoder i klassen
  • $c_{i}$ är komplexiteten i metoden
• CBO - koppling mellan objektklasser
  • antal andra klasser som är kopplade (använder eller används)
• RFC - svar för en klass
  • $RFC=|RS|$ där
  • $RS=\{M\}\cup _{all\ i}\{R_{i}\}$
  • $R_{i}$ är en uppsättning metoder som anropas av metod i
  • $M$ är uppsättningen metoder i klassen
• NOC - antal barn
  • summan av alla klasser som ärver denna klass eller en avkomling till den
• DIT - depth of inheritance tree
  • maximalt djup av arvsträ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
  • $LCOM={\begin{cases}|P|-|Q|,&{\text{if }}|P|>|Q|\\0,&{\text{annars }}\end {fall}}$
  • Där $P=\{(I_{i},I_{j})|I_{i}\cap I_{j}=\emptyset \}$
  • Och $Q=\{(I_{i},I_{j})|I_{i}\cap I_{j}\neq \emptyset \}$
  • Med $I_{i}$ uppsättningen attribut (instansvariabler) som nås (läses från eller skrivs till) av i { $displaystyle i}$ -th metoden i klassen

Se även

• Programvarukris (och efterföljande programmeringsparadigmlösningar )
• Programvarumått - kvantitativt mått på någon egenskap hos ett program.