2011/11/04 - 計算数学II 2011年度 15班 Google App Engine

作業

• Model View Controller と言われるものにしたがって、実装すれば動く (つもりの) コードを書いてみた: classes.txt. このような設計でよいのだろうか?
  • RequestHandler を継承した Output では、 get(), post() をそれぞれ GetReceiver, PostReceiver に委譲する。
  • GetReceiver は ConcreteGetter とテンプレートのパスからなる。
  • ConcreteGetter はデータを取ってくるだけなので、View の一部である。
  • PostReceiver は ConcreteProcessor とテンプレートのパスからなる。
  • AbstractProcessor は自分自身の todict(result), parse(request) を呼び出しているが、これは抽象メソッドであり、ConcreteProcessor で実装される。model.proc は '抽象変数のメソッド' である。
  • ConcreteProcessor はこれらを実装しているが、(データベースへの入力を伴うかもしれない) 実際の処理は ConcreteProcessingModel へ任せてしまっている。
• 実装 (とは言えないレベルのものであるが) してみたら動いた: source_20111103.zip!
  • 上の設計から、冗長な部分を取り除いたりしてある。
• 主に View, Controller にあたるものを UML のクラス図にしてみた、つもり。'?' は abstract であることを示す。ただし、図の AbstractGetter, AbstractProcessingModel はコードにない。単一の抽象メソッドからなるため実装する意味がないと考えた。こんな感じでよいだろうか? (コードとの一致、および、設計自体の適切さについて)

課題

• やっぱり全体の構造 (必要なクラス集合) を決めるのが最も難しいと感じる。
  • 2011/10/28 に書いた「コミュニティ」は管理ユーザ (アプリケーションの管理者と同じとは限らない) と一般ユーザとからなる。ただし管理ユーザの特権は一般ユーザを追加/削除することくらいでよいだろう。複数のコミュニティに所属したいユーザは Google アカウントを複数とってもらうってことでよいと思う (「ユーザ」は成績管理業務を担う人のことであるから、この仮定に無理はないだろう)。

コメント

• 僕もmarathonなどのコンテストに出るときは、こういう図を描いてみたいと思います -- チームK (2011-11-11 14:47:22)