タグ

モデリングに関するsugimoriのブックマーク (17)

  • 始めよう! ドメイン駆動設計&マイクロサービス開発 ~C# と Azure Service Fabric で最高の DDD 開発を~

    3. 自己紹介 • 会社 株式会社ネクストスケープ • 名前 上坂貴志(うえさかたかし)Twitter:@takashiuesaka • 年齢 44歳 • 好き・興味あり Azure(Microsoft MVP for Microsoft Azure)、 Scrum(認定スクラムマスター) DDD、ソフトウェアアーキテクチャ、機械学習 • 講演活動 • 2016年 NS Study No.6 Azure IoTHub紹介 アプレッソ 最新IT事例セミナー Azure Machine Learning セミナー登壇 SANSAN DDD勉強会発表 • 2015年 FEST2015 (Channel9で動画公開) MSxNextscape合同 Azure Machine Learningセミナー開催 Developers Summit 2015 QCon 2015 CloudDays2015東

    始めよう! ドメイン駆動設計&マイクロサービス開発 ~C# と Azure Service Fabric で最高の DDD 開発を~
  • 第24回上流工程勉強会

    なぜ、現状の基幹業務システムは、ビジネス環境の変化に迅速に対応できないのか? ~超高速開発ツールの導入が必然である理由~

    第24回上流工程勉強会
    sugimori
    sugimori 2016/02/23
    これ行きたかったな
  • 「【改訂版】初歩のUML」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords

    【改訂版】初歩のUML: 第5回 少しだけ高度なモデリング技術(その2)クラスの依存関係と実現関係 今回も「第4回 少しだけ高度なモデリング技術(その1)」に引き続き、高度なモデリングの考え方についてクラス図を取り上げて説明していきます。今回取り上げるのはクラスの依存関係と実現関係です。(2012/10/1) 【改訂版】初歩のUML(13): UMLモデリングのノウハウ、最後の秘訣(UMLモデリングの開発過程 開発編その2) (2004/1/10) 【改訂版】初歩のUML(12): UMLモデリングの開発過程 開発編 (2003/12/20) 【改訂版】初歩のUML: 第11回 UMLモデリングの開発過程(ビジネスモデリング編) (2003/11/15) 【改訂版】初歩のUML: 第10回 開発プロセスの上手な組み合わせ (2003/10/8) 【改訂版】初歩のUML: 第9回 UMLベー

  • モデルベース要件定義 at BPStudy

    ハンドノート T字形ERモデル セミナー資料 (Author; S.Toriyabe SYSTEMS DESIGN Co.,Ltd. Japan)

    モデルベース要件定義 at BPStudy
    sugimori
    sugimori 2015/07/24
    これベースでいいか
  • UML 2 アクティビティ図の概要

    by Scott W. Ambler, Copyright 2003 UML2.xのアクティビティ図(Object Management Group 2003)は、一般的に、ビジネスプロセスモデリング、1つのユースケースまたは利用シナリオに記述されたロジックのモデリング、ビジネスルールの詳細ロジックのモデリングなどに使います。UMLのアクティビティ図を使って複雑な操作の内部ロジックをモデリングすることも可能ですが、アクティビティ図が必要ないレベルまで単純になるよう操作を書き直すほうがはるかによい方法です。多くの意味で、オブジェクト指向におけるUMLアクティビティ図は、構造化開発のフローチャートやデータフロー図(DFD)に相当します。 最初に、図1および図2で使用している基的な表記法について説明しましょう(この他にもさまざまなものがあります)。 初期ノード (initial node):黒

    sugimori
    sugimori 2015/07/24
    これわかりやすいな
  • UML 2 シーケンス図の概要

    by Scott W. Ambler, Copyright 2003 UMLシーケンス図を使うことで、システム内のロジックの流れを視覚的に表現し、ロジックを文書化して検証できます。この図は一般的に、分析にも設計にも使われます。システム内の振る舞いを明らかにするための動的モデリングを行うときには、UMLの成果物の中でもシーケンス図をもっともよく使用します。動的モデリングの技法にはこの他に、アクティビティ図、コミュニケーション図、タイミング図、相互作用概観図などがあります。私の意見ですが、最新のビジネスアプリケーション開発を行うときにもっとも重要になる設計レベルのモデルは、このシーケンス図と、クラス図、物理データモデルです。 通常、シーケンス図は以下のものをモデリングするために使います。 利用シナリオ:利用シナリオとは、考えられるシステムの使い方を記述したものです。利用シナリオのロジックは、ユ

    sugimori
    sugimori 2015/07/24
    複数のユースケースの流れは、シーケンスで表現するのがいいのかな
  • UMLモデリングカフェ「Square」 | オブジェクトの広場

    内容はこれまで通り、毎回、身近にあるモノや出来事など、簡単な【お題】を出題し、皆様にモデリングをして頂きます。 次回の記事で、皆様の解答モデルの中から 3 つほど取り上げて、コメントを付けていくかたちで進めていきます。 この連載では、UMLでの表現の優劣やテクニックを競ったりというものではなく、 あまりUMLに馴染みのない人も気軽にモデリングを愉しんでもらえる連載にするつもりです。解答していただきたい読者の方としては、普段からUMLを使ってバリバリ開発されているソフトウェアエンジニアの方よりもむしろ、最近UMLを覚えたばかりでモデル作成の経験の浅い方、モデルを作成するといつも複雑になってしまうと悩んでおられる方を対象に考えています。 モデリング大好きな達人モデラーの方々には少々物足りないネタになってしまうかもしれませんが、まわりの仲間を誘って、一緒にモデリングしてみたり、個別にモデリングし

    UMLモデリングカフェ「Square」 | オブジェクトの広場
  • PHPメンターズ -> 第40回IT勉強宴会モデリング競演2でDDDのモデリングについて発表しました

    後半のセッションでは、「What the system is(共通性や可変性を分析する)」を説明しつつも、「What the system does」とは別のものとして切り分けることはできないという主張から、 DDD とリーンアーキテクチャとの比較、そしてパターンに関する議論が展開されました。 @remore が前半部分をまとめてくださっていまして、そこで出て来るいくつかの用語(Form, Structure, What the system is, What the system does)を前提として私のできる範囲で行いました。 なお当日のCoplien氏によるセッション内容は、許可を得た上でYouTubeにアップロードされていますので、より深くご覧になりたい方はこちらも併せてご参照下さい。 DCI Tokyo 1 - Lean Architecture by James Coplie

  • DDD,UML,DOA競演モデリング発表会2<第40回IT勉強宴会in大阪>

    20150425(土) 14:00から開催しました。申し込み案内は こちら 今回も前回に続き花束問題でした。モデリングには一家言ある方々にお越し頂いてますので全員が面白く為になります。40人を超える方にご参加いただきました。ありがとうございました。また毎回無料で会議室をお貸し...

    sugimori
    sugimori 2015/06/02
  • モデリングの標準問題から学べること - 設計者の発言

    大切な人の記念日に花束とカードを贈りましょう――そんな事業を支援するシステムの三要素モデルを公開した。もともとのシステム要件は「花束問題V1.2」として、IT勉強宴会のサイトで公開されている。複雑過ぎず単純過ぎないバランスの良い問題である。 ・ダウンロードページ(モデルを閲覧するにはX-TEA Modelerが必要) ・花束問題V1.2のページ 要件をざっと説明しよう。「商品」である花束に組み込まれる素材は「単品」と呼ばれ、入荷日毎にロット管理される。単品ロットはナマモノなので、規定の日数後には廃棄されなければいけない。ゆえに、受発注状況に応じた単品の欠品見込や廃棄見込をリアルタイムで示すための仕掛けが要る。次図は公開したモデルの一部である。 ▼受注~出荷の流れを示す業務フロー ▼受注まわりのデータモデル このシステム要件にもとづいてまとめられたモデルを、手法横断的に比較検討する。そんな活

    モデリングの標準問題から学べること - 設計者の発言
    sugimori
    sugimori 2015/06/02
    これはやってみたい
  • 要求開発にて”「これだけ」モデリング”:An Agile Way:オルタナティブ・ブログ

    これだけモデリング!というコンセプトで、山岸さんが話された5/28の要求開発定例が面白かったので紹介します(山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日語が好き)。 情報システム部門目線で見て、どんどん複雑になるアプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性が今回テーマです。そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなかペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。 (※6/5 追記: 以下に、当日の資料を公開します。) これだけモデリングとは、 誰が? ー 情報システム部門の人(と開発の人が共に) いつ? ー システム開発の前段階、すなわち「要求開

    要求開発にて”「これだけ」モデリング”:An Agile Way:オルタナティブ・ブログ
    sugimori
    sugimori 2014/06/06
    この辺勉強したいな〜
  • UMTP Japan - 2013年度 第2回 UMLモデリング入門セミナー開催のご案内 2013-10-23

    皆様におかれましては、平素より当協議会の活動にご参加いただきまして、誠にありがとうございます。 さて当協議会では、2013年度第2回目となるUMLモデリング入門セミナーを10月23日に開催いたします。UMLを使ったモデリング技術に興味をお持ちの方、およびUMLモデリング技能認定試験L1の受験を目指している技術者を対象にUMLの紹介とUMLモデリングの基およびL1の試験対策・模擬問題解説等を含めたセミナーを開催いたします。 詳しくは下記の要綱をご参照願います。

  • Continuous Modeling - Fly me to the Luna

    みなさまご無沙汰しております。僕はここの所、残業はしないまでも毎日クタクタになるほど忙しい毎日を過ごしています。どんな仕事か一言でいうと、あるプロダクトのアーキテクチャを刷新するお仕事です。今までできなかったあれやこれやを実現するために、既存のアーキテクチャを改善したり、作りなおすお仕事です。今はまだ始まったばかりで、方針を決めるために、既存のアーキテクチャ上に機能拡張してみて問題点を調査したり、どう改善するのか方針案を考えたり、実際に改善案を少しずつやってみたりしています。 このプロジェクトは、それほど大所帯ではないですが、他の会社のエンジニアさんも加わるなど、結構スキルセットがバラバラです。そのため、久しぶりにペアプロで作業を回しています。1日じゅうペアプロすると、一日の終わりの頃には頭がクタクタです。久しぶりです、この感覚。楽しい。 さて、既存のアーキテクチャを見ていくと、10年以上

    Continuous Modeling - Fly me to the Luna
  • ぐるぐる DDD/Scrum というワークショップをやってきました - haradakiro's blog

    東北デベロッパーズコミュニティにお招きいただき、DDD/Scrumのワークショップをやってきました。 ワークショップは、DDD のモデリングのうずまきに、スクラムのワークショップでよく使うタイムボックス縛りを組み合わせて、Agile でいうところの Swarming という状態になれないかな、という目標で設計しました。 正直、1時間の枠組みで、シナリオ書いて、モデル描いて、コードも実装するのは、だいぶ大変だったと思います。ご参加いただき、ありがとうございました。 ただ、1時間を二回廻すだけでも、チーム内で駐車場を語る語彙、モデル、設計実装案は、だいぶ共有できたのではないでしょうか。そのまま、プロジェクトに突入できる訳ではありませんが、わからないことがわかっているというのは、プロジェクトを始めるときには非常に役に立つでしょう。 参加された方は、各チームの発表したモデルの中心(コアドメイン)が

    ぐるぐる DDD/Scrum というワークショップをやってきました - haradakiro's blog
    sugimori
    sugimori 2013/07/16
    やってみたいなー
  • ドメイン駆動設計の感想~OOAは過ぎ去りDOAはもう一度舞台に上がるのか - プログラマの思索

    【1】増田さんによるドメイン駆動設計の話は、「エリック・エヴァンスのドメイン駆動設計」のの目次に従って説明してくれたので、とても分かりやすかった。 OOAに関しては「実践UML」「アナリシスパターン」「ストリームラインオブジェクトモデリング―パターンとビジネスルールによるUML」などを2000年代前半に勉強会で読みこなしていたから、ドメイン駆動設計では、オブジェクト指向設計をどのように生かしているのか、が理解できたからかもしれない。 増田さんの職歴を聞いた所、OracleのデベロッパーからJavaなどのオブジェクト指向設計へ転向したとのことなので、DOAの良さもOOAの良さもよく理解されているのだろう。 また、ドメイン駆動設計だけでなく、ICONIXやSpringによる実装も組み合わせたオブジェクト指向設計なので、要件定義から外部設計、実装に至るまでの経験が豊富なことは感じられた。 【2

    ドメイン駆動設計の感想~OOAは過ぎ去りDOAはもう一度舞台に上がるのか - プログラマの思索
    sugimori
    sugimori 2013/02/21
    単純なモデルだったらRailsであまり考えずに作れてしまう気がするけど、大規模システムのモデリングと実装はどうやって繋ぐべきなんだろうか。
  • 組み込みアジャイルコーチ James Grenning さんインタビュー ( 後編 ) | オブジェクトの広場

    去る8月にアメリカ・テキサス州ダラスで開催された Agile 2012 にて James Grenning さんにインタビューを実施させていただきました。James さんは、組み込みソフトウェア開発におけるアジャイル開発のコーチ・トレーナー・コンサルタント、『Test Driven Development for Embedded C』[1] の著者、アジャイルソフトウェア開発宣言の著者17名の1人、そしてアジャイルな見積り手法「プランニングポーカー」[2] の考案者でもあります。 インタビューでは、日の「 Test Driven Development for Embedded C読書会 」参加メンバーから挙がった質問について順次尋ねる形で進めました。 2012 年 10 月号の前編に続く後編の記事では以下の話題についてお伝えします。 ・ モデリングやアーキテクチャ設計とTDDの関係

    sugimori
    sugimori 2013/01/14
    「モデリングやアーキテクチャ設計とTDDの関係」ふむふむ
  • 業務ロジックをデータモデリングはどこまで表現できるか? - プログラマの思索

    「業務ロジックをデータモデリングはどこまで表現できるか?」について考えたことをラフなメモ書き。 業務システムでは、データが命。 データには個人情報が含まれるために管理が重要だったり、売上データやPVデータから、どの層の顧客から売上やアクセスが多いのか、を計測することもできる。 すると、それらデータを格納するRDBが必要になり、そのテーブル設計が重要になってくる。 顧客の業務プロセスをモデリングする場合、最近ならOOAが主流。 でも、DOAの方が現代は重要性を増していると考えている。 例えば、Railsのような優れたWebフレームワークがあれば、ER図さえきちんと作れば、DBマイグレーションとプログラム雛形を自動生成することによって、テーブルのCRUDのような画面はすぐに作れてしまうからだ。 日におけるデータモデリングの歴史は意外に古い。 TH法、T字型ER、渡辺さんのXEAD Model

    業務ロジックをデータモデリングはどこまで表現できるか? - プログラマの思索
    sugimori
    sugimori 2012/11/28
    DOAだと言いながら、ちゃんとデータモデルかけてないんじゃないか。業務ロジックをデータモデリングで表現できていれば、もっとモデリングと実装がつながってもいいはずなのだが。
  • 1