構造化設計とオブジェクト設計の違い
概要
本記事では，構造化分析・設計手法とオブジェクト分析・設計手法の違いについて述べる．
2手法の主な違いは2つある
まず，処理の対象となるデータの取り扱い方針に違いがある
構造化分析・設計手法では，プログラムとデータをそれぞれ独立した要素として取り扱う
オブジェクト分析・設計手法ではプログラムをアプリケーションロジックとデータ操作ロジックの2つに分離して取り扱う
オブジェクト分析・設計手法では，データをデータ本体とデータ操作ロジックのセットで取り扱う
次に，各手法に沿って構築されるソフトウェアのアーキテクチャに違いがある
構造化分析・設計手法では，ソフトウェアがユーザインターフェース層，アプリケーション層で構成される．
一方，オブジェクト分析・設計手法ではソフトウェアがユーザインターフェース層，アプリケーション層，ドメイン層で構成される
データの取り扱い方針の違い
構造化分析・設計手法では，プログラムの処理とデータをそれぞれ独立した要素として取り扱う
このことにより，データが処理に依存することを避けられる．
その結果，同じ内容のデータがプログラムの複数箇所で重複して定義されているといった無駄な設計を回避することができる．
一方で，構造化分析・設計手法にはデータ構造の変更がプログラムの処理全体に影響を及ぼしてしまうといった問題がある．
なぜなら，プログラムとデータを分離することでデータの依存性は回避することができたが，処理については依然としてデータ構造に依存してしまっているためである．
オブジェクト分析・設計手法では，プログラムで取り扱うデータをデータ本体とデータ操作ロジックのセットとして捉える
アプリケーションロジックはアプリ固有の抽象度の高い概念を「オブジェクト」として操作し，アプリケーションが提供する機能を実装する
データ操作ロジックは，アプリケーションロジックからの呼び出しに応じてデータベースといった実装レベルのデータを直接操作する．
その上で操作した結果をアプリケーションロジックが取り扱う抽象度の「オブジェクト」としてアプリケーションロジックに渡す
オブジェクト分析・設計手法では，データ構造の変更により影響が及ぼされるロジックはデータ操作ロジックに限定される
なぜなら，データ構造の変更に伴い以下2つの事項について対応すればアプリケーションロジックを変更する必要はなくなるからである．
- データを直接操作するデータ操作ロジックの内容を変更する
- アプリケーションロジックに向けて公開しているデータ操作用のインタフェースの仕様を保持する
アーキテクチャの違い
構造化分析・設計手法ではプログラムが以下に示す2つの処理層から構成される
- ユーザインターフェース層
- アプリケーション層
前節で述べた通り，構造化分析・設計手法ではプログラムとデータを分離して取り扱う．
分離されたプログラムはアプリケーション固有の処理のみ(ユーザインターフェース処理も含む)を行う
故に，アーキテクチャとしてはユーザインターフェース層とアプリケーション層のみとなる
オブジェクト分析・設計手法ではプログラムが以下に示す3つの処理層から構成される
- ユーザインターフェース層
- アプリケーション層
- ドメイン層
オブジェクト分析・設計手法では，構造化分析・設計手法のアプリケーションロジックに加えてデータ操作を行う処理層としてドメイン層がアーキテクチャの構成要素に含まれる
まとめ
構造化分析・設計手法とオブジェクト分析・設計手法の違いとは，データの取り扱い方針の違いである．
構造化分析・設計手法では処理とデータ本体を分離して取り扱うのに対し，オブジェクト分析・設計手法ではデータをデータ本体とデータ操作ロジックの２つ１組として取り扱う．
このデータ操作ロジックのことをドメイン層と呼ぶ．
ドメイン層を設けることにより実装レベルのデータ処理が隠蔽されるため，データ構造の変更による影響をドメイン層に留めることができる．
文章の書き方
前提
メモとして残した技術情報を元に手を動かしたい
現状，メモを構成する論理要素は以下のとおりである．
- 目標の状態
- 前提状態
- 前提状態から目標状態を得るための変換プロセス
- 各状態の確認方法
問題
執筆した技術メモをもとに手を動かすことができない
なぜなら、読み手(執筆者も含む)が文章の論理構造を理解できないからである。
なぜなら、その論理要素間の関係を理解できないからである
課題
上記の通り，課題は論理要素間の関係を読み手に理解させることである
論理要素間の関係を読み手に理解させる
論理要素間の関係を読み手に理解させるためには、読み手に明確なメンタルモデルを形成させることが必要となる
そのためには，読み手に予想させた情報に沿って文章を展開することが必要となる
予想させた情報にそって文章を展開するためには，以下2つの条件を満たす文章を書く必要がある
- 段落単位で論理構成が整理されていること
- 段落内ですでに述べた既知情報をつなぎに新しい情報が展開されていること
施策
以下2つの課題を満たす文書作成手順を示す
- 段落単位で論理構成が整理されていること
- 段落内ですでに述べた既知情報をつなぎに新しい情報が展開されていること
段落単位で論理構成が整理されていること
以下の手順に沿って段落構成を決める
- 情報を分類する
- グループを正しく対応させる
- 情報の対応関係に不足がないか確認する
- 各パラグラフの展開順を決める
情報を分類する
まず，情報を分類する
まず，述べる情報を一覧にする．
一覧にした情報を一段抽象度の高い概念でグルーピングする
グルーピングされない情報については，ふるい落とす
グループを正しく対応させる
次に，グループ間で情報を正しく対応させる
まず，グルーピングした情報の論理関係を定義する
論理関係は，問題-課題-施策といった論理的な対応関係のことである
論理関係を有さない情報については，不要な情報としてふるい落とす
情報の対応関係に不束がないか確認する
次に，情報の対応関係に不足がないか確認する
定義した論理関係の中に結論まで達することなく途中で切れてしまっているものがないか確認する．
切れているものに関しては，その理由を追記する．
または，不要な情報としてふるい落とす
各パラグラフの展開順を決める
次に，パラグラフの展開順を決める
まず，適切な順序でグループを整理する
適切な順序とは，時間順や空間順，割合順などの順序である
次に，整理したグループの順番に要約文を書きパラグラフとする
この時以下の条件を満たす要約文を書く
- 具体的な単語を使う
- 肯定形で内容を表現する
- 被修飾語句と修飾語句の関係が明確になるように表現する
段落内ですでに述べた既知情報をつなぎに新しい情報が展開されていること
以下の手順に沿って各論の詳細を記述する
- 各要約文の結論の導出過程を整理する
- 結論までの導出過程をチェックする
各要約文の結論の導出過程を整理する
まず，各要約文の結論の導出過程を整理する
各導出は，以下の要素で構成する
この時，根拠となる情報は前段で述べた結論か提言的事実のどちらかの情報である
- 真とする根拠情報
- そこから導出する結論情報
- 結論を導出する論拠
- 根拠に対する反証
- 論拠に対する反証
結論までの導出過程をチェックする
結論までの導出過程をチェックする
具体的には，整理した導出過程に上記の要素がすべて含まれているか確認する
効果検証
以下の手順に沿って施策の効果検証を実施する
- 以上の手順に沿って技術文書を作成する
- 作成した文書を元に成果物を作成する(不具合修正も含む)
- 作成した成果物が期待通り動作するか確認する
チーム開発環境の整備（ワークフロー）
ブログを復活させたわけですが、本格的に動き出す前に開発環境を整備したいと思います。
というのも先日私が研究室にいたときの後輩と久しぶりに会いまして食事をしたのですが、研究室（後輩と私はWebシステムに関する研究を行う研究室に所属しておりました）で学んだ知識を無下にするのももったいないということで、自分達で使えるWebシステムを一緒に作ろうという話になりました。
とは言ってもお互いに住んでいる場所は離れているため、リモートでかつ共有して使える開発環境が欲しくなったという次第であります。
GitHub Flow
とりあえずGitHub社が採用しているワークフローであるGitHub Flowに沿った開発環境を構築することにしました。
GitHub Flowについては以下の本を参考にしました
GitHub Flowhttps://www.amazon.co.jp/GitHub実践入門-Pull-Requestによる開発の変革-PRESS-plus/dp/477416366X
個人的な感想としてはみんなでリポジトリを触ってもmasterブランチだけは壊さないようにするためのGitHubで提供されている各種機能の使い方とその手順というような感じだと思いました。
GitHub Flowに沿って開発を行うためには以下のツールが必要なようです
- CIツール
- デプロイツール
CIツールとデプロイツールについては現在調べている途中です（現状だとCircleCIが良さそう）
ブログを再開したいと思います
最後のブログを更新してからかなりの時間が経過しました。
もし私のブログをはるか昔に読まれていた方がいらっしゃいましたらお詫びさせていただきます。途中で更新を放り出してしまい大変申し訳ありませんでした。
私の方はあれからいろいろありまして、今年の４月から某電機メーカーの技術者として働くことになりました。
社会人として働くにあたり、自分が習得した知識について振り返ってみたところ、恥ずかしながらあまりに中途半端な知識しか身に着けていないことに気づきまして、勉強をやり直す必要があると感じている次第であります。
だらだらと続けて結論が見えないですね。つまり、このブログを再開しようと考えております。具体的には私の勉強の内容をまとめる備忘録としてこのブログを機能させたいと考えております。
とりあえず、以前の更新から放置してしまったリアルタイムOSの勉強から手をつけたいと考えております。
さらに、制御工学、FPGA、WEBと私の勉強の記録を幅広く残していきたいと思うので、これらの分野に興味のある方で時間に余裕のある方は、私自身未熟者ですので、記事を読んで批評していただくと助かります。
それでは、よろしくお願いします。
まずはkozos上ででいろいろやってみる
あらかた雑用も終わったので、kozos-inspireの制作に入っていこうと思う。早速前回考えていた機能を追加していきたいところだが、正直な話ファイルシステムの実装とか言ってもファイルシステム自体まだ良くわかっていないような状態（わかってないのに実装するとか言うな！って感じですけど、私は概要だけささっと見て面白そうだなと思ったらとりあえずやりたくなっちゃうたちなので・・・）なので、まずは既存のkozos上でデキることで遊んでみたいと思う。とりあえずなにをしようかいろいろ考えていたところ、以前kozosでwebサーバを動かした時に不便だなぁと感じた点があったことを思い出した。それは何かというとhtmlファイルの追加・変更まわりの機能である。従来のkozosだとソースコードに直接htmlの内容を書き込んでH8に転送し直さなくてはならなかった。この手間を省くためにSDカードからhtmlファイルを読み込んだり管理したりするためにmkdirやlsとかcatとかのコマンドを追加したいと思ってる。実際に動かすことで仕組みも自ずとわかってくると思うのでとりあえずやってみる。
自作組み込みOS、kozos-inspireのコンセプトについて
夏休みに入ったはいいが、先輩にリンカスクリプトの講座を頼まれたり下級生の手伝いをしたりと何かと雑用が多くて思うように組み込みOS製作が進められずもやもやしてます・・・。まぁ愚痴を言ってもしょうがないので今できることからやっていこうと思う。とりあえずどんなOSにするかはっきりと決めていなかったので今ある考えを文章に起こして整理してみたいと思う。ちなみに作るOSの名前はまだ決まってません。kozosをベースに作るので暫定的にkozos-inspireと呼びたいと思います。
まず、どんなOSを作りたいかというところから整理してみる。とりあえず今考えていることをざっと書いてみると、こんな感じになる
- みんなが使いやすいOS
- ハードの深いところまで自由に制御できるようなOS
- マイコンで気軽にスレッドプログラミングができるようになるOS
- データの取り扱いが容易なOS
- 他の組み込み機器を用意に扱えることができるOS
1と2に関しては抽象的な言い方でなにをしたらいいかはっきり見えてこないかもしれないがこれから作るOSの核となる重要なテーマである。ざっくり言うとわたしは今回UbuntuとかDebianのような組み込みOSを作りたいと思っているのです（ちょっとわかりずらいたとえかもしれないけど）。どういうことか説明するために例として二つのOSとしてWindowsとFreeBSDを挙げたいと思う。独断と偏見が混じった見解なので間違ったこと言ってるかもしれないがそこらへんはご容赦ください。
まず、Windowはマウス操作ひとつでほとんどのことができて便利な一方、自分が自由に制御できる機能はだいぶ制限されてしまうOSである。次に、FreeBSDは、コンピュータの下層の部分まで大方自由に制御できる反面、ユーザインターフェースがCUIしかないところなどが初心者にはきついOSである。二つのOSにはそれぞれ長所と短所があるが、その二つのOSのいいとこ取りなOS、つまりは、Ubuntuのような初心者でもなんとかついてこられる程度の操作難易度で、なおかつマイコンの下層まで自由に制御することができるOSを作りたい（FreeBSDもXウィンドウシステム使えるけど、わたしはFreeBSDはそういう風に使うOSじゃないと思っているので)。
3,4,5に関してはまだまだ考え中といったところだが、4を実現するためにファイルシステムを実装してみようかなと思っている。さらに5については、UNIX系ＯＳのストリームみたいな入出力機能を持たせてみたいと考えている。3についてはもっとスレッドプログラミングについて勉強してから決めることにする。
こうして整理してみるとわたしの知らない新しい分野のことだらけなのでちょっぴり不安だが何とかがんばってやり遂げたいと思います。もし、どんなソースコード書いてるのか見たい方がおりましたらわたしのgithubのリポジトリのリンクを張っておくのでご覧になってください。
つーか、コレ夏休み中に終わるかな・・・
