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).
Related
I'm new to Redux-Saga, so please assume very shaky foundational knowledge.
In Redux, I am able to define an action and a subsequent reducer to handle that action. In my reducer, i can do just about whatever i want, such as 'delete all' of a specific state tree node, eg.
switch action.type
...
case 'DESTROY_ALL_ORDERS'
return {
...state,
orders: []
}
However, it seems to me (after reading the docs), that reducers are defined by Saga, and you have access to them in the form of certain given CRUD verb prefixes with invocation post fixes. E.g.
fetchStart, destroyStart
My instinct is to use destroyStart, but the method accepts a model instance, not a collection, i.e. it only can destroy a given resource instance (in my case, one Order).
TL;DR
Is there a destroyStart equivalent for a group of records at once?
If not, is there a way i can add custom behavior to the Saga created reducers?
What have a missed? Feel free to be as mean as you want, I have no idea what i'm doing but when you are done roasting me do me a favor and point me in the right direction.
EDIT:
To clarify, I'm not trying to delete records from my database. I only want to clear the Redux store of all 'Order' Records.
Two key bit's of knowledge were gained here.
My team is using a library called redux-api-resources which to some extent I was conflating with Saga. This library was created by a former employee, and adds about as much complexity as it removes. I would not recommend it. DestroyStart is provided by this library, and not specifically related to Saga. However the answer for anyone using this library (redux-api-resources) is no, there is no bulk destroy action.
Reducers are created by Saga, as pointed out in the above comments by #Chad S.. The mistake in my thinking was that I believed I should somehow crack open this reducer and fill it with complex logic. The 'Saga' way to do this is to put logic in your generator function, which is where you (can) define your control flow. I make no claim that this is best practice, only that this is how I managed to get my code working.
I know very little about Saga and Redux in general, so please take these answers with a grain of salt.
In our new project we decided to use hexagonal architecture. We decided to use repository pattern to gain more data access abstraction. We are using command bus pattern as service layer.
In our dashboard page we need a lot of data and because of that we should use 3 level many to many relations (user -> projects -> skills -> review) and also skills should be active(status=1).
The problem rises here, where should i put this?
$userRepository->getDashboardData($userId).
2.$userRepository->getUser($userId)->withProjects()->withActiveSkills()->withReviews();
3.$user = $userRepository->getById();
$projects = $projectRepository->getByUserId($user->id);
$skills = $skillRepository->getActiveSkillsByProjectsIds($projectIds);
In this case, I couldn't find the benefits of repository pattern except coding to interface which can be achived with model interfac.
I think solution 3 is prefect but it adds a lot of work.
You have to decide (for example) from an object-oriented perspective if a "User" returned is one that has a collection of skills within it. If so, your returned user will already have those objects.
In the case of using regular objects, try to avoid child entities unless it makes good sense. Like, for example.. The 'User' entity is responsible for ensuring that the child entities play by the business rules. Prefer to use a different repository to select the other types of entities based on whatever other criteria.
Talking about a "relationship" in this way makes me feel like you're using ActiveRecord because otherwise they'd just be child objects. The "relationship" exists in the relational database. It only creeps into your objects if you're mixing database record / object like with AR.
In the case of using ActiveRecord objects, you might consider having specific methods on the repository to load the correctly configured member objects. $members->allIncludingSkills() or something perhaps. This is because you have to solve for N+1 when returning multiple entities. Then, you need to use eager-loading for the result set and you don't want to use the same eager loading configuration for every request.. Therefore, you need a way to delineate configurations per request.. One way to do this is to call different methods on the repository for different requests.
However, for me.. I'd prefer not to have a bunch of objects with just.. infinite reach.. For example.. You can have a $member->posts[0]->author->posts[0]->author->posts[0]->author->posts[0].
I prefer to keep things as 'flat' as possible.
$member = $members->withId($id);
$posts = $posts->writtenBy($member->id);
Or something like that. (just typing off the top of my head).
Nobody likes tons of nested arrays and ActiveRecord can be abused to the point where its objects are essentially arrays with methods and the potential for infinite nesting. So, while it can be a convenient way to work with data. I would work to prevent abusing relationships as a concept and keep your structures as flat as possible.
It's not only very possible to code without ORM 'relationship' functionality.. It's often easier.. You can tell that this functionality adds a ton of trouble because of just how many features the ORM has to provide in order to try to mitigate the pain.
And really, what's the point? It just keeps you from having to use the ID of a specific Member to do the lookup? Maybe it's easier to loop over a ton of different things I guess?
Repositories are really only particularly useful in the ActiveRecord case if you want to be able to test your code in isolation. Otherwise, you can create scopes and whatnot using Laravel's built-in functionality to prevent the need for redundant (and consequently brittle) query logic everywhere.
It's also perfectly reasonable to create models that exist SPECIFICALLY for the UI. You can have more than one ActiveRecord model that uses the same database table, for example, that you use just for a specific user-interface use-case. Dashboard for example. If you have a new use-case.. You just create a new model.
This, to me.. Is core to designing systems. Asking ourselves.. Ok, when we have a new use-case what will we have to do? If the answer is, sure our architecture is such that we just do this and this and we don't really have to mess with the rest.. then great! Otherwise, the answer is probably more like.. I have no idea.. I guess modify everything and hope it works.
There's many ways to approach this stuff. But, I would propose to avoid using a lot of complex tooling in exchange for simpler approaches / solutions. Repository is a great way to abstract away data persistence to allow for testing in isolation. If you want to test in isolation, use it. But, I'm not sure that I'm sold much on how ORM relationships work with an object model.
For example, do we have some massive Member object that contains the following?
All comments ever left by that member
All skills the member has
All recommendations that the member has made
All friend invites the member has sent
All friends that the member has established
I don't like the idea of these massive objects that are designed to just be containers for absolutely everything. I prefer to break objects into bits that are specifically designed for use-cases.
But, I'm rambling. In short..
Don't abuse ORM relationship functionality.
It's better to have multiple small objects that are specifically designed for a use-case than a few large ones that do everything.
Just my 2 cents.
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.
I have a form with inputs that do not really belong inside any model. Things like "confirm password" and "I accept these conditions" etc.
What is the best practice for situations such as this?
I thought about the following possibilities:
Create a temporary model inside the controller action with validation rules.
Create a separate model for these inputs.
Some other feature in cake 2.x specifically for this situation?
I've read many answer posts about this but either the answer is for v1.x of cake and might be outdated, or people propose to put all that stuff inside the model with the closest relationship to the current controller. So what is the best practice?
Thanks!
I use behaviors for that.
Password add/edit:
https://github.com/dereuromark/tools/blob/master/src/Model/Behavior/PasswordableBehavior.php
( see https://www.dereuromark.de/2011/08/25/working-with-passwords-in-cakephp/ )
Accept Conditions:
https://github.com/dereuromark/tools/blob/master/src/Model/Behavior/ConfirmableBehavior.php
( see https://www.dereuromark.de/2011/07/05/introducing-two-cakephp-behaviors/ )
This allows me a DRY approach without having to repeat it all over again in the different models where I use them. I just add them dynamically ($this->Behaviors->load()) or via $actsAs and can use the extended functionality (similar to Traits in PHP5.4).
You could put your password validate stuff into the APP user model for a single app. But as soon as you are maintaining multiple apps the code would have to be duplicate at some point. That's why I prefer the behaviorable approach.
But it is neither impossible nor impractible for some situations to just drop the validation in the respective models.
Just don't create temporary models or something. That usually is the wrong way to go.
If I need two modes in my application what design pattern would I use so I can prevent ugly conditional code? App is currently MVC, but I don't want conditional code in my controllers and don't want two controllers for each view unless I have to.
Any suggestions?
A different subclass for each implementation, with shared functionality either in a common superclass or using the Template Method pattern.
Perhaps the State Pattern?
Abstract Factory, or Proxy. Your controller would contain some kind of Factory or Proxy instance that is used to retrieve a "mode" and act on it accordingly.
It is difficult to say for sure without more information, but I would suggest the strategy pattern. You could use the same controller and just swap out the strategy object to produce the desired change in behavior.
Here is an article you may find useful:
http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html
take a look at JSR-168, java portlet and its reference implementation, it should be similar to what you are trying to achieve.
The appropriate place for such a decision is the controller of MVC. I would recommend you write it there first. If it really is repetitive, it may be straightforward to figure out how to clean it up: you can move the conditional logic into a base class, or depending on the language, may be able to handle it with some sort of filter. You may also be able to create some "factory" for the views, which understands the "mode" of your application. Architecturally, though, all this is in the controller.
You are right to not want it in the view. This would be pretty messy. You probably want two versions of the views, one for "view" and one for "edit".
In the end, this is what controllers are for. Good luck!
In CafeTownsend demo made with PureMVC there is a similar situation where there are two different views and two separate Mediators. You absolute don't need conditional code for that. I don't know what technology and programming language you are using, but in Flex it will be a ViewStack with the ListView and EditView as children:
Corresponding mediator is registered by demand when the view is created. You can check other implementations using previous link.