40. Структурное проектирование АИС.
Процесс проектирования АИС задается последовательностью следующих этапов:
1. постановка задачи
2. предпроектное обследование сферы деятельности
3. декомпозиция системы по функциональным основаниям (на микро- и макроуровнях)
4. декомпозиция системы по средствам обеспечения
5. разработка методов, способов создания элементов и частей системы
6. композиция спроектированных элементов и частей системы в технологические структуры (подсист.)
7. опытная эксплуатация, экспериментальные исследования
8. внедрение системы
Микро- и макроуровни.
На макроуровне формируется совокупность информационной структуры, сферы деятельности или предметная область в виде распределенной БД или сети. На этом уровне решаются вопросы взаимодействия всех участников сети. Условно м. разделить на: субъектов потребителей и субъектов производителей.
На микроуровне – создание внутренней структуры конкретной АИС как составную часть какой-либо др. АИС. На этом уровне происходит декомпозиция по видам обеспечения и функциональным частям.
41. Проектирование лингвистического обеспечения АИС.
При проектировании ПО разделяется на проектирование ЛО внешней и внутренней БД.
Для проектирования внешней БД проводится анализ внешних документопотоков, т.е. анализ схемы доступа к др. БД АИС и сетям. Для этого использ-ся таблицы, матрицы.
При проектировании ЛО внутренней БД проводится сопоставительный анализ ИПЯ, применяемых в различных процессах или БД системы. В результате – схема-матрица.
Основной единицей ЛО – массивы лексических единиц.
ЛО:
- Словарь смыслового выражения ед-ц (классификатор, рубрикатор; тезаурус, дескриптор, ключевые слова; словарь);
- Критерии выдачи (логические; весовые; вычислительные);
- Правила индексирования док-в и з-сов (с помощью словаря; свободное; с грамматикой – между единицами логические связи; без грамматики – набор слов);
- Правила построения, ведения ИПЯ (акрипторн.- до создания ИПЯ; апестерион.- правила ИПЯ; в пр-се проект-я).
42. Проектирование информационного обеспечения АИС.
ИО – совокупность информационных массивов. При эксплуатации ИО постоянно решаются вопросы сбора, ввода, организации и хранения документов в АИС. В структуре ИО выделяется совокупность данных, методы подготовки этой совокупности.
В современных АИС не вся информация представлена в машинной форме (сущ-ет внутримашинная и внемашинная).
Внемашинная информационная база м.б. весьма сложной по структуре. Их м. строить в зависимости от типа организации.
1 часть – док-ты, предназначенные для удовлетворения пользователей (основной документный массив);
2 часть – документы служебные (управляющая документация).
Структура внутримашинной информационной базы – комплекс баз и банков данных; фактографические и документальные.
БД м. подразделить с позиции использования на:
Внешн., внутрен., основн., служебн.
БД м. располагаться в пределах 1 ЭВМ или системы, но м. также находиться на большом расстоянии др. от др. такой состав – декомпозиция на макроуровне.
Для проектирования ИО проводится микроанализ информационной базы , отражающий ее состав на уровне элементов данных. При описании док-тов распределяются 3 группы док-тов: входные, выходные и промежуточные.
Для каждого класса устанавливается формат (состав, структура реквизитов). Для библиографической БД перечень элементов устанавливается ГОСТом для каждого класса док-тов (формат MARC).
Для фактографической БД в качестве элементов данных выступают реквизиты, которые подразделяют на следующие группы: основание и признаки.
Принято считать, что при создании внутренней БД решаются след. группы задач: структурные, функциональные, технологические, эксплуатационные, организационные.
Процесс проектирования внутренней БД начинается на этапе предпроектного исследования, продолжается на этапах проектирования и внедрения. При создании информационного массива прежде всего определяется их состав и структура.
Следующим этапом является подготовка и формирование информационных массивов, т.е. определение структуры БД. Должен быть сформирован и нормативно-технический массив необходимый и достаточный для проведения всех экспериментов. Для каждой решаемой АИС определяются входные и выходные потоки док-тов и устанавливаются их характеристики.
43. Проектирование комплекса технических и программных средств.
Комплекс технических средств (КТС) – материальная основа. В КТС принято различать 2 части: центральную и периферийную.
Состав центральной части определяется объемно-временными характеристиками задач, т.е. кол-во задач подлежащих обработке и времени, в течение которого должна быть решена. Функционирование центральной части не зависит от ПО АИС, т.к. существуют единые правли обработки информации на ЭВМ, технические характеристики и возможности программного обеспечения.
Периферийная часть представляется классами средств регистрации, передачи и подготовки информации. Состав периферийной АИС зависит от технического сбора, передачи информации.
Существуют 2 основных способа регистрации: централизованный и децентрализованный.
При 1-ом способе регистрации информации все технические операции выполняются на ВЦ. Связь с ВЦ осуществляется различными способами. Самый примитивный – почта, курьер, дискета – для небольших информационных потоков.
При проектировании КТС должны соблюдаться общие принципы:
1. совместимость всех технических средств, кодов, техники и программ;
2. соответствующая пропускная способность всего КТС;
3. максимальное использование устройств;
4. надежность как самих средств, так и системы;
5. агрегатированность, возможность наращивать, перестраивать.
К КТС предъявляются след. требования:
1. решение всех задач системы в заданное время и в необходимом объеме;
2. выполнение всех этапов автоматической обработки информации;
3. возможность контроля информации на всех этапах обработки;
4. возможность развития (расширение);
5. эффективность функционирования задач, оптимальность решения.
Структура ПО – это операционные системы, сервисные системы (оболочки, утилиты и т.п.), система технического обследования, пакеты прикладных программ, собственно обеспечивающие программы (сетевые программы). При выборе программных средств отталкиваются от анализа решаемых задач.
Рекомендации по выбору сетевых программ:
1. топология сетей;
2. максимальное удаление ЭВМ др. от др.
3. кол-во ЭВМ по сети;
4. решить будут ли однородными или неоднородными ЭВМ по сети;
5. надежность;
6. передающая среда.
При выборе прикладных программ АИС необходимо учитывать следующие их характеристики: технические, сервисные, эксплуатационные.
Технические – ориентирована на определенные ЭВМ и операционную систему, объем основной памяти, доступное кол-во рабочих станций.
Сервисные – режим ввода запросов пользователей в систему, возможность телекоммуникационного доступа, устройство форматов, кол-во форматов, кол-во поиска.
Эксплуатационные – отработанность, наличие дополнительных программных средств, возможность работать под управлением универсальной операционной системой.
44. Оценка эффективности проектируемой АИС.
Эффективность АИС бывает разная. Рассмотрим несколько эффективностей:
- общая экономическая эффективность от внедрения АИС (с т.зр. финансов);
- прагматические показатели (с т.зр. потребителя);
- семантические показатели – мера полноты, точности.
Оценка экономической эффективности производится минимум 3 раза: на этапе предпроектной стадии, на этапе технического проектирования, после внедрения АИС.
По методике принятой в АСНТИ, АСУ рассматриваются 2 показателя:
Годовая экономическая эффективность (выгода, разница между затратами и прибылью):
Эф-сть годовая = А (Со – С1) – Ен* Кв;
где А – кол-во поиска в год;
Со – себестоимость поиска до внедрения;
С1 - себестоимость поиска после внедр-я;
Ен – нормативный коэф-т окупаемости затрат;
Кв – затраты на внедрение.
Срок окупаемости затрат:
То=
Ер =
Для того, чтобы определить будет ли эффективна новая АИС необходимо сравнить: Ер – Ен, если от 0,13 до 0,25, то она эффективна.
Основной источник получения экономического эффекта – снижение поиска. Чем больше запросов, тем меньше себестоимость каждого поиска, а значит выше экономические показатели.
45. Этапы проектирования БД.
В БД отражается информация об определенной ПО. В АИС отражение ПО представлено моделями данных нескольких уровней. Можно выделить соответствующим им этапы проектирования БД.
ДМ является моделью логического уровня и представляет собой отображение логических связей между элементами данных безотносительно к их содержанию и среде хранения. Эта модель строится в терминах информационных единиц, допустимых в той конкретной СУБД, в среде которых проектируется БД. Этап создания ДМ наз-ся даталогическим проектированием.
Для привязки ДМ к среде хранения используется физическая модель. Эта модель определяет используемые ЗУ, способы физической организации данных в среде хранения, строится также с учетом возможностей, предоставляемых СУБД. Описание физической структуры называется схемой хранения. Соответствующий этап проектирования БД называется физическим проектированием.
В некоторых СУБД, помимо описания общей логической структуры БД, имеется возможность описать логическую структуру БД с т.зр. конкретного пользователя. Такая модель называется внешней, а ее описание – подсхемой. Внешняя модель не всегда является точным подмножителем схемы. Если определена подсхема, то пользователь имеет доступ к данным которые отражены в соответствующей подсхеме, что является одним из способов защиты информации от несанкционированного доступа. Использование аппарата подсхемы облегчает работу пользователя, т.к. он должен знать структуру не всей БД, а только ее часть, которая имеет непосредственное отношение к нему. Кроме того, эта структура приспособлена к его потребностям.