Documentation
  • Introduction
  • Why Ampersand?
    • The Business Rules Manifesto and Ampersand
  • Tutorial
    • Example system: Enrollment
    • Conceptual Model: Enrollment
    • Your tool: RAP4
    • Making your first Ampersand script
  • Reactive programming
  • The language Ampersand
    • How to read syntax statements
    • Truth
    • Atoms
    • The CONCEPT statement
    • The RELATION statement
    • The MEANING statement
    • The PURPOSE statement
    • The CLASSIFY statement
    • The RULE statement
    • Terms
      • Semantics
      • Semantics in logic
        • Primitive terms
        • Boolean operators
        • Relational operators
        • Residual operators
      • Semantics in natural language
        • Primitive terms in natural language
        • Boolean operators in natural language
        • Relational operators in natural language
        • Residual operators in natural language
      • Semantics in sets
        • Primitive terms in set theory
        • Boolean operators in set theory
        • Relational operators in set theory
      • Semantics of terms, defined algebraically
        • Boolean operators in algebra
        • Relational operators in algebra
      • Semantics visualized
        • Semantics of boolean operators visualized
        • Semantics of relational operators visualized
        • Semantics of residuals visualized
    • Context
    • Module
    • Best Practices
    • Syntactical Conventions
      • The CONCEPT statement
      • The RELATION statement
      • The RULE statement
      • The CONTEXT statement
      • The INCLUDE statement
      • Explanation
      • Patterns
      • Population
        • Population in spreadsheets
      • The PURPOSE statement
      • The IDENT statement
      • The TABLE statement
      • Language support
    • The INCLUDE statement
    • Patterns
    • Services
      • Example: Client
      • Example: Login
      • Syntax and meaning
      • Explanation
      • Layout of user interfaces
        • Your own widgets (HTML and CSS)
      • CRUD
    • Population
      • Population in spreadsheets
    • The ENFORCE statement
    • The IDENT statement
    • The TABLE statement
    • Language support
    • Current date
    • The Preprocessor
    • Design considerations
  • Running the Ampersand compiler
    • Configuration
    • Commands (vs. 4.0.0 and later)
    • Options (up to vs. 3.17.4)
  • Architecture of an Ampersand Application
    • Backend framework
    • Hooks
    • Extensions
      • The ExecEngine
  • Deploying your Ampersand script
    • Compiler
    • Deploy your own web application on your laptop
    • Prototype multi-stage build
    • Prototype database
  • Reusing Available Modules
    • Modules
    • Security
    • SIAM (Sessions, Identity and Access Management) Module
  • Exercises
    • Delivery
    • VOG (in Dutch)
  • Installing Ampersand
    • Deploying your Prototype
    • Installing the tools manually
  • Modeling
    • Domain Driven Design
    • Data modeling
    • Legal modeling
    • Architecture modeling
    • Metamodeling
    • Limitations of Ampersand
  • Configuring your application
  • The Excel Importer
  • Plans
    • Current State
    • NoSQL storage
    • API documentation
    • OWL and RDFS input
    • Refactor the front-end
  • Research
Powered by GitBook
On this page
  • Constraints
  • No obligations
  • Reliable semantics
  • Automated design process
  • Working systems over comprehensive documentation
Export as PDF
  1. The language Ampersand

Design considerations

The design considerations of Ampersand are treated as principles, not as laws. In case of conflicting design considerations, choices have been made.

Constraints

An Ampersand context presents itself as a universe with constraints. This was chosen to allow for incremental development. Adding a constraint changes nothing to the semantics of other constraints.

One example of this is found in the CRUD annotations: A service provides all possible CRUD-functions, which are constrained by CRUD annotations.

No obligations

The Ampersand engineer gets as much freedom as possible, to facilitate incremental development. Every obligation imposed on the Ampersand-engineer is a necessity.

One example is the freedom to define PURPOSE statements. Although the Ampersand team feels strongly about the need to specify a purpose for almost everything, the choice is left to the user. Since there is no hard technical reason for having them, the compiler does not impose its use.

As a consequence, the Ampersand engineer can choose the order in which she adds statements. This is consistent with the order-free semantics of Ampersand.

Reliable semantics

The semantics of a script is well-defined and self-contained, to ensure predictable behaviour of information systems defined in Ampersand.

The prime example is the relation algebraic semantics of terms, which is defined unambiguously in a well-studied formalism that is over a century of age.

Automated design process

Tools must be reliable and may not distract their users from their real work: designing information systems. For this reason we have paid much attention to making reliable tools and to automate the process of designing and building.

An example is the generation of software by the Ampersand compiler, which makes Ampersand more than a design tool. But also the deployment automation with Docker exemplifies this principle.

Working systems over comprehensive documentation

Every Ampersand script, that passes the compiler without errors yields a working system. This makes it easy to focus on working systems, because partial implementations can be demonstrated and tried. (prototyping).

This principle makes it easy to neglect documentation.

PreviousThe PreprocessorNextRunning the Ampersand compiler

Last updated 5 years ago