わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
AWS-PlantUMLで使える全AWSリソースの定義と画像表示 - Qiita
お題 PlantUMLという、ダイアグラムを独自のDSLで生成するツールがある。 （名前にUMLは付くもののUML以外にも、ワイヤーフレーム、ガントチャート、マインドマップ、ER図などさまざまなダイアグラムを生成できる。） そのPlantUMLの公式ライブラリとして、AWS-PlantUMLというものがあり、これを使うとテキスト形式のファイルでAWSリソースを使ったアーキテクチャ図を表現できる。 具体的には以下の通り。 1) 以下のようなPlantUML独自のDSLでテキストファイルを作る。 @startuml !define AWSPUML https://raw.githubusercontent.com/milo-minderbinder/AWS-PlantUML/release/18-2-22/dist !includeurl AWSPUML/common.puml !includ
リレーションシップ駆動要件分析(RDRA) - Qiita
リレーションシップ駆動要件分析(RDRA)とは？ 要件定義において、重要な要素が3つあります。 「網羅性」：システムの目的や、それを実現するための要件が漏れや重複無く定義されている 「整合性」：各要件の整合性が取れている 「表現力」：それぞれの要件が分かりやすく表現されている 複数の人間で共同作業する際にも、網羅性によって要件定義に必要な情報の枠組みが決まり、整合性によって作業の手順が決まり、表現力によって共通認識を確立します。 リレーションシップ駆動要件分析(RDRA)とは、要件定義において重要なこれらの３要素を高いレベルで実現するための要件分析フレームワークです。 RDRAでは要件定義を4つの構成要素に分け、UMLを拡張した表現方法で要件分析を行います。 よくあるように要件をリストでただ並べるのではなく、UMLの視覚効果を利用することで表現力を実現します。 要件定義についてはこちら↓
PlantUML Example for モデルベース要件定義テクニック - Qiita
PlantUMLはテキストの記述でUMLの図を描くことができます。オプション機能や組み合わせで色々な表現をすることができるので、UML を拡張した図が使われるモデルベース要件定義テクニックの書籍からいくつかのモデルを記述します。 書籍にはモデルの着眼点や解説が丁寧に記載されています。図の背景に興味がある方は合わせてお読みください。 コンテキストモデル ユースケース図でシステムの関係者を整理します。 left to right direction を利用すると図の方向を左から右に変更できます。 left to right direction actor 経営者 rectangle システムに直接関わる人 { actor 顧客 actor 営業 actor 物流 actor システム部門 actor オーダー部門 経営者 -- 営業 経営者 -- 物流 顧客 -- (商品販売サイト) 営業 -
Markdownテキストでシーケンス図とフローチャートを描く - Qiita diagram sequence
つい先日、とあるシステムの処理の流れと一部処理のフローチャートを付けた見積り資料を書くことになり、ちょうど良い機会だったので、MarkdownでUML図表が描ける「StackEdit」を使って、オールMarkdownで資料を作成してみた。 いやぁ、打ち込んだテキストがリアルタイムに図表化されていく様は、とても新鮮で、そしてすごく面白かった。資料が出来上がった後の達成感というか、完成した図表を見た時の感動が結構はんぱない。技術系の資料作成でこんな良い体験ができたのは初めてかもしれんな…(笑) ──と、結構感動的な体験ができるMarkdownでのUML図表作成なんだが、せっかくなのでそれの書き方を含めてもう少し突っ込んだTIPSとしてまとめておこうかと思った次第。 Markdown+UML とは？ とりあえず、「Markdown+UML」というのは私の造語だ。まぁ、正確に言うなら「UML di
plantUML の色をいい感じにする。 - ンンンパ
いい感じ（主観）にします。 結果です。 使用前 -> 使用後です。 フローのソースです ソースはこんな感じで、!include color.incの color.inc に設定しておいたスタイルを、ケツに<<hoge>>て具合につけると適用できます。 color.inc はこんなかんじ とくに一部だけを抜き出しましたが、各項目のケツにスタイル名をつけていくかんじです。 plantUML 便利 おきゃくさまに「図でわかりやすく説明してよ」と言われて図を用意しないといけなくなったんですが、追加削除を考えると Cacoo でやるのも結局変更めんどくさいし一緒だよねとテキストであれできるものを探していたらみつかったのが plantUML さん。 色の替えかたがわかってからはなにかと便利につかっています。 追記 色やフォントの設定名称はマニュアルの 10.3 Color に一覧があります。 plan
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Real World PlantUML
GitHub - Hywan/Database-to-PlantUML: Compile PostgreSQL and MySQL table information into a PlantUML description.