How to show relation between interfaces and classes in UML?

I have some related interfaces and classes that I want to represent in UML (sorry about the relationships, I don't know how to do it properly with StarUML):

The idea of an interface ISMS implementing IMessage and IStorable, instead of having directly the SMS class implementing itself both interfaces, aims to make the project more modular, maintainable, and easier to test.

Is this a good approach for the design? If so, is this a good way of representing them in an UML Class Diagram or is there a better way to represent an interface and its relationship with other interfaces/classes in UML?

I have a couple of remarks on top of Bruno's already very clear answer.

Your design

The decomposition of the interfaces into IStorable and IMessage seems at first sight to be a sound application of interface segregation principle.

Combining the two interfaces into a reusable ISMS interface instead of directly implementing them in a concrete SMS class will in this regard keep your code more maintainable, since it will easily allow to replace the SMS implementation with an alternative one (which makes sense if you consider that SMS functionality can be platform specific).

The question is however if SMS and email could not be used interchangeably. But only you can answer this question: If your design requires to keep those communication channels distinct (and maybe your real code adds some differences between the two interfaces), it's fine. But if not, it would make sense to allow such interchangeability and replace ISMS and IEmail with a single more general INotification.

Your UML representation

First of all, I'd like to reinforce Bruno's remark about the difference between generalization (plain line) and realization (dotted line).

Maybe I'm old school, but instead of using the circle for the interface, I'd advise for the more conventional interface as with a class box with the keyword «interface» above the name of the interface. Especially if you have properties and operations.

The circle is in my view better suitable for the lollipop notation of an interface. This is very practical when you have no much to say about the interface itself, but want to show what interfaces a class implements (lollipop) or is dependent on (socket). The interfaces details are then defined in another more detailed diagram. You can theoretically merge the two notations in the same diagram, but personally I find it less readable and would not advise it.