UML 실습 (Unified Modeling Language)

Presentation on theme: "UML 실습 (Unified Modeling Language)"— Presentation transcript:

1 UML 실습 (Unified Modeling Language)

2 객체지향 개발 프로세스 Plan OOA OOD Coding Testing Use Case Diagram
Conceptual Class Diagram Sequence Diagram Sate Transition Diagram Activity Diagram OOD Detail Class Diagram Component Diagram Deployment Diagram Coding Testing

3 Use Case 다이어그램 (1) 시스템과 사용자의 요구 분석 과정에 사용되는 다이어그램으로 Actor와 Use Case의 상호 작용으로 표현 Actor는 시스템 사용자 혹은 외부 시스템 Use Case는 Actor들과 관련하여 수행되는 행위(시스템 기능) 따라서, 이러한 Use Case Diagram을 통하여 초기에 시스템 개발시 사용자와 개발자는 충분히 요구사항을 반영하고 변경할 수 있는 대화 수단

4 Actor 추출법 우리는 시스템과의 상호작용을 하는 Actor를 몇 가지 질문을 통해 그 대상을 Actor로 간주할 수 있다.
1)   시스템의 주기능을 사용하는 사람은 누구인가? 2)   누가 시스템으로부터 업무 지원을 받는가? 3)   누가 시스템을 운영, 유지 보수하는가? 4)  시스템과 정보를 교환하는 외부 시스템은 무엇인가? 5)  시스템이 내어놓은 결과물에 누가 관심을 가지는가?

5 Use Case 추출법 Actor와 같이 Use Case또한 여러가지 질문을 통해 찾아낼 수 있다.
Actor가 요구하는 시스템의 주요 기능은 무엇인가? 2) Actor가 시스템의 어떤 정보를 수정, 조회, 삭제, 저장하는가? 3)시스템이 Actor에게 주는 어떠한 Event가 있는가?, Actor가 시스템에 주는 어떠한 Event가 있는가? 4)시스템의 입력과 출력으로 무엇이 필요한가? 그리고 입력과 출력이 어디에서 오고 어디에로 가는가? 5)시스템의 구현에서 가장 문제가 되는 점은 무엇인가?

6 Use Case 추출법 Actor와 같이 Use Case또한 여러가지 질문을 통해 찾아낼 수 있다.
Actor가 요구하는 시스템의 주요 기능은 무엇인가? 2) Actor가 시스템의 어떤 정보를 수정, 조회, 삭제, 저장하는가? 3)시스템이 Actor에게 주는 어떠한 Event가 있는가?, Actor가 시스템에 주는 어떠한 Event가 있는가? 4)시스템의 입력과 출력으로 무엇이 필요한가? 그리고 입력과 출력이 어디에서 오고 어디에로 가는가? 5)시스템의 구현에서 가장 문제가 되는 점은 무엇인가?

7 제품주문관리 시스템 Order scenario: We have customers who order our products. 우리에게는 우리 제품들을 주문하는 고객들 있다. We distinguish corporate customers from personal customers, since corporate customers are billed monthly whereas personal customers need to prepay their orders. (기업고객들과 개인고객들을 구분하고 있다. 기업고객들은 매달 대금청구서를 발송하고 있는 반면 개인고객은 주문 전에 주문 이전에 선납을 해야 하기 때문이다.) We want our orders to be lined up product by product. (우리는 주문이 제품별로 정렬되기를 바란다) Each line should contain the amount and the price of each product (각 주문라인은 각 제품의 가격, 수량을 포함되어야 한다)

8

9 Order scenario: We have customers who order our products. 우리에게는 우리 제품들을 주문하는 고객들 있다. We distinguish corporate customers from personal customers, since corporate customers are billed monthly whereas personal customers need to prepay their orders. (기업고객들과 개인고객들을 구분하고 있다. 기업고객들은 매달 대금청구서를 발송하고 있는 반면 개인고객은 주문 전에 주문 이전에 선납을 해야 하기 때문이다.) We want our orders to be lined up product by product. (우리는 주문이 제품별로 정렬되기를 바란다) Each line should contain the amount and the price of each product (각 주문라인은 각 제품의 가격, 수량을 포함되어야 한다)

10

11 Order: We have customers who order our products. We distinguish corporate customers from personal customers, since corporate customers are billed monthly whereas personal customers need to prepay their orders. We want our orders to be lined up product by product. Each line should contain the amount and the price of each product

12

13 We want our orders to be lined up product by product.
각 Order에 대해 제품별 주문라인 (Order line) 즉, Order는 다수의 Order line과 관련. Order line 하나의 Order와 관련 Each line should contain the amount and the price of each product 하나의 Order line에 한 종류씩의 product 를 포함하며 각 product의 수량 및 가격을 포함.  하나의 product 는 다수의 Order line에 포함 될 수 있다.

14

15

16

17 도서관리 시스템 1. 도서예약 1.1 Brief Description 이 use case는 사서에 의해 초기화된다.
1. 도서예약 1.1 Brief Description 이 use case는 사서에 의해 초기화된다. 대여자가 대여하기 전에 원하는 도서를 예약하는 기능으로 대여를 원하는 도서가 대여 상태인지를 체크하거나 존재하는지를체크한다. 이 use case는 입력, 수정, 조회, 취소 기능을 제공한다. 1.2 Main Flow of Events 이 use case에서 사서는 대여자가 원하는 도서를 검색한다 (E-1). 대여자의 정보를 입력한다. 예약정보를 입력한다. 이 시스템은 다음과 같은 활동을 할수있다. : 입력, 조회, 수정, 취소, 종료. 입력 : A-1 ‘예약 정보 입력’ 수행 조회 : A-2 ‘예약 정보 조희’ / A-2-1 ‘도서 조회’ / A-2-2 ‘대여자 조회’ 수행 변경 : A-3 ‘예약 정보 수정’ 수행 취소 : A-3 ‘예약 정보 취소’ 수행 종료 : 이 Use Case 를 끝낸다. 1.3 Alternative Flows A-1 : ‘예약 정보 입력’ 사서는 예약 정보를…. 1.4 Exception Flows E-1 : 만약 예약하려는 도서가 존재하지 않는다면, ….. 1.5 Scenarios ………

18 도서관리 시스템 Scenarios 사서는 도서관리 시스템에서 login, logout 이 가능하도록 한다.
사서는 도서관리 시스템을 이용하여 대여자가 도서를 대출하기 이전에 대여자의 요청으 로(offline) 도서예약이 가능 하도록 한다. 예약되지 않은 경우라도 대여분이 있다면 도서대여는 가능하도록 한다. 또한 도서반납도 이 시스템을 통하여 이루어지도록 한다. 도서반납 시 반납예정일을 계 산하여 초과시 연체료를 계산 하도록 한다. 사서는 도서예약과 도서 대여 시 조건에 따라 대여자 등록을 하도록 한다. 새로운 도서 를 구매하면 도서항목을 추가 하도록 한다.

19 도서관리 시스템 Scenarios 사서는 도서관리 시스템에서 login, logout 이 가능하도록 한다.
사서는 도서관리 시스템을 이용하여 대여자가 도서를 대출하기 이전에 대여자의 요청으 로(offline) 도서예약이 가능 하도록 한다. 예약되지 않은 경우라도 대여분이 있다면 도서대여는 가능하도록 한다. 또한 도서반납도 이 시스템을 통하여 이루어지도록 한다. 도서반납 시 반납예정일을 계 산하여 초과시 연체료를 계산 하도록 한다. 사서는 도서예약과 도서 대여 시 조건에 따라 대여자 등록을 하도록 한다. 새로운 도서 를 구매하면 도서항목을 추가 하도록 한다.

20 도서관리 시스템 Scenarios 사서는 도서관리 시스템에서 login, logout 이 가능하도록 한다.
사서는 도서관리 시스템을 이용하여 대여자가 도서를 대출하기 이전에 대여자의 요청으 로(offline) 도서예약이 가능 하도록 한다. 예약되지 않은 경우라도 대여분이 있다면 도서대여는 가능하도록 한다. 또한 도서반납도 이 시스템을 통하여 이루어지도록 한다. 도서반납 시 반납예정일을 계 산하여 초과시 연체료를 계산 하도록 한다. 사서는 도서예약과 도서 대여 시 조건에 따라 대여자 등록을 하도록 한다. 새로운 도서 를 구매하면 도서항목을 추가 하도록 한다. Log in 대여자등록 Log out 도서항목 추가 사서 사서 도서예약 도서대여 도서반납 연체료계산

21 도서관리 시스템 Scenarios 사서는 도서관리 시스템에서 login, logout 이 가능하도록 한다.
사서는 도서관리 시스템을 이용하여 대여자가 도서를 대출하기 이전에 대여자의 요청으 로(offline) 도서예약이 가능 하도록 한다. 예약되지 않은 경우라도 대여분이 있다면 도서대여는 가능하도록 한다. 또한 도서반납도 이 시스템을 통하여 이루어지도록 한다. 도서반납 시 반납예정일을 계 산하여 초과시 연체료를 계산 하도록 한다. 사서는 도서예약과 도서 대여 시 조건에 따라 대여자 등록을 하도록 한다. 새로운 도서 를 구매하면 도서항목을 추가 하도록 한다. Log in 대여자등록 Log out 도서항목 추가 사서 사서 도서예약 도서대여 도서반납 연체료계산

22 도서관리 시스템 Scenarios 사서는 도서관리 시스템에서 login, logout 이 가능하도록 한다.
사서는 도서관리 시스템을 이용하여 대여자가 도서를 대출하기 이전에 대여자의 요청으 로(offline) 도서예약이 가능 하도록 한다. 예약되지 않은 경우라도 대여분이 있다면 도서대여는 가능하도록 한다. 또한 도서반납도 이 시스템을 통하여 이루어지도록 한다. 도서반납 시 반납예정일을 계 산하여 초과시 연체료를 계산 하도록 한다. 사서는 도서예약과 도서대여 시 조건에 따라 대여자 등록을 하도록 한다. 새로운 도서 를 구매하면 도서항목을 추가 하도록 한다. Log in 대여자등록 Log out <<Extends>> 도서항목 추가 사서 사서 도서예약 <<Extends>> 도서대여 도서반납 연체료계산 <<Extends>>

23 Use Case 다이어그램 (2) 도서관리 시스템 Log in 대여자등록 Log out
<<Extends>> 도서항목 추가 사서 사서 도서예약 <<Extends>> 도서대여 도서반납 연체료계산 <<Extends>>

24 개략 Class 다이어그램 (1) 분석 단계의 클래스 다이어그램으로 시스템을 전체적으로 파악 개념 수준의 클래스 다이어그램
관련성 : 연관, 일반화, 집단화 역할 : 두 클래스 간의 연관 관계에 역할 명시 다중성 : 클래스의 객체 생성 수

25 개략 Class 다이어그램 (2) 복사 도서항목 데이타베이스 도서 관리 참조 대여 잡지 책 사서 예약 소유 대여자 1..*
itemID:String available:Boolean lost:Boolean 도서항목 Title[]:Map Item[]:Map Borrower[]:Map Loan[]:Map Reservation 데이타베이스 Name:String Isbn:ISBNType Price:Float loanPeriod:Integer numOfItem:Integer Availcount:Integer reservationCount: 도서 checkInDate:Date checkOutDate:Date lateReturnFee:Integer validLoan:Boolean LoanCount:Long 대여 userID:String Passward:String LogInFlag:Boolean 사서 reserveDate:Date 예약 Ssn:String Address:String logInFlag:Boolean 대여자 Author:String 책 Month:String publishCycle:String 잡지 관리 참조 소유 1 0..1 0..* * 1..*

26 Sequence 다이어그램 (1) Sequence Diagram은 여러개의 객체들 사이에 동적인 메시지 흐름을 보여주는 다이어그램 이 다이어그램의 중요한 특징은 객체사이의 메시지 흐름을 시간에 따라 순차적으로 표현하는 것 객체와 시스템의 수행중 어떤 특정 한 시점에서 발생할 무언가들 사이에 상호 작용을 보여줌

27 Sequence 다이어그램 (2) :사서 :제어기 :예약 :도서 :대여자 :데이터베이스 makeReservation
titleRef:=searchTitle(is bn:String) titleRef:=searchTitleDB(is bn:String) (titleRef is invalid) displayMess age(“Error”) (titleRef is valid) borrowRef:=searchBarrower(ssn:String) borrowRef:=searchBarrowerDB(ssn:String) (borrowerRef is invalid) displayMessage(“Error”) (borrowerRef is valid) reservatonRef:=new 예약(titleRef:도서, borrowerRef:대여자) addReservation(reservationRef:예약) addReservationDB(reservationRef:예약)

28 Collaboration 다이어그램 (1)
Collaboration Diagram은 Sequence Diagram처럼 동적인 사항을 보여줌 시간 흐름보다는 객체간의 상호작용에 초점을 두는 다이어그램 내부적으로 표현되는 정보의 양이 동일하므로, 표현 방식만 다르지, Sequence Diagram과 동일하다고 볼 수 있음 따라서, 시간의 흐름에 초점을 맞추는 경우라면 Sequence Diagram을 그리는 것이 유리하고, 상호 작용이나 협력 관계에 초점을 두는 경우라면 Collaboration Diagram을 그림

29 Collaboration 다이어그램 (2)

30 State 다이어그램 특정 클래스의 객체가 가질 수 있는 상태와 상태간의 전이를 나타내는 다이어그램
이것을 통하여 객체가 어떤 상태에 이르고, 어떻게 객체에 도달한 이벤트의 결과로써, 객체의 상태가 변하는지에 대한 모든 가능한 상태를 묘사 예약되지 않음 예약수 :=0 예약 됨 도서예약 /예약수++ 예약삭제 (예약수=1) /예약수-- (예약수>1)

31 Activity 다이어그램 (1) 개발될 시스템에 대한 작업 흐름을 표현하기 위한 모델링 도구
개략 활동도와 상세 활동도로 구성 활동들 간의 순차적인 흐름뿐 아니라 병행 흐름도 표현 수행하는 기능의 주체를 나타내기 위해 스윔레인을 이용

32 Activity 다이어그램 (2) 도서예약 대여자 정보 입력 도서 대출 취소 예약 도서 입력 도서 검색 도서 예약 도서 구입
신청 반납 도서 검색 (존재하지 않음) (존재함) 도서예약

33 상세 Class 다이어그램 (1) 객체의 타입인 클래스를 표현하는 다이어그램
클래스의 속성과 행위(Operation), 그리고, 연관, 합성, 위임, 일반화, 패키지등의 다른 클래스들과 정적 관계를 표현하며, 정적 관계에 대한 제약등을 표현 이러한 클래스 다이어그램의 목적은 다른 동적인 다이어그램에서 보여진 특징에 대한 기초 클래스를 정의하는데 있음 또한, Class Diagram에서 클래스는 클래스 개념을 지원하는 언어에서 직접 구현될수 있음

34 상세 Class 다이어그램 (2)

35 Component 다이어그램 (1) 실제 코드 컴포넌트에 바탕을둔 코드의 물리적 구조를 보여주는 다이어그램
어떤 클래스를 어떤 파일에 넣으며, 어떤 파일을 모아 어떤 모듈을 만들 것인지 등을 정의 클래스의 의존성과 마찬가지로 컴포넌트의 의존성을 표현 컴포넌트하기 위한 조건으로 클래스들 간의 메시지 수를 고려하여 많은 호출이 있는 클래스들을 하나의 컴포넌트로 구성 가능 컴포넌트 내부의 클래스는 컴포넌트 외부의 클래스들과 호출이 없으면 인터페이스를 통해 상호 작용 컴포넌트들 간에도 연관성이 강한 컴포넌트를 묶어 복합 컴포넌트 가능

36 Component 다이어그램 (2) 데이타베이스 도서항목 데이타베이스 도서 대여 잡지 책 사서 예약 도서관리 대여 대여자 예약
itemID:String available:Boolean lost:Boolean Title[]:Map Item[]:Map Borrower[]:Map Loan[]:Map Reservation * Name:String Isbn:ISBNType Price:Float loanPeriod:Integer numOfItem:Integer Availcount:Integer reservationCount: 대여 잡지 checkInDate:Date checkOutDate:Date lateReturnFee:Integer validLoan:Boolean LoanCount:Long 책 Month:String publishCycle:String Author:String 사서 Name:String userID:String Passward:String LogInFlag:Boolean 예약 도서관리 reserveDate:Date 대여 대여자 Name:String Ssn:String Address:String logInFlag:Boolean 예약

37 복합 Component 다이어그램 (3) 예약 UI AWT 도서관리 예약 대여 메인 데이타베이스

38 Deployment 다이어그램 프로세스간, 하드웨어간 장비와 이들간의 연결과 같은 시스템의 하드웨어와 소프트웨어의 물리적 구조를 보여줌 클라이언트 서버 예약 UI TCP/IP 도서 대여 대여 UI 예약 데이터베이스