05 km templates

7/31/2019 05 Km Templates

1/68

Template knowledge models

Reusing knowledge model elements


2/68

Template knowledge models 2

Lessons

Knowledge models partially reused in newapplications

Type of task = main guide for reuse

Catalog of task templates small set in this book

see also other repositories


3/68


The need for reuse

prevent "re-inventing the wheel"

cost/time efficient

decreases complexity

quality-assurance


4/68


Task template

reusable combination of model elements

(provisional) inference structure

typical control structure

typical domain schema from task point-of-view

specific for a task type

supports top-down knowledge modeling


5/68


A typology of tasks

range of task types is limited

advantage of KE compared to general SE

background: cognitive science/psychology

several task typologies have been proposed in theliterature

typology is based on the notion of system


6/68


The term system

abstract term for object to which a task is applied.

in technical diagnosis: artifact or device beingdiagnosed

in elevator configuration: elevator to be designed does not need to exist (yet)


7/68Template knowledge models 7

Analytic versus synthetic tasks

analytic tasks

system pre-exists

it is typically not completely "known"

input: some data about the system,

output: some characterization of the system

synthetic tasks

system does not yet exist

input: requirements about system to be constructed

output: constructed system description



Task hierarchy

knowledge-

intensive

task

analytic

task

classification

synthetic

task

assessment

diagnosis

configuration

design

planning

scheduling

assignment

modelling

prediction

monitoring

design



Structure of templatedescription in catalog

General characterization

typical features of a task

Default method

roles, sub-functions, control structure, inference structure Typical variations

frequently occurring refinements/changes

Typical domain-knowledge schema

assumptions about underlying domain-knowledge structure



Classification

establish correct class for an object

object should be available for inspection

"natural" objects

examples: rock classification, apple classification terminology: object, class, attribute, feature

one of the simplest analytic tasks; many methods

other analytic tasks: sometimes reduced to

classification problem especially diagnosis



Classification:pruning method

generate all classes to which the object may belong

specify an object attribute

obtain the value of the attribute

remove all classes that are inconsistent with thisvalue


12/68


Classification:inference structure

object

class

attribute

feature

truthvalue

generate

specify

match

obtain


13/68


Classification:method control

while new-solution generate(object -> candidate) docandidate-classes := candidate union candidate-classes;

while new-solutionspecify(candidate-classes -> attribute)

and length candidate-classes > 1 doobtain(attribute -> new-feature);

current-feature-set := new-feature union current-feature-set;

for-each candidate in candidate-classes do

match(candidate + current-feature-set -> truth-value);

if truth-value = false;then candidate-classes := candidate-classes subtract candidate;


14/68


Classification:method variations

Limited candidate generation

Different forms of attribute selection

decision tree

information theory user control

Hierarchical search through class structure


15/68


Classification:domain schema

object type

attribute

value: universal

object class

class

constraint

requires

has-attributeclass-of

2+ 1+


16/68


Rock classification

volcanic

rock

igneousrock

plutonic

rock

syenite diorite

peridotite dunite

mineral

rock

texturegrain sizecolour

mineral

content

percentagepresence

1+

mineral content

constraint

silicate

neso

silicate

tecto

silicate

olivine quartz

mineralsontology


17/68


Nested classification

rock

rockclassifcation

minerals

obtain: Quartz percentage

mineralclassification

Quartz olivine

sub-task

identifyQuartz

contains


18/68


Rock classification prototype


19/68


Assessment

find decision category for a case based on domain-specific norms.

typical domains: financial applications (loan

application), community service terminology: case, decision, norms

some similarities with monitoring

differences:

timing: assessment is more static

different output: decision versus discrepancy


20/68


Assessment:abstract & match method

Abstract the case data

Specify the norms applicable to the case

e.g. rent-fits-income, correct-household-size

Select a single norm Compute a truth value for the norm with respect to

the case

See whether this leads to a decision

Repeat norm selection and evaluation until a decisionis reached


21/68


Assessment:inference structure

case

abstractedcase norms

normvaluedecision

abstract

select

match

specify

evaluate norm


22/68


Assessment:method control

while new-solution abstract(case-description -> abstracted-case)do

case-description := abstracted-case;

end while

specify(abstracted-case -> norms);

repeat

select(norms -> norm);

evaluate(abstracted-case + norm -> norm-value);

evaluation-results := norm-value union evaluation-results;

until has-solution match(evaluation-results -> decision);


23/68


Assessment control:UML notation

abstract

specifynorms

selectnorm

matchdecision

evaluatenorm

[more abstractions]

[no moreabstractions] [match fails

no decision][match succeeds:decision found]


24/68


Assessment:method variations

norms might be case-specific

cf. housing application

case abstraction may not be needed

knowledge-intensive norm selection random, heuristic, statistical

can be key to efficiency

sometimes dictated by human expertise

only acceptable if done in a way understandable to experts


25/68


Assessment:domain schema

case

case

datum

case datum

value: universal

decisionnorm

truth-value: booleanindicates

hasabstraction

implies

decision

rule

requirement

abstraction

rule

1+

1+

1+


26/68


Claim handling forunemployment benefits

:claim

collectdata

dataentry

decideabout claim

computebenefit

sendnotification prepare

payment

[no right][right]

claim handling finacialdepartment


27/68


Decision rules forclaim handling

WW benefitrequirement

WW benefit

right

benefit decision

rule

DEFINES

insured = falseDEFINESWW-benefit-right.value = no-right

iunemployed = falseDEFINESWW-benefit-right.value = no-right

weeks-worked-requirement = falseDEFINESWW-benefit-right.value = no-right

insured = true ANDunemployed = true ANDweeks-worked--requirement = true ANDyears-worked-requirement = falseDEFINESWW-benefit-right.value = short-benefit

insured = true ANDunemployed = true ANDweeks-worked--requirement = true ANDyears-worked-requirement = trueDEFINESWW-benefit-right.value = long-benefit


28/68


Diagnosis

find fault that causes system to malfunction example: diagnosis of a copier

terminology: complaint/symptom, hypothesis, differential, finding(s)/evidence,

fault

nature of fault varies state, chain, component

should have some model of system behavior default method: simple causal model

sometimes reduced to classification task direct associations between symptoms and faults

automation feasible in technical domains

Di i


29/68


Diagnosis:causal covering method

Find candidate causes (hypotheses) for the complaintusing a causal network

Select a hypothesis

Specify an observable for this hypothesis and obtainits value

Verify each hypothesis to see whether it is consistentwith the new finding

Continue this process until a single hypothesis is leftor no more observables are available

Di i


30/68


Diagnosis:inference structure

complaint

cover

specify

select obtain

hypothesis

observable

finding

hypothesis

verify

result

Di i


31/68


Diagnosis:method control

while new-solution cover(complaint -> hypothesis) do

differential := hypothesis add differential;

end while

repeat

select(differential -> hypothesis);

specify(hypothesis -> observable);obtain(observable -> finding);

evidence := finding add evidence;

foreach hypothesis in differential do

verify(hypothesis + evidence -> result);

if result = false then differential := differential subtract hypothesis

until length differential =< 1 or no observables left

faults := hypothesis;

Di i


32/68


Diagnosis:method variations

inclusion of abstractions

simulation methods

see literature on model-based diagnosis

library of Benjamins

Di i


33/68


Diagnosis:domain schema

systemfeature

system

observable

value: universal

system

state

status: universal

fault

prevalence: number[0..1]

system

state

system

featurecan cause

causal

dependency


34/68


Monitoring

analyze ongoing process to find out whether it behavesaccording to expectations

terminology:

parameter, norm, discrepancy, historical data

main features: dynamic nature of the system

cyclic task execution

output "just" discrepancy => no explanation

often: coupling monitoring and diagnosis output monitoring is input diagnosis

M it i


35/68


Monitoring:data-driven method

Starts when new findings are received

For a find a parameter and a norm value is specified

Comparison of the find with the norm generates a

difference description This difference is classified as a discrepancy using

data from previous monitoring cycles

M it i


36/68


Monitoring:inference structure

newfinding

select

systemmodel

specifycompare

classify

parameter

difference

norm

discrepancy

historicaldata

receive

Monitoring


37/68


Monitoring:method control

receive(new-finding);

select(new-finding -> parameter)

specify(parameter -> norm);

compare(norm + finding -> difference);

classify(difference + historical-data -> discrepancy);

historical-data := finding add historical-data;

Monitoring


38/68


Monitoring:method variations

model-driven monitoring

system has the initiative

typically executed at regular points in time

example: software project management

classification function treated as task in its won right

apply classification method

add data abstraction inference


39/68


Prediction

analytic task with some synthetic features

analyses current system behavior to constructdescription of a system state at future point in time.

example: weather forecasting often sub-task in diagnosis

also found in knowledge-intensive modules ofteaching systems e.g. for physics.

inverse: retrodiction: big-bang theory


40/68


Synthesis

Given a set of requirements, construct a systemdescription that fulfills these requirements

"P166 processor requires 16Mb"

"prefer cheap est component"

preference

constraint

"price lower than $2,000"

"fast sys tem"

hard requirement

soft requirement

requirements(external) constraints & preferences(internal)


41/68


Ideal synthesis method

Operationalize requirements

preferences and constraints

Generate all possible system structures

Select sub-set of valid system structures obey constraints

Order valid system structures

based on preferences

Synthesis:


42/68


Synthesis:inference structure

requirements

hardrequirements

softrequirements

possiblesystem

structures

list of preferredsystem s tructures

valid systemstructures

constraints

preferences

preferenceordering

knowledge

systemcompositionknowledge

operationalize

generate

selectsubset

sort


43/68


Design

synthetic task

system to be constructed is physical artifact

example: design of a car

can include creative design of components creative design is too hard a nut to crack for current

knowledge technology

sub-type of design which excludes creative design =>

configuration design


44/68


Configuration design

given predefined components, find assembly thatsatisfies requirements + obeys constraints

example: configuration of an elevator; or PC

terminology: component, parameter, constraint, preference,requirement (hard & soft)

form of design that is well suited for automation

computationally demanding

Elevator configuration:


45/68


Elevator configuration:knowledge base reuse

Configuration:


46/68


Configuration:propose & revise method

Simple basic loop:

Propose a design extension

Verify the new design,

If verification fails, revise the design

Specific domain-knowledge requirements

revise strategies

Method can also be used for other synthetic tasks

assignment with backtracking

skeletal planning

Configuration:


47/68


Configuration:method decomposition

requirements

softrequirements

hard

requirements

skeletal

design

design

extension

violationtruthvalue

action

actionlist

operationalize

critique

modify

verify

specify

propose

select

Configuration:


48/68


Configuration:method control

operationalize(requirements -> hard-reqs + soft-reqs);specify(requirements -> skeletal-design);

whilenew-solution propose(skeletal-design + design +soft-reqs -> extension) dodesign := extension union design;

verify(design + hard-reqs -> truth-value + violation);if truth-value = false then

critique(violation + design -> action-list);

repeat select(action-list -> action);

modify(design + action -> design);

verify(design + hard-reqs -> truth-value + violation);

until truth-value = true;

end while

Configuration:


49/68


Configuration:method variations

Perform verification plus revision only when for alldesign elements a value has been proposed.

can have a large impact on the competence of the method

Avoid the use of fix knowledge

Fixes are search heuristics to navigate the potentiallyextensive space of alternative designs

alternative: chronological backtracking

Configuration:


50/68


Configuration:domain schema

design element

parameter

value: universal

component

model list: list

fix act ion

action type

constraint

design

element

component

calculat ion

expression

constraint

expression

computes

implies

1+

1+

1+

1+ fix

has-parameter

0+

defines

preference

preference

rating: universal

preference

expression

1+

Types of configuration may


51/68


Types of configuration mayrequire different methods

Parametric design

Assembly is largely fixed

Emphasis on finding parameter values that obey globalconstraints and adhere to preferences

Example: elevator design

Layout

Component parameters are fixed

Emphasis on constructing assembly (topological relations)

Example: mould configuration Literature: Motta (1999), Chandrasekaran (1992)


52/68


Assignment

create mapping between two sets of objects

allocation of offices to employees

allocation of airplanes to gates

mapping has to satisfy requirements and be

consistent with constraints

terminology

subject, resource, allocation

can be seen as a degenerative form of configuration

design

Assignment:


53/68


Assignment:method without backtracking

Order subject allocation to resources by selecting firsta sub-set of subjects

If necessary: group the subjects into subject-groupsfor joint resource assignment

requires special type of constraints and preferences

Take an subject(-group) and assign a resource to it.

Repeat this process until all subjects have a resource

Assignment:


54/68


Assignment:inference structure

subjectssubject

set

subjectgroup

resourceresources

currentallocations

selectsubset

group

assign

Assignment:


55/68


Assignment:method control

while not empty subjects doselect-subset(subjects -> subject-set);

while not empty subject-set do

group(subject-set -> subject-group);

assign(subject-group + resources + current-allocations ->

resource);current-allocations := < subject-group, resource > union

current-allocations;

subject-set := subject-set/subject-group;

resources := resources/resource;

end whilesubjects := subjects/subject-set;

end while

Assignment:


56/68


Assignment:method variations

Existing allocations

additional input

subject-specific constraints and preferences

see synthesis and configuration-design


57/68


Planning

shares many features with design

main difference: "system" consists of activities plustime dependencies

examples:travel planning; planning of building activities

automation only feasible, if the basic plan elementsare predefined

consider use of the general synthesis method (e.g

therapy planning) or the configuration-design method


58/68


Planning method

plan goal

hardrequirements

softrequirements

possibleplans

list of preferredplans

valid plans

constraints

preferences

preferenceordering

knowledge

plancompositionknowledge

operationalize

generate

selectsubset

sort

requirements


59/68


Scheduling

Given a set of predefined jobs, each of whichconsists of temporally sequenced activities calledunits, assign all the units to resources at time slots

production scheduling in plant floors

Terminology: job, unit, resource, schedule

Often done after planning (= specification of jobs)

Take care: use of terms planning and scheduling

differs

Scheduling:


60/68


Scheduling:temporal dispatching method

Specify an initial schedule

Select a candidate unit to be assigned

Select a target resource for this unit

Assign unit to the target resource Evaluate the current schedule

Modify the schedule, if needed

Scheduling:


61/68


Scheduling:inference structure

job

schedule

candidateunit

targetresource

truthvaluespecify

modify

verify

assign

select

select

Scheduling:


62/68


Scheduling:method control

specify(jobs -> schedule);

while new-solution select(schedule -> candidate-unit) do

select(candidate-unit + schedule -> target-resource);

assign(candidate-unit + target-resource -> schedule);

evaluate(schedule -> truth-value);

if truth-value = false then

modify(schedule -> schedule);

end while

Scheduling:


63/68


Sc edu gmethod variations

Constructive versus repair method

Refinement often necessary

see scheduling literature

catalog of Hori (IBM Japan)

Scheduling: typical


64/68


g ypdomain schema

schedule job

release-date: timedue-date: time

unit

start: timeend: timeresource-type: string

resource

type: stringstart-time: timeend-time: time

includes

{dynamicallylinked}

{temporallyordered}

job unit

preference

constraint

is performed at

resource

capacity

constraint


65/68


Modeling

included for completeness

"construction of an abstract description of a systemin order to explain or predict certain systemproperties or phenomena"

examples:

construction of a simulation model of nuclear accident

knowledge modeling itself

seldom automated => creative steps

exception: chip modeling

In applications:


66/68


pptypical task combinations

monitoring + diagnosis

Production process

monitoring + assessment

Nursing task

diagnosis + planning

Troubleshooting devices

classification + planning

Military applications

Example: apple-pest


67/68


p pp pmanagement

mintorcrop

identifypest

planmeasure

executeplan

[possible threat]

[possible pest]


68/68

Comparison with O-O analysis

Reuse of functional descriptions is not common in O-O analysis

notion of functional object

But: see work on design patterns

strategy patterns

templates are patterns of knowledge-intensive tasks

Only real leverage from reuse if the patterns arelimited to restricted task types

05 km templates

Documents