Foundations
v1.0 · in consultationPrinciples and core concepts
The principles behind Public Framework Modelling Language 1.0 and the core concepts every model works with: the model, the element, layer and family, the relationship, the property, sheets and identity.
Describes specification v1.0
Principles of the language
- Each concept belongs to exactly one layer and one family. Membership is fixed in the type definition, not in the model; a sheet can still freely combine elements from any of the 12 layers.
- Layer codes are stable. The code, for example STR, identifies the layer; its name and colour are for display only.
- Relationships are typed and checked. The editor does not create a relationship that is not permitted, and validation reports one as an error if it appears some other way.
- Policy intent is separate from legal basis. A public policy (Policy) has a legal basis without becoming a legal resource (LegalResource).
- The public service is separate from the software that supports it, so the service stays the same when the application changes.
- Service continuity is separate from technical recovery. OPS describes how systems are recovered; CNT describes how the public service continues when systems fail.
- The X layer is not a place for unclassified elements. Each cross-cutting concept is explicit and linked to its subjects.
- Object identity is stable. Renaming changes the name, not the identifier.
The model and its sheet
A model (Model) is an architecture description saved in a .pfmodel file. It has an identifier, a name, a description and a version, and contains the elements and the relationships between them. The model sheet shows the elements and relationships on a drawing surface; it is saved in the same file, separately from the model, so the meaning of the model does not depend on how it is drawn.
A project usually brings together several models in separate files. The “Family support benefit” example has three: the main model, benefits.pfmodel, a technical view and a continuity view.
The element, layer and family
An element (Element) describes a concrete thing in the architecture: a public policy, a public service, a dataset or a node. The element type fixes its layer, family, own fields and permitted relationships. All elements share common fields: identifier, name, description, documentation, tags and properties; validation requires every element to have an identifier and a name.
The layer shows which architecture question an element answers. The family shows what kind of thing the element is, regardless of layer. For example, a service channel (ServiceChannel) in ORG and an API in APP both belong to the access family. The language has 11 families, and many relationship rules depend on them.
| Family | What it groups | Example types |
|---|---|---|
| structure | Participants, resources and structural parts | PublicOrganisation, Role, SoftwareSystem, Node |
| service | What is offered to a beneficiary | PublicService, Capability, ManagedService |
| behaviour | The activity carried out | Procedure, Pipeline, Deployment |
| access | Access points and boundaries | ServiceChannel, API, Endpoint |
| information | The meaning, structure and evidence of information | InformationEntity, Dataset, LegalResource |
| store | Places where data or code are kept | DataStore, SourceRepository, StorageResource |
| event | What happens and starts an activity | LifeEvent, Incident, Milestone |
| intent | The direction, results and conditions pursued | Policy, Goal, Requirement, Risk |
| decision | Choices and decision rules | ArchitectureDecision, DecisionRule |
| change | Changes to the architecture | Programme, Project, ArchitectureState |
| location | Locations, areas and contexts | DataCentre, Environment, GeographicArea |
The relationship and the property
A relationship (Relationship) connects a source element with a target element and has a type, one of the 21 in the language. It has its own identifier and, optionally, a name; source and target are mandatory. Three optional fields each make sense for a single type: access mode for access, influence sign for influence, and restoration order for restoresAfter.
A property (Property) is a free key-value pair attached to an element or a tool. It keeps information the type does not provide for, for example a code from an internal register; the meaning of keys is set by the organisation maintaining the model.
Detail sheets, tools and references
An element may have one or more detail sheets describing its inside. Besides elements, sheets contain tools, which serve for annotation or for describing a workflow and are not architecture elements. Five tools are general: text annotation, group, region, time horizon and reference element. The others follow BPMN notation and are used only on detail sheets of elements in ORG, APP and CNT.
The reference element (ReferenceElement) shows on a sheet an element that already exists, usually in another model, without copying it. It keeps the target file and identifier as well as its type and name, so the sheet stays readable even when the target is not loaded.
Identity
Relationships, sheets and reference elements in other models find an object by its identifier. The application forms the identifier of a model or element from its name, and that of a relationship from its type, and does not change it when the name changes.