bélyegkép|336x336px| Példa UML 2.0-ban kifejezett két összetevőre. A pénztár komponens, amely elősegíti az ügyfél rendelését, megköveteli, hogy a kártyafeldolgozó komponens terhelje az ügyfél hitel- vagy betéti kártyáját (az utóbbi által biztosított funkció) A komponensalapú szoftverfejlesztés (CBSE), más néven komponensalapú fejlesztés (CBD) a szoftvertervezés egyik ága, amely hangsúlyozza az adott szoftverrendszerben elérhető széles körű funkcionalitással kapcsolatos aggályok elkülönítését. Ez egy újrafelhasználáson alapuló megközelítés a lazán összekapcsolt független komponensek rendszerbe történő meghatározásához, megvalósításához és komponálásához. Ennek a gyakorlatnak az a célja, hogy egyformán széles körű előnyöket érjen el rövid és hosszú távon mind a szoftver, mind a szoftvert támogató szervezetek számára.
A szoftvertervezéssel foglalkozó szakemberek az alkotóelemeket a szolgáltatásorientáció kiinduló platformjának tekintik. Az alkatrészek ezt a szerepet töltik be például a webszolgáltatásokban, újabban pedig a szolgáltatásorientált architektúrákban (SOA), amelyek során a webszolgáltatás egy alkotórészt átalakít szolgáltatássá, és ezt követően további jellemzőket örökít meg egy átlagos komponenshez képest.
Az alkatrészek előállíthatnak vagy felhasználhatnak eseményeket, és felhasználhatók eseményvezérelt architektúrákhoz (EDA).
Komponensek karakterisztikája és definíciója Egy egyedi szoftverkomponens egy szoftvercsomag, egy webszolgáltatás, egy webes erőforrás vagy egy modul, amely a kapcsolódó funkciók (vagy adatok) halmazát foglalja magában.
Az összes rendszerfolyamat különálló komponensekbe van foglalva, így az egyes összetevők belsejében lévő összes adat és funkció szemantikailag kapcsolatban áll egymással (akárcsak az osztályok tartalmával). Ezen elv miatt gyakran mondják, hogy az alkatrészek modulárisak és összetartók.
A rendszer egészére kiterjedő koordinációt illetően az komponensek interfészeken keresztül kommunikálnak egymással. Amikor egy komponens szolgáltatásokat kínál a rendszer többi részének, felvesz egy biztosított interfészt, amely meghatározza azokat a szolgáltatásokat, amelyeket a többi komponens használhat, és hogy hogyan tudják ezt megtenni. Ez az interfész a komponens aláírásának tekinthető – az ügyfélnek nem kell tudnia a komponens belső működéséről (megvalósításról) annak használatához. Ebből az elvből kiindulva nevezzük a komponenseket beágyazottaknak. A cikk UML-illusztrációi a komponens külső széléhez rögzített nyalóka-szimbólummal jelölt interfészeket ábrázolják.
Ha azonban egy összetevőnek egy másik összetevőt kell használnia a működéséhez, felvesz egy használt interfészt, amely meghatározza a számára szükséges szolgáltatásokat. A cikk UML-ábráin a használt interfészeket egy nyitott foglalat szimbólum képviseli, amely az alkatrész külső széléhez van rögzítve. balra|bélyegkép|500x500px| Egyszerű példa több szoftverkomponensre – az UML 2.0-ban képviselt elméleti üdülési foglalási rendszerben. Az összetevők másik fontos tulajdonsága, hogy helyettesíthetők, így egy alkatrész helyettesíthet egy másikat (tervezési vagy futási időben), ha az utód komponens megfelel az eredeti komponens követelményeinek (az interfészeken keresztül kifejezve). Következésképpen az alkatrészek cserélhetők egy frissített verzióval vagy egy alternatívával anélkül, hogy megszakítanák a rendszert, amelyben az alkatrész működik.
A komponenseket helyettesítő mérnökökre vonatkozó bevett szabályként a B komponens azonnal helyettesítheti az A komponenst, ha a B komponens legalább azt biztosítja, amit az A komponens biztosított, és nem használ többet, mint amit az A komponenst használt.
A szoftverkomponensek gyakran objektumok (nem osztályok) vagy objektumgyűjtemények formájában (objektumorientált programozásból), valamilyen bináris vagy szöveges formában, ragaszkodva valamilyen interfészleíró nyelvhez (IDL) jelennek meg, így az más komponensektől függetlenül létezhet egy számítógépben . Más szavakkal, egy komponens a forráskód megváltoztatása nélkül működik. Bár a komponens forráskódjának viselkedése megváltozhat az alkalmazás bővíthetősége alapján, amelyet az írója biztosít.
Amikor egy komponenst elérni vagy megosztani akarnak futtatási kontextusok közt vagy hálózati linkeken, gyakran olyan technikákat alkalmaznak, mint például a sorosítás vagy a rendezés, hogy az összetevőt a rendeltetési helyre juttassák.
Az újrafelhasználhatóság fontos jellemzője egy kiváló minőségű szoftverkomponensnek. A programozóknak úgy kell megtervezniük és megvalósítaniuk a szoftver-összetevőket, hogy sok különféle program újra felhasználhassa őket. Továbbá figyelembe kell venni az alkatrészalapú használhatóság tesztelését, amikor a szoftverkomponensek közvetlenül kölcsönhatásba lépnek a felhasználókkal.
Jelentős erőfeszítésre és tudatosságra van szükség egy olyan szoftverkomponens megírásához, amely hatékonyan újrafelhasználható. A komponensnek a következőknek kell lennie:
teljesen dokumentált alaposan tesztelt robusztus – átfogó input-érvényesség ellenőrzéssel képes a megfelelő hibaüzenetek vagy kódok visszaadására annak a tudatában készül, hogy előre nem látott felhasználási környezetekben lesz alkalmazva
Az 1960-as években a programozók tudományos alprogram könyvtárakat építettek, amelyek mérnöki és tudományos alkalmazások széles körében újrafelhasználhatók voltak. Bár ezek az alprogram könyvtárak hatékonyan használták jól körülhatárolt algoritmusokat, korlátozott alkalmazási területük volt. A kereskedelmi webhelyek rendszeresen létrehoztak alkalmazási programokat újrafelhasználható modulokból, amelyek Assembly , COBOL, PL / 1 és más második és harmadik generációs nyelveken íródtak, mind a rendszer, mind a felhasználói alkalmazás könyvtárak segítségével.
2010 óta a modern újrafelhasználható komponensek egybefoglalják az adatszerkezeteket és az azokra alkalmazott algoritmusokat. A komponensalapú szoftverfejlesztés számos korábbi elméletre épít a szoftver objektumok, szoftver architektúrák, szoftver keretrendszerek és szoftver tervezési mintákból, valamint a kiterjedt objektumorientált programozás elméletéből és ezek objektumorientált felépítéséről. Azt állítja, hogy a szoftver komponensek, mint a hardver komponensek melyeket például a telekommunikációban használnak, felcserélhetővé és megbízhatóvá tehetőek.
Története Az ötlet, hogy a szoftvert komponensekre kell építeni – előre gyártott komponensekből – először Douglas McIlroy beszédével vált hangsúlyossá az 1968-ban a szoftvertervezésről rendezettNATO-konferencián a németországi Garmisch-ban, Mass Produced Software Components címmel. A konferencia az úgynevezett szoftverválság leküzdésére indult. McIlroy a későbbi csövek és szűrők beépítésével a Unix operációs rendszerbe valósított meg először egy infrastruktúrát ehhez az ötlethez.
A stepstone-i Brad Cox nagyrészt meghatározta a szoftverkomponens modern koncepcióját. Szoftver IC-knek nevezte őket, és nekilátott, hogy az Objective-C programozási nyelv feltalálásával infrastruktúrát és piacot hozzon létre ezekhez az összetevőkhöz. (Ezt a nézetet foglalja össze Object-Oriented Programming – An Evolutionary Approach 1986 című könyvében.)
A szoftverkomponenseket két különböző kontextusban és kétféle módon használják: I) komponensek részekként történő felhasználása egyetlen futtatható fájl létrehozásához, vagy II) mindegyik futtatható összetevő komponensként kezelhető elosztott környezetben, ahol az összetevők az internet vagy intranet protokollok segítségével együttműködnek az IPC-hez (Inter Process Communications). A fentiek az előbbi, míg az alábbiak a későbbi fajtához tartoznak.
Az IBM az 1990-es évek elején a System Object Model (SOM) rendszerrel járt az élen. Válaszként a Microsoft megnyitotta az utat az objektum-összekapcsolás és beágyazás (OLE) és a komponens-objektum modell (COM) használatával a komponensszoftver tényleges telepítése felé. 2010-ben már sok sikeres szoftverkomponens-modell létezik.
Felépítés A több szoftverkomponenst futtató számítógépet gyakran alkalmazáskiszolgálónak nevezik. Az alkalmazáskiszolgálók és a szoftverkomponensek ilyen kombinációját általában megosztott számításnak hívják. Valóságbeli alkalmazása például pénzügyi alkalmazásokban vagy üzleti szoftverekben történik.
Komponens modellek A komponensmodell azoknak a tulajdonságoknak a meghatározása, amelyeknek az alkotóelemeknek meg kell felelniük, avagy az összetevők összetételének módszerei és mechanizmusai.
Az elmúlt évtizedekben a kutatók és a gyakorlati szakemberek több, különböző jellemzőkkel rendelkező komponensmodellt javasoltak. A meglévő alkatrészmodellek besorolása adott. Példák alkatrész modellekre: Enterprise JavaBeans (EJB) modell, Component Object Model (COM) modell, dotNET modell, X-MAN komponens modell, és a Common Object Request Broker Architecture (CORBA) komponens modell.
Technológiák
Üzleti objektum technológiák Newi Komponens alapú szoftver keretek meghatározott területekhez Advanced Component Framework Earth System Modeling Framework (ESMF) MASH IoT platform eszközkezeléshezMASH defines assets as people, property and information and management as monitoring, control and configuration. Presented at the 2013 IEEE IoT conference in Mountain View MASH includes a full IDE, Android client and runtime. "MASH YouTube channel" KOALA komponens modell a szórakoztató elektronika szoftverekhez kifejlesztveA component-oriented approach is an ideal way to handle the diversity of software in consumer electronics. The Koala model, used for embedded software in TV sets, allows late binding of reusable components with no additional overhead.Component model for embedded devices like TV developed by Philips based on paper by van Ommering, R.: Koala, a Component Model for Consumer Electronics Product Software React (JavaScript könyvtár) Szoftverkommunikációs architektúra (JTRS SCA) Komponens-orientált programozás Az OSGi Service Platform által meghatározott csomagok Komponens webplatform moduláris js, css és egyéb eszközök számára Komponens objektum modell (OCX / ActiveX / COM) és a DCOM a Microsoft-tól TASCS – SciDAC Technológiai Központ a fejlett tudományos komponens szoftverekhez Eiffel programozási nyelv Vállalati JavaBeans a Sun Microsystems-től (ma Oracle) Flow-alapú programozás Fractal komponens modell az ObjectWeb-től MidCOM komponens keretrendszer a Midgard és a PHP számára Oberon, Component Pascal és BlackBox Component Builder rCOS módszer az alkatrészalapú modellvezérelt tervezéshez az UNU-IIST-től SOFA összetevő rendszer az ObjectWeb-től A System. ComponentModel névtér a Microsoft dotNET-ben Az Unity által kifejlesztett Unity Technologies Az Epic Games által fejlesztett Unreal Engine UNO az OpenOffice.org irodai csomagból VCL és CLX Borlandból és hasonló ingyenes LCL könyvtár. XPCOM a Mozilla Alapítványtól Összetett dokumentum technológiák Aktív dokumentumok az Oberon Systemben és a BlackBox Component Builderben A KParts, a KDE összetett dokumentum technológiája Objektumok összekapcsolása és beágyazása (OLE) OpenDoc Elosztott számítástechnikai szoftverek .dotNET Remoting a Microsoft-tól 9P elosztott protokoll a Plan 9-hoz kifejlesztve, amelyet az Inferno és más rendszerek használnak. CORBA és a CORBA Component Model az Object Management Group-tól D-Bus a freedesktop.org szervezet részéről A DCOM és a COM (és a COM +) újabb verziói a Microsoft-tól DSOM és SOM az IBM-től (már selejtezve) Ice a ZeroC-től Java EE a Sun-tól Kompics a SICS-től Univerzális hálózati objektumok (UNO) az OpenOffice.org webhelyről Webszolgáltatások REST Zope a Zope Corporation-től AXCIOMA (az elosztott, valós idejű és beágyazott rendszerek komponens kerete) a Remedy IT részéről COHORTE a platformok közötti futásideje robusztus és megbízható elosztott szolgáltatásorientált komponensalapú alkalmazások futtatásához és kezeléséhez, az isandlaTech-től DX-MAN szervizmodell