改行文字の有無判定と修正

与えられた文字列に対して、改行文字の有無を判断し、

改行文字がない場合は改行文字を追加するという関数を

作りたい。

★の部分で詰まる改行文字を追加しないといけないけどどうすればできる?

string使うとかはなし、古いコードでデバッグ文字に改行有無が混在しているため。

可能ならば、コンパイル時に処理が終了して、実行速度に影響がないと嬉しい

template<typename T, int N>
T*
SAMPLE(T(&x)[N])
{
　if (x[N - 2] == '\n')
　{
　　return x;
　}

　//constの場合はここでconstを外す
　types<T>::type y[N + 1] = { 0 };
　strcpy_s(y, N, x);
　y[N - 1] = '\n';

　return y;★
}

int main()
{
for (int i = 0; i<10; i++) {

::Sleep(1000);
::OutputDebugString(TEXT(SAMPLE("Hello!")));

}
return 0;
}

データベースについて

仕事で1年目にデータベースを使っていたけど、復習のために再勉強。

■主キー

DB上のデータのタプル(データ構造を示す組のこと→行ともいう)を一意に示すことができるキーをいう。複数の列(属性)で構成されうこともある。

・一意静制約

・非NULL制約

■候補キー

主キー候補となるキーを示し、行を一意に識別できる最小のキーの組をいう。

NULLでもいい。

■スーパーキー

行が一意に識別できるキーをいう。というか左記の条件を満たす属性の組み合わせは多すぎるから業務でつかったことなし。

例えば、属性が①～③まであって主キーが①ならスーパーキーは以下となる。

・①、①②、①③、①②③

UMTP L2合格しました

UMTP L2 合格しました。

以下の参考書の意味が分かっていれば合格できます。あとは黒本で過去問を2回位とけばいける感じ。

UML モデリングのエッセンス 第3版 (Object Oriented SELECTION)

UMLについて モデリング

 ■モデリングの種類

・ビジネスモデリング

システム化対象の業務(ビジネス)をモデル化する。主に業務の流れをモデル化には、アクテビティ図、業務用語からの関連データ抽出には、クラス図が利用される。

・要求分析モデリング

システムに対する要求をモデル化する。システムに対するユースケースごとの分析が主なため、ユースケースシナリオとユースケース図でモデリングされる。

・分析モデリング

ユーザー視点でシステム対象分野を分析してモデル化する。

・設計モデリング

実装者視点でシステム対象分野を分析してモデル化する。

UMLプロファイル

UMLプロファイルは特定ドメイン向けに、UMLの記法を拡張する拡張セットのこと。

以下の3つから提供される。

・ステレオタイプ

要素に具体的な役割を与える。«boundary»、«control»、«entity»などをつけると、その要素の役割がすぐわかるし、違う役割の要素もステレオタイプですぐわかる。

・メタ属性(タグ付き値)

コンテキスト固有の情報を与える。{abstract}、{ordered}など

・制約

UMLを見る全員が一貫した解釈をもてるように制約を与える。{XOR}など

UMLについて 2017/02/12

勘違いや間違いがあったので、備忘録...

・UMLに独自の図を追加して使うことはできない。

 UMLの仕様はOMG(Object Management Group：オブジェクト指向技術の標準化を行なう団体)が決めているので、この仕様にない図を使ったものはUMLとは認められない。

拡張をする場合は、UMLの仕様にあるメタ属性や制約、ステレオタイプで行う。この拡張のセットをUMLプロファイルという。

・UMLの図の種類

構造図：クラス図、オブジェクト図、パッケージ図、コンポーネント図、コンポジット構造図、配置図

振る舞い図：ユースケース図、アクティビティ図、相互作用図、ステートマシン図

なお、相互作用図は、更にシーケンス図、コミュニーケーション図、タイミング図、相互作用概略図が存在する。

以下Wikipediaにある図

・UnifiedProcess

以下のフェーズからできている

(1)方向づけ：対象システムが実現可能であるか判断する

(2)推敲：アーキテクチャを策定

(3)作成：製品レベルのシステムを作り上げる

(4)移行：利用環境に適応しているかの確認を行う

パッケージ図 その２

パッケージを描くときは、パッケージ間の依存関係を意識する。具体的には、単一方向に依存が付くような場合が望ましい。

例外はあって、Mapperパターンのデータマッパーなどは、データを管理する層とロジックの層の橋渡しをするため両方から依存が付く。

橋渡しでは、ロジック層で扱うデータをデータ保存するのに適した形に変換したりするので、両方から依存が付くのが自然で正しい。