객체지향 개발방법론 편집하기

'''객체지향 개발방법론'''<!-- 객체지향 개발방법론 -->이란 프로그램을 객체와 객체 간의 인터페이스 형태로 구성하기 위하여 문제 영역에서 객체, 클래스 및 이들 관의 관계를 식별하여 설계 모델로 변환하는 [[개발방법론]]이다.<ref>〈[https://middleware.tistory.com/entry/%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%EB%B0%A9%EB%B2%95%EB%A1%A0 객체지향 방법론이란]〉, 《무강》</ref>

== 개요 ==
객체지향 개발방법론은 현실 세계의 [[엔터티]](entity)를 [[속성]](attribute)과 [[메소드]](method)가 결합된 형태의 [[객체]](object)로 표현하고 메시지 통신을 이용하여 프로그램을 개발하기위한 절차 및 기법, 도구 등 상호작용함으로써 전체시스템을 운영하는 이론적 체계이다.<ref name="객체방법론">〈[https://m.blog.naver.com/roser111/221682433987 객체지향 방법론]〉, 《Network 이야기》</ref>

== 역사 ==
1990년대를 대표하는 정보기술은 [[인터넷]]과 [[객체지향]] 기술이라고 할 수 있다. 1990년대 들어 PC의 성능은 더욱 강력해지고 인터넷을 비롯한 네트워크 기술의 현저한 발전으로 다양한 소프트웨어를 대량으로 생산할 필요가 대두되었다. 객체는 실 세계의 개념을 가장 정확하게 반영할 수 있고 객체의 재사용을 통해 개발생산성을 향상시킬 수 있다는 점에서 객체지향 기술이 부각되게 되었다.

1990년 중반까지 수많은 객체지향 방법이 발표되었으며 Rumbaugh의 OMT(Object Modeling Technique), Booch의 OOD(Object-Oriented Design), Jacobson의 OOSE(Object-Oriented Software Engineering) 등과 같은 1세대 방법론과 이들을 보완한 HP사의 FUSION, MOSES와 같은 2세대 방법론으로 구분하기도 한다. 이와 같은 다양한 개발방법론과 서로 다른 방법 사이의 표기방법 차이로 인해 개발자에게 혼란을 야기하게 되었고 이를 해결할 목적으로 OMG에서는 객체지향 분석 및 설계를 위한 표기법의 표준화를 추진하게 되었다.

Rational사 주도의 UML(Unified Modeling Language)과 OPEN(Object-oriented Process, Environment, and Notation) 컨소시엄의 OML(Open Modeling Language) 등이 경쟁한 결과1997년 말 UML이 표준으로 확정되었으며 현재는 OPEN 방법을 비롯한 대부분의 다른 객체지향 방법론에서 UML을 채택하고 있다. 대부분의 객체지향 방법론은 사용자의 만족도 향상 및 개발자의 동기 부여를 위한 반복적이고 점진적인 개발 모형을 택하고 있다. 하지만 객체의 재사용을 통한 개발생산성의 효과는 미미한 것으로 파악되고 있다.<ref name="객체지향">〈[http://blog.daum.net/bigdown/352 객체지향 방법론 역사]〉, 《기억을 이기는 기록》</ref>

== 등장배경 ==
<ref name="객체방법론" />
:{|class=wikitable  width=700 style="background-color:#ffffee" 
|-
!align=center style="background-color:#ffeecc"|구분
!align=center style="background-color:#ffeecc"|내용
|-
|align=center| '''개발 측면'''
| '''*''' 전통적인 개발 방법론의 문제점 극복 <br> '''*''' 저품질, 고위험요소로 개발 생산성 저하 <br> '''*''' 소프트웨어 위기를 해결하기 위한 필요성 증대 <br> '''*''' 재사용성, 확장성 증대 필요 
|-
|align=center| '''사용자 측면'''
| '''*''' 사용자들의 욕구 증대 <br> '''*''' 컴퓨팅 환경에 대한 보다 많은 기능(Functionality), 단순성, 사용 편의성
|-
|align=center| '''소프트웨어 위기 극복'''
| '''*''' 낮은 생산성, 납기 지연과 경영 환경의 변화 
|-
|align=center| '''규칙 혼선 발생'''
| '''*''' 사용자 요구사항 조사시 사용자는 명확한 요구사항 제시 미흡 <br> '''*''' 사용자는 시스템 개발시 짧은 개발 주기와 더 많은 융통성을 원함 <br> '''*''' 사용자의 초기 요구 사항에 대한 반영이 빈약
|-
|align=center| '''위험관리 실패 가능성 증가'''
| '''*''' 전통적인 Waterfall방법은 문제 발견이 늦어질 수 있음
|-
|align=center| '''소프트웨어 복잡성 증가'''
| '''*''' 규모가 커지면서 시스템 전체를 이해하는 것이 불가능 해짐 <br> '''*''' 소프트웨어는 계속 진화하면서 확장됨
|}

== 특징 ==
<ref name="객체방법론" />
:{|class=wikitable  width=1000 style="background-color:#ffffee" 
|-
!align=center style="background-color:#ffeecc"|핵심개념
!align=center style="background-color:#ffeecc" colspan="2"|상세내용
|-
|align=center rowspan="4"| '''캡슐화'''
|-
|align=center| 정의
|'''*''' 외부에 대한 가시적인 부분과 내부 및 구현에 관계되는 세부적인 사항을 분리하는 모델링 및 구현기법 <br> '''*''' 클래스를 사용하여 정의한다.
|- 
|align=center| 특징
|'''*''' Private: 변하기 쉬운것은 감추며, 외부에서 변경해도 영향을 받지 않는다. <br> '''*''' Public: 변하기 어려운 것은 드러내며, 변하기 어려워 외부에서 사용해도 변경될 일이 적다.
|-
|align=center| 장점
|'''*''' Readability 향상: 유지보수에 용이하다. <br> '''*''' 변경용이성/재사용성이 높은 소프트웨어 개발 가능하다. <br> '''*''' 정보은닉(Information Hiding)으로 내부자료에 대한 일관성을 유지한다. <br> '''*''' 객체간 인터페이스(메시지)를 이용하여 종속성 최소화
|-
|align=center rowspan="4"| '''추상화'''
|-
|align=center| 정의
|'''*''' 어떤 영역에서 필요로 하는 속성이나 행동을 추출하는 작업이다.
|- 
|align=center| 특징
|'''*''' 클래스를 이용함으로써 데이터와 프로세스를 함께 추상화의 구조에 넣어 보다 완벽한 추상화를 실현한다.
|-
|align=center| 장점
|'''*''' 객체 중심의 안정된 모델 구축한다. <br> '''*''' 현실 세계를 자연스럽게 표현한다. <br> '''*''' 분석의 초점이 명확하다.
|-
|align=center rowspan="4"| '''다형성'''
|-
|align=center| 정의
|'''*''' 동일한 외부 명령에 대해 각 객체가 서로 다른 방식으로 명령을 수행한다.
|- 
|align=center| Over-Loading
|'''*''' 메소드의 이름은 같으나, Argument 나 Return Type이 다른 경우이다. <br> '''*''' 일반적으로 단일 클래스내 동일 메소드가 중복 정의된 경우이다. <br> '''*''' 상속구조에서 상위 클래스가 추상 클래스이고 메서드도 추상 메서드일 경우
|-
|align=center| Over-Riding
|'''*''' 부모클래스에서 정의한 메소드를 자식클래스에서 무시하고 재정의한 경우. <br> '''*''' Argument와 Return Type이 동일하다.
|-
|align=center rowspan="4"| '''정보은닉'''
|-
|align=center| 정의
|'''*''' 캡슐화된 항목들이 다른 객체(Object)에게 보이지 않게 하는 것이다. <br> '''*''' 메시지 전달에 의해 다른 클래스 내의 메소드가 호출된다.
|- 
|align=center| 특징
|'''*''' 블랙박스 역할 : 데이터와 메서드를 숨기는 장치로, 객체의 사용자와 제공자의 역할을 명확히 분리해준다. <br> '''*''' 인터페이스를 통한 접근 : 사용자가 공개 인터페이스를 사용함으로써 객체 내부의 자료구조를 몰라도 객체를 쉽게 이용한다. <br> '''*''' 자료구조 변경이 용이 : 제공자가 객체 내부의 자료구조를 변경해도 <br> &nbsp;&nbsp; 그 객체와 인터페이스를 통해 통신하는 사용자에게는 영향을 주지 않으므로 부담 없이 자료구조를 변경한다.
|-
|align=center| 장점
|'''*''' 독립성 향상 : 다른 모듈과 관계가 적어 모듈의 독립성을 높여준다. <br> '''*''' 수정 용이 : 인터페이스가 바뀌지 않으면 다른 모듈에 미치는 영향을 고려 할 필요 없다. <br> '''*''' 이해도 증진 : 다른 모듈의 구현 내용을 자세히 알 필요 없이 제공하는 기능만 알면 메시지를 통해 사용 가능하다. <br> '''*''' 확장성 증가 : 모듈 내의 데이터와 알고리즘을 변경하기 쉬워 기능을 추가가 쉽다.
|-
|align=center rowspan="6"| '''상속성'''
|-
|align=center| 정의
|'''*''' 하위 클래스에게 자신의 속성과 메소드를 사용할 수 있도록 허용한다.
|- 
|align=center| 단일 상속
|'''*'''부모와 자식 클래스 간의 관계가 슈퍼 클래스와 서브 클래스로 유지된다.
|-
|align=center| 다중 상속
|'''*''' 하나의 클래스가 하나 이상의 클래스로부터 상속 받는다.
|-
|align=center| 반복 상속
|'''*''' 같은 조부모 클래스로부터 상속 받은 두 부모 클래스로부터 상속 받는다.
|-
|align=center| 장점
|'''*''' 이해 용이 : 개별 클래스를 상속 관계로 묶어 클래스 간의 전체 구조이해가 용이하다. <br> '''*''' 재사용성 증대 : 데이터/메서드의 오버로딩을 피하고 기존 클래스것을 재사용한다. <br> '''*''' 확장 용이 : 새로운 클래스, 데이터, 메서드를 추가가 쉽다. <br> '''*''' 유지보수 용이 : 데이터와 메서드 변경시 상위만 수정하여 전체적 일관성을 유지한다. <br> '''*''' 추상화 가능 :  일반화, 특수화의 관계를 통해 추상화 단계를 표현한다.
|}

=== 개념 및 구성요소 ===
[[파일:객체지향방법론개념도.png|800픽셀|가운데|섬네일|객체지향 개발 방법론 개념도]]

<ref name="객체방법론" />
:{|class=wikitable  width=750 style="background-color:#ffffee" 
|-
!align=center style="background-color:#ffeecc"|구분
!align=center style="background-color:#ffeecc"|내용
|-
|align=center| '''클래스'''
| '''*''' 같은 종류(또는 문제 해결을 위한)의 집단에 속한 속성(attribute)과 행위(behavior)이다. <br> '''*''' 객체 지향 프로그램의 기본적인 사용자 정의 데이터형 (user define data type)이다.
|-
|align=center| '''객체'''
| '''*''' 자신 고유의 데이터(attribute)를 가지며 클래스에서 정의한 행위(behavior)를 수행한다. <br> '''*''' 객체는 클래스의 한 인스턴스(instance)가 된다. <br> '''*''' 데이터(실체)와 그 데이터에 관련되는 동작(절차, 방법, 기능)을 모두 포함한 개념이다.
|-
|align=center| '''메소드'''
| '''*''' 클래스로부터 생성된 객체를 사용하는 방법
|-
|align=center| '''메시지'''
| '''*''' Sender 와 Receiver 객체들간의 상호작용의 수단으로 다른 객체에 특정 작업을 요청하는 신호이다. <br> '''*''' 수신객체이름, 오퍼레이션 이름, 매개변수로 구성된다.
|}
=== 객체지향 방법론 특징 ===
<ref name="객체방법론" />
:{|class=wikitable  width=750 style="background-color:#ffffee" 
|-
!align=center style="background-color:#ffeecc"|특성
!align=center style="background-color:#ffeecc"|내용
|-
|align=center| '''모형의 적합성'''
| '''*''' 객체중심 모형은 우리의 사고 방식과 유사하다. <br> '''*''' 뚜렷하게 구별되는 객체로 나누고 객체들의 메시지는 상호 작용수단으로 활용한다.
|-
|align=center| '''재사용 용이'''
| '''*''' Openness, Closeness를 다 갖춘 재사용 단위이다. <br> '''*''' 상속(inheritance), 다형성(polymorphism) 등이 있다.
|-
|align=center| '''Time-To-Market'''
| '''*''' 종래의 폭포수모형은 단계가 길고 문서 작업이 많다. <br> '''*''' 클래스의 재사용과 확장에 의한 빠른 개발이 가능
|-
|align=center| '''설계와 프로그래밍의 매핑'''
| '''*''' 개발 각 단계의 전환이 자연스럽고 신속하다. 
|}

=== 객체지향 방법론의 단계 ===
개념화 단계(Inception Phase)
:- 시스템에 대한 비즈니스 사례(Business Case)를 만들고 프로젝트 범위(Scope)를 정의한다.
:- 시스템과 상호작용을 하는 모든 외부 엔티티(Actor)를 명시하고, 상위 레벨(High Level)에서 상호작용의 특징을 정의한다.
:- 모든 유스케이스(Use Case)를 명시하고 중요한 몇 가지를 설명하는 것도 포함된다.
:- 비즈니스 사례는 성공기준(Success Criteria), 위험관리(RiskManagement), 필요한 자원의 평가, 주요한 이정표 날짜를 보여주는 단계별 계획을 포함한다.
:- 개념화 단계의 마지막에는 프로젝트 목적을 검사하고 개발 진행여부를 결정한다.

상세화 단계(Elaboration Phase)
:- 문제영역(Problem Domain)을 분석하고 견고한 아키텍쳐 토대를 마련하고 프로젝트 계획을 개발하며 프로젝트에서 가장 위험한 요소를 제거하는 것이다.
:- 아키텍쳐에 대한 결정은 전체 시스템의 충분한 이해를 통하여 이루어져야 한다. 이것은 유스케이스를 기술하고 추가적인 요구사항과 같은 제약사항을 고려하는 것을 의미한다.
:- 아키텍처를 검증하기 위해서는 선정된 아키텍쳐를 실현하고(Demonstrates) 중요한 유스케이스를 실행하는 시스템을 구현하는 것이다.
:- 상세화 단계의 마지막에는 상세한 시스템의 목적과 범위 및 아키텍쳐 선정과 주요 위험을 검사한다.

구축 단계(Construction Phase)
:- 구축 단계에서는 사용자들(User Community)에게 전이할 수 있도록 반복 및 점증적으로 제품을 완전히 개발하는 것이다. 이것은 나머지 유스케이스를 기술하고 설계부문을 더욱 충실하게 하며, 구현을 완전히 끝내고 소프트웨어를 테스트하는 것을 의미한다.
:- 구축단계의 마지막에는 소프트웨어와 환경과 사용자들이 운영될 준비가 되었는지를 결정한다.

전이 단계(Transition Phase)
:- 소프트웨어를 사용자들(User Community)에게 전달하는 것이다.
:- 제품이 사용자의 손에 전해졌을 때에는, 시스템에 적합하도록 추가적인 개발 및 발견되지 않은 문제점을 수정하고 미루어 놓은 사항들(Features)을 마무리 짓는다.
:- 일반적으로 이 단계는 시스템의 "베타 릴리즈(Beta Release)"로 시작된다.
:- 전이 단계의 마지막에는 생명주기 목적의 충족여부 및 또 다른 개발 주기의 시작여부를 결정해야 한다. 또한 프로세스를 개선하기 위해 프로젝트에서 경험한 것을 여기서 정리한다.

=== 객체지향 방법론의 문제점 ===
* 이진형태의 파일을 연결하는 표준이 부재하며 각 객체는 동일 컴파일러를 사용해야 한다.
* 다른 언어간에 객체를 호출하거나 재사용은 거의 불가능하다.
* 개발은 Low Level Coding이며 테스트 또한 White Box테스트가 주를 이룬다.
* 완성된 이진형태의 객체를 변경하고자 하면 소스레벨의 어플리케이션을 재 컴파일 해야 한다.
* 개발방법론은 전통적인 SDLC를 따르므로 문제점 인지 및 대응, 문서화에 제약이 따르며 절차적 프로그래밍에 익숙한 개발자에게는 충격으로 받아줄 수 있다.
* 개발 수준이 저 수준의 추상화 개념이므로 실제로 재사용 가능한 소프트웨어 개발은 기대하기 어렵다.
* 개발의 생산성 및 유지보수성을 위한 아키텍쳐 및 표준적용이 어렵다.
* 대규모 프로젝트에서의 확장성이 떨어진다. <ref name="객체지향" />

{{각주}} 

== 같이 보기 ==
* [[개발방법론]]
* [[객체]]
* [[객체지향 프로그래밍]]

{{프로그래밍|검토 필요}}