Пакеты прикладных программ
Пакеты прикладных программ являются в настоящее время основной формой организации специального программного обеспечения. Эти пакеты должны обеспечивать программную реализацию, информационную согласованность своих компонентов, простоту в эксплуатации, открытость для модернизации и развития с минимальными затратами времени. Пакетом прикладных программ обычно называют комплекс взаимодействующих программных модулей, обладающих специальной организацией и обеспечивающих решение задач из некоторых областей знаний, называемой предметной областью пакета.
По способам организации выделяют пакеты простой структуры, а также пакеты сложной структуры имеющие средства аналитической их настройки, путем формирования работающих программ из готовых модулей. Пакеты прикладных программ могут работать либо в диалоговом, либо в пакетных режимах.
Диалоговый режим основной, дает возможность пользователю вызывать пакет, настроить его на конкретную объектную область, ввести задание на проектирование, оперативно получать промежуточные результаты и в зависимости от них проводить корректировку процессов проектирования.
В составе пакетов прикладных программ выделяют проблемные и системные компоненты. Проблемные компоненты отражают класс решаемых задач включает модель предметной области и библиотеку прикладных модулей.
Модель предметной области – это совокупность знаний по предмету области, представленные в специальной машинной форме. Библиотека прикладных модулей – набор законченных программных единиц, реализующих некоторую проектную процедуру. Модули библиотеке хранятся либо виде текстов на языке программирования, либо виде объектных модулей. Каждый объектный модуль имеет описатель, который содержит имя модуля, объем необходимой памяти, время счета и тому подобное. Эти модули используются программами системной части для автоматической генерации рабочих программ на основе модели предметной области и задания проектировщика.
Системные компоненты пакетов прикладных программ оформляются виде монитора пакета, функция монитора напоминают функции О.С. В некоторых мощных пакетах часть действий обычно выполняемых О.С. передается мониторам пакетов, что позволяет разгрузить О.С., ограничившись минимумом необходимых ее операций. Монитор пакета осуществляет взаимодействие с монитором пакета, корректирует ввод и производит корректировку исходных данных, вывод необходимых результатов на внешнее устройство.
Типовой монитор включает в себя компоненты:
1) Ведущий модуль, который осуществляет общее управление остальных модулей и связь с О.С.
Модуль ввода/вывода
3) Транслятор переводит с входного языка на внутренний
4) Планировщикпроизводит построение алгоритма решения сформулированной задачи, выбор последовательность использования прикладных модулей.
5) Интерпретатор осуществляет выполнение модуля рабочей программы, в соответствии с полученным от планировщика алгоритмом
6) Библиотекарь производит вод и удаление модулей, осуществляет проектировку моделей предметной области.
Различают три группы прикладных программ:
1) Пакеты автоматизирующие полный цикл проектирования, некоторые продукты изделия(авторегулятор)
2) Пакеты для расчета характеристик и свойств проектированной системы.(микрокаб)
3) Пакеты обеспечивающие выполнение типовых процедур для различных методик объектов проектирования.(Оптимального раскроя материала)
Информационное обеспечение.
Информационное обеспечение по большому счету имеет две формы организации:
1) Файловая система
2) Банки данных
Структура банков данных.
 |
Хранение данных в базе данных как правило осуществляется в действующей вспомогательной памяти. Общее описание данных, хранимых в БД называется схемой, подсхемой называется описание части БД, доступной конкретному пользователю, выполненная на языке, близком к языку описания данных.
В схеме выделяют три части:
1) Концептуальную (иформационно-логическую)
2) Логическую
3) Физическую
Концептуальная– это описание хранимых данных вне связи СУБД. Логическая часть схемы – описывает способы хранения данных определенных в логических частях схемы. Если мы имеем дело с распределенной информационной системой, то физических схем может быть несколько, по одной в каждом узле системы.
Основным средством обработки данных являются прикладные программы реализующие проектные операции. Для их корректного выполнения прикладным программам должны быть известны подсхема и схема, т.е. описание обрабатываемых данных и его отображение в общее описание данных. Одним из способов связи их с прикладной программой является включение их в состав загрузочного модуля на этапе редактирования связи прикладной программы. Наиболее часто используется способ при котором подсхема является частью раздела данных прикладных программ на исходном языке программирования, а схема подключается к загрузочному модулю прикладной программы, либо на этапе редактирования связей, либо связывается с ним в оперативной памяти ЭВМ посредством СУБД.
Способы доступа к данным и их обработке реализуется СУБД, как команды языка манипулирования данными и их параметрами.
Диалоговый процессор – это программное средство позволяющее СУБД выполнять в диалоговом режиме большинство команд языка манипулирования данными, а также при помощи диалогового процессора разработчик проверяет правильность последовательности команд при манипулировании данными до включения их в прикладную программу.
Проектирование схемы базы данных облегчает словарь данных. Словарь данных – это программно – лингвистическое средство поддерживающее перечень хранимых данных на языке понятном неподготовленному пользователю. На основе словаря данных разработчики определяют концептуальную, логическую, физическую части схемы, а также подсхемы. Словарь данных является важным средством централизации управления базы данных. Словарь данных представляет собой специальную систему в составе банка данных, предназначенную для хранения единообразной и централизованной информации обо всех ресурсов данных конкретного банка. В нем содержаться сведения об объектах, свойствах, связях для данного ПО, а также содержаться сведения о данных хранимых в БД, а именно: наименования данных, структура, связи с другими данными, а также об их возможных значениях и форматах представления, об источниках их возникновения, о кодах защиты и ограничениях доступа к данным со стороны других пользователей.
Словарь данных призван способствовать уменьшению избыточности и противоречивости данных, хранить централизованное описание данных, позволяющее централизованно вводить в систему новые типы данных, изменять описание существующих, либо удалять устаревшие. Кроме того словарь данных обеспечивает пользователю системы, администратору БД единую терминологию по данному ПО при решении вопросов связанных с обслуживание запросов в банки данных.
Преимущества при использовании словаря данных заключаются в централизованном накоплении описание суммарного ресурса данной системы, как на этапах проектирования БД, так и на этапах ее функционирования. В настоящее время имеются СУБД в состав которых входят программные средства ведения словаря и в этом случае говорят об интегрированном словаре данных, так а СУБД не имеющих в своем составе таких средств. В последнем случае разрабатывают специальный пакет программ для ведения словаря, так называемого независимого словаря данных. В системах с интегрируемом словарем описания данных хранятся в единственном экземпляре в словаре и используются при работе системы. Этот словарь данных может также служить средством контроля работы системы. В системах с независимым словарем существует дублирование описания данных, что повышает вероятность избыточности и противоречивости данных, хранимых как в СУБД, так и в словаре.
Генератор отсчетов – программно лингвистическое средство, обеспечивающее формирования форматированных отчетов о содержимом БД и ее статистических параметров. Также генератор отсчетов применяется для выполнения запросов к БД, не требуемых сложной математической обработки.
Неотъемлемой частью современных банков данных является администратор БД. Администратор БД – лицо или группа лиц осуществляющих контроль за функционированием банка данных. В обязанности администратора БД входит определение информационного содержания БД, способы хранения и доступа к данным, контроль и процедура проверки достоверности и восстановления данных. Для выполнения своих обязанностей АБД использует примерный набор утилит, т.е. программ обслуживания БД. Для первоначальной загрузки справочных и информационных баз используются утилиты загрузки. Рассматривая банк данных как систему управления необходимо указывать объект управления и управляющий орган. В банке данных в качестве объекта выполнения выступает БД, в качестве управляющего органа выступает группа специалистов знакомых, как с теорией систем обработки данных, так и с ПО данной системы.
Реализовать банк данных полностью как автоматическую систему для всего жизненного цикла информационной системы пока не удается. Это прежде всего связанно с тем, что система в состав которой входит банк данных является развивающейся системой, обеспечивающей вид человеческой деятельности, поэтому приходится вносить какие-то коррективы в ПО, что может быть сделано только специалистом. Банки данных отличаются той особенностью, что их внедрение занимает продолжительное время. Развитие банков данных происходит по мере разработке пакетных программ, расширения ПО, поэтому функции АБД являются долгосрочными, направленные на координацию всех этапов проектирования, реализации и ведения БД.
Функции администратора базы данных:
1) Решать вопросы организации данных и установления связей между этими данными с целью объединения информации о различны объектах.
2) Координировать все действия по проектированию, реализации и ведению БД. Учитывать как перспективные, так и текущие требования пользователей и следить, чтобы БД удовлетворяла интеллектуальным информационным потребностям.
3) Решать вопросы связанные с расширением БД в связи с изменением границ ПО.
4) Разрабатывать и реализовывать меры по обеспечению защиты данных от некомпетентного их использования и сбоев технических средств по обеспечению секретности определенной части данных и разграничение доступа к данным.
5) Выполнять работы по ведению словаря данных, контролировать избыточность и противоречивость данных.
6) Следить за тем, чтобы банк данных отвечал заданным требованиям по производительности, т.е. обработка запросов выполнялась за приемлемое время
7) При необходимости изменять методы хранения данных, пути доступа к ним, форматы данных, определять степень влияния изменения данных на всю БД.
8) Координировать вопросы технического обеспечения системы аппаратными средствами исходя из требований, предъявляемой БД к оборудованию.
9) Координировать работу программистов, разрабатывающих дополнительное ПО для улучшения эксплуатационных характеристик системы.
10) Выполнять проверку и включение прикладных программ в состав ПО системы
Для нормальной работы АБД важно, чтобы в системе была обеспеченна независимость пакетов программ от данных, поскольку АБД при расширении системы, а также в целях обеспечения эффективного обслуживания пользователей требуется выполнять работы по изменению методов хранения данных, путей доступа к ним, структуры и форматов данных, связей между ними. Если не принят специальных мер, то при написании пакетов программ при любых изменениях в базе, касающихся данных, потребуется коррекция исходного текста и перекомпиляции программы. Независимость прикладным программ от данных обеспечивается средствами СУБД. В основе методов лежит следующая идея: пользователям системы требуется информационное содержание данных, а не детали их представления и расположение в памяти системы. Поэтому прикладные программы следует освободить от этих подробностей, т.е. чтобы пользователи могли использовать БД не зная их внутреннего представления. К сожалению в существующих СУБД не удается достигнуть полной независимости прикладных программ от данных, хранимых в базе. Поэтому АБД обязан контролировать действия выполнения работ по изменению БД, ориентируясь на тот уровень независимости, который обеспечивается независимостью СУБД.
Системы управления базами данных.(СУБД)
В банках данных обычно применяется одны из следующих моделей данных:
1) Реляционная
2) Иерархическая
3) Сетевая
Эти модели представляют собой образцы типовых структур данных, отличающихся между собой. Но не существует таких СУБД, поддерживающих в чистом виде какую-то одну модель данных. Такое положение связанно с тем, что на практике при даталогическом моделировании ПО не удается без серьезных издержек обойтись какой-то одной моделью.
Иерархические модели нельзя без избыточности реализовать сложные сетевые структуры, а в реляционной модели нельзя в чистом виде реализовать иерархические структуры, не вводя избыточные данные. Поэтому в ряде случаев языки конкретных СУБД ориентируют в основном на определенную модель данных, но при этом в них реализуют некоторые возможности работы с другими моделями данных.
Реляционная модель является наиболее простой и основывается на представлении данных в виде таблиц, строка такой таблицы эквивалентна записи файла БД, а колонка – полю записи. Доступ к элементам данных осуществляется посредством связи требуемой строки, т.е. записи, требуемой колонкой, т.е. полем. Недостатком реляционной модели является жесткость структуры данных (невозможно задание строк таблицы произвольной длинны), а также зависимость скорости ее работы от размера БД. При выполнении ряда операций требуется просмотр всей базы.
В иерархической модели данные связываются по уровням. Данные высшего уровня называются родительскими, связанные с ними данные следующего уровня - сыновними. Такие связи отображаются виде дерева графа, где допускаются только односторонние вертикальные связи от старших вершин к младшим.
В сетевой модели наряду с вертикальными допускаются и горизонтальные связи.
Использование иерархической и сетевой модели ускоряет доступ к информации БД, но поскольку каждый элемент данных должен содержать ссылки на другие элементы, требуются значительные ресурсы памяти ЭВМ. Недостаток оперативной памяти снижает скорость обработки данных, кроме того для таких моделей характерна сложность реализации СУБД. Поэтому в настоящее время реляционные СУБД лучше соответствуют техническим способностям персональных ЭВМ и способны удовлетворить потребности многих пользователей.
СУБД реляционного типа.
К числу СУБД, предназначенных для персональных ЭВМ относят семейство “Fox Pro”, ”dBase”, “Paradox”, “Clipper”. В этих СУБД записи и соответственно поля обычно имеют фиксированную длину от 4 до 5000 байт, число полей вирируется от 128 до 1024. Большинство СУБД реляционного типа позволяют создавать БД числом записей до одного миллиарда и объемом до двух гигабайт. Обычно в состав СУБД, предназначенных для работы на ПК входят три основных компонента:
1) Командный язык
2) Интерпретирующая система или компилятор для преобразования команд к выполнимому виду
3) Средство взаимодействия пользователя с СУБД (интерфейс пользователя)
Командный язык – служит для выполнения и обеспечения требуемых операций с данными, т.е. позволяет создавать структуры файлов БД и манипулировать данными, создавать прикладные программы, создавать экранные формы ввода и вывода информации и тому подобное. В качестве командных языков используют язык dBase и в настоящее время наиболее мощный язык.
Интерпретирующая система и компилятор –два принципиально разных способа преобразования команд к исполнимому виду. Интерпретирующая система преобразует поочередно команды в исполнимый вид перед их непосредственным выполнение (“Fox Pro”, ”dBase”, “Paradox”). Во втором способе сначала вся исходная программа преобразуется в программу из исполнимых машинных команд, а затем эта программа выполняется. (СУБД “Clipper”)
Первый способ выполнения команд СУБД имеет то преимущество, что исходная программа занимает сравнительно немного места в оперативной памяти и кроме того, этот способ позволяет выполнять команды по одной, либо в режиме ввода с клавиатуры, либо в режиме управляемом с помощью меню. Однако выполнение исходной программы происходит достаточно медленно.
Второй способ в отличии от первого позволяет выполнять программы значительно быстрее, но программа составленная из машинных команд занимает гораздо больше оперативной памяти.
Взаимодействие пользователя с СУБД, которое использует интерпретирующая система обычно может осуществляется в режиме, управляемым с помощью меню, а второй режим дает возможность работать пользователя с пакетом СУБД не зная командного языка. Структура и содержание компонентов СУБД определяет ее назначение и круг потенциальных пользователей.
Система управления базами данных с компиляторами программ в основном ориентирована на программистов а СУБД с интерпретирующей системой предназначены для широкого круга пользователей.
В задачах обработке информации, основанных на системах БД, существует два варианта расположения данных:
1) Локальное
2) Удаленное
Локальныеданные, как правило располагаются на жестком диске компьютера и находятся в монопольном ведении работающего пользователя. Пользователь при этом работает автономно, не зависит от других пользователей и не влияет на их работу.
Удаленные данные располагаются вне компьютера пользователя либо на файловом сервере сети, либо на специально выделенном для этих целей компьютере. Существует две технологии или архитектуры обработке удаленных данных. Это файл - серверная архитектура и архитектура клиент – сервер.
Банк данных – важная обслуживающая подсистема, он выполняет функции информационного обеспечения и имеет ряд особенностей. В нем хранятся, как редко изменяемые данные (архивы, справочные данные, типовые проектные решения), так и сведения о текущем состоянии различных версий выполняемых проектов. Как правило банк данных работает в многопользовательском режиме.
Построение банка данных САПР – сложная задача, обусловленная следующими особенностями САПР:
1) Разнообразие проектных данных, фигурирующих в процессах обмена как по своей семантике, так и по формам представления. В частности здесь значительная доля графических данных.
2) Нередко обмены должны происходить с высокой частотой, предъявляет жесткие требования к быстрому обмену
3) В САПР проблема целостности данных оказывается более трудной для решения, чем в большинстве других систем, поскольку проектирование, как правило, является процессом взаимодействия многих проектировщиков, которые не только считывают данные, но и изменяют их, причем значительное время они работают параллельно. Из этого факта вытекают следующие следствия: Итерационный характер проектирования обычно приводит к наличию по каждой части проекта нескольких версий, любая из них в дальнейшем может быть принята в качестве основной, поэтому надо хранит все версии, с возможностью возврата к ним и также нельзя допускать использование неутвержденных данных. Поэтому каждый проектировщик должен иметь свое рабочее пространство в памяти, работать в нем автономно, а моменты внесения изменения в общую БД должны быть согласованны и не должны порождать для других пользователей неопределенность данных.
4) Транзакции могут быть длительными и трудоемкими. Транзакцией называют последовательность операций по удовлетворению запроса. В САПР транзакции могут включать в себя очень трудоемкие операции в результате могут длится даже несколько часов
5) Иерархическая структура проектных данных и следовательно отражение на следование в целях сокращения объема БД.
В определенной мере названные особенности учитываются в СУБД третьего поколения, в которых стали применятся черты объектно-ориентированных СУБД. Объектно-ориентированные БД выгодны тем, что во-первых данные по конкретным объектам проектирования не разбросаны по множеству таблиц, как это имеет место в реляционных БД, а сосредоточенны в определенных местах. Во-вторых для каждого объекта могут быть назначены свои типы данных, в результате проще решаются задачи управления и удовлетворения запросов.