Смысл заключается в том, что насос не должен работать, если сработал хотя бы один из трех датчиков (Methane, Airflow, Carbon monoxide), в нормальном режиме насос работает по сигналам уровнемеров. Картинка процесса представлена ниже.


Начинаю изучать UML с нуля. Строю диаграмму прецедентов (Use Case Diagram). Вопрос такой, может ли в качестве актеров выступать неодушевленный предмет? Пока выбрал три актера: Operator (получает сигнал тревоги), Environment Controller (следит за уровнем газа в окружающей среде) и Pump Controller (который управляет насосом и получает информацию от датчиков уровня). Должны ли датчики выступать в роли актеров?

А что Вы хотите показать на ДВИ (Use Case Diagram)? Здесь ДВИ Вам не поможет. Нарисуйте обычную Д Состояний.

Датчики могут выступать в качестве актеров. Но они будут лишь инициировать ВИ, подавая сигнал. Взаимодействия не будет

Я предполагаю показать взаимодействие 3х подсистем.
А какие диаграммы подходят для описания данной системы, помимо д. состояний?

Диаграмма взаимодействия

Диаграмма взаимодействия

нет такой диаграммы (в UML по крайне мере).

Диаграмма последовательности имелась в виду?

нет такой диаграммы (в UML по крайне мере).

А вот у меня на столе лежит книга какого-то Шмуллера, который клевещет:

"Как диаграммы последовательностей, так и диаграммы коммуникации отражают взаимодействие объектов. По этой причине эти два вида диаграмм в UML называют диаграммами взаимодействия (interaction diagram)."

Пора начинать холивар?

А вот у меня на столе лежит книга какого-то Шмуллера, который клевещет:

"Как диаграммы последовательностей, так и диаграммы коммуникации отражают взаимодействие объектов. По этой причине эти два вида диаграмм в UML называют диаграммами взаимодействия (interaction diagram)."

Пора начинать холивар?

Зачем? Диаграммы взаимодействия = диаграмма последовательности + диаграмма коммуникации.
Но диаграммы взаимодействия (ед. число) нет

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

Ну вы и развели проблему!) Я уже и не знаю к чему притронуться!

Ну вы и развели проблему!) Я уже и не знаю к чему притронуться!

Товарищ. Во всем нужна целесообразность. Вам нужно разработать систему управления. Что понимать под оной?
Программно-аппаратный комплекс, наверное, назначение которого состоит в том, чтобы управлять работой насоса.
При этом вполне возможно обойтись и чисто аппаратной частью, а программу управления реализовать на физическом уровне путем создания схем управления.
Если же решено сделать упор на программу, которая:
а/ собирает информацию о состоянии объекта управления
б/ управляет объектом управления
то соответственно и надо разрабатывать
модель сбора и возможно хранения информации о состоянии объекта
модель управления объектом

Поскольку Ваш объект есть суть конечный автомат, то очевидно, что можно сначала построить модель работы как модель конечного автомата сиречь диаграмма состояний.

Далее нужно подуать о программе в которой будет некий класс Насос, который и будет представлять реальный насосо. Класс Насос будет отражать текущие характеристики реального насоса. Программа будет воздействовать на ваш класс Насос, который уже в свою очередь будет воздействовать на реальный

Autimaatik, почитайте здесь

Накопилось несколько вопросов:



1. Должны ли объекты, помеченные на рисунке цифрой 1, на диаграмме последовательности действий (Sequence diagram) являться классами, т.е. просто переносишь классы на диаграмму и показываешь последовательность?
2. Должны ли описания, помеченные на рисунке цифрой 2, являться операциями классов? У меня названия отличаются на двух диаграммах.
3. Как выбирается количество классов и их названия при составлении диаграммы классов? Должны ли датчики являться классами?
4. Как выбираются атрибуты и операции классов?

Моя черновая диаграмма классов.
http://s42.radikal.ru/i095/0904/86/8f60b4fa2032.jpg

1) Это должны быть ЭКЗЕМПЛЯРЫ классификаторов (классов, ДЛ, компонентов)
2) Если сообщение передаются экземпляру класса, то должны

В диаграмме последовательности неясно, почему, получив первый раз сигнал от датчика, Environment Controller не послал SwitchOff, а во второй раз -- послал (предпоследнее сообщение).

2. Должны ли описания, помеченные на рисунке цифрой 2, являться операциями классов? У меня названия отличаются на двух диаграммах.

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

3. Как выбирается количество классов и их названия при составлении диаграммы классов? Должны ли датчики являться классами?

Датчики будут экземплярами классов, если их взаимодействие с Environment Controller программное, а не hardwar'ное.

4. Как выбираются атрибуты и операции классов?

Операции классов получаются -- из "операций анализа" с диаграмм взаимодействия и из соображений реализации методов (во втором случае возникают закрытые операции). Также необходимость в добавлении операций может возникнуть при моделировании состояний системы. Рекомендую нарисовать диаграмму состояний для Pump Controller. Атрибуты классов обычно уточняются потом. Часть атрибутов выявляется из описаний предметной области. Другая часть -- из диаграмм состояний -- сочетания их значений определяют в каком состоянии находится объект.

Моя черновая диаграмма классов.
http://s42.radikal.ru/i095/0904/86/8f60b4fa2032.jpg

По диаграмме классов хочу заметить, что Вы дублируете одни и те же атрибуты в нескольких классах. Недостаток такого решения в том, что нужно следить, чтобы их значения менялись согласовано. Для PumpStatus'а это будет непросто.