Download presentation
Presentation is loading. Please wait.
1
UML 기초 개념 모델링이란 2. UML의 개요 3. UML의 뷰(view) 4. UML의 구성요소
2
1. 모델링의 중요성 모델링의 중요성 모델링의 목적 모델이란: 현실을 단순화시킨 것으로서 시스템의 청사진 제공
현실을 단순화/가시화 시키는 것 System의 Blueprint를 제공 개발 고려 시스템의 총체적인 계획 및 상세 계획 표현 중요 영향 요소의 파악, 불필요 요소의 생략 및 시스템 구축 제약 조건 표현 모델링이란 : 모델을 만드는 일(추상화)로써 품질이 좋은 소프트웨어를 개발 및 배치할 수 있 게 하는 모든 활동의 중심 모델 구축을 통해 개발 대상 시스템에 대한 이해의 증진 모델링의 목적 시스템을 현재 또는 원하는 모습으로 가시화 시스템의 구조와 행동을 명세화 시스템을 구축하는 기본 형태를 제공 시스템 분석/설계의 문서화
3
2. UML(Unified Modeling Language)의 개요[1]
80년대 후반과 90년대 초반 등장하기 시작한 객체지향적 분석 및 설계방법론 들간의 치열한 경쟁 가장 유력한 방법론이었던 Rumbaugh의 OMT, Booch의 OOAD, Jacobson의 OOSE이 UML이라는 하나의 모델링 언어로 통합되게 됨 1997년 9월 Rational사는 UML버전 1.1을 발표하고 OMG에 의해 표준표기법으로 받아들여지게 됨 UML을 이용한 모델링의 특성 사용사례 분석기법을 사용하여 사용자 관점에서의 업무과정을 포착할 수 있음 업무객체와 업무논리를 포착할 수 있도록 하는 커뮤니케이션 도구로써 업무객체와 업무논리로부터 응용시스템을 분석하고 설계할 수 있도록 함 시스템의 복잡성을 관리할 수 있도록 함 : 사람은 보통 한번에 7+-2개만을 효과적으로 다룰 수 있다. 소프트웨어의 아키텍처를 정의할 수 있도록 함. 프로그래밍 언어 등 시스템구현 환경과 독립적으로 시스템을 모델링 할 수 있다. 예)3계층 소프트웨어 아키텍처에 따라 사용자 인터페이스는 비쥬얼 베이직 혹은 자바, 업무논리는 C++ 혹은 자바, 데이터베이스 서버는 C++과 SQL로 구현 재사용을 촉진시킨다. 즉, 재사용 가능한 시스템구성 컴포넌트를 모델링함으로써 이를 여러 시스템에서 사용할 수 있다.
4
2. UML(Unified Modeling Language)의 개요[2]
가시화 언어 개념 모델 작성 오류 없이 전달 의사 소통의 용이 Graphic 언어 구축 언어 다양한 Prog. 언어와 연결 왕복 공학 가능 (순 공학/역공 학) 실행 시스템 예측 가능 명세화 언어 정확한 모델 제시 완전한 모델 작성 분석,설계의 결정 표현 문서화 언어 시스템에 대한 통제, 평가, 의사소통의 문서 (요구사항, Architecture, 설계, Source Code, Project 계획,Test, Prototype, Release)
5
(Implementation View)
3. UML의 뷰(view) 설계 뷰 (Design View) 구현 뷰 (Implementation View) 프로세스 뷰 (Process View) 배치 뷰 (Deployment View) 쓰임새 뷰 (Use Case View) 시스템 조립 형상관리 시스템 구성 형태 분산, 인도, 설치 어휘 기능성 성능 확장성 처리량
6
3. UML의 뷰(view) - 2 아키텍쳐 종류 내 용 정적 도해 동적 도해 쓰임새 뷰 시스템 행동을 설명
(Use Case View) 시스템 행동을 설명 최종사용자, 분석가, 설계자, 테스트 담당자에게 제공 되는 뷰 시스템 아키텍쳐를 구체화하는 요인들을 명세화 쓰임새도 교류도 상태도 활동도 설계 뷰 (Design View) 시스템이 최종사용자에게 제공해야 할 서비스를 표현 문제 영역과 해법의 어휘를 형성하고 있는 Class, Interface, Collaboration으로 구성 클래스도 객체도 프로세스 뷰 (Process View) 시스템의 성능, 신축성, 처리 능력을 표현 시스템의 동시성과 동기화 메커니즘을 형설하고 있는 Thread와 Process로 구성 활성 클래스도 구현 뷰 (Implementation View) 시스템 배포의 형상관리 표현 물리적인 시스템을 조립하고 배포하는데 사용되는 Component와 File 들로 구성 컴포넌트도 배치 뷰 (Deployment View) 시스템을 구성하는 물리적 부분의 분산, 인도, 설치 표현 H/W 형태를 형성하는 Node로 구성 배치도
7
3. UML의 뷰(view) - 3 UML의 뷰 1) 사용사례 뷰 2) 논리적 뷰 3) 컴포넌트 뷰 4) 전개 뷰
-외부활동자(actor)에 의해서 인지된 시스템이 제공해야 하는 기능들을 묘사 -actor는 시스템과 상호작용하는 사용자 or 다른 시스템이 될 수 있음 -고객, 설계자, 개발자, 시험자에 의해 사용될 수 있음 -사용사례 뷰는 다른 뷰의 개발을 유도한다는 점에서 중요함 -시스템개발의 최종목적이 사용사례 뷰에서 제시된 기능을 제공하는 것이라고 할 수 있음 2) 논리적 뷰 -시스템의 기능들이 어떻게 제공되는지를 묘사 -설계자, 개발자에 의해 주로 이용됨 -시스템 내부를 들여다보는 것으로 정적구조(클래스, 객체, 관계) 및 객체간의 메시지 교환을 보여주는 동적인 협력도 묘사한다. -정적구조: 클래스 및 객체 다이어그램 -동적협력구조: 상태, 연속, 협력, 활동 다이어그램 3) 컴포넌트 뷰 -구현 모듈과 모듈간의 의존성을 묘사 -주로 개발자에 의해서 사용됨 4) 전개 뷰 -컴퓨터와 주변장치, 이들이 어떻게 연결되어 있는지를 묘사 -개발자, 시스템 통합자, 시험자에 의해서 사용됨
8
4. UML의 구성요소 : 사물(thing), 관계(relationship), 도해(diagrams)
9
4. UML의 구성요소[1] : 사물(thing)
1) 구조사물(structural things): 보통 명사형 표현됨. 모델의 정적인 부분을 표현. -클래스: 동일한 속성, 오퍼레이션, 관계, 그리고 의미를 공유하는 객체들을 기술 -인터페이스: 클래스 또는 컴포넌트의 서비스를 명세화하는 오퍼레이션들의 집합 -쓰임새(use case): 시스템이 수행하는 순차적 활동들을 기술하며, 행위자(actor)와 반응함 -컴포넌트 -노드 2) 행동사물(behavioral things): UML모델의 동적인 부분을 표현. 시간과 공간에 따른 행동을 표현. -교류(interaction) -상태머신: 상태의 순서를 지정하는 행동. 3) 그룹사물(groupings things): UML모델을 조직하는 부분 -패키지 4) 주해사물(annotational things): UML모델을 설명하는 부분. 모델의 어떠한 요소들에 대하여 설명하고, 명확하게 하는 것. -노트
10
4. UML의 구성요소[2] : 관계(relationship)
혼자서 존재하는 클래스는 거의 없으며, 다양한 방식으로 다른 사물과 교류함 클래스를 파악하고 나면, 클래스들간의 관계에 주목해야 함 4가지 관계 : 의존, 연관, 일반화, 실체화 1) 의존(dependency): 한쪽 사물의 변화가 다른 사물에 영향을 주는 관계 B의 변화가 A에 영향을 미치는 경우 2) 일반화(generalization): 특수화(specialization)/일반화(generalization)관계 보다 일반적인 클래스와 이 클래스와 완전한 일관성을 가지며 추가적인 정보를 제공하는 보다 상세한 클래스간의 분류학적 관계 A B 운송수단 자동차 보트 스포츠카 승용차 트 럭 모터보트 요트
11
3) 연관(association): 객체들간의 링크(연결)가 있음 을 표현
어느 한 사물 객체가 다른 사물 객체와 연결되어 있음 집합연관(aggregation)관계 : 전체/부분 관계. 부분에 대한 참조 전체와 부분은 서로 독립적으로 창조되고 파괴됨 has, is_part_of, consists_of, composed_of 예) 자동차는 네 바퀴, 엔진, 차체 등으로 구성되어 있다. 복합연관(composition)관계 : 전체/부분 관계. 부분의 값을 포함 부분의 창조와 파괴는 전체의 결과로서 일어남(동일한 수명을 가짐) 예) 어느 특정 윈도우가 두 개의 스크롤 바, 제목, 그리고 본체로 구성되어 있다면, 윈도우가 없어지면 이들 구성요소들도 없어지게 될 것이다. 사람 회사 일한다 팀 사람 구성원 1 0..* 윈도우 스크롤바 제목 본체
12
4) 실체화(realization): 한쪽 분류자는 다른 쪽 분류자가 수행하기로 되어 있는 계약을 명세화
13
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)
14
(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는 내부의 구현을 생각하지 않는다.
15
(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로 구성한다.
16
(1) Use Case Diagram의 예 - 3 신용카드 인증 시스템 Actor의 추출
신용카드를 사용하는 개인 고객, 단체고객 신용카드로 거래를 하는 소매기관 고객의 신용 상태를 처리하는 기관 Use Case의 추출 고객이 신용카드를 사용하여 카드 거래를 한다. 거래에 대한 대금을 처리한다. 고객개인의 계좌를 관리한다.
17
다이어그램 시나리오 작성 고객은 신용카드를 취급하는 소매점에 가서 카드를 가지고 거래를 한다. 소매점에서는 카드를 가지고 고객의 신용상태를 점검한 후 거래에 해당하는 금액을 처리한다. 소매점에서 카드에 해당하는 고개의 신용을 조회하면 금융기관에서 개인의 구좌를 확인하여 신용상태를 알려준다.
18
객제지향의 개념 객체 메시지 클래스 캡슐화 상속 재사용
-현실세계의 현상을 이해하고 설명하기 위해서 복잡한 현실세계를 우리의 목적이나 관심에 따라 단순화시킴 -즉, 우리가 관심을 갖고 있는 세계의 범위를 정하고 그 세계를 구성하는 개체(or 개념)를 정의하고 개체와 개체간의 관계를 파악 -현실세계를 구성하는 개체 혹은 개념을 우리의 목적이나 관점에 따라서 추상화시킨 것이 객체임 -객체는 유일한 ID(identity), 속성, 객체의 행동방법을 나타내는 메소드로 구성됨 메시지 -객체간에 서로 메시지를 교환함으로써 상호작용함 클래스 -동일한 유형의 객체들의 집합. 클래스 정의를 통하여 클래스내 모든 객체에 동일하게 적용되는 메소드와 속성변수들이 정의됨 -클래스를 통하여 생성된 객체를 그 클래스의 인스턴스(instance)라고 함. 캡슐화 -정보은닉 상속 -하위클래스는 상위클래스로부터 메소드와 변수를 상속받을 수 있음 재사용 -상속을 통하여 하위클래스는 상위클래스의 메소드를 상속받아 재사용하게 됨.
19
(2) 클래스 다이어그램 클래스 개별적인 객체라기보다는 동일한 속성, 오퍼레이션, 관계, 그리고 의미를 공유하는 객체 집합
시스템의 어휘 모델링 예) 소매유통 시스템에서 뽑아낸 클래스 : 고객, 주문, 제품, 송장, 거래 …. 이름 고객 이름 주소 전화 생년월일 주문 거래 속성 항목 수량 actions 제품인도() 반환() 오퍼레이션
20
(2) 클래스 다이어그램-2 가시성(visibility) 다중성(multiplicity) 사람 회사 1..* * 종업원 고용주
속성이나 오퍼레이션을 다른 분류자에 의해 사용될 수 있는지 여부를 지정하는 것 공용(public): 모든 외부 분류자들이 사용할 수 있음. “+” 보호(protected): 이 분류자의 모든 자식들이 사용할 수 있음. “#” 전용(private): 이 분류자 자신만이 사용할 수 있음. “-” * 분류자: 구조적, 행동적 특성을 설명하기 위한 메커니즘. Ex)클래스, 컴포넌트, 노드, 쓰임새 등 다중성(multiplicity) 하나의 클래스가 가질 수 있는 인스턴스 수 특정 실체에 잠정적으로 허용 가능한 관계수의 범위 사람 회사 1..* * 종업원 고용주
21
모델에 정보를 덧붙이기 위하여 사용됨. Ex)요구사항, 관찰기록, 검토의견 등
공통 메카니즘 명세서(specification) - UML의 Graphic 표현에 구문법과 구성 요소의 의미를 포함하여 점진적으로 모델을 구성 장식(adornment) - UML 요소의 고유하고 직접적인 Graphic 표기 등 요소의 가장 중요한 관점을 가시적으로 표현 노트(note): 그래픽 심볼로서 한 요소나 요소들에 연결된 제약과 주석을 표현 모델에 정보를 덧붙이기 위하여 사용됨. Ex)요구사항, 관찰기록, 검토의견 등 확장(extensibility) - UML의 목적인 분석/설계 정보를 보다 정확하게 전달하기 위한 표준 언어를 제공 - 하나의 언어로 불가능한 모형은 통제된 방법으로 언어를 확장 스테레오타입: UML의 어휘를 확장시켜 새로운 구성요소를 만들어 낼 수 있음 예시: <<subsystem>> 꼬리표값: UML구성요소의 프로퍼티를 확장 예시: {version = 3.2} 제약: UML의 구성요소의 의미를 확장시켜 새로운 규칙을 추가하거나 기존의 것을 수정 예시: {>10 이하} EventQueue {version = 3.2 author = YL} add ( ) remove ( ) flush ( ) “exception” Overflow {ordered} Tagged Value Constraint Stereotype
22
(3) 객체 다이어그램 객체는 클래스로부터 생성되는 한 인스턴스 클래스와 동일한 관계를 갖는다.
다음 예와 같이 객체이름:클래스이름 또는 객체이름이 생략되기도 함. 홍길동 : 사람 : 승용차 이름 : 홍길동 생년월일 : 이름 : SM5 배기량 : 2000
23
(4) 패키지 다이어그램 패키지(packages) 요소들을 그룹으로 조직하기 위한 범용 메커니즘
수입(import)과 수출(export) 한 패키지가 수출하는 부분은 그 패키지를 명시적으로 수입하는 패키지의 내용물들에만 보인다. 보기에서 policies는 명시적으로 GUI패키지를 수입하고 있다. 따라서 policies패키지의 내용물들은 GUI::window와 GUI::Form을 볼 수 있다. 그러나 GUI::EventHander는 보호되어 있으므로 볼 수 없다. Server패키지는 GUI를 수입하지 않으므로 어떤 내용물에도 접근할 수 없다. Client + OrderForm + TrackingForm - Order Server + Database + LoggingService policies + OrderRules - GUI::Windows <<import>> GUI + Window + Form # EventHandler <<import>>
24
(4) 패키지 다이어그램 - 2 패키지의 일반화 관계 GUI + Window + Form # EventHandler
WindowsGUI + GUI::Window + Form # GUI::EventHandler + VBFom MacGUI
25
(5) 교류 다이어그램 (1) 순차 다이어그램 객체들이 어떻게 상호작용 하는지를 메시지 순서에 초점을 맞추어 보여
주는 다이어그램 세로축: 아래 방향으로의 시간의 흐름을 의미, 가로축: 일련의 객체로 구성 (2) 협력 다이어그램 교류에 참여하는 객체의 구조를 강조. 객체 역할간의 관계를 보여줌 상호작용이 일어나는 객체와 그들간의 연결을 중심으로 상호작용 표현
26
(6) 상태 다이어그램 한 객체의 생명주기 동안의 일련의 상태(변화)를 보여주는 다이어그램
즉, 객체의 가능한 상태와 이벤트 발생에 의해 이들 상태가 시간에 걸쳐 어떻게 영향을 받는지를 보여줌 모든 객체는 상태를 가지며, 외부자극(이벤트)에 의하여 변함 ex) 자동차(객체)가 서 있다(상태). 자동차(객체)가 달리고 있다(상태). 상태이름 상태변수 활동 Entry Do Exit 이벤트[조건]/행동
27
(7) 활동 다이어그램 상태도의 특수형태. 순서도의 개념
Similar presentations