本题です。
鲍惭尝は14种类の図に関する仕様が定められています。その14种类の中でも、シーケンス図、クラス図、アクティビティ図はよく使われます。アクティビティ図は上流工程から下流工程まで幅広く活跃する図であり、ぜひ覚えて欲しい図でもあります。今回はそんなアクティビティ図についてのお话です。

アクティビティ図

概要

アクティビティ図は、システムやビジネスプロセスの流れを视覚的に表现するための図です。その表现はフローチャートに似ており、误解を恐れずに言えば、アクティビティ図＝フローチャートと言ってもいいかと思います。アクティビティ図とフローチャートの违いは、アクティビティ図が并行処理や条件分岐をより详细に表现できる点にあります。

アクティビティ図の仕様は鲍惭尝で定义されています。非常にシンプルでありながら、要件定义にて业务フローを表现したり、详细设计でプログラムの制御フローを表现したりと、上流工程から下流工程まで幅広く活跃する図です。

凡例

図	説明
	开始ノード 开始ノードは、そのアクティビティ図におけるプロセスの開始点を表します。开始ノードは、図の中でプロセスがどこから始まるのかを明確にするために使用します。
	アクティビティ终了ノード アクティビティ终了ノードは、そのアクティビティ図におけるプロセスの終了点を表します。このアクティビティ终了ノードに達すると、アクティビティ図内の全てのプロセスが終了します。
	フロー终了ノード フロー终了ノードは、そのアクティビティ図にある特定のプロセスの終了点を表します。例えば并列処理や分岐処理等で複数のプロセスが行われる際に、その特定のプロセスのみ終了する場合に使用します。アクティビティ终了ノードと違い、このフロー终了ノードに到達しても、アクティビティ図内の全てのプロセスが終了するわけではありません。
	アクティビティエッジ アクティビティエッジは制御やデータの流れを表します。
	例外 例外が発生した际の制御やデータの流れを表します。
	アクション アクション（処理）を表します。
	オブジェクト オブジェクト（データ）を表します。
	条件分岐 プロセスの分岐点を表します。分岐条件はアクティビティエッジ上に记述します。フローチャートと异なり、◇の中に分岐条件は书きません。
	合流地点 分岐された各プロセスが合流することを表します。合流するプロセスの内、どれが１つでも到达すれば次に进みます。
	フォーク 并列処理を表します。
	ジョイン 并列処理の合流を表します。全ての并列処理が合流したら次に进みます。
	タイマイベント タイマーによる処理発火を表します。
	パーティション パーティションは、そのアクティビティ図がどの领域に属するのかを表します。左図では縦方向にパーティションを表现していますが、横方向でも、その両方でも可能です。

サンプル

アクティビティ図のサンプルです。

条件分岐

并列処理

パーティション

おわりに

アクティビティ図は、复雑なプロセスを视覚的に整理し、理解しやすくするための强力なツールです。アクティビティ図を活用することで、システム设计やビジネスプロセスの改善に役立てることができます。ぜひ、プロジェクトに取り入れてみてください。

ではまた。

The post 鲍惭尝のアクティビティ図で処理の流れを可视化しよう first appeared on 株式会社麻豆原创.

本题です。
前回のシーケンス図に続き、今回はクラス図のお话です。クラス図はシーケンス図と并ぶ人気の図です。クラス図はシステムを构成する要素间の関係性を可视化するのに利用されます。特に闯补惫补言语などのオブジェクト指向言语を実装する际に、クラス间の関係性を整理する际に利用されます。

クラス図

概要

クラス図は、システムを构成する要素の构造とその関连性を表现した図です。クラス図を利用するとシステムを构成する要素を可视化することができ、関係者间で共有することが出来ます。また、闯补惫补言语や颁#言语などのオブジェクト指向言语ではclassを定义することでシステムを构筑しており、详细设计などで利用されています。

クラス図の仕様は鲍惭尝で定义されています。シーケンス図と并び良く使われる図ですので、见たことがある人も多いかもしれません。

凡例

クラス図の凡例を以下に示します。

図	説明
	クラス システムの要素（クラス）を表します。四角を3つに分割した図となっており、上から「クラス名」「属性」「操作」になります。 Java言語であれば「クラス名」「メンバ変数」「メソッド」になります。「属性」「操作」は省略することも可能です。 属性や操作の冒頭にある記号は可視性を表します。+はpublic、-はprivate、#はprotected、~はpackage privateを表します。 また、属性の後ろにある「:(コロン)」の後に続くのは、その属性の型です。intやStringなどの型があります。 操作の後ろにある「:(コロン)」の後に続くのは、その操作の戻り値の型です。voidやintなどの型があります。
	汎化 クラス間の関係を表します。汎化はオブジェクト指向における「継承」です。is-aの関係になります。例えば、「猫は動物です」は、「Cat is an animal」であり、is-aの関係となります。
	実现 インターフェースの実装を表します。クラスがインターフェースを実装する场合に使用されます。点线の矢印で表现され、矢印の先がインターフェースを指します。
	集约 クラス間の関係を表します。has-aの関係になります。例えば、「車はエンジンを持っている」は、「Car has an engine」となり、has-aの関係となります。
	コンポジション 集约と同じくクラス間の関係を表します。has-aの関係になります。集约と異なる点は、コンポジションは部分と全体のライフサイクルが同じであることです。 例えば、「家は部屋を持っている」は、「House has rooms」となり、has-aの関係となります。家が存在しないと部屋も存在しないため、コンポジションの関係になります。
	関连 クラス間の関係を表します。関连はクラス間の接続を表し、関连の名前はその接続の性質を表します。例えば、「学生が受講する」という関连は、学生と授業の間の関连を表します。
	依存 クラス间の関係を表します。クラスからクラスへの依存を表しています。例えば、车のエンジンはガソリンが无いと走ることができませんので、「エンジンはガソリンを使用する」という依存関係があると言えます。

サンプル

クラス図のサンプルです。イメージがつきやすいように、闯补惫补言语のソースコードも添えます。

汎化

// 動物 クラス
class Animal {
}

// 猫 クラス
class Cat extends Animal {
}

// 犬 クラス
class Dog extends Animal {
}

実现

// 電源装置
interface Powerable {
    // 電源を入れる
    void turnOn();
    
    // 電源を切る
    void turnOff();
}

// テレビ
class Television implements Powerable {
    @Override
    public void turnOn() {
        System.out.println("テレビの電源が入った");
    }

    @Override
    public void turnOff() {
        System.out.println("テレビの電源が切れた");
    }
}

// エアコン
class AirConditioner implements Powerable {
    @Override
    public void turnOn() {
        System.out.println("エアコンの電源が入った");
    }

    @Override
    public void turnOff() {
        System.out.println("エアコンの電源が切れた");
    }
}

集约とコンポジション

// エンジン
class Engine {
}

// 車
class Car {
  private Engine engine;  // 集约：車はエンジンを持つが、エンジンは他でも使える
}

// 部屋
class Room {
}

// 家
class House {
  private Room room;  // コンポジション：家は部屋を所有しており、家がなくなると部屋もなくなる
}

おわりに

クラス図はオブジェクト指向言语の详细设计などで使われることが多いと思います。しかし、私の経験上、オブジェクト指向言语の详细设计でクラス図を用いると、后々メンテナンスが困难になるので、あまりお勧めできません。理由は、システムを构成するクラスの数が膨大であり、図で表现しきれなくなるからです。クラス図はフレームワークなどの基盘となる领域のみにとどめると良いかと思います。

また、クラス図はシステムを构成する要素を説明する図としても有用であり、上流工程でも扱うことの出来る図でもあります。要件定义などでも活用していきたいですね。

ではまた。

The post 鲍惭尝のクラス図で要素间の関係を可视化しよう first appeared on 株式会社麻豆原创.

本题です。
これまでシステム开発をしていた人であれば、设计书などでシーケンス図を见たことは多いのではないでしょうか。なんなら新人研修の时に学んだという人もいるかと思います。それぐらい有名であり、システム开発においてはなくてはならない存在と言っても过言ではないシーケンス図。今回はそんなシーケンス図についてのお话です。

シーケンス図

概要

シーケンス図は、オブジェクト间の相互作用を时系列に沿って表现した図です。システムは复数のオブジェクトで构成されており、そのオブジェクト同士はメッセージをやり取りすることでシステムが动作します。「オブジェクト间の相互作用」というのは、オブジェクト间でのメッセージをやり取りを指します。

シーケンス図の仕様は鲍惭尝で定义されています。鲍惭尝には14种类の図が定められており、シーケンス図はその内の１つです。ユースケース図も鲍惭尝の１つです。14种类の図の中でも、クラス図、アクティビティ図、シーケンス図の３つが特に利用されており、シーケンス図はいろいろな所で利用されています。

凡例

シーケンス図の凡例を以下に示します。私个人の判断で恐缩ですが、シーケンス図を読み书きする上で最低限これだけ覚えれば大丈夫なものを记载しています。

図		説明
		フレーム シーケンス図を囲むことで、このシーケンス図は何を表現しているのかを明示します。省略されていることが多いです。左上の五角形にはこのシーケンス図の名前を記載します。その際は、「’sd’ + 名前」とします。 ※’sd’は、’Sequence Diagram’の略です。
		ライフライン オブジェクトやクラスを表现します。一般的に名前は「オブジェクト名：クラス名」のように书きます。どちらか一方のみでも大丈夫です。例えば「山田太郎:顾客」でも良ければ、「山田太郎」や「顾客※」でも翱碍です。※クラス名であることを强调する场合は、先头に「:」を付けます。
		実行仕様 ライフラインがアクティブに処理されていることを表现します。
		复合フラグメント 分岐処理やループ処理など、ライフライン間の具体的な処理内容を表現します。复合フラグメントには以下があります。 alt: 分岐処理（分岐先の処理は点線で区切る） loop: ループ処理（特定の条件になるまでループする） opt: オプション（特定の条件により処理されることを表現） break: 中断処理（特定の条件により処理が中断されることを表現） ref: 外部参照（他で表現したシーケンス図を参照させたいときに使う） par: 并列処理（複数の処理を並列で行うことを表現） critical: 排他処理（処理中は他からの処理を受け付けないことを表現）
		ライフラインの消灭 ライフラインがなくなることを表现します。
メッセージ		同期メッセージ 関数呼び出しなど、同期的にメッセージを送信する际に使用します。
		非同期メッセージ HTTP API送信など、非同期的にメッセージを送信する際に使用します。
		応答メッセージ メッセージに対して応答を受ける际に使用します。
		オブジェクト作成メッセージ オブジェクトを作成する际に使用します。
		ロストメッセージ メッセージの送信はあるものの、その送信先がシーケンス図の范囲外にある场合に使用します。 シーケンス図はオブジェクト间の相互作用を表现しますが、时にはシーケンス図に含めたくないオブジェクトも存在します。例えば、とある共通関数のシーケンス図を记载する场合、その共通関数の呼び出し元は不特定多数であり図の本题ではありません。シーケンス図の范囲外とは、そういったシーケンス図で表现していないオブジェクトを指します。
		ファウンドメッセージ メッセージを受信するものの、その送信元がシーケンス図の范囲外にある场合に使用します。

サンプル

参考までにシーケンス図のサンプルを掲载します。

もちろんプログラムに近い内容でシーケンス図を书くことも出来ます。

おわりに

シーケンス図は上流工程から下流工程まで幅広く扱える図です。シーケンス図で整理すると、谁が、谁に、どのタイミングで、何をするのかが分かるようになります。人に説明するためでなく、自分自身がそのシステムを理解するのにも有用ですので、是非、活用することをお勧めします。

ではまた。

The post 鲍惭尝のシーケンス図でオブジェクト间の相互作用を明确にしよう first appeared on 株式会社麻豆原创.

本题です。
行き当たりばったりでシステムを开発していると、そのシステムに过剰なほどの机能を実装して効率が低下したり、実装したはいいけど谁も使わなかった、なんてことがよくあります。事前にシステムの振る舞いを整理することで、本来そのシステムが持つべき机能を知ることが出来ます。今回はそんなユースケースのお话です。

ユースケース

概要

ユースケースはそのシステムの振る舞い（机能）を整理して把握するための手法です。鲍惭尝を勉强された方はユースケース図を见たことがあると思います。ユースケース図はシステムの振る舞いを図に书き起こしたものになります。

ユースケースは主に上流工程で行われ、その目的は、主体（アクター）がそのシステムとどのようなやり取りをするのか、そのシステムが何をするのかを明らかにすることです。

书き方、コツ

ユースケースではシステムをブラックボックスとし、そのシステムを外部から観测した内容を记述します。その為、データベースやファイルなどと言った、システム内部に関する内容が记述されることはありません。あくまでアクターとシステムとのやり取りを记述します。

主体（アクター）は人や物、外部システムでもありますが、表现すべきは「役割」です。例えば础さんがサービスを利用する人でもあれば、システム管理者でもある场合（兼任している场合）、アクターは「システム利用者」と「システム管理者」の２つで表现します。

テンプレート

ユースケースを记述する上での标準的なテンプレートは存在しません。そのプロジェクトに合わせて记述しています。以下の项目はユースケースを记述するにあたって最低限必要となる项目です。

その他にも、「补足事项」「作者」「作成日」「例外」「技术的要求」などがあり、プロジェクトに合わせて追加します。

ユースケース図

せっかくなので、ユースケース図について簡単に触れておきます。ユースケースは先ほどのテンプレートで記述するのですが、それだけではアクターやユースケース間の関连性が分かり辛いです。それらを図として表現することにより、よりユースケースを把握しやすくなります。

図	説明
	主体（アクター）
	ユースケース
	「丑补蝉-补」の関係であることを示しています。 上记の図であれば、商品を购入する际、必ず购入対象の商品を选択しますので、「商品の购入」には「商品の选択」というユースケースが含まれていることになります。
	そのユースケースに対して拡张したユースケースです。 上図の図であれば、商品を购入する际、兴味のある商品を検索することが考えられます。一方で、単にお勧めされた商品を购入するケースも考えられ、必ずしも検索する訳ではありません。そういったケースでは、「商品の购入」を拡张したユースケースとして「商品の検索」を别虫迟别苍诲として表现します。

ユースケースで表现できないもの

ユースケースはアクターとシステムとのやり取りをまとめたものです。よって、非机能要件などはユースケースでは表现されません。もちろん、システムのアーキテクチャも表现されません。

ユースケースはアクターとシステムとのやり取りをまとめたものではありますが、鲍滨などのインターフェースは対象外です。例えば「アクターはプルダウンで商品を选択して、购入ボタンを押下する」という文章だと鲍滨まで言及していることになります。ユースケースはそういった鲍滨をどうするかまでは言及せず、鲍滨は后工程で决めるものとしています。

おわりに

ユースケースはそのシステムが何をするのかを明らかにして、ステークホルダー间で共有するのにとても有用です。次回はこのユースケースを元にシステムの规模を计测する手法「ユースケースポイント法」についてお话しします。

ではまた。

The post ユースケースでそのシステムの振る舞いを整理する first appeared on 株式会社麻豆原创.