Visual Studio Codeでdraw.ioを使う

フローチャートやネットワーク図等は、フリーの作図ツール「draw.io」を使うと楽に記述できます。
Excelでも記述はできますが、draw.ioでは各々の図の記述に適した素材が提供されているという特徴があります。
また、draw.ioはブラウザ上での使用が想定されていますが、フリーのコードエディタである「Visual Studio Code」を用いるとローカル上で編集が可能になります。

今回は、使用手順を簡単に紹介していきたいと思います。


1.draw.ioのホームページにアクセスする。

https://app.diagrams.net/

2.ファイルの保存方法を選択する。

今回は「Device」を選択します。これで図がローカルに保存できるようになります。
また、選択後、新規にファイルを作成するかどうか聞かれるので、新規にファイルを作成する(Create New Diagram)を選択します。

3.どのような図を作成するか選択する。

今回は「Flowchart」を選択します。

4.ブラウザ上でファイルを編集してみる。

例えば、図形を追加する場合は、「Shapes -> General」から追加することができます。
また、図形の中に文字を入力したい場合は「右クリック -> Edit」で入力できます。
図を保存したい場合は、画面上部の「Click here to save.」から保存できます。

5.Visual Studio Codeに拡張機能を入れる。

ローカルでVisual Studio Codeを開き、拡張機能の検索画面を開きます。
そして、「draw.io」を検索し、「Draw.io Integration」をインストールします。

6.4でローカルに保存したファイルをVisual Studio Codeで開く。

すると、以下のように、ローカルでdraw.ioの図を編集できるようになります。
図形の追加は「General」から、文字編集は図形をダブルクリックすることで可能です。


いかがでしたでしょうか。

Visual Studio Codeはコードエディタではありますが、サクラエディタのようなテキストエディタというよりも、EclipseやVisual StudioのようなIDEに近く、「軽量IDE」と呼んだ方が実態に近い位です。
そして、IDEと同じように、拡張機能も数多く用意されています。

機会があれば、便利な拡張機能をまた紹介したいと思います!

クラウドコンピューティングの分類

今回はクラウドコンピューティングについて、その概要と分類について書いていきます。

世界的に有名なクラウドコンピューティングサービスとしては、Amazon Web Services(AWS)、Google Cloud Platform(GCP)、Microsoft Azure等が挙げられます。
これらのサービスが実務で使われることも増えています。
また、ここ5年ほどで、情報技術者試験でも、クラウドコンピューティングの概要や分類について知っておかないと解けない問題が出題されるようになりました。

情報技術者試験で問われるレベルの知識がないと会話や情報収集をするだけでも難しくなっており、現代のIT技術者にとって重要な技術となりました。


【クラウドコンピューティングの概要】

クラウドコンピューティングとは、サービス事業者が管理するシステムにインターネットを介して接続することで、目的のサービスを受けるというものです。
月額必要を支払うことで、自社でシステム資源を用意し管理する必要がなくなるというメリットがあります。
可用性等のシステム要件はサービス提供事業者毎に異なり、SLAにより合意します。

クラウドコンピューティングは、仮想化技術によって支えられています。
仮想化技術とは、1台の物理サーバを複数台の仮想的なサーバに分割し、それぞれに別のOSやアプリケーションソフトを動作させる技術のことです。
1台の物理サーバで複数の仮想サーバをコントロールできるため管理が容易になりますが、1台のサーバに処理が集中し競合も起きるため、サーバの利用率やCPUのオーバヘッドは上昇します。


【クラウドコンピューティングの分類】

クラウドコンピューティングのサービス形態は、大きく分けると以下の3つがあります。

■SaaS(Software as a Service)

サービス提供事業者はアプリケーション・ミドルウェア・OS・ネットワーク・ハードウェアを提供・管理する。
利用者はクラウド上のアプリケーションを使用する。
利用者が管理するものはない。
利用者はアプリケーションにおける設定可能範囲内でカスタマイズが可能。
 

■PaaS(Platform as a Service)

サービス提供事業者はミドルウェア・OS・ネットワーク・ハードウェアを提供・管理する。
利用者は、クラウド上で用意されたプログラミング言語・ライブラリ・サービス・ツールを使用し、アプリケーションを実装する。
利用者はアプリケーションを管理する。
利用者はミドルウェアにおける設定可能範囲内でカスタマイズが可能。
 

■IaaS(Infrastructure as a Service)

サービス提供事業者はOS・ネットワーク・ハードウェアを提供・管理する。
利用者は、クラウド上で用意されたインフラ資源を利用し、システムを構築する。
利用者はアプリケーション・ミドルウェアを自前で用意・管理する。
利用者はOS・ネットワークに関して決められた範囲内でカスタマイズが可能。
(OS・ネットワークも完全に利用者が自前で用意する場合もある)


クラウドコンピューティングの分類について、記憶を定着させたり情報を整理するために簡単な表を作りましたので、よろしければこちらも参考にしてみてください。

■SaaS・PaaS・IaaSの概要

※頭文字を取って「SPI」と覚えると、より覚えやすいかもしれません。
 ちなみに、「SPI」は就職試験で使われる有名な適性試験の名前です。  

■SaaS・PaaS・IaaSでの資源の扱い


いかがでしたでしょうか。

クラウドコンピューティングについて、情報処理技術者試験で問われるレベルのことを書いてみました。
現代でインフラエンジニアとして仕事をするのであれば、より深い知識が必要になります。
ベンダー資格も充実しているので、興味があれば学ぶことをお勧めします。

シーケンス図の使い所とPlantUMLの紹介

UMLの一つであるシーケンス図は、クラスやオブジェクト間のやりとりを時間軸に沿って表現する図です。
複数の処理が並列で走る場合に、処理タイミングを整理する上で便利な図です。

例えば、マルチスレッドプログラムを開発している時に便利です。
シーケンス図を書くと、ややこしいスレッド間の関連をわかりやすく整理することができます。
マルチスレッドを取り扱う解説書やシーケンス図は良く出てくるのですが、保守開発等で自分がコーディングする時にも頭の整理のために役立てることができます。

以下では、javaでのスレッド制御(joinとsynchronized)で取り上げたサンプルコードを、試しにシーケンス図でまとめてみます。
このように、シーケンス図を書くことで、各スレッドの連関をわかりやすく整理することができます。

・そのまま実行した場合

・①のコメントアウトを外した場合(join)

・②のコメントアウトを外した場合(synchronized)


UMLの図を書く時は、PlantUMLを使うと便利です。
PlantUMLは、テキストからUMLの図を生成することができるツールです。
UMLをテキストで書くことで、手軽に図を書けるようになりますし、Gitでの管理・差分比較もできるようになります。

下記のページにアクセスするだけで、すぐに使うことができます。
図の書き方(文法)についても説明されています。
https://plantuml.com/ja/

オンライン上で図を生成することが可能で、上記ページ中で試しに作ることができる他、「オンラインサーバ」のページにアクセスすることで大きな画面で作ることができるようになります。

セキュリティや作業効率等の問題でオンライン上で図を生成したくない場合は、ローカル上で図を生成することもできます。
ローカル上で図を生成する方法は、「クイックスタートガイド」に書いてあります。

以下、試しに、シーケンス図を書いてみたものです。
前述の「①のコメントアウトを外した場合(join)」のケースについて書いています。

【サンプルコード】

【生成結果】


いかがでしたでしょうか。

UMLの中では、シーケンス図はかなり使用頻度が高い図です。
今回紹介したケースのように、処理のタイミングを整理したい時に便利な図なので、書き方を覚えておくと良いでしょう。
その際にPlantUMLを使えば、図を書いたり管理したりする手間も少なくなると思います。

データレコードの種類を増やして拡張性を持たせる

以前に書いた「ヘッダレコード・データレコード・トレーラレコードとは」の続きです。


企業間でやりとりするファイルでよく見かけるフォーマットとして、レコードが「ヘッダレコード」「データレコード」「トレーラレコード」に分かれているフォーマットがあります。
簡単に言うと、それぞれのレコードの説明は以下のようになります。

【それぞれのレコードの説明】

・ヘッダレコード

ファイルの1レコード目のレコード。
一般的には、そのファイルが何日のデータなのかが記述される。

・データレコード

ファイルの中間レコード。
実際にやりとりするデータの中身が記述される。

・トレーラレコード

ファイルの最終レコード。
一般的には、そのファイルのデータレコード件数が記述される。


ここで、拡張性を確保するために、データレコードの種類を増やすという手段が有効になることがあります。
種類が異なるデータレコードをファイルに含める場合、データレコードのフォーマットを変えてしまうと、フォーマットが複雑になることで書き込み・読み込み処理が複雑になったり、フォーマット変更時の影響が全種類のデータレコードに出てしまったりします。
しかし、種類毎にデータレコードを用意することで、1つ1つのフォーマットが複雑になることを防いだり、フォーマット変更の影響が当該種類内のデータレコードに限定させることができます。

フォーマットと処理の例としては以下の通りです。
商品の種類毎にデータレコードの種類を変えることで、データ体系の違いを吸収している所がポイントです。
(1つのデータレコードにしてしまうと、1つのデータレコードに「食品商品コード」と「玩具商品コード」が含まれることになり、どちらを書き込むか・読みこむかの判断が必要になってしまいます。また、食品若しくは玩具にだけ新たな項目を追加する時に、追加が必要無い方の種類の商品の考慮も必要になってしまいます。)

【フォーマット例】

取扱商品ファイルを想定した例を記載します。
可変長のCSVファイルを想定します。
(固定長の場合も多いです。固定長の場合は、カンマ区切りではなくバイト数で区切ることになります。)

・ヘッダレコード

1項目目:ファイル区分(1がセットされる)
2項目目:ファイル作成日付(YYYYMMDD)

・食品データレコード

1項目目:ファイル区分(2がセットされる)
2項目目:食品商品コード(7桁の数値)
3項目目:商品名(全角文字)
4項目目:値段(数値)

・玩具データレコード

1項目目:ファイル区分(2がセットされる)
2項目目:玩具商品コード(6桁の数値)
3項目目:商品名(全角文字)
4項目目:値段(数値)

・トレーラレコード

1項目目:ファイル区分(9がセットされる)
2項目目:データレコードの件数(数値)

【ファイルのレコード例】

【ファイル受信時の処理例】

ヘッダレコードやトレーラレコードは、受信側のチェック処理に利用できます。
以下、ファイルを1レコード目から順番に読む場合の処理例について記載します。

・ファイル区分が1の時

1レコード目がファイル区分1でなければ異常終了。
(送信側が中間ファイル等誤ったファイルを送信することを想定)
バッチ日付と比較し一致しなければ異常終了。
(送信側が誤って過去ファイルを送信することを想定)

・ファイル区分が2の時

業務上必要な食品向けの処理を実行。

・ファイル区分が3の時

業務上必要な玩具向けの処理を実行。

・ファイル区分が9の時

最終レコードのファイル区分が9でなければ異常終了。
(ファイルを全件受信できていないことを想定)
件数がファイル区分2~3のレコード数と一致しなければ異常終了。
(ファイルを全件受信できていないことを想定)


いかがでしたでしょうか。

このテクニックは、レガシーなシステムでは良く使われるテクニックです。
レガシーなシステムの設計をする場合に、もしかしたら役に立つことがあるかもしれません。

システムの概要を示す設計書が本当に必要な設計書である

表題の通りですが、システム開発で本当に必要な設計書は、システムの概要を示す設計書です。
そのような設計書があれば、実装を知らない立場の人(例えば要件定義担当や上位の設計者)との意思疎通がスムーズになりますし、開発者を新たに向かい入れる時にも実装の内容をスムーズに理解してもらえるようになります。


例として、在庫確認モジュールを開発しているとします。
具体的な実装としては以下のイメージとします。
実際には、「:」の箇所に数行~数十行のコードが書かれているイメージです。

【実装イメージ】


良くない設計書の例としては、以下のようなものがあります。
(残念ながら、実務でも見かけることがあります)

・ソースコードと1対1対応の設計書

ソースコードを1行1行日本語に訳したような設計書は良くありません。
そのような設計書は記述量が多くなり、作成するのも大変ですし、それを読んで内容を理解するのも大変です。
また、日本語(自然言語)は意味が曖昧になりがちなので内容も不正確になります。
更に、ソースコードに些末な変更を行う度に、設計書の更新も必要になるという問題もあります。
(設計書の更新を忘れると、設計書を信用できなくなる)

・見た目だけで内容に乏しい設計書

経験が浅く見様見真似で設計業務に当たっている場合、以下の絵のような見た目だけで内容に乏しい設計書を作成しがちです。
(この例の絵は少し誇張しすぎですが)

しかし、設計書はかっこ良く見せる資料ではなく、実装に直接的・間接的に関わる人と意思疎通を取るための資料なので、実装内容が早く正確に伝わればそれで良いです。
どのような設計書を作れば良いかイメージが付きにくい場合は、現現場の既存の設計書や他現場の設計書を参考にしたり、先輩社員に聞いたりすると良いでしょう。


システムの概要が早く正確に伝わる設計書が良い設計書です。
例えば、以下のような処理概要を掴めるフローチャートは良い設計書です。

このような設計書があれば、要件定義担当や上位の設計者が全体像をつかみやすくなり、レビュー(要件や全体の設計の観点から見て問題がないことの確認)が捗ります。
また、新たに開発者を向かい入れる場合にも、モジュールの全体像を掴んでもらってから、必要に応じて細かい箇所を確認してもらうことができるようになります。


いかがでしたでしょうか。

良い設計書を書けるようになることが、PGからSEへのステップアップの鍵です。
システムの概要を示すことを意識することが重要で、それを意識しながら実務にあたると、自ずと良い設計書が書けるようになるでしょう。