Az alkalmazáscsomag (röv. PPP, angol alkalmazáscsomag [1] ) vagy szoftvercsomag egymáshoz kapcsolódó modulok összessége, amelyek egy bizonyos témakör egy bizonyos osztályának problémáinak megoldására szolgálnak . A PPP jelentése szerint helyesebb lenne modulcsomagnak nevezni a bevett szoftvercsomag kifejezés helyett. Abban különbözik a könyvtártól , hogy a könyvtár létrehozásának célja nem a tárgykör igényeinek teljes körű lefedése, hiszen egy alkalmazás több könyvtár modulját is felhasználhatja. A szoftvercsomaggal szemben támasztott követelmények szigorúbbak: egy problémamegoldó alkalmazásnak csak a csomag moduljait kell használnia, és egy adott alkalmazás létrehozása a nem programozók számára is elérhető [2] .
A csomagos megközelítés szembeállítható egy "univerzális" program létrehozásával. Egy ilyen program különféle problémák megoldásában vehet részt, míg a csomagos megközelítésben a csomag több modulját kombinálják egy probléma megoldására. A különbség kicsinek tűnhet (lehetséges, hogy egy szoftvercsomagból „univerzális” programot készítsünk egy vezérlő kiegészítő hozzáadásával, vagy fordítva, az „univerzális” program egyes moduljait PPP-ként használjuk). Építészeti szempontból azonban a PPP kényelmesebb a bővítéshez és módosításhoz, mivel a PPP fejlesztése olyan új modulok hozzáadásával valósulhat meg, amelyek nem befolyásolják a korábban hibakereső modulok teljesítményét [2] .
A kötegelt megközelítést a legegyszerűbben a Unix folyamattal szemléltethetjük . Egy Unix rendszer nagyszámú kis programot tartalmaz, amelyek meghatározott funkciót látnak el. A folyamatban lévő láncba tartozó programok bizonyos adatokat feldolgozhatnak [3] .
A láncszemlélet bizonyos esetekben automatizálható, ha a lánc felépítését a csomag rendszereszközeire bízzuk [3] . A láncot létrehozó enumerációs mechanizmuson (a láncban szereplő modulok explicit hozzárendelése) mellett lehetséges egy asszociációs mechanizmus, amelyben a modul valamilyen attribútum alapján rendszereszközzel kerül be a generált programba. Abban az esetben, ha a felhasználó beállítja az ismert és kívánt értékeket, a lánc rendszer segítségével történő helyreállítását automatikus számítási tervezésnek nevezzük . Bizonyos előnyök és egyéni sikerek (PRIZ és SPOR rendszerek) ellenére az automatikus számítási ütemezés nem kapott tömeges fejlődést a lánc szegénysége miatt, mint konfigurációs irányelv [4] .
A programozási tapasztalatok bármely szakterületen való felhalmozásával idővel kialakulnak a racionális moduláris felépítéssel kapcsolatos ötletek, felhalmozódik egy olyan modulkészlet, amely nem sokat változik a programok egyik verziójáról a másikra való áttéréskor, és vannak állandó helyek is. cserélhető modulokhoz . Ennek eredményeként egy alkalmazásarchitektúra jön létre, amely egy állandó komponensből áll - egy keretből , amely nyílásokkal rendelkezik a cserélhető modulok elhelyezésére [5] . Természetesen az aljzatok és a beépülő modulok specifikációi megegyeztek .
Egy konkrét konfiguráció beállítása a felhasználó számára leegyszerűsödik. A keretfészkek a megoldandó probléma jellemzőit tükrözik, a cserélhető modulok pedig e jellemzők megengedett értékei [5] .
Például egy két variánsfészkes keretben lehetőség van a számítási konfiguráció leírására anélkül, hogy a probléma algoritmusát érintené: Материал ← Алюминий, Точность ← Двойная.
A láncszemléletű megközelítéssel ellentétben a keretmegközelítés nagyobb szabadságot ad a generált program szerkezetének megtervezésében, ami a legtöbb tantárgy esetében előnyös [5] .
A PPP következő típusai különböztethetők meg [6] :