5 ms·

It looks pretty impressive, but I’m struggling to find the practical problem it solves. Lots of jargon, eg “constraint language for modelling data structures”.

• hcs 7y ago
  This isn't about generating production code, it's a way of testing designs. This helps shake out bugs in the design in much the same way fuzzing does in an implementation, but at this abstract level it's able to get much more exhaustive.
• hwayne 7y ago
  The big difference between Alloy and mainstream UML is that Alloy can check if your model has properties your want, and if not general a counterexample. A couple use cases for this: 1. You're writing an access control policy feature. There are many different moving parts to it: you can assign policies to individuals or user roles, some resources can inherit policies from parent resources, some policies can have multiple conditions, etc. Is there some weird feature interaction that lets somebody see a resource they shouldn't? 2. You're modeling an invoice. Every invoice has a number of items, each item has a supplier. Some items may correspond to their own invoice the supplier is paying, with its own line items. Its possible for you to pay for an item by supplier S that corresponds to an invoice where they pay you. Also two suppliers may be able to supply the same item and have different invoices for that item. Does your model of this have any insane edge cases you should be worried about?