Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Получается, что подобные тонкости лучше описывать на простом языке, без каких либо излишеств?"Это зависит..." (Капитан Очевидность)
Наверно, проще будет приложить макет.На картинке изображена такая фильтрация:
Получается, что пользователь, может добавить фильтр.имеется 5 фильтров и 2 блока?
Для этого фильтра указать:
- поле обьекта
- условие(<,>,= и т.д)
- значение по умолчанию (не обязательно)
значение по умолчанию (не обязательно)А почему необязательно, ведь мы должны сравнивать значение поля, для чего надо знать с чем сравнивать? (разве что для логического типа данных может быть попроще)
При этом при добавлении второго и последующих фильтров появляется возможность указать между ними условные операции.Скорее не "возможность", а "необходимость".
И вот я не понимаю, как это можно описать в сценариях да и стоит ли?Если кратко:
Если фильтров больше 1, между ними необходимо указывать логические операции (and, or, not).
Должна быть возможность объединять фильтры в блоки и указывать между блоками логические операции (and, or, not).
любой объект может изменить свой подкласс, например суперкласс - Человек, подклассы - Одинок, В браке, Разведен, Вдов
Есть такой диалект - ontoUML. Там стереотип <<Phase>> означает, что подкласс может меняться.По ссылке пример прямо в тему:
На "нормальной" старшинство по отношению к "хвосту" было бы размечено композицией / агрегацией.Согласен с необходимостью внести на диаграмму (в модель) для ассоциации между Student и Classification какой-то "несимметричности".
Смена типа студента состоит в том, что один "хвост" ему отрезают, а другой -- пришивают.- студент может сменить "хвост", а "хвост" не может сменить студента - только "умереть", освободив место для свежерождённого "хвоста". И maxCourceLoad можно переместить в Student, чтобы не передавать его значение из старого "хвоста" в новый.
Многие UML-модели делаются так, как-будто типы экземпляров статичны (с единственной поблажной имени Барбары Лисковы). Например, в классическом RUP-овом примере от Rational используется делегирование, чтобы показать, что студенты бывают разных типов и могут менять свой тип:Это тоже вариант. У него свои недостатки:
Смена типа студента состоит в том, что один "хвост" ему отрезают, а другой -- пришивают.Причем отрезанный "хвост" надо сразу уничтожить, а пришиваемый - прямо перед "этим" (или даже в ходе "этого") создать, да ещё с тем же значением maxCourceLoad!
Если требуется комментарий к решению с powertype, то он есть в книжке Milicev "MDD with xUML". В таком ключе: powertype придумали бизнес-аналитики, пусть они им и пользуются.Перечитал Milicev "MDD with xUML". Он просто своим OOIS UML никак не обрабатывает powertype, поэтому тоже не знает, может ли объект менять тип (или считает, что всегда не может).
На диаграмме чего-то странное с закрашенными ромбиками творится. Так что я -- тоже новичок и тоже пока ничего не понимаю. На языке стандартного UML прочесть её нельзя.Подумаешь от нуклеотида 2 композиции с множественностью 1..1 идут. Так много где делают, и считают, что это обозначает: каждый нуклеатид входит или в ДНК, или в РНК (но не в обе - композиция же, и куда-нибудь точно входит - минимальная множественность 1, а не 0)
Вы вот формируете какую-то запись. Можно же нарисовать диаграмму объектов. Судя по серой диаграмме между студентом и предметом может бытьЗдесь мой косяк - привык к тому, что если на диаграмме линии обобщения имеют общую стрелку (полый треугольник), то это означает, что имеется SetGeneralization с {complete, disjoint}. UML требует явного указания. Давайте считать, что для всех объединений стрелок обобщения на всех диаграммах указано {complete, disjoint}.
1. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени.
Или
2. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени и сдавать экзамен не будет
или
3. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени и сдавать экзамен будет
или
4. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени и сдавать экзамен будет, но еще не сдавал
или
5. Студент записался на Предмет и на момент наблюдение потратил на изучение Х времени и сдавать экзамен будет, и закончил обучение сдав экзамен
Разве тут нет логических ловушек?
Если мы выберем вариант 1, то так и не поймем есть экзамен или его нет, вернее это совершенно не важно, т.е. по сути это почти эквивалентно варианту 2
Аналогично, если мы выберем вариант 3, то остановимся на факте, что нужно сдавать экзамен, следовательно такая конструкция нелогична, нужно либо вариант 4 либо 5
Итого должны быть валидны только 2, 4 или 5
Итого имеем то, что можно смоделировать 4 атрибутамиНе обозначено:
Затрачено времени
Будет экзамен?
Дата экзамена
Оценка
Вся избыточность только в случае отсутствия экзамена.
Возможные решения
Между Студент и Предмет две связи с двумя классами-ассоциациями: Записан на курс (Затрачено времени), Есть экзамен (Дата, Оценка)
Может быть ввести отдельный класс - Экзамен - соединив его с классом ассоциацией Изучение - 1 ко многим, то есть фиксируется не одна а несколько попыток сдачи экзамена. Экзамен класс который как мы помним определяется в том момент когда Студент записывается на Предмет и тогда как-то определяется нужно ли ему сдавать экзамен или достаточно просто изучить предметЭто уже другая предметная область, для неё и другое решение
Но интересна практическая значимость всех этих знаний. Пример приводимой в ветке мне показался не очень убедительным.Класс-ассоциация сам (сама) по себе не очень обязательная конструкция и легко заменяется:
