タグ

設計と開発に関するhiro360のブックマーク (40)

  • 要求開発入門 | リコーITソリューションズ株式会社

    株式会社 匠Lab 代表取締役社長 萩 順三 2000年にオブジェクト指向技術の企業、豆蔵を立ち上げ、以降ITアーキテクト、メソドロジストとして活躍してきた大ベテラン。2009年7月、匠BusinessPlaceを設立。また、総務省行政管理局技術顧問や内閣官房IT室GPMO補佐官として、2005年から3年間は、豆蔵と兼務しながら政府のITプロジェクトにも関わる。 現在は、匠BusinessPlaceにて、ビジネスとITの可視化を行うための要求開発をさらに洗練・拡張させた手法「匠Method」を開発。自らユーザー企業で実践している。 株式会社 匠Lab http://www.takumi-lab.co.jp/ 連載では、萩順三氏に「要求開発超入門」を紹介していただきます。 要求開発を深く理解してもらうために、誰にでもわかる要求開発を目指して、分かりやすい説明をしていきます。

  • 【ハウツー】クラス構造がまる見えに! UDocでJavaをダイナミックに分析する (1) Ja...

    UML、なかでもクラス図はクラスの関係を把握するうえで欠かせないダイアグラムだ。できれば既存のAPIはクラス図を見て簡単に全容を把握しておきたい。その際に全自動でクラス図を作成できると大変便利だろう。そこで紹介したいのがUDocだ。こうした用途にぴったりのアプリケーションである。 UDocはJava クラスをUMLライクのダイアグラムによって視覚化するGUIアプリケーションだ。Javadoc、Javaバイナリファイル、Javaソースコードなどから動的に UMLライクのダイアグラムを生成できる。生成されるダイアグラムそのものを動的に編集することも可能なので、グリグリといぢりながらクラス関係を解析できるすぐれものだ。動作にはJDK 5.0かそれ以上のバージョンが必要。稿執筆時点の最新版は12日(米国時間)に公開された1.005であり、GNU GENERAL PUBLIC LICENSE Ve

  • Technologies for UI

    Technologies for UI List view Topics copyright livedoor 上下カーソルキーでスライドを切り替えられます。 表示されない場合はこちらから

  • 「ソフトウェアの仕様書は料理のレシピに似ている」へのフィードバックをいくつか集めてみた

    一年近く前に書いた「ソフトウェアの仕様書は料理レシピに似ている」というエントリー。今になってもトラックバックやコメントが送られて来るのは、実際に日IT業界に働く人たちの間にも「今のやりかたはおかしい」という疑問や不満があるという証拠だろう。 そこで今日は、シオレットの引用機能のテストも兼ねて、よせられたフィードバックを新しい順にいくつか紹介してみる(それも、昨日になってやっとシオレットが動き始めたSafariブラウザーを使っての投稿だ^^)。 まして、優秀でないエンジニアがコードを書かずして、仕様書を作ることが出来ようか?ソフトウェア開発はウォーターフォールでは上手くいきません。 【さくねこの”チラシうら”にっきより引用】 別会社のSEが設計して、それを請け負った会社のPGが実装する。こんなやり方でまともなプログラムが作れたらある意味凄い。物凄いオーバーヘッド作業をこなして作るわけだ

  • スケーラブルWebサイト

    ユーザー数の増加に伴って、その規模を容易に拡大できるスケーラブルなWebサイト構築について解説した総合ガイド。何百万人ものユーザーに対応するWebアプリケーション用のインフラを構築するための立証された手順を、実践的な例と最先端テクニックを使ってソフトウェア/ハードウェアの両面から解説します。限られた予算で今日のWebアプリケーションに耐えうる性能を実現したいすべての開発者にとって有用な1冊です。 翻訳者によるサポートページ。 訳者まえがき まえがき 1章 はじめに 1.1 ウェブアプリケーションとは? 1.2 ウェブアプリケーションの構築法 1.3 アーキテクチャとは? 1.4 どう始めるか 2章 ウェブアプリケーションのアーキテクチャ 2.1 階層化されたソフトウェアアーキテクチャ 2.2 階層化技術 2.3 ソフトウェアインタフェースの設計 2.4 A地点からB地点へ 2.5 ソフトウ

    スケーラブルWebサイト
  • 業務系のクラスでインタフェイスの実装クラス名に「インタフェイス名+Impl」って名前をつけるのはダサいよね。 - wildcatsの日記

    実装に特性があるからインタフェイスと実装を分離するわけで*1 インタフェイスに対して実装が1クラスになる場合にはインタフェイスと実装を分離する必要が無いとボクは思うね。 追記:特定のDIコンテナの話はこのエントリと無関係です。 追追記:他所での議論の延長でボクの考えをここに書いただけなので、特定のDIコンテナとか特定の設計手法とかは何も関係ない(というか意識もしていなかった)話ですけど。 上にも例外として書いたしコメントにも書いたんだけど、たとえばトランザクション自動制御とかでFacadeに対してAspectをかけたい場合の設計手法の一つとしてインタフェイスと実装を強制的に分離(インタフェイスと実装が1対1)してDynamic Proxyを使う設計手法を用いても構わないのではないでしょうか?最近のプロジェクトでDIコンテナは使ってないけどHibernateのセッションとかの管理をFacad

    業務系のクラスでインタフェイスの実装クラス名に「インタフェイス名+Impl」って名前をつけるのはダサいよね。 - wildcatsの日記
  • 階層アーキテクチャの利点は、複雑さの減少 ― @IT

    個々のコンポーネントを組み上げて、どのようなシステムを構築するか。構造(アーキテクチャ)によって、できあがるシステムの性質が変わってくる。作り手側の視点に立てば、どのようなアーキテクチャを採用するかによって、作り方も変わってくる。いままで連載した記事を通して、わたしたちは、個々のコンポーネントの作り方を学んできた。今回からは、コンポーネントをいかに組み上げるか、という課題に知恵を絞ることになる。コンポーネントの利点を最大限に生かすこと。それがアーキテクチャ設計の現実的な意味の1つだ。そして、1つの有効なアプローチに階層化アーキテクチャがある。 前回「使いやすくて、変化に強いコンポーネント」までにサブシステムなどを利用したコンポーネントの作り方についてお話ししてきました。それでは、コンポーネントは実際どのような単位で作り上げていけばよいのでしょうか。 コンポーネントの単位として考えられるのは

    階層アーキテクチャの利点は、複雑さの減少 ― @IT
  • オブジェクト指向を正しく理解する - 特集 オブジェクト指向は難しくない!:selfup

    オブジェクト指向はしばしば,とっつきづらく難しい技術と言われます。その理由の一つには,対象とする分野が広く,それぞれに深みがあることが挙げられます。しかし,それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と,「もの中心」を意味するコンセプト自体の問題です。 そこで特集では,「オブジェクト指向という言葉をよく聞くけど,実際どんなものかよくわからない」という方のために,初心者/入門者が陥りやすい落とし穴を明確にしながら,オブジェクト指向の全体像を説明します。余計な先入観やまぎらわしいたとえ話に惑わされなければ,オブジェクト指向そのものはそれほど難しい技術ではないことを理解していただきたいと思います。なお,オブジェクト指向プログラミング,デザインパターン,分析/設計といった個々の技術については特集2以降でそれぞれ解説

    オブジェクト指向を正しく理解する - 特集 オブジェクト指向は難しくない!:selfup
  • ひがやすを blog - [Seasar]ページ駆動開発とテーブル駆動開発

    Seasar2.3の時代は、Goyaと言われる開発手法がありました。Goyaのアーキテクチャは、JavaEEの基にのっとったレイヤモデルアーキテクチャです。詳しくはこの辺。 http://d.hatena.ne.jp/higayasuo/20050817#1124260949 http://d.hatena.ne.jp/higayasuo/20050818#1124338844 役割分担がきちんとされているきれいなアーキテクチャだと思うのですが、CRUD(Create Read Update Delete)しかないような単純な画面でもそこそこクラスが必要で重い感じがするのも事実です。 過去のDIではインターフェース中心の設計が強く推奨されていたため、レイヤモデルアーキテクチャは重く感じられても非常にDIにフィットしていました。 しかし、Javaでさらに生産性を高めるためには、レイヤモデル

    ひがやすを blog - [Seasar]ページ駆動開発とテーブル駆動開発
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • どうなっているの?あのソフトの仕組み - 今からでも遅くない!アルゴリズム入門:selfup

    Webの全体像を効率よく取り込み,分類する 「YSTのシステムは大まかに三つの機能に分かれます(図2)。最初は世界中のWebページをYSTのシステムに取り込む『クローリング(crawling)』という機能です」(Yahoo! JAPAN,リスティング事業部 検索企画室の宮崎光世氏,以下同)。 取り込むと簡単に言っても,Webページの数は膨大なうえ,更新の頻度や情報の質などがまちまちです。すべてのページに同じようにアクセスしていると非効率なことこの上ありません。そこで,限られた時間で質の良い検索ができるようにするための工夫をしています。例えば,クローリングを繰り返すうちに頻繁に更新されることがわかったページは短いサイクルでチェックし,ほとんど更新のないページはチェックの頻度を落とす,といったことをしているそうです。 ただ,更新の頻度が単に高いだけではダメです。重要性が高いと考えられるWebサ

    どうなっているの?あのソフトの仕組み - 今からでも遅くない!アルゴリズム入門:selfup
  • S2Containerのクラス図 - y-komori’s diary

    S2Containerのソースを読んでいると、ついクラスの構成を忘れがちになるので、Judeでリバースしてクラス図(といっても継承関係だけだが)を書いてみた。 リポジトリに入っている最新版を落としているので、S2.4関係のクラスも混ざってしまっていたりして完璧ではないかもしれないけど、とりあえず全体を掴むのには役に立つはず。(パッケージの分け方とかも完璧ではありませんのでご了承を) containerパッケージ S2Containerの中心となるクラス群。 deployerパッケージ コンポーネントのインスタンス属性に従って、インスタンス化の方法を実現するのがこの辺。 assemblerパッケージ コンポーネントのインジェクションを行っているのはこの辺。 factoryパッケージ Diconを読み込んでS2Containerを構成しているのはこの辺。 autoregisterパッケージ S

    S2Containerのクラス図 - y-komori’s diary
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • Seasarひがやすを氏の提案するページ駆動開発とは? (1) これまでは「レイヤモデルアーキテクチャ」 (MYCOMジャーナル)

    電通国際サービス 開発技術センター 統括マネージャー(Seasarファウンデーション Chief Committer) 比嘉康雄(ひがやすを)氏 UMLモデリング推進協議会(UMTP/Japan)は14日および15日、大手町サンケイプラザにおいてモデリングに関するフォーラム「Modeling Forum 2006」を開催した。同フォーラムでは2日間にわたってUML、モデリング、SOA、SOX法、内部統制などに関する幅広いセッションが催される。ここでは、電通国際サービス 開発技術センター 統括マネージャー(Seasarファウンデーション Chief Committer)比嘉康雄(ひがやすを)氏によって発表された「EJB3時代のアーキテクチャパターン」についてとりあげたい。 Webアプリケーションにおける従来のJavaの開発は、いわば「レイヤモデルアーキテクチャ」、と同氏は説明する。レイヤそれ

  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • [ThinkIT] 第5回:モジュールの作成 (1/2)

    今回はフレームワークの役割と構築について前回までで紹介しきれなかった部分を解説した上で、フレームワーク全体がどう動作しているかを説明します。 「簡単に使い方を覚えられる」という条件を満たすために、データオブジェクトを使って素早く動作するようにカスタマイズしたデータアクセス層を採用しました。他のオプションも検討しましたが、広告会社の開発環境で使うには複雑過ぎるという結論に達しました。 データオブジェクトがどのようなふうに動作するのか詳しく見ていく余裕はありませんが、フレームワークで使用しているデータオブジェクトのスーパークラスをお見せします。 データベースの全テーブルには、フレームワークのデータオブジェクトスーパークラスを継承した各データオブジェクトクラスが対応します。リスト8と9を見てください。指定したデータベースのデータオブジェクトをすべて生成するスクリプトもあります。これで時間を大幅に

  • [ThinkIT] 第4回:フレームワークの役割と構築方法 〜 後編 (1/3)

    リクエストハンドラはリクエストを受け取ると、それが正しいものかチェックして要求されたモジュールに送ります。どのような振る舞いをするかは、ユーザがリクエストを送ったModuleによります。リスト5を見てください。 リスト5 <?php ⁄** * * * @author Darryl Patterson < darryl.patterson@eurorscg.com > * @copyright Euro RSCG 4D * *⁄ include_once('common/util/class-EnvironmentFactory.php'); include_once('common/util/class-ModuleFactory.php'); require_once('common/util/class-Config.php'); class Handler { var $confi

  • [ThinkIT] 第3回:フレームワークの役割と構築方法 〜 中編 (1/3)

    前回に引き続き、今回もフレームワークの役割と構築方法について解説します。 サーチエンジンにとってわかりやすいURLにするためには、.phpという拡張子をフロントコントローラから取り除く必要があります。コーディングを少しでも簡単にするため、基的なApacheの設定をいくつか行います。リスト1は、使用するバーチャルホストの基的な設定です。PHPのinclude_path を設定していることに注意してください。 このパスでは通常4項目を指定します。カレントディレクトリ、PEARへのパス、Webアプリケーションのincludeディレクトリ、そしてフレームワークへのパスです。これでフレームワークとWebアプリケーションのファイルインクルードが簡単にできるようになります。 リスト1 <VirtualHost *> ServerName www.example.com DocumentRoot "/

  • [ThinkIT] 第2回:フレームワークの役割と構築方法 ~ 前編 (1/2)

    一般的に、フレームワークには次のような効果を発揮することが求められ、これが多くの開発現場でフレームワークを使う理由にもなっています。 開発スピードのアップは開発者がフレームワークに最も求めているものであり、素早く簡単に成果をあげなければなりません。Web開発に共通で必要なものはフレームワークが提供するので、開発者はアプリケーション特有の機能のコーディングに集中できます。開発者がフォーム入力チェック/データ操作/セキュリティ/セッションやログイン管理などを気にすることがあってはいけません。こういったことはフレームワークで処理されるべきです。

  • [ThinkIT] 第1回:フレームワークの実用化に向けて (1/2)

    フレームワークという言葉が一般的になるずっと以前に、筆者はフレームワークを公開していました。当時は、筆者自身フレームワークを使っているという認識はありませんでした。Wikipediaでは、フレームワークとは「様々なソフトウェア開発で利用できるサポート構造が定義されたもの」とされており、さらに「フレームワークにはサポートプログラム、コードライブラリ、スクリプト言語、別のソフトウェアプロジェクトのコンポーネントを使えるようにするなど、開発に役立つ他のソフトウェアが含まれることもあります」とあります。筆者がはじめてフレームワークを公開したのは1992年であり、当時LingoというMacromediaが開発したDirectorのスクリプト言語を勉強していました。 Lingoは非常に興味深い言語でした。オブジェクト指向言語であり、親子関係と振る舞いの概念に基づいていました。spriteと呼ばれる目に