UML, We Will Miss You
統一モデリング言語 (UML) は、Rational Software によって開発され、1997 年に Object Management Group (OMG) によって標準として採用されました。 .
私の UML との関係の歴史は、IT とビジネスの架け橋としてこの言語の伝道者になったほぼ 10 年前に始まりました 。特定のソフトウェア製品をモデル化するための表記法としての UML の価値について、私はこれまで完全に確信していませんでした。私の目標は、UML を使用して、設計されたシステムに必要な構造的および動作上のプロパティを記述することでした。
私にとっての啓示は、UML アクティビティ図に関連する正式なセマンティクスでした。非公式の Visio の図には多くのあいまいさが含まれているため、我慢できませんでした。たとえば、長方形から出ている 2 つの矢印は、ストリームを選択または 2 つの平行なパスに分割することを意味しますか? 同様の例: 同じ長方形を指す 2 つの矢印は、最初のスレッドが長方形に到達した直後にアクションが開始されることを意味しますか? それとも、OR、XOR、またはANDですか？一般的に、あなたはポイントを取得します。UML は、明確で明確なセマンティクスを導入することにより、この問題を解決します。
ゲームは最初から不公平でした: 正解はありませ
ん.私は本当に私の心と魂を UML に注ぎました:
- 私は 2004 年から 2015 年にかけて、UML のみを使用して 7 人の異なる雇用主とクライアントのために、自分のソリューションの図を描きました。
- UML ( -) .
- , UML. Haskell GraphViz UML.
数年後の 2015 年頃、他の同僚や、最近相談したほとんどすべての Fortune 500 クライアントと同様、UML の使用を実質的にやめたことに気づきました。何が起こった？
私はそれが千切りによる死だったことを知っています。いいえ、UML は、その複雑さや厳密さのためにビジネス コミュニティを殺したわけではありません。対照的に、ビジネスパーソンは、いくつかの新しいシンボルを使用して、明確かつ明確にコミュニケーションする能力を愛していました。 IT 担当者は、UML を引き上げ (私はかつて、これを行いました)、UML を低下させました。
しかし、UML 自体は犠牲者ではありませんでした。率直に言って、UML は単なる担保損失です。真の虐殺は、ビジネス インテリジェンスとデザインを含む要件定義領域でした。アジャイルは殺人者となり、ユーザー ストーリーは彼の毒矢でした。
ユーザー ストーリーが入力に押し込まれ、デモ (または機能の生産リリース) が出力で受け取られるモデルでは、タスクの意味のある構造分析の余地はありません。
今日のすばらしい新世界では、理解が本番環境に対応したコードに直接結晶化します。実際、ビジネス モデリングでさえ、関連するアジャイル分野であるドメイン駆動設計 (DDD) によって殺されてきました。境界付けられたコンテキストは複雑さをカプセル化 (敷物の下に一掃) するため、企業は「ピザ 2 個のチーム」にまで拡大できます。 BDD を使用し、チームにCucumber の仕様を作成する必要がある企業 は、ここで優位に立っていますが、それを行う企業はほとんどありません。
現代のパラダイムでは、まだ問題を理解することはできません。デジタル トランスフォーメーションの専門家は、ユーザーがビジネス要件を事前に定式化するのではなく、ユーザー自身がビジネス要件を理解できるように、製品を本番環境にデプロイする必要があると言っています。これのおかげで、私たちはそれを正しくするためにいくつかの試みを行うことができます。はい、このパラダイムでは、すばやく何度も間違いを犯さなければなりません。
これが UML の欠陥ではないことはもうお分かりでしょう。私たちはビジネス分析と形式仕様をあきらめたばかりなので、新しい質問に直面しています。UML の代わりに何を使用するか?
マサラ ダイアグラムの例 C4 の
ような軽量のモデリング手法 を使用するものもありますが、現在使用されているほとんどのダイアグラムは、私が「マサラ ダイアグラム」と控えめに呼ぶタイプのもの です。結局、自分で作成した図を呼び出してみませんか?なぜマサラ？それらは非公式であるためです。それらは同時にいくつかの次元をカバーし、構造的、行動的、論理的および物理的です。多くの場合、それらは4+1 建築モデルのレンダリングの寄せ集めです 。
マサラ ダイアグラム
の作成方法 私たちの生活と財政が依存している何百万ドルものシステムは、これらのマサラ ダイアグラムから完全に作成、資金提供、実装されています。
「著者、そうですね、私の銀行の住宅ローンシステムのアーキテクチャは、あなたの恐ろしいマサラモデルに基づいて設計されたものではありません!」
それは真実ではありえないのですか？実際、あなたの銀行が CICS を使用しておらず、ソリューションが昨年販売された場合、非常にマサラの図に基づいて構築された可能性が高いです。
世界がおかしくなった？いいえ、ソフトウェアエンジニアリングをあきらめただけ です。今はただの コード ギャンブルです。ソフトウェアを書く人たち自身がエンジニアではないと言っているのではありません。多くの場合、そうではありません。ポイントではありませんことを 、組織レベルで、ソフトウェアはもはや設計された機械工学では、例えば、他の地域で行われているように、。ボーイングは、そのような非公式のマサラ図に基づいて、ロールスロイスにジェットエンジンを注文することは決してありません。
ただし、マサラ図には独自の目的があります。本来あるべき場所で使うと美しい。ご覧のとおり、 これらは仕様ではありません。彼らの目標は、感情を呼び起こすことです。マサラ図は、対象となるリーダーの心に喜びをもたらす必要がある場合に役立ちます 。
アジャイル陣営の友人たちとどんなに口論をしても、人々の幸せに目をつぶるわけにはいきません。私のクライアントや同僚は、より多くのマサラ図を求めているだけでなく、私が さらにマサラにすることを要求しています (そのため、より多くの建築的寸法をそれらに組み合わせることができます!)。なぜこれに抵抗するのですか？
UML は今でも私の心の中に残っており、いくつかのディメンションを使用してソリューションを構築し続けていますが、純粋なデータ/テーブルの形式です。グラフィック表記に関しては、ブレンダーと 5 リットルのスキレットを取り出して、お気に入りのクライアントのために素晴らしいマサラ チャートを作り始めます。
広告
Epic サーバーは 、Opencart の小さなオンライン ストアから大勢の視聴者を抱える本格的なプロジェクトまで、サイトをホストするための VDS です。数回クリックするだけで、独自のサーバー構成を作成できます! テレグラム チャットに
参加して ください。
