How can you draw a self-call and recursive call with Umbrello like this
The only option I can see from the app calls to other actors.
Am I missing something?
Related
I have created a sequence diagram and one of the objects will do a self function and inside of the function it will call the other class object function. How do i represent this correctly in a sequence diagram? My current diagram show it this way for now but i don't think its the right way to show it.
The self-call can be represented with an overlapping execution specification (rectangle). This allows to distinguish the call from the execution of the called function, and to visualize with accuracy what happens in the self-call, and what happens after the self-call returns:
I have been working a a very dense set of calculations. It all is to support a specific problem I have.
But the nature of the problem is no different than this. Suppose I develop a class called 'Matrix' that has the machinery to implement matrices. Instantiation would presumably take a list of lists, which would be the matrix entries.
Now I want to provide a multiply method. I have two choices. First, I could define a method like so:
class Matrix():
def __init__(self, entries)
# do the obvious here
return
def determinant(self):
# again, do the obvious here
return result_of_calcs
def multiply(self, b):
# again do the obvious here
return
If I do this, the call signature for two matrix objects, a and b, is
a.multiply(b)...
The other choice is a #staticmethod. Then, the definition looks like:
#staticethod
def multiply(a,b):
# do the obvious thing.
Now the call signature is:
z = multiply(a,b)
I am unclear when one is better than the other. The free-standing function is not truly part of the class definition, but who cares? it gets the job done, and because Python allows "reaching into an object" references from outside, it seems able to do everything. In practice they'll (the class and the method) end up in the same module, so they're at least linked there.
On the other hand, my understanding of the #staticmethod approach is that the function is now part of the class definition (it defines one of the methods), but the method gets no "self" passed in. In a way this is nice because the call signature is the much better looking:
z = multiply(a,b)
and the function can access all the instances' methods and attributes.
Is this the right way to view it? Are there strong reasons to do one or the other? In what ways are they not equivalent?
I have done quite a bit of Python programming since answering this question.
Suppose we have a file named matrix.py, and it has a bunch of code for manipulating matrices. We want to provide a matrix multiply method.
The two approaches are:
define a free:standing function with the signature multiply(x,y)
make it a method of all matrices: x.multiply(y)
Matrix multiply is what I will call a dyadic function. In other words, it always takes two arguments.
The temptation is to use #2, so that a matrix object "carries with it everywhere" the ability to be multiplied. However, the only thing it makes sense to multiply it with is another matrix object. In such cases there are two equally good ways to do that, viz:
z=x.multiply(y)
or
z=y.multiply(x)
However, a better way to do it is to define a function inside the file that is:
multiply(x,y)
multiply(), as such, is a function any code using the 'library' expects to have available. It need not be associated with each matrix. And, since the user will be doing an 'import', they will get the multiply method. This is better code.
What I was wrongly confounding was two things that led me to the method attached to every object instance:
Functions which need to be generally available inside the file that should be
exposed outside it; and
Functions which are needed only inside the file.
multiply() is an example of type 1. Any matrix 'library' ought to likely define matrix multiplication.
What I was worried about was needing to expose all the 'internal' functions. For example, suppose we want to make externally available matrix add(), multiple() and invert(). Suppose, however, we did not want to make externally available - but needed inside - determinant().
One way to 'protect' users is to make determinant a function (a def statement) inside the class declaration for matrices. Then it is protected from exposure. However, nothing stops a user of the code from reaching in if they know the internals, by using the method matrix.determinant().
In the end it comes down to convention, largely. It makes more sense to expose a matrix multiply function which takes two matrices, and is called like multiply(x,y). As for the determinant function, instead of 'wrapping it' in the class, it makes more sense to define it as __determinant(x) at the same level as the class definition for matrices.
You can never truly protect internal methods by their declaration, it seems. The best you can do is warn users. the "dunder" approach gives warning 'this is not expected to be called outside the code in this file'.
I would like to know what do you believe is the more elegant way to handle common code executed after a conditional synchronous function call.
For example, assume that there is a function that handles "identify and sort shapes from smallest to largest". Depending on the condition result (e.g. "is the shape to be searched for a triangle or a circle?"), one of two different asynchronous functions can be executed (assume in my example that for some reason the logic can't be combined into a single function):
Find all shapes that are a triangle
Find all shapes that are a circle
Based on the outcome of one of the two functions (depending on the condition), the subsequent section of code would have to be executed. That logic (call it "sort shapes") is assumed the same regardless whether the shape being searched for is a triangle or a circle.
If I used callbacks, I would separate the code after the calls to 1 and 2 above, into a separate dedicated "sort shapes" function that would be the same callback, like this:
function identifyAndSortShapes() {
if (searchingForShape === TRIANGLE)
findTriangleShapes(sortShapes) // sortShapes is the common callback
else
findCircleShapes(sortShapes)
... // The common code that would have been here is then moved to a
... // separate (callback) function sortShapes, due to the asynchronous
... // functions sharing the same callback logic
}
function findTriangleShapes(callback) {
... // Some asynchronous operation, e.g. DB query
callback()
}
function findCircleShapes(callback) {
... // Some asynchronous operation, e.g. DB query
callback()
}
function sortShapes() {
...
}
But is this practice (separating the code that I would have left within the identifyAndSortShapes function, into a separate sortShapes callback function) the right way to go? Or is there a more elegant way to handle this conditional asynchronous function call and then have the same callback code for both without having to create a separate function?
Apologies as my abstraction example might not be the best choice, but I think it shows what my current issue is. I believe this might be a basic conceptual one (on how to properly structure asynchronous code), so I look forward to your advice that could help me shine some light on this.
I'm creating some sequence diagram and i want to detail my calls, but there is a class which call successively intern functions, would it be ok if i draw it this way:
If not how could i do ?
thanks !
No, that's syntactically simply wrong. You would use a Loop Fragment:
funcA is an internal call. Inside the two operations funcB and funcC will be called in a loop which is guarded by the condition some condition. This could as well be N times or whatever constraints the loop.
When a caller is higher in the stack, what does this mean? For example, lets say I start a program, a form loads up (we'll call this a), then this form calls another form (b). The called form will be at the top of the stack, so if this form called form a, will this be a caller higher in the stack making a call to something below?
Thanks
I think you have the wrong impression of the call stack. The call stach is just a "list" of the functions that have been called. When ou have a call chain like you describe, a calls b which calls a, your stack is just:
a.second
b.first
a.first
You can't really call "down" to something. You make another call, and it goes on top of the stack, even if it has been called before, the previous call is completely different, the new call starts a whole new "stack frame".
You need to distinguish between the object making the call (if any), the target of the call, and the method being called. For instance, your call stack could easily look like this:
FormA.Method3()
FormB.Method2()
FormA.Method1()
This is an instance of FormA executing Method1, calling Method2 on an instance of FormB. That then calls Method3 on an instance of FormA - either the same FormA as the first one, or a different one. It doesn't really matter.
It's not really a case of calling "something below" because the stack frames don't represent objects - they represent methods (and the state within those methods). Does that help at all, or is it just confusing things more?