As the title says I have problems creating a simple use case diagram for the game Hangman. The rules are simple, the computer generates a word, it gives you the length and the first and last letter, and you have 9 tries to guess the word. So far I've done this :Hangman Diagram
The problem is that this is my first diagram, and I think I didn't I put everything in order and the player is associated with more actions. Every suggestion will be greatly appreciated. Thank you in advance.
You have it very detailed.
Also there seam to be misunderstanding of Actors definition. Quote:
Actors. An actor is a person, organization, or external system that
plays a role in one or more interactions with your system.
Your Computer actor is in fact internal system therefore should not be modeled as an actor.
Also for the use cases
A use case describes a sequence of actions that provide something of
measurable value to an actor.
The point here is about providing measurable value.
I suggest you to try to change it when you think more about these UML principles.
EDIT:
Nice UML example for game is here: http://xnagamedevelopment.blogspot.cz/2009/03/use-case-diagram.html
Interesting discussion on game industry vs uml is here: http://www.gamedev.net/topic/192120-uml-for-games/
That discussion might not help with your assignment, though.
Related
I've never made a use-case diagram before so I'm wondering if mine is correct or not.
In short
This is an (almost) valid use-case diagram. But this does not make make them good use-cases. But what matters in the end is if it is useful to you.
More details
Is it formally correct according to UML?
UML is value-agnostic and defines UC on page 637 of the specs (highlight by me):
A UseCase is a kind of BehavioredClassifier that represents a
declaration of a set of offered Behaviors. Each UseCase specifies some
behavior that a subject can perform in collaboration with one or more
Actors. UseCases define the offered Behaviors of the subject without
reference to its internal structure. These Behaviors, involving
interactions between the Actors and the subject, may result in changes
to the state of the subject and communications with its environment.
Let's check the validity of your UC in view of this definition:
Start game, move paddle, restart game, and exit game are behaviors that the game (subject) offers in collaboration with the player (actor). These are valid UC according to UML.
Ball falls, hit all bricks, hit brick, and display score are behaviors that are more questionable: they do not require a collaboration or an interaction with the player. You could nevertheless argue that these make sense only if the user observe these behaviors, so there is an interaction with the player. So it could be claimed that these are also valid UC in regard of the UML definition.
Add score seems to be a purely internal behavior that is done without the user and not even observed by the user. This would not be a valid UC. However labels might be misleading: if Display score would mean the final game-over score and Add score would mean an update of the score on the screen, it could again be argued that it's a valid UC.
The use of extension (optional) and inclusion (systematic) seem also correct.
Is it a good UC?
While UML is value-agnostic, many authors define a use-case in a more ambitiuous way. In particular Ivar Jacobson, the inventor of the Use case defines it as:
A use case is all the ways of using a system to achieve a particular
goal for a particular user. Taken together the set of all the use
cases gives you all of the useful ways to use the system, and
illustrates the value that it will provide.
According to this definition, there is only one single use case here:
Play a game : this is the goal of the user that brings him/her value.
All the other elements are only ways of using the system to achieve this goal. So they belong to the single use-case. A approach would be to represent them as detail of the use-case description:
One suitable way would be to show these in terms of intent in an essential use-case. This approach was invented by Constantine and Lockwood in 1999. It is used centered and leaves full flexibility about the sequence of actions in the user interface.
Another modern way is the Use-Case 2.0, invented by Ivar Jacobson in 2011. These detailes would be shown as use-case slices, in a very similar way than user-stories.
Im in a confusion on the sequence of drawing UML diagrams. I cannot understand where to start drawing them. Which diagram should come first if I have the scenario with me?
Start with Use Cases (and the related diagrams). Once Actors and Use Cases are identified, you can start designing a Class model. Create Collaborations realizing the Use Cases. Then inside show how the Instances of the Classes collaborate to actually realize what is needed for the Use Cases.
I recommend the ICONIX approach since that is what got me going a long time ago.
The other option is to start with Activity Diagram. I.e. make a business process analysis.
I always start with a problem-domain class diagram. (Some examples of what I mean are here and here.) Understanding the concepts in the domain and the relationships between them is extremely important. If you don't understand the problem domain, everything else will be confused and brittle, including business processes, requirements, use cases, and collaborations. Here is an example of an improper domain model, and here are the recommended corrections.
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.
Has anyone ever seen a sequence diagram used as a use case? I never have and it really twists my head. At my current company, in all the documentation and discussions, the term "use case" is used to label a sequence diagram. I've asked a couple of times about this practice and get funny looks like it is a normal thing to do. - I've been a software engineer for a long time and used UML since the late 1990's when it was first (fairly) widely talked about. I don't expect to change the company culture. I'm just asking if this practice is used anywhere else and associated comments. - Thanks.
In my university, we learned that a use case diagram and a sequence diagram are both different diagrams with different meanings. In my experience, I have never heard anyone calling a sequence diagram a use case diagram or vice versa so I guess it's just the company culture...
Sequence Diagrams are typically used to describe an example of an action flow with communication. Thus Sequence Diagrams are very well suited to display an example for a use case. For this reason it is normal to refer to such a diagram as "a use case".
In consequence you would draw multiple Sequence Diagrams for each Use Case
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)