유스케이스 다이어그램을 그리고 있는데..
하나의 유스케이스 단위를 어떻게 정해야 할 지 모르겠습니다.
책을 보니 하나의 단위기능으로 하고, 하나의 이벤트 흐름에서 해결할수 있는 범위내로 한것 같은데요..
그렇다면 예를 들어 지도의 확대 축소 버튼과 지도모드 변경 버튼이 있다고 할때
지도 확대, 지도 축소, 지도모드 변경 이 각각이 유스케이스가 되나요?
아니면 지도조작 과 같은 하나의 유스케이스가 되나요..
그리고 지도 확대 축소와 같은 경우는 하나의 유스케이스로 묶어도 될런지요..
묶어서 하려고 보니 이벤트 흐름이 각각 다르자나요.. 하나는 확대 버튼을 누르는것이고 하나는 축소 버튼을 누르는것이니..
그런데 또 이렇게 세분화하면 너무 많은 유스케이스가 생길것 같아서요..
사용자 관점에서 시퀀스 다이어그램을 그려보시면 유스케이스가 그려지고
그 유스케이스를 토대로 설계상에 필요한 클래스 다이어그램과 시스템 시퀀스 다이어그램이 그려져요
근데 저도 요새는 이런거 안 하네요.
초기에 개발문서에 너무 진빼지마시고 차라리 이렇게 해보세요
Step 1
크게 기능단위로 묶어보기
Step 2
중간 크기로 기능별 세부사항을 명세한다
Step 3
기능별 세부사항을 구현하기 위한 모듈을 명세한다.
이렇게 기능별 구현을 3 depth 정도 만들면 공통 모듈도 뽑아지고
그러면서 간단하게 설계가 만들어져요.
그걸 토대로 개발하면 일정 산출이나 기능별 구현에 있어서 큰 도움이 되지요.
참고 서적은 헤드퍼스트 SW 개발방법론 책을 보시면 될거에요.
제 경험상..어차피 설계는 개발 초기부터 무수한 수정을 거치게 되어 있어요.
어차피 수정될꺼 큰 그림만 그려놓고 협업자랑 의견 공유하면서 구현해도 늦지 않아요.
질문을 보아하니, 프로젝트 매니저가 하는 역할인 것 같아요.
이전에 회사다닐땐 확대 축소와 같은 다음 단계가 없는 것 까지 모두 그리더군요. 말씀대로 그냥 너무 많은 유스케이스가 생기도록 만듭니다.
저도 한창 공부중이지만.. 20년 넘은 선배 개발자가 말씀하시길, 그냥 손으로 그리라 하시더군요 허허.