commonkads design and implementation
DESCRIPTION
Ch. 11-12 of the CommonKADS textbookTRANSCRIPT
![Page 1: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/1.jpg)
System design and implementation
Design principles and quality criteria CommonKADS system architecture
Four steps in creating a Design Model Sample implementations
![Page 2: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/2.jpg)
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
![Page 3: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/3.jpg)
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
![Page 4: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/4.jpg)
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)
![Page 5: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/5.jpg)
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
![Page 6: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/6.jpg)
System design & implementation 6
Design quality criteria in general
■ Minimization of coupling ■ Maximization of cohesion ■ Transparency ■ Maintainability
![Page 7: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/7.jpg)
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
![Page 8: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/8.jpg)
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
![Page 9: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/9.jpg)
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
![Page 10: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/10.jpg)
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
![Page 11: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/11.jpg)
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
![Page 12: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/12.jpg)
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
![Page 13: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/13.jpg)
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
![Page 14: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/14.jpg)
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
![Page 15: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/15.jpg)
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
![Page 16: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/16.jpg)
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
![Page 17: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/17.jpg)
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
![Page 18: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/18.jpg)
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
![Page 19: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/19.jpg)
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
![Page 20: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/20.jpg)
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)
![Page 21: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/21.jpg)
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
![Page 22: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/22.jpg)
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
![Page 23: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/23.jpg)
System design & implementation 23
Step 3: Specify architectural components
■ Specify component interfaces ■ Design general architectural facilities
➤ view update mechanism
![Page 24: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/24.jpg)
System design & implementation 24
Controller facilities
■ activation/termination of application functions ■ user interrupts for trace/background information ■ function abortion ■ handling transfer functions
![Page 25: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/25.jpg)
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
![Page 26: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/26.jpg)
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,
![Page 27: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/27.jpg)
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)
![Page 28: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/28.jpg)
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
![Page 29: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/29.jpg)
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
![Page 30: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/30.jpg)
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
![Page 31: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/31.jpg)
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
![Page 32: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/32.jpg)
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
![Page 33: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/33.jpg)
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
![Page 34: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/34.jpg)
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
![Page 35: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/35.jpg)
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)
![Page 36: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/36.jpg)
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
![Page 37: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/37.jpg)
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
![Page 38: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/38.jpg)
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
![Page 39: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/39.jpg)
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
![Page 40: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/40.jpg)
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
![Page 41: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/41.jpg)
System design & implementation 41
Trace Prolog system (1)
![Page 42: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/42.jpg)
System design & implementation 42
Trace Prolog system (2)
![Page 43: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/43.jpg)
System design & implementation 43
Trace Prolog system (3)
![Page 44: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/44.jpg)
System design & implementation 44
Trace Prolog system (4)
![Page 45: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/45.jpg)
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
![Page 46: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/46.jpg)
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
![Page 47: CommonKADS design and implementation](https://reader034.vdocuments.mx/reader034/viewer/2022042815/55770b08d8b42a0e058b53f8/html5/thumbnails/47.jpg)
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)