DevLOVE名古屋「オブジェクト設計とリーン開発、その実践」に参加しました
2014年5月17日に名古屋で開催されたDevLOVE名古屋「オブジェクト設計とリーン開発、その実践」に参加してきました。その個人的な感想です。 向かい続けることが理想市谷さんのリーン開発のお話後半で、『リーン開発の現場 カンバンによる大規模プロジェクトの運営』に出てくる次の言葉を紹介されていました。 理想とはたどりつくべき場所のことではなく、 ありたい姿に向かい続けることなんだ！ Henrik Kniberg著『リーン開発の現場 カンバンによる大規模プロジェクトの運営』オーム社 2013年 p. 109 私個人もこの種の言葉は大好きです。そして、この種の言葉の背後にある価値観こそ、私がソフトウェアエンジニアとして、プロフェッショナルとして、持っていたいと常々感じているものでもあります。こういった価値観は、少なくともソフトウェアエンジニアとしての仕事の様々な局面で必要となる判断に、大きく影
第2回 似て非なる言葉「オブジェクト」と「エンティティ」の関係 - ITプロフェッショナル・コラム：ITpro
「オブジェクト」と似て非なる言葉に「エンティティ」がある。リレーショナル・データベース設計で使用されるER図（エンティティ・リレーションシップ・ダイアグラム）の「エンティティ」だ。だが「エンティティ」という言葉は，オブジェクト指向の本にも登場する。それが「エンティティ・クラス」という言葉だ。また，UML（Unified Modeling Language）という表記法が登場するまでは，オブジェクト指向分析・設計においてもクラス図の代わりにER図が使用されていたことがある。 それと同様に，いくら説明を聞いても釈然としないのが，リレーショナル・データベースとオブジェクト・データベースの違いだ。それらの違いを概念から探り，整理していく必要がありそうだ。 今回は「オブジェクト」と「エンティティ」の概念の違いについて，アリストテレス先生に聞いてみたい。 （アリストテレスの経歴と業績などについては，末
連載：次世代開発基盤技術“Software Factories”詳解 第2回 開発手法「ソフトウェア・プロダクトライン」とは？（2/2） - ＠IT
そのスコープで提供するシステム利用者の要求機能（フィーチャ）の決定。その要求のうち「長期的に変化する要求」と「変化しない安定した要求」を区別
連載：次世代開発基盤技術“Software Factories”詳解 第2回 開発手法「ソフトウェア・プロダクトライン」とは？（1/2） - ＠IT
従来の開発プロセスの多くは、長期的視点と短期的視点が明確に分離できていない。あるいは、ソフトウェア・システムの各構成部分における要求や技術の変化に対して、その変化のスピードの違いをまとまりとして管理していない。 図1はソフトウェア・システムを構成する複数のサブシステム（アーキテクチャやドメインの単位）*1における変化のスピードの違いを管理する2種類の方法を図示している。 *1 UML 2.0では、サブシステムとコンポーネントの違いは漠然としていて、サブシステムはコンポーネントの特殊なモデルである。また、コンポーネント自体は物理的な成果物ではなく、論理的な設計段階での構成体で、クラス概念を継承する。○はコンポーネントを表し、□はサブシステムを表している。図中の2つのソフトウェア・システムには、それぞれ3つのサブシステムがあり、個別のサブシステムの中には2つずつコンポーネントが含まれている。左
distributed-design
１．概要 １．１ 提案する設計方法の考え方 現在、ビジネス・アプリケーションの分析、設計方法としてよく利用されているのは構造化設計とオブジェクト指向設計である。構造化設計技法は、1970年代にソフトウェアの設計に工学的な手法を取り入れ、標準的なルールに基づいて仕様を記述するという重要な役割を果たし、既に長い間開発現場で利用されてきた。一方、オブジェクトの概念が導入されたのは、1980年代の後半からである。当初は、AdaやSmalltalkによるオブジェクト指向言語による設計のために利用され、純粋にオブジェクトを中心に設計する手法が提案された。この方法は、現実世界に存在するモノがコンピュータの中で構築したオブジェクトの写像と捉えることによって、両者が自然に対応づけられ、GUI(Graphic User Interface)などを用いたシステムでは非常に有効な設計方法として利用された。 ところ
Beyond MVC
PHP Advent Calendar 2013 - 6日目 昨日は@fivestrさんのComposerを使った簡単Travis CI設定でした。 TL;DR オブジェクト指向/MVCでうまく捉えきれていなかったものは何なのか？MVCから続くソフトウェアアーキテクチャーの「その先」は何なのか？Reenskaug博士を知っていますか？ WikipediaによればReenskaug博士は1930年生まれ。MVCという概念が世の中に送り出された論文『MODELS - VIEWS - CONTROLLERS (pdf)』は1979年ですから、49歳の時ということになります。1960年からソフトウェアを書き始め、1973年からオブジェクト指向でソフトウェアを開発しており、現在でも現役でソフトウェアの世界にいらっしゃいます（ex 2009年の講演）。「プログラマ歴42年 (* Clean Coder
Signs of the Next Paradigm Shift: Part II
Software: The Next Generation Signs of the Next Paradigm Shift: Part II by James O. Coplien August 24, 2006 Summary In Part I, I related a resurgence in interest in multi-paradigm design about thirteen years after its first appearance. In this 'blog I consider what such developments portend for curriculum design and, in fact, the basic content of any CS program. So: What if I was right? My last 'b
渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - 設計方法論
三要素分析法の特徴（オブジェクト指向分析手法との違い） 三要素分析法は企業システムの設計に特化した方法です。つまり、「企業システム」という特定のドメイン（問題領域）の特性に合わせてまとめた手法であるため、森羅万象を扱えるような万能の分析・設計手法ではありません。 オブジェクト指向分析手法との違いはまさにそこにあります。オブジェクト指向分析手法は、「プログラミングの枠組み」から発展したものであるため対象とするドメインを限定しない代わりに、汎用的であるゆえのモデリングの難しさがつきまといます。いっぽう三要素分析法は企業システムの枠組みにもとづいたものなので、「ゲームソフト」や「組み込みソフト」の開発プロジェクトで使えるものではありませんが、企業システム開発を専門にしているＳＥやエンドユーザには理解しやすい手法です。 では、そもそも「企業システムの枠組み」とはどのようなものなのでしょう。
オンデマンドCRMのリーディングカンパニー セールスフォース・ドットコム - salesforce.com
営業・カスタマーサポート・メール配信の機能がひとつになったCRMの活用で、短期間で導入効果とビジネスの成長を実現
凝集度と結合度：このコードのどこが悪いのか？：＠IT
前編「ソフトウェアの品質を数値化して確かめる」では結合度について少し触れましたが、今回は結合度とともにソフトウェア設計において古くから知られている凝集度についても紹介し、ソフトウェアメトリクスの解説をしていきます。 抽象的な話だけになってしまうと、具体的なイメージがつかみにくいので、実際のプログラムコードを示し、何が良くて、何が悪いのかを明確にしていきます。理論的な話も重要ですが、メトリクスの測定が実際にどう評価されるかを理解して、良いプログラムを作れるようになる手助けになれば幸いです。 それでは、メトリクスの詳細を見ていきます。 1. 凝集度と結合度 1.1. 凝集度とは？ 凝集度とは、クラスやパッケージ内の機能要素と情報要素間の関連性の強さを表す指標です。互いに関連する機能や情報があちこちに分散していると、仕様変更が生じた場合の影響範囲が広くなってしまいます。これらの機能や情報が局所化
＠IT：初めてのソフトウェアメトリクス（後編）
初めてのソフトウェアメトリクス（後編） ソフトウェアメトリクスを現場に組み込む テクノロジックアート 長瀬嘉秀｜矢野大介 2006/1/14 前編（ソフトウェアの品質を数値化して確かめる）、中編（凝集度と結合度：このコードのどこが悪いのか？）を通じて、ソフトウェア・メトリクスの概要を解説しながら、ツールを利用したメトリクス測定による問題点の抽出方法を提示しました。今回は、実際の開発現場で設計改善するときの問題点や、メトリクス測定を利用した改善方法を説明します。 1. 開発現場の現状 一般的に、開発が進み、機能が増えていくに従って、図1のような複数のクライアントコードからロジックコードが呼び出されるような構造になっていきます。図1で明らかなように、依存性がとても複雑になるため、徐々に拡張性や可読性、保守性が悪化していきます。また、単純に重複したコードを共通化・共有していくと、さらに複雑さが増
Episode #001: Design is Hard - Elephant in the Room
Podcast on PHP, Software Design, and Testing, by @everzet and @mathiasverraes Hello world! We are Konstantin Kudryashov aka @everzet and Mathias Verraes aka @mathiasverraes. We decided at the PHPNW13 conference to start a PHP podcast. In our very first podcast episode ever, we discuss the importance of design. And, because we might as well start with a bang, we talk about caching and naming things
RPA Migration, Analytics, & Process Improvement | Blueprint
Blueprint: Migrate your RPA estate automatically Automation is meant to reduce manual effort. Then why are companies still migrating RPA platforms manually? It's risky, labor-intensive, and expensive...but it doesn't have to be! Migrate to an intelligent automation platform the quick & easy way Organizations are facing a lot of challenges with their legacy RPA tools: inflated costs, a high degree
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Visualization Mnemonics for Software Principles
Hexagonal Architecture
Agility and the essence of software architecture by Simon Brown [PDF]
http://www.s-lagoon.co.jp/newron/ss00Nakatani.pdf
ソフトウェア品質管理に向けた静的メトリックスの検討 (PDF)
GOTO Berlin 2013 Conference
10月にベルリンにおける最初のGOTOカンファレンスがやって来る
