Управление

объектом

СУБД

ОС

Моделирование управления.

Известно два типа моделей управления:

1. Модель централизованного управления.

2. Модель событийного управления.

1. В этой модели одна подсистема выделяется как системный контроллер. Ёе обязанности – руководить работой других систем.

Две разновидности:

• Модель вызов – возврат.

Главная

программа

Подпрограмма 2

Подпрограмма 1

Подпрограмма 2.1

Подпрограмма 1.2

Подпрограмма 1.1

Подпрограмма 1.1.1

• Модель менеджера. Она используется в системах параллельной обработки.

Процессы-

-датчики

Процессы-

-исполнители

Вычислительные процессы

Процессы-

-обработчики отказов

Системный

контроллер

Пользовательский интерфейс

2. Здесь системой управляют внешние события. Две разновидности:

   • Широковещательная модель. Каждая подсистема уведомляет обработчика о своём интересе к конкретным событиям. Когда событие происходит, обработчик пересылает его подсистеме, которая может обработать это событие. Функции управления в обработчик не встраиваются.

Подсистема

2

Подсистема

1

Подсистема

N

Обработчик событий и

сообщений

• Модель управляемая прерываниями. Здесь все прерывания разбиты

на группы – Типы прерываний, которые образуют вектор прерываний.

Для каждого типа прерывания есть свой обработчик.Каждый обработ-

чик реагирует на свой тип прерывания и запускает свой процесс.

Прерывания

Вектор В

В

Обработчик

1

Процесс

1

ектор прерывания

Декомпозиция подсистем на модули. Модульность.

Известны два типа моделей модульной декомпозиции:

1. Модель типа данных(Разбиение по функциям);

2. Модель объектов.(Эта модель основана на слабо сцеплённых единицах имеющих собственные наборы данных состояния и наборы операций).

Выбор типа декомпозиции зависит от сложности разбиваемой подсисте-мы.

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

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

X – Проблема

C(X) – Сложность решения проблемы X

T(X) – Затраты на решение X

Пусть p1,p2 – Проблемы

C(p1) > C(p2) => T(p1) > T(p2)

C(p1+p2) > C(p1) + C(p2)

T(p1+p2) > T(p1) + T(p2)

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

Стоимость

Стоимость

Общая стоимость интерфейса

Стоимость

одного модуля

Количество

Область min стоимости модулей

Нет корректного критерия для гарантированного предсказания точки оптимума. Оптимальный модуль должен удовлетворять двум критериям:

1. Снаружи он проще чем внутри;

2. Его проще использовать чем построить.

Информационная закрытость.

Принцип информационной закрытости. Содержание модулей должно быть скрыто друг от друга.

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

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

Обеспечивается возможность разработки модулей различными независимы-ми коллективами. Обеспечивается лёгкая модификация системы.