Understanding Quality in Conceptual Modeling: Odd Ivar Lindland, Guttorm Sindre, Arne Sølvberg IEEE Software, March 1994
Understanding Quality in Conceptual Modeling: Odd Ivar Lindland, Guttorm Sindre, Arne Sølvberg IEEE Software, March 1994
Conceptual Modeling
Odd Ivar Lindland, Guttorm
Sindre, Arne Slvberg
IEEE Software, March 1994
Contents
A good model !?!
What are the properties of a good model?
A framework for quality considerations
The quality framework
Quality types and goals
Techniques and tools for improved quality
Examples
Model Quality
- what is a good model?
Quality assessment approaches
quality of end-product depends to a great extent on
the quality of early models (conceptual models,
requirements)
most quality frameworks appear as lists of desired
properties of the considered systems
our framework distinguishes between goals and
means, and is based on linguistic concepts
Some common quality properties of
information system specifications
appropriate - ability to capture germane concepts
complete - everything the software shall do is included in the specification
conceptually clean - simplicity, clarity, ease of understanding
consistent - no requirement is in conflict with other requirements
constructable - there is a systematic approach to formulating
specifications
executable - automatic execution of specifications
expressive - everything relevant may be expressed without too much
effort
formal - specification in formal language permitting formal analysis of
spec.
precise - can find whether some realization does not meet some
requirement
testable
traceable - the origin of each requirement statement is clear
unambiguous, understandable, verifiable, minimal, modifiable,..
Weaknesses of the list-approach to
quality assessment
Many definitions are vague, complicated,
undefined
List is unstructured, and properties overlap
Specification properties, language properties
and model properties are intermixed
Some properties are design/implementation
directed
Some goals are unrealistic/impossible to
reach, e.g., completeness
The framework for model quality
Model Domain
Modeling
language
Actors
Semantic
quality
Syntactic
quality
Pragmatic
quality
D
M
L
A
Quality statements
The language L consists of all of the statements that
can be made according to the syntax
The domain D consists of all possible statements that
are both correct and relevant for the problem at hand
The model M is the set of statements actually made
The audience interpretation A is the set of statements
that the audience thinks that the model contains
Quality Goals
Syntactic quality:
Goal: That the model is correct wrt. to the syntax of the modeling
language
Statement: M \ L =
Semantic quality:
Goal: The model shall contain a complete and correct representation of
all relevant statements from the domain
Statement: Correct: M \ D = , Complete: D \ M =
Pragmatic quality:
Goal: The model is understood by all relevant actors. An individual
actor must have understood the parts of the model relevant to him/her
Statement: "
i
, M
i
= A
i
Quality types and means
Types of quality - more specific
Model Domain Language
Actor
Tool
Model qualities
Language-quality
Proess-qualities
Semantic
quality
Pragmatic
quality
Syntactic
quality
Pragmatic
quality
Means for increased model quality
Model Quality Goal Means
Syntactic
Correct
Formal syntax of modelling language
Error prevention
Error detection
Error correction
Semantic
Correct
Complete
Statement insertion / deletion
Formal Semantics
Consistency-testing
Pragmatic
Understood
Inspection
Aesthetics, Readability
Visualisation, Filtering
Explanation-generation, Paraphrasing,
Translation
Execution, Animation, Simulation
Tool support Can the model be supported by proper
tools and techniques?
Language Quality
"suitability" Is the selected modelling language
suiteable for the situation?
- Is it usable for the relevant actors?
- Can we express the relevant
properties of the domain?
- Does it lend itself to proper tool-
support?
CASE tools
Meta-Model
Repository:
Persistent model storage
multi-user support
Meta-Model:
definition of model languages and
relations between different
languages and perspectives.
Integrated modeling languages
Tools and techniques for
improved model usage:
Syntax testing
Consistency checking
Simulation
Inspection
Explanatiion generation
Execution
Prototyping
CSCW support:
Examples
P1.1
P1.3
P1.2
P1.4
T
T T
T
T
T
T
T
T
P1.2
P1.1
P1.3
P1.4
T
P1.1
P1.3
P1.2
P1.4
T
T T
T
T
T
T
T
T
P1.1
P1.3
P1.2
P1.4
T
T T
T
T
T
T
T
T
Hvorfor var
ordren
Ugyldig ?
Flyten Ugyldig
ordre ble sendt
av P1 fordi
Kundedata ikke
var gyldige
View generation / Filtering
Explanation generation
Translation
Simulation
Constructivity in DFD
Motta
Ordre
P1
Telefon
Mottak
P1.1
Fyll ut
P1.3
Motta
ferdig
utfylt
P1.2
Sjekk
ordre
P1.4
ordrer
godkjent
ugyldig
Kundedata
Varedata
Ordre
Constructivity in PrM
Telefon
Mottak
P1.1
Fyll ut
P1.3
Motta
ferdig
utfylt
P1.2
Sjekk
ordre
P1.4
ordrer
Kundedata
Varedata
Ordre
Motta
Ordre
P1
Kundedata
Varedata
Ordre
godkjent
ugyldig
T
T
T
T
T T
T
T
T
T
T
T
Name ?
P1
inn-ordrer ut-ordrer
A priori rules : never allowed
A posteriori rules : Not allowed
in a finished model
Syntax checking
Check-list:
Name
Flows
Triggers/Termination
Ports
Flow content definitions
Process specifications
Data store content definitions
Explanation generation
Syntax explanation
P1
Receive
Order
P1
This is a process symbol. A process is a
dynamic concept that reads a set of input-
flows and generates a set of output-flows. All
processes must have a name and an ID.
name
Error explanation
inn-ordrer ut-ordrer
The diagram is illegal since P1 does not
generate any ouput. All processes must
generate at least one output-flow.
A data-flow cannot be directly connected
between two datastores.
Dynamic Explanation (in simulation)
P1
The flow Illegal order was sent because
the input flow customer data was not legal
Receive
order
Why was the order rejected?
P1
Customer data was illegal since the
customer have less than 500,- on her
account. This violates R3: Orders from
direct customers can only be accepted if the
customer has more than 500,- in balance
Receive
order
Why was customer data illegal?
Summary
Models and modeling languages are subject to
variation - as needed
Often tailored for specific purposes and adjusted for proper
tool-support
A good model?
It depends on
the Domain (D), the Language (L), the Actors (A)
Syntactic quality
Semantic quality
Pragmatic quality
Proper tool support provides means for increased
model quality