Consider a simple example, you have a class that represents a
rectangle and you want to know its height, width, and area. How do you
show that the area is derivable from the height and width?

A common way is to show the height and width as attributes and
the area as an operation. People do this because that's how they would
implement it; fields for the height and width, and a method to
calculate the area.

UML also has a notation for derived properties, you prefix the
name with a '/'. So you could use this for the area.

Both of these approaches are reasonable and different teams do
different things. Some only use attributes for fields; such teams
don't use derived notation, or only do it when derivable information
is cached in a field. Others use derived markers when they follow the
same naming standard for derived values that they do for fields, such
as a getArea() operation or using properties in languages
like C# or Ruby.

My preference is to think about this slightly differently. One of
the key properties of an object is that they are encapsulated. If I'm
the user of the rectangle class I actually should not know or care
that the circumference is calculated. The implementor might store the
height and circumference and calculate the width - I shouldn't be able
to tell. So that would leads me to use an identical
naming convention for fields and for derived information on the
implementation, and to represent them all as properties on the class
diagram.

Does that mean I wouldn't use the derived marker? Actually no.
I'm happy to mark the circumference as derived, but it indicates that
there's a constraint between the three values, it doesn't specify what
is calculated and what is stored. So in a similar argument I would say
that if you have three side properties for a triangle it's reasonable
to mark one of them as derived.

In fact it matters less which approach you take than it does that
you follow a consistent style within your team. It's also important to
remember that different people do different things, so this is
something you'll need to figure out when looking at a foreign diagram.
(I use derivation less than I would in my books because of this
inconsistency of interpretation.) It's one of the many cases where the
UML is less rigorous than it would like to think it is.