1. Class Diagram 2. Activity Diagram 3. Object Diagram

1. krns@etri.re.kr
“ Electronics and Telecommunication Research Institute ”
Class / Activity / Object Diagram
정승화

2. 2
Class Diagram
▣기본 구성 단위인 클래스와 그들간의 관계를 정의한다.
▣정적인 관점에서 클래스 구조를 표현한다.
▣목적:
◈클래스 정의
◈속성/오퍼레이션 정의 (자바: 필드/메소드 정의)
◈클래스들간의 관계 정의

3. 3
Class Diagram
▣클래스의 단순형 표현
▣클래스의 정규형 표현
◈A  B (내 관점) (B는 A를 모름) (A는 B가 보임 = 참조함)
클래스 이름
클래스 이름
속성
오퍼레이션

4. 4
Class Diagram
▣정규형 표현 규칙
◈클래스 이름
◈속성
필드 명
필드 명 : 타입
필드 명 : 타입 = 디폴트 값
◈오퍼레이션
메소드 명
메소드 명 ( 인수 타입들 )
메소드 명 ( 인수 타입들 ) : 리턴 타입
 인수 타입 포맷 = 인수 명 : 타입
+ : public
- : private
# : protected
클래스 이름
+ 오퍼레이션
클래스 이름
+ 속성

5. 5
Class Diagram
▣Multiplicity (사용하고자 하는 개체의 수)
예: 1 과목당 선수과목이 0개 혹은 다수 존재한다.

6. 6
Class Diagram
▣ Multiplicity (사용하고자 하는 개체의 수)
1. 교수는 과목을 3개 강의해야 한다.
2. 학생은 과목을 수강하지 않거나 4개까지 수강할 수 있다.
3. 한 과목당 적어도 3명 많으면 10명까지 수강할 수 있다.

7. 7
Class Diagram
▣Aggregation (두 클래스가 전체-부분 관계 일 때)
◈각 클래스가 독립적인 생명 주기를 가진다.
전체 클래스가 소멸하더라도 부분 클래스가 존재할 수 있을 때
class 바퀴
{ ... }
class 자동차
{ 바퀴[] 필드 명[4] }

8. 8
Class Diagram
▣Composition (두 클래스가 부분-전체 관계 일 때)
◈부분 클래스의 생명 주기가 전체 클래스의 영향을 받는다.
전체 클래스가 소멸할 때 부분 클래스도 함께 소멸할 때

9. 9
Class Diagram
▣Generalization (두 클래스가 상속의 관계에 있음)
◈Abstract Class를 상속받을 때
abstract class 결재
{ ... }
class 현금 결재 extends 결재
{ ... }
결재
현금 결재 카드 결재

10. 10
Class Diagram
▣Realization (두 클래스가 선언-구현의 관계를 가짐)
◈Interface를 상속받을 때
interface 결재
{ ... }
class 현금 결재 implements 결재
{ ... }
<<interface>>
결재
현금 결재 카드 결재

11. 11
Class Diagram
▣Dependency (클래스의 생성/소멸이 있는 종속적 관계)
◈한쪽 클래스가 실행 도중 다른 쪽 클래스의 실행을 요청
주로 메소드 내 인수나 지역 변수로 사용될 경우
Class
Professor
Lecture ( Class )

12. 12
Class Diagram
▣Association (두 클래스 간의 일반적인 협력 관계)
◈화살표가 없을 때
보통 분석 단계에서 아직 참조 방향이 결정되지 않은 상태
 의미적인 관련성만을 표현할 때
 양쪽 다 참조 가능할 때

13. 13
Class Diagram
▣Association (두 클래스 간의 일반적인 협력 관계)
◈Association Name
◈Multiple Association
사람 교과목
수강하다
강의하다
. . .
사람 교과목
수강하다
강의하다
. . .

14. 14
Class Diagram
▣클래스 다이어그램 예:
◈병원업무 자동화 시스템 (Conceptual Level)
 진료비는 진료정보를 입력하면 자동 산정됩니다.
 환자는 진료 예약을 하고, 환자의 과거병력과 진료정보는 관리됩니다.
 일반사용자는 병원 정보와 의료진 정보를 조회하고 상담 및 문의를 할 수 있
습니다.
 의료진은 자신의 진료 스케줄을 자동 생성하고, 진료 내역을 관리하고, 환
자 정보를 조회하기를 원합니다.
 원무과 직원은 이 시스템을 통해 진료비 청구서를 조회, 발행하고, 진료예약
을 확정하기를 원합니다.
◈ 사용 클래스:
 질병, 병력, 환자, 진료예약, 진료비, 진료, 의료진, 간호사, 의사

15. 15
Class Diagram

16. 16
Class Diagram

17. 17
Activity Diagram
▣일의 수행 순서와 처리 흐름 모델링 한다.
▣조건과 상태에 따른 필요 상황을 알 수 있다.
▣목적:
◈처리 순서의 표현
◈처리 흐름의 도식화 (프로그램의 로직 정의 가능)

18. 18
Activity Diagram
▣Action (무언가 동작하는 행위를 표현)
◈ “- 한다.”로 설명될 수 있는 행위이다.
▣State (시스템의 현재 도달된 상태)
◈Action에 비해 모서리가 덜 둥글다.
◈잘 사용되지 않는다.
슈퍼에 간다.
슈퍼 도착

19. 19
Activity Diagram
▣Start/End (시작과 끝이 명확)
◈하나의 시작 상태만 가질 수 있다.
◈종료 상태의 개수 제한은 없다.
▣Decision (Branch: 2개 이상 분기 가능)
◈결정에 맞는 Action (활동)으로 간다.
◈각 분기에 대한 설명을 적어준다.
파일이 있을 때
파일이 없을 때

20. 20
Activity Diagram
▣Synchronization Bar (병렬 처리)
◈같은 등급의 일들이 시작되거나 모일 때 사용
예:

21. 21
Activity Diagram
▣Transition
◈하나의 Activity가 행위를 완료하고 다른 Activity로 처리 순서
가 옮겨지는 제어 흐름을 표현
◈하나의 Action/State 에서 여러 개로 분기 될 수 있음
단 이때 각 분기에 대한 설명을 적어 주어야 함
저녁을 결정한다.
시켜먹는다.
요리한다.

22. 22
Activity Diagram
▣Swim Lane (도메인 별 구분)
◈Activity Diagram의 가독성을 증가시킨다.
예:
Domain 1 Domain 2 Domain 3

23. 23
Activity Diagram

24. 24
Object Diagram
▣Object Diagram 은 클래스 대신 인스턴스들을 보여준다.
◈복잡한 관계의 작은 조각들을 설명할 때 유용하다.
▣Object Diagram 은 특정 순간의 시스템 모델 구조의 전
체 또는 부분의 구조를 보여준다.
예: 한 대학의 학과가 많은 다른 과들을 포함 할 수 있다는 것을 보
여주는 Class Diagram

25. 25
Object Diagram
▣ 앞의 예제로 나온 클래스 다이어그램을 구체적인 예제로 변경
▣ Object Diagram의 각 네모는 개개의 인스턴스를 나타낸다.
◈ UML 표기에서 인스턴스 이름은 밑줄 침
◈ 다이어그램의 의미가 명확하다면 클래스나 인스턴스 이름은 생략 가능

26. 26
Class Diagram
Object Diagram

27. 27
Object Diagram

28. 28
Object Diagram

29. 29
설계 단계 (Class Diagram)
1. Conceptual level
◈ 개발범위에 속해있는 문제영역에 대해 단순한 관계를 도출하는데 중점
◈ 업무 관점의 class 들만 도출하고, 구현에 관련된 시각은 최대한으로
배제
2. Specification level
◈ 구현관점을 살려 모델링을 수행
◈ 어떻게 코딩 할 건지에 대한 관점을 배제
◈ 클래스의 속성과 오퍼레이션을 될 수 있는 한 상세히 정의하고, 구체적
인 플랫폼(개발언어의 특성 등)특성을 반영하지 않음
3. Implementation level
◈ 언어와 개발플랫폼이 가진 특성 및 제한 사항을 반영
◈ 정의된 class를 보고 정해진 개발언어로 개발자가 코딩을 하기에 충분
한 정보를 모두 표현

30. 30
작성 단계 (Class Diagram)
1. 객체를 식별하고 클래스를 정의
◈ 사용자 문서나 유즈케이스 정의서, 문제 기술서 등을 참고하여 객체를 식별
◈ 식별된 객체를 바탕으로 클래스를 정의
◈ 이 단계에서는 클래스 명 정도만 표현
2. 속성과 오퍼레이션을 정의
◈ 클래스의 속성과 오퍼레이션을 정의
◈ 한번에 상세한 정의를 마치지 못하므로 여러 번 정제과정을 거쳐야 함
3. 클래스간 관계를 정의
◈ 클래스와 클래스간 관계를 정의
◈ 관계의 종류를 결정하고, 관계 명을 부여
◈ 관계 수를 정의
4. 정제과정을 반복
◈ 클래스 다이어그램은 분석과 설계 과정에서 지속적으로 정제 필요
◈ 다른 모델을 작성하는 과정에 새로운 클래스가 추가되기도 하고, 관계가 변경되기도 함

31. 31
주의 사항 (Class Diagram)
▣ 모델의 단순성을 유지
◈ 불필요하게 복잡한 클래스 다이어그램이 되지 않도록 단순성을 유지하는 것이 좋음
◈ UML을 너무 적게 쓰는 것이 너무 많이 쓰는 것 보다 낳음
▣ 의미 있는 이름을 부여
◈ 클래스 명, 속성 명, 오퍼레이션 명, 관계 명 등은 직관적으로 의미가 이해될 수 있도록 의미
있는 이름으로 정해야 함
◈ 명칭은 모호하지 말아야 하고 명확해야 함
▣ 포인터나 레퍼런스는 Association으로 대신
◈ Association은 그 자체가 상대 클래스의 인스턴스에 대한 포인터나 레퍼런스의 의미를 이미
가지고 있기 때문에 별도로 정의할 필요가 없음
▣ 여러 클래스가 동시에 관계를 가지는 Association의 경우,
이를 둘 간의 관계로 분리
◈ 세 클래스 이상이 한꺼번에 관계를 가지는 것은 가능하지만 이는 구현과정이 어렵기 때문에
두 클래스의 관계로 분리하는 것이 좋음
▣ 관계 수는 복잡하지 않게 정의
▣ 객체모델은 많은 반복 작업을 통하여 완성됨
◈ 빈번한 클래스 다이어그램의 수정을 두려워하지 않도록 해야 함
◈ 클래스 다이어그램은 많은 반복 작업을 통하여 완성되는 것임을 명심