Use-Case Driven Design(ユースケース)에 대해

ユースケース（Use Case）とは、ソフトウェア工学やシステム工学でシステム（あるいはシステムのシステム）の機能的要求を把握するための技法である。各ユースケースは、何らかのビジネス目標/機能に関するシナリオでのアクター(actor)と呼ばれるユーザーとシステムのやりとりを描いたものである。ユースケースのアクターはエンドユーザーの場合もあるし、別のシステムの場合もある。ユースケースでは技術専門用語をなるべく使わず、エンドユーザーやそのビジネスの専門家に分かり易い用語を用いる。ユースケースの作成は、ビジネスアナリストとエンドユーザーが共同で行うことが多い。ユースケースとユースケース図は厳密には区別されるべきものである。

 

유스케이스 (Use Case)는 소프트웨어 공학 및 시스템공학 시스템 (또는 시스템의 시스템)의 기능적인 요구를 파악하기 위한 기법이다. 각 유스케이스는 어떤 사업목표/기능에 대한 시나리오의 엑터 (actor)라는 사용자와 시스템의 상호 작용을 그린 것이다. 유스케이스의 액터는 최종사용자의 경우도 있고, 다른 시스템인 경우도 있다. 유스케이스는 기술용어를 가급적 사용하지 않고 최종사용자와 그 비즈니스 전문가에 알기 쉬운 용어를 사용한다. 유스케이스의 작성은 비즈니스 분석가와 최종사용자가 공동으로 할 것이 많다. 유스케이스와 유스케이스 다이어그램은 엄격히 구별되어야 할 것이다.

 

1986年、後に統一モデリング言語(UML)やラショナル統一プロセス (RUP) で重要な役割を演じたイヴァー・ヤコブソンは、初めてユースケースの視覚化モデリング技法を成文化した。当初彼は usage scenarios とか usage case という用語を使用していたが、それらが英語として不自然であると気づき use case という用語を使うようになった[1]。ヤコブソンが創始したユースケースのモデリングに対して、Kurt Bittner、Alistair Cockburn、Gunnar Overgaard といった人々が改良を加えていった。

 

1986년 이후 통합 모델링 언어(UML)와 합리적인 통합 프로세스 (RUP)에서 중요한 역할을 맡은 이봐와 야콥손은 처음 유스케이스의 시각화 모델링 기법을 성문화했다. 당초 그는 usage scenarios 라든지 usage case 라는 용어를 사용하고 있었지만, 그들이 영어로 자연스럽지 않다고 느껴, use case라는 용어를 사용하게 되었다. 제이콥슨이 창시한 유스케이스 모델링에 대해 Kurt Bittner, Alistair Cockburn, Gunnar Overgaard 같은 사람들이 개량을 더해 갔다.

 

1990年代、ユースケースは機能要求を把握する手法として最もよく使われるようになってきた。特に元々の発祥の分野であるオブジェクト指向関連で顕著であるが、ユースケースの有効性はオブジェクト指向に限らない。というのも、ユースケース自体は本質的にはオブジェクト指向とは無関係だからである。

 

1990년대 유스케이스는 기능 요구를 파악하는 방법으로 가장 많이 사용되게 되어왔다. 특히 원래의 발상 분야인 객체 지향 관련이 현저하지만 유스케이스의 효과는 객체 지향에 없다. 왜냐하면 유스케이스 자체는 본질적으로 객체 지향과는 무관하기 때문이다.

 

 

システム工学において、ユースケースはソフトウェア工学よりも抽象度の高いレベルで利用され、システムの任務やシステム保有者の目標を描くのに使われることが多い。より詳細な要求は SysML のリクワイアメント図などで把握される。

 

시스템 공학에서 유스케이스는 소프트웨어 공학보다 추상적인 수준에서 이용된 시스템의 임무 및 시스템 보유자의 목표를 ​​그리는 데 사용되는 경우가 많다. 자세한 요구는 SysML의 리콰이어먼트도 등으로 파악된다.

 

 

ユースケースの目的と範囲

유스 케이스의 목적과 범위

 

各ユースケースは、1つの目標やタスクを成し遂げる方法を描く。ほとんどのソフトウェアプロジェクトでは、開発予定のシステムに関するユースケースを数十ほど描く必要がある。そのソフトウェアプロジェクトの形式性の度合いやプロジェクトの段階によってユースケースに求められる詳細さのレベルが変化する。

 

각 유스케이스는 하나의 목표와 작업을 달성하는 방법을 그린다. 대부분의 소프트웨어 프로젝트에서 개발하려는 시스템에 관한 사례를 수십 페이지정도를 그릴 필요가 있다. 소프트웨어 프로젝트의 정형화 정도나 프로젝트 단계에 따라 유스케이스에 요구되는 상세 수준이 변화한다.

ユースケースとシステムの機能は必ずしも一致しない。1つのユースケースが複数の機能に対応していることもあるし、1つの機能が複数のユースケースに対応していることもある。

 

유스케이스와 시스템 기능은 반드시 일치하지 않는다. 하나의 유스케이스가 여러 기능을 지원하는 것도 있고 하나의 기능이 여러 유스케이스에 대응하고 있는 것도 있다.

 

ユースケースは、あるゴールを成し遂げるにあたっての外部のアクターとシステムとのやり取りを定義する。アクターはそのシステムとやり取りする人間や物の「役割」である。実際には1人の人間であっても、役割が複数あれば複数のアクターとして描かれる。例えば、A さんが現金自動預け払い機(ATM)で預金を引き落とす場合には「顧客」であるが、同じ A さんが実は「銀行員」として ATM にお金を補充するなら、それは別の役割である。

 

유스 케이스는 하나의 목적을 달성하는 데에 있어서 외부 행위자와 시스템 사이의 상호 작용을 정의한다. 액터는 시스템과 상호 작용하는 인간과 사물의 "역할"이다. 실제로 1명의 인간도 역할이 여러 있으면 여러 행위자로 그려진다. 예를 들어, A 씨가 현금 자동 입출금기 (ATM)에서 예금을 인출하는 경우에는 「고객」이지만, 같은 A 씨가 실은 '은행원'으로 ATM에 돈을 보충한다면, 그것은 다른 역할 있다.

 

ユースケースではシステムをブラックボックスとして扱う。したがってシステムの反応を含めたシステムとのやり取りは外部から観測されるものとして描かれる。これは意図的に設定された方針であり、ユースケース作成者はシステムがどう動作するかではなく何をするかに集中しなければならない。これによって特定の実装方法を暗黙のうちに前提としてしまう罠を避けるのである。

 

유스 케이스는 시스템을 블랙박스로 취급한다. 따라서 시스템의 반응을 포함한 시스템과의 상호작용은 외부에서 관측되는 것으로 그려진다. 이것은 의도적으로 설정된 정책이며, 유스케이스 작성자는 시스템이 어떻게 작동하는지가 아니라 무엇을 할 것인가에 집중해야한다. 이에 의하여 특정한 구현 방법을 암묵적으로 전제하고 버리는 함정을 피하는 것이다.

 

ユースケースには、ビジネスユースケースとシステムユースケースがある。これらの違いはその対象範囲だけである。ビジネスユースケースはビジネス全体をブラックボックスとして扱い、そのビジネスと外部のアクターとのやりとりを描く（例えば、顧客が何かを購入するシナリオなど）。ビジネスユースケースの詳細によりビジネスのプロセスが定義される。

 

유스케이스는 비즈니스 유스케이스와 시스템 유스케이스가 있다. 이러한 차이는 그 범위뿐이다. 비즈니스 유스케이스는 비즈니스 전체를 블랙박스로 취급하고, 비즈니스와 외부의 행위자와 상호 작용을 그린다. (예를 들어, 고객이 뭔가를 구입하는 시나리오 등) 비즈니스 유스케이스의 상세 의해 비즈니스 프로세스가 정의된다.

 

ビジネスユースケースを具体化することで、労働者がそのビジネスでどのように協力してビジネスの外部アクターに価値を提供するかが説明される。労働者の一部でも自動化されるなら、その自動化される部分はシステムユースケースの対象となる。その場合、他の労働者や外部アクターはそのシステムユースケースでのアクターとなる。

 

비즈니스 유스 케이스를 구체화하여 근로자가 그 사업에서 어떻게 협력하여 사업 외부 행위자에게 가치를 제공하는지가 설명된다. 노동자의 일부라도 자동화된다면 그 자동화되는 부분은 시스템 유스 케이스의 대상이 된다. 이 경우 다른 노동자와 외부 행위자는 그 시스템 유스케이스에서 액터가 된다.

 

ユースケース作成の際の注意点は以下の通りである:

∙ 特定のゴールを達成するためにシステムをアクターがどう使うかを 描く。

∙ 実装を限定するような言葉を使わない。

∙ 適切なレベルの詳細さで描く。

∙ ユーザーインターフェイスや表示などの詳細を含めない。

これらはユーザーインターフェイス設計の範疇である。

 

유스 케이스 작성시주의 사항은 다음과 같다 :

∙ 특정 목표를 달성하기 위해 시스템을 배우가 어떻게 사용할 것인가를 그린다.

∙ 구현을 제한하는 것과 같은 말을 쓰지 않는다.

∙ 적절한 수준의 세부로 그린다.

∙ 사용자 인터페이스 및 표시 등의 세부 사항을 포함하지 않는다. 이들은 사용자 인터페이스 설계의 범주이다.

 

ユースケースの書き方

유스케이스 작성방법

 

詳しさの度合い

자세한 정도

Alistair Cockburn の Writing Effective Use Cases には、ユースケース作成にあたって3段階の詳しさのレベルを定義している。

Alistair Cockburn의 Writing Effective Use Cases 에는 유스 케이스 작성에 있어서는 3 단계의 자세한 수준을 정의하고 있다.

 

要約

요약

要約(brief)ユースケースはユースケースをいくつかの文にまとめたものである。これはスプレッドシートを使ってソフトウェア開発を計画するのに最も適している。要約ユースケースはスプレッドシートのセルに書ける程度の長さであり、同じ行の別のセルにビジネス上の優先度、技術的複雑度、リリース番号などを記入する。

요약(brief) 유스케이스는 유스케이스를 여러 문장으로 정리한 것이다. 이것은 스프레드 시트를 사용하여 소프트웨어 개발을 계획하는데 가장 적합하다. 요약 유스케이스는 스프레드 시트의 셀에 쓸 정도의 길이이며, 동일한 행의 다른 셀에 비즈니스 우선 순위와 기술적 복잡도, 릴리스 번호 등을 기입한다.

 

 

略式

약식

略式(casual)ユースケースは、要約ユースケースの内容をより詳しく文章化したもので、ストーリーのような形でそのユースケースを詳述する。

약식 (casual) 유스케이스는 요약 유스케이스의 내용을 더 자세히 문장화한 것으로, 스토리의 형태로 그 사례를 자세히 설명한다.

 

詳細

상세(자세한)

詳細(detailed)ユースケースはいくつもの節に分かれたテンプレートに従って書かれる定形文書である。ユースケースといえばこれを指すのが一般的である。

상세 (detailed) 유스 케이스는 여러 단원으로 나누어 템플릿에 따라 쓰는 정형 문서이다. 유스 케이스라고하면 이것을 가리키는 것이 일반적이다.

 

ユースケースの詳細さのレベルはプロジェクトの段階によっても異なる。最初のユースケースは要約程度でよいが、開発工程が進むに従って、より詳細なユースケースが必要となってくる。このためユースケースに要求されるものは異なってくる。当初はユーザーの観点でビジネス上の要求をまとめるための要約レベルのユースケースでよい。しかし、開発が進むと開発者は設計の指針として詳細なユースケースを必要とするようになってくる。

 

유스케이스의 상세 수준은 프로젝트의 단계에 따라서 다르다. 첫 번째 사례는 요약 정도 있으나, 개발 공정이 진행됨에 따라 더 자세한 유스케이스가 필요하게 된다. 이 때문에 유스케이스에 요구되는 것은 달라진다. 처음에는 사용자의 관점에서 비즈니스 요구 사항을 정리하기 위한 요약 수준의 유스케이스에 좋다. 그러나 개발이 진행될 것으로 개발자는 설계 지침으로 상세한 유스 케이스를 필요로 하게 된다.

 

ラショナル統一プロセスでは、要約ユースケースをユースケース図として描き、コメントとして略式の記述を入れ、さらにイベントの流れについて詳細な記述を加えていく。これらを1つのユースケースツール（つまり、UMLツールなど）で入力できる場合もあるし、もちろん別々にテキストエディタで書くことも可能である。

 

합리적인 통합 과정에서 요약 유스케이스를 유스 케이스 다이어그램으로 그려 주석으로 약식 설명을 넣어 더욱 이벤트의 흐름에 대해 상세한 설명을 더해 간다. 이들을 하나의 유스케이스 도구 (즉, UML 도구 등)으로 입력 할 수 있는 경우도 있고, 물론 별도로 텍스트 편집기로 쓸 수도 가능하다.

 

 

ユースケースの長所

유스 케이스의 장점

 

ユースケースはソフトウェアへの要求仕様を把握する成熟したモデルである。従来、新たなシステムの設計を開始する際には1つの分厚い文書の形式で要求仕様がまとめられていたが、完全性という意味では失敗することが多かった。

유스 케이스는 소프트웨어에 대한 요구 사양 을 파악하는 성숙한 모델이다. 기존 새로운 시스템의 설계를 시작할 때 하나의 두꺼운 문서의 형식으로 요구 사양이 정리하고 있었지만, 완전성 의미에서는 실패하는 경우가 많았다.

∙ （ユースケースを記述することも含めた）ユースケース・モデリン

グは、一般にシステムの機能要求を把握するための素晴らしい技法とされている。

∙ (유스 케이스를 작성할 수도 포함) 유스 케이스 모델링은 일반적으로 시스템의 기능 요구를 파악하는 좋은 기법이라고되어​​있다.

∙ ユースケースは早まった設計を防止する。

∙ 유스 케이스는 조기 설계를 방지한다.

∙ ユースケースは検証可能である。

∙ 유스 케이스는 검증 가능하다.

∙ ユースケースは見積もり・スケジューリングなどの基盤としても

使用できる。

∙ 유스 케이스는 견적 스케줄링 등의 기반으로 사용할 수 있다.

∙ ユースケースはプロジェクト内で再利用可能である。版を重ねる

毎に、要求仕様の把握、プログラマのための開発ガイドライン、テストケース、ユーザー向け文書に利用できる。

∙ 유스 케이스는 프로젝트에서 재사용 가능하다. 판을 거듭할수록 요구 사양 파악 프로그래머를위한 개발 지침, 테스트 케이스 사용자를위한 문서에 유효하다.

∙ ユースケースの代替経路によってシステムの頑健性を強化する

ことができる。

∙ 유스 케이스의 대체 경로가 시스템의 견고성을 향상시킬 수있다.

∙ ユースケースは範囲設定に有効である。ユースケースは

段階的リリースを行いやすくする。プロジェクト内での優先順位に従って、追加・削除が比較的容易である。

∙ 유스 케이스는 범위 설정에 효과적이다. 유스 케이스는 단계적으로 출시를 쉽게 한다. 프로젝트의 우선순위에 따라 추가 · 삭제가 비교적 쉽다.

 

∙ ユースケースはビジネスユーザーに理解しやすいことを旨として

おり、開発者とエンドユーザーの意思疎通に役立つ。

∙ 유스 케이스는 비즈니스 사용자에게 이해하기 쉬운 것을 취지로 하고 있으며, 개발자와 최종 사용자의 의사소통에 도움이 된다.

∙ ユースケースには特別な言語を必要としない。個々のプロジェクト

に合った形で書くことができる。

∙ 유스 케이스는 특별한 언어를 필요로 하지 않는다. 개별 프로젝트에 맞는 형태로 쓸 수 있다.

∙ ユースケースでストーリーを記述することができる。

ユースケースをストーリーやシナリオに変換するのは非常に簡単である。

∙ 유스 케이스에서 스토리를 설명 할 수 있다. 유스 케이스 스토리와 시나리오로 변환하는 것은 매우 간단하다.

∙ ユースケースはユーザーとシステムのやりとりに関するもの

である。ユーザーインターフェイス設計者はソフトウェア本体の開発以前に（あるいは並行して）開発に参加することができる。

∙ 유스 케이스는 사용자와 시스템의 상호 작용에 관한 것이다. 사용자 인터페이스 설계자는 소프트웨어 본체의 개발 이전에 (혹은 동시에) 개발에 참여할 수 있다.

∙ ユースケースは文脈の中に要求仕様を入れ、ビジネスタスクとの

関連でそれらを明確に説明する。

∙ 유스 케이스는 맥락에 요구 사양을 넣고 비즈니스 작업과 관련하여 그들을 명확하게 설명한다.

∙ ユースケース図はシステム開発依頼者にシステムやそのビジネス

領域を理解させやすい。

∙ 유스 케이스 다이어그램은 시스템 개발 의뢰자 시스템 및 그 사업 영역을 이해시키기 쉽다.

 

 

∙ ユースケース図を作成するためのUMLツールが各種存在する。

ユースケースやユースケース図を CASE ツールで作成すれば、他の設計書類と共に統合され、

完全な要求・設計・実装に関する書類が保存できるようになる。

∙ 유스 케이스 다이어그램을 만들기 위한 UML 도구가 각종 존재한다. 유스 케이스와 유스 케이스 다이어그램을 CASE 도구로 작성하면 다른 설계 서류와 함께 통합 된 완전한 요구 · 설계 · 구현에 관한 서류를 보존 할 수 있게 된다.

∙ テストケースの一部（システムテスト、受け入れテスト、

機能テスト）はユースケースから直接作成可能である。

∙ 테스트 케이스의 일부 (시스템 테스트, 인수 테스트, 기능 테스트)는 유스 케이스에서 직접 작성 가능하다.

∙ ユースケースはパフォーマンス・エンジニアリングの

効率的実行に重要である。

∙ 유스 케이스는 성능 엔지니어링 의 효율적 수행에 중요하다.

 

 

 

ユースケースの限界

유스 케이스의 한계

 

ユースケースには以下のような限界もある:

유스 케이스에는 다음과 같은 한계도있다 :

 

∙ ユースケースはシステムに関する機能的でない要求を

把握するのには向いていない。

∙ 유스 케이스는 시스템에 대한 기능이지 않은 요구를 파악하는 데 적합하지 않다.

∙ ユースケースのテンプレートは明確性を自動的に保証する

ことはできない。明確性は作者の技量に依存する。

∙ 유스 케이스의 템플릿은 명확성을 자동으로 보장 할 수 없다. 명확성은 저자의 기량에 의존한다.

∙ 正確性が重要なミッションクリティカルなシステムや

リアルタイムシステムには向いていない。

∙ 정확성이 중요한 미션 크리티컬 시스템과 실시간 시스템에는 적합하지 않다.

∙ エンドユーザーとプログラマについて、ユースケースを正しく

理解する際の学習曲線が存在する。標準化された定義が存在しないため、理解は徐々に深めていくしかない。

∙ 최종 사용자와 프로그래머에 대한 유스 케이스를 제대로 이해하기위한 학습 곡선이 존재한다. 표준화 된 정의가 존재하지 않기 때문에 이해는 점차 깊어 져 갈 수 밖에 없다.

∙ エクストリーム・プログラミングではユースケースが不必要に

文書的になっているとし、むしろもっと単純なユーザーストーリーという手法を好む。

∙ 익스트림 프로그래밍에서는 유스 케이스가 불필요하게 문서를 끌고 있다며 오히려 더 간단한 사용자 스토리 수법을 좋아한다.

∙ ユースケースを書く際に、ユーザーインターフェイスに依存する

レベルをどうすべきかに悩むことがある。理論的にはユースケースはいかなるユーザーインターフェイスも前提としないことになっているが、何らかのインターフェイスを前提としないとユースケースを視覚化できないのである。

∙ 유스 케이스를 작성할 때, 사용자 인터페이스에 의존하는 수준을 어떻게 해야 할 지 고민할 수 있다. 이론적으로는 유스 케이스는 어떠한 사용자 인터페이스도 전제로 하지 않는 것으로 되어 있지만, 어떤 인터페이스를 전제로 하지 않으면 유스 케이스를 시각화 할 수 없기 때문이다.

∙ ユースケースはプラットフォームの要求仕様記述には

向いていない。ユースケースは実装すべき1つのシステムを想定しているが、プラットフォーム（ハードウェアやオペレーティングシステム）はその上でいくつものシステムが動作するのである。

∙ 유스 케이스는 플랫폼의 요구 사양 기술에 적합하지 않다. 유스 케이스 구현해야 할 하나의 시스템을 상정하고 있지만, 플랫폼 (하드웨어 및 운영 체제)는 그 위에 여러 가지 시스템이 작동하는 것이다.

∙ ユースケースは強調されすぎる傾向がある。Object Oriented Software Construction（第2版）でバートランド・メイヤーはユースケースに忠実にシステムを設計するあまり、他の有用な要求分析技法を排除してしまう問題を論じている。

∙ 유스 케이스는 강조되고 너무 경향이 있다. Object Oriented Software Construction (제 2 판)에서 버트 랜드 메이어는 유스 케이스에 충실하게 시스템을 설계한 나머지 다른 유용한 요구 분석 기법을 배제 해 버리는 문제를 논하고 있다.

출처 : https://ja.wikipedia.org/wiki/%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9