ヌスメ！アプリケーション・アーキテクチャ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2009/02/15(日) 14:34:01これからの時代、業務アプリケーション開発のみならず
SOHOでプログラマをして喰っていこうという人は多いはず。
そこで気をつけなければならないのが、
趣味で作るプログラムと依頼されて作るプログラムで
決定的に違う部分、スケジュール管理である。
0002デフォルトの名無しさん
2009/02/15(日) 14:47:40依頼者からの具体的な要件を聞いた後、
それを作るためにどのくらい時間がかかるか、答えなければならない。
また、趣味で作るプログラムであれば
自分でテストしながらコーディングしていけばいいが、
依頼されて作るプログラムではそうはいかない。
発注者の視点で考えてみればよくわかる。
プログラムが出来上がる数ヶ月間、どういったものが
作られているか全くわからないままただ待つというのは、
とても不安な話である。ましてや金を出しているのだから、
内容は逐一把握しておきたいと思うものである。
どういったものが出来上がるのかわからないものに、
数ヶ月前から金を払う、なんて話はどこの世界にもない。
半年かけて自分では「完璧だ」と思えるような作品が出来上がっても
他人の目からみたら「全く使えないもの」であることはよくある話だ。
そういったことを危惧し、開発を管理するのが発注者の役目でもある。
プログラマの自己満足な作品に終わらないよう、
外部の目によるチェックやテストが必ず要求される。
そういった理由で、プログラマには必ず外部の目によるチェックやテストが要求される。
また、他のテスターと連携をとる形になれば、より細かく工数を見積もらなければならない。
0003デフォルトの名無しさん
2009/02/15(日) 14:50:00というのでは、テスターとの分担作業も不可能。
また、機能ごとのチェックやテストをしてみたい、
場合によっては機能の変更なども考えたい、
といった発注者側の都合にも対応できない。
0004デフォルトの名無しさん
2009/02/15(日) 14:50:52次のようなスキルが求められる。
・アプリケーション全体を作るのではなく、要求された機能を一つずつ完成させ、
単体テスト（アプリケーション全体から見れば一部の機能についてのみのテスト）
を可能にするスキル。
・複数の機能にまたがるような設計は極力避け、
外部の人間が機能ごとにテストできるようにするスキル。
・一つずつ単独で作った機能を、最終的に矛盾なく一つにまとめ、
アプリケーション全体での整合性をスムーズに取れるような設計手法。
つまり、個人プログラマによる開発においても、
アプリケーションを分担して開発する手法が必要とされているのである。
このことは、分散アプリケーションの設計概念であるアプリケーション・アーキテクチャを
個人プログラマに適用させる必要があることを意味している。
各機能ごとにプログラムを組む際、一貫した設計概念があれば、
最終的に一つのアプリケーションとしてまとめる際に整合性がとりやすくなる。
また、各機能ごとにプログラムを完成させるため、機能ごとの工数が見積もりやすくなり、
機能ごとのテストも容易になる。
では具体的に、個人プログラマによる分担アプリケーション開発における
アプリケーション・アーキテクチャとはどのようなものなのか。
0005デフォルトの名無しさん
2009/02/15(日) 14:52:54言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
0006デフォルトの名無しさん
2009/02/16(月) 07:55:51これではスレも進みようがないわな。
話題も提供していないし。
「今日の俺は気分が良い」ってスレを建てるのと同じだ。
0007デフォルトの名無しさん
2009/02/17(火) 12:57:220008デフォルトの名無しさん
2009/02/18(水) 00:27:460009デフォルトの名無しさん
2009/02/20(金) 23:36:270010デフォルトの名無しさん
2009/02/21(土) 15:57:28思いのたけをぶちまけようぜ。
アプリケーション・アーキテクチャ知らんと
業務アプリなんて絶対完成しないチクショウ
0011デフォルトの名無しさん
2009/02/22(日) 00:29:01DALC にアクセスするのか SA にアクセスするのか、
その判断ロジックは、ビジネス層に持たせるべき？
それともう一つ、DALC は、CRUD (Create,Refere,Update,Delete) メソッドを
持たせるべきってのはわかるけど、SA はそういうのないよね？
アクセス先のサービスからデータを取得してくるだけだよね？
0012デフォルトの名無しさん
2009/02/22(日) 06:22:45程度は低いので、熟練プログラマーである諸先輩方には
温かい目で見守っていてくれると続けやすい。
0013デフォルトの名無しさん
2009/02/22(日) 06:23:32アプリケーション・アーキテクチャでは、次の三つの層（レイヤ）が定義されている。
１．ユーザーインターフェース層
ユーザーインターフェースを定義する。
２．ビジネス層
ビジネスロジックを定義する。
３．データ層
データアクセスを定義する。
個人レベルでの分担アプリケーション開発においては、
ビジネス層の「ビジネス」という言葉は必ずしも適切ではないかもしれない。
趣味のためのツールであったり、個人で使うツールであったりと、
一般的にはビジネスと呼ばれないものの場合もあるからだ。
現存のアプリケーション・アーキテクチャと対応づけて論ずるため
そのまま「ビジネス」という言い回しをするが、
ここはそのアプリケーションの主な機能ということで
「アプリケーション」などと読み替えても良いかもしれない。
また、上記３つの層全てにまたがる要素として、
セキュリティや通信などを定義する層もあるが、
それについては、後ほど論ずることにする。
0014デフォルトの名無しさん
2009/02/22(日) 06:26:00さらに、各層には次のようなコンポーネントが定義されている。
○ユーザーインターフェース層
・ユーザーインターフェースコンポーネント ( UI )
ユーザーインターフェースを定義する。
ボタンやラベルの位置や大きさ、ウインドウの概観など
ユーザーと対話するための部品を定義するコンポーネント。
・ユーザープロセスコンポーネント ( UIP )
ユーザーの作業プロセスを定義する。
ユーザーインターフェース毎に個別にロジックを持たせず、
同じような動作をするユーザーインターフェースや
ウィザードの雛形を定義したい場合などに使う。
また、長期に渡るユーザープロセスの管理（中断・再開）なども行う。
ユーザーインターフェースの状態を管理するため、
ユーザーインターフェースに直結する。場合によっては、
ユーザープロセスコンポーネントは実装せず、
ユーザーインターフェースコンポーネント内で済ませる場合もある。
0015デフォルトの名無しさん
2009/02/22(日) 06:26:23・サービスインターフェース ( SI )
アプリケーションをwebなどのネットワーク上に公開する場合、
サービスのやり取りのために必要な部分を定義するコンポーネント。
・ビジネス・ワークフロー ( BW )
長期に渡るビジネス処理を管理するためのコンポーネント。
中断や再開の機能を実装する。
・ビジネス・コンポーネント ( BC )
ビジネス処理を定義するコンポーネント。
アプリケーションの主な機能を具体的に定義する部分となる。
・ビジネス・エンティティ ( BE )
ビジネス処理で使われるデータを定義する。
ファイルやデータベースなどのデータソースをそのまま利用するのではなく、
アプリケーションで利用しやすい形に加工したものをここで用意する。
これにより、データソースに依存しないビジネス層が実現される。
○データ層
・データアクセスロジック・コンポーネント ( DALC )
ファイルやデータベースなどのデータソース毎に、
データの取得方法、更新方法などを定義する。
・サービスエージェント ( SA )
ネットワーク上のサービスからデータを取得する場合に
その取得方法などを定義する。
■ このスレッドは過去ログ倉庫に格納されています