How to completely decouple Model from View/Controller in Java Swing

Question

Is there a collection of commonly-agreed-upon design guidelines for separating the Model classes from the View/Controller classes in a Java Swing app? I'm not so concerned that the View/Controller know nothing about the Model as the other way around: I'd like to design my Model to have no knowledge of anything in javax.swing. Ideally it should have a simple API enabling it to be driven by something as primitive as a CLI. It should be, loosely speaking, an "engine."

Communicating GUI events to the model isn't too hard -- the Action Performers can call the model's API. But what about when the model makes its own state changes that need to be reflected back to the GUI? That's what "listening" is for, but even "being listened to" is not entirely passive; it requires that the model know about adding a listener.

The particular problem that got me thinking involves a queue of Files. On the GUI side there's a DefaultListModel behind a JList, and there's some GUI stuff to choose files from the file system and add them to the JList. On the Model side, it wants to pull the files off the bottom of this "queue" (causing them to disappear from the JList) and process them in some way. In fact, the Model code is already written -- it currently maintains an ArrayList<File> and exposes a public add(File) method. But I'm at a loss as to how to get my Model working with the View/Controller without some heavy, Swing-specific modifications to the Model.

I'm very new to both Java and GUI programming, having always done "batch" and "back-end" programming up to now -- hence my interest in maintaining a strict division between model and UI, if it's possible and if it can be taught.