소프트웨어시스템설계 2023-03-29 수업정리

Flow

• Review
• Design Pattern Overview

Review

---

• 사실 Code Smell 은 성능 측면에서는 별 영향을 주지 않는다.
• 하지만 code smell을 없에면 유지보수성을 강화할 수 있다.
• 현실적으로는 유지보수성 이외에도 ISO 25010의 여러 요소를 중요하게 판단해야 한다.
• 본 강의에서는 유지보수성에 중점을 두고 설명한다.

Design Pattern Overview

---

일반적으로 디자인 과정은 아래와 같은 세 개의 sub-process로 나눌 수 있다. 개발 과정에서 비슷한 코드를 재사용하듯이, 설계 과정에서도 이러한 설계사항을 재사용 할 수 있다. 이를 설계의 재사용이라고 하고 Design Pattern으로 정리되었다. Design Pattern의 사용을 통해 검증된 설계를 상황에 맞게 적용할 수 있다.

Example : Data - Views Consistency Problem

다음 상황의 문제점에 대해 살펴보자

• 점수 정보를 저장하는 ScoreRecord클래스는 데이터를 가공하여 출력하는 DataSheet, PieGraph, BarGraph 클래스에 정보 갱신 사실을 알리기 위해 association 하고 있다.
• DataSheet, PieGraph, BarGraph클래스는 ScoreRecord로 부터 점수 정보를 받아오기 위해 ScoreRecord에 association하고 있다.
• 이러한 설계는 새로운 그래프의 추가, 점수 정보 이외의 정보 추가 등 새로운 요구사항을 반영해야 할 때 OCP를 위반하는 문제점이 있다.
• OCP위반을 막기 위해서는 ScoreRecord가 나머지 클래스를 association하지 않아야 한다.
• 하지만 이 경우 점수 정보가 변경되었을 때 나머지 클래스에서 실시간 갱신이 힘들다는 문제가 있다.
• 이를 해결하기 위해 나머지 클래스에서 ScoreRecord클래스를 주기적으로 Polling하면 되지만, 이 경우 불필요한 recource를 낭비하게 되어 성능이 떨어지는 문제가 있다.
• 이런 총체적인 문제점을 해결하기 위해서는 Observer Pattern을 적용하면 된다.
• 아래 UML은 Observer Pattern을 적용한 UML이다.
• 구현은 항상 바뀔 수 있으니 인터페이스에 의존해야 한다.(DIP)
  • DIP : Dependency Inversion Principle
  • ConcreteSubject가 Observer를 직접 참조하면 ConcreteSubject가 여러 개일 경우 결국 duplicated code smell이 발생한다. Subject 클래스 생성을 통한 인터페이스 의존을 통해 이런 문제를 해결할 수 있다.
    • 기존 코드에서는 list, array, vector로 객체 리스트를 관리했지만, 인터페이스 의존을 할 경우 set등의 non-ordered 자료구조를 사용하여 관리가 가능하다.
  • 이런 식의 인터페이스 의존을 통해 Shotgun Surgery smell을 없엘 수 있다.
• ConcreteSubject가 ConcreteObserver를 직접 association하여 OCP를 위반하는 것이 문제였던 초기 상황과 달리, Subject가 Observer를 association하고 있는 상황이므로 OCP를 위반하지 않으면서 성능 문제도 없다.
  • ScoreRecord(ConcreteSubject)에서 Notify()호출 -> Observer의 Update()호출 -> 그래프 및 데이터시트 갱신