Sovelluspaketti (lyhennetty PPP, englanninkielinen sovelluspaketti [1] ) tai ohjelmistopaketti on joukko toisiinsa liittyviä moduuleja , jotka on suunniteltu ratkaisemaan tietyn aihealueen tietyn luokan ongelmia . PPP:n merkityksen mukaan olisi oikeampaa kutsua sitä moduulipaketiksi vakiintuneen ohjelmistopaketin sijaan. Se eroaa kirjastosta siinä, että kirjaston luomisen tavoitteena ei ole täysin kattaa aihealueen tarpeita, koska sovellus voi käyttää moduuleja useista kirjastoista. Ohjelmistopakettia koskevat vaatimukset ovat tiukemmat: ongelman ratkaisevan sovelluksen tulee käyttää vain paketin moduuleja, ja tietyn sovelluksen luominen voi olla muidenkin kuin ohjelmoijien käytettävissä [2] .
Pakettilähestymistapaa voidaan verrata "universaalin" ohjelman luomiseen. Tällainen ohjelma voi osallistua erilaisten ongelmien ratkaisemiseen, kun taas pakettilähestymistavassa paketin useita moduuleja yhdistetään yhden ongelman ratkaisemiseksi. Ero saattaa tuntua pieneltä (ohjelmistopaketista on mahdollista tehdä "yleinen" ohjelma lisäämällä ohjauslisäosa tai päinvastoin käyttää "universaalin" ohjelman joitain moduuleja PPP:nä). Arkkitehtonisesta näkökulmasta PPP on kuitenkin kätevämpi laajentaa ja muokata, koska PPP:tä voidaan kehittää lisäämällä uusia moduuleja, jotka eivät vaikuta aiemmin vianjäljitettyjen moduulien suorituskykyyn [2] .
Helpoin tapa havainnollistaa erälähestymistapaa on Unix-liukuhihna . Unix-järjestelmä sisältää suuren määrän pieniä ohjelmia, jotka suorittavat tietyn toiminnon. Ketjuun kuuluvat ohjelmat pystyvät prosessoimaan joitain tietoja työn alla [3] .
Joissakin tapauksissa ketjulähestymistapa voidaan automatisoida antamalla ketjun rakentaminen paketin järjestelmätyökaluille [3] . Ketjun luomisen numeratiivisen mekanismin (ketjuun sisältyvien moduulien eksplisiittinen osoitus) lisäksi on mahdollista assosiaatiomekanismi , jossa moduuli sisällytetään järjestelmän keinoin generoituun ohjelmaan jonkin attribuutin perusteella. Siinä tapauksessa, että käyttäjä asettaa tunnetut ja halutut arvot, järjestelmän avulla tapahtuvaa ketjun palauttamista kutsutaan automaattiseksi laskennan suunnitteluksi . Joistakin eduista ja yksittäisistä onnistumisista (PRIZ- ja SPOR-järjestelmät) huolimatta automaattinen laskennan ajoitus ei ole saanut massakehitystä ketjun köyhyyden vuoksi konfigurointiohjeena [4] .
Ohjelmointikokemuksen kertyessä miltä tahansa aihealueelta ajan myötä kehitetään ideoita järkevästä modulaarisesta organisaatiosta, kertyy joukko moduuleja, jotka eivät muutu paljon siirryttäessä ohjelmaversiosta toiseen, ja siellä on myös pysyviä paikkoja. vaihdettaville moduuleille . Tuloksena syntyy sovellusarkkitehtuuri, joka koostuu pysyvästä komponentista - kehyksestä , jossa on paikat vaihdettavien moduulien sijoittamista varten [5] . Tietenkin pistorasioilla ja plug-in-moduuleilla on sovitut tekniset tiedot .
Tietyn kokoonpanon määrittäminen käyttäjälle on yksinkertaistettu. Kehyspesät heijastavat ratkaistavan ongelman ominaisuuksia, ja vaihdettavat moduulit ovat näiden ominaisuuksien sallittuja arvoja [5] .
Esimerkiksi kehyksessä, jossa on kaksi varianttipesää , on mahdollista kuvata laskentakonfiguraatiota koskematta ongelmaalgoritmiin: Материал ← Алюминий, Точность ← Двойная.
Toisin kuin ketjulähestymistapa, kehyslähestymistapa antaa enemmän vapautta generoidun ohjelman rakenteen suunnittelussa, mikä on suositeltavampaa useimmille aihealueille [5] .
Seuraavat PPP-tyypit voidaan erottaa [6] :