Submitted by
Stefan Nadschl¨ager MSc Submitted at Institut f¨ur Anwendungsorientierte Wissensverarbeitung Supervisor and First Examiner A.Univ.-Prof. Dipl.-Ing. Dr. Josef K¨ung Second Examiner Ao.Univ.Prof. Dr. Ste-fan Biffl 09 2019 JOHANNES KEPLER UNIVERSITY LINZ Altenbergerstraße 69 4040 Linz, ¨Osterreich
Application
of Architecture and
Design Patterns
in the context of
Knowledge Processing or
Knowledge Based
Systems
Doctoral Thesis
to obtain the academic degree of
Doktor der technischen Wissenschaften
in the Doctoral Program
Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die vorliegende Dissertation selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die wörtlich oder sinngemäß entnommenen Stellen als solche kenntlich gemacht habe. Die vorliegende Dissertation ist mit dem elektronisch übermittelten Textdokument iden-tisch.
September, 2019
——————————————————-Stefan Nadschläger
Abstract
Knowledge is a precious good for a company. It has to be preserved and extended because it can provide advantages over competitors. Modern technologies allow to apply knowl-edge and even extend it by using methods and techniques from the domain of knowlknowl-edge processing. Even though knowledge processing has been around for more than forty years, no documentation, or architectural guideline, exists for the development (especially design and implementation) of homogeneous high-quality systems. Developing knowledge pro-cessing systems is a complex task, requiring an architecture and data structures differing from them of (well-documented) enterprise applications, and having to deal with (often complex) processing algorithms. To preserve experience and to build new systems based on identified best practices, some form of documentation is necessary.
In this thesis, a first step towards an architectural guideline for the development of knowl-edge processing systems is made. It provides resources for software developers and re-searchers on the development of knowledge processing systems following enterprise appli-cation quality standards. Firstly, it eases the development of complex knowledge processing systems and secondly, it documents best practices and experiences.
The design pattern concept is familiar to most software developers. Therefore, it was cho-sen as the foundation of an architectural guideline. Especially two questions are answered: Which existing design patterns can be applied to knowledge processing development (re-ducing the large number of existing design patterns to choose from) and which "new" de-sign patterns can be mined and identified in existing knowledge processing systems? To answer these questions, existing knowledge processing systems / frameworks from re-search and economy have been selected and analysed. Suitable design patterns from the domain of enterprise applications, appropriate for knowledge processing system develop-ment, were selected, as well as object-oriented design patterns. Moreover, design patterns specifically for knowledge processing systems were defined and pattern candidates have been identified.
To evaluate the need and benefits of an architectural guideline, a study has been conducted. Participants were requested to create a knowledge processing system based on a simple inference algorithm template. As an example, an ATM had to be implemented using only rules and facts. At first, no additional material or help was provided to the participants. The result showed the difficulty of implementing such a system. The quality of the
implemen-tation was not good and results, different in design and implemenimplemen-tation, were handed in. After providing material, presented in this thesis, to the participants, the quality improved significantly, and every result was based on a sound architecture.
The results of this thesis are (1) a smaller catalogue of object-oriented design patterns for knowledge processing systems, (2) identified commonalities between the design and im-plementation of enterprise applications and knowledge processing systems, (3) enterprise application design patterns that can also be used in the context of knowledge processing and (4) a pattern language especially for knowledge processing systems.
Kurzfassung
Wissen ist ein wertvolles Gut für Unternehmen. Es muss bewahrt und erweitert werden, denn es kann viele Vorteile gegenüber Mitbewerbern bringen. Mit Hilfe von modernen Methoden aus dem Bereich der Wissensverarbeitung, kann dieses Wissen aktiv eingesetzt und sogar erweitert werden. Obwohl das Gebiet der Wissensverarbeitung bereits seit mehr als 40 Jahren existiert, gibt es bis heute keine vollständige Dokumentation, oder Anleitung für eine Softwarearchitektur (besonders für Design und Entwicklung), um eine einheitliche hochqualitative Architektur von wissensverarbeitenden Systemen zu gewährleisten. Die Entwicklung von wissensverarbeitetenden Systemen ist eine komplexe Aufgabe, die sich mit von typischen Unternehmensanwendungen abweichenden (gut dokumentierten) Ar-chitekturen und Datenstrukturen beschäftigt und auch die Integration von (oftmals kom-plexen) wissensverarbeitenden Algorithmen beinhaltet. Um Erfahrungen und bewährte Vorgehensweisen zur Entwicklung neuer Systeme zu bewahren, müssen diese in einer geeigneten Form dokumentiert werden.
In dieser Dissertation wird ein erster Schritt zu einer Anleitung für eine Softwarearchitek-tur zur Entwicklung von wissensverarbeitenden Systemen gesetzt. Sie enthält Ressourcen (für Software Entwickler und Forscher) um wissensverarbeitende Systeme mit der Qualität und den Standards von Unternehmensanwendungen zu entwickeln. Dadurch wird einer-seits die Entwicklung solcher Systeme einfacher, anderereiner-seits werden so auch gemachte Erfahrungen und gute Vorgehensweisen dokumentiert.
Das Konzept der Entwurfsmuster ist den meisten Softwareentwicklern bekannt. Daher wurde dieses Konzept als Grundlage für die Architekturanleitung gewählt. Insbesondere zwei große Fragen werden behandelt: Welche existierenden Entwurfsmuster können für die Entwicklung von wissensbasierten Systemen eingesetzt werden (um die Auswahl aus der großen Menge von existierenden Patterns zu erleichtern)? Welche neuen Entwurfsmuster können in existierenden wissensverarbeitenden Systemen identifiziert werden?
Um diese beiden Fragen zu beantworten, wurden wissensverarbeitende Systeme aus Forschung und Wirtschaft und spezielle Frameworks ausgewählt und analysiert. Geeignete Patterns aus dem Bereich der Unternehmensanwendungen zur Entwicklung von wissensbasierten Systemen, sowie objektorientierte Patterns, wurden ausgewählt. Außerdem wurden Pat-terns, speziell für Entwicklung von wissensverarbeitenden Systemen definiert und weitere Pattern Kandidaten identifiziert.
Um die Notwendigkeit und die Vorteile einer solchen Architekturanleitung zu evaluieren, wurde eine Studie durchgeführt. Die TeilnehmerInnen wurden gebeten ein wissensverar-beitendes System zu entwickeln, welches auf einem einfachen Inferenzalgorithmus basiert. Als Beispiel musste nur mit Fakten und Regeln ein "Geldautomat" entwickelt werden. Zuerst wurde kein zusätzliches Material oder Hilfsmittel zur Verfügung gestellt. Das Ergebnis zeigte die Schwierigkeiten auf, so ein System zu implementieren. Die Qualität der einzel-nen Systeme war schlecht und sehr unterschiedliche Lösungen, hinsichtlich Design und Implementierung, wurden eingereicht. Nachdem zusätzliches Material (welches in dieser Dissertation vorgestellt wird) den Teilnehmern zur Verfügung gestellt wurde, hat sich die Qualität signifikant erhöht und die Abgaben wiesen eine verständliche gemeinsame Ar-chitektur auf.
Die Ergebnisse dieser Dissertation bilden (1) ein kleinerer Katalog von objektorientierten Entwurfsmustern für Frameworks wissensverarbeitender Systeme, (2) eine Liste von Gemein-samkeiten zwischen Unternehmensanwendungen und wissensverarbeitenden Systemen, (3) Entwurfsmuster von Unternehmensanwendungen, die auch in der Entwicklung von wissensverarbeitenden Systemen eingesetzt werden können, sowie (4) eine Mustersprache speziell für wissensverarbeitende Systeme.
Acknowledgements
Firstly and foremost, I would like to express my sincere gratitude to my advisor A.Univ.-Prof. Dr. Dipl.-Ing. Josef Küng for the continuous support of my PhD study, even though it took a bit longer. His guidance and knowledge made this thesis possible in the first place. Thanks for providing enough freedom besides projects to work on this thesis. Moreover, I want to thank my second supervisor Ao.Univ.Prof. Dr. Stefan Biffl and my fourth exam-iner A.Univ-Prof. Dr. Paul Grünbacher for their valuable input during discussions in the "research methods seminar".
Besides my advisor, I also want to thank my workmates, both from the institute, as well as the FAW GmbH, for their understanding in stressful phases and also for their support, especially in paper writing and the evaluation phase.
All my collegues from the institute I had and have the chance to work with (in chrono-logical order of their appearence): Marina Braumann, Christian Hanusch, Simon Wagner, Hilda Kosorus, Erik Sonnleitner, Katrin Straßl, Jan Kubovy, Andreas Pomarolli, Markus Jäger, Christian Huber, Pablo Gomez-Perez, Trong Nhan Phan, Daniel Hofer. Last, but not least, Andreas Dreiling and Monika Neubauer.
Special thanks go to Dagmar Auer and Markus Jäger for their valuable feedback and efficient support in paper writing and their fruitful discussions during projects.
And of course, thanks to all my former and current colleagues from the FAW GmbH: Knud Steiner, Daniel Jabornig, Simon Thalbauer, Hannes Gindl, Stefan Parzer, Wolfgang Köppl, Stefan Wagner, Peter Regner, Melanie Wallner, Simon Wagner, Robert Starzer, Endre Szaz-Revai, Kinga Szabo, Thomas Moser, Evelyn Forstner, Manuel Essmeister, Florian Wurm, Bernd Landgraf, Dominik Stadler, Lisa Breitenfellner, Elisa Rusz, Florian Pössl, Michael Probst, Reinhard Stumptner, Sohaib Ijaz, Shavan Omar, Massimiliano Mele.
I also want to thank my family and friends, especially and in first place my mother Gisela Nadschläger: For providing me the freedom to work and forbearing the one or other helpful hand, for giving me the opportunity to study and all her support during all my educational years. Moreover, I would like to thank Manuel Graf, always reminding me to take breaks and helping me to spend them wisely.
Moreover, in times when the nerves are on edge, I also have to thank my two cats Salem (RIP) and Lupo, for calming me down and bringing me back on track.
Gender-neutral Formulation
For reasons of easier readability, the usual male language form is used for personal nouns and pronouns in this thesis. However, this does not imply any discrimination of the female gender, but should be understood as gender-neutral in the sense of linguistic simplification.
Contents
Eidesstattliche Erklärung ii Abstract iv Kurzfassung vi Acknowledgements viii 1 Introduction 11.1 Knowledge Processing Systems . . . 2
1.2 Design Patterns . . . 4
1.3 Motivation . . . 4
1.3.1 Research Gap . . . 5
1.3.2 Empirical Study . . . 6
1.3.3 Application areas . . . 6
1.3.4 Design Patterns and Knowledge Processing . . . 7
1.4 Research Questions . . . 8
1.5 Methodology . . . 10
1.6 Contribution . . . 11
1.7 Dissertation outline . . . 13
2 Definitions and Related Work 15 2.1 Knowledge Processing and Knowledge Based Systems . . . 15
2.1.1 Data, Information and Knowledge . . . 15
2.1.2 Definition of Knowledge Systems . . . 16
2.2 Design Patterns . . . 21
2.2.1 History . . . 21
2.2.2 Pattern Description . . . 23
2.2.3 Classification . . . 26
2.2.4 Organization of patterns . . . 28
2.2.5 Design pattern selection . . . 29
2.2.6 Summary . . . 29
2.3 Related Research . . . 30
2.3.1 Search Methodology . . . 30
2.3.2 Knowledge Based System Architecture . . . 31
2.3.3 Design Patterns . . . 34
2.3.4 Design Patterns for Knowledge Processing Systems . . . 34
2.3.5 Summary . . . 35
2.4 Systems and frameworks to be analysed . . . 35
2.4.1 Research Project Prototypes . . . 35
2.4.2 Development of a knowledge processing system . . . 38
2.4.3 Knowledge Processing Systems . . . 41
3 Analysis of OO patterns 47 3.1 Methodology . . . 48
3.2 Design Patterns Analysis . . . 50
3.2.1 Factory Method . . . 51 3.2.2 Singleton . . . 52 3.2.3 Adapter . . . 52 3.2.4 Decorator . . . 53 3.2.5 Proxy . . . 54 3.2.6 Template Method . . . 55 3.2.7 Strategy . . . 56 3.2.8 Observer . . . 58 3.3 Discussion . . . 59 3.3.1 Abstract Factory . . . 61 3.3.2 Chain of Responsibility . . . 61
3.3.3 Command . . . 62
3.3.4 Iterator . . . 62
3.3.5 Visitor . . . 63
4 Design Pattern Collection 65 4.1 Definition Enterprise Application . . . 65
4.2 Common Aspects . . . 67
4.2.1 Data and its access . . . 69
4.2.2 Parallelism and Cloud . . . 69
4.2.3 Integration of external and internal components . . . 69
4.2.4 Server Side development . . . 70
4.3 Architecture and Design Patterns . . . 71
4.3.1 Definitions . . . 71
4.3.2 Data Access . . . 72
4.3.3 Integration of components . . . 74
4.3.4 Parallelism and Cloud . . . 78
4.3.5 Server Communication . . . 83
4.4 Discussion . . . 84
4.4.1 Data Access . . . 84
4.4.2 Integration . . . 86
4.4.3 Parallelism and Cloud . . . 88
4.4.4 Server Communication . . . 90
5 Pattern Language 91 5.1 Patterns for Knowledge Processing Systems . . . 92
5.1.1 Motivational example . . . 93 5.1.2 Fact . . . 94 5.1.3 Rule . . . 96 5.1.4 Knowledge Base . . . 98 5.1.5 Working Memory . . . 101 5.1.6 Inference Engine . . . 103 5.2 Application Example . . . 105 5.3 Discussion . . . 108
6 Evaluation and Discussion 111 6.1 Empirical Study . . . 111 6.1.1 Methodology . . . 111 6.1.2 Procedure . . . 112 6.1.3 Demand investigation . . . 112 6.1.4 First half . . . 115 6.1.5 Second half . . . 117 6.1.6 Threats to validity . . . 119
6.2 Discussion and Outlook . . . 120
6.2.1 Limitations and Further Work . . . 121
6.2.2 Knowledge Processing in the context of Big Data and Cloud . . . 122
6.2.3 Openness to new knowledge . . . 124
7 Summary and Conclusion 133 7.1 Research Questions revisited . . . 134
7.2 Future Work . . . 135
7.3 Conclusion . . . 135
References 137 Curriculum Vitae 147 Appendices 151 A Design Pattern Identification 153 A.1 Fact . . . 154
A.1.1 Fact in NxBRE . . . 154
A.1.2 Fact in Drools . . . 154
A.1.3 Fact in JavaDON . . . 155
A.2 Rule . . . 155
A.2.1 Rule in NxBRE . . . 156
A.2.2 Rule in Drools . . . 156
A.2.3 Rule in JavaDON . . . 157
A.3.1 Knowledge Base in NxBRE . . . 158
A.3.2 Knowledge Base in Drools . . . 158
A.3.3 Knowledge Base in JavaDON . . . 159
A.4 Working Memory . . . 160
A.4.1 Working Memory in NxBRE . . . 160
A.4.2 Working Memory in Drools . . . 161
A.4.3 Working Memory in JavaDON . . . 162
A.5 Inference Engine . . . 163
A.5.1 Inference Engine in NxBRE . . . 163
A.5.2 Inference Engine in Drools . . . 164
A.5.3 Inference Engine in JavaDON . . . 165
B Questionnaires and Task Descriptions 167 B.1 Preliminary Questionnaire . . . 168
B.2 Task description first half . . . 173
B.2.1 The task . . . 173
B.2.2 The story . . . 173
B.2.3 What you will have to implement . . . 173
B.2.4 The inference algorithm . . . 174
B.2.5 ATM Functionality . . . 175
B.2.6 What to do and what to pay attention to . . . 175
B.3 Task first half Questionnaire . . . 178
B.4 Task description second half . . . 180
B.4.1 The task . . . 180
B.4.2 When you are done . . . 180
List of Figures
1.1 Example of a knowledge processing system with connections to external
ser-vices. . . 3
1.2 Graphical representation of the research area. . . 9
1.3 Visual representation of the work process. . . 12
2.1 Common representation of an expert system architecture. . . 19
2.2 Architecture of the Linkilike system. . . 36
2.3 Architecture of the S-Mate system. . . 37
2.4 Architecture of the CLAFIS system. . . 38
2.5 Excerpt of the workflow of an automated teller machine. . . 39
2.6 Sequence diagram for a knowledge processing process. . . 39
3.1 Factory Method, as it is shown in Gamma et al. [46]. . . 51
3.2 Example of Factory Method in Drools. . . 51
3.3 Singleton, as it is shown in Gamma et al. [46]. . . 52
3.4 Adapter, as it is shown in Gamma et al. [46]. . . 52
3.5 Example of Adapter in Drools. . . 53
3.6 Decorator, as it is shown in Gamma et al. [46]. . . 53
3.7 An example of a Decorator in Drools. . . 54
3.8 Proxy, as it is shown in Gamma et al. [46]. . . 54
3.9 Example of Proxy in OpenRules. . . 55
3.10 Template Method, as it is shown in Gamma et al. [46]. . . 55
3.11 Strategy, as it is shown in Gamma et al. [46]. . . 56
3.12 An example of the Strategy pattern in Drools. . . 56
3.14 An example of Strategy in OpenRules. . . 57
3.15 An example of Strategy in JavaDON. . . 58
3.16 Observer, as it is shown in Gamma et al. [46]. . . 58
3.17 Example of the Observer pattern in Drools. . . 59
3.18 Overview of design pattern usage. . . 60
3.19 Abstract Factory, as it is shown in Gamma et al. [46]. . . 61
3.20 Chain of Responsibility, as it is shown in Gamma et al. [46]. . . 61
3.21 Command, as it is shown in Gamma et al. [46]. . . 62
3.22 Iterator, as it is shown in Gamma et al. [46]. . . 62
3.23 Visitor, as it is shown in Gamma et al. [46]. . . 63
3.24 Overview of design pattern usage, including additional patterns. . . 64
4.1 Example of an enterprise-ready knowledge processing system. . . 68
4.2 An example architecture of a "classical" enterprise application, using theLayers pattern. . . 70
4.3 An example of a knowledge processing architecture, mapped to an enterprise application architecture. . . 70
4.4 An example architecture of an "embedded" knowledge processing system. . 71
4.5 Data Access in the ATM example. . . 85
4.6 External integration in the ATM example. . . 86
4.7 Internal integration in the ATM example. . . 88
4.8 Parallelism in the ATM example. . . 88
4.9 Cloud in the ATM example. . . 89
5.1 Overview of the five essential patterns for knowledge processing systems. . 93
5.2 UML class diagram of the Fact pattern. . . 94
5.3 UML class diagram of the Rule pattern. . . 96
5.4 UML class diagram of the Knowledge Base pattern. . . 98
5.5 UML class diagram of the Working Memory pattern. . . 101
5.6 UML class diagram of the Inference Engine pattern. . . 103
5.7 An schematic excerpt of the ATM example process. . . 105
5.8 The example system, implemented by using the pattern language. . . 106
6.2 Results of the questionnaire on experience. . . 114
6.3 Results of the questionnaire on the familiarity with design patterns. . . 114
6.4 Results of the questionnaire after task 1. . . 116
6.5 Results of the evaluation of the first half of the task. . . 117
6.6 Results of the questionnaire after the second half of the task. . . 118
6.7 Results of the evaluation of the second half of the task. . . 119
6.8 Example of the DAO. . . 126
6.9 DTO usage as described by Fowler [43]. . . 127
6.10 Dependency Injection. . . 129
A.1 A fact in NxBRE. . . 154
A.2 A fact in Drools. . . 155
A.3 A fact in JavaDON. . . 155
A.4 A rule in NxBRE. . . 156
A.5 A rule in Drools. . . 157
A.6 A rule in JavaDON. . . 157
A.7 A knowledge base in NxBRE. . . 158
A.8 A knowledge base in Drools. . . 159
A.9 A knowledge base in JavaDON. . . 160
A.10 A working memory in NxBRE. . . 161
A.11 A working memory in Drools. . . 162
A.12 A working memory in JavaDON. . . 162
A.13 An inference engine in NxBRE. . . 163
A.14 An inference engine in Drools. . . 164
List of Tables
2.1 Common knowledge processing system frameworks (last checked on 08.08.2019). 43
3.1 An overview of the identified design patterns. . . 59
4.1 Mapping of patterns to requirements for data access. . . 74
4.2 Mapping of design patterns to requirements for external integration. . . 77
4.3 Mapping of patterns to requirements for internal integration. . . 79
4.4 Mapping of patterns to requirements for parallelism. . . 81
4.5 Mapping of patterns to requirements for cloud. . . 83
Chapter 1
Introduction
“
Even the best architecture, the most perfectly suited for the job, will be essen-tially useless if the people who need to use it do not know what it is; cannot understand it well enough to use, build, or modify it; or (worst of all) misun-derstand it and apply it incorrectly. And all of the effort, analysis, hard work, and insightful design on the part of the architecture team will have been wasted. [...] Creating the architecture isn’t enough. It has to be communicated in a way to let its stakeholders use it properly to do their jobs.Bass et al. [11]
”
"In the past decade the amount of data being created has skyrocketed. More than 30,000 gi-gabytes of data are generated every second, and the rate of data creation is only accelerating." Marz et al. [78]. Companies try to collect this amount of data and use it to their advantage. "This flood of information gives us the power to make more informed decisions, react more quickly to change, and better understand the world around us." Pierson [106]. To analyse this data, popular methods from Machine Learning, Deep Learning, and Data Mining are used. Especially, the discipline of knowledge processing systems becomes more and more important. Knowledge management (KM), knowledge processing (KP) and knowledge based sys-tems (KBS) can be established in companies to collect, structure, and organize knowledge of experts. By applying techniques like reasoning algorithms, the knowledge can be extended by creating new knowledge or getting new insights. For companies, this provides several benefits that can contribute advantages over competitors. Currently, interest increases for knowledge processing systems in the context of Cloud platforms, Big-Data processing, as well as Machine and Deep Learning that offer new opportunities. This thesis contributes to software architecture and code quality of these systems by providing an architectural guideline. It supports software engineers to ease the design and implementation to be able to build high-quality systems, ready for integration into enterprise applications. Also, re-searchers are supported in the development of evolutionary prototypes. In this thesis, a special focus is set on design patterns and the commonalities of knowledge processing and
based systems.
Throughout this thesis, the terms (software) architecture and implementation are always meant as used in the domain of software engineering (designing a software application and produc-ing source code). Especially in the context of knowledge based systems, these two terms often are interpreted differently. In the context of knowledge based systems they are often meant as "use", "introduce", or "apply".
In this thesis, the terms knowledge processing system and knowledge based system refer to their joint parts, altough they describe different extents of matter. A definition of these terms is given in section 2.1.
1.1
Knowledge Processing Systems
Knowledge processing, as the name implies, processes knowledge with influences from ar-tificial intelligence (such as machine learning, see, for example, Dutta [36]), data mining, as well as data processing. It covers the tasks of acquisition, storage, representation, and processing (especially reasoning, see section 2.1.2 for a more detailed explanation) of knowl-edge. Processing of knowledge pursues the aim to discover new knowledge, or insights, for example, by using discovered patterns and / or relationships, predefined rules, or applying formulas (which can also be classified as knowledge) on existing knowledge. This is done by algorithms that perform reasoning / inference (based on rules or ontologies, decision trees, or case-based reasoning), or also by executing newly developed methods that pro-cess knowledge for a given context (e.g., a formula in a specific context). The algorithms can become complex, computation intensive, and often have to process a large amount of knowledge.
Knowledge processing can add various advantages to a business application. It offers a lot of opportunities to change existing processes, for example automating complex tasks normally done manually by humans that involve "intelligence" (like data migration tasks, as described by Nadschläger et al. in [89]). Knowledge processing can also be applied to improve customer satisfaction (e.g., recommendations and suitable advertisement), by representing the knowledge of buying behaviour and finding relations. Further benefits are listed by Akerkar and Sajja [3]:
• Capturing knowledge: Knowledge is preserved and shared with employees, • dependency on experts is reduced and
• knowledge can be processed to generate new knowledge and get new insights into existing knowledge.
A widespread form of knowledge processing systems are rule based systems, originating from
expert systems (see section 2.1.2), which consist of the following parts: The Inference Engine,
such a system. Existing knowledge processing system frameworks, also called rule engines, or expert system shells, commonly originate from university research projects and lack of the quality requested in modern enterprise applications, due to their prototypical state (see, for example, Jacob and Froscher [60]). The goal of this thesis is to provide an architectural guideline for developers and researchers to implement and increase the quality of knowl-edge processing systems.
As a basis for comparison, enterprise applications have been chosen. A lot of literature on best practices in enterprise application development has been written (see, for example, Fowler [43], Posch et al. [108], or Starke [119]). Libraries and frameworks for the devel-opment of such applications are constantly improved to implement high-quality systems (taking into consideration maintainability and source code readability). Moreover, enter-prise applications are often critical systems in a company and therefore have to meet high quality standards. In this thesis, the proven concepts of enterprise application development are transferred to knowledge processing system development.
Figure 1.1: Example of a knowledge processing system with connec-tions to external services.
1.2
Design Patterns
“
Patterns help you build on the collective experience of skilled software engi-neers. They capture existing, well-proven experience in software development and help to promote good design practise.Buschmann et al. [22]
”
Design patterns are a compact description of the experience of experts. They allow soft-ware engineers to quickly adopt knowledge without the need to build it up by collecting experience over many years. Moreover, design patterns contribute a common language and document best practices. Therefore, they are a good technique to combine and write down the best working solutions of different knowledge processing systems, described in the literature.
Design patterns separate a problem-solution combination into three essential parts: context,
problem and solution. Although different styles (so-called templates) exist to describe design
patterns, these three aspects can be found in all of them. The context describes the circum-stances when a pattern can be used, the problem explains the difficulties the pattern tries to solve, and the solution shows how to actually solve the described problem.
Patterns do not exist in isolation, and often they are connected to each other, either loosely in a collection / catalogue of similar patterns, or in a pattern language that together form a combination of patterns to solve larger problems.
Many design patterns exist in the area of software engineering for different contexts and problems (see, for example, the most famous ones in Gamma et al. [46], Buschmann et al. [22], Fowler [43]), but no patterns are defined specifically for the area of knowledge processing. It, therefore, is not clear which of the large number of existing software patterns can, or should, be used for the implementation of a knowledge processing system. In this thesis, design patterns are considered as an ideal solution to support software engineers, as well as researchers, to build and integrate high-quality knowledge processing systems. Alternatives to design patterns for an architectural guideline exist: Architecture Description
Language (ADL), Frameworks, UML, or simple Wiki systems (see Bass et al. [11] for
de-tails). These have been considered, but the pattern concept was selected because it is far more common and established in software engineering. This assumption has been con-firmed by the evaluation, done in the course of this thesis (see chapter 6).
1.3
Motivation
As already shown in section 1.1, knowledge processing systems can add benefits to a com-pany and provide advantages over competitors. The following chapters provide analyses of knowledge processing systems and reveal the diversity and commonalities in their software architecture. Without a guideline or documentation of best practices, reproducing good
systems and also integrating existing ones, is difficult. Especially for software engineers specialized in enterprise applications without experience in the development of knowledge processing systems. An architectural guideline for knowledge processing systems contains best practices and clear instructions on the design and implementation of such systems and therefore also supports software engineers to develop them. Also, researchers are sup-ported in evolutionary prototyping, starting with a solid basis. Making the development of these systems easier intends to boost their quality and popularity.
1.3.1
Research Gap
A literature review (see also related work in section 2.3) shows the need for research in knowledge processing system architecture. In this section, relevant citations from literature are listed, underlining the need for research on an architecture guideline.
“...no lifecycle model is available specifically to develop knowledge-based sys-tems. These systems are considered the same as computer-based information systems for development purposes. Akerkar and Sajja [3]”
“No development model exists for the knowledge-based systems. The infor-mation and knowledge possess different characteristics and hence, the typical information system development model may not be suitable for the knowledge-based system. Akerkar and Sajja [3]”
“Developing a KBS is costly and tedious. Though it offers a high level of cus-tomization in a specific domain and solves problems in a more humanlike fash-ion, people may not prefer to develop the system. The readymade solutions do not offer a high level of customization, but they do provide quick, comparatively error-free, cheaper, ready-to-use solutions. Akerkar and Sajja [3]”
“The early development of knowledge-based systems (KBSs) was self-contained, often divorced from the inclusion of other diverse components. Davis et al. [26]”
“Most KBS development shells claim to provide hooks to connect an external resource to a KBS after it has been constructed. However, the communication among the KBS and external entities requires additional functionality to truly integrate them. Currently, there is no process or directive on how to accomplish this. Davies et al. [26]”
“KBSs are unique in that much of their functionality is embedded in an inference engine, which is programmed, rather than developed. The inference engine works with declarative knowledge and information to deduce the prescribed conclusions. Davis et al. [26]”
“Modern enterprise systems bring together various systems built on different platforms and enable them to communicate with each other. Similarly, knowl-edge systems will be more attractive if they can be integrated with existing con-ventional systems. Abdullah et al. [120]”
“Knowledge system projects are extremely specialized, requiring the team mem-bers to have knowledge of both the problem domain and the development tools. As a result, the team members are highly skilled individuals, [...] Abdullah et al. [120]”
“The development process of a KBS is similar to the development of any other software system; Avram [8]”
“Our findings showed that interest in KBSs as research topic has not ceased, but the topic itself shifted toward a more secondary role – KBSs being today generally embedded in other types of systems. Avram [8]”
1.3.2
Empirical Study
To underline the statements from literature listed in the previous section, an empirical study was carried out with software engineers and students with specialization in the develop-ment of enterprise applications. Additionally to a questionnaire, containing questions on their education and familiarity with the concepts of knowledge processing and design pat-terns, they were provided with an inference algorithm template. Based on this algorithm, they were requested to implement a knowledge processing system. The detailed results of this survey are presented in chapter 6, a summary is given here.
Even though the majority of participants had theoretical experience in the domain of knowl-edge processing, only one also had practical experience (implementation). On the contrary, nearly all of them were familiar with the concept of design patterns and only slightly less are using them in practice. All of them attended a university, or university of applied science, with a field of study of a form of informatics (software engineering, bioinformatics, etc.). The implementation task revealed that all of them had major difficulties in the implemen-tation of a knowledge processing system. The analysis of their work showed that the core components differ from each other. No common core architecture could be identified. The implementation task took very long or was cancelled because no working solution could be found.
1.3.3
Application areas
Knowledge processing systems are used in a wide range of application areas (see Pannu [102], Jabbar and Khan [59], Sharma and Jain [116], Avram [8] and also Abdullah et al. [120]): Medicine, Physics, Mathematics, Industry and many more.
Besides the quality assurance of the basic systems, research emerges to other modern trends (see Wagner [130]):
• Distributed knowledge processing systems and knowledge processing systems in the Cloud (Microservices).
• Parallelism in knowledge processing systems.
• Exchangeability and extensibility of inference algorithms in knowledge processing systems.
• Knowledge Acquisition and Representation.
• Persistent knowledge storage (relational databases, NoSQL databases, etc.). • Flexible knowledge manipulation (scripting, for example).
• Big Data / Big Knowledge.
An example solution to overcome the challenge of having to process large amounts of knowl-edge and the need for computation intensive processing algorithms, is to make use of mod-ern cloud technologies or compute-clusters. Even though many algorithms are well in-vestigated and tested, this is still an ongoing area in research. Algorithms are constantly changed, extended and improved. Due to their complexity and the lack of existing frame-works that suite all architecture criteria of enterprise applications, these may be avoided to be integrated into a business-critical application, even though they can provide a huge benefit for the company.
Technologies from the area of knowledge processing (for example reasoning algorithms) are also playing an important role in business and science. The integration of such algo-rithms into modern business applications is difficult because existing knowledge process-ing frameworks are not designed for usage together with modern development frameworks (e.g., Spring framework1, or Java Enterprise Edition2). Besides some proposals of architec-tures for knowledge based and processing systems (like the ones described by Chattratichat et al. [23], or Kouamou [68]), there are only few architecture styles, patterns and no guide-lines defined that can be applied when implementing such a system. Without having some guidance in the form of architecture styles or patterns, like the well known ones, for ex-ample, described by Fowler [43], or Buschmann et al. [22], which describe patterns for the general domain of enterprise application architecture, the implementation of a system using knowledge processing algorithms is difficult.
1.3.4
Design Patterns and Knowledge Processing
To facilitate developing knowledge processing system applications, the concept of architec-ture and design patterns has been brought to the area of knowledge processing. Also, in the
1http://projects.spring.io/spring-framework/ 2https://projects.eclipse.org/projects/ee4j
context of knowledge processing systems, patterns provide a common language and make the documentation of software architecture easier. Often, the distinction between architec-ture and design patterns is not clear and source of discussion. For this reason, and since the distinction in this thesis is unimportant, these two terms are treated synonymously for simplicity’s sake.
A lot of architecture and design patterns exist for the context of enterprise application devel-opment (see Fowler [43], Gamma et al. [46] and Buschmann et al. [22], to name just a few), but none are especially defined for the context of knowledge processing systems. These are complex systems applying mainly reasoning / inference algorithms, also prototypes, and try to use modern technologies to improve performance (e.g., cloud infrastructure, cluster, or map-reduce [27]). Some first architecture descriptions exist for special purposes (e.g., the “lambda” architecture described by Marz and Warren [78] that describes an architec-ture for big data processing), but for knowledge processing applications, no architecarchitec-ture styles or patterns are defined that support the development of such systems. The “lambda architecture” describes how to build the whole system and only fits on big data processing systems, it does not provide a solution for the key components of a knowledge processing system as defined in section 2.1.2.
1.4
Research Questions
Existing patterns for enterprise applications can also be applied to the context of knowledge processing, but no list or reference exists that describes the suitability and usability of pat-terns for developing and integrating knowledge processing algorithms, or creating custom knowledge processing systems. Patterns have to be identified and analysed to provide a list that can be used to easily create or integrate knowledge processing systems. Having a smaller amount will make the selection of patterns and development of knowledge process-ing systems easier.
The main research questions therefore are:
Research Question 1
• What are commonalities between knowledge processing systems and enterprise applications?
- How do they differ from classical enterprise applications? - What are the requirements?
Research Question 2
• What existing architecture and design patterns can be used for knowledge pro-cessing systems?
- How can these be used and do they have to be changed?
• Can new design patterns be identified for knowledge processing systems?
Research Question 4
• How to enable software developers to integrate and build knowledge processing systems in an enterprise application quality.
The result is a list of architecture and / or design patterns that can be used to overcome the most common difficulties in developing knowledge processing systems using the expe-rience in software development of many software engineers. This gives the developers an architecture guideline in the form of a pattern list, to easily integrate algorithms, or develop a custom knowledge processing system.
Figure 1.2 is a graphical representation of the research area. It shows the known way in the software engineering field to build an enterprise application (using design patterns, fa-mous architectures, components, etc.). On the contrary, this is not known on the knowledge
processing site. A plethora of algorithms (symbolically represented as the clouds with the
star cluster in it) with no documented architecture guideline results in a large number of different systems. On the software engineering side it is clear how to apply the existing doc-umented experience of other developers to build systems of high quality, whereas on the knowledge processing side this process is unclear. It is not guaranteed that the development result is of the same quality as the result on the software engineering side.
1.5
Methodology
The research methodology chosen for the work presented in this thesis is design science, according to the conceptual and mental model presented by Peffers et al. [104]:
1. Problem identification and motivation: This has been presented in the previous parts in this section. The problem is underlined by statements cited from literature and a motivational introduction.
2. Objectives of a solution: This part of the method is covered by the research questions and the definitions and related work that will be presented in chapter 2.
3. Design and development: The results of this step are presented in chapters 3, 4 and 5 in the form of (a) an object-oriented design pattern selection, (b) a design pattern col-lection consisting of enterprise application patterns and (c) a knowledge processing system specific design pattern language.
4. Demonstration: The demonstration is part of chapters 3, 4 and 5. In every chapter, short examples on how to apply the solution are given. Moreover, the evaluation contains a practical demonstration of the pattern collections and language.
5. Evaluation: Chapter 6 contains the evaluation in the form of an empirical study. 6. Communication: Communication is done in section 6.2 and chapter 7 in the form of a
discussion section and a conclusion.
The results presented in this thesis were achieved, combining the research methodology with an agile process model: Kanban. This model is used in modern software development and can also be applied to research tasks, as shown by the Kanban Tool Blog Entry [62], Nelson [94], or Kirkland [65]. Also, experiences in applying it to writing a dissertation can be found, like the one by Williams [135]. It separates the work into small tasks that allow identifying bottlenecks in an early project stage. Therefore, the tasks are assigned to states, represented in the form of columns, all of them having a limit of possible parallel tasks (work-in-progress ("wip") limit). This is an ideal method to avoid research into directions for no avail. Moreover, it supports a good organization of the tasks.
After an extensive literature study was done, existing knowledge processing system frame-works were analyzed for the usage of the "Gang-of-Four" design patterns for object-oriented programming. The result is presented in chapter 3.
The second step was to analyze different knowledge processing systems, identifying com-mon aspects with enterprise applications. For the analysis and tests, access to the source code is necessary. Therefore, real-world knowledge processing systems with accessible source code were needed and the following three projects qualified for the analysis (de-tails are provided in section 2.4.1):
1. Question Answering System3: A system that allows the user to ask questions and as a result, the user is provided with similar questions (having the same semantic mean-ing) and videos that answer these questions. This system uses a newly developed methodology for calculating similarity (see Nadschläger et al. [88]).
2. Authentication Calculation4: This application allows calculating the authenticity of a user by analyzing a social media profile (e.g., Facebook or Google+).
3. Disease Pressure Calculation5: A system in the agricultural domain for the calculation of the risk of a disease outbreak in a field. This system uses a newly developed formula for processing existing knowledge.
As a result, a collection of architecture and design patterns was defined, which can be ap-plied on the identified common aspects of knowledge processing systems and enterprise applications (see section 4.2). Existing architecture styles and patterns were analyzed and classified for their suitability of usage in the area of knowledge processing.
Finally, four selected knowledge processing frameworks were analyzed to define a custom knowledge processing system pattern language. The purpose of this pattern language is to support the development of a basic architecture for a knowledge processing system. For the evaluation of this work, an empirical study was conducted with software developers from university and a company specialized in the development of enterprise applications. On the one hand, this study intends to show the need of an architecture guideline for knowl-edge processing systems, on the other hand, it proves the suitability of design patterns as an approach to define such a guideline.
The work process described in this chapter is represented graphically in figure 1.3.
1.6
Contribution
This thesis contributes to the development of an architectural guideline for the design and implementation of knowledge processing systems. It eyes the practical software develop-ment aspect of knowledge processing systems.
Research Question 1 This question is answered by a comparison of enterprise applications
with knowledge processing systems that shows common aspects and their require-ments. Afterwards, design patterns were collected and mapped to a collection. The comparison and the pattern collection can be found in chapter 4 and was published in [87] and [90]. The early software architecture of the systems used for analysis was also published in [88] and [89].
3http://www.jku.at/faw/content/e240348/e240351/e240878 4http://www.jku.at/faw/content/e240348/e240351/e251409 5http://www.jku.at/faw/content/e240348/e251414
Li te ra tu re R e v ie w o n K P S D e v e lo p m e n t P e rs o n a l E xp e ri e n ce C o m p a ri so n t o E A d e v e lo p m e n t Li te ra tu re R e v ie w o n D e si g n P a tt e rn s Id e n ti fi ca ti o n o f K P S D e si g n P a tt e rn s Li te ra tu re R e v ie w o n D e si g n P a tt e rn s in K P S K P S f ra m e w o rk co m p a ri so n Id e n ti fi ca ti o n o f O O p a tt e rn s Id e n ti fi ca ti o n o f K P S p a tt e rn s Ev a lu a ti o n o f n e e d Ev a lu a ti o n fi rs t h a lf o f Ta sk Ev a lu a ti o n se co n d h a lf o f Ta sk A n a ly si s a n d D is cu ss io n A rc h it e ct u re G u id e li n e f o r K P S Figure 1.3: V isual representation of the w or k process.
Research Question 2 is partially answered by the pattern collection. Moreover, a detailed
analysis of existing knowledge processing frameworks has been conducted, identify-ing object-oriented design patterns that have been applied. The result of this analysis is presented in chapter 3 and in [91].
Research Question 3 The patterns can be used in knowledge processing systems without
the need to create any new variant. Nevertheless, patterns could be identified and set into relation in a pattern language for knowledge processing systems, presented in chapter 5 and in [86] and [92].
Research Question 4 This thesis is the contribution and answer to this question. It forms
an architectural guideline that can be used by software engineers to study design pat-terns for knowledge processing systems. Moreover, it contains introductions to the domains design patterns and knowledge processing systems. This statement is supported by the evaluation published in [93].
1.7
Dissertation outline
Chapter 2 Besides knowledge based systems, an overview will be given on design
pat-terns. Their history and templates to describe them will be presented. It will be explained how to be group and classify them. Moreover, related work will be introduced in this chap-ter.
Chapter 3 contains an analysis of three knowledge processing frameworks on the usage
of patterns. Especially the usage of object-oriented design patterns from Gamma et al. [46] was analysed. This is done via a manual analysis, supported with a tool for pattern identi-fication.
Chapter 4 describes the comparison of knowledge processing systems with enterprise
ap-plications. Common aspects are identified and form the basis for several design pattern collections. These collections contain design patterns specifically for one aspect, taken from well-known literature and familiar to software engineers.
Chapter 5 In this chapter, a pattern language, developed especially for the design and
implementation of knowledge processing systems, is presented. The pattern language con-tains five patterns to be able to create a high-quality basis for the development of knowledge processing systems.
Chapter 6 is about the evaluation of the need for design pattern collections and language
for knowledge processing systems, but also the improvement of the system design is tested when providing an architectural guideline for the implementation. Therefore, an empirical
study was conducted with participants from a software development company, specialized on the development of enterprise applications, and from the university.
Chapter 2
Definitions and Related Work
2.1
Knowledge Processing and Knowledge Based Systems
“
KBSs can leverage organizational knowledge by providing a real and practical approach for capturing, preserving, and distributing critical knowledge.Dutta Suomitra [36]
”
In this chapter, a definition of knowledge based and processing systems is given, to clearly define the boundaries and the context of this thesis. Moreover, the terms data, information and knowledge will be defined. This chapter contains a list of existing knowledge
process-ing frameworks and describes three selected projects from research which are the essential
source for the analysis presented in the further chapters.
2.1.1
Data, Information and Knowledge
Before a definition can be given about knowledge based and processing systems, the terms
data, information and knowledge have to be understood. An explanation is given in Akerkar
and Sajja [3]:
Data: "Factual, discrete and static things, and raw observations of the given area of interest
are known as data." Data has a specific static type. An example of data is the date 25.12.2016.
Information: An extension of data is information. To extend the example given of data, we
can add the information that this date represents "Christmas".
Knowledge: Knowledge is built on top of information and, according to Akerkar and Sajja
[3], "is considered a human understanding of a subject matter that has been acquired through proper study and experience." To convert the information that 25.12.2016 is
Christmas to knowledge, a rule can be added, for example, "if it is Christmas, a present has to be bought".
The definition given above is common-sense. Nevertheless, it is not yet a clear definition of knowledge and especially of its representation so that it can be analyzed by computers. For this, no uniform definition exists. Knowledge can be represented as facts, or rules (for example in the form of "IF A THEN B" combinations), but also with simple "is-a" hierar-chies. Moreover, (eventually complex) formulas can be considered as knowledge if they deduce facts from knowledge. More representation forms of knowledge exist (like frames, or ontologies), for details see Akerkar and Sajja [3].
In this thesis, everything will be classified as knowledge that allows some form of reasoning process. Section 2.1.2 will explain this in detail.
2.1.2
Definition of Knowledge Systems
Abdullah et al. identified the term Knowledge Systems. It includes all systems that work with
knowledge. Unfortunately, no clear definition of this term and the sub-concepts exists. In the
literature the following terms can found: • Data processing system
• Knowledge based system • Knowledge management system • Knowledge processing system
Furthermore, the terms Machine Learning, Data Mining, Expert Systems and Reasoning will be defined. These often occur in topics on knowledge systems.
Data Processing System
As the name already implies, a data processing system mainly operates on data. It performs conceptually simple tasks, like filtering, sorting, aggregation, conversion, etc. An example of a data processing system is an Extract-Transform-Load (ETL) tool. It takes data from a source, modifies it and writes it back to a data sink. Such tools can be used to take data from various sources and modify it so that it can be organized and converted to knowledge later on.
Knowledge Based System
A quite old, yet still valid and precise definition of a knowledge based system, is given by Feigenbaum et al.:
“
AI programs that achieve expert level competence in solving problems by bring-ing to bear a body of knowledge are called knowledge-based systems. Often, the term expert system is reserved for programs whose knowledge base contains the knowledge used by human experts in contrast to knowledge gathered from textbooks or non-experts. More often than not, the two terms expert system and knowledge based systems are used synonymously.Feigenbaum et al. [38]
”
Beierle and Kern-Isberner [15] determine the start of knowledge based systems with a work-shop in Dartmouth in 1956. A famous knowledge based system is the MYCIN system (see Shortliffe [117]) that supports the diagnosis of bacterial infections and was developed in the 70s.
Often, knowledge based systems are set equal to Expert Systems (see 2.1.2), Database
Man-agement Systems in Conjunction with an Intelligent User Interface, Linked Systems, CASE-Based Systems and Intelligent Tutoring Systems (see Akerkar and Sajja [3] for details).
Knowledge Management System
Knowledge management deals with the organization and structure of the knowledge itself.
Knowledge can be represented and stored in different formats (for example plain text files, structured text files (like XML), or unstructured text files like PDF or Rich Text documents, but also audio and video files). The main aspect of knowledge management is the stor-age and organization of knowledge. The storstor-age system should support distribution (for large amounts of knowledge) and fit the format the knowledge is represented in (relational databases, NoSQL databases, files, etc.). The system frontend must provide the possibility to add new or edit existing knowledge.
Akerkar and Sajja [3] define this definition as "technocentric". Also, an "organizational" and an "ecological" perspective exist on knowledge management. These include, for example, "ways how an organization’s operations are carried out", "organization’s best practices", or even the "relationships between the knowledge, people, and environmental factors".
Knowledge Processing System
Knowledge processing uses the collected knowledge to reason on existing, or gain new
knowl-edge, process it, such as for monitoring, controlling, decision support, or for different visu-alizations. The designation "knowledge processing" is sometimes used synonymously to "knowledge systems" in literature (for example, Abdullah et al. [120]). To get new insights, or to provide a better way to present existing knowledge, it has to be processed, analyzed, modified, etc. Especially if there is a lot of knowledge, processing can become computa-tion intensive. Therefore, technologies like distributed processing of data with Map-Reduce [27], actor-based [53], or highly parallelized systems can be used.
According to Wolff et al. [136], knowledge processing covers the following areas (in this thesis, the focus especially lies on the last one):
• "data collection and pre-processing, • discovery of regularities,
• creation of subject domain theories,
• application of formal knowledge structures,
• formal reasoning and interpretation in the application domain."
The difference between knowledge processing systems and knowledge based systems can be com-pared to the difference between data warehousing and data warehouse, as defined by Bauer and Günzel [12]. Whereas data warehousing and knowledge processing characterise more the overall process, including necessary tasks to operate the system, knowledge based systems and
data warehouse concentrate solely on the system itself. Although the terms knowledge process-ing systems and knowledge based systems do not describe the same extent of knowledge systems,
their joint part is addressed by the work presented in this thesis.
Machine Learning and Data Mining
The two topics "machine learning" and "data mining" are not synonyms of knowledge pro-cessing systems. Even though in some literature these are counted to knowledge based technologies (Akerkar and Sajja [3]), in this thesis the main criterion for classification of a service as a knowledge processing one is the presence of any form of reasoning process. Machine learning and data mining mainly deal with automatic learning or identification of patterns (not to confuse with design patterns), which is not directly a task of knowledge based systems.
Expert Systems
One certain characteristic of knowledge based systems are expert systems. Because handling all system types would exceed the boundaries of this thesis, the original form of knowl-edge based systems was selected, and therefore, a special focus is on rule based systems, originating from expert systems.
In literature, the architecture of an expert system is commonly described as in figure 2.1 (see, for example, Akerkar and Sajja [3]):
In te rf a ce s Knowledge Base Inference Engine
Figure 2.1: Common representation of an expert system architecture.
Interfaces These can either be a graphical user interface, or a remote communication
inter-face (e.g., web services) to access the functionality of knowledge processing systems.
Knowledge Base The knowledge base contains all the knowledge (in the form of facts and rules) of the system.
Inference Engine The inference engine is the concrete reasoning algorithm.
Working Memory The working memory is commonly not shown in figures but is an
es-sential component. It functions as a runtime storage for inferred facts.
Explanation Module Optionally, some expert systems also provide an explanation
mod-ule. This module is responsible for creating some form of log file that explains how certain knowledge was deduced.
The knowledge in an expert system is represented via rules and facts. Facts represent static data that is always true, for example (taken from Akerkar and Sajja [3]): "The Earth moves around the Sun." A rule contains a list of conditions and actions. An example of a rule is "If there is daylight, then the Sun is in the sky." (Akerkar and Sajja [3]).
Reasoning
A broad overview on the functionality of reasoning / inference algorithms is provided by Russell and Norvig [113], Wunderlich [137], Akerkar and Sajja [3], or Beierle and Kern-Isberner [15]. Most algorithms (as for example Rete [41]) are based on the concepts of
forward or backward chaining. In the case of forward chaining, the target state may not be
known a priori. Based on a initial state, matching rules are identified that may add new insights. The order of the rules is important. In contrast, backward chaining starts from the target state and tries to find matching rules that lead to this state. The order does not play such an important role in this case (but can influence performance).
2.1.3
Knowledge Processing System Properties
To use and distribute knowledge in a company, techniques from knowledge management can be applied. Another possibility is processing of knowledge to gain new insights, or prepare and change the existing data structures to be able to present stored knowledge in a suitable form to the user. Many existing systems, like Content Management System (CMS) tools, do not initially support the processing of knowledge, only its storage and management. Normally, knowledge is specific for a domain and should be preserved and combined into forms that can be distributed, for example, to colleagues. Often knowledge does not only exist in documents in the form of written words. Sometimes the knowledge itself is stored in the implementation of an algorithm. This can be interpreted as knowledge processing. For example, the transformation of existing data into a meaningful output (e.g., a percentage value), based on a formula (that can also be classified as knowledge).
Many default tools that are widely suggested for usage in knowledge management are not fully capable of representing the knowledge of a company (for details, see Hüttenegger [58]). Examples for tools are Groupware systems, Wikis, forums, blogs, etc. In many cases, they lack integration possibilities and cannot be combined so that the user experiences one workflow throughout the whole system. Especially in the area of knowledge processing these tools are limited and not capable of applying the company’s complete knowledge.
To call a system a knowledge processing system, it has to comply with the following prop-erties:
• Knowledge must be present,
• it must be represented in a way so that knowledge is computer processable, • the knowledge must be processed in a form of reasoning,
• it must apply any algorithms / technologies from the area of reasoning / inference. Disciplines in knowledge processing:
• Reasoning / inference.
• Knowledge representation (ontologies).
• Application of other knowledge (e.g., formulas, etc.).
The design of a software architecture and the implementation of knowledge processing systems can generally be compared to “normal” enterprise applications (see, for example, Akerkar and Sajja [3] or Beierle and Kern-Isberner [15]). Many parts are similar, but some parts differ from these systems. These recur in many knowledge processing systems. In the next chapter, key areas of a knowledge processing system will be defined, and design patterns suitable to solve problems for this specific aspect will be identified and described.
2.2
Design Patterns
“
Because patterns are (by definition) found in practice, one does not invent them; one discovers them.Bass et al. [11]
”
Design patterns are a means of documenting the collective experience and that of experts in software development, hence documenting best practices in software development in the long term. They provide solutions to recurring problems in software architecture and design, or programming in general, in the form of a description of the problem and a suit-able solution. In general, the description tries to be independent of a specific programming language or paradigm, but exceptions do exist (e.g., object-oriented versus functional pro-gramming languages). Knowing such patterns allows creating complex software architec-tures by building on the experience of skilled software developers. Patterns are a form of documentation of the experience of many developers over a long period of time and there-fore are valuable resources for software development. According to Avgeriou and Zdun [7], design patterns should not describe an obvious solution. The importance of architec-ture documentation and how design patterns support this task is described, for example, by Buschmann et al. [22], Zdun and Avgeriou [139] and Bass et al. [11].
2.2.1
History
The idea of architecture patterns was made popular by the building architect Christopher Alexander [4] in 1979. He tried to identify solutions for recurring problems in architec-ture. Soon, this idea was brought to software development. One of the first attempts was made by Beck and Cunningham [13] with design patterns for the design of graphical user interfaces in Smalltalk. The idea was further extended to the domain of object-oriented pro-gramming by the, nowadays quite famous, so-called “Gang-of-Four”1(GoF, Gamma et al. [46]), who created a catalogue of design patterns for recurring problems in object-oriented applications.
Since then, others picked up the idea of design patterns to write down and share the col-lective experience of developers. The pattern concept is not limited only to software devel-opment, but it can also be found in different domains: buildings architecture, education, communication, etc. (see for example Buschmann et al. [21]).
Buschmann et al. [22] define patterns to consist of the following characteristics: • "A pattern addresses a recurring design problem that arises in specific
de-sign situations and presents a solution to it.
• Patterns document existing, well-proven design experience,
• identify and specify abstractions that are above the level of single classes and instances, or of components (Gamma et al. [46]),
• provide a common vocabulary and understanding for design principles (Gamma et al. [46]),
• are a means of documenting software architectures,
• support the construction of software with defined properties, • help you build complex and heterogeneous software architectures, • help you to manage software complexity."
Some common characteristics of design patterns can also be found in Alur et al. [5], a pattern catalogue for Java Enterprise Edition:
• "Patterns are observed through experience, • are typically written in a structured format, • prevent reinventing the wheel,
• exist at different levels ob abstraction, • undergo continuous improvement, • are reusable artefacts,
• communicate designs and best practices, • can be used together to solve a larger problem."
Patterns make communication easier as they provide a concise name for a problem and its solution. Everybody who knows this name and the pattern does not need any (possibly complicated) explanation / documentation for the problem and its solution. A design pat-tern can be seen as a best practice, and it improves software documentation. It also has a positive influence on design and implementation, depending on the diligent usage by the developer.
In software development, design patterns provide descriptions to solve a common problem. The actual implementation of the pattern can vary, see Buschmann et al. [21].
