Design the application level code (i.e. non-GUI or "domain" code) first.  So
you might have (just for example) an instance of ChatApplication which
contained a BuddyList and (dynamically) zero or more ChatServers, plus (even
more dynamically) zero or more Conversations.

The visible part of the overall application would contains a "My buddies"
tab -- which would be connected to the BuddyList instance as its Model, and one
or more "Chatting with Bob" tabs, each of which would be connected to one of
the Conversation as its Model.  Each of the tabs would be/hold an instance of
its own class (just one instance of BuddyListPresenter and several instances of
ConversationPresenter).   Those panels would Observe the changes to the
Conversations (and so on), and update themselves accordingly.  Similarly the
overall window would Observe the ChatApplication (its own model) and would
add/remove "Chatting with.." tabs as Conversations started up or died.

On-the-wire events (incoming messages) would be routed from the ChatServers to
the Conversation objects and so reflected in the "Chatting with..." tabs.  Or
via the BuddyList to the "My buddies" tab.

The important point is that you have a nested structure of Models, and a (more
or less) corresponding structure of "presenters" which know how to control and
display the changing state of their models.

If you want to take my use of the word "presenter" as implying that I favour
MVP... Well, that's true, I do, but all I mean by the word here is "that which
implements the presentation".

If you want an easy test for whether you've got the separation right (and I
know that you didn't even hint that you did ;-)  It should be a trivial matter
to extend your application so that the user can spawn off any particularly
interesting conversation tab into a separate top-level window (obviously that
would take some extra Swing code to open the window, but it shouldn't require
much more than that).

   -- chris