人-ware : Forwards Veritas

구현 컴포넌트 분석 - 컴포넌트 내부 분석 컴포넌트의 내부 분석은 상당한 노력과 시간이 요하는 작업이다. 특히, 이 작업을 수행할 때에는 내부 로직을 하나씩 세부적으로 분석할 필요가 있으며, 그러한 분석 내용은 차후를 위해 정리하는 작업도 같이 병행되면 더 좋다. 컴포넌트의 내부는 관련된 객체가 서로 결속력이 강한 형태를 이루어야 하는데, 컴포넌트 리팩토링 단계에서는 내부 결속력이 강하지 못한 객체를 중심으로 식별하여 리팩토링 대상을 삼는다. 또한, 더 세부적으로 기능의 유사성을 식별하여 재사용 가능한 형태의 구조까지도 리팩토링을 수행할 수 있다. 유형 - 너무 많거나 적은 책임성(Responsibility)을 가지는 클래스가 발생하는 현상. - 타 클래스와 협업(Collaboration)이 적은 클래스..

구현 컴포넌트 분석 - 컴포넌트 크기 분석 컴포넌트는 적절한 크기로 만들어져야 하며, 그 크기는 상대적으로 관리할 수 있는 형태이어야 한다. 즉, 컴포넌트는 독립적인 비즈니스 개념 및 프로세스를 담고 있어야 한다. 컴포넌트 크기는 인터페이스 갯수, 인터페이스의 오퍼레이션 갯수, 컴포넌트가 호출하는 다른 컴포넌트의 인터페이스 갯수 등 다양한 기준으로 측정이 가능하며, 각각의 경우에 있어서 적절한 기준을 선정해야 한다. 유형 - 하나의 컴포넌트가 너무 많은 인터페이스를 가지고 있는 현상. - 하나의 인터페이스에 서로 성격이 다른 유형의 오퍼레이션을 가지고 있는 현상. - 하나의 오퍼레이션이 너무 많은 기능을 수행하는 현상. - 하나의 인터페이스가 너무 적은 수의 오퍼레이션을 가지고 있는 현상. 분석 내용 -..

구현 컴포넌트 분석 - 컴포넌트 Dependency 파악 컴포넌트 Dependency는 현재 구현된 컴포넌트의 의존관계에서 원칙에 위배되는 내용을 파악하는 단계이다. 이 단계에서는 이러한 의존관계의 위배 현상의 피상적인 결과 뿐만 아니라, 왜 그와 같은 의존관계가 형성될 수 밖에 없는지의 원인까지도 가능한 파악되어야 한다. 이러한 컴포넌트 의존관계 원칙은 컴포넌트 설계 전에 우선 결정이 되어야 하며, 설계를 진행하고 구현하는 과정에서 이러한 피드백을 받아서 다시 의존관계를 조정해야 한다. 유형 의존관계가 위배되는 유형은 아래와 같이 크게 세가지 형태로 나뉠 수 있다. - Dependency 의 역전 현상 (엔티티에서 프로세스로의 호출, 유틸리티에서 프로세스 혹은 엔티티로의 호출) [1] - Depende..

컴포넌트 리팩토링은 구현 컴포넌트 분석, 리팩토링 목적 및 범위 설정, 방안 마련, 리팩토링 수행, 테스팅으로 나뉠 수 있다. 각 단계에서는 컴포넌트가 가지는 여러가지 측면에서 단계별로 접근하게 된다. 전체적인 컴포넌트 리팩토링 절차는 아래 그림과 같다. 이러한 컴포넌트 리팩토링은 컴포넌트 클러스터링 원칙인 결합도가 적고, 결속력이 높은 상태의 컴포넌트로 바뀌게끔 그 목적을 두어야 한다.

컴포넌트 리팩토링은 소프트웨어 개발주기에서 컴포넌트 설계 단계에서 발생되며, 최초 컴포넌트를 설계 후, 구현 및 테스트 과정에서 발생되는 컴포넌트의 품질 문제 해결을 위해서 다시 개발주기를 반복하는 과정에서 수행된다. 리팩토링 시점은 반복 설계 시점의 초반에 수행되며, 컴포넌트의 인터페이스 및 의존성에 대한 수정이 발생될 수 있는데, 이는 리팩토링된 컴포넌트를 통합하는 과정에서 발생된다.

컴포넌트를 대상으로 하는 리팩토링은 그 작업 자체만으로도 많은 부분에 영향을 미칠 수 있다. 또한, 컴포넌트의 어떠한 부분을 초점으로 접근할 것인가에 따라 그 접근방법이 다양하고, 그에 따른 리팩토링 전략도 달라질 수 있다. 우선은 컴포넌트를 리팩토링을 하기 전에 컴포넌트가 갖게 되는 뷰에 따라 어떠한 품질 속성들을 요구하는지에 대해 살펴보면 아래 그림과 같다. 컴포넌트 기반 구조 (Component Infrastructure) - 컴포넌트의 기반 구조 차원에서 컴포넌트는 표준화(standardability), 유사성(conformability), 가용성(availability) 등의 품질 속성을 말할 수 있다. 이는 컴포넌트의 구조를 이루는 뼈대에 해당하는 부분이 얼마나 견고하고 일관성 있게 만들어졌는..

3.5 기타 아래 표는 다양한 클러스터링 기준을 제시한다. 기업 내의 조직 의 책임이 강조되는 시스템의 경우 소유권을 중심으로 클러스터링을 하며, 레거시를 기반으로 하는 클러스터링, 위치에 따른 클러스터링, 그 외에도 다양한 방식의 클러스터링 기준을 아래표로 존재한다. 컴포넌트 클러스터링 기준은 컴포넌트화를 위한 조직의 비즈니스 드라이버에 의해 좌우된다. 아래 표에서 제시한 10 가지 클러스터링은 하나 이상의 기준이 복합적으로 적용될 수 있다. 그림 3-5. 기타 컴포넌트 클러스터링 기준 소유권에 따른 클러스터링 : 데이터와 활동이 조직의 부서에 의한 사용 혹은, 조직의 부서의 관리 목표에 따라 클러스터링 된다. 결국 조직 구조와 일치하는 시스템 구조를 만들게 된다. 이것은 시스템이 조직 단위 사이의 의..

3.4 역할 클러스터링의 대상이 되는 객체/컴포넌트의 역할에 따른 클러스터링이 가능하다. 따라서 임의의 객체/컴포넌트는 예를 들면, Controller의 역할을 수행하기 위해 클러스터를 형성한다. 다음 그림은 컴포넌트를 위한 여섯 가지 역할을 제시한다. 이 역시 컴포넌트 클러스터링을 위한 또 하나의 기준이 될 수 있다. 컴포넌트 클러스터링 목표 도메인의 특성에 따라 새로운 역할이 존재할 수 있으며, 시스템에 새로운 역할의 추가 및 기존 역할의 확장을 할 수 있다. 역할을 클러스터링에 사용하는 방식은 RDD (Responsibility Driven Design) 기반의 OOAD 기법에서 가져온 개념으로 일부는 비즈니스 컴포넌트를 구성하는 내부의 소규모 컴포넌트들에 역할과 책임을 부여할 때 사용할 수 있다...

3.3 유형 컴포넌트의 유형은 크게 데이터 중심, 프로세스중심, 규칙 중심의 컴포넌트로 나눌 수 있다. 컴포넌트 클러스터링을 위해 이러한 유형을 식별하는 작업이 필요하다. 일단 유형이 식별되면 하나의 비즈니스 컴포넌트를 구성하기 위해 데이터는 데이터 끼리, 프로세스는 프로세스 끼리, 비즈니스 규칙은 비즈니스 규칙 끼리 함께 묶어서 하나의 클러스터를 형성하며, 이 클러스터는 컴포넌트의 후보가 된다. 이외에 컴포넌트화 접근방법에 따라 데이터-드리븐, 프로세스-드리븐, 비즈니스 규칙-드리븐, 협업-드리븐, 유스케이스-드리븐 등 다양한 정책을 기반으로 할 수 있다. 그림 3-3. 유형에 의한 컴포넌트 분류 커플링(coupling)에는 한 컴포넌트가 다른 컴포넌트를 호출하는 두 컴포넌트 간의 운영 종속성 (ope..

3. 컴포넌트 클러스터링 기준 3.1 레이어 - 레이어드(layered)와 크로스 레이어드(cross-layered) 컴포넌트는 그림3-1처럼 레이어 아키텍처를 가질 수 있다. 레이어드 클러스터링은 각 레이어(프리젠테이션, 워크플로우, 비즈니스 객체, 데이터 서비스) 단위로 컴포넌트 구성요소를 묶는 것이다. 크로스 레이어드 클러스터링은 그와 반대로 하나의 비즈니스 로직과 관련된 각 레이어의 구성요소를 묶는다. 그림 3-1. 레이어드와 크로스 레이어드 컴포넌트 클러스터링 기준 중에 아키텍처 관점에서 고정 레이어 (fix layer)를 사용하는 방식은 나누어진 레이어를 클러스터링하는 방법이 각각의 레이어 내에서 컴포넌트를 식별하는 방법과, 레이어와 관계없이 컴포넌트를 식별하고, 컴포넌트를 레이어로 나누는 크..