Автор работы: Пользователь скрыл имя, 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
Операция проверитьСледующийШлю
Вместо только что описанной архитектуры мы могли бы ввести для каждого прибора по одному экземпляру задач Интерфейс кнопок, Интерфейс датчика функционирования шлюзов, Интерфейс датчика исправления ошибок и Диспетчер. При наличии одного процессора такое решение нежелательно из-за слишком больших накладных расходов.
Но в многопроцессорной среде для каждого прибора допустимо иметь свой процессор, на котором будут выполняться экземпляры задач Интерфейс кнопок, Интерфейс датчика функционирования шлюза, Интерфейс датчика исправления ошибок и Диспетчер. Задачи Монитор контроля функционирования шлюзов и Монитор контроля исправления ошибок удобно разместить на отдельном процессоре. В случае нескольких ЦП с общей памятью объект абстрагирования данных Состояние по-прежнему хранился бы в разделяемой памяти.
Если же процессоры не располагают общей памятью, то несколько задач не смогут напрямую обращаться к объекту Состояние. Далее мы опишем проект распределенной системы управления приборами.
Физическая конфигурация распределенной системы управления прибором состоит из нескольких узлов, соединенных локальной сетью. В такой среде необходимо установить дисциплину, согласно которой все коммуникации между распределенными подсистемами происходят путем обмена сообщениями. Общая архитектура распределенного ПО показана на рис.16, где представлено несколько экземпляров Подсистемы управления шлюзами, несколько экземпляров Подсистемы шлюзов (по одной на каждый пункт) и один экземпляр подсистемы Диспетчер. Все коммуникации между подсистемами осуществляются посредством слабо связанного обмена сообщениями.
В распределенной конфигурации нет разделяемой памяти, а значит, Диспетчер и экземпляры Подсистемы управления исправлением ошибок не могут напрямую обратиться к объекту абстрагирования данных Состояние, как было в предыдущем случае. Один из способов решить проблему - поместить такой объект в серверную задачу. Вместо того чтобы вызывать операцию объекта абстрагирования данных, клиентская задача отправит синхронное сообщение с ответом задаче Сервер Состояния и Плана работы системы исправления ошибок. Но при этом сервер может стать узким местом, поскольку у него есть довольно много клиентов. Альтернативное решение – применение репликации данных. Каждый экземпляр Подсистемы управления исправлением ошибок хранит собственный локальный объект Локальное Состояние и План работы системы исправления ошибок. Есть такой объект и у Диспетчера, только в нем содержатся состояния и называется он Сводное Состояние и План работы системы исправления ошибок.
Рис. 16. Архитектура распределенного ПО
В распределенном проекте для каждого шлюза имеется по одному экземпляру Подсистемы управления исправлением ошибок, включающему по одному экземпляру задач Интерфейс кнопки включения, Интерфейс кнопки исправления ошибок, Интерфейс кнопки включения автомата, Интерфейс кнопки выключения, Интерфейс Датчика исправления ошибок и Диспетчер. Кроме того, каждый экземпляр Подсистемы управления исправлением ошибок хранит собственный локальный экземпляр объекта абстрагирования данных Состояние.
Архитектура задач для Подсистемы управления исправлением ошибок показана на рис.17. Она аналогична архитектуре для нераспределенного решения с тем отличием, что экземпляров подсистем существует несколько.
Пересмотренная архитектура задач показана на рис.18. Здесь изображены интерфейсы задач, а также способ доступа к объектам, скрывающим информацию. Проект объекта абстрагирования данных Локальное Состояние проще, чем для централизованного решения.
На этапе конфигурирования целевой системы каждый экземпляр Подсистемы управления исправлением ошибок обычно отображается на узел физического прибора, поэтому программы в каждом узле исполняются независимо от всех остальных.
Рис.17. Архитектура задач для подсистемы управления исправлением ошибок
Рис.18. Архитектура задач для подсистемы управления исправлением ошибок: интерфейсы задач
В описанном выше распределенном решении существует по одному экземпляру Подсистемы шлюзов для каждого шлюза. В каждом таком экземпляре есть по одному экземпляру задач Интерфейс датчика неполадок шлюза и Интерфейс датчика исправления ошибок.
Архитектура задач для Подсистемы шлюзов показана на рис. 19. Она аналогична архитектуре для нераспределенного решения с тем отличием, что экземпляров подсистем существует несколько. Интерфейсы задач для пересмотренной архитектуры изображены на рис. 20.
Рис. 19. Архитектура задач для подсистемы шлюзов
Рис. 20. Архитектура задач для подсистемы шлюзов: интерфейсы задач
Существует единственный экземпляр Подсистемы шлюзов, которая состоит из двух задач и одного скрывающего информацию объекта. Это объект абстрагирования данных Сводное Состояние, который содержит текущее состояние каждого шлюза, описывающий, существует ли неполадка в работе шлюза или нет.
В любом узле доступ к объекту Локальное Состояние осуществляется со стороны задач Диспетчер. Серверная задача принимает сообщения о состоянии шлюза и обновляет объект Сводное Состояние, а координирующая задача принимает Запросы на обслуживание от нескольких экземпляров задачи Интерфейс кнопок. Каждый раз при получении сообщения Запрос на обслуживание задача Диспетчер проверяет, по отношении к какому шлюзу осуществляется запрос. Архитектура задач для Подсистемы диспетчера показана на рис. 21. Интерфейсы задач для пересмотренной архитектуры изображены на рис. 22.
Рис. 21. Архитектура задач для подсистемы диспетчера
Рис. 22. Архитектура задач для подсистемы диспетчера: интерфейсы задач
После определения интерфейсов задач во всех подсистемах можно обновить архитектуру распределенной программы с целью показа интерфейсов подсистем (см. рис. 23). На самом деле все интерфейсы принадлежат той или иной из ранее рассмотренных задач.
Рис. 23. Архитектура распределенной программы: интерфейсы подсистем
Сами классы были определены на этапе разбиения на объекты, теперь речь пойдет о проектировании их операций. Классы абстрагирования данных описаны выше; в этом разделе мы разработаем остальные классы, скрывающие информацию.
Класс интерфейса устройства скрывает истинный интерфейс с физическим устройством, предлагая вместо него виртуальный интерфейс. Для каждого типа устройств ввода/вывода имеется отдельный интерфейсный класс. Состав операций, поддерживаемых таким классом, зависит от функций, которые должен поддерживать объект интерфейса. Классы интерфейса устройств изображены на рис.24 и описаны ниже:
– Интерфейс Кнопок Прибора. Предоставляет две операции: читать (считывает значение датчика кнопки прибора) и инициализировать;
– Интерфейс Датчика Яркости. Предоставляет две операции: читать (считывает значение датчика поломок) и инициализировать;
– Интерфейс Поля индикации. Предоставляет две операции: читать (считывает значение поля индикации) и инициализировать;
В системе есть только один зависящий от состояния класс Управление дамбой. Он поддерживает две операции: обработать состояние и текущее состояние. Этот объект вложен в задачу Диспетчер. Поскольку задача существует в нескольких экземплярах, то и экземпляров класса будет несколько – по одному для каждого прибора. Спецификация класса Управление дамбой представлена на рис.25.
Рис. 24. Классы интерфейса устройств
Рис. 25. Зависящий от состояния управляющий класс
Итак, задачи и скрывающие
информацию классы определены. Далее
нужно выполнить детальное
На этапе детального проектирования интерфейсы описываются более точно с помощью объектов-разъемов, как показано на рис.26. Так, объекту Диспетчер поступают сильно связанные сообщения, не требующие ответа. Данный интерфейс отображается на объект-разъем Буфер сообщений диспетчера. Обычно такого рода разъем существует между одним производителем и одним потребителем, однако в нашем случае есть две задачи-производителя – Интерфейс датчика наличия неполадок и Интерфейс датчика исправления ошибок, которые отправляют сообщения Диспетчеру (при этом последний находится в различных состояниях).
Диспетчер является производителем в трех интерфейсах со слабо связанным обменом. Во всех трех случаях потребители находятся в других распределенных подсистемах. Следовательно, мы будем использовать три очереди-разъема (см. рис.26), которые скрывают детали асинхронного обмена сообщениями с потенциально удаленными задачами, Очередь сообщений диспетчера инкапсулирует детали обмена с Диспетчером, а Очередь сообщений датчика наличия неполадок и Очередь сообщений датчика исправления ошибок – детали обмена с Подсистемой шлюзов.
В распределенном приложении разъемы следует проектировать так, чтобы они могли во время выполнения определить, находится задача-получатель в том же или в удаленном узле. Отправители не должны знать о расположении получателей. Такая независимость от места позволит реализовать гибкую стратегию конфигурирования, при которой распределенные подсистемы проектируются в виде распределенных компонентов. Экземпляры таких компонентов отображаются на физические узлы на этапе конфигурирования.
Рис. 26. Проектирование разъемов диспетчера
Рассмотрим теперь проектирование
составной сгруппированной
Любой объект интерфейса асинхронного устройства ввода/вывода помещается внутрь асинхронной задачи, поддерживающей это устройство. Например, все экземпляры объектов Интерфейс кнопки включения, Интерфейс кнопки выключения, Интерфейс кнопки включения автомата, Интерфейс кнопки исправления ошибок принадлежат задаче Интерфейс кнопок.
Рис. 27. Детальный проект диспетчера
На этапе конфигурирования
целевой системы производится
отображение подсистем на
Рис.24. Диаграмма развертывания нераспределенной системы управления дамбой.
В этом разделе мы применим теорию планирования в реальном времени к анализу производительности распределенного варианта системы управления дамбой.
Суммарное затраченное время на исправление одной неполадки рассчитывается по формуле:
Затраченное время = время обработки запроса от кнопок + время, необходимое рабочим, чтобы добраться до шлюза + время исправления неполадки + время поступления сигнала от датчиков наличия неполадок и исправления ошибок.
Время обработки запроса от кнопок в худшем случае составляет 1 сек. Время наступления очередной неполадки невозможно предугадать, обозначим его как t. Время поступления сигнала от датчика наличия неполадок занимает в худшем случае также 1 сек. На принятие решения об отправке рабочих для исправления неполадок оператор тратит в среднем 5 с. Время, необходимое рабочим, чтобы добраться до шлюза, в котором произошла неполадка, занимает в среднем 300 секунд. Время исправления неполадки зависит от сложности ремонта, но в среднем составляет 3600 сек. Все в сумме дает в среднем 3909 сек.
Если после включения системы оператор решил использовать автомат, то нужно учитывать время, требующееся на принятие решения о включении автомата. Оно занимает в среднем 5 с.
На принятие решения о выключении системы требуется также в среднем 5 с.
Рассмотрим соответствующие прецеденты последовательности событий в распределенной системе (рис.29).
Последовательность событий «Запуск системы»