ホーム » スタッフ (ページ 120)

スタッフ」カテゴリーアーカイブ

2025年6月
1234567
891011121314
15161718192021
22232425262728
2930  

検索・リンク

歯みがきロボコン親子工作教室

恒例の、10/4(日)に予定されている、歯みがきロボコンのための親子工作教室が8/8に開催されました。

1508150715_640x640.JPG

2015年8月9日(第435回)

収録でお送りしました。

  • ジャズバー歴史 8杯目「『賭ける』ということ」
  • 歌える翻訳コンテストについて
  • 夏休みの話

担当:松島(4C、MIX)、田中(2B、MC)、水島(1C)、鷲田(1EI)、西(教員)

2015年8月2日(第434回)

  • ジャズバー歴史 7杯目「家族のあり方」
  • 期末試験の話
  • 夏休みの予定

担当:松島(4C、MIX)、田中(2B、MC)、川﨑(2EI)、水島(1C)、西(教員)

メール送信取り消し機能なのか?

学科に求人募集の企業さんから、2通のメールが届きました。

(1通目)
> Subject: 【株式会社×××】採用選考会のご案内
> 進路担当様 各位 ....
>  [以下略]
(2通目)
> Subject: 取り消し: 【株式会社×××】採用選考会のご案内
> ◯◯◯◯はメッセージ - "【株式会社×××】採用選考会のご案内"
> を取り消します。

たぶん、求人募集のメールを送信間違いで送って、取り消したんでしょうが、 最近Gmailなどで実装された「一定時間以内ならメールの取り消し」と 同様の機能を使ったのだろうと思います。

だけど、一定時間に間に合わないと、2通目のような極めてぶっきらぼうな メールが相手先に飛んでしまうんでしょうか?

これじゃ、2通目で相手に極めて失礼な印象を持たれて、 ビジネス的には思いっきりマイナスじゃないでしょうか….

送信取り消し機能が、「スンドメール」とかで出てきた頃から、 「身近な送信サーバが実際の送信まで遅延させる」んだから、 遅配の原因にもなるし、あんまり使えないと思っていたけど、 このメール見ると「使っちゃいけない機能」に思えてくる。

2015年7月26日(第433回)

学生さんがテスト期間中につき、教員による収録でお送りしました。

  • 新任教員紹介 電子情報工学科 小越先生
  • ジャズバー歴史 6杯目「国民意識」
  • 最近の福井高専とその周辺

ゲスト:電子情報工学科 小越先生

担当:中村(国語科教員、MC)、川上(電子情報工学科教員)、伊勢(国語科教員)、西(電子情報工学科教員、MIX)

オブジェクト指向プログラミング2015全講義録

オブジェクト指向プログラミングまとめ

2015年度のオブジェクト指向プログラミングの講義録を以下にまとめる。

レポート課題は以下のとおり

  • 隠蔽化に関するレポート(複素数クラスの直交座標系・極座標系での実装)
  • 仮想関数に関するレポート(図形クラスに機能を追加し色付き図形に拡張)
  • UMLに関するレポート(自分の特別研究の内容より2つのUML図を記述)

オブジェクト指向とソフトウェア工学

オブジェクト指向プログラミングの最後の総括として、 ソフトウェア工学との説明を行う。

トップダウン設計とウォーターフォール型開発

ソフトウェア工学でプログラムの開発において、一般的なサイクルとしては、 専攻科などではどこでも出てくるPDCAサイクル(Plan,Do,Check,Action)が行われる。 この時、プログラム開発の流れとして、大企業でのプログラム開発では一般的に、 トップダウン設計とウォーターフォール型開発が行われる。

トップダウン設計では、全体の設計(Plan)を受け、プログラムのコーディング(Do)を行い、 動作検証(Check)をうけ、最終的に利用者に納品し使ってもらう(Action)…の中で、 開発が行われる。設計の中身も機能仕様や動作仕様…といった細かなフェーズになることも多い。 この場合、コーディングの際に設計の不備が見つかり設計のやり直しが発生すれば、 全行程の遅延となることから、前段階では完璧な動作が必要となる。 このような、上位設計から下流工程にむけ設計を行う方式は、 トップダウン設計などと呼ばれる。また、処理は前段階へのフィードバック無しで次工程へ流れ、 川の流れが下流に向かう状態にたとえ、ウォーターフォールモデルと呼ばれる。

引用:Think IT 第2回開発プロセスモデル

このウォーターフォールモデルに沿った開発では、横軸時間、縦軸工程とした ガントチャートなどを描きながら進捗管理が行われる。

一方、チェック工程(テスト工程)では、 要件定義を満たしているかチェックしたり、設計を満たすかといったチェックが存在し、 テストの前工程にそれぞれ対応したチェックが存在する。 その各工程に対応したテストを経て最終製品となる様は、V字モデルと呼ばれる。

引用:@IT Eclipseテストツール活用の基礎知識

しかし、ウォーターフォールモデルでは、前段階の設計の不備があっても前工程に戻るという考えをとらないため、全体のPDCAサイクルが終わって次のPDCAサイクルまで問題が残ってしまう。 巨大プロジェクトで大量の人が動いているだから、簡単に方針が揺らいでもトラブルの元にしか ならないことから、こういった手法は大人数巨大プロジェクトでのやり方。

ボトムアップ設計とアジャイル開発

少人数でプログラムを作っている時(あるいはプロトタイプ的な開発)には、 部品となる部分を完成させ、それを組合せて全体像を組み上げる手法もとられる。 この方法は、ボトムアップ設計と呼ばれる。

また、ウォーターフォールモデルでは、前工程の不備をタイムリーに見直すことができないが、 少人数開発では適宜前工程の見直しが可能となる。 特にオブジェクト指向プログラミングを実践して隠蔽化が正しく行われていれば、 ライブラリの利用者への影響を最小にしながら、ライブラリの内部設計の見直しも可能となる。 このような内部構造の改善はリファクタリングと呼ばれる。

一方、プログラム開発で、ある程度の規模のプログラムを作る際、最終目標の全機能を実装したものを 目標に作っていると、全体像が見えずプログラマーの達成感も得られないことから、 機能の一部分だけ完成させ、次々と機能を実装し完成に近づける方式もとられる。 この方式では、機能の一部分の実装までが1つのPDCAサイクルとみなされ、 このPDCAサイクルを何度も回して完成形に近づける方式とも言える。 このような開発方式は、アジャイル開発と呼ぶ。 一つのPDCAサイクルは、アジャイル開発では反復(イテレーション)と呼ばれ、 短い開発単位を繰り返し製品を作っていく。この方法では、一度の反復後の実装を顧客に見てもらい、 顧客とプログラマーが一体となって開発が行われる。

引用:コベルコシステム

エクストリームプログラミング

アジャイル開発を行うためのプログラミングスタイルとして、 エクストリームプログラミング(Xp)という考え方も提唱されている。 Xpでは、5つの価値(コミュニケーション,シンプル,フィードバック,勇気,尊重)を基本とし、 開発のためのプラクティス(習慣,実践)として、 テスト駆動開発(コーディングではテストのためのプログラムも並行して行い,こまめにテストを実行する)や、 ペアプログラミング(2人ペアで開発し、コーディングを行う人とそのチェックを行う人で役割分担をし、 一定期間毎にその役割を交代する)などの方式が取られることが多い。

2015年7月19日(第432回)

学生さんがテスト期間中につき、教員による収録でお送りしました。

  • 新任教員紹介 電気電子工学科 堀川先生
  • ジャズバー歴史 5杯目「近代化普及装置(2)」
  • 福井高専のニュース

ゲスト:電気電子工学科 堀川先生

担当:中村(国語科教員、MC)、原口(英語科教員)、伊勢(国語科教員)、西(電子情報工学科教員、MIX)

UML振る舞い図

参考資料図をもとに振る舞い図の説明を行う。

ユースケース図

1507131131_211x192.png

ユーザなど外部からの要求に対する、システムの振る舞いを表現するための図。 システムを構築する際に、最初に記述するUMLであり、システムに対する処理要件の全体像を理解するために記述する。 ユーザや外部のシステムは、アクターとよび人形の絵で示す。楕円でシステムに対する具体的な処理をユースケースとして記述する。 関連する複数のユースケースをまとめて、サブジェクトとして示す場合もある。

アクティビティ図

初期状態から、終了状態までの手順を示すための図。 複数の処理を並行処理する場合には、フォークノードで複数の処理を併記し、最終的に1つの処理になる部分をマージノードで示す。 通常の処理は、角丸の長方形で示し、条件分岐はひし形で示す。

ステートチャート図(状態遷移図)

ステートチャート図は、処理内部での状態遷移を示すための図。 1つの状態を長丸長方形で示し、初期状態から終了状態までを結ぶ。 1つの状態から、なんらかの状態で他の状態に遷移する場合は、分岐条件となる入力とその際に出力する内容を「入力/出力」で矢印に併記する。 複数の状態をグループ化して表す場合もある。

シーケンス図

複数のオブジェクトが相互にやり取りをしながら処理が進むようなものを記述するためのものがシーケンス図。 上部の長方形にクラス/オブジェクトを示し、その下に時系列の処理の流れの線(Life Line)を描く。 オブジェクトがアクティブな状態は、縦長の長方形で示し、そのLife Line間を、やり取り(メッセージ)の線で相互に結ぶ。 メッセージは、相手側からの返答を待つような同期メッセージは、黒塗り三角矢印で示す。 返答を待たない非同期メッセージは矢印で示し、返答は破線で示す。

システム

最新の投稿(電子情報)

アーカイブ

カテゴリー