[Software Architecture] 아키텍처 설계

품질속성 이해

• SW아키텍처가 만족시키고자 하는 품질 요구사항
  • 시스템 품질속성
  • 비즈니스 품질속성
    • 시장적시성 (Time to Market)
      - 빠르게 개발하는 것
    • 비용과 이익 (Cost and benefit)
    • 시스템의 프로젝트 생명주기 
      - 정책적으로 SW를 어떻게 할 것인지
      - 요금정책 (기능추가, Update 추가할때마다 사용료 받을지)
    • 목표시장 (Targeted market)
    • 신규발매일정
    • 노후 시스템과의 통합
  • 아키텍처 품질속성
• 실무에서의 핵심
  • 비지니스 적인 속성을 얼마나 만족시켜 주느냐?
  • 비기능적 품질속성, 비기능적 요구사항으로 도출됨 -> 여기에 집중 해야 함
• 개발업무에서 중요한 부분
  • 시스템 품질 속성
• QA 시나리오 (품질속성 시나리오)
  • 요구사항을 명세 (개발자가 이해하기 쉽게 쓰는 것 -> 의사소통 도구로)
  • 시나리오 형태로 만드는 것
  • 6개 항목으로 정의
    • 자극원
    • 자극
    • 자극대상
    • 환경
    • 반응
    • 반응 측정
      • 최대한 수치적으로 나타날 수 있는 것으로 잡아라 (정량적)
      • 그게 안되면 비기능적으로 표현(정성적) 하되 
      • 도출된 측정값이 품질속성을 만족시키는지를 확인해야 함
        • ex) 가용성 / 응답시간 -> 응답시간이 이런 시나리오에서 만족하면 가용성을 가지고 동작한다고 볼 수 있다
        • ex) 정합성 / 정합성을 측정하는 Sum check or 2개 데이터의 비교 등의 알고리즘/기법
               -> 100% 동일합니다.
      • 테스트 시나리오에 그대로 들어감
  • 한글로 표현하는 방법
    • 3개 문장으로 시나리오 표현
      • 1문장으로 환경을 표현 - 주로 자그원을 수식 (시점, 조건, 상태 등)
      • 자극원 (주어) + 자극 (동사) + 대상체 (목적어)
      • 응답 (주어+동사+목적어) + 응답 측정 (주로 동사를 수식, 정략적 수치)
    • 작성예)
      • 환경 - 시스템 정상동작 / 이메일 발송 화면
      • 자극원 - 이메일 자성 화면
      • 대상체 - 이메일 전송모듈
      • 자극 - 작성된 내용 발송 요청 응답
      • 응답 - 이메일 발송
      • 응답측정 - 정해진 동작에 따라 100% 발송
      • 시나리오
        • 시스템이 정상 동작하는 상태에서 사용자가 이메일을 발송하려고 한다
        • 사용자는 이메일 작성 화면을 통하여 이메일 전송모둘에 작성된 내용을 발송하라고 요청한다
        • 이메일 전송 모듈은 담당모듈에 처리를 명령하고 사용자가 발송 요청한 이메일은 정해진 발송 동작에 따라 100% 발송이 완료된다
  • 속성당 3개 정도의 시나리오를 작성해야 함

 

 

디자인 패턴

• 시스템에서 검증된 해결방법이 어떻게 작동하는지를 기술한다
• 정의
  • 이미 해결해 본 문제의 햅버 중 당면한 문제와 가장 유사한 문제를 찾아 당시의 해결방법의 핵심을 재사용하여 문제해결에 응용
  • '유사한 문제'라는 구체적이고 세세한 사항은 다를 수 있지만, 그 해결책이 가지는 핵심적인 방법은 같은 것
  • 특정 문제에 대한 해법을 재사용할 수 있도록 해놓은 것
  • 디자인패턴과 디자인스타일은 크게 다르지 않다
    • 적용하는 레벨은 다를 수 있지만, 그 안에 해법에 대한 관점은 같다. 다만 그 디테일/상위 레벨로 하느냐가 다른 것이다.
    • 해법에 집중해서 내가 해결하고자 하는 문제/레벨에 잘 적용시킬 방법을 
  • 즉, 패턴이란 시스템 디자인 시에 자주 발생하는 문제들에 대한 "재사용하는 해결책" 이다
• 특징
  • 효과가 입증된 설계 경험을 정리한 것
  • 추상 레벨에서 발견되고 정의 (컴포넌트, 단일 클래스, 객체보다 높은 단계)
  • 설계 원칙에 대한 공통 어휘와 공감대를 형성시켜줌
  • 문서로 정리하는 방법을 제공함
  • 고유한 특성을 제공
  • 아키텍처 구축하는데 도움을 줌
  • SW 복잡성을 관리하는데 유용
• 패턴과의 관계
  • 패턴의 솔루션에 집중해야 한다
  • 패턴 내 컴포넌트와 다른 컴포넌트들의 관계는 항상 최소의 다위가 아니다
    • 특정패턴은 그보다 더 작은 패턴에 의해 서술될 수 있고, 그것들을 포함하고 있는 더 큰 패턴에 의해 통합될 수도 있다
    • 예) MVC 패턴은 모델이나 뷰등의 작은 패턴으로 설명될 수 있음
  • 개선(refinement), 조합(combination), 변형(variant)의 세가지 종류의 관계를 응용하여 패턴을 효과적으로 사용
    
    

설계 전술 (Tactic)

• 품질속성의 응답을 제어하는데 영향을 주는 설계 결정 사항이고 이러한 설계 전술을 일정한 방식으로 묶은 것을 패턴이라 할 수 있다
• 아키텍트의 선택 사항 
• 구조와 운용법
• 특징
  • 다른 설계전술들로 세분화 될 수 있음
  • 패턴은 여러가지 설계 전술을 포함
• 가용성 설계전술 (운용법 / 구현방법)
  • 결함 탐지 - 인지하기 위한 설계전술
    • Ping/echo, Hearbeat (생명주기신호), Exceptions (예외발생 = 문제가 생기면 알리는 것)
  • 결함 복구 - 결함에 대비하고, 결함 발생시 시스템을 수리하기 위한 설계전술
    • Voting
    • Avtive Reundancy, Passive Redundancy (비활성중복), Dual Redundancy, Triple Redundancy
    • Hot Restart, Warm Restart
    • Spare
    • 그림자 동작 (Shadow operation), 상태 재동기화(State Resynchronization)
    • Checkpoint/Rollback  
  • 결함 방지 (Fault Prevention)
    • 서비스로부터 제거
    • Transaction (하나의 트랜잭션으로 묶어서 처리)
    • Process 감시
• 변경용이성 설계전략
  • 변경사항의 지역화
  • 파급효과의(연쇄작용) 방지 (Prevent ripple effects)
  • 바인딩 시점의 연기 (Defer binding time)
• 성능 설계전술

 

 

아키텍처 구조표현과 뷰

• 설계방법론 = View point을 어떻게 가져갈 것이냐, 어떤 관점에서 SW를 표현할 것인가
• SW는 눈에 보이지 않기 때문에 View point 관점에서 표현할 수 있는 정보가 제한됨
• 전사적인 관점에서 접근함
• Siemens Four View
  • Conceptual View (개념으로 설명) = 상위레벨 설계
  • Module View = 컴퍼넌트보다는 하위단의 개념
  • Code View = Detail function Level
  • Execution View = 실제 실행단에서의 움직임
• 4+1 View (Rational Unified Process 방법론)
  • Logical View
  • Process View
  • Deployment View
  • Implementation View
  • UseCase View * = 가장중요 / 사용자 측면에서 시스템을 표현하겠다 
  • UML = 국제표준 표기법
    • 국제 공용/기준 도구이지 방법론이 아니다
• Architectural Structure (Paul Clements 03, SEI )
  • 모듈뷰 (Module View)
    • 모듈은 시스템의 주요한 구현 단위이며 각 모듈은 기능적 책임을 갖는다
    • 분할(Decomposition), 사용(Uses), 클래스(Class) 또는 일반화(Generalization), 계측 (Layered)
    • "정적인 구조의 덩어리"의 흐름에 대해 표현하는 View
      -> 정적인 구조 정보 표현
    • Class Diagram
  • 컴포넌트 & 커넨터뷰 (Component and Connector View)
    • 런타임 컴포넌트와 커넥터로 시스템의 실행단위를 기술
    • Pipe-and-Filter, 공유데이터, Client-Server, Peer-to-Peer
    • 연결관계에 촛점을 맞춰서 어떤일이 벌어지는지(흐름에 대해) 에 대해 표현을 하는 View
      -> 동적인 정보 표현
    • Sequence Diagram
    • Input / Output port가 존재
  • 할당 뷰 (Allocation View)
    • 시스템의 SW 구성요소와 SW가 생성되고 실행되는 외부 환경사이의 관계를 기술
    • 배치(Deployment = HW/SW 연관성)
      구현(Implementation = 폴더 구조)
      작업할당(Work Assignment)
    • SW Package 구조, Folder 구조, HW/SW 할당 뷰
    • HW의 Spec 및 제약사항이 있다면 특히 유념해야 함
  • 결합 (Combined View)
    • 혼성(Hybrid), 중첩(Overlay)

 

설계 사이클

• 아키텍처에 영향을 미치는 요소
  • 기술적 환경
  • 배경과 경험
  • 개발조직 = 개발조직의 문화, 개발비용, 개발조직의 역량, 개발조직
  • 이해관계자
  • 품질 요구사항
• 아키텍처 설계 생명주기 (설계절차와 상호 연관성)
  • 요구사항 분석 
    • 시스템 환경의 이해
      • 1.1 요구사항 검토
    • 요구사항의 분석
      • 1.2 중요 속성 식별
      • 1.3 시나리오 작성 (QAW)
  • 설계 뷰 작성
    • 설계 뷰 작성
      • 2.1 아키텍처 설계
      • 2.2 아키텍처 실체화 (Diagram화)
    • 아키텍처 문서화와 의사소통
      • 2.3 아키텍처 정제 및 명세화
  • 설계 검증
    • 아키텍처 설계 검증
      • 3.1 아키텍처 이해
      • 3.2 아키텍처 분석
      • 3.3 아키텍처 검증
  • 아키텍처 기반 시스템 개발
  • 아키텍처 준수 여부 확인
• 설계 사이클 구성의 배경
  • SW 품질속성을 기반으로 아키텍처 구성
  • 비기능 요구사항을 줌심
  • 과정 - 단계 - 활동

 

SW아키텍처 분석과정

• 요구사항 분석절차
  • 담당졀 역할 요약
    • 프로젝트 결정권자 -> 참석이 필수여야 한다 (없으면 추후 승인이라도 받을 수 있어야함)
    • 요구사항 분석팀
    • 이해관계자
• 요구사항 검토
  • 비지니스 목표 이해
    • 비지니스 환경 소개 자료
    • 비지니스 목표 정리 목록
  • 시스템 환경의 이해
    • 시스템 환경 소개 자료
    • 시스템 환경 정리 목록
• 중요 속성 식별
  • 기능 요구사항 도출 + 비기능 요구사항을 주로 도출하는 단계
  • 중요 기능 요구사항 식별
    • 우선순위화된 중요 기능 요구사항 목록
  • 핵심 품질속성 식별
    • 우선순위화된 핵심 품질속성 목록
• 시나리오 작성
  • 시나리오 도출 및 정합
    • 정합활동 = 데모시나리오로 재사용 가능 / 구체화 하고 명확화 하는 단계
  • 시나리오 우선순위화
  • 시나리오 정제
    • 상위 5개 정도의 중요 시나리오를 대상으로 좀더 상세하게 분석