veftech.blogg.se - Sequence diagram creator

Sure, diagrams are important, but really you are creating a model. A common misunderstanding is that UML is about creating diagrams. The previous posts have too many answers and not enough questions.

And the messages should then be mappable to function calls or system events.Some context: Recently for graduate school I researched UML tools for usability and UML comprehension in general for an independent project. But this shall make cristal clear what system object is responsible for what action in the interaction. Once the interactions with the user are clear, you can of course show an abstracted version in a sequence diagram. Other more specialised tools are more appropriate for the human perception of what happens (e.g.

Even Booch, Rumbaugh and Jacobson, the inventors of UML make this clear in their book “ Unified Process”, which is about using UML in the system analysis and design. UML is a good tool to show the system in its environment (use case) and show the internals of the system (most of the other diagrams).īut it is not a tool to document user interface scenarios. Use the right modelling tool for the right problem There is obviously a couple of things wrong here. In the latter case, you may probably want to go for a create message to conditionally create this life line.Īnd what is its role: why to you want to “show” a web page to an object ?Īnd why, if the login fails does the User object return the login form to the login form which then return the login form to the actor. Do you have a user object that exists all the time ? Or do you attempt to create it once you have all the elements ? The role of your :User object is not fully clear.

it is even questionned if it is legal to use an actor in a sequence diagram ( for example here or here or here).īut the goal of modelling is to better understand the design, so if the actor helps you, it’s up to you to decide on that formal question.

So the level of abstraction and the semantics are not the same on both sides of the diagram.

In reality the actor does not interact with the form, but with UI widgets on that form, and you have transformed this widgets into messages.

The first question is whether or not put the user (i.e. If you want to model the user interface scenarios, better go for some annotated wireframe scenarios. It is more accurately depicted as asynchronous communication (by using solid arrows with an open arrow head). That is not an accurate representation of how a (human) user would interact with a system.

Your diagram uses synchronized calls (a component makes a call and then does absolutely nothing until that call returns).

If you want to use an UML stereotype to indicate something is a page in your UI, you should choose another stereotype, like > or >.

The UML stereotype > means the same as a C#/Java class defined with the keyword >.

If you want to use it in a document, where you may not be around to explain the deviations from UML, I would propose some minor changes: It is mostly that you have used elements with a particular meaning in UML where that meaning does not match with what you want to express.Īs a sketch on a whiteboard with some verbal explanation, your diagram will do fine. There are a few things "wrong" with the diagram, but nothing major.