Пакеты прикладных программ. Введение.

Автоматизацией прикладной деятельности называется весь комплекс работ, связанных с разработкой алгоритмов и программ решения задач, а также с подготовкой и проведением расчетов ПО – это совокупность прикладных задач и используемых при этом методов. Дисциплина работы – система правил, соглашений, технологических приёмов и подходов, принятых при разработке, отладке и эксплуатации программ. В структуре ППП можно выделить 3 основные компоненты:

1) Функциональное наполнение (отражает специфику ПО);

2) Язык заданий (средства общения пользователя с пакетом);

3) Системное наполнение (совокупность программ, обеспечивающих взаимодействие пользователя с пакетом и выполнение заданий).

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

 

Функциональное наполнение (ФН)

ФН отражает специфику ПО пакета и представляет собой совокупность модулей. Язык (языки) программирования, на котором написаны эти модули, называется базовым языком пакета. В ФН можно выделить 2 части:

1)Функциональная (в неё включаются программные модули). Представляет собой активную часть ФН, используемую при планировании вычислений, синтезе программ и др. подобных действиях.

2)Информационная (к ней относятся данные, документы, справочники и т.п.).

Существуют качественные различия между библиотеками подпрограмм и функций и ФН пакета. При разработке библиотеки преследуется цель обеспечить общими «вычислительными услугами» смежные ПО. Весь объем конкретной прикладной деятельности не рассматривается. Специфические задачи каждой из смежных областей не отражаются в библиотеке. При разработке ФН пакета преследуется цель достижения полного охвата конкретной ПО, другими словами, состав ФН должен обеспечивать решение любой прикладной задачи из числа рассматриваемых.

Разработка ФН начинается с модульного анализа ПО. Целью модульного анализа является построение такого множества простых алгоритмов, суперпозицией которых могут получаться алгоритмы решения всех задач, рассматриваемых в данной ПО. Такое множество простых алгоритмов называется алгоритмическим базисом. С точки зрения функциональной нагрузки элементы алгоритмического базиса могут быть:

1 математическими (описывают реализации отдельных математических методов);

2 физическими или прикладными (соответствуют задачам конкретной ПО).

 

Модуляризация.

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

1) экономия записи. В модули помещаются повторяющие части программы (как функции в Си);

2) сокращение суммарного времени трансляции. Выделяются модули, допускающие автономную трансляцию. Написание программы в целом можно распределить между несколькими исполнителями;

3) удобство редактирования текста программ (1-2 страниц). Выделяются модули, логику которых можно целиком показать на экране;

4) экономия оперативной памяти. Принцип Оверлея: выделяются сегменты программы в виде отдельных модулей, которые сменяют друг друга в опер. памяти во время выполнения программы;

5) систематизация и упрощение разработки.

Рекомендуется выделять в качестве модулей функционально независимые части программы. Желательно чтобы каждый модуль выполнял одну функцию. Такой подход существенно облегчает дальнейшее развитие программы, так как локализуются вносимые в неё изменения. Этот мотив также называют функциональным подходом к модуляризации. Первые четыре относятся к технической модуляризации.

 

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

Регламент модуляризации.

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

Регламент включает требования обеспечивающие совместимость модулей в рамках расчётных программ. Совместимость модулей по инф. и управлению. Программные реализации функционального наполнения осущ-ся адоптацией уже имеющегося программного материала. При этом модули нередко оказываются не стандартизованными по взаимодействию. Модули не способные к непосредственному взаимодействию наз. квази-модулями. Стандартизация допускает 2 решения:

1. Внутренняя модуляризация. Заново переписать все квази-модули в соответствии с регламентом модуляризации. Здесь совместимость достигается соблюдением всех требований регламента в период их разработки (неприемлемо по причине трудоёмкости).

2. Вешняя модуляризация. Доработка квази-модулей. Исходные тексты квази-модулей не изменяются. Здесь опять 2 подхода:

-1. основан на дополнении сопроводительной записи ко всякому квази-модулю (наз. паспорт или заголовок). В нём содержится формальное описание, достаточное для обеспечения совместимости. Требуется разработка соответствующих системных средств и спец языка описания заголовков (разработка оправдана, если адаптируемые квази-модули должны сочетаться в многочисленных разнообразных конфигурациях).

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

 

Язык Заданий

Является средством общения пользователя с пакетом. Он позволяет описывать последовательность выполнения различных операций, необходимых для решения задачи или постановку задачи по которой эта последовательность строится автоматически. При разработке языков заданий используют 3 подхода:

1.Для небольших пакетов, ориентированных на пользователей-программистов. Язык заданий в этом случае совпадает с базовым языком программирования. Проблемная ориентация достигается написанием функций, подпрограмм, а также использованием соответствующей мнемоники. При идентификации переменных, составлении функций, подпрограмм такой подход не даёт особых преимуществ пользователю при составлении задания по сравнению с обычным языком прог-я, но не требует от разработчика значительной специальной системной поддержки.

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

3.Основан на разработке специализированного проблемно ориентированного языка задания. Такие языки не связаны ни с каким языком прог-я. Ориентация на ламеров. Обычно основан на лексике предметной области и имеет простой синтаксис. Стремятся обеспечить высокую непроцедурность этого языка т.е. большая часть задания описывает постановку задачи а не её реализацию. Такая реализация требует развитых программных средств.

 

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

1.основан на идеи языка ядра – общая часть языков задания всех пакетов создаваемых такой Инструментально Базисной Системы (ИБС). В нём помимо средств, отражающих то общее что есть в приложениях содержаться средства расширения. При этом подходе язык задания конкретного пакета создаётся путём дополнения языка ядра новыми понятиями и конструкциями, которые учитывают специфику предложения.

2.язык ИБС является базовым метаязыком, т.е. языком описания языков. Используя такой метаязык, определяется синтаксис и семантика языка заданий конкретного пакета. Сам метаязык не входит как часть в создаваемый язык заданий.