[펌] UML

객체지향 모델링과 다른 방식의 모델링과의 차이점

##########0* ##########1* ##########2* 정보공학(Information Engineering)은 기업의 업무처리용 SW개발에 적용된 모델링 체계입니다. 정보공학은 구조적 기법중 하나로 처리절차보다는 기업의 정보구조를 중시하는 모델링 체계입니다. 다음은 정보공학에서 정의한 세 가지 관점의 모델링입니다. ##########3* ##########4* 구조적 기법 ##########5* ##########6* 프로세스 모델링 ##########7* 프로세스 모델링은 SW시스템의 기능을 구조적으로 정의해 나가는 과정입니다. 업무를 분석함으로써 도출한 업무 기능을 계층적으로 분할하여 기능-서브기능- 프로세스-서브프로세스-단위 프로세스로 분할하여 나가는 것입니다. ##########8* 이렇게 정의해 나가면 프로세스 모델의 최 하단에는 시스템을 구성하는 최소의 프로그램 단위가 정의됩니다. top-down방식을 적용한 이 프로세스 모델링의 결과물을 "기능차트"라고 합니다. ##########9* ##########10* ##########11* 이벤트 모델링 ##########12* 이벤트란 시스템이 기능으로 처리하여야만 하는 시스템 내,외부의 사건입니다. 이벤트 모델링은 시스템이 처리해야 하는 이벤트는 무엇이 있으며, 이벤트가 발생하였을 때 시스템이 어떤 순서로 어떻게 반응해야 하는 가를 정의하는 것입니다. ##########13* 이 이벤트 모델링은 사건과 처리라는 자연스런 문제해결 논리를 시스템 구축과정에 응용한 것으로, 모든 사건과 모든 처리는 곧 시스템이 되는 것으로 생각할 수 있습니다. ##########14* ##########15* ##########16* 데이터 모델링 ##########17* 데이터 모델링은 시스템이 어떤 정보를 내부에서 관리하고, 유지해야 하는지를 정의하는 과정입니다. 데이터 모델링은 위 두 가지 모델링을 포함한 정보공학의 세 가지 모델링 중 가장 중시되고, 중앙에 존재하는 모델입니다. ##########18* 정보공학에서의 이 데이터 모델링에 기존의 Entity Relationship Diagram(ERD)를 적극 수용하여, 데이터 모델의 정합성과 일관성을 확보하려고 하였습니다. ##########19* ##########20* ##########21* ##########22* ##########23* 개요 ##########24* ##########25* 객체지향 모델링 특히 UML(Unified Modeling Language)을 적용한 객체지향 모델링은 현존하는 모든 모델링 기법에 비해 진보된 것입니다. 정보공학이 제공하는 프로세스 모델링, 이벤트 모델링, 데이터 모델링은 객체지향 모델링에서도 수용하고 있으며, 다른 방식의 모델링 체계도 제공하기 때문입니다. 물론, 정보공학 모델링 방식 그대로를 수용한 것은 아니며 다른 형식으로 같은 목적을 달성할 수 있게 제공합니다. ##########26* 객체지향 모델링은 정보공학에는 없는 동적 모델링과 아케텍처링을 제공합니다. ##########27* 동적 모델링 ##########28* SW의 단위 구성원(객체지향에서는 객체)이 동적으로 어떤 연관관계를 가지면서 동작하는가를 정의하는 과정입니다. 주어진 이벤트와 동적 여건에 대하여 어떤 객체들이 관여하게 되고, 이들 간에는 어떤 순서로 어떤 메시지를 교환하면서 외부의 요청을 처리하는 지를 정의하는 것입니다. ##########29* 즉, 문제를 해결해 가는 시스템 내부의 처리과정을 정의해 나가는 것이 동적 모델링입니다. 동적 모델링을 수행하면 불필요한 실행모듈을 줄이고 S/W시스템을 오류없이 정확하게 동작하게 하고, 프로그램 코딩 근거를 제시하게 됩니다. ##########30* ##########31* ##########32* SW 아키텍쳐링 ##########33* 아키텍쳐는 S/W시스템 구성요소들을 책임과 역할에 따라 엄격하게 분류하고, 구성요소간 상호작용의 원칙을 정의한 것을 말합니다. 객체지향 기법하에서는 아키텍쳐의 표현이 용이하게 됩니다. S/W 시스템 개발시 효율적인 아키텍쳐를 구현하면, 유지보수가 쉬워지고, 재사용에 의한 개발 생산성도 높아집니다. ##########34* 또한 다른 시스템과의 통합을 고려할 때 이의 분석평가를 위해서는 반드시 대상 시스템의 아키텍쳐를 정의하고 분석해야 합니다. 객체지향은 이 작업을 위한 최적의 방법을 제공합니다. ##########35* ##########36* ##########37* 정보공학과 객체지향 모델링의 차이점 ##########38* 정보공학 모델링과 객체지향 모델링의 차이점을 정리하면 다음과 같습니다. ##########39* 정보공학은 비즈니스 분석을 지원하는 적절한 모델이 없고, 동적 모델링과 아키텍쳐링 관련 모델도 없음을 알 수 있습니다. 반면에 개발(코딩) 단계에서는 객체지향 모델링과 차이가 없습니다. 이 표를 보면 풍부한 모델링을 지원하는 객체지향 체계가 보다 진보된 방식임을 알 수 있습니다. ##########40* 정보공학 모델링 객체지향 모델링(UML 기반) 분석 (비즈니스 모델링) ##########41* 프로세스 모델링(기능챠트) ##########42* 이벤트 모델링 (이벤트 목록/시나리오) ##########43* 유즈케이스 모델링 (유즈케이스 다이어그램) ##########44* 데이터 모델링(ER Diagram) ##########45* 비즈니스 개념 모델링 (클래스 다이어그램) 없음 ##########46* 비즈니스 프로세스 모델링 (액티비티 다이어그램) ##########47* 비즈니스 객체 생명주기 모델링 (스테이트차트 다이어그램) 설계 (S/W 모델링) 없음 ##########48* 아키텍쳐 설계 (컬레보레이션 다이어그램) ##########49* S/W 동적 모델링 (시퀀스 다이어그램) ##########50* Component 모델링 (Componet 다이어그램) ##########51* 프로그램 설계 (프로그램 사양서) ##########52* 클래스 상세설계 (클래스 다이어그램) ##########53* User Interface 설계 (화면 레이아웃) ##########54* User Interface 설계 (화면 레이아웃) ##########55* Data Base 설계 (테이블 정의서) ##########56* Data Base 설계 (테이블 정의서) 개발 ##########57* 프로그램 코딩(프로그램) ##########58* 프로그램 코딩(프로그램) ##########59* 테스트(테스트 결과) ##########60* 테스트(테스트 결과)

	##########61*
##########62*

UML은 Unified Modeling Language의 약자입니다. 그럼 UML에 대하여 구체적으로 살펴볼까요? ##########63* ##########64* ##########65* UML은 Unified 체계입니다. Unified란 단어는 기존의 여러 방법론에서 사용되어 오던 표기법들을 통합한 것이라는 의미로 사용되었습니다. UML은 새롭게 창조되어 생소하고 검증이 덜 된 체계가 아니라, 기존에 사용되던 안정되고 검증된 표기체계들을 이어받고 통합한 것입니다. 물론 기존에 사용되던 체계 그대로가 아니라 많은 부분을 발전적으로 수정하고 보완한 완성도 높은 체계입니다. ##########66* ##########67* UML은 Modeling Language입니다. UML은 복잡한 방법론(Methodology)이 아닙니다. 방법론은 SW개발과정 중에 따라야 할 절차와 기법과 도구를 제시하는 것이지만, 모델링을 위한 표기체계, 즉 언어(Language)라고 합니다. 그리고 언어이기에 구성요소와 룰과 원칙(문법)이 존재하지만 그 적용분야가 제한되지 않습니다. 이러한 이유로 UML은 여러 다양한 방법론에서 응용할 수 있는 범용성 높은 모델링 언어이고, SW 분야뿐 아니라 모델링이 필요한 모든 분야에 적용이 가능한 것입니다.

UML의 특징은 다음과 같습니다. ##########68* ##########69* ##########70* ##########71* 가시화 언어("Language for Visualizing", The UML User's Guide) ##########72* UML은 여러 개의 그래픽 기호로 구성되어 있으며 각 기호들은 정확한 의미를 가지고 있습니다. 그러므로, UML로 모델링한 것은 통일된 의미를 갖기 때문에 UML로 작성된 문서를 보는 사람들은 시스템에 대해 동일한 의미를 공유할 수 있게 됩니다. ##########73* ##########74* 명세화 언어("Language for Specifying", The UML User's Guide) ##########75* 명세화란 정확하고, 명백하며, 완전한 모델을 의미하는데, UML은 분석, 설계, 구현에서의 모든 중요한 결정에 대한 명세서를 다룰 수 있게 합니다. ##########76* ##########77* 구축하는 언어("Language for Constructing", The UML User's Guide) ##########78* UML 언어에서는 프로그래밍 코드를 생성하는 것이 가능하고, 또한 구현된 코드로부터 UML 모델을 다시 생성할 수 있는 역공학(reverse engineering)도 가능합니다. ##########79* ##########80* 문서화 언어("Language for Documenting"- The UML User's Guide) ##########81* UML은 시스템 구조와 그것의 모든 상세 내역에 대한 문서화를 다루며, 요구사항을 표현하고 시스템을 시험하는 언어와 프로젝트 계획과 배포관리 액티비티를 모델링하는 기능을 제공합니다.   UML 이전의 모델링 체계   ##########82* ##########83* OMT는 James Rumbaugh가 GE 프로젝트들을 수행한 경험을 토대로 개발한 객체지향 모델링 체계입니다. 이것은 1990년 "Object-Oriented Modeling and Design" 출간함으로써 세상에 소개되었으며, 발표 이후 UML에 통합되기 전까지 전 세계에 걸쳐 가장 널리 적용된 객체지향 모델링 체계 중 하나입니다. 그리고 시스템의 표현을 위한 다음과 같은 다양한 모델들을 제공하여 완전한 모델링의 구축을 추구하였습니다. 시스템의 표현을 위한 모델링에 대하여 자세히 살펴봅시다. ##########84* ##########85* ##########86* ##########87* 객체 모델(Object Model) ##########88* 시스템의 기능구현을 위해 식별된 모든 클래스와 클래스 간의 정적인 관계를 표현한 모델입니다. 이 모델은 시간과 사건의 개념이 포함되지 않고, 모든 객체가 하나의 평면에 표현되기 때문에 정적모델이라고 하는 이것은 어떻게 정의해야 할까요? 객체모델을 정의하기 위해서는 다음 순서의 일을 수행해야 합니다. ##########89* ※ 깜박이는 화살표를 클릭하세요. ##########90* ##########91* ##########92* ##########93* 동적 모델(Dynamic Model) ##########94* 시스템의 특정 기능에 참여하는 객체들과 객체간 동적 상호관계를 표현한 모델입니다. 이 모델은 시간과 사건에 따른 객체의 순서적 행위를 표현하기 때문에 동적 모델이라고 합니다. 동적 모델에는 객체 자체와 객체의 상태 그리고 기능을 유발하는 사건과 기능을 수행하는 시간개념이 포함됩니다. ##########95* ##########96* 기능 모델(Functional Model) ##########97* 시스템이 어떠한 기능을 수행해야 하는 지를 나타내는 모델입니다. 이 모델은 객체와 객체간 메시지 교환을 통해 기능이 어떤 방식으로 구현될 지에 대해 설명합니다. ##########98* ##########99* ##########100* ##########101* Grady Booch가 국방, 상업 등 대규모 시스템들에 대한 개발 경험을 기반으로 정립한 모델링 체계입니다. 이것은 90년 초반에 저서 "Object-oriented Analysis and Design with Applications"을 출간함으로써 Booch Method가 소개되었습니다. Booch Method의 특징은 다음과 같습니다. ##########102* 시스템 아키텍처에 초점 ##########103* 시스템의 구성요소 및 구성요소와 구성요소간 관계와 상호작용을 정의한 아키텍쳐를 중시한 모델링 체계를 제시하였습니다. ##########104* ##########105* 시스템을 다양한 관점에서 분석하는 개념을 제시 ##########106* 여러 종류의 모델링 방법을 제시함으로써 시스템을 다양한 관점에서 분석할 수 있게 하였습니다. 이러한 모델링 관점의 다양화는 보다 완전한 모델 구축을 가능하게 합니다. ##########107* ##########108* 반복적이고, 점증적인 개발 프로세스 제시 ##########109* 시스템을 개발할 때 과거와 같이 한번에 개발하는 대신, 작은 영역으로 쪼개어 여러 번에 걸쳐 나누어 개발하는 방식을 주창하였습니다. 이 방식은 개발과정에 숨겨져 있는 위험(Risk)들을 조기에 발견하여 대처하게 함으로써 시스템 개발이 실패할 위험을 줄여줍니다. ##########110* ##########111* OOSE (Object-Oriented Software Engineering)는 Ivar Jacobson에 의해 제안된 객체지향 개발 방법론입니다. Objectory는 통신, 금융 분야에서의 Ivar Jacobson의 방법론에 기반하여 다양한 시스템에 적용된 방법입니다. OOSE/Objectory 방법론의 특징은 유스케이스 중심 접근법 (Use-Case Driven Approach)으로 대표됩니다. 유스케이스 모델을 간단히 소개하면, 시스템 개발 초기단계에 작성되어 다른 모든 모델을 유도해 내는 기준 모델이라고 합니다. 즉, 유스케이스 모델은 시스템과 상호 작용하는 방식들을 파악하여 시스템의 모든 기능들을 서술하는 것이라고 할 수 있습니다.   UML의 탄생과정과 의의   ##########112* ##########113* ##########114* UML은 1997년 표준으로 채택되었지만, 기존 방법론들의 장점들을 취합한 표기체계입니다. UML이전에도 객체지향 기반의 모델링 체계를 포함한 방법론들이 많이 존재했었지만, 너무 많아서 문제가 있었습니다. 많은 개발자들이 모델링 체계가 달라 의사소통에 불편을 느끼게 되었기 때문입니다. 그래서 자연스럽게 하나의 표준 표기체계가 필요하다는 것을 느끼게 되었습니다. 통합되고 표준화된 객체지향 표기체계의 필요성이 대두되던 이 시점에 UML이 등장하게 된 것입니다. 1960년대부터 현재에 이르기까지 UML의 탄생과 발정과정을 아래의 표와 그림으로 살펴봅시다. ##########115* 1967년 최초의 객체지향 언어 SIMULA 탄생 1980년대와 90년대 초반 다양한 객체지향기반 표기체계 및 방법론(약 50여 가지)이 난립 1995년 ##########116* Booch의 Booch 방법론과 Rumbaugh의 OMT방법론이 통합 ##########117* 객체지향 학술대회인 OOPSLA('95)에 발표 1996년 ##########118* Jacobson의 OOSE 방법론이 추가로 통합 ##########119* 대표적인 3대 방법론에서 쓰이던 표기체계가 통합됨 ##########120* UML(Unified Modeling Language)로 명명되어 v 0.9로 정의 1997년 ##########121* 1월 : UML ver. 1.0 발표 ##########122* 9월 : UML ver. 1.1 발표         객체지향 기술표준 기구인 OMG에 표준화안 상정 ##########123* 11월 : OMG 표준 인증 1999년 UML ver. 1.3 발표 2001년 UML ver. 1.4 발표 2002년 UML ver. 2.0 예정 ##########124* * OMG : Objec Management Group. "www.omg.org" ##########125* ##########126* ##########126*   ##########127* ##########128* ##########129* 1997년 UML은 버전 1.0이 OMG(Objec Management Group."www.omg.org")의 표준인증을 획득하여 객체지향 모델링 체계의 세계 표준이 되었습니다. UML은 다음과 같은 의의를 가집니다. ##########130* ##########131* 표기체계의 통합 및 표준화 ##########132* 1980년대에서 90년대에는 50여 가지의 표기체계가 난립하였습니다. UML은 이러한 표기체계를 하나로 통합함으로써 표준화의 대업을 이루었습니다. UML은 개인이나 기업이 아닌 비영리 표준화 단체인 OMG에 의해 사양과 업그레이드가 관리되며, 이것의 등장으로 재사용과 원할한 의사소통 효과를 비롯한 많은 효과를 기대할 수 있게 된 것입니다. ##########133* ##########134* 개발 프로세스와 개발언어에 독립적 표기체계 ##########135* UML은 특정 개발방법론에 얽매이지 않은 개방적인 표기체계를 제시하였습니다. 방법론에 독립적일 뿐 아니라 개발언어의 물리적 제한사항을 수용하는 추상성을 제공하는 표기체계를 채택함으로써 개발언어에도 독립적입니다. 따라서 우리는 UML의 등장으로 개발 방법론과 개발언어에 제한없이 적용될 수 있는 개방적인 모델링 체계를 갖게 된 것입니다. ##########136* ##########137* 적용에 제한이 없는 범용적 표기체계 ##########138* UML은 적용하기 위한 별도의 비용이나 허가가 필요없는 공개된 표준 모델링 체계를 제공합니다. UML을 사용하기 위한 제한된 조건은 없으며, 이것의 등장함으로써 우리는 SW시스템의 개발과정뿐 아니라 비즈니스 영역을 비롯한 적용가능한 모든 분야에서 폭넓게 응용할 수 있는 범용적인 표기체계를 갖게 된 것입니다.

##########139*	##########140*
##########141*

UML은 Things, Relationships, Diagrams의 세 가지 구성요소를 가집니다. 이 구성요소는 UML이 모델링 체계로서 의미를 가지기 위한 최소한의 요건입니다. Things, Relationship, Diagrams의 각 구성요소는 각기 4개 혹은 9개의 하위요소로 이루어져 있습니다. ##########142* ※ ? 를 클릭해 보세요. ##########143* ##########144* ##########145* ##########146*

 

 

##########147*	##########148*
##########149*

##########150* Things(사물) ##########151* ##########152* 추상적인 개념으로, 모델에서는 주제를 나타내는 요소입니다. 언어로서의 UML을 생각해 볼 때 단어에 해당하며, 단어 중에서도 명사 혹은 동사의 의미를 가지는 요소라고 볼 수 있습니다. ##########153* UML을 그림으로 생각해 볼 때 Things는 도형의 형식을 가지는데 Things의 유형과 종류가 정해져 있어서 마음대로 도형을 추가하지는 못합니다. 이 Things는 사전에 부여된 명확한 의미를 가집니다. ##########154* ##########155* Relationships(관계) ##########156* ##########157* Things의 의미를 확장하고 더욱 명확히 하는 요소입니다. Relationships는 Things와 Things를 연결하여 그들 간의 관계를 표현하는 요소입니다. 언어로서의 UML을 생각해 볼 때 Relationships는 단어에 해당하며, 단어 중에서도 형용사나 부사에 해당합니다. ##########158* UML을 그림으로 생각해 볼 때 Relationships는 선의 형식을 가집니다. 마찬가지로 UML에서는 정해진 선만을 사용해서 Relationships를 표현해야 합니다. 이 선들은 사전에 부여된 명확한 의미를 가집니다. ##########159* ##########160* Diagrams(도해) ##########161* ##########162* Things과 Relationships을 모아 그림으로 표현한 것입니다. Diagrams에는 Things와 Relationships가 어우러진 한 장의 그림으로 보는데 UML에서는 그 그림의 형식을 9가지로 정의하고, 각 그림에 대해 용도와 목적을 정의하고 있습니다. ##########163* 보통 UML이라는 용어는 9개의 Diagrams와 동일한 의미로 쓰일 때가 많습니다. 언어로서의 UML을 생각해 볼 때 Diagrams는 주제를 담은 문장들로 이루어진 글월에 해당합니다. 이 글월은 문장(Things와 Relationships 몇 개가 합쳐진 형태)과 단어(Things, Relationships)들로 구성됩니다. ##########164* Diagram 한 장은 바로 하나의 모델을 의미합니다. 따라서 UML은 9가지 종류의 모델 체계를 제시하고 있다고 할 수 있습니다.

 

 

 

 

 

	##########165*
##########166*

Things는 추상적인 개념으로, 모델에서 주제를 나타내는 UML의 요소입니다. Things에는 네 가지 종류의 Things가 있습니다. ##########167* ※ ? 를 클릭하세요. ##########168* ##########169* ##########170* ##########171* ##########172*   ##########173* ##########174* ##########175* 구조 사물은 UML 모델의 명사에 해당합니다. ##########176* ##########177* 주로 모델의 정적인 부분들이며, 개념적이거나 물리적인 요소들을 표현합니다. ##########178* ##########179* Structural Things의 종류는 다음과 같습니다. ##########180* ##########181* 클래스(class) ##########182* 인터페이스(interface) ##########183* 컬레보레이션(collaboration) ##########184* 유즈케이스(use case) ##########185* 액티브 클래스(active class) ##########186* 컴포넌트(component) ##########187* 노드(node) ##########188* [클래스(class)] ##########189* ##########190* 정의 클래스는 의미를 공유하는 객체의 집합이며, 객체의 타입입니다. ##########191* ##########192* 표현 방법 UML에서는 직사각형의 형태로 표현하며, 그 안에 Class 이름만을 표시하거나, 두 개의 행을 두고 각각 Attribute와 Operation을 같이 표시하기도 합니다. ##########193*   [인터페이스(interface)] ##########194* ##########195* 정의 Interface는 Class의 일종입니다. interface는 class나 Component의 기능 중 외부로 가시화 하는 부분을 정의할 목적으로 쓰이며 구현은 하지 않습니다. interface의 구현은 클래스에서 하게 되며, 이 클래스는 interface를 상속함으로써 단지 선언뿐인 interface의 구현을 담당합니다. Interface는 단독으로 표시되는 경우는 거의 없으며 해당 Interface를 구현하는 Class나 Component에 붙어 다닙니다. ##########196* ##########197* 표현 방법 원으로 표현하고 Interface 명을 아래쪽에 표시합니다. 혹은 일반 클래스(① 클래스 내용참조)로 표현하고 <>라는 표기(스테레오타입)를 사용하기도 합니다. ##########198*   [컬레보레이션(collaboration)] ##########199* ##########200* 정의 Collaboration(협력)은 특정 목적을 위한 요소들과 그 요소들 사이의 상호작용과 역할을 정의함으로써 일련의 행위를 표현합니다. 일반적으로 정의(definition)가 실현되는 방법을 나타내는 명세서가 되며 이러한 실현은 분류자(classifier)들과 연관(혹은 관계)으로 이루어집니다. 분류자(classifier)는 다음과 같습니다. (→ Class, Interface, data type, signal, Component, Node, Use Case, Subsystem) ##########201* ##########202* 표현 방법 점선으로 된 타원으로 표현하고 Collaboration(협력) 명을 표시합니다. ##########203*     [유즈케이스(use case)] ##########204* ##########205* 정의 유즈케이스는 시스템이 제공하는 서비스 혹은 기능입니다. 유즈케이스는 시스템이 외부에 제공하는 사용자 관점의 기능단위이며 외부의 요청에 반응하여 원하는 처리를 수행하거나 원하는 정보를 제공합니다. 유즈케이스는 그 자체로 의미있는 자기완결형(Self Contained)의 서비스 단위입니다. ##########206* ##########207* 표현 방법 실선으로 된 타원으로 표현하고 Use Case 명을 표시합니다. ##########208* [액티브 클래스(active class)] ##########209* ##########210* 정의 클래스에서 파생된 객체가 하나 또는 그 이상의 프로세스(process)나 스레드(thread)를 갖는 클래스를 기술합니다. 이 클래스에 해당하는 객체는 제어 활동을 일으킬 수 있습니다. ##########211* ##########212* 표현 방법 클래스와 같으며 단지 테두리 사각형의 선 두께를 굵게 표시합니다. ##########213*   컴포넌트(component)] ##########214* ##########215* 정의 시스템에서 물리적으로 관리되는 한 묶음의 SW를 표현합니다. 모델을 구성하는 요소들을 물리적으로 패키지화 한 것을 나타냅니다. ##########216* ##########217* 표현 방법 탭이 달린 직사각형으로 표현하고 Component 명을 표시합니다. ##########218*   [노드(node)] ##########219* ##########220* 정의 연산 능력이 있는 물리적 요소를 표현합니다. 컴퓨터나 네크워크 기기등을 의미합니다. ##########221* ##########222* 표현 방법 입방체로 표현하고 Node명을 표시합니다. ##########223*   ##########224*

##########225*	##########226*
##########227*

##########228* 행동사물은 UML 모델의 동사에 해당합니다. ##########229* ##########230* 주로 UML의 동적인 부분들이며, 시간과 공간에 따른 행동을 나타냅니다. ##########231* ##########232* Behavioral things의 종류는 다음과 같습니다. ##########233* ##########234* 교류(interaction) ##########235* 상태머신(state machine) [교류(interaction)] ##########236* ##########237* 정의 Interaction은 행동이며, 지정된 목적을 완수하기 위해서 특정 문맥에 속한 객체들 간에 주고 받는 메시지들로 구성됩니다. 객체간 메시지, 활동 순서(메시지로 호출되는 행동), 객체간의 연결 등을 표현하기 위하여 사용됩니다. ##########238* ##########239* 표현 방법 직선으로 표현하며 Interaction 명을 표시합니다. ##########240*   [상태머신(state machine)] ##########241* ##########242* 정의 State Machine은 외부의 이벤트에 대한 객체의 상태와 상태의 변화 순서를 기술하는 행위 사물입니다. ##########243* ##########244* 표현 방법 모서리가 둥근 직사각형으로 표현하고 State 명을 표시하며 필요에 따라 하위 상태를 포함합니다. ##########245*   ##########246* ##########247* ##########248* 그룹사물은 UML 모델의 다른 사물들을 그룹화 하는 기능을 담당합니다. ##########249* ##########250* Package(그룹사물)에는 Package(패키지)가 있습니다. ##########251* ##########252* 정의 ##########253* Package는 요소를 그룹으로 묶는 것을 표현합니다. Package로 요소들을 묶는 것은 논리적인 것이며 실제 구현되는 상태와는 다를 수 있습니다. 즉, 같은 Package에 있다 하더라도 다른 컴포넌트(DLL, EXE 등)로 구현될 수 있습니다. ##########254* ##########255* 표현 방법 ##########256* 탭이 달린 폴더로 표현하고 Package를 표시합니다. 폴더 안에 package에 포함되는 요소들을 직접 표시하기도 합니다. ##########257* ##########258* ##########259* ##########260* ##########261* 주석사물은 UML 모델을 설명하는 부분입니다. ##########262* ##########263* 모델링에 참여하지는 않지만 모델링에 참여하는 다른 사물들 뿐만 아니라 모델링을 이해하는데 필요한 정보 등 필요한 모든 설명을 표시하기 위해 사용합니다. ##########264* ##########265* Annotation things(주해 사물)의 종류에는 note(노트)가 있습니다. ##########266* ##########267* 정의 ##########268* Note(노트)는 첨부되는 주석 또는 제약을 기술하는 기호입니다. ##########269* ##########270* 표현 방법 ##########271* 모서리가 접힌 직사각형으로 표현하고 직사각형 안에 문자 또는 그림을 사용하여 서술합니다. ##########272* ##########273*

	##########274*
##########275*

Relationship(관계)는 Things의 의미를 확장하고 더욱 명확히 하는 요소이며, Things와 Things를 연결하여 그들 간의 관계를 표현합니다. Relationships는 다음의 네 종류의 관계가 있습니다.

	##########276*
##########277*

Relationships의 네 가지 종류에 대해 좀 더 자세히 살펴봅시다. ##########278* ##########279* Dependency(의존) 관계 ##########280* ##########281* 의미 ##########282* -  Dependency(의존)는 두 사물간의 의미적 관계로서, 한쪽 사물의 변화가 다른 사물에 영향을 줄 수 있음을 표현합니다. ##########283* - 한 쪽 사물이 실행 도중 다른 쪽 사물의 실행을 요청하는 경우, 즉 사물간의 사용관계를 표현합니다. ##########284* - Class와 Class / Package와 package /Component와 Component에 주로 사용되는 관계이고, 때로는 Class-Package-Component 상호간에도 사용되는 관계입니다. ##########285* ##########286* 표현 방법 및 사례 ##########287* 표현 방법 사례 ##########288* ##########289* 점선 화살표로 표현하고 필요에 따라 선 위에 설을 붙이기도 합니다. ##########290* ##########291* [해설] 주문을 위해서는 상품 (상품의 정보를 위해)을 사용합니다. ##########292* ##########293* Association(연관) 관계 ##########294* ##########295* 의미 ##########296* -  Association(연관)은 사물들간의 일반적인 참조관계를 표현합니다. ##########297* - Aggregation(집합연관)은 특별한 종류의 연관으로서, 전체(whole)과 부분(part) 간의 구조적 관계를 표현합니다. ##########298* - 두 클래스가 서로 association관계에 있다면 그로부터 파생된 한쪽 객체에서 상대편 객체를 참조할 수 있음을 의미합니다. ##########299* ##########300* 표현 방법 및 사례 ##########301* 표현 방법 사례 ##########302* ##########303* -  실선으로 표현합니다. 실선은 한쪽에 열린 화살표가 붙을 수 있습니다. - 이 경우는 참조 방향을 의미합니다. 즉, 화살표가 나가는 쪽은 상대편을 참조할 수 있지만, 반대편 사물은 상대편을 참조할 수 없습니다. ##########304* ##########305* [해설] 고객은 회사와 연관관계를 가집니다. ##########306* Generalization(일반화) 관계 ##########307* ##########308* 의미 ##########309* -  일반화(Generalization)는 특수화(specialization)/일반화(generalization) 관계를 표현합니다. 즉, 두 클래스 관계가 일반화-특수화 관계가 있을 때 사용합니다. ##########310* - 일반화 관계는 객체의 특성 중 상속(Inheritance)을 표현하는 관계입니다. ##########311* - 클래스-클래스 / 유즈케이스-유즈케이스 사이에 허용되는 관계입니다. ##########312* ##########313* 표현 방법 및 사례 ##########314* 표현 방법 사례 ##########315* ##########316* 속이 빈 삼각형의 화살표가 한쪽에 달린 실선으로 표현합니다. ##########317* ##########318* [해설] 코끼리는 동물의 특성을 상속하였습니다. ##########319* ##########320* Realization(실체화) 관계 ##########321* ##########322* 의미 ##########323* -  정의하는 사물과 이를 구현하는 사물간에 표현하는 관계입니다. ##########324* - 실체화 관계는 Use case(정의하는 사물) - Collaboration(구현하는 사물)과 Interface(정의하는 사물) - class(구현하는 사물)사이에 허용되는 관계입니다. ##########325* ##########326* 표현 방법 및 사례 ##########327* 표현 방법 사례 ##########328* ##########329* 속이 빈 삼각형의 화살표가 한쪽에 달린 점선으로 표현합니다. ##########330* ##########331* [해설] 건물은 청사진을 실현한 것입니다.

Diagrams는 Things와 Relationships를 모아 그림으로 표현한 것입니다. Diagrams에는 Things와 Relationships가 어우러진 한 장의 그림입니다. UML에서는 그 그림의 형식을 9가지로 정의하고, 각 그림에 대해 용도와 목적을 정의하고 있습니다. 보통 UML이라는 용어는 9개의 Diagram과 동일한 의미로 쓰일 때가 많습니다. 그러면 9개의 UML Diagrams에 대한 내용을 간단히 알아 봅시다.

##########332*

##########333* UseCase Diagram ##########334* Class Diagram ##########335* Sequence Diagram ##########336* Collaboration Diagram ##########337* State chart Diagram ##########338* Activity Diagram ##########339* Component Diagram ##########340* Deployment Diagram ##########341* Object Diagram

 

##########342* UseCase Diagram(유스케이스 다이어그램) -  시스템이 제공하는 서비스와 외부 환경과의 관계를 표현하는 Diagram입니다. -  시간개념과 순서개념이 없으므로 정적인 관점에서의 모델입니다. -  사용자 관점에서 시스템의 기능을 정의하고 외부 환경을 정의하는 목적으로 작성됩니다.   ##########343* Class Diagram(클래스 다이어그램) -  클래스와 클래스 간의 관계를 나타내며 UML의 모델 가운데 가장 공통적으로 많이 쓰이는 Diagram입니다. -  직접적으로 프로그램밍과 관련된 내용을 담고 있습니다. -  클래스 다이어그램은 시스템의 정적인 관점을 나타냅니다. ##########344* Sequence Diagram (시퀀스 다이어그램) -  외부의 특정한 처리요청을 해결하기 위해 필요한 객체들과 그 객체들이 참여한 시간적, 순서적 처리흐름을 표현하는 Diagram입니다. -  클래스가 아닌 객체가 등장하며 시간의 흐름에 따라 객체간의 메시지 전달과정이 잘 표현됩니다. -  시스템의 동적인 관점을 나타내며, 시스템의 동적 모델중 하나입니다. ##########345* Collaboration Diagram(컬레보레이션 다이어그램) -  Sequence Diagram과 목적과 용도가 같은 Diagram입니다. -  Sequence Diagram이 시간순서를 중시한 모델인 반면 Collaboration Diagram은 객체와 메시지를 구조적으로 표현하는 데 유리한 표현체계를 가집니다. -  두 다이어그램은 표현형태만 다를 뿐이어서 서로 의미의 손실없이 자동적으로 변환이 가능합니다. -  시스템의 동적인 관점을 나타내며, 시스템의 동적 모델중 하나입니다. ##########346* State chart Diagram(상태 다이어그램) -  State chart Diagram은 하나의 객체가 생성되어 소멸될 때까지 가질 수 있는 가능한 모든 상태(state)를 분석하고, 표현하는 다이어그램입니다. -  시스템에서 복잡한 역할을 수행하는 핵심 객체에 대해 자세한 변화를 추적하여 완전성을 기하기 위해 작성합니다. -  상태 다이어그램은 시스템의 동적인 관점을 다루는 모델입니다. ##########347* Activity Diagram(액티비티 다이어그램) -  처리흐름을 모델링하는 범용적인 다이어그램입니다. -  대상은 클래스의 처리흐름일 수 도 있고, 비즈니스측면의 워크플로우 일 수도 있고, 기타 다른 다양한 분야가 대상이 될 수 있습니다. -  논리 흐름과 처리 순서, 프로세스 플로우 등에 대해 판단, 처리, 액티비티를 사용하여 분석하는 모델입니다. ##########348* Component Diagram(컴포넌트 다이어그램) -  클래스로 구성된 물리적인 배치 단위인 컴포넌트와 컴포넌트간의 구성과 의존관계를 나타내는 다이어그램입니다. -  컴포넌트는 컴퓨터 장치에 독립적으로 배치할 수 있는 단위입니다. -  시스템의 정적인 구현관점을 표현합니다. ##########349* Deployment Diagram(배치 다이어그램) -  시스템이 실행되는 환경인 노드와 그 노드에 배치된 컴포넌트의 구성을 나타내는 다이어그램입니다. -  Deployment Diagram은 컴포넌트 다이어그램과 관련이 있는데, 일반적으로 하나의 노드는 컴포넌트 다이어그램에 정의된 컴포넌트를 수용하기 때문입니다. ##########350* 객체 다이어그램 (Object Diagram) -  특정 시점에서의 객체들의 상태와 그들 간의 관계를 표현한 다이어그램입니다. -  Class Diagram에 있는 요소들의 인스턴스에 대한 정적인 스냅 샷을 나타냅니다.

 

유즈케이스란 "어떤 대상을 사용하는 한가지 사례, 방식" 이라는 의미입니다.
그래서 유즈케이스들을 모두 모아 놓으면 결국 그 대상을 사용하는 방법의 모든 것,
즉 대상이 제공하는 모든 서비스의 집합이 됩니다.

그런 의미에서 유즈케이스 다이어그램은 전자상가에서 볼 수 있는 상품의
주요기능을 적어놓은 선전용 전단과 유사한 의미를 가집니다. 유즈케이스
다이어그램은 사용자가 나중에 인도받게 될 SW시스템의 기능과 서비스의 내용을
직관적으로 파악할 수 있게 합니다.

누구나 알 수 있는 그림의 형태로 이 모든 것이 정의되기 때문에 SW에 대한 지식이
없는 사용자들이 쉽게 이해하고 동의할 수 있습니다.

자 그럼 유즈케이스 다이어그램의 세계로 떠나 볼까요 ?

 

 1. 개요

 

	##########351*
##########352*

UML의 9개 다이어그램은 각기 독립적인 의도와 목적으로 사용됩니다. 그렇기 때문에 어떤 다이어그램부터 공부해야 하는가 하는 순서는 없다고 할 수 있습니다. 하지만 대부분의 UML관련 교재나 자료에서 유즈케이스 다이어그램을 UML의 여러 다이어그램 중에서 제일 먼저 소개합니다. 왜 그럴까요 ? 유즈케이스 다이어그램을 가장 먼저 공부해야 하는 이유는 다음과 같습니다. ##########353* ##########354* 유즈케이스 다이어그램은 대개의 경우 다른 다이어그램들보다 먼저 작성됩니다. ##########355* ##########356* 유즈케이스 다이어그램은 다른 다이어그램을 작성할 때의 기준이 됩니다. ##########357* ##########358* 다른 다이어그램들은 유즈케이스 다이어그램에서 정의한 내용을 보다 상세하고 구체적으로 추가 정의하는 형태로 작성될 때가 많습니다. ##########359* 유즈케이스 다이어그램은 다른 UML 다이어그램들과 유기적인 관계를 가지고 있습니다. 현장에서 UML을 적용할 때의 중요한 성공요인은 모델링과정에서 항상 이러한 유기적인 관계를 염두에 두고 모델간의 의미적, 문법적 일관성을 유지하는 것입니다. 즉, UML의 9개 다이어그램은 각기 고유의 목적이 있어 독립적이며, 특성에 맞게 적용하면 되지만, 종합적인 면에서 서로 유기적인 연관성을 가진다는 것도 알아두시기 바랍니다.   ##########360*

유즈케이스 다이어그램은 "사용자의 시각에서 SW 시스템의 범위와 기능을 쉽게 설명하고 정의한 모델"입니다. 또한 "SW 시스템의 기능적 요구사항에 대한 베이스라인"입니다. ##########361* ##########362* 유즈케이스 다이어그램은 건물을 짓기전에 미리 건물의 설계도를 작성하는 것처럼 나중에 완성될 SW 시스템의 모습을 개념적으로 정의하여 여러 관련자들과 의견을 나누고 합의하는 과정에서 사용됩니다. ##########363* 우리는 이 유즈케이스 다이어그램을 통해 이후 완성될 SW 시스템의 모습을 상상하는 최초의 시도를 하게 되는 것입니다.

	##########364*
##########365*

유즈케이스 다이어그램을 작성하는 시기는 SW개발 프로젝트를 시작하는 시기입니다. 구체적으로 프로젝트 개발 초기단계 중에서도 다음과 같은 시점에 유즈케이스 다이어그램을 작성하게 됩니다. ##########366* ##########367* ##########368* SW 프로젝트의 개발 범위를 정의하는 단계 ##########369* ##########370* SW에 대한 요구사항을 정의하는 단계 ##########371* ##########372* SW의 세부기능을 분석하는 단계 ##########373* ##########374* SW가 아닌 업무영역(Business Domain)을 이해하고 분석하는 단계 ##########375* 특히  ##########376* 의 경우는 작성내용이 SW의 기능이 아닌 업무지식를 내용으로 하고 있기에 "비즈니스 유즈케이스 다이어그램"이라고 합니다. 이러한 유즈케이스 다이어그램을 작성하기 전에 먼저 선행되어야 할 사항은 시스템에 대한 사용자의 요구사항이 수렴되고 정의되어야 합니다.

   2. 구성요소 : 액터와 유즈케이스

 

            ##########377*

 

	유즈케이스 다이어그램의 구성요소는 다음과 같습니다.
##########378*
	##########379*

	##########380*
##########381*

	##########382* 액터의 표기 ##########383* ##########384* ##########385* 액터는 왼쪽과 같은 사람모양의 그림입니다. ##########386* ##########387* 작대기로 만든 사람이라는 의미로 "스틱맨"이라는 애칭으로 부르기도 합니다. ##########388* ##########389* 스틱맨의 아래에 액터의 이름을 명사로 표시합니다. ##########390* ##########391* 액터의 정의, 의미 ##########392* ##########393* 액터는 시스템의 외부에 존재하면서 시스템과 교류 혹은 상호작용(interaction) 하는 것입니다. ##########394* ##########395* 액터는 자신에 대해 시스템이 서비스를 해 주기를 요청하는 존재들이고 , 시스템이 정보를 제공하는 대상이기도 합니다. ##########396* ##########397* 액터는 시스템의 일부가 아니라 외부에 독립적으로 존재합니다. ##########398* 시스템의 사용자로서, 액터는 다음의 3가지 부류로 나눌 수 있습니다. ##########399* ※ 아래의 각 그림을 클릭하세요. ##########400* ##########401* SW의 사용자 혹은 SW가 제공하는 정보를 얻는 사람 ##########402* ##########403* SW와 상호작용하는 외부의 독립된 SW 시스템 ##########404* ##########405* SW로 정보를 주고, 받는 하드웨어 장치
##########406*
	##########407* ##########408* 액터명 정의시 주의사항 ##########409* 액터가 사람일 경우는 액터 명은 직책이나 조직,개인 이름이 아닌 그 사람의 역할(Role)입니다. 즉, 결재 시스템에서 결재하는 사람이 액터로 식별되었다면 그 이름은 팀장이 아닌, 결재하는 사람의 역할로서 "결재자"가 액터 명이 되어야 합니다.

##########410* 액터의 예 ##########411* ##########412* 결재 시스템에서 : 상신자, 합의자, 결재자, 통보자 ##########413* ##########414* 전자 상거래 시스템에서 : 회원, 구매자, 배달자, 관리자, 배송시스템, 결재시스템 ##########415* ##########416* 병원관리시스템에서 : 의사, 간호사, 환자, 수납책임자, 약사 ##########417* ##########418* 소방경보시스템에서 : 관리자, 연기센서, 온도센서, 경보기 ##########419* ##########420* 액터의 식별방법 ##########421* SW가 담당할 문제영역에 따라 액터는 항상 다르게 정의됩니다. 액터를 식별하는 것은 생각보다는 어려운 작업이고, 액터를 정의하는 사람에 따라, 경험수준에 따라 차이가 있습니다. 따라서 액터를 정의하는 과정에서 관련 당사자들이 지속적으로 의견을 나누고, 결과는 반드시 리뷰하는 과정이 필요합니다. UML을 적용하여 SW를 잘 만들려면 액터부터 정확히 식별해야 합니다. 다음은 액터를 식별하는데 도움을 얻을 수 있는 질문들입니다. ##########422* ##########423* 시스템의 주요기능을 누가 사용하는가 ? ##########424* ##########425* 자신의 일상적인 업무를 수행하기 위해 시스템 지원을 필요로 하는 것은 누구(무엇)인가? ##########426* ##########427* 시스템이 운영될 수 있도록 관리 및 유지하는 것은 누구인가 ? ##########428* ##########429* 시스템이 취급하여야 하는 하드웨어 장치는 무엇인가? ##########430* ##########431* 시스템이 상호작용하여야 하는 다른 시스템은 무엇인가? ##########432* ##########433* 시스템이 제공하는 산출물에 관심을 갖는 대상은 무엇인가?

##########434* ##########435* ##########436* ##########437* 유즈케이스의 표기 ##########438* ##########439* ##########440* 왼쪽과 같은 타원 모양의 그림으로 표기합니다. ##########441* ##########442* 유즈케이스 아래에는 유즈케이스 명을 짧은 문장 혹은 행위를 나타내는 명사형으로 표시합니다. ##########443* ##########444* 경우에 따라 유즈케이스 명을 타원 안에 표기하기도 합니다. ##########445* ##########446* 유즈케이스의 정의, 의미 ##########447* ##########448* 유즈케이스는 시스템이 제공하는 서비스 혹은 기능 입니다. ##########449* ##########450* 유즈케이스는 시스템이 액터에게 제공하는 사용자 관점의 기능단위입니다. ##########451* ##########452* 유즈케이스는 액터의 요청에 반응하여 원하는 처리를 수행하거나 원하는 정보를 제공합니다. ##########453* ##########454* 유즈케이스는 액터와 한 번이상의 상호작용을 통한 한 의미있는 묶음의 시스템 행위입니다. ##########455* ##########456* 유즈케이스는 그 자체로 의미있는 자기완결형(Self Contained)의 서비스 단위입니다. ##########457* ##########458* 유즈케이스는 사용자의 관점으로 정의해야 합니다. ##########459* "유즈케이스는 의미있는 한 묶음의 시스템 행위" 라는 것의 예를 들어보면, 어떤 시스템에 유즈케이스 "주문하다" 가 있다고 가정해 봅시다. 이 유즈케이스는 액터인 고객과 다음의 그림처럼 표기되고, 그 교류는 다음과 같습니다. ##########460* ※ 아래의 깜박이는 글씨를 클릭하세요. ##########461* ##########462* ##########463* 이 예에서 유즈케이스는 액터와 여러 번의 교류를 하고 있음을 알 수 있고, 하나의 자기완결적인 행위(위 예에서는 주문에 대한 행위)를 담당하고 있다는 것도 알 수 있습니다. ##########464* 유즈케이스의 예 ##########465* ##########466* 결재 시스템에서 : 상신하다, 결재하다, 통보하다 ##########467* ##########468* 전자 상거래 시스템에서 : 상품정보 조회, 주문, 배송, 결재 ##########469* ##########470* 병원관리시스템에서 : 과거 병력 조회, 진료기록 입력, 진료비 계산 ##########471* ##########472* 소방경보시스템에서 : 화재 감시, 경보음 출력 ##########473* ##########474* 유즈케이스의 식별방법 ##########475* 다음은 유즈케이스를 정의하는 데 도움을 주는 질문들입니다. ##########476* ##########477* 액터가 어떤 기능을 시스템으로부터 요구하는가 ? ##########478* ##########479* 액터는 시스템을 통해 무슨 일을 수행하는가 ? ##########480* ##########481* 액터가 시스템에 있는 정보를 읽고, 작성하고, 저장하고, 수정하고, 삭제하여야 하는가? ##########482* ##########483* 시스템의 이벤트에 대하여 액터가 통보받아야 하는가 ? ##########484* ##########485* 액터가 시스템에게 어떤 사항을 통보하여야 하는가 ? ##########486* ##########487* 시스템의 새로운 기능을 통하여 액터의 업무가 단순화되거나 효율화 될 수 있는가? ##########488* ##########489* 시스템의 입력과 출력으로 무엇이 필요한가? 그리고 입력과 출력이 어디에서 오고 어디로 가는가? ##########490* ##########491* ##########492* 유즈케이스 식별시의 주의사항 ##########493* ##########494* 유즈케이스는 사용자 관점에서 정의해야 합니다. ##########495* ##########496* 유즈케이스는 구현방법이나 물리적 환경과는 상관없이 독립적으로 정의되어야 합니다. ##########497* ##########498* 사용자와 교류없이 시스템 내부에서 수행되는 기능은 유즈케이스가 아닙니다. ##########499* ##########500* 유즈케이스는 반드시 하나 이상의 액터와 상호작용 해야 합니다. ##########501* ##########502* 유즈케이스의 이름은 짧은 문장이나 행위를 표현할 수 있은 명사형으로 정의해야 합니다. 예) 강좌(X) , 수강하다(O), 상품 조회(O)   3. 구성요소 : 관계   ##########503* ##########504* 이번에는 액터-유즈케이스, 혹은 액터-액터, 유즈케이스-유즈케이스 사이에 정의되는 관계에 대해 학습하겠습니다. 유즈케이스 다이어그램에서 관계를 정의하는 것은 액터나 유즈케이스를 식별하는 것 만큼 중요합니다. 유즈케이스 다이어그램에서 사용되는 관계의 종류는 다음과 같습니다. ##########505* ##########506* ##########507* ##########508* ##########509* ##########510* ##########511* ##########512* 정의 및 특징 ##########513* ##########514* communicates는 액터와 유즈케이스 사이에 정의되는 관계입니다. ##########515* ##########516* communicates관계는 두 개체가 일반 상호작용 관계에 있다는 것을 의미합니다. ##########517* ##########518* 즉, 액터가 특정 사용목적을 가지고, 유즈케이스와 상호작용할 때 정의합니다. ##########519* ##########520* 액터는 서비스를 요구 하는 입장, 유즈케이스는 서비스를 제공하는 입장에 있습니다. ##########521* ##########522* 혹은 액터는 정보를 통보받거나 요구하는 입장, 유즈케이스는 정보를 제공하는 입장에 있습니다. ##########523* ##########524* 표기법 ##########525* ##########526* 화살표 없는 실선으로 표현합니다. ##########527* 모델 설명 ##########528* 학생(액터)는 수강하다(유즈케이스)와 교류하고 있습니다. 즉 학생 액터는 수강하다라는 유즈케이스의 서비스를 받습니다. (또는 사용합니다.) ##########529* ##########530* 한쪽 화살표를 가진 실선으로 표현합니다. ##########531* 모델 설명 ##########532* 알람을 울리다(유즈케이스)가 잠꾸러기 (액터)에게 알람을 울리고 있습니다. 이 경우 화살표의 방향은 communication을 누가 개시하느냐에 따라 달라집니다. 위의 예는 "알람을 울리다"라는 유즈케이스가 교류를 시작하고 있음을 알 수 있습니다. (이렇게 유즈케이스가 액터에 먼저 communication하는 예는 흔하지 않습니다) ##########533* ##########534* ##########535* 정의 및 특징 ##########536* ##########537* generalization은 액터와 액터, 유즈케이스와 유즈케이스 사이에 정의되는 관계입니다. ##########538* ##########539* generalization관계는 두 개체가 일반화 관계에 있음을 의미합니다. ##########540* ##########541* 즉, 보다 보편적인 것과 보다 구체적인 것 사이의 관계입니다. (is-a 관계라고도 합니다.) ##########542* ##########543* generalization관계는 상속(inheritance) 특성을 가집니다. ##########544* ##########545* 표기법 ##########546* ##########547* 삼각형 화살표가 붙은 실선으로 표현합니다. ##########548* 모델 설명 ##########549* 인터넷 고객(액터)와 고객(액터)는 일반화 관계가 있습니다. 즉, 인터넷 고객은 고객이 가진 특성을 모두 가지고 있고, 자신만의 특성을 추가적으로 가집니다.(상속) ##########550* 사용자 인증(유즈케이스)와 패스워드 확인 (유즈케이스)는 일반화 관계가 있습니다. 즉, 사용자 인증은 보다 보편적인 것, 패스워드 확인은 보다 더 구체적인 방법으로서 상호간 관계를 가집니다. ##########551* ##########552* ##########553* 정의 및 특징 ##########554* ##########555* include는 유즈케이스와 유즈케이스 사이에 정의되는 관계입니다. ##########556* ##########557* include관계는 한 유즈케이스가 다른 유즈케이스의 서비스 수행을 요청하는 관계입니다. ##########558* ##########559* 즉, 한 유즈케이스가 자신의 서비스 수행 도중에 다른 유즈케이스의 서비스를 사용할 필요가 있을 때 정의합니다. ##########560* ##########561* 이 경우 수행요청을 의뢰받은 서비스는 반드시 수행됩니다. ##########562* ##########563* 이때 수행의뢰를 받은 유즈케이스는 공통 서비스를 가진 존재입니다. 이렇게 수행될 때 Shared Service를 수행한다라고 합니다. ##########564* ##########565* 보통의 경우에 요청된 유즈케이스는 두 개 이상의 유즈케이스로부터 서비스 수행을 요청받습니다. ##########566* ##########567* 표기법 ##########568* ##########569* 화살표 붙은 점선에 <<include>> 스테레오타입을 정의합니다. ##########570* ##########571* 화살표의 방향은 수행을 의뢰하는 쪽에서 수행될 유즈케이스쪽으로 향합니다. ##########572* 모델 설명 ##########573* 로그인(유즈케이스)과 계좌이체 (유즈케이스)는 Shared Service인 사용자인증(유즈케이스)의 서비스 수행을 의뢰합니다. 즉, 로그인과 계좌이체 유즈케이스는 자신의 서비스 수행단계 중 특정한 시점에서 사용자 인증 서비스의 수행을 요청하는 것입니다. ##########574* ##########575* ##########576* 정의 및 특징 ##########577* ##########578* extend는 유즈케이스와 유즈케이스 사이에 정의되는 관계입니다. ##########579* ##########580* extend 관계는 include 관계와 마찬가지로 한 유즈케이스가 다른 유즈케이스의 서비스 수행을 요청하는 관계입니다. ##########581* ##########582* 다만, include관계와는 달리 수행요청을 의뢰받은 서비스는 수행되지 않을 수도 있습니다. ##########583* ##########584* 즉 수행을 의뢰하는 유즈케이스는 조건에 따라 수행을 의뢰할 수도 있고 의뢰하지 않을 수도 있습니다. 이것이 include관계와의 차이점입니다. ##########585* ##########586* 수행을 의뢰할 조건을 extension point 라고 합니다. ##########587* ##########588* include와는 달리 하나의 유즈케이스에 의해 서비스 수행을 요청받을 수도 있습니다. ##########589* ##########590* 표기법 ##########591* ##########592* 화살표 붙은 점선에 <<extend>> 스테레오타입을 정의합니다. ##########593* ##########594* 화살표는 include와 반대로 수행될 유즈케이스에서 수행을 의뢰하는 쪽으로 향함합니다. ##########595* 모델 설명 ##########596* 고객목록조회(유즈케이스)는 고객상세 정보 조회(유즈케이스)의 서비스 수행을 의뢰합니다. 그런데 무조건 의뢰하는 것이 아니고, 고객의 요청이 있을 경우에 한해 상세정보조회 서비스의 수행을 요청합니다.   4. 사례연구   ##########597* ##########598* 다음은 어느 회사의 간단한 인사시스템의 유즈케이스 다이어그램입니다. 유즈케이스 다이어그램의 실 사례를 편안한 마음으로 보시면서 이 다이어그램이 의미하는 시스템 영역과 기능을 정리할 수 있는지 판단해 보시기 바랍니다. ##########599* ##########600* ##########601* 어느 회사의 간단한 인사관리시스템입니다. 이 시스템의 사용자는 액터인 인사담당자와 시스템관리자입니다. 인사담당자에게 시스템은 인사정보를 신규등록하고 수정하고 인사현황 조회를 서비스합니다. 그리고 이를 위해 사원 검색 서비스를 공통 서비스로 분리하여 정의하였습니다. 시스템 관리자는 기준정보를 관리합니다. ##########602* ##########603* 실제 현실에서 경험할 수 있는 사례를 가지고 모델링을 수행한 결과를 살펴보도록 하겠습니다. 아래에 기술된 문제영역은 모델링의 대상이 되는 주제와 이것과 관련된 주변정보를 제공합니다. 이 문제영역에 대한 분석을 통해 실제 유즈케이스 다이어그램을 작성하고 이를 소개하도록 하겠습니다. 여러분은 "문제영역" 설명을 보시고 현재까지의 지식을 총 동원하여 나름대로 유즈케이스 다이어그램을 작성해 보십시오. 그런 다음 "문제영역에 대한 유즈케이스 다이어그램" 항목의 기준모델과 비교해 보시기 바랍니다. 모델링은 눈으로 익히는 것이 아니라 손과 머리로 익히는 것입니다. ##########604* ##########605* A병원은 이번 기회에 SW시스템을 구축하여 업무의 일부를 자동화 하기를 원합니다. A병원에는 기존시스템으로 병원의 수입과 지출을 관리하는 "회계시스템"이 운영되고 있습니다. 이 시스템과 연계하면서 병원정보, 환자의 병력및 진료정보, 의료진 정보의 각종 정보관리와 진료예약 처리 및 수납지원을 수행하는 신규 시스템을 구축하기를 원하고 있습니다. 병원의 각 관계자는 시스템을 통해 아래와 같은 기능을 수행하기를 원합니다. ##########606* ##########607* 진료비는 진료정보를 입력하면 자동 산정됩니다. ##########608* ##########609* 환자는 진료 예약을 하고, 환자의 과거병력과 진료정보는 관리됩니다. ##########610* ##########611* 일반사용자는 병원 정보와 의료진 정보를 조회하고 상담 및 문의를 할 수 있습니다. ##########612* ##########613* 의료진은 자신의 진료스케쥴을 자동 생성하고, 진료 내역을 관리하고, 환자 정보를 조회하기를 원합니다. ##########614* ##########615* 원무과 직원은 이 시스템을 통해 진료비 청구서를 조회, 발행하고, 진료예약을 확정하기를 원합니다. ##########616* ##########617*

 

  5. 작성단계 및 주의사항

 

	##########618*
##########619*

유즈케이스 다이어그램을 작성하는 순서는 딱 정해진 바는 없습니다. 그러나 프로젝트 현장에서는 다음의 순서대로 작성하는 것이 일반적입니다. 물론 순서를 꼭 지켜야만 하는 것은 아닙니다. ##########620* ##########621* ##########622* ##########623* ##########624* ##########625* ##########626* ##########627* ##########628* ##########629* 액터를 식별합니다. ##########630* ##########631* 시스템의 모든 사용자의 역할을 식별합니다. ##########632* ##########633* 시스템과 상호작용하는 타 시스템를 식별합니다. ##########634* ##########635* 시스템과 정보를 주고받는 하드웨어나 지능형 장치를 식별합니다. ##########636* ##########637* 유즈케이스를 식별합니다. ##########638* ##########639* 액터가 요구하는 서비스를 식별합니다. ##########640* ##########641* 액터가 요구하는 정보를 식별합니다. ##########642* ##########643* 액터가 시스템과 상호작용하는 행위를 식별합니다. ##########644* ##########645* 관계를 정의합니다. ##########646* ##########647* 액터와 액터간의 관계를 분석하고 정의(generalization 관계)합니다. ##########648* ##########649* 액터와 유즈케이스간의 관계를 분석하고 정의(communicates)합니다. ##########650* ##########651* 유즈케이스와 유즈케이스 간의 관계를 분석하고 정의(include, extend, generalization) 합니다. ##########652* ##########653* 유즈케이스를 구조화(factoring)합니다. ##########654* ##########655* 두 개 이상의 유즈케이스에 존재하는 공통 서비스 추출합니다. ##########656* ##########657* 추출된 서비스를 유즈케이스로 정의합니다. ##########658* ##########659* 공통 서비스를 사용하는 유즈케이스와 신규 유즈케이스의 관계를 정의(include)합니다. ##########660* ##########661* 조건에 따른 서비스 수행부분을 분석하여 추출합니다. ##########662* ##########663* 추출된 서비스를 독립 유즈케이스로 정의합니다. ##########664* ##########665* 추출된 서비스를 사용하는 유즈케이스와 관계를 정의(extend)합니다.

	##########666*
##########667*

다음은 유즈케이스 다이어그램시 작성시 주의사항입니다. ##########668* ##########669* 액터와 유즈케이스의 명칭은 직관적으로 이해할 수 있는 명쾌한 것으로 정해야 하며, 모호한 명칭은 삼가합니다. 예) 전체정보를 피드백하다(X), 활동을 탐색하다(X), 신규회원정보 등록(O) ##########670* ##########671* 사용자 관점이라는 전제를 잊으면 안 되겠습니다. 예) Data Window 출력(X), 회원정보 검색(O) ##########672* ##########673* 모든 유즈케이스는 반드시 하나 이상의 액터와 교류해야 합니다. (단, include/extend 관계의 유즈케이스는 직접 actor와 관계를 갖지 않을 수도 있습니다. 그러나, 이 경우는 include/extend 요청 유즈케이스와 하나로 간주하므로 상관없다고 하겠습니다.) ##########674* ##########675* 유즈케이스의 추상화 레벨은 비슷한 레벨이어야 합니다. 즉, 어떤 것은 아주 개념적인데 비해 어떤 것은 구체적이어서는 안됩니다. 예) - 고객을 관리하다 vs. 고객정보를 입력하다.       - 회계시스템과 인터페이스하다 vs. 과정수강정보를 회계시스템에 제공 ##########676* ##########677* 유즈케이스의 크기단위(granularity)는 일정해야 합니다. 즉 동일한 유즈케이스 다이어그램에서 어떤 것은 여러 유즈케이스로 나뉠만한 매우 큰 단위인데, 어떤 것은 여러 개의 작은 유즈케이스로 정의되어서는 안됩니다. 예) 파일관리 vs. 파일저장/파일열기

1. 개요

	##########678*
##########679*

유즈케이스 정의서는 "유즈케이스 다이어그램의 각 유즈케이스에 대해 처리 흐름을 상세히 정의한 문서"입니다. 이 문서는 통상 자연어로 기술됩니다. 그러나 자연어로 기술하라는 것이 정해진 것은 아닙니다. 문서의 내용이 유즈케이스의 처리 흐름을 정의한 것이기 때문에 그 목적을 만족하는 것이라면 형태에 구애받지는 않습니다. ##########680* ##########681* ##########682* 즉, 수학적인 표식이어도 되고, 처리 흐름을 알 수 있는 도표로 표현되어도 됩니다. 단, 혼자만 알 수 있는 표현이면 안 되고, 모든 사람, 특히 전산지식이 없는 사람도 쉽게 이해할 수 있는 표현이어야 하고, 표준화가 전제되어야 합니다. 유즈케이스 정의서는 UML을 적용하는 대부분의 현장에서 작성하고 있으며, 이 산출물을 작성하는 것을 당연한 것으로 생각하고 있습니다.

	##########683*
##########684*

유즈케이스 다이어그램은 SW 시스템의 외부환경과 SW 시스템간의 교류를 표현하는 다이어그램입니다. 유즈케이스 다이어그램은 사용자의 관점으로 작성하고, SW 지식이 깊지 않은 사용자라도 이해해야 하기 때문에 그 형식과 내용이 매우 간결하게 표현됩니다. 이런점 때문에 유즈케이스 다이어그램이 전달하고자 하는 내용은 부족한 점이 많습니다. ##########685* ##########686* 유즈케이스는 액터와 시스템의 일련의 교류 ##########687* 유즈케이스 다이어그램에서는 단지 교류가 있음을 나타내고 있을 뿐 시스템 내·외부간 교류의 세부적인 사항은 유즈케이스 다이어그램에서는 정의되지 않습니다. 따라서 보다 정확한 시스템의 이해를 위해서는 유즈케이스 다이어그램을 보완하여 내부의 자세한 처리 내용을 기술하여 정의하는 것이 필요합니다. 바로 유즈케이스 정의서는 이러한 필요성에 따라 유즈케이스의 처리 흐름을 상세하게 정의하는 문서인 것입니다. 그럼 유즈케이스 정의서를 작성하는 목적은 무엇일까요? 유즈케이스 정의서의 작성목적은 다음과 같습니다. ##########688* ##########689* 유즈케이스별 처리 흐름을 기술함으로써 SW 시스템에 대한 기능적 요구사항을 더욱 명확히 합니다. ##########690* ##########691* 유즈케이스 모델링 이후 계속되는 분석 작업의 기준을 세웁니다. ##########692* ##########693* 유즈케이스 정의서 작성과정에서 공통 서비스("include"관계의 유즈케이스)를 발견함으로써 유즈케이스 모델을 완전하게 합니다. ##########694* ##########695* SW 시스템 개발 후 사용자가 요구한 대로 개발되었는지를 테스트하는 기준을 정의합니다.

	##########696*
##########697*

유즈케이스 정의서의 작성시기는 유즈케이스 다이어그램이 만들어진 직후입니다. 그러나 모든 UML로 작성되는 모델들이 그렇지만 한번에 완전한 산출물을 만드는 것은 아닙니다. 다른 모델들이 반복적으로 정련되는 것처럼 유즈케이스 정의서도 그렇습니다. 최초로 작성되는 시점은 유즈케이스 다이어그램이 작성된 직후이지만, 다음과 같은 시기에 정렬을 위해 내용이 수정됩니다. ##########698* ##########699* include관계, extend관계의 유즈케이스가 정의될 경우 이 경우 공통의 처리흐름을 기술한 부분이 독립적인 유즈케이스로 정의되는 것이므로 해당 부분이 수정되어야 합니다. ##########700* ##########701* 사용자의 요구사항이 변경되는 경우 시스템 기능에 대한 사용자의 요구사항은 때때로 변경됩니다. 그 경우마다 유즈케이스 다이어그램은 물론 유즈케이스 정의서는 변경되어야 합니다. ##########702* ##########703* SW 시스템의 설계 도중 시스템의 기능이 변경될 경우 SW 시스템의 설계가 진행되면서 기술상의 이유로 시스템의 기능이 변경될 수 있습니다. 이럴 경우 역시 유즈케이스 다이어그램은 물론 유즈케이스 정의서는 변경되어야 합니다. ##########704* 유즈케이스 정의서 작성 시기를 결정한 후 정의서를 작성하기 위해서는 먼저,유즈케이스 다이어그램이 그려져 있어야 합니다.

	##########705*
##########706*

유즈케이스 정의서는 다음과 같이 구성됩니다. 유즈케이스 정의서는 통상 자연어로 기술되기 때문에 본 구성은 문서의 목차와 비슷합니다. ##########707*                                                        목차                     Use Case 명 : 유즈케이스 정의서 개요                     이벤트흐름 : 기본흐름, 선택흐름                     특별요구사항                   사전조건                     사후조건                     향후조건 ##########708* ##########709* 유즈케이스 정의서의 표준양식 유즈케이스 정의서의 표준 양식은 없다고 할 수 있습니다. UML의 사양을 정의한 공식문서인 "OMG Unified Modeling Language Specification"에는 유즈케이스 정의서(Use case Specification)에 대한 표준은 언급하고 있지 않기 때문입니다. 유즈케이스 정의서의 내용은 UML을 더 풍부하게 응용하는 차원이기 때문에 적절한 형식을 정의하여 쓰면 됩니다. 다만, RUP(Rational Unified Method)라는 UML적용 방법론에서 정의된 양식이 많이 쓰이는 실정입니다. 여기에서 소개하는 내용도 RUP(Rational Unified Method)에서 제시한 양식을 소개합니다. 또한 차별성을 위해 사례는 모회사에서 자체적으로 표준으로 쓰는 것을 해설과 함께 소개하도록 하겠습니다. 앞서 언급한 UML의 사양을 정의한 공식 문서는 인터넷 주소 "www.omg.org"에서 무료로 공개하고 있습니다.

 

	##########710*
##########711*

##########712* Use case 명 ##########713* 유즈케이스 정의서의 제목 부분에 해당합니다. 유즈케이스 정의서는 유즈케이스 하나마다 작성됩니다. 따라서 유즈케이스 정의서가 어떤 유즈케이스에 대한 것인지를 명시합니다. 이 내용 후에는 유즈케이스가 하는 일에 대한 간략한 개요를 기술합니다. ##########714* ##########715* 이벤트 흐름(Flow of events) ##########716* 유즈케이스는 액터의 이벤트로 그 동작을 개시합니다. 이벤트란 응답을 유발하는 사건을 의미합니다. 예를 들면, "상품정보 요청" 이벤트는 시스템으로부터 상품정보를 제공하는 응답을 유발합니다. 이렇게 SW시스템 외부의 이벤트와 그 이벤트에 대한 시스템의 응답을 알면 시스템이 하는 일을 알 수 있습니다. 이렇게 이벤트 흐름(Flow of events)부분은 액터와 유즈케이스 사이의 이벤트 흐름, 즉 처리 흐름을 상세하게 정의하는 부분입니다.

자, 그러면 이벤트 흐름의 종류인 기본 흐름(Basic flow), 선택 흐름(Alternative flow)에 대하여 자세히 살펴봅시다.

##########717*

    기본흐름(Basic flow)

##########718* 이 유즈케이스가 실행되면 반드시 발생하는 기본적 처리 흐름을 기술합니다. 즉, 경우에 따라서 조건에 따라서 실행되는 처리 흐름이 아닌 무조건적으로 실행하는 처리 흐름이 기술되어야 합니다. 또한 처리 흐름 중에 반드시 하나를 선택해야 할 경우에는 대표적인 선택과 그에 따른 처리 흐름을 기술합니다. ##########719* ##########720* 이벤트 흐름이므로 기술되는 방식은 외부 이벤트글, 그에 대한 유즈케이스의 응답이 쌍으로 기술되도록 합니다. ##########721* ##########722* 각각의 처리 흐름을 구분하고 번호를 매겨 처리 순서도 표현합니다. ##########723* ##########724* 위 그림에서 처리 1과 처리 3 부분이 기본 흐름에 해당됩니다.

  선택흐름(Alternative flow)

##########725* 기본 흐름과는 달리 조건과 상황에 따라 추가적으로 혹은 달리 실행되는 처리 흐름에 대하여 기술하는 부분입니다. 유즈케이스가 액터의 선택 결과에 따라 다른 처리 흐름으로 진행해야 할 경우가 있을 때 기술합니다. ##########726* ##########727* 선택 흐름은 기본 흐름에서 가지 쳐 나온 처리 흐름입니다. ##########728* ##########729* 위 그림에서 처리 2에 해당되는 부분이 선택 흐름에 기술됩니다.

##########730* 특별 요구사항(Special Requirement) ##########731* 이 유즈케이스가 실행될 때 기능 외의 특별한 요구사항을 기술하는 부분입니다. 특별 요구사항에 정의될 수 있는 것들은 다음과 같습니다. ##########732* ##########733* 표준에 관한 요구사항(어플리케이션 표준) ##########734* 품질과 관련된 요구사항(성능, 신뢰성 등) ##########735* 기술관련 요구사항(OS, 호환성, 기타 설계 제한사항) 등 ##########736* ##########737* 사전 조건(Pre-Conditions) ##########738* 유즈케이스가 실행되기 위한 전제 조건을 명시하는 부분입니다. 이 사전 조건을 만족하지 못하는 한 유즈케이스는 실행될 수 없습니다. 사전 조건은 다른 유즈케이스가 실행된 후에 만족하는 경우가 많습니다. 이 부분도 자연어로 기술되고 사전 조건이 여러 개인 경우 번호를 붙여 나열합니다. ##########739* ##########740* 사후 조건(Post-Conditions) ##########741* 유즈케이스가 실행한 후의 시스템 상태가 변화한다면 이를 명시하는 부분입니다. 시스템의 상태가 변화한다는 것은 다른 유즈케이스의 실행에 영향을 주는 변화를 의미합니다. 이러한 사후 조건을 기술하는 유즈케이스는 많지 않습니다. ##########742* ##########743* 확장 조건(Extension Points) ##########744* 유즈케이스가 다른 유즈케이스를 <<extend>>할 경우 다른 유즈케이스를 실행하는 조건을 정의합니다. 즉 특정 조건이 만족하면 다른 유즈케이스를 사용(실행)하는 extend 관계를 가질 경우, 그 조건을 명시하는 부분입니다. extend 관계가 없는 유즈케이스의 경우 이 부분은 생략됩니다.

	##########745*
##########746*

다음 제시되는 것은 RUP의 Use case specification 템플리트를 기본으로 해서 정의한 양식사례입니다. 실제 프로젝트에서 작성한 것이며, 현업에 적용하기 쉽게 정의된 형태입니다. ##########747* 유즈케이스 정의서 시스템명 XX시스템 작성일 2001.09.14 페이지 1/2 Use Case 명 개인고객등록 작성자 홍 길 동 1. 개요 ##########748*      영업담당자가 개인고객(키맨, 협력자, 가망고객, 가족, 친구)의 정보를 등록한다. ##########749* 2. Relationships ##########750*      ▶ Initiator                 영업담당자      ▶ Pre-condition      ▶ Post-condition ##########751* 3. Flows of Events ##########752*      3.1 Main Flows            1. 영업담당자가 고객유형(N-1)을 '키맨'으로 선택한다(A-1).            2. 영업담당자가 고객소속구분(N-2)을 'XXX'로 선택한다(A-2).                         3. 시스템은 XXX 리스트를 로드한다.            4. 영업담당자가 등록하고자 하는 개인이 속한 회사를 선택한다.            5. 영업담당자가 개인고객정보(N-3)를 입력하고 저장을 요청한다.                         6. 시스템은 성공적으로 저장되었음을 알려주고 Use Case를                             종료한다. ##########753*      3.2 Alternative Flows        A-1. '가족' 또는 '친구'를 선택할 경우            1. 영업담당자가 고객유형을 '가족'(또는 '친구')로 선택한다.                → Main Flow의 5번으로        A-2. '활동담당사업장'을 선택할 경우            2. 영업담당자가 고객소속구분을 'YYY'로 선택한다.            3. 시스템은 YYY를 로드한다.            4. 영업담당자는 개인고객이 속한 회사를 선택한다.                → Main Flow의 5번으로        A-3. '개별'을 선택할 경우(가망고객의 경우만 가능)            1. 영업담당자가 고객소속구분을 '개별'로 선택한다.                → Main Flow의 5번으로      3.3 Exception Flows ##########754* 4. Note ##########755*       N-1. 고객유형 : 키맨, 협력자, 가망고객, 가족, 친구       N-2. 고객소속 구분 : 활동담당 기업, 활동담당 사업장, 개별(가망고객의 경우만)       N-3. 개인정보 항목 ##########756* 구분 항목   성명, 주민등록번호(미입력시 Warning) 기본정보 실제생일(양/음), 결혼기념일, 취미, 혈액형, 출신지, 종교, 주량, 흡연, Mobile Phone, e-mail 자택정보 주소, 전화, 부인생년월일(양/음), 가족특이사항(부인/ 자녀-출산, 진학,취직, 결혼 등) 직장정보 직장명, 주소, 부서명, 직책, 직급, 직업, 전화, FAX, 입사일 학력/재무정보 출신고, 출신대, 대학전공, 대학원, 대학원전공, 경력사항, 년소득, 특기사항 ##########757*

	##########758*
##########759*

유즈케이스 정의서의 작성단계는 특별히 존재하지는 않습니다. 정해진 목차의 순서에 따라 작성하면 됩니다. 작성하는 시점에 결정되지 않은 항목에 대해서는 생략하고 넘어간 후 추후 작성하도록 합니다. 유즈케이스 정의서 작성 시 주의사항은 다음과 같습니다. ##########760* ##########761* ##########762* 유즈케이스 정의서 작성 시 간결하고 명료한 표현을 사용해야 합니다. 불 필요하게 장황한 설명을 하거나 처리 흐름을 명확하지 않게 표현해서는 안됩니다. ##########763* ##########764* 유즈케이스 정의서는 액터와의 상호작용에 초점을 맞추어 기술해야 합니다. 즉, 액터의 요구(이벤트)와 유즈케이스의 응답의 관점에서 기술합니다. ##########765* ##########766* 물리적인 구현 관점의 용어가 언급되지 않도록 주의해야 합니다. 유즈케이스 정의서는 구현 사양을 기술한 것이 아닙니다. 이후 어떤 구현 환경으로도 구현될 수 있다는 생각으로 정의해야 합니다. 또한 유즈케이스 정의서는 SW 지식이 없는 사람도 이해할 수 있어야 합니다. ##########767* GUI(Graphic User Interface) 용어 화면, 버튼, 프레임, 그리드, 리스트, 더블클릭 등 ##########768* 시스템 용어 EJB, Socket, JDBC, JNDI 등 Entity, Table, Row, Column 등 ##########769* ##########770* 모호한 용어나, 지나치게 추상화된 처리 흐름으로 기술하지 말아야 합니다. 유즈케이스 정의서 작성 도중 유즈케이스 다이어그램을 수정해야 할 경우에는 바로 수정합니다. 단 수정의 결과로 기능의 변경으로 인해 사용자와 합의가 필요한 경우, 합의를 먼저 득한 후 수정합니다.

클래스 다이어그램 이란 무엇일까요? 클래스 다이어그램은 곧바로 프로그램 코드로 변환할 수 있는 모델입니다. 예를 들어 볼까요? 아파트 단지를 건축한다고 했을 때 아파트를 짓기 위해서는 여러 가지 설계도를 그리게 되지만, 현장 작업자의 손에 전달되어 그대로만 하면 아파트가 지어지는 그런 도면은 하나입니다. 개념도와 아파트 동 배치도와 같은 것이 아니라, 완전한 아파트 내부의 설계도는 한 종류인 것이죠. 이처럼 건축에서와 같이 프로그래머가 시스템을 구축할 때 곧바로 프로그램 코드로 변환할 수 있는 설계도와 같은 그러한 기능을 하는 것이 바로 클래스 다이어그램입니다. 다른 다이어그램들은 클래스 다이어그램을 이해하는 보조적인 용도로 사용될 뿐입니다. 클래스 다이어그램, 중요하겠지요? 마음을 가다듬고 시작해 볼까요?   ##########771* ##########772* 클래스 다이어그램은 "시스템에서 사용되는 객체 타입(클래스)을 정의하고 그들 간에 존재하는 정적인 관계를 다양한 방식으로 표현한 다이어그램"입니다. ##########773* 클래스 다이어그램은 객체지향 SW 시스템을 분석하고 설계하는 데 사용되는 핵심적인 모델입니다. 객체지향 SW 시스템은 클래스와 그 관계로 뼈대가 구성되기 때문에 이를 정의한 클래스 다이어그램은 곧 시스템의 구현될 모습을 정의한 것입니다. 클래스 다이어그램은 분석되거나 설계되는 모든 클래스를 한 장의 다이어그램으로 정의한 것입니다. ##########774* 클래스 다이어그램은 클래스의 정적인 정의와 관계를 표현합니다. 객체가 아닌 클래스는 본질적으로 "정적(靜的)"입니다. 시간과 조건이 개입되지 않기 때문입니다. ##########775* 그러나 객체는 그 자체가 동적(動的)인 개념을 가집니다. 클래스에서 파생된 것이 객체이고, 객체는 상태와 행위가 시간과 구체적인 조건에 따라 변화하고, 또한 다른 객체와 동적으로 상호 작용하는 것이기 때문입니다. ##########776* ##########777* 단연 대표적인 UML의 다이어그램이라고 할 수 있는 클래스 다이어그램을 작성하는 목적은 다음과 같습니다. ##########778* 객체지향 SW시스템의 기본 단위인 클래스를 식별하고 그 관계를 정의하는 유용한 방식을 제공합니다. ##########779* 클래스 다이어그램은 객체지향 SW 시스템의 기본 단위인 클래스의 정의를 용이하게 함으로써 시스템을 구축하는 본격적인 단계로 인도합니다. ##########780* ##########781* 클래스 간의 정적인 협력관계를 정의함으로써 시스템을 이해하는데 용이하게 합니다. ##########782* 하나의 클래스가 할 수 있는 일은 적습니다. 한 단위의 임무를 수행하려면 클래스간의 협력은 필수적으로 필요합니다. 클래스 다이어그램은 이러한 클래스간의 정적인 협력관계를 정의함으로써 시스템을 분석하고 이해하는데 도움을 줍니다. ##########783* ##########784* 클래스의 오퍼레이션과 속성을 상세히 정의함으로써 SW시스템을 설계합니다. ##########785* 클래스의 속성과 오퍼레이션을 상세히 정의하는 일은 객체지향 SW 시스템에 있어서의 설계를 의미합니다. 클래스 다이어그램은 이러한 설계관점의 작업을 쉽게 수행하는데 도움을 주어, 시스템 구축 과정에 큰 역할을 합니다. ##########786* ##########787* 논리적인 관점으로부터 물리적인 관점까지 시종 일관된 형식으로 SW 시스템을 분석, 설계하는 방식을 제공합니다. ##########788* 기존 방식의 가장 큰 단점인 분석/설계 모델간의 차이(gab)를 극복하고, 동일한 형식과 관점을 제공함으로써 의미의 소실없이 효과적인 시스템 분석, 설계방식을 제공합니다. 클래스 다이어그램을 적용한 분석설계는 객체지향 프로그래밍에 가장 가깝고 효과적인 방식입니다. ##########789* ##########790* ##########791* ##########792* 클래스 다이어그램을 작성하는 시기는 정확히 언제라고 단정할 수는 없습니다. 보통 SW시스템의 분석단계와 설계단계에서 여러 번 작성됩니다. 여러 번에 걸쳐 클래스 다이어그램이 작성되면서 점점 상세화되고 정련되는 과정을 거칩니다. ##########793* 이렇게 여러 번 작성하는 이유는 이 다이어그램을 작성하는 시기마다 그 관점이 변화하기 때문입니다. 분석단계에서는 분석의 관점에서 클래스를 정의하고 설계단계에서는 설계의 관점에서 클래스를 정의하게 됩니다. 그래서 클래스 다이어그램은 작성이 반복될 때마다 진화하지만, 단계 단계마다 작성되는 클래스 다이어그램 자체도 나름대로 의미가 있습니다. ##########794* 보통의 경우 아래와 같은 시기에서 클래스 다이어그램이 작성됩니다. ##########795* ##########796* ##########797* ##########798* ##########799* 클래스 다이어그램을 작성하려면 사용자의 요구사항이 정의되고, 개발할 SW 시스템에 대한 범위가 정의되어야 합니다.   ##########800* ##########801* Class diagram을 처음부터 상세하게 정의할 수는 없습니다. 그래서 상세한 class diagram을 얻기 위해 단계적으로 상세화시켜 나가는 방식을 사용합니다. Class Diagram은 다음과 같이 3가지 관점으로 반복적이면서 점증적인 방식으로 작성해 나갑니다.   Conceptual level - 개발범위에 속해있는 문제영역에 대해 단순한 관계를 도출하는데 중점 - 업무 관점의 class 들만 도출하고, 구현에 관련된 시각은 최대한으로 배제   Specification level - 구현관점을 살려 모델링을 수행 - 어떻게 코딩할 건지에 대한 관점을 배제 - 클래스의 속성과 오퍼레이션을 될 수 있는 한 상세히 정의하고, 구체적인 플랫폼(개발언어의 특성 등)특성을 반영하지 않음.   Implementation level - 언어와 개발플랫폼이 가진 특성 및 제한 사항을 반영 - 정의된 class를 보고 정해진 개발언어로 개발자가 코딩을 하기에 충분한 정보를 모두 표현   ##########802* ##########803* 클래스 다이어그램의 구성요소는 다음과 같습니다. ##########804* ##########805* ##########806* ##########807* ##########808* ##########809* 일반적인 클래스 표기법 ##########810* 클래스는 일반적인 표기와 icon 표기 두 가지의 표기가 가능합니다. 일반적인 표기는 단순형 표기와 정규형 표기등 두 가지가 있습니다. ##########811* ##########812* ##########813* 단순형 표기 정규형 표기 ##########814* 직사각형에 클래스 명을 표기 ##########815* ##########816* Conceptual Level(개념 단계)의 클래스 다이어그램을 작성할 경우나, 클래스가 많아 그림이 복잡할 경우의 생략형 표현 ##########817* 세 개의 가로 간이 있는 사각형에 각각 클래스 명, 속성, 오퍼레이션을 차례로 표기 ##########818* ##########819* ##########820* 스테레오 타입이 정의된 클래스 표기법 ##########821* 스테레오 타입이 정의된 클래스의 경우 그 표기법은 달라집니다. 클래스의 스테레오 타입 중 대표적인 것은 <<boundary>> , <<control>> , <<entity>>, <<interface>> 입니다. 이를 일반형 표기와 icon 표기로 나타낸 것은 다음과 같습니다. ##########822* ##########823* ##########824* ##########825* ##########826* 클래스는 크게 대별하면 Boundary, Entity, Control 다음 세 가지 종류로 구분할 수 있습니다. ##########827* ##########828* Boundary Class ##########829* 사용자와 인터페이스를 담당하는 클래스입니다. 주로 UI(User Interface)에 짝을 이루어 정의됩니다. 이 클래스의 역할은 다음과 같습니다. ##########830* ##########831* 사용자로부터 UI 이벤트를 직접 받아서 시스템 내부에 처리를 의뢰합니다. ##########832* ##########833* 시스템으로부터의 응답을 UI를 조작하여 사용자에게 보여 줍니다. ##########834* ##########835* 사용자의 적절치 못한 입력에 대해서는 오류 메시지 등을 통해 직접 처리합니다. ##########836* ##########837* Control Class ##########838* Boundary Class와 Entity Class사이의 처리를 중재하고 제어하는 클래스입니다. 이 클래스의 역할은 다음과 같습니다. ##########839* ##########840* 여러 클래스간의 협력작업을 제어하고 클래스간의 실행순서를 통제합니다. ##########841* ##########842* 결과를 조합하여 Boundary Class에 전달합니다. ##########843* ##########844* 데이터를 처리하는 도중에 발생하는 Transaction을 관리합니다. ##########845* ##########846* Entity Class ##########847* 원하는 처리에 필요한 정보(데이터)를 관리하는 클래스입니다. 이 클래스의 역할은 다음과 같습니다. ##########848* ##########849* 처리에 필요한 데이터를 읽어 옵니다. ##########850* ##########851* 데이터를 저장합니다. ##########852* ##########853* 데이터를 삭제합니다. ##########854* ##########855* 데이터를 수정합니다. ##########856*