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