For large systems, having to model the entire system in a single CIF file can lead to long CIF specifications. Being able to split that single CIF file into multiple CIF files can help. Consider the following two CIF specifications in CIF files
// producer.cif event provide; automaton producer: location: initial; edge provide; end
// consumer.cif import "producer.cif"; automaton consumer: location: initial; edge provide; end
The two CIF specifications together form a simplified producer/consumer system. The
producer.cif file declares the
provide event and the
producer automaton. The
provide a product.
consumer.cif file declares the
consumer automaton, that can accept products provided by a producer. The
provide event is not declared in that CIF specification. However, the
producer.cif file is imported, which does declare that event. By importing another CIF specification, all declarations from that imported CIF specification (
producer.cif in the example) become available in the importing CIF specification, i.e. in the specification that does the import (
consumer.cif in the example).
The result of the import in
event provide; automaton producer: location: initial; edge provide; end automaton consumer: location: initial; edge provide; end
You can think of an import as being replaced by the content of the imported file. The
producer.cif file contains only its own content, while the
consumer.cif file contains the contents of both files, due to the use of the import.
If one CIF specification is merged into another CIF specification, the names of the declarations in both CIF specifications must be different. It is not allowed to have declarations with the same name in multiple CIF specifications. For instance, in the example above, if the
provide event were declared in both CIF specifications, the imports would be invalid. Exceptions to this rule are discussed in one of the next lessons, which explains the relation between imports and groups.