Knowledge Modeling with UML
Knowledge Modeling is the visualization of knowledge
patterns. These patterns are discovered through knowledge acquisition. During
the knowledge acquisition process the knowledge engineer works with the domain expert(s)
to uncover and document the results of their meetings. To elicit feedback from
the domain experts the knowledge engineer will develop certain knowledge models
to visualize what has been learned from the domain expert(s).
As we learned from our chapter on knowledge modeling our
focus has been on five (5) major representations of knowledge. These
representations include Ladders, Network Diagrams, Tables, Grids, Decision
Trees and Case-based Reasoning. This chapter (Knowledge modeling with UML) will
examine the knowledge modeling and UML concepts learned in previous chapters
and combined the two concepts. We will specifically examine building UML
knowledge models for the following, Ladders, Network Diagrams, and Decision
Trees. The Unified Modeling Language (UML) will be used as the notation or
language to construct these types of models. To begin we will first determine
if the domain is appropriate to knowledge acquisition and knowledge modeling.
The following represents an approach to domain analysis and
knowledge acquisition. Although there may be several approaches that may be
applicable, based on research conducted through the National Science Foundation
the following method is more likely to be successful:[1]
- Domain
analysis has two components: appropriateness and probability of success.
This ontology should drive the choice of questions to be asked by the
knowledge engineer. The ontology should be extensible, either generally or
as customized by specific end-users. Probability of success will be driven
by rules and/or similarity to a case from a case-base (see Case Based
Reasoning Chapter 7).
- Appropriateness
and probability of success related to ROI, the issue of "what counts
as a domain" is both interesting and important. Some problems may be
too general, some too specific. Granularity may have to be taken into
account during appropriateness evaluation. A domain may become
inappropriate if its scope is changed during specification.
3.
Given the reality of today's business climate, and the
foreseeable future, a domain may be deemed appropriate if (its knowledge-based
implementation) helps reduce labor needs within an organization (see Knowledge
Value – Chapter 2).
4.
Implementing the Kline and Dolins architecture questions to
help determine appropriate approach. There categories include:
a. Is Deep Reasoning or Shallow
Reasoning needed to solve problems within the domain?
b. What are the key problem
characteristics within the domain?
c. What are characteristics of typical input provided
during problem solution?
d. Aspects of knowledge
representation
e. What knowledge (if any) can we
bring to bear to solve problems within the domain?
f. Details of the problem-solving
process
g. Solution characteristics
h. How will end-users interaction
with the program?
The guidelines contained within Kline and Dolins also can be
used to detect sub-optimal use of techniques or the need to re-design an
application to make it more amenable to a particular technique, should a
favored one surface.
Once the appropriateness of the domain has been determined,
knowledge acquisition and knowledge modeling techniques can be applied. We will
now examine how to apply UML to knowledge modeling.
UML Applied to Knowledge Models:
The Unified
Modeling Language (UML) will be used as the central modeling notation to
capture knowledge from a specific domain. The knowledge that will be captured
via UML will typically be tacit and/or explicit in nature. The UML will be
adopted to construct several types of knowledge modeling constructs. These
constructs include:
-
Laddering, which is a tree-like structure that is used to
capture concepts, complex entities (machines, organizations and documents),
decisions, properties associated with concepts and processes
-
Network Diagrams, which include:
o
Concept Maps - A concept map is a type of diagram that shows
knowledge objects as nodes and the relationships between them as links (usually
labeled arrows).
o
Process Maps - This type of diagram shows the inputs,
outputs, resources, roles and decisions associated with each process or task in
a domain. The process map is an excellent way of representing information of
how and when processes, tasks and activities are performed.
o
State Transition Networks - A transition network is a set of
states and the transitions between them. As noted above, they are good at
capturing the notion of process. For example:
·
Control processes such as those in a digitally controlled
heating system.
·
Processes controlling manufacture or design.
·
Workflow processes such as those found in product data
management software.
-
Decision Trees (also a tree-like structure) - Decision trees
classify instances by
sorting them down the tree from the root
node to some leaf node,
which provides the classification of the instance. Each node in the tree
specifies a test of
some attribute of the
instance, and each branch
descending from that node corresponds to one of the possible values for this attribute. This type
of construct is an excellent way to represent tacit knowledge as a set of rules
for implementation into a rules-based system.
The first step to knowledge
modeling is to capture the knowledge of the domain. In order to do so we must
construct use cases, specifically knowledge use cases. When constructing
knowledge use cases we will produce both a visual model with a knowledge use
case model as well as the textual version in the form of a knowledge use case
specification.
Knowledge Use
Case Model:
The knowledge use case model will
consist of the same widgets as a traditional use case model. However, the
traditional stick figure representing an actor will also represent the human
agent, see figure “Knowledge Use Case Model” below.
Knowledge Use Case
Specification
Use Case Specifications describe the behavior of the system under development (see Chapter 10). What makes a Knowledge Use Case Specification (KUCS) different from other use cases that describe the system is that a KUCS describes the knowledge process of the system (see figure Knowledge Production Use Case Specification Sample). As discussed in chapter 10, a use case defines a set of sequences of actions or scenarios that the system is to perform. These set of actions have an observable benefit to the actor(s). The relationship between business process and use cases shows that when an IT application is viewed functionally it is viewed as performing a set of use cases supporting various tasks within the system under development. In a Knowledge Management System (KMS) the use cases will support knowledge production process, which include knowledge validation. In an KMS it will also support the various activities in the knowledge management process. The KUCS that are developed will support the human agents, which interact with the KMS (see Figure Knowledge Process and KUCS).
Knowledge
Process and KUCS
The
knowledge use case may be described at various levels of abstraction or
concreteness. To develop an overall understanding of the knowledge management
system (KMS) we must first focus on the “high-level” use cases. These are the
use cases that describe the KMS functionality at an abstract or “20,000 foot
level”.
An example
of a high-level use case would be to “Perform Knowledge Discovery in a
Database” the following is a set of tasks that the use case will perform:
- Retrieve and display
strategic, tactical goals and objectives and results of knowledge
discovery
- Select entity objects
representing business domains to be mined for new knowledge
- Explore data and clean
for modeling
- Record and transform
data
- Reduce data
- Select variables for
modeling
- Transform variables
- Perform measurement
modeling
- Select modeling
techniques
- Estimate models
- Validate models
Each task in
the Perform Knowledge Discovery in a Database use case could itself be a use
case. Only through further analysis would we know for sure. However, since this
is a high-level abstraction we can conclude that the more abstract use case
will decompose into more concrete use cases. Further we can classify use cases
in the KMS by whether they support knowledge production (KP), knowledge
integration (KI) or knowledge management (KM) and even further whether they
support the various sub-processes and activities in the KP, KI, or KM
processes. The following are examples of KUCS classified as KP, KI or KM.[2]
Knowledge Production Use Cases
Information
Acquisition
o
Performing cataloging and tracking of previously acquired enterprise
data, information and knowledge bases related to business processes
o
Perform cataloging and tracking of external data, information and
knowledge bases related to enterprise business processes
o
Order data, information, or external claimed knowledge and have it
shipped from an external source
o
Purchase data, information, or external knowledge claims
o
Extract, reformat, scrub, transform, stage, and load, data, information
and knowledge claims acquired from external sources.
Knowledge Claim Formulation
o
Prepare data, information and knowledge for analysis and analytical
modeling
o
Update all data, information and knowledge stores to maintain
consistency with changes introduced into the KMS
o
Perform analysis and modeling including revising, reformulating, and
formulating models and knowledge discovery in databases with respect to:
o
Planning and planning models
o
Descriptions and descriptive models
o
Measurement Modeling
o
Cause-Effect analyzing and modeling
o
Predictive and time-series forecasting and modeling
o
Assessment Modeling
Knowledge Claim Validation
-
Test competing knowledge models and claims using appropriate analytical
techniques, data, and validation criteria
-
Assess test results and compare competing knowledge models and claims
-
Store outcomes of information acquisition, individual and group learning,
knowledge claim formulation, and other knowledge claim validation activities
into data, information, or knowledge store accessible through electronic
queries
-
Load into data, information, or knowledge and updates into enterprise
stores and provide access to enterprise query and reporting tools
Knowledge
Integration Use Cases:
Storing the outcomes of knowledge integration
activities into an accessible data, information, or knowledge store
Searching/Retrieving Stored Data, Information, or
Knowledge
-
Receiving transmitted into data, information, or
knowledge through e-mail, automated alerts, and data, information, and
knowledge base updates
-
Retrieving through computer-based querying data, information and
knowledge of the following types:
o
Planning
o
Descriptive
o
Cause/Effect
o
Predictive and Time –series Forecasting
o
Assessment
-
Search/Retrieve from enterprise stores through computer-based querying,
data, information, and knowledge of the following types:
o
Planning
o
Descriptive
o
Cause/Effect
o
Predictive and Time –series Forecasting
o
Assessment
-
Use e-mail to request assistance from personal networks
Broadcasting
-
Publish and disseminate data,
information, and knowledge using the enterprise intranet
-
Present knowledge using the
KMS
Sharing
-
Use e-mail to request
assistance from personal networks
-
Share data, information, and
knowledge through collaboration spaces
Teaching
-
Present e-learning or
CBT modules to knowledge workers, delivered through the KMS (see Chapter 2 - figure
Knowledge Management System Components)
Knowledge Management Use Cases
Leadership
-
Identify knowledge management responsibilities based on
segmentation or decomposition of the KM process
-
Retrieve available qualification information on knowledge management
candidates for appointment
-
Evaluate available candidates according to rules relating
qualifications to predicted performance
-
Communicate appointments to knowledge management
constituency
-
Plan and schedule motivational events
Building External Relationships
-
Communicate with external individuals through e-mail and
online conferencing technology
KM
Knowledge Production
-
All knowledge production and knowledge integration use cases
specified for knowledge processing
-
Specify and compare alternative KM options in terms of
anticipated costs and benefits
KM
Knowledge Integration
-
Querying and reporting using data, information and knowledge
about KM staff plans, KM staff performance description, KM staff performance cause/effect
analysis, and KM staff performance prediction and forecasting
-
Querying and reporting using data, information, and
knowledge about accessing KM staff performance in terms of costs and benefits
Crisis Handling
-
Search/retrieve from enterprise stores through querying and reporting,
data, information, and knowledge of the following types about crisis potential:
o
Planning
o
Descriptive
o
Cause/Effect
o
Predictive and Time –series Forecasting
o
Assessment
Changing
Knowledge-processing Rules
-
Search/retrieve from enterprise stores through computer-based querying
data, information, and knowledge of the following types about knowledge process
rules:
o
Planning
o
Descriptive
o
Cause/Effect
o
Predictive and Time –series Forecasting
o
Assessment
-
Communicate rule-changing directives through e-mail
Allocating Resources
-
Select training programs(s)
-
Purchase training vehicles and materials
The above listing only
provides a more concrete idea of the nature of the KMS use cases that relate to
knowledge acquisition. To gain an understanding of the magnitude of use cases
that are needed to cover all aspects of a KMS further analysis is needed. Your
analysis should center on the Knowledge Management System Components detailed
in chapter 2 (i.e. Workflow, E-learning, Knowledge Acquisition, CRM,
Collaboration and Document Management).
UML to Create Knowledge Models
The
following describes the relationship between traditional knowledge modeling
techniques described in chapter 9 with their Unified Modeling Language (UML)
counterpart.
Concept Ladder
A
concept ladder shows classes of concepts and their sub-types (see chapter 9).
All relationships in a concept ladder take the form ‘is a’. For example a whale is a mammal. The
following represents an example of a concept ladder constructed in UML:
This UML diagram
utilizes the class diagram construct. Each ‘is a ‘ relationship is associated
with a generalization as a stereotype pointing back to the parent class.
A composition ladder shows the way a knowledge object is
composed of its constituent parts (see chapter 9). The following is an example
of a composition ladder constructed in UML:
Composition Ladder
A decision ladder shows the alternative courses of action
for a particular decision (see chapter 9). The following is an example of a
concept ladder constructed in UML:
Decision
Ladder
An attribute ladder shows attributes and values. All the
adjectival values relevant to an attribute are shown as sub-nodes, but
numerical values are not usually shown (see chapter 9). The following is an
example of a concept ladder constructed in UML:
Attribute Ladder
This ladder shows processes (tasks, activities) and the
sub-processes (sub-tasks, sub-activities) of which they are composed. All
relationships are the part of relationship (see chapter 9). The following is an
example of a concept ladder constructed in UML:
Process Ladder
Network
Diagrams: Network diagrams show nodes connected by arrows. Depending
on the type of network diagram, the nodes might represent any type of concept,
attribute, value or task, and the arrows between the nodes any type of relationship
(see chapter 9).
A concept map is a type of diagram that shows knowledge
objects as nodes and the relationships between them as links (usually labeled
arrows). The knowledge objects (concepts) are usually enclosed in circles or
boxes of some type, and relationships between concepts or propositions,
indicated by a connecting line between two concepts (see chapter 9). The
following is an example of a concept map constructed in UML:
Concept Map
The
Concept Map shown in the diagram above uses UML Objects to represent Knowledge
Objects.
A Process
Map shows the inputs, outputs, resources, roles and decisions associated with
each process or task in a domain. Process Maps represent information of how and
when processes tasks and activities are performed (see Chapter 9).
Process
Map
A State Transition
Network diagram comprises two elements: (1) nodes that represent the states
that a concept can be in, and (2) arrows between the nodes showing all the
events and processes/tasks that can cause transitions from one state to
another.
As stated
in chapter 9, a transition network is a set of states and the transitions
between them. State Transition Networks are good at capturing the notion of
process. For example:
·
Control processes such as those in a digitally controlled
heating system.
·
Processes controlling manufacture or design.
·
Workflow processes such as those found in product data
management software.
State
Transition Network
Decision
trees classify instances by sorting them down the tree from
the root node to some leaf node, which
provides the classification of the instance. Each node in the tree specifies a test
of some attribute of the instance, and each branch
descending from that node corresponds to one of the possible values
for this attribute (see chapter 9).
An
instance is classified by starting at the root node of the decision tree,
testing the attribute specified by this node, then moving down the tree branch
corresponding to the value of the attribute. This process is then repeated at
the node on this branch and so on until a leaf node is reached.
In UML the
decision tree will be constructed using the class diagram paradigm (see figure
UML - Decision Tree).
UML –
Decision Tree
[1] “UML Based Framework for Knowledge Acquisition” National Science Foundation sponsored project conducted by A.J. Rhem & Associates, Inc. 2004
[2] Enterprise Information Portals and Knowledge Management, Joseph M. Firestone, Ph.D., p. 204-205