フレームワークによる開発

わんくま同盟東京勉強会 #22


実はどのように開発するのが良いのかよく分からない

これは、外部の開発者と接する機会が少ないことと、Google先生でも教えてくれない為、独自の開発方法となり、いわば井の中の蛙状態となってしまっている。ともかく今の開発方法を公開した上で、みなさんの知識の情報を収集しようという作戦です。


やじゅ＠静岡の田舎　 http://blogs.wankuma.com/yaju/

ＳＬ ( 大井川鉄道 ) が通っているところに住んでいます。

セッション　・「ドラえもんの世界をオブジェクト指向で」　　２月２３日　わんくま同盟東京勉強会＃１７　・「設計時の見落とし　 Google先生も教えてはくれない」　　３月２９日　わんくま同盟大阪勉強会＃１７


１．開発仕様について

２．フレームワークについて


・開発内容　（仮定）わんくま販売管理システム・モジュール構成について・フォルダ構成について・アセンブリの配置について・アプリケーション・ドメインについて・初回起動が遅いについて・開発方法について

・プロジェクト分割指針ってどうしてます？　意見求む

・バージョンの付け方ってどうしてます？　


（仮定）わんくま販売管理システム

　・開発規模　　プログラム本数　１００本　　ＤＢ Oracle10g 　８０テーブル　・開発ツール　　 Microsoft Visual Studio 2005 VB.NET2005

　サードパーティ製　　　入力コンポーネント、グリッドコンポーネント、

　　　帳票作成コンポーネント


メニュー画面 ( ログイン入力画面を含む ) のみＥＸＥ形式、それ以外はＤＬＬ形式とする。

１画面 ( 機能 ) で１プロジェクトとはせずにサブシステム単位でプロジェクトを分割する。※ここで言うプロジェクトは、ソリューションファイルを指す。※プロジェクト分割方針については、後述

※タスクスケジューラで動作させる処理は、 EXE 形式　または　 BAT ファイル＋SQLPlus( ストアド実行 ) とする。

　単独で動作させたい処理は、別途 EXE 形式で作成し、その中で該当する DLL を　呼ぶ形式で作成する。


ＡＰＰフォルダの中身　 wnkMenu.exe　 wnkMenu.exe.config　 wnkMitusmori.dll　 wnkJuchu.dll　 wnkUriage.dll　 wnkSeikyu.dll　　wnkShire.dll　　wnkZaiko.dll　　wnkMaster.dll　　wnkCommon.dll　　clsCommon.dll　　clsControlLibrary.dll　　clsDBAccess.dll　　各サードパーティ製 .dll　ｘ

　ｎ本

常に最新版があるフォルダを統一しておき、参照もＡＰＰから設定するビルド出力パスもＡＰＰとする。


．ＮＥＴでは side-by-side が基本なので、ＥＸＥと同じフォルダにＤＬＬを配置すればいい。※ｓｉｄｅ－ｂｙ－ｓｉｄｅは複数のバージョンを同じコンピュータで実行する機能です。

ＧＡＣ（グローバルアセンブリキャッシュ）への登録は、開発中はお勧めしません。開発の終わり頃に登録するくらいでもいいも・・・

．ＮＥＴＦｒａｍｅＷｏｒｋのウリの１つのキャッチフレーズとして「コピーしただけでインストール完了」があるらしい。

アセンブリの検索順既に読込み済のもの→ＧＡＣ→コードベース→プローブ (探査 )


．ＮＥＴアプリケーションでは１プロセスの中に型やセキュリティを管理する単位として、ＡｐｐＤｏｍａｉｎという器を作成する。

ＥＸＥ形式では、１プロセスとなるため、ＡｐｐＤｏｍａｉｎを作成することになり起動コストが高くなる。

ＤＬＬ形式では、ＡｐｐＤｏｍａｉｎ内にＤＬＬファイルが読み込まれ実行する。注意点　ＤＬＬのアンロードはＡｐｐＤｏｍａｉｎ　単位となるため、違う種類のＤＬＬを読み　込めば、それだけメモリが増大する。


ＰＣ起動直後は、ＣＬＲ（共通言語ランタイム）やＪＩＴコンパイラなど必要なモジュールが読み込み実行され、かつアプリケーションドメインの初期化に時間をとられるため、遅い。なお、ＶＩＳＴＡ上で．ＮＥＴアプリの起動が速いのは、上記処理が既に終わっているためです。

◆対応策：　・システムのスタートアップ時に画面が表示されない小さな．ＮＥＴアプリを起動して　　ＣＬＲなどをロードさせてしまう。　・アンマネージなスプラッシュ・スクリーンを作成して体感速度をごまかす。　・ＮＧＥＮでネイティブなコードにコンパイル、でもネイティブのまま配布はできない　・Ｓｃｏｔｔさんのｂｌｏｇによると、起動時間（コールドスタートアップ）の改善が　　２００８年の夏くらいに行う予定のようで、２５－４０％の改善予想とのこと。


・開発用にｄｌｌを起動するドライバを作成　外部プログラムの設定に指定　コマンドラインに起動内容を設定　（パラメータは、キー：値でセット、例 JUCHU_NO:1234 　 SortedList型で格納）


アセンブリ（ソリューション）をどう作成するべきか？

システム内に１００の機能 ( 画面 ) があったとします。その中は８つ ( 見積、受注、売上、請求、発注、仕入、在庫、マスタ保守 ) のサブシステムが分かれており、メニュー画面が１つあります。

１．全ての機能 ( 画面 ) を１つのＥＸＥとする。２．メニューはＥＸＥ、機能 ( 画面 )ごとにＥＸＥとする３．メニューはＥＸＥ、関連機能（サブシステム）ごとにＥＸＥとする。４．メニューはＥＸＥ、機能 ( 画面 )ごとにＤＬＬとする５．メニューはＥＸＥ、関連機能（サブシステム）ごとにＤＬＬとする。６．その他

※パターンが多くなるので、システム共通系としてＤＬＬが数個あることにします。

※機能 ( 画面 )ごとＥＸＥまたはＤＬＬにするとファイル管理コストばかり跳ね　上がってしまう予感がします。保守性とのトレードオフですかね。


＜メジャー・バージョン＞ . ＜マイナー・バージョン＞ . ＜ビルド番号＞ . ＜リビジョン＞開発時のアセンブリバージョン、ファイルバージョン　　基本は同じ値とする？

　　　　各項目値は、 0 ～ 65534

アセンブリバージョン　 1.0.1234.1

　アセンブリバージョン　 1.0.1.1234 アセンブリバージョン　 1.0.2008.712

アセンブリバージョン　 1.2008.7.12 　　アセンブリバージョン　 2008.7.12.1

　　　管理上、日付を入れたかったりする


・開発目的について・共通仕様を決める・フォーム、入力コントロールの継承と拡張について・抽象化を理解について・ポリモーフィズムについて・インターフェイスについて・簡易フロー・前処理・本処理・後処理について　・入力チェックの統一化について・ソースサンプル・まとめ


・共通機能を内包することによりアプリケーション側のコードの絶対量が削減され、製造者の負担を減らす。コードの統一化により、開発者のスキルの差が少なくなり、品質をある程度均一されることにより信頼性が向上する。

・型にはめる方が楽自由すぎると思わぬ不具合を引き起こす可能性が高い　型にはめてしまう事で、中身の製造に専念させる。


・画面最上部にファンクションキーボタン表示

・Ｅｎｔｅｒキーで項目移動・○○時 (登録など ) 、再度、項目移動のチェック + 全体の整合性チェック・項目移動で内容に変更なしなら、入力チェックはしない。・背景黄色の項目は検索画面を呼び出し可能 (Ｆ８キー連動）　・背景緑色の項目は表示専用　・入力項目を編集したなら、クリア時・終了時に確認メッセージを出力・検索項目ならＦ８キーを有効化、それ以外は無効化・グリッドコントロールならＦ５～Ｆ７キーを有効化、それ以外は無効化・行挿入、行追加が最大行数に到達ならＦ５、Ｆ６キー無効化・行削除が最低行数ならＦ７キーを無効化などなど


・ファンクションキーを配置、モード表示ラベル、　タイトル表示ラベル、ステータスバー・フォームの拡張プロパティ　編集フラグ、処理モード、フォームタイプ　ファンクションキー表示、検索画面の結果受取　検索保持コントロール、グリッド保持コント　ロール　などなど

・入力コントロールの拡張プロパティ　拡張Ｅｎａｂｌｅｄ、検索呼出　値変更通知、全チェック、項目値保持　などなど


マスターフォーム

IFWForm

各コントロール各コントロール

IFWControl

▲Use

Use▼

▲Use

テキストコントロール


IFWForm

Use▼

IFWControl

▲Use

グリッドコントロール

IFWGridView


IFWForm

Use▼

▲Use

インターフェイス　 IFWForm 、 IFWControl 、 IFWGridView など

インターフェイスというのは外部に公開するサービス ( メソッドやプロパティ等 ) の定義のセットです。今回でいえば、拡張したサービスを最小単位のクラス？として他クラスからアクセス可能とさせたいときに使っています。


関係・機能を抽出し、システム化したもの

グー

チョキパー

ジャンケンへび

かえるナメクジ

虫拳

３すくみ

関係を抽象化


共通サブルーチン呼び出す側Ａ呼び出す側Ｂ呼び出す側Ｃ

呼び出される側

呼び出す側が増えても呼び出される側を修正する必要がない　

ポリモーフィズム呼び出される側が増えても、呼び出す側を修正する必要がない　

呼び出される側Ｘ呼び出される側Ｙ呼び出される側Ｚ

呼び出す側

オーバーライド (再定義 ) によって、中身を書き換える。


前処理

画面起動

本処理

後処理

Ｌｏａｄ

初期化処理

前処理

更新アクション

本処理

後処理

全入力チェック

初期化処理

前処理

印刷アクション

本処理

後処理


初期化処理

前処理

ＣＳＶアクション

本処理

後処理


初期化処理

前処理

クリアアクション

本処理

後処理

初期化処理

モード変更 F1- F4

初期化処理

検索画面呼出

検索呼出処理

各アクション

ファンクションキー

処理振分け


前処理

アクション

本処理

後処理

基本の考え方

前処理

更新アクション

本処理

後処理


初期化処理

確認メッセージを出力登録します。よろしいですか？

完了メッセージを出力登録が完了しました。

トランザクション開始

正常ならコミット異常ならロールバック

各処理で異常なら次の処理へは進まないで、処理を抜ける。

例

継承元フォームにある程度記述し必要なら、継承先にて書き換える。


・各入力コントロールの入力チェック処理を、統一の入力チェックメソッド　ＩｎｐｕｔＣｈｅｃｋ　に統一する。　人によって、チェック処理を書くイベント (Leave ,Validating, Validated, Enter) が違っていた　

テキスト型、マスク型、数値専用型、日付型、コンボボックス型のＶａｌｉｄａｔｉｎｇチェックボックス型、ラジオボタン型のＣｈｅｃｋＣｈａｎｇｅｄ

継承先フォームにて入力チェック処理を記述

Ｅｎｔｅｒキー / Ｔａｂ移動で編集あり

検索画面の戻りのタイミング

全入力チェック( 更新ボタン前など )

各入力コントロールの入力チェック

ＩｎｐｕｔＣｈｅｃｋどこから呼ばれたのかは引数で渡されてくる。


'------------------------------------------------------------------ ' 更新前処理

'------------------------------------------------------------------ Protected Overrides Function UpdateBefore() As Boolean

'入力チェック以外の関連チェック処理 For Row = 0 To Detail.Rows.Count - 1 If IsItemCheck(Row,Shohin_cd) = False Then Return False End If Next 　　

' 親メソッド呼出更新確認メッセージ出力 If MyBase.UpdateBefore() = False Then Return False End If

Return True End Function


クラス作りは思いやりが大切複数のプログラマが１つのシステムを構築する場合には「私はクラスを作る人、貴方はクラスを使う人」という役割分担ができます。クラスを作る人は、クラスを使う人に楽をさせるための工夫をしましょう。それが、オブジェクト指向プログラミングを効果的に実践するための秘訣です。「思いやり」が大事なのです。


ご清聴ありがとうございました。

フレームワークによる開発

Documents

Transcript of フレームワークによる開発