I am really consufed and i can't indetify the parts of an sequence diagram. I see ppls make simple sequence diagrams for some process, and other ppls make it extremly detailed.
Can you please help me to find an good (not the best) sequence diagram for the following actions: Login Register
Let me explain you:
There is an Android application that Call web service in IIS Server
When user ask for login, get back as response Full Name if success (i don't want to represent failure in diagram)
In case of registration, user send data in Web Service. The Web service create an folder in HDD with user name. (It is file server, so we create user folder)
So, How i can represent the upper bullets in sequence diagram?
This is what i've done. I have no idea if it is right.
Sequence Diagram 1
Sequence Diagram 2
There is no right or wrong here. The level of detail exposed in your sequence diagrams is a choice your team should make. The only 'wrong' way of doing it, is when you have multiple SDs for the same application, showing different levels of detail.
Who are going to use these sequence diagrams? Let's assume that they are developers who must implement it and, in the future, technical designers who must know how the current version of the product works, in order to design extensions to it.
In my opinion, the level of detail should be such, that the SDs give a clear overview of the flow, which provides enough information to know where to look in the source code (once it's finished) if you want to know more details.
You should sit together with the developers and your fellow designers and decide which lifelines (the official word for the participating objects) are valuable to show in the SDs. Once you know which lifelines to draw, I think it is the best strategy to include all messages interchanged by these lifelines.
If your audience consists of people like architects or product owners, then sit together with them. They may be interested only in a global view, in which case you should include less details.
Looking at your SDs, you seem to be in doubt whether to include 'Login Activity' as a lifeline. Personally, I'd say yes, so I'd prefer Sequence Diagram 2.
For more information about sequence diagrams for web applications, check my paper, chapter Scenarios.
All you want are method calls and return values, so basic SD things.
Make a life line for the Android app and send a message from it to the IIS.
Show the return value (full name) in the return message.
You can send a message to a file service in the web server after authentication to create a folder. Eventually use an alt-fragment to show that it's doing that only on positive authentication.
So that's it. It's pretty much straight forward.
Related
I am currently working on the use cases for a car sharing app.
The simple diagram for the process of registration looks like this:
At the moment I am stuck with the following scenarios.
When a new customer is registered, a process is carried out at the head office (central)in which the following points are checked
Scenario 1 - Head office side:
1. The identity of new customers is carried out externally with
the post. Two possibilities: presenting the identity card at a post office branchor carrying out by video.
2. The verification of the customer's bank details is carried out externally with the bank.
3.The system will verify that the contact details (email address) are correct
4.the consent to the GTC has been obtained
My sketch for the confirmation process looks like this:
How do I show that the system verifies that the contact details (email address) is correct ? How do I show that consent to the GTC has been given ?
Scenario 2 - Customer's side: A customer can view and edit the information of his registration.
1.Edit profile data
2.Edit contact information
3.Edit bank details.
If information is changed during editing, verification must be carried out again by the head office.
What would the two use case diagrams look like ?
One or two apps?
(Posted before diagrams were added to the question)
Nothing in the narrative says that you need two systems. It's too early to decide about system architecture. You could have the following variants, each with pros and cons:
one and the same system (e.g. post office and customer access it via the web);
one and the same system that is accessible using different components on different devices (e.g. a rich client in the post office, a web interface for the customer on her mac/PC and a mobile app for a customer when using a smartphone);
several independent systems (e.g. a back office in the post-office, and an independent app that would connect not only to the back office, but also to other back-end services e.g. from other companies).
But how do you want to decide before first knowing what is needed and how the needs are related?
First, you have to understand the big picture of what's needed. Focus on the users not on the inner details of your solutions, as explained in the UML specifications:
UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. (...)
a UseCase (...) specifies a set of behaviors (...), which yields an observable result that is of value for Actors or other stakeholders (...)
(...) without reference to its internal structure
Look into your narrative to find actors (people, organisation, responsibilities), their goals (what do they need to do?) and how they could relate to each other. Just try a first sketch.
Your current model
(Posted after the diagrams were added)
I still see no reason to go for 2 distinct systems. You are working on a solution for car sharing. It may have different sub-systems/components, but the actors do not care. And neither does your customer. But:
If you'd go for two independent systems, you'd draw two disginct diagrams, and in each diagram you'd have an actor representing the other system that interacts with the system under consideration. As said, this makes sense only if it's an independent system.
In your case, I could imagine this for the bank account verification and the video identity verification: unless you intend to develop your own super-secured AI component capable of doing this, you'd probably outsource this to a specialized company, that may offer this service via an automated API.
The identify verification is at a different level of details than the other use-cases. You may want to show it in a separate diagram, in order not to pollute the main diagram.
And lastly, your second diagram has some issues:
the arrows of extend and include should not following the same direction: the target of an include is the included use case whereas the target of the extend arrow should be the use case that is extended (and not the use case that is extending the normal use case as you have shown).
ID correct and Bank correct are states. Use cases do not show states. The end-state can be specified in the description of the use-case but not in the use-case diagram.
Post office, Bank account, Video seem to be use-cases, but they are not well described.
A possible diagram could therefore be:
Note: I'd personally prefer specialization of Ensure identity. This corresponds more to the reality that there are two very distinct behaviors. But extension is ok.
Just to stress this fact: you do NOT describe a scenario with use cases. A use case is "just" to show the added value a system under consideration delivers to one of its actors. What you are asking is functional decomposition and that's just plain wrong. You would describe a scenario with an activity diagram (or as plain text like in the Cockburn way).
I have created a use case diagram for site similar to oDesk.
Site description: the place, where freelancers can find suitable jobs accordingly to their skills and pricing demands and where employers/clients can find suitable freelancers for their job postings with necessary skills and for stated price.
The goal of the site owner is: get income, by means of taking 10% fee from every payment made from employer/client to freelancer.
Have a look at the link below. Will be happy to hear any comments and advices!
I'm new here, but this question looks suitable for Business Analysts. This diagram does make sense. From my point of view, i would have added a "user" role (generalization of "employer" and "freelancer)". And aligned functions similar to "freelancer" and "employer" with "user" role.
From use full functionality point of view (it is what UseCase defines) your diagram is almost perfect. BUT, remove login usecase (it is not service..no body use system to login. Login is precondition for accessing security website functionality). Separate profile manage, block profile and other administration services (usecase) from the rest and build new diagram for them. There are mix of incompatible use cases at the same place.
Your "Make Payment" use case is off. You have it so that only the Employer doesn't make payments to anyone except possibly himself. Consider making the two types of payment into specializations of Make Payment (remove all the extends and includes except from the Make Payment to the Process Transaction), associating the Employer with the main use case, and associating the Site Owner and Freelancer each with the appropriate specialized use case.
Also, as Vladimir says, you might consider splitting this up into multiple diagrams.
The UML 2.4 documentation defines an actor as following:
An actor specifies a role played by a user or any other system that interacts with the subject.
In my case, the subject is a web service provided by a Soccer Association. The operations of the service are the 4 ones in the middle. Now, the website (or a web application) is the one which really interacts with the system (web service), but it won't do it by itself; it needs a user.
So, who is the actor?
Below you have an example of how I thought the diagram should look like, but I have doubts regarding its correctness.
I have one remark, and that's about the title 'Asking information use case'. The outer rectangle is the system boundary, so maybe 'Asking information system' would be more convenient. It is actually not a use case, it's the complete system you are describing.
Edit: after the change of the diagram: i would make the relationship between the 'visit webpage' use case and the other use cases as an 'include' (with the arrow pointing away from the visit webpage use case).
Then i would tend to agree with it.
I would split the use-case diagram into two diagrams. One for the web application and the other for the web service, since these are really two different systems.
In the first diagram, there will be two actors: the fan and the web service.
In the second diagram, there will be three systems actors: the web application, the Soccer Association, and the meteorological agency.
This splitting has the advantage that you can think of more use cases for the web applications without getting bogged down the details of the web service -- these two ideally should be independent systems.
I'm finding it hard to get around my head how the specific scenario would work out:
I have a database server, a web server and a user.
When the user registers a service is created to the web server, the web server then goes to the database server and returns to the web server to register the details.
How would I actually illustrate this.
I have created the three Actors; User, Web Server, Database Server.
As a note I have read many online resources, and also a Book on UML.
Thanks in advance.
Are the DB/web servers part of the system you're implementing? If so you don't need them as Actors. UC Diagrams should only show actors outwith the scope of your system.
So you only need one Actor (User) in this case. The Use Case should describe the goal from the User's perspective (e.g. "Buy a Widget").
You could show the servers in a diagram showing how the UC is realised - usually a sequence diagram or activity diagram. Although I'd typically expect to see logical entities (classes) as well / instead of the physical servers.
hth.
I agree with maple_shaft's last statement. A high-level UC (use case) is a vehicle for capturing requirements.
Req'ts are the "what" of a system. What is the system supposed to do. What does the user need to accomplish. What interaction does the user need from the system.
By capturing system components in your UC you are injecting "how" into it and that's inappropriate for a UC. You don't want your use case to say how the system will accomplish something as that's an implemenation decision.
In short, I disagree that you really want to create a Use Case diagram. This sounds more like a component diagram.
Use case diagrams should represent user flow and non-technical flow from a user perspective, not demonstrate underlying architectural structure.
How can I communicate in a very simple and effective way the path the user takes through my application?
I'm currently working in a Ruby and Rails environment, so I tend to visualize my application in terms of RESTful URIs. So for example, if I want my users to sign up, I could match a new route called /users/new. The thing is, I would like to see beyond that specific action, and visualize how many pages or forms does it take to create an account and some business logic associated with the process in general. In other words, I'd like to see a mix of a workflow diagram and some implementation details (at an interface level).
I was thinking in showing mockup pictures wrapped in boxes, and relate them through arrows with their corresponding GET, POST, PUT, DELETE methods and URIs attached to them. I think it is a good idea, but I haven't seen examples yet that inspire me.
In your experience, what helps you see the big picture? Balsamiq mockups allow to define links and navigate through the app, but it doesn't help to conceptualize.
Have you thought of using a mind-map? You could try the free FreeMind
If you stick with UML, you could consider an Activity diagram.
I think you're on the right path. Showing different screens with possible combinations of users' transactions between them is a good technique. Basically you would be able to show user's flow through your application and stress out decisions a user will make on the way.
The good example for it was presented here http://vimeo.com/43869717
This technique called Storyboarding. You should be able to find some examples. But the one I mentioned above is one of the best Storyboarding techniques. I use it all the time to show the big picture and present application workflow from user perspective to my team.