На странице 180 спецификации UML 2.5.1 в разделе 9.9.7.4 “Атрибуты” для Generalization значение по умолчанию для возвращаемого булева значения мне не совсем понятно, если может быть возвращено значение null. Вот описание:
isSubstitutable : Boolean [0..1] = true
Указывает, может ли конкретный классификатор использоваться там, где может быть использован общий классификатор. Если это правда, то
следы выполнения конкретного классификатора должны быть надмножеством следов выполнения общего классификатора. Если
ложь, то таких ограничений на следы выполнения нет. Если не задано, моделировщик не указал, есть ли такое
ограничение или нет.
Значения по умолчанию предназначены для использования, если другое значение не задано; однако это уже так, если возвращается значение null булева типа, что указывает на то, что “моделировщик не указал, есть ли такое ограничение или нет.” Клиенты, запрашивающие этот атрибут, никогда не увидят значение null булева типа, если возвращается значение по умолчанию, и, следовательно, не смогут определить намерение или отсутствие такового со стороны моделировщика. Так зачем же тогда это дополнительное значение по умолчанию?
Я бы подумал, что объявление этого атрибута должно быть либо без какого-либо значения по умолчанию, либо с кратностью 1..1 и некоторым значением по умолчанию… имеет ли больше смысла здесь значение true, чем false, также является предметом дебатов. Если бы это зависело от меня, я бы вовсе убрал значение по умолчанию и просто установил кратность на 1..1.
Было бы здорово, если бы кто-то мог объяснить это мне?
Ответ
Вопрос, который вы подняли по поводу атрибута isSubstitutable в спецификации UML 2.5.1, действительно вызывает интересные размышления. Давайте разберемся в этом вопросе подробнее.
Понимание атрибута isSubstitutable
Атрибут isSubstitutable имеет тип Boolean и описывается в спецификации как возвращающий значение, которое указывает, может ли конкретный класс (специфичный класс) использоваться везде, где может использоваться общий класс. Логика такого атрибута заключается в соблюдении принципа подстановки Лисков, который является ключевым аспектом объектно-ориентированного программирования и проектирования.
Значения атрибута
-
true: Это значение говорит о том, что все операции и поведения специфичного класса являются расширением поведенческих операций общего класса. То есть, в любой ситуации, где ожидается общий класс, можно использовать специфичный класс без нарушения функциональности.
-
false: Это значение указывает на то, что специфичный класс не обязательно соблюдает поведение общего класса, и его использование в тех же местах может привести к неожиданным результатам или ошибкам.
- null: Отсутствие явного значения (null) в этой модели фактически указывает на неопределенность решения, принятого моделлером. Это значит, что моделлер не сделал заявлений о том, существует ли такая метрика подстановки или нет.
Ваши опасения
Вы правы в том, что наличие значения по умолчанию (true) может ввести в заблуждение при наличии возможности возврата null. Это может создать ситуацию, когда клиентский код, ожидающий boolean значение, может неверно интерпретировать отсутствие явного указания (null) как состояние подстановки, просто принимая значение по умолчанию.
Возможные улучшения
Ваше предложение убрать значение по умолчанию и установить множество значений на 1..1 вполне разумно. Это сделало бы контракт более строгим, обеспечивая, что моделлер всегда должен будет явно указать, является ли класс подставимым или нет, и избегая двусмысленности в интерпретации. При этом вы корректно отметили, что разумно было бы рассмотреть вопрос о том, что именно следует использовать в качестве значения по умолчанию — true или false, так как это также может зависеть от контекста конкретного применения модели.
Заключение
Таким образом, ваш вопрос выделяет важный аспект проектирования в UML и подчеркивает сложность управления семантикой атрибутов. Улучшение указанных вами аспектов может повысить прозрачность и надежность моделей, а также снизить вероятность ошибок и недопонимания среди тех, кто их использует. Подход с четким указанием значений и отказ от значений по умолчанию действительно мог бы улучшить спецификацию.