소프트웨어 공학 Lecture # 6 - 1: UML

1. 소프트웨어 공학Lecture #6 - 1: UML 안 병 익 biahn99@gmail.com 강의 블로그Mobilecom.tistory.com

2. 강의 개요 • 소 개 • UML 기초 • 모형화 개념 • UML 응용

3. 소 개 • 객체지향 분석 및 설계 방법 • 표현 방법에 중점: 예) UML • 개발 프로세스: 예)Unified Process • 개발자 • Grady Booch, James Rumbaugh, and Ivar Jacobson • OMG(Object Management Group)에 의하여 표준 채택 보급 • Rational Software, Microsoft, Hewlett-Packard, Oracle, Texas Instruments, MCI Systemhouse 등

4. UML • 표준 문서 • The Unified Modeling Language for Object-Oriented Development • Available from http://www.rational.com • UML의 발전 • Unified Method 0.8 at OOPSLA ‘95 • UML 0.9(June ‘96), UML 0.91(Oct ‘96) • UML 1.0(Dec. ‘96) • UML 1.1(July ‘97) • UML 1.3(Expected to be completed mid-1999)

5. 시스템 모형 • 기능적 모형 • 사용자 측면에서 본 시스템 기능 • UML: 사용 사례 다이어그램 • 객체 모형 • 객체, 속성, 연관관계, 오퍼레이션으로 시스템의 정적 구조를 나타냄 • UML: 클래스 다이어그램 • 동적 모형 • 시스템의 내부 동작 • UML: 순서 다이어그램, 상태 다이어그램, 액티비티 다이어그램

6. UML 이전의 방법들 • 많이 쓰이던 세 가지 방법 • Booch, Rumbaugh’s OMT, Jacobson’s OOSE • 기타 방법들 • Meyer의 Assertion Mechanism • Shlaer-Meller의 Object Lifecycles • Odell의 Classification • Wirf-Brock의 Responsibility • Fusion의 Operation descriptions, Message numbering • Embley의 Singleton classes, High-level view • Harel의 State Charts • Gamma 등의 Frameworks, Patterns

7. UML의 장점 • 업계에서 많이 채택하여 사용 중 • OOA/D 방법 중 많이 사용하던 Booch, Rumbaugh, Jacobson의 방법을 기초로 작성 • OMG에 의하여 표준화 • 다양하고 일관성 있는 표현 방법 • 분석 및 설계, 구현에 이르기까지 매끄럽게 연결됨 • 의사교환이 용이해짐 • 소규모나 대규모 모두 잘 적용할 수 있음 • CASE 도구 및 개발 프로세스의 지원 • ROSE • Unified Process

8. 강의 개요 • 소 개 • UML 기초 • 모형화 개념 • UML 응용

9. UML 기초 • 사용사례 다이어그램 • 외부 사용자에 의하여 보여지는 시스템의 큰 기능을 나타냄 • 시스템의 기능 모형 • 클래스 다이어그램 • 시스템을 구성하는 클래스가 어떤 것들이며 그들 사이의 관계를 나타냄 • 시스템의 객체 모형(정적 모형) • 순서 다이어그램 • 시스템의 객체들 사이의 메시지 교환을 시각화 • 시스템의 동적 모형 • 상태 다이어그램 • 객체에 대한 상태 변환을 나타냄 • 액티비티 다이어그램 • 병렬 수행 가능 작업을 나타냄

10. Use-Case 다이어그램 • 정의 • “순서 있는 액션의 집합을 기술한 것으로 액터에게해택이 있는 결과를 제공하여야 함”(UML User guide, pp.220) • 목적 • 시스템의 외부 기능을 나타냄 • 사용자의 요구를 추출하고 분석 • 구성 요소 • 사용사례(use case) –액터에게 보이는 시스템의 기능 • 액터(actor) –시스템과 상호작용하는 사람이나 다른 시스템, 하드웨어 • 의미 • 시스템의 범위를 정함

11. Use-Case 다이어그램 • 시스템이 어떤 기능을 수행하고(Use Cases), 주위에 어떤 것이 관련되는지(Actors)를 나타낸 모형. Library Reserve book Browse Browser Book borrower Borrow copy of book Update catalog Return copy of book Librarian Extend loan

12. 교과서의 예 Watch ReadTime WatchUser SetTime WatchRepairPerson ChangeBattery

13. 클래스 다이어그램 • 정의 • 시스템을 구성하는 클래스의 구조를 나타냄 • 객체들의 공통 구조와 동작들을 추상화 한 것 • 목적 • 시스템을 구현할 때 어떤 클래스가 필요한지 • 클래스 사이의 관계를 나타냄 • 구성요소 • 객체, 클래스, 속성, 오퍼레이션, • 연관관계 • 의미 • 클래스 다이어그램은 객체지향 프로그램의 골격(즉 클래스의 정의)을 나타냄

14. UML 클래스 다이어그램 예: 시계 Simple Watch 1 1 1 1 2 1 1 2 Display Battery Time PushButton

15. 순서 다이어그램 • 정의 • 시스템의 동작을 정형화하고 객체들의 메시지 교환을 시각화 • 목적 • 사용 사례 다이어그램에 관련된 객체(참여 객체)를 추가로 찾아 내기 위하여 • 객체 사이에 일어나는 상호 작용을 파악하여 나타냄 • 의미 • 클래스가 가져야 할 오퍼레이션을 파악하는 데 사용됨 • 각 사용 사례에 대하여 하나의 순서 다이어그램을 그림

16. 순서 다이어그램: Simple Watch :Time :SimpleWatch :Display :WatchUser PressButton1() blinkHours() blinkMinutes() PressButton1() blinkMinutes() PressButton2() incrementMiutes() Refresh() PressButton1And2() CimmitNewTimes() StopBlinking()

17. 상태 다이어그램 • 정의 • 객체가 갖는 여러 상태와 상태 사이의 전환을 표현 • 목적 • 단일 객체의 동작을 나타냄 • 객체의 상태 변화를 점검하여 빠진 오퍼레이션이 없는지 점검 • 요소 • 원 –객체의 상태 • 화살표 - 전이(transition)

18. SimpleWatch의 상태 다이어그램 button2Pressed button1&2Pressed Increment Hours BlinkHours button2Pressed button1&2Pressed Increment Minutes BlinkMinutes button1&2Pressed button2Pressed Increment Seconds BlinkSeconds StopBlinking

19. 액티비티 다이어그램 • 액티비티: • 시스템에서 수행되는 작업(오퍼레이션의 집합) • 클래스의 매소드 • 출처 • 이벤트 다이어그램(Jim Odell) • SDL State Modeling technique • Petri-nets • 구성요소 • 원: 액티비티 • 화살표: 트랜지션(다른 액티비티로의 전환) • 동기 막대: 제어흐름의 동기화 • 다이어몬드: 선택 분기 • 시작, 종료

20. 액티비티 다이어그램 예 Allocate Resources Coordinate Resources Open Incident Archive Incident Document Incident

21. 강의 개요 • 소 개 • UML 기초 • 모형화 개념 • UML 응용

22. 모형화 개념 • 모형화 개념이 중요한 이유 • 아직 개발되지 않은 소프트웨어 시스템에 대하여 vision을 갖는 과정 • 복잡한 시스템에 대하여 컨셉을 잡고 • 이를 구체화 시키는데 필요 • 무에서 유를 창조하는 방법 • 모형: 상상 속의 시스템, 즉 설계 • 소프트웨어: 모형을 프로그래밍으로 구현 • 모형을 잘 개발하려면 • 연습이 필요

23. 시스템, 모형, 뷰 • 시스템 • 특정한 목적을 위하여 설계된 상호작용하는 부품의 집합 • 예: 자동차 • 목적: 사람이나 짐을 운반 • 부품: 바퀴, 엔진, 차체, 변속기어 • 서브시스템 • 시스템의 컴포넌트는 다시 작은 시스템이 될 수 있음 • 예: 자동차의 엔진 • 실린더, 피스톤, 연료공급 모듈 • 서브 시스템으로의 분할 • 추상 -> 구체적

24. 모 형 • 모형 • 복잡한 것을 다루기 위한 수단 • 서로 다른 관점과 정확성의 수준을 가짐 • 예: 지도(map) • 지형을 2차원으로 모형화 한 것 • Scale • 모형과 추상화 • 불필요한 자세한 부분을 생략하고 주요 관심사만 표현 • 예: 비행기 제작 • 스케일 모형(외관만 표현) • 모의 비행 시스템(비행기의 조작 계기판만 표현)

25. 비행기 제작 모형 스케일 모형 전기 기타 설계도 비행기 연료 비행 시뮬레이터

26. 뷰와 표현 방법 • 뷰 • 이해할 수 있도록 만든 모형의 부분집합 • 예: 비행기 설계도, 연료시스템 구성도 • 중첩될 수도 있음 • 표현 방법 • 뷰를 표현하는 방법 • 그래픽 또는 문자의 규칙 • 예: UML 다이어그램 • 같은 의미도 다른 표현 방법을 사용할 수 있음

27. 여러 가지 다른 표현 방법 • UML 1 * Book Chapter Composed-of • Booch N Chapter Book Composed-of

28. 개념과 현상 • 현상 • 존재하며 인식될 수 있는 객체 • 예: • 이 책 • 현재의 이자율 3% • 내 검정 시계 • 금요 낚시클럽 • 개념 • 현상을 나타내는 추상 • 예: • 객체지향 소프트웨어공학 교과서 • 정기 예금의 이자율 • 검정 시계 • 낚시 클럽

29. 개 념 • 현상들이 가지고 있는 공통된 특성 • 검정 시계 -> 개념 멤버 이름 목적 시간을 재기 위한 장치 Clock

30. 모형화 • 추상화 • 현상을 개념으로 구별하여 정의하는 것 • 모형화 • 여러 현상들에 대한 물음에 대답이 될 수 있는 추상들을 개발하는 작업 • 예) 원소 주기율표 • 원자의 무게와 전자의 수를 기초로 정리한 것 • 어떤 분자를 구성하는지, 어떻게 구할 수 있는지는 나타내지 않음 • 시스템 엔지니어 • 시스템 디자인 작업 –모형화 작업 • 응용 도메인과 솔루션 도메인에서 개념을 추상화

31. 객체지향 모형화 • 응용 도메인 • 사용자 환경의 모든 문제를 포함 • 사용자, 작업 과정 등 • 객체지향 분석 • 솔루션 도메인 • 구현 가능한 시스템의 모든 영역 • 시스템의 구조 및 객체 설계 • 객체지향 설계

32. 응용 도메인과 솔루션 도메인 응용 도메인 솔루션 도메인 응용 도메인 모형 솔루션 도메인 모형 Traffic Control MapDisplay SummaryDisplay Traffic Controller HightPlanDatabase Airport AirCraft FlightPlan Traffic Controll

33. 강의 개요 • 소 개 • UML 기초 • 모형화 개념 • UML 응용

34. 사용사례 다이어그램 • 사용사례는 시스템의 외부 동작을 파악한 것 • 시스템이 외부 자극에 어떻게 반응하는가 • 외부에서 보이며 테스트 가능한 시스템의 액티비티 • 사용자와 컴퓨터 사이의 상호작용 • Ex) 워드프로세서 • “굵은체로 만들기” • “인덱스 생성” • 사용사례는 시스템과 외부 환경, 그들 사이의 관계를 나타냄

35. 구성 요소 • 액 터 • 시스템과 상호 작용하는 외부 엔티티 • 사용자가 맡은 일 또는 다른 시스템 • 사용사례 • 특정 액터에게 원하는 결과를 제공하는 시스템에 의하여 수행된 액션이나 트랜젝션

36. 사건 관리 시스템 사건관리시스템 Report Emergency FieldOfficer Open Incident Dispatcher Allocate Resources

37. 액 터(Actor) • 액터는 시스템의 일부가 아님 • 시스템을 이용하거나 같이 동작하는 시스템 외부 요소 • 액터는 • 시스템에 자료를 입력만 할 수도 있음 • 시스템에서 정보를 받기만 할 수도 있음 • 자료를 주고 정보를 받을 수도 있음 • 액터는 사용자의 역할을 표현한 것임 • 액턴는 사람일 수도 있고 기계, 다른 시스템일 수도 있음

38. 액터를 찾기 위한 질문 • 시스템의 특정 기능을 요구하는 사람(기계)은 누구인가? • 기관의 어느 부서가 시스템을 사용하는가? • 시스템의 사용으로 누가 혜택을 보는가? • 시스템에 누가 자료를 제공하고, 정보를 이용하고, 정보를 삭제하는가? • 누가 시스템을 제공하고 유지보수 하는가? • 시스템이 외부 자원을 사용하는가? • 한 사람이 여러 가지 역할을 담당하는가? • 여러 사람이 같은 역할을 담당하는가? • 시스템이 노후 시스템과 연결되어 상호작용하는가?

39. 사용사례(Use-Case) • 사용 사례(use case) • 액터와 시스템 사이의 전형적인 인터액션을 표현한 것 • 시스템이 제공할 기능을 표현한 것 • 완전하고 의미 있는 이벤트의 흐름 • 사용 사례의 집합은 시스템을 사용하는 모든 방법을 이룬다. • 사용사례 이름 붙이기 • 액터의 관점에서 이름 붙임 • 시스템에 치우친 이름은 피한다. • 수동적 이름을 사용

40. 사용사례 Template • 이름 • 사용사례에 고유한 이름을 붙여 개발자가 구별할 수 있도록 • 참여 액터 • 사용 사례와 관련된 액터 • 시작 조건 • 사용 사례가 활성되기 전에 만족되어야 하는 조건 • 사건 흐름 • 사용 사례를 구성하는 액션을 순서대로 나타낸 것 • 종료 조건 • 사용 사례가 종료 후 만족하여야 하는 조건 • 특수 요구 • 비기능적 요구: 성능, 구현, 하드웨어 플랫폼에 대한 조건

41. 사용사례의 예(ReportEmergency) 사용사례 이름ReportEmergency 참여 액터FieldOfficer에 의하여 구동됨 Dispatcher와 통신 시작 조건1. FieldOfficer가 자신의 터미널에서 “Report Emergency? 기능을 활성시킨다. 시스템이 입력양식을 화면에 제시 하여 경찰관에게 반응한다. 사건의 흐름2. FieldOfficer가 응급 정도, 종류, 위치, 상황의 간단한 설 명을 양식에 입력한다. 또한 FieldOfficer는 응급사태의 상황에 적절히 대응한 것을 기술할 수 있다. 양식이 일 단 완성되면 FieldOfficer는 양식을 제출하고 Dispatcher 에게 알린다. 3. Dispatcher가 보고된 정보를 살펴보고 OpenIncident사용사례를 구동시켜 데이터베이스에 Incicent를 생성한다. 종료 조건4. FieldOfficer가 회신과 선택된 응답을 받는다. 특수 요구FieldOfficer의 보고는 30초 안에 응답되어야 한다. Dispatcher에 의하여 응답이 보내진 후 30초 이내로 선택 된 응답을 받는다.

42. 사용사례 파악을 위한 질의 • 액터는 어떤 작업을 하나? • 어떤 액터가 시스템에 정보를 제공, 저장, 사용, 변경하는가? • 어떤 사용사례가 이러한 정보들을 제공, 저장, 사용, 변경하는가? • 외부 환경의 변화에 대하여 시스템에 알려주어야 하는 액터는? • 시스템의 유지보수를 담당하는 사용사례는?

43. 시나리오 • 사용사례와의 관계 • 시나리오: 사용사례의 인스턴스 • 사용사례: 시스템의 기능을 나타내는 모든 가능한 시나리오를 추상화 한 것 • 시나리오 • 사용 사례의 예 • 시나리오 기술 • 이름: 시나리오의 이름 • 참여 액터의인스턴스: 시나리오에 참여한 액터 • 이벤트의 흐름: 단계적으로 일어나는 이벤트의 순서

44. 시나리오의 예 시나리오 이름warehouseOnFire 참여 객 인스턴스kim, lee: FieldOfficer park: Dispatcher 사건의 흐름1. 경관 Kim이 순찰차를 타고 순회하는 중 창고 건물에서 연기가 나오는 것을 보았다. 동료 Lee 경관이 순찰차 안에 있는 컴퓨터를 이용 Report Emergency?기능을 구 동시킨다. 2. Lee 경관이 빌딩의 주소 및 위치를 간단히 기술한 후 응급 수준을 입력한다. 소방장비뿐만 아니라 응급처리를 위한 장비도 요청한다. 입력된 것을 재확인시키고 응답을 기다린다. 3. Dispatcher인 Park은 워크스테이션의 알람 기능에 의하여 응급 상황을 알게 된다. Lee 경관이 입력한 정보를 살펴본 후 보고로 회신한다. 소방장비와 응급장비를 Incident 사이트에 배정하고 예정된 도착시각을 Lee에게 알린다. 4. Lee 경관이 응답과 예정 도착시각을 받는다.

45. 사용사례 관계 • 통신 관계 • 액터와 사용사례 사이의 관계 • 선으로 표시 • 시스템의 기능을 접근하여 사용할 수 있음을 의미 • 포함 관계 • 복잡한 시스템에서 중복된 것을 줄이기 위한 방법 • 함수의 호출처럼 포함된 사용사례를 호출하는 의미 <<include>> OpenIncident HelpDispatcher <<include>> AllocateResources

46. 사용사례 관계 • 확장관계 • 예외 사항을 나타내는 관계 • 이벤트를 추가하여 다른 사례로 확장 • 포함관계와의 차이 • 화살표의 방향 • 공통적으로 가지는 기능을 나타낼 때는 포함관계 <<extend>> OpenIncident ConnectionDown <<extend>> AllocateResources

47. 일반화 관계 • 사용사례의 inheritance • 일반화/특수화 관계의 적용 • 유사한 사용사례를 모아 일반적인 사용사례 정의 Authenticate with Password Authenticate Authenticate with Card

48. 클래스 다이어그램 • UML의 중요한 요소 • 시스템의 골격을 나타냄 • 클래스 다이어그램을 구성하는 요소들 • 클래스와 객체 • 연관 관계와 링크 • 역할 • 다중도 • 연관 클래스 • 전체부분관계 • 일반화

49. Order Multiplicity: Mandatory Customer dateReceived isPrepaid number: String price: Money name address * 1 Class creditRating(): String Association dispatch() close() Generalization 1 {if Order.customer.creditRating is ‘poor”, then Order is prepaid must be true} Corporate Customer Personal Customer ContactName CreditRating CreditLimit CreditCard# Role name Attribute remind() billForMonth(integer) line items Multiplicity: Many-valued Operation * * Orderline Sales rep 0..1 quantity: Integer price: Money isSatisfied: Boolean Employee Multiplicity: Optional * 1 Product 클래스 다이어그램

50. 객 체 • 객체란 물체로 존재하거나 개념상 존재하는 엔티티들의 표현 • 구체적인 물체(예, 영철이의 차, 내 컴퓨터) • 개념(예, 구매 주문, 은행에서의 거래) • 범위가 잘 정의될 수 있고 의미가 뚜렷한 개념, 추상적인 것, 사물 Purchase Order, 001 UML notation for an Object