ページ 84 – 電子情報工学科

2025年6月
日	月	火	水	木	金	土
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

情報制御基礎2018全講義録

2018年7月13日

注意：2018/07/30(Mon)前期期末テスト・情報制御基礎は、A4✕1枚の手書き資料のみ、持ち込み可とする。

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

2018年7月13日

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

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

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

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

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

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

引用：Wikipedia ガントチャート

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

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

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

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

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

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

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

引用：コベルコシステム

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

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

リーン開発は、品質の良いものを作る中で無駄の排除を目的とし、本当にその機能は必要かを疑いながら、優先順位をつけ実装し、その実装が使われているのか・有効に機能しているのかを評価ながら開発をすすめる。

伽藍とバザール

これは、通常のソフトウェア開発の理論とは異なるが、重要な開発手法の概念なので「伽藍とバザール」を紹介する。

伽藍とは、優美な寺院のことであり、その設計・開発は、優れた設計・優れた技術者により作られた完璧な実装を意味している。バザールは有象無象の人の集まりの中で作られていくものを意味している。

たとえば、伽藍方式の代表格である Microsoft の製品は、優秀なプロダクトだろうが、中身の設計情報などを普通の人は見ることはできない。これに対しバザール方式の代表格の Linux は、インターネット上にソースコードが公開され、誰もがソースコードに触れプログラムを改良してもいい。その中で、新しい便利な機能を追加しインターネットに公開されれば、良いコードは生き残り、悪いコードは淘汰されていく。

バザール方式は、オープンソースライセンスにより成り立っていて、このライセンスが適用されていれば、改良した機能はインターネットに公開する義務を引き継ぐ。このライセンスの代表格が、GNU パブリックライセンス(GPL)であり、公開の義務の範囲により、BSD ライセンス、Apacheライセンスといった違いがある。

制御工学とまとめ

2018年7月13日

情報制御基礎の授業を通して、入力値を制御するため、コンピュータを使う場合の数値処理の基礎的な話として、信号の平滑化や差分について説明をしてきた。実際には、入力値を制御に利用する場合には、数学的バックグラウンドも必要となる。

制御工学の概要

以下に、制御工学ではどのようなことを行うのか、概要を述べる。
ここで紹介する制御理論は、古典制御理論と呼ばれる。

制御工学では、入力値 $x(t)$ と、何らかの処理を施し出力値 $y(t)$ が得られるシステムで、どのように制御するかを考える。

例えば、電気ポットの温度制御をする場合、設定温度の値を入力値(x)とし、何らかの処理を行い、出力となるヒーターの電流を制御し、最終的には温度(y)が測定される。ヒーターは、設定温度(x)と温度計の値(y)の差に応じて電流量を変化させる。このように一般的な制御では、最終的な温度が入力に戻っている。このように目標値に近づけるために、目標値との差をとって制御することをフィードバック制御という。

入力と出力で制御された波形の例を示す。

この波形では、黒のように入力値が変化した場合、それに追いつこうと出力が変化する。(1)理想的には、速やかに追いつく赤のように変化したい。しかし、(2)変化への制動が大きい過制動(青点線)では、目標値に追いつくまでに時間がかかる。(3)一方ずれに対して制御が激しいと目標値を追い越したり、増えすぎ分を減らしすぎたり変動する過制御(赤点線)となる。

PID制御

目標値 $x(t)$ 、出力 $y(t)$ 、ずれ(偏差) $e(t)$ 、制御量 $u(t)$ とした時、基本的なフィードバック制御として偏差の使い方によってP動作,I動作,D動作がある。参考 Wikipedia PID制御

比例制御(P制御)

$u(t) = K_p\times e(t) = K_p ( x(t) - y(t) )$

偏差に比例した制御(K_pは比例ゲイン)

積分制御(I制御)

$u(t) = K_i \int e(t) = K_i \int ( x(t) - y(t) ) dt$

偏差のある状態が長い時間続く場合、入力値の変化を大きくすることで目標値に近づけるための制御。(K_iは積分ゲイン)

微分制御(D制御)

$u(t) = K_d \ \frac{d}{dt} e(t) = K_d \ \frac{d}{dt}( x(t) - y(t) )$

急激な出力値の変化が起こった場合、その変化の大きさに応じて妨げようとする制御。(K_dは微分ゲイン)

PID制御

上記のI制御やD制御だけでは、安定することはなく、これらを組み合わせたPID制御を行う。

$u(t) = K_p\times e(t) + K_i\times \int e(t) dt + K_d\times \frac{d}{dt} e(t)$

この中で、 $K_p , K_i , K_d$ の値は、制御が最も安定するように調整を行うものであり、数値シミュレーションや、ステップ応答を与えた時の時間的変化を測定して調整を行う。

差分計算・レポート-No.4

2018年7月13日

前回の「差分」の講義における、波形データから、山の数をカウントする処理を記述せよ。

2018-07-06-wave

# 授業では結果が「4つの山」としていたが、計算方法が明記されていれば、異なる結果でもよい。

処理は、C言語などのプログラムで記述しても、表計算ソフトでの式による計算でも良い。表計算ソフトを用いる場合は、どのような式を入れてあるか具体的な式について明記してあること。

レポートでは、計算方法が判るプログラムリスト(もしくは表計算ソフトの式がわかるもの)と、その説明。および結果(全データでなくても良く、山としてカウントした部分の近辺のデータ)と、考察を記述すること。

UML振る舞い図

2018年7月13日

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

ユースケース図

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

アクティビティ図

処理順序を記述するための図にはフローチャートがあるが、上から下に処理順序を記述するため、縦長の図になりやすい。また、四角枠の中に複雑なことを書けないので、UMLではアクティビティ図を用いる。

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

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

ステートチャート図は、処理内部での状態遷移を示すための図。１つの状態を長丸長方形で示し、初期状態から終了状態までを結ぶ。１つの状態から、なんらかの状態で他の状態に遷移する場合は、分岐条件となる契機(タイミング)とその条件、およびその効果(出力)を「契機[条件]/効果」で矢印に併記する。複数の状態をグループ化して表す場合もある。

シーケンス図

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

コミュニケーション図

クラスやオブジェクトの間の処理とその応答(相互作用)と関連の両方を表現する図。

リスト追加処理

2018年7月11日

最初のリスト生成の説明では、補助関数 cons を用いて、直接リストを生成していた。
しかし、実際にはデータを入力しながらの処理となるであろう。

最も単純なリスト挿入

struct List* top = NULL ;

int main() {
   int x ;
   while( scanf( "%d" , &x ) == 1 ) {
      top = cons( x , top ) ;
   }
   print( top ) ; // 前回示したリスト全要素表示
   return 0 ;
}

ここで示したコードは、新しい要素を先頭に挿入していく処理となる。このため、作られたリストは、与えられた要素順とは逆順となる。この方法は、リストを管理するポインタが1つで分かりやすい。

要素を末尾に追加

前に示した方法は、逆順になるので、与えられた要素が末尾に追加する方法を示す。

struct List* top = NULL ;
struct List** tail = &top ;

int main() {
   int x ;
   while( scanf( "%d" , &x ) == 1 ) {
      *tail = cons( x , NULL ) ;
      tail = &((*tail)->next) ;
   }
   print( top ) ; // 前回示したリスト全要素表示
   return 0 ;
}

この方法は、次回にデータを追加する場所(末尾だからNULLが入っている)を覚える方式である。ただし、リストへのポインタのポインタを使う方法なので、少しプログラムがわかりづらいかもしれない。

レポート課題

以下に示すようなデータを扱うリスト構造を作り、そのリストを扱うプログラムを作成せよ。
( 出席番号 % 3 ) + 1 の番号の課題に取り組むこと。

名前と誕生日(指定した開始月日・終了月日の範囲のデータのみ表示)
名前と身長・体重(指定したBMI指数以上(もしくは以下)のデータのみ表示)
名前と学科と学年と学籍番号(指定した学籍番号などで検索)

このようなプログラムを作るのであれば、以下の例を参考に。

struct NameAgeList {
   char                name[ 20 ] ; // 名前
   int                 age ;        // 年齢
   struct NameAgeList* next ;       // 次のデータへのポインタ
} ;
struct NameAgeList* na_cons( char* nm, int ag,
                             struct NameAgeList*p )
{  struct NameAgeList* ans ;
   ans = (struct NameAgeList*)malloc(
               sizeof( struct NameAgeList ) ) ;
   if ( ans != NULL ) {
      strcpy( ans->name , nm ) ;
      ans->age  = ag ;
      ans->next = p ;
   }
   return ans ;
}

Ubuntuを最新版にアップグレード(メモ)

2018年7月10日

Azure 上のサーバから、ubuntu を最新版にアップグレードするために、do-release-upgrade を実行せよとのメールが来た。Debian を使っていると、”aptitude update ; aptitude safe-upgrade”を定期的に実行して、大幅アップグレードの時には、/etc/apt/sources.list.d/* を触ってアップグレードを行っているけど、こういうプログラムがあるみたい。

管理している他のサーバは、すでに Ubuntu 16.04 xenial を導入済みで、最初に Azure を使い始めたこのサーバだけ、未だに Ubuntu 14.04 trusty 。

# lsb_release -a        # 現在の情報の確認
# do-release-upgrade -c # 更新が可能かチェック
# do-release-upgrade -s # 更新を実行

ただし、”do-release-upgrade -s” を実行したら、途中で ssh のコネクションが切れておかしくなる可能性があるから、以下のようなメッセージが表示される。Azure 上のサーバなので、1022 のポートを開けたりといった手間が必要そうだし、もう少し状況確認が必要かな。Ubuntu は慣れないなぁ…

SSH経由で実行していますが、続けますか？ 

このセッションはSSH上で実行されているようです。アップグレードをSSH越しに行うことは推奨されません。アップグレードに失敗した時の復元が困難になるからです。 

続行する場合、追加のSSHデーモンをポート '1022' で起動します。 
本当に作業を進めてよろしいですか？ 

続行する[yN]

変化の検出・差分処理

2018年7月5日

変化の検出

例えば、以下のような波形が与えられたとする。この波形で「大きな山が何ヶ所ありますか？」と聞かれたら、いくつと答えるべきであろうか？山の判断方法は色々あるが、4カ所という答えは、１つの見方であろう。では、この4カ所という判断はどうすればいいだろうか？

2018-07-06-wave

こういった山の数を数えるのであれば、一定値より高いか低いか…という判断方法もあるだろう。この絵であれば、15ステップ目、32ステップ目付近は、100を越えていることで、2つの山と判断できるだろう。

こういった予め決めておいた値より「上か？/下か？」で判断するときの基準値は、しきい値(閾値)と呼ぶ。

しかし、この閾値では、40ステップ目から50ステップ目も100を越えており、以下のようなプログラムを書いたら、40ステップ目～50ステップ目すべてをカウントしてしまう。

#define THRESHOLD 100
int x[ 100 ] = {
   // 波形のデータが入っているとする。
} ;

int count = 0 ;
for( int i = 0 ; i < 100 ; i++ ) {
   if ( x[i] >= THRESHOLD )
      count++ ;
}

また、65ステップ目の小さな山も1個とカウントしてしまう。

この問題を避けるために、閾値を130にすると、今度は最初の2つの山をカウントできない。どうすれば、山の数をうまくカウントできるのだろうか？

差分を求める

前述のような問題で山の数を数える方法を考えていたが、数学で山を見つける時には、何をするだろうか？

数学なら、山や谷の頂点を求めるのならば、微分して変化量が0となる場所を求めることで、極大値・極小値を求めるだろう。そこで、山を見つけるために入力値の変化量を求めてみよう。

表計算ソフトで差分を計算するのであれば、セルに図のような式を入力すればいいであろう。このようなデータ点で前の値との差を差分と呼ぶ。数学であれば、微分に相当する。

このグラフを見ると、波形が大きく増加する部分で、差分が大きな正の値となる。さらに波形が大きく減少する部分で差分が負の大きな値となる。特にこのデータの場合、山と判断したい部分は差分が20以上の値の部分と定義することも考えられる。

#define TH_DIFF 20
int x[ 100 ] = {
   // 波形のデータが入っているとする。
} ;

int count = 0 ;
for( int i = 0 ; i < 100 ; i++ ) {
   if ( x[i] - x[i-1] >= TH_DIFF
        && x[i+1] - x[i] <= -TH_DIFF )
      count++ ;
}

しかし、このプログラムでは、山の数をうまくカウントしてくれない。うまく、山の数を数えるためには、差分の値を山と判断するための閾値(この場合は20)を調整することになるだろう。

表計算ソフトで山の場所を見つけたいなら、先の差分の式の隣に、以下のようなセルを入れるといいだろう。
IF( 条件式, 値1, 値2 )
   条件が、TRUEで値1,FALSEで値2 を返す式。
AND( 条件1, 条件2 )
   条件1, 条件2 の両方がTRUEの時、TRUEとなる式

UMLと構造図

2018年7月5日

UMLの構造図の書き方の説明。詳しくは、参考ページのUML入門などが、分かりやすい。

クラス図

クラス図は、構造図の中の基本的な図で、枠の中に、上段：クラス名、中段：属性(要素)、下段：メソッド(関数)を記載する。属性やメソッドの可視性を示す場合は、”-“:private、”+”:public、”#”:protected 可視性に応じて、”+-#”などを記載する。

is-a 、has-a の関係

前の課題でのFigureクラスで、Color 情報をどう扱うべきかで、悩んだ場合と同じように、クラスの設計を行う場合には、部品として持つのか、継承として機能を持つのか悩む場合がある。この場合には、“is-a”の関係、“has-a”の関係で考えると、部品なのか継承なのか判断しやすい。

たとえば、上の乗り物(Vehicle)クラスと、車(Car)のクラスは、”Car is-a Vehicle” といえるので、is-a の関係。 “Car is-a Engine”と表現すると、おかしいことが判る。車(Car)とエンジン(Engine)のクラスは、”Car has-a Engine”といえるので、has-a の関係となる。このことから、CarはVehicleからの派生であり、Carの属性としてEngineを部品として持つ設計となる。

オブジェクト図

クラス図だけで表現すると、複雑なクラス関係では、イメージが分かりづらい場合がでてくる。この場合、具体的な値を図に書き込んだオブジェクトで表現すると、説明がしやすい場合がある。このように具体的な値で記述するクラス図は、オブジェクト図と言う。書き方としては、クラス名の下に下線を引き、中段の属性の所には具体的な値を書き込んで示す。

その他の構成図

その他の構成図としては、コンポーネント図(物理的な構成要素から、システムの構造を表現する図)、配置図(ハードウェアとアプリケーションの関係を図示したもの)、パッケージ図(パッケージ同士の関係をグループ化した図) なども用いる。

UMLの概要

2018年7月5日

巨大なプロジェクトでプログラムを作成する場合、設計の考え方を図で示すことは、直感的な理解となるため重要であり、このために UML がある。以下にその考え方と記述方法を説明していく。

プログラムの考え方の説明

今まで、プログラムを人に説明する場合には、初心者向けの方式としてフローチャートを使うのが一般的であろう。しかし、フローチャートは四角の枠の中に説明を書ききれないことがあり、使い勝手が悪い。他には、PAD と呼ばれる記述法もある。この方法は、一連の処理を表す縦棒の横に、処理を表す旗を並べるようなイメージで記載する。

しかし、これらの記法は、手順を記載するためのものであり、オブジェクト指向のようなデータ構造を説明するための図が必要となってきた。

UML記法が生まれるまで

巨大なプロジェクトでプログラムを作る場合、対象となるシステムを表現する場合、オブジェクト指向分析(Object Oriented Analysis)やオブジェクト指向設計(Object Oriented Design)とよばれるソフトウェア開発方法が重要となる。(総称して OOAD – Object Oriented Analysis and Design)

これらの開発方法をとる場合、(1)自分自身で考えを整理したり、(2)グループで設計を検討したり、(3)ユーザに仕様を説明したりといった作業が行われる。この時に、自分自身あるいはチームメンバーあるいはクライアントに直感的に図を用いて説明する。この時の図の書き方を標準化したもの、UML であり、(a)処理の流れを説明するための振る舞い図(フローチャートやPAD)と、(b)データ構造を説明するための構造図を用いる。

UMLは、ランボーによるOMT(Object Modeling Technique どちらかというとOOA中心)と、ヤコブソンによるオブジェクト指向ソフトウェア工学(OOSE)を元に1990年頃に発生し、ブーチのBooch法(どちらかというとOOD中心)の考えをまとめ、 UML(Unified Modeling Language)としてでてきた。

UMLでよく使われる図を列記すると、以下の物が挙げられる。

構造図
- クラス図
- コンポーネント図
- 配置図
- オブジェクト図
- パッケージ図
振る舞い図
- アクティビティ図
- ユースケース図
- ステートチャート図(状態遷移図)
- 相互作用図
- シーケンス図
- コミュニケーション図(コラボレーション図)

リンク集

検索・リンク

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

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

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

伽藍とバザール

制御工学の概要

PID制御

比例制御(P制御)

積分制御(I制御)

微分制御(D制御)

PID制御

ユースケース図

アクティビティ図

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

シーケンス図

コミュニケーション図

最も単純なリスト挿入

要素を末尾に追加

レポート課題

変化の検出

差分を求める

クラス図

関連

is-a 、has-a の関係

オブジェクト図

その他の構成図

プログラムの考え方の説明

UML記法が生まれるまで

投稿ナビゲーション

システム

最新の投稿(電子情報)

アーカイブ

カテゴリー

メタ情報