Domov / Pracujte na internete / Vývojárske nástroje sú nevyhnutné a len užitočné. Stručný historický prehľad vývoja nástrojov na vývoj zlého softvéru

Vývojárske nástroje sú nevyhnutné a len užitočné. Stručný historický prehľad vývoja nástrojov na vývoj zlého softvéru

Vývoj softvéru, ako každá iná oblasť činnosti, si vyžaduje určité nástroje. Ak však zoznam softvéru, ktorý bežný človek zvyčajne potrebuje firemný používateľ(možnosť pre bežného domáceho používateľa) je viac-menej zrejmá, potom s vývojármi nie je všetko také jednoduché: zoznam nástrojov používaných na vytváranie aplikácií sa v žiadnom prípade neobmedzuje na vývojové nástroje.

Úvod

Keď sa hovorí o vývoji softvéru, mnohí používatelia majú na mysli predovšetkým písanie aplikačného kódu alebo v lepšom prípade aj implementáciu vytvorených produktov. Tento názor je často založený na minulých skúsenostiach. Mnohí IT profesionáli a používatelia, najmä starší, prišli z akademickej obce. V 80. rokoch programovanie často dopĺňalo vedecký výskum a v podstate si vedec zadal úlohu, vykonal ju a bol jediným (alebo jedným z mála) používateľov vytvorenej aplikácie. Dôsledkom toho bolo, že začiatkom 90. rokov bolo v Rusku pomerne veľa vývojárov (často tí istí bývalí vedci, ktorí vedeli programovať), ktorí tvorili už odcudzené produkty, no zároveň rokovali so zákazníkmi, navrhovali aplikácie, písali kódy. , pripravoval projektovú dokumentáciu, testoval a implementoval produkt a často zároveň sprevádzal užívateľské pracoviská. Prirodzene, sada nástrojov takéhoto všeobecného vývojára sa zvyčajne obmedzovala na vývojový nástroj, textový editor na prípravu zmlúv a dokumentácie a oveľa menej často na nástroje na návrh údajov a generovanie distribúcie.

Aj keď je teraz v Rusku veľa takýchto univerzálnych vývojárov, prevažná väčšina spoločností, dokonca aj relatívne malých, čoraz viac uprednostňuje služby úzkych špecialistov. Dôvodom je výrazné zvýšenie požiadaviek na funkčnosť, dizajn, kvalitu a použiteľnosť softvéru (skúste navrhnúť moderný používateľ textový editor s rozhraním príkazový riadok namiesto Microsoft Word!). Úspešná implementácia moderných projektov si vyžaduje veľmi široké spektrum vedomostí a zručností, ktorými spravidla disponujú rôzni špecialisti, ktorí v projekte vykonávajú rôzne operácie a potrebujú vhodné nástroje.

Fázy, roly, nástroje…

Moderná metodika vývoja softvéru zahŕňa rozdelenie projektu (alebo jeho časti, napríklad ďalšej iterácie projektu) na etapy, v ktorých špecialisti, ktorí v projekte zohrávajú určité úlohy, vykonávajú rôzne akcie a vytvárajú súčasti projektu. Spravidla pri akomkoľvek prístupe k organizácii vývojového procesu možno v tej či onej forme rozlíšiť nasledujúce fázy: obchodná analýza a definícia požiadaviek, návrh, vývoj, testovanie a hodnotenie kvality, dokumentácia, implementácia a údržba - a podľa toho, roly ako projektový manažér, obchodný analytik, systémový analytik, aplikačný architekt, tvorca aplikačného kódu, špecialista QA/QA, technický zapisovateľ, špecialista implementácie, špecialista na údržbu, špecialista na vzdelávanie používateľov, špecialista na marketing vytvorených produktov. Zoznam rolí možno rozšíriť v závislosti od rozsahu a zložitosti projektu (napríklad v niektorých projektoch sú testeri rozdelení na manažérov testov, analytikov testov, tvorcov skriptov pre automatizované testovanie, testerov používateľského rozhrania, testerov záťaže a každého z nich ktoré si vyžadujú vlastné nástroje) a naopak – v malom projekte môže jeden interpret vykonávať viacero rolí (napríklad spojiť rolu testera a technického spisovateľa).

Nižšie sa pozrieme na to, aké nástroje môže vývojový tím potrebovať v rôznych fázach vývoja aplikácie.

Definícia požiadaviek

Stanovenie požiadaviek je úlohou obchodných analytikov, ktorí realizujú predprojektový prieskum prostredníctvom komunikácie so zákazníkom a potenciálnymi užívateľmi a zisťovaním ich problémov a potrieb. Výsledkom prieskumu je zvyčajne dokument, ktorý sa u nás nazýva referenčný rámec a obsahuje informácie o účele produktu, súbor požiadaviek naň a popis hraníc projektu.

Aké nástroje potrebujú obchodní analytici? Potreba nástrojov je určená rozsahom projektu, požiadavkami zákazníka na vyhotovenie dokumentácie, normami prijatými v konkrétnej vývojovej spoločnosti. Obchodný analytik to dokáže textový procesor(napríklad Microsoft Word), s uvedením požiadaviek vo forme textu. V poslednej dobe je však zvykom ilustrovať popis požiadaviek pomocou diagramov UML a IDEF0, ktoré popisujú scenáre interakcie používateľa s produktom, poradie, v ktorom sa správy prenášajú z jedného objektu na druhý, interakciu objektov medzi sebou, pracovné postupy, a zmena stavu objektu. Na vytváranie takýchto diagramov môžete použiť Microsoft Visio, Rational Rose, Rational XDE, Borland Together, na vytváranie diagramov v štandarde IDEF0 sa najaktívnejšie používa CA AllFusion Process Modeler (predtým nazývaný BPwin).

Ktorý nástroj je vhodný pre daný projekt do značnej miery závisí od procesov vývoja. Ak obchodný analytik potrebuje iba ilustrovať projektovú dokumentáciu, potom výber nástroja nie je rozhodujúci – pokiaľ s ním dokážete nakresliť ten či onen diagram. Ak obchodný analytik musí nielen urobiť ilustráciu, ale vytvoriť model pre následné použitie systémovými analytikmi, vývojármi a testermi v nasledujúcich fázach projektu, potom je výber nástroja určený jeho schopnosťou integrovať sa s vývojovými nástrojmi, ktoré budú najviac pravdepodobne použiť ako nástroj na implementáciu kódu. Z technologicky najvyspelejších moderných párov „vývojový nástroj – modelovací nástroj“ stojí za zmienku napríklad Visual Studio .NET – Rational XDE, Visual Studio .NET – Borland Together, Borland JBuilder – Borland Together.

Okrem textových editorov a nástrojov na modelovanie môžu obchodní analytici používať nástroje na správu požiadaviek, ktoré vám umožňujú uložiť štruktúrovaný a systematizovaný zoznam požiadaviek na produkt v databáze a odkazovať naň v nasledujúcich fázach, pričom požiadavky prepoja s komponentmi produktu, ktoré ich implementujú a testy, overenie zhody produktu s požiadavkami, ako aj správne sledovanie zmien požiadaviek, ktoré sa vyskytujú takmer pri každom projekte, bez ohľadu na to, ako starostlivo je štúdia vykonaná, a vplyv týchto zmien na výsledky následnej práce. RequisitePro (IBM/Rational), DOORS (Telelogic) a CaliberRM (Borland) patria dnes medzi najznámejšie nástroje na správu požiadaviek. V skutočnosti, pri správnej organizácii vývojového procesu a s potrebnými šablónami, môžu byť referenčné podmienky generované pomocou nástroja na správu požiadaviek a dokonca sú v súlade s požiadavkami ruských štátnych noriem.

Typické rozhranie nástroja na správu požiadaviek (Borland Caliber RM)

Vo fáze definície požiadaviek sú teda potrebné nástroje na prípravu dokumentov av mnohých prípadoch nástroje na riadenie požiadaviek, modelovanie obchodných procesov a modelovanie UML.

Dizajn

Po etape definovania požiadaviek, ktorá vyvrcholí schválením zadávacích podmienok, nasleduje etapa návrhu. Vykonávajú ho spravidla aplikační architekti, ktorí rozhodujú o architektúre a komponentoch vytváraného riešenia, ako aj o technológiách ich implementácie, a systémoví analytici, ktorí navrhujú dátové a aplikačné triedy, niekedy aj prototypovanie. používateľské rozhrania. Výsledkom tejto fázy je zvyčajne dokument, často nazývaný technický projekt, obsahujúci diagramy tried, dátové modely, prototypy používateľského rozhrania.

Typicky sa v tejto fáze do modelu vytvoreného obchodnými analytikmi pridajú diagramy tried vytváraných aplikácií a diagramy nasadenia vytváraného riešenia, ako aj diagramy popisujúce logický dátový model a ich fyzickú štruktúru pre vybratú DBMS. tejto fáze.

Aké nástroje sa používajú v tejto fáze? Vyššie uvedené nástroje na modelovanie UML sa používajú na vytváranie diagramov tried a diagramov nasadenia. Dátové inžinierstvo zvyčajne používa nástroje ako CA AllFusion Data Modeler (predtým ERwin), Sybase Power Designer, Oracle Designer a podobné nástroje od Embarcadero a Popkin Software. Pre DBMS vyvinuté spoločnosťou Microsoft môžete celkom úspešne použiť Microsoft Visio. Uvedené nástroje umožňujú vytvoriť aspoň skript na generovanie Databáza a rozdiely medzi nimi spočívajú v tom, ako riadia generovanie kódu na strane servera spojeného s vytváraním spúšťačov a uložených procedúr.

Všimnite si, že ak modelovacie nástroje UML ešte nie sú všade používané, potom je použitie nástrojov na návrh údajov typické aj pre malé spoločnosti. Túto kategóriu nástrojov možno klasifikovať ako povinné.

Prototypovanie používateľského rozhrania, ak v tejto fáze existuje, môže vyžadovať použitie buď nástroja na kreslenie obrázkov foriem budúcej aplikácie (napríklad Microsoft Visio alebo grafické editory), alebo priamo nástrojov na vývoj aplikácií.

Vo fáze návrhu sú teda potrebné nástroje na modelovanie a návrh údajov a modelovanie UML av niektorých prípadoch aj nástroje na vytváranie obrázkov formulárov.

Vývoj produktov

Vo fáze vývoja je kód aplikácie vytvorený v súlade s technickým projektom, vrátane serverového kódu, ktorý implementuje funkcionalitu, ktorá nie je v dátovom modeli. V tejto fáze je hlavným nástrojom, ktorý sa musí použiť, nástroj na vývoj aplikácií. Výber vývojového nástroja je určený predovšetkým platformou (Windows, .NET, Java / J2EE, Linux / UNIX) a architektúrou (aplikácie s GUI, konzolové aplikácie a služby, webové aplikácie) a je v súčasnosti pomerne rôznorodá. Nástroje na vývoj aplikácií Java / J2EE vyrábajú IBM, Oracle, Borland, nástroje na vývoj aplikácií pre Windows - Microsoft, Borland, Sybase, nástroje na vývoj aplikácií .NET - Microsoft a Borland, nástroje na vývoj aplikácií pre Linux - Borland a niektoré ďalšie spoločnosti.

Okrem vývojových nástrojov si táto etapa niekedy vyžaduje rôzne doplnkové knižnice komponentov určené na použitie na konkrétnej platforme alebo spolu s určitými vývojovými nástrojmi. Takéto komponenty dodáva veľké množstvo nezávislých vývojárov, ako aj veľa predajcov komerčných produktov, na základe ktorých by mali byť vytvorené riešenia inými vývojármi (príkladom takýchto produktov sú mnohé geografické informačné systémy, CAD aplikácie a niektoré serverové produkty).

Prirodzene, pri vytváraní riešení založených na akomkoľvek serverovom produkte (DBMS, J2EE server, messaging server atď.) by ste v tejto fáze mali mať tento produkt. V mnohých prípadoch, najmä pre vývojárov riešení, výrobcovia takýchto produktov vydávajú verzie určené na vývoj aplikácií a ladenie, ale nie na výrobu.

Vo fáze vývoja aplikácie sa používajú aj modelovacie nástroje, najmä keď dokážu nielen generovať kód v rôznych programovacích jazykoch, ale podporujú aj reverzné inžinierstvo vytvorením diagramu tried na základe hotovej aplikácie alebo umožňujú synchrónne upravovať kód aj model. . Funkcia synchrónnej zmeny kódu a modelu výrazne zjednodušuje mnohé procesy, ktoré samotný vývoj sprevádzajú, takže ak existuje možnosť výberu nástrojov, potom by ste mali venovať pozornosť jej podpore (podporovaná je napríklad synchrónna zmena kódu a modelu niektorými vydaniami modelovacieho nástroja Borland Together UML).

Vo fáze vytvárania aplikácií sa často používajú nástroje na optimalizáciu kódu a ladenie. Takéto nástroje môžu byť súčasťou vývojovej súpravy alebo môžu byť dodávané samostatne.

Testovanie a hodnotenie kvality

Pri skúšaní výrobku sa kontroluje jeho súlad s požiadavkami a v závislosti od týchto požiadaviek sa vykonáva definícia skúšobných metód, tvorba skúšok a výber vhodných nástrojov.

V moderných projektoch sa testuje používateľské rozhranie, výkon aplikácií, bezpečnosť dát a kompatibilita s rôznymi operačnými systémami a aplikáciami. Na tento účel boli vyvinuté vhodné nástroje, ako sú pomocné programy na testovanie databáz, automatizované nástroje na testovanie používateľského rozhrania, nástroje na testovanie záťaže, nástroje na testovanie chýb pri vykonávaní a nástroje na testovanie bezpečnosti aplikácií. Takéto nástroje spravidla obsahujú skriptovacie nástroje, podľa ktorých sa vykonáva automatizované testovanie, to znamená viacnásobné vykonávanie množiny akcií pri zhromažďovaní štatistík porúch, času vykonávania operácie a ďalších informácií súvisiacich s hodnotením kvality produktu.

Hlavnými výrobcami testovacích nástrojov sú v súčasnosti Compuware, Segue, Mercury Interactive, IBM/Rational, Borland. Každý z nich produkuje niekoľko automatizovaných testovacích nástrojov, vrátane testovania záťaže, testovania používateľského rozhrania, testovania chýb pri vykonávaní.

Okrem testovacích nástrojov sa na posúdenie kvality produktu často používajú analyzátory zdrojového kódu aplikácie na určenie správnosti návrhu hierarchie tried, štýlu písania kódu a ďalších funkcií implementácie produktu. Môžu byť vyrobené vo forme jednotlivé aplikácie alebo byť súčasťou simulačných nástrojov (najmä v niektorých vydaniach Borland Together) alebo nástrojov na vývoj aplikácií.

Ak je aplikácia určená na spustenie na rôznych operačných systémoch a ich jazykových verziách (napríklad rôzne 32-bitové verzie a vydania systému Microsoft Windows), testeri môžu považovať za užitočné vytvoriť virtuálne stroje, ktorý vám umožňuje mať na jednom počítači súčasne načítaných niekoľko rôznych operačných systémov a organizovať medzi nimi sieťovú interakciu (o produktoch v tejto kategórii plánujeme hovoriť v samostatnom článku). Zo softvéru tejto triedy sú široko používané produkty Microsoft a VMWare. Pri testovaní programov na inštaláciu aplikácií možno použiť aj nástroje Rezervovať kópiu a obnova obrazov pevných diskov vytvorených spoločnosťami Symantec, PowerQuest a ďalšími.

Dokumentácia

Dokumentáciu projektu vykonávajú rôzni odborníci. Používateľskú príručku zvyčajne vytvára technický autor a jeho hlavným nástrojom je textový editor a nejaký nie príliš zložitý nástroj na spracovanie grafiky, pomocou ktorého môžete k snímkam obrazovky pridať šípky, popisy a ďalšie prvky, ktoré sú zvyčajne znázornené na ilustráciách takýchto Dokumenty. Autori produktových školení a marketingových materiálov potrebujú podobné nástroje a môžu potrebovať aj prezentačné nástroje, ako je Microsoft PowerPoint.

Dokumentáciu nasadenia a údržby, ako aj ďalšie technické dokumenty zvyčajne vytvárajú analytici alebo špecialisti na nasadzovanie. V tomto prípade môžu potrebovať mnohé z vyššie uvedených vecí, ako sú nástroje na správu požiadaviek, nástroje na modelovanie údajov a nástroje na modelovanie UML – často významnú časť týchto dokumentov tvoria modelové správy. Zároveň čím presnejšie boli práce na modeli realizované, tým jednoduchšie bolo vytváranie projektovej dokumentácie.

Súbory pomocníka sa zvyčajne generujú na základe používateľskej príručky pomocou špeciálnych nástrojov. V najjednoduchšom prípade je možné súbor pomocníka vytvoriť pomocou programu Microsoft Word a pomôcok spoločnosti Microsoft na vytváranie súborov pomocníka, ktoré sú súčasťou mnohých vývojových nástrojov, ale veľký objem práca často využíva špecializované nástroje od spoločností ako Blue Sky Software, EC Software, JGsoft.

Implementácia a podpora

Pred uvedením produktu sa zvyčajne vytvárajú distribučné aplikácie, ktoré tento proces uľahčujú – spúšťame ich pri inštalácii konkrétneho produktu do počítača. Na tvorbu distribučných aplikácií sa využívajú aj špecializované nástroje, ktorých lídrami na trhu sú InstallShield Software a Wise Solutions. Vývojové nástroje často obsahujú špecializované verzie týchto produktov, berúc do úvahy ich špecifiká (napríklad možnosť zahrnúť knižnice zahrnuté v distribučnom balíku). tento nástroj rozvoj).

Vo fáze údržby produktu, ako ukazuje prax, možno budete potrebovať všetko, čo bolo vyrobené počas práce na projekte, a teda akékoľvek nástroje.

Rozvoj tímu a projektový manažment

Ak na ktorejkoľvek časti projektu pracuje viac ako jedna osoba, pri vývoji môžu byť nápomocné nástroje na správu verzií (najpopulárnejšie z nich sú Merant PVCS Version Manager a Microsoft Visual SourceSafe). Často sa používajú pri vytváraní nielen aplikačného kódu, ale aj dokumentov (napríklad technických špecifikácií) alebo modelov. Veľké projekty často využívajú nástroje na riadenie zmien. Takéto produkty umožňujú uložiť všetky komponenty projektu a ich verzie do jednej databázy a zjednodušiť správu verzií kódu, modelov, požiadaviek a tiež umožňujú sledovať vplyv zmien v jednej časti projektu na jeho ďalšie časti. Z dnes najpopulárnejších nástrojov na riadenie zmien treba spomenúť produkty od spoločností Borland a IBM / Rational.

Žiadny projekt sa nezaobíde bez človeka, ktorý je zaň zodpovedný a ktorý plánuje činnosť všetkých špecialistov a riadi všetky vývojové procesy. Hoci je možné plánovať prácu na papieri, v poslednej dobe je hlavným nástrojom projektového manažéra (a vo veľkých projektoch manažérov zodpovedných za jednotlivé časti projektu) nejaký špecializovaný nástroj projektového riadenia. Lídrom medzi produktmi v tejto kategórii je rodina produktov Microsoft Project.

Vzorový plán projektu rozvoja softvérový produkt(Projekt Microsoft)

Záver

pri vymenovaní nástrojov, ktoré môžu byť potrebné pri vývoji aplikácií, sme, samozrejme, nepomenovali všetky možné možnosti. Niektoré projekty môžu vyžadovať generátory zostáv, iné môžu vyžadovať grafické nástroje, ďalšie nástroje webového dizajnu a ďalšie nástroje CAD alebo GIS. Zároveň, ako sme videli, v najjednoduchších prípadoch si vystačíte s vývojovým nástrojom a textovým editorom – táto sada môže byť celkom efektívna, ak projekt nie je príliš veľký.

Všetky ostatné kategórie nástrojov uvedené v tomto článku sa v skutočnosti pri vývoji aplikácií striktne nevyžaduje. Ako však ukazuje prax, práca s nimi je oveľa jednoduchšia.

Fáza 1: pred polovicou 50. rokov.

Hlavné náklady sú spojené s kódovaním (v strojových kódoch). Objavujú sa autokódy (jazyky používajúce mnemotechnickú notáciu pre príkazy) a prekladatelia z nich (assemblery).

Implementujú sa možnosti samostatného zostavovania a prenosnosti programov. Zobrazia sa nakladače a linkery programu.

2. etapa: polovica 50. - polovica 60. rokov

Veľkosť programov sa zväčšuje, odhaľuje sa priepasť medzi konceptmi problémových oblastí a strojovo orientovanými jazykmi. Objavujú sa rôzne jazyky vysoký stupeň(algoritmické, univerzálne):

Fortran (1954-1957);

Algol-60 (1958-1960);

Cobol (1959-1961);

a prekladatelia z nich (zostavovatelia). Vymyslené a odskúšané sú takmer všetky základné dátové typy, operácie s nimi, riadiace štruktúry a spôsoby ich zobrazovania v programoch, rôzne možnosti parametrizácie podprogramov.

3. etapa: polovica 60. - začiatok 70. rokov.

Veľkosť softvéru sa prudko zvyšuje, dochádza k prechodu na kolektívny charakter práce. Požiadavky na softvér sa v dôsledku prechodu na komoditnú výrobu zvyšujú.

Mení sa pomer nákladov na vývoj softvéru (40 % a viac sa minie na ladenie, dizajn a dokumentáciu), kódovanie je jedným z najjednoduchších typov práce. Používajú sa a vytvárajú "veľké" programovacie jazyky - PL/1, ALGOL-68, SIMULA-67, zovšeobecňujúce a integrujúce už nájdené riešenia.

Existujú pokročilé programovacie systémy s optimalizáciou a ladením kompilátorov, makro knižníc, knižníc štandardné programy, špecializované textové editory, analytické nástroje a interaktívne ladenie z hľadiska vstupného jazyka. Vyvíjajú sa vyvinuté operačné systémy, prvé DBMS, početné systémy automatizácie dokumentácie, systémy riadenia konfigurácie softvéru (sledovanie modifikácií a verzií softvéru budov).

4. fáza („fáza krízy vývoja softvéru“): začiatok 70. rokov – polovica 70. rokov

Napriek vývoju nástrojov produktivita programátorov nerastie. Navyše v dôsledku zvyšujúcich sa požiadaviek na softvér a nelineárneho rastu jeho zložitosti klesá produktivita práce. Podmienky vývoja softvéru sú porušené, jeho náklady rastú, jeho kvalita je nepredvídateľná, tradičné metódy (poskytovanie ďalších ľudských a materiálnych zdrojov) nefungujú, čo je charakterizované ako „softvérová kríza“.

Získajte uznanie metodológie štruktúrované programovanie(Dijkstra, 1968), tvoria sa základy programovacej techniky (jazyk Pascal (N. Wirth), 1971).

5. etapa: 1976 – naša doba. Etapa pokrízového vývoja nástrojov.

1976 - publikácia Boehmovej práce, ktorá zavádza pojem životný cyklus softvéru a naznačuje, že hlavné náklady nie sú na vývoj, ale na údržbu softvéru.

Programovacie jazyky:

C (začiatok 70. rokov, prvý raz úplne opísaný v roku 1978);

Modula-2 (1978, vyvinutý jazykom Oberon (1988));

Prolog (1972, rozšírený od roku 1980);

Smalltalk (70. roky, predstavený ako Smalltalk-80 v roku 1980);

C++ (začiatok 80. rokov, názov je 1983, v bežnej podobe existuje od roku 1990);

Java (verzia Java 1.0 - 1996, Java 2.0 - 1998, Java 5 - 2004...);

C# (1998-2001, verzia 1.0 - 2000-2002, verzia 2.0 - 2003-2005, verzia 3.0 - 2004-2008, verzia 4.0 - 2008-2010).

Vyvíjajú sa integrované prostredia na vývoj softvéru. Objektovo orientovaný prístup k dizajnu a programovaniu si získava uznanie. Vyvíjajú sa programy, ktoré podporujú tvorbu softvéru v každej fáze.

Testovacie otázky:

1. Aké činnosti zahŕňa vývoj softvérového produktu?

2. Aké sú fázy vývoja softvéru v rámci Rational Unified Process (RUP)?

3. Čo poskytuje použitie nástrojov?

4. Aké sú súčasti programu? Účel každej časti.

5. Definície programu a softvéru.

6. Aké vlastnosti by mal mať softvér?

7. Aké programovacie jazyky sa používajú pri vývoji programov?

8. Definícia softvéru nástroja.

9. Na aké štyri skupiny možno rozdeliť nástrojový softvér? Príklady softvéru pre každú skupinu.

10. Podľa akých kritérií možno porovnávať programy z rovnakej triedy?

11. Aké sú fázy vývoja nástrojov na vývoj softvéru?

12. Účel a hlavné charakteristiky kompilátorov (assemblerov) a editorov odkazov.

13. Vymenovanie a hlavné charakteristiky textových editorov.

14. Účel a hlavné charakteristiky debuggerov.

15. Účel a hlavné charakteristiky programov na vytváranie inštalátorov.

16. Účel a hlavné charakteristiky editorov zdrojov.

17. Účel a hlavné charakteristiky profilovačov.

18. Účel a hlavné charakteristiky programov na podporu verzií.

19. Účel a hlavné charakteristiky programov na vytváranie súborov pomocníka (dokumentácie).

20. Účel a hlavné charakteristiky generátorov dokumentácie.

21. Účel a hlavné charakteristiky disassemblerov a dekompilátorov.

22. Účel a hlavné charakteristiky programov na sledovanie aktivity systému a zmien vyskytujúcich sa v systéme.

23. Účel a hlavné charakteristiky programov-overovačov a kontajnerov.

24. Účel a hlavné charakteristiky programov na ochranu vyvíjaného softvéru (protektory).

25. Účel a hlavné charakteristiky SDK.

26. Účel a hlavné charakteristiky syntaktických analyzátorov.

27. Vymenovanie technologických noriem.


TÉMA: Metodiky vývoja softvéru.

Literatúra: 1. Zelkowitz M., Shaw A., Gannon J. Princípy vývoja softvéru.

2. Ghezzi K., Jazayeri M., Mandrioli D. Základy softvérového inžinierstva.

3. Kamaev V. A., Kosterin V. V. Programovacie technológie.

Zvážte koncepty metodológie, metódy a prostriedkov.

Definícia 1: Metóda(z gréc. methodos - metóda výskumu alebo poznania, teória alebo výučba) - metóda alebo systém metód na praktickú realizáciu niečoho v akejkoľvek predmetnej oblasti, súbor metód alebo operácií na praktický alebo teoretický rozvoj reality, s výhradou riešenia konkrétnych problémov.

Metóda zahŕňa fondy- prostredníctvom ktorého sa akcia vykonáva a spôsoby- ako sa akcia vykonáva.

Definícia 2: Metodológia je systém princípov, ako aj súbor myšlienok, konceptov, metód, metód a prostriedkov, ktoré určujú štýl vývoja softvéru.

Metodika je implementácia štandardu. Samotné normy hovoria len o tom, čo by malo byť, pričom ponechávajú slobodu výberu a prispôsobenia.

Konkrétne veci sa realizujú prostredníctvom zvolenej metodiky. Je to ona, ktorá určuje, ako sa bude vývoj realizovať. Existuje mnoho úspešných metodík vývoja softvéru. Výber konkrétnej metodiky závisí od veľkosti tímu, od špecifík a zložitosti projektu, od stability a vyspelosti procesov vo firme a od osobnostných kvalít zamestnancov.

Metodológie sú jadrom teórie riadenia vývoja softvéru.

V závislosti od použitého modelu životného cyklu sa metodiky delia na:

Vodopád (kaskáda);

Iteratívne (špirála).

Existuje aj všeobecnejšia klasifikácia:

Predpovedané;

Adaptívny.

Projektované metodológie zamerať sa na podrobné plánovanie do budúcnosti. Plánované úlohy a zdroje sú známe počas celého trvania projektu. Mužstvo na prípadné zmeny takmer nereaguje. Plán je optimalizovaný na základe rozsahu prác a existujúcich požiadaviek. Zmena požiadaviek môže viesť k výraznej zmene plánu, ako aj návrhu projektu. Často sa zriaďuje špecializovaný výbor „riadenia zmien“, aby sa zabezpečilo, že sa v projekte zohľadnia len tie najdôležitejšie požiadavky.

Adaptívne metodológie sú zamerané na prekonanie očakávanej neúplnosti požiadaviek a ich neustálu zmenu. Keď sa zmenia požiadavky, zmení sa aj vývojový tím. Tím zapojený do agilného vývoja má problém predpovedať budúcnosť projektu. Presný plán je len na blízku budúcnosť. Vzdialenejšie plány existujú len ako deklarácie cieľov projektu, očakávaných nákladov a výsledkov.

Kaskádový vývoj alebo vodopádový model - model procesu vývoja softvéru, v ktorom proces vývoja vyzerá ako tok, ktorý postupne prechádza fázami analýzy požiadaviek, návrhu, implementácie, testovania, integrácie a podpory.

Hlavná vlastnosť vodopádový prístup je: prechod do ďalšej etapy sa uskutoční až po úplnom dokončení práce v súčasnej etape a nie sú žiadne návraty do prechádzajúcich fáz . Každá etapa končí niektorými výsledkami, ktoré slúžia ako vstup pre ďalšiu etapu (obr. 1).

Ryža. 1. Kaskádový model životného cyklu.

Každá fáza vyvrcholí vydaním súboru dokumentácie, ktorý postačuje na to, aby vo vývoji pokračoval ďalší vývojový tím. Kritériom kvality vývoja pri tomto prístupe je presnosť plnenia špecifikácií zadávacích podmienok.

Výhody použitia kaskádovej metódy:

V každej etape sa vytvorí kompletný súbor projektovej dokumentácie, ktorá spĺňa požiadavky na úplnosť a konzistentnosť;

Fázy práce vykonávané v logickom slede vám umožňujú naplánovať načasovanie dokončenia všetkých prác a zodpovedajúcich nákladov.

Kaskádový prístup sa dobre osvedčil pri konštrukcii elektroniky informačné systémy, pre ktorú je možné na samom začiatku vývoja celkom presne a úplne sformulovať všetky požiadavky tak, aby dali vývojárom voľnosť pri ich technickej implementácii čo najlepšie.

Tento prístup má zároveň množstvo nevýhod, predovšetkým z toho dôvodu skutočný proces vývoj softvéru nikdy úplne nezapadá do takého prísneho vzoru. Proces vytvárania softvéru má spravidla iteratívny charakter: výsledky ďalšej fázy často spôsobujú zmeny dizajnové riešenia generované v predchádzajúcich etapách. Existuje teda neustála potreba vracať sa k predchádzajúcim etapám a objasňovať alebo revidovať skôr prijaté rozhodnutia (obr. 2). Zobrazenú schému možno pripísať samostatnému modelu - modelu so stredným riadením, v ktorom medzistupňové úpravy poskytujú väčšiu spoľahlivosť v porovnaní s kaskádovým modelom, hoci predlžujú celé vývojové obdobie.

Hlavnou nevýhodou vodopádového modelu je značné oneskorenie pri získavaní výsledkov a v dôsledku toho vysoké riziko vytvorenia systému, ktorý nezodpovedá meniacim sa potrebám používateľov. Je to spôsobené dvoma dôvodmi:

Používatelia nie sú schopní okamžite uviesť všetky svoje požiadavky a nemôžu predvídať, ako sa zmenia počas vývoja;

Počas vývoja môže dôjsť k zmenám vo vonkajšom prostredí, ktoré ovplyvnia požiadavky na systém.

Ryža. 2. Kaskádový model životného cyklu v praxi.

V rámci kaskádového prístupu sú požiadavky na vyvíjaný produkt fixované vo forme technickej úlohy po celú dobu jeho tvorby a získané výsledky sú s užívateľmi odsúhlasené až v bodoch plánovaných po ukončení každého etapa (je možné upraviť výsledky podľa pripomienok užívateľov, ak neovplyvňujú požiadavky uvedené v zadávacích podmienkach). Používatelia tak môžu robiť významné pripomienky až po úplnom dokončení práce na systéme. Používatelia môžu dostať systém, ktorý nespĺňa ich potreby. V dôsledku toho musíte začať nový projekt, ktorý môže postihnúť rovnaký osud.

Na prekonanie týchto problémov bol v polovici osemdesiatych rokov minulého storočia navrhnutý špirálový model životného cyklu (obr. 3).

Ryža. 3. Špirálový (iteratívny) model životného cyklu.

Jeho hlavnou črtou je: aplikačný softvér sa nevytvára okamžite, ako v prípade vodopádového prístupu, ale po častiach pomocou metódy prototypovania .

Pod prototyp označuje aktívny softvérový komponent, ktorý implementuje jednotlivé funkcie a externé rozhrania vyvíjaného softvéru. Tvorba prototypov sa uskutočňuje v niekoľkých iteráciách alebo otáčkach špirály. Každá iterácia zodpovedá vytvoreniu fragmentu alebo verzie softvéru, objasňuje ciele a charakteristiky projektu, hodnotí kvalitu získaných výsledkov a plánuje prácu ďalšej iterácie. Pri každej iterácii sa starostlivo posudzuje riziko prekročenia času a nákladov projektu, aby sa určilo, či je potrebná ďalšia iterácia, stupeň úplnosti a presnosti v pochopení systémových požiadaviek a či by sa mal projekt ukončiť.

Špirálový model zbavuje používateľov a vývojárov potreby presne a úplne formulovať systémové požiadavky v počiatočnej fáze, pretože sú spresňované pri každej iterácii. Dochádza tak k prehĺbeniu a dôslednému konkretizovaniu detailov projektu a v dôsledku toho sa vyberie rozumná možnosť, ktorá sa privedie k realizácii.

Špirálový model je klasickým príkladom evolučnej dizajnovej stratégie. Špirálový model (od Barryho Boehma, 1988) je založený na najlepšie vlastnosti klasický životný cyklus a rozloženie, ku ktorému sa pridáva nový prvok- analýza rizík predtým nebola k dispozícii.

Špirálový model definuje štyri aktivity reprezentované jednotlivými sektormi špirály:

1. Plánovanie – definovanie cieľov, možností a obmedzení.

2. Analýza rizika - analýza možností a rozpoznanie/výber rizika.

3. Inžinierstvo – vývoj produktov ďalšej úrovne.

4. Hodnotenie - vyhodnotenie aktuálnych výsledkov návrhu zákazníkom.

Integračný aspekt špirálového modelu je zrejmý pri zvažovaní radiálneho rozmeru špirály. S každou iteráciou po špirále (pohyb od stredu k periférii) viac a viac plné verzie ON.

V prvom otočení špirály sa definujú počiatočné ciele, možnosti a obmedzenia, rozpozná sa a analyzuje riziko. Ak analýza rizík ukáže neistotu požiadaviek, vývojárovi a zákazníkovi pomôže prototypovanie (použité v kvadrante dizajnu). Modelovanie môže byť použité na ďalšiu identifikáciu problematických a rafinovaných požiadaviek. Zákazník hodnotí inžiniersku (projektovú) prácu a dáva návrhy na úpravy. Ďalšia fáza plánovania a analýzy rizík je založená na návrhoch zákazníkov. V každom cykle v špirále sa výsledky analýzy rizík formujú vo forme „pokračovať, nepokračovať“. Ak je riziko príliš veľké, projekt môže byť zastavený.

Vo väčšine prípadov špirála pokračuje, pričom každý krok posúva vývojárov k ďalším všeobecný model systémov.

S iteračnou metódou možno chýbajúcu prácu vykonať v ďalšej iterácii. Hlavnou úlohou je čo najskôr ukázať používateľom systému funkčný produkt, čím sa aktivuje proces spresňovania a dopĺňania požiadaviek.

Špirálový model nevylučuje kaskádový prístup v záverečných fázach projektu v prípadoch, keď sú požiadavky na systém plne definované.

Hlavným problémom špirálového cyklu je určenie momentu prechodu do ďalšej fázy. Na jeho vyriešenie je potrebné zaviesť časové obmedzenia na každú z fáz životného cyklu. Prechod prebieha podľa plánu, aj keď nie sú dokončené všetky plánované práce. Plán je zostavený na základe štatistických údajov získaných z predchádzajúcich projektov a osobných skúseností developerov.

Výhody špirálového modelu:

Najrealistickejšie (vo forme evolúcie) odráža vývoj softvéru;

Umožňuje vám explicitne vziať do úvahy riziko v každej fáze vývoja;

Začleňuje krok systematického prístupu do štruktúry iteratívneho vývoja;

Používa simuláciu na zníženie rizika a zlepšenie softvérového produktu.

Nevýhody špirálového modelu:

Novinka (neexistuje dostatočná štatistika o účinnosti modelu);

Zvýšené požiadavky na zákazníka;

Ťažkosti s monitorovaním a riadením času vývoja.

K dnešnému dňu možno rozlíšiť nasledujúce iteratívne metodológie vývoja softvéru:

Rational Unified Process (RUP)

Flexibilné vývojové metodiky (SCRUM, KANBAN, DSDM, MSF, ALM, XP)

Agilná metodika vývoja(angl. Agile software development).

Väčšina agilných metodík má za cieľ minimalizovať riziko znížením vývoja na sériu krátkych cyklov tzv iterácií ktoré zvyčajne trvajú jeden až dva týždne. Každá iterácia sama osebe vyzerá ako miniatúrny softvérový projekt a zahŕňa všetky úlohy potrebné na vytvorenie miniatúrneho rastu funkčnosti: plánovanie, analýza požiadaviek, dizajn, kódovanie, testovanie a dokumentácia. Zatiaľ čo jedna iterácia vo všeobecnosti nestačí na vydanie novej verzie produktu, predpokladá sa, že agilný softvérový projekt je pripravený na vydanie na konci každej iterácie. Na konci každej iterácie tím prehodnotí priority vývoja.

Agilné metódy kladú dôraz na komunikáciu tvárou v tvár. Väčšina agilných tímov sa nachádza v rovnakej kancelárii. Minimálne zahŕňa aj „zákazníkov“ (zákazníkov, ktorí definujú produkt; môžu to byť aj produktoví manažéri, obchodní analytici alebo zákazníci). Kancelária môže zahŕňať aj testerov, dizajnérov rozhraní, technických autorov a manažérov.

Jednou z najznámejších a najpokročilejších agilných metodík je metodika SCRUM.

SCRUM- metodika určená pre malé tímy (do 10 osôb). Celý projekt je rozdelený na iterácie (sprinty), z ktorých každá trvá 30 dní. Vyberie sa zoznam funkcií systému, ktoré sa plánujú implementovať počas nasledujúceho sprintu. Najdôležitejšími podmienkami sú nemennosť zvolených funkcií pri vykonávaní jednej iterácie a prísne dodržiavanie dátumov vydania nasledujúceho vydania, aj keď nie je možné jeho vydaním implementovať všetku plánovanú funkcionalitu. Vývojový manažér máva denne 20-minútové stretnutia, ktoré sa nazývajú scrum, výsledkom ktorých je definovanie funkcie systému implementovanej v predchádzajúci deň, vzniknuté ťažkosti a plán na nasledujúci deň. Takéto stretnutia umožňujú neustále sledovať priebeh projektu, rýchlo identifikovať vzniknuté problémy a rýchlo na ne reagovať.

KANBAN– agilná metodika vývoja softvéru, ktorá je orientovaná na úlohy.

Základné pravidlá:

Vizualizácia vývoja:

o rozdelenie práce na úlohy;

o používanie značiek o pozícii úlohy vo vývoji;

Obmedzenie práce vykonávanej súčasne v každej fáze vývoja;

Meranie času cyklu (priemerný čas na dokončenie jednej úlohy) a optimalizácia procesu.

Výhody KANBAN:

Zníženie počtu paralelných úloh výrazne znižuje čas vykonania každej jednotlivej úlohy;

Rýchla identifikácia problémových úloh;

Vypočítajte čas na dokončenie priemernej úlohy.

METÓDA VÝVOJA DYNAMICKÉHO SYSTÉMU(DSDM) vznikla ako výsledok práce konzorcia 17 britských spoločností. Na vývoji manuálov k tejto metodike, organizovaní školení, akreditačných programov atď. sa podieľa celá organizácia. Okrem toho má hodnota DSDM aj peňažnú hodnotu.

Všetko to začína štúdiou realizovateľnosti programu a jeho rozsahu. V prvom prípade sa snažíte zistiť, či je DSDM pre daný projekt vhodný. Má sa naštudovať rozsah programu na krátkej sérii seminárov, kde sa programátori dozvedia o oblasti podnikania, pre ktorú budú pracovať. Rozoberá tiež hlavné ustanovenia týkajúce sa architektúry budúceho systému a plánu projektu.

Proces sa ďalej delí na tri na seba nadväzujúce cykly: cyklus funkčného modelu je zodpovedný za tvorbu analytickej dokumentácie a prototypov, cyklus návrhu a konštrukcie je za uvedenie systému do prevádzkyschopného stavu a nakoniec posledný cyklus - cyklus implementácie - zabezpečuje nasadenie softvérového systému.

Základné princípy, na ktorých je DSDM postavená, sú:

Aktívna interakcia s používateľmi;

Časté vydania verzií;

Nezávislosť vývojárov pri rozhodovaní;

Testovanie počas celého pracovného cyklu.

Rovnako ako väčšina ostatných agilných metodológií, DSDM používa krátke iterácie, z ktorých každá trvá dva až šesť týždňov. Osobitný dôraz sa kladie na vysoká kvalita výkon a prispôsobivosť meniacim sa požiadavkám.

RÁMEC MICROSOFT SOLUTIONS(MSF) je metodika vývoja softvéru navrhnutá spoločnosťou Microsoft Corporation. Lekári bez hraníc čerpá z osvedčených postupov spoločnosti Microsoft a opisuje, ako sa riadia ľudia a pracovné postupy v procese vývoja riešení.

Základné koncepty a princípy procesného modelu Lekárov bez hraníc:

Jednotná vízia projektu - všetky zainteresované strany a len účastníci projektu musia jasne pochopiť konečný výsledok, každý by mal pochopiť účel projektu;

Riadenie kompromisov – hľadanie kompromisov medzi zdrojmi projektu, harmonogramom a realizovateľnými príležitosťami;

Flexibilita - pripravenosť na zmenu konštrukčných podmienok;

Zamerajte sa na obchodné priority – zamerajte sa na návratnosť a výhody, ktoré spotrebiteľ od riešenia očakáva;

Podporovať slobodnú komunikáciu v rámci projektu;

Tvorba základné verzie- oprava stavu akéhokoľvek artefaktu projektu, vrátane programového kódu, plánu projektu, používateľskej príručky, nastavení servera a následného efektívneho riadenia zmien, analýzy projektu.

Lekári bez hraníc poskytujú osvedčené metodiky plánovania, navrhovania, vývoja a implementácie úspešných IT riešení. Vďaka svojej flexibilite, škálovateľnosti a nedostatku pevných smerníc sú Lekári bez hraníc schopní splniť potreby organizácie alebo projektového tímu akejkoľvek veľkosti. Metodológia MSF pozostáva z princípov, modelov a disciplín pre riadenie personálu, procesov, technologických prvkov a otázok súvisiacich so všetkými týmito faktormi, ktoré sú typické pre väčšinu projektov.

Správa životného cyklu aplikácie(ALM) - vyvinutý a udržiavaný spoločnosťou Borland.

extrémne programovanie(XP) - extrémne programovanie podporované otvorenou komunitou nezávislých vývojárov.

Predmet: Technológia vývoja softvéru.

Téma: Kolaboratívne nástroje na vývoj softvéru.

vzdelávacie

Oboznámenie sa s nástrojmi kolektívneho vývoja softvéru.

vyvíja sa:

Rozvíjať schopnosť počúvať druhých, vyvodzovať závery a zovšeobecňovať získané poznatky

Vzdelávacie:

Pestovať zmysel pre dôležitosť predmetu v odborných činnostiach, presnosť v práci

Interdisciplinárne prepojenia:

anglický jazyk

Operačné systémy

Informačné technológie

Základy algoritmizácie a programovania

Vybavenie: tabuľa, krieda, písacie potreby, projektor, PC

Typ lekcie: kombinovaná

Vyučovacia metóda: vysvetľujúca ilustračná

Počas tried:

1. Organizačný moment

Kontrola pripravenosti úradu

Oznámenie témy

2. Stanovenie cieľa vyučovacej hodiny

3.Opakovanie preberanej látky

Nástroje na vývoj softvéru.

Nástrojové prostredia pre vývoj a údržbu softvérových nástrojov a princípy ich klasifikácie

Hlavné triedy prostredí na vývoj nástrojov a údržba softvérových nástrojov

Programovacie prostredia

4. Komunikácia nových poznatkov

Pojem technológie vývoja počítačového softvéru a jeho úlohy

Systémy nástrojov technológie programovania

Nástroje na vývoj softvéru

5. Vnímanie a povedomie študentov o novom materiáli

6. Zovšeobecnenie porozumenia a systematizácia vedomostí

7. Zhrnutie hodiny a stanovenie domácich úloh

Naučte sa obsah témy

Gagarina L.G. str. 257-259.

Odpovedz na otázku:

16.4. Pojem technológie vývoja počítačového softvéru a jeho úlohy

Existujú určité ťažkosti pri vytváraní presnej definície technológie CASE (počítačová technológia na vývoj PS). CASE je skratka pre Computer-Aided Software Engineering (Computer-Assisted Programming Engineering). Ale bez pomoci (podpory) počítača sa PS už dávno nevyvíjajú (používa sa aspoň kompilátor). V skutočnosti je tomuto pojmu vložený užší (špeciálny) význam, ktorý sa postupne stiera (ako to býva vždy, keď pojem nemá striktnú definíciu). Spočiatku sa CASE chápal ako inžinierstvo raných fáz vývoja softvéru (určenie požiadaviek, vývoj externého popisu a architektúry softvéru) pomocou softvérovej podpory (softvérové ​​nástroje). CASE možno teraz chápať aj ako inžinierstvo celého životného cyklu softvéru (vrátane jeho údržby), ale iba v prípade, keď sú programy čiastočne alebo úplne generované podľa dokumentov získaných v uvedených počiatočných fázach vývoja. V tomto prípade sa technológia CASE zásadne líši od manuálnej (tradičnej) technológie vývoja softvéru: zmenil sa nielen obsah technologických procesov, ale aj ich súhrn.

V súčasnosti počítačová technológia Vývoj PS možno charakterizovať pomocou

  • softvérová podpora pre vývoj grafických požiadaviek a grafických špecifikácií PS,
  • automatické generovanie programov v akomkoľvek programovacom jazyku alebo v strojovom kóde (čiastočne alebo úplne),
  • softvérová podpora pre prototypovanie.

Hovorí sa tiež, že výpočtová technika na vývoj PS je „bezpapierová“, t.j. určené na počítačovú reprezentáciu programových dokumentov. Je však dosť ťažké s istotou rozlíšiť technológiu manuálneho vývoja softvéru od počítačovej technológie založenej na týchto vlastnostiach. To znamená, že to najpodstatnejšie vo výpočtovej technike nebolo vyčlenené.

Podľa nášho názoru je hlavný rozdiel medzi technológiou manuálneho vývoja softvéru a počítačovou technológiou nasledovný. Manuálna technológia je zameraná na vývoj dokumentov, ktoré sú rovnako chápané rôznymi vývojármi PS, kým výpočtová technika je zameraná na poskytovanie sémantického porozumenia (interpretácie) dokumentov so softvérovou podporou výpočtovej techniky. Sémantické chápanie dokumentov poskytuje softvérovej podpore schopnosť automaticky generovať programy. V tomto ohľade je podstatnou súčasťou výpočtovej techniky používanie formálnych jazykov už v raných fázach vývoja softvérového systému: tak na špecifikáciu programov, ako aj na špecifikáciu iných dokumentov. Široko používané sú najmä jazyky formálnych grafických špecifikácií. Práve to umožňuje racionálne meniť samotný súbor technologických procesov pre vývoj a údržbu softvéru.

Z diskusie sa to dá zistiť vývoj softvéru výpočtová technika ako programovacia technológia, ktorá využíva softvérové ​​nástroje na vývoj formalizovaných špecifikácií programov a iných dokumentov (vrátane grafických špecifikácií) s následným automatickým generovaním programov a dokumentov (alebo aspoň ich významnej časti) podľa týchto špecifikácií.

Teraz sú jasné hlavné zmeny v životnom cykle softvéru pre výpočtovú techniku. Ak pri použití manuálnej technológie bolo hlavné úsilie pri vývoji PS vynakladané v etapách skutočného programovania (kódovania) a ladenia (testovania), tak pri použití výpočtovej techniky to bolo v raných fázach vývoja PS (definovanie požiadaviek). a funkčná špecifikácia, vývoj architektúry). Zároveň sa výrazne zmenil charakter dokumentácie. Namiesto celého reťazca neformálnych dokumentov zameraných na prenos informácií od zákazníka (používateľa) k rôznym kategóriám vývojárov sa vytvorí prototyp PS, ktorý podporuje zvolené používateľské rozhranie a formálne funkčné špecifikácie (niekedy aj formálne špecifikácie architektúry PS) postačujú na automatickú syntézu (generáciu) programov PS (alebo aspoň ich významnej časti). Zároveň bolo možné automaticky generovať časť dokumentácie potrebnej pre vývojárov a používateľov. Namiesto manuálneho programovania (kódovania) - automatické generovanie programov, vďaka čomu nie je potrebné nezávislé ladenie a testovanie programov: namiesto toho sa pridáva skôr hlboká automatická sémantická kontrola dokumentácie. Je možné automaticky generovať testy podľa formálnych špecifikácií pre komplex ( systémový) Ladenie PS. Výrazne sa mení aj povaha údržby PS: všetky zmeny vykonáva správca iba podľa špecifikácií (vrátane prototypu), ostatné zmeny PS sú vykonávané automaticky.

S tým povedané životný cyklus softvéru pre výpočtovú techniku možno znázorniť nasledovným diagramom (obr. 16.3).

Ryža. 16.3. Životný cyklus softvérového nástroja pre výpočtovú techniku.

prototypovanie PS je voliteľná etapa životného cyklu PS s výpočtovou technikou, ktorá na Obr. 16.3 je znázornená bodkovanou šípkou. Využitie tohto kroku v mnohých prípadoch a zodpovedajúca počítačová podpora tohto kroku je však charakteristická pre výpočtovú techniku. V niektorých prípadoch sa prototypovanie vykonáva po (alebo počas) vývoja špecifikácií. PS, napríklad v prípade prototypovania používateľského rozhrania. Toto je znázornené na obr. 16,3 bodkovaná šípka späť. Hoci umožňujeme návrat k predchádzajúcim štádiám v ktorejkoľvek fáze, ale tu je to explicitne zobrazené, pretože prototypovanie je špeciálny prístup k vývoju PS (pozri prednášku 3). Prototypovanie používateľského rozhrania umožňuje nahradiť nepriamy popis interakcie medzi používateľom a PS v manuálnej technológii (pri vývoji externého popisu PS) priamou voľbou používateľa spôsobu a štýlu tejto interakcie, fixujúc všetky potrebné podrobnosti. V podstate sa v tejto fáze vytvára presný popis používateľského rozhrania, zrozumiteľný softvérovou podporou výpočtovej techniky a so zodpovednou účasťou používateľa. To všetko je založené na prítomnosti softvérovej podpory počítačovej technológie prispôsobiteľného shellu s rozsiahlou knižnicou polotovarov pre rôzne fragmenty a detaily obrazovky. Zdá sa, že tento druh prototypovania je najlepším spôsobom, ako preklenúť bariéru medzi používateľom a vývojárom.

Vývoj špecifikácií PS rozpadá sa na niekoľko rôznych procesov. Ak vylúčime počiatočnú fázu vývoja špecifikácií (určenie požiadaviek), potom tieto procesy využívajú metódy, ktoré vedú k tvorbe formalizovaných dokumentov, t.j. používajú sa formalizované špecifikačné jazyky. Zároveň sa vo veľkej miere využívajú grafické metódy špecifikácií, ktoré vedú k vytváraniu rôznych schém a diagramov, ktoré určujú štruktúru informačného prostredia a štruktúru riadenia PS. K takýmto štruktúram sú pripojené fragmenty údajov a popisy programov, prezentované v jazykoch algebraickej špecifikácie (napríklad pomocou operačnej alebo axiomatickej sémantiky) alebo jazykoch logickej špecifikácie (na základe logického prístupu k špecifikácii programu). Takéto špecifikácie umožňujú, aby sa programy generovali z veľkej časti alebo úplne automaticky. Nevyhnutnou súčasťou vývoja špecifikácií je vytvorenie slovníka pomenovaných entít používaných v špecifikáciách.

Automatizované riadenie špecifikácií PS využíva skutočnosť, že významná časť špecifikácií je prezentovaná vo formálnych jazykoch. To vám umožňuje automaticky vykonávať rôzne typy kontroly: syntaktickú a čiastočnú sémantickú kontrolu špecifikácií, kontrolu úplnosti a konzistencie schém a diagramov (predovšetkým je potrebné identifikovať všetky ich prvky a premietnuť ich do slovníka pomenovaných entít), koniec -dokonca kontrola rovnováhy úrovní špecifikácií a iných typov kontroly v závislosti od možností jazykov špecifikácie.

generácie programy PS. V tejto fáze automaticky generuje kostry kódu pre programy PS alebo úplne kódy pre tieto programy podľa formálnych špecifikácií PS.

Automatizovaná dokumentácia PS. Predpokladá možnosť generovania rôznych foriem dokumentov s ich čiastočným plnením podľa informácií uložených v úložisku. Zároveň sa v porovnaní s tradičnou technológiou znižuje počet typov dokumentov.

Komplexné testovanie a ladenie PS. V tejto fáze sa testujú všetky špecifikácie PS a opravujú sa chyby zistené počas tohto procesu. Testy je možné vytvárať manuálne aj automaticky (ak to umožňujú používané špecifikačné jazyky) a prechádzajú cez vygenerované PS programy.

Certifikácia PSmá rovnaký obsah.

podpora PS je výrazne zjednodušený, pretože hlavné zmeny sa vykonávajú iba v špecifikáciách.

Pracovisko výpočtovej techniky vývoja softvéru je nástrojové prostredie, ktoré podporuje všetky fázy životného cyklu tejto technológie. Toto prostredie výrazne využíva úložisko. V úložisku sú uložené všetky informácie vytvorené počas vývoja PS (najmä slovník pomenovaných entít a všetky špecifikácie). Pracovisko výpočtovej techniky je ako také integrované, aspoň čo sa týka používateľského rozhrania a dát. Hlavnými nástrojmi takéhoto pracoviska sú:

  • dizajnéri používateľského rozhrania;
  • nástroj na prácu so slovníkom pomenovaných entít;
  • grafické a testovacie editory špecifikácií;
  • analyzátory špecifikácií;
  • generátor programov;
  • dokumentátori.

14.5. Systémy nástrojov technológie programovania

Systém nástrojov programovacej technológie - je integrovaná sada softvérových a hardvérových nástrojov, ktoré podporujú všetky procesy vývoja a údržby veľkých PS počas celého ich životného cyklu v rámci určitej technológie. Už bolo uvedené vyššie (pozri odsek 14.3), že okrem toho, že je integrovaný, má aj vlastnosti zložitosti a zamerania na kolektívny rozvoj. To znamená, že je založený na konzistencii produktov technologických procesov. Prístrojový systém je teda schopný zabezpečiť aspoň kontrolu nad úplnosťou (úplnosťou) vytvorenej dokumentácie (vrátane sady programov) a konzistenciou jej zmeny (verzovanie). Podpora fázy údržby PS prístrojovým systémom znamená, že musí zabezpečiť Správa konfigurácie PS. Nástrojový systém navyše podporuje riadenie práce tímu a pre rôznych členov tohto tímu poskytuje rôzne prístupové práva k rôznym fragmentom výrobných technologických procesov a podporuje prácu manažérov za riadenie tímu vývojárov. Systémy nástrojov programovacej technológie sú veľké a drahé softvérové ​​systémy, ktoré sú nejakým spôsobom odôvodnené preťažením nástrojmi. Preto je súbor nástrojov v nich obsiahnutých starostlivo vybraný s ohľadom na potreby oblasti, používané jazyky a zvolenú technológiu programovania.

Berúc do úvahy diskutované vlastnosti inštrumentálnych systémov programovacej techniky, možno rozlíšiť tri z ich hlavných komponentov:

  • Úložisko,
  • nástroje,
  • rozhrania.

Nástroje- súbor nástrojov, ktorý definuje schopnosti, ktoré systém poskytuje vývojovému tímu. Zvyčajne je tento súbor otvorený a štruktúrovaný. Okrem minimálnej sady ( vstavané nástroje), obsahuje prostriedky jeho rozšírenia ( dovážané nástroje). Navyše, vďaka integrácii cez akcie, pozostáva z určitej spoločnej časti všetkých nástrojov ( jadrá) a štrukturálne (niekedy hierarchicky súvisiace) triedy nástrojov.

Rozhraniarozdelené na užívateľské a systémové. Vlastné Rozhranie poskytuje vývojárom prístup k súprave nástrojov. Je implementovaný škrupina systémov. Systémové rozhrania poskytujú interakciu medzi nástrojmi a ich spoločnými časťami. Systémové rozhrania vynikajú ako architektonické komponenty vďaka otvorenosti systému – musia ich používať nové ( dovezené) nástroje zahrnuté v systéme.

Najvšeobecnejšia architektúra inštrumentálnych systémov programovacej techniky je znázornená na obr. 16.4.


Ryža. 16.4. Všeobecná architektúra inštrumentálnych systémov programovacej techniky.

Existujú dve triedy systémov nástrojov programovacej technológie: systémy nástrojov na podporu projektu a systémy nástrojov závislé od jazyka.

Systém nástrojov na podporu projektu - ide o otvorený systém, ktorý dokáže podporovať vývoj PS v rôznych programovacích jazykoch po jeho príslušnom rozšírení o softvérové ​​nástroje orientované na zvolený jazyk. Sada nástrojov takéhoto systému podporuje vývoj PS a obsahuje aj nástroje nezávislé na programovacom jazyku, ktoré podporujú vývoj PS (textové a grafický editor, generátory správ atď.). Okrem toho obsahuje nástroje na rozšírenie systému. Jadro takéhoto systému zabezpečuje najmä prístup do úložiska.

Jazykovo závislý nástrojový systém - ide o systém na podporu vývoja softvéru v ľubovoľnom programovacom jazyku, ktorý v podstate využíva špecifiká tohto jazyka pri organizácii svojej práce. Táto špecifickosť môže ovplyvniť tak schopnosti jadra (vrátane štruktúry úložiska), ako aj požiadavky na shell a nástroje. Príkladom takéhoto systému je Ada Programming Support Environment (APSE).

7.1. Nástroje na vývoj softvéru

Nástrojový softvér (Software tools) - softvér používaný v priebehu vývoja, opravy alebo vývoja iných programov:

editory, kompilátory, debuggery, pomocné systémové programy, grafické balíky atď.

Patria sem programovacie jazyky, integrované prostredia na vývoj programov, systémy CASE atď.

7.1.2. Výber programovacieho jazyka

V súčasnosti existujúce programovacie jazyky možno rozdeliť do nasledujúcich skupín:

Univerzálne jazyky na vysokej úrovni;

Špecializované jazyky pre vývojárov softvéru;

Špecializované používateľské jazyky;

Jazyky nízky level.

V skupine univerzálnych jazykov na vysokej úrovni je dnes nesporným lídrom jazyk C ++. V skutočnosti má niekoľko výhod:

Škálovateľnosť. V jazyku C++ sú programy vyvíjané pre širokú škálu platforiem a systémov;

Schopnosť pracovať na nízkej úrovni s pamäťou, adresami, portami, ktoré sa pri neopatrnom používaní môžu ľahko zmeniť na nevýhodu;

C++ má výkonný preprocesor zdedený z C, ale ako každý iný výkonný nástroj je potrebné ho používať opatrne;

Schopnosť vytvárať zovšeobecnené algoritmy pre odlišné typyúdajov, ich špecializácia a výpočty v štádiu zostavovania pomocou šablón.

Jazyk C++ má zároveň niekoľko významných nedostatkov:

Pripojenie rozhrania externého modulu prostredníctvom vloženia hlavičkového súboru predprocesorom (#include) vážne spomaľuje kompiláciu, keď je zahrnutý veľký počet modulov;

Nedostatok informácií o type údajov v čase kompilácie;

Ťažkosti s učením a zostavovaním;

Niektoré typy konverzií nie sú intuitívne. Najmä operácia s číslami bez znamienka a číslami so znamienkom vytvára výsledok bez znamienka.

Pre C++ existuje veľké množstvo knižníc tried, ktoré podporujú vytváranie používateľského rozhrania, aplikácií klient-server, prácu s databázami atď.

takže zatiaľ neexistuje žiadna alternatíva k C++. Pre sekundárne projekty sa niekedy používa Visual Basic. Jazyk Java bol považovaný za alternatívu k Basic, ale kvôli chýbajúcemu vizuálu

prostriedkom na rozvíjanie foriem, stále zostáva málo použiteľný.

Modern Object Pascal, podobne ako Pascal, navrhnutý N. Wirthom v polovici 70. rokov 20. storočia, zostáva najatraktívnejším pre výučbu základov programovania vďaka svojmu

jednoduchosť, štruktúrovanosť a odhalenie veľkého množstva nielen syntaktických, ale aj sémantických chýb kompilátorom.

Dnes, na rozdiel od 60. rokov, programovacie jazyky sa vytvárajú len zriedka. Za posledných 15 rokov možno zaznamenať iba dve novinky, ktoré sa rozšírili - je to Java (Sun Microsystems, 1995), ktorá sa stala populárnou najmä vďaka technológii jej používania na internete a vzniku takého konceptu, ako je napr. virtuálny stroj Java a C # (Microsoft, 2000), založené na C++.

Tvorcom jazyka je zamestnanec Microsoftu Andreas Hejlsberg. Vo svete programátorov sa preslávil dávno predtým, ako prišiel do Microsoftu. Hejlsberg patril medzi popredných

vývojári jedného z najpopulárnejších vývojových prostredí - Delphi. V Microsofte pomáhal vytvárať verzie Java- J++, takže má veľa skúseností s písaním jazykov a programovacích prostredí. Ako sám Andreas Hejlsberg poznamenal, C# bol vytvorený ako komponentový programovací jazyk, a to je jedna z hlavných výhod jazyka, zameraná na možnosť opätovného použitia vytvorených komponentov.

Ďalšie výhody jazyka C#:

Zachováva si najlepšie vlastnosti populárnych programovacích jazykov C/C++, na ktorých je založený. V tomto ohľade je uľahčený prechod programátorov z C ++ na C #;

Je to jednoduchšie a spoľahlivejšie ako C++. Jednoduchosť a spoľahlivosť sú spôsobené hlavne tým, že C#, hoci je povolené, nepodporuje také nebezpečné vlastnosti C++,

ako ukazovatele, adresovanie, dereferencovanie, aritmetika adries;

Je plne objektovo orientovaný jazyk, kde aj typy zabudované do jazyka sú reprezentované triedami;

Implementuje schopnosti dedenia a univerzalizácie;

Berie do úvahy všetky funkcie Framework .Net, keďže C# bolo vytvorené súbežne s týmto prostredím;

S .Net Framework postaveným na operačnom systéme získajú programátori C# rovnaké výhody práce s virtuálnym strojom ako

Java programátori. Efektívnosť kódu je dokonca vylepšená, pretože runtime CLR je prechodný jazykový kompilátor

virtuálny stroj Java je interpret bajtového kódu;

Výkonná rámcová knižnica podporuje pohodlie pri vytváraní rôznych typov aplikácií C#, čo vám umožňuje jednoducho vytvárať webové služby, iné druhy komponentov,

stačí jednoducho ukladať a získavať informácie z databázy a iných dátových úložísk;

Je to zdroj spoľahlivého a efektívneho kódu.

Okrem jazykov opísaných vyššie patria do univerzálnej skupiny aj Modula, Ada, COBOL, FORTRAN a niektoré ďalšie. Každý z vyššie uvedených jazykov má svoje vlastné charakteristiky, a teda aj svoj vlastný rozsah. V súčasnosti sa univerzálne programovacie jazyky používajú v rôznych oblastiach ľudskej činnosti, ako napríklad:

Vedecké výpočty (jazyky C++, FORTRAN, Java);

Systémové programovanie (jazyky C++, Java);

Spracovanie informácií (jazyky ​​C++, COBOL, Java);

Umelá inteligencia (LISP, Prolog);

Publikovanie (Postscript, TeX);

Vzdialené spracovanie informácií (Perl, PHP, Java, C++);

Popis dokumentov (HTML, XML).

V priebehu času sa niektoré jazyky vyvinuli, získali nové funkcie a zostali v dopyte, iné stratili svoj význam a dnes sú v najlepšom prípade čisto teoretické (Focal, PL / 1 atď.). Je to spôsobené najmä nasledujúcimi faktormi:

Dostupnosť programovacieho prostredia, ktoré podporuje vývoj aplikácií v konkrétnom programovacom jazyku;

Jednoduchá údržba a testovanie programov;

Náklady na vývoj pomocou špecifického programovacieho jazyka;

Jasnosť a ortogonalita jazykových konštrukcií;

Aplikácia objektovo orientovaného prístupu.

Na vytváranie špecifických typov softvéru sa používajú špecializované vývojárske jazyky. Zahŕňajú:

Databázové jazyky;

Jazyky na vytváranie sieťových aplikácií;

Jazyky na vytváranie systémov umelej inteligencie atď.

Špecializované používateľské jazyky sú zvyčajne súčasťou profesionálnych používateľských prostredí, sú úzko zamerané a nepoužívajú ich vývojári softvéru.

Nízkoúrovňové jazyky umožňujú programovanie takmer na úrovni strojových inštrukcií. Zároveň získajú to najoptimálnejšie z časového hľadiska

vykonaním a z hľadiska množstva pamäte potrebnej pre program. Ich nevýhodou je, že nepodporujú princípy štruktúrovaného programovania.

V súčasnosti jazyky typu assembler zvyčajne používajú:

Pri písaní porovnateľne jednoduché programy, kontaktovať technické prostriedky, ako sú vodiči;

Vo forme insertov do programov vo vyšších jazykoch napríklad na urýchlenie transformácie dát v slučkách s veľkým počtom opakovaní.

Vo väčšej miere je výber programovacieho jazyka určený skúsenosťami vývojára, požiadavkami organizácie vedúcej vývoj alebo jednoducho ustáleným názorom.

7.7.3. Výber programovacieho prostredia

Integrované prostredie na vývoj softvéru je systém softvérové ​​nástroje používané programátormi na vývoj softvéru.

Vývojové prostredie zvyčajne obsahuje textový editor, kompilátor a/alebo tlmočník, linker, debugger a systém pomoci. Niekedy obsahuje aj systém správy verzií a rôzne nástroje na zjednodušenie konštrukcie grafického používateľského rozhrania.

Mnohé moderné vývojové prostredia obsahujú aj inšpektor objektov, prehliadač tried a diagram hierarchie tried, ktoré sa používajú na objektovo orientovaný vývoj softvéru.

Typicky je vývojové prostredie pre jeden špecifický programovací jazyk, ako napríklad Visual Basic alebo Deiphi, ale existujú vývojové prostredia pre viacero jazykov, ako napríklad Eclipse alebo Microsoft Visual Studio.

Príkladmi vývojových prostredí sú Turbo Pascal, Borland C++, GNU toolchain, DrPython.

V poslednej dobe sa s rozvojom objektovo orientovaného programovania rozšírili skôr spomínané vizuálne programovacie prostredia, v

ktoré sú najbežnejšie bloky programového kódu reprezentované ako grafické objekty.

Najčastejšie používané vizuálne prostredia sú Delphi, C++ Builder od Borland (Inprise Corporation), Visual C++, Visual Basic od Microsoftu, Visual Ada od IBM atď.

Technológia .NET Framework, navrhnutá spoločnosťou Microsoft ako platforma na vytváranie bežných programov a webových aplikácií, si v súčasnosti získala veľkú obľubu. Hlavnou výhodou .NET je kompatibilita rôznych služieb napísaných v rôznych jazykoch.

Napríklad služba napísaná v C++ pre .NET môže pristupovať k metóde triedy z knižnice napísanej v Delphi; v C# môžete napísať triedu, ktorá dedí z triedy napísanej vo Visual Basic .NET a výnimku vyvolanú metódou napísanou v C# možno zachytiť a spracovať v Delphi.

Rovnako ako v prípade výberu programovacieho jazyka je výber programovacieho prostredia určený povahou projektu, zvykmi a schopnosťami vývojára, trendmi doby, požiadavkami zákazníka a jednoducho verejnou mienkou. : „Všetok takýto vývoj by sa mal vykonávať v prostredí...

1. Nástroje na vývoj softvéru. V procese vývoja softvérových nástrojov sa v tej či onej miere využíva počítačová podpora pre vývoj softvérových systémov. Dosahuje sa to prezentovaním aspoň niektorých programových dokumentov PS (predovšetkým programov) na počítačových dátových nosičoch (napríklad diskoch) a poskytnutím špeciálnych PS alebo špeciálnych zariadení zahrnutých v počítači, vytvorených na akékoľvek spracovanie takýchto dokumentov. . Ako taký špeciálny PS môžete zadať kompilátor z akéhokoľvek programovacieho jazyka.

Kompilátor zbavuje vývojára PS potreby písať programy v jazyku počítača, čo je pre vývojára. PS by bolo mimoriadne nepohodlné - namiesto toho píše programy v programovacom jazyku, ktorý je pre neho vhodný, ktorý príslušný kompilátor automaticky preloží do jazyka počítača. Ako špeciálne zariadenie, ktorý podporuje proces vývoja PS, môže slúžiť ako emulátor akéhokoľvek jazyka. Emulátor umožňuje spúšťať (interpretovať) programy v inom jazyku, ako je jazyk počítača, ktorý podporuje vývoj PS, napríklad v jazyku počítača, pre ktorý je tento program určený. PS určený na podporu vývoja iných PS sa bude nazývať nástrojom vývoja softvéru pre PS a počítačové zariadenie špeciálne navrhnuté na podporu vývoja PS sa bude nazývať nástrojom vývoja hardvéru pre PS.

Vývojové nástroje PS možno používať počas celého životného cyklu PS na prácu s rôznymi programovými dokumentmi. Takže textový editor možno použiť na vývoj takmer akéhokoľvek programového dokumentu. Z hľadiska funkcií, ktoré nástroje vykonávajú pri vývoji softvéru, ich možno rozdeliť do nasledujúcich štyroch skupín: editory, analyzátory, konvertory, nástroje podporujúce proces vykonávania programu.

Editory podporujú návrh (tvorbu) určitých programových dokumentov v rôznych fázach životného cyklu. Ako už bolo spomenuté, na tento účel môžete použiť nejaký univerzálny textový editor. Špecializovaní editori však môžu poskytnúť silnejšiu podporu: každý typ dokumentu má svoj vlastný editor. Najmä v počiatočných fázach vývoja môžu dokumenty vo veľkej miere využívať grafické pomôcky popisy (schémy, schémy atď.). V takýchto prípadoch môžu byť veľmi užitočné grafické editory. Vo fáze programovania (kódovania) môže byť vhodnejšie použiť namiesto textového editora syntakticky riadený editor, ktorý je orientovaný na použitý programovací jazyk. Analyzátory vykonávajú buď statické spracovanie dokumentov, vykonávajú rôzne druhy ich kontroly, identifikujú ich určité vlastnosti a zhromažďujú štatistické údaje (napríklad kontrolu súladu dokumentov so stanovenými normami), alebo dynamickú analýzu programov (napr. na identifikáciu distribúcie runtime programu podľa programových modulov). Konvertory umožňujú automaticky preniesť dokumenty do inej formy prezentácie (napríklad formátovače) alebo preložiť dokument jedného typu do dokumentu iného typu (napríklad konvertory alebo kompilátory), syntetizovať dokument zo samostatných častí atď.

Nástroje, ktoré podporujú proces vykonávania programu, umožňujú vykonávať na počítači popisy procesov alebo ich jednotlivých častí, prezentované v inej forme ako strojový kód alebo strojový kód s pridané vlastnosti jeho výklad. Príkladom takéhoto nástroja je emulátor kódu iného počítača. Do tejto skupiny nástrojov by mali byť zahrnuté aj rôzne debuggery. V podstate každý programovací systém obsahuje runtime softvérový subsystém, ktorý vykonáva najtypickejšie programové fragmenty pre daný programovací jazyk a poskytuje štandardnú odpoveď na výnimky, ktoré vznikajú pri vykonávaní programov (takýto subsystém budeme nazývať výkonná podpora) – môže byť aj považovaný za nástroj pre tieto skupiny.

2. Nástrojové prostredia pre vývoj a údržbu softvéru. V súčasnosti nie sú s každým programovacím systémom spojené samostatné nástroje (napríklad kompilátor), ale nejaká logicky súvisiaca sada softvérových a hardvérových nástrojov, ktoré podporujú vývoj a údržbu softvérových systémov na daný jazyk programovanie alebo zameranie na akúkoľvek konkrétnu oblasť. Takýto súbor sa bude nazývať inštrumentálne prostredie pre vývoj a údržbu PS. Takéto nástrojové prostredia sa vyznačujú po prvé používaním softvérových aj hardvérových nástrojov a po druhé určitou orientáciou buď na konkrétny programovací jazyk, alebo na konkrétnu oblasť. Prostredie nástroja nemusí fungovať na počítači, na ktorom sa bude používať PS vyvinutý s jeho pomocou. Často je takáto kombinácia celkom pohodlná (ak to umožňuje len výkon použitého počítača): nie je potrebné zaoberať sa počítačmi rôznych typov, do vyvinutého PS možno zahrnúť komponenty samotného prostredia nástroja.

Existujú tri hlavné triedy nástrojových prostredí pre vývoj a údržbu programovacieho prostredia PS, pracoviská výpočtovej techniky, nástrojové systémy programovacej techniky. Programovacie prostredie je určené najmä na podporu procesov programovania (kódovania), testovania a ladenia PS. Pracovisko výpočtovej techniky je zamerané na podporu raných fáz vývoja PS (špecifikácií) a automatického generovania programov podľa špecifikácií. Systém nástrojov programovacej technológie je navrhnutý tak, aby podporoval všetky procesy vývoja a údržby počas celého životného cyklu softvéru a je zameraný na kolektívny vývoj veľkých softvérové ​​systémy s dlhým životným cyklom.

3. Prostredia programovacích nástrojov obsahujú v prvom rade textový editor, ktorý umožňuje navrhovať programy v danom programovacom jazyku, nástroje umožňujúce kompilovať či interpretovať programy v tomto jazyku, ako aj testovať a ladiť výsledné programy. Okrem toho môžu existovať ďalšie nástroje, napríklad na analýzu statických alebo dynamických programov. Tieto nástroje sa navzájom ovplyvňujú prostredníctvom bežných súborov pomocou štandardných funkcií. systém súborov. Existujú nasledujúce triedy prostredí programovacích nástrojov: prostredia všeobecný účel, jazykovo orientované prostredia.

Programovacie prostredia na všeobecné použitie obsahujú sadu softvérových nástrojov, ktoré podporujú vývoj programov v rôznych programovacích jazykoch (napríklad textový editor, linker alebo tlmočník pre jazyk cieľového počítača) a sú zvyčajne nejakým rozšírením schopnosti používaného operačného systému. Na programovanie v takomto prostredí v akomkoľvek programovacom jazyku budete potrebovať ďalšie nástroje, ktoré sú na tento jazyk orientované (napríklad kompilátor). . . Klasifikácia programovacích prostredí

4. Koncepcia výpočtovej techniky pre vývoj softvéru a jeho úlohy. Existujú určité ťažkosti pri vytváraní presnej definície technológie CASE (počítačová technológia na vývoj PS). CASE je skratka anglického Computer-Aided Software Engineering (Computer. Assisted Programming Engineering). Ale bez pomoci (podpory) počítača sa PS už dávno nevyvíjajú (používa sa aspoň kompilátor). V skutočnosti je tomuto pojmu vložený užší (špeciálny) význam, ktorý sa postupne stiera (ako to býva vždy, keď pojem nemá striktnú definíciu). Spočiatku sa CASE chápalo ako inžinierstvo raných fáz vývoja softvéru (definícia požiadaviek, vypracovanie externého popisu a architektúry PS) pomocou softvérovej podpory (softvérové ​​nástroje). Teraz možno CASE chápať aj ako inžinierstvo celého životného cyklu softvéru (vrátane jeho údržby), ale iba v prípade, keď sú programy čiastočne alebo úplne generované podľa dokumentov získaných v uvedených počiatočných fázach vývoja. V tomto prípade sa technológia CASE zásadne líši od manuálnej (tradičnej) technológie vývoja softvéru: zmenil sa nielen obsah technologických procesov, ale aj ich súhrn.

V súčasnosti možno výpočtovú techniku ​​na vývoj PS charakterizovať - ​​využívaním softvérovej podpory pre vývoj grafických požiadaviek a grafických špecifikácií PS, - automatickým generovaním programov v ľubovoľnom programovacom jazyku alebo v strojovom kóde (čiastočne alebo úplne ), - softvérová podpora prototypovania.

Systém nástrojov programovacej technológie je integrovaný súbor softvérových a hardvérových nástrojov, ktorý podporuje všetky procesy vývoja a údržby veľkých softvérových systémov počas celého životného cyklu v rámci určitej technológie. Z tejto definície vyplývajú tieto hlavné znaky tejto triedy počítačovej podpory: · komplexnosť, · zameranie na kolektívny rozvoj, · technologická istota, · integrácia.

S prihliadnutím na diskutované vlastnosti inštrumentálnych systémov programovacej techniky možno rozlíšiť tri ich hlavné komponenty: · vývojovú databázu (repozitár), · nástroje, · rozhrania.

Úložisko - centrálne počítačové úložisko informácií súvisiacich s projektom (vývojom) PS počas celého životného cyklu. Toolkit – sada nástrojov, ktorá definuje schopnosti, ktoré systém poskytuje vývojovému tímu. Zvyčajne je táto sada otvorená: okrem minimálnej sady (vstavané nástroje) obsahuje prostriedky na jej rozšírenie (importované nástroje) a štruktúrovanú, pozostávajúcu z nejakej spoločnej časti všetkých nástrojov (jadro) a štrukturálnych (niekedy hierarchicky súvisiace) triedy nástrojov. Rozhrania sú rozdelené na 1) používateľské 2) systémové. Používateľské rozhranie poskytuje vývojárom prístup k nástrojom (príkazový jazyk atď.), ktoré implementuje systémový shell. Systémové rozhrania zabezpečujú interakciu medzi nástrojmi a ich spoločnými časťami. Systémové rozhrania vynikajú ako architektonické komponenty vďaka otvorenosti systému – musia ich využívať nové (importované) nástroje zahrnuté v systéme.

Existujú dve triedy systémov nástrojov programovacej technológie: 1) systémy nástrojov na podporu projektu a 2) systémy nástrojov závislé od jazyka. Systém nástrojov projektovej podpory je otvorený systém schopný podporovať vývoj softvérových produktov v rôznych programovacích jazykoch po jeho príslušnom rozšírení o softvérové ​​nástroje orientované na zvolený jazyk. Takýto systém obsahuje jadro (zabezpečujúce najmä prístup k úložisku), sadu nástrojov, ktoré podporujú riadenie (riadenie) vývoja PS, nástroje nezávislé na programovacom jazyku, ktoré podporujú vývoj PS (textové a grafické editory, generátory zostáv atď.), ako aj nástroje na rozšírenie systému. Jazykovo závislý inštrumentálny systém je systém podpory vývoja softvéru v akomkoľvek programovacom jazyku, ktorý v podstate využíva špecifiká tohto jazyka pri organizovaní svojej práce. Táto špecifickosť môže ovplyvniť tak schopnosti jadra (vrátane štruktúry úložiska), ako aj požiadavky na shell a nástroje.

Jednotný modelovací jazyk UML Most existujúce metódy objektovo orientovaná analýza a návrh (OOAD) zahŕňa modelovací jazyk aj popis procesu modelovania. Modelovací jazyk je zápis (väčšinou grafický), ktorý sa používa v metóde na opis projektov. Notácia je zbierka grafických objektov, ktoré sa používajú v modeloch; je to syntax modelovacieho jazyka. Napríklad zápis diagramu tried definuje, ako sú reprezentované prvky a koncepty ako trieda, asociácia a multiplicita. Proces je popis krokov, ktoré treba dodržať pri vývoji projektu. Unified Modeling Language (UML) je nástupcom generácie metód OOAP, ktoré sa objavili koncom 80. a začiatkom 90. rokov.

UML je všeobecný vizuálny modelovací jazyk, ktorý je určený na špecifikáciu, vizualizáciu, návrh a dokumentáciu softvérových komponentov, obchodných procesov a iných systémov. Jazyk UML je jednoduchý a zároveň výkonný modelovací nástroj, ktorý možno efektívne použiť na vytváranie konceptuálnych, logických a grafických modelov zložitých systémov rôzneho druhu. určený účel. Konštruktívne používanie UML je založené na porozumení všeobecné zásady najmä modelovanie zložitých systémov a vlastností procesu objektovo orientovaného projektovania (OOP). Voľba výrazových prostriedkov na budovanie modelov zložitých systémov predurčuje úlohy, ktoré je možné pomocou týchto modelov riešiť. Zároveň je jedným zo základných princípov konštrukcie modelov zložitých systémov princíp abstrakcie, ktorý predpisuje zahrnúť do modelu len tie aspekty navrhovaného systému, ktoré priamo súvisia s výkonom funkcií systému alebo s ním zamýšľaným účel. V tomto prípade sú vynechané všetky drobné detaily, aby sa príliš neskomplikoval proces analýzy a štúdia výsledného modelu.

UML obsahuje štandardnú sadu diagramov a zápisov rôznych druhov. Diagram v UML je grafické znázornenie množina prvkov, najčastejšie zobrazovaná ako súvislý graf s vrcholmi (entitami) a hranami (reláciami). Diagramy sú nakreslené na vizualizáciu systému z rôznych perspektív. Diagram je v istom zmysle jednou z projekcií systému. Spravidla, s výnimkou najtriviálnejších prípadov, diagramy poskytujú zhustený pohľad na prvky, ktoré tvoria systém. Rovnaký prvok môže byť prítomný vo všetkých diagramoch, alebo len v niekoľkých (najbežnejšia možnosť), alebo nie je prítomný v žiadnom (veľmi zriedkavé). Teoreticky môžu diagramy obsahovať akúkoľvek kombináciu entít a vzťahov. V praxi sa však používa relatívne malý počet typických kombinácií zodpovedajúcich piatim najbežnejším typom, ktoré tvoria architektúru softvérového systému.

UML rozlišuje tieto typy diagramov: - diagramy prípadov použitia - na modelovanie obchodných procesov organizácie (systémové požiadavky); - diagramy tried (diagramy tried) - na modelovanie statickej štruktúry tried systému a vzťahov medzi nimi. Takéto diagramy zobrazujú triedy, rozhrania, objekty a spolupráce, ako aj ich vzťahy. Pri modelovaní objektovo orientovaných systémov sa tento typ diagramu používa najčastejšie. Diagramy tried zodpovedajú statickému pohľadu na systém z hľadiska návrhu; – diagramy správania systému (diagramy správania); interakčné diagramy - na modelovanie procesu posielania správ medzi objektmi. - stavové diagramy - na modelovanie správania sa objektov systému pri prechode z jedného stavu do druhého.

- diagramy aktivít - na modelovanie správania sa systému v rámci rôzne možnosti používanie alebo modelovanie. - implementačné diagramy (implementačné diagramy): diagramy komponentov (diagramy komponentov) - na modelovanie hierarchie komponentov (subsystémov) systému; diagramy nasadenia (deployment diagrams) - na modelovanie fyzickej architektúry systému.

Úvod

V procese vývoja softvéru sa používa veľké množstvo najuniverzálnejšieho softvéru (SW). Tento kurz prednášok skúma kedy a čo sa používa vo fáze vývoja aplikácie.

Aby sme poskytli úplnejší obraz o úlohe každého nástroja alebo vývojových segmentov v procese vývoja softvéru, všetky nástroje diskutované v tomto kurze prednášok zvážime na príklade vývoja aplikácií pomocou jedného z ich jazykov na vysokej úrovni. Všetky používané nástroje možno pre jednoduchosť rozdeliť do 4 skupín. Pozrime sa bližšie na každú zo skupín.

Požadovaný

Potrebné nástroje sú tie, bez ktorých v zásade nie je možné získať spustiteľný kód; Táto skupina zahŕňa:

§ textové editory;

§ kompilátory a assemblery;

§ linkery alebo odkazy editorov (linkery);

Často používané

Ide o prostriedky, ktorých použitiu sa na rozdiel od nevyhnutných dá vyhnúť. Ale bez nich je proces vývoja veľmi ťažký a predĺžený; Medzi bežne používané nástroje patria:

§ pomôcky na automatickú montáž projektu;

§ debuggery;

§ programy na vytváranie inštalátorov;

§ editory zdrojov;

§ profilovači;

§ programy na podporu verzií;

§ programy na vytváranie súborov pomocníka (dokumentácie).

Špecializovaný

Tieto nástroje sa používajú vo výnimočných prípadoch, riešia skôr špecifické úlohy:

§ programy na sledovanie závislostí;

§ rozoberače;

§ dekompilátory;

§ hex editory;

§ programy na sledovanie aktivity systému a zmien vyskytujúcich sa v systéme;

§ overovacie programy a kontajnery (vytvorte virtuálne prostredie pre jednotlivé triedy programov, v ktorom môžete skúmať správanie programu);

Integrované vývojové prostredia

IDE obsahujú väčšinu vyššie uvedených programov a umožňujú vám zjednodušiť proces vytvárania aplikácií. Celkovo je vývojové prostredie program, ktorý spája niekoľko nástrojov z prvej a druhej (a niekedy aj tretej) skupiny.

V budúcnosti sa bližšie zoznámime s hlavnými predstaviteľmi každej skupiny a zvážime, ako to celé funguje v integrovanom vývojovom prostredí.

KLASIFIKÁCIA NÁSTROJOV

TÉMA 1 KONCEPCIA NÁSTROJOV.

KLASIFIKÁCIA NÁSTROJOV.

Systém nástrojov programovacej technológie- je integrovaná sada softvérových a hardvérových nástrojov, ktoré podporujú všetky procesy vývoja a údržby veľkých PS počas celého ich životného cyklu v rámci určitej technológie.

Nástrojové systémy programovacej techniky možno rozdeliť do troch hlavných komponentov:

úložisko

súprava nástrojov,

rozhrania.

Nástroje- súbor nástrojov, ktorý definuje schopnosti, ktoré systém poskytuje vývojovému tímu. Zvyčajne je tento súbor otvorený a štruktúrovaný. Okrem minimálnej sady ( vstavané nástroje), obsahuje prostriedky jeho rozšírenia ( dovážané nástroje). Navyše, vďaka integrácii cez akcie, pozostáva z určitej spoločnej časti všetkých nástrojov ( jadrá) a štrukturálne (niekedy hierarchicky súvisiace) triedy nástrojov.

Rozhrania rozdelené na užívateľské a systémové. Vlastné Rozhranie poskytuje vývojárom prístup k súprave nástrojov. Je implementovaný škrupina systémov. Systémové rozhrania poskytujú interakciu medzi nástrojmi a ich spoločnými časťami. Systémové rozhrania vynikajú ako architektonické komponenty vďaka otvorenosti systému – musia ich používať nové ( dovezené) nástroje zahrnuté v systéme.

Najvšeobecnejšia architektúra inštrumentálnych systémov programovacej techniky je znázornená na obr.

Ryža. Všeobecná architektúra inštrumentálnych systémov programovacej techniky.

Existujú dve triedy systémov nástrojov programovacej technológie: systémy nástrojov na podporu projektu a systémy nástrojov závislé od jazyka.

Systém nástrojov na podporu projektu- ide o otvorený systém, ktorý dokáže podporovať vývoj PS v rôznych programovacích jazykoch po jeho príslušnom rozšírení o softvérové ​​nástroje orientované na zvolený jazyk. Sada nástrojov takéhoto systému podporuje vývoj PS a obsahuje aj nástroje nezávislé na programovacom jazyku, ktoré podporujú vývoj PS (textové a grafické editory, generátory zostáv a pod.). Okrem toho obsahuje nástroje na rozšírenie systému. Jadro takéhoto systému zabezpečuje najmä prístup do úložiska.

Jazykovo závislý nástrojový systém- ide o systém na podporu vývoja softvéru v ľubovoľnom programovacom jazyku, ktorý v podstate využíva špecifiká tohto jazyka pri organizácii svojej práce. Táto špecifickosť môže ovplyvniť tak schopnosti jadra (vrátane štruktúry úložiska), ako aj požiadavky na shell a nástroje.