I have two tables: Project and Contract. One project result in a contract. Plus, a contract could be extended leading to another contract related to the previous one. So I think I could use something like:
contract = models.ManyToManyField('self')
Any idea?
Thanks!
It depends on your requirements. A contract can result in another contract or another contractS? That is very important questions. If we assume that a contract A can lead to another contract B (but not to other contracts) and that the new contract B can be extended only from contract A, then OneToOneField('self') would be appropriate.
If a contract A can lead to contract B, but also to contract C or maybe contract D, then the ForegnKey('self') should be used. But if contract B can be traced back not only to contract A, but also to contract E, or maybe even contract F and contract G, then you need ManyToManyField('self').
So it is very basic question first to clarify if it as a 1:1, 1:n or m:n relation. After figuring this out you'll have your right answer.
From the information you provided I can just vaguely guess what should be the right approach.
I hope my answer can help you.
Related
I was digging into this OZ smart contract:
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Context.sol
As you may see, it has only two functions to deal with metatxs. I can't figure out why this contract is defined as abstract, as both functions are implemented. Thanks in advance to all of you!
The Context contract was made abstract in the pull request #2229. One of the contributors links to the issue #8162 for explanation:
it seems like what the keyword does is mark the contract as non-deployable (i.e. it needs to be inherited from). Because contracts missing function implementations are always non-deployable, they require abstract.
From my understanding, their reason was just to explicitly say "This contract has no use on its own, and should not be deployable (on its own)."
I have contract in solidity MasterChef.sol which can be seen at the link below
https://github.com/pancakeswap/pancake-farm/tree/master/contracts
I want to deploy it using truffle on the Binance smart chain and the question is that the constructor of the MasterChef.sol takes in 5 args and two of them are contracts I want to know that how to pass the other two contracts i.e CakeToken.sol and SyrupBar.sol as the first two args in the deploy_contracts.js file.
You need deploy other contracts beforehand, write down their addresses and pass addresses when MasterChef is deployed.
Let's say I have the following code:
class A {
public:
void doSomething(B* b);
}
class B {
}
How would I describe this in a UML diagram? My first thought is that A uses B, so there should be a dotted line from A to B. But in some of the school papers (this is a very tiny part of a school assignment report) they seem to use the aggregation symbol (empty diamond and solid line).
That doesn't seem right to me - if A actually contained a pointer to B as a member, that seems right. But when only some methods use a pointer to B, and don't store it in any member variables, it seems wrong.
What's right here?
(I could ask my teachers but they usually take really long to respond to this type of question... and honestly, I trust the collective brain trust of Stackoverflow more :) )
You should use a simple dependency between A and B:
A does just use B as parameter in an operation. If you have some attribute of type B then you would use an association. Aggregation give only a little extra semantics and you can (/should) leave it out unless you know that you want to transport some specific information.
There should NOT be any arrow between class A and class B. Arrows between classes are used to indicate "associations".
An association indicates that the system you are developing stores
links of some kind between the instances of the associated types.
Source: Properties of associations on UML class diagrams
To capture/represent void doSomething(B* b); you might try using activity diagram, for more see this link.
I have a class Client with attribute noClient, I wan to verify there is no client with the same noClient.
I have the solution below, but the teacher said its not appropriate. Because the contraint may be repeated. I don't know why. And I need to find another solution.
context Client
inv NoClientUnique: Client.allInstances -> isUnique (noClient)
My problem is, I don't even know what is the problem with the code above to be able to find another solution.
This this a school question. Maybe not enough challenging out there, but I spend hours trying to understand. I'm stuck here.
Apart from minor syntactical mistakes (should be allInstances()-> ) I don't see a problem with your expression. Make sure you didn't misunderstood your teacher regarding what the constraint was supposed to constrain
I just saw in an example, my teacher created a class Singleton, then use the Singleton as context, and not the Client.
class Singleton
-- nothing here.
end
...
context Singleton
inv SingletonisUnique : Singleton.allInstances -> size() = 1
inv noClientUnique : Client.allInstances -> isUnique(noClient)
I think this is the key to my problem, but I don't understand what's the mechanism there.
As far as I know, in a typing vision, the OclExpr in parameter should be a boolean expression to evaluate, which is not the case here.
Of course, the result will vary from one OCL tool to another.
Your teacher is correct in that with typical OCL tools evaluation of all Clients will be repeated for each Client.
But your teacher is also wrong in that a decent OCL tool should optimize the self-less invariant to achieve the same effect as the spurious Singleton. Tools should help the users not force users to manually optimize.
More realistically, the container of Client may perhaps be Business and you could more sensibly express the business practice that noClient is unique in Business since it isn't really a Client constraint.
Another option would be:
context Client
inv NoClientUnique: Client.allInstances()->forAll(c1, c2 : Client | c1 <> c2 implies c1.noClient <> c2.noClient)
For anyone else looking for the answer in 2020:
Client.allInstances().collect(noClient) -> count(noClient) = 1
I'm using USE from Bremen University and the isUnique() operation does not work as intended. Took me awhile to figure out an alternative.
I am about to add a class X that will be used by my three previously designed classes (A, B and C).
The new class X will contain data and functions for new features as well as provide services to the classes that use it to hide lower layers. The problem is that A, B and C will use class X quite differently, that is, use different functions of it.
My question is if I should provide an API (or Abstract Base Class in C++) for the new class X or not. If I should, should that API be per X class or per A, B and C class? I have read somewhere that an API is sometimes more closely related to that caller that the class that implements it. If I do provide one API for each caller, the API will only contain the functions that the particular caller needs.
Or should I just create a normal C++ class and let the callers use a subset of the public functions of X in each of A, B and C, although they "technically" can use them all? The functions of class X are not very likely to change neither is the need to create a similar class to X.
If I'm not completely lost in object oriented programming, one reason for providing an interface/API for a class is that code that use the interface/API doesn't need to change if you add another subclass since the caller works on the interface name and uses dynamic binding to resolve the correct subclass type.
Best regards and please let me know if anything is unclear and I'll try to answer that as quickly as possible.
Thanks,
Tomas
Are you sure all these functions belong to the same class X? Think about separating different functionality into different classes:
http://en.wikipedia.org/wiki/Low-Coupling_/_High-Cohesion_pattern
But without knowing what the functions of X are it is difficult to help further.
If things are unlikely to change then it's probably not worth the extra effort.
If you decide to, though, the question is whether new classes would implement all or just part of the functionality. For example, do they share backend storage, so all would need to be updated at once (in which case there is no point in splitting), or do they relate to entirely separate concerns in which case splitting (as suggested by #GarethOwen) is probably the way to go.