WEBディレクション

ディレクターの役割


・クライアント~製造側の仲介
・要望を聞き、アイディアを出す
・要件をまとめ、終わらせる
・製造側へ要件を伝える

発想する

・意見を出す/否定する/俯瞰で見る、それぞれの視点が必要。
・アイディアを出す成果を問わない。無責任にとにかく数を出す。
・メディア置換:ゲームだったら?SF映画だったら?恋愛ドラマだったら?
・ブランド置換:アップルだったら?トヨタだったら?
・人物置換:秋本康だったら?ビルゲイツだったら?

仕事の流れ


UX:User eXperience (ユーザー体験)
UI:User Interface (ビジュアル、機能)
プロトタイピング:現代ではユーザーの環境(サイズ、状況、好み)は多様な為、スマホ用画面等をユーザに操作してもらう
後工程での不満が無くなる為必要

この流れを崩さない
プロトタイピング、デザインを見積もりより先にする事はない。
アジャイル的になアプローチだとしてもそれはあくまでヒアリング、要件定義工程の一部として簡易的にやるべきで時間を掛け過ぎない事。
その後に要件定義、見積もりを終わらせ、それが終わった後の仕様追加、要望は別見積もりとする。
後から要望が出ない、変わらない様に最初の工程でクライアントの全て要望を引き出す事が必要。

トラブル予測

・ほとんどのトラブルは予測/対策できる
・あらゆるトラブルを予測/対策しておく事
・対策の立てようが無いものは無視
・金銭面のトラブルは会社として対応(ディレクターの仕事外)

設計

手段と目的

手段:WEBサイト構築
綺麗、派手、動く・・・
目的:効果(コンバージョン)
問い合わせ数UP、認知度UP・・・

提案は目的を達成できる根拠を備える必要がある。
目的を達成できる見込みのある提案をクライアントは断れない。
目的を達成できる見込みがある場合、後工程での仕様追加/変更は発生しない。

ターゲット設定

ペルソナ(架空のユーザー)
・年齢/性別/趣味
・普段使うアプリ
アプリの操作感(ボタンの大きさ等)の好みが決まる
・普段よく見るWEBサイト
・性格
系統
・王道:既存のペルソナを想定
・邪道:従来とは違うターゲットを設定

ターゲットを絞り込めない場合
・ペルソナ毎のランディングページを用意する
・複数のベルソナをターゲットにできるランディングページを作成する

ジャーニーマップ
・行動
・時間
を想定する

障害対策

対策

一覧

障害 対策名 内容
対策 フォールトトレラント 継続
フェイルソフト 機能縮小
フォールバック 縮退運転
フェイルセーフ 安全
フェイルオーバー 代替(自動)
スイッチオーバー 代替(手動)
フェイルバック 回復
フールプルーフ 誤作動防止
許容 フォールトアボイダンス 別対策

フォールトトレラント

障害が発生しても機能を継続させる設計手法
機能は縮小させない≠フェイルソフト
・電源の二重化
・ハードディスクのRAID
フォールトトレラントな具体的な手法としてフェイルオーバーがある。

フェイルソフト

機能縮小
障害発生時、自動的に機能を縮小させて稼働を維持させる機能
≠運用

フォールバック

縮退運転
障害発生時、機能を縮小させて稼働を維持する運用方法
≠機能

フェイルセーフ

障害発生時、システムを安全な状態へ移行させる機能
システム停止も許容する
・自動車の緊急ブレーキ
・Windowsの電源ボタン押下時のOS停止機能

フェイルオーバー

障害発生時、自動的に代替システムに機能を引き継がせて処理を続行させる仕組み。

スイッチオーバー

障害発生時、手動で代替システムに機能を引き継がせて処理を続行させる仕組み。

フェイルバック

フェイルオーバーした際の障害が回復した場合に処理を主系に戻す事

フールプルーフ

ユーザーの誤動作時、システムが危険が生じない、
またはそもそも誤った操作や危険な使い方ができない様な設計

フォールトアボイダンス

avoidance:逃避
障害に対して事前対策を取る事
・テスト
・教育

構成

ホットスタンバイ

同じ構成のシステム(ハード)を2台用意させ、片方を同じ動作をさせながら待機させる多重化方式
稼働側:主系、本番系
待機側:従系、待機系、予備系
主系→従系へ常にデータを同期させ、
障害発生時に従系にシステムが切り替わった場合にデータの欠損は無い。
コールドスタンバイに比較して同期処理の分、コストが高い
データベースサーバでは一定間隔での同期を行う場合でもホットスタンバイに分類される

コールドスタンバイ

同じ構成のシステム(ハード)を2台用意させ、片方を同じ動作をさせずに待機させる多重化方式
主系に障害が発生してから従系を稼働させる
同期処理を行わない為にコストは低い
データ同時実行性とは、多数のユーザーが同時にデータにアクセスできることを意味します。
データ整合性は、各ユーザーにデータの一貫したビューが表示され、その中にユーザー自身のトランザクションや他のユーザーのトランザクションによる参照可能な変更も含まれることを意味します。

障害

一覧

障害 分類
ハングアップ ソフトウェア
フリーズ ソフトウェア
アベンド ソフトウェア
クラッシュ ソフト/ハードウェア

ハングアップ

メモリの使用超過等によりプログラムの機能が停止。復旧の見込みが無い状態
プロセス自体は起動している

フリーズ

メモリの使用超過等によりプログラムの機能が停止。しかし復旧の見込みは有る状態
実際に復旧するかどうか分からない。
時間経過を待つ、他プログラムを終了させる等の処置を施す必要がある。

アベンド

Abnormal End
ソフトウェアの異常終了
クラッシュ
プロセスは終了

クラッシュ

ソフトウェアの異常終了、ハードウェアの障害

リスク

種類 内容 発生時
回避 発生原因を除去 発生しない
(回避しているので)
転嫁 対応を他に任せる

対応しない
(他が対応する)
軽減 発生確率を下げる
発生後のダメージを減らす

対応する
受容 発生した段階で対応する。
発生後のダメージを見込んでおく

対応する

UML

一覧

構造図 クラス図 クラスと関係によって、(クラスの)構造と(クラス間の)関係を表現する
オブジェクト図 システムのある時点でのスナップショット
振る舞い図 ユースケース図 システムのコンテキストと外部機能の設定
相互作用図 シーケンス図 相互作用するオブジェクトの時系列表現
コラボレーション図 オブジェクト集団における相互作用の直接表現やオブジェクト集団の接続トポロジーとメッセージ、スレッドの順序などを表現する
ステートチャート図
(状態遷移図)
1つのオブジェクトの生成から消滅までの状態遷移
=ライフサイクル"
アクティビティ図 1つのインタラクション全体における手続きの制御フロー。状態図の相対表現としてワークフローに焦点を当てる図
実装図 コンポーネント図 ソフトウェア-ユニット間の依存関係を示すもので、ソフトウェアモジュールの構成やバージョン管理も表現することができる
配置図 オブジェクトやパッケージ、ファイルなどを実際のプラットフォームやネットワークノード上のどこに配置するのか、さらにはどのプロセス上で実行するのか、といった物理的な視点でシステム構成を表現する
クラス図

クラス図」参照

ユースケース図

uml (1)

アクティビティ図

uml (2)

シーケンス図

uml (3)

ステートチャート

uml (4)

Excelでのフローチャートの書き方

フローチャートとは?

プログラムの流れを表した図
アルゴリズムやプロセスを表現する

Excelでフローチャートを書く

Excelでフローチャートを書くメリット

・環境に依存しない
 Excelさえあれば新規のアプリケーション等をインストールする必要が無い
 移動先等でも修正等を行える
・既存のExcelドキュメントに差し込める
・Excelの多彩な機能を利用できる

Excelでフローチャートを書くデメリット

・記号の数が少ない
・Excelの余計な機能が描画の邪魔をする

Excelで記述する場合の注意点

図と図を接続する
flowchart16
メリットの1つ「Excelの多彩な機能を利用できる」
これにより線は接続されたまま各図を動かして全体のレイアウトを調整できます。

ズレを矯正する
flowchart17
デメリットの1つ「Excelの余計な機能が描画の邪魔をする」
接続された線が真っすぐにならない事がよくあります。
デフォルトでは矯正できません。
「書式」タブを追加設定し、「ズレ」欄の値を0cmにする必要があります。
「書式」タブや「ズレ」欄の追加設定の方法はExcelのバージョンに依ります。

一覧

flowchart (1) 端子 フローチャートの最初と最後に使用
flowchart (2) 処理 計算や代入など
flowchart (3) 入出力 ファイルへの入出力
flowchart (4) 書類 プリンタなどへのデータ出力
flowchart (5) ループ開始 ループの始まり
flowchart (6) ループ終了 ループの終わり
flowchart (7) 判断 条件によって分岐(if分等)
flowchart (8) 結合子 ページ内で結合
flowchart (9) 他ページ結合子 他のページとの結合
flowchart (10) 準備 変数の宣言や初期値の設定等
flowchart (11) 定義済み処理 別に用意した処理を利用

判断記号のパターン

A=B

flowchart (13)

A>B

flowchart (14)

A=1、A=2・・・

flowchart (15)

flowchart (12)

データベース 排他制御

排他制御

データ同時実行性

多数のユーザーが同時にデータにアクセスできる事

データ整合性

通称「読取の一貫性」
各ユーザの更新が全てに反映され、各ユーザのデータ読み込み時に差が無い事
ユーザA:SELECT(長い時間が掛かる)
ユーザB:UPDATE(ユーザAのSELECT内容を変更)
ユーザA:SELECT終了→ユーザBのUPDATE内容は反映されない。
ユーザA:SELECT(長い時間が掛かる)
ユーザA:SELECT終了→ユーザBのUPDATE内容は反映されている。

デッドロック

(1)A:トランザクション開始
(2)B:トランザクション開始
(3)A:トランザクションでXテーブルのあるレコードをUPDATE
(4)B:トランザクションでYテーブルのあるレコードをUPDATE
(5)A:トランザクションで(4)のレコードをUPDATEしようとする→ロックがかかっているのでWAIT
(6)B:トランザクションで(3)のレコードをUPDATEしようとする→ロックがかかっているのでWAIT
→AB相互にWAIT=デッドロック
複数ユーザが同一トランザクションにおいて複数テーブルを続けて更新する場合に発生する。
デッドロック発生時のフローを設計しておく事が必要

ロックモード

モード SELECT 更新 複数設定 解除方法
共有ロック × Commit/RollBack
排他ロック × × × Commit/RollBack

共有ロック

ユーザA:共有ロック
ユーザB:共有ロック○、排他ロック×
読み取り○、変更×
データの読み込み時のロック
OracleのSelect ~ For Update は共有ロック

排他ロック

=占有ロック
ユーザA:排他ロック
ユーザB:共有ロック×、排他ロック×
読み取り×、変更×
データの書き込み時のロック
Insert、Update時 は排他ロック

ロックの種類

行レベルロック

対象行のみをロック
複数ユーザーがデータベースを扱う場合に効率良い運用を行える

表ロック

ロック名 呼称 対象 ロック方法
行共有 RS Row Share Row Share Select For Update
LOCK TABLE IN ROW SHARE MODE
行排他 RX Row eXclusive Row eXclusive Insert/Update/Delete
LOCK TABLE IN ROW EXCLUSIVE MODE
共有 S Share Share CREATE INDEX(VIEW、PROCEDURE、SYNONYM)
LOCK TABLE IN SHARE MODE
共有行排他 SRX Share Row eXclusive Row Share eXclusive LOCK TABLE IN SHARE ROW EXCLUSIVE MODE
排他 X eXclusive eXclusive DROP(ALTER) TABLE
LOCK TABLE IN EXCLUSIVE MODE

トランザクション分離レベル

TransactionIsolationLevel
トランザクションが複数同時に行われた場合に、どれほどの一貫性、正確性で実行するか?の4段階の定義
=分離レベル
=隔離レベル
=独立性レベル
4段階の定義
(1)非コミット読取り
READ UNCOMMITTED

(2)コミット読取り
READ COMMITTED

(3)リピータブル・リード
REPEATABLE READ

(4)シリアライズ可能
SERIALIZABLE

↑低レベル。不都合な読み込みが発生し易い。しかし速い。
↓高レベル。不都合な読み込みが発生し難い。しかし遅い。

 ダーティリード   ファジーリード   ファントムリード 
非コミット読取り
 READ UNCOMMITTED 
発生する 発生する 発生する
コミット読取り
READ COMMITTED
発生しない 発生する 発生する
 リピータブル・リード 
REPEATABLE READ
発生しない 発生しない 発生する
シリアライズ可能
SERIALIZABLE
発生しない 発生しない 発生しない

ダーティ・リード

変更されたがコミットされてないデータを読み込んでしまう事
A:データ更新(未コミット)
B:データ読込
A:コミット
→Bの読み込んだデータと更新された内容が違う
排他ロックを掛ける事で防ぐ

ファジーリード

non-repeatable read
=反復不可能読み込み
複数回の読み込み結果が異なる事
B:データ読込
A:データ更新
B:データ読込
→1回目の読み込み内容と2回目の読み込み内容が違う

ファントムリード

複数回の読み込み時における増減データ
B:データ読込
A:データ追加(削除)
B:データ読込
→2回目の読み込み時には1回目には無かったデータがある(あったデータが無い)

各データベースソフトにおけるトランザクション分離レベル対応表

 SQLServer   Oracle   Postgre 
 READ UNCOMMITTED  × ×
 READ COMMITTED 
 REPEATABLE READ  × ×
 SERIALIZABLE 

デフォルト設定

現場のアーキテクチャの話をしてみませんか?

概要

DevLove関西主催の勉強会

変化と依存

architecture2
・UIは理解しやすく、変化しやすい
顧客の担当変更により簡単に仕様が変わる。
DBの構造等は変わらない。
・Dataの変更はLogic・UIに影響する
UIの変更はLogic・UIに影響するとは限らない
・結論、データ、ビジネスロジックから開発し、UIは最後に作ると、
手戻りが少ない開発が行える。
・データ、ビジネスロジック、UI層を分化し、
UIの変化が他に影響しない構造を作る
レイヤードアーキテクチャー」参照

判断レベルの推移

architecture

アーキテクチャ哲学

・アーキテクチャは選択の集合体
・アーキテクチャ魂=自分ならコウする
しかし判断の根拠が必要。立場、役割、目的毎に
アーキテクチャの判断指標」参照
・トレードオフが必要。
しかし平均点は高くなくても良い。
一部の重点項目が良ければ他は要望を満たしてなくても良い場合もある
・目の前の要求に惑わされない
・未来に共感せよ
・アーキテクチャの目的は伝える事(未来へのバトン)
アーキテクチャで用いる図では1つの視点に集中する
他の視点は他の図で表す

・リスクに敏感になれ。しかしリスクを恐れない
・未来を感じろ。誰も教えてくれない。
・自分で感じた未来を信じろ

レイヤードアーキテクチャー

※=レイヤ化~/階層化~/多層~
処理を分類する

・OSI参照モデル
・MVC
MVCモデルにおいては
×:Controller > Model
○:Controller < Model
だが全てをModelに書くと大規模なアプリケーションでは結局分かり難くなる。
各層の責務(ルール)を決める
↓↑View(Routing)
 ※(1)ルーティング/認証/フィルタリング
↓↑Controller
 ※(2)HTTPリクエスト/レスポンス/バリデーション/Serviceの実行
↓↑Service
 ※(3)ビジネスロジック内容での検証/ビジネスロジック
↓↑Model
 ※(4)DBアクセス
・処理を分離する
(1)~(2)では文字の不正検証等のみを行い、
(3)ではビジネスロジックとしての検証を行う(在庫数や社員在籍有無等)

・流れを一方向に固定する
・クラス/メソッド名はドメイン用語
・ドメイン毎、ビジネスロジック毎に名前空間を分ける
・サービスから作る(その後→テスト→UI)

アーキテクチャの判断指標

 セキュリティ   性能   可用性   発展性 
 機能   ✔   ✔   ✔   ✔ 
 情報   ✔   ✔   ✔   ✔ 
 並行性   ✔   ✔   ✔   ✔ 
 開発   ✔   ✔   ✔   ✔ 
 配置   ✔   ✔   ✔   ✔ 
 運用   ✔   ✔   ✔   ✔