Architectural Decision 구조적 의사결정

doran·2024년 10월 18일

Associate Architecture

목록 보기

6/6

[앞 내용 요약]
크게 두개의 element 가 있음 - 모듈, 컴포넌트
클래스 = 모듈 = 개발측면 element - 관계를 그린 것이 module view
오브젝트 = 컴포넌트 = 실행동작 측면 element - 어떤 형태로 interact 하는지 component-connector view

https://github.com/bosornd/example-module-design

deployment view
-> thread A,B,C 를 없애고 6개의 component 로 보여주면 - componenct view
layer 로 그려진 것은 module view

** module 과 component 를 잘 구분해야함.

module view 그림을 그리고 맥락을 이해할 수 있어야하고
component view 그림을

data를 logic이 의존하는 그림

서버라는 Package 를 두고, server1.ts, server2.ts
data를 하나로 묶고, logic 을 하나로 묶고

server가 data, logic 에 의존함.
data가 logic 을 의존하고

logic 이 data를 의존하느냐 logic이 data를 의존하느냐?

logic을 data가 의존하기 때문에
logic을 변경하면 data에 영향을 미치지만,
data를 변경하는것은 Logic에 영향을 미치지 않음

** module 과 component 를 잘 구분해야함.

module view 그림을 그리고 맥락을 이해할 수 있어야하고
component view 그림을 “”

Architectural Decision Record

구조적 요구사항
FR(기능적 요구사항) - T/F, 요구되는 기능은 무조건 달성해야함
QR(품질 요구사항) - measure. 품질(성능)에 의해서 소프트웨어를 평가함, 중요한 품질이 뭔지 잘 판단해야함.
개발 품질을 좋게하기 vs. 유지보수성 높이기는 trade-off 가 있음. 두 개 다 만족하는게 어렵지만 둘 중 더 좋은것을 택해야함
ASR 을 판단하는것이 어려움. 가장 중요한 품질 요구사항이 무엇인지 그것과 관련된 기능이 뭔지를 보고 최적성있게 끌어내는 것이 중요.
? 질문: 가장 중요한 품질이 무엇입니까? 성능(부팅타임, 쿼리 처리타임, 메인페이지 보여주기..) 어떤 성능인지 구체적으로 알아야함

Architecutral Drivers

Functional Requirements

고객의 요구사항
core functionality 을 중요하게 다루지만, 추가적으로 중요한 품질과 관련되어 있는 기능(bootin time, 예외처리 등)

Constraint

미리 정의된 요구사항

Quality Attributes

고객에 의해 요구가 되지 않았지만, 사용성을 높이기 위해서 제공되는 기능 (품질을 높이기 위한 것으로 꼭 하지 않아도 되는 것)
측정에 따라서 좋다 나쁘다 평가가 가능함.
기능과 품질이 같이 가진 않음. 기능적 요구사항을 다 한 다음에 품질을 검토하면 이미 늦음. 구조를 다 바꿔야할 수도 있음.
구조적 의사결정 (AD) 를 하게 될 때 Q1이 좋아지지만 Q2가 나빠질 수도 있다. 구조설계단계에서 중요한 품질이 무엇인지 미리 파악해야함. 나빠지는 게 더 중요하기 때문에 뭐가 나빠진다 하면 하지 말아야함.

⭐️Performance (성능)

Quaility Scenario 품질 시나리오로 명세, External Performance 를 주로 다룸(7개 내외)

QS(Quality Scenario) = TS(Test Scenario, 환경, 자극, 반응) + M(Measure)
E(환경): 주로 정상적 상황/응급 상황/과부화 상황 등

⭐️Modifiability (변경/유지보수 용이성 - Maintainability)

환경은 어떤 시점에 변경을 요구하는지
다음과제에서 바뀐다. 언제 변경 요구되는지, 개발 이후에 다음과제에, 환경은 중요하진 않음
Source 는 누가 요구사항 변경을 요청하는지? 도 그닥 중요하진 않음
- 어떤 요구사항이 변경 요구될 것인지가 가장 중요함
품질요구사항을 결정할 땐 구조설계가 안되어있기 때문에 Code/Data/ 뭐가 변경될지는 모르기 때문에 사람을 적어주는 것이 좋음
반응도 일반적으로 비슷함. 변경이 요구됐으니까 순서대로 하는 것
Measure : Effort(Manmonth) 도 애매하긴 함. 구체적으로 측정도 어려움. 일반적으로는 manmonth로 다룸, 타이트하게 하고싶다면 LOC 로 하기도 함. 모듈의 크기
[Tactic]
모듈의 크기를 줄이고
응집도를 높이고
결합도를 낮추고 (의존성) - A->B 로 바로 보내는것이 아니라 브로커를 두어서 Subscribe 하도록 하면 의존성을 낮출 수 있다.

Availability (Reliability)

비정상적인 상황(HW고장, NW 상태 불량 등 나쁜 상황)에서 시스템이 어떻게 반응하길 기대하는지?
비정상적인 상황의 명세를 정의하는 것이 중요함
네트워크가 안좋은 상황에서, 부하가 심한 상황에서, Startup 도중에, 환경에 명세해도 좋다.
보통은 자극에 명세하는 경우도 많음.
Fault 에대한 로그를 남기거나, recover 를 한다거나
Measure Availability percentage or Fault 를 감지하는데까지 걸리는 시간, repair 하는데 걸리는 시간

Security

공격에 따른 대응이 달라짐
어떤 공격인지 명확히 해야한다. (Stimulus)
어떤 공격자가 NW로 packet을 분석해서 중간에 바꿔치기를 한다. -> 반응은 공격인지 아닌지 감지하여 방어하거나 복원한다거나 원하는 response 를 명시하면 됨

Usability

포괄적/구체적인 경우 나뉨
사용자가 물품을 구매하는데 사용편의성이 좋았으면 좋겠다.(포괄적)
measure 는 사용자가 score 를 주도록
UX에 관련된 설계 결정이 필요한 것과 Architect 가 다뤄야하는 것을 나눌 필요가 있음
심미/미학적으로 보기에 ~했으면 좋겠다 = UX
사용자가 시스템을 사용하는데 있어서 support 하는 일. 사용자의 preferance 개인화 = Architect
UX 에 영향을 많이 받는 Module 은 Separation 하는것이 가장 일반적
사용자가 관심을 가지고싶어할 만한 자동차를 광고처럼 알려주는 경우, 자극원은 사용자보다는 시스템이 될 수 있음. 시스템은 사용자에게 추천하고 싶은 자동차를 보여준다. 반응원이 사용자가 될 수 있음.
measure 는 내가 광고한거 중에 몇번이나 상세한 정보를 확인했는지? 에 대한 것으로 둘 수 있음