タグ

設計に関するwiz7のブックマーク (9)

  • お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える - Qiita

    お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考えるmodelDDD設計 みなさんは、Modelと言われたときに何をイメージしますか? こんなアレを思い浮かべた方も多いかと思います。 マサカらせてください。やはりお前らのModelは間違っている。 アレをModelと呼ぶと何が不味いのか すみません、早速言い過ぎました。半分は正しいです。MVCの発明者、Trygve Reenskaug氏による1979年の説明によると、 Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects. 1 このように「Modelは単体のオブジェクトであっても

    お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える - Qiita
    wiz7
    wiz7 2018/03/20
    MVCの解説
  • 機能要件の合意形成ガイド バッチ編

    Information-technology Promotion Agency, Japan Software Engineering Center Software Engineering Center Copyright © 2010 IPA, All Rights Reserved 機能要件の合意形成ガイド(ver.1.0) ~「発注者ビューガイドラインver.1.0」改訂版~ 分冊6 バッチ編 2010年3月31日 独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター 要求・アーキテクチャ領域 機能要件の合意形成技法WG 1 Software Engineering Center Copyright © 2010 IPA, All Rights Reserved 機能要件の合意形成ガイド 分冊6 バッチ編 使用条件 <ガイドをご使用になる前にお読みください> 機

    wiz7
    wiz7 2017/09/08
    機能要件の合意形成ガイド(ver.1.0) バッチ処理
  • Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん

    バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ

    Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
    wiz7
    wiz7 2017/09/08
    バッチ処理
  • DockerでサクッとDBからER図を作成する - Qiita


    SchemaSpyDBER Docker使 https://hub.docker.com/r/schemaspy/schemaspy/  docker run -v "$PWD/schema:/output" --net="host" schemaspy/schemaspy:snapshot \ -t <DB> -host <DB/IP>:<> -db <DB> -u <DB> -p <DB> schemaHTML  docker run  -v
    DockerでサクッとDBからER図を作成する - Qiita
  • 詳細設計書が滅亡しない理由 - kagamihogeの日記


    IT  SIer  Excel  Excel   100% Excel   使 !!Excel:  Excel  PowerPoint 使 Excel 
    詳細設計書が滅亡しない理由 - kagamihogeの日記
    wiz7
    wiz7 2017/07/21
  • DB論理設計のノウハウ - Qiita


    DB DB DB    ER          () ()  DB  2
    DB論理設計のノウハウ - Qiita
  • 非機能要求グレードの研修教材と利用ガイド[活用編]を公開:IPA 独立行政法人 情報処理推進機構


      IPA(*1)IT使
    wiz7
    wiz7 2017/05/26
    非機能要件、非機能要求の見える化資料 学習・研修用資料 IPA
  • 第3回 設計段階で性能を見積もろう


    Web    
    第3回 設計段階で性能を見積もろう
    wiz7
    wiz7 2017/04/27
    性能要件 性能見積
  • 第13回 [データモデル編]発注者が確認しやすいようにCRUD図をアレンジする

    CRUD図を利用して発注者とレビューをされたご経験はありますか? CRUD図というと一般的には以下のような図をイメージされるのではないでしょうか。 このCRUD図を使って,機能とデータの抜け・漏れや処理の集中,不完全な分割などがないかどうかを検証する「CRUD分析」で発注者に確認したいことが発生したときに,CRUD図をそのまま見せても,発注者はなかなか理解しずらいものです。 確認したい内容に絞り込んだ表を作成する そこでCRUD図をそのまま発注者に見せるのではなく,以下のようにアレンジしたCRUD図を作成してみましょう。 この図のポイントは以下の通りです。 ・申請書作成や承認といった処理のタイミングごとに,各エンティティの作成,参照,更新,削除があるかどうかを表した表形式にする。 ・確認したいエンティティとタイミングのみ記載する。 ・エンティティの数が多い場合は分類する。 ・作成,参照,更

    第13回 [データモデル編]発注者が確認しやすいようにCRUD図をアレンジする
    wiz7
    wiz7 2016/06/19
  • 1