インフラアーキテクトとアプリケーションアーキテクトはこれをもとに会話するのがよいと思う。さらにユーザともね。
ここからSA/SDとOOA/OODに分岐していくイメージ。
路線
道路管理者によって指定・認定されている道路網上の単位であって、起点から終点までを結ぶ。属性：
路線名：文字列
路線を一意に識別するための名称。道路種別と路線番号から構成される。また、主要
地方道、都道府県道、市町村道などの場合は、全国で一意に識別するために、当該都
道府県、市町村の名称も含む。種別：文字列
道路の区分で、道路の存在する地域及び地形の状況によって分類したもの。
第一種、第二種、第三種、第四種級別：文字列
道路の区分で、道路の種類、存在する地域の地形、計画交通量によって分類したもの。
第一級、第二級、第三級、第四級道路種類：文字列
道路法第3 条で定められた道路網上に占める役割によって分類したもの。
高速自動車国道、一般国道、都道府県道、市町村道自動車専用道区分：論理値
自動車専用道に指定されているか否か。
定義域
TRUE:自動車専用道
FALSE:自動車専用道でない場合存在期間：数値
路線認定された時間から、路線認定を外されるまでの期間。
コード化されていない例をあげだが、実際はコード化されていることが多い。したがって、コード定義書も必要になる。
余談:
伝票などインスタンスベースで分析をすると、たとえば勘定科目っていくつあるかみたいなことを調査するのを忘れがちである。
この勘定科目は部門でまちまちであることもある。悲惨なのは勘定科目にコードを入力している場合である。全社システムを導入する際にユーザ教育に時間がかかる、もしくはユーザの反発が予想される。なぜなら、自分達の覚えたコードをそのまま使いたがるからである。
