The PrimaryScape™ notation is real simple and consists of a total of 3 concepts and 4 relationships.
The 3 concepts are represented by behavior and information realized in structure.
The 4 relationships are data access, data transfer, functional access, and functional transfer.
Together these concepts and relationships can be combined to express just about any kind of system, be it people based or computer based. PrimaryScape™ can be used to describe teams, companies, enterprises, information systems, people, batch scripts, files, or just about any other type of system conceivable.
You can now also view a presentation introducing PrimaryScape on SlideShare.net.
Concepts
The three core concepts are behavior, information, and structure. These are the primary building blocks of PrimaryScape™ diagrams.
Behavior represents any activity, process, or function. Basically if anything happens it is behavior. The term behavior can be thought of as odd to people used to model functions or processes. The intent with a general definition of behavior is to avoid any specific definitions of the commonly used terms “process” or “function”. What some people call process others call function and others call activities. For the Primary Modeling Notation, if anything happens then it is represented by a yellow box with rounded corners, i.e. behavior.
Information represents any set of information, data, or material. Basically if it is acted on, used by, or produced by some kind of behavior then it is considered information. The intent is to avoid any specific definitions of the term data or the term information. Information is also not meant to represent a type, such as classes or entities in other notations, but rather the existence of information. A good way to think about information is to think of each piece of information/data/material as a pebble and then ask yourself where the heaps of information are.
Structure represents the tangible things which realizes behavior and information. Behavior and information cannot exist independent of structure. Structure is basically anything which has to be created, configured, or set up before behavior can occur or information stored. Examples of structures are teams, computer systems, enterprises, buildings, factories, websites, trading partners, or individual people. It all depends on what it is you are modeling.
Relationships
Relationships are used to show the interactions between the primary building blocks. Primarily these are relationships between behavioral and informational concepts. The relationships can also be broken down into two categories, access and transfer. With behavior or information and access or transfer we end up with a 2×2 matrix of relationships which adds up to a total of 4 relationships.
| access | transfer | |
| information | data access informational access |
data transfer informational transfer |
| behavior | functional access behavioral access |
functional transfer behavioral transfer |
The labels data and functional are used instead of informational and behavioral for conventional reasons. References to data transfers and functions are more relatable and intuitively understandable in the information technology industry. However, the terms informational access, information transfer, behavioral access, and behavioral transfer can be used just as well if you prefer.
Data access is a relationship primarily between behavior and information. The direction of the arrow should indicate the main direction of the flow of information.
When the primary purpose of the behavior accessing the information is to update the information then the direction of the arrow is into the information.
When the primary purpose of the behavior accessing the information is to read or query the information then the direction of the arrow is into the behavior.
When the primary purpose of the behavior accessing the information is to both write to the information and read from the information then you can either use arrows in both directions or use no arrows at all. Using bi-directional arrows can make it easier to see the flow of the information in the diagram. In other cases using bi-directional arrows can clutter the diagram. Use your judgement based on the context and intent of the diagram you are creating.
The data access relationship is not allowed between two sets of information.
If the data access relationship is used with a structure then it short-hand and the implied behavior or information must be evident based on its context. If the short-hand is ambiguous then add the appropriate behavior or information within the structure to make it clear.
[more later …]
Data transfer is a relationship mainly between two sets of information. The direction of the arrow shows the direction of the transfer of information. Data transfers are deliveries of information which happens asynchronously. Think of data transfers as sending letters or packages via mail as compared to the data access relationship which is more like picking up a phone to get to the information while you wait.
Data transfers should never be bi-directional to the point where any exception proves the rule. If you think there is a bi-directional data transfer then most likely you are dealing with two different populations of information of the same type and modeling it as two separate sets of information adds clarity.
[more later …]
Functional access is a relationship between two functions (behaviors). Functional access is basically what is normally referred to as a function call if we were talking about one computer system calling a function of another computer system. However, since PrimaryScape™ is a more general modeling notation the functional access relationship can just as well be used between two teams, one team (structure) accessing the function (behavior) of another team (structure).
The functional access relationship is a synchronous call, which means the calling behavior is waiting for the called behavior to complete. For this reason it is important to understand which behavior is the caller and which is the called one. This is why at one end of the functional access relationship there is a weight or anchor to indicate the calling behavior.
The functional access relationship can also indicate the direction of the flow of information. For most functional access relationships there is a clear purpose. One such example is calling a function to create new information. The calling behavior is passing information to the called behavior for it to create new information. Simple examples would be create new customer or call in a new order. Another example where the direction of the information flow is rather clear are any queries, questions, or look-ups. The calling behavior is asking for information from the called behavior.
There is nothing to prevent you from indicating that information flows in both directions. One could make the argument that information always flows in both directions but the intent of using PrimaryScape™ is to capture the main intent. It is more important for PrimaryScape™ diagrams to be understandable rather than being accurate in too much detail.
[more later …]
Functional transfer is a relationship between two functions (behaviors). Functional transfers show how one behavior triggers another behavior. The triggering behavior does not wait for the triggered behavior to completed and instead moves on. The most common use of a functional transfer is to show the order in which behaviors take place, one function (behavior) handing off to the next.
Functional transfers can be bi-directional but using two separate uni-directional functional transfers between two behaviors will likely provide greater clarity.
[more later …]