Know-how, előadás, komponens technológiák és terjesztett
Összefoglaló: Az összetett szoftverfejlesztési technológiák és az összetevő koncepciójának főbb koncepcióit tekintjük. Leírja az általános elvek fejlesztése elosztott szoftver és a szervezet kölcsönhatása komponensek távoli eljárás hívás és a tranzakciókat.
Az összetett technológiák alapfogalmai
A szoftverkomponens (szoftverkomponens) koncepciója a modern szoftverfejlesztés kulcsa. Ez a kifejezés több különböző dologot jelent, gyakran nem tisztázva az egyes konkrét esetekben rejlő jelentést.
- Ha ez egy szoftver architektúra (vagy szoftverfejlesztője), az összetevő ugyanazt jelenti, mint amit gyakran neveznek szoftver modulnak. Ez eléggé önkényes és elvont eleme a rendszer szerkezetének, melyet határozottan elosztottak a környezetben. egyes részfeladatok megoldása a rendszer közös feladatai keretében, és egy adott felületen átjárva a környezetet. Ebben a koncepcióban ezt a fogalmat használják az építészeti elem vagy az építészeti alkotóelem fogalma.
- Az UML-ben található komponens-diagramok gyakran ábrázolják azokat a komponenseket, amelyek az összeszerelés és a konfiguráció egységei - egyes nyelvű kódokkal rendelkező fájlok, bináris fájlok és a rendszereket alkotó bármely dokumentum. Néha ugyanazon a helyen vannak olyan komponensek, amelyek a rendszer kiépítésének egységei, ezek a komponensek már a harmadik, a következő értelemben.
- A telepítési komponensek azok a blokkok, amelyekből az összetevő szoftver épül. Ugyanazok az összetevők értendők az összetett technológiákról, komponensalapú vagy komponensalapú szoftverfejlesztésről, JavaBeans összetevőkről. EJB. CORBA, ActiveX, VBA, COM, DCOM. Net, webes szolgáltatások, valamint a tanfolyam címében említett komponens-megközelítés. Szerint [1]. egy ilyen összetevő egy olyan szoftverrendszer strukturális egysége, amely jól definiált interfésszel rendelkezik. amely teljes mértékben leírja a környezettől való függőségét. Az ilyen komponensek egymástól függetlenül szállíthatók, vagy nem szállíthatók, hozzáadhatók vagy eltávolíthatók valamely rendszerből, beleértve a más beszállítók rendszerét is.
Az ilyen fogalmak közötti különbség, bár elég finom, még mindig a szöveg vagy a beszélgető fél súlyos félreértését eredményezheti egyes esetekben.
Az építészeti alkotóelem vagy modul meghatározása a rendszer egészének szerkezeti elemeinek elszigetelését és a kisebb alproblémákkal megoldandó feladatok bontását hangsúlyozza. Az ilyen összetevők információs tárolóegységek (fájlok, adatbázisok stb.) Formájában történő ábrázolása nem számít. Az interfész, bár meghatározott, finomítható és kibővíthető a fejlesztési folyamatban.
A szerelési összetevő és a konfigurációvezérlés koncepciója kapcsolódik a rendszer szerkezeti elemeihez, amelyekkel foglalkoznia kell az összeszereléssel és a konfigurációkezeléssel foglalkozó eszközökkel. valamint az ilyen eszközökkel dolgozó embereket. Ezeket a komponenseket nem lehet meghatározni a rendszer más hasonló elemeivel való kapcsolódási pontok között.
Ebben az előadásban és a következők többségében a harmadik értelemben vett elemekkel foglalkozunk. Ez a koncepció számos szempontot tartalmaz:
- Ebben az értelemben egy komponens egy olyan, kifejezetten strukturált egység, amelynek egy jól definiált interfésze van. Szigorúbb követelményeket támaszt az interfész definíciójának tisztázása érdekében. mint egy építészeti elem. Az interfészen belül feltétlenül meg kell adni a környezeti függőségeket. Az egyik komponens több interfésszel is rendelkezhet. több különböző szerepet játszik a rendszerben.
Nem csak a műveletek aláírása fontos a komponens felületének leírásában. amely vele együtt végrehajtható. Fontos lesz továbbá, hogy milyen egyéb elemeket használhat a munkája során, továbbá milyen korlátozásokkal kell a bemeneti műveleti adatokat kielégíteni, és milyen tulajdonságokat kell elvégezni a munkájuk eredményeihez.
Ezek a korlátozások az úgynevezett interfész-szerződés vagy az alkatrész szoftvercsomagja. A komponens interfész olyan műveletek csoportját tartalmazza, amelyeket bármely olyan összetevővel fel lehet hívni, amely végrehajtja ezt az interfészt. és olyan műveletek, amelyeket ez az összetevő más összetevőkre adott válaszként okozhat. A csatolószerkezet maga (vagy az általa használt) minden egyes művelete számára meghatározza a hívás előfeltételét és utófeltételét. A művelet előfeltételét akkor kell végrehajtani, amikor hívják, különben az eredmények helytállósága nem garantált. Ha ezt a műveletet az összetevő hívja, akkor az előfeltételeket az ügyfél hívja meg. Ha ezt a műveletet egy másik komponens egyik komponensének nevezi, maga vállalja, hogy eleget tesz ennek a feltételnek. A posztkondícióval ellentétes az igaz - a komponens által meghívott művelet utáni feltételét hívás után kell végrehajtani, és ez az alkotó felelőssége. Egy művelet utáni állapota határozza meg, hogy az eredményeket helyesnek tartják-e. A komponens által okozott műveletek tekintetében a posztfeltételek végrehajtását azoknak az összetevőknek kell biztosítaniuk, amelyekről hívják őket, és a hívó komponens a munkájukra támaszkodhat.
Az interfész megvalósításakor a működés előfeltételei gyengülhetnek, és a posztondíciók - csak erősebbé válnak. Ez azt jelenti, hogy ennek a műveletnek a végrehajtásával egyes komponensek az előfeltételhez szükséges szélesebb bemeneti adatbázissal valósíthatók meg, és szigorúbb korlátozásokat is eredményezhetnek, mint amennyit a postcondition megkövetel. Azonban a külső összetevők nem támaszkodhatnak erre mindaddig, amíg a forrásfelületen dolgoznak. - a végrehajtás megváltozhat. Hasonlóképpen, ha a komponens interfésze a rendszerben lévő más komponensek jelenlétét igényli egy bizonyos műveletsorral, akkor ez nem jelenti azt, hogy ennek a felületnek a végrehajtása ténylegesen e műveleteket okozza.
Ideális esetben egy ilyen komponens hozzáadásával vagy teljesen helyettesíthető ugyanazon interfészek egy másik megvalósításával közvetlenül a rendszer működése közben, anélkül, hogy leállítaná. Bár az összetevők nem minden elemével rendelkeznek, az elérhetőség nagyon kívánatos.
Mindez azt jelenti, hogy egy ilyen alkatrésznek minden olyan környezetben működőképesnek kell lennie, ahol a működéséhez szükséges egyéb alkatrészek rendelkezésre állnak. Ehhez egy bizonyos infrastruktúra szükséges, amely lehetővé teszi az összetevők számára, hogy megtalálják egymást és kölcsönhatásba lépjenek bizonyos szabályok szerint.
Számos komponens modell létezik. Helyesen kölcsönhatásba léphetnek egymással csak az ugyanabban a modellben épített komponensek, mivel az összetett modell meghatározza a "nyelvet", amelyben az összetevők egymással kommunikálhatnak.
Az összetevő modell mellett. az összetevők működtetéséhez bizonyos alapvető szolgáltatásokra van szükség. Például az összetevőknek képesnek kell lenniük arra, hogy megtalálják egymást egy olyan környezetben, amely több gépre osztható. A komponenseknek képesnek kell lenniük egymásnak átadni az adatokat, méghozzá, talán a hálózati interakciók segítségével, de az egyes összetevők önmagukban történő végrehajtása nem függhet az alkalmazott kommunikáció típusától és az interakciós partnerek helyétől. Egy ilyen alapvető készlet. a legtöbb szervizösszetevő működéséhez szükséges, az általuk támogatott komponensmodellel együtt komponens-keret (vagy komponens keret). Az ismert komponenskörnyezetek példái a J2EE különböző megvalósításai. NET, CORBA. Önmagukban J2EE. A NET és a CORBA az alkatrészmodellek és az alapszolgáltatások specifikációi. amelyeket végrehajtásukkal támogatni kell.
Az összetevők környezetében működő összetevők. eltérő módon hajtja végre ugyanazt az összetevő modellt és az alapvető szolgáltatásokra vonatkozó előírásokat. képesnek kell lennie arra, hogy szabadon működjön. A gyakorlatban sajnos ez nem minden esetben lehetséges, de az ilyen kölcsönhatások bármilyen akadályát súlyosnak tekintik, korai megoldási probléma mellett.
Az összetevők, azok kapcsolódási pontjainak kapcsolata. a komponensmodell és az összetevõkörnyezet képviselhetõ, amint az a 2. ábrán látható. 12.1.
- Az osztály nem csak a végrehajtott interfészek halmazát határozza meg. hanem azok végrehajtását is, mivel tartalmazza a meghatározandó műveletek kódját. Az összetevő szerződés, leggyakrabban, nem oldja meg interfészeinek megvalósítását.
- Az osztály egy adott programozási nyelven íródott. Az összetevő nem kötődik egy adott nyelvhez, hacsak természetesen nem szükséges az összetevő modellje - a komponens modell az összetevők számára ugyanaz, mint az osztályok esetében a programozási nyelv.
- Általában az összetevő egy nagyobb szerkezeti egység, mint az osztály. Egy komponens végrehajtása gyakran szorosan kapcsolódó osztályokból áll.
kattints a kép nagyításához
Ábra. 12.1. Az összetevő szoftver fő elemei
Meg kell jegyezni, hogy bár a piac lényegében egy hosszú idő, és alkatrész kifejlesztett technológiák közel 20 éve, a komponensek piac fejlődik elég lassan. Az alkatrész-beszállítók csak egyes vállalatok szorosan kapcsolódnak az adott összetevők környezetének fejlesztőihez. nem pedig az egyéni és vállalati fejlesztők széles közösségének, mint a születésük során képzelt alkotóelemek alkotóinak.
Nyilvánvalóan az egyik fő tényező, amely gátolja a piac fejlődését, az a "technológiai verseny" a fő komponensek szállítói között. Ennek következménye a fejlődésük hiánya. Az új verziók túl gyakran jelennek meg, és gyakran új verziók kiadásával, az összetevők változásának elemei. Tehát a következő verzióhoz tartozó komponensek fejlesztésekor számos más szabályt kell követni, és a régi komponenseket alig lehet újra felhasználni.