Category: software design – basic design

1. どんなプログラミング言語を作りたいか　が大事
2. 小さいプログラミング言語を作り育てていく
3. 開発OSはUbuntuを使用する
4. 開発のためのプログラミング言語はC, js, javaを使う
※コンパイラを作る場合は、アセンブラ言語を用いる必要があり、アセンブラ言語の知識が必要

どんな言語を作りたいかが骨格だが、他の言語の特徴を知っておくことが必要だろう
Python, C, C++, Java, C# などは昔から人気だ。
近年ではTypeScript, Go, Rustなども支持を集めている。

すぐに思いつくだけでもこれだけある
– インタプリタかコンパイル型か
– オブジェクト型かどうか
– 型指定があるかどうか

ブロックチェーン用のプログラミング言語の場合、
– 誰向けの言語か
– Dappsとしての機能を備えるか
– チューリング完全か

また、Solidityなど、他のブロックチェーンが採用している言語は最低限調べる必要がある
インタプリタ型かコンパイル型かについては、両方の開発方法を知っておく必要がある

奥を知ろうと思うと結構時間がかかりそうだ

プログラミング言語を作るには、ルールに合致した機械的な文字列だけを扱う割り切ったプログラムを作ること
インタプリタとコンパイラの共通処理として、字句解析と構文解析がある
※インタプリタは1行ずつ変換すると同時に、その都度命令を処理実行する
※コンパイラは全ての命令をまとめて一括で変換して、一気に処理実行する

### 字句解析(lexical analysis)とは
単語を意味のあるトークンに区切る

num=13-5*2;
print(num);

こちらをtoken配列に入れる文字列処理する

tokens = [
	"num", "=", "13", "-", "5", "*", "2", ";",
	"print", "(", "num", "num", ";"
];

文字列を分割するsplit機能や正規表現は最近の言語では備わっている
C言語の場合は、一文字ずつアルファベットか数字か記号かをチェックしていく
字句解析は、簡単な文字列分割機能だけで十分

### 構文解析(parsing)
処理を途中で止める手段が必要だが、例えば引き算を解析する関数を呼ぶ
tree構造のデータにすると分かりやすくなる。抽象構文木(AST: abstract syntax tree)
tree構造にすると、leftとrightに分けて、=, *, -, () などはopと呼ぶのが面白い。bitcoinのOPやハッシュ値のparseとプログラミング言語のparsingにかなり共通点があることがわかる。

{
	left: {
		left: 'num',
		op: '=',
		right: {
			left: '13',
			op:'-',
			right: {
				left: '5',
				op: '*',
				right: '2' 
			}
		}
	},
	op: ';'
	right: {
		left: 'print',
		op: '()',
		right: 'num'
	}
}

parsingとは、token配列をASTに変換する

### インタプリタ
字句解析、構文解析の後、ASTをそのまま実行する

### コンパイラ
字句解析、構文解析の後、ASTを元に、アセンブラを出力する
アセンブラのテキストファイルはasコマンドでバイナリに変換する
その後、リンカと呼ばれるldコマンドで、複数のオブジェクトファイルを連結して1つの実行ファイルにする
実行ファイルを実行すると、execシステムコールが呼ばれ、OSはバイナリ中で指定されたローダーと呼ばれる外部プログラムを起動する。
ローダーは実行ファイルや動的ライブラリなどをメモリ上に配置して、指定されたエントリポイントからCPUに制御を渡す

一個作っておいて、追加/加筆することで、ノウハウを蓄積していく。

## 目次
– 方針
– マークアップ(HTML)
– スタイルシート
– 画像スライス
– SP対応
– フォーム
– その他
– 表示速度の改善
– その他

### 作っていく中で気になった点
ID・Class名
L 原則としてBEM+FLOCSSのルールに従って命名

CSS プロパティの順序

box-sizing
margin、padding
width、min-width、max-width
height、min-height、max-height
background、background-color、background-image、background-repoeat、background-position、background-size
border、border-width、border-style、border-color、border-radius
outline、outline-width、outline-style、outline-color
table-layout、border-collapse、border-spacing、empty-cells、caption-side
box-shadow
list-style、list-style-type、list-style-image、list-style-position
overflow
opacity、visibility
display、box-flex
float、clear
position、top、right、bottom、left、z-index
color
font-size、font-weight、font-style、line-height、letter-spacing
text-align、text-decoration、text-shadow
vertical-align
content
zoom
その他

フォント周りの単位指定
L font-size:remで指定

PNG-32(24)
L 透過色がある画像に使用

画像ファイルの圧縮
L compressor.ioを使う

ちょっとずつクオリティを上げていきたいですね。JSの最新版の書き方もやっておかないといけないな。
よし、次行こう。Next:テストコードの書き方

– 今回はDjangoを学習するのが目的の一つでもあるため、設計書はざっくりと作る
– 販売管理システムは財務会計システムとの連携(ERP化)を見据えて作る
– できればRPA、機械学習、Docker、レジシステム連携、ECサイトのAPI連携、ラズパイ/Arduino連携を盛り込みたい
———–
1.全体
　1-1. 何故、販売管理システムを導入するか？
　1-2. 販売管理システムで出来る事(後から作る)
2. システム要求
　2-1. 機能要求
　2-2. 競合のシステムとの差別化
　2-3. 財務会計との連携(後から作る)
3. 基本設計
　3-1. 業務フロー
　3-2. ユースケース
　3-3. 機能詳細
4. 外部設計
4-1 システム概要図
　4-2 インフラ構成図
　4-3 ハードウェア構成図
　4-4 ミドルウェア構成図
5. UI設計
　5-1. URL一覧
　5-2. 画面遷移図
　5-3. 画面定義(別紙)
　5-4. メール設計
　5-5. バリデーション
6. 詳細設計
　6-1. MVC構成図
　6-2. シーケンス図
　6-3. コントローラ処理
　6-4. バッチ処理
　6-5. その他

設計書はサクッと作ろうと思ったけど、最低限の事はちゃんとやろうと思うとそこそこのボリューム感になってしまうな。

■要件定義書
– システム概要(何をするシステムなのか、どうしてそのシステムが必要なのか、そのシステムの目的は何か)
– システム構成図(システム概念図、業務フロー、ユースケース図)
– 機能要件(システムの機能一覧、各機能の詳細)
– 入出力要件(入力データ一覧、各入力データの詳細、出力データ一覧、各出力データ詳細)
– 非機能要件(セキュリティ要求、品質・性能要求)
– その他(概略スケジュール、ステークホルダー相関図)
■外部設計
– システム概要
　 — シナリオ
　 — ビジネスロジック
– システムの構成
　— システム構成図
— 業務フロー・アクティビティ図
　— ハードウェア・ソフトウェア構成図
　— ネットワーク構成図
– 機能一覧表
– データベース仕様
— ER図
— テーブル定義書
– UI設計
— 画面遷移図
— 画面レイアウト設計図
– その他
— 開発体制
— 開発スケジュール
— プロジェクト管理ツール
■内部設計
– 機能分割説明
— クラス図
– データフロー
— DFD図
– モジュール詳細
— モジュール名
— 役割
— 引数・戻り値
— 処理概要
— 備考

なんか、げっそりするな、見ただけで。

帳票は一般画面と別の扱いか。。うむ。

– 項目名
– 説明
– 取り扱い
– 備考

仕事とは、突然降ってきます。
とりあえず、機能一覧について調査します。

-システム開発における大分類、中分類を洗い出して、一覧表にまとめて整理します。

1. Plan
2. requirement analysis
3. basic design
4. development, coding
5. test
6. implmentation

Basic Design
3.1 screen form design
3.2 database design
3.3 common part design
3.4 process design
3.5 external interface design
3.6 operational design
3.7 migration design
3.8 schedule

development quotation
– Implementation
– Additional man-day or man-hour
– Unit Test
– Source Review
– Combined Test
– Release man-day
– Procedure preparation

Difference between external design and internal design
– external design
— system function, performance, condition
– internal design
— operation, function, physical data inside the system