[Sofrware Architecture] SA 개요

SW World

Software가 Physical World에 존재하는 산업의 Value Chain을 먹고 있다

• Amazon (1994.07.05)
• Netflix (1997.08.29)
• Google (1998.09.04)
• Tesla (2003.07.01)
• Facebook (2004.02.04)
• NAVER (1997.02월)
• Yanolja (2005년)
• Kakao (2006.12월)
• 배달의 민족 (2011.03.10)
• 토스 (2013.08월) 
• 마켓컬리 (2015년)
• NVIDIA CEO Jensen Huang (2019.08) AI에 의한 코딩 자동화, AI가 웹사이트를 만든다
  (MIT Technology Review) Software is eating the world, but AI is going to eat software

그만큼 IT 및 SW가 중요한 세상이다~

Software Architecting을 통해서 Platform을 설계하는 실력/시아를 가질 수 있도록 하는 것이 중요하다!!

 

 

---

SW Architecture

Architecture 어원

• 건물을 지을때 전체 구조를 관리

 

SW Architecture

• SW의 구조를 관리하는 것
• [ANSI/IEEE Std 1471-2000] The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the pronciples governing its design and evolution 
  • 시스템에 대한 기본 조직 체계로
    - 시스템을 이루는 구성요소와 구성요소들 사이의 관계
    - 구성요소와 주변 환경(외부 시스템 등) 들과의 관계
    - 시스템의 진화와 설계를 지배하는 원칙들로 실체화
• [CMU SEI] The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, and properties of both
  • A Structure is the set of elements itself, as they exist in software or hardware
    (구조는 SW 또는 HW에 존재하는 요소의 집합)
  • A view is a representation of a structure. It consists of a representation of a set of elements and the relations among them
    (뷰는 구조의 표현. 뷰는 요소집합의 표현화 요소들 간의 관계로 구성됨)
  • SW Architecture는 View를 통해서 보여주고 문서화 되어진 구조의 집합이다
    (아키텍트는 구조를 설계하는데 뷰를 사용하는 것)
    3 뷰 모델
    - C&C View = 사용자 중심 컴퍼넌트
    - Module View = 개발자 중심
    - Deployment 뷰 = 운영/유지보수자 중심, 제안서에 많이 들어가는 System Diagram 
    * SW 시스템을 바라보는 관점(View)를 일치 시킨 후 의사소통 필요
• SW Architecture 탄생 배경
  • PJT 복잡도가 커짐 -> 대규모 PJT 전에 철저하게 준비하고 계획된 내용을 지켜야 함
    = 사용자의 요구를 만족시키려면 전체 시스템의 구조를 생각하고 균형/조화 이루도록 설계 필요
       -> SW Architecture의 개념
    - 아래와 같은 사용자 요구 만족시키기 위해 SW Architecture가 필요함
       > 적시성 (Time to Market)
       > 유연성 (Flexibility) - 급변하는 사용자 환경에도 적응할 수 있어야 함
       > 통합 (Integration) - 기존 시스템과 쉽게 통합 되어야 함

 

SW Architecture 3요소

• 컴퍼넌트
  • 시스템을 이루는 구성요소
  • SW개발구성요소, 사용 SW, 데이터베이스
• 구성요소간의 관계, 주변환경과의 관계
  • SW 개발 구성요소들 간의 관계
  • 구성요소와 주변 환경들과의 관계
  • 이해 관계자 뷰에 따른 관계
• 원칙 및 기법
  • Software Architecture Framework (Based on IEEE 1461-2000)
  • Software Architecture Viewpoint Model (ISO RM-ODP (ISO/IEC 10746)
    • Siemens 4 views in SA (개년적, 모듈, 코드, 실행 View)
    • 4 + 1 View (Usecase view, Logical view, Implementation view, Process view, Deployment view)
    • SEI View Model (Component & Connector view, Model view, Allocation view)
  • Architecture 모델 (데이터 중심형, CS 모델, 계층 모델MVC, 데이터 흐름 모델)
  • 평가방법
    • ATAM (Architecture Tradeoff Analysis Method)
    • SAAM
    • ARID
    • CBAM (Cost Benefit Analysis Method)

 

SW 아키텍처의 필요성 & 중요성

• 체계적인 분석 및 설계를 위한 접근 방법 임
• 재사용 가능한 시스템의 추상화를 제공하여 SW 아키텍처가 시스템을 구성하는 요소와 관계를 간략/명확하게 나타낼 수 있음 = 큰 규모의 재사용이 가능, SW 조직의 Asset
• 설계방향의 가이드
  - 전체적인 관점에서 품질 속성을 고려하여 목표 시스템의 설계 방향을 조기에 결정할 수 있도록 지원함
  - 위험요소 감소 가능
• 이해관계자 (PJT 관리자, 품질 담당자, 개발자, 테스터, 고객 등) 와의 커뮤니케이션을 위해 정의된 형상이자 표현의 수단 -> 원활한 커뮤니케이션 가능
• 품질 요구사항을 반영할 수 있게 함
• 요구 사항들간 Trade off 관계의 품질 속성 간의 충돌 조정
• SW 상세 설계 및 구현 이전 초기 설계 단계에서 SW가 가질 품질 요구사항을 예측할 수 있게 함

 

SW 아키텍처의 특징

• SW에 대한 전체적인 구조 제공
  - SW의 골격을 나타내는 추상화된 전체 구조 제공 -> 모든 이해관계자들의 시스템에 대한 전반적인 이해에 도움 
• 여러 구성요소(서브시스템, 컴포넌트)를 다룸
  - 어떤 구성요소로 나눌 것인지 결정 (Divide & Concur 원리 이용)
  - 구성 요소 간의 관계 및 구조가 조화롭게 일관성을 가지도록 함
• 구성 요소들이 인터페이스를 통해서 어떻게 상호작용하는지 정의
  - 구성요소를 외부에서 사용할 수 있도록 인터페이스를 제공
  - User - SW간 I/F, 타기관 과의 I/F 정의
• 세부내용 보다는 아키텍트의 전문가적 판단(Expert Judgement, Delphi 기법 등)하에 중요한 부분 다룸
• 시스템 설계와 개발 시에 적용되는 원칙과 지침이 있어야 함
  - EA 원칙
    : 원칙근거, 원칙 준수 가이드라인 등을 정의

 

SW 아키텍처 산출물

• Meta-Architecture
  • 아키텍처 설계하기 위한 일반적인 지침
  • SA가 무엇인지 결정하고 아키텍처를 설계하기 위한 의사결정트리와 아키텍트의 역할에 대한 정의 아키텍처 문서에 대한 템플릿으로 구성
• Software Architecture
  • Module View, C&C View, Allocation View로 구성
  • Context diagram, Component spec, interface spec 도출
• 가이드라인과 정책

 

SA의 효율적인 실무 활용 방안

• 아키텍처가 제공하는 다양한 모형으로부터 여러가지 품질 특성을 추론하고 품질향상을 도모함
• 이해관계자 간의 원활한 의사소통에 도움 될 수 있도록 베이스라인 관리와 추적성 관리 필요
• 기술 혹은 플랫폼 독립적인 모형에 기반 -> 향후 유연하게 대응할 수 있도록 아키텍처 모형 제공

 

핵심 기초 기술 of Open CA 평가기준

• People
  - Apply Communication Skills
  - Lead Individual & Teams
  - Perform Confilict Resolution (갈등 해결)
• Project Management
  - Architecture Element 관리 (산출물 관리 등)
• Business
  - Understand Business Aspects (비즈니스 측면 이해)
• Architecture
  - Develop IT Architecture
  - Use Modeling Techniques
  - Perform Technical Solution Assessment (기술 솔루션 평가)
  - Apply IT Standards (표준끼리 상충되는 부분 존재 -> 기본적인 표준 수립 필요)
  - Establish Technical Vision (기술 비전 수립)
  - Use of Technique 
  - Apply Methods (방법론 적용)
  - Define Solution Functional & Non-Functional Requirements
  - Manage Stakeholder Requirements (이해 관계자 요구사항 관리 - 요구사항은 줄이는 것이 중요)
  - Establish Architectural Decision (아키텍처 결정 수립)
  - Validate Conformance of the Solution to the Architecture (솔루션의 적합성 검증)
  - Perform as Technical Advisor (Master급 부터 활동)