I am trying to come up with a use-case diagram for a social networking application. I have User as an actor.
I want to know how to represent the "People you may know" functionality through the use case diagram. This is not an action which the user can actually perform on the system, but which the system is providing the user. How do I represent such cases in my use case diagram.
There is no requirement for an Actor to be a person in usecase diagrams. It can be a system event such as a timer, watchdog or on going batch process. Have a system actor invoke the usecase "Show people you may know", which would hava a 'include' sterotype association with usecase e.g. "Show Messages" used by a Human user Actor.
Related
I am attempting to model account access in a graph DB.
The account can have multiple users and multiple features. A user can have access to many accounts. Each account can give access to only part of the features for each user.
One way I see it is to represent access for each user through relationship attributes, this allows having a shared feature node.
user_1 has access to account_1-feature_1 and account_2-feature-2. user_1 does not have access to account_1-feature_2 even though it is enabled for the account.
Another way to model the same access, but without relationship attribute is to create account specific feature nodes.
Question 1: which of these 2 ways is a more 'proper' modeling in the graph DB world?
Now to make things more interesting the account can also have parts which can be accessed by multiple accounts and a certain feature should be able to be scoped down to only be accessible for specific part by user.
In this example user_1 can access account_1 only for part_a feature_1.
To me it seems like defining an attribute on relationship is the way to go for being able to scope down user access by feature & by part of the account. However, reading neo4j powerpoints this would be one of the code smells of relationships having "Lots of attribute-like properties". Is there a better way to approach such problem in a graph?
I could be wrong here, but here are my thoughts. Option 1 definitely sounds the better way from a modeling perspective, however, I don't see how you can keep the data consistent without building heavy machinery to do it. For example, If someone deletes Account1.Feature1, and does not update the edge from User1 -> Account1, then you end up having stale RBAC rules in the system. You think you have access to something, but in reality that "thing" does not exist anymore. Option 2 may not seem very attractive from a data model perspective, but it does keep your data consistent. If you delete Account1.Feature1, the edge is automatically deleted in the same transaction.
The only con is that, you need to incur additional cost at insertion where you need to insert a lot more nodes than Option 1. For an RBAC system, I think its a fair compromise.
The same comment applies to the second half of your question as well.
I'm implementing an Alexa search skill for a website. My question is that there is some kind of possibilities to give intents some kind of scopes, so built in Intents could be reused?
I mean, for ex. the AMAZON.YestIntent to have different functionalities on different situations.
You can handle this in your intent handler. You can save context information in the session or a database if you are using one. Then in the intent handler, test the session or DB data to determine which response to take.
For example, in the Who's On First? Baseball Skit skill, the dialog between the user and Alexa is about 85 lines long. The user can say "who?" at several different places in the dialog, and Alexa needs to respond differently depending upon which line of the dialog they are at. To handle this, I simply save the line number in the session. Then when an intent is called, the intent handler gets the line number session variable, uses it to select the appropriate response, and increments it and passes it along in the session for the next line.
It really depends on the complexity of your skill, the accepted answer is a perfectly correct implementation for a simple flow and it starts to address keeping state tied to the session.
If your skill is more complex and you're using Node.js, I would suggest using the official SDK which offers this functionality out of the box:
https://github.com/alexa/alexa-skills-kit-sdk-for-nodejs
The state management allows you to define which intents should be handled in each state and the rest can be passed to a context-specific handler. More information is here:
https://github.com/alexa/alexa-skills-kit-sdk-for-nodejs#making-skill-state-management-simpler
The state management takes a little getting used to, but once you have used it, you won't go back because of the control it offers you over the experience.
I am implementing FHIR server and for some un-avoidable reason I do not have access to doctor's schedule, however, I have access to the slots available for appointment booking.
I can get slots from 4 parameters using
doctor id
organization id
location id
date of slot
Will below be considered as valid slot query using FHIR :
http://localhost:8080/context/fhir/Slot?practitioner=Practitioner/123456789&organization=Organization/1234&location=Location/2&start=2016-07-25
Also, in the response to above query, since reference to Schedule is absolutely necessary (Slot has card=1..1 for Schedule reference), can I pass reference value as something like :
"schedule": {
"reference": "Schedule/notrequired"
}
in Slot response ?
Unfortunately, right now, you do have to expose a Schedule, but there isn't any reason it has to be "real". The way we have currently implemented Slot searching is by exposing a dummy Schedule with the only data element being the link to the actor. For example:
<Schedule xmlns="http://hl7.org/fhir">
<id value="1234" />
<actor>
<display value="Cooper Thompson, MD" />
<reference value="http://host/api/FHIR/DSTU2/Practitioner/1234" />
</actor>
Our Slot search ends up looking like this (with some edits for brevity and clarity, specifically around the slottype):
http://host/api/FHIR/DSTU2/Slot?Schedule.actor:Practitioner=1234&Schedule.actor:Patient=5678&slottype=urn:oid:1.2.3|Cardiology&start=2016-07-21
Note that this is technically invalid, as a Slot can only have one Schedule, and we are including multiple chained search parameters for Schedule. We also make use of extensions to send back the patient, practitioner, and location associated with the slot, since Slot.schedule is 1:1. However this "intentional misuse" is the best option I've found without forcing the client to become the scheduling system and deal with lining up slots for each resource.
There are some tracker items (9989, 9208) in the FHIR gforge about making updates to Slot to be more friendly to "simple clients". We'd appreciate your input :).
I might be missing something here, but not sure how you are defining the difference between the slot and schedule?
The Schedule resource simply defines a period of time that slots may exist within, and for which other resource. It does not define or expose the appointments that may exist during this time.
The slot search parameters do not define any search parameters as you've implied. These are all on the schedule resource that it links from.
A Practitioner, Location and Patient can each have their own schedule/slots and thus it depends on the system where the complexity is defined.
Some systems decide that they are only going to worry about practitioners (who have their own room), others only worry about the room and will allocate practitioners later.
From my understanding of what I think you're trying to so (creating a FHIR Façade in front of a practice management system) I think you will need to expose the following resources:
Practitioner: To expose the details of the practitioner (interested if your practitioners can work in multiple locations)
Schedule: To simply expose the date range that you are accepting appointments (and will have slot availability defined) and the practitioner is linked to this resource, if they work at multiple locations, you'll have one of these for each location the practitioner works. (If the location resources have their own schedule, then will need to further consider it, and where the negotiation for available slots is done)
Slot: To define the available slots that appointments could be scheduled into. (note: these are not appointments)
Appointment: To receive the created appointments (Not sure how you're going to handle this if you don't have access to the schedule)
Patient: Assuming that you want to assign patients to the appointments ;)
If this all makes sense and you clarify your environment, I'll put in the likely queries that you'll need to handle.
This was a great question, and Patient Administration is planning to write some implementation guidance on implementing this functionality in the various environments (General Practice, inpatient, outpatient, community, lab, etc.)
Can I customize the BPF in the following ways?
Initiate the BPF process instance based on criteria?
I.E. Can I initiate a BPF process instance for Opportunities that belong to a certain team, not apply the BPF to all opportunities?
Customize the BPF ribbon button?
I.E. Disable the 'Back button' on the BPF Ribbon?
Thanks in advance
Accept that this is a generic response for your question, appreciate if you could post specifically what do you meant by criteria and customize.
BPF do not actually run as system jobs (Initiate) in the way that workflows and dialogs do. Instead they provide a means of data entry and enforce a set of rules when a user interacts with record through a form. They cannot have any branching or conditional logic beyond required field steps to prevent the user from progressing without completing necessary information.
May be what you need can be achieved by combining different CRM features together like, Field Security, Business Rules and Workflows.
I am writing a score submission system for games where I need to ensure that reports back to the server are not falsified (aka, hacked).
I know that I can store a password or private passkey in the program to authenticate or encrypt the request but if the program is decompiled, a crafty hacker can extract the password/passkey and use it to falsify reports.
Does a perfect solution exist?
Thanks in advance.
No. All you can do is make it difficult for cheaters.
You don't say what environment you're running on, but it sounds like you're trying to solve a code authentication problem*: knowing that the code that is executing is actually what you think it is. This is a problem that has plagued online games forever and does not have a good solution.
Common ways in which such systems are commonly broken:
Capture, modification and replay of submissions to the server
Modifying the binary to allow cheating
Using a debugger to modify the submission in-memory before the program applies signatures/encryption/whatever
Punkbuster is an example of a system which attempts to solve some of these problems: http://en.wikipedia.org/wiki/PunkBuster
Also consider http://en.wikipedia.org/wiki/Cheating_in_online_games
Chances are, this is probably too hard for your game. Hiding a public key in your binary and signing everything that leaves it will probably put you well ahead of the pack, security-wise.
* Apologies, I don't actually remember what the formal name for this is. I keep thinking "running code authentication", but Google comes up with nothing for the term.
There is one thing you can do - record all of the user inputs and send those to the server as part of the submission. The server can then replay the inputs through a local copy of the game engine to determine the score. Obviously this isn't appropriate for every type of game, though. Depending on the game, you may need to include replay protection.
Another method that may be appropriate for some types of games is to include a video recording of the high-scoring play within the submission. Provide links to the videos from the high score table, along with a link to report suspicious entries. This will let you "crowd-source" cheat detection - if a cheater's score hits the table at number 1, then the players behind scores 2 through 10 have a pretty big incentive to validate the video for you. If a score is reported enough times, you can check the video yourself and decide if it should be removed (and the user banned).