The system is usually named by the type (some narrow class) of its primary function (if the supra system team names it) or the service provided to it (if the producer names it) — i.e. by the primarily assigned behaviour in its supra system/operational environment. In other words, the system is named as a role object if you use it, or as part of a design if you manufacture it — but in the manufactured system, you are also trying to anticipate its function, to specify its role (by type). If you have a box in your car that connects various electronic devices (ignition switch, speedometer, etc.) to the Internet (some servers in the cloud), what do you call it? According to its type! In the house, the device that connects various home electronics to the Internet is called a router. Here it will be a car router! That’s it, the type (router packets of data from some local devices to the “big Internet”) is defined, and you will save a lot of minutes explaining what kind of System-of-Interest you have.
According to the main purpose/function, not only the System-of-Interest is named as a role object. All others (supra systems, systems in the environment, subsystems), i.e. naming the system, turns out to be naming it as a functional “black-box” of a given purpose, rather than a white-box, and this naming is associated with the behaviour, the play of some type role. It is this type role that will be the name of the system. So the naming of the system depends on the expected environment of the system. We tend to name the service with some generalization of the expected role/function of the system in the supra system.
So, a microscope is designed to look at small objects. If one occasionally nails with it, that is not considered its primary purpose, although that would sometimes be its behaviour/function in the supra system. It is a rare purpose, a feature of some uses. Therefore, a microscope cannot be called a “nailing microscope” or a “hammer microscope”. No, only for its primary purpose. But if you are taking the microscope into your system specifically as a nail gunner, then call it that! The name of the “seller” and the name of the “buyer” can differ. We have already discussed that service and function are different. The service and naming of the system as a modular object is usually done by the seller and expresses the expectation of possible use. But a functional object is bought, and it is named according to actual use. Don’t be surprised by the two names if you buy a microscope (manufacturer’s name!) as a nail gun (consumer’s name!).
We name the class/type of system, not a unique instance of the system. It is very often a role object, an “activity performer” (assembler, loader, slicer), but not only. The purpose of “scissors” (caesorium referred to as a cutting instrument in Latin) is well known, so scissors will most likely be called scissors-but add clarifications (e.g., “metal scissors”). Remember that overgeneralization is a big mistake. A microscope should not be called an “optical instrument”, and scissors would also be better specified — hairdressing scissors or metal scissors. Specifying is good. Generalizing is bad. If you called the system “fruit” rather than “orange”, do not be surprised if they will be angry, finding that you have not sold a peach. A peach is a “fruit”, and customers will assume that
“fruit” will fulfil any role in this category. If not, they will be angry for a reason. So, as always, name it accurately, don’t generalize.
The most common mistake one makes when naming is to list all possible functionality in a long list. Instead of “bus”, it would be “a system for boarding, highway transportation, stop notification and driver and passenger communication, disembarking passengers and closing doors for safety”. You can’t do that: any lengthy listing of functions in a name is unacceptable. And sometimes there’s an established name that should be used — the same “bus”. If it’s a type, it’s already clear to everyone what such a system does.
Another equally common mistake is to refer not to the role object, i.e., the action/function in the supra system, but the construction. The construction usually refers to the time the system was made, “what we made the system out of and how we made it. Instead of “metal scissors” would be “a system of blades, handles, and screws”, an obvious mistake. Instead of “antistatic for plastics” (the role of “antistatic” in a potential “plastic” supra system) it would be “a system of introducing carbon tubes into plastics” (what antistatic was made of, an error). No, the name of the system is given by the primary/common/typical purpose of the system, by the role/functionality in the supra system of the system.
We have already talked about the violation of the “mailman principle” as indicating too general a role object, too general an action/role/function, but we will say it again “Cutting system” instead of “metal scissors”. “Motor vehicle” instead of “bus”. “Fruit” instead of “orange”. The role must be specified precisely, without overgeneralization. You can’t say “calculations”, you have to specify which calculations, what precisely those calculations count (not “calculation”, but “calculation of medium-term risks” or “calculation of the order readiness date”). The name should guess the domain from the system level of the supra system, with no overgeneralizations. Programmers are particularly notable for ignoring a domain: they have all the “calculations”, “services”, “databases” without any indication of what they do in the domain. There are no words from the domain in which these “calculations” and “services” work — something is named wrong. There is an overgeneralization.
Another one is the unwarranted use of the word “system” in the titles: “metal scissor system” should be replaced with “metal scissors” right away.
