FAQ on modeling - Logische Werkzeugebene

1. How do I model a database that does not belong to any application component?

What is meant here is probably a database system. A database system can be an application component in the broadest sense. In this case, however, an application component must first be defined, which serves as a shell, so to speak. A database system is then assigned to this application block. The application block is provided with block interfaces via which other application blocks can then access the database system.

2. Is it possible to create several database systems for one application block?

According to our meta model, there is no possibility of assigning several database systems to one application module. In our experience, this is not necessary, since the application modules known to us always have only one database system. However, it may well be possible for one application module to access several database systems. In this case, the database systems and the application modules that own them (see also FAQ 5.) must be modeled first. The access must then be modeled via block interfaces and communication relationships.

3. Are there modeling guidelines on the logical tool level for paper-based application modules?

4. When is an interface a user interface and when is it a component interface?

An interface is always a component interface when it is used to model a communication relationship to another application component. A user interface refers to the human-machine interaction and considers more software-ergonomic aspects.

5. Why is the message type linked to the object type in the object type/property dialog? Doesn't the message type belong to the record type or document type (e.g. message type "ADT message" - record type "Patient master data" instead of object "Patient")

According to our metamodel, there are three ways in which an object type can be represented at the logical tool level: as a message type, as a record type or as a document type. The representation as record type refers to the storage in a database system. The representation as message type refers to the communication between two computer-based application modules. The representation as document type refers to the storage in a document collection and the communication between two application modules, of which at least one is paper-based.

6. can I understand the master DBS as the database management system as it is named in the model browser?

No.

7. when is it necessary to model non-computer supported building block interfaces? (e.g. if something is first documented on paper and later captured with a computer-based application building block - power arrangement)

A typical example of data communication between a computer-based and a paper-based application component is the occurrence of media breaks. If one wants to model/see this, the following questions have to be asked for the interfaces: Tip: Since users are not usually modeled in the 3LGM² toolbox, the use of the computer-based application module is not explicitly modeled. So if a paper is printed, read and then destroyed, it is usually not modeled. Reading would also have been possible on screen. If this case is to be modeled, e.g. to confirm the suspicion of an unnecessarily high amount of paper, a paper-based application module "Operation" can be modeled with a document collection "Recycle Bin".

8. In my understanding, there are no interfaces that can be both send and receive interfaces. Nevertheless, the meta-model and the building set allow this. Why?

Our meta model allows one and the same interface to be both a sending and receiving interface. This is not obvious at first, since realistic interfaces are generally either send or receive interfaces. However, it should be considered that it will be desirable to model more abstractly. For example, if you only want to show that two application blocks communicate with each other in both directions, you will define an interface for each AB and connect them in both directions. The meta-model deliberately leaves open possibilities here, in order to enable the modeler to model his IS under different objectives and degrees of abstraction.

9. How can I assign its master DBS on the logical level to my database system?

This is not possible. See also 1.

10. ETNT is not offered for the record type, only for the document type. How can I then model this for two computer-based application modules?

This is intended. Behind it is the following: If we are in the purely computer-based area, the communication takes place exclusively via message types, an ETNT combination is therefore not necessary for the data record type. The data record type only represents how object types are stored. In the paper-based area, on the other hand, the representation form document type is used both for communication and for storing object types. Therefore, we also need an ETNT combination ( which should actually be called ETDT combination ).

11. In the properties dialog for software products in the model browser, the software products are assigned to tasks and not to application modules. Is this correct?

That is correct. In the metamodel this corresponds to the relationship 'can_support'. This enables you to model additional information about the software product itself. Not all tasks that a software product can support are actually supported after installation. This depends for example on the parameterization. Thus it is theoretically possible to determine whether additional tasks should not be supported by an application component based on a certain software product, for example to reduce the degree of heterogeneity.

12. Why are application programs assigned to software products and application modules? I thought application programs are adapted software products (esp. parameter settings,...)

An application component is controlled by an application program (relationship is_controlled_by in the meta model.) An application program is an adapted software product (relationship is based on in the metamodel). For the sake of simplicity, you can now assign a software product directly in the properties dialog of an application component, but this product is actually assigned to the application program of this application component. However, the modeling of these relationships is rather unintuitive and also incorrect. For example, it is currently possible to assign several software products in the properties dialog of an application component without seeing this in the properties dialog.