소프트웨어공학, 소프트웨어 아키텍처 이론과 실제 마인드맵

소프트웨어 아키텍쳐

1. 정의

가. 아키텍처

1) SW구성요소와 그들이 지니고 있는 외부에 들어나는 특성과 구성요소간의 관계를 표현하는 시스템의 구조나 구조체

가) SW요소를 정의

나) 하나이상의 구조로 구성

다) 모든 SW는 아키텍처 존재

라) 시스템 행위를 아키텍처로 표현가능

2) 필요성

가) 이해관계자 의사소통수단

나) 초기 중요결정사항

(1) 개발제약사항 정의

(2) 개발구조 결정

(3) 품질속성 장려, 억제

(4) 일정 비용 예측

다) 재사용 가능한 시스템 추상화

(1) 특정시장의 시스템특징 공유(Product Line)

(2) 특정요소 외주 개발(교환용이성)

(3) 템플릿 기반 개발

라) 시스템 진화 방향 제시

나. 뷰

1) 이해관계자에 의해 읽히고 쓰이는 아키텍처 요소의 일관된 집합

다. 구조

1) 소프트웨어나 하드웨어에 존재하는 아키텍처 요소 그자체

라. 패턴

1) 특정문제에 대한 반복해서 나타나는 해결책

2) 장점

가) 설계생산성 향상

나) 문제와 해결채을 문서 ->문제영역의 어휘와 언어 정리

마. 스타일

1) 아키텍처 설계에서 반복해서 나타나는 문제들을 해결 하는 방법

바. 프레임워크

1) SW의 특정한 클래스에 대하여 재사용할수 있는 설계로 구성된 관련한 클래스들의 집합

2) 사용목적

가) 모듈화

(1) 구현을 I/F 뒤에 감추는 캡슐화

(2) 설계와 구현의 변경에 따르는 영향을 최소화

나) 재사용성

다) 확장성

(1) 다형성

라) 제어의역흐름

(1) 헐리우드의 원리

(가) 나를 부르지마라,

(나) 내가 너를 부를 것이다.

3) 종류

가) Spring

나) Struts

다) Ruby

사. 종류

1) 기술아키텍처 (지식)

가) 해결가능 솔루션 적용

2) 응용아키텍처 (선택)

가) 비즈니스 적합 선택

3) 비즈니스아키텍처 (분석)

2. 구조

가. 뷰타입

1) 모듈 (구현단위)

가) 분할스타일

(1) is part of

나) 사용스타일 use

(1) depend on

다) 일반화스타일 class

(1) is a

라) 계층스타일 layer

2) 컴포넌트&커넥터 (구조화)

가) 컴포넌트

(1) Client

(2) Server

(3) Filter

(4) Object

나) 커넥터

(1) Procedure Call

(2) Publishing Subscribe

다) 스타일

(1) 파이프 필터 스타일

(2) 공유 데이터 스타일

(3) 출판/구독 스타일

(4) 클라이언트/서버 스타일

(5) 피어투피어 스타일

(6) 커뮤니테이션 프로세스 스타일

3) 할당 (맵핑)

가) 배포스타일

나) 구현스타일

다) 작업할당스타일

나. 스타일

1) 아키텍처 스타일 + 디자인 패턴

2) Pattern Oriented SW Architecture(POSA)

3) 종류

가) 데이터중심 스타일

나) 데이터흐름 스타일

다) 가상머신 스타일

라) 호출/리턴 스타일

마) 독립적 컴포넌트 스타일

바) 이질적 컴포넌트 스타일

다. 뷰

3. 개발단계

가. 요구사항 분석

1) 유스케이스 모형정제

2) UI 설계

3) 객체모형 작성

나. 아키텍처 정의

1) SW 아키텍처 정의

2) 설계전략 정의

3) 비즈니스 컴포넌트 설계

4) 시스템 아키텍처 정의

5) 컴포넌트 획득

6) 데이터 모형 작성

다. 아키텍처 프로토타이핑

1) 아키텍처 프로타타입 계획

2) 아키텍처 프로토타입 개발

3) 아키텍처 프로토타입 평가

라. 테스트및 전환

1) 테스트 계획

2) 전환 계획

4. 품질속성 SAiP

가. 시스템

1) 가용성 Availability

2) 변경가능성 Modifiability

3) 시험용이성 Testability

나. 비즈니스

1) 적시성 Time to Market

2) 비용/예산 Cost/Buget

3) 목표시장 Target Market

4) 첫공개일정 Rollout Schedual

5) 기존시스템통합 Legacy Integration

다. 아키텍처

1) 개념적무결성 Conceptual Integrity

2) 정확성/완전성 Correctness / Completeness

3) 구축가능성 Buildability

5. 아키텍처 평가

가. 기법

1) ATAM Architecture Tradeoff Analysis Method

가) 민감점(Sensitivity Points)

나) 절충점(Trade off Points)

다) 위험/무위험risk/nonrisk)

라) 아키텍처 접근법 분석서

2) CBAM Cost Benefit Analysis Method

가) 목적

(1) 비용(Cost) 최소화

(2) 이익(Benefit) 최대화

(3) 불확실성(Uncertainty) 최소화

나) 단계

(1) 시나리오결정

(2) 효용-반응값곡선 작성

(3) 아키텍처접근법 전체이익계산

(4) 아키텍처접근법 선정과검증

3) SAAM Software Architecture Analysis Method

가) 최초 정의된 아키텍처 평가방법

나) 간단하고 다양한 영역 적용가능

다) 시나리오

(1) 직접시나리오

(2) 간접 시나리오

4) ARID Active Reviews for Intermediate Designs

가) 부분아키텍처를 아키텍처 설계초기에 평가하는 방법

나) ATAM,SAAM + ADR 혼합

나. 방식

1) 이른평가(Early)

2) 늦은평가(Late)

다. 결과

1) 적합성판단 Suitability

2) 달성목표

3) 우선순위

라. 베이스라인

6. 문서화 SAD

가. 표준

1) IEEE 1471-2000

2) 아키텍처 관련 용어,개념 통일

3) 기술중립적

나. 작성공정

1) 아키텍처 정보작성

2) 이해관계자 관심식별

가) 사용자

(1) 필수 이해관계자

나) 인수자

다) 개발자

라) 유지보수자

3) 관점 선택

가) 뷰를 작성하는 규칙과 방법 정의 => 뷰의 메타모델

4) 관점 설명 작성

가) 관점이름

나) 관점관련 이해관계자목록.관심

다) 뷰작성 방법

5) 뷰 작성

6) 전체 뷰 작성

가) 시스템 개괄

나) 뷰사이 관계

다) 구성요소 사전

라) 용어사전

다. 형식

1) 1.Revision history정보

2) 2.Introductino

가) purpose

나) scope

다) 목적

라) 범위

3) 3.Architecture Representation

4) 4.Architecture Goal & Constraints

5) 5.4+1 View

가) Use case

나) Logical(논리적)

다) Process(프로세스)

라) Developmentation(개발)

마) Implementation(물리적)

6) 6.Size & Performance

7) 7.Quality

라. 아키텍처 프레임워크

1) 정의

가) 아키텍처 기술서를 구성하는 뷰가 따라야 하는 관점들과  이 관점들 사이의 관계를 정의

2) 4+1 View

가) 시나리오 Use case

나) 논리 Design

다) 물리 Deployment

라) 개발 Implementation

마) 프로세스 Process

3) RM-ODP Reference Model for Open Distributed Processing

가) 엔터프라이즈관점

나) 정보관점

다) 계산관점

라) 공학관점

마) 기술관점

http://digilogmap.tistory.com

정보관리기술사 준비를 위한 마인드맵

소프트웨어 공학 > 소프트웨어 아키텍처

정보관리기술사 신재용