Changes between Version 19 and Version 20 of Archtectural Overview Design Principles

Timestamp:

Sep 9, 2007, 6:32:46 PM (17 years ago)

Author:

KOBAYASHI, Shinji

Comment:

--

Archtectural Overview Design Principles

@@ -48 +48 @@
 [[Image(design_principles3.gif)]]
 
-この図では、通常の情報システム（[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principles3.gif 図5]一番左下）で知られているような「データ」は通常ではオブジェクトモデル(一番左上）に相当する。システムは
+この図では、通常の情報システム（[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principles3.gif 図5]一番左下）で知られているような「データ」は通常ではオブジェクトモデル(一番左上）に相当する。「旧来」の方法（例えばすべてのドメインセマンティクスがソフトウェアやデータベースのどこかでコード化されているようなもの）で開発されたシステムは、この種のアーキテクチャに限定されている。2段階モデリングを利用することにより、実行時のデータはアーキタイプとセマンティクスが一致し、参照モデルに対しても具体的に整合性を持つことになる。アーキタイプはすべて、一般的なアーキタイプ定義言語(ADL; Archetype Definition Language)で表現される。
 
 In this figure, "data" as we know it in normal information systems (shown on the bottom left) conforms in the usual way to an object model (top left). Systems engineered in the "classic" way (i.e. all domain semantics are encoded somewhere in the software or database) are limited to this kind of architecture. With the use of two-level modelling, runtime data now conform semantically to archetypes as well as concretely to the reference model. All archetypes are expressed in a generic Archetype Definition Language (ADL).
 
+アーキタイプやテンプレートがどのようにopenEHRで機能しているのか詳細については55ページの[wiki:"Archtectural Overview Archetypes" アーキタイプとテンプレート]に記述されている。
+
 The details of how archetypes and templates work in openEHR are described in Archetypes and Templates on page 55.
+
+=== ソフトウェア工学のための結論 ===
 Consequences for Software Engineering
+
+2段階モデリングはシステム開発プロセスに大変革をもたらしている。通常のITを集約したプロセスでは、要件はユーザー（典型的には「ユースケース」法として知られている方法）による場当たり的な議論を通じて集められ、設計やモデルは要件から構築され、素の設計を元に実装が進められ、引き続きテストと配備が行われ、最終的にはライフサイクルの維持期となる。
 
 Two-level modelling significantly changes the dynamics of the systems development process. In the usual IT-intensive process, requirements are gathered via ad hoc discussions with users (typically via the well-known "use case" methodology), designs and models built from the requirements, implementation proceeds from the design, followed by testing and deployment and ultimately the maintenance part of the lifecycle. This is usually characterised by ongoing high costs of implementation change and/or a widening gap between system capabilities and the requirements at any moment. The approach also suffers from the fact that ad hoc conversations with systems users nearly always fails to reveal underlying content and workflow. Under the two-level paradigm, the core part of the system is based on the reference and archetype models (includes generic logic for storage, querying, caching etc.), both of which are extremely stable, while domain semantics are mostly delegated to domain specialists who work building archetypes (reusable), templates (local use) and terminology (general use). The process is illustrated in FIGURE 6. Within this process, IT developers concentrate on generic components such as data management and interoperability, while groups of domain experts work outside the software development process, generating definitions that are used by systems at runtime.