개요
요구사항과 관련해서 단순히 전부 적고 끝내는 것이 아니라, 어떤 요구 사항이 언제 들어왔고 사라졌는지에 관한 세부적인 내용도 관리를 해야한다.
기능 요구사항(Functional requirements)으로는 use case diagrams를, 모든 유형의 요구사항(All types of requirements)으로는 separate requirement lists를 작성하면 된다.
위의 두 작업까지 하면 specification이 끝나고 design을 할 차례가 된다.
Use Case Diagram 그리기
Use Case Diagram을 처음 보면 상당히 복잡한 형태로 그려져 있다고 느껴진다.
마치 시스템이 내부적으로 어떻게 돌아가는지 까지 다 그린 것 같은 느낌이지만, Use Case Diagram을 그릴 때는 내부에서 어떻게 동작하는지는 묘사하지 않고 외부에서 어떻게 의사소통 하는 지만 만든다.
그러면 어디까지가 내부? 외부?
내부와 외부의 경계가 약간 모호한 면이 있다.
사실 이를 정확하게 나누는 규칙이나 공식이 있는 것이 아니라 사람마다 약간의 편차가 발생할 수는 있다.
그렇다고 누가 옳고 그른 것은 없고, 정당한 사유가 있다면 각자의 Use Case Diagram이 된다.
그럼에도 약간의 가이드라인을 정해보면, 서비스에서 제공하는 기능들을 외부, 그리고 그걸 어떻게 구현했는지는 내부라고 생각하면 첫 거름망으로 사용하기엔 좋다.
외부 예시
- 로그인 하기
- 로그아웃 하기
- 회원가입하기
내부 예시
- 어떤 언어로 개발
- 어떤 OS에서 동작
- 어떤 DB를 사용했는지
유저들은 서비스에서 제공하는 기능들을 사용하면서
“와우 이건 C++로 만들었나요? 굉장히 최적화가 잘 되어있네요~” ▼
라는 말을 하지 않는다.
보통 이런 말을 하는 것은 자기가 프로그래머임을 과시하고 싶은 사람이다.
클라이언트에게 이걸 보여줬는데 클라이언트가 프로그래머가 아니면 못알아듣게 된다.
우리가 필요한 것은 사용자들이 직접 사용하는 외부적인 기능 묘사인 것이다.
Notation of Use Case Diagrams
Use Case
Use Case는 사용자가 사용하는 것을 말한다.
즉, 기능을 말한다.
“~~하기” 의 형태, 동사형으로 표현을 한다. ▼
Actor
Actor는 시스템 밖에서 Use Case를 사용하는 존재를 말한다.
외부의 모든 것을 actor라고 한다.
스틱맨으로 표현을 한다.
이 Use Case를 사용할 때 외부의 스틱맨의 역할을 표현한다. (Actor = role)▼
이런 역할을 가진애가 이런 Use Case를 사용한다는 말이 된다. ▼
위에서 Actor를 Use Case를 사용하는 “존재”라고 한 이유는 꼭 사람만을 이야기하는건 아니고 시스템이나 기기의 역할을 말하기도 하기 때문이다.
시스템과 상호작용하는 외부 디바이스들도 포함한다.
우리 시스템과 인터랙션하는 모든 외부의 요소들을 actor라고 하고 role로 표현한다.
비회원, 회원 등등 모두 역할이 될 수 있다.
이벤트를 Actor로 표현할 때도 있다.
그런데 이벤트를 Actor라고 하기에는 약간 모호하다.
뚜렷하게 어떤 사람, 어떤 것이 아니라 하나의 현상이기 때문이다.
그래서 이런 이유로 Actor라고 표현을 안할수도 있는데, 사실 Actor로 표현하는 방법 말고 더 좋은 방법이 없기에 이렇게 사용한다고 한다.
Subsystem
Use case를 모아서 어떤 기능을 한다는 그룹화를 말한다.
직사각형으로 표현하며, 직사각형 안에 Use case의 그룹을 넣으면 된다.▼
그렇다고 한 사각형 안에 다 빽빽하게 넣으면 보기 안좋다.
그래서 가장 먼저 소프트웨어 아키텍쳐라는 가장 큰 그림을 그리고, 각 서브시스템 하나하나에 use case를 그리면 더 가독성 있게 계층적으로 표현할 수 있다.
Communication associations
Actor 와 Use Case를 이어주는 선을 말한다.
화살표는 그려도 좋고, 안그려도 괜찮다.
그러나 누가 먼저 커뮤니케이션을 시작했냐를 나타내기 위해서는 화살표가 필요하기도 하다.
지금까지 본 Notation들 예제
어카운턴트가 액터.
그리고 액터가 4가지 use case를 먼저 실행함.
그리고 이 4가지를 엮어놓은게 Staff Management.
이 4가지 일을 하는 사람이 어카운턴트다~
Dependencies
use case 간의 관계를 표현한 것을 말한다.
관계는 크게 Extend와 Include의 두 가지 관계가 있다.
이 둘은 하나의 Stereotype으로 stereotype의 뜻은 일반적으로 고정관념이지만, 여기서는 하나의 틀과 형태로 보면 된다.
즉, 특정 목적으로만 사용할 수 있게 만든 것이다.
이들을 표기할 때는 guillemets라는 기호와 점선 화살표를 이용한다..
«extend» and «include»
«extend» and «include»를 보면, UML에서 stereotype으로 표현해놓은것이라고 이해하면 된다.
Extend relationship
중간의 관계를 extend sterotype으로 표현한다.
관계를 표현한다고는 했지만, 실제 사용되는 용도는 옵션의 표기에 가깝다.
이걸 해도 되고, 안해도 괜찮은, 연쇄적으로 필연적으로 일어나지 않는 Use Case에 표기한다. ▼
위의 예시를 보면, 아래에 출력버튼이 있음에도 고라니 TMI만 보고 나갈 수도 있다.
출력은 눌러도, 안눌러도 그만이다.
이와 같은 요소를 «extend»로 표현한다.
또 다른 이해로는 서브를 통한 메인의 확장이다.
프린트 기능을 넣음으로 기본 기능을 확장 시킨 것이라고 이해하는 것도 좋다.
옆의 노트는 언제 옵션이 일어나는지 컨디션을 적은것인데, 필수로 기술해야하는 영역은 아니다. ▼
그럼에도 이 use case는 액터와 연결이 되어야한다.
연결이 안되어있다면 아무도 안쓰는 것이고, 아무도 안쓰는 기능은 만들 필요가 없으므로 기술을 할 이유가 없다.
위에 프린트도 직접 연결은 아니지만 간접 연결이 되어있는 것을 알 수 있으므로, 어떻게든 연결이 되어야한다.
주의사항으로는 앞에서도 언급했지만 Use Case는 사용자 관점이므로 내부적인 이야기를 기술하면 안된다. ▼
Include relationship
고라니에게 일을 할당시켜 일하게 만든다고 해보자.
그런데, 아주 당연한 이야기지만, 일을 시키기 위해서는 시킬 일이 필요하다.
그렇기에 우선 할 일들을 찾아야 한다.
이런 흐름으로 보면 일을 할당하는 행위 이전에 선행되는 행위로 할당시킬 일을 찾는 행위가 등장한다.
이렇게 선행되는 일을 하는 것을 «include»로 표현한다.
일 할당이라는 일 내부에는 할당시킬 일 찾기가 있으므로, 일 할당이 할당시킬 일 찾기를 «include» 한다고 볼 수 있는 것이다. ▼
하지만 하나씩만 «include»하는 경우엔 include는 생략한다.
«include»가 하나만 있다면 이는 다른 방식으로의 묘사가 아니라 잘못 만들어진 것이다.
중요한 부분
«extend»는 사용자에게 옵션이지만, 개발자에게는 옵션이 아니다.
누군가는 개발을 해야한다.
«extend»자체는 개발자에겐 핵심이기에, 개발할 때 생략하면 안된다.
하지만 «include»는 없어도 괜찮다.
묘사를 덜 한 것일 뿐이고, 핵심 자체는 아니기에 «include»없이도 핵심 표현이 가능하다.
추가로 주의를 해야하는 것으로는 «include»는 포함관계 표현 용도로만 쓰면 안된다는 것이고,
«extend»는 실행순서 표현 용도로만 쓰면 안된다는 것이다. ▼
Generalization
Use Case나 Actor 중에서 공통된 것을 추출하여 Super-Use Case와 Super-Actor를 만든 것을 말한다.
조금 더 쉽게 말하면, 공통된 부분을 상위 계층으로 올려버리는 것을 말한다.
Common funtionality = super-use-case
Common role = super actor
학생과 교수가 있으면 공통점은 사람이고,
그럼 학생과 교수는 사람이라는 요소를 상속받는다.
삼각형 화살표를 이용하여 묘사하는데, 삼각형의 의미는 IS-A다.
IS-A는 a kind of 로 생각하면 좋다고 이전 포스트에서 이야기했었다.
아래 두개의 기능을 개발한다고 해보자. (Assign~ 으로 시작하는 두 기능)
두 기능을 만들기 위해 요구사항을 보니 Assign이 공통된다는 것을 알았고, 이를 Super Use Case로 만들어버렸다.
사실 Super Use Case는 없어도 괜찮다.
Super-Use Case가 없어도 내용이 달라지진 않기 때문이다.
어떻게 보면 «include»와 비슷한 느낌이지만, 둘은 차이점이 명확하다.
다른 예제를 보자. ▼
(삽화 자리)
위의 그림에서의 Generalization은 (isa) 아무 의미가 없다.
그런데 아무 의미 없는 걸 왜 그린 것일까?
이는 다른 데에 추가적인 정보가 있다는 의미라는 것으로 사용한 것이다.
사실 이렇게 묘사하는건 좋지는 않지만, 아무런 의미가 없는 듯한 IS-A에도 의미가 내포될 수 있다.
예제
교수가 학생들에게 과제를 낸다고 해보자.
가장 먼저 할 것은 과제 생성으로 교수가 하는 것이다.
use case = 과제 생성, role = 교수
그다음에 할 것은 과제 제출로 학생이 하는 것이다.
use case = 과제 제출, role = 학생
그런데 위의 두 Use Case를 하기 위해서는 둘이 공통적으로 해야하는 것이 있다.
바로 로그인이다.
use case = 로그인, role = 교수, 학생
이렇게 만들고 나니 use case랑 role이랑 잘 안맞는 느낌이 든다.
학생과 교수라는 역할이 로그인을 하는 역할이라고 하기엔 조금 맞지 않는 느낌이 든다.
그럼 이제 둘의 공통점을 찾아보자.
둘 다 아이디와 패스워드가 있고, 로그인은 회원이라는 역할로 로그인을 한다.
그리고 회원은 교수와 학생, 이렇게 둘이 있으니 아래와 같이 표현이 된다.
use case = 로그인, role = 회원
추가로 게스트라는 역할이 있다고 해보자.
게스트는 회원이 아니기 때문에 둘러보기밖에 못한다.
use case = 둘러보기, role = 게스트
로그인 하는 애들중에 공통적인 걸 하는 애들도 있을거이다.
걔네를 모아주는게 Generalization이라고 생각한다.
마치며
내용이 조금 빠져 다음에 더 추가를 해야겠다.
'CS > 소프트웨어 공학' 카테고리의 다른 글
| 11. 다형성(Polymorphism) 예제 (0) | 2024.01.31 |
|---|---|
| 10. 객체 지향 프로그래밍 (Object-Orientation Programming) (0) | 2024.01.31 |
| 8. 요구사항 포착 (0) | 2024.01.26 |
| 7. Modeling Concepts (0) | 2024.01.26 |
| 6. Agile (0) | 2024.01.21 |
