I am creating this sequence diagram, and wondered exactly what methods to include. I have included all methods in every method, for example, the
handleCustomerAccountAction()
method, got a method from another class called
getListOfCustomers()
Is that right to do, or do you only have to include the method and not all the methods it uses inside it?
Also, is it okay to show the same method multiple times on other methods? For example the method
getListOfCustomers()
is shown three times (the one with a loop around it), but from different methods.
Here is the image of my sequence diagram:
It always depends on what you want to show. A SD shows a certain collaboration you want to explain in detail. A SD should focus on a certain aspect and must not show each and every message (e.g. certain call branches can simply be left out). However, if a method is called twice in a sequence you must show it if it's of importance.
Related
In UML Sequence Diagrams you have the combined fragment type Alt to branch based on different values for parameters. But let's say that in the middle of your sequence you are waiting for one of two different messages from two different external actors and you shall branch the code depending on which one arrives, what would be the best way to model this? And to make the question a little more challenging, let's throw in the possibility that neither message comes (triggering a timeout).
Without a better solution, I would divide the sequence diagram into multiple sequence diagrams, each new one starting with the one of the two possible messages. Or possibly just go over to state machines. But is their a not too convoluted way that would allow me to show these different cases within one sequence diagram?
I would simply go for the two SDs which you can name accordingly. One should always keep in mind that a SD shall highlight a certain aspect of a complex chain of actions in a system. Trying to put more and more information in a single SD will mess it up and hinder more than it helps.
It is also possible to use diagram fragments which allows navigation through zooming into the two fragments.
The timing diagram will not really help here. You would still need a large alt-fragment to show the sequences depending on which message arrived first.
In addition to the answer I referred in the comment, I made a little sample with a duration constraint for the timeout.
If you have a lot of conditional logic to show Activity Diagrams are an alternative. They do not have object responsibilities or a time axis, but because of this they can freely use two dimensions to show flow control.
I have a class (let's call it "CLASS") in two different EA diagrams.
CLASS is the same object in both diagrams.
I want to change the attributes order in one diagram without it automatically changed in the other diagram too.
Any ideas?
Thanks.
That depends on what you want. Do you want to show different aspects of the same element in the two diagrams then you can play with the Feature and Compartment Visibility (Ctrl-Shift-Y)
If you want to show different elements, but one starting as a copy of the other then you can Copy the element (Ctrl-C) and Paste as duplicate (Ctrl-Shift-V)
You can not do that. And it does not make much sense to hide single attributes or methods of a class in specific diagrams. Either all or nothing (to show just the class). EA has a way to hide single stereotyped element parts for a whole diagram. But that's not what you're looking for.
Maybe you can explain WHY you want to do that.
No, you can't do that. As you note, it is the same element (avoid using the term "object" here; object is actually a type of element in UML, just like class, component, use case, etc).
Attributes can either be sorted alphabetically (by default) or in some custom order which you set manually, but EA stores this order with the class, not with the diagram. In other words, the attributes of one particular class will always be displayed in the same order in all diagrams.
New users often find this type of issue confusing or even frustrating, until they realize that a diagram is only a visualization of the underlying model data -- it is not a drawing. This is why you don't do search-and-replace in models: you make a change to an element in one place and it is immediately reflected wherever else that element is shown.
The only way to show two different attribute sort orders is to make a copy of the class, but then of course it's not the same element anymore.
Background
I have one action (action_a) that calls an operation(operation_x) on another action (action_b).
The parameters to operation_x are as follows:
action_b.operation_x( param_1, param_2 )
I'm trying to work out how to document the parameters being passed in UML activity diagrams.
Option 1
One option may be to use a comment?
Option 2
Another option may be to use activity parameters, but it doesn't seem right to show two flows from action_a for one operation call?
Question
How can I show multiple objects being passed?
Option 2 is close, but the edges coming out of action_a are not right, and I don't think it's legal to show the call and the details on the same diagram. Please see my other answer.
What I am doing is get the marks of each and every student for a course, here I have created an explicit lifeline for students (the student list in the course object) and then even added a "get(indexValue)" method to show that it is iterated over to get each student.
The issue is that I wish to be a bit less detailed and more conceptual, how should I structure my diagram in order to show that there is looping over all the students in the course without explicitly defining it by using a studeentList lifeline and using a "get(indexValue)" method as seen in lists in Java.
Additionally is this representation correct if having a more detailed diagram was the objective as well. Also regarding breaking a loop I have used a return statement in a loop (as seen in programming languages), I have also seen some versions on the internet use "break" fragments to highlight this, is there a need to be specific for that either
You can put a loop box around the parts of the lifelines involved in the loop. In notes for the loop, you enter the continue/exit conditions. There are no "break" or "return" UML constructs. That is an implementation detail.
That said, if you want to get information for each student, I believe you'll have to use the studentList class to get info for each student in the loop. However, you can have one sequence diagram for how you handle each student and then the loop and the list are not necessary.
Remember that each sequence diagram has a precondition, a single scenario, and a post-condition. You can combine diagrams to show more complex behavior and decisions.
Before nested contexts my life was easy declaring some common functions from NSManagedObjects such as:
awakeFromFetch
awakeFromInsert
validateX
didChangeValueForKey
Through try and fail, call it, life lessons. I learnt to be more careful about those functions when using inheritance with my entities.
Now jumping to the nested context part of Core Data, I am getting used to see the very same NSManagedObject existing in several contexts. I am trying to grasp a key part of this: The above mentioned functions might be called several times from different contexts, but things like validation, value observation, and initialization are only relevant once. Therefore I normally check if the self.managedObjectContext correspond to the main context I work with. If they are the same, I run the whole function, if not, I just call [super] and return.
Is that the way I am supposed to deal with nested contexts?
Doing this has saved me several times. I was surprised seing awakeFromInsert called more than once for the same object, but even if I abort the initialization part of that function in all contexts but the main one, the information is persistet back to the store. I would like some confirmation that I am dealing with this topic the right way.
UPDATE:
Trying to make my ideas clear I wrote a post about this topic in my blog. What I wrote there has saved me several times from invalid entity layouts and other errors. However I am not sure if there are approaches better than mine.
http://www.digital-lumberjack.com/blog/2012/11/surviving-core-data/