객체지향적 분석과 디자인(Object-Oriented Analysis and Design) — 소개 (Part 1) [번역]
저는 1년 동안 스타트업에서 리드 개발자로서 4개의 프로젝트를 관리했습니다. 저희 팀에서 효과적이었던 소프트웨어 공학적 접근 방법 중 하나인 OOAD 를 잘 소개하는 글이 있어서 저자의 동의 하에 번역하였습니다.
이 글의 원문 ( Source )
이 글은 아래 글을 번역한 글입니다.
객체 지향 개념Object-Oriented Analysis and Design (OOAD)
- SLDC(Software Development Life Cycle) 에서의 OOAD
- 객체지향적 분석 (Object-Oriented Analysis)
- 객체지향적 디자인 (Object-Oriented Design)
- 다른 도식들(Diagrams)System Modeling
- 다른 관점들(Different Perspectives)
- UML(Unified Modeling Language)
객체 지향 개념
객체 지향은 프로그래밍 패러다임 중 하나이다. 객체지향 자체는 프로그래밍 언어는 아니지만, 많은 언어의 바탕이 되는 개념의 집합이다.
만약 객체지향 개념에 익숙하지 않는다면, 다음 글을 보기를 바란다.
→ 객체지향 프로그래밍 이야기
객체지향 언어에서는 모든 것이 객체로부터 시작되고, 객체에 초점이 맞추어져 있다. 이러한 객체지향 언어에서, 하나의 큰 프로그램은 작은 프로그램들을 포함하는 객체들로 쪼개지고, 각각의 객체는 어플리케이션의 서로 다른 부분들을 가리킨다.
그리고 각각의 객체는 그것의 데이터와 로직을 가지고 있고, 서로 다른 객체들끼리 서로 통신한다.
이러한 객체는 무작위로 이루어진 것이 아니다. 객체들은 사람이 일상 생활에서 해결하고자 하는 특정 문제에 대해 말하고 생각하는 방식을 표현한다.
객체들은 프로그램에 존재하는 무엇이든(직원, 이미지, 은행 계좌, 우주선, 비디오 클립, 오디오 파일 등) 표현한다.
Object-Oriented Analysis and Design (OOAD)
OOAD 는 객체지향 개념을 적용해 시스템을 분석하고 디자인하는 구조화된 방법(structured method)으로, SW 의 개발 생명주기 동안 시스템 모델 조합을 제공한다.
SLDC(Software Development Life Cycle) 에서의 OOAD
SW의 생명주기는 일반적으로, 문제의 추상화된 정의에서 시작해 디자인하고, 코드로 만들고, 테스팅하고, 최종적으로 배포하는 단계로 나누어진다.
이 과정의 초기 단계는 (요구사항) 분석과 디자인이다.
분석과 디자인의 차이는 ‘무엇’과 ‘어떻게’로 설명할 수 있다.
분석 단계에서, 개발자는 사용자와 도메인 전문가와 함께 시스템이 무엇을 해야 하는지 정의한다. 이 단계에서 세부적인 구현에 관해서는 대부분 혹은 완전히 고려하지 않는다.
분석 단계의 목표는 시스템 모델을 적합한 기술과 같은 제약사항들과 관계 없이 시스템의 모델을 만드는 것이다. 이 과정은 일반적으로 Use cases 와 개념적 모델을 사용하여 가장 중요한 객체들에 대한 추상적 정의를 통해 이루어진다.
디자인 단계는 분석 모델을 개선하고, 필요한 기술과 다른 실행 단계의 제약 사항을 적용한다.
디자인 단계는 객체와 객체의 특성(attributes), 동작(behaviors), 상호작용(interactions) 을 묘사하는 데 초점을 맞춘다. 디자인 모델은 요구되는 모든 세부사항들을 가지고 있어야 한다. 그렇게 함으로, 프로그래머는 코드로 디자인을 구현할 수 있다.
이런 단계들은 반복적이고 점진적인 소프트웨어 방법론에서 가장 잘 수행됩니다. 그러므로, OOAD 의 활동들과 개발된 모델들은 한번에 끝나지 않고, 이러한 단계들을 계속해서 재검토하고 개선해야 합니다.
객체지향적 분석 (Object-Oriented Analysis)
객체지향적 분석에서 해야할 것들은 …
- 요구사항 도출: SW가 무엇을 해야하는지, 어떤 문제를 해결하려고 하는지 정의한다.
- 요구사항 명세: 요구사항을 자세하게 서술한다. 보통 use cases (and scenarios)를 사용하거나 user stories를 사용한다.
- 개념적 모델 (Coceptual Model): 중요한 객체들을 식별(identify)하고 정제(refine)한다. 그리고 객체들간의 관계와 행동을 정의하고 그것들을 간단한 다이어그램으로 그린다.
첫번째 두 활동에 대해서는 이 글에서 설명하지 않겠다. 첫번째 두 활동에 대해서 자세하게 설명된 글은 다음과 같다. Requirements Engineering
객체지향적 디자인 (Object-Oriented Design)
분석 단계는 객체들, 그들간의 관계, 그리고 개념적 모델(객체에 대한 추상적 정의)을 사용한 행위를 식별한다.
디자인 단계에서, 이러한 객체들, 그들의 속성과 행동, 그리고 상호작용을 묘사한다. (개념적 다이어그램을 이용한 클래스 다이어그램을 이용한다. 보통 개념적 모델을 클래스 다이어그램과 매핑시킨다.)
소프트웨어 디자인 원리와 패턴을 적용하는 것 역시 포함된다. 이것들에 대해서는 다음 튜토리얼들에서 다루겠다.
객체지향적 디자인에 사용되는 것들(input)은 객체지향적 분석의 결과물(output)이다. 그러나, 분석과 디자인은 보통 평행하게 발생하고, 한 활동의 결과물이 다른 활동에 쓰인다.
객체지향적 디자인에서, 우리는 …
- 클래스를 묘사하고 그것들의 관계를 클래스 다이어그램으로 표시한다.
- 연속 다이어그램(sequence diagram)을 사용해서 객체들간의 관계를 묘사한다.
- 소프트웨어 디자인원리와 디자인 패턴을 적용한다.
클래스 다이어그램은 필요한 클래스들을 시각화한 것이다. 그리고 클래스 다이어그램을 통해 상속이나 다형성과 같은 객체지향 원리를 실제로 구체화할 수 있다.
이러한 객체들간의 관계를 묘사하는 것은 다른 객체들의 책임과 그 객체들이 가져야할 행동들에 대해 더 잘 이해하게 해준다.
— 다른 도식들(Diagrams)
우리가 다른 관점들로부터 시스템을 모델링할 수 있는 많은 다른 다이어그램이 있다. 객체들간의 관계, 시스템의 구조, 그리고 시스템의 행동 그리고 객체들이 어떻게 이벤트에 반응하는지에 대해서와 같은 다양한 관점들이 있다.
상황(need)에 맞는 다이어그램을 선택하면 된다. 어떤 다이어그램이 명확하지 않은 상황에 대해 생각하거나 의논을 할 때 효과적일지 분명하게 파악해야 한다.
시스템 모델링과 우리가 사용할 다른 모델들은 나중에 다루겠다.
System Modeling
시스템 모델링은 시스템의 모델을 개발하는 과정이고, 각 모델은 시스템의 다른 관점들을 대표한다.
시스템 모델에 대한 가장 중요한 측면은 세부사항으로부터 떨어져 있다는 것이다; 시스템 모델은 시스템의 추상화된 표현이다.
모델들은 대부분 그래픽 표기법에 기초해있다. 그래픽 표기법은 대부분 UML(Unified Model Language) 안에 있는 표기법에 기초해있다. 시스템의 다른 모델들은 세부적인 시스템 설명인 수학적모델과 같은 것들이 있다.
모델들은 분석 과정중에 요구사항을 도출하는 데, 디자인 과정에서는 시스템을 엔지니어들에게 묘사하는데, 그리고 개발 후에는 시스템 구조와 동작을 문서화하는데 사용된다.
다른 관점들(Different Perspectives)
우리는 시스템을 다른 관점으로부터 표현하는 모델이 필요할지 모른다.
- 외부(External), 상황(context)이나 시스템의 환경을 모델링하는 경우
- 상호작용(Interaction), 시스템의 컴포넌트간, 혹은 시스템과 다른 시스템들간의 상호작용을 모델링하는 경우
- 구조적(Structural), 시스템의 구성(organization)이나 시스템에서 처리되는 데이터의 구조를 모델링하는 경우
- 행동(Behavioral), 시스템의 동적인 행동과 이벤트에 어떻게 반응하는지를 모델링하는 경우
UML(Unified Modeling Language)
Unified Modeling Language는 객체지향 모델링의 표준 모델링 언어이다. UML에는 많은 다이어그램이 있지만 보통 사용되는 대부분의 다이어그램은 다음과 같다.
- UseCaseDiagram: 특정 상황에서 시스템과 시스템의 환경(사용자나 시스템) 간의 상호작용을 보여준다.
- Class Diagram: 객체들과 그 객체들간의 관계, 들의 행동과 속성에 대해 보여준다.
- Sequence Diagram: 시스템에서 다른 객체들간의, Actor들과 객체들간의 상호작용을 보여준다.
* Actor: 시스템과 상호작용하는 시스템 외부의 존재 - State Machine Diagram: 시스템 외부, 내부의 이벤트들에 대해 시스템이 어떻게 반응하는지 보여준다.
- Activity Diagram: 시스템 안에서 프로세스들 사이에서 데이터의 흐름을 보여준다.
다이어그램을 그리는 활동은, 적어도 프로젝트의 초기 단계에, 종이나 화이트 보드 위에서 할 수 있다. 그러나 이런 UML 다이어그램들을 그리는데 도움이 되는 몇개의 다이어그래밍 툴들을 이용할 수도 있다.
