OOAD는 무엇인가? (feat. OO)

안녕하세요. yeTi입니다.
오늘은 객체 지향 분석 및 설계(OOAD)와 객체 지향 프로그래밍(OOP) 의 개념을 다뤄보고자 합니다.

계기

2023년 5월 11일 안영회 대표님과의 대화에서 처음 접한 개념이 있습니다.

객체 지향 분석 및 설계(OOAD) 인데요.
당시에는 소프트웨어의 근현대사를 듣는 느낌에 재미있게 들었지만 어떻게 생각을 이어나가야 할지는 느껴지지 않았습니다.

그러나 최근에서야 OO 라는 개념이 커뮤니케이션을 함에 있어 인간이 가진 인지 능력을 활용하여 소프트웨어의 복잡도를 다루는 시도였다는 느낌이 들어 이를 글로 옮겨보고자 합니다.

OOAD란 무엇인가?

객체 지향 분석 및 설계(OOAD)는 시스템을 상호 작용하는 객체들의 집합으로 시각화하여 분석하고 설계하는 방법론입니다. OOAD는 분석 단계와 설계 단계의 두 가지 주요 단계로 나눌 수 있습니다.

1. 분석 단계: 이 단계는 문제 도메인을 이해하는 데 중점을 둡니다. 시스템의 요구 사항을 파악하고, 필요한 객체와 그 상호작용을 결정하며, 시스템의 기능을 모델링합니다. UML(통합 모델링 언어) 같은 도구를 사용하여 시스템의 구조와 동작을 나타내는 다이어그램을 작성합니다.
2. 설계 단계: 분석이 완료된 후, 설계 단계에서는 요구 사항을 시스템의 청사진으로 변환합니다. 이 단계에서는 상세한 아키텍처, 클래스 계층 구조, 객체 상호작용을 정의합니다. 결과물은 개발자에게 전달될 수 있는 포괄적인 설계입니다.

OOP란 무엇인가?

객체 지향 프로그래밍(OOP)은 객체라는 개념을 중심으로 한 프로그래밍 패러다임입니다. Java, C++, Python과 같은 OOP 언어는 객체를 생성하고 조작하여 소프트웨어 애플리케이션을 구축할 수 있도록 지원합니다.

제가 생각하는 OOP는 이렇습니다.

지향하다. (feat. Object-oriented Programming) 에서 언급한 것처럼 객체를 지향한다는 것은 구현 활동을 함에 있어서 반응하는 개념의 이상화(idealizations) 를 정의하고 그 집합을 만들어 나가겠다는 약속을 한 것입니다. 일회성 기법이 아니고 약속이라고 표현한 이유는 일회성의 설계 기법이나 구현 기법이 아닌 지속적으로 추구해야하는 이상향적 가치이기 때문입니다. - 앨런 케이는 왜 세포에서 영감을 받아 객체지향을 말했을까? (feat. OOP) 中

OOAD의 역사적 배경

OOAD의 기원은 객체 지향 프로그래밍 개념의 진화로 거슬러 올라갑니다:

• 객체 지향 프로그래밍(OOP): 앨런 케이(Alan Kay)가 명명한 OOP는 객체 개념을 도입하여 기초를 마련했습니다. 초기 OOP 언어인 Simula 67과 Smalltalk는 객체와 클래스의 기본 원칙을 소개했습니다.
• OOAD 방법론: 1980년대와 1990년대에 Grady Booch의 Booch Method, Ivar Jacobson의 객체 지향 소프트웨어 엔지니어링(OOSE), 그리고 Booch, Jacobson, James Rumbaugh가 개발한 UML(통합 모델링 언어)과 같은 방법론은 OOAD의 공식화와 채택에 중요한 역할을 했습니다. 이러한 방법론은 시스템 분석과 설계를 구조화된 접근 방식으로 통합하여 객체 지향 원칙을 모든 단계에 포함시켰습니다.

OOAD와 OOP의 차이

OOAD와 OOP는 풀고자하는 문제의 영역이 다릅니다. OOAD는 객체라는 개념을 소프트웨어를 위한 분석 및 설계에 영역에서 다루는 것이고, OOP는 객체라는 개념을 소프트웨어의 구현의 영역에서 다루는 것입니다.

• OOAD는 청사진을 제공합니다: OOAD는 소프트웨어를 분석, 설계 단계에서 개념화합니다. 객체를 식별하고, 그들의 책임을 정의하며, 상호작용을 이해하기 위한 구조화된 접근 방식을 제공합니다. 이 청사진은 개발자에게 가이드 역할을 합니다.
• OOP는 설계를 구현합니다: OOP는 OOAD 과정에서 생성된 설계를 실행 가능한 코드로 변환합니다. 캡슐화, 상속, 다형성과 같은 OOP의 원칙과 특징은 설계된 시스템을 효율적으로 구현하는 데 도움을 줍니다.

여기서 OOAD 를 응용하여 MDD, MDA 류의 개념들이 나타났는데요. 이는 안영회 대표님께서 다루신 것이 있습니다. 폭포수 방식 설계는 기술 부채를 남긴다

결론

OOAD와 OOP의 차이를 이해하는 것이 어떠한 실질적인 효과가 있는지는 잘 모르겠습니다.

그러나 지속적으로 초점이 맞춰지는 부분은 소프트웨어를 만드는 작업에서 의사소통이 중요하다는 것입니다. 왜냐하면 소프트웨어를 만든다는 것은 추상적인 개념을 실체화 해나가는 과정인데, 실체화를 해나가는데 있어 결과가 우리에게 만족스러워야 한다는 것입니다.

만족스럽다고 표현한 이유는 실체화의 결과가 돈을 벌어다 주기를 기대할 수도 있지만 다른 만족감으로 대체될 수도 있기 때문입니다.

이런 상황에서 객체지향 을 분석, 설계 단계에서 하던 구현 단계에서 하던 중요한 것은 인간이 가장 효율적으로 인지할 수 있는 개념 이라는 것을 활용하겠다는 것이 중요한 점이라는 생각이 들었습니다.