Upload
annabel-thomasine-lawrence
View
215
Download
0
Embed Size (px)
Citation preview
System design and implementation
Design principles and quality criteria
CommonKADS system architecture
Four steps in creating a Design Model
Sample implementations
System design & implementation
2
From analysis to design
Applicationdomain
Softwaresystem
communicationmodel
knowledgemodel
taskmodel
agentmodel
organizationmodel
designmodel
experts
textbooks
protocols
cases
reasoningstrategies
requiredresponse time
Analysismodels
problems &opportunities
implementationlanguage
softwarearchitecture
hardwareplatform
algorithmdesign
datastructuredesign
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
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)
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
System design & implementation
6
Design quality criteria in general
Minimization of coupling Maximization of cohesion Transparency Maintainability
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
System design & implementation
8
Steps in system design
design architecture
specifyhw/sw platform
detailedarchitecturespecification
detailedapplication
design
Step 1 Step 2 Step 3 Step 4
CommonKADS referencearchitecture
list ofavailableenvironments
checklistof architecuredecisions
predefinedmappingsto architecture
support knowledge for CommonKADS design
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
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 outputto external agents
(user interface,database query)
handles input from external
agentsand from
internal functions
resultreport
updatesfunction
invocationsinformation
access
controllerviews
User Input
Sensors
Databases
User interface
External system interface
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
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
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
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
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
System design & implementation
16
System architecture: application model sub-system
dynamic role
datatypedomain-mappingcurrent binding
access/updatefunctions
task
I/O rolesmethod
execute
transferfunction
I/O roles
task method
intermediate rolescontrol specification
execute
static role
domain-mapping
access functions
domain model
domain-model nameuses
access functionsinferencing functions
inference
I/O rolesstatic rolesmethod
give-solutionmore-solutions?has-solution?
inference method
algorithm speclocal vars
execute
domain construct
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 choicenot true in case of real-time application
If choice is more or less free: consider to postpone until completion of step 3
System design & implementation
18
Platform criteria (1)
Library of “view” object classesmay be a considerable amount to construct yourself
Declarative knowledge representation formalism?idem
Standard interfaces to other software e.g. ODBC, CORBA often required
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
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)
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
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
System design & implementation
23
Step 3: Specify architectural components
Specify component interfaces Design general architectural facilities
view update mechanism
System design & implementation
24
Controller facilities
activation/termination of application functions user interrupts for trace/background information function abortion handling transfer functions
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
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,
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)
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
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
System design & implementation
30
Typical interface format for tracer
Static role bindings
Application tracer
Task control
EXECUTING task t2
REPEATNEW-SOLUTION(inference B)
inference A
inference B
UNTIL HAS-SOLUTION(inference D)
Dynamic role bindings
Inference structure
Domain knowledge used by inference A
IF obj.a1 > 2 AND obj.a2 < 4THEN obj.a3 = "xyz"
IF obj.a1 =< 2THEN obj.a3 = "abc"
object 1object 1object 2
object 3
object 4object 5
Role X Role Y Role Z
Role U Role V Role W
object 7object 6
X ZB
A
D
C
U
V
W
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
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
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
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
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)
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
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
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
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
System design & implementation
40
Architecture Prolog system
SWI-Prolog (+XPCE)
O-O kernel
inferencemethodlibrary
CommonKADS kernel
"model""controller"
"views"
architecturalfacilities
applicationrealization
implementationplatform
System design & implementation
41
Trace Prolog system (1)
System design & implementation
42
Trace Prolog system (2)
System design & implementation
43
Trace Prolog system (3)
System design & implementation
44
Trace Prolog system (4)
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
System design & implementation
46
Aion8 system architecture
CommonKADS Library
Framework Library
housingapplication
assessmenttemplate
frameworklayer
CommonKADSlayer
task-templatelayer
applicationlayer
<other applications>
<other templates>
assessmentframework
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)