3 분 소요

이번 포스트에서는 Logical Architecture과 UML Package Diagram 에 대해 다룬다.

Logical Architecture

Logical Architecture란?

논리 아키텍처는 소프트웨어의 설계에 중요한 주제 (분석 -> 설계)

  • 소프트웨어 구조를 패키지 단위로 정의
  • 클래스들이 포함될 패키지 구조를 설계하는 것

특징

  • 이 시점에서부터 분석 중심 작업에서 소프트웨어 설계로 넘어감.
  • 요구사항 분석이 끝난 이후, 시스템의 구조를 설계하는 단계 중에서 구조가 logcial Architecture

UP와 LA의 관계

  • LA

UP에서의 Supplementary Specification( 보조 명세서 ) 는 비기능 요구사항인 NFR을 포함하고 있고 이것이 주로 LA를 형성하는 prime input

  • UML Package Diagram

LA를 시각적으로 표현한 것으로 Design model의 일부

나중에 Software Architecture Document에 하나의 뷰로 정리될 수가 있다.

LA, Layer 정의

논리 아키텍처 (LA)란?

  • 소프트웨어 클래스들을 패키지, 서브시스템, 계층으로 구성하는 대규모 구조 설계
  • 배포(Deployment) 관점이 아닌, 논리적 조직화에 집중
  • 설계 모델(Design Model)의 일부

계층 (Layer)이란?

  • 클래스, 패키지, 서브시스템 등을 묶은 큰 단위의 (coarse-grained) 그룹
  • 각 계층은 명확한 책임과 역할을 가짐. (cohesive reponsibilty)
  • 상위 계층은 하위 계층의 서비스를 사용 (역방향 호출 X)
  • 예시
      1. User Interface (UI) : 사용자와 상호작용하는 계층
      1. Application Logic and Domain Objects : 비즈니스 로직 및 도메인 모델을 포함하는 계층
      1. Technical Services : DB 접근, 로깅 등 여러 시스템에서 재사용 가능한 일반 기술 서비스 계층

Strict vs Relaxed LA

**Strict Layered Architecture **

  • 한 Layer는 자신 바로 아래의 레이어만 호출할 수 있음.
  • 상위 계층은 딱 한 단계 아래만 접근 가능
  • 네트워크 프로토콜에서 많이 사용

Relaxed Layered Architecture

  • 상위 Layer가 하위의 여러 레이어를 동시에 호출할 수 있음.
  • 계층 간 유연성 증가
  • 현실에서 많이 사용

공통적으로 두 개의 아키텍처 모두 lower에서 higher 계층을 호출 불가

Software Architecture

Software Architecture란?

  • 소프트웨어 시스템의 기본적인 구조와 이런 구조들을 설계하는 방법론
  • 구성 요소
    • software elements : 클래스, 모듈같은 소프트웨어 구성요소들
    • Relations : 요소들 간의 연결관계
    • Properties : 요소와 관계가 가지는 속성

UML Package Diagram

UML Package Diagram 이란?

UML Package Diagram의 목적

  • 논리 아키텍처를 표현하는데 자주 사용
  • LA의 구성요소들을 시각화 할 수 있음.
  • UML 패키지는 다양한 요소들을 그룹화할 수 있음.
  • 가능한 대상 : 클래스, 다른 패키지, 유스케이스 등등..

Dependency

패키지 의존성 : 개발자가 시스템 내 대규모 결합 구조를 시각적으로 이해하는데 도움을 준다.

  • 점선 화살표 dependency line 이 사용 (아래 그림과 같음)
![Package Diagram Tutorial Lucidchart](https://corporate-assets.lucid.co/chart/22822490-aa0c-40a1-abd0-822de91a0229.png?v=1707819674726)

계층을 이용한 설계의 핵심 개념

  • 시스템을 논리적으로 구조화하기 위해 계층을 사용

  • 각 계층은 역할이 명확히 분리된, 관련 있는 책임을 갖는다.

  • 계층의 구분 방식

    • 하위 (lower) 계층 : 낮은 수준의 기술적 기능과 공통 서비스를 담당

    • 상위 (higher) 계층 : 애플리케이션 특화 기능을 담당

    • 상위 계층은 하위 계층 호출이 되지만, 반대는 안됨.

      결합도 (coupling) 가 줄어들고, 유지보수성이 좋아진다.

Mapping code

  • 실제 언어(Java, C#, Python 등)의 패키지/네임스페이스와 매핑 가능
// UI Layer
com.company.app.ui.swing
com.company.app.ui.web

// Domain Layer
com.company.app.domain.sales
com.company.app.domain.payments

// Technical Services
com.company.service.persistence
org.apache.log4j

// Foundation
com.company.util

Domain Layers and Domain Objects

어떻게 objcet를 활용해 application logic 을 design 할 수 있을까?

정답

  • 실세계의 도메인을 반영한 소프트웨어의 객체를 만들고
  • 여기에 애플리케이션 로직을 할당한다.
  • 현실 개념을 반영한 객체 = 도메인 객체

Domain Object

  • 문제 도메인 안의 개념
  • 관련된 애플리케이션 로직이나 비즈니스 로직을 포함함.

Domain Layer

  • 도메인 객체를 포함해 애플리 케이션 로직을 처리하는 계층

도메인 객체가 어떻게 현실 개념에서 영감을 받아 만들어졌는지는

주로 설계 모델의 클래스 정의에 영감을 준다.

=> representation gap

Tier, Layer, Paritions

  1. Tier
  • 물리적 처리 단위 (노드) 를 의미함. 시스템 외부 배치
  • 주로 하드웨어 배치나 네트워크 구조에서 사용
  1. Layers
  • 시스템을 수직으로 나눈 논리적 계층
  • 각 레이어는 특정한 책임을 맡음
  1. Partition
  • 하나의 Layer내부를 수평으로 나눈 것
  • 서로 유사하거나 병렬적인 하위 서브시스템들을 구분

Layer , Parition 은 수직 과 수평 방향의 차이

Model-View Separation Principle

  1. Do not connect or couple non-UI objects direclty to UI objects.
  • UI 객체가 아닌 객체는 UI 객체와 직접 연결하면 안된다.
  • 이유
    • UI는 특정 애플리케이션에 종속
    • 도메인 객체는 재사용 가능성이 높아야한다.
  1. Do not put application logic in the UI object methods.
  • UI 코드 안에 application logic을 넣지 마라
  • UI 는 다음만 담당해야함. : UI 초기화, 버튼 클릭, 이벤트
    • 로직 실행은 반드시 도메인 객체에 위임

Connection Between SSDs, System Operation, Layers

UI -> Domain Layers 요청 위임

  • UI 계층에서 이벤트 발생시, 해당 요청 직접 처리가 아닌 도메인 계층에 위임 또는 전달을 함.

전달되는 메시지 SSD의 시스템 연산들

  • 도메인 계층에 호출되는 연산들
  • SSD 에 명시되어 있음.
  • SSD에서 시스템 객체가 수행하는 메시지는 결국 Domain Layer가 수행함.

참고

Concurrency, Locks

8 분 소요

이번 포스트는 OS의 Concurrency와 Locks에 대해 다룬다.