Реферат: Ответы к экзамену по специальности Информатик-технолог

- обратной связи. Возможность корректировки ранее принятых решений;

- человекомашинности. Основан на совмещении возможностей человека и технических средств в результате разумного распределения обязанностей человека и ЭВМ;

- однократного ввода информации и многократного ее использования. Рекомендуется одновременно вводить полный объем информации, чтобы получить максимальный объем выходных данных;

- типовых проектных решений. Широкое использование уже наработанных опытов, что сокращает сроки проектирования;

- совместимости с окружением. Способность системы воспринимать действительное окружение без дополнительного преобразования;

- адаптивности. Живучесть, приспосабливаемость.

- техничности. Требования удобства и простоты эксплуатации системы;

- дружественности. Способность системы предоставлять пользователю возможность простейшего и эффективного общения без обучения и подготовки;

- компактности. Экономичность структуры системы (элементы зависимы друг от друга);

- коллективности. Участие специалистов разных направлений;

- единого руководства на всех этапах проектирования. Отвечать за ввод новой системы должен 1 человек;

- перманентности. Необходимость постоянного совершенствования системы в связи со старением прикладных программ, технических средств, лингвистических средств.

39. Предпроектное обследование объекта автоматизации. Состав и структура технического задания.

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

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

Техническое задание – юридический и нормативно-технический документ на основе которого осуществляется разработка АИС. В нем указывается цели и задачи, ее функциональная и организационная структура, функции отдельных подсистем, требования ко всем видам обеспечения, критерии оценки эффективности системы, этапы разработки и этапы оценки ожидаемого экономического эффекта.

ТЗ состоит из трех стадий:

а) обоснование необходимости разработки программы (ИС) – постановка задачи, сбор исходных материалов, выбор и обоснование критериев эффективности и качества разработанной АИС, обоснование необходимости проведения НИР;

б) НИР – определение структуры входных и выходных данных, предварительный выбор методов решения задач, обоснование целесообразности применения ранее разработанных программ (ИС), определение требований к техническим средствам, обоснование принципиальной возможности решения поставленной задачи;

в) разработка и утверждение ТЗ – определение требований к программам, разработка технико-экономического обоснования АИС, определение стадий, этапов и сроков разработки АИС и документация на нее, выбор языков программирования,  определение необходимости проведения НИР на последних стадиях, согласование и утверждение ТЗ.

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. Этапы проектирования БД.

В БД отражается информация об определенной ПО. В АИС отражение ПО представлено моделями данных нескольких уровней. Можно выделить соответствующим им этапы проектирования БД.

ДМ является моделью логического уровня и представляет собой отображение логических связей между элементами данных безотносительно к их содержанию и среде хранения. Эта модель строится в терминах информационных единиц, допустимых в той конкретной СУБД, в среде которых проектируется БД. Этап создания ДМ наз-ся даталогическим проектированием.

Для привязки ДМ к среде хранения используется физическая модель. Эта модель определяет используемые ЗУ, способы физической организации данных в среде хранения, строится также с учетом возможностей, предоставляемых СУБД. Описание физической структуры называется схемой хранения. Соответствующий этап проектирования БД называется физическим проектированием.

В некоторых СУБД, помимо описания общей логической структуры БД, имеется возможность описать логическую структуру БД с т.зр. конкретного пользователя. Такая модель называется внешней, а ее описание – подсхемой. Внешняя модель не всегда является точным подмножителем схемы. Если определена подсхема, то пользователь имеет доступ к данным которые отражены в соответствующей подсхеме, что является одним из способов защиты информации от несанкционированного доступа. Использование аппарата подсхемы облегчает работу пользователя, т.к. он должен знать структуру не всей БД, а только ее часть, которая имеет непосредственное отношение к нему. Кроме того, эта структура приспособлена к его потребностям.

Но для того, чтобы спроектировать структуру БД, необходима исходная информация о ПО. Желательно, чтобы эта информация была представлена в формализованном виде. Информация, требуемая для проектирования БД, мало зависит от особенностей СУБД. Описание ПО, выполненное без ориентации на используемые в дальнейшем программ и технических средств называется  ИМ ПО.

46. Инфологическая модель ПО.

Чтобы спроектировать структуру БД необходима исходная информация о ПО. Описание ПО, выполненное  без ориентации на используемые в дальнейшем программы и технические средства называется  ИМ ПО.

ИМ ПО строится первой. ИМ должна строится вне зависимости от того, будете ли ВЫ в дальнейшем использовать какую-либо СУБД или пользоваться др. программными средствами для реализации своей ИС.

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

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

ИМ должна  легко восприниматься разными категориями пользователей.

47. Даталогическое проектирование БД.

ДМ – модель логического уровня, ориентирована на тип СУБД.

При проектировании ДМ – большое влияние оказывает ИМ. Результатом ДП будет описание логической структуры БД на языке описания данных (ЯОД), схематичное изображение структуры БД.

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

Основные принципы ДП:

ДМ – ориентируется на тип СУБД. Процесс проектирования предусматривает предварительное инфологическое проектирование, при котором происходит классификация ПО, систематизируется представление объектов и их взаимосвязь. Процесс ДМ – преобразование ИМ в ДМ. Проверка адекватности получаемой ДМ (в соответствии с потребностями, в соответствии с ПО).

Для любой ПО существует множество БД. При этом в 1-ую очередь определяется состав БД, минимальной логической единицей БД является свойство объекта.

Связи между сущностями ПО отображаемой в ИМ, в ДМ могут отображаться по разному – путем совместного расположения или путем указания связей. В конкретной ДМ отображаются не все связи существующей ПО. Решение выбора связей зависит от многих факторов – особенность отображаемой сущности, объем номенклатуры, особенности СУБД и т.п.

Этапы ДП:

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

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

48. Физическое проектирование БД.

ФМ привязывает логическую модель к среде хранения. Сложность и трудность физической реализации зависит от возможности конкретной СУБД. Общий перечень работ:

- выбор типа носителя;

- выбор способа организации данных;

- выбор методов доступа;

- определение физических размеров, блоков;

- размещение данных и управление этим размещением на внешних носителях;

- управление свободной памятью;

-    решение целесообразности сжатия данных и методов сжатия;

-    оценка физической модели данных.

Проектирование БД связано с понятием «обеспечение целостности данных». Целостность данных – это условное название, набор условий. Это значит допустимые значения отдельных информационных единиц – полей, файлов и связей между ними.

Ограничение целостности в общем случае определяется 2 группами факторов:

1.  семантическое – исходя из особенностей ПО;

2.  синтаксическое – определяется способом организации данных.

Для полей чаще всего используется следующие виды ограничений:

Типы формата, задание диапазона значений, признак пустого поля, принцип уникальности.

Ограничения на запись: ограничение на значение всей строки, ограничение на значение некоторых полей данной строки, записи.

Ограничение целостности на таблицы: запрет на обновление – поле, запись, файл.

49. Исключения. Обработка исключений. Блоки try…finally, try…except.

Исключения – способ передачи информации об ошибке во время исполнения программы.

Причины:

1.  из-за математических ошибок;

2.  при использовании индекса, выход за предел массива;

3.  переполнение стека из-за ошибок при распределении памяти, неправильных входных данных;

4.  неготовых устройств.

Отсюда следует, что исключения – уведомление об ошибке во время исполнения или о др. ситуации, при которой требуется отступить от обычного исполнения программы.

Страницы: 1, 2, 3, 4, 5, 6