수정입니다
Use-case & Use-case Diagram 본문
Use Case => actor가 goal을 성취하기 위한 text story, 그 scenario들의 집합
Three Kinds of Actors
- Primary Actor : user goal을 가진 actor
- Supporting Actor : system에 service를 제공하는 actor
- Offstage Actor : 직접적인 interaction은 없지만, scenario와 연관이 있음
Three Common Use Case Formats
- Brief : main success scenario or happy path만 표현하는 방식
- Casual : 여러 다양한 scenario 포함 (alternate scenario도)
- Fully Dressed : 모든 step을 다 포함
What Do the Section Mean?
- Scope : design을 어디까지 할건지, 바운더리
- Level : user goal 다 할건지, 일부만 할건지
- Primary Actor
- Stakeholders and Interests list : 이 use case가 뭘하는건지 주요 관심사/actor가 뭐 하고싶은지
- Preconditions and Success Guarantees(Post Condition)
- => 선행조건이 만족하지 않으면 유스케이스의 동작이 시작x
- => 정상 동작에 대한 최소한의 판단 기준(그러나 이게 만족 됐다고 정상동작한다는 보장 x)
- Main success scenario : happy path
- Extensions(or Alternate flow)
- => main + exten ==> 거의 모든 stakeholers의 interest를 만족시켜야함
Valid use case 찾는 법
- The Boss test => real measurable value를 산출할만한 크기여야함
- The EBP test => 한 사람이 맡을만한 크기여야함
- The Size test => 여러 step을 포함해야함 (너무 작게하지 x)
==> 그러나 언제나 예외는 존재..
Use case Diagram
following question
- What is being described? (the system)
- Who interacts with the system? (the actors)
- What can the actors do? (the use cases)
기본적인 기능들... 문법들은.. 다 ... 알지? 응...
** 모든 actor와 usecase는 독립적으로 존재할 수 x 반드시 각 쌍으로 존재해야함
Relationships between Use Cases <<include>>
- 점선 화살표.. << include >>
- A(Base uc)가 B를 포함, A가 B의 정보를 가지고 있음.
- A를 진행하다가, B를 call해서... 사용...
- B는 actor와 직접연결이 안되어있어도 괜찮다 (왜냐면 A를 통해서도 쓰이니까)
Relationships between Use Cases <<extend>>
- 점선 화살표.. <<extend>>
- A(Base uc)에서 B를 확장 시키는것 (그러나 A는 B의 정보가 없다)
- 확장'된' 쪽은 B라서, B가 A의 정보를 가지고 독자적 use case를 가짐
- 사실 flow는 include와 다를 것은 없지만 dependency가 반대이다.
- A라는 기존 기능에 뭔가의 기능을 추가하고 싶을 때, extend를 사용하여 B를 만들면, 기존 A를 건드리지 않고도 B의 기능을 사용할 수 있게 됨.
- 여기서도 A가 extension point를 가지고 B를 호출할 수 있기 때문에, B는 actor와 직접적인 연결이 되지 않아도 무방하다.
Relationships between Use Cases Generalization
- use case간 상속이 가능하다
- 상속된 use case 역시 base uc와 연결되어 있으므로, actor와 직접연결 안해도 괜찮음
- actor간의 상속도 가능한데, 이 역시 uc와 직접 연결이 되지 않아도 괜찮다.
'전공 > 소프트웨어공학' 카테고리의 다른 글
Domain model (0) | 2024.04.20 |
---|---|
Software Requirements (0) | 2024.04.20 |
Software Development Process (1) | 2024.04.20 |
sequence diagram (0) | 2024.04.17 |
class diagram (0) | 2024.04.16 |