3-1공부/소프트웨어공학론

기말2. 아키텍쳐

KGW2027 2022. 5. 10. 11:00
728x90
반응형

아키텍쳐(Architecture)란?

 '설계에서 의사 결정의 집합, 시스템의 청사진 ( 구조, 상호작용, 기능 등... )'

 아키텍쳐를 설계하는 단계에서는 많은 창의성이 요구된다.

 

 1. 아키텍쳐 설계에서의 중요한 점

  • Third-party 컴포넌트를 사용할 때, 유지보수를 위해 Wrapper와 같은 기능을 이용하는 것이 유리하다.

 2. 비-기능적 요구사항의 설계 방향

  • 성능 ( Perfomance ) : 성능에 큰 영향을 미치는 Operation들은 모으고, 모듈간 상호작용은 최소화한다.
  • 보안 ( Security ) : Layered 아키텍처를 사용해서 보안이 필요한 에셋들을 안쪽 레이어로 넣는다.
  • 안전성 ( Safety ) : 안전에 치명적인 기능들은 Sub-system에 넣어서, 안전성 검증의 비용을 최소화한다.
  • 가용성 ( Availability ) : 모듈을 여러개로 구현하여, 하나가 다운되더라도 나머지로 실행할 수 있게 한다.
  • 유지보수 ( Maintainability ) : 모듈화를 잘 해서, 고장난 부분만 교체하고, 새로운 부분을 추가할 수 있게 한다.

3. 아키텍쳐 표현 방식

  • Package Diagram : 계층적으로 분할된 Diagram
  • Facade Design Pattern : Client와 subSystem이 Facade를 두고 분리된다.
  • 이외에도, Simple & Informal하게 도형으로 다이어그램을 표시할 수 있다. ( ex: Android, MFC 등 )

4. 디자인 아키텍처

  • Layered Architecture ( 계층적 구조 )
    - 각 계층에는 연관된 기능끼리 위치하며, 바로 위 계층에 서비스를 제공한다.
    - 가장 아래 계층에는 서비스의 핵심과 관련된 기능들이 위치한다.

    장점 : 각 계층에 인증과정을 모두 추가해 신뢰성을 높일 수 있다.
    단점 : 계층을 명확하게 구분하지 못하거나, 접근 가능한 계층 보다 더 밑의 계층을 이용할경우 성능 문제가 발생할 수 있다.
  • Client-Server Architecture ( 클라이언트-서버 구조 )
    - 각 서버가 서로 다른 기능을 구현하고, 클라이언트는 원하는 기능에 맞는 서버를 조합해서 서비스를 이용한다.
    - 여러 지역에서 공유 DB를 사용할 때 (ex: Youtube), 시스템 부하가 가변적이고 복제서버를 둘 수 있을 때 사용한다.

    장점 : 네트워크로 서버를 분산 배치할 수 있으며, 모든 사용자가 서비스를 이용할 수 있다.
    단점 : 성능이 컴퓨터 시스템 뿐만 아니라 네트워크 성능에도 의존하며, DOS 공격에 취약하다.
            또한, 여러 개의 기관이 서버를 소유할 경우 관리 문제가 발생할 수 있다.
  • MVC 모델
    - Model ( 데이터를 실제로 처리하는 곳 ), View ( 처리된 데이터를 보여주는 곳 ), Controller ( 모델과 뷰를 조합해 사용자의 입력을 처리하는 곳 )와 같이, 데이터를 처리하는곳과 보여주는곳을 분리한다.
    - Controller는 Model에 요청하고, Model은 계산된 결과를 View에 전송한다.

    장점 : 한 데이터를 여러 방법으로 보여주려고 할 때 유용하다.
    단점 : 데이터 모델과 데이터를 사용하는 방법이 간단할 때, MVC 모델을 적용하면 쓸데없이 복잡해질 수 있다.
  • Event-Driven Architecture ( 이벤트기반 구조 )
    - 여러 subSystem들이 하나의 mainSystem을 공유하며, subSystem들이 다른 subSystem을 사용할 때 함수 참조가 아닌 이벤트를 이용해 참조한다.
     - 이 때, mainSystem이 해당 이벤트를 수행하기 위한 Handle을 구현한다.
     - IoT 등을 구현할 때 유용하다.

    장점 : 시스템 변경이 상대적으로 쉽다.
    단점 : 이벤트가 언제 Handle될 지 예측할 수 없다.
  • Repository Architecture ( 저장소 구조 )
    - 각 subSystem들이 하나의 Repository를 공유한다. 단, subSystem Component끼리는 데이터 교환이 없다.
    - IDE와 같은 시스템을 구현할 때 유용하다.
     => Syntax tree, Symbol table들을 모아놓고, Text editor, parser, lexer들이 공유하게 한다.

    장점 : 각 컴포넌트가 독립적이며, 중앙 저장소를 변경하면 모두 적용된다. 중앙 저장소 데이터를 일관성있게 관리할 수 있다.
    단점 : 중앙 저장소의 문제가 전체에 영향을 줄 수 있으며, 중앙 저장소를 통해서만 데이터를 주고받는게 비효율적이다. 여러 컴퓨터에 동일한 저장소를 분산시키기 어렵다.
  • Pipe & Filter Architecture ( 파이프와 필터 구조 )
    - 배치 파일의 실행과 같이, 기능을 나열한 뒤 순차적으로 진행한다. ( 역순이나 순서변경은 일어나지 않는다. )
    - 앞 컴포넌트의 Output이 뒤 컴포넌트의 Input이 된다.

    장점 : 이해하기 좋고, 재사용이나 변환에 용이하며, 비즈니스 처리구조에 적합하다.
    단점 : 인접한 변환들 간의 데이터 형식을 미리 약속해야 하며, 이에 따른 변환작업이 필요하다. -> 시스템 부하 상승.

5. 설계의 원리 ( Design Principle )

  • Step-wise Refinement
    - Level 1 : 진행 순서에 대한 간략한 정리 ( 게임시작 -> 플레이 -> 종료 )
    - Level 2 : Level1의 각 순서에 대한 상세한 정리 ( 게임시작 : 버튼을 누를 시 -> 변수 초기화, 게임 판 초기화 -> ... )
  • Abstraction
    - 중요한 것만 보여주고, 중요하지 않은 내용은 모두 숨긴다.
    함수적 추상화 ( Procedure Abstractions ) : Interface만 보여주고, Algorithm은 숨긴다.
    자원 추상화 ( Data Abstractions ) : 데이터의 연산 method만 보여주고, 표현법은 숨긴다.
  • Modularization
    - Coupling ( 결합도 ) : 두 모듈간의 의존성. 두 모듈이 얼마나 밀접하게 작동하는가?
     1. Data Coupling : 모듈간 인터페이스가 매개변수 전달 등의 자료 요소로만 구성됨.
     2. Stamp Coupling : 배열이나 레코드의 일부 or 전역 변수의 일부만 전달한다.
     3. Control Coupling : 다른 모듈의 실행 순서를 제어 가능하다.
     4. Common Coupling : 여러 모듈이 공동의 자료 영역을 사용한다.
     5. Content Coupling : 다른 모듈의 지역 변수나 명령어를 수정 가능하다.
     위에 있을수록 결합도가 낮고, 아래에 있을수록 결합도가 높다.

     - Cohesion ( 응집도 ) : 한 모듈의 일관성. 한 모듈이 목적하는 한 기능에 대한 일만 수행하는가?
      1. Functional Cohesion : 모듈이 하나의 기능만을 구현함.
      2. Sequential Cohesion : 모듈 안에서 하나의 작업의 결과가 다음 작업의 입력으로 전달된다.
      3. Communication Cohesion : 동일한 입출력 데이터에 대한 명령을 모아둠.
      4. Temporal Cohesion : 동일한 시점에 사용되는 명령을 모아둠. ( Init 초기화 함수 등.. )
      5. Logical Cohesion : 모듈의 요수들이 논리적으로 관련이 있어서 모아둠. ( Math 클래스 )
      6. Coincidental Cohesion : 아무 관계 없는 코드들이 하나의 모듈에 있음.
      위에 있을수록 응집도가 낮고, 아래에 있을수록 응집도가 높다.
  • SOLID
    - SRP ( Single Responsibility Principle, 단일 책임 원리 )
     모든 모듈은 한 기능에 대한 책임만을 가져야 한다.
     -> 한 기능이 여러 모듈에 걸쳐 작동하는 경우 Aspect-Oriented Programming을 이용한다.

    - OCP ( Open-Closed Principle, 개방 폐쇄 원리 )
      모든 모듈은 기존 코드의 변경 없이 확장가능해야 한다.
      -> 어떤 기능에 대한 test를 진행할 때, 기존 코드를 건드리지 않고 할 수 있어야 한다.

     - LSP ( Liskov Substitution Principle, 리스코프 치환 원리 )
      부모 객체는 변경 없이 자식 객체로 대체 가능해야 한다.
      -> 부모.func()를 사용하는 곳에서 자식.func()로 변환해도 기능이 작동해야 한다.

     - ISP ( Interface Segregation Principle, 인터페이스 분리 원리 )
      복잡한 작업을 수행하는 클래스는 각 기능에 대한 인터페이스로 분리되어 상속받아 구현하게 한다.
      -> 복합기가 print(), scan(), copy()를 수행할 때, Printer, Scanner, Copier Interface를 상속받아 각각 구현해야, 프린트만 필요할 때 복합기가 아니라 Printer 를 사용할 수 있다.
      -> 결합도가 낮아지고, 보안이 향상된다.

     - DIP ( Dependency Inversion Principle, 의존 역전 원리 )
      고수준 모듈이 저수준 모듈에 의존하게 만들면 안된다.

 

 

 

 
 

 

728x90
반응형