Notes:
Here is an example, using evolution as the application into which UML has hypothetically been embedded. There is a /proc-like filesystem used to import evolution internal data into the UML. The calendar, tasklist, and contact list are imported into the UML as subdirectories /evolution/calendar, ../tasks, and ../contacts, respectively. So, each calendar entry would have a directory or file under ../calendar, and similarly for tasks and contacts under ../tasks and ../contacts. New entries or changes made through the GUI will appear immediately in this directory.
Within the UML, we can then run any sort of tools we want in order to look at and manipulate these entries. For example, by putting this UML on the network and running a mail server inside it would allow us to automatically convert incoming email (sent to tasks@evolution.mydomain.com) into tasks. Or we could use some scripts to tie the task list to a bug tracker. New bugs would be sent to the embedded UML and converted into tasks. Conversely, finished tasks would be sent back to the bug tracker as closed bugs. Another example would be running a web server inside the UML in order to make the application Web-accessible.
These sorts of integration and network- and group-enabling require only scripting inside the UML, and require no changes to the application itself.