[25기 손정섭] 개체지향 CBD 개발 방법론 (4장 4.1~4.2)

[25기 손정섭]

개체지향 CBD 개발 방법론 중

4장 아키텍처 (Architecture)란 무엇인가? 

선문비트교육센터

25기 손정섭 

목 차 

4. 1 소프트웨어 아키텍처 개념의 이해

4. 2 비 기능 요구사항과 품질 속성 

4. 1. 1 소프트웨어 아키텍처 정의

- 소프트웨어 요소와 이들 요소의 외부 속성 그리고 이들 사이의 관계를 구성

하는 시스템의 구조.

- 소프트웨어 아키텍처는 시스템의 전반적인 구조,

- 소프트웨어 아키텍처는 시스템의 컴포넌트와 이들 사이의 관계 그리고

이들의 설계 및 변경에 대한 원리와 가이드라인을 정의한 구조

- 소프트웨어 아키텍처 정의를 통해 알 수 있는 사항

   1. 소프트웨어 아키텍처는 소프트웨어 시스템의 구조를 결정.

   2. 소프트웨어 시스템은 여러 소프트웨어 요소 또는 컴포넌트로 구성.

   3. 소프트웨어 요소 또는 컴포넌트는 외부로 드러나는 속성, 즉 인터페이스를 가짐.

   4. 소프트웨어 요소 또는 컴포넌트는 다른 소프트웨어 요소 또는 컴포넌트와

      관계를 가지며, 인터페이스를 통해 서로 커뮤니케이션.

   5. 소프트웨어 아키텍처는 소프트웨어 요소 또는 컴포넌트를 설계하고

      변경하는 것에 대한 원리와 가이드라인을 제공.

4. 1. 2 소프트웨어 아키텍처와 다른 작업 사이의 관계     

-       설계작업은 요구파악 작업에서 필요한 요구사항과 품질속성, 그리고 하드웨어 아키텍처 설계에서 정의된

    하드웨어 입력을 받아 소프트웨어 아키텍처를 정의하고 그 결과를 설계구현/통합테스트에 넘겨줍니다.

    또한 소프트웨어 아키텍처 설계작업에서 변경된 요구파악 작업에 되돌려줌으로써 요구사항 변경이 가능하고

    마찬가지로 하드웨어 아키텍처에 대한 변경도 하드웨어 아키텍처 설계작업에 되돌려줌으로써 하드웨어

    아키텍처가 변경될 수 있게 합니다. 소프트웨어 아키텍처 설계작업에서도 상세설계, 구현, 통합, 테스트 작업에서

    도출된 구현 제약사항을 받아서 아키텍처에 반영할 수 있습니다. 이 그림처럼 각 작업은 서로에게 영향을 주고

    받고 협력하면서 프로젝트를 진행하게 됩니다.

 4. 1. 3 소프트웨어 아키텍처가 왜 중요한가?

1) 이해당사자 사이의 의사소통.

- 소프트웨어 아키텍처는 이해당사자 사이의 의사소통의 수단으로 사용되는데, 소프트웨어

시스템의 구축에는 많은 사람들이 관여하게 되며, 이들을 이해당사라 합니다. 이들은

소프트웨어 시스템에 대하여 서로 다른 관점과 요구사항들을 가집니다. 가령 고객은

낮은 비용으로 적시에 공급되고 자주 변경되지 않는 소프트웨어 시스템을 원할 것이며,

end_user는 시스템이 사용하기 쉽고 빠르며 안전하고 신뢰할 수 있는 것을 원할 것 입니다.

소프트웨어 아키텍처는 이들 이해당사자들 사이의 서로 다른 관점을 이해하고, 협상하며

합의점을 끌어내며 서로 의사소통 하는데 기반으로서 사용될 수 있는 공통적인 언어로서

시스템의 추상화를 표현합니다.

2) 초기 설계 결정 사항.

    - 아키텍처는 구현에 대한 제약사항을 정의하고 개발할 시스템에 대한 구조뿐 아니라

      구조도 정의합니다. 또한 뒤에서 나올 시스템의 품질 속성을 실현할 것인지의 여부도

      결정하게 되며 시스템을 변경해야 할 필요가 있을 때 가장 적은 비용과 위험부담을 갖는

변경 경로를 소프트웨어 아키텍처를 사용할 수 있습니다. 이 외에도 소프트웨어

아키텍처는 프로젝트 관리자가 비용과 스케줄을 추정하는데 사용 할 수 있습니다.

   3) 재사용할 수 있는 시스템의 추상화.

    - 소프트웨어 아키텍처를 재사용할 수 있다. 당연한 말이지만 프로젝트 초기에 재사용성을

적용할 수 있다면 그만큼 더 많은 이점을 얻게 될 것입니다. 마찬가지로 코드를

재사용하는 이점도 있지만, 아키텍처 단계에서의 재사용은 유사한 요구사항을 갖는

시스템에 대하여 많은 이점을 제공한다. 이 경우 코드뿐만 아니라 아키텍처를 결정짓게

한 요구사항, 아키텍처 설계 경험까지 모두 재사용할 수 있게 된다.

4. 2 비 기능 요구사항과 품질 속성

1) 시스템 품질 속성.

2) 비즈니스 품질 속성.

3) 아키텍처 품질 속성.

4. 2. 1 시스템 품질 속성

(1) 가용성 – 시스템이 필요할 때 작동하게 될 가능성의 정도를 의미.

(2) 변경가능성 – 시스템을 변경하는데 소요되는 시간과 노력 등의 비용.

(3) 성능 – 시스템이 얼마나 빠르고 효율적으로 원하는 기능을 수행하는가 하는 문제와 관련.

(4) 보안 – 적법한 사용자에 대해 서비스를 제공하고, 권한이 없는 사용자에 대해서는 서비스를 거부하는 시스템의

             능력을 측정.

(5) 테스트가능성 – 테스트를 통해 소프트웨어가 결함을 가지고 있음을 얼마나 쉽게 증명할 수 있는가를 나타냄.

(6) 사용성 – 얼마나 손쉽게 원하는 작업을 할 수 있는가를 나타냄.

4. 2. 2 비즈니스 품질속성

시스템의 품질 속성과 함께 비즈니스에 관련된 품질 속성도 자주 아키텍처에 영향을 미치게 된다. 여기에는 다음과 같은 품질 속성이 포함된다.

(1) 적시성 – 만약 서비스 개시일이 공식 발표되어 소프트웨어 시스템을 런칭해야 하는 일정이 고정되어 변경될 수

               없거나, 시장의 주도권을 잡기 위해 경쟁사의 제품보다 먼저 출시해야 한다고 할 때 개발 일정을 맞추는

               일이 중요해지므로 아키텍처에 영향을 미치게 됨.

(2) 비용과 예산 – 아키텍처마다 서로 다른 개발비용을 산출하게 되는데 일반적으로 유연성이 높은 아키텍처는 그렇지

                     않은 아키텍처보다 더 많은 예산 필요.

(3) 시스템의 내구연한 – 시스템을 얼마나 오랫동안 사용하느냐 하는 것도 아키텍처에 영향을 미치는데 시스템의

                             내구연한이 길어야 한다면 변경가능성, 확장성, 이식성 등의 시스템 품질 속성이 중요해짐.

(4) 목표시장 – 범용성을 갖는 소프트웨어라면 기능뿐만 아니라 시스템이 실행하는 플랫폼도 잠재적인 시장의 크기를

                  결정하는 요소가 되는데 따라서 이 경우에는 이식성과 기능성이 시스템의 품질 속성을 결정하게 됨.

(5) 첫 공개일정 – 첫 버전에서는 기본적인 기능만을 제공하고 많은 다른 기능들을 이후 버전에서 릴리즈(기능 제한을

                     해제)하기로 했다면 유연성과 확장성이 시스템의 중요한 품질 속성이 됨.

(6) 기존시스템 – 새로운 시스템이 기존 시스템과 통합해야 한다면 적절한 통합 매커니즘을 정의하는데 많은 노력을

                    기울어야 하며 이것은 아키텍처를 결정하는데 있어서 제약사항으로 작용.

4. 2. 3 아키텍처 품질속성

시스템 품질 속성과 비즈니스 품질 속성도 소프트웨어 아키텍처에 영향을 주지만 특별히 아키텍처 그 자체에만 직접 관련된 품질 속성도 있는데 이러한 품질속성을 아키텍처 품질 속성이라고 하며 다음과 같은 품질 속성을 포함.

(1) 개념 무결성.

 - 모든 레벨에서 시스템의 설계를 단일화하는 주제나 비전을 의미.다시 말해 아키텍처는 유사한 방법으로 유사한 일을

   해야 한다는 것.

(2) 정확성과 완료성.

 - 아키텍처가 시스템의 모든 요구사항과 런타임 자원 제약을 충족시키는 것은 모든 아키텍트가 가지고 있는 최선의

   바람.

(3) 빌드 가능성.

 - 적시에 가용 팀에 시스템이 완료되고 개발 진행에 따라 일정한 변경이 허용되도록 하는데 이것은 최대한 병렬식

   개발을 통해 원하는 시스템을 손쉽게 구축하는 것을 가리킨다. 이를 위해서는 시스템을 적절하게 모듈로 분할하고

   분할된 묘듈을 적절하게 개발팀에 분배하고 모듈과 팀 사이의 종속성을 제한해야 한다.