Architecture & Ontology
part of the SIKS course on
Architecture for
Information and Knowledge Systems
Wednesday, Sept. 27, 2006
Stijn Hoppenbrouwers
About me
• Assistant Professor at Nijmegen (Informatiekunde,
Informatica)
• Been working on NL and IKS modeling issues for last 10
years at UvT (applied research projects), Ordina (research
consultant) , and ICIS (researcher, lecturer)
• Contributed to ArchiMate project and language
• Now focusing on modelling processes in (information and
knowledge) systems development: modeling as a behavior
(strategies, goal-driven)
• Core topics: Modelling strategies, some focus on
ORM/Lisa-D; controlled languages; MODIAL
• This talk lies within my expertise but is not about my core
research
2
Agenda
• Architecture, architecture modeling, and ontology: some
theory, definitions, and issues
• A basic conceptual framework for ontological models (ORM
+ Dietz)
• Discussion: formal architecture modeling?
• Illustration: formalization of architecture principles
3
Architecture: a workable definition
IEEE 1471: “the fundamental organization of a system embodied in
its components, their relationships to each other and to the
environment, and the principles guiding its design and evolution.”
•
•
•
•
•
4
“Every system has an architecture, but an architecture is not a
system”. (?)
“An architecture and an architecture description are not the same
thing” (!)
“Architecture descriptions are inherently multiviewed (!)”
Architecting and architecture modeling are two different
though related activities
(compare: the Architect and guy who makes the Blueprint)
Some flavours
•
•
•
•
•
•
•
•
•
5
Enterprise architecture
Business process architecture
Information architecture
Application architecture
Software architecture
Infrastructure architecture
Service-oriented architecture
Model driven architecture
…
Main Goals of Architecture
•
•
•
•
•
Managing Complexity
Governance / steering
Alignment
Standardisation
Communication
So architecture models / descriptions should support those
goals
J. Dietz: “Architecture serves the purpose of constraining
design space”
6
Architecting and Architecture Modeling
Architecting (that which architects do) goes way beyond just
modeling, it includes:
– Charting all stakeholders and understanding their wishes and
needs
– Charting all additional restrictions (including standards)
– Mediating in negotiations between stakeholders
– Eliciting or creating “a vision”
– … based on/expressed in well-formulated principles
– Guarding those principles during construction
– …
• So (at least) two types of “engineered” artifact:
– Architecture principles
– Architecture models
7
Some basic concepts (IEEE 1471)
By the way, this is a good
example of a sort of ontology
based on an IKS technique!
8
Models and Systems (L. Apostel; J. Dietz)
• “Any subject using a system A that is neither directly nor
indirectly interacting with system B, to obtain information
about the system B, is using A as a model for B”
• So, the notion of a model is a role notion: something is not
a model per se, but it may be used as a model
9
conversion
Models and Systems (Dietz)
CONCEPTUAL
SYSTEM
SYMBOLIC
SYSTEM
CONCRETE
SYSTEM
transformation
imitation
10
So: a conceptual system providing information about a concrete system
is a conceptual model of the concrete system (revisit slide 4!)
Views and viewpoints
• A view is a partial representation of a model, focusing on a
particular concern or stakeholder type (my own work
definition!).
• For example: all the services in an application architecture
neatly organized as a tree (services and sub-services).
• Viewpoint: type-level specification of a class of views.
11
Ontology: a workable definition
• Gruber: “a formal, explicit specification of a shared
conceptualization”
• Rephrased in a more focused, practical tone:
“a tightly specified description of concepts used in one or
more related models/views, that is agreed by and used
amongst a diverse group of agents (h/a) that communicate
in some common context”
• Now compare this to (goals of) architecture (models):
12
–
–
–
–
–
Managing Complexity
Governance / steering
Alignment
Standardisation
Communication
(Meta-linguistic communication)
A note on term meaning
• Meta-linguistic communication: communication about
language
• Ontologies are often meant for use by automated agents
(semantic web!)
• If this is not the purpose, ontologies may still be used as
documents about term meaning meant for human
communication
• Form (representation) of ontology should depend on its
purpose
13
Representing ontologies: formal and informal
14
• Full blown formalization may be desirable in principle, but it
is usually too much to ask in practice (NL-AL divide;
resources). This is a pending issue in research.
• Semantic networks, domain models, OWL, ORM, ER, UML
class diagrams, SBVR, etc. etc.: numerous ways of and
opinions about representing ontologies.
• If requirements are not too harsh, a simple list of term
definitions may do (part of) the trick! –but most academics
do not like this as using NL almost inherently entails
ambiguity.
• Formal principles may also apply to NL statements, yet may
be ambiguous or not explicitly marked (so: extra
conversation for clarification needed to formalize)
Focus
• We present the basics of an ontology for architecture here,
not a complete set of architecture concepts! (for more, see
Dietz, but alternatively also Jonkers, etc.).
15
A foundation for ontological models
•
•
•
•
16
In IKS development, ontologies are very much linked up with the
notion “meta-model”, “meta-language”, and “meta modelling”
Distinction between “concepts for modelling” and “domain
concepts”: necessary but tricky (no absolute boundaries)
Recommended: Jan Dietz’s “Enterprise Ontology” book; the
upcoming slides are partly based on it.
Comparable conceptual framework: some recent Nijmegen ICIS
papers on ORM and domain modelling (v. Bommel,
Hoppenbrouwers, Proper, v.d. Weide)
Some stances on modeling
Objectivist – Subjectivist – Constructivist (intersubjective view)
17
Essential high-level (meta) concepts
intentional definition: listing properties
concept
type
subjective
instantiation
population
object
class
objective
extensional definition: listing objects
18
Levels/foci in basic IKS modeling
datalogical – infological – ontological
19
(Dietz)
Form-oriented
Content-oriented
Change-oriented
(copy, store, read,
write, speak, listen)
(inquire, calculate,
reason)
(decide, judge, request,
promise, commit)
Stata and Facta
• At any particular moment, a world is in a state; state
changes are called transitions; a particular occurrence
(instantiation) of a transition is called an event (which is
unique)
• A statum is something unchangeable. Stata are subject to
existence laws, which require or prohibit the coexistence of
stata (in the same state of the world)
• A factum is the result of the effect of an act. Facta are
subject to occurrence laws, which prohibit sequences of
events in the course of time.
20
Definition of ontological model of a world
• The ontological model of a world consists of the
specification of its state space and its transition space
(Dietz; note the difference between “ontology” and
“ontological model”)
• State base = set of statum types of which instances may
exist in some state of the world
• State space = set of allowed or lawful states: state base +
existence laws
• Transition base = set of factum types of which instances
may occur in the world
• Transition space = set of allowed or lawful sequences of
transitions: transition base + occurrence laws
21
Declaration of statum types
x is a person
Extension: PERSON = {x | person(x)}
y is a language
Extension: LANGUAGE = {y | language(y)}
x speaks y
Extension: SPEAKS = {<x,y> | speaks(x,y)}
The truth of speaks(a,b), where a, and b are identifiers of resp. a person
and a language, in a state of the world means that there exists a statum
(an instance of speaks) representing that person a speaks language b
SPEAKS
x
22
y
speaks
(graphical notation of the extension of the binary statum type speaks;
extension = ORM objectification)
Specification of Existence Laws (1)
• Existence Law types:
–
–
–
–
–
23
Reference laws
Dependency laws
Unicity laws
(Exclusion laws)
…
Specification of Existence Laws (2)
PERSON
Reference Law:
If for some x, student(x) holds, then person(x) also holds
student
x
x is a student
member
MEMBERSHIP
x
y
PERSON
y is member of x
Dependency Law:
For every membership(x) there must be a person(y) such that member(x,y) holds
(Reference laws: if for some x and y member(x,y) holds,
then (membership(x) and person(y)) must also hold)
24
Specification of Existence Laws (3)
member
MEMBERSHIP
x
y
PERSON
y is member of x
Unicity Law:
(added to earlier examples:)
Every membership cannot occur more than once
in a lawful population of statum type member
For more in-depth treatment and formalization see Dietz, and
Object Role Modeling literature
25
Derivation of Statum Types
•
No time here to treat in detail
•
Partition: subset: “all members at some time” (persons occurring
in role y in member)
Aggregation: = objectification (e.g. “marriage”)
Specialization: if b is a specialization of a, then b is a subtype of
a and a is a supertype of b.
Generalization: if e is a generalization of c and d, the c and d
are subtypes of e and e is a supertype of both c and d.
•
•
•
•
26
Please note: specialization refers to deriving a subtype from
existing categories; generalization takes two categories and
abstracts them in a union; think of purpose, not just result!
Declaration of Factum Types
x
Membership x has been started
member
MEMBERSHIP
x
y
PERSON
y is member of x
Occurrence laws (only basic concepts presented here!):
• Prerequisite law: a transition must have occurred before some other
transition may occur
x
z
• Preclusion law: prohibits that some transition occurs after another
transition has occurred
x
27
X
z
Looking Back
• A broad, formal conceptual framework for system
description, based on FOL and including rules (constraints!)
• Concepts can be further specialized/refined (for example to
include stransaction, or service, or even more technical
notions like infrastructure)
• Not intended (in the Nijmegen point of view) as universal
modeling method but as an integration. Different views,
levels of abstraction, specialized concepts etc. are crucial,
but so is integration. (example: UML as viewpoints)
• But now what about the architecture principles?
– Could also be formalized?
– Blended in with model?
28
Discussion (after a short break)
• Should we strive for complete formalization of architecture
models and principles? Why? Why not?
• What are the big challenges here?
29
Illustration: Formalization of Architecture Principles
• TOGAF: “The open Group’s Architecture Framework”
• Data is Shared (TOGAF1): “Users have access to the data
necessary to perform their duties; therefore, data is shared
across enterprise functions and organizations.”
• Common Use Applications (TOGAF2): “Development of
applications used across the enterprise is preferred over the
development of duplicate applications which are only
provided to a particular organization.”
30
Assignment
• Create ORM-like conceptual models for the relevant
concepts in the principles
• Create constraints (rules) reflecting the NL versions
• Any observations, comments, weird stuff noted?
• Note that a whole load of assumptions needs to be made
that would in real life have to be validated!
• BTW, ORC = Object-Role Calculus, an extension of ORM
31
ORC analysis of TOGAF 1
• 1.a Each Enterprise-function has access to
Data which some User [ that supports that
Enterprise-function ] needs for some Duties
• 1.b Each Organization has access to Data
which some User [ that belongs to that
Organization ] needs for some Duties
Related rules, both implied by TOGAF 1
• 1.c Each ( Enterprise-function and
Organization ) has access to Data needed by
some User [ that ( supports or belongs to )
that ( Enterprise-function or Organization )
] for some Duty
32
Collapsed rules, keeping the distinction in order to respect the domain
ORM diagram with TOGAF 1
Organization
has access to / is available to
Enterprise function
has access to / is available to
includes / belongs to
is supported by / supports
Data
TOGAF principle 1
User
Duty
… needs … for ...
33
ORC analysis of TOGAF 2 (1/2)
• 2. If an Application A [ that is used in an
Organization O ] results from some
Development, and this Application A is not a
duplicate of another Application [ that is
used in another Organization than O ], then
that Development is preferred by the
Enterprise that includes both Organizations
and both Applications.
34
ORC analysis of TOGAF 2 (2/2)
• 2.a If an Application results from some
Development, and that Application is not a
Duplicate of another Application, then that
Development is preferred by the Enterprise.
This rule just includes the “duplication” clause, which logically seems to suffice
• 2.b If an Application A [ that is used in
some Organization ] results from some
Development, and that Application is not a
duplicate of any other Application that is
used in the same Organization, then that
Development is preferred by the Enterprise
that includes Application A.
35
Extra, implicit rule now made explicit
ORM diagram with TOGAF 2
Development
Enterprise
prefers / is preferred by
Organization
of / resulting from
ncludes / is part of
TOGAF principle 2
Application
uses / is used in
36
is duplicated by / is duplicate of
Formal proofs are possible and helpful!
• Does (1.a AND 1.b) indeed amount to 1.c?
• Does 2.a indeed logically subsume 2? Also, does 2.a
indeed logically subsume 2.b?
• Does 2.b indeed fail to be logically covered by 2?
37
Descargar

Titel van de presentatie