Введение
Создание «дружественного интерфейса» для конечного пользователя ЭВМ – одна из наиболее приоритетных проблем информатики. Попытки ее радикального решения, особенно интенсивные в 80-х годах, закончились фактически неудачей. Последняя из них – широко известный японский проект «ЭВМ V-го поколения», главной целью которого была разработка средств общения с компьютером, максимально близких к естественному языку. Однако отсутствие каких-либо официальных сообщений (проект должен был завершиться в 1995-1996г.г.) наводит на мысль об отсутствии значительных результатов этого предприятия.
Практика широкого использования средств вычислительной техники пошла по пути разработки специализированных систем программирования. Наиболее полно этот подход реализован в концепции так называемых пакетов прикладных программ (ППП), являющихся в настоящее время и, вероятно, в обозримом будущем оптимальным компромиссом между достижимой степенью «дружественности» интерфейса и сложностью его реализации. ППП – это специализированное программное обеспечение (ПО), представляющее собой комплекс взаимосвязанных прикладных программ и средств системного обеспечения (прикладных и языковых), предназначенное для автоматизации решения определенного класса задач в какой-либо предметной области.
Пакетная проблематика весьма обширна. Ограниченность времени, тем более рамки конспекта, остро ставят вопросы отбора соответствующего учебного материала. Поскольку данный конспект лекций предназначен прежде всего для студентов групп ФБ и ФБИ, то кроме обязательных основ архитектуры и структуры ППП, а также технологии разработки ПО, рассмотрены характерные особенности постановок и алгоритмизации задач в экономике. Сюда относятся: исследование корректности используемых технико-экономических показателей, осуществляемое методом теории размерностей; оценка границ обобщения постановок задач и соответствующих алгоритмов их решения, столь актуальная для пакетной реализации; наконец, оценка экономической эффективности проекта ППП.
Этот материал представляет интерес не только для студентов, но и для специалистов в области информационных систем в экономике.
Глава I. СТРУКТУРА И АРХИТЕКТУРА ППП
Как уже было отмечено выше, одной из основных форм специализированного программного обеспечения являются ППП. Существует много различных определений этого понятия, характеризующих его с разных точек зрения. Мы будем исходить из трактовки ППП, предложенной во Введении.
Принято различать два аспекта ППП – его структуру и архитектуру. Первый – это устройство пакета с точки зрения системного программиста, второй – это то, что открыто и доступно пользователю. Ясно, данные аспекты взаимосвязаны, однако опыт показал не только желательность, но и необходимость при документировании ППП четко разделять эти моменты. Руководство пользователя не должно обременять его ненужными деталями системного программирования, которые должны быть скрыты.
1.1. Структура ППП
В структуре ППП можно выделить три основных компоненты: функциональное наполнение, язык заданий и системное наполнение (рис.1).
 |
Функциональное наполнение отражает специфику предметной области пакета и представляет собой совокупность модулей. Под модулем здесь понимается конструктивный элемент, используемый на различных стадиях функционирования пакета. Состав функционального наполнения пакета, его мощность или полнота охвата («покрытия») им предметной области отражает объем прикладных знаний, заложенных в пакет, т.е. потенциальный уровень тематической квалификации пакета.
Язык заданий пакета является средством общения пользователя с пакетом. Он позволяет описывать последовательность выполнения различных операций, обеспечивающих решение задачи или постановку задачи, по которой эта последовательность строится автоматически.
Системное наполнение представляет собой совокупность программ, которые обеспечивают выполнение задания и взаимодействие пользователя с пакетом, адекватное дисциплине работы в данной прикладной деятельности. Можно говорить, что системное наполнение организует использование потенциала знаний, заложенных в функциональное наполнение, в соответствии с возможностями, предусмотренными в языке заданий пакета. Реализация функций системного наполнения осуществляется на основе согласованного использования: а) штатных средств системного обеспечения; б) средств системного наполнения, расширяющих и сопрягающих возможности компонент штатного обеспечения и в) специальных средств системного наполнения, выполняющих управляющие, архивные и обрабатывающие процедуры с учетом специфики прикладной деятельности, охватываемой пакетом. Язык (языки), на котором пишутся программы системного наполнения, будем называть инструментальным языком пакета, в отличие от базового языка, на котором пишутся модули функционального наполнения.
1.1.1. Структура функционального наполнения
Предшественниками функционального наполнения развитого пакета являются библиотеки стандартных подпрограмм, реализующих элементарные вычислительные процедуры, а также простые тематические наборы программ для решения типовых, не связанных между собой задач (заметим, что именно такие наборы и породили термин «пакет»). При конструировании ППП функциональной модуляризации придается новое содержание: выделенные модули должны образовать алгоритмический базис пакета, достаточный для построения расчетной программы потенциально любой задачи из обслуживаемой области. На рис.2 проиллюстрировано отличие пакетного подхода к разбиению на модули от разработки обычных «универсальных»
 |
программ, где с помощью одной программы стараются охватить возможно более широкий класс задач. Главное достоинство пакетного подхода к модуляризации – возможность безболезненного развития программного фонда. Напротив, развитие «универсальной» программы всегда сопряжено с изменениями текстов написанных ранее частей программы. Вместе с тем необходимо отметить, что с пакетным подходом связана серьезная технологическая проблема – как организовать взаимодействие существующих модулей с вновь создаваемыми? Известно ее решение в рамках технологии искусственного интеллекта. С каждым модулем связывается и записывается в функциональное наполнение формальное описание его входных/выходных данных и условий его применимости, а вместо непосредственных вызовов модулей используются вызовы «по образцу», определяющие не конкретный модуль, а лишь стоящую перед ним задачу. Поэтому вновь появившийся модуль никак не воздействует на тексты модулей – своих потенциальных потребителей. Эти модули автоматически найдут его из-за соответствия его описания выставленным ими запросами. В существующих пакетах программ технология искусственного интеллекта применяется относительно редко, так как она часто приводит к значительной потере эффективности и требует от разработчиков пакета свободного владения весьма нетривиальным логическим аппаратом. В большинстве случаев, однако, удается найти более экономичное решение стоящих перед пакетом задач на основе существенно более простых программных конструкций. Действительно, во многих пакетах все расчеты ведутся по одной слабо меняющейся схеме. Ей соответствует вполне определенная структура всех формируемых пакетом расчетных программ. Многообразие проводимых расчетов здесь достигается не количеством схем счета, а многочисленными вариантами заполнения «гнезд» фиксированной программой структуры-каркаса. Например, в функциональном наполнении пакета может содержаться несколько модулей, реализующих различные методы расчета. Но в структуре программы для них предназначается единственное гнездо «Метод», в которое по указанию пользователя при формировании расчетных программ подставляется тот или иной модуль. При данном подходе, который называется каркасным, не накладывается ограничений на способы взаимодействия модулей. Однако свободой выбора способов взаимодействия разработчик пакета пользуется только на стадии проектирования каркаса программы, а в дальнейшем все модули должны программироваться в строгом соответствии с выработанными при проектировании каркаса требованиями к заполнению гнезд. Нетрудно видеть, что каркасный подход обеспечивает безболезненность развития программного фонда пакета. Появление нового модуля никак не затрагивает тексты ни его соседей по гнезду, ни вызывающих его модулей. Соседи по гнезду никогда не соседствуют в расчетных программах, а вызывающие модули программировались в рамках соглашений каркаса и потому могут с равным успехом обращаться к любой (в том числе и к новой) реализации гнезда.
Реже встречаются предметные области, в которых многообразие связей модулей по управлению удается ограничить последовательным выполнением модулей, не жертвуя при этом ни удобством составления программ, ни эффективностью их выполнения. Расчетная программа здесь представляет собой цепочку выполняемых друг за другом модулей, вследствие чего данный подход называется цепочечным. Обычно состав и порядок следования модулей в цепочке определяется некоторой внешней конструкцией, называемой планом вычислений. Но встречаются пакеты, где в ходе выполнения цепочки каждый очередной модуль сам динамически выбирает себе преемника. Популярности цепочечного подхода не в малой степени способствует то обстоятельство, что многие современные операционные системы (прежде всего UNIX) предоставляют удобные средства для его применения при организации связей между задачами. Все же основная масса крупных программных комплексов для решения вычислительных задач опирается на каркасный подход. Относительно неширокая распространенность цепочного подхода объясняется тем, что накладываемые им сильные ограничения на управляющие связи модулей влекут за собой существенные трудности при программировании.
1.1.2. Структура системного наполнения ППП
Рассмотрим более подробно эту компоненту ППП. Можно утверждать, что уже традиционными составляющими ее структуры являются (рис.3):
- резидентный монитор, осуществляющий интерфейс как между отдельными составляющими системного наполнения, так и между ними и штатным ПО;
- транслятор входных заданий, формирующий внутреннее представление задания и реализуемый обычно в виде макрогенератора или препроцессора;
- архив функционального наполнения (подсистема хранения программного материала);
- банк расчетных данных (подсистема хранения начальных и промежуточных данных, а также результатов расчетов);
- монитор организации вычислительного процесса (взаимодействия модулей по данным и управлению);
- планировщик вычислительного процессе, который определяет последовательность выполнения модулей, реализующую задания пакету;
- монитор организации интерактивного взаимодействия с пользователем.
 | |||
|
В различных пакетах эти составляющие системного наполнения получили разную степень развития (иногда просто отсутствовали), реализовывались на основе различных системных подходов и по-разному назывались (терминология в пакетной проблематике не вполне установилась). Поэтому приведенную выше структуру следует воспринимать как сводный список различных ее составляющих, а не как обязательный перечень принадлежностей типичного ППП.
1.2. Архитектура ППП
Архитектура, т.е. представляющийся пользователю «внешний» вид специализированной программной системы, определяется тем, какие задачи она может решать и какие возможности предоставляются пользователю. Ясно, что язык заданий отражает основные архитектурные решения, принятые разработчиками пакета в данной предметной области. Именно через язык заданий пользователь воспринимает и оценивает, каковы «вычислительные услуги» и насколько удобно их использование, т.е., другими словами, каков фактический уровень тематической квалификации ППП.
1.2.1. Язык заданий
Общая структура и стиль языка заданий пакета в значительной степени зависят от дисциплины работы, принятой в обслуживаемой пакетом предметной области. Можно выделить две основные (в определенном смысле противоположные) дисциплины проведения вычислений:
- активную дисциплину, предусматривающую при создании конкретных расчетных программ модификацию и настройку имеющихся модулей функционального наполнения, а также разработку новых модулей;
- пассивную дисциплину, предусматривающую проведение вычислений без модификации функционального наполнения пакета.
Последняя характерна для деятельности так называемых конечных пользователей, т.е. специалистов, которые не обязательно имеют высокий уровень подготовки в области вычислительной техники и программирования. Главная цель разработчика языка заданий пакета, обеспечивающего решение прикладных задач в режиме пассивной дисциплины, заключается в том, чтобы «спрятать» от конечного пользователя основную массу алгоритмических подробностей решения его задачи, или, другими словами, повысить уровень непроцедурности языка. Такие языки, называемые языками запросов, ориентированы обычно на формулирование содержательных постановок задач, т.е. запросов, указывающих, «что необходимо получить» без явного задания того, «как это получить». Пользователь тем самым избавляется от необходимости конкретизировать способы и средства решения задач, что позволяет радикально понизить порог требований к уровню его программистской подготовки.
Язык заданий пакета может быть реализован как в форме самостоятельного языка, так и в форме встроенного языка, т.е. расширения существующего языка программирования. Независимо от формы реализации разработчик языка стремится к тому, чтобы лексика, синтаксис и семантика языковых конструкций были бы как можно ближе к пользовательскому восприятию решаемых прикладных задач. Важно не только опираться на понятия и терминологию предметной области и свойственной ей дисциплины работы, но и наглядно отразить в языке основные рабочие акты автоматизируемой прикладной деятельности.
1.2.2. Тематическая квалификация
Повышение тематической квалификации ППП определяется здесь тем множеством прикладных задач, которые можно формулировать и решать с помощью языка запросов. По мере развития функционального наполнения пакета может расти и круг решаемых им задач, и поэтому язык запросов обычно определяется как расширяемый, т.е. допускающий включение новых запросов. Расширяемость языка может поддерживаться соответствующей инструментально базовой системой или же достигаться путем прямого расширения возможностей системного наполнения.
Наконец, тематическая квалификация пакета может быть охарактеризована уровнем «профессионализма» выдаваемых пользователю решений и рекомендаций. Например, это имеет место при использовании пакетов, моделирующих динамику сложных экономических объектов.
1.2.3. Общение пользователя с пакетом
В настоящее время это, как правило, совершенные формы диалога, позволяющие пользователю и пакету регулярно обмениваться информацией, уточняющей и направляющей работу пакета на всех этапах его функционирования. В частности, можно предоставить пользователю средства оперативного управления ходом выполнения расчетной программы, позволив ему в определенных узловых пунктах решения выбирать дальнейшее направление вычислительного процесса.
1.2.4. Сервис
Одна из важных задач сервиса охватывает функции отладки и наблюдения за процессом исполнения задания пользователя. Сюда входят, в частности, средства диагностики ошибок и выдачи сообщений, локализующих ошибки.
При работе с пакетами программ, функциональное и системное наполнение которых интенсивно развивается, возникает задача постоянного отслеживания в пользовательской документации всех вносимых в программу изменений. Для развивающихся пакетов на смену выпуску быстро устаревающих печатных руководств приходят сервисные средства оперативного документирования, отражающие текущее состояние пакета.
1.2.4. Информационное обеспечение
При реализации информационных задач обычно широко используется техника меню или гипертекста. Чаще всего это бывает необходимо для ознакомления пользователя (актуального или будущего) с возможностями пакета и/или с его текущим состоянием.