5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

ヌスメ!アプリケーション・アーキテクチャ

1 :デフォルトの名無しさん:2009/02/15(日) 14:34:01
アプリケーション・アーキテクチャのススメ

これからの時代、業務アプリケーション開発のみならず
SOHOでプログラマをして喰っていこうという人は多いはず。

そこで気をつけなければならないのが、
趣味で作るプログラムと依頼されて作るプログラムで
決定的に違う部分、スケジュール管理である。



2 :デフォルトの名無しさん:2009/02/15(日) 14:47:40
プログラミングを請け負う際、まず必要となるのが工数の見積もりである。
依頼者からの具体的な要件を聞いた後、
それを作るためにどのくらい時間がかかるか、答えなければならない。

また、趣味で作るプログラムであれば
自分でテストしながらコーディングしていけばいいが、
依頼されて作るプログラムではそうはいかない。

発注者の視点で考えてみればよくわかる。
プログラムが出来上がる数ヶ月間、どういったものが
作られているか全くわからないままただ待つというのは、
とても不安な話である。ましてや金を出しているのだから、
内容は逐一把握しておきたいと思うものである。
どういったものが出来上がるのかわからないものに、
数ヶ月前から金を払う、なんて話はどこの世界にもない。

半年かけて自分では「完璧だ」と思えるような作品が出来上がっても
他人の目からみたら「全く使えないもの」であることはよくある話だ。
そういったことを危惧し、開発を管理するのが発注者の役目でもある。
プログラマの自己満足な作品に終わらないよう、
外部の目によるチェックやテストが必ず要求される。

そういった理由で、プログラマには必ず外部の目によるチェックやテストが要求される。

また、他のテスターと連携をとる形になれば、より細かく工数を見積もらなければならない。


3 :デフォルトの名無しさん:2009/02/15(日) 14:50:00
アプリケーション全体が完成するまでテストできない、
というのでは、テスターとの分担作業も不可能。
また、機能ごとのチェックやテストをしてみたい、
場合によっては機能の変更なども考えたい、
といった発注者側の都合にも対応できない。


4 :デフォルトの名無しさん:2009/02/15(日) 14:50:52
以上のような経緯から、プログラマーには
次のようなスキルが求められる。

・アプリケーション全体を作るのではなく、要求された機能を一つずつ完成させ、
 単体テスト(アプリケーション全体から見れば一部の機能についてのみのテスト)
 を可能にするスキル。

・複数の機能にまたがるような設計は極力避け、
 外部の人間が機能ごとにテストできるようにするスキル。

・一つずつ単独で作った機能を、最終的に矛盾なく一つにまとめ、
 アプリケーション全体での整合性をスムーズに取れるような設計手法。

つまり、個人プログラマによる開発においても、
アプリケーションを分担して開発する手法が必要とされているのである。
このことは、分散アプリケーションの設計概念であるアプリケーション・アーキテクチャを
個人プログラマに適用させる必要があることを意味している。

各機能ごとにプログラムを組む際、一貫した設計概念があれば、
最終的に一つのアプリケーションとしてまとめる際に整合性がとりやすくなる。
また、各機能ごとにプログラムを完成させるため、機能ごとの工数が見積もりやすくなり、
機能ごとのテストも容易になる。


では具体的に、個人プログラマによる分担アプリケーション開発における
アプリケーション・アーキテクチャとはどのようなものなのか。

5 :デフォルトの名無しさん:2009/02/15(日) 14:52:54
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

                  京都大学霊長類研究所

6 :デフォルトの名無しさん:2009/02/16(月) 07:55:51
>1の自己満足で終わっている。
これではスレも進みようがないわな。
話題も提供していないし。
「今日の俺は気分が良い」ってスレを建てるのと同じだ。

7 :デフォルトの名無しさん:2009/02/17(火) 12:57:22
スレタイはススメ!かなと思った。

8 :デフォルトの名無しさん:2009/02/18(水) 00:27:46
せめてスレで何を話したいのかを書いてくれればいいのだが

9 :デフォルトの名無しさん:2009/02/20(金) 23:36:27
スレタイにおっ、と思って開いたら1のレベルにがっかり

10 :デフォルトの名無しさん:2009/02/21(土) 15:57:28
いやここは1のレベルに関係なく
思いのたけをぶちまけようぜ。

アプリケーション・アーキテクチャ知らんと
業務アプリなんて絶対完成しないチクショウ

11 :デフォルトの名無しさん:2009/02/22(日) 00:29:01
ビジネス層からデータ層にアクセスする際、
DALC にアクセスするのか SA にアクセスするのか、
その判断ロジックは、ビジネス層に持たせるべき?

それともう一つ、DALC は、CRUD (Create,Refere,Update,Delete) メソッドを
持たせるべきってのはわかるけど、SA はそういうのないよね?
アクセス先のサービスからデータを取得してくるだけだよね?


12 :デフォルトの名無しさん:2009/02/22(日) 06:22:45
間が開いてしまったが、自分なりに思うところを述べる。
程度は低いので、熟練プログラマーである諸先輩方には
温かい目で見守っていてくれると続けやすい。


13 :デフォルトの名無しさん:2009/02/22(日) 06:23:32
まずは、アプリケーション・アーキテクチャの基本についておさらいしておく。
アプリケーション・アーキテクチャでは、次の三つの層(レイヤ)が定義されている。

1.ユーザーインターフェース層
 ユーザーインターフェースを定義する。

2.ビジネス層
 ビジネスロジックを定義する。

3.データ層
 データアクセスを定義する。

個人レベルでの分担アプリケーション開発においては、
ビジネス層の「ビジネス」という言葉は必ずしも適切ではないかもしれない。
趣味のためのツールであったり、個人で使うツールであったりと、
一般的にはビジネスと呼ばれないものの場合もあるからだ。

現存のアプリケーション・アーキテクチャと対応づけて論ずるため
そのまま「ビジネス」という言い回しをするが、
ここはそのアプリケーションの主な機能ということで
「アプリケーション」などと読み替えても良いかもしれない。
また、上記3つの層全てにまたがる要素として、
セキュリティや通信などを定義する層もあるが、
それについては、後ほど論ずることにする。




14 :デフォルトの名無しさん:2009/02/22(日) 06:26:00
アプリケーション・アーキテクチャで定義されている三つの層(レイヤ)について、
さらに、各層には次のようなコンポーネントが定義されている。


○ユーザーインターフェース層

 ・ユーザーインターフェースコンポーネント ( UI )
  ユーザーインターフェースを定義する。
  ボタンやラベルの位置や大きさ、ウインドウの概観など
  ユーザーと対話するための部品を定義するコンポーネント。

 ・ユーザープロセスコンポーネント ( UIP )
  ユーザーの作業プロセスを定義する。
  ユーザーインターフェース毎に個別にロジックを持たせず、
  同じような動作をするユーザーインターフェースや
  ウィザードの雛形を定義したい場合などに使う。
  また、長期に渡るユーザープロセスの管理(中断・再開)なども行う。
  ユーザーインターフェースの状態を管理するため、
  ユーザーインターフェースに直結する。場合によっては、
  ユーザープロセスコンポーネントは実装せず、
  ユーザーインターフェースコンポーネント内で済ませる場合もある。


15 :デフォルトの名無しさん:2009/02/22(日) 06:26:23
○ビジネス層

 ・サービスインターフェース ( SI )
  アプリケーションをwebなどのネットワーク上に公開する場合、
  サービスのやり取りのために必要な部分を定義するコンポーネント。

 ・ビジネス・ワークフロー ( BW )
  長期に渡るビジネス処理を管理するためのコンポーネント。
  中断や再開の機能を実装する。

 ・ビジネス・コンポーネント ( BC )
  ビジネス処理を定義するコンポーネント。
  アプリケーションの主な機能を具体的に定義する部分となる。

 ・ビジネス・エンティティ ( BE )
  ビジネス処理で使われるデータを定義する。
  ファイルやデータベースなどのデータソースをそのまま利用するのではなく、
  アプリケーションで利用しやすい形に加工したものをここで用意する。
  これにより、データソースに依存しないビジネス層が実現される。

○データ層

 ・データアクセスロジック・コンポーネント ( DALC )
  ファイルやデータベースなどのデータソース毎に、
  データの取得方法、更新方法などを定義する。

 ・サービスエージェント ( SA )
  ネットワーク上のサービスからデータを取得する場合に
  その取得方法などを定義する。


9 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)