ISO/TR 26999:2012 高度道路交通システム—システムアーキテクチャ—ITS国際標準およびその他の成果物におけるプロセス指向の方法論の使用 | ページ 5

2.1

俳優

ターミネータのサブ要素

注記1:これは主に、ターミネータの特定のバリアントを他のバリアントと区別できるようにするために使用されます。たとえば、公共交通機関の運転者を他のタイプの運転手またはすべての運転手と区別するために使用されます。

2.2

建築模型

アーキテクチャ ビューのコンテンツに貢献するモデル

2.3

アーキテクチャ (一般的な定義)

ハードウェアおよびソフトウェア環境から独立した、システム全体のエンティティ間の相互関係を記述するシステムの概念と規則のセット。

注記1:アーキテクチャは、一般性/特異性、抽象化/概念、全体性/構成要素などのさまざまなレベルにある一連の視点を通じて記述されます。以下の「コミュニケーションの観点」、「機能の観点」、「組織の観点」、「物理的な観点」の定義も参照してください。

2.4

建築の視点

特定された一連のアーキテクチャ関連の問題の観点からのシステムの表現

2.5

アーキテクチャの説明

アーキテクチャを記述するために使用される情報のコレクション

2.6

願望

利害関係者が ITS の実装に提供してほしいと思っていることの表現。通常、利害関係者の言語で書かれているため、正式な構造がほとんどまたはまったくない可能性があります。

注記 1: ITS の各実装には、その範囲と関与する利害関係者の数に応じて、多くの願望が存在する可能性があります。

2.7

コミュニケーションの視点

関心のあるシステムのいくつかのアーキテクチャの観点の 1 つ。物理的な観点でビルディング ブロック間のリンクを示し、ビルディング ブロックが相互に通信できるようにし、予想されるデータ スループットの詳細と、通信ハードウェアおよびソフトウェア

2.8

機能的な観点

関心のあるシステムのいくつかのアーキテクチャの観点の 1 つ。ユーザーのニーズで表現された要件を満たすために必要な機能を示します。この機能は、一連の機能とデータ ストア、およびそれらの間のデータ フローとデータ フローとして示されます。関数とターミネータの間

2.9

ITSアーキテクチャ

ITS 実装の初期段階でツールとして使用するためのシステム アーキテクチャの特定の形式。

2.10

モデル

全体の重要な要素間の相互関係を保持しながら、特定の詳細を削除することによって、重要な要素が抽象化されたエンティティの表現。

注記 1モデルは，概念と関係が強調され，より容易に理解されるように，詳細を連続的に抑制することによって多かれ少なかれ抽象化することができる。ただし、単純化where必要な理解を達成できる限界を超えた場合、プロセスが行き過ぎてしまう可能性があります。したがって、モデリングのプロセスは、最適な理解と洞察を達成するのに十分なだけのプロセスであり、それ以上ではありません。

注記 2:モデルは、自然な状態以外のものを表現する方法です (参考文献の参考文献^[2]にある Web サイトの「ITS のモデル」文書を参照してください)

2.11

組織の視点

対象となるシステムのいくつかのアーキテクチャ上の観点の 1 つ。物理的な観点 (または機能的な観点) からのビルディング ブロックを、ITS に関与するさまざまなタイプの組織 (または、既知の場合は組織自体) に割り当てる方法を示します。実装

2.12

物理的な観点

関心のあるシステムのいくつかのアーキテクチャ上の視点の 1 つ。機能的な視点からの機能をさまざまな物理的な場所に割り当て、さまざまなビルディング ブロックに組み合わせる方法を示します。

2.13

利害関係者

ITS の実装に何らかの形で関与しているエンティティ

2.14

利害関係者のニーズ

利害関係者が ITS 実装が提供することを期待するものを定義し、そこから機能的な観点 (「ユーザーのニーズ」とも呼ばれる) を作成するための、「しなければならない (shall)」言語を使用した正式な表現

2.15

システムアーキテクチャー

システムの主要な要素またはオブジェクトと、それらの間の相互接続の単一の高レベルな説明

2.16

関心のあるシステム

ITS アーキテクチャから作成された ITS 実装に含まれるものに適用される、システムに使用される別の名前

2.17

ターミネーター

システムの外部にあるが、システムが通信して入力を取得するか、出力を送信できるエンティティ。

注記 1:ターミネーターは、必要に応じて複数の俳優に分割することができます。

注記 2:ほとんどの ITS アーキテクチャでは、ターミネータは機能的観点と物理的観点の両方で同じである可能性があります。

注記 3米国国家 ITS アーキテクチャでは、ターミネータは対象システムの境界を定義します。各ターミネータは、ITS に接続する人、システム、および一般的な環境を表します。ターミネータと、ナショナル ITS アーキテクチャ内のサブシステムおよびプロセスとの間のインターフェイスは定義されていますが、ターミネータには機能要件が割り当てられていません。 National ITS Architecture の論理アーキテクチャ ビューと物理アーキテクチャ ビューには、まったく同じターミネータ セットがあります。

2.18

統一モデリング言語

UML

ISO/IEC 19501 で規定されているオブジェクト指向モデリング言語

2.19

ユーザーの必要性

「利害関係者のニーズ」の別名

2.1

actor

sub-element of a terminator

Note 1 to entry: It is mainly used to enable a particular variant of a terminator to be differentiated from other variants, e.g. to differentiate a public transport vehicle driver from any other type of driver, or all drivers.

2.2

architectural model

model that contributes to the content of an architectural view

2.3

architecture (generic definition)

set of concepts and rules for a system that describes the inter-relationship between entities in the entire system, independent of the hardware and software environment

Note 1 to entry: Architecture is described through a series of viewpoints that might be at varying levels of generality/specificity, abstraction/conception, totality/component, and so on. See also “communications viewpoint”, “functional viewpoint”, “organizational viewpoint” and “physical viewpoint” definitions below.

2.4

architectural viewpoint

representation of a system from the perspective of an identified set of architecture-related concerns

2.5

architectural description

collection of information items used to describe an architecture

2.6

aspiration

expression of what a stakeholder wants the ITS implementation to provide, usually written in the language of the stakeholder and thus possibly having little or no formal structure

Note 1 to entry: There could be many aspirations for each ITS implementation, depending on its scope and the number of stakeholders that are involved.

2.7

communications viewpoint

one of several architectural viewpoints of the system of interest, showing the links between the building blocks in the physical viewpoint that will enable them to communicate with each other, and including details of expected data throughputs and any other constraints that will affect the eventual choices of communications hardware and software

2.8

functional viewpoint

one of several architectural viewpoints of the system of interest, showing the functionality that will be needed to fulfil the requirements expressed in the user needs, this functionality being shown as a series of functions and data stores plus the data flows between them and the data flows between the functions and the terminators

2.9

ITS architecture

specific form of a system architecture for use as a tool in the initial stages of an ITS implementation

2.10

model

representation of an entity from which the important elements have been abstracted by removing certain detail while at the same time retaining the interrelationship between the key elements of the whole

Note 1 to entry: A model can be made more or less abstract by the successive suppression of detail such that the concepts and relationships come into enhanced focus and become more readily understood. However, the process can be taken too far when the simplification has exceeded the threshold where a necessary understanding can be achieved. Thus the process of modelling is one of going only far enough to achieve the optimum understanding and insight — and no further.

Note 2 to entry: A model is a way of representing something, other then in its natural state (see “Models of ITS” documents at the web site given in Reference^[2] in the Bibliography).

2.11

organizational viewpoint

one of several architectural viewpoints of the system of interest, showing how the building blocks from the physical viewpoint (or the functional viewpoint) can be allocated to the different types of organization (or organizations themselves, if known) that will be involved with the ITS implementation

2.12

physical viewpoint

one of several architectural viewpoints of the system of interest, showing how the functionality from the functional viewpoint can be allocated to different physical locations and combined into different building blocks

2.13

stakeholder

entity that is involved in some way with the ITS implementation

2.14

stakeholder need

formal expression, using “shall” language, to define what the stakeholders expect the ITS implementation to provide, and from which the functional viewpoint is created, also known as “user need”

2.15

system architecture

single, high-level, description of the major elements or objects of a system plus the inter-connections between them

2.16

system of interest

another name used for the system, applied to whatever will be included in the ITS implementation that is created out of the ITS architecture

2.17

terminator

entity that is external to the system but with which the system communicates either to obtain inputs or to which it can send outputs

Note 1 to entry: Terminators may be split up into actors if necessary.

Note 2 to entry: In most ITS architectures, the terminators may be the same in both the functional and the physical viewpoints.

Note 3 to entry: In the US National ITS Architecture, a terminator defines the boundary of the system of interest. Each terminator may represent the people, systems and general environment that interface to ITS. The interfaces between terminators and the sub-systems and processes within the National ITS Architecture are defined, but no functional requirements are allocated to terminators. The logical and physical architecture views of the National ITS Architecture both have exactly the same set of terminators.

2.18

unified modelling language

UML

object-oriented modelling language specified in ISO/IEC 19501

2.19

user need

another name for “stakeholder need”