Паке́т прикладны́х програ́мм (аббр. ППП, англ. application package[1]) или паке́т програ́мм — набор взаимосвязанных модулей, предназначенных для решения задач определённого класса некоторой предметной области. По смыслу ППП было бы правильнее назвать пакетом модулей вместо устоявшегося термина пакет программ. Отличается от библиотеки тем, что создание библиотеки не ставит целью полностью покрыть нужды предметной области, так как приложение может использовать модули нескольких библиотек. Требования же к пакету программ жёстче: приложение для решения задачи должно использовать только модули пакета, а создание конкретного приложения может быть доступно непрограммистам[2].
Пакетному подходу можно противопоставить создание «универсальной» программы. Такая программа может участвовать в решении различных задач, тогда как в пакетном подходе несколько модулей пакета объединяются для решения одной задачи. Разница может показаться небольшой (из пакета программ можно, добавив управляющую надстройку, сделать «универсальную» программу, или наоборот, использовать некоторые модули «универсальной» программы в качестве ППП). Тем не менее, с точки зрения архитектуры, ППП более удобен для расширения и модификации, так как развитие ППП может происходить за счёт добавления новых модулей, не затрагивающих работоспособность ранее отлаженных модулей[2].
Проще всего проиллюстрировать пакетный подход на примере конвейера в Unix. Система Unix содержит большое количество небольших программ, выполняющих конкретную функцию. В конвейере входящие в цепочку программы могут обрабатывать некоторые данные[3].
Цепочечный подход в ряде случаев можно автоматизировать, поручив построение цепочки системным средствам пакета[3]. Помимо перечислительного механизма к созданию цепочки (явное задание входящих в цепочку модулей), возможен ассоциативный механизм, при котором модуль включается системными средствами в формируемую программу на основании некоторого атрибута. В случае, когда пользователь задаёт известные и искомые величины, восстановление цепочки средствами системы называется автоматическим планированием вычислений. Несмотря на некоторые достоинства и отдельные успехи (системы ПРИЗ и СПОРА), автоматическое планирование вычислений не получило массового развития по причине бедности цепочки как конфигурационного ориентира[4].
При накоплении опыта программирования в любой предметной области со временем вырабатывается представления о рациональной модульной организации, накапливается набор модулей, которые сильно не изменяются при переходе от одной версии программ к другой, а также находятся постоянные места для сменных модулей. В результате вырисовывается архитектура приложения, состоящая из постоянного компонента — каркаса, имеющего гнёзда для размещения сменных модулей[5]. Разумеется, гнёзда и сменные модули имеют согласованные спецификации.