UML class modeling of callback functions/classes

Question

I'm no expert in UML, I just took a course before I graduated that spent a significant amount of time on UML modeling. I understand the basics but I was working on a project the other day and just for my own curiosity, I was wondering how you would model a callback. Here is a portion of the code I was working on

class OnChangeHandler():

    def my_init(self, rem, loc):
        self.remotes = rem
        self.locals = loc

    def process_IN_CREATE(self, event):
        #Do some work

    def process_IN_MODIFY(self, event):
        #Do some other work

class Watch():
    def __init__(self):

        self.wm = WatchManager()
        self. notifier = AsyncNotifier(self.wm, OnChangeHandler(loc=self.locals, rem=self.remotes))

I'm using a framework obviously, so I guess my question boils down to how would you model complex relationships where you are working with black box modules and frameworks? Is it just not even worth spending time on? But if so, aren't the majority of programs built within frameworks? I found UML class models to be really helpful when we were learning, but now I'm just confused.

Answer 1

You can reverse a framework by reversing the .class in order to get a class diagram.

See an example of a framework reverse at: http://www.ejb3.org/jar_file_reverse/jar_file_reverse.html The class diagram will give a view of the structure of the application and its architecture.

The sequence diagram is also possible in order to understand what is going on when running the application. It helps to have a better understanding of how a .java class could react with a framework .class class. See an example at: http://www.ejb3.org/jar_file_reverse/jar_file_reverse.html#3.Sequence_Diagram_reverse_engineering It is very useful if you need to add new code and reuse existing compiled code.

Hope this helps.

Answer 2

Just for the record. One could just model the methods for callback registration and invocation in the class. OTOH if one wants to have more of abstraction to match the framework components and stereotypes could be used, e.g. by extending the Interface metaclass with an Event and Callback stereotype.