2000년 초반 한창 UML을 이용한 설계가 붐이었는데, 지금은 완전히 사그라진 것 같다.
UML툴도 거의 프로그램 다 만들고 나서 다이어그램 등 산출물 작성하는 용도로만 쓰이고 있는 것 같다.
예전 프로젝트 하나를 대차게 말아먹고 난 후 요구사항와 설계쪽 능력 향상에 대한 갈망이 생겼다.
소프트웨어공학의 요구사항, 비지니스프로스모델링, 설계등에 대한 공부를 관련 교육도 들어가면서 공부를 했다. 교육에 대한 소감은 좀 글쎄였다. 아마 강사들이 PMO쪽 경력이고, 너무 추상적이거나 이론적이서 실무에 어떻게 적용되지? 하는 의문이 들었다.
대형 SI업체에서 있으면서 큰 프로젝트도 했었지만, 역시 이론대로 프로젝트 관리나 설계가 되는 것 같지는 않았다.
내 맘에 드는 Best Practice를 못 찾았다. 내 방식대로 시작을 했다.
툴은 Sparx에서 나온 Enterprise Architect.
UML쪽 툴 1위는 IBM의 Rational 이지만, Sparx의 이 툴도 기능이 그에 크게 뒤지지 않는다는 평가를 받고 있다. 가격도 꽤나 싼 편이다.
난 약 30만원 정도 가격의 Professional version을 구매했다.
이 툴을 프로젝트에 실제 사용한 것은 의료용 솔루션을 개발할 때 부터였다.
그 전에 하던 방식을 보자면, 요구사항도 일일히 excel이나 word로 정리하고, 그걸 바탕으로 설계 문서를 만드는데, 그것도 역시 powerpoint 문서. 그런데 진행하면서 문서 update가 제대로 되는 경우가 없었다. 그래서 문서는 단지 고객에서 보여주는 용도로만 사용하고, 개발용으로 거의 쓸모가 없었다.
체계적인 교육없이 이 툴을 사용하는 것은 쉽지 않았다. 사용 정보는 거의 제조사 홈페이지 있는 tutorial이 거의 전부였다. tutorial 보면서 익혔다. 시중에 나와있는 UML 관련 책들도 대부분 읽어봤다.
툴, 즉 UML spec 대로 작성하다 보니 가장 좋은 점이 생각이 많이 구체적으로 정리되는 것이다. 그리고 고객사나 동료 개발자와 논의할 때도 오해가 거의 없이 전달되는 점.
UML spec에 대한 이해없이 diagram 그리는 것은 만만치 않다. 파워포인트 식대로 이 상자에서 저 상자로 선을 그리어 관련됨을 나타내고 싶은데, UML에서 그 모든 기호가 명확하게 되어 있어 대충 그릴 수가 없게 되고, 그리다 보면나의 생각이 잘못되어 이렇게 그릴 수가 없구나라는 점도 깨달을 수 있었다.
Activity들에 대한 설계를 activity diagram으로 그리고 나서 그걸 다시 state diagram 과 collaboration diagram, sequence diagram 다양한 관점으로 그리다 보니, 한 쪽 면만을 보며 설계했던 것의 오류도 설계 단계에서 쉽게 노출이 되었다.
내가 활용한 방식을 정리해본다.
1단계 : 용어사전
EA에서는 Glossary라고 한다. 프로젝트 수행에서 용어, 즉 명사는 꽤나 중요하다. 특히나 고객과 내가 같은 단어를 사용하는 데 실제 각기 다른 의미로 이해하는 경우가 많다. 그리고 많은 의미를 나타내는 데 여러가지 단어를 혼재하기도 하고..
Glossary에 프로젝트에 사용되는 모든 용어를 정리한다. 이렇게 정의하면 이후 다른 문서에서 이 용어에 해당하는 단어에 링크가 걸리면서 정의를 바로 확인한 수 있다.
2단계 : 요구사항 정리
Requirements Model이라는 요구사항 템플릿을 기반으로 하여 작성한다.
요구사항을 나열식으로 볼 수 있고, 요구사항간의 관계를 맺을 수 있어, 엑셀로 정리하는 방식보다도 훨씬 편했다. 이렇게 작성한 요구사항은 이 후 단계인 Logical Modeling, Physical Modeling 단계와 자동 매칭되면서 누락여부, 또는 어떻게 모델링과 구현과 이어지는지 추적할 수 있다.
3단계 UseCase diagram 작성
구현범위를 가장 큰 관점에서 그린 것이다. 구현할 범위를 System Boundary안에 usecase로 표시하고, 그 usecase을 하는 주체 또는 객체를 actor로 도출하여 그린다.
이렇게 한장의 그림으로 비 IT인인 고객과 업무 범위에 대한 큰 범위 정의가 된다. 그리고 usecase의 속성 창에서 업무 프로세스를 고객이 사용하는 용어로 순서대로 작성한다.
4단계 Activity diagram
앞 3단계의 usecase 속성에 업무절차를 순서대로 기록하며 그것이 tool 자체적으로 activity diagram생성시킬 수 있다. 이렇게 생성한 기본 다이어그램을 좀 더 보강하면서 구체적으로 기술해 간다.
5단계 Data Modeling
이 전까지 데이타 모델링을 주로 ErWin을 사용했었다. 하지만 EA만으로도 DB모델링을 할 수 있고, 이렇게 하면 연속적으로 모델에 대한 추적이 가능해진다.
먼저 논리적 모델링을 하고, 물리적 모델링을 했다. ErWin과는 달리 논리 모델과 물리모델을 한 diagram 에서 쓸 수는 없어, 논리 모델링을 한 후 그걸 물리모델로 복사후 물리모델링을 했다.
6단계. UI 프로토타이핑
UI 프로토타이핑도 EA에서 할 수는 있으나, 별로 좋지 않았다. 그래서 UI prototyping 만은 별도의 툴을 사용해서 했다. Justinmind라는 툴을 사용하여 UI 설계하고, 동작 UX를 고객과 동료에게 보여주면서 피드백을 받으면서 UI/UX에 대한 확정을 했다.
7단계. Class Modeling
UI까지 다 되었으니, 이제부터가 본격적인 코드에 대한 설계다. 먼저 class에 대한 설계. 안드로이드 기준 activity class 위주의 class diagram이 아래와 같다. 이렇게 하여 각 class 기준 업무 분장을 하게 된다.
8단계. Interaction/collaboration/state /instance diagram
앞 단계까지 하여 코딩이 시작하나, 설계를 좀 더 구체화 필요가 있었다. 예외사항이라든가, 놓치고 있는 점이 없는지.. 구현단계에서 설계 결함을 발견하면 싹 갈아엎어야 하는 상황이 벌어지기 때문. 앞서 작성한 usecase, activity, class diagram을 다른 관점(즉, 협업관점, 상태관점, 흐름관점 등)으로 검증을 해 본다. 그리다 보면 막히는 부분이 나오게 된다. 미쳐 생각하지 못한 부분이던가, 놓치고 있던 것, 아니면 아예 엉뚱하게 생각하고 있었던 점이 이 과정에서 마구마구 나왔다. 이것들을 다시 윗 단계에서 만든 diagram들에 다시 반영하면서 모든 관점에서 다 적합할 때까지 그린다.
9단계. Deploy diagram과 기술스택 검증
프로그램이 돌아가는 환경과 기술스택도 diagram을 만든다. 완료보고서에 들어가기도 하지만, 미리 동료들과 충분한 이해를 할 수 있다. 이와 함께 기술스택에 대한 프로토타입 코드를 작성하며 기술스택에 대한 검증도 한다.
10단계. 설계 문서 생성
나중 산출물 작성을 별도로 할 필요없이(물론, 원하는 보고서 양식에 맞게 수정 작업은 해야 하지만) 이 자체만으로 어느정도 모양을 갖춘 산출 문서를 생성할 수 있다.
위 같이 문서를 generate시켜면, 제법 볼 만한 형식의 문서가 만들어진다. 물론 세부 항목의 디테일을 diagram을 얼마나 구체적으로 만들었느냐에 달려있다.
이게 나의 설계 방법론
이 프로젝트 진행 당시 함께 일한 훌륭한 동료들과 이 툴을 사용하여 설계에 충분한 시간을 들여 이제까지의 나의 프로젝트 중 가장 성공적인 것이었다.
하지만, 이 방법이 Best Practice는 아닐 것이다. 하면서도 "더 좋은 방법, 더 제대로 된 방법이 있을 것 인데"하는 갈증을 느꼈다.
좀 더 잘 이 툴을 사용하고 싶고, 더 잘 UML을 그리고 싶다.
물론 툴에만 너무 몰입하면 주객이 전도되기도 한다지만, tool이란게 여러 사람들의 best practice를 패턴화해서 만든 소프트웨어인고, 그걸 일단 잘 사용하고 나서 그게 넘어설 단계가 되는 거라 생각한다.
