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

Timestamp:

Sep 9, 2007, 7:30:02 PM (17 years ago)

Author:

KOBAYASHI, Shinji

Comment:

--

Archtectural Overview Design Principles

@@ -59 +59 @@
 Consequences for Software Engineering
 
-2段階モデリングはシステム開発プロセスに大変革をもたらしている。通常のITを集約したプロセスでは、要件はユーザー（典型的には「ユースケース」法として知られている方法）による場当たり的な議論を通じて集められ、設計やモデルは要件から構築され、素の設計を元に実装が進められ、引き続きテストと配備が行われ、最終的にはライフサイクルの維持期となる。
+2段階モデリングはシステム開発プロセスに大変革をもたらしている。通常のITを集約したプロセスでは、要件はユーザー（典型的には「ユースケース」法として知られている方法）による場当たり的な議論を通じて集められ、設計やモデルは要件から構築され、素の設計を元に実装が進められ、引き続きテストと配備が行われ、最終的にはライフサイクルの維持期となる。しかし、この手法では相次ぐ変更により実装コストが高くなり、常にシステムの能力と要求の間に大きな差が開くことになるのが一般的である。このアプローチを使う限り、システムのユーザーとの場当たり的会話では、潜在的な内容やワークフローが明かになることはあまりないために苦しむことになる。2段階パラダイムでは、システムのコアの部分が極めて安定している参照モデルとアーキタイプモデル（保存や問い合わせ、キャッシュなどの一般ロジックを含む）が基礎となる。そこで、そのドメインでのセマンティクスはアーキタイプ（再利用可能）やテンプレート（ローカルでの利用）や用語体系(一般的に利用)を構築したそのドメインの専門家に委ねられている。このプロセスは[図6 http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principles2.gif]に示されている。
+
+[[Image(design_principles2.gif)]]
 
 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.