Автор работы: Пользователь скрыл имя, 26 Августа 2013 в 00:10, курсовая работа
Данная система должна управлять работой дамбы. Она должна отвечать на команды операторов, а также автоматически управлять исправлением ошибок.
Прежде всего, нужно разработать аналитическую модель и отобразить ее сначала на централизованный, а потом на распределенный проект.
Введение 3
1. Описание задачи 4
2. Модель прецедентов 5
2.1. Прецедент «Запуск системы» 5
2.2. Прецедент «Исправление ошибки функционирования дамбы» 5
2.3. Прецедент «Остановка системы» 6
2.4. Абстрактные прецеденты 6
2.5. Абстрактный прецедент «Автоматический режим работы системы» 7
2.6. Абстрактный прецедент «Планирование работы системы управления дамбой» 8
2.7. Конкретный прецедент «Запуск системы» 8
2.8. Конкретный прецедент «Исправление ошибки функционирования дамбы» 9
3. Статическая модель предметной области 10
4. Разбиение на объекты 12
5. Динамическая модель 13
5.1. Диаграмма кооперации для прецедента «Запуск системы» 13
5.2. Диаграмма кооперации для прецедента «Исправление ошибок» 14
5.3. Диаграмма кооперации для прецедента «Остановка системы» 16
5.4. Консолидация диаграмм кооперации 17
6. Разбиение на подсистемы 19
7. Разбиение системы на задачи 22
7.1. Выделение задач в подсистеме управления исправлением ошибок 23
7.2. Выделение задач в подсистеме шлюзов 24
7.3. Выделение задач в подсистеме диспетчера 25
7.4. Определение интерфейсов задач 26
7.5. Проектирование класса абстрагирования данных 28
7.6. Обсуждение альтернативных архитектур 30
8. Проект распределенной системы управления дамбой 31
8.1. Структура подсистемы управления дамбой 32
8.2. Структура подсистемы шлюзов 34
8.3. Структура подсистемы диспетчера 36
8.4.Интерфейсы подсистем 37
9. Проектирование скрывающих информацию классов 38
9.1. Проектирование классов интерфейса устройств 38
9.2. Проектирование класса, зависящего от состояния 38
10. Разработка детального проекта программы 40
10.1. Проектирование объектов-разъемов 40
10.2. Проектирование составных задач 41
11. Конфигурирование целевой системы. 43
12. Анализ производительности системы управления дамбой. 44
12.1. Сценарий для анализа производительности 44
12.2. Последовательности событий 45
Заключение 47
Список литературы 48
E5: Поступил Запрос кнопки исправить ошибку объекту Интерфейс кнопки исправления ошибки.
E6: Объект Интерфейс кнопки исправления ошибки посылает Запрос на обслуживание объекту Диспетчер.
Е7: Объект Диспетчер передает Запрос объекту Интерфейс Датчика исправления ошибок в шлюз.
Е8: Объекты Интерфейс Датчика исправления ошибок передают Запрос Датчику исправления ошибок.
E9: Поступил Запрос кнопки включения автомата объекту Интерфейс кнопки включения автомата.
E10: Объект Интерфейс кнопки включения автомата посылает Запрос на обслуживание объекту Диспетчер.
Е11: Объект Диспетчер передает Запрос объекту Интерфейс датчика функционирования шлюза.
Е12: Объекты Интерфейс датчика функционирования шлюза передают Запрос Датчику функционирования шлюза.
Рис. 6. Диаграмма кооперации для прецедента «Исправление ошибок»
Диаграмма кооперации для прецедента Остановка системы изображена на рис.7.
Система останавливается кнопкой «Стоп», передача запросов осуществляется Диспетчером. Вот описание последовательности сообщений:
А1: Поступил Запрос кнопки выключения объекту Интерфейс кнопки выключения.
А2: Объект Интерфейс кнопки выключения посылает Запрос на обслуживание объекту Диспетчер.
Рис. 7. Диаграмма кооперации для прецедента «Остановка системы»
Результат консолидации диаграмм кооперации, описывающих все три прецедента, показан на рис.8. Некоторые объекты принимают участие в нескольких прецедентах. Так, объекты Интерфейс кнопки включения, Интерфейс датчика функционирования шлюза, Датчик функционирования шлюза, Интерфейс датчика исправления ошибок и Датчик исправления ошибок участвуют в прецедентах Запуск системы и Исправление ошибок. Другие объекты – к примеру, Интерфейс кнопки выключения и Интерфейс кнопки включения автомата – задействованы только в одном прецеденте.
Для объектов, которые принимают участие лишь в одном прецеденте, все взаимодействия изображены на диаграмме кооперации, описывающей этот прецедент. Если же объект занят в нескольких прецедентах, его взаимодействия представлены на разных диаграммах и объединены на консолидированной диаграмме кооперации.
На консолидированной диаграмме кооперации должны присутствовать все взаимодействия объектов.
В результате консолидации мы получаем диаграмму кооперации, которая описывает все вышеописанные прецеденты.
Рис. 8. Управление дамбой: консолидированная диаграмма кооперации
На следующем шаге система разбивается на подсистемы. Поскольку потенциально это приложение является распределенным, то, прежде всего, применяются рекомендации, касающиеся географического местоположения и агрегирования/композиции.
В частности, все кнопки, отвечающие за работу системы, и связанные с процессом управления исправлением ошибок являются частями составного объекта Подсистема управления исправлением ошибок. С другой стороны, объекты Датчик функционирования шлюза и Интерфейс датчика исправления ошибок входят в состав шлюза, они образуют составной объект Подсистема шлюза. Наконец, объект-координатор Диспетчер помещается в своей собственной подсистеме, поскольку не зависит ни от шлюзов, ни от процесса исправления ошибок.
На рис. 9 показана общая структура разбиения на подсистемы управления исправлением ошибок, шлюзов и диспетчера. Подсистема управления исправлением ошибок – это управляющая подсистема, Подсистема шлюзов – подсистема сбора данных, а подсистема Диспетчер - координирующая. Структура Подсистемы управления исправлением ошибок представлена на рис.10, а Подсистемы шлюзов – на рис.11.
Рис. 9. Разбиение на подсистемы
Рис. 10. Структура подсистемы управления исправлением ошибок
Рис. 11. Структура подсистемы шлюзов
Дополнительно разрабатывается уточненная статическая модель, изображаемая на диаграмме классов. Эта диаграмма выводится из общей архитектуры подсистем и структуры каждой подсистемы. На диаграмме классов отражены все классы, из которых создаются объекты, представленные на диаграммах кооперации, а также отношения между этими классами, то есть сами кооперации. На рис.12 приведена уточненная статическая модель, в которой каждая подсистема предстает в виде составного класса. Становится очевидным, как программные понятия соответствуют статической модели предметной области, созданной ранее (см. рис.3). Так, составной класс Подсистема управления дамбой включает несколько классов, в том числе классы интерфейса устройств, например Интерфейс кнопки включения, Интерфейс кнопки выключения, Интерфейс кнопки включения автомата и Интерфейс кнопки исправления ошибок, которые взаимодействуют с внешними классами, в частности Датчик функционирования шлюза и Датчик исправления ошибки, представленными в статической модели. Аналогичные наблюдения справедливы в отношении составного класса Подсистема шлюзов и его составляющих. Операции каждого класса определены в разделах 9.5 и 11, посвященных проектированию классов.
Далее рассматривается разбиение на задачи. Для этого необходимо проанализировать все объекты на диаграммах кооперации и применить критерии выделения задач. Мы сделаем это для каждой диаграммы по очереди.
В распределенной системе управления исправлением ошибок имеется по одному экземпляру Подсистемы управления исправлением ошибок и по одному экземпляру Подсистемы шлюзов (см. рис. 9). Но, если трактовать систему как нераспределенную, можно кое-что упростить. В данном случае система управления исправлением ошибок отображается на один процессор или сильно связанную многопроцессорную конфигурацию (с общей памятью).
Важным аспектом нераспределенного решения является то, что сущностные объекты Состояние и План работы системы управления дамбой доступен всем шлюзам, равно как и Диспетчеру, то есть их можно расположить в централизованном хранилище данных. Для слабо связанной распределенной системы, в которой нет разделяемой памяти, этот подход не годится. Распределенное решение опишем в разделе 10.
Рис.12. Уточненная статическая модель системы управления исправлением ошибок
Рассмотрим архитектуру задач Подсистемы управления исправлением ошибок для нераспределенного случая.
На диаграмме кооперации Исправление ошибок нужно обратить внимание на объект интерфейса устройства, который получает входную информацию от актера, и затем проследить цепочку взаимодействий. Объект Интерфейс кнопки исправления ошибок выделяется в самостоятельную задачу Интерфейс кнопок (актер нажимает на кнопку для исправления ошибок) с помощью критерия асинхронного интерфейса устройства ввода. Применив инверсию задач, мы проектируем одну задачу, которая будет отвечать за все кнопки системы, вместо того чтобы иметь по одной задаче на каждую кнопку. Задача Интерфейс кнопок активизируется прерыванием, возникающим при нажатии любой кнопки. Затем она считывает входную информацию от кнопки и посылает запрос Диспетчеру, а сама тем временем готовится к приходу следующего прерывания. Диспетчер, который является объектом-координатором, получает сообщения от Интерфейса кнопок в данном прецеденте. Он выделяется в координирующую задачу, активизируемую приходом сообщения Запрос кнопки.
Диспетчер выделяется в отдельную задачу-координатор, которая активизируется асинхронно по событию Включение системы или Выключение системы.
Итак, в нераспределенной системе управления приборами Подсистема управления исправлением ошибок разбивается на две задачи: Интерфейс кнопок и Диспетчер. Предварительная архитектура задач изображена на начальной диаграмме параллельной кооперации (рис.13).
Объекты Интерфейс датчика функционирования шлюза и Интерфейс датчика отправки исправления ошибки выделяются в самостоятельную задачу Интерфейс датчиков на основе критерия асинхронного интерфейса устройства ввода и критерия группировки задач. В случае нераспределенного решения задача Интерфейс датчиков отвечает за обработку ввода внешней информации. Она активизируется прерыванием, обрабатывает его и посылает Запрос на обслуживание объекту Диспетчер, после чего готова к приходу следующего прерывания.
Бывает так, что различные экземпляры задач одновременно посылают запросы датчикам. В таком случае необходимо иметь для каждого устройства задачу-монитор ресурса, которая сможет сериализовать обработку параллельных запросов. Итак, выявилась потребность в задачах Монитор контроля функционирования шлюза, Монитор контроля ошибок. Все объекты Интерфейса датчика функционирования шлюза отображаются на задачу Монитор контроля функционирования шлюза. Все объекты Интерфейса датчика исправления ошибок отображаются на задачу Монитор контроля исправления ошибок. Задачи, из которых состоит Подсистема шлюзов в нераспределенной системе управления прибором, показаны на рис. 13.
В случае нераспределенного решения Диспетчер – это подсистема, которая состоит из одного объекта-координатора, выделенного в задачу. Задача Диспетчер активизируется по запросу, в частности после получения Запроса на обслуживание, и выбирает режим, наиболее подходящий для его удовлетворения.
Поскольку речь идет о нераспределенном решении, очевидно, что Диспетчер может напрямую читать Состояние. Архитектура задач для нераспределенного случая представлена на рис. 13.
Рис.13. Нераспределенная система управления дамбой: архитектура задач
Рассмотрим теперь, как определяются интерфейсы задач. В случае интерфейсов обмена сообщениями между параллельными задачами возможен либо слабо связанный, либо сильно связанный обмен. Необходимо исследовать только интерфейсы между объектами, выделенными в самостоятельные задачи. Кроме того, следует точно описать сообщения, включая их имена и параметры.
Взаимодействие между задачами Интерфейс кнопок и задачей Диспетчер, показанными на рис.13, отображается на слабо связанный обмен сообщениями (рис.14). Тем самым гарантируется, что исполнение задач Интерфейс кнопок не будет приостановлено после отправки сообщения задаче Диспетчер.
Рассмотрим интерфейс между Диспетчером и двумя задачами-мониторами ресурсов: Монитор контроля функционирования шлюза и Монитор контроля исправления ошибок. Диспетчер дает команды управления Монитору контроля функционирования шлюза и команды управления - Монитору контроля исправления ошибок (см. рис. 13). Подобное взаимодействие отображается на слабо связанный обмен сообщениями, так как несколько экземпляров Диспетчера в состоянии одновременно посылать сообщения Монитору контроля функционирования шлюза или Монитору контроля исправления ошибок (см. рис.14) и при этом не должны блокироваться.
Проанализируем пассивные сущностные объекты, к которым обращается сразу несколько задач. Состояние - объект абстрагирования данных, который инкапсулирует состояние прибора. В нераспределенном варианте есть только один экземпляр этого объекта, так что можно использовать централизованное хранилище. К объекту осуществляют доступ несколько экземпляров задачи Диспетчер (см. рис.13). Доступ к пассивному объекту должен быть синхронизирован, чтобы его операции исполнялись взаимно исключающим образом.
Рис.14. Нераспределенная система управления исправлением ошибок: интерфейсы задач
При централизованном подходе есть только один класс абстрагирования данных - Состояние и План работы системы исправления ошибок. Состояние - это текущее состояние шлюза. План работы системы исправления ошибок представляет собой список шлюзов, в которых произошла неполадка. Поскольку есть только один экземпляр указанного класса, мы вправе прибегнуть к централизованному хранилищу, как показано на рис. 15.
Чтобы определить операции класса абстрагирования данных, необходимо понять, как к нему обращаются. На рис. 14 показана задача, обращающаяся к такому объекту: Диспетчер.
Диспетчер читает план и состояние шлюзов с целью выбрать шлюз, в котором произошла неполадка. Эта функция выполняется внутри операции выбратьШлюз. Диспетчер обновляет план работы системы испраления ошибок и проверяет, не произошла ли неполадка в каком-либо шлюзе. Эта функция реализуется операцией обновитьПлан. Каждое из названных сообщений отображается на операцию объекта абстрагирования данных (см. рис. 15).
Рис.15. Классы абстрагирования данных: а – для централизованного решения; б – для распределенного решения
Операция проверитьЭтотШлюз вызывается с параметром Шлюз# и проверяет, существует ли неполадка и обновляет состояние и план работы шлюзов. Операция возвращает СостояниеШлюза: поломка, если в шлюзе произошла неполадка, или норма – в противном случае.