| 99 | |
| 100 | == 2 概要 == |
| 101 | |
| 102 | 2 Overview |
| 103 | |
| 104 | === 2.1 ADLとは何か === |
| 105 | |
| 106 | 2.1 What is ADL? |
| 107 | |
| 108 | アーキタイプ定義言語(ADL; Archetype Definition Language)はアーキタイプを表現する形式言語であり、ドメインエントリーの制約ベースのモデルである。つまり、「構造化されたビジネスルール」といってもいいようなものである。アーキタイプの概念はBealによって記載されている[[FootNote(Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. |
| 109 | OOPSLA 2002 workshop on behavioural semantics.[BR] Available at http://www.deepthought.com.au/it/archetypes.html)]], [[FootNote(Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. OOPSLA 2002 workshop on behavioural semantics.[BR] Available at http://www.deepthought.com.au/it/archetypes.html)]]。 |
| 110 | |
| 111 | Archetype Definition Language (ADL) is a formal language for expressing archetypes, which are |
| 112 | constraint-based models of domain entities, or what some might call ‘structured business rules’. The |
| 113 | archetype concept is described by Beale [1], [2]. The openEHR Archetype Object Model [3] |
| 114 | describes the definitive semantic model of archetypes, in the form of an object model. The ADL syntax |
| 115 | is one possible serialisation of an archetype. |
| 116 | The openEHR archetype framework is described in terms of Archetype Definitions and Principles [6] |
| 117 | and an Archetype System [7]. Other semantic formalisms considered in the course of the development |
| 118 | of ADL, and some which remain relevant are described in detailed in section 10 on page 109. |
| 119 | ADL uses three other syntaxes, cADL (constraint form of ADL), dADL (data definition form of |
| 120 | ADL), and a version of first-order predicate logic (FOPL), to describe constraints on data which are |
| 121 | instances of some information model (e.g. expressed in UML). It is most useful when very generic |
| 122 | information models are used for describing the data in a system, for example, where the logical concepts |
| 123 | PATIENT, DOCTOR and HOSPITAL might all be represented using a small number of classes such |
| 124 | as PARTY and ADDRESS. In such cases, archetypes are used to constrain the valid structures of |
| 125 | instances of these generic classes to represent the desired domain concepts. In this way future-proof |
| 126 | information systems can be built - relatively simple information models and database schemas can be |
| 127 | defined, and archetypes supply the semantic modelling, completely outside the software. ADL can |
| 128 | thus be used to write archetypes for any domain where formal object model(s) exist which describe |
| 129 | data instances. |
| 130 | When archetypes are used at runtime in particular contexts, they are composed into larger constraint |
| 131 | structures, with local or specialist constraints added, via the use of templates. The formalism of templates |
| 132 | is dADL. Archetypes can be specialised by creating an archetypes that reference existing |
| 133 | archetypes as parents; such archetypes can only make certain changes while remaining compatible |
| 134 | with the parent. |
| 135 | Another major function of archetypes is to connect information structures to formal terminologies. |
| 136 | Archetypes are language-neutral, and can be authored in and translated into any language. |
| 137 | Finally, archetypes are completely path-addressable in a manner similar to XML data, using path |
| 138 | expressions that are directly convertible to Xpath expressions. |
| 139 | 2.1.1 Structure |
| 140 | Archetypes expressed in ADL resemble programming language files, and have a defined syntax. |
| 141 | ADL itself is a very simple “glue” syntax, which uses two other syntaxes for expressing structured |
| 142 | constraints and data, respectively. The cADL syntax is used to express the archetype definition, |
| 143 | while the dADL syntax is used to express data which appears in the language, description, ontology, |
| 144 | and revision_history sections of an ADL archetype. The top-level structure of an ADL archetype |
| 145 | is shown in FIGURE 1. |
| 146 | |
| 147 | [[FootNote]] |