Основу многих современных систем моделирования (как и САПР) составляют пакеты прикладных программ (ППП). Комплексные программные системы могут объединять несколько ППП.

Пакеты прикладных программ могут быть:
• объектно-зависимыми, проблемно-ориентированными на определенную предметную область;
• объектно-независимыми, методоориентированными (инвариантными), т.е. могут использоваться при моделировании и решении задач из различных предметных областей.
Применение таких методоориентированных ППП часто менее эффективно:
• в них не учитывается специфика задач конкретной предметной области;
• требуется достаточно высокая математическая подготовка пользователя, так как при использовании объектно-независимых ППП необходима специальная предварительная подготовка задачи в соответствии с особенностями применяемого метода.

Что же из себя представляет проблемно-ориентированный ППП в общем случае?
Проблемно-ориентированный ППП — это комплекс специально-организованных программных средств, ориентированных на решение задач в определенной предметной области науки и техники, отличающийся следующими главными чертами:

1) наличие проблемно-ориентированного языка программирования (ПОЯ) с непроцедурной формой задания на уровне, близком к естественному профессиональному языку данной предметной области. ПОЯ не требует от пользователя специальных знаний в области алгоритмического программирования;

2) выполнение функции организации и планирования вычислительного процесса — организация правильной последовательности выполнения программных модулей, обмен данными между ними, ввод-вывод и хранение информации, т.е. наличие достаточно универсального монитора.

Представим обобщенную архитектуру ППП, отражающую ее внутреннюю организацию и способ общения с пользователем (рис. 1).

Рис. 1. Обобщенная архитектура пакета прикладных программ

В архитектуре пакета можно выделить ядро пакета (это неизменная часть пакета), составляющая системное обеспечение ППП, и изменяющуюся для предметных областей — проблемное обеспечение. Ядро (монитор) пакета развивает возможности операционных систем ЭВМ для решения конкретных прикладных задач.

Архитектура ППП включает следующие основные составляющие:
• монитор пакета (управляющая программа);
• библиотека программных модулей (база данных);
• процессор с входного языка;
• сервисные средства пакета.

Монитор пакета — специальная программа, которая по формулировке задачи на входном языке автоматически организует вызов модулей в нужной последовательности, обеспечивает обмен информацией между ними и управляет процессом решения задач. Ввод модели на входном языке можно осуществлять в произвольном порядке.

Анализатор обеспечивает трансляцию исходного текста задания на входном языке пакета во внутренний язык ЭВМ. Другими словами осуществляется расшифровка конструкций, сформулированных на входном языке пакета и извлечение из них информации для организации работы всех остальных программ пакета.

Планировщик вычислительного процесса определяет правильную необходимую цепочку, последовательность обработки модулей для выполнения соответствующих инструкций.

Загрузчик-исполнитель последовательно загружает и выполняет все программные модули по вычислительной схеме планировщика.

Пакет прикладных программ сопровождается документацией, необходимой для его установки и эксплуатации. Документация включает:
1) паспорт и пояснительную записку (составные части и характеристику пакета — назначение и область применения);
2) инструкцию по вводу ППП в эксплуатацию, т.е. инструкцию по генерации пакета на ЭВМ;
3) инструкцию для пользователя по подготовке исходных данных и инструкцию по работе с пакетом для решения задач;
4) документацию на модули.

Модуль системы — это программа, реализующая законченную функцию, ориентированная на его совместное использование с другими модулями и в соответствии с этим оформленная.

Модуль — программная единица, для создания которой нужен минимум знаний о других программных единицах, программных модулях. Перекомпоновка и замена модулей не должна вызывать перекомпоновку пакета. Значит центральная концепция модульности — независимость.

И, наконец, модуль должен:
1) реализовать требуемую функцию, т.е. иметь один выход;
2) возвращать управление тому, кто его вызвал, и иметь возможность обращаться к другим модулям;
3) быть сравнительно небольшим — считается, что в среднем длина исходного текста модуля не должна превышать одну страницу распечатки АЦПУ (или от нескольких десятков до нескольких сотен операторов языка программирования).

Представим документы, сопровождающие модуль:
1) название, назначение, область применения (идентификатор модуля);
2) алгоритм, реализованный в модуле;
3) текст программы;
4) контрольный (текстовый) пример.

Модули можно разрабатывать параллельно и независимо друг от друга, их легко менять, включать при адаптации к новым условиям. Но эти преимущества тем ощутимее, чем слабее так называемое сцепление модулей.

Под сцеплением понимается теснота связей модулей друг с другом. Другими словами, межмодульные связи, их взаимозависимость должна быть минимально возможной. Минимальное сцепление обеспечивается при делении модулей по функциональному признаку.

Наличие сильного сцепления между модулями системы есть основание для их объединения в единый модуль.

Итак, ППП позволяет хранить относительно простые готовые программы (модули) и автоматически собирать из них сложные программы, подобно тому, как из унифицированных деталей строятся разнообразные архитектурные сооружения.

Комментарии запрещены.