| ドキュメント名 | 解説 | 様式番号 |
|---|---|---|
|
コンポーネント 開発計画書 |
新たに再利用コンポーネントの構築が検討される時に作成する計画書 | 5-01 |
|
パッケージ 開発環境標準 |
コンポーネント開発に必要となる標準的なルールを定めたもの。 | 5-02 |
|
パッケージ 利用解説書 |
コンポーネントを配布提供する単位（パッケージと呼ぶ）毎にクラスライブラリの使い方を解説したもの。この単位をフレームワークとする場合は、フレームワーク仕様書という名前になる。 | 5-03 |
|
パッケージ 仕様書 |
コンポーネントを配布提供する単位（パッケージと呼ぶ）毎にクラスライブラリの設計方針やオブジェクト設計について記述されたもの。 | 5-04 |
再利用コンポーネントの開発計画
コンポーネント要求分析
コンポーネント要求条件の作成コンポーネント要求モデルの作成
再利用基盤モデル分析
クラスライブラリ分析
パッケージ計画
パッケージ開発環境標準の作成
- ソースファイル名（ヘッダファイル名）
- ファイル名は、カテゴリ分類が可能で、かつ、分かりやすい名前にしなければならない。
例）
- カテゴリ名を１文字または２文字使用した名前とする。
- 一つのソースファイル（またはヘッダファイル）には、公開されたクラス１つといくつかの非公開のクラスがセットで格納 される。
- その他リソースファイル
- プログラム構築時や実行時に必要となるリソースファイルについて、そのファイル名付与規約を作成する。
- 統合化のために事前に環境を整備
- 開発当初は個人でソースを管理することになるが、最終的にパッケージというリリース単位を作成する際に、支障のないように事前にパッケージ結合後の開発環境構造を設計しておく。 最近では、ビジュアルな開発環境ツールが発達してきたが、このようなツールを利用する際には、そのツールを個人で利用する場合と、チーム全体で統合して利用する場合の２つのパターンを前もってルール化する。
- クラス名（公開）
- カテゴリ単位に２文字程度（大文字＋小文字）のプレフィックス に続き大文字で役割の名前を用いる。 クラス名は、理解しやすく、役割が明確にわかる名前とする。
よい例） AbLine,AbText,OwLine,OwText
悪い例） abline（小文字で始まっている）、getBuffer（機能名になっている）
- クラス名（非公開）
- プレフィックスにアンダーバー（_）を用いる。
よい例） _LineBuffer
悪い例） LineBuffer（公開クラスとの区別がつかない）
- 属性名
- 小文字で始まるわかりやすい名前とする。
例） firstName
- 公開メソッド名
- 小文字で始まる動詞、または動詞＋名詞の組み合わせ。
ただし、名詞にクラス名を含める必要はない。
例） draw,drawLine
- 非公開メソッド名
- プレフィックスにアンダーバー（_）を用いる。
例） _setline
※ベースとするクラスライブラリが大文字から始まるメソッド名を持つ場合もある。
このような時は、ベースとなるクラスライブラリに準拠する。
再利用範囲を予測しているか？コンポーネントの使われ方に集中しているか？