The following image describe my Quiz System
the teacher will login to a website and create a quiz and enter its question and the probable answers,
then the student will use their phone to login and chose the teacher and select the required quiz,then answer the questions and view the results at the end on the phone,in addition the teacher can view the quiz results on the website.
does the following Use case describe what I have just said??!.
From student perspective:
1- should the login use case to be the base case and all other use cases will be added as include
2- should I have a "Do the Quiz" use case or just directly associate the other use cases to the student
3-should the "View Quiz Results" be associated as include to "Do the Quiz"
From teacher perspective
I have the same question for teacher actor which use cases should be associated as include and which should be associated directly to the actor and which should be associated as extend.
Here's a few questions to ask yourself:
Is the Admin required to log in?
Could Prepare Quiz Information be replaced by Create New Quiz?
Likewise, could Do The Quiz be replaced by Choose The Quiz?
What does the line between Teacher and Admin represent?
Also see What's is the difference between include and extend in use case diagram?
which says
Extend is used when a use case conditionally adds steps to another
first class use case.
For example, imagine "Withdraw Cash" is a use case of an ATM machine.
"Assess Fee" would extend Withdraw Cash and describe the conditional
"extension point" that is instantiated when the ATM user doesn't bank
at the ATM's owning institution. Notice that the basic "Withdraw Cash"
use case stands on its own, without the extension.
Include is used to extract use case fragments that are duplicated in
multiple use cases. The included use case cannot stand alone and the
original use case is not complete without the included one. This
should be used sparingly an only in cases where the duplication is
significant and exists by design (rather than by coincidence).
For example, the flow of events that occurs at the beginning of every
ATM use case (when the user puts in their ATM card, enters their PIN,
and is shown the main menu) would be a good candidate for an include.
To answer your questions:
should the login use case to be the base case and all other use cases will be added as include
From my experience, no.
should I have a "Do the Quiz" use case or just directly associate the other use cases to the student
I would directly associate Student with Choose The Quiz, but it is highly subjective.
should the "View Quiz Results" be associated as include to "Do the Quiz"
No, the included use case should not be able to stand alone but in your example it clearly can. See the definition of include and extends in the previous link.
Related
I'm still learning Codeigniter/PHP/Database/SQL.
Whenever i encounter new problems, i usually learn something to solve them that may/may not apply to my previous methods.
If they do apply to previous methods or if i make changes to my database design, i usually have to edit/update my CRUD methods relevant to the tables changed.
The problem lay there, since i write my methods as i need them and i don't follow any plan so they're all over the place.
It's not that its not solveable but its very hassle and it just saps away any anticipation i had towards improving my codes then i end up just doing other stuff(procrastinating), its a very vicious cycle, whenever i try to get into it, i end up procrastinating then days pass by then weeks.
I also want to implement thin controller/fat model idea ive read online. Up to now, this is also a part of the problem. I'm trying to solve them all right now but i have a question/doubt before i can truly do it.
I separated my controller into two. 1. needs authentication 2. no authentication.
For now, i have my main controller with methods that needs a user logged in.
for example, user/story dashboard, submitting stories. etc.
The other one is my pages controller, i put there the methods that don't need any user authentication. Like viewing homepage, viewing story profile, reading a chapter, viewing user profile. etc.
In my models, i have separated them into two. account_model and story_model. Any method related to account like registration,logging in etc. and story like publishing story,fetching story data, etc.
My problem with that is that there are some methods that fall into a gray area. or some methods that i would like to group but get separated.
For example: I have a review system(my previous question), users can review other users(author) who have published their stories, stories and chapters.
In my models, the review_author method would go into account model, the review_story and review_chapter would go into story model.
Is it correct for me to just make a review_model and put them all there?
In line of that thought, can i also make separate models for separate groups of methods for example, Pagination model for any method related to pagination(user/story). dashboard model for any method related to my user/story dashboard.
The essence of my question is that i want to be as efficient as possible(of my level of knowledge) so that whenever i get far into my project i don't lose enthusiasm if i have to make changes because of the headache inducing wall of codes.
Is it possible to extend a use case multiple times in a Use-CaseDiagram?
I have 2 Actors with their own 'Show post table' use cases.
These 2 cases both have a Create, Edit, delete use-cases.
Can I extend these use-cases for both 'Show post table' use cases? Or should I create 2 use-cases for create, edit and delete, and then extend them each to one of the use cases?
See following picture for a better explanation:
Use Case Diagram:
Also, is it correct to include the login use case? (As the red arrows shows)
Formally you can do that - if your intention is correct.
Practically people use include and extend for functional analysis during use case synthesis. And that is a wrong use. So the best advice is to keeps hands off both links.
N.B.: Your use cases lists Login. But obviously you are on a business level. And Login is no use case on that level. Rather it is a constraint you want to apply to other use cases. A use case isn't one if it does not add value to its actor. Logout of course the same.
Yes, that's absolutely correct to extend UC more than once as well as extend more than one UC with the same UC.
What is important is to properly define what UC is (end thus find real UCs). Remember that each UC should have a business purpose. What is the purpose of showing the table? Isn't it only a sort of starting/ending point for each of your Use Cases? It'll probably be just a behaviour that will be invoked during UC realization.
Yet you can have for example use cases like "Create Client", "Update Client" that both extends "Place Order" (you create client if a new one is ordering and you update it when you just provide a new address for an already existing Client - both at the Order placing).
I'm working on my pet project where I have the following scenario:
user can create article and becomes its owner
only article owner can edit given article
I wonder how to model it correctly. I don't want to have dumb objects like User and Article that only have properties, but would like them to have some behavior. This is how I'd approach it initially:
article = articles_repository.find(id)
if(article.changeable_by(user))
article.change(title, content)
articles_repository.save(article)
else
raise NoEditRights
end
My only concern here is that I need to check if user can modify before I do modifications. I
Another approach was to pass current user to change method and let article check it and raise error if user is not allowed to change it.
I was also thinking about something like this:
article = articles_repository.find(id)
article.as_user(user) do
article.change(title, content)
articles_repository.save(article)
end
but I don't know if it is any better.
How would you approach such case? How to internally prevent article from being changed by other users I know it is quite simple, but I'd like to grasp how to model such cases before I jump into something more difficult.
EDIT: some more info added
So this is content publishing application, users can write and publish articles, others can read them and comment on them.
This is really simple app (just a toy project) and I can see the following bounded contexts here:
publishing article
editing article
some others that are not important I guess (like comment on article)
I'm not sure if I should introduce different models for each context?
These are not bounded context, but some use cases.
From what you say I guess there will be 2 bounded contexts: publishing and access management. Access management - unless you're willing to introduce some unordinary mechanisms - is a generic concern that probably don't require your focus and DDD - just add some good library that solves this problem already. And maybe wrap it with some application service.
So in some app service there would be a method doing something like (pseudocode, sorry, I don't know Ruby):
var user = auth::authenticationService.getUser(...)
if user.hasAccessTo(articleId) then
var article = pub::articleRepo.get(articleId)
article.doSomething()
end
Note that authentication service and user belongs to one context (auth) and article and article repo to another (pub). There is only a small connection between them. User don't know anything about articles in pub context (it's just a value object storing the id) and article doesn't know anything about access management (but probably has a value object of user that contains his name).
Another way would introduce some tiny objects in pub context like Author, Editor, Commenter representing the roles over the article.
var role = pub::roleService.getAuthorFor(articleId, userId)
if role != null then
role.doSomethingWithArticle()
end
where roleService acts as an anticorruption layer between auth and pub (so it calls a authenticationService, gets user object full of auth-specific stuff and based on it, construct a lightweight role object that contains only pub-specific behavior.
The second example sounds heavier but it's more prone to changes in one of the contexts.
First, Please bear with me with all my questions. I have never used TDD before but more and more I come to realize that I should. I have read a lot of posts and how to guides on TDD but some things are still not clear. Most example used for demonstration are either math calculation or some other simple operations. I also started reading Roy Osherove's book about TDD. Here are some questions I have:
If you have an object in your solution, for instance an Account class, what is the benefit of testing setting a property on it, for example an account name, then you Assert that whatever you set is right. Would this ever fail?
Another example, an account balance, you create an object with balance 300 then you assert that the balance is actually 300. How would that ever fail? What would I be testing here? I can see testing a subtraction operation with different input parameters would be more of a good test.
What should I actually test my objects for? methods or properties? sometime you also have objects as service in an infrastructure layer. In the case of methods, if you have a three tier app and the business layer is calling the data layer for some data. What gets tested in that case? the parameters? the data object not being null? what about in the case of services?
Then on to my question regarding real life project, if you have a green project and you want to start it with TDD. What do you start with first? do you divide your project into features then tdd each one or do you actually pick arbitrarily and you go from there.
For example, I have a new project and it requires a login capability. Do I start with creating User tests or Account tests or Login tests. Which one I start with first? What do I test in that class first?
Let's say I decide to create a User class that has a username and password and some other properties. I'm supposed to create the test first, fix all build error, run the test for it to fail then fix again to get a green light then refactor. So what are the first tests I should create on that class? For example, is it:
Username_Length_Greater_Than_6
Username_Length_Less_Than_12
Password_Complexity
If you assert that length is greater than 6, how is that testing the code? do we test that we throw an error if it's less than 6?
I am sorry if I was repetitive with my questions. I'm just trying to get started with TDD and I have not been able to have a mindset change. Thank you and hopefully someone can help me determine what am I missing here. By the way, does anyone know of any discussion groups or chats regarding TDD that I can join?
Have a look at low-level BDD. This post by Dan North introduces it quite well.
Rather than testing properties, think about the behavior you're looking for. For instance:
Account Behavior:
should allow a user to choose the account name
should allow funds to be added to the account
User Registration Behavior:
should ensure that all usernames are between 6 and 12 characters
should ask the password checker if the password is complex enough <-- you'd use a mock here
These would then become tests for each class, with the "should" becoming the test name. Each test is an example of how the class can be used valuably. Instead of testing methods and properties, you're showing someone else (or your future self) why the class is valuable and how to change it safely.
We also do something in BDD called "outside-in". So start with the GUI (or normally the controller / presenter, since we don't often unit-test the GUI).
You already know how the GUI will use the controller. Now write an example of that. You'll probably have more than one aspect of behavior, so write more examples until the controller works. The controller will have a number of collaborating classes that you haven't written yet, so mock those out - just dependency inject them via an interface. You can write them later.
When you've finished with the controller, replace the next thing you've mocked out in the real system by real code, and test-drive that. Oh, and don't bother mocking out domain objects (like Account) - it'll be a pain in the neck - but do inject any complex behavior into them and mock that out instead.
This way, you're always writing the interface that you wish you had - something that's easy to use - for every class. You're describing the behavior of that class and providing some examples of how to use it. You're making it safe and easy to change, and the appropriate design will emerge (feel free to be guided by patterns, thoughtful common sense and experience).
BTW, with Login, I tend to work out what the user wants to log in for, then code that first. Add Login later - it's usually not very risky and doesn't change much once it's written, so you may not even need to unit-test it. Up to you.
Test until fear is replaced by boredom. Property accessors and constructors are high cost to benefit to write tests against. I usually test them indirectly as part of some other (higher) test.
For a new project, I'd recommend looking at ATDD. Find a user-story that you want to pick first (based on user value). Write an acceptance test that should pass when the user story is done. Now drill down into the types that you'd need to get the AT to pass -- using TDD. The acceptance test will tell you which objects and what behaviors are required. You then implement them one at a time using TDD. When all your tests (incl your acc. test) pass - you pick up the next user story and repeat.
Let's say you pick 'Create user' as your first story. Then you write examples of how that should work. Turn them into automated acceptance tests.
create valid user -> account should be created
create invalid user ( diff combinations that show what is invalid ) -> account shouldn't be created, helpful error shown to the user
AccountsVM.CreateUser(username, password)
AccountsVM.HasUser(username)
AccountsVM.ErrorMessage
The test would show that you need the above. You then go test-drive them them out.
Don't test what is too simple to break.
getters and setters are too simple to be broken, so said, the code is so simple that an error can not happen.
you test the public methods and assert the response is as expected. If the method return void you have to test "collateral consequences" (sometimes is not easy, eg to test a email was sent). When this happens you can use mocks to test not the response but how the method executes (you ask the mockk if the Class Under Test called him the desired way)
I start doing Katas to learn the basics: JUnit and TestNG; then Harmcrest; then read EasyMock or Mockito documentation.
Look for katas at github, or here
http://codekata.pragprog.com
http://codingdojo.org/
The first test should be the easiest one! Maybe one that just force you to create the CUT (class under test)
But again, try katas!
http://codingdojo.org/cgi-bin/wiki.pl?KataFizzBuzz
I am writing a document in which I am proposing that our web application have both wizard-style user interfaces, and normal user interfaces.
To my mind, a normal interface in one in which you can browse a list of domain objects, and then view or operate on them as you please. This style of interface is good for creative, non-directed, interaction with the data a program manages.
A wizard interface, on the other hand, is a task oriented interface in which you first choose what you want to accomplish, and are then guided through it.
What I need to know, is what is the accepted term to describe a normal, non-wizard, user interface?
Edit: I went with "overview style user interface", but I also liked the answer "Non-linear user flow" to describe the type of interaction.
Perhaps the most widely known terms are function-oriented UI and object-oriented UI, where a wizard is a type of a function-oriented, and “normal” GUIs are object-oriented. Personally, I think these terms have been poorly defined, being simultaneously too broad and too narrow. They are also easy to confuse with implementation language.
I have suggested:
Task-centered user interface structure, where each window represents a task, or, if the task is complex, a step in the task. The layout in the window and navigation links between windows represents the task structure –what steps follow what and how tasks can branch and loop. Along with wizards, Microsoft’s Inductive User Interface and many form-type web application user interfaces use task-centered user interface structures.
Object-centered user interface structure, where each window represents one or more object classes, and the layout in the window and navigation links between windows represents the data model –how one class relates to another. For the most part, this is the type of structure used in general-purpose office software, where there’s only one class represented, typically some kind of document. If your application is a collection of record lists, master-detail forms, and/or “properties” windows that the user can “drill down” through, you’re probably making an object-centered structure.
You provide a good summary of the main advantage of object-centered structures. I’ve more on the pros and cons of each, plus methods and issues on combining them in the same app at http://www.zuschlogin.com/?p=3.
I guess the complete opposite is one long form, with all fields and options that your application supports. Mind you, you could still show that intelligently, by using the right header and collapse/expand behavior.
"Expert"
"Advanced"
"Detailed"
"Witch.".
Seriously speaking, the answer to your Q depends on the target audience.
If it is internal (designers/developer), "non-wizard" seems to be a commonly accepted term.
If it's end users, either use "non-wizard" or "advanced/expert"
Web Applications tend to be "form based". Thus IMHO the application either has "Standard Forms" based interface, or a "Wizard Forms" based interface.
A normal interface = "Standard Interface"
Opposite of wizard = "Non-Linear User Flow"
What about single-page vs. multi-page?