[SW Architect] Architectural Views

mandu·2025년 6월 25일
SW Architect

[SW Architect]

목록 보기
6/10

SW Architecture란?
소프트웨어 아키텍처는 시스템에 대해 추론하기 위해 필요한 구조들의 집합으로, 이는 소프트웨어 요소들과 그들 간의 관계 및 각 요소와 관계의 속성을 포함한다.

1. Architectural View

Architectural View(아키텍처 뷰)는 시스템 아키텍처의 특정 관심사(concerns)에 집중하여 구조를 표현한 것

  • 소프트웨어 아키텍처 문서는 여러 뷰의 집합으로 구성된다.

1.1 하나의 시스템에 여러 View가 필요한 이유

  • 현대 시스템은 복잡성이 높아 전체 구조를 단일한 구조로 한 번에 이해하는 것이 어려움
  • 서로 다른 이해관계자(Stakeholders)는 각자 시스템에 대한 다른 관심사를 가짐
    → 각 관심사, 중요도에 초점을 맞춰 구조를 표현함으로써 복잡한 소프트웨어 시스템을 다양한 관점에서 이해할 수 있도록 해야함
  • 건물을 설계할 때 각 전문가가 자신이 관심 있는 부분에 초점을 맞추어 보는 것과 유사
    e.g.,
    • 구조적 관점(Structural View): 건축 구조 엔지니어(Structural Engineers)가 건물의 골격, 하중 등을 분석할 때 사용하는 뷰.
    • 배관 관점(Plumbing View): 배관공(Plumbers)이 물 공급 및 배수 설비 등을 검토할 때 사용하는 뷰.a
    • 전기적 관점(Electrical View): 전기 엔지니어(Electrical Engineers)가 배선, 전력 공급 및 전기 설비를 설계할 때 사용하는 뷰.

1.2 Architecture view Model

  • 4+1 View Model
  • SEI View Model → 앞으로 내가 사용할 Model
  • Siemens View Model

2. SEI View Model

SEI(Software Engineering Institute) View Model은 소프트웨어 아키텍처를 다음의 세 가지 주요 관점(View)으로 나누어 설명함:

  • Component-and-Connector (C&C) View
  • Module View
  • Allocation View

각 View는 시스템을 서로 다른 측면에서 설명하며, 함께 사용되어 전체 시스템의 구조와 특성을 포괄적으로 표현함.

2.1 Component-and-Connector (C&C) View

정의

  • 런타임 시점의 시스템 구성 요소(component)와 이들 간의 상호작용(connector)을 설명함.

구성

  • Component: runtime에 존재하는 주요 처리 단위 및 데이터 저장소
    • 1개 이상의 Port(다른 컴포넌트와의 interaction을 위한 interface)를 가지고 있음 (Port name 필수, multiplicity까지 포함 가능)
    • streotype (<<controller>>, <<server>> 등)을 통해 어떤 역할을 하는지 작성
    • 예시: 프로세스, 스레드, 객체, 데이터 저장소, 주요 processing unit(logical 혹은 conceptual), 또는 데이터 저장소
  • Connector: 구성 요소 간의 통신 및 상호작용
    • interaction을 명확하게 인지할 수 있도록 작성
    • 마찬가지로 name, role(== component의 port와 동일, multiplicity를 가짐), stereotype 가질 수 있음
    • 복잡한 connector는 여러개의 component와 connector의 집합으로 만들어질 수 있음
    • UML Connector는 그냥 simple line임
    • UML Connector에서도 조금 복잡해지면, Component처럼 표현해야 함
    • call-return connector는 assembly connector(rollypop 형식)으로 작성
    • Tagged values(simple line에 메모 달기)를 통해 connector에 부가 설명 가능
    • Attachment: 컴포넌트 포트는 커넥터의 역할(role)과 연결됨
    • Delegation: 컴포넌트 포트는 내부 서브 아키텍처의 포트와 연결될 수 있음

목적

  • 시스템이 실행 시 어떻게 동작하는지 시각적으로 표현
  • 런타임 품질 속성 분석에 활용됨:
    e.g.,
    • Performance: 각 프로세스의 cycle time 분석
    • Reliability: 개별 구성 요소의 신뢰도 기반 전체 신뢰도 추정
    • Availability: 상호작용 경로의 장애 대응성 분석

주의사항

  • 컴포넌트 타입과 컴포넌트 인스턴스(:)를 하나의 다이어그램에서 섞어 쓰지 말아야 함
  • 포트의 이름은 왠만하면 작성해야 함 (외부 component의 입장에서 어떤 component인지 적어주면 됨)
    즉, Client Teller와 Main: Account Server이 같은 다이어그램 안에 혼재되면 안 되고, 분리된 다이어그램으로 그려야 함
  • lollypop interface 및 port multiplicity를 component instance에는 적지 마라

예시

  • 보통 C&C Type + Runtime Configuration으로 이루어지기도 함

2.2 Module View

정의

  • 시스템의 정적 구조를 코드 단위인 모듈로 나누고, 모듈 간의 관계를 설명함.
  • 모듈: 명확한 책임을 가진 구현 단위
    • 예시: 클래스, 함수, 레이어, 라이브러리 등
  • 모듈 관계: 포함, 호출, 의존성 등

구성

  • Modules: 소프트웨어의 구현 단위로, 일관된 책임(기능/역할)을 수행하는 구성 요소

    • 함수, 프로시저
    • 클래스
    • Aspects
    • Layer
    • Data Entity

  • Relations: 모듈 간의 정적 관계

    • is part of: 하위 모듈이 상위 모듈의 일부인 전체-부분 관계
    • Depends on: uses, allowed to use, crosscuts, data entity relationships
    • Is a: 일반화/특수화 관계 (상속)

목적

  • 구현 단계(Construction): 소스 코드 설계의 청사진(blueprint)으로 사용
  • 분석(Analysis): 요구사항 추적성과 영향도 분석에 사용
  • 커뮤니케이션(Communication): 시스템 구조를 잘 모르는 사람에게 Top-down 구조로 시스템 설명 가능
  • 모듈 뷰는 런타임 동작 및 품질 속성 분석용이 아님
    • (e.g., Performance, reliability)
  • 모듈 뷰에서의 하나의 모듈들은 C&C 뷰에서 많은 요소와 매핑될 수 있음
  • 반대로, C&C 뷰에서 하나의 요소는 모듈 뷰에서 많은 모듈에 매핑될 수 있음

스타일

  1. Decomposition Style
    • 복잡한 시스템을 한눈에 파악하기 위한 스타일
    • is-part-of relation에 초점을 맞춤
    • 표현 방법
      • UML: Package construct(박스 안에 박스)
      • Indentation
    • 나누는 기준
      • Achievement of certain quality attributes
      • Build-versus-buy decisions
      • Product line implementation: 동일 회사 제품군으로 묶기
      • Team allocation
    • 패키지: 의미있는 요소들 모아둔 것
    • 서브시스템(우측 상단에 fork symbol 존재): 독립적으로 실행 및 배포 가능한 시스템들의 집합

  1. Uses Style

    • depends-on relation에 초점을 맞춤
    • "특정 모듈이 work하기 위해서 어떤 모듈이 존재해야하는가?"
    • Incremental development를 위한 planning 하는데에 사용됨
    • 변경 파급효과 측정 가능
    • 표현 방법
      • UML: <> stereotype 사용
      • Matrix, Two column table
  1. Generalization Style
  • abstract module을 사용한 class inheritance, interface inheritance, interface realization
  • 표현 방법
    • 상속, 인터페이스 구현 기호 사용
  1. Layered Style
  • 가장 많이 사용
  • Layer: 밀접하게 관련된 서비스들의 논리적 묶음
  • 상위 layer만 하위 layer에 접근 가능 (이 순서가 꼭 지켜져야 함)
  • layer 정보는 소스 코드로부터 절대 도출될 수 없음
  • layer끼리 영향 x --> modifiability, portability, reusability ↑
  • Decomposition Style과 일치하지 않을 수 있음
  • 표현 방법
  1. Data Model Style
  • Data entity와 그들간의 관계에 초점을 두어서 표시
  • Relations
    • one-to-one, one-to-many, many-to-many
    • Generalization/Specialization
    • Aggregation
  • 데이터 구조 표현
  • 데이터 모델의 영향 분석
  • 표현 방법
    • UML: Multiplicity로 표현

2.3 Allocation View

정의

  • 소프트웨어 요소(Module or C&C View)와 환경 요소(하드웨어, 파일시스템, 조직 등) 간의 매핑을 설명함.

스타일

  1. Deployment Style

    • 컴포넌트 및 커넥터를 실제 하드웨어 환경(디스크, 노드, 네트워크 등)에 매핑
    • Software element가 요구하는 속성들을 고려하여 Environment element에 매핑
    • UML: Deployment diagram: Artifact(파일, 라이브러리, db, config 파일 등)가 node(devide 혹은 SW 실행 환경) 안에서 deploy되는 그림
      • <<manifest>>: 구체화
      • 노드 간에는 physical link나 protocol 작성
      • 예: 웹 서버 프로세스를 특정 서버 노드에 배치

  2. Installation Style

    • 소프트웨어 구조를 파일 시스템에 매핑
    • 예: 실행 파일, 설정 파일, 디렉토리 구조 구성

  3. Work Assignment Style

    • 소프트웨어 모듈을 담당 인력, 팀, 조직 단위에 매핑
    • 예: A 팀은 UI 모듈, B 팀은 백엔드 모듈 담당

목적 (특히 Deployment Style 기준)

  • Performance 분석
    • 소프트웨어-하드웨어 매핑 변경을 통해 성능 조정 가능
  • Reliability 분석
    • 실패 가능성이 있는 처리 요소나 통신 채널 파악
  • Security 분석
    • 하드웨어 구성과 소프트웨어 배치에 따른 보안 영향 평가
  • Cost Estimation
    • 하드웨어 구매 옵션 비교 시 비용 추정 가능

예시

No discussion of design alternatives with rationale
설계 대안들에 대한 합리적인 설명(이유 포함)이 없는 상태

profile
mandu
만두는 목말라
이전 포스트

[SW Architect] Architecture style

다음 포스트

[SW Architect] Architectural Tactics

0개의 댓글