Designing function interface in the form of function prototype is an important skill in programming. In this article, we discuss the problems of designing function prototypes in the C programming language. This learning task requires performing 5 different steps. Students can make mistakes at each step. These mistakes can concern misconceptions of function's action, identification of data elements, determining of conceptual-level data types for data elements, data elements' directions, inconvenient naming of function and parameters, and syntax of the C language. Modern solutions for analyzing program code and checking student-written code do not detect all these mistakes in the function-interface design. Existing approaches are based on general solutions for seeking errors in program code so they cannot provide informative feedback about semantic mistakes in designing function interfaces. We propose developing an automatic tutor which should guide students through the process of designing function prototypes step by step, detecting and explaining mistakes at each step and providing hints to help fixing the found mistakes. The tutor should allow natural variability in the function interface. In order to deal with various possible representations of the data passed to and from function, the tutor should work with a formal subject-domain model and a model of the target programming language.

Keywords: automatic tutors, requirements for tutoring systems, introductory programming learning, tasks with complex result, multi-step tasks, online education, mixed education, automatic grading

An ontology is a formal, explicit specification of a shared conceptualization of some fragment of domain, which is understandable for both people and intelligent systems. However, it is rather complicated for a domain expert with limited ontology expertise to create complete and consistent ontology, which could answer required competency questions. In this paper we consider the approach with the use of ORM2-diagram as an intermediate model for creating an OWL2-ontology. This approach requires specialized conversion rules allowing to map ORM2-diagram into OWL2-ontology. In this study we revealed that existing conversion rules do not comply with ORM2-semantics. We improved existing conversion rules for Entity Type and Subtyping elements of ORM2 notation. Also we automated the process of mapping ORM2-diagram (consisting of base elements of ORM2 notation - Entity Type, Value Type, Subtyping, Unary Role, Binary Role) into OWL2-ontology as well. As result of this study, we developed a software component, which is part of plugin for ontology editor Protégé. This paper also describes an experiment that confirms the effectiveness of the developed module. It is proven that module allows to exclude mistakes encountered in conversion ORM2-diagram to OWL2-ontology and to reduce conversion time as well.

Keywords: explicit knowledge representation, visual model, intermediate model, ontology modeling, ontology, OWL2, ontological pattern, ORM (Object-Role Modeling), ORM diagram