2) 소프트웨어 시스템 개발에서 특정 시스템에 대해 요구되는 기능, 품질을 확보하고 소프트웨어 시스템의 구축, 지속적
인 개선이 용이하도록 하는 역할
3) 개발하고자 하는 소프트웨어의 사전 작업을 통하여 소프트웨어 개발을 쉽게 하도록 기본 틀을 만드는 것으로, 복잡한
개발을 체계적으로 접근하기 위한 밑그림
4) 시스템의 대형화, 복잡화로 인해 소프트웨어 아키텍쳐 필요성이 높아졌으나 작은 프로젝트일 경우 오히려 비효율적
2. 소프트웨어 아키텍처의 역할
1) 요구사항 분석 활동에 의해 도출된 요구사항을 모두 충족시킬 수 있는 시스템이 만들어 질 수 있도록 하기 위한 설계
활동으로서 설계 및 구현을 위한 구조적/비구조적 틀을 제공
틀
1) 아키텍처 설계의 결과물로서 실행을 요구하는 결정 또는 모델을 의미 2) 구조적 틀은 시스템 개발을 위해 결정된 컴포넌트의 구조모델을 의미 3) 비구조적 틀은 구조모델 이외의 다른 아키텍처 설계의 결정들을 의미 품질 속성 : 비기능적인 요구사항 중 특별히 소프트웨어 아키텍처에 많은 영향을 미치는 요구사항
3. 소프트웨어 아키텍쳐 결정 요인
1) 기능(함수) 요구사항 : 입력, 출력
2) 비기능 요구사항 : 품질, 제약사항
3) 기능 요구사항은 입력과 출력이 명확해 모델링이 쉬우나 비기능은 어려움
4. 아키텍처 설계 절차
1) 요구사항 분석
1] 소프트웨어 개발의 요구 사항 분석 단계와 같으나 품질 속성과 같은 비기능적 요구 사항에 더 많은 관심
2] 요구사항 취득, 식별, 명세, 분류, 검증
3] 기능적/비기능적 요구 사항 분류 및 명세
2) 아키텍처 분석
1] 개발 프로젝트에 필요한 품질 속성을 식별하고 식별된 품질 속성의 우선순위 결정
2] 품질 속성 반영 방법을 개발
3) 아키텍처 설계
1] 관점 정의 : 이해 관계자를 파악하고 이해 관계자 별 관점을 정의(아키텍처 4+1 view)
2] 아키텍처 스타일 선택 : pipe=filter, mvc, layer 등 스타일을 혼용하여 적용 가능
3] 후보 아티텍처 도출 : 배경도 및 각 관점별 다이어그램을 작성하고 스프투에어 아키텍처 명세서(SAD)를 기술
4) 검증 및 승인
1] 아키텍처 평가 : 요구사항 만족도, 적합성을 평가하고 품질 속성(성능, 사용, 보안, 안전, 검증, 변경)간 절충관계평가
2] 아키텍처 상세화(반복) : 설계방법을 도출하고 설계패턴을 고려
3] 아키텍처 승인 : 이해 관계자들이 최종 승인
5. 아키텍처 설계의 입력과 출력
1) 시스템 개발은 모든 요구사항을 달성대상이지만 아키텍처 설계는 아키텍처에 관련된 대표적 요구사항이 주된 관심
대상이며, 이러한 특별한 요구사항들을 아키텍처 드라이버라 명명
2) 설계의 결과는 아키텍처를 문서화한 아키텍처 문서가 주된 출력물이 되고 이에 대한 추가적 관련사항을 정리한 아키
텍처 가이드 라인이 이차적 출력물
3) 태스크는 한명의 수행자가 수행하는 일을 지칭
4) 소프트웨어 설계 모델링 언어인 UML의 활동 다이어그램은 더 이상 분해하지 않는 일의 단위를 태스크라 부르고 다른
태스크 혹은 활동으로 구성된 일의 단위를 활동이라고 명명
6. 소프트 아키텍처 절차에 따른 적용원리
1) 정렬된 아키텍처 드라이버와 식별된 문제들 : 요구사항을 아키텍처 설계가 적용되기에 좋은 형태로 만들어가는 원리
2) 아키텍처 모델링 방법의 결정 : 아키텍처를 어떻게 표현할 것인가에 대한 원리
3) 아키텍처 설계 : 이 전의 두 단계에서 적용한 결과를 바탕으로 아키텍처 설계를 수행하는 원리
4) 아키텍처 평가
아키텍처 드라이버 1) 시스템 요구사항 중 아키텍처에 영향을 주는 요구사항 2) 아키텍처 설계에 더 집중할 수 있기 위해 아키텍처 드라이버를 먼저 잘 식별해낸 후 아키텍처 설계에 효과적으 로 반영
품질속성, 검증 가능성, 품질속성 시나리오 1) 아키텍처 드라이버들을 먼저 검증할 수 있는 형태로 바꾸어 놓은 것 2) 품질속성으로 불리는 요구사항들은 아키텍처에 영향을 미치면서 고객의 도움 없이는 개발자 단독으로 검증 가 능한 형태로 바꾸기 어려운 유형의 요구사항
문제분석 1) 요구사항들이 어떤 문제의 해결을 요청하는 것인지 분석
콤포넌트와 커넥터 1) 처리, 저장, 전달을 수행하는 소프트웨어 시스템의 구성 요소로, 커넥터는 컴포넌트를 연결하는 연결자
아키텍처 스타일 1) 아키텍처 스타일은 아키텍처의 유형을 의미하며 신뢰 있는 기관에서 검증된 보편적인 설계 방법 양식들 2) 적절한 아키텍처 스타일의 선택은 대상 시스템 개발을 효율적, 효과적으로 함
3) MVC구조 1] 모델 : 사용자 요청을 처리해 사용자에게 출력할 데이터를 만드는 요소 2] 뷰 : 모델이 처리한 결과를 화면에 보여주는 요소 3] 컨트롤러 : 사용자 요청을 받아 그 요청을 처리할 모델 호출하며, 모델이 처리 후 결과를 뷰에 전달 4] 구현하려는 전체 어플리케이션을 위 세 요소로 구분하여 유저인터페이스와 비즈니스 로직을 서로 분리, 애플 리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플 리케이션을 생성 가능 5] 즉, 구현하려는 전체 어플리케이션을 모델, 뷰, 컨트롤러로 구분하여 유저인터페이스와 비즈니스 로직을 서로 분리하여 개발하는 방법
4) Client/Server 구조 1] 네트워크를 이용하는 분산 시스템 형태 모델 2] 데이터와 처리 기능을 정보를 요청하는 클라이언트와 정보를 제공하는 서버에 분할하여 사용 3] 서버, 서비스, 클라이언트로 구성 4] 시스템 확장이 용이하고 유연성이 있어 많은 자원 공유 가능
5) 저장소 구조 (Repository, 데이터 중심형 모델) 1] 리포지토리에 공동으로 활용하는 데이터를 보관하고 모든 서브시스템이 여기에 저장된 공유 데이터에 접근 하여 정보를 검색, 저장, 변경하는 역할 2] 서브시스템은 리포지토리에 정보를 요청하여 가져와 연산한 후 그 결과를 다시 리포지토리에 저장 3] 대량의 데이터를 공유하는 은행 업무 시스템에 매우 유용 4] 데이터가 리포지토리 한 곳에 모여있기 때문에 데이터를 모순되지 않고 일관성 있게 관리 가능
6) 계층 구조 1] 계층 하나를 서브시스템으로 생각하여 하위 계층은 서버, 상위 계층은 클라이언트 역할을 하도록 구성 2] 계층 간의 역할 분담을 명확히 하여 각 계층을 필요에 따라 쉽게 변경 가능
7) 데이터 흐름 구조(파이프 필터 구조) 1] 필터에 해당하는 서브시스템이 데이터를 입력받아 처리 후 결과를 다음 서브시스템에 넘겨주는 과정을 반복 2] 일반적으로 데이터를 변환하는 시스템에서 주로 사용 3] 필터 또는 파이프 단위로 나누어 개벼할 수 있기에 동시 개발이 가능
소프트웨어 아키텍처를 보는 관점체계 1) 아키텍처 스타일에 따라 적합한 관첨체계가 다를 수 있음 2) J2EE 기반의 응용, BPMS 기반의 SOA응용, 내장소프트웨어 Web 응용 등 적절한 관첨체계가 동일하지 않음 3) 소포트웨어 아키텍처는 여러 관점이 존재하고 적절한 여러 개의 관점을 동원할 때 아키텍처를 더 잘 포착가능 4) J2EE : 분산 객체, 효율적 자원 관리, 컴포넌트 기반 개발 등을 자바 환겨에서 사용할 수 있도록 하는 표준 규약 은행 전산망처럼 큰 규모의 전산 환경을 엔터프라이즈급 환경이라 하며, 수많은 고객 정보를 공유하 고 어느 곳에서나 동일한 서비를 제공해야 하는데 J2EE는 이러한 개방적 웹 환경을 지원 5) BPMS : 기업의 업무, 조직구조, 추진 방식에 숨어 잇는 프로세스를 명확히 정의하고 자동화, 최적화하여 업무 와 인간과 시스템간의 관계를 통합 관리하는 시스템
설계의 일반원리 1) 소프트웨어 아키텍처에 적용되는 보편적인 원칙 2) 적용할 수 있는 많은 원리 중 문제의 해결에 단서가 되는 보편적 원칙
아키텍처 설계 절차 1) 아키텍처를 구성하는 요구사항들로부터 먼저 어떤 아키텍처 설계의 선택이 있는가 판단 2) 여러가지 설계의 장단점을 따져 좋은 선택
아키텍처 패턴 1) 반복적으로 발생하는 문제애 대해 미리 만들어진 솔루션 2) 특정한 문제를 해결하는 처방 3) 설계자들은 설계의 해법을 패턴에서 먼저 찾고, 해답이 없는 경우 품질속성 설게전술을 사용 4) 문제에 대한 일반적인 솔루션을 제공
품질속성 설계전술 1) 단일 품질속성 으답을 제어하는데 영향력 있는 설계의 결정 2) 아키텍처 패턴에서 해결하지 못할 경우 사용
아키텍처의 분석 1) 주어진 아키텍처가 적절한지 판단하기 위한 분석
아키텍처의 평가 1) 완결된 설계를 대안과 비교함으로써 그 결과에 따라 설계라는 과정을 다시 수행할 것을 요구할 수도 있음
7. 소프트웨어 아키텍처 프레임워크(소프트웨어 개발 환경)
1) IEEE1471는 소프트웨어 구조에 대한 기술을 규정한 IEEE 표준, IEEE42010로 통합
2) IEEE42010은 시스템 및 SW엔지니어링 아키텍처 기술과 관련된 용어와 개념을 정의한 국제표준
8. SW 아키텍처 4+1 View의 개요
1) 스스템의 여러 가지 측면을 고려하기 위한 다양한 관점을 바탕으로 정의되며, UML의 4+1 View가 표준
2) 고객 요구사항을 중심으로 4가지 관점으로 소프트웨어 아키텍처를 설계하는 기법
3) 분석가, 설계자의 논리 뷰 : 논리관점
1] 상위 수준에서 시스템의 논리적인 구조, 행위를 클래스, 인터페이스, 협력관게로 정의
2] 시스템의 기능에 관심이 있는 유스케이스 관점과 달리 시스템 내부를 확인
3] 시스템의 기능을 제공하기 위해 필요한 클래스, 컴포넌의 종류, 이들의 관계에 ㅗ점
4] 필요한 클래스와 컴포넌트를 파악하고 기술
4) 프로그래머의 구현 뷰 - 구현관점
1] 독립적으로 실행되는 컴포넌트와 이들 간 관계를 정의
2] 물리적 시스템에서 사용하는 소프트웨어 서브시스템의 모듈(원시 코드, 데이터 파일, 컴포넌트, 실행 파일 등으로 구
성)이 어떻게 구조화 되어 있는가에 관심
5) 시스템 통합자의 프로세스 뷰 : 프로세스 관점
1] 시스템의 병럴처리 및 동기화 처리를 위한 스레드와 프로세스를 정의
2] 시스템 통합자를 위한 것으로, 실제 구동 환경을 살펴봄으로써 논리적 관점과 같이 시스템 내부의 구조(클래스간의
관계, 클래스의 행동, 클래스 사이의 상호작용)에 초점
3] 모든 클래스가 아닌 독자적인 제어 스레드를 가질 수 있는 클레스에 초점
4] 시스템의 동시성과 동기화에 관심
프로세스 : 주기억장치에 저장된 프로그램(실행 중)으로, 운영체제가 관리하는 최소 단위의 작업
스레드 : 프로세스를 분할하여 운영체제의 성능을 개선하려는 방법으로, 하나의 프로세스 내에서 병행성을 즈대 시키는 기법 동일 프로세스 환경에서 서로 독립적인 다중 수행이 가능
6) 시스템 엔지니어의 배치 뷰 : 배치 관점
1] 실행되는 시스템 하드웨어와 소프트웨어 관계를 정의
2] 시스템을 구성하는 처리 장치 간의 물리적인 배치에 초점을 둠
3] 시스템의 분산 구조와 실행할 때 컴포넌트들의 배치 상태를 나타냄
7) 사용자의 유스케이스 뷰 = 사용자 사례 관점
1] 시스템의 외부 사용자 관점에서 사용 사례들 간의 관계를 정의
2] 시스템이 사용자에게 제공하는 기능에 관심
3] 다른 네 가지 관점에 사용되는 다이어그램의 근간이 되어 분석 및 설계 전 과정에 사용
