И. Соммервилл - Инженерия программного обеспечения (1133538), страница 55
Текст из файла (страница 55)
10.6 представлена модель централизованного управления для параллслыюй спстемьь Подобная молель часто используется в "мягких" системах реального времени, в которьш нет чересчур строгих временнмх ограничений. Центральный контроллер управ. лает выполнением ьшожества процессов, связанных с датчиками и исполнительными механизмами. Система, использующая такую модель управления, рассмотрена в главе 13. 10. Архитектурное проектирование 215 Рис. 10.6. Модель цгнэг1гплизогл нного укрп влгтл гил пгсэгглгы Ргаааного вркчгкк Контроллер системы, в зависимости от псрсмснных состояния системы, определяет моменты запуска или завершения процессов. Он проверяет, гснсрирустся ли в остальных процессах информация, для того чтобы затем обработать сс или передать другим процессам на обработку.
Обычно контроллср работает постоянно, проверяя датчики и другие процессы или отслеживая изменения состояния, поэтому данную модель иногда называют моделью с обратной связью. 10.2.2. Системы, управляемые событиями В моделях централизованного управлсния, как правило, управление систсмой опрсдс. ллстся значсниями некоторых псрсмснных сс состояния. В противоположность таким моделям существуют системы, управление которыми основано на внсиннх событиях.
В данном контекста под гобьилкгм подразумсвастсл пс только бинарный сигнал типа "да-пст". Здссь сигнал может принимать некоторый диапазон значений. Различие между событием и обычными входными данными заключастсл в том, что плапироваиис события выходит за рамки управления процсссом, обрабатывающилг это событис. Длл обработки события подсистеме необходим доступ к информации состоянил, однако такая информация обычно нс опрсдслястся потоком управлсния.
Разработано множество различных типов событийноэправлясмых систем. К ним о гиосятся элсктропиыс таблицы, в которых измснснис значсния в какой-либо лчсйкс измсилсг содср. жилггю других ячссгг, системы искусственного интсллскга, в которых нрн выиол1юшпг игкоторого условия происходит ипициировапис действия либо используются активиыс об ьскт ы, то. гда при изменении значения свойства объскга ипициирустсл пскоторос дсйствис. В кингс [128) подробно рассматриваются разлпчныс типы событнйно управлясмых снстсм. В этом раздслс описаны двс модели систем, управляемых событиями. 1.
Модглк ггглгдачи сообщений. В этих моделях событис прсдсгавляст собой псрсдачу со. общения всем подсистсмам. Любав подсистема, которал обрабатываст даппос событие. отвсчвст на него. 2. Модели, угглааляемыг луггРмэлггигмгк. Такие модсли обычно используются в системах реального врсмсни, гдс внсшнис прерывания регистрируются обработчиком прсрываиии, а обрабатываются другим системным компонснтом. 216 'Часть 1П. Проектировавие Модели передачи сообщений эффективны при интеграции подсистем, распределенных на разных компьютерах, которые объединены в сеть. Модели, управляемые прерываниями, используются в системах реального времени со строгими временными требованиями. В модели передачи сообщений (рис. 10.7) подсистемы реагируют на определенные события.
Если произошло некоторое событие, управление переходит к подсистеме, обрабатывающей данное событие. Между моделью передачи сообщений и моделью централизованного управления, показанной иа рис. 10.6, существует отличие: алгоритм управления не встроен в обработчик сообщений и событий. Подсистемы определяют, какие события им требуются, а обработчик сообщений и событий следит, чтобы данные события были отправлены именно им. Рис. 10. 7. Модель управления, оеиоеииная ио иередиче еообя1еиий Все события могут генерировать сообщения всем подсистемам, но при этом значительно увеличивается нагрузка при обработке данных. Часто обработчик событий и со.
общений управляет регистром подсистем и событиями, на которые онн реагируют. Подсистемы генерируют события, в которых, возможно, есть данные для обработки. Обработчик регистрирует событие. принимая во внимание его регистр, и передаег это событие в те подсистемы, которые на него'реагируют. Обработчик события всстда поддерживает двухточечное взаимодействие. Поэтому подсистемы могут явно отправить сообщение другой подсистеме. Существует множество разновидностей атой модели [291, 114, 14е1.
Брокеры запросов к объектам, обсуждаемые в главе 11, также поддерживают данную модель управления при взаимодействии между распределенными объектами. Преимуществом модели передачи сообщений является относительно простая модернизация систем, построенных в соответствии с этой моделью. Новую подсистему можно интегрировать в систему, регистрируя ее события в обработчике событий. Каждая под. система может активизировать любую дру|ую подсистему, не зная ее имени или размещения.
Подсистемы также можно реализовать на разных машинах. Недостатком данной модели является то, что подсистемам неизвестно. когда произой. дет обработка события. Генерируя событие, подсистема не знает, какая именно система прореагирует на него. Вполне допустима ситуация, когда разные подсистемы реагируют на одинаковые события. Это может привести к конфликтам при получении доступа к резулы а г|м обработки события. Системы реального времени, в которых одним из требований является быстрая обработка внешних событий, должны быть событийно. управляемыми. Например, система реального времени, управляющая системой безопасности автомобиля, должна определить возможную аварию и успеть наполнить воздухом подушку безопасности до того, как голова водителя ударится о руль.
Для того чтобы обеспечить быструю реакцию на события, необходимо использовать управление, основанное на прерываниях. На рис. 10.8 показана модель управления, основанная на прерываниях. Для каждого типа прерываний существует свой обработчик. Каждый тип прерывания ассоциируется с 10. Архитектурное проектирование 217 ячейкой памяти, в которой хранится адрес обработчика прерывания. При получении определенного прерывания аппаратный переключатель немедленно передает управление обработчику прерывания. В ответ на событие, вызванное прерыванием, обработчик мо.
жег запустить или завершить другие процессы. Прериэанин Рис. 10.8. Модель у«фаеление, опьманнаа на «увуяееаиьэл Данная модель используется только в жестких системах реального времени, где требуется немедленная реакция на определенные события. Можно скомбинировать эту модель с моделью централизованного управления. Центральный диспетчер обрабатывает нормальный ход выполнения системы, а в критических ситуациях используется управление, основанное на прерываниях. Преимуществом такого подхода является мгновением реакция системы на происходящие события, недостатками — сложность программирования и аттестации системы. Практически невозможно имитировать все прерывания в процессе тестирования системы.
Сложно изменять системы, разработанные на основе такой модели, так как число преры. ваний ограничено аппаратурой. Никакие другие типы событий не обрабатываются, если достигнут этот предел. Ограничение иногда можно обойти, если на одном прерывании определить несколько типов событий и предоставить для их обработки отдельный обработчик. Однако, если требуется очень быстрая реакция на прерывание, такой подход ока.
зывается непрактичным, 10.3. Модульная декомпозиция После этапа разработки системной структуры в процессе проектирования следует этап декомпозиции подсистем на модули. Между разбивкой системы на подсистемы и подсистем на модули нет принципиальных отличий. На этом этапе можно использовать модели, рассмотренные в разделе 10.1. Однако компоненты модулей обычно меньше компонентов подсистем, поэтому можно использовать специальные модели декомпозиции. Здесь рассматриваются две модели, используемые на этапе модульной декомпозиции подсистем.
1. Обэекюноориенюэуюеа«ная модель. Система состоит из набора взаимодействующих объектов. 218 'Часть П1. Проектирование 2. Модель яомэков дпкных Система состоит из функциональных модулей, которые получают на входе данные и преобразуют их некоторым образом в выходные данные. такой подход часто называется конвейерным. В объектно-ориентированной модели модули представляют собой объекты с собственными состояниями и определенными операциями над этими состояниями.
В модели потоков данных модули выполняют функциональные преобразования. В обеих моделях модули реализованы либо как последовательные компоненты, либо как процессы. По возможности разработчикам не стоит принимать поспешных решений о том, будет лн система параллельной или последовательной. Проектирование последовательной системы имеет ряд преимуществ: последовательные программы легче проектировать, реализовать, проверять и тестировать, чем параллельные системы, где очень сложно формализовать, управлять и проверять временнв~е зависилюсти между процессами. Лучше сначала разбить систему на модули, а на этапе реализации решить, как организовать их выполнение — нослеловательно или параллельно. 10.3.1. Объектные модели Объектноориентированная архитектурная модель структурирует систему в виде совокупности слабо связанных объектов с четко определенными интерфейсами.
Объекты вы. зывают сервисы, предоставляемые другими объектами. С некоторыми объектными моде. лями вы познакомились в главе 7, более подробно они рассматриваются в главе 12. На рис. 10.9 представлен пример объектно. ориентированной архитектурной модели лля системы обработки счетов, Данная система выписывает счета заказчикам, получает платежи, отправляет квитанции по поступившим платежам и уведомления по неоплаченным счетам. В этом примере используется система нотации лзыка моделирования 11М1. (сьь главу 7), в которой классы объектов имеют имена и набор атрибутов.
Операции, если онн есть, определяются в нижней части прямоугольника, обозначающего объект. Штриховые стрелки означают, что объекты используют свойства или сервисы, предоставляемые другилп~ объектами. 1 1 1 ! 1 ! Ркс. 10.9. Обманная модель сисеемы об~>аботкк счетов 1!а этапе объектно-ориентированной декомпозиции определяются кчассы объектов, пх свойства н операции.
При реализации системы из этих классов создаются объекты; для координации операций обьсктов используется какая-либо модель управления. В нашем 10. Архитектурное проектирование 219 конкретном примсрс класс Счет имеет различные свяэанныс операции (ььстоды), которые реализуют функциональные средства системы. Этот класс использует другис классы, представляющис заказчиков, платежи и квитанции.
Преимущества объектно. ориентированного подхода хорошо известны, Поскольку объскты слабо связаны между собой, можно иэмсиять реализацию того или иного объекта, нс воэдсйствуя на остальные объекты. Структуру системы легко понять, так как объскты часто являются объектами реального мира. Для непосредственной реализации систсмных компонснтов можно использовать объскгно.орисьпированныс языки программирования. Вместе с том объсктночьриснтированиый подход имеет и недостатки. При испольэо.
нанни сервисов объекты должны явно ссылаться на имска других объектов и знать их иптсрфсйс. Если при иэмснснии системы требуется измснить интерфейс, необходимо оценить эффект от такого изменсния с учетом всех пользователей изменяемого объекта. Многие объекты реального мира сложно представить в виде системных объектов. 10.3.2. Модели потоков данных В управляемой потоками данных модсли данные проходят через послсдоватсльпость преобразований.
Каждый шаг обработки данных реализован в виде преобразования. Данныс, поступающие на вход системы, проходят чсрсэ всс преобразования и достигают выхода системы, Преобразования моьут выполняться последовательно или параллельно. Обработка данных можят быть пакетной или поэлемснтной.
Если преобразования представлены в виде отдельных процсссов, такую модсль иногда на. выкают конвсйсром или моделью фильтров, следуя терминологии, принятой в системс Пппс Последнял поддерживаст конвсйсры, которые дсйствуют как хранилища данных, и набор ко. манд, представляющих функциопальпыс прсобраэования. Здесь использустся тсрмнн "фильтр", поскольку преобразование "фильтр)чт" данные ао врача обработки потока данньж. Различные варианты модели потоков данных возникли вместе с появлснисм первых компьютеров, прсдназначснных для автоматизированной обработки данных.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
