タグ

ブックマーク / www.ogis-ri.co.jp (10)

  • アナリシスパターンを読もう|オブジェクトの広場

    アナリシスパターン。さまざまなところで「難解」、「難読」、「現場と無関係」とさまざまな憶測を呼んでいるようですね。でも、ツボにはまればわりと簡単に読めるし、非常に有用であることもわかってもらえると思っています。なにせ、私は、これなしで生きていけない体になってしまいました。まあ、肩の力を抜いてお話に付き合ってください。「なーんだ、簡単」と思っていただければ幸いです。 1.なにするものぞ まず、この先の話を読んでもらえるように、何の役に立つかから説明しましょう。アナリシスパターンの最大の御利益。まず、これを最大限に感じてもらうために、少し遠回りですが、要求獲得から設計初期に行われることについて少し触れます。 最初のかぎは、要求獲得にあります。要求獲得といえばユースケースですね。さて、ユースケースは、システムが達成すべき目標を「変化」の視点で表します。そこでは、「目的」として、現状のシステムを「

    アナリシスパターンを読もう|オブジェクトの広場
  • UMLモデリングカフェ「Square」 | オブジェクトの広場

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

    UMLモデリングカフェ「Square」 | オブジェクトの広場
  • 第一回 認証基盤のこれからを支えるOpenID Connect | オブジェクトの広場

    長年、組織領域とインターネット領域の境界で高価なセキュリティ製品を配備し、脅威から資産を守る手法が、世の中のデファクトスタンダードとして、多くの企業で採用されてきました。しかし、「モバイルデバイスの活用」、「クラウドサービス利用の浸透」、「ワークスタイルの変革」などのリクエストによって、その有効性は失われつつあります。また、これらのリクエストに対し、資産ごとにセキュリティ対策を実施すると、コストが非常に高くなる傾向があります。 第一回の記事では、資産を守るための新たな境界である「アイデンティティ」に注目し、その境界を体現する認証連携方式について解説を行います。そして、数ある認証連携方式の中から2014年2月に標準化された「OpenID Connect」に注目して、仕様説明と有用性を解説したいと思います。 認証基盤のこれまで 認証基盤における認証対象アプリケーションとの連携実装方法を振り返

    第一回 認証基盤のこれからを支えるOpenID Connect | オブジェクトの広場
  • 間違いやすいセキュリティ用語 | オブジェクトの広場

    セキュリティ技術としての「署名」と「証明書」はどう違うのでしょうか?「復号化」という用語に違和感はないですか?記事では、間違いやすい、混同しやすいセキュリティ用語について解説します。 はじめに セキュリティ技術としての「署名」と「証明書」はどう違うのでしょうか? 「復号化」という用語に違和感はないですか? 同じ用語を人によって違う意味で使っていて、仕様書の解釈や打ち合わせでのコミュニケーションに困ったことはないですか? 記事では、間違いやすい、混同しやすいセキュリティ用語について解説します。セキュリティ分野の基礎知識を得たいITエンジニアのみなさんの参考になれば幸いです。 目次:間違いやすいセキュリティ用語 暗号化と復号「化」? 暗号方式の種類 ー 公開鍵暗号と非対称鍵暗号は同じ? 暗号鍵の種類 ー 秘密鍵は secret key?private key? 呼び方のバリエーション おす

    間違いやすいセキュリティ用語 | オブジェクトの広場
  • (プログラマのための)いまさら聞けない標準規格の話 第2回 文字コード実践編 | オブジェクトの広場

    プログラマがシステム開発において共通で必要となる、技術と業務の狭間の共通知識を解説します。連載第2回は文字コードの実践編です。 0. 前回の復習と今回の概要 システム開発で必要となる標準規格の話、前回 は文字コードの概要について説明しました。ざっくりまとめるとこんな内容でした。 「符号化文字集合」で文字集合と符号位置を定義し、「符号化方式」でバイト表現に変換していること。 日では、しばらく文字集合 JIS X 0208 を、ISO-2022-JP、EUC-JP、Shift_JIS の符号化方式で利用してきたこと。 近年は、世界中の文字が扱える Unicode が主流となっており、UTF-8、UTF-16 などの符号化方式があること。 常用漢字、人名用漢字に限っても、字体を正確に扱おうとすると、JIS X 0208 の範囲では不十分であり、JIS X 0213、Unicode、サロゲートペ

    (プログラマのための)いまさら聞けない標準規格の話 第2回 文字コード実践編 | オブジェクトの広場
  • (プログラマのための) いまさら聞けない標準規格の話 第1回 文字コード概要編 | オブジェクトの広場

    プログラマがシステム開発において共通で必要となる、技術と業務の狭間の共通知識を解説します。連載第1回は文字コードの概要編です。 0. はじめに 業務システムを開発する場合、プログラミング言語、フレームワーク、ミドルウェア、業務知識など以外に、共通で必要となる知識があります。文字コード、国際化、日付・時刻の扱い、住所コード、郵便番号、電話番号などの各種コード、…。 連載では、プログラマがシステム開発で必要となる、技術と業務の狭間の共通知識を解説して行きたいと思います。 連載第1回は文字コードの概要編です。コンピュータシステムにおいて、文字情報は文字コードを用いて処理されます。文字コードとは、各文字に対応付けられた数値 (符号) のことです。近年、新規に開発される業務システムでは Unicode が使われることが多いと思いますが、既存システムとの連携など他の文字コードが使用されることもまだま

    (プログラマのための) いまさら聞けない標準規格の話 第1回 文字コード概要編 | オブジェクトの広場
  • 単一責任の原則(Single responsibility principle)について、もう一度考える | オブジェクトの広場

    単一責任の原則(Single responsibility principle)について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle:単一責任の原則 Open/closed principle:オープン/クロースドの原則 Liskov substitution principle:リスコフの置換原則 Interface segregation principle:インターフェース分離の原則 Dependency inversion principle:依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や

    単一責任の原則(Single responsibility principle)について、もう一度考える | オブジェクトの広場
  • (第2報)「宅ふぁいる便」サービスにおける不正アクセスによる、お客さま情報の漏洩について(お詫びとお願い) | オージス総研

    お知らせ (第2報)「宅ふぁいる便」サービスにおける不正アクセスによる、お客さま情報の漏洩について(お詫びとお願い) 2019.01.26お知らせ >第1報についてはこちらをご確認ください >第3報についてはこちらをご確認ください ファイル転送サービス「宅ふぁいる便」におきまして、一部サーバーに対する不正アクセスにより、約480万件のお客さま情報のデータが外部に漏洩したことを確認いたしました。 ご利用の皆さまに多大なるご心配とご迷惑をおかけしておりますことを、深くお詫び申し上げます。 なお、現時点で具体的な被害は確認されておりませんが、引き続き第三者を含めた調査を行っており、詳細が判明次第、改めてお知らせいたします。 1.漏洩したお客さま情報 (1)内容 「宅ふぁいる便」のお客さま情報 メールアドレス、ログインパスワード、生年月日、氏名、性別、業種・職種、居住地(都道府県のみ)(2)件数

  • CRC(Class Responsibility Collaborator)モデルの概要

    CRC (Class Responsibility Collaborator) モデルの概要 by Scott W. Ambler, Copyright 2003 CRC (Class Responsibility Collaborator) モデル (Beck & Cunningham 1989; Wilkinson 1995; Ambler 1998a) とは、普通のインデックスカードの集合です。このインデックスカードは、図1に示すように3つの区画に分かれています。クラス (class) は同じようなオブジェクトの集合であり、責務 (responsibility) はクラスが知っている、あるいは行う事柄であり、協調クラス (collaborator) はクラスが責務を果たすために相互作用する他のクラスです。図2に手書きのCRCカードの例を2つ示します。 図1. CRCカードの区画 図2

    CRC(Class Responsibility Collaborator)モデルの概要
  • [ 技術講座 ] Domain-Driven Designのエッセンス 第1回|オブジェクトの広場

    DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』(以降DDD)は、「

  • 1