dev 3.4 아키텍처정의서

1. 개요(Overview)

아키텍처는 시스템을 구성하는 요소 (elements)를 정의하고, 이 요소들간의 상호작용을 모호함이 없이 정의하여 어떠한 형태를 갖는 구조와 행위로 나타내는 것이라고 할 수 있다. 따라서, 아키텍처 정의서에서는 시스템(system)을 구성하는 요소들과 이들간의 상호작용 및 구조를 정의해야 한다. 이것을 보다 체계화하여 나타내기 위해 Innovator 방법론에서는 아키텍처를 비즈니스 아키텍처, 소프트웨어 아키텍처, 기술 아키텍처의 관점으로 정의하고 있다.
Business ArchitectureSoftware ArchitectureTechnical Architecture* Business Object

• Business Service
• Business Process* Analysis & Design Models, Patterns
• Software Component
• APIs & Application Adaptors* Transaction management
• Communication Support
• Naming, location, security, etc.
  [그림1] 삼성 SDS 개발프로세스 표준
  아키텍처 모델인 [그림1] 의 내용을 살펴보면 다음과 같다.
• 비즈니스 아키텍처 (Business Architecture) : 현실 세계의 비즈니스 도메인을 비즈니스 객체와 프로세스로 추상화하여 해당 비즈니스에서 제공하는 서비스를 나타내는 모델이다.
• 소프트웨어 아키텍처 (Software Architecture) : Workflow와 비즈니스 컴포넌트를 결정하며 어플리케이션 내부구조를 표현한 모델이다.
• 기술 아키텍처 (Technical Architecture) : 기술적 컴포넌트와 플랫폼 인프라에 의거하여 제공되는 기술적 서비스를 결정하며, 어플리케이션의 운영 및 개발 환경을 표현한다.

아키텍처 정의서 또한 이러한 세가지 아키텍처 관점으로 시스템을 구성하는 각 요소들을 정의하고 소프트웨어의 구조와 상호작용에 대한 추상화된 모델링을 통해 설계 및 개발에 있어서 일관되고 체계적인 설계 및 개발이 될 수 있도록 한다.

1. 작성기준
   1. 미작성시 영향

• 고객이나 개발자들이 시스템에 대한 개념적인 이해를 할 수 없으므로 프로젝트 의사소통에 지장을 줄 수 있다.
• 아키텍쳐에 대한 상위-수준의 비전과 시스템의 범위를 명확히 제시할 수 없다.
• 시스템의 전반적인 구조를 이해하지 못하므로 인해 위험을 조기에 식별할 수 없다.

1. 1. 작성이 불필요한 경우

아키텍처정의서는 반드시 작성하도록 한다.

1. 1. 제출시 고려사항

분석단계 완료 시 고객에게 제출하고 승인을 받도록 한다.

1. 작성항목
   1. 개요

• 개요에 작성할 내용은 아키텍처 정의서가 서술하고 있는 개요(Overview)에 대한 내용과 아키텍처 정의서가 시스템 아키텍처를 바라보는 세가지 관점(비즈니스 아키텍처, 소프트웨어 아키텍처, 기술아키텍처)이 무엇을 의미하는 지에 대하여 명확한 정의를 내려준다. 이것은 아키텍처 정의서가 어떠한 관점으로 무엇을 기술할 것인지에 대한 분명한 기준을 제시하여 참조자로 하여금 아키텍처 정의서의 구조와 전달할 내용에 대한 정보를 파악할 수 있게 한다.
• 개요에 대한 하위 항목으로는 아키텍처의 목적(Purpose), 적용범위(Scope), 제약사항(Constraints), 기술 표준 및 구조(Technology standard) 등이 작성될 수 있다.
  1. 1. 목적(purpose)
• 아키텍처 정의서를 통해 얻을 수 있는 이점이나 목적을 작성한다. 또한 설계 시 고려되어야 할 요소들이나 아키텍처의 도출 배경과 타당성들을 기술해 줄 수 있다.

1. 1. 1. 적용범위(Scope)

• 아키텍처 정의서의 적용범위에 대해 간단히 기술한다.

1. 1. 1. 제약사항(Constraints)

• 요구사항 정의서에 나타난 기본 제약 조건들 중 시스템에 반영되어야 하는 제약사항(constraints)을 명시한다. 제약 사항은 요구분석단계에서 도출되어 시스템에 반영되어야 할 것으로 아키텍처 정의서 서두에 제약사항을 명세함으로써 아키텍처 도출에 있어서 근거를 제시할 수 있다.

1. 1. 1. 기술표준 및 구조(Technology Standard)(선택)

• 최근에 기술 발전의 속도는 매우 빨라서 다양한 종류의 기술들이 쏟아져 나오고 또 기존의 기술도 버전업이 되는 경우가 매우 많다. 따라서 아키텍처 정의서 상에 가정하고 있는 기술표준이 무엇인지를 정의해준다. 이것은 향후 기술간의 호환과 안정성, 검증에 있어서도 기준이 될 수 있다.
• 기술 표준 및 구조를 정의할 때, 기술 블럭(Technical Building Block)의 형태로 작성하여 한 눈에 볼 수 있도록 작성할 수도 있다.

1. 1. 1. 참조대상자(Audience) (선택)

• 아키텍처 정의서를 참조하게 되는 참조대상자들의 역할을 중심으로 명세하여 아키텍처 정의서 상의 독자를 명시할 수 있다. 이는 아키텍처 정의서가 초점을 맞추어야 할 대상을 잡는데 기준이 될 수 있다. 즉, 개발자가 주로 참조하는 문서인지, 고객이 향후 시스템 운영을 위해 참조하는 문서인지에 따라 기술되는 방향이 달라질 수 있으므로, 이를 개요부분에 명시하는 것이 좋다.

1. 1. 비즈니스 아키텍처
2. 비즈니스 아키텍처 모델

• 비즈니스 아키텍처는 해당 도메인에서 사용자가 처리하는 Business Events, 각 Event 가 발생했을 때 사용자가 수행해야 할 단위 업무들과 업무처리 Flow, 업무처리 시 준수해야 할 표준 또는 가변적인 프로세스들을 모델화하는 것이다. 이러한 것을 모델화한 모델로는 요구 분석시의 산출물들이 될 수 있다. 이러한 모델들이 이미 작성되어 있다면, 아키텍처 정의서에서는 별도로 추가적인 작업 없이 이러한 산출물들을 Link 혹은 간략히 명세 해주면 된다.

예) 액티비티 다이어그램(To-Be), 패키지 구조(업무기능), 유스케이스 다이어그램

1. 1. 소프트웨어 아키텍처

• 소프트웨어 아키텍처는 소프트웨어 아키텍처 스타일, 설계 메커니즘 등의 관점으로 작성되는데, 이러한 세 가지 관점에 대한 정의와 기준을 간략히 기술한다. 또한, 위의 관점이 어떻게 소프트웨어 아키텍처에 반영되고 있는지 본 문서를 참조하는 독자에게 기준을 제공해 줄 수 있다.
• 소프트웨어 아키텍처 스타일: 전체 구성도에서 소프트웨어의 작동원리를 중심으로 티어(Tier) 혹은 레이어(Layer)로 아키텍처 스타일을 정의한다. 소프트웨어를 구성하는 클래스 또는 컴포넌트 요소들과 이들간의 상호작용을 표현한다.
• 설계 메커니즘: 소프트웨어를 구성하는 주요 이슈들을 중심으로 설계 시에 고려해야 할 주요 메커니즘을 정의한다.

1. 1. 1. 소프트웨어 아키텍처 스타일

• 소프트웨어 아키텍처 스타일은 보통 Layered Architecture로 정의될 수 있다. Layer에 따라 각 역할과 책임을 분명히 정의하여, 각 Layer가 어떤 역할을 수행하는지에 대한 기준을 독자에게 제공하는 것이 중요하다. 본 방법론에서는 MVC모델을 적용한 Layered Architecture를 기본으로 가이드하고 있다.
• Layer에 의한 정의의 예(1)

프리젠테이션 레이어, 워크 스페이스 레이어, 워크 플로우 레이어, 서비스 레이어, 퍼시스턴스 레이어

• Layer에 의한 정의의 예(2)

프리젠테이션 레이어, 비즈니스 레이어, 퍼시스턴스 레이어

• 이렇게 정의된 스타일을 중심으로 다음과 같이 전체 소프트웨어 아키텍처 스타일을 한눈에 볼 수 있는 형태로 제공하고, 전체 스타일 중 각 레이어에 대해 부분적으로 상세하게 설명할 수 있는 형태로 나누어 작성한다.

1. 1. Layered 소프트웨어 아키텍처

• 전체 소프트웨어 아키텍처를 작성하고 각 레이어(Layer) 별 구성요소에 대해 설명한다.

2) 소프트웨어 아키텍처 상세 가이드

• 각 Layer별로 구성요소들간의 협력작용을 상세히 기술하도록 한다.
• 이때 사용하는 패턴이나 혹은 프레임워크는 소프트웨어 아키텍처 스타일 하단에 다음과 같이 기술한다.
• 설계패턴 (옵션)

아키텍처상에 언급되는 주요 설계패턴과 설계 시 참조할 패턴을 정의하고 참조사이트를 링크한다. 아키텍처 정의서에 사용될 패턴을 정의함으로써 설계 패턴의 남용(Overuse)과 설계 패턴의 불충분한 사용(Underuse)를 방지하도록 한다.
표현 예 )
클래스 패턴 참조사이트
ProjectDAO DAO http://java.sun.com/.....

• 프레임워크

프로젝트에서 재사용 및 생산성 향상을 위해 프레임워크를 사용한다면, 구체적으로 사용된 프레임워크를 아키텍처 정의서에 명세하고 참조문서를 링크해준다. 특히 사내에서 개발된 프레임워크를 사용한다면 프레임워크 작성가이드에 따라 프레임워크의 메커니즘과 구조를 간략히 기술하도록 하고 아키텍처 정의서는 이 문서를 참조하는 형태로 작성한다. 내부적으로 개발된 프레임워크나 오픈 소스(Open Source) 혹은 재사용 프레임워크를 적용하게 된다면 그 목록만을 작성하고, 참조문서와 연결하거나 간단히 기술될 수 있는 내용이라면 아키텍처 정의서 내에 포함시켜도 무방하다.
단, 프레임워크는 분석/설계자나 개발팀에게 있어서 중요한 고려사항이므로 이들이 프레임워크를 잘 이해할 수 있도록 적용 가이드 문서를 별도로 작성하거나, 소프트웨어 아키텍처 상에 반영 되어야 하는 부분을 분명하게 명세하도록 한다.

1. 1. 1. 설계 메커니즘

• 아키텍처를 시스템으로 구현하기 위해 설계시에 필요한 주요 설계 메커니즘을 설명한다. 각 프로젝트에서 고려하는 주요 메커니즘으로는 다음과 같은 것들이 있다.

1. 1. 데이터접근

• 데이터 접근과 관련한 주요 메커니즘을 기술한다. 주로 자원의 재사용을 통한 DB Connection 과 관련된 메커니즘이 서술될 수 있으며 생성,수정,삭제,조회 관련해서 대표적인 메커니즘이 있다면, 이를 클래스 다이어그램과 시퀀스 다이어그램을 통해 모델링하여 분석/설계자들이 설계시 사용할 수 있도록 한다.
• 표현 예 )
• 클래스다이어그램(연결,생성,수정,삭제,조회) 혹은 시퀀스 다이어그램(연결,생성, 수정,삭제,조회)
• 참조 도해(연결, 자원재사용 방식)
• 참조) UML로 작성된 다이어그램과 코드는 설계 시에 제공되어 사용될 수 있다.

2) 보안

• 보안과 관련한 주요 메커니즘을 기술한다. 보안에 관련된 부분이 중요하고, 별도의 전문가나 Vendor의 도움을 받는 경우 보안계획서를 별도의 문서로 작성할 수 있다.
• 보안과 관련한 메커니즘으로는 다음과 같은 두 가지 항목으로 작성될 수 있다.

• 사용자 권한 및 메뉴설정

사용자의 권한 및 메뉴설정 관련한 메커니즘을 정의할 수 있다. 이 외에 정의해야 할 사항은 별도로 기술해 준다. 이때 보안전문업체를 통해 보안계획서를 별도로 작성할 수 있다.

• 보안 적용기술

보안 적용기술을 정의한다. SSL의 사용여부 및 인증관련 보안 알고리즘을 정의하고,이것을 지원하는 패키지나 라이브러리를 정의하여 보안 메커니즘을 아키텍처 상에 정의할 수 있다.
3) 로깅, 에러 및 예외처리

• 예외 처리 및 로그관리와 관련하여 정의할 내용을 작성한다. 로그,에러,예외처리로 각각 나누어 기술할 수 있다. 특히 예외처리 부분은 비즈니스 관점의 Exception과 시스템 측면의 Exception 발생시 처리 절차를 명확히 정의하는 것이 좋다. 개발자가 코딩시 참조하는 예외처리 및 로그관리에 대한 샘플 코드는 SPM의 개발표준 부분에 추가하도록 하는 것이 좋다.

1. 기타

• 이 밖에 꼭 정의해야 할 메커니즘이 있다면 기타 메커니즘에 작성하도록 한다. 참조할 수 있는 항목은 다음과 같다.
• XML & XSL 처리 : XML과 XSL의 처리 방식을 정의할 수 있다.
• 국제화 처리 : 시스템의 국제화 지원 여부를 정의한다.

표현 예 ) 국제화 처리 규약, 규칙 등

• 공통코드 처리 : 공통코드의 처리 방식을 정의한다.
• 보고서 출력 및 통계처리 : 보고서 출력 기능이 있고 다른 별도의 보고서 출력을 지원하는 어플리케이션을 사용한다면 개발시스템과 이것과의 연동 및 작동 메커니즘을 정의한다.
• 이외에도 별도의 패키지 어플리케이션을 사용하게 되면 이것과 개발 시스템과의 연동 문제를 기술하여야 한다.

1. 1. 기술 아키텍처

• 기술 아키텍처는 물리적 H/W환경과 소프트웨어의 구성 및 사양을 정의한 것이다. 이는 다음과 같은 두 가지 관점에서 기술될 수 있다.

• 하드웨어와 네트워크의 구성 및 사양 : 물리적 운영환경, 분산환경 혹은 클러스터 환경에 따라 시스템을 위해 필요한 하드웨어 및 네트워크에 대한 기술적 구성 사양을 설명한다.
• 소프트웨어 구성 및 버전 : 운영환경과 개발 단계에서 사용되는 소프트웨어와 버전 등을 명세화하여 개발자 및 운영자가 참조하도록 한다.

1. 1. 1. 하드웨어 및 네트워크 구성 및 사양

• 하드웨어 및 네트워크가 어떻게 구성되는지 파악할 수 있도록 작성한다. 이때 작성해야 할 내용으로는 Cluster 환경인지 아닌지, Distribute 환경인지 아닌지가 잘 나타날 수 있도록 작성한다. H/W 및 N/W 장비나 세부 사양은 별도로 나누어 표를 사용해서 작성해도 되고, 그림이나 다이어그램으로 나타낸 전체 시스템 구성도상에 함께 표시할 수도 있다.
• 하드웨어 및 네트워크 구성

외부 시스템과의 인터페이스 방식 및 장애 대비 방안, 장애 발생시 처리 및 복구 방안, 백업 및 시스템의 운영을 위해 필요한 용량산정에 관한 결과도 필요한 경우 아키텍처 정의서에 정의할 수 있으나, 별도의 문서로 작성하는 것이 개발 및 향후 운영에 도움을 줄 수 있다.
기술환경에 따른 소프트웨어 구성 : 물리 운영 환경에서 작동하는 기술 소프트웨어의 Communication 방식을 구조적으로 작성한다. 이러한 그림은 소프트웨어 설계 및 개발에 있어서 중요한 고려사항이 될 수 있다. 또한 추가적으로 동시사용자수나 트랜잭션 양을 기술할 수 있다.

1. 1. 1. 소프트웨어 구성 및 버전

• 개발환경과 운영환경을 나누어 소프트웨어명과 버전을 명세할 수 있다. 또한, 소프트웨어 기술환경을 그림이나 다이어그램을 통해 보다 명확히 명세할 수도 있고, SPM이나 기타 문서에 기술한 경우 아키텍처 정의서에서는 생략할 수도 있다.

1. 1. 용어정의(Glossary) (선택)

• 아키텍처 정의서에 나타나는 새로운 기술에 대한 약어나 용어를 선택적으로 정의할 수 있다.
• 예) ICE : The Information and Content Exchange(ICE) Protocol, *http://www.w3.org/TR/Note_ice*
• WSRP : Web Service Remote Portals, http://www.oasis-open.org/commitees/wsr/

1. 1. 참조 문서(References) (선택)

• 아키텍처 정의서를 작성하는데 있어서 참조가 된 문서를 명세할 수 있다.

예) Vision for Technology Development, Valerie Smothers, January 2003.

1. 작성시 고려사항

• 아키텍처를 정의시 여러가지 대안이 검토된 경우에는 대안에 대한 내용도 기술하도록 한다.
• 공통
• 비즈니스 아키텍처, 소프트웨어 아키텍처, 기술 아키텍처는 서로 간의 일관성을 유지한다.
• 설계를 수행할 수 있도록 충분히 기술한다.
• 작성된 아키텍처는 요구사항을 충분히 반영한다.
• 작성된 아키텍처를 가지고 이해당사자(stakeholder)들과 충분한 대화를 통해 리뷰를 수행한다.
• 비즈니스 아키텍처(Business Architecture)
• 비즈니스 아키텍처를 표현한 모델과의 관계가 적절히 잘 작성한다.
• 소프트웨어 아키텍처(Software Architecture)
• 소프트웨어 아키텍처 스타일을 기반으로 설계 및 개발하는 데 있어 필요한 충분한 정보를 기술한다.
• 소프트웨어 아키텍처 스타일에서 사용하는 프레임워크나 패턴을 상세히 기술한다.
• 설계 진행 중에 필요한 의사결정 문제를 설계 메커니즘을 통해 솔루션을 제공하고 이를 잘 표현한다.
• 소프트웨어 아키텍처를 표현하는 세가지 관점상 일관성을 유지한다.
• 기술 아키텍처(Technical Architecture)
• 하드웨어 구성을 위한 기본방향 및 네트워크 구성을 상세히 기술한다.
• 지역별로 N/W이 구성될 경우 중앙과 지역간의 통신 구성방식을 상세히 기술한다.
• 웹 서버, 미들웨어 서버, 통합서버, DB서버에 대한 상세 사양을 잘 정의한다.
• 개발 및 운영 환경에서 사용하는 소프트웨어의 버전을 정확히 표시한다.
• 실제 운영환경에서 하드웨어 상에 로드된 소프트웨어 인스턴스 개수를 모니터링 하고 관리한다.

1. 관련기법(Related Technique)

• 아키텍처정의 기법
• Framework(Athena)적용 기법
• 이터레이션적용 기법