Stijn Hoppenbrouwers

1. Stijn Hoppenbrouwers Architecture & Ontologypart of the SIKS course on Architecture for Information and Knowledge SystemsWednesday, Sept. 27, 2006

2. 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

3. 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

4. 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.” • “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)

5. Some flavours • Enterprise architecture • Business process architecture • Information architecture • Application architecture • Software architecture • Infrastructure architecture • Service-oriented architecture • Model driven architecture • …

6. 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”

7. 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

8. By the way, this is a good example of a sort of ontology based on an IKS technique! Some basic concepts (IEEE 1471)

9. 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

10. Models and Systems (Dietz) conversion CONCEPTUAL SYSTEM conceptualization formulation interpretation implementation CONCRETE SYSTEM SYMBOLIC SYSTEM imitation transformation So: a conceptual system providing information about a concrete system is a conceptual model of the concrete system (revisit slide 4!)

11. 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.

12. 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): • Managing Complexity • Governance / steering • Alignment • Standardisation • Communication (Meta-linguistic communication)

13. 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

14. Representing ontologies: formal and informal • 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)

15. 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.).

16. A foundation for ontological models • 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)

17. Some stances on modeling Objectivist – Subjectivist – Constructivist (intersubjective view)

18. concept type subjective instantiation extension reference conformity population objective object class Essential high-level (meta) concepts intentional definition: listing properties extensional definition: listing objects

19. Levels/foci in basic IKS modeling datalogical – infological – ontological (Dietz) Form-oriented (copy, store, read, write, speak, listen) Content-oriented (inquire, calculate, reason) Change-oriented (decide, judge, request, promise, commit)

20. 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.

21. 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

22. 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 speaks x y (graphical notation of the extension of the binary statum typespeaks; extension = ORM objectification)

23. Specification of Existence Laws (1) • Existence Law types: • Reference laws • Dependency laws • Unicity laws • (Exclusion laws) • …

24. 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 MEMBER- SHIP PERSON x y 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 ymember(x,y) holds, then (membership(x) and person(y)) must also hold)

25. Specification of Existence Laws (3) member MEMBER- SHIP PERSON x y 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

26. 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. • 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!

27. x Declaration of Factum Types Membership x has been started member MEMBER- SHIP PERSON x y 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 • Preclusion law: prohibits that some transition occurs after another • transition has occurred x z x z X

28. 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?

29. 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?

30. 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.”

31. 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

32. 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 • 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 Related rules, both implied by TOGAF 1 Collapsed rules, keeping the distinction in order to respect the domain

33. ORM diagram with TOGAF 1

34. 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.

35. 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. • 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. This rule just includes the “duplication” clause, which logically seems to suffice Extra, implicit rule now made explicit

36. ORM diagram with TOGAF 2

37. 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?