Unified Modeling Language UML 2.0 Chapter.10 UML Unified Modeling Language UML 2.0 Media System Lab., Yonsei University

Index Modeling 개요 UML 개요 UML View 종류 및 개념 UML Diagram 분류 HCI 에서 사용되는 UML HCI 프로젝트 적용 예시

Modeling 개요 모델링의 중요성 모델링이란 모델링의 목적 모델이란: 현실을 단순화시킨 것으로서 시스템의 청사진 제공 현실을 단순화/가시화 시키는 것 System의 Blueprint를 제공 개발 고려 시스템의 총체적인 계획 및 상세 계획 표현 중요 영향 요소의 파악, 불필요 요소의 생략 및 시스템 구축 제약 조건 표현 모델링이란 개발 대상 시스템에 대한 이해를 증진 질이 좋은 프로젝트를 개발 효과적인 인터페이스의 설계 모델링의 목적 시스템을 현재 또는 원하는 모습으로 가시화 시스템의 구조와 행동을 명세화 시스템을 구축하는 기본 형태를 제공 시스템 분석/설계의 문서화

UML 개요 UML의 배경 UML을 이용한 모델링의 특성 80년대 후반과 90년대 초반 등장하기 시작한 객체지향적 분석 및 설계방법론 들간의 치열한 경쟁 가장 유력한 방법론이었던 Rumbaugh의 OMT, Booch의 OOAD, Jacobson의 OOSE이 UML이라는 하나의 모델링 언어로 통합되게 됨 1997년 9월 Rational사는 UML버전 1.1을 발표하고 OMG에 의해 표준표기법으로 받아들여지게 됨 2007년 현재 UML 2.0 까지 발표(http://www.uml.org) UML을 이용한 모델링의 특성 사용사례 분석기법을 사용하여 사용자 관점에서의 업무과정을 포착할 수 있음 업무객체와 업무논리를 포착할 수 있도록 하는 커뮤니케이션 도구로써 업무객체와 업무논리로부터 응용시스템을 분석하고 설계할 수 있도록 함 시스템의 복잡성을 관리할 수 있도록 함 : 사람은 보통 한번에 7+-2개만을 효과적으로 다룰 수 있다. 소프트웨어의 아키텍처를 정의할 수 있도록 함. 프로그래밍 언어 등 시스템구현 환경과 독립적으로 시스템을 모델링 할 수 있다. 예)3계층 소프트웨어 아키텍처에 따라 사용자 인터페이스는 비쥬얼 베이직 혹은 자바, 업무논리는 C++ 혹은 자바, 데이터베이스 서버는 C++과 SQL로 구현 재사용을 촉진시킨다. 즉, 재사용 가능한 시스템구성 컴포넌트를 모델링함으로써 이를 여러 시스템에서 사용할 수 있다.

UML 의 정의 UML UML(Unified Modeling Language)의 정의 가시화 언어 개념 모델 작성 오류 없이 전달 의사 소통의 용이 Graphic 언어 구축 언어 다양한 Prog. 언어와 연결 왕복 공학 가능(순/역공학) 실행 시스템 예측 가능 명세화 언어 정확한 모델 제시 완전한 모델 작성 분석,설계의 결정 표현 문서화 언어 시스템에 대한 통제, 평가, 의사소통의 문서 (요구사항, Architecture, 설계, Source Code, Project 계획,Test, Prototype, Release)

UML 의 특징 UML의 특징 가시화 언어(Language for Visualizing) 문서를 보는 사람들은 시스템에 대해 동일한 의미를 공유할 수 있게 됩니다. 2. 명세화 언어(Language for Specifying) 명세화란 정확하고, 명백하며, 완전한 모델을 의미하는데, UML은 분석, 설계, 구현에서의 모든 중요한 결정에 대한 명세서를 다룰 수 있게 합니다. 3. 구축하는 언어(Language for Constructing) UML 언어에서는 프로그래밍 코드를 생성하는 것이 가능하고, 또한 구현된 코드로부터 UML 모델을 다시 생성할 수 있는 역공학(reverse engineering)도 가능합니다. 4. 문서화 언어(Language for Documenting) UML은 시스템 구조와 그것의 모든 상세 내역에 대한 문서화를 다루며, 요구사항을 표현하고 시스템을 시험하는 언어와 프로젝트 계획과 배포관리 액티비티를 모델링하는 기능을 제공합니다.

UML View Design View Implementation View 정적/동적 측면을 동시에 바라보는 논리적인 뷰 어휘 기능성 시스템 조립 형상관리 Use Case View 실제구동환경 성능 확장성 처리량 Process View Deployment View 시스템 구성 형태 분산, 인도, 설치

UML View UML의 뷰 Use case View Design View 외부활동자(actor)에 의해서 인지된 시스템이 제공해야 하는 기능들을 묘사 actor는 시스템과 상호작용하는 사용자 or 다른 시스템이 될 수 있음 고객, 설계자, 개발자, 시험자에 의해 사용될 수 있음 사용사례 뷰는 다른 뷰의 개발을 유도한다는 점에서 중요함 시스템개발의 최종목적이 사용사례 뷰에서 제시된 기능을 제공하는 것이라고 할 수 있음 Design View 시스템의 기능들이 어떻게 제공되는지를 묘사 설계자, 개발자에 의해 주로 이용됨 시스템 내부를 들여다보는 것으로 정적구조(클래스, 객체, 관계) 및 객체간의 메시지 교환을 보여주는 동적인 협력도 묘사한다. 정적구조: 클래스 및 객체 다이어그램 동적협력구조: 상태, 연속, 협력, 활동 다이어그램 시스템 분석 및 설계 담당자

UML View Process View Implementation View Deployment View 실제 구동 환경을 살펴봄 시스템의 성능, 신축성, 처리 능력을 표현 시스템의 동시성과 동기화 메커니즘을 형설하고 있는 Thread와 Process로 구성 Implementation View 구현 모듈과 모듈간의 의존성을 묘사 주로 개발자에 의해서 사용됨 Deployment View 컴퓨터와 주변장치, 이들이 어떻게 연결되어 있는지를 묘사 개발자, 시스템 통합자, 시험자에 의해서 사용됨 시스템 배포 및 시스템 엔지니어

UML 구성 요소

UML 구성 요소 Things(사물) Relationships(관계) Diagrams(도해) 추상적인 개념으로, 모델에서는 주제를 나타내는 요소 언어로서의 UML을 생각해 볼 때 단어에 해당, 단어 중에서도 명사 혹은 동사의 의미를 가지는 요소 UML을 그림으로 생각해 볼 때 Things는 도형의 형식을 가짐 Things의 유형과 종류에 따라 사전에 부여된 명확한 의미를 가짐 Relationships(관계) Things의 의미를 확장하고 더욱 명확히 하는 요소 Relationships는 Things와 Things를 연결하여 그들 간의 관계를 표현하는 요소 언어로서의 UML을 생각해 볼 때 Relationships는 단어에 해당하며, 단어 중에서도 형용사나 부사에 해당 UML을 그림으로 생각해 볼 때 Relationships는 선의 형식을 가짐 UML에서는 정해진 선만을 사용해서 Relationships를 표현, 이 선들은 사전에 부여된 명확한 의미를 가짐 Diagrams(도해) Things과 Relationships을 모아 그림으로 표현한 것 Diagrams에는 Things와 Relationships가 어우러진 한 장의 그림 UML에서는 그 그림의 형식을 9가지로 정의하고, 각 그림에 대해 용도와 목적을 정의 보통 UML이라는 용어는 9개의 Diagrams와 동일한 의미로 쓰임 언어로서의 UML을 생각해 볼 때 Diagrams는 주제를 담은 문장들로 이루어진 글월에 해당 글월은 문장(Things와 Relationships 몇 개가 합쳐진 형태)과 단어(Things, Relationships)들로 구성 Diagram 한 장은 바로 하나의 모델을 의미 따라서 UML은 9가지 종류의 모델 체계를 제시하고 있다.

다이어그램 클래스 다이어 그램(Class Diagram) : 클래스의 정의 및 복수 클래스간의 관련을 나타냅니다. 객체 다이어 그램(Object Diagram) : 객체를 나타냅니다. 시퀀스 다이어 그램(Sequence Diagram) : 객체 간의 메시지 패싱을 시간에 주목하여 나타냅니다. 협력 다이어 그램(Collaboration Digram) : 객체 간의 메시지 패싱을 객체에 주목하여 나타냅다. 상태 다이어 그램(State chart Diagram) : 객체의 상태 변화난 이동을 나타냅니다. 활동 다이어 그램(Activity Diagram) : 객체의 액션의 흐름을 플로어 차트처럼 나타냅니다. 컴포넌트 다이어 그램(Component Diagram) : 컴포넌트 다이어그램을 조합하여 시스 템 전체의 구성을 나타냅니다. 배치 다이어 그램(Deployment Diagram) : 컴포넌트 다이어그램을 조합하여 시스템 전 체의 구성을 나타냅니다. 유스케이스 다이어 그램(Usecase Diagram)  : 사용자 측에서 본 시스템의 사용 방법 을 나타냅니다.

4. UML의 구성요소[3] : 도해(diagrams) 1) 클래스도(Class diagram) 2) 객체도(Object diagram) 3) 쓰임새도(Use case diagram) 4) 순차도(Sequence diagram) 5) 협력도(Collaboration diagram) 6) 상태도(Statechart diagram) 7) 활동도(Activity diagram) 8) 컴포넌트도(Component diagram) 9) 배치도(Deployment diagram)

(1) Use Case Diagram Use Case Use Case 다이어그램의 필요성 Use Case 표기법 사용자의 시스템에 대한 요건을 이해하기 위한 것으로, 가장 근본적인 요소임 시스템의 Use Case View를 모델링하는 Diagram Use Case View란 시스템의 구현을 배제하고 시스템 전체 혹은 시스템의 일부분과 외부와의 Interaction 및 시스템 자체의 행위(Behavior)등을 보는 관점을 나타낸다. Use case는 이후의 모든 시스템분석, 설게, 개발, 시험에 걸쳐 영향을 미침 Use Case 다이어그램의 필요성 사용자와 개발자, 시스템 설계자와의 의사소통 도구 개발자에게 시스템에 대한 쉬운 이해를 제공하여 개발을 도움을 줌 Use Case는 개발 진행기간 동안 시스템의 행위에 대한 테스트의 기본 Use Case 표기법 Use Case는 시스템의 사용자 입장에서의 기능적인 요구사항을 나타낸다. Use Case는 시스템 내에서 혹은 외부 시스템과의 상호작용(Interaction)하는 행위들의 집합을 나타내다. 이러한 모든 Use Case는 내부의 구현을 생각하지 않는다.

(1) Use Case Diagram - 2 Use Case 다이어그램의 모델링 순서 Actor는 Use Case와의 Interaction시에 Use Case를 사용하는 사용자의 역할들의 집합을 말한다. Actor는 사람뿐만 아니라 하드웨어 디바이스, 다른 외부 시스템 등이 될 수 있다. Use Case 다이어그램의 모델링 순서 모든 Actor들을 추출한다. Actor중 좀 더 일반적인 혹은 더 특화된 Actor 들로 선별하여 구성한다. 각 Actor에 관한 Interaction에서 Use Case를 추출한다. 또한 이러한 Interaction을 통한 상태의 변화를 Use Case로한 추출한다. 여기서 추출된 Use Case에서 좀 더 일반적인 혹은 특화된 Use Case로 구성한다.

(1) Use Case Diagram의 예 - 3 신용카드 인증 시스템 Actor의 추출 신용카드를 사용하는 개인 고객, 단체고객 신용카드로 거래를 하는 소매기관 고객의 신용 상태를 처리하는 기관 Use Case의 추출 고객이 신용카드를 사용하여 카드 거래를 한다. 거래에 대한 대금을 처리한다. 고객개인의 계좌를 관리한다.

다이어그램 시나리오 작성 고객은 신용카드를 취급하는 소매점에 가서 카드를 가지고 거래를 한다. 소매점에서는 카드를 가지고 고객의 신용상태를 점검한 후 거래에 해당하는 금액을 처리한다. 소매점에서 카드에 해당하는 고개의 신용을 조회하면 금융기관에서 개인의 구좌를 확인하여 신용상태를 알려준다.

(1) 유스케이스 다이어그램 (Usecase Diagram) 유스케이스 다이어그램은 유스케이스를 그려놓은 다이어그램이다. 여기서 유스케이스란 말 그대로 컴퓨터 시스템과 사용자가 상호작용을 하는 하나의 경우이다. 예를들어 보험처리 프로그램의 경우에 "고객이 보험증권에 sign한다.",  "보험 판매원이 판매통계량을 종합한다." 등이 use case가 된다. 이러한 유스케이스 다이어그램은 시스템 구축의 초기에 이 시스템이 어떠한 일을 하는지에 대한 부분을 사용자 입장에서 이해할 수 있을 정도로 기술을 하여야 한다. 이러한 유스케이스 다이어그램은 사용자와의 대화수단으로 그리고 앞으로 구축해 나갈 때의 밑바탕이 되는 것이다. 그림 1 - 유스케이스 다이어그램

(3) 시퀸스 다이어그램 (Sequence Diagram) 시퀸스 다이어그램은 콜레버레이션 다이어그램과 함께 시스템의 동적인 면을 나타내는 대표적인 다이어그램이다. 시스템이 실행시 생성되고 소멸되는 객체를 표기하고 객체들 사이에 주고 받는 메시지를 나타내게 된다. 콜레버레이션 다이어그램 또한 메시지의 흐름을 나타내지만 시퀸스 다이어그램 만의 특징이라면 횡축을 시간축으로 하여 시간의 흐름을 나타내어 메시지의 순서에 역점을 두고있다.

상태 다이어그램 (Statechart Diagram) 상태 다이어그램은 한 객체의 상태 변화를 다이어그램으로 나타낸 것이다. 시스템의 실행시 객체의 상태는 메시지를 주고 받음으로써 또한 어떠한 이벤트를 받음으로써 많은 변화가 있을 수 있다.  실제 시스템에서 실행시 많은 객체가 생성되고 소멸된다. 이렇게 무수한 객체의 상태 전부를 모두 다이어그램으로 나타내는 것은 불가능하다.  결국 상태 다이어그램은 특별히 관심을 가져야 할 객체에 관하여 그리고 특정 조건에 만족하는 기간동안의 상태를 표시하여야 한다.

액티비티 다이어그램 (Activity Diagram) 액티비티 다이어그램은 플로우챠트가 UML에 접목이 되었다면 가장 이해가 빠를 것이다.  시스템 내부에 존재하는 여러가지 행위들 그리고 각 행위의 분기, 분기되는 조건 등을 모두 포함 하게 된다. 이러한 액티비티 다이어그램에서 기존 플로우 챠트와 다른 점은 어떠한 행위에 따라 객체의 상태를 표기할 수 있다는 것이다. 이러한 점을 제외하고 기존 플로우챠트와 표기법과 의미가 약간씩 달라질 뿐 크게 다르지 않다라고 보아도 좋다.

Reference Book Visual Modeling with Rational Rose and UML, Terry Quatrani, Addison Wesley UML Distilled Second Edition, Martin Fowler with Kendall Scott, Addison Wesley The Rational Unified Process An Introduction Second Edition, Philippe Kruchten The Unified Modeling Language Reference Manual, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison Wesley The Unified Modeling Language User Guide, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison Wesley Developing Enterprise Java Applications with J2EETM and UML, Khawar Zaman Ahmed, Cary E. Umrysh, Addison Wesley 초보자를 위한 UML, Joseph Schmuller, 곽용재 역, 인포북 Site OMG UML Resource Page http://www.omg.org/uml/ Cetus Links http://www.cetus-links.org/