Changes between Version 34 and Version 35 of Archtectural Overview Design Principles
- Timestamp:
- May 12, 2009, 7:46:56 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Archtectural Overview Design Principles
v34 v35 1 [wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Aims" PREV] [wiki:"Archtectural Overview Package" NEXT] 1 [wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Aims" PREV] [wiki:"Archtectural Overview Package" NEXT] 2 2 3 = 4 設計原則 = 3 [[TOC]] 4 4 Design Principles 4 [[TOC]] 4 Design Principles 5 5 6 6 この文書は[http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/front.html Archtectural Overview]の[http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/design_principles.html 4 Design Principles]の翻訳である。内容の正確性については保証しないので，適宜原文を参照してください。 7 8 7 9 8 openEHRの情報やサービス，そのドメインでの知識をモデル化するアプローチは以下に記述するような多くの設計原則を元にしている。これらの原則を適用することで，openEHRアーキテクチャモデルを分離することができ，高レベルのコンポーネント化ができるようになった。これにより保守性や拡張性，柔軟な配備が可能となった。 … … 12 11 13 12 == 4.1 オントロジー的分離 == #ontology 14 15 13 4.1 Ontological Separation 16 14 … … 34 32 35 33 === 2段階モデリングとアーキタイプ === 36 37 34 Two-level Modelling and Archetypes 38 35 … … 62 59 Consequences for Software Engineering 63 60 64 2段階モデリングはシステム開発プロセスに大変革をもたらしている。通常のITを集約したプロセスでは、要件はユーザー（典型的には「ユースケース」法として知られている方法）による場当たり的な議論を通じて集められ、設計やモデルは要件から構築され、 素の設計を元に実装が進められ、引き続きテストと配備が行われ、最終的にはライフサイクルの維持期となる。しかし、この手法では相次ぐ変更により実装コストが高くなり、常にシステムの能力と要求の間に大きな差が開くことになるのが一般的である。このアプローチを使う限り、システムのユーザーとの場当たり的会話では、潜在的な内容やワークフローが明かになることはあまりないために苦しむことになる。2段階パラダイムでは、システムのコアの部分が極めて安定している参照モデルとアーキタイプモデル（保存や問い合わせ、キャッシュなどの一般ロジックを含む）が基礎となる。そこで、そのドメインでのセマンティクスはアーキタイプ（再利用可能）やテンプレート（ローカルでの利用）や用語体系(一般的に利用)を構築したそのドメインの専門家に委ねられている。このプロセスは[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principles2.gif図6]に示されている。このプロセスではIT開発者はデータマネジメントや相互可用性のための汎用コンポーネントに集中し、一方でドメインの専門家グループはソフトウェア開発プロセスから離れてシステムが実働する時に使われる定義を生成していくことになる。61 2段階モデリングはシステム開発プロセスに大変革をもたらしている。通常のITを集約したプロセスでは、要件はユーザー（典型的には「ユースケース」法として知られている方法）による場当たり的な議論を通じて集められ、設計やモデルは要件から構築され、その設計を元に実装が進められ、引き続きテストとデプロイが行われ、最終的にはライフサイクルの維持期となる。しかし、この手法では相次ぐ変更による実装コストが高くなり、常にシステムの能力と要求の間に大きな差が開くことになるのが一般的である。このアプローチを使う限り、システムのユーザーとの場当たり的会話では、潜在的な内容やワークフローが明かになることはあまりないために苦しむことになる。2段階パラダイムでは、システムのコアの部分が極めて安定している参照モデルとアーキタイプモデル（保存や問い合わせ、キャッシュなどの一般ロジックを含む）が基礎となる。そこで、そのドメインでのセマンティクスはアーキタイプ（再利用可能）やテンプレート（ローカルでの利用）や用語体系(一般的に利用)を構築したそのドメインの専門家に委ねられている。このプロセスは[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principles2.gif 図6]に示されている。このプロセスではIT開発者はデータマネジメントや相互可用性のための汎用コンポーネントに集中し、一方でドメインの専門家グループはソフトウェア開発プロセスから離れてシステムが実働する時に使われる定義を生成していくことになる。 65 62 66 63 [[Image(design_principles2.gif)]] … … 73 70 74 71 == 4.2 責任の分離 == #responsibility 75 76 72 4.2 Separation of Responsibilities 77 73 … … 80 76 A second key design paradigm used in openEHR is that of separation of responsibilities within the computing environment. Complex domains are only tractable if the functionality is first partitioned into broad areas of interest, i.e. into a "system of systems" [6]. This principle has been understood in computer science for a long time under the rubrics "low coupling", "encapsulation" and "componentisation", and has resulted in highly successful frameworks and standards, including the OMG's CORBA specifications and the explosion of object-oriented languages, libraries and frameworks. Each area of functionality forms a focal point for a set of models formally describing that area, which, taken together usually correspond to a distinct information system or service. 81 77 82 [http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principlesa.gif 図7]は丸で示された数多くのサービスによる医療情報環境を概念的に図示している。典型的なつながりは実線で示されており、丸が中央に近ければ近いほど、臨床でケアを提供するために中核となる要求に対応したサービス（EHRや用語体系、 人口体系/個人識別、医学参照データのような）である。図で示したサービスを持つopenEHRはEHRや人口統計をはじめととした中心的な仕様のためだけに現在は仕様を提供している。78 [http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principlesa.gif 図7]は丸で示された数多くのサービスによる医療情報環境を概念的に図示している。典型的なつながりは実線で示されており、丸が中央に近ければ近いほど、臨床でケアを提供するために中核となる要求に対応したサービス（EHRや用語体系、デモグラフィック/個人識別、医学参照データのような）である。図で示したサービスを持つopenEHRはEHRやデモグラフィクをはじめととした中心的な仕様のためだけに現在は仕様を提供している。 83 79 84 80 FIGURE 7 illustrates a notional health information environment containing numerous services, each denoted by a bubble. Typical connections are indicated by lines, and bubbles closer to the centre correspond to services closer to the core needs of clinical care delivery, such as the EHR, terminology, demographics/identification and medical reference data. Of the services shown on the diagram, openEHR currently provides specifications only for the more central ones, including EHR and Demographics. … … 91 87 92 88 == 4.3 視点の分離 == #viewpoint 93 94 89 4.3 Separation of Viewpoints 95 90 … … 98 93 The third computing paradigm used in openEHR is a natural consequence of the separation of responsibilities, namely the separation of viewpoints. When responsibilities are divided up among distinct components, it becomes necessary to define a) the information that each processes, and b) how they will communicate. These two aspects of models constitute the two central "viewpoints" of the ISO RM/ODP model [4], marked in bold in the following: 99 94 100 * 事業：ビジネス活動（たとえば、特定のシステムの目的や使用範囲、方針）に関連があるもの。95 * エンタープライズ用途：ビジネス活動（たとえば、特定のシステムの目的や使用範囲、方針）に関連があるもの。 101 96 * '''情報'''：システムに保存されたり処理されるべき情報のセマンティクスに関連があるもの。 102 * '''コンピュータによる''':システムを 配布することができるようにインターフェースとなって仲介するオブジェクトの集合としてのシステムの記述に関連があるもの103 * 工学：システム を配布することを支援する機構に関連するもの104 * 技術的： 配布されたシステムを構築するコンポーネントの詳細に関連するもの97 * '''コンピュータによる''':システムを分散させることができるように、インターフェースとして仲介するオブジェクトの集合であるシステムの記述に関連があるもの 98 * 工学：システムが分散していることを支援する機構に関連するもの 99 * 技術的：分散したシステムを構築するコンポーネントの詳細に関連するもの 105 100 106 107 108 109 110 101 * Enterprise: concerned with the business activities, i.e. purpose, scope and policies of the specified system. 102 * Information: concerned with the semantics of information that needs to be stored and processed in the system. 103 * Computational: concerned with the description of the system as a set of objects that interact at interfaces - enabling system distribution. 104 * Engineering: concerned with the mechanisms supporting system distribution. 105 * Technological: concerned with the detail of the components from which the distributed system is constructed. 111 106 112 したがって、openEHRの仕様は情報視点（openEHRの参照モデル)とコンピュータによる視点（openEHRのサービスモデル）を網羅している。工学視点はopenEHRの実装技術仕様モデル([wiki:"Implementation Technology Specifications" 83ページの実装技術仕様]を参照)に対応しており、技術的視点は用語体系や実際に 配備されるときに使われるコンポーネントや技術に対応している。この部門の視点に置ける重要な側面は、モデルの仕様と視点とが通常は1体1で対応していないということである。例えば、事業視点での「健康についての指令書」（CEN ENV13940 Continuity of Care concept）の概念があったとする。情報視点では、それは多くのクラスを持つモデルとなるものである。コンピュータによる視点では、情報視点で定義される情報構造は、複数のサービスを繰り返すようなものであり、「健康についての指令書」サービスになるものでもありならないものでもある。コンピュータ視点で定義されるサービスの粒度は、事業あるいは地域の役割の分野に強く関連するものであり、情報視点でのコンポーネントの粒度は問題空間における精神的な概念の粒度に対応する。情報視点でのコンポーネントの粒度はより細か鋳物となる傾向がある。107 したがって、openEHRの仕様は情報視点（openEHRの参照モデル)とコンピュータによる視点（openEHRのサービスモデル）を網羅している。工学視点はopenEHRの実装技術仕様モデル([wiki:"Implementation Technology Specifications" 83ページの実装技術仕様]を参照)に対応しており、技術的視点は用語体系や実際にデプロイされるときに使われるコンポーネントや技術に対応している。この部門の視点における重要な側面は、モデルの仕様と視点とが通常は1体1で対応していないということである。例えば、事業視点での「健康についての指示書」（CEN ENV13940 Continuity of Care concept）の概念があったとする。情報視点では、それは多くのクラスを持つモデルとなるものである。コンピュータによる視点では、情報視点で定義される情報構造は、複数のサービスを繰り返すようなものであり、「健康についての指示書」サービスになりうるものでもあり、なりえないものでもある。コンピュータ視点で定義されるサービスの粒度は、事業あるいは地域の役割の分野に強く関連するものであり、情報視点でのコンポーネントの粒度は問題空間における精神的な概念の粒度に対応する。情報視点でのコンポーネントの粒度はより細かいものとなる傾向がある。 113 108 114 109 The openEHR specifications accordingly include an information viewpoint - the openEHR Reference Model - and a computational viewpoint - the openEHR Service Model. The Engineering viewpoint corresponds to the Implementation Technology Specification (ITS) models of openEHR (see Implementation Technology Specifications on page 83), while the Technological viewpoint corresponds to the technologies and components used in an actual deployment. An important aspect of the division into viewpoints is that there is generally not a 1:1 relationship between model specifications in each viewpoint. For example, there might be a concept of "health mandate" (a CEN ENV13940 Continuity of Care concept) in the enterprise viewpoint. In the information viewpoint, this might have become a model containing many classes. In the computational viewpoint, the information structures defined in the information viewpoint are likely to recur in multiple services, and there may or may not be a "health mandate" service. The granularity of services defined in the computational viewpoint corresponds most strongly to divisions of function in an enterprise or region, while the granularity of components in the information view points corresponds to the granularity of mental concepts in the problem space, the latter almost always being more fine-grained. … … 118 113 [[FootNote]] 119 114 120 [wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Aims" PREV] [wiki:"Archtectural Overview Package" NEXT]115 [wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Aims" PREV] [wiki:"Archtectural Overview Package" NEXT]
