Получается у каждого лифта по одному блоку вызова на этаже? (с кнопками - вверх, вниз.)
 
А в чём разница между двумя системами с отдельными лифтами и одной системой с двумя лифтами?

Всё равно же в реализации мы создадим два экземпляра класса "лифт", и у каждого будут свои состояния, и эти экземпляры будут обмениваться сообщениями о своих состояниях.


Получается добавится только количество событий, а состояний будет два (пока остановился на двух, а дальше посмотрим) : остановка, движение.

Или вы хотите сказать 2 состояния непременно приведут к 4: два основных и два подсостояния для "движения": вверх - вниз? и состояния вверх -остановка -вниз являются минимизированными максимально?

Ну почему два блока управления.
Может быть и один на два лифта.
Такое реально встречается.

Хотя действительно две панели вызова нужны только в случае когда, на этаже слишком много людей для одного лифта, которые хотят вниз. Но они просто могут отправить дополнительный сигнал вниз когда сядет первая партия. Тем самым подтвердить свои намерения.

Что скажет заказчик?

Или нужен конечный автомат без памяти?

Немного отошел от задачи, считаю, что надежней сделать работу лифтов максимально независимыми, без выделенного управленца.

Принцип функционирования лифта заключается в выполнении поставленных задач которые можно задавать как из кабинки, так и с этажа. На этаже можно нажать кнопку ВВЕРХ, кнопку ВНИЗ. Лифт едет и собирает по-пути пассажиров: если лифт едет вверх и на этаже нажата кнопка ВВЕРХ останавливается, ежели лифт едет вверх, а на этаже нажата кнопка ВНИЗ едет дальше, а остановится на обратном пути. Это реализуется двумя списками задач, для одного направления и для обратного, когда задачи из одного направления заканчиваются лифт переходит к выполнению задач обратного направления и т.д.

Работа двух лифтов аналогична, НО у лифта есть список индивидуальных задач (те которые были заданы из лифта), и общих задач (которые были заданы с этажа). Задачи выполняются последовательно от этажа к этажу, тот лифт который быстрей выполнит общую задачу  исключает ее из списка задач обоих лифтов, таким образом Лифты работают асинхронно и у каждого свой алгоритм управления.
Примечание: чтоб лифты не стартовали к одному этажу (не приступали к выполнению одной задачи), кто первый приступает к  выполнению задачи ставит метку «выполняемая», после обслуживания удаляет из списка задач. Если лифт сделавший пометку  «выполняемая» ломается он снимает метку.

Момент старта (когда лифты никого не обслуживают) решается вопрос кому первому обслуживать задачу (кто ближе к этажу назначению, если равноудалёно то в случайном порядке).

Тут малость помоделировал в свободное от основной работы время.

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

У вас на диаграмме не ясен контекст системы.

У вас на диаграмме не ясен контекст системы.

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

например учитывать автоматизированную систему безопасности как контр меры аварийных ситуаций таких как пожар или отключение энергии или разрыв троса... могут повлиять на диаграмму состояний
а мне кажется что безопасность имеет первостепенную роль даже если в шахте каких то 5 этажей)))
не учитывать ее в построении диаграмм активности или состояний работы данного механизма мне кажется еще более неверным чем неумение "рисовать" эти самые диаграммы...

на этой диаграмме попытался описать контекст системы управления механизмом
ps если есть желание и возможности - ругайте пожалуйста сильнее. а то вторая в жизни Д на uml..

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

Я имел в виду контекст на диаграмме. Или границы системы, она же boundary. Что это? Лифт, Система управления лифтом. Отсюда будет более ясно, кто и зачем взаимодействует с системой.

При этом Система безопасности может быть частью Системы управления лифтом (тами), а может быть чем-то независимым.

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

пока мы рассуждали о модели использования

на этой диаграмме попытался описать контекст системы управления механизмом
ps если есть желание и возможности - ругайте пожалуйста сильнее. а то вторая в жизни Д на uml..

1. зачем выделяется такая сущность как Пассажир и описываются его операции? Разве вы сможете им управлять?
2. не понял семантику реализации интерфейсов КНОПОК зданием и лифтом.

Я имел в виду контекст на диаграмме. Или границы системы, она же boundary. Что это? Лифт, Система управления лифтом. Отсюда будет более ясно, кто и зачем взаимодействует с системой.

границу системы я видел ограничивающую акторами... не встречал в сети диаграмм где за границей boundary могут быть другие преценденты...
так надеюсь правильнее?..

При этом Система безопасности может быть частью Системы управления лифтом (тами), а может быть чем-то независимым.

естественно. именно поэтому я ее обозначил как актор, то есть как внешнее к системе отношение...
то есть актор тоже может быть внутри системы?..

пока мы рассуждали о модели использования
1. зачем выделяется такая сущность как Пассажир и описываются его операции? Разве вы сможете им управлять?
2. не понял семантику реализации интерфейсов КНОПОК зданием и лифтом.

1.непосредственно пассажиром нет... я хотел показать чем может управлять пассажир и какие у него возможности взаимодействия. то есть этот класс совсем не нужен?..
2.    а)эм... в каждом лифте есть блок управления (эти самые кнопки с 1го по 5й этажи, например)
       б)в здании на каждом этаже есть кнопки вызова "вниз" и "вверх"
    я именно это хотел показать на диаграмме интерфейсами...

границу системы я видел ограничивающую акторами... не встречал в сети диаграмм где за границей boundary могут быть другие преценденты...
так надеюсь правильнее?..

и правильно не встречали, так как что же это за вариант использования, если его некуда приложить? Вот и ваша диаграмма стала сразу малопонятной. Вот выделили вы boundary и назвали его System, понятней не стало, что за System?

естественно. именно поэтому я ее обозначил как актор, то есть как внешнее к системе отношение...

Актор - нечто внешнее по отношении к системе, обладающее поведением. Да в вашем случае система безопасности может быть внешней по отношении к рассматриваемой системе. Это вы показали и сейчас это стало ясно, но все равно не до конца.

то есть актор тоже может быть внутри системы?

с точки зрения синтаксиса и семантики нет, актор внутри системы быть не может.

..1.непосредственно пассажиром нет... я хотел показать чем может управлять пассажир и какие у него возможности взаимодействия. то есть этот класс совсем не нужен?..

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

2.    а)эм... в каждом лифте есть блок управления (эти самые кнопки с 1го по 5й этажи, например)

есть

       б)в здании на каждом этаже есть кнопки вызова "вниз" и "вверх"

встречаются, но не всегда

    я именно это хотел показать на диаграмме интерфейсами...

На мой взгляд сомнительно.
Скажите, на кого рассчитана эта модель? На какие вопросы она должна ответить? И какой ответ и кто получит, увидев кружочек с надписью "кнопки"?

и правильно не встречали, так как что же это за вариант использования, если его некуда приложить? Вот и ваша диаграмма стала сразу малопонятной. Вот выделили вы boundary и назвали его System, понятней не стало, что за System?

я его не называл систем оно само))) а поменять не нашел где...
про границы не понял... какой смысл от квадратика который ограничивает все прецеденты на диаграмме если и так понятно что акторы - внешние объекты системы?..

Скажите, на кого рассчитана эта модель? На какие вопросы она должна ответить? И какой ответ и кто получит, увидев кружочек с надписью "кнопки"?

1 на человека имеющего опыт построения uml диаграмм классов, который ее увидит на этом форуме
2   а)что в диаграмме не правильно?
     б) на что можно указать автору диаграммы что бы он понял свои ошибки в построении?
     в)как можно ее исправить что бы она приняла адекватный вид и смогла помочь в построении диаграмм активности
        механизма управления двумя кабинами лифтов?
3 не знаю я пытался отобразить как раз взаимодействие

зы. спасибо за содержательное обсуждение

про границы не понял... какой смысл от квадратика который ограничивает все прецеденты на диаграмме если и так понятно что акторы - внешние объекты системы?

просто boundary может быть несколько раз, во вторых именованная boundary сразу создает контекст обсуждения. Вот в первом вашем случае было не понятно к чему вы применяете свои ВИ, к какой системе? Каждый может интерпретировать сам. Например я отношу к лифту, другой к системе управления, для которой лифт реально - просто набор датчиков и т.п. Важна точность и однозначность.

2   а)что в диаграмме не правильно?
     б) на что можно указать автору диаграммы что бы он понял свои ошибки в построении?
     в)как можно ее исправить что бы она приняла адекватный вид и смогла помочь в построении диаграмм активности
        механизма управления двумя кабинами лифтов?

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

3 не знаю я пытался отобразить как раз взаимодействие

ДК не предназначена для отражения взаимодействия. поведение изображается на диаграмма состояний, деятельности и взаимодействия(последовательности и коммуникации).

спасибо ошибку понял, не учел кол-во сторон интерпретации.
по второй диаграмме я понимаю что это явно не ДК я пытался описать эту Д как  Д простой кооперации.
поэтому посчитал что позволительно было наградить Д так же и интерфейсами. но тут я понимаю что все не правильно и как правильно мне еще не дано знать...
("system" так и не нашел как изменить)

упростил систему, акцентировав внимание на самом механизме.
ПО которое управляет передвижением кабины лифта зависит от взаимодействия с этим лифтом внешних ЗЛ(небольшое число)которых я постарался обозначить посредством ДВИ приложенной к этому посту.

постараюсь выявить классы ПО которое необходимо смоделировать.
1.для перемещения кабины необходимо 2 мотора(основной и мотор открытия дверей)
которые были выделены в один суперКласс "привод"- имеющий операции "посадка" и "движение на n этаж"
2.этаж-имеющее такие параметры как "номер этажа"
3.лифт-имеющий идентификатор и состояния...
4.так же думаю необходимо добавить класс "траектория движения"...

в общем с классами и ДК- в частности - беда. изучаю...
большое спасибо за ответ.

Я думаю, вам тут нужно определиться.

1. Описываете ли вы просто систему управления лифтами.
2. Или вы пытаетесь построить симулятор лифтовой системы.

Результат может быть различный, когда вы перейдете к выявлению классов ПО.
Но что вы теряете, делайте свои варианты и не волнуйтесь слишком:)