1. Use case diagram
- text 형태의 use case(이게 메인임)를 보조하는 수준으로 쓰일 수 있다.
- 간단하고 심플한 그림을 활용한다.
- 시스템은 네모를 사용
- use case는 동그라미 사용
- actor는 보통 stick man을 많이 사용한다.
- actor와 use case는 반드시 연결되어야 하고 1..3처럼 여러명과의 관계를 나타낼수도 있다.
2. <<include>>
- use cases간에 관계가 존재한다면 <<include>> 표기를 한다.
- 서로 다른 두 use cases가 동일한 behavior를 가질 수 있기 때문에 <<include>>를 활용한다. (중복 제거)
- actor가 강의를 공지하고 싶어 한다. : Announce lecture use case를 성공적으로 마치기 위해서는 assign lecturer usercase 작업을 수행해야 한다.
- actor가 강의자를 할당하고 싶다 : assign lecturer use case 실행
- 즉 여기서 Announce lecture를 base use case라고 하고 assign lecturer가 included use case라고 한다. 강의를 공지 use case는 강의자 할당 use case를 내포하고 있다. 물론 강의자 할당 use case 단독으로 수행할수도 있다.
- 여기서 actor와 included use case를 연결하는 선이 없으면 base use case 를 수행하다 included로 갔다가 base로 돌아오는 작업이 된다. (base를 연결하는 선은 없어서는 안된다.)
- 여러 use case가 공유하는 공통 부분(use case)을 재사용하기 쉽게 만드는 방법이다.
- process sale과 process rental은 서로 공통된 use case를 include하고 있다.
3. <<extends>>
- 주어진 usecase를 변경하지 않으면서 확장해 사용하고 싶다면 <<extend>>를 사용한다.
- 사용자가 lecture hall을 예약하고 싶다 : Reserve lecture hall use case를 수행한다.
- 사용자가 announce exam을 예약하고 싶다 : announce exam use case를 수행한다.
- 사용자가 announce lecture를 수행하고 싶다 : announce lecture use case를 수행하다가 확장한 Reserve lecture hall, announce exam을 둘다 수행하고 돌아온다.
- 화살표 의미를 헷갈리면 안된다. actor가 A를 수행하려고 하면 B를 수행해야 한다는 것이다. "A는 B를 확장한 것이다"라는 뜻이다.
- 여기서 actor와 B를 연결하는 선이 없으면 A를 수행하다 B로 갔다가 A로 돌아오는 작업이 된다. (A를 연결하는 선은 없어서는 안된다.)
4. {abstract}
- 상속하는 관계를 나타낸다.
- 재활용할 거리가 있는 base use case(A)들을 상속해서 여러 sub use case(B)를 만들 수 있다.
- Announce event : announce lecture 실행 -> announce exam 실행
- Announce exam : announce exam 실행
- 보통 A는 template용도로만 사용된다. A를 상속하고 있는 B를 실행한다.
- A는 템플릿이기 때문에 따로 실행할수는 없다. 반드시 상속하는 sub use case가 있어야 한다.
5. relationship
- 사용자끼리의 상속관계도 있다. A는 B를 상속하고 있고 A는 B의 모든 권한을 갖는다.
- 좌측은 query student를 실행하기 위해 professor, assistant 모두 필요하다는 뜻이다.
- 우측은 professor, assistant 모두 각각 query student data가 가능하다는 뜻이다. (abstract로 interface를 정의해서 사용하고 있음)
6. 잘못된 예시
- 마지막으로 잘못된 예시 몇개만 살펴보자.
- relationship은 work flow가 아니다. 헷갈리지 말자
- actor가 system안에 있음
- or 관계가 아니라 and 관계다 의미를 헷갈리지 말자
- use case의 목적은 요구사항 파악이다 너무 잘게 구현을 다루는 내용들로 나누지 말자 (과한 decomposition을 피하라)
7. 정리
'ComputerScience > Software Engineering' 카테고리의 다른 글
소프트웨어공학 - 9. Class diagram -> Code Generation (0) | 2022.04.06 |
---|---|
소프트웨어공학 - 8. UML Class diagram (0) | 2022.03.31 |
소프트웨어공학 - 6. Requirement, Use cases (0) | 2022.03.17 |
소프트웨어공학 - 5. Iterative, Evolutionary, Agile (0) | 2022.03.16 |
소프트웨어공학 - 4. OOA/D(Object Oriented Analysis & Design) (0) | 2022.03.16 |