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?
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?