2007年02月28日

[UML] 会社をUMLで描ききる試みについて || システムを取り巻くしがらみの図

システムエンジニアとか、システム分析、という言葉があります。はたして、そこで言われているシステムって何だろうと思いつつも、あまりよく考えたことはありませんでした。
そう思って調べてみると、IEEE 1471(IEEEのアーキテクチャ概念モデル(下図))では、「システム」に一つの定義を与えていました。
ieee1471.gif
概略(By Jan Øyvind Aagedal):
「システム」(Asystem)は、特定の機能もしくは機能セット実現のために組織化されたコンポーネントの集合である。システムという用語には、個々のアプリケーション、従来の意味である体系、サブシステム、システムのシステム、製品ラインアップ、製品ファミリー、企業全体、そのほかあらゆる関心事が含まれている。システムは、それがある環境(environment)における1つ以上の「ミッション」を遂行するために存在する。
環境(あるいは前後関係)によって、そのシステムにおける開発上、運用上、政治上など、さまざまな影響の設定や状況が決まる。
「ミッション」(missions)とは、1人以上の「利害関係者」が一連の目的を達成するためにシステムに期待する用途もしくは運用方法である。
「利害関係者」(stakeholders)は、1つのシステムに対して同じ関心もしくは懸念を持つ個人、チーム、もしくは組織(その意味では各階級も)である。 典型例は、下記。
¨ Client
¨ Acquirer
¨ Owner
¨ User
¨ Operator
¨ Architect
¨ System Engineer
¨ Developer
¨ Designer
¨ Builder
¨ Maintainer
¨ Service Provider
¨ Vendor
¨ Subcontractor
¨ Planner


viewpoint.gif
これは、IFEAD というところが、IEEE1471をもとに企業体ドメインに変換し、拡張したものです。いわば、企業を「システム」に見立てた図です。
図の読み方は、難しいですが、「会社」とその使命、関係者を抽象的に定義する試みは、箱庭のようで興味深い。

※ IEEE1471は、下記売店で、78ドルです。
http://shop.ieee.org/ieeestore/Product.aspx?product_no=SS94869



Summary of IEEE 1471
By Jan Øyvind Aagedal, SINTEF Telecom and Informatics
より


Starting with system, it is defined to be “a collection of components organized to accomplish
a specific function or set of functions.” For the purposes of the recommended practice, “the
term system encompasses individual applications, systems in the traditional sense,
subsystems, systems of systems, product lines, whole enterprises, and other aggregations of
interest.” From this it follows that anything can be a system as long as it fulfils some purpose
(i.e., accomplishes function(s)) and one chooses to view it as a whole.

A system inhabits an environment, while the environment of a system can influence that
system. The environment, sometimes referred to as the context, “determines the settings and
circumstances of developmental, operational, political, and other influences upon that system.
The environment can include other systems that interact with the system of interest, either
directly via interfaces or indirectly in other ways. The environment determines the
boundaries that define the scope of the system of interest relative to other systems”.
Essentially, one draws a line between the system of interest and anything outside that system
that influences it in some way. This line is the interface between the system and its
environment.

A system has one or more stakeholders. A stakeholder has one or more concerns relative to
the system. Concerns are “those interests which pertains to the system’s development, its
operation or any other aspects that are critical or otherwise important to one or more
stakeholders.” Typical concerns a stakeholder can have relative to a system are functionality,
performance, security, reliability, safety, etc.
A system exists to fulfil one or more missions in its environment. The existence of a system
has a purpose; it should meet one or more objectives of one or more stakeholders. Often
some of these objectives coincide with enterprise objectives so that using the system is an
efficient use of resources in the enterprise.

So far, the terminology presented has only been related to systems and their environments.
However, most of IEEE Std 1471-2000 is concerned with architectural descriptions, and in
the following terminology related to this are presented.
A system has an architecture and this can be described in an architectural description. Note
the distinction between the architecture of a system, which is conceptual, from the description
of this architecture, which is concrete. Architectural description is defined as “a collection of
products to document an architecture”. The architectural description can be divided into one
or several views. Each view covers one or more stakeholder concerns. View is defined as “a
representation of a whole system from the perspective of a related set of concerns”. A view is
created according to rules and conventions defined in a viewpoint. Viewpoint is defined as “a
specification of the conventions for constructing and using a view. A pattern or template from
which to develop individual views by establishing the purposes and audience for a view and
the techniques for its creation and analysis”. The distinction between view and viewpoint is
analogous to that between a searchlight and what one sees using the searchlight as shown in
Figure 2. A view expresses those concerns of a system architecture that are defined in its
viewpoint definition. The viewpoint defines the languages and methods to use when
describing such views.
posted by TAKEJI at 21:16| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/34907687
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。