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

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - [прилетело НЛО и...]

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »
361
Модель как эскиз, модель как иллюстрация, модель как промежуточное звено в цепочке трансформаций моделей, модель как предшественница сгенерированного по ней кода, модель как результат обратной инженерии кода...

362
Мне нравится, как у Амблера написано про годные гибкие модели: http://agilemodeling.com/essays/whenIsAModelAgile.htm Что у модели есть цель и аудитория, что она достаточно подробна, достаточно точна  и достаточно непротиворечива. В этом смысле любую модель можно критиковать, определяя свою цель, свой уровень подробности, точности, непротиворечивости.
Пример, похожий на [1] даётся далее в главе 6

поэтому тут можно усмотреть чисто методические причины.
[2] Когда было проще с проходом в здания, такое практиковалось и, насколько мне известно, официально не запрещено.
[3] Может. У нас физику читали преподы с другого факультета (физфака). А наши преподы мучили студентов-геологов.
[4] Имеет смысл отделить описание курса от прочтения курса, если мы хотим идти дальше учебного эскиза. 

363
Если верить этому переводу...
Это перевод первой редакции книги (про "первый" UML). Вот мы и раскрыли тайны "кухни". При подготовке перевода второй редакции поленились снова перевести диаграмму, взяли готовую из предыдущего перевода, не обратив внимание на то, что у неё в разных редакциях разные версии.

364
По-моему, в руководстве по языку авторы приводят примеры для иллюстрирования конструкций языка. То есть, они не ставят перед собой задачу проанализировать ситуацию и построить адекватную модель. Вместо этого они описывают на языке некое положение вещей, считаемое заведомо ясным, и фокусируются на том, как работает язык.

365
Привет.
История такая. Картинку взяли из 1-го издания, где она имела номер 5-10 и в сопроводительном тексте ничего не было сказано о мощностях ассоциации Курс -- Факультет. Но текст взяли из второго издания, где картинка исправлена и выглядит так:

Итог. Ошибка у тех, кто готовил к изданию перевод на русский язык. 

366
Это диаграмма из RUP'а, т. е. учебный пример от Rational.

367
Я лишь пытаюсь уточнить свою мысль. Переходить от "ограничений на связанные с экземпляром классификаторы" на другие ограничения в мои планы пока не входит.
Ещё в стандарте есть параграф 9.9.9.6. Именно к нему относится сказанное мной об отсутствии ограничений в стандартной метамодели UML.
Подход "запишем через запятую и всё" не плох, что и говорить.) 

368
Ограничения есть
P. S. В метамодели UML ассоциация между классификатором и экземпляром ничем не ограничена. Вообще. Нет даже сакраментального "Cannot be expressed in OCL".

369
Берётся, но не достигает.
Имелось в виду, что там не придаётся внимания тому, что за графом лежит ещё один слой "таблички", почти не отличимый в простых случаях, и требующий вывода в сложных. Наоборот применяется растушёвка: вершины стабильные и нестабильные; звенья/переходы/составные переходы.

370
Ограничения есть, конфигурация классов должна быть допустимой, но это на совести автора диаграммы объектов - как определять допустимые конфигурации по модели классов даже у Оливе нет.
Эти ограничения настолько слабы (после overlapping'а по умолчанию), что их как бы и нет. Единственное, что явно сказано про недопустимые конфигурации в стандарте -- disjoint'ы. Нет их, нет и ограничений.
Путь с обязательным заведением класса-наследника неприемлем.
Это путь от кода. Но ему есть хоть какое-то объяснение. Что например мешает двум никак не связанным классам расшарить экземпляр? По [молчащему на этот счёт] стандарту -- ничто. По этому пути -- хотите шарить -- заводите общий подкласс, т. е. сначала свяжите классы хотя бы опосредованно.

371
Проблема стандарта в том, что эти вершины-псевдосостояния и звенья-псевдопереходы для авторов стандарта как бы заслонили тот факт, то [настоящая] диаграмма состояний описывает табличку [настоящих] переходов между [настоящими] состояниями.  В результате метамодель в части конечных автоматов описывает не автомат как таковой, а некий граф, из которого может быть выведен [настоящий] автомат в том случае, когда граф построен по правилам. Но описать правила построения графа и правила вывода из него автомата стандарт не берётся.

372
Перечёл у Рамбо обсуждение обобщений. Выглядит странно на фоне стандарта 2.5.  Стандарт говорит о том, что классификаторы могут расшаривать экземпляры при {overlapping}, но не уточняет, что для этого надо.   Ну, то есть, как на диаграмме объектов нарисовать этот самый расшаренный экземпляр? Стандартная метамодель UML разобраться нисколько не помогает. По ней -- связывай экземпляр с любыми классификаторами и всё. Никаких тебе ограничений.
По [моему пониманию] Рамбо ограничения {overlapping/disjoint} говорят о том, какие обобщения можно проводить между подклассами и их наследниками. Если мы хотим запретить "склеивать" ветки в поддереве наследования, то пишем {disjoint}, иначе ничего не пишем и получаем по умоланию {overlapping}. Разница между написанным в стандарте и этой трактовкой в том, что экземпляры не могут просто так шариться. Сначала придётся завести класс-наследник у двух подклассов, а затем только экземпляры этого класса (его наследников и других, таких же как он) могут быть расшарены. Пока такого класса нет, нет и реальной возможности использовать расшаренный экземпляр, а декларируемая стандартном возможность  остаётся только теоретической.
Неясно как в свете UML 2.5 выглядят примеры Рамбо в параграфе 4.6.3. Он словно ломится в открытую дверь усложняя модель.

373
А куда и почему произойдет переход из State1 по событию b На диаграмме 3?
Если трактовать переходное псевдосостояние, как спец. обозначение для более удобной записи переходов и сторожей, то для ответа на вопрос, нужно переписать диаграмму без спец. обозначения. Получаем:
<>--[a=1 and a=1]-->State2
и
<>--[a=1 and a!=1]-->State3
Ответ: State2.

374
В книге Рамбо и Блаха в 4.10. прямо сказано: "Производными могут быть классы, ассоциации и атрибуты" и пример есть (правда не очень хороший)
Спасибо за ссылку на пример.

375
Если мы сделаем в третьем процессе цикл goto с join аналогичный первому, будет ли это означать, что индивидуальные токены заявок восстановлен из общей кучи, куда их сунули при перемещении?
Это возможно, но при этом на поток данных из второго datastore надо вешать select, определяющий в каком порядке выбираются заявки из общей кучи. Вместо цикла можно было бы задействовать <<iterative>> expansion region, если бы я знал как набор токенов-заявок превратить в один токен-коллекцию-заявок.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »