Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Ну принципиально это возможно.Тогда добавление читательского номера в идентифицирующий набор не "лечит"!
Если в читальный зал, то не достаточно.Почему? Только потому, что выдача одного экземпляра может быть несколько раз в течении даты?
выдача идентифицируется инвентарным номером экземпляра, читательским номером и датой выдачиДостаточно инвентарного номера экземпляра и даты выдачи.
Я считаю главным недостатком дублирование "подавтомата" для ввода операнда. Представим, что надо добавить в калькулятор числа с плавающей точкой (в тексте автор путает[!!!] их с числами с фиксированной точкой). Апгрейдить придётся обе копии подавтомата. А зачем?
Например, мне кажется логичным negated прятать внутрь operand'ов. Ведь знак - это часть записи операнда.
Прети-принтинг) Может быть, так "красивше".)"Обложечная" нотация выглядит более строгой, значит для "красивше" в ней нет места.
В PSCC2 есть кусок кода [p.191] и пояснение к нему.Это пояснение:
Note that only the TRUE branch of the if contains the “return Q_TRAN()” statement,?
meaning that only the TRUE branch reports that the event has been handled. If the
TRUE branch is not taken, the break statement causes a jump to the final return that
informs the QEP that the event has not been handled. This is in compliance with the
UML semantics, which require treating an event as unhandled in case the guard
evaluates to FALSE. In that case, the event should be propagated up to the higher levels
of hierarchy (to the superstate).
Самек считает, что else ветка в его нотации означает, что событие не обрабатывается, а передаётся дальше обработчику суперсостояния.Может наоборот -
There is a difference between a choice pseudostate with an empty else segment and an otherwise identical choice pseudostate without the else segment. The explicit empty else will cause the event to be consumed (without doing anything), while the absence of the else segment will cause the event to propagate to the superstate(s).
На "обложке" дана диаграмма калькулятора в нотации Самека, к слову.На этой "обложечной" диаграмме свои вопросы:
P. S. Оценило, что калькулятор иллюстрирует стандартное правило выбора одного перехода из конфликтующих.Где? Когда из begin есть свой OPER, а из ready свой?
Некоторая трудность в том, что кроме модели другого описания (достаточно точного) поведения калькулятора нет (скачать прогу, которая якобы реализует, я не смогло). Поэтому логику приходится "считывать" из модели.Пока прога не изготовлена, модель - это единственное место, в котором может быть достаточно точное описание
Например, мне кажется логичным negated прятать внутрь operand'ов. Ведь знак - это часть записи операнда.Это если считать, что название состояния (в том числе и композитного) абсолютно точно передаёт его смысл. Чаще встречается ситуация, когда сначала выделяются безымянные состояния (в том числе и композитные), определяются их точные свойства, а наименование подбирается потом, исходя из соображений, что суть надо более-менее отразить, но наименование не должно быть длинным. Например operand1 более точно назвать "операнд 1 без знака", но это длинно.
Наличие отдельного от begin result'а (а вслед за ним и ready) выглядит ненужным усложнением.Для begin есть возможность задать знак (переход к negated1), а для result - нет, различия есть. Много общего, но есть различия - делай композит.
Я считаю главным недостатком дублирование "подавтомата" для ввода операнда. Представим, что надо добавить в калькулятор числа с плавающей точкой (в тексте автор путает[!!!] их с числами с фиксированной точкой). Апгрейдить придётся обе копии подавтомата. А зачем?Согласен, что и такой недостаток есть, обсуждать планировал позже (есть подозрение, что он лечится очень непросто).
+ Ready имеет смысл для логики работы калькулятора (в нём он готов к началу нового вычисления);композит ready и negated1 тоже имеет смысл для логики работы калькулятора - в нём он готов к вводу цифровой части числа-операнда
+ Ready немного упрощает диаграмму и позволяет нормально разместить её на странице;композит ready и negated1 объединит 3 исходящих перехода (ready объединяет 4). Кстати, отсутствие перехода по OPER от negated1 выглядит подозрительно.
Или не обеспечивает.)Не понял: если при уничтожении Здания уничтожаются и Этажи в его составе, то не может возникнуть ситуация, что Этаж есть, но он не связан ни с каким Зданием - структурное ограничение выполняется.
Или разыскать стандарт и прочесть."If a composite object is deleted, all of its part instances that are objects are deleted with it." (UML 2.5, 9.5.3., стр. 110)
Между "часть не может существовать без целого" и "при уничтожении целого уничтожаются также и части в его составе" есть некоторая разница."часть не может существовать без целого" - структурное ограничение, а "при уничтожении целого уничтожаются также и части в его составе" - одно (но не единственное!) из поведений, которое обеспечивает выполнение этого структурного ограничения.
Я пользуюсь в работе агрегацией без дополнительных отношений ассоциации. Отношения я прописываю на ассоциации между элементами модели.Как будут выглядеть такие ситуации (в них, как я понимаю, отношения прописаны прямо на композиции).
Здание◆-1---1..*-Этаж
Авто◆-0..1---3..8-Колесо
А зачем там отношения, используемые в ассоциациях?)))Композиция и агрегация являются ассоциациями с дополнительными ограничениями (транзитивное замыкание антирефлексивно - нельзя быть композитом/агрегатом самому себе ни непосредственно, ни опосредованно; композитов не может быть более одного; ...).
Композиция: Элемент-источник является частью и не может существовать без целевого элемента.А если при черном ромбе будет не 1..1, а 0..1?
Агрегация: Элемент-источник является частью и может существовать отдельно целевого элемента.А если при белом ромбе будет 1..1 или 1..*?
Семантика umlьная. Другой на моей планете нет, не завезли.
