Пространства имен UML и «isDistinguishableFrom»
Эта операция описана на стр. 91 спецификации UML 2.5.1 в разделе 7.8.9.7 «Операции» для описания NamedElement. Я пытаюсь понять, как это можно сделать, как указано:
Запрос isDistinguishableFrom() определяет, являются ли два NamedElements могут логически сосуществовать в пространстве имен. По умолчанию два именованных элемента различимы, если (а) у них есть типы, ни один из которых не является типа другого или (б) у них разные названия.
В каких языках программирования два одинаковых имени могут сосуществовать в одной области действия только потому, что они имеют разные типы? Есть ли они?
Судя по всему, не работает на С++:
#include <iostream>
int main() {
int a = 4711;
const char *a = "Hello, Strange World";
++a;
std::cout << a << std::endl;
return 0;
}
/////////
bob@my_laptop:~/code$ g++ -c strange.cpp
strange.cpp: In function ‘int main()’:
strange.cpp:6:15: error: conflicting declaration ‘const char* a’
6 | const char *a = "Hello, Strange World";
| ^
strange.cpp:5:7: note: previous declaration as ‘int a’
5 | int a = 4711;
| ^
Говоря о типе, я думаю, они имеют в виду метатип. Таким образом, вы можете иметь класс, свойство и операцию с одинаковым именем.
В C++ вы вполне можете дать одно и то же имя классу, функции или экземпляру, потому что путаница абсолютно исключена.
В C++ вы вполне можете дать одно и то же имя классу, функции или экземпляру, потому что здесь абсолютно невозможна путаница. Неприятный пример: ideone.com/VAu9TB — Я бы, конечно, не рекомендовал такую практику ни в C++, ни в UML.
@Christophe Спасибо за пример; Я собирался попросить тебя об одном! Вчера вечером я начал перечитывать стандарт C++ о правилах поиска имен. Я поигрался с вашим примером, но думаю, что поиск по имени не учитывает все объявления MyType; Я не мог найти способ ИСПОЛЬЗОВАТЬ оба i и t в одной и той же области. Однако меня больше интересует мотивация определения ограничения UML как оно есть. Конечно, для профиля C++ его придется переопределить. Но какие языки могли бы использовать это таким образом?
Спецификация UML для Variable указывает, что через ConnectableElement это TypedElement и, следовательно, NamedElement - здесь нет большого сюрприза, но это означает, что имя переменной может быть таким же, как и какая-либо другая переменная в том же пространстве имен, если бы они имели разные имена. типы, и ограничение UML по-прежнему будет удовлетворено. Однако, если это так, как говорит @GeertBellekens, цель ограничения заключалась в проверке типа метакласса вместо смоделированного типа, поскольку оба будут иметь тип Variable, они должны будут иметь разные имена.
Ответы 3
Язык под названием UML не предназначен для представления каких-либо вещей в реальности, будь то типы животных или классы Java. Таким образом, если вы хотите перевести UML на какой-либо более ограниченный язык, вам нужно будет наложить эти ограничения на использование UML. Иногда вам даже нужно дополнить UML профилем, чтобы сделать язык таким же выразительным, как какой-либо другой язык, например OWL.
Проще говоря, то, что работает в UML, не обязательно должно работать в C++.
Для чего нужен UML? Сколько проектов реализовано в OWL по сравнению с такими языками, как C++ и Java? Мне хотелось бы думать, что между полезностью UML и его реализациями все еще существует какая-то прямая связь. Кроме того, вы не ответили на мой вопрос: "Какие языки программирования существуют, где два одинаковых имени могут сосуществовать в одной области только потому, что они имеют разные типы? Есть ли такие?"
@RobertHairgrove Я бы не поспорил. Слышали ли вы когда-нибудь об эзотерических языках? Есть большие чудаки. P.S.: en.wikipedia.org/wiki/Esoteric_programming_language
@qwerty_so лол! Я никогда не слышал ни о чем из этого. Но сегодня я узнал кое-что новое, спасибо!
@Jim_L Вы, конечно, правы в том, что профиль C++ будет переопределять и/или добавлять любые ограничения, которые ему нравятся.
@RobertHairgrove язык Alf должен быть полностью совместим с UML. Я считаю, что два имени разных типов могут сосуществовать.
@ДжимЛ. Интересно... на самом деле существует два языка программирования по имени Альф, но разных типов. :) en.wikipedia.org/wiki/… Итак, я думаю, имя соответствует определению ограничения!
@RobertHairgrove Я имел в виду en.wikipedia.org/wiki/Executable_UML#fUML_and_ALF
Если вы прочитаете дальше, вы найдете спецификацию OCL для того же ограничения.
body: (self.oclIsKindOf(n.oclType()) or n.oclIsKindOf(self.oclType())) implies
ns.getNamesOfMember(self)->intersection(ns.getNamesOfMember(n))->isEmpty()
В этом формальном выражении мы видим, что types, упомянутый в объяснении открытого текста, относится к .oclType().
Если мы затем проверим спецификацию OCL, мы обнаружим
oclType(): Классификатор
Оценивает тип, экземпляром которого является self.
сообщение: self.oclIsTypeOf(результат)
Поскольку это ограничение OCL записано в метамодели UML, ясно, что оно относится к мета-типу элемента, а не к классификатору, известному как тип.
Это означает, что в пространстве имен разрешено иметь
- Класс с именем А
- Ассоциация с именем А
- Операция с именем А
Поскольку ни класс, ни ассоциация, ни операция не являются видом друг друга.
Не допускается иметь
- Тип данных с именем A
- Перечисление с именем A
Поскольку перечисление является типом данных KindOf
Это во многом соответствует тому, как ограничения именования реализованы в большинстве языков программирования.
Прежде всего, моделирование — это также вопрос суждений, и поэтому разработчику модели остается разумно использовать возможности UML.
Даже в C++ в редких случаях элементы разного типа могут иметь одно и то же имя в одной области без какой-либо путаницы:
class MyTest {};
int MyTest() { return 1; };
Но несмотря на то, что язык позволяет это, большинство разработчиков будут избегать этого из-за путаницы.
В более широком смысле, в проекте C++ имя исполняемого файла MyTest может иметь то же имя, что и класс MyTest, который он реализует. В UML и артефакт, и класс могут иметь одно и то же имя в одном пакете без какой-либо путаницы.
И последнее, но не менее важное: вы можете представить себе реализацию компонента, предоставляющего COM-интерфейс, который имеет то же имя, что и класс C++, реализующий компонент. Опять же, реальность Microsoft C++ может иметь смысл и оправдывать использование одного и того же имени для разных элементов разных метаклассов в UML.
Как объяснил Герт, у вас может быть ассоциация и класс с одинаковым именем. В большинстве случаев это кажется абсурдным, не так ли? С другой стороны, существуют классы-ассоциации, которые одновременно являются ассоциацией и классом, и оба должны иметь одно и то же имя (на этот счет даже есть правило). Таким образом, эта очевидная абсурдная гибкость UML в некоторых случаях имеет смысл. Разве не было бы разрешено, нельзя было бы последовательно обращаться к именованию ассоциативных классов в соответствии с их семантикой.
Итак, в заключение, хотя в большинстве случаев разработчику модели следует избегать этой возможности именования по собственной инициативе, тем не менее, есть случаи, когда это оправдано и даже необходимо, и это, вероятно, причина гибкости UML в этом отношении. .
Конечно, некоторые типы переопределяют эту операцию, например BehavioralFeature, чтобы учитывать сигнатуру функции, которая может быть перегружена другой функцией с тем же именем.