アメダス（KBC)

システムの命名法、何って、呼んだっけ？　忘れた

システムの命名法だ・・・　System Naming

System開発、プログラミングにおいて、開発を行いやすいような命名規則を作る

そういうことだ・・・



naming
【名】ネーミング、命名
【＠】ネイミング
naming authority
命名機関
naming ceremony
命名式、命名の儀
naming convention
命名規則、命名法
naming domain
命名領域
naming method
ネーミング方式
Naming Names
【著作】名指し・彼らは全部知っている◆《米国》Leo Townsend、1982。FBI に共産党に入党していたのを追及されたが、取り調べで Townsend が白状した人の名前、行動のすべてがすでに FBI にばれていた事を書いた本。
naming policy
命名方針
naming right
名称の権利、命名権、ネーミングライト◆通例 naming rights、カタカナ表記の場合も複数形（ネーミングライツ）が多い
naming rules
《コ》命名規則
naming schema
命名体系
naming scheme
命名体系
naming stage
命名期

ちなみに難易度が高い名前は、そのシステムの目的や理想のような英単語の頭文字をつなげて、最もらしい名前にすることだと思います。
これらの類では個人的にJSON（ジェイソン、JavaScript Object Notation）というデータフォーマットの名前が好きです。

http://isol.pro-s.co.jp/news/2008/12/11/naming/

システム開発とネーミング

2008-12-11 06:56

システム開発という仕事をしていると、何かに名前をつけなければならない事が多々あります。 何事も名前をつけるという行為は難しく悩ましいものです。
今回はシステム開発に纏わる「命名」という行為に関して少しお話したいと思います。

システム名

大規模なシステムではそのシステム自体に名前をつけることがよくあります。 「原価管理システム」とか「業務管理システム」というのではなく アメリカ人やイタリア人のような名前のついたシステムの開発に携わったことは何度かあります。
ジャストシステムの製品では「一太郎」とか「花子」等あえて日本人の名前を採用していたりするのは、日本企業ならではのこだわりが感じられ結構好きです。

ちなみに難易度が高い名前は、そのシステムの目的や理想のような英単語の頭文字をつなげて、最もらしい名前にすることだと思います。
これらの類では個人的にJSON（ジェイソン、JavaScript Object Notation）というデータフォーマットの名前が好きです。

開発しているシステムに名前をつけるということはいくつか利点があります。 例えば、「ディック」と命名されたシステムがあったとしたら「ＸＸＸシステム」とわざわざ呼ぶよりも「ディック」の方が会話がスムーズになりますし、何よりシステムに対して開発者の深い愛着が生まれます。

コードネーム

開発中の製品には名前とは別にコードネームが付いたりします。元々コードネームとは開発中の製品の機密保持が目的だったようですが、近年ではあえて一般に公開されることも多く、システムのバージョンを表す別名という意味合いが強くなってきています。

コードネームに限った事ではありませんが、一定のルールに則ってつけられる名前があります。コードネームで私が好きなのは２つあります。

一つはLinuxのディストリビューションの一つDebian GNU/Linuxのコードネームです。 Debianのコードネームは、下表の通り映画の「トイ・ストーリー」のキャラクタとなっています。woodyやsargeはよく利用しました。

バージョン	コードネーム	説明
1.1	buzz	バズ・ライトイヤー。主人公の宇宙飛行士。
1.2	rex	レックス
1.3	bo	ボー・ピープ
2.0	hamm	ハム
2.1	slink	スリンキードッグ
2.2	potato	ミスターポテトヘッド
3.0	woody	ウッディ
3.1	sarge	軍曹
4.0	etch	エッチ・ア・スケッチ

もう一つ好きなのはJava開発者なら身近なEclipseのコードネームです。Eclipseのコードネームは木星の衛星の名前からつけられています。木星の衛星というチョイスはかなりナイスです。

バージョン	コードネーム	説明
3.2	Callisto	カリスト
3.3	Europa	エウロパ
3.4	Ganymede	ガニメデ

ちなみにEclipseはもともとはIBMが開発した製品がベースとなっています（現在はオープンソースです）。 有名な話ですがEclipse（日食）というネーミングは、IBMがライバルのSun(太陽)との対立を表しているといわれていますが、 当然IBMは公式には否定しているようです。

ホスト名

私は社内にある数十台のサーバの面倒を見ていますが、以前は新しいサーバを立ち上げる際のホスト名の命名に悩みました。 例えば新しくWindowsＰＣを購入した際に、初期設定で「コンピュータ名」を何にしようか悩む方もいらっしゃると思います。しかしＰＣは後から簡単に変えられますが、サーバのホスト名の変更は、ＰＣほど容易には出来ません。

一般的に多数のサーバのホスト名の命名には選択肢が豊富なシリーズものが好まれ、例えば「太陽系の惑星」、「星座」、「動物名」、「ギリシャ神話の神」等はサーバ管理者の間ではよく使われています。

まだ私がサーバ管理者になりたての頃に、これらサーバのホスト名の命名で失敗したことがあります。 ある大規模プロジェクトで開発サーバを何台も構築する必要が発生した際に、 理由は忘れましたが何故か「北斗の拳」のキャラクターから名前を拝借したことがありました（多分疲れていたのです）。 かなり前なので、全てを思い出せませんが以下のような感じだったと思います。

・raou（ラオウ）
・kokuou（黒王号）
・kaiou（カイオウ）
・ken（ケンシロウ）
・yuria（ユリア）
・jagi（ジャギ）　　←ジャギと命名されたサーバはかなりスペックが低い

今思うとかなり痛々しい名前でしたが、当時は名前を考える時間も勿体無いくらい忙しかったわけです。

幸い、開発プロジェクトが終了したらこれらのサーバも別の開発サーバに転用されていった為、 再インストールでホスト名も消えていったのですが、諸事情により「kokuou」サーバだけは ついこの間まで弊社の中で現役で稼動しておりました。

最近は社内のサーバのホスト名は、それなりの命名規則に則ってつけていたのですが この「kokuou」だけは数年間もずっとこの規則から外れたサーバとしてがんばっていました。

この「kukuou」サーバにログインする度に、「ああ、やっぱり名前は慎重に考えないとイカン」と身に染みていました。。。

開発資源のネーミング

システム開発者が日常的に悩むのは、設計時のデータベースの「テーブル名」や「フィールド名」、コーディング時の「変数名」「メソッド名」「クラス名」等の命名でしょう。
「ああー、こんなクラス名をどうするかで悩んでいる暇ねーのに！」という思いは誰もが経験した事があると思います。

これらの命名は英語にするか日本語にするかという選択や、言語によっても文化が異なり意外と奥深い話題です。
また大規模システム開発ではこれらは命名規約によって左右されますので、その規約を作る人の手腕によって大きく左右されます。（テーブル名やクラス名がＩＤ形式の命名規約は最悪です。）

この辺の話は書き出すとまた長くなってしまうので、また別の機会に続きを書きたいと思います。

Posted by T.S

以下は、プログラミングの命名規則

http://ja.wikipedia.org/wiki/%E5%91%BD%E5%90%8D%E8%A6%8F%E5%89%87_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0)

---Wiki

命名規則（めいめいきそく、英: Naming conventions）とは、プログラミングを行う際に識別子の名称となる文字列を決定するためのルールを定めたもの。ネーミング規則、ネーミング規約、命名規約とも呼ぶ。

通常は、ソースコードの可読性や視認性の向上、プログラミング効率の改善などを目的としている。

命名規則は、プログラミング言語の仕様、メモリサイズ等のハードウェア的な制約、エディタや IDE の機能などに影響を受けていることがある。

命名規則を決めた場合の潜在的利点としては、以下のものが挙げられる。

• 識別子の使用法に関して追加情報（メタデータ）を名前に含める。
• 開発チーム内で命名について一貫性を持たせる。
• リファクタリングを自動化したり、検索置換ツールで間違える可能性を減らす。
• 潜在的な曖昧さを回避し、違いを明確化する。
• 成果物に美しくプロフェッショナルな見た目を与える（長すぎる名前、かわいい名前、面白い名前、略語を排除するなど）
• 複数のチームが開発したものを統合するような場合に、名前がかち合うのを防ぐ（名前空間参照）。

命名規則の選択とその実施は、論争になりやすく、各人がどんな命名規則が最善かについて意見を持っていることが多い。

さらに、よく知られている命名規則を採用したとしても、全体に実施を徹底させることができなければ、一貫性がなくなり、混乱が生じる。

このような課題は、その命名規則が一貫しておらず、記憶しづらく、利点よりも欠点が多いような場合には、さらに悪化する。

エンドユーザーが識別子の良否を意識することはほとんどないが、システムを引継いでゆくアナリストや開発者にとっては、識別子が適切に選定されていることで、システムが何をしているかを理解したり、さらには新たなビジネス所要に応じてソースコードをどのように修正・拡張すればよいかを判断することが極めて容易となる。

例えば、

a = b * c  

というコードは文法的に間違っているわけではないが、その意図・意味は見当もつかない。

これに対して、

weekly_pay = hours_worked * pay_rate

というコードでは、少なくともアプリケーションの基本的な前後関係を理解している人には意味・意図がよくわかる（weekly_pay = 週給、hours_worked = 勤務時間、pay_rate = 時給）。

命名規則は実際には、開発する対象や環境に依存する。しかし、多くの命名規則に共通に見られる要素がいくつか存在する。

識別子の長さ [編集]

命名規則の最も基本的な規則は識別子の長さに関するものである（長さの限度および識別子に使える文字の種類）。数値を挙げて上限を設定する場合もあれば、もっと緩やかなガイドラインを設定する場合もある。

識別子長の規則は議論の的になりやすく、学術的な議論にもなっている。

考慮すべき点:

• タイピングしやすいため、短い識別子が好まれる傾向がある。
• あまりにも短い識別子（'i' とか 'j'）は、識別が困難である。
• 短い識別子では暗号的な名前になるなど意味情報が込められないとして、長い識別子を好む場合もある。
• 長い識別子は見た目にも判別しづらいため、敬遠される場合がある。

これらの要素がどのように絡み合ってプログラマの好みが形成されるのかは明らかではなく、今後の研究が待たれる。

初期のリンケージエディタには、メモリ使用量を抑えるために変数名などを6文字以内に制限していたものがあり、そのために古いプログラムで識別子が短く制限されていたという事実もある。

大文字/小文字と数字 [編集]

命名規則によっては、大文字と小文字の使い方を制限しているものもある。また、大文字も小文字も使えるが、それらに意味を与える場合もある。アルファベット、数字、両方を混合した英数字の使い方を指定した命名規則もある。

複数の単語からなる識別子 [編集]

一般に「意味のある識別子」が推奨される。1つの単語では意味がわかりにくい場合もあり、複数の単語を識別子に使用することになる。結果として、命名規則には、複数の単語を連結する場合の方法が指定されることになる。

単語境界の表し方 [編集]

多くのプログラミング言語は識別子内に空白を許さない。そのため、空白以外で単語の区切りを示す方法が必要となる（区切りを示さないと、可読性が低くなる）。

区切り記号による単語の連結

英数字で記された単語を特定の区切り記号（デリミタ）で連結する。一般に、この目的で使われる文字は、ハイフン（'-'）かアンダースコア（'_'）である（例えば、two words を two-words とか two_words と記述する）。ハイフンはCOBOLやLISPでよく使われる。Cascading Style Sheets でもセレクタ名にハイフンが使われることが多い。他の言語（C言語やPascal系など）はハイフンが引き算の記号と同じであるため、識別子には使わない（使えない）のが一般的である。また、区切り記号を使った識別子は、テキストエディタやIDEなどのツールでソースコードを操作したときに、予期しない結果になることがある。

大文字/小文字による単語の切り分け

単語の頭文字を大文字、それ以外を小文字にする。例えば、two words は twoWords や TwoWords と記述される。これをキャメルケースなどと呼ぶこともある。

メタデータと命名規則 [編集]

命名規則によっては、特定のプロジェクトや問題領域に必要とされる規則や必要条件というだけでなく、ソフトウェアアーキテクチャによって定義される原則、根底にあるプログラミング言語やプロジェクト横断的な方法論などを表す大きな枠組みを提供する。

ハンガリアン記法 [編集]

最もよく知られている命名規則としてハンガリアン記法がある。これには、「目的」を名前に含める方式（アプリケーションハンガリアン）と、「データ型」を名前に含める（システムハンガリアン）に分けられる。

桁位置に意味を持たせる記法 [編集]

非常に短い（8文字以下）長さで識別子を形成する場合、桁位置ごとに意味を持たせることがある。例えば、LCCIIL01 という名前で、先頭の LC は「信用状（letter of credit）、次の C は COBOL、IIL は 特定のプロセスサブセットを表し、01 がシーケンス番号となっている。

このような規則はメインフレームでのJCLなどで今でも使われている。また、MS-DOSでのファイル名（8文字＋拡張子3文字という制限がある）でも見られる。

単語連結法 (OF Language) [編集]

初期の命名規則として、IBMが1980年代にIMS（Information Management System）のマニュアルで採用した "OF Language" がある^[要出典]。

これは、PRIME-MODIFIER-CLASS（主要部-修飾部-クラス）の形式で、例えば "CUST-ACT-NO" という名前で "customer-account-number"（顧客-口座-番号）を表す。

PRIMEの単語は、システムが対象とする主な実体を指す。MODIFIERの単語は、補助的な具体化をしたり、可読性を向上させる役目を持つ。CLASSの単語は理想的にはデータ型を表す短いリストである。典型的なCLASS単語として、NO（number）、ID（identifier）、TXT（text）、AMT（amount）、QTY（quantity）、FL（flag）、CD（code）、W（work）などがある。実際、CLASS単語としては2ダースほどの単語がリストアップされている。

CLASS単語は一般に右端（接尾辞）に置かれ、ハンガリアン記法（システムハンガリアン）の接頭辞と同じ役目を果たしている。

CLASS単語の目的は、一貫性を保つだけでなく、プログラマにデータフィールドのデータ型を指示する意味がある。BOOLEAN（two values only）が登場するまでは、FL（flag）が二値だけをとるフィールドを示していた。

言語固有の命名規則 [編集]

C と C++ [編集]

C と C++ では、キーワードや標準Cライブラリの識別子の多くは小文字である。また、マクロで定義される識別子は慣習として大文字で書かれることが多い（これは、多くの言語で定数が大文字で書かれることと関連している）。また、アンダースコア2個、あるいはアンダースコアと大文字1個ずつで始まる名前は、実装上（コンパイラや標準ライブラリに）予約されているため、ユーザーは使えない（例えば、__reserved や _Reserved）。

Java [編集]

Javaでは、言語設計時点からクラスや変数での大文字の使い方が決められている。従って、Javaプログラマにとっては、widget.expand() と Widget.expand() では全く違う意味になる。これはコンパイラがそのような制限をかけているわけではないし、Widget クラスについてユーザーが知らなくても関係ない。

Visual Basic、VB.NET、BASIC [編集]

BASICは本来、C言語と違って大文字/小文字の区別をしていない言語である。IDEは場当たり的に変数の識別をしている。そのため、Visual Basic の命名規則は人間によって読みやすいように設定される傾向があり、識別子自身に関する情報をもたせようとしない。従って、C言語で lpszMyString となっている識別子は Visual Basic では MyString となる傾向があり、widget.expand() と Widget.expand() は同じ意味になる。

Delphi (Object Pascal) [編集]

Delphi言語は、VB系の言語と同様、大文字/小文字の区別を行なわないが、下記の命名規約が推奨されている。

• レコード型、オブジェクト型、クラス型、およびtypeキーワードによる型のエイリアスなど、型を表すシンボルは'T'で始める。
• インターフェイス型名は'I'で始める。
• クラスのフィールド名は'F'で始める。
• ルーチン名、メソッド名は大文字で始めて、大文字で単語を区切る（Pascal形式）。

なお、Delphiの文法や言語機能を一部導入しているC#言語および.NET Frameworkは、Microsoftによる標準的な命名規約も（C/C++よりはむしろ）Delphiに似たものを踏襲している^[1]。

Automated

Meteorological

Data

Acquisition

System


AMeDAS 自動気象観測システム



http://www.jma.go.jp/jma/kishou/know/amedas/kaisetsu.html

アメダス（AMeDAS）とは「Automated Meteorological Data Acquisition System」の略で、「地域気象観測システム」といいます。 雨、風、雪などの気象状況を時間的、地域的に細かく監視するために、降水量、風向・風速、気温、日照時間の観測を自動的におこない、気象災害の防止・軽減に重要な役割を果たしています。 アメダスは1974年11月1日から運用を開始し、現在、降水量を観測する観測所は全国に約1,300ヶ所あります。このうち、約850か所（約21km間隔）では降水量に加えて、風向・風速、気温、日照時間を観測しているほか、雪の多い地方の約290か所では積雪の深さも観測しています。

地域気象観測所一覧[PDF形式：約380KB]

表示データについて

種類	内容	単位
降水量	降ってくる雨や雪の量	0.5mm単位で表しています。 雪やあられなどは、溶かして水にしてから観測します。
風向	風の吹いてくる方向	北、北北東、北東、東北東、東、東南東、南東、南南東、南、南南西、南西、西南西、西、西北西、北西、北北西の16方向で表しています。観測前10分間の平均値です。 北東の風とは北東から吹いてくる風をいいます。
風速	風の速さ	1m／s単位で表しています。 観測前10分間の平均値です。
気温	空気の温度	0.1℃（摂氏）単位で表しています。
日照時間	太陽が照らした時間	0.1時間（6分）刻みで表しています。 例えば、11時から12時の1時間にすべて太陽が照っていたら１時間と表します。
積雪の深さ	積もっている雪の地面からの高さ	1cm単位で表します。