System design and implementation
Design principles and quality criteria
CommonKADS system architecture
Four steps in creating a Design Model
Sample implementations
From analysis to design
Application
domain
Software
system
Analysis
models
experts
textbooks
protocols
cases
reasoning
strategies
knowledge
model
algorithm
design
communication
model
task
model
required
response time
problems &
opportunities
software
architecture
agent
model
design
model
datastructure
design
hardware
platform
implementation
language
organiz ation
model
System design & implementation
2
System design

Input:




knowledge model = problem-solving requirements
communication model = interaction requirements
other models = “non-functional” requirements
Output:


specification of a software architecture
design of the application within this architecture
System design & implementation
3
System architecture

Description of software in terms of:





decomposition into sub-systems
choice of control regime(s)
decomposition of sub-systems into software modules
Focus point in the design process
Reference architecture for CommonKADS-based systems
Cf. textbook of Sommerville (1995)
System design & implementation
4
Structure-preserving design
“Preserve both the content and the structure of the analysis
model during design”
 Central modern design principle
 Design is seen as “adding implementation-specific detail
to the analysis results”
 Preservation of information is key notion
 Directly related to quality criteria
System design & implementation
5
Design quality criteria in general




Minimization of coupling
Maximization of cohesion
Transparency
Maintainability
System design & implementation
6
Quality criteria for KS design


Reusability of design elements / resulting code
Maintainability and adaptability



one-step development is usually unrealistic, especially for
knowledge-intensive systems
Explanatory power
Knowledge-elicitation/refinement ease

knowledge changes over time
System design & implementation
7
Steps in system design
Step 1
Step 2
Step 3
Step 4
design
architecture
specify
hw/sw platform
detailed
architecture
specification
detailed
application
design
CommonKADS
reference
architecture
list of
available
environments
checklist
of architecure
decisions
predefined
mappings
to architecture
support knowledge for
CommonKADS design
System design & implementation
8
Step 1: specify global architecture


Principle: separate functionality from interface issues
MVC architecture:



developed for Smalltalk-80
distinction between application objects and their visualizations
central control unit with event-driven regime
System design & implementation
9
System architecture:
three main sub-systems
User Input
views
controller
Sensors
Databases
handles input
from external
agents
and from
internal functions
function
invocations
controller
views
provides output
to external agents
(user interface,
database query)
result
report
updates
User interface
External system
interface
information
access
application model
reasoning functions
(tasks, inferences)
domain schema(s)
data/knowledge bases
System design & implementation
10
Sub-system: application model

contains application data and functions
= knowledge-model objects

data:



knowledge bases
dynamic data manipulated during reasoning (dynamic roles)
functions

tasks, inferences, transfer functions
System design & implementation
11
Sub-system: views




visualizations of application data and functions
multiple visualizations possible
aggregate visualization of multiple application objects
requires architectural update/integrity mechanisms


mapping table
message protocol for state changes of objects
System design & implementation
12
Sub-system: controller





central “command & control unit”
provides handlers for external and internal events
enables activation of application functions
may define its own “control” views
may have internal clock plus agenda
=> demon-like behavior
System design & implementation
13
Some remarks about the
MVC architecture




Developed in an object-oriented context
Is in fact functional decomposition of “objects”
Use not necessarily restricted to an O-O
design/implementation approach
But: message passing paradigm fits well with required
architectural facilities
System design & implementation
14
Decomposition of the
application model sub-system

Criteria



Options


should enable structure-preserving design
should enable integration with other SE approaches
functional or object-oriented decomposition
Choice: object-oriented decomposition


fits well with declarative character of object specifications in the
knowledge model (task => object)
simplifies mapping onto O-O implementations
System design & implementation
15
System architecture:
application model sub-system
task
I/O roles
method
task method
execute
intermediate roles
control specification
execute
inference
I/O roles
static roles
method
give-solution
more-solutions?
has-solution?
inference method
algorithm spec
local vars
execute
transfer
function
I/O roles
static role
domain-mapping
access functions
dynamic role
domain model
datatype
domain-mapping
current binding
domain-model name
uses
domain construct
access/update
functions
System design & implementation
access functions
inferencing functions
16
Step 2: Identify target
implementation platform

Customer-specific requirements often constrain this
choice
= reason for early placement in the process

Software choice is nowadays much more important than
hardware choice
not true in case of real-time application

If choice is more or less free:

consider to postpone until completion of step 3
System design & implementation
17
Platform criteria (1)

Library of “view” object classes
may be a considerable amount to construct yourself

Declarative knowledge representation formalism?
idem

Standard interfaces to other software


e.g. ODBC, CORBA
often required
System design & implementation
18
Platform criteria (2)

Language typing facilities



weak typing usually implies more work in mapping analysis model
(see Step 4a)
Control facilities/protocols
CommonKADS support


dedicated platform extension (e.g. object library)
link with CASE tool supporting CommonKADS
System design & implementation
19
Example environments: Prolog






View library: vendor-dependent
Declarative knowledge representation
DB interfaces: vendor-dependent
Weak language typing
No standard event-handling/message-passing control
protocols
UvA tools provide some support (API)
System design & implementation
20
Example environments: Java





library of views
no declarative knowledge representation
DB interfaces
C++-like typing facilities
control facilities:
e.g. multi-threading

currently no CommonKADS support
System design & implementation
21
Example environments:
AionDS 8.0






Library of view objects
(Semi-)declarative knowledge representation
ODBC/CORBA interfaces
O-O typing facilities (including relations)
O-O message passing protocol
CommonKADS support

dedicated framework
System design & implementation
22
Step 3: Specify architectural
components


Specify component interfaces
Design general architectural facilities

view update mechanism
System design & implementation
23
Controller facilities




activation/termination of application functions
user interrupts for trace/background information
function abortion
handling transfer functions
System design & implementation
24
Application-model facilities (1)

Task:


Task method:



initialization and execute methods
control-language elements
control-language declarativity
Inference


execute, more-solutions?, has-solution?
linking to inference methods
System design & implementation
25
Application-model facilities (2)

Inference method



Transfer function


method library?
enable many-to-many relation between inference and method
implemented via message-passing pattern
Dynamic role


data types allowed: “element”, “set”, “list” ?!
access/update operations: select, subtract, append,
System design & implementation
26
Application-model facilities (3)

Static role


Domain model




access/query functions
representational format
access/query functions
modification/analysis functions
Domain construct

(only inspected)
System design & implementation
27
View facilities


Standard graphical visualizations
Generation of external formats


e.g. SQL query
Architectural view-update facilities


mapping table
message protocol
System design & implementation
28
User interfaces

End-user interface


consider special facilities: natural language generation, ….
use domain-specific visualizations
=> depends on application design

Expert interface


trace interface
edit/refine interface for knowledge bases
System design & implementation
29
Typical interface format for tracer
Application tracer
Task control
Inference structure
EXECUTING task t2
X
REPEAT
NEW-SOLUTION(inference B)
B
A
inference A
Z
C
inference B
UNTIL HAS-SOLUTION(inference D)
U
D
W
V
Dynamic role bindings
Role U
object 1
Role X
object 4
object 5
System design & implementation
Role V
object 1
object 2
Role Y
object 6
Static role bindings
Role W
object 3
Role Z
Domain knowledge used by inference A
IF obj.a1 > 2 AND obj.a2 < 4
THEN obj.a3 = "xyz"
IF obj.a1 =< 2
THEN obj.a3 = "abc"
object 7
30
Step 4: specify application within
architecture
Step 4a: “map analysis info onto architecture”


ensures structure-preserving approach
manual mapping is cumbersome
Step 4b: “add design details”

list of design details that need to be added to complete
operationalization of an analysis model
System design & implementation
31
Step 4a: map analysis info onto
architecture

mapping tools have been constructed



example: VOID API
see web-site for information
extent of mapping depends on built-in design decisions in
architecture
System design & implementation
32
Application design of controller




Main input: communication model
Often “hand work” needed
Minimum: bootstrapping procedure
Other functions:




handling explanation requests
user control over reasoning process
reasoning interrupts / strategic control
enabling “what-if” scenario’s
System design & implementation
33
Application model design
Minimal set of application-design activities:
 For each task method:


For each dynamic role:


construct operational control structure
choose a data type
For each inference:


identify a map
write a method-invocation call for the inference
System design & implementation
34
Application design of views


Select a view for each application object, if required
Guideline: for end-user interface use views as close as
possible to domain-specific formats


too often system designers just impose on users what they like
themselves
each domain has its own “tradition” in representing information
(and usually for a good reason)
System design & implementation
35
Prototyping: reasoner sub-system

When needed?



Newly constructed elements in knowledge model
Gaps in domain knowledge
In general: knowledge-model V&V
– verification: “is the system right”
– validation: “is it the right system”

Should be supported by implementation platform

should be a matter of days to construct a prototype
System design & implementation
36
Prototype: mock-up agent
interface


Test mock-up interface without full application functionality
When needed:



complex external interaction (e.g.; HOMEBOTS)
complex view formats
complex view aggregations
System design & implementation
37
Distributed knowledge systems

Reasoning service



Knowledge-base/ontology server


example: GRASP server for art objects
Method service


application model functions as services
no UI
distributed system realized through a set of methods
Combinations
System design & implementation
38
Sample implementations



Housing application
Source code at web-site
“Academic” implementation


“Business” implementation


public-domain Prolog
Aion8
Experiences show that prototypes of “running knowledge
models” can be built within days
System design & implementation
39
Architecture Prolog system
"views"
application
realization
architectural
facilities
implementation
platform
System design & implementation
"controller"
"model"
CommonKADS kernel
O-O kernel
inference
method
library
SWI-Prolog (+XPCE)
40
Trace Prolog system (1)
System design & implementation
41
Trace Prolog system (2)
System design & implementation
42
Trace Prolog system (3)
System design & implementation
43
Trace Prolog system (4)
System design & implementation
44
Aion8 system for “housing”

Realized as O-O “framework”




roles, interfaces => multiple inheritance
Hollywood principle
Includes task-template library facility
Default implementation of inferences
System design & implementation
45
Aion8 system architecture
housing
application
assessment
template
<other applications>
<other templates>
CommonKADS Library
Framework Library
application
layer
task-template
layer
CommonKADS
layer
framework
layer
assessment
framework
System design & implementation
46
Key points



Design as a structure-preserving refinement process
Four-step design process
Support can be provided by:




CommonKADS architecture
knowledge/communication-model transformation tools
dedicated platforms with “CommonKADS packages”
“Rational design: how and why to fake it” (Parnas &
Clements)
System design & implementation
47