ZIM/Essential Use Case

• 클라이언트 (Zimmer)
  
• 서버관리자 (Zimmer Master)
  

• Actor : Zimmer
  

  Actor Action	System Response
  1. 사용자의 ID와 암호를 입력한다.	2. 등록된 사용자인지 ID와 암호를 비교한뒤 결과를 보낸다.

• 관련 유스케이스 : 상대지머선택
  

• Actor : Zimmer
  

  Actor Action	System Response
  1. 파일을 받을 지머(Zimmer)와 보낼 파일을 선택한다.	2. 파일을 전송한다.

• 관련 유스케이스 : 상대지머선택
  

• Actor : Zimmer
  

  Actor Action	System Response
  1. 화일 이름 & 용량을 확인한뒤 화일수신수락여부를 결정한다.	2. 파일을 수신한다.

• 관련 유스케이스 : 상대지머선택, 파일전송
  

• Actor : Zimmer
  

  Actor Action	System Response
  1. 파일을 받을 지머(Zimmer)를 선택한다.	.
  2. 메세지창에 문자를 입력한다.	3. 해당 Zimmer에게 문자를 전송한다.

• 관련 유스케이스 : 상대지머선택
  

• Actor : Zimmer
  

  Actor Action	System Response
  .	1. 문자를 받는다.
  .	2. 현재 열려있는 대화창의 유저를 확인하고 새 대화창을 열거나, 해당 대화창에 문자를 출력한다.

• 관련 유스케이스 : 문자열전송
  

• Actor : Zimmer
  

  Actor Action	System Response
  1. 현재 보고 있는 웹 페이지를 닫는다.	2. 현재 접속을 끊는다.

ShowMeTheExample~

화일 전송시의 System Response는 클라이언트프로그램의 입장에서 써야 하나요? -- 석천
음. UP 로 Process 진행할 때.. 많은 Requirements를 모두 나열하고..
그것을 구현으로 들어간다는건 좀 무리라고 볼 수 있죠..
저희팀(2001년 2학기 정보처리 실습 worktool팀)에서 한 방법을 하나 소개해준다면.
처음 Requirements 만들때 각 Requirements 별로 Risk Level 을 정하는 방법이죠..
예를 들면 로그인,쪽지 보내기, 문자열 송수신, 같은 경우를 Level 1
파일 전송에 대한 것은 Level 2 이런 식으로 말이죠..
이렇게 먼저 아키텍쳐에 기반이 될만한 것은 Level1 으로 정하고..
미리 만드는 것이 프로세스를 진행해 나가는데 위험도를 최소로 하여 진행해 나갈 수 있을 듯 싶네요. -- 구근

RUP는 ADD이고 XP는 FDD에 가깝습니다. 참고로 마이크로소프트에서는 FDD를 선호합니다. 스펙과 요구사항이 미리 확실히 정의되어있고 변화할 일이 거의 없고, 개발시 리스크가 낮다(유사 기술 개발 경험이 있다)면 ADD를, 그렇지 않고, 변화가능하고, 요구사항도 확실치 못하고, 개발시 리스크가 높다면 FDD가 적절하겠죠. XP의 아키텍춰에 대해서는 http://users.vnet.net/wwake/xp/xp0007b.shtml 를 참고하세요. --김창준

ZIM