Those have been in UML for years. (Google it.) Actually, that's the problem: everything is in UML. I am sure someone pointed out that "X" had it but UML didn't, so they made sure to add it.
BTW, a 20 year old link is not going to present anyone with up to date tech info. You have to make allowances for the progress of rival technology.
Said parent commenter:
"Without any good life strategies the happiness money brings peaks at 70k or such (basically you don't have to worry about regular life expenses)."
Please! Try having a few kids and living in a desirable metro area. I didn't stop worrying about money until my salary was twice that, and my wife works too.
So many sayings about financial happiness seem written for single people with no dependents.
Your example of needing to define a type because "int" is not good enough is very C/C++ centric.
Most languages don't have the plethora of integer types that C has. Java, for example, has just has 2 in general use: int (signed 32 bit) and long (signed 64 bit). (Nobody considers byte a general integer type.)
In C/C++, you have to define so many things about the types you use because so much is "implementation dependent." So for C/C++, you may be correct. Most other languages define their types more stringently and include a smaller number of general purpose types.
You deal with a lot of data that is of only a few simple types, and as I said in my post, interoperability means you can't get too crazy with your class definitions. They need to stay simple or the SYSTEM will become more complicated.
As for a variable never staying a simple type, again, see my example in my previous post. A string id is going to stay a string id and its data and behavior is dictated by being an id to remain supersimple.
I am not against defining new types; I am against defining a new type for every single variable "just because."
All you have accomplished really is to move the descriptive name from the variable's name to the variable's type, and at what cost? You now have to create a whole new datatype. The programmer must look up that datatype and see oh, it's just an int. And now you need conversion routines or worse yet casting to convert that type to a simple int for interop reasons (database, UI).
Experience has shown that it is very productive to have a small number of generally useful datatypes which are augmented by custom datatypes.
Creating a new datatype for something as simple as an int or String defeats that and makes it more cumbersome to work with. (It's especially unwarranted for a variable that is an immutable variable serving as a simple id.)
BTW, a 20 year old link is not going to present anyone with up to date tech info. You have to make allowances for the progress of rival technology.