ソフトウェア工学

システム開発ライフサイクル内で働く専門家、学者、学生向けのQ&A

1
ページング戦略:ページトークンとスキップ/開始インデックス
多くのアイテムを含む結果のページ間をユーザーが移動できるようにするために、ページトークンを使用する新しいAPIがますます増えていることを確認しています。ただし、APIデザイナーの観点からは、ユーザーがスキップしたいアイテムの数を指定できるようにする場合と比較して、トークンを使用する利点が何であるかは明確ではありません。 だからここに私の質問があります: 開始インデックスよりもページトークンを使用する利点は何ですか? 大まかに言えば、一般的なページトークンの実装では、どのようにしてページを追跡するのでしょうか。すべての結果をキャッシュすると、かなり非効率になります。ある種のハッシュを使用できると思いますが、結果を再構築するために何がハッシュされるのかわかりません。 ありがとうございました

3
ユーザーがREST APIで自分のリソースを変更/操作することのみが許可されることを承認するための最良のソリューション
バックグラウンド: 現在、REST APIを構築する過程で、ノードw / expressを使用しており、モバイルアプリと最終的には(最新のブラウザーベースの)Webサイトによって消費されます。 私は、ユーザーが自分のリソースを変更することのみが許可されるように、ユーザーの更新/アクション要求を承認する最良の方法を特定しようとしています。アクションは準高頻度で発生するため、懸念事項です。 注:この使用例では、エンティティーの所有権を譲渡することはできません。 可能なソリューション: 解決策:reddisなどのサーバーセッションで各ユーザーのリソースのリストを保存および維持します。 懸念事項:サーバー側セッションの永続化には、複数のサーバーに合わせて拡張する独自の複雑さのセットがあります。これもRESTに違反しています。詳細については、do-sessions-really-violate-restfulnessをご覧ください。 解決策: ユーザーの更新/アクションクエリの前に読み取りクエリを実行します。IEは私にこのユーザーのアイテムを提供し、リストにある場合は更新を続行します。 懸念事項: ユーザーがリソースに代わって操作するたびに追加の読み取りのオーバーヘッド。 解決策: ユーザーIDをdbレイヤーに渡し、それを更新条件付きの一部にします。または、ファンシーを取得したい場合は、データバックエンドに応じて、そのリソースに対してPostgresの行レベルのセキュリティなどを使用します。 懸念事項: リソースがリクエストしているユーザーのものかどうかを確認するには、リクエストのライフサイクルの少し遅いようです。エラーは、データバックエンドからずっと上にスローされる必要があります。同じように、認証とロールベースの承認はリクエストのライフサイクルの最初に行われることが多いので、少しずれているかもしれません。実装は、データバックエンドにも依存します。また、データバックエンドにビジネスロジックを示します。 解決策: クライアント側で一種のセッションに署名しました。JWTまたは暗号化/署名されたCookieを使用します。基本的に、ユーザーのリソースIDのリストを含む信頼されたセッションを維持します。 懸念事項: クライアント側セッションのサイズ。不要な場合でも、すべてのリクエストで送信されるという事実。複数のアクティブなセッション/クライアントの可能性を導入すると、メンテナンスが非常に複雑になります。リソースが別のクライアントに追加されたときに、クライアント側の状態をどのように更新しますか。 解決策: リソースがフェッチされるときに、署名された更新トークン(JWT)またはURLをリソースとともにクライアントに渡します。リソースが更新/アクションされたときに期待します。署名されたトークンには、ユーザーIDとリソースIDが含まれ、これらに対して簡単に確認できます。 懸念事項: リソースの所有権を譲渡できる場合は複雑になりますが、私の場合は問題ありません。更新前の読み取りよりも複雑になります。ちょっと変? 最終的な考え: 私は最後の解決策に傾いていますが、それが頻繁に発生することはないので、何か不足しているのではないかと思いますか?あるいは、私が知らないデザインパターンの一部かもしれません。

3
すべてのオブジェクトは自分自身を表示/描画する方法を知っている必要がありますか?
David Westは、著書Object Thinking(第10章、セクション1、サブセクション2)で、理想的なOO環境では、すべてのオブジェクトが要求に応じて自分自身を表示できる必要があると提案しました。人間向け(GUIとして)、非ネイティブコンポーネント(JSONやXMLとして)、またはその他の関係者向け: オブジェクト思考は、ビュー(インターフェイスとも呼ばれます)は、グラフィックまたはその他の方法で、オブジェクトが別のオブジェクトと通信するための手段であり、それ以上のものではないと言います。ビューの必要性は、オブジェクトが他のオブジェクト(通常は人間)またはアプリケーション(たとえば、プラットフォーム間で共有されているデータオブジェクトのXMLビュー)に対して「非ネイティブ」形式で表示される必要がある場合に発生します。 ビューが満たす必要のあるニーズとパラメーターの発見は、オブジェクトが参加するシナリオで明らかになります。オブジェクトがそれ自体を表示するように要求されるときは常に、その表示メッセージの送信者に適したビュー(表現)を使用する必要があります。たとえば、オブジェクトがそれ自体をインスタンス化しようとしている(それ自体の値を取得している)場合、そのオブジェクトのビューを、人間(または他のサービス提供オブジェクト)に暗黙の要求として値を提示する必要があります。ソフトウェアオブジェクトと人間のオブジェクトの間の仲介役として機能するGUIを構築する場合は、表示用にグリフを使用し、対話用にウィジェットを使用します。 しかし、どのグリフとウィジェットをGUIに含める必要がありますか?アプリケーションの実行中に当面のシナリオのシナリオを完了するために必要なもののみ。この視点は、アプリケーションからGUIを定義することを示唆しているため、ほとんどの開発者にとって直観に反しています。 例として、醸造所を考えてみましょう。片側にはビールが入ったバットがあります。ボトルウォッシャー、フィラーステーション、キャッピングマシン、パッケージアセンブラーで構成される複雑な生産ライン。その上にあるのは、醸造所を監視し、人間の管理者にステータスと問題を通知するコントロールステーションです。従来の開発者は、コントロールパネルの観点から「醸造所管理システム」の分析と設計を開始する可能性があります。これは、インターフェースからの設計に似ています。 オブジェクト思考は、代わりに、どのオブジェクトが醸造所とそのすべての無数の機械の主要な顧客であるかを検討することを示唆します。誰のために、機器の複雑な迷路が存在しますか?ビジネスの正解は、もちろん「お客様」です。しかし、オブジェクトの考え方をより反映した答えは、「ビール」です。すべてのシナリオは、ビールの観点から書かれており、キャップを付けて、ボトルに入れられ、パッケージに入れられ、トラックに常駐しています。コントロールパネルは、醸造所の状態の受動的な観察者5です。ある時点でビールに問題が発生した場合、介入サービスを要求するメッセージをコントロールパネル(またはマシン固有のコントロールパネル)に送信することにより、オペレーターの介入を要求するのはビールの責任です。 このパースペクティブは、GUI設計を簡素化し、さらに重要なことに、コントロールパネル(GUI)のパースペクティブから設計するときに必然的に発生すると思われるマネージャーおよびコントローラーオブジェクトのホストを排除します。 オブジェクト指向の世界の初心者から来る:これは本当にそうでしょうか? 自分自身を表現する方法を知っているオブジェクトがあれば、ウェストが彼の本で繰り返し言ったコントローラー/マネージャーオブジェクトの数を減らすことができます。しかし、この「ルール」を守らないとSRPが破られますか? また、(それが事実であることが判明した場合)、たとえばAndroidアプリケーションでの典型的な実装を考えると、どうすればこの種の目標を達成できるでしょうか?私たちが作成するすべてのオブジェクトは、それ自体をとして提示する方法を知っている必要がありViewますか?

5
Javaまたはその他のプログラミング言語での構成可能な同時実行性
SoftwareとConcurrency Revolution(htmlバージョン)という名前の並行性に関する研究論文を読んでいたとき。私は次の行に出くわしました: 残念ながら、ロックは機能しますが、最新のソフトウェア開発にとって深刻な問題を引き起こします。ロックの基本的な問題は、ロックが構成可能でないことです。正しいロックベースのコードを2つ取り、それらを組み合わせて、結果がまだ正しいことを知ることはできません。現代のソフトウェア開発は、ライブラリをより大きなプログラムに構成する機能に依存しているため、ロックベースのコンポーネントを、その実装を調査せずに構築することは困難です。 私は、Javaがどのように構成可能な同時実行性を保証するか、あるいはこのシナリオを生成する方法があるかさえ考えていました。 また、1つ以上のライブラリのデータをどのように同期させることができますか?プログラマーは自分のプログラムからそれを行うことができますか、それとも物事を同期させるのはライブラリ次第です。 Javaでない場合、ロックベースの同時実行を使用し、構成可能な同時実行を保証する他の言語はありますか? 以下も同じ論文から引用したものです。 同期メソッドには少なくとも3つの大きな問題があります。1つは、他のオブジェクト(Javaのベクターや.NETのSyncHashTableなど)の仮想関数を呼び出すメソッドを持つ型には適していません。ロックを保持したままサードパーティのコードを呼び出すと、デッドロックが発生する可能性があるためです。第2に、同期されたメソッドは、すべてのオブジェクトインスタンスのロックを取得および解放することにより、多くのロックを実行する可能性があります。第3に、プログラムがオブジェクトまたは異なるオブジェクトに対して複数のメソッドを呼び出すときに原子性を維持しないため、同期化されたメソッドはロックをほとんど実行できません。後者の簡単な例として、銀行振込を考えてみましょう。account1.Credit(amount); account2.Debit(amount)... 注:論文は2005年9月に発行されました

3
設計:データベースの変更が原因で下位互換性が失われないようにする方法
これは私のシナリオです、私はこのインターフェースを持っています: public interface hitTheDataBase { public void insertMe(String [] values); public void modifyMe(String [] values); public DataTable selectMe(); } そして、私はインターフェースを実装するこれらの2つのクラスを持っています: public Class hitSqlServer implements hitTheDatabase { public void insertMe(String [] values) { executes insert into table_in_sqlServerBD (col1, col2) values(values[0], values[1]) } public void modifyMe(String [] values) { executes update table_in_sqlServerBD …

2
タスク/プロジェクトの複雑さを見積もるときに、上司(または同僚)をより注意深くするにはどうすればよいですか?
私はソフトウェア開発者で、小さなWeb開発会社で働いています。なかなか時間がかかるとミドルマネージャーから聞かれるのはよくあるテーマのようで、見積もりを出すと高すぎると思います。それがより技術的なマネージャーまたは別の開発者である場合、彼らは通常、自分自身の見積も​​りをすでに心に留めており、より速く実行できると考えているため、独自の方法でそれを実装しようとします。 ただし、他の開発者が見積りよりも大幅に多くの時間を費やしてしまう傾向があります。彼らは予算の半分を経て、実装計画では適切に対応できないビジネス上のニーズがあることを認識します。たいていの場合、私の計画はこの必要性に対処するはずでしたが、「あなたはそれを必要としない」機能として肩をすくめられました。 さらに悪いことに、彼らがこの壁にぶつかったとき、彼らは通常、彼らが自分たちが描いたコーナーから抜け出すのを手伝うために私のところに来ますが、私の一日にはほんの数時間しかありません。 最良の場合:これらの中断は、自分の開発作業に割り当てた時間に割り込んだため、他のプロジェクトが遅れたり、「Xを実行できる唯一の人」であるため、残業しなければなりません。 最悪の場合:私は自分でタスク/プロジェクトを引き継ぐ必要があり、その時点では予算に「私の」やり方でそれを行う時間は残っていません。彼らが始めた方法で彼らが始めたものを終わらせなければならないので、「会社はこれ以上お金を失うことはありません」。「私の」ハッキーコードになるので、これはいつも私に噛み付きます。それが壊れると、なぜそれがそのように作成されたのか、人々は私に尋ねます(結局のところ、誰が実際にそれを作成したのかわかりません)。 ですから私の質問は次のとおりです。物事が想像しているほど単純ではなく、クライアントのニーズに対する理解を再評価する必要があるときに、これらの同僚がどのように理解できるようにすることができますか? [既存の]技術的負債に対処するための経営陣の説得に関するこの同様の質問とは異なり、私の質問は、それが最初から起こらないようにするために、チームが技術的負債を負おうとする前に[積極的に]実現するのを助けるための戦略を求めています。これら2つは密接に関係していますが、私の考えでは明らかに異なります。他の質問の答えは、将来の機能の見積もりにリファクタリング時間を追加することを提案しています。他の開発者(したがってマネージャー)が、将来の機能は実際よりも時間がかからないといつも考えている場合、これは決して機能しません。また、私の見積もりがより現実的であると彼らに納得させることができません。

2
DDD:再利用可能なモジュールとサービスタイプの区別(ドメイン、インフラストラクチャ、アプリケーション)の作成
したがって、「Vaughn Vernonによるドメイン駆動設計の実装」を読んだ後、コアドメインの概念と思われるものを個別のモジュールに分離することにより、再利用性を高めるためにコードをリファクタリングすることにしました。 各モジュールには、ドメイン、インフラストラクチャ、アプリケーション/プレゼンテーションレイヤーを含む独自のアーキテクチャレイヤーのセットが含まれています(ヴォーンの推奨に従って、アプリケーションレイヤーの責任をルート、MVCコントローラー+テンプレートに存在するテンプレートからさらに分離することにしましたプレゼンテーション層)。 これらの各レイヤーを独自のパッケージ内に配置することにしました。各パッケージは、その下のレイヤーを依存関係として参照しています。つまり、プレゼンテーション層はアプリケーション層に依存し、アプリケーションはインフラストラクチャに依存します。リポジトリはドメインの一部であるため、各リポジトリインターフェースはドメイン層/パッケージ内に存在し、実装はインフラストラクチャ層/パッケージ(Doctrine 、など)。 この方法でコードを再構築することで、アプリケーションレイヤーをスワップアウトし、複数のWebアプリケーション間でドメインを再利用できることを願っています。 最終的にコードは再び形を整え始めているように見えますが、それでも私を混乱させるのは、アプリケーション、インフラストラクチャ、ドメインサービスのこの違いです。 ドメインサービスの一般的な例の1つは、パスワードのハッシュに使用するものです。ユーザーエンティティは、ユーザーの資格情報を格納するために使用される可能性のあるさまざまなハッシュアルゴリズムに関与する必要がないため、これはSRPの観点からは理にかなっています。 そのことを念頭に置いて、私はこの新しいドメインサービスを私のリポジトリと同じように扱いました。ドメインでインターフェースを定義し、実装をインフラストラクチャ層に任せることにより。しかし、私は今、アプリケーションサービスで何をすべきかについて考えています。 現在のところ、各エンティティには独自のアプリケーションサービスがあります。つまり、ユーザーエンティティにはアプリケーション層内にUserServiceがあります。この場合のUserServiceは、プリミティブデータ型の解析と一般的なユースケース「UserService :: CreateUser(string name、string email、etc):User」の処理を担当します。 私が気になるのは、アプリケーション層を交換することにした場合、複数のアプリケーションにわたってこのロジックを再実装する必要があるという事実です。だから私はこれが私の次のいくつかの質問につながると思います: ドメインサービスは、インフラストラクチャレイヤーとモデル間の抽象化レイヤーを提供するために存在する単なるインターフェイスですか?例:リポジトリ+ HashingServicesなど 私はこのようなアプリケーションサービスを持っていると述べました: Access / Application / Services / UserService :: CreateUser(string name、string email、etc):User メソッドシグネチャは、プリミティブデータ型の引数を受け入れ、新しいユーザーエンティティ(DTOではない!)を返します。 これは、ドメインレイヤー内で定義されたいくつかのインターフェイスの実装としてインフラストラクチャレイヤーに属しますか、それともプリミティブデータ型の引数などにより、実際にはアプリケーションレイヤーがより適切ですか? 例: Access/Domain/Services/UserServiceInterface そして Access/Infrastructure/Services/UserService implements UserServiceInterface 個別のモジュールが一方向の関係をどのように処理するか。モジュールAは、モジュールBのアプリケーションレイヤー(現在行っているように)またはインフラストラクチャの実装(個別のインターフェイスを介して)を参照する必要がありますか? アプリケーション層サービスには別のインターフェースが必要ですか?答えが「はい」の場合、それらはどこに配置する必要がありますか?

7
単一の日付と日付範囲の両方を表すことができるプロパティ:適切にモデル化する方法は?
私は2つの方法で「送料見積もり」を表すことができるシステムで働いています。 特定の日付:アイテムはその日付で出荷されることが保証されています 日間隔:アイテムは今日から「X to Y」日で発送されます モデルに関する情報は、意味的には同じで、「発送予定」です。配送見積もりの​​情報をシステムから取得すると、見積もりが最初の形式か2番目の形式かがわかります。 このための現在のモデルは次のようになります。 class EstimattedShippingDateDetails { DateTime? EstimattedShippingDate {get; set;} Range? EstimattedShippingDayRange {get; set;} } Range 整数の「始まり->終わり」をラップする単純なクラスです。 struct Range { int Start {get; set} int End {get; set} public override ToString() { return String.Format("{0} - {1}", Start, End); } } 推定モデルのプロパティの1つだけが入力されるため、このアプローチは好きではありません。一方のプロパティでnullをテストし、もう一方のプロパティにデータがあると仮定する必要があります。 各プロパティは、ユーザーには異なる方法で表示されますが、現在のスイッチングロジックが存在するカスタムMVC DisplayTemplateを使用して、UIの同じ場所に表示されます。 @Model EstimattedShippingDateDetails @if …

2
ファイルからのオブジェクトの読み取り、SRPの違反?
C ++で物理シミュレーションプログラムを書いています。私はOOPとC ++の初心者です。 私のプログラムでは、入力ファイルのデータに基づいていくつかのオブジェクトを初期化する必要があります。 たとえば、架空の入力ファイル: # Wind turbine input file: number_of_blades = 2 hub_height = 120 # Airfoil data: airfoil1 = { chord = 2, shape = naca0012} airfoil2 = { chord = 3, shape = naca0016} この例では、TurbineクラスとAirfoilクラスがあるとします。翼オブジェクトは翼弦と形状を知る必要があり、タービンオブジェクトは翼の高さと数を知る必要があります。 各オブジェクトが入力ファイルから自分自身を構築できるように、これを行う必要がありますか? 例えば: class Turbine { public: Turbine(File input_file); // reads input file …

4
教科書が実際の言語ではなく疑似コードを使用するのはなぜですか?
大学やアルゴリズムの教科書では、教師と著者が疑似コードで制御フローを説明することは非常に一般的です。PythonやHaskellなどのより表現力のある言語の出現により、大学がこれらの言語のいずれかを介してアルゴリズムを説明するように切り替えることは合理的ですか? 私が考えることができる疑似コードの唯一の利点は、それがおそらく言語に依存しないということです。そうではありません。一部の疑似コードは命令型アプローチを使用し、他の疑似コードは機能的に見えます。著者は、使いやすいプログラミング言語からセマンティクスを借用するか、またはさらに悪いことに、セマンティクスを自然言語で記述します。では、疑似コードが実際に言語に依存しない場合、それを使用する利点は何ですか?既存の言語をそのまま使用した方がよいのではないでしょうか。

1
EAVにMySql 5.7 JSON列を使用する
私はeコマース製品を開発しており、すべての機能を実装できたため、ユーザーが製品の追加属性を作成できるようになりました。現在、私には2つのオプションがあります。 EAV EAVは主に眉をひそめていますが、Magentoで動作するようです。しかし、すべての頭痛を調査した後、それを使用するのには少し気が進まなくなります MySql 5.7でJSON列を使用する これはかなり新しいものであり、他のどこにも実装されていないので、JSON属性を照会した結果として全テーブルスキャンを実行するのは大変です。しかし、このMySql 5.7 JSONを読んだ後、彼らはJSONの使用を推奨しているようです。そして、この実用的なMySqlスキーマアドバイスのようなものを実装するよりも、それほど面倒ではありません。 私の質問は、NoSQLは私にとってオプションではないので、属性を格納するJSON列の方法を使用することに偏っていますが、EAVテーブルを使用するよりも深刻な欠点があります。

4
PythonプログラミングとPythonicであるために、なぜ「今のところ*現在*よりも優れていないことが多い」のですか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 Zen of Pythonでは、以下を除くほとんどの部分を理解できます。 Now is better than never. Although never is often better than *right* now ですから、今それを行うか、結果を得ることが今よりも良いと思います。しかし、なぜ「今のところ、*現在*よりもよくない」のはなぜですか?それはどういう意味ですか? 上記の2行のコンテキストを確認するには、PythonのZen全体を次に示します。 The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is …
8 python 

2
分散システムでのエラー処理
これは、Javaアプリケーションでの2つの分散コンポーネントの一般的なシーケンスです。 1 A sends request to B 2 B starts some job J in parallel thread 3 B returns response to A 4 A accepts response 5 Job finishes after some time 6 Job sends information to A 7 A receives response from a Job and updates これは、すべてが機能すると仮定した場合の理想的なシナリオです。もちろん、実生活は失敗に満ちています。たとえば、最悪のケースの1つは、#6単にネットワークが原因で失敗した場合です。ジョブは正しく実行されましたが、ジョブAについて何も知りません。 このシステムのエラーを管理する方法についての軽量なアプローチを探しています。多くのコンポーネントがあるため、エラー処理のためにそれらをすべてクラスター化しても意味がありません。次に、同じ理由で各コンポーネントに再度インストールされる分散メモリ/リポジトリの使用を取りやめました。 私の考えは、Bに1つの絶対状態を持ち、Aに永続状態を決して持たないという方向に向かっていAます。これは、次のことを意味します。 …

2
イベントの調達、再生、バージョン管理
イベントソーシング、CQRS、マイクロサービスを使用するシステムを設計しています。これは珍しいパターンではないことを理解しました。このサービスの重要な機能は、記録システムから再水和/復元する機能である必要があります。マイクロサービスは、MQ(Kafka)でコマンドとクエリを生成します。他のマイクロサービスが応答します(イベント)。コマンドとクエリは、監査と復元の目的でS3に保持されます。 現在の思考プロセスは、システムを復元するために、S3からイベントログを抽出し、単純にKafkaにフィードバックできるというものでした。 しかし、これは時間の経過に伴う生産者と消費者の両方の変化を認めることができません。コマンド/クエリレベルでのバージョン管理は、問題の解決にある程度役立つようですが、復元中のコマンドが受信および処理されたときに、まったく同じになるようにコンシューマーのバージョン管理を行うことはできません。 [のバージョン]コマンドを最初に受信したときに処理を実行しているコード。 これを解決するために使用できるパターンはありますか?この機能を宣伝する他のシステムを知っている人はいますか? 編集:例を追加します。 「バイヤー」が私のオークションサイトの「セラー」に「質問」を送信します。フローは次のようになります。 UI -> Web App: POST /question {:text text :to seller-id :from user-id} Web App -> MQ: SEND {:command send-question :args [text seller-id user-id]} MQ -< Audit: <command + args appended to log in S3> MQ -< Questions service: - Record question in DB …

2
階層化アプリケーションの承認ルールはどこに適用されますか?
この質問は、私を混乱させる私の申請の規則を適用することについてです。 コントローラはサービスを使用しており、サービスはリポジトリを使用しています。 public class CommentController: ApiController{ [HttpPost] public bool EditComment(Comment comment){ commentService.Update(comment); } } public class CommentService{ ICommentRepository repository; .... .... public void Update(Comment comment){ repository.Update(comment); } } ユーザーが認証されると、コメントを更新できます。 ただし、ユーザーは自分のコメントを編集する必要があります。 ただし、管理者はすべてのコメントを編集できます。 ただし、指定した日付以降はコメントを編集できません。 部門で編集 そして、私はこれらのルールのようなものを持っています。 サービスレイヤーで「ユーザー編集独自のコメント」ルールを適用すると、Update methotを変更し、コントローラーのパラメーターUser.Identity.Nameを渡します。 public class CommentService{ ICommentRepository repository; .... .... public void Update(string updatedByThisUser, Comment comment){ // …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.