This is the definition of a private field (if I had included it in the second box of my Class Diagram) of type int with the name counter. This way can save you typing out public, private, protected, static, etc. Although I like this, it is heavily dependent on what language you are using, and how you are using it. For example, in Objective-C if I wanted an "instance" method, I would go:
UML does not seem to be very applicable to this language, since it only has two access modifiers, - and +, and class fields can be declared, and have getters and setters in a matter of 2 lines of code, less work than diagramming your class using UML.
My real problems with UML begin when getting into the more complex areas of UML.
One of these problems, sequence diagrams, seem to keep haunting me. These diagrams are used to model how classes are created, destroyed, communicate, loop, make decisions, where your program will end up, and more. Mapping this out mentally would give me nothing but a headache, but putting this on paper doesn't do much more for me either. Once I get to this point I feel like it would be much more beneficial to simply start programming. I don't see a point to mapping out every little detail of functionality visually for the sake of understanding the flow of my program.