Файл: 7.docx

Экзаменационный билет № 7

Утверждаю

Проректор по учебной работе

_____________ С.В. Михайлов

" " мая 2014 г.

Кафедра бизнес-информатики

Итоговый междисциплинарный экзамен по специальности «Прикладная информатика в экономике». Специализации «Информационные системы в банковском деле»

1. Архитектура операционных систем.

Большинство современных операционных систем представляют собой хорошо структурированные программные модули системы, приспособленные к развитию, расширению и переносу на другие аппаратные платформы. Какой-либо единой архитектуры операционных систем не существует, но существуют универсальные подходы к структурированию ОС.

Есть ОС на ядре, а есть микроядерная.

1. Архитектура операционной системы,
   основанная на ядре

При реализации этой архитектуры все программные модули ОС делятся на модули ядра и вспомогательные модули.

Ядро операционной системы образуют программные модули, решающие внутрисистемные задачи организации вычислительного процесса.

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

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

Формат программного модуля ядра обычно отличается от формата приложений.

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

Рис. 1.3. Нечеткость границы между операционной системой и приложениями

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

Вычислительную систему, работающую под управлением операционной системы на основе ядра, можно рассматривать как систему, состоящую из трех иерархически расположенных слоев:

1. Микроядерная архитектура

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

В состав микроядра входят машинно-зависимые модули, а также модули, выполняющие функции базовых механизмов обычного ядра:

• по управлению процессами;

• обработке прерываний;

• управлению виртуальной памятью;

• управлению устройствами ввода-вывода, связанными с загрузкой или чтением регистров устройств.

Все остальные функции ядра оформляются в виде приложений, работающих в пользовательском режиме.

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

Очевидно, что для реализации микроядерной архитектуры необходимым условием является наличие в ОС удобного и эффективного способа вызова процедур одного процесса из другого. Поддержка такого механизма и является одной из главных задач микроядра (рис. 1.5).

Рис.1.5. Иллюстрация системного вызова в микроядерной архитектуре

Преимущества микроядерной архитектуры:

• Высокая степень переносимости, обусловленная тем, что весь машинно-зависимый код изолирован в микроядре, поэтому для переноса системы на новый процессор требуется меньше изменений и они все сгруппированы вместе.

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

• Легкая конфигурируемость ОС – достаточно изменить файл с настройками начальной конфигурации системы или же остановить ненужные больше серверы (менеджеры ресурсов) в ходе работы системы обычными для остановки приложений средствами.

• Повышенная надежность ОС – каждый сервер выполняется в виде отдельного процесса в своей собственной области памяти и таким образом защищен от других серверов ОС, что не наблюдается в традиционных ОС, где все модули ядра могут влиять друг на друга. Кроме этого, уменьшенный объем кода ядра снижает вероятность появления ошибок программирования.

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

Недостаток микроядерной архитектуры:

• Более низкая производительность, чем при классической архитектуре – системный вызов сопровождается не двумя переключениями режима (пользовательского и привилегированного), а четырьмя (рис. 1.5 и 1.6).

2. Нотация DFD. Виды нотаций DFD. Синтаксис DFD.

ОПР.: В DFD (Data Flow Diagram), модель системы определяется как иерархия диаграмм потоков данных, описывающих процессы преобразования информации от момента ее ввода в систему до выдачи конечному пользователю. Диаграммы верхних уровней иерархии - контекстные диаграммы, задают границы модели, определяя её окружение (внешние входы и выходы) и основные рассматриваемые процессы. Контекстные диаграммы детализируются при помощи диаграмм следующих уровней.

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

Если же для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Признаками сложности (в смысле контекста) могут быть:

• наличие большого количества внешних сущностей (десять и более);

• распределенная природа системы;

• многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.

Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.

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

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

После построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами).

Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или миниспецификации. При детализации должно выполняться правило балансировки. Суть этого правила сводится к тому, что при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь детализируемая подсистема или процесс на родительской диаграмме;

Миниспецификация (описание логики процесса) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.

Миниспецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании миниспецификации принимается аналитиком исходя из следующих критериев:

• наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока);

• возможности описания преобразования данных процессом в виде последовательного алгоритма;

• выполнения процессом единственной логической функции преобразования входной информации в выходную;

• возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20-30 строк).

Синтаксис DFD включает четыре основных элемента:

• поток данных;

• процесс;

• хранилище;

• внешняя сущность.

Рассмотрим эти элементы подробнее.

Поток данных

ОПР.: Поток данных соединяет выход объекта (или процесса) с входом другого объекта (или процесса). Он представляет промежуточные данные вычислений. Поток данных изображается в виде стрелки между производителем и потребителем данных, помеченной именами соответствующих данных. Упрощенно можно считать, что потоки данных являются механизмами, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую.

Потоки на диаграммах изображаются стрелками (обычно именованными), ориентация которых указывает направление движения информации (Error: Reference source not found).

ОПР.: Процесс преобразует значения данных.

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

Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующим дополнением (например, «выдать пропуск»). Кроме того, каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.

ОПР. 1: Накопители данных предназначены для изображения неких абстрактных устройств для хранения информации, которую можно туда в любой момент времени поместить или извлечь, безотносительно к их конкретной физической реализации. Накопители данных являются неким прообразом базы данных информационной системы организации.

ОПР. 2: ХРАНИЛИЩЕ (НАКОПИТЕЛЬ) ДАННЫХ позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое и быть существительным. В случае, когда поток данных входит или выходит в/из хранилища, и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме.

ОПР. 1: ВНЕШНЯЯ СУЩНОСТЬ (или ТЕРМИНАТОР) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

ОПР. 2: Под внешней сущностью (External Entity) понимается материальный объект, являющийся источником или приемником информации.

В качестве внешней сущности на DFD диаграмме могут выступать заказчики, поставщики, клиенты, склад, банк и другие.

3. Запустить виртуальную машину с установленным MS SQLServer и перенести на этот сервер учебную базу bank2010, backup-копия которой находится в папке Studbackup сервера app. Создать диаграмму, проверить работоспособность базы, вывести содержимое таблиц.