Sparx Enterprise Architectでプロジェクトを準備しています。 私たちのレシピ

Habr様、Sparx Enterprise Architectでプロジェクトを準備するためのメモと基本的なレシピを共有することにしました。 さらに、プロジェクトとは、何らかの情報システムの作成を意味します。 あなたの前には、図の例、Enterprise Architectのプロジェクト構造、要件、設計、開発計画についての少しの説明があります。







出所

1.序文の代わりに

1.1。 始まりについて

むかしむかし、遠い、遠い銀河で...いいえ、そうではありません。 むかしむかし、先週の金曜日に、おそらく十分な単語、論文、個々のjiraタスクなどがあると判断したようです。 -より適切なものを使用する時が来ました。 すべてがクロスリンクで混乱していたため、歴史性といくつかのアプローチを維持するためのさまざまな方法で不便になりました。 エンタープライズアーキテクト（EA）の使用への旅が始まりました。 なぜそれで十分ですか？ 多くの理由があります。 プロセスの各参加者には、独自のものがあります。 主な理由は絶対的な力です。







ダースシディアスは影響分析を実施します。 依存関係は青で表示されています（映画「スターウォーズ：エピソード3-シスの復ven」のフレーム）



心に影響を与え、作成された情報システムの要素間の関係を理解するように全員を支配したいという意味での絶対的な力（広義の要素は、開発されて後で機能するだけでなく、使用される要件や仕様などでもありますシステムを作成する際に）理解するだけでなく、これらのつながりをすばやく見つけ、分析し、「1日で変更を実装でき、2週間必要な理由がわからない」顧客を表示します。



完全に公正な質問-「なぜ他のツールではなくエンタープライズアーキテクトを選択したのですか？」プロセスの開始時点で、資産にはjira、confluence、MS office、SP、Sybase Power Designer（現在はSAP Power Desiner）とSparxエンタープライズアーキテクト。 実際、質問は当時のEAの個人的な好みとスキル（2011〜2012年）、およびエンタープライズアーキテクトに心と思いを与えた先駆者である人々によって決定されました。 おそらくこれは間違いだった。

1.2。 ちょっとしたキャプテン

情報システムを作成するプロジェクト（および、一般に、おそらく各ステージの定義までのほぼすべてのプロジェクト）のライフステージの主な段階は、GOSTによると、単に常識に基づいて、非常に明白です。 これは：

1. コンセプト
2. スケッチ
3. 参照条件（要件の収集と識別）、
4. 技術設計（アーキテクチャ開発）、
5. 詳細設計（開発と設計）、
6. 実装
7. 操作とメンテナンス。

注：数字は説明のためのものです-ステージを組み合わせたり、明確な境界を設けたり、反復したりすることができます。



通常、すべてを迅速に、緊急に、非常に美しく行う必要があるため、概念については、まだEnterprise Architectを使用していません。 したがって、これは、さまざまな拡張機能または他の描画マシンを備えたvisioという言葉です（一般的には、美しさです）。 残念ながら、このスケッチは顧客の関心を引くものではありませんが、EAで作成することができれば幸いです。 最後の2つのポイントは、ミス（他の手段とツールによって（いずれにせよ）解決される）または改善に関するものであり、その後はすべてポイント3〜5で終わります。



したがって、参照条件（要件の収集と識別）、技術設計（アーキテクチャの開発）、詳細設計（開発と設計）などの段階について説明します。

1.3。 結果を試すのが待ちきれない人のために（ネタバレ）

コンポーネント（この場合、各コンポーネントは1つのデプロイメントモジュール）、それらの関係、基本プロトコルの図。







主な関係を示す、ノード別の一般的なソフトウェアの展開図

2.レシピについて

2.1。 成分

必要な基本的なものは次のとおりです。

• 不快感-情報システムを作成する現在のプロセスに満足している場合、すべてが自分に合っている場合は、既にEA（そのようなものかもしれません）を持っているか、それを必要とせず、すべてがうまくいきます。
• システムメタモデル-システムをどのように、どのような用語で説明するかを理解し、説明します。
• 形式言語-自然言語は、メッセージの意味を正確かつコンパクトに伝えるのにあまり適していません（私たちの意見では）。 そして、正式な言語が助けになります。 UMLを使用しました。
• エンタープライズアーキテクトの知識は少なくとも最小限ですが、バージョン管理、アクセス制御、1つのプロジェクトでの作業などの要望があればあるほど、EAのモジュールの開発に没頭することができます（まだありません）。

痛くありません：

• 忍耐と柔軟性。 曲げられない剛性は私たちのモットーではありません。 新しいアプローチの導入、古いアプローチのいくつかの重大な変更は困難です（特に初めて）。 多くの質問、間違い、慣性、完全な抵抗がありますので、個人的なレシピで我慢して妥協し、これを考慮する必要があります。 たとえば、EAが既に行われたことを文書化して保存するための単なるツールになるような例外的な状況については非常に落ち着いています。 さらに、要件のある作業の例で停止します。
• 健康的な怠inessとおいしいコーヒー。 怠inessは自動化できる多くのルーチンであるという意味での怠azine。 私たちの意見では、これは正しいです。 したがって、たとえば、最終的にドキュメントを書くのが面倒でした-EAから作成します。 確かに、これらはGOSTに準拠したドキュメントである場合があり、それから2段階で行います。最初はEAからの「肉」、そして勇敢なテクニカルライターがVBAスクリプトを使用してGOSTに変換します。 まあ、コーヒー-それなしで、もちろん、あなたはできますが、それなしでどこに？ 私たちは本当にJavaの種類が大好きです。

そうそう、私はほとんど忘れていました-私はまだ友好的で熱心なチームが必要です。 それなしではどこにもありません。 それだけです。

2.1.1。 不快感について

私たちにとって、これらは：

• さまざまなツール-1つが必要です。
• システムの説明に集中化が欠けている（どこかでナッツを隠し、どこかを忘れてしまったタンパク質のように振る舞うのをやめたい）のは、あらゆるものの1つの倉庫です。
• 影響を迅速に分析する絶対的な力はありません。コンポーネントを2つに分割した場合や、システムの動作シナリオの変化などがどうなるかを知りたいのです。
• 文書を書くのにうんざり-私は「クリック」と文書が欲しいです。

2.1.2。 メタモデルについて

私たちの意見では、意識的または無意識的に、何かを作成するプロセスに関与するほとんどすべての人々のチームは、それを作成するもの、それが何で構成されるか、それがどのように機能するかなどを伝えることができます。 プレゼンテーションの「穴」に関係しているとは限りません。 しかし、それでも、できます。 情報システムの作成も同様です。 最上位レベルでは、おそらく機能的な要件や他の要件、重要であまり明確で曖昧な要件、システム内のブロック、使用される基本的なテクノロジーなど、要件があることを想像するでしょう。システムが取り囲んでいること、これがどのように相互接続されているか。 要件と実装の原則の詳細、データ構造の説明などがあります。 これらすべての基本的な部分とそれらの間の通信の規則は、「メタモデル」と呼ばれます。







メタモデル。 美人！



私たちのレシピでは、メタモデルはスケーターに十分です-その輪郭の輪郭を描き、各部分をもう少し詳しく見てみましょう：

• 要件
• 情報システム構造
• ステージング
• デザイン。

2.1.3。 言語について

すぐにUMLを最も一般的なオプションとして選択したため、長い選択の苦しみを自慢することはできません。 まあ、「急いで」。 確かに、異なる言語と表記法のさまざまな組み合わせを使用することができ、おそらく、各部分に独自のメタモデルを選択することでこれに到達しますが、今のところ選択の苦痛と表記法と言語の交差の両方を喜んで免れています。

2.1.4。 エンタープライズアーキテクトの知識について

最初は知識がありませんでした。 もちろん、ある意味では、単独で作業する方法や単純なドキュメントを作成する方法については断片化されていました。 一般的に、振り返ってみると、あなたは私たちの認知症と自信と学習のスピードの勇気に驚いています。 それ以来、エンタープライズアーキテクトの深Architectにどんどん突っ込んでいますが、私たちはまだ新しい地平を発見しています。 現在、私たちは次の側面を所有しています：EAプロジェクトと要素の操作、バージョン管理、アクセス制御、ドキュメント生成。

2.2。 料理

そのため、不快感、メタモデル、正式な言語、エンタープライズアーキテクトの知識、フレンドリーなチーム、怠iness、コーヒー、忍耐、柔軟性があります。

次に、EAを取得し、その中にプロジェクトを作成し、メタモデルに従って構造を作成し、要素と接続を作成する必要があります。

私たちは試して-結果を見て、評価して-気に入って、さらに適用します。 気に入らなかった-メタモデルを修正し、要素や接続などを更新してから調理します。



気に入らなかったものを理解する方法は？ あなたはそれが好きではない、あなたはさらに不快であり、あなたは利益を感じない。 どういうわけか、非常に平凡で漠然としているでしょうか？ あなたは絶対に正しい、親愛なる読者です。 ただし、一般的なケースに対して非常に明確で厳密な基準を提案することは困難であり、おそらく必要ではありません。 しかし、もちろん、私たちは経験を共有します。

2.2.1。 プロジェクトについて（EAにあります）

Enterprise Architectのプロジェクトは、ルートパッケージのセットで構成されています。



同様に、各ルートパッケージには他のパッケージが含まれる場合があります。 そして、すべての通常のパッケージには要素（ここでは要素はEA要素）と図が含まれています。

ルートディレクトリは、EAPファイル内でローカルに配置することも、データベース内で中央に配置することもできます。 さらに、各パッケージはバージョン管理システムのリポジトリにxmlとして保存できます。



データベースにプロジェクトを保存することはできませんでした。 最初はクールでした-変更はすべての人に反映されていましたが、しばらくしてからミスをしたり、要素の消失などの奇妙な状況になったりしました。 その結果、私たちはそれを治療のために吐き出し、しばらく忘れていました。 しかし、バージョン管理システムを引っ張ってSVNをねじ込みました。



エンタープライズアーキテクトのプロジェクト



最も原始的なバージョンでは、メタモデルの主要部分をルートパッケージまたは第1レベルパッケージとして作成し、モデル要素とそれらの間の関係を格納するための構造を取得できます。 この例では、これらのパーツの一部が第1レベルのパッケージに分散しているため、少し複雑です。 しかし、一般的に、原則は追跡可能です。 さらに、SVNを「ねじ込む」ことで、「1つのパッケージ-1人の所有者」の原則に従ってブランチやリリース、アクセス制御を操作する機会を得ました。

2.2.2。 要件について

要件（EA要素として）は次のようになります。



電子的相互作用の要件の例



これは、UMLのEA要素の圧倒的多数です（そのため、見ました-残りを見ました）。



メタモデルは、要件の観点からはかなり退屈です-この部分は、より大きなクローズアップでは低くなっています。





一般に、特別なことは何もありません。要件を作成し、それを策定し、必要に応じて他の要件と関連付けます。 しかし、1つの「しかし」があります。アクティブな識別と収集の段階での要件は、EAには根付いていません。 そして、私たちはそれらを昔ながらの方法で-直接言葉にした。



なぜこれが起こっているのかと繰り返し疑問に思いました。 現時点では、次の結論に達しました。

• 私たちの顧客は言葉を愛し（そして私たちにとっては少し奇妙です）言葉と卓越性。 まあ、もちろん、プレゼンテーション（さらには美しいもの）。 彼らは他に何も見たくありません。
• 要件を作成し、非常に迅速に合意する必要がある場合、要件に関してEAを迅速かつ便利に使用する方法を学習していません。 しかし、私たちは成功するだろうと考えており、それに取り組んでおり、要件の次の段階がEAに行くことを期待しています。

すべての要件に同意するとすぐに、メタモデルの対応する部分でそれらをすぐにEAにアップロードしました。 そして、すべての要件の変更はEAのみを通過します。

2.2.3。 構造について

基本的な要件が組み立てられると、IPの構造、技術、コンポーネント間の通信、メタモデルのこの部分に応じた個々の技術的ソリューションなど、設計上の決定をスケッチし始めました。





このように起こった。 まだ存在しないソリューション用の図が作成されました。 このため、システムを記述する要素をEnterprise Architectプロジェクトに蓄積し、これらの要素が関係するソリューションを作成する際に、必要な図にドラッグして単純に再利用しました。 この場合、影響の分析に必要な接続が機能し始めます。



構造を説明するために、4つのタイプの図を使用しました-ユースケース、コンポーネント、展開、およびクラス（論理データモデルを説明するため）。 さらに、場合によっては、外部オブジェクト（図面、ファイル、リッチテキストドキュメント）を使用するEAの機能が使用されました。



たとえば、1つの物理コンポーネント（展開モジュールに相当）の説明がEAプロジェクトのダイアグラムとその関係でどのように見え、複雑なものではないかを以下に示します。

2.2.4。 プロダクションについて

基本的なソリューションが完成したら、プログラムコードの設計と開発を開始できますが、後者の場合は「開発ステートメント」が必要です。



このステートメントには、IPが機能またはシナリオ、詳細に関与するコンポーネントとメソッド、使用される論理データモデルのエンティティに関して、IPがどのように機能するかについての説明が含まれています。



念のため、以下では、システムの機能（ユースケースのピクトグラムとして説明）は、システムの特定の複雑なプロセスを意味します。たとえば、ユーザーから普通預金口座を開くためのアプリケーションを処理すると、いくつかのシステムまたは1つのシステムの一部間の相互作用の「重い」プロセスを隠すことができます。





この段階では、システムの機能が中心になります。 センター周辺で次の作品が作られています。

• 関数のスクリプトの仕様。
• スクリプトで使用されるアルゴリズム。
• アーキテクチャ要件-1つまたは別のステップを実装またはアルゴリズム化するときに遵守する必要がある制限。
• 論理データモデルの詳細化と改良。
• 物理データモデルの形成。
• コンポーネントの「ビジネスインターフェース」の形成-サブジェクトエリアの観点から重要な一連の操作。これらの操作は実装する必要があります。 ユースケースのアイコンによってメタモデルに示されるメソッドは冗長であることに注意する必要があります。したがって、関数のスクリプトの仕様のステップと対応するインターフェースをリンクします。
• 要素間の関係の明確化。

これらの作業の後、この情報を使用してコードを設計および開発し、テストしました。



転送プロセス自体はjiraを介して編成されます-タスクが作成され、ステートメントが配置されているEAプロジェクト内の場所とSVNブランチを示します。



ステートメントは次のようになります。

2.2.5。 設計について

設計には、基本クラス、ソフトウェアインターフェイス、パッケージ（Java用語）の説明、およびシステムの構造との関係が含まれます。



これに加えて、設計では、システム関数の実装を示すコンポーネントとクラス間の相互作用の順序があります。





レシピのこの部分は秘密にします。

3.結論の代わりに

レシピのやや混乱した手順を経て、EAのプロジェクトである料理を手に入れました。



一部の私たちのレシピは奇妙で、ばかげているように見えます。 誰かが自分で新しいことを学ぶでしょう。 誰かが料理を始めて結果に満足しますが、誰かはそうではありません。

そして、これは正常です-結局のところ、これは私たちのITキッチンのレシピにすぎません。



メモは敵意にとらわれず、建設的な批判と有益な質問があると確信しています。そこからレシピを修正し、Enterprise Architectの使用とHabréでの公開に関するメモを続けることができます。