A szoftverfejlesztés, mint minden más tevékenységi terület, bizonyos eszközöket igényel. Ha azonban az átlagembernek általában szüksége szoftverek listája vállalati felhasználó(egy lehetőség az átlagos otthoni felhasználó számára) többé-kevésbé kézenfekvő, akkor a fejlesztőknél nem ilyen egyszerű a dolog: az alkalmazások készítéséhez használt eszközök listája korántsem korlátozódik a fejlesztőeszközökre.

Bevezetés

Amikor szoftverfejlesztésről beszélünk, sok felhasználó mindenekelőtt az alkalmazáskód írására, vagy jó esetben a megalkotott termékek megvalósítására gondol. Ez a nézet gyakran múltbeli tapasztalatokon alapul. Sok informatikai szakember és felhasználó – különösen az idősebbek – akadémikus. A 80-as években a programozás gyakran kiegészítette a tudományos kutatásokat, és lényegében a tudós maga tűzte ki a feladatot, hajtotta végre, és a létrehozott alkalmazás egyetlen (vagy a kevés közül) felhasználója volt. Ennek az lett a következménye, hogy a 90-es évek elején Oroszországban jó néhány fejlesztő volt (sokszor ugyanazok a korábbi tudósok, akik tudtak programozni), akik már elidegenedett termékeket hoztak létre, de közben tárgyaltak a vevőkkel, alkalmazásokat terveztek, írt. kódot, elkészítette a projektdokumentációt, tesztelte és implementálta a terméket, és gyakran egyidejűleg kísérte a felhasználói munkaállomásokat. Természetesen egy ilyen általános fejlesztő eszközkészlete általában egy fejlesztőeszközre, a szerződés- és dokumentációkészítést szolgáló szövegszerkesztőre, és sokkal ritkábban adattervező és -elosztás generáló eszközökre korlátozódott.

Bár jelenleg sok ilyen univerzális fejlesztő létezik Oroszországban, a vállalatok túlnyomó többsége, még a viszonylag kicsik is, egyre inkább szűkebb szakemberek szolgáltatásait veszik igénybe. Ennek oka a szoftverek funkcionalitásával, tervezésével, minőségével és használhatóságával kapcsolatos követelmények jelentős növekedése (próbáljon javasolni modern felhasználó szöveg szerkesztő interfésszel parancs sor ahelyett Microsoft Word!). A modern projektek sikeres megvalósítása nagyon széles körű ismereteket és készségeket igényel, amelyekkel általában különböző szakemberek rendelkeznek, akik különféle műveleteket végeznek a projektben, és megfelelő eszközöket igényelnek.

Színpadok, szerepek, eszközök…

A modern szoftverfejlesztési módszertan egy projektet (vagy annak egy részét, például a projekt következő iterációját) szakaszokra osztja, amelyekben a projektben bizonyos szerepet betöltő szakemberek különféle műveleteket hajtanak végre, és elkészítik a projekt alkotórészeit. Általános szabály, hogy a fejlesztési folyamat megszervezésének bármely megközelítésével a következő szakaszok különböztethetők meg ilyen vagy olyan formában: üzleti elemzés és követelmények meghatározása, tervezés, fejlesztés, tesztelés és minőségértékelés, dokumentáció, megvalósítás és karbantartás - és ennek megfelelően, olyan szerepkörök, mint a projektmenedzser, az üzleti elemző, a rendszerelemző, az alkalmazástervező, az alkalmazáskód-író, a minőségbiztosítási/minőségbiztosítási szakértő, a műszaki író, a megvalósítási szakértő, a karbantartási szakértő, a felhasználói oktatási szakértő, a létrehozott termékmarketing szakértő. A szerepkörök listája a projekt méretétől és összetettségétől függően bővíthető (például egyes projektekben a tesztelőket tesztmenedzserekre, tesztelemzőkre, szkriptírókra az automatizált teszteléshez, felhasználói felület tesztelőire, terhelési tesztelőire és mindegyikre osztják fel. amelyekhez saját eszközökre van szükség), és fordítva - egy kis projektben egy előadó több szerepet is betölthet (például kombinálhatja a tesztelő és a műszaki író szerepét).

Az alábbiakban megnézzük, milyen eszközökre lehet szüksége egy fejlesztőcsapatnak az alkalmazásfejlesztés különböző szakaszaiban.

Követelmények meghatározása

A követelmények meghatározása az üzleti elemzők feladata, akik projekt előtti felmérést végeznek, kommunikálnak az ügyféllel és a potenciális felhasználókkal, feltárják problémáikat, igényeiket. A felmérés eredménye általában egy olyan dokumentum, amelyet hazánkban feladatmeghatározásnak neveznek, és amely információkat tartalmaz a termék céljáról, a rá vonatkozó követelményrendszerről és a projekt határainak leírásáról.

Milyen eszközökre van szükségük az üzleti elemzőknek? Az eszközigényt a projekt léptéke, a megrendelő dokumentációs követelményei, az adott fejlesztő cégnél elfogadott szabványok határozzák meg. Az üzleti elemző megteheti szövegszerkesztő(például Microsoft Word), szöveges formában rögzítve a követelményeket. Mostanában azonban szokás a követelmények leírását UML és IDEF0 diagramokkal illusztrálni, amelyek leírják a felhasználói interakció forgatókönyveit a termékkel, az üzenetek egyik objektumról a másikra való továbbításának sorrendjét, az objektumok egymás közötti interakcióját, munkafolyamatokat, és változó objektumállapotok. Ilyen diagramok készítéséhez használhatja a Microsoft Visio, Rational Rose, Rational XDE, Borland Together alkalmazásokat, diagramok készítéséhez az IDEF0 szabványban a CA AllFusion Process Modeler (korábbi nevén BPwin) a legaktívabb.

Az, hogy egy adott projekthez melyik eszköz alkalmas, nagyban függ a fejlesztési folyamatoktól. Ha egy üzleti elemzőnek csak a projektdokumentációt kell szemléltetnie, akkor az eszköz kiválasztása nem kritikus – mindaddig, amíg meg tud vele rajzolni egy-egy diagramot. Ha az üzleti elemzőnek nem csak illusztrációt kell készítenie, hanem modellt kell létrehoznia, amelyet a rendszerelemzők, fejlesztők és tesztelők a projekt későbbi szakaszaiban használhatnak, akkor az eszköz kiválasztását az határozza meg, hogy képes-e integrálni a fejlesztőeszközökkel, amelyek valószínűleg kódmegvalósító eszközként használható. A technológiailag legfejlettebb modern "fejlesztői eszköz - modellező eszköz" párok közül érdemes megemlíteni, mint például a Visual Studio .NET - Rational XDE, a Visual Studio .NET - Borland Together, a Borland JBuilder - Borland Together.

A szövegszerkesztők és modellező eszközök mellett az üzleti elemzők olyan követelménykezelő eszközöket is használhatnak, amelyek lehetővé teszik a termékkövetelmények strukturált és rendszerezett listájának adatbázisban való tárolását és a későbbi szakaszokban történő hivatkozást, összekapcsolva a követelményeket az azokat megvalósító termékkomponensekkel, valamint tesztek, a termék követelményeknek való megfelelésének ellenőrzése, valamint a szinte minden projektben előforduló követelmények változásainak helyes nyomon követése, függetlenül attól, hogy milyen körültekintően történik a vizsgálat, és ezeknek a változtatásoknak a későbbi munka eredményeire gyakorolt ​​hatása. A RequisitePro (IBM/Rational), a DOORS (Telelogic) és a CaliberRM (Borland) napjaink legismertebb követelménykezelési eszközei közé tartoznak. Valójában a fejlesztési folyamat megfelelő megszervezésével és a szükséges sablonokkal a feladatmeghatározás a követelménykezelő eszközzel generálható, és még az orosz állami szabványok követelményeinek is megfelel.

Tipikus követelménykezelő eszköz interfész (Borland Caliber RM)

Így a követelménydefiníció szakaszában szükség van dokumentum-előkészítő eszközökre, és sok esetben követelménykezelési, üzleti folyamatmodellező és UML modellező eszközökre is.

Tervezés

A követelmények meghatározásának szakaszát, amely a feladatmeghatározás jóváhagyásával zárul, a tervezés szakasza követi. Általában alkalmazástervezők végzik, akik döntéseket hoznak a készülő megoldás architektúrájával és összetevőivel, valamint az ezek megvalósításának technológiáival kapcsolatban, valamint rendszerelemzők, akik adatokat és alkalmazásosztályokat terveznek, és néha felhasználói felületeket prototípus készítenek. . Ennek a szakasznak az eredménye általában egy dokumentum, amelyet gyakran műszaki projektnek neveznek, és amely osztálydiagramokat, adatmodelleket, felhasználói felület prototípusokat tartalmaz.

Jellemzően ebben a szakaszban a létrehozandó alkalmazások osztálydiagramjai és a létrehozandó megoldás telepítési diagramjai, valamint a logikai adatmodellt és azok fizikai struktúráját leíró diagramok a kiválasztott DBMS-hez hozzáadódnak az üzleti elemzők által létrehozott modellhez ezt a szakaszt.

Milyen eszközöket használnak ebben a szakaszban? A fenti UML modellező eszközök osztálydiagramok és telepítési diagramok létrehozására szolgálnak. Az adattervezés általában olyan eszközöket használ, mint a CA AllFusion Data Modeler (korábban ERwin), a Sybase Power Designer, az Oracle Designer, valamint az Embarcadero és a Popkin Software hasonló eszközei. A Microsoft által fejlesztett DBMS-hez meglehetősen sikeresen használhatja a Microsoft Visio-t. A felsorolt ​​eszközök lehetővé teszik legalább egy szkript létrehozását a generáláshoz Adatbázis, és a köztük lévő különbségek abban rejlenek, hogy miként szabályozzák a triggerek és tárolt eljárások létrehozásához kapcsolódó szerveroldali kód generálását.

Vegye figyelembe, hogy ha az UML modellező eszközöket még nem mindenhol használják, akkor az adattervező eszközök használata ma már a kis cégeknél is jellemző. Ez az eszközkategória kötelezőnek minősíthető.

A felhasználói felület prototípusához, ha van ilyen ebben a szakaszban, szükség lehet a jövőbeli alkalmazás formáinak képeinek rajzolására szolgáló eszköz (például Microsoft Visio vagy grafikus szerkesztők), vagy közvetlenül alkalmazásfejlesztő eszközök használatára.

Így a tervezési szakaszban szükség van modellező és adattervező, valamint UML modellező eszközökre, illetve esetenként űrlapképek létrehozására szolgáló eszközökre.

Termékfejlesztés

A fejlesztési szakaszban az alkalmazás kódja a műszaki projektnek megfelelően jön létre, beleértve az adatmodellben nem szereplő funkcionalitást megvalósító szerverkódot is. Ebben a szakaszban a fő eszköz, amelyet használni kell, az alkalmazásfejlesztő eszköz. A fejlesztői eszköz kiválasztását elsősorban a platform (Windows, .NET, Java / J2EE, Linux / UNIX) és az architektúra (alkalmazások GUI, konzolalkalmazások és szolgáltatások, webalkalmazások), és jelenleg meglehetősen változatos. A Java / J2EE alkalmazásfejlesztő eszközöket az IBM, az Oracle, a Borland, a Windows alkalmazásfejlesztő eszközöket - Microsoft, a Borland, a Sybase, a .NET alkalmazásfejlesztő eszközöket - a Microsoft és a Borland, a Linux alkalmazásfejlesztő eszközöket - a Borland és néhány más cég gyártja.

A fejlesztői eszközökön kívül ebben a szakaszban időnként különféle kiegészítő komponenskönyvtárak szükségesek, amelyeket egy adott platformon vagy bizonyos fejlesztői eszközökkel együtt történő használatra terveztek. Ezeket az alkatrészeket szállítjuk nagyszámú független fejlesztők, valamint számos olyan kereskedelmi termék szállítója, amelyek alapján más fejlesztőknek megoldásokat kell létrehozniuk (ilyen termékekre példa számos földrajzi információs rendszer, CAD alkalmazás és egyes szervertermékek).

Természetesen, ha ebben a szakaszban bármilyen szerverterméken (DBMS, J2EE szerver, üzenetküldő szerver stb.) alapuló megoldásokat hoz létre, akkor ezt a terméket kell használnia. Sok esetben, különösen a megoldásfejlesztők számára, az ilyen termékek gyártói alkalmazásfejlesztésre és hibakeresésre szánt verziókat adnak ki, de nem gyártásra.

Az alkalmazásfejlesztési szakaszban modellező eszközöket is használnak, különösen akkor, ha nem csak kódot tudnak generálni különböző programozási nyelveken, hanem támogatják a visszafejtést is azáltal, hogy osztálydiagramot készítenek egy kész alkalmazás alapján, vagy lehetővé teszik a kód és a modell szinkron szerkesztését. . A szinkron kód- és modellváltás funkciója nagymértékben leegyszerűsíti a tényleges fejlesztést kísérő folyamatok nagy részét, így ha van eszközválasztás, akkor érdemes odafigyelni a támogatására (például a kód és modell szinkron cseréje támogatott a Borland Together UML modellező eszköz egyes kiadásai által).

Az alkalmazások létrehozásának szakaszában gyakran kódoptimalizáló és hibakereső eszközöket használnak. Az ilyen eszközök a fejlesztőkészlet részét képezhetik, vagy külön szállíthatják.

Tesztelés és minőségértékelés

Egy termék tesztelésekor a követelményeknek való megfelelését ellenőrzik, és ezen követelmények függvényében végzik el a vizsgálati módszerek meghatározását, tesztek elkészítését és a megfelelő eszközök kiválasztását.

A modern projektekben a felhasználói felületet, az alkalmazások teljesítményét, az adatbiztonságot, valamint a különféle operációs rendszerekkel és alkalmazásokkal való kompatibilitást tesztelik. Ehhez megfelelő eszközöket fejlesztettek ki, például adatbázis-tesztelő segédprogramokat, automatizált felhasználói felület tesztelő eszközöket, terheléstesztelő eszközöket, végrehajtási hibatesztelő eszközöket és alkalmazásbiztonsági tesztelő eszközöket. Az ilyen eszközök általában tartalmaznak szkripteszközöket, amelyek szerint automatizált tesztelés történik, azaz egy műveletsor többszöri végrehajtása, miközben a hibastatisztikát, a művelet végrehajtási idejét és egyéb, a termék minőségének értékelésével kapcsolatos információkat gyűjtik.

A tesztelőeszközök fő gyártói jelenleg a Compuware, Segue, Mercury Interactive, IBM/Rational, Borland. Mindegyikük számos automatizált tesztelőeszközt gyárt, beleértve a terhelési tesztelést, a felhasználói felület tesztelését, a végrehajtási hibák tesztelését.

A termék minőségének értékeléséhez a tesztelő eszközök mellett az alkalmazás forráskódjának elemzőit is gyakran használják az osztályhierarchia kialakításának, a kódírási stílusnak és a termék megvalósításának egyéb jellemzőinek helyességének meghatározására. Formában készíthetők egyedi alkalmazások vagy bekerülhet a szimulációs eszközökbe (különösen a Borland Together egyes kiadásaiba) vagy az alkalmazásfejlesztő eszközökbe.

Ha egy alkalmazást különböző operációs rendszereken és azok nyelvi verzióin (például a Microsoft Windows különböző 32 bites verzióin és kiadásain) futtatni kívánnak, akkor a tesztelők hasznosnak találhatják virtuális gépek, amely lehetővé teszi, hogy egyszerre több különböző operációs rendszert töltsön be egy számítógépre, és szervezze meg a köztük lévő hálózati interakciót (az ebbe a kategóriába tartozó termékekről külön cikkben fogunk beszélni). Az ebbe az osztályba tartozó szoftverek közül a Microsoft és a VMWare termékeit széles körben használják. Az alkalmazások telepítésére szolgáló programok tesztelésekor eszközök is használhatók Tartalékmásolat valamint a Symantec, a PowerQuest és mások által készített merevlemez-képek helyreállítása.

Dokumentáció

A projekt dokumentálását különböző szakemberek végzik. A felhasználói kézikönyvet általában egy műszaki író készíti, fő eszköze egy szövegszerkesztő és valami nem túl bonyolult grafikus feldolgozó eszköz, amellyel nyilakat, feliratokat és egyéb elemeket adhat hozzá a képernyőképekhez, amelyeket általában az ilyen képek illusztrációin ábrázolnak. dokumentumokat. A terméktanfolyamok és marketinganyagok íróinak hasonló eszközökre van szükségük, és olyan prezentációs eszközökre is szükségük lehet, mint a Microsoft PowerPoint.

A telepítési és karbantartási dokumentációt, valamint az egyéb műszaki dokumentumokat általában elemzők vagy telepítési szakemberek írják. Ebben az esetben a fentiek közül sokra szükségük lehet, például követelménykezelő eszközökre, adatmodellező eszközökre és UML modellező eszközökre – ezeknek a dokumentumoknak gyakran jelentős része modelljelentésekből áll. Ugyanakkor minél pontosabban végezték el a munkát a modellen, annál könnyebb volt a projektdokumentáció elkészítése.

A súgófájlokat általában a felhasználói kézikönyvből állítják elő speciális eszközök segítségével. A legegyszerűbb esetben a Microsoft Word és a Microsoft segédprogramjai segítségével súgófájl készíthető, amely számos fejlesztőeszközhöz tartozik, de nagy térfogatú a munka gyakran olyan cégek speciális eszközeit használja, mint a Blue Sky Software, az EC Software, a JGsoft.

Megvalósítás és támogatás

Egy termék bevezetése előtt általában terjesztési alkalmazásokat készítenek, hogy megkönnyítsék ezt a folyamatot – ezeket akkor indítjuk el, amikor egy adott terméket telepítünk számítógépre. A disztribúciós alkalmazások létrehozásához speciális eszközöket is használnak, amelyek piacvezetői az InstallShield Software és a Wise Solutions. A fejlesztőeszközök gyakran tartalmazzák ezeknek a termékeknek speciális verzióit, figyelembe véve azok sajátosságait (például a terjesztési csomagban található könyvtárak felvételének képességét). ezt az eszközt fejlesztés).

A termékkarbantartás szakaszában, amint azt a gyakorlat mutatja, mindenre szüksége lehet, ami a projekten végzett munka során készült, és ennek megfelelően bármely eszközre.

Csapatfejlesztés és projektmenedzsment

Ha egynél több személy dolgozik a projekt bármely részén, a verziókezelő eszközök (amelyek közül a legnépszerűbbek a Merant PVCS Version Manager és a Microsoft Visual SourceSafe) hasznosak lehetnek a fejlesztés során. Gyakran nem csak alkalmazáskód, hanem dokumentumok (például műszaki leírások) vagy modellek létrehozásakor is használják őket. A nagy projektek gyakran alkalmaznak változáskezelési eszközöket. Hasonló termékek lehetővé teszi a projekt összes összetevőjének és azok verzióinak egyetlen adatbázisban történő tárolását, és egyszerűsíti a kódok, modellek, követelmények verzióinak kezelését, valamint lehetővé teszi a projekt egyik részének változásainak a másikra gyakorolt ​​hatásának nyomon követését. alkatrészek. Napjaink legnépszerűbb változáskezelési eszközei közül a Borland és az IBM / Rational termékeit érdemes megemlíteni.

Egyetlen projekt sem nélkülözheti az érte felelős személyt, aki minden szakember tevékenységét megtervezi és minden fejlesztési folyamatot irányít. Bár papíron is meg lehet tervezni a munkát, de a közelmúltban a projektmenedzser (és nagy projekteknél - a projekt alkotórészeiért felelős vezetők) fő eszköze valamilyen speciális projektmenedzsment eszköz. Ebben a kategóriában a termékek között vezető szerepet tölt be a Microsoft Project termékcsalád.

Minta szoftverfejlesztési projektterv (Microsoft Project)

Következtetés

felsorolva azokat az eszközöket, amelyekre az alkalmazások fejlesztése során szükség lehet, természetesen nem neveztünk meg mindent lehetséges opciók. Egyes projektek jelentéskészítőket, mások grafikus eszközöket, megint mások webtervező eszközöket, mások pedig CAD vagy GIS eszközöket igényelhetnek. Ugyanakkor, mint láttuk, a legegyszerűbb esetekben meg lehet boldogulni egy fejlesztőeszközzel és egy szövegszerkesztővel - ez a készlet elég hatékony lehet, ha nem túl nagy a projekt.

Valójában az összes többi, ebben a cikkben felsorolt ​​eszközkategóriát nem feltétlenül kell használni az alkalmazások fejlesztése során. A gyakorlat azonban azt mutatja, hogy sokkal könnyebb velük dolgozni.

1. szakasz: az 50-es évek közepéig.

A fő költségek a kódoláshoz kapcsolódnak (gépi kódokban). Megjelennek az automatikus kódok (a parancsokhoz mnemonikus jelölést használó nyelvek) és az ezekből származó fordítók (összeszerelők).

A programok külön összeállításának, hordozhatóságának lehetőségei megvalósulnak. Programbetöltők és linkerek jelennek meg.

2. szakasz: 50-es évek közepe – 60-as évek közepe

A programok mérete nő, szakadék tárul fel a problématerületek és a géporientált nyelvek fogalmai között. Különféle nyelvek jelennek meg magas szint(algoritmikus, univerzális):

Fortran (1954-1957);

Algol-60 (1958-1960);

Cobol (1959-1961);

és tőlük fordítók (összeállítók). Szinte az összes alapvető adattípust, a rajtuk végzett műveleteket, a vezérlési struktúrákat és a programokban való megjelenítési módokat, az alprogramok paraméterezésének különféle lehetőségeit kitalálják és tesztelik.

3. szakasz: 60-as évek közepe – 70-es évek eleje.

A szoftver mérete meredeken növekszik, átmenet van a munka kollektív jellegére. A szoftverrel szemben támasztott követelmények az árutermelésre való áttérés következtében nőnek.

Változik a szoftverfejlesztési költségek aránya (40%-ot vagy még többet költenek hibakeresésre, tervezésre és dokumentációra), a kódolás az egyik legkönnyebb munkatípus. "Nagy" programozási nyelveket használnak és hoznak létre - PL/1, ALGOL-68, SIMULA-67, általánosítva és integrálva a korábban talált megoldásokat.

Vannak fejlett programozási rendszerek optimalizáló és hibakereső fordítókkal, makrókönyvtárak, könyvtárak szabványos programok, speciális szövegszerkesztők, elemző eszközök és interaktív hibakeresés a beviteli nyelv tekintetében. Kifejlesztett operációs rendszerek, az első DBMS, számos dokumentációs automatizálási rendszer, szoftverkonfiguráció-kezelő rendszer (követő módosítások és épületszoftver verziók) fejlesztés alatt áll.

4. szakasz („szoftverfejlesztési válságszakasz”): 1970-es évek eleje – 1970-es évek közepe

Az eszközök fejlesztése ellenére a programozók termelékenysége nem növekszik. Ráadásul a szoftverrel szembeni növekvő igények és összetettségének nem lineáris növekedése miatt a munkatermelékenység csökken. A szoftverfejlesztés feltételei törtek, költsége nő, minősége kiszámíthatatlan, a hagyományos (többlet humán és anyagi erőforrást biztosító) módszerek nem működnek, amit "szoftverválságként" jellemeznek.

Szerezzen módszertani elismerést strukturált programozás(Dijkstra, 1968), a programozási technológia alapjai kialakulóban vannak (Pascal nyelv (N. Wirth), 1971).

5. szakasz: 1976 – a mi időnk. Az eszközök válság utáni fejlesztésének szakasza.

1976 – Boehm művének publikálása, ahol a koncepciót bemutatják életciklus szoftvert, és jelezték, hogy a fő költségek nem a fejlesztésre, hanem a programok karbantartására vonatkoznak.

Programozási nyelvek:

C (1970-es évek eleje, először 1978-ban írták le teljes mértékben);

Modula-2 (1978, fejlesztette Oberon nyelv (1988));

Prolog (1972, 1980 óta terjed);

Smalltalk (1970-es évek, Smalltalk-80 néven vezették be 1980-ban);

C++ (az 1980-as évek eleje, a név 1983, 1990 óta létezik a megszokott formában);

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

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

Integrált szoftverfejlesztő környezetek fejlesztése folyamatban van. A tervezés és programozás objektum-orientált megközelítése egyre nagyobb elismerést kap. Olyan programokat fejlesztenek, amelyek minden szakaszban támogatják a szoftverek létrehozását.

Ellenőrző kérdések:

1. Milyen tevékenységeket foglal magában egy szoftvertermék fejlesztése?

2. Melyek a Rational Unified Process (RUP) szoftverfejlesztés szakaszai?

3. Mit nyújt az eszközhasználat?

4. Melyek a program összetevői? Az egyes részek célja.

5. Program- és szoftverdefiníciók.

6. Milyen tulajdonságokkal kell rendelkeznie a szoftvernek?

7. Milyen programozási nyelveket használnak a programok fejlesztése során?

8. A szerszámszoftver meghatározása.

9. Milyen négy csoportra oszthatók a szerszámszoftverek? Szoftverpéldák minden csoporthoz.

10. Milyen szempontok alapján hasonlíthatók össze az azonos osztályba tartozó programok?

11. Melyek a szoftverfejlesztő eszközök fejlesztésének szakaszai?

12. A fordítók (assembler) és linkszerkesztők célja és főbb jellemzői.

13. Szövegszerkesztők kinevezése és főbb jellemzői.

14. A hibakeresők célja és főbb jellemzői.

15. A telepítők létrehozására szolgáló programok célja és főbb jellemzői.

16. A forrásszerkesztők célja és főbb jellemzői.

17. A profilkészítők célja és főbb jellemzői.

18. A verziótámogató programok célja és főbb jellemzői.

19. Súgó fájlok (dokumentáció) készítésére szolgáló programok célja és főbb jellemzői.

20. A dokumentációs generátorok célja és főbb jellemzői.

21. A disassembler és decompiler célja és főbb jellemzői.

22. A rendszer tevékenységének és a rendszerben bekövetkező változások nyomon követésére szolgáló programok célja és főbb jellemzői.

23. A programok-hitelesítők és konténerek célja, főbb jellemzői.

24. A kifejlesztett szoftverek (védők) védelmét szolgáló programok célja és főbb jellemzői.

25. Az SDK célja és főbb jellemzői.

26. Az elemzők célja és főbb jellemzői.

27. Technológiai szabványok kijelölése.

TANTÁRGY: Szoftverfejlesztési módszertanok.

Irodalom: 1. Zelkowitz M., Shaw A., Gannon J. A szoftverfejlesztés alapelvei.

2. Ghezzi K., Jazayeri M., Mandrioli D. A szoftverfejlesztés alapjai.

3. Kamaev V. A., Kosterin V. V. Programozási technológiák.

Vegye figyelembe a módszertan, a módszer és az eszközök fogalmát.

1. definíció: Módszer(a görög methodos szóból - kutatás vagy tudás, elmélet vagy tanítás módszere) - bármely tárgykörben valaminek a gyakorlati megvalósítására szolgáló módszer vagy módszerrendszer, a valóság gyakorlati vagy elméleti fejlesztésére szolgáló módszerek vagy műveletek összessége, adott problémák megoldásától függően.

A módszer magában foglalja felszerelés- amelyen keresztül az akciót végrehajtják és módokon- hogyan hajtják végre a műveletet.

2. definíció: Módszertan alapelvrendszer, valamint a szoftverfejlesztés stílusát meghatározó ötletek, fogalmak, módszerek, módszerek és eszközök összessége.

A módszertan egy szabvány megvalósítása. Maguk a szabványok csak arról beszélnek, aminek lennie kell, meghagyva a választás és az alkalmazkodás szabadságát.

A konkrét dolgokat a választott módszertanon keresztül valósítják meg. Ő határozza meg, hogy a fejlesztés hogyan valósul meg. Számos sikeres szoftverfejlesztési módszer létezik. A konkrét módszertan kiválasztása a csapat méretétől, a projekt sajátosságaitól és összetettségétől, a vállalati folyamatok stabilitásától és érettségétől, valamint az alkalmazottak személyes tulajdonságaitól függ.

A módszertanok képezik a szoftverfejlesztési menedzsment elmélet magját.

Az alkalmazott életciklus-modelltől függően a módszerek a következőkre oszlanak:

Vízesés (vízesés);

Iteratív (spirál).

Van egy általánosabb besorolás is:

Előrejelzés;

Adaptív.

Tervezett módszertanok a jövő részletes tervezésére összpontosítson. A tervezett feladatok és erőforrások a projekt teljes időtartamára ismertek. A csapat alig reagál az esetleges változásokra. A tervet a munka terjedelme és a meglévő követelmények alapján optimalizáljuk. A változó követelmények a terv és a projekt kialakításának jelentős változásához vezethetnek. Gyakran külön „változáskezelési” bizottságot állítanak fel annak biztosítására, hogy csak a legfontosabb követelményeket vegyék figyelembe a projektben.

Adaptív módszertanok a követelmények várható hiányosságának és folyamatos változásának leküzdésére irányulnak. A követelmények változásával a fejlesztőcsapat is változik. Az agilis fejlesztéssel foglalkozó csapat nehezen tudja megjósolni egy projekt jövőjét. Pontos terv csak a közeljövőre van. A távolabbi tervek csak a projektcélok, várható költségek és eredmények deklarációjaként léteznek.

Lépcsőzetes fejlesztés vagy vízesés modell - a szoftverfejlesztési folyamat modellje, amelyben a fejlesztési folyamat úgy néz ki, mint egy folyamat, amely egymás után halad át a követelményelemzés, a tervezés, a megvalósítás, a tesztelés, az integráció és a támogatás fázisain.

A kaszkád megközelítés fő jellemzője: a következő szakaszra való áttérés csak az aktuális szakasz munka teljes befejezése után történik, és nincs visszatérés az áthaladt szakaszokhoz . Minden szakasz bizonyos eredményekkel zárul, amelyek bemenetként szolgálnak a következő szakaszhoz (1. ábra).

Rizs. 1. Kaszkád életciklus modell.

Minden szakasz egy olyan dokumentációkészlet kiadásában ér véget, amely elegendő ahhoz, hogy a fejlesztést egy másik fejlesztőcsapat folytathassa. A fejlesztés minőségének kritériuma ennél a megközelítésnél a feladatmeghatározásban foglaltak teljesítésének pontossága.

A kaszkád módszer használatának előnyei:

Minden szakaszban egy teljes projektdokumentáció-készlet készül, amely megfelel a teljesség és a következetesség követelményeinek;

A logikai sorrendben elvégzett munkaszakaszok lehetővé teszik az összes munka befejezésének ütemezését és a kapcsolódó költségeket.

A kaszkád megközelítés jól bevált az elektronika felépítésében információs rendszerek, amelyre a fejlesztés legelején elég pontosan és maradéktalanul meg lehet fogalmazni az összes követelményt, hogy a fejlesztők szabadságot kapjanak, hogy azokat technikailag a lehető legjobban megvalósítsák.

Ugyanakkor ennek a megközelítésnek számos hátránya van, elsősorban abból a tényből adódóan valódi folyamat A szoftverfejlesztés soha nem illeszkedik teljesen egy ilyen merev mintába. A szoftverkészítés folyamata általában iteratív jellegű: a következő szakasz eredményei gyakran okoznak változást tervezési megoldások az előző szakaszokban keletkezett. Így folyamatosan szükség van a korábbi szakaszokhoz való visszatérésre és a korábban meghozott döntések pontosítására vagy felülvizsgálatára (2. ábra). Az ábrázolt séma egy külön modellhez köthető - a közbenső vezérlésű modellhez, amelyben a szakaszok közötti kiigazítások nagyobb megbízhatóságot biztosítanak a kaszkádmodellhez képest, bár növelik a teljes fejlesztési időszakot.

A vízesés-modell fő hátránya az eredmények megszerzésének jelentős késése, és ennek következtében nagy a kockázata egy olyan rendszer létrehozásának, amely nem felel meg a felhasználók változó igényeinek. Ennek két oka van:

A felhasználók nem tudják azonnal megfogalmazni minden igényüket, és nem látják előre, hogyan változnak a fejlesztés során;

A fejlesztés során a külső környezetben olyan változások következhetnek be, amelyek befolyásolják a rendszer követelményeit.

Rizs. 2. Kaszkád életciklus modell a gyakorlatban.

A kaszkád megközelítés keretében a fejlesztés alatt álló termékkel szemben támasztott követelményeket technikai feladat formájában rögzítik a létrehozásának teljes idejére, és a kapott eredményeket csak az egyes termékek elvégzése után tervezett pontokon egyeztetik a felhasználókkal. szakaszban (lehetőség van az eredmények módosítására a felhasználók észrevételei szerint, ha azok nem érintik a feladatmeghatározásban meghatározott követelményeket). Így a felhasználók csak a rendszeren végzett munka teljes befejezése után tehetnek jelentős megjegyzéseket. A felhasználók olyan rendszert kaphatnak, amely nem felel meg az igényeiknek. Ennek eredményeként új projektet kell indítania, amely ugyanerre a sorsra juthat.

E problémák leküzdésére az 1980-as évek közepén egy spirális életciklus modellt javasoltak (3. ábra).

Rizs. 3. Spirális (iteratív) életciklus modell.

Fő jellemzője a következő: Az alkalmazásszoftver nem azonnal készül el, mint a vízesés-megközelítés esetén, hanem részenként prototípuskészítési módszerrel .

Alatt prototípus Olyan aktív szoftverkomponensre utal, amely a fejlesztés alatt álló szoftver egyes funkcióit és külső interfészeit valósítja meg. A prototípusok létrehozása több iterációban vagy spirálfordulatban történik. Minden iteráció megfelel a szoftver egy töredékének vagy verziójának létrehozásának, amelynél meghatározzák a projekt céljait és jellemzőit, értékelik a kapott eredmények minőségét, és megtervezik a következő iteráció munkáját. Minden iterációnál gondosan felmérik a projekt időtartamának és költségének túllépésének kockázatát, hogy megállapítsák, szükség van-e újabb iterációra, milyen a teljesség és a pontosság a rendszerkövetelmények megértésében, és hogy a projektet le kell-e fejezni.

A spirálmodell mentesíti a felhasználókat és a fejlesztőket attól, hogy a kezdeti szakaszban pontosan és teljes körűen megfogalmazzák a rendszerkövetelményeket, mivel azokat minden iterációnál finomítják. Így a projekt részletei elmélyülnek és következetesen konkretizálódnak, és ennek eredményeként egy ésszerű opció kerül kiválasztásra, amely megvalósul.

A spirálmodell az evolúciós tervezési stratégia klasszikus példája. A spirálmodell (Barry Boehm, 1988) azon alapul legjobb tulajdonságait klasszikus életciklus és elrendezés, amelyhez hozzáadódik új elem- korábban nem elérhető kockázatelemzés.

A Spirálmodell négy tevékenységet határoz meg, amelyeket a spirál egyes szektorai képviselnek:

1. Tervezés - célok, lehetőségek és korlátok meghatározása.

2. Kockázatelemzés - opciók elemzése és kockázatfelismerés/kiválasztás.

3. Mérnökség – következő szintű termékfejlesztés.

4. Értékelés - az aktuális tervezési eredmények megrendelő általi értékelése.

A spirálmodell integráló aspektusa nyilvánvaló, ha figyelembe vesszük a spirál radiális dimenzióját. Minden egyes iterációval a spirál mentén (a középpontból a perifériára haladva) egyre több teljes verziókÁLTAL.

A spirál első fordulójában meghatározzák a kezdeti célokat, lehetőségeket és korlátokat, valamint felismerik és elemzik a kockázatot. Ha a kockázatelemzés a követelmények bizonytalanságát mutatja, akkor a prototípuskészítés (a tervezési kvadránsban) jön a fejlesztő és a megrendelő segítségére. A modellezés felhasználható a problémás és finomított követelmények további azonosítására. A megrendelő értékeli a mérnöki (tervezői) munkát és javaslatot tesz a módosításokra. A tervezés és a kockázatelemzés következő fázisa az ügyfelek javaslataira épül. A spirál minden egyes ciklusában a kockázatelemzés eredményei a "folytassa, ne folytassák" formában alakulnak ki. Ha a kockázat túl nagy, a projekt leállítható.

A legtöbb esetben a spirál folytatódik, és minden lépéssel a fejlesztőket többre vezetik általános modell rendszerek.

Az iteratív módszerrel a hiányzó munka a következő iterációban elvégezhető. A fő feladat az, hogy a rendszer felhasználóinak mielőbb működőképes terméket mutassunk meg, ezzel aktiválva a követelmények tisztázását, kiegészítését.

A spirálmodell nem zárja ki a kaszkád megközelítést a projekt végső szakaszában azokban az esetekben, amikor a rendszer követelményei teljesen meghatározottak.

A spirálciklus fő problémája a következő szakaszba való átmenet pillanatának meghatározása. Megoldásához időkorlátokat kell bevezetni az életciklus egyes szakaszaira. Az átállás a terveknek megfelelően halad, még akkor is, ha nem fejeződik be minden tervezett munka. A terv a korábbi projektekből nyert statisztikai adatok és a fejlesztők személyes tapasztalatai alapján készül.

A spirálmodell előnyei:

A legreálisabb (az evolúció formájában) a szoftverfejlesztést tükrözi;

Lehetővé teszi, hogy kifejezetten figyelembe vegye a kockázatot a fejlesztés fejlődésének minden szakaszában;

A szisztematikus megközelítési lépést beépíti az iteratív fejlesztési struktúrába;

Szimulációt használ a kockázat csökkentése és a szoftvertermék fejlesztése érdekében.

A spirálmodell hátrányai:

Újdonság (nincs elegendő statisztika a modell hatékonyságáról);

Megnövekedett követelmények a vevővel szemben;

Nehézségek a fejlesztési idő nyomon követésében és kezelésében.

A mai napig a következő iteratív szoftverfejlesztési módszerek különböztethetők meg:

Rational Unified Process (RUP)

Rugalmas fejlesztési módszerek (SCRUM, KANBAN, DSDM, MSF, ALM, XP)

Agilis fejlesztési módszertan(Eng. Agilis szoftverfejlesztés).

A legtöbb agilis módszertan célja a kockázat minimalizálása azáltal, hogy a fejlesztést rövid ciklusok sorozatára csökkenti iterációk amelyek általában egy-két hétig tartanak. Minden iteráció úgy néz ki, mint egy miniatűr szoftverprojekt, és magában foglalja az összes olyan feladatot, amely a funkcionalitás mini-növekedéséhez szükséges: tervezés, követelményelemzés, tervezés, kódolás, tesztelés és dokumentáció. Bár egyetlen iteráció általában nem elég a kiadáshoz új verzió termék esetében feltételezzük, hogy az Agile Software Project minden iteráció végén készen áll a kiadásra. Minden iteráció végén a csapat újraértékeli a fejlesztési prioritásokat.

Az agilis módszerek a szemtől szembeni kommunikációt hangsúlyozzák. A legtöbb agilis csapat ugyanabban az irodában található. Legalább a "vevőket" (a terméket meghatározó ügyfeleket, például termékmenedzsereket, üzleti elemzőket vagy ügyfeleket) is magában foglalja. Az irodában tesztelők, felülettervezők, műszaki írók és vezetők is lehetnek.

Az egyik legismertebb és legfejlettebb agilis módszertan a SCRUM módszertan.

DULAKODÁS- kis csapatok (maximum 10 fő) számára kialakított módszertan. A teljes projekt iterációkra (sprintekre) van felosztva, amelyek mindegyike 30 napig tart. A rendszer kijelöli azon rendszerfunkciók listáját, amelyeket a következő sprint során terveznek megvalósítani. A legfontosabb feltétel a kiválasztott függvények változatlansága egy iteráció végrehajtása során, és a következő kiadás megjelenési dátumainak szigorú betartása, még akkor is, ha annak kiadásával nem lehet az összes tervezett funkcionalitást megvalósítani. A fejlesztési vezető napi 20 perces megbeszéléseket tart, melyeket scrumnak neveznek, melynek eredménye az előző napon megvalósított rendszerfunkció meghatározása, a felmerülő nehézségek és a következő napi terv. Az ilyen találkozók lehetővé teszik a projekt előrehaladásának folyamatos nyomon követését, a felmerült problémák gyors azonosítását és gyors reagálását.

KANBAN– feladatorientált agilis szoftverfejlesztési módszertan.

Alapszabályok:

Fejlesztési vizualizáció:

o a munka feladatokra való felosztása;

o érdemjegyek használata a feladat fejlesztési pozíciójáról;

Az egyidejűleg végzett munka korlátozása a fejlesztés minden szakaszában;

Ciklusidő mérés (átlagos idő egy feladat elvégzéséhez) és folyamatoptimalizálás.

A KANBAN előnyei:

A párhuzamos feladatok számának csökkentése jelentősen csökkenti az egyes feladatok végrehajtási idejét;

A problémás feladatok gyors azonosítása;

Számítsa ki az átlagos feladat elvégzéséhez szükséges időt!

DINAMIKUS RENDSZERFEJLESZTÉSI MÓDSZER(DSDM) egy 17 brit cégből álló konzorcium munkájának eredményeként jelent meg. Egy egész szervezet vesz részt e módszertan kézikönyveinek kidolgozásában, képzések szervezésében, akkreditációs programokban stb. Ezenkívül a DSDM értékének pénzben kifejezett értéke is van.

Minden a program megvalósíthatóságának és hatókörének tanulmányozásával kezdődik. Az első esetben azt próbálja kitalálni, hogy a DSDM megfelelő-e egy adott projekthez. A program hatókörét egy rövid szemináriumsorozaton kell tanulmányoznia, ahol a programozók megismerkedhetnek azzal az üzleti területtel, amelyen dolgozni fognak. A leendő rendszer architektúrájára és a projekttervre vonatkozó főbb rendelkezéseket is tárgyalja.

A folyamat további három, egymással összefüggő ciklusra oszlik: a funkcionális modell ciklus az analitikai dokumentáció és prototípusok létrehozásáért, a tervezési és kivitelezési ciklus a rendszer működőképes állapotba hozataláért, végül az utolsó ciklus - a megvalósítási ciklus - biztosítja a szoftverrendszer kiépítését.

A DSDM alapelvei a következők:

Aktív interakció a felhasználókkal;

Verziók gyakori kiadása;

A fejlesztők függetlensége a döntéshozatalban;

Tesztelés a teljes munkaciklus alatt.

A legtöbb más agilis módszerhez hasonlóan a DSDM is rövid, két-hat hetes iterációkat használ. Különös hangsúlyt kap jó minőség teljesítmény és alkalmazkodóképesség a változó követelményekhez.

MICROSOFT SOLUTIONS KERET(MSF) a Microsoft Corporation által javasolt szoftverfejlesztési módszertan. Az MSF a Microsoft legjobb gyakorlataira támaszkodik, és leírja, hogyan kezelik az embereket és a munkafolyamatokat a megoldásfejlesztési folyamat során.

Az MSF folyamatmodell alapelvei és alapelvei:

Egyetlen elképzelés a projektről – minden érdekelt félnek és csak a projekt résztvevőinek világosan meg kell érteniük a végeredményt, mindenkinek meg kell értenie a projekt célját;

Kompromisszumok menedzselése - kompromisszumok megtalálása a projekt erőforrásai, ütemezése és a megvalósítható lehetőségek között;

Rugalmasság - készenlét a változó tervezési feltételekre;

Összpontosítson az üzleti prioritásokra - összpontosítson a megtérülésre és az előnyökre, amelyeket a megoldás fogyasztója elvár;

A projekten belüli szabad kommunikáció ösztönzése;

Teremtés alap verziók- bármely projektműtermék állapotának rögzítése, beleértve a programkódot, a projekttervet, a felhasználói kézikönyvet, a szerverbeállításokat és az ezt követő hatékony változáskezelést, projektelemzést.

Az MSF bevált módszertanokat kínál a sikeres informatikai megoldások tervezéséhez, tervezéséhez, fejlesztéséhez és megvalósításához. Rugalmasságával, méretezhetőségével és a merev irányelvek hiányával az MSF bármilyen méretű szervezet vagy projektcsapat igényeit képes kielégíteni. Az MSF módszertana alapelvekből, modellekből és diszciplínákból áll a személyzet, a folyamatok, a technológiai elemek és az ezekkel a tényezőkkel kapcsolatos kérdések kezelésére, amelyek a legtöbb projektre jellemzőek.

Alkalmazás életciklus-kezelés(ALM) - a Borland fejlesztette és karbantartja.

extrém programozás(XP) - extrém programozás, amelyet független fejlesztők nyílt közössége támogat.

Tárgy: Szoftverfejlesztési technológia.

Téma: Együttműködő szoftverfejlesztő eszközök.

nevelési

Ismerkedés a kollektív szoftverfejlesztés eszközeivel.

Fejlesztés:

Fejlessze mások meghallgatásának, következtetések levonásának és a megszerzett ismeretek általánosításának képességét

Nevelési:

Nevelje a tárgy fontosságának érzését a szakmai tevékenységben, a pontosságot a munkában

Interdiszciplináris kapcsolatok:

angol nyelv

OS

Információs technológia

Az algoritmizálás és programozás alapjai

Felszerelés: tábla, kréta, íróeszközök, projektor, PC

Az óra típusa: kombinált

Oktatási módszer: magyarázó szemléltető

Az órák alatt:

1. Szervezési mozzanat

A szekrény készenlétének ellenőrzése

Témahirdetés

2. Az óra céljának kitűzése

3.A lefedett anyag ismétlése

Szoftverfejlesztő eszközök.

Szoftvereszközök fejlesztésére és karbantartására szolgáló eszközkörnyezetek és osztályozásuk elvei

Az eszközfejlesztő környezetek és a szoftverkarbantartás főbb osztályai

Programozási környezetek

4. Új ismeretek közlése

A számítógépes szoftverfejlesztési technológia fogalma és feladatai

Programozási technológiai eszközrendszerek

Szoftverfejlesztő eszközök

5. A tanulók új tananyag észlelése és tudatossága

6. Szövegértés általánosítása, ismeretek rendszerezése

7. Az óra összegzése és a házi feladat felállítása

Ismerje meg a téma tartalmát

Gagarina L.G. 257-259.

Válaszolj a kérdésekre:

16.4. A számítógépes szoftverfejlesztési technológia fogalma és feladatai

Vannak bizonyos nehézségek a CASE-technológia (a PS fejlesztésére szolgáló számítógépes technológia) szigorú meghatározásának kidolgozása során. A CASE a Computer-Aided Software Engineering (Computer-Assisted Programming Engineering) rövidítése. De számítógép segítsége (támogatása) nélkül már régóta nem fejlesztenek PS-eket (legalább fordítóprogramot használnak). Valójában egy szűkebb (speciális) jelentést helyeznek ebbe a fogalomba, amely fokozatosan elmosódik (mint ez mindig megtörténik, ha egy fogalomnak nincs szigorú definíciója). A CASE kezdetben a szoftverfejlesztés korai szakaszainak tervezése (követelmények meghatározása, a szoftver külső leírásának és architektúrájának kidolgozása) szoftvertámogatás (szoftvereszközök) segítségével. A CASE ma már a szoftver teljes életciklusának tervezéseként is felfogható (beleértve a karbantartást is), de csak abban az esetben, ha a programok részben vagy teljesen a fejlesztés jelzett korai szakaszában beszerzett dokumentumok alapján generálódnak. Ebben az esetben a CASE-technológia alapvetően eltér a szoftverfejlesztés manuális (hagyományos) technológiájától: nemcsak a technológiai folyamatok tartalma változott meg, hanem azok összessége is.

Jelenleg számítógépes technológia A PS fejlesztés a felhasználással jellemezhető

• szoftvertámogatás a PS grafikus követelményeinek és grafikus specifikációinak fejlesztéséhez,
• programok automatikus generálása bármilyen programozási nyelven vagy gépi kódban (részben vagy teljesen),
• szoftver támogatás a prototípus elkészítéséhez.

Azt is mondják, hogy a PS fejlesztésének számítástechnikája "papírmentes", azaz "papírmentes". programdokumentumok számítógépes ábrázolására tervezték. A manuális szoftverfejlesztési technológiát azonban meglehetősen nehéz magabiztosan megkülönböztetni az e tulajdonságokon alapuló számítógépes technológiától. Ez azt jelenti, hogy a számítástechnikában a leglényegesebbet nem emelték ki.

Véleményünk szerint a fő különbség a manuális szoftverfejlesztési technológia és a számítástechnika között a következő. A manuális technológia a különböző PS-fejlesztők által egyformán érthető dokumentumok fejlesztésére összpontosít, míg a számítástechnika a dokumentumok szemantikai megértésére (értelmezésére) összpontosít a számítógépes technológia szoftveres támogatásával. A dokumentumok szemantikai megértése lehetővé teszi a szoftvertámogatás számára, hogy automatikusan generáljon programokat. Ebben a tekintetben a számítástechnika elengedhetetlen része a formális nyelvek használata már a szoftverfejlesztés korai szakaszában: mind a programok specifikálásához, mind más dokumentumok specifikálásához. Különösen a formális grafikus specifikációs nyelveket használják széles körben. Ez teszi lehetővé a szoftverfejlesztés és -karbantartás technológiai folyamatainak racionális megváltoztatását.

A megbeszélésből megállapítható szoftverfejlesztés számítástechnika mint programozási technológia, amely szoftvereszközöket használ a programok és egyéb dokumentumok (beleértve a grafikus specifikációkat) formalizált specifikációinak kidolgozására, majd a programok és dokumentumok (vagy legalábbis jelentős részük) automatikus generálására ezen előírásoknak megfelelően.

Most világossá váltak a számítástechnika szoftveréletciklusának főbb változásai. Ha a manuális technológia használatakor a PS fejlesztésének fő erőfeszítései a programozás (kódolás) és a hibakeresés (tesztelés) szakaszában történtek, akkor a számítástechnika használatakor a PS fejlesztésének korai szakaszában (követelmények meghatározása, ill. funkcionális specifikációk, architektúra kidolgozása). Ugyanakkor a dokumentáció jellege jelentősen megváltozott. Az informális dokumentumok egész láncolata helyett, amely az ügyfelektől (felhasználóktól) a fejlesztők különböző kategóriáihoz történő információtovábbításra összpontosít, egy PS prototípus jön létre, amely támogatja a kiválasztott felhasználói felületet, és elegendő a formális funkcionális specifikációk (néha formális PS architektúra specifikációk) is. a PS programok (vagy legalábbis jelentős részük) automatikus szintéziséhez (generálásához). Ezzel párhuzamosan lehetővé vált a fejlesztők és felhasználók számára szükséges dokumentáció egy részének automatikus előállítása. A kézi programozás (kódolás) helyett - automatikus programok generálása, ami szükségtelenné teszi a programok független hibakeresését és tesztelését: helyette a dokumentáció meglehetősen mély automatikus szemantikai vezérlése kerül hozzáadásra. Lehetővé válik a tesztek automatikus generálása a formális specifikációk szerint egy komplex ( szisztémás) PS hibakeresés. A PS karbantartás jellege is jelentősen megváltozik: minden változtatást a karbantartó csak a specifikációkon hajt végre (beleértve a prototípust is), a PS egyéb módosításai automatikusan.

Ezzel mondva szoftver életciklusa a számítástechnika számára a következő diagrammal ábrázolható (16.3. ábra).

Rizs. 16.3. Egy számítástechnikai szoftvereszköz életciklusa.

prototípus elkészítése PS a PS életciklusának opcionális szakasza számítógépes technológiával, amely az ábrán látható. A 16.3-at pontozott nyíl mutatja. Ennek a lépésnek a használata azonban sok esetben és ennek a lépésnek megfelelő számítógépes támogatása jellemző a számítástechnikára. Egyes esetekben a prototípuskészítés a specifikációk kidolgozása után (vagy közben) történik. PS például a felhasználói felület prototípus készítése esetén. Ez az ábrán látható. 16.3 pontozott vissza nyíl. Bár bármely szakaszban megengedjük a visszatérést az előző szakaszokhoz, de itt ez kifejezetten megmutatkozik, hiszen a prototípuskészítés a PS fejlesztésének speciális megközelítése (lásd 3. előadás). A felhasználói felület prototípusa lehetővé teszi, hogy a felhasználó és a PS közötti interakció közvetett leírását a manuális technológiában (a PS külső leírásának kidolgozásakor) helyettesítse a felhasználó által az interakció módszerének és stílusának közvetlen megválasztásával, rögzítve az összes szükséges részletek. Lényegében ebben a szakaszban készül el a felhasználói felület pontos, a számítástechnika szoftveres támogatásával érthető leírása, a felhasználó felelősségteljes közreműködésével. Mindez azon alapul, hogy a számítógépes technológia szoftvertámogatásában egy testreszabható héj található, amely a különféle töredékek és képernyőrészletek széles tárházával rendelkezik. Úgy tűnik, hogy ez a fajta prototípus a legjobb módja annak, hogy áthidalja a felhasználó és a fejlesztő közötti akadályt.

PS specifikációk kidolgozása több különböző folyamatra bomlik. Ha kizárjuk a specifikációk kidolgozásának kezdeti szakaszát (követelmények meghatározása), akkor ezek a folyamatok olyan módszereket használnak, amelyek formalizált dokumentumok létrehozásához vezetnek, azaz formalizált specifikációs nyelveket használnak. Ugyanakkor széles körben használják a specifikációk grafikus módszereit, amelyek különféle sémák és diagramok létrehozásához vezetnek, amelyek meghatározzák az információs környezet szerkezetét és a PS kezelési struktúráját. Az ilyen struktúrákhoz adattöredékek és programleírások kapcsolódnak, amelyeket algebrai specifikációs nyelveken (például operatív vagy axiomatikus szemantika használatával), vagy logikai specifikációs nyelveken (a programspecifikáció logikai megközelítésén alapuló) mutatnak be. Az ilyen specifikációk lehetővé teszik a programok nagyrészt vagy teljesen automatikus létrehozását. A specifikációfejlesztés lényeges része a specifikációkban használt elnevezett entitások szótárának elkészítése.

Automatikus specifikáció vezérlés PS használja azt a tényt, hogy a specifikációk jelentős része formális nyelveken jelenik meg. Ez lehetővé teszi különféle típusú vezérlések automatikus végrehajtását: a specifikációk szintaktikai és részleges szemantikai vezérlése, a sémák és diagramok teljességének és konzisztenciájának ellenőrzése (különösen minden elemüket azonosítani kell és tükrözni kell a megnevezett entitások szótárában), vége - a specifikációs szintek egyensúlyának végpontig történő vezérlése és más típusú vezérlések a specifikációs nyelvek képességeitől függően.

Generáció programokat PS. Ebben a szakaszban automatikusan kódvázakat generál a PS-programokhoz, vagy teljesen kódokat állít elő ezekhez a programokhoz a formális PS-specifikációk szerint.

A PS automatizált dokumentációja. Feltételezi a különböző formájú dokumentumok generálásának lehetőségét azok részleges kitöltésével az adattárban tárolt információk szerint. Ugyanakkor a hagyományos technológiához képest csökken a dokumentumtípusok száma.

A PS átfogó tesztelése és hibakeresése. Ebben a szakaszban minden PS specifikációt tesztelnek, és az ezalatt talált hibákat kijavítják. A tesztek manuálisan és automatikusan is létrehozhatók (ha a használt specifikációs nyelvek ezt lehetővé teszik), és a generált PS programokon keresztül továbbíthatók.

PS minősítésazonos tartalommal rendelkezik.

PS támogatás nagymértékben leegyszerűsödik, mivel a főbb változtatásokat csak a specifikációkban hajtják végre.

Szoftverfejlesztés számítástechnikai munkahelye egy olyan eszközkörnyezet, amely támogatja a technológia életciklusának minden szakaszát. Ez a környezet jelentős mértékben kihasználja az adattárat. A repository tárolja a PS fejlesztése során keletkezett összes információt (különösen a megnevezett entitások szótárát és az összes specifikációt). Mint ilyen, a számítástechnikai munkahely integrált, legalábbis a felhasználói felület és az adatok tekintetében. Egy ilyen munkahely fő eszközei a következők:

• felhasználói felület tervezők;
• eszköz a megnevezett entitások szótárával való munkához;
• specifikációk grafikus és tesztszerkesztői;
• specifikációelemzők;
• programgenerátor;
• dokumentálók.

14.5. Programozási technológiai eszközrendszerek

Programozástechnikai eszközrendszer szoftver és hardver eszközök integrált készlete, amely támogatja a nagy PS fejlesztési és karbantartási folyamatait annak teljes életciklusa során, egy bizonyos technológián belül. Fentebb már jeleztük (lásd a 14.3. pontot), hogy az integráltság mellett a komplexitás és a kollektív fejlesztésre összpontosító tulajdonságokkal is rendelkezik. Ez azt jelenti, hogy a technológiai folyamatok termékeinek konzisztenciáján alapul. Így a műszerrendszer képes legalább ellenőrzést biztosítani az elkészített dokumentáció (beleértve a programkészletet) teljessége (teljessége), változtatásának (verziójának) következetessége. A PS karbantartási szakaszának a műszeres rendszer általi támogatása azt jelenti, hogy biztosítania kell PS konfigurációkezelés. Ezen túlmenően a műszeres rendszer támogatja a csapat munkájának irányítását, és ennek a csapatnak a különböző tagjai számára különböző hozzáférési jogokat biztosít a technológiai folyamatok előállításának különböző töredékeihez, és támogatja a munkát. vezetők fejlesztői csapat irányításához. A programozási technológiai eszközrendszerek elég nagy és költséges szoftverrendszerek ahhoz, hogy valamilyen módon igazolják az eszközök túlterheltségét. Ezért a bennük található eszközkészletet gondosan választják ki, figyelembe véve a tantárgyi terület igényeit, a használt nyelveket és a választott programozási technológiát.

Figyelembe véve a programozástechnikai műszerrendszerek tárgyalt tulajdonságait, három fő összetevőjük különíthető el:

• adattár,
• szerszámok,
• interfészek.

Eszközök- olyan eszközkészlet, amely meghatározza a rendszer által a fejlesztőcsapat számára biztosított képességeket. Általában ez a készlet nyitott és strukturált. A minimális készleten kívül ( beépített eszközök), tartalmazza a kiterjesztésének eszközeit ( importált műszerek). Ezenkívül a műveletek feletti integráció miatt az összes eszköz közös részéből áll ( magok) és strukturális (olykor hierarchikusan összefüggő) eszközosztályok.

Interfészekfelhasználóra és rendszerre osztva. Egyedi A felület hozzáférést biztosít a fejlesztőknek az eszközkészlethez. Megvalósul héj rendszerek. Szisztémás Az interfészek interakciót biztosítanak az eszközök és közös részeik között. A rendszer interfészek a rendszer nyitottsága miatt architekturális komponensként tűnnek ki – ezeket új ( importált) a rendszerben található eszközök.

A programozástechnikai műszerrendszerek legáltalánosabb architektúráját az ábra mutatja. 16.4.

Rizs. 16.4. Programozástechnikai műszerrendszerek általános felépítése.

A programozási technológiai eszközrendszereknek két osztálya van: projekttámogató eszközrendszerek és nyelvfüggő eszközrendszerek.

Projekttámogató eszközrendszer - ez egy nyílt rendszer, amely a kiválasztott nyelvre orientált szoftvereszközökkel történő megfelelő kiterjesztés után támogatja a PS fejlesztését különböző programozási nyelveken. Egy ilyen rendszer eszközkészlete támogatja a PS fejlesztését, emellett a programozási nyelvtől független eszközöket is tartalmaz, amelyek támogatják a PS fejlesztését (szöveges ill. grafikus szerkesztő, jelentéskészítők stb.). Ezen kívül rendszerbővítő eszközöket is tartalmaz. Egy ilyen rendszer magja különösen hozzáférést biztosít az adattárhoz.

Nyelvfüggő eszközrendszer - ez egy szoftverfejlesztést támogató rendszer bármely programozási nyelven, amely lényegében ennek a nyelvnek a sajátosságait használja fel munkája szervezésében. Ez a sajátosság hatással lehet mind a kernel képességeire (beleértve a tároló szerkezetét), mind a shell és az eszközök követelményeire. Ilyen rendszer például az Ada Programing Support Environment (APSE).

7.1. Szoftverfejlesztő eszközök

Szerszámszoftver (Szoftvereszközök) - egyéb programok fejlesztése, javítása vagy fejlesztése során használt szoftverek:

szerkesztők, fordítók, hibakeresők, segédrendszer programok, grafikus csomagok stb.

Ide tartoznak a programozási nyelvek, az integrált programfejlesztő környezetek, a CASE rendszerek stb.

7.1.2. Programozási nyelv kiválasztása

A jelenleg létező programozási nyelvek a következő csoportokra oszthatók:

Univerzális magas szintű nyelvek;

Speciális szoftverfejlesztői nyelvek;

Speciális felhasználói nyelvek;

Nyelvek alacsony szint.

Az univerzális magas szintű nyelvek csoportjában ma vitathatatlanul vezető szerepet tölt be a C ++ nyelv. Valójában számos előnye van:

Méretezhetőség. A C++ nyelven a programokat a legkülönfélébb platformokra és rendszerekre fejlesztik;

Alacsony szintű munkavégzés képessége memóriával, címekkel, portokkal, ami gondatlan használat esetén könnyen hátrányba kerülhet;

A C++-nak van egy erős előfeldolgozója, amelyet a C-ből örököltek, de mint minden más hatékony eszközt, ezt is óvatosan kell használni;

Lehetőség általánosított algoritmusok létrehozására különböző típusok adatok, azok specializációja és számításai az összeállítási szakaszban sablonok segítségével.

Ugyanakkor a C++ nyelvnek számos jelentős hátránya van:

Egy külső modul interfészének összekapcsolása egy fejlécfájl előfeldolgozói beszúrásával (#include) jelentősen lelassítja a fordítást, ha nagyszámú modult tartalmaz;

Az adattípusra vonatkozó információk hiánya a fordítási időben;

Tanulási és összeállítási nehézségek;

Egyes típuskonverziók nem intuitívak. Különösen az előjel nélküli és előjeles számokkal végzett művelet ad előjel nélküli eredményt.

A C++ esetében számos osztálykönyvtár létezik, amelyek támogatják a felhasználói felület létrehozását, a kliens-szerver alkalmazásokat, az adatbázisokkal való munkát stb.

így egyelőre nincs alternatíva a C++-nak. Másodlagos projektekhez néha Visual Basic-et használnak. A Java nyelvet a Basic alternatívájaként tekintették, de a vizualitás hiánya miatt

formák fejlesztésének eszköze, még mindig kevés haszna van.

A modern Object Pascal, mint Pascal, amelyet N. Wirth javasolt a XX. század 70-es éveinek közepén, továbbra is a legvonzóbb a programozás alapjainak oktatásában, köszönhetően

az egyszerűség, a strukturáltság és a fordító által nagyszámú nem csak szintaktikai, hanem szemantikai hiba észlelése.

Ma, az 1960-as évektől eltérően, programozási nyelveket ritkán hoznak létre. Az elmúlt 15 évben csak két újdonság figyelhető meg, amelyek széles körben elterjedtek - ez a Java (Sun Microsystems, 1995), amely nagyrészt az internetes felhasználás technológiája és egy olyan koncepció megjelenése miatt vált népszerűvé, mint pl. a Java virtuális gép és a C# (Microsoft, 2000), C++ alapú.

A nyelv megalkotója a Microsoft alkalmazottja, Andreas Hejlsberg. Jóval azelőtt vált híressé a programozók világában, hogy a Microsofthoz került volna. Hejlsberg az élen járt

az egyik legnépszerűbb fejlesztői környezet, a Delphi fejlesztői. A Microsoftnál ő segített az alkotásban Java verziók- J++, tehát nagy tapasztalattal rendelkezik a nyelvek írásában és a programozási környezetekben. Ahogy Andreas Hejlsberg maga is megjegyezte, a C# komponens programozási nyelvként jött létre, és ez a nyelv egyik fő előnye, amely a létrehozott komponensek újrafelhasználásának lehetőségét célozza.

A C# nyelv további előnyei:

Megőrzi a népszerű C/C++ programozási nyelvek legjobb tulajdonságait, amelyeken alapul. Ebben a tekintetben megkönnyítik a programozók átmenetét C ++-ról C #-re;

Egyszerűbb és megbízhatóbb, mint a C++. Az egyszerűség és a megbízhatóság elsősorban annak köszönhető, hogy a C#, bár megengedett, nem ösztönzi a C ++ ilyen veszélyes tulajdonságait,

mint a mutatók, a címzés, a hivatkozás megszüntetése, a címaritmetika;

Teljesen objektum-orientált nyelv, ahol még a nyelvbe épített típusokat is osztályok reprezentálják;

Megvalósítja az öröklési és univerzalizálási képességeket;

Figyelembe veszi a Framework .Net összes funkcióját, mivel a C# ezzel a környezettel párhuzamosan készült;

Az operációs rendszerre épülő .Net Framework segítségével a C# programozók ugyanazokat az előnyöket élvezhetik a virtuális gépekkel való munkavégzés során, mint

Java programozók. A kód hatékonysága még javult is, mivel a CLR futtatókörnyezete egy köztes nyelvi fordító, míg

a Java virtuális gép a bájtkód értelmezője;

A nagy teljesítményű keretrendszer-könyvtár támogatja az építhetőséget különféle típusok C# nyelvű alkalmazások, amelyek megkönnyítik a webszolgáltatások, egyéb összetevők,

elegendő egyszerűen tárolni és lekérni az információkat az adatbázisból és más adattárolókból;

Ez egy megbízható és hatékony kód forrása.

A fent leírt nyelveken kívül a Modula, Ada, COBOL, FORTRAN és néhány másik is az univerzális csoportba tartozik. A fenti nyelvek mindegyikének megvannak a maga sajátosságai, és ennek megfelelően saját hatóköre. Jelenleg az univerzális programozási nyelveket az emberi tevékenység különböző területein használják, például:

Tudományos számítástechnika (C++, FORTRAN, Java nyelvek);

Rendszerprogramozás (C++, Java nyelvek);

Információfeldolgozás (C++, COBOL, Java nyelvek);

Mesterséges intelligencia (LISP, Prolog);

Kiadó (Postscript, TeX);

Távoli információfeldolgozás (Perl, PHP, Java, C++);

Dokumentumok leírása (HTML, XML).

Idővel egyes nyelvek fejlődtek, új funkciókra tettek szert, és továbbra is keresettek, mások elvesztették relevanciájukat, és ma a legjobb esetben is pusztán elméleti érdeklődésre tartanak számot (Focal, PL / 1 stb.). Ez nagyrészt a következő tényezőknek köszönhető:

Olyan programozási környezet elérhetősége, amely támogatja az alkalmazások fejlesztését egy adott programozási nyelven;

A programok egyszerű karbantartása és tesztelése;

Egy adott programozási nyelv használatával történő fejlesztés költsége;

A nyelvi konstrukciók egyértelműsége és ortogonalitása;

Objektumorientált megközelítés alkalmazása.

Speciális fejlesztői nyelveket használnak bizonyos típusú szoftverek létrehozására. Tartalmazzák:

Adatbázis nyelvek;

Nyelvek hálózati alkalmazások létrehozásához;

Rendszerépítő nyelvek mesterséges intelligencia stb.

A speciális felhasználói nyelvek általában a professzionális felhasználói környezetek részét képezik, szűken fókuszálnak, és a szoftverfejlesztők nem használják őket.

Az alacsony szintű nyelvek lehetővé teszik a programozást szinte a gépi utasítások szintjén. Ugyanakkor mind az idő szempontjából a legoptimálisabbat kapják

végrehajtását, és a programhoz szükséges memória mennyiségét tekintve. Hátránya, hogy nem támogatják a strukturált programozás elveit.

Manapság az assembly nyelv típusú nyelvek általában a következőket használják:

Ha összehasonlítóan írunk egyszerű programok, felvenni a kapcsolatot technikai eszközöket, mint például a járművezetők;

Magas szintű nyelveken a programokba való beillesztések formájában, például az adatok nagy ismétlésszámú hurkokban történő transzformációjának felgyorsítása érdekében.

A programozási nyelv kiválasztását nagyobb mértékben a fejlesztő tapasztalata, a fejlesztést vezető szervezet követelményei, vagy egyszerűen kialakult vélemény határozza meg.

7.7.3. Programozási környezet kiválasztása

Az integrált szoftverfejlesztő környezet egy rendszer szoftver eszközök a programozók szoftverfejlesztésre használják.

A fejlesztői környezet jellemzően szövegszerkesztőt, fordítót és/vagy értelmezőt, linkert, hibakeresőt és súgórendszert tartalmaz. Néha tartalmaz egy verzióvezérlő rendszert és különféle eszközöket a grafikus felhasználói felület felépítésének egyszerűsítésére.

Számos modern fejlesztőkörnyezet tartalmaz objektum-ellenőrzőt, osztályböngészőt és osztályhierarchia diagramot is, amelyeket objektumorientált szoftverfejlesztéshez használnak.

A fejlesztőkörnyezet általában egy adott programozási nyelvhez, például a Visual Basichez vagy a Deiphihez szól, de vannak fejlesztői környezetek több nyelvhez is, mint például az Eclipse vagy a Microsoft Visual Studio.

Példák a fejlesztői környezetekre: Turbo Pascal, Borland C++, GNU toolchain, DrPython.

Az utóbbi időben az objektum-orientált programozás fejlődésével terjedtek el a korábban említett vizuális programozási környezetek, a

amelyek a programkód leggyakoribb blokkjait grafikus objektumokként ábrázolják.

A leggyakrabban használt vizuális környezetek a Delphi, a Borland (Inprise Corporation) C++ Builder, a Visual C++, a Microsoft Visual Basic, az IBM Visual Ada stb.

A Microsoft által hagyományos programok és webalkalmazások létrehozására szolgáló platformként javasolt .NET Framework technológia napjainkban nagy népszerűségre tett szert. A .NET fő előnye a különböző nyelveken írt szolgáltatások kompatibilitása.

Például egy C++ nyelven írt szolgáltatás .NET-hez hozzáférhet egy osztálymetódushoz egy Delphiben írt könyvtárból; C#-ban írhatunk olyan osztályt, amely a Visual Basic .NET-ben írt osztálytól örököl, a C#-ban írt metódussal dobott kivétel pedig Delphiben fogható és kezelhető.

A programozási nyelv kiválasztásához hasonlóan a programozási környezet kiválasztását a projekt jellege, a fejlesztő szokásai és készségei, a kor trendjei, a megrendelő igényei és egyszerűen a közvélemény határozza meg. : „Minden ilyen fejlesztést a környezetben kell végrehajtani...

1. Szoftverfejlesztő eszközök. A szoftvereszközök fejlesztése során bizonyos mértékig számítógépes támogatást használnak a PS fejlesztéséhez. Ezt úgy érik el, hogy a PS legalább néhány programdokumentumát (elsősorban programokat) számítógépes adathordozókon (például lemezeken) jelenítik meg, és a PS fejlesztőjét speciális PS-ekkel vagy a számítógépben található speciális eszközökkel látják el, amelyek az ilyen dokumentumok feldolgozásához készültek. . Mint ilyen speciális PS, bármilyen programozási nyelvből megadhatunk fordítót.

A fordító mentesíti a PS fejlesztőt attól, hogy a programokat a számítógép nyelvén írja meg, ami a fejlesztőé. A PS rendkívül kényelmetlen lenne - ehelyett a számára kényelmes programozási nyelven ír programokat, amelyeket a megfelelő fordító automatikusan lefordít a számítógép nyelvére. Mint speciális eszköz, amely támogatja a PS fejlesztési folyamatát, bármely nyelv emulátoraként szolgálhat. Az emulátor lehetővé teszi a programok futtatását (értelmezését) a PS fejlesztését támogató számítógép nyelvétől eltérő nyelven, például annak a számítógépnek a nyelvén, amelyre ez a program készült. A más PS-ek fejlesztésének támogatására tervezett PS-t a PS szoftverfejlesztő eszközének, a kifejezetten a PS fejlesztését támogató számítógépes eszközt pedig a PS hardverfejlesztő eszközének nevezik.

A PS fejlesztői eszközök a PS teljes életciklusa során használhatók a különböző programdokumentumokkal való együttműködéshez. Szövegszerkesztővel tehát szinte bármilyen programdokumentum fejleszthető. A szoftverfejlesztés során az eszközök által ellátott funkciók szempontjából a következő négy csoportba sorolhatók: szerkesztők, elemzők, konverterek, a programvégrehajtási folyamatot támogató eszközök.

A szerkesztők támogatják bizonyos programdokumentumok tervezését (alakítását) az életciklus különböző szakaszaiban. Mint már említettük, ehhez valamilyen univerzális szövegszerkesztőt használhat. A speciális szerkesztők azonban erősebb támogatást nyújthatnak: minden dokumentumtípusnak megvan a maga szerkesztője. Különösen a fejlesztés korai szakaszában lehet széles körben felhasználni a dokumentumokat grafikus segédeszközök leírások (diagramok, diagramok stb.). Ilyen esetekben nagyon hasznosak lehetnek a grafikus szerkesztők. A programozási (kódolási) szakaszban a szövegszerkesztő helyett kényelmesebb lehet egy szintaktikailag vezérelt szerkesztő használata, amely a használt programozási nyelvhez igazodik. Az elemzők elvégzik a dokumentumok statikus feldolgozását, különféle ellenőrzési módokat, azok egyes tulajdonságainak azonosítását és statisztikai adatok felhalmozását (például a dokumentumok meghatározott szabványoknak való megfelelésének ellenőrzését), vagy a programok dinamikus elemzését (pl. szerinti programmunkaidő-eloszlásának azonosítására szoftver modulok). A konverterek lehetővé teszik a dokumentumok automatikus másfajta megjelenítési formába hozását (például formázók), vagy egy típusú dokumentum lefordítását egy másik típusú dokumentummá (például konverterek vagy fordítók), egy dokumentum szintetizálása különálló részekből stb.

A programvégrehajtás folyamatát támogató eszközök lehetővé teszik a folyamatok vagy egyes részeik leírásának számítógépen történő végrehajtását, amelyek nem gépi kódban vagy gépi kóddal jelennek meg. további jellemzők az ő értelmezése. Ilyen eszköz például egy másik számítógép kódemulátora. Ebbe az eszközcsoportba különféle hibakeresőket is bele kell foglalni. Lényegében minden programozási rendszer tartalmaz egy futásidejű szoftver alrendszert, amely a programozási nyelvre legjellemzőbb programtöredékeket hajtja végre, és szabványos választ ad a programok végrehajtása során fellépő kivételekre (az ilyen alrendszert executive supportnak nevezzük) - szintén lehet eszköznek tekintik e csoportok számára.

2. Eszközkörnyezetek szoftverek fejlesztéséhez és karbantartásához. Jelenleg nem külön eszközök (például fordító) vannak társítva az egyes programozási rendszerekhez, hanem valamilyen logikailag összefüggő szoftver- és hardvereszközkészlet, amely támogatja a szoftverrendszerek fejlesztését és karbantartását. adott nyelv programozás, vagy egy adott témakörre összpontosít. Egy ilyen készletet a PS fejlesztésének és karbantartásának instrumentális környezetének nevezünk. Az ilyen eszközkörnyezeteket egyrészt szoftveres és hardveres eszközök használata, másrészt egy adott programozási nyelvhez vagy egy adott tárgykörhöz való bizonyos orientáció jellemzi. Az eszközkörnyezetnek nem kell működnie azon a számítógépen, amelyen a segítségével fejlesztett PS-t használni kell majd. Gyakran egy ilyen kombináció meglehetősen kényelmes (ha csak a használt számítógép teljesítménye lehetővé teszi): nem kell különféle típusú számítógépekkel foglalkozni, magának az eszközkörnyezetnek a komponensei beépíthetők a kifejlesztett PS-be.

A PS programozási környezet fejlesztésére és karbantartására szolgáló eszközkörnyezetek három fő osztálya, számítástechnikai munkahelyek, programozástechnikai eszközrendszerek. A programozási környezet elsősorban a PS programozási (kódolási), tesztelési és hibakeresési folyamatait hivatott támogatni. A számítástechnika munkahelye a PS (specifikációk) fejlesztésének korai szakaszainak támogatására és a specifikációk szerinti automatikus programok generálására összpontosít. A programozási technológiai eszközrendszert úgy tervezték, hogy támogassa az összes fejlesztési és karbantartási folyamatot a szoftver teljes életciklusa során, és a nagy méretű szoftverek kollektív fejlesztésére összpontosít. szoftverrendszerek hosszú életciklussal.

3. A programozóeszköz-környezetek mindenekelőtt tartalmaznak egy szövegszerkesztőt, amely lehetővé teszi programok tervezését egy adott programozási nyelven, olyan eszközöket, amelyek lehetővé teszik a programok ezen a nyelven történő fordítását vagy értelmezését, valamint az így létrejövő programok tesztelését és hibakeresését. Ezen kívül lehetnek más eszközök is, például statikus vagy dinamikus programelemzéshez. Ezek az eszközök normál szolgáltatásokat használó, közönséges fájlokon keresztül kölcsönhatásba lépnek egymással. fájlrendszer. A programozási eszközkörnyezetek következő osztályai vannak: környezetek Általános rendeltetésű, nyelvorientált környezetek.

Az általános célú programozási környezetek olyan szoftvereszközöket tartalmaznak, amelyek különböző programozási nyelveken támogatják a programok fejlesztését (például szövegszerkesztő, linker vagy célszámítógépes nyelvi tolmács), és általában a programozás képességeinek némi kiterjesztését jelentik. használt operációs rendszert. Ha ilyen környezetben bármilyen programozási nyelven szeretne programozni, további eszközökre lesz szüksége, amelyek erre a nyelvre vannak orientálva (például fordító). . . Programozási környezetek osztályozása

4. A szoftverfejlesztési számítástechnika fogalma és feladatai. Vannak bizonyos nehézségek a CASE-technológia (a PS fejlesztésére szolgáló számítógépes technológia) szigorú meghatározásának kidolgozása során. A CASE az angol Computer-Aided Software Engineering (Computer. Assisted Programming Engineering) rövidítése. De számítógép segítsége (támogatása) nélkül már régóta nem fejlesztenek PS-eket (legalább fordítóprogramot használnak). Valójában egy szűkebb (speciális) jelentést helyeznek ebbe a fogalomba, amely fokozatosan elmosódik (mint ez mindig megtörténik, ha egy fogalomnak nincs szigorú definíciója). A CASE kezdetben a szoftverfejlesztés korai szakaszainak tervezése (követelmények meghatározása, a szoftver külső leírásának és architektúrájának kidolgozása) szoftvertámogatás (szoftvereszközök) segítségével. A CASE ma már a szoftver teljes életciklusának tervezéseként is felfogható (beleértve a karbantartást is), de csak abban az esetben, ha a programok részben vagy teljesen a fejlesztés jelzett korai szakaszában beszerzett dokumentumok alapján generálódnak. Ebben az esetben a CASE-technológia alapvetően eltér a szoftverfejlesztés manuális (hagyományos) technológiájától: nemcsak a technológiai folyamatok tartalma változott meg, hanem azok összessége is.

A PS fejlesztésére szolgáló számítástechnika jelenleg a következőkkel jellemezhető: - Szoftvertámogatás alkalmazása a PS grafikai követelményeinek és grafikus specifikációinak fejlesztéséhez, - Programok automatikus generálása bármilyen programozási nyelven vagy gépi kódban (részben vagy teljesen), - Szoftver támogatás prototípus készítéséhez .

A programozási technológiai eszközrendszer olyan szoftverek és hardvereszközök integrált készlete, amely támogatja a nagy szoftverrendszerek fejlesztésének és karbantartásának összes folyamatát egy adott technológia teljes életciklusa során. Ebből a definícióból a következő főbb jellemzői következnek a számítógépes támogatás ezen osztályának: · összetettség, · a kollektív fejlesztésre való összpontosítás, · technológiai biztonság, · integráció.

A programozástechnikai műszerrendszerek tárgyalt tulajdonságait figyelembe véve három fő összetevőjük különíthető el: · fejlesztési adatbázis (repository), · eszközök, · interfészek.

Repository - a PS projektjével (fejlesztésével) kapcsolatos információk központi számítógépes tárolása a teljes életciklus során. Eszközkészlet - olyan eszközkészlet, amely meghatározza a rendszer által a fejlesztőcsapat számára biztosított képességeket. Általában ez a készlet nyitott: a minimális készleten (beépített eszközök) kívül tartalmazza a bővítésének eszközeit (importált eszközök), valamint strukturált, az összes eszköz valamilyen közös részéből (a magból) és szerkezeti (néha hierarchikusan összefüggő) eszközosztályok. Az interfészek 1) felhasználói 2) rendszerre oszthatók. A felhasználói felület hozzáférést biztosít a fejlesztőknek a rendszerhéj által megvalósított eszközökhöz (parancsnyelv stb.). A rendszer interfészek interakciót biztosítanak az eszközök és közös részeik között. A rendszer interfészek, mint architekturális komponensek a rendszer nyitottsága miatt emelkednek ki – ezeket a rendszerbe beépített új (importált) eszközöknek kell használniuk.

A programozási technológiai eszközrendszereknek két osztálya van: 1) projekttámogató eszközrendszerek és 2) nyelvfüggő eszközrendszerek. A projekttámogató eszközrendszer egy nyílt rendszer, amely a választott nyelvre orientált szoftvereszközökkel történő megfelelő bővítést követően képes különböző programozási nyelveken szoftvertermékek fejlesztését támogatni. Egy ilyen rendszer tartalmaz egy magot (elsősorban hozzáférést biztosítva a repository-hoz), a PS fejlesztés menedzselését (menedzselést) támogató eszközkészletet, a PS fejlesztését támogató programozási nyelvtől független eszközöket (szöveges és grafikus). szerkesztők, jelentéskészítők stb.), valamint rendszerbővítő eszközök. A nyelvfüggő műszerrendszer olyan szoftverfejlesztést támogató rendszer bármely programozási nyelvben, amely alapvetően ennek a nyelvnek a sajátosságait használja fel munkája szervezésében. Ez a sajátosság hatással lehet mind a kernel képességeire (beleértve a tároló szerkezetét), mind a shell és az eszközök követelményeire.

Egységesített modellezési nyelv UML Most meglévő módszereket Az objektumorientált elemzés és tervezés (OOAD) egy modellezési nyelvet és a modellezési folyamat leírását is tartalmazza. A modellező nyelv egy (többnyire grafikus) jelölés, amelyet egy metódus használ a projektek leírására. A jelölés a modellekben használt grafikus objektumok gyűjteménye; ez egy modellező nyelv szintaxisa. Például az osztálydiagram jelölése határozza meg, hogyan jelenjenek meg az olyan elemek és fogalmak, mint az osztály, az asszociáció és a többszörösség. A folyamat a projekt fejlesztése során követendő lépések leírása. Az Unified Modeling Language (UML) a 80-as évek végén és a 90-es évek elején megjelent OOAP-módszerek generációjának utódja.

Az UML egy általános célú vizuális modellező nyelv, amelyet szoftverösszetevők, üzleti folyamatok és egyéb rendszerek specifikálására, megjelenítésére, tervezésére és dokumentálására terveztek. Az UML nyelv egy egyszerű és hatékony modellező eszköz, amely hatékonyan használható különféle komplex rendszerek fogalmi, logikai és grafikus modelljei felépítésére. kijelölt célra. Az UML konstruktív használata a megértésen alapul Általános elvek komplex rendszerek modellezése és különösen az objektum-orientált tervezés (OOP) folyamatának jellemzői. Az összetett rendszerek modelljeinek megalkotásához szükséges kifejező eszközök megválasztása előre meghatározza azokat a feladatokat, amelyeket ezekkel a modellekkel lehet megoldani. Ugyanakkor a komplex rendszerek modelljeinek megalkotásának egyik alapelve az absztrakció elve, amely előírja, hogy a tervezett rendszernek csak azokat a szempontjait vegyék be a modellbe, amelyek közvetlenül kapcsolódnak a rendszer funkcióinak teljesítéséhez, vagy annak céljaihoz. célja. Ebben az esetben minden apró részletet kihagyunk, hogy ne bonyolítsuk túlzottan az eredményül kapott modell elemzésének és tanulmányozásának folyamatát.

Az UML különféle típusú diagramok és jelölések szabványos készletét tartalmazza. Egy diagram az UML-ben grafikus ábrázolás elemek halmaza, amelyet leggyakrabban csúcsokkal (entitásokkal) és élekkel (relációkkal) összefüggő gráfként ábrázolnak. Diagramok készülnek, hogy egy rendszert különböző perspektívákból ábrázoljanak. A diagram bizonyos értelemben a rendszer egyik vetülete. A diagramok általában – a legtriviálisabb esetek kivételével – sűrített képet adnak a rendszert alkotó elemekről. Ugyanaz az elem előfordulhat minden diagramon, vagy csak néhányon (a leggyakoribb), vagy egyiken sem (nagyon ritka). Elméletileg a diagramok entitások és kapcsolatok tetszőleges kombinációját tartalmazhatják. A gyakorlatban azonban viszonylag kis számú tipikus kombinációt használnak, amelyek megfelelnek a szoftverrendszer architektúráját alkotó öt leggyakoribb típusnak.

Az UML a következő típusú diagramokat különbözteti meg: - használati eset diagramok - a szervezet üzleti folyamatainak (rendszerkövetelmények) modellezésére; - osztálydiagramok (osztálydiagramok) - a rendszerosztályok statikus szerkezetének és a köztük lévő kapcsolatok modellezésére. Az ilyen diagramok osztályokat, felületeket, objektumokat és együttműködéseket, valamint ezek kapcsolatait mutatják be. Objektumorientált rendszerek modellezésekor ezt a fajta diagramot használják leggyakrabban. Az osztálydiagramok a rendszer statikus nézetének felelnek meg tervezési szempontból; – rendszerviselkedési diagramok (viselkedési diagramok); interakciós diagramok - az objektumok közötti üzenetküldési folyamat modellezésére. - állapotdiagramok - a rendszerobjektumok viselkedésének modellezésére az egyik állapotból a másikba való átmenet során.

- tevékenység diagramok - a rendszeren belüli viselkedés modellezésére különféle lehetőségeket felhasználási vagy modellezési tevékenységek. - megvalósítási diagramok (implementációs diagramok): komponens diagramok (komponens diagramok) - a rendszer összetevői (alrendszerei) hierarchiájának modellezésére; telepítési diagramok (telepítési diagramok) - a rendszer fizikai architektúrájának modellezésére.

Bevezetés

A szoftverfejlesztés során a legsokoldalúbb szoftverek (SW) nagy részét használják. Ez az előadási kurzus azt vizsgálja, hogy mikor és mit használnak az alkalmazásfejlesztési szakaszban.

Annak érdekében, hogy teljesebb képet kapjunk az egyes segédprogramok vagy fejlesztési szeletek szerepéről a szoftverfejlesztési folyamatban, az előadások során tárgyalt összes eszközt a magas szintű nyelvek valamelyikét használó alkalmazásfejlesztés példáján keresztül megvizsgáljuk. Az egyszerűség kedvéért az összes használt szerszám 4 csoportba osztható. Nézzük meg közelebbről az egyes csoportokat.

Kívánt

Szükséges eszközök azok, amelyek nélkül elvileg nem lehet végrehajtható kódot szerezni; Ez a csoport a következőket tartalmazza:

§ szövegszerkesztők;

§ fordítók és összeállítók;

§ linkerek vagy szerkesztői hivatkozások (linkerek);

Gyakran használt

Ezek olyan eszközök, amelyek használata a szükségesektől eltérően elkerülhető. De nélkülük a fejlesztési folyamat nagyon nehéz és meghosszabbodik; A gyakran használt eszközök a következők:

§ segédprogramok a projekt automatikus összeállításához;

§ hibakeresők;

§ telepítők létrehozására szolgáló programok;

§ forrásszerkesztők;

§ profilkészítők;

§ verziótámogató programok;

§ súgófájlok (dokumentáció) létrehozására szolgáló programok.

Specializált

Ezeket az eszközöket kivételes esetekben használják, meglehetősen specifikus feladatokat oldanak meg:

§ függőséget követő programok;

§ szétszerelők;

§ visszafordítók;

§ hex szerkesztők;

§ a rendszer tevékenységének és a rendszerben bekövetkező változások nyomon követésére szolgáló programok;

§ ellenőrző programok és tárolók (virtuális környezet létrehozása az egyes programosztályok számára, amelyben felfedezheti a program viselkedését);

Integrált fejlesztési környezetek

Az IDE-k a legtöbb fenti programot tartalmazzák, és megkönnyítik az alkalmazások létrehozását. A fejlesztői környezet nagyjából egy olyan program, amely az első és a második (és néha a harmadik) csoport több eszközét egyesíti.

A jövőben részletesebben megismerkedünk az egyes csoportok fő képviselőivel, valamint átgondoljuk, hogyan működik mindez egy integrált fejlesztői környezetben.

SZERSZÁMOK OSZTÁLYOZÁSA

1. TÉMA AZ SZERSZÁM FOGALMA.

SZERSZÁMOK OSZTÁLYOZÁSA.

Programozástechnikai eszközrendszer szoftver és hardver eszközök integrált készlete, amely támogatja a nagy PS fejlesztési és karbantartási folyamatait annak teljes életciklusa során, egy bizonyos technológián belül.

A programozási technológia eszközrendszerei három fő részre oszthatók:

az adattárat

az eszközkészlet,

interfészek.

Eszközök- olyan eszközkészlet, amely meghatározza a rendszer által a fejlesztőcsapat számára biztosított képességeket. Általában ez a készlet nyitott és strukturált. A minimális készleten kívül ( beépített eszközök), tartalmazza a kiterjesztésének eszközeit ( importált műszerek). Ezenkívül a műveletek feletti integráció miatt az összes eszköz közös részéből áll ( magok) és strukturális (olykor hierarchikusan összefüggő) eszközosztályok.

Interfészek felhasználóra és rendszerre osztva. Egyedi A felület hozzáférést biztosít a fejlesztőknek az eszközkészlethez. Megvalósul héj rendszerek. Szisztémás Az interfészek interakciót biztosítanak az eszközök és közös részeik között. A rendszer interfészek a rendszer nyitottsága miatt architekturális komponensként tűnnek ki – ezeket új ( importált) a rendszerben található eszközök.

A programozástechnikai műszerrendszerek legáltalánosabb architektúráját az ábra mutatja.

Rizs. Programozástechnikai műszerrendszerek általános felépítése.

A programozási technológiai eszközrendszereknek két osztálya van: projekttámogató eszközrendszerek és nyelvfüggő eszközrendszerek.

Projekttámogató eszközrendszer- ez egy nyílt rendszer, amely a kiválasztott nyelvre orientált szoftvereszközökkel történő megfelelő kiterjesztés után támogatja a PS fejlesztését különböző programozási nyelveken. Egy ilyen rendszer eszközkészlete támogatja a PS fejlesztését, emellett a programozási nyelvtől független, a PS fejlesztését támogató eszközöket is tartalmaz (szöveg- és grafikus szerkesztők, riportgenerátorok stb.). Ezen kívül rendszerbővítő eszközöket is tartalmaz. Egy ilyen rendszer magja különösen hozzáférést biztosít az adattárhoz.

Nyelvfüggő eszközrendszer- ez egy szoftverfejlesztést támogató rendszer bármely programozási nyelven, amely lényegében ennek a nyelvnek a sajátosságait használja fel munkája szervezésében. Ez a sajátosság hatással lehet mind a kernel képességeire (beleértve a tároló szerkezetét), mind a shell és az eszközök követelményeire.