ITアーキテクトを目指す多くの人々は、現在、プログラミングを主な作業として仕事に従事しているのではないだろうか。プログラミングを行う場合、Javaなど特定の言語のみを主軸としている人と、振られる仕事によって言語を切り替えるような、複数の言語を同時に操っている人とに分かれるだろう。今回はプログラミング言語を中心とした開発系の話が中心である。 ソフトウェアはある特定の環境でしか動作しない ソフトウェアはそもそも、特定の基盤技術の上（特定のハードウェアやOSの上ということ）で、特定のコンパイラを用いて、特定の言語を操作して構築するものだ。このうち、どれか1つでも“特定”という条件から外れた場合、そのソフトウェアは動作しない。それは、ハードウェアやOSから独立した特定のバーチャルマシン上で動作するJavaクラスファイルでも同じ話だ（例えば、PC-AT互換機であろうとも、Java SE 5.0仕様V
「こんな感じでできました。ちょっと見てもらっていいですか？」 「ようやくできたか。これはどういう構成になってる？」 「ベース部分にオープンソースのライブラリを使ってるんですが、デキがあまり良くない部分があったんで改良を加えてます。これなかなかすごいんですよ」 「えーと、そのライブラリの内容は？ ライセンスは？ ドキュメントは？」 「まだあんまり有名じゃないんですけど、ベータ版の段階ですから手を加えました。ちゃんと本家にフィードバックします。ライセンスは作者がいいかげんなのか何も書いてませんね。ドキュメントはソースコードそのものです（笑）」 「悪いが全部作り直してくれ。客には謝っておく。ちょっと頭を冷やしてくれ」 「え？」 このやりとりについて、どこに問題があるのか、念のために指摘しておこう。オープンソース利用時によく指摘されている「ライセンス形態が不明瞭」などという問題があるのは当然だろう
俺の図書館フォルダが火を吹いたんだぜ ■次【第三弾】 →sm3080570 ■新作【第六弾】→sm19955600 ■マイリスト →mylist/6277180
.NETアプリケーションのアーキテクチャやフレームワーク、設計に役立つ情報を中心に紹介しています。また業務システムに役立ちそうなユーティリティやノウハウをサンプルコードつきで公開しています。言語はC#とVB.NETを扱っています。 UMLでクラス間の関係が集約とコンポジションである場合の実装例をC#とVBで紹介する。集約は白抜きのひし形を付けた関連で、コンポジションは黒塗りのひし形を付けた関連であり、どちらも関連の一種である。その違いを簡単に説明すると、集約が弱い結びつきであるのに対して、コンポジションは一心同体の強い結びつきを表す。集約は、関連する先のオブジェクトが最初からある場合もあるし、外したり、後から追加されたりするような関係である。一方、コンポジションはオブジェクトが生成されるときに、関連する先のオブジェクトも同時に生成され、破棄されるときは同時に破棄されるような関係である。 実
図1●オブジェクト指向の問題点を解決する オブジェクト指向技術が浸透するにつれ，その問題点が明らかになってきた。これを解決するキーワードが「疎」である。 図2●部品化のメリット システムを分割してうまく部品化できれば，さまざまなメリットが生まれる。中でも重要なものは，同じ部品を他のシステムで再利用できること，変更を加えたときに影響が及ぶ範囲を部品内に限定できること，部品を別のものに入れ替えることでシステムの変更や拡張が容易になること，である。 オブジェクト指向言語の考え方が登場してから30年余。オブジェクト指向は，ソフトウェア開発の現場にようやく定着してきた＊1。システム・インテグレーションの現場では「案件のほぼすべてが，オブジェクト指向開発」（日本ユニシス・ソリューション AD CoE コンピテンスセンタ統括部長の川口真一氏）。「システムを発注する側が，設計情報をUML（Unified
フレームワーク活用の「ツボ」がわかる！ 本書はWebアプリケーションの設計・開発におけるフレームワークの利用について解説したものです。Webアプリケーション開発では、MVC（Model/View/Controller）や3層アーキテクチャなどを採用した開発の枠組み（フレームワーク）が用いられます。本書はそのフレームワークの思想に沿ったアプリケーションの設計とプログラミングを実践的に解説するものです。フレームワークの狙いはどこにあるのか、効率的な開発と改修のためにはどう考えていくべきなのかを学ぶことができます。また、サンプルとしてS2StrutsによるJavaのアプリケーションを提供していることも本書の大きな特徴です。 筆者のシステム開発者、インストラクターとしての経験を活かし、さまざまな現場で応用可能な基本的技法をやさしく身に付けられます。 第1章 イントロダクション―エンジニアのスキルと
なぜ、要求を管理する必要があるのか なぜ、要求を管理するのでしょうか？ 一言でいうと、要求を管理することが、プロジェクトの成功を大きく左右するからです。まず、一般的なプロジェクトのゴールを考えてみましょう。次のような定義を見てください。 「顧客の真のニーズを満たす」「高品質」「期間内」「予算内」という4つのキーワードが出てきますが、どれも要求管理と大きくかかわってきます。まず、「高品質」な製品を作るためには、要求管理において、信頼性やスループットといった製品の機能面以外の要求も確実に把握することが重要です。また、「期間内」「予算内」で製品を開発するには何が問題でしょうか？ プロジェクトは、時間と予算とリソースが制限された状態で製品を開発しなければなりません。与えられた時間、予算、リソースを用いてどれくらいの作業ができるか考慮して、製品の要求仕様の範囲を、作業が可能である範囲に抑えねばならな
ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系 作者: F.ブッシュマン,H.ローネルト,M.スタル,R.ムニエ,P.ゾンメルラード,Frank Buschmann,Hans Rohnert,Michael Stal,Regine Meunier,Peter Sommerlad,金沢典子,桜井麻里,千葉寛之,水野貴之,関富登志出版社/メーカー: 近代科学社発売日: 2000/12メディア: 単行本購入: 15人 クリック: 448回この商品を含むブログ (54件) を見るPattern-Oriented Software Architecture, A System of Patterns (Wiley Software Patterns Series) 作者: Frank Buschmann,Regine Meunier,Hans Rohnert,Peter Somme
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して で以下のようなコメントをいただきました。 アプリケーションのアーキテクトという役割についてちょっと理解が曖昧だったのがこのエントリ読んでだいぶスッキリした。今度の開発系の勉強会のネタにとりあげようかな アーキテクトの働き方の参考に。 そもそもオブジェクト指向を本当に理解していてプログラミングも得意なアーキテクトがどれくらい居るのやら。 全体の設計がちゃんと推敲されていて、きちんと疎結合が達成されているなら、後の修正にも耐えられる。 アーキテクトが何をどこまで責任持つのか、という認識が整合されてないんじゃないの 現代的アーキテクトの仕事 このようなコメントから、「アーキテクト」という仕事の内容については、実はよくわからないと考えている方が多いように感じられます。実は、私自身も「アーキテクトという役割で仕事をす
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: :
Amazon.co.jp: 職業としてのソフトウェアアーキテクト (Software Architecture Series): マークスウェル (著), ローラスウェル (著), 倉骨彰 (翻訳): 本
Amazon.co.jp: はじめての設計をやり抜くための本: 概念モデリングからアプリケーション、データベース、アーキテクチャの設計まで: 吉原庄三郎: 本
Amazon.co.jp: ＩＴアーキテクトのやってはいけない 設計、メソドロジ、実装・テスト、運用、セキュリティのアンチパターン (日経BPムック): 日経SYSTEMS: 本