3장 아키텍쳐란 무엇인가.pptx
목차가 많습니다... 여기서 중요한 부분만 요약 정리하겠습니다.
소프트웨어 아키텍처가 구현할 소프트웨어 시스템의 커다란 그림을 표현한다는 것을 의미한다.
소프트웨어 아키텍처는 상위 레벨의 추상화를 통해서 시스템의 전반적인 모습을 보여주는 것이다. = 소프트웨어 시스템의 자세한 것은 언급 안 한다.
인터페이스를 통해 외부로 드러나는 속성을 표현한다. 컴포넌트는 인터페이스를 통해 서로 커뮤니케이션을 한다.
소프트웨어 시스템의 구조는 컴포넌트들과 컴포넌트 사이의 인터페이스 관계를 보여주며 결국 이것을 소프트웨어 아키텍처라 부른다..
요구파악에서 도출된 요구사항과 품질속성, 하드웨어 아키텍처 설계작업에서 정의된 하드웨어 아키텍처를 입력 받아 소프트웨어 아키텍처를 정의한다. 소프트웨어 아키텍처 설계 결과를 상세설계, 구현 통합 테스트 작업에 넘겨준다. 소프트웨어 아키텍처 설계 과정에서 변경된 요구사항을 요구파악 작업에 넘겨줌으로 요구사항을 변경할 수 있게 하며 하드웨어도 마찬가지이다. 소프트웨어아키텍처 설계작업에서도 상세설계/구현/통합테스트/작업에서 도출된 구현제약사항을 소프트웨어아키텍처 설계에 반영하게 된다. 이처럼 각 작업은 서로 영향을 주고 받으며 협력하면서 프로젝트를 진행한다. 1.이해 당사자들은 소프트웨어시스템에 대하여 서로 다른 관점을 가지고 있다. 가령 고객은 낮은 비용으로 적시에 공급되며 자주 변경되지 않는 소프트웨어시스템을 원할 것이고 사용자는 사용하기 쉽고 빠르고 안전하고 신뢰할 수 있는 소프트웨어 시스템을 바랄 것이다. 소프트웨어 아키텍처들은 이들 이해 당사자들 사이의 서로 다른 관점을 이해하고 협상하며 합의를 끌어내며 서로 의사 소통하는데 기반으로서 공통적인 언어로 시스템의 추상화를 표현한다. 2. 아키텍처를 구현에 대한 제약사항을 정의하며, 개발할 시스템에 대한 구조 뿐 아니라 개발 조직의 구조도 정의한다. 시스템의 품질 속성을 실현할 것인지 여부도 결정,시스템변경이 있을 때 가장적은 비용과 위험부담을 갖는 변경경로를 결정하는데 소프트웨어 아키텍처를 사용할 수도 있다. 3. 프로그램 초기에 재사용성을 적용한다면 그만큼 더 많은 이점을 얻게 된다. 아키텍처단계에서의 재사용은 유사한 요구사항을 갖는 시스템에 대하여 많은 이점을 제공한다.이로 인해 아키텍처를 결정짓게 한 요구사항, 아키텍처의 설계 경험까지도 재사용할 수 있게 된다.
시스템의 실패는 일괄적인 서비스를 제공하지 못할 때 발생 한다. 사용자는 시스템의 실패를 알 수 있게 될 때부터 실패의 원인을 제거함으로써 시스템을 복구해야만 재 가동할 수 있게 된다. User가 system에 작업을 요청할때 시스템은 반응하고 그 결과를 user에게 제공한다 이때 대기시간을 알 수 있다. 분당 또는 초당 처리할 수 있는 트랜잭션의 수로도 표현된다. 인증 : 사용자가 자신임을 밝힘 권한 : 사용자가 어떤 리소스에 접근하게 할지 결정한다. 기밀성 : 권한이 없는 사용자가 접근을 허용하지 못하게 한다. 무결성 : 권한이 없는 사용자가 데이터를 변경하지 못하게 하는 속성 부인방지 : 사용자가 자신이 했다는 것은 부인하지 못하게 하는 속성. 가상머신은 인터페이스를 통해 다른 모듈에 서비스를 제공하며 다른 모듈에서는 가상머신이 제공하는 서비스가 어떻게 구현되었는지 알지 못하고도 제공되는 인터페이스를 통해 서비스를 사용할 수 있다. <<layer>>스테레오탑입을 갖는 패키지로 표현, 패키지사이의 관계는 <<allowed to use>> 스테레오 타입을 갖는 종속관계로 표현 레이어 B는 레이어 A 아래에 놓이게 되며 레이어 A는 레이어B가 제공하는 인터페이스를 통해 기능을 사용할 수 있도록 허용된 상태 이러한 상태를 허용된 상태라 한다. 1개발자들은 자신의 소프트웨어가 어느 레이어에 놓이게 되는가를 알면 코드 작업 환경에서 어떤 서비스를 사용할 수 있는지를 알게 된다. 또한 레이어는 개발 팀에게 작업을 할당하는 기준을 제공할 수도 있다. 2 모듈을 인터페이스를 갖는 레이어로 구성할 때 레이어는 이러한 복잡성을 관리하는 중요한 도구가 된다. 3. 시스템을 변경할 필요가 있을 때 변경할 영역을 경정하게 함으로써 변경 영향도를 분석하여 설계에 넘겨줄 수 있다. 논리 뷰 : 시스템의 기능적인 요구사항 즉, 시스템이 최종사용자를 위해 해야만 하는 것을 지원......... 논리 뷰는 설계모델의 추상화 이며 주요 설계 패키지와 서브 시스템,클래스를 식별한다. 클래스와 이들 사이의 관계의 집합을 보여주는 클래스 다이어그램으로 표현 구현 뷰 : 개발 환경안에서 정적인 소프트웨어 모듈(소스코드,데이터파일,컴포넌트,실행파일)의 구성을 보여준다… 소프트웨어는 서브시스템 등의 작은 단위로 패키지며 이들 패키지는 소수의 개발자에 의해 개발된다 서브시스템은 레이어 계층으로 구성되며 각 레이어는 상위 레이어에 대해 잘 정의된 인터페이스를 제공한다. 개발자 관점에서 소프트웨어의 구현과 관리적인 측면을 컴포넌트 다이어그램으로 표현한다. 프로세스 뷰 : 런타임 시의 시스템의 동시적인 면, 즉 task ,thread, process 그리고 이들 사이의 상호작용 등의 관계를 표현하며 성능이나 가용성과 같은 시스템의 비기능적인 요구사항을 고려한다. 이 뷰는 배포,시스템무결성, 내구성과 같은 문제를 해결한다. 프로세스 뷰는 시스템의 프로세스 구조를 <<process>>와<<thread>>스테레오타입을 사용하여 클래스 다이어그램과 컴포넌트 다이어그램으로 표현한다. 배포 뷰: 다양한 실행 파일과 다른 런타임 컴포넌트가 해당 플랫폼 또는 컴퓨팅 노드에 어떻게 맵핑되는가를 보여주며 가용성,신뢰성,성능,확장성 등의 시스템의 비기능적인 요구사항을 고려한다.물리적인 노드의 구성과 상호 연결 관계를 배포 다이어그램으로 표현한다. 유스케이스 뷰 : 특별한 역할을 하는데 ,,, 이뷰는 몇 개의 주요 유스케이스 또는 시나리오를 포함한다. 유스케이스 또는 시나리오는 아키텍처를 도출하고 설계하는 작업을 주도한다. 그러나 나중에 이들은 아키텍처의 다른 뷰를 검증하는데 사용된다. ooCBD방법론에서는 전체시스템 아키텍처를 비즈니스 아키텍처, 애플리케이션 아키텍처, 기술 아키텍처, 데이터 아키텍처로 구분하고 이것들을 각 아키텍처 관점에서 소프트웨어 시스템의 구조를 분할하고 각 구조를 표현 하도록 함.ooCBD방법론은 “4+1뷰”를 응용하여 유스케이스뷰,논리뷰,구현뷰,배포뷰를 포함하고 프로세스뷰를 제외하엿다(일반적으로 엔터프라이즈 애플리케이션에서 각 프로세스에 대한 처리는 미들웨어가 자동으로 담당하므로 굳이 소프트웨어 아키텍처에 표현할 필요가 없다고 판다.) “4+1뷰”에 포함되지 않은 중요한 요소인 사용자 인터페이스 뷰와 데이터 뷰를 포함 시켰으며 기술아키텍처에 기술 유스케이스 뷰를 추가하였다.
모듈화 : 구현을 인터페이스 뒤에 감추는 캡슐화를 통해서 모듈화를 강화한다. 모듈화는 설계와 구현의 변경에 따르는 영향을 국소화함으로써 손쉽게 소프트웨어의 품질을 향상시킬 수 있게 한다.
재사용성 : 프레임워크가 제공하는 인터페이스는 여러 애플리케이션에서 반복적으로 사용할 수 있는 일반적인 컴포넌트를 정의할 수 있게 함으로써 재사용성을 높여준다.
프레임워크 컴포넌트를 재사용하는 것은 소프트웨어 품질, 성능, 신뢰성, 상호 운용성을 향상시킬 뿐만 아니라 프로그래머의 생산성을 상당히 높여준다.
확장성 : 프레임워크는 다형성을 통해 애플리케이션이 프레임워크의 인터페이스를 확장할 수 잇게 한다. 프레임워크 확장성은 새로운 애플리케이션 서비스와 특성을 커스터마이징 하는 것을 보장 하는데 있어서 필수적인 사항이며, 또한 프레임워크를 애플리케이션의 가변성으로부터 분리함으로써 재사용성의 이점을 얻게 한다.
제어의 역흐름 : (헐리우드 원리)”나를부르지마라, 내가 너를 부를것이다.”원리
이벤트가 발생할때 다형성을 통해 애플리케이션이 확장한 메소드를 호출함으로써 제어가 프레임워크로부터 애플리케이션으로 거꾸로 흐르게 한다.
이러한 제어의 역흐름을 통해서 프레임워크가 외부의 이벤트에 대해서 애플리케이션이 어떠한 메소드들이 수행해야 하는지 결정할 수 있게 한다.
아키텍처는 아키텍처적으로 중요한 사항을 결정하며, 이결정에 따라 설계 및 구현 작업에 제약사항을 부여하게 된다.
그리고 설계 및 구현 작업에서의 모든행위는 아키텍처의 제약사항을 준수해야 한다. 그러나 아키텍처적으로 중요하지 않은 사항에 대해서는 설계 및 구현 작업에서 자유롭게 결정될 수 있으며 아키텍처가 구현을 정의하지는 않는다.
처음으로 돌아가 위의 말은 결국 속성이 외부로 드러나는 소프트웨어 요소가 아키텍처적으로 중요한 것이라는 것이다. 결국 소프트웨어 요소가 외부로 드러나지 않아 다른 요소에게 인식될 수 없다면 그 요소는 아키텍처적으로 중요하지 않은 것이다. 아키텍처적으로 중요한 소프트웨어 요소를 아키텍처 요소라 하며 아키텍처적으로 중요하지 않은 소프트웨어 요소를 비 아키텍처 요소라 한다.