Создание «дружественного интерфейса» для конечного пользователя ЭВМ – одна из наиболее приоритетных проблем информатики. Попытки ее радикального решения, особенно интенсивные в 80-х годах, закончились фактически неудачей. Последняя из них – широко известный японский проект «ЭВМ V-го поколения», главной целью которого была разработка средств общения с компьютером, максимально близких к естественному языку. Однако отсутствие каких-либо официальных сообщений (проект должен был завершиться в 1995-1996г.г.) наводит на мысль об отсутствии значительных результатов этого предприятия.
Практика широкого использования средств вычислительной техники пошла по пути разработки специализированных систем программирования. Наиболее полно этот подход реализован в концепции так называемых пакетов прикладных программ (ППП), являющихся в настоящее время и, вероятно, в обозримом будущем оптимальным компромиссом между достижимой степенью «дружественности» интерфейса и сложностью его реализации. ППП – это специализированное программное обеспечение (ПО), представляющее собой комплекс взаимосвязанных прикладных программ и средств системного обеспечения (прикладных и языковых), предназначенное для автоматизации решения определенного класса задач в какой-либо предметной области.
Пакет прикладных программ Компьютерные мультимедийные возможности
Пакетная проблематика весьма обширна. Ограниченность времени, тем более рамки конспекта, остро ставят вопросы отбора соответствующего учебного материала. Поскольку данный конспект лекций предназначен прежде всего для студентов групп ФБ и ФБИ, то кроме обязательных основ архитектуры и структуры ППП, а также технологии разработки ПО, рассмотрены характерные особенности постановок и алгоритмизации задач в экономике. Сюда относятся: исследование корректности используемых технико-экономических показателей, осуществляемое методом теории размерностей; оценка границ обобщения постановок задач и соответствующих алгоритмов их решения, столь актуальная для пакетной реализации; наконец, оценка экономической эффективности проекта ППП.
Этот материал представляет интерес не только для студентов, но и для специалистов в области информационных систем в экономике.
Глава I. СТРУКТУРА И АРХИТЕКТУРА ППП
Как уже было отмечено выше, одной из основных форм специализированного программного обеспечения являются ППП. Существует много различных определений этого понятия, характеризующих его с разных точек зрения. Мы будем исходить из трактовки ППП, предложенной во Введении.
Принято различать два аспекта ППП – его структуру и архитектуру. Первый – это устройство пакета с точки зрения системного программиста, второй – это то, что открыто и доступно пользователю. Ясно, данные аспекты взаимосвязаны, однако опыт показал не только желательность, но и необходимость при документировании ППП четко разделять эти моменты. Руководство пользователя не должно обременять его ненужными деталями системного программирования, которые должны быть скрыты.
1.1. Структура ППП
В структуре ППП можно выделить три основных компоненты: функциональное наполнение, язык заданий и системное наполнение (рис.1).
Пакеты прикладных программ — Создание Web-сайтов
Функциональное наполнение отражает специфику предметной области пакета и представляет собой совокупность модулей. Под модулем здесь понимается конструктивный элемент, используемый на различных стадиях функционирования пакета. Состав функционального наполнения пакета, его мощность или полнота охвата («покрытия») им предметной области отражает объем прикладных знаний, заложенных в пакет, т.е. потенциальный уровень тематической квалификации пакета.
Язык заданий пакета является средством общения пользователя с пакетом. Он позволяет описывать последовательность выполнения различных операций, обеспечивающих решение задачи или постановку задачи, по которой эта последовательность строится автоматически.
Системное наполнение представляет собой совокупность программ, которые обеспечивают выполнение задания и взаимодействие пользователя с пакетом, адекватное дисциплине работы в данной прикладной деятельности. Можно говорить, что системное наполнение организует использование потенциала знаний, заложенных в функциональное наполнение, в соответствии с возможностями, предусмотренными в языке заданий пакета. Реализация функций системного наполнения осуществляется на основе согласованного использования: а) штатных средств системного обеспечения; б) средств системного наполнения, расширяющих и сопрягающих возможности компонент штатного обеспечения и в) специальных средств системного наполнения, выполняющих управляющие, архивные и обрабатывающие процедуры с учетом специфики прикладной деятельности, охватываемой пакетом. Язык (языки), на котором пишутся программы системного наполнения, будем называть инструментальным языком пакета, в отличие от базового языка, на котором пишутся модули функционального наполнения.
1.1.1. Структура функционального наполнения
программ, где с помощью одной программы стараются охватить возможно более широкий класс задач. Главное достоинство пакетного подхода к модуляризации – возможность безболезненного развития программного фонда. Напротив, развитие «универсальной» программы всегда сопряжено с изменениями текстов написанных ранее частей программы.
Вместе с тем необходимо отметить, что с пакетным подходом связана серьезная технологическая проблема – как организовать взаимодействие существующих модулей с вновь создаваемыми? Известно ее решение в рамках технологии искусственного интеллекта.
С каждым модулем связывается и записывается в функциональное наполнение формальное описание его входных/выходных данных и условий его применимости, а вместо непосредственных вызовов модулей используются вызовы «по образцу», определяющие не конкретный модуль, а лишь стоящую перед ним задачу. Поэтому вновь появившийся модуль никак не воздействует на тексты модулей – своих потенциальных потребителей.
Эти модули автоматически найдут его из-за соответствия его описания выставленным ими запросами. В существующих пакетах программ технология искусственного интеллекта применяется относительно редко, так как она часто приводит к значительной потере эффективности и требует от разработчиков пакета свободного владения весьма нетривиальным логическим аппаратом.
В большинстве случаев, однако, удается найти более экономичное решение стоящих перед пакетом задач на основе существенно более простых программных конструкций. Действительно, во многих пакетах все расчеты ведутся по одной слабо меняющейся схеме. Ей соответствует вполне определенная структура всех формируемых пакетом расчетных программ.
Многообразие проводимых расчетов здесь достигается не количеством схем счета, а многочисленными вариантами заполнения «гнезд» фиксированной программой структуры-каркаса. Например, в функциональном наполнении пакета может содержаться несколько модулей, реализующих различные методы расчета.
Но в структуре программы для них предназначается единственное гнездо «Метод», в которое по указанию пользователя при формировании расчетных программ подставляется тот или иной модуль. При данном подходе, который называется каркасным, не накладывается ограничений на способы взаимодействия модулей.
Однако свободой выбора способов взаимодействия разработчик пакета пользуется только на стадии проектирования каркаса программы, а в дальнейшем все модули должны программироваться в строгом соответствии с выработанными при проектировании каркаса требованиями к заполнению гнезд. Нетрудно видеть, что каркасный подход обеспечивает безболезненность развития программного фонда пакета. Появление нового модуля никак не затрагивает тексты ни его соседей по гнезду, ни вызывающих его модулей. Соседи по гнезду никогда не соседствуют в расчетных программах, а вызывающие модули программировались в рамках соглашений каркаса и потому могут с равным успехом обращаться к любой (в том числе и к новой) реализации гнезда.
Реже встречаются предметные области, в которых многообразие связей модулей по управлению удается ограничить последовательным выполнением модулей, не жертвуя при этом ни удобством составления программ, ни эффективностью их выполнения. Расчетная программа здесь представляет собой цепочку выполняемых друг за другом модулей, вследствие чего данный подход называется цепочечным.
Обычно состав и порядок следования модулей в цепочке определяется некоторой внешней конструкцией, называемой планом вычислений. Но встречаются пакеты, где в ходе выполнения цепочки каждый очередной модуль сам динамически выбирает себе преемника. Популярности цепочечного подхода не в малой степени способствует то обстоятельство, что многие современные операционные системы (прежде всего UNIX) предоставляют удобные средства для его применения при организации связей между задачами. Все же основная масса крупных программных комплексов для решения вычислительных задач опирается на каркасный подход. Относительно неширокая распространенность цепочного подхода объясняется тем, что накладываемые им сильные ограничения на управляющие связи модулей влекут за собой существенные трудности при программировании.
1.1.2. Структура системного наполнения ППП
Рассмотрим более подробно эту компоненту ППП. Можно утверждать, что уже традиционными составляющими ее структуры являются (рис.3):
— резидентный монитор, осуществляющий интерфейс как между отдельными составляющими системного наполнения, так и между ними и штатным ПО;
— транслятор входных заданий, формирующий внутреннее представление задания и реализуемый обычно в виде макрогенератора или препроцессора;
— архив функционального наполнения (подсистема хранения программного материала);
— банк расчетных данных (подсистема хранения начальных и промежуточных данных, а также результатов расчетов);
— монитор организации вычислительного процесса (взаимодействия модулей по данным и управлению);
— планировщик вычислительного процессе, который определяет последовательность выполнения модулей, реализующую задания пакету;
— монитор организации интерактивного взаимодействия с пользователем.
В различных пакетах эти составляющие системного наполнения получили разную степень развития (иногда просто отсутствовали), реализовывались на основе различных системных подходов и по-разному назывались (терминология в пакетной проблематике не вполне установилась). Поэтому приведенную выше структуру следует воспринимать как сводный список различных ее составляющих, а не как обязательный перечень принадлежностей типичного ППП.
1.2. Архитектура ППП
Архитектура, т.е. представляющийся пользователю «внешний» вид специализированной программной системы, определяется тем, какие задачи она может решать и какие возможности предоставляются пользователю. Ясно, что язык заданий отражает основные архитектурные решения, принятые разработчиками пакета в данной предметной области. Именно через язык заданий пользователь воспринимает и оценивает, каковы «вычислительные услуги» и насколько удобно их использование, т.е., другими словами, каков фактический уровень тематической квалификации ППП.
1.2.1. Язык заданий
Общая структура и стиль языка заданий пакета в значительной степени зависят от дисциплины работы, принятой в обслуживаемой пакетом предметной области. Можно выделить две основные (в определенном смысле противоположные) дисциплины проведения вычислений:
— активную дисциплину, предусматривающую при создании конкретных расчетных программ модификацию и настройку имеющихся модулей функционального наполнения, а также разработку новых модулей;
— пассивную дисциплину, предусматривающую проведение вычислений без модификации функционального наполнения пакета.
Последняя характерна для деятельности так называемых конечных пользователей, т.е. специалистов, которые не обязательно имеют высокий уровень подготовки в области вычислительной техники и программирования. Главная цель разработчика языка заданий пакета, обеспечивающего решение прикладных задач в режиме пассивной дисциплины, заключается в том, чтобы «спрятать» от конечного пользователя основную массу алгоритмических подробностей решения его задачи, или, другими словами, повысить уровень непроцедурности языка. Такие языки, называемые языками запросов, ориентированы обычно на формулирование содержательных постановок задач, т.е. запросов, указывающих, «что необходимо получить» без явного задания того, «как это получить». Пользователь тем самым избавляется от необходимости конкретизировать способы и средства решения задач, что позволяет радикально понизить порог требований к уровню его программистской подготовки.
Язык заданий пакета может быть реализован как в форме самостоятельного языка, так и в форме встроенного языка, т.е. расширения существующего языка программирования. Независимо от формы реализации разработчик языка стремится к тому, чтобы лексика, синтаксис и семантика языковых конструкций были бы как можно ближе к пользовательскому восприятию решаемых прикладных задач. Важно не только опираться на понятия и терминологию предметной области и свойственной ей дисциплины работы, но и наглядно отразить в языке основные рабочие акты автоматизируемой прикладной деятельности.
1.2.2. Тематическая квалификация
Повышение тематической квалификации ППП определяется здесь тем множеством прикладных задач, которые можно формулировать и решать с помощью языка запросов. По мере развития функционального наполнения пакета может расти и круг решаемых им задач, и поэтому язык запросов обычно определяется как расширяемый, т.е. допускающий включение новых запросов. Расширяемость языка может поддерживаться соответствующей инструментально базовой системой или же достигаться путем прямого расширения возможностей системного наполнения.
Наконец, тематическая квалификация пакета может быть охарактеризована уровнем «профессионализма» выдаваемых пользователю решений и рекомендаций. Например, это имеет место при использовании пакетов, моделирующих динамику сложных экономических объектов.
1.2.3. Общение пользователя с пакетом
В настоящее время это, как правило, совершенные формы диалога, позволяющие пользователю и пакету регулярно обмениваться информацией, уточняющей и направляющей работу пакета на всех этапах его функционирования. В частности, можно предоставить пользователю средства оперативного управления ходом выполнения расчетной программы, позволив ему в определенных узловых пунктах решения выбирать дальнейшее направление вычислительного процесса.
1.2.4. Сервис
Одна из важных задач сервиса охватывает функции отладки и наблюдения за процессом исполнения задания пользователя. Сюда входят, в частности, средства диагностики ошибок и выдачи сообщений, локализующих ошибки.
При работе с пакетами программ, функциональное и системное наполнение которых интенсивно развивается, возникает задача постоянного отслеживания в пользовательской документации всех вносимых в программу изменений. Для развивающихся пакетов на смену выпуску быстро устаревающих печатных руководств приходят сервисные средства оперативного документирования, отражающие текущее состояние пакета.
1.2.4. Информационное обеспечение
При реализации информационных задач обычно широко используется техника меню или гипертекста. Чаще всего это бывает необходимо для ознакомления пользователя (актуального или будущего) с возможностями пакета и/или с его текущим состоянием.
Источник: poisk-ru.ru
Раздел 1. Разработка и использование пакетов прикладных программ Тема 1.1. Пакеты прикладных программ: состав и структура. Особенности ппп
Пакет прикладных программ – комплекс взаимосвязанных программ для решения задач определенного класса конкретной предметной области.
Многочисленные программные средства для решения различных типов вычислительных задач можно разделить на следующие группы:
- Отдельная прикладная программа пишется, как правило, на некотором универсальном языке программирования и предназначается для решения конкретной прикладной задачи. Примерами могут служить программа решения системы линейных алгебраических уравнений тем или иным численным методом, программа вычисления собственных значений матрицы и т. д. Авторами таких программ являются прикладные программисты, специализирующиеся в соответствующих предметных областях. Прикладная программа может быть реализована в «виде набора модулей, каждый из которых выполняет некоторую самостоятельную функцию. Например, программа вычисления собственных значений матрицы может включать модули, — реализующие преобразования матрицы из одной, формы представления в другую ввод и вывод данных, обработку аварийных ситуаций с выдачей диагностических сообщений пользователю и другие действия.
Источник: studfile.net
Тема 1.2 Структура и основные компоненты ППП
Несмотря на разнообразие конкретных пакетных разработок, их обобщенную внутреннюю структуру можно представить в виде трех взаимосвязанных элементов1 (рис. 2):
1.входной язык (макроязык, язык управления) — представляет средство общения пользователя с пакетом;
2.предметное обеспечение (функциональное наполнение) — реализует особенности конкретной предметной области;
3.системное обеспечение (системное наполнение) — представляет низкоуровневые средства, например, доступ к функциям операционной системы.
Рис. 2. Структура ППП
Входной язык — основной инструмент при работе пользователя с пакетом прикладных программ. В качестве входного языка могут использоваться как универсальные (Pascal, Basic и т.п.), так и специализированные, проблемно-ориентированные языки программирования (Cobol — для бизнес-приложений, Lisp — списочные структуры данных, Fortran и MathLAB — математические задачи и т.п.).
Развитый пакет может обладать несколькими входными языками, предназначенными для выполнения различных функций в рамках решаемого класса задач. Так, например в пакете OpenOffice.org поддерживаются языки StarBasic, Python, JavaScript и Java. StarBasic является основным входным языком, предназначенным для автоматизации работы с пакетом, для этого языка имеется интегрированная среда разработки и встроенный отладчик. Скрипты на языках Python и JavaScript загружаются и исполняются из внешних файлов. На Java (через SDK и функции API OpenOffice) можно создавать модули расширения и полнофункциональные приложения-компоненты.
Входные языки отражают объем и качество предоставляемых пакетом возможностей, а также удобство их использования. Таким образом, именно входной язык является основным показателем возможностей ППП. Однако стоит отметить, что в современных пакетах обращение пользователя к языковым средствам обычно происходит косвенно, через графический интерфейс.
Предметное обеспечение отражает особенности решаемого класса задач из конкретной предметной области и включает:
· программные модули, реализующие алгоритмы (или их отдельные фрагменты) прикладных задач;
· средства сборки программ из отдельных модулей.
Наиболее распространено в настоящее время оформление программных модулей в виде библиотек, подключаемых статически или динамически. В зависимости от использованного разработчиками подхода к проектированию и реализации ППП такие библиотеки содержат встроенные классы и описания их интерфейсов (при использовании объектно-ориентированного программирования). При использовании парадигмы структурного программирования в библиотечных модулях содержатся процедуры и функции, предназначенные для решения некоторых самостоятельных задач. В обоих случаях библиотеки связаны с другими модулями пакета лишь входной и выходной информацией.
Системное обеспечение представляет собой совокупность низкоуровневых средств (программы, файлы, таблицы и т.д.), обеспечивающих определенную дисциплину работы пользователя при решении прикладных задач и формирующих окружение пакета. К системному обеспечению ППП относят следующие компоненты:
· монитор — программа, управляющая взаимодействием всех компонентов ППП;
· транслятор(ы) с входных языков — для ППП характерно использование интерпретируемых языков;
· средства доступа к данным — драйверы баз данных и/или компоненты, представляющие доступ через унифицированные интерфейсы (ODBC, JDBC, ADO, BDE и т.п.);
· информационно-справочный модуль — предоставляет функции поддержки, среди которых информационные сообщения, встроенная справочная системы и т.п.
· различные служебные программы, выполняющие низкоуровневые операции (автосохранение, синхронизация совместно используемых файлов и т.д.)
Приведенная логическая структура ППП достаточна условна и в конкретном ППП может отсутствовать четкое разделение программ на предметное и системное обеспечение. Например, программа планирования вычислений, относящаяся к прикладному обеспечению, может одновременно выполнять и ряд служебных функций (информационное обеспечение, связь с операционной системой и т.п.).
Кроме того, одни и те же программы в одном пакете могут относиться к предметному обеспечению, а в другом — к системному. Так, программы построения диаграмм в рамках специализированного пакета машинной графики естественно отнести к предметному обеспечению. Однако те же программы следует считать вспомогательными и относящимися к системному обеспечению, например, в пакете решения вычислительных задач.
Тема 1.3 Эволюция ППП. Примеры современных ППП
Этапы развития ППП
Первые ППП представляли собой простые тематические подборки программ для решения отдельных задач в той или иной прикладной области, обращение к ним выполнялось с помощью средств оболочки ОС или из других программ. Современный пакет является сложной программной системой, включающей специализированные системные и языковые средства. В относительно короткой истории развития вычислительных ППП можно выделить 4 основных поколения (класса) пакетов. Каждый из этих: классов характеризуется определенными особенностями входящих состав ППП компонентов — входных языков, предметного и системного обеспечения.
Первое поколение
В качестве входных языков ППП первого поколения использовались универсальные языки программирования (Фортран, Алгол-60 и т.п.) или языки управления заданиями соответствующих операционных систем. Проблемная ориентация входных языков достигалась за счет соответствующей мнемоники в идентификаторах.
Составление заданий на таком языке практически не отличалось от написания программ на алгоритмическом языке. Предметное обеспечение первых ППП, как правило, было организовано в форме библиотек программ, т.е. в виде наборов (пакетов) независимых программ на некотором базовом языке программирования (отсюда впервые возник и сам термин «пакет»).
Такие ППП иногда называют пакетами библиотечного типа, или пакетами простой структуры. В качестве системного обеспечения пакетов первого поколения обычно использовались штатные компоненты программного обеспечения ЭВМ: компиляторы с алгоритмических языков, редакторы текстов, средства организации библиотек программ, архивные системы и т.д. Эти пакеты не требовали сколько-нибудь развитой системной поддержки, и для их функционирования вполне хватало указанных системных средств общего назначения. В большинстве случаев разработчиками таких пакетов были прикладные программисты, которые пытались приспособить универсальные языки программирования к своим нуждам.
Второе поколение
Разработка ППП второго поколения осуществлялась уже с участием системных программистов. Это привело к появлению специализированных входных языков на базе универсальных языков программирования.
Проблемная ориентация таких языков достигалась не только за счет использования определенной мнемоники, но также применением соответствующих языковых конструкций, которые упрощали формулировку задачи и делали ее более наглядной. Транслятор с такого языка представлял собой препроцессор (чаще всего макропроцессор) к транслятору соответствующего алгоритмического языка. В качестве модулей в пакетах этого класса стали использоваться не только программные единицы (т.е. законченные программы на том или ином языке программирования), но и такие объекты, как последовательность операторов языка программирования, совокупность данных, схема счета и др. Существенные изменения претерпели также принципы организации системного обеспечения ППП. В достаточно развитых пакетах второго поколения уже можно выделить элементы системного обеспечения, характерные для современных пакетов: монитор, трансляторы с входных языков, специализированные банки данных, средства описания модели предметной области и планирования вычислений и др.
Третье поколение
Третий этап развития ППП характеризуется появлением самостоятельных входных языков, ориентированных на пользователей-непрограммистов. Особое внимание в таких ППП уделяется системным компонентам обеспечивающим простоту и удобство. Это достигается главным образом за счет специализации входных языков и включения в состав пакета средств автоматизированного планирования вычислений.
Четвертое поколение
Четвертый этап характеризуется созданием ППП, эксплуатируемых в интерактивном режиме работы. Основным преимуществом диалогового взаимодействия с ЭВМ является возможность активной обратной связи с пользователем в процессе постановки задачи, ее решения и анализа полученных результатов.
Появление и интенсивное развитие различных форм диалогового общения обусловлено прежде всего прогрессом в области технических средств (графическая подсистема ЭВМ и средства мультимедиа, сетевые средства). Развитие аппаратного обеспечения повлекло за собой создание разнообразных программных средств поддержки диалогового режима работы (диалоговые операционные системы, диалоговые пакеты программ различного назначения и т. д.).
Прикладная система состоит из диалогового монитора — набора универсальных программ, обеспечивающих ведение диалога и обмен данными, и базы знаний об области. Информация о структуре, целях и форма диалога задает сценарий, в соответствии с который монитор управляет ходом диалога.
Носителями процедурных знаний о предметной области являются прикладные модули, реализующие функции собственной системы. Таким образом, создание прикладной системы сводится к настройке диалогового монитора на конкретный диалог, путем заполнения базы знаний.
При этом программировать в традиционном смысле этого слова приходится лишь прикладные модули, знания о диалоге вводятся в систему с помощью набора соответствующих средств — редактора сценариев. Логично требовать, чтобы редактор сценариев также представлял собой диалоговую программу, отвечавшую рассмотренным выше требованиям.
Благодаря готовому универсальному монитору программист может сосредоточиться на решении чисто прикладных задач, выделение же знаний о диалоге в сценарий обеспечивает в значительной степени необходимая гибкость программного продукта. Большое внимание в настоящее время уделяется проблеме создания «интеллектуальных ППП».
Такой пакет позволяет конечному пользователю лишь сформулировать свою задачу в содержательных терминах, не указывая алгоритма ее решения. Синтез решения и сборка целевой программы производятся автоматически. При этом детали вычислений скрыты от пользователя, и компьютер становится интеллектуальным партнером человека, способным понимать его задачи. Предметное обеспечение подобного ППП представляет собой некоторую базу знаний, содержащую как процедурные, так и описательные знания. Такой способ решения иногда называют концептуальным программированием, характерными особенностями которого является программирование в терминах предметной области использование ЭВМ уже на этапе постановки задач, автоматический синтез программ решения задачи, накопление знаний о решаемых задачах в базе знаний.
Источник: cyberpedia.su