Modular/product/constructive descriptions
When the role/activity/labor concern is not related to the system's runtime but to the system's construction time - modular synthesis, procurement of modular parts/products/modules/items/blocks, assembly of the system from purchased modular parts, shipment of the resulting system-product, modular/constructive/product descriptions should be used. These descriptions answer the question of "how the system is made" (cf. with the functional "how the system works" - this is design-time versus run-time. Remember that in design-time we include not only design but also manufacturing or modernization, and decommissioning. But we do not include the time of operation).
The modular/constructive/product diagrams show modules, connected through interfaces, literally - "what's between." An interface is usually described by a standard, describing both the connection properties and the events occurring during the interaction of modules through the connection. It is customary to speak of assembling modules for their interaction through interfaces as integration. Standards describing two-way interaction are called protocols.
Module interfaces are similar to ports of functional parts in that they are places of attachment, i.e., interfaces are not constructive elements, they do not occupy space, although they may have a form. A plug and a socket, a socket and a plug, a USB cable and a USB socket: an interface is what is between them. And the physical end of the cable, designed according to the standard, the connector in the computer if it's a USB? This is an interface module, the main purpose of which is to implement some interface in the physical world. This module usually has not just one interface but two interfaces: one target and the other connecting it to some module that requires the target interface. This is a very common mistake: to confuse an interface with an interface module. Do not make this mistake (and students should not be surprised by a re-exam if you didn't read this far and call some part of the construction an interface). For example, the cell membrane is an interface of the cell with the outside world, or is it an interface module? Since the membrane consists of molecules that occupy space-time, it is a module. Membranes, cases, are interface modules with the environment, not interfaces! They have two interfaces: inside the system and outside the system.
Here is an example of such an interface module (which is colloquially called a USB interface, which is incorrect - it also has a signal interface to the board, a separate power interface, and even an interface to the user: an LED that flashes when data is transmitted and a power button, and there is also a mechanical attachment interface to the case or another board):
And what about the connections needed for operation - all these pipes, cables, waveguides? These are also modules/products/items/artifacts, and they have their interfaces: they are between them and the modules they connect. What passes through these interfaces, and how is it related to the operation of the entire system?
It's unknown because we are talking about constructive units in design-time: functions cannot be defined here; to do so, one must go beyond modular description into the realm of engineering solutions for implementing functional parts of the system with its constructive parts.
Most engineering solutions are about defining the roles of which functional parts will be played by certain constructive parts/modules, what interfaces will be between these constructive parts, and through these interfaces, what services will be performed corresponding to the functions of functional parts. Remember: from the system's perspective, the subsystem is expected to perform functions as a functional part, and from the subsystem's perspective as a constructive part for the system, providing a service through the interface is expected.
Often we are talking about the reception-processing-output by the module of some flow passing through the input and output interfaces of this physical flow. This physical flow will implement the functional flow from the functional description (e.g., a schematic), which goes through the functional/role part, to perform the role assigned to the module. So, via the USB interface, this or that data stream can be transmitted (to the printer, to the overhead projector, to the external monitor), physically corresponding to the passage of some profile of an electric current through the contact points of interface modules - but in the schematic/functional diagram/dataflow diagram, these will be streams of object (pages for the printer, slides for the projector, screens for the external monitor) data between the functional parts of the system.
During integration, it is important not just assembly but coordination of the modules' operation on their interfaces: the installer must ensure that the connection through the interface between a pair of interface modules is established, complies with the standard describing the interface, and thus the module will be able to perform its service in run-time.
There are rules for establishing a connection through interfaces, but it is unknown what exactly and why is transmitted through this interface - this will only be known from the schematic. The subject domain appears in the schematic from understanding what is done there in the functional world, not from understanding the construction. "Bedroom" appears from understanding what is done there functionally. In the constructive world, the world of products/modules, it is a "room." The "bedroom" is implemented by a "room" (instead of, say, a hallway or a balcony).
For example, a printer and a computer are connected via a USB interface, but what information goes to the printer, this is unknown to the interface. The iron is connected to the power grid via an interface between a Euro plug and a Euro socket, but this interface does not know what current will pass through it and what this current will do in run-time. But the maximum current values that can pass through this interface are known, as well as the maximum amount of information that can pass through the USB interface. The task of modular synthesis in system design is to select interface modules whose interfaces could withstand the flows with their operational modes, provided by the functional structure of the system.
Here is another example of modular/component (IEC 81346-1 suggests calling a component an ordered product that comes into the project from other creators) description, in this case, it is simply a list of components (another name for a product/component) that need to be purchased to manufacture the iPhone 2008, along with prices - and this immediately becomes a hybrid description, as it includes cost estimates[1]:
Note how many different standards are mentioned here: GPS, HSPDA, DDR, Bluetooth - a list of interfaces described by standards, usually for modular descriptions. The essence of modules is precisely the replacement of the implementation of a certain functional part of the system by simply replacing the constructive part: a module with a standard interface. The rapid progress in smartphone and laptop engineering is determined precisely by this: careful description of interfaces.
Instead of connecting one printer via a USB interface to the computer, you can connect another printer of the same brand, or even a printer of another brand, or not a printer but some other device (such as a scanner, or even an additional display) - without standardizing the interface, this would be impossible. Next comes competition: the price and quality of the service received through the same interface from competing module suppliers will be different, but changing the module will be easy for engineers, they won't have to change anything in the project if they used a standard interface!
Standard (with standard interfaces) parts are cheap because competition drives their price down. If you want to increase the product's price, remove the standard interfaces from it - and you will immediately get a huge amount of work that the developers of the standards have done in case of using standards. This is often used in government projects to justify their high cost: they simply specify a non-standard interface in the contract - and it's done! The method of fighting - demand that inter-module interfaces be specified not in the contract but in an open standard, with the contract containing only a reference to the open publicly available standard. Then more likely competition will arise, and the prices of purchased modules will drop. This method of fighting for low component prices is called open architecture. However, architecture is not regularly opened for reasons of protection against competitors, as well as to make it easier to manage the configuration. In closed architecture, to change the interface between modules requires agreement of fewer people - changing the standard requires much more time. The iPhone architecture belongs to this class of closed architectures. And it is not the cheapest device, although Apple's negotiating power is significant enough to keep component prices low: there are large volumes of each module produced, and this is a powerful factor in negotiations.
All these considerations apply to enterprises/organizations as well, but for them, functional parts are organizational roles, functions are work practices, and constructive parts are organizational units performing services. This will be discussed in more detail in the "Methodology" and "System Management" courses.