Modeling
There can be many reasons for making an Ampersand model. Just a few examples are:
You want to study the conceptual structure of something, to gain a better understanding or to acquire the jargon of a topic. Business analysts do it when starting on a new assignment. In a new environment with new people, unknown habits and a lot of catching up to do, they pick some documentation, courseware, legislature or other jargon-laden documentation and make an Ampersand model. Making sense of piles of new material goes much faster if you try to make an Ampersand model on the side.
You want to design persistent store (a database) for use in an application. You make a model of the data, the rules and make one service for every service your store provides.
You want to detect flaws in an architecture. Make an ampersand model of that architecture, and model every rule you want checked. Populate your model with data from the real architecture, and you can measure every flaw as it occurs.
Your build-team wants clear working instructions, but there is no time to make a functional specification. You make your Ampersand model and derive the work instructions from the functional specification and the prototype that you have made.
You need correct software. Develop your software in Ampersand and use the rules to establish correctness.
Your assignment is to cleanse a polluted database. Try to find the rules that define what clean data is, and run your data through Ampersand.
This chapter about modeling discusses different ways of using Ampersand. Each section serves a different purpose (e.g. how to make a data model, how to make a legal analysis, etc.), using the same tool (Ampersand). These sections can be used as study material.
The ways of using Ampersand are not exhaustive. There are most certainly other reasons for making an Ampersand model, because a good conceptual analysis precedes practically every problem that is worth solving.
An information system is modeled by designing every subsystem separately.
To specify an information system, take the following steps: 1. Agreement on the domain language; 2. Agreement on rules; 3. Validate rules; 4. Define services.
An ampersand model describes the rules, relations and concepts that define a business system. Using this specification, a software system can be built that can hold structured information as a set of facts. Based on the rules, the set of facts can be checked automatically to detect violations of rules.
In an Ampersand model, services can be defined too, enabling the definition of changes to the set of facts.