[예비 21기 김택환 발표자료] CBD 개발방법론

[THKim]

CBD개발 방법론 아키텍처란 무엇인가에 대해 발표를 하게 된 김택환입니다.

목차는 아키텍처란 무엇인가에 대하여 정의, 소프트웨어아키텍처와 다은 작업 사이의 관계 아키텍

처가 중요한 이유, 품질속성, 문서화의 7가지 규칙, 아키텍처 적용시 장점, 4+1뷰 아키텍처 모델에

대하여 발표하겠습니다.

소프트웨어 아키텍처는 소프트웨어 요소와 이들 요소의 외부 속성 그리고 이들 사이의 관계를 구성하는 시스템의 구조이다.

소프트웨어 아키텍처는 시스템의 구조를 정의하며 표현한다.

구현할 소프트웨어 시스템의 커다란 그림을 그린다고 보면 됩니다.

이러한 그림을 그리는 사람이 아키텍트라 합니다.

아키텍트는 소프트웨어를 개발할 때 중요한 재료들을 잘 다뤄야 하며,

그것은 비용, 적용기술, 조직의 역량, 기능, 목표, 시스템의 복잡도에 대한

아키텍트의 중요한 판단을 바탕으로 시스템을 구상하고 추상화하는 방법입니다.

이것이 바로 소프트웨어 아키텍처의 기본이며, 소프트웨어 개발을 구상하고 추상화하는 것이

곧 소프트웨어 아키텍처의 과정입니다.

이 그림은 소프트웨어 아키텍처를 중심으로 다른 개발 작업들 사이의 관계를 보여주고 있습니다.

요구파악에서 도출된 요구사항과 품질의 속성 그리고 하드웨어 아키텍처 설계 작업에서 정의된 하드웨어 아키텍처를 입력으로 받아 소프트웨어아키텍처를 정의 하고, 그 결과를 설계/구현/통합

/테스트 작업에 넘겨 주게 된다. 또한 설계 작업에서 변경된 사항들을 요구파악, 하드웨어 아키텍처설계작업에 되돌려주어 아키텍처가 변경될 수 있게 합니다.

이처럼 각 작업은 서로에게 영향을 주고 받으며 협력 하면서 프로젝트를 진행 하게 됩니다.

①이해 당사자 : 고객, 사용자, 개발자, 프로젝트 관리자, 조직 관리자, 마케팅 담당자 등이 있습니다. 이들은 서로 다른 관점에서 요구사항 들을 갖고 있습니다.

이들 이해 당사자들 사이의 서로 다른 관점을 이해 하고, 협상 하며, 합의를 끌어내며, 서로 의사소통 하는데 기반으로서 사용될 수 있습니다.

②초기 설정사항에는 구현에 대한 제약 사항 및 개발시스템에 대한 구조뿐만 아니라 개발

초기에 많은 부분을 결정지을 수 있게 해줍니다.

③소프트웨어의 아키텍처를 재사용 할 수 있다. 프로젝트 초기의 재사용은 많은 이점을 얻게

됩니다.

또한 그림처럼 소프트웨어 아키텍처는 요구사항을 제대로 구현하기 위해 도움을 줄 수

있는 커뮤니케이션 툴로 정의를 내릴 수 있습니다.

개발 초기의 요구사항과 실제 완성된 솔루션과의 갭을 매울 수 있는 역할을 하게 됩니다.

 

①시스템 품질 속성

가용성 – 시스템이 중단되지 않고, 사용자에게 서비스를 제공할 수 있는 능력

변경 가능성 - 시스템의 유지보수를 위하여 사용자의 요청에 손쉽게 변경 가능한 성질

성능 – 응답속도, 처리용량 등 시스템이 소화할 수 있는 능력

보안 – 비 인가자의 접근에 대항 할 수 있는 능력

테스트 가능성 – 테스트를 통해 소프트웨어가 결함을 가지고 있음을 얼마나 쉽게 증명할

수 있는가를 나타낸다.

사용성 – 사용자가 얼마나 손쉽게 원하는 작업을 할 수 있는가와 관련

②비즈니스 품질속성

적시성 – 개발일정을 맞추는 것.(원하는 시간에 제품을 공급)

비용과 예산 – 투자비용대비 얻을 수 있는 수익

목표시장 – 제품을 공급 하고자 하는 곳

첫 공개일정 – 시장에 배포하고자 하는 시점

기존 시스템과 통합 – 기존의 시스템과 인터페이스를 통하여 연계하는 것

③아키텍처 품질속성

개념적 무결성 – 모든 수준에서 시스템 설계가 한데 묶여야 한다는 근본 원리

정확성과 완료성 – 모든 요구 사항과 자원 제약 사항을 만족하도록 아키텍처를 결정해야

 하는 속성.

빌드 가능성 – 적절한 시기에 적시에 쓸 수 있는 팀이 시스템을 완성하고 개발과정에서

 쉽게 변경할 수 있는 능력

좋은 문서를 만드는 문서화의 7가지 규칙입니다.

중요한 내용이니 아키텍처 작성시에 필히 준수하려고 노력 해 주시기 바랍니다.

시스템을 문서화 할 때에는 이렇게 이상을 추구하면서도 차근차근, 부드럽게 설계 과정을 밟아서 결과물을 내야 합니다.

아키텍처를 도입하면 어떤 좋은 점이 있길래 아키텍처를 도입하자고 하는 것일까요? 소프트웨어 아키텍처를 적용하였을 때의 장점을 알아봅시다.

첫째, 아키텍처의 품질을 평가하여 비합리적인 의사 결정이 합리적인 의사 결정으로 변경됩니다.

둘째, 과거의 경험을 답습하거나 과거의 사례에서 배우지 못했던 것에서 소프트웨어 아키텍처를 재사용 함으로서 과거 프로젝트의 성공과 실패 사례를 배우는 것으로 변경됩니다.

셋째, 프로젝트의 복잡성을 아키텍처를 통해 관리하는 것이 가능해 집니다.

넷째, 프로젝트 마무리 시점에서 발생하는 문제들을 아키텍처를 도입하여 프로젝트 초기에

   해결할 수 있습니다.

다섯째, 설계자가 단순히 요구사항을 개발자에게 전달하는 것을 아키텍처를 통해 설계자가 요구사항 분석 뿐 아니라 기술적인 문제도 모델링 할 수 있게 하며 개발자는 더욱 효율적으로 시스템을 구현하는 것이 가능합니다.

①Logical View (논리 뷰)

최종 사용자, 분석가/테스터 관점이며,시스템의 기능적인 요구사항을 반영합니다.

설계 모델의 추상화로 주요 설계 패키지와 서브 시스템, 클래스를 식별합니다.

소프트웨어 아키텍처 구조에서의 모듈 뷰 타입에 속합니다.

논리뷰는 클래스와 이들 사이의 관계의 집합을 보여주는 class diagram 으로 표현합니다.(sequence diagram ,collaboration diagram)

②Implementation View(구현 뷰)

프로그래머 관점에서 개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여줌

소프트웨어 구현과 관리 측면을 컴포넌트로 표현

소프트웨어 아키텍처 구조에서 할당 뷰 타입 중 구현 스타일에 해당 하고

개발 뷰, 컴포넌트 뷰라고도 함

component diagram

③Process View (프로세스 뷰)

시스템 통합자, 분석가/테스터 관점 이고런타임 시의 시스템의 동시적인 면을 표현(task, thread, process)합니다.

프로세스 구조를 클래스 class diagram과 Component diagram으로 표현 하고 소프트웨어 아키텍처 구조에서 컴포넌트-커넥터 뷰 타입에 해당 합니다.

③Deployment View (배포 뷰)

시스템 엔지니어 관점에서 다양한 실행파일과 다른 런타임 컴포넌트가 해당 플랫폼, 혹은

누드에 어떻게 mapping 되는지 표현 물리적인 Node의 구성과 상호 연결 관계를 배포 다이어그램(배치 다이어그램)으로 표현합니다. 소프트웨어 아키텍처 구조에서 할당 뷰 타입

중 배포 스타일에 속합니다.

물리적인 뷰라고도 합니다.

④Use case view (유스케이스 뷰)

유즈케이스와 시나리오를 포함하고, 아키텍처를 도출하고 설계하는 작업을 주도하고 다른

뷰를 검증하는데 사용됩니다.

 

 질문 있으십니까?

감사합니다.

[21기 이종찬]

CBD 아직 많이 남았는데 더 이어서 부탁드려요~~^^