「全貌」の意味や使い方 わかりやすく解説 Weblio辞書 (original) (raw)
全貌
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/02/24 03:17 UTC 版)
ビューポイント及びビューの目的は、複雑システムを人間の技術者に理解を可能にさせ、そして専門的知識ドメインを取り巻く問題と解決策の要素を編成することである。物理集約的システムにおけるエンジニアリングではビューポイントは、しばしばエンジニアリング組織内の能力と責任に対応する。 ほとんどの複雑システムの仕様は、一個人では仕様のすべてを完全に理解できないほど大規模である。更に、我々はそれぞれ、与件システムに異なった関心を持ち、システムの仕様を試す異なった理由を持っている。事業の執行者は、システムの実装者よりシステムを作り上げるための異なった質問を問いかける。ビューポイントフレームワークの概念は、その利害関係者とのコミュニケーションを円滑にするため、与件の複雑システムの仕様に別々のビューポイントを提供することである。各ビューポイントは、システムの特定の局面のセットに関心を持つ聴衆を満足させる。各ビューポイントは、そのビューポイントの聴衆のため、語彙と表現を最適化する特定なビューポイント言語を利用し得る。ビューポイントモデリングは、大きな分散システム本来の複雑性を取り扱うための有効なアプローチになった。 現在のソフトウエアアーキテクチャ的実践は、IEEE 1471に記述されている様に、それぞれがシステムの特定局面に焦点を当てる、幾つかの関心領域に設計活動を分ける。例には、4+1 アーキテクチャビュー・モデル（英語版）、Zachmanフレームワーク、The Open Group Architecture Framework (TOGAF)、DoDAF（英語版）、及びRM-ODF（英語版）を含む。
※この「全貌」の解説は、「ビュー・モデル」の解説の一部です。
「全貌」を含む「ビュー・モデル」の記事については、「ビュー・モデル」の概要を参照ください。
全貌
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/08/06 14:27 UTC 版)
世界の記述に使われる主なメカニズムの1つは、出来事または活動の順序だったシーケンス(Sequence)での物語に関係している。IDEF3プロセス記述獲得手法は、状況あるいは事業プロセス (Business process)を記述する共通のメカニズムを配慮した、活動のシーケンス (Sequence)の記述を獲得するため創られた。IDEF3の主な目標は、ドメイン・エキスパート(Domain_expert)が特定システムまたは組織の運用についての知識 (Knowledge)を表現できる、構造化された方法を提供することである。知識獲得 (Knowledge acquisition)は、獲得するための最も自然な形式で、実世界のプロセスや出来事についての見方を直接獲得することによって可能にされる。IDEF3は、プロセス知識獲得のための信頼されかつ良く構造化されたアプローチで、情報獲得 (Information_capture)のための表現豊かで、使い易くて、そして表現を提供することにより、この種の知識獲得を支援する。 IDEF3の開発動機は、以下を必要とする： 事業システム・モデリング のプロセスをスピードアップする、 このデータ・ライフサイクル情報を記述するメカニズムを提供する、 自動化されたツールによりプロジェクト管理 (Project management)を支援する、 システム要求 (System requirements)を構築するための概念、構文、および手順を提供する、 異なった集中の領域を取扱うその他の手法（例えば、IDEFファミリ手法への補完的追加としてIDEF0機能モデリング手法）との独立性と連結性の両方で良く働く。
※この「全貌」の解説は、「IDEF3」の解説の一部です。
「全貌」を含む「IDEF3」の記事については、「IDEF3」の概要を参照ください。
全貌
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/02/24 03:12 UTC 版)
「Core Architecture Data Model」の記事における「全貌」の解説
Core Architecture Data Model (CADM)は、標準化された構造でDoDAFアーキテクチャ情報を取り込むために設計された。CADMはDoDAFのデータ要件を支援するため開発された。CADMは、アーキテクチャ記述内及び横断して統合を可能にするDoDAFアーキテクチャデータ要素のためのエンティティと関係性を定義する。このように、CADMは、ミッション領域、コンポーネント、及び連邦と連立パートナー間のアーキテクチャ情報の交換を支援することから、アーキテクチャのデータの相互運用性を促進する。 CADMは、DoDAFに従ってアーキテクチャを統合することを可能になる重要な側面がある。これは、エンティティとオブジェクトの全てのアーキテクチャ記述のため、共通データ要素の定義、セマンティクス、及びデータ構造の利用を含む。CADMの基盤としての使用は、複数ビューを横断する共通オブジェクトと忠実に関係する。現在承認されているバージョンのCADMへの準拠を含めた、そのフレームワークの遵守は、アーキテクチャ開発のための共通アプローチと、関係するアーキテクチャへの基本的基盤の両方を提供する。CADMへの準拠は、共通のアーキテクチャデータ要素（またはタイプ）の使用を保証する。
※この「全貌」の解説は、「Core Architecture Data Model」の解説の一部です。
「全貌」を含む「Core Architecture Data Model」の記事については、「Core Architecture Data Model」の概要を参照ください。
全貌
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2016/01/27 00:51 UTC 版)
米空軍（USAF）のICAMプログラムは、オハイオ州のライト・パターソン空軍基地にある米空軍物資研究所でデニス・ウィスノスキーやダン・L.・シュンク（Dan L. Shunk）他によって1976年に設立された。1970年代中ごろ、ジョセフ・ハリントン は、ICAMプログラムの設計でウィスノスキーとシュンクにアシストされ、製造企業全体を包含するコンピュータ統合製造 (CIM)の概念を広げた。ハリントンは製造を一つの『モノリシック（ひと固まり）な機能』と考えた。 ICAMプログラムは、新しいアプローチが製造会社での統合を達成するため必要であることを示した先鞭であった。ウィスノスキーとシュンクは、彼らのICAMプロジェクトの仕組み（アーキテクチャ）を描き、共に作業しなければならなかった種々の要素を示す『ホイール（轍）』を開発した。ウィスノスキーとシュンクは、統合のため必要とされる相互依存性のWebを理解する最初の最中であった。彼らの作業は、一連のシーケンシャルな運用から並列な処理へ製造の焦点をシフトさせる最初の大きなステップを代表する。 ICAMプログラムは、製造統合をサポートするツール、技法、及びプロセスを開発するため、1億ドル以上を費やし、多くの企業のCIMプロジェクトの試みに影響を与えた。空軍のICAMプログラムは、統合化努力の中心としてデータの役割を認識した。データは、機能を横切って共通でかつ共有されるべきだ。その概念は、未だにその時間よりも進んだままである、なぜなら、ほとんどの主要な会社は、1990年代に良くなるまで、データ・アーキテクチャ（仕組み）への挑戦を真剣に攻撃し始めないであろうことから。ICAMプログラムはまた、製造施設内で実行される主な活動を分析し文書化する方法のニーズを認識した。そこで、ICAMから管理と事業改善努力におけるモデリングと分析のための標準である、IDEF群が登場した。IDEFは、ICAM DEFnitionを意味する。
※この「全貌」の解説は、「ICAM」の解説の一部です。
「全貌」を含む「ICAM」の記事については、「ICAM」の概要を参照ください。
全貌
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2018/10/03 09:17 UTC 版)
「エンタープライズエンジニアリング」の記事における「全貌」の解説
工学の1つの分野で、より一般化された形のエンタープライズエンジニアリングが出現した。 『これは、それがプロダクト、プロセス、及び事業運営（英語版）の各項目で、企業全体をエンジニアリングするシステム工学と戦略的経営を結びつける、本質的に学際的分野であり、企業に関連する全ての要素の分析、設計、実装、及び運用に係わる知識、原則、及び熟達性（専門的技能）のアプリケーション』を含んでいる。 この分野は、エンジニアリング管理（英語版）、運用管理、サービス管理（英語版）、及びシステム工学を関係付ける。 ソフトウェア開発の文脈におけるエンタープライズエンジニアリングの1つの特定分野は、『事業プロセスの様々な組織的及び技術的なモデリングと統合』を取り扱うことと言える。情報システム開発の文脈では、組織的なシステム分析の活動領域であり、既存の情報モデリングの概念範囲を拡張する。それはまたソフトウェア開発工程におけるシステム分析とシステム設計フェーズの拡張と一般化であるとも言える。そこでエンタープライズモデリングは、情報システム開発ライフサイクルの初期、中間、及び後期の部分を形成する。組織的及び技術的なシステム・インフラの明らかな表現は、既存の実践作業の整然とした転換を理解するため開発される。 この専門的技能（熟達性）は、エンタープライズアーキテクチャ、あるいはエンタープライズアーキテクチャの2つの主要なサブ分野の1つであるTemplate:エンタープライズオトロジを伴うことが知られている。
※この「全貌」の解説は、「エンタープライズエンジニアリング」の解説の一部です。
「全貌」を含む「エンタープライズエンジニアリング」の記事については、「エンタープライズエンジニアリング」の概要を参照ください。
全貌
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/11/12 13:45 UTC 版)
「エンタープライズアーキテクチャフレームワーク」の記事における「全貌」の解説
エンタープライズアーキテクチャフレームワークの3つの構成要素は以下である。 ビュー : 仕組（アーキテクチャ）に重要な関係性についての情報をコミュニケートするのためメカニズムを提供する。 手法 : 整合性、正確性及び完全性の確認を助ける方法で、データを集め、組織化し、そしてビューを構築する規律を提供する。 訓練／経験：手法の応用とツールの利用を支援する。 エンタープライズエンジニアリングとエンタープライズアーキテクチャの規律が大変広いこと、及び事業体は大きくまた複雑であり得ることから、規律を持った関連するモデルも大規模かつ複雑であるといえる。このスケールと複雑性を管理するため、アーキテクチャフレームワークは、彼らが最も必要とするとき価値ある人工物を作り出すことに焦点と許可をタスクに持ち込むようにツールと手法を提供する。 エンタープライズアーキテクチャは、情報技術及び情報システム統治（ガバナンス）で一般に使われる。組織は、システム設計が認可される前に作り出されるべき一定のモデルを委任したいと望むかもしれない。同じように彼らは、調達されたシステムのドキュメントに使われる一定のビューを特定したいと望むかもしれない。そのためアメリカ国防総省は、一定以上の資金プロジェクトのため、装置サプライヤによって提供される特定のDoDAFビューを規定した。
※この「全貌」の解説は、「エンタープライズアーキテクチャフレームワーク」の解説の一部です。
「全貌」を含む「エンタープライズアーキテクチャフレームワーク」の記事については、「エンタープライズアーキテクチャフレームワーク」の概要を参照ください。
全貌
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/11/12 13:46 UTC 版)
「エンタープライズモデリング」の記事における「全貌」の解説
エンタープライズモデリングは、プロセスモデル、データモデル、資源モデル、あるいは新しい概念体系などを伴うビジネスの全体または一部のモデルを構築するプロセスである。それは、企業についての知識、以前のモデル、あるいはモデル表現言語を使ったドメインの概念体系と同様に、参照モデルに基づいている。一般に1つの企業は、経済的組織あるいは活動の単位である。これらの活動は、プロダクトあるいはサービスを開発し顧客に提供する。1つの企業は、調達、製造、マーケッティング、財務、エンジニアリング、及び研究と開発のような複数の機能や運用を含んでいる。関心の企業とは、現在と潜在的な将来変化するプロダクトを製造するのに必要なそれらのコーポレート機能と運用である。 用語としての『エンタープライズモデル』は、真の標準定義がない、異なったビジネス表現を表す業界で使われる。企業組織の複雑さゆえに、膨大な数の異なるエンタープライズモデリングのアプローチが業界及び学界を超えて追求された。エンタープライズモデリングの構築は、製造運用あるいは事業運用に焦点を当てることができるが、エンタープライズモデリングにおける共通の目的は、情報技術による査定の融和である。例えば、物品サプライチェーンに沿って、必要な物の発注と受注する場合において、コンピュータを利用し、ネットワークにより、情報をやりとりする方式は、情報技術が企業内で製造・運用をどのように協調させるかをモデル化するため使われる例である。 Ulrich Frankによると、エンタープライズモデリングの基本的考え方は『学界と実務の両方における、様々な利害関係者間の対話を促進するための媒体を準備することにより、1つの企業における様々なビューを提供すること』である。この目的において、戦略的計画（英語版）、ビジネスプロセス・リエンジニアリング、及びソフトウエア工学のための適切な抽象化を行う。ビューは、体系的な抽象概念による複雑システムのより良い理解を早めるため、お互いに補完し合うべきである。ビューは、それらがあらゆるビジネスにも適用できるように一般化されるべきで、同時にそれらは、会社の長期間の戦略とその組織とうまく統合された情報システムの設計に助けとなる抽象概念を提供すべきである。それ故エンタープライズモデリングは、高度の統合をサポートする概念的インフラと見なされ得る。
※この「全貌」の解説は、「エンタープライズモデリング」の解説の一部です。
「全貌」を含む「エンタープライズモデリング」の記事については、「エンタープライズモデリング」の概要を参照ください。
全貌
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/10/17 06:26 UTC 版)
モデリング言語は、図式またはテキスト形式であり得る.。 図式 概念などを表現する楕円や箱、その関係を表現するライン、及び制約を表現する様々な記号、などといった、形式的なダイアグラムと、それらに付される名前などにより表現する。 テキスト形式 形式言語を文字列により表現する。 （UMLの一部の図のように、形式的でないものもある。形式的でないものは、その意味が曖昧かもしれない） 図式モデリング言語とテキスト形式モデリング言語への対応の一つの例は、EXPRESSである。 全てのモデリング言語は実行可能なわけではなく、そしてそれらが存在することで、それらの使用がもはやプログラマーが要求されないことを必ずしも意味しない。それどころか、実行可能モデリング言語は、熟練したプログラマーが、並列コンピューティングや分散化システムのようにより挑戦的な問題に取り組むため、彼らの生産性を増大させることを意図している。
※この「全貌」の解説は、「モデリング言語」の解説の一部です。
「全貌」を含む「モデリング言語」の記事については、「モデリング言語」の概要を参照ください。
全貌
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2020/04/18 02:43 UTC 版)
'参照モデル'に包含される幾つかの概念が存在する。これら概念のそれぞれは重要である： 抽象的：参照モデルは抽象的である。参照モデルで記述される『もの』は実際のものの抽象的な表現である。ある家の仕組みを記述するとき、実際の外壁は寸法と材質で規定されるが、参照モデルとしての外壁は壁の概念の一部である。人は、壁を持つ家を建てるため、壁の概念を理解しなければならない。 エンティティと関係性：参照モデルは、エンティティ（存在するもの）と関係性（どのようにそれらがお互いに作用するか）の両方を含む。エンティティのリストは、それだけでは、参照モデルを記述するには不十分である。 一つの環境の中で：一つの参照モデルは、『全てのもの』を記述しようとはしない。一つの参照モデルは、『一つの環境でのもの』あるいは問題空間を明確にするため使われる。参照モデルが有用であるためには、それが解決する問題と、その問題が解決されるのを見る必要のある利害関係者が持つ関心についての、明確な記述を含むべきである。 技術的不可知論（Technology Agnostic）：もしそれが特定のコンピューティング環境における技術やプラットフォームについて仮定するなら、参照モデルは有用ではない。参照モデルは、直面した問題を理解するためのメカニズムであり、それに係わるソリューションではなく、そして実際に、その実践者に価値を提供するため選ばれたソリューションと独立でなければならない。注釈：問題空間として『ソフトウエア・アプリケーションのセットを如何に管理するか』があり得ることから、これはソフトウエア・アプリケーションのセットを記述する参照モデルの開発を防げるものではない。
※この「全貌」の解説は、「参照モデル」の解説の一部です。
「全貌」を含む「参照モデル」の記事については、「参照モデル」の概要を参照ください。
全貌
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/08/06 14:25 UTC 版)
IDEF0 機能モデリング手法は、組織又はシステムの意思決定、行動、あるいはアクティビティをモデル化するよう設計された。それは、Douglas T. RossとSofTech, Inc.によって開発された、確立した図式モデリング言語SADTから派生した。そのオリジナル形式で、IDEF0は、図式モデリング言語（構文Syntaxと意味論）の定義と、モデル開発のための包括的手法論の解説の両方を含んだ。米空軍は『システムの機能的観点を分析しコミュニケートする機能モデリングFunction_model手法を開発した。IDEF0は、単純化された図式手段を通して分析者と顧客間のシステム分析を組織化し、効率的コミュニケーションを促進することで補助すべきである。』ことをSADT開発者に委託した。 フローチャートは、製品productの機能的流れを示すため使われるところで、IDEF0は、ライフサイクル・プロセスのデータフロー、システム・コントロール、及び機能的フローを示すため使われる。IDEF0は、事業、製造、あるいは事業体運営のその他のタイプの広く多様な姿をあらゆる詳細さのレベルまで、図的に表現する能力を持っている。それは、厳密で正確な記述を提供し、そして用途や解釈の整合性を促進する。それは、政府や民間産業による長年の活用を経て良くテストされ証明されている。それは、各種のコンピュータ・グラフィック・ツールで生成される。幾つかの商用製品が、IDEF0ダイアグラムとモデルの開発と分析を特別に支援する。 関連する技術である、情報モデリングのための統合定義（IDEF1X）は、データ指向システムのためのIDEF0を補足するため使われる。IDEF0標準：連邦情報処理標準公開183（FIPS 183）とIDEF1X標準（FIPS 184）は、アメリカ国立標準技術研究所（NIST）によって維持されている.
※この「全貌」の解説は、「IDEF0」の解説の一部です。
「全貌」を含む「IDEF0」の記事については、「IDEF0」の概要を参照ください。
ウィキペディア小見出し辞書の「全貌」の項目はプログラムで機械的に意味や本文を生成しているため、不適切な項目が含まれていることもあります。ご了承くださいませ。 お問い合わせ。