sw아키텍처 Flashcards
sw 아키텍처
[리드] 시스템에 대한 기본 조직 체계
[정의] 시스템을 이루는 구성요소들 간의 상호 관계의 구조와 이들을 설계하고 전개하기 위한 지침과 원리
[역할] 1) 청사진 2) 설계계획 및 지침 3) 의사소통도구 - 간략화/추상화/가시성/관점모형
[구성 3요소] (원관컴)
1. 원리 : 소프트웨어 디자인/아키텍쳐 패턴/개발구성요소 이끄는 기본이론
2. 관계 : 컴포넌트간의 관계, 이해관계자 뷰에 따라 관계설정
3. 컴포넌트 : 시스템의 기본조직, 소프트웨어 개발구성요소
[절차] (요참모프배)
1. 요구사항분석 : 이해관계자, 요구, 품질속성, 리스크 식별
2. 참조 아키텍처 분석 : 업계 모델, 표준 모델 분석 → 자체 참조 아키텍처 준비
3. 아키텍쳐 모델링 : 뷰 정의, 패턴/스타일, 프레임워크, 설계이슈 선정 및 평가
4. 아키텍처 프로토타이핑 : 유스케이스, 컴포넌트 단위 설계, 프로토타입 검토/작성
5. 아키텍처 배포 : 프로토타입 모델 구조화, SAD 작성, 검토
SW 아키텍처 스타일
[정의] 시스템을 구성하는 컴포넌트 및 컴포넌트간 제어/데이터 송수신 방법에 대한 패턴
유형
1. 연결형
- CS (Clinet-Server) : 클라이언트 서비스요구-서버 제공, 사내 ERP 시스템
- Peer to Peer : 파일공유 N/W, 멀티미디어 프로토콜
2. 중개형
- Broker : 컴포넌트가 통신 조절, Kafka, RabbitMQ
- Event-bus Pattern : 특정 채널로 메시지 전송, 알람 서비스
- Publish and Subscribe: Sub(topic) > Pub(Topic, Data) 구조, 메시징 시스템
3. 데이터 중심형
- Blackboard : 음성인식, 차량 식별 및 추적
- Repository : 서브 시스템의 중앙자료 접근/공유, CMDB/Database
4. 기능 분활형
- MVC : Model/View/Controller(역할분리 따른 변경 효율, Dataset/JSP화면/Biz Logic)
- MSA : Git, Amazon, Neflix
5. 콜 엔 리턴형
- Layered Architecutre : 서비스 프리미티브, OSI 7 Layer
- MS (Master-Slave) : 컴퓨터 시스템 버스 주변 장치, DB 쿼리 오프로딩, Replication
6. 데이터 흐름형
- Pipes and Filters : 컴파일러, 의미/어휘 분석
- Batch Process
MVC
[정의] 웹 APP의 확장성,유지보수성을 위해 모델,뷰,컨트롤러로 분리 구성한 SW 아키텍처 패턴
[구성요소]
1. Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분입니다.
2. View : 사용자에서 보여지는 UI 부분입니다.
3. Controller : 사용자의 입력(Action)을 받고 처리하는 부분입니다.
[장점] - 단순하다 보니 보편적으로 많이 사용
[단점]
- MVC 패턴의 단점은 View와 Model 사이의 의존성이 높다는 것입니다.
- View와 Model의 높은 의존성은 어플리케이션이 커질 수록 복잡하지고 유지보수가 어렵게 만들 수 있습니다
MVP
[정의] MVC모델에서 뷰, 모델의 의존성을 없애기위해 Presenter를 추가한 SW 아키텍처 패턴
[구성요소]
1. Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분
2. View : 사용자에서 보여지는 UI 부분
3. Presenter : View에서 요청한 정보로 Model을 가공하여 View에 전달해 주는 부분, View와 Model을 붙여주는 접착제(?) 역할
[특징]
- Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 접착제 역할
- Presenter와 View는 1:1 관계
[장점] View와 Model의 의존성 제거, MVC 모델 단점 해결
[단점] View와 Presenter 사이의 높은 의존성
MVVM
[정의] 뷰, 모델의 의존성을 없애고 Data Binding을 통해 확장성과 개발 편의성을 높인 SW 아키텍처 패턴
[특징]
- Command 패턴, Data Binding 패턴 사용 : View와 View Model 사이의 의존성 제거
- View Model과 View는 1:n 관계
[구성요소]
1. Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분
2. View : 사용자에서 보여지는 UI 부분
3. View Model : View를 표현하기 위한 Model
[장점] View와 Model의 독립적 개발 가능( 의존성 제거)
[단점] View Model의 설계 어려움
4+1 View
[정의] 고객의 요구사항을 정리해 놓은 시나리오를 4개의 관점에서 바라보는 Software적인 접근 방법
[필요성] Box 나 화살표 diagram 과 같은 단순한 View Model의 한계 극복
[구성요소] (U설프구배)
1. Use Case View : 요구 사항을 분석해 시스템의 기능을 명세화 (Use Case, Sequence 다이어그램)
2. 설계 (Loical View) : Use Case View에 표현된 요구사항들을 시스템의 구조와 행동으로 명세화 (Class, Object 다이어그램)
3. 프로세스 (Process View) : Thread와 Process에 의한 동작을 중점적으로 표현 (동시성, 분산처리)
4. 구현 (Implementation View) : 물리적인 소프트웨어 모듈로 표현 (Component, Interface 다이어그램)
5. 배치 (Deployment View) : UML 모델 요소를 배치할 하드웨어 표헌 (Deployment 다이어그램)
* 유스케이스는 4개 뷰에 영향을 미치고 4개뷰는 시나리오를 중복해 다룸
IEEE 1471
[정의] SW 집약적인 시스템에서 아키텍쳐가 표현해야하는 내용 및 상호관계를 제공하는 아키텍쳐 표준 메타 모델
[필요성] 표준화, 중립성, 유연성, 의사소통
[특징] 1.SW아키텍처를 정의하기 위한 SW 구성요소 및 구성요소간의 관계를 확립하여 SW아키텍처기술서(SAD)명세를 위한 표준 프레임워크 2.ISO/IEC/IEEE 42010 가 최종 표준화
[구성요소]
1. Mission : 시스템이 수행해야 되는 목표
2. Environment : 시스템 구성하는 외부요인, 영향력요소
3. System : 시스템집합구현체
4. Architecture : 요구사항별 아키텍쳐
5. Stakeholder : 시스템에 대한 이해당사자
6. Architecture Description : 아키텍처 기록을 위한 산출물 / 관심사, 하나 이상의 View로 구성
7. Rationale : 선택되어 설계된 아키텍쳐 논리적근거
8. Concern : 동일 시스템에 대한 각 이해관계자들의 서로 다른 의견과 목표
9. View Point : View를 구성하기 위한 규칙을 정의하는 패턴, 관점
10. View : 이해관계자의 관점에 의한 시스템 뷰(뷰포인트에 따라 실제표현되는시스템)
11. Model : View 도출하기 위한 표준화된 모델
SAD
[정의] 이해관계자들의 관심사 파악 및 관점들을 정의하고, 다양한 뷰를 통해 SW아키텍쳐를 기술한 문서
[구성]
- 개요/배경/요구사항/참조아키텍처/설계전략(Tactics)/시스템View/용어사전, 참고문서
[5원칙] (핵표준내리) 1.핵심집중(보는사람관점) 2.표현방법(모호제거) 3.표준준수(템플릿) 4.내용충실(근거첨부) 5.리뷰 활동(지속검토)
[작성절차] (아이관설뷰)
1.아키텍쳐 기술서 정보 작성 : 규정/일정/조직/변경이력/참고
2.이해관계자와 관심 식별 : 이해당사자역할/관심사/품질속성/목표/경제성
3.관점 선택 : 후보관점식별/정제/통합/표현을위한뷰구성
4.관점에 대한 설명 작성
5.뷰 작성 : 뷰포인트별 뷰선정/명세/불일치조정기록
6.전체 뷰 작성
소프트웨어 아키텍처 드라이버
[정의] SW 아키텍처를 만드는데 기능적, 품질적, 성능적 영향을 주는 요구사항
[유형]
- 기능 요구사항 : 시스템에서 반드시 구현되어야 하는 부분
- 품질속성 : 가용성,변경용이성,성능, 보안성
- 제약사항 : 비즈니스,조직,기술 제약사항
SW 아키텍처 평가
[정의] 제시된 SW 아키텍처가 개발될 SW에 대해 요구되는 품질 특성을 충족시킬 수 있는가를 아키텍처 수준에서 평가하는 작업
[필요성] 요구검증, 조기문제발견
[평가유형]
1. 시나리오 기반 : SAAM, ATAM, CBAM, ADR, ARID
2. 시뮬레이션 기반 : BMT, 프로토타이핑 → 가장 많이 사용됨
3. 수학적 모델 기반 : 모델 수치(정량)화, 평가
4. 경험기반 : 정량분석 난해 시, 전문가 경험
[평가방법]
1. 가시적 평가 : 인스펙션, 리뷰, Validation/Verification
2. 비가시적 평가 : SAAM, ATAM, CBAM, ARID, ADR
* 일반적으로 정방향 분석인 CBAM, ATAM 모델이 많이 사용
SW 아키텍처 평가 방법
[평가방법] (사아탐 C 아드리 아리다)
- SAAM : 변경 용이성, 기능 분석 중심의 최초 아키텍처 평가 방법 / 평가 용이
- ATAM : 아키텍처가 품질 속성을 만족 시키는지 판단 품질 속성간 상호 작용
- CBAM : 아키텍처가 평가의 ROI, 재무재표 등 경제성 측면 평가 방법 (ATAM + CBAM)
- EATAM : 개별 평가모델의 확장, 스테이지 기반 모델을 통한 PL아키텍처 평가 수행
- ADR : 아키텍처 구성 요소간 응집도 평가
- ARID : 부분 아키텍처를 아키텍처 초기에 평가 방법, 특정 부분의 품질요소 집중 (SAAM/ATAM + ADR)
ATAM
[정의] 품질 목표 간의 트레이드 오프(Trade-Off) 및 민감도 분석, 시나리오 기반 아키텍처 평가 기법
[특징] Trade-Off & 민감도 분석, 모든 Quaillity Attributes 평가(SAAM은 일부만 평가)
[절차]
1. 소개 : ATAM소개 → 비즈니스 동인소개 → 아키텍처 소개
2. 조사/분석 : 아키텍처 접근법 식별 → 품질속성 유틸리티 트리 작성 → 아키텍처 접근법분석
3. 테스트 : 브레인스토밍과 시나리오 우선순위결정 → 아키텍처 접근법 분석 반복
4. 보고 : 결과발표
[차별화]
- SAAM : ATAM 기초 모델. 수정 가능성과 기능 분석 중심, 최초의 아키텍처 평가 방법
- ARID : ATAM + ADR(상세설계 응집도-모듈/컴포넌트 검토) , 초기 평가 기법
CBAM
[리드] 비용와 이득을 고려한 아키텍처 평가 방법
[정의] ATAM 기반 경제적 평가 보강, ROI 계산 및 순위결정 통한 효용성(Utility) 기반 아키텍처 평가 기법
[특징] 품질 속성 경제성 중심, 비용과 이익으로 부터 ROI 계산
* 품질속성이 가져다 주는 이익을 측정, ROI를 계산 “효용(utility)”으로 표현
[개념도]
- 비즈니스 목표 → 아키텍처 결정(비용) → 품질 특성 (성능,보안,사용성..) → 이익,ROI실현 – CBAM 목표
[프로세스]
1. 시나리오 결정 : 시나리오 수립, 시나리오 정제, 시나리오 우선순위
2. 효용-반응값 곡선 작성 : 효용-반응 값 곡선 작성
3. 아키텍쳐 접근법 전체 이익계산 : 예상 반응값 결정, 예상 효율 계산, 전체 이익 계산
4. 아키텍쳐 접근법 선정과 검증 : ROI 계산, 순위 결정, 아키텍처 접근법 선정, 결과 검증
유틸리티 트리
[정의] 비기능적 품질 속성간 중요도, 영향도 파악 목적 트리구조, ATAM 기반 SW 아키텍처 평가방법
[목적] 품질속성 결정, 시나리오 도출, 아키텍처 평가
[특징]
- ATAM 프로세스 중 조사와 분석 단계에서 작성
- 시스템이 획득해야할 품질 속성 도출 및 정의 (SW 설계시점)
[절차]
1. 유틸리티 작성-유틸리티 : 시스템이 제공해야 할 모든 품질 의미
- (사례) 트리에서 최상위를 Utility라고 표기
2. 품질속성 추출 : 시스템이 제공해야할 비기능적 품질 속성 추출
- (사례) 성능. 가용성, 보안, 유지보수성 등
3. 세분화한 품질속성 결정 : 품질 속성을 세부적으로 구분
- (사례) 성능(지연 시간, 대역폭, 처리 속도), 가용성(디스크 실패, 사용), 보안(데이터 암호화, 무결성 보장)
4. 시나리오 검증 : 품질 속성 기반, 가상의 시나리오를 수립하고 검증
- (사례) 성능(200ms 내에 DB 저장 완료), 가용성(디스크 실패 후 5분 이내 재시작), 보안(99.99%시간 트랜잭션 신뢰성 보장)
SW 품질속성
[정의] 제품 품질기준을 만족시키기 위해 소프트웨어가 가져야 하는 성능, 보안 등 시스템 비기능 속성
[유형] (시아비)
1. 시스템 : 성능, 보안, 가용성, 유지보수성, 재사용성
2. 비즈니스 : 시장 적시성, Cost, 목표시장, 시스템의 프로젝트 생명주기
3. 아키텍처 : 정확성, 구축성, 완전성, 개발 용이성
