객체지향 방법론

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을 채택하고 있다. 대부분의 객체지향 방법론은 사용자의 만족도 향상 및 개발자의 동기 부여를 위한 반복적이고 점진적인 개발 모형을 택하고 있다. 하지만 객체의 재사용을 통한 개발생산성의 효과는 미미한 것으로 파악되고 있다.

객체지향 방법론의 정의

- 현실세계에서 객체(Entity)를 데이터(Attribute)와 함수(Method)를 결합시킨 형태로 표현하는 개념으로 객체간의 메시지 통신을 통해 시스템을 구현하는 개발 방법

- 데이터와 그 위에서 수행할 수 있는 오퍼레이션의 집합인 객체들 사이에 약속화된 메시지를 통해 상호 의사 소통함으로써 필요한 서비스를 제공하는 방식

객체지향의 특성

- Object와 Message

Object란 실 세계에 존재하는 사물을 표현하는 것으로 데이터와 함수로 구성 객체간의 통신은 Message를 통하여 전달하며 외부객체에 의해 함수를 구현하여 객체의 데이터(Attribute)에 접근함

- 캡슐화, 정보은닉

객체의 데이터와 함수를 하나로 묶고 블랙박스화 하여 외부와 접근을 제한 함. 데이터의 임의 변경을 통제하기 위해 메소드를 통해서만 접근이 가능토록 하는 것을 정보 은닉이라고 함.

- Class, Instance

같은 종류 및 특성을 가진 객체들을 모아서 공통의 특성으로 분류하고 탬플릿화 하는 것을 클래스로 정의함. 클래스의 실체들로서 탬필릿화된 클래스에서 파생된 하나의 실제 객체를 인스턴스로 정의함.

- 상속(Inheritance)

클래스간읜 IS-A 및 IS-PART-OF의 계층구조를 통하여 공통 특성을 상위 클래스로부터 물려받는 것을 상속이라함.

다중 상속 : 두 개 이상의 상위 클래스로부터 상속으로 C++ 언어가 이를 지원함.

단일 상속 : 오직 하나의 상위 클래스로부터 상속가능하며 Java 언어가 지원함.

- 다형성(Polymorphism)

하나의 함수의 이름이나 연산자가 여러 목적으로 사용될 수 있는 것

Overriding : 상위클래스에 정의된 Method를 하위 클래스에서 정의

Overloading : 매개변수의 데이터 형식에 따라 같은 이름의 Method 다중정의를 하여 여러 목적으로 사용함.

기존 방법론의 문제점

종래의 구조적 설계기법은 공정 단계가 길고 문서 작업이 많았으나, 객체지향 방법론은 인간의 사고방식과 유사한 분석 및 설계가 가능하고 개발 공전간의 전환이 자연스럽고 신속하다.

항목	구조적 설계기법	객체지향 설계기법
접근방법	Top Down	Bottom Up
설계방향	프로세스 중심(기능위주)	데이터 중심(데이터+연산)
확장성/재사용성	확장어려움/중복 많음	확장용이/재사용성 높음
DBMS/CASE 지원	전통적 DB(파일 및 관계형)/상위레벨지원(다이어그램)	전통적 DB와 객체지향 DB지원 /상위레벨지원(다이어그램)
방법 제시 모델	Jackson, Yourdon, Warnier-orr	UML

객체지향 방법론의 특징

- 사용자, 업무 영역 전문자, 개발자 사이에 상호 이해가 용이 : 가변적인 기능 중심의 분해에서 가시적이고 업무 영역의 불변적인 요소인 객체를 중심으로 추상화와 캡슐화를 진행

- 크고 복잡한 시스템의 이해가 용이 : 객체를 통해 고도의 추상화를 실현

- 사용자의 요구사항과 컴퓨팅 환경의 변화에 강함 : 가변적인 기능이 아닌 보다 불변적인 객체를 우선 식별, 식별된 객체를 중심으로 시스템을 확장

객체지향 방법론의 단계

반복

방법론 프로세스에서의 각 단계는 여러 번의 반복으로 나누어질 수 있다. 반복은 하나의 완전한 개발 루프로서 내부적 혹은 외부적 실행 가능한 제품(개발내에서 최종 제품의 부분적인 집합)을 만들어낸다. 이 실행 가능한 제품은 반복과 반복을 거듭하므로서 점증적으로 발전하여 최종 시스템이 된다. 여러 반복들이 서로 다른 부분에 강조를 하면서 4단계를 수행하는 모습으로 나타날 수 있다.

개념화 단계(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를 따르므로 문제점 인지 및 대응, 문서화에 제약이 따르며 절차적 프로그래밍에 익숙한 개발자에게는 충격으로 받아줄 수 있다.

- 개발 수준이 저 수준의 추상화 개념이므로 실제로 재사용 가능한 소프트웨어 개발은 기대하기 어렵다.

- 개발의 생산성 및 유지보수성을 위한 아키텍쳐 및 표준적용이 어려움

- 대규모 프로젝트에서의 확장성이 떨어짐.