情報職業論覚え書き①

 ついに来た、11月のテストラッシュ。あさっていきなり図書館司書の試験が3発来るんだけど、それより恐ろしいのは、今月中旬にある情報の試験6連発。
 これは正直、持ち込み可だからなんとかなるだろと、なめていて、ほとんど準備してなかったんだけど(システム設計演習の課題を終わらせることだけに意識が向いてしまっていた)、昨夜、試験範囲が広すぎることが判明し、慌てて試験の対策にとりかかっております。
 基本的に、持ち込み不可の方が試験の内容は易しいようだ。考えてみれば当然かもしれないが。

情報科教育法II(危険度☆☆)
持ち込み不可。ただし5月に受けた情報科教育法Ⅰと試験形式は似ているので、多分いける。

システム設計演習(危険度☆☆)
持ち込み不可。この前こなしたばかりだけあって、まだ記憶が残っている。多分いける。

コンピュータネットワーク(危険度☆☆☆)
持ち込み可。ブログにかなりまとめたから、まだ多少は覚えてるんだけど、内容自体はかなり専門的で警戒せねばならない。
持ち込み用ノートの作成を急ぐ。

データベースシステム(危険度☆☆☆☆)
持ち込み可。やばい。SQL文忘れた。やばい。
試験範囲がテキストの全てじゃないのが救いか。ノート作成。

情報職業論(危険度☆☆☆☆)
持ち込み可。範囲がここまで広いことを昨夜知った。メチャ準備不足。
かなりやばい。ノート作成。

ディジタル画像概論(危険度☆☆☆☆☆)
持ち込み可。レポート瞬殺科目(フォトショップを使うだけ)。
しかし、試験内容がめちゃめちゃ専門的なことを昨夜知った。メチャ準備不足。
超ヤバイ。ノート作成。

参考文献:廣石良雄著『情報と職業』

コンピュータの歴史
かつては、コンピュータに使われる論理素子の集積度によって第1世代~第4世代に分類していたが、現在では、そういったハードウェアの側面ではなく、コンピュータをどのように利用しているかという利用形態の側面で論じられることが多い。

第1世代(1940年代~):真空管
第2世代(1950年代~):トランジスタ
第3世代(1960年代~):IC(集積回路)
第3.5世代(1970年代~):LSI(大規模集積回路)
第4世代(1980年代~):VLSI、ULSI(超大規模集積回路)


黎明期(1930年代~)
コンピュータの歴史は、チューリングマシンまでさかのぼる。
これは、もともとコンピュータを開発するために作られたのではなく、ゲーデルの不完全性定理(数学の不完全性)を証明するために作られたマシンである。
チューリングは、理論上どんな計算でも解ける完璧なマシンを作り、そのマシンが解けない計算を見つければ、数学の完全性は崩れ去ると考えた。数学に何か恨みでもあったのだろうか。
このマシンを開発するに当たって、チューリングは人間が実際にどのように計算を行っているか、その手順をルールにまとめている(数字を見る→演算の記号を確認→イコールの隣に答えを書く→終了、もしくは、答えが出なかったらやり直しなど)。これこそが後のプログラムである。

①真空管コンピュータ
真空管のパルス信号で表された数値を計算するコンピュータ。
特殊な電球に過ぎない真空管には寿命があるため、やがて同様の機能があり寿命がないトランジスタにお株を奪われることになる。
ちなみにそれまでは電磁石を使っていた。

ABC(1939~42年開発)
世界最初のコンピュータといわれる。
第二次大戦中に、アイオワ州立大学のアタナソフ教授(A)とその院生ベリー(B)が開発したコンピュータ(C)。
汎用性はなく、連立一次方程式を計算するのに特化したコンピュータ。
入力はパンチカード、制御は手動で、プログラム能力はなかった。
計算の仕方は二進法。

ENIAC(1943~46年開発)
1万8000本もの真空管を用いた、幅30メートル、重さ27トンという巨大なコンピュータで、プログラムは配電盤の変更や多数のスイッチで実現したため、プログラム変更は大変だった(例えば、足し算とかけ算でケーブルの接続のパターンが違った)。
これを克服する、プログラムとデータを同じ記憶装置に格納するプログラム内蔵方式は当時すでにアイディアはあったものの、戦時中だったために完成が優先され実装されなかった。
フォン・ノイマンが開発に関わったが、出来には納得がいっていなかったらしい。
その後、ノイマンは、プログラム(演算ルール)も数値化してデータのように扱ってしまえばいいという内容のチューリングの論文を読み、大きな影響を受けた。
ちなみにENIACの計算の仕方は十進法だった。

②ノイマン型コンピュータ
チューリングの論文の影響を受けたノイマンが提唱したプログラム内蔵方式のコンピュータ。49年にはEDSACとして完成。
ノイマン型コンピュータは現在のコンピュータでも主流となっている。その特徴は、プログラムとデータを、主記憶装置に一旦格納してから実行(プログラム内蔵方式)、プログラムに書かれた命令をひとつずつ実行(逐次制御方式)、0と1の計算によって実行(二進数処理)の3つである。

メインフレーム時代(1950年代~)
メインフレームとは複数の利用者が共有する中央計算機のこと。これに他の計算器を複数接続して、その力をみんなで共用していた。
ENIAC以来、計算機は大学や研究所が中心となって開発した。IBMなど民間のメーカーも生まれたが、処理形態がバッチ処理(一括処理)であり、利用者には時間や手続きの制約が多かった。
しかし、その後TSS方式が開発されたことで、利用者の利便性は向上、商用化が活性化された。
ちなみに、当時は日本のメーカーも通産省の誘導のもとメインフレームの開発競争に明け暮れていた。富士通、東芝、三菱などが戦い、80年代には富士通が日本IBMのマーケットシェアを抜いた。

①タイムシェアリング(TSS)形式
一つの処理機構において、二つ以上の処理過程の時間を細分化して交互に配置させるようにする、データ処理システムの方法のこと。
当時は、全ての機能を中央の大型コンピュータに置き、これを多くの利用者がシェアしていた。
しかし、バッチ処理では、利用者ごとのCPUの処理時間の割り当ては、運用者が周辺装置によって割り当てていた。
その処理時間を、利用者単位に自動的に分割することで(処理時間を利用者ごとにずらす)、複数の利用者が同時にコンピュータを利用できるようになった。
アイディア自体は57年頃、アメリカの計算器科学者のボブ・バーマーやジョン・マッカーシーが思いついた。
その後、59年にイギリスのコンピュータ科学者クリストファー・ストレイチーがTSSの特許を取得。

②マシンインタフェースの飛躍
人間とマシンが接触して相互に情報を交換する仕組みが向上する。
例えば、あのマウスがダグラス・エンゲルハートによって発明される。
また、彼はハイパーテキスト(文書の任意の場所に別の文書のリンクを埋め込める仕組み)や、グラフィカルユーザインタフェース(ユーザに対する情報の表示にグラフィックを多用し、大半の操作をマウスポインタで行うことができるインタフェースのこと)なども開発、コンピュータの使いやすさは飛躍的に上がった。

③ARPANET導入
アメリカ国防総省のARPAによって開発されたパケット交換方式のコンピュータネットワーク。
分散したUNIXコンピュータ同士をTCP/IPプロトコルで相互接続したもので、後のインターネットの原型になった。

④第三の波
1980年に出版されたアドルフ・トフラーの著書。農業革命、産業革命に続く第三の技術革命として情報化革命の到来を力説した。
彼の予言はかなり当たっていて、ネットショッピング、ネットオークション、ノマドワーカー、スマートコミュニティ(先端技術を用いて社会インフラを効率化・高度化した都市や地域)などは、その後現実のものとなった。

クライアント・サーバ時代(1980年代~)
80年代に入ると、パーソナルコンピュータやミニコンピュータが登場し、非常に高価なメインフレームに対して、低価格のコンピュータを企業が独自に持てるようになった。
これらの低価格コンピュータは個人や家庭にも普及し始めたが、まだIT技術者が趣味や業務として使う程度だった。
90年頃になると、コンピュータシステムのダウンサイジング、オープン化(標準化)によって、クライアント・サーバシステムが一般化していった。
このシステムにより、クライアント側からサーバにデータを要求し、得られたデータを使ってクライアント側でも処理ができるようになった。
そのため、クライアント側で分散して行われた処理やデータをどのように集約し、管理するかという問題が発生した。
さまざまな種類のコンピュータ資源をひとつのコンピュータとして利用できないかというアイディアは、後のクラウドコンピューティングにつながる。
サーバにはUNIX系コンピュータ、クライアントPCにはウィンドウズやマッキントッシュが使用されたが、年々画面表示の機能や各種の処理機能が向上し、メインフレーム時代の処理の集中から、処理の分散へ時代は移り変わっていった。

①ビル・ゲイツの登場
ビル・ゲイツは75年4月にポール・アレンとマイクロソフト社を設立し、その後、同社を世界的企業へと成長させた。
82年からマイクロソフト社がメーカーにOEM(相手企業に自社ブランドを製造させること)提供を開始したOSがMS-DOSであり、各社の各機種のPCに移植された。
さらに、85年にはWindowsを発表した。当時は独立したOSではなくグラフィカルインタフェースを実現するアプリケーションであったが、90年代後半以降は世界中のPCの大半に搭載されるようになった。
Windowsは、その後さまざまなシリーズが発表され、GUI機能、マルチタスク機能、ネットワーク機能などを企業だけでなく個人にも浸透させた。

②Macintosh発売
アップルが開発と販売を行っているPCで、84年1月に発売が開始された。
Windows搭載のPCとともに世界中の主流となっているが、特に使い勝手を重視した設計思想を持ち、デザイン、音楽、映像などの分野や、それを利用した教育分野に多く使用されている。

Webコンピューティング時代(1990年代~)

①www概念の提案
89年イギリスのコンピュータ技術者バーナーズ・リーがグローバル・ハイパーテキスト・プロジェクトを提案し、後にwwwの概念として知られる仕組みや環境を構築した。
94年リーは、アメリカのマサチューセッツ大学のコンピュータ科学研究所に移り、wwwの各種技術の標準化を推進するために、非営利団体のW3コンソーシアムを創設、HTML、URL、HTTPなどwwwの基礎となるプロトコルを規定した。

②Java言語の開発
95年にアメリカのサン・マイクロシステムズ社がC++をもとに開発したオブジェクト指向言語がJavaである。
もともとは90年に同社の若いプログラマ(パトリック・ノートン)がJavaに発展するプログラミング言語の素案を書いた。
JavaはJava仮想マシン(Javaのバイトコードをそのプラットフォーム固有の形式に変換して実行するソフトウェア)を実装した環境であれば、異なるハードウェアや異なるOSでプログラムを稼働できるため、インターネットで動作するウェブアプリケーションの言語にはうってつけであった。

③Mosaic発表
ネットワークに接続されるPCの数は膨大になり、クライアントPCにアプリケーションやデータを配布して、サーバ側で処理を行うという方法は事実上、不可能になった。
これを解消したのが、PC標準で装備されるようになっていたWebブラウザ(Webページを閲覧するためのアプリケーションソフト)である。
Mosaicは、93年にアメリカ国立スーパーコンピュータ応用研究所からリリースされたWebブラウザで、テキストと画像を同一のウインドウ内に自動的に編集し表示することができた最初のブラウザだった。

④Netscapeブラウザ
ネスケの愛称で親しまれたブラウザ。
90年代はWebブラウザといえば、このネットスケープ・ナビゲータであったが、マイクロソフト社のInternet Explorerや、ほかのブラウザにシェアを奪われ、2008年2月にサポートは終了した。
超懐かしい。

⑤Windows95発表
Windows3.1の後継として95年に発表されたOSである。
インターネットに必要な通信プロトコルのTCP/IPを選択することができた。
Win32と呼ばれるAPI(あるソフトウェアの機能や管理するデータなどを、外部のほかのプログラムから呼び出して利用するための手順やデータ形式を定めた規約のこと)搭載のほか、消費者向けOSとして充実した機能を持っていた。

⑥ハイパーテキスト対応大規模ウェブ検索エンジン
利用者が知りたい情報をWeb上で探し出すことは、いかにコンピュータやネットワークの性能が向上したとはいえ、大変である。
このような検索を簡単に行うのが検索エンジンである。
90年代後半、ヤフーが検索エンジン界では圧倒的強さを誇っていたが、それに対抗したのが98年に創立されたグーグルであり、98年発表の『ハイパーテキスト対応大規模ウェブ検索エンジンの分析』という論文の中で、グーグルの検索エンジンに対する考え方が説明されている。

クラウドコンピューティング時代(2000年代~)
Webコンピューティングの進展により、不特定複数の企業や個人がネットワークを通じてサービスを提供するビジネスモデルが確立されてきた。
アメリカ国立標準技術研究所(NIST)は、クラウドコンピューティングを「ネットワーク、サーバ、ストレージ、アプリケーション、サービスなどの構成可能なコンピューティングリソースの共用プールに対して、便利かつオンデマンドにアクセスでき、最小の管理労力またはサービスプロバイダ間の相互動作によって迅速に提供され利用できるという、モデルの1つ」と定義している。
クラウドは、コンピュータネットワークを空に浮かぶ雲に例えた言葉である。
雲のどこかに、ユーザが利用したい時、利用したい分だけの利用料金で、サーバマシンやシステム開発環境やアプリケーションなどを提供してくれるものがある、というイメージである。

①インターネットのプラットフォーム化
クラウドはインターネットでつながれた資源を、あたかもひとまとまりのコンピュータとして扱う。
インターネットをOSのようにプラットフォーム化し、クラウド市場を進展させた技術が2005年にその言葉が使われ出したAjaxである。
AjaxはWebブラウザに実装されているJavaScriptのHTTP通信機能を使って、Webページのリロードを伴わずに、サーバとXML形式のデータのやりとりを行って処理を進めていく対話型Webアプリケーションの実装形態である。
これによって、画面遷移を伴わない動的なWebプリケーションの制作が可能になった。

②Googleクラウドを提唱
2006年、グーグル社CEOエリック・シュミットが、自社のサービス群を「クラウドコンピューティング」と表現したことが、クラウドという言葉の誕生といわれる。

③各社クラウド事業参入
先駆的な会社は、グーグル、マイクロソフト、セールスフォース・ドットコム、ヤフー、アマゾン、イーベイなどである。

④2009自治体クラウド
総務省は、平成21年度から22年度にかけて「自治体クラウド開発実証事業」を実施した。
自治体クラウドとは、自庁内にハードウェアなどを設置せず、あらかじめ事業者が所有するデータセンタに設置されたハードウェアおよびソフトウェアなどから、インターネットや専用線などのネットワークを経由してサービスを利用することで、クラウドコンピューティング技術の進展や普及をふまえた情報システムの地方導入を行うことを指している。
複数の地方公共団体が一体となって、情報システムの共有化と集約化を進めることで、運用経費の削減を図ることが目的とされた。

システム設計演習覚え書き④

 とりあえず必修課題は全て終わりました・・・!\(^o^)/

 とはいえ、試験の加点対象になるオマケの課題がまだ9個あって、そのうち3個はできたんだけど、残り6個は仮想マシンで動かさなきゃいけないやつで、この仮想マシンが私の家のネット環境だとオーバーテクノロジーで、まあ、止まる止まる。ぷーあらあら(どせいさん)。みたいな。
 で、調べてみたら、オマケを3問やってたった1点の加点ということで、まあ、諦めて(え)、今日の午後は、来月中旬のテスト勉強をしてました。
 でも、まあ、残りの6問も気持ちが悪いから、今度気が向いたらネットカフェとかに行ってやってみるかもしれない。

 それでは、今までのシステム設計の一ヶ月ちょいの軌跡を振り返ってみましょう。

クラスとインスタンス
クラス図とインスタンス図はデザインがそっくりなので、インスタンスの名前の部分には必ず下線をつけて区別する!
課題2-2ー2.jpg

継承
どちらが一般的で、どちらが特殊かを考える。
例えば、正方形は特殊な長方形なので、包含記号を使うと「長方形⊃正方形」となる。論理記号の矢印のデザインは⇒で、クラス図の矢印はチビ太のおでんのようなデザインなのに注意。
課題2-4.jpg

ポリモーフィズム
同じ呼び方(メッセージ)の操作で異なる動作をさせること。
例えば、一から作るのではなく、既存のシステムの操作をすこし修正=上書き(オーバーライド)すれば事足りそうな場合など。

抽象クラス
抽象クラスには実態がないため、例えば「図形」という抽象クラスがあった場合、その具体例であるインスタンスは作れない。
これが、「長方形」や「楕円」などの具体的な図形のクラスではいろいろなインスタンス(いろいろな形の長方形や楕円)が作れる。
課題6-2発展4.jpg

関連
多重度が重要。アスタリスクのマークは任意の数。
頻出する関連パターンは「モノ」-「コト」ー「コト」で、多重度は「1対*」「*対1」が多い。

特にこの問題が危険。
生徒にとっては、受講できる科目は最大10科目なので、0..10となる。
講義科目にとっては、受講する生徒の数は最大20人なので0..20となる。
課題3-4.jpg

依存
依存を示す矢印は点線で、さきっちょは^で、黒い三角形▲ではないのに注意。
依存するクラスは変更できるが、依存される側を変えると、そいつに依存している奴にも影響が及ぶ。
課題3-7.jpg

コンポジション関連
販売伝票の情報から、明細というクラスを作りデータを分ける。
販売伝票に共通するデータは「日時」「支店名」「合計金額」なので、これらは販売伝票のクラスに残す。
それ以外の何を何個買ったかのデータ「商品名」「単価」「数量」「金額」は、明細のクラスに送る。
課題3-8.jpg

実装
依存はさきっちょが^の点線の矢印だったが、実装はさきっちょが△の点線の矢印。
そういや、実習課題で実装の矢印ってあんまり使わなかった気がする。
課題3-9.jpg

パッケージ図
関連性の高いデータや操作は一つのパッケージに入れてしまう。
例えば、「マグロ」「カンパチ」「ヒラメ」などのデータは「寿司ネタ」というパッケージに入れるとわかりやすい。
また、パッケージ内のデータは可視性の設定によって、表示・非表示が可能。非表示設定にすると、そのデータは他のパッケージから見えなくなる。
表示は+のマーク、非表示は~なので注意。
課題4-1.jpg

シーケンス図
課題を進めるにつれ最終的にすごい複雑になった奴。
例えばこれ。
課題12ー4ー2.jpg
ちなみに、シーケンス図の作成には、まずクラス図(設計図)を作成しなければならない。
また、あるクラスの処理は、そのクラスを指すメッセージの矢印によって行われるのに注意(逆に言うとメッセージの矢印に書かれている操作内容は、矢印が刺さっているクラスが持っている!)。
さらに、同期メッセージの矢印の先っちょは▲、非同期メッセージの矢印の先っちょは^なのも注意する(これを混同すると実行仕様=活性区間を示す縦長の四角形が連動して勝手に大きくなっちゃう)。

要件定義
要件定義は、顧客と開発者の共同作業で考える。
まず現状を分析し、顧客からシステム要求を聞き、それを元に開発者が分析結果(要件定義書)を提示して、共通理解を図る。
顧客は、依頼者やエンドユーザのことで、これがステークホルダーになると、もう少し広く、開発側も含まれる。
要件定義のうち、必ず搭載すべき機能は機能要件と呼ばれるが、反応速度といったユーザビリティや、故障しにくいといった信頼性、セキュリティなど、顧客の要件にはない機能(性能)である非機能要件が昨今取りざたされている。これは要件定義書に明記されてはいないため、限られた時間と資金の中、顧客の気持ちをどれだけ忖度できるかが、顧客の満足度を高めるという。

ユースケース図
ユーザの要求に、どのようにシステムが対応するかを示す図のこと。
従って、まずアクターを抽出しなければならない。
例えば、コンビニのレジシステムの場合、それを扱うアクターはレジ係と店長(店長もレジは使えるから)であり、お客さんではない。

以下は、学生が図書館で本を借りる際のユースケース図。
なお、「氏名と本のタイトルを確認する」の手順のように、「本を借りる」ときにも「本を返す」ときにも行われるようなものは、〈〈include〉〉の矢印で指し示す。
課題8-1.jpg

ER図
マイクル・クライトン先生の緊急救命室ではない。
エンティティ・リレーションシップ・ダイアグラムの略。
エンティティとは実体とか概念のことで、複数の対象物を共通のカテゴリーでまとめた四角形と考えて良い。
これはUMLでいうクラスに相当するため、クラス図をER図に変換することができる。
課題10-4.jpg

クラス図との違いは、クラス名(エンティティ名)が四角形の外に追いやられ、1段目のマスにはRDBSのように主キーが入ること。
さらに、「学生」や「本」のように一意(ユニーク)に求められるものは親エンティティ、「貸出」のように様々なパターンがあるものは子エンティティと呼ばれる。

これら親子をつなぐ多重度のマークも覚えなければならない。
鳥の足(クロウズ・フット)のマークは複数という意味。
|は1つ、○は0つ、エンティティにつながっているという意味。
ちなみに|と○を合体させると0か1という意味。
また、子エンティティが親エンティティに依存している場合、子エンティティの四角形の角は丸くなる。
課題10-4.jpg

システム設計演習覚え書き③

 最近気が向いて順調に攻略中のシステム設計。残る必修課題は12個。なんとか今月中にいけそうだ!やれば出来る子!!

参考文献:内山俊郎著『わかりやすい情報システムの設計――UML/Javaを用いた演習』

開発プロセス
情報システムの開発プロセスには、大きく二つの方法がある。
順番に手順を完了させるウォーターフォール型と、部分的なリリースを繰り返して完成度を上げていく反復型である。
この二大派閥は、どちらが優れていて、どちらが劣っていると、決めつけることはできず、また、仮に反復型が優れていたとしても、明日から反復型にします!と簡単に切り替えられない現実的な問題もある。

ウォーターフォール型
要件定義→設計→実装と、滝が流れるように順次処理をする。
滝の水が逆流しないように、プロセスは後戻りしない。
そのため、事前に綿密な計画(いつまでに何を作るか、コストの見積はいくらか)を立てる。基本的に手順のルールがしっかりと決まっている。
開発期間は数ヶ月~数年で、もちろん最終目標(スコープ=何を作るか)は変わらない。

メリット
生産性が高い。要件定義を終えれば設計を一気に進められる(中断が少ない)。
全体的な予算見積もりが早期に出る。

デメリット
対応力が低い。プロセスの初期で要件定義を終えているので、その後変更が必要になっても路線変更が難しい。実際は手順を戻ることになるが、それもできずに手遅れになることもある。
工程によってメンバーが替わるため(バトンタッチする)、引き継ぎ業務(ドキュメント作成など)が必要。

反復(イテレーション)型
非ウォーターフォール型とも呼ばれる。
システムを機能面などで小分けにし、それぞれに開発期間(1~4週間ほどの短いもの)を設ける。つまり、各開発期間で分割されたシステムの開発(全アクティビティの実行)を行う。
全体の計画は概略的。開発規模の見積もりが固まり出すのは、プロジェクト期間の10~20%が終わるくらい。つまり、定額契約が難しい。
ルールよりもエンジニアの経験がものをいうため、開発の進め方は彼らの経験とともに変わり、常に向上していく。
2000年頃普及しだしたイメージがあるが、古くには、50年代のX15極超音速ジェット機の開発、60年代のNASAにおけるマーキュリー計画、72年のトライデント潜水艦命令制御システムの開発、77~80年のスペースシャトルの第1航空電子ソフトウェアシステムの開発などの例がある。
その後、アメリカ国防省はウォーターフォール型の開発を推奨したが、失敗事例(先端技術開発では開発要求がリアルタイムで進化していってしまうため)を見て、87年の勧告では早くも反復型の推奨に戻している。

メリット
対応力が高い。いつでも軌道修正が可能。
例えば、ある機能をせっかく開発したのに結局使わなかったというような開発の無駄をなくせる。
システムを小単位ごとに分割するため開発期間が短縮できる。
工程が変わってもメンバーが替わらないため引き継ぎが不要で、また前行程での経験がチームのノウハウとして蓄積していく。

デメリット
生産性が低い(作業を途中で中断することが容易なため)。
全体的な予算の見積もりが不明確な状態でスタートするため、請負型契約(完成した仕事に報酬を支払う契約)が困難。同様に、企業の規模が大きいと予算管理部門が反復開発を採用しない。

アジャイル開発
アジャイルとは俊敏という意味(・・・もしかしてアジャコングって俊敏なゴリラっていう意味!?)。
アジャイルソフトウェア開発宣言(01年にユタ州に集まった17人のプログラマーやエンジニアが行なった宣言)と、全12項目のアジャイル原則を指針とする、反復型開発プロセスである。

アジャイル宣言
プロセスやツールよりも・・・個人と相互作用
包括的なドキュメントよりも・・・動くソフトウェア
契約交渉よりも・・・顧客との協調
計画に従うよりも・・・変化に対応すること

これは、左側の言い分にも価値はあるが、それよりも右側を重視するということである。
「個人と相互作用」からは、まず開発者が満足することが持続可能な開発において必要であることが、「顧客との協調」「変化に対応すること」からは、顧客やエンドユーザからのフィードバックを受け入れることや、コミュニケーションを重視している(スクラム開発)ことがわかる。
また、アジャイル開発には上手くいく方法の中で最もシンプルなものを選べという考え方も盛り込まれている。

スクラム(Scrum)
人命に関わるシステムの設計にも用いられているアジャイル開発の中で最も有名な手法。
ラグビーのスクラムのように、開発チームのメンバー(なぜかブタと呼ばれる)同士がコミュニケーションをよく取り合い、足並みをそろえて開発を行なう。

例えば、毎朝立ちながら20分程度のミーティング(スクラムミーティング)をするなど、反復ごとに自分たちで立案した計画を自分たちで精査する。
そのため、チームの人数は3~10人くらいに抑える(人数が多いとコミュニケーションが難しくなり、チームとしての一体感も希薄化するため)。

ちなみに、反復の途中ではメンバー以外の利害関係者が作業を追加してはならない。つまり、部外者(なぜかニワトリと呼ばれる)は口をはさまない。チームの自律性を重んじるのである。

スクラムミーティングの内容としては以下のものがある。
①前回のスクラム以降何を行ったか?
②今から次のスクラムまでに何を行うか?
③反復の目的を達成する上での障害は何か?
④スプリントバックログ(チームが当たるタスクの待ち行列のこと)に追加するタスクはあるか?
⑤チームメンバーから刺激を得て、何か新しく学んだことはあったか?

エクストリーム・プログラミング(XP)
小規模プロジェクトを素早く成功させることに特化した方法(反復期間は1~2週間)。
開発途中の仕様変更や設定変更にも勇気をもって柔軟に対応する。
プログラマー中心主義と言ってもよく、バディムービーのようにタッグを組んでプログラミングをするペアプログラミングなど面白い考え方がある。
XPが独特な点は、プログラムコードとテスト以外には成果物を要求しない点である。
他のアジャイル開発では、目前の反復の計画くらいは立てるが、XPではドキュメント作成を極力減らすため、そういったものすら作らない(ただし、ホワイトボードにタスクリストくらいは書く)。

システム設計演習覚え書き②

 今月中に全ての課題をこなせるのか、いよいよ厳しくなってきました。C言語よりも必修課題の数が膨大なんだよな。唯一の救いは、講義の先生が優しくて手順を丁寧に教えてくれるところだね。
 でも、javaでプログラミングする第5講あたりから、まずもってjavaがやれる環境を準備するのが大変で、ソフトウェアとか3つくらい必要だし、そこでかなり労力を使っちまったよ。

シーケンス図
あるシステムの処理において、それぞれのオブジェクトがどのように協調・影響し合うかを、時間軸に沿って説明する図。
各オブジェクトの関係はコミュニケーション図という図でも表せるが、その場合時間経過は表現できない。
課題4-2シーケンス図.jpg

ステートマシン図
図書館にある本の状態(書架にある・貸し出し中)など、システムの振る舞いを記述するための図。開始状態を黒い丸、状態は角が丸い枠で表す。
課題4-3.jpg

アクティビティ図
動的な処理の流れを表現できる図で、フローチャートに似ている。
条件判断や並列処理を表現する際に用いられる。
処理全体の流れをおおまかに表現したい場合はアクティビティ図、もう少し個々の相互作用のディティールも表現したい場合はシーケンス図など、使い分けが大切らしい。

各ノードは次のとおり。
開始ノード:黒い丸。システムの開始を表す。
ディシジョンノード:菱形。分岐点を表す。
マージノード:菱形。集合点を表す。
フォークノード:太い横線。並列処理の開始を表す。
ジョインノード:太い横線。並列処理の終了を表す。
終了ノード:黒い二重丸。システムの終了を表す。

また、「顧客」「店員」「店長」のように、アクションをする人や組織ごとに、アクションのグループ分けをすることができる(アクティビティ・パーティション)。
課題4-5.jpg

javaプログラミング演習
事前にJDK(ジャヴァ・デベロップメント・キット)というソフトウェアをダウンロードしたあと、システムのプロパティのコーナーにある「環境変数の設定」の「path」にJDKがダウンロードされた所在地のアドレス(ただしセミコロン;とbinで挟む!!)を追加する。
さらにjEditというソフトウェアもダウンロードするのだが、拡張子がマックでしか通用しないタイプ(.dmg)で、開くのに結構手間がかかる(´;ω;`)
この準備が終わったら、どこでもいいので、ある任意のフォルダを作って、そのフォルダに課題のソースコードのファイルをぶち込む。
次に課題が入ったファイルをマウスポインタで選択したあと、シフトキーを押しながら右クリックをすると、コマンドウィンドウをここで開くという、通常出てこない選択肢が出てくる。
これを選ぶと、選択したフォルダ(ディレクトリ)のコマンド入力画面が出てくるので、ここで、jEdit ソースコード名 と半角で入力する。これで、ウィンドウズのソースコード入力ツールであるjEditの入力画面に飛んでくれる。
ちなみに、OSがリナックスだとgeditという別のエディタになる。

メソッド
javaの世界では操作はメソッドと呼ばれる。"main"というメソッドだけは、コマンドウィンドウから起動および実行できる。

astah* professionalとの関連
すごい便利なのが、クラス図などの描画ソフト「アスタープロフェッショナル」でjavaのソースコードが読み込めるという点。javaのコードをそのまま図に変換してくれる。
手順は、「ツール」→「java」→「javaソースコードの読み込み」→好きなファイルを選択→図にしたいデータを候補リストから選択リストに移す→「了解」

課題5-3.jpg

上のソースコードをこんな感じで自動的に描画してくれる。素敵。
課題5-3クラス図.jpg

リバースエンジニアリング
設計書からプログラムを作ることをフォワードエンジニアリングというが、それの逆。
つまりプログラムから設計書を作ること。

javaで作図をする
懐かしのプログラミング基礎が思い出されずにはいられない課題。
特に、楕円とか二等辺三角形の数式が激ムズ。
ただ思ったのは、C言語って汎用性が高いなというか、文法はほとんどCもjavaも変わらないのねっていう。

図形の設定コード(Figure)
abstract class Figure{
final double PAratio = 0.45; // 画素のアスペクト比
final String Pixel = "@"; // 図形は@の集合として描けという意味
abstract void draw();
abstract String getNote();
void draw_w_Note(){
draw(); // ←描画は文章の前に描き出させる
System.out.println("上記の図形は,"+getNote());
}
}

直角三角形の作図コード(TyokkakuTriangle)
class TyokkakuTriangle extends Figure{
private double width; // 直角三角形の幅
private double height; // 直角三角形の高さ
TyokkakuTriangle( double width, double height ){
this.width = width;
this.height = height;
}
void draw() {
for( double i = 0 ; i < height ; i++ ){
for( double j = 0 ; j < width/PAratio ; j++ ){
double x = (j + 0.5)*PAratio;
double y = height - 0.5 - i;
double equation = y + height/width*x - height;
if( equation <=0 ) System.out.print(Pixel);
else System.out.print(' ');

}
System.out.println();
}
}
String getNote(){
return "底辺、高さが(" + this.width + ", " + this.height+ ")の直角三角形"; }
}

二等辺三角形の作図コード(NitouhennTriangle)
class NitouhennTriangle extends Figure{
private double width; // 二等辺三角形の幅
private double height; // 二等辺三角形の高さ
NitouhennTriangle( double width, double height ){
this.width = width;
this.height = height;
}
void draw() {
for( double i = 0 ; i < height ; i++ ){
for( double j = 0 ; j < width/PAratio ;j++ ){
double x = (j + 0.5) * PAratio;
double y = height - 0.5 - i;
double equation1 = y + 2.0*height/width*x - 2.0*height;
double equation2 = y - 2.0*height/width*x;
if( equation1 <=0 && equation2 <=0 ) System.out.print(Pixel);
else System.out.print(' ');

}
System.out.println();
}
}
String getNote(){
return "底辺、高さが(" + this.width + ", " + this.height+ ")の二等辺三角形"; }
}

図形の呼び出しコード(FigureTester)
このソースをコマンドプロンプトでコンパイルすると全部引っ張り出される。
ちなみに、コンパイルの仕方は「javac FigureTester.java」→「java FigureTester」でOK。

class FigureTester{
public static void main(String[] args){
TyokkakuTriangle myTyokkakuTriangle = new TyokkakuTriangle(5,10);
myTyokkakuTriangle.draw_w_Note();
NitouhennTriangle myNitouhennTriangle = new NitouhennTriangle(19,15);
myNitouhennTriangle.draw_w_Note();
}
}

コンパイル例
課題6-2発展3.jpg

リバースエンジニアリング
課題6-2発展4.jpg

ヒトラーを欺いた黄色い星

 「面白い度☆☆☆ 好き度☆☆☆」

 ユダヤ人を嫌うことと、ユダヤ人をガス室で殺すことは違う。

 vicさんお勧め映画。
 ナチス政権下では、ドイツに住むユダヤ人は全員ゲシュタポに捕まって強制収容所送りになったイメージがあるけど、ベルリンとかに終戦までけっこう潜伏してたよっていう話。
 実際にベルリンに潜伏した四人のユダヤ人の証言がついていて、わりとドキュメンタリー映画だった。NHKスペシャル的な。
 当たり前だけど全てのドイツ人がユダヤ人を迫害したわけではない。市井の人々だけではなく、なんと高級官僚や、ドイツ軍の将校ですらユダヤ人を匿ってくれた人がたくさんいた、と。
 ドイツ人将校のお屋敷なんかパーティであんなに軍人がいるのに、そこで働く家政婦がユダヤ人だと気づかない!
 ドイツの軍人「黒い瞳だな、ユダヤ人かね?」ユダヤ人家政婦「ユダヤ人は絶滅したのでは?」一同爆笑「わっはっは!」おしまい(^_^;)わからねーのかっていうw
 実際、民族的とか人種的なレベルではユダヤ人ってのはいなくて、ユダヤ教信者=ユダヤ人なわけだろう。
 これは本当に、オタク狩りみたいなもんで、例えば、仮に第二次世界大戦でユダヤ人を物理的に根絶したとしても、その後、再びユダヤ教が評価されて、信者さんがついちゃったら、ユダヤ人は復活するってことになるわけだから、どだい無理がある計画ではあるんだよな。だからさ、もうどう考えても、当時の八つ当たりなわけで。
 でもさ、こういう、ユダヤ人を救ってくれたドイツ人がいたよっていう事実をユダヤの人たちの方から証言してくれるのは本当にありがたいよね。おのれドイツ人!みたいに憎悪だけになっちゃうと、こうはいかないし、そいで、ドイツ人の方から、ユダヤ人匿ったドイツ人だっていたんだぞ感謝しろ、みたいに言うのも、ちょっとまずいじゃない。

 そういえば、こういうユダヤ人迫害映画の邦題ってだいたい『ヒトラーのうんちゃら』って付けられることが多いけど、ヒトラーをかばうわけじゃないけどさ、これってちょっとどうなんだろうというか、すべてのドイツ人がユダヤ人を迫害したわけじゃないのと同様に、すべてのドイツ人がユダヤ人迫害に反対したわけじゃないわけであってさ。
 それをさもいい感じにヒトラーを悪のシンボルにしてスケープゴートというか、ナチスドイツの所業をこの人に全部押し付けちゃえ的なことにしちゃうと、また同じことが起きるぞというか、まあ、実際に起きつつあってさ、そういう懸念はあるよ。
 だから『ヒトラーの忘れもの』も、『ドイツの忘れもの』だとちょっと衝撃的すぎるなら、『ナチスの忘れもの』くらいでよかったんじゃないかとかね。
 というか、『ヒトラーの忘れもの』も『ヒトラーを欺いた黄色い星』も、原題はヒトラーってついてないしな。
 つまりヒトラーに全部押し付けちゃえっていうのは、日本の配給会社の思惑なのかもね。ドラえもんの映画じゃないんだからさって思うよな。『ヒトラーの大魔境』とか。『ヒトラーの鉄人兵団』とか。
 多分さ、今後こういう悪のシンボルにされそうなのが、トランプさんなんだろうけど、これもさ、トランプさんに投票したアメリカ人はたくさんいるわけでさ。
 内心(やべえ、投票する奴間違えた!)って思っても、まあいいや、全部トランプに騙されたってことにしようとかやってる限り、同じ過ちを繰り返すよね。
Calendar
<< January 2020 >>
SunMonTueWedThuFriSat
   1234
567891011
12131415161718
19202122232425
262728293031
search this site.
tags
archives
recent comment
recent trackback
others
にほんブログ村 科学ブログへ にほんブログ村 科学ブログ 恐竜へ カウンター
admin
  • 管理者ページ
  • 記事を書く
  • ログアウト

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267