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. From analysis to design

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. 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. 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. Design quality criteria in general • Minimization of coupling • Maximization of cohesion • Transparency • Maintainability

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. Steps in system design

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. System architecture: three main sub-systems

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. 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. 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. 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. 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. System architecture: application model sub-system

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. 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. 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. 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. 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. 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. Step 3: Specify architectural components • Specify component interfaces • Design general architectural facilities • view update mechanism

24. Controller facilities • activation/termination of application functions • user interrupts for trace/background information • function abortion • handling transfer functions

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. 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. Application-model facilities (3) • Static role • access/query functions • Domain model • representational format • access/query functions • modification/analysis functions • Domain construct • (only inspected)

28. View facilities • Standard graphical visualizations • Generation of external formats • e.g. SQL query • Architectural view-update facilities • mapping table • message protocol

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. Typical interface format for tracer

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. 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. 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. 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. 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. 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. 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. 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. 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. Architecture Prolog system

41. Trace Prolog system (1)

42. Trace Prolog system (2)

43. Trace Prolog system (3)

44. Trace Prolog system (4)

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. Aion8 system architecture

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)