Complexiteit programmeren - Programming complexity

Programmeercomplexiteit (of softwarecomplexiteit ) is een term die veel eigenschappen van een stuk software omvat, die allemaal interne interacties beïnvloeden. Volgens verschillende commentatoren is er een onderscheid tussen de termen complex en ingewikkeld. Ingewikkeld houdt in dat het moeilijk te begrijpen is, maar met tijd en moeite uiteindelijk kenbaar is. Complex daarentegen beschrijft de interacties tussen een aantal entiteiten. Naarmate het aantal entiteiten toeneemt, zou het aantal interacties tussen hen exponentieel toenemen, en het zou een punt bereiken waarop het onmogelijk zou zijn om ze allemaal te kennen en te begrijpen. Evenzo verhogen hogere niveaus van complexiteit in software het risico dat interacties onbedoeld worden verstoord en vergroot zo de kans op het introduceren van defecten bij het aanbrengen van wijzigingen. In meer extreme gevallen kan het wijzigen van de software vrijwel onmogelijk worden. Het idee om softwarecomplexiteit te koppelen aan de onderhoudbaarheid van de software is uitgebreid onderzocht door professor Manny Lehman , die zijn Laws of Software Evolution uit zijn onderzoek ontwikkelde. Hij en zijn co-auteur Les Belady verkenden in hun vaak geciteerde boek talloze mogelijke softwarestatistieken , die gebruikt konden worden om de staat van de software te meten, en kwamen uiteindelijk tot de conclusie dat de enige praktische oplossing zou zijn om er een te gebruiken die gebruik maakt van deterministische complexiteit. modellen.

Maatregelen

Er zijn vele maten van softwarecomplexiteit voorgesteld. Veel van deze, hoewel ze een goede weergave van de complexiteit opleveren, lenen zich niet voor gemakkelijke metingen. Enkele van de meest gebruikte statistieken zijn

McCabe's cyclomatische complexiteitsmetriek
Halsteads softwarewetenschappelijke statistieken
Henry en Kafura introduceerden in 1981 Software Structure Metrics Based on Information Flow, waarmee de complexiteit wordt gemeten als een functie van het in- en uitwaaieren. Ze definiëren fan-in van een procedure als het aantal lokale stromen in die procedure plus het aantal datastructuren waaruit die procedure informatie ophaalt. Fan-out wordt gedefinieerd als het aantal lokale stromen uit die procedure plus het aantal datastructuren dat de procedure bijwerkt. Lokale stromen hebben betrekking op gegevens die worden doorgegeven van en naar procedures die de procedure in kwestie oproepen of worden aangeroepen. De complexiteitswaarde van Henry en Kafura wordt gedefinieerd als "de procedurelengte vermenigvuldigd met het kwadraat van fan-in vermenigvuldigd met fan-out" (lengte × (fan-in × fan-out) ²).
Een Metrics Suite voor Object-Oriented Design werd in 1994 geïntroduceerd door Chidamber en Kemerer, gericht, zoals de titel suggereert, op metrics specifiek voor objectgeoriënteerde code. Ze introduceren zes OO-complexiteitsstatistieken; gewogen methoden per klasse, koppeling tussen objectklassen, respons voor een klasse, aantal kinderen, diepte van overervingsboom en gebrek aan samenhang van methoden

Er zijn verschillende andere statistieken die kunnen worden gebruikt om de complexiteit van programmeren te meten:

Vertakkingscomplexiteit (Sneed Metric)
Complexiteit van gegevenstoegang (kaartmetrisch)
Gegevenscomplexiteit (Chapin Metric)
Gegevensstroomcomplexiteit (Elshof Metric)
Beslissingscomplexiteit (McClure Metric)

De wet van Tesler is een adagium in de interactie tussen mens en computer dat stelt dat elke toepassing een inherente hoeveelheid complexiteit heeft die niet kan worden verwijderd of verborgen.

Types

Geassocieerd met en afhankelijk van de complexiteit van een bestaand programma, is de complexiteit die gepaard gaat met het wijzigen van het programma. De complexiteit van een probleem kan in twee delen worden verdeeld:

Toevallige complexiteit: heeft betrekking op moeilijkheden waarmee een programmeur wordt geconfronteerd als gevolg van de gekozen software-engineeringtools. Een beter passende set tools of een programmeertaal op een hoger niveau kan dit verminderen. Toevallige complexiteit is vaak ook een gevolg van het ontbreken van het gebruik van het domein om de vorm van de oplossing, dwz de code, te kaderen. Een praktijk die kan helpen om onbedoelde complexiteit te voorkomen, is domein-gestuurd ontwerp .
Essentiële complexiteit: wordt veroorzaakt door de kenmerken van het op te lossen probleem en kan niet worden verminderd.

Chidamber en Kemerer Metrics

Chidamber en Kemerer stelden een reeks programmacomplexiteitsmetrieken voor, die op grote schaal worden gebruikt in veel metingen en academische artikelen. Dit zijn WMC, CBO, RFC, NOC, DIT en LCOM, die hieronder worden beschreven:

WMC - gewogen methoden per klasse
- ${\ displaystyle WMC = \ sum _ {i = 1} ^ {n} c_ {i}}$
- n is het aantal methoden in de klasse
- ${\ displaystyle c_ {i}}$ is de complexiteit van de methode
CBO - koppeling tussen objectklassen
- aantal andere klasse die is gekoppeld (gebruikt of wordt gebruikt)
RFC - antwoord voor een klas
- ${\ displaystyle RFC = | RS |}$ waar
- ${\ displaystyle RS = \ {M \} \ cup _ {all \ i} \ {R_ {i} \}}$
- ${\ displaystyle R_ {i}}$ is een reeks methoden die wordt aangeroepen door methode i
- ${\ displaystyle M}$ is de verzameling methoden in de klasse
NOC - aantal kinderen
- som van alle klassen die deze klasse of een afstammeling ervan erven
DIT - diepte van de overervingsboom
- maximale diepte van de overervingsboom voor deze klasse
LCOM - gebrek aan samenhang van methoden
- Meet het snijpunt van de attributen die gemeenschappelijk worden gebruikt door de klassemethoden
- ${\ displaystyle LCOM = {\ begin {cases} | P | - | Q |, & {\ text {if}} | P |> | Q | \\ 0, & {\ text {else}} \ end {cases }}}$
- Waar ${\ displaystyle P = \ {(I_ {i}, I_ {j}) | I_ {i} \ cap I_ {j} = \ emptyset \}}$
- En ${\ displaystyle Q = \ {(I_ {i}, I_ {j}) | I_ {i} \ cap I_ {j} \ neq \ emptyset \}}$
- With is de set attributen (instantievariabelen) waartoe toegang wordt verkregen (gelezen van of geschreven naar) door de -de methode van de klasse ${\ displaystyle I_ {i}}$ ${\ displaystyle i}$