System design and implementation Design principles and quality

System design and implementation Design principles and quality criteria Common. KADS system architecture Four steps in creating a Design Model Sample implementations System design & implementation

From analysis to design System design & implementation 2

System design n Input: ä ä ä n 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 3

System architecture n Description of software in terms of: ä ä ä n n 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 Common. KADS-based systems Cf. textbook of Sommerville (1995) System design & implementation 4

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

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

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

Steps in system design System design & implementation 8

Step 1: specify global architecture n n 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 9

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

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

Sub-system: views n n 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 12

Sub-system: controller n n n 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 13

Some remarks about the MVC architecture n n 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 14

Decomposition of the application model sub-system n Criteria ä ä n Options ä n should enable structure-preserving design should enable integration with other SE approaches 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 15

System architecture: application model sub-system System design & implementation 16

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

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

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

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

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

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

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

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

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

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

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

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

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

Typical interface format for tracer System design & implementation 30

Step 4: specify application within architecture Step 4 a: “map analysis info onto architecture” ä ä ensures structure-preserving approach manual mapping is cumbersome Step 4 b: “add design details” ä list of design details that need to be added to complete operationalization of an analysis model System design & implementation 31

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

Application design of controller n n 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 33

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

Application design of views n n 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 35

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

Prototype: mock-up agent interface n n 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 37

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

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

Architecture Prolog system System design & implementation 40

Trace Prolog system (1) System design & implementation 41

Trace Prolog system (2) System design & implementation 42

Trace Prolog system (3) System design & implementation 43

Trace Prolog system (4) System design & implementation 44

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

Aion 8 system architecture System design & implementation 46

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