학부생 시절에 C++, Java 등 언어의 수업을 들으면서 객체지향 패러다임 이라는 것을 처음으로 배우게 되었다.
어떤 책인지 정확히 기억은 안나는데, 객체지향 패러다임에 대해 다음과 같이 적혀있었던 것이 기억난다.
모든것은 객체이며 객체들은 자신의 상태를 가지고 있고, 메시지를 주고받으며 계(界)와 객체간 상호작용한다.
그 때에는 이 말이 무슨 말인지도 잘 몰랐다.
그냥 클래스 몇개 만들고, new 연산자로 객체를 만들고 대충 사용하면 된다고 생각했었다.
개발밥을 좀 먹다 보니, 단순히 코드를 작성하는것을 넘어, 소프트웨어나 시스템을 설계하는데 있어 객체지향적 사고를 한다는 것이 얼마나 중요한 것인지 깨닫게 되었다. (객체지향 언어나 프레임워크를 사용하지 않는다 하더라도 말이다.)
앞서 요구사항 구체화(Requirements Specification) 단계에서 수집된 요구사항들이 구현을 위한 중요한 기반 산출물로 가공된다고 언급한 바 있다.
객체지향 분석설계(OOAD-Object Oriented Analysis and Design)는 정리된 요구사항을 바탕으로, 도메인 개념과 객체 책임, 협력 구조를 분석하고 설계 모델로 구체화하는 과정이다.
OOAD는 바로 이 개발에 착수 가능한 상태를 위해 실제로 산출물 내 요구사항을 분석하고, 개발을 위한 설계를 진행하는 단계라고 볼 수 있을 것이다.
요구사항 잘 수집하면 된 것 아닌가. 무슨 또 분석을 하며, 설계를 하느냐고 .. 설계는 산출물 나올 때 같이 하면 되는것 아닌가? 라는 생각이 들 수 있다.
사실, 간단한 토이 프로젝트 수준의 앱을 만들거나, 학부생이 받는 학기 말 프로그래밍 언어 과제로 나오는 정도 수준의 과제라면 일견 맞는 말이다.
하지만, 현실세계의 문제는 굉장히 복잡하고 미묘해서, 요구사항이 계속해서 추가되거나 변경되는 바람에, 애써 분석한 요구사항이 무용지물이 되는 경우도 부지기수이다.
요구사항 분석과 설계가 튼튼하지 않으면, 결국 상황에 따라 이리저리 흔들리고 치이다가 기술 부채를 양산하여 나중에 큰 대가를 치르거나, 심각한 경우 일정을 제대로 맞추지 못해 납기 지연이 발생할 수 있다.
한마디로 요약하자면, 요구공학은 건물의 설계도를 그리는 행위이고, OOAD는 설계도를 시공 가능한 구조도/상세도면으로 바꾸는 작업이라 할 수 있겠다.
OOAD는 반복적(iterative), 점증적(incremental), 추적성(tracebility) 중심으로 흘러간다.
즉, OOAD는 산출물을 1회 뽑아내고 돌격 앞으로! 가 아닌, 2회 이상 산출물 작성 활동을 수행함으로써 변경에 강한 구조를 도출한다. 결론적으로 OOI(Object Oriented Implement)를 통해 실제 요구사항에 걸맞는 소프트웨어를 구현하는데 목적과 의의가 있다.
OOAD를 교안에서 공부하면서 느꼈던 정의와 필요성, 그리고 요구공학과의 상관관계에 대해서 정리해보았다.
다음 글에서는 OOAD의 산출물이 무엇인지, 요구공학의 산출물과 어떻게 이어지는지 탐구해보고자 한다.