E-ラーニングの成績管理は、Tin Can APIで、コンテンツと分離できるらしい

現在、E-ラーニングの標準規約としては、SCORMがある。
SCORMは、コンテンツをひとまとまりにして、作成する。
つまり、ＳＣＯＲＭで成績管理をしようとした場合、
コンテンツは、ＳＣＯＲＭ用のコンテンツとして纏め上げないといけない。

最近のＥ－ラーニングの新規約Tin Canは、そうではないらしい。
Tin Can APIは、成績管理のための受け渡しデータがＪＳＯＮ形式で決まっているようだ。


次世代SCORM – Tin Can API
http://scorm.jpn.org/projecttincan


つまり、
・成績管理サーバーをたてて、そこで、成績管理用のＷｅｂＡＰＩを用意しておく
・コンテンツは、成績についての情報を、Ｗｅｂ（ＲＥＳＴ）形式で、
　　　成績管理ＷｅｂＡＰＩを呼び出して、情報を渡す。
　　　　　→Tin Can APIにより、受け渡しデータはＪＳＯＮ形式が決まってるみたい
・成績管理サーバーは、そのデータを受けとって、ＤＢに保存
・必要なときに、ＤＢのデータをみて成績処理！

というように読める。

こうだとすると、コンテンツは、成績管理サーバーのＷｅｂＡＰＩをＡＪＡＸ形式で
呼び出せばよいだけとなり、便利便利に読めるんだけど、そういう意味なのかなあ？

ファイルのアップロード

各フレームワーク、言語で、ファイルのアップロードについて、調べてみた

■Java フレームワーク

・Struts

●Struts－１８．ファイルアップロード
http://www.javaroad.jp/opensource/js_struts20.htm


・Struts2

struts2でファイルアップロード(FileUpload Interceptorの設定、初期値、制限)
http://atohi.com/blog/post/2010/04/24/struts2e381aeFileUpload-Interceptere381abe996a2e38199e3828be8a8ade5ae9ae4ba8be9a085e38081e5889de69c9fe580a4e38081e58299e5bf98e98cb2.aspx



・サーブレット

●Servlet－１２．ファイルアップロード
http://www.javaroad.jp/servletjsp/sj_servlet12.htm


・Spring

第7回 SpringMVCで簡単！ファイル・アップロード
http://itpro.nikkeibp.co.jp/article/COLUMN/20080307/295677/


・JavaEE

Servlet3.0で追加されたファイルアップロードを使う
http://d.hatena.ne.jp/jabaraster/20110330/1301466968


■ＰＨＰ
・PHP

ファイルのアップロード
http://www.php-labo.net/tutorial/php/upload.html


・Cake PHP

CakePHP 画像や各種ファイルのアップロードフォームを作る
http://onlineconsultant.jp/pukiwiki/?CakePHP%20%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E3%82%A2%E3%83%83%E3%83%97%E3%83%AD%E3%83%BC%E3%83%89%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A0%E3%82%92%E4%BD%9C%E3%82%8B


■Ruby

Rubyでファイルのアップロード
http://shinob.cocolog-nifty.com/mix_dvd/2008/09/ruby-6381.html



■結論
どの言語でも、やりかたは、たいていＷｅｂに載っている。

正常系と異常系の区別とドキュメントの書き方について

正常系と異常系について、テストの観点から書かれているものが多い。
そして、区別が曖昧なものも多いです。
ところが、ソフトウェア工学の観点から見ると、これは、明確に分かれます。
　　→ユースケース記述で

そして、開発上、重要な意味を持つので、ちょっと所見を書いてみます。

---

■正常系とは

＜＜ソフトウェア工学的には：たぶん＞＞
・事前条件が成立するときに、事後条件が成立するケースが正常

＜＜解説＞＞
　ある処理に対して、入力値が適切であるとき、
　処理終了後の状態が、期待している通りになっているもの
　　　→期待している成果物ができている状態

■正常系でないとは
＜＜ソフトウェア工学的には：たぶん＞＞
２とおりある
　　　・事前条件が成立しないケース
　　　・事前条件は成立するが、事後条件が成立しないケース

＜＜解説＞＞
正常系でないのは、２とおりあります。

　　　・そもそも、入力値に間違い、エラーがある
　　　　　→入力チェックなどではじきます。

　　　・入力値は正しいが、処理中に何らかの問題を生じ、
　　　　期待した状態に達しなかった
　　　　　→通信エラー、ＤＢ中のエラー

２種類を一緒にして異常系という場合と、
ばらばらにわけで、エラーと例外とか、いろんな言い方を
する場合があります。

時と場合と会社とプロジェクトリーダーと
リーダーの気分によります。

---

■ドキュメントに書く場合

　正常系は、いくつものケースがありえます。
　そのため、正常系でも
　　　　一番単純なケースや
　　　　一番使われる頻度が多いケース、
　　　　法律や慣習なんかで、これが基本形
　と決まっているケースをメインとして記述していき、
　そこから、「こういう場合は」と派生して書いていきます。

　さらに、異常系は、正常系に対して、
　　　こんな入力の場合は・・・

　というふうに書いていきます。

---

■ソフトウェア開発上の意義

　正常系は、結局、目的を達しているケースなので、
　このケースが出来ない場合は、目的を達していない
　　＝開発失敗
　ということになります（当たり前品質）。

　一方、異常系は、正常形ができた上で（＝目的を達した上で）、
　正常でないケースに対応するということになるので、
　このケースが出来なくても、目的は達成する可能性があります。
　（魅力的品質）

　ということで、正常系が確実に動くことを、早く保証したいわけです。
　そうしないと、話がひっくり返ってしまうことがありますから。

　そこで、正常系と異常系をわけ、正常系に関して、より重視するという
意義が、あったり、なかったりです。