- 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다.
- UML과 개발 공정
UML은 객체지향 분석 설계 방법과 함께 발전했다. 프로젝트 개발시 어떤 공정법을 사용하느냐에 따라 UML 사용법도 달라진다.
흔히 UML에 대해 이야기할 때 RUP(Rational Unified Process)를 많이 언급한다. RUP는 UML과 함께 사용하는 공정중의 하나이지만, Rational 사의 사람들이 UML에 참여한것과 이름에 Unified 가 있는것만 빼면 둘은 관련이 없다.
- 반복 공정과 폭포수 공정
폭포수(Waterfall) 방식은 프로젝트를 액티비티 기준으로 나눈다. 소프트웨어 개발에는 분석, 설계, 개발, 테스트 액티비티가 필요하다. 각 단계사이에는 특정 형태의 산출물이 있다.
이론적으로는 앞 단계가 끝나면 그 다음 단계로 넘어가지만 실제로 개발단계가 되었다고 해서 분석, 설계가 완벽하게 끝났다고 생각하는것은 현실적이지 못하다. 이슈가 생길시 분석, 설계 단계로 되돌아가는것이 현실이다.
반복(Iterative) 방식은 프로젝트를 기능의 부분집합으로 나눈다. 만약 1년짜리 프로젝트를 3개월 단위로 나누었다고 치면 3개월내에 분석, 설계, 개발, 테스트 액티비티를 끝낸다. 1번째 반복이 끝나면 요구사항의 1/4 정도가 구현되었을것이며, 2번째 반복이 끝나면 요구사항의 절반이 구현되어있을것이다.
각 반복이 끝날 때마다 완성된 품질의 통합 소프트웨어가 만들어져야 한다. 반복 개발은 증가(incremental), 나선형(spiral), 진화(evolutionary) 라는 이름으로 불리기도 한다.
반복과 폭포수를 혼합할수도 있다. 분석과 설계는 폭포수방식으로 하고, 개발과 테스트는 반복개발로 진행한다. 요즘에는 폭포수방식을 찾아보기가 힘들어 거의 반복 공정으로 개발한다. 하지만 겉으로는 반복을 하고 있는데 폭포수를 하고 있거나, 특유의 K-헬적화와 합쳐지면서 폭포수를 반복으로 돌리는 끔찍한 혼종이 생기기도 한다.
반복공정을 잘못사용하면 오해가 생긴다. SI 프로젝트 같은 경우 일정압박이 너무 강하다보니 "이번 반복 기간의 코드는 버그가 많지만 나중에 정리하면 된다."는 생각으로 반복을 끝낸다. 일정이 바빠서 그런 상황이 불가피할 수는 있지만 그렇다면 최소한 반복 공정을 잘 적용하고 있다고 해서는 안된다.
반복공정의 기간은 항상 일정해야 한다. 요구사항을 모두 끝내자는 생각으로 "이번 기간은 좀 더 길게하고 다음 기간을 줄인다"는것은 잘못된 생각이다. 구현하지 못한 기능을 다음 반복으로 미루어야 한다.
반복공정에서 코드의 재작업은 필수적이다. 반복을 끝내면 그에 대한 피드백이 있고, 기존 코드를 수정한다. 소프트웨어는 하드웨어(제조업)와 다르다. 제조업에서는 반복을 쓸데없는것으로 보지만 소프트웨어는 재작업을 하면서 기존 코드를 수정해야 한다. 이 때 회귀 테스트, 리팩토링등을 적용한다.
- 예측 계획법과 적응 계획법
폭포수 개발 방식이 죽지 않는 이유는 소프트웨어를 예측 가능하다고 생각하기 때문이다. 예측 계획법에서는 앞으로 무엇을 해야하는지 알기 위해서 프로젝트 초기에 예측을 한다. 이 부분에서는 논쟁이 있다. 그 중심에는 요구사항 분석이 있는데, 소프트웨어 시스템의 요구사항은 이해하기 어렵기 때문이다. 그렇다고 해서 요구사항을 fix 해놓고 고객에게 변경시키지말라고 해버리면 고객은 화를 내거나 그런 소프트웨어 시스템은 고객에게 실질적으로 필요한 기능을 제공하기가 어렵다.
이 때문에 어떤 사람들은 요구사항을 변경하는것이 소프트웨어의 숙명이라고 생각한다. 이런 사람들은 적응 계획법을 지지한다. 적응 계획법에서는 예측 이라는것 자체를 할 수 없는일로 여긴다. 변경은 필연적인거시며 좋은 소프트웨어를 만들기 위해 변경을 제어한다.
- 애자일 프로세스
아마 소프트웨어 개발 방법론과 관련하여 가장 많이 들어봤을법한 단어일것이다. 아마 애자일에 관련된 모든것을 언급하면 글이 몇십개라도 모자랄것이므로 간단하게 공통된 특성만 알아본다. 애자일에 대해 가장 흔한 오해는 애자일이 하나의 특수한 공정으로 생각하는것이다.
애자일이란 애자일 소프트웨어 공동 선언문에서 정의한 가치와 원칙을 준수하는 다양한 공정을 대표하는 용어이다. 즉 어떤 특수한 공정 하나를 가리키는것이 아니다. 애자일 원칙을 준수하는 공정들에는 익스트림 프로그래밍(XP - Extreme Programming), Scrum, FDD(Feature Driven Development), Crystal, DSDM 등이 있다.
애자일 방법론의 공통적인 원칙에는 다음과 같은 것들이 있다.
- 한 달 이하의 기간을 갖는 반복을 사용한다.
- 문서에 집중하지 않아 UML을 스케치하는 용도로 사용한다.
- 형식에 덜 치중한다.
- RUP(Rational Unified Process)
RUP는 UML과 보통 함께 언급된다. RUP를 공정으로 부르지만 사실은 공정 프레임워크이다.
RUP사용시에는 가장 먼저 프로젝트에 사용하려고 하는 공정의 개발 사례를 선택해야 한다. 그리고 그것이 어떤 개발 사례이건간에 RUP는 반복 공정이다. 폭포수를 사용하면서 RUP라고 사기치는 경우가 많지만 RUP라면 4 가지 단계를 따라야 한다.
- 개념화(inception): 프로젝트에 대한 초기평가를 한다. 다음(상세화)단계를 수행할 자금을 할당할지를 결정한다.
- 상세화(Elaboration): 시스템의 주요 유스케이스를 도출한다. 이 단계가 완료되면 요구사항을 잘 이해해야 하며, 뼈대 시스템이 돌아가야 한다. 그리고 이를 통해 주요 위험 요소를 해결해야 한다.
- 구축(Construction): 개발 공정 진행 및 릴리즈 하기 위한 기능을 개발한다.
- 전이(Transition): 반복적으로 수행하지 않은 액티비티를 포함한다. 예를 들면 데이터 센터 배치, 사용자 교육 등이 있다.
- 공정의 적용
소프트웨어 프로젝트는 아주 다양하다. 그리고 프로젝트에 영향을 주는 요인에는 시스템의 종류, 회사의 문화, 부서의 일하는 스타일 등 다양한 요인이 있다. 그래서 모든 프로젝트에 맞는 마스터 키 같은 공정이 있을거라는 기대를 버려야 한다. 그래서 공정을 선택할떄에는 우선 어떤 공정이 프로젝트에 맞는지 파악하고 프로젝트에 맞게 변화시켜야 한다.
매 반복이 끝나면 회고를 해야 하는데 보통 세 가지를 수행한다.
- 유지(Keep): 진행이 잘 되어 계속 유지할 것들
- 문제점(Problem): 문제가 되는 부분
- 시도할 것(Try): 개선하기 위해 변화할 것들
- UML의 공정 적용
요구사항 분석 액티비티란 사용자와 고객이 시스템이 어떤것을 해주기 원하는지 파악하는 것이다. 여기에 적용할 수 있는 UML은 다음과 같다.
- 유스 케이스: 시스템과 이해관계자들간의 상호작용
- 클래스 다이어그램: 도메인 관점의 클래스 다이어그램, 도메인의 정확한 어휘를 구성하는 좋은 방법이다.
- 액티비티 다이어그램: 소프트웨어와 이해관계자의 상호작용의 워크 플로우이다.
- 상태 다이어그램: 어떤 개념이 다양한 상태와 상태를 변경하는 이벤트로 구성되어 어떤 생명주기를 가지는지 표현한다.
요구사항 분석 단계에서의 목적은 고객과 대화하는것이다. 사용자나 고객은 UML에 익숙하지 않으므로 이 단계 산출물에서 UML의 표준을 너무 복잡하게 적용시키지 않는것이 중요하다. 고객과 의사소통을 위해서라면 표준을 무시하는 유연성도 가질 수 있어야 한다.
설계단계에서는 기술적인 표현이 들어가도 좋다. 더 다양하고 정확하게 표기한다.
- 클래스 다이어그램: 설계 단계에서는 소프트웨어 관점에서 클래스 다이어그램을 표기한다.
- 시퀀스 다이어그램: 중요한 유스케이스를 식별하여 시퀀스 다이어그램을 표현한다.
- 패키지 다이어그램: 소프트웨어 구조를 큰 단위로 나타낸다.
- 상태 다이어그램: 복잡한 생성이력을 가지는 클래스를 나타낸다.
- 배치 다이어그램: 소프트웨어의 물리적인 레이아웃을 나타낸다.
'Concepts > UML' 카테고리의 다른 글
UML - 클래스 다이어그램과 의존 (0) | 2021.02.10 |
---|---|
UML - 클래스 다이어그램과 일반화 (0) | 2021.02.10 |
UML - 클래스 다이어그램과 오퍼레이션 (0) | 2021.02.10 |
UML - 클래스 다이어그램과 프로퍼티 (0) | 2021.02.10 |
UML - 개요 (0) | 2021.02.10 |
댓글