web-dev-qa-db-ja.com

ソフトウェアシステムをモデル化する場合と、すべてコードで実行する場合の利点は何ですか。

私が知っているほとんどのIT関係者は、コーディングの前にUMLまたは他のタイプのダイアグラムでソフトウェアをモデル化することが有益であると信じています。 （私の質問は特にUMLに関するものではなく、ソフトウェア設計のグラフィカルまたはテキストによる説明である可能性があります。）

よくわかりません。主な理由は次のとおりです。コードは嘘をつきません。コンパイラまたはインタプリタによってチェックされます。うまくいけば自動テストがあり、静的コード分析に合格する必要があります。モジュールが別のモジュールと正しくインターフェースしていない場合は、エラーメッセージが表示されるため、通常はコードで明らかです。

図やその他のドキュメントでは、これらすべてを行うことはできません。はい、UMLをチェックするツールはありますが、これまでに見たものはすべて非常に限られています。したがって、これらのドキュメントは不完全、一貫性がない、または単純な誤りである傾向があります。

図自体に一貫性がある場合でも、コードが実際にそれらを実装しているとは確信できません。はい、コードジェネレータはありますが、すべてのコードを生成することはありません。

モデリングへの執着は、コードは必然的に、建築家、デザイナー、または全体像を把握している他の有給の人々が対処する必要のない理解できない混乱である必要があるという仮定からの結果のように感じることがあります。そうでなければ、それはあまりにも高価になります。したがって、すべての設計上の決定はコードから離れるべきです。コード自体はスペシャリスト（コードモンキー）に任せる必要があります。スペシャリスト（コードモンキー）は、コードを書く（そしておそらく読む）ことができますが、他のことを扱う必要はありません。これは、アセンブラが唯一の選択肢であった場合におそらく理にかなっていますが、現代の言語では、非常に高いレベルの抽象化でコーディングできます。したがって、私はモデリングの必要性をこれ以上見ていません。

モデリングソフトウェアシステムのどのような引数が欠けていますか？

ちなみに、図はソフトウェアデザインの特定の側面を文書化して伝達するための優れた方法だと思いますが、だからといってbaseソフトウェア設計。

説明：

質問は不明確であるとして保留にされました。したがって、いくつか説明を追加しましょう：

私は、ソフトウェアをモデル化する（コードではない）ドキュメントをソフトウェア設計に関する主要な情報源として使用することが理にかなっているかどうかを尋ねています。私は、コードの大部分がこれらのドキュメントから自動的に生成されるケースを考慮していません。その場合、ドキュメント自体をモデルではなくソースコードと見なします。

私がこの手順のいくつかの欠点を挙げたので、（私の経験上）非常に多くの人々がなぜこれをソフトウェア設計の好ましい方法と見なしているのか不思議に思います。

designarchitectureumlmodeling
20
Frank Puffer

すべてをコードでモデル化する場合と比べて、ソフトウェアシステムをモデリングする場合の利点は、モデルをホワイトボードに収めることができることです。

私は1枚の紙でコミュニケーションの魔法を信じています。ホワイトボードにコードを配置しようとした場合、システムを新しいプログラマーに教えるときに、必要な抽象化レベルのコードがホワイトボードに収まらないだけです。

私はあなたが言及しているモデリングへの執着を知っています。なぜそれをしているのかを考えずに、それが以前に行われた方法だからです。私はそれを形式主義と呼んでいます。愚かさを伝統の背後に隠すのは難しいので、私は非公式に働くことを好みます。

だからといって、時々UMLスケッチを作成しないわけではありません。しかし、コードを書く前に、UMLドキュメントを提出するように要求するようなことは決してしません。 1人しか理解できないコードの存在には我慢できないので、5分ほどかかり、何をしているのかを説明する方法を見つける必要があるかもしれません。

ファウラーは、人々が彼が MLモード と呼んだUMLのさまざまな使用方法を特定しました。それらすべての危険なことは、それらが有用な仕事をすることから隠すために使用できることです。マウスを使用してコーディングする場合は、多くの試みが見られます。誰もが実際にそれを機能させるのを見たことがない。コミュニケーションのためにそれをしている場合は、他の人があなたを理解していることを確認してください。あなたがそれを設計するためにそれをしているなら、あなたはあなたが仕事をしているときに問題を見つけて修正するほうがいいのです。すべてがスムーズに進んでいて、ほとんどの時間を費やして矢印を素敵に見せたら、それを打ち消して作業に戻ります。

最も重要なのは、1日以上有効であると予想される図を作成しないことです。なんとかできれば、失敗しています。ソフトウェアはソフトであることを意図しているからです。何週間も費やして、図を正しく理解しないでください。何が起こっているのか教えてください。必要に応じて、ナプキンを使用してください。

とはいえ、私はUMLとそのデザインパターンを知っているコーダーを好みます。コミュニケーションが簡単です。図の作成はフルタイムの仕事ではないことを彼らが知っている限り。

23
candied_orange

ソフトウェアをモデル化する（非コード）ドキュメントをソフトウェア設計に関する主要な真の情報源として使用することが理にかなっているかどうかを尋ねています

いいえ、これは意味がありません。あなたのコードはあなたの主要な設計ドキュメント、すなわち「ソフトウェア設計に関する真実の主要な情報源」です。コンパイラーがその設計を採用し、そこからアプリケーションを作成するときのアプリケーションの動作を正確に記述するのはコードだけです。

ダイアグラムを補足的な設計ドキュメントとして必ず使用してください。ただし、コードから自動生成されない場合は、実際の設計とは異なるストーリーを伝えることに注意してください。 UMLがボートをフロートさせる場合は、それを使用します。そうでない場合は、別のものを使用してください。

一部の人々は、コードを書き始める前に、ダイアグラムの形で彼らの考えをスケッチすることは有用だと思います。しかし、ボブおじさんがこの件について言ったことを思い出してください。

"はい、そうです、図は時々不適切である可能性があります。それらが不適切な場合はありますか？それらを検証するためのコードなしでそれらを作成し、次にそれらを追跡するつもりです。図を描いてアイデアを探求することに何の問題もありません。 "

UMLを使用してデザインを探索する場合は、コーディングを開始するときに捨ててください。テストを作成してから、合格するためのコードを記述します。繰り返す。このようにして、検証済みのデザインが完成します。 UMLは、設計と同じレベルの検証を提供することはできません。

6
David Arno

ソフトウェアをモデル化した（非コードの）ドキュメントをソフトウェア設計に関する主要な真の情報源として使用することが理にかなっているかどうかを尋ねています。私は、コードの大部分がこれらのドキュメントから自動的に生成されるケースを考慮していません。この場合、ドキュメント自体をモデルではなくソースコードと見なします。

blueprintsのように、多くの非コードドキュメントが役立ちます。つまり、デザインの「真実」はこの方向に従う必要があります。これは、設計が満たさなければならない要素をモデル化する方法です。それらを要件ドキュメントと呼ぶこともできますが、これは、私が提供できるすべての例では多すぎる可能性があります。私は PlantText.com を介してPlantUMLを使用してこれらを生成しました。

  • ユースケース図は、目的の機能とユーザーまたは外部システムとの相互作用を示すことができます。 enter image description here

  • アクティビティ図は、ソフトウェアがサポートする必要のあるビジネスプロセスを示すことができます。 enter image description here

  • 状態図は、Webサイトで意図された動的を示すことができます： enter image description here

  • 一団の4つの設計パターンは、静的モデルと動的モデルとして提示されます。たとえば、メメント：
    enter image description here
    enter image description here

この手順の短所をいくつか挙げてみたが、なぜこれほど多くの人（私の経験上）が、ソフトウェア設計を行うのに好ましい方法だと考えるのか不思議に思う。

経験以外のUMLの使用に関する実際の情報に興味がある場合は、いくつかの調査が行われています（ペイウォール以外の記事へのリンクを見つけようとしました）。

5
Fuhrmanator

私が知っているほとんどのIT関係者は、コーディングの前にUMLまたは他のタイプのダイアグラムでソフトウェアをモデル化することが有益であると信じています。

あなたが知っているすべての人がこれを信じていることには異論はありませんが、それが必ずしも全体的に一般的であるとは思いません。 1970年に、Winston Royceは、ソフトウェア開発が設計とコードアクティビティの間にある程度の反復があることを知っていました。 1992年に、 Jack Reevesはコーディングが真の設計活動であることを書きました （また C2 Wikiで議論されています ）。

これは、人々がモデル駆動型開発ツールを作ろうとしたことを意味するのではありません。 UMLモデルからコードを生成しようとするツールがあります（クラス図だけでなく、さまざまな図のタイプをリンクして、それらからコードを生成します）。しかし、これらは、少なくとも私が見た限りでは、広く使用されているツールではありません。

これは、要件からコードの記述に直接進むべきだという意味でもありません。早期に正しく決定するために重要な特定の設計上の決定があり、ある程度のモデリングは、全員がオプションとその影響を理解し、コミュニケーションできるようにするために役立ちます。 これを「ソフトウェアアーキテクチャ」と呼ぶ人もいます（私を含む） 。

コードは嘘をつきません。コンパイラまたはインタプリタによってチェックされます。うまくいけば自動テストがあり、静的コード分析に合格する必要があります。モジュールが別のモジュールと正しくインターフェースしていない場合は、エラーメッセージが表示されるため、通常はコードで明らかです。

これは、アジャイルモデリングのいくつかの側面、特に 実行可能仕様 および 単一の情報源 の中心です。私は必ずしもTDDに同意するわけではありませんが、コードとそれに関連するテスト（単体テストから受け入れテストまで、できれば自動テストとしてキャプチャする）を単一の真の情報源とするという考えは良い考えです。

図自体に一貫性がある場合でも、コードが実際にそれらを実装しているとは確信できません。はい、コードジェネレータはありますが、すべてのコードを生成することはありません。

原則として、model-> codeから行くのは間違った方法だと思います。代わりに、コードはモデルを生成する必要があります。つまり、ツールはコードを調べて、エンジニアがテキストを書くときにさらに拡張できるグラフィックおよび表形式の表現を生成できる必要があります。そして、このコードからのモデルの生成は、ビルドおよびリリースプロセスのシームレスな部分である必要があります。

さまざまな程度で、さまざまな言語でこれをサポートするツールがあります。言語とパラダイムの性質を考えると、一部の人にとっては他の人よりも簡単です。

この手順の短所をいくつか挙げてみたが、なぜこれほど多くの人（私の経験上）が、ソフトウェア設計を行うのに好ましい方法だと考えるのか不思議に思う。

これらの人々がソフトウェア工学とソフトウェア設計を必ずしも理解しているとは思いません。これらの人々は、他のエンジニアリング分野が何をしているのかを見ていて、それをソフトウェアエンジニアがやるべきだと思うことにマッピングしていると思います。しかし、彼らは一つの大きな違いを無視しています。他のエンジニアリング分野では、最初にモデルとシミュレーションを作成します。これは、実際の製品を構築するのに非常に費用と時間がかかるためです。ソフトウェアエンジニアリングでは、設計の一部を取り、現実世界の環境でテスト可能な何かを非常に短い時間と非常に少ないコストで作成できます。経済は大きく異なります。

ソフトウェアシステムをモデル化する場合と、すべてコードで実行する場合の利点は何ですか。

非常に複雑なソフトウェアシステムを使用している場合、モデルを使用することは、理解しやすいものを使用することを意味します。これは抽象化のレベルが異なり、システムのさまざまな側面を人々が理解するのに役立ちます。これは、さまざまな利害関係者がソフトウェアシステムを概念的にすばやく簡単に理解できるようにするために、さまざまなモデリング言語とさまざまなタイプのモデルが各モデリング言語または表記法で許可されている理由の1つです。

5
Thomas Owens

私たちの開発者は画像を使用して私たちの世界を説明するのが大好きなので、ここに車の製造に関するものがあります：

  • 車は、コードと同じ生産チェーンの結果です（もちろん、導入プロセスを追加します）。
  • 車の設計書はソフトウェアの設計書と同じです。

私たちの世界では、設計ドキュメントを考案して作成する人が、コードを生成する人と同じである場合よりも、よく起こります。それは他の分野では真実ではありません。ただし、すべてを同時に行うことで、同じレベルの品質を実際に実現できるという意味ではありません。

最初にコーディングせずにそれらのドキュメントを作成することで（ファジビリティの概念実証などを除く...）：

  • あなたがやらなければならないことが簡単だとわかったら、コーディングする前に考えて、コーディングすることは確実です。
  • ソフトウェアの最も困難な部分に、より経験豊富な人々を集中させることができます。設計、アルゴリズム/数学は、非常に特定の目的（埋め込み、リアルタイム、アセンブリ）を除いてすべてです。
  • 経験の浅い人にはコーディングプロセスの大部分を委任でき、熟練した人は自分のスキルのレベルを必要とする最も重要な部分にのみ焦点を当てます。それらの経験の浅い人々はそれについて多くを学ぶでしょう。
  • 設計ドキュメントのイメージを介してIT以外の人と話し合うことができますが、コードしかなければ、何かを忘れるすべてのリスク（どこかに忘れられたリスナー...）コミュニケーションの詳細については、CandiedOrangeの回答を参照してください。
  • ソフトウェアを進化させる必要がある場合、何が影響するかをよりよく予測できます。
  • 設計により、ソフトウェアの一部を簡単に削減し、ソフトウェアの一部を同時に開発することができます。
  • コードを簡単にする前にテストをコーディングするTDDアプローチでは、それらのコーディング中にすべてのケースをカバーする必要があることについて頭痛を感じる必要がない場合、これらの反響ユニットテストを簡単に作成できます。
  • ...

注：これらの確認は、コードが実際にデザインを反映しており、どちらも最新の状態になっていることを前提としています...

0
Walfrat