제 2 장 UML

2 Contents  UML 이란 ?  UML 역사와 역할  UML 구성요소 Things Relationships Diagrams  UML 확장  Summary

3 UML 이란 ?  UML 1) ? 객체지향 분석 / 설계 산물 (artifacts) 을 위한, 표준화된 notation  Not a method  Not a development process UML 은 모델링 언어의 통합을 위한 표준 UML 은 s/w 를 시각화, 명세화, 문서화하기 위한 언어  UML 은 시스템의 여러 분야를 포함 데이터 모델링 (Entity Relationship Diagram) 객체 모델링 Component 모델링 1) Unified Modeling Language

4 UML 역사 3 amigos Booch, Rumbaugh, Jarcobson 97 년 11 월 UML1.1 을 OMG 1) 표준 으로 승인 월. UML 1.4 발표 2004 년 12 월.UML 2.0 표준안으로 채택 1) Object Management Group

5 UML Model 시스템 UML 역할 시스템의 경계와 주요 기능 추 출 (Use Case, Actor) Use Case 설명 (Interaction Diagram) 시스템의 정적인 구조 표 현 (Class Diagram) 객체들의 행동 표현 (Statechart Diagram) 시스템의 물리적인 구조 표 현 (Component Diagram, Deployment Diagram) 다양한 형태의 확장 지 원 (Stereotype)

6 UML 구성요소  Things Structural: Actor, Use case, Class, Interface, Collaboration, Active class, Component, Node Behavioral: Interaction, State Machine Grouping: Package Annotation: Note  관계 (Relationships) Dependency, Association, Generalization, Realization

7 사용 사례 (Use Case) 사용 사례 (Use Case)  사용사례 시스템이 수행할 것으로 기대되는 기능 사용자 또는 시스템이나 기타 요소들이 시스템과 상호 작용하는 다이얼 로그를 모델링 액터에 의해 구동 구동된 후 발생되는 일연의 상호작용을 나타낸다는 의미에서 완전한 이벤트의 흐름  사용사례 다이어그램 구성 액터, 사용사례, 확장관계, 포함관계  사용사례 작성 과정 액터찾기 -> 시나리오 찾기 -> 사용사례 작성 -> 사용사례 사이의 관계 찾 기

8 액터 (Actor) 찾기  액 터 시스템과 작용하는 외부 엔티티 요구추출의 첫 단계 시스템에 자료를 입력만 할 수도 있음 시스템에서 정보를 받기만 할 수도 있음 자료를 주고 정보를 받을 수 있음 사람일 수도 있고 기계, 다른 시스템일 수도 있 음

9 Things: Actor  Actor 는 시스템의 사용자가 할 수 있는 역할 (Role) 을 표현한다.  Actor 는 시스템의 부분이 아니다.  개발할 시스템과 상호 작용하는 사람이나 객체 ( 시스 템 ) 등을 Actor 로 정의  Actor 는 시스템과 정보를 교환  UML 표기 Actor

10 Things: Actor -2  Actor 를 찾기 위한 질문들 누가 시스템을 사용하는가 ? 누가 시스템을 설치하는가 ? 누가 시스템을 시작시키는가 ? 누가 시스템을 유지하나 ? 누가 시스템을 끝내는가 ? 어떤 시스템들이 이 시스템을 사용하나 ? 이 시스템으로부터 누가 정보를 얻는가 ? 누가 시스템에 정보를 주는가 ? 시스템은 외부 자원을 사용하는가 ?

11 Things: Actor -3 은행원 ATM 시스템 ATM 관리자 은행 시스템 시스템 경계

12 시나리오 찾기  시나리오 사용 사례의 인스턴스 단일 액터의 관점으로 시스템의 단일 기능을 비정형적으로 표현  구체적인 상호작용 표현  시나리오의 사용 요구추출 과정 리엔지니어링 작업에서 시스템을 이해할 때 미래에 개발할 시스템에 대한 아이디어를 정리할 때 구현된 시스템을 평가할 때 교육을 위하여 단계적으로 사용 사례를 보여줄 때

13 시나리오 찾기 시나리오 이름 :normalRentVideo 참여액터 :lee: Clerk 스캐너를 이용 시작 조건 : 1. 점원 lee 가 터미널에서 " 비디오 대여 " 기능을 활성시킨다. 시스템이 고객 ID 입력양식을 화면에 제시하여 반응한다 사건의 흐름 : 2. 점원인 lee 가 비디오를 대여하려는 고객에게 전화번호의 끝 네자리를 물어 '1245' 를 입력한다 3. 입력한 네자리로 찾은 이름, ' 이동국 ', ' 김한국 ' 을 화면에 보여주고 맞는 것을 선택하도록 한다. 4. 고객이 ' 이동국 ' 이라는 것을 알려주어 선택한다. 5. 스캐너를 이용하여 대여하려는 비디오 ID('A ') 를 입력한다. 6. 스캔된 비디오 정보 ( 비디오 제목과 비디오 고유번호 ) 가 화면에 출력되고 대여중인 비디오 데이터베이스에 기록한다. 대여할 비디오가 더 있으면 반복한다. 종료 조건 : 7. lee 가 대여료를 받고 테이프를 건네준다.

14 사용사례 작성 사용사례 이름 :RentVideo 참여 액터 : User 에 의하여 구동됨 스캐너를 이용 시작 조건 : 1. User 가 터미널에서 " 비디오 대여 " 기능을 활성시킨다. 시스템이 고객 ID 입력양식을 화면에 제시하여 반응한다. 사건의 흐름 : 2. 점원인 User 가 비디오를 대여하려는 고객에게 전화번호의 끝 네자리를 물어 입력한다. 3. 입력한 네자리로 찾은 이름들을 화면에 보여주고 맞는 것을 선택하도록 한다. 4. 연체료가 있다면 화면에 출력하고 없으면 스캐너를 이용하여 대여하려는 비디오 ID 를 입력한다. 5. 비디오 ID 를 이용하여 비디오 정보를 찾아 화면에 출력하고 대여중인 비디오 데이터베이스에 기록한다. 대여할 비디오가 더 있으면 반복한다. 종료 조건 : 6. User 가 대여료를 받고 테이프를 건네준다

15 사용사례 관계  통신관계 액터와 사용사례 사이의 관계 정보의 흐름 표현 액터는 사용사례와 통신하는 다른 액터와 구별되어야 함 클래스의 기능을 어떤 액터가 접근할 수 있는지 접근제어 표현  확장관계 예외 사항을 나타내는 관계 이벤트를 추가하여 다른 사례로 확장 시작 조건과 종료 조건 필요

16 사용사례 관계  포함관계 사용사례 사이의 중복 제거 함수의 호출처럼 포함된 사용사례를 호출하는 의미  확장관계와 포함관계의 차이 관계의 방향 ( 화살표 방향 ) 포함관계 – 목표 사용사례가 구동되는 조건이 출발 사용사례에 기술 확장관계 – 확장이 적용되는 조건이 확장 사용사례의 시작조건으로 기 술 예외적이며 선택적이며 거의 발생하지 않는 경우는 확장을 사용 두 개 이상의 사용사례가 공유하는 동작은 포함관계를 사용

17 사용사례 관계 Manager Clerk Edit Customer Profile Parental authorization Pay Late Fees Get Video ID Type ID Scan Barcode Add Videos Retire Videos Rent Videos Return Videos Sell Videos >

18 클래스 ( Class)  동일한 객체들의 속성을 기술한 자료형 (type)  Class 구성요소 : Name, Attributes, Methods  UML 표기 Class Name Attribute 1 Attribute 2 … Method1 Method2 … - 필요에 따라 attribute 부분과 method 부분을 생 략하게 그릴 수 있음 [Rational Rose 에서의 모습 ]

19 객체 모델링  객체 모델링 사용사례를 작성하여 도메인 분석이 어느 정도 된 후 객체를 찾고 관 계를 정의하는 작업  클래스가 될 수 있는 요소들 - 구조 - 외부 시스템 - 디바이스 - 역할 - 운용절차 - 장소 - 조직 - 완성된 시스템에 의하여 조작되어야 할 정보  클래스 후보의 세가지 유형 엔티티 클래스 경계 클래스 제어 클래스

20 엔티티 클래스  엔티티 클래스 시스템에서 계속 추적해야 할 자료가 들어 있는 클래스  엔티티 클래스를 발견하는 휴리스틱 사용사례를 이해하기 위하여 사용자와 개발자가 명확히 규정된 용어 사용사례에서 반복되어 나오는 용어 시스템이 계속 추적하여야 하는 실세계의 엔티티 자료저장소 또는 단말 자주 사용하는 응용 도메인의 용어

21 경계 클래스  시스템 외부의 액터와 상호 작용하는 클래 스로 사용자 인터페이스를 제어하는 역할  액터와 연결된 시스템의 인터페이스 표현  사용자 인터페이스를 개괄적으로 모형화

22 제어 클래스  경계 클래스와 엔티티 클래스 사이에 중간 역할  사용 사례의 초기에 생성되고 끝까지 존재  경계 클래스로부터 정보를 받아 엔티티 클래스에 전달 예 ) 양식의 순서, undo, 히스토리 저장 큐 등  자료를 다른 클래스로부터 받아 처리하는 것이 주임무인 클 래스

23 Things: Packages  Packages? Package 는 구성 요소들을 묶는 역할 담당 Class 들을 Package 로 묶어서 모델을 단순하고 식별이 용 이하게 함 Package 는 명확한 기준이 있으면 어떻게 나누어도 상관없 음  UML 표기 Package name

24 Relationships  Dependency 어떤 모델링 element 에서의 한 변화가 다른 것에 영 향을 주는 관계 ( 역은 성립할 필요 없음 )  Generalization superclass(parent) 와 subclass(child) “is-a-kind-of” 관계, 상속 (Inheritance) 관계 parent 가 사용되는 곳이면 어디든 child 도 사용가능 or

25 Relationships -2  Association 클래스간의 의미적 연결 연관관계의 이름은 동사 (or 동사구 ) 로 표현  예 : ‘ 철수라는 사원이 회사에서 일한다.’ 고 할 때 ‘ 일한다 ’ 가 사원과 회사라는 클래스간의 연관 관계를 나타낸다. 일반적으로 Binary Association, n-ary 도 가능 구성요소 : Name, Role, Multiplicity 0..1 * employeremployee employ

26 Relationships -3 Realization 하나의 Class(or Component) 가 특정 Interface 의 operation 들을 실현시키는 관계 Aggregation “has-a” relationship (“whole/part”) special kind of association

27 The 4+1 View 모델 Process view Deployment view Component view Logical view Use case view End user - Functionality - VocabularyProgrammers - Software management Analysts/Testers - Behavior System integrators - Performance - Scalability - Throughput System engineers - System topology - Delivery and installation - Communication Implementation View Process (Task), Thread

28 The 4+1 View 모델 -2  Logical view includes subsystems and classes. Related Area  functional requirements Static aspects  class diagram, object diagram  Implementation view includes components and files. Related Area  configuration management Static aspects  component diagram

29 The 4+1 View 모델 -3  Process view include tasks, threads and processes. Related Area  performance, scalability, throughput Static aspects  class diagram, object diagram  Deployment view includes executable and computing node Related Area  distribution, delivery, installation Static aspects  deployment diagram

30 The 4+1 View 모델 -4  Use case view includes use cases and actors Related Area  requirements Static aspects  use case diagram  Dynamic aspects of all views represented by interaction diagram, statechart diagram and activity diagram.

31 UML 구성요소 -2  다이어그램 (Diagrams) Use case diagram Class diagram Sequence diagram Collaboration diagram Statechart diagram Activity diagram Component diagram Deployment diagram Interaction diagram

32 Diagrams: 예제 시스템 요구사항  수강신청 프로그램 학기초에 학생들은 그 학기에 개설되는 과목 목록을 요청할 수 있다. 각 과목에 대한 정보 ( 교수, 학과, 선수과목 ) 가 수강 신청에 도움을 주기 위 하여 학생들에게 제공된다. 새로운 시스템에서 학생은 다음 학기에 대해 4 개의 필수 과목과 2 개의 선택 과목을 등록할 수 있다. 단, 한 과목은 10 명의 학생을 초과할 수 없 고 3 명 미만의 과목도 개설될 수 없다. 즉, 3 명 미만의 과목은 취소된다. 일단 한 학생에 대한 등록이 끝나면 시스템은 정보를 회계 시스템으로 보내어 학생에게 그 학기에 대한 청구서를 보낼 수 있게 한다. 교수들은 온라인 시스템에 접근하여 자신이 강의할 과목을 지정한다. 그 리고 교수들은 자신의 과목에 등록한 학생들을 볼 수 있다. 각 학기에 대하여 학생이 자신의 수강신청을 변경할 수 있는 기간이 있 으며 학생들은 이 기간동안에 과목을 추가하거나 삭제할 수 있다. Actor 들은 ? Use Cases ?

33 Diagrams: Use Case diagram  Actor 와 Use Case 의 관계를 도식화 Student Maintain Schedule Billing System Professor Request Course Roster Registrar Maintain Curriculum

34 Diagrams: Sequence diagram  시간 순서대로 객체 상호작용을 표시 : 학생 등록 양식 등록 관리자 수학 1: 등록정보입력 2: 제출 3: 과목 추가 ( 철수, 수학 ) 4: 개설했나 ? 5: 추가 ( 철수 )

35 Diagrams: Collaboration diagram  객체 관점에서 객체들의 상호작용과 그들의 관계를 표시 : 학생 등록 양식 등록관리자 수학 1: 등록정보 입력 2: 제출 3: 과목에 학생추가 ( 철수, 수학 ) 4 : 개설했나 ? 5 : 추가 ( 철수 )

36 Diagrams: Class diagram  Class diagram 은 시스템의 논리적인 관점에서 Class 들과 Class 들 간의 관계를 표시  Class diagram 의 요소 클래스와 그들의 구조 및 행위 클래스들 간의 관계  Association  Aggregation  Dependency  Inheritance 개수와 상호 참조 표시자 (Multiplicity and navigation indicators) 역할 이름 (Role names)

37 Diagrams: Class diagram -2 RegistrationForm RegistrationManager Course Student CourseOffering Professor addStudent(Course, StudentInfo) name numberCredits open() addStudent(StudentInfo) major location open() addStudent(StudentInfo) tenureStatus ScheduleAlgorithm name RegistrationUser 1.. * *

38 Diagrams: State chart diagram  State chart diagram? Class(or Object) 들의 개별적 동적 행동 (dynamic behavior) 을 기술한다. 클래스의 이력 (life history), 상태 전이를 일으킨 사건 (event), 상태 변화 결과인 동작 (action) 을 표시 중요한 동적 행위를 가진 클래스들을 대상으로 작성

39 Diagrams: State chart diagram -2 Initialization Open entry: Register student exit: Increment count Closed Canceled do: Initialize course do: Finalize course do: Notify registered students Add Student / Set count = 0 Add student[ count < 10 ] [ count = 10 ] Cancel  COURSE 객체의 State chart diagram

40 Diagrams: Activity diagram  한 시스템 (or Class) 내에서의 활동의 흐름 기술 Flowchart 와 유사 Statechart 는 State 중심으로 기술, Activity diagram 은 Activity 를 중심으로 기술

41 Diagrams: Component diagram  소프트웨어의 물리적인 구조와 Component 사이의 의존 관계를 표시  Component 의 형태 Source code(.h,.cpp, …) Run-time library(.dll) 실행 파일 (Executable file) (.exe) component interface dependency compilation dependency

42 Diagrams: Component diagram -2 Course Offering Student Professor Course.dll People.dll Course User Register.exe Billing.exe Billing System

43 Diagrams: Deployment diagram  Deployment diagram? Node (Hardware component) 들과 그 곳에서 운 영될 소프트웨어 구성 요소들을 표시 전체 시스템 구성 요소들의 배치 상황을 시각화 한다

44 Diagrams: Deployment diagram -2 Registration System Library Dorm Main Building Registration interface Registration interface Registration interface Registration manager University DB node interface component dependency

45 UML 확장  Stereotype 을 사용하여 사용자 정의 타입이나 아이템 을 생성하여 UML 을 확장  Stereotype 은 주로 Relationship, Class, Component 를 확장하는데 이용  Example (built-in stereotypes) Class Stereotypes: boundary, control, entity, utility, exception, … (  표기도 따라 변하는 경우도 있음 ) Relationship Stereotypes: uses, extends, … Component Stereotypes: subsystem, …