모든 프로그램을 만들때는 과정이 단순하지는 않다.
보통 어떤 동작을 해야하는지 파악하고 해당 동작에 대해 이상없이 작동할수 있게 정리한후 해당 프로그램을 제작한다.
최종적으로 같은동작을 하더라도 사람마다 충분히 다르게 생각할수 있고 다른형태로 구성할수 있다.
그리고 같은사람이 같은 행동을 하는 프로그램을 만들더라도 매번 다른형태로 만들수도 있다.
프로그램이 간단해서 잠깐의 시간동안 제작가능한거라면 위의 생각하는 전체 과정을 머리속에 생각하면서 할수 있을것이다.
그런데 만약 프로그램이 하루만에 불가능하고 오래 걸린다면 내 머리속의 전체 과정을 계속 같은형태로 유지할수 있을까?
물론 다 기억할수도 있겠지만 간단하게 기록해두거나 하면 그 기록을 보면서 제작의 일관성을 높일수도 있고 생각하지못해 빠뜨린부분도 체크할수 있을것이다.
또한 고객이 원하는 부분과 전혀 다른형태로 작동하는 프로그램이 만들어져 많은 수정이 필요할수 있다.
이렇게 생각한것들을 정리하고 고객과 협의하는 전체과정과 기록들을 유즈케이스라고 한다.
참고로 이번포스트는 Head First Object-Oriented Analysis & Design 의 내용을 대부분 발췌해서 사용한다.
광고는 아니지만 그냥 한번 읽어볼만한 책이어서 대여하거나 책사기 좋아하면 하나 사서 읽어보자.
우리는 정원으로 통하는 현관 출입문에 밑에 강아지가 드나들수 있도로 해달라는 프로그래밍 의뢰를 받았다.
그래서 우리는 아래와 같이 몇가지 함수를 사용해서 멋지게 프로그램해서 만들었다.
doorOpen() , doorClose() , doorIsOpen()
하지만 문은 고객이 원하는대로 작동하지 않았다.
"마당에있는 토끼와 쥐가 집안으로 들어왔어요. 우리는 강아지 자유롭게 드나들수있는 문을 원한거지 토끼와 쥐를 집안으로 들일려는건 아니에요!"
고객의 강한 클레임으로 확인을 해보니 문의 작동로그를 확인해보니 문은 정상적으로 작동하고있었다.
단지 고객이 강아지가 나가게 문을 열어주고 문을 닫지 않아 그사이에 토끼와 쥐가 집으로 들어온 것이었다.
여기서보면 상당한 딜레마가 있다.
위의 경우에 고객입장에서는 필요없는 문이 되버릴수있다.
오히려 집에 토끼나 쥐가 들어오니 없느니만 못한 프로그램이 되버린것이다.
고객은 강아지가 왔다갔다 할수 있는 문을 만들어달라고 하고 우린 만들어줬지만 고객이 마음에 들게 작동하지는 않는것이다.
사실 거의 모든 고객은 자신이 뭘 원하는지 정확히 알지 못하고 설명하지 못한다.(진짜다 이건.)
그래서 많은 협의가 필요하고 수많은 유즈케이스를 생각해보며 고객이 원하는 프로그램을 만들어내야 한다.
그럼이제 다시 고객과 협의를 하고 고객이 원하는 방향으로 프로그램을 수정해보자.
1.강아지문에 대한 요구사항을 수집한다.
2.문이 실제로 무엇을 해야하는지 알아낸다.
3.고객으로부터 추가정보를 얻는다.
4.문을 잘만든다.
크게 정리해보니 위와 같았다.
그러면 고객으로부터 요구사항을 수집해보자.
고객A : " 문이 2~3초후에 자동으로 닫히면 좋겠어요. 자다가 강아지 문닫으려고 일어나고싶지않아요. "
당신 : " 리모콘에 버튼을 하나로 유지하는게 좋을까요 아니면 열기 닫기 두개버튼으로 나누는게 좋을까요? "
고객B : " 글쎄요 항상자동으로 닫히면 두개가 필요없지않나요? 리모콘에는 버튼하나만 두죠"
당신 : " 알겠습니다 그럼 문이 닫혀있을때 버튼을 누르면 열리고 열려있을때 누르면 문을 닫을수도 있는것으로 하죠. 혹시 문이 다른것에 걸려서 자동으로 닫히지 않을때를 대비해서요"
고객B : " 좋습니다."
이제 요구사항을 정리하자.
---------------------------------------------------------------------------------------------------------
1. 리모콘은 하나의 버튼이 있고 닫혀있을때 누르면 문이 열리고, 열려있을때 누르면 문이 닫힌다.
2. 강아지문은 한번열린후 버튼을 누르지않아도 2~3초후 자동으로 닫혀야한다.
---------------------------------------------------------------------------------------------------------
다음으로 강아지 문이 실제로 하는일을 정리해보자.
---------------------------------------------------------------------------------------------------------
1.강아지가 밖에 나가고 싶어 짖는다.
2.고객은 강아지가 짖는것을 듣는다.
3.고객이 리모콘의 버튼을 누른다.
4.강아지 문이 열린다.
5.강아지가 밖으로 나간다.
6.강아지가 밖으로 나가 쉬하거나 냄새를 맡는다.
7.강아지가 안으로 들어온다.
8.강아지문이 자동으로 닫힌다.
---------------------------------------------------------------------------------------------------------
이제 다된거같다.
위와 같이 수정해주면 당장 급한 불은 끌수 있을것이다.
위와 같이 변경해주고 다른클레임이 들어올내용은 없을지 다시 생각해보자.
위와같이 정리해봤다.
아직도 고객이 요구할 사항은 수없이 많다.
위에서 정리한 사항 이외에도 얼마든지 다른 유즈케이스들이 나올수 있다.
일단은 위에서 정리한 유즈케이스들로 대체경로를 만들어보자.
위의 문제점들때문에 강아지 소리 인식과 문을긁을때를 대비한 진동 인식장비를 와 강아지 출입을 인식할수 있는 센서를 추가하기로 했다.
주경로 대체경로
--------------------------------------------------------------------------------------------------------------------
1.강아지가 밖에 나가고 싶어 짖는거나
문을 긁는다.
2.강아지 소리인식기가 소리를 듣거나 2.1 고객이 강아지가 짖는것을 듣는다.
진동인식장치가 긁는진동을 느낀다.
3.장비들이 문여는요청을 강아지문에 3.1 고객이 리모콘을 열어 문을연다.
전달한다.
4.강아지 문이 열린다.
5.강아지가 밖으로 나간다. 5.1 강아지가 밖으로 나가지않을경우 강아지문 센서가
6.강아지가 밖으로 나가 쉬하거나 일정시간인지한후 자동으로 문을닫는다.
냄새를 맡는다.
6.1 문이 자동으로 닫힌다.
6.2 강아지가 안으로 보내달라고 6.2.1 고객이 강아지가 짖는것을 듣는다.
짖거나 긁는다.
6.3 장비들이 인지하고 강아지문에 6.3.1 고객이 리모콘을 열어 문을 연다.
여는요청을 전달한다.
6.4 강아지 문이 열린다.
7.강아지가 안으로 들어온다.
8.강아지문이 자동으로 닫힌다.
최종적으로 위와 같이 변경될것이다.
이제 위의 유즈케이스에 따라 클래스 다이어그램등을 만들어서 프로그램을 하면 고객도 만족하게 될것이다.
위의 예제처럼 최종 행동에 대해 여러방면으로 생각해보고 일어날수 있는 문제점들을 미리 정리해두면 실제로 고객에 게 훨씬 유연하게 대처할수 있을것이다.
작은프로그램들도 항상 머리속으로라도 유즈케이스를 작성해보기바란다.
***숙제 : 하나의 주제를 정해 프로그램을 만든다는 생각으로 유즈케이스를 작성해보자.
'[ Program ] > c#스터디' 카테고리의 다른 글
| 49. 디버깅 (0) | 2021.10.09 |
|---|---|
| 48. 계산기 만들기 (0) | 2021.10.09 |
| 46. 엑셀파일읽기 (0) | 2021.10.09 |
| 45. 파일읽기/쓰기 (0) | 2021.10.09 |
| 44. 로또생성기만들기 (0) | 2021.10.09 |
댓글