Towards a Domain Model for Learning and Teaching

Oleg Shvets

1 a

, Kristina Murtazin

1 b

, Martijn Meeter

2 c

and Gunnar Piho

1 d

Department of Software Science, Tallinn University of Technology (TalTech), Akadeemia Str 15A, Tallinn, Estonia

LEARN! Research Institute, Vrije Universiteit Amsterdam, De Boelelaan 1105 1081 HV, Amsterdam, The Netherlands

Keywords:

Higher Education, Teaching, Domain Model, Domain Engineering, Model-Driven Architecture, Business

Archetypes and Archetype Patterns.

Abstract:

In software engineering, a domain model is a conceptual model that represents the concepts and relationships

within a particular domain (education, banking, transportation, etc.) by modelling the behaviour and data

of these concepts and relationships. This paper presents a novel domain model for learning and teaching in

higher educational institutions, addressing the evolving needs of digitized education systems. We integrate

concepts from domain engineering, model-driven architecture, and business archetypes to construct a compre-

hensive framework. Our model, developed by a team of experts from Tallinn University of Technology and

Vrije Universiteit Amsterdam, focuses on the interplay between various educational components, including

curriculum design, student assessment, and personalized feedback mechanisms. Two educational scenarios –

providing feedback on student assignments and managing workplace-based learning – are examined to evalu-

ate the model’s usability. Our contribution lies in offering a structured framework for modelling educational

processes, thereby paving the way for more universal and interoperable domain models and ontologies that

also support personalized learning and feedback.

1 INTRODUCTION

Digitalization has transformed the way students learn,

and teachers teach. It has enabled students to access

educational resources from anywhere in the world,

at any time, and at their own pace. Digitalization

has also made education more inclusive by providing

equal opportunities for disabled students. Automating

the learning process may revolutionize learning and

teaching further by reducing teachers’ workload and

providing students with personalized learning experi-

ences and feedback. However, some issues still need

to be addressed, such as the lack of digital literacy

among teachers and students, the lack of human in-

teraction and the lack of standardization in automated

assessments. By addressing these issues, we can en-

sure that the beneﬁts of digitalization and automation

of the learning process are available to everyone.

Domain modelling is a crucial step in the software

development process. It involves creating a concep-

tual model of the problem domain, which helps devel-

https://orcid.org/0000-0003-2171-3512

https://orcid.org/0000-0001-9605-756X

https://orcid.org/0000-0002-5112-6717

https://orcid.org/0000-0003-4488-3389

opers understand the system’s requirements and de-

sign an appropriate solution. It helps developers iden-

tify the key concepts, relationships, and constraints

relevant to the problem domain (Bjørner, 2006). In

healthcare, domain modelling is developing apace.

Due to healthcare systems and data interoperability

needs, different healthcare domain models exist, in-

cluding healthcare domain-related standards, e.g. ISO

13940 (ContSys, a system of concepts to support con-

tinuity of care) (ISO, 2015; S

oerd et al., 2023). In

education, however, the situation is different. We

only know one standard related to teaching and learn-

ing (Educational Organization (ISO, 2018)), and we

found only a few papers on Google Scholar related to

the educational domain model (e.g. (Sottilare et al.,

2016; Brusilovsky, 2016)).

ISO 21001:2018 is the only ISO standard that

is directly related to education. It speciﬁes require-

ments for a management system for educational orga-

nizations when such an organization needs to demon-

strate its ability to support the acquisition and devel-

opment of competence through teaching, learning, or

research. It also aims to enhance the satisfaction of

learners, other beneﬁciaries, and staff through the ef-

fective application of its management system, includ-

288

Shvets, O., Murtazin, K., Meeter, M. and Piho, G.

Towards a Domain Model for Learning and Teaching.

DOI: 10.5220/0012471400003645

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 12th International Conference on Model-Based Software and Systems Engineering (MODELSWARD 2024), pages 288-296

ISBN: 978-989-758-682-8; ISSN: 2184-4348

ing processes for improvement of the system and as-

surance of conformity to the requirements of learners

and other beneﬁciaries.

Sottilare et al. (Sottilare et al., 2016) present

a conceptual model of intelligent tutoring systems.

According to them, these have four main compo-

nents: the domain model, the student model, the tu-

toring model, and the user interface model. They

use the term ’domain model’, unlike the domain

model concept outlined in our current position paper,

for the ideal expert knowledge, including the bugs,

mal-rules, and misconceptions that students period-

ically exhibit; it contains the set of skills, knowl-

edge, and strategies/tactics of the topic being tu-

tored. The student model contains the cognitive, af-

fective, motivational, and other psychological states

students develop during learning. As the monitoring

of learner performance is primarily tracked in the do-

main model, the learner model is viewed as an over-

lay of the domain model. The tutor or pedagogi-

cal model takes the domain and learner models as

input and selects tutoring or pedagogical strategies.

The user interface interprets the learner’s communica-

tion and learning contribution through input (how stu-

dents get information) and output (how students per-

form assignments) media, e.g. text, diagrams, anima-

tions, agents, etc., including natural language interac-

tion like speech recognition and the sensing of learner

emotions. Our current position paper’s domain model

concept should ideally contain all four main compo-

nents proposed by Sottilare et al.

There are various proposed domain models focus-

ing on some aspects of learning and teaching like life-

long learning (Hermans, 2015), qualiﬁcation-based

learning (Then, 2020), curriculum design (Melill

et al., 2023), personalized feedback (Bogdanova and

Snoeck, 2019), and learning outcomes (Bogdanova

and Snoeck, 2017). Brusilovsky (Brusilovsky, 2016)

proposes a personalized guidance domain model for

students’ monitoring that helps enhance the learning

process’s overall effectiveness for individual students.

We aim to develop a general and universal domain

model for learning and teaching in higher education

institutions grounded in the abstract process domain

model. This model should not only encompass pro-

cess objectives and outcomes but should also integrate

a robust feedback mechanism. In this context, we are

guided by two pivotal research questions: a) Is the

creation of such a domain model feasible? and b) Is

the implementation of this domain model reasonable

and justiﬁable in terms of its practical applicability

and potential beneﬁts to the educational processes and

supporting information systems?

This paper proposes a ﬁrst draft of a simple and

generalized domain model for learning and teaching

in higher educational institutions based on the pro-

cess domain model. The proposed domain model is a

conceptual framework that deﬁnes and organizes the

key elements and concepts related to the teaching pro-

cess of a speciﬁc subject or topic. It provides a basis

for describing the learning content in the context of

domain knowledge, including the set of skills, knowl-

edge, strategies of the tutored topic, expert knowl-

edge, and misconceptions students may make. It

helps organize the education processes and provides

personalized management, support, and monitoring

of students.

The rest of the paper is structured as follows. In

Section 2, we explain how we designed the domain

model for learning and teaching. We propose and

explain the model in Section 3. In analysis and dis-

cussions Section 4, we explain why we designed the

model as we designed it. We also discuss two use

cases: work-based learning within higher education

and evaluating students’ assignments. We conclude

in Section 5.

2 METHODOLOGY

We follow archetypes and archetype patterns based

methodology of domain engineering (Piho, 2011),

(Piho et al., 2010a). This methodology is based on the

domain engineering methodology proposed by Dines

orner (Bjørner, 2006) and utilizes the Zachman

Framework (Zachman, 1987), (Piho et al., 2010b)

and archetypes and archetype patterns based model-

driven architecture (Arlow and Neustadt, 2003), (Piho

et al., 2012), (Piho et al., 2011b). The general idea of

the methodology is illustrated in Figure 1.

Figure 1: Zachman Framework with archetypes and

archetype patterns.

By asking Zachman Framework questions What,

How, Where, Who, When and Why, we design a

domain model using concepts of Things, Processes,

Locations, Persons, Events, and Strategies by using

common predeﬁned models (business archetype pat-

terns, AP) for products (including services), parties

Towards a Domain Model for Learning and Teaching

289

(organizations and persons) and party relationships,

orders and inventory, and quantity, money and rules.

There are two main theoretical principles that

we utilized when developing the archetypes and

archetype patterns we used in domain modelling for

learning and teaching: the item-type pattern by (Coad,

1992) and the system’s evolving pattern by Oei et

al.(Oei et al., 1994). According to the item-type pat-

tern, every concept in our system has a speciﬁable

type. This means, for instance, that every process

(e.g., study programme for the students admitted in

September 2023) has a process type (e.g., programme

curriculum from 2020). According to the system’s

evolving pattern, every item and its type has Valid-

From, ValidTo, Recorded, and Deleted date-time at-

tributes (S

oerd et al., 2023). The system’s evolving

pattern enables changes (e.g. a new curriculum ver-

sion) and auditable error corrections (e.g. some at-

tributes were incorrectly entered into the system) ac-

cording to the need.

While products, parties, orders, inventory, quan-

tity, money and rules archetype patterns (Piho, 2011)

are quite strict models of the same business concepts

hinted at by the names of these archetype patterns, the

following two things have to be explained in more de-

tails: a) how do we model business events with orders

and inventory; and b) how do we model business pro-

cesses with the party relationship archetype pattern.

Column 5 (when, events, Figure 1) describes all

business events related to the organization’s business

processes. Examples of these events are “a new or-

der from a customer”, “a plan is ready”, “some re-

source has reached the minimal acceptable limit”, or

“a new employee is hired”. Examples in the context

of higher education would be: “a student has been

admitted to university”, “a student has been enrolled

on the course”, “a student got his/her exam result”,

etc. All such business events should be logged. In

our domain model, we model all such business events

utilizing the order (what happened and when) and

the inventory (what has been changed) archetype pat-

terns. With the order archetype pattern, any request to

change something in the enterprise‘s inventory book

or in another book/list/registry, such as a student list,

has been recorded. This is why we utilize the order

archetype not only for the purchase and sale but also

for the entry of a speciﬁc grade in the student’s study

book.

Column 2 (how, processes, Figure 1) describes

business processes. Examples of business processes

are “buying”, “selling”, “producing”, “planning”,

“servicing”, “controlling”, “reporting”, “transport-

ing”, and so on. For modelling business processes,

we use the business process archetype pattern (Fig-

ure 3). As described earlier, the process model is de-

scribed by its elements (process, thread, task, action

and outcome) and their types (process type, thread

type, task type, action type and outcome type). Our

business process model metaphor is a subordinate‘s

report/feedback to a supervisor (e.g., students’ home-

work or assignments presented to the teacher). There-

fore, the central part of our model is tasks and task

types (inherited from the party relationship and party

relationship type, respectively) that specify commu-

nication/interaction/relationship between two parties

(persons, organizations, or even artiﬁcial agents) that

are “playing” some roles (e.g. student and teacher)

in the particular process or generally in the domain.

In our understanding, this metaphor is quite power-

ful for modelling different kinds of business processes

and even business plans, where a plan is nothing more

than an expected business process with expected out-

comes in the future. We utilized the business pro-

cess archetype pattern to develop a domain model for

learning and teaching in higher educational institu-

tions. We explain this in more detail in the analysis

and discussion part in Section 4.

In developing the domain model for learning and

teaching in higher educational institutions, we ﬁrst

identiﬁed the main concepts (e.g. teacher, student,

exam, class, etc.) and their relationships. During

this period, we conducted a systematic literature re-

view on work-based learning (Murtazin et al., 2020)

and of providing student feedback in e-learning sys-

tems (Shvets et al., 2020) and evaluated the adequacy

of learning outcomes of the work-based study pro-

grammes in regular interaction with stakeholders and

completed the preliminary analysis of the student and

tutor models. In this way, we got the ﬁrst draft of the

proposed domain model.

The domain model we propose in this position pa-

per (Figure 2) was designed by authors during a four-

day workshop within four iterative development cy-

cles, where each cycle lasted a day of intensive team-

work. This workshop exclusively involved the authors

of this paper, ensuring a focused and collaborative en-

vironment. Each day began with constructive criti-

cism of the previous day’s domain model version and

ended with a new version of the domain model by the

end of the workshop day.

Class diagrams illustrated in Figures 2 and 3 use

Visual Studio class diagrams notation instead of stan-

dard UML. This is because we utilized Test-Driven

Domain Modeling (Piho et al., 2011a) and are devel-

oping a domain model that is executable, unit-testable

and usable as class libraries in software development,

or as Martin Fowler pointed out, the model is usable

as an embedded or internal domain-speciﬁc language

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

290

(Fowler, 2010).

In Visual Studio class diagram notation, the

rounded rectangular objects are either classes (as in

Figure 2) or interfaces (as in Figure 3). The inheri-

tance relation notion is the same as in standard UML.

Two other relations in the ﬁgures are one-to-one nota-

tion (→) and one-to-many notation ().For instance,

when, in Figure 2, there is Programme  Student

means, that Programme consists of many Students. It

does not mean that the Student may be enrolled in

only one Programme.

In the current paper, we visualize and explain only

classes and relations between the classes and leave the

speciﬁcation of class attributes for future work.

3 A DOMAIN MODEL FOR

LEARNING AND TEACHING

Figure 2 visualizes the proposed domain model for

learning and teaching in higher educational institutes.

A Programme is a study programme with at-

tributes EnrolledStudents, Curriculum (describing the

content students must learn to get a diploma), and

Courses (describing the general plan of study sub-

jects taught in a particular study year and semester

of the study programme). Thus, the study programme

is composed of students admitted to the same curricu-

lum (e.g. Business Information Technology Master’s

at TalTech) in a given academic year (e.g. in 2023),

and these students are studying based on a speciﬁc

version of the curriculum approved for that academic

year, and these admitted students have a study pro-

gramme plan according to the study courses speciﬁed

in the Courses attribute.

The Curriculum speciﬁes the content the students

are learning during the study programme period. The

Curriculum has attributes of Content and Expected-

Outcomes. The Content speciﬁes the course syl-

labuses the students must learn, and the Expected-

Outcomes specify the competencies (skills, disposi-

tions, and knowledge) the students must gain during

the study programme period.

A study Programme normally has many Courses

the students must pass during the study programme

period. Every Course in the study Programme, like

the study Programme itself, has the EnrolledStudents

attribute. These are the students who have registered

for this Course (e.g. “programming fundamentals”)

in a given semester (e.g. 2023 fall semester). The

content of every Course is speciﬁed in the attribute

Syllabus. The ExpectedOutcomes of the Syllabus are

specifying the Curriculum competencies in detail. In

addition, the Course can have one or more course or-

ganizers (professor, lecturer, assistant, etc.; not shown

in Figure 2) and one or more Units.

A Unit is a period in the Course (for example, a

study week or a study month, as required), and during

that Unit, one of the topics (Topic) of the course is

addressed. Different activities (Lecture, Lab, Assess-

ment, Project, etc) can be organized during the study

Unit, where the Task attribute speciﬁes the content of

these activities.

While the Programme and Course are not spe-

ciﬁc to the particular student (Student) but are spe-

ciﬁc to a student’s group (EnrolledStudents), the Unit

and, therefore, the Activity and ActualOutcome, are

student-speciﬁc. This means that for Unit, Activity

and ActualOutcome classes, there is always an at-

tribute Student (not shown in the Figure.2) that speci-

ﬁes the student whose period of study (the Unit) it is,

who performed (or performs) the activities (Activity)

and who got the actual outcomes (ActualOutcomes).

The Topic is divided into learning Tasks. The Task

can be a study instruction (Instruction), Exam, As-

signment, etc., and consists of sub-tasks (Content).

Sub-tasks can be questions (Question) or any similar

that, through possible learning outcomes (Possible-

Outcomes), are related and should contribute to the

gaining competencies (Competency) and can be used

as a check during the learning process. For instance,

if the sub-task (SubTask) is some assessment ques-

tion (Question), the possible outcomes (ResponseCat-

egory) from the learner’s point of view is a correct or

wrong answer if the question needs a simple “yes” or

“no” answer.

A task may have both the entrance and passing

rules. For instance, the passing rule for an assessment

can be to get at least 6 points out of a maximum of

10, and the entrance rule for the course’s ﬁnal exam

can be the requirement of passing all the assessment

tasks according to the assessments’ passing rules dur-

ing the same learning unit or all the learning units of

the course.

Before explaining the Activity class’s Entrance,

Passing and Outcomes attributes, we discuss the

GradeBook and Grade classes.

Every student has a GradeBook, where all the

Grades are recorded. Every Grade is composed of

the student’s results (Result), and every Result is eval-

uated by one of the course teachers (not shown in

Figure.2). In addition, every Result is related to the

Activity (e.g. ﬁnal exam, project, assessment, etc.)

and records the student’s actual outcomes for all the

sub-tasks related to the Task that describes the content

of the Activity. Therefore, in case the activity (Activ-

ity) is the assessment (Assessment), and the type of

this assessment (Task) is an exam (Exam), then the

Towards a Domain Model for Learning and Teaching

291

Figure 2: Domain model for learning and teaching.

student’s actual outcomes are the answers to the exam

questions (Question), that the evaluator evaluated ac-

cording to the sub-tasks (Question) possible outcomes

(ResponseCategory).

The results thus evaluated (ActualOutcomes) are

used to assign the needed arguments (RuleContext)

to calculate the rule value (true/false) of the Task to

determine whether a particular student can participate

in the given activity or whether he or she has met the

conditions required to complete the activity.

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

292

These evaluated results (ActualOutcomes) are

also used to give a student personalized feedback

(Feedback). Such personalized feedback comprises

suggestions (Suggestion), where each suggestion can

be a predeﬁned response (Response) based on the re-

sponse category (ResponseCategory) of the student’s

actual outcome.

4 ANALYSIS AND DISCUSSIONS

Here, we present a preliminary analysis of the pro-

posed domain model. To perfect the model, more

detailed analysis and evaluation are needed. Cur-

rently, we propose only a rough evaluation by show-

ing three use cases. We ﬁrst show how a typical

university course would be described in the domain

model. Then, we explain that work-based learning

can also be described using this mode. Finally, we

illustrate model compatibility with personalized feed-

back on students’ assignments and homework. In the

descriptions, the capitalized words refer to classes in

Figure.2.

4.1 A Typical University Course

As an example of a typical university course, the

Course “inclusive education” at a large research uni-

versity consists of lectures, labs and seminars, an

exam and a practical assignment. The Syllabus of

the course describes two Topics, each covered by one

Unit. The ﬁrst Topic covers theory. Its associated

Unit consists of the following Activities: 12 Lectures

and one Assessment. The Task within that last Activ-

ity is an Exam. This Task contains many SubTasks of

class Question, with each ResponseCategory linked

to these questions being linked to a Competency that

is described in the Syllabus as learning outcomes of

the Course.

The second Topic is linked to the competency to

write individualized learning plans for students with

special educational needs. This Topic is linked to a

Unit consisting of the following Activities: Labs and

an Assessment. The latter contains a Task that is an

Assignment. Its ActualOutcome is graded according

to a Rule for passing (formalized in a rubric).

Passing both the Exam and the Assignment cre-

ates a Result that is translated into a Grade, which is

registered in the GradeBook of an individual Student,

helping that Student complete the Course and later the

Programme.

4.2 Work-Based Learning

Work-based learning is an educational approach that

enhances students’ learning experiences by connect-

ing them to real-world work environments. Our do-

main model is compatible with work-based learning.

Work-based learning is often informal, but the formal-

ized learning outcomes could help evaluate the rele-

vance of industry (or company) projects to the uni-

versity curricula and specify the objectives a student

can achieve through the Work-based projects. The

following is based on job-based study in the Bach-

elor of Business Information Technology curriculum

of Tallinn University of Technology.

Regarding work-based learning, the course Unit

is one study semester (16 weeks) during which stu-

dents work on a work-based project (Topic). The con-

tent of the work-based project, the teaching/learning

methods, the course activities/student’s reﬂections,

the learning outcomes (ExpectedOutcomes) and the

evidence of learning outcomes, assessment criteria

and designs are speciﬁed in the Syllabus. The work-

based learning Activity is a project. The Tasks could

be Instruction (in case students need to study some

learning materials or read a book during the project),

Assessment (the project report, Demo) or Exam (the

defence of the conducted project). The Tasks could

consist of sub-tasks (Content). Sub-tasks can be ques-

tions (Question) or assessment criteria that are related

to the competencies (Competency) and can be mea-

sured and evaluated through possible learning out-

comes (PossibleOutcomes) - how the students can ap-

ply knowledge, skills and social or methodological

abilities in a work situation. Rules (Rule) are all pos-

sible requirements, conditions and prerequisites. Ac-

tualOutcome are learning outcomes achieved by one

particular student. The Results related to ActualOut-

comes could be the personal and professional devel-

opment plans, learning diaries, learning logs, pre-

sentations, interviews or reﬂective reports, and as-

sessments of learning outcomes, assessing students’

achievements according to criteria. The work-based

course grade (Grade) comprises the students’ results

(Result).

4.3 Personalized Feedback

Teacher feedback provided to learners in real-time

is crucial for their knowledge and skills acquisition.

Feedback (e.g. Corrective feedback) helps learners

improve their understanding and performance on var-

ious tasks (e.g. exam) (Hattie and Timperley, 2007).

However, providing real-time feedback at an individ-

ual level is often infeasible, considering limited teach-

Towards a Domain Model for Learning and Teaching

293

Figure 3: Business process archetype pattern.

ing resources. Therefore, it is very important to de-

velop systems which can support learners at any place

and time by generating personalized feedback auto-

matically (Deeva et al., 2021).

Feedback can take both formal and informal forms

and is often provided by persons in such roles as

teachers, employers (e.g. in work-based learning),

or peers. Feedback can be delivered through various

means, such as written or verbal comments, assess-

ments, evaluations, or observations. In the current do-

main model, all these means are Suggestions.

As Feedback is an integral part of the educational

process, ensuring that learners have the guidance and

support they need to progress and achieve their objec-

tives, in our domain model, every suggestion (Sugges-

tion, part of the Feedback) to the student is an evalua-

tor’s response (Response) to the student’s actual out-

come (ActualOutcome).

Hypothetically, and we claim it but cannot yet

prove it, the proposed model can also be used to auto-

mate the feedback. If the assessment or homework

(Task) is divided into such assignment tasks (Sub-

Task; for example, calculating the hypotenuse of a

right-angled triangle by catheters), where the result of

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

294

performing or solving a task can be divided into very

simple categories of responses (ResponseCategory,

for example: knows or does not know the Pythagoras

formula; knows or does not know what hypotenuse

is; can or cannot calculate squares of numbers; etc.),

then it should be possible to predeﬁne corresponding

feedback responses (Response), based on these cate-

gories (ResponseCategory), which are then are used

to generate automated/semi-automated feedback with

suggestions according to the student’s actual answer

(ActualOutcome).

4.4 The Business Process Archetype

In the context of our proposed domain model for

learning and teaching, a signiﬁcant aspect is its com-

patibility with the Business Process Archetype Pat-

tern (Figure. 3, (Piho, 2011; Piho et al., 2014)). This

compatibility is crucial as it enables the model to align

with established business process management frame-

works, thus facilitating its integration into existing ed-

ucational management systems.

The backbone of the model comprises the Pro-

gramme, Course, Unit, Activity, and ActualOutcome

classes. These classes correspond to the Process (Pro-

gramme), Thread (Course), Task (Unit), Activity (Ac-

tivity) and Outcome (ActualOutcome) classes in the

abstract process archetype pattern. The essence of this

compatibility lies in the model’s ability to map educa-

tional processes into the general business archetype

pattern. This mapping allows for a structured ap-

proach to managing educational processes, akin to

managing business processes.

Moreover, the model’s integration with the Busi-

ness Process Archetype Pattern supports scalability

and adaptability. It provides a structured yet ﬂexi-

ble framework that can accommodate different edu-

cational settings and requirements. This adaptability

is particularly beneﬁcial in higher education, where

diversity in courses and teaching methodologies is

prevalent.

Furthermore, this compatibility ensures that the

model can effectively interface with other systems

and components of an educational institution, such

as administrative systems, learning management sys-

tems, and student information systems. It facilitates

seamless data ﬂow and interoperability, which are vi-

tal for the efﬁciency and effectiveness of digitalized

educational environments.

5 CONCLUSIONS

We proposed a domain model for learning and teach-

ing based on the principles of domain engineering, the

Zachman Framework, and archetypes and archetype

patterns. This model is designed by educational do-

main experts, who teach students and develop study

programmes and curricula daily. In addition, the

model developers in question have sufﬁcient knowl-

edge of modelling techniques and principles. The

model was developed over four iterative cycles, with

each cycle starting with a criticism of the existing

model by analyzing its bottlenecks and ending with

a new and improved version of the model. Although

a thorough validation and veriﬁcation of the model is

still in progress, a preliminary evaluation of the model

has been carried out in this paper by analyzing the

model from the ordinary study course, work-based

learning perspectives, and from the perspectives of

feedback on students’ assignments and homework.

The next phase of our research will focus on ex-

tensive validation and reﬁnement of the proposed do-

main model. We plan to further reﬁne the compatibil-

ity with the Business Process Archetype Pattern in fu-

ture iterations of the model. Our aim is to enhance the

model’s ability to represent educational processes and

provide actionable insights for continuous improve-

ment in teaching and learning. This enhancement will

involve deeper integration with the Business Process

Archetype Pattern, ensuring that the model remains

both robust in its theoretical foundation and practical

in its application.

Moreover, we aim to conduct empirical studies in

diverse educational settings to evaluate the model’s

practicality and effectiveness in real-world scenarios.

This will include testing the model’s adaptability to

various curricula and its efﬁcacy in providing per-

sonalized student feedback. Additionally, we plan to

explore the integration of advanced technologies like

artiﬁcial intelligence and machine learning to further

enhance the model’s capabilities for automated feed-

back and adaptive learning strategies. These efforts

are expected to yield a more robust and versatile do-

main model that can signiﬁcantly contribute to the

digital transformation of higher education.

ACKNOWLEDGEMENTS

This work in the ‘ICT programme’ project was sup-

ported by the EU through the European Social Fund.

We thank the anonymous evaluators for their valuable

feedback.

Towards a Domain Model for Learning and Teaching

295

REFERENCES

Arlow, J. and Neustadt, I. (2003). Enterprise patterns and

MDA: building better software with archetype pat-

terns and UML. Addison-Wesley, Object Technology

series, Boston, ...

Bjørner, D. (2006). Software Engineering 3: Domains, re-

quirements, and software design. Springer Science &

Business Media, Berlin Heidelberg.

Bogdanova, D. and Snoeck, M. (2017). Domain mod-

elling in bloom: Deciphering how we teach it. In The

Practice of Enterprise Modeling: 10th IFIP WG 8.1.

Working Conference, PoEM 2017, Leuven, Belgium,

November 22-24, 2017, Proceedings 10, pages 3–17.

Springer.

Bogdanova, D. and Snoeck, M. (2019). Use of personal-

ized feedback reports in a blended conceptual mod-

elling course. In 2019 ACM/IEEE 22nd International

Conference on Model Driven Engineering Languages

and Systems Companion (MODELS-C), pages 672–

679. IEEE.

Brusilovsky, P. (2016). Domain modeling for personalized

guidance. Army Research Laboratory.

Coad, P. (1992). Object-oriented patterns. Communications

of the ACM, 35(9):152–159.

Deeva, G., Bogdanova, D., Serral, E., Snoeck, M., and

De Weerdt, J. (2021). A review of automated feed-

back systems for learners: Classiﬁcation framework,

challenges and opportunities. Computers & Educa-

tion, 162:104094.

Fowler, M. (2010). Domain-speciﬁc languages. Addison-

Wesley Professiona, New Tork.

Hattie, J. and Timperley, H. (2007). The power of feedback.

Review of educational research, 77(1):81–112.

Hermans, H. (2015). Openu: design of an integrated system

to support lifelong learning.

ISO (2015). 13940:2015 Health informatics - system of

concepts to support continuity of care. International

Organization for Standardization, Geneva. Switzer-

land.

ISO (2018). 21001:2018 Educational organiza-

tions.Management systems for educational or-

ganizations.Requirements with guidance for use.

International Organization for Standardization,

Geneva. Switzerland.

Melill

an, A., Cravero, A., and Sep

ulveda, S. (2023). Soft-

ware development and tool support for curriculum de-

sign: A systematic mapping study. Applied Sciences,

13(13):7711.

Murtazin, K., Shvets, O., and Piho, G. (2020). Literature re-

view on work-based learning. In 2020 IEEE Frontiers

in Education conference (FIE), pages 1–8. IEEE.

Oei, J. H., Proper, H. A., and Falkenberg, E. D. (1994).

Evolving information systems: meeting the ever-

changing environment. Information Systems Journal,

4(3):213–233.

Piho, G. (2011). Archetypes based techniques for develop-

ment of domains, requirements and software: towards

LIMS software factory. PhD thesis, Tallinn University

of Technology.

Piho, G., Roost, M., Perkins, D., and Tepandi, J. (2010a).

Towards archetypes-based software development. In

Sobh, T. and Elleithy, K., editors, Innovations in

Computing Sciences and Software Engineering, pages

561–566, Dordrecht. Springer.

Piho, G., Tepandi, J., Parman, M., Puusep, V., and Roost,

M. (2011a). Test driven domain modelling. In

2011 Proceedings of the 34th International Conven-

tion MIPRO, pages 576–581. IEEE.

Piho, G., Tepandi, J., and Roost, M. (2010b). Domain anal-

ysis with archetype patterns based zachman frame-

work for enterprise architecture. In 2010 Interna-

tional Symposium on Information Technology, vol-

ume 3, pages 1351–1356, New York. IEEE.

Piho, G., Tepandi, J., and Roost, M. (2011b). Evaluation of

the archetypes based development. In Databases and

Information Systems VI, pages 283–295. IOS Press,

Amsterdam.

Piho, G., Tepandi, J., and Roost, M. (2012). Archetypes

based techniques for modelling of business domains,

requirements and software. In Information Modelling

and Knowledge Bases XXIII, pages 219–238. IOS

Press, Amsterdam.

Piho, G., Tepandi, J., Thompson, D., Tammer, T., Parman,

M., and Puusep, V. (2014). Archetypes based meta-

modeling towards evolutionary, dependable and inter-

operable healthcare information systems. Procedia

Computer Science, 37:457–464.

Shvets, O., Murtazin, K., and Piho, G. (2020). Providing

feedback for students in e-learning systems: a litera-

ture review, based on ieee explore digital library. In

2020 IEEE global engineering education conference

(EDUCON), pages 284–289. IEEE.

oerd, T., Kankainen, K., Piho, G., Klementi, T., and Ross,

P. (2023). Towards speciﬁcation of medical processes

according to international standards and semantic in-

teroperability needs. In MODELSWARD, pages 160–

167.

Sottilare, R. A., Graesser, A. C., Hu, X., Olney, A., Nye,

B., and Sinatra, A. M. (2016). Design recommen-

dations for intelligent tutoring systems: Volume 4-

domain modeling, volume 4. US Army Research Lab-

oratory.

Then, M. (2020). Supporting qualiﬁcations-based learn-

ing (QBL) in a higher education institution’s IT-

infrastructure. PhD thesis, Dissertation, Hagen, Fer-

nUniversit

at in Hagen, 2020.

Zachman, J. A. (1987). A framework for information sys-

tems architecture. IBM systems journal, 26(3):276–

292.

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

296