소프트웨어공학 UML 2017. 1학기
UML 다이어그램 다이어그램 이름 개략적인 모양 설 명 Use Case Diagram Class Diagram 3장 요구 분석 UML 다이어그램 다이어그램 이름 개략적인 모양 설 명 Use Case Diagram 특정 시스템 혹은 개체 내에서 기능을 표현하는 usecase들과 그 외부의 actor들 간의 관계(상호작용)를 표현한 다이어그램 Class Diagram Class 관련 요소들의 여러 가지 정적인 관계를 시각적으로 표현한 다이어그램 Package Diagram 관련된 클래스를 패키지로 grouping 하여 의존도를 낮추기 위하여 사용 객체지향 소프트웨어 공학, SciTech
UML 다이어그램 다이어그램 이름 개략적인 모양 설 명 Sequence Diagram Collaboration Diagram 3장 요구 분석 UML 다이어그램 다이어그램 이름 개략적인 모양 설 명 Sequence Diagram Instance 들이 어떻게 상호작용을 하는지를 묘사하는 다이어그램 Collaboration Diagram 순차 다이어그램과 같은 내용을 나타내지만 모양이 네트워크 형태임 State(Chart) Diagram 특정 개체의 동적인 행위를 상태와 그것들간의 transition을 통해 묘사하는 다이어그램 (일반적으로 클래스의 인스턴스에 대한 행위 묘사 객체지향 소프트웨어 공학, SciTech
UML 다이어그램 다이어그램 이름 개략적인 모양 설 명 Activity Diagram Component Diagram 3장 요구 분석 UML 다이어그램 다이어그램 이름 개략적인 모양 설 명 Activity Diagram State Diagram의 특별한 형태이며, 활동들의 수행 흐름을 묘사하는 다이어그램 (Flow Chart와 유사) 시스템의 동적 특징을 나타냄 Component Diagram Software component 사이의 의존관계를 묘사하는 다이어그램 Deployment Diagram 물리적인 컴퓨터 및 장비 등의 하드웨어 요소들과 그것에 배치되는 소프트웨어 컴포넌트, 프로세스 및 객체들의 형상을 묘사하는 다이어그램 객체지향 소프트웨어 공학, SciTech
작성 과정 Usecase diagram 작성 Domain model diagram 작성 주요 개체 entity 추출 => entity class로 승화 Entity class급의 class diagram 작성 Sequence diagram 작성 1차 작성된 class의 refinement 추가로 class 생성 (boundary 또는 control 급의 class가 이에 해당될 수 있음) Activity diagram 시스템과의 상호작용의 modelling 객체간 operation들(activty)의 복잡한 상호 관계 표현 특히 병렬 수행
StarUML 연습: Use Case Diagram [ATM System]
Use Case 일반적으로 Use Case는 작업의 시작부터 끝까지 전반적인 단계를 포괄해야 함 3장 요구 분석 Use Case 일반적으로 Use Case는 작업의 시작부터 끝까지 전반적인 단계를 포괄해야 함 사용자가 시스템과의 상호작용을 나타냄 시스템이 실행하는 계산이 아님 Use Case 는 특정 사용자 Interface 설계와 독립 적으로 작성되어야 함 Actor가 컴퓨터와 상호작용 하는 action만을 포함 하여야 함 Object지향 소프트웨어 공학, SciTech
시나리오 시나리오는 Use Case의 instance Use Case가 다음의 구체적인 조건에 일어난 것 특정 Actor 3장 요구 분석 시나리오 시나리오는 Use Case의 instance Use Case가 다음의 구체적인 조건에 일어난 것 특정 Actor 특정 시간 특정 데이터 Object지향 소프트웨어 공학, SciTech
Use Case를 표시하는 방법 이름 Actor 목적 시작조건 설명 관련 Use Case 단계적 사건의 흐름 종료 조건 3장 요구 분석 Use Case를 표시하는 방법 이름 Use Case에 대한 간단한 이름 Actor Use Case를 이용하는 사용자나 외부 시스템 목적 Actor가 무엇을 성취하려는가를 설명 시작조건 Use Case를 구동시키기 위하여 만족되어야 할 조건 설명 간단한 비정형적 설명 관련 Use Case 단계적 사건의 흐름 Actor의 action과 시스템의 반응은 2 컬럼으로 표현 종료 조건 종료된 후 시스템의 상태 Object지향 소프트웨어 공학, SciTech
3장 요구 분석 Use Case diagram Object지향 소프트웨어 공학, SciTech
확장(extension) 선택적인 interaction을 명시적으로 나타낼 때 또는 예외 적인 사례를 다룰 때 사용 3장 요구 분석 확장(extension) 선택적인 interaction을 명시적으로 나타낼 때 또는 예외 적인 사례를 다룰 때 사용 Use Case 확장을 분리함으로써 기본적인 Use Case의 표 현이 간단해 진다. Use Case 확장도 Use Case의 처음부터 끝까지 모든 단계 를 나열하여야 함 특수한 경우의 처리도 포함 Object지향 소프트웨어 공학, SciTech
일반화(generalization) Class diagram에서 super Class와 유사 3장 요구 분석 일반화(generalization) Class diagram에서 super Class와 유사 일반화된 Use Case는 여러 유사 Use Case를 표현 상세화 된 여러 Use Case가 유사 Use Case의 상 세한 내용을 제공 Object지향 소프트웨어 공학, SciTech
포함(inclusion) 여러 Use Case들 사이에 공통적인 부분을 표현 다른 Use Case들 안에 3장 요구 분석 포함(inclusion) 여러 Use Case들 사이에 공통적인 부분을 표현 다른 Use Case들 안에 일련의 action을 공유 다수의 Use Case 사이에 중복을 피함 하위 수준의 작업의 수행을 하위 수준의 목표로 표 현 Object지향 소프트웨어 공학, SciTech
3장 요구 분석 Use Case diagram 예 Object지향 소프트웨어 공학, SciTech
Use Case 작성 예… Use Case: 파일 불러오기 관련 Use Case: 다음 두 Use Case를 일반화 한 것임 3장 요구 분석 Use Case 작성 예… Use Case: 파일 불러오기 관련 Use Case: 다음 두 Use Case를 일반화 한 것임 파일 이름을 주고 불러오기 브라우징으로 불러오기 작업순서: Actor측 action 시스템측 반응 1. ‘불러오기....’ 명령을 선택 2. ‘파일 불러오기’ 다이얼로그를 창을 디스플레이 3. 파일 이름을 명시 4. 선택을 확인 5. 디스플레이에서 다이얼로그 창을 삭제 Object지향 소프트웨어 공학, SciTech
Use Case 작성 예… Use Case : 파일 이름을 주고 불러오기 관련 Use Case: 파일 불러오기의 상세화 3장 요구 분석 Use Case 작성 예… Use Case : 파일 이름을 주고 불러오기 관련 Use Case: 파일 불러오기의 상세화 사건의 흐름: Actor측 action 시스템측 반응 1. ‘불러오기....’ 명령을 선택 2. ‘파일 불러오기’ 다이얼로그 창을 3a. 텍스트 필드를 선택 디스플레이 3b. 파일 이름을 입력 4. ‘불러오기’를 클릭 5. 디스플레이에서 다이얼로그를 삭제 Object지향 소프트웨어 공학, SciTech
Use Case Diagram
Use Case Diagram
Use Case Diagram
Use Case Diagram
Use Case Diagram
Use Case Diagram
StarUML 연습: Class Diagram
Class diagram의 기초 Class diagram에 사용하는 기본 symbol Class 연관관계 Attribute 3장 요구 분석 Class diagram의 기초 Class diagram에 사용하는 기본 symbol Class 자료 type 그 자체를 나타냄 연관관계 Class instance 사이의 관계를 나타냄 Attribute Class와 그 instance 안에서 발견될 단순 자료 Operation Class와 그 instance에 의하여 수행될 함수를 나타냄 일반화 Class를 상속 구조로 grouping Object지향 소프트웨어 공학, SciTech
Class Class는 박스로 표현하며 그 안에 이름을 적는다 3장 요구 분석 Class Class는 박스로 표현하며 그 안에 이름을 적는다 diagram은 Attribute과 Operation을 나타낼 수 있다. Operation의 원형은 다음과 같이 표시한다. operationName(parameterName parameterType, …): returnType Object지향 소프트웨어 공학, SciTech
속 성 Object의 상태 또는 성질을 나타냄 Object에 대한 정보를 나타냄 3장 요구 분석 속 성 Object의 상태 또는 성질을 나타냄 Object에 대한 정보를 나타냄 Attribute은 변수와 동의어는 아님. Abstract적으로 정의한 성질 Object 외부에서 값을 가져갈 수도 있고 변경할 수도 있음 읽기 전용도 있음 Object지향 소프트웨어 공학, SciTech
Operation 박스 맨 아래 Operation의 원형으로 표현 대부분 Attribute에 대한 get,() set() 3장 요구 분석 Operation 박스 맨 아래 Operation의 원형으로 표현 대부분 Attribute에 대한 get,() set() 읽기 전용은 get() Operation만 일부 Operation은 매개변수 필요 일부 Operation은 다른 Object에 메시지 호출할 필요가 있음 Object지향 소프트웨어 공학, SciTech
가시성 Attribute과 Operation 앞에 visibility 표시 Public : ‘+’ Protected : ‘#’ 3장 요구 분석 가시성 Attribute과 Operation 앞에 visibility 표시 Public : ‘+’ Protected : ‘#’ Private : ‘-’ Object지향 소프트웨어 공학, SciTech
Abstract Class Abstract Operation Abstract Class 구현이 없는 Operation 3장 요구 분석 Abstract Class Abstract Operation 구현이 없는 Operation Abstract Class instance가 없는 Class Object지향 소프트웨어 공학, SciTech
연관관계 두 개의 Class가 서로 어떻게 관련이 있는지를 나타냄 연관관계의 양 끝에는 다중도를 표시 3장 요구 분석 연관관계 두 개의 Class가 서로 어떻게 관련이 있는지를 나타냄 연관관계의 양 끝에는 다중도를 표시 연관관계 특성을 드러내기 위해 이름을 붙임 Object지향 소프트웨어 공학, SciTech
연관관계 검토 One-to-one 한 회사에 오직 한 개의 책임자 위원회가 있음 책임자 위원회는 한 회사를 위한 위원회임 3장 요구 분석 연관관계 검토 One-to-one 한 회사에 오직 한 개의 책임자 위원회가 있음 책임자 위원회는 한 회사를 위한 위원회임 회사는 항상 위원회를 가지고 있어야 함 위원회는 어떤 회사의 소속임 Company BoardOfDirectors Object지향 소프트웨어 공학, SciTech
연관관계 검토 Many-to-many 비서 1명이 여러 명의 관리자를 위하여 일함 관리자 1명이 여러 명의 비서를 둘 수 있음 3장 요구 분석 연관관계 검토 Many-to-many 비서 1명이 여러 명의 관리자를 위하여 일함 관리자 1명이 여러 명의 비서를 둘 수 있음 비서는 pool에서 일함 관리자들은 비서의 그룹을 가질 수 있음 어떤 관리자는 비서가 없을 수도 있음 관리자가 없는 비서는 일시적으로 가능한가? * supervisor 1..* Secretary Manager Object지향 소프트웨어 공학, SciTech
연관관계 검토 불필요한 1대1 관계는 피함 하나의 Class로 표현해야 3장 요구 분석 Object지향 소프트웨어 공학, SciTech
복잡한 예 예약은 항상 단 하나의 탑승객에 대한 것 탑승객이 다수의 예약을 할 수 있음 탑승객이 없는 예약은 없음 3장 요구 분석 복잡한 예 예약은 항상 단 하나의 탑승객에 대한 것 탑승객이 없는 예약은 없음 예약에 탑승객이 여러 명인 경우는 없음 탑승객이 다수의 예약을 할 수 있음 탑승객이 예약이 하나도 없을 수 있음 탑승객에 다수의 예약이 있을 수도 있음 만약, ‘1..*’로 표시한 경우는? Object지향 소프트웨어 공학, SciTech
연관 Class 두 개의 연관 Class에 관한 Attribute을 어느 한쪽에 위치시킬 수 없 을 때 다음과 같은 경우 3장 요구 분석 연관 Class 두 개의 연관 Class에 관한 Attribute을 어느 한쪽에 위치시킬 수 없 을 때 다음과 같은 경우 Object지향 소프트웨어 공학, SciTech
재귀 연관관계 Class 자신과 연관관례를 맺음 Course successor * * prerequisite 3장 요구 분석 Object지향 소프트웨어 공학, SciTech
Class diagram 일반화 관계 두 가지 이상의 서브Class로 구체화 시키는 것 3장 요구 분석 Class diagram 일반화 관계 두 가지 이상의 서브Class로 구체화 시키는 것 Discriminator: 상세화 할 때 기준을 나타내는 레이 블 Animal habitat typeOfFood Herbivore Carnivore LandAnimal AquaticAnimal Object지향 소프트웨어 공학, SciTech
불필요한 상속 피하기 instance가 되어야 할 것을 무리하게 Class 구조로 상속한 경우 3장 요구 분석 불필요한 상속 피하기 instance가 되어야 할 것을 무리하게 Class 구조로 상속한 경우 개선 후 Class diagram Object지향 소프트웨어 공학, SciTech
구별자 grouping하는 기준 동력의 위치에 따른 구별 – 내연, 외연 운송 매체 – 육상, 해상 3장 요구 분석 Object지향 소프트웨어 공학, SciTech
전체부분 관계 - Aggregation Aggregation : 전체부분 관계를 나타내는 특수한 형태 3장 요구 분석 전체부분 관계 - Aggregation Aggregation : 전체부분 관계를 나타내는 특수한 형태 전체에 해당되는 Class는 aggregate 또는 assembly라 부름 다이어몬드 symbol은 isPartOf 라는 관계로 생각할 수 있 음 Object지향 소프트웨어 공학, SciTech
Aggregate를 사용하는 경우 일반적인 경우 다음의 관계가 성립하면 aggregate를 사용 3장 요구 분석 Aggregate를 사용하는 경우 일반적인 경우 다음의 관계가 성립하면 aggregate를 사용 ‘is a part of’ 관계가 성립할 때 ‘is composed of’ 관계가 성립할 때 집합 개념을 관리하거나 소유하고 있으면 부분 개 념도 소유 Object지향 소프트웨어 공학, SciTech
합성관계(Composition) 합성은 aggregation이 강한 관계 집합이 소멸되면 부분도 따라서 소멸 3장 요구 분석 합성관계(Composition) 합성은 aggregation이 강한 관계 집합이 소멸되면 부분도 따라서 소멸 주소를 표현하는 두 가지 방법 (1:1합성관계) * Building Room Employee Employee Address address: Address street municipality region country postalCode Object지향 소프트웨어 공학, SciTech
3장 요구 분석 Aggregation 구조 Object지향 소프트웨어 공학, SciTech
Interface Interface는 Object집합이 가지는 행위의 일 부를 가시화 한 것 3장 요구 분석 Interface Interface는 Object집합이 가지는 행위의 일 부를 가시화 한 것 Interface는 Class와 유사, instance 변수와 구현된 메소드만 없다. «interface» Person Machine Person Machine Cashier withdraw Cashier Cashier deposit Employee ATM Employee ATM Object지향 소프트웨어 공학, SciTech
Class diagram 개발 과정 반복, 점증적 방법 초벌로 작성 후 계속 추가, 삭제 3장 요구 분석 Object지향 소프트웨어 공학, SciTech
Class 파악 도메인 모델을 개발할 때 Class를 찾아내려고 노 력 3장 요구 분석 Class 파악 도메인 모델을 개발할 때 Class를 찾아내려고 노 력 사용자 Interface나 시스템 구조에 대한 작업할 때 필요한 Class를 고안 특정 설계 문제를 해결할 때 필요 도메인 모델을 생성할 때 고안할 수도 있음 재사용에 관심을 두어야 프레임워크 시스템 확장 유사 시스템 Object지향 소프트웨어 공학, SciTech
연관관계 파악 가장 중요한 중심 되는 Class부터 시작 분명하고 확실한 데이터를 포함할 수 있는 것이어야 3장 요구 분석 연관관계 파악 가장 중요한 중심 되는 Class부터 시작 분명하고 확실한 데이터를 포함할 수 있는 것이어야 덜 중요한 Class로 작업을 이동 Class에 많은 Attribute과 연관관계를 추 가하는 것은 피해야 Object지향 소프트웨어 공학, SciTech
연관관계 파악 비결 다음과 같은 관계가 Class에 성립되는지 판단해 본다. 양 끝에 다중도를 표시하고 레이블을 정확히 붙임 3장 요구 분석 연관관계 파악 비결 다음과 같은 관계가 Class에 성립되는지 판단해 본다. possesses controls is connected to is related to is a part of has as parts is a member of, or has as members 양 끝에 다중도를 표시하고 레이블을 정확히 붙임 Object지향 소프트웨어 공학, SciTech
Attribute 파악 각 Class에서 보관하여야 할 데이터를 찾음 3장 요구 분석 Attribute 파악 각 Class에서 보관하여야 할 데이터를 찾음 Class 후보에서 탈락한 명사는 대부분 Attribute 임 Attribute은 단순한 원자적 값을 가져야 함 스트링, 문자, 정수 등의 type Object지향 소프트웨어 공학, SciTech
3장 요구 분석 항공권 예약 시스템의 예 Object지향 소프트웨어 공학, SciTech
일반화 관계와 Interface의 파악 일반화를 파악하는 두 가지 방법 3장 요구 분석 일반화 관계와 Interface의 파악 일반화를 파악하는 두 가지 방법 상향식 유사 Class를 grouping 하여 superClass를 생성 하향식 먼저 일반적인 Class를 찾고 필요하면 상세화 super Class 대신에 Interface를 정의하는 경우 몇 개의 Operation만 같고 그 외의 부분은 다른 Class들 하나 이상의 Class들이 이미 superClass가 존재 (다중상 속이 되는 경우) 같은 Class의 구현이 다르게 존재할 때 Object지향 소프트웨어 공학, SciTech
3장 요구 분석 일반화 사례 Object지향 소프트웨어 공학, SciTech
Class에 임무부여 임무(responsibility)란 시스템이 수행하도록 요구된 사 항 임무를 결정하기 위하여 3장 요구 분석 Class에 임무부여 임무(responsibility)란 시스템이 수행하도록 요구된 사 항 주어진 Class의 모든 요구는 명확히 서로 연관됨 (interactions) 한 Class에 너무 많은 임무가 주어지면 다른 Class로 분산 임무가 부여되지 않은 Class는 필요 없는 것임 어떤 임무가 현재 존재하는 Class에 할당되지 않았다면 새 Class 를 생성 임무를 결정하기 위하여 Use Case 분석 시스템 명세에 action을 기술하고 있는 동사와 명사를 찾음 Object지향 소프트웨어 공학, SciTech
3장 요구 분석 임무 파악 사례 Object지향 소프트웨어 공학, SciTech
Operation 파악 각 Class에 부여된 임무를 실현시키기 위하여 필 요 3장 요구 분석 Operation 파악 각 Class에 부여된 임무를 실현시키기 위하여 필 요 임무 하나에 여러 개의 Operation이 필요할 수도 있음 임무를 구현한 main Operation은 public으로 선언되 어야 임무를 실행하기 위하여 Collaboration하는 다른 메소 드는 가능하면 private으로 선언 Object지향 소프트웨어 공학, SciTech
Collaboration Class와 Operation 3장 요구 분석 Collaboration Class와 Operation Object지향 소프트웨어 공학, SciTech
Class Diagram
Class Diagram: dependency Class MyclassA { Public void operation1(void); Public void operation2(void); } Class MyclassB Public void createAobj() MyClassA Aobj = new MyClassA(); Aobj.operation1(); //이 method내부에서만 유지
StarUML 연습: Sequence Diagram [실습] GUI는 키 입력을 운영체제에게 알린다. 운영체제는 CPU에게 그 사실을 알린다. 운영체제는 GUI를 갱신한다. CUP는 비디오 카드에게 GUI 갱신에 필요한 명령을 내린다. 비디오 카드는 모니터로 메시지를 전송한다. 모니터는 화면에 Alpha Numeric 문자를 표시하고, 사용자에게 피드백을 제공 한다.
연습문제 Web-based ATM 시스템의 개발 은행 고객들이 Web 상에서 ATM의 기본적인 금융 트랜잭션을 수행 은행 직원을 위한 기능 고객의 추가/삭제 계좌의 생성/삭제 고객을 위한 기능 계좌 조회 트랜잭션 조회 현금 인출 예금 계좌이체
StarUML 연습: Sequence Diagram 객체(Object) 메시지(Message) 생명선(Lifeline) 시간의 흐름 실행 (Activation) 메시지(message) - 한 객체에서 다른 객체로 전송을 의미 - 한 객체의 생명선에서 다른 객체의 생명선으로 이동하는 것으로 표현. - 객체는 자기 자신에게 메시지를 보낼 수 있다. 실행(activation): 객체가 수행되고 있는 시간을 나타낸다. 사각형의 길이는 오퍼레이션의 실행 소요 시간을 나타낸다.
System Sequence Diagram
Sequence Diagram Frame operator Loop: Opt (Alt) Par: Region: guard가 true일 동안 looping 반복 횟수 n값을 지정할 수도 있음 Opt (Alt) Guard가 true이면 수행 Par: Parallel running 구역 Region: 단 하나의 thread만 run할 수 있는 critical region
Sequence Diagram
Sequence Diagram
Sequence Diagram
Sequence Diagram
Sequence Diagram
Use Case Diagram
Sequence Diagram (1/6) logIn customer
Sequence Diagram (2/6) addCustomer
Sequence Diagram (3/6) deleteCustomer
Sequence Diagram (4/6) addAccount
Sequence Diagram (5/6) showAccount
Sequence Diagram (6/6) transfer
State diagram 시스템 전체, 시스템의 일부, 개별 Object에 대한 동작을 나타냄 3장 요구 분석 State diagram 시스템 전체, 시스템의 일부, 개별 Object에 대한 동작을 나타냄 주어진 시점에 시스템이 어떤 상태에 있다고 하는 것은 발생 이벤트에 대응하여 특정한 방법으로 동작한다는 것을 의미 어떤 이벤트는 시스템의 상태를 변화시킴 새로운 상태에서 이벤트에 대하여 시스템은 여러 방법으로 작동 노드는 상태를 나타내며 아크는 트랜지션을 나타내는 방향성 있 는 그래프 Object지향 소프트웨어 공학, SciTech
상태 State 주어진 시점에 시스템은 어떤 상태에 있음 이벤트가 발생하여 상태를 변화시키기 전까지는 그 상태 에 머물러 있음 3장 요구 분석 상태 State 주어진 시점에 시스템은 어떤 상태에 있음 이벤트가 발생하여 상태를 변화시키기 전까지는 그 상태 에 머물러 있음 상태는 둥근 사각형 안에 상태 이름을 표시하여 나타냄 특수 상태 시작 상태는 검은 원으로 나타냄 종료 상태는 원이 둘려진 검은 점으로 나타냄 Object지향 소프트웨어 공학, SciTech
트랜지션 Transition 트랜지션 이벤트에 대한 상태 변화를 나타냄 트랜지션 위에는 상태변화를 일으키는 이벤트를 표시 3장 요구 분석 트랜지션 Transition 트랜지션 이벤트에 대한 상태 변화를 나타냄 즉시 일어남이 원칙 트랜지션 위에는 상태변화를 일으키는 이벤트를 표시 Object지향 소프트웨어 공학, SciTech
3장 요구 분석 시간이 표시된 State diagram Object지향 소프트웨어 공학, SciTech
3장 요구 분석 조건이 표시된 State diagram Object지향 소프트웨어 공학, SciTech
State diagram의 Activity 3장 요구 분석 State diagram의 Activity Activity란 시스템이 어떤 상태에 있을 때 발생하 는 것 일정 시간이 걸림 Activity가 완료된 응답으로 어떤 상태에서 빠져 나오 는 트랜지션이 이루어짐 그 외의 트랜지션 Activity의 인터럽트 상태에서 조기에 빠져 나옴 Object지향 소프트웨어 공학, SciTech
3장 요구 분석 사례: Activity Object지향 소프트웨어 공학, SciTech
상태diagram의 action action은 시간의 경과 없이 바로 일어날 수 있는 것 3장 요구 분석 상태diagram의 action action은 시간의 경과 없이 바로 일어날 수 있는 것 특정 트랜지션이 이루어질 때 특정 상태로 진입할 때 특정 상태에서 빠져나올 때 action은 감지할 수 없는 적은 시간을 소비하여 야 함 Object지향 소프트웨어 공학, SciTech
State diagram – action 사례 3장 요구 분석 State diagram – action 사례 Object지향 소프트웨어 공학, SciTech
3장 요구 분석 State diagram – 다른 예 Object지향 소프트웨어 공학, SciTech
내장된 상태와 가드 조건 State diagram이 상태 안에 내장될 수 있음 내부 diagram의 상태를 서브 상태라 함 3장 요구 분석 내장된 상태와 가드 조건 State diagram이 상태 안에 내장될 수 있음 내부 diagram의 상태를 서브 상태라 함 Object지향 소프트웨어 공학, SciTech
3장 요구 분석 상태diagram – 내장 형태 Object지향 소프트웨어 공학, SciTech
Activity diagram Activity diagram은 State diagram과 유사 Activity diagram은 3장 요구 분석 Activity diagram Activity diagram은 State diagram과 유사 단, 대부분의 트랜지션이 내부 이벤트(계산 종료)에 의하여 이루어 진다는 것이 다름 Activity diagram은 Object나 컴포넌트가 수행하는 작업의 흐름을 이해하는데 사용 다른 Use Case 사이의 관계나 상호작용을 가시화하는데 사용 대부분 여러 Class와 관련 됨 1) 시스템 차원의 작업의 흐름 파악 2) 주요 클래스 객체(들)을 중심으로 작업의 흐름 파악하는데 사용 Activity diagram의 강점 중의 하나는 병행 Activity의 표현 Object지향 소프트웨어 공학, SciTech
3장 요구 분석 Activity diagram - 사례 Object지향 소프트웨어 공학, SciTech
병행처리 표현 병행처리는 fork, join, rendezvous를 사용하여 표현 3장 요구 분석 병행처리 표현 병행처리는 fork, join, rendezvous를 사용하여 표현 fork는 단일 입구 트랜지션과 다수의 출구 트랜지션을 가짐. 실행경로가 두 개의 병행 스레드로 분할 됨 Rendezvous는 다수의 입구 트랜지션과 다수의 출구 트랜지션을 가짐 모든 입구 트랜지션이 트리거 되면 시스템이 모든 출구 트렌지션 이루어 짐 Join은 다수의 입구 트랜지션과 단일 출구 트랜지션을 가짐 모든 입구 트랜지션이 이루어진 후 출구 트랜지션이 발생 입구 트랜지션은 분리된 스레드에 의하여 트리거 됨 먼저 어루어진 입구 트랜지션은 다른 입구 프렌지션이 이루어질 때까지 기다림 Object지향 소프트웨어 공학, SciTech
스윔레인 Swim Lane Activity diagram은 대체로 여러 Class와 관련됨 3장 요구 분석 스윔레인 Swim Lane Activity diagram은 대체로 여러 Class와 관련됨 같은 스윔레인 안에 있는 Activity들은 동일한 Class와 관련된 것 Object지향 소프트웨어 공학, SciTech
Activity Diagram
Activity Diagram
Package diagram Package 관계 공통적인 특성을 가진 Class들의 모임 재사용의 단위가 됨 3장 요구 분석 Package diagram Package 공통적인 특성을 가진 Class들의 모임 재사용의 단위가 됨 관계 점선 화살표는 의존관계를 나타냄 컴파일 타임에 바인딩 Object지향 소프트웨어 공학, SciTech
3장 요구 분석 Package diagram - 사례 Object지향 소프트웨어 공학, SciTech
Code Generation Generate Code from Class Diagram Java Profile 추가 [Model]->[Profiles] Java Profile을 Include함 Generate Code [Tools]->[Java]->[Generate Code] Package 선택-> 생성할 Class 선택->파일을 생성할 위치 선 택-> Option Setup 선택한 디렉토리에 .java 파일들이 생성됨
Reverse Engineering ` Generation한 Code로 Reverse Engineering [Tools]->[Java]->[Reverse Engineer] 소스 코드 선택 디렉토리 선택->자바 소스 파일 선택->모델을 생성할 Package 선택->옵션 선택 ` Generate Code Reverse Engineering