En applikationspakke (forkortet PPP, engelsk applikationspakke [1] ) eller en softwarepakke er et sæt indbyrdes forbundne moduler designet til at løse problemer af en bestemt klasse af et bestemt fagområde . Ifølge betydningen af OPP ville det være mere korrekt at kalde det en pakke af moduler i stedet for den etablerede term softwarepakke. Det adskiller sig fra et bibliotek ved, at oprettelsen af et bibliotek ikke sigter mod fuldt ud at dække fagområdets behov, da en applikation kan bruge moduler fra flere biblioteker. Kravene til en softwarepakke er strengere: en applikation til at løse et problem skal kun bruge modulerne i pakken, og oprettelsen af en specifik applikation kan være tilgængelig for ikke-programmører [2] .
Pakketilgangen kan sammenlignes med oprettelsen af et "universelt" program. Et sådant program kan være med til at løse forskellige problemer, mens der i pakketilgangen kombineres flere moduler af pakken for at løse ét problem. Forskellen kan virke lille (det er muligt at lave et "universelt" program fra en softwarepakke ved at tilføje en kontroltilføjelse eller omvendt at bruge nogle moduler i det "universelle" program som PPP). Men fra et arkitektonisk synspunkt er PPP mere bekvemt til udvidelse og modifikation, da udviklingen af PPP kan ske ved at tilføje nye moduler, der ikke påvirker ydeevnen af tidligere debuggede moduler [2] .
Den nemmeste måde at illustrere batch-tilgangen på er med Unix-pipelinen . Et Unix-system indeholder et stort antal små programmer, der udfører en bestemt funktion. I pipelinen kan de programmer, der indgår i kæden, behandle nogle data [3] .
I nogle tilfælde kan kædetilgangen automatiseres ved at overlade konstruktionen af kæden til pakkens systemværktøjer [3] . Ud over den numerative mekanisme til at skabe en kæde (eksplicit tildeling af moduler inkluderet i kæden), er en associativ mekanisme mulig, hvor modulet er inkluderet af systemmidler i det genererede program baseret på en eller anden attribut. I det tilfælde, hvor brugeren indstiller de kendte og ønskede værdier, kaldes gendannelsen af kæden ved hjælp af systemet automatisk beregningsplanlægning . På trods af nogle fordele og individuelle succeser (PRIZ- og SPOR-systemer) har automatisk beregningsplanlægning ikke modtaget masseudvikling på grund af kædens fattigdom som en konfigurationsvejledning [4] .
Med akkumulering af programmeringserfaring inden for ethvert fagområde udvikles der over tid ideer om en rationel modulær organisation, et sæt moduler akkumuleres, der ikke ændrer sig meget, når man flytter fra en version af programmer til en anden, og der er også faste pladser til udskiftelige moduler . Som et resultat opstår der en applikationsarkitektur, bestående af en permanent komponent - en ramme , der har slots til placering af udskiftelige moduler [5] . Naturligvis har stikkontakter og plug-in moduler aftalte specifikationer .
Indstilling af en specifik konfiguration for brugeren er forenklet. Frame nests er en afspejling af egenskaberne ved det problem, der skal løses, og udskiftelige moduler er de tilladte værdier for disse egenskaber [5] .
For eksempel i en ramme med to varianter er det muligt at beskrive beregningskonfigurationen uden at røre ved problemalgoritmen: Материал ← Алюминий, Точность ← Двойная.
I modsætning til kædetilgangen giver rammetilgangen mere frihed til at designe strukturen af det genererede program, hvilket er at foretrække for de fleste fagområder [5] .
Der kan skelnes mellem følgende typer OPP [6] :