system design and implementation design principles and quality criteria commonkads system...

System design and implementation

Design principles and quality criteria

CommonKADS system architecture

Four steps in creating a Design Model

Sample implementations

System design & implementation

2

From analysis to design

Applicationdomain

Softwaresystem

communicationmodel

knowledgemodel

taskmodel

agentmodel

organizationmodel

designmodel

experts

textbooks

protocols

cases

reasoningstrategies

requiredresponse time

Analysismodels

problems &opportunities

implementationlanguage

softwarearchitecture

hardwareplatform

algorithmdesign

datastructuredesign


3

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


4

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)


5

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


6

Design quality criteria in general

Minimization of coupling Maximization of cohesion Transparency Maintainability


7

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


8

Steps in system design

design architecture

specifyhw/sw platform

detailedarchitecturespecification

detailedapplication

design

Step 1 Step 2 Step 3 Step 4

CommonKADS referencearchitecture

list ofavailableenvironments

checklistof architecuredecisions

predefinedmappingsto architecture

support knowledge for CommonKADS design


9

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


10

System architecture: three main sub-systems

application model

reasoning functions(tasks, inferences)

domain schema(s)

controller

data/knowledge bases

views

provides outputto external agents

(user interface,database query)

handles input from external

agentsand from

internal functions

resultreport

updatesfunction

invocationsinformation

access

controllerviews

User Input

Sensors

Databases

User interface

External system interface


11

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


12

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


13

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


14

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


15

Decomposition of the application model sub-system

Criteria should enable structure-preserving design should enable integration with other SE approaches

Options 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


16

System architecture: application model sub-system

dynamic role

datatypedomain-mappingcurrent binding

access/updatefunctions

task

I/O rolesmethod

execute

transferfunction

I/O roles

task method

intermediate rolescontrol specification

execute

static role

domain-mapping

access functions

domain model

domain-model nameuses

access functionsinferencing functions

inference

I/O rolesstatic rolesmethod

give-solutionmore-solutions?has-solution?

inference method

algorithm speclocal vars

execute

domain construct


17

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 choicenot true in case of real-time application

If choice is more or less free: consider to postpone until completion of step 3


18

Platform criteria (1)

Library of “view” object classesmay be a considerable amount to construct yourself

Declarative knowledge representation formalism?idem

Standard interfaces to other software e.g. ODBC, CORBA often required


19

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


20

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)


21

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


22

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


23

Step 3: Specify architectural components

Specify component interfaces Design general architectural facilities

view update mechanism


24

Controller facilities

activation/termination of application functions user interrupts for trace/background information function abortion handling transfer functions


25

Application-model facilities (1)

Task: initialization and execute methods

Task method: control-language elements control-language declarativity

Inference execute, more-solutions?, has-solution? linking to inference methods


26


Inference method method library? enable many-to-many relation between inference and method

Transfer function implemented via message-passing pattern

Dynamic role data types allowed: “element”, “set”, “list” ?! access/update operations: select, subtract, append,


27


Static role access/query functions

Domain model representational format access/query functions modification/analysis functions

Domain construct (only inspected)


28

View facilities

Standard graphical visualizations Generation of external formats

e.g. SQL query

Architectural view-update facilities mapping table message protocol


29

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


30

Typical interface format for tracer

Static role bindings

Application tracer

Task control

EXECUTING task t2

REPEATNEW-SOLUTION(inference B)

inference A

inference B

UNTIL HAS-SOLUTION(inference D)

Dynamic role bindings

Inference structure

Domain knowledge used by inference A

IF obj.a1 > 2 AND obj.a2 < 4THEN obj.a3 = "xyz"

IF obj.a1 =< 2THEN obj.a3 = "abc"

object 1object 1object 2

object 3

object 4object 5

Role X Role Y Role Z

Role U Role V Role W

object 7object 6

X ZB

A

D

C

U

V

W


31

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


32

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


33

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


34

Application model design

Minimal set of application-design activities: For each task method:

construct operational control structure

For each dynamic role: choose a data type

For each inference: identify a map write a method-invocation call for the inference


35

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)


36

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


37

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


38

Distributed knowledge systems

Reasoning service application model functions as services no UI

Knowledge-base/ontology server example: GRASP server for art objects

Method service distributed system realized through a set of methods

Combinations


39

Sample implementations

Housing application Source code at web-site “Academic” implementation

public-domain Prolog

“Business” implementation Aion8

Experiences show that prototypes of “running knowledge models” can be built within days


40

Architecture Prolog system

SWI-Prolog (+XPCE)

O-O kernel

inferencemethodlibrary

CommonKADS kernel

"model""controller"

"views"

architecturalfacilities

applicationrealization

implementationplatform


41

Trace Prolog system (1)


42



43



44



45

Aion8 system for “housing”

Realized as O-O “framework” roles, interfaces => multiple inheritance Hollywood principle

Includes task-template library facility Default implementation of inferences


46

Aion8 system architecture

CommonKADS Library

Framework Library

housingapplication

assessmenttemplate

frameworklayer

CommonKADSlayer

task-templatelayer

applicationlayer

<other applications>

<other templates>

assessmentframework


47

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 and implementation design principles and quality criteria commonkads system...

Documents