タグ付けされた質問 「design」

現在、「ソフトウェア開発」の研究のために卒業に取り組んでおり、外部企業で複雑なソフトウェアを個別に開発する必要があります。これはすべて、構造化された方法で行われ、対応するすべてのドキュメントを作成する必要があります。 このプロジェクトでは、IEEE要件文書（ソフトウェア要件文書（SRS）、ソフトウェアアーキテクチャ文書（SAD）、ソフトウェア設計文書（SDD））を使用することにしました。別の方法で学校で教えられましたが、このプロジェクトでは、開発前に（代わりに）開発後にSDDを作成することにしました。私の推論は： 私がインターンシップを行っている会社は、実験的な方法で、特定の要件を満たす複雑なソフトウェアを作成するよう指示をくれました。プロジェクトの定義で彼らが私に与えた自由の量のために、事前にほとんど何も確実ではなく、開発プロセスの実験中に最もよく遭遇することができます。さらに、私はソフトウェアを個別に作成していますが、このソフトウェア設計を事前に行うことは、社内の他の誰にとってもメリットがありません。プロジェクトの不確実性により、事前に作成したデザインを大幅に変更する必要があることを確信できるため、事前にそれを行うと、後で変更するのにかなりの時間がかかります。これは逆効果だと感じています。 これは、開発後にSDDを作成する正当な理由ですか？そうでない場合、そのための正当な理由はありますか？ 編集：SDDを後で作成する理由は、将来の開発者がプロ​​ジェクトを継続するためです。私は卒業期間中にプロジェクト全体を終了することはできませんので、他の開発者は現在のコードベースを継続する必要があります。

11 design  documentation  software  iso 

私は非常に簡単な質問に苦労しています： 現在、サーバーアプリケーションで作業しています。例外の階層を作成する必要があります（一部の例外は既に存在しますが、一般的なフレームワークが必要です）。どうすればこれを開始できますか？ 私はこの戦略に従うことを考えています： 1）何が問題なのでしょうか？ 何かが求められますが、これは許可されていません。 何らかの質問があり、許可されていますが、パラメーターが間違っているため機能しません。 何らかの質問があり、許可されていますが、内部エラーのために機能しません。 2）リクエストを開始しているのは誰ですか？ クライアントアプリケーション 別のサーバーアプリケーション 3）メッセージ処理：サーバーアプリケーションを扱っているので、メッセージの送受信がすべてです。それでは、メッセージの送信がうまくいかない場合はどうでしょうか？ そのため、次の例外タイプが発生する場合があります。 ServerNotAllowedException ClientNotAllowedException ServerParameterException ClientParameterException InternalException（サーバーがリクエストの送信元を知らない場合） ServerInternalException ClientInternalException MessageHandlingException これは例外階層を定義するための非常に一般的なアプローチですが、いくつかの明らかなケースが欠けているのではないかと心配しています。私がカバーしていない分野についてのアイデアがありますか、この方法の欠点を知っていますか、この種の質問に対するより一般的なアプローチがありますか（後者の場合、どこで見つけることができますか）？ 前もって感謝します

11 design  c++  exceptions  stl 

契約は同一なので、これはJava SEとAndroidの両方に適用されます。 Java SEのCharSequenceドキュメント Android用CharSequenceドキュメント CharSequencecontains(CharSequence)メソッドを定義しません。私は理由を見つけることができないようで、それを含めることは非常に有用でありCharSequence#toString()、文字のシーケンスをチェックするために呼び出す必要を防ぎます。 例えば、Androidの中で、ユーザーが呼び出すことを余儀なくされているEditable#toString()にもかかわらず、それは文字の配列を含むかどうかを確認するためにEditable実装しCharSequenceた場合に回避することができ、CharSequence定義されましたcontains(CharSequence)。 この設計選択の背後にある考え方は何ですか？それは潜在的な見落としですか、またはこれには設計上の理由がありますか？

11 java  design  interfaces  android 

特定のユースケースがあり、インターネットを介してそれを行う3つの方法を見つけました。私はこれらの3つを見つめています。 私は何をすべきかわからないままそこに座る傾向があります-それから何もしません...選択する良い方法はありますか？それらすべてを試してみるべきですか？ 特定のコンテキストをより具体的にするために、ボードゲームグリッドを回転したり、グリッドにズームインしたり、このグリッド上のピースを移動したりできる画面の一部が必要な非常に軽量なボードゲームを作成しようとしています。私はこれを行う方法がわかりませんでしたが、Core Animation、Core Graphics、Sprite Kitのようなものをオンラインで見つけ、それらに対する賛否両論を見ました-たとえば、Spriteキットは高レベルですが、フレームレートを60に保ちます画面で実際に何も動いていない場合、バッテリーの無駄です。Core Animationは低レベルのAPIであり、「最高レベルの抽象化を行う」というAppleのガイダンスに反対しています。使用する3つのことを学びたくありません。1。選択してスタックを解除する方法はありますか？ ソフトウェアの分野全体に当てはまると思うので、これを意図的に漠然とした質問として残しています。

11 design  third-party-libraries  research 

私は次の用語についてかなり混乱しています。 ソフトウェアアーキテクチャ ソフトウェアアプリケーションアーキテクチャは、パフォーマンス、セキュリティ、管理性などの一般的な品質属性を最適化しながら、すべての技術的および運用上の要件を満たす構造化ソリューションを定義するプロセスです。さまざまな要因に基づいた一連の決定が含まれ、これらの決定はそれぞれ、アプリケーションの品質、パフォーマンス、保守性、および全体的な成功に大きな影響を与える可能性があります。（マイクロソフト） システムアーキテクチャー システムアーキテクチャは、システムの構造、動作、およびその他のビューを定義する概念モデルです。1アーキテクチャ記述は、システムの構造と動作に関する推論をサポートする方法で編成された、システムの正式な記述と表現です（wiki） クラス図 ソフトウェアエンジニアリングでは、Unified Modeling Language（UML）のクラス図は、システムのクラス、その属性、操作（またはメソッド）、およびオブジェクト間の関係を示すことにより、システムの構造を記述する静的構造図の一種です。（wiki） これらの説明を読んだ場合、これらはすべてアプリケーションの異なるモジュール間の相互作用を説明しています。しかし、これらの違いは何ですか？ これらの用語を比較するために私が考え/試みたもの： クラス図はシステムアーキテクチャの形式ではありません。上記の説明（structure, behavior, and more views of a system）は、アーキテクチャに実装の詳細が存在しないことを意味するのに対し、クラス図は実装を記述し、おそらくアーキテクチャではなく設計の方向にありますか？ ソフトウェアアーキテクチャはアプリケーション自体に焦点を合わせているのに対して、システムアーキテクチャは外部対話（データベースなど）も含むアーキテクチャだと思いますか？

11 design  architecture  class-diagram 

2000以上のマシンにデプロイされるjavaFxのUIを使用してシステムを構築します（最小は2000ですが、さらに多くなります-5000台のマシンに到達できます）。 他の理由/制限のため、マシンにインストールする必要があるため、Webブラウザーインターフェイスでは実行できません。 2000台以上のマシンは、異なる地理的ロケーショングループに属します。一般に接続は良好ですが、より多くの遠隔地ではそれほど良好ではない場合があります。 データベースに直接アクセスする代わりに、Spring + Spring Boot + Spring Data（java）を使用してRESTサービスクラスターを構築することを考えています。 RESTサービスはJsonを受け入れて返します。 私はそれが良い考えだと思う： サービスはデータベース接続プールとして機能します（データベースで2000以上の接続を行うと問題が発生すると思います）。 一部のクエリを処理するために、他の読み取り専用データベースへのログ配布を備えたデータベースを使用することができます。 より多くのマシンを追加してRESTサービスを実行できるため、スケーラビリティが向上します。 セキュリティおよび帯域幅節約の理由で、圧縮されたHTTPSを使用することができます。 2000以上のマシンを再デプロイせずに、ビジネスエンティティに集中的な変更を加えることができます。 他のシステムとの統合性が向上します（RESTサービスをポイントするだけです）。 それは本当に良いアイデアですか？ 肯定的または否定的な経験を共有できますか？ ありがとうございました。

11 java  design  rest  spring 

私は、製造現場のスケジューリングプログラムの作成をITに任せている製造工場で働いています（これは非常に必要です）。他の経験に基づいて、より少ない時間で利用可能な基本的なフレームワークを構築し、機能を追加することでその上に構築するか、完全に実装されたソリューションをすぐに作成して開始する方が良いでしょうか？私は約1年しかデベロッパーではなく、このサイズのアプリの初期作成の経験はあまりありません。私は、ある種のデジタルスケジュールが非常に必要なため、ベアボーンアプリが最初に行く方法であるという考えに傾いてきましたが、事実の後にランダムな機能を追加すると少し厄介になる可能性があります。あなたが同じ状況にあった場合、あなたはどの道に向かって傾くでしょうか？

11 design  theory  methodology 

複数の開発者がいる分散システムを含むソフトウェア開発プロジェクトでは、論理および物理アーキテクチャの図を作成することがベストプラクティスですが、私の経験では、これらの図は常にプロジェクトの開始時に適切に管理されていますが、プロジェクトのリリース時に更新されませんメンテナンスフェーズが開始されます。 多くの分散プロセスを持つ複雑なプロジェクトの場合、最初のリリースの前であっても、誰も知識を持っていないため、ダイアグラムはすぐに古くなったり不正確になったりする傾向があります。 このような背景から、コミュニティに次の質問をしたいと思います。 正確で最新の論理および物理アーキテクチャ図を作成することはどれほど重要ですか？ それらを最新の状態に保つのに役立つツールやプロセスはありますか？ それらを最新の状態に保つ責任は誰にありますか？システム管理者、開発者、QAチームはどのように貢献できますか？

11 design  architecture  testing 

特定のプログラム用のインターフェイスを作成しようとすると、通常、検証されていない入力に依存する例外をスローしないようにします。 よくあることは、次のようなコードを考えたことです（これは単なる例であり、実行する機能は気にしないでください（Javaの例））。 public static String padToEvenOriginal(int evenSize, String string) { if (evenSize % 2 == 1) { throw new IllegalArgumentException("evenSize argument is not even"); } if (string.length() >= evenSize) { return string; } StringBuilder sb = new StringBuilder(evenSize); sb.append(string); for (int i = string.length(); i < evenSize; i++) { sb.append(' …

11 design  design-patterns  programming-practices  performance  validation 

プログラムがオブジェクトのクラスを知る必要がある場合、通常は設計上の欠陥を示しているので、これを処理するための適切なプラクティスを知りたいと読みました。Circle、Polygon、Rectangleなど、さまざまなサブクラスを継承するShapeクラスを実装しています。また、CircleがPolygonまたはRectangleと衝突するかどうかを知るためのさまざまなアルゴリズムがあります。次に、Shapeの2つのインスタンスを取得し、一方が他方と衝突するかどうかを知りたいと仮定します。そのメソッドでは、どのアルゴリズムを呼び出すべきかを知るために衝突しているオブジェクトがどのサブクラスタイプであるかを推測しますが、これは悪いデザインや練習？これが私が解決した方法です。 abstract class Shape { ShapeType getType(); bool collide(Shape other); } class Circle : Shape { getType() { return Type.Circle; } bool collide(Shape other) { if(other.getType() == Type.Rect) { collideCircleRect(this, (Rect) other); } else if(other.getType() == Type.Polygon) { collideCirclePolygon(this, (Polygon) other); } } } これは悪いデザインパターンですか？サブクラス型を推測せずにこれをどのように解決できますか？

11 design  object-oriented  class 

アプリケーションには3つのレイヤーがあります。外部APIを提供するサービスレイヤー。ビジネスロジック用のBOレイヤー、およびデータベース接続用のDAOレイヤー。 ファイルを更新するたびに、フォルダ内の何か、たとえば「最終変更日」も変更したいとします。これは、トランザクションで実行する必要があります。成功し、ファイルとフォルダーの両方が編集されます。または、障害が発生し、トランザクションがロールバックされるため、両方のオブジェクトが以前の状態になります。 「ファイルが編集されたときにフォルダーを編集する」アクションは、純粋にビジネスロジックです。したがって、これはBOレイヤーに属していることを意味します。ただし、データベースにはObjectifyを使用しているため、トランザクションを開始するにはofy（）。transact（...）を呼び出す必要があります。BOレイヤーでこの関数を呼び出すと、ビジネスレイヤーでデータベース固有の呼び出し（Objectify）が発生するため、デザインが破損します。 この問題のクリーンなソリューションは何でしょうか？

11 java  design  design-patterns  transaction 

カーレースをシミュレートするJavaコードをいくつか見てきました。これには基本的なステートマシンの実装が含まれています。これは、古典的なコンピューターサイエンスステートマシンではなく、複数の状態を持つことができ、一連の計算に基づいて状態を切り替えることができるオブジェクトにすぎません。 問題だけを説明するために、Carの状態の定数（OFF、IDLE、DRIVE、REVERSEなど）を定義するネストされたenumクラスを持つCarクラスを取得しました。この同じCarクラス内には、更新機能があります。これは基本的に、現在の車の状態を切り替え、計算を行い、車の状態を変更する大きなswitchステートメントで構成されています。 私が見る限り、Cars状態は独自のクラス内でのみ使用されます。 私の質問は、これが上記の性質のステートマシンの実装を処理する最良の方法ですか？それは最も明白な解決策のように聞こえますが、過去には「switchステートメントが悪い」といつも聞いていました。 ここで見られる主な問題は、状態を追加すると（必要に応じて）switchステートメントが非常に大きくなり、コードが扱いにくくなり、保守が難しくなる可能性があることです。 この問題のより良い解決策は何ですか？

11 design  design-patterns  object-oriented  switch-statement 

BLがCRUDを実行するためにDAL（またはDALのインターフェース）のメソッドを呼び出す責任を負った3層アーキテクチャーよりも、オニオンアーキテクチャーにのみ利点があると思います。タマネギは、関心事、テスト容易性、保守容易性のより良い分離があり、よりきれいです。 だから、オニオンアーキテクチャはすべての面で本当に優れており、3層アーキテクチャは物事を行うための古い方法にすぎません。または、3層アーキテクチャを使用したい場合、いくつかのシナリオがあります。

11 design  architecture  layers  n-tier  onion-architecture 

現在、ユーザーに返されるページに基づいてサーバーロジックを調整する必要があることが多いwebappに取り組んでいます。 各ページには4文字のページコードが与えられ、これらのページコードは現在、静的な文字列としてクラスにリストされています。 public class PageCodes { public static final String FOFP = "FOFP"; public static final String FOMS = "FOMS"; public static final String BKGD = "BKGD"; public static final String ITCO = "ITCO"; public static final String PURF = "PURF"; // etc.. } そして、多くの場合、コードには次のようなコードが表示されます（1番目の形式）： if (PageCode.PURF.equals(destinationPageCode) || PageCodes.ITCO.equals(destinationPageCode)) { …

11 java  design  enum 

ユーザーは、実行に時間がかかる拡張技術操作を開始する場合があります。このような場合、通常、現在進行中のタスクに関する情報とともに、何らかのプログレスバーを表示すると便利です。 UIとロジックレイヤーの密接な結合を避けるために、通常、何らかのプロキシを介して通信を行うことが最善です。つまり、バックエンドは独自のUI要素を操作したり、中間層と直接対話したりすることはできません。 明らかに、これを機能させるためにはどこかにコールバックが必要です。通常、2つの方法のいずれかで実装しました。 可変オブジェクトをバックエンドに渡し、進行中にバックエンドに変更を加えます。オブジェクトは、変更が発生するとフロントエンドに通知します。 フォームのコールバック関数を渡すvoid f(ProgressObject)かProgressObject -> unit、バックエンドが呼び出します。この場合、バックエンドはを構築し、ProgressObject完全に受動的です。進行状況を報告するたびに新しいオブジェクトを作成する必要があると思います。 これらの方法の欠点と利点は何ですか？合意された最適な使用方法はありますか？それらの使用には異なる状況がありますか？ 私が見落としている進捗状況を報告するための完全に異なるテクニックはありますか？

11 design  object-oriented  gui