A szoftvertervezés az az eljárás, ahol a szerző létrehoz egy szoftvertermék specifikációt, melynek lényege különböző célok elérése, primitív összetevők felhasználásával és korlátozásoknak alávetve.Ralph, P. and Wand, Y. (2009). A proposal for a formal definition of the design concept. In Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., editors, Design Requirements Workshop (LNBIP 14), pp. 103–136. Springer-Verlag, p. 109 . A szoftverfejlesztés utalhat "az összes tevékenységre, amely a komplex rendszerek fogalmának megfogalmazásában, kialakításában, megvalósításában, üzembe helyezésében és végső soron átalakításában", vagy "a követelmények specifikációját követő és a programozás előtti tevékenységekre vonatkozik, mint egy stilizált szoftverfejlesztési folyamat."
A szoftvertervezés általában magában foglalja a problémamegoldást és a szoftvermegoldás tervezését. Ez magában foglalja mind az alacsony szintű összetevők és algoritmusok kialakítását, mind a magas szintű architektúrák kialakítását.
Áttekintés A szoftvertervezés egy vagy több problémakészlet szoftvermegoldásainak elképzelése és meghatározása. A szoftvertervezés egyik fő alkotóeleme a szoftverigény-elemzés (Software Requirements Analysis - SRA). Az SRA a szoftverfejlesztési folyamat része, amely felsorolja a szoftverfejlesztésben használt specifikációkat. Ha a szoftver "félig automatizált" vagy felhasználóközpontú, akkor a szoftvertervezés során a felhasználói élményt olyan tervezéssel kell ellátni, amely előállít egy forgatókönyvet az előírások meghatározásához. Ha a szoftver teljesen automatizált (azaz nincs felhasználó vagy felhasználói felület), akkor a szoftvertervezés olyan egyszerű lehet, mint egy folyamatábra vagy az események tervezett sorozatát leíró szöveg. Vannak félig szabványos módszerek is, mint például a Unified Modeling Language (UML) és az alapvető modellezési koncepciók. Mindkét esetben a terv néhány dokumentációja általában a terv eredménye. Ezenkívül a szoftvertervezés lehet platformfüggetlen vagy platformspecifikus, attól függően, hogy rendelkezésre áll-e a tervezéshez használt technológia.
A szoftver-elemzés és a tervezés közötti fő különbség az, hogy a szoftverelemzés eredménye kisebb megoldandó problémákból áll. Ezenkívül az elemzést nem szabad nagyon különbözően megtervezni a különböző csoporttagok vagy csoportok között. Ezzel szemben a tervezés a képességekre összpontosít, így több terv is létezhet ugyanahhoz a problémához. A környezettől függően a formatervezés gyakran változik, függetlenül attól, hogy megbízható keretekből készül-e, vagy megfelelő tervezési mintákkal valósították meg. Tervezési példák lehetnek az operációs rendszerek, weboldalak, mobileszközök vagy akár az új felhőalapú számítástechnikai paradigma.
A szoftvertervezés mind folyamat, mind modell. A tervezési folyamat egy lépések sorozata, amely lehetővé teszi a tervezőnek, hogy leírja a szoftver összes aspektusát az elkészítéséhez. A kreatív készség, a múltbeli tapasztalat, a "jó" szoftvert létrehozó érzés és a minőség iránti általános elkötelezettség példák az illetékes tervezés kritikus sikertényezőire. Fontos azonban megjegyezni, hogy a tervezési folyamat nem mindig egyszerű eljárás; a tervezési modell összehasonlítható az építész ház terveivel. Először az építendő dolog összességének ábrázolásával kezdődik (pl. A ház háromdimenziós renderelése); lassan finomítják a dolgot, hogy útmutatást nyújtsanak az egyes részletek felépítéséhez (pl. a vízvezeték fektetése). Hasonlóképpen, a szoftver számára létrehozott tervezési modell a számítógépes szoftver különféle nézeteit tartalmazza. Az alapvető tervezési alapelvek lehetővé teszik a szoftvermérnök számára, hogy navigáljon a tervezési folyamatban. DavisDavis, A:"201 Principles of Software Development", McGraw Hill, 1995. elveket javasol a szoftvertervezéshez, amelyeket adaptáltak és kibővítettek a következő listában:
A tervezési folyamatnak nem szabad szenvednie a "csőlátásától". Egy jó tervezőnek fontolóra kell vennie az alternatív megközelítéseket, és mindegyiket a probléma igényei, és a munka elvégzéséhez rendelkezésre álló erőforrások alapján kell megítélnie. A tervnek nyomon kell követnie az elemzési modellt. Mivel a tervezési modell egyetlen elemét gyakran több követelményre vezethetjük vissza, ezért rendelkezni kell egy eszközzel annak nyomon követésére, hogy a tervezési modell hogyan teljesítette a követelményeket. A kialakításnak nem szabad feltalálnia a kereket. A rendszereket tervezési minták halmaza alapján állítják elő, amelyek közül sokkal valószínűleg találkoztak már korábban. Ezeket a mintákat mindig a feltalálás alternatívájaként kell megválasztani. Az idő rövid és az erőforrások korlátozottak; A tervezési időt bele kell fektetni a (valóban új) ötletek ábrázolására a már létező minták integrálásával (adott esetben). A tervezésnek "minimalizálnia kell a szellemi távolságot" a szoftver és a probléma között, mivel ez a valós világban fennáll. Vagyis a szoftver tervezésének struktúrájának, amikor csak lehetséges, utánoznia kell a probléma tartomány szerkezetét. A formatervezésnek egységességet és integrációt kell mutatnia. A formatervezés egységes, ha teljesen koherensnek tűnik. Ennek az eredménynek a elérése érdekében meg kell határozni a stílus és a formátum szabályait a tervezőcsoport számára a tervezési munka megkezdése előtt. A formatervezés integrálva van, ha vigyázunk a tervezési elemek közötti interfészek meghatározására. A tervet úgy kell kialakítani, hogy az megfeleljen a változásoknak. A következő szakaszban tárgyalt tervezési koncepciók lehetővé teszik a tervek számára ezen elv elérését. A kialakítást úgy kell kialakítani, hogy enyhén romoljon, még akkor is, ha eltérő adatokkal, eseményekkel vagy működési feltételekkel találkozunk. A jól megtervezett szoftverek soha nem bombázhatnak; úgy kell megtervezni, hogy figyelembe vegye a szokatlan körülményeket, és ha meg kell szüntetnie a feldolgozást, akkor ezt kecses módon kell megtennie. A tervezés nem kódolás, a kódolás nem tervezés. Még akkor is, ha a program összetevőire részletes eljárási terveket készítünk, a tervezési modell absztrakciójának szintje magasabb, mint a forráskódé. A kódolási szinten hozott egyetlen tervezési döntésnek a végrehajtás apró részleteire kell vonatkoznia, amelyek lehetővé teszik az eljárási terv kódolását. A formatervezés minőségét a kialakításkor kell értékelni, nem pedig a tény alapján. Különböző tervezési koncepciók és tervezési intézkedések állnak rendelkezésre, hogy segítsék a tervezőt a minőség értékelésében a fejlesztési folyamat során. A tervezést felül kell vizsgálni a fogalmi (szemantikai) hibák minimalizálása érdekében. Időnként hajlamosak vagyunk az apró részletekre összpontosítani a terv felülvizsgálatakor. A tervező csapatnak gondoskodnia kell arról, hogy a formatervezés fő fogalmi elemeivel (mulasztások, kétértelműség, következetlenség) foglalkozzanak, mielőtt a tervezési modell szintaxisa miatt aggódnának.
Tervezési koncepciók A tervezési koncepciók alapot nyújtanak a szoftvertervezőnek, amelyből kifinomultabb módszerek alkalmazhatók. Alapvető tervezési koncepciók halmaza fejlődött ki. Ezek a következők:
Absztrakció - Az absztrakció az általánosítás folyamata vagy eredménye azáltal, hogy egy fogalom vagy megfigyelhető jelenség információtartalmát csökkentik, tipikusan azért, hogy csak egy adott cél szempontjából releváns információkat tárolhassanak. Ez az alapvető jellemzők ábrázolása, a háttér részleteinek vagy magyarázatainak felvétele nélkül. Finomítás - Ez a kidolgozás folyamata. A hierarchiát úgy alakítják ki, hogy lépésről lépésre bontják a makroszkopikus működési kimutatást, amíg el nem érik a programozási nyelvi utasításokat. Mindegyik lépésben egy adott program egy vagy több utasítását részletesebb utasításokra bontjuk. Az absztrakció és a finomítás kiegészítő fogalmak. Modularitás - A szoftver architektúrája modulokra nevezett komponensekre oszlik. Szoftverarchitektúra - Ez utal a szoftver általános szerkezetére és annak módjaira, amellyel ez a struktúra a rendszer fogalmi integritását biztosítja. A jó szoftver-architektúra jó megtérülést eredményez a beruházás szempontjából a projekt kívánt eredményéhez képest, pl. A teljesítmény, a minőség, az ütemterv és a költség szempontjából. Vezérlőhierarchia - olyan programstruktúra, amely a programösszetevő szervezetét képviseli, és magában foglalja a vezérlési hierarchiát. Strukturális particionálás - A program felépítése vízszintesen és függőlegesen is felosztható. A vízszintes partíciók a főbb programfunkciókhoz a moduláris hierarchia különálló ágait definiálják. A függőleges particionálás azt sugallja, hogy a vezérlést és a munkát felülről lefelé kell elosztani a program struktúrájában. Adatstruktúra - Ez az adatok egyes elemei közötti logikai kapcsolat ábrázolása. Szoftver eljárás - Az egyes modulok feldolgozására összpontosít. Információ elrejtése - A modulokat meg kell határozni és úgy kell megtervezni, hogy a modulon belüli információk hozzáférhetetlenek legyenek más olyan modulok számára, amelyeknek nincs rá szükségük.
Objektummodelljében Grady Booch az absztrakciót, az egységbezárást, a modularizációt és a hierarchiát említi mint alapvető szoftvertervezési alapelveket. A PHAME rövidítést (Principles of Hierarchy, Abstraction, Modularisation, and Encapsulation) néha e négy alapelvre utal.
Tervezési szempontok Számos szempontot figyelembe kell venni egy szoftver tervezésénél. Az egyes szempontok fontosságának tükröznie kell azokat a célokat és elvárásokat, amelyekkel a szoftvert létrehozták, hogy megfeleljen. Néhány ilyen szempont a következő:
Kompatibilitás - A szoftver képes működni más termékekkel, amelyeket egy másik termékkel való együttműködésre terveztek. Például egy szoftver egy része visszamenőleg kompatibilis lehet önmagában egy régebbi verzióval. Bővíthetőség - Új lehetőségek adhatók a szoftverhez az alapul szolgáló architektúra jelentős változtatása nélkül. Modularitás - a kapott szoftver jól definiált, független komponenseket tartalmaz, ami jobb karbantarthatóságot eredményez. Az összetevőket ezután izolálva be lehet építeni és tesztelni, mielőtt integrálnák a kívánt szoftverrendszert. Ez lehetővé teszi a munka megosztását egy szoftverfejlesztési projektben. Hibatolerancia - A szoftver ellenálló az alkatrészek meghibásodásainak és helyreállítható azokból. Karbantarthatóság - A hibajavítások vagy a funkcionális módosítások egyszerűségének mérése. A magas karbantarthatóság a modularitás és a kibővíthetőség eredménye. Megbízhatóság (a szoftver tartóssága ) - A szoftver képes egy meghatározott funkciót meghatározott időtartamon keresztül elvégezni a megadott feltételek mellett. Újrafelhasználhatóság - Az a képesség, hogy a már létező szoftver némelyikét vagy mindegyik aspektusát más projektekben is felhasználjuk, kevés vagy nulla módosítással. Robusztus - A szoftver képes stressz alatt működni, elviseli a kiszámíthatatlan vagy érvénytelen bemeneteket. Például tervezhető úgy, hogy ellenálljon az alacsony memóriaviszonyoknak. Biztonság - A szoftver képes ellenállni az ellenséges cselekedeteknek és befolyásoknak. Használhatóság - A szoftver felhasználói felületének használhatónak kell lennie a célfelhasználó/közönség számára. A paraméterek alapértelmezett értékeit úgy kell megválasztani, hogy a felhasználók többsége számára jó választás legyen. Teljesítmény - A szoftver a felhasználó számára elfogadható időkereten belül végzi el feladatait, és nem igényel túl sok memóriát. Hordozhatóság - A szoftvernek számos különféle körülményben és környezetben használhatónak kell lennie. Méretezhetőség - A szoftver jól alkalmazkodik az adatok, hozzáadott szolgáltatások vagy a felhasználók számának növekedéséhez.
Szoftverfejlesztési életciklus