【正文】 Stevens, 2021) was used as the strategy for defining the model of processes and data in the development of PROTECTOR, and UML for the software development analysis phase. The task of visual modeling of the system is to define the objects and logic of the real system using the adopted graphic notation. Visual Studio was chosen as the programming environment for the development of PROTECTOR. UML has been used as the most appropriate notation, and the system’s architecture was conceived in the form of a threelevel class diagram. This architecture supports well the objectoriented approach in model development for plex applications. Its main characteristic is a separation of the domain model, which is represented by business services and data services, from user interface, represented by user services. Fig. 4 depicts the threetiered service model of PROTECTOR. Fig. 4. Threetiered service model of PROTECTOR. The nine classes identified within the user services of PROTECTOR represent its interface forms. They are used for data manipulation (entering, viewing and searching the data), textual and graphical presentation of results and munication with other modules in PROTECTOR (expert system and neural work). The classes related to user services municate with classes at the business service level by sending messages that initiate the execution of specific applications. Two interface forms belonging to user services are shown in Fig. 5. They enable text search and editing, munication with the database, creation of business diagrams, etc. Fig. 5. Interface forms of PROTECTOR. Three classes were identified within the business services, all of them are Visual Basic application modules and they are used for safety assessment. In Fig. 6 an activity diagram depicts the dynamic model of one of these classes the Neuro class. This class includes specific procedures based on the model of permitted time determination for specified level of vibration using a neural work and linear interpolation. Fig. 6. Activity diagram for dynamic model of Neuro class Data services provide data maintenance, data access and modification functions. In view of the plexity of the PROTECTOR system’s global model data structure, which had to model all relevant parameters of plex surface coal mine safety analysis, the design and realization of the database was executed in the MSAccess relational database management system. The system offers safe data archiving for plex data models as this one, as well as all procedures for data manipulation. The use of SQL as a standard query language for data manipulation secures the openness of the hybrid system PROTECTOR for a connection with different environments. Fig. 7 depicts the structure of the database relevant to PROTECTOR through the MSAccess Relationships panel. Fig. 7. Database structure of PROTECTOR. PROTECTOR was developed using an expert systems shell, the KAPPAPC applications development system. KAPPAPC is a MS Windows application which provides a wide range of tools for constructing and using applications by means of a highlevel graphical environment which generates standard C code. In the KAPPAPC system, the ponents of the domain are represented by objects that can be either classes or instances within classes. The relationships among the objects in a model can be represented by linking them together into a hierarchical structure. Thus the modified OOA model based on the strategy for evaluation of the general safety state of the surface coal mine could be easily mapped onto the appropriate elements of KAPPAPC. Objectoriented programming tools within KAPPAPC were used to endow PROTECTOR objects with methods that specify what objects can do. First the objects and methods for the knowledge base were constructed. Then mechanisms were build that specify how objects should behave and that can reason about the objects by using rules. Each rule specifies a set of conditions and a set of conclusions to be made if the conditions are true. The conclusions may represent logical deductions about the knowl edge base or specifications of how it changes over time. Each rule is a relatively independent module, which made it possible to build the reasoning systems gradually, rule by rule. The classes and objects of the modified OOA model were transformed to classes and instances in the KAPPAPC system as shown in the system’s object browser (Fig. 8). The object browser shows also classes that KAPPAPC generates for each application, such as Root, Image and KWindow. Fig. 8. The KAPPAPCObject Browser for PROTECTOR Classes/instances are described using the class/instance editor, while slot facets are defined by means of the slot editor. Slots represent class attributes while methods in the class/instance editor account for both methods and IFTHEN rules related to a class in the modified OOA model. As an example consider the Gas class given in Fig. 9. Fig. 9. The Gas Class. The class has a parent class MineEnviron and six slots. Five methods are listed. The first three are numerical procedures (CalcFakGas, CalcFakMix, CalcHlpFMix) used for calculating the value of attributes FakGasa and FakMix and the remaining (CalcKatME, CalcEstimate) contain rules for the evaluation of the mine environment on basis of several parameters and their mutual relationships. Since all rules in the system do not have to be related to particular objects KAPPAPC offers the possibility of specifying rules independently, using a rule editor. The problemsolving process in PROTECTOR unfolds by means of the KAPPAPC backward chaining inference engine. Goals to be satisfied by backward chaining are defined by means of the goal editor. The goals in PROTECTOR pertain to estimation of different parametervalues. Goals can also be gene