개인 취미/언제나 휴일2(IT 소설)

8. 약속 (언제나 휴일2, IT 소설)

언제나휴일 2016. 5. 15. 13:34
반응형

8. 약속 (언제나 휴일2, IT 소설)



우리는 영상 채팅 P2P 프로젝트를 수행하기로 결정하였다.

 

 먼저, 우리 프로젝트를 사용할 사용자의 관점에서 Peer 프로그램을 사용하는 경우에 대해 생각을 하고 이에 대해 정리를 하였다. 크게 가입, 로긴, 상태 유지 및 친구의 접속 상태를 확인하게 되는 경우에 대한 부분과 채팅, 파일 전송, 숏 메시지를 보내는 경우로 구분을 하였고 각 경우에 어떻게 사용을 할 것인지를 고민하였다. 또한, 서버 side는 역할에 따라 계층을 두기로 하였고 Peer의 요청을 접수하는 Facade계층, 실제 서비스를 처리하는 Business계층, 데이터를 처리하는 Transaction계층으로 나누기로 하였다. 아직 DB를 배우지 않은 상태라서 간단히 ODBC를 이용하여 Access파일을 사용하기로 하였고 Business 계층은 가입 서버, 로긴 서버, 상태 서버로 나누기로 하였다. 채팅이나 메시지 전송은 P2P로 하였기 때문에 로긴시에 Peer는 자신의 채팅이나 메시지를 받을 수 있는 채널을 생성하여 이 정보를 서버에 보내고 상태 서버에서는 이 정보를 접속되어 있는 각 Peer에게 통보해 주기로 하였다.

 

 이와 같이 사용자 관점에서 우리 프로젝트를 사용하는 케이스를 결정하고 난 후에 우리는 프로젝트를 구성하는 컴포넌트를 정의를 하고 이들 사이의 필요한 채널을 약속을 하였다. 이 후 각 Usecae별로 시퀀스를 정의를 하면서 채널을 통해 전달하게 될 패킷들을 약속하였고 각 패킷의 구조를 약속을 하였다. 아키텍쳐 단계 이후에 순조롭게 설계 및 구현 단계를 수행할 수 있게 하기 위해서 각 채널에서 사용할 패킷들을 라이브러리화 하는 작업과 이들을 사용하는 방법에 대해 학습을 어떻게 할 것인지에 대해 약속을 하였다. 또한, 시퀀스 정의를 통해 관리할 비지니스 객체를 모델링하고 DB를 설계 작업을 맡을 이를 결정하였다. 또한, 실제 사용자가 Peer를 사용하는 모습을 확인할 수 있도록 Peer를 맡는 이들이 프로토 타이핑을 하기로 하였다.

 

 요구 파악을 통해 아키텍쳐 단계에서의 우리의 약속이 설계 및 구현 단계에서 효율성을 높여줄 것이라 믿는다.

 


참고

요구사항 정의서

유즈케이스 정의서

컴포넌트다이어그램

시퀀스다이어그램

비지니스 객체 모델링


언제나 휴일2

1. 새로운 도전 (언제나 휴일2, IT 소설)

2. 첫 미팅 (언제나 휴일2, IT 소설)

3. 풋나기 (언제나 휴일2, IT 소설)

4. 미션1 클리어, Next Go Go! (언제나 휴일2, IT 소설)

5. 이상한 나라의 강리스 (언제나 휴일2, IT 소설)

6. 나의 Guru들 (언제나 휴일2, IT 소설)

7. workshop (언제나 휴일2, IT 소설)

9. 미리보기 (언제나 휴일2, IT 소설)

10. Turning Point (언제나 휴일2, IT 소설)

11. 역할 분담 (언제나 휴일2, IT 소설)

12. 코어 (언제나 휴일2, IT 소설)

13. 중간 정점 (언제나 휴일2, IT 소설)

14. Hello, .NET!!! (언제나 휴일2, IT 소설)

15. C# 강의가 끝나다. (언제나 휴일2, IT 소설)

16. 리모팅 (언제나 휴일2, IT 소설)

17. UX (언제나 휴일2, IT 소설)

18. 모모 (언제나 휴일2, IT 소설)

19. 우리들의 이야기 (언제나 휴일2, IT 소설)


반응형