Szoftvertervezés

A Wikipédiából, a szabad enciklopédiából

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.[1] 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."[2]

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[szerkeszté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. Davis[3] 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[szerkesztés]

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:

  1. 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.
  2. 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.
  3. Modularitás - A szoftver architektúrája modulokra nevezett komponensekre oszlik.
  4. 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.
  5. Vezérlőhierarchia - olyan programstruktúra, amely a programösszetevő szervezetét képviseli, és magában foglalja a vezérlési hierarchiát.
  6. 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.
  7. Adatstruktúra - Ez az adatok egyes elemei közötti logikai kapcsolat ábrázolása.
  8. Szoftver eljárás - Az egyes modulok feldolgozására összpontosít.
  9. 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.[4] A PHAME rövidítést (Principles of Hierarchy, Abstraction, Modularisation, and Encapsulation) néha e négy alapelvre utal.[5]

Tervezési szempontok[szerkesztés]

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.[6]
  • 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.

Modellező nyelv[szerkesztés]

A modellező nyelv minden olyan mesterséges nyelv, amely felhasználható információk, ismeretek vagy rendszerek kifejezésére egy struktúrában, amelyet egységes szabályrendszer határoz meg. Ezeket a szabályokat az összetevők értelmezésére használják a szerkezeten belül. A modellező nyelv lehet grafikus vagy szöveges. Példák a szoftvertervezés grafikus modellezési nyelveire:

  • Szerkezetleíró nyelv (ADL) egy olyan nyelv leírására ami képviseli az architektúráját egy szoftverrendszernek.
  • Az üzleti folyamatok modellezési notációja (BPMN) egy példa a folyamatmodellezési nyelvre.
  • Az EXPRESS és az EXPRESS-G (ISO 10303-11) egy általános szabvány általános célú adatmodellezési nyelv.
  • Az kiterjesztett vállalati modellezési nyelvet (EEML) általában használják az üzleti folyamatok modellezésére több rétegben.
  • A folyamatábrák algoritmusok vagy más lépésről lépésre történő sematikus ábrázolások.
  • Az Fundamental Modeling Concepts (FMC) a szoftverintenzív rendszerek modellezési nyelve.
  • Az IDEF egy modellezési nyelvcsalád, amelyek közül a legjelentősebb az IDEF0 a funkcionális modellezéshez, az IDEF1X az információs modellezéshez és az IDEF5 az ontológiák modellezéséhez.
  • A Jackson Strukturált Programozás (JSP) egy olyan módszer a strukturált programozáshoz, amely az adatfolyam és a program struktúrájának összefüggésein alapszik.
  • A LePUS3 objektum-orientált vizuális formatervezési nyelv és formális specifikációs nyelv, amely elsősorban nagy objektum-orientált (Java, C++, C # ) programok és tervezési minták modellezésére alkalmas.
  • Az Unified Modeling Language (UML) egy általános modellezési nyelv, amely leírja a szoftvert mind szerkezetileg, mind viselkedésbeli szempontból. Grafikus jelöléssel rendelkezik, és lehetővé teszi a profil (UML) kiterjesztését.
  • Az ötvözet (specifikációs nyelv) egy általános célú specifikációs nyelv a szoftverrendszer komplex szerkezeti korlátainak és viselkedésének kifejezésére. Tömör nyelvi alapot nyújt az elsőrendű relációs logikáról.
  • A rendszerek modellezési nyelve (SysML) egy új általános célú modellezési nyelv a rendszerek tervezéséhez.
  • Szolgáltatásorientált modellezési keret (SOMF)[7]

Tervezési minták[szerkesztés]

A szoftvertervező azonosíthat egy olyan tervezési problémát, amelyet a múltban már észrevettek, és talán meg is megoldottak mások. A közös probléma megoldását leíró sablont vagy mintát tervezési mintának hívják. Az ilyen minták újbóli felhasználása felgyorsíthatja a szoftverfejlesztési folyamatot.[8]

Technika[szerkesztés]

Azért nehéz a "tervezés" kifejezést a szoftverrel kapcsolatban használni, mert néhány esetben a program forráskódja a kiadott program terve is. Amennyiben ez igaz, a "szoftvertervezés" a formatervezés tervezésére vonatkozik. Edsger W. Dijkstra a szemantikai szintek ilyen rétegződését a számítógépes programozás "radikális újdonságának" nevezi[9] és Donald Knuth a TeX írása során szerzett tapasztalatainak segítségével leírta a program megtervezésének kísérletének hiábavalóságát annak végrehajtása előtt:


„A TEX egy nagy kudarc lenne, ha csak meghatároztam volna, és nem vettem volna teljes mértékben részt annak kezdeti végrehajtásában. A végrehajtás folyamata állandóan váratlan kérdésekhez és új ismeretekhez vezetett arról, hogyan lehetne javítani az eredeti specifikációt.[10]

Használat[szerkesztés]

A szoftvertervezési dokumentáció felülvizsgálható vagy bemutatható, hogy lehetővé váljon a korlátozások, a specifikációk és a követelmények kiigazítása a számítógépes programozás előtt. Az újratervezés bekövetkezhet egy programozott szimuláció vagy prototípus áttekintése után. Lehetőség van szoftver fejlesztésére a programozás során, terv vagy követelmény elemzés nélkül,[11] de összetettebb projektek esetében ez nem lenne megvalósítható. A programozás előtt egy külön tervezés lehetővé teszi a multidiszciplináris tervezőknek és a téma szakértőinek számára, hogy együttműködjenek magasan képzett programozókkal a szoftverek számára, amelyek hasznosak és technikai szempontból is megfelelnek.

Jegyzetek[szerkesztés]

  1. 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 doi:10.1007/978-3-540-92966-6_6.
  2. Freeman (2004). „A Science of design for software-intensive systems”. Communications of the ACM 47 (8), 19–21 [20]. o. DOI:10.1145/1012037.1012054.  
  3. Davis, A:"201 Principles of Software Development", McGraw Hill, 1995.
  4. Booch, Grady. Object-Oriented Analysis and Design with Applications, 3rd, MA, USA: Addison Wesley (2004. április 25.). ISBN 0-201-89551-X. Hozzáférés ideje: 2015. január 30. 
  5. Suryanarayana, Girish. Refactoring for Software Design Smells. Morgan Kaufmann, 258. o. (2014. november 1.). ISBN 978-0128013977 
  6. szerk.: Carroll: Scenario-Based Design: Envisioning Work and Technology in System Development. New York: John Wiley & Sons (1995). ISBN 0471076597 
  7. Bell, Michael. Introduction to Service-Oriented Modeling, Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons (2008). ISBN 978-0-470-14111-3 
  8. Judith Bishop: C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems. C# Books from O'Reilly Media. (Hozzáférés: 2012. május 15.) „If you want to speed up the development of your .NET applications, you're ready for C# design patterns -- elegant, accepted and proven ways to tackle common programming problems.”
  9. Dijkstra: On the cruelty of really teaching computing science, 1988. (Hozzáférés: 2014. január 10.)
  10. Knuth, Donald E.: Notes on the Errors of TeX, 1989
  11. Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136

Irodalom[szerkesztés]

  • Roger S. Pressman. Software engineering: a practitioner's approach. McGraw-Hill. ISBN 0-07-365578-3  Roger S. Pressman. Software engineering: a practitioner's approach. McGraw-Hill. ISBN 0-07-365578-3  Roger S. Pressman. Software engineering: a practitioner's approach. McGraw-Hill. ISBN 0-07-365578-3 

Fordítás[szerkesztés]

Ez a szócikk részben vagy egészben a Software design című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

Kapcsolódó szócikk[szerkesztés]