UML 이 남경.

Presentation on theme: "UML 이 남경."— Presentation transcript:

1 UML 이 남경

2 목 차 UML이 필요한 이유 UML 소프트웨어 개발 시 발생하는 문제들 모델 & 모델링 소프트웨어 모델링
Things Relationships Diagram 참고

3 1. UML이 필요한 이유

4 1. 소프트웨어 개발 시 발생하는 문제들 - 모호한 사용자 요구사항 - 요구사항의 변화 - 적용기술의 변화
- 불명확한 개발절차나 성과물 프로젝트의 진척 사항 파악의 어려움 : 시스템을 원하는 사용자가 자신이 필요로 하는 기능, 동작, 사양 등에 관한 요구를 명확하게 언어로 표현할 수 없다. 또 사용자의 요구는 그 비즈니스에 관련된 시장 환경의 변화나 동향, 고객의 기호 변화에 따라 매우 극심하게 변화한다. 근래의 정보기술의 변화혁신 속도가 놀라울 정도로 빨르다. 기존에 사용되던 문서나 도면 등이 표준화 되어있지 않고 표준화 되어있어도 형식적이어서 잘 활용되지 않고 있다. 표준화의 기준도 조직이나 프로젝트마다 다르다. 그 결과, 플젝의 상황을 파악하려 해도 어느 정도 성공을 거둔 것인지, 문제나 리스크 요인이 어딨고 그것을 어케 해결할지 등을 정확하게 파악할 수가 없고 시간도 오래걸린다.

5 개발자의 제안을 참고로 needs를 명확히 하고 싶은데.. 개발자가 needs를 제대로 이해했는지 모르겠다. 유저의 needs가 명확하지 않다. 유저의 의견을 듣고 조금 더 도움이 되는 시스템으로 만들고 싶은데…

6 2. 모델 & 모델링 모델 현실을 단순화 / 가시화 시킨 것 시스템의 청사진을 제공 모델링 모델을 만드는 일
품질 좋은 소프트웨어를 개발 및 배치할 수 있게 하는 활동 모델링의 목적 이해당사자들 사이의 원활한 의사소통 시스템을 원하는 모습으로 가시화 구조와 행동을 명세화 분석/설계의 문서화

7 3. 소프트웨어 모델링 소프트웨어 모델 실제 개발할 소프트웨어 시스템을 단순화해 체계적으로 정의한 논리적 모델
소프트웨어를 바라보는 여러 관점들 - 요구 모델(requirement model) : 최종 사용자의 경우 - 분석 모델(analysis model) : 시스템 분석가 - 구현 모델(implementation) : 프로그래머 - 테스트 모델(test model) : 시스템 테스터 필요에 의해 여러 가지의 관점이 필요하며 이에 따라 여러 소프트웨어 모델이 개발되어야 할 수도 있다. 시험해 볼 구체적인 것이 있고, 그것을 코드로 시험해 보는 것 보다는 소프트웨어 모델을 사용해 시험하는 것이 비용이 덜 든다.

8 2. UML

9 1 . UML 정의 및 특징 정의 목적 - UML은 하나의 모델링 언어( Modeling Language )
- 소프트웨어 개념을 다이어그램으로 그리기 위해 사용하는 시각적인 표기법 전 세계의 표준(OMG ) 표기법 : 전세계의 누구나 쉽게 이해 - 시스템을 바라보는 다양한 시각을 표현 목적 객체 지향 시스템을 가시화, 명세화, 문서화 하는 것

10 특징 핵심적인 개념을 확장할 수 있는 확장성과 특수화 방법을 제공 특정 개발 프로세스와 언어에 종속되지 않는다
모델링 언어를 이해하기 위한 공식적인 기초를 제공 객체 지향 툴 시장의 성장을 장려

11 UML 가시화 시 스 템 모 델 링 표 준 언 어 명세화 SYSTEM UML 구 축 문서화
UML은 비주얼화(가시화)하는 언어이다. - UML은 여러 개의 그래픽 기호로 구성되어 있으며 각 기호들은 정확한 의미를 갖고 있다. 그러므로, UML로 모델링한 것은 통일된 의미를 갖기에 개발팀원들이 시스템에 대해 동일한 생각을 갖게 되며, 동일한 의미를 공유할 수 있게 된다. UML은 명세화하는 언어이다. - 명세화란 정확하고, 명백하며, 완전한 모델을 의미한다. UML은 분석, 설계 구현에서의 모든 중요한 결정에 대한 명세서를 다룰 수 있게 하며 이러한 결정들은 소프트웨어 시스템을 개발하고 배치할 때 정해야 하는 것들이다. UML은 문서화하는 언어이다. - UML은 시스템 아키텍쳐와 그것의 모든 상세 내역에 대한 문서화 를 다루며, 요구사항을 표현하고 시스템을 시험하는 언어도 제공한 다. UML은 구축하는 언어이다. - UML언어에서 프로그래밍코드를 생성하는 순공학이 가능하다. 또한, 구현된 코드로부터 UML모델을 다시 생성할 수 있는 역공학 도 가능하다. 구 축 문서화

12 예) 다이어그램을 그려야 하는 경우 · 여러 사람이 동시에 작업을 하며 설계에서 특정 부분의 구조를 이해해야 할 때 · 어떤 설계 아이디어로 이것 저것 시도해 보고 싶을 때 · 누군가에게 코드 일부분의 구조를 설명할 때

13 2. UML의 구성 구성요소 Structural Thing Behavioral Thing Grouping Thing
Annotation Thing Things Dependency Association Generalization Realization Relationships Class Diagram Object Diagram Use Case Diagram Sequence Diagram Collaboration Diagram State Chart Diagram Activity Diagram Component Diagram Deployment Diagram Diagrams 구성요소

14 2 - 1 . THINGS 2 – 1 - 1 . Structure things UML 모형의 명사형
모형의 정적인 부분이며 개념적이거나 물리적인 요소표현

15 Structure요소 - 클래스 : 동일한 속성, 연산, 관계, 의미를 공유하는 객체를 표현 Window 클래스 명
ORIGINE SIZE 속성 Open() Close() Display() 오퍼레이션

16 - 인터페이스 : 객체가 가지고 있어야 하는 기능만 명시
- Collaboration : .서로 다른 요소와 역할들의 집합을 표현 시스템을 구성하는 Pattern을 표현 - Class의 행동적이고 구조적인 중요성을 도식 - Active Class : 객체가 하나 이상의 process를 갖는 클래스 <<interface>> iActivityPaln iActivityPlan ( icon 형태 ) 스테레오타입으로 표현 EventManager suspend() flush()

17 - Use Case : 시스템이 제공하는 서비스 혹은 기능
- Component : 클래스, 인터페이스, collaboration 등 서로 다른 논리 요소를 물리적으로 Package 화 한 것 종류 : Application, Document, File, Library , Page , Table … - Node : 실행 시에 존재하는 물리적 요소, 약간의 메모리와 처리능력을 갖는다. student.java server

18 2 – 1 – 2 .Behavioral Things 종류 - Interaction : 행위.
UML의 동사형. 시간과 공간에 따른 행동 요소 표현 종류 - Interaction : 행위. 객체들 사시에 주고 받는 메시지들로 구성 - State Machine : 객체의 상태를 순서대로 명시 Display Waiting

19 2 – 1 - 3 .Grouping Things 모델을 그룹화해 요소 표현 Package( 그룹 띵의 종류 )
- UML 요소들을 Group으로 묶음 - 개발 시에만 존재하는 개념적인 모형 ( Component 와는 다르며 FrameWork, 서브시스템을 표현 ) Business Rules

20 2 – 1 - 4 .Annotation Things UML 모델을 설명하는 부분이며, 모델 요소를 설명하고, 명확히 표현
노트(Note) - 하나의 요소 또는 요소들로 구성된 공동체에 첨부되는 제약과 주석을 표현하는 기호이다. - 모서리가 접힌 직사각형으로 표현

21 2 - 2. Relationship 구성요소들간의 의미 있는 연관성을 표현
:: 일반적으로 클래스들간의 관계 표현 시 사용된다.

22 종류 - 의존 관계 (Dependency Relationship)
- 한 클래스가 다른 클래스를 사용하는 관계 하나의 클래스가 다른 클래스에 영향을 준다. - 연관 관계 (Association Relationship) - 클래스로부터 생성된 객체간 일반적 협력 관계 주문 상품 가르친다 선생님 학생 *

23 - 일반화 관계 (Generalization Relationship)
일반화된 개념적 사물과 구체화된 특수 사물의 관계 표현 부모 자식 간 상속 개념

24 - 실체화 관계 (Realization Relationship)
- 인터페이스와 실제 구현 관계 표현 - Use-Case에 정의된 기능을 구현하는 Collaboration에 연결시 사용

25 2 - 3. Diagram Object diagram Class diagram Use-Case diagram
Sequence diagram Collaboration diagram State Chart diagram Activity diagram Component diagram Deployment diagram

26 Static Structure Diagrams
시스템의 정적인 관점 - 클래스, 인터페이스, 노드 등의 존재와 배열을 의미 시간의 흐름, 사용자의 행동으로 변하지 않는 시스템 골격이나 구조를 표현 DIAGRAM Class Diagram Object Diagram Component Diagram Deployment Diagram

27 Dynamic Behavior Diagrams
시스템의 동적인 관점 - 시간에 따른 메시지 흐름이나 네트워크를 통한 컴포넌트의 물리적 이동 등을 의미 시간 흐름이나 사용자 행동으로 발생하는 시스템의 변화에 대한 관점 표현 Diagram Use Case Diagram Sequence Diagram Collaboration Diagram State Chart Diagram Activity Diagram

28 Class diagram - 시스템의 논리적 구조(클래스)를 표현 시스템이 처리 해야 하는 작업을 분할 한 것
관련된 클래스끼리 패키지화 한다. Window 클래스 명 ORIGINE SIZE 멤버변수 Open() Close() Display() 함수 Class

29 Class diagram 관계도 연관 클래스로부터 생성된 인스턴스들 간의 관계를 표현 일반화
클래스간 계승을 통한 개념의 일반화 의존 하나가 다른 하나를 사용 사용되는 모델요소가 변경되면 사용하는 모델요소가 영향을 받음 포함 연관의 특별한 경우로 한 클래스의 객체가 다른 클래스의 객체를 부분으로서 포함하는 것. 이때 마름모의 색이 채워져 있으면 부품으로 그 속한 클래스와 운명을 같이한다. 마름모가 비어있으면 다른 곳에서 받아온 것으로 속한 클래스가 죽어도 계속 살 수 있다는 것을 의미한다. 집합

30 1. 연관 2. 일반화 BB AA는 BB를 알고 있지만 아직 BB는 AA에 대해 모른다. AA AA는 BB와 CC의 부모이고
BB와 CC는 AA를 상속 받았다는 의미 BB CC

31 3. 의존 4. 집합 한 쪽 클래스가 실행 도중 다른 쪽 클래스의 실행을 요청하는 경우 AA
한 쪽 클래스가 실행 도중 다른 쪽 클래스의 실행을 요청하는 경우 AA BB 4. 집합 컴퓨터 CPU는 컴퓨터와 운명을 같이한다. 하지만 모니터의 경우 다른 용도로 사용될 수 있다. 컴퓨터를 사용할 땐 cpu와 모니터 모두 사용하지만 내가 ps2를 하기 위해 모니터를 연결하면 컴퓨터는 사용되지 않게 되는 것! CPU 모니터

32 Object diagram 특정 시점의 시스템에 포함된 객체들의 모습을 기술
클래스가 아니라 클래스의 instance 들의 관계를 기술 객체의 구성이 복잡하게 얽혀 있는 경우 유용 각 특성이 가지는 현재 값들을 기술 객체이름 : 클래스 이름 또는 객체이름이 생략되기도 한다. :(한권의) 책 : 도서명 번호 = 001 대여일 = 반납일 = … 소장하고있다 제목 : ㅋㅋㅋ 저자 : 이남경 :(한권의) 책 번호 = 002 대여일 = 반납일 = …

33 Use-Case diagram 목적 컴퓨터 시스템과 사용자가 상호작용 하는 것 사용사례와 사용자의 관계를 표현
- 주로 요구분석 단계에서 사용자의 요구를 기술하는데 사용 목적 - 사용자의 관점에서 시스템을 모델링 하기 위함 - 즉, 사용자가 시스템에 대하여 바라는 바를 표현 - 사용자의 시점을 빨리 이해함으로써 쓸모 있고(useful), 쓸 수 있는(usable) 시스템을 만들 수 있도록 함. - 즉, 시스템의 기능에 대해 사용자와 communication 하는 것이다.

34 시스템과 상호작용하는 사람 또는 모든 것 Actor에게 서비스를 제공하는 시스템이 벌이는 일련의 행위

35 특별한 의미를 가지진 않지만 전체 시스템의 구획을 표현
System name System 특별한 의미를 가지진 않지만 전체 시스템의 구획을 표현 Association Actor와 System 내부의 기능을 표현

36 Include 기본 use case가 다른 use case를 수용하는 것을 의미

37 Extend 기본 use case 수행 시 특별한 조건을 만족했을 때 수행되는 use case 예 ) 택배 - 세 시간 이하 배달은 퀵 서비스를 이용한다!

38 Generalization 자식 element가 부모 element의 행동, 의미를 상속

39 [음료수 사기] 음료 자판기 시스템 음료수 사기 소비자 쓰임새 설명 : 자판기에서 음료수를 사는 경우이다.
쓰임새 설명 : 자판기에서 음료수를 사는 경우이다. 가정 : 한번에 한명의 소비자만 사용한다. 시작 행위자 : 소비자 선행조건 : 목이 마르다 진행 단계 동전 또는 지폐를 넣는다. 컵이 내려오고, 음료가 채워진다. 종료조건 : 음료를 가졌다. 결과 받는 행위자 : 소비자 [음료수 사기] 음료수 사기 음료 자판기 시스템 소비자

40 Sequence diagram 상호작용 다이어그램 객체와 객체 그룹사이, 객체와 객체사이, 객체그룹과 객체 그룹사이의
동적인 행위 기술 - 객체들간의 상호작용을 시간적 순서를 강조하여 표현 객체 실행 생명선 시간은 위에서 아래로 표현

41 보험 가입 다이어그램

42 Collaboration Diagram
- sequence diagram 과 같이 객체들 사이의 행위를 나타내는 것 - 객체들 사이의 정적인 구조에 더 역점 - 객체 하나의 행위를 정확하게 표현하기에는 부적절 - 번호를 적어 메시지가 전달되는 순서를 나타냄 - 시간의 흐름은 표시되지 않음

43

44 Activity Diagram - Activity diagram은 순서에 따른 activity를 나타냄
Activity는 인간이나 컴퓨터에 의해 수행이 필요한 어떠한 업무(task)를 의미 플로우 차트와 유사

45 시장간다 케익을 산다 샴페인을 산다 생일파티를 한다

46 Statechart Diagram • 클래스의 생명주기 표현 – Event : 다른 상태로의 전이를 일으키는 사건
– Action : 상태전이의 결과인 행동 • 객체의 상태 전이를 종합 • 사건과 상태의 변화를 표현

47 조건

48 Chess Game 시작! 흰색 움직임 하얀색 차례 검은색 차례 검정색 움직임 stalemate stalemate checkmate checkmate Draw 검정 승 하얀색 승

49 Deployment Diagram 시스템마다의 하드웨어, 소프트웨어 컴포넌트들의 관계를 나타냄
Node를 이용해 물리적 표현을 함

50 PC 1 :hub fw1: firewall 컴퓨터나 LAN 등이 어떤 물리적 관계로 접속되어지는가… Server1:
httpserver PC 1 :hub fw1: firewall M1 : MAILSERVER 컴퓨터나 LAN 등이 어떤 물리적 관계로 접속되어지는가…

51 Component Diagram • 소프트웨어 컴포넌트간의 종속성 표현 • 시스템에 물리적 컴포넌트의 구성을 표현
• 실제로 어떻게 코드가 모듈로 나누어지는지 보여줌 – Execute File, Library, Database Table, File, Document • 구성 요소 - Component - Interface - Dependency

52 component - 물리적으로 시스템의 블록을 만드는 것 인터페이스 - 컴포넌트에 의해 만들어지고 사용되는 Operation 그룹

53 Dependency : SW component 사이의 의존 관계를 명시

54 참 고

55 Diagram을 만들 때 구조가 좋은 Diagram
너무 크거나 적지 않은 범위에서 표현 각 Diagram에 의미 있는 명칭을 붙이고 의도를 명확하게 표현 형식에 집착하지 않고 작성 구조가 좋은 Diagram 시스템에서 하나의 View를 전달하는데 초점을 맞춤 관점을 이해하는데 필수적인 요소만 표현 추상적 계층에 맞는 상세한 정보를 제공 중요한 의미를 사용자에게 정확히 전달될 정도로 복잡하게 구현

56 UML 규칙 이름 (Name) 사물, 관계, 도해의 호칭 범위 (Scope)
이름에 특정한 의미를 부여하는 문맥(Context) 가시성 (Visibility) 이름을 참조하고 사용할 수 있는 방법 무결성 (Integrity) 사물 상호간에 올바르고 일관성 있는 관계를 유지시키는 방법 실행 (Execution) 동적 Model을 실행하거나 모의 실험 하는 것

57 끝