요구 분석 및 정의 단계에서는 프로젝트의 이해 관계자들의 요구 사항을 분석 및 정의합니다. 요구 사항은 기능 요구 사항과 품질 요구 사항으로 구분할 수 있는데 이 책에서는 기능 요구 사항만 파악할 것이며 여러분께서는 개발 방법론에 관한 학습 자료를 통해 보다 깊은 이해와 활용 능력을 키우세요.
이 책에서는 편의상 Peer 측과 서버 측을 분리하여 분석 및 정의할게요. 그리고 어떠한 이해 관계자의 요구 사항인지는 구분하지 않기로 할게요.
다음은 EH 메신저 Peer측 요구 사항입니다.
요구 ID | 종류 | 설명 |
CP01 | 기능 | 최종 사용자는 서비스에 가입/탈퇴할 수 있어야 한다. |
CP02 | 기능 | 최종 사용자는 서비스에 로긴/로그 아웃할 수 있어야 한다. |
CP03 | 기능 | 최종 사용자는 서비스에 로긴한 사용자 ID를 확인할 수 있어야 한다. |
CP04 | 기능 | 최종 사용자는 다른 사용자에게 숏 메시지를 보낼 수 있어야 한다. |
CP05 | 기능 | 최종 사용자는 다른 사용자에게 파일을 보낼 수 있어야 한다. |
CP06 | 품질 | 서비스와 주고 받는 메시지 부분은 동적 링크 라이브러리로 만든다. |
요구 사항을 파악하였으면 이를 Usecase 다이어그램을 작성합니다.
Usecase 다이어그램은 액터와 Usecase와 관계로 구성합니다. 액터는 시스템을 사용하는 사용자 혹은 외부 시스템과 시스템이 사용하는 외부 시스템을 말합니다. 다이어그램에서는 사람 모습으로 표현합니다.
그리고 Usecase는 언제 관련 액터가 시스템을 사용하는지 혹은 시스템이 관련 액터를 언제 사용하는지를 말합니다. 다이어그램에서는 타원으로 표시합니다.
관계는 액터가 시스템을 사용하는지 혹은 시스템이 액터를 사용하는지의 방향성을 갖는 직접 연관관계(실선과 화살표)와 서로 연관이 있는 연관관계(실선), Usecase에서 다른 Usecase를 선택적으로 수행하는 확장 관계(점선과 화살표, 스테레오 타입으로 extend, 선택적으로 수행하는 Usecase에서 출발하게 표시), Usecase에서 다른 Usecase를 반드시 수행하는 포함 관계(점선과 화살펴, 스테레오 타입으로 include, 반드시 수행해야 하는 Usecase로 향하게 표시)등이 있습니다.
다음은 서버 측 요구 사항입니다.
요구 ID | 종류 | 설명 |
CS01 | 기능 | Peer에 가입/ 탈퇴 서비스를 제공해야 한다. |
CS02 | 기능 | Peer에 로긴/로그 아웃 서비스를 제공해야 한다. |
CS03 | 기능 | Peer에 로긴 계정의 정보를 제공해야 한다. |
CS04 | 품질 | 프리젠테이션, 비지니스, 데이터 계층으로 나누어 작성한다. |
CS05 | 품질 | Peer와 서비스, 서비스와 서비스 사이의 메시지는 동적 링크 라이브러리로 만든다. |
[그림 7.2]에서 KeepAlive 유즈케이스는 Peer가 로긴을 성공하면 주기적으로 자신이 서비스 Zone에 상태를 유지하기 위해 보내는 기능에 관한 것입니다. 만약 특정 Peer로부터 처음 받은 KeepAlive일 때는 이미 로긴 상태의 Peer에게 새롭게 KeepAlive를 보낸 Peer의 로긴 계정의 정보를 제공합니다. 그리고 새롭게 KeepAlive를 보낸 Peer에게 이미 로긴 상태 Peer의 계정 정보를 제공합니다. 이처럼 선택적으로 수행할 때 extend로 관계를 표시합니다.
CheckKeepAlive는 주기적으로 가장 최근에 받은 KeepAlive 시간과 현재 시간을 비교하여 서비스에서 정한 시간을 초과하면 강제로 로그아웃 처리할 것입니다. 마찬가지로 선택적으로 수행할 것이므로 extend로 관계를 표시하였습니다.