I'm a beginner in Alloy. This is my first model using Alloy Analyzer. I'm now building a generic model for Travel in Alloy. In this model, a user (I use sig Request in this model) can make a request for 'accommodation' (includes 'hotel' or 'apartment' or 'hostel'); 'flight'; or 'tour', (the request can be either one of them or any combination of them, for example hotel and tour). Each of them is subset of 'resource'. For now, I stick the request for one destination only, and check-in & check-out date for accommodation as well as inbound-date & outbound-date for flight must be the same as begin-date & end-date for user request.
My questions as follows:
Firstly, in order to ensure check-in, check-out, inbound, and outbound date are the same as as begin-date & end-date for user request, all of them is mapped to beginning_of_journey and end_of_journey (please see the codes). Is this the correct way?
Secondly, I have a problem on how to code the constraint - tour date must be within begin-date and end-date of user request (so that the tour date must be within check-in, inbound, check-out, and outbound date as well). I define a set Date (sig Date) that has the fields day, month, and year where each of them has been defined as Integer. However, the problem is day can be negative number. And after executing the codes, the given instance seems weird. Could anyone please give a suggestion or advise me the right way to define that constraint?
Thirdly, I have a question that need to be clarified. Let say, the above problem has been resolved, and I need to initialise the specific request, for example tour date is July 1, 2016, date-begin is July 2, 2016 and end-date is July 4, 2016. Since I have defined the above constrained (Question No. 2), I want Alloy informs that the date given are violated. Is it possible to Alloy to do that?
I would really appreciate if anyone could give some comments and advice. Thank you
You need to test dates for sameness and for order. Unless you are trying to check the correctness of a design for calculating sameness and order of dates in the Gregorian calendar, however, there seems to be very little utility to modeling the internal structure of dates in Alloy.
So in your position I would, as Loïc Gammaitoni has already suggested, define an ordering on Date to support your queries on sequence.
Related
I have an application that uses subscriptions for each member that joins. I'm having some issues with dates and calculations related with it. For example, let say a member joins on 2/10/2020 at 10:00. When the user submit the request to the server to process the subscription (the server is using UTC) the date that is being calculate is 2/10/2020 16:00 (because I'm -6:00 hours from UTC). This scenario is OK at this point, because the date is still the same (no matter the time). But, if we replicate this scenario when the user joins for example 2/10/2020 at 19:00, when the request is received and calculate the date, the result is 2/11/2020 01:00, and that produces an error in the invoice because the billing date of the invoice is wrong (one day after). What is the best way to implement this? I have read a lot of this topic, but most of the pages and questions are related in the other way, server to client, to parse of format dates to display to the user.
I have several questions related with this process.
Should I sent the date for the UI to the API? Or the timezone and
based on that, calculate the date in the API? (since the server have
UTC)
Moment.js library have a way to solve this or should be better with vanilla Javascript using Date?
Is there any HTTP header for the request to handle the time or date?
This really depends on what behavior you want to have. Before you try to fix anything, think through and decide on the exact requirements for what the billing date should be based on.
Is the user's time zone relevant? If so, you'll likely need to know what the user's time zone is. You'll be potentially assigning different dates to different invoices even if they're using the same UTC point in time. Your business might get confused on why some customers have invoice dates before or after the business day.
Or maybe the time zone of your company is more relevant? Many business work that way. All of your invoices will be aligned, but some customers might get confused on why their invoice date is before or after their current date.
Or maybe some customers snap to time zones of nearby offices, in the case of businesses with offices around the world.
Only you and your company can decide this. There are probably other options I'm not thinking through here. It's a business decision, not a technical one.
On your three questions:
That depends on what you decide above.
Libraries are a good idea for simplifying your code, but they're not a hard requirement. You can use the Date API, if you know what you're doing, but you may find libraries easier to work with. Also, Moment is in maintainance mode. For new development, the Moment team recommends you use Luxon instead of Moment. There are other popular modern libraries also, including date-fns and js-Joda.
There's the date header, but that's not going to help you with this.
In the chat application i am developing with dialog flow has scenario like this. Users can ask details about loans that they can get. that is a one intent. once user says the loan type they want i need to save it and use it every where when they ask question. for one example i have a another intent called loan payments.
In that intent they can ask questions like
I am interested in getting a personal loan for a duration of 5 years
and the loan amount would be 5 million rupees. Can you let me know the
monthly repayment amount?
to calculate that, loan type is a must (personal loan in this case). so if any user has specified the loan type before i need to use it here other wise i need to ask users to provide it again. but if i am using context i cant add add required. how to achieve this. also since i have already set the parameters i cant change the value of them. this is how my parameters look like
This is where your business logic comes in picture. Chat application can be built in two ways, directional & open-ended. In first one, you can explicitly go on asking few questions with set options/buttons for the services that you're offering & user has to select any one of them or in the second one, you keep it open for people to type-in anything & then you extract values & respond them based on their inputs.
Now that you're of second type, even if you use contexts, dialogflow offers you a favor to extract parameter values of first intent in the second one. You just have to use, #context_name.parameter_name. But now, if you're saying that if user has already defined loan type in earlier intent then you don't want to ask him again it in next intent, then this is purely a business logic that you will have to code in your webhook. Dialogflow won't do it for you.
I hope, this answers your question & if you don't want to do it that way, go for directional flow.
I am building an api.ai agent, but I'm struggling to get unbounded date-period parameters understood correctly.
For example:
before 2000 is interpreted as ["2000-01-01/2000-12-31"]
after 1999 is interpreted as ["1999-01-01/1999-12-31"]
after January 2007 is interpreted as ["2007-01-01/2007-01-31"]
This makes me think only the date (2000/January 2007) is used for calculating the date-range, ignoring the adverb (before/after).
Is there a way to understand before 2000 as ["0000-01-01/2000-01-01"] (or at least ["1970-01-01/2000-12-31"] if Epoch-based)?
The before and after isn't matched, you are right.
You can add a custom entity, like temporal preposition, to deal with this.
before: prior to, previous to, earlier than, preparatory to, in preparation for, preliminary to, in anticipation of, in expectation of; in advance of, ahead of, leading up to
after: following, subsequent to, succeeding, at the close/end of, in the wake of, later than
You may create a composite entity (see in the docs).
There you can compose the new preposition entity with the sys.date entity.
So you will bound them together logically.
I'm quite new to DDD so apologies if this is well writ but I have struggled to find an answer.
In our domain we have a representation of a 'Normal Shift', e.g. Afternoon: 15.00 - 18.00. It is possible however for shifts to be modified either on specific days of the week (Mon - Sun) or for specific 'Locations'. The end result should be the same shift (Afternoon for example) but with a new time on a specific day / at a specific location.
How should we model these updated shifts? So far we've come to.
A common 'Shift' object which can be applied as a Normal Shift and also associated to a day or location.
A model to denote the change 'Shift Adjustment'.
Unique models for each shift, with some kind of relationship so they can be applied. E.g. 'Location Shift'.
We keep toggling between 1 & 3. 1 seems like a more natural language fit yet 3 feels more complete in that the business logic isn't hiding real facets of the model.
Any help would be greatly appreciated!
First, I think this initially has nothing to do with DDD. Rather it is about how you represent these concepts in your domain model.
You don't state explicitly the behavior you require. So, I'm guessing you may want to be able to send a message to an appropriate object in your model to get you a shift ... FindShift(name,[day,location]). FindShift would return either a default shift, or a custom one if it exists. Providing the day and location might be optional.
One simple way to represent this is as follows:-
A Shift has an optional day and location. This solution requires a business rule (a constraint) preventing applicable duplicates.
There are other ways to model this, especially in regards to making "default" shifts explicit. But it's hard to do so if you don't state the behavior required, rather than just a structural description.
I have a requirement in which I need to import data from excel (CSV) to Dynamics CRM regularly.
Instead of using some simple Data Duplication Rules, I need to implement a point system to determine whether a data is considered duplicate or not.
Let me give an example. For example these are the particular rules for Import:
First Name, exact match, 10 pts
Last Name, exact match, 15 pts
Email, exact match, 20 pts
Mobile Phone, exact match, 5 pts
And then the Threshold value => 19 pts
Now, if a record have First Name and Last Name matched with an old record in the entity, the points will be 25 pts, which is higher than the threshold (19 pts), therefore the data is considered as Duplicate
If, for example, the particular record only have same First Name and Mobile Phone, the points will be 15 pts, which is lower than the threshold and thus considered as Non-Duplicate
What is the best approach to achieve this requirement? Is it possible to utilize the default functionality of Import Data in the MS CRM? Is there any 3rd party Add-on that answer my requirement above?
Thank you for all the help.
Updated
Hi Konrad, thank you for your suggestions, let me elaborate here:
Excel. You could filter out the data using Excel and then, once you've obtained a unique list, import it.
Nice one but I don't think it is really workable in my case, the data will be coming regularly from client in moderate numbers (hundreds to thousands). Typically client won't check about the duplication on the data.
Workflow. Run a process removing any instance calculated as a duplicate.
Workflow is a good idea, however since it is being processed asynchronously, my concern is the user in some cases may already do some update/changes to the data inserted, before the workflow finish working.. therefore creating some data inconsistency or at the very least confusing user experience
Plugin. On every creation of a new record, you'd check if it's to be regarded as duplicate-ish and cancel it's creation (or mark for removal).
I like this approach. So I just import like usual (for example, to contact entity), but I already have a plugin in place that getting triggered every time a record is created, the plugin will check whether the record is duplicat-ish or not and took necessary action.
I haven't been fiddling a lot with duplicate detection but looking at your criteria you might be able to make rules that match those, pretty much three rules to cover your cases, full name match, last name and mobile phone match and email match.
If you want to do the points system I haven't seen any out of the box components that solve this, however CRM Extensions have a product called Import Manager that might have that kind of duplicate detection. They claim to have customized duplicate checking. Might be worth asking them about this.
Otherwise it's custom coding that will solve this problem.
I can think of the following approaches to the task (depending on the number of records, repetitiveness of the import, automatization requirement etc.) they may be all good somehow. Would you care to elaborate on the current conditions?
Excel. You could filter out the data using Excel and then, once you've obtained a unique list, import it.
Plugin. On every creation of a new record, you'd check if it's to be regarded as duplicate-ish and cancel it's creation (or mark for removal).
Workflow. Run a process removing any instance calculated as a duplicate.
You also need to consider the implication of such elimination of data. There's a mathematical issue. Suppose that the uniqueness' radius (i.e. the threshold in this 1D case) is 3. Consider the following set of numbers (it's listed twice, just in different order).
1 3 5 7 -> 1 _ 5 _
3 1 5 7 -> _ 3 _ 7
Are you sure that's the intended result? Under some circumstances, you can even end up with sets of records of different sizes (only depending on the order). I'm a bit curious on why and how the setup came up.
Personally, I'd go with plugin, if the above is OK by you. If you need to make sure that some of the unique-ish elements never get omitted, you'd probably best of applying a test algorithm to a backup of the data. However, that may defeat it's purpose.
In fact, it sounds so interesting that I might create the solution for you (just to show it can be done) and blog about it. What's the dead-line?