hello, my first question is how I can place cases to better readability? I want to make this diagram fit on a A4-sized paper.
But I am aware that this diagram may be badly made, so I ask you to advice, maybe I should share on the smaller part?
You need to to connect a use case only to its primary actor. So eventually you have to create a common role where the UC is used by this common actor role. Then your specific actors inherit from this common one. Like in #Amir's example International Student inherits from Student.
I'd simply up-vote the latter example but it has <<include>>/<<extend>> which is no favorable with use case synthesis. Moreover it uses a generalization which is very bad practice with UCs since a UC represent an individual added value and inheritance from added value does not make sense (unlike in a class context).
I don't understood your language (In your use-cases). Generally most of time we have some common feature so You can use inheritance in UML diagram. For example if you have different kinds of students (or Actors) that have some common feature you can do something like below picture:
I think there is too many of use cases. I had the same problem. Try using CRUD - https://books.google.co.uk/books?id=gKHfVZn1CkgC&pg=PA367&lpg=PA367&dq=crud+use+cases&source=bl&ots=g7C2qnzunP&sig=F3OtpNWT29NFyqFvmO-MBtTG98k&hl=en&sa=X&ved=0ahUKEwjAmKifh9_OAhWpCsAKHV9pA344ChDoAQg4MAU#v=onepage&q&f=false
Also, you can divide your diagram into few use case diagrams for each actor. Or put all actors on the one side of the diagram and use cases on other. Hope this helps.
I completely agree with the given suggestions (CRUD, inheritance and responsibility by roles) and I additionally recommend not to try to create an overview about the whole universe. Instead, try to separate your use cases into groups based on similarities, differences etc. and explain your modeling on smaller pieces.
Avoid too complex structures and mutual/cyclic dependencies - they are almost always a sign of poor design. Remember, you have to implement and test every connection in your diagram somehow. Less connections, less effort, less errors.
Related
I have a question about uml and extend notation of use-case.
How I can extend all use case.
For example if I created a connection down use case that extend almost all use case, but I don't want to connect all with the notation on the use case diagram cause is very orrible to see. How can I do?
First of all: the importance of Use Cases
Modeling Use Case Diagrams (Use Case Modeling) is SO important step in Software Analysis and Use Case Modeling should be performed by professional Analysts:
All estimations (Time, Budget, Resources and etc.) are performed based an Use Cases.
In some Use Case Driven Methodologies, all subsequent steps are based on Use Cases.
and etc.
Secondly: Knowing Use Case Modeling Traps.
In Use Case Modeling there are some traps that we need to conside related to your question:
(Trap #1: Use cases that users don't understand.) (see reference 1)
Use cases are a way to represent user requirements, which describe
what the user needs to be able to do with the product. Use cases
should focus on tasks a user needs to accomplish with the help of the
system, so they should relate to the user's business processes.
Your users should be able to read and review use cases to find
possible problems, such as missing alternative flows or incorrectly
handled exceptions. If users cannot relate to use cases, there's a
problem. Perhaps they're written too much from a technical, rather
than business, perspective.
(Trap #4: Describing specific user interface elements and actions) (see reference 1)
Write "essential" use cases that describe the interactions between the
user and the system at an abstract level, without incorporating
user interface specifics. The use case description should not include
a screen design, although simple user interface prototypes can be
valuable to facilitate the use case exploration.
(2. Not having clear business goals for every use case) (see reference 2)
(6. Specifying use cases in too much detail) (see reference 2)
Thirdly: Use Case Modeling is in the Requirement phage of methodologies.
We should not put common implementation methods in Use Cases. Common methods in implementation handled by other diagrams in next steps of methodology. (maybe in Design Model) So, if we put all common methods in Use Case Model, the number of use cases increases a lot. (and our estimation as mentioned in first part goes wrong)
You can't - and it's nonsense. A use case shows added value for an actor. Extensions to use cases are very rare. In most cases people try to apply functional decomposition and mistake a step of actions recurring in multiple use cases as "partial" use cases. They aren't! If you are trying to do what you describe you went the wrong path. You should instead think why and where your use case synthesis broke.
I strongly recommend reading Bittner/Spence to get the right idea what use cases are all about.
You can use use inheritance.
Something like this, use cases B and C are extended since this is inherited.
But as #Kilian said, it would be interesting that you explain why you need a such model.
Is the diagram correct? Can more use cases be added in this diagram? Is there a need for include and extend functionalities?
The diagrams look ok and you can add more use cases at your wish. But for clarity sake it's advisable to split them into sub-domains where you can focus on a couple of somehow related use cases. Do this by creating different diagrams or using boundaries to split the sub-domains.
Avoid <<include>> and <<extend>>. Use cases undergo a synthesis an not an analysis. There are only very rare cases where one could use those relations in a useful way.
Can more use cases be added in this diagram?
This should not be your goal, therefore I daresay you don't want to ask this question. At least not anyone!
Instead, try to model the fewest possible UML entities without losing valuable information. Simplifying and splitting up diagrams into simpler parts is often way more challenging than modeling new entities.
The question is: Which information is required? You'll need to work that out with your stakeholders. Remember: YAGNI.
Firstly, I'm still quite new to UML; but, highly interested and am attempting to learn as much about it as I can.
With that said, I’m in a situation where I’m directed to assemble a ‘Context Diagram’. I feel as though I understand the concept of what a context diagram is and how to create one, so I think I’m ok there. Basically it is identifying the system and the components or actors it will interact with. It applies the focus on the system, and not the actors. Kind of like a Use case diagram, but not focusing on the actors. If I’m wrong, please tell me.
I read somewhere that Context Diagrams are not actually part of UML. I also read, somewhere, that, if you use a Context Diagram, it falls into the Component side of things. When I read about Domain models, it seems like it should be there.
For my current situation, I know a simple answer is to simply create the diagram and move on, as that is all that is required. But, for my interest to better understand and leverage UML, I know there is a right way and a wrong way. If I were in a case of a bigger project, what would be the right way?
Now here is where my question begins. I’m using Enterprise Architect, create my project, and start to create a model. Does it belong in a Domain Model or Component Model? What is the difference between these two? Or even more. As it is an aide to help identify requirements, should it go there? Or does is just simply depend on what and how I want to convey it?
The Domain Model is where you standardize the vocabulary that everyone on the project will use to communicate in a consistent manner. The development team are experts at software development, but they may not have any experience in the domain (e.g. banking, air traffic control, healthcare) in which they are being asked to work. So you get domain experts and modelling experts together to build a model that describes the domain, answering important questions like "how are account fees calculated?" and "how does a pilot know what route to follow?" and then this model is then passed to the development team to provide them with the important domain knowledge that they will need. I would use UML class diagrams to create a domain model.
A Context Diagram shows the system being modeled in relationship to external systems. It could show data flowing in from and out to external systems, modeled by a data flow diagram (not part of UML). It could show behavioral interactions between the system and external "actors", modeled by a UML use case diagram. It could show the system's physical connections to other systems, modeled by a SysML block diagram. Whichever you choose, it will be on page 1 of your design document, so choose wisely!
You (can) create context diagram by making any element composite. Then drag the element itself onto that diagram as link (not instance!) and highlight it by making the border a bit thicker. Finally insert related elements from the context menu (differs from EA version to version). Layout the diagram and now you have your element in the context.
A domain model is usually a class diagram showing the (business) domain on a higher abstraction level.
As you have said, Context Diagrams per se are not part of the UML spec. There are plenty of ways to do a context diagram, but the UML way is to use a Use Case diagram, with or without supporting narratives and scenarios. Start with this, which is a broad overview of different types of Context Diagrams. Then, investigate use case diagrams, use case narratives, and activity diagrams. If you need to go into more detail than a use case narrative can easily do, get into use case scenarios and sequence diagrams. Here is a pretty good use case narrative template (feel free to leave out sections such as "scope and level" if they are more than you need, and consider adding information about what triggers the use case and where you go when you finish it--these two are required for scenarios if you go that far).
Keep in mind that use case narratives and use case scenarios are often confused. (Some people will say that I am the confused one; I will invite you to judge the matter for yourself.) A narrative is an explanation of an entire (single) use case, and may be supported with an activity diagram. A scenario is an explanation of a single path through a single use case, and may be supported with a sequence diagram.
For example, a use case will generally have a basic flow of events, along with a number of alternate flows. The narrative describes the entire process. The basic flow and each alternate flow would each be a separate use case scenario.
I suspect that it's unlikely that you will have to get down to the level of use case scenarios. You will probably want to put a use case diagram together, and possibly prepare narratives and activity diagrams for each of the use cases in the diagram.
i've been created the following diagram for forums system but i'm not sure if the relation between use cases and actors is correct.
so i want to know if my diagram is correct or if i've added too much complexity to my diagram. did i got my use cases relation with the actors correctly? well to better say, is it correct at all?
any help is really appreciated.
Not a bad effort for a first attempt, but I'd say it is a bit over complex. When you do analysis, using use cases or some other method, you really do want to keep it simple and avoid going into design mode, which is when you start thinking about relationships between things.
In my opinion, your actors should not be generalizations of one another. A "person who posts" on a forum is not a a more specific type of a "person who reads posts": they are different roles which the same person might take on at different times, not expansions on one another. So I'd advise you to drop those generalizations.
The same goes for the use cases themselves. Normally, use cases relate to one another by way of either the <<extend>> or <<include>> relationship, but generalizations or not normally used. Use cases aren't like classes and don't really have the option of being abstract, so the "manage" use cases need to make sense on their own, and they don't really do that. Your "concrete" use cases, on the other hand, make perfect sense.
In order to group related use cases together, it's a better idea to use separate diagrams and / or gather the use cases into packages called "post management", "site administration", etc. There is nothing which says you have to put all your use cases into a single diagram.
I support your method of use case diagrams. I struggled with this very issue a while back. To show each association from one use case to each of the actors was getting messy. By generalizing the actors, it consolidated the associations into a nice, easily readable format. Thus, the information is easier for others to consume.
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)