Форум Сообщества Аналитиков

Общий раздел => Примеры => Тема начата: avtomaatik от 14 Апреля 2009, 14:44:44

Название: Система управления откачиванием шахтной воды
Отправлено: avtomaatik от 14 Апреля 2009, 14:44:44
Смысл заключается в том, что насос не должен работать, если сработал хотя бы один из трех датчиков (Methane, Airflow, Carbon monoxide), в нормальном режиме насос работает по сигналам уровнемеров. Картинка процесса представлена ниже.
(http://s45.radikal.ru/i108/0904/e0/ed4241be5916.jpg)

Начинаю изучать UML с нуля. Строю диаграмму прецедентов (Use Case Diagram). Вопрос такой, может ли в качестве актеров выступать неодушевленный предмет? Пока выбрал три актера: Operator (получает сигнал тревоги), Environment Controller (следит за уровнем газа в окружающей среде) и Pump Controller (который управляет насосом и получает информацию от датчиков уровня). Должны ли датчики выступать в роли актеров?
Название: Re: Система управления откачиванием шахтной воды
Отправлено: bas от 14 Апреля 2009, 15:00:50
А что Вы хотите показать на ДВИ (Use Case Diagram)? Здесь ДВИ Вам не поможет. Нарисуйте обычную Д Состояний.
Название: Re: Система управления откачиванием шахтной воды
Отправлено: Виталий Григораш от 14 Апреля 2009, 15:10:57
Датчики могут выступать в качестве актеров. Но они будут лишь инициировать ВИ, подавая сигнал. Взаимодействия не будет
Название: Re: Система управления откачиванием шахтной воды
Отправлено: avtomaatik от 14 Апреля 2009, 15:19:20
Я предполагаю показать взаимодействие 3х подсистем.
А какие диаграммы подходят для описания данной системы, помимо д. состояний?
Название: Re: Система управления откачиванием шахтной воды
Отправлено: Виталий Григораш от 14 Апреля 2009, 15:58:42
Диаграмма взаимодействия
Название: Re: Система управления откачиванием шахтной воды
Отправлено: Денис Иванов от 14 Апреля 2009, 17:44:38
Диаграмма взаимодействия
нет такой диаграммы (в UML по крайне мере).

Диаграмма последовательности имелась в виду?
Название: Re: Система управления откачиванием шахтной воды
Отправлено: Григорий Печенкин от 14 Апреля 2009, 18:08:30
нет такой диаграммы (в UML по крайне мере).

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

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

Пора начинать холивар? :)
Название: Re: Система управления откачиванием шахтной воды
Отправлено: Денис Иванов от 14 Апреля 2009, 18:10:57
А вот у меня на столе лежит книга какого-то Шмуллера, который клевещет:

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

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

Зачем? Диаграммы взаимодействия = диаграмма последовательности + диаграмма коммуникации.
Но диаграммы взаимодействия (ед. число) нет :)
Название: Re: Система управления откачиванием шахтной воды
Отправлено: Galogen от 14 Апреля 2009, 20:17:20
Диаграмма взаимодействия суть абстрактная диаграмма, не имеющая экземпляров
Название: Re: Система управления откачиванием шахтной воды
Отправлено: avtomaatik от 14 Апреля 2009, 23:58:56
Ну вы и развели проблему!) Я уже и не знаю к чему притронуться!
Название: Re: Система управления откачиванием шахтной воды
Отправлено: Galogen от 15 Апреля 2009, 07:53:07
Ну вы и развели проблему!) Я уже и не знаю к чему притронуться!
Товарищ. Во всем нужна целесообразность. Вам нужно разработать систему управления. Что понимать под оной?
Программно-аппаратный комплекс, наверное, назначение которого состоит в том, чтобы управлять работой насоса.
При этом вполне возможно обойтись и чисто аппаратной частью, а программу управления реализовать на физическом уровне путем создания схем управления.
Если же решено сделать упор на программу, которая:
а/ собирает информацию о состоянии объекта управления
б/ управляет объектом управления
то соответственно и надо разрабатывать
модель сбора и возможно хранения информации о состоянии объекта
модель управления объектом

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

Далее нужно подуать о программе в которой будет некий класс Насос, который и будет представлять реальный насосо. Класс Насос будет отражать текущие характеристики реального насоса. Программа будет воздействовать на ваш класс Насос, который уже в свою очередь будет воздействовать на реальный
Название: Re: Система управления откачиванием шахтной воды
Отправлено: Виталий Григораш от 15 Апреля 2009, 10:10:56
Autimaatik, почитайте здесь (http://www.math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html)


Название: Re: Система управления откачиванием шахтной воды
Отправлено: avtomaatik от 22 Апреля 2009, 20:46:43
Накопилось несколько вопросов:

(http://i045.radikal.ru/0904/52/32a066fa71f2.jpg)

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

Моя черновая диаграмма классов.
http://s42.radikal.ru/i095/0904/86/8f60b4fa2032.jpg (http://s42.radikal.ru/i095/0904/86/8f60b4fa2032.jpg)
Название: Re: Система управления откачиванием шахтной воды
Отправлено: Денис Иванов от 22 Апреля 2009, 20:56:32
1) Это должны быть ЭКЗЕМПЛЯРЫ классификаторов (классов, ДЛ, компонентов)
2) Если сообщение передаются экземпляру класса, то должны
Название: Re: Система управления откачиванием шахтной воды
Отправлено: Виктор Малышко от 28 Апреля 2009, 18:38:31
В диаграмме последовательности неясно, почему, получив первый раз сигнал от датчика, Environment Controller не послал SwitchOff, а во второй раз -- послал (предпоследнее сообщение).
2. Должны ли описания, помеченные на рисунке цифрой 2, являться операциями классов? У меня названия отличаются на двух диаграммах.
Необязательно. В начале, при анализе они являются, так называемыми, "операциями анализа" -- т. е. заготовками будущих операций, подлежащими уточнению при проектировании.

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

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

Цитировать
Моя черновая диаграмма классов.
http://s42.radikal.ru/i095/0904/86/8f60b4fa2032.jpg (http://s42.radikal.ru/i095/0904/86/8f60b4fa2032.jpg)
По диаграмме классов хочу заметить, что Вы дублируете одни и те же атрибуты в нескольких классах. Недостаток такого решения в том, что нужно следить, чтобы их значения менялись согласовано. Для PumpStatus'а это будет непросто.