Diagrams are useful to help visualize data flow. The data is the foundation of virtually every program. Well done UML shows you where the data is stored (The model), what is looking at it (the controller), and how it might be presented (the view).
A concrete example of an MVC system might be a blog application. The data such as the blog entries, comments and such might be stored into a database. That's the Model portion. The view portion would be a set of routines which construct the html for the pages. These would not be complete, they would just be a framework, so if they were run without inputs, they would produce a few static visual elements, and some empty boxes. They are responsible for the aesthetic presentation of the content.
The controller would tie the two together by requesting data from the database, and handing it to the html routines for display, as well as accepting input from the user via the html pages, and making further data display requests.
An important aspect about this paradigm is that the interfaces presented by both the view framework and the database can be general. If the method for getting an article is always getArticle(ArticleID), it doesn't matter how the backend is implemented, be it an SQL database, a hash db or a set of flat files. All that needs to happen is that the raw article data is handed over.
Equally, the view software need only be able to handle the raw data. This is one of the reasons why CSS is important, and idea of markup is important. If your article data only has semantic markers, like paragraph, division, and so on, and avoid naming fonts or colors or other aesthetic attributes, then you can use the same interfaces for a view which handles the aesthetics completely differently. For instance, it could render it into braille, or speak it.
I hope this helps and isn't just another recapitulation of other explanations you have read.