Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Ограничения естьP. S. В метамодели UML ассоциация между классификатором и экземпляром ничем не ограничена. Вообще. Нет даже сакраментального "Cannot be expressed in OCL".
Берётся, но не достигает.Имелось в виду, что там не придаётся внимания тому, что за графом лежит ещё один слой "таблички", почти не отличимый в простых случаях, и требующий вывода в сложных. Наоборот применяется растушёвка: вершины стабильные и нестабильные; звенья/переходы/составные переходы.
Ограничения есть, конфигурация классов должна быть допустимой, но это на совести автора диаграммы объектов - как определять допустимые конфигурации по модели классов даже у Оливе нет.Эти ограничения настолько слабы (после overlapping'а по умолчанию), что их как бы и нет. Единственное, что явно сказано про недопустимые конфигурации в стандарте -- disjoint'ы. Нет их, нет и ограничений.
Путь с обязательным заведением класса-наследника неприемлем.Это путь от кода. Но ему есть хоть какое-то объяснение. Что например мешает двум никак не связанным классам расшарить экземпляр? По [молчащему на этот счёт] стандарту -- ничто. По этому пути -- хотите шарить -- заводите общий подкласс, т. е. сначала свяжите классы хотя бы опосредованно.
А куда и почему произойдет переход из State1 по событию b На диаграмме 3?Если трактовать переходное псевдосостояние, как спец. обозначение для более удобной записи переходов и сторожей, то для ответа на вопрос, нужно переписать диаграмму без спец. обозначения. Получаем:
В книге Рамбо и Блаха в 4.10. прямо сказано: "Производными могут быть классы, ассоциации и атрибуты" и пример есть (правда не очень хороший)Спасибо за ссылку на пример.
Если мы сделаем в третьем процессе цикл goto с join аналогичный первому, будет ли это означать, что индивидуальные токены заявок восстановлен из общей кучи, куда их сунули при перемещении?Это возможно, но при этом на поток данных из второго datastore надо вешать select, определяющий в каком порядке выбираются заявки из общей кучи. Вместо цикла можно было бы задействовать <<iterative>> expansion region, если бы я знал как набор токенов-заявок превратить в один токен-коллекцию-заявок.
Как реализуется цикличность обработки каждой заявки?Сначала скажу, что моя версия диаграммы лишь демонстрировала, как я представляю себе цикличность "процесса клиента". Она полна недостатков. Например, можно составить вариант с одним, а не двумя datastore. Есть и другие пробелы.
Без него не получится сделать цикл. Примерный вид диаграммы во вложении.Эх. Если нужен цикл, значит нужно придумывать, когда его начинать, а когда заканчивать."Accept-флажок" внутри деятельности может не иметь входящих потоков. Т. е. initial node для "процесса клиента" заводить не обязательно. Если нужно учитывать время приёма заявки, можно завести [decision node и] сторожевое условие.
С точки зрения стандарта UML 2.5, если каждый из 3 процессов стартует из своего начального узла (initial node), то в рамках моделируемой деятельности "процесс клиента", "процесс перемещения" и "процесс обработки" отработает по одному разу. Т. е., скорее всего, в "процессе клиента" должен быть цикл, иначе в течение выполнения всей большой деятельности клиент будет лишь один (не более одного) и datastore не понадобится для его единственной заявки.
... непонятно насколько корректна такая ДА
А правильные то примеры с двумя асинхронными процессами встречаются? С удовольствием бы глянул. А то я похоже выразительные возможности диаграммы активности недооценивалКонечно, проще искать ошибки, чем предложить что-то конструктивное. Если уточните, что нужно, попробую представить. В каком-то смысле, для асинхронных процессов достаточно диаграммы с форком.
