Разработка распределенной системы автоматизации производства

Разработка распределенной системы автоматизации производства
Рассмотрим проектирование системы автоматизации производ¬ства. Это сильно распределенное приложение с несколькими клиентами и серве¬рами, с компонентом управления в реальном масштабе времени. На этом примере продемонстрируем обмен данными как между клиентами и серверами, так и между равноправными участниками.
На заводе имеется сборочная линия, вдоль которой расположены производственные рабочие станции (рис.1). Лента конвейера перемещает де¬тали между этими станциями. На каждой рабочей станции производятся опреде¬ленные операции с деталью. Поскольку рабочие станции программируемые, то возможно получение различных вариантов готового изделия. Обычно выпускает¬ся серия деталей одного типа, а затем – серия деталей другого типа.
На каждой рабочей станции есть сборочный робот, предназначенный для сборки изделия, и подъемно-транспортный робот, который поднимает детали с конвейера и кладет их обратно. Каждый робот оснащен датчиками и приводами. Датчики используются для мониторинга рабочего состояния (например, обнару¬жения прибытия очередной детали), а приводы – для включения и выключения механизмов (например, конвейера). Первая рабочая станция является приемной, последняя – отгрузочной. Эти станции оборудованы только подъемно-транспорт¬ным роботом. Все остальные станции называются линейными, в них имеется так¬же сборочный робот. Дежурные операторы следят за состоянием станций и тре¬вожными сигналами.
Шаги, необходимые для получения готового изделия из исходного сырья, опи¬сываются технологической картой процесса, подготовленной инженерами-техно¬логами. Карта определяет вид технологического процесса и последовательность производственных операций. Каждая операция выполняется на некоторой рабо¬чей станции.
Обработка новых деталей начинается с того, что начальник производства со¬ставляет наряд-заказ, где указано количество деталей каждого типа.

Рис. 1. Система автоматизации производства
Модель прецедентов
В системе имеются следующие актеры-люди: Начальник Производства, Дежурный Оператор и Инженер-Технолог. Кроме них, есть еще актеры, соот¬ветствующие внешним системам: Сборочный Робот и Подъемно-Транспорт¬ный Робот. Прецеденты сгруппируем в па¬кеты применительно к актерам, которые их инициируют и принимают в них участие. Для каждого из главных актеров в системе автоматизации производства можно определить пакет прецедентов, а именно: Пакет Прецедентов Инженера-Технолога, Пакет Прецедентов Дежурного Оператора и Пакет Прецедентов Начальника Производства.
Пакет прецедентов, которые инициирует Дежурный Оператор (рис. 2):
1. Следить за Сигналами Тревоги. Дежурный оператор следит за сигнала¬ми тревоги и вовремя устраняет причины сбоя. Он вправе также подписать¬ся на извещения о сигналах тревоги заданного вида.
2. Следить за Состоянием Рабочей Станции. Дежурный оператор наблюда¬ет за состоянием одной или нескольких рабочих станций. Разрешается также подписаться на извещения об изменениях в состоянии рабочей станции.
3. Изменить Состояние Рабочей Станции и Известить. Состояние рабо¬чей станции изменяется в ходе функционирования - например, когда начи¬нается или завершается обработка детали. Операторы извещаются о тех из¬менениях, на которые они подписались.
4. Поднять Тревогу и Известить. Если в процессе обработки детали воз¬никло состояние тревоги, генерируется сигнал. Операторы извещаются о тех сигналах тревоги, на которые они подписались.

Рис. 2. Прецеденты Дежурного Оператора
Инженер-технолог определяет несколько производственных операций, а за¬тем создает технологическую карту процесса изготовления детали. С этой целые разрабатываются два прецедента, которые объединяются в Пакет Прецедентов Инженера-Технолога (рис. 3). При создании и изменении операций техно¬лог задействует прецедент Создать/Изменить Операцию, исполняемый для каждой вновь создаваемой операции. Затем инженер-технолог может воспользо¬ваться прецедентом Создать/Изменить Технологическую Карту, чтобы опре¬делить последовательность операций по изготовлению детали. Прецедент Со¬здать/Изменить Технологическую Карту расширяет прецедент Создать/ Изменить Операцию. Поэтому одна из необязательных альтернатив в прецеден¬те Создать/Изменить Операцию – создание технологической карты.

Рис. 3. Прецеденты инженера-технолога
Начальник Производства инициирует прецедент Создать/Изменить На-ряд-Заказ. Он же инициирует более сложный прецедент Изготовить Деталь, который описывает процесс обработки деталей на заводе. Указанные прецеденты объединены в Пакет Прецедентов Начальника Производства (рис. 4). В прецеденте Изготовить Деталь начальник производства создает наряд-заказ на изготовление деталей. Обработка каждой детали начинается на приемной рабо¬чей станции, где на ленту конвейера укладываются исходные компоненты. На сле¬дующей станции компоненты снимаются с конвейера подъемно-транспортным ро¬ботом и обрабатываются сборочным роботом, после чего подъемно-транспортный робот помещает частично обработанную деталь на конвейер, и она передвигается к следующей станции. Описанный процесс продолжается до тех пор, пока готовая деталь не прибудет на отгрузочную станцию, где подъемно-транспортный робот снимет ее для подготовки к отгрузке заказчику. На заводе применяется система опе-ративной поставки. Это означает, что рабочая станция получает деталь только тог¬да, когда она готова ее обработать, так что детали никогда не накапливаются.
Прецедент Изготовить Деталь можно обобщить, выделив три абстрактных прецедента:
1. Принять Деталь. Приемная рабочая станция получает от начальника про¬изводства запрос на изготовление новой детали и отсылает эту деталь на первую линейную станцию.
2. Обработать Деталь на Рабочей Станции. Линейная станция принимает деталь от предыдущей станции (предшественника), выполняет сборочную операцию и отправляет деталь следующей рабочей станции (пре-емнику). Данный прецедент повторяется многократно.
3. Отгрузить Деталь. Последняя линейная станция отправляет готовую де¬таль отгрузочной станции, которая посылает начальнику производства уве-домление о завершении обработки.

Рис. 4. Прецеденты начальника производства
Концептуальная статическая модель предметной области
Статическое моделирование при автоматизации производственных систем особенно важно, так как статические модели предметной области в целом и контекста системы в дальнейшем представимы в виде диаграмм классов.
Статическая модель системы автоматизации производства приведена на рис. 5. Поскольку завод можно считать состоящим из рабочих станций, то класс Завод мо¬делируется как составной, включающий несколько Рабочих Станций. Существует три типа рабочих станций: линейные, приемные и отгрузочные. В модели это отражено с помощью иерархии обобщения/специализации. Класс Рабочая Станция имеет подклассы Приемная Рабочая Станция, Линейная Рабочая Станция и Отгрузочная Рабочая Станция. Так как рабочая станция способна генерировать различные сигналы тревоги, между классом Рабочая Станция и классом Тревога существует отношение один-ко-многим. Рабочая Станция обладает также Состоянием Рабочей Станции, за которым следит Дежурный Оператор.

Рис. 5. Статическая модель системы автоматизации производства
Технологическая карта определяет шаги, необходимые для изготовления де¬тали данного вида. Она состоит из нескольких операций, причем под операцией понимается один шаг обработки, выполняемый рабочей станцией. Следовагельно, имеется ассоциация один-ко-многим между классами Технологическая Карта и Операция. Поскольку конкретная рабочая станция проводит несколько операций, между классами Рабочая Станция и Операция также существует ас¬социация один-ко-многим. Наряд-заказ указывает, сколько должно быть изготовлено деталей данного вида, поэтому класс Наряд-Заказ связан с классом Деталь ассоциацией один-ко-многим. Так как в технологической карте отмечается, и ка¬ком порядке должны обрабатываться все детали одного вида, между классами Технологическая Карта и Деталь также существует ассоциация один-ко-многим.
Атрибуты классов, включенных в статическую модель, приведены на рис. 6. Эти атрибуты необходимо задать до разработки диаграммы кооперации: в неко¬торых случаях они читаются или обновляются.

Рис. 6. Классы и их атрибуты в системе автоматизации производства
На рис. 7 представлены внешние классы, с которыми взаимодействует система. Три из них – работающие с системой люди:
Инженер-Технолог, Начальник Производства и Дежурный Оператор. Рабо¬чие станции являются частью системы, поэтому на диаграмме контекста отсут¬ствуют. С другой стороны, Сборочный Робот и Подъемно-Транспортный робот представляют собой внешние системы, так что они моделируются в виде внешних классов. Каждый робот управляется контроллером, а информа¬ция о производственных операциях, то есть исполняемые роботами программы, загружается из системы автоматизации производства. Сравнение внешних клас¬сов с актерами показывает, что в рассматриваемом примере каждый внешний класс соответствует определенному актеру.

Рис. 7. Внешние классы системы автоматизации производства
Разбиение на объекты
На этапе динамического моделирования анализируется ка¬ким образом объекты принимают участие в прецедентах.
Сущностные объекты живут относительно долго, сохраняя в себе информа¬цию. В данной системе имеются следующие сущностные объекты: Технологическая Карта, Операция, Наряд-Заказ и Деталь. Есть также объекты Состояние Рабочей Станции и Тревога. Сущностные объекты представлены в статической модели на рис. 5, а их атрибуты показаны на рис. 6. Все сущностные объекты являются серверами, к которым обращаются различные объекты-клиенты, поэтому на диаграмме кооперации сущностные объекты будут отображаться как серверные:
Сервер Технологических Карт, Сервер Операций, Сервер Нарядов-Заказов, Сервер Деталей, Сервер Состояний Рабочих Станций и Сервер Сиг¬налов Тревоги.
Для каждого aктeра-человека должен быть объект интерфейса пользователя. Таким образом, появляются объекты Интерфейс Инженера-Технолога, Интер¬фейс Начальника Производства и Интерфейс Дежурного Оператора. Для управления рабочей станцией необходим объект Контроллер Рабочей Станции. Существует один Контроллер Приемной Рабочей Станции, один Контроллер Отгрузочной Рабочей Станции и несколько экземпляров Контроллера Ли¬нейной Рабочей Станции – по одному для каждой линейной станции.
Динамическая модель
Динамические зависимости представлены с помощью динамической модели, которая состоит из диаграмм кооперации и диаграмм состояний.
Диаграммы кооперации соответствуют описанным прецедентам. На них изображаются объекты, определенные выше, прецеденты, в кото¬рых они участвуют, и сообщения, которыми они обмениваются.
Рассмотрим Прецеденты Дежурного Оператора.
Два из них отно¬сятся к типу клиент-сервер, причем клиентом является объект пользовательского интерфейса. Начнем с прецедента Следить за Сигналами Тревоги (рис. 8):

Рис. 8. Диаграмма кооперации для прецедента Следить за Сигналами Тревоги
S1: Оператор направляет запрос сервису сигналов тревоги, информируя о же¬лании посмотреть текущие сигналы или подписаться на извещения о сигна¬лах тревоги некоторого вида.
S1.1: Объект Интерфейс Оператора посылает запрос Серверу Сигналов Тревоги.
S1.2: Следить за Сигналами Тревоги выполняет запрос, в частности считывает список текущих сигналов тревоги или добавляет имя клиента к листу подпис¬ки, а затем посылает ответ объекту Интерфейс Оператора.
S1.3: Объект Интерфейс Оператора отображает оператору ответ, например информацию о сигналах тревоги.
Прецедент Следить за Состоянием Рабочей Станции также являет клиент-серверным и очень похож на предыдущий (рис. 9):

Рис. 9. Диаграмма кооперации для прецедента
Следить за Состоянием Рабочей Станции
VI: Оператор направляет запрос сервису состояний рабочих станций, информируя о желании посмотреть текущее состояние станции.
VI.1: Объект Интерфейс Оператора посылает запрос Серверу Состояний Рабочих Станций.
VI.2: Сервер Состояний Рабочих Станций отвечает, возвращая данные о состоянии указанной рабочей станции.
V1.3: Объект Интерфейс Оператора отображает оператору полученный ответ.
Два других прецедента связаны с подпиской на извещения, когда клиент уведомляется о новых событиях, на которые подписался ранее в рамках клиент-серверного прецедента. Рассмотрим прецедент Поднять Тревогу и Известить (рис. 10):

Рис. 10. Диаграмма кооперации для прецедента Поднять Тревогу и Известить
M1: Объект Контроллер Рабочей Станции получает от внешнего робота информацию о чрезвычайной ситуации.
М2: Объект Контроллер Рабочей Станции отправляет сигнал тревоги Сер¬веру Сигналов Тревоги.
МЗ: Сервер Сигналов Тревоги рассылает тревожное сообщение всем под¬писчикам, выразившим интерес к извещениям этого вида.
М4: Объект Интерфейс Оператора принимает извещение о тревоге и выво¬дит информацию.
Прецедент Изменить Состояние Рабочей Станции и Известить очень похож на предыдущий (рис. 11):

Рис. 11. Диаграмма кооперации для прецедента
Изменить Состояние Рабочей Станции и Известить
N1: Объект Контроллер Рабочей Станции получает от внешнего робота информацию об изменении состояния рабочей станции, например о том, что обработка детали закончена.
N2: Объект Контроллер Рабочей Станции направляет сообщение о состоя¬нии рабочей станции Серверу Состояний Рабочих Станций.
N3: Сервер Состояний Рабочих Станций рассылает сообщение, содержа¬щее новое состояние станции, всем подписчикам, выразившим интерес к из¬вещениям этого вида.
N4: Объект Интерфейс Оператора принимает сообщение о состоянии рабо¬чей станции и выводит информацию.

Далее рассмотрим прецеденты планирования процесса производства, инициируемые Инженером-Технологом.
Технолог создает описания производственных операций, а затем составляет из них технологическую карту. В эту категорию попадают два прецедента: Создать/Изменить Операцию и Создать/Изменить Технологи¬ческую Карту, причем второй расширяет первый (см. рис.3). Рассмотрим преце¬дент Создать/Изменить Операцию (рис.12):

Рис. 12. Диаграмма кооперации для прецедента Создать/Изменить Операцию и Создать/Изменить Технологи¬ческую Карту
О1: Инженер-Технолог вводит информацию, необходимую для создания операции, с помощью объекта Интерфейс Инженера-Технолога. Сюда вхо¬дит название операции, тип рабочей станции и используемые программы для роботов.
О1.1: Объект Интерфейс Инженера-Технолога посылает запрос Создать Операцию объекту Сервер Операций.
О1.2: Сервер Операций отвечает сообщением Информация об Операции.
О1.3: Объект Интерфейс Инженера-Технолога выводит Информацию об Операции инженеру-технологу. Инженер может повторить весь процесс для создания следующей операции.
Перейдем к прецеденту Создать/Изменить Технологическую Кар-ту (рис. 12), который расширяет предыдущий прецедент, поскольку технологическая карта создается из операций, определенных в прецеденте Создать/Изменить Операцию:
Р2: Инженер-Технолог вводит информацию, необходимую для создания тех¬нологической карты, с помощью объекта Интерфейс Инженера-Техноло¬га. Сюда входит название карты, тип детали, сырье и информация о первой операции.
Р2.1: Объект Интерфейс Инженера-Технолога посылает сообщение Со¬здать Технологическую Карту объекту Сервер Технологических Карт.
Р2.2: Сервер Технологических Карт направляет запрос Серверу Операций.
Р2.3: Сервер Операций возвращает информацию о запрошенной операции.
Р2.4: Сервер Технологических Карт посылает Информацию о Техноло¬гической Карте объекту Интерфейс Инженера-Технолога.
Р2.5: Объект Интерфейс Инженера-Технолога выводит полученные данные Инженеру-Технологу. Инженер включает в технологическую карту новые операции.
Перейдем к прецеденту Создать/Изменить Наряд-Заказ, инициируемому Начальником Производства.
На этом этапе происходит обращение к трем сущностным объектам – Серверу Нарядов-Заказов, Серверу Деталей и Серверу Технологических Карт (рис.13):

Рис. 13. Диаграмма кооперации для прецедента
Создать/Изменить Наряд-Заказ
R1: Начальник Производства с помощью объекта Интерфейс Начальни¬ка Производства определяет Задание на Производство, в частности тип подлежащей изготовлению детали.
R1.1: Объект Интерфейс Начальника Производства посылает запрос Сер¬веру Технологических Карт, который извлекает информацию о карте, со¬ответствующей указанному типу детали.
R1.2: Сервер Технологических Карт направляет Информацию о Техноло¬гической Карте объекту Интерфейс Начальника Производства.
R1.3: Объект Интерфейс Начальника Производства отображает получен¬ные сведения.
R2: Начальник Производства вводит данные о наряде-заказе с помощью объекта Интерфейс Начальника Производства. Сюда входит название на¬ряда-заказа, тип детали и число подлежащих изготовлению деталей.
R2.1: Объект Интерфейс Начальника Производства посылает сообщение Создать объекту Сервер Нарядов-Заказов.
R2.2: Сервер Нарядов-Заказов передает Серверу Деталей запрос Создать для каждой указанной в наряде детали.
R2.3: Сервер Деталей подтверждает запрос на создание деталей.
R2.4: Сервер Нарядов-Заказов возвращает информацию о наряде-заказе объекту Интерфейс Начальника Производства.
R2.5: Полученная информация отображается пользователю.
Прецеденты распределенного управления
Далее рассмотрим сложный прецедент Изготовить Деталь, он инициируется начальником производства и описывает различные стадии обра¬ботки детали на заводе. В прецеденте участвуют три разных вида контроллеров рабочих станций: Контроллер Приемной Рабочей Станции, Контроллер Ли¬нейной Рабочей Станции и Контроллер Отгрузочной Рабочей Станции. Экземпляров объекта Контроллер Приемной Рабочей Станции столько же, сколько линейных станций, и все они соединены последовательно. После того как начальник производства создал наряд-заказ, Контроллеру Приемной Рабочей Станции посылается сообщение Начать Изготовление Детали, где указаны идентификатор детали и нужное количество. На основании данного сообщения следует получить, а затем уложить на конвейер исходное сырье для каждой изго¬тавливаемой детали. На отгрузочной станции объект Контроллер Отгрузочной Рабочей Станции снимает готовые детали с конвейера и перемещает их в зону отгрузки.
Алгоритм оперативной поставки гарантирует, что рабочая станция будет за¬прашивать деталь только тогда, когда она готова к ее получению, поэтому детали нигде не накапливаются. Когда некоторая станция завершает свою часть обработ¬ки детали, она ждет сообщения с запросом детали от своего преемника. Как толь¬ко сообщение получено, Контроллер Рабочей Станции посылает Подъемно-Транспортному Роботу команду Положить деталь на конвейер. Затем контроллер отправляет преемнику сообщение Идет Деталь, а предшественнику - сообщение Запрос Детали. Контроллер Приемной Рабочей Станции рассчитывает, сколь¬ко деталей осталось изготовить по данному наряду-заказу. Контроллер Отгру¬зочной Рабочей Станции удаляет готовые детали с конвейера для подготовки к отгрузке и посылает Интерфейсу Начальника Производства сообщение Де¬таль Готова.
В процессе изготовления детали можно выделить три абстрактных прецеден¬та (рис. 4):
А. Принять Деталь. Контроллер приемной рабочей станции отправляет деталь первому контроллеру Линейной рабочей станции.
В. Обработать Деталь на Рабочей Станции. Контроллер линейной рабо¬чей станции N посылает деталь контроллеру N+1. Этот прецедент повторяет¬ся несколько раз.
С. Отгрузить Деталь. Контроллер последней линейной рабочей станции пе¬редает деталь контроллеру отгрузочной рабочей станции.
Конкретный прецедент обработки детали, которая должна пройти через w линейных рабочих станций, включает одно исполнение прецедента A, (w-1) исполнений прецедента В и одно исполнение прецедента С. Все три абстрактных пре¬цедента показаны на диаграмме кооперации, им соответствуют события А, В, С.
Поскольку Контроллер Рабочей Станции – это зависящий от состояния управляющий объект, для его определения используется диаграмма состояний.
Диаграмма состояний контроллера линейной рабочей станции включает в себя две диаграммы: Обработка Детали и Запрос Детали. Они представлены в виде надсостояний на диаграмме верхнего уровня и разделены пунктирной линией (рис.14). В любой момент времени контроллер находится в одном из подсостояний состояния Обработка Детали (рис.15), которое соответствует текущей стадии обработки детали на данной станции, и в одном из подсостояний состояния Запрос Детали (рис.16), которое свидетельствует, поступил ли от преемника запрос на деталь. Внутри объекта Контроллер Рабочей Станции нет никакого параллелизма, просто так удобнее моделировать эти относительно независимые события.

Рис. 14. Диаграмма состояний контроллера линейной рабочей станции: надсостояния

Рис. 15. Диаграмма состояний контроллера линейной рабочей станции:
подсостояние Обработка Детали

Рис. 16. Диаграмма состоянии контроллера линейной рабочей станции:
подсостояние Запрос Детали
Надсостояние Обработка Детали содержит следующие подсостояния (пере¬ходы между ними рассмотрим при описании диаграмм кооперации):
Ожидание Детали от Предшественника. Это начальное состояние, в ко¬тором рабочая станция ждет поступления детали;
Деталь на Подходе. Контроллер линейной рабочей станции переходит в данное состояние после получения от предшественника сообщения, ин¬формирующего о том, что деталь уже движется по конвейеру;
Робот Поднимает. Переход в указанное состояние осуществляется, когда деталь дошла до рабочей станции. Подъемно-транспортный робот снимает деталь с ленты конвейера и переносит ее на рабочую станцию;
Сборка Детали. В это состояние контроллер линейной рабочей станции переходит, получив сообщение о том, что деталь готова к обработке. Сборочный робот начинает с ней взаимодействовать;
Робот Возвращает. Подъемно-транспортный робот возвращает деталь на конвейер для отправки станции-преемнику. Переход в такое состояние производится, если сборочный робот закончил операцию, и от преемника уже поступил запрос на деталь;
Ожидание Запроса Детали от Преемника. Переход в данное состояние реализуется, когда робот завершил сборку, но запроса на деталь от преемника еще нет.
В надсостоянии Запрос Детали есть следующие подсостояния:
Нет Запроса на Деталь. От станции-преемника еще не пришел запрос;
Поступил Запрос на Деталь. От станции-преемника поступил запрос.
Эти два подсостояния выступают в роли условий, проверяемых внутри диаграммы Обработка Детали при решении вопроса о том, в какое состояние перейти, когда сборочный робот закончил обработку детали.
Прецеденты изготовления детали
Рассмотрим прецеденты, связанные с изготовлением детали
(рис.14-19). Контроллеры отгрузочной и всех рабочих станций посылают сообщение Запрос Детали своим предшественникам на стадии инициа-лизации. Этому соответствуют сообщения В2 и С2, показанные также на диаграм¬ме состояний (рис.15). Начальник производства инициирует главную последовательность событий путем создания наряда-заказа (А1). Чтобы повысить степень повторной применимости абстрактного прецедента, нужно разрешить объекту из одного прецедента посылать сообщение объекту из другого прецедента. Номера сообщений в названных прецедентах обычно различаются, но мы будем говорить, что они эквивалентны.
При инициализации системы происходят следующие события:
Bl,C1: Запуск Рабочей Станции. Когда осуществляется это внутреннее со¬бытие, Контроллер Рабочей Станции переходит в состояние Ожидание Де¬тали от Предшественника (рис.15).
В2,С2: В момент перехода состояний Контроллер Рабочей Станции посы¬лает своему предшественнику сообщение Запрос Детали. Данное сообщение показано на диаграмме Обработка Детали как выходное событие, которое достигает диаграммы Запрос Детали уже в качестве входного события и вы¬зывает переход из состояния Нет Запроса на Деталь в состояние Поступил Запрос на Деталь.
На диаграмме кооперации для абстрактного прецедента Принять Деталь (рис. 17) Контроллер Приемной Рабочей Станции отправляет деталь перво¬му Контроллеру Линейной Рабочей Станции.

Рис. 17. Диаграмма кооперации для прецедента Принять Деталь
Описание последовательности сообщений:
А1: Начальник производства инициирует обработку наряда-заказа, что запус¬кает процесс изготовления всех указанных в нем деталей.
А2: Интерфейс Начальника Производства посылает сообщение Начать Изготовление Детали объекту Контроллер Приемной Рабочей Станции, в котором указаны тип детали и количество необходимых деталей.
A3: Контроллер Приемной Рабочей Станции командует Подъемно-Транс¬портному Роботу положить на конвейер сырье для изготовления детали.
А4: Подъемно-Транспортный Робот помещает сырье на конвейер и изве¬щает об этом Контроллер Приемной Рабочей Станции.
А5 = В3: Контроллер Приемной Рабочей Станции посылает Контроллеру Линейной Рабочей Станции сообщение Деталь Идет. Это сообщение явля¬ется последним в прецеденте контроллера приемной рабочей станции и сле¬дующим в очередности событий прецедента контроллера линейной рабочей станции.
На диаграмме кооперации для абстрактного прецедента Обработать Деталь на Рабочей Станции (рис. 18) Контроллер Линейной Рабочей Станции-Предшественника отправляет деталь Контроллеру Линейной Рабочей Стан¬ции. Данная последовательность событий изображена как на диаграмме коопера¬ции, так и на диаграмме состояний Контроллера Линейной Рабочей Станции:

Рис. 18. Диаграмма кооперации для прецедента
Обработка Детали на рабочей станции
В3: Получив от предшественника сообщение Деталь Идет, Контроллер Линейной Рабочей Станции переходит в состояние Деталь на Подходе (рис. 15).
В4: С переходом в это состояние ассоциировано действие, которое посылает Запрос Следующей Операции объекту Сервер Технологических Карт, где указаны тип детали и номер текущего шага (первоначально 1).
В5: Сервер Технологических Карт увеличивает на единицу номер текущего шага, определяет идентификатор операции для нового шага и посылает запрос Серверу Операций с просьбой сообщить сведения о следующей операции.
В6: Сервер Операций возвращает запрошенную информацию.
В7: Сервер Технологических Карт отправляет данные об операции Контроллеру Линейной Рабочей Станции.
В8: Датчик Подъемно-Транспортного Робота обнаруживает прибытие детали и посылает Контроллеру Линейной Рабочей Станции сообщение Деталь Пришла. Это вызывает переход контроллера в состояние Робот Поднимает.
В9: При переходе состояний Контроллер Линейной Рабочей Станции направляет Подъемно-Транспортному Роботу команду снять деталь с конвейера.
В10: Подъемно-Транспортный Робот снимает деталь и переносит ее на рабочую станцию. О завершении операции робот уведомляет контроллер, после чего тот переходит в состояние Обработка Детали.
В11: Контроллер Линейной Рабочей Станции передает Сборочному роботу команду Начать Сборку.
В12: По завершении сборки Сборочный Робот посылает сообщение Конец Операции. Если на деталь уже поступил запрос (С2), то Контроллер Линейной Рабочей Станции переходит в состояние Робот Возвращает, в противном случае – в состояние Ожидание Запроса Детали от Преемника.
В13: В момент перехода Контроллер Линейной Рабочей Станции командует Подъемно-Транспортному Роботу вернуть деталь на конвейер.
В14: Положив деталь, Подъемно-Транспортный Робот посылает сообщение контроллеру Деталь Положена. Контроллер переходит в состояние Ожидание Детали от Предшественника. В момент перехода выполняются два параллельных действия: В15 и В15а.
В15 = С3: Контроллер Линейной Рабочей Станции посылает преемнику со¬общение Деталь Идет. Это сообщение показано на диаграмме Обработка Де¬тали как выходное событие, которое достигает диаграммы Запрос Детали уже в качестве входного события и вызывает переход из состояния Нет Запроса на Деталь в состояние Поступил Запрос на Деталь.
В15а (параллельная последовательность): Контроллер Линейной Рабочей Станции отправляет сообщение Запрос Детали своему предшественнику.

Рис. 19. Диаграмма кооперации для прецедента Отгрузить Деталь
Диаграмма кооперации для абстрактного прецедента Отгрузить Деталь (рис.19), когда последний Контроллер Линейной Рабочей Станции отправляет деталь Контроллеру Отгрузочной Рабочей Станции, состоит из такой последовательности событий:
С4: Расположенный на отгрузочной станции датчик обнаруживает прибытие детали, и Подъемно-Транспортный Робот посылает сообщение Деталь Пришла.
С5, С6: Подъемно-Транспортный Робот снимает деталь с конвейера и извещает об этом Контроллер Отгрузочной Рабочей Станции.
С7: Контроллер Отгрузочной Рабочей Станции помещает деталь на склад готовых деталей и отправляет сообщение Деталь Обработана объекту Интерфейс Начальника Производства.
С8: Интерфейс Начальника Производства выводит сообщение о заверше¬нии обработки детали.
Разбиение на подсистемы
Поскольку система автоматизации производства довольно велика, не имеет смысла разрабатывать для нее одну консолидированную диаграмму кооперации. Удобнее разбить ее на подсистемы, а затем построить диаграмму кооперации подсистем.
Некоторые подсистемы легко выделить по признакам территориальной распределенности или ответственности сервера. Одна из самых распространенных форм территориальной распределенности – наличие клиентов и серверов, которые всегда относятся к различным подсистемам.
Для выявления других подсистем полезно рассмотреть основанные на прецеден¬тах диаграммы кооперации, из которых видно, какие объекты взаимодействуют друг с другом чаще всего. Это достаточно разумный подход: если объекты постоянно взаимодействуют друг с другом, лучше поместить их в одну подсистему при усло¬вии, конечно, что они не являются территориально разнесенными.
Мы будем различать агрегированные и составные подсистемы. Составная под¬система структурируется с помощью критериев разбиения на подсистемы и в слу¬чае распределенного приложения всегда следует принципу территориальной раз¬несенности. Следовательно, объекты, находящиеся в географически удаленных точках, никогда не попадают в одну и ту же составную подсистему. Каждая со¬ставная подсистема представляет собой распределенный компонент, который допустимо развернуть в отдельном узле. Агрегированная подсистема образуется по признаку функционального сходства, то есть включаемые в нее объекты (воз¬можно, составные) обладают похожей функциональностью или взаимодействуют друг с другом в одних и тех же кооперациях.
На диаграмме кооперации подсистем (рис. 20) показаны все подсистемы в системе автоматизации производства и интерфейсы между ними.
На рис. 21 и 22 приведены диаграммы кооперации для подсистем Составление Техно¬логической Карты и Управление Производством. Детальная диаграмма ко¬операции для подсистемы Обработка Детали изображена на рис. 23.
Рассмотрим принципы и решения, которые были приняты при разбиении на подсистемы.
Сначала рассмотрим кооперации типа клиент-сервер. Из диаграммы коопера¬ции Следить за Сигналами Тревоги следует, что Сервер Сигналов Тревоги представляет собой серверную подсистему, а клиентский объект Интерфейс Опе¬ратора – это на самом деле составной объект, который лежит в основе одноимен¬ной подсистемы интерфейса пользователя (рис. 20).

Рис. 20. Диаграмма кооперации подсистем для системы автоматизации производства
Существует только один экземпляр Сервера Сигналов Тревоги, но много экземпляров подсисте¬мы Интерфейс Оператора – по одному для каждого оператора. Аналогично из прецедента Следить за Состоянием Рабочей Станции видно, что Сер¬вер Состояний Рабочей Станции – тоже серверная подсистема, и для каждой такой станции существует отдельный ее экземпляр.
Проанализируем диаграммы кооперации для процедуры составления технологических карт (Создать/Изменить Операцию и Создать/Изменить Технологическую Карту). Поскольку объекты Сервер Техноло¬гических Карт и Сервер Операций используются совместно, они объединяют¬ся в составную серверную подсистему Сервер Технологического Планирова¬ния. Агрегированная подсистема Технологическое Планирование включает две составные подсистемы: Сервер Технологического Планирования и Ин¬терфейс Инженера-Технолога (рис. 21).

Рис. 21. Подсистема технологического планирования
Встречающиеся в прецеденте Создать/Изменить Наряд-Заказ объект интер¬фейса пользователя Интерфейс Начальника Производства и объек¬ты Сервер Деталей и Сервер Нарядов-Заказов помещаются в агрегированную подсистему Управление Производством. Как и раньше, объект Интерфейс На¬чальника Производства образует основу составной подсистемы интерфейса пользователя. Поскольку объекты Сервер Деталей и Сервер Нарядов-Заказов используются совместно, они объединяются в составную подсистему Сервер Управления Производством (рис. 22).

Рис. 22. Подсистема управления производством
Объект Сервер Технологических Карт, который также принимает участие в прецеденте Управление Нарядами-Заказами, не является частью подсистемы Управление Производством: он уже отнесен к Подсистеме Технологического Планирования.
Объекты, участвующие в прецеденте Изготовить Деталь, образуют три управ¬ляющие подсистемы: Контроллер Линейной Рабочей Станции (несколько экзем¬пляров), Контроллер Приемной Рабочей Станции (один экземпляр) и Контрол¬лер Отгрузочной Рабочей Станции (также один экземпляр). Агрегированная подсистема Обработка Детали включает четыре составные подсистемы: три управ-ляющие и одну серверную – Сервер Состояний Рабочих Станций (рис. 23).
Объекты, участвующие в прецедентах подписки на извещения, уже распреде¬лены по разным подсистемам.

Рис. 23. Диаграмма кооперации для подсистемы обработки детали
Статическая модель всех составных классов в системе автоматизации произ¬водства показана на рис. 24.

Рис. 24. Статическая модель составных классов
Каждый составной класс – это компонент, кото¬рый можно развернуть в отдельном узле на этапе конфигурирования системы. На рис. 24 изображены также ассоциации между классами. Предложенная статичес¬кая модель построена на основе диаграммы кооперации подсистем. Ассоциации соответствуют связям между компонентами на диаграммах кооперации. Направ¬ление навигации определяется направлением передачи сообщений от компонента-отправителя к компоненту-получателю, например от клиента к серверу.
Архитектура распределенной программы
При отображении аналитической модели на архитектуру распределенной про¬граммы необходимо убедиться, что распределенные подсистемы можно сконфи¬гурировать. Проверить, все ли подсистемы спроектированы как компоненты, способные эффективно функционировать в распределенной среде, можно при помощи критериев конфигурируемости. В распределенной системе каждый компонент потенциально способен исполняться в отдельном узле, а все коммуникации меж¬ду компонентами имеют вид обмена сообщениями.
Применение критериев конфигурируемости компонентов
На рис. 23 показано по одному экземпляру подсистем Контроллер При¬емной Рабочей Станции и Контроллер Отгрузочной Рабочей Станции и не¬сколько экземпляров подсистемы Контроллер Линейной Рабочей Станции. Каждая из данных подсистем – автономный компонент, выполняющий одну сер¬висную функцию. Любой компонент способен функционировать независимо на протяжении длительного периода: он сохраняет работоспособность в условиях временного отказа остальных компонентов. Поскольку это управляющие компо¬ненты, то размещение их в отдельных узлах позволяет добиться предсказуемой производительности. Кроме того, с контроллером рабочей станции часто ассоци¬ируется специализированная аппаратура, в частности датчики и приводы.
Имеется несколько серверных подсистем, каждая из которых является ком¬понентом, способным работать в отдельном узле. Есть по одному экземпляру Сервера Технологического Планирования, Сервера Управления Произ¬водством и Сервера Сигналов Тревоги. Наивысшая производительность, ско¬рее всего, будет достигнута, если каждому серверному компоненту назначить от¬дельный узел, чтобы он мог быстро отвечать на запросы клиентов.
Что касается подсистемы Сервер Состояний Рабочих Станций, удобно иметь один его экземпляр для всей системы. Другой – децентрализованный – ва¬риант заключается в том, чтобы предоставить каждой рабочей станции по одному экземпляру этого компонента; в описываемом случае его допустимо разместить в том же узле, что и соответствующий Контроллер Линейной Рабочей Стан¬ции. Для такого решения есть две причины: сравнительно высокая интенсивность потока сообщений между Контроллером Линейной Рабочей Станции и Серве¬ром Состояний Рабочих Станций и большая вероятность того, что пропускной способности узла рабочей станции хватит для поддержки обоих компонентов.
Наконец, существует несколько подсистем интерфейса пользователя, каждая из которых является клиентом, потенциально размещаемым в отдельном узле:
Интерфейс Начальника Производства (один экземпляр), Интерфейс Инже¬нера-Технолога (по одному экземпляру для каждого инженера) и Интерфейс Оператора (по одному экземпляру для каждого оператора). Данные клиентские компоненты будут взаимодействовать с одним или несколькими серверами.