CommonKADS design and implementation

3,061 views

Published on

Ch. 11-12 of the CommonKADS textbook

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,061
On SlideShare
0
From Embeds
0
Number of Embeds
193
Actions
Shares
0
Downloads
67
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CommonKADS design and implementation

  1. 1. System design and implementation Design principles and quality criteria CommonKADS system architecture Four steps in creating a Design Model Sample implementations
  2. 2. System design & implementation 2 From analysis to design Applic ation domain S oftware s ys tem communication model knowledge model tas k model agent model organiz ation model des ign 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. 3. 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
  4. 4. 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)
  5. 5. 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
  6. 6. System design & implementation 6 Design quality criteria in general ■  Minimization of coupling ■  Maximization of cohesion ■  Transparency ■  Maintainability
  7. 7. 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
  8. 8. System design & implementation 8 Steps in system design des ign   architecture s pecify hw/s w  platform detailed architecture s pecification detailed application des ign S tep  1 S tep  2 S tep  3 S tep  4 C ommonKAD S   reference architecture list  of available environments checklist of  architecure decisions predefined mappings to  architecture s upport  knowledge  for   C ommonK ADS  des ign
  9. 9. 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
  10. 10. System design & implementation 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 S ensors Databases User  interface E xternal  system   interface    
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. System design & implementation 16 System architecture: application model sub-system dynamic  role datatype domain-­‐mapping current  binding access/update functions tas k I/O  roles method execute trans fer function I/O  roles tas k  method intermediate  roles control  specification execute s tatic  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  cons truct
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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)
  21. 21. 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
  22. 22. 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
  23. 23. System design & implementation 23 Step 3: Specify architectural components ■  Specify component interfaces ■  Design general architectural facilities ➤  view update mechanism
  24. 24. System design & implementation 24 Controller facilities ■  activation/termination of application functions ■  user interrupts for trace/background information ■  function abortion ■  handling transfer functions
  25. 25. 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
  26. 26. 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,
  27. 27. 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)
  28. 28. 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
  29. 29. 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
  30. 30. System design & implementation 30 Typical interface format for tracer S tatic  role  bindings  Applic ation  trac er   T ask  control E X E C UTING    task  t2 RE P E AT NE W -­‐S OLUTION(inference  B)  inference  A   inference  B UNTIL  HAS -­‐S OLUTION(inference  D) Dynamic  role  bindings Inference  structure Domain  knowledge  used  by  inference  A IF  obj.a1  >  2  AND  obj.a2  <  4 THE N  obj.a3  =  "xyz" IF  obj.a1  =<  2 THE N  obj.a3  =  "abc" object  1 object  1 object  2 object  3 object  4 object  5 R ole  X R ole  Y R ole  Z R ole  U R ole  V R ole  W object  7object  6 X ZB A D C U V W    
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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)
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. System design & implementation 40 Architecture Prolog system S WI-­‐Prolog  (+XPCE) O-­‐O  kernel inference method library CommonKADS  kernel "model""controller" "views" architectural facilities application realization implementation platform    
  41. 41. System design & implementation 41 Trace Prolog system (1)
  42. 42. System design & implementation 42 Trace Prolog system (2)
  43. 43. System design & implementation 43 Trace Prolog system (3)
  44. 44. System design & implementation 44 Trace Prolog system (4)
  45. 45. 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
  46. 46. System design & implementation 46 Aion8 system architecture C ommonKADS  L ibrary Framework  L ibrary housing application assessment template framework layer C ommonK ADS layer task-­‐template layer application layer <other  applications> <other  templates> assessment framework
  47. 47. 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)

×