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

(1通目)
> Subject: 【株式会社×××】採用選考会のご案内
> 進路担当様　各位 ....
>　　[以下略]

(2通目)
> Subject: 取り消し: 【株式会社×××】採用選考会のご案内
> ◯◯◯◯はメッセージ - "【株式会社×××】採用選考会のご案内"
> を取り消します。

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

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

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

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

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

ユースケース図

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

アクティビティ図

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

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

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

シーケンス図

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

計算処理中に一時的なデータの保存として、stackとqueueがよく利用されるが、 それを配列を使って記述したり、任意の大きさにできるリストを用いて記述する。

スタック

一時的な値の記憶によく利用されるスタックは、一般的にLIFO( Last In First out )と呼ばれる。 配列を使って記述すると以下のようになるであろう。

#define STACK_SIZE 32
int stack[ STACK_SIZE ] ;
int sp = 0 ;
void push( int x ) {
stack[ sp++ ] = x ;
}
int pop() {
return stack[ --sp ] ;
}
void main() {
push( 1 ) ; push( 2 ) ; push( 3 ) ;
printf( "%d\n" , pop() ) ;
printf( "%d\n" , pop() ) ;
printf( "%d\n" , pop() ) ;
}

しかし、この中にSTACK_SIZE以上のデータは貯えられない。 同じ処理をリストを使って記述すれば、ヒープメモリを使い切るまで使うことができるだろう。

struct List* stack = NULL ;
void push( int x ) {
stack = cons( x , stack ) ;
}
int pop() {
int ans = stack->data ;
struct List* d = stack ;
stack = stack->next ;
free( d ) ;
return ans ;
}

キュー(QUEUE)

２つの処理の間でデータを受け渡す際に、その間に入って一時的にデータを蓄えるためには、 待ち行列(キュー)がよく利用される。 FIFO(First In First Out)

配列にデータを入れる場所(wp)と取り出す場所のポインタ(rp)を使って蓄えれば良いが、 配列サイズを超えることができないので、データを取り出したあとの場所を循環して用いる リングバッファは以下のようなコードで示される。

#define QUEUE_SIZE 32
int queue[ QUEUE_SIZE ] ;
int wp = 0 ;
int rp = 0 ;
void put( int x ) {
queue[ wp++ ] = x ;
if ( wp >= QUEUE_SIZE )
wp = 0 ;
}
int get() {
int ans = queue[ rp++ ] ;
if ( rp >= QUEUE_SIZE )
rp = 0 ;
return ans ;
}
void main() {
put( 1 ) ; put( 2 ) ; put( 3 ) ;
printf( "%d\n" , get() ) ;
printf( "%d\n" , get() ) ;
printf( "%d\n" , get() ) ;
}

このようなデータ構造も、get() の実行が滞るようであれば、wp が rp に循環して追いついてしまう。

そこで、このプログラムもリストを使って記述すると以下のようになる。

struct List* queue = NULL ;
struct List** tail = &queue ;
void put( int x ) {
*tail = cons( x , NULL ) ;
tail = &( (*tail)->next ) ;
}
int get() {
int ans = queue->data ;
struct List* d = queue ;
queue = queue->next ;
free( d ) ;
return ans ;
}

ただし、上記のプログラムは、データ格納後にget()で全データを取り出してしまうと、 tail ポインタが正しい位置になっていないため、おかしな状態になってしまう。

また、このプログラムでは、rp,wp の2つのポインタで管理することになるが、 2重管理を防ぐために、リストの先頭と末尾を1つのセルで管理する循環リスト法が使われることが多い。

職場に届いた、フィッシングメール。 あまりにも出来が悪いので、記念に掲載しておこう。