[좐]군의 To-Be

(1) 소프트웨어를 반복적으로 개발한다.
(2) 사용자의 요구사항을 관리한다.
(3) 컴포넌트 기반의 아키텍처를 사용한다.
(4) 소프트웨어를 시각적으로 모델링한다.
(5) 소프트웨어 품질을 검증한다.
(6) 소프트웨어의 변경을 통제한다.

2.1. 유즈케이스 기반
- 유스 케이스 모델은 전형적인 시스템의 기능 명세서(functional specification)를 대체한다. 기능 명세서는 “시스템이 무엇을 수행하여야 하는가?”에 대한 응답을 할 수 있다.
- 유스 케이스는 요구사항을 지정하기 위한 도구만은 아니다.
- 유스 케이스는 시스템의 설계, 구현 및 테스트를 유도한다.
- 즉, 유스 케이스는 개발 프로세스를 유도한다.
- 개발자는 유스 케이스 모델에 근거하여 유스 케이스를 실현하는 일련의 설계 모델과 구현 모델을 작성한다.
- 개발자는 유스 케이스 모델에 대한 적합성을 위하여 각각의 모델을 검토한다.
- 테스터는 구현 모델의 컴포넌트가 유스 케이스를 정확히 구현했는지를 보장하기 위하여 구현을 테스트한다.

2.2. 아키텍쳐 중심
-소프트웨어 아키텍처의 역할은 건축물을 구축하는 과정에서의 아키텍처의 역할과 유사하다.
-소프트웨어 시스템의 아키텍처는 구축하고자 하는 시스템에 대한 다양한 뷰로 표현된다.
-소프트웨어 아키텍처 개념은 시스템의 가장 중요한 정적인 측면과 동적인 측면을 구체화한다.
-아키텍처는 구체적인 사항을 제거함으로써 보다 가시화되는 중요한 특성을 갖는 전체 설계에 대한 뷰이다.
-프로세스는 아키텍처 개발자가 올바른 목표에 집중할 수 있도록 도와준다.
-아키텍처와 유스 케이스는 어떠한 관계를 갖는가?
-모든 제품은 기능과 형태를 갖는다. 어느 것도 하나만으로는 충분하지 못하다.
-따라서 기능과 형태는 성공적인 제품을 얻기 위하여 균형을 이루어야 한다.
-이때 기능은 유스 케이스에 대응되며, 형태는 아키텍처에 대응된다.
-즉, 아키텍처와 유스 케이스는 병행하여 발전하여야 한다.
-아키텍처 개발자는 개발 대상 시스템의 핵심적인 기능을 표현하는 유스 케이스의 부분 집합을 가지고 작업을 수행한다.
-선택된 각각의 유스 케이스는 서브시스템, 클래스, 컴포넌트로 구체화되고 실현된다.
-유스 케이스가 완성됨에 따라 보다 많은 아키텍처가 식별된다.

2.3. 반복과 점진
-대부분의 상용 소프트웨어를 개발하기 위해서는 수개월에서 많게는 수년 혹은 그 이상이 소요된다.
-이러한 경우 개발 작업을 보다 작은 단위 혹은 미니 프로젝트로 나누어 수행하는 것이 실용적이다.
-각각의 미니 프로젝트는 증가분(increment)을 만들어 내는 반복(iteration)이다.
-반복은 작업 분야(discipline)의 단계를 의미하며, 증가분은 제품의 성장을 의미한다.
-이러한 이유로 반복을 미니 프로젝트라고 한다.
-개발자는 다음과 같은 두 가지의 요소에 근거하여 각각의 반복에서 구현할 대상을 선택한다.
-반복은 지금까지 개발된 산출물의 유용성을 함께 확장시키는 유스 케이스의 그룹을 다룬다.
-반복은 가장 중요한 위험을 다룬다

3. 프로세스
3.1. 프로세스 구조

-Unified Process는 시스템의 생명을 구성하는 일련의 주기(cycle)에서 반복된다.
-각각의 주기는 사용자에게 전달되는 산출물 릴리즈로 종료된다.
-각각의 주기는 [그림 14.2]와 같이 시작(inception) 단계, 상세(elaboration) 단계, 구축(construction) 단계 및 전환(transition) 단계의 네 가지 단계(phase)로 구성된다.
-각각의 단계는 반복(iteration)으로 추가적으로 나누어진다.
-Unified Process는 이차원적인 구조를 갖는다.
-수평축은 시간을 표현하며 프로세스의 생명주기 측면을 보여준다.
-수직축은 활동의 특성에 따라 활동을 논리적으로 그룹핑하는 핵심적인 프로세스 분야(process discipline)를 표현한다.
-첫 번째 차원은 프로세스의 동적인 측면을 표현하는 것으로 주기, 단계, 반복 및 이정표(milestone) 등의 항목으로 표현된다.
-두 번째 차원은 프로세스의 정적인 측면을 표현하는 것으로 프로세스 컴포넌트, 활동, 작업 분야, 산출물 및 작업자의 항목으로 표현된다.

3.2. 반복적인 프로세스 4단계

(1) 시작(inception) 단계 : 최종 산출물에 대한 비전과 비즈니스 케이스를 지정하고, 프로젝트의 범위를 정의한다. 시작 단계는 생명주기 목표(life cycle objective) 이정표에 의해 종료된다.

(2) 상세(elaboration) 단계 : 필요한 활동과 자원을 계획하고, 소프트웨어의 특징을 지정하며, 아키텍처를 설계한다. 상세 단계는 생명주기 아키텍처(life cycle architecture) 이정표에 의해 종료된다.

(3) 구축(construction) 단계 : 산출물을 개발하고, 산출물을 사용자에게 납품할 수 있을 때까지 산출물의 비전, 아키텍처 및 계획을 발전시킨다.

구축 단계는 초기 운용 능력(initial operational capability) 이정표에 의해 종료된다.

(4) 전환(transition) 단계 : 산출물을 사용자에게 전달하고, 사용자가 만족할 때까지 교육, 훈련, 기술 지원 및 유지보수를 제공한다.

3.3. 반복적인 UP 프로세스의 이정표

소프트웨어의 수명이 한 세대에서 종료되지 않는다면, 기존의 산출물은 시작, 상세, 구축 및 전환의 동일한 순서를 반복하면서 다음 세대로 진화하게 된다.

이러한 주기를 진화 주기(evolution cycle)라고 한다.

4. 개발 주기별 주요 활동

(1) 시작 단계 : 전체적인 요구사항을 이해하고 개발 노력의 범위를 결정하는데 중점을 둔다.

(2) 상세 단계 : 기본적으로는 요구사항에 중점을 두지만 아키텍처에 대한 프로토타입 개발, 기술적인 위험 요소의 완화, 도구 및 기법의 사용 방법에 대한 학습 등을 위하여 약간의 소프트웨어 설계와 구현이 추가된다.

상세 단계에서 사용자는 다음 단계를 위한 기준선(baseline)으로 역할을 하게 될 실행 가능한 아키텍처 프로토타입을 개발한다.

(3) 구축 단계 : 설계와 구현에 중점을 둔다.

구축 단계에서 사용자는 초기의 프로토타입을 첫 번째 운용 가능한 산출물로 발전시킨다.

(4) 전환 단계 : 시스템이 사용자의 목적을 충족시키는 품질 수준에 도달했음을 보장한다. 전환 단계에서 소프트웨어의 결점을 제거하고, 사용자를 교육하며, 누락된 요소들을 추가한다. 최종적인 산출물을 개발하여 납품한다.

4.1. 시작단계

4.1.1. 목적

(1) 운용 개념, 인수 기준, 산출물에 대한 설명 등을 포함하는 프로젝트의 소프트웨어 범위 및 경계 조건의 설정

(2) 시스템의 주요 유스 케이스 식별. 즉, 시스템의 기능을 유도하는 행위에 대한 기본적인 시나리오와 주요 설계 트레이드-오프(trade-off)의 구성

(3) 기본적인 시나리오에 대한 최소한 하나의 후보 아키텍처의 제시 및 증명

(4) 전체 프로젝트에 대한 비용 및 스케줄 산정과 상세 단계에 대한 세부적인 추정 제공

(5) 잠재적인 위험의 추정

4.1.2. 활동

(1) 프로젝트의 범위 결정. 즉, 가장 중요한 요구사항과 제약조건을 파악하여 최종 산출물에 대한 인수 기준을 유도한다.

(2) 비즈니스 케이스의 계획과 준비. 그리고 위험 관리, 인력 투입, 프로젝트 계획, 비용 및 스케줄간의 트레이드-오프 등을 위한 대안 평가

(3) 후보 아키텍처의 종합, 설계의 트레이드-오프 평가, 개발/구매/재사용 결정의 평가 및 비용, 스케줄, 자원에 대한 추정

4.1.3. 산출물

(1) 비전 문서(vision document). 즉, 코어 프로젝트의 요구사항, 주요 특징 및 주요 제약조건에 대한 일반적인 비전

(2) 초기 단계에 식별할 수 있는 모든 유스 케이스 및 액터를 나열하는 유스 케이스 모델 서베이(use-case model survey)

(3) 초기 프로젝트 용어집(project glossary)

(4) 다음을 포함하는 초기 비즈니스 케이스

 - 비즈니스 컨텍스트

 - 성공 기준

 - 재무 예측

(5) 초기 위험 평가

(6) 단계와 반복을 보여주는 프로젝트 계획

(7) 추가적 산출물

∙ 초기 유스 케이스 모델(10%～20% 완료)

∙ 프로젝트 용어집보다 복잡한 도메인 모델

∙ 필요한 경우, 비즈니스 모델

∙ 사용하는 프로세스를 설명하기 위한 예비 개발 케이스(development case) 설명

∙ 하나 혹은 그 이상의 프로토타입

4.1.4. 평가기준

(1) 범위 정의 및 비용, 스케줄 추정에 대한 이해 당사자의 합의

(2) 기본 유스 케이스의 충실도에 근거한 요구사항에 대한 이해

(3) 비용 및 스케줄 추정, 우선순위, 위험 및 개발 프로세스의 신뢰성

(4) 개발된 아키텍처 프로토타입의 깊이와 폭

(5) 실제의 지출 대 계획된 지출

4.2. 상세단계

4.2.1. 목표

(1) 가능한 한 빠른 아키텍처의 정의, 검증 및 기준선 지정(baselining)

(2) 비전의 기준선 지정

(3) 구축 단계를 위한 신뢰할 수 있는 계획의 기준선 지정

(4) 아키텍처 기준선이 합리적인 비용과 시간 이내에 이러한 비전을 지원한다는 증명

4.2.2. 활동

(1) 비전을 구체화하며, 아키텍처 결정과 계획 수립 결정에 영향을 미치는 가장 중요한 유스 케이스를 확실히 이해한다.

(2) 프로세스, 기반구조 및 개발 환경을 구체화하고 프로세스, 도구 및 자동화 지원을 준비한다.

(3) 아키텍처를 구체화하고 컴포넌트를 선택한다.

잠재적인 컴포넌트를 평가하고, 구축 단계의 비용과 스케줄을 결정하기 위하여 개발/구매/재사용 결정을 충분히 고려한다.

선택한 아키텍처 컴포넌트를 통합하고 기본적인 시나리오에 대해 평가한다.

이러한 활동의 결과를 이용하여 요구사항을 다시 고려하거나 대안 설계를 고려하면서 아키텍처를 재설계할 수 있다.

4.2.3. 산출물

(1) 유스 케이스 모델 서베이에 모든 유스 케이스가 식별되고, 모든 액터가 식별되며, 대부분의 유스 케이스 설명이 개발된 유스 케이스 모델(최소한 80% 완료)

(2) 특정한 유스 케이스에 관련되지 않은 비기능적 요구사항과 기타의 요구사항을 확보하는 추가적인 요구사항

(3) 소프트웨어 아키텍처 설명

(4) 실행 가능한 아키텍처 프로토타입

(5) 수정된 위험 목록과 비즈니스 케이스

(6) 반복과 각각의 반복에 대한 평가 기준을 제시하는 전체 프로젝트에 대한 개발 계획

(7) 사용하려는 프로세스를 지정하는 수정된 개발 케이스

(8) 예비 사용 매뉴얼(선택적)

4.2.4. 평가기준

(1) 산출물 비전의 안정성

(2) 아키텍처의 안정성

(3) 주요 위험 요소의 파악 및 해결

(4) 구축 단계 계획의 상세함과 정확성

(5) 현재 아키텍처 환경에서 현재 비전의 달성 가능성에 대한 이해 당사자의 합의

(6) 실제의 지출 대 계획된 지출

만약 프로젝트가 생명주기 아키텍처 이정표를 통과하는데 실패하면, 프로젝트가 취소되거나 심층적인 재검토가 요구될 수 있다.

4.3. 구축단계

4.3.1. 목표

(1) 자원의 최적화 및 불필요한 작업의 제거를 통한 개발 비용의 최소화

(2) 적절한 품질 달성

(3)∙ 유용한 버전 확보(알파, 베타 및 기타의 테스트 릴리즈)

4.3.2. 활동

(1) 자원 관리, 자원 통제 및 프로세스 최적화

(2) 완전한 컴포넌트 개발 및 평가 기준에 대한 테스팅

(3) 비전을 위한 수락 기준에 대한 산출물 릴리즈의 평가

4.3.3. 산출물

(1) 적절한 플랫폼에 통합된 소프트웨어 산출물

(2) 사용자 매뉴얼

(3) 현재 릴리즈에 대한 설명

4.3.4. 평가기준

(1) 사용자에게 배치할 수 있는 정도의 산출물 릴리즈의 안정성과 성숙도

(2) 모든 이해 당사자가 사용자로 전환하기 위한 준비

(3) 실제의 지출 대 계획된 지출

4.4. 전환단계

전환 단계의 목적은 소프트웨어 산출물을 사용자에게 제공하는 것이다

(1) 사용자 기대를 충족시키는 새로운 시스템을 검증하기 위한 베타 테스팅

(2) 대체 대상인 레거시 시스템과의 병행 운영

(3) 운영 데이터베이스의 변환

(4) 사용자 및 유지보수 담당자에 대한 교육 훈련

(5) 마켓팅, 배포 등을 위한 산출물의 공개

전환 단계는 소프트웨어를 최종 사용자에게 제공하기 위한 활동에 중점을 둔다.

전환 단계는 베타 릴리즈(beta release), 일반 가용 릴리즈(general availability release), 결함 제거 및 개선 릴리즈(bug-fix and enhancement release) 등을 포함하는 다수의 반복으로 이루어진다.

4.4.1. 목표

(1) 사용자 지원 보장

(2) 배치 기준선의 완전성 및 평가 기준에 대한 적합성 여부의 이해 당사자 합의

(3) 최종 산출물 기준선의 확보

4.4.2. 활동

(1) 소프트웨어 배치에 관련된 엔지니어링 활동

(2) 성능과 유용성을 위한 결함 제거 및 개선 등의 튜닝 활동

(3) 산출물에 대한 인수 기준 및 비전에 대한 배치 기준선의 평가

전환 단계에서 반복 동안에 수행되는 활동은 목적에 따라 달라진다.

예를 들어, 결함 제거를 위한 경우에는 구현과 테스팅 만으로도 충분하다.

그러나 새로운 기능을 추가하는 경우에는 구축 단계의 활동과 유사한 반복이 이루어진다.

4.4.4. 평가기준

(1) 사용자의 만족도

(2) 실제의 지출 대 계획된 지출

UP의 주요 산출물 요약

분야	산출물	단계
		시작 I1	상세 E1...En	구축 C1...Cn	전환 T1...Tn
비즈니스 모델링	도메인 모델		시작
요구사항	유스 케이스 모델	시작	구체화
	비전	시작	구체화
	보충 명세서	시작	구체화
	용어집	시작	구체화
설계	설계 모델		시작	구체화
	소프트웨어 아키텍처 문서		시작
	데이터 모델		시작	구체화
구현	구현 모델		시작	구체화	구체화
프로젝트 관리	소프트웨어 개발 계획	시작	구체화	구체화	구체화
테스팅	테스트 모델		시작	구체화
환경	개발 케이스	시작	구체화

참조 : 객체지향 분석과 설계 (저.윤정모)

(0) (0)

Posted by 좐군

높은 수준에서 전체 시스템을 설계하기 위한 일반적인 절차
(1) 설계 우선순위를 고려
     시스템을 설계하는 과정에서 고려하여야 하는 다음과 같은 추가적인 요인들이 존재

    1. 기능적 요구사항 :
         각각의 유스 케이스는 시스템이 제공하여야 하는 기능을 나타낸다.  
         따라서 주어진 예산과 일정 안에서 구현을 할 유스 케이스와
         그렇지 않을 유스 케이스를 선택하여야 한다.
     2. 융통성
         모듈화 개념을 도입하여 시스템을 설계하면
         사용자의 요구사항이 변경되었을 때 설계 변경이 용이
     3. 속성(“~ilities”)
          우수한 설계는 규모성(scalability), 신뢰성(reliability) 및 가용성(availability) 등과
          같은 다양한 속성을 고려하여야 한다.
     4. 성능
          설계 내역은 시스템 속도에 영향을 미친다.
         시스템이 충분히 빠르지 못한 경우   사용자는 시간을 낭비하게 된다.
         시스템이 너무 빠른 경우라면 시스템개발에 필요 이상의 비용을 지불했을 수 있음.
     5. 비용
         거의 대부분의 경우 시스템은 예산이 정해져 있다.
         설계는 시스템 예산의 범위 내에서 이루어져야 한다.
     6. 일정
         비용과 마찬가지로 일정도 설계의 주요 요인
         대개의 경우, 업체의 경쟁이나 계약 조건에 의하여
         시스템이 특정한 날짜까지 설계 및 개발이 완료되도록 요구되고 있다.

(2) 현재의 시스템을 검토
     새로운 시스템이 기존의 시스템을 대체하는 것이거나
     혹은 기존 시스템에 대한 기능의 추가라면,
     기존 시스템이 어떻게 설계되어 있는지를 살펴보아야 한다.

(3) 시스템을 분해
     시스템을 보다 작은 규모의 서브시스템으로 분해
     각각의 보다 작은 문제를 해결할 수 있다면,
     이들 해결책의 종합이 보다 큰 문제도 해결할 수 있다.

(4) 아키텍처를 정의
     서브시스템을 정의하였으면 이들 서브시스템이
     상호간에 어떻게 연관되어 있는지를 설명하여야 한다.

(5) 객체 지속성(object persistence)을 선택
     일부의 객체는 지속성을 가져야 한다.
     즉, 시스템의 전원이 꺼지는 경우에도 이들 객체는 지속적으로 보존되어야 하는데,
     이들 객체를 어떻게 보존할 것인지도 결정하여야 한다.

(6) 서브시스템 인터페이스를 정의
     서브시스템을 클래스처럼 다룰 수 있다.
     각각의 서브시스템은 중요한 오퍼레이션에 대한 책임을 갖는다.

(7) 컴포넌트를 선택
     시스템이 최대의 융통성을 갖도록 설계한다는 것은 컴포넌트에 의한 설계를 의미
     컴포넌트는 시스템에서 블랙 박스처럼 작동하는 모듈 개념의 대체 가능한 단위

(8) 시스템 전략을 결정
     시스템의 시작과 종료 방법을 고려
     또한 에러 처리 방법과 시스템 실패를 대비하는 설계 전략도 고려
     시스템 보안, 데이터 무결성, 사용자 프라이버시도 중요한 고려 대상

(9) 단계 ②에서 단계 ⑧을 반복한다.
      단계 ①에서 단계 ⑧까지의 설계 사항을 검토한 후에는,
      각각의 단계를 다시 수행하면 단계 ①에서 선택한 설계  
      우선순위에 근거하여 임시적인 설계 결정을 내린다.
      패키지 다이어그램이나 배치 다이어그램(deployment diagram)을 사용하여
      설계 의사결정을 기록

(10) 반복을 다시 수행한다.
        단계 ②에서 단계 ⑧까지를 다시 반복한다.
        이러한 반복을 두번 내지 세번 정도를 수행했을 때
        우수한 설계 결과를 얻을 수 있다.
¹

(0) (0)

Posted by 좐군

1. 개요

최근에 컴퓨터의 이용이 증가함에 따라 소프트웨어에 대한 수요의 증가로 소프트웨어의 개발, 유지보수 비용은 급속한 속도로 증가하고 있다. 품질 좋은 소프트웨어를 개발하기 위한 소프트웨어 방법론이 많은 연구되고 있다. 현재 많이 이용되는 구조적 개발 방법론은 소프트웨어 재사용이나 모듈화, 개발된 소프트웨어를 유지보수하는 데는 효과적이지 못하다는 결점을 가지고 있다. 그러므로 적은 규모의 소프트웨어를 개발하는 데는 적합하지만 대규모 소프트웨어를 개발하는 데는 적합하지 못하다.

조직개발 방법론의 대안으로 객체 지향 개발 방법론이 대두되었다. 종래의 구조적 개발 방법론은 소프트웨어의 동적인 기능 측면에 초점을 맞추고 있는데 비해, 객체 지향 개발 방법론은 소프트웨어의 정적인 데이터 측면과 동적인 기능 측면을 모두 중시한 시스템을 개발할 때 요구되는 여러가지 강력한 모델링 개념과 캡슐화 개념 등을 잘 지원하고 있다. 이러한 객체 지향 방법론은 구조적 개발 방법론에 비해 소프트웨어 분석, 테스트, 유지보수, 확장 등을 쉽게 해주며, 분명하면서도 잘 이해할 수 있는 설계 결과를 만들어 낸다. 즉 클래스는 자연스럽게 소프트웨어 모듈의 한 단위가 되고 객체 지향 설계 과정은 그러한 객체 지향 사이의 복잡도를 적절히 관리해 준다.

본 고는 객체 지향 분석 및 설계(object- orient analysis and design: OOAD) 방법론을 비교 분석하는데 있다.

OOAD의 평가요소를 동일하게 하여 다양한 OOAD기술과 표현 방법들을 비교하고 분석하며, 또한 OOAD 방법론의 장단점을 비교 분석하여 현재까지 연구된 OOAD 방법론을 평가, 비교하기 위한 프레임워크를 구성하고, 구성된 프레임워크는 완전한 OOAD 방법론 개발을 위한 많은 연구들이 융합될 수 있는 토대를 마련하도록 한다.

본 고의 구성은 2장에서는 객체 모델링에 대해서 알아보고, 3장에서는 객체 지향 분석 및 설계에 대해서 비교 분석하고, 4장에서는 결론을 맺는다.

2. 객체 지향 모델링

가. 객체 모델링 방법론

소프트웨어 개발의 큰 문제점은 복잡성, 요구의 변화, 개발 기간의 시간적인 제약성이다. 이러한 문제 해결에 제안된 기본적인 개념으로 분해 기법과 추상화 기법을 들 수 있다.

분해 기법은 복잡한 문제를 작고 단순한 서브 프로그램들로 나눈다. 나누어진 문제는 전체 문제보다 해결하기 쉽고, 서브 프로그램들을 다시 결합하면 원래 의도한 문제를 해결할 수 있다[8].

추상화 기법은 다양하고 복잡한 개념을 단순 개념으로 사상하는 과정으로 서로 다른 많은 사항들을 무시한 채 같은 것으로 취급함으로써 복잡한 방법을 줄이는 것이다. 객체 지향 방법론는 두가지 개념을 바탕으로 소프트웨어를 개발한다[8].

객체 지향 방법론은 해 영역의 실제에 의미를 부여하고 실제를 객체로 추상화시키는 의미 객체 모델링(정적 모델) 방법과 처음부터 동적 모델을 고려한 객체 추출을 기반으로 하는 객체 모델링 방법으로 나눈다.

(1) 의미 정의에 대한 객체 모델링

정보처리 시스템은 문제 영역 P에 대한 해 영역 S를 양식으로 나타낸 것으로 P⊂S인 관계로 나타낸다. 실세계에서 문제의 의미를 분석하여 기술하고, 양식에 의한 설계를 하여 해를 기술한다. 또한 P는 의미 객체를 포함한 집합으로써 P의 객체들은 해 보다는 문제를 기술하는 개념으로 사용한다.

시스템의 의미 객체는 고객, 주문, 항목, 피고용자들로서 주어진 시스템의 실체들이 된다. S는 문제 영역 P 이외에도 인터페이스, 응용, 기본 객체들을 포함한다.

인터페이스 객체는 사용자와 정보처리 시스템 간의 인터페이스를 설명하고 문제 영역 자체를 설명하지 않는다. 즉 의미 객체에 대한 사용자의 관점에서 기술한다.

응용 객체는 정보처리 시스템에 관한 제어 메카니즘이다. 유도기능을 가지고 개발된 시스템의 기능들을 순차적으로 제어한다. 즉 시스템의 주된 모듈로서 다른 객체들에 대한 메시지와 메뉴를 전달한다[8].

기본 객체는 문제 영역이나 응용되는 독립된 객체이다.

의미 객체 모델을 바탕으로 객체 지향 분석을 하는 과정은 의미 자료 모델을 갖추어야 할 자료의 추상화, 의미 객체의 식별, 집합관계, Classification과 Instantiation, 속성의 승계, 그리고 서브 클래스와 슈퍼 클래스를 정의하여 수행한다[8].

분석 단계는 문제점을 기술함으로 의미 객체별 요구와 양식 중심으로 기술하고 설계 단계는 그 해를 기술한다. 객체 지향 분석은 문제 영역을 모델링하기 위하여 의미 객체의 집합을 식별하여 그 양식을 정하고 시스템 요구에 의해서 관련성을 기술한다. 객체 지향 설계는 해 영역을 모델링하는데 의미 클래스, 응용 및 기본 클래스를 설계한다.

결과적으로 실체를 식별하여 의미 객체로 추상화하고 객체들의 속성과 관련성, 집합관계를 기술하여 의미 자료 모델링을 하고, 여기에 객체 지향 프로그랭 언어가 가진 특성, 즉 속성의 외부 서비스, 객체 간의 인터페이스 메시지, Classification 및 행위의 승계, 그리고 정보 은닉과 캡슐화를 추가하여 객체 지향 분석 및 설계를 수행한다.

(2) 객체 모델링

객체 모델링은 문제 분석과정부터 객체를 추상화시켜서 클래스로 정의하고, 관련성을 분석하여 상속성을 정의하는 분석 과정이다[8].

① 객체

객체는 사람, 장소, 물건 등과 같이 물리적이거나 온도, 액수, 구좌 등과 같이 개념적일 수 있다. 또한 실체 시스템의 구성요소와 일대일 대응관계를 갖는다. 그러나 객체는 개개의 요소를 의미하는 것이지 항목들의 일반적인 범주나 그룹을 의미하는 것은 아니다. 객체는 하나의 고유 식별자를 갖는 것을 의미한다.

행위는 객체가 제공하게 될 서비스와 수행하게 될 책임을 의미하는 것으로 외부에서 객체를 사용하는 방법과 시스템에서 주어진 일을 수행하는 방법이 된다. 임의의 조건 하에서 어떠한 사건이 발생할 때 취하는 객체의 행동 파악이 필요하다. 행위는 또 다른 사건을 유발할 수도 있고 객체를 생성 또는 파괴하기도 하며 메시지의 교환일 수도 있다. 또한 객체는 상태를 갖고 이상태는 시간에 따라 변화를 일으킨다. 상태란 객체의 현재 상황이나 전체 흐름에서의 단계를 의미한다. 객체에 대한 상태를 정의하는 방법으로는 여러가지가 있을 수 있으나 가장 가능한 방법으로는 현재 가동중인 시스템인 경우 시스템 운영의 흐름 내에서 객체 관찰을 통해서 그리고 수행되고 있는 시스템이 없는 경우 전체의 흐름을 가정하여 파악하는 것이다[7].

② 객체 클래스

서로 비슷한 객체들끼리 하나의 추상화된 것으로 만들 필요가 있다. 또한 분류작업으로 간주할 수 있다. 각 객체 클래스는 이름을 갖게 되면 이들이 포함하게 될 객체의 일반적인 성질을 갖게 된다.

③ 관련성

객체는 서로 다른 객체와 어떠한 형태로든 관련성을 갖고 있다. 즉 객체들 간의 논리적 관계를 가지고 있다.

일반화(Is-A 관련성 집합) 관계는 한 객체가 다른 객체의 상위 집합인지 하위 집합인지를 정의한다. 이때 상위 집합을 일반화라고 하고 하위 집합을 상세화라고 한다. 이는 집합의 개념으로 판단하는 것으로 집합에 속하는 원소들을 고려하여 하위 집합에 속하는 객체가 상위 집합에 속할 수 있어야 한다.

상속 관계에서 하위 집합의 원소는 상위 집합의 원소라고 정의한다. 이는 일반화가 지닌 모든 관련성 집합에 새로 정의된 상세화가 포함됨을 의미한다. 상세화는 일반화가 지닌 모든 관련성을 상속 받는다. 어떤 경우는 하나의 객체 클래스가 두가지 이상의 일반화의 상세화일 수 있다. 이때 하위집합은 여러 개의 상위집합이 지닌 모든 관련성을 상속 받는다. 이를 다중 상속이라고 정의한다.

집성화 관계는 한 객체가 또 다른 객체를 자신의 서브 파트나 부품으로 구성한 경우 이들 상호간에 집성화 관계가 존재한다고 한다. 이 집성화 관계에는 참가 제한 사항이 추가된다

Is-Member 관계에서는 하나의 객체로 취급하려는 객체와 그들 원소들간의 관계를 말한다. 즉 이진 관계이다.

나. 객체 모델링의 단계

객체 지향 분석은 시스템의 시나리오에 나타난 객체를 식별하고 그들 간의 상호 작용을 파악한 다음, 각 객체에 부과된 책임(행위)을 분석한다. 객체의 행위 분석은 인터뷰하기 전부터 시작할 수 있으므로 시스템의 시나리오를 문서로 작성한 이유도 객체 추출을 쉽게 하기 위한 것이다. 여기에서 중점을 두어야 할 내용은 시스템을 개발하게 된 동기가 무엇이며, 동기별로 어떤 사건이 일어날 것인가 하는 점이다. 즉 기술 문서와 함께 객체와 그들의 속성 및 행위를 식별하는 것이 객체 지향 분석의 중요한 과제이다

(1) 분석 단계

분석 단계는 기본 단계로서 분석을 위한 계획서 작성, 행위에 초점을 맞춘 행위 분석, 객체를 추출하고 그 행위의 기술, 객체들 간의 관련성 파악, 동적 모델링으로 구분할 수 있다

기본 단계는 분석의 계획 단계이다. 시스템의 시나리오를 바탕으로 살펴보면 개념적 모델링, 외부 양식, 구현의 과정을 정하고 시스템의 시나리오에 나타난 목표를 설정하고, 시스템의 범위와 문제 공간의 기술, 분석을 위한 자료의 선정, 그리고 분석 단계의 계획을 세운다. 시스템의 범위와 문제 공간의 기술은 시스템의 환경과 조건을 파악하고 문제 분석의 공간 영역이 어디까지인가를 결정한다. 분석을 위한 자원 식별은 사용자의 파악과 영역을 설명할 수 있는 전문적인 지식 그리고 적당한 참고문서 등을 찾아낸다. 이상과 같이 분석과정의 상위 단계에서 나타난 행위를 설명하고 다음에 연결되는 1 단계부터 4 단계까지의 분석을 위한 계획을 세우고, 모델의 개념을 정립한다[8]. 기본 단계에서 기술되는 문서는 분석계획, 현 시스템의 목표, 요구 정의, 품질 목표, 면담내용의 기술로서 시스템의 시나리오와 비교하여 모순점이 없는가를 평가할 수 있는 문서와 객체 모델링의 전과정에 관한 계획문서이다. 요구정의와 품질목표, 면담 등은 인터뷰와 참조문서를 바탕으로 해서 이루어 지는데 객체들의 활동을 설명하는 시나리오, 에러조건과 처리방법, 모델에 포함된 서비스, 서비스의 수행 책임자인 행위자의 식별의 내용을 포함해야 한다. 시스템의 목표와 계획이 세워지면 개념적인 모델링 단계에 들어가는데 이 과정으로 문제분석, 객체의 추출, 그리고 객체의 관련성 정의에 들어간다[8].

문제 분석 단계에서는 시스템의 기능을 정하고 그 기능을 누가 수행하며, 누구의 도움을 받아서 집행할 것인가를 결정한다. 시스템 기술에서 나타난 동기와 사건을 중심으로 야기되는 문제를 파악하고 그 해답 영역을 찾는다. 그리고 나서 해당 영역별로 어떤 활동이 일어날 것인가를 예측하고, 활동할 객체를 선정한다. 선정된 객체는 어떤 역할을 담당할 수 있는가를 분석하여 그 객체의 행위와 속성을 정의한다. 끝으로 행위자의 활동을 중심으로 하여 객체들의 행위를 결정하여 기술 문서를 작성한다. 기술 문서의 내용은 객체와 속성, 그리고 요구자의 행위와 행위자의 서비스를 기술한다. 활동 기술서는 요구자와 행위자의 객체가 수행하는 활동을 의미한다. 객체가 식별되면 요구자의 행위는 행동이라고 하고, 행위자의 행위는 서비스라고 정한다.

(2) 활동 기술 단계

객체 추출과 활동의 기술 단계는 문제 분석에서 추출된 모든 객체의 역할을 정하고, 객체의 속성과 행위를 비교 분석하여 미비점과 모순점을 찾아낸다. 그 다음에 객체들을 구분하여 요구자인지, 행위자인지를 식별하고 각각의 행위를 기술한다. 끝으로 트레이스의 방법을 기술하면 객체의 기초적인 모델링은 끝난다. 객체의 속성은 논리적인 특성이기 때문에 객체활동에 관련된 성질을 정의하면 된다. 객체의 행위는 객체의 책임이 무엇인가를 파악하고, 그 객체가 제공할 서비스와 다른 객체에 요청할 서비스를 구분하여 정해 나간다. 모든 참여자가 객체로 나타나는데 참여자는 동기를 부여하고 서비스를 요청하는 요구자와 서비스를 수행할 행위자로 나눌 수 있다. 그러나 한 개의 객체가 요청과 수행의 두가지 기능을 같이 가질 수 있다. 이럴 때는 객체 기능은 두 가지로 구분해서 설명할 수 있는 활동을 정의해야 된다. 객체는 요구자와 행위자가 되는데 요구자의 활동은 능동적인 행동을 의미하고, 행위자의 활동은 수동적인 서비스를 의미한다. 본 단계의 활동 기술서에서는 활동 기술서를 구별하여 설명하는 과정이 중요하다.

(3) 관련성 기술 단계

객체의 관련성 기술 단계에서는 객체의 관련성을 추상화에 의한 일반화, 특성화에 의한 집합관계, 그리고 링크와 결합에 의한 연결관계를 찾아서 객체들을 그룹으로 나누는 단계이다.

추상화는 객체에 어떤 기능을 부여할 것인지를 기술함으로써 외부적 관점에서 설명하고자 하는 것으로 구현에 의해서도 그 기능이 변하지 않은 캡슐화를 시도할 수 있다. 또 공통된 특성과 행위를 특성화시켜서 다른 객체에 승계시켜 줄 수 있도록 일반화시키고 추상화된 객체를 새로운 객체(새로운 특성과 행위를 추가시켜서)로 재정의하는 특성화를 통해 보다 차원 높은 추상화를 유도해 낼 수 있다. 즉 추상화된 객체를 일반화와 특성화를 통해서 재차 추상화시킴으로써 승계를 위한 차원 높은 추상화 객체에 대해서 집합관계를 설계할 수 있다.

집성화 관계는 a-part-of 나 partwhole로 표현되는 객체의 그룹화를 위한 관계 정의를 하는 분석과정이다. 자원관리의 BM구조와 같이 제안된 방법으로 설계할 수 있는 DB 에서 쉬운 예를 찾아볼 수 있다. 링크와 결합을 사용자가 정의하는 내부 레코드의 관계와 DB에서 parent-child 관계와 같이 정의한다. 관계의 비중을 나타내는 차수와 대응수, 그리고 종속성이 정의된다. 객체 모델에서 일반화, 집합관계 및 링크와 결합관계는 매우 중요하다.

(4) 동적 모델링 단계

동적 모델링 단계에서는 앞 단계에서 설명한 문제분석, 객체 추출과 행위 기술, 그리고 객체들 간의 관련성을 중요하게 생각하는 분석이 정적 모델링이라고 한다면, 시스템 전체의 생명주기를 모델링하는 것을 동적 모델링이라고 할 수 있다. 동적 모델링에서는 객체의 상태가 변화되어 가는 과정을 중요시한다. 객체의 상태는 기술문서에 나타난 전후 조건들로부터 파악된다. 정적 모델링이 객체의 구조만 관심을 두고, 시간 조건을 배제한 환경에서 설계된다면, 동적 모델링은 시간에 따라서 변하고 시스템의 관점에서 객체를 관찰하게 된다. 따라서 두 가지 모델링의 관점은 서로간에 균형을 유지할 수 있도록 설계되어야 한다. 동적 관점의 설계 내용은 각 객체에 대한 상태를 정의하고 동적 행위를 가진 객체의 상태가 객체의 생명에 어떤 영향을 줄 수 있는가를 정의한다.

다. 여러가지 객체 모델링의 비교 분석

(1) Edwards

분석결과에서 C++로 코딩할 수 있고 정적 및 정적 차원에서 지원할 수 있으나 승계 정의를 고려하지 않았다. 정적 차원의 지원에서는 클래스, 인터페이스, 관계, 기능(관계)이 있고, 동적차원의 지원에서는 다중 객체로 일어난 이벤트를 중심으로 분석하고, 단순 이벤트는 STD에 의해 분석한다. 이벤트의 5개 영역은 객체 생성, 용어의 정의, 클래스 확장, 클래스 재구성, 객체의 재분류 등이 있다.

여기서 클래스의 확장과 재구성, 객체 분류는 객체를 클래스로 구분하는 과정이다.

(2) Page와 Jones의 이벤트 영역 분류

이벤트의 영역 분류를 통해서 객체를 모델링하는 과정은 다음과 같다.
① 객체 생성
② 용어 정의
③ 객체 정의와 분류에 의한 클래스 정의
④ 단계와 반복 순서
⑤ 재분류
⑥ 관계의 재정의
⑦ 서로 다른 객체의 표준화와 동향

(3) Shlaer와 Mellor의 OOA
객체의 상호 관련은 이벤트를 통해서 정의되고 이때 활동을 통해서 이벤트를 생성한다. 전이는 이벤트가 발생할 때 일어난다.
활동을 확장할 때 DFD를 채용하며, DFD는 외부 속성을 표현한다. STD에 의해서 객체의 라이프 싸이클을 결정한다.

(4) Rumbaugh의 OMT

Rumbaugh는 활동 상태와 활동을 구분하여 설명하고 있다. 활동은 전이 가능한 이벤트와 동시에 일어나고, 활동상태는 상태가 추가된 연산과정으로 생각한다. 객체의 상태는 객체가 가지고 있는 다른 객체들 간의 결합으로 모은 집합이다. 활동상태는 전이 가능한 이벤트에서 끝나고, 항상 활동으로 바꿀 수 있다. 그래서 자료 동적 및 정적 성질을 표현하는데 중점을 두고 있다.
객체 지향 분석은 다음과 같이 4가지 과정을 반복해서 이루어진다.
① 객체 모델링
② 동적 모델링
③ 기능 모델링
④ 모델 간의 관계정립
특히 Booch와 Gibson은 서브 시스템을 사용하여 객체를 정의함으로써 설계과정의 단계를 상세하게 추가하고 있다. 즉 확장 가능한 객체를 서브 시스템에 정의하고 그 자료구조를 설계하고 행위의 알고리즘을 설계하면서 새로운 객체를 식별하는 기회를 갖게 한다.

본 연구에서는 Rumbaugh, Booch와 Gibson의 방법을 참조하면서 객체 모델링 방법을 설명하였다.

3. 객체 지향 분석 설계에 대한 비교 분석

가. 객체 지향 분석 및 설계 프로세스

OOAD 프로세스에서는 객체를 의미, 인터페이스, 응용, 베이스/유틸리티 클래스들로 분류하여 나타낸다. 그리하여 OOAD프로세스에서는 클래스로 정제하는 활동을 한다. 이것은 공통된 행위에 대한 클래스의 추상화와 애트리뷰트에 대한 구조를 조사하는 것이다. 또한 설계자의 관점에서는 클래스가 완벽하고 올바르다는 것을 확인할 수 있으며 “메소드에 누락된 것이 있는가,” “메소드와 애트리뷰트가 올바른 위치에 있는가”에 대해서 클래스를 정제하는 작업이다. 많은 연구자들에 의해 OOAD 프로세스에 대한 연구가 이루어졌는데 그 중에서 Booch, Coad and Yourdom, Rumbaugh, Bulmn 등이 OOAD프로세스에 대한 많은 부분을 설명하였다. 특히, Bulman은 인터페이스, 응용, 베이스, 유틸리티 객체에 중점을 두고 설명하였다.

나. OOAD 방법

표현은 크게 정적인 관점과 동적인 관점 그리고 표기법에 관한 관점으로 구분할 수 있다. 객체 지향 정적모델은 객체 지향 동적 모델보다 많은 종류의 모델이 있으며, 동적 모델 중에서 구성요소 대부분이 객체 모델에서 행위로 매핑되거나 번역되는 상태 전이도로 구성된다. 표기법에 관한 관점은 관계의 표현을 포함하는 것으로써 대부분의 표현들은 일반화 관계로 지원된다. 집단화 관계도 지원되지만 아직까지 널리 이용되고 있지 않다.

다. OOAD 복잡도 관리

몇몇 연구자들이 방대한 OOAD 복잡도를 관리하기 위한 개념적인 메커니즘을 제공하고 있는데 이 메커니즘의 대부분은 구조적인 복잡도에 대하여 처리하고 있다. 예를 들어 Coad and Youndom’s의 서브젝트와 Wirfs-Brock et al의 서브 시스템이 있는데 서브젝트는 어떤 루트 구조나 서브스트락처에서 객체를 캡슐화하는 매카니즘이며 루트로부터 구조를 상속받아 구성되므로 복잡도가 감소한다. 반면에 서브 시스템은 루트구조에 기반을 두지 않고 상위 레벨 기능을 달성하기 위해 구성된 다른 서브 시스템이나 클래스로 이루어져 있다.

라. OOAD 장단점

현재의 OOAD에 접근하는 일반적인 세 가지 방법은 다음과 같다.

(1) 결합에 의한 접근

객체 지향, 기능 지향 그리고 동적 지향 기술을 단독으로 모델 구조, 기능성, 동적행위로 이용하고 다른 모델을 통합하기 위한 방법론을 제공한다. 그러나 이 결합에 의한 접근은 다른 관점을 객체 지향 설계방법으로 통합할 때 내용이 변경될 수 있다.

(2) 적용될 수 있는 접근

기존의 기술을 객체 지향에 이용하거나 객체 지향 기술을 포함하여 확정한다.

(3) 순수한 객체 지향 접근

객체구조, 기능성, 동적행위를 모델화하기 위해 새로운 기술을 이용한다.

OOAD를 지원하기 위한 정형화된 방법은 아직 표준화되어 있지 않으나 지금까지 기술한 OOAD에 대한 장담점은 <표 1>과 같다.

4. 결론

OOAD방법론에 많은 연구자들이 관심을 가지고 연구하고 있는 분야이다.

따라서 본 고는 OOAD 방법론에 관한 연구들을 비교 평가하기 위한 프레임워크를 구성하여 현재까지 개발된 객체 지향 설계 방법론 구성요소인 프로세스, 표현, 복잡도 관리를 이용하여 구성한 프레임워크를 통해 살펴보았다. 그러나 이와 같은 설계 방법론이 우수하다고는 말할 수 없다.

OOAD 방법론 중에서 프로세스, 표현, 복잡도 관리에 대한 모든 것을 지원하는 방법론이 제시되지 않았기 때문이다. 향후 연구는 지금까지 연구되어진 OOAD 방법론들을 기반으로 프로세스, 표현, 복잡도 관리가 모두 지원될 수 있는 OOAD 방법론을 개선하는데 있다.



<참 고 문 헌>
[1] 안중호, 고급 정보시스템 분석 및 설계, 서울, 1989.
[2] 송영제, 객체 지향 소프트웨어 설계법에 관한 연구, 대한전자공학회.
[3] 원유현, 객체 지향 언어의 주요 개념, 석사학위논문.
[4] 류형규 외 3인, UML기반 객체 지향 클라이언트/서버구축, 홍릉출판사.
[5] APPLYING UML AND PATTERNS(An Introduction to object- oreiented analysis and design and the unified procss).
[6] R.F.SINCOVEEC: Modular Software construction And Object-Oriented Design Using Ada Journal Of PASCAL/ Ada & Modula-2.
[7] R. Pricto-Diaz And P.Frecman: Classfying Software For Reusability IEEE Software.
[8] 정보과학회지, 제11권 2호(통권52호), ISSN 1015-9908.

(0) (0)

Posted by 좐군