2015-07-14
1563
ТЕСТЫ
Дисциплина: «Проектирование АСОИУ»
Специальность: 230102 «Автоматизированные системы обработки
информации и управления»
Курс: 5
Форма обучения: очная
Составитель: к.э.н. Кораблёва Г. В.
Рассмотрено на заседании кафедры «Информатизации и управления»
Протокол № от «» 2007 г.
СПИСОК ТЕСТОВЫХ ЗАДАНИЙ
1. Метод проектирования программного обеспечения включает:
- совокупность концепций и теоретических основ;
- инструментальные средства реализации основных теоретических концепций;
- процедуры, определяющие практическое применение метода.
2. Методология проектирования программного обеспечения АИС – это
- наука о методах проектирования программного обеспечения АИС;
- наука о методах, средствах и нотациях, применяемых для проектирования программного обеспечения АИС;
- совокупность методов и технологических операций проектирования в их последовательности и взаимосвязи, приводящая к разработке проекта программного обеспечения.
3. Технология разработки программного обеспечения АИС – это
|
|
|
- совокупность методов и технологических операций проектирования в их последовательности и взаимосвязи, приводящая к разработке проекта программного обеспечения;
- совокупность средств, методов сбора, обработки и передачи информации для получения информационного продукта;
- совокупность процедур описания данных и методов проектирования программного обеспечения.
4. Технология проектирования программного обеспечения включает:
- средства проектирования программных продуктов и АИС;
- методы и средства организации проектирования;
- исполнителей проектных работ;
- последовательность технологических операций, выполнение которых позволяет получить готовый к использованию программный продукт.
5. Требования, которым должна удовлетворять современная технология разработки программного обеспечения:
- обеспечивать минимальное время получения работоспособного программного обеспечения АИС;
- зависимость получаемых проектных решений от средств реализации АИС (СУБД, операционных систем, языков и систем программирования);
- иметь поддержку комплекса согласованных CASE - средств, обеспечивающих автоматизацию процессов жизненного цикла;
- обеспечивать интеграцию различных инструментальных средств в процессе разработки программного продукта.
6. К числу основных возможностей, обеспечиваемых современными инструментальными средствами, относятся:
- графический анализ и проектирование;
- интерактивное прототипирование;
- автоматическое тестирование и верификация программного обеспечения;
|
|
|
- разработка руководства пользователей.
7. Понятие "правильная" по отношению к декомпозиции системы означает следующее:
- количество связей между отдельными подсистемами должно быть минимальным;
- количество подсистем ограничено (не более 8);
- связность отдельных частей внутри каждой подсистемы должна быть максимальной.
8. На сегодняшний день в программной инженерии существуют следующие основные подходы к разработке программного обеспечения АИС, принципиальное различие между которыми обусловлено разными способами декомпозиции систем:
- структурный подход;
- RAD (Rapid Application Development);
- объектно – ориентированный подход;
- системный подход.
9. В основу структурного подхода положен принцип:
- функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами;
- объектной декомпозиции при которой структура системы описывается в терминах объектов и связей между ними;
- инкапсуляции данных.
10. Основными принципами структурного подхода являются:
- «разделяй и властвуй»;
- инкапсуляции;
- модульности;
- иерархической упорядоченности.
11. Основными принципами объектно – ориентированного подхода являются:
- «разделяй и властвуй»;
- инкапсуляции;
- модульности;
- иерархической упорядоченности.
12. Модели, используемые для описания и анализа систем в рамках структурного подхода:
- DFD (диаграммы потоков данных);
- UML – диаграммы;
- SADT (IDEF0) – диаграммы;
- нотации Бекуса – Наура.
13. Основными элементами функциональных SADT – моделей являются:
- блоки;
- накопители данных;
- стрелки информационных потоков;
- дуги.
14. Слева в функциональный блок SADT – модели поступает:
- управляющая информация;
- входная информация;
- результаты выполнения функции предыдущего функционального блока.
15. Управляющая информация в функциональном блоке SADT – модели отображается в виде:
- входящей в блок сверху вертикальной стрелки информационного потока;
- входящей в блок снизу вертикальной стрелки информационного потока;
- входящей в блок в произвольном месте стрелки информационного потока.
16. Между функциональными блоками SADT – модели существуют следующие типы связей:
- временная;
- процедурная;
- коммуникационная;
- иерархическая.
17. Иерархическая декомпозиция SADT – диаграмм осуществляется на основе:
- декомпозиции функций;
- декомпозиции поступающей информации;
- декомпозиции функций, поступающей и выходной информации.
18. Основными элементами диаграмм потоков данных (DFD) являются:
- системы, подсистемы, процессы;
- индикаторы состояний;
- накопители информации;
- блоки принятия решений.
19. Иерархическая декомпозиция диаграмм потоков данных (DFD) осуществляется на основе:
- декомпозиции систем, подсистем, процессов;
- декомпозиции накопителей информации;
- декомпозиции систем, подсистем, процессов, накопителей информации.
20. Поставщиками информации от информационных объектов и других информационных систем в исследуемую информационную систему являются:
- накопители данных;
- внешние сущности;
- носители информации.
21. Для анализа и проектирования автоматизированных информационных систем с применением SADT – моделей и диаграмм потоков данных (DFD) используются специальное программное обеспечение, именуемое:
- СУБД (система управления базами данных);
- язык программирования 4GL;
- CASE – средства.
22. Для анализа и проектирования автоматизированных информационных систем с применением методологии структурного подхода используется:
- CASE – средство BPwin v4.1 Computer Associates;
- CASE – средство Pacestar UML Diagrammer;
- инструментальная среда разработки Borland DELPHI 7.0;
- инструментальная среда разработки программного обеспечения Borland JBuilder 7.
|
|
|
23. CASE – средство BPwin v4.1 Computer Associates создавать модели сложных систем в виде:
- SADT – диаграмм;
- UML – диаграмм;
- диаграмм потоков данных (DFD);
- блок – схем.
24. Основные стадии жизненного цикла программного обеспечения АИС определяются государственным стандартом:
- ГОСТ 34.601-90. Автоматизированные системы. Стадии создания;
- РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов;
- ГОСТ 234.003-90. Автоматизированные системы. Термины и определения.
25. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания включает следующие стадии жизненного цикла программного обеспечения:
- формирование требований к автоматизированной системе;
- технический проект;
- выбор и обоснование инструментальных средств разработки программного обеспечения;
- тестирование.
26. В соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99 и ISO/ IEC 12207 модель жизненного цикла программного продукта представляет собой:
- совокупность разнородных процессов от маркетинговых исследований о целесообразности разработки программного продукта до его приобретения заказчиком;
- структуру, состоящую из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение, т.е. всю жизнь ПС: от установления требований к нему до снятия с эксплуатации;
- набор стадий и этапов разработки и использования программного продукта от принятия решения о его создании до утилизации.
27. Структура жизненного цикла программного обеспечения в соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99 и ISO/ IEC 12207 базируется на следующих группах процессов:
- на основных процессах;
- на дополнительных процессах;
- на организационных процессах;
- на вспомогательных процессах.
28. Основные процессы жизненного цикла в соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99 и ISO/ IEC 12207 включают:
- приобретение;
- поставку;
- управление конфигурацией;
- аудит.
29. Основные процессы жизненного цикла в соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99 и ISO/ IEC 12207 включают:
- разработку;
|
|
|
- верификацию;
- эксплуатацию;
- сопровождение.
30. Вспомогательные процессы, обеспечивающие выполнение основных процессов, в соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99 и ISO/ IEC 12207 включают:
- документирование;
- разработку;
- управление конфигурацией;
- обеспечение качества.
31. Вспомогательные процессы, обеспечивающие выполнение основных процессов, в соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99 и ISO/ IEC 12207 включают:
- верификацию;
- аттестацию;
- аудит;
- поставку.
32. Организационные процессы в соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99 и ISO/ IEC 12207 включают:
- управление проектами;
- верификацию;
- создание инфраструктуры проекта;
- приобретение.
33. Организационные процессы в соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99 и ISO/ IEC 12207 включают:
- определение, оценку и совершенствование жизненного цикла программного средства;
- документирование;
- разрешение проблем;
- обучение.
34. Процесс разработки программного средства заключается в:
- принятии решения о приобретении или разработке программного продукта, выполнении анализа требований к системе автоматизации, анализа рынка продуктов, выработки требований к продукту и составу поддерживающих документов, создания предварительного плана действий;
- выполнении действий и задач поставщика, который должен руководствоваться указаниями по организационным и вспомогательным процессам, определённых договором или контрактом;
- выполнении работ по созданию программного обеспечения в соответствии с заданными требованиями, в том числе оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала и т. д.;
- выполнении работ по внедрению компонентов программного средства, в том числе конфигурирование баз данных, рабочих мест пользователей, обеспечение документацией, проведение обучения персонала и т. д., и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию компонентов ПС в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы.
35. Процесс эксплуатации программного средства заключается в:
- принятии решения о приобретении или разработке программного продукта, выполнении анализа требований к системе автоматизации, анализа рынка продуктов, выработки требований к продукту и составу поддерживающих документов, создания предварительного плана действий;
- выполнении действий и задач поставщика, который должен руководствоваться указаниями по организационным и вспомогательным процессам, определённых договором или контрактом;
- выполнении работ по созданию программного обеспечения в соответствии с заданными требованиями, в том числе оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала и т. д.;
- выполнении работ по внедрению компонентов программного средства, в том числе конфигурирование баз данных, рабочих мест пользователей, обеспечение документацией, проведение обучения персонала и т. д., и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию компонентов ПС в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы.
36. Процесс сопровождения программного средства заключается в:
- принятии решения о приобретении или разработке программного продукта, выполнении анализа требований к системе автоматизации, анализа рынка продуктов, выработки требований к продукту и составу поддерживающих документов, создания предварительного плана действий;
- выполнении работ и задач сопровождающим персоналом; данный процесс реализуется при изменениях (модификациях) программного средства, вызванных возникшими проблемами или потребностями в модернизации;
- выполнении работ по созданию программного обеспечения в соответствии с заданными требованиями, в том числе оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала и т. д.;
- выполнении работ по внедрению компонентов программного средства, в том числе конфигурирование баз данных, рабочих мест пользователей, обеспечение документацией, проведение обучения персонала и т. д., и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию компонентов ПС в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы.
37. Существуют следующие модели жизненного цикла программного обеспечения:
- спиральная модель;
- семантическая объектная модель;
- каскадная модель;
- модель с промежуточным контролем.
38. Достоинства каскадной модели жизненного цикла программного обеспечения:
- на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
- выполняемые в логичной последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты;
- возможность возврата к любой стадии жизненного цикла для продолжения работ или исправления результатов их выполнения.
39. Недостатки каскадной модели жизненного цикла программного обеспечения:
- процесс разработки программного обеспечения носит итерационный характер и не может укладываться в жёсткую схему последовательности разработки программного обеспечения;
- существует проблема определения окончания работ на текущем этапе и перехода к следующей стадии жизненного цикла;
- невозможность корректировки решений принятых на ранних стадиях разработки программного продукта;
- достаточно высокий риск создания программного средства, не удовлетворяющего изменившимся потребностям пользователей.
40. Достоинства спиральной модели жизненного цикла программного обеспечения:
- на каждой стадии формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
- возможность возврата к любой стадии жизненного цикла для продолжения работ или исправления результатов их выполнения;
- выполняемые в логичной последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты;
- возможность создания программного средства, в полной мере удовлетворяющего потребностям пользователей.
41. Недостатки спиральной модели жизненного цикла программного обеспечения:
- процесс разработки программного обеспечения носит итерационный характер и не может укладываться в жёсткую схему последовательности разработки программного обеспечения;
- существует проблема определения окончания работ на текущем этапе и перехода к следующей стадии жизненного цикла;
- невозможность корректировки решений принятых на ранних стадиях разработки программного продукта;
- достаточно высокий риск создания программного средства, не удовлетворяющего изменившимся потребностям пользователей.
42. Инструментальные средства разработки программного обеспечения можно классифицировать на следующие группы:
- традиционные системы программирования;
- инструменты для создания файл-серверных приложений;
- средства автоматизации делопроизводства и документооборота;
- интегрированные средства программирования.
43. Инструментальные средства разработки программного обеспечения можно классифицировать на следующие группы:
- средства разработки приложений клиент-сервер;
- средства разработки Internet/Intranet-приложений;
- СУБД (системы управления базами данных);
- средства автоматизации проектирования программного обеспечения.
44. CASE - средства - это
- инструменты для создания файл-серверных приложений;
- средства разработки приложений клиент-сервер;
- средства разработки Internet/Intranet-приложений;
- средства автоматизации проектирования программного обеспечения.
45. Особенности CASE – средств:
- наличие мощных графических средств для описания и документирования системы, обеспечивающих удобный интерфейс с разработчиком и развивающих его творческие возможности;
- наличие средств быстрого доступа к данным;
- использование специальным образом организованного хранилища проектных метаданных (репозитория);
- наличие средств обеспечения безопасности и целостности данных.
46. CASE – средства можно классифицировать по следующим группам:
- средства анализа и проектирования;
- средства проектирования баз данных;
- средства проектирования клиент – серверных приложений;
- средства управления требованиями.
47. CASE – средства можно классифицировать по следующим группам:
- средства управления конфигурацией программного обеспечения;
- средства документирования;
- средства разработки файл – серверных приложений;
- средства управления проектами.
48. Концептуальной основой объектно-ориентированного подхода является
- информационная модель предметной области;
- модель «AS - IS» деятельности объекта автоматизации;
- объектная модель;
- концептуальная модель.
49. Базовыми принципами объектной модели являются:
- инкапсуляция;
- декомпозиция;
- иерархия;
- структурирование данных.
50. Базовыми принципами объектной модели являются:
- модульность;
- типизация;
- непротиворечивость;
- устойчивость.
51. Базовыми принципами объектной модели являются:
- абстрагирование;
- детализация;
- параллелелизм;
- наследование.
52. Однотипные объекты группируются в:
- массивы объектов;
- классы;
- пакеты;
- мультисписковые структуры.
53. Тип объекта определяется:
- классом, к которому он относится;
- типами данных, определяющими поля объекта;
- пакетом, в который входит класс данного объекта;
- начальными значениями полей объекта.
54. Данные класса (объекта) называются:
- полями класса;
- переменными класса;
- методами класса;
- конструкторами класса.
55. Поименованные операции, реализованные внутри класса, называются:
- полями;
- методами;
- блоками инициализации переменных;
- конструкторами.
56. Для создания объектов классов используются специальные методы именуемые:
- конструкторами;
- модификаторами доступа;
- абстрактными методами;
- финальными методами.
57. Инкапсуляцию элементов классов (полей и методов) обеспечивают специальные ключевые слова именуемые:
- модификаторы доступа;
- идентификаторы;
- лексемы;
- модификаторы реализации.
58. Основные принципы объектно – ориентированной технологии программирования:
- инкапсуляция;
- модульность;
- полиморфизм;
- наследование.
59. UML – это
- язык программирования класса 4GL;
- язык манипуляции реляционными данными;
- унифицированный язык моделирования;
- средство управления проектами по разработке программного обеспечения.
60. Нотации диаграмм классов включают:
- прямоугольники, разделённые на две или три области;
- ромбы;
- направленные линии;
- овалы.
61. Подход RAD предусматривает наличие следующих составляющих:
- небольших групп разработчиков (от 3 до 7 человек), выполняющих работы по проектированию отдельных подсистем программного обеспечения;
- короткого, но тщательно проработанного производственного графика (до 3 месяцев);
- спиральную модель жизненного цикла разработки программного обеспечения;
- использование языков программирования 4GL.
62. Тестирование включает:
- определение тестов, в том числе следующих возможностей: ввода тестовых наборов, генерации тестовых наборов, генерации тестовых данных, ввода ожидаемых результатов, генерации ожидаемых результатов;
- «захват» операторского ввода и выполнение тестируемой программы между контрольными точками;
- анализ тестовых результатов;
- создание документации на выполненное тестирование – протоколов тестирования.
63. Тестирование включает:
- управление тестами (test driving), т. е. выделение и работа с участками программы, для которых CASE-средство может автоматически выполнять тестовые наборы;
- регрессионное тестирование, т. е. возможность тестирования с возвратом от более сложных тестов к простым;
- выполнение анализа производительности программы;
- выполнение проверки качества разработанных тестов и условий верификации.
64. Виды тестирования программных продуктов и АИС:
- комплексное тестирование;
- пробное тестирование;
- эксплуатационное тестирование;
- квалификационное тестирование.
65. UML включает следующие типы диаграмм:
- диаграммы вариантов использования;
- диаграммы переходов состояний;
- диаграммы классов;
- диаграммы поведения системы.
66. UML включает следующие типы диаграмм:
- диаграммы взаимодействия;
- диаграммы последовательности;
- семантические объектные диаграммы;
- диаграммы потоков данных.
67. UML включает следующие типы диаграмм:
- кооперативные диаграммы;
- ER – диаграммы;
- диаграммы состояний;
- диаграммы переходов состояний.
68. UML включает следующие типы диаграмм:
- диаграммы деятельностей;
- семантические объектные диаграммы;
- диаграммы «Сущность - связь»;
- диаграммы реализации.
69. UML включает следующие типы диаграмм:
- функциональные диаграммы;
- диаграммы компонентов;
- диаграммы Парето;
- диаграммы размещения.
70. Диаграммы вариантов использования применяются для:
- формализации функциональных требований к системе;
- построения концептуальной модели проектируемой системы;
- представления статической структуры исследуемой системы;
- моделирования процесса обмена сообщениями между объектами.
71. Диаграммы классов применяются для:
- формализации функциональных требований к системе;
- построения концептуальной модели проектируемой системы;
- представления статической структуры исследуемой системы;
- моделирования процесса обмена сообщениями между объектами.
72. Диаграммы взаимодействий применяются для:
- формализации функциональных требований к системе;
- построения концептуальной модели проектируемой системы;
- представления статической структуры исследуемой системы;
- моделирования процесса обмена сообщениями между объектами.
73. Диаграммы компонентов применяются для:
- представления статической структуры исследуемой системы;
- моделирования процесса обмена сообщениями между объектами;
- обеспечения многократного использования отдельных фрагментов программного кода;
- представления концептуальной и физической схем баз данных.
74. Диаграммы реализации применяются для:
- представления статической структуры исследуемой системы;
- физического представления моделей систем;
- обеспечения многократного использования отдельных фрагментов программного кода;
- представления концептуальной и физической схем баз данных.
75. База данных – это ……..
- самодокументированная совокупность интегрированных записей;
- структурированная и систематизированная информация о некоторой предметной области;
- совокупность сведений об объекте, процессе или явлений;
- интегрированные данные различных форматов, объединённые в некотором общем хранилище.
76. Модель данных – это ………
- язык описания данных;
- средство описания структуры данных;
- средства построения структуры данных;
- совокупность концепций, используемых для описания структуры набора информации.
77. СУБД – это ……….
- прикладная программа, обеспечивающая манипуляции данными в базах данных;
- программный продукт, включающий комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования баз данных многими пользователями;
- инструментальное средство разработки приложений баз данных.
78. Банк данных – это …………
- несколько интегрированных баз данных;
- комплекс информационных, технических, программных, языковых и организационных средств, обеспечивающих сбор, хранение, поиск и обработку данных;
- база данных большой информационной ёмкости.
79. Существуют следующие модели данных:
- сетевая модель;
- реляционная модель;
- семантическая модель;
- постреляционная модель.
80. Существуют следующие модели данных:
- продукционная модель;
- объектно-ориентированная модель;
- модель «Сущность - связь».
81. Существуют следующие модели данных:
- иерархическая модель;
- семантические сети;
- многомерная модель;
- концептуальная модель.
82. Модель данных, отображающая данные в виде двумерной плоской таблицы – это …
- сетевая модель;
- многомерная модель;
- реляционная модель.
83. Модель данных, описывающая данные в виде графа, каждый узел которого имеет ровно одного родителя, называется ……..
- сетевой моделью;
- иерархической моделью;
- объектно-ориентированной моделью.
84. Модель данных, описывающая данные в виде графа, каждый узел которого имеет произвольное количество связей с другими узлами, называется ……..
- сетевой моделью;
- иерархической моделью;
- объектно-ориентированной моделью.
85. Модель данных, представляющая данные в виде множества классов и экземпляров этих классов – объектов, называется …………
- реляционной моделью;
- иерархической моделью;
- многомерной моделью;
- объектно-ориентированной моделью.
86. Модель данных, представляющая данные в виде трёхмерного гиперкуба или гиперкуба большей размерности, называется …………
- реляционной моделью;
- постреляционой моделью;
- многомерной моделью;
- объектно-ориентированной моделью.
87. Модель данных, представляющая данные в виде двумерной таблицы, для которой не соблюдаются нормальные формы, называется ………….
- реляционной моделью;
- постреляционой моделью;
- многомерной моделью;
- объектно-ориентированной моделью.
88. Этапы проектирования баз данных:
- обследование объекта автоматизации;
- системный анализ предметной области;
- разработка технического задания;
- датологическое проектирование.
89. Этапы проектирования баз данных:
- обследование объекта автоматизации;
- инфологическое моделирование;
- разработка технического задания;
- датологическое проектирование.
90. Этапы проектирования баз данных:
- выполнение рабочего проекта;
- системный анализ предметной области;
- физическое проектирование;
- выбор и обоснование СУБД и других средств разработки базы данных и приложения.
91. Обследование объекта автоматизации, изучение информационных потоков на объекте автоматизации и форм представления информации (документов), методов её обработки осуществляется на этапе:
- инфологического моделирования;
- системного анализа предметной области;
- физического проектирования.
92. Выделение информационных объектов в исследуемой предметной области и определение информационных связей между ними осуществляется на этапе:
- инфологического моделирования;
- системного анализа предметной области;
- физического проектирования.
93. Для того, чтобы инфологическую модель исследуемой предметной области преобразовать в датологическую модель базы данных необходимо:
- преобразовать информационные объекты в таблицы базы данных;
- по информационным объектам создать таблицы базы данных;
- выбрать СУБД, средствами которой будет создаваться база данных.
94. Создание таблиц базы данных в терминах выбранной СУБД и определение связей между ними осуществляется на этапе:
- инфологического моделирования;
- системного анализа предметной области;
- датологического проектирования;
- физического проектирования.
95. Размещение базы данных на реальном физическом носителе информации и организация доступа к ней осуществляется на этапе:
- инфологического моделирования;
- системного анализа предметной области;
- физического проектирования.
96. На ER – диаграмме в классических нотациях связи обозначаются:
- прямоугольниками;
- ромбами;
- овалами;
- параллелограммами.
97. На ER – диаграмме в классических нотациях атрибуты сущностей обозначаются:
- прямоугольниками;
- ромбами;
- овалами;
- параллелограммами.
98. На семантических объектных диаграммах связи между информационными объектами обозначаются:
- составными объектами, имеющими объектные атрибуты, присутствующие в каждом из взаимосвязанных семантических объектов;
- ромбами;
- прямоугольниками;
- вообще не обозначаются.
99. Типы связей, существующие между информационными объектами:
- все – к - одному;
- многие – ко – многим;
- один – к – одному;
- один – ко – всем.
100. Типы связей, существующие между информационными объектами:
- один – ко – многим;
- многие – ко – многим;
- один – к – одному;
- один – ко – всем.
101. Множество значений атрибута информационного объекта называется:
- картежем;
- доменом;
- предикатом;
- областью определения.
102. Столбец реляционной таблицы называется:
- доменом;
- картежем;
- полем;
- записью.
103. Строка реляционной таблицы называется:
- доменом;
- картежем;
- полем;
- записью.
104. Поле реляционной таблиц имеет:
- имя (идентификатор);
- тип данных;
- размер;
- формат.
105. Поле реляционной таблиц имеет:
- ограничения целостности, накладываемые на его значения;
- тип данных;
- размер;
- формат.
106. Между двумя реляционными таблицами могут быть определены следующие типы связей:
- один – к – одному;
- многие – ко – многие;
- один – ко – многим;
- многие – к – одному.
107. Нормализация отношений при проектировании реляционной базы данных необходима для:
- устранения избыточности данных;
- устранения различных аномалий (вставки, удаления);
- ускорения доступа к базе данных;
- упрощения организации данных в базе данных.
108. Нормализация баз данных позволяет достичь:
- высокой скорости доступа и обработки данных;
- минимального объёма хранимых данных;
- дублирования данных больших объёмов;
- нарушений целостности базы данных.
109. Основным положением первой нормальной формы является ………..
- все поля базы данных должны иметь одиночные значения, не допускаются массивы и повторяющиеся группы;
- все неключевые атрибуты функционально зависят от всего ключа;
- отношение не имеет транзитивных зависимостей;
- отношение не имеет многозначных зависимостей.
110. Основным положением второй нормальной формы является ………..
- все поля базы данных должны иметь одиночные значения, не допускаются массивы и повторяющиеся группы;
- все неключевые атрибуты функционально зависят от всего ключа;
- отношение не имеет транзитивных зависимостей;
- отношение не имеет многозначных зависимостей.
111. Основным положением третьей нормальной формы является ………..
- все поля базы данных должны иметь одиночные значения, не допускаются массивы и повторяющиеся группы;
- все неключевые атрибуты функционально зависят от всего ключа;
- отношение не имеет транзитивных зависимостей;
- отношение не имеет многозначных зависимостей.
112. Основным положением четвёртой нормальной формы является ………..
- все поля базы данных должны иметь одиночные значения, не допускаются массивы и повторяющиеся группы;
- все неключевые атрибуты функционально зависят от всего ключа;
- отношение не имеет транзитивных зависимостей;
- отношение не имеет многозначных зависимостей.
113. Нормальная форма более высокого порядка предполагает выполнение нормальных форм:
- всех предыдущих;
- одной предшествующей;
- никаких;
- только тех, которые указаны в формулировке нормальной формы.
114. К средствам манипуляции реляционными данными относят:
- теорию предикатов;
- реляционное исчисление;
- реляционную алгебру;
- формальную теорию L.
115. К средствам манипуляции реляционными данными относят:
- язык структурированных запросов SQL;
- язык запросов по образцу QBE;
- теорию предикатов (формальную теорию К);
- формальную теорию L.
116. К операторам языка SQL относятся:
- SELECT;
- ABSTRACT;
- LOGICAL;
- FROM.
117. К операторам языка SQL относятся:
- WHERE;
- INSERT;
- AFTER;
- BETWEEN.
118. В SQL – запросах для указания таблицы, из которой будет происходить выборка данных, указывается оператор:
- SELECT;
- ABSTRACT;
- LOGICAL;
- FROM.
119. В SQL – запросах для указания условия выборки данных указывается оператор:
- WHERE;
- INSERT;
- AFTER;
- BETWEEN.
120. В SQL – запросах для указания диапазона выборки данных указывается оператор:
- WHERE;
- INSERT;
- AFTER;
- BETWEEN.
121. Информационное хранилище – это ……….
- систематизированные и структурированные электронные данные различных форматов, а также средства доступа к ним;
- интегрированные данные, имеющие определённую структуру и методы доступа;
- несколько баз данных;
- несколько баз и банков данных.
122. Принципы построения информационных хранилищ:
- интеграция данных;
- историчность;
- непротиворечивость;
- оптимальность.
123. Основным параметром, в соответствии с которым формируются «слои» информационного хранилища является:
- логические зависимости между данными;
- время;
- скорость доступа;
- время выборки данных.
124. Основными компонентами информационного хранилища являются:
- репозиторий хранимой информации;
- средства администрирования контента информационного хранилища;
- СУБД;
- одна или несколько баз данных.
125. На сегодняшний день известны следующие архитектуры организационных систем обработки данных:
- системы удалённого доступа;
- локальные сети с выделенным сервером;
- клиент – серверные системы;
- одноранговые локальные вычислительные сети.
126. На сегодняшний день известны следующие архитектуры организационных систем обработки данных:
- системы удалённого администрирования;
- локальные сети с выделенным сервером;
- файл – серверные системы;
- распределённые базы данных.
127. Архитектура систем обработки данных, при которой обработка данных по запросу пользователя ведётся на сервере, называется:
- системой удалённого доступа;
- локальной сетью с выделенным сервером;
- клиент – серверной системой;
- одноранговой локальной вычислительной сетью.
128. Архитектура систем обработки данных, при которой обработка данных по запросу пользователя ведётся на клиентской ПЭВМ, называется:
- системой удалённого доступа;
- файл – серверной системой;
- клиент – серверной системой;
- одноранговой локальной вычислительной сетью.
129. Этапами жизненного цикла базы данных являются:
- проектирование;
- создание;
- разработка рабочего проекта;
- реализация.
130. Этапами жизненного цикла базы данных являются:
- разработка технического проекта;
- эксплуатация;
- сопровождение;
- утилизация.
131. Информационная база автоматизированной информационной системы может быть представлена в виде:
- совокупности типизированных файлов;
- базы данных;
- информационного хранилища;
- разнородных информационных массивов.
132. Автоматизированная информационная система – это ………
- комплекс информационных, технических, программных, языковых и организационных средств, обеспечивающих сбор, хранение, поиск и обработку данных;
- совокупность средств, методов сбора, передачи, обработки информации и преобразования её в информационный продукт;
- человеко – машинная система, включающая в состав технические средства, реализующая одну или несколько информационных технологий, позволяющая решать задачи обработки информации или осуществлять поддержку функций управления.
133. Автоматизированные информационные системы по признаку структурированности задач можно классифицировать на:
- структурированные, частично структурированные и неструктурированные;
- формализуемые и слабо формализуемые;
- однозадачные, многозадачные.
134. Автоматизированная информационная система включат следующие технологические подсистемы:
- техническое обеспечение;
- типовое обеспечение;
- технологическое обеспечение;
- программное обеспечение.
135. Автоматизированная информационная система включат следующие технологические подсистемы:
- эргономическое обеспечение;
- многофункциональное обеспечение;
- организационное обеспечение;
- правовое обеспечение.
136. Автоматизированная информационная система включат следующие технологические подсистемы:
- документационное обеспечение;
- стандартное обеспечение;
- информационное обеспечение;
- математическое обеспечение.
137. В соответствии с ГОСТ 34601 – 90 «Автоматизированные системы. Стадии создания» жизненный цикл АИС включает стадии:
- технико – экономическое обоснование целесообразности создания АИС;
- создание эскизного проекта;
- разработка технического задания;
- выбор оптимального варианта технического проекта системы.
138. В соответствии с ГОСТ 34601 – 90 «Автоматизированные системы. Стадии создания» жизненный цикл АИС включает стадии:
- тестирование;
- техническое проектирование;
- ввод в действие;
- верификация;
- функционирование, сопровождение, модернизация.
139. В соответствии с ГОСТ 34601 – 90 «Автоматизированные системы. Стадии создания» жизненный цикл АИС включает стадии:
- исследование и обоснование создания системы;
- верификация;
- рабочее проектирование;
- валидация.
140. Логический порядок следования этапов проектирования АИС в ГОСТ 34601 – 90 «Автоматизированные системы. Стадии создания»:
- исследование и обоснование создания системы (1); создание эскизного проекта (2); разработка технического задания (3); рабочее проектирование (4); техническое проектирование (5); ввод в действие (6); функционирование, сопровождение, модернизация (7);
- исследование и обоснование создания системы (1); разработка технического задания (2); создание эскизного проекта (3); техническое проектирование (4); рабочее проектирование (5); ввод в действие (6); функционирование, сопровождение, модернизация (7);
- исследование и обоснование создания системы (1); разработка технического задания (2); создание эскизного проекта (3); рабочее проектирование (4); техническое проектирование (5); ввод в действие (6); функционирование, сопровождение, модернизация (7).
141. В современной индустрии разработки программного обеспечения известны следующие технологии проектирования автоматизированных информационных систем:
- типовая технология проектирования,
- нисходящее проектирование,
- модульное проектирование,
- индустриальное проектирование.
142. В современной индустрии разработки программного обеспечения известны следующие технологии проектирования автоматизированных информационных систем:
- каноническая технология проектирования,
- нисходящее проектирование,
- модульное проектирование,
- индустриальное проектирование.
143. Классификатор – это …….
- документ, с помощью которого осуществляется формализованное описание экономической информации в АИС,
- признак, в соответствии с которым классифицируется информация в иерархических системах классификации,
- признак объекта, на основании которого он может входить в некоторую классификационную группировку.
144. Экономическая информация существует в виде:
- экономических показателей,
- файлов на магнитных носителях,
- реквизитов,
- документов.
145. Экономические показатели бывают:
- обобщающие показатели,
- реквизиты – основания,
- реквизиты – признаки,
- относительные показатели.
146. Системы классификации информации характеризуются:
- ёмкостью системы,
- степенью заполненности системы,
- объёмом классифицируемого множества,
- уровнями иерархии,
- гибкостью системы.
147. Известны следующие системы классификации информации:
- иерархическая,
- семантическая,
- параметрическая,
- многоаспектная.
148. К многаспектным системам классификации информации относятся:
- фасетная,
- кластерная,
- дескрипторная,
- многоуровневая,
- иерархическая.
149. Достоинства иерархической системы классификации:
- использование большого числа признаков классификации и их значений для создания группировок,
- простота построения,
- использование независимых классификационных признаков в различных ветвях иерархической структуры,
- возможность простой модификации всей системы классификации без изменения структуры существующих группировок.
150. Достоинства фасетной системы классификации:
- использование большого числа признаков классификации и их значений для создания группировок,
- простота построения,
- использование независимых классификационных признаков в различных ветвях иерархической структуры,
- возможность простой модификации всей системы классификации без изменения структуры существующих группировок.
151. Недостатки иерархической системы классификации информации:
- сложности внесения изменений в классификационные группировки,
- невозможность группировки объектов по заранее не предусмотренным сочетаниям признаков,
- сложность построения.
