jjug_night_20161121

Introduction of “ICONIX” Practical Method of OOAD

for not being swept away by trends as a Java User

21th-Nov-2016

Naoya Kojima

@jugemix

Profile

u I am …

u Father / Husband / A just application developer interested in Application design & Testing

u I love making / drinking coffee very much (^^)v

u Specialty

u Automation Test ( with JavaSE AspectJ Junit/TestNG Selenium WebDriver )

u I make a keyword-driven test system.

Notice

um(_ _)m

本題までが⻑いですが、何卒お付き合い下さい。

Today I talk about

Design Software Application Design ICONIX

u(^_^)

u早速ですが

u(^_^;)

uそもそもDesignって何をするんでしたっけ？

What is …Software Design

u Quote from wikipedia https://en.wikipedia.org/wiki/Software_design

u(^_^;)

u･･･難しいですね

u(^_^)

u分からないので調べました

What is …Software Design 2

u Mr. Grady Booch Said …

u “Design is an ordered approach to exploit answers to a problem.”

u Quote from Object-Oriented Analysis and Design with Applications, 2nd Edition 1995


u Dr. Jack Mostow ( Carnegie Mellon University ) Said …

u Purpose of designu Satisfies a given (perhaps informally) functional specification

u Conforms to limitations of the target medium

u Meets implicit or explicit requirements on performance and resource usage, e.g., time, space, power, cost

u Satisfies implicit or explicit design criteria on the form of the artifact, e.g., style, simplicity, testability, maintainability, reliability, reusability, manufacturability, modularity, etc. ( Make Quality !! )

u Satisfies restrictions on the design process itself, such as its length or cost, or the tools available for doing the design (e.g., drafting table versus graphic editor).

u Quote from Toward Better Models Of The Design Process 1985


u Bjarne Stroustrup (development of the C++ programming language. ) Said …

u Purpose of design

u The purpose of the design is to create a clear and relatively simple internal structure, what is called an architecture. Design is the final product of the design process.

u Quote from Object-Oriented Analysis and Design with Applications, 2nd Edition 1995


u Mr. Grady Booch summarize …

u The design includes tasks to balance the competing set of requirements,

u allowing you to think logically of the structure,

u considering trade-offs when requirements collide,

u and in general the implementation's perspective.

u The model that provides the design is the deliverable of the design.

u(^_^;)

u結局、何をすればDesignと⾔えるのかな？

u(^_^;)

uそれに･･･そもそもSoftwareって何でしたっけ？

Software is …Origin

u Quote from Wikipedia https://en.wikipedia.org/wiki/Software#Purpose.2C_or_domain_of_use

u by Alan Turing

u part of a computer system that consists of encoded information or computer instructions

u by John W. Tukey ( on developing statistical methods for computers where he invented the term "bit")

u In computer science and software engineering, computer software is all information processed by computer systems, programs and data.

System Software is …indirectly effects

u In low-level language

u Software written in machine language does not directly affect the user.

u But by combining changing the state of the processor, it is possible to give the user an indirect effect such as changing the state of the Personal Computer.

u In high-level language

u Software written in machine language affect the user directly.

Non System Software is …directly effects

u(^_^)

uつまり

Hardware

Low-Level Lang

High-Level Lang

System Software

Application Softwareetc.

Software written in high-level programming language is …

System SoftwareApplicationSoftware

Java Application Software

People

Device Drivers

Java Device Driver

Devices

Utilities

Java Utility Software

Programs

Software Various types of

use useuse

u(^_^)

uSoftwareの種類毎にUser( Actor )が異なる

u(^_^)

uUse CaseはSoftwareのActorに対する振る舞い

u(^_^)

uしかもActorの実体は様々

u (^_^)

u経営を仕事とするActoru⼈事を仕事とするActor

uプリンタ制御をするActoruメモリを管理するActor

uetc･･･

u(^_^)

uSoftwareの種類・⽬的に応じて、設計⽅法も

多様に変化するのでは？

u(^_^)

uSoftwareの種類を限定して設計⽅法を

調べよう

How do I …Design

u With the word of Mr. Booch …

u The design includes tasks

u to balance the competing set of requirements,

u allowing you to think logically of the structure,

u considering trade-offs when requirements collide,

u 要求から問題領域を正確に捉えることu 問題領域から解決領域へたどり着くプロセスを明確にすること

u and in general the implementation‘s perspective model that provides the design is the deliverable of the design.

u 設計の成果物として実装をうながす為の「⾒取り図」的なものを⽤いること

u(^_^)

u抽象的な概念には具体的な実装があるはず

How do I …Application Design

u I thought …u 要求から問題領域を正確に捉えること

u 要求分析（ドメイン分析）

u 問題領域から解決領域へたどり着くプロセスを明確にすることu EAフレームワーク（ザックマン、TOGAF、FEAF、経済産業省EA）u OOAD（ICONIX、責務駆動設計、ドメイン駆動設計、UP、RUP、etc.）

u 設計の成果物として実装をうながす為の「⾒取り図」的なものを⽤いることu アーキテクチャ記述u UML（シーケンス図、クラス図、etc.）

u(^_^)

uApplication Designはこんなイメージ

How do I …Application Design 2

u Abstract Application Structure

Requests

Application

Architecture

SomethingAnalysisDesign

u(^_^)

uということで

How do I …Application Design 3

u In order to create an application, it is necessary to design u The application architecture

u Something that makes up the architecture

u(^_^;)

u何度もすみません。Architectureって何でしたっけ？

What is …Application Architecture

u Quote from Software Architecture Review and Assessment (SARA) Report Version 1.0

u Quote from ⾮機能要件記述とアーキテクチャ記述ガイド IPA SEI 2010年3⽉

What is …Application Architecture 2

u Quote from Patterns of Enterprise Application Architecture

u アーキテクチャとはu 主観的要素（重要とする要素により、形を変える）u PJの熟練開発者がシステム設計に関して共通に理解していること

u 共通理解u システムの主要なコンポーネントu コンポーネントの相互作⽤

u 主要なコンポーネントu 後で変更することが難しい決定事項u ⼈の性格のようなもの（私⾒）


u Quote from ⾮機能要件記述とアーキテクチャ記述ガイド IPA SEI 2010年3⽉

u(^_^)

uつまり


u Abstract Application Structure

Requests

Application

Architecture(Main-Components & Relations)

Non-Architecture(Other Components & Relations)

AnalysisDesign


u (^_^)

u Application Architectureの詳細は勉強中なのでまた今度

uここではNon-Architectureの設計に限定して議論しましょう

u(^_^;)

uところで･･･毎度申し訳ありませんが、

Componentって何でしたっけ？

What is …Component

u Quote from CMU SEI http://www.sei.cmu.edu/architecture/start/glossary/

u(^_^;)

u分かりづらいので、これも調べましょう

What is …Component 2

u Quote from 「オブジェクトデザイン」（レベッカ・ワーフスブラック他）

u She said …

u ⼀般的に多くの異なるアプリケーションで使⽤することを意図した設計要素。

u コンポーネントを使えば、システムの残りの部分を構成し直すことなく、更新や交換でき、そうなるようにインターフェースが設計される。

u Translator notes …

u フレームワークを「⼤きな粒度の再利⽤」と考えると、コンポーネントは「中程度の粒度の再利⽤」単位と考えることができる。

u ⼀⽅、単⼀のクラスは再利⽤を⾏う単位としては「⼩程度の粒度の再利⽤」単位と考えることができる。

u(^_^)

uつまり

What is …Component 3

u Abstract Component Structure

Requests

Application

Architecture

ComponentsObject Object Object Object

AnalysisDesign

Noteアーキテクチャを考慮すると、本定義だけに限定されないと考えています

u(^_^)

uApplicationは複数のObjectで構成されることが分かりました

u(^_^)

uではオブジェクト指向でDesignを考えていきましょう

u(^_^;)

uところで･･･毎度申し訳ありませんが、Objectって何でしたっけ？

What is …Object

u Quote from 「オブジェクトデザイン」（レベッカ・ワーフスブラック他）

u I understood that…

u ソフトウェアは部品を元に設計される

u このソフトウェア部品はオブジェクトである

u オブジェクトは他の部品に対してリクエストをして相互作⽤する

u この為、オブジェクトにはリクエストに応える義務が、ある期間に発⽣する

u つまり、オブジェクトには役割があり、役割通りに動作する責任が発⽣するu また、オブジェクトは役割通りに動作をする為の判断材料となる情報を持つ

u(^_^)

uつまり

What is …Object 2

責務

動作の実⾏義務

情報の蓄積義務

Noteタスクの実⾏を補助判断する為に利⽤される

Note適切に動作する為には判断材料（情報）が必要

ロール

責務責務

責務

What is …Object 3

役割を通して関連するタスク、情報の集合

What is …Object 4

Object

ロール

ロール

ロール

What is …Object 5

“右向き”

“左向き”

ComponentCollaboration of Objects

Encapsulated Info“回転⽅向”

Object

Task“回転する”

u(^_^)

uよって

Object-Oriented Analysis and Design

u Abstract OOAD Structure

Requests

Application

Architecture

ComponentsObject Object Object Object

AnalysisDesign

Object

Roles

Responsibilities

Task Info

has

Roles

Object-Oriented Analysis and Design余談u Architecture と Non-Architecture の設計順序

u Applicationの重要な要素であるArchitecture を設計してからComponentの設計を⾏うことが⼀般的な考え⽅である

u ApplicationがRoles（役割）を持つことから、⼀⽅でRolesの配置先が明⽰されていれば、ある程度並⾏して⾮主要コンポーネントを予備設計しておいても、詳細設計前には紐付けすることをできるのではないだろうか

u(^_^)

u設計すべき対象について理解できました

u(^_^;)

uでもObjectの設計は具体的にどう進めればいいのかな？

The ICONIXPractical Method of OOAD

u Quote from 「Use Case Driven Object Modeling with UML Theory and Practice」Doug Rosenberg, others.

u Abstraction of ICONIXu ICONIX⾃体はOOADよりも広い範囲をサポートする開発⼿法u 静的＋動的なワークフローが構成するイテレーティブなプロセスu １イテレーションでは、ユースケースまたはその論理的な集合に対して、要求分析〜単体テストをスコープとする実践的な⼿法

u イテレーティブな為、agileプラクティスとの親和性が⾼いu UP（統⼀プロセス）よりも使⽤するUMLやドキュメントの種類が少なく、軽量である

u 他の⼿法との折衷案を採⽤してもよい（私⾒）u マイルストーンと確認ポイントが⽰されているので分かりやすい

The ICONIXPractical Method of OOAD 2

u Abstraction of ICONIX Process （One Iteration）

要求定義機能要求振る舞い要求ドメイン分析

ドメインモデリングレビュー

要求分析

予備設計ロバストネス分析

属性追加（ドメインモデルの更新）

コントローラオブジェクトの識別

レビュー

詳細設計シーケンス図作成操作の追加（ドメインモデルの更新）

シーケンス図の更新レビュー

実装コーディング

ユニットテスト実施

統合テスト、テストシナリオの実施

コードレビュー各モデルの更新 To Next Iteration


u 要求定義

機能要求

•システムができることを記述する。

•例）1ヶ⽉ログインのないユーザは、パスワードを再設定しなければならない。

振る舞い要求

•アクター（ユーザ、システム等）との対話を叙述的に記述（ユースケース記述）する。

•例）ログイン画⾯で、ユーザはIDとパスワードを⼊⼒する。システムは、ユーザの最終ログイン⽇を取得し、現在⽇付との⽐較結果が１ヶ⽉以内かを判定する。また、ログイン情報と⼀致するかを判定する。システムは、判定結果を元にメニュー画⾯を表⽰する。

ドメイン分析、モデリング

•ユースケース記述から問題領域のオブジェクトを抽出する。

•抽出にはCRCカードを使うとオブジェクトの⽬的、責務、相互作⽤先の候補を挙げやすい。（私⾒）

•ドメインオブジェクト同⼠を相互作⽤の観点で結ぶ。


u 分析・予備設計ロバストネス分析

•ユースケース記述をロバストネス図上に表現する。

•UC記述中、オブジェクトはバウンダリ、エンティティとし、タスク・処理はコントローラとする。

•例）ログイン画⾯で、ユーザはIDとパスワードを⼊⼒する。システムは、ユーザの最終ログイン⽇を取得し、現在⽇付との⽐較結果が１ヶ⽉以内かを判定する。また、ログイン情報と⼀致するかを判定する。システムは、判定結果を元にメニュー画⾯を表⽰する。

ドメインモデルの更新１

•ロバストネス図を記述した結果、ドメインモデルに不⾜するオブジェクトがあれば追加する。

•例えば、UC記述上ではユーザはアクターだが、判定処理を⾏う際にIDとパスワードはどこに格納しておくのか？

•結果、「ユーザ情報」というエンティティ（タスクの実⾏を補助判断する情報を格納するオブジェクト）が必要であると考えることができる。

•IDとパスワードはユーザ情報の属性とする。

コントローラオブジェクトの識別

•ロバストネス分析の結果、次の箇所をコントローラの候補とする。

•「ユーザの最終ログイン⽇を取得」

•「現在⽇付との⽐較結果が１ヶ⽉以内かを判定する」

•「ログイン情報と⼀致するかを判定する」


u 詳細設計

シーケンス図作成

•ロバストネス図から、バウンダリ、エンティティ、コントローラをシーケンス図に反映する。

•例）ログイン画⾯とユーザ情報はオブジェクトとして表現する。

•例）「ユーザの最終ログイン⽇を取得」、「現在⽇付との⽐較結果が１ヶ⽉以内かを判定する」、「ログイン情報と⼀致するかを判定する」、「メニュー画⾯を表⽰する」は相互作⽤（オブジェクト間のメッセージ）として表現する。

ドメインモデルの更新２

•シーケンス図を記述した結果、ドメインモデルのオブジェクトにメッセージを追加する。

•その他、メッセージのインプット（引数）、アウトプット（戻り値）等からオブジェクトに不⾜する属性を判断する。

•この結果、ドメインモデルはクラス図として完成する。

シーケンス図の更新

•Java EEやフレームワークを利⽤する場合は、RequestDispatcherの実装オブジェクトもシーケンス図上で表現することでActorとオブジェクト間の相互作⽤がより詳細に分かるようになる。


u 実装

コーディング・ユニットテストの記述

• 完成したクラス図を元にクラスを実装する。

• 設計を元にユニットテストを記述する。

統合テスト・テストシナリオの実施

• 設計を元に統合テスト、テストシナリオを実装する。

• テストシナリオにおいては、ユースケースを元に実装することでユースケーステストを設計することができる。

コードレビュー・各モデルの更新

• コードレビューを実施し、パターンの適⽤や適切な責務の実装を促す。

• 次のIterationに備えてモデルを更新する。

u(^_^)

u設計をする上で⾃分の軸になりそうです

u(^_^)

u次回LTでは実践編を紹介したいと思います

um(_ _)m

どうもありがとうございました

Engineering

jjug_night_20161121