객체지향 방법론 – 개요
- 2019-08-30
- Posted by: javasolution
- Category: 프로젝트방법론
객체지향 방법론 – 개요
객체지향 방법론은 상호작용하는 객체들의 집합으로 세상을 바라보는 객체지향 패러다임을 기반으로 하고 있다.
결국 객체지향 방법들에서는 목적 시스템을 객체 와 그들의 상호작용으로 파악하고 표현하게 된다.
이러한 시각을 바탕으로 객체지 향 방법들은 객체 및 그 구조를 정의하는 정적 관계(static relation)부분과 객체들 간의 상호작용을 정의하는 동적행위(dynamic behavior)부분으로 소프트웨어를 파악 한다.
정적관계는 객체 및 클래스들 사이의 관계가 문제 영역이 존재하는 시간동안 시 간의 흐름에 관계없이 항상 고유하게 유지되는 것이다.
예를 들면 포함관계 (aggregation), 계승관계(inheritance)등이 이에 속한다.
동적행위는 정적 관계와 상대 적인 개념으로 시간의 흐름에 따라 변하는 관계를 말한다.
동적행위는 객체들의 상 태 변화와 이런 상태 변화를 유발시키는 행위에 중점을 둔다. 동적행위는 시간이 흐르면서 연속적으로 이루어지는데, 이러한 연속적인 흐름이 모여 어떤 하나의 작업을 구성한다.
▶ 구조적 방법론과 객체지향 방법론 간의 비교
구조적 방법론 | 객체지향 방법론 |
|
|
객체지향 소프트웨어 개발은 이러한 정적 관계와 동적행위를 분석, 설계, 구현 등 소프트웨어 개발의 전체 과정에 걸쳐 일관되게 적용한다.
분석단계에서는 객체를 추출하고 그들 간의 관계를 파악하며, 객체간의 행위를 파악하게 된다.
설계 단계에는 시스템의 환경을 고려하여 분석과정을 그대로 반복하게 되며, 구현단계에서는 컴퓨터 언어를 고려하여 설계과정을 반복하게 된다.
객체지향 방법들은 위와 같은 공통적인 특성을 가지고 있으나, 각각의 적용 범위와 특화분야가 방법들에 따라 다 양하다.
객체지향 방법론마다 각기 다른 방식으로 묘사되는 여러 관점들을 정리해보면 다 음과 같다.
▶ 객체지향 개발의 관점
개 발 관 점 | 표준 객체지향 개발 모형 |
문제영역/ 구현환경 관점 |
표준 객체지향 개발 모형은 분석, 설계, 구현, 테스트로 단계를 정의한다. 분석과 설계단계를 구분하는 기준은 시스템을 파악하는 관점이 문제영역의 관점이냐 구현환경의 관점이냐에 따른 것이다. |
시스템 내부/ 외부 관점 |
분석단계의 두 번째 활동인 사용자 요구사항 분석 부분에서는 시스템 사용자 및 사용사례 정의를 통해 시스템 외부로부터 시스템의 목적을 파악하고, 사용사례로부터 클래스를 파악함으로써 시스템 내부의 기능을 파악한다. |
정적구조/ 동적행위 관점 |
시스템의 정적구조 및 동적행위의 파악에 대한 내용은 개발 전단계에 걸쳐서 나타난다. 각 단계에서 시스템의 정적구조 및 동적행위는 유기적 연관성을 가진다. |
시스템 추상레벨 관점 |
시스템 추상레벨 관점은 방법론을 구성하는 활동을 통해 직접적으로 나타나지는 않는다. 시스템 추상레벨에 따른 반복적인 개발을 고려하여, 개략설계와 상세설계 부분을 나누어 따로 정의하지는 않았다. |
객체지향 방법론 역시 기본적으로 활동과 산출물로 구성된다. 하지만 일반 방법론과 달리 각 활동을 구성하는 세부 작업은 순차적으로 수행되지 않고 독립적으로 정의된다.
이는 개발 작업을 진행할 때, 수행하는 활동의 순서는 프로세스의 특성에 따라 유동적이기 때문이다.
▶ 객체지향 방법론과 ISO/IEC 12207의 공정 매핑 비교
ISO/IEC 12207 | 객체지향 개발 방법론 | ||
활 동 | 작 업 | 활 동 | 작 업 |
시스템 요구사항 분석 |
∙ 시스템 요건 기술 및 분석 ∙ 시스템 요구사항 평가 |
||
시스템 구조 설계 |
∙ 시스템 개략 설계 ∙ 시스템 구조 및 항목 평가 |
||
소프트웨어 요구사항 분석 |
∙ S/W 요건 기술 및 분석 ∙ S/W 인터페이스 분석 ∙ DATA 정의/DB 요건 분석 ∙ S/W 요구사항 평가 ∙ 합동 검토 수행 |
분석 | ∙ 분석 준비 ∙ 사용자 요구사항 분석 ∙ 사용사례 정의 ∙ 사용사례 관계 정의 ∙ S/W 아키텍처 분석 ∙ 정적구조 분석 ∙ 분석 클래스 정의 ∙ 동적행위 분석 ∙ 클래스간 상호작용 정의 ∙ 분석 컴포넌트 정의 |
소프트웨어 구조 설계 |
∙ 소프트웨어 컴포넌트 정의 ∙ 인터페이스 설계 ∙ DB 설계 ∙ 사용자문서 개발 ∙ S/W 통합계획 및 요건 정의 ∙ S/W 구조 설계 평가 |
∙ 설계준비 ∙ 소프트웨어 아키텍처 설계 |
|
소프트웨어 상세 설계 |
∙ S/W 컴포넌트 상세 설계 ∙ 인터페이스 상세 설계 ∙ 데이터베이스 상세 설계 ∙ 사용자 문서 갱신 ∙ 단위 테스트 요건 및 일정 ∙ 통합계획 및 요건 재정의 ∙ S/W 상세설계 및 테스트 요구사항 평가 ∙ 합동검토 수행 |
설계 | ∙ 사용자 인터페이스 설계 ∙ 데이터베이스 설계 ∙ 제어 설계 ∙ 시스템 인터페이스 설계 ∙ 설계 컴포넌트 정의 ∙ 프로세스 설계 |
ISO/IEC 12207 | 객체지향 개발 방법론 | ||
활 동 | 작 업 | 활 동 | 작 업 |
소프트웨어 코딩 및 테스트 |
∙ 단위 S/W 및 DB 개발 ∙ 단위 S/W 및 DB 테스트 ∙ 사용자 문서 갱신 ∙ 코드 및 테스트 결과 평가 |
구현 | ∙ 구현 준비 ∙ S/W 아키텍처 구현 ∙ 클래스 구현 ∙ 프로세스 구현 ∙ 컴포넌트 구현 |
소프트웨어 통합 |
∙ 통합계획 수립 ∙ 단위 S/W 및 컴포넌트 통합 ∙ 문서 갱신 ∙ 테스트 케이스 및 절차 수립 ∙ 소프트웨어 통합 평가 |
||
소프트웨어 적합성 테스트 |
∙ 적합성 테스트 ∙ 사용자 문서 ∙ 설계, 코드, 테스트, 테스트 결과, 사용자 문서 평가 ∙ 검사 ∙ 베이스 라인 설정 |
테스트 | ∙ 테스트 준비 ∙ 단위 테스트 ∙ 통합 테스트 |
시스템 통합 |
∙ S/W 형상관리 항목 통합 ∙ 테스트 케이스 및 절차 수립 ∙ 시스템 통합 평가 |
∙ 시스템 테스트 | |
시스템 적합성 테스트 |
∙ 시스템 적합성 테스트 수행 ∙ 시스템 평가 ∙ 검사 ∙ 베이스 라인 설정 |