アーキテクチャを理解する

コンピューターやアプリケーションにとって、「アーキテクチャ」は非常に一般的であり、曖昧なことが多い言葉です。確かに複雑なシステムを指すようで、構造やフレームワーク、計画や青写真、アプローチや方法論などと混同されることが多いようです。ただし、この用語を使用するのには一定の理由があることがわかります。

私たちの理解では、まず、複雑さによって設計と実装に巨大な (おそらくオープンな) オプションの余地が生じ、これにより選択の可能性を減らす特定の方法が必要になります。第二に、機能やスタイルとデザインや構造、開発、変革、さらにはメンテナンスやガバナンスのプロセス/アプローチとの間には密接な関係があります。そして 3 番目は、設計および実装プロセスにおける、構成、コンポーネント、リソース、プロシージャなどの再利用の必要性です。したがって、いくつかの 建築原理 複雑なシステムに合計することができます。

• 設計と実装の関連性に関する原則 — 設計 (構造やコンポーネントなど) の選択は、可能な方法と手段の制限を受ける必要があります。

• 共通性への原則 — 設計と実装は、可能な限り、共通性、明確な適用条件、実証済みの信頼性を備えた共通のコンポーネントまたは構造に基づいている必要があります。

そこからのアーキテクチャは、少なくとも 2 つの側面に関係するいくつかの関連要素または原則を提供する必要があります。1 つは、 何、つまり、ターゲット システムの機能、機能のスタイル、構造、または外観の特徴。もう一つは、 どうやって システムの設計、実装、およびガバナンスのプロセスの内容、つまり原則、方法またはアプローチ、およびリソース (参照モデルのフレームワーク、共通手順など) に関連します。

そこからのアーキテクチャは、少なくとも 2 つの側面に関係するいくつかの関連要素または原則を提供する必要があります。1 つは、 何、つまり、ターゲット システムの機能、機能のスタイル、構造、または外観の特徴。もう一つは、 どうやって システムの設計、実装、およびガバナンスのプロセスの内容、つまり原則、方法またはアプローチ、およびリソース (参照モデルのフレームワーク、共通手順など) に関連します。たとえば、ISO/IEC 42010 では、「アーキテクチャ」を次のように定義しています。

システムの基本的な組織。そのコンポーネント、コンポーネント間の関係、および環境との関係、およびその設計と進化を支配する原則に具体化されています。

それは明らかに次の 2 つの側面に現れています。システムの基本的な構成。そのコンポーネント、コンポーネント間の関係、および環境に具体化されています。);その方法（その設計と進化を支配する原則）。

さらに、アーキテクチャのコンテキストでは、目標はシステムを構築することであるため、最初に懸念されるのは前者、つまり「何を」であるかです。後者の「どのように」は、アーキテクチャを選択または比較するときに、「何を」に依存しますが、制限されます。場合によっては、他の側面の要素が実証なしで自然に指定される、つまり自明であるため、アーキテクチャが 1 つの側面でのみ示される場合があります。明らかに、それは上記の原則に違反しません。

* 写真の説明: 建築モノグラフの 1 ページ – 西暦 1103 年に出版された中国の建築書、营造法式 (Yingzao Fashi) より ウィキメディア・コモンズ。

著者: ユウ・トンイン

余彤鹰 (Yu、Tong-Ying、インターネット上では TY または Mountriver TY Yu とも署名) は、エンタープライズ アプリケーション、ビジネス プロセスの改善と移行、管理の分野を担当する中国出身の独立系コンサルタントです。は、産業分野での豊富な経験と、エンタープライズ アプリケーションのライフサイクルの各主要フェーズに関する経験を持っています。彼は、企業および情報システム向けアプリケーションの革新的な開発と研究に長期的に取り組んでいます。研究対象には、モデル駆動型アプリケーションとモデルの動作メカニズム、アーキテクチャ、エンタープライズ モデリング、エンタープライズ エンジニアリング、および一般的なモデリング理論が含まれます。 1998 年以来、EE-Forum.org などを通じて多くの影響力のある記事を発表してきました。 2001 年に中国初のエンタープライズ エンジニアリング セミナーを立ち上げました。 モデルで考える