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 & implementation 2 From analysis to design

3. System design & implementation 3 System design n Input: ä knowledge model = problem-solving requirements ä communication model = interaction requirements ä other models = “non-functional” requirements n Output: ä specification of a software architecture ä design of the application within this architecture

4. System design & implementation 4 System architecture n Description of software in terms of: ä decomposition into sub-systems ä choice of control regime(s) ä decomposition of sub-systems into software modules n Focus point in the design process n Reference architecture for CommonKADS-based systems Cf. textbook of Sommerville (1995)

5. System design & implementation 5 Structure-preserving design “Preserve both the content and the structure of the analysis model during design” n Central modern design principle n Design is seen as “adding implementation-specific detail to the analysis results” n Preservation of information is key notion n Directly related to quality criteria

6. System design & implementation 6 Design quality criteria in general n Minimization of coupling n Maximization of cohesion n Transparency n Maintainability

7. System design & implementation 7 Quality criteria for KS design n Reusability of design elements / resulting code n Maintainability and adaptability ä one-step development is usually unrealistic, especially for knowledge-intensive systems n Explanatory power n Knowledge-elicitation/refinement ease ä knowledge changes over time

8. System design & implementation 8 Steps in system design

9. System design & implementation 9 Step 1: specify global architecture n Principle: separate functionality from interface issues n MVC architecture: ä developed for Smalltalk-80 ä distinction between application objects and their visualizations ä central control unit with event-driven regime

10. System design & implementation 10 System architecture: three main sub-systems

11. System design & implementation 11 Sub-system: application model n contains application data and functions = knowledge-model objects n data: ä knowledge bases ä dynamic data manipulated during reasoning (dynamic roles) n functions ä tasks, inferences, transfer functions

12. System design & implementation 12 Sub-system: views n visualizations of application data and functions n multiple visualizations possible n aggregate visualization of multiple application objects n requires architectural update/integrity mechanisms ä mapping table ä message protocol for state changes of objects

13. System design & implementation 13 Sub-system: controller n central “command & control unit” n provides handlers for external and internal events n enables activation of application functions n may define its own “control” views n may have internal clock plus agenda => demon-like behavior

14. System design & implementation 14 Some remarks about the MVC architecture n Developed in an object-oriented context n Is in fact functional decomposition of “objects” n Use not necessarily restricted to an O-O design/implementation approach n But: message passing paradigm fits well with required architectural facilities

15. System design & implementation 15 Decomposition of the application model sub-system n Criteria ä should enable structure-preserving design ä should enable integration with other SE approaches n Options ä functional or object-oriented decomposition n 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 design & implementation 16 System architecture: application model sub-system

17. System design & implementation 17 Step 2: Identify target implementation platform n Customer-specific requirements often constrain this choice = reason for early placement in the process n Software choice is nowadays much more important than hardware choice not true in case of real-time application n If choice is more or less free: ä consider to postpone until completion of step 3

18. System design & implementation 18 Platform criteria (1) n Library of “view” object classes may be a considerable amount to construct yourself n Declarative knowledge representation formalism? idem n Standard interfaces to other software ä e.g. ODBC, CORBA ä often required

19. System design & implementation 19 Platform criteria (2) n Language typing facilities ä weak typing usually implies more work in mapping analysis model (see Step 4a) n Control facilities/protocols n CommonKADS support ä dedicated platform extension (e.g. object library) ä link with CASE tool supporting CommonKADS

20. System design & implementation 20 Example environments: Prolog n View library: vendor-dependent n Declarative knowledge representation n DB interfaces: vendor-dependent n Weak language typing n No standard event-handling/message-passing control protocols n UvA tools provide some support (API)

21. System design & implementation 21 Example environments: Java n library of views n no declarative knowledge representation n DB interfaces n C++-like typing facilities n control facilities: e.g. multi-threading n currently no CommonKADS support

22. System design & implementation 22 Example environments: AionDS 8.0 n Library of view objects n (Semi-)declarative knowledge representation n ODBC/CORBA interfaces n O-O typing facilities (including relations) n O-O message passing protocol n CommonKADS support ä dedicated framework

23. System design & implementation 23 Step 3: Specify architectural components n Specify component interfaces n Design general architectural facilities ä view update mechanism

24. System design & implementation 24 Controller facilities n activation/termination of application functions n user interrupts for trace/background information n function abortion n handling transfer functions

25. System design & implementation 25 Application-model facilities (1) n Task: ä initialization and execute methods n Task method: ä control-language elements ä control-language declarativity n Inference ä execute, more-solutions?, has-solution? ä linking to inference methods

26. System design & implementation 26 Application-model facilities (2) n Inference method ä method library? ä enable many-to-many relation between inference and method n Transfer function ä implemented via message-passing pattern n Dynamic role ä data types allowed: “element”, “set”, “list” ?! ä access/update operations: select, subtract, append,

27. System design & implementation 27 Application-model facilities (3) n Static role ä access/query functions n Domain model ä representational format ä access/query functions ä modification/analysis functions n Domain construct ä (only inspected)

28. System design & implementation 28 View facilities n Standard graphical visualizations n Generation of external formats ä e.g. SQL query n Architectural view-update facilities ä mapping table ä message protocol

29. System design & implementation 29 User interfaces n End-user interface ä consider special facilities: natural language generation, …. ä use domain-specific visualizations => depends on application design n Expert interface ä trace interface ä edit/refine interface for knowledge bases

30. System design & implementation 30 Typical interface format for tracer

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. System design & implementation 32 Step 4a: map analysis info onto architecture n mapping tools have been constructed ä example: VOID API ä see web-site for information n extent of mapping depends on built-in design decisions in architecture

33. System design & implementation 33 Application design of controller n Main input: communication model n Often “hand work” needed n Minimum: bootstrapping procedure n Other functions: ä handling explanation requests ä user control over reasoning process ä reasoning interrupts / strategic control ä enabling “what-if” scenario’s

34. System design & implementation 34 Application model design Minimal set of application-design activities: n For each task method: ä construct operational control structure n For each dynamic role: ä choose a data type n For each inference: ä identify a map ä write a method-invocation call for the inference

35. System design & implementation 35 Application design of views n Select a view for each application object, if required n 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. System design & implementation 36 Prototyping: reasoner sub-system n 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” n Should be supported by implementation platform ä should be a matter of days to construct a prototype

37. System design & implementation 37 Prototype: mock-up agent interface n Test mock-up interface without full application functionality n When needed: ä complex external interaction (e.g.; HOMEBOTS) ä complex view formats ä complex view aggregations

38. System design & implementation 38 Distributed knowledge systems n Reasoning service ä application model functions as services ä no UI n Knowledge-base/ontology server ä example: GRASP server for art objects n Method service ä distributed system realized through a set of methods n Combinations

39. System design & implementation 39 Sample implementations n Housing application n Source code at web-site n “Academic” implementation ä public-domain Prolog n “Business” implementation ä Aion8 n Experiences show that prototypes of “running knowledge models” can be built within days

40. System design & implementation 40 Architecture Prolog system

41. System design & implementation 41 Trace Prolog system (1)

42. System design & implementation 42 Trace Prolog system (2)

43. System design & implementation 43 Trace Prolog system (3)

44. System design & implementation 44 Trace Prolog system (4)

45. System design & implementation 45 Aion8 system for “housing” n Realized as O-O “framework” ä roles, interfaces => multiple inheritance ä Hollywood principle n Includes task-template library facility n Default implementation of inferences

46. System design & implementation 46 Aion8 system architecture

47. System design & implementation 47 Key points n Design as a structure-preserving refinement process n Four-step design process n Support can be provided by: ä CommonKADS architecture ä knowledge/communication-model transformation tools ä dedicated platforms with “CommonKADS packages” n “Rational design: how and why to fake it” (Parnas & Clements)