Моделирование управления Событийное управление - ПЕРЕДАЧА СООБЩЕНИЙ

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

+ Каждая подсистема может активизировать любую другую подсистему, не зная ее имени или размещения.

+ Подсистемы также можно реализовать на разных машинах.

- Подсистемам неизвестно, когда произойдет обработка события.

- Генерируя событие, подсистема не знает, какая именно система прореагирует на него.

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

Моделирование управления Событийное управление - ПРЕРЫВАНИЯ

Interrupts

Interrupt

vector

Моделирование управления Событийное управление - ПРЕРЫВАНИЯ

+ Мгновенная реакция системы на происходящие события,

– Сложность программирования и аттестации системы. Практически невозможно имитировать все прерывания в процессе тестирования системы.

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

обрабатываются, если достигнут этот предел. Ограничение

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

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

(Software engineering)

Учебный курс

очного обучения по специальностям 220400 «Программное обеспечение вычислительной техники и автоматизированных систем»

351500 «Математическое обеспечение и администрирование информационных систем» кафедры

Этап архитектурного проектирование Модульная декомпозиция

Цель - воплощение в процессе разработки программ

обоих общих методов борьбы со сложностью: и

(1)обеспечение независимости компонент системы, и (2)использование иерархических структур.

Для воплощения первого метода формулируются

определенные требования, которым должен удовлетворять программный модуль, т.е. выявляются основные характеристики «хорошего» программного модуля.

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

древовидные модульные структуры программ.

Модульная декомпозиция Программный модуль

Модуль — это обычно компонент системы, который предоставляет один или несколько сервисов для других модулей. Модуль может использовать сервисы, поддерживаемые другими модулями. Как правило, модуль никогда не рассматривается как независимая система. Модули обычно состоят из ряда других, более простых компонентов.

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

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

После разработки системной структуры следует этап декомпозиции подсистем на модули. Между разбивкой системы на подсистемы и подсистем на модули нет принципиальных отличий. На этом этапе можно использовать модели, рассмотренные в выше. Однако компоненты модулей обычно меньше компонентов подсистем, поэтому можно использовать специальные модели декомпозиции:

1.Объектно-ориентированная модель. Система состоит из набора взаимодействующих объектов.

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

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

Модульная декомпозиция Характеристики программного модуля

Для оценки приемлемости выделенного модуля используются некоторые критерии. Так, Хольт [R.C.Holt. Structure of Computer Programs: A Survey // Proceedings of the IEEE, 1975, 63(6).] предложил следующие два общих таких критерия:

хороший модуль снаружи проще, чем внутри;

хороший модуль проще использовать, чем построить.

Майерс [Г.Майерс. Надежность программного обеспечения. М.: Мир, 1980] предлагает для оценки приемлемости программного модуля использовать более конструктивные его характеристики:

размер модуля,

связность (прочность) модуля (cohesion),

сцепление с другими модулями (coupling),

рутинность модуля (независимость от предыстории обращений к нему).

Характеристики программного модуля Размер модуля

Размер модуля измеряется числом содержащихся в нем операторов или строк.

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

Обычно рекомендуются программные модули размером от нескольких десятков до нескольких сотен операторов

Здесь еще бы рисунок 4.11 из Орлова

Характеристики программного модуля

Рутинность (независимость от предыстории обращений)

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

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