Sammanfattning Där I detta dokument föreslår vi ett matematiskt ramverk som är generiskt, eftersom det inte är specifikt för någon särskild programvaruartefakt, och rigoröst, eftersom det är baserat på exakta matematiska begrepp. Denna ram definierar flera viktiga mätkoncept (storlek, längd, komplexitet, sammanhållning, koppling Många koncept har införts genom åren för att definiera egenskaperna hos de artefakter som produceras under programvaruprocessen. Till exempel, man talar om storlek och komplexitet av programvara specifikation, design och kod, eller sammanhållning och koppling av en programvara design eller kod. Flera tekniker har införts, med målet att producera programvara som är bättre med avseende på dessa begrepp. Som ett exempel försöker Parnas (P72) designprinciper minska kopplingen mellan moduler och öka sammanhållningen inom moduler. Dessa begrepp används som vägledning för att välja mellan alternativa tekniker eller artefakter. Till exempel, en teknik kan föredras framför en annan eftersom det ger artefakter som är mindre komplexa; en artefakt kan föredras framför en annan eftersom det är mindre komplex. University of Maryland CS-TR-3368 -2 definition av relevanta begrepp (dvs. klasser av programvarukarakteriseringsåtgärder) är det första steget mot kvantitativ bedömning av programvaruartefakter och -tekniker, som behövs för att bedöma risker och hitta optimala avvägningar mellan programvaras kvalitet, schema och utvecklingskostnader. För att fånga dessa begrepp på ett kvantitativt sätt har hundratals programvaruåtgärder definierats i litteraturen. De allra flesta av dessa åtgärder överlevde dock inte förslagsfasen och lyckades inte bli accepterade i den akademiska eller industriella världen. Ett skäl till detta är att de inte har byggts med hjälp av en klart definierad process för att definiera programvaruåtgärder. Som vi föreslår i [BMB94(b)] bör en sådan process drivas av tydligt identifierade mätmål och kunskap om programvaruprocessen. En av dess viktigaste verksamheter är den exakta definitionen av relevanta begrepp, som är nödvändiga för att fastställa en strikt ram för programvarutekniska åtgärder och för att definiera meningsfulla och välgrundade programvaruåtgärder. Den teoretiska sundheten hos en åtgärd, dvs. det faktum att den verkligen mäter den programvara som den ska mäta, är en uppenbar förutsättning för dess acceptans och användning. Den undersökande processen att söka efter samband är inte i sig en godtagbar vetenskaplig valideringsprocess om den inte åtföljs av en solid teori som stöder den. Tyvärr är nya programvaruåtgärder mycket ofta definierade för att fånga gäckande begrepp som komplexitet, sammanhållning, koppling, konnektivitet, etc. (Endast storleken kan anses vara någorlunda väl förstådd.) Det är därför omöjligt att bedöma de nya föreslagna åtgärdernas teoretiska sundhet, och godkännandet av en ny åtgärd är till största delen en fråga om tro. I detta syfte har flera förslag lagts fram i litteraturen [LJS91, TZ92, W88] under de senaste åren för att ge önskvärda egenskaper för programvaruåtgärder. Dessa arbeten (särskilt [W88]) har använts för att "validera" befintliga och nyligen föreslagna programvaruåtgärder. Förvånansvärt nog, när en ny åtgärd som föreslogs som en programvara komplexitet åtgärd inte uppfyller den uppsättning egenskaper mot vilken det kontrollerades, flera författare misslyckades med att dra slutsatsen att deras åtgärd inte var en programvara komplexitet åtgärd, t.ex., [CK94, H92]. I stället drog de slutsatsen att deras åtgärd var en komplicerad åtgärd som inte tillfredsställer denna uppsättning egenskaper för komplexa åtgärder. Vad de faktiskt gjorde var att ge en absolut definition av en programvara komplexitet åtgärd och kontrollera om egenskaperna var förenliga med åtgärden, dvs. kontrollera egenskaperna mot sin egen åtgärd. Denna situation skulle vara oacceptabel inom andra tekniska eller matematiska områden. Anta till exempel att man definierar en ny åtgärd och hävdar att den är en distansåtgärd. Antag också att denna åtgärd misslyckas med att tillfredsställa triangeln ojämlikhet, som är kännetecknande egenskap avstånd åtgärder. Den naturliga slutsatsen skulle vara att inse att det inte är ett avståndsmått, snarare än att säga att det är ett avståndsmått som inte uppfyller villkoren för ett avståndsmått. Det är dock sant att ingen av de uppsättningar av egenskaper som hittills föreslagits har nått så bred acceptans för att betraktas som "rätt uppsättning av nödvändiga egenskaper för komplexitet. Det är vår ståndpunkt att denna märkliga situation beror på att det finns flera olika begrepp som fortfarande omfattas av samma ord: komplexitet. Inom den uppsättning allmänt nämnda programvaruegenskaper, storlek och komplexitet är de som har fått största uppmärksamhet. De flesta författare har dock varit benägna att tro att en åtgärd fångar antingen storlek eller komplexitet, som om, förutom storlek, alla andra koncept relaterade till programvaruegenskaper skulle kunna grupperas under det unika namnet komplexitet. Ibland har till och med storlek betraktats som en särskild form av komplexitetsåtgärd. I själva verket fångar dessa begrepp olika programvaruegenskaper, och tills de är tydligt åtskilda och deras likheter och skillnader tydligt studeras, kommer det att vara omöjligt att nå någon form av samförstånd om de egenskaper som kännetecknar varje koncept som är relevant för definitionen av programvaruåtgärder. Syftet med detta dokument är att lägga grunden för en diskussion om detta ämne genom att tillhandahålla egenskaper för en partial uppsättning mätkoncept som är relevanta för definitionen av programvaruåtgärder. Många av de mätegenskaper som föreslås i litteraturen är generiska i den meningen att de inte karakteriserar specifika mätbegrepp utan är relevanta för alla syntaktiska åtgärder (se [S92, TZ92, W88]). I den här artikeln vill vi fokusera på egenskaper som skiljer mätbegrepp som storlek, komplexitet, koppling m.m. Därför vill vi identifiera och klargöra de väsentliga egenskaperna bakom dessa begrepp som är vanliga inom programvaruteknik och bildar viktiga åtgärdsklasser. På så sätt kommer forskarna att kunna validera sina nya åtgärder genom att kontrollera egenskaper som är särskilt relevanta för den klass (eller koncept) de tillhör (t.ex. storlek bör vara additiv). Dessa egenskaper bör inte på något sätt betraktas som den unika uppsättning av egenskaper som eventuellt kan definieras för ett givet begrepp. Snarare vill vi ge en teoretiskt sund och bekväm lösning för att differentiera en uppsättning välkända begrepp och kontrollera deras analogier och konflikter. Möjliga tillämpningar av en sådan ram är att vägleda forskare i deras sökande efter nya åtgärder och hjälpa yrkesutövare att bedöma lämpligheten av åtgärder som tillhandahålls av kommersiella verktyg. Vi anser också att undersökningen av åtgärder även bör omfatta artefakter som produceras i programvaruprocessen förutom kod. Det anses allmänt att de tidiga programvaruprocessfaserna är de viktigaste, eftersom resten av utvecklingen beror på de artefakter de producerar. Ofta är de begrepp (t.ex. storlek, komplexitet, sammanhållning, koppling) som anses relevanta med avseende på kod också relevanta för andra artefakter. För detta ändamål kommer de egenskaper vi föreslår att vara tillräckligt allmänna för att vara tillämpliga på en stor uppsättning artefakter. Tidningen är organiserad enligt följande. I avsnitt 2 introducerar vi de grundläggande definitionerna av vårt ramverk. Avsnitt 3 ger en uppsättning egenskaper som karakteriserar och formaliserar intuitivt relevanta mätkoncept: storlek, längd, komplexitet, sammanhållning, koppling. Vi diskuterar också relationerna och skillnaderna mellan de olika begreppen. Några av de mest kända åtgärderna används som exempel för att illustrera våra punkter. Avsnitt 4 innehåller jämförelser och diskussioner om de egenskaper för komplexa åtgärder som definieras i dokumentet och i litteraturen. Slutsatserna och riktlinjerna för det framtida arbetet återfinns i avsnitt 5. Innan vi introducerar de nödvändiga egenskaperna för den uppsättning begrepp som vi avser att studera, ger vi grundläggande definitioner relaterade till objekt för studier (på vilka dessa begrepp kan tillämpas), t.ex. storlek och komplexitet av vad? Två av de begrepp som vi kommer att undersöka, nämligen storlek (avsnitt 3.1) och komplexitet (avsnitt 3.3) är relaterade till system, i allmänhet, dvs. man kan tala om storleken på ett system och komplexiteten i ett system. Vi inför också ett nytt koncept, längd (avsnitt 3.2), som är relaterat till system. I vårt allmänna ramverk-upphäver att vi vill att dessa egenskaper ska vara så oberoende som möjligt av varje produkt abstraktion-, ett system kännetecknas av dess element och förhållandet mellan dem. Därför minskar vi inte antalet möjliga systemrepresentationer, eftersom element och relationer kan definieras efter behov. Ett system S kommer att representeras som ett par <E,R>, där E representerar uppsättningen av element av S, och R är en binär relation på E (R  på E × E) som representerar förhållandet mellan S element. Med tanke på ett system S = < E,R> är ett system m = < E m,R m > en modul av S om och endast om E m  med E, R m med E × E och R med R. Som exempel kan E definieras som en uppsättning kodangivelser och R som en uppsättning kontrollflöden från ett uttalande till ett annat. En modul m kan vara ett kodsegment eller ett delprogram. elementen i en modul är anslutna till elementen i resten av systemet genom inkommande och utgående relationer. Den uppsättning InputR(m) av förhållanden från element utanför modulen m = <E m,R m > till dem av modul m definieras som InputR(m) = { <e 1,e 2 > R på e 2 e m och e 1 E m } Den uppsättning OutputR(m) av förhållanden från elementen i en modul m = < E m,R m > till dem i resten av systemet definieras som OutputR(m) = { <e 1,e 2 > R på grund av elementen i en modul m = < E m,R m > på grund av resten av systemet är definierad som OutputR(m) = { <e 1,e 2 >  på grund av R på grund av att E m och e 2 på grund av E-E m }  på University of Maryland CS-TR-3368 -4 Vi inför nu inkludering, union, interaktioner för moduler och definitioner av tomma och delade moduler, som ofta kommer att användas i resten av papperet. För notationell bekvämlighet, kommer de att betecknas genom att förlänga den vanliga set-teoretiska notation. Vi ska illustrera dessa operationer med hjälp av systemet S = <E,R> representerat i figur 1, där E = {a,b,c,d,f,g,h,i,j,k,l,m} och R = {<b,a>, <b,f>, <c,b>, <c,d>, <c,g>, <d,f>, <e,g>, <f,k>, <g,m>, <h,a>, <h,i>, <i,j>, <k,j>, <k,j>, <k,l>}. Vi kommer att överväga följande moduler -m 1 = <E m1,R m1 > = <{a,b,f,j,k}, { <b,a>, <b,f>, <f,k>, <i,j>, <k,j>} (område fyllt med ) -m 2 = <E m2,R m2 > = <{f,j,k}, { <f,k>, <k,j>} (område fyllt med ) -m 3 = <E m3,R m3 > = <{c,d,e,f,g,j,m},<c,d>, <c,g>, <d>,f,j>>> (område fyllt med) -m 4 = m4,R m4 > = <d,g}, <e,f> (område fyllt med) Modul m 1 = <E m1,R m1 > sägs ingå i modul m 2 = <E m2,R m2 > (notering: m 1  på m 2 ) om E m1  på m2 och R på m2. I figur 1, m 4  på m 3. Fackförening. Sammanslutningen av moduler m 1 = <E m1,R m1 > och m 2 = <E m2,R m2 > (notation: m 1  på m 2 ) är modulen <E m1  på m2,R m1 på m2 >. I figur 1 är sammansättningen av modulerna m 1 och m 3 modul m 13 = <{a,b,c,d,e,f,g,i,j,k,m}, { <b,a>, <b,f>, <c,d>, <c,g>, <d,f>, <e,g>, <f,i>, <f,k>, <g,m>, <i,j>, <k,j>} (område fyllt med eller ). Genomskärning. Skärningspunkten mellan modulerna m 1 = <E m1,R m1 > och m 2 = <E m2, R m2 > (notation: m 1  på m 2 ) är modulen <E m1  på m2,R m1 på m2 >. I figur 1, m 2 = m 1  på m 3. Töm modulen. Modul < ∅, ∅> (benämns av ∅) är den tomma modulen. Eftersom modulerna i detta ramverk bara är delsystem kan alla system teoretiskt sett brytas ned i moduler. Definitionen av en modul för en viss åtgärd i ett specifikt sammanhang är bara en fråga om bekvämlighets- och programmeringsmiljö (t.ex. språk) begränsningar. University of Maryland CS-TR-3368 -5 De andra två begreppen vi kommer att undersöka, sammanhållning (avsnitt 3.4) och koppling (avsnitt 3.5), är meningsfulla endast med hänvisning till system som är utrustade med en modulär nedbrytning, d.v.s. kan man tala om sammanhållning och koppling av ett helt system endast om det är strukturerat i moduler. Man kan också tala om sammanhållning och koppling av en enda modul inom ett helt system. Den 3-tums MS = <E,R,M> representerar ett modulärt system om S = <E,R> är ett system enligt definition 1, och M är en samling moduler av S så att  på ett sådant sätt att E (t.ex. m) M (m = <E m,R m > och E m ) ) och E m 1,m 2 M (m 1 = <E m1,R m1 > och m 2 = <E m2,R m2 > och E m1 E m2 = ∅) d.v.s. uppsättningen av element E i MS delas in i modulernas uppsättningar av element. Vi betecknar föreningen av alla R m's som IR. Det är uppsättningen av intra-modul relationer. Eftersom modulerna är osammanhängande är föreningen av alla OutputR(m)'s lika med föreningen av alla InputR(m)'s, som är lika med R-IR. Det är uppsättningen av inter-module relationer. Som exempel kan E vara uppsättningen av alla deklarationer av en uppsättning Ada moduler, R uppsättningen beroenden mellan dem, och M uppsättningen av Ada moduler. Figur 2 visar ett modulärt system MS = < E,R,M>, som erhålls genom att dela upp systemets uppsättning element i figur 1 på ett annat sätt. I detta modulsystem är E och R desamma som i system S i figur 1, och M = {m 1,m 2,m 3 }.
I detta arbete använde vi en annan modell för modulrepresentation (baserad på LDL) och bevisade formellt att de föreslagna åtgärderna respekterar ramverkets egenskaper genom REF.
Property-based Software Engineering Measurement
{'venue': 'IEEE Transactions on Software Engineering', 'journal': None, 'mag_field_of_study': ['Computer Science']}