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.
Related
I created an empty migration, which now looks like this:
def forwards(apps, schema_editor):
Foo = apps.get_model('app', 'Foo')
FixedResponse.objects.create(name='Bar')
def backwards(apps, schema_editor):
Foo = apps.get_model('app', 'Foo')
Foo.objects.filter(name='Bar').delete()
class Migration(migrations.Migration):
dependencies = [
('app', '0035_fixedresponse'),
]
operations = [
migrations.RunPython(forwards, backwards)
]
Since there is no Django documentation anywhere on this topic (migrations specific) or best practice,
I want to know how do I type hint the code above?
There is no universal answer to that question, and the only reputable source you will find about it is Django's reference and documentation, which don't make any mention about annotations for migrations.
The "correct way to handle type hinting in Django" strictly depends on your company's policy. Prior to asking how, you must ask why. Once you know why, figuring out how will likely be straightforward. However, if instead of asking "why?", you (or your boss) ask "why not?", that's taking the issue upside down. You need a reason to do something, but you don't need a reason not to do something. (1)
If the reason is "to pass CI", this is no valid reason. CI is meant to work for you, not the opposite.
If the reason is "to document the code", this is no valid reason either. Type hints are documentation, the purpose of writing documentation is not "to document the code". Why is any documentation needed? Who is going to read this documentation? What information do they need that is not already clear in the code?
I see 3 valid reasons to use type hints:
Provide help for developers using the functions. In the case of migrations, forwards and backwards functions are only used internally by Django. Developers reading your code are expected to have knowledge about migrations. If they don't know what apps and schema_editor are, it seems fair to expect them to refer to migrations.RunPython documentation, rather than re-explaining it for every single backwards and forwards callbacks of every single RunPython operation of every single migration.
QA type checking. But type checking is only useful for your own code. You'll never import the functions from migrations to use them in your code, so there is nothing to check.
Provide meta information for some smart tools (internal or third party) using introspection to do magic stuff.
Unless your case fits in one of these three, or you have any other reason to use type hints, don't try to fit to "policies" blindly. Don't write annotations just because you can. Keep calm and (re)read the Zen of Python. :) (2)
TLDR: Ask your boss to tell you why he wants type hints for migrations. If the answer is a well-defined purpose, write hints to serve that purpose. If the answer is anyhow stupid, write stupid type hints. ¯\(ツ)/¯ (3)
Footnotes
(1) The double negation might be confusing. What I mean here is that if someone can't explain the purpose of doing something, you don't need to find the purpose of not doing it. Or at least, there is a very straightforward purpose: saving the time and resources required to do it and maintain it.
(2) Don't try to find any principle specific to this situation in the Zen of Python. I only meant this reference as a general reminder of Python's philosophy: keep things simple, clear explicit code is worth more than poor paraphrasing documentation, that kind of stuff.
(3) If the purpose is "to pass CI" or such, I'd personally recommend something silly like def forwards(apps: ..., schema_editor: ...) -> ... (I mean, literally annotate with the Ellipsis object). Either nobody notice and it was indeed pointless, either your boss or your colleagues throw it back at you and hopefully come with a better defined purpose.
The documentation:
code (and reverse_code if supplied) should be callable objects that accept two arguments; the first is an instance of django.apps.registry.Apps containing historical models that match the operation’s place in the project history, and the second is an instance of SchemaEditor.
https://docs.djangoproject.com/en/stable/ref/migration-operations/#django.db.migrations.operations.RunPython
So, if you want to annotate your data migrations with types, these are the appropriate annotations:
from django.apps.registry import Apps
from django.db.backends.base.schema import BaseDatabaseSchemaEditor
def forwards(apps: Apps, schema_editor: BaseDatabaseSchemaEditor):
...
I'm looking for a data structure which behaves similar to boost::property_tree but (optionally) leaves the get/set implementation for each value item to the developer.
You should be able to do something like this:
std::function<int(void)> f_foo = ...;
my_property_tree tree;
tree.register<int>("some.path.to.key", f_foo);
auto v1 = tree.get<int>("some.path.to.key"); // <-- calls f_foo
auto v2 = tree.get<int>("some.other.path"); // <-- some fallback or throws exception
I guess you could abuse property_tree for this but I haven't looked into the implementation yet and I would have a bad feeling about this unless I knew that this is an intended use case.
Writing a class that handles requests like val = tree.get("some.path.to.key") by calling a provided function doesn't look too hard in the first place but I can imagine a lot of special cases which would make this quite a bulky library.
Some extra features might be:
subtree-handling: not only handle terminal keys but forward certain subtrees to separate implementations. E.g.
tree.register("some.path.config", some_handler);
// calls some_handler.get<int>("network.hostname")
v = tree.get<int>("some.path.config.network.hostname");
search among values / keys
automatic type casting (like in boost::property_tree)
"path overloading", e.g. defaulting to a property_tree-implementation for paths without registered callback.
Is there a library that comes close to what I'm looking for? Has anyone made experiences with using boost::property_tree for this purpose? (E.g. by subclassing or putting special objects into the tree like described here)
After years of coding my own container classes I ended up just adopting QVariantMap. This way it pretty much behaves (and is as flexible as) python. Just one interface. Not for performance code though.
If you care to know, I really caved in for Qt as my de facto STL because:
Industry standard - used even in avionics and satellite software
It has been around for decades with little interface change (think about long term support)
It has excellent performance, awesome documentation and enormous user base.
Extensive feature set, way beyond the STL
Would an std::map do the job you are interested in?
Have you tried this approach?
I don't quite understand what you are trying to do. So please provide a domain example.
Cheers.
I have some home-cooked code that lets you register custom callbacks for each type in GitHub. It is quite basic and still missing most of the features you would like to have. I'm working on the second version, though. I'm finishing a helper structure that will do most of the job of making callbacks. Tell me if you're interested. Also, you could implement some of those features yourself, as the code to register callbacks is already done. It shouldn't be so difficult.
Using only provided data structures:
First, getters and setters are not native features to c++ you need to call the method one way or another. To make such behaviour occur you can overload assignment operator. I assume you also want to store POD data in your data structure as well.
So without knowing the type of the data you're "get"ting, the only option I can think of is to use boost::variant. But still, you have some overloading to do, and you need at least one assignment.
You can check out the documentation. It's pretty straight-forward and easy to understand.
http://www.boost.org/doc/libs/1_61_0/doc/html/variant/tutorial.html
Making your own data structures:
Alternatively, as Dani mentioned, you can come up with your own implementation and keep a register of overloaded methods and so on.
Best
As far as I understand TDD and BDD cycle is something like:
Start by writing tests
See them fail
Write code
Pass the tests
Repeat
The question is how do you write tests before you have any code? Should I create some kind of class skeletons or interfaces? Or have I misunderstood something?
You have the essence of it, but I would change one part of your description. You don't write tests before you write code - you write a test before you write code. Then - before writing any more tests - you write just enough code to get your test to pass. When it's passing, you look for opportunities to improve the code, and make the improvements while keeping your tests passing - and then you write your second test. The point is, you're focusing on one tiny bit of functionality at any given time. What is the next thing you want your program to do? Write a test for that, and nothing more. Get that test passing. Clean the code. What's the next thing you want it to do? Iterate until you're happy.
The thing is, if you write tests before writing code, you don't have that focus. It's one test at a time.
Yes, that is correct. If you check out Michael Hartl's book on Ruby on Rails (free for HTML viewing), you will see how he does this specifically. So to add on to what lared said, let's say your first job is to add a new button to a web page. Your process would look like this:
Write a test to look for the button on the page visually.
Verify that the test fails (there should not be a button present, therefore it should fail).
Write code to place button on the page.
Verify test passes.
TDD will save your bacon when you accidentally do something to your code that breaks an old test. For example, you change the button to a link accidentally. The test will fail and alert you to the problem.
If you are using a real programming language, (you know, with a compiler and all,) then yes, of course you have to write class skeletons or interfaces, otherwise your tests will not even compile.
If you are using a scripting language, then you do not even have to write skeletons or interfaces, because your test script will happily begin to run and will fail on the first non-existent class or method that it encounters.
The question is how do you write tests before you have any code? Should I create some kind of class skeletons or interfaces? Or have I misunderstood something?
To expand on a point that lared made in his comment:
Then you write tests, which fail because the classes/whatever doesn't exist, and then you write the minimal amount of code which makes them pass
One thing to remember with TDD is that the test you are writing is the first client of your code. Therefore I wouldn't worry about not having the classes or interfaces defined already - because as he pointed out, simply by writing code referencing classes that don't exist, you will get your first "Red" in the cycle - namely, your code won't compile! That's a perfectly valid test.
TDD can also mean Test Driven Design
Once you embrace this idea, you will find that writing the test first serves less as a simple "is this code correct" and more of a "is this code right" guideline, so you'll find that you actually end up producing production code that is not only correct, but well structured as well.
Now a video showing this process would be super, but I don't have one but I'll make a stab at an example. Note this is a super simple example and ignores up-front pencil and paper planning / real world requirements from business, which will often be the driving force behind your design process.
Anyway suppose we want to create a simple Person object that can store a person's name and age. And we'd like to do this via TDD so we know it's correct.
So we think about it for a minute, and write our first test (note: example using pseudo C# / pseudo test framework)
public void GivenANewPerson_TheirNameAndAgeShouldBeAsExpected()
{
var sut = new Person();
Assert.Empty(sut.Name);
Assert.Zero(sut.Age);
}
Straight away we have a failing test, this won't compile because the Person class doesn't exist. So you use your IDE to auto-create the class for you:
public class Person
{
public int Age {get;set;}
public string Name {get;set;}
}
OK, now you have a first passing test. But now as you look at that class, you realise that there is nothing to ensure a person's age is always positive (>0). Let's assert that this is the case:
public void GivenANegativeAgeValue_PersonWillRejectIt()
{
var sut = new Person();
Assert.CausesException(sut.Age = -100);
}
Well, that test fails so let's fix up the class:
public class Person
{
protected int age;
public int Age
{
get{return age;}
set{
if(value<=0)
{
throw new InvalidOperationException("Age must be a positive number");
}
age=value;
}
}
public string Name {get;set;}
}
But now you might say to yourself - OK, since I know that a person's age can never be <=0, why do I even bother creating a writable property - do I always want to have to write two statements, one to create a Person and another to set their Age? What if I forgot to do it in one part of my code? What if I created a Person in one part of my code, and then later on I tried to assign a variable that was negative to Age later on, in another module? Surely, Age must be an invariant of Person so let's fix this up:
public class Person
{
public Person(int age){
if (age<=0){
throw new InvalidOperationException("Age must be a positive number");
}
this.Age = age;
}
public int Age {get;protected set;}
public string Name {get;set;}
}
And of course you have to fix your tests because they are won't compile any more - and if fact now you realise that the second test is redundant and can be dropped!
public void GivenANewPerson_TheirNameAndAgeShouldBeAsExpected()
{
var sut = new Person(42);
Assert.Empty(sut.Name);
Assert.42(sut.Age);
}
And you will then probably go through a similar process with Name, and so on.
Now I know this seems like a terribly long-winded way of creating a class, but consider that you have basically designed this class from scratch with built-in defences against invalid state - for example you will never ever have to debug code like this:
//A Person instance, 6,000 lines and 3 modules away from where it was instantiated
john.Age = x; //Crash because x is -42
or
//A Person instance, reserialised from a message queue in another process
var someValue = 2015/john.Age; //DivideByZeroException because we forgot to assign john's age
For me, this is one of the key benefits of TDD, using it not only as a testing tool but as a design tool that makes you think about the production code you are implementing, and forcing you to consider how the classes you create could end up in invalid, application killing states, and how to guard against this, and helping you to write objects that are easy to use and don't require their consumers to understand how they work, but rather what they do.
Since any modern IDE worth it's salt will provide you with the opportunity to create missing classes / interfaces with a couple of keystrokes or mouse clicks, I believe it's well worth trying this approach.
TDD and BDD are different things that share a common mechanism. This shared mechanism that is that you write something that 'tests' something before you write the thing that does something. You then use the failures to guide/drive the development.
(
You write the tests by thinking about the problem you are trying to solve, and fleshing out the details by pretending that you have an ideal solution that you can test. You write your test to use your ideal solution. Doing this does all sorts of things like:
Discover names of things you need for your solution
Uncover interfaces for your things to make them easy to use
Experience failures with your things
...
A difference between BDD and TDD is that BDD is much more focused on the 'what' and the 'why', rather than the 'how'. BDD is very concerned about the appropriate use of langauge to describe things. BDD starts at a higher level of abstraction. When you get to areas where the detail overwhelms language then TDD is used as a tool to implement the detail.
This idea that you can choose to think of things and write about them at different levels of abstraction is key.
You write the 'tests' you need by choosing:
the appropriate langauage for your problem
the appropriate level of abstraction to explain your problem simply and clearly
an appropriate mechanism to call your functionality.
I'll simplify things for this scenario (It's in Perfect Developer, it gets complex quite quickly). Let's say I have a simple schema in my class, called Succeed, which takes a Course (which is a previously defined class) as parameter.
Basically, I want to be sure that the course is in my courses set as a precondition, and then add it to my coursesCompleted set in my postcondition. This simple schema works great, and looks like this :
schema !Succeed(c:Course)
pre
c in allCourses
post
coursesCompleted! = coursesCompleted.append(c);
However, I want to add a quite simple if condition: If my coursesCompleted cardinality is 30 or more, I want to set a Diplomation enum to, let's say, "Ok". If the cardinality is less than 30, I will set it to "NotOk"
According to Perfect Developer's documentation, and all the rare examples I've seen, the if syntax should look like this :
if [condition1] : do stuff;
[condition2] : do other stuff;
fi
However, if I plug that directly in my schema, as is :
schema !Succeed(c:Course)
pre
c in allCourses
post
coursesCompleted! = coursesCompleted.append(c),
if [#coursesCompleted >= 30] : diplomation = Ok#DiplomationEnum;
[#coursesCompleted < 30] : diplomation = NotOk#DiplomationEnum;
fi
it does not work, I always end up with a "very descriptive"
Error! Syntax error at keyword 'if', expected one of: '!' '(' '?'
'c_address_of'
I've tried adding some ; everywhere, adding a via keyword after the post, changing it's position, trading ;s with ,, and a lot of other trial and error stuff.
So my question is: How can I add a if condition to a postcondition of a schema, in Perfect Developer?
Please answer in Perfect Developer. I (sadly) know my formal methods, I only need the if to compile in the worst tool in the world.
I can provide a solution in formal-methods using the zet notation, since I am not using Perfect Developer, however, that program should be based on formal-methods. As far as I know in formal methods, if conditions are not used when the system has different behavior over some preconditions, but rather you create 2 methods with different
preconditions(the way i implemented it) or a nested method covering both scenarios, seperated with a Logic OR in between. When it comes to error handling, you first provide a best case scenario and then define a robust method definition(schema calculus).
In formal methods the notation ! is used to describe the output while ? is used for the input.
I hope that this will help you understand possible issues, since its not a direct perfect-developer solution. However, considering the fact that in formal methods mathematics are used, you can use the following specification and jump to any program/language for the implementation part.
Note that: Anything that you will see in the following schemata on the preconditions/how the system changes part, is connected with a logic AND, however I am not using the symbol because is implied as far as a logic OR is not used.
So here is how it will look like in formal-methods(Z-notation).
I have a class CardStack. I have several classes that inherit from CardStack e.g. Cascade, Deck, Foundation etc.
Foundation doesn't need to add any functionality to CardStack, but for display purposes my app needs to know which of the CardStacks are actually Foundations.
Incidentally, I have no such function CardStack.Display() (I'm using a model-view-controller pattern where the View object simply queries the Model to find out what type of objects it's dealing with).
It seems OK to me, but is there any reason not to do this?
class Foundation : public CardStack
{
};
class Model
{
Cascade cascade[10];
Foundation foundations[10];
...
};
Nothing wrong with this.
Do it all the time.
In the future, there may be a difference in structure, behavior or implementation. For now, they happen to share a lot of common features.
I don't see any technical problem with it, so maybe you're doing this for semantic reasons. In that case, make sure you document the reason it VERY CLEARLY so maintenance programmers later on don't try and change things.
Yep, this is valid and useful. An empty class can act as placeholder for future functionality (as example). Of course, a bit of documentation is in order if the class in question is "connected" to the program in any way ;-)
In your case above, the C++ code generated won't be burdened... but readability of your code is increased.
I do it all the time for lists
public class MyObjects : List<MyObject> { }
It's good practice, since it is semantically clearer with nearly, with nearly no cost associated and allows for modifications, when the need arises for subclasses do behave differently.
Nothing wrong with it, I do this often. I like it better than empty "marker" interfaces (in Java). As others have mentioned, you should probably comment on the fact that the implementation is supposed to be empty (or perhaps "reserved for future use"), but otherwise IMHO you're fine.
The way you did it the Model class it seems to me that typedef will suffice to distinguish names (and readability!):
http://en.wikipedia.org/wiki/Typedef