I have an analysis exam tomorrow and one of my designs is a sequence diagram. I do not know if I have got it right. Its pretty simple, its supposed to illustrate a teacher who creates an assignment and posts it to a schools website, then a student gets a notice and the teacher is able to edit or add more files to the assignment. Repeat
Is it something wrong with this diagram? What could I have changed?
What are some key points about sequence diagram that I could say in my oral exam.
Strictly speaking, what you draw is NOT a sequence diagram in UML spec. There are more than one correct ways to draw a sequence diagram for a given flow.
Here is a sequence diagram I created with ZenUML (I created this tool btw). There are a few key items in a sequence diagram - lifeline, message and fragment.
This answer is certainly late for the exam, but your diagram looks ok. For the sake of completeness, here some minor remarks:
the messages are certainly all asynchronous (i.e. the website will not wait for the student to answer the notification before it continues its job); so the arrows should have an open head
you could consider using a combined fragment (with operator loop) around the interactions related to the addition of a file, to show that this part may be repeated.
all messages in your diagram describe interactions. The wording "web page is updated" suggests a state, whereas a wording "notify student of the update" would be more consistent with the rest.
the first execution occurence ("activation bar" on the lifeline) on the website should start with the incoming message that triggers the related activity. Similarly, for the student I'd put a small activation bar after each notification, instead of a continuous one.
Related
I was reading about statechart diagrams, which are diagrams that model the different states that one or more instances of one or more classes can be.
An object can go from one state to the other through a transition, which is represented using arrow with an event and eventually a action to that event over and respectively below it.
My problem now is that I don't understand exactly what are OR and AND decompositions in a statechart diagram. Could you please give me an explanation (since I've not found around any)?
I would really appreciate a concrete example with the corresponding picture or diagram.
The following picture is an example for an OR. Consider a token traveling from Initial to the Choice (diamond). Here the token travels either to the left or right guided by the constraints which test the condition checked in Choice. From then where they are they next transit through the following unnamed diamond to Continued. You might leave away the joining diamond and draw the transitions directly to Continued.
The AND condition looks like this:
The first Fork(the bar) duplicates the token and sends them to Either and Or. The Join behind these states waits for two tokens to arrive before it sends only one token further to Continued.
Fork and Join use the same symbol. They wait until all incoming tokens arrive and then send as many tokens as there are outgoing transitions. So they are actually some split personality. But mostly they are used the one or the other way.
When designing flowchart models for my programing, I sometimes ask myself if I am drawing email communication between swim lanes the best way. Perhaps there are some who has better suggestions to describe the following process?
A wants a specific customer list from B. To do that, A has to send a request to B - it could be an email. B creates the list and sends it back to A.
UPDATE
My initial illustration wasn't UML so I try with this instead - ready for your comments:
Actually this is a perfect and overall used approach. Rather than using swim lanes, which are just graphical elements on the diagram, you should use ActivityPartitions (which are real UML elements) which you can classify with the actors in question.
Further you should use ActivityInitial (full circle) and ActivityFinal (hollow circle with large dot in center) to mark the start and end of your flow.
For more examples see here.
N.B. Just noticing this is tagged with Visio. Since Visio is a pure drawing tool you should consider using a real UML modeling tool instead.
P.S. I see that Geert removed the UML tag. So I may have been deceived by the question and thinking of this as being an UML activity diagram. So that's what my answer refers to. Anyhow, since flow charts are ancestors of activity diagrams this might help as well.
I have made an activity diagram for gym management, but i am facing a problem how will i connect Receptionist with Admin, According to requirement activity between Admin and receptionist takes place only through notification and i have made a signal and receptor for notification. Please also check if every notation is right and suggest me for modification?
I am sorry for not answering at once - several times had I looked at your picture, and, frightened, retreated.
You really tried and did something. It is good. But... You have put Use Cases directly into the activity diagram. So as is, it has no sense.
Let's take a customer. He has his swimlane. Good. According to your diagram, the customer comes and decides, what to do - immediately leave, join or inquiry. It doesn't matter, if he joins or inquiries, the result is common (why had he been choosing?) - he gives some unknown message to the receptionist. He never gets something back, never he does smth. else, he remains here and becomes immortal, because even his death won't finish his state of being here, waiting for some reaction from anybody. Poor man!
I don't think it is necessary to analyze here other swimlanes - they are even worse.
Better divide your work into levels.
Use Case diag. Define, who are actors (you have defined them well) and what are their interaction with system and its parts.
As the next stage you can make a deployment diagram - where are components of the system and maybe, actors, located and what messages they send to each other, defined.
And only now you can start with Activity diagram.
Also notice, that you'll have to return and correct the elders diagrams when you'll come to a dead end or some radical changes in the younger ones. You'll meet with both, be sure.
And when you have some problem with some diagram, come here, write down what you had BEFORE it (you didn't), what you have done on this stage (you did it) and we'll be able to help.
i am currently doing an dynamic model for my ojt project. but i am stuck on a particular problem, my idea of a solution just seems overly complex.
to explain it in a different context, lets say i have 2 classes: customer and salesperson. the customer is buying something from the customer. but before everything is settled, they have to undergo a series of activities. after each activity, both the customer AND the salesperson have to chance to back out of the transaction. put in a diagram it looks like this:
is this correct? how about when i have like 50 possible activities? then that diagram will become very unreadable. what is a good way to solve this?
If you look at InterruptibleActivityRegion in the UML spec (section 12.3.33 of UML 2.4.1 superstructure ), it gives a similar example of cancelling an order at any point before the transaction is agreed. Within the interruptible region, which is notated as a dashed rounded rectangle with a Z shaped arrow coming out of it, all the activities may be interrupted by the event associated with the arrow - in your case backing out - and end up in the interruption handling activities.
You should use interruptible activity region. For a quick reference, see this sample diagram:
I have a question about UML diagrams.
Can be displayed relations between loose coupled components on sequence diagrams?
It is required in loose coupled environment (MQ) or optional?
For example, component "A" put some message into queue "X", then component "B" takes this message from queue "X". Should be this relation displayed on sequence diagram?
Thanks for help.
The one sequence diagram is not good place for it because according your question there are TWO asynchronous interactions.
The best way is to use TWO sequence diagrams or state chart diagram (you can use it to describe how queue works)
Yes, you can do that. A sequence diagram demonstrates how components/classes interact in a use case. As long as the resulting diagram clearly demonstrated the interaction you are modelling then you should show the interactions. If the diagram looks very cluttered and difficult to read then you could split in to 2 seperate diagrams; first shows 'A' put the message on the queue and the second diagram shows 'B' pull the message off the queue. Ultimately, you need to make the concepts in the diagram easy for somebody to read, so less clutter the better.