설계
- 요구분석: '무엇을 만들 것인가'를 다루는 작업
- 설계는 '어떻게 실현할 것인가'를 구체적으로 결정하는 활동
1. 기본 구조 설계: 아키텍처 설계로 각 모듈의 역할과 인터페이스를 정의
2. 상세 설계: 모듈 내부의 알고리즘과 데이터를 명세화함
image p. 2 참조
설계 사고 4가지 원칙
설계 사고: 문제와 해결책을 영향을 받는 사람의 관점에서 생각하는 방식
4가지 원칙
- Human rule: 모든 디자인은 사회적인 영향을 미친다
- Ambiguity rule: 옵션을 열어두기 위한 일부 애매함은 허용한다
- Redesign rule: 기존에 유사하게 설계된 솔루션을 참조할 수 있다
- Tangibility rule: 아키텍처는 명확하게 표현해야 한다
Design for Humans
- 설계는 기본적으로 사람 중심의 노력임
- 사람들을 위해, 사람들과 함께 설계해야 함
- 모든 설계 결정은 개인들을 도움
- 설계는 사회적인 활동으로 팀의 중심에 있어야 함
- 아키텍처와 상호작용하는 사람에게 초점을 두는 것은 더 나은 설계자, 소통자, 리더가 되게 함
Preserve Ambiguity
- 공학에서 애매함은 위험하다
- 일단 설계에 대한 결정이 되면, 명확하고 명료해야 함
- 요구사항, 설계 결정 등은 애매하게 둬서는 안 됨
- 그러나 옵션을 열어 두기 위한 일부 애매함은 사용할 수 있다
- 아키텍처는 기대 품질 속성을 만족시키기 위해 구조를 배열하는 것임
- 이를 위한 최소한의 아키텍처 설계와 위험 감소에만 초점을 맞출 수 있음
- 나머지 설계 결정은 그 다음 작업의 설계자에게 남겨 둘 수 있음
Design is Redesign
- 기존의 문제에 대한 솔루션 패턴을 집대성하면, 유사한 문제에 대해 유사한 솔루션을 적용할 수 있음
- 다른 팀 또한 우리 팀과 유사한 문제를 겪었을 가능성이 있음
- 우리가 풀어야 할 문제에 대해, 누군가 패턴을 만들어 놓았을 수 있음
- 혹은 유사한 문제에 대한 프레임워크를 만들어 놓았을 수 있음
- 기존에 유사하게 설계된 솔루션을 참조하거나 고도화할 수 있음
Make the Architecture Tangible
- 아키텍처 구조가 코드에만 있다면, 아키텍처가 잘 보이지 않음
- 코드는 읽기 힘들고, 품질 속성, 설계 이유 등을 설명하지 않았을 경우
- 다른 사람과 아키텍처를 공유하려면 더 구체화해야 함
- 아키텍처는 명확하게 표현하기 위한 여러 방법이 있음
- 그림 그리기 혹은 프로토타이핑을 통해 해당 구조의 품질을 경험하게 할 수 있음
- 모델을 만들어 어떤 식으로 작동하는지 보여 줄 수 있음
설계 마인드셋
Understand the Problem
문제를 해결하기 위해 관련자들로부터 정보를 수집한다
- 이를 위해 시스템 관련자들의 필요를 이해해야 함
- 관련자들이 중시하는 비즈니스 목표와 품질 속성을 명시해야 함
- 설계 결정의 우선순위와 트레이드 오프를 이해하기
Explore Ideas
여러 설계 개념을 생성하고 공학적인 접근을 명시한다
- 다양한 패턴 탐색
- 기술 탐색
- 개발 프랙티스 탐색
*주의사항: 관련자들과 함께 작업할 때 의미가 있음!
Make it Real
- 아이디어를 구체적인 산출물로 표현하여 공유해야 한다
- 모델을 만들고, 프로토타이핑을 하고, 문서를 작성하고, 수치를 계산하며 다양한 접근 방법으로 구체화하기
- 계획에 대한 소통을 위해서 아키텍처를 구체화해야 함
Evaluate Fit
- 설계 결정이 현재의 문제를 풀 수 있는지를 검증해야 함
- 일반적인 방법은 여러 시나리오를 활용해 아키텍처를 돌려봄으로써 검증하는 것임
- 혹은 실험이나 결정과 관련된 위험을 조사하여 설계 결정을 시험하기
설계 마인드셋은 ppt p. 16 참조
소프트웨어 아키텍처 정의
아키텍처 구축이란?
- 건물 전체를 지탱하는 구조
→ 아키텍처는 건물(또는 시스템)이 무너지지 않고 서 있게 만드는 근본 구조라는 뜻 - 금속, 흙, 벽돌 같은 실제 재료 없이도 존재하는 추상적인 개념
→ 아키텍처는 벽돌 그 자체가 아니라
어디에 기둥을 두고, 어떻게 하중을 분산할지에 대한 ‘설계 개념’ - 아키텍처를 바꾸는 것은 어렵고 위험하다
→ 건물의 뼈대를 나중에 바꾸면 무너질 수 있듯이 시스템의 아키텍처를 나중에 바꾸는 것도 매우 어렵고 위험함
시스템의 소프트웨어 아키텍처란,
시스템을 이해하고 판단(reasoning)하기 위해 필요한 구조들의 집합이며, 이 구조는 다음을 포함함.
- 소프트웨어 요소들 (elements)
→ 모듈, 컴포넌트, 클래스, 서비스 등 - 요소들 간의 관계 (relations)
→ 호출 관계, 의존성, 데이터 흐름, 통신 방식 - 요소와 관계가 가지는 속성 (properties)
→ 성능, 보안성, 확장성, 신뢰성 등
ppt p. 21 참조
- 박스 = Element(요소)
- 선 = Relation(관계)
- 박스나 선에 붙은 설명 = Property(속성)
- 점선 박스 전체 = Structure(구조)
- Reasoning = 이 구조를 보고 “이 시스템은 안전한가? 확장 가능한가?”를 판단
프로그램 혹은 컴퓨팅 시스템의 소프트웨어 아키텍처란, 소프트웨어 구성요소, 이들 구성요소의 가시적인 속성, 그리고 구성요소 사이에 관계로 구성된 시스템의 전체적인 구조 또는 구조들을 말함.
소프트웨어 아키텍처는 소프트웨어 시스템들의 큰 규모의 구조와 실행에 관한 연구이다.
소프트웨어 아키텍처란, 다음과 같은 것에 관한 중요한 결정들의 집합이다.
1. 시스템의 구조를 나타내는 구조적 구성요소와 그들을 결합시키는 인터페이스
2. 그들의 협동을 통해 나타나는 구조적 구성요소와 행위적 구성요소들의 결합을 점진적으로 서브 시스템에 매핑하는 것
3. 구조를 이끌어나가는 아키텍처 스타일의 선택
아키텍처는 시스템의 근본적인 개념 혹은 특성으로, 환경에서의 시스템에 대해, 시스템의 요소 및 그 관계에 대해, 또한 그 설계와 진화의 원칙에 대한 것이다.
- 환경: 시스템에 영향을 주는 모든 것
- 원칙: 시스템의 설계 및 진화의 원칙
아키텍처의 역할
문제에서 솔루션으로의 전환
품질의 요구사항 반영
위험 감소
변경을 손쉽게 포용함
1. 요구사항 분석 - user 관점에서의 문제점 -> 시스템 관점에서의 문제점
2. 아키텍처 설계 - 상위 레벨의 시스템 디자인, 시스템 레벨의 추상화
3. 상세 설계 - 모듈, 컴포넌트, 알고리즘, 데이터 구조
4. 구현 - 데이터 레이아웃, 메모리 맵
5. 통합 및 시험
소프트웨어 아키텍처는 소프트웨어 시스템의 성능과 품질을 결정함
두 개의 시스템이 서로 다른 구조를 가지고 있는 것은 품질 속성이 다르기 때문임
- 포탈의 커뮤니케이션 채널과 우주 왕복선의 커뮤니케이션 채널은 다른 구조를 가짐 - 품질 속성이 다르기 때문
아키텍처에서 적극적으로 위험의 감소하는 것에 노력을 기울이면, 시간이 갈수록 설계는 안정화되고 오류 정정을 위한 노력에 초점을 둘 수 있음
소프트웨어는 변경에 유연하게 대응할 수 있어야 함
소프트웨어 아키텍처는 변경을 가능하게 하는 구조를 제공해야 함
중요한 정보는 아키텍처에 삽입함 (요구사항을 통해 주요 내용을 삽입)
아키텍처 선택하기
아키텍처 설계 옵션의 탐색
제약 사항의 수용
기대 품질 촉진
아키텍처 설계 옵션 탐색
아키텍처의 일반 형태를 구성하기 위한 요소들의 책임과 탐색
요소들의 상호작용을 결정 짓기 위한 관계와 인터페이스 검색
도메인 모델의 이해와 탐색
기대 품질을 촉진할 기술과 프레임워크 탐색
구축과 배포 방식의 탐색
기존 설계의 탐색
제약 사항 수용
기술 적 제약사항, 인력, 비용, 일정, 프로세스 등을 수용해야 함
- 동시 개발을 수행할 수 있도록 하는 방식 선택
- 증분의 배포를 가능하게 하는 패턴 선택
- 위험을 줄일 수 있는 기술 선택
- 자동화와 개발 가속화를 할 수 있는 기술 선택
- 기술적 부채를 승인하거나 일부 계획을 미루는 등의 선택
아키텍처 설계는 사람 중심의 관점이 시작점임
아키텍처 설계에서 문제와 솔루션이 일관되고 구체적인 것이 중요함
아키텍처 설계는 점진적이고 점증적인 방법임
아키텍처 설계에서의 선택은 기대 품질에 기반함