FX 외환 거래 데일리 리뷰

1. 개발 프로세스와 UML
왜 UML에 대해서 이야기를 하는데 또 듣기만 해도 골치가 아픈 프로세스 이야기를 꺼내는걸까요. 결코 제가 여러분을 괴롭히는것이 목적이라서 그런걸까요. ㅎㅎ 그렇지는 않습니다. (아냐 그럴지도 몰라요. ㅋㅋ 너무 저를 밎지 마세요)
앞서 시간에서 저는 UML의 가장 기초적인 의미에 대해서 언급하였습니다. 무엇인지 기억하십니까 ? 네에. 바로 의사소통을 위한 통일된 표기법이었습니다. 그럼 프로세스는 왜 언급한 것일까요 ?
바로 UML은 그 자체가 표기법이기 때문에, 어떤 표기법을 언제 사용하면 좋은지 알아야 될것 아닙니까 ? 그걸 모르고 어떻게 UML을 사용한다 하겠습니까? 마치 건물 설계도에서 화살표를 언제 써야 좋을지 모르는것과 마찬가지 상황이죠. (쓰고 나서 보니 참 황당한 상황이네요)
즉, 좀 어렵게 말한다면

1.1 요구사항 분석
네, 바로 그 지겨운 요구사항 분석입니다. 다들 아시리라 생각합니다. 사용자가 요구하는 시스템을 이해하고 그 이해한 결과를 다시 표현하는 과정입니다. 이 과정이 중요한 이유는 고객이 생각하는 시스템과 개발자가 생각하고 있는 시스템을 일치시켜야 하기 때문이죠. 또한 개발해야될 시스템의 기능과 어디까지가 개발 대상인지 그 경계를 명확히 하기 위해서도 이 과정은 반드시 거쳐야 할 것입니다.
이 과정에서는 주로 Use Case Diagram이 많이 사용됩니다. 필요에 따라서 다른 다이어그램도 사용할 수 있습니다.
1.2 시스템 분석
분석단계에서는 이전 단계에서 고객의 요구를 정확히 파악했다는 전제하에, 개발해야될 시스템을 더욱 자세히 파고들어 세부부분들을 끌어내는 과정입니다. 이 과정에서 가능하다면 구현기술관련 분석은 하지 않는것이 좋습니다. 조금 어려운 말로 Domain을 분석한다라고도 말합니다.
조금 더 구체적으로 적어 보죠.
이 단계를 통해서 다음과 같은 일들을 수행 할 수 있을 것입니다.
 

• 개발해야될 시스템에 대한 보다 자세한 세부점들을 파악해야 합니다. 가장 중요한것이 바로 비지니스 프로세스를 파악하는 것이겠죠.
• 비지니스 클래스들을 파악할 수 있습니다. 비지니스 프로세스들을 파악한 클래스를 통해서 표현할 수 있습니다.
• 여러번 이터레이션을 거치면서 보다 정확하고 정적인 클래스들관의 관계를 모델링 할 수 있습니다.
• 그리고 이 단계에서 User Interface도 함께 디자인하여 최종결과물로서 GUI와 비지니스 클래스 들을 사용하여 비지니스 로직이 빠짐없이 수행될수 있도록 하면 됩니다.

이 단계에서 사용할 수 있는 다이어그램들은 Class Diagram, Sequence Diagram, Collaborate Diagram, State Diagram, Activity Diagram등이 있습니다.

간단한 Class Diagram Sample

1.3 시스템 설계
이 단계는 시스템 분석의 결과물에다가 보다 자세한 사항과 개발기술과 관련된 사항들을 접목시켜 한번더 시스템 설계를 확장하는 단계입니다. 좀더 쉽게 말한다면 어떻게 구현할 것인지를 이제부터 생각하면서 설계를 하는 것입니다. 이것을 MDA에서는 PIM, PSM이라고 하는데, 아직 그걸 이야기 할 정도 강좌가 진행된것은 아니지만 추상화 레벨을 달리하여, 시스템의 기능과, 그 기술적인 하부 구현부분을 분리하여 설계를 진행하면 추상화 레벨이 높은 부분의 분석단계의 결과물은 차후 재사용이 가능하다는 이점이 있습니다. (예를 들어 동일한 기능을 가진 시스템을 웹용, Windows용으로 개발할 경우 공통의 시스템 분석단의 결과물은 공유해서 재사용할 수 있다는 말입니다.)
구체적으로 다음과 같은 작업들을 수행 할 수 있습니다.

• 클래스들을 package를 사용하여 그룹화 할수 있습니다.
• 동시성의 경우 비동기적 메세지나 동기화 기술들을 고려하여 모델링 할 수 있씁니다.
• 시스템의 인터페이스 (GUI, File, Network)등에 대해서 구체적으로 정의한다.
• 예외처리에 대한 설계
• 외부 라이브러리나 프레임워크 등을 표시한다.

이 단계에서 산출 할수 있는 결과물은 Class diagram, Sequence Diagram, Collaboration Diagram, State Diagram, Activity Diagram, Component Diagram, Deployment Diagram등이 있습니다.
이 단계역시 여러번의 이터레이션을 거치면서 설계를 견고하게 할 필요가 있습니다.
1.4 구현
이 단계는 머 별거 있나요.. 코딩하는 단계죠. 이전의 단계에서 자세하게 설계를 한만큼 이 단계에서 편하게 작업이 가능할 것입니다. 많은 개발자들이 지금까지의 앞단계를 무시하더가 대충 한다음에 바로 코딩으로 들어가는 경우가 많은데, 객체지향적 설계의 장점을 살리기위해서는 분석과 설계는 반드시 필요한 단계라고 할 수 있겠습니다.
구현하는 과정에서 설계가 변경될수 있는데, 이 경우 귀찮게 여겨질수도 있지만, 설계 문서의 변경도 반드시 해놓아야 할 것입니다. 이 단계에서 UML을 사용해서 따로 결과물을 생성하는 일은 아마 드물것입니다.

1.5 테스트
개발한 시스템을 테스트 하는 과정입니다. 요즘들어 테스트의 중요성이 다시 한번 확인되어지고 있는데요, 저는 테스트 시나리오 작성을 Sequence와 Activity를 통해서 작성했던 적이있습니다.

1.6 배포
Deploymeny Diagram을 사용하여 설계한 문서가 있다면 이 단계에서 그 문서를 사용할 수 있습니다.