タグ

UMLに関するnanakosoのブックマーク (7)

  • UMLとかAWS構成図とかを描くツール

    UMLとか構成図とかの図を描くの何のツールを使えばいいか迷いませんか?私は迷います。 ですので、最近使っているツールを紹介します。 世の中にツールがイロイロあるのは理解した上で、大量に紹介するとやっぱり迷うので、似たようなツールや個人的に使わないツールはバッサリ省いています。 パワポで描く まずはPowerPointです。 エンジニア技術系の方は「パワポで図を描くのはちょっと、、、」と思われるかも知れませんが、状況によってありだと思っています。 パワポのメリット パワポは、ビジネスユーザーならほぼ誰でも使える システムを作る時に、お客さん側も含めた関わるメンバー全員がITに詳しいとは限りません。しかしそういう人にもシステムに対する理解は最低限していただく必要があります。システム構成図とか特に興味がない人に説明するときに「新しいツールをいれてください」というのはハードルが高いです。 パワポ

    UMLとかAWS構成図とかを描くツール
  • 結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ?と思ったときの選択肢 - Qiita

    自身のプライオリティによりますが、いくつか。 Markdownで幅広く再利用性を利かせたい、長期的に丁寧に版管理したい 自分自身の操作性、描きやすさと、見た目 俄然手軽に、短期的に、Onlineでいつでもどこでも いずれかという視点で考えると良いのかなと思い、並べてみました。 1. 長期的に: Markdownで幅広く再利用性を利かせたい、丁寧に版管理したいなら Markdownで描くことのメリットは再利用性。 将来的に追記・編集、自分以外の誰かが手を入れる可能性が高い。 現在のドキュメントだけでなく多種説明資料、媒体に転用する可能性がある。 ...という点で差分管理をしたいなら、以下。 VSCodeでPlantUML、Mermaid 上記参考で以下。 Alt+D でプレビュー起動。 Ctrl + Shift + P でコマンドパレットを起動し、出力。 png, svg, eps, pdf

    結局UMLとかシーケンス図とかAWSの図とかどれで描くと良いのよ?と思ったときの選択肢 - Qiita
  • 単一責任の原則(Single responsibility principle)について、もう一度考える | オブジェクトの広場

    単一責任の原則(Single responsibility principle)について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle:単一責任の原則 Open/closed principle:オープン/クロースドの原則 Liskov substitution principle:リスコフの置換原則 Interface segregation principle:インターフェース分離の原則 Dependency inversion principle:依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や

    単一責任の原則(Single responsibility principle)について、もう一度考える | オブジェクトの広場
  • Visual Studio Code ではじめるシーケンス図

    テキストでUMLやシーケンス図、クラス図などを作成できる言語です。 ダイアグラムをテキストで記述できるため、Gitで管理することもできます。 Visual Studio Codeでは、次のようにPlantUMLプレビューでダイアグラムを確認しながら作成できます。 まず、Visual Studio Codeが端末にない人はインストールをしてください。 Visual Studio Code – Code Editing. Redefined また、Javaもインストールが必要となります。 無料Javaソフトウェアをダウンロード インストールが完了したら、Visual Studio Codeで拡張機能としてPlant UMLを追加します。 Marketplaceから「plantuml」と検索してインストールします。 下のリンクからでもインストールできます。 marketplace.visuals

    Visual Studio Code ではじめるシーケンス図
  • Markdownテキストでシーケンス図とフローチャートを描く - Qiita diagram sequence

    つい先日、とあるシステムの処理の流れと一部処理のフローチャートを付けた見積り資料を書くことになり、ちょうど良い機会だったので、MarkdownでUML図表が描ける「StackEdit」を使って、オールMarkdownで資料を作成してみた。 いやぁ、打ち込んだテキストがリアルタイムに図表化されていく様は、とても新鮮で、そしてすごく面白かった。資料が出来上がった後の達成感というか、完成した図表を見た時の感動が結構はんぱない。技術系の資料作成でこんな良い体験ができたのは初めてかもしれんな…(笑) ──と、結構感動的な体験ができるMarkdownでのUML図表作成なんだが、せっかくなのでそれの書き方を含めてもう少し突っ込んだTIPSとしてまとめておこうかと思った次第。 Markdown+UML とは? とりあえず、「Markdown+UML」というのは私の造語だ。まぁ、正確に言うなら「UML di

    Markdownテキストでシーケンス図とフローチャートを描く - Qiita diagram sequence
  • PlantUML の使い方 | プログラマーズ雑記帳

    テキストから UML を生成する PlantUML についての解説記事を書いてみました。 PlantUML の使い方 (今回) シーケンス図 クラス図 オブジェクト図 パッケージ図 ユースケース図 アクティビティ図 状態遷移(ステートマシン)図 コンポーネント図 配置図 skinparam PlantUML 実行用のバッチファイル 今回は PlantUML の使い方の説明です。 PlantUML とは インストール 日語 コマンドライン Doxygen との連携 Doxygen 連携用スクリプト その他のツールとの連携 オンラインデモ PlantUML とは 最近、プログラムの設計書などで UML を使うのが浸透してきていますが、 この UML を書くのはわりと面倒です。 CASE ツール, Doxygen などでは、クラス図を自動生成してくれますが、 ユースケース図やシーケンス図は自分

  • 歴史的使命を終えつつあるUMLそしてオブジェクト指向: プログラマの思索

    Janet Gregory: 実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践) アジャイル開発におけるテスト管理、リリース管理、ビルド管理などの観点を詳しく解説したアジャイルテストの4象限の図は、とても分かりやすい。「アジャイル開発の質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス」と共に、Agile2.0時代においてアジャイル開発に関する必読の書籍の一つ。 ディーン・レフィングウェル: アジャイル開発の質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive) XPが出た2000年初頭に出現した初期のAgile開発では、その利点は受け入れられたものの、スケールアップが難しいなどの弱点を言われ続けて

    nanakoso
    nanakoso 2010/07/24
    別に図を書かなくてよくなったわけじゃないし。つまみ食いで役に立つならそれでよくね?じゃなければXHTML->HTML5みたいにシンプルな代替案を考えようぜ
  • 1