소프트웨어 설계 3강. UML과 객체지향 설계

1990년대 객체지향 표기법은 오십 가지가 넘었습니다. 서로 자기 그림이 맞다고 싸우던 세 사람이 한 회사에 모이면서 전쟁이 끝났죠.

풀고 시작

삼총사가 만든 표준어

1990년대 초 객체지향 설계 표기법은 난립 상태였습니다. 제임스 럼바우의 OMT, 그래디 부치의 부치 방법론, 이바 야콥슨의 OOSE가 각자의 기호를 쓰고 있었죠. 같은 시스템을 그려도 회사가 다르면 서로 읽지 못했습니다. 그러다 셋이 모두 래셔널이라는 한 회사로 모입니다. 업계는 이들을 삼총사(three amigos)라고 불렀고, 그 결과물이 1997년 표준으로 채택된 UML(Unified Modeling Language)입니다.

UML은 그리는 순서를 정해 주는 방법론이 아니라 표기법입니다. 구성 요소는 셋으로 정리됩니다. 클래스나 관계처럼 그림을 이루는 사물(things), 사물을 잇는 관계(relationships), 그리고 이들을 모아 보여 주는 다이어그램(diagrams)입니다.

다이어그램은 크게 둘로 갈립니다. 구조 다이어그램은 정적인 뼈대를 그립니다. 클래스, 객체, 컴포넌트, 배치, 복합체 구조, 패키지 여섯이죠. 행위 다이어그램은 시간에 따른 움직임을 그립니다. 유스케이스, 시퀀스, 커뮤니케이션, 상태, 활동, 상호작용 개요, 타이밍 일곱입니다. 시험은 대개 하나를 던지고 "정적인가 동적인가"를 묻습니다. 배치와 컴포넌트가 구조 쪽이라는 것만 잡아 두시면 나머지는 이름에서 짐작이 됩니다.

관계의 여섯 가지 화살표

클래스 다이어그램에서 선을 어떻게 그리느냐가 곧 설계 판단입니다.

집합과 합성의 차이는 예로 잡으시면 잊히지 않습니다. 컴퓨터와 마우스는 집합입니다. 컴퓨터를 버려도 마우스는 다른 컴퓨터에 꽂으면 되니까요. 반면 주문서와 주문 항목은 합성입니다. 주문서를 지우면 그 안의 항목은 존재할 이유가 없죠. 속이 찬 마름모가 더 강한 소유라고 기억하시면 됩니다.

객체지향의 다섯 낱말, 그리고 럼바우

객체지향 개념은 다섯 낱말로 압축됩니다. 캡슐화는 데이터와 그것을 다루는 연산을 하나로 묶는 것이고, 그 결과로 외부에서 내부 구현을 못 보게 되는 것이 정보 은닉입니다. 상속은 상위 클래스의 속성과 연산을 물려받는 것이고, 다형성은 같은 메시지에 객체마다 다르게 반응하는 성질입니다. 도형에게 그리라고 시키면 원은 원을, 사각형은 사각형을 그리는 그 상황이죠. 추상화는 공통된 성질만 뽑아 내는 것입니다.

시험이 특히 좋아하는 것은 럼바우의 객체지향 분석 절차입니다. 순서가 정해져 있습니다. 객체 모델링으로 시스템의 정적 구조를 클래스 다이어그램으로 그리고, 동적 모델링으로 상태와 시간 흐름을 상태 다이어그램으로 그리고, 기능 모델링으로 자료 흐름도를 써서 처리 과정을 그립니다. 객체가 먼저이고 기능이 마지막이라는 순서가 그대로 문제가 됩니다.

한편 유스케이스 다이어그램에서 헷갈리는 두 관계도 정리해 두시죠. 포함(include)은 반드시 실행되는 필수 관계이고, 확장(extend)은 조건에 따라 실행될 수도 있는 선택 관계입니다. 결제에는 로그인이 반드시 포함되지만, 결제에 쿠폰 적용은 조건부로 확장됩니다.

다음 강은 이 설계가 사용자와 만나는 지점, 화면 설계로 넘어갑니다.

인출 문제

생각해볼 질문 (정답 없음)

설계도를 그리는 데 드는 시간이 코드를 고치는 시간보다 길다면, 그 설계도는 여전히 그릴 가치가 있을까요. 어느 규모부터 그림이 말보다 싸질까요.

이전: 2강 요구사항 확인과 분석 모델 · 다음: 4강 화면 설계와 UI