I want to create a very basic sequence diagram for the first iteration of my app. I have a database of exercises, and I have a use case for creating, another for editing, and another for deleting an exercise. They are all very simple, and use the same elements and actors, like User, DAO, and Database. What I want to do is to create a single SD, that begins with the user asking to create an exercise, followed by the user asking to edit that exercise, and then asking to delete it. My question is: is this considered correct in a sequence diagram? I don't want to create 3 SDs almost identical to one another, and this seems like a simple way to represent all the information, but I don't know if this is correct by UML standards. Thanks.
From a standards conformance point of view, there is nothing in the UML standard, that imposes a relationship between your use case models and sequence diagramme models. So, no matter how many use cases you want to reflect in a sequence diagramme, it would be neither "correct" nor "incorrect".
From a personal point of view : What you are asking about is a question of modeling style, not conformity. As long as the people who are reading your models understand them, you can do whatever you want. So, something like this would be perfectly fine :
Related
I just create this diagram can anyone tell me if these 2 pictures are correct or wrong and which one should I use?, can anyone tell which is correct in these 2 pictures.
Both diagrams are ok, except:
the association between an actor and a use case should be straight lines and not directed arrows. These arrows are an obsolete practice.
the subject rectangle should be closed
actors not related to anything are useless and should be removed
The question of whether add and edit should be in the same use case or in distinct ones is up to you to decide:
grouping them has the benefit of simplifying the model. Manage students could be even more generic and is quite common.
keeping them separate may appear more granular but makes sense if there are different actors or if the business needs are very different.
You may read more to make up your mind, googling for CRUD Use case.
With this Use Case diagram, I'm unsure if I'm currently doing it correctly or not. Checked online and each site is giving me a different answer. I just need a direction or someone to correct me.
This is interesting as I am currently going through the exact same discussion with a client...
I would say "no" simply because I am unsure of what this actually represents.
A use case must bring a benefit to a user, and I really don't this in this diagram. What does Actor0 actually trying to accomplish? I do not get this from the diagram.
Did you write down statements before trying to do this? I find that going to a whiteboard and writing down what your actor's goal and how you see this happening so that the actor achieves the goal is a good start to better understanding the use case and differentiate the system being built from external systems. One way to do this is through a set of user stories (or use case slices).
And answering Thomas Kilian's excellent questions will also help you in this task!
Also, you are doing something that I see too often from people starting with use cases (and sometimes with UML experience): use case decomposition as a set of actions - basically trying to model a set of activities by breaking it down. Doing that is typically the second step in your analysis (e.g., by using activity and sequence diagrams).
No. Only "Register" (what?) and "Add/View Details" (which?) can be regarded as use cases since they add value. Neither "Login" nor "Main Menu" are use cases. The first is a constraint and the second an implementation detail.
[Original Title] : Does an actor need to point directly in use case diagram?
or can I do it like this?
in this Use Case Diagram, I want to say that actor can use any use case in the pointed group-of-use-case.
does this kind of thing allowed?
Edit #1
The reason why I ask this question, is because when I create this use case there's a lot of line intersecting each other that makes me confuse.
And there's a comment :
It would be better to split that into smaller diagrams
does it mean like this?
Edit #2
after reading comment :
A UseCase specifies a set of actions performed by its subjects, which yields an observable result that is of value for one or more Actors or other stakeholders of each subject.
so I decided to change to this :
is this how a use case diagram should be?
Edit #3
CONCLUSION
An actor should point directly to use case
Read more the detail about how a Use Case Diagram should be in comment on this question
To be UML compliant you can not do that. But I guess one can understand what you are trying to communicate.
As a side note: Login is not a business use case. It is a constraint. Also with CRUD use cases I would not separate them but have a Maintain <object> instead (which itself is some borderline use case since maintaining something is not directly business relevant). You can constrain maintenance operations to certain actors separately.
Edit Regarding Login (one of my favorites): Use cases are most commonly used to describe business context (exactly as you are doing). So when looking from a business perspective, a Login is not a use case, but a simple constraint (you can do the business relevant things only when you are logged in).
Now for the Manage/Maintain use cases. They are on a similar level. Usually the "managing" itself is not directly business related. In many cases the focus on the real business was lost. So instead the reason why you manage something is the real use case (e.g. Correct User Data, Collect User Data). This is quite challenging and I confess that sometimes I also fall back to Manage. Most people don't bother but doing a good job requires to think over basics and not adopt bad habits.
suppose you have to do a Use Case Diagram for this simple problem (that is part of a much bigger exercise i am doing):
a registered user (of a web application) can search for tourist attractions in two ways: by category (for example: museums, parks, theaters, archaeological sites) or by location (city, county).
How should i model this UCD?
The most simple way would be: the actor (registered user), two use cases (search tourist attraction by category and search by location), the secondary actor (the server of the web application, which would process the query and send back the results).
My concern is that in this way the four categories and the two type of locations would not be present in the use case.
I was thinking of using the "extend" relationship. For example, i would add a use case named "Search parks" that extends the use case "Search by category". The extension point would be the event that the user chooses to search for parks.
Or i could use an inheritance relationship between the "Search by category" and "Search parks"...mmmm...i am a little confused...
How would you model this little problem using USD??
Thank you,
Luca
First of all you have to realize, that Use Case Diagrams aren't substitute for actual (written) Use Cases. Use Case descriptions contain many important details, which are omitted in Use Case diagrams. Use Case diagrams are good for depicting hierarchies of actors, associated use cases and relationships between use cases, but nothing more.
Another important thing is to realize what an use case actually is. Good way to think about them is to find a goal of an actor, which he/she wants to achieve with help from the system. Achieving this goal should give the actor some business value. My point is, that from what you described, registered user might want to search for a sightseeing and/or buy entry tickets. So this is his goal and this should be a an use case, don't confuse use cases with functionality/features like different ways of searching etc.
In your first suggestion you have two use cases, which differ only in data (e.g. it might be just different choice from a combo box in a form). Such differences, if they don't influence the way the system and actors interact, are described separately from the use cases in a data glossary, which you reference in your use case. This way you avoid many unnecessary details in use case descriptions. If on the other hand, the steps in the description change (e.g. when registečred user chooses location system gives him/her an option to select another registered user as a friend and pre-selects favourite locations of both or something like that...), you can capture this by using alternatives/extensions.
You mention the system you are developing as the secondary actor. Don't forget, the system under development is an implicit actor and is not shown diagrams as a separate actor. Use boundary box (rectangle encompassing use cases excluding actors) to depict scope of your system.
Finally to your concern. These are all just details about the data, which are not part of an use case. You can capture those details in text (by namicng all categories etc.) using the data glossary as mentioned above. If you think the structure and relations between data is important and needs to be captured using diagrams, you can use class diagrams to create data/domain models.
Last note about use case relationships - don't use them if you don't have to. They are often hard to understand and vaguely defined. Never ever use them to decompose the functionality, that is up to design, not analysis with use cases.
I hate depicting Search in a use case. There are simply too many variables. It's like trying to write a use case for using a browser.
Search is a good candidate for early prototyping supplemented with business rules.
I have an Access db I wrote that I've used for my checkbook and budgeting for the last 3 years. I've never written a program before, but I've decided to write the db into a stand alone program. My only experience, besides the simple VBA in the db itself, is an Intro to C++ class and an OO Logic class.
Even though I know what I want the program to do (because it's what my db does now) I want to approach the planning and design as properly as possible, so I can write the program as properly as possible, so that feature additions and maintenance are easier.
I need help planning. I guess UML diagrams should be first. What UML diagrams do I need to do? And in what order? I tried to do a use-case but since the program only involves me, my money, the bank, and the stores, it seemed pointless. Or was I thinking about it wrongly? Do I need to diagram my money and my budget inside my account? I don't know. I need help on how to proceed. Thanks.
It's good to have a set of UML diagrams to keep track of what is happening, but to remember in the end that documentation decays - your code is your design. That said, UML are good for planning and recalling bits and parts. There's a large dose of personal experience involved here, so feel free to take what you want and leave out what you think don't applies.
Use Case Diagrams
Skip this, and just write use cases instead.
Class Diagrams
I find them useful for planning the big picture view of an architecture, but I usually would leave out all the method names, or only leave in the relevant . I use it to illustrate the logical model of your classes
Sequence Diagrams
One of the more useful diagrams especially for business logic, and flow of data. I always find myself sketching sequence diagrams for complicated data-flow and especially when there are events being dispatched.
Object Diagrams
Shows the interaction of objects at run-time. I usually draw those for complex object interactions, and not the 'academically correct' ones. I think it is less useful than sequence diagrams.
Flow diagrams
Good for websites if you have complicate flow
State Transitions
Important if your application has many states. Again, just sketch out the most complex system, there is no need to have one for every sub-system.
ER Diagram
I know this is not UML, but a good database design upfront is important, and an ER diagram would help you to organise and plan how different tables relate with each other
Since your application is for personal use, I think you only really need two diagrams, maybe three. You can use a Use Case diagram if you want, but you will probably be better off with just a list of use cases. Since no one else has stated it, a use case is a requirement where you state something you're going to use it for. These help you define what features you need.
Next you need the class diagrams for how you're going to organize your program. A class diagram shows which classes you have and how they're connected. This is useful for figuring out if your program is too complicated or if you're using the antipattern known as the blob. If you have a lot of lines connecting classes to each other, you might want to reorganize to see if you can make each class more cohesive and if you see very few classes, you might want to check for a blob antipattern. An antipattern is a common occurrence which is bad for readability or maintainability. Class cohesiveness is defined by if each class has exactly what it needs. For example, if you decide to have a class for your account, it doesn't need to know information which isn't related to your account, like the street address or name of your bank.
The last UML diagram I think you'll need is a sequence diagram which shows how different objects in your program will interact. This will help you better understand the interactions your classes are doing and decide if you need to better organize them if they're getting too complex.
Those are the UML diagrams you might need. You might also want a network diagram to understand how your database is going to connect to the bank's website and get the information you need.
The diagrams are there just to make you understand what you are doing and keep you on track. I guess you already know that. In your case, i Believe a detailed use case will suffice, just to make sure you handle all the features and dont forget anything. (Reminder: Use case is not a diagram. it is text)