| 객체지향 방법론 (Object Oriented Methodology) |
| - 본 글은 객체지향 방법론의 개략이며 Rational社의 객체지향 방법론인 Objectory Process의 개요서 부분 중 일부를 번역한 내용입니다. |
| 1. 생명주기 구조(LifeCycle Structure) |
소프트웨어 생명 주기는 여러주기로 나누어 지며, 각 주기는 제품의 새로운 생산물을 만든다. 본 방법론은 4개의 연속적인 단계로 하나의 개발 주기를 이룬다.
개념화 단계동안 시스템에 대한 비즈니스 사례(Business Case)를 만들고 프로젝트 범위(Scope)를 정의한다. 이를 성취하기 위해서는 시스템과 상호작용을 하는 모든 외부 엔티티(Actor)를 명시하고, 상위 레벨(High Level)에서 상호작용의 특징을 정의한다. 여기에는 모든 유스케이스(Use Case)를 명시하고 중요한 몇 가지를 설명하는 것도 포함된다. 비즈니스 사례는 성공기준(Success Criteria), 위험관리(Risk Management), 필요한 자원의 평가, 주요한 이정표 날짜를 보여주는 단계별 계획을 포함한다. 개념화 단계의 마지막에는 프로젝트 목적을 검사하고 개발 진행여부를 결정한다. 1.2 상세화 단계(Elaboration Phase) 상세화 단계의 목표는 문제영역(Problem Domain)을 분석하고 견고한 아키텍쳐 토대를 마련하고 프로젝트 계획을 개발하며 프로젝트에서 가장 위험한 요소를 제거하는 것이다. 아키텍쳐에 대한 결정은 전체 시스템의 충분한 이해를 통하여 이루어져야 한다. 이것은 유스케이스를 기술하고 추가적인 요구사항과 같은 제약사항을 고려하는 것을 의미한다. 아키텍쳐를 검증하기 위해서는 선정된 아키텍쳐를 실현하고(Demonstrates) 중요한 유스케이스를 실행하는 시스템을 구현하는 것이다. 상세화 단계의 마지막에는 상세한 시스템의 목적과 범위 및 아키텍쳐 선정과 주요 위험을 검사한다. 1.3 구축 단계(Construction Phase) 구축 단계에서는 사용자들(User Community)에게 전이할 수 있도록 반복 및 점증적으로 제품을 완전히 개발하는 것이다. 이것은 나머지 유스케이스를 기술하고 설계부문을 더욱 충실하게 하며, 구현을 완전히 끝내고 소프트웨어를 테스트하는 것을 의미한다. 구축단계의 마지막에는 소프트웨어와 환경과 사용자들이 운영될 준비가 되었는지를 결정한다. 1.4 전이 단계(Transition Phase) 전이 단계에서는 소프트웨어를 사용자들(User Community)에게 전달하는 것이다. 제품이 사용자의 손에 전해졌을 때에는, 시스템에 적합하도록 추가적인 개발 및 발견되지 않은 문제점을 수정하고 미루어 놓은 사항들(Features)을 마무리 짓는다. 일반적으로 이 단계는 시스템의 "베타 릴리즈(Beta Release)"로 시작된다. 전이 단계의 마지막에는 생명주기 목적의 충족여부 및 또 다른 개발 주기의 시작여부를 결정해야 한다. 또한 프로세스를 개선하기 위해 프로젝트에서 경험한 것을 여기서 정리한다. 1.5 반복(Iteration) 방법론 프로세스에서의 각 단계는 여러 번의 반복으로 나누어질 수 있다. 반복은 하나의 완전한 개발 루프로서 내부적 혹은 외부적 실행가능한 제품(개발내에서 최종 제품의 부분적인 집합)을 만들어낸다. 이 실행 가능한 제품은 반복과 반복을 거듭하므로서 점증적으로 발전하여 최종 시스템이 된다.
이는 다음 그림과 같이 여러 반복들이 서로 다른 부분에 강조를 하면서 4단계를 수행하는 모습으로 나타날 수 있다.
이 반복적인 접근방법의 중요한 점은 산출물은 초기에 기술되며 계속적으로 단계가 지나감에 따라 증대되며 성숙해진다.
|
| 2. 프로세스 컴포넌트(Process Component) |
2.1 프로세스 표현(Process Representation) 본 방법론의 프로세스가이드에서는 작업자(Workers)와 활동(Activities)과 작업흐름(Workflows)에 의하여 프로세스 컴포넌트를 기술한다. 수행하는 산출물은 산출물가이드에서 기술하고 있다.
프로젝트 관리자에 적합한 사람으로는 그 관련된 능력을 소지한 사람으로 볼 수 있다. 주어진 개개인이 한 작업자의 연관된 활동, 행위를 수행하고, 작업자와 연관되어 있는 모든 산출물에 대한 책임을 갖는 방법으로, 프로젝트 관리자는 이들 개개인을 작업자와 연관시킬 것이다.
예를 들어서, 클래스의 설계자는 구현자(Implementer)가 될 수 있다. 주어진 유스케이스에서 동일한 개인이 유스케이스 명세자(Specifier)와 유스케이스 설계자로 행동할 수 있다. 2.2 프로세스 컴포넌트와 모델(Process Components and Models) 프로세스 컴포넌트는 연관된 집합의 활동과 산출물을 가지고 있다. 가장 중요한 산출물은 각 프로세스 컴포넌트가 산출하는 모델이다. 즉 유스케이스 모델, 설계 모델, 구현 모델 그리고 테스트 모델이다. 아래 그림은 프로세스 컴포넌트와 모델의 관계도를 보여주고 있다.
프로세스 컴포넌트 중 요구사항 수집의 목표는 시스템이 무엇이며 무엇을 하는가를 기술하고 개발자와 고객이 기술서에 동의하도록 하는 것이다. 이를 위해서 시스템의 범위를 정하고 시스템의 주위 환경 및 행동을 정의한다. 시스템 요구사항이 존재할 뿐만 아니라 고객과 잠재적인 사용자는 정보의 중요한 소스(Sources)이다. 요구사항 수집을 하므로써 유스케이스 모델과 추가 요구사항(Supplementary Requirements)을 만들어 낸다. 유스케이스 모델은 사용자와 개발자에게 필수적인 요소이다. 사용자에겐 예상한 시스템이 모델에 잘 반영되었는가를 평가하기위해 모델이 필요하며, 개발자에게는 시스템상에서 요구사항을 보다 잘 이해하기 위해서 모델이 필요하다. 유스케이스 모델은 프로젝트에 참여하고 있는 모든 사람에게 유용하다. 유스케이스 모델은 액터(Actors)와 유스케이스(Use Cases)로 구성되어 있다. 액터는 사용자와, 개발되어질 시스템과 상호작용을 하는 다른 시스템을 의미한다. 액터는 시스템 범위를 정하는 것을 도와주고, 시스템이 어떻게 될 것이다라는 명확한 그림을 제공한다. 유스케이스는 시스템의 행위를 표현한다. 유스케이스는 액터의 요구사항에 의해 개발되어지기 때문에 시스템은 사용자에게 보다 적절하게 될 수 있다. 아래 그림은 재활용품 수집기(Recycling-machine) 시스템에 대한 유스케이스 모델의 예를 보여주고 있다.
유스케이스 역할은 시스템의 개발 주기 전체에 걸쳐 통합된 매개체(Thread)의 기능을 하는 것이다. 동일한 유스케이스 모델이 요구사항 수집, 분석 및 설계와 테스트 동안에 사용된다. ▶ 작업자와 작업흐름(Workers and Workflow) 각 작업자는 활동 집합과 행동에 대해 책임을 진다. 각 프로세스 컴포넌트는 고유의 작업자들과 그 작업자가 활동을 진행하는 논리적 방법인 작업흐름을 가지고 있다. 아래의 작업자들은 요구사항 수집에서 정의된다.
프로세스 컴포넌트 중 분석 및 설계의 목표는 구현 단계에서 시스템이 어떻게 실현되는가를 보여주는 것이다. 아래 사항을 만족하는 시스템을 구축하여야 한다.
분석 및 설계에서는 소스 코드의 추상적 개념을 보여주는 설계 모델을 만들어 낸다. 설계 모델은 어떻게 소스 코드가 구조화되어져 있고 쓰여졌는지를 보여주는 청사진과 같은 역할을 한다. 설계 또한 유스케이스의 내부에 관한(Inside-view) 설명서 또는 참여하는 객체/클래스의 관점에서 유스케이스가 어떻게 실현되는지를 기술한 유스케이스 실현(Use-Case Realization)을 만든다. 설계 모델은 설계 패키지에 구조화된 설계 클래스들로 구성되어 있다. 또한 설계 모델은 유스케이스를 수행하기 위해서 어떻게 이들 설계 클래스의 객체들이 상호작용하고 있는지를 기술한 내용을 담고 있다. 설계 활동은 아키텍쳐 측면에 집중한다. 이 아키텍쳐의 생산(Production) 및 확인(Validation)은 초기 설계 반복의 주요한 초점이 된다. 아키텍쳐는 몇 개의 아키텍쳐(Architectural) 뷰에 의해 표현된다. 이들 뷰에는 주요하고 구조적인 설계 결정사항들이 수집된다. 본질적으로 아키텍쳐 뷰는 상세부분에서 탈피하여 중요한 특성을 보다 쉽게 볼 수 있도록 전체 설계를 추상화 혹은 단순화하는 것이다. 아키텍쳐는 좋은 설계 모델을 개발하는 것 뿐만 아니라 시스템 개발 동안 모델의 품질을 증대시키기 위한 중요한 수단이다. ▶ 작업자와 작업흐름(Workers and Workflow) 아래의 작업자들은 분석 및 설계에서 정의된다.
시스템은 구현을 통해서 생성되는 소스, 즉 소스 코드 파일(Source-Code Files), 헤더 파일(Header Files), 메이크 파일(Make Files) 등에 의해서 실현된다. 이 소스는 실행 가능한 시스템을 만들어 낼 것이다. 그리고 소스는 구현 패키지(Implementation Packages)에 구성된 모듈(Modules)로 이루어져 있는 구현 모델(Implementation Model)에서 설명된다. 설계 모델은 구현을 위한 기초 자료가 된다. 구현은 별개의 클래스 또는 패키지의 테스팅을 포함하고 있지만, 동시에 패키지와 클래스를 함께 테스팅하는 것은 포함하지 않는다. 이것은 다음 프로세스 컴포넌트 "테스트(Test)"에서 설명된다. ▶ 작업자와 작업흐름(Workers and Workflow) 아래의 작업자들은 분석 및 설계에서 정의된다.
테스트는 시스템 전체를 검증한다. 참여하고 있는 클래스들이 잘 어울려져 올바르게 작동하는가를 검증하기 위해서는, 먼저 개별적으로 유스케이스를 테스트한다. 그런 후에 유스케이스 설명서를(어떤 관점에서의) 테스트의 입력 자료로 사용하여 전체적으로 시스템을 테스트 한다. 테스트를 끝낸 후에 시스템은 전달되어 진다. ▶ 작업자와 작업흐름(Workers and Workflow) 아래의 작업자들은 분석 및 설계에서 정의된다.
|
'JAVA > JEE' 카테고리의 다른 글
| [펌] Oracle9i JDeveloper 기술 정보 (0) | 2004.08.06 |
|---|---|
| [펌] SOA소개 - 가트너 14 April 2003 (0) | 2004.04.14 |
| [펌] 웹 서비스와 SOA(Service Oriented Architecture) (0) | 2004.04.01 |
| [펌] 사용성을 만족시키는 인포메이션 아키텍처 (0) | 2004.04.01 |
| [펌] 방법론 (0) | 2004.04.01 |