Konstrukce softwaru - Software construction

Nesmí být zaměňována s vývojem softwaru .
Vývoj softwaru
Hlavní činnosti
Paradigmata a modely
Metodiky a rámce
Podpůrné disciplíny
Praxe
Nástroje
Standardy a subjekty znalostí
Glosáře
Obrysy

Konstrukce softwaru je obor softwarového inženýrství . Jedná se o detailní tvorba pracovních smysluplné softwaru prostřednictvím kombinace kódování , ověřování , testování jednotek , testování integrace , a ladění . Je spojena se všemi ostatními disciplínami softwarového inženýrství , nejsilněji s návrhem softwaru a testováním softwaru .

Základy konstrukce softwaru

Minimalizace složitosti

Potřeba snížit složitost je způsobena hlavně omezenou schopností většiny lidí uchovávat složité struktury a informace ve svých pracovních vzpomínkách. Snížené složitosti je dosaženo zdůrazněním vytvoření kódu, který je spíše jednoduchý a čitelný než chytrý. Minimalizace složitosti se dosahuje využitím standardů a četnými specifickými technikami kódování . Podporují to také techniky kvality zaměřené na konstrukci .

Předvídání změn

Předvídání změn pomáhá softwarovým inženýrům vytvářet rozšiřitelný software, což znamená, že mohou vylepšit softwarový produkt bez narušení základní struktury. Výzkum za více než 25 let ukázal, že náklady na přepracování mohou být 10 až 100krát (5 až 10krát u menších projektů) dražší, než kdyby byly požadavky splněny poprvé. Vzhledem k tomu, že 25% požadavků se během vývoje mění na průměrném projektu, potřeba snížit náklady na přepracování objasňuje potřebu předvídat změnu.

Konstrukce pro ověření

Konstrukci pro ověřování prostřednictvím budování software takovým způsobem, že je možno chyby vyšťoural snadno pomocí softwarových inženýrů psaní software , stejně jako v průběhu nezávislého testování a provozní činnosti. Mezi konkrétní techniky, které podporují konstrukci pro ověření, patří dodržování standardů kódování pro podporu kontroly kódu , testování jednotek , organizační kód pro podporu automatizovaného testování a omezené používání složitých nebo těžko srozumitelných jazykových struktur.

Znovu použít

Systematické opětovné použití může umožnit významné vylepšení produktivity, kvality a nákladů softwaru. Opětovné použití má dva úzce související aspekty:

  • Konstrukce pro opětovné použití: Vytvářejte opakovaně použitelná softwarová aktiva.
  • Konstrukce s opětovným použitím: Opětovné využití softwarových aktiv při konstrukci nového řešení.

Normy ve stavebnictví

Standardy, ať už externí (vytvořené mezinárodními organizacemi) nebo interní (vytvořené na podnikové úrovni), které přímo ovlivňují stavební záležitosti, zahrnují:

Správa stavby

Konstrukční model

Pro vývoj softwaru byla vytvořena řada modelů , z nichž některé zdůrazňují konstrukci více než jiné. Některé modely jsou z konstrukčního hlediska lineárnější, například Waterfall a modely životního cyklu se stupňovitým doručením. Tyto modely považují konstrukci za činnost, která nastane až po dokončení významných nezbytných prací - včetně podrobných požadavků , rozsáhlých konstrukčních prací a podrobného plánování . Jiné modely jsou více iterativní , například evoluční prototypování , extrémní programování a Scrum . Tyto přístupy mají tendenci považovat konstrukci za aktivitu, která se vyskytuje souběžně s jinými aktivitami vývoje softwaru , včetně požadavků , návrhu a plánování , nebo je překrývá.

Stavební plánování

Volba stavební metody je klíčovým aspektem konstrukce plánovací činnosti. Volba metody výstavby ovlivňuje rozsah, v jakém jsou prováděny stavební předpoklady (např. Analýza požadavků , návrh softwaru , atd.), Pořadí, v jakém jsou prováděny, a míra, v jaké se očekává jejich dokončení před stavebními pracemi začíná. Stavební plánování také definuje pořadí, ve kterém jsou komponenty vytvářeny a integrovány, procesy řízení kvality softwaru , přidělování úkolů konkrétním softwarovým technikům a další úkoly podle zvolené metody .

Stavební měření

Lze měřit četné stavební činnosti a artefakty, včetně vývoje kódu, úpravy kódu, opětovného použití kódu, zničení kódu, složitosti kódu, statistik kontroly kódu, míry opravy chyb a hledání chyb, úsilí a plánování. Tato měření mohou být užitečná pro účely řízení výstavby, zajištění kvality během výstavby, zlepšení procesu výstavby i z jiných důvodů.

Praktické úvahy

Konstrukci softwaru řídí mnoho praktických úvah:

Konstrukční návrh

Aby bylo možné zohlednit neočekávané mezery v návrhu softwaru , je třeba během konstrukce softwaru provést některé úpravy návrhu v menším nebo větším měřítku, aby byly upřesněny podrobnosti návrhu softwaru .

Low Fan-out je jednou z konstrukčních charakteristik, které výzkumníci považují za přínosné. Skrývání informací se ukázalo jako užitečná návrhová technika ve velkých programech, které usnadnily jejich úpravu faktorem 4.

Stavební jazyky

Konstrukční jazyky zahrnují všechny formy komunikace, kterými může člověk určit spustitelné řešení problému s počítačem. Zahrnují konfigurační jazyky, jazyky nástrojů a programovací jazyky :

  • Konfigurační jazyky jsou jazyky, ve kterých si softwaroví inženýři vybírají z omezené sady předdefinovaných možností pro vytvoření nové nebo vlastní softwarové instalace.
  • Jazyky Toolkit se používají k vytváření aplikací z nástrojů a jsou složitější než konfigurační jazyky.
  • Skriptovací jazyky jsou druhy aplikačních programovacích jazyků, které podporují skripty, které jsou často interpretovány spíše než kompilovány.
  • Programovací jazyky jsou nejflexibilnějším typem konstrukčních jazyků, které používají tři obecné druhy zápisu:
    • Jazykové zápisy, které se vyznačují zejména použitím slovních řetězců textu, které představují složité softwarové konstrukce, a kombinací těchto slovních řetězců do vzorů, které mají syntaxi podobnou větě.
    • Formální zápisy, které se méně spoléhají na intuitivní každodenní významy slov a textových řetězců, a více na definice podložené přesnými, jednoznačnými a formálními (nebo matematickými) definicemi.
    • Vizuální notace, které se mnohem méně spoléhají na textově orientované notace jazykové i formální konstrukce, a místo toho se spoléhají na přímou vizuální interpretaci a umístění vizuálních entit, které představují základní software.

Programátoři pracující v jazyce, který používají po dobu tří let nebo déle, jsou asi o 30 procent produktivnější než programátoři s rovnocennými zkušenostmi, kteří s tímto jazykem začínají. Jazyky na vysoké úrovni, jako je C ++, Java, Smalltalk a Visual Basic, přinášejí 5 až 15krát lepší produktivitu, spolehlivost, jednoduchost a srozumitelnost než jazyky na nízké úrovni, jako je montáž a C. Rovnocenný kód prokázal potřebu méně řádků být implementovány v jazycích vyšší úrovně než v jazycích nižší úrovně.

Kódování

Hlavní článek: Počítačové programování

Na činnost kódování konstrukce softwaru se vztahují následující úvahy:

  • Techniky pro vytváření srozumitelného zdrojového kódu , včetně pojmenování a rozložení zdrojového kódu. Jedna studie ukázala, že úsilí potřebné k ladění programu je minimalizováno, pokud jsou názvy proměnných mezi 10 a 16 znaky.
  • Použití tříd , vyjmenovaných typů , proměnných , pojmenovaných konstant a dalších podobných entit:
    • Studie provedená NASA ukázala, že uvedení kódu do dobře promyšlených tříd může zdvojnásobit opakovanou použitelnost kódu ve srovnání s kódem vyvinutým pomocí funkčního designu.
    • Jeden experiment ukázal, že návrhy, které přistupují k polím postupně, nikoli náhodně, mají za následek méně proměnných a méně odkazů na proměnné.
  • Použití řídicích struktur:
    • Jeden experiment zjistil, že smyčky s výstupem jsou srozumitelnější než jiné druhy smyček.
    • Pokud jde o úroveň vnoření do smyček a podmíněných podmínek, studie ukázaly, že programátoři mají potíže s pochopením více než tří úrovní vnoření.
    • Ukázalo se, že složitost řízení koreluje s nízkou spolehlivostí a častými chybami.
  • Zpracování chybových stavů - jak plánované chyby, tak výjimky (například zadání špatných dat)
  • Prevence narušení zabezpečení na úrovni kódu (například překročení vyrovnávací paměti nebo přetečení indexu pole )
  • Využití zdrojů pomocí vylučovacích mechanismů a disciplíny v přístupu k opakovaně použitelným zdrojům (včetně vláken nebo databázových zámků )
  • Organizace zdrojového kódu (do příkazů a rutin ):
    • Ukázalo se, že vysoce soudržné rutiny jsou méně náchylné k chybám než rutiny s nižší soudržností. Studie 450 rutin zjistila, že 50 procent vysoce soudržných rutin je bezchybných ve srovnání s pouze 18 procenty rutin s nízkou soudržností. Další studie různých 450 rutin zjistila, že rutiny s nejvyššími poměry vazby k soudržnosti měly sedmkrát více chyb než ty s nejnižšími poměry vazby k soudržnosti a jejich oprava byla 20krát nákladnější.
    • Studie sice ukázaly neprůkazné výsledky týkající se korelace mezi velikostmi rutin a mírou chyb v nich, ale jedna studie zjistila, že rutiny s méně než 143 řádky kódu byly 2,4krát levnější než běžné rutiny. Další studie ukázala, že kód bylo třeba změnit nejméně, když rutiny dosahovaly v průměru 100 až 150 řádků kódu. Další studie zjistila, že strukturální složitost a množství dat v rutině korelovaly s chybami bez ohledu na jejich velikost.
    • Rozhraní mezi rutinami jsou některé z nejvíce náchylných k chybám v programu. Jedna studie ukázala, že 39 procent všech chyb byly chyby v komunikaci mezi rutinami.
    • Nepoužité parametry korelují se zvýšenou mírou chyb. V jedné studii nemělo žádné chyby pouze 17 až 29 procent rutin s více než jednou neodkazovanou proměnnou, ve srovnání s 46 procenty rutin bez nepoužívaných proměnných.
    • Počet parametrů rutiny by měl být maximálně 7, protože výzkum zjistil, že lidé obecně nemohou sledovat více než asi sedm kusů informací najednou.
  • Organizace zdrojového kódu (do tříd , balíčků nebo jiných struktur). Při zvažování omezení by maximální počet datových členů ve třídě neměl překročit 7 ± 2. Výzkum ukázal, že toto číslo je počet samostatných položek, které si člověk pamatuje při provádění dalších úkolů. Při zvažování dědičnosti by měl být omezen počet úrovní ve stromu dědičnosti. Bylo zjištěno, že stromy hlubokého dědictví jsou významně spojeny se zvýšenou mírou poruch. Při zvažování počtu rutin ve třídě by měl být co nejmenší. Studie programů C ++ zjistila souvislost mezi počtem rutin a počtem poruch.
  • Dokumentace kódu
  • Ladění kódu

Stavební zkoušky

Účelem konstrukčního testování je zmenšit mezeru mezi okamžikem, kdy jsou chyby vloženy do kódu, a časem, kdy jsou tyto poruchy detekovány. V některých případech se testování konstrukce provádí po napsání kódu. V programování prvním testováním se testovací případy vytvářejí před zápisem kódu. Stavba zahrnuje dvě formy testování, které často provádí softwarový inženýr, který kód napsal :

Znovu použít

Implementace opětovného použití softwaru vyžaduje více než vytváření a používání knihoven aktiv. Vyžaduje formalizaci praxe opětovného použití integrací procesů a činností opakovaného použití do životního cyklu softwaru . Mezi úkoly související s opětovným použitím při konstrukci softwaru během kódování a testování patří:

Kvalita konstrukce

Mezi primární techniky používané k zajištění kvality kódu, jak je konstruován, patří:

  • Testování jednotek a testování integrace . Jedna studie zjistila, že průměrná míra detekce defektů při testování jednotky a testování integrace je 30%, respektive 35%.
  • Test-první vývoj
  • Použití tvrzení a obranné programování
  • Ladění
  • Inspekce . Jedna studie zjistila, že průměrná míra detekce vad u formálních inspekcí kódu je 60%. Pokud jde o náklady na nalezení závad, studie zjistila, že čtení kódu detekovalo o 80% více chyb za hodinu než testování. Další studie ukázala, že detekce vad designu stojí šestkrát více pomocí testování než pomocí inspekcí. Studie provedená společností IBM ukázala, že pouze 3,5 hodiny bylo potřeba k nalezení závady při kontrole kódu, oproti 15–25 hodinám při testování. Microsoft zjistil, že nalezení a oprava defektu pomocí inspekcí kódu trvá 3 hodiny a vyhledání a oprava defektu pomocí testování trvá 12 hodin. V programu 700 tisíc řádků bylo oznámeno, že kontroly kódu byly několikrát stejně nákladově efektivní jako testování. Studie zjistily, že kontroly mají za následek o 20% - 30% méně závad na 1000 řádků kódu než méně formálních postupů kontroly a že zvyšují produktivitu přibližně o 20%. Formální kontroly obvykle zaberou 10–15% rozpočtu projektu a sníží celkové náklady projektu. Vědci zjistili, že mít více než 2–3 recenzenty při formální kontrole nezvyšuje počet nalezených závad, i když se zdá, že výsledky se liší v závislosti na druhu kontrolovaného materiálu.
  • Technické recenze . Jedna studie zjistila, že průměrná míra detekce defektů u neformálních kontrol kódu a kontroly dokumentů je 25%, respektive 40%. Bylo zjištěno, že návody mají míru detekce defektů 20% - 40%, ale bylo zjištěno, že jsou také drahé, zvláště když se zvýší tlak na projekt. Čtení kódu našla NASA k detekci 3,3 defektů za hodinu úsilí oproti 1,8 defektům za hodinu při testování. Rovněž zjistí o 20% - 60% více chyb během životnosti projektu než různé druhy testování. Studie 13 recenzí o kontrolních schůzkách zjistila, že 90% závad bylo zjištěno při přípravě na kontrolní schůzku, zatímco jen asi 10% bylo zjištěno během schůzky.
  • Statická analýza (IEEE1028)

Studie ukázaly, že k dosažení vysoké míry detekce defektů je třeba použít kombinaci těchto technik. Další studie ukázaly, že různí lidé mají tendenci nacházet různé vady. Jedna studie zjistila, že Extreme Programming postupů programování páru , kontrola stůl , jednotkové testy , testování integrace , a regresní testování může dosáhnout rychlosti zjištění vady 90%. Experiment zahrnující zkušené programátory zjistil, že průměrně byli schopni najít 5 chyb (nejlépe 9) z 15 chyb testováním.

80% chyb bývá soustředěno do 20% tříd a rutin projektu. 50% chyb se nachází v 5% tříd projektu. IBM dokázala snížit vady hlášené zákazníkem desetkrát na jednu a snížit rozpočet údržby ve svém systému IMS o 45% opravou nebo přepsáním pouze 31 ze 425 tříd. Přibližně 20% rutin projektu přispívá k 80% nákladů na vývoj. Klasická studie IBM zjistila, že nejdražšími entitami bylo málo rutin OS / 360 náchylných k chybám. Měli kolem 50 vad na 1000 řádků kódu a jejich oprava stála 10krát více, než kolik bylo zapotřebí k vývoji celého systému.

Integrace

Klíčovou aktivitou během výstavby je integrace samostatně vytvořených rutin , tříd , komponent a subsystémů. Konkrétní softwarový systém může být navíc nutné integrovat do jiných softwarových nebo hardwarových systémů. Obavy spojené s výstavbou integrace patří plánování pořadí, v jakém komponenty budou integrované, vytváří lešení na podporu prozatímní verze tohoto softwaru , stanovení stupně testování a kvality vykonané práce na složek před tím, než jsou integrovány, a stanovení místa v projektu, při níž předběžná verze tohoto softwaru jsou testovány.

Stavební technologie

Objektově orientované runtime problémy

Objektově orientované jazyky podporují řadu runtime mechanismů, které zvyšují flexibilitu a adaptabilitu programů, jako je abstrakce dat , zapouzdření , modularita , dědičnost , polymorfismus a reflexe .

Abstrakce dat je proces, při kterém jsou data a programy definovány s podobným vyjádřením jako jejich význam, přičemž jsou skryty podrobnosti implementace. Akademický výzkum ukázal, že díky abstrakci dat jsou programy srozumitelnější asi o 30% než funkční programy.

Tvrzení, návrh podle smlouvy a obranné programování

Tvrzení jsou spustitelné predikáty, které jsou umístěny v programu a umožňují běhové kontroly programu. Design by contract je vývojový přístup, ve kterém jsou pro každou rutinu zahrnuty předběžné a dodatečné podmínky. Defenzivní programování je ochrana rutiny před prolomením neplatnými vstupy.

Zpracování chyb, zpracování výjimek a odolnost proti chybám

Zpracování chyb označuje programovací praxi předvídání a kódování chybových stavů, které mohou nastat při spuštění programu. Zpracování výjimek je konstrukt programovacího jazyka nebo hardwarový mechanismus navržený ke zpracování výskytu výjimek, zvláštních podmínek, které mění normální tok provádění programu. Tolerance chyb je soubor technik, které zvyšují spolehlivost softwaru detekcí chyb a následným zotavením z nich, pokud je to možné, nebo obsahující jejich účinky, pokud obnovení není možné.

Stavové techniky založené na stavech a řízené tabulkou

Stavové programování je programovací technologie používající stroje s konečným stavem k popisu chování programu. Metoda řízená tabulkou je schéma, které používá tabulky k vyhledání informací namísto použití logických příkazů (například if a case).

Konfigurace běhu a internacionalizace

Konfigurace za běhu je technika, která váže hodnoty proměnných a nastavení programu, když je program spuštěn, obvykle aktualizací a čtením konfiguračních souborů v režimu just-in-time. Internacionalizace je technická činnost přípravy programu, obvykle interaktivního softwaru, na podporu více národních prostředí. Odpovídající aktivita, lokalizace , je aktivita úpravy programu na podporu konkrétního místního jazyka.

Viz také

Poznámky

Reference

externí odkazy