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

Applic ationdomain

S oftwares ys tem

communica tionmodel

knowledgemodel

tas kmodel

agentmodel

org aniz a tionmodel

des ignmodel

experts

textbooks

protocols

ca s es

rea s onings tra teg ies

requiredres pons e  time

Analys ismodels

problems  &opportunitie s

implementa tionlanguage

s oftwa rea rchitec ture

ha rdwa repla tform

a lg orithmdes ig n

da ta s tructuredes ig n

System design & implementation 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

System design & implementation 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)

System design & implementation 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

System design & implementation 6

Design quality criteria in general

■  Minimization of coupling ■  Maximization of cohesion ■  Transparency ■  Maintainability

System design & implementation 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

System design & implementation 8

Steps in system design

des ign  a rchitec ture

s pec ifyhw/s w  pla tform

deta iledarchitec tures pec ifica tion

deta iledapplica tiondes ign

S tep  1 S tep  2 S tep  3 S tep  4

CommonKADS  re ferencea rchitec ture

lis t  ofa va ilableenvironments

checklis tof  a rchitecuredec is ions

predefinedmapping sto  a rchitec ture

s upport  knowledge  for  C ommonK ADS  des ign

System design & implementation 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

System design & implementation 10

System architecture: three main sub-systems

applic ation  model

reas oning  functions(tas ks ,   inferences )domain  s chema(s )

controller

data/knowledge  bas es

views

provides  outputto  external  agents(us er  interface,databas e  query)

handles  input  from  external

agentsand  from

 internal  functions

res ultreport updatesfunc tion

invocationsinformationacces s

controllerviews

User  Input

S ensors

Databases

User  interface

E xternal  sys tem  interface

   

System design & implementation 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

System design & implementation 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

System design & implementation 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

System design & implementation 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

System design & implementation 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

System design & implementation 16

System architecture: application model sub-system

dynamic  role

da ta typedoma in-­‐mappingcurrent  binding

a cces s /upda tefunctions

tas k

I/O  rolesmethod

execute

trans ferfunction

I/O  roles

tas k  method

inte rmedia te  rolescontrol  s pec ifica tion

execute

s ta tic  role

doma in-­‐mapping

a cces s  functions

domain  model

doma in-­‐mode l  nameus es

a cces s  functionsinferenc ing  functions

inference

I/O  roless ta tic  rolesmethod

g ive -­‐s olutionmore-­‐s olutions ?ha s -­‐s olution?

inference  method

a lg orithm    s pecloca l  va rs

execute

 

domain  cons truc t

System design & implementation 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

System design & implementation 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

System design & implementation 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

System design & implementation 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)

System design & implementation 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

System design & implementation 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

System design & implementation 23

Step 3: Specify architectural components

■  Specify component interfaces ■  Design general architectural facilities

➤  view update mechanism

System design & implementation 24

Controller facilities

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

System design & implementation 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

System design & implementation 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,

System design & implementation 27

Application-model facilities (3)

■  Static role ➤  access/query functions

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

■  Domain construct ➤  (only inspected)

System design & implementation 28

View facilities

■  Standard graphical visualizations ■  Generation of external formats

➤  e.g. SQL query

■  Architectural view-update facilities ➤  mapping table ➤  message protocol

System design & implementation 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

System design & implementation 30

Typical interface format for tracer

S tatic  role  bindings

 Applic ation  trac er  

T as k  control

E X E C UTING    task  t2

RE P E ATNEW -­‐S OLUTION(inference  B )

  inference  A  

inference  B

UNTIL  HAS -­‐S OLUTION(inference  D )

Dynamic  role  bindings

Infe rence  s truc ture

Domain  knowledge  used  by   inference  A

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

IF  obj.a1  =<  2THE N  obj.a3  =  "abc"

objec t  1 objec t  1objec t  2

objec t  3

objec t  4objec t  5

R ole  X R ole  Y R ole  Z

R ole  U R ole  V R ole  W

objec t  7objec t  6

X ZB

A

D

C

U

V

W

   

System design & implementation 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

System design & implementation 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

System design & implementation 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

System design & implementation 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

System design & implementation 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)

System design & implementation 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

System design & implementation 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

System design & implementation 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

System design & implementation 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

System design & implementation 40

Architecture Prolog system

S WI-­‐P rolog  (+XP C E )

O-­‐O  kernel

inferencemethodlibrary

C ommonKADS  kernel

"model""controller"

"views "

architecturalfacilities

applicationrealization

implementationplatform

   

System design & implementation 41

Trace Prolog system (1)

System design & implementation 42

Trace Prolog system (2)

System design & implementation 43

Trace Prolog system (3)

System design & implementation 44

Trace Prolog system (4)

System design & implementation 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

System design & implementation 46

Aion8 system architecture

C ommonKADS  L ibra ry

F ramework  L ibra ry

housingapplica tion

assessmenttempla te

frameworklayer

C ommonKADSlayer

task-­‐templatelayer

applicationlayer

<other  applications >

<other  templates >

assessmentframework

System design & implementation 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)