CentOS6.3+Apache2.4.2インストール

minimum+開発／ネットワーク系最低限インストールのCentOS6.3へApache2.4.2をソースからインストールする手順。

1. apr-1.4.6.tar.gzとapr-util-1.4.1.tar.gzをダウンロード
2. 上記をhttpd-2.4.2/srclib/に展開
　ディレクトリ名は、apr、apr-util
3. yum install pcre-devel
4. configure
./configure --prefix=/usr/local/httpd --enable-so --enable-ssl=shared --enable-proxy=shared --with-included-apr
5. makeとmake install

参考：
configureオプション
http://bitwalker.dtiblog.com/blog-entry-190.html
--
apr
http://satospo.sakura.ne.jp/blog_archives/tech/apache/centos6_apache241.html
--
pcre
http://blog.77jp.net/apache-2-4-2-インストール-手順-fedora-centos-ソース-コンパイル

備考：
system-config-firewall-tuiでポート解放

UMLによるオブジェクト指向モデリングセルフレビューノート要点

【書籍】
UMLによるオブジェクト指向モデリングセルフレビューノート　荒井玲子著

【要点】
・UMLモデリングの良書だったため、内容を忘れないようにまとめた要点
・基本的には書籍の要点とするが、一部オリジナルの表記あり
　→設計作業時の参照で自分で使い易くするため

■使用する図

　・ユースケース図
　・クラス図
　・シーケンス図

　・補足 - コラボレーション図、コンポーネント図

■ユースケース図

　・サービスとサービスの提供先を表す
　・サービスは機能ではない

■クラス図

　・静的モデル
　・モデル要素の構造を表す
　・クラスの構造、クラスどうしの関係を表す
　・必須モデル
　・分析のクラス図と設計のクラス図がある
　・情報量は、分析のクラス図 ＜ 設計のクラス図

■シーケンス図

　・動的モデル
　・モデル要素の振舞いを表す
　・クラスではなくインスタンスが登場する
　・分析のシーケンス図と設計のシーケンス図がある

■図の関係

　・ユースケース図１：シーケンス図N
　・ユースケース図１：VOPC(View of Participating Classes)図１
　・ユースケース図N：全体のクラス図１

■図の作成順

　ユースケース図→クラス図
　　１．ユースケース図
　　２．ユースケースごとのクラス図(VOPC図)
　　３．全体のクラス図

　ユースケース図→シーケンス図
　　１．ユースケース図
　　２．ユースケースごとのユースケース仕様書
　　３．ユースケース仕様書のフローごとのシーケンス図

■開発工程と図の関係

　要件定義
　　・機能要件に対してユースケース図とユースケース仕様書を作成
　　・非機能要件に対して非機能要件仕様書を作成

　分析
　　・機能要件に対して分析のシーケンス図と分析のクラス図を作成
　　・非機能要件に対してアーキテクチャのシーケンス図とアーキテクチャのクラス図を作成

　設計
　　・設計のシーケンス図と設計のクラス図を作成　※アーキテクチャを組込む

■開発工程

　要件定義
　　・焦点は仕様化
　　・要求を仕様として定義する
　　・曖昧性の排除、矛盾の解消
　　・実現性と重要度の適用
　　・機能要件と非機能要件を分けて定義

　分析
　　・焦点は問題領域の構造と振舞い
　　・要件を分析するのではなく、問題領域を分析する
　　・非機能要件から必要なメカニズムを検出して実現のための設計を行う

　設計
　　・How(どのように)を考える
　　・アーキテクチャを組込む

■UMLの部分適用

　要件定義のみに適用
　　・ユースケース図とユースケース仕様書を利用
　　・ユースケース図２：ユースケース仕様書８の割合い
　　・分析、設計、実装を非オブジェクト指向による場合や下流工程をアウトソーシングする場合

　分析のみに適用
　　・ユースケース図、ユースケース仕様書が必要
　　・分析のクラス図、分析のシーケンス図を作成
　　・保守案件時の問題領域の再分析

　設計のみに適用
　　・分析のクラス図が必要
　　・ソースコードから設計書を作成する(リバースエンジニアリング)場合にも適用可能
　　・リファクタリングにも適用可能

■UML以外のドキュメント

　・UMLだけでは開発できない
　・UML以外が適しているもの
　　・画面仕様書、画面設計書
　　・ファイル設計書
　　・データ遷移表(CRUD表)

■要件定義のユースケース図を検証

　・ユースケース数は50以下
　　・多い場合は機能分割になっていないか、複数の目的を持ったシステムでないかを検証

　・ユースケース名は動詞
　　・「アクター名」＋は＋「ユースケース名」で意味が通るもの
　　・「ユーザ」は「検索する」×→「ユーザ」は「書籍を検索する」○

　・設計の思考を含まない
　　・「XML文書からお気に入りCDを検索する」×→「お気に入りCDを検索する」○

　・アクターは役割を表す
　　・多くのアクターが同一のユースケースに関係している場合は検証(本当に必要なアクターか?)

　・ユースケースの切出し単位
　　・多くのアクターが同一のユースケースに関係している場合は検証(ユースケースを分割するべきか?)

　・アクターの切出し単位
　　・多くのユースケースが同一のアクターに関係している場合は検証(アクターを分割するべきか?)

■ユースケース仕様書の項目

　・ユースケース名
　・定義
　・アクター
　・前提条件
　　・前提条件を満たす場合にユースケースが実行される
　・事前条件
　　・事前条件を満たす場合は基本フローを通る
　　・事前条件を満たさない場合は代替フローを通る
　・基本フロー
　　・戻り点を記述する
　・代替フロー
　　・事前条件を満たさない場合のフローをすべて記述する
　　・アプリケーションレベルの異常系フローをすべて記述する
　　・基本フローの途中で分岐するフローをすべて記述する
　　・すべての代替フローの戻り点を記述する
　・事後条件
　・特記事項
　・未決定事項、仮決定事項

■ユースケース仕様書の用途

　・ユーザマニュアルのインプット
　・システムテスト仕様書のインプット
　・分析モデル(特に分析のシーケンス図)のインプット

■ユースケース仕様書のボリュームの目安

　・A4サイズ3～8枚

■分析のクラス図を検証

　・クラス名の適切さ
　　・名詞または形容詞＋名詞
　　・単数形
　　・問題領域で使われる用語
　　・機能名、～制御、～管理、～情報、は責務が曖昧となるためNG

　・属性の適切さ
　　・本当にそのクラスに必要か?

　・設計の思考が含まれていないか
　　・～IDという属性名がないか
　　・属性、引数、戻り値に型を定義してないか
　　・属性、操作に可視性を定義してないか　※分析では属性=プライベート、操作=パブリック

　・ロールの適切さ
　　・[A]-(ロール)[B]の場合、「A」は「ロール」が必要。「ロール」は具体的には「B」。と読めること
　　　[工事]-(許可機関)[市役所]の場合、「工事」は「許可機関」が必要。「許可機関」は具体的には「市役所」○

　・集約の適切さ
　　・集約は「全体」-「部分」の関係
　　・部分は独立して存在できるが、全体は部分がないと存在できない

　・クラスの存在意義
　　・属性が0または1つの場合は機能関数でないか検証
　　・アクセサしかない場合はエンティティクラス→分析では作成されない(設計の思考が含まれている)

　・クラスの独立性
　　・すべてのクラスが関連する巨大なクラスが存在しないか　→　分割の必要性を検証
　　・関係線が複雑でないか　→　小さいクラスを統合できないか検証

■分析のシーケンス図を検証

　・シーケンス図の単位
　　・ユースケース仕様書の基本フロー、代替フローの数と同じことを検証
　　・オブジェクトが３つ以上、メッセージ線が４本以上であることを検証

　・オブジェクトの独立性
　　・１つのオブジェクトから多くのメッセージ線が引かれていないことを検証
　　・メッセージの中継しかしていないオブジェクトがないことを検証

■分析から設計のクラス図作成

　・クラス図の分割単位
　　・オペレーション数が1～2の場合はクラスの必要性を検証
　　・オペレーション数が9つ以上の場合は複数の責務を負ったクラスでないか検証

　・パッケージの分割単位
　　・クラス数が5～9でない場合はサブパッケージへの分割の必要性を検証
　　・パッケージのツリーの適切性を検証(その親子関係は妥当か?)

　・コンポジット関連
　　・インスタンスの寿命が同じであること
　　・全体側の多重度が1であること

　・メッセージの引数
　　・3以下であること(4つ以上の場合はオブジェクト渡しの必要性を検証)

　・チェックオペレーション
　　・checkという単語を使用しない
　　・validate～(型の正当性)に修正
　　・verifecate～(値の妥当性)に修正

■分析から設計のシーケンス図作成

　・設計対象外
　　・アーキテクチャのクラス、サブシステムのオブジェクトには内部線を書かない

管理会計システム

[情報システム]
■経営分析(財務分析)システム

安全性分析、収益性分析、生産性分析、成長性分析などがある
B/S(貸借対照表)やP/L(損益計算書)の数字から過去と現在の状態を把握するもので、将来の予測をするものではない

■予算実績管理システム

当該年度予算を作成し、それを目標に行動をコントロールする
  ・総合予算を求める方法として損益分岐点分析を行う
  ・総合予算を製造原価、販売管理費、経費などに分割し、各部門へ配分する
  ・各予算にベースライン(時系列予算配分)を設定して月次計画へと詳細化する
  ・必要資金に対する資金調達計画(支払計画など)を作成する

■原価計算システム

製品の原価を求める計算を行う
□原価計算の目的
  ・財務諸表作成
  ・売価決定
  ・原価(コスト)管理
  ・予算作成

[キーワード]
■経営戦略室(経営企画室)

役員会、取締役会、経営会議などの意思決定機関による方向性から、実現可能性の検討・検証や具体的戦略の立案などを行う機関

■経営戦略

[入力]
  経営方針
[メソッド]
  経営目標設定
  事業環境分析
  主要成功要因(CSF)設定
  経営戦略実施・チェック・修正
[出力]
  中長期経営計画
  個別単年度計画

■SWOT分析

事業環境分析手法
http://www.atmarkit.co.jp/aig/04biz/swot.html

■主要成功要因(CSF)

http://www.atmarkit.co.jp/aig/04biz/csf.html

■コアコンピタンス

利益の源泉となる企業独自の技術
製品、サービス、管理、インフラなど
傾向としてコアコンピタンスに対する集中資本投下、それ以外の部門をアウトソーシングする戦略がある
http://www.atmarkit.co.jp/aig/04biz/corecompetence.html

■PPM

事業ドメイン(事業範囲)分析手法
http://www.atmarkit.co.jp/aig/04biz/ppm.html

■バランスト・スコアカード(バランス・スコアカード)

管理項目を4つの視点に分け、それぞれに測定指標と目標値を設定してその実現を目指す経営戦略
http://www.atmarkit.co.jp/aig/04biz/bsc.html

■損益分岐点

企業の利益ゼロ地点
費用(固定費+変動費) = 売上高となる地点

ITアーキテクト Vol.07

特集が「ドキュメンテーション完全ガイド」だったので購入した。
内容はドキュメント全般の簡単な説明とITアーキテクトが作成するドキュメント(要件定義書、システム方式設計書、ソフトウェア・アーキテクチャ設計書、データベース設計書)の書き方について。
個別のモデルや表の書き方が載っていて、参考になるといえば参考になるけど、
・ドキュメント全体のまとめ方
・下流設計書やソースコードとの整合性の取り方
が書いていなかった。
特にドキュメント作成ツールの紹介が欲しかったかな。

１冊通して目立つキーワードは「SOA」と「OSS」だった。