I'm designing some Sequence Diagrams for my project and decided to divide login and register use cases, creating two different diagrams (thought was a wise choice to separate concerns and simplify).
Now, when Register process is finished, I would like to tell the diagram to follow some path inside Login Diagram. Is that what Lost message is for? Like calling an event outside the diagram? Please clarify.
This is a Gate. UML 2.5 Specs:
17.4.4.3 Gate
Gates are just points on the frame, the ends of the messages. They may have an explicit name (see Figure 17.4).
17.12.9 Gate [Class]
17.12.9.1 Description
A Gate is a MessageEnd which serves as a connection point for relating a Message which has a MessageEnd (sendEvent / receiveEvent) outside an InteractionFragment with another Message which has a MessageEnd (receiveEvent / sendEvent) inside that InteractionFragment.
Related
The picture is taken from the book "UML # Classroom". The text says "the registration is via e-mail, that is, asynchronous".
In actuality, I believe, there would be no "Student" and "Professor" objects involved in the process. Rather an interface, a call to a mail server and in general, nothing that would tell the viewer of the diagram what is really going on.
That makes sense to me because it has an illustrative purpose. The methods of the classes in the sequence diagram would only resemble the methods in a class diagram at a low level.
If I am tasked with a high level view of class diagram and high level sequence diagrams of a particular interaction, if I am then asked why the classes of the class diagram don't have any of the methods of the sequence diagram, am I right to say that they simply don't have to?
Should I reach a compromise with the sequence diagram wherein I try to make the calls similar to what will be going on in the program?
The methods of the classes in the sequence diagram would only resemble the methods in a class diagram at a low level.
Not necessary, all depends on the goal of the sequence diagram, you can have classes at design level (may be allowing to generate code) but having them in a sequence diagram giving a semantic (high) level. You can also show these classes in class/package/... diagrams without low detail so not at design level.
The only rule is to have diagram saying something useful, and following UML specification of course. Do not forget UML is not a method but a language, it does not indicate how it must be used.
Remark you can put note in a diagram to help saying explicitly its level/goal in case you are afraid it is confusing because not 100% limited/dedicated to design even using classes part of the design.
if I am then asked why the classes of the class diagram don't have any of the methods of the sequence diagram, am I right to say that they simply don't have to?
yes, because the goal is not necessary to show a sequence of calls but for instance a higher level.
Should I reach a compromise with the sequence diagram wherein I try to make the calls similar to what will be going on in the program?
Of course you can do too.
Notice a sequence diagram (so in fact an interaction) has limited features, while for instance an activity allows to model a behavior in detail without the same limitations.
I'm working on my graduation project which is an online quiz website. now i'm drawing the UML activity diagram but it gets too complex and i can't add more details because at the end it must be printed in the project documentation in A4 papers.
can i split the diagram into multiple diagrams?. and if i did this should i repeat the login/registration actions in the beginning of each diagram?
Use structured activities to form logical groups. You can instantiate these activities as call behavior actions where needed.
Assume you have an activity Login
(the lying 8 is an invention of Enterprise Architect to indicate an embedded diagram; not UML standard)
which looks inside like
(just very simplified).
Now you can instantiate that like
where the fork indicates the action is a call behavior.
Adding activity parameters it would even be possible to parametrize these. Just like you would do when calling a function in a programming language.
I have an OPT (Optional) fragment in my sequence diagram and I wanted to draw it on my collaboration diagram but unsure if there is such a thing as OPT fragmnet in collaboration? I googled and couldn't find any solutions.
One of my friends told me to use: [condition]: someFunction()
But I don't know if that is correct way
A communication diagram (that is the official name) is just one of the four possible views on an Interaction (the others being sequence diagram, timing diagram and interaction overview diagram). Each of the diagrams will show different aspects of the Interaction. So, an optional Fragment will be shown as a frame in a sequence diagram and as a guard on the message label of the first message contained in the fragment in a communication diagram. Since the connection between the messages is only deducible by the hierarchical message number, it is harder to see this connection. On the other hand, it is easier to see the network of connections between the participants of the interaction in a communication diagram.
Im new in UML,
I am recently in charge of a web application, this application manages projects through a flow of states. There are multiple users within the application and each of them can intervene in the flow in a certain state.
Therefore I want to represent this information through a state diagram for me and for future developers do not have to ask the same question again.
My question is: How do I represent the different actors in the state diagram and their intervention in each of them?
Do I need to create a different state diagram for each actor?
Is there a diagram to do this that you do not know?
Thanks.
This is my example diagram and how an actor can pass from stateX to stateY
You try to oversimplify your model.
Each actor has certain system functionality that they can run. These single functionalities are called Use Cases (UC) and you present them on a Use Case diagram. This diagram shows which Actor can perform what Use Case but it does not show a relation to a state. While each Use Case can have pre-conditions defining what has to be true before the UC can be performed and post-conditions declaring what will be true if the UC ends successfully (which in your case would both probably be something like "System is in State A"), UC diagram does not support showing pre- and post-conditions. You can always add them in the notes attached to a UC.
To have a clear view of the system State Machine you can use two diagrams. One will be UC diagram, the other one will be State Machine Diagram or to be more specific Protocol State Machine. Then on State Machine you depict which UC causes what system State change while UC diagram provides information which Actor is eligible for running specific UC.
Finally you can use Sequence Diagram if you want to model how specific flow of interactions in the system impact changes of the system state. You can present states and actors on a single diagram here, but it is not designed, cannot and should not be used to depict all possibilities on a single diagram.
Disclaimer
Next part of my answer is opinion based
/Disclaimer
Most probably I would use UC diagram and SM diagram together according to information you've provided.
On the notation
A side note to your diagram - ovals are used only on UC diagram and represent Use Cases. They are not associated with each other, only with Actors.
States are presented as rectangles with rounded corners (both in State Machine Diagram and Sequence Diagram).
I am new to the world of UML and have so far learnt the basics of use case, activity and deployment UML diagrams. I have a requirement of where users interact with a system e.g. user sending an email, which is then processed by a system and then sent to an agent (person) who then responds and interacts once again with a system.
I am having a hard time picturing these requirements and whether it should be a combination of use case, activity or deployment. Can I intermingle them? What is standard practice?
As you know, use cases are used to capture requirements. When identifying and detailing use cases, you look at the problem from the perspective of users. Only focus on what an actor expects the system to do. First step is to identify the use cases and actors and then detail the use case flows.
1- Identify the use cases and actors
In your example send email could be a use case initiated by the end user (your actor). What happens next (e.g system sending a notification to the agent) could be modeled as part of the flow of this use case.
Another use case could be the agent actor handling what they have to do after receiving the notification from the system (a prerequisite of this use case could be that a notification has been received).
Note that you could combine these two use cases together and have the agent as a secondary actor (secondary actor interacts with the use case but does not initiate it). Whether you do this or not, is a modeler's choice and depends on the size of use cases, number of use cases and many other things.
2- Detail the use cases
After identifying use cases and actors, you should detail use cases. The most important part is to detail the use case flow (step by step interactions of actor and system). This can be written as text or drawn as an activity diagram.
So to answer your question: yes it is possible and very common to combine activity diagrams and use cases; that is an activity diagram drawn to show the flow of steps of a use case.
Deployment diagrams on the other hand are totally irrelevant to the requirement elicitation phase. They model the physical structure of the system and how hardware components and software components interact.
In fact, it is very odd that you have learned component diagrams before class diagrams, sequence diagrams, state diagrams and many other diagrams.