Transcript 슬라이드 1
UML 이 남경 1 목차 1. UML이 필요한 이유 소프트웨어 개발 시 발생하는 문제들 모델 & 모델링 소프트웨어 모델링 2. UML UML의 정의 및 특징 UML의 구성 1. 2. 3. Things Relationships Diagram 참고 2 1. UML이 필요한 이유 3 1. 소프트웨어 개발 시 발생하는 문제들 - 모호한 사용자 요구사항 - 요구사항의 변화 - 적용기술의 변화 - 불명확한 개발절차나 성과물 -프로젝트의 진척 사항 파악의 어려움 4 개발자의 제안을 참고로 needs를 명확히 하고 싶은데.. 개발자가 needs를 제대로 이해했는지 모 르겠다. 유저의 needs가 명확하지 않다. 유저의 의견을 듣고 조금 더 도움이 되는 시스템으로 만들고 싶은데… 5 2. 모델 & 모델링 • 모델 • 현실을 단순화 / 가시화 시킨 것 • 시스템의 청사진을 제공 모델링 • 모델을 만드는 일 • 품질 좋은 소프트웨어를 개발 및 배치할 수 있게 하는 활동 모델링의 목적 • 이해당사자들 사이의 원활한 의사소통 • 시스템을 원하는 모습으로 가시화 • 구조와 행동을 명세화 • 분석/설계의 문서화 6 3. 소프트웨어 모델링 소프트웨어 모델 • 실제 개발할 소프트웨어 시스템을 단순화해 체계적으로 정의한 논리적 모델 소프트웨어를 바라보는 여러 관점들 - 요구 모델(requirement model) : 최종 사용자의 경우 분석 모델(analysis model) : 시스템 분석가 구현 모델(implementation) : 프로그래머 테스트 모델(test model) : 시스템 테스터 필요에 의해 여러 가지의 관점이 필요하며 이에 따라 여러 소프트웨어 모델이 개발되어야 할 수도 있다. 시험해 볼 구체적인 것이 있고, 그것을 코드로 시험해 보는 것 보다는 소프트웨어 모델을 사용해 시험하는 것이 비용이 덜 든다. 7 2. UML 8 1 . UML 정의 및 특징 정의 - UML은 하나의 모델링 언어( Modeling Language ) - 소프트웨어 개념을 다이어그램으로 그리기 위해 사용하는 시각적인 표기법 - 전 세계의 표준(OMG ) 표기법 : 전세계의 누구나 쉽게 이해 - 시스템을 바라보는 다양한 시각을 표현 목적 객체 지향 시스템을 가시화, 명세화, 문서화 하는 것 9 특징 1. 핵심적인 개념을 확장할 수 있는 확장성과 특수화 방법을 제공 2. 특정 개발 프로세스와 언어에 종속되지 않는다 3. 모델링 언어를 이해하기 위한 공식적인 기초를 제공 4. 객체 지향 툴 시장의 성장을 장려 10 UML 가시화 UML 시 스 템 모 델 링 표 준 언 어 명세화 SYSTEM 구축 문서화 11 예) 다이어그램을 그려야 하는 경우 · 여러 사람이 동시에 작업을 하며 설계에서 특정 부분의 구조를 이해해야 할 때 · 어떤 설계 아이디어로 이것 저것 시도해 보고 싶을 때 · 누군가에게 코드 일부분의 구조를 설명할 때 12 2. UML의 구성 구성요소 Things Structural Thing Relationships Diagrams Dependency Class Diagram Behavioral Thing Association Object Diagram Grouping Thing Generalization Use Case Diagram Annotation Thing Realization Sequence Diagram Collaboration Diagram State Chart Diagram Activity Diagram Component Diagram Deployment Diagram 13 2 - 1 . THINGS 2 – 1 - 1 . Structure things • UML 모형의 명사형 • 모형의 정적인 부분이며 개념적이거나 물리적인 요소표현 14 Structure요소 - 클래스 : 동일한 속성, 연산, 관계, 의미를 공유하는 객체를 표현 Window 클래스 명 ORIGINE SIZE 속성 Open() Close() Display() 오퍼레이션 15 - 인터페이스 : 객체가 가지고 있어야 하는 기능만 명시 <<interface>> iActivityPaln iActivityPlan ( icon 형태 ) 스테레오타입으로 표현 - Collaboration : .서로 다른 요소와 역할들의 집합을 표현 시스템을 구성하는 Pattern을 표현 - Class의 행동적이고 구조적인 중요성을 도식 - Active Class : 객체가 하나 이상의 process를 갖는 클래스 EventManager suspend() flush() 16 - Use Case : 시스템이 제공하는 서비스 혹은 기능 - Component : 클래스, 인터페이스, collaboration 등 서로 다른 논리 요소를 물리적으로 Package 화 한 것 종류 : Application, Document, File, Library , Page , Table … student.java - Node : 실행 시에 존재하는 물리적 요소, 약간의 메모리와 처리능력을 갖는다. server 17 2 – 1 – 2 .Behavioral Things UML의 동사형. 시간과 공간에 따른 행동 요소 표현 종류 - Interaction : 행위. 객체들 사시에 주고 받는 메시지들로 구성 Display - State Machine : 객체의 상태를 순서대로 명시 Waiting 18 2 – 1 - 3 .Grouping Things 모델을 그룹화해 요소 표현 Package( 그룹 띵의 종류 ) - UML 요소들을 Group으로 묶음 - 개발 시에만 존재하는 개념적인 모형 ( Component 와는 다르며 FrameWork, 서브시스템 을 표현 ) Business Rules 19 2 – 1 - 4 .Annotation Things UML 모델을 설명하는 부분이며, 모델 요소를 설명하고, 명확히 표현 노트(Note) - 하나의 요소 또는 요소들로 구성된 공동체에 첨부되는 제약과 주석을 표현하는 기호이다. - 모서리가 접힌 직사각형으로 표현 20 2 - 2. Relationship 구성요소들간의 의미 있는 연관성을 표현 :: 일반적으로 클래스들간의 관계 표현 시 사용된다. 21 종류 - 의존 관계 (Dependency Relationship) - 한 클래스가 다른 클래스를 사용하는 관계 주문 - 상품 하나의 클래스가 다른 클래스에 영향을 준다. - 연관 관계 (Association Relationship) - 클래스로부터 생성된 객체간 일반적 협력 관계 가르친다 선생님 1 학생 * 22 - 일반화 관계 (Generalization Relationship) 일반화된 개념적 사물과 구체화된 특수 사물의 관계 표현 부모 자식 간 상속 개념 23 - 실체화 관계 (Realization Relationship) - 인터페이스와 실제 구현 관계 표현 - Use-Case에 정의된 기능을 구현하는 Collaboration에 연결시 사용 24 2 - 3. Diagram Object diagram Class diagram Use-Case diagram Sequence diagram Collaboration diagram State Chart diagram Activity diagram Component diagram Deployment diagram 25 Static Structure Diagrams 시스템의 정적인 관점 - 클래스, 인터페이스, 노드 등의 존재와 배열을 의미 시간의 흐름, 사용자의 행동으로 변하지 않는 시스템 골격이나 구조를 표현 DIAGRAM Class Diagram Object Diagram Component Diagram Deployment Diagram 26 Dynamic Behavior Diagrams 시스템의 동적인 관점 - 시간에 따른 메시지 흐름이나 네트워크를 통한 컴포넌트의 물리적 이동 등을 의미 시간 흐름이나 사용자 행동으로 발생하는 시스템의 변화에 대한 관점 표현 Diagram Use Case Diagram Sequence Diagram Collaboration Diagram State Chart Diagram Activity Diagram 27 Class diagram - 시스템의 논리적 구조(클래스)를 표현 -시스템이 처리 해야 하는 작업을 분할 한 것 - 관련된 클래스끼리 패키지화 한다. Window 클래스 명 ORIGINE SIZE 멤버변수 Open() Close() Display() 함수 Class 28 Class diagram 관계도 연관 클래스로부터 생성된 인스턴스들 간의 관계를 표현 일반화 클래스간 계승을 통한 개념의 일반 화 의존 하나가 다른 하나를 사용 사용되는 모델요소가 변경되면 사 용하는 모델요소가 영향을 받음 포함 연관의 특별한 경우로 한 클래스의 객체가 다른 클래스의 객체를 부분 으로서 포함하는 것. 이때 마름모의 색이 채워져 있으면 부품으로 그 속 한 클래스와 운명을 같이한다. 마름모가 비어있으면 다른 곳에서 받아온 것으로 속한 클래스가 죽어 도 계속 살 수 있다는 것을 의미한 다. 집합 29 1. 연관 BB AA AA는 BB를 알고 있지만 아직 BB는 AA에 대해 모른다. 2. 일반화 AA AA는 BB와 CC의 부모이고 BB와 CC는 AA를 상속 받았다는 의미 BB CC 30 3. 의존 AA BB 한 쪽 클래스가 실행 도중 다른 쪽 클래스의 실행을 요청하는 경우 4. 집합 컴퓨터 CPU는 컴퓨터와 운명을 같이한다. 하지만 모니터의 경우 다른 용도로 사용될 수 있다. CPU 모니터 31 Object diagram - 특정 시점의 시스템에 포함된 객체들의 모습을 기술 - 클래스가 아니라 클래스의 instance 들의 관계를 기술 - 객체의 구성이 복잡하게 얽혀 있는 경우 유용 - 각 특성이 가지는 현재 값들을 기술 - 객체이름 : 클래스 이름 또는 객체이름이 생략되기도 한다. :(한권의) 책 번호 = 001 대여일 = 10.06.05 소장하고있다 반납일 = 10.07.05 … : 도서명 제목 : ㅋㅋㅋ 저자 : 이남경 :(한권의) 책 번호 = 002 대여일 = 10.06.05 반납일 = 10.07.05 … 32 Use-Case diagram - 컴퓨터 시스템과 사용자가 상호작용 하는 것 - 사용사례와 사용자의 관계를 표현 - 주로 요구분석 단계에서 사용자의 요구를 기술하는데 사용 목적 - 사용자의 관점에서 시스템을 모델링 하기 위함 - 즉, 사용자가 시스템에 대하여 바라는 바를 표현 - 사용자의 시점을 빨리 이해함으로써 쓸모 있고(useful), 쓸 수 있는 (usable) 시스템을 만들 수 있도록 함. - 즉, 시스템의 기능에 대해 사용자와 communication 하는 것이다. 33 시스템과 상호작용하는 사람 또는 모든 것 Actor에게 서비스를 제공하는 시스템이 벌이는 일련의 행위 34 System name System • 특별한 의미를 가지진 않지만 전체 시스템의 구획을 표현 Association • Actor와 System 내부의 기능을 표현 35 Include • 기본 use case가 다른 use case를 수용하는 것을 의미 36 Extend • 기본 use case 수행 시 특별한 조건을 만족했을 때 수행되는 use case 예 ) 택배 - 세 시간 이하 배달은 퀵 서비스를 이용한다! 37 Generalization • 자식 element가 부모 element의 행동, 의미를 상속 38 [음료수 사기] 음료 자판기 시스템 음료수 사기 소비자 소비자 쓰임새 설명 : 자판기에서 음료수를 사는 경우이다. 가정 : 한번에 한명의 소비자만 사용한다. 시작 행위자 : 소비자 선행조건 : 목이 마르다 진행 단계 1. 동전 또는 지폐를 넣는다. 2. 컵이 내려오고, 음료가 채워진다. 종료조건 : 음료를 가졌다. 결과 받는 행위자 : 소비자 39 Sequence diagram -상호작용 다이어그램 - 객체와 객체 그룹사이, 객체와 객체사이, 객체그룹과 객체 그룹사이의 동적인 행위 기술 - 객체들간의 상호작용을 시간적 순서를 강조하여 표현 객체 시간은 위에서 아래로 표현 실행 생명선 40 보험 가입 다이어그램 41 Collaboration Diagram - sequence diagram 과 같이 객체들 사이의 행위를 나타내는 것 - 객체들 사이의 정적인 구조에 더 역점 - 객체 하나의 행위를 정확하게 표현하기에는 부적절 - 번호를 적어 메시지가 전달되는 순서를 나타냄 - 시간의 흐름은 표시되지 않음 42 43 Activity Diagram - Activity diagram은 순서에 따른 activity를 나타냄 - activity의 의미를 파악하는 것이 중요 -Activity는 인간이나 컴퓨터에 의해 수행이 필요한 어떠한 업무(task)를 의미 - 플로우 차트와 유사 44 시장간다 케익을 산다 샴페인을 산다 생일파티를 한다 45 Statechart Diagram • 클래스의 생명주기 표현 – Event : 다른 상태로의 전이를 일으키는 사건 – Action : 상태전이의 결과인 행동 • 객체의 상태 전이를 종합 • 사건과 상태의 변화를 표현 46 조건 47 Chess Game 시작! 흰색 움직임 하얀색 차례 검은색 차례 검정색 움직임 stalemate checkmate checkmate 검정 승 stalemate Draw 하얀색 승 48 Deployment Diagram • 시스템마다의 하드웨어, 소프트웨어 컴포넌트들의 관 계를 나타냄 • Node를 이용해 물리적 표현을 함 49 <<LAN>> Server1: httpserver PC 1 :hub M1 : MAILSERVER fw1: firewall 컴퓨터나 LAN 등이 어떤 물리적 관계로 접속되어지는가… 50 Component Diagram • 소프트웨어 컴포넌트간의 종속성 표현 • 시스템에 물리적 컴포넌트의 구성을 표현 • 실제로 어떻게 코드가 모듈로 나누어지는지 보여줌 – Execute File, Library, Database Table, File, Document • 구성 요소 - Component - Interface - Dependency 51 component - 물리적으로 시스템의 블록을 만드는 것 인터페이스 - 컴포넌트에 의해 만들어지고 사용되는 Operation 그룹 52 Dependency : SW component 사이의 의존 관계를 명시 53 참고 54 • Diagram을 만들 때 – Diagram 전부를 유지하는 것이 아니라 시스템이 만들어질 때 활용되고 용도 를 마치면 폐기 – 불 필요하거나 중복된 Diagram는 작성하지 않음 – 각 Diagram이 의도하는 문제를 다루기에 충분하도록 상세하게 표현 – 구조적 Diagram과 행동적 Diagram가 균형을 유지하도록 – 너무 크거나 적지 않은 범위에서 표현 – 각 Diagram에 의미 있는 명칭을 붙이고 의도를 명확하게 표현 – 형식에 집착하지 않고 작성 • 구조가 좋은 Diagram – 시스템에서 하나의 View를 전달하는데 초점을 맞춤 – 관점을 이해하는데 필수적인 요소만 표현 – 추상적 계층에 맞는 상세한 정보를 제공 – 중요한 의미를 사용자에게 정확히 전달될 정도로 복잡하게 구현 55 UML 규칙 이름 (Name) 사물, 관계, 도해의 호칭 범위 (Scope) 이름에 특정한 의미를 부여하는 문맥(Context) 가시성 (Visibility) 이름을 참조하고 사용할 수 있는 방법 무결성 (Integrity) 사물 상호간에 올바르고 일관성 있는 관계를 유지시키는 방법 실행 (Execution) 동적 Model을 실행하거나 모의 실험 하는 것 56 끝 57