System design and implementation

(1)

System design and implementation

Design principles and quality criteria CommonKADS system architecture Four steps in creating a Design Model

Sample implementations

(2)

System design & implementat

ion 2

From analysis to design

Application

domain Software

system

communication model knowledge

model

modeltask

agent model

organization model

design model experts

textbooks protocols

cases reasoning strategies required response time

Analysis models

problems &

opportunities implementation

language software architecture

hardware platform algorithm design datastructure

design

(3)

ion 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)

ion 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)

ion 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)

ion 6

Design quality criteria in general

 Minimization of coupling

 Maximization of cohesion

 Transparency

 Maintainability

(7)

ion 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)

ion 8

Steps in system design

design

architecture specify

hw/sw platform

detailed architecture specification

detailed application

design

Step 1 Step 2 Step 3 Step 4

CommonKADS reference architecture

list of available environments

checklist of architecure decisions

predefined mappings to architecture

support knowledge for CommonKADS design

(9)

ion 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)

ion 10

System architecture:

three main sub-systems

application model

reasoning functions (tasks, inferences) domain schema(s)

controller

data/knowledge bases

views

provides output to external agents

(user interface, database query) handles input

from external agents and from internal functions

result

report updates

function

invocations information

access controller

views

User Input

Sensors

Databases

User interface External system interface

(11)

ion 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)

ion 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)

ion 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)

ion 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)

ion 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)

ion 16

System architecture:

application model sub-system

dynamic role datatype domain-mapping current binding access/update functions

task I/O roles method execute

transfer function I/O roles task method

intermediate roles control specification execute

static role domain-mapping access functions

domain model domain-model name uses

access functions inferencing functions inference

I/O roles static roles method give-solution more-solutions?

has-solution?

inference method algorithm spec local vars execute

domain construct

(17)

ion 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 choice

not true in case of real-time application

 If choice is more or less free:

 consider to postpone until completion of step 3

(18)

ion 18

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

(19)

ion 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)

ion 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)

ion 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)

ion 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)

ion 23

Step 3: Specify architectural components

 Specify component interfaces

 Design general architectural facilities

 view update mechanism

(24)

ion 24

Controller facilities

 activation/termination of application functions

 user interrupts for trace/background information

 function abortion

 handling transfer functions

(25)

ion 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)

ion 26

Application-model facilities (2)

 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)

ion 27

Application-model facilities (3)

 Static role

 access/query functions

 Domain model

 representational format

 access/query functions

 modification/analysis functions

 Domain construct

 (only inspected)

(28)

ion 28

View facilities

 Standard graphical visualizations

 Generation of external formats

 e.g. SQL query

 Architectural view-update facilities

 mapping table

 message protocol

(29)

ion 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)

ion 30

Typical interface format for tracer

Static role bindings Application tracer

Task control

EXECUTING task t2 REPEAT

NEW-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 < 4 THEN obj.a3 = "xyz"

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

object 1 object 1

object 2 object 3

object 4 object 5

Role X Role Y Role Z

Role U Role V Role W

object 7 object 6

X B Z

A

D

C

U

V

W

(31)

ion 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)

ion 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)

ion 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)

ion 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)

ion 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)

ion 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)

ion 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)

ion 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)

ion 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)

ion 40

Architecture Prolog system

SWI-Prolog (+XPCE) O-O kernel

inference method

library CommonKADS kernel

"model"

"controller"

"views"

architectural facilities application

realization

implementation platform

(41)

ion 41

Trace Prolog system (1)

(42)

ion 42

Trace Prolog system (2)

(43)

ion 43

Trace Prolog system (3)

(44)

ion 44

Trace Prolog system (4)

(45)

ion 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)

ion 46

Aion8 system architecture

CommonKADS Library

Framework Library housing

application

assessment template

framework layer CommonKADS

layer task-template

layer application

layer

assessment framework

(47)

ion 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)