Changes between Version 24 and Version 25 of Archtectural Overview Design Principles

Timestamp:

Sep 9, 2007, 8:07:34 PM (17 years ago)

Author:

KOBAYASHI, Shinji

Comment:

--

Archtectural Overview Design Principles

@@ -59 +59 @@
 Consequences for Software Engineering
 
-2段階モデリングはシステム開発プロセスに大変革をもたらしている。通常のITを集約したプロセスでは、要件はユーザー（典型的には「ユースケース」法として知られている方法）による場当たり的な議論を通じて集められ、設計やモデルは要件から構築され、素の設計を元に実装が進められ、引き続きテストと配備が行われ、最終的にはライフサイクルの維持期となる。しかし、この手法では相次ぐ変更により実装コストが高くなり、常にシステムの能力と要求の間に大きな差が開くことになるのが一般的である。このアプローチを使う限り、システムのユーザーとの場当たり的会話では、潜在的な内容やワークフローが明かになることはあまりないために苦しむことになる。2段階パラダイムでは、システムのコアの部分が極めて安定している参照モデルとアーキタイプモデル（保存や問い合わせ、キャッシュなどの一般ロジックを含む）が基礎となる。そこで、そのドメインでのセマンティクスはアーキタイプ（再利用可能）やテンプレート（ローカルでの利用）や用語体系(一般的に利用)を構築したそのドメインの専門家に委ねられている。このプロセスは[図6 http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principles2.gif]に示されている。このプロセスではIT開発者はデータマネジメントや相互可用性のための汎用コンポーネントに集中し、一方でドメインの専門家グループはソフトウェア開発プロセスから離れてシステムが実働する時に使われる定義を生成していくことになる。
+2段階モデリングはシステム開発プロセスに大変革をもたらしている。通常のITを集約したプロセスでは、要件はユーザー（典型的には「ユースケース」法として知られている方法）による場当たり的な議論を通じて集められ、設計やモデルは要件から構築され、素の設計を元に実装が進められ、引き続きテストと配備が行われ、最終的にはライフサイクルの維持期となる。しかし、この手法では相次ぐ変更により実装コストが高くなり、常にシステムの能力と要求の間に大きな差が開くことになるのが一般的である。このアプローチを使う限り、システムのユーザーとの場当たり的会話では、潜在的な内容やワークフローが明かになることはあまりないために苦しむことになる。2段階パラダイムでは、システムのコアの部分が極めて安定している参照モデルとアーキタイプモデル（保存や問い合わせ、キャッシュなどの一般ロジックを含む）が基礎となる。そこで、そのドメインでのセマンティクスはアーキタイプ（再利用可能）やテンプレート（ローカルでの利用）や用語体系(一般的に利用)を構築したそのドメインの専門家に委ねられている。このプロセスは[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principles2.gif  図6]に示されている。このプロセスではIT開発者はデータマネジメントや相互可用性のための汎用コンポーネントに集中し、一方でドメインの専門家グループはソフトウェア開発プロセスから離れてシステムが実働する時に使われる定義を生成していくことになる。
 
 [[Image(design_principles2.gif)]]
@@ -73 +73 @@
 4.2 Separation of Responsibilities
 
-openEHRで使われている第2の重要な設計パラダイムはコンピュータ環境における責任の分離である。複雑なドメインは機能性が関心の及ぶ広い範囲（例えば「システムの中のシステム」）を最初に切り分けることができたときにだけ扱うことができる[[FootNote(Maier M. Architecting Principles for Systems-of-Systems. Technical Report, University of Alabama in Huntsville. 2000. Available at http://www.infoed.com/Open/PAPERS/systems.htm)]]。
+openEHRで使われている第2の重要な設計パラダイムはコンピュータ環境における責任の分離である。複雑なドメインは機能性が関心の及ぶ広い範囲を最初に切り分けること（例えば「システムの中のシステム」）ができたときにだけ扱うことができる[[FootNote(Maier M. Architecting Principles for Systems-of-Systems. Technical Report, University of Alabama in Huntsville. 2000. Available at http://www.infoed.com/Open/PAPERS/systems.htm)]]。この原理はコンピュータサイエンスでは長い間「疎結合」、「カプセル化」、「コンポーネント化」として教科書的に理解されており、フレームワークや標準として大きな成果をあげている。OMGのCORBA仕様書やオブジェクト指向言語の発展、フレームワークやライブラリといったものがその成果でもある。機能性の各分野で、その分野を形式的に記述するモデルの組み合わせが重要なものとなっており、明確な情報システムやサービスに対応して一まとめに考えられている。
 
 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.
 
+図7は
+
 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.
+
+[[Image(design_principlesa.gif)]]
 
 Since there are standards available for some aspects of many services, such as terminology, image formats, messages, EHR Extracts, service-based interoperation, and numerous standards for details such as date/time formats and string encoding, the openEHR specifications often act as a mechanism to integrate existing standards.